I always forget how to set up ctags for a Ruby/Rails app so that I get tags for not only the project, but also any gems specified in my Gemfile. From the project root do:

ctags -R `bundle show rails`/../* .

Sidestep is an experiement built using Sinatra and jQTouch. It's a mobile web app that provides NJTransit train information. The source code is available on GitHub and a working example is on Heroku.

1. Pick a format and stick to it. I prefer "As a <role> I want to <goal> so that <benefit>."
2. Be sure to include acceptance tests with the story.
3. Keep technology terms / phrases out; a story should define user interaction absent of technology.
4. Have your customers write the stories; stories must be understandable to the customer.
5. Don't be afraid to split large stories.
6. Make sure each story provides something of value to the customer.
7. Stories should be independent of each other.

Awhile ago I wrote about the Module Pattern in JavaScript. There is an alternative that is quite popular called the Revealing Module Pattern that looks like this:

The problem is, I don't like it. My main issue with this pattern is readability: it makes it easy to fall into the trap of confusing which functions are private vs. public. This is especially true when you come across code that alternates private and public functions haphazardly like this:

Yes, I know that you can just scroll down to the "return" statement to see which functions are public, but I find that having the public function definitions in the "return" block more intuitive when reading code. The whole point of private functions is to provide abstraction.

When using the regular Module Pattern I can read the public function and scroll up to the private definitions if needed. When reading the module from the top I don't need to keep a mental model to track which functions are public vs. private.

I was playing around with Sinatra a few months ago and decided to create a small app with it. It's a very basic online fuel efficiency tracker which I've dubbed with the stupid name: Fuelyo.

You send a text message to the app (I'm using ZeepMobile for SMS support) with the details of your fill-up. The app calculates your MPG and sends you a text back. You can then go to the app online and see a history of your MPG ratings.

I've put the source code on GitHub. Since this is my first real Sinatra app if anyone has any pointers regarding the code please let me know!

Sometimes when trying to pivot a large dataset it makes more sense to perform the pivot in SQL rather than using something like Ruport. I always forget how to do this so here's a reminder.

Spellbook is a Rails 3 application generator that aims to make the tedious parts of setting up a new Rails app trivial. You define various settings in YAML and Spellbook runs through each of them prompting you for your choice. After all your choices have been made Spellbook executes the 'pre_bundle' code for each one, runs 'bundle install' and then runs any 'post_bundle' code.

It's just a single file gist so you can easily tweak it for your needs.

Edit: For those that do not know how to run this with the 'rails' command, you pass the '-m' option with the path to this file. For example, I have this in my bashrc:

function rspell {
  rails new $1 -m ~/dev/spellbook/spellbook.rb $@
}

Apparently the new Rails 3 generators do not support looking up custom generators in ~/.rails/generators anymore. Here is a bash function that copies a generator from ~/.rails/generators/GENERATOR into your rails app so that it can be used without having to turn it into a plugin / gem.

Note that Rails 3 does not support older 2.x style generators so you have have to re-write those using the new Thor syntax. Here are some helpful links:

• Rails Guides
• Rails specific Thor actions
• Thor Docs

When I started getting more into JavaScript I was looking for the best ways to organize my code. One of the most popular is to use the Module Pattern. This pattern provides structure and helps you to write self-contained decoupled pieces of code. Here is an example template:

During iteration planning, sometimes user stories need to be split so that they can be better handled. Here are a few ideas for doing just that.

Split according to data boundaries:

Try splitting based on the data needed to support the story, like region (i.e. northeast, southeast, etc.), instead of everything (i.e. U.S.).

Split by operation:

Make an effort to split stories into separate CRUD operations (i.e. create, read, update, destroy).

Separate performance requirements:

If a story is made complicated by specific performance requirements, split the functional and non-functional requirements into separate stories (i.e. Story 1: Make the chart screen; Story 2: Make it respond in < 1 second).

Split by Priority:

If a large story has pieces that have different priorities, split them into separate stories.

For more on when and how to split stories, I highly recommend reading Mike Cohn's book, Agile Estimating and Planning.