Winging It

Large Latte, No Foam, Extra Code Please

A little over a year ago, Code and Coffee was born. After a weekend in Kalamazoo and a good talk with Mike about his little group of Bitslingers in Cincy, Jeffery and I stole borrowed hatched the idea to get our butts out of bed early, hit a coffee shop somewhere, and write some code. Any code would do, but preferably something outside our comfort zone. Code and coffee numero uno saw us working on the Ruby Koans.

It’s moved around Columbus to different places. Started out at Polaris, held in Dublin a couple times, and we’ve had a pretty regular group at Stauf’s in Grandview since last November. I’ve lost track of the number of new faces that have showed up at our little gathering, but there are a few – like Greg and Andrew – who have been to almost all of them.

“Yeah, so what, Wingfield…we know you do this Code and Coffee crap, it’s in your twitter stream more than ice hockey and Hair Band Friday combined.”

OK, ok…my point: Last Thursday, Aug 12th, we had a 23 geeked up, caffeinated coders in 3 locations in two different cities writing code for the fun of it before they went to work. 23 guys and gals in Grandview, Columbus, and Indianapolis. (Props to Scott for getting it rolling in Indy!) 23 people would be one helluva dev team; especially if it’s THESE 23 who care enough to get up and do an hour of coding for fun before work.

What do these 23 people compare to?

• That’s a whole football team plus a kicker
• That’s 10 more people than have ever coached the Chicago Bears
• That’s an entire active NHL roster
• That’s one less than all the sousaphone players in the OSU Marching Band…in other words, it’s all the sousaphone players NOT dotting the I.

That’s a lot of sports references for a bunch of geeks so…

• 23 is the atomic number of vanadium
• 23 is the port used for telnet
• Julius Caesar was stabbed 23 times…that might be a bad example
• 23 is the lowest prime number to consist of consecutive digits. (Back to geekdom!!)

I’ve had a lot of fun at Code and Coffee and can’t deny having 23 people at three locations on some random Thursday brings a smile to my face.

But why stop at 23?

Want to geek it up with fellow geeks? Start a Code and Coffee. Pick a place to meet and a time and hit up twitter. (We use the hashtag #codeandcoffee, it’s worked great for setting up gatherings.) Let’s go beyond 23 folks.

At least to 34 so I can make some Walter Payton references.

45 for a little Archie Griffin.

Then to 61 so I can add Rick Nash to the fray.

Why Not Add Some Ruby?

If twitter is good for one thing it’s starting debates amongst your friends. Today didn’t disappoint as Mike started us off with: “things i miss from rails while i'm doing java: rails.”

It started in the productivity trap, which is going to be subjective to the developer doing the work, so it’s a tough one to measure. Can I do some things faster in Ruby than I can C#? Yes, but the inverse is still true.

One point I need to make is I’ve seen a few of these discussions and often they become Rails v. C#/.Net, which isn’t really a fair comparison because Rails is a web framework. To go apples to apples, you need to compare Rails to ASP.Net MVC, not .Net in general. You wouldn’t compare WebForms or WPF to Ruby or Python, would you? (You shouldn’t compare WebForms to much of anything…but I digress.)

So, Jon asked a pretty valid question: Why don’t more people switch? Since I come from a .Net background, I’ve really only seen this debated as it pertains to .Net.

For a number of the arguments around the IDE, Intellisense, Static v. Dynamic typing, there are plenty of other blogs that have covered this, here’s a recent one I really liked: Ruby is Scary.

For my quick entry here, I’ll say this…I can have VIM or TextMate open and have a couple tests written before the VisualStudio splash screen has closed. Also, those two tools have yet to throw an “Out of Memory” exception on me, can’t say the same for Studio.

And I don’t really miss intellisense.

On with the show…

On the heels of Jon’s question Bill Sempf jumped in. As a bystander, Bill was very much representing the average .Net dude, and the arguments I’ve heard from the average .Net dude. (Bill has looked into Ruby, we’ve paired writing Ruby. That’s not really the point here, though.)

Ruby, the Average Dev, and the Complex System

@JonKruger: That's not my problem. I just don't think that 80% of the dev teams out there can handle coding in Ruby. (link)

That was Bill’s entry to the discussion, and I’m not sure I can disagree with him. However, I’m going to be snobbish and self centered and say I want to work with the 20%. If you’re in the 80% and can’t code Ruby…or Python, or F#, or any other language you have to learn…I don’t want to work with you. You can stay in “The Enterprise.”

@JonKruger: My point is those stories are told by top-tier devs, and not everyone is one of those. (link)

Again, tough to disagree with Bill’s assertion here. Not everybody is a rock star, and that’s cool. If you’re a budding rock star, you’ll be able to write some effective Ruby code.

In between those tweets were a few others, mainly around supporting complex systems using Ruby. Personally, I haven’t written a large scale application in Ruby, so I can’t lean on any experience here in writing the typical central Ohio “claims app” in Ruby.

What I have done with it has worked well. So my first counter to Bill’s argument on the complex systems: Use it where it fits. Ruby brings a great set of DSLs to the table for testing, web frameworks, and testing. Yeah, said it twice. Year one of Codemash (Jan of ‘07) I listened to Neal Ford talk about DSLs to help write your applications and Polyglot programming. Using Ruby to support your app – to write build scripts, tests, POC web sites – falls right in on the polyglot thing.

On the testing side, I’d much rather read a batch of RSpec tests than a batch of nUnit tests. Cucumber is already helping my current team get through some testing issues. Let me repeat that: I’m using Cucumber in a .Net environment RIGHT NOW to help the team get better test coverage on their application.

Learning a New Language

@JonKruger: There is a difference between learning the language, and being productive in it. (link)

I’m in total agreement with Bill here. Which is why I’m such a big fan of the incremental approach to using Ruby on your projects.

Great place to start: use Rake as your build script. I’ve done this for a couple years now, it’s a great way to dip your toe into Ruby, get comfortable with the language and a few of its concepts without really getting in on your production code. On the .Net side, use Albacore with Rake and you’ll have a build script in no time.

Next up you can start writing some tests in it. That’s a pretty good way to pick up a new language, anyway. And with the nice testing tools with Ruby, you can learn a new language and ease some testing pain.

But, the main point here, don’t be afraid of picking up a new language. How many do you know already? If you’re a web developer, you probably already know Javascript, CSS, HTML, C# (or some back end language), a little SQL, and a healthy dash of XML. Picking up another one isn’t going to be too difficult.

Essence v. Ceremony

I first heard this from Neal Ford, possibly at eRubyCon a couple years back. But, Stuart Holloway had a great blog post about it prior to when I heard Neal speak.

To me (and many others), Ruby gets to the essence of what you’re after quickly. I find myself working within it’s idioms easily, not fighting them constantly with adapter patterns, dependency injection, and ORMs. I find that my tests flow naturally from the various testing tools I use in Ruby, and the code that makes those tests pass benefits from that.

So, to Bill’s point, maybe Ruby isn’t ready to have average devs write big, complex, “enterprise” systems in it. But, it is ready to support what you’re writing today. Right now. Why not give it a try?

Unless you’re afraid of learning…

3 Things To Help That Presentation Go Better

I recently gave two presentations at Codestock. One on Kanban that I’ve given a number of times and is well rehearsed, and another on IronRuby that I’d never presented before. I had given a similar talk, but a good bit of this one was new. Since I hadn’t practiced the IronRuby talk too many times, it didn’t go as well as I’d had hoped.

There’s the first sign I was going to have trouble, I hoped it would go well. The Kanban talk I knew would go well, not so much with the IronRuby talk. I had some time issues in preparing, had a number of other events I was was participating in, but none of that mattered to those people in the room with me in Knoxville while I did an under prepared presentation.

Here are three things you can do to save yourself the same fate I had in Knoxville.

1. Un-busy those slides!

Yeah, drop the bullet points, the animations, the cool stuff that PowerPoint or Keynote will let you do and just keep it simple. I mean, who’s telling this story? You or some software program that just needs you there to hit the “Next” button?

I was recently at a national/international level conference and a fairly well known speaker was giving a talk, but this person’s slides had all kinds of images and animations and bullet points. They had crammed so much info on each slide that a number of their headings were lost in the curtaining surrounding the screen. As an audience member I had a poor user experience, and I can’t recall the topic of the talk because I was so distracted by the horror that was on display in their slide deck.

Simplify. One image per slide is a technique I use often. Use that image to support what you’re talking about rather than BE what you’re talking about. Keep the animations low, one or two per slide is plenty. You don’t want to distract your audience, you want them listening to you.

The last point on un-busying your slides, I’m sure a few of you are thinking, “But when I upload my slide deck, nobody will know what the main points of the talk were.” That’s fine, put the supporting points to the slide in the speaker notes, then a downloader will have a good idea what you were talking about…in the presentation they should have attended. (Because you were that awesome!)

2. Practice, practice, practice!!

Give your presentation to the wall of your office a few times. Set up a few of your kid’s (or your own) stuffed animals and regale them with the wonders of TSQL. Give it to some colleagues in an informal lunch and learn. But, practice it a number of times. You want to be comfortable with the flow of the presentation and the points you want to make on each slide.

You can add speaker notes to help you through, and jog your brain on some points you’d like to make, but you want to practice enough that you’re comfortable to give a good talk without those notes. Because…

Let’s say – hypothetically – you own a MacBook Pro and an iPhone and you’re going to use the wonders of the Apple Corporation to help you give a presentation. You’re going to use the phone as your presentation remote and it’ll show you those bullet point, memory joggers mentioned above. And because it’s all Apple, all the time…IT’LL JUST WORK! But – again, hypothetically – something is wrong with the wireless network and for some reason the phone doesn’t want to connect to an ad hoc network on your laptop. What then? What of those memory joggers? The notes? Well, you will have practiced enough that this will barely even slow you down.

3. Practice those code samples

Yes, more practice. But with good reason.

Live coding can make or break you…it usually breaks me. I’ve bored enough people to tears with my live coding, that I rarely do it. I have some colleagues that are awesome at live coding demos. Somehow they’ve mastered the art of saying one thing and typing another. I don’t have that gift…just like I don’t have the gift of being able to hit a fastball, the gift 4.3 speed, or the gift a 103 MPH slap shot. But, I digress.

Practice those coding samples. I mean, as developers were in this to code anyway, just do the same code over and over so you can give the presentation without a hitch. I read a great line the other day, and though it applied to development in general, it definitely fits here: Novices will practice until they get it right, experts will practice until they never get it wrong. When it comes time to do a code sample in front of 40 developers, you’re going to want to be an expert.

That’s all there is to it

So, in review…

1. Keep it simple
2. Practice the presentation
3. Practice the code samples
4. And, um, have fun!

Yes, it’s a bit of work to put on a presentation. But when it comes time to deliver that presentation, the people watching you are giving up part of their day to spend with you. Respect those people and that hour of time of theirs that they’re giving to you.

IronRuby: Rake, Albacore, and you

In my post about setting up to run Cucumber with IronRuby, I included steps to install Rake and Albacore, but didn’t use them. In this post, we’ll put them to use.

Using Rake in .Net isn’t really a new idea, and a number of people have been using it for a while. I’ve used rake to compile and run the tests on all my .Net projects for at least the last year. Before Albacore came along to make my Rake tasks easier, I was copying the set-up from the folks at Fluent nHibernate. (FNH has used rake to build as far back as I can remember it existing and is now utilizing Albacore as well.) Now with IronRuby in the mix, rake is going to take on even more fun in your .Net projects.

For my example I’m again going to use my TestingSeaPound project, and specifically the rake file I’m using in that project. Pop it open real quick, and we’ll look through it.

At the top, you’ll see the standard Ruby require statements. In this file we’re including rake, the task library for RSpec, Cucumber, the task library for Cucumber, and Albacore.

Following the required libraries are a number of tasks that are combining the tasks that are defined later in the file. This is a way keep your rake file nice and dry. Define each task as needed, combine them in a call such as task :spec => [:msbuild, :rspec] to reuse them in different situations. From the command line in the directory where this rake file lives, if I enter rake spec it’s going to build the code then run RSpec

The only task in this list to take note of is the :default task. That’s the task that will run if you’re at the command prompt and just enter the command rake.

MSBuild

Skip down to the line that includes msbuild do |msb|. That’s our first task definition, and in this case we’re using the Albacore library. The top line of that task that includes the path_to_command is needed to build a .Net 4.0 project. I believe a fix is in the works, and may already be in place, but when I set up this file this was the way to call the .Net 4.0 compiler.

The next two lines, properties and targets, should look pretty familiar to anybody who has set up a .Net build in the past using MSBuild or Nant. Here we’re just saying what configuration we want to compile in, and what our target build is. Following that I’m setting the verbosity to quiet to keep the command line output fairly small.

The last line should be fairly obvious, it’s the path the solution file. Since MSBuild is very good at picking up a solution file and building it, why fight it? Pass the solution to MSBuild and let it do its thing.

nUnit

The next task down is our nUnit test runner. This is again an Albacore task, and it’s just pointing the test assemblies at the nUnit console app.

These two tasks are the only Albacore tasks in the file, so here’s as good a place as any to let you know the magic going on under the covers with Albacore. It is in essence building the correct command line arguments for MSBuild and nUnit and then shelling out to run them. Now, there’s more work going on than just that, but that’s the bulk of if. Albacore is giving us a nice DSL to write .Net build tasks. I’m only using two, there are a lot more available.

One important note: to this point our rake file hasn’t required IronRuby. You can use Albacore to build your project and run .Net based testing suites with MRI, IronRuby isn’t a requirement. I know as a .Netter that may seem odd, but we’re really not leveraging the Iron part of IronRuby.

Yet…

RSpec

The next two tasks are both RSpec tasks, and they’re running rspec against our .Net app. The first task is the default runner where it outputs a period for each passing test, the second will output the describe blocks and spec names.

NOW we need IronRuby. Not so much for the rake task, but because RSpec isn’t going to be able to test our dlls without the Iron added to our Ruby.

Cucumber

The final two tasks are Cucumber tasks. The first outputs the standard cucumber output, with each feature and specification output in their full glory – minus line numbers because I turned those off with the –-no-source option. The second task outputs the cucumber specs very much like nUnit and RSpec do, with a period for each passing test.

Once again we need IronRuby. Since I’m using the Ruby version of Cucumber in this case, we need to add the Iron to get it to reach into our dlls and do its magic.

That’s all for the tasks required to build and run the tests for this sample application. If you pull down the code and go to the root of the project and enter rake all at a command prompt, you’ll build it and run each suite of tests in order. Give it a try.

IronRuby at CONDG

Off the top, apologies for the rather dark color scheme. The slides I think I can change the contrast on a little and they’ll be fine, but I know better than to use a dark color scheme for my ide and/or text editor. I guess the editing of the config file in Rails was just all black, sorry about that. (On the config side, you didn’t miss much, though.)

HOWEVER! :)

I just uploaded a PDF of the slides and you can look at them in whatever color scheme really makes them pop! You can get it all here:

http://github.com/timwingfield/TestingSeaPound/tree/CONDG

Not a total cop out, please take a look at the code sample if you want to see the complete test classes from the examples - both the nUnit and RSpec ones. The rails app uploaded is the same one I created in the presentation, complete with the poorly named controller.

Again, sorry for the dark background in places, but thanks for coming out to watch.

(And big thanks to Kruger for making me remember how much I miss AutoHotKey after moving to the Mac. Windows devs, download AutoHotKey as soon as you read this.)