8th Light Blog

Articles Feed

Authors

Micah (15)
Paul (15)
Jim (10)
Eric (15)
Doug (13)
Eric Meyer (1)
Colin (3)

Stubbing :new Considered Harmful

by: eric | February 8th, 2010 | 0 comments »

Hi my name is Eric, and I have made a mess.

There I said it. I’m not proud of it, but I believe a couple very loosely related things:

You only learn from your mistakes
Everybody makes mistakes, a craftsman cleans them up.

It is in the process of cleaning up the mess that I’ve been trying to evaluate the messy code in the first place. How is the code messy? Was it Test-Driven? It was - or at least it attempted to be (we’ll get back to that). Was I lazy? Certainly not. Am I stupid? Crap I hope not. So how did we end up in this mess?

What’s the mess nimrod?

Recently Justin, our latest apprentice, wrote about attending a code review here. The feature he is referring to is part of one of our best client’s systems, where we integrated with several webservices, making them look seamless in our application. This was an extremely difficult problem, and our code bent in a dozen painful ways for a solution, and has since become rigid. Changes have stopped being done in the nice Test-Code-Refactor mode, and instead are being done by trying a change, trying the product, then backing out the change and making the test pass. While we identified several ways to improve the code, such as better naming and adding a facade between some of our interfaces, one stated goal was to “make the tests readable.” See the problem isn’t that it’s not tested - it’s that you can’t follow the tests at all. Let’s look at an example, modified to protect the guilty:


  it "should call a webservice when its complete" do
    @caller.should_receive(:call_webservice)
    typedObj = mock("Obj", :no_follow_ups? => false, :null_object => true)
    ProprietaryObject.stub!(:create_typed_obj).and_return(typedObj)
    @page.stub!(:widget_id).and_return(@widget.id)
    @page.stub!(:previous_page_id).and_return(nil)
    @product.page_cache = [@page]
    @widget.follow_ups({}, {:application_id => "123", :group => "group"})
  end

This probably isn’t the worst example - if you look closely you can see that we’re testing that call_webservice needs to get called when ‘its complete.’ But what complete? I don’t see a stubbed object that returns complete. Also I have no idea what @page, @widget, @product or :createtypedobj are doing here. When I want to write the next test I have to guess at intent, and start playing with variables. What this is trying to test is that a webservice caller object receives call_webservice when the widget (an object on the screen) is called with certain variables. I’d tell you what those variables are, but I truly don’t know.

It doesn’t get better. Let’s look at where some of those variables are coming from. These are excerpts from a setup method that is too long.*


  Context.stub!(:find_by_widget_and_application_form).and_return(@context)
  Page.stub!(:new).and_return(@page)
  ...
  @caller = mock('caller', :call_webservice => nil)
  WebserviceCaller.stub!(:new).and_return(@caller) 
  ...
  @page_factory = mock_model(PageFactory, :acquire => @page)
  PageFactory.stub!(:new).and_return(@page_factory)

So by my count we’ve stubbed new three times, two finders, and an acquire all of which inject yet another dependency into the code. Thus the premise of the article stubbing new considered harmful.

Is it really harmful?

Dependencies in static languages are generally more onerous than what we’ve got here, sometimes extremely painful although usually it can be accomplished with simple setters and constructors. In Ruby this isn’t the case - you can just stub new and create the object the way the user intended, thereby continuing to test. This can be a VERY BAD THING because it’s a moment where you need to pause. Do you need this dependency? Should you be wrapping dependencies? Do you need a facade or wrapper object for a couple dependencies? The difficulty of DI in other languages enforces that pause, but Ruby does not. It lets you stub anything, only to one day wonder why you have such a mess on your hands.

It’s important to remember that Dependency Inversion existed before Unit Testing, and isn’t just a Unit Testing technique. Indeed we often sell TDD as a way to make you have better designs, and yet here it failed me because I can so simply call new and continue testing. This is a mistake. To paraphrase Jurassic Park, just because you can easily stub new doesn’t mean you should. Would you create a constructor that took five objects? Then why would you stub :new (or finders, or factory methods) five times. Would you pass in an object to the constructor that’s only used in one method? No - that’s not cohesive. By stubbing :new you can slowly, and easily, introduce dependency after dependency creating an indecipherable mess despite writing tests. Worse you can do this easily, without suffering the traditional pain of tightly coupled code. It’s only later that you’ll feel the awful, horrible, indescribable pain. Trust me it’s bad.

Am I really advocating stopping stubbing :new? No not really. It makes perfect since to just call :new when you can, and in many cases factories are a way to get around the limitations of a static language. What I am saying is that each time you do stub!(:new) THINK! You have a dependency to manage, so manage it. It’s your job you know.

*This is also a smell. Allow me to quote “The Art of Unit Testing”, an excellent book on Unit Testing by Roy Osherove

Don’t use [SetUp] and [TearDown] to initialize or destroy objects that aren’t shared throughout the test class in all the tests, because it makes the tests less understandable. Someone reading your code won’t know which tests use the logic inside the setup method and which don’t.

Zeroth rule of professionalism

by: paul | January 8th, 2010 | 1 comments »

This is a response to an article “Software Testing Craft” by Markus Gärtner in inaugural issue of Agile Record.

As an apprentice, I remember thinking that solutions to software were either right or wrong. Later this was able to be simplified to either the solution works or doesn’t work. This became my base level understanding of a software solution.

Then came the time I thought solutions should be judged by how clean or efficient they were. This was my renaissance of aesthetics in the code. How to code your intentions expressively was the goal. This too became a new base level of understanding.

Now I am of the understanding that software solutions are a judged by factors of time. Making all the trade offs correctly so the code works and is readable, but also in the shortest amount of time possible. The key thing here is to take the long term view of time. Not how much time in a single sitting, but every time you come back to the same solution. How often do you come back? How hard is it to change?

From the article, Markus says, “As a software tester, you should take responsibility for the out- come of every decision you make. I call this the zeroth rule of professionalism.”

I think this is an elegant way of stating my understanding of software solutions. Every decision you make is a function of time and understanding. By taking responsibility for each of your decisions software becomes a series of trade offs that you have to live with and learn from. When a design works and is written well, it becomes easier to live with the outcomes of your decisions.

It is much like how I learned to play chess. At first I would make a move and try to understand the consequences in position and strength. Then I learned the common openings and endgames which helped me express my strategic creativity and play moves that had aesthetic value. Finally came the important skill. Being able to project moves forward and do a risk analysis of each possible move. This let me take the previous skills and put them together in a coherent fashion. I could understand how a move fatal to my king was a consequence of a move made much earlier in the game and learn from that decision. This skill is when I started playing chess as a game rather than a set of moves.

For me, it was only through the out-comes of my design decisions that I learn this lesson. It was very important for me to be in a position transparent to the positive and negative consequences of the code I write. Like the chess analogy, I need to project forward to attempt to understand the consequences of a decision before I make it.

A Software Craftsman's New Year's Resolutions

by: colin | December 30th, 2009 | 1 comments »

There is so much to learn in this field, and the many new languages, frameworks, and APIs that are developed every day only add to our task. Sorry for the title-bait, but no self-respecting iterative-developing programmer would make resolutions for an entire year of learning. I expect to re-evaluate every few months, but making a long list of goals is a fun way to brainstorm paths to improvement.

Let me first take a moment to reflect on the past year. I've learned so much in 2009, beginning with my discovery of the Software Craftsmanship movement and its focus on apprenticeship. I leapt at the opportunity to come to 8th Light as an apprentice under Micah Martin, and was excited to come onboard long-term at the conclusion of my formal apprenticeship. It's important to remember that only a year ago, I wasn't doing TDD or Agile and hadn't really used any other technologies professionally beyond the Rails ecosystem. This year, I've done quite a bit of Java and JRuby, and I've studied Scheme through SICP, as well as some Clojure (mostly exercise-type practice) and Scala (just enough to write a Tic-Tac-Toe program). My progress speaks both to the time and effort I invested in learning (see Uncle Bob's tweet about professionalism) and to the tremendously positive peer pressure that surrounds me here in the Chicago area, the Software Craftsmanship community, and 8th Light specifically.

However, a software developer can't be caught looking backwards for very long. With that in mind, I present my goals for 2010.

1. Check email and Twitter less frequently.

Like many other developers (and musicians), I have a bit of an obsessive personality, so I end up interrupting my work and personal life to get my news fix much more often than necessary. Besides, it's going to be illegal to text, email, or tweet while driving in Illinois beginning January 1, so it's absolutely necessary (not that it was safe while driving before).

2. Take more breaks when coding alone.

When programming without a pair, I tend to stay very close to the code and neglect the big picture. With some open-source work over a recent vacation, I found myself coming to an impass nearly every evening, and invariably I'd have a simple solution the following morning. It's less necessary with a pair (like Doug Bradbury) who's able to step back and evaluate bigger-picture ideas, but our minds don't have infinite endurance, even with the labor split up.

3. Timebox spike code.

I'm improving my test-driven development habits, but there are so many unfamiliar areas to me as a programmer that I have a hard time telling whether I'm going in the correct direction until I'm there. I don't write tests for most spikes, so this means that I sometimes end up with a couple hundred lines of working code that I need to retrofit tests onto. Obviously, this ends up being more work than it should, and while I can refactor to make the code more easily testable (especially with automated refactoring tools), I'd prefer to have tests in the first place. And in the worst cases, I might miss some tests that need to be written and allow bugs that should have been caught. So my intention is to put a cap on the amount of time I spend on a spike before I backtrack and start writing tests. Something like 30 minutes seems reasonable. Besides, most of the spike code I write is alone, so I should be taking more breaks anyway.

4. Focus language study.

There's something to be said for the tremendous breadth in the languages I studied this year (Java, Ruby, Scheme, Clojure, Scala, and C), but I don't want to be a jack of all trades, master of none. It's time to get serious and get some real depth. Since my current project is mostly in Java and JRuby, it seems logical to get really in-depth with those two languages. My study at home would be reinforced by what I do daily at work, and vice versa. On the other hand, it also seems smart to go after an up-and-coming language and get ahead of the curve there. So I won't rule out more Clojure or Scala study, but it's my intention to pick one at most.

5. Focus open-source efforts.

I tend to leap around open-source projects a bit, looking into a few projects just enough to catch some low-hanging fruit from the bug or feature lists. I'd like to get more depth on a project or two, ideally in the same languages I'm planning to study more of: Java and Ruby. Limelight is the no-brainer choice, and I've already started a bit of work there. The best news is that I already know Micah, the creator/maintainer, and he's very willing to help me learn and contribute to the project. I highly recommend the project, as well as Nokogiri (the Java branch would be exciting to get working) and JRuby, for anyone with Java and Ruby skills looking for a project.

6. Really learn testing frameworks well.

It's not very often that I run into a testing problem that's limited by my lack of knowledge of the testing framework, but it sure is embarrassing when that does happen. The acceptance tests for my project are in Fitnesse, and the unit tests are in RSpec and JUnit. Following my current rationale, I should get really good at those. I have the longest to go in Fitnesse, where I still feel like a beginner, so I plan to start there.

7. Schedule study / practice.

My evenings often end up being extended mashups of coding, reading, and television. It's nice to have a relaxed feel about practice, but too often, it means less quality time with my wife and dogs. I'd like to schedule my study, both to increase the quality of my work during that time and to increase the amount of quality family time.

I'm sure the ways to achieve these will vary, but I think they're specific enough to drive my growth as a developer. I'm excited about continuing the improvements of the past year in 2010, and I hope that by focusing on these "resolutions", I'll even accelerate things a bit. I'd love to hear other ideas people have for improving their skills in the coming year!

Why Software Development is a Craft

by: doug | October 22nd, 2009 | 4 comments »

Craftsmanship has been used as a metaphor for software development. Pete McBreen argues in his book “Software Craftsmanship” that craft is a better metaphor for software development than is engineering or science.

I take the association one step further and claim that it craft is not just a good metaphor for software development, but that software development is literally a craft.

The Hand and the Eye

A key facet of historical craft is the intimate connection between the hand and the eye. A furniture maker cuts a joint with his hands, then fits the two pieces together. If the alignment isn’t perfect, he sands and trims and fills until the joint is true. It’s a cycle of shaping and observing. A glass blower turns the bead of molten glass over and over in a steady rhythm as she shapes the glass towards its final form. Her eye informs her hands and she constantly sees the effects of the changing speed and angle of the turning rod.

Code is a physical thing. Though technically code is nothing more than some states stored on a fast spinning magnetic disk, it is just as physical as a lump of clay. Consider the language used when talking about code. It is touched, shaped, moved, broken, cut, pasted, fiddled with, tweaked, and played with. It is the physicality of code that enables the feedback between the hand and the eye. It is touched and a change is observed.

This is why Test Driven Development is such a key practice in software craftsmanship. There was a time when a programmer would write a bunch of code and try it out hours or even days later. The time between making something with the hand and seeing the results was long. When a programmer writes a little bit of test code and runs it, then a little bit of production code and runs it, this cycle shrinks to minutes or even seconds. The connection between the hand and the eye increases. The craftsman immediately sees the work of his hand.

Making

Another element that makes software development a literal craft is that software development is a process of making. Contrast that to engineering. What is the primary activity of an engineer? It is design. A civil engineer designs a bridge that an ironworker builds. The electrical engineer doesn’t typically etch or populate the circuit board. She designs a circuit that is printed on a board and populated by either machine or technician.

In contrast, the software craftsman doesn’t just design the software (though she does do that), she also makes it. She writes the code that makes it work. There is little manufacturing involved in taking the made software and putting it in the hands of the person who will use it. Sometimes there is a deployment to a server or perhaps a CD is burnt and packaged in a box. But often even these tasks are performed or automated by the maker herself.

Material

Historical craftsmen have always been makers. The potter makes a vessel; the blacksmith, a horseshoe; the weaver, a garment. These makers have always had close connection to the raw material of their work: the wool, the iron, and the clay. What then is the raw material of software craftsmanship? What is the material of which software is made?

The material of software is language. Java, Ruby, C, Scala, Clojure, etc.: these syntaxes are the medium in which the software craftsman works. What makes this media so interesting is that the materials themselves are composite materials made of more primitive materials. Beneath Ruby code lies an interpreter built in C which is compiled by a compiler. The most basic of which is built in an assembly language which is assembled by an assembler which is built in the most primitive machine language which is read directly by the computer’s processor. Each new language emerges out of other languages as craftsmen explore the materials and invent new ways of combining and deconstructing what they have at hand.

It’s similar to metal alloys like steel. Iron is combined with other metals to make an new raw material whose strength enables the construction of enormous buildings. Each new language innovation gives the software craftsman a new, more powerful material from which to build both larger and simpler systems.

Tools

A discussion of software as craft isn’t complete without mentioning tools. A software craftsman does deal with the hardware on which his software runs, but the more interesting tool set is the software that the craftsman uses to write code. The text editor or development environment, the unit testing framework, the continuous integration system, and the acceptance test system are the tools of the software craftsman’s trade. Because these tools are built from the same raw materials as the thing being made, software craftsmen have the ability like historical craftsmen to be tool makers.

Learning

The final argument for treating software development as a literal craft is the way in which it is learned. A traditional college education in computer engineering or computer science produces graduates woefully unprepared to develop software. The best way to learn how to make software is to sit down with someone who knows how to do it and learn from them. This is currently being displayed in many shops throughout the world that are embracing an apprenticeship model for training and growth. This model has been used for centuries to pass on crafts from one generation to the next.

Software is Craft

The Software Craftsmanship community is growing and having some fabulous discussions. I think that this is largely a result of people not just using craftsmanship as a way to talk about or explain software, but embracing and practicing software as a literal craft. The historical crafts have begun to inform us in the software craft and have helped us develop our practice. Most metaphors break down when taken too far, but software-as-craft isn’t losing any steam. Perhaps that is because the association is more than metaphor and software really is a craft.

Limelight 0.5.0 Released

by: micah | October 19th, 2009 | 0 comments »

Today we released a new and exciting version of Limelight. Just a reminder, Limelight is a user-interface framework for Ruby. Included in this release are not only some new features, but also a new means of production(application) distribution called Playbills, and a snazzy production that documents the Limelight framework.

Playbills

Playbills is a hosted repository of available Limelight production. When you open the Limelight application, Playbills will open automatically (assuming you’re connected to the internet) and display a playbill for each production. Each Playbill provides a brief description to help you decide if you’d like to open the production. When you’re convince, click on the provided button. The production will be downloaded an opened in Limelight. Pretty nifty I think.

Limelight Docs

Among one list is a Playbill for our own Limelight Docs production. We’re quite pleased with this one. It’s a swiss army knife of documentation that should make it fairly simple for developers to build their own Limelight productions. You’ll find descriptions, walkthroughs, RDoc, and dynamic sandboxes where you can experiment with the features right inside the documentation! What’s more, the RDoc is loaded dynamically from Limelight’s runtime… You can’t get more up to date than that!

Status

Limelight has been a thrilling side project to work on. I’m very pleased with how it is turning out. We are using Limelight internally at 8th Light for a variety of projects. This release (0.5.0) is still a beta but the Framework is maturing rapidly. Although there are still a few rough spots, I’d certainly be willing to use it for production projects. Development on Limelight is active and the productivity advantages of using Limelight are hard to beat.

P.S. If you have a production you’d like listed on the Playbills server, let me know (micah at 8thlight dot com).

Pair Fridays

by: paul | October 6th, 2009 | 0 comments »

8th Light has always had an open door policy towards developers. When anyone has asked to come hang out at 8th Light offices, we don’t turn anyone away. We also invite developers to come in and pair with us. It has been a fun practice to get to know other developers here in Chicago as well as developers traveling through town. We would like to flip that practice around and invite anyone interested in pairing with 8th Lighters or just coming in to hang out.

Every Friday we have a noon lunch and learn (lunch provided by 8th Light) and then we will be available to pair for the afternoon. Want to come in and see how we work? Learn to use Limelight? Teach us something cool? Just hang out with cool developers?

Please RSVP with me (paul [at] our domain name) so we know how much food to order.

Reflection on Hangman

by: micah | October 4th, 2009 | 7 comments »

Last week concluded the Hangman Ruby Sparring Tournament. The results are below.

Unlike the previous Battleship Tournament, I put the effort in to write a competitive hangman player (of course he was banned from competition). This made things interesting. By knowing precisely what it takes to create a player, I was able to precisely tune the scoring metrics. My goal with the scoring metrics was to evaluate the code, without actually looking at it myself, and rate it’s quality/cleanliness on a scale of 0 to 100, where 100 was asymptotically impossible to reach.

It is not easy to score well on ALL the metrics. Each metric will push your code in a different direction some of them are opposing. For example, to score well on the flog metrics, you have to break your code up in to lots of tiny methods. However, extracting methods increases the amount of code you have which brings down the simplicity score. To get an overall high score requires compromising between opposing metrics over and over again. Realistically, writing clean code requires the same type of compromising between coding principles. I am thoroughly impressed with the high scores that people were able to achieve in this tournament.

In the end, I believe that the highest scoring players do fit many of the criteria for “clean code”. Which is to say that to metrics used to evaluate the code are fairly complete. However, there is one gaping hole. The highest scoring solutions look like this:

def b
  @r.fill(0)
  c
  @l = @l.sort_by { |x| @r[x] }
end

People discovered that by using short variable names and method names, they could considerably reduce the “simplicity” of their solution. For this tournament, the simplicity score measures the code mass (compress all the code and count the bytes). It’s a fair metrics because in general, the less code there is, the less code people have to read to understand it. I especially like the fact that comments hurt the score. Anyhow, clearly the code above is not good code.

What’s missing is a analysis tool to measure “Readability” of code. I imagine such a tool would be similar to flog and flay in that it parses your code and examines all names used for variables, methods, classes, etc. When it finds 1-letter names like above, it punishes. When it finds names containing english (or other languages) words, or derivatives of other names, it rewards. For example, it I had a class named “Player”, that’s an english word which is readable. Good. Now a class named “ThingAmaBob” is not english but that not necessarily bad. And you’d expect variables with names like “mythingamabob” or “thingama_bobs” which would be good. There are plenty of ways to expand on the idea. Such a tool would bring our repertoire of metric tools one step close to completion.

Apprenticing to Mastery

by: paul | September 29th, 2009 | 0 comments »

Come see Dave Hoover and I speak about about software apprenticeships on November 19, 2009 in San Fransisco.

Thoughts from a Boutique Software Shop

by: paul | September 12th, 2009 | 0 comments »

Michael Feathers recently wrote a blog about boutique software shops. He drew the parallel between master chefs and software shops. There were a few great points I would like to respond to:

1. “So, where are the high-end restaurants of software development? One place to look is in the “boutique software shops.” I don’t know where I first heard that term, but for me it is a “catch all” for all of the small software development houses that I see springing up all over the place.”

This is an interesting phenomenon. I am not sure if this has always happened or if I am paying attention more to boutique shops now that I am a part of one. 8th Light is an 8 craftsmen software shop that started in 2006 with the goal of writing high quality software. No teaching, coaching, staff augmentation. Just writing software, with the idea that focusing on proving quality has a high correlation to success.

I agree with the high-end software shop analogy. If you take a small team of trained craftsmen focused on doing their best work, the result is most often a very strong culture of quality. Ramsay creates this strong culture of quality through a theatrical performance of yelling and screaming at failure. There are other ways for masters to do the same thing. Micah Martin, the 8th Light master craftsman, creates this strong culture by setting an example of writing good code and holding yourself to a constantly higher standard. This is the common thread that I have seen through these boutique shops–they all have an owner who is a technical leader who creates a strong culture where (excuse the pun) failure is just not an option. There are other similarities like strong discipline, small teams, cutting edge technologies, and ability to develop strong skill sets in developers, however, I think that all of these are direct descendants of the strong leadership.

2. “It’s not that development teams need UX people, it’s more like UX teams need developers.”

I partially agree with Michael. I think this statement can be replaced with any critical specialization in the domain of software applications. The reason UX is getting a spotlight is because, as Michael notes, we have stuck UX on the back burner for so long. In the last few years though, the expectations from users of software have luckily skyrocketed. It is no longer okay to plow through features, but they need to be simple, attractive, and intuitive. When I worked with Gilberto Medrano in 2005, he talked about the UX revolution that was coming. In 2006, he created a UX design while at 8th Light that continues to impress 3 years later (in web application years, that is a lifetime). Well, he was right, I can no longer stand an application which is not aesthetically pleasing. It doesn’t matter how cool the feature set–which is a weird statement to come from a developer.

This is an argument for craftsmen teams. Craftsmen have many tools in their bag, and UX is one of them. Part of being a craftsman is to know enough about UX that you can talk to an expert as well as do some UX. Just like a UX expert craftsman can dabble in code. A craftsmen has many shallow skills as well as a few very deep skills. Craftsmen teams have individuals with diverse expertise talents and a common knowledge of intermediate and beginner talents. It is very fun to be on these teams, when the work is one which has quality–quality of being “aesthetically” impressive as well as “feature set” impressive.

Hangman Tournament

by: micah | August 28th, 2009 | 12 comments »

Several months ago, I hosted the Ruby Battleship Tournament. It was an all-round fun event where craftsmen sharpened their claws and pitted their skills against their peers. Since then, there has been much interest in the next tournament.

Today I am announcing the commencement of the Ruby Hangman Tournament. In this tournament your challenge is to build an AI to play hangman. Unlike Battleship, your AI will not battle against opponents, but will instead play solo. You must teach your player how find words as accurately and as quickly as possible.

The most prodigious player will be dubbed Tournament Champion. But this is a tournament of Craftsmanship, so the ultimate title will be awarded to the Tournament Master. To earn this most prestigious of monikers, your player must not only play hangman spectacularly, but also be crafted with the utmost quality of code.

Getting started is easy. Simply follow the instructions to get a default AI generated and running on your computer. Then all you have to do is tweak the solution to be as good as you can get it before the end of September.

This is a great way to practice your craft. You could introduce the tournament in your next user group meeting. Show it to your peers over lunch and learn.

You can also just play the game if you like (screenshot below). Good luck!

We're Busy!

by: eric | August 23rd, 2009 | 0 comments »

This week is a big one for the 8th Light team. Let’s head through the highlights:

Agile 2009

As usual a large number of 8th Lighters will be participating at Agile 2009. This is always a fun and educational experience for us, and this year it’s in our hometown. Let’s go through the talks we’re giving:

Mission Impossible: TDD and Javascript In the New Orleans room on Tuesday at 11:00 Jim Suchy will be giving a talk on doing TDD in Javascript. Javascript is a language that people tend to claim is “untestable” or “not worth it” but Jim will be showing that testing is not only possible, but worthwhile. In addition he demonstrates some of the neat features that make Javascript a cool language.

Ruby Kata and Sparring Back in the New Orleans room on Thursday at 9:45, Micah Martin will be talking about Ruby Kata and Sparring. Everybody wants to be a great developer, but how do you do it? Micah will show two different practice techniques, kata’s and sparring. If you go to this talk you get to judge the speaker and tell him how well he codes. How often do you get to do that?

TDD on iPhone The Eric’s are giving their legendary talk on practicing TDD on the iPhone on Thursday from 2:00 - 3:30 in Grand Ballroom F. This time we have a special surprise for those who attend - a Randori coding session where you will code functioning iPhone application. Please wash your hands before attending, as you’ll be using my keyboard. Head to my github page to see a sneak preview of what we’ll be working on.

Live Aid Once again some 8th Light guys will be helping out with Live Aid, including our newest Craftsman Colin Jones. Come to the stage, write some Rails, help charity. 10 minutes or 10 hours it doesn’t matter. Experience in Rails or even web development are unnecessary - that’s what the mentors are there for.

chiPhone

The second meeting of chiPhone, the Chicago iPhone developer group, will be held at a special location this week: the Obtiva offices! Thursday night if you’d like to do some hacking head to the chiPhone website to register - or just show up. I only need to count so I order the right amount of pizza.

SCNA America

I saved the best for last. Software Craftsmanship North America is a joint effort by 8th Light and Obtiva and frankly it has the best speaker lineup I’ve ever seen. Registrations are still available and cheap! If I could take credit for this I would - but it really goes to the organizers, who did a fantastic job. The entire 8th Light staff well be there and available for discussion, questions, and to accept free beer from the attendees. Meanwhile two of us will be speaking:

The Business of Craftsmanship “Craftsmanship sounds expensive!” If you’ve heard similar comments from your supervisors or clients, then join Micah, Kevin Taylor and Carl Erickson, three experienced craftsmen-turned-entrepreneurs for this 30 minute panel discussion. All three panelists come from technical backgrounds and have built successful software development companies that are built on craftsmanship values, such as quality, learning, and community, and use Extreme Programming practices to develop software.

Apprenticing to Mastery Listen to Paul and Obtiva’s Dave Hoover discuss how an Apprenticeship program can benefit your company and your career. Software companies are always looking for ways to develop skilled developers. Formal software apprenticeship is the approach taken by more and more companies, including Obtiva and 8th Light. Over the past 2 years we have observed almost a dozen apprenticeships and come to recognize certain apprenticeships of developers that are themed by their aspiration to mastery.

This might be the biggest week in 8th Light history - hope to see you there!

JRuby Installer Samples

by: micah | July 21st, 2009 | 1 comments »

The JRuby dev team is interested in distributing friendly installers for future released of JRuby. The installer will take care of unpacking files, setting environment variables, and even installing Java is need be. Sweet huh?

Having worked with Install4J on Limelight, I proposed using it for JRuby. The good folks at ej-technologies were kind enough to donate a license so I whipped up some installers. But there are a few options to consider and we want to choose the option that offers the best experience.

Below are links to sample JRuby installers for Windows (built on my mac) using Install4J. If you’re willing, try out an installer and let us know what you think.

Disclaimer: Use at your own risk.

Bowling in Clojure

by: micah | July 20th, 2009 | 2 comments »

I’ve been long overdue to learn a new programming language and Clojure recently caught my eye. Clojure attracted my attention because it seemed like a rich Lisp dialect where I could learn all the goodness of functional programming, and it runs on the JVM allowing me to make use of all hte Java goodness out there.

Along with a couple colleagues at 8th Light, I read Halloway’s Book. We then challenged each other to write the bowling game in Clojure so we could compare our solutions. Coincidentally, my father, Unclebob, performed the same exercise independently. Below is my solution.

First comes the tests:

(ns micah.test.bowling (:use micah.bowling clojure.contrib.test-is))
(deftest test-gutter-game
  (is (= 0 (score (repeat 20 0)))))
(deftest test-one-pin-wonder
  (is (= 20 (score (repeat 20 1)))))
(deftest test-one-spare
  (is (= 20 (score (concat (list 5 5 5) (repeat 17 0))))))
(deftest test-one-strike
  (is (= 30 (score (cons 10 (repeat 18 1))))))
(deftest test-perfect-game
  (is (= 300 (score (repeat 12 10)))))
(deftest test-all-spares
  (is (= 150 (score (repeat 21 5)))))
(deftest test-heart-breaker
  (is (= 299 (score (concat (repeat 11 10) (list 9))))))
(run-tests)

And the production code:

(ns micah.bowling (:use clojure.contrib.seq-utils))
(defn score [rolls]
  (loop [score 0 rolls (vec rolls) frame 1]
    (if (> frame 10)
      score
      (cond
        (= 10 (rolls 0)) 
          (recur (+ score 10 (rolls 1) (rolls 2)) (subvec rolls 1) (inc frame))
        (= 10 (+ (rolls 0) (rolls 1)))
          (recur (+ score 10 (rolls 2)) (subvec rolls 2) (inc frame))
        :else 
          (recur (+ score (rolls 0) (rolls 1)) (subvec rolls 2) (inc frame))))))

Thoughts

As with learing any new language, writing this first program was frustrating. Getting the environment running took a while and simple tasks, like creating a list of 20 zeros, required several minutes of research. Nonetheless, I was very pleased when it was complete.

I was quite impressed with size of the program. Compared to previous Java solutions I’ve written, this Clojure solution is about 20% the size. That’s a huge size reduction. But as I compare the solutions more, it occurrs to me that the Clojure solution is also about 20% as readable. Just look at it! You could get lost in that cond statement for eons.

Now my craftsmanship spirit was nagging me all the while I was coding, just begging me to refactor. However, I struggled to find good ways to improve the code. All my typical tricks, extract variable, extract method, didn’t feel right. My hope is that I’ll acquire new tricks to refactor in Clojure from experienced Clojure programmers, perhaps like you. Please let me know if you see a way to improve my code.

Reasons to Attend SCNA

by: paul | July 17th, 2009 | 1 comments »

SCNA website

1 - “The list of SCNA presenters reads like Who’s Who of Software Jedi Knighthood” -- Ray Hightower

This is a complete testament to how willing and excited the thought leaders and software masters were to speak at this conference. The creme of the crop in software mastery will be talking about how to raise the bar in our industry. I have never seen a lineup of speakers who put me in such a state of awe since the early XP Universe days. Thanks to all of them for getting together for this conference.

2 - Join software craftsmanship over crap.

Last year Uncle Bob challenged software developers to become professionals. We have spent a year of summits, manifestos, meet ups, and conferences trying to figure out how to move forward towards professionalism with this paradigm of software craftsmanship. The momentum of craftsmanship is only growing.

3 - Software craftsmen all in one room.

The google map of software craftsman who have signed the software craftsmanship manifesto has proven this to be a global community of software developers. It is unique that we have people flying in from multiple continents to participate. I am excited to meet face to face with all these craftsmen whom I know only their ideas and email addresses.

4 - Richard Sennett

A sociologist who wrote The Craftsman, Dr. Sennett has provided a template for studying the habits and techniques of craftsmanship. He touches on everything from extending your concentration to why we choose vocations so passionately. It is a true authority on craftsmanship.

Up and running with TDD on Android

by: colin | July 11th, 2009 | 2 comments »

A couple of weeks ago, I happened to be in the right place at the right time (the first ORD Session) when Google hooked a bunch of developers up with an Android Dev Phone 1. I'd been interested in Android for awhile because it's a more open platform than the iPhone, and the code is Java (I've never worked in Objective-C), so I was excited. After my initial excitement of hacking around and getting things to work, I decided to regain my discipline and figure out a workflow for TDD. The good news is that JUnit is built right into the Java framework that Android app have available. The less-good news is that writing and running tests on Android isn't as well-documented as many other facets of the application framework. I'd like to share my setup, which doesn't depend on any specific IDE or text editor. I'm assuming Mac or Linux here, but I'm sure Windows would only require minimal changes. Other assumptions:

The Android SDK is installed
Android tools directory is on the PATH
Ant is on the machine and on the PATH

Note: the "tools" directory is the main one, not the one below "platforms" - in my case: '/Users/colin/lib/android/tools' Let's get started by creating a project with the command-line utility, which will give you the test directory structure and build files that you need (you won't get these with the Eclipse or IntelliJ plugins, for instance). Of course, you can read documentation for the android command to see more details, but here's what we're doing:

  $ android create project -t 1 -p tictactoe-android -a TicTacToe -k com.colinwjones
  $ cd tictactoe-android

All of these options are required (-n, the project name, is optional, and I've left it out above)

-t is the build target platform (1 refers to Android version1.1 on my machine, see the ids in $ android list targets for yours - this is important to remember as you'll need to refer to it later)
-p is the path of the new project to create (make up a folder name for your new project
-a is the first Activity that you want to create
-k is your package name

Next, we want to create an AVD (Android Virtual Device) if one doesn't already exist - it's an emulator for the phone operating system. We can check to see if one exists already first:

  $ android list avd

If you don't have an AVD already, create one:

  $ android create avd -n ColinPhone -t 1

You'll be asked if you want a custom hardware profile (I don't, so I just hit Return).

-n is the name of the new device
-t is the target platform, as before (and it should match your project's platform)

At this point, let's go ahead and fire up the emulator, making sure to match the name to the one you created. It's good to make sure that our state at this early point is a good one.

  $ emulator -avd ColinPhone &

Here I'm launching the emulator (AVD) in the background so I don't need to open up a new Terminal window. You'll get some output in your terminal window; if it bothers you, Ctrl-L will freshen it up. Now we'll build and install both of your apps (the test package is really a separate application, which is a good idea to keep the tests out of the eventual deployment package anyway).

  $ ant debug
  $ adb install -r bin/TicTacToe-debug.apk
  $ cd tests
  $ ant debug
  $ adb install -r bin/TicTacToe-debug.apk

The debug target isn't actually defined in either buildfile (build.xml or tests/build.xml), but is available nonetheless (see $ ant help for other targets you might not otherwise find). This takes care of bundling resources, compiling, converting classfiles to Android's .dex format, and packaging. Note that adb is NOT ant - it's the Android Debug Bridge, and it's invaluable for working with the emulator. The -r option to adb install reinstalls the package if necessary. Now, this is pretty redundant-looking, but just remember that the tests directory is a sort of parallel structure with your project directory, and you need both. It's time to run the default test suite that the android create project call has given us (this can be run either from tests directory or from the root of the project):

  $ adb shell am instrument -w com.colinwjones.tests/android.test.InstrumentationTestRunner

Of course, you'll want to substitute your package and activity names for the ones in my examples. It's very important to realize that you've just compiled and installed your software on the emulator and are running tests on it there. In order to do TDD, you'll need to recompile changed code and reinstall on the emulator. I hope that one day there will be a way to avoid going through the emulator each time (or that there already is one that I've been unable to find), but this is the only method I've been able to get working so far. Now we need to actually add a real test to (in my case) tests/src/com/colinwjones/TicTacToeTest.java. Here, an IDE like IntelliJ or Eclipse comes in handy, especially if you're just starting with Android and aren't sure of the methods you might want to use.

  // with imports at top:
  import import android.widget.Button;
  /* some code
   * ...
   * ...
   */
  // inside your test class:
  public void testNewGameButtonExists() throws InterruptedException
  {
      Button button = (Button) getActivity().findViewById(R.id.new_button);
      assertEquals("New Game", button.getText());
  }

Building our test package at this point will fail, since no resource with the new_button id exists yet. Let's do it anyway to see the first failure and guide us to our implementation code (running this from the tests directory):

$ ant debug

The error tells us where to go next: we'll implement the button in /layout/main.xml (making sure to set the right ID on the button). Since we changed the main layout, the implementation package needs to be built first, then the test package:

  $ cd ..
  $ ant debug && adb install -r bin/TicTacToe-debug.apk
  $ cd tests
  $ ant debug && adb install -r bin/TicTacToe-debug.apk

Now run the tests again:

  $ adb shell am instrument -w com.colinwjones.tests/android.test.InstrumentationTestRunner

Great! Now we have a proper failure:

  com.colinwjones.TicTacToeTest:
  Failure in testNewGameButtonExists:
  junit.framework.AssertionFailedError: expected:<new game> but was:<>

We just need to add the right text in the XML layout: Let's rid of the default "Hello, World" TextView in main.xml while we're at it. Now rebuild, reinstall, and re-run tests

  $ cd ..
  $ ant debug && adb install -r bin/TicTacToe-debug.apk
  $ cd tests
  $ ant debug && adb install -r bin/TicTacToe-debug.apk
  $ adb shell am instrument -w com.colinwjones.tests/android.test.InstrumentationTestRunner

This is getting annoying typing all these commands: we're going to want to write a shell script or Ant task to do this for us. But for the time being, we'll plod through (that was the last time, though). Now we're passing:

  Test results for InstrumentationTestRunner=..
  Time: 1.009
  OK (2 tests)

It's a bit strange that the test runner claims we have 2 tests: each test class will add one of its own. Now that we've seen how to get the tests running, let's automate it by adding Ant tasks to the build.xml in the main project directory. You'll need to set the environment variable ANDROID_TOOLS for this exact task to work, or you can provide the full path to adb.

    <target name="clean">
        <delete includeemptydirs="true">
            <fileset dir="bin" includes="**/*" />
            <fileset dir="tests/bin" includes="**/*" />
        </delete>
    </target>
    <target depends="clean, debug" name="test">
        <property environment="env" />
        <property name="android-tools" value="${env.ANDROID_TOOLS}" />
        <ant dir="tests" antfile="build.xml" inheritall="false" target="debug" />
        <exec executable="${android-tools}/adb" failonerror="true">
            <arg line="install -r bin/TicTacToe-debug.apk" />
        </exec>
        <exec executable="${android-tools}/adb" failonerror="true">
            <arg line="install -r tests/bin/TicTacToe-debug.apk" />
        </exec>
        <exec executable="${android-tools}/adb">
            <arg line="shell am instrument" />
            <arg value="-w" />
            <arg line="com.colinwjones.tests/android.test.InstrumentationTestRunner" />
        </exec>
    </target>

Now we can just run

  $ ant test

from the project directory (assuming the emulator is already up and running with $ emulator -avd ColinPhone &), and we'll be good to go. Honestly, it's a pretty simple process: the key for me was in using the Android command-line tools rather than IDE plugins. It helped me to understand the build process and get beyond the initial frustration of not having the IDE do the work for me. I imagine things will change a bit for Windows users, so please leave comments if there's anything drastically different (and also if things change for Mac/Linux users as the framework develops). I do hope this will help someone else to get set up and save the headache I had when first discovering Android.

###############