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

Week 1, Friday

March 27, 2009 at 5:28 pm (Java, Week 1) (, , , , , )

I spent some time last night experimenting with Swing and was able to get the Tic-Tac-Toe grid set up, with some listeners on the squares. Then this morning I wired up the GUI to my existing Java Code. I only had to make one major change, which was getting rid of the Dependency Inversion Principle violation I had in my display code. I just turned that into an abstract class and moved the existing, console-based code into a subclass, and then also derived a GUI display class from the abstract class.

That part was simple, but I really did a lot of monkey-hacking today to get the GUI working properly together with the existing game code. I think part of the problem was that I never really stopped the “spiking” I did last night to learn how to use Swing a little bit. I just kept right on trucking (in implementation code, without tests) until I had a working game. So I need to go back and retrofit some tests to most of the code I’ve written today, which I’m sure will mean rewriting some things. My mom got me Michael Feathers’ Working Effectively With Legacy Code for my birthday, so I may dig into that some to give me some ideas. My understanding is that the book describes legacy code as any code not under test, so I wrote a bunch of legacy code today [frown].

On a brighter note, I’m going to be working with one of the craftsmen on an internal project, most likely using Rails, so at least I’ll be familiar with the language for this one. I’m glad I’ll have a compelling reason to learn RSpec, and probably Cucumber and Selenium as well. These are the kinds of things that motivated me to want to work at 8th Light in the first place. As I told one of the craftsmen when I interviewed, it seems like all of the big names in the Ruby world use TDD/BDD, so I really was looking forward to writing code that way.

I took my first crack at estimating (our initial iteration meeting for the project was today), and only time will tell if I was being too optimistic or not. I certainly don’t think we’ll have too little to do, but as I said in a previous post, I think I’ll get better at estimating as I do it more often and measure actual velocity (stories completed per iteration) against estimates.

Since it’s the end of my first week here, I’ll just close with a general thought on TDD: it isn’t faster to write your first few lines of code in a new project. But if you have tests for those lines, then you know they work. The tests allow you to forget about them, and still be able to change other parts of the eventual system without fear of breaking old stuff. Because it’s got a test suite that you run and see that of the system’s requirements that you have encoded in tests, you’re passing. I’m looking forward to making this a habit and really having TDD become my default coding behavior.

Permalink 6 Comments

Week 1, Thursday

March 26, 2009 at 7:05 pm (Java, Week 1) (, , , , , , , )

I FINALLY got my head wrapped around the minimax algorithm today. I went more slowly and stepped away more often, and I finally have an unbeatable computer in Java. This took me a heck of a lot longer than it did in Ruby, but I think it was reasonable considering my limited Java knowledge, a new algorithm, and new knowledge about things to avoid.

My last step was kind of an interesting one: I rewrote (not refactored) part of the algorithm in a way that was easy for me to understand, very slowly and deliberately, and it came out right! Imagine that…

// before:
bestScore = Math.max(bestScore, -minimax(child, depth - 1, otherPlayer);

// after:
otherPlayerScore = minimax(child, depth - 1, otherPlayer);
maxOtherPlayerScore = Math.max(otherPlayerScore, maxOtherPlayerScore);
bestScore = -maxOtherPlayerScore;

If you take a minute or two to look through this, you’ll see that the two versions are not equivalent. Although I could break the second version down into one line, I don’t trust myself to be able to understand it as well later on, so I’m leaving it explicitly spelled out this way.

I demoed the game for Micah and indeed, it seemed to work correctly. Micah had me draw up a UML diagram of the code in its current state, with all the methods and dependencies that I knew about, and Micah pointed out violations of the SOLID principles for object-oriented class design. I’d read about them but needed a refresher and deeper understanding, so he walked me through each of the principles, asking me what they were and where I saw problems. I didn’t catch them all of, course, but I was glad I at least had a cursory introduction already. I made sure that I understood the kinds of situations in which a principle violation would bite me.

For those unfamilar with these, you can learn more on Ward Cunningham’s wiki (he’s the inventor of the wiki, among other distinctions):

I just read about these for the first time a few months ago (they’re detailed in Agile Software Development: Principles, Practices, and Patterns by Robert C. Martin (Micah’s dad, incidentally). I had more Dependency Inversion violations than anything (though certainly not as many as my Ruby version had), but there were some Open-Closed problems as well.

My next step, which seems realistic for an Agile/XP project, is to put a GUI on top of my Java code. I haven’t done anything to speak of with Swing, so I spent a couple of hours this afternoon investigating the API and figuring out sizing, colors, and other things I’m going to need to draw the board.

I have an Open-Closed violation or two around my GameDisplay class, which means that my design is going to have to change around that point in order to substitute the GUI for my command-line output. The good news is that I HAVE a display class in the first place; my Ruby display code was coupled to the rest of the game in several places.

Permalink Leave a Comment

Week 1, Wednesday

March 25, 2009 at 8:03 pm (Java, Week 1) (, , , , , )

We worked from a client site today, where Jim and Eric S. generally work. They had an iteration meeting this morning, so I was there to observe. I’m told this one was really abnormal, as the new feature demo was only a few minutes long and it was around one computer rather than a conference room: one of the customers was on a tight schedule and had actually already signed off on some other stories from the iteration.

Each time Micah sits down with me and I try to explain my way through something, I realize how differently I need to approach my coding. Here’s the conversation that ends up happening (perhaps a bit paraphrased and exaggerated for my point):

Me: So, one of my tests is failing but the others are all passing. Here’s the code…
Micah: OK, so walk me through it.
Me: Well, this thing depends on that one and needs to call on it for later on when it updates the other thing. And before, when I was working on that first thing, I had a weird problem with the other thing so I changed the implementation of that first thing to be the new thing’s gobbledygookandtrailingoff… [you get the idea]
Micah: Wait. Go back to the beginning. Let’s think through each step.

I must slow down and be more methodical, especially when I’m having a problem. And even more especially when I’m having a problem understanding why I’m having the problem. The whiteboard was VERY helpful in solidifying my understanding of the minimax algorithm itself, especially as I applied terms from the implementation to it. Recursion can be really difficult for me to understand when I don’t go step by step (or call by call).

My ComputerPlayer is getting better: it wins when it can win immediately, but it gets much dumber after the first move. I actually thought it was finished at one point, but alas, my tests weren’t extensive enough and I was able to beat it easily. I banged my head against the wall (figuratively, of course) for awhile today trying to get it working – I think I needed to step away for awhile. Jim suggested 25 minutes of continuous coding/debugging, and then a 5-minute break (the Pomodoro technique). I’ll give that a shot tomorrow.

There was a lot of refactoring today. Some of it was to sanitize some nasty stuff I’d written, but some was out of necessity. For instance, I had the Board responsible for deciding the next move possibilities, but it should have been the Player, since the move itself depends on the player’s mark (X or O). This meant I had to bring a method or two up out of my Board class into the Player before I could move on with the algorithm. I also learned a couple more refactorings in IntelliJ that will save a lot of time: Introduce Variable and Extract Method. I had to spend a little time verifying for myself that the Extract Method change wasn’t going to break anything, so I need to crack the cover of the Martin Fowler Refactoring book sometime soon. It’s in my reading queue piling up from Amazon, but there are several others as well.

I spent a little time with Java generics and Lists in the morning – I’m used to Ruby where an array resizes for you automatically, so I figured that a new Java array, even one with space for 9 allocated, would have length 0, as it does in Ruby. But of course int[] possibleMoves = new int[9] is just an array of nine ZEROS. At any rate, I’m certain this is a much better way to learn a language than trying to learn all the syntax cold before hopping into the code, but it’s frustrating sometimes. I have a good friend living in Berlin who knew only a few phrases in German like “Where is the bathroom?” when he moved there a few years back, but of course he was fluent within a year or so. I imagine it’s similar here, except that I don’t have to speak in Java to buy a sandwich. Yet…

Permalink Leave a Comment

Week 1, Tuesday

March 24, 2009 at 8:05 pm (Java, Week 1) (, , , , , , )

Okay, so today was harder. I had a flurry of discoveries this morning as I got my questions answered from some work I did last night on the Tic-Tac-Toe game, and then I hit a big roadblock this afternoon. Lesson learned: interrupt when necessary and get questions answered rather than stalling on my own if I’m really stuck.

My problem this afternoon was the Minimax algorithm. I’d looked at it briefly before, after I had finished the Ruby version of the game, but didn’t understand it and gave up. Since the algorithm is part of this assignment, I buckled down and read several descriptions of the algorithm that I found on Google. I thought I understood the mechanics of the algorithm, decision tree and all, but two things were eluding me: the implementation of the decision tree and the computation of the value of a given board position. Eventually I got close (basically translating the pseudocode to Java and Tic-Tac-Toe), but I really did need Micah to help me think through my implementation line by line in order to see a big mistake I was making with recursion. It’s not there yet, but I think it’s close.

Which leads me to the other (maybe bigger) afternoon problem: in my efforts to understand and implement the algorithm, I had neglected TDD and avoided writing tests. Because it was hard => because I’m not good enough at it yet. Well, Micah’s given me some ideas to begin with: sending in board positions where there is a definite best move, and testing that the algorithm spits out the right one, along with some other lower-level things. He did say it’s hard to test, so that makes me feel a little better, but I have to get to the point where I’m not intimidated by TDD. I caught myself jumping ahead to the implementation several times today (and once in front of Micah IN THE TEST CODE – whoops!).

On to the more complete wins of the day, from the morning: I came in with a couple of questions about how to test specific points in the project. Let’s say I have Game, Player, and Board classes. Now, I needed to test that when I told a Player to make a move, the Player would pick a move, and then populate the Board with that move. I was struggling to find a way to verify that the Player had told the Board to populate. It turned out that I just needed a mock Board object. I had an inkling that this is something mocks would be good for, because I remembered a bit of RSpec (ONLY a bit) where an object might have “should_receive(:populate)” to do something similar. I was really glad to come across this problem, because nearly every time I’d read about mocks and stubs in the past I’d come away feeling dumb and defeated. This was simple, though: I just derived a MockBoard class from Board, added a field on the class (private boolean populateCalled = false;), and overrode the populate() method, setting populateCalled = true inside it (and calling super.populate() when I needed the real behavior later).

I’m still incredibly slow in IntelliJ, so I was happy to pick up a few IDEAs about it today. Get it? Get it? I know, I’m incorrigible… Shift-F6 is the Rename refactoring. Wow, is that going to save a lot of time! I think you have to be hovering on the declaration, but the program goes through and changes the name of that method/field/variable/class, in a pretty smart way.

The biggest IntelliJ thing I’m excited to know about is Live Templates, which right now seems exactly like TextMate snippets. Micah wrote me a quick one that does the skeleton of a JUnit test on a tab-complete of “test”, and I can see how this is going to come in handy. I always liked scripting up and using snippets to blast out often-used ERB template things for Rails, and I’m definitely going to start paying more attention to the things that I end up typing over and over so that I can give those to IntelliJ to do.

Permalink 3 Comments

Week 1, Monday

March 23, 2009 at 7:07 pm (Java, Week 1) (, , , , , , )

Alright, first real day of work in the books. I started off with the normal things, getting email and other account access stuff set up, and then Micah had me install IntelliJ and JUnit. Java, I knew it! Though Micah has assured me that won’t be the only language I work in: I’m betting on C++ as well, maybe some Objective-C too?

At any rate, my first assignment is to re-implement Tic-Tac-Toe in Java. And boy oh boy, this is a lot slower going than when I wrote it in Ruby.

First of all, I know Java only a little better than I know C. Which is not well. More on that later.

Secondly, I’ve read and learned so many things about object-oriented design principles recently that I’ve spent a lot more time trying to avoid a crazy dependency structure like my Ruby version had. That’s a good thing; once I learn to do these things right it’s going to be possible for me to write clean, maintainable code. I spent a bit of time mapping out what I thought would be a decent design, and then Micah helped me with some UML concepts at the whiteboard. I got a little bit better idea of how class diagrams work (public vs. private variables, dependencies vs. inheritance, abstract classes), and I started to understand dynamic diagrams a little better as well. I’d seen these in the PPP book (Agile Development: Principles, Practices, and Patterns) but I really just used context clues to get an idea of what I was looking at there. I checked out a book on UML from the local library; hopefully I can catch up a bit with that as well.

I’m learning a lot of Java. Most of my previous knowledge was from a kind of hand-holding online course where you mainly just had to fill in the blanks to complete the programming exercises. Sure, I read a lot of articles and some API docs, but it didn’t really stick, I guess. So I’m going to have a lot of “DOH!” moments along the way. A big one today was that to initialize an array in one line, you have to use curly braces:

char[] letters = { 'A', 'B', 'C' };

Yes, I was using square brackets and couldn’t for the life of me figure that one out (though to my credit, I finally found that problem without having to ask). Without going into all of my mistakes, we’ll just say that abstract classes and methods, and parsing user input (and especially testing that!) were also problematic for me. “Doh!” say I; “Duh!” say the Java people. Well, it’s new to me; I’ll learn.

I also got to sit in on an IPM (Iteration Planning Meeting, NOT Integrated Pest Management, as Google would’ve had me believe) for Fresnel, an open-source Limelight application, and learned a bit about the estimating process. Just like I’m reading about in Extreme Programming Explained, these guys estimate units of work (stories) with story points, which don’t really stand for a specific time period. The team has measured its velocity (number of story points from the last iteration), and it assumes it can get the same number of story points done in the next iteration. If the points completed go up or down from the previous week, the velocity has changed, so next time the team takes on fewer or more story points to match the previous iteration. The team comes to a consensus (unanimous in the case of the small team I was observing), based on discussion, about how many points each story is worth. I like the idea of measuring progress and adapting on an iteration (2-week) basis – it seems like over time you’d get really good at estimating, which is definitely a skill I need to work on.

Permalink Leave a Comment