The end of the beginning

June 15, 2009 at 11:21 pm (Scala) (, , , )

Today was the big day, when the craftsmen at 8th Light all got together to review my apprenticeship challenges (the presentation a couple Fridays ago, a more technical blog post I’ve written, and my Scala Tic-Tac-Toe. This morning I paired with Doug for a bit to work on a continuous build server for a client (CruiseControl.NET). It wasn’t a lot of fun: just some XML configuration and battling through ~3 layers of virtual Windows machines.

After lunch, the guys got together downstairs while I sweated it out with Caleb, Matt, and Andrew upstairs. Then each craftsman talked to me, one on one, giving me feedback on my challenges. I guess I did pretty well, judging from the feedback, but I did get a lot of great pointers, especially on presentations and writing. I tend to make bigger jumps than I should when explaining things, both in the written and spoken word. There were certainly other things (mostly positive, actually), but those are the things that I see as needing the most immediate attention.

But at the end of the day, Micah offered me a position as software craftsman at 8th Light, and of course I immediately accepted. I’m very excited to get started on client work tomorrow with Micah and Doug, on the project I’ve worked on a little bit during my apprenticeship. I’m going to be taking on more work and expected to contribute at least as much to the team as I take from it (my words, not theirs), and I’m going to rise to the challenge.

This morning, 8th Light and Obtiva had a big spread in the Chicago Tribune about the Craftsmanship Swap, starring Jim Suchy and Jake Scruggs. I got lucky the day the photographer was in the office, when I happened to be pairing with Jim on some Rails code, so I got my picture in the paper (and online.

The day’s last big hurrah was when I somehow finagled my way onto Github Rebase #23 for my tictactoe-scala project. It’s pretty sweet to be featured as a new project, but as I’m just getting into Scala, I wouldn’t take code I’ve written as gospel. Look to Dean Wampler for that.

This apprenticeship has been an amazing experience. I’ve written unbeatable Tic-Tac-Toe problems in Java and Scala, given a presentation on Scheme, learned test-driven development from the ground up and lots of object-oriented design patterns, touched on some functional programming, committed code to the JRuby project, and worked as part of an incredible team for twelve weeks. I shouldn’t ask for more, but I will. My formal apprenticeship may be at an end, but I’ve got a lot of learning left to do. I’m planning to take a short hiatus from blogging, but I’ll post my continued adventures in the near future.

Permalink 4 Comments

Tidying up Tic-Tac-Toe and some serious writing

June 12, 2009 at 4:53 pm (Scala, Week 12) (, , , , )

Today was packed! I started out by wrapping some more tests that I’d been wanting to write (clearing out TODO’s that had been hanging around). None of them were actually very hard, which was a welcome relief after struggling a bit yesterday with integration tests.

Then I drew some UML to analyze my code for SOLID problems (and package principle problems). Things were actually not as nasty as I had feared, but there were four or five violations that became immediately apparent. I had my Player factory in my basegame package, so there were some circular dependency problems between the basegame and players packages. I solved that pretty easily by moving the factory into the players package where it belonged. Another problem I had was with my Game class depending on a concrete Board implementation for a clear() method, which I got around by requiring my Boards to implement that clear() method.

After cleaning up these violations, I worked on refactoring my test code, some of which was not DRY at all (I learned kind of late in the game about Scalatests’s BeforeAndAfter trait). I also wrote a kind of neat trait that allows for easy Console redirection. I also went ahead and posted the code to GitHub: http://github.com/trptcolin/tictactoe-scala/tree/master. The trait I’m talking about is at test/unit/console/ConsoleRedirection.scala. Passing a function as a parameter makes this kind of thing easy – where you need to wrap a function in some other function calls.

For the time being, you’ll need Scala in your path to actually run the game. I may at some point turn this into an executable jarfile, but not tonight.

I also did a lot of work based on helpful feedback and suggestions from Micah, Caleb, and Eric S. on a more in-depth and technical blog post that’s my other remaining apprenticeship challenge. It’s a refactoring of a simple example to a more functional style in Scala, and it took a lot more reflection and thinking than I expected it to. It’s not that I expected to breeze through it, it’s more that I hit several points where I thought things were great, and then got feedback that made me take a few steps back, because the issues they raised were things I hadn’t even considered.

Today at Lunch & Learn we watched the Clojure Peepcode. It was pretty awesome, but there was a point maybe 3/4 of the way through where I should’ve taken a break, because I got a bit lost. I was definitely glad I’d had some experience with Scheme (Clojure, like Scheme, is a Lisp dialect) – that helped a lot at the beginning. There’s one feature of Clojure in particular that seems amazing to me. My understanding was that if you construct an expression where a symbol is used in place of a function, and a map is the argument to it, the expression will result in finding the value in the map whose key is the symbol at the start of the original expression. I’ll have to look into this further, and I’m not sure if there’s a practical reason for this, but it seems to me to be along the lines of Ruby’s 5.times {puts "hello world"}. Pretty cool stuff.

Permalink Leave a Comment

Scheme presentation and more fun with Scala/Swing

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

I gave my lunch & learn presentation on Scheme Friday, and it went pretty well. I found that I had forgotten to correct one of my slide mistakes, but aside from that I felt good about it. I went through the basics of Scheme/Lisp syntax and talked through some examples, and then finished up with the prime factors kata in Scheme. It went almost twice as long as I’d expected, since we stopped several times to discuss and answer questions. I took suggestions on the kata as well, which also slowed things down, but I felt like it was a better way to teach the process of refactoring to an inner recursive function (in place of what would be a loop in an imperative language). Everyone seemed interested and I got some great advice afterwards. The biggest things were that I didn’t always stand up (sometimes camping out in a chair) and that I kind of half-heartedly slapped a name on the presentation (“Scheme for Rubyists”) with only a few references to Ruby (where I could have had comparable Ruby examples for all my Scheme code).

Here are my [corrected] slides, if you want to get the basic gist (unfortunately, the formatting doesn’t translate perfectly to ppt file format – I used OpenOffice): Scheme Presentation

Friday afternoon and this weekend, I got a basic working version of Tic-Tac-Toe using Swing in Scala. I still have plenty to do: just as before, with Java Swing, I was basically spiking to learn the framework, and so there are some GUI tests missing. For now, I’ve put in TODO’s for implementation code I don’t have tests for; tomorrow I’ll start commenting out those pieces of code and driving them test-first. I feel good about my board and player classes; Friday I implemented some in-memory caching to speed up the computer player’s board-scoring computation. I still need to do some thinking about the technical article part of my apprenticeship challenges. I’m leaning towards something on functional programming, perhaps a few refactorings from imperative code to functional.

Permalink 2 Comments

State machines and scala.swing

June 4, 2009 at 10:49 pm (Scala, Scheme, Week 11) (, , , , )

After some morning refactoring on my Scala Tic-Tac-Toe (including moving my computer player’s minimax algorithm to a completely functional style) and speed tweaks, I moved on to thinking about how to integrate a GUI. Micah’s told me it’s not a requirement, but I’d like to have another crack at GUI development – I was very slow thinking things through in Java. Micah and I had talked yesterday about the possibility of a state machine to hold the game state so that my other application logic didn’t need to concern itself with whose turn it was. I have mixed feelings about it: on the one hand, state is what I’m trying to avoid in my functional programming study, but on the other, it’s apparently a very widely applicable design pattern that I ought to learn anyway.

At any rate, I spent the morning and most of the afternoon looking into SMC, the state machine compiler. Apparently there are numerous different ones (all named SMC) floating around on the internet. I believe all of them started with Uncle Bob‘s idea, and the one I’m using does give him credit on the website. It’s really like stepping into a second new language (DSL) writing state tables for the state machine compiler. I’m sure that the benefits will outweigh the time I needed to spend reading the documentation.

At the end of the workday, I fooled around with Scala’s Swing library (a wrapper for Java Swing). There are still some Javadocs I needed to dig into to understand what I was doing, but I was able to pick up the syntax pretty quickly. I have to say, Scala really does seem to be Java++. The Java libraries are still super-easy to grab, and the syntax is similar enough that it feels closer than it did with JRuby. The advantages I do see to Java are a familiar syntax and proliferation of tools, especially IDE support for refactoring – Scala’s IntelliJ plugin is good and has a few refactorings, but it has plenty of room for growth.

I spent some time tonight going back over my slides for tomorrow’s Lunch & Learn (“Scheme for Rubyists”), going through the presentation once for my wife and our dogs. I found a couple of outright mistakes and several extra points I needed to make, so it was good practice. I also went through a kata in Scheme that I’ll do tomorrow for the group if we have time. Wish me luck!

Permalink Leave a Comment

Hacking up a storm: Scala takes to the command line

June 3, 2009 at 10:22 pm (Scala, Scheme, Week 11) (, )

Today was a bit slow going, but I was in a pretty good state of mind, and Scala was feeling a little better. At some point something started to click a little bit on the micro level for functional programming, and I mentioned that I thought functional programming would make testing easier. But when I tried to explain it to Micah, I realized that the problems I had been having with testing in my normal imperative loop were more due to the fact that I hadn’t really thought out what I needed to test in that loop. In fact, my problems were cleared up pretty easily with mocks (hand-rolled — I’m not sure if there’s a mocking library for Scala or not).

Tonight I hacked out the minimax algorithm and have a working (albeit slow) computer player on the console. I got a little stuck a few times, but I remembered that the breakthrough last time (in Java) was to slooooow dowwwwn and make sure I understood precisely for WHOM I was calculating the score for a given board.

I did some Pomodoros when I got home: 25 minutes on, 5 minutes off. I ended up alternating between coding and reading this Programming in Scala book during my “on” sessions, but eventually I got so involved in the minimax problem that I forgot about the timer and just kept going (much to my wife’s chagrin).

I did a few rounds of Scheme code kata as well, in preparation for my Lunch & Learn talk on Friday. I’m realizing as I practice these more that there are a few more topics I need to introduce in the slides portion of the presentation in order to have the kata make sense; probably will get to that tomorrow.

Hooray for progress! Now I have lots of refactoring and GUI code to look forward to.

Permalink Leave a Comment

Language unfamiliarity and design decisions breed frustration

June 2, 2009 at 9:40 pm (Scala, Week 11) (, )

Today was all Scala, all the time. I came in thinking that I knew my stuff after my refactoring discoveries yesterday, but I quickly took a detour into Frustration-Land as I hacked away on Tic-Tac-Toe.

I struggled with some design decisions, as I wanted to do things from scratch and avoid too many parallels with my Java version. These problems I can’t really blame on my noob-ness with the language; I’m just trying to shift my paradigm to a more functional style. I don’t know yet if I’ll be implementing a GUI for my Scala version (apparently there’s a way I can hook into Swing), but I’m trying to think ahead, since I had lots of issues when moving my Java version from console to GUI. I’m debating whether to have my Player classes (driven by my Game class) waiting for input from my event listeners – I got the impression that this design (which I used in Java) was kind of unorthodox – or if I should instead have the application flow driven more by the events. I’m leaning in that direction, but need to do some more whiteboarding and reading. I did quite a bit of reading on and practice with the Actor model to see if I might be able to apply it to GUI event and game messages, but I’m concerned it might be an extra layer of complexity that’s unneeded.

My woes with Scala were basically due to me not knowing the libraries, and that will definitely come with time. I bought a book last night: Programming in Scala by Martin Odersky (the language creator), Lex Spoon, and Bill Venners. I’d checked out a bit of Dean Wampler and Alex Payne’s online book draft, which is great, but I just like having paper – I stare at the laptop enough during the day.

When I moaned that I had been a little frustrated today with my (lack of) progress on Tic-Tac-Toe, Micah pointed out tactfully that I had kind of jumped into things before really learning much of the language. It’s true – I felt like I needed to be constantly writing tests and typing code today, but what I should probably have done is take a step back and spend some time learning the language: reading, code kata, and typing examples from the book. I’ve spent some time tonight catching up on the language, and I’m going to continue some practicing now. There’s a lot to be said for applying a brand-new language (and paradigm) to a problem, but the less familiar the language, the more work I need to do before I feel comfortable in an actual project.

Permalink 1 Comment

Fitnesse (the extra “e” is for “excellent”)

May 21, 2009 at 8:49 pm (Javascript, Ruby, Week 9) (, , , , )

Today was my introduction to Fitnesse. I’d heard Micah and Doug talking about it, and of course I’ve read about the acceptance testing framework before, but I hadn’t every really looked into the code or used it outside of a few minutes during my interview here. As a high-level testing tool, it reminds me a lot of Cucumber. Both frameworks have a good argument for being the most customer-friendly. Cucumber is written in plain English sentences, whereas Fitnesse has a more complicated syntax to learn. On the other hand, Fitnesse is hosted in a wiki, so the acceptance test author doesn’t need to worry about using Subversion, Git, or any other source control management system. What we call “steps” in Cucumber are “fixtures” in Fitnesse, which may seem a bit strange to people coming from Rails, where fixtures are sample data (also for use in tests). I’ll have to get in deeper to see more changes.

I need to go through Brett Schuchert’s Fitnesse Tutorials to learn which commands are built into RubySlim (the language that runs the backend of our tests) and which were created especially for this project. I was able to get a couple of tests written towards the end of the day (with lots of help from test that were already written, and confirmation from Micah), but I’d have a hard time writing my own from scratch.

Micah and I wrote some AJAX code with JQuery that that ends up doing something similar to what we’d use RJS for in Rails (we’re using Sinatra). It definitely took a little longer than RJS would have, but on the other hand, we were forced to think about exactly how we were interacting between the browser and server. I’d done just a small bit of this before, working on a typing trainer web app for programmers, but this time I felt much more comfortable (my informal functional programming study helped, I think).

I drove Caleb to the train station after work, and we talked about his Tic-Tac-Toe implementation (he’s working on minimax right now). He’s doing his in Java as well, and it sounds like things are going great. My impression is that he’s done a better job of test-driving his work than me, though I’m getting closer to making it a habit. It’s inspiring to be surrounded by a bunch of motivated people who are all working to get better!

Permalink 1 Comment

Exploring Limelight

April 28, 2009 at 9:44 pm (Limelight, Ruby, Week 6) (, , , , , )

I spent the day continuing and accelerating my learning in the Limelight GUI framework. I’m sure I’ve mentioned before, but everything you write is Ruby code (there’s Java behind the scenes, so you run your applications with the JRuby interpreter and gems. Limelight is still very young (pre-1.0), and as with any framework, it takes time and advice to learn how the framework wants you to code. I ran across a couple of things that I felt would be more intuitive with a slightly different API (mostly styling-related), and Micah agreed and had me report them on the project’s Lighthouse page. There’s not a ton of tutorial documentation on Limelight so far, but here are the most important ones I know about already:

  • Installing Limelight
  • Calculator in 10 Minutes Screencast – Micah walks you through building a lightweight calculator application
  • Tutorial #1 – there’s a slight tweak you need to do to get it working this way, at least on the latest Limelight version
  • A Cook’s Tour of Limelight – great deeper-level overview of the parts of Limelight (Production, Props, Scenes, Players, Stages)
  • Style Attributes – similar to CSS style attributes, but with some awesome additions like built-in gradients and rounded corners (there are plans for drop shadows as well)

I’m sure as time goes by, there will be a lot more available, especially as JRuby gains in popularity. Keep your ears open!

I got the Tic-Tac-Toe game working with human players, which was a big step. There are still some kinks to be worked out with the “Play Again” process (I think my Java code is left waiting for input), but I’m excited to have it working, and to have spent the day getting better and more confident with BDD. Once I’ve patched those up, the real work will start on this assignment: styling it up, adding some effects, and in general just making it really presentable, with relation to the UI and design. I know my designer pals would be scared to hear about me designing anything, but I’d like to add some more design skill to the old bag of tricks, so I may be hitting them up for links to design blogs and other learning resources.

Permalink Leave a Comment

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.

Permalink Leave a Comment

Week 5, Wednesday

April 22, 2009 at 10:37 pm (Java, Week 5) (, , , , , , )

From yesterday morning to this afternoon I improved my understanding of the Hashtable a lot. Micah found a flaw in my hashing yesterday, but when I started to blog about it last night, I found I didn’t really understand my problem, so I held off until tonight.

I was doing this sort of thing:

private Board board;
private static Hashtable boardScores = new Hashtable();
// ... (calculating the score for a particular board position)
boardScores.put(board, calculatedBoardScore);

I had hashCode() and equals() defined on my Board class according to the squares filled on the board, but I wasn’t REALLY following the way that hashing works in Java (actually, in any language). My big flaw was in not realizing that while a given board position would always resolve to a given hashCode(), there’s no guarantee that it will be distinct from the hashCodes for other positions! So “XOX XOO X” (for a 3×3 board) might go in the same “bucket” as “OOXX OO X”, for all I know. Well, that’s not necessarily a problem when I store the positions in the Hashtable; the problem is getting them back out.

From Hashtable’s get() method:

if ((e.hash == hash) && e.key.equals(key)) {
return e.value;
}

And the key WAS a Board, which has equals() defined as having every square equal. So a hash lookup with Boards as keys really should work? No, actually! (This is where I got lost trying to work things out in my head last night) It’s true that the board is the key and 2 boards with different square configurations will not compare as true with equals(), but the keys are not really different boards. In fact, they were all references to the same board, which means that when if I get a hashCode() collision (which will most likely happen with the millions of boards that I’m hashing), there will be confusion, because the second part of the conditional in the Hashtable code above will always be true.

So anyway, Micah helped me to refactor to use new String objects as the Hashtable keys instead, which fixed the logic flaw, but took up even more memory and crashed the program at a lower depth search (running out of room in the heap). This all took place yesterday. Today I came in with the idea that I’d refactor things, write some more tests, and clean up some dependencies. I think I accomplished those goals, starting with a lot of refactoring (using IntelliJ’s built-in refactoring tools). I tried out a new-to-me tool called JDepend to check out problems with my packages, and I tracked down a few dependency cycles (that’s a BAD Java programmer. No dependency cycles. Nnnoo!). JDepend is an open source project by Mike Clark of Advanced Rails Recipes fame. It was pretty easy to use, and while class-level detail could’ve been nice, it was easy enough to do a “Find in Path” to track down the naughty dependencies. Here’s how it went:

  1. downloaded from Github (http://github.com/clarkware/jdepend)
  2. ran ant task to build it
  3. $ java jdepend.swingui.JDepend ~/IdeaProjects/TicTacToe/ (there’s also a textui and xmlui version)
  4. too many packages shown for me to process well, so I added jdepend.properties in home directory to ignore junit, hamcrest, java
  5. ran again, started doing searches for dependencies in my packages and breaking them where necessary to avoid the cycles

Now my package dependencies were as follows:

  • main => depends on baseGame, boards, players, and ui
  • ui => depends on baseGame, boards, and players
  • players => depends on baseGame and boards
  • boards => depends on baseGame
  • baseGame => no other project dependencies

Before my refactorings, every single one had a dependency cycle (icky).

And then we came to the afternoon, when I finally got fed up enough with the memory constraints of the Hashtable to open a JDBC connection and write the millions of positions and scores to a database. This was new to me, but the MySQL website was helpful enough that it wasn’t a big deal to do. One false start (only 8 levels deep), ~10 million database records, 16 levels deep, and ~6 hours of writes and indexing later, my computer player can play a 4×4 board more quickly, but in exactly the same way as he did at 6 levels deep with the (corrected) Hashtable. Which was not that badly, except at the opening. He makes smart moves to avoid a loss (on both sides) at the end, but at the beginning he thinks all the positions are equivalent. My impression in thinking as deeply as I can about this for a week or so is that on a 4×4 board, it is extremely easy to force a tie. So easy that a player would need to make at least two bad moves in order to lose. There’s no forcing a win after one misstep like on a 3×3 board. I think in order to get the computer to play like a human, I’d have to use an evaluation function that added value for 2-in-a-rows and 3-in-a-rows, which I’d have to do anyway in a more complicated game like chess, since there are so many more possibilities to consider there.

At any rate, Micah decreed that today was my last day on Java Tic-Tac-Toe, and so I’m moving on to Limelight tomorrow. Micah’s actually the author of Limelight; it’s a framework based on Java and JRuby that allows you to write rich GUI applications in Ruby. Pretty cool stuff; I’ve looked at some here and there since arriving in Illinois, and Eric and I looked at some this afternoon. I don’t know yet whether I’ll be doing some more Tic-Tac-Toe or something else, but I’m looking forward to digging into the new technology.

Whew, how’s that for an epic send-off for Java Tic-Tac-Toe? Apparently that’s what happens when you write 10 millions records to a database!

Permalink Leave a Comment

Next page »