RSS
 

Archive for the ‘coding’ Category

Don’t get blocked

26 Sep

Every day at our stand-up, each person shares what they did the day before, what they plan to do today, and, critically, whether or not they’re blocked.

Blocked is a crappy place to be. It means you’re trying to get something done but can’t. Current velocity: zero.

I’ve noticed something about programmers I admire: they’re extremely good at not getting blocked.

Some time ago I spent three days trying to get a feature working. I was blocked, and bad. Finally, I took a break and went to work on something else. The next day at standup, a colleague mentioned implementing that same feature, and then then going on to do two more tasks with the other half of his day. Incredulous, I asked him how he solved the problem I’d run into. He happily admitted he hadn’t. He’d run into that problem, spent a half hour on it, and then changed direction.

Me: got blocked, pounded on the barrier. Great programmer: got blocked, tried something else that worked and moved on.

Like most programmers, I have an strong desire to solve problems. Put some broken code in front of me and I’ll wrestle with it ’til it works. There’s lots to do but I’ve got to start by fixing this problem.

The best programmers I know have a different mantra: don’t get blocked. They’re focused on moving things forward, not getting bogged down making everything perfect. They’ll duck and weave, leaping over obstacles or tunneling beneath them. They like problems too, but they like something else even more: shipping.

Don’t get blocked.

 
No Comments

Posted in coding

 

Programmer Resumes are Deprecated

13 Jun

First, some exciting news: after a thorough (but enjoyable!) interview process, I’ve accepted a position at thoughtbot in Boston and will begin in a few weeks. I can’t wait to get started.

The interviews themselves will make great fodder for future posts, but I realized a startling fact the other day: I never once sent anyone at thoughtbot a resume.

Moreover, I was never asked about schools, degrees, nor much about my past experience. My “resume” took the form of links to this blog, some open source contributions, and access to a couple private github repos of Rails apps I’d built.

This experience confirms an idea that I’m glad to see gaining ground lately: resumes are deprecated. Code is king. Oh, and connections help a lot too.

A year ago I wrote that it was possible to land a Rails job with no experience, provided you had a portfolio application, some code on Github, and attended Ruby meetups to network. Some people were skeptical, but it was exactly those things that got me my first Rails job. Now, years later, the same set of things got me in the door at thoughtbot: code, more code, and the recommendation of thoughtbotter Dan Croak, who I got to know during the ’09 Rails Rumble (yet more coding!)

I’m starting to think this really is the secret sauce for professional programming success, regardless of experience level. Get some code out there for people to see, and get yourself out there to meet awesome programmers you might want to work with someday. Leave the bullshitty bullet points to the MBAs.

 
3 Comments

Posted in coding, rails

 

Don’t Use Rails’ Scaffolded Controllers

12 Nov

Fellow Rails Developers, the state of the art has moved on, and you should no longer be using the controllers generated by Rails’ scaffold command (or ‘rails g resource foo’).

These controllers are all the same. Repetition like that can and should be eliminated.

Instead, you should use something like Inherited Resources.

Here’s what a controller generated by Rails looks like:

class UsersController < ApplicationController
  # GET /users
  # GET /users.xml
  def index
    @users = User.all

    respond_to do |format|
      format.html # index.html.erb
      format.xml  { render :xml => @users }
    end
  end

  # GET /users/1
  # GET /users/1.xml
  def show
    @user = User.find(params[:id])

    respond_to do |format|
      format.html # show.html.erb
      format.xml  { render :xml => @user }
    end
  end

  # GET /users/new
  # GET /users/new.xml
  def new
    @user = User.new

    respond_to do |format|
      format.html # new.html.erb
      format.xml  { render :xml => @user }
    end
  end

  # GET /users/1/edit
  def edit
    @user = User.find(params[:id])
  end

  # POST /users
  # POST /users.xml
  def create
    @user = User.new(params[:user])

    respond_to do |format|
      if @user.save
        format.html { redirect_to(@user, :notice => 'User was successfully created.') }
        format.xml  { render :xml => @user, :status => :created, :location => @user }
      else
        format.html { render :action => "new" }
        format.xml  { render :xml => @user.errors, :status => :unprocessable_entity }
      end
    end
  end

  # PUT /users/1
  # PUT /users/1.xml
  def update
    @user = User.find(params[:id])

    respond_to do |format|
      if @user.update_attributes(params[:user])
        format.html { redirect_to(@user, :notice => 'User was successfully updated.') }
        format.xml  { head :ok }
      else
        format.html { render :action => "edit" }
        format.xml  { render :xml => @user.errors, :status => :unprocessable_entity }
      end
    end
  end

  # DELETE /users/1
  # DELETE /users/1.xml
  def destroy
    @user = User.find(params[:id])
    @user.destroy

    respond_to do |format|
      format.html { redirect_to(users_url) }
      format.xml  { head :ok }
    end
  end
end

Here’s that SAME controller using Inherited Resources:

class UsersController < InheritedResources::Base
end

That’s right, just by inheriting from InheritedResources::Base you all the standard REST actions for free.

If you need to, you can override any of the default actions:

class UsersController < InheritedResources::Base
  def new
    # do different stuff for new
  end
end

It even has a nice DSL for customizations you’re likely to need. Here’s how to change just the redirect for the destroy action:

class UsersController < InheritedResources::Base
  def destroy
    destroy!{ root_url }
  end
end

The best thing is, once you’ve got that duplicated code out of there, you don’t need to test it! Inherited Resources already has its own tests for the standard actions, so you only need test the things you explicitly change.

A few months ago, I refactored an app to use Inherited Resources instead of the generated controllers. And by ‘refactored’, I mean ‘deleted pages and pages of controller and test code’. I ‘git rm’d almost all our functional tests and damn that felt good.

You gotta get in on this! The README is solid, so you should have little trouble getting started.

 
2 Comments

Posted in coding, rails, ruby