Sometimes, it makes sense to set up a queue and worker processes, but other times it would be great just to have the method run in background with minimal code changes.

Enter Sucker Punch, a single-process asynchronous processing library. Using the wonderful celluloid framework, it lets us do asynchronous work in very few steps.

Setup

First of all, your app needs to be running on Ruby 1.9+, JRuby 1.6+ or Rubinius 2.0 (with Ruby 1.9 mode on the last 2).

Then, install the gem by running

  gem install sucker_punch

or add it to you Gemfile via

  gem 'sucker_punch'
1</p>
<p>And that's it! Now lets see how to use it.</p>
<h2>Creating a Worker</h2>
<p>Creating a worker is pretty simple. It's just a plain ruby class that includes the  <code>SuckerPunch::Worker</code> module, and defines one or more instance methods. Sucker Punch suggests just one <code>perform</code> method, but any name and number of methods can be defined and used. </p>
1
  class SomeWorker
    include SuckerPunch::Worker
    def perform(some_data)
      # Method code. Do some work.
    end
end

Calling the Worker

Before calling the worker, we need to configure our queues:

  SuckerPunch.config do
    queue name: :some_queue, worker: SomeWorker, workers: 5
    queue name: :welcome_queue, worker: WelcomeEmailWorker, workers: 2
  end

We can define as many queues as we want with as many workers as we want (preferable 2+ per queue), but each can have only one worker class per queue.
More workers equals more parallel jobs that can be performed, but be aware of running out of connections if you’re using a connecting to an external service like a database or memcached.

Then you can access the workers on the queues via

  SuckerPunch::Queue[:some_queue] # or
  SuckerPunch::Queue.new(:some_queue)`

This will give us a Celluloid::ActorProxy object wrapping our worker object.
We can call the perform method (or any other method we defined) on that object directly, or use async to return control instantly and make it run in background.

  SuckerPunch::Queue[:welcome_queue].perform(1)
  SuckerPunch::Queue[:welcome_queue].async.perform(1)
1</p>
<p>Just be aware that running the job async will not raise any exception if it fails. It will just fail silently.</p>
<h2>Testing</h2>
<p>Everything needs testing, of course!</p>
<p>Fortunately, testing the worker is pretty easy. You can test it as any Ruby class.
With some rspec flavor:</p>
<p>1
describe WelcomeEmailWorker
  let(:user){ FactoryGirl.create :user }
  let(:worker){ EmailWorker.new }
  describe "#perform" do
    it "delivers an email" do
      expect{
        worker.perform(user.id)
      }.to change{ UserMailer.deliveries.size }.by(1)
    end
  end
end

To test how it integrates with other methods, there are 2 options:

1) Test that it calls and enqueues the job.
To do this you need to require sucker_punch/testing:

require 'sucker_punch/testing'
describe User do
  describe "#send_welcome_email" do
    it "delivers an email" do
      let(:user){ FactoryGirl.create :user }
      expect{
        user.send_welcome_email
      }.to change{ SuckerPunch::Queue.new(:email).jobs.size }.by(1)
    end
  end
end

2) Running jobs inline.
This can be done by requiring sucker_punch/testing/inline, and jobs will always be run synchronously.

require 'sucker_punch/testing'
describe User do
  let(:user){ FactoryGirl.create :user }
  it "delivers an email" do
    describe "#send_welcome_email" do
      expect{
        user.send_welcome_email
      }.to change{ UserMailer.deliveries.size }.by(1)
    end
  end
end

Considerations

Tests Running Inside DB Transactions

There’s one thing to have in mind with tests. If you’re running each test inside a transaction, you’ll need to change that to a truncation strategy for Sucker Punch tests. Here’s an example of how to do it with DatabaseCleaner:
https://gist.github.com/kitop/5248674.

This happens because Sucker Punch workers always run the method in a separate thread, no matter if it is synchronous or asynchronous.

Persistence

Keep in mind that Sucker Punch runs your jobs on a separate thread, and not polling from an outside queue. That means that, if your app goes down while processing a job, it will not notify nor store that error anywhere by default, and it won’t retry it either.
If you need more control over this, you can write your own wrapper. Maybe you could get some inspiration from girlfriday, or use some other solution like resque, sidekiq, or delayedjob.

Rails

If you’re working with Rails, workers usually go in the app/workers directory.

You should be careful with ActiveRecord objects and connections. Workers should receive a record id and not the full object. Preferably, workers should wrap database access related code in a ActiveRecord::Base.connection_pool.with_connection block so it does not exhaust connections in the pool.

class WelcomeEmailWorker
  include SuckerPunch::Worker
  def perform(user_id)
    ActiveRecord::Base.connection_pool.with_connection do
      user = User.find(user_id)
      UserMailer.welcome(user).deliver
    end
  end
end

Connections

You have to be careful not just with ActiveRecord connections, but also with any redis, memcache, or any other service that may limit connections.
It’s important to also limit the number of workers based on those limits. You don’t want to have 20 workers, when there are 10 connections max!

Unicorn/Passenger

If you’re using Unicorn or Passenger as your web server, there’s one more step to ensure everything is set up well. That is to define the queues on blocks that run after the server.

For unicorn (only needed if preload_app true is set):

# config/unicorn.rb
after_fork do |server, worker|
  SuckerPunch.config do
    queue name: :log_queue, worker: LogWorker, workers: 10
  end
end

For Passenger:

# config/initializers/sucker_punch.rb
if defined?(PhusionPassenger)
  PhusionPassenger.on_event(:starting_worker_process) do |forked|
    SuckerPunch.config do
      queue name: :log_queue, worker: LogWorker, workers: 10
    end
  end
end

Further Reading:

• Concurrency and Database Connections, Heroku Dev Center
• Celluloid’s Frequently Asked Questions
• Celluluid’s Thread safety notes

Today, I want to discuss a few of the techniques that I use to make swapping branches easier, specifically the git-stash command.

git-stash is a wonderful way to temporarily hide changes in a dirty working directory. This allows us to work on a feature branch and quickly swap to other branches without the bother of staging / commiting our changes first.

[Typical Stash Workflow]

If you are like most developers, then the extent of your experience with git-stash extends no further than the following two commands:

git stash

and

git stash pop

Often, this is enough for what we need, but git-stash has so much more to offer. Let’s explore some of its myriad abilities.

Saving With a Description

The simplistic approach to stashing is git stash and is analogous (mostly) to git stash save. The latter takes several arguments, most important of which is a description. If you are going to use stash as part of your normal workflow you must use these descriptions to keep better control of each stash. Let’s see how that’d work:

touch gum_drop_mountains.rb   # New feature
git add .                     # git-stash only works on tracked files
                              # unless you pass the --include-untracked flag
                              # to stash save
git stash save "Initial pass on Gum Drop Mountains."
git stash list
stash@{0}: On master: Initial pass on Gum Drop Mountains.

Now when we view the current stash list we see meaningful messages instead of the default description WIP on <branch> <last commit message>.

Stashing In Patches

Sometimes you want to stash a specific subset of changes, for this we can use the --patch (-p) flag. This allows us to interactively specify which changes will be included in this stash.

# edit gum_drop_mountain.rb
git stash save -p "Added GDM tests"

Which will drop you into a prompt like below:

Once you’ve begun the interactive process, you can press ? to see a list of available commands. Upon completion you’ll be able to see your new stash with git stash list. The changes that are left uncommitted (to the stash) will still be in your current directory.

Listing Stashes

The most common way to view your current stashed changes is to type git stash list as we touched on earlier. This will print:

# Unless you are cool and passed a description
stash@{0}: WIP on submit: 6ebd0e2... Initial Commit.
stash@{1}: On master: 9cc0589... Add git-stash

Here, the stashes are specified as stash@{<revision>}. Many of the git-stash commands allow this stash identifier to be explicitly set, making it an important piece of information. git stash list takes any of the options accessible to git log which allows for some customization.

git stash list --pretty=format:'%Cblue%h %Cred* %C(yellow)%s'

Which will output something like:

You can alias git-log with the above formatting, which is common. Doing so with the git stash list is a prime candidate for this style of optimization, as being able to quickly decipher these descriptions can save you time.

Showing Individual Stashes

Showing stashes can be done with the git stash show command. It accepts an argument for the stash identifier and defaults to stash@{0} (most recent). It will display the diffstat by default.

Applying Stashes

Let’s assume we’ve been working for few hours. During this time we’ve been pulled off several times to work on other branches in the project. As we were pulled away, we’ve stashed our dirty working directories and given them all nice messages so we can cobble it all together later. Now that the bugs are fixed, we get to go back to our features. Our stash list looks like this:

git stash list
stash@{0}: On gum_drop_mountain: Touching up gum drop mountain peaks.
stash@{1}: On candy_cane_lane: Adding some tinsel to candy cane lane
stash@{2}: On master: First pass on gum drop mountains.

We want to go back to the candy_cane_lane feature branch and apply our stashed changes there. To do so, we are going to use the git stash apply command.

git checkout candy_cane_lane
git stash apply stash@{1}    # Specified stash or most recent (stash@{0})

Once we’ve done that, our changes are back in their proper place and we can resume work.

Git is smart here, in that you can apply these changes to branches other than the branch from which they were stashed. Furthermore, the branch you apply the changes to doesn’t have to be a clean directory! Git will throw a merge conflict to be manually resolved if the stash no longer applies cleanly[1].

Removing Stashes

Just for funzies, let’s check the stash list before moving on.

git stash list
stash@{0}: On gum_drop_mountain: Touching up gum drop mountain peaks.
stash@{1}: On candy_cane_lane: Adding some tinsel to candy cane lane
stash@{2}: On master: First pass on gum drop mountains.

What? Our stash is still present in our list even after applying it. That’s because apply doesn’t automatically clean up after itself, we have to use the following command to remove the stash

git stash drop stash@{1}

Which will drop just the stash we applied. Had we not given it a stash identfier it would have assumed we meant to drop stash@{0} (most recent). If we want to be rid of all stashed changes we can run git stash clear. Beware of clearing stashes (with either drop or clear) as they are impossible to recover.

The Oh-So Convenient Pop

After applying a stash of changes to a branch, it is quite frequently a good idea to remove that stash from the list (like above). Luckily, Git provides us with a convenient method that wraps this workflow. Assume we want to apply stash@{1} and remove it from the stash list. We can run the following command:

git stash pop stash@{1}

If we provide no stash identifier, it would assume most recent (like most git-stash commands). The git-stash man page provides a good way of thinking about this command. That it does the inverse of git stash save.

Branching a Stash

Sometimes you’ll find yourself in a situation where you’ve begun changes on the wrong branch (master for example) and want to take your current dirty directory to its own branch. Well you are in luck! Normally you’d have to do something like this:

git stash
git checkout -b new_feature
git stash pop

But git-stash has a convenience method to do just this. Simply:

git stash
git stash branch new_feature

This will create and checkout a new branch new_feature and apply stash@{0} to it.

To Stash or Not To Stash

Determining when to stash versus when to commit and squash later is a matter of taste. As long as you write descriptive messages about the stash and be sure to keep your stash list clean, then stashing is a great way to quickly get to a clean directory. If, on the other hand, you don’t take care, you’ll find yourself painfully wasting time figuring out which stash is which.

Warnings aside, stashing is a powerful ability that Git provides and with a little practice it can help you navigate your code more quickly and safely. Happy hacking!

Resources

1. Pro Git (stashing)
2. git ready
3. git-stash man page

David Brady – Learning and Laughing

Every week a group of Ruby Enthusiasts get together in a Virtual Roundtable and explore/discuss/argue some a
spect of the Ruby language or the Ruby community. They allow the rest of us to listen in on their discussion by way of The Ruby Rogues podcast. The podcast can be accessed on iTunes or on the website and offers a ‘fly on the wall’ view of a great bunch of technology savvy people sharing their ideas and opinions.

In this series of articles I will share the results of my interviews with each member of this special group.

Beginning with “The Basics”

Thom: Like any interview, in a podcast or in writing, the first question of course is; “David, please tell us about yourself.”"

David: No, next question.

Thom: Okay. That was a short interview!!

David: No, I’m kidding…

I am kind of an old-school programmer, kind of self-taught. I grew up in rural Utah. When I was in middle school they had some old Apple II computers — well, at the time they were rather new — and they say when you first fall in love with computers, your emotional growth is stunted at that point. So I was 11 and that’s my emotional age to this day because I just absolutely fell in love with computers. I’ve been tinkering and hacking the entire time since.

I took kind of a weird route through programming. I started in Apple Basic and then I moved to IBM and DOS and so I went into BasicA and GW-Basic and I moved up through the ‘Basics’, moved to Quick Basic – well QBasic – Visual Basic, then I sort of went down the rabbit hole. I went into C++ and then into C and then into Assembler.

At that point I was writing graphics drivers and writing video games and just really, really enjoying it and then somebody said, “You know, does it really have to hurt this much to be efficient? And do you really need to be that efficient?” So I said, “I don’t know, tell me more about what you mean.” He said, “Well, there’s this language called Perl and it’s this very high-level language, much higher than even Basic.” I absolutely fell in love with how much you could get done — yeah, you gave up a ton of efficiency, but for 90% of the things you do, you don’t need super efficiency.

Also, Perl is write only [as a language], it’s very terse and everything is implicit, they value implicitness, don’t waste time telling me things that I already know.

A few years later Python came along and I’m like, “Oh my gosh, it’s like Perl, only clear.”
Python has one right way to do it and every other way is wrong and that started to stick in my craw a little bit. Then I came across Ruby. Ruby’s attitude, of course, is there’s probably one right way to do this, but this general class of problem has nine different types of solutions. Unlike Perl where you should try to use all of them for every situation, Ruby says you should use the best one for each given situation. I think a lot of Python people would say that, too, so I don’t want to kick Python’s tires too much, it’s not a bad language.

But I finally found my way into Ruby and I’ve just absolutely loved it. It’s a language that lets me do what I want the way I want and communicate to others in the way that I like.

So that’s more of a programming language history of me. Does that answer the question?

Thom: That’s perfect, because my next question was how did you discover Ruby? You just answered it for me.

David: Perfect.

Thom: This interview is remote control.

David: Perfect.

Neighbors – Friends – Fellow Rogues

Thom: So how did you discover the Ruby Rogues? Did I get an impression that you and Charles Max Wood were friends and had worked together?

David: Honestly, “Location, Location, Location”, just like in real estate. I lived a mile and a half away from Chuck and I was actually at URUG, the Utah Ruby Users Group, back when there was only one Utah Ruby group [now there’s like five]. I was at URUG the first time Chuck came out to a Ruby meet. We made friends, we found out that we were living — did I say a mile away? More like 500 yards! I mean, literally, he was down my street, hang a left and go down a half a block.

Thom: So like if you have a loud party, he’ll know it.

David: Yes, exactly. Well, he moved, but it’s a small town, so now he’s two miles away and so we still know where to find each other.

Yeah, he got talking with James Edward Gray about starting up a panel-based podcast and just kind of out of the blue he’s like, “I think it would be funny to have you on the show,” and I said, “Okay, I will do my best to come and be funny.” I thought I had an opportunity as well to help people, not just be funny, but also to see things in a different way and that’s what I like doing, is getting into a conversation with people and then finding some angle that they haven’t viewed something from, and saying, “Well, have you looked at it this way?” Then there’s that moment when everybody around suddenly goes, “Oh, Wow!” and they make these mental connections that weren’t there before. That’s my favorite thing in the world to do ever.

I’d like to think that’s why Chuck invited me to be on the show, but the reality is, it’s probably just because I was in the room when he was thinking about it.

Thom: I think you don’t give yourself enough credit, but that is funny, the self-deprecating humor seems to be common in the tech world.

David: Yeah.

Thom: Is there something that you’re working on or some project, is there a soapbox you want to get on?

David: No, and I regret that. What I will say is that I have something in the works. I’m not ready to announce yet. I am getting into more of a training and mentoring aspect and so if anybody would like to do that, that’s the direction I’m going with what I’ve got in the works. But that’s not the main business model, so it’s not even a “You can pay me to train you” thing, it’s just a “Hey, if you want to pair just get a hold of me.”

Thom: Terrific. You know you’re going to get a lot of response from that. I may be at the top of that list.

David: Absolutely! I think we could, maybe, break something together.

David: One of the very first programming books I ever opened up said, “Don’t be afraid of the computer, you can’t hurt the computer by typing on it, unless you type with a hammer.” Yeah, I’ve burned up a disk drive by writing a program that was very disrespectful of the hardware timing. I don’t know how many things I’ve burned up or fried. They lied to me. They absolutely lied to me!

What is interesting; I actually never programmed in Fortran. I came in right behind it, but everybody that I looked up to and everybody that I mentored under had come out of Fortran. So for, oh gosh, 15 years, I was (in 1999) writing C++ code professionally as my career and I was rigidly formatting my code to 72 columns. I did not know why, and I got with an old-timer who saw that I was still doing that and he just died laughing. He’s said, “Do you know why you’re doing that?” I said, “No.” He said, “Because in Fortran you need to leave 8 characters for the address line on the punch card and you’ve only got 80 columns on the punch card, that’s why you’re doing that. You’ve got a 21-inch monitor,” (those were the biggest ones at the time) “stop formatting your code at 72 characters.” It’s like the old story of cutting off the pot roast because Grandma did it, but Grandma did it because it wouldn’t fit in her oven.

Thom: Yes, it wouldn’t fit in the pan she had, right.

David: Yes.

Thom: So you probably also then – the habit I can’t break – put the constant first in a comparison?

David: Actually, no, that came after my time. I came from Basic and then into C++, you can do

if X = 42

Right? And oops, you just assigned X the value 42.

Thom: Exactly. Instead of comparing, you just assigned it.

David: But I had gone through the phase where I was writing loops like while *p++ = *d++ which is a de-reference copy and re-reference and then increment both pointers inside the If test.

Thom: Right.

David: And if you look at the source code for strcpy in the old C-reference, that kind of monkey business was not only allowed but almost praised.

So when Microsoft introduced the coding style of swapping the constant and the variable, it was just wrong. Constant == variable, it just never caught on and I still don’t do it to this day. I tried, I don’t like to throw away an idea without tasting it first and I spent a year where I rigidly did — I think they call LHC style, Left Hand Constant style — and no. It just read wrong to me.

David: Ruby does the same thing because you can do

if fp = file.open(...)

Then you’ve got an fp variable in the next line.

Thom: When I work in VBScript, it just (shudder)…

David: Just between you and me and — You know, I was going to say this is not for print, but you can go ahead and print this. I fed my family for a year writing VBA and VB script and so I don’t tell people that I do it, because if you want to hire me for that skill, I don’t want to work for you.

Thom: I agree. In job interviews, when asked if I do VB or VB scripting, I always say, “Yes, but I wash my hands afterwards.”

David: Yes. Yes, exactly. So anyway, I just wanted to mention that as a yes, it’s a mark of shame, but I stand with you in solidarity, brother.

Revealing a new Perspective

Thom: What do you see your role in the Ruby Rogues?

David: Obviously I have a pretty good sense of humor and I like to inject that where appropriate and then a little bit more, as much as I can get away with without annoying people too much.

Like I mentioned earlier, trying to make people think and see things from different ways is a very big goal. But the open secret that I have when I’m on the show is I love it when I’m on a show with two people that have wildly differing approaches to something. That one is like, “Don’t ever test,” and the other one is, “Over test everything.” When I can look at two people and say, “You know, you guys are in disagreement on 98% here, let me throw one-third thought in here that you guys haven’t mentioned,” and then both of them go, “Oh, my gosh, you’re right.” I absolutely love that.

I love the MINASWAN — that stands for Matz Is Nice And So We Are Nice. I really like honoring that in the community and when we have somebody on the show that has a really strong opinion about something, I love being able to temper that in such a way that we can have people with strong opinions that suddenly find themselves working together with their strong opinions, rather than opposing each other.

I think that’s kind of why my favorite episodes I’ve ever been on are the ones that have been on like diversity and drama in the Ruby community and interpersonal relationships. Those are my favorite episodes to be on because they’re such juicy topics for people to be wound up about and yet care deeply. When you can get two people and tap into their caring deeply, you can suddenly make them going from disagreeing violently to agreeing; maybe still violently.

But that’s really what my favorite thing to do on the show is. I just use the humor to distract from that.

Thom: Thanks David

David: My pleasure.

You can find David Brady in the usual places:

• Github
• Ruby Rogues

I thought it would be interesting (and hoepfully useful) if I documented the progress I made on RubySource as I went along … so here is part one of the series!

My idea is to build some Sinatra middleware that could be bolted on to a project to add some simple content management support. I also want to have taggable pages and the possibility of extensions (such as navigation lists modules, file upload modules, email modules etc).

MongoDB and Mongoid

I decided to use MongoDB for persistance. I’ve used it a little bit in the past and thought that it would be a good fit here. MongoDB is a NoSQL data store that is fast and scalable. It uses the concept of collections of documents instead of tables and rows. A big advantage is that it is schemaless, and therefore, doesn’t require any migrations. Also, you can add new fields on the fly (in fact documents in the same collection don’t even have to have the same fields), making it very flexible and suitable for agile development.

I chose to use Mongoid as an ORM since I liked the look of the syntax, it is well documented, and under very active development. I found installing MongoDB locally to be a bit of a pain, but the MongoDB documentation should help you out. Once it it installed, you need to start the mongod server. This is operating system specific, so consult the documentation about how to get it done.

Setting Up

To get started, I created the following Gemfile:

    source "https://rubygems.org"
    ruby "2.0.0"
    gem "sinatra"
    gem "slim"
    gem "sass"
    gem "mongoid"
    gem "redcarpet"

First of all, Mongoid requires at least Ruby 1.9.3, so it helps to put this in the Gemfile (specifically for when we come to deploy on Heroku later.) Obviously, we need Sinatra. I will be using Slim for the view logic and Sass for the styles. This is purely my choice and my default development choices currently. To be honest, there won’t be that much styling going on, but it’s always easier to use Sass. I’ve already mentioned Mongoid, which leaves Red Carpet – an implementation of markdown, created by the kind folks at GitHub.

To make sure everything is installed run bundle install from a command prompt.

Mongoid also requires a bit of set up. To do this, create a file called mongoid.yml and save it in the same directory. These are the default settings that I’ve found work nicely to start with Mongoid:

    development:
      sessions:
        default:
          database: cms
          hosts:
            - localhost:27017
    production:
      sessions:
        default:
          uri: <%= ENV['MONGOHQ<em>URL'] %>
          options:
            skip_version_check: true
            safe: true

In the same directory, we need to create a file called main.rb where our main functionality will go. To get things moving, I decided to dive in and build a classic application and will move it to modular later. At the beginning of main.rb, we need to require the relevant gems and configure Mongoid:

    require 'sinatra'
    require 'sinatra/reloader' if development?
    require 'mongoid'
    require 'slim'
    require 'redcarpet'
    configure do
      Mongoid.load!("./mongoid.yml")
    end

A Page Class

Now we come on to the heart of our CMS - the page model. We'll start simple - give it a title and content field:

    class Page
      include Mongoid::Document
      field :title,   type: String
      field :content, type: String
    end

To use Mongoid in a class, all you need to do is include the Mongoid::Document model. After this you can define the fields to be used in the database. Our two fields are 'title' and 'content' and they are both of type string. Now we can have a go at creating some pages!

Create Some Pages

We don't have any routes defined yet, but that doesn't mean we can't create any pages. It's always useful to be able to run our program through the console. Open up a terminal and start up IRB using the following command:

$> irb

This should give you a ruby prompt similar to the one below where we can require the main.rb file:

2.0.0-p0 :001 > require './main'
=> true

Now we can have a go at adding some pages:

2.0.0-p0 :002 > hello = Page.new
 => #
2.0.0-p0 :003 > hello.title = "Hello World!"
 => "Hello World!"
2.0.0-p0 :004 > hello.content = "
This is our first page
"
 => "
This is our first page
"
2.0.0-p0 :005 > hello.save
 => true

We've just created our first page! This is done using the new method. We assign the page to the variable hello. This has setter methods of title and content provided by Mongoid. Once these have been set, we use the save method to commit the changes to the database.

Rather than writing out each property one at a time and then saving the object, we can create a document in the database in one line, using the create method:

2.0.0-p0 :006 > Page.create(title: "Markdown Page", content: "This page uses markdown")
 => #

We can check that the pages have been created by querying the database. First of all, let's check how many pages have been saved using the count method:

2.0.0p0 :007 > Page.count
 => 2

That's good news - there are 2 pages saved in the database, as we expected. There are numerous ways to search for the pages using Mongoid. Here are a selection of queries that we might use:

    2.0.0p0 :009 > Page.first
     => # Page.last
     => #, title: "Hello World!", content: "
This is our first page
">

The first and last methods do exactly as they say on the tin and find the first and last documents in the database, respectively. We can also find a specific document using the find method with the document's id string as an argument:

    2.0.0p0 :011 > Page.find("5173f574a39401776a000002")
     => #

We might not always know the document id, so we can also search by the different fields, using the find_by and where methods:

2.0.0p0 :012 > Page.find_by(title: "Hello World!")
 => #This is our first page
">
2.0.0p0 :013 > Page.where(title: "Hello World!").first
 => #This is our first page
">

Although these look the same, there is a subtle difference: find_by returns a Page object, wheras where returns a MongoDB criteria, which is a proxy object that can be chained together. It doesn't query the database until all the criteria have been completed.

Viewing the Pages

Now that we have some pages, let's create some routes and views so that we can see them!

First of all, we'll create an index page that lists all of the pages in the database. Add the following route to the bottom of main.rb:

get '/pages' do
  @pages = Page.all
  @title = "Simple CMS: Page List"
  slim :index
end

This finds all of the pages in the database and stores them as an array in the instance invariable @pages. We also use the instance variable @title to store the title of the page (this will be used in the layout view). We then render the view called index using slim.
We need to create that view now. Create a file called 'index.slim' and save it in a folder named views in the root directory. Place the following code inside this file:

  h1 Pages
  -if @pages.any?
    ul.pages
    - @pages.each do |page|
      == slim :page, :locals => {page: page}
  - else
    p No pages here!

This is simply a list of all the pages, but it uses a partial to display the actual information about each page in the line == slim :page, :locals => {page: page}. This means that we need to create another view called 'page.slim' (also saved in the 'views' folder), containing the following code:

li
  a href="/pages/#{page.id}" =page.title

It's not a huge partial, but it makes sense to keep it in a separate file, as we might want to add more information to what we place in here later or use it in other views.

The page partial had a link to each individual page. We need to write a route handler to deal with that. This is used to display each individual page - place the following code below:

    get '/pages/:id' do
      @page = Page.find(params[:id])
      @title = @page.title
      slim :show
    end

This finds the page based on the id give in the URL and creates an instance variable called @page to store the Page object. We also store the title of the page in the @title instance variable.

Next, let's create a page to view the actual page. Save the following code in the views directory as 'show.slim':

h1= @page.title
- if @page.content
  == markdown @page.content

This is a very straightforward view that shows the title as a level-1 heading and using the markdown method to display the content (if there actually is some content). Notice that both of these are methods of the @page instance variable created in the route handler.

Before we test this out, we need to create a layout for the application. Here is a basic HTML5 layout that will do just fine:

doctype html
html
  head
    title= @title || "Simple Sinatra CMS"
  body
    h1
      a href="/pages" Simple Sinatra CMS
    == yield

Save the code snippet above as 'layout.slim' in the views directory, then start up a server by typing ruby main.rb into a terminal, then go to http://localhost:4567/pagesin your browser and you should see a list of pages similar to the following:

Have a go at navigating around all the pages!

Creating Pages

That was fun, but we only have two pages, so we need to create more ... and in the browser too.

First of all, we need to create a route handler for the page where we will add a new page. Add the following code to 'main.rb', but make sure that it goes before the '/pages/:id' route (this is because Sinatra always looks for the first route that matches a URL and '/pages/:id' matches '/pages/new' by setting params[:id] to 'new'):

get '/pages/new' do
  @page = Page.new
  slim :new
end

This simply creates a new page object and stores it in the instance variable @page, which will be available in the view. We probably won't need this object at the moment, but in the future we might be using the same form to edit a page as we do to create a new one. The edit form will have references to the page that is being edited, which will be the @page instance variable. If this didn't exist then we'd get errors, so we just create a new Page object to avoid this.

We then display the new view, which we better create in the 'views' folder, here's the code:

h1 New Page
form action="/pages" method="POST"
  fieldset
    legend Create a new page
    == slim :form
  input type="submit" value="Create"

This uses a partial for the actual form (so we can reuse it in the edit page). We also need to save the following as 'form.slim':

label for="title" Title:
input.title type="text" name="page[title]" value="#{@page.title}" size="32"
label for="content" Content:
textarea.content name="page[content]" rows="12" cols="72" ==@page.content

At the moment, we only have two fields that are required, so it's a fairly straighforward form. You can see the references to the @page instance variable - these will show up as blank when it is a new page.

Now we need to sort out what happens when that form is submitted. We can use a route handler to deal with this. We use the URL '/pages' as this is what was in the form's 'action' attribute. But in this case, we use the HTTP verb 'post' as this is the method used by the form when it is submitted:

post '/pages' do
   page = Page.create(params[:page])
   redirect to("/pages/#{page.id}")
end

In this action, we create a new Page object using the create method that we used in IRB earlier. params[:page] is a hash of all the values entered in the form. We then use Sinatra's helpful redirect and to methods to redirect to the URL for the newly created page.

Now that all the routes are in place, we just need to add a link on the index page to create a new page. Make the following line somewhere near the top of index.slim:

a href='/pages/new' Add a new page

Restart the server (Hold down Ctrl + C then type ruby main again) and have a go at creating some new pages.

Eureka! We have the beginnings of our simple content management system. We can create new pages using Markdown and view them.
In part 2, we'll look at editing and deleting pages and also how to create permalinks with 'pretty URLs' based on the title of the page.

I hope you've enjoyed this post, please leave any feedback in the comments section. I'd be especially interested in hearing any ideas for the project going forward.

Getting information into the Transmogrifier

In our last episode, we transmogrified data from one format into another. Now you need to get data into it using the transmogrifier. We could hard code the file names in there but that will come back to haunt us. Let’s make is so we can load in the definition file, the data file, and the name of the output file.

You’ll need to read the csv data file. How do you read a file line by line in Ruby?

require 'csv'
File.open("def.txt") do |file|
  while line = file.gets
    puts line
  end
end

You can save the file. I saved it as transmogrifier.rb

You can go ahead and run it.

$ ruby transmogrifier.rb
FIELD NAME      FORMAT
NAME            A(50)
ADDRESS1        A(50)
ADDRESS2        A(50)
CITY            A(50)
STATE           A(2)
ZIP             A(10)
CONTACT         A(50)
CONTACTPHONE    A(10)
ACCOUNTOPENED   9(8)

It works. We have data now we need to load up the definitions. In the transmogrifier.rb go ahead and add the code to do that. Remember what to do?

File.open("data.csv") do |file|
  while line = file.gets
    puts line
  end
end

If you’re curious go ahead and run it.

Now that you have the definitions and the data loaded you need to send them to the transmogrifier. You need to send the data, length of the field, the type, and the column name. Three of the four come from the definition file.

Let’s write out the Type, Length and, Field name. The Field name starts at the beginning of a line
We could split the line up and put it in an array. Since the file uses spaces, not tabs, for aligning things we can use split.

require 'csv'
definitions = Array.new
File.open("def.txt") do |file|
  while line = file.gets
    definitions = line.split()
    puts definitions[0]
    puts definitions[1]
  end
end
...

That gets us the field name but the Type and Length are still together. Were you thinking of regular expressions to find the Type and the Length?

require 'csv'
definitions = Array.new
File.open("def.txt") do |file|
  while line = file.gets
    definitions = line.split()
    field = definitions[0]
    type = definitions[1] =~ /9/? '9' : 'A'
    length = definitions[1].slice(1..definitions[1].length).gsub(/[^0-9]/, "")
    puts 'field => ' + field.upcase + ' type => ' + type + ' length => ' + length.to_s
  end
end

Go ahead run it.

$ ruby transmogrifier.rb
field => FIELD type => A length =>
field => NAME type => A length => 50
field => ADDRESS1 type => A length => 50
field => ADDRESS2 type => A length => 50
field => CITY type => A length => 50
field => STATE type => A length => 2
field => ZIP type => A length => 10
field => CONTACT type => A length => 50
field => CONTACTPHONE type => A length => 10
field => ACCOUNTOPENED type => 9 length => 8

Now we’re getting somewhere. Three of the four variables that get passed to the transmogrifier. Maniacal laugh.

One Queston.

How do you think you will get the data into that array?

What if we throw the array into a hash? Then, take that hash into another hash where the key is the field name and the data is from the first hash.

All we need to do is loop through data and find the key from the hash that goes with that column and send all that to the transmogrifier. Keeping things simple here.

First, go ahead and put the definition data into a hash. Then stuff that into a hash. For fun, go ahead and output that last hash so we can see it.

require 'csv'
object_name = Hash.new
definitions = Array.new
File.open("def.txt") do |file|
  while line = file.gets
    definitions = line.split()
    field = definitions[0]
    type = definitions[1] =~ /9/? '9' : 'A'
    length = definitions[1].slice(1..definitions[1].length).gsub(/[^0-9]/, "")
    object_formatting = Hash.new
      object_formatting["type"] = type
      object_formatting["length"] = length
      object_formatting["field"] = field
      object_name[field.upcase] = object_formatting
  end
end
puts object_name

Run it and let’s and see what we have.

$ ruby transmogrifier.rb
{"FIELD"=>{"type"=>"A", "length"=>"", "field"=>"FIELD"}, "NAME"=>{"type"=>"A", "length"=>"50", "field"=>"NAME"}, "ADDRESS1"=>{"type"=>"A", "length"=>"50", "field"=>"ADDRESS1"}, "ADDRESS2"=>{"type"=>"A", "length"=>"50", "field"=>"ADDRESS2"}, "CITY"=>{"type"=>"A", "length"=>"50", "field"=>"CITY"}, "STATE"=>{"type"=>"A", "length"=>"2", "field"=>"STATE"}, "ZIP"=>{"type"=>"A", "length"=>"10", "field"=>"ZIP"}, "CONTACT"=>{"type"=>"A", "length"=>"50", "field"=>"CONTACT"}, "CONTACTPHONE"=>{"type"=>"A", "length"=>"10", "field"=>"CONTACTPHONE"}, "ACCOUNTOPENED"=>{"type"=>"9", "length"=>"8", "field"=>"ACCOUNTOPENED"}}
...

Lovely. Now you need to process the data file. Let’s get the Field name and the data for that column

CSV.foreach("data.csv", headers: true) do |data|
  data.headers.each do |field|
    puts field + ' => ' + data[field].to_s
  end
end

Hold on! What is that CVS.foreach() call? Let’s take a look at that.
That line will process a CSV file and treat the first line as a header and not data.

When you run that you output should look like

name => Wonder widgets
address1 => 1600 Vassar Street
address2 =>
city => dallas
state => tx
zip => 75220
contact => Tim Smith
contactPhone => 214-555-1212
accountOpened => 12052001
name => Timmy's Bikes
address1 => 2723 Auburn Street
address2 => Building 3
city => Erie
state => PA
zip => 16508-1234
contact =>
contactPhone => 814-555-4321
accountOpened => 865289

We’re Almost Home.

Now we have the data and the definitions. Let’s send that information to the transmogrifier.

As we loop through the data, we need to find the matching key form the hash we made earlier. When we match it send it to the transmogrifier

CSV.foreach("data.csv", headers: true) do |data|
  data.headers.each do |field|
    object_name.each do |key,value|
      if field.upcase == key
        field.upcase!
        line = transmogrifier(data[field].to_s, object_name[field]["length"].to_i, object_name[field]["type"], field)
        print line
      end
    end
  end
  puts ' '
  puts ' --------- '
end

That will do all that we talked about. Had we written tests like in the first part we would catch a bunch of gotchas. What if there is no data for a column? How do we get all the data on one row? How do we save the data? How do we pass the definition and data file names in?

Here’s what I came up with before refactoring

require 'csv'
def transmogrifier(data,len,type,column)
proper_formatted = ''
unless data.nil?
    case
    when data.length > len
      data = data.slice(0..(len-1))
    when data.length < len
      if type == "A"
        data = data.ljust(len)
      else
        data = data.rjust(len)
      end
    else
      if column == "ACCOUNTOPENED"
        data = data.slice(4..7)+data.slice(0..3)
      else
        data
      end
    end
    proper_formatted += data
  end
  proper_formatted += '|' # added pipes to see where the field ends
  proper_formatted
end
object_name = Hash.new
file = File.new(ARGV[0],"r")
definitions = Array.new
while (line = file.gets)
    definitions = line.split()
    field = definitions[0]
    type = definitions[1] =~ /9/? '9' : 'A'
    length = definitions[1].slice(1..definitions[1].length).gsub(/[^0-9]/, "")
    object_formatting = Hash.new
      object_formatting["type"] = type
      object_formatting["length"] = length
      object_formatting["field"] = field
      object_name[field.upcase] = object_formatting
  end
file.close
aFile = File.new(ARGV[2], "w")
CSV.foreach(ARGV[1], headers: true) do |data|
  data.headers.each do |field|
    object_name.each do |key,value|
      if field.upcase == key
        field.upcase!
        line = transmogrifier(data[field].to_s, object_name[field]["length"].to_i, object_name[field]["type"], field)
        aFile.write(line)
        print line  #so you can see something in the terminal window
      end
    end
  end
  aFile.write("\n")
  puts ' '
  puts ' --------- '
end
aFile.close

If you run $ ruby transmogrifier.rb def.txt data.csv formated.txt
You should have a new file in the folder you are working in called formated.txt

Now go forth and transmogrify Maniacal laugh.

Defining the Finished Output.

We are given a, let’s say, definition file on how the data needed to be formatted for importing. Let’s say it looked like this.

FIELD NAME      FORMAT
NAME            A(50)
ADDRESS1        A(50)
ADDRESS2        A(50)
CITY            A(50)
STATE           A(2)
ZIP             A(10)
CONTACT         A(50)
CONTACTPHONE    A(10)
ACCOUNTOPENED   9(8)

What does this mean? We’re really focused on the format. ‘A’ means alphanumeric with white space added to the right. ’9′ means numeric with white space added to the left. The number means length of the field, so ‘A(10)’ is a alphanumeric field of 10 characters.

Our source data is in a CSV file. Something like:

name,address1,address2,city,state,zip,contact,contactPhone,accountOpened
Wonder widgets,1600 Vassar Street,,dallas,dallas,tx,75220,Tim Smith,214-555-1212,12052001
Timmy's Bikes,2723 Auburn Street,Building 3,Erie,ERIE,PA,16508-1234,,814-555-4321,03232011

The output just needs to be a text file.

Wonder widgets  1600 Vassar Street             dallas tx75220     Tim Smith 214-555-121220011205
Timmy's Bikes   2723 Auburn Street  Building 3 Erie   PA16508-1234          814-555-432120110323

How would you do that?

Time to Start Transmogrifing

How would you transmogrify the data? From the target definition, we know the name will be 50 characters long. You can write a method to take the name column and make it 50 characters long. Want to plow down that path? We can re-factor later. Remember you have to pass in text.

def nameFixing(name)
  name = name.ljust(50)
end

Good old ljust will add the extra white space we need. Does this seem to easy? It is Ruby, but maybe we should test this.

require 'test/unit'
def nameFixing(name)
  name = name.ljust(50)
end
class NameLengthTest < Test::Unit::TestCase
  def test_name_short_should_equal_50
    name = nameFixing "boo"
    assert_equal(name.length, 50)
  end
end

Save that file and go ahead and run the test.

$ ruby ljust_test.rb
Loaded suite ljust_test
Started
.
Finished in 0.000802 seconds.
1 tests, 1 assertions, 0 failures, 0 errors, 0 skips
Test run options: --seed 27164

Sweet, It did work.

What happens if it’s more than 50 characters long? Go ahead and take stab at it.

require 'test/unit'
def nameFixing(name)
  name = name.ljust(50)
end
class NameLengthTest < Test::Unit::TestCase
  def test_name_short_should_equal_50
    name = nameFixing "boo"
    assert_equal(name.length, 50)
  end
def test_long_short_should_equal_50
    name = nameFixing "dgrtefdgdfshrtyutyuykhjkmbnmvcbdfgrthjghjgghvdfgrstthg"
    assert_equal(name.length, 50)
  end
end

$ ruby ljust_test.rb
Loaded suite ljust_test
Started
F.
Finished in 0.001179 seconds.
1) Failure:
test_long_short_should_equal_50(NameLengthTest) [ljust_test.rb:15]:
<54> expected but was
<50>.
2 tests, 2 assertions, 1 failures, 0 errors, 0 skips
Test run options: --seed 40377

Did you expect that? ljust adds white space, but does not slice off extra characters. What do you think would slice off the extra characters? You got it slice.

If the name is less than 50 we need to add white space to the left. If the name is over 50 we need to slice off the extra characters. If the name has 50 characters we leave it alone. Did we just rewrite our tests?

require 'test/unit'
def nameFixing(name)
  case
  when name.length 50
    name = name.slice(0..49)
  when name.length < 50
    name = name.ljust(50)
  else
    name
  end
end
class NameLengthTest < Test::Unit::TestCase
  def test_name_short_should_equal_50
    name = nameFixing "boo"
    assert_equal(name.length, 50)
  end
def test_name_long_should_equal_50
    name = nameFixing "dgrtefdgdfshrtyutyuykhjkmbnmvcbdfgrthjghjgghvdfgrstthg"
    assert_equal(name.length, 50)
  end
def test_name_50_should_equal_50
    name = nameFixing "dgrtefdgdfshrtyutyuymbnmvcbdfgrthjghjgghvdfgrstthg"
    assert_equal(name.length, 50)
  end
end

Do you think this will pass? Try it.

Now that you have a way to make the name the proper length, we need to continue with the other columns. Did you notice a pattern with the definitions? Alphanumeric or numeric and a certain length.

Why don’t we go ahead and tackle the length of the column. You should just be able to pass in a variable to set that. Try it.

require 'test/unit'
def nameFixing(name,len)
  case
  when name.length len
    name = name.slice(0..(len-1))
  when name.length < len
    name = name.ljust(len)
  else
    name
  end
end
class NameLengthTest < Test::Unit::TestCase
  def test_name_short_should_equal_50
    name = nameFixing "boo",50
    assert_equal(name.length, 50)
  end
def test_name_long_should_equal_50
    name = nameFixing "dgrtefdgdfshrtyutyuykhjkmbnmvcbdfgrthjghjgghvdfgrstthg",50
    assert_equal(name.length, 50)
  end
def test_name_50_should_equal_50
    name = nameFixing "dgrtefdgdfshrtyutyuymbnmvcbdfgrthjghjgghvdfgrstthg",50
    assert_equal(name.length, 50)
  end
end

Now you’re passing in the length we need to set it too. Save and rerun the test. Remember Check yourself before you wreck yourself. I need to practice that too.

$ ruby ljust_test.rb
Loaded suite ljust_test
Started
...
Finished in 0.000863 seconds.
3 tests, 3 assertions, 0 failures, 0 errors, 0 skips
Test run options: --seed 30117

Still green. We can set the the length to whatever we want. We’ve only really worked with the alphanumeric side. For numeric we need to add white space to the left side. We haven’t checked to see if we are adding white space to the right side of the string. Why don’t you go ahead and add that to the test. I’ll wait.

def test_name_should_have_white_space_on_the_right
  name = nameFixing "should be 18", 18
  assert_equal(name, "should be 18      ")
end

Are your tests passing? Cool. Let’s move on to numeric columns. Pretty much the same idea but white space on the left. Here’s my quick and dirty code

require 'test/unit'
def nameFixing(name,len)
  case
  when name.length len
    name = name.slice(0..(len-1))
  when name.length < len
    name = name.ljust(len)
  else
    name
  end
end
def numbFixing(numb,len)
  case
  when numb.length len
    numb = numb.slice(0..(len-1))
  when numb.length < len
    numb = numb.rjust(len)
  else
    numb
  end
end
class NameLengthTest < Test::Unit::TestCase
  def test_name_short_should_equal_50
    name = nameFixing "boo",50
    assert_equal(name.length, 50)
  end
def test_name_long_should_equal_50
    name = nameFixing "dgrtefdgdfshrtyutyuykhjkmbnmvcbdfgrthjghjgghvdfgrstthg",50
    assert_equal(name.length, 50)
  end
def test_name_50_should_equal_50
    name = nameFixing "dgrtefdgdfshrtyutyuymbnmvcbdfgrthjghjgghvdfgrstthg",50
    assert_equal(name.length, 50)
  end
def test_name_should_have_white_space_on_the_right
    name = nameFixing "should be 18",18
    assert_equal(name, "should be 18      ")
  end
def test_numb_should_have_white_space_on_the_left
    numb = numbFixing "123",8
    assert_equal(numb, "     123")
  end
end

Go ahead, try it. Is it green? Excellent but we’re not very DRY.

Time to Refactor.

We con combine the methods and when we need to add white space we could put an if in there for alphanumeric or numeric. Let’s try that.

require 'test/unit'
def allThingsFixing(data,len,type)
  case
  when data.length len
    data = data.slice(0..(len-1))
  when data.length < len
    if type == "A"
      data = data.ljust(len)
    else
      data = data.rjust(len)
    end
  else
    data
  end
end
class NameLengthTest < Test::Unit::TestCase
  def test_name_short_should_equal_50
    data = allThingsFixing "boo",50,"A"
    assert_equal(data.length, 50)
  end
def test_name_long_should_equal_50
    data = allThingsFixing "dgrtefdgdfshrtyutyuykhjkmbnmvcbdfgrthjghjgghvdfgrstthg",50,"A"
    assert_equal(data.length, 50)
  end
def test_name_50_should_equal_50
    data = allThingsFixing "dgrtefdgdfshrtyutyuymbnmvcbdfgrthjghjgghvdfgrstthg",50,"A"
    assert_equal(data.length, 50)
  end
def test_name_should_have_white_space_on_the_right
    data = allThingsFixing "should be 18",18,"A"
    assert_equal(data, "should be 18      ")
  end
def test_numb_should_have_white_space_on_the_left
    data = allThingsFixing "123",8,"X"
    assert_equal(data, "     123")
  end
end

Did you rerun the test? Did they all pass? Brilliant.

How to Handle the Date.

According to the definition, date needs to be yyyymmdd and luckily we are receiving it mmddyyyy. We just need to cut it up and rearrange it.

Will you be able to pass that data blindly into our method? We do know that the name of the column is “accountOpened.” To keep things moving we could pass a column name into the method. Time to write a test.

def test_date_should_format_properly
  data = allThingsFixing "08152003",8,"9","accountOpened"
  assert_equal(data, "20030815")
end

Did you remember to add the new variable you’re passing into the method?

Here’s what I did with the method

def allThingsFixing(data,len,type,column)
  case
  when data.length len
    data = data.slice(0..(len-1))
  when data.length < len
    if type == "A"
      data = data.ljust(len)
    else
      data = data.rjust(len)
    end
  else
    data
  end
end

You can go ahead and run the test. It should fail.

$ ruby ljust_test.rb
Loaded suite ljust_test
Started
F.....
Finished in 0.001405 seconds.
1) Failure:
test_date_should_format_properly(NameLengthTest) [ljust_test.rb:52]:
<"08152003"expected but was
<"20030815">.
6 tests, 6 assertions, 1 failures, 0 errors, 0 skips
Test run options: --seed 25697

Now you just need to reformat the date. It looks like we just need to move the year from the back to the front. Now where should we put this? Since there are eight digits in the column and it calls for eight digits in the output, we’ll put it in the section of its where data.len == len

def allThingsFixing(data,len,type,column)
  case
  when data.length len
    data = data.slice(0..(len-1))
  when data.length < len
    if type == "A"
      data = data.ljust(len)
    else
      data = data.rjust(len)
    end
  else
    if column == "accountOpened"
      data = data.slice(4..7)+data.slice(0..3)
    else
      data
    end
  end
end

There seem to be a lot of if statements. That can be re-factored later. Does the test pass?

$ ruby ljust_test.rb
Loaded suite ljust_test
Started
......
Finished in 0.001030 seconds.
6 tests, 6 assertions, 0 failures, 0 errors, 0 skips
Test run options: --seed 48958

Transmogrification Complete!

How would you get the data into the Transmogrifier? Stay tuned!

In this tutorial I will show you the setup and use of a email-preview gem called Letter-Opener by Ryan Bates. In case you are serious about using Rails and you do not know Ryan’s excellent Railscasts, go watch them.

The gem we are using here makes it really easy to preview your application emails the minute they are sent in development mode.

Tutorial Details

• Program: Ruby on Rails, TextMate
• Gem: letter_opener
• Versions: Ruby 1.8.7+, Rails 3.0.10+
• Difficulty: easy
• Estimated completion time: 1 hour

Introduction

Let’s say you have an Rails application that sends out notifiction emails to a group of users. Action Mailer, which has been completly overhauled with Rails 3, will take care of sending the mails, provided you have configured your application right. But while you’re developing, you might not want to open your mailbox and wait for the delivery of your mails every time you make a change. This is especially true when your are sending out HTML emails and have lots of minor changes. What you need is the possibility to preview your emails quick and easy. That’s where Letter-Opener comes in.

This tutorial walks you through setting up a Rails application quickly, writing the notification-mailer for sending your emails, and shows you how to use Letter Opener to preview them.

Step 1 Setting Up a new Rails application quickly.

Just go to the console and setup a new Rails application:

rails new postbox

We’ll call the application Postbox.

“Throughout the tutorial we’ll be using RVM, the ruby version manager, to create a special gemset to not pollute any other projects.”

Step 2 Install Your Gems

After you’ve created the app, just go into the postbox/ directory and open your Gemfile in your favorite editor. We’re using TextMate here.

Add the letter_opener gem to your Gemfile like this

gem "letter_opener", :group => :development

It’s important to use the :group => :development as you only want to use this gem in your development environment.

“Grouping your gems is highly recommended, so you do not get them mixed up throughout your environments.”

After you’ve done that, run the bundle install command to install the gems. It looks something like this:

Step 3 Setting Up the Delivery Method

After installing the gem, we need to configure it so that Rails knows to use Letter Opener in our development environment. Again, that’s pretty easy. Just one line in the config/environments/development.rb file.

Open it up in the editor and write:

config.action_mailer.delivery_method = :letter_opener

Now everything is set up and we can start writing the code for our notification emails.

Step 4 Writing the Notification Mailer

At the console, type the following command:

rails generate mailer NotificationMailer

Rails will automatically create the necessary files for you.

Let’s step through the files one by one and see what Rails baked for us.

1 app/mailers/notification_mailer.rb
2 app/views/notification_mailer
3 test/functional/notification_mailer_test.rb

notification_mailer.rb

First file that’s been created is the notification mailer. It will take control of the details like addresses and content of the emails. Let’s have a closer look.

You’ll find the default parameter for the sender’s address.

“Note that mailers always reside in the mailers directory .”

First of all, change the default parameters for our application.

default (:from => "info@postbox.tut", :to=>"somelist@postbox.tut")

Now every email you send from this mailer will be sent from and to the default values. You can override this everytime you want to in a specific method.

Next we will write a method (notification_mailer) that will actually take care of sending the email. It takes a parameter that is a hash. First, we set two variables and then tell Rails to send out the email. The subject for the email is set in the last line.

def notification_mailer(notification)
  @notification = notification
  @url  = "http://postbox.tut/"
  mail(:subject => "New Notification")
end

The complete code looks like this.

Views

Next, let’s go to the corresponding views/ folder, where our email templates reside. There are no templates yet, so we’re going to set them up.

Note that we are going to set up an HTML and a TEXT version of our emails. That way we can send multi-part-emails automatically without further effort.

“ActionMailer will automatically send out multi-part emails, HTML and TEXT versions, if you create both files in the corresponding folder.”

Ok, now that we have created the templates, let’s write some code. We want our users to have nice notifications in their inboxes. Start with writing some HTML for this version of the email. The code goes like this:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></pre>
<h1>Notification email.</h1>
<h2><%= @notification.headline %></h2>
<pre>
<%= @notification.content %>
This email was sent out to you, because you are subscribed to the postbox-mailing-list.
If you want to unscribscribe, please use this url: <%= @url %>.

Note that inside the h2 and the following paragraphs we paste in some content through our mailer. From our @notification hash we will fill in the headline and the content of the mail. The link, which can be clicked to unsubscribe the newsletter is set by the @url variable.

Please note, that the @url is set only for demo-purposes as we will not implement the functionality of unsubscribing throughout this tutorial. Let’s complete this part by writing our text-version of the email.

Notification email.
-------------------
<%= @notification.headline %>
<code><%= @notification.content %>
This email was sent out to you, because you are subscribed to the steamengine-mailing-list.
If you want to unscribscribe, please use this url: <%= @url %>.

Make sure that the method in your mailer (notification_mailer) and the name of your views (notification_mailer.html.erb) are the same. Otherwise, no email will be sent

Now we are all done…almost. How do we get the hedline and content into the email? We need a notifications model in our apllication, but first let’s take a short excursion on testing.

notification_email_test.rb

Testing and TDD (test-driven-development) are some of the best things that Rails allows you to do. They help in so many situations, whether you have a large distributed team or code on your own. Let’s spend at some time on testing your mailer.

We’ll be creating a unit test for our postbox apllication that will reside in the test/unit/ folder and will go by the name notification_email_test.rb.

You might have noticed, that we’re not using the functional test, that was created by the generator. Instead, we make up a unit test. This is because we do some basic testing here. I’ll leave it up to you to expand your testing with a functional test.

require 'test_helper'
class NotificationMailerTest < ActionMailer::TestCase
  tests NotificationMailer
  test "notification_email" do
    expected = new_mail
    expected.from    = 'info@postbox.tut'
    expected.to      = 'somelist@postbox.tut'
    expected.subject = "New Notification"
    expected.date    = Time.now
    actual = nil
    assert_nothing_raised { actual = NotificationMailer.notification_mailer(@recipient) }
    assert_not_nil actual
    expected.message_id = '<123@456>'
    actual.message_id = '<123@456>'
    assert_equal expected.encoded, actual.encoded
   end
end

Let’s have a look at the test. First, we include the helper, which we’ll discuss in a minute. Next, a new class is declared that inherits from ActionMailer::Testcase. We’re defining a test here called notification_email, where we create a new email message and give it the necessary parameters.

Next we will create the actual email by using our NotifcationMailer. With assertions, we will check that the email was created properly. We’ll test if anything was raised while creating the email and check that is was really created through the method and is not nil.

By assigning the same message_id to both of the emails, otherwise our next assertion will fail. The last step is to compare both emails with each other. Ok, so we now have three assertions in our code. Let’s check the test_helper.

def new_mail( charset="UTF-8" )
  mail = Mail.new
  mail.mime_version = "1.0"
  if charset
    mail.content_type ["text", "plain", { "charset" => charset }]
  end
  mail
end

We created a method called new_mail that sets up a mail everytime we need it. The method accepts a parameter to set the charset of the email, in case you want to change it. If not, it will always fall back to the default.

We could have done it in the test itself, but it’s these kinds of methods you should put into the test_helper, so you can easily change them on a global level. Now it is time to run the test, using rake.

Ok, obviously we’ve done everything right because the output of our test is

1 tests, 3 assertions, 0 failures, 0 errors

Go ahead and play around with the test. Use another sender-address for instance and see what happens.

“Testing is one of Rails most important features. Use it extensively while you write your code. That’ll help you to save a lot of time while your code is growing and the complexity of the application is rising!”

Step 5 The Notification Model and Controller

Now that we have everything in place to send out the email (including tests!), we’ll setup a nice little interface to write the actual notification and use the mailer to send them.

For the sake of this tutorial, we will use Rails scaffolding. Remember, we had headline and content in our views, so we will implement them here.

rails generate scaffold Notification headline:string content:text

Rails now creates everything we need: the migration for the database, the model, the controller, and the views.

Let’s start up the server:

rails server

Do not forget to migrate the database by using rake db:migrate This will set up the table for us.

Next, fire up the browser and point to http://localhost:3000/notifications. It should look something like this:

Now we navigate to the new notifications page and create a new one by filling out the form.

Success will look something like this. Of course, you should write tests to be sure that everything works fine. I leave it up to you. ;-)

One last thing before we can send the email and see the magic of letter_opener. Hopefully, you still remember that we wanted to find out how to use this gem. We now need to send the email, so we head over to the controller and modify the code.

In the create method we will add one line of code that tells ActionMailer to send out our notification if it was saved succesfully.

def create
  @notification = Notification.new(params[:notification])
  respond_to do |format|
    if @notification.save
      **NotificationMailer.notification_mailer(@notification).deliver**
      format.html { redirect_to(@notification, :notice => 'Notification was successfully created.') }
      format.xml  { render :xml => @notification, :status => :created, :location => @notification }
    else
      format.html { render :action => "new" }
      format.xml  { render :xml => @notification.errors, :status => :unprocessable_entity }
    end
  end
end

After that, create another notification through the web interface. If we’ve done everything right, another tab in our browser should show up and we can preview the email we just created! Voila!

As you can see, you have a great way to preview emails from your application. Now you can go and modify them. As extra credit, try to find out where on your disk the previews are stored. I’m giving you a hint, look in the tmp/ directory or in the address bar of your browser.

I hope you enjoyed learning about letter_opener.  The rails app I used for this article can be found here.

Installation

Sphinx installation on Linux is pretty straightforward. Downloading and compiling from source is a preferred method of Sphinx installation, despite the fact that apt and yum repositories are almost up-to-date.

The newer versions of Sphinx has multi-query support with mysql, and hence it’s better to compile it with mysql development headers included.

$ wget http://sphinxsearch.com/files/sphinx-2.0.7-release.tar.gz
$ tar xvzf sphinx-2.0.7-release.tar.gz
$ cd sphinx-2.0.7-release/
$ ./configure --with-mysql
$ make
$ sudo make install

Once Sphinx is installed successfully, you can install Thinking Sphinx as a gem or bundle it in your application.

$ gem install thinking-sphinx -v "~> 3.0.2"

If mysql is your database of choice, you will have to make sure the mysql2 gem version is either locked at 0.3.12b4 or 0.3.12b5. The earlier versions of mysql2 gem will throw the following exception :

undefined method `next_result' for Mysql2

The error occurs because the previous versions of the mysql2 gem did not have multiquery support, and Sphinx now has that out-of-the-box.

Configuration

Thinking Sphinx has two main configuration files. In the earlier versions, the first file was named sphinx.yml, but has been renamed to thinking_sphinx.yml.

The second file is .sphinx.conf (e.g development.sphinx.conf) and is used to interface Sphinx with the database. Whenever a fresh index is created, a fresh conf file is created which lists all the Sphinx queries based on the defined indices and connection details in database.yml.

thinking_sphinx.yml is an extension of this file where you can pass extra options to improve your search results.

Use Case

Let’s say we have an application with the following models :

• Vendor – name, rating
• Shop – name, description, vendor_id, location
• Product – name, sku, description, price, shop_id

with the following model associations

• Vendor – has_many shops
• Shop – belongsto vendor, hasmany products
• Product – belongs_to shop

We have the following use cases which we will cover in our article:

• Search Vendor, Shop, Product individually
• Search across all models
• Search via asociation
• Define Facets to Create filters

Basics – Definition of Indices.

Thinking Sphinx 3.0 takes a cleaner approach to the definition of indices compared to earlier versions.

To start defining an index, you first need to create a directory named ‘indices’ under the app folder.

$ mkdir indices

Let’s follow our use case and create three index files in our indices folder:

• vendor_index.rb
• shop_index.rb
• product_index.rb

The index file definition includes the name of class on which need to search. It should be the same as the model class name.

The indices for attributes can be defined simply by writing :

indexes column_name

However, there are a few reserved keywords for Sphinx (e.g status). To make these columns acceptable by Sphinx, you would have to define them as a symbol.

indexes :status

According to our use case, let’s write our first index for the vendor model. This will index the vendor name and rating. We will use rating as a parameter to sort our search results for the vendor.

ThinkingSphinx::Index.define :vendor, :with => :active_record do
  indexes name
  indexes rating, :sortable => true
end

Now, while searching for products and stores, we need vendor name to be a common criteria for each search. So, if we need to search for a product called “Batman Action Figure” in the vendor “Marvel Toys”, we could search for it using the vendor name and find all the products related to it. Here is how it is done:

ThinkingSphinx::Index.define :vendor, :with => :active_record do
  indexes name, :as => vendor_name
  indexes rating, :sortable => true
end

Inside our other indexes, the associations are defined as:

shop_index.rb
ThinkingSphinx::Index.define :shop, :with => :active_record do
  indexes name, description, location
  has vendor(:name), :as => :vendor_name
end

product_index.rb
ThinkingSphinx::Index.define :product, :with => :active_record do
  indexes name, description
  indexes price, :sortable => true
  has shop.vendor.name, :as => :vendor_name
end

In both the files above, we have called vendor_name using associations. Shop belongs to a vendor, so we could make a direct call from vendor and call it vendor_name, whereas in product, we called it via the shop association.

Running and Generating the Index

Once, we’re done with writing the indexes in our files, we would need to generate an index and run our Sphinx server.

$ rake ts:index
$ rake ts:start

Searching

Once our Thinking Sphinx is up and running, we can write controller methods to search and display the results.

Running search on individual models looks like this:

@search_products = Product.search(params[:search], :ranker => :proximity, :match_mode => :any)

If you want to create an application wide search, you can call the ThinkingSphinx.search method to define models to be searched. You can tie this to any route and pass the search term as a parameter.

def search
   @search =  ThinkingSphinx.search(params[:search],
                             :classes => [ Vendor, Store, Product],
                             :ranker => :bm25,
                             :match_mode => :any,
                             :order => '@weight DESC',
                             :page => params[:page],
                             :per_page => 10)
end

Ranking uses different algorithms like bm25 and proximity for generating best matches within the search results.

Sorting uses an order field and can be defined to sort the results in different ways. Based on rating, alphabetical, or created_at are just some of the ways it can be sorted.

@weight is a default keyword that contains Sphinx ranking value.

Other Stuff

Field Weights :
We can rank our search results according to different fields inside a particular model:

@search_products = Product.search(params[:search],
                                 :ranker => :proximity,
                                 :match_mode => :any,
                                 :field_weights => {:description => :15,
                                                    :name => 10})

You can also write field weights inside your index files using the set_property rule like this:

:set_property :field_weights => {:description => 15,
                                 :name => 10})

Getting excerpts from the search results:

@excerpter = ThinkingSphinx::Excerpter.new 'product_core', params[:search], { :before_match => '<span class="match">',
 :after_match => '</span>',
 :chunkseparator => ' … '}
 

Adding Facets :

Facet-based search is used when you need to filter according to different classes or parameters. Facet definition can be done by simply defining a facet => true rule against the attribute to facet in the index file.

indexes name, :facet => true

This and then just rebuild the index.

rake ts:rebuild

In your controller, facet accepts the same parameters as search, so your facet would look like this :

 @facets = ThinkingSphinx.facets(params[:search],
                                :class_facet => false,
                                :page => params[:page],
                                :per_page => 10)

If no facets are defined on any model and a facet search is written, it would fall back to class facets, calling the search on individual model classes. You can turn it off by calling false inside your facet rule, as shown above.

You can display the facet results in your view in the following way:

<% @facets[:class].each do |option, count|%>
<%= link_to "#{option} (#{count})", :params => { :facet => option, :page => 1}%>
&lt;%end%><br/>

Searching for partial words can be done using min_infix_len inside your thinking_sphinx.yml or inside your index file using set_property. This means it will match at the least 3 characters before declaring it a match. min_infix_len is not advisable to be kept at 1, as it could be a serious memory hog.

 development:
   mem_limit: 128M
   min_infix_len: 3
 test:
   mem_limit: 128M
   min_infix</em>len: 3
 production:
   mem_limit: 128M
   min_infix_len: 3
 

Delta Indexes

Sphinx, by default, runs indexes from scratch everytime you run and index command. In order to avoid Sphinx starting from scratch, we can define delta indexes. This will only index the documents that are newly created.

  set_property :delta => true

Conclusion

Thinking Sphinx 3.0 brings along a lot of advancements and bug fixes from previous versions. It takes a very clean approach, placing the search code outside your app models. Therefore, as queries start getting complex, the code remains readable.

Hopefully, this article has inspired you to give Thinking Sphinx a try in your application.

But, is it being really effective? In fact, the majority of ranking implementations are wrong, and can even make your application less attractive. It’s difficult or downright impossible to reach the top spots and you may never find a real challenge against other users. Those are just some of the problems when talking about Rankings.

Many big compaines, such as Sony, Microsoft, and Nintendo, have experimented with algorithms to make rankings more dynamic and attractive. Lots of great implementations have surfaced from those companies, and we are able to use them in our development processes.

Rankings

What is the Proposal?

The mathematical description of a ranking is quite simple, as you can see at Wikipedia

“A ranking is a relationship between a set of items such that, for any two items, the first is either ‘ranked higher than’, ‘ranked lower than’ or ‘ranked equal to’ the second. In mathematics, this is known as a weak order or total preorder of objects.”

A ranking by itself is quite easy to implement, basically sorting a number of items according to some criteria, but what is the purpose of a ranking?

A ranking is not only an opaque information, it’s being used on games and applications to engage users to improve themselves and achieve higher positions, usually competing against each other.

What often happens is the early adopters will reach the top of the ranking really fast, and improve so much that it will be too difficult or even impossible for new users to surpass them or even try to challenge someone with the same skill level.

So if you were trying to make your application more attractive with rankings, chances are that you have failed! No one wants to enter in a competition where it is impossible to actually compete.

But how can we make rankings something more interesting, to transform this old social technique into a powerful tool to keep users engaged? That is our goal and the real purpose of a Ranking implementation.

Making Rankings Effective

Think about a ranking as an piece of data. Data is essentially good and when you have it, you have power. It isn’t just about sorting items, it’s about building an application that fits every level of each user’s needs.

The idea is that, if you have a ranking, you have a resource.

For example, when ranking users, the parameters can change as the user progresses. Those changes can be the interactions between each other, but the condition to change those parameters and get a higher or lower ranking must be compatible with the resource skills and current position.

It’s quite simple and when I thought about the essence of it I came up with the following short list that defines the purpose of a ranking:

• Organize and order a resource.
• Make it possible to change positions.
• Find challenges/conditions that are compatible with the user’s current rank
  and skills.

It certainly doesn’t sound too difficult, but when it comes to technique, it is. But don’t worry; because big companies are working on this for us.

The best solution that I’ve seen so far is the one that Microsoft Research team researched and developed, known as True Skill

True Skill

Microsoft has published a lot of research related to the new business areas that it has ventured into in the past few years, such as the game console market. The Xbox is one of the most incredible devices on the market right now and its updates and features are always bringing innovation. One of those features is the True Skill ranking system.

“TrueSkill is a Bayesian ranking algorithm developed by Microsoft Research and used in the Xbox matchmaking system built to address some perceived flaws in the Elo rating system. It is an extension of the Glicko rating system to multiplayer games”

TrueSkill was developed based on the Elo Rating system, one of the most well known algorithms, that is used in a lot of different ranking tools; it was the initial implementation of statistical estimation on rankings.

It matches the short list that I mention above. It not only sorts users, but it also make it dynamic, providing challenges that fits the skills of every user.

How it Works?

The basic idea and a basic implementation of True Skill is that every resource has two variables: One that represents the perceived resource skills, that we will reference by using the letter S, and another one that represents how much ‘confidence’ the system has in the S value, that we will reference by using the letter C.

A default value for S and C have to be defined in order for new resources to have an initial position in the ranking. In Xbox Live, the default values are S = 25 and C = 25/3. The S value will increase or decrease after every win or loss, but what will make the difference in the resource position is the value of C and how “surprising” the outcome of the challenge is to the system. So, if the outcome is actually the expected result (the favorite player wins, for example), it will not produce a huge increase in the user’s position.

A Resource rating is estimated by using the following formula R = S – 3 * C. The True Skill system can be applied with any scale, in Xbox Live it’s using a 0 to 50 scale.

This is just the beginning of the concepts behind True Skill. There are a lot of details when thinking about all possible results. A draw, for example, or a competition between various players at the same time.

There are some peculiar results that are quite interesting when using True Skill, for example an initial loss can actually make a user achieve a higher position on the ranking, because the C may have a bigger loss then the S variable. Let’s see an example:

Example

Imagine a new user, “John”, on Xbox Live. We can assume the S = 25 and C = 25/3, so John’s rank would be calculated as R = 25 – 3 * 25/3, resulting in a rating 0.

In the first challenge, the system is expecting that John will win, but he actually loses. His skill level will decrease by 5, resulting in S=20. It was not the result expected by the system, so the system doesn’t have much confidence in this new skill. This will result in a bigger loss of the C variable, for example C=15/3.

The thing is that John’s rating result will be higher then the initial one. Losing his first challenge results in R = 20 – 15 = 5, because the system does not believe that the loss represents John’s correct skills measure. However, if John keeps losing, the confidence of a smaller skill will increase, resulting in a huge rating loss.

What and How?

Rankings are not only about competition between users, as you can measure anything that you want. Having a good ranking will help you to find out what better fits any position.

You can rank your users and, depending on their spot, offer different features, interfaces, and ‘customizations’ that better fit their skills and how they interact with your application. The rule is simple, if you can rank something, you can make it more personal to everyone.

The whole True Skill implementation is not available on the web, it’s patented by Microsoft and can only be used if a license is acquired. But derivations of it, such as Glicko rating system are free to use. Unfortunately, there is just one implementation of True Skill system in Ruby that I’ve found on the web and it’s not completed yet. But, you can find a lot of Glicko and Elo implementations in other languages.

Right now, I’m implementing a derivation of the True Skill system in Gioco. I’ve opened an issue on github to add this feature in the next release, so it will be easier to have a correct and good ranking implementation in your application that will help you to engage your users. Stay tuned!

There’s several editors, IDEs, etc. that all have excellent Ruby support aimed at keeping you operating at maximum “output” (I’m not one of those crazy managers that measures this output with lines of code, so, you get to choose how to define it). In this article, I’ll go over the advantages, disadvantages and odd points about each of them, from my perspective (read: the article is biased, but, my opinions are correct so it doesn’t matter :P).

Let’s open with a classic.

Vi(m)

Vi came to be in the days when bandwidth was small and people were patient with their computers. It ran inside your terminal/console, just nibbling on your memory and processor. The featureset was meant to be limited – it accomplished a few tasks, but it accomplished them pretty darn well. However, the limited featureset did not mean that it constrained you. With its simple and composable commands, vi became a favorite for those who cherished simplicity but needed flexibility and power.

Vi’s development gradually fell apart, as various people moved around in the project. But, fear not, because Vim was invented! Vim is a modified version of vi that is meant to offer a larger featureset while still remaining true to the vi vision of simplicity and respect of the power user.

So, what has vim got do with Ruby? Well, here’s where it gets a bit complicated.
Vim itself doesn’t really have any features specific to Ruby (aside from syntax highlighting), but Rails/Ruby hackers have always placed the console above a GUI in almost all of their decisions as a community. Vim fills that specification perfectly. In addition, vim has a number of extensions (NerdTree, ctrl+p, vim-rails etc.) that make working with Rails/Ruby applications pleasant.

There’s also nothing quite like watching someone experienced with vi(m) work – fingers flying across the keyboard, where seemingly half the characters typed seem to be inserted by vim itself. For those that do prefer a regular GUI for an editor, vim also include GVim, which is a version of vim using GTK (an interface toolkit).

But, vim is not all fun and games. Vim is a modal editor, which means that you can’t just go ahead and start typing and expect to be comfortable – there’s a pretty steep learning curve. There are three different modes: insert, visual and normal. Insert is one where you can type, visual is where you do things like select bits of text and the “normal” mode is where the keystrokes comprise vim commands. Getting used to this sort of arrangement can be really annoying, especially if you’re someone that has worked with IDEs and expect Ctrl+C to copy and Ctrl+V to paste (more on that later). One of the most annoying things about the whole modal arrangement (for me) is changing between modes. To do that, you have to hit the escape key. When you first hear of the concept, modes seem like something seldom used. The reality is, you change between modes all the time when using vim, and you have to move across your finger to the escape key EVERY SINGLE TIME. This is especially a problem for me since I have incredibly small hands; might not be an issue for some of you.

Then, there’s the command syntax. You get used to it pretty quickly, but it’s mostly devoid of “Ctrl”s and “Alt”s, using largely the alphabet (that’s why there’s the normal mode). Copy and paste seems incredibly complicated when you first start out. There are terms like “buffers” and “registers”, which you thought you’d never come across when trying to figure out how to use a text editor (of all things).

All in all, vi(m) is awesome if you can adjust yourself to it. Doing that is going to take at least some effort as well as a degree of determination to force yourself to keep using it (a bit like learning touch typing – there’s not much point unless you do it all the time). Additionally, if you’re coming from an IDE, don’t expect some IDE-like features such as it underlining all the errors for you – vim isn’t meant to do that (remember, simplicity is key!), so don’t expect features specific to e.g. Rails.

Emacs

Of course, now that we have talked about vim, so it is absolutely necessary to talk about Emacs.

I haven’t used Emacs all that much, but it does have some pretty nice Ruby support from the community. I’ve heard of a few who are quite happy with Rinari, which is an emacs mode for Rails in particular. There are many extensions that make Emacs more suited to Ruby development, such as test-runner, which is meant to be used with RSpec, Test::Unit, etc.

From what I’ve used of it, there seems to be far less support for Rails/Ruby (i.e. fewer people using it) than with Vim or Sublime Text 2 – this might be a problem if you run into trouble setting stuff up. Personally speaking, my tiny paws can’t keep up with the Ctrl and Alt shortcuts of Emacs, so I’ve stayed fairly clear of it. But, if you’ve used Emacs for other projects, there’s no harm in giving it a whirl for Ruby.

If you’re starting afresh, try both Vim and Emacs without installing any extensions, see what you like better. Once you’ve chosen one, write several blog posts insulting those who use the employ the other editor – it seems like a “coming of age” ritual, judging from the sheer quantity of such posts.

Sublime Text 2

This is one that I’m pretty excited about, especially because it is a nice GUI editor that doesn’t have so much stuff piled on it that it starts looking like Eclipse (shudder that brings back memories from Java). It’s comprised of a perfect middle ground between something like vim and a full-blown IDE.

I often find (especially when working with larger projects) vim starts to feel a little bit inadequate in terms of just coping with so many files. Switching between NerdTree (a file explorer) and the editing window feels tiresome, and typing in filenames into the “ctrl+p” extension even more so. This is where Sublime Text comes in. It is a GUI kind of deal, so if you need to work over SSH or something (I don’t know, maybe your company thinks Git and Puppet are for heretics) that might not work out.

First thing you notice is the clean and simple design – its just the editor and a file tree. I find this to be incredibly helpful in comparision to the Eclipse way of doing things where every thing under the sun that has anything to do with Java has a place somewhere near the editor. You might notice a small box at the right side of the editor – this the marvelous mini-map. It lets you know where in the source code you are (opening up a longer file will make this clear.) This is incredibly helpful when you’re moving up and down the source code hunting for that one variable that keeps setting itself to “false”.

ST also has a sensible and human-operable (without much effort) tab scheme that just works without getting in your way, unlike vim. ST doesn’t try to hide you from the “horrors” of the Terminal application (unlike most IDEs) – it simply “coexists”.

There’s a few downsides. First of all, if you are a hardcore vim user already, getting used to the new shortcuts is a little bit annoying. Secondly, if you are looking for an IDE, keep reading, because this isn’t one. Also, after you complete your evaluation of the product, you have to dish out a bit of cash to keep using it (although there’s no real time limit for evaluation).

Aside from that, I’m a really big fan of Sublime Text 2 and I like the direction that the project has taken.

RubyMine

This is the one I’ve had least experience with, but I like what I see. RubyMine is a complete IDE meant for Ruby and Rails. Filled to the brim with code completion, Javascript/Coffeescript support, git integration and a pretty cool GUI test runner. I’ve typically moved away from IDEs in general, but, RubyMine is really quite interesting. It doesn’t seem to suffer from the same issues as Eclipse and Netbeans (just too much stuff one screen) and has pretty awesome support.

But, of course, it is an IDE. That means that, if you had rather work in the console than anything else, you might not like it. It is also not the most customizable IDE in the world (as far as I’ve found), so if you want all the Eclipse plugin magic, it might be a disappointment.

Regardless, I think it is a great option and if you’re willing to let loose a little moo-lah, it might just work out.

Wrapping it up

Hopefully, you enjoyed my summary of some of the tools that Rubyists use to get stuff done. The easiest way to develop an opinion about one of these is to pick one, get thoroughly acquianted with it, and then try to change it up. If the change feels good, you might have found a better option. If it doesn’t, just roll it back! For extra points, write blog posts making fun of editors you don’t like and the people that use them.