June Developer Challenge: Share the Knowledge

Note: This was originally posted to the Dynamo Blog.

Last month we leveled-up with Crush Your Achilles’ Heel. This month, it’s about helping your team members level-up with “Share the Knowledge”. This month’s focus is about sharing knowledge with your team mates. After years as a solo freelancer, one of the great joys I now experience working with a team, is the learning gained from my team members. I also love sharing what I’ve learned. However, we need to be proactive about sharing to allow others to benefit.

This month, your challenge is to take what you learned from last month’s challenge, and share it with your team members. At Dynamo, we have a number of avenues for sharing information with others. These include:

• Workshop Wednesdays: Lunch-time sessions for presentations and discussions
• Dynamo Central: A wiki hosted on GitHub to share process and procedures
• Dynamo Blog: This blog to share with the greater design and development community
• Dynamo Retreat: A yearly event to review what’s working, and what’s not

So choose something valuable from last month’s challenge to share. If you didn’t complete the challenge, I’m sure you have something else. Do you have a checklist or procedure documented in your notebook? Do you have a process that you’re benefiting from, but no one knows about it? I encourage you to share this knowledge as a presentation, a blog post, or simply as a checklist on the wiki.

Your Developer Challenge for the month of June has been issued! Please let us know what you attend to share this month in the comments below.

Ron Jeffries on Requirements

This is one of my favourite quotes on requirements:

Most of us were taught to write down all our requirements at the very beginning of the project. There are only three things wrong with this: “requirements,” “the very beginning,” and “all.” At the very beginning, we know less about our project than we’ll ever know again. This is the worst possible moment to be making firm decisions about what we “require.”

From Estimation is Evil, Ron Jeffries: Signatory of the Manifesto for Agile Software Development 

May Developer Challenge: Crush Your Achilles' Heel

Note: This was originally posted to the Dynamo Blog.

We all have it. It’s that gap in our knowledge that slows our development down. It’s your Achilles’ Heel. Every day we use the same tool, but we’re never really take the time to understand the fundamentals of how it works. This might be Git, SQL, or Regular Expressions. It might be a concept that we struggle with, but have never said, “OK, I need to dedicate some time to really understand this”. So this month, it’s time to crush it.

Inspired by RailsConf talk ”Nobody will Train You but You” from Zach Briggs, your challenge for the month of May is to identify a weakness in your development knowledge, and proactively train yourself in that area. Since the beginning of the year, I have been proactively addressing weakness in my development knowledge. Here are examples:

• SQL: After years of working with Rail’s ORM, ActiveRecord, I felt my knowledge of SQL beginning to wane. I went back to basics and completed Standford University’s course on databases. After this course, I had cleared out those SQL cobwebs, and back to feeling comfortable working at the SQL console again.
• NewRelic: Normally I use NewRelic in periods of stress, trying to resolve a performance issue. This means revisiting and learning the UI while I’m trying to solve a problem. By dedicating two afternoons to reading the documentation and reviewing a live application’s metrics, I feel much more prepared to dive in when there’s a performance fire.
• Performance Optimization: I’ve addressed performance in an ad-hoc manner in the past. To resolve this. I have dedicated time to review various resources on performance including the Scaling Rails series (which is developed a couple a few years ago, but still relevant). This resulted in a cheat sheet that I actively use to think about performance from day one.

But this challenge doesn’t end with passively reading a book or watching a screencast. It’s about reinforcing your knowledge by sharing with others. You really understand a topic, when you share it with others. So after spending the month learning, next month I encourage you to write a blog post, perform a workshop or write a test suite demonstrating what you have learnt.

So here’s the plan:

1. Take the week to identify your areas of weakness. As you go through your day, write down these areas as you experience them.
2. Pick an area at the end of the week to work on. At this point, you might want to consider how you will share your knowledge. Please share your topic in the comments below.
3. Develop a plan on how you’re going to improve your knowledge. Don’t try to be too ambitious, keep your goals realistic. Think SMART.
4. Work through your plan for the month.
5. At the end of this month commit to how you would like to share your knowledge. We will prepare to share our knowledge in the month of June.

OK, your Developer Challenge of the month of May has been issued! Please don’t forget to share your topic in the comments below. Good luck with crushing your Achilles’ Heel.

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.