A Bit of Git coming soon

I’m excited to announce that I’ve been writing a book, titled A Bit of Git.


I use the version control system Git for everything. It’s been crucial in building almost every software project I’ve worked on in the last five years, and with the rise of GitHub, it’s become even more crucial to my daily workflow.

Git suffers from an immense learning curve. My experience in learning Git was mostly trial and error, and I found that it was only when I worked with other people on Git-managed projects that I started to become sure that what I was doing was “correct”.

I think this is avoidable. I’m a big fan of the Pareto principle, summed as “80% of the effects comes from 20% of the causes”. This is incredibly applicable to Git, where the vast majority of knowledge about how Git works and the commands that come with it are just not needed for a beginning Git user. While great Git books exist about how to understand Git from the inside out, I would have loved a book that laid out the primary few tasks I would be doing in Git, and quickly taught me how to accomplish those tasks.

A Bit of Git will be available for $9.99 on Amazon, and includes seven chapters:

  1. Learning the ABO way
  2. Installing Git
  3. Interacting with files, and handling changes
  4. Branching and merging
  5. GitHub and the remote model
  6. Common Git interactions: The pull request
  7. Common Git interactions: Working with a team

The content is very focused – by the end of the book, you’ll feel comfortable using Git on software projects large and small, on a team, and solo. This is that crucial 20% you need to be effective with Git, no more.

As the book writing wraps up, I’ll be including some bonus content here on the site: a screencast with my daily Git workflow, the sample Git project I use in the book, and a blog post about the auxiliary tools I’m using around Git day-to-day.

The book is on Amazon today, with a planned release of December 31, 2015. I’ve partnered with Amazon to do their KDP program, meaning the book will be available for free for the first three months of publication. Since this is my first book release, I thought I’d experiment a bit and see what readership numbers I can reach in the first couple months. The hope is to see it pop up in some places for people learning programming, like Reddit, Hacker News, etc.

Random (but useful) data in Paw

I’m a big fan of Paw, a REST client for Mac. I use it primarily for API documentation – with the right plugins, it exports flawless Markdown documentation that fits perfectly in your Git repository.

Most developers have problems with picking good test data. Think how many times you’ve tested a form by typing “asdfghjk<TAB>asdfghj<TAB>”. When you’re testing various types of input, random text isn’t the best solution – especially with different types of input, like emails, and addresses.

In designs, we get through this problem by using Lorem Ipsum (though the use of that is controversial), but in development, there are very practical reasons to add “good data”. Adding a valid email address to a form in order to validate format on the backend is a better idea than just typing gibberish in that input.

This morning, I was looking for a good solution to random data in Paw requests. As a Rubyist, Faker came to mind. Paw has extensions, but they’re in JavaScript, so I gave Faker.js a shot. Unfortunately, the JS format of Paw’s extensions is pretty simple – they use Apple’s built-in JavaScript interpreter, so things like ES6 and modules are out of the question. Because Faker.js is a fairly popular library, it includes a lot of support for various module solutions, but I couldn’t get Paw to pick it up like an old-school “global” JavaScript library.


Instead, I found a Paw extension for Chance.js. Chance.js has a wide variety of things to be randomized, including names, addresses, and various social media username formats. Unfortunately, limitations of Paw’s “Dynamic Value” extensions don’t allow discovery of these types. For instance, I tried first_name and last_name a couple times before realizing I wanted first and last, instead.

The solution was to create a Dash docset for Chance.js. I did this by using Dashing, a Go tool for converting HTML into a Dash docset. I hadn’t heard of this tool before today, but it’s super cool – you specify CSS3 selectors that correspond to Dash data types.

"selectors": {
"dt a": "Command",
"title": "Package"

The JSON for Chance was pretty similar – the docs are a single page with each method under the CSS selector article.method. I cloned the gh-pages branch, compiled it with jekyll build, and ran Dashing against the HTML output. The result was a functional Chance.js.docset that I’ve been using happily this morning. You can find it here:


Apple Music’s “Intro to” Series

I’ve really been enjoying Apple Music. It combines the great parts of iTunes Match (ubiquitous library, consistent streaming reliability) with the huge selection of a modern streaming service.

One of my favorite discoveries is the “Intro to…” series of playlists. For a huge selection of artists on Apple Music, a playlist has been created by Apple with a good sampling of their “best” (or at least, most popular) songs. Interestingly enough, these playlists also serve as a great indicator of some of the most fundamental problems in Apple Music.

Intro to Stars of the Lid

I was enjoying this playlist of songs by the ambient group Stars of the Lid – a lot, actually. I added it to my library by clicking the “+” icon that was located at the top-right (of course, after adding, it becomes a check mark, as seen above). The problem with this is that doing this doesn’t add the songs to your library. It adds just the playlist. Out of habit, I now go back to the predominant album in the playlist and add it to my library, so some of the songs from this playlist actually end up in my library. The separation of songs and playlists in Apple Music is incredibly weird, and I’m not sure what Apple’s intentions are in making this extra step required.

Second is the “attribution” of the playlist – “by Apple Music Experimental“. Who? Only by searching for the name do we find that it is actually a “curator”:


Turns out that the curator section is incredible. While writing this, I added (checked?) a huge number of the playlists by Apple Music Experimental. The problem is that none of them are discoverable. Unless you’re viewing an artist that is part of those playlists, searching manually for the curator is the only way to find this amazing selection. Of course, the “For You” section is supposed to be the main point of exposure to these playlists, but again, the curator names aren’t selectable.

Apple seems to be a bit indecisive – curators are discoverable, kinda. But they aren’t exposed like a focal point of the service. I’m hoping that future updates of the service will make this a bit easier. FWIW, Apple Music seems to be a client-side application – here’s hoping that an update to support curator discovery is more trivial than a point release of iOS.

PostgreSQL as default

I found a nice series titled “What PostgreSQL has over other open source SQL databases” via Hacker News. The premise – there are many databases you could pick for a project, based on scaling needs, write consistency, etc. That said, PostgreSQL is the right choice most of the time. It continues to be fast and easy to use, compared to other database tools. When you begin needing more than basic read/write operations, PostgreSQL usually has what you need, tucked away. If not, it likely has a reasonable explanation for why it isn’t included.

I’m currently recording a Pluralsight course called “Integrating Payments with Ruby on Rails”. In the course, I use the Stripe API to build a simple subscription service on top of Ruby on Rails. Stripe handles the heavy-duty parts of the payment system. Our database tables: users, subscriptions, and the actual data model provided by the subscription. Pretty straightforward! In the course, the first topic is how we architect the application. Rails, of course, but also the database – Postgres.

There are many “hotter” database solutions out there – JSON-based like MongoDB, or real-time cloud systems like Firebase. Postgres is a great example of my favorite economics tool, the Pareto principle (also known as the 80/20 rule). In this context, 20% of Postgres’ feature set meets 80% of our requirements from a database. In my course application, we don’t need more than basic tables and relations. Postgres does this instinctually, and building it in Rails is trivial. In this situation, these architecture decisions are pretty much a no-brainer. When we need to expand our feature set (that last 20%), there’s a good chance that the additional features in Postgres will do the trick. Consider the following example:

In Stripe’s subscription API, a request with credit card information is passed to Stripe – they validate it, and respond with JSON containing a “customer” object”:

There’s a ton of information in there – some of it is more useful than others. We could take the time to pull out the relevant information: id seems immediately useful, as it’s the way we’ll now communicate with that user instance on Stripe. created could be useful as well, to track the length of subscription. We’ll take those values and map them to a subscription table. But what happens when it turns out we wanted the cards list as well? Maybe the customer has an existing Stripe account, and by leveraging the fact that Stripe is used all over the web, we could allow our users to change the “active” card for their subscription.

What we need to do is, of course, store everything in this object. If we were in MongoDB, we could dump this into a StripeCustomer collection and be on our way. Luckily Postgres has a similar json field that does the trick. To keep things simple, we could even just dump the entire object into a stripe_customer row, and get things like Postgres’ validation for free. For instance, the customer JSON can be considered invalid if the id field is nil.

Here’s another short example: I’m building a mobile application with a focus on real-time communication between people in groups. I could build it in Rails, but I know that Rails isn’t the best choice for real-time. Instead, I took a gamble – I’m building it in Elixir, using the Phoenix framework. Phoenix is Rails-like, but with “channels” (like WebSockets) built-in. Real-time communication is a first-class citizen in Phoenix. I’m picking something different than the obvious 80/20 choice because I know my requirements. This is an acceptable compromise for when to pick the “less hot”, reliable tools – when you need something that tool doesn’t offer, from day one.

I’m a big fan of Tesla – I pretty much salivate over every Model S I see drive-by on the road. Day-to-day however, I really like my car: a Mazda. Why do I love my Mazda (to the point where I’m grinning when I get in the driver’s seat)? Because it does the 80% that I need – it drives well, it has enough “extras” to make traveling easier, and it’s literally is about 20% the price of a Tesla. Funny how that works. There may be a day when I roll up to the Tesla dealership and get the insane $125k version of that car. But for now, my car works really well, and by the same token, so does Postgres. When you’re storing billions of rows, Postgres will probably still be kick-ass, but at that point, you can consider alternative options because you can actually encounter bottlenecks at that scale.

The tl;dr? Don’t over-optimize – it is a very common trap. Use Postgres until they rip it from your cold, dead hands.

My favorite to-do app updates to reach perfection

For years I’ve looked for a “perfect” to-do application. Of course, a perfect one doesn’t exist, but there are so many to choose from that my baseline requirements are pretty well-defined at this point:

  • Native, cross-platform (iOS/Mac, web optional)
  • Notification support
  • Easy to create notifications, easy to complete them

Pretty much all the big hitters in the to-do space do this, and for a while, I even went above and beyond that with GTD applications like OmniFocus.

For about a year and a half, I’ve consistently been using the same application: Due. Due is a very basic to-do application with one killer feature: reminders never go away, unless you complete them.

One task this has been helpful in is reminding me to do my laundry. On Sunday night at 6pm, the first notification is fired from Due. If I don’t immediately go complete it, Due will remind me… every… single… hour, until it’s done. It is really annoying, but incredibly handy. The reality is that our schedules are not as set in stone as we think, and Due handles this by allowing you to push off tasks for another ten minutes, an hour, etc., until you can complete it.

This idea of persistence has been incredibly useful for me, to the point where every task I have goes in Due. I probably have a task go off every hour in Due. It’s been a real game-changer.

My one issue (and it’s minor) is that it hasn’t been very easy to add new tasks to Due. You can, of course, add from the application on your phone or computer, but as a power-user on both platforms, I’d love a way to do this more quickly. In the newest version of Due (2.2), the developer added support for importing from Reminders.app. This brings it to feature-parity with a lot of iOS apps that do the same, and this brings two awesome (and frankly, under-mentioned) abilities to Due:

Siri support

I was surprised to see the developer not mention this, but since Siri writes to Reminders.app, Due now supports Siri, indirectly. Interestingly, OmniFocus did a identical thing (with a launch video and all) as a big announcement – this is literally identical, but understated.

Power-user tools

In a classic Apple move, Reminders works great, but provides pretty much no extensibility. The landscape of tools supporting interfacing Reminders directly is pretty weak (even more so after the move to iCloud), but one shining light still stands (but probably not for long) – Applescript. A great example of this is the Alfred workflow for adding Reminders, which I use now to push things into Due from anywhere on my computer.

The lack of hype on both of these as they pertain to Due’s new update is a bit concerning – maybe the user base for the application is smaller than I thought, or the developer has essentially moved on and this is just a maintenance update. Either way, the app is still handling my day-to-day perfectly fine, and with these updates, has become even better.

Joining Pluralsight

I’m very happy to announce that I’ve joined Pluralsight as a instructor. I’ve been looking for an opportunity to teach programming topics, and Pluralsight will give me the opportunity to leapfrog audience size from a fairly small YouTube channel to 750,000 interested learners.

My first course will be on integrating payments with Ruby on Rails, using Stripe. I’ve done a fair amount of work in various projects on this topic, and it should be a good chance to update and expand some of the Rails content on Pluralsight. Look for it coming by the end of the year, hopefully in the next couple months.

The best way to move to the Colemak keyboard layout

The original QWERTY keyboard layout is inefficient. It was developed in 1873 – originally for typewriters, but as newer technology was manufactured, it stuck as the layout of choice.. It’s been over a century and we’re still using it. This is because switching is really hard. It’s essentially the same as a piano player trying to play a piano in which every single key has been switched.

I like the Colemak layout. It’s a practical layout comparatively to the “fastest”1 keyboard layout, Dvorak. I’m not going to go into too much detail about why you would switch; I was having RSI problems and switching to Colemak seems to have helped a bit, so far. Jason Trill has a great post on the ErgoDox keyboard that includes great keyboard heatmaps – a representation of how typing is distributed on the physical keyboard. The below example shows a large Javascript framework being typed on each layout.


qwerty heatmap


colemak heatmap

What I am going to talk about is the best way I’ve found to switch to Colemak. There are seventeen keys moved from QWERTY to Colemak (versus Dvorak in which, from what I can tell, every key is changed), so it’s not a complete change, but still pretty comprehensive.

Enter Tarmak. Tarmak is an ingenious system devised in the Colemak forums, which acts as a “transitional” layout system from QWERTY to Colemak. Here’s a nice GIF from the introductory forum post that sums it up well:


The transition period was fairly smooth, though I noticed that the final steps were the hardest; specifically moving some of the vowels (I and O). I spent about a month moving in total, with about one week per step. You shouldn’t expect to be at maximum typing speed immediately – I switched about two months ago and I still have some inaccuracies day-to-day. When should you switch? Here’s a nice answer from the Colemak forum:

I think focusing on accuracy is very important when considering when to level up. From my experience I suggest the aim should be between 95-100% combined with a speed of >25WPM. Having a greater speed initially helps, as performance will very likely decrease when adding more keys from the colemak layout.

The forum includes various downloads for most operating systems. I used this [Github project] that adds Tarmak options in the native OS X keyboard layouts. I was happy to see that once I finished Tarmak, Mac OS X had Colemak built-in. You can find all the various layouts in “Input Sources” under the Keyboard section of System Preferences.

Screen Shot 2015-08-16 at 10.31.00 PM

Unfortunately, iOS doesn’t have Colemak support for day-to-day typing, but does have it for Bluetooth keyboards. I find that I type fine on my phone still, but interestingly enough, I revert back to Colemak sometimes when I’m not looking.

Overall, the move to Colemak seems to be a win so far – my wrists feel a bit better, and it’s another item checked on my ergonomic to-do list.

Some shorter-form content

It’s been a while since I wrote on this site. I’ve been busy, but not that busy. I just haven’t had anything of substantial length to write about. In the interest of keeping content coming more regularly, I’m going to begin writing more short-form content. I’m shooting for at least one a week. Hoping to get the next one up in the next couple days.

Starting a new Rails application

Greenfielding a Rails application is an exciting process. That being said, all the ambition in the world can be halted or slowed down easily by bad tooling. In this post, I’ll talk a bit about some of my recommendations for building a new Rails app.

Whiteboard, whiteboard, whiteboard

A couple years ago, I was building a fairly simple web app for a client. She was an author and her website was essentially a list of her books and where to buy them online. Like I said, very simple. We spent some time drawing out the layout of the site in our initial meeting. In my head, I was considering the ramifications of her requirements: at first glance, it seemed like she didn’t need more than a static, single-page site. Then we talked more about the “orbiting” features of that single, simple requirement. She wanted:

  1. The ability to add additional “links” per book. A book might begin by only being on sale at Lulu, but will eventually be available on Amazon.
  2. The ability to add “testimonials” per book.
  3. Last but not least, the ability to add more books as her bibliography grew.

This was not a static, single-page application. This was a dynamic site with a light CRM behind it. The amount of code needed for this project changed from a flyer to a novella.

This is the kind of HUGE thing you catch in whiteboarding. Structural and architectural issues that completely redefine how your application looks. In my case, this awareness led to an entirely different contract estimation, but more importantly, long-term satisfaction for the client and myself.

Day-to-day happiness, not just for engineers

The verdict is in at this point: HTML and CSS are not the most efficient way to write websites. Are you on a team with designers and copywriters, not just engineers? Consider using SASS for your CSS and HAML for your HTML. Engineers are obsessed with clean, modular code; allow your designers to be the same way.

Technical bits: the part where Kristian lists a lot of Ruby gems

Part of the reason I keep coming back to Rails is the huge amount of open source tools around it. Here are some of my favorites:

Database: Postgresql

There are very few reasons to not pick Postgres as your application’s database. It has a double advantage: not only is it the de-facto choice for most applications, it also actually earns that designation. It does the things you’d expect from a relational database, but it also has some tricks up its sleeve: for instance, Postgres 9.4 includes a JSON type – if you were thinking about picking MongoDB or another NoSQL database, you might be surprised to learn that Postgres outperforms Mongo at its own game.

Memory store: Redis

Redis is an insanely powerful memory store with a great Ruby interface. I try to cache as much as possible – for instance, if a database request is slow, cache the result for a couple minutes (or as appropriate) so that each user isn’t hammering the database.


  • better_errors: Although Rails 4 introduced web_console, better_errors is the original (and in my opinion, better) tool. When your app raises an exception, better_errors will helpfully open a REPL and stack trace in-browser. You can even navigate up the trace and continue to use the REPL at any point in the stack. I put this in every Rails app I develop on. It has saved me hours.


  • pry is a replacement debugger for Ruby. If you’re using Rails, pry-rails replaces the Rails console. The real trick is using pry as you develop: pry-rescue will open a pry instance on exceptions, and binding.pry will open pry where specified. Very handy when code is behaving unexpectedly.

  • simplecov is a code coverage tool. You’re writing tests, right? simplecov checks every line of code to see if there’s a corresponding test. While most projects don’t have 100% code coverage, I usually strive for over 80% coverage.

  • sidekiq is, in my opinion, the best background job tool for Ruby. The reality is that almost every performance issue I see in Rails apps are because someone isn’t backgrounding a task in their app. With Rails 4, job processing is easier than ever with ActiveJob. Background your stuff – it’s a win-win for developers and users.

There is a lot of other tools that I integrate into Rails apps as they grow in size, but if you start with some solid basics, your app will be in a better position to scale than a off-the-shelf Rails app. Having problems scaling? Let’s talk.

Some thoughts on nipping burnout

I recognized, as I do about once a year, the symptoms of burnout coming on this last Friday afternoon.

Here’s the frustrating thing about burnout: it’s non-deterministic. It doesn’t wait for a slow week, and it isn’t afraid to strike when you’re doing good work. This last week I’ve been working on a fairly massive project, one that requires keeping track of a lot of things at once. When I come back in the morning to work on it, it takes me fifteen minutes just to get back in the groove to work on it. This isn’t something boring: it’s an interesting project that has helped me become a better programmer, and it has a fairly large influence and positive effect if done correctly. It is, by all accounts, something I’m happy to be working on. Regardless, on Friday afternoon, I began to feel this sense of dread creeping in. So much code. So much to keep track of. Can I go somewhere else for the rest of the day, please? Hello, burnout.

Burnout manifests itself in various ways for people – for me, I always think of the stereotypical scene in a movie, where a cubicle worker stares at his CRT monitor with dead eyes. It’s hard to feel like the thing you’re working on is surmountable, and you don’t really know how (or want to, honestly) proceed. This feeling is different than dissatisfaction with your job, for me: I’m really happy where I work and the organizational structure is great. It’s a matter of exhaustion, and while outside forces might flame the fires, it’s really something going on internally.

This might be fake but it was too depressing to not include.
This might be fake but it was too sad to not include.

I want to be clear – a lot of the symptoms of burnout are very close to depression. That being said, if you think that you are experiencing depression, please seek help. I am not a doctor, I’m just some dude on the internet. Me being bummed out and tired of writing code is nothing compared to actual depression. /disclaimer

I spent the weekend trying to nip what I perceived as the beginning of this burnout before it took hold. Here are a couple tips that I suggest:

1. Get away from the computer. 

This could be more generally stated as “take some time away from your thing”. If you’re burned out as a professional musician, the fix isn’t to go play guitar until you like it again. I program all day – this weekend, I stayed far away from code, work email, even the programming industry at large. That means no Twitter, no Hacker News. It’s easier than you’d think. This is pretty obvious, especially because so many of us have integrated computers so heavily into our lives that they ARE the main part of our lives. Give it a rest for the weekend.

2. Exercise the neglected parts of your brain

You have a big, beautiful brain – it can do a ton of things and it’s probably helped you get to some amazing places.

Imagine our brain was a car. It’s good to wash your car and take it in to a repair shop to make sure it’s in top shape. Sometimes, we treat our brain like a car that only gets the tires rotated, and nothing else. I almost always exclusively exercise the part of my mind that’s analytical: when I write code or reason about problems, that part of the brain is spinning as fast as it possibly can. But what if I never check the other parts of that car? Is car functioning if the tires are pristine, but the oil hasn’t been changed for a hundred thousand miles? Probably not.

I find reading fiction super relaxing in this case. I spend a ton of time reading technical books and career books, and in a lot ways, reading those books is basically the equivalent of continuing working into the evening. A lot of people are concerned that if they aren’t “switched on” (ALWAYS progressing in their field, staying at the cutting-edge), they’ll fall behind. In the same way, weightlifters don’t deadlift their PR (personal record) seven days a week. They take days off, or they come in and focus on strengthening other areas. Find the parts of your brain that you haven’t been in contact with for a while; for most of us, that’s the imaginative and creative parts of our brain. Trust me, it’s a lot of fun over there!

3. Shut off your brain for a bit

About a year and a half ago, I was feeling pretty dissatisfied with the work I was doing and was regularly stressing out about pretty much nothing. There was no concrete thing to latch on to – it was stressing out for the sake of stressing out. I decided to try something a bit new, and drove up to a Buddhist temple forty-five minutes away and meditated with a group for about an hour. It was wonderful. Since then, I’ve somewhat regularly meditated: normally when I begin to feel stress, though recently I’ve begun to do it more regularly just as a habit.

Meditation doesn’t have to be hand-wavey and mystical – it’s simply sitting down and letting your brain do its thing without you filling it full of your life junk. It’s a bizarre phenomenon that is hard to explain until you experience it. There’s a wonderful clarity that comes out of meditation, enough so that I’d consider it the killer item on this list. It won’t solve all your problems, but at the least, it might help identify what those problems are.

We live in the age of apps, of course, so if you’re interested in trying this, I recommend guided meditation with Headspace. It’s super useful; I’ll probably do a session after finishing this post.

Those are my three tips – not an exhaustive list, and it definitely won’t help everyone. For me, this does the trick (normally), and on this Sunday afternoon, I’m cautiously excited to get back to work tomorrow. Are you experiencing burnout or have you successfully fought back against it? I’d love to hear your stories.

Leveling up, a day at a time