Refactoring to separate presentation from logic

June 10, 2009 at 5:41 pm (Ruby, Scala, Week 12) (, , , )

My plan today was to dig into my Swing code, get some tests wrapped around it, and eliminate the duplication that built up last night as I played around with styling. Company business intervened, so I spent most of the day on a project with Eric M. and Caleb working on translating a large set of data into YAML format (with occasional HTML where necessary). As we got started, I realized that my work was going to be extremely error-prone, tedious, and slow if I just copied and pasted things over, formatting as I went. So I hacked up a Ruby script to do the basic import to YAML, which I think saved a lot of time (and I feel much more comfortable with handing this to the client). We did still do a bit of manual work (every export we sampled from our word processing program had limitations), but it wasn’t too bad.

Eventually, I got back over to my Swing code and eliminated a lot of duplication. I’m working on extracting all view/presentation code away from the code that I need to test. I’m not, for instance, going to bother with a test to make sure that the background color is blue. Among other benefits, this will make it clear to me when I’m finished, as I go through and add tests. I read the chapter in Programming in Scala last night on pattern matching, and I’m seeing uses for it everywhere now. I’m going to be very careful to avoid switch statements where polymorphism is possible, but I’m starting to get more comfortable with Scala and find multiple solutions pretty quickly.

There’s been some talk recently on the JRuby mailing list about using Jemmy to write integration tests on Swing code, so I’m excited about its prospects as I delve into my GUI tests.

Permalink 1 Comment


June 1, 2009 at 9:50 pm (Scala, Week 11) (, , , )

After Caleb and I finished setting up a Slicehost account for a site we’d worked on, Micah met with me to talk about my apprenticeship challenges. I have three major projects to complete by the end of next week: a presentation at this coming Friday’s Lunch & Learn, an article on something I’d learned recently as part of my apprenticeship (more formal and expert-level than posts on this blog), and another version of Tic-Tac-Toe, this time in a language I’d never used before. After a bit of waffling on my part among Clojure, C++, Objective-C, and Scala, I finally settled on Scala.

I’d attended Dean Wampler’s excellent talk at this past weekend’s Chicago Code Camp, so I had some basic syntax knowledge coming in, and there are a lot of similarities to Java. But I thought I should spend some time getting a decent handle on the basics of the language before diving into Tic-Tac-Toe. I discovered what looks like the best test framework for Scala: ScalaTest. It’s pretty nifty, allowing several styles of testing, including one that looks suspiciously like RSpec. There’s also an IntelliJ plugin for Scala, which works well. Since I’m still getting the hang of all of IntelliJ’s features and options, it did take me awhile to get the IDE set up to run tests and write code, but by the end of the afternoon, I had my first failing test.

Things were pretty slow going since I was having to look up basic syntax at first, but I’m already seeing some really cool things in Scala. For one thing, I can mix functional and object-oriented ideas in the same program. It’s hard for me to think about things like a Board outside of an object-oriented space, which makes Scheme difficult for me (so far), but Scala deals with classes and objects without problems. My first implementation code (on the board class) looked basically like Java with a weird syntax and a fancy & functional map method:

def full: Boolean = { =>
     if(position == null)
       return false
   return true

And I thought this was pretty concise, so I was fairly proud. But I did some reading later this evening, and now I’m really psyched about the refactoring Scala allowed me to do:

def full: Boolean = {
  !positions.exists(_ == null)

This seems more like Ruby, but with a really beefed-up version of the Symbol#to_proc syntax that we get with Rails (1.1+) or Ruby 1.9. Nice, right?

Permalink 2 Comments

Slicing & dicing, and Chicago Code Camp!

May 31, 2009 at 1:55 pm (Ruby, Scheme, Watching, Week 10) (, , , , , , , )

Friday I spent the morning with Eric Meyer working on the same Rails app Jim and I had been working on last week. We got two bugs knocked out pretty quickly, and we also did some planning for a database refactoring (not as big of a deal as it sounds like, as the system isn’t in production yet). Eric’s laptop was having some boot problems, so we used mine; hopefully his Time Machine backup worked over the weekend – there aren’t many things more frustrating than not being able to boot. In the afternoon I chopped up a new website that should launch on Monday, showing Paul some tricks with the Slice tool in Photoshop along the way. I feel like I’m pretty efficient slicing up a PSD into XHTML/CSS – hopefully before too long I’ll feel that way in the code world!

Saturday was Chicago Code Camp, and it was awesome. The first session I went to was “Trends in Continuous Integration and Software Delivery” with Sean Blanton of OpenMake software. He went through the major features of a continuous integration system, and while we’ve got one in place for a couple of websites I work on (cc.rb), there was a lot of information there. I never realized how many different systems were out there. I was impressed with the fact that Sean wasn’t just pimping his products (Mojo and Meister) – it really seemed like a pretty fair assessment of the different systems. There were a couple of slides on Git, actually, which talked about how powerful it was, but that it might be hard for novices to get into. I thought that was odd at first, but as people asked questions I realized that Subversion and other systems have lots of GUI implementations that integrate tightly with OS’es, and Git doesn’t have so many yet. Maybe that’s a good project for someone…

Then I made the tough choice to miss Eric Smith and Eric Meyer’s talk on “TDD for the IPhone,” in order to attend Dean Wampler’s talk on “Better Ruby through Functional Programming.” Sorry, guys! I figured that since I’m working on a presentation involving functional programming, and I mostly use Ruby during work hours, I’d learn a lot there. And I did! I have a much better grasp of what functional programming is now, and how to apply that to Ruby (it can be done without too much hassle, actually). There was one particularly interesting point where Dean posited that we’d see programming (and concurrent programming in particular) become more functional on a small scale, but still object-oriented on a macro level.

Micah’s talk on Limelight (“Develop your Graphical User Interfaces (GUIs) faster than ever, with a thorough suite of unit tests to boot.”) was great, but it was tough because the 8th Lighters were the only Rubyists in the audience (I think), and there were only a few Agile/TDD practitioners. But there was a powerful point about what to do when something is hard to test: rewrite it so that it’s easy to test. And that’s just what Micah did with Limelight – which is indeed easy to test, once you know what you’re doing.

Next, I went to Dean’s other talk, “The Seductions of Scala,” and missed Jim’s “TDD and JavaScript” talk. Sorry, Jim! I had seen a version of Jim’s talk on Friday during the Lunch & Learn, and it was awesome. I’d of course heard about Scala because of the big Rails/Scala/Twitter debacle awhile back, so I was interested in what a language looks like that’s built with concurrency in mind. The language runs on the JVM, so like JRuby, it’s easy to interface with existing Java code. There is some strange-looking syntax to get used to, but it seems interesting, and it sounds like it’s gaining traction on production systems. I had thought the next language I took a look at would be Clojure, since it’s a Lisp dialect with concurrency in mind, and I’ve been studying Scheme, but now I’m thinking I may look into Scala. Or maybe learn JavaScript right. We’ll see. Incidentally, Dean’s new book, Programming Scala is available online in draft form as a preview – it looks great!

Micah’s last talk on “Ruby Kata and Sparring” was great. I’d seen forms of it before: the Langston’s Ant Kata and RubyConf 2008. There’s some kind of magical stuff in this version of the kata (instance_eval), but it’s extremely elegant once you understand the algorithm. I really like the notion of practice as important in software development; Paul was talking about this earlier in the day as well. I’m going to try to do the same kata 3 times a week for a few weeks and see if I see any benefits. I know from trumpet playing that even playing ridiculously easy exercises on a regular basis, with strict attention to form, can yield great benefits.

Permalink 2 Comments

REST, refactoring, and the best cheap sandwiches

May 27, 2009 at 7:19 pm (Ruby, Week 10) (, , , , , )

Today Jim and I finished up the second iteration of our client project on Rails (I had been under the impression that we were on iteration 1 until this morning’s stand-up). I coded a story on my own early in the day, along with some styling and validation work, and we paired to finish off another story (and do some refactoring) later in the day. It was a little hectic, and we ended up not quite finishing all of the stories for the iteration, but the good news is that we have well-tested, relatively clean code that will be easy to modify and refactor as changes become necessary.

I was excited to see that in Rails 2.3.2, overriding a RESTful route doesn’t seem to force you to manually override routes on a per-action basis when you want to add non-RESTful actions (through the use of the member and collection parameters to the routes file). Our growing understanding of the project is guiding us towards refactoring those actions to their own controllers (making them CRUD/RESTful along the way). We haven’t done that refactoring yet, but in the meantime, it’s nice that Rails is now doing what I had expected it to do in 2.2. I’m not sure where that change came along, but I like it!

There were a few times pairing with Jim where I would lose focus and find myself needing to take several steps back to remember what exactly we were wanting to test, but things are feeling pretty natural with BDD/RSpec on Rails. I ran into more issues with objects like template on my own when working on helper and view tests, but I’m getting more of an understanding – the more times I have to figure these things out, the quicker I’ll get at it.

We’re using Pivotal Tracker for this project, which is a pretty cool app for agile project management. Note cards are great, but an app like Pivotal Tracker essentially gives everyone their own copy of the cards online, which seems like a must for teams with remote members, and it’s very well-done.

Also, in a poll taken over lunch today, 100% of respondents* agree that Jimmy John’s is better than Subway.

* Sample set for this poll were selected from actual respondents by using only the very common last names Jones and Smith. This is a surefire statistical method that could never fail 😉

Permalink Leave a Comment

RSpec getting easier on new project

May 26, 2009 at 9:44 pm (Ruby, Week 10) (, , , )

I hopped on a new project today with Jim and Paul (both Erics are also on the project, but weren’t in the office today). It’s a Rails application, and I was making some changes and bug fixes. I ended up having lots of questions for both of the guys as I got acquainted with the application; some of those are going to go away as I learn the codebase. The end of the first iteration is tomorrow, so I’m trying to work quickly to patch up these bugs, but at the same time I’m keeping a high standard of quality. It was a little stressful, but that’s probably mostly because I had a little too much caffeine – nobody’s putting pressure on me to hurry up yet!

It was great taking responsibility for a small piece Rails code (test-driving it, of course) and improving it. As I’ve said before, I generally feel very comfortable working with Rails and HTML/CSS, so I appreciate the chance to give back to the team, even though the other guys are probably still faster on the Rails test-writing.

RSpec isn’t feeling foreign at all anymore. At this point, I think I have a decent intuition for when to mock, when to stub, and the general syntax, but my vocabulary needs much improvement. I spent some time with the RSpec documentation looking for matchers, but I didn’t always know where to look to find what I wanted (especially in view and controller tests). So I’m planning to bone up a bit on objects like response and template (looks like the RSpec wiki on GitHub is a great source of information).

Tonight Software Craftsmanship group meeting was awesome. Doug kicked things off by talking about a bit of the history behind the software craftsmanship manifesto, and his thoughts on gaining consensus and what makes someone an authority. The main takeaway, for me (in addition to the contextual history of the manifesto), was that apprenticeship is the path to finding your personal authority. When you’re an apprentice to someone, you’re making that person an authority in your field of apprenticeship.

Then Jake Scruggs and Jim talked about their experiences during the software craftsmanship swap (which they’ve also both blogged about). It was mostly a question-and-answer session, but both of the guys were really interesting and engaging speakers. I’m excited about the next swap; it seems to me that it’s energized both teams into improvement.

Permalink Leave a 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"
### 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

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

Crazy Java/Windows problem and some Scheming

May 12, 2009 at 8:34 pm (Java, Limelight, Ruby, Scheme, Week 8) (, , , , , )

As soon as I came in this morning, Micah asked for my help with a bug he’d been working on tracking down in some Java JNA code in the Limelight source. The gist of the code is that it was calling some native code in Windows DLLs, and about half the time, one of the API hooks didn’t get properly installed. We looked and looked, eventually doing some print statements looking for threading issues and other possibilities. Take a look at the code and see if you can spot the problem:

new Thread()
  public void run()
    W32API.HINSTANCE appInstance = Kernel32.INSTANCE.GetModuleHandle(null);
    final User32.HHOOK keystrokeHook = User32.INSTANCE.SetWindowsHookEx(User32.WH_KEYBOARD_LL, new KeyboardHandler(), appInstance, 0);
    hookThreadId = Kernel32.INSTANCE.GetCurrentThreadId();

Well, if you knew right away that the new KeyboardHandler() might sometimes get garbage collected before the Windows code gets around to calling it, then you’re lying. Just kidding! I am very impressed if so. Once we looked back on the problem, we could see how the problem might have happened, but it was really bizarre. The idea is that because we don’t hold onto a reference to the new KeyboardHandler() that we create, the garbage collector could think we’re all done with it, even though the Windows code really needs to hold onto it. We didn’t look in depth into how JNA translates the Java code into native Windows code, but Micah understands it, and I think he said it passes a function pointer to the Windows code in this case, so when Windows tries to callback to our Java code residing in that pointer, that code is no longer there. Wacky.

We also made an installer using install4j, which seemed really easy. I’m not sure how much setup Micah had already done, but we were able to drop in some custom icons and a splash screen really easily for our application, and it looks good on both Mac and Windows. I did my first work in Photoshop CS 3, and it was weird not so have the Save Optimized As.. option that I’m used to from Photoshop/ImageReady CS.

I spent some time this afternoon practicing recursion by writing methods to identify palindromes. I did it in Scheme, Ruby, and Java (in that order), all TDD, all in different editors. Of course, Ruby was the easiest and clearest by the end (negative array indexing helped out!), but Scheme wasn’t as hard as I’d expected. Things may be getting easier!

By the way, if anyone else is going through SICP and feeling like you need some more interesting assignments than reading the online book and watching the lectures, check out the sample programming assignments on the website. Even the first one (Exercise 11) might blow your mind if you’re like me and not so used to functional programming.

Here’s a taste:

(define foo6
  (lambda (x)
    (x (lambda (y) (y y))))

Give a Curried application of foo6 that evaluates to 3. Keep in mind this means that at some point you have to evaluate an expression which is a function applied to itself! Yikes. I’ll post my solution later, if anybody’s interested, but I don’t want to give it away too easily. I probably spent a good hour thinking this last one over, and learned to think in a different way in the process.

I need to find a new way of embedding code in this blog. Since it’s hosted on WordPress, I can’t include Javascript embeds of a Gist or Pastie, and I also don’t really have control over the styling. Any suggestions?

Permalink 1 Comment

Prime factors and the first client project

May 6, 2009 at 6:34 pm (Flex, Java, Limelight, Ruby, Scheme, Week 7) (, , , , , , )

I worked with Doug almost the whole day today, which was great. This morning when I came in, I happened to mention that last night, I’d done the prime factors kata, inspired by tweets from Doug and Caleb, but I used Scheme: the results are in a Gist. It was pretty frustrating trying to do this in a functional style, purposefully avoiding defining anything other than functions, but I sure learned how poorly I understood Scheme’s list-building constructs (cons, cdr, and car). I have a feeling there are clearer ways to do this, and I’ll definitely try again at some point to make it more fluid (I was completely stumped several times).

So, we spent some time in the morning working through the kata in C++, which was awesome. I hadn’t written any C++ since my only CS course in college, around 10 years ago, and what I wrote then was of course very simple. We used CPPUTest as our unit testing framework, but luckily, Doug already had the tests constructed, so we uncommented one at a time and concentrated on the implementation. I’d like to look into testing C++ a bit more at some point, but it may be awhile, considering all the other things I’m learning. We found several variations on the process of solving this problem, and the process of solving it became clearer, slowly but surely, as we worked through it several times. Then Doug said I should “perform” the kata for Caleb, which I did in Java (and in the process learned how much I rely on my IntelliJ Live Templates when I’m writing JUnit test code!) At some point I may try my hand at screencasting and record myself performing it, but I think I need a little more practice first!

Later on, after I struggled through setting up FlexUnit for the small AIR/Flex I’m building, Doug helped me get my bearings in the client project I’m working on now. We were writing Ruby, HTML, and JavaScript code most of the day, though Objective-C is also part of the project, and Flex/ActionScript may be eventually. It was awesome to be working on a bigger project and finding myself able to figure our what’s going on relatively quickly. My Limelight experience with Tic-Tac-Toe definitely paid off – if I hadn’t spent some time with that, there’s no way I would’ve known what was going on today. Of course, the technology itself wasn’t the sole aim of the Limelight Tic-Tac-Toe project – visual design was a big part of that, too.

At any rate, I’ll obviously have to be a bit more vague about project details now, but I’m excited to be getting into some client work, and I know I’m going to learn a lot from seeing Doug and Micah code on a regular basis.

Permalink 2 Comments

Next page »