Why Agile Developers love Ruby on Rails

The more I develop with Ruby on Rails the more I feel that I’ve wasted a lot of time re-inventing the wheel. There’s a lot of things that Rails gets right, the following list is a short summary of some of the many things that makes it a great tool.

Generators get you setup fast

Rails generators help to quickly mock out your application, moving from nothing to a clickable wireframe with a database in minutes to hours instead of days. “rails generate” is a great tool helping you to create your base template classes for any instance you may have in a project, as a bonus most all generators take additional parameters to complete the code within. When creating model instances the command a rails generate model comment commenter:string body:text will create a new database migration the model class for it as well as a default set of test cases to get you started.

Multi-environment Setup is part of the package

By default Rails is ready for a multiple environment setup. Using the environment variable RAILS_ENV, which can be set via command line on any linux system. Using the built in rails webserver via “rails server” will use the Development configuration by default. Being *database agnostic you can also feel free to use sqlite, or whatever local database you have configured. Not having to configure this setup every single time is a huge timesaver, typically you’ll find a config file full of else if statements configuring via domain names in most multi-environment projects.

* be careful when using database plugins and gems, many of them may use database specific functions that can cause you issues when using different databases in multiple environments. Whenever possible its best to use the same database in all environments.

Tests

Rails will automatically generate your starting tests for you, this applies to both controllers and models. One of the things that really pulled me to rails was that from the very start most tutorials perceive testing as “how you write code” instead of an afterthought; to agile developers this is an important aspect of writing code. When the test stubs are generated for excuses for not testing are eliminated… as if there were any excuses to not test in the first place. If you don’t like the default testing framework and you have a different one in mind for your project if the chosen direction provides generators you can swap it in and still maintaine the same functionality, RSpec is a popular choice over the default testing framework.

CSS and Javascript Grouping with Compression for FREE!!!

While not strictly agile its a best practices treat that all recent versions of Rails will automatically group (combining all the file into one) and compressed javascript and css using the asset pipeline making your site faster, which is a better experience for your users, and a better experience for the Google Bot. The asset pipeline is probably the easiest javascript grouping tool out there. For those of use who who are worried about it being harder to debug, FEAR NOT because when in development mode the javascript and css files are included individually so you can easily track down javascript and css bugs.

Change is expected, Rails embraces it

“Responding to Change” is one of the 4 tenants of the Agile Software Development Manifesto and databases are probably the most painful part of following this. By using migrations Rails handles database changes with ease, instead of writing SQL you write Migration Objects, which are individually time stamped and kept track of per instance. If a migration goes wrong you simply *roll it back to the last stable version. Using migrations its also easy to debug the project at different revisions, by simply checking out the code and running rake db:migrate your working with the version of the database the code expects and on to resolving issues.

The rails ecosystem is Ripe with people who love trying out new things, Rails supports technologies such as Coffee Script, Less CSS, and many many more thru gems. Instead of having to build these from scratch as many of these additions require pre-processing, the rails Gem will automatically handle it for you, adding to the list of one less thing you need to worry about.

*migrations will NOT backup your database so any time a migration will remove data its a good idea to back the database up first, if rolling back the database or code would cause your application to no longer work

Dependency Management

Like Maven provides for Java; Bundler provides for Rails. Dependencies for individual projects are easily installed on your machine via bundler install. No hunting around for packages you may or may not have, bundler automatically finds and installs them for you saving lots of time.

In closing; Ruby on Rails is more than just a web framework. Ruby on Rails is also a collection of utility and support tools that allow developers to focus on what’s important Solving Problems and pushing software. For Agile development few alternatives come close to the breadth of thought that has put into Rails. Spin-up for new project members is fast, database management is easy, and integrating the latest and greatest web technologies is a easy. Using rails you can iterate fast, and deliver more value to your clients by focusing on what matters most.

If Ruby isn’t your thing you can also take a look at Django, written in Python it is probably as close as you can get to Rails without writing Ruby, but who wouldn’t want to write Ruby?

Mentioned in this Article:

Posted in Agile, Databases, Ruby on Rails, TDD (Test Driven Development) | Leave a comment

Prove it to me! TDD (Test Driven Decisions)

With the flurry of new technology available for development today as Developer we often come accross this kind of talk lately:

Developer 1: I heard…
Developer 2: But HackerNews said….
Developer 3: Well I’ve been doing this for X years and…..
Developer 4: But [insert favorite lean company here] uses…..

Lot’s of talk about technologies, articles read, opinions muttered. To me its a lot of noise. To make a good decision when it comes to technology you need to do the footwork and actually play around with the technologies you talk about. You can chair surf all day, and spout your opinions, but until you get down in the dirt, the nitty gritty you’re never going to know how things actually perform.

What I want to hear is this:

Awakened Developer: I tested out [insert awesome new technology here] and based on my findings from [insert lists of tests and scenarios] I find that this [insert awesome new technology here] is a [good/bad] fit for our needs.

Do you see the differences? The first example includes a lot of “but”, “if”, “well”, “said”. The second is a formed thought based on actual work.

Avoid Excuses:

  • I don’t want to install XYZ on my machine, It doesnt match the live environment..:
    With Rackspace cloud servers or Amazon S3 you can spin up a dedicated machine for a few cents a day.
  • I don’t have enough time:
    It may take you a few days to investigate the new technology to flesh it out and decide if it meets your needs, but the cost of not doing it is far worse. Making the square peg fit the round hole is never going to work, and you’ll waste countless hours triaging the dyeing patient till your end product is crap, over budget and doesn’t meet the needs of the project.

In Summary

Test driven should be the way we do technology. You should be able to validate the decisions you make to others, and feel confident in those decisions. This isn’t a practice of accusation, its a practice of verifiable results. We test our code, so why not test our environments and assumptions? I often say the difference between a Software Engineer and a Software Developers is that the Engineer can tell you WHY it went wrong and how to fix it in the future. The other side of that is making a better informed decision in the first place. No matter what your title is always strive to be the engineer.

Posted in Analysis, Strategy, TDD (Test Driven Development) | Tagged , , , | Leave a comment

Why I choose CouchDB over MongoDB

Theres a lot of discussion lately over NoSQL databases for high-performance distributed web apps. Actually thats an understatement, theres been a lot of discussion about NoSQL for the past few years. NoSQL removes the need to a schema, in favor of non-relational data being stored in “documents” (and then theres some really cool magic that happens to keep track of them all).

Currently there are 2 main contenders; CouchDB and MongoDB, and if you care about your data saving, and alway having your data available MongoDB is not a good fit. The marketing engine behind MongoDB is huge, and they have very good writers doing the content for their website. You get Examples like below:

Use Cases
It may be helpful to look at some particular problems and consider how we could solve them.

  • if we were building Lotus Notes, we would use Couch as its programmer versioning reconciliation/MVCC model fits perfectly. Any problem where data is offline for hours then back online would fit this. In general, if we need several eventually consistent master-master replica databases, geographically distributed, often offline, we would use Couch.
    mobile
  • Couch is better as a mobile embedded database on phones, primarily because of its online/offine replication/sync capabilities.
    we like Mongo server-side; one reason is its geospatial indexes.
    if we had very high performance requirements we would use Mongo. For example, web site user profile object storage and caching of data from other sources.
  • for a problem with very high update rates, we would use Mongo as it is good at that because of its “update-in-place” design. For example see updating real time analytics counters
    in contrast to the above, couch is better when lots of snapshotting is a requirement because of its MVCC design.

Generally, we find MongoDB to be a very good fit for building web infrastructure.

There are a log of magic words and phrases in here “MVCC”, “update-in-place design”. Heres what they really mean.

MVCC (Multi-version concurrency): If you go to write something and it fails you don’t lose your data. The new data get’s added to the system, and then when that is successfull the old data, is either forgot, versioned, or thrown away.

“update-in-place design”: We write over the old data right where it was stored, so if something goes wrong you’re hosed. So instead of leaving the last working copy alone before writing, it writes directly on top of it. If this write fails for any reason your data is gone.

In general, if we need several eventually consistent master-master replica databases, geographically distributed, often offline, we would use Couch.

This is really my biggest issue, what’s described here in my opinion is what being “web-scale” is all about. Read/Write your data everywhere and distribute it. The point about data “offline” is actually one of the BEST things about CouchDB, and is kind of tossed aside here. You can maintain your CouchDB database on a mobile device and then synchronize it with one on a server. The web is more than just websites, its data going between places. Arguably anytime your not synching data actively your offline.

In short, if your server crashes, someone trips over the powercord, etc… MongoDB is more than likely going to lose data, while CouchDB will wake back up, see what it was last doing and will lose only the write that was happening at the time of failure. All the benchmarks of performance in the world can’t outweigh that. The biggest saddness about this is that MongoDB won’t even let you know that it failed to write the data. A perfect storm being, the user “saves” their data from their app, the save fails, and they leave their session. When they come back the document is gone.

Use MongoDB only if you don’t care about the state of the data, but want to sling it out distributed as fast as possible. If you’re willing to wait an extra millisecond to ensure that that save and replication actually happens, and when it fails you just use the last valid version use CouchDB.

Posted in Databases | Tagged , , | 7 Comments

Here We Go

So I had some time… and I started this blog.

Till I add more cool articles you can find out what I’m up to on twitter

Posted in Uncategorized | Leave a comment