Rails Demonstration Application Working

Today, I got my first Rails application with a domain model working.  The application was pretty simple, and it is really only a first step.

I’m going to take a brief detour from Rails to check out Node.js and some related technologies, including MongoDB.  Although I’m having good success with Rails, I was reading something today about JavaScript that has me rethinking my position on Rails.  Take a look at Node.js job posting trends.


JavaScript is the front end language, and that isn’t going to change.   By simply accepting that reality, and by standardizing on JavaScript on the back end, we can likely reduce development costs by standardizing on a single language.

Consider also that PhoneGap cross-platform development for iOS and Android uses JavaScript.

These considerations, combined with the availability of several viable domain modeling frameworks for JavaScript (e.g., Backbone.js) is going to make me take a deeper look at JavaScript on the back end.

What if a couple of years from now, we’re all programming in JavaScript?  Stranger things have happened.

Ruby on Rails

Yesterday, I started reading through the Book of Ruby (Huw Collingbourne), which is a bible for Ruby developers.   This book focuses on the Ruby language itself.   Ruby syntax reminds me of Pascal but with significant improvements.

In terms of capability, Ruby seems roughly equal to Groovy, offering meta-programming and closures.  I feel that the jump from Java to idiomatic Ruby would be about the same as a jump from Java to Groovy.  The key is taking advantage of all of the new language features to simplify code.

Ruby is dynamically typed.  This means errors can sneak in where they would be caught at design time with a strongly-typed language like Java.  Fortunately, Rails supports a super-disciplined, test-everything philosophy, which is a good idea in any case.  This makes me believe that the actual benefits of strict typing may be overrated, so long as ample unit testing is performed.  We Java developers may have been brainwashed into thinking that strong typing is a panacea.

I was drinking from a fire hose, running through the Ruby on Rails Tutorial (Michael Hartl).  The first chapters of the book get you set up with the proper development infrastructure.

I’ve evaluated a couple of Ruby IDEs and ultimately I’ve settled on RubyMine.
RubyMine is crammed with features and has been working beautifully thus far.  There is also an Eclipse-based IDE called Aptana, but my sense is RubyMine is the better choice.  One drawback with RubyMine is that it is Swing-based, so it has a slightly clunky look and feel; however, the developers have done a great job making the best of things within that constraint.

The Rails tutorial has also given me a crash course in Git and GitHub.  If you have nothing better to do, you can actually visit my first application (first_app) here:


Finally, this tutorial stepped me through the process of setting up Heroku, which is apparently a preferred cloud provider for Rails.


I’m proud to say that this application is running in the cloud as expected, but it doesn’t do anything useful.  This was just an exercise to ensure that all infrastructure hurdles have been dealt with before actual development begins.

I’m planning to develop my first demonstration app next week. Stay tuned for excitement and surprises.

Deep Dive Underway: Rails vs Grails vs Play vs Zend

SOTA has two greenfield opportunities in play, both of which are mobile-first -> cloud and also involve domain model and persistence.  To meet the requirements of these two new projects, I’m currently in a deep dive to evaluate four modern web frameworks:

  • Grails (Groovy)
  • Rails (Ruby)
  • Play (Scala)
  • Zend Framework (PHP)

I’ve read tons of information about these on the web, but I’m going to take the time to install all of them and do some experiments to see how well they support model-driven development, and moreover, to see whether I can stomach working with them.

Thus far I’ve spent most of my time with Grails, and I have to say that my initial impressions are good.   This framework allows you to easily construct a domain model that is implicitly persistent in the database of your choosing, including NoSQL databases such as MongoDB.  Once you do this, you can immediately begin to create controllers in Groovy that operate upon the domain model objects.

Under the covers, this system uses Spring and Hibernate, which for me are well known.  The other thing that is very cool is how Groovy essentially modernizes Java.  Most Java programs are also valid Groovy programs, but to take advantage of Groovy language features, such as closures and dynamic typing, you need to tweak your coding style.

Groovy classes are regular Java bytecode, so to get familiar with what is really happening, I’ve been decompiling the classes with JD (Java Decompiler).   There are a lot of “secret” methods that Groovy creates in the bytecode that are the key to Groovy’s magic.  The JVM of course is oblivious about whether the classes were actual Java or Groovy, which is one of the most exciting points about the Grails system.

Interoperability between Groovy and Java is seamless, and this is coming from someone that hates that word because it is usually baloney.  In this case, it is accurate.  In Groovy you can directly call on the jaw-dropping variety of open source Java code.  There is nothing that you need to do that hasn’t already been written in Java at least twice.

Add to this spectacular tooling: The Groovy/Grails IDE (GGTS) is really Eclipse with some specialized plug-ins that leverage the Eclipse JDT (Java Development Tooling) package.  This means GGTS is industrial strength and has everything needed for Grails iterative development in Groovy, Java or a combination of the two.

Based on searches of Monster and Google Trends, Grails penetration isn’t nearly as high as Rails (Ruby), but it can be considered on a low-burn upward trajectory.  I can definitely see Grails on the short list of enterprise shops that have investments in Java, because it provides a viable solution for modernizing into the cloud.   Being a seasoned Eclipse/Spring/Hibernate/Java developer, I take to Grails like a duck to water.

For shops considering Grails but concerned about the availability of Grails engineers, I believe a disciplined Java developer can be “retooled” for Groovy/Grails in short order, perhaps a couple of weeks.  Thus, a Grails project can tap into a very large body of engineers, many of which will be highly motivated for the opportunity to work with this modern platform.

Grails is aligned with the Spring, Hibernate, Groovy and OSGi communities, and is loosely affiliated with the Eclipse community as well.  Forgive me if I seem xenophobic, but this community is my “tribe” and that makes me instinctively lean towards Grails.  Moreover, the company that I was contracting with last did a thorough evaluation of web frameworks over a year-long evaluation period, and ultimately chose Grails for their cloud migration efforts.

Grails reminds me of a battle-hardened aircraft carrier group.  It is large, well-documented,  industrial strength, ready for enterprise-scale projects.