Oz Citizenship iPhone released

I had a lot of fun developing my first iPhone app. I was a bit disappointed with the Objective-C/XCode community though, it's so different than the Ruby and Java ones. Anyways, kudos to Brian Knorr from UISPec, you rock dude!

Check the Oz Citizenship app in iTunes

I found these tools very useful while developing my app:

• Pivotal Tracker (agile project management)
• UISpec (functional tests - hope I find the time to blog about it, it's really cool!)
• GHUnit (unit tests)
• EGODatabase (sqlite3 ORMish)
• OCMock (mocking framework)

One piece of advice for devs: don't use IB at all and write the UI by hand. Over and over code generation proves to be a bad choice.

Thanks to Lawrence Song for the help with development, Kevin O'neill for tips and tricks and Christof Wildermuth for the german translations. Curious that it was indexed in german before any other language.

Yet Another Validator

Sick of writing validators? Sick of XML? Sick of framework specific validation? Sick of complex formats and extra stuff you never use? Well, I was too and now I've outsourced something that might help you too reducing these pains.
Check out YAV.
YAV is a simple, framework independent, lightweight Java validation tool. It applies validations directly to domain models through annotations. It checks for mandatoriness, email, range and regex. If you need, create your own methods to perform more complex validations. It is JSR-303 non-compliant - thank goodness :)
Currently integrates nicely with Spring2.5, Struts2 is on the way.
It also has ValidationTestCases that minimize annoyingly repetitive testing tasks.
As always, there are a few edges to trim, but it works.

Momentary Autism and Business Blindness on Software Development

I finished reading Blink a couple of weeks ago and the anecdotes keep on coming back to me all the time. The book has several support stories for the author’s arguments and in general they are very well constructed. There is one in especial that is closely related to software development. It is the one that talks about how police officers get into a state of momentary autism on situations of extreme pressure. Far from me saying that software developers are under the gun in the same fashion as police people, but there are similarities.

In the book Gladwell discusses why highly trained professionals can bluntly fail to recognize true danger. The most probable reason is that once inside of complex situations the human mind tends to fail intercepting external stimuli. He suggests that a way to avoid getting caught on such mind blanking traps is to repeat safety steps. Most people can handle complex situations but few know how to avoid creating them in the first place. In software production, frequent codebase commits and updates, rigorous test writing (preferably in TDD way) and the use a continuous fast build are as important as keeping a gun away from suspects or holding the torch with the weak hand. If the process provides safety use it always.

In his research Gladwell found that police officers working in pairs do things differently than those working alone. Actually partners tend to speed up when working together. For the police speed can be bad because failing to correctly interpret signals in life threatening situations may be disastrous. Software, on the other hand, needs to be produced quickly, so let’s pair. Developers working together are more confident and like police officers tend to be bolder and charge more. It's a pity that police doesn’t have test frameworks to find out if the suspect was holding a gun or a wallet by the time they decided to open fire.

The autistic condition reported by officers has striking resemblance with the business blindness that plagues developers. Officers say that the fear of gunfire is such that they react without considering external factors. They are trained gunmen but the last thing they want is to fire a gun. Don’t go on writing code unless you know it has business value. It is every developer’s job to challenge requirements for purpose and need. Don’t allow yourself into a condition where everything is self-justified. Don’t use your experience to simply write more code instead make sure that every line delivers value.

This is a list of things to note when developing Rails/JRuby applications that will be deployed to java web containers such as Tomcat, WebSphere et alli. It's obviously incomplete but it is much longer than I thought it would be when I first started.

• RAILS_ROOT becomes the context therefore your traditional Rails folders aren't where you'd expect them to be. In a java container the public area is usually context's root. Warbler helps be copying the files from the application's Rails public folder and you can also modify how it packs the app by changing the entries in warbler.rb.
• Rails caching usually depends on where public files are and things tend to go bezerk unless you set where the public folder lives. So, place this in your environment.rb: Rails.public_path="#{RAILS_ROOT}/.."
  
• Try to stick to one interpreter only. It's quite confusing managing dependencies and versions when having too many rubys installed, and it's very easy to end up with:
  

1. the IDE's JRuby
2. the JRuby you installed
3. the JRuby that comes with warbler
4. the C-ruby install

• Assuming the app will run in JRuby prefer NOT to use a C-ruby interpreter at all, not even in development. This doesn't necessarily means giving up Mongrel/Webrick. Java containers won't refresh changes to view files so it is very handy to use Mongrel/Webrick for the minor css/html changes, otherwise you'll loose rails quick feedback cycle.
• Make sure that the version you're developing in is the same the app will be running when in production.
  
• Don't use warbler's (v. 0.9.9) JRuby version (1.1.1) it will most certainly cause you grief. Delete it from the installed GEM and get the latest jruby-complete.jar, then place it in the lib directory so warbler picks it up when packing the war.
• Check config.webxml.rails.env in warble.rb to make sure the warbled app is configured with the environment you want it to be. This variable creates an entry in the generated web.xml that defines which RAILS_ENV will be executed.
• JDBC adapters seem to be a problem still. When running RSpec the test environment crashes because recreate-database method isn't implemented yet. It seems that Derby is the only one fully implemented.
• Gems dependencies (Rails 2.1) aren't working properly. It seems that it has issues with java gems. I failed to install/unpack hpricot and activerecord-jdbc. So use other ways to freeze gems into the project. Don't forget to use config.load_paths to tell where the gems are in relation to the app in the java container.
  
• Deploy as frequently as possible to the target java container to avoid surprises. I can assure you that there will bad surprises if you don't do it.
• Autotest (ZenTest) doesn't seem to like the script/spec command. A cheap way to overcome this is to create a softlink called script in JRuby's bin directory that points to the bin directory itself.
• I'm using H2 (file based) in development and it is a cool database but there is one annoyance in Windows. Windows locks H2 log file even if the connection is explicitly saying that it shouldn't - url: jdbc:h2:file:db/development;FILE_LOCK=NO. In Linux/MacOS it behaves properly.
• JNDI resources are available for databases only, if you need to grab a hold of other JNDI resources some code has to be cooked to do the lookup. I wrote this very simple JNDI adapter.
• Let database adapters do their jobs, it's a little more code but it guarantees you won't run into type conversion problems. For instance:

1. GOOD -> Person.find_by_name name, :conditions => ["alive = :breathing", {:breathing => true}]
2. BAD -> Person.find_by_name name, :conditions => ["alive = true"]

• Use Exception Notification. It provides a very nice snapshot of the state of affairs and you'll need it.
• Use HAML, it really makes things simpler. This not a JRuby thing but a still a good recommendation.
• Pay attention to links. Strive to use rails resolvers to create links and urls, as traditionally, in a java container you'll usually have a context. In regular rails it looks like this: http://localhost:3000/persons and in java-land most likely this: http://localhost:8080/appName/persons
• Netbeans 6.1 made me smile after frustrated weeks using Aptana and E. I know IDE's are religious war starters but this is my take on it. Netbeans works the others don't.
  
• If possible prefer NOT to develop in Windows, especially because it is definitely much slower. If you must use Cygwin. BTW there is this cool tool called Terminator, it keeps all terminals together in tabs.
• I had problems making controllers see some modules. More specifically cache sweeping. In my controller I had to add these 2 lines, or it doesn't work:
  

1. require File.expand_path("#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/caching/sweeping") unless defined? cache_sweeper
2. include ActionController::Caching unless defined? cache_sweeper

• Protect from forgery has problems with WebSphere. It always complains about the generated tokens not been compatible. Is any one using it?
  

Slight difference on defined? results

Some piece of ruby logic was depending on a defined? check to identify local-variables. It was working fine in C-Ruby but it failed when ported to JRuby.
So what we found out was that the defined? keywork/method/check/thingy in JRuby gives a slightly different response.
Try it out. In your terminal bring up irb and type:


Then try it with Jruby:


JRuby spits out a local-variable(in-block) whilst C-ruby gives back local-variable only. I suppose this is intentional, although I didn't go down the rabbit hole to confirm it. If you know the rationale I'd like to know it too. Anyways, just a heads up that they are different.

Reading JNDI resources in JRuby

The most common use of a JNDI resource in JRuby-land is for configuring datasources. But now I wanted to have ActionMailer send emails using a JNDI config. So how to do it?
Do not fear! JRuby is your friend and every old java trick can be used.

So let's create the JNDI resource which is an javax.mail.Session pointing to localhost. This is what one would normally find in Tomcat's context.xml file (pastie):


Then let's create an adapter to do look ups for us (pastie):


And finally a simple test to see if it works (pastie):


Pretty easy huh?

The Omen strikes again! JRuby on Rails on, yikes, Websphere.

Recently I kept my self busy, and highly frustrated trying to get a JRuby application working on WebSphere 6.1. The recipe was pretty straight forward: warble it and deploy it. Truthfully, there are a few steps that you need to be taken care of, such as configuring database.yml to point to the right place and making sure warbler.rb config file includes the proper jdbc-adapters, but that is all OK.

So, after trying the generated .war in Tomcat and confirming that it was working fine, it was time to hit WebSphere land, and guess what!, didn't work, duh!

The default web.xml configuration doesn't play well in WebSphere. The worst part is that there are no error messages, not even a trace in the logs to help.

The default web.xml spat out by warbler reads:


The filter doesn't work in WebSphere, but the servlet does the trick. So I changed the web.xml.erb within the installed gem to produce this:


Note that I've repeated the listener tag, it was intentional. WebSphere will complain if the listener declaration came after the servlet tag, it must be before, duh! again!