$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.

Advertisements

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

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