Software Craftsmanship North America

Dave Hoover, one of my fellow colleagues at Obtiva, is collaborating with the people at 8th Light to bring us one of the first conferences focused on software craftsmanship (Software Craftsmanship North America):
http://scna.softwarecraftsmanship.com/

I originally got introduced to the idea of Software Craftsmanship while reading the Pragmatic Programmer by Andrew Hunt and Dave Thomas, and later learned more about it through the book titled Software Craftsmanship by Pete-McBreen.

I even blogged about Software Craftsmanship contrasting it with Software Engineering over here:
http://andymaleh.blogspot.com/2008/12/software-craftsmanship-vs-software.html

Well, if you want to learn more about it, InfoQ recently posted an interview with Dave Hoover clarifying the purpose and goals behind the conference:
http://www.infoq.com/news/2009/06/software-craftsmanship-conf

Feel free to post a comment if you have any questions about it

The IDE vs Editor War in the Ruby World

Ever since I switched to Ruby programming last September to develop Rails web applications, I've been fighting an up-hill battle to convince other developers of the value of using Eclipse or IDEs in general.

Since Ruby is an interpreted language (with a transparent compilation step for optimizations purposes only), developers mainly rely on test-driven development to produce reliable code. Auto-compilation and verification of code is thus rendered for the most part unnecessary.

Additionally, given Ruby's support for attributes (via attr* methods) and no need to declare class variables, many of the source code generators used in Java are not needed in Ruby. After all, Ruby's philosophy is about producting the tersest most abstract code, free of boiler-plate repetitive code.

Refactoring with Ruby is often done manually, but given that there isn't usually a lot of code with proper abstraction, and given Ruby's method aliasing support, huge refactorings of the nature that ripples through the whole system are rare, and thus refactoring is quite easy to perform manually especially given the protection of the Ruby must-have unit tests.

So, what does that leave as far as tooling needs? Color coding, syntax highlighting, file lookup, search and replace, and possibly some autocompletion capabilities.

Well, these limited needs brought back the popularity of simple editors that support just these features. By simple editors, I do actually mean good old VIM and emacs as well as the new extremely popular Mac editor, TextMate.

After 10 months of pair-programming with different Ruby developers with varying habits and backgrounds, I got to do a pilgrimage through most Ruby editors and IDEs. So far, I've gone through TextMate, VIM, Aptana RadRails, Eclipse DLTK, NetBeans, and IntelliJ RubyMine.

Yes, I'm a shortcut freak, and I used to write Java programs in Eclipse mouse-less!!! So, how did other editors and IDEs measure in comparison as far as shortcuts and productivity?

I'll leave that to another post.

In the meantime, what is your opinion of the matter? Do any of you prefer editors over IDEs? If so what's your editor/IDE of choice and what are the reasons you like it? Feel free to mention different ones for different programming languages.

iMeow

Some of my colleagues at work built a new iPhone app called iMeow (iTunes link).

The instructions for using iMeow are actually encoded in a poem included with the app:

"I like to have my ears and belly rubbed.
But, please don't step on my toes or pull my tail!!!
I'll cry for food if I'm hungry.
And whatever you do. Do. Not. Shake. Me."

Since I have a coffee-colored cat called Java, I decided to try out iMeow with her.

When I pressed the mouth of the iMeow cat to make it meow, my cat suddenly became alert and still. I did it a few times and then tossed the phone away. My cat started moving slowly towards the phone and then went and sniffed it.

Next experiment was to pull the iMeow's cat tail or step on its toes. The shrieks that came out of that sent chills down my cat's spine!!!

Finally, I shook the iPhone forcing the iMeow cat to give an aggressive fighting shriek and exhale (the one cats do right before clawing you). That freaked my cat out, but it was fast enough that my cat was able to get over it quickly.

In any case, I expect the app to get a number of updates in the future, so if you have a cat and you would like to test how it would react to another cat, give iMeow a spin.

My next experiment will be to test iMeow in the wild, either in a pet store, or at a public place to see how everyone will react. ;)

XP West Michigan and EclipseCon 2009

Tyler Jennings, Jake Scruggs, and I went on a road trip to Grand Rapids, Michigan yesterday and gave two presentations at the XP West Michigan user group. Jake presented "What’s the right level of testing?", and Tyler and I presented "Pairing Parody". Atomic Object hosted us and gave us a tour around their office. They had a nice open environment for pair-programming and a street light that signals the state of project builds (red for failure, green for success, and yellow for build in progress). The experience was very hospitable overall thanks to Michael Swieton.

Today, I flew to the Silicon Valley area around San Jose, California to present at EclipseCon 2009 tomorrow. I will be giving a short talk about Glimmer and the current state of the project.

If you have any specific questions about the project, feel free to list them here in the comments, and I will try to cover them in the talk.

Agile 2009 Workshop: TDD Ping Pong Match!

By the way, Dave Hoover and I proposed a workshop for Agile 2009 titled: TDD Ping Pong Match!

It's a new and improved version of the same workshop conducted in Toronto last year at Agile 2008.

Abstract:

Attendees will be entered into a competition where they will pair-program on implementing small software application features following the TDD Ping Pong game rules. Each game will last for a few minutes, and the programmer with the least time driving (i.e. doing the simplest thing that works and coming up with the most tests) will be declared winner. This game is a great opportunity to learn TDD and Pair-Programming effectively and pragmatically. Winners will receive prizes, so sharpen your TDD Ping Pong skills and get ready for Andy and Dave’s challenge!

Agile 2009 Talk: Pairing Parody

I submitted a proposal for this talk with Tyler Jennings:
http://agile2009.agilealliance.org/node/2370

Comments are welcome.

Abstract

Pair programming requires a certain level of social interaction (Yikes!!!) that quite a few developers are not accustomed to - even with their peers. Learning to work effectively with people of different personalities and skills (or even Jedi powers) can sometimes seem daunting compared to the typical habit of working alone in a dark corner. We’ve seen pairing work wonderfully, we’ve seen it be an abysmal failure that involved some shouting and storming away, and we’re going to bring our best-of moments to you in comedic fashion.
Process/Mechanics

First we’ll cover the basics for anyone who isn’t familiar with the drama that often accompanies pair programming. Afterward, Andy and I will be acting out various skits, demonstrating both effective and dysfunctional pairing scenarios. Discussions (and laughter or cries of terror) are highly encouraged at the end of each skit.

Basic Patterns

* Be Verbose
* Questions Not Demands
* Pair Negotiation
* Ping Pong Programming
* 2 x 2 Pairing
* Independent Research / Spikes

Mentoring Patterns

* Let the student drive
* Let the student fail
* The third wheel
* Test Mentor

Anti-Patterns

* The Prima Donna Programmer
* The Apathetic Programmer
* The Human Compiler
* Worshipping The Hero
* The Professional Driver

Learning outcomes

* Recognizing a dysfunctional pairing session
* Patterns for pairing effectively with various personality types and skill levels

Obtiva HackFest and Glimmer Tree Data Binding in Progress

Today, instead of having our weekly GeekFest meeting at Obtiva, Dave organized a HackFest instead.

Colin, Dave, Roy, and Nate worked on
Colin's ultimate midi controller project. Tom, Leah, and Jake worked on the Metric Fu Aggregator. And, Tyler, Turner, and I worked on implementing Tree Data-Binding support for Glimmer.

In one hour, we made as much progress as we could, which amounted to coming up with a design for the data-binding syntax in this unit test:

  module Node
    attr_accessor :parent, :children
  end
  
  class Person 
    include Node
    attr_accessor :name, :age, :adult
  end
  
  def test_root_node_only
    adam = Person.new
    adam.name = "Adam"
    
    @target = shell {
      @tree = tree {
        items bind(adam, :name)
      }
    }
    
    assert_equal 1, @tree.widget.getItems.size
    assert_equal adam, @tree.widget.getItems.first
  end

To bind SWT Tree items to a model node hierarchy, you pass two parameters to the bind command: the root model node and the name of the attribute to be used for displaying text in the tree.

More tests will eventually be written to test data-binding a root model with children.

In the future, this will probably grow in other directions to handle tree node images and selection.

Test-driven design is a common practice at Obtiva as it gets many birds with one stone: ease of exploration of ideas, test-coverage, clean code design, and higher productivity due to incremental development preventing endless hours of debugging.

Stay tuned for more on Tree Data-Binding support in Glimmer in the future.