Week one at 8th Light

When I first wrote my Tic-Tac-Toe application I tried to create working code and that was all. I didn't make any piece reusable, I didn't make my code flexible, I didn't write unit tests, and I didn't separate concerns. My computer player algorithm was brute force and worked only after too much prayer and cursing. If someone else were asked to work on the code without me being there they would probably first rip out their hair and then rewrite it. When I started, on my first day, my first task was to work with the code I had already written and I became nervous. I had to write unit tests for my working Tic-Tac-Toe. I wrote the JUnit tests in Eclipse and when Eclipse complained too much I switched to Intellij and found my new favorite Java IDE. After my tests passed it was time to re-factor.

This is when I did myself a favor and started over from scratch. I went through and implemented all the components of a Tic-Tac-Toe game (board, game rules, game logic, etc). I made a mistake in extending Board in Game for code reuse. Paul advised me to change this to a has-a relationship and went into SOL of the SOLID principles. Everything was going well and looked much cleaner.

This time around I also did strict TDD, which I had never done before. In school I typically write my code and then write tests to pass after the fact. This, I have learned, makes some people cringe. The reason my code was so clean was in part due to TDD and in part due to thinking about architecture more in depth before beginning. Regardless, clean and well written tests during TDD are invaluable to catching little bugs that blow up as the project grows.

Then it came time to make Tic-Tac-Toe players. I was told to write the Players in a way that I could drop in Players to square off, Human vs. AI, Human vs. Human, and AI vs. AI. Since I was coding this project in Java I just made a Player Interface to hold player number and return the x, y coordinates of their move when given the board state. I wrote an adapter for my brute force algorithm and a human player. I was able to drop them both in and have them play out Tic-Tac-Toe games. Then came the toughest part of the project, writing an AI player who picks their move based of a minimax implementation. This was a recursive mess when I first dove in. I developed my own TreeNode data structure (since Java Collections doesn't have trees) and tried to store each possible board state as a TreeNode. After getting essentially no where when doing this I decided to try again. Thankfully, Eric Meyer delivered a minimax lesson for all of the apprentices. Finally, I had a working AI player which used minimax.

During the second half of the week Doug introduced myself and two other apprentices to Fitnesse accepting testing framework. We're currently working through Java Fitnesse tutorials using Slim with the final goal being an Objective-C implementation. That's where I'm at now, at the end of the first week.