Follow this blog:: RSS; Email Alert

Software Engineer

Programming news: Reflector, BlackBerry AppWorld 2.1, HTML Working Group

February 15, 2011, 2:04 PM PST

Takeaway: Read about IronPython 2.7 Beta 2, Mule iON, Windows Phone tools and tips, BlackBerry tablet simulator, Async examples, and more.

Language/library updates

IronPython 2.7 Beta 2
The IronPython team released the second beta of IronPython 2.7.

Tools and products

Mule iON in beta
I spoke to the team at MuleSoft about the beta of Mule iON. It is an integration platform offered as a cloud service. Instead of trying to code disparate systems to match each other, you have them match the iON interface, which links them together. This makes it much easier to re-use services, and it reduces the need to write per-application integrations.

Reflector goes paid
In a move that has surprised and angered many in the .NET community, Red Gate is going to discontinue free versions of the popular tool Reflector.

Pervasive DataRush 5.0
Pervasive released DataRush 5.0. Its big new feature is the ability to scale across clusters.

BlackBerry AppWorld 2.1
BlackBerry AppWorld 2.1 has launched. It includes the ability to add in-app payments.

January WP7 tools update
The Windows Phone 7 development tools have been updated, including copy/paste support.

BlackBerry tablet simulator updated
RIM updated its tablet simulator. The full BlackBerry Browser is now included.

SOASTA CloudTest Pro
SOASTA announced CloudTest Pro, a system for testing cloud-based applications (including Azure and AWS).

Editorial and commentary

HTML Working Group charter extended
The HTML Working Group (currently working on HTML5) has had its charter extended. Along with it came the responsibility to get to Last Call by May 2011, and reach Recommendation status by the middle of 2014.

Dilbert explains the economics of downsizing
Dilbert is usually pretty good, but the 2/13/2011 strip about downsizing was particularly outstanding.

Tips and tricks

How to make sample data based on a class
Kirupa Chinnathambi posted a tutorial on how to use Blend to generate sample data from a .NET class. This is very useful when developing an application.

RSS on Windows Phone 7
Arik Poznanski put together a free library to read RSS on WP7.

101 Async examples
Here are 101 examples in C# and VB.NET that show off the functionality in the new Async CTP. (You must have Silverlight installed to view the content.)

Silverlight OOB apps and the Taskbar
Kunal Chowdhury wrote a good article about how to get Silverlight Out of Browser apps to work with the Window 7 Taskbar.

Events

Delphi Developer Days
The Delphi Developer Days conference is coming to Washington DC, Houston, Frankfurt, and Amsterdam in April and May. Check the Delphi Developer Days site for specific dates and more details.

NetBeans Day in Munich
There will be a NetBeans Day event in Munich on June 18.

Nebraska CodeCamp looking for speakers
The Nebraska Code Camp is looking for speakers. The conference will be held April 9, 2011.

J.Ja

Get IT Tips, news, and reviews delivered directly to your inbox by subscribing to TechRepublic’s free newsletters.

About Justin James

Justin James is an employee of Levit & James, Inc. in a multidisciplinary role that combines programming, network management, and system administration. He has been blogging at TechRepublic since 2005.

Full Bio
Disclosure
Contact

Checking out the Vim code editor

Try the SL4A scripting environment for your Android device

People who read this...

Comments

Add Your Opinion

Join the conversation!

Follow via:: RSS; Email Alert

See All Comments

Staff Picks
Top Rated
Most Recent
My Contacts

No messages found

0 Votes

+ -

Contributr

One of OO's purported benefits...

Justin James 17th Feb 2011

... was that you could split the work up better. Have a central committee or architect define common interfaces, abstract classes, etc., and the teams could code against those specs, even if they were just stubbed out and waiting for other teams to implement them. Of course, as we know, this just required a different kind of micro-management to keep everyone on the same page (the Rational suite, anyone?) and replaced the "programmer analyst" with the "architect" as a gatekeeper, bottle neck, single point of failure, and general nuisance. happy

J.Ja

View in thread

0 Votes

+ -

Keep teams to four people max.

Mark Miller 16th Feb 2011

This was what we talked about in college, and what us engineers talked about at work. A huge amount of project work is communication. If you make a team larger than four people, the overhead starts to eat into your productivity. This is what we saw in practice as well. I heard in college about projects being done with hundreds of people, but they took a very long time, and were frequently beset with bad designs that needed to be corrected during the project. There was also a premium put on documentation, as I recall. This might've substituted for the technical meetings you were talking about. There would be a team (or perhaps multiple teams) dedicated to creating and revising the technical documentation. All of the technical documentation would be fleshed out so that there was very little that the programmers had to think up, though I imagine there had to have been feedback loop processes, because in any project, stuff you think will work often doesn't, and so needs to be corrected. You don't know until you try it.

One of the design strategies we talked about was thinking in terms of interfaces, adding in extra parameters to functions that were just dummies at first, but could be filled in later if need be, so that other functionality that depended on that interface wouldn't break with each change. This was during the time when procedural programming was the norm, not OO. I imagine SE adopted a similar strategy with OO (though without the dummy parameters), since the popular languages in that genre allowed you to create new interfaces on the fly for the same class.

View in thread

0 Votes

+ -

Contributr

I've been in similar environments...

Justin James 15th Feb 2011

... where the meetings were so frequent that the truly took away your ability to do your job. Often, you were at the office to go to meetings more or less, and then had to actually do your job after hours. It was pretty miserable after a certain point. So we started hiring, and for everyone that we hired to do work, we had to have MORE MEETINGS to keep everyone on the same page. It was a disaster.

Looking back, there were two fundamental problems:

* Too few people had the ability, total project knowledge/insight, or the authority to operate independently, so you needed to have meetings to make sure people knew what to do.

* The project crossed too many teams, so you needed to have meetings to make sure that each team was on the same page.

So you'd get this awful situation... all of the leaders would have a meeting to figure out what to do (the cross team meeting). Then each leader would have a meeting with their team to tell them what to do. Then there would be another cross team meeting amongst technical members to coordinate the details. Then the technical people would need an internal team meeting to let everyone on the team know how things needed to be done to coordinate. Then the leaders would need another cross team meeting to explain to the other teams how the changes to the original plan made within the team would affect the greater vision.

Repeat. Forever.

Needless to say, it was a mess. We tried less meetings, and people got out of sync and work had to be thrown out or the customer didn't get what they had asked for. We tried more meetings, and no one had time to get anything done. Great example of where 2 - 5 "rock starts" can demolish problems but a team of 20+ average folks can't, because you don't have to deal with the inefficiencies of scale.

J.Ja

View in thread

Once logged in, adding contacts is simple. Just mouse over any member's photo or click any member's name then click the "Follow" button. You can easily manage your contacts within your account contacts page.

See all comments