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.

The BSCoE4J Java application development framework was released today to the Commonwealth and is now available for download. The framework contains both abstract and concrete components that support the creation, manipulation, and persistence of domain objects. It interfaces well with, and is meant by no means to supplant, well-understood open source frameworks that address presentation layer, persistence layer, or domain object creation and discovery challenges.

The addition of the BSCoE4J Framework as the third core BSCoE assets rounds off the BSCoE offering for custom enterprise application development. BSCoE4J joins the BSCoE.NET Framework and the BSCoE Software Engineering Process (SEP), forming a comprehensive set of tools for Commonwealth applications looking to do development in either Java or .NET.

Jacob Reimers’ Google Maps Control has been a genuine blessing for me over the last couple of days. After a lot of prototyping with Google and Yahoo maps, I decided to go with Google maps for GeoGlue and keep Yahoo maps open as an option based upon the development of the APIs as well as any potential licensing or usage constraints. After dealing with the Google APIs directly, and feeling the pain of issues such as the well-known Internet Explorer “Operation Aborted” maps loading issue, I was yearning for an intermediary API that had already thoughtfully addressed some of these issues.

The Google Maps Control does just this and more, and hit the sweet spot of platform combinations that I was dealing with - .NET 2.0 and Google Maps v2.0. The component is well documented and its design well thought out. Its naming convention emulates the Google API naming fairly closely, so when in doubt, most standard Google Map documentation will lead you to the answer of how to address the issue with the control’s API. The control also contains methods to support Google’s newly released geocoding functionality as well as support for Yahoo’s geocoding functionality, which by virtue having been around longer, is more likely to be in use in existing applications.

The component is well maintained and aligns well with the newest releases of the Google API. It is closed source but free for all use (Jacob’s words) although no license is included in the distribution. Best of all, it enables you to remove all the Javascript references in your .NET source code and use pure C# / VB.NET. The sample below is a snippet from GeoGlue that replaced 60 odd lines of Javascript code scattered across several files. In brief, it sets the latitude, longitude, and markers and then adds a number of markers to the map from a data source -- all in pure C#.

GoogleMap.Latitude = double.Parse(locationResult.Latitude);

GoogleMap.Longitude = double.Parse(locationResult.Longitude);

GoogleMap.Zoom = 1;

while (ProductResults.read())

{

   GoogleMarker gm = new GoogleMarker();

   gm.ID = ProductResults["Title"].ToString();

   gm.Latitude = double.Parse(ProductResults.["Latitude"]);

   gm.Longitude = double.Parse(ProductResults.["Longitude"]);

   gm.MarkerText = "<b>" + ProductResults.["Title"].ToString() + "</b><br\\>" + ProductResults.["Description"].ToString();

   GoogleMap.Markers.Add(gm);

}

I received the Bose SoundDock as a gift for Father’s Day (thank you girls!) and felt compelled to tell everyone about it. For a couple of days, I mulled over trading in the white model I received for a black model to match my IPod. After reading all the glowing reviews on Amazon.com, I just couldn’t bear waiting another week to try the SoundDock out. I was not disappointed…

The sound on the unit is incredible given its small size. What’s most amazing is that you can crank up the volume and get little or no sound degradation. Given the rather limited controls on the speaker unit, fine tuning is more a matter of tweaking the IPod’s equalizer settings. It gets around pretty well within the house, having made the rounds from the bedroom to the study and ultimately to the basement to accompany me for workouts. From the reviews I read, it would seem that caution (and adequate packing) is advised for transporting the SoundDock over longer distances. I believe that a separate case is available for the SoundDock. If nothing else, you can box it up again and move it around that way.

With a $300 non-negotiable Bose pricetag, the SoundDock doesn’t immediately appeal to your thrifty consumer (that’s me). However, I implore you to drop by your local electronics store with your IPod and give it a listen with some of your favorite tunes. You might be surprised at how compelled you feel to get a SoundDock after you’ve heard how it sounds.

Since I originally published my article on active authentication in the Java Developer’s Journal a couple of years back, I’ve been receiving a trickle of requests for the source code. It looks like the article is still available online although the accompanying source code seemed to have disappeared. I rummaged through my archives and dug up the WAR file containing the source code in case you’re interested. I can’t vouch for its absolute correctness. I seem to recall recreating the source code for a guy in Switzerland a couple of years back to run on Tomcat 5. I’m not sure if this is the version I’ve posted.

ActiveAuthentication.war (6.11 KB)

Also, since I’ve been less involved with Java over the past 3 or 4 years, I’m not sure that this solution is even necessary or applicable anymore. Even when the article was written, there were various degrees of vendor support for active authentication through HTTP filters across the various platforms. I most vividly remember the differences between Tomcat and Websphere. Give the code a whirl and let me know if it works or needs a bit of improvement.

With Suzanne and the kids away for a week, I’ve been holding up my end of the bargain and working to make some significant progress with GeoGlue. After getting hung up quite a while on the nuances of Google and Yahoo maps – not to mention Flash encoding -  I chose to take a more lightweight approach to getting a first-cut working product out to production. I’ve revamped the user interface pretty significantly but still  many of the tried and true styles still manage to show through.

I’m now engaged in getting the site ready for a production push, albeit in a much scaled-back mode, prior to my departure for Detroit on Friday. I’ve included a fuzzy screen shot to give you and idea of what I’m dealing with. As always, if you’re interested in becoming an alpha adopter, drop me a line at alpha@geoglue.com.

The BSCoE project recently received a Computerworld Honors Program laureate honoring the project for its use of information technology to benefit society. It looks like the official case studies and pictures of the award ceremonies have been posted online. You can find the BSCoE case study here. I’ve also included a couple of interesting photos from the Computerworld ceremonies including the snapshot of our client receiving the award.

I’ve been experimenting quite a bit with Web-based video for GeoGlue as of late. I knew very little about the medium out of the gate but with a bunch of reading and prototyping over the past couple of weeks, I’ve learned quite a bit. The first revelation to me was that the majority of professional-grade video sites such as YouTube and Google video encode their video as Flash. A bit of further research found claims of 98% pervasiveness of the Flash plugin, as opposed to much lower rates for Real, Quicktime, and Windows Media. Scott Persinger’s post on the video format wars proved to be quite interesting reading in this respect.

My first inclination was to look at desktop-based software for Flash video encoding just to get a feel for the potential end product and dealing with streaming media. Most of the software that is available for desktop Flash video encoding is extremely easy to use and provided the encoded video, JPEG stillframe, video player controls, and an HTML snippet as the end product. I tried out encoders from On2 Technologies, Blue Pacific Software, and MSI Web Video. All of them worked pretty well and provided a good way to generate Flash-based video suitable for posting to a Web site.

What GeoGlue really needs, however, is to provide on-demand, server-based encoding of a variety of audio and video formats into Flash. It appears that On2’s Flix Engine API is one of the market leaders in this area. I chose, however, to experiment with the Turbine Video Engine SDK from Blue Pacific. The Turbine SDK proved to perform efficient asynchronous and synchronous conversion of videos to Flash. Its potential shortcomings (based upon your requirements) are that it does not encode to Flash 8 and that it is intended solely for deployment on Windows-based machines. Wrapping the Turbine SDK calls in a component called by a Windows Service running cron-type jobs proved to be more than adequate for meeting my needs.

Scott also provided an excellent follow-up entry on Web-based video that handles the costs associated with video-based hosting. This was my first introduction to Content Distribution Networks (CDN) such as Limelight Networks. This post was quite an eye opener and is causing me to reexamine the long-term costs associated with the growth of GeoGlue. In subsequent reading, I’ve been floored by some of the numbers that I’ve heard thrown around for streaming media hosting. Most recently, I recall reading that YouTube’s bandwidth costs alone total a couple of hundred thousand dollars – per day. Keep that VC funding flowing…