Tristan Blease

Improve vim responsiveness with better timeout settings

Sun, 06 Jan 2013 22:55:00 -0500

Vim is typically fast, but it can be painfully slow at times, too.

A great example of this is when you make a block selection, insert/append text, and then hit ESC to apply your action to the rest of your selection. It seems to take forever before you’re back in normal mode and can see your action applied to the selection.

After digging into the issue, I learned that it doesn’t have to be this way.

Vim has two settings that you let you control timeouts when working with map key sequences and terminal keycodes/escape sequences:

timeoutlen defaults to 1000 and is the delay in milliseconds that vim uses when checking for map key sequences. It’s also used when checking keycodes if ttimeoutlen is disabled.
ttimeoutlen defaults to -1 (disabled) and is the delay in milliseconds that vim uses when checking for keycodes.

Out of the box, my vim was taking a full second to switch between insert and normal mode because ttimeoutlen was disabled; every hit of the ESC key caused vim to wait the full timeout in anticipation of a possible keycode.

To get around this I added the following to my vimrc:

" Adjust keycode timeout length
set ttimeoutlen=100

Since doing so, I’ve noticed that vim has been much snappier and even more of a pleasure to work with than usual.

If you’re like me and use vim in tmux, it’s worth noting that I also had to adjust my tmux.conf to get the timeout settings above working as expected. tmux has its own built-in delay for escape sequences that needs to be tweaked.

Improving WordPress security through Nginx

Fri, 14 Dec 2012 00:08:00 -0500

WordPress security has always been a hot topic given its popularity and the large number of amateur developers creating add-ons for it.

Looking through my nginx error logs for a WordPress site I host, I was disgusted to see that an alarming percentage of requests were clear attempts to hijack the site via insecure plugins and themes.

Thankfully, every one of these requests ended up serving a 404 page since the site in question only uses a handful of custom-written plugins, but what if we were using published plugins with known security vulnerabilities?

I’d rather not find out.

When placed above your @php location (or other location for processing php files in your nginx.conf), this location directive will stop evil-doers dead in their tracks when they try to directly access any sort of PHP script in the wp-content directory:

location ~ ^/wp-content/.+\.php { return 444; }

You’ve likely seen other 400 HTTP status codes, but the 444 code used here is special. It’s not an actual HTTP status code, but instead it directs nginx to drop the connection and not send back any response.

Previously I had a guard in my @php location to stop visitors from potentially executing PHP scripts in /wp-content/uploads (returned a 500 response instead), but this updated location directly goes the extra mile by not allowing would-be hijackers the privilege of even receiving a 500 or 404 response.

Useful fullscreen mode for iTerm in Lion

Wed, 15 Aug 2012 12:51:41 -0400

Fullscreen mode in Lion sucks if you use multiple monitors, but it doesn’t have to suck if you’re using iTerm2.

If you disable ‘Use Lion-style Fullscreen windows’ under General > Window in iTerm2’s preferences, iTerm2 will expand to cover the entire desktop area for the monitor it’s currently displayed on and you’ll still be able to use your other monitor for other applications/windows.

Alternate screen mode and annoying scrolling issues in iTerm2

Sun, 08 Jul 2012 11:27:00 -0400

I recently switched to using vim inside of iTerm instead of running MacVim, and I was immediately annoyed by the strange scrolling behavior that happened while I was using vim.

Accidental mouse scrolls into the scrollback buffer would reveal strange lines and pieces of the files I was working on. Clearing the scrollback buffer would help for a short period of time, but iTerm was determined to keep logging bits and pieces of my files and status line as I went about using vim.

After googling around, I learned that the curses-based version of vim runs in alternate screen mode. Alternate screen mode lets an application draw to a different screen so that the state of your shell/prompt is preserved and can be restored when you quit that application.

This is how vim (and other curses-based applications) takes over your screen and then returns you back to your shell (just as you left it) when you exit the application.

For whatever reason, iTerm saves lines from alternate screen mode and puts them into the scrollback buffer by default. Luckily, this can be disabled by a quick visit to the terminal tab within your profile settings:

Now, after I enter vim I can immediately clear the scrollback buffer (Menu item Edit > Clear Scrollback Buffer or Cmd-K), issue the vim redraw command in ex mode (:redraw!), and I’m all set for hours of happy hacking without any side effects from accidental mouse scrolling.

The Unix Philosophy

Tue, 03 Jul 2012 15:19:00 -0400

The Unix Philosophy:

The more I find myself integrating the shell and Unix tools into my workflow, the more drawn I am to the Unix way: “Write programs that do one thing and do it well.”

Shell Arguments

Sat, 30 Jun 2012 09:54:48 -0400

Shell Arguments:

This in-depth article clarifies how your shell deals with word-splitting, quoting, and expansion. Well worth the read if you do any work in the shell.

Faster searching in the shell with ack

Fri, 29 Jun 2012 12:33:00 -0400

You’re already using ack, right? Great.

A really simple way to speed up your searching in the shell is to trick out your ackrc file (~/.ackrc). This file takes a list of arguments to ack, which ack will then use as default arguments.

This means you can update/set the various file types and format the output exactly how you’d like it to be formatted by default.

Here are the contents of my ackrc:

--noheading --nobreak --ignore-dir=public/assets --ignore-dir=public/javascripts/cache --ignore-dir=db --ignore-dir=log --type-set=coffee=.coffee,.cakefile --type-set=tests=.spec,.feature,.rb --type-set=ruby=.rb,.rhtml,.rjs,.rxml,.erb,.rake,.haml,.mustache --type-set=mustache=.mustache --type-add=css=.sass,.scss,.styl,.less

Right away you can see I’ve changed the default output to remove the file heading that gets printed and remove all extra line breaks. This makes it easier to take the output I get from ack I pipe it to other shell utilities as needed.

If I wanted my heading and line breaks back, I would just run ack with the correct arguments to override my preset defaults.

ack --heading --break "Foo"

The next set of arguments set folders that I typically don’t want to ack to search in. Again, I can override these by passing an argument to ack at runtime to unignore the folder:

ack --noignore-dir=log "Foo"

The last set extends the different filetype groupings ack recognizes and allows me to search faster by specifying the types of files I’m interested in:

ack --coffee --js "Foo"

Customizing your ackrc may take about as long as it took for you to read this post, but you’ll immediately start reaping the benefits. For a full list of arguments that ack supports, you can run ack --help or review the ack documentation online.

I <3 Internet Explorer

Tue, 26 Jun 2012 12:52:28 -0400

I <3 Internet Explorer

CoffeeScript is JavaScript

Sat, 23 Jun 2012 21:55:00 -0400

CoffeeScript is JavaScript:

I really, really, really hate hearing excuses from other developers about why they are unable to learn or use CoffeeScript. This article, CoffeeScript is not a language worth learning, does a great job of putting the CoffeeScript vs JavaScript issue into perspective. If you haven’t read it yet, you absolutely need to stop what you’re doing and read it now.

The bottom line? CoffeeScript is awesome, so stop making excuses and start making great software instead.

Vim Clutch

Thu, 21 Jun 2012 20:58:00 -0400

Earlier today a link was making rounds of how Aleksandr Levchuk modified a USB pedal to act as a toggle for Vim’s insert mode. Press the pedal to enter insert mode, and depress it to return to normal mode.

When I think about all of the different types of inputs that we use to operate other technology (for example, driving a car), it surprises me that today was the first time I’ve read about anyone attempting to use alternative inputs beyond a keyboard and mouse to improve their coding efficiency.

I’m not sure how useful the Vim Clutch really is in practice, but it certainly sounds like a fantastic idea.

Aliases on the shell

Thu, 21 Jun 2012 11:33:00 -0400

The easiest way to speed up your workflow in your shell is to create aliases for your most frequently used applications and their configuration settings. If you use zsh, these aliases can go into ~/.zshrc, but if you use bash they should go in ~/.bash_profile.

A few sample aliases from my for git:

alias g='git'
alias ga='git add'
alias gc='git commit -m'
alias gac='git add -u && git commit -m "Auto commit"'

Now, when I’m on my prompt, the aliases will be expanded by my shell after I hit return to execute the command.

$ gc 'This is my commit message'

Expands to:

$ git commit -m 'This is my commit message'

Set Default Options

You can also use this to set default options for commonly used programs.

For example, let’s say you want to have ls display its output in list mode with color on OSX. I can just set up an alias like:

alias ls='ls -lG'

And now when I invoke ls on my prompt, it will automatically expand it as follows:

$ ls -a /path/to/foo

Expands to:

$ ls -lG -a /path/to/foo

More Examples

alias p='pushd'
alias o='popd'
alias s='cd -'
alias rcedit='mvim -f ~/.zshrc && source .zshrc'
alias hostedit='sudo mvim -f /etc/hosts && dscacheutil -flushcache'

Share your custom shell aliases and tips in the comments.

Git Fresh

Wed, 20 Jun 2012 01:42:00 -0400

Here is a quick script that lets you easily check the freshness of your git repository branches.

Place this script somewhere in your PATH and make it executable. This script can then be ran within any git repository by calling `git fresh` within the repository.

View on GitHub

To the cloud

Tue, 19 Jun 2012 00:00:00 -0400

Last weekend I decided to decouple my development environment from my local machine and move it to an EC2 instance in the cloud. Now, I can work on my projects on any computer anywhere as long as a computer has access to the Internet and a terminal emulator.

For text editing I’m using Vim - I’ve been using this fantastic editor on my Mac for a while, so choosing this as my editor in the cloud was a no brainer. With my vimrc file in place, it’s just like editing files locally except I now edit files over SSH.

To handle screen multiplexing, I’m using tmux, and I’m specifically using the version that’s compiled with extra support for iTerm2. This makes screen management a little easier when I’m logged in via my own machines, but ensures that I can log in from anywhere.

I’m not running any major services (nginx/mysql/postgres/etc) in my environment yet, but I do have ruby and node installed for the sake of being able to spin up a project-based application server as needed.

If I do end up starting a heavier duty project (one that requires a dev db or real web server), I can always set up a file watcher to rsync my changes to another server.

Looking forward to seeing how well this works over the next few weeks. Details to follow…

On spending time to save time

Sun, 01 Jan 2012 00:00:00 -0500

I’m in an unfortunate position where I get to slice up PSDs and create single-use HTML emails for marketing purposes at least twice a week. It’s work, but it’s by no means interesting or fun.

Like most folks, I’ve nailed down a process derived from years of battling with the major email clients (my favorite client being Outlook 2007/2010). My process works. On average, it takes me an hour per email to go from PSD to a mashup of JPGs and HTML markup that displays correctly in most clients.

Spending an hour per email isn’t that bad, but why spend two hours a week pushing pixels when you can be spending that time doing anything else?

Not wanting to waste another minute on HTML email, a few weeks ago I spent three hours coding up a quick and dirty Node app that uses a blend of CoffeeScript and Eco to quickly generate all of the needed markup for my emails from just a few lines of code. How few? Depends on how you slice up that PSD, but it’s possible to generate full emails in 30 lines of code or less.

You just pass the app this file and in return you get a new file chock full of ugly, disgusting HTML markup that works across most email clients without further adjustment or tweaking. Hooray!

So far, I’ve only been able to use my new tool a handful of times, but now I’m finding that I can go from PSD to HTML in 15-20 minutes. In the amount of time it used to take me to one email, I’m doing 3-4 of them.

That’s an extra 40-45 minutes per email per week, or an extra 48–72 hours a year, that I get to spend having fun by refining this new app or coming up with new ways to make my other processes more efficient.

I’ll take it.

Sanity check: how do you organize your web projects?

Sat, 05 Feb 2011 00:00:00 -0500

This past week, I was handed a Joomla site developed by someone else, and I was asked to clean up and update a few sections on the site. At first glance, I just about died. The file system was a mess—multiple Joomla installs, assets spread across different directories, everything out of place—and the internal structure (database) was no better. We tracked down the correct files using WebKit’s developer tools, but we could have saved significant time if the site was better organized.

Everyone already knows that keeping your projects well-organized streamlines development. makes collaborating with others easier, and allows you to keep your sanity should you have to come back to a project weeks, months, or even years, after completing it. Right?

How do you keep your project folders organized when creating web sites/apps? Read on for my organization strategy, and then leave yours in the comments.

Organization at a glance

To get started, here’s how I organize mine:

/client/ 
/client/project 
/client/project/.git 
/client/project/app 
/client/project/config 
/client/project/export 
/client/project/front_end 
/client/project/logs 
/client/project/public_html 
/client/project/scripts

Getting into the nitty-gritty…

/client, /client/project

Each client gets it’s own directory on my server, and each project gets its own directory underneath the client its specifically built for.

/client/project/.git

Version control. Everyone should use some flavor of version control. It doesn’t matter whether you use git, subversion, mercurial… just use it and stop complaining about having to learn something new.

/client/project/app

For custom PHP projects, CodeIgniter apps, and ExpressionEngine installs, I put all of my app logic into subdirectories contained within the app directory; keeping this data out of the docroot helps keep me organized and gives an extra layer of security.

/client/project/config

I use this directory to keep all of my needed configuration files for any scripts, application settings, and even hosting configs (if I’m running nginx, I’ll drop a symlink to this host’s specific configuration file.) Again, config files kept away from the docroot is a nice boost for security.

/client/project/export

If I’m exporting data out of my web app as a file, I’ll usually export it to this directory. When a user needs to download it from the site, I’ll have PHP fetch the file and return it. Keeps export files safe from prying eyes and allows me to use whatever authentication scheme I’m using to allow/deny access to these files.

/client/project/front_end

Usually, I’ll build the project’s front end code out separately from the app logic. If so, I keep those original files here and stashed in the repository for easy reference later on.

/client/project/logs

Application specific logs go here as well as symlinks to any domain-specific host access and error logs.

/client/project/public_html

My docroot for each project. I try to limit files going in here to only what’s needed (final front end assets like js/css/images, static html, etc.).

/client/project/scripts

Deployment scripts, front-end testing JS (for large forms that require repetitive data entry).

That’s how I do it. Et tu?

Do you use a similar strategy? Maybe something completely different? Leave your strategies and ideas on organization in the comments, and let’s get organized.

Generating a pubkey on Mac OS X

Mon, 23 Aug 2010 00:00:00 -0400

Read on for a quick tutorial on how to generate an SSH pubkey using Mac OS X. This should work for just about any version of Mac OS X and be useful to create public keys for services like Codebase.

Go into the Utilities folder in your Applications folder and open Terminal.app.

When the prompt appears, enter ‘ssh-keygen’ and hit return. This will start the key generator.

$ ssh-keygen

The first question the key generator will ask is where to save the key to. Just hit return to save the key in it’s default location

Enter file in which to save the key (/Users/tristan/.ssh/id_rsa):

Next, enter a passphrase to secure your key. It will ask you to confirm your passphrase. You can leave this blank, requiring no passphrase, but it is recommended to secure your key. When you use a passphrase, the system will ask you for that passphrase whenever the key is used for the first time after you’ve logged into your computer.

Enter passphrase (empty for no passphrase): 
Enter same passphrase again:

Next, you’ll be told where your key was saved and where your public key was saved. Select and copy the public key path. You’ll need that in a second. The path should look something like /Users/tristan/.ssh/id_rsa.pub.

Your identification has been saved in /Users/tristan/.ssh/id_rsa 
Your public key has been saved in /Users/tristan/.ssh/id_rsa.pub 
The key fingerprint is: 
13:cc:de:c8:e7:88:4d:62:3f:57:85:5d:f5:88:33:97

Next, type ‘cat ’ into the terminal, paste the path to your public key, and hit return. This will output your public key which you can then use elsewhere (like on Codebase)

$ cat /Users/tristan/.ssh/id_rsa.pub

Once you’ve done this, your public key will be output and look similar to:

ssh-rsa U2FsdGVkX1+VGwbGhYieyuhW+H0QD85yK3/wPCQfiXHLRtGt00AttZH N3SdjKFxjK3LsZlBGsve+aX7urQF23LKDM5esPzS7zFo75qSo6XNwPQYcBbpiRH xbXOZ+fPLoKjqYWvDEWs+RNMGs7QkQv+Xt096V/di3j48wZyRSStTGWBkEPRceR WBB6tSbKd48QNdbsZK1LVkiepw8dWBQNI8wuIEiWDe/TKlHaWCSOftRwQijC/qz GIwzBW0MojOR6j4aJU/rWzijFGw== tristan@24-107-186-239

You can copy and paste this public key as needed, and it will always be stored at the path where you generated it at (usually /Users/yourusername/.ssh/). Just make sure you’re always and only using your public key (id_rsa.pub) and not the private key that was generated (id_rsa).

iPad First Impressions

Mon, 05 Apr 2010 00:00:00 -0400

I knew immediately that I was going to get an iPad after Apple made the announcement, but I didn’t plan to buy one on launch day. Originally, I had planned to hold out for the 3G version. After talking it over with Clay on Friday night, I came to the conclusion that the extra $130 and $15/month contract wouldn’t be worth the ten minutes a month I’d actually spend using the 3G service. I went to bed early that night, but still had no intention of waking up early the next morning to wait in line.

Then Saturday morning came.

I woke up at precisely 6:30am. Checked Twitter. Saw a few tweets describing that only a handful of people were in line at the West County Mall Apple Store. By 7:00am, I was in that line. The store opened at 9:00am, and soon after, I was on my way home with 16GB iPad and accessories in hand.

Unboxing and activating the device was simple. After peeling off the plastic wrap and plugging into iTunes I was ready to go.

Having seen most of the first-party apps already, I immediately jumped into the App store to see what was available. Similar to the iPhone, the iPad is only as good as the apps it runs, right? I downloaded apps across almost every category, but I especially wanted to check out the journalism apps to see how they extended their content to the platform.

While some apps seemed to be just resized versions of their iPhone cousins, others make fantastic use of the new, larger screen format. A few that come to mind include Evernote, Square, Twitteriffic, and Epicurious.

I was very disappointed in the few journalism apps I played with. While they all do a great job of bringing their content to the small screen, they all seem to fall short in terms of engagement. None of the apps I tested let you view or leave comments (a big miss as far as I am concerned), and the most interactivity I saw in their content came from the embedded ads. Hopefully, those are things that will be addressed as time goes on.

Overall, I’m impressed with the iPad. Clay is going to get one when the 3G version comes out at the end of the month, and by then I’m sure were going to start seeing a lot of really great apps coming out in the App store. Can’t wait.

For those of you who were also early adopters, I’m curious to hear your opinions on the iPad and the apps that made it in time for launch day. Was it good for you, too?