Fitnesse (the extra “e” is for “excellent”)

May 21, 2009 at 8:49 pm (Javascript, Ruby, Week 9) (, , , , )

Today was my introduction to Fitnesse. I’d heard Micah and Doug talking about it, and of course I’ve read about the acceptance testing framework before, but I hadn’t every really looked into the code or used it outside of a few minutes during my interview here. As a high-level testing tool, it reminds me a lot of Cucumber. Both frameworks have a good argument for being the most customer-friendly. Cucumber is written in plain English sentences, whereas Fitnesse has a more complicated syntax to learn. On the other hand, Fitnesse is hosted in a wiki, so the acceptance test author doesn’t need to worry about using Subversion, Git, or any other source control management system. What we call “steps” in Cucumber are “fixtures” in Fitnesse, which may seem a bit strange to people coming from Rails, where fixtures are sample data (also for use in tests). I’ll have to get in deeper to see more changes.

I need to go through Brett Schuchert’s Fitnesse Tutorials to learn which commands are built into RubySlim (the language that runs the backend of our tests) and which were created especially for this project. I was able to get a couple of tests written towards the end of the day (with lots of help from test that were already written, and confirmation from Micah), but I’d have a hard time writing my own from scratch.

Micah and I wrote some AJAX code with JQuery that that ends up doing something similar to what we’d use RJS for in Rails (we’re using Sinatra). It definitely took a little longer than RJS would have, but on the other hand, we were forced to think about exactly how we were interacting between the browser and server. I’d done just a small bit of this before, working on a typing trainer web app for programmers, but this time I felt much more comfortable (my informal functional programming study helped, I think).

I drove Caleb to the train station after work, and we talked about his Tic-Tac-Toe implementation (he’s working on minimax right now). He’s doing his in Java as well, and it sounds like things are going great. My impression is that he’s done a better job of test-driving his work than me, though I’m getting closer to making it a habit. It’s inspiring to be surrounded by a bunch of motivated people who are all working to get better!

Permalink 1 Comment

$0 in Ruby is worth more than you’d think!

May 20, 2009 at 10:51 pm (Ruby, Week 9) (, , , , )

I feel pretty good about my work today; we did a lot of refactoring and cleaning, and I was able to do a couple larger things on my own, which was good for my confidence. I got a better understanding of how the application works in edge cases, and we got some code under test (and made even more code more testable). We also cleaned up a lot of noise in the tests and process runs, moving it to log files rather than STDOUT. I was able to use a lot of code that Micah had just written, so that made my job significantly easier. Micah taught me a neat trick for differentiating between command-line file runs and simple requires in Ruby: $0, which is the name of the file run from the command line. Here’s what I’m talking about:

### file1.rb
if $0 == __FILE__
  puts "running file_1.rb from the command line"
end
### file2.rb
require "file1"

So, if I type this at the command line:
$ ruby file1.rb
I’ll see the output from the puts statement above, but not if I run
$ ruby file2.rb

Now, it might not look like much in the simple example above, but imagine if you have a script you want to run at the command line, but you also want to require it in other files in order to test the methods in the file. So you can eliminate the need to actually run the script during the test, simply by wrapping the actual run line in an if statement like the above. Pretty cool idea.

I was also able to give Jim a couple of tips on using Vlad the Deployer, the deployment love-child of Capistrano and the Rails Machine gem. Great stuff, but it could stand to have more examples in the documentation, so the second time around is much easier.

Permalink 8 Comments

The big dummy moment and first remote pairing

May 19, 2009 at 8:47 pm (Java, Javascript, Ruby, Week 9) (, , , , , , , , )

This morning I finished up most of a task from our biggest story, with some pointers from Micah. The big dummy moment came at the end of the morning, when I spent about an hour debugging why Javascript wasn’t working properly in our customized Webkit browser, and after going through everything I could think of, I realized that the browser had cached the Javascript file! Ack. So, my choices were to figure out where the cache was and clear it, or to do what Rails has always done for me behind the scenes to prevent caching: append a question mark and a big number to the filename. We’re using Sinatra, so I wrote a simple helper that does the latter:

def no_cache
"?#{Time.now.to_i}"
end

Pretty simple, but I’m not sure I like the way it looks tacked onto the end of the filename in the Erb templates; that may need to change to take a parameter…

I spent a little time in the afternoon working on a JRuby bug that the JRuby team posted on their Twitter feed. The problem was with Array#pack, which I’d never used before (and quite honestly, still don’t entirely understand). It takes a formatting string and packs an array into a string. There was a problem when the asterisk (*) was used in a format string like “A4N*” – it’s supposed to take all the rest of the parameters from the string, but it was taking too few. I tracked it down to a change in value of a local variable (listSize). It was hard to spot, because I wouldn’t have expected the list size to change, so I wasn’t looking for that. Lots of System.out.println’s and compiling ensued. It really gave me an appreciation for Ruby’s interpreted nature. I’m sure there’s a way I could’ve streamlined things, but it was taking me 30 seconds to build the project each time, which is an eternity when you’re just debugging and adding print statements (and especially if you’re not too sure of what you’re looking for).

Micah and I did some remote pairing in the late afternoon, which I’d never done. We used iChat, which was really pretty awesome. We had some problems with audio volume and crashy programs, but all in all, I think it was pretty successful. Micah came up with a new data structure to eliminate some network traffic in our application, and we implemented it, simplifying code and adding a feature along the way. This was code I hadn’t seen before, but it felt a bit easier to get around – partly because it’s just simpler, and (hopefully) partly because I’m getting better.

Permalink Leave a Comment

Programming parallels with trumpet playing

May 18, 2009 at 7:41 pm (Ruby, Week 9) (, , , , )

Throughout the day, Micah and I did some ping-pong TDD development in Ruby, getting a good bit of the way through the feature we’re working on. There are still some things to do on this, and I’m going to need to get quicker at changing contexts within the application. It’s not trivial – most Rails apps I’ve worked on have been basically CRUD applications, so this is definitely the most complex (and interesting) project I’ve worked on. The code is very clean, but there were some requirements that increased the complexity a good bit (involving AJAX where we might ordinarily use a simpler 2-way communication method). I’m sure things will get easier as I get more exposure to the project.

With a big project like this, I’m seeing a convincing parallel between my programming life and my trumpet-playing life. As a working trumpet player, I often needed to perform music that seemed too hard for me. In high-pressure situations like these, I just had find a way to make it happen. I would practice and do my best, and in the end I often just had to accept the fact that I couldn’t play it as well as I imagined it could be played by my favorite trumpeters. I feel kind of like that on this project – Micah is of course very comfortable on the project, partly because he’s been on it longer, but mostly because he’s a great programmer. The big plus here is that because we’re pairing most of the time, I don’t have to settle for a subpar performance. The aspects where my junior-ness really shows are the length of time it takes me to figure out how to write the next test or to make it pass, and the number of times I have to ask Micah for explanations and/or confirmation. The end result is still good code, Micah’s making sure of that; it’s just slower going for now.

Just like with trumpet playing, I know things are going to get easier as I get better. How do I make that happen? I’ve improved a lot since I arrived in Libertyville, so my plan is partly to continue on the path I’m on: listening, watching, practicing, and performing (just as I’d do with trumpet). As a trumpet player, there are 2 basic ways I get to the point where I can play a piece beautifully: practicing fundamental skills, and practicing parts of the difficult piece at a slower tempo or lower register. I have the luxury right now of being a little slow, but it needs to be faster. I’m not panicking or pushing myself to go faster than I’m able to do well, but I’m going to start digging into the parts of this project that are difficult for me, in order to get more comfortable, so that I can get faster at thinking through things.

Permalink Leave a Comment