Google Reader

News Readers have been around for several years and like many other people I have my own collection of feeds to which I subscribe. The only problem was synchronization from computer to computer. It was fairly common for me to read through a list of published articles at work and then come home to do it all over again. It wasn't as time consuming the second time because I could just skip over the ones I'd already read but it was still annoying.

So finally, Google's listened to its users and upgraded its previously weak Google Reader and added the features I needed to use it full time. It's amazing to me what they can accomplish with a browser application. It's making me rethink what can be done with a web app.

Digg, Ruby, & Cocoa

I recently discovered that Digg allows you to simplify story submission for readers by placing a "digg this" link on your website. That sounded like a reasonable thing to do for my blog entries and after reading Guy Kawasaki's blog about it, I decided to give it a whirl. It wasn't long before I found myself wanting to automate the generation of the anchor tag. So I immediately ran off to my Ruby editor and generated a little script:

require "erb"
include ERB::Util

title, description, url, topic = ARGV[0], ARGV[1], ARGV[2], ARGV[3]
puts <<EOS
<a href="http://adigg.com/submit?phase=2
&url=#{url_encode(url)}
&title=#{url_encode(title)}
&bodytext=#{url_encode(description)}
&topic=#{url_encode(topic)}">
<img src="http://digg.com/img/badges/91x17-digg-button.gif"
width="91" height="17" alt="Digg!" border="0" />
</a>
EOS

That worked reasonably well, but then I started thinking back to all the stuff I learned about Mac OS X software development with Cocoa and decided that I should really wrap up my cute little Ruby script with a Cocoa GUI!

So I immediately opened XCode, generated a Cocoa application, and started messing around with Interface Builder. Here's what I came up with:



From Interface Builder I stubbed out my controller class (MVC after all!) and wired the button to an action method. I also decided to use Cocoa Bindings to wire the text fields to NSString properties in my model without any code. Now since my model only needed to expose four string properties (one for each field in my window) I chose to cheat a bit and just added the four properties to the controller.

Since Objective-C doesn't have automatic memory management, you typically manage the memory allocation and deallocation in the accessors. Fortunately Accessorizor came to my rescue and generated that code for me. So the only thing left for me to code was to pass my four text values to my Ruby script. A simple Google search resulted in this page on Cocoa Dev Central that describes how to call the 'ls' unix command from Cocoa. I quickly adapted it for calling my Ruby script. The one change I made was that I added my Ruby script to my XCode project as a resource so that it would be included in the application bundle at build time. So I added this line for finding it:

NSString *path = [[NSBundle mainBundle] pathForResource:@"digg" ofType:@"rb"];

Finally I decided it would be nice to just put the generated anchor tag on the clipboard when I click on the "Digg It" button. So I perused my "Cocoa Programming For Mac OS X" book and added these three lines:

NSPasteboard *pb = [NSPasteboard generalPasteboard];
[pb declareTypes:[NSArray arrayWithObject:NSStringPboardType] owner:self];
[pb setString:string forType:NSStringPboardType];

and voila:

Rethinking the car

Here are two extraordinary cars that I discovered through the magic of the internet. One is the Tesla Roadster. The Tesla is fascinating because it redefines what an electric car can be. How does 0 to 60mph in about 4 seconds and 135mpg equivalent all wrapped up in a gorgeous sports car package sound? Nikola Tesla would be proud.

Then you have the Ariel Atom. A stripped down minimal sports car with a phenomenal power to weight ratio but no windshield. You have to see this one to believe it. It's amazing.

I'll take one of each. ;-)

Ruby User Group Meeting

Last night I attended my first Ruby user group meeting. I've been a member of a lot of user groups and so my expectations were (perhaps unreasonably) high. My initial impressions weren't that great and I left the meeting unsure whether or not I'd return the following month.

But then I started to think about it:

1. Here were a bunch of geeks (me included) getting together to talk about a nascent technology in a city largely dominated by Java and .NET. The fact that these people cared enough about fostering the growth of the language and framework to set all this up is commendable.
   
2. The presentation was actually quite good. I came out of there knowing something about Capistrano that I didn't know before I went in there. It inspired me enough to go looking at the Capistrano and Mongrel websites.
   
3. The group was roughly 20-25 people. Not bad when you consider very few of us are actually getting paid for writing Ruby.
   
4. There were door prizes (a couple books from O'Reilly and no, I didn't win). The people in charge are trying to entice people to come and learn and share.

So I reconsidered. I'll probably continue to attend and hope to see the technology and user group flourish. Only with growth (and perhaps some corporate sponsorship) can we eliminate poor first impressions like the one I had. In the interim, I'll continue to learn, make contacts, and maybe if I learn enough I'll be able to give a presentation one day too.

Set phasers to stun...

The last couple days have been a bit painful for me as I've endured exposure to the white hot burning effects of crappy UI design. My crap-block was only at an SPF level of 20 and I really should have just got the all-over environmental suit and properly protected myself.

Seriously, I don't understand why so many people undervalue good user interface design. At the very least, people should expect some consistency. Love 'em or hate 'em Apple set some pretty good keyboard conventions with:

Command-S == Save
Command-A == Select All
Command-X == Cut
Command-C == Copy
etc.

Even Microsoft's Windows 95 decided to copy Apple's Command key combinations with the likes of CTRL-S and CTRL-A (they even figured out CTRL-X, CTRL-C, CTRL-V for Cut, Copy, & Paste instead of that abomination that was Shift-Del, Ctrl-Ins, Shift-Ins in Windows 3.1).

Apple's human interface design was also heavily copied. For example, potentially destructive user actions were met with a nice little dialog box asking the user to confirm their action.

So imagine my surprise and frustration today when I pressed Ctrl-S to save my work and this ridiculous application promptly threw away my data and selected (as in SQL select) the data from the database again! What I don't understand is that a committee of people reviewed a number of these vertical market candidate applications and chose this one as the best. Good lord I can only imagine what the others looked like!

JRuby on Rails

It was only a week ago I was waxing philosophically about Enterprise Software and mentioned that Ruby was in the early stages of running on the JVM and .NET CLR and just today Sun announced that they're hiring the JRuby developers to continue their work full time at Sun. Wow! That's big news. Maybe mainstream Ruby on Rails development won't be far behind... Ahh the winds of change.

P.S. I tried JRuby a few weeks ago after Rails went to 1.1.6. The Gem system actually worked to fetch rails and I was able to create a skeleton rails app and start webbrick. It didn't work much more than that (which was still very impressive) and it was definitely slow but that proof of concept gives my high hopes for this project.

User Interface Development

Given the same amount of time, who is more productive... a small team of multi-talented developers? or a large team of specialists? Since I think the answer lies with the multi-talented crew, I took stock of my own skills and decided it was time again to strengthen my ability to create web user interfaces.

So here was my plan: design a web page or two in a graphics tool of some sort and then translate it to an xhtml/css implementation that I can then make dynamic at some later date with something like rails.

I started by perusing the css zen garden for inspiration. Then while keeping the goal of simplicity and efficiency in the back of my mind, I opened OmniGraffle and threw together some nice curves, a healthy amount of translucency, a decent colour palette and quickly had a design.

I then moved onto creating the browser implementation. It was simple enough to create the bare-bones xhtml to represent he text of my fictitious website. But then I ran into my biggest skill deficit, a weak understanding of css. I've read books and coded a lot of this stuff in the past, I just didn't have the big picture. I couldn't make the html tags do what I wanted. I even got so desperate that I almost resorted to the the evil "table" tag. Fortunately I stumbled across Mike Hall's BrainJar website.

He has some great descriptions (with diagrams!) of css positioning, the box model, selectors, etc. After absorbing some of that good information I was soon off and running again.

But no sooner had I started coding than I found myself in the nasty world of css standard unconformity. You see I wanted to take advantage of some of the css3 enhancements I was reading about and unfortunately they weren't working.

In the past I've always relied on Firefox to be the standards compliant browser, but I discovered that the nightly build of Safari/webkit has support for just the properties I needed (i.e., border-radius and multiple background-image properties). For the Firefox fans you probably know that it also supports -moz-border-radius, but Safari's anti-aliased rendering without artifacts is definitely superior.

So a couple "float:right;" properties here, a "-webkit-border-radius:15px;" there and I pretty much got what I wanted. I did discover however that content and style are not as cleanly separated as a I thought they would be. I still ended up nesting a couple div tags and placing content in a certain order so that the float property would do what I wanted but regardless I'm pretty happy with the end result. Next will be dealing with the various browser differences. And I bet Windows IE will be the big pain... PNG support sucks, CSS support is spotty, I'll let you know...

What is Enterprise Software?

What is "enterprise software"? And the follow up question what is an "enterprise software developer"?

The reason I ask is that I've been thinking about the Java vs Rails question again and the reaction I get from my fellow Java developers when I talk about Ruby and Rails. Generally, they turn their noses up. Ruby doesn't have the breadth they say, it's immature, it's slow, it doesn't scale, it's not an "enterprise" solution. So what exactly are they talking about?

"Breadth": Java has it and Ruby doesn't. There I said it. And quite frankly I agree with it. If I need some oddball service in my app, I can probably find an open source Java framework to help me out. I may not be so lucky in Ruby. But on the other hand do I care? Not really. If I'm building a web app (which describes nearly every single Java project I've worked on) then I don't really give a hoot about most of the stuff that's in Java. As a matter of fact Ruby's ability to create domain specific languages (DSLs) is the power that Rails exploits in its framework, allowing me to express the complexities of my projects very succinctly. It's not about writing gobs of code it's about efficiently expressing a maintainable solution to a problem in as few lines of code as possible. And this is where Ruby and Rails succeeds.

"Ruby/Rails is immature/slow": While it's true that Ruby's been around a long time it certainly hasn't had the commercial success that Java enjoyed and therefore it hasn't received the research dollars to improve it's language runtime. However Rails is getting a lot of attention and by extension so is Ruby. Ruby is in the early stages of running within the .NET CLR and Java Virtual Machine and by the sounds of things Ruby 2.0 has some virtual machine tricks of its own. So at that point at least the discussion of performance can be evenly leveled at all the virtual machines of the world.

Immaturity has also been expressed to me in terms of a lack of an IDE. While I lament the inability to easily refactor my Ruby code as easily as I refactor my Java code with the assistance of something like Eclipse, I console myself with the knowledge that refactoring tools in the Java world are relatively new too. It wasn't that many years ago that I was doing this the hard way in Java. Personally I think this particular complaint is pretty weak. I think developers who are clutching on to this one are doing themselves a real disservice. If nothing else they are depriving themselves of a fresh perspective to object relational mapping and web development because they don't have all the fancy tools.

"Scalability": Well that's a tough one to tackle because of the differences in strategy between Java and Rails. Java likes distributed shared caching (think EJB). Rails likes a Shared Nothing Architecture (SNA). So which is better? Well both have their successes. But to me, the SNA architecture is simpler to understand, simpler to implement and well-proven by the Googles of the world. Fewer moving parts certainly attracts me. There's less to go wrong.

"Enterprisy": Well I dunno how to address that one at all. Because first of all, I don't know what the term "Enterprise" means. I've developed a lot of applications for a lot of users who believe their apps are critical to the success of their business. So does that mean I've developed "enterprise" applications and as a result am an "enterprise developer". Maybe? So am I qualified to say whether or not Rails is ready for the enterprise? Maybe... maybe not. But in any case I can say that I think the IT shops I work for could definitely benefit from Ruby and Rails. I've seen a lot of crazy Java solutions. They tend to be overly-complicated and inconsistently designed and constructed. There is way to much configuration, way too much thinking about "what-if" and not enough thinking about keeping it DRY. Rails comes with a lot of opinions about how things ought to be done and if you can just accept them and go with the flow, you can be very productive.

But it's funny, the "enterprises" that could benefit the most from this technology are probably the people who will be the last to adopt it. Enterprises are big and difficult to steer. Once they get some momentum in one direction, it's hard to get them off that path. Take for example my latest attempt to move from Java 1.4 to Java 1.5. You wouldn't believe the number of departments and the amount of bureaucracy I have to cut through to try and get this approved. All I want to do is use the latest version of Java that was released two years ago so I can take advantage of it's language features so I can write cleaner, more maintainable code. What are the chances that this particular enterprise will ever use Rails? And they claim they're an agile development shop too. LOL.

Watch that SQL!

Long before I used object relational mapping tools like Hibernate or Toplink in Java or ActiveRecord in Ruby on Rails I used to write a fair amount of SQL (some real nasty queries too!). And in a lot of the shops where I worked it was standard practice to create an explain plan just to make sure that the database could execute the SQL efficiently. If it couldn't, I would dutifully restructure the query, add indexes, or go ask for some DBA help.

But nowadays in this wonderful land of ORMs people just let the framework crank out the queries and never ever look at them. To me, that's just plain wrong. If you're using Hibernate turn on the logging. If you're using Rails just go take a look at the development.log file and go watch what's going on! You may be surprised.

I started a new job a few weeks ago and just wanted to see what Hibernate was doing. And lo and behold, a JSP page was causing 69 queries to run in order to generate a simple list of rows from a table. The main problem was that every lazily instantiated relationship for each object in the collection was being traversed after the initial fetch.

So what could have been done? Well in this case, Hibernate has several options:

1. Hibernate's query language is quite expressive and something like select e from Employee e left outer join fetch e.department d would have caused both objects to be fetched in a single query.
2. The fetch keyword I used in the first example has one limitation (for good reason too). It can only be used to fetch one collection. So take advantage of Hibernate's caching to prefetch related objects instead. Hibernate will associate any newly instantiated objects with objects that already exist in cache. Even if you're not using something like EHCache you still have some caching built into your session so don't discount this tip right away.
   
3. Use a DTO-like object and go old-school and only select the fields you need with something like: select new EmployeeListDTO( e.firstName, e.lastName, d.name) from Employee e left outer join e.department d

Now if you're using ActiveRecord you don't have the double edged sword of a cache so the second option I described above isn't available, but the other two are possibilities:

1. Employee.find :all :include => :department
2. Employee.find_by_sql "select e.first_name, e.last_name, d.name from employees e left outer join departments d on e.department_id = d.id"
   

The second option shows one distinct design difference between Hibernate and ActiveRecord. Hibernate gives you a SQL-like query language but does away with having to specify join constraints because that information is in the mapping metadata. Whereas ActiveRecord says why reinvent SQL and just let's you have at it. Oddly enough I like both approaches...

Finally, be sure to use the ad-hoc query tools at your disposal to try out your queries before you embed them in your app. If you're using Hibernate 2.x then go get a copy of Hibernate Console (part of the Hibernate Tools). It can be a bit of a pain to get it setup but I really appreciate being able to work out the query before running it as part of my app. If you're using Hibernate 3.x and Eclipse then go get the Hibernate Tools plugin. If you're using Ruby on Rails then you already have all the tools you need. Simply drop to the command line, cd to your project directory and then type script/console. Open up a second shell window (if you're running unix) and type tail -f log/development.log from your project directory and you can instantly watch what SQL Rails generates when you execute those find methods.

Now go out there and watch what you're doing for database access! Don't let all that ORM goodness make you lazy.

Should Rails come with a Warning Sticker?

I've been a Java Developer for about 9 years, and maybe my interest is finally waning or maybe the lack of productivity is starting to get to me but maybe, just maybe, something else is has come along that has shown me a better way... I suspect that something is Ruby on Rails.

Now I'm not saying Rails is perfect or that Rails is an appropriate solution for every problem but as I said to someone else last week, it amazes me how many of the things that I've written these past 9 years would be appropriate for Rails.

One of the things that tends to annoy me is that every Java development shop is maddeningly different. They all have a different combination of open source and commercial frameworks. I've dealt with Struts, Hibernate, Spring, JSF, Tomcat, OC4J, Spring, JBoss, Weblogic, TopLink, EJB, JSP, JSTL, DOM4J, JAXB, Swing, Tiles, Facelets, etc, etc. Now while some will say (and yes I'm sure I've used this argument in the past) that the Java community is vibrant and constantly pushing the state of the art, sometimes I wish there wasn't so much choice. Some consistency would be quite nice.

Secondly, why does each shop have to have its own collection of "clever" Java developers who feel they need to endow the poor developers that follow them with some fascinatingly weird framework of their own? Why can't these guys just build a straightforward solution with the frameworks they've chosen? They all seem to feel this overwhelming urge to hide what they're doing behind layers and layers of abstraction, abstraction that usually involves one implementation. For crying out loud if you're going to abstract away Hibernate's API behind your own, you better have a darn good reason and it better not be "just in case".

Rails is a breath of fresh air. David Heinemeir Hannson has said he's very "opinionated" and that may tend to put some people off, but the strength of his character has allowed a single vision to shine through. Rails isn't littered with a pile of abstraction because it's not needed. It's simple, it's straightforward and it's productive. As a Java developer someone should have told me that Rails was so revolutionary. Now when I write Java web applications I'm constantly thinking about how much better it could be with Rails. Is the grass just greener on the other side? Maybe, but either way Rails should have come with a warning sticker. It's addictive.

Rails and Apple together in Leopard

David Heinemeier Hannson notes in his blog that Ruby on Rails will ship with the next major release of the Mac OS, Leopard (a.k.a., Mac OS 10.5). As a Mac user and Rails admirer I have to say that these two seem to go so well together... Not sure how to explain that... It's just that they both have a great aesthetic, and are two of the most elegant software products I've used in years.

Cool Reception

A friend of mine, who works at a Java shop, recently gave a Ruby on Rails presentation and was surprised and dissapointed by the people who didn't come to the presentation. In his blog he discussed some of his theories about why one person in particular didn't show up...

I have a simpler theory, one that was presented by Bruce Tate in the Ruby on Rails Podcast back in March of this year. He said:

You can either look at a programming language as a means or as an end. And if you're looking at a programming language as a means it's just a tool to get a job done and religion just falls out of it. But once a language is entrenched and that language becomes a meal-ticket then the language becomes the end. And when that happens you're gonna get passions stirred up whether you want to or not, because now when you threaten a language you're threatening somebody's ability to feed their family...

I wouldn't present it quite so dramatically as being unable to feed one's family, afterall Java isn't about to be replaced any time soon, but I think his position is probably correct. Java is a meal-ticket for a lot of people. Many have worked their way up to nice lofty "architect" or "senior lead" positions. Most of them through hard work. They know Java and the frameworks and tools that go with it (JSF, Hibernate, Struts, Spring, Eclipse, IntelliJ, Tomcat, JBoss, JUnit, etc). They've made a significant investment and may quite naturally feel threatened by something like Rails whether they realize it or not. It challenges their position and knowledge.

Andy Hunt, one of the authors of "The Pragmatic Programmer" said:

Languages and frameworks come and go, but your habits--your practices--stay with you for your whole career.

Unfortunately, most people don't understand that. They look only at what's directly in front of them and don't check the horizon to see what's coming. Today Java can be a morass of complexity and it's only by looking at things like Rails do we challenge our preconceptions and make our day-to-day Java development positions better.

Keep giving the presentations, continue to push the boundaries. People don't like to be pushed but constant gentle persuasion will eventually leave its mark.

SOA and APP

During a recent job interview they told me that one of their new technical directions is Service Oriented Architecture (SOA). So I'm thinking okay, Web Services probably figures into that somehow... But unfortunatley (or maybe fortunately) the last time I touched any of that stuff (UDDI, WSDL, SOAP) was at least a couple years ago. So I started Googling to get up to speed again...

All the regular Web Services stuff is still out there but I found a couple other articles/blog entries/presentations by Joe Gregorio that are much more profound:

• Implementing the Atom Publishing Protocol
• How to create a REST protocol
• The Atom Publishing Protocol: Publishing Web Content with XML and HTTP
  

In the meantime I also watched a presentation by David Heinemeir Hansson called "Discovering a world of resources" (slides, video) where he describes something obviously influenced by the Atom Publishing Protocol (APP).

My interpretation of all this is that we tend to naively use just the GET and POST methods of the HTTP protocol and tend to be fairly inconsistent and sloppy in how we choose our URIs. These articles suggest that we can more wisely and efficiently use all of HTTP's methods to provide basic CRUD functionality:

CREATE - POST
READ - GET
UPDATE - PUT
DELETE - DELETE

Rather than reinventing the wheel with SOAP and all the WS-* standards we can just keep it simple with HTTP. Sounds pretty smart to me.

MacCallisto

Even with a few weeks off from work I still like to keep up-to-date with what's going on in the Java world. And the biggest news so far has been the release of Eclipse 3.2 and the various other Eclipse based projects. So I downloaded 3.2 and then went on to install these other projects:

• Visual Editor (VE)
• Java EE and Web Tools (WTP)
• Test and Performance Tools (TPTP)
• Reporting Tools(BIRT)
• Data Tools (DTP)

I was happy to see that VE is now supported on Mac OS X. I was able to quickly create a very simple Swing app in just a couple minutes. I can't say too much about stability of the tool at the moment but it worked first time!

Then I moved onto the Data Tools. It was pretty easy to connect to PostgreSQL (my preferred local database) even though PostgreSQL wasn't one of the predefined driver types. I browsed my schema and then quickly learned that you need to create a SQL editor and then connect it to a database before you can issue ad-hoc queries. In the end it's nice to see these tools in Eclipse but the implementation is still pretty weak compared to something like Aqua Data Studio whose code completion features are more comprehensive.

Then because I haven't really messed around with Web Services before I figured I'd take the Eclipse web tools for a spin. Now I know why David Heinemeier Hansson calls the Web Services collection of standards, which usually sports the abbreviation WS-*, as WS-death-star! Yikes! But in the end I was able to use the wizards to create a bottom-up web service from a simple JavaBean method that returned a String and then deploy that web service in Tomcat 5.5 and then use the generated web service client, also deployed in Tomcat, to execute the method and return my String. It sure is a lot of plumbing to do something so simple but maybe for large heterogeneous enterprise IT shops the benefits for integration outweigh the overhead...

So I still have the reporting tools and the test and monitoring tools to look at but so far everything looks good in the latest Eclipse offering. But I must admit I was suffering some nasty Eclipse crashes at first with the rather nebulous "Out of Memory" exception. After a bit of monkeying around I discovered that the following changes/additions to my eclipse.ini file (within the Eclipse bundle on Mac OS X) made everything happy again:

-Xms256M
-Xmx768M
-XX:PermSize=128M

The last one in particular made the biggest difference. Let me know if you discover anything interesting...

Just Say No to Specialization

One of the topics of our standup meeting this morning was the communication problems with the database group. At the eleventh hour they wanted to change the names of tables, columns and constraints. While I suppose there's nothing too much wrong with caring about consistent naming conventions, I question a lot of the specialization that happens in larger IT shops nowadays.

I read this quote on Apple's Pro site:

Where these big shops have tiers and tiers of people focused on something specific and get bogged down by their infrastructures, we can win a huge campaign with just two artists and a Mac.

...and I can't help but see the parallels with IT development. The last few shops I've worked in (with one exception) have had Business Analysts, System Analysts, Technical Architects, Senior Java Developers, Junior Java Developers, Product Managers, Software Project Managers, HTML developers, Art directors, DBAs, QA managers, QA testers, Release Engineers, etc. etc.

As a result, even the simplest project ends up involving at least 10 to 15 people. If you then consider the communication overhead this introduces, there's not much wonder that productivity suffers. The funny thing is that all these shops actually think that they're agile.

Anyway, back to the database group's requests for change. WTF!? I've long since come to the view that the database model and the object model are just two perspectives on the same thing. But in a lot of circumstances I see the DB design and the object model design begin to drastically diverge as the product evolves. And naming conventions tend to be the worst offenders.

Usually a glossary of terms is developed (even informally) as the dev team and the business people talk about the business problem, and usually the object model's class, attribute and method names are changed to better reflect the real world problem space. But for one reason or another, the database is left to decay. And then when the all-knowing database group comes along to make the problem worse and suggests/enforces naming conventions, I just give my head a shake...

For me it's all this skill specialization that is destroying the holistic view of the software systems that we build. Smaller teams of people with a broader set of skills and responsibilities are what we need to get the job done.

That is just so awful...

I was watching a video about Django, a Python powered web framework, when the presenter, Jacob Kaplan-Moss, made the following comment (at around 29:22):

I've actually seen a system, I shit you not, that has every single URL on the site calls a stored procedure in an Oracle database that generates html in the stored procedure and returns it to the web for display. I'm not joking! That is just so awful I can't even start to begin...

That comment took me back a few years where I encountered just such a mess. I was brought into the organization to introduce Java and J2EE but the developers that lived there already had this Oracle solution in place. For reasons that I still don't understand to this day, they couldn't see that this was one incredibly awful idea. In any case, the next time you find yourself looking at some ugly bit of Java or Ruby or whatever, just remember it could be a lot worse!

Billion Dollar Boondoggle

The "Canadian Firearms Program" more widely known as the "Canadian Gun Registry" was a program instituted by the former Liberal government of Canada under Prime Minister Jean Chretian to license and register certain types of firearms across Canada. Bill C-68 was introduced in February 1995 and has been controversial ever since for a number of reasons but undoubtedly the issue that has caught everyone's attention has been the cost of the program, now over $1,000,000,000, and growing.

So leaving the politics behind, I was interested in the technical details behind this program from a software developer's perspective. What exactly did these guys do wrong that would result in such astronomical cost overruns? What technologies did they use and what could be learned from their mistakes?

Well it was surprisingly difficult to find information but finally I came upon a two-year-old article in eWeek titled "Canada Firearms: Armed Robbery". The system was originally comprised of an Oracle 7 database and a PowerBuilder application built by EDS. Given what I know about those technologies, I doubt that the problem was the technology. Instead, it appears that the biggest problem was incorrect initial assumptions and ballooning, ever-changing requirements.

But after eight years of mismanagement what was the solution? That's right! They decided to rebuild the application with a different set of technology and consulting resources (CGI)! Maybe the implementation really was poor, but I suspect some incompetent management types were deftly pointing fingers elsewhere and some unwitting bureaucrat believed them. Ahhh that old story...

DAOs and ORMs

The discussion that this article on the ServerSide generated reminds me of an article I wrote a little while ago. The original poster gets a bit confused about the problem because he assume the use of an ORM means that you need to use the "Open Session In View" pattern. But if you get by that and read some of the comments, you discover that many people (like me) don't believe that the DAO pattern is necessary when using an ORM solution.

A valid concern about ditching DAOs is the coupling that may happen between your domain objects and your persistence mechanism. But if you like ActiveRecord or Rich Domain Models or Annotations or XDoclet then you've already made the choice of productivity over ultimate framework plugability and should just get over it.

But if the coupling is still nagging you and you're concerned about sprinkling framework API calls throughout your code then maybe you want to consider looking at EJB3. Instead of using the vendor's API (e.g., Hibernate, Toplink, etc.) you can reference standard annotations and classes that are free of implementation specifics. At least that way you've provided some hope of switching out implementations.

In the end, question why you're using the DAO pattern and then ask yourself if you've already done something in your code that has violated that pattern. Think about your use of OpenSessionInView filters or the navigation of lazily instantiated collections in your view layer. Maybe DAO and ORM really don't mix...

XML Glue

When I discovered XDoclet I quickly stopped editing my hibernate mapping documents by hand. From the XDoclet website:

XDoclet lets you apply Continuous Integration in component-oriented development. Developers should concentrate their editing work on only one Java source file per component.

This approach has several benefits:

1. You don't have to worry about out dating deployment meta-data whenever you touch the code. The deployment meta-data is continuously integrated.
2. Working with only one file per component gives you a better overview of what you're doing. If your component consists of several files, it's easy to lose track. If you have ever written an Enterprise Java Bean, you know what we mean. A single EJB can typically consists of 7 or more files. With XDoclet you only maintain one of them, and the rest is generated.
3. You dramatically reduce development time, and can concentrate on business logic, while XDoclet generates 85% of the code for you.

But unfortunately I still find myself editing a ridiculous amount of Spring XML by hand. Spring sounds nice in theory but after using it for awhile I don't think there's anything wrong with the factory and singleton patterns. This unholy quest for ultimate flexbility by gluing components together with XML has to stop. Most of the time you simply don't need it.

On Frameworks and Top Management

I couldn't have said it better myself:

Frameworks

Top Management