Friday, December 30, 2005

Enterprise = Answering the wrong question

"Enterprise will follow legacy to become a common insult among software creators and users"

I don't think legacy is a bad thing (definitely better than failed projects), but I definitely agree with David H.H.'s post that the concept of "Enterprise" software has lost a lot of luster. I have been part of a couple of these roll outs, and it's never pretty. There's something about software that is supposed to everything that makes it do nothing particularly well. This "Coding Horror" post linked to in the comments is even more to the point. Enterprise buyers seem to purchase based on the number of checkmarks in the feature list, rather than based on how well any of those check marked features actually work. Would you buy a new car based purely on the spec sheet?

I can think of one situation where we had a large number of users on a client/server ArcView system that I had put together in 1996-1999. We worked out a nice locking system for multi-user access at different sites and built a lot of custom extensions. There was a massive push in 2001 to replace it with a web based "Enterprise" system based on ArcIMS. I tried to help them out for about six months, but it was obvious that ArcIMS at the time was only going to be able to provide about 50% of the features and performance to which the users had been accustomed. Plus, they now had to ask someone to add new base map data instead of being able to add it themsleves among other indignities. I escaped prior to the first deployment, which was a complete disaster and the project eventually skidded to a halt.

Honestly, there was no need to replace the system, it just needed a new name for political reasons as two projects were being merged. As it stands, they are still cruising along as we head into 2006. The project might actually make a little more sense now that we have some better web browsers available, but there are some tasks that you just don't want to do in a browser. I feel like the enterprise version of Photoshop would be browser based, with some workflow where you had to get managerial approval before you changed your color pallette.

What languages should students learn?

In an article that is creating a fair amount of discussion, Joel (on Software) Spolsky rants against kids learning Java in school. I think it's a bit of a strawman, as I don't know of any schools that only teach Java to CS majors, but that would be pretty sad. I think in four years you ought to have time to really learn a couple of languages, and get exposed to a few more. I wish I had been able to take MIT's 6.001 [see image for objectives].

I like the approach of starting on both sides, with a high level and a low level language. If you can see how assembler works, you can start to see the reasoning behind things in c works, and then when you see a bunch of c code, you understand why a lot of the memory management and abstractions were added to the other languages. I like the idea of understanding what things are more efficiently accomplished in a high level language versus which things need to be done in a low level language in a hands on fashion.

Now, what about the people that can only deal with the abstractions? I mean for reasons of patience or just lack of interest, some people aren't interested in understading things all the way down. I don't think it's wrong to stop at a particular level of abstraction for those people. Maybe they don't need to know about pointers, but it is going to limit what kind of work they can do effectively.

Maybe the right answer is that you have to understand at least one level of abstraction below where you work. I think that is enough to uncover one level of problem. I have run into Java programmers that know a little c++, but didn't realize all of their variables were pointers to memory, and they do have problems writing code that takes advantage of that fact. The pointers are still in there in the languages that abstract them away- it's just a little harder to screw them up, or make them do exactly what you want.

Thursday, December 22, 2005

Excel as interchange format

I really like the concept Dion Almaer outlines here. If your users already have a flexible data entry tool that they are experts at using, why not allow them to use that as the data entry tool for your system? To me this is real re-use, and despite Dion's claim that it isn't sexy, I find it rather attractive.

To me this is the essence of what is wrong with letting the Enterprise Architects dictate user experience. James McGovern, an enterprise architect whose book I really like, has been going on and on about how "web 2.0" is not something that architects should be thinking about. [see his 2006 predictions post for an example] I really think it is something that they should be focusing on- improving the user experience. I think if you think that way, you build an Excel import function. If you think the bad way, you build a complex user application that is buzzword compliant ESB, SOA, EBI, etc. forgetting that the spreadsheet is the application whose usability and flexibility drove the adoption of the PC (and that your corporate developers probably aren't as good as the people at Microsoft that wrote Excel).

Wednesday, December 21, 2005

Bird's Eye Article Popularity

Over on All Points Blog, they consider why a NY Times article on Google Earth was the most emailed on the site for a couple of days,

I think the reason is very simple- people have been unaware of the existence of high quality commercial satellite imagery and aerial photography. The only thing Google can be accused of is lowering the price, making it easier to use, and publicizing it to the point where uninformed people in positions of power can begin to make themselves look foolish in the press. The headline on the article, "Governments Tremble at Google's Bird's-Eye View" is an alarmist overstatement (given that there was no evidence of trembling presented) that colors the perception of the reader, making something out of very little.

It reminds me of the situations that occured when various governmental organizations began putting public records online. A lot of people were uncomfortable with what was considered public record (how much they paid for their house, how much money they gave to political candidates, etc.) and the fact that you could click to it from the comfort of your home instead of waiting in line at some county office somehow made it newsworthy.

Tuesday, December 20, 2005

Google Homepage Widgets

Google has provided a little interface- compare to JSR-168, for adding sections to their homepage. I read the document and added a little one to run the mobile version of Backpack in about 3 minutes. Obviously, there's a lot more you can do with this- particularly the location aspect.

<?xml version="1.0" encoding="UTF-8"?>
<ModulePrefs title="Backpack" />
<Content type="url" href=""></Content>

Monday, December 19, 2005

no more DOCTYPE...

Drop the: "Back when we cooked up XML in 1996-97, there were good reasons to have that ugly upper-case gibberish at the top of your XML documents. That was almost ten years ago; now it’s time to do away with it, and also time to have a spec for Doctype-free XML."

Tim Bray is ready to drop the doctype. I am too. I am not overly fond of discussing the foibles of my colleagues, present or former, preferring to discuss topics in the abstract. However, a particularly heinous form of idiocy that I was exposed to in a previous consulting engagement was related to this. These folks were operating on a network that was not connected to the internet. They were concerned that all of these doctype declarations in XML were referring to things like So, they wanted to do the logical thing and create websites on their internal network that resolved to those addresses and host the DTDs there. You know, so they could download the DTDs and parse the files. I think a similar group at that organization expressed a great interest in starting a project to provide a buzzword-compliant web service to actually perform validations of XML against Schemas and DTDs. Which would of course have been accompanied by an enterprise policy that forbade anyone else from validating XML....

I really think anyone writing a parsing application needs to make sure that they don't put in any dependencies on actually reading the DTD. I always try to parse XML using XPath in a relatively fault tolerant way. I honestly think that one of the reasons for the ascendancy of Internet Explorer was that they went out of their way to try to display as much as they could of any old hacked up HTML that is out there. This to me is the best part of Tim's post->
"’s usually a bad idea for a document to express an opinion as to what its own schema is. Most useful languages have more than one schema, and it’s the absolute right of someone receiving a document to decide whether it meets their definition of “valid” before they use it, so they’re going to make their own decisions as to which schema (if any) is appropriate."

I reserve that right.

Google Earth book

Okay, so there is a book coming on Google Earth and Maps, Hacking Maps and Earth, which is a 500 pager from Wiley in the cheesy looking ExtremeTech series.

Picked this up from Squidoo somehow...

Servlets and Earth

More of a tracking link for me than anything else, but here is a decent article in Java World on writing servlets to interact with Google Earth, bi-directionally.

Sunday, December 18, 2005

Ruby updates

Even though I should probably be coding, or doing the books, or something else useful, Andrew Glover's basically hype-free Ruby off the Rails (an good intro for Java developers) is up on IBM's developerWorks.

There's also a new Manning book, Ruby for Rails coming out in April that focuses on learning Ruby as you build with Rails.

Finally, this isn't anything new, but the Ruby Scripts for SketchUp page is full of cool stuff, but I am still waiting for them to release some things related to their Google Earth integration. You can find some references in their forums. If you have seen those really cool 3D models of buildings that people have been throwing together, you may not realize that building models is pretty easy compared to other 3D tools.

I think if the decision had been made this year, ESRI might have chosen Ruby over Python for ArcGIS scripting. As it is, I am glad they have kept a simple language in there, even if it isn't Avenue...

Tuesday, December 13, 2005

Rails 1.0: Party like it's one oh oh!

Rails 1.0: Party like it's one oh oh!: "15 months after the first public release, Rails has arrived at the big 1.0."

Getting to a 1.0 release is really going to make this easier to use in a variety of contexts. Ruby and Rails have really brought a sea change in my way of thinking about the best way to develop software. I am not 100% happy with it, as it seems to be a little too "database driven", but there are a lot tricks in there to make it less so. I think that is one thing that really separates it from things like Oracle's HTML DB. HTML DB is great for generating database driven web applications, until you want to do something outside of the framework, then you are alone in a cold dark place with nothing but burning pl/sql code to keep you warm.

There's something nice about having code generation vs. a pure wizardry approach that leaves you nothing to modify. The downside is, of course, that your changes are overwritten if you re-gen. A beauty of Rails is that if you add a field to the database, it is accessible in the model, but it still must be added to the user interface. One mode of development is to start by modifying the templates for code generation such that one can always add fields and regenerate the UIs, at least. I haven't gotten that deep into Rails yet, but that's the direction I am going.

One of the things about Rails that really surprised me was that the scaffolding generates a web service to go along with the web pages for a particular domain object. I think this is a really interesting feature that will also probably be assimilated by database companies, if it already hasn't been.

Saturday, December 10, 2005

How XML Killed Java (A Contrarian Perspective)

Required reading...

How XML Killed Java (A Contrarian Perspective): "In the early 21st century, computer programmers often used statically typed languages, especially Java. While these languages were suitable for small-scale projects, they were not as well suited for enterprise class systems, where flexibility and adaptability were (and are) primary concerns."

The basic premise is that by using XML for integration Java has opened itself up to any other language being able to read that XML. And by using XML for configuration, Java has become dependent on reflection, which removes many of the benefits of statically typed languages.

As someone who has to plead guilty to creating flexible systems by using external configuration files- there is a limit to that approach. I actually prefer to keep the configuration in the database, as opposed to XML, but the net effect is the same. If you are making your system truly configurable, using a dynamically typed language is one of the easiest ways to enable that.

Yahoo! Buys, does lose value?

Yahoo! Buys, it will be interesting to see how quickly it gets connected to the other Yahoo properties.

In particular, I think there is a way is used to store placemark equivalents. I like the ability in to just right click on the map and have that create a point. Using to manage those with Yahoo Maps would be cool...

I think could really lose value if they don't remain an open application thing. I think Yahoo! basically did the right thing with Flickr, even if there was some whining about the change to using the Yahoo ID system, there's a lot to be said about common identity as the basis for integration. I also like how Yahoo opened up the Maps geocoding API, which could not have been cheap to do, but is the right thing to do.

I expect to see the same integration and consolidation thing happening for, which potentially makes it a lot more useful, or could mean people just stop using it. There is some value to independence that is being lost, but hopefully the integration gains are greater. I think of it as a corporate mash-up: Yahoo buys so that they can do official mash-ups with all of their assets. You just have to hope they don't do anything to disable all of the unofficial things that already exist.

Friday, December 09, 2005

A (very mild) cure for the common inbox

A cure for the common inbox: Posted by Jared Jacobs, Gmail Engineer

Right place- wrong thing. It be much niftier to integrate Google Reader. I see this as something that is more for people who still don't really get the whole subscription concept. I am not one of these people who wants rss feeds in my inbox (unless they are the search alerts associated with ME personally), but I would like to see a little integration.

Google could now have four separate lists of RSS feeds for me associated with the personalized homepage, the afforemention Reader, Google Desktop 2, and now in Gmail. Only one of these imports OPML...if I worked at Google my 20% time would be spent 100% on at least loosely integrating all of the stuff they already have.

Thursday, December 08, 2005

The Wrong Tale: The GIS Long Tail

So, I was reading the new Squidoo lens on the Long Tail, and I realized it's becoming one of those things that can mean whatever you want. Something bothered me when I saw this thing a couple of months ago from Dave Bouwman.

The first thing is that the long tail isn't that long, relative to the short tail. Or, rather, the area under the tail is pretty small. I wonder what would happen if we had actual numbers on the y-axis: does anyone know how many users there are of Mapquest, Yahoo Maps, Google Maps, Windows Local Live/Virtual Earth, Google Earth etc. compared to the users of specialized GIS tools? It's probably a pretty high ratio. This makes the long tail a lot shorter, and the slope a lot steeper.

One reason that the Long Tail makes a lot sense for things like books is that there are millions of books to choose from. But it's not the guy that sells one book out at the far end of the tail that gets rich, it's Amazon with a virtual warehouse that sells the whole long tail. If users paid for their GIS software per use, the model might make some kind of economic sense. The people that use GIS alot, want some complex GIS features. The people that are looking at pretty pictures and want to find the shortest route to Grandma's house (it's over the river and through the 'hoods) don't need it, in fact, they don't need to pay at all.

The real question is at what level people will start paying for features. There is a point somewhere between Google Earth Pro and ArcInfo where people really do have a choice in terms of what to buy. The biggest change that has developed in the past two years is that the feature list of the free stuff keeps creeping upwards, and taking some of the left side of the tail away from the people that sell things. When you have services with APIs and lots of free data, that changes the game. It grows the whole market, so there is a lot more demand for data, data that has to be created with the advanced tools.

Anyway, I'll draw up a new tail tomorrow and we'll see how it looks.

Earned Value Management

EVM is a messed up concept. I estimate the design will take 20 weeks. It takes 10 weeks. I earned 20 weeks of value, yea!!! Except there's no value to the customer. Don't give intrinsic value to time- give value to the actual value delivered to the customer.

Of course, working for the government, they can demand that you give value to the non-real tasks. I tried to read the document from the CIO Council, searching for any guidance that the tasks to which value is assigned are tasks that have direct value to the customer, not tasks like "create test plan".

In IT projects, value only comes from value delivered to customers. Putting meetings on the schedule and "earning value" by getting to the end just doesn't make sense.

Letting Go and theTest Drive

This is a funny little post about "the fall from scaffolding". I had never really imagined that people would try to completely depend on the scaffolding and not actually stick any of the back end code in there, but I guess it's more than possible, it's happening.

I think the comment by the Python guy on Django is a little sad..."Rails just gives you scaffolding, Django gives you the whole house!
" He's taking the angle that the author is just now discovering that there's more to Rails (and Ruby) and using that to imply that there is nothing else there, and some how more in Django. Sick rhetoric- why does everything have to be such a competition. I think people should have known for a long time that it's not comparing feature lists that makes people choose one technology over another. If it was, you'd pick out your car strictly from the spec sheet without looking at it or taking a test drive.

The test drive that comes with Rails is really really good. The acceleration (in terms of how long it takes to get running) and miles per gallon (in terms of features delivered per hour) are great too, but it's really about the feeling you get that makes it different.

Remember Virtual Earth? Forget Virtual Earth....

In a move that seems really really too similar to the Google Maps to Google Local transition, we now have Windows Live Local.

I think it is much clearer that this is a competitor with Google Local than Google Earth, even with the 45 degree angle shots that I clipped here. I also think it's interesting that they are calling this Windows Live versus Microsoft Live. I think Windows is a far better brand than Microsoft. The Microsoft name just has far too much baggage associated with it in too many contexts, whereas Windows and Office are really seen in a much more positive light. I'd be interested to see some numbers behind that.

Google Earth Book

Is anyone out there working on a Google Earth book? O'Reilly?

Refactoring Ruby

Refactoring and Code Completion- two things about Eclipse that are very hard to give up when typing in Ruby. Jon Tirsen's post sums up the challenges in Ruby pretty well, although there are some innovative approaches for doing things like a rename, if you have a fully automated test suite that will throw deprecation warnings.

It's not like Java or (C#) is completely immune to these kinds of things. Once you start writing framework style code (like an O/R mapper or something with great gobs of XML splattered about) and using reflection and the Class class all of the time, a lot of the type safety disappears. In most cases, a class cast exception is no better than what would happen in Ruby. The concept of method_missing is also a neat way to deal with what happens when duck typing fails.

In any case, the ascent of dynamically type languages continues. Python, which appeared to be the heir to Perl, is rolling with some well made new web frameworks. Ruby is selling more books though, according to Tim O'Reilly. The debate Ruby vs. Python really doesn't matter toooo much, although I suspect that the Ruby will end up in more enterprise locations, once people like Justin and Stu get the Enterprise kinks worked out.

Anyway, I know code completion and refactoring make me a lot more productive. It is an open question whether the other gains of Ruby/Rails make up for that loss.

Monday, December 05, 2005

Google Earth enterprise consultant

I am seeking resumes from geniuses who want to do consulting on enterprise installations of Google Earth in the Washington, DC and Baltimore, MD metro areas. US citizenship required. Resumes and cover letters to

Sunday, December 04, 2005

Slashdot for GIS?

Well, there aren't many discussions yet, but SlashGISRS is using the same website engine. Where is the best discussion forum for GIS in the general perspective? I tend to spend time on the ESRI Developer Network (despite it's limited Java and Avenue coverage) or the Google Earth "BBS", but neither of those is really a general purpose site.

What makes Slashdot Slashdot is the community. There's enough people posting stories and commenting on them that it actually ends up getting interesting information fast. So, while using the same software is great, SlashGISRS (why the rs?) needs commenters and submitters to be worth going to. Aggregation without editors is the other approach, and there may be some smarts that can be put in there to keep the most interesting and recent stories up there, but that's not as easy as it sounds.

Friday, December 02, 2005

ArcGIS Explorer...Still not done

James says:

To be able to take ArcGIS Server, ArcIMS, WMS, ArcWeb Services and other types of GIS datasets and display them all in one program really speaks volumes of what ESRI is trying to accomplish here. ArcGIS Explorer seems to be the product that Google Earth should have been.

It seems really snide to say "should have been". Google Earth isn't just a client- they're serving up an unprecedent quantity of imagery, elevation, and vector data at amazing speeds to a huge number of users. That really changed the game for all of the people that don't have ArcGIS Server, ArcIMS, WMS, etc services that cover whole world available to them. GIS isn't much fun without good data, and Google Earth has exposed a lot of people to data that they didn't even know existed.

By James's definition of "should have been", Google Earth should have been the viewer for ESRI data formats...maybe if Keyhole had been looking to get bought by someone else. In reality, the server side of Google Earth changed the game in terms of scaling 3D imagery services and the client changed the way most people who used it thought about GIS user interfaces (apparently to include ESRI). Hacking across data formats is a nice side business for system integrators, not really the primary focus for most innovative product companies [reference ESRI support for OGC standards].

Here's one big thing missing from ArcGIS Explorer so far- the ability to create data. A community sprung up around Keyhole and then Google Earth in large part due to the ease of creating data and sharing with it others. Now, you probably wouldn't use this kind of tool to produce datasets that you would sell, but it handles the long tail of applications for the occaisonal GIS user.