Schneems

I thought I was spoiled when I worked for Gowalla, but Heroku appeals to my true inner Geek. The people, the building, and the oh-so-delicious food have blown my mind. It’s impossible to turn the corner without bumping into some of the best minds in the community. Where else are you going to find yourself walking to work with @hone02, a maintainer of Bundler, and playing pingpong after lunch with @bmizerany, the creator of Sinatra. The knowledge isn’t just Ruby, there’s all sorts of Java, Python, and even a little Erlang getting thrown around. You can tell everyone loves working on the Heroku platform by the way they talk about it, and the passion they have for their jobs. I haven’t run into Matz, the creator of Ruby, since he joined heroku, but I can’t wait to give him the super-secret Heroku staff handshake (it’s just a regular handshake).

While I’ve been working for Heroku for a week now, today was my first day working out of SF. The offices are great: fully stocked fridges, catered lunch, a games room, and Mac power adapters all over the place. It almost makes me wish I wasn’t working out of Austin (almost).

The building is old fashioned brick, with massive steel girders and origami all over the place. Seeing how intimate and friendly the lunches are it’s hard to remember just how many people work here. Getting to put faces to names has been great, and it’s one of the reasons I enjoy going out to events and attending conferences.

Before I flew out to the office, I got to attend my first event as a Heroku employee. On Saturday I helped out with APIHackDay Austin. It was a great reminder of why I started programming and took this job in the first place. Seeing a small team or lone developer toiling on some crazy app is really a thing of beauty. I can’t wait to help out with more events.

We have a ton of great things coming out of Heroku in the future that I can’t wait to talk about. If you catch me at a user group or conference, say “hi” and you might just get a sneak preview. If not, I’m at least good for a cup of coffee or a cold pint.

^_^

When Gowalla was acquired by Facebook I wrote that I was talking to companies in Austin and California in Should I Stay or Should I Go. I’m happy to announce that I’ve made a decision on where I’m going next.

Now you must be wondering… is it Austin, is it California? Actually it’s both. I’m starting work today for Heroku which is in San Francisco, though I’ll be staying put for now in the live music capital of the world, Austin Texas!

Heroku first launched as I was just learning to deploy my first Rails application. They were the best and easiest back then, and still are today. I’m excited to be joing such a great team and working on such an amazing platform.

Keep a look out for future posts on my insider experience with the Heroku!

I’m teaching a beginner ruby class. If you’ve ever been interested in learning Ruby this is a hands on class with no experience and no software required. Class is this Wednesday the 15th at 7pm in downtown Austin.

If you’ve never taken a class at Hourschool before, it’s a peer-to-peer learning platform that lets anyone teach and take classes. It’s been a fun way to meet people in the community and pick up some skills too. Even if you’re not into programming they’ve got lots to offer, from cooking to color design. Forget going to a boring movie next week, learn how to make bagels with real live people instead !!

P.S. Hourschool runs on Heroku and I helped build it (in Ruby of Course)!

Remember that great presentation you gave at that user group? What about that one at the conference, you know the one everyone loved. What if your presentation wasn’t limited by the number of seats in the room or badges sold at a desk. What if, and this is a bit crazy, you could use some sort of electronic device to record your presentation and share it using a series of connected tubes.

Well now you can!! It is so simple to record your presentations as screencasts you have no excuse not to. Check out this quick video on how:

Quit waiting for con-freaks to show up at your house and beg you to record your material. Give the people what they want. All you’ll need is.

• A Mac
• Quicktime
• A Presentation

Thats it. Quit reading and go record something.

Do it now!!!

Today a lowly programing peon fails a devious whiteboarding interview torture trap! After candidate leaves, the interviewer asks their colleges, “why are there no good programmers available?”. Well…

Recently I’ve heard two common complaints, first from companies looking to hire not finding talent, and the second from programmers looking for new jobs only to find a degrading, demoralizing, and difficult interview process (re: @bascule’s “Can you solve this problem for me on the whiteboard?”). If you don’t think these two trends have something to do with one another, think again.

I’ve been interviewing a fair bit since the Gowalla announcement. While I don’t mind the psycho-crazy-double-link-list-recursive-binary-tree-fizz-buzz-sorting-matrix-manipulation—whiteboard questions, they’re not my favorite. In fact, they’re no-ones favorite questions. Instead I appreciate interviews that focus on the position I’m applying for and have done adequate research into my background. As a general rule of thumb if you’re an interviewer, don’t as me a question that you wouldn’t mind me asking you.

Interviewer: “Do you have any questions for me?”

Me: “Yes! Given a singly linked list …”

If I did that to an interviewer they would think I was joking or be offended. Why would I not think the same?

So we all agree, whiteboarding questions aren’t the holy grail of interviewing techniques, instead here are a few things companies have done that I prefer and feel they gave a greater insight into how I would perform on the job.

Pair Programming

The first alternative, is pair programming. Pick a real problem, it can be open source, or it can be from your code base, as long as the interviewer and the candidate can understand and work on the problem in under an hour (or more depending on the length of the interview). Why do I like this method? It shows how I really work, and answers quite a few questions about how the company works. We get to have a real conversation about a real problem using real programming tools and hopefully do some real work. Doesn’t that sound great? But there are some down sides to this approach. This will require quite a bit more work on the interviewer’s side to pick a problem that is appropriate and short enough. It can also be easy to accidentally allow this technique to degrade into “pair whiteboarding”, which still misses the point. I think the effort is worth it. If a company can’t take the time to find a decent problem they probably won’t take the time to help me grow in my career.

Projects

My second favorite alternative, is a project. Only two companies I interviewed with asked for projects, though I’ve decided to accept a position with one of them (details coming soon!). Again the project should be related to the job at hand and not simply a take-home whiteboarding question. This allows the candidate to use their every day tools and resources- hello API docs - to produce code like they would be committing to your repo. It doesn’t even have to be coding based. It could be a presentation on a potential feature, or filing a bug report, or anything you want. The downside is the same as above, coming up with a meaningful project is harder then regurgitating the same questions we were asked out of college. But it is very rewarding to see someone’s true potential. A word of note, don’t use this to “weed” candidates out, programmers don’t have infinite time and the last thing we want to be doing is doing projects for a company that won’t follow up with us. Time box the project at 1~2hrs if it’s early on in the process, or more if its later in the interviews and you are really serious about the candidate. If you ask for a project first, don’t do whiteboarding later … that’s just redundant and disrespectful.

Brainstorming

Pick a question that the company has run into in the past or is currently facing and start a brainstorming session. Use this to see how the candidate approaches problems and leverages those around them for more information. In this scenario you’re deliverable is not run-able code but a solid understanding of the problem and at least one potentially viable solution. Make sure the interviewer isn’t just grilling the candidate and that it’s a joint session. It’s easy, it’s fun, it’s collaborative, and it’s useful. Feel free to use this with any other methods listed.

Work to Hire

I’ve never had a company offer this to me. Though I’ve worked for one that offered it. We gave a guaranteed six months full time work with a full-time offer by the 5th month if there was a good fit. It was nice for both parties involved because it gave enough time to let the honeymoon period wear off and see if there was a mutually beneficial relationship. The upsides are great, “have your cake and let it go if it doesn’t work for you too”, but there are some major downsides. Your team will lose productivity bringing new hires up to speed, and while this task should become easier over time, hiring a number of people just to let them go, is not a great idea. If you have a truly great candidate, you might lose them to a full-time job offer. That being said I would rather get a work-to-hire offer from a company then no offer at all.

Above all Else

Programmers: Ask what interview tactics a company uses early on. Suggest an alternative that you like from above if they whiteboard. Don’t be afraid to call out an interviewer on an irrelevant question, or at least ask for the motivation behind that question. Having a firm understanding of what the company wants will help you put your best foot forward.

Interviewers: Decide what qualities you’re looking for before a candidate comes to your office. If you care about team culture, leadership abilities, specific programming abilities or skills, then make sure the interview process reflects those values. Better yet, be up-front with the candidate. If you’re a large company and you will only accept PHD level fortran programmers, then say so. Also don’t expect a philosophy major with 7+ years of python to give you big O notation of every sort algorithm off the top of their head. Expect them to do python. Please read up on a candidates background and ask them specific questions related to your values before bringing them in. If you must whiteboard, explain why and what you’re looking for, be honest. Remember everything you do, says something about your company.

Good luck and happy interviewing.

If you have had a good experience with a interview method not mentioned here, or a useful comment, drop me a line on twitter @schneems or richard-AT-gowalla-DOT-com. Though be prepared to answer grueling series of programming questions before getting a firm reply ^_^

All good developers should write tests, and anyone with a high stake in a web app should write acceptance tests. Acceptance tests use a web driver like Capybara to test the full functionality of your web app by interacting directly with view elements the same way a user would (clicking links, filling out forms, etc.)

My only problem with acceptance tests is that they can be a bit slow, so i’m always looking for ways to speed mine up. One of my pain points is since everything is done via manual interaction with a headless website, any test requiring a logged in user (most of them) also requires that before it is run, Capybara must log the user in by visiting the sign in path and entering valid credentials. While I still think manual sign in should be tested, it doesn’t need to be tested every single time we run another test.

If you’re doing authentication with Devise to speed things up a bit we can stub out a logged in user with Warden’s built in test helpers.

It works like this when you’re running a non-acceptance test we want to use Devise’s sign_in helper since we have direct access to the request object (not available during capybara/acceptance tests). All other times we want to use Warden’s login_as method.

Here is an example of as_userand as_visitor helpers that do just that:

I then needed to call Warden.test_reset! after each test to ensure correct functionality

RSpec.configure do |config|
  config.after(:each) { Warden.test_reset! }
end

Then in my tests (shown here with capybara/rspec, I can simply log in a user like this:

It’s that simple. With a few lines of code I was able to speed up my tests and keep all expected behavior. For more details on how this works, you can go to the wiki page I created: https://github.com/plataformatec/devise/wiki/How-To:-Test-with-Capybara . Good luck and happy testing!

We’ve all been there, we start a new project with grand hopes and aspirations. But soon enough our project turns into one big ball of mud. In this presentation I talk about some commonly mistakes in Rails and how to keep your project Sane.

I gave this presentation at Austin On Rails and it was filmed by Austin Tech Videos.

If you want to make a change to Rails, you probably want to test out your change in an existing project. Here is what I needed to do to get an example project running on my fork of Rails:

First: Fork Rails

Before you can run a custom copy of Rails you’ll want to make a fork and then clone your fork to your local machine.

Go to https://github.com/rails/rails and click the Fork button.

Once you’ve got a fork clone it locally:

$ cd documents/projects

$ git clone git@github.com:schneems/rails.git 

$ cd rails

Next Modify Your Gemfile

Now that you’ve got a development copy of Rails locally you’ll need to modify the Gemfile of your existing Rails project that you’re testing against:

You need to point ‘rails’ to your local copy, mine is at /Users/schneems/documents/projects/rails, you also need to tell it where to find journey and arel, for those I just pointed at the existing repos online.

Here is my full Gemfile:

You may need to run bundle exec rake gem in your Rails copy directory to regenerate gemspec files.

Run your Local project

Go into your project directory with the modified Gemfile and run Bundler

bundle install

Then start your server using

bundle exec rails s

Now you can try running your changes against your own Rails project.

If you’ve never contributed to rails check out the Rails contribution Guide or ask someone who has. Don’t forget to make a new branch before you make any changes.

For a great example on contributing to an open source project for the first time, check out Contributing to Open Source.

If you have problems message me @schneems or check out #rails-contrib on IRC freenode, they were very helpful getting me set up. Especially @nashby_ for helping with the Gemfile. Good luck and happy contributing.

Rails needs controller level filter logging and Im submitting a patch to Rails core, but first I want some feedback. Let me know if you like it, hate it, or don’t understand it. All comments welcome, especially alternative implementation & style.

Please let me know what you think, please leave comments on the original gist: https://gist.github.com/1443757