Week 5, Friday

April 25, 2009 at 10:22 am (Java, Limelight, Ruby, Week 5) (, , , , , , )

I took the steps necessary to have no parameters in the constructor for my Tic-Tac-Toe view class, so that we could implement the interface in JRuby during our Randori session over lunch. I’d spent a little time thinking about what it would take, so it wasn’t too bad. I had three parameters initially: a Controller, a PlayerFactory, and a Board.

Well, the PlayerFactory was only really being used in one method, and all we really needed there was an array of Strings that showed the types of games that were available, like “Computer (X) vs. Human (O)”. So I changed that method to take an array of strings, and changed uses of that method to pass in information from the PlayerFactory (they were all in the Controller, so no new package dependencies resulted).

Also, since the Controller already had a reference to the same Board object as the View, I just added a getter called getBoard() on the Controller, and used that to set the Board on the View rather than the constructor.

The last thing was taking the controller out of the constructor. The View needs the Controller, for sure, so I added a setter on the View, which any class that instantiates a View would need to call right after creating it. I don’t much like this, since I had to change all my test class setups, and it’s more work for anyone wanting to implement a View, but I think it’s necessary to make the connection to Ruby code.

I also started with the Limelight props and styles being built already, so for the Randori, we focused on implementing the View interface in Ruby. We worked in IntelliJ, and there were a few tongue-in-cheek complaints about that (from Textmate fans). I definitely don’t know IntelliJ as well as I know Textmate or even Vim, but the big plus it has for me is the ease of refactoring, and the color-codification of things that are not going to compile or run properly. At any rate, we got a lot done. After a bit over an hour, with rotation of pairs every 5 minutes, we almost had a running Limelight application that used two computer players. I just had to change a couple lines right afterwards to get it to work as expected.

I have to say, I was initially skeptical when Micah told me we could use my Ruby version OR Java version of Tic-Tac-Toe to implement it in Limelight. I knew my Ruby version worked, but looking back, I knew its OO design was weak; I don’t think there was any kind of display class at all, so I’d have had to change a lot – I may still do that. But to use Java classes in Ruby code? That sounds crazy, but honestly, it wasn’t too bad. But I guess the person showing us how to do this has written a framework using Java and Ruby, so you’ll have to decide for yourself:

require '/Users/colin/IdeaProjects/TicTacToe/tttt.jar'
module Board
def scene_opened(e)
@view = new View(self)
Java::trptcolin.main.TicTacToe.newGame(@view)
end
end


class View
include Java::trptcolin.baseGame.View
# implement methods
#
#
end

Now, it may only be this easy because we’re doing it through Limelight, but either way, I think it’s pretty nifty.

I felt a lot less embarrassed about my abilities during this Randori than at the last one, where I was basically useless. This time I had a lot of domain knowledge to offer (since I wrote the Java code and the Limelight props), but more importantly, I had a better idea of what to test when I was at the keyboard. I still felt slower than everybody else, but at least this time I felt like we were more or less on the same page.

Advertisements

Permalink Leave a Comment

Week 1, Weekend

March 29, 2009 at 9:03 pm (Java, Week 1) (, , , )

I spent a lot of time this weekend trying to wrap my head around Java/Swing listeners and how to do TDD with this setup. Eventually I backed up a bit and dug into some more basic Java knowledge – reading from Learning Java by Patrick Niemeyer and Jonathan Knudsen. I just was a little overwhelmed with all I need to learn, and I wanted to focus things a bit more. And it turns out, after spending a good portion of the weekend looking at event listener code, I have a lot better grasp of it now. I was able to delete big chunks of my old GUI code and simplify some things. There are still LOTS of things I need to learn about testing this stuff; I think I might’ve painted myself into a corner with my console-based presenter, so that testing is difficult. Maybe there’s a way around it I’m not seeing, though. Basically, I have the core logic sending a request to a controller (for a move, the game type, or playing again), and the controller listening to the view layer for the answer. Right now there’s a lot of state-saving variables (boolean waitingForInput, stuff like that) that I know there has to be a way around.

At any rate, I’m going to spend some more time with the Java book over the coming week, so that I can get a better handle on things. I’ve been a bit spoiled in that I’ve worked with Ruby for the past couple of years, and have had all that time to absorb and read about the language. So much to learn! It’s so motivating when I come into work and literally everyone else knows so much more than I do (and are more disciplined). The advice that I’ve read from Chad Fowler (My Job Went to India) and many others to “Be the Worst” is really paying off.

I also realized that I never blogged about our Friday Lunch & Learn session – we had a Randori session, where we worked in five-minute pair programming sessions to build a small app. It was humbling to get back into Ruby, which I felt great about two weeks ago, and forget the syntax to set an instance variable in front of everybody (I was being Java-y). But it was excellent to see everybody in action and to hear people’s thought processes as we started the app, when the design was so sparse.

Permalink Leave a Comment