Week 4, Weekend

April 19, 2009 at 6:44 pm (Week 4) (, , , )

I got a lot of reading done over the weekend: finished up Clean Code by Robert Martin (with chapters by other Object Mentors as well), which I’d been working on for a couple months or so now. Great book; I highly recommend it. I ended up finishing it late Saturday night, and then felt a strong urge to do some coding. So I took a look through some open-source project I’d contributed to in the past, mostly just playing around, and finally ended up spending a few hours doing some bug fixes on the Rails app Eric and I are working on. Bug fixes are so much more satisfying when you write tests to accompany them. This way, you feel confident that you’re not going to see that bug again, and you also get a chance to go back into the code and refactor if needed. Refactoring wasn’t much needed in this case, but I looked!

And speaking of Refactoring, I started reading that book (by Martin Fowler) last night as well. I’d been putting it off since I felt better about my abilities “in the small” than with larger-scale design decisions, but the introduction makes me realize that small improvements are going to lead to larger design improvements over time, so I’m excited about that. I certainly have a lot of room for improvement and learning on a small scale as well!

After hearing Eric Smith and Corey Haines tweet back and forth a little bit about SICP, I had to investigate. Turns out “SICP” is Structure and Interpretation of Computer Programs, a computer science textbook using Scheme (a LISP dialect), which I’d looked into when I first started getting interested in programming but which went way over my head at the time. Inspired, I watched the first course lecture (by Hal Abelson) on Google Video, read the first section of SICP, and played around with Scheme on my laptop (re-learning Emacs navigation along the way).

I’ve learned a lot this weekend, and I’m looking forward to getting back into Java a bit this week, along with Rails and whatever else is in store!

Advertisements

Permalink Leave a Comment

Week 4, Friday

April 17, 2009 at 7:47 pm (Ruby, Week 4) (, , , )

Jake Scruggs and I started the day out by changing the feature I did yesterday so that emails would only be sent for 500 errors, not 404’s. This way people’s inboxes won’t be clogged with notifications when any old bot hits the wrong URL – or tries to hack it! It’s a good fix to begin with, but Jake also helped me to think through a refactoring that really cleaned things up. I was overriding the rescue_action_in_public method from the exception_notification plugin, and now that we needed it to act almost like the default, we had almost an exact copy of that method from the plugin. There’s an if-else statement that separates 404 errors from others, and the plugin, by default, calls its render_404 method and render_500 method, respectively. The obvious solution (well, obvious after the fact, anyway), was to instead override render_404 and render_500 to simply call our new method, render_error (which uses the Rails layout code to keep some consistency across the site). Much nicer, much cleaner. Thanks, Jake!

Eric and I finally got our continuous integration server up and running for the site, which was kind of an adventure. Note to self: use rake features, not cucumber features -n. CruiseControl.rb interprets the rake tasks better than command line output – or at least the setup is more intuitive that way. CruiseControl.rb, by the way, is pretty awesome: it’s a Rails app that monitors your Subversion repository and runs scripts of your choice, emailing build failures as desired. I can imagine a similar setup using Ant tasks for Java, and it looks like there’s a Cruise Control for that, too.

Eric and I started a small bug list as well, and knocked out several of those before we finished for the day (several styling things, and one or two things we didn’t consider when building stories). I’m definitely feeling much more comfortable in RSpec now: I wrote some helper tests after everyone else left for the day, and I knew exactly what I needed to do, in a strict TDD/BDD manner. I went pretty slowly, and because of my tests, and our already extensive unit and integration test suite, I’m pretty confident of the correctness of my implementation code (of course, I also checked manually to make sure I didn’t do anything stupid that I forgot to test). It’s nice not to feel overwhelmed by RSpec anymore. I still want to get the new RSpec book, but I’m feeling less and less that I absolutely MUST read it as I learn more on the job.

Permalink Leave a Comment

Week 4, Thursday

April 16, 2009 at 7:15 pm (Ruby, System Administration, Week 4) (, , , , )

Eric and I spent a good bit of time today trying to upgrade our app to Rails 2.3.2 (it’s currently 2.0.2), and we ran into several issues. One was that since we had Rails vendor’ed, our commit that upgraded the version caused our Subversion server some heartache on the commit side (but, strangely enough, not on the update side). Another was an error with the mysql gem that we solved on my machine and on another machine, but not on Eric’s machine, where we’ve been doing most of our work. Looong story short, we’ve reverted back to Rails 2.0.2 (which was a bit of a trial by itself), and next time we’ll most likely use Git and start right out using 2.3 (or higher!). <sarcasm>You have got to love debugging.</sarcasm>

I took a story, mostly alone, this afternoon and got it into a pretty good state, and meanwhile Eric worked on setting up a continuous integration server. I set up the exception_notification plugin and configured it for our project, which was pretty simple since I’d done it before. I just had to spend a bit of time figuring out how to get it under test (not the plugin itself, since that’s well-tested already: my implementation of it). I ended up getting some unit tests on the controller that I think are sufficient, but I don’t know how to get Cucumber cooperating yet for integration tests, so those are missing for now.

In case anyone else is struggling with how to write specs that test emails being sent when someone hits a bad url (like “/asgiuaguw”) in your application, here’s what I did (in a before block):


ActionMailer::Base.delivery_method = :test
ActionMailer::Base.perform_deliveries = true
ActionMailer::Base.deliveries = []
controller.use_rails_error_handling!

The first three lines just set up a fake mailing environment that you can query later with things like:

ActionMailer::Base.deliveries[0].to.should include("colin@8thlight.com")

Where ActionMailer::Base.deliveries[0] is a TMail::Mail object with all the information I can imagine you’d need to know about an email you’re sending.

The last line (controller.use_rails_error_handling!) ensures that RSpec isn’t going to rescue the exception for you (usually if there’s an exception during a test, the test fails with an error), and instead allows Rails to handle exceptions as it would during normal processing (with a rescue_action_in_public, for instance, as exception_notification uses). That way we can test that the behavior we want actually happens!

Permalink Leave a Comment

Week 4, Wednesday

April 15, 2009 at 7:10 pm (Ruby, Week 4)

I spent basically the whole day today doing some tri-pairing (ping-pong-pung?) with Eric Meyer and Jake Scruggs, who’s still here for the week on loan from Obtiva (yay Craftsman Swap!). It was really educational hearing their thought processes play out on this Rails app we’re working on. And with the structure we followed (make a test pass, then write a failing one), I really got a chance to improve my TDD. I can feel things getting more normal; by the end of the day I was needing less and less prompting to write specs when it came to be my turn. Implementations, of course, have been simple: the key is figuring out what to test.

I wonder if that’s true for experienced TDD’ers as well? Is writing the test where most of the hard thinking takes place (when you’re doing the driving), or do things work out more evenly once you’re familiar with the process?

We got a big chunk of work knocked out, which makes me feel good about our odds of meeting our target velocity this iteration. It seems like it’s very easy to have your velocity lowered from one week to the next (not meeting your target velocity), but I’m not sure how you’d increase the velocity – maybe by finishing stories early and then adding stories from a backlog?

At any rate, I feel like my RSpec familiarity is growing really fast, and I’m getting to a point where I feel like I’d be comfortable (albeit slow) doing a small Rails app TDD-style by myself, which would have sounded crazy two months ago. I may revisit a small Merb app I wrote earlier in the year and see if I can rewrite it (probably on Rails) using TDD. I’ll post here when I get going on it, of course.

Permalink 2 Comments

Week 4, Tuesday

April 14, 2009 at 5:54 pm (Java, Week 4) (, , , )

Back into Tic-Tac-Toe today, and things turned out much better than I’d hoped. Jake Scruggs of Obtiva is in the office as part of the 8th Light – Obtiva Craftsman Swap, and he helped me to think through some of my 3-D Tic-Tac-Toe woes. It was good to have another set of eyes on the code, and another voice of reason encouraging me to write my tests first.

As one of my speed strategies, to get this thing to actually run in a reasonable amount of time, I was working on putting board positions in a Hashtable, but we quickly realized that we’re not going to have enough memory for all the possible board positions. Because of the exponential growth of possible boards (with the number of positions), we’re looking at numbers in the trillions, and I was running out of memory around 600,000. So Jake had two insights that helped me focus on what really needed to be done: I could (1) make rules for my computer player that made him move properly for longer-term strategy, and (2) use a disk-based dictionary to cache the values of various board positions (like a flat text file or a full-fledged database). Before we could leap into coding up either of the solutions, however, Micah analyzed the situation and saw that I might be better off working on a 2-dimensional 4×4 board.

His reasoning was that since we had found a flaw in the 3x3x3 game (picking the center of the cube guarantees a win – try it!), it was only really good for learning, and I’d probably learn more with a slightly smaller problem anyway. So, I spent the rest of the afternoon coding up a 4×4 board, which was fairly easy now that I have abstracted the concept of a board away. Then I won some memory savings by having one reusable board (accompanied by a stack of moves that gets pushed and popped as I traverse the game tree), so now the only optimization I have left from Micah’s list is the biggie: caching board positions and scores. This one has me stumped right now, since the score will only be applicable on a per-player basis, but I’m sure a little away time will give me some focus when I come back to it.

I had a couple of people interested in seeing the source code, so I’m happy to direct people to the Git repository for my code. This should give you a good idea of where my Java knowledge is at the moment; I’m sure I’ll shudder about it a few years down the road!

I also got to meet Robert Martin (whose books I’ve read and blogged about) and James Grenning, who were in the office today to work with Doug on a Slim implementation (for Fitnesse). Exciting!

Permalink 2 Comments