This lil post is about a single setting in Vim that you’ll see in just about every modern .vimrc.

set nocompatible

“nocompatible” is a mode that I feel most aren’t familiar with, which is seeded in a lack of knowledge on the history of Vim.

Vim stands for Vi (Improved). Essentially all that means is Vim has modern tech built into it, Vi is antiquated and wonky.

Would anyone still prefer vi?

Realistically, they shouldn’t. But plenty of people will have to work with vi day to day, just because their OS or shell can’t (or won’t) run Vi(m).

So set nocompatible is described as such in the Vim docs:

This option has the effect of making Vim either more 
Vi-compatible, or make Vim behave in a more useful way.

You can see all of the the options related to nocompatible here.

Just wanted to illuminate the meaning behind something I see in every .vimrc (including mine), yet most people don’t bother to look up.

Custom Bundler Configs

Earlier today I was working in a legacy ruby environment, and ran into a system conflict with my local rubies. In short, libv8 wasn’t installing correctly, and my bundle was broken. This bundler was using Rake 1.12.5 and ruby-2.2.0.

Here’s this problem pretty well documented online:

• Github Issue
• Stack Overflow
• Stack Overflow 2

All of those solutions basically address the sole problem: libv8 version conflicts. But none of them address this through the bundle, all using the gem cli. I needed something I could push to a distributed environment.

The gem failures were based on libv8 and therubyracer. I needed to link up the correct system v8 on install.

brew uninstall v8
brew install v8-315

The solutions would lead to tell me something like this:

gem install libv8 -- --with-system-v8
gem install therubyracer -- --with-v8-dir=/usr/local/..

But I needed it via bundle, this I dug into bundler configs.

So to set this up via CLI, heres the command:

bundle config --local build.libv8 --with-system-v8
bundle config --local build.therubyracer --with-v8-dir=$(brew --prefix v8-315)

Which leads to…

---
BUNDLE_PATH: ".bundle/gems"
BUNDLE_BIN: ".bundle/bin"
BUNDLE_DISABLE_SHARED_GEMS: true
BUNDLE_BUILD__LIBV8: "--with-system-v8"
BUNDLE_BUILD__THERUBYRACER: "--with-v8-dir=/usr/local/opt/v8@3.15"

Boom… now I am installing legacy versions through bundler.

The other day I discovered MacDown, a markdown client for Mac. Since I work at a software consultancy that heavily utilizes jekyll and markdown for day to day communication, this was a godsend.

Why use MacDown?

In general, you have to push up your README.md files or any of your blog posts to see them fully formatted. That can be a pain in the ass when you’re trying to check formatted lists, bullets, code, whatever in Github markdown.

So instead, use MacDown and view/edit your changes immediately. The split makes it easy to keep track of your source if you like the markdown editor.

But that wasn’t good enough. MacDown has a CLI integration, which you can see here. Esentially the app ships with a binary your can use and symlink to create a global command. Here’s the docs on that -> Scroll a little less than halfway.

The docs will tell you to create a symlink like so:

sudo ln -s /Applications/MacDown.app/Contents/SharedSupport/bin/macdown /usr/bin

Running the above command failed for me, with “permission denied”. And really I prefer to manage these symlinks via aliases in my .zshrc, so I ended up with this nice little alias:

# macdown
alias md="/Applications/MacDown.app/Contents/SharedSupport/bin/macdown"

# usage is simple
md <file>

Now I just use md <file> to open it up in MacDown. I love it.

Let’s face it. As a professional software engineer, and especially a professional contract software engineer, the speed at which you work is important. We all hate it hear it, but it’s the truth. And its the same reason managers are always arguing with developers about things they know nothing on… unit tests, devops, etc.

Before you start worrying about writing code faster, take care of your foundation:

• Write lots of tests (TDD helps)
• Study Your Language and know it’s ins/outs
• Learn OOP, FP, and POP

Once you’ve gotten a good start, now you can implement a few tips and tricks to start customizing your workflow for speed.

Use Custom Snippets

This is key. If you’re not using custom snippets, you’re wasting dozens of keystrokes every minute.

What are snippets?

Snippets are code bits that you can tab through with a shortcut. For example:

# Snippet to produce louder logging with '==='

snippet ===
puts "============================================================"
puts "== $1"
puts "============================================================"
endsnippet

# Snippet for defining a method in ruby
snippet def
def $1
  $0
end

Most editors have boilerplate snippets built in, but those aren’t going to make you a badass. I’m a vimmer, so of course I want to customize my own. Start tracking the code bits you write multiple times a day and abstract all of them into custom snippets. Learn them, master them.

Use Starter Projects

Some developers don’t have the luxury of starting every project in a “Greenfield”, or without any code at all. When you do start a new project, there’s a ton of freedom because no decisions have been made for you yet. But once you have to setup 5 new projects in a week, you can instantly see the duplicated work.

Abstact your preferred dependencies into a start project and move it into Github. Always start your projects there. Maintain that project and change it just like your dotfiles.

Use CLI Aliases

I don’t care if you’re not a terminal junky like me… you need to have an aliases file. Aliases allow you to set a command like ‘hi’ to run a different command or entire function/script.

Muscle Memory

If you use vim, use chromium.

The other day, I needed to search strings in my PostgreSQL database for substrings. This has since become a recurring pattern and I’ve been using it virtually every day now.

# Delete all example email users
User.where("email ~* ?", "example").delete_all

# Find specific User
User.where("email ~* ?", "jon@dough.com")

# Chained where calls
User.where("email ~* ?", "jon")
    .where("email ~* ?", "dough")
    .where("name ~* ?", "j")

Just a quick reminder for myself, and others. Take care!

As a software developer with some wrist pain (skateboarding, tennis, etc), I want to talk about a few key keybindings I use. Keybindings can greatly reduce key stretch and help reduce the overall impact on your wrists.

Here’s the keybinding I have to setup to be efficient on any computer.

Caps-lock -> Ctrl

If you use vim or the terminal frequently in development, then you’ll love this keymapping. Let’s face it, no one really needs the caps-lock key anyways. It’s just fluff. But the awkward placement of Ctrl (a critical key in the terminal) makes the remap valuable.

This keymap is so important, I can’t stress it enough. If I only had one keymapping on any computer, this would be the one. I also use this all the time on Linux/Ubuntu.

1. CMD + (1-0) => Space

In Mac OSX - I like to setup my workspace around “Spaces” in Mission Control. I map each of my spaces to an individual program, like iTerm2 or Photoshop for example. I know this general layout by heart, so I can switch through screens from memory.

For me, this is faster than the CMD+Tab workflow. I just don’t really like that my programs align horizontally (visually), and can rearrange order based on usage.

So for this mapping, CMD+1 takes me to screen 1. And CMD+2, screen 2 etc.

1. Right Shift => Backspace

If you have a larger keyboard, you might appreciate this mapping. I had been looking for ways to reduce the keystrech for my right wrist (my more sensitive wrist to soreness), and I ended up really liking this mapping. Try it now… Imagine typing right-shift for backspace. It just makes sense.

This mapping is really just about my personal needs. Wanting to be a long term programmer, etc. The first two are crucial for me to be a fast programmer.

There’s a lot of ways to distrubute code. In this post, I care most about portablity and least about ease of use.

npm/gem/pip/cocoa/etc, the highest level dist.

These ae your high level distributions. Users of this package will have access to, at the very least, a full virtual machine that they can provision as needed to run your package.

linux/ubuntu/brew, OS packages.

A little bit lower level. These packages are directly installed as executables in your operating system (usually usr/local/bin). They can then be directly accessed form the CLI.

Shell Scripts

What’s more portable than OS packages? Simple shell scripts. All OSs are going to have a shelll and really just represent a cimplex interaction with the shell. Being able to paste a single file into the shell and run it is incredibly powerful, and super portable.

From Memory

The most portable way to distribute code: from memory. No dependencies (besides your lang, compiler, etc) Pop into any terminal and start working. The more you write, the more you remember!