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

Jemmy in Scala and readying for deployment

June 11, 2009 at 10:08 pm (Scala, Week 12) (, , , )

I spent most of the morning working on integration tests to make sure I’ve got control of the Swing side of things. Jemmy is the library I’m using to drive these high-level tests. It’s great that I can now find some text on a button and click that element – it gives me a high level of confidence that I’m not going to break things when I go in and refactor things a bit later on. There were a few gotchas I ran across, so I thought I’d share those for anyone else trying to integrate Jemmy into a Scala project.

First of all, getting up and running was a bit of a trial. I knew I wanted to drive the tests with the same framework I’m using for the rest of my testing on this project: Scalatest (which is awesome, by the way – lots of choices for test syntax, though no mocking capabilities that I know of). There was some talk in the Jemmy docs online about writing a main function in your test class, which I wanted to avoid, and the only way I found to fire up the application was something like this:

new ClassReference("SwingTicTacToe").startApplication()
mainWindow = new JFrameOperator("Tic-Tac-Toe")

And, to end it:


The sleep was a workaround for what I believe to be a threading problem – I spent about an hour trying to figure out why my tests were not failing as they should have been if mainWindow was closed after they ran, only to find that there was apparently a timing issue going on when I added a println right before closing the window. The println took just long enough to give me the right behavior a little more than 50% of the time. All of this weirdness leads me to believe that there’s an easier way to do this. Eric Smith worked around it in a Java application he’s working on by using Mockito to mock out the application itself (sounds like he’s restricting Jemmy testing to his view), but I’m not sure how I’d do that in Scala.

Another problem I encountered was getting the tests running in an Ant task. I ended up with this:

<target name="test-integration" depends="clean, init, build.compile, test-integration.compile">
   <exec executable="scala">
     <arg line="-cp ${statemap.jar}:${scalatest.jar}:${jemmy.jar}:${build.dir}" />
     <arg line="org.scalatest.tools.Runner" />
     <arg line="-p ${build.dir}" />
     <arg line="-o" />

Of course, this is relying on some other definitions elsewhere in my build.xml file, but the problem I had was that I didn’t have a task like I would have with Java. Also, it’s important to note that all the arg tags have attributes name “line”. When I was following examples I saw in the Ant documentation, I saw lots of tags that looked like <arg value="..." />. This didn’t work in my case, apparently because “value” mangles strings with spaces somehow. Changing “value” to “line” did the trick immediately.

I also spent some time breaking my previously single-directory, default-package code into parallel test and source directories, with four packages: basegame, gui, console, and players. I still have some final code quality checks I want to do, but it’s very close. If I have time left over after passing through again for SOLID violations, I may work on some styling and learn about graphics objects and drawing in Swing (gradients, specifically).

Permalink Leave a 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 = {
   positions.map((position:String) =>
     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