Why Katas

The Merriam-Webster dictionary provides the following definition for kata

Kata

a set combination of positions and movements (as in karate) performed as an exercise

Most people are probably familiar with katas as they are used in martial arts (come on, admit it, you liked the Karate Kid).  My introduction to katas in software was through the Software Craftsmanship movement, where they are often used as training exercises.

It is important to understand with coding katas that the idea is not to do the exercises the same way every time.  Katas are a great way to experiment with different techniques and styles.

• Can I provide more descriptive naming
• Does a terse syntax make the code easier or harder to understand in a particular place.  Would a more verbose, explicit approach be better.  For example, in the case of a complex ternary operator, would an explicit structured if/else construct be better?  Worse?  Try them out and decide for yourself.
• Experiment with different syntax, e.g. the unless keyword in Ruby.  More or less readable?
• Should I use a defensive programming style checking for nil/null in several places or a more confident programming style?
• How am I naming my tests (yes you should be writing tests as part of your katas)

There are no right or wrong answers to these questions, the goal is to experiment and try out new ideas.  Understand where an idea works well and where it doesn’t work well.  Try a variety of approaches.  And the great thing about a kata, unlike your code base at your real job, is that you can blow it away when you are done and do it a little different the next time.

Katas and Interviews

I’ve been using pairing as a key part of the interview process for several years now, but a consistent challenge is to what to pair on.  It is unrealistic to assume that most developers are going to walk in the door and instantly grok your code base.  No matter how awesome you are or how descriptive the tests are, it’s just not gonna happen. Instead pick a problem set that a candidate can quickly get their head around and that you can discuss different design and implementation choices.

Katas and Pairing

I had an awesome pairing session yesterday with someone I had never worked with before, and we did some katas as a way to get to know one another, discuss approaches to coding, good naming, refactoring techniques.  It was a blast!

And the really great thing about katas and pairing is that it can be challenging to think of different ways to try something on your own.  But with a pair you have different perspectives baked-in.  And what you can learn may not be strictly code related: it could be keyboard shortcuts, different IDEs or editors, maybe even a wacky keyboard.  Don’t be afraid to experiment.

Resources for Katas

Cyber Dojo
Great resource for ideas for simple exercises.  Even if you don’t use the online collaboration tools, it has a great list of problems that can be used for a kata.  I used this yesterday for my leap year kata in Ruby

Dave Thomas’s Katas
This is the blog post that kicked off a lot of the talk about katas in the software craftsmanship movement. Again, great problem sets that you can get your head around quickly, but with enough meat for some interesting challenges to address.

Your Friendly Neighborhood Software Craftsmanship Group
Here in Boston we have Boston Software Craftsmanship. Great group, someone’s always willing to pair.  Find your local group, or start one yourself.

Another Developer on Your Team
Ask someone on your team if they’d be interested in brown bagging it some day and do some kata’s together.  You should do this especially if you are not pairing now or are not doing TDD.  You may find that you should really be pairing and you really should be doing TDD.  You should.  Really.

CodeRetreat.org
I had a great time at last year’s Global Day of Code Retreat.  Check it out.  Conway’s Game of Life is a great coding exercise.  This also introduces some great constraints and pairing ideas that really get you thinking.

Now get out there and start coding…

So Ends The Season of Ruby

After a few false starts trying to get started with Ruby, I made a commitment this year to dive in with both feet and really learn it.  I decided on the notion of a “season” to dedicate to getting started with Ruby, and I think my initial dive has come to an end.  When are you ever done learning about a language or a technology, probably never?  And I am no more done learning about Ruby than I am done learning about C#, Java, Python, Perl, Javascript, or any other language.  Well, maybe Perl (ha, ha, ha).

So my introduction to Ruby and Ruby on Rails has not disappointed.  As expected, the community is vibrant and on the whole focused on real quality and craftsmanship.  There is no shortage of great resources out there to help a developer come up to speed on Ruby and Ruby on Rails.  And in that spirit, I wanted to take a snapshot on what I have learned, what resources I have found helpful, and where I might focus in the future.

Learn Ruby First

It is surprising easy to get up and running in Rails without really knowing much Ruby, just follow the wealth of examples and tutorials that are already out there.  I would argue strongly against that approach though.  Ruby has some really great features, especially if you are new to dynamic languages.  There is a an expressive syntax, great features like blocks and iterators, and incredibly rich set of standard libraries and 3rd party gems that allow you to build on.

Here are some of the resources I used to get up to speed with Ruby

Ruby Koans – Well structured introduction to the various features of Ruby.  A great intro to the language that you can bang through pretty quickly and refer back to when questions arise.  I have a lot of experience with Test Driven Development, but if you are new to TDD this will also get you thinking about TDD and how to write tests for your code.

The Pickaxe Book – Great resource on features of the Ruby language

The Ruby Way – Extensive resource for ways to solve several common programming tasks using Ruby.  This is also a great early introduction to writing in a Ruby-esque style, which was really helpful for me coming from C#.

Ruby-Doc.org is another good reference for features about Ruby, especially the core API and standard library.

Moving on To Ruby On Rails

There is just an incredible wealth of resources to getting started with Ruby on Rails.

I spent a lot of time on Michael Hartl’s Ruby on Rails Tutorial.  I loved the focus on TDD and good developer practices.  Other added benefits to this tutorial is it is a gently introduction to git and even shows you how to push your code up to heroku.  I know this is a resource I will continue to come back to again and again.

As much as I loved the Hartl tutorial, I wish I had actually started with Rails for Zombies.  Rails for Zombies is put on by Code School, which has a lot of content available for purchase, but the Rails for Zombies course will give you a good introduction to Rails and it’s free.  You can blast through it pretty quickly, gives you a good sense of the basics, and it really sets the table for a deeper dive into Rails.  I actually did this after spending a lot of time with the Hartl tutorial, but doing Rails for Zombies provided a lot of “a ha” moments as I went through it.

RailsCasts has a ton of great content, both free and by subscription and is just a fantastic resource.  The screencasts are typically anywhere between 5 and 15 minutes and cover a huge range of topics.

I can’t get enough of the Ruby Rogues podcast.  These guys do a fantastic job and have great chemistry.  I am shocked that they can do all of this every week, and it has made my commute a lot more educational and enjoyable.  They have some great guests and even for a newb I find the content informative.  Some stuff goes past me, but I usually go to the website afterwards and follow up on the links for the list of topics discussed on each episode.

Ruby 5 is another great podcast.  It serves a different purpose than Ruby Rogues.  Ruby 5 is more of a news oriented feed of what’s happening in the Ruby community, what gems have been released, what books have come out, etc.

Other great resources for learning about Rails are the Rails Guides and Rails ApiDock.

Get Involved in the Local Community

I am fortunate that in Boston there are a lot of resources for meeting and learning from other people in the community.

Boston Ruby puts on some great talks each month and also does hackfests a couple times a month.  I have been to a few talks, but really need to get to the hackfests. They also have a very active mailing list that is a great resource for technical issues.

The Boston Ruby on Rails group meets more sporadically, but seems like a great group.  I went there for a series of lightning talks just before starting the Season of Ruby and there was a spirited Q&A after each of the talks.  I am sure that helped motivate me.

I also went to a few workshops put on by thoughtbot that I got a lot out of: the Web Design and Development Process, and Intermediate Ruby on Rails.

Where to Next

The simple answer is just write more code because that is the best way I know to improve.  There is still sooooooo much to learn.

The Non-Linear Nature of Learning

Learning is a funny thing, rarely does our knowledge progress in a smooth, linear fashion.  I have been spending some of my copious free time learning Ruby and Rails and in that time I have experienced various moments of joy, frustration, utter confusion, and total clarity.  It got me to thinking about the way we learn.

Inspired by Jessica Hagy’s great work at Indexed I came up with this diagram.

I experienced a brief, fleeting moment of Ruby hubris (Rubris?) a few weeks back and implied I was starting to “get it”, even invoking the good name of Ralph Kramden.  Well the Rails gods rightfully smited  me for my lack of a deep understanding of Rail’s Active Record Associations.

For my penance, I have started to take a look at HacketyHack and hope to soon contribute some lessons or help out however I can.  If anyone knows of any other resources for teaching kids to code, I’d be interested in helping out.

Needless to say I’ll also be spending some time trying to grok Active Record Associations as well.

Still having a blast on this journey.

Season of Ruby – Things Are Starting To Click

The danger with doing any online tutorial, even one as good as the Michael Hartl Rails Tutorial, is that if you aren’t careful the only benefits you will have at the end is that your typing skills have improved and you have the marketable ability to cut-and-paste large snippets of code.  At some point you need to start driving the bus.  Today I felt like the Ralph Kramden of Rails.

Editor’s Note: I am not actually old enough to have seen the Honeymooner’s, I just remember in my college days the reruns were on at 11PM, just before Star Trek at midnight (also in reruns).

The last few chapters I have been making an effort to implement the code without looking at the solution from the tutorial.  Today I stepped it up a little further by taking more control of writing and defining the tests too.  It really paid off today as I felt like I took ownership of the app and the technical choices.

Chapter 10 starts out by defining the functionality needed for editing a user.  I looked over the wireframes and had a good idea about the functionality I wanted.  I glanced at the titles of the 1st three tests: get page successfully, has correct title, and includes link to change gravatar.

From a pure TDD approach, doing the simplest thing that works, I was able to get these tests to pass with the following code.

app/views/users/edit.html.erb

<h1>Edit User</h1>
<a href="http://gravatar.com/emails">change</a>

app/controllers/user_controllers.rb

 class UsersController < ApplicationController
    ...
    def edit
      @title = "Edit user"
    end
    ...

Obviously this is not enough to implement the final solution, but it is enough to get the tests to pass, and in my experience additional functionality should be driven by the tests.  From the perspective of a Rails noob I felt that these were valuable tests because they proved out the plumbing and set the table for more complex tests/functionality.  Now it was time to look at the tutorial’s solution.

I was surprised to see that the tutorial solution included the form and all its associated fields.  Now this is not a knock on the tutorial, it is a very good tutorial.  I love this tutorial, but while it introduces some concepts of TDD and its primary goal is not to teach TDD.  But clearly there was a disconnect between the solution and the tests.

So I added the tests for the fields, and now was happily back to red.  Yes Virginia, real developer’s love failing tests, they are a sign of progress.

spec/controllers/user_controllers_spec.rb

   it "should have a name field" do
      get :edit, :id => @user
      response.should have_selector("input[name='user[name]'][type='text']")
    end

    it "should have an email field" do
      get :edit, :id => @user
      response.should have_selector("input[name='user[email]'][type='text']")
    end

    it "should have an password field" do
      get :edit, :id => @user
      response.should have_selector("input[name='user[password]'][type='password']")
    end

    it "should have an confirmation field" do
      get :edit, :id => @user
      response.should have_selector("input[name='user[password_confirmation]'][type='password']")
    end

Getting to green was fairly trivial, and I was able to cut-and-paste a lot of the code from “new” and make a few minor mods.

app/views/users/edit.html.erb

<h1>Edit User</h1>
<%= form_for(@user) do |f| %>
  <%= render 'shared/error_messages', :object => f.object %>
  <div>
    <%= f.label :name %><br />
    <%= f.text_field :name %>
  </div>
  <div>
    <%= f.label :email %><br />
    <%= f.text_field :email %>
  </div>
  <div>
    <%= f.label :password %><br />
    <%= f.password_field :password %>
  </div>
  <div>
    <%= f.label :password_confirmation, "Confirmation" %><br />
    <%= f.password_field :password_confirmation %>
  </div>
<div>
  <%= f.submit "Update" %>
</div>
<% end %>
<div>
  <a href="http://gravatar.com/emails">change</a>
</div>

My tests were passing but now I had quite a bit of duplicated code in my app/views/users/new.html.erb and app/views/users/edit.html.erb files.  It was time for the 3rd piece of the red-green-refactor cycle.

Thinking back to earlier chapters, I thought what I would like to do is to implement a partial view that encapsulated the user forms.  After some googling about how to pass parameters into a partial view I ended up with the following partial view

app/views/shared/_user_fields.html.erb

<div class="field">
  <%= f.label :name %><br />
  <%= f.text_field :name %>
</div>
<div class="field">
 <%= f.label :email %><br />
 <%= f.text_field :email %>
</div>
<div class="field">
 <%= f.label :password %><br />
 <%= f.password_field :password %>
</div>
<div class="field">
 <%= f.label :password_confirmation, "Confirmation" %><br />
 <%= f.password_field :password_confirmation %>
</div>

And the edit.html.erb was a lot cleaner now and my tests were still passing.
app/views/user/edit.html.erb

<h1>Edit User</h1>

<%= form_for(@user) do |f| %>
 <%= render 'shared/error_messages', :object => f.object %>
 <%= render 'shared/user_fields', :f => f %>
 <div class="actions">
 <%= f.submit "Update" %>
 </div>
<% end %>

<div>
 <a href="http://gravatar.com/emails">change</a>
</div>
<pre>

Making the necessary changes to new.html.erb completed the process.
app/views/user/new.html.erb

<h1>Sign up</h1>
<%= form_for(@user) do |f| %>
  <%= render 'shared/error_messages' %>
  <%= render 'shared/user_fields', :f => f %>
  <div class="actions">
    <%= f.submit "Sign up" %>
  </div>
<% end %>

Run the tests one more time…and still green.

It was a really good day in Rails land.  None of this was rocket-science, but I felt like I knew what I wanted to do and how to do it (with just a few minor hiccups related to syntax and mechanics).

Season of Ruby – Iteration 4 Retrospective

Iteration 4? Wait, shouldn’t I be on Iteration 5?  Yes, but as expected work reared its ugly head and the Season of Ruby got pushed to the back of the line.

I am now through Chapter 8 of the Ruby on Rails Tutorial.  I wish I had tracked the actual time spent on the tutorial, that would have been useful information for anyone wishing to follow the same roadmap.  I would estimate I have spent around 14-16 hours through the first 8 chapters.

What Went Well

• In the interest of trying to get as much as possible, I am resisting the urge to cut-and-paste from the tutorial.  You learn a lot from mistakes, big and small, so there is a lesson to be learned when you type “name” or “@name” when what you really needed to type “:name”.
• I still think one of the strengths of this tutorial is the focus on TDD.  As I have started to get more comfortable with the environment, I have also been trying to implement solutions on my own after writing the tests from the tutorial.  That makes me feel like I am starting to get more of a lay of the land.
• Used the FactoryGirl gem to simulate model objects for testing.
• Got my shiny new MacBook Pro and have switched all my Ruby and Rails development from Windows.  It was really cool once the environment was set up to grab the repo of github and pick up right where I left off.  BTW, I used the thoughtbot laptop project to get my system all set up for Rails development.  Went pretty smoothly.

What Can Be Improved On

• I feel a little like how I felt during the Ruby Koans, that I am gaining a false sense of knowledge by following the tutorial.  It has been really helpful to get me moving forward with Rails, but you are still following a well-defined roadmap.
• I want to finish the tutorial because I think there are several more lessons to learn and it will be a great reference to look back on, but I am anxious to start from a clean sheet of paper and make a ton of mistakes.  That is when the real learning will happen.
• I have been pretty good about not doing a lot of cut-and-paste from the tutorial, but at times it is hard.  Just need to keep forcing myself to resist doing that.

What Am I Going To Do To Improve

The most learning has come in cases where I have tried to implement my own solutions after using the tests as provided from the tutorial.  From this point on, that will be the approach I will use.  Then when I have a passing test I can look at the tutorial and compare my solution against the tutorial solution and take that as a refactoring exercise.  It may take longer, but it will pay dividends down the line.

Iteration 5 Stories/Tasks

Chapters 9 and 10 of the Ruby on Rails Tutorial, implementing my own solutions first after using the tutorial tests to get to “red”.

New Startup Accelerator Program Coming To Boston

There is a new startup accelerator looking to set up shop in Boston this summer.  The thing that caught my eye is that this accelerator, Bolt, will focus on connected devices.  Real…physical…stuff.

I think that this is great for the Boston area.  We already have a lot of energy and effort in the area around startups for mobile, web, and software services, but I think this will help bring other engineering disciplines into the Boston startup community.  The ability to iterate in the mechanical/electrical world has improved a lot over the years, especially with the widespread use of 3D printers, electronics prototyping, and OTS platforms like Arduino.  It will be interesting to see how lean startup principles come into play in the physical world (yes, I know that’s where they came from initially)

As someone who has spent most of his career doing software for robotics, automation, and medical devices this will be something to keep an eye on.

Season of Ruby – Iteration 3 Retrospective

I am now a month into the  Season of Ruby, so aside from the usual retrospective, it is a good time to reflect on what I have learned to this point.  In the last month I have made the following strides:

• Set up a github account and pushed code up to it.
• Re-familiarized myself with git and got more practice using it on a day-to-day basis, creating and merging branches, as well as pushing code to github and heroku.
• Learning the basics of Ruby and used it to develop an implementation of the Conway’s Game of Life
• Picked up a little Rails with the Ruby on Rails Tutorial

What Went Well

• I am really enjoying the Ruby on Rails Tutorial, not just for how it teaches Rails, but as much for the developer practices that it encourages.
• Gave some thought to the overall roadmap of where I want to go for the next few months.  I thought this website gave a good picture and though I will customize it a bit, I think a lot of the areas I want to build on are covered here.  For me the areas that I want to focus on in the next few months are a strong foundation in Ruby along with a better understanding of JavaScript (and CoffeeScript), and CSS.  I have a few ideas about an app I can put together that will provide an opportunity to strengthen those areas.

What Can Be Improved On

• Practice, practice, practice.  The tutorial is really helping me put all this together, but I need to keep repeating the lessons to make sure it sinks in.  Similar to what I went through with the Ruby Koans, I don’t want to develop a false sense of understanding, so I need to keep writing code and making sure to dig beneath the surface.

What Am I Going To Do To Improve Things

To make sure I am really grokking the lessons from the tutorial, I think it would be a good idea to take a few hours at the end of this iteration and write a simple app.  Something similar in complexity to the micro-blogging example in the tutorial. It doesn’t need to be a complete application, but the parts I get to need to be “right”, so I will time-box it at 3 hours. Does not need to be visually pretty.

Iteration 4 Stories/Tasks

Keep chugging away on the Ruby on Rails tutorial.  I am through chapter 5, but this is going to be a long week at work, so I would like to be able to get through chapters 6 & 7 this week.

To make sure I am really absorbing the tutorial lessons, develop a simple application without referring back to the tutorial documentation.  Going through other documentation is OK, e.g. StackOverflow, Ruby Core Docs, Rails Guides.  Time-box it at 3 hours, and follow good developer practices, i.e. use TDD, git/github.  Application is TBD, but should be similar in complexity to the micro-blogging example.