I have hundreds of files and folders in my dotfiles repo, and nearly 1000 commits—there are quite a few hidden gems buried in there that generally don’t get to see the light of day. Rather than wander aimlessly through them, let me give you the guided tour.

I’ve written in the past (twice) about how to streamline the writing process when using LaTeX. Since then, I’ve found that I enjoy writing even more when I don’t have to reach for LaTeX at all. By reaching first for Markdown, then for LaTeX when necessary, writing is easier and more enjoyable.

People often ask me why I switched to zsh. Back when I had first switched, I was hesitant to answer because I was still finding my way around. Now that I’ve been using it, I’ve managed to distill down a few things zsh does well that sets it apart as my shell of choice.

Stephen Diehl’s article Vim and Haskell in 2016 does a great job of outlining the quickest way to get a quality Haskell development experience. His post presumes Ubuntu; here we presume OS X.

Discussions of encryption permeate tech and political news sites these days. All too frequently though, ideas presented in these discussions draw upon outdated analogies and confusion due to technological progression. I think it’s time to have a chat to answer some questions and move the discussion forwards.

When it comes right down to it, SML is a pretty great language. It’s clear that extensive thought has gone into its design and implementation. I quite enjoy programming in SML, due in no small part to my collection of workflow hacks that make editing and developing with SML responsive and interactive.

Zsh has given me so much mileage with respect to efficiency at the command line. Looking back I’m a little sad I didn’t switch to it sooner. One of the reasons why it took so long was that I didn’t know where to start; with this in mind, I’ve collected some of the zsh-specific bits of my dotfiles into one place to help people hit the ground running.

I’ve been watching a disk space leakage creep slowly upwards for months now; finally, I figured out where it was going!

I’ve been using Docker for a couple side projects lately, but only intermittently. That means every time I try to get back into things, I spend the first 15 minutes or so trying to remember all the little tricks I’ve picked up from previous Google searches and hunts through the documentation. Rather than continue to suffer through this cycle, I’ve written them down here to help you and me ramp up more quickly on our next Docker projects.

A while back I was doing some spring cleaning of my Python packages. I noticed that there were a bunch of packages that I couldn’t recall installing. I wanted to know if I could safely remove them, so I wrote a simple bash script to tell me called pip-uses.

I recently rewrote most of my dotfiles to clean them up and in the process decided to take a renewed look at using rcm’s array of features to manage syncing my dotfiles across multiple servers and hosts.

I took some screenshots to accompany my Vim as an IDE repo on GitHub. This is by no means a complete walkthrough! It’s just a reference for those who are curious if they installed everything correctly. This is what my system looks like for me after each step.

I’ve changed my GitHub username from Z1MM32M4N to jez (hopefully it’ll be a little easier to type now!). Make sure you update any remote URLs for repos of mine that you’ve cloned.

Git is an incredibly powerful platform for collaboration. The ability to create light-weight branches as well as push to and pull from multiple remote repos is the foundation of this power. Learning to harness the git log command will help with visualizing all the information that supports these features, refining and invigorating your current workflows.

There are LaTeX document classes for typesetting books, articles, exams, presentations, and more. Now, there’s one for homework assignments, too.

I’ve already written about how I develop LaTeX offline in Vim using GNU Make. Recently, though, I found a tool that implements another feature that GUI editors had to themselves: splitting panes.

Whenever someone complains about a slow computer, the first thing I check is how many Chrome tabs they have open. Chrome hogs memory like no other. For users, this means Chrome is snappy and responsive, but oftentimes it comes at the expense of crowding out other programs. To get an idea of how much memory Chrome is really using, I wrote a quick bash oneliner.

HTML and CSS can be frustrating when first starting out. Despite all you try, nothing is in the right place. I’ve advised more than a few friends on how to figure out this mystery and I’ve noticed a pattern: people don’t realize they should be using a grid.

A while back I found a command that removes all Ruby gems installed on a system when you’re using rbenv. It worked great, so I decided to build on top of it. After a bit of research, I found a much better solution to the root of my problems: sandboxing Ruby gems.

Man pages are an essential part of every developer’s workflow. Unfortunately, the default system pager less isn’t the best interface. That’s why I wrote a Vim plugin and a short shell function to take care of opening man pages in Vim.