Task Lists in Our Pull Requests

Note: This was originally posted to the Dynamo Blog.

Since we have been using Pull Requests to drive development over a month or so now, GitHub Task Lists have been an important component. Personally, I have been using them to document my initial thoughts/brainstorming on tasks required to complete a feature and the whole team have been using them pervasively. They also have an impact on issues (from the GitHub post):

You can use task lists to break down large issues and discourage the creation of many microscopic issues, allowing you to focus on interacting with the list instead of editing Markdown.

A Task List can be created in PR comments using GitHub Flavored Markdown. Here’s an example of a Task List from a project I’m currently working on:

And they are easily created with a bit of Markdown:

Oh, and a power tip: pressing ‘M’ on the keyboard will display a Markdown cheat sheet.

How are you using GitHub Tasks Lists? Let us know in the comments.

Recently Launched: Tarkett Sports CMS and Websites

An ongoing project I have been working on at Dynamo over the last year with Hugo Frappier is a custom CMS for Tarkett Sports, a division of the Tarkett Group, "a worldwide leader of innovative and sustainable flooring and sports surface solutions".

A multi-Site, multi-lingual CMS

Tarkett Sports required a multi-site, multi-lingual CMS to serve all the sites of their subdivisions. FieldTurf (North America) was the first to be launched on the new platform, followed by FieldTurf Europe and an API for their iPad sales tool, "Link". At the time of writing, Beynon Sports Surfaces and Tarkett Sports Indoor (North America) are set to launch within the month.

Built on Ruby on Rails and MongoDB

The CMS was built with the usual Rails stack, however MongoDB was used with Mongoid, an Object-Document-Mapper, instead of ActiveRecord and a relational database. This was my first venture in the world of NoSQL, and working with a schema less data store was a perfect match for the CMS. However, it did require a new way of thinking, such as being comfortable with de-normalizing data structures and ensuring those data structures can be properly index. For example, MongoDB does not allow indexing of parallel arrays.

Support a large content-base

Why a custom CMS? Why didn't we just use one of the prominent offerings such as RefineryCMS? I've implemented five RefineryCMS installations over the last couple of years, and Refinery's sweet spot is small websites. Tarkett Sports currently holds over 10,000 content items. Refinery's UI and tree data structure is just not appropriate for such a large content-base.

Publish content collections anywhere in the page hierarchy

We also took a novel approach to the page hierarchy. With platforms such as RefineryCMS and Radiant, structured content (think news and product catalog) containing large data sets are typically supported by creating custom Rails model view, and controller classes. There's usually wrangling to unify the site URLs with the routing system. The Tarkett Sports CMS supports the concept of a collection. A collection of structured content, small or large, can be published anywhere within the page hierarchy. No URL wrangling required, no custom controller class. Collections are a first class citizen.

Reduce custom classes, increase content type re-use

The benefit of all this is that it has reduced the number of custom classes required for a site by increasing the reuse of existing collections and content types. In the past, I have found myself creating custom controllers and models just to support a different content type with the same structure just so I can use it in a different part of the page hierarchy. The concept of publishable collections has solved this.

Below are a few screen shots, showcasing the different sites and portions of the administration screens.

FieldTurf (North America) Home Page

FieldTurf (Europe) Home Page

FieldTurf Products

FieldTurf Product Detail

Tarkett Sports CMS Admin: Pages

Tarkett Sports CMS Admin: Page Detail

Tarkett CMS Sports Admin: Page Publishing

Open Gems with vim-bundler

When working with platforms such as Spree and RefineryCMS it's more than likely that I will be extending their models more often that not. This means opening the Gem to identify a specific behaviour I want to override. Vim is my text editor of choice, and I typically try to restrict my self to one instance of the editor running. It makes working with multiple buffers a lot easier! Whenever I want to open a Ruby Gem, it always irks me that I have to open another instance of the editor, in a separate window/pane (although Tmux reduces the pain of this a wee bit).

Vim does offer a client-server option, but admittedly I couldn't get this working and in my search I came across Tim Pope's vim-bundler. From the README:

An internalized version of bundle open : :Bopen (and :Bsplit , :Btabedit , etc.).

Exactly what I wanted, a way to `bundle open` within Vim. Here's a quick demo of using vim-bundler to open Spree's `Order` model and navigate to the `add_variant` method.

vim-bundler from Nicholas Henry on Vimeo.

Creating Dedicated, Focused Time

Note: This was originally posted to the Dynamo Blog.

Working on multiple projects in a single day has a mental cost and less efficient than dedicating time to a single project. Segmenting the week to work on a specific project and allocating time for the unexpected is one possible solution for reducing the cost of context switching.

Yesterday we had a terrific conversation in our weekly project mini-retrospective about the cost of context switching in the studio. This is a problem that any service-based company with multiple clients has, but it’s a tough problem specifically when providing creative services. At Dynamo, we’re working on engaging problems, which require dedicated, focused time to solve.

However, during the day we might be working on multiple projects, and there are maintenance tasks competing for our attention. So how might we reduce the context switching to create dedicated, focused time?

Our solution has four components:

1. Segment the week to dedicate specific days to a project, depending on the velocity required.
2. Assign a dedicated day to work on maintenance. This is planning for the unexpected, and the unexpected always happens.
3. Publish your schedule. Let your team members and project managers know what days you have assigned.
4. Project managers will be mindful of these assigned days.

The last component is the key. When project managers know the maintenance day of the project’s maintainer, then expectations can be appropriately set with the client when a maintenance task can be completed.

Of course, emergencies and rush tasks are always going to arise. But, in reality these are rare. So I plan to put this into practice, and I will let you know how it goes. How do you reduce the context switching to create dedicated, focused time? Let us know in the comments.

Taming the pile of unread books

Recently I posted to Facebook:

You know you have a book buying problem when... you discover that you have two copies of the same book on your bookshelf. Unread.

Yes, I have a book buying problem. And after that post I decided it was time to do something about it. I love reading. I find it extremely motivating and inspiring. But having a few dozen unread or partially started books is not only a waste of money, but just another open loop in my life that just doesn't need to be there. Jumping from book to book also inhibits in my ability to really understanding a book.

And before you start thinking I'm talking about a pile of trashy romance novels, I am talking about computer and business related books!

So how did it get this way?

I have always had a stack of unread books around, but I typically got through the queue. However, with eBooks it really has got out of control. I start with reading an inspiring blog post, or watching a video of a conference talk, it references a book and wham! Next moment, I'm online purchasing that sucker.

So what have I done to resolve this?

It was pretty simple really. I present to you, my three step plan:

1. First, I took inventory. I identified the books as unopened, "briefly" started (read a few chapters), and "well" started (at least half way through).
2. For those that were briefly started, I removed bookmarks, virtual or physical, and added them to the unopened pile. Basically, calling bankruptcy on the "briefly" started. This cleared a lot of open loops. A lot.
3. With the "well" started books I recorded them in OmniFocus. This has helped me to keep conscious of how many books I have on the go. This ended up being four in total. The goal is to have no more than two in progress.

Since starting this two weeks ago, I have completed one book, and will finish the second this week. I will be at my goal of two in progress. Oh, and I haven't bought any new books in the last two weeks -- there have been a couple of occasions where I would have.

Yes, I know this all sounds pretty ridiculous. However, I bet I'm not the only developer out there, with a book addiction. If you are, please let me know in the comments, how you have curbed your book buying behaviour, or please give my recovery plan a go!

April Developer Challenge: Feature Development With Pull Requests

Note: This was originally posted to the Dynamo Blog.

This month’s Dynamo Developer Challenge has been inspired by our own Daniel Wright—more about that in the moment.

In a nutshell, for the month of April we will be experimenting across the studio with using Pull Requests to develop a new features. We are moving beyond simply using them as a Code Review tool, as we have in a past challenge.

Over the last few months, Daniel has been religiously using Pull Requests to push new features. As I’m a bit of GitHub stalker I love seeing this, as it gives me a chance to provide feedback on commits and putting Code Reviews into practice. However, these Pull Requests were created once the feature was deemed “done.”

After viewing Zach Holman’s slides from a talk titled GitHub: Behind the Feature, Daniel began creating Pull Requests at the start of a new feature. And I’ve been impressed by what I have seen so far! But I don’t want to get a head of myself; I’ll share some observations at the end of this challenge.

So, how does this all work?

Here’s some steps, based on the write-up Daniel did for his current project:

1. Choose a feature to implement, and create a new Git feature branch for it.
2. Once you’ve selected your feature to work on, you’d create a new branch for it: git checkout -b features/your-new-feature
3. Now do a very small amount of work, just enough that you can commit it. For example, you might create the view-template you’re going to use (e.g. app/views/pages/about.html.haml).
4. Now commit it! git add . && git commit -m "Adds about page template"
5. Push your branch up to GitHub: git push -u origin HEAD
6. Finally, visit the project page on GitHub and create the pull request. Since you just pushed the branch, the project’s landing-page should prompt you to create the pull request. Give it a descriptive title, and describe what you’re planning to accomplish with the PR. For a simple integration job, this should be fairly straightforward, but you can be as descriptive as you like.
7. Submit the pull request!

So, the April challenge has been posted for our Dynamo-Devs, but we encourage you to join us too. Are you up for the challenge? Please share you experiences in the comments along with our team’s.

For a little more background on this development strategy, checkout the slides below:

Developer Challenges: Helping Us to Improve Our Craft

NOTE: This was originally posted to the Dynamo Blog.

We’re sharing an initiative that we’ve been experimenting off and on over the last year called “Improving Your Craft”, a.k.a Dynamo Developer Challenges.

These began as weekly challenges to help the team members and the team as a whole to improve development practices and increase developer happiness. Admittedly, when I was first driving this initiative, I was infrequent in posting these challenges, and the weekly schedule was a little too ambitious. Based on feedback from the team, we reduced the frequency to a monthly schedule, and I’m more disciplined in posting challenges each month—a calendar reminder really helps!

Here are some examples of the challenges posted to date:

• Self-Directed Morning Code Review
  Inspired by Jason Fried’s post Morning tells the truth, this challenge asked developers to review their commit log from the previous day as a self-directed code review.
• Pull Requests for Code Reviews
  This time it was Zach Holman’s talk How GitHub Uses GitHub to Build GitHub. The driver for this challenge was to encourage developers to review each others code, pollinating knowledge across projects. If you’re not currently using pull requests, GitHub has some great documentation on the topic.
• In-Person Peer Code Reviews
  As an extension to the previous challenge, developers were asked to sit down with a peer for a 30-minute code walkthrough. It’s amazing how much the author of the code learns by just walking someone else through it.
• Automation
  A final example was encouraged developers to start thinking what they can do to optimize their workflow. Too often we run the same set of commands everyday, when a simple shell alias can save us from repetitive typing or making a time-consuming mistake.

Hopefully this gives you a feel of the type of challenges that the team has been working on. And we would love if you joined us! Previously, these challenges have been posted to our Basecamp account, but we will now be posting them to the blog. I encourage you to share your experiences in the comments and the team will be sharing their as well, either as comments or blog posts (hint, hint!).

Although I’m a little late this month for April’s challenge, please be on the lookout tomorrow.