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”.

The first, albeit very rudimentary, version of GeoGlue is now available online at www.geoglue.com. As described in previous posts, this release is really nothing more than a soundseeing mashup with Google maps. The functionality is very basic, allowing the user to browse for soundseeing tours graphically using maps and a menu system or to search for tours using a combination of keywords. All tours are provided via MP3 streaming audio, either from the site that created the tour or from GeoGlue.com directly.

We are planning a follow up release in the near future. This release will make the map-based transitions a bit smoother by using AJAX instead of pure postbacks. We will also be working on increasing the content base, allowing users to suggest new soundseeing torus and rolling out a user provisioning system. Keep your eyes open and, as always, email us at admin@geoglue.com if you have any questions or suggestions.

Phil Windley’s recent post on e-Government mashups is a great introduction to the topic of citizen-facing Web services. As refreshing as it is to see that progressives in Rhode Island and the District of Columbia are exposing government data to their citizens and opening themselves to the law of unintended consequences, this only scratches the surface of what is possible. As I’m sure Phil knows as a former state CIO, fully open citizen self-service is likely to only go so far. As cool as it is to mashup public highway, crime, and public entity data on a map for the world to see, enabling truly effective government is going to be, to a greater extent, dependent upon empowering government knowledge workers. Imagine if, as an example, a knowledge worker was able to pull together information from their state’s welfare, criminal justice, and revenue (i.e. tax) systems and mash these up in a way that enabled them to uncover hidden relationships between this data and serve the state’s citizens more effectively.

Behind the scenes, what state governments should be doing is exposing all of their data through services. Then, through the combination of public policy setting and comprehensive identity management frameworks (another thing Phil knows a thing or two about), they can filter through as much of that data as is possible and allowable to each of their discrete stakeholder groups. Those of us working on such monumental tasks recognize that this is truly much easier said than done. However, the rewards of pursuing this route clearly are worth the effort expended. Although I do have a working knowledge of other states’ activities in this area, I can say concretely that Pennsylvania has already begun reaping the rewards of pursuing this approach. Our state’s Justice Network (J-NET) system is allowing for the effective exchange of offender, court, and other criminal justice data between state systems and empowering the knowledge worker. This ranges from high level policy setters who can now integrate criminal justice information into their data analysis and policy setting right down to the police officer making a routine traffic stop who can now more comprehensively assess the situation using data available on his wireless device.

Phil has got it right when he says that the goal should be to “set the data free”, exposing ourselves to the law of unintended consequences. the thought of better informed citizens, empowered knowledge workers, and greater transparency cause those famous words to echo through my head - government of the people, by the people, for the people.

A couple of weeks ago, I was asked to describe what GeoGlue was. Although, we have a far-reaching strategic vision for GeoGlue, I can describe the functionality in the initial release using two words – “Soundseeing Mashup”. Now both of these words are fairly new additions to the English language. The mashup concept has gained a good deal of traction through all of the Web 2.0 writeups. Soundseeing, on the other hand, was a term that even I had not heard until just a couple of weeks ago.

Wikipedia, in its very brief description of soundseeing, describes it as an audio tour that uses the ambient sounds and descriptions given by a tour guide to give the listener an accurate depiction of the surroundings. These types of recordings are usually made at tourist points of interest and are commonly distributed through podcasting  Soundseeingtours.com provides a collection of links to get you started on understanding soundseeing. The New York Minute Show appears to be a leader in the genre, with a number of podcasts covering popular areas of New York City. The Amateur Traveler is also pretty good, with a diverse geographic focus and a good bit of content collected over the last year or so.

GeoGlue, then, mashes up soundseeing tours with Google Maps. Now I can hear you thinking, “just what the world needs, another Google Maps mashup.” Please bear with us, the mapping component is only one of GeoGlue’s facets. It just happens to be the facet that gets the most visceral reaction from people and is therefore a great feature for our initial release.

In going about assembling some initial content for GeoGlue, what I did discover is that the barriers to entry in soundseeing are fairly low. Not to knock any of the podcasts available out there now but with a small investment of time, anyone could tell a somewhat compelling story or stories about the town they grew up in, work in, or traveled to. We at GeoGlue are counting on this and will be reaching out to you to collect your stories in the not-so-distant future.

I was revisiting an article I penned very optimistically several years ago about open source software collaboratives. Most notably, I mentioned the Avalanche Corporate Technology Cooperative and the Government Open Code Collaborative (GOCC). These were (I stress the “were”) seemingly ill-fated initiatives to share the source code to business applications in the commercial and public sectors, respectively.

Open Source Article.pdf (550.16 KB)

Checking on these initiatives two years hence, I discovered that there has been scarce an update to either one of these sites since I wrote the article. Looking back and reflecting on my thoughts and experiences over the past couple of years, I realize that these two initiatives were destined to fail and that the open source community is unlikely to produce quality, open source enterprise applications. Allow me to compare.

The market for infrastructure software such as operating systems, servers, and utilities is occupied by a competitive mix of open source and commercial products. The margins on these products and their support services are low and there is little value added by offering unique product configurations. The market for enterprise applications, on the other hand, is occupied by businesses, system integrators and the software developers they employ to build their applications. Organizations may derive significant business value from product differentiation and custom configurations and there are no incentives for sharing of software at this level.

However, despite all of these important points, the most important reason why open source enterprise applications are unlikely can be explained in two words – critical mass. A significant amount of effort is spent making sure that open source operating systems, servers, and utilities run on a variety of software and hardware platforms and can be configured in a myriad of ways to meet business needs. The only real parallel in terms of the enterprise application world are enterprise resource planning (ERP) systems from companies such as SAP and PeopleSoft. Even these systems are known for how difficult they are to configure. The open source community will likely never see the case for building infinitely configurable enterprise applications that serve a handful of organizations at most.

Given the growth of Web 2.0, mashups, and Web services, it remains to be seen whether enterprises choose to leverage any or all of these developments in their applications. Perhaps open source enterprise applications aren’t really applications at all, just mashups of different open services that look like what we used to refer to as “enterprise applications”.

I stumbled onto the book Getting Real: The smarter, faster, easier way to build a successful web application while cancelling my Backpack service with 37signals. True to the advice they give in the book, 37signals made cancelling their service very easy – one of many valuable nuggets of advice offered in the book.

Getting Real describes the practices, both software development and beyond, used by 37signals, a small company that despite their excellent, easy-to-use applications is perhaps still best known as the innovators and driving force behind the Rails framework. Given the tie to the Rails creators, it is not surprising to learn that this book espouses an Agile approach to software development. What differentiates this book from other Agile texts is that it blends both Agile software development practices with, dare I say it, pragmatic guidance from 37signals and other industry notables on the business of creating, releasing and managing Web applications in the Web 2.0 world. This includes advice on staffing and the organization (borrowing from Peopleware), application design (using a user story / UI approach as opposed to a user story / domain object approach), pricing and signup, promotion strategy, support and post-implementation activities.

The book could not have been released at a better time. It will function very well as a handbook for operations at GeoGlue as the team expands. To that extent, I believe you can even purchase an organizational license to the book for about $50. There are a couple of real gems in here (for the Ruby crowd, no pun intended) – one of my favorites is the obligatory sections beating up on functional specifications.

“A bunch of people agreeing on paragraphs of text isn’t true agreement. Everyone may be reading the same thing but they’re thinking something different. This inevitably comes out later on: ‘Wait, that’s not what I had in mind.’ ‘Huh? That’s not how we described it.’ ‘Yes it was and we all agreed upon it – you even signed off on it.’ You know the drill.

Further, I appreciated the analogy between agile approaches and parallel efforts outside of software engineering such as military special operation forces and hurry-up offenses in American football. In this respect, I’m sure functional specifications will continue to have their place, as do conventional forces that constitute the majority of our military and the huddle-based offence run during 95% of your average football game. Getting real is a great approach – but it’s not the only approach.

In the end, I measure a book by how timeless it is and how often I refer to it after my initial reading or perusal. I believe that, in this sense, Getting Real will take a coveted position next to classics by Fowler, the GoF, Stephens, Wall, and others.