tl;dr It’s nerdy and totally overkill.

chef-workstation

A few years ago, I read a blog post by Josh Timberman titled OS X Workstation Management with Chef. This was in the height of my early exploration with chef and “DevOps”. I loved the idea of keeping my desktop machine configuration in sync and set out to create my own version.

The result is my chef-workstation repository used in conjunction with a hosted chef instance.

I use this daily to keep my configuration in sync, but also it means I can reliably rebuild a machine from scratch with minimal effort (and without relying on backups).

Just 5 simple steps!

For my annual upgrade, I like to start fresh. I run the installer from a USB key and re-format my hard drive. This year I tried to note the steps I took following my initial login after the clean install:

1. Update the hostname (Sys Prefs > Sharing). (I also turn on SSH access while I’m here).
2. Install chef-dk - this handy package includes all the chef-related tools I need.
3. Install xcode command line tools: xcode-select --install
4. Create my /etc/chef directory. In the past, I’ve removed my old node and created a new one (using my validator key, kept on a usb drive). This year, I just copied the directory from a backup.
5. Run sudo chef-client. This takes a long time.

Almost perfect…

There are a few things left for me to do once the initial chef run is complete. I’d love to have them automated eventually:

• There doesn’t seem to be a way to install apps from the Mac App Store programatically. So things like Keynote and Tweetbot have to get installed later.
• There’s a lot of logging in required after the fresh install. I use LastPass (for passwords) and Authy (for two factor auth), which both sync all the details, but I still need to re-authenticate everywhere.
• My ~/Projects folder contains my, well, projects. I tend to re-create this (fresh clones, etc) manually. It helps weed out the cruft, but it would be nice to somehow automate.

Feel free to check out the code and offer feedback, or fork it for your very own.

“Read Later” is an Inbox

I don’t know if all of the people who refer to Inbox Zero have ever watched Merlin’s talk or how they practice it, but I’ve gotten quite good at my Gmail version of it. My system is simple: using a combination of stars and not-in-email lists (Todoist, issues, etc) I keep everything out of my inbox following a triage session (which I do a few times per day).

For “read later”, I currently use Pocket (although, I own Instapaper too) which has similar features - and is supported on all of my devices (making capture very easy).

Triage regularly

I put the Pocket app on the home screen of my iPhone, and enabled the ‘unread count’ badge. Those who know me (and have ever seen my phone), know that I’m fairly obsessive about eliminating those little red circles. This helped me form a habit to process a bunch of my Pocket inbox whenever I had a few free moments.

My goal was to triage (note: this doesn’t mean read) 100 articles per day. I set Pocket to show me the oldest first so I could work my way through the backlog.

Be relentless. If you’re like me and want to consume ALL THE INFORMATION, there are probably articles in your list that are no longer relevant. Delete them.

Process and Purge

It may be that you have hundreds of unread articles in your read later queue that are all things you just want to read for the sake of reading. For me, however, I found that my backlog consisted of several types of articles that I was able to skim and act upon to remove them from the queue:

• Restaurant / cafe reviews - if they sound good, I added them to my foursquare todos.
• Interesting apps - I download to try later (side note: google play is so much nicer for this than launching iTunes…)
• Research for a specific project - I send the article to the relevant Evernote notebook (still not 100% sold on this one).

Finally, a lot of my queue tends to be technical articles (performance tricks, coding techniques, new releases, etc). The thing is, without a specific project associated, there isn’t anything actionable for these. Currently, I tag them with the language/framework/etc and archive (skimming first if they’re quick). In theory, they’re still in my archive for someday. In reality, things change quickly and I’m far more apt to just search when I need to know.

Everything else - which is long form articles that I actually just want to sit and read - gets “favorited”.

Now, when I get the chance to sit and read, I open Pocket to my “favorite” queue and enjoy!

I mentioned a few posts ago that I consider Atom to be an important part of my static blog toolkit. It’s true: I’m writing this post with it, using the live Markdown preview. But, I’ve also been using it for day-to-day coding. I’ve been getting actual work done with it. And I’ve been enjoying it!

Atom can be extended by packages written in coffeescript - something I use currently for work - vs. elisp which I haven’t done much with since University. The truth is, though, I haven’t written any Atom packages (yet?). I’m not even sure that I will.

Because I love lists of threes, here we go:

Three Emacs Things I Miss

1. Magit - Having version control (i.e. git) built-in is handy. I’ve been trying Github for Mac, but mostly just using the git command-line.
2. Flymake - I didn’t realize how much I’d come to rely on my flymake setup for writing typo-free (ish) code. I’ve been following and using the Linter package, which will hopefully become a suitable atom equivalent.
3. Years of tuning - my emacs.d configuration has been on github since 2011, in SVN and CVS before that. The regular tweaking has made emacs so comfortable for me that it’s gotten hard to use other things.

Three Atom Things I Love

1. atom - Given my project-switching habits, I’ve long envied the Textmate/Sublime users launching a project (with tree view!) from the command-line. I can now start working on a project by typing atom ~/Projects/<name> and it even remembers which files were open. Projectile has similar project-focused features, but I’m loving a window per-project.
2. Status Bar - It’s amazing how useful a clean, clear status bar can be. Icons! Colours! Not to mention nice plugins like Travis CI Status. I’m finding it far more useful than my emacs mode line.
3. apm (and stars) - Package management for years was a major pain for emacs. While it’s gotten much better lately (and I have enjoyed Cask), apm is proving to be far more useful. Moving between machines? Star the packages you use on atom.io and run apm stars --install.

I don’t know that I’ll ever give up Emacs completely (and I actually use Vim for quick edits), but I have a new, free, cross-platform editor that I like to use - and it’s not even 1.0 yet.

It’s an interesting challenge trying to balance the things I would like to do with all the various life constraints. I want it to be something I can do every day, which means it can’t take too long (some mornings are school mornings) or require too much equipment (some mornings are on the road).

I love reading other people’s routines as I continue to refine my own. My current routine consists of:

1. Doing a quick 10 minute, guided meditation using Headspace.
2. Writing an unfiltered, stream of consciousness 750 words.
3. Having breakfast with a carefully brewed cup of coffee. (yes, I am getting into coffee nerdery)

I have tried much more elaborate schemes, but this current one is simple and effective. Ultimately, I would like to do all of the above before checking email, etc on my phone. However, I can’t say I’m quite there… yet.

I do contract work for multiple clients who each have their own ticketing / issue queue / agile systems. For work, then, I spend most of my day in Jira, Github issues or whatever else they use. Ideally, I book work in “day” chunks, so my morning starts by loading the tools for that day’s client.

My to-do list, however, goes well beyond software tasks. For years and years, I was a remember the milk pro user. Their apps, though, started to lag. I don’t remember what, exactly, had me look elsewhere but (and the timing here was completely coincidental) exactly one year ago today I became a premium user of Todoist.

Everything I am supposed to do in a day (that isn’t directly related to a specific software project) goes into Todoist. I have had the same general structure for several years:

• I keep the number of lists (or projects) minimal: “Personal”, “Work” and recently I have added “House” (before that, “Move”).
• I make use of tags for context. Each client in the “Work” list has a tag, for instance.
• I give every task a deadline. I liberally postpone and shift that deadline, but if it doesn’t have a deadline it will just never get done. Most days begin and end with a review and deadline adjustments.

As for the tool itself, my biggest requirement is ubiquity. I need to be able to capture tasks wherever I am and be confident that it will be available when and where I need it. Todoist has apps and integrations everywhere and I have found the sync to be reliable. Some of the specific features that I use all the time are:

• Gmail integration: for any email that requires a “not right now” action, I create a task, assign a deadline, and the task is then linked to the email (which I then archive so it doesn’t clutter my inbox). When the task is done, I can easily recall the email to fire off whatever “it’s done” message is required and mark the task complete.
• Desktop Mac App: most importantly, the keyboard shortcut to the “quick add” dialogue. When I’m at my computer and a task comes up (during a call, in a chat, or whatever), I hit cmd-ctrl-a and capture the task. After a year, it’s become automatic.
• Location reminders: I find these a little cumbersome to add, but when I have I think they’re great. Anytime I have a “next time I’m at the post office” kind of task, I can set a location reminder and when it detects my phone is there, I get a notification.

Finally, if you’re like me and a total sucker for gamification, Todoist Karma is a fun feature. In my first year, I managed to hit “master” level … well on my way to productivity enlightenment.

However, I got a tweet reply from Boris that triggered an idea. While his suggestion was to write a post with the titles of my “Unpublished Drafts”, I’m going to take it one step further:

I’m going to run this blog like an open source project.

Now, since the switch to jekyll over 3 years ago, the source code for my blog has been open source on github. However, I’m going to open up things a bit further:

• Instead of a post with untitled drafts, I have started to create issues with an “idea label” for blog post ideas.
• Beginning with this post, I’m trying github flow for all new posts. This will result in a new PR.
• And, of course, all posts will be tested on travis-ci.

This might be overkill. It’s an experiment. But, this is (more or less), the way I build software. That’s something I do every day, so maybe it will better integrate blogging with the rest of my flow.

Of course, it also encourages collaboration. I am not expecting a lot of participation on my blog, but I anticipate that giddy feeling the first time someone does! See you on github.

FeedPress

With feedburner all but abandoned by Google, I’ve been on the hunt for something a little more reliable. At some point, I came across FeedPress as a viable alternative.

I had a long standing issue to convert my feedburner feeds over and finally took the plunge. While I wish the stats were real-time, I otherwise have no complaints whatsoever paying a few dollars a month to have reliable feed analytics with some neat features.

Here’s my feedpress affiliate link if you’re interested in checking them out.

Buffer

One thing I quickly noticed with my new FeedPress account: RSS is dead. My subscriber account is way down. What? No, of course that has nothing to do with not posting for a few years.

All the kids these days are are on the social networks. If I want people to read what I write, that’s where I need to be. Buffer makes this easy with scheduling and some additional analytics.

As a bonus, you can have FeedPress automatically post new articles to a connected Buffer account. Now that’s automagical!

Atom

No, not the feed format. Feeds are dead. I’m talking about the hot new text editor from the lovely folks at Github. What makes it great for my Octopress blog? It has built-in live markdown preview that even renders YAML front matter.

This is getting pretty efficient. I may look around for free/open alternatives to FeedPress and Buffer, but for now the seamless integration seems worth it.

Am I missing anything?

There.

So, what’s the first thing that a nerd does before blogging again? Tinker with blogging software, of course.

What’s wrong with Jekyll?

Nothing, really. In fact, I managed to hack together some emacs config and rake tasks that more or less did things the way I wanted them done: easily start a new draft, publish said draft and mindlessly publish (via rsync). It worked pretty well, at least for this blog. (More big claims: I might start other blogs this year).

But there’s Octopress!

When I first converted this blog from Drupal to Jekyll, I remember looking at Octopress. Aside from the “Kubrik of Jekyll” theme, the thing that always bugged me was “start by cloning this repository” as instructions. I want my blogging tool to be a package I install and commands I use to manage my blog.

Apparently, back in October, I stumbled across the next generation of Octopress. I don’t even remember how. (Yes, this post has been a long time coming). A few weeks ago, the official teaser post came out and nicely summarized some of the features. Essentially, Octopress 3 does the things I want and more. Things I dig so far:

1. It’s now a gem with octopress new draft and octopress publish, etc.
2. My rsync rake task is cleanly replaced by octopress deploy
3. Octopress “ink”: allows for installable themes (no more “clone this repo”).
4. You can work on just your current post with octopress isolate which is great when your blog (however sporadically used) dates back over a decade.

Maybe nicer tools won’t make for better writing habits, but it definitely won’t hurt.

Here’s to writing more, in public, at my own domain in 2015.

Two types of Vagrant

What I realized is that I have two ways that I use vagrant (and, of course chef):

1. For local development (generally for PHP-based stuff) where I want to simulate the production environment.
2. To test chef-based deployment of apps (generally anything non-PHP) that I’m developing “locally”.

The first use case requires a lightweight way for me to boot up the environment while I’m working. The later just needs verification that it’s working, but isn’t intended for local use.

The new plan

I still start with berks cookbook for a project. However, instead of running vagrant provision over and over until my cookbooks converge nicely, I’ve started to make use of test-kitchen. If you haven’t yet, check it out. It provides automated testing to make sure my cookbooks work (packages installed properly, services running, etc).

The best part is: this cleanly supports my second use case as is.

However, test-kitchen isn’t designed to be used for my “develop in the VM” scenario. The reality is that those VMs don’t (and shouldn’t) change frequently. Also, from project to project, they tend to be very similar (particularly, say, between Drupal projects).

The best part is: along with Vagrant 1.5 came VagrantCloud. This allows me to easily share (and version!) packaged vagrant boxes. My first one is an ubuntu box for drupal development which is built from my chef-drupal repository. So now things look like:

1. Write my “application” cookbook
2. Test / verify with test-kitchen
3. Vagrant package the box
4. Release the new box on vagrantcloud
5. Start a new project with vagrant init walkah/box-name

No more cloning repositories for similar projects. No need to converge/provision over and over to do development. Yet, I can still keep projects cleanly updated. I like it!

It starts with the ReadyCase

I was an Indiegogo backer of the ReadyCase which I recommend (although, my first-run case needed a little modification to work with my Belkin dock, YMMV). One of the biggest attractions is that it comes with a USB stick - something I never seem to have on me when I need it. Now, as long as I have my phone on me (i.e. always), I have my USB stick.

Partition It

As an early adopter, I got a 16gb version (the max now is 8gb). I split my drive into two partitions: 1 for the Mavericks installer (aka “Mavericks”) and a second partition for “important” files (aka “Data”). It was super simple to set this up using Disk Utility:

• Both partitions are “Mac OS Extended (Journaled)”
• I’m using the GUID Partition scheme (available under “Options”) - required for install disks
• I made the 2nd partition encrypted, just in case.

I am thinking of potentially adjusting this into 3 partitions, though: Installer, Secret files (encrypted) and Scratch (for temporary transfers, etc).

Mavericks Installer

It wasn’t too tricky before, but Mavericks includes a nice little utility for creating “install media”. Once you’ve downlowded the Mavericks installer from the app store, just run:

/Applications/Install\ OS\ X\ Mavericks.app/Contents/Resources/createinstallmedia --volume /Volumes/Mavericks --applicationpath /Applications/Install\ OS\ X\ Mavericks.app

Important Files

So far, my “Important Files” drive includes my ssh private key and a few other handy backups. However, I’m working hard so that more and more of my configuration is automated via my chef-workstation setup. Between that and all of my “in the cloud” data, I can pretty easily bootstrap a new machine in an emergency.

I am prepared.