I put my InfoTec 2007 presentations online last night. If you don’t want to hear about how much fun I had giving them, here is the link.

My first talk was a 4 hour “Introduction to Ruby on Rails”. It had a decent turnout, and was a lot of fun to give. Thanks to a IM chat with Harish the night before the talk, I gave the best line I’ve given so far in a talk (IMHO): “So, what type of web application would you like to build today?”

My second talk was “Agile Java Web Frameworks”. There were twice as many people in this talk that had signed up before the conference started, though slightly fewer than in my rails talk. A slightly disjointed talk, I hit upon some of the more interesting web frameworks in the java world: Struts2, Spring MVC/WebFlow, Click, Rife, and then the dynamic contenders: Grails, Rails, and Lift.

Click was an interesting experience, as I had only learned about it the night before from Stephen Haberman. It looks pretty promising.

We only had enough time to quickly dive into one of the frameworks, and the audience chose Grails. So we delved into the bowels of GroovyQuiz and I showed them how it works.

Overall I had a lot of fun, and am looking forward to next years InfoTec.

I’ve got a few talks coming up in the next couple months:

March:

Domain Specific Languages - I’ll be talking to the Omaha Dynamic Language Users Group on March 6th.    I will be focusing on the Groovy language, but may slip in some Ruby and Lisp.

Basic Spring -  This talk will be part of the Omaha Java Users Group March 20th meeting.  It will be a “nothing but Spring” meeting.   Nick Larson will be talking about Spring MVC, whil I will focus on the fundamentals.

April:

This year I will be presenting at Infotec, the local Omaha conference for Information Technologies, put together by the local AITP association.  I have one session and one tutorial:

Agile Java Web Frameworks - sort of an omnibus of the latest frameworks, and of course what a “agile web framework” is.

Introduction to Ruby on Rails - this will be a four, yes FOUR, hour tutorial  using Ruby on Rails.  I am so excited to be doing this!  We will be building an application from scratch, covering most of the features in Rails.
Should be a fun couple of months!

I got a comment on my James McGovern::Thought Leadershit blog post earlier today, ostensibly from James himself, that I feel compelled to respond to:

Don’t have such a low threshold for measuring success. Success is Java, .NET, XML, Web Services, SOA, etc. Ruby has potential and an upward trajectory but can’t yet be called successful.

In terms of getting large enterprises whose primary business model isn’t technology involved in Ruby benefits Ruby by the simple fact that this demographic represents 90% (The masses) of all IT folks. More importantly, this same demographic has 590% more capital than the 10% that Ruby currently has. Capital allows folks to accelerate the growth, features and adoption of all the hard work the Ruby community put into it.

You should noodle this thought and even if you agree slightly, you should amplify it in your next blog entry…

I slightly agree with the above, mostly with the demographics and the problems those demographics cause. Not sure about the math…. However, what I really want to address is not the demographics… those are a causal by-product the misunderstanding evident in these statements:

Don’t have such a low threshold for measuring success. Success is Java, .NET, XML, Web Services, SOA, etc. Ruby has potential and an upward trajectory but can’t yet be called successful.

My definition of success in the enterprise has absolutely nothing to do with the technology used. Technology is nothing more than an enabler for the solutions set forth by the organization to accomplish its goals. Java, .Net, XML, Web Services, SOA, and yes, even Ruby are all just tools (and fads) that we have at our disposal at this point in time that help accomplish these goals. They are not the success factors themselves.

I am much more concerned with providing value and efficiencies to the organization. Solving problems matters more then the technology used.

What I value more than the programming language

1. Right sized solutions to the right problems. It is so easy to build the wrong sized solution, buts worse when its not even the right problem.
2. Simplicity Simplicity is a mindset. But lets not mistake it for “Do the simplest thing that could possibly work.” Do the simplest thing that can be maintained for 10 years.
3. Maintainability I am sick and tired of hearing about brand spanking new projects using Struts, because thats what people know. But, on the other hand, if you can see struts still being used (and supported) at the EOL for your project, by all means. Typically I prefer to weigh my decisions on what is the latest, with the most likelyhood to succeed. Failing that (which most frameworks do), I want to know how bad (unreadable) the frameworks code is… good sign of how easy it will be to fix problems when you are on your own.
4. Flexibility I want flexibility in my language, my IDE, my organization, and not least of which: my system’s architecture.
5. Structure But, you cannot be all flexibility. Think of your app as a piece of Bamboo. Simple, elegant, solid, and flexible in the wind.
6. Understanding The team must be able to read my code. Everyone (devs, admins, users, everyone) must understand the vision of the app. Without this, you have people doing things that will invariably be incongruent with the vision and goals of the team and organization.

In essence, I want everyone to think about what they are doing, and try to come up with the simplest, most maintainable system they can. I think that that is difficult in every language, and in fact I think it transcends language. This is the Silver Bullet problem (there isn’t one). So, all I can do is try to design the system the best I can, and then use a language that gives me the best Thought to Expression ratio for my solution.

Thought to Expression Ratio

I’ve mentioned this a couple of times before. Thought to Expression Ratio is a very subjective measure of how much expression is needed to convey a thought, with a ratio of 1:1 being perfect expression of a thought and 1:0 being the no expression capable of the thought.

As an example, remember the old saying “A picture is worth a thousand words”. Now, if only we had a programming language that could do that. Well, we do in a way. This is were Domain Specific Languages come into play. We can bring the programming system closer to the thoughts of the organization, and in so doing, raise the Thought to Expression ratio. And right now, there are few languages that give me the flexibility to define a DSL easily, with Ruby being the one with the most interest pointed in its direction.

Durability

By day I am a Enterprise Java developer/architect. By night I play with Ruby, and Smalltalk, and other languages that intrigue me. Why? Because Java will not be around forever. Java is indeed the next COBOL. In fact, so is Ruby. And C++, and VB, and .Net. and ….

I am a proponent of Ruby, though not as much as one might think given some of my previous posts. I value the flexibility that Ruby gives me, but I also hate the sheer power with which Ruby allows a person to write the most horrendously ugly code this side of perl. Indeed, this is what could very well be the downfall of Ruby.

Success

In the end, success on an Enterprise application can only be determined by the organization and teams involved. This is a hard problem, especially the more stakeholders involved in the definition of success. And, to me, that has nothing to do with the languages involved.

Which do you think is better?

this:

or this:

I would say “It depends, what is in the Job class?”

Heh, ok so its an interface. What is the implementation?

Which gives you this client code:

But also allows for the implementation of closures:

Ok, so there are two different interfaces, both ostensibly providing a mechanism to schedule something to run at a later date/time. Which is better? Lets look at each in turn.

The first one is using primatives to represent the data needed for the scheduling contract, in this case a Long for a “domainId” and a Date for the “scheduledDate” to run at. Each method specifies what type of job needs to be scheduled (”scheduleDelivery”, “scheduleReplay”, etc). On the immediate surface, there is nothing that stands out as a major issue. Now, lets think about how this will need to be maintained:

• Lets say you need to change the domainId from a Long to a “DomainKey” object. This is a huge change, of which the Scheduler interface is going to see only minor changes from, but will cause rippling effects throughout both the client and the implementation code.
• What if you want to allow a different type of job to be scheduled? You would need to add a new interface method and a new implementation.
• The interface leaves you (or at least me) with the impression that I would need to keep the interface pretty consistent to maintain clarity. That means that anytime I wanted to schedule some new thing, I would feel compelled to propagate the interface as it is currently implemented. If I needed to do anything that seemed inconsistent I would hesitate, and probably end up with an implementation different than I initially wanted.

The second one uses an Interface to provide the job implementation. This helps to abstract the Scheduler from the implementation details of the job. By not tying into the implementation details, it keeps it’s Single Responsibility clear: to run the given job at the given time.

The only “problems” that this implementation has is that it creates extra classes, and has the ability to be “abused” by using anonymous inner classes. Notice the use of quotations in the prior sentence to indicate the facetiousness of this argument. Surprisingly, I’ve heard this argument so many times, both directly and indirectly. In this case the argument is groundless, as there is very little in the way of extra classes; just an interface and a class per implementation. This is no big deal, and is completely outweighed by the simplicity of the design.

Another argument that I have heard with this type of discussion is that the only data needed is the primitives, so why not just send that? Well, there are a number of reasons not to do that. The first is that the primitives do not represent your domain… they are an abstraction of your domain, which is an abstraction itself. I generally prefer to keep my sanity.

The one argument I could see holding water against the second interface is if it is desirable to have a domain centered interface for scheduling these jobs. But, in this case, the solution is not to get rid of the current Scheduler interface, but to add a Domain Specific Scheduler interface:

Notice that even this new interface stays away from the primitive Long domainId field from the first interface. This reduces the problems from the first interface:

• Now, a change to the key would not require an interface change, and depending on the implementation, it may not need to change either. The client code is obviously not affected.
• It is clearer what you are doing with the data. Even if the underlying implementation does the exact same thing, now you are not wondering why only the id field is needed.

The final two interfaces are examples of porous interface design. They allow for wider ranges of data to go through, but without the worry of incorrect data, or providing too much data (Why would you allow Object?). They also make the system more extensible without changing any of the existing code. By keeping things centered around the domain, and the Single Responsibility Principle in mind, you end up with a much simpler, more maintainable design.

I was just perusing my copy of Java Design: Building Better Apps and Applets by Peter Coad and Mark Mayfield and noticed a good set of rules to follow when thinking about using inheritance:

1. “Is a special kind of”, not “is a role played by a”
2. Never needs to transmute to be an object in some other class
3. Extends rather than overrides or nullifies superclass
4. Does not subclass what is merely a utility class (useful functionality you would like to reuse)
5. Within PD(Problem Domain): expresses special kinds of roles, transactions, or devices

Update: I probably should mention that you should fulfill all or at least most of these to consider inheritance. Otherwise use composition or re-analyze your design.