Articles Feed

Observing a Craftsman

by: paul | November 17th, 2008 | 1 comments »

“Knowledge can be communicated, but not wisdom. One can find it, live it, be fortified by it, do wonders through it, but once cannot communicate and teach it.” –Hermann Hesse, from Sidhartha

My path in becoming a craftsman was not through conventional academics. I did get a Bachelor degree in Computer Science. During those years of learning, I was taught a lot about how to learn and how to communicate, but I learned nothing about how to practice my craft of software. I learned how TCP/IP works, how registers are able to do math . All of this is interesting and some of it is useful for a broader view of computer interactions as a whole. None, however, taught me about developing software as a craft. I did some programming, which is a prerequisite for any kind of software development.

My real learning began after school. Learning software as a craft was not done in books. It took being around journeymen and master craftsmen to learn the way they think. Observing their idiosyncrasies and approach to a problem is part of the learning. Much of the wisdom is tacit. For me it is watching the way my mentor approaches a story. The way a craftsman sees a problem and digests it, without hurry, and finds a satisfactory solution. Then they write code, introducing faults and fallacies the original solution could not have predicted. Finally, a meticulous approach to improve each fault in the code. The whole time demanding perfection, without ever hitting it. This is the good code I strive to write. I can’t learn that by looking at the solution though.

These are observations of behavior and intent, not of actions. For example, I have read about Test Driven Development, and it has made my job easier. For awhile after I learned it, I wrote a lot of simple assertions, almost reverse engineering my production code in my head to figure out what the test code would look like. However, the practice itself became ten times more valuable when I saw my mentor use the tests to design their API. They would say things like “what do I want this to do” or “that doesn’t feel right, lets rename the method to this”. Those insights into the thought process provide me with the experiential learning it takes to further improve my craft. When I started thinking about TDD in a similar manner, it allows me to clean up my code and know it still works, refactor my code into easily extendable solutions, and it gives me the confidence to experiment with the aesthetics of my code. I couldn’t fully learn that from books alone.

This is why it is so important to apprentice as a software developer. There are many things about development that I only learned through watching the behaviors and actions of the craftsmen I admire. To me, these are the things that open up the software world to gain wisdom. For example, to be a better developer is not to learn a new language, but to have the wisdom to learn and understand any computer language, which requires you to learn new languages all the time.

Kata: Langston's Ant in Ruby

by: micah | November 13th, 2008 | 1 comments »

I’ve recorded my Langston’s Ant kata for all to see.

This particular kata, with slight variations, has been in front of an audience twice before. Once at a Software Craftsmanship group SCG meeting and again at RubyConf2007.

On both occasions I asked the audience to evaluate my performance on a scale of 0-10, 0 being the worst kata you can imagine, and 10 being the best. At the SCG, my performance was longer than the screencast because I didn’t use the instance_eval trick and wrote multiple case/when statements. It resulted in much more code as well. Honestly, I felt the kata dragged on a bit too long which is why I shortened in subsequent performances. Despite this, the SCG audience gave me an average score of 8. At RubyConf, the kata was almost exactly like the screencast and it earned me an average score of 7.

Now coming from an audience of dedicated Ruby developers, I’m quite pleased with my score. Here’s some of the feedback I got…

• Use of instance_eval: -1
• First test, going from compile error to passing tests: -1
• Refactoring on with red bar: -1 (not repeated in the screencast)
• Non-idiomatic is_black?: -0.5 (fixed in screencast)
• Steps are too big in between tests: -1
• …

I find this feedback immensely valuable and thank those who took the time to provide me with it.

In martial arts, the techniques performed in kata are not always by the book. There is an aspect of art, creativity, and entertainment. At several points in my Langston’s Ant kata I intentionally decided to bend the rules to enhance artistic and entertainment values. I leave it up to you whether I made the right compromise or not.

After watching the kata, leave a comment with your rating and any feedback you have for me. I thank you in advanced.

Simon

by: micah | November 10th, 2008 | 0 comments »

You remember the classic Simon game, right? The one where the electronic devise will blink a color and make a sound that you have to replicate by pushing the colored buttons.

At RubyConf 2008, I cornered Jim Weirich and asked his opinion on Limelight. He didn’t feel like he had seen enough of it to give a good opinion. So we found an hour where we could both sit down and build a simple Limelight production. We decided to build Simon.

The result is really quite simple. It’s a couple hundred lines of code, UI, game logic, and all. It’s also got a suite of unit tests.

If Limelight is installed, you can download the production file, and double click it, or enter the url in the Startup Limelight Production.

Limelight Production file: http://blog.8thlight.com/files/simon.llp

The Source Code can be found on github.

Ruby Battleship Sparring Tournament

by: micah | November 8th, 2008 | 0 comments »

Yesterday in my talk at RubyConf2008, I announced the commencement of the Ruby Battleship Sparring Tournament.

This is an open tournament. All are welcome to participate.

Limelight 0.3.0 Released

by: micah | November 5th, 2008 | 0 comments »

This release of limelight contains many new features and stability. Perhaps most notably, Limelight will no longer eat 95% of your CPU (ouch)! It's proud to say it's becoming quite usable for real apps of considerable size.

Default event implementation - feature_request
Image player - feature_request
Sending variables to partials - feature_request
CPU Hog -
Gems in productions - feature_request
Giving Floats to prop styles - feature_request
Scene's Default name - feature_request
Hand Cursor Stays - bug
generate production templates - feature_request
Validate styles - feature_request
Auto resizing doesn't trigger update on parent. - bug
Double click to open production - feature_request
Color as a hash - feature_request
Add more Known colors - feature_request
Need to relaunch when changing player. - feature_request
Shared Players - feature_request
Unique IDs - bug
Building a Production - documentation
Document Events - documentation
Document Prop API - documentation
Document Styles - documentation
Variable size text areas - feature_request
Editable TextArea size - bug
Simple App screencast - documentation
RDoc - documentation
finish 0.2.0 release - release
Reserved prop keywords - bug