• Interactive Git Stash

    Often times I have the need to stash some changes in git but don't want to stash everything.

    The solution is to use git stash -p. The -p instructs git to do a stash interactively and will iterate over each changed hunk one at a time and instruct git what to do.

    These are the options:

    y - stash this hunk  
    n - do not stash this hunk  
    q - quit; do not stash this hunk or any of the remaining ones  
    a - stash this hunk and all later hunks in the file  
    d - do not stash this hunk or any of the later hunks in the file  
    g - select a hunk to go to  
    / - search for a hunk matching the given regex
    j - leave this hunk undecided, see next undecided hunk  
    J - leave this hunk undecided, see next hunk  
    k - leave this hunk undecided, see previous undecided hunk  
    K - leave this hunk undecided, see previous hunk  
    s - split the current hunk into smaller hunks  
    e - manually edit the current hunk  
    ? - print help
    
  • Purge Redis Keys with Lua Script

    Redis has some powerful Lua scripting capabilities. One of the uses I've found for this feature is purging cache keys. On occasion I need to purge a set of keys that all have the same prefix.

    The following command will do just that.

    EVAL "return redis.call('del', unpack(redis.call('keys', ARGV[1])))" 0 prefix:*  
    

    Replace prefix with whatever prefix you are looking for and they will be deleted from Redis.

  • First Round Interview with Kimber Lockhart on Technical Debt

    It's easy for teams to go to extremes with technical debt -- either trying to eliminate any and all and the expense of delivering the needs of the business, or ignoring tech debt and letting it happen without any thought or purpose, eventually causing great pains later on in the product's life.

    This interview with Kimber Lockhart has some great advice for engineering teams on how to handle technical debt responsibly. Here are a few highlights:

    Begin code review before anyone codes. The best technical teams envision — not just review — code together. “It goes without saying that some form of code review is essential in any type of engineering organization,” Lockhart says. “Early on, pair development or sitting next to each other reading through code will work. As the team grows, it might be important to get code reviews more formally from different individuals or teams.”

    For many companies, process evolves so that this code review is the only time engineers get feedback on their code and iterate to make it better," says Lockhart. "Unfortunately, finding a problem after the fact forces the tough decision between taking the time to rewrite and living with bad code.

    Technical debt should be a controlled decision to take a shortcut.

    "Technical debt is not the scarlet letter. It happens to the best of teams. I’d argue it’s actually irresponsible for a startup not to have any technical debt."

    Scrap the shortcuts that don’t save time. Lockhart has found that shortcuts can be an illusion — often it takes the same amount of time to write clean code as it would to produce code that introduces technical debt. “The problem is, bad code often feels faster in the same way hurrying feels faster,” says Lockhart, “little time is wasted planning and the code itself is written more frantically.”

    Create a rating system for bad code. “Many engineering teams lament the failure of their organization to adequately address bad code resulting from technical debt, but they can’t get their footing when asked how to resolve it,” Lockhart observes. “Engineering teams owe their organization careful prioritization, just like anyone else making requests.”

    “Hire seasoned engineers who have some tolerance for technical debt and an earned intuition when it comes to trade-offs. Seek developers who think in pros and cons, not absolutes.”

  • Better Colors in Vim

    I'm a sucker for pretty editors. Webstorm, Atom, Sublime and others have always have been better looking than Vim. Vim and the terminal simply weren't able to support the 24-bit colors that the other editors could. Macvim did a lot to improve the situation but I really like to use Tmux, iTerm2, and Neovim together.

    Luckily, while doing some research on the topic the other day, I finally got 24-bit color support via iTerm (nightly), Tmux, and Neovim.

    Here is how to accomplish it.

    1.) Install Neovim. Here are the install instructions for Homebrew on Mac. Once complete, add the following to your Vim config file.

    let $NVIM_TUI_ENABLE_TRUE_COLOR=1  
    

    2.) Download the nightly version of iTerm2. It supports 24-bit color.

    3.) Install a patched version of Tmux that supports 24-bit color.

    brew tap choppsv1/term24  
    brew install choppsv1/term24/tmux  
    

    Finally, here is what my setup looks like in all it's colorful beauty.

    If you'd like to checkout my dotfiles and Vim config they are on Github here.

  • How to Create New Postgres User

    I was doing some work in Knex today, the fantastic SQL builder for node and needed create a new user. It took some research but here is what I found:

    This assumes you've already logged into Postgres with another user.

    CREATE ROLE myUser WITH LOGIN PASSWORD '';  
    GRANT ALL PRIVILEGES ON DATABASE "knex_test" TO myUser;  
    

    To test it out just log back in.

    psql -h localhost -U myUser -d knex_test