Beckshome.com: Thomas Beck's Blog

On October 4, 2006, the Pennsylvania State Capitol Building celebrates the centennial anniversary of its dedication. In honor of this special event, I have created a GeoCast for the Capitol building, its art, and some surrounding points of interest. This GeoCast can be downloaded or streamed in MP3 format by clicking the link below or by going to the Pennsylvania category on GeoGlue.com.

If you are interested in further information about the Capitol or the centennial celebration activities, the Capitol Preservation Committee website provides a treasure trove of information. If you can’t make the trip to Harrisburg but would like to experience the Capitol’s beauty, a QuickTime virtual tour is available on line as well.

In addition to the technical assets that I’ve mentioned in previous blog postings, BSCoE also makes a set of software process assets available. These software process assets are arranged into disciplines and collected under the umbrella of BSCoE’s Software Engineering Process (SEP). Information about the BSCoE SEP is available online to the general public.

The SEP is based roughly upon the Rational Unified Process (RUP) and Microsoft Solutions Framework (MSF). Those looking at the sample assets will notice the similarities with the standard RUP templates. The process component of the SEP is specifically vague, leaving decisions such as formality versus agility, process activities, and roles to the projects employing the SEP. In particular, projects have several options for SEP customization including document-driven (RUP-style development case), local modifications to the process, or modifications with intent to contribute back changes to BSCoE for inclusion in the master SEP distribution. The SEP is conceptually similar in some ways to Ivar Jacobson’s new Essential Unified Process (EssUP). However, whereas the EssUP variability comes through the selection of practices, SEP’s variability comes through the selection of artifacts.

I’m not well-versed in the nuances of NASCAR racing and don’t understand the spectacle very well so when I say this, please take it with a grain of salt. The whole Java versus .NET thing seems to me like a NASCAR race, one car edging ahead of the other and then again giving up ground to the competitor… on and on again for countless monotonous laps. I am in the process of re-immersing myself in the newer releases of Java. It has been years since I dealt with Java on a regular basis – the 1.1 through 1.4 days. This week, I had the chance to see a lightweight EJB 3 container in action, working through Oracle’s slick new IDE with integrated Java Server Faces (JSF) and Object Relational Mapping tool (Toplink, in this case) support. Suffice it to say that I was floored with the progress the Java community had made away from the monolithic J2EE / EJB 2.1 towards the lightweight model espoused by frameworks such as Spring. Just when it appeared that the Java car was pulling ahead ready to steal the race, along comes the announcement of the Community Technology Preview of ADO.NET vNext. NASCAR fans, we’ve got ourselves a race again. Below I offer a preview of some of the aforementioned technologies:

I tried answering Tad Anderson’s comment within the bounds of my August 8th posting but eventually decided that this topic really warranted a posting of its own. My thoughts around using Extreme Programming and other Agile approaches to software development are pretty well formed. As an ex-soldier, military analogies seem to work particularly well for me:

• On the high end, the truly capable XP team is small, lightweight, and meets the requirements Tad set forth in his post. In many ways, effective Agile teams parallel our military’s elite special forces (e.g. SEALs, Green Berets, Delta Force, etc).
• In the middle, there are well-trained, capable teams that practice UP, ICONIX, and other iterative processes with varying degrees of agility. These teams may infuse certain XP practices into their process as they are needed. The individuals on these teams may have the mettle to be elite special forces. However, due to project requirements, team size, or other factors they are not “active operators”, in military parlance. These folks operate in a fashion analogous to our highly-skilled tactical units, such as the 82nd Airborne, 10th Mountain, and the like.
• On the lower end (of the agility scale, that is) are teams that mirror our more traditional Army units: infantry, mechanized infantry, armor, artillery, etc. Their capabilities are more geared toward larger, more structured engagements. Backing these capabilities are detailed approaches and tactics, significantly greater support and infrastructure requirements, and longer lead times to get a team on the ground to effectively engage the problem.

So where does this leave us? To me, at least, it’s pretty clear that, on software projects, as in combat, there is no one-size-fits-all approach. I would no more likely try to tackle building an air traffic control system with XP than I would send in a special forces team to face off against a Soviet armored column. Analogously, I would neither call in the third armored division to handle a jungle-based guerilla insurgency nor try to use CMM level 5 processes to build a simple Web-based e-commerce application.

Three Mile Island, the nuclear power plant which, at least figuratively speaking, is located right in my back yard, was the site of the nation’s worst nuclear disaster in March of 1979. What better site to select for my first custom Geocast then something so near and dear to the locals’ hearts.

Sure, the recording quality is not great but it just further proves that it doesn’t take too much to create a Geocast, convert it to an MP3, and upload it for consumption. I’ve included a link to the file below but you can, of course, also find this under the Pennsylvania category on GeoGlue.com.

With two little girls running around the house, I have plenty of material to fuel my zeal to experiment with online audio and video. I uploaded a cut of Anna using her own utensils for the first time.

Aside from the family and sentimental value, I learned a couple of things for a first timer:

• Use firewire and not USB for video transfer. This makes all the difference in the world.
• Don’t use the WMV format. I uploaded WMV instead of AVI at the recommended screen size and after the conversion to Flash, there’s quite a bit of residual fuzz.
• YouTube is slow in the evening (8:00 – 11:00 EDT). Video playback drags quite a bit. This will impact willingness to leverage YouTube video content externally.
• There doesn’t appear to be the ability to download YouTube video. I believe this option is provided on Google Video. Once again, this impacts ability to integrate into other applications.

All-in-all, YouTube makes uploading and sharing video an easy process. I can’t say that I understand their revenue model but someone is paying the one million dollar network costs they ring up monthly with their content distribution network and, at least for now, it’s not me.

I received an email from one of my clients a couple of days back referring to a quote of mine on Cenqua’s website under their Clover.NET product. This brought me back to an article I wrote for Dr.Dobb’s Journal when build tools, unit testing products, and continuous integration were making their way from the Java world over to .NET. I decided to meander over to Dr.Dobb’s site (I still call it a site although a barrage of emails from CMP Media constantly reminds me that it’s a new and improved portal) and see if the article is still available.