Choking on Java

As you can tell from my blog I am a long time Java developer who likes to flirt with dynamic languages. Not surprisingly my two favorite languages at this point are Groovy and Ruby. Therefore, I enjoy working with the Grails and Rails frameworks. After working with Java for so long I was starting to get tunnel vision around a single language. After all, Java is a general-purpose language that can do anything if you bend it enough.

However, Java is not always the best solution for all situations. Obviously, Web development is one of those glaring areas where Java can work but might not be the best candidate. I began developing web applications with Java using plain old servlets and jsp pages. Like most Java developers I also discovered Struts 1. While some of the components of the framework seemed a little strange, Struts was better than my homegrown attempt. So I developed with Struts for a while but I was not entirely satisfied. Of course there were other issues to tackle outside of the presentation layer including persistence, transaction handling, and other services. So I evaluated JDO, EJB, and Hibernate. I finally settled on Hibernate but there was still a mess between my presentation tier and my persistence layer. Later I found Spring and glued everything together. After evaluating countless presentation frameworks I refined my Java Web stack over time using Stripes, Spring, and Hibernate. This combination took a lot of experimentation but I was able to make Java conform to the web in a relatively lightweight manner. The point is that I had to do a lot of bending here.

When Rails first came on the scene I was fairly closed minded mainly because of my investment in Java. How could this newcomer trump all my hard work or be as robust as Java? Well after taking Rails out for a test drive I quickly realized how over-architected Web development was with Java. It reminded me of so many early math classes where it would take several pages of computation to achieve a result. Then more advanced math classes introduced techniques to achieve the same results in just a few steps. I appreciated the simplicity of solving a problem with less computation and yielding the same results (or better). Doing less work for the same results once I understand the underlying theory works for me.

But with RoR there was a fair bit of voodoo so I became less intrigued by Rails and wanted to know as much as possible about Ruby. Ruby turned out to be a fun language with constructs that are currently not available or easy to achieve with Java (i.e. closures, better mixin techniques, creating your own DSLs with builders, everything is an object, etc). I quickly realized that I could code much more expressively and achieve the same functionality with a lot less lines of code. Testing my code with a dynamic language instead of Java was also enjoyable because it was simpler. I actually wanted to do testing! Exposure to a new language like Ruby actually improved my Java code (and made me resent how noisy Java is). So now I am an aspiring polyglot with an open mind to new languages.

Not long after I looked at Rails I saw that Grails 0.3 was available (I think I first saw it on http://java.net). So the Java camp was attempting to answer Rails with Grails. OK fine, I took a look at Grails and this is when I was first exposed to Groovy. Groovy offered much of the same dynamic capabilities as Ruby and worked well with my existing Java code (mostly). And Grails offered much of the same convention over configuration principles like Rails. Even better I could integrate my Grails application with my existing Java code. It was like winning the World Series of Poker when I hooked up my existing Spring beans and Hibernate annotated domain objects with Grails. Grails automatically recognized my Spring beans and seamlessly added all of the GORM dynamic methods to my domain classes.

However, I still liked the Ruby language slightly better than Groovy because it did not carry the Java baggage along with it. So now I have a language and a framework that are great for new development, but I could not reach out to my existing Java classes or external libraries with Ruby. Then I found JRuby. JRuby allows me to write Ruby code and integrate with my Java code, Spring beans, etc. However, if I was going to use Rails and wanted to follow their paint by numbers framework then I was stuck with ActiveRecord. Also Rails does not have a service layer concept so my Spring beans did not naturally fit in the Rails framework. I quickly found out how to create a Spring bean factory in JRuby so my Rails controllers could access these services.

As much as I like JRuby there are some things that I want. First, I would like to see JRuby continue to strive for near Java performance. I do realize that we are talking about a dynamic language but I believe that this can be achieved. Second, I think that JRuby needs to provide easier integration for popular open source frameworks like Spring and Hibernate. Why shouldn’t JRuby/Rails emulate Grails the same way that Grails “borrowed” from Rails. Maybe the JRuby team could offer these items as gems to supplement the Rails framework. Or maybe this will be a pluggable feature with Rails 3? This is about bridging the gap between the Java and Ruby communities. Finally, I want to see Engine Yard offer commercial support and training for JRuby (which seem inevitable now that Charles Nutter is at EY).

While building Rails applications is fun, deployment can be a pain. I think that the leveraging JRuby/Rails on a Java platform makes a lot of sense here. Ruby contains several gems for integrating your Rails application in a Java environment. First, there is the Warbler gem, which allows you to take your Rails application and package it up in a standard war file format. So now your Rails application can be deployed on any standard Java container. Second, there is a Glassfish gem for deploying your applications without Warbler. The JDBC-ActiveRecord gem allows you to use your JDBC drivers to connect to your database instead of the Rails drivers. By deploying your Rails application on a JVM you get extra benefits like simpler deployment strategies, better threading support, and easier ways to scale. So while you might want Rails for development, the JVM might offer better services for housing your application. Even if you don't have to integrate any Java code you should still consider JRuby for Rails development IMHO.

So, if you choose to use a dynamic language should you use Grails or Rails for Web development? I do not think there is a cut and dry answer to this question. In this case, the lines are a little blurry because the underlying languages seem to be converging in capabilities. However, I will provide my 2 cents on this issue and watch the comments for this entry fill up. Let me start off by saying that I like both frameworks for different reasons.

Let's start with Grails. Grails is great for Java developers that have existing experience with Spring and Hibernate. The migration to Grails will benefit these people the most because they understand how Spring and Hibernate work. Grails is pretty much just a wrapper around these frameworks so when problems arise they will have the same issues that had to be solved before. The benefit is that this is a great way to get started with a dynamic language (like Groovy) and start to understand what all the fuss is about using a familiar set of tools. Plus, as I indicated earlier you could drop in your Spring beans and Hibernate classes and watch them work out of the box. You will need a deep understanding of Spring and Hibernate when things go wrong to troubleshoot problems as they arise. This is where things might break down for developers that do not understand these frameworks.

Now let's talk about Ruby on Rails with JRuby. Working in Rails is just a fun way to develop. Rails was created solely to solve the domain specific problem around web development. And Rails developers seem to introduce easy solutions to mundane problems. There are lots of plugins and gems that can make Rails even more enjoyable. However, there are thousands of Java libraries available that you might want or need to integrate with. As a Rails developer why wouldn't you at least give yourself the option to tap into those libraries?

So how does everybody win? I believe that everyone will benefit if these two communities come together. I have observed the Java and Ruby communities for some time and seen a lot of mud thrown from both sides. At the end of the day you have to ask yourself why these two groups cannot see that they really need each other at some level. Is this more of a cultural gap than a technical one? Java is infused into so many organizations and is not likely to go away any time soon. What better way to get your Rails application deployed in a Java shop than making a case with JRuby? Also, if you want to evangelize and strengthen Rails as a popular development platform why not build on top of one of the largest existing infrastructures? Rails will only survive by gaining acceptance as a viable framework.

As for Java developers that think that Rails is not a good solution for Web development I say they are passing judgment without entertaining the idea. Let's face it, Java is legacy. If you still think that JSF provides rapid development or think WebSphere is a great application server then you probably will not buy into this blog entry. As technologists we need to find and accept better ways to solve problems. Maybe Rails is not the end all solution for Web development. There are many emerging frameworks like Seaside, Django, Lift, Sinatra, Camping and more that believe they have a better mousetrap. This is a sign that people believe that Java is too complicated and over-architected for web development.

Let me summarize by overstating how much Web development has changed. Java developers and Ruby developers need to understand how the JVM can benefit them. Web development using domain specific languages and dynamic languages are hot and over architected Java solutions are not. But there is a middle ground and whether you choose Grails, RoR, or some other framework to simplify your web development you are probably on the right track. Finally, both the Java community and the Ruby community have things to offer each other to secure their survival.

Well off to look at more Scala...

IntelliJ 8.1 buuild 9732 hangs with Apple Java for OS X 10.5 - Update 4

If you are a Mac user and you applied Apple's Java for OSX 10.5 Update 4 you might be experiencing crashes with IntelliJ 8.1.x. It appears that the software was not tested well enough against the developer preview before the update went GA. You can read more about this here:

http://lists.apple.com/archives/java-dev/2009/Jun/msg00142.html

While you cannot rollback the Java update on the Mac there is a workaround for this issue as described here:

http://www.jetbrains.net/devnet/message/5240216

Here are the steps I used to correct this on my Mac:

Rename this file:

/Applications/IntelliJ IDEA 8.1.3.app/Contents/MacOS/idea

Replace the idea file with the Java system file like this:

cp /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub 64 to /Applications/IntelliJ IDEA 8.1.3.app/Contents/MacOS/

This did correct the issue for me and the software has been stable. IntelliJ was not the only software affected by this update. I also had to get a new version of DbVisualizer (6.5.7) to correct issues with that software as well because of this issue.

RSpec and AutoSpec with JRuby

I had a little bit of a struggle last weekend setting up RSpec with JRuby so I thought I would share the way I set this up. I am not sure why I could not find more information on how to do this so I thought I could help the next guy. Anyways, I am using JRuby 1.3.0RC2 which comes bundled with RSpec 1.2.6 which is great but there were two issues I needed to address before using this in my Rails application.

The first issue was introducing RSpec into my Rails application. It turns out that this is simple. First you need to install the RSpec-Rails gem like this:

jruby -S gem install rpec-rails

Next switch to your Rails project home directory and scaffold out the RSpec components like this:

jruby -S script/generate rspec

This will introduce an rspec folder with the initial scaffolding you will need to write RSpec tests for your Rails application. This only needs to be done once.

The next thing I wanted to do was use AutoTest so that my tests would run in the background while I am coding. This way I can make changes to my code and tests and have the modified tests run on a continuous basis. When we ran the RSpec scaffolding in the Rails application we received an autospec script in the script folder. This is what will allow you to have this perform your local continuous testing. The only other gem you will need is the ZenTest gem which is used for AutoTest and AutoSpec.

jruby -S gem install ZenTest

You are now setup to run all of your Rails RSpec tests manually with Rake from your project home directory:

jruby -S rake spec

Or you can turn on AutoSpec and let this happen in a Terminal like this:

jruby -S script/autospec

I am also using the latest NetBeans IDE (6.7 RC1) for development and find that AutoSpec works great there as well. To do this right click on your project folder and click AutoSpec. This will kick off the script. Here is an example of some of my results:

NetBean also has a nice navigator window for seeing an outline of your specs:


I think that RSpec and AutoSpec provides a very easy and productive way to practice TDD in your Rails applications. Well back to writing more tests...

I Code Better Without A Computer

Alright so this might sound a little silly because we need a computer to actually write code. However, I find that most of my best design, code, and refactoring efforts happen when I am not at a computer. This has been a common theme for me since college where I would wake up with a thought about some problem I was working on but could not resolve while conscious. I would literally wake up some nights with an answer to something that I obsessed about during the day.

I continue to find myself doing the same thing with my code. This happens when I am driving, sleeping, watching TV, playing WoW, showering (don't think too hard on that one) or while my wife is trying to carry on an important conversation (bad idea BTW). I just tell her that I was listening but spawned a new thread while she was talking. This tends to not work in my best interest so don't try that one. I will let you know when I think of a response that won't get you in trouble.

I guess I found out that I was not the only person who experiences this behavior when I attended Neal Ford's On the Lam from the Furniture Police presentation. There he explained how the right and left sides of your brain operate and how they contend for time. The right side of your brain is where your creative non-linear thoughts occur while the left side of you brain spends it's time with rational linear thought processes. It turns out that if you can occupy the left side of your brain with mundane white noise like sleeping, driving, showering, WoW, the wife, whatever...you free up time for your right brain to produce meaningful analytical abstractions without your left brain interfering.

How many times have you resolved an issue while you are in the process of explaining it to a coworker. Your own blabbering can shut down your right brain so your left brain can reason things out! Here is another cool technique that Neal Ford suggested which sounded bizarre at first to me but then made good sense (to me at least). He suggested putting a rubber duck on top of your monitor and when you get stuck you explain the issue to the duck. This is not a magic duck (I don't think). The point is you are freeing up your right brain to perform the tasks you are really interested in.

I am pretty interested in understanding more about how the brain functions and will probably read Andy Hunt's book Pragmatic Thinking and Learning: Refactor Your Wetware. Maybe if I can control my mind I might be able to control my code. Those of you that know me might agree...

Swiz is the Shiz

Now that I am doing more Flex development I am back to researching MVC frameworks for the Flex client. I initially did what most Flex developers do as they start learning and create inline code that cannot be maintained. From there I went to the other side of the spectrum and tried Cairngorm which did exactly what it said it would do but at the price of being very heavy but keep your code organized. The biggest problem with Cairngorm is that it lead to code explosion with all of the objects it required you to create. Needless to say I wanted to find something simpler.

I then researched some other available frameworks like PureMVC and Mate. PureMVC looks like and octopus of classes and seems like a Cairngorm like framework with incremental improvements. Mate was a lot closer to what I wanted but seemed to introduce too much custom framework.

Finally, I found Chris Scott's Swiz framework. Swiz works that way I think since I do so much Spring development in Java. Swiz's main goal is reduce the clutter you maintain in Flex like singletons and service locators by using dependency injection of your components in your application. Swiz also comes with a very intuitive annotation model for dynamically dispatching and registering event listeners to your methods. All of the nonsense you would normally write with some of the other frameworks are abstracted in Swiz and you end up with little framework noise. Visit the Swiz site and look at the docs. You will be up and running in about an hour if you understand how dependency injection works already. You can also check out Christope Coenraets Swiz example for a simple running example. Also look at the Flex 360 video from Chris Scott for a full explaination about this framework.

Mockups

I found this cool little mockup tool that is very easy to work with called Balsamiq. I generally use OmniGraffle for sketching mockups and wire frames but I found this tool to be very enjoyable to work with. When you DnD you elements to the screen you get lots of options for editing that is very intuitive. Here is a quick example of something I whipped up with this tool so you can see what you can do in 2 minutes. The images are cartoonish but I think it will resonate well with end-users when doing design meetings or technical presentations. Simple! Easy to use! Great tool!

Hudson, run a bypass

I thought I would share a pleasant experience I had with a CI (continuous integration) tool called Hudson. I have used other tools like this in the past including Anthill, CruiseControl, and TeamCity. While these tools did their job none of them seemed as easy to use as Hudson.

Hudson downloads as a self contained war file that launches from a command line:

java -jar hudson.war

That is really it to get running and there is nothing else to install. Hudson comes with a built in servlet engine called Winstone. There are no configuration files that you have to touch because you use the built-in intuitive UI to configure the Hudson server and your projects. There are tons of plugins available that can be used to extend the core functionality or you can write your own custom plugins. We run Starteam (yuck) for source control internally but I found a plugin for it and installed it from the web administration. Very simple! I was able to configure SCM checkout, setup email notifications, and execute our build script successfully in about 15 minutes without knowing the product. If you want to see what awesome open source projects look like check out Hudson.