On building software for people

For far too long, Rails’ application.js has been a junk drawer for Javascript. Having less files is ideal, after all it’s much faster to download one large file than 10 small ones. The problem is, a huge file with lots of code is very difficult to maintain. It would be much easier to break that up into a number of small files, just like we do with with our Ruby code.

There are a number of libraries, called “asset packagers”, that combine multiple Javascript and/or CSS files into one large file for use in production. Sprockets, from 37signals is one such library. With Sprockets we get the best of both worlds: lots of small files for developing, but only one file for the user to download. In Rails 3.1 and up, Sprockets is part of the framework so we get this helpful behavior out of the box.

In Rails 3.1 and up, application.js serves a new purpose. Instead of a junk drawer of spaghetti Javascript, it’s now a container of well organized client code (see Ryan Bigg’s Asset Pipeline guide for more on how this works). This organization will make it much easier to find problems in static files (make sure you set debug: true). You no longer have an excuse for disorganized client-side code.

In case you haven’t heard, Rails 3.1 is right around the corner. I’m very excited for the built-in asset packaging and rendering engines for Javascript and CSS templates. The patterns they are recommending will help keep my static assets more organized without hurting client-side performance. Ryan Bates (of Railscasts fame) has put together a list of all the changes coming in the next release of Rails. Along with the asset changes, Rails 3.1 sees built-in role support for ActiveRecord models to improve your app’s security, jQuery as the default Javascript framework and much more. If you’re interested in seeing it in action watch Ryan’s Rails 3.1 overview screencast. With this release, the Rails team has proven they want to stay ahead of the curve. My hope is that it will help us deliver more robust software faster.

UPDATE: There is great discussion going on about pasting in Vim on Hacker News. Join the conversation if you have questions or thoughts.

I like using Vim on the command line in a terminal emulator¹ rather than through a GUI. I’m a fairly distracted person, and I’ve found that a strong single-tasking workflow helps me stay focused. Most of my day is spent in one terminal window with one browser window open.

The problem

Unfortunately, pasting in command-line terminal Vim sucks. When I paste a nicely formatted block of Ruby code I end up with something like this:

    add_task_address=<YOUR TODO APP EMAIL ADDRESS>
    task=$*

    if [ $task ]; then
      # Send email with task as subject
      echo "" | mail -s $task $add_task_address
        if [ $? ]; then
            echo "Successfully added task \"$task\""
              fi
              else
                mail -s "Inbox" $import_tasks_address
                fi

Vim can’t determine the difference between normal keystrokes and pasted text. Therefore, certain character combinations could execute commands instead of showing up as text (GUI Vim implementations such as MacVim understand the difference). The solution is easy: tell Vim that you’re about to paste, paste, then tell Vim you’re done.

    <ESC>
    :set paste
    i <D-V> " Command + v
    <ESC>
    :set nopaste
    i

The solution

This works, but if you do much pasting it gets old fast. To automate this, I created a command to do it all for me:

    <C-O>:set paste<CR><C-r>*<C-O>:set nopaste<CR>

And then mapped it to <Leader>v in insert mode:

    imap <Leader>v  <C-O>:set paste<CR><C-r>*<C-O>:set nopaste<CR>

N.B. this command only works in Vim 7.3 or later. It’s written for insert mode, but it shouldn’t be hard to create a normal mode command that works in a similar manner.

Want to know how it works?

That should give you a good excuse to get familiar with Vim’s :help command or practice Googling. Everything in this command is native, documented Vim. Have fun!

Speaking of web-based tools to help you develop faster, Rubular is a regex tester to help you build and test regular expressions without having to run your app. I use this when I’m troubleshooting tricky regular expressions. The way it splits out capture groups is very nice. My only complaint is that I can only test against one string at a time. I’d like to be able to put in a few test cases and see where it fails. Maybe I should write a test for that…

strfti.me is an excellent reference for anyone who has ever had to look up the syntax to date format strings in Ruby, PHP, C or Python. Bookmark this one!

Here are some helpful guidelines for developers when you need to make UI decisions. My advice: if you have access to (or can hire) a designer, then use them! If you don’t (or can’t), then please spend some time up front talking to your target demographic (or someone similar) about what you are building and how it will solve their problem. When you finish a feature, go back to them and have them try it. I promise, it will be well worth it.

Speaking of getting everyone on the same page, before you create a story map the Inception Deck is a great tool from ThoughtWorks for communicating high level goals without going into the nitty-gritty. Using this tool, you’ll discuss what’s in scope, what’s not in scope, some technical architecture and more. I used this recently with a team and we found that everyone had a slightly unique take on the goals of the project. Now we all know what we’re building and why.

Jeff Patton shares his process of brainstorming product features and breaking them down into a backlog of cards. I’ve used this a couple times and found great success with it. It’s helped me better understand the problem I’m trying to solve and helped us stay on the same page, without going too far into technical details.

Recently I started reflecting on some of the tools, workflows and processes I use and whether or not they are actually helping me be more productive. But how do I know if they are making me more productive? We need to go deeper.

Productivity = Value / Time (productivity equals value divided by time)

By this definition there are two primary ways of increasing productivity:

1. Increase the value created
2. Decrease the time required to create that value

- What is productivity?

Decreasing time is pretty obvious, but value is subjective. What is value for a programmer? The most obvious definition is “the number of features completed over time”. But when is a feature complete? When the tests pass? Sure, it’s working, but how do you know you solved the problem correctly (or solved the correct problem)? The feature isn’t done until the user tries it and says their problem is solved. Therefore, programmer productivity means solving the most problems to your user’s satisfaction.

Rails is going to force you to use coffeescript in an upcoming version and there’s nothing you can do about it.

You have to learn coffeescript now.

It can’t be removed.

You must rewrite all existing apps to use coffeescript if you want to upgrade.

In his usual style, Jason Seifer kindly asks us to quit fighting about CoffeeScript being integrated in Rails 3.1. I was squarely in the anti-CoffeScript camp at first. My argument? It’s just an abstraction on top of a language, and I’d rather just use the language itself. But then Joe Cannatti reminded me that Ruby is merely an abstraction on top of C and C is an abstraction on top of assembler. Thinking about all the goodness Ruby provides has made me excited to try CoffeeScript (I haven’t yet, but will soon).