Archive for the ‘Training’ Category

Code Retreat in Boulder, Colorado

February 26, 2011

I’m in beautiful downtown Boulder, getting ready to attend a code retreat with Ruby greats like Corey Haines, Chad Fowler, Dave Thomas*, Mike Clark, Michael Feathers and many more.

Last night I hung out with some KC friends and we setup our dev environments for the event. I got motivated, and created a base environment on GitHub you can download. It runs your tests automatically using Watchr every time you save your code file, and if you’re on a mac it even takes a screen shot at each save! Now you can go back and relive the magic. Maybe string them together into a video with a little commentary, and boom – easy post-retreat blog video.

Use the link above, and let me kno w if it was useful!

*not the Wendy’s guy, as my wife likes to ask. You’d think since the world is down to just one living, notable Dave Thomas that joke would get a little old. I think the people who grew up watching Wendy’s commercials will also have to die out first :)

Review of the “Database is Your Friend” Workshop by Xavier Shay

August 23, 2010

Xavier ShayThis Saturday I had the privilege of attending Xavier Shay’s “Database is Your Friend” workshop right here in Kansas City. It explores the enterprise domain of high-traffic, mission-critical databases in Rails. At $350, the price tag trumps just about every regional Ruby or Rails conference I’ve heard of. It was worth the price, and more. It would have been well worth the expense of travel and lodging if it had been out of town.

I’ve never had such a thorough learning experience. Xavier had a git repository setup with several branches of a basic Rails app, which we all cloned. He would give a 10-15 minute overview of a difficult concept, then we would checkout a given branch, and spend about 20 minutes completing whatever part of the code Xavier had omitted. We used test-driven development much of the time, which forced us to fully understand the cause and effect of each technique.

Xavier was in constant motion, visiting each of the six students to ensure everybody got it. After all, the exercises themselves were mission critical, because the following lessons built upon them. After experiencing this, I wonder why all teaching isn’t done this way. The “Long Lecture, Here’s Your Homework, Now Get Out” system I remember from college could benefit a lot from this.

It’s obvious a lot of love went into the design of the workshop. The flow was so natural that several times, one of us would ask a question and Xavier would answer that the next segment addresses it. The result was a natural progression of solving more and more complex problems.

If you struggle with (or wonder about) data integrity and high-traffic database issues, take the opportunity to learn from Xavier Shay on his current tour.

PS –

While this workshop is definitely worth travelling, I didn’t have to. Wes Garrison of Databasically, who helps organize our monthly Ruby meetings, took the initiative. Xavier normally attaches his workshop to conferences, but Wes looked at the schedule and saw that Xavier had a small gap between his Chicago and Austin dates. Wes offered to arrange both travel and lodging for Xavier, who luckily agreed to squeeze another workshop into his busy schedule. Wes, thank you.

Introducing: Rails Kata

June 24, 2010

A Scary Idea is Born

In a previous post about RailsConf and Code Kata, I decided to take action, and begin publicly practicing my programming craft. Without further ado, I give you my brainchild: I’ve designed my first personal kata.

I’ve been meaning to get into the Cucumber testing framework for a long time, so my first kata was to create an entire MVC stack, test driven, using Cucumber and Shoulda. I recorded it. It took 100 minutes. So I went back to the drawing board for something more fundamental – basic data modeling with my chosen testing framework and editing tools. Voila, a ten minute kata practicing the most fundamental rails tools.

I’m posting my work on Vimeo, due to their unlimited video lengths. I invite you to record your own version of this kata, and post the video link in the comments! Let’s learn from each other.

So here’s my first try. I’m not good at screencasting just yet. I also have a sore throat, making my narration a little scratchy. But I welcome feedback.

My RailsConf Takeaway – Kata and Code Retreats

June 16, 2010

I attended RailsConf last week, and it was amazing. I met a lot of amazing people (including a handful of personal geek heroes) and became truly fired up about my personal craft of programming. Serendipity played a big part, as a series of events lined up to help me form my new strategy for being a better developer.

On the plane ride out, I read the first half of Malcolm Gladwell’s Outliers. Chapter 2 had me spellbound. The title: The 10,000 Hour Rule. In study after study, the author showed that to truly master a craft, only a nominal amount of intelligence and “natural” talent are required. For instance, any IQ above 120 should be more than capable. After that basic filter, what separates the masters from the rest is *practice*. About 10,000 hours, by most studies’ estimates. That could be practicing baseball, music (not just performing, but practicing to intentionally get better), or chess. You get the idea.

Fast forward to the Ignite RailsConf event Sunday night, where 14 speakers had 5 minutes each to give a lightning presentation, with no overtime. Three of those speakers mentioned the 10,000 hour rule. Later in the week, Yehuda Katz gave a keynote where he said he’d only been programming since 2004! Just six years, about half my professional career, and he’d mastered Ruby and Rails to the level of being a core member of the Rails team. How? Finding “impossible” challenges, and doing them. This is, of course, the essence of practice – making a concerted effort to complete tasks that were previously out of your ability.

But it gets better. BohConf (the official unconf of RailsConf) hosted a mini code retreat Tuesday afternoon. Code retreats, as defined by Corey Haines, blend Dave Thomas’ concept of Code Kata with pair programming and repetition. You pair with someone, and work to solve a common programming problem, most typically Conway’s Game of Life. You have about 30 minutes to write a purely test-driven solution. Then you reflect on what you were able to get done, delete the code, find a new coding partner, and start all over! This is practice and feedback combined!

Over the week, the idea rolled around my head. And during my extended 12-hour plane trip home. And all weekend. I need to be practicing, in order to master my craft. I need to create my own collection of code kata – “fundamentals” I can practice over and over until they become second nature. I also want to pair program more, and perform my kata in public where I can be open to feedback.

I have a plan for this, which I’ve already put in motion. Stay tuned :)

UPDATE: I have posted my first (official) kata at vimeo. Read my blog post about it.

Announcement: Kansas City Ruby User Group Meeting

January 11, 2010

Every month, the Kansas City Ruby User group meets to discuss current events in the development world, and learn from each other. This month, Shashank Date will be offering a refresher of his talk from last year on Procs and lambdas. Often, Ruby on Rails developers can be strong on Rails, and light on Ruby.

This talk covers one of the most powerful Ruby features that is used all the time by the Rails framework itself. Newer developers, however, may not realize just how easy it is to harness the power of blocks, and by extension Proc and lambda calls, in methods. I might also stand up and give a brief rundown on binding, a closely related concept.

The Where and When

If you live in the Kansas City area, join us Tuesday January 11, 2010 at 6:30pm here:

Centriq Foss
8700 State Line Road
Leawood, KS 66206

Visit the meetup page for more info.

Preview

To give some background, here’s a code snippet that illustrates a block:

def do_for_each(array=[], &block)
   array.each{|element| block.call element}
 end

do_for_each([1,2,3]){|x| puts x}

A Ruby block is a chunk of code that can be passed to a method and run at will. This code prints each element of the array on its own line. If this looks familiar, that’s because it’s really a lamer version of the Array class’ map instance method.

When you pass a block to a method like this, you’re recreating a Proc object implicitly. You don’t have to do anything extra, and Ruby knows what to do with this extra code hanging off the method call. But what if, for instance, you needed to pass *two* blocks into a method? Here’s one way:

def custom_print(words, quiet, loud)
  words.each do |word|
    if word =~ /!$/
      puts loud.call(word)
    else
      puts quiet.call(word)
    end
  end
end

words = ['hello', 'world!', 'turkey']
custom_print(words, lambda{|w| w + '.'}, lambda{|w| w.upcase})

In this example, words are “loud” if they end in an exclamation point. I chose to end quiet words with a period, and to capitalize loud words. Please join us Tuesday for a much more detailed explanation.


Follow

Get every new post delivered to your Inbox.