Ruby on Rails – WOW

Over the last couple of weeks I decided to re-familiarize myself with the Ruby programming language. I was first introduced to it back in 2002-2003 at OOPSLA (or was it the Software Development Conference?) when I took a full day workshop with the Pragmatic Programmers, Dave Thomas and Andy Hunt.

Back then I loved the language, but decided not to focus on it since the support in the form of libraries just weren’t there like they were for Python at the time. I wrote a few programs in Ruby, but left it to the side and focused on Python.

Well, those days are over. When I started with Ruby, I decided to take a look at Ruby on Rails as well. Over the last couple of weeks all of my spare time has been focused on learning the Ruby language and this completely awesome framework, even at the expense of regular podcasts.

First off, I’m absolutely enamoured by the language. So much so that with Rails piled onto it I couldn’t imagine programming in any other language. For quite a while I’ve hated Java and the complexity that it brings to projects. There’s just too much work involved in doing Java development anymore.

Ruby combines complete object orientation with the flexibility of a scripting language. Some of the features it has baked into it, such as iterators and blocks make life so much easier.

Now pile Rails on top of it. Rails is an elegant MVC framework written in the Ruby Language by the folks over at 37 signals. These two things combined make for the perfect programming environment for web applications.

I’m still on the steep end of the learning curve. I’ve got the Programming Ruby : The Pragmatic Programmers’ Guide and Agile Web Development with Rails : A Pragmatic Guide (The Facets of Ruby Series) constantly at my side as I pull my hair out trying to learn all of this stuff.

But the cool thing is, even with my unfamiliarity with the language I’m still productive. If that isn’t the sign of a great development environment, I don’t know what is.

I’m working diligently to become proficient in the language. Rails is a little complex and I’m still struggling to learn all of the conventions. However, I think most of my programming moving forward will be with these tools. Its just a lot easier to spend time thinking about the problems you are trying to solve and being able to express them eloquently rather than struggling with the complexity and code/compile/run process baked into Java development.

What Corporate Projects Should Learn from Open Source


OnLamp had an excellent article yesterday called What Corporate Projects Should Learn from Open Source. The articles pretty long, but well worth the read. While there are obvious differences in the two types of projects (like budgets and deadlines), I still believe that corporations can move closer to the OSS model of development and get major productivity increases.

Build Google and Yahoo Maps Without Coding

I stumbled across MapBuilder as I was browsing the Google Code site today. MapBuilder was referenced as one of the sites featured projects. The application is pretty interesting, allowing you to visually create a map using either the Yahoo Maps or Google Maps API and then to export the source code for inclusion on your web site. There is also an option to host your maps directly on MapBuilder and reference them from your site with a button that links to a list of all of your available maps.

There are quite a few things that are really cool about the site:

  1. Supports both Yahoo! Maps and Google Maps.
  2. No need to learn the details of the mapping API’s – just create your maps and go.
  3. MapBuilder does geo-coding, using the Yahoo! Geocode API’sand while Google Map API’s require lattitude and longitude in order to do anything with them.
  4. MapBuilder does the “driving directions to / from here” for you. No need to create custom code for this functionality.
  5. MapBuilder will also do custom development for you if you want something different from what the basic services provide. I’m assuming there is a fee involved, but I couldn’t find reference to it.
  6. The site facilitates building communities around maps that people create on the site.
  7. Best of all, it allows the “common man” to include mapping capabilities on their web sites without having to know how to code in Javascript and HTML.

MapBuilder is a really good example of new, unintended possibilities that are exposed when web applications are designed as a set of API’s using the web as a development platform rather than the siloed approach that we have used historically. This application was written by a third party not affiliated at all with Google or Yahoo!, but because of the way their applications were written they have the possibility of an audience that they did not originally target by allowing someone to build applications around their base functionality.

One should note that creation of a user account is required in order to use the full functionality of the MapBuilder site. They basically ask you for a username, password, and your email address. Thats it. Registration for either a Google Maps API key or Yahoo! Maps API key is also required if you would like to host your map on your own web site rather than hosting it on MapBuilder directly.

Too Much Object Orientation?

Ed Gibbs has an article entitled Spaghetti OOs Code in which he talks about a conversation he had with his brother about “too many objects” vs. more “meaty” objects and it reminded me of a position I was in once, and hopefully a lesson that makes sense.

I’ve always ahered to the idea to have enough objects to get things done in an understandable way, without having 4000 objects to keep track of in order to get something done. I’ve seen many applications written where there are several layers of indirection that you have to traverse in order to figure out whats going on, as you have objects that perform certain actions on other objects such as rendering its contents as HTML or XML. These would all be great if they worked on a base class of the actual object being rendered, however they work on specific derivitives, requiring a reimplementation of a rendering object for each specialization of the original object.

Here’s an example. I worked at a place once that had a general rule (big red flag here) that each piece of functionality had to be made up of four separate components:

DA (Data Access)
This object was responsible for retrieving data from a database or other data source.

BO (Business Object)
This object was normally a result of retrieving data through the DA object and represented a business object.

BS (Business Service)
This object was responsible for performing services related to the BO.

BA (Business Access Object?)
I know we had something called a BA, but I can’t remember what it was used for (second red flag). However, it was a required component.

These components had no base classes or framework around them (third red flag), they were just required components that had to be used. Now, for some, this doesn’t seem like a big deal, but try writing some simple code that renders a pulldown in HTML off of a database query and then multiply that work by 10 and you’ll see where this becomes problematic. No framework in place, but all objects were required.

When I first came on, I had to write code that rendered a pulldown box in HTML and I wrote something like the following (Editors note: This was written to illustrate a point and most likely will not execute – its been a while since I’ve written Java):

* Yes, this should or could have been an interface. I was a beginning java programmer at the time, coming from C++ - so
* this made much more sense to me at the time!
public abstract class PulldownData {
* Generate a hash table from a query in which the keys are the select values and the values are the descriptions to appear
* in the pulldown
public abstract Hashtable getData();

public class PulldownRenderer {
public String renderData(String name, PulldownData dataObject) {
StringBuffer strHTML = new StringBuffer();
String keyName = null;
String itemDescription = null;

if (dataObject != null) { /* still have arguments whether this is necessary in Java */

for (Enumeration e = dataObject.keys() ; e.hasMoreElements() ; ) {
keyName = e.nextElement();

if (keyName != null) {
itemDescription = dataObject.get(keyName);

strHTML.append("" + itemDescription + "n");


Once this framework was completed, all you had to do to create a new combo box was to derive a new class from the PulldownData object and pass this object to an instance of the PulldownRenderer class and voila! You had a pulldown!

Despite the decrease in actual work involved, I actually spent quite a bit of time arguing why this was a better approach than having four tightly coupled objects that could not be reused to render my combo box with an “architect” that was on staff at the time. I had violated the “general rule” and written something simple and useable.

All of this was written just to illustrate a point. The simpler the better. If you are decomposing things into 500 objects because “thats the way we do it” or “everything else here is written that way”, you are doing it for the wrong reasons. There has to be a reason to decompose things to a level that makes sense for the person coming after you, or the people you are working with. Object orientation has the ability to make your job a hell of a lot easier, but its a two edged sword. It can also make your life extremely difficult if you ignore the KISS principle and abstract for the sake of abstraction.

Aardvark’d: 12 Weeks with Geeks


Joel Spolsky of Joel on Software fame has announced the completion of the movie Aardvark’d: 12 Weeks with Geeks, a documentary chronicling the development of a software product called Aardvark. DVD preorders are being taken now for a ship date of December 1. The trailer is available on the project page and I have to say, it looks really cool from a geeks point of view. I think I’ll be preordering this one.

Coté : Make the Iteration Fit the Deliverable, and Other Thoughts on Becoming Agile

Coté from the DrunkandRetired podcast has written a very good article called Make the Iteration Fit the Deliverable, and Other Thoughts on Becoming Agile.

Key points I took away are:

  • Agile development doesn’t mean planning less; as a matter of fact, it takes more planning
  • Planning should happen as part of the team not apart from it.
  • There is no fixed iteration size. You should plan your iteration size based on what you are doing.
  • Two week iterations require a pipeline of planning in order to work effectively. This pipline is normally not present unless your organization has reached a level of maturity
  • Agile development doesn’t mean throwing away design

In my mind, one of the misconceptions that people have when switching to any methodology is that there are a set of rules and procedures you must follow in order to be “doing the methodology”. I don’t think this is the case. The great thing about agile development is being able to adapt to the situation rather than be “stuck” having to follow a set of steps no matter what.

When I think about this idea, the quote from Bruce Lee about Jeet-Kune-Do, his martial art, always comes to mind:

Absorb what is useful, reject what is useless, and add what is specifically your own.

Bruce Lee was annoyed with traditional martial arts because it had “too much form”. The martial artist was unable to adapt to the unexpected. Rather he was limited by the forms he used while learning. (Before any martial artists start posting comments – this was Bruce Lee’s philosophy – not mine). Lee thought that the martial artist, given a set of tools, should be able to react naturally rather than having to think before responding.

I view development “methodologies” in the same way.

Things are going to happen. We have to be able to respond to them in order to be effective, and not get caught up in “how” we get things done. This to me is the power of the “philosophy” of agile development. It has nothing to do with iteration size or any of the other “guidelines” in the methodology.

Shorter iterations, however, do not mean that we do not design or plan during the process. It doesn’t mean working randomly. It means that we should do what is necessary in order to plan, design, and execute – no more and no less.

I think it would be more useful to explain Agile development as a philosophy in this way rather than a set of “methodologies”. People get caught up in “doing the methodology” rather than executing what they have set out to do. I have seen this time and time again as people try to change the way they do things. Agile development methodologies provide a set of tools, like TDD and the idea of iterations. Its up to you and the needs of the project to decide which tools are appropriate to get the work done.

Anyway, I digress. Coté has obviously set off a whole train of thought in my head this morning with this article. Perhaps it will do the same for you.

Charles Petzold: Does Visual Studio Rot the Mind?

Charles Petzold, author of Programming Windows (the Bible of Windows programming when I was coming up) has written an article called Does Visual Studio Rot the Mind?. In this very well written (and very LONG) article, Charles goes through the history of Windows programming as he sees it and explains how he feels Visual Studio removes a lot of the “real programming” out of Windows development these days.

I too have fond memories of the “old days”. I remember being the only one in my department that could recite all eleven CreateWindow parameters and being the “Windows API” manual for the department. Nowadays, as Charles points out, Intellisense and code generation have given programmers the ability to “opt out” of actually learning the environment that they work in, as the full API is only a keystroke away. The IDE does way too much for people these days.

Damn all this technology. Give me my BRIEF editor or EMACS any day.