Java Web Apps to Rails, A Developer’s Experience…

After transitioning from Java to Rails, I realized this may be a topic worth exploring within the CloudForge community.  This blog delves into my experience of switching from building Java/Flex applications to building Rails applications.   Let me share a little bit of history to help set the tone of this blog.  I have worked in procedural and OO languages (C/C++, Perl, Java) building web applications.  This is my first time developing on a Mac (not to mention, even a right click without a mouse was a mystery when I started).  So, the transition is not just to Rails, but to Rails using a Mac interface.

The goal of this blog is to compare:  developer start-up time, developer tools, Java & Ruby languages, and Web frameworks.

Developer start up time:

The last two Java web applications I worked on were huge code stacks with Flex UI and an Oracle database.  It took a week to get these applications to run, tweak and break because the setup process required me to install a plethora of tools:  version control, application servers, language packages, databases, and version management systems.

On the contrary, Rails comes pre-packaged with some of the tools mentioned above which reduced my setup time significantly.  It took less than a day on a developer Mac and one day on a brand new Mac.

Developer Tools:

When it was time to look at the code, I was a bit disappointed.  TextMate looked like a popular choice but it fell short in many ways.  I struggled to navigate the code, link the methods across files and follow the code. Grep was my only savior. Some of these might take getting used to, but I did not find anything in the menu that could help. Maybe I am biased, but I miss the intuitive Eclipse IDE and the debugging comfort that allowed me to understand the code better and quicker.
The other developer tools such as database viewer, testing frameworks, and command line interface were pretty much the same, no surprises.

Language

My approach to learning Ruby was to start looking at code and figuring out pieces of syntax that did not make sense.  That turned out to be a bad idea. Constructs like “do |x| x+1” threw me off. It certainly helps when switching languages to map constructs.  However, mapping should only be the initial step to get acquainted.  I found it very important to understand the motivation behind creating the new language.  In the case of Ruby, the reasons I see are to reduce inconsistencies, to minimize verbosity (abstracting/hiding boiler plate code), to simplify complex operations. and to reduce programmer errors.

For example, Java has a concept of primitive data types.  Integer and int co-exist in the language and programmers need to make sure Object versions of these data types are used in the appropriate places.  The language does have warnings/errors in place to help the programmer.  However, a developer should be aware of these aspects.  Ruby eliminates that need since everything in Ruby is an Object including nulls.  Blocks in Ruby simplify iterating and modifying collections among other things.  There is significantly less code to maintain, notably code for parsing files, and code for getter/setter methods.

However, I miss parameters list, curly braces, return statements, camel case naming conventions and one way to declare variables (as opposed to the multiple symbols :, @ in Ruby) that make Java code readable.  The concept of ‘open classes’ that allow developers to go in and change a base class sounds scary.  This means the class I write might operate very differently at a later point and the only way to track it down is by looking at the files history.  It is possible in Java too, but I feel the language protects against it more than Ruby does.

Framework

Frameworks for web applications are probably not too different.  Since the purpose of the framework is same across languages and platforms, the main pieces are similar.  The differences I see are in the amount of automation the frameworks offer.  It helps to start with what makes a web application and what tools a developer needs to get things running.  A web application needs front end/UI code, server code, a web archive of deployed code, application server where the application lives, databases for persisting data, testing framework, a continuous integration system to test, build and deploy code.  Here is my mapping of Java Web application to a Rails app.

Concept Java Technologies Rails
Frontend JSP, Flex Views folder (ERB)
Backend J2EE (src/main/java) Ruby (Model, Controller folders)
Deployment WEB-INF Capistrano
Application Server Tomcat Brick
Database Oracle/MySQL/..any other Same as J2EE
Testing Framework Junit Rspec
Mock Testing EasyMock, DBunit Factory Girl, Relish
Build Management Maven, Ant RVM
URL Mapping Web.xml Routing.rb

In conclusion, Ruby is much more flexible and Rails is a bit more restricted than I am used to.  The restrictions are part of the Convention over Configuration idea.  I need to get use to its various ways and unlearn a lot of Java habits.

How has your transition been? I’d love to know so please share your experiences by entering it in the comment section below.

 

Tagged with: , , , , , , , , , , , , , , ,
Posted in CloudForge
One comment on “Java Web Apps to Rails, A Developer’s Experience…
  1. Jon Kern says:

    Thanks for taking the time to jot down your experience.

    Regarding the IDE, I am surprised you did not find RubyMine. JetBrains makes awesome IDEs (ItelliJ, too).

    More about the motivation behind Ruby…

    Ruby treats you like an adult. It doesn’t baby you, or hold your hand, or make you type all sorts of (obfuscating) fluff that a compiled language needs. Your code is more compact and obvious and “dense with meaning”, leading to less need for things like return types and method parameter data types. Or semicolons.

    Rails is incredibly opinionated about how the MVC code should look. It is basically a model-driven architecture. You can use the generators (interesting when first starting, or for banging out a quick prototype), or write your own twist on a generator. Instead of focusing on the boring framework bits with repetitive, template-like code for each domain object, you can focus on quickly creating features that people want to use and pay for :-)

    Ruby on Rails has a great ecosystem of wonderfully talented folks providing gems to do all sorts of useful things. From the full registration/user management (devise) to PDF parsing, to simple rules models, and so much more.

    The ecosystem of supporting tools is incredible. Cucumber, Rspec, FactoryGirl/Fabricate, etc., all make it easy to “do the right thing” and write code with BDD/TDD to provide quality from the start.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

CAPTCHA Image

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

connect with CollabNet
   Contact Us
sign up for emails
looking for something
conversations

CloudForge: Upcoming webinar: #Git #Gerrit with TeamForge: Secure, Scalable, Standards-Compliant for the Enterprise http://t.co/SBf8HDW9Nn
Date: 28 August 2014 | 6:00 pm

CloudForge: @jbergmans: Sorry for the difficulties. I will escalate this issue for you with support and they will respond to you by email tomorrow PST.
Date: 25 August 2014 | 4:14 am

CloudForge: @samuelwford: We apologize for the inconvenience. You may email support@cloudforge.com.: Your inquiry has already been sent to our team.
Date: 20 August 2014 | 4:05 pm