This comes up in games like Plants vs Zombies, or Doodle Jump, where the first two minutes of each are nearly no challenge at all.

I’d like to pass a certain checkpoint (something fairly hard) and never have to play the easy stuff again. You’d just start right at the hard part. Multiple checkpoints at increasing difficulty might be even better.

Blizzard seems to agree with this: in Starcraft 2, all players start with six worker units already built. No one has to prove they can sit there for two minutes building drones to get to the interesting stuff.

Apps that do this show respect for my time, which helps me love them.

The First Commandment of vim is “Thou shalt not use the arrow keys, for they be too far from thy holy home row. Use instead the blessed h, j, k and l.”

A noob does not know his motions.

When a noob deletes a word, he holds ‘x’.

When a master deletes a word, he taps ‘dw’.

A noob should learn the motions granted him by w, i, t, f, and a. His practice would be guided well by the writings in ‘:help motion.txt’

A noob does not know the ‘.’ command.

And great is his needless suffering.

A noob does not record macros.

A master’s q key is well-worn.

A noob writes Rails code with vim, unaware of this screencast.

A master does not hesitate to share his awesome content.

1. It’s all about your portfolio app

It’s important to build a Rails app that an interviewer can access and play with. The best way to prove you understand something is with working code. Even a simple Rails app demonstrates that you’ve grasped a whole host of technologies and concepts: databases, Ruby, Rails, ERB, HTML, CSS, deployment, and others. If you’re brand new to Ruby and Rails, I recommend the following path:

1. Read this book; I think it’s the best out there. However, like most programming texts, you shouldn’t only read it. Instead, follow along and actually create the example application. Along the way, think of some simple exercises and do them. You will learn and retain vastly more this way.
2. After you’ve read a good chunk of the book, choose your portfolio app. Pick something small, as even basic applications will provide plenty of challenge at this point.
3. Once your new app is working, use it as your experimenting ground. Try out a bunch of plugins and gems. Switch from Test::Unit to RSpec. Try out a fixture replacement like factory_girl. Tinker with a variety of code.
4. Now, grab a couple of job descriptions for Rails gigs that you might want. Each should have a list of technologies they use. Go down these lists and note which topics are both popular and unfamiliar to you. This list will include things like jQuery, TDD, and git. Spend some time implementing/adding these to your app. You don’t need deep mastery of these topics, just familiarity. Your goal should be the ability to have an exchange like this — Interviewer: we have a whole bunch of jQuery, have you used it much?  You: well, not a lot, but I did implement drag and drop and a few visual effects in my FooBar application.  You’re trying to convince the interviewer that you’re capable of teaching yourself new things. If you can do this, they’ll think you’ll be fine with their guidance.

2. Get thee to github

If there were an official tool for sharing Ruby code, Github would be it. You should absolutely have an account there and should aggressively publish code you write. At the very least, the code for your portfolio app should live there (in a public repo). You should also ‘watch’ a few repostories and ‘follow’ a few programmers that interest you. Reading commits made by others will expose you to common Ruby idioms and style.

3. Start attending a Ruby meetup

This is the best way to hear about opportunities. They’re guaranteed to be local, and you’ll know your future coworkers attend Ruby meetings, which is a great sign. Not only will you hear about more jobs this way, but when you do apply, your resume will be coming through an employee that has already met you. This is the best way for your resume to reach a company.

Beyond hearing about open jobs, Ruby groups are a great way to find a mentor. Most people are quite willing to help new Rubyists with their questions, and getting your code reviewed by an experienced programmer will quickly improve your chops. To start, simply ask someone to point out the worst parts of your code, and outline how they’d fix them.

Questions I’ll Pretend Are Frequently Asked:

Is the Rails market really that hungry for talent?

Absolutely. At my last Boston.rb meeting I heard of 4+ open gigs. The position I hold now had been open for months before they decided to take a junior guy and train him. Everybody seems to be hiring.

Is it worth trying to break into the Rails?

Definitely!

Ruby is a wonderful thing to work with every day. I love my language.

You’ll also be joining a wonderful community.

So will these tips work for me?

Maybe. They did for me! I managed to land a Rails job that I love after only a few months’ hard work. You gotta put the work in, but if you focus it in the areas above you should get a great return on that investment.

As an anecdote, I recommended the steps above to a close friend. After a few months of hard work, he landed the first Rails job he interviewed for. He’s now working for a great startup in Harvard Square and loving it.

How can I increase my chances even further?

Well, if you like, you can hire me to coach you. Here’s what we’ll do:

1. Two one-hour coaching sessions. (All sessions take place on Skype or phone). We’ll chat and find out where you are technically and how you well you’re marketing yourself (what do I see when I google you?) If you need to brush up on your Rails knowledge, I’ll point you to great resources to ensure your fundamentals are solid. If you’re lacking a public presence, I’ll help you with that too.

2. Two one-hour code reviews. I’ll review any Ruby code you like and we’ll discuss over the phone. We’ll make sure your portfolio app uses the framework correctly and contains good, Rubyish code. Most importantly, I’ll make sure you really understand all the changes I suggest so that the code stays “yours.”

3. A one-hour resume review. It’s a tricky thing to write a good resume when you lack relevant experience. You’ve got to emphasize things you’ve done while gracefully acknowledging areas you’re still improving. I’ve got some great tricks for this, and we’ll edit your resume together. When we’re done, we should have something that will make people pick up the phone and call you.

4. A one-hour mock interview. Finally, I’ll run you through a standard phone screen for a Rails position. After, I’ll give you the honest feedback that you’d never hear from a real hiring manager who’s afraid of litigation. We’ll talk about any red flags or questions you botched, and how to handle them better in the future.

If you’re willing to put in the work, the end result should be an offer letter (or two, or three!) for your first Rails job.

Why should I hire you?

I love teaching! (And I’m good at it). I’ve sold hundreds of Rails-related screencasts, given a training class with thoughtbot, and had the sixth-highest-rated RailConf talk this year.

How much?

You’ll see the sessions above total up to 6 hours. Now my normal hourly rate is $150, which gives a price of $900 for everything. However, I’m going to be offering a discount from my normal rate because, frankly, I think this is going to be a lot of fun: I LOVE helping bring new Rubyists into the fold, and I really get a thrill out of teaching. As such, the program will cost you only $599. A small amount when you consider how much impact a new job can have on your happiness.

Now $599 is a pretty steep discount off my normal rate, but it’s still a decent chunk of change. I don’t want cost to be prohibitive, so let’s do this: you can start the program for just $199. I’ll trust you to pay the remainder when you can, and not until you’ve seen that our relationship and program are worth it to you. If at any point you don’t feel like you’re getting good value, I’ll refund your $199 with my apologies and absolutely zero hassle.

Let me tell you, working with Ruby and Rails is a TON of fun. The technology is first-rate, and the community is second-to-none. It’s really a blast to be a Rails programmer. If you’re stuck in some lame programming backwater, or are having trouble landing a programming job at all, this could be a great investment in your career.

Now this program will be time-intensive, so I’m going to limit the number of mentees I’ll take on. One slot has sold already, leaving only 3 at the reduced price, so sign up soon!

On the other, you have this: Steve Jobs is Willy Wonka.  He won’t let you inside his chocolate factory and he is unreachable from the outside world.  The factory is cloaked in secrecy.

And then come demo days, when we all get to see something delightful.There’s something a little bit special about this experience, and I’m not sure I want it to change.  A commenter on Hacker News mentioned that he was disappointed to have seen the 4G prototype before its official release, and I know what he means.

I think I’d like to see a more-open Apple, but I can’t help but enjoy a helping of the big reveal.

“I’m not going to go on until every single person in this room [has] come to love and understand classical music. Now you notice that there is not the slightest doubt in my mind that this is going to work. It’s one of the characteristics of a leader that he not doubt for one moment the capacity of the people he’s leading to realize whatever he’s dreaming.

I’m going to be weaving this idea into my upcoming talk at RailsConf.

I have a goal for my audience, and will show no doubt that they can achieve it.  Then, I’ll make sure they do by giving them the means in my talk.

Since then, I’ve sold 148 copies of that screencast at $9 each.  After expenses I’ve been left with over $1,200 of profit.  Honestly I’m extremely pleased.  For my first crack at this, this feels great.

I was inspired to try this venture thanks to the inspiring and informational writings of others.  As such, I feel compelled to share the little I’ve learned, so that other entrepreneurs might enjoy the same benefits I did.

Be warned: the title of this post is admittedly a false promise.  I’m not sure if doing what I did will let you sell a hundred screencasts (or any, for that matter).  I only know it worked for me, and that I hope it will work for you too.

Things (I think) I did right

I chose a topic in which I was already an expert.

On my product page, I tell people “I spend every day writing Rails code in vim, and I’ve optimized the heck out that process. The screencast contains the best of what I’ve learned for creating and editing Rails code at top-speed.”

That stuff is true!  I work full-time as a Rails developer, and I’ve been a vim user for several years.  I’m also a nearly compulsive optimizer (I’ve aliased ‘ls’ to ‘a’ because it saves me a keystroke).  After a year of honing, my editor and environment are extremely customized to support the sort of programming I do.  I’ve shared these tips with others, and seen the subsequent boost in productivity they had.  When I was brainstorming possible screencast topics, this was an easy choice.

I let someone else worry about the infrastructure.

My site runs on Shopify, accepts payments through PayPal and Google Checkout, and handles digital delivery with Fetch.  I set the entire thing up in maybe three hours, and it requires literally no action from me to process orders–I just get the best email ever when it’s complete.  Using these services let me focus on what was important: getting my product out the door.  You ain’t done jack until they can pay for it.

I made the best damn product I could.

I probably spent 50 hours creating my first screencast.  I dragged myself to the office on weekends so I could focus better.  I tried really, really hard to make something useful.  So far, it looks like I did: feedback has been overwhelmingly positive.  I have no doubt this was the most important element of my success.

Things I screwed up (an extremely incomplete list)

I didn’t realize how valuable other peoples’ reviews were.

My first attempts at marketing involved sending emails about my screencast to ruby group mailing lists.  This got me my first handful of sales from several different lists.  In one of the them, a member replied that he had bought the screencast and found it well worth $9.  I made ten times as many sales to this list as the others.

Through dumb luck, Peter Cooper (really nice guy, by the way) saw a tweet about my screencast and offered to write a review on Rails Inside.  I figured this would be good for sales, but wouldn’t have guessed that 40% of my people purchasing my screencast would come from this review.  Oh, and another 30% from this other review, published a short time later.

I’m starting to think the second-best thing someone can do for me is to buy my product; the best is to write a review of it.

I didn’t show an early draft to anyone.

Several reviewers and survey respondents felt the very first section of the screencast went on too long.  The consistency with which people mention this suggests that I could have gotten this feedback by soliciting just a few reviews before launching.

Things that surprised me

I’m surprised by just how good it feels to get ‘new order’ emails.  I’m surprised by how bad it feels on days when I don’t get any.

I’m surprised by how many non-Americans are buying my screencast.  Overall, 59% of my orders have been outside the US, primarily to Australia, Brazil, Germany and Great Britain.

I’m surprised by exactly how much work is involved with actually shipping, and how it all feels worth it when I do.

The next thing

Inspired by my success so far, I’ve released my second screencast! It’s called Building a File-Upload App with Rails and S3, and I’m extremely pleased with how it came out.  I’ve used everything I’ve learned from my first screencast to make this one even better, and overall I think it’s quite polished.

Speaking of learning from the past: if you’re a blogger willing to write a review, email me and I’ll send you a free copy.

Being a capable programmer, he “took an evening” and wrote up a Ruby library to replicate this functionality.  Then he extended vim with a plugin called fuzzyfinder_textmate that called out to this Ruby library.

The results were terrific, and fuzzyfinder_textmate is my go-to solution for opening files in vim.  I almost never type “:e …” anymore.  I’ve yet to see anything faster at grabbing a file buried somewhere in a directory tree. This plugin is particularly useful for me when working on Rails projects, where vim’s ‘current directory’ is Rails.root, and everything I want to open is down at least one level.  If you’re not familiar with the plugin, here’s a silent-movie-style screencast Jamis put together when he released it.

Sadly, this terrific plugin has a bit of a problem: it’s a pain in the ass to install.

Jamis’ fuzzyfinder_textmate relies on a second plugin, called fuzzyfinder.vim.  The author of this plugin makes frequent changes, which usually end up breaking fuzzyfinder_textmate.  This got to be too much for Jamis, and he officially dropped the project a year ago.  Today, the latest versions of these plugins won’t work together.

However, thanks to several contributors and github’s forking, you can get this big mish-mash of libraries and plugins to work…provided you install exactly the right versions of each.  It’s a trifle annoying, but fortunately I’ve done the homework for you.  Follow the steps below and enjoy my favorite bit of vim functionality.

Installing fuzzyfinder_textmate:

1. Make sure you’re using vim 7.2 (the latest, as of this writing).  It’s possible earlier versions work as well, but I can’t confirm these steps will apply.
2. Make sure the vim you installed was compiled with ruby support.  Check this by running vim –version | grep ruby at the command line.  A result of +ruby means you’re good, -ruby means you DON’T have ruby support.  Debian/Ubuntu users can get a ruby-capable vim by running sudo apt-get install vim-ruby.  Another test to make sure you’ve got ruby support: type :ruby in vim.  Argument required is good.  Not an editor command: ruby is bad.
3. Install Jamis’ fuzzy_file_finder Ruby library from here.  This is installable as a gem, but I strongly recommend simply git cloneing this repo, creating a ruby directory in your .vim folder, and placing the lib/fuzzy_file_finder.rb inside there.   This keeps this dependency in your .vim directory (rather than on a system gem you’ll forget about when you change servers), and enables keeping your vim configuration in a git repository (HIGHLY recommended).
4. Install vim-fuzzyfinder version 2.22.3.  IMPORTANT: you MUST use this exact version.  Other versions (particularly anything NEWER than this one) will NOT work.  After installing, confirm it works by running :FuzzyFinderFile in vim.  You should get a pop up box with a list of files.  If you do you’re almost there.
5. Install fuzzyfinder_textmate, but use sethbc’s fork from github.  Don’t use the version from Jamis’ repo as it will NOT work with the version of fuzzyfinder.vim we installed.  git clone again, and simply put fuzzyfinder_textmate.vim in your .vim/plugin folder. To test that everything worked, run :FuzzyFinderTextMate in vim.  If you get a popup box, you’re done!

If you’re having trouble, the most common culprit is that you’ve mucked up the versions.  This collection of files is quite finicky, and if you’re using the wrong version of any one things fall apart quickly.  After that, double-check you’ve got Ruby support.

If you’re still having trouble, do a git clone of my dotfiles.  My setup is confirmed working, so you can diff your copies of the library/plugins against mine.  Any differences mean you’ve got the wrong version.

If you still have issues, leave a note in the comments and I’ll try to get you sorted out.

Finally, if you found this post useful, I’d urge you to check out my screencast: Vim for Rails Developers.  In it, I’ll teach you the best plugins, external tools, and editing tricks for writing Rails code at top-speed.  If you write Rails code in vim, it’s sure to save you time.

They look like this:

Factory(:user) do |u|
 
  u.after_create { |user_instance| do_something_to(user_instance) }
 
end

Now, when you use Factory(:user) in your tests, the do_something_to method will be called after the user is saved in the database.  Also notice that you’ll be passed the instance of the user as block parameter.

There are two other callbacks now available: after_build and after_stub.  Their callbacks fire pretty much where you’d expect them to.

You can mix and match these callbacks on the same factory.  Multiple definitions of the same callback will be executed in the order you provide them:

Factory(:user) do |u|
 
  u.after_build { |user_instance| do_something_to(user_instance) }
 
  u.after_create { do_this_after_create }
 
  u.after_create { then_do_this }
 
end

I’m excited about this addition because of how much more flexibility this gives factory_girl.  There are some kludgy parts of my factories.rb files that will be more elegantly accomplished with these tools.

Accepting these little lambdas to be run later feels very lispy, something I take as a great sign.

For more usage details, check out the ‘callbacks’ section of the README.

And, if you’d like to read more about using Ruby’s blocks this way, Greg Brown has an excellent article on the topic (excerpted from his also-excellent book).

I also can’t stand reading code on the site.

Why?  Frankly, the text is plain old ugly:

Those italicized comments look like faintly-etched glass.  And the bolded bits look clumsy as well (check out the ‘m’ on ‘module’)!

What’s with the ugly?  Let’s ask Firebug:

‘Bitstream Vera Sans Mono’?  Never heard of it.  Haven’t got it installed.  If you’re on Windows or OS X, you probably don’t either.

Okay, so I haven’t got Bitstream, so it looks like we’re falling back t–oh my GOD it’s COURIER.

Yes, Courier.  Invented in the 1950s.  For typewriters.  I think I last used this font while editing GORILLA.BAS to mess with the speed and gravity.  No one should be using Courier anymore (unless you’re writing a screenplay).

Fortunately, there are two easy ways to fix this.  The first, you and I can do.  The second will have to be done by the Github guys.

What we can do: install Bitstream Vera Sans Mono.

Download it here.

Installation is OS-specific, but I bet you can figure it out.

Here’s how things look after the install:

Sweet mystery of life at last I’ve found you!  This is about…a billion times more readable.

Now, the experience of not having their first-choice font shouldn’t have been so painful.  If you’re going to lead with a talented but fragile rookie, make sure you have a dependable second-string something something sports analogy.

Anyway, the Github guys should change ‘Courier’ to ‘Courier New’ in their stylesheet. Courier New is an updated and refreshed grand-child of Courier, and it’s far more readable, especially when bolded or italicized.  Plus it’s just as widely installed as Courier.

Little change on our side.  Little change on their side.  Code looks beautiful; everyone’s happy.

Github — no longer a butterface.