Pages

Saturday, January 16, 2010

CodeMash Precompiler Session # 1 - Ruby Koans

As I mentioned in my last post, I recently returned from CodeMash 2010, where I attended two PreCompiler sessions. For the morning session, I attended "The Ruby Koans, Learning Ruby One Test at a Time with Joe O'Brien and Jim Weirich" which taught Ruby syntax and how to write tests in Ruby. (Joe also gave an excellent and extremely popular talk called: "Refactoring the Programmer"

The word "koan" comes from Zen Buddhism. As I understand it, Jim and Joe called their talk "Ruby Koans" because of their unique style of teaching that relies as much on mystery and intuition as it does on rational thinking.

Jim has asked participants in the CodeMash session to show the koans to someone else, so I encourage you to look at them. You can try the koans yourself as follows:

(1) Have a working version of Ruby:
- Windows: Install from: http://rubyforge.org/frs/download.php/66871/rubyinstaller-1.8.6-p383-rc1.exe
- Macs: OS X comes preloaded on Macs so you are ready to go.
- Linux Users: Use apt-get, or whatever is appropriate for your system

(2) Download the Ruby Koans and install into a working directory:
- http://cloud.github.com/downloads/edgecase/ruby_koans/rubykoans.zip

The file README.rdoc is a text file that explains the concept, tells how to get started, and gives contact information.

To set up for the exercise: unzip the koans, open a command-prompt, and cd to the directory containing the koans. The exercise starts at the most simple level possible, but if you complete the koans, you will learn most of the Ruby syntax and see examples of how Ruby behaves at edge cases.

To start the exersise, give the command:
ruby path_to_enlightenment.rb
You should see the following result:

Thinking AboutAsserts
test_assert_truth has damaged your karma.

You have not yet reached enlightenment ...
is not true.

Please meditate on the following code:
./about_asserts.rb:10:in `test_assert_truth'
path_to_enlightenment.rb:28
The line " is not true." gives a hint as to why the test failed.
The line after the "Please meditate..." line tells what line of code the test failed on.

Looking in the file about_asserts.rb around line 10, we see:
def test_assert_truth
assert false # This should be true
end
In Ruby, def/end declares a method, and the word: "test_" at the start of the method name declares it as a test. The comment is a hint from Joe that the test fails, in this case rather obviously, because it is asserting false. So this koan demonstrates the a test in its simplest form, one that asserts a boolean condition. If you change false to true and run "ruby path_to_enlightenment.rb" again, that test will pass and the error you will see:
Thinking AboutAsserts
test_assert_truth has expanded your awareness.
test_assert_with_message has damaged your karma.

You have not yet reached enlightenment ...
This should be true -- Please fix this.
is not true.

Please meditate on the following code:
./about_asserts.rb:16:in `test_assert_with_message'
path_to_enlightenment.rb:28

So now the test_assert_truth test passes and the test_assert_with_message test is failing. The code for the second test is:
def test_assert_with_message
assert false, "This should be true -- Please fix this"
end
and we see where the "This should be true..." message comes from. Joe has now shown us what an assertion with an error message looks like. Again change false to true, rerun the ruby command and you'll see the next failing test.

The koans go on to present illustrations of control statements, hashes, scope, strings, arrays, inheritance, iteration and others language details. I don't think anyone at the PreCompiler finished all the exercises during that session - I sure didn't - but it's clear that I will know a lot about Ruby syntax when I do.


Finally if you have questions about the koans, you can reach Jim at his website http://onestepback.org/ or @jimweirich on Twitter. Or you can reach Joe at his website http://objo.com or @objo on Twitter

Back from CodeMash 2010

I just got back from a great experience at CodeMash 2010. This was my first CodeMash, and it will certainly not be my last. If you're a software developer and you've never gone to a CodeMash, I can't recommend it enough. (If you're a developer and you've already gone, I don't have to say anything because I know you'll be going back.) Besides all the technical goodness, there was lots of fun!

If you're not familiar with CodeMash, its home page describes it as a unique two (or optionally three) day event:
"... that will educate developers on current practices, methodologies and technology trends in variety of platforms and development languages such as Java, .NET, Ruby and PHP. Held [in] January, at the lush Kalahari Resort in Sandusky, Ohio, attendees will be able to attend a world-class technical conference amid Ohio's largest indoor waterpark.
There were also sessions on career development, TDD/BDD, Agile/Lean/Kanban methodologies, dynamic languages like F# and Scheme, development for mobile platforms like iPhone and Android, and too many more for me to list here. See the session list for more, and for detailed writeups and presenter bios.

This year, there were three keynote addresses and loads of software-development-related sponsors, the likes of Microsoft, Amazon, Compuware, RedGate, and ComponentOne gave talks, demonstrations, held raffles and gave away lots of swag.

But some of the most valuable experiences come from talking with other developers in the hallways, between sessions, at open space meetings organized by participants based on their interests, in the Coding Dojo room, and at the cocktail party.

I mentioned that CodeMash is two or optionally three days. They call the optional third day events, held the day before the official conference opens, the PreCompiler. The PreCompiler Sessions are 4 hour, hands-on, interactive labs. That's not to say that if you only attend the main conference you won't have a chance to sit down at a machine and try somethings out, but interactive sessions at the main conference are shorter (only about an hour) and tended to be less in-depth.

I attended 2 PreCompiler sessions, "The Ruby Koans, Learning Ruby One Test at a Time with Joe O'Brien and Jim Weirich" and "Practical T/BDD - Half Day Hands-on Lab with Phil Japikse"

I'll tell about these in subsequent blog posts.

Monday, January 11, 2010

Grand Rapids CodeRetreat ... but it's in Ruby

I'm a big fan of CodeRetreat. Besides being a fun day, it's a great way to practice agile things like: pair programming, supportive environment, software craftsmanship, TDD, retrospectives, courage, and so on. I think they are great events for both aspiring Agilists and experienced Agilists.

I read Jeremy Anderson's blog post about an upcoming CodeRetreat in Grand Rapids. I was all set to go when I read that it will be held in Ruby, and since I haven't used Ruby, I was discouraged. As much as I'd like to try it, I'm not sure how much time I'll have in my schedule before then.

Then I found TryRuby. It offers an interactive Ruby prompt and a follow-along tutorial, right in your browser! And there's another tutorial I found, Ruby in Twenty Minutes .

So I guess I'll have to revisit the sessions I planned to attend this week at CodeMash 2010 and see if there are beginner Ruby sessions. Perhaps, between them and some extra work during downtime, I'll pick up enough Ruby to feel comfortable attending the Grand Rapids Code Mash next month.

Monday, November 23, 2009

What is agile communication?

In thinking about some things for the Agile Skills Project, I realized that agile teams communicate differently than non-agile teams.

It seems to me that agile communication aims to be:
  • public (vs private or secret) [public within the entire team, not public as in news media]
  • early (vs delayed)
  • spoken, preferably in person (vs email)
  • free from judgment (vs assigning blame)
  • osmotic (vs selectively broadcast)
  • flat (vs hierarchical)
A significant enabler of agile communication is the Supportive Environment Agile Pillar.

What characteristics of agile communications do you notice?

Monday, November 16, 2009

Why we say: "No Best Practices"

I came across an great article from 2005 titled: No Best Practices and it reminded me that there was some discussion about the term "best practice" at the recent 1DevDay event.

Besides speaking to reasons why we say there are no best practices, James Bach gives a nice list of "simple, honest alternatives":
  • “Here’s what I would recommend for this situation.”
  • “Here is a practice I find interesting.”
  • “Here is my favorite practice for dealing with {x}.”
  • “{Person X} attributes {practice Y} for his success. Maybe you’d like to learn about it.”
as well as a list of answers to common replies to his argument, replies like:
  • “I don’t mean ‘best practice’ literally. I’m just suggesting that this is a damn good practice.”
  • “When I said this practice is a ‘best practice’ I meant it was best for a certain context. But pretty much everyone in the industry shares that context, so what’s the point of talking about context?”
  • “This practice represents a consensus among industry leaders.”
  • “Lighten up. It’s just an expression.”
It really helped me get clear about why we say: "No Best Practices".

Sunday, November 15, 2009

My (growing) Agile Booklist

In no particular order, here are the agile books currently in my bookcase:

  • Practices of an Agile Developer, by Venkat Subramaniam and Andy Hunt
  • Clean Code, by (Uncle) Bob Martin
  • Refactoring: Improving the Design of Existing Code, by Martin Fowler
  • Test Driven Development: By Example, by Kent Beck
  • Working Effectively with Legacy Code, by Michael Feathers
  • Agile Principles, Patterns, and Practices in C#, by: Martin C. Robert & Martin Micah

CodeRetreat 12-5-09 LeanDog

I'm looking forward to attending CodeRetreat 12-5-09.
It's a free event, sponsored by and held at LeanDog. If you aren't familiar with the idea of a Code Retreat, as promoted by my friend Patrick Wilson Welsh, take a look at his description here.

Briefly, it's an event where agile software developers get together and pair program several solutions to a practice program, with the goal of honing our craft and furthering learning and discussion (Think software kata.) The event hits 5 of the 7 agile skill pillars proposed by the Agile Developer Skills Project:
* Collaboration
* Supportive Culture
* Confidence
* Technical Excellence
* Self-Improvement

I attended the previous LeanDog CodeRetreat and it was great! Lots of talented developers, great practice and learning, tech talks and a party-like atmosphere.

LeanDog's location is amazing. Their website describes says:
Our office is floating in downtown Cleveland right next to the U.S.S. Cod (a WWII Submarine), the Burke Lakefront Airport, and the Rock and Roll Hall of Fame. We are located on a converted steamship, the Keasarge, that was formerly known as Hornblower’s Barge and Grill. The restaurant setting remains and offers open spaces that are perfect for practicing Agile. Our location gives a great view of the skyline of the city we support.

We'll be coding in Java again, but if you want to learn or practice pairing and you don't know Java, don't let that stop you. That was my situation last time and it was still a great experience!