You’re likely to be more comfortable with many situations if you know the rules of the environment you’re in, including knowing its bounds and how flexible they are.

It sounds so obvious when it’s printed on the page in front of you, but if you’re more familiar with a situation, it frees up your mind to focus on other things that you need to do or are good at. You stop worrying about whether you’re within the acceptable bounds of your current situation and just do what you’re good at. “Apprehension” is usually just a term we use when we come across a situation that we don’t quite fully understand.

Take, for example, the security lines at most American airports. If you place someone in that situation who has never been there before, it would most likely be very overwhelming. There are uniformed people with badges who don’t quite look like police, everyone is taking off their shoes, but not before they hand two important documents to one of the faux-police, and then you have to walk next to these weird doorway things but there are two kinds and one you have to pause in the middle and turn sideways and oh yeah you remembered to take everything out of your pockets before this, right? It’s overwhelming to someone who’s not familiar. To someone who travels often, however, it’s positively rote.

Clearly, you don’t need to spend ten thousand hours going through security lines to become comfortable with air travel. Even one experience where you’re out of your element but aware of your surroundings helps to prepare you for the next time. It’s obvious that the more you know something, the better you are at it. But so many people seem to not take the time to learn the rules and boundaries and then continually “wing it” while being overly-anxious.

An article I recently read about how some anxiety is necessary might initially seem like it’s a counterpoint to this, but there’s a big difference between being prepared and being complacent. Even that article mentions that you have to get the balance just right lest you become lazy. Sports are a great example here. You have to know the game you’re playing inside and out and have finely-honed fundamental skills so you can focus most or all of your thinking on strategy or on the dynamic parts of the game that your instincts cannnot help with.

Even “simple” things, like how to interact in social situations, can be made easier if you think about the rules. It’s probably not a good idea to talk about that weird rash on your lower back, but it is a good idea to talk about a great beer you tried recently, or how the playoffs are going, or that you’re thinking about getting a dog. The basic rule there is “don’t be creepy.”

The hard part is knowing the rules in the first place. That comes through experience, and sometimes a little research – Googling, asking your friends or family – beforehand comes in handy.

I love writing with vim, but — for many valid reasons — some people are averse to it. I think the steep (–ish) learning curve has something to do with it, but I think some people really don’t want to give up their IDE. The thing is, vim isn’t just a text editor. You can extend it to do pretty much anything, including features that normally show up in IDEs.

I recently started using syntastic, which is a vim plugin that runs linters or syntax checkers and displays warnings and errors right in your window. IDEs like Eclipse or Xcode provide this syntax-checking for a couple of languages, but syntastic supports many languages and linters out of the box with pluggable support for nearly any language.

Setup

If you use pathogen like every sane vim user does, installing syntastic is just like any other plugin. Clone the repository or create a submodule in bundle/syntastic and you’re ready to go.

I mainly work with Javascript, Python, HTML, and CSS, so that’s what I’ll talk about. It’s worth checking out the syntax checkers in bundle/syntastic/syntax_checkers/, even if you just look at the list of files there. You might have to dive into the files to figure out which linters are actually supported as it’s not clearly documented.

Before we get to configuring individual syntax checkers, syntastic itself has a couple of configuration options. Syntastic has what it refers to as a “mode map”, which is basically just a way to configure which file types are checked. Here is the relevant config option from my vimrc:

1
2
3
4

" On by default, turn it off for html
let g:syntastic_mode_map = { 'mode': 'active',
    \ 'active_filetypes': [],
    \ 'passive_filetypes': ['html'] }

The ‘mode’ option set to active means that syntastic is on by default, so we can leave the list of ‘active_filetypes’ empty. The ‘passive_filetypes’ names filetypes that syntastic does not attempt to check. I don’t check HTML files because I mainly work with templates that either can’t or won’t validate with most HTML syntax checkers. If templates use non-standard attributes, it’s hard for a syntax checker to do its job.

Python

Setting up syntastic for use with python was extremely easy. Just install pyflakes with pip install pyflakes and set up some related options. I ignore certain errors regarding whitespace, indentation, and end-of-line backslashes, but those are all customizable. See the pep8 error code documentation for an explanation of the error codes.

1
2
3

" Use flake8
let g:syntastic_python_checkers = ['flake8']
let g:syntastic_python_flake8_args = '--ignore="E501,E302,E261,E701,E241,E126,E127,E128,W801"'

Javascript

There are a number of Javascript linters, including JS Lint and Google’s Closure linter, but I decided to use the communtiy-driven JS Hint. JS Hint can be configured with a jshintrc, which just is a JSON object that contains options. There are two categories of options: those that enforce stricter rules than the defaults and those that relax default checks. The options page of the jshint website does a great job of explaining each option. You can view my jshintrc on my Github page. I added a few “enforcing” options, but the only “relaxing” option I use is sub, which allows subscript notation when accessing properties, e.g. this['domNode'] as well as this.domNode.

You can tell syntastic to use jshint with the following config option:

1
2

" Use jshint (uses ~/.jshintrc)
let g:syntastic_javascript_checkers = ['jshint']

Usage

By default, syntastic runs your file through the configured filetype’s linter whenever the buffer is written. If there are errors, they are highlighted inline. When your cursor is on a line with an error, the description of the error is visible in the status line. You can use the :Errors command to open a quickfix window with a list of all errors in the file. Pressing enter on an error will take you to that line in the file. Syntastic uses vim’s signs, which means that a gutter with a sign appears on the left side of every line with an error on it, making it easy to scan the buffer for errors. You can change these symbols with some syntastic options.

1
2
3

" Better :sign interface symbols
let g:syntastic_error_symbol = '✗'
let g:syntastic_warning_symbol = '!'

You can configure syntastic in many other ways, including telling it to check a buffer whenever it is opened. I explored the help file (:help syntastic) when I first started using syntastic, and it was incredibly helpful. I encourage anyone who uses syntastic to do the same.

Syntastic has already helped me avoid many typos and silly errors that would ordinarily be hard to track down. It’s an invaluable tool in my workflow.

I just started using Mint to track statistics on my site. I’ve been using Google Analytics for a long time, and I will continue to do so, but it is definitely geared more towards sites trying to earn money. Mint seemed to offer a more streamlined and customizable interface for people who just want to look at stats.

Mint is a pluggable, extensible stats system. Mint modules are known as “peppers,” and each one provides some small functionality. There is a default pepper that provides some basic stats functionality like page views, unique visitors, search terms that brought those visitors to your site, and which pages they are looking at. There are a large number of official and community peppers over at the Peppermill that offer much more functionality and statistical views.

Installation

Installing Mint was a breeze. I just followed the simple instructions and I was good to go. If you have unfettered access to your server (via ssh) you should have no issues.

Issues with mod_pagespeed

I did run into a couple strange display issues when I went to view my Mint stats. Each pane took up the maximum width when it was opened. Even though I could view all my stats, the interface didn’t look good. After posting in the forum and fruitlessly trying to edit the Mint source code, I disabled mod_pagespeed on the hunch that my code changes weren’t taking effect because mod_pagespeed was caching everything. All of a sudden, the Mint interface looked fine, and it turned out that my small tweaks didn’t really make much of a difference after all. I still haven’t figured out exactly why mod_pagespeed was causing issues, but disabling it sure did fix them. If anyone has any insight into this, please let me know.

Peppers

I mentioned that Mint is pluggable and extensible. In fact, that is its entire basis: every bit of functionality is provided by modular plugins called peppers. Mint comes with the default pepper that I mentioned before, but there are many more available. I use a number of them.

Backup/Restore

This pepper is self-explanatory: back up and restore your Mint stats. That’s it.

iPhone

The default Mint interface isn’t that great for a smaller screen like the iPhone, so this pepper displays an optimized interface when you view Mint on an iPhone.

Outbound

A lot of analytics apps try to show you where your visitors come from, and that information is important. You might be interested in where your visitors go next, so this pepper shows your most popular outbound links.

User Agent 007

This cleverly-named pepper shows a breakdown of your visitors by user agent.

Real Estate

This one shows a breakdown of your visitors by the size of their screen.

Local Searches

If your blogging software has a search mechanism, this pepper shows you what your visitors are searching for. Note that this is different than the search engine queries that bring visitors to your site that the default pepper shows.

Doorbell

When you’re viewing your Mint interface, the doorbell pepper provides a some audio feedback when you get a new visitor.

Errors

This pepper shows any error pages that your visitors may have seen, along with the page that was requested that caused that error.

Locations

This pepper provides a breakdown of your visitors by geographic location.

Sparks!

Sparklines provide a great way to view useful trends in a small space. This combined with the iPhone pepper makes checking visitor trends on the go a snap.

I use both Google analytics and Mint on my site, but I find myself looking at Mint much, much more often. It just offers a better view into the kind of people visiting your site, especially if you’re coming from a position of trying to understand what kind of content brings them to your site in the first place. Mint comes highly recommended.

I’m not entirely sure if there’s a better name for this pattern that already exists, but I like “handle pattern” to describe this method of keeping track of and managing “subscriptions”.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

var subscriber = (function() {

    var _listeners = {};

    var s = {
        // Listen to a channel and call a callback when that channel fires
        listen: function(channel, cb) {
            // Add the callback to the list of listeners on the given channel
            _listeners[channel] = _listeners[channel] || [];
            _listeners[channel].push(cb);

            return {
                // Return an object that can be used to remove the callback from the channel
                unlisten: function() {
                    // Remove the callback from the list of listeners on that channel
                    _listeners[channel].splice(_listeners[channel].indexOf(cb), 1);
                }
            }
        },

        // Manually fire events on a given channel.
        publish: function(channel) {
            _listeners[channel] = _listeners[channel] || [];
            _listeners[channel].forEach(function(cb) {
                cb();
            });
        }
    };

    return s;
})();

var h = subscriber.listen('update', function() {
    console.log('The update event was fired!');
});

subscriber.publish('update'); // > "The update event was fired!"

h.unlisten();

subscriber.publish('update'); // > <no output>

When you have an event-driven application, like a Javascript app that performs actions based on user interaction or based on back end “pushes” to a listening front end, you often have a central “publisher” that handles firing events when certain actions occur. It makes sense to have a static listen function that takes a “channel” and a callback function to call when that channel gets updated. The problem comes when you have to decide how to stop listening to that channel. If you go with a static unlisten function on the publisher with the same signature as listen (the channel and callback), you need to keep track of which callback is listening to which channel, and it can get messy.

Instead, listen can return a handle, which is just an object that contains a method unlisten that knows exactly how to stop listening on the specific channel and with the specific callback that was given to listen. Then, the caller just needs to keep track of the return values of listen (as opposed to the arguments to listen) in order to be able to unlisten later.

The Dojo Stateful interface uses this pattern to watch values on objects. If you watch a property, a callback can be fired each time that property changes. The return value of watch is a handle that can be used to stop watching that particular property value.

Feel free to play around with this code on JSFiddle.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<?php

function getObject($id) {
    $object = null;

    // TODO Do we need to validate username?
    $objects = $this->db->retrieveForUsername($this->username);

    // FIXME Write `retrieveForIdAndUsername` instead of iterating here
    foreach ($objects as $o) {
        if ($o->id() == $id) {
            $object = $o;
            break;
        }
    }

    return $object;
}

This shouldn’t happen. I’m not talking about the comically bad code – it’s a contrived example, but it proves the point – but about the little “notes” left by whoever committed this.

Do we need to validate the username? Probably. Find out, and take the necessary action. If you know your codebase well, it should take about ten seconds to know the answer.

The FIXME is a bit more time-consuming, but the payoff is greater. If you leave this FIXME, I’m going to assume one of two things: you’re a lazy programmer, or you’re a bad programmer. You’re lazy because you can’t be bothered to write something correctly or you’re bad because you don’t know how to write it correctly¹.

Of course, use TODO or FIXME while you’re developing to keep a list of tasks that you have to finish before your feature is complete. Just don’t commit them to where other developers can see them and certainly don’t merge them to trunk.

If you’re lazy with that code now, there’s no way you’re going to overcome that laziness and come back to fix it later.

Really. My microwave helpfully makes the numbers 1 through 6 shortcuts for running for that number of minutes, on full power. When’s the last time you needed to microwave something for six whole minutes?

Most of my microwaving involves re-heating leftovers or softening things like tortillas or butter. These things don’t take minutes; they take seconds. And if I have something that really need to warm up over the course of one or two minutes, it certainly doesn’t need to be that long at full power. Those preset buttons are absolutely useless. I need presets for 10, 20, and 30 seconds, and maybe 90, and at power levels of 5, 7, and “hi”. Not “high”, mind you, “hi”.

The rest of my microwaving time is spent trying to defrost frozen meat, like a chicken breast or a tilapia filet. There’s a button for this, yes, but it requires that I guess the weight of the thing I’m defrosting. I don’t own a kitchen scale, but even if I did, I sure as hell wouldn’t bust it out to figure out how to long I need to defrost my meat. Let me tell you what I’m defrosting, and then figure out how long to defrost it. Defrosting is not a new science or even science at all.

Here’s another irksome feature: when I open the microwave door before the timer goes off, I really appreciate that it remembers how much time was left. Once eight hours have passed, though, I think it’s safe to assume that I’m no longer in need of that timer. “PRESS START” is not helpful after that long. Show me the clock again after a reasonable amount of time has passed.

Another thing: that awful beeping sound. I know some smug person with too much time on his hands has Googled his unit’s manual and has memorized the arcane sequence of button presses required to mute the microwave, but I haven’t. Why is there not just a mute button? It’s not for lack of room: put it under my “9 “ button or in between “Defrost” and “Popcorn” (which always burns those poor defenseless kernels) or even in the place of the “Reminder” button, because I don’t keep my todo list on my microwave.

Can someone “Nest-ify” the microwave? I would buy one in a heartbeat.

Starting a fresh environment on a new system isn’t a very common or regular task, but when you do, it comes in handy to have a quick and easy way to do it. To help with this, I keep my vim environment and my environment dot files in version control on Github.

I use Pathogen to manage my vim plugins. I follow the examples in this great article on plugin management with Pathogen to keep most of my plugins as git submodules. Installing my vim environment is just a matter of cloning the git repository and symlinking my vimrc.

I just spent some time cleaning up and organizing my dotfiles. I wasn’t even using my old dotfiles repository on GitHub, but I quickly rectified that. I now keep my dotfiles in ~/.dotfiles and symlink them to ~. There is a helper script in my dotfiles repository that sets up these symlinks.

Along with the usual bashrc, there are a few config files that aren’t as common. My ackrc defines a few convenient options and ignores directories with built artifacts in them. My (old) pythonrc defines a tab-completion function, although this might be outdated at this point. There’s a tm_properties config for TextMate 2.

Hopefully the fact that my configuration is out in the open will bring to light some useful features that I probably take for granted but you might not know about. So, go explore! Check out my inputrc, for example. I know that I discover new things almost every time I look at someone else’s vimrc or bashrc.

Do you have any configuration tips or tricks? Let me know.

Like most of the world, I love coffee. I usually drink a cup or two a day, and sometimes more. I’m lucky enough to live close to places that sell great coffee: Whole Foods roasts their own coffee, and there are numerous local places with great beans.

I usually make a full “batch” of coffee in a French press (or сafetière), but sometimes that’s too much. I know it’s considered blasphemous, but I got a Keurig single cup brewer for Christmas, and I absolutely love it. I was apprehensive about Keurig machines until I found out about refillable “K-Cups” that you could fill with your own, delicious coffee. I use the official Keurig “My K-Cup”, but that requires that you replace the entire holster mechanism each time. It’s not time consuming, but it is a bit annoying.

I discovered the Ekobrew, which is a filter that fits in the existing cup holster. Two of them are on their way to my house from Amazon right now.

Regardless of how it gets there, coffee from the Keurig is (perhaps surprisingly) pleasant. It’s not the best cup of coffee, but it’s quick, easy, and clean.

I still use the French press when I need to make a bigger batch of coffee or if I want to relax and enjoy a really great cup. I use the seemingly-ubiquitous Bodum French press and burr grinder and keep the coffee warm in my Zojirushi carafe. Coffee stays hot for hours on end, so I can make coffee in the morning and still enjoy it later in the afternoon. How I make coffee just depends on how much I need and what kind of mood I’m in.

One last thing: I also got a small stovetop espresso maker for Christmas, and it is amazing. When I want a treat, I make myself a café Americano: a bit of espresso in a normal-sized coffee cup and filled the rest of the way with hot water. Yum!

Full disclosure: I’ve linked to a number of products on Amazon in this post, and most of them contain my affiliate link. I’ll get a small kickback if anything is bought via these links. I will only ever post links to products that I use and love, and that is certainly the case with everything here. I’m passionate about my coffee, and I don’t want to mislead anyone. I have not included my affiliate link to the Ekobrew refillable K-Cup because I have not received or used it at this time.

In light of some recent excellent posts about tools that smart people use, here are my essential tools that I used in 2011.

Hardware

I use a 15” MacBook Pro i5 with 8 GB of RAM. It’s quick and does everything I need it to. It’s not too bulky, but it’s certainly bigger than my older 13” MacBook. I keep toying with the idea of a MacBook Air, but I can’t justify the cost and I don’t want to use two machines.

I connect to an Apple LED Cinema Display when I’m at my standing desk, and I use a Logitech wireless keyboard and an Apple Magic Trackpad.

I do daily, local backups to a smallish volume on a 1 TB hard drive. The rest of the drive holds my music, photos, and other media.

Software

I do all of my work (both professionally and on this site) on VMs in “the cloud” that I ssh to with iTerm 2. I love that it can copy-on-select and the customizable colors are more robust than in other terminal apps. I used the built in Terminal.app for a long time, but the latest iTerm 2 is stable and excellent.

I also use HTTP Client to test our API, as well as both Firefox and Chrome.

When I write code, I usually use vim, but I’ve been testing out the recent alpha builds of TextMate 2.

When I write for this website or for my own personal notes, I’ve started using Byword to write and preview Markdown. Its fullscreen and “paragraph focus” modes are nice touches. I’ve heard good things about Marked, which allows Markdown previews from any app, but I haven’t used it yet.

I’m not a huge calendar user, but I do keep track of shows I attend and personal events on Google Calendar. I interact with my calendars with Fantastical. Its natural language event input is pretty great and lets me add events really quickly.

I work on and use a browser-based email client at work, but I also like to use Sparrow. The minimal interface stays out of the way, but all my mail is available quickly. Shortcuts for reply and reply all make it easy to respond to threads. A nice little touch: Sparrow automatically picked up the fact that I had an IMAP folder called Archive in my work email and started using it when I press Delete to archive messages.

I use Alfred all day every day. My usage statistics say I average 13.6 uses per day, but if you didn’t count weekends, holidays, or days that I don’t actually use my computer, I bet it’d be a lot higher. I love the clipboard management.

I occasionally use Cloud to quickly upload screenshots, but I don’t use it for much else.

I use Dropbox to manage files, share some music with friends, and back up certain documents. I also store my (encrypted) 1Password data on Dropbox so that I can access my passwords from anywhere.

Divvy and Stay are two window management tools that I use all the time. When I disconnect from my display, Stay puts my windows back to where I want them. It doesn’t quite work with Chrome, but everything else works well. Divvy lets me resize windows on a custom-sized grid. You can even define shortcuts – I use “c” for a centered window and “6” for a window taking up 60% of the right side of the screen.

I recently started using Evernote, but I haven’t gotten into it just yet. I’ll have more to write about that when learn how to use it and actually start using it more. I do use Evernote’s Clearly browser extension to read articles on line.

For my musical pleasure throughout the day, I still use iTunes a lot of the time. However, Rdio (with Airfoil) is usually how I listen to music these days. Airfoil makes it easy to listen to music in my living room via my Apple TV.

You can now follow Uptonian Thoughts on Twitter! I’m using the Lessn Shortlinks and Simple Twitter Connect Wordpress plugins to tweet my posts to @uptonin.

I might still occasionally link to my own posts on my @thomasupton account, but all posts and articles, along with information about the site, will be available on @uptonin.