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.

So, I am starting up a new project, and wanted to have a more visible indicator of what my Continuous Integration builds were doing. I am sticking with CruiseControl for this project, even though I recently looked at Continuum, and must say that it is really nice. I probably will start using that more and more as time goes on. But there is also a Ruby version of CruiseControl in the works, so one never knows…

Anyway, for this project it is good ol’ CruiseControl. And, I wanted to monitor it. There are plenty of monitors out there, but I was looking for something in particular. I wanted a big visible sign that something went wrong. The CC server, a desktop PC that will also server as first-stage test server and DB, is sitting in the same area as my partner and I. So, we will be able to see the screen when something goes wrong. And it will provide a cool green glow when everything is alright.

I decided to write my own monitor, after seeing that CruiseControl has a Socket interface for publishing statuses.

While digging around in Groovy in Action (a fabulous book, BTW), I noticed that Groovy scripts can run in interactive mode, so one could write something as simple as this:

And one has a simple command line monitor that will just dump the status to the console. Now, this is really no better than doing a:

Which it is rather boring… so I decided to use SwingBuilder.

My first experience with SwingBuilder was for my Groovy DSL talk a few weeks ago… I implemented a pseudo-LOGO interpreter on top of Groovy, using SwingBuilder to build my environment. It was the first time in a LONG time that I enjoyed working with Swing.

Here is the code for the monitor:

The code is fairly straightfoward… open up a ServerSocket listening on a port, waiting for a socket to connect…. when one does, the process method is called and the window’s color is changed to the appropriate color for the status.

Simple, and quick, it didn’t take too long to throw that together, and now I have a tool that can be reused for any other time I use CruiseControl.

Here are the results:

Success!

Failure

Fixed!

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.

Most of you who know me know that I am not a huge fan of Spring. Actually, anything that makes me put business logic in XML makes me crazy (more on that below). Regardless, Spring definitely has had a positive affect on the Java community. The funny thing is that, at least in my opinion, the biggest benefits of Spring is not the framework itself, but the ideas that it promotes. Here are some of the ideas that are now mainstream (or becoming mainstream) due to the success of Spring:

Dependency Injection

The reason I am writing this semi-rant right now is because of some code I found yesterday in a J2EE(EJB) app that I am trying maintain long enough to replace it. Down deep in the bowels of this DAO, there are the following two lines (repeated in almsot every method):

AAAAAAAAH!!! What was the original author of this code thinking?!?!? Well, thats pretty easy to guess: the author was probably thinking about how this code was only going to run in a container, and that getting an InitialContext object is SO simple (when you don’t care about the context) that why not just do it wherever its needed?

Now, guess how I found this code?

I must admit that I’ve done stuff like this in the past, and really it was Spring (and the great book “Better, Faster, Lighter Java” by Bruce Tate) that awoke me to the fact that I am locking myself (and downstream developers) into a prison cell of maintenance hell whenever I do something like that. I think that in this case the J2EE spec made it too easy to do bad things. Why not have a Singleton that you got the Context(s) from?

Anyway, Dependency Injection is a good thing for many reasons.

Spring makes EJBs no longer “necessary” (never were but thats beside the point)

Who needs an EJB when you can have lighter weight Java objects that do not need a container to do their magic? This is a sentiment that I know many people share, and it is spreading. Unfortunately there is a big shadow looming over all of this in the form of EJB3. While EJB3 is certainly better than all of the prior versions combined, multiplied and prettied up for the fair, it is still a heavier weight model than Spring, if for no other reason than you still have the massive production EJB containers. The interesting thing is that this mindset has been around for a _long_ time, and is only now hitting mainstream. I find that kinda sad.

POJOs (or, Back to Better Design Principles)

Another issue I have with J2EE/EJB are the “Blueprints” design patterns. I have been pretty fortunate that in my Java career I have only been witness to a few EJB webapps. These webapps follow the Blueprints, and have at their core a fundemental misunderstanding of code flexibility. There are Business delegates that call DAOs that call business delegates that … ugh I can’t continue. Each method is one or at most two lines of code, calling the next layer in this seemingly endless pile of angel hair spaghetti code. There is little to no flexibility here.

Whereas with Spring, you are once again dealing with Java Objects. Hopefully this distillation back to basics with help developers create a better Object domain. We will see. I think that regardless, it is a good start. Now if only we could get rid of this POJO buzzword….

And now for some not so great things

• Lock in.Same problem with most Java frameworks really, but with Spring it is a little more insideous. For instance, lets say that you only want to use Spring for dependency injection. One of your more enterprising developers (lets call him JoJo) finds the extremely handy JDBC helpers in Spring and starts using them for all of his code. Now the team decides to move to Pico container (for whatever reason) and they remove the Spring jars… uhoh. JoJo’s code no longer worky. We are experiencing this right now on a project I am working on. The lead has decided that we no longer want Spring in the system, but can’t just get rid of it, as it was used heavily in our Data layer. Now, one good thing about Spring is that they have kindof anticipated this, and made the code very modular. You do not need to keep around every Spring jar in the above scenarios, and since you are most likely relying on Depency Injection to make the Spring code work you can just plug the code in directly with out the Spring configuration files. However, it is still an issue.
• Programming in XMLMy biggest dislike of Spring is that it uses XML heavily to manage your configuration. This in effect means you are programming in XML, and if there is one thing I hate, it is using XML as a control structure in my code. Yes yes I know that you can use other things, but pretty much every example I have seen has been XML based. Personally I really really want to start using the Groovy version, as then I have a little more control.
• Thats it

While I have some reservations about it, Spring really is a good framework, and I am impressed by what it can do for you. My dislikes are pretty minor in the grand scheme of a project, but they are issues to take into consideration.