Iterative Design

A lot of my day-to-day production work involves coding up designs into living HTML, CSS and JavaScript. Portland Cafés, my little side project with David, is different.

We initially focused on a working web app; it must function to be of any use. I began with Bootstrap, which was an easy way to throw together some markup and styles. As the site grows it becomes apparent that Bootsrap doesn’t solve our UI problems. Its design doesn’t fit the site’s content, too. But, there’s tests to write, performance to improve, and features to polish.

It’s an exercise in patience. I was finally able to roll out a new menu design last week, which improves navigation particularly for mobile visitors. Baby steps. It’s a new kind of challenge, but a rewarding one.

Commit Messages

Fellow Needmore alumnus Dan Manchester recently wrote about the importance of good commit messages. He provides some quality pointers that seem subtle but significantly improve a project’s history.

Rule 2: Commits should start with a verb.

Specifically, every commit message should start with a present tense action verb. If we think of a commit message as a sentence with the implied subject of “This commit…” , it is our role to write the rest of that sentence…

Having these verbs at the start of commits not only makes them grammatically uniform, it also makes scanning through commit logs easier.

Looking back on a few recent projects, I realize I don’t author commits consistently. Version control is tangential to the task at hand; using it well requires thoughtful communication and constant vigilance. I’m sure current and future teammates will be thankful for seeing even some of Dan’s techniques into practice on our projects.

DevOps Is Hard

My friend David and I recently started work on Portland Cafés. The idea was simple enough: we wanted to know which coffee shops were open and how far away they were.

I wouldn’t say the project was complete, but it was usable. Usable enough to go live. We decided that, in publishing our web app, we wanted to incorporate some sort of automated deployment process.

Roughly, this meant:

  1. We commit some changes on a feature or fix. These commits eventually end up in a “production” branch, master in our case.
  2. Changed files are transmitted to our server.
  3. The server builds the project from the new files.

On the surface, these steps don’t seem very complicated. The most obvious hole occurs between steps 1 and 2: something needs to respond to the post-commit hooks and deal with it. Several services exist to fill this hole. We looked at:

CircleCI was our first choice: their virtual machine runs your tests, deploying only when everything passes. That sounds awesome. After browsing the documentation and hooking it up to the repo, Dave and I quickly realized it was overkill. I wrote exactly one unit test. I don’t think Dave’s written any Ruby tests.

So, we settled on Deploy. Eight hours after pulling our hair out, we were set up.

This was my first experience setting up a legitimate deployment system. It was a nightmare. “Development operations” – the integration and automation portions, at least – requires such a broad and deep understanding of several technologies. We’re fairly focused: Dave’s a Ruby and JavaScript guy, I work in front-end land. All that hair-pulling is especially frustrating because it’s peripheral to our actual work. My time would be better spent designing a part of the app or coding up new features.

The initial setup was hell (I could write a whole article on lessons learned) but it will pay off. Automation is future time saved. Now, merely merging code results in deployment, which is easy and awesome.

If only we could stop Readme updates from firing off the whole thing.

Git’s Rebase

Atlassian has an excellent article on git’s rebase. When first learning git, I was told to avoid rebase like the plague. The article explains it with more nuance:

As an alternative to merging, you can rebase the feature branch onto master branch using the following commands:

git checkout feature
git rebase master

This moves the entire feature branch to begin on the tip of the master branch, effectively incorporating all of the new commits in master. But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch.

Rebasing seems most useful for cleaning up local commits. Interactive rebasing looks like a very cool tool, too. Definitely worth looking in to. There’s also very good illustrations.