Zero to Riding the Rails in Four Months

rails-podcast.pngWhew! four months of nose-to-the-keyboard development work, and we launched our new product! Because it was the first time we designed, developed, and deployed a complete web application with our new team, we wanted to chronicle our experiences over the whole process – particularly with Ruby on Rails. We thought doing so would help us improve on our experiences in the future. And we hope it can help you too…

In the beginning there was Java and it was good, but something was missing. Java as a partner was not particularly pretty, it was not very fun to wake up to in the morning, but it got the job done. In late May Daniel sent an IM to Matt, He was having problems with eclipse and svn and went off on a tangent. The IM went something like this:

Daniel: “I see why the RoR people are in love. Not that SVN has anything to do with RoR”
Matt: “RoR?”
Daniel: “Ruby on Rails, I was playing with it yesterday”
Matt: “I see, is it good for backend? frontend? both?”
Daniel: “If you are ok with going with the defaults it lets you focus only on developing features, so you don’t have to worry about backend or frontend. Some of the deployment tools are pretty neat too. Ok, back to topic…”

Daniel had just watched the Rails Screencasts and was in love. The concerns we were having with Java and Google Web Toolkit seemed like they would probably go away with Rails. It took a long time to develop new features the way we had been doing things. After debating the topic for a while we had a founder’s meeting in the car while driving to Target, and decided: we would devote two weeks to try our hand at porting (rewriting) YouBook from Java to Ruby on Rails. We quickly purchased the PDF+Hard Copies of “Programming Ruby” and “Agile Web Development with Rails” from Pragmatic Programmers, and the adventure began.

The first couple weeks were incredibly hard. When you develop with Rails, you really have to know the Rails Way to be effective, and not feel like you’re swimming upstream. However, within days we were already starting to see an application take shape. What would have taken us days to change and test in our old environment we could do in minutes in Rails. The phrase, “Wow, I can’t believe how easy this is” was repeated time and again for at least the first month. As great a story as “How we learned Rails” might be, this article is also about the lessons we learned, and what we would do differently – as well as some really useful resources we found along the way.

Framework: Ruby on Rails!
Source Code Control
: Git
Development Methodology
: Speed of development, fixes, and new features

Why we chose Rails over Java + Google Web Toolkit (GWT):

Programming languages & frameworks are just tools. Depending on the job, some tools are better than others. We started with two tools we thought would be fantastic: Java & the Google Web Toolkit. We did so because we were experienced with Java web programming, and knew we wanted our application to have AJAX. Given Matt’s past employment at Google, the GWT framework seemed like a great fit. We wrote our first web application YouBook for ThriveSmart (our company), which let users book appointments online with businesses that partnered with us. Given our experience, they were definitely strong tools. For the next version of YouBook and our new application, we wanted to choose new tools that addressed some frustrations we ran into. GWT & Java have their strengths, but there were some big concerns:

Number of Serial HTTP Requests to Render Any Data
The biggest concern we had was that GWT made the first impression of our app feel slow – the load. We used Javascript to load and render the data of the page (in other words, the server didn’t render any dynamic data onto the page). That meant that (1) browser loaded the GWT “loader” js file, which then (2) interpreted and loaded the real GWT compiled javascript, which then (3) interpreted and then loaded the data (as JS objects which were then drawn by JS). Because this all happened in serial, it just made the page feel slow.

Pages Not Indexable
Another concern was that since our data was loaded in dynamically and not rendered on the original page, none of the content would have been indexable by search engines. Anything that we wanted to have searchable, we probably would have had to have Java + Struts (or whatever framework) render itself. GWT would have had to have been implemented on top of it.

UI more like Swing than HTML+CSS
Although it’s not perfect, designing layouts in HTML with CSS is incredibly flexible and elegant. You get a wonderful separation of design and data. With the UI components that come with GWT, it’s more like you’re developing UIs in Swing, which does not share the same benefits. GWT/Swing makes it easy to quickly mock up a moderately complex UI, but HTML+CSS gives you great results, has better design tools, and allows for far more stylish designs – which can all be changed with a swap of the CSS.

At the end of the day, it’s still Java
Java+GWT has some nice benefits: you can understand what’s going on, because you design the whole thing. You can really reduce the number of complex SQL statements because you have low level control. With GWT, you have the same language for both the server and the UI (cool!). However, at the end of the day you still have Java code, which is not particularly elegant, and any plugins you use for uploading, or RESTful design are usually bloated and not well tested. Perhaps Paul Buchheit says it best.

So we were always on the lookout for better tools that came along. Tools that truly supported our methodology of quickly responding to customer needs and rolling out new features. Thank goodness we found Rails! We learned it, practiced, and started writing our app. And we never looked back.

Let’s continue with what we love the most about Ruby on Rails – the community and light-weight plugins, and show you what we were able to implement within our application in short order!

The Great Rails Community & Plugins

One of the things that impressed about Ruby and Rails was the community. There was an abundance of information and extensions to the core Rails framework offering functionality that we needed. Browsing the source code for the plugins was also a great way to expand our Ruby knowledge – and a great way to expand our webapp features in a lighweight manner. We list all the tools & plugins we use at the end of the post (appendix). But here are some interesting pieces of the Rails community in no particular order:

Railscasts
Ryan Bates is putting together a library of video podcasts that walk you though creating a rails application. Currently at post # 74 I always find a nice nugget of information in each episode. It is also nice to see a topic covered after you have already coded up a solution to find out that you did it the “rails way”.

Peepcode
The one non-free resource in the list. Early on we purchased the RESTful rails episode and recently the Textmate episode. There are many other episodes on the site and for the price, they are a fantastic resource for developers that want to learn a specific subject.

Rails Wiki
A relatively up to date place to find out information on various recommended techniques for building your application.

Blogs
There are “google only knows” how many blogs offering up all kinds of tips and tricks for Rails applications. The one gripe we had with the community is that many blogs do not insert links into the Wiki and the only way to find the information was to (1) check the wiki, (2) search for and add it to del.icio.us

After spending days reading blogs, wikis and plugin source code, we learned a ton – and spent time designing and coding. At the end of the four months, we ended up with a great webapp, in our eyes. Here’s some of the key things we ended up with in short order:

What We ended up With

RESTful Routes
We wanted Sprout! to have pretty URL’s, with that in mind we looked at the two Rails routing options and choose the REST option. Once again, PeepCode screencasts came to the rescue.

Authentication & Authorization
We started off with the restful_authentication plugin and extended it to include authorization per User / Business

Git
We had worked with centralized repositories for years. I had not had the best luck with Subversion. after watching a video: Linus Torvalds on Git, and realizing that some of the issues he described we were having we switched to Git. We started off with local repositories and pulling changes between each other with git-deamon. When we setup our production server we also created a shared repository we could push and pull changes to via SSH. For fun we created a TextMate bundle to assist with commiting, pushing, pulling and getting status of changes – which we will release!

Capistrano based deployment
Capistrano rocks, we love being able to push changes to the website and the app with one command and a password. If you haven’t checked it out (Rails project or not), you are doing yourself a dis-service. It now takes us about 15 seconds, and we can roll back to any release easily.

Static Asset Hosting
As we got close to deployment we noticed that loading Javascript, images and style sheets from on host was slowing page loads. We had already created Apache rules to serve our static web pages, but that was not enough. Initially we used the builtin asset host (config.action_controller.asset_host ) and that was an improvement. We ran into an issue where our javascript files (particularly tinyMCE) would make GET requests against the static host and the inline pop ups stopped working. We also had issues with HTTPS pages showing security warnings in internet explorer. Since we had to come up with a way to serve javascript differently from images and stylesheets we figured we would add a requirement to not serve assets from the asset host if the request was HTTPS. A slightly modified (for HTTPS) version of multi-asset-locations plugin fulfilled our requirements very nicely.

Hosting
For our previous application we had a dedicated server. The cost was pretty high, but we could do whatever we wanted to the machine. We started looking at Virtual Private Servers as we were getting ready to deploy. We knew Joyent was the official rails host, and after poking around we saw that they also hosted twitter. We figured with their experience, great prices, and Daniel’s bias to Sun gear we would try them out. It took a little while to get our first instance (or accelerator as they call it). Now we have two and we love it.

Exception Reporting
Having your users get an error page, no matter how pretty it is, sucks! Going through logs looking for exceptions and stack traces is almost as fun. Early in the Beta we started looking at plugins that could help us by sending emails to the development team when exceptions occurred. We tried the exception_notifier plugin but couldn’t get it to work with Rails 1.2.3. Instead of trying to debug the plugin, Daniel wrote his own while Matt and Jenn were eating dinner.

Performance Monitoring
Being new to Ruby on Rails we are concerned about finding and removing performance hot spots in an intelligent fashion. Using the default Rails logs to do this can be painful. Thankfully we came across this post about a Hodel 3000 compliant logger. Now we get a nightly email showing the performance of the application over the previous day. The change makes it nearly impossible to read stack traces in the log. Thankfully we already had exception reporting 🙂

Image Uploads
Pictures are a big part of the Sprout! experience. With Attachment Fu, a good bit of Javascript a new tinyMCE plugin and a splash of CSS we were off to the races. Attachment fu managed the the uploaded images, resizing, and storage. Javascript and responds_to_parent allow us to do uploads without refreshing the page. And to top it off, we used the JonDesign’s SmoothGallery 2.0 to display stunning slideshows.

Testing
When we started porting YouBook, it was very important to us to decrease the amount of manual testing we had to do. We started off using the standard rails functional and unit tests and changed over to using the test_spec_on_rails plugin after two months. When creating a new feature we don’t always start with tests, but before we push the change, you better believe the tests are in there. We both really enjoying seeing the all green before a commit or right after a pull of the latest code.

Drag and Drop Sorting, Javascript callbacks
In our application, it was really important that our users could edit right in the context of what they’d see. This meant heavy javascript. First, we heavily use the Scriptaculous Drag and Drop code for easy ordering of slideshows or catalog items. The built-in javascript callbacks (for different request formats, like JS, ics, etc) were a lifesaver. We could respond with javascript directly and have it rendered in the browser. It’s so easy, and really efficient – no parsing javascript objects, just javascript code itself!

What We’d Do Differently

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.

Appendix – Resources We Used

Education

Programming Ruby
Best book for learning ruby, for noobies.
Agile Web Development with Ruby on Rails
If you’ve never done any rails development, prepare to get wowed with this great introduction.

PeepCode Screencasts
Regularly expand your Rails repritoire

Railscasts
Great short podcasts you can subscribe to – similar to Peepcode but covers different subjects.

Creating an Images plugin for TinyMCE in Rails
We wrote this little how to =)

Development Environment

Git
Solid source code management – and wicked fast. Plus you don’t get SVN dropplets all over your source directory.

Locomotive (Duh)
Get a Mac and then install this 1-stop-shop for rails development (download the ImageMagick Bundle).
Autotest & Growl (a gem, not a plugin)
Part of the Zentest suite, autotest runs tests in the background as you modify files. It is pretty good at determining what tests need to be run if you make changes to models, controllers or views. With Growl notification it was a lot of fun to see the “All tests passed” message pop up. The “X tests failed” message was not as fun causing many late night head scratching sessions especially when we were new to Ruby.

Ruby On Rails Plugins

Restful Authentication
A well tested and helpful authentication for your webapp on top of RESTful rails.

Attachment Fu
We use it to help us manage uploaded images. This plugins stand out quality is how easy it is to integrate. It comes with helpers for tests, it is robust offering File, database and Amazon S3 storage options for uploads. The other piece of functionality that put a big smile on my face was the ability to quickly add different image sizes to uploads, and the simple integration with image manipulation libraries like ImageMagik.

Test Spec on Rails
About two months into the project we tried to switch from rails builtin functional tests to using RSpec functional specifications. The functional spec tests were easier to read and with specify blocks it was easier to seperate tests by context such as if the user was an admin, customer, anonymous, etc. After an all nighter trying to figure out how to make autotest run RSpec tests and the three hundred existing tests we were about to give up when at around five am we came across the test_spec gem and test_spec_on_rails plugin. Thankfully it let us use our existing tests as is, and integrate specifications for future tests.

Responds to Parent
This little beauty helped us again in the image upload department. By using an iframe for the upload we were able to spare a page refresh after an upload completed. We liked it so much we integrated it with the tinyMCE editor, created our own image select and upload plugin and wrote a how-to about it.

Exception Notifier Plugin
Send email notifications when errors occur in a Rails application. NOTE: Has problems with Rails 1.2.3

Multi-Assets Locations Plugin
Easily map asset host URLs to different asset types (images, javascript, stylesheets) to hosts like static1.myhost.com, static2.myhost.com to improve page load time.
Hodel 3000 Compliant Logger
Changes the log format so you can use pl_analyze to gather performance application for your rails application.

Javascript

Prototype API Documentation
Way too much time spent in here – but necessary if you want to code in rails.

Scriptaculous Effects – Drag N Drop
Javascript effects library including drag and drop, sorting, and highlighting.

SmoothGallery 2.0
A fantastic javascript slideshow library by my friend Jonathan Schemoul.

Responds To Parent
Help with having a parent of an iframe execute returned javascript code.

TinyMCE
A good wysiwyg content editor, which wordpress also uses.

Deployment

Joyent Hosting
A wonderful Ruby on Rails host – we love it!

Capistrano
Deploy your rails app with it, period!

Advertisements
Explore posts in the same categories: rails, Technology

Tags: , ,

You can comment below, or link to this permanent URL from your own site.

25 Comments on “Zero to Riding the Rails in Four Months”

  1. Raju Says:

    Hey! Thanks for the great overview. I am working on my own little project, and initially it does feel like you are riding upstream with Rails. I will be sure to keep your article considering you have had a similar experience, but are far ahead in the development game with Rails than I am…

    Thank you… (Oh, and thrivesmart looks great! Great job guys)


  2. […] HTML e Javascript – foram selecionados frameworks para implementação de Ajax com Javascript. O artigo original oferece bons links indicando como o aprendizado de Ruby on Rails pode ser obtido em pouco […]


  3. […] Zero to Riding the Rails in Four Months « Hack’d – Great Stuff for Web Hackers […]

  4. Dennis Says:

    Excellent overview and pointers re what to do and what not to do when riding the RAILS – in particular thanks for “Getting Real” and TinyMCE commentary and links.

  5. Steve Shreeve Says:

    *Extremely* helpful! Thank you for sharing your experiences. You’ve already saved me a ton of time!


  6. […] Zero to Riding the Rails in Four Months « Hack’d – Great Stuff for Web Hackers A collection of cool ideas we come across while building ThriveSmart. (tags: development deployment ruby rubyonrails rails programming javascript tutorial resources tts web2.0) […]

  7. themedingers Says:

    Thanks for the article; good stuff. I just have one comment about your blog, though. Do you really think you should name it something about hackers, when you guys are attempting to market products to naive business consumers to build their sites (at thrivesmart.com)?? I think that may scare people off if they see your blog with the word ‘hack’ in it. That word seems to have a negative connotation….or so it seemed to in most business people’s eyes that I have spoken with. Just an candid outsiders opinion trying to be helpful…

  8. Behzad Kateli Says:

    Really good article — i am just starting to use ROR and sometimes i am amazed at how simple some things are – like validation. Now i just need to think of a good project. 🙂

  9. Matt Says:

    @themedingers – great point, and we really appreciate the feedback. We totally agree. This blog is actually different than our corporate blog. It’s our development-specific blog, similar to what you might find at developers.xyzcorp.com. We’ll release a marketing & customer focused blog as well, at a different address. Thanks!


  10. Thanks,

    as I’m looking into rails right now, this post was very helpful for me.


  11. […] Zero to Riding the Rails in Four Months « Hack’d – Great Stuff for Web Hackers (tags: hackd.wordpress.com 2007 mes9 dia16 at_tecp ruby_on_rails java comparação) […]


  12. […] Zero to Riding the Rails in Four Months « Hack’d – Great Stuff for Web Hackers (tags: rubyonrails deployment tutorial) […]

  13. Ben Says:

    We have been using RoR for a over a year now (since 1.1.2) and we love it. It seems hard to get most companies of any size to adopt it though. I hope more “business” people read articles like this and realize that we are not just excited about playing with some new technology, but that RoR has actually changed the game.

    “I always thought Smalltalk would beat Java, I just didn’t know it would be
    called ‘Ruby’ when it did.”
    — Kent Beck


  14. […] Zero to Riding the Rails in Four Months « Hack’d – Great Stuff for Web Hackers (tags: rails ruby rubyonrails ror programming development tutorial business article webdev) […]


  15. […] Zero to Riding the Rails in Four Months. […]


  16. […] Check it out! While looking through the blogosphere we stumbled on an interesting post today.Here’s a quick excerptMiksi Ruby on Rails GWT:n sijaan. […]

  17. Matt Jaynes Says:

    Wow. Super great article! You guys rock!

  18. Ryan Grow Says:

    Great article. I’m running into the same https problem with the standard asset host management. Did you create/post a patch for the modifications to the multi-asset-locations plugin to handle https pages correctly?

  19. Dan Says:

    @Ryan
    I never did get around to posting the patch to multi-asset-locations. I doubt they would like my git formatted patch.

    The change is fairly straightforward. In multi_asset_locations.rb change:
    unless source.include?(“:”)
    to
    unless source.include?(“:”) || @controller.request.ssl?

    and you are good to go.

  20. Maximus Says:

    I would like to see a continuation of the topic

  21. cootHaist Says:

    Nice site keep it up!

    ————————————–
    http://www.dasofte.com

  22. Poster Says:

    In Java you write a lot of code. So basically you spend your time writing code.

    In RoR you can do the same thing in one line. So basically you spend the same amount of time in search of how this one line is written.


  23. […] Zero to Riding the Rails in Four Months. […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: