Java The Hutt

This past Wednesday Aimee and I went to check out "Slava's Snowshow" down at the Golden Gate theater in the lovely tenderloin district. It was a very entertaining show and probably took a mind that was able to appreciate things that a bit more abstract as well as have an appreciation for the ridiculous. When I talk about appreciating things that are more abstract it means understand that there's essentially no dialogue in the show and that you don't quite understand with 100% certainty that what you're seeing makes much sense. Basically you have to realize that it's kind of a cirque de soleil type of show but there are no acrobats, just clowns. I think there were quite a few "regulars" that didn't enjoy the show at all. During intermission, which seemed to come about 20 minutes into the show, I heard one older lady nearby answer the "Do you like it?" question with "No, it doesn't make any sense. It's really weird". I won't spoil the show at all here but I can say if you can appreciate seeing something that's a bit unusual and entertaining it's totally worth going. There is a level of audience participation that left me laughing and as entertained as I've been in quite sometime. Basically if you like seeing something that's ridiculous and enjoy watching the audience get messed with there are a couple parts of the show that are worth the price of admission alone. And whatever you do, do NOT leave before the ending, it's worth the price of admission alone.

Anyway, check it out before it's over (I think May 11th).

You know those times when something all of a sudden stops working for seemingly no reason at all? Well about a half hour ago was one of those times for my rails app. Here I was making what should've been a minor and harmless change to one of my controllers to validate some session data before calling an action. I made my change, ran my tests, everything was fine. Went to restart my production application and bam! I get this:

$ restart.sh 
Stopping lighttpd.
Waiting for PIDS: 52846.
No matching processes belonging to you were found
Starting lighttpd.
Rails running in: productionspawn-fcgi.c.186: child spawned successfully: PID: 53350
Rails running in: productionspawn-fcgi.c.186: child spawned successfully: PID: 53353
$ /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:200:in `const_missing': uninitialized constant Builder (NameError)
        from /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_view/helpers/prototype_helper.rb:733
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:214:in `require'
        from /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_view/base.rb:202:in `load_helpers'
        from /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_view/base.rb:200:in `load_helpers'
        from /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_view.rb:32
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:214:in `require'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/actionpack/lib/action_controller.rb:58
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:214:in `require'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/railties/lib/initializer.rb:125:in `require_frameworks'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/railties/lib/initializer.rb:125:in `require_frameworks'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/railties/lib/initializer.rb:80:in `process'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/railties/lib/initializer.rb:42:in `run'
        from /users/home/mkovacs/loanback_current/public/../config/environment.rb:11
        from /users/home/mkovacs/loanback_current/public/dispatch.fcgi:21
using frozen rails/users/home/mkovacs/loanback_current/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:200:in `const_missing': uninitialized constant Builder (NameError)
        from /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_view/helpers/prototype_helper.rb:733
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:214:in `require'
        from /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_view/base.rb:202:in `load_helpers'
        from /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_view/base.rb:200:in `load_helpers'
        from /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_view.rb:32
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:214:in `require'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/actionpack/lib/action_controller.rb:58
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:214:in `require'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/railties/lib/initializer.rb:125:in `require_frameworks'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/railties/lib/initializer.rb:125:in `require_frameworks'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/railties/lib/initializer.rb:80:in `process'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/railties/lib/initializer.rb:42:in `run'
        from /users/home/mkovacs/loanback_current/public/../config/environment.rb:11
        from /users/home/mkovacs/loanback_current/public/dispatch.fcgi:21
using frozen rails

Huh? WTF? I just did a simple update. The site's been running for weeks just fine. I have rails frozen to 1.0 so that shouldn't be an issue. Or is it? Well for those keeping score at home, looking at the above stack trace you can see that my "frozen" rails is melting and leaking outside of the /vendor/rails directory for initialization. Now I'm not an expert at how rails is put together and quite honestly I don't know that I want to be but there appears to be something wrong right here:

        from /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_view.rb:32
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:214:in `require'

and here:

        from /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_view/helpers/prototype_helper.rb:733
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require'
        from /users/home/mkovacs/loanback_current/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:214:in `require'

Those two areas of the stacktrace show that a require is going outside of the /vendor/rails installation and leaking on to the local gems for actionpack.

Obviously my belief that checking out the tagged 1.0 release of rails into my app's vendor/rails directory as being frozen was wrong. It was also wrong for me to be sleeping well thinking that it's not possible for textdrive to change the version of rails on the server and have my app break out from under me. Welp, guess I was wrong about that one. My app is using the frozen version to start, as you can tell by both my stack trace and my print statement "using frozen rails".

So when folks talk about something being "enterprise ready" this is the stuff that they're referring to. So I'm not certain that this isn't somehow my fault because I've not heard of another single person that's come across this problem. The only thing that I can think of is that I didn't do my "freeze" properly? A directory listing of /vendor/rails shows the following:

mkovacs@production_machine$ cd vendor/rails/
mkovacs@production_machine$ ls -la
total 24
drwxr-xr-x   9 mkovacs  mkovacs  512 Mar 29 13:44 .
drwxr-xr-x   5 mkovacs  mkovacs  512 Mar 29 13:44 ..
drwxr-xr-x   7 mkovacs  mkovacs  512 Mar 29 13:44 .svn
drwxr-xr-x   5 mkovacs  mkovacs  512 Mar 29 13:44 actionmailer
drwxr-xr-x   6 mkovacs  mkovacs  512 Mar 29 13:44 actionpack
drwxr-xr-x   6 mkovacs  mkovacs  512 Mar 29 13:44 actionwebservice
drwxr-xr-x   7 mkovacs  mkovacs  512 Mar 29 13:44 activerecord
drwxr-xr-x   5 mkovacs  mkovacs  512 Mar 29 13:44 activesupport
-rwxr-xr-x   1 mkovacs  mkovacs   75 Mar 29 13:44 cleanlogs.sh
-rwxr-xr-x   1 mkovacs  mkovacs  489 Mar 29 13:44 pushgems.rb
drwxr-xr-x  13 mkovacs  mkovacs  512 Mar 29 13:44 railties
-rwxr-xr-x   1 mkovacs  mkovacs  901 Mar 29 13:44 release.rb
mkovacs@production_machine$ 

That looks like everything is there to me. Has anyone else had this problem? Unfortunately this forced me to upgrade my app to 1.1.2 on my production server right now in order for my site to get back up and running. Luckily I was able to do this after fixing a few problems that came up in the upgrade. Even though I fixed it and the site was down for only 30 minutes this is NOT the type of problem that I take lightly as it takes years off of your life as you scramble to fix things, all the while cursing rails and how you were lied to about your rails gems being frozen.

Rails team, I love the new features in 1.1. You guys have been totally crankin and are doing a hell of a job. That said please take the time to ensure that things like this are not issues. It doesn't matter how many cool new features are added to the framework if things like error messages, load paths, and other fundamental mechanisms aren't robust. I realize that rails is not even 2 years old and this pain is part of being an early adopter but these kinds of problems are showstoppers when it comes to trusting your business to a framework.

A very clever commentary by DHH on the entire WS-* work going on for web services, or is it SOA? Whatever your favorite name for these specs there's no doubt that there's a large amount of complexity there and it seems to me that the folks that need the functionality represented by these specs are larger companies with lots of disparate systems that they'd like to have communicate in a common way as well as have a way to manage them all efficiently. Of course for the small/medium business owner this is all too heavyweight and the opposite end of the spectrum, namely REST, is the way that all of those folks are going. To me the biggest reason for the WS-* stuff to exist is the use cases for management of services as well as to support web services that aren't invoked point to point. I'm not an expert on this topic by any means so I may be simplifying things a bit too much but to me those are the salient points for why you'd need to climb on to the WS-deathstar. For most folks a direct point to point connection to the web service in question over an SSL connection is perfectly fine.

I realize more and more that my beliefs about complexity are in line with the philosophy that's taken with ruby on rails. Several months ago before I was even aware of rails I had the opportunity to speak to some folks at Sun and give some feedback regarding the JDK and provide input into their plans for the JDK's future. At that meeting, when asked what types of things I'd like to see in the future I said that I'd like to see things removed or at least stop adding more stuff. I questioned the merits of including web services as part of the base JDK 6.0 offering (I believe the inclusion stems from the belief that there will be many clients out there that need these APIs to invoke web services.) I said that I thought it was best to make many things add-on libraries, or plugins, so that you keep the core simple. Certainly you can mitigate the issue for web service client needs by having the JRE get the plugins that are needed, but I digress.

What made me think of this explicit scenario with Sun was when I read the comment that the rails team was going to pull the web services support out of rails and make it a plugin. I think that's very smart. They are very conscious of adding things that add value but realize the dangers of allowing it to become too bloated. Keeping a simple, functional core and surfacing features as plugins is a great way of making sure things don't spiral out of control. Of course it becomes tricky to manage what gets added to core to support a given plugin as well as ensure that changes made to the core don't break the set of plugins out there but everything comes with a price. Of course none of this is anything new but it just represents a basic philosophical approach to software. Simplicity. Eclipse does the same thing. It's build entirely on a plugin framework.

Looks to be a pretty good bargain at $270. Anybody building or considering building a rails application that lives in the bay area should probably be going.

See you there.

Well my plan of live coverage at TSSS didn't work out so well for a few reasons, flaky wireless not being the least of those reasons. Anyhow, I'll give a brief overview of each of the speakers I checked out. I'll probably go into more detail in the future as I investigate various technologies that appeared to be interesting to me.

First talk was Cedric's talk on TestNG. It gave a good overview of what is offered and why it's better than JUnit. In a nutshell you are able to exert more control over how your tests are setup and executed. I haven't delved into the details of using TestNG yet but as I look into JBoss seam a bit I'll no doubt be posting more opinions and thoughts about it as well as seam. The best feature to me so far appears to be the failed test script generation. When your tests fail a script file is created that will enable you to just run the failed tests, very handy.

The next talk was a split for me between Heinz Kabutz's talk on what amounted to java proxies and Chris Nelson's talk on his trails project. Heinz is a good speaker and his talk was sort of a Josh Bloch type of talk where he discussed some advanced topics and patterns and best practices. Most of his talk was useful for infrastructure code writing, like WebLogic and other plumbing frameworks, not so much for writing apps. Seeing as I'm not super interested in that topic I decided to checkout the Trails talk and see how it matches up with RoR. I walked into the talk and I guess I'd not missed much as he was trying to get a demo working for what must've been a half hour or so because he hadn't covered much ground. He gave the slide talk and gave a demo where he did a bunch of CRUD operations which we've all seen by now but trails is missing what I was really hoping for and what most of the java community seems to be missing and that is something that goes end to end in terms of tooling and deployment. I asked many questions at the end and there is not much thought or effort being placed into things like unit and functional testing, or database migrations, or ajax integration. Overall I didn't get the larger philosophy or vision about what it is that the trails team is setting out to accomplish besides trying to mimick a small portion of what rails offers. To be fair I've not really taken a look at trails and hopefully I just missed a bunch of things that are either in the project or on the roadmap.

Next I went to see the first of two talks by Geert Bevin. This talk was on java continuations. Simply put continuations are a way of executing some code, persisting the state of your execution at that point, and then resuming from there when you come back to continue. The assertion Geert makes is that it makes it nice and easy to program webapps because of the very nature of request/response and the build up of state over multiple request/response cycles. Geert is a really great speaker and knows his topic very well and is well prepared and it shows, he's very polished. I plan on looking into continuations and the rife framework a bit so I'll post more on that in the future. There is still one question that Sam asked that I've still not heard a good answer to and that is, "What if I'm using a resource or am in a transaction and I pause my execution? What happens to those resources in the context of a continuation?". If anyone has a good answer to that question I'd love to hear it.

Next up was Justin Gehtland & Dion Almaer talking about AJAX. They had some great tips and tool recommendations for AJAX development such as a plugin for firefox called firebug that allows you to see dynamic changes to your DOM tree. The tools for AJAX style development are all still in their infancy but it looks like things are coming along nicely. Oh and I won't mention that the example app they were using for their AJAX demo was a rails app (unless they decided to change their tomcat port to 3000 for some uknown reason ;-)

The last talk of the day was Kito Mann's talk about portlet development with JSF. The takeaway here is that he likes liferay the best out of all the java open source portals and also recommends not using the JSPTL at all to one audience user who asked about it. It also appears that facelets are the templating mechanism of choice for JSF development right now.

I also briefly checked out Gavin's talk about seam but was too interested in hearing about rife so I bailed after a few minutes and went down the hall to check that talk out. In short it seems that rife is about the closest thing to a rails like framework that java has to date. Thought I've not checked out grails yet so maybe those guys have done a good job as well. I wish there were more hours in the day to dive into more of these frameworks but with the day job keeping me busy on Java EE 5.0 and my spare time filled with ruby and rails it'll be hard to squeeze in much time to get familiar with these frameworks that no doubt have great features and innovation. I think when it's all said and done that rife will be the most innovative web framework out of the newest crop but that's just a hunch :-)

The last talk of note was Bruce Tate's talk about ruby, rails, seaside, and all things beyond java. I mostly enjoyed the talk but unfortunately I think that Bruce isn't as forthcoming about some of the problems that you can have when making one of these other languages/frameworks your platform of choice. He talked about ruby quite a bit but didn't talk about some of the potential dangers of having something as powerful as mixins can be. Don't get me wrong, I'm a fan of ruby and rails but it's not perfect and I think it's best to call out some of the things that could be seen as a detriment and a reason you wouldn't choose ruby on rails.