When it goes away there will be a power void. What we need is for someone to quickly build an API compatible replacement.

Don’t worry about the web UI part, just let people use a google account, pull their feeds, and then expose them with the same api. Charge a dollar. Or go to partners producing rss apps like Feedly and have them pay to use your api. They will need something like this if gReader goes away. You can cross promote feed apps and they can promote you to their users. Maybe get acquired by one of the larger feed app companies.

It seemse that Feedly is already busy building an API replacement. Whether they share this with other companies stands to be seen. Either way, I think there is room to compete here and to provide services for all the feed aggregators that are currently relying on Google Reader.

If I wasn’t so busy with creating a marketplace for musicians I would be all over this. Now please lazy internet, make this happen :)

Here’s a dead simple way to set up a split test without using a fancy application server or Rails application.

Let’s say you’re starting out with a new application and you want to test a few versions of the landing page. In the truly lean fashion, you haven’t built any dynamic application backend yet. All you’ve got is two versions of the homepage in static html, using something like MailChimp on the backend to capture your signups.

Take your two versions and place them in a directory, along with whatever assets (css/js/images) go along with them:

• public_html/welcome.html
• public_html/hello.html

Let’s also assume that these pages contain some type of signup form that redirects back to:

• public_html/thanks.html

That way we’ll know the goal is completed.

Notice that I’ve named them in user friendly ways. This will become important as we’ll have our webserver (nginx) redirect to those pages, so users will see them in the url. Why nginx? Because apache is a horrible nightmare to configure.

Now sign up for mixpanel.com and follow their instructions to place a snippet of their javascript into those two pages. Additionally, add an event to the bottom of each page to identify it:

welcome.html:

hello.html:

thanks.html:

Now, we’ll set up nginx to redirect to one of these pages “randomly”. Since there is no true random capability built in, we’re going to use the last digit of the user’s ip:

/etc/nginx/sites-enabled/mysite.conf

server {
  listen 80;
  server_name website.com;
  root /home/someuser/public_html;

  location / {
    if ($remote_addr ~ "[02468]$") {
      rewrite ^/$ http://website.com/welcome.html break;
    }
    if ($remote_addr ~ "[13579]$") {
      rewrite ^/$ http://website.com/hello.html break;
    }
  }
}

Now hit your website. If your ip is even, you’ll see the first page, and if it’s odd, you’ll see the second page.

Go to Mixpanel, and create two Funnels. One that starts with your welcome event, and one that starts with the hello event, and the second step in each funnel is the Signup Completed event. Now you have a funnel analysis for each page, and you can compare each to see how it performs.

All that, and without even an application server.

The Good:

Zero time for knowledge transfer – when my pair partner decided to leave the company, we didn’t have weeks of knowledge transfer sessions. Because we had been pairing about 90% of the time, there was actually no knowledge transfer required. Contrast to previous companies, where a core engineer with siloed knowledge leaving the company would wreak havoc.

I felt more productive. A pair keeps you honest and prevents you from facebooking and checking email compulsively. This meant that we would get a very strong groove going and be very productive. Conversely, by the time 4:30 or 5pm rolled around, we were pretty destroyed. While we tried to take sporadic breaks, I found that when I worked by myself, I would work longer but with more breaks. With a pair, we would work shorter hours but start to feel quite inefficient by the afternoon.

Higher quality code. I did feel that after discussing things with a pair, the overall code quality improved. For this to work, your pair doesn’t always have to be an all-knowledgeable rockstar. Even bouncing ideas off someone who doesn’t understand them fully can often lead to a better design. But it’s even better if your pair nicely complements your knowledge in areas you’re not strong in. I was lucky to work with some pretty bright people. In past companies, I had been paired with B-level guys, and that was not only a drag on productivity but also morale, leading me to dismiss pairing. But that’s more of a hiring issue, and not a pairing problem.

Not So Good

My voice got tired. I also find that when coding, something happens to my linguistic center for English and I just start speaking very strangely. Switching constantly between English and code is hard and reduces overall productivity. On the other hand, discussing things usually leads to better code.

Research and learning is awkward. It’s definitely counter productive to read over someone’s shoulder while they’re doing research, as people read and absorb information on different schedules and in different ways. For example, I google and skim pages at lightning speed, causing my partners to probably think I have ADD, but that’s what works for me. I found it extremely helpful if one person was coding, the other could use a second computer to look things up and pass things back and forth as chat links.

Creative tasks are harder. While our combined creativity in refactoring code was high, non-coding tasks such as visual/ux design became a chore with someone over your shoulder. I found it easier to break apart for such things and have one person work on the connecting code while I mocked up the design.

Simple tasks take longer. While the overhead of pairing is well justified when you’re debugging complex issues, designing new areas of the system, and so on, for quick one liner tasks the overhead of having to explain to your partner what you’re doing slowed the overall process down.

During times when I worked remotely, I was able to knock lots of little tasks in a day, whereas with a partner it felt like we achieved half as much. During remoting sessions, we would not simultaneously pair, but we would discuss things in chatrooms, and do code review via github pull requests. I believe if you are not lazy in code review, and really question every line of code, it can be just as good as pairing in terms of code quality.

The desire for environment uniformity can be difficult to handle. One partner I worked with had an idea that everyone should have exactly the same environment, editor, etc. I believe this idea comes from Pivotal Labs. Having a uniform environment lets you seamlessly switch from one workstation to another and not have to adjust. This seems like a good idea on the surface, so that developers can be equally productive. However, I believe that lowering everyone to the lowest common denominator actually decreases productivity.

For example, my vim setup lets me type probably an order of magnitude less keystrokes per day than most people and achieve incredible speed and efficiency. I personally don’t feel comfortable having to type more, which is horrible for your hand health, and forced into an editor I don’t like just to achieve team uniformity. Instead, I find having two machines side by side, with one person reviewing code and doing research much more productive. With my other partner, we were able to achieve a nice harmony with him driving for half the day, and I for the other half. This allowed each of us to be ultra productive on home turf, while still getting all the benefits of pairing in terms of knowledge transfer and code review.

Summary

I think pairing coupled with an extremely pragmatic approach to knowing when not to pair is the key to success. For me, the benefits of pairing are very high. Instant knowledge transfer and high quality code are very important. But, I believe it must come with a healthy dose of scheduled breaks, time for doing solo tasks such as design, and occasional remote code review sessions to give pairs a psychological break and mental refresh.

Typing colon :commands is really slow. You have to hit shift, colon, command, plus enter to execute. You’re taking a 3 keypress overhead every time you use one. So what to do? Simplify your life with a three tiered approach

1. Super common things should be chords (Ctrl-something, Cmd-something, Cmd-Shift-something) or single key presses.
2. Second most common things should be two character mnemonics such as vv
3. Third tier should be leader-based commands with two or three keys such as ,gg for GitGrep in my setup

For example, the normal way to go to a tab is :tabn which is at least 7 keypresses. A much better way is to map all your tabs to Cmd-1 through Cmd-9 and jump instantly to them with a single chord (This if for MacVim, you can map another key if you need unix)

map <silent> <D-1> :tabn 1<cr>

What about jumping between windows? The standard vim way will have you doing a chord and then a key (C-w, l) to get to the right. Remap to a two-key chord:

nnoremap <silent> <C-l> <C-w>l

Closing windows? Normally you’re stuck with :bd for 5 key presses to kill a buffer or C-w, c – a chord and a key (3 slow keys). I kill windows all the time, so for me it’s just the letter Q – a simple chord. And I made it smart enough to kill either the window or the buffer, using a script that figures out if there are any other windows into the same buffer.

What about splits? Same deal..way too many keys. Type a two key mnemonic vv for a vertical split:

nnoremap <silent> vv <C-w>v

I usually grep for things all day long so I mapped a single key K to give me the git grep for the current word under the cursor:

nnoremap <silent> K :GitGrep <cword><CR>

My rule is to really consider every time I type more than 3 keys to execute a command in vim, and if it’s something I do every day, remap, remap, remap!

If you liked this, please take a look at my YADR dotfiles project – which has many more interesting keymappings to save you time, and has recently broken 700 watchers on GitHub!

Here are my notes on Xavier Shay’s awesome video on sustainable productivity in Rails. I agree wholeheartedly with all of his points, and although they’re not particularly new, it’s nice to hear from someone with real world perspective on maintaining a large Rails project.

1. Rails does not make data integrity a priority, so be conscious of it and take the effort. Ideally the framework will evolve in this direction eventually.
   • validates_uniqueness_of doesn’t validate uniqueness with concurrent access – you need db constraints (unique indexes, foreign keys, etc). At the same time, Rails doesn’t provide a good built in way to error handle constraint violations.
   • Rails encourages poor practice with database because things like t.references in migrations doesn’t add foreign keys.
   • (personal note) I have seen many Rails projects completely ignore database keys. I like the old adage that your database will outlive your application. Put constraints where they belong.
2. Consistency is incredibly important, and is more so when you have a large team. If you create two ways of doing one thing, the next developer has to scratch his head. Don’t duplicate code or concepts, design for reuse.
3. Don’t pepper third party dependencies in your code. Design layers of abstraction so that all third party access is in one spot, easy to change. Use reification – start naming concepts rather than implying them with conditional logic (e.g. the Null Object pattern).
4. “Fail your build for basic style, complexity, and readability violations.” Don’t let people check in stuff with bad whitespace, complex methods, etc. Make it part of the continuous integration cycle. Bad code spawns more bad code. Easier to prevent in the first place than untangle later. (see: cane, also metric_fu)
5. Self-documenting code is awesome, but documentation should be used on a class level to describe how the class figures into the bigger picture. I’m a huge fan of this idea, and don’t do it enough myself.
6. Rails unit/functional/integration test definitions are different from everywhere else in the world. They tell you how to organize code but are not useful, leading us to have “fast spec” vs “slow spec”. This is bad. A unit test should not touch the database, filesystem, etc. Unit tests should be fast and without dependencies, integration tests specify boundaries, acceptance tests make sure the system works.
   • (Personal note) At Crowdcast we have been working purely with fast-spec lately, even stubbing out dependencies in our controller tests so we can blazing fast TDD our code through the entire stack, relying on a single high level acceptance test that makes sure everything connects correctly, and stubbing everything at lower levels.

Videos are awesome but not everyone has the time. I made these notes for myself but if people find them useful, I’ll try to continue blogging short summaries of talks that I watch. I hope others do the same, so we can save each other time :)

So I decided to do something about this. Every single day, I spend at least 5 minutes learning something new that saves me time. I notice a repetitive motion, and I write a vim mapping, a shell alias, or a utility script, or just spend time looking at what other people are doing. It’s sometimes hard to step back and be self aware about the things that I repeat, so I try to watch how others work too. Then I go and write a shortcut. This small investment every single day, pays huge dividends because I get exponentially faster at the mechanical parts of my job every day, leaving more time for thought and productivity.

I like doing this, and I like sharing my learnings with the world. If you want a peek at how I do things, check out my dotfiles project, YADR. Fork it, copy it, steal the bits that you like, or contribute some of your own. Huge wins stand on the shoulders of lots of tiny ones.

1. With your cursor over the thing that’s highlighted in a bad color, hit the ,hi. Say I don’t like the way this describe keyword is done in pink:

2. Note the info displayed in the status line, it will look something like:

These are the color highlight groups, in brackets. The leftmost one is the one with highest precedence, and the one we want to override.

3. Look at the list of available colors using :hi. Note the names of the groups on the left, and their displayed colors. Find one you like. The list will look something like this:

4. Create a link between the group you want to modify and the one you like. Let’s say the one I like is Identifier, and the group I’m modifying is MatchParen. I would link them like this:

Reload your vimrc, or the file in which you placed the statement. The easiest way to evaluate the current file is :so %. And voila:

You can place this in your ~/.vimrc, or in a subfile under ~/.vimrc/plugins. If you liked this example, be sure to check out my highly customized dotfile project called YADR, which offers the ,hi functionality, well organized vim snippets and plugins, and other handy shortcuts to save you tons of time.

As software developers, ops guys, designers, it is a known evil that we sometimes choose shortcuts, accruing tech debt with the knowledge that we’ll pay for it later with considerable interest. However, there are a few categories of design choices that we make every day that will make software easier or harder to maintain for the next guy who comes after us, which are specifically evil and malicious forms of tech debt.

Here are a few basic categories that most non-Maintenance Driven decisions fall into. Please don’t be that guy :)

• duplication – This is the cardinal sin against Maintainable Design. If you duplicate code, it will instantly grow into piles of subtly divergent crap. It would have taken you an additional hour to figure out how to do it in a non-duplicated way. It will take your maintainers half a lifetime to understand why and how the code has diverged. My own anecdotal experience says that duplication has about a 1000% tech debt interest rate. That is, 1 hour saved by committing duplicated code will cost you 10 hours down the line. And this interest is compounded over time as the code diverges further.
• clever code – Clever is the enemy of Maintainable. Every time you cut and paste a really cool hack that you found on a blog in 2006, a unicorn dies. Follow conventions, and use existing and accepted practices instead of reinventing the wheel.
• personal aesthetics – Having a strong sense of personal style is awesome. You like snakeskin jackets and neon green pants? Sweet. But leave it out of the code. If you have a personal style that goes against accepted conventions, and you choose to prioritize your style over that of the community, you are not Maintenance Driven. When in doubt, look at the source code for a large community supported project (i.e. Rails) for style ideas.
• poor naming – Single letter variable names are impossible to grep for effectively. Names based on your favorite ninja turtles, though they will win you points with me, are bad for business. Same goes for commit messages – don’t write something clever and witty at the expense of clearly explaining your changes.

(go to file, use it over any reference to a file, such as a Rails partial), and

(go to tag, use it over any class or function name). But one problem in vim is that by doing these commands, you lose your previous place. Sure it’s easy to go back to with Ctrl-O or similar, but I find it much more useful to open the new location in a split, as you are usually exploring them while retaining the current context. Here are two mappings that do that for you:

If you like these, you might want to check out my Yet Another Dotfile Repo project, which includes these and more!