Ruby on Rails instead of Java + Google Web Toolkit

An article where a couple of guys decided to use Ruby on Rails instead of Java and Google Web Toolkit. I would encourage everyone who is learning RoR to read the entire article. Don’t skip the last part of the article – it should give us RoR newbies a heads-up.

Snip. Snip. Snip.

We had a great introductory ride on Ruby on Rails. We didn’t know Ruby or Rails at all before we started, and we were able to launch a pretty sophisticated web app in a short amount of time. But of course, as with all things, there were mistakes we had to make — mistakes that we would rather avoid in the future.

Design First in HTML + JS
Our biggest mistake: we didn’t complete our interface design before we started programming in rails (Getting Real did teach us to Design Interface First). This was completely understandable, because we didn’t really know what (design & interface-wise) was really hard, versus what was easy to implement in rails. We had to play around with the programming and implementation before we completely designed our app. If we hadn’t, we might have designed our way into an impossibly difficult interface to implement in rails.

But now we know what rails can and can’t do. And we really can’t stress this enough – WE WILL DESIGN OUR INTERFACE FIRST – COMPLETELY! This means we will sit down together and draw every page out on paper together (we like to do this over meals). Once the paper mockups are in order, we will then create full HTML mockups with javascript. Once we settle on the user interface, we’ll go back and “fill in the blanks” with server side code. The beauty is that in Rails, it really is fill-in-the-blanks, and it makes design first a breeze.

Good Javascript Libraries
There were a few painful points that we thought took a long time when writing our app. One of them was surely javascript. Although prototype and scriptaculous are a good start (particularly because there are great helpers to interface with them in rails), there is so far to go in this department. Before we try to write a lot of javascript, we’ll be sure to write additional helpers between rails and our JS code to make it drop-dead-easy to create features.

Use Fixtures Sparingly
When we started testing fixtures provided a way to quickly setup test data. However as our models became more complex and the relationships between them more involved, maintaining fixture data quickly became a headache. Going forward we will be using Mocha to create mock objects for our tests where there is a need to setup relationships between models.

Caching
When we started coding we had discussed implementing caching, but as deadlines approached we kept putting it off. Sure enough when the Beta launched, we didn’t take advantage of caching. In the future we know that we will need to implement caching, but it will probably require a good bit of refactoring to be effective.

Grab the article here.