Custom Bundler Configs

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:

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_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.

MacDown App & a nice little alias

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 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/ /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/"

# usage is simple
md <file>

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

Increase your coding speed

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 "============================================================"

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

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.

Using PostgreSQL Matchers in ActiveRecord

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 ~* ?", "")

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

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

Max OSX Keybindings

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.

Ways to Distribute Your Code

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!

Starting Gem builds with 'bundle init'

I’ve been building a lot of tiny gems lately to script out some basic stuff. It’s super easy, super powerful, and a lot of fun. I thought I’d share a few tips and tricks to get you rolling out your gem init.

The basics:

Building a gem is simple. All your need to do is add a .gemspec file and file to call your methods from. But how do you grow a bundle?

bundle gem <gem_name>

This is going to spit out a nice little dir:


Then… get to it. Having a dir structure is super important to me personally, so this gives me a big head start. I’m also a fan of cleaning the entire dir out if the script is only one file. But that’s for another time.