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:

• Java Server Faces (JSF) – Formally, the implementation of the JSF specification developed under JSR 127 and JSR 252. For those from the .NET world, this is tantamount to custom Web controls. The newer UI’s allow you to drag and drop JSF components onto a pallet and wire up event-based handling to build your user interface layer. As with the newer .NET components, AJAX capabilities are being built into a lot of these components. The Wikipedia writeup for JSF has links to several popular JSF toolkits, many of which offer online demonstrations or reference applications.
• Object Relational Mapping Support – Along with EJB 3 came the Java Persistence API, which codifies various persistence frameworks into a single API. This includes support for new Java 1.5 language features, such as annotations, which are pure Java metadata descriptors that can be used to interact with the persistence framework (e.g. Hibernate) being used. In addition, XML mapping descriptors continue to receive support. Particularly interesting to me was not the support for ORM, which has been an item in the Java developer’s toolbox for years, but the rich integration of the API support in some of the IDEs. I’ve included a screenshot from Oracle’s JBuilder that illustrate the steps in creating Entity Beans from existing database tables. In particular, note the ability to select the type of collection to be used as well as to annotate the collections as either eager or lazy loaded (see Fowler Lazy Load pattern from P of EAA) 
• ADO.NET vNext – This version of ADO.NET, slated to come out after the not-yet-released ADO.NET v3.0, is revolutionary in the minds of those at Microsoft. It’s great to hear the folks at Microsoft talk about impedance mismatch as if they had just discovered it. “With the new version of ADO.NET and LINQ and the powerful capabilities of the Entity Framework …” Y-A-W-N. C’mon guys, you’re just as far behind in the ORM world as the Java community was in the visual design and UI component world 5 years ago. Time to hit the gas and at least catch up. What should be really interesting is to see just how good the IDE support is for their Entity Framework. As you can see from the Oracle screenshot, Microsoft has a lot of catching up to do.

I tried answering Tad Anderson’s comment within the bounds of my August 8^th 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 82^nd Airborne, 10^th 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.

Deciding what type of software development process to use is ultimately a managerial responsibility. From this decision, to paraphrase a saying, will come 90% of your happiness or misery. Making the right decision requires that the manager has an intimate understanding of his team’s capabilities, understands the scope of the project, and has correctly assessed the level of involvement that can be expected from project stakeholders. This knowledge is, by no means, easy to come by; which helps explain why there is so often a dissonance between the approach applied and the one required. Just like with a SEAL team, there are limitations on the number of individuals that have the raw capabilities to be effective members of an Agile A-Team. If you done an honest assessment and are certain that the Agile approach is right for the project and you have an A-Team, then go for it.

As a footnote, this military analogy brings to light interesting questions of contingent or complementary force parallels in software engineering. That is, Operation Iraqi Freedom was fought with a mix of closely coordinated heavy armor, airborne, and special forces units. I can imagine that within an enterprise, or even within a project, there might be room for similar collaboration between high ceremony teams, medium-weight iterative teams, and light-weight agile teams. I’ve started to see the first signs of this on projects and would be interested to hear your take on this.

When I purchased this book almost 3 weeks ago, I was surprised to find that it had been on the shelves for 3 months already. Books that unify advanced architectural concepts such as Domain-Driven Design and design patterns are few and far between. This is especially true in the .NET world since many of the source materials originated in the Java realm.

Nilsson does a rather unique job of puling together some of the best domain-driven, object-oriented patterns and approaches and explain them using .NET-specific examples. The pros and cons, as I see them, are taken from my Amazon.com review and reprinted below:

Pros

• Combines the ideas of Domain Driven Design (Evans) with Patterns of Enterprise Application Architecture (Fowler). These books are pretty much mandatory reading prior to diving into this book.
• Draws upon a myriad of other well-known sources, including materials from Refactoring to Patterns and the GoF, work from Johnson and Lowy, as well as a rare reference to Naked Objects. The more experienced and better read you are, the more this stuff will make sense.
• Rare .NET coverage of advanced concepts like Plain Old CLR Objects (POCOs), persistence ignorant (PI) objects, O/R mapping with NHibernate, Dependency Injection, Inversion of Control, and Aspect-Oriented Programming.

Cons

• While some sections are really insightful and could contain more interesting materials, other sections seem to drone on too long. The work on defining the NUnit tests, in particular, flows like a stream of consciousness and doesn’t really add a lot of structured value to understanding DDD, patters, or TDD for that matter.
• Embedded comments in the text adopt from the style used in Framework Design Guidelines. It worked very well for Cwalina / Abrams in their book because it seemed planned in from the outset. Comments like “one reviewer commented on the code with the following, more succinct version” seem like editorial comments left in and not collaborative authoring by design.

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. 

Drop me a line and let me know what you think and, if you’re ever in the neighborhood, make sure to include this tourist attraction on your itinerary.

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.

Googling around, I was quickly able to locate the articles, which were published in two parts: Part I and Part II. Reading through the articles, I reflected on how far we’ve come in the .NET community since then. Continuous Integration (CI) and the tools supporting it have been embraced by the community and have found fairly widespread acceptance on commercial and open source products alike. In fact, the pendulum has swung so far in this direction that Microsoft decided that it was time that they undertook the effort to re-create these tools and repackage them within proprietary Microsoft products. The ultimate incarnation of this effort is Team System, which represents Continuous Integration and everything else tangentially related to the software development process rolled into one… and then given a shot of steroids - the proverbial 500 pound gorilla.

If you were thinking that the previous statement was a ramp-up to a bout of low-brow Microsoft bashing, you’d be wrong. Sure, Team System is huge and some of its beta versions were more like pre-Alpha. The last couple of demos I’ve seen, running off of laptops, I’ll add, looked not only fairly stable but pretty darn interesting. Since it was engineered from the ground up as an integrated suite of tools, the integration points appear much more polished than they do with the Rational Enterprise Suite. I can’t speak for how well the product works or for the validity of the third party extension approach. I can, however, attest to hearing quite a bit of interest from clients in the new product. If Microsoft would clearly articulate its strategy for integrating modeling tools with Team System, I would go as far as to say they’d had themselves a single and were picking up speed and heading for second.

If you pull back the covers on Team System, you’ll recognize all of the components that make up your standard Continuous Integration environment; the same ones I wrote about in the article. They’re all there and then some: a build engine, unit testing tool, code coverage reporting, static code analysis, and a completely revamped VSS version control system. This overt infringement on the open source’s domain might rub you the wrong way if you’re a proponent of the open source tools. I still love (and regularly employ or recommend) these tools but I’m open to the way that Microsoft went about making these ideas their own.

Employing James Newkirk, the creator of NUnit, to design the Team System unit testing tool leverages the lessons learned in building and maintaining NUnit and recognizes a valuable member of the open source community for his contributions. The story of a phenomenal documentation tool, NDoc, ends on a less positive note. Whether or not Sandcastle (Micrsoft’s codename for their new documentation tool) would have otherwise spelled the end for NDoc will never be known. The utter lack of financial and maintenance support for NDoc left its creator, Kevin Downs, frustrated enough to relinquish NDoc project ownership. Thankfully, Microsoft has picked up the ball here and I’m sure that once the bugs are worked out, we’ll be able to easily churn out documentation for our .NET 2.0-specific code.

“So where does this leave us?” you might ask. It leaves us with options. Choose to use the open source tools or their Team System counterparts. If you’re feeling particularly lucky, you can write some custom build script tasks and mix and mingle the two. Either way, acceptance of continuous integration will continue to grow in the .NET community. Furthermore, CI will continue to be augmented by tools of ever-increasing sophistication, be it Team System from Microsoft or a Trac or NProject-like variant from the open source community. This is good news for those employing the .NET platform or those considering a move in that direction.

Pennsylvania’s Office of Information Technology (OIT) issued the Keystone Technology Plan to serve as the information technology blueprint through the year 2009. The plan’s phased approach is quite interesting, with the following phases taking center stage:

• Yesterday: Enterprise Planning and Governance
• Today :Shared Infrastructure Services
• Tomorrow: Business Centric Services

BSCoE plays a prominent role in OIT’s vision and is mentioned as a driver of infrastructure today and key player in the creation of business-centric services in the future.

Although I was notified of this release through offline communications channels, I also stumbled upon a Technorati link to a Pennsylvania-specific technology blog – PATechSpot. The folks running this blog seem to have a pretty good handle on technology happenings in the Commonwealth. It’s definitely a site worth adding to my blogroll.

For some time I’ve been giving thought to user-generated content on the Internet. In particular, I’ve been interested in audio and video content. A recent post by Dion Hinchcliffe drove me to put a bit more structure around my ideas and put pen to paper, figuratively speaking.

I’ve been following Dion’s blog for nearly a year now and his writing helped shape my thinking about Web 2.0. Although I strongly agree with his statement that user-generated content is one of the pillars of Web 2.0, it appears that we disagree somewhat with respect to the limits of its potential. I can honestly say that user-generated content on sites such as Amazon.com, Wikipedia, and del.icio.us has added tangible value to my online experience. In many ways, there is no way to even emulate these services in the world outside of the Web. I don’t think, however, that I will ever be able to make a similar assertion about video and YouTube, in its current incarnation.

Call it frivolous, but I’d rather spend a couple of dollars to download the latest version of Lost or 24 onto my iPod than watch any number of the best of the best YouTube clips. Creating quality programming usually involves capital expenditures beyond most individuals’ means; casting and directing a team of professionals – be it actors, animators or otherwise; leveraging a professional production staff; and having a mechanism for distributing this programming. YouTube only addresses one facet in the programming production chain – distribution.

The fact that YouTube represents such a radical departure from traditional video content distribution channels has lead many to attribute much more disruptive potential to YouTube than might ever be realized. In my opinion, creating video content that will compel a potential audience to pay to be entertained still requires a talented team and some degree of financial backing. The existing TV networks, their content acquisition pipelines, and advertising revenues continue to be the driving force in enabling the creation of programming with sufficient mass market appeal to justify its creation.

In many cases, the existing networks churn out content of questionable artistic, societal, and intellectual value. In some cases, however, they hit a home run. Will a Seinfeld or 24 ever emerge from YouTube directly? I consider this highly unlikely. In this sense, I believe that the true power of YouTube and its Web 2.0 brethren is the way they can shift the balance of power in the way that quality media is identified and consumed.

The trend towards on-demand and pay-per-view programming is already well underway. Leveraging Internet technologies, YouTube can compound this trend by decoupling us from conventional viewing medium (the television) and making video consumption location independent. It also provides a channel for aspiring actors, directors, and producers to create and distribute content of real artistic, societal, and intellectual value that they might otherwise never have had. This channel could also serve as a feeder for obtaining lucrative financial backing and making a trip to “the big league”.