SuperAcidJax

Some Tips for Vim Newbies

2013-11-21T00:00:00-08:00

As someone who tended to revert to Sublime when faced with a particularly time-sensitive editing task, learning Vim tended to go more slowly than I would have liked.

However, over the past two weeks, I’ve refused to allow myself to open Sublime at all, even when on a tight feature-release deadline for work. So here’s a suggested strategy if you find yourself not learning as quickly as you would like.

Each morning, before you start work, your goal should be to pick up one single new thing. For me yesterday it was learning how to quickly open test file/app files in a split. So if I was in a controller, being able to instantly open the functional test in a split was a big boost. The day before, I learned about indenting.. etc. The book Practical Vim from Pragmatic is really good (you can work through it in small daily chunks.)

Then work that day using ONLY vim. Do not open Sublime or TextMate. You will be slower. You will get frustrated. That’s ok. Throughout the day, use that day’s technique every possible chance you get. If you get to a point where you absolutely just can’t accomplish it in Vim, then look up the relevant technique. Yes, that’ll slow you down for the few minutes it will take you, but you’ll end up owning that technique afterwards, because you were forced to use it, and it was highly relevant.

I’m not a vim expert yet, but I’ve improved more in the past few weeks than I had after a year of using Vim to “learn” and then switching to Sublime to “work.” The key is combining learning as you work.

This is probably common sense, but it’s very effective. If you want to be even more hardcore, just delete Sublime completely. Then it would take you 5-10 minutes just to download and reinstall it that the effort wouldn’t be worth it and you’ll force your way through vim instead. I personally didn’t do this simply because in my job I occasionally have to pair with people who don’t use vim.

I also recommend Tmux and using Vim in the terminal instead of using MacVim. The reason is personal for me – I prefer to have one screen for everything, meaning running iTerm in full screen with my vim in a vertical split over the top 80% of the screen with my command-line underneath. (Like an upside down T.) The advantage of this is I can switch almost instantly between my console/command line and vim without having to switch apps. That’s just my way of working, so it might not apply to everyone, but MacVim is, to me, another app to switch into and out of, so the slight delay (and loss of mental “flow” in doing that dozens of times and hour) is costly. The very best book on Tmux is also from Pragmatic and can be found here.

This might not help everyone, but it worked for me. Good luck fellow newbies! We will win vim, and subsequently win the internet.

The Trouble With Averages For Application Performance Monitoring

2013-11-19T00:00:00-08:00

Most web application performance tuning starts with an almost obsession with average response times. The problem with average response times is that we tend to make the assumption that the average would be evenly distributed. Yehuda Katz and Tom Dale from Tilde make an excellent point about how this is wrong. If web application performance were distributed like human heights were distributed, then it wouldn’t be unusual to see a 12 foot person occassionally on the street or a 2 foot person.

Using average response times is a bad idea because your responses aren’t ever distributed as a bell curve.

The reason the averages become useless is because the programming language you’re using is Turing Complete and has branches. As an example, the performance characteristics of a cache hit versus a cache miss are completely different. So in an If statement you have a cache hit, then it’s going to be very fast, but a cache miss would then result in the program doing some expensive computation, however those two response times are averaged which gives you a completely worthless number.

Instead, it’s better to look at the average worst response time (at the 95th percentile.) This would be the average worst response your users would get.

For example, good performance is worthless if it’s not consistent. So having 200ms, 200ms, 200ms is much better than having 50ms, 50ms, 1 second. The 95th percentile measurement simply means that 1 out of 20 requests made by a user will hit this worst response time. The 95th percentile isn’t an outlier, it’s a slow request that your users will routinely hit. Which ultimately translates into a degraded user experience that isn’t reflected by using average response time as a measurement.

The Point

Chasing average response times can be helpful as a vanity metric, however it doesn’t actually measure how well your application is performing for each user. If every 20th request is taking 5 seconds, those 200ms requests aren’t very appealing anymore, even though your average request time might only be 300ms.

You can hear more about this with Thoughtbot’s Ben Orenstein and Tilde’s Yehuda Katz and Tom Dale in Episode 53 of the Giant Robots Smashing into Other Giant Robots Podcast.

Bundler Parallel Installs

2013-11-18T00:00:00-08:00

The new Bundler version 1.5.0.rc.1 is awesome. One of the cool new features is the ability to bundle install in parallel. Which means you can speed up your bundling by up to 60% over the previous version of bundler.

Parallel Installs

First you need to install the new version of bundler. Since it’s a pre-release, you’ll need to install it like this:

gem install bundler --pre

Next you’ll need to use the –jobs option like this:

bundle install -j4

This specifies that 4 workers will be used to complete the bundle process.

To always use it this way you can run this:

bundle config --global jobs 4

And that’s it! Happy bundling.