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

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

Using Javascript to order the client around

May 17, 2009 at 10:00 pm (Java, Javascript, Ruby, Week 8) (, , , , , , )

Micah and I spent most of Friday working on a lightweight messaging system that’s going to allow us to push messages from server to client, even though the client is basically a web browser. Since HTTP is basically stateless, we’re doing it with AJAX requests (Javascript, with some help from JQuery). And in order to keep it really simple and flexible on the client side, we’re developing something like a message queue on the server, which builds up Javascript for the client to execute whenever it’s ready (this way the server keeps track of time-sensitive issues, and the client doesn’t really have to hammer the server to stay updated). It’s a pretty cool idea that Micah had; he likens it to us putting food on a plate (at the server), and when the client’s hungry, he comes along and takes the food that’s there and eats it (executes it in the browser). We’re using the command pattern to fill up the plate of Javascript.

The lunch & learn was a bit more technical this week (after last week’s great Star Trek excursion), but still great fun. Doug presented a prepared code kata: TDD factorials in C++. I had already seen a little of CppUTest from pairing with Doug earlier in the month, but he went a little more in depth explaining the syntax, which we had just kind of touched on before. He’s teaching a TDD class this week, which I’m sure will be awesome for anyone lucky enough to attend.

Eric Meyer presented the development of a story using acceptance test driven development (ATDD) with Cucumber. He and I had worked with it a good bit while developing our Rails app (which by the way has been live for awhile now): a job board for software craftsmen, so I knew the syntax and structure already. Eric used a great technique to get the story done quickly and correctly while doing a good bit of live coding as well: git tags. He had about 8 steps to the development of the story that he had practiced, and each one was tagged, so that he was free to code in a normal way and know that we could fast-forward to the next step at any point. I’d like to learn more about version control (both Subversion and Git), but it’ll just have to go in the bucket of stuff to learn with everything else!

In less technical news, I finally got a Cubs hat. Look out Chicago, now you might have to hear me say “Y’all” before you know I’m not from around here.

Permalink Leave a Comment