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: 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="" />
     <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

Refactoring to separate presentation from logic

June 10, 2009 at 5:41 pm (Ruby, Scala, Week 12) (, , , )

My plan today was to dig into my Swing code, get some tests wrapped around it, and eliminate the duplication that built up last night as I played around with styling. Company business intervened, so I spent most of the day on a project with Eric M. and Caleb working on translating a large set of data into YAML format (with occasional HTML where necessary). As we got started, I realized that my work was going to be extremely error-prone, tedious, and slow if I just copied and pasted things over, formatting as I went. So I hacked up a Ruby script to do the basic import to YAML, which I think saved a lot of time (and I feel much more comfortable with handing this to the client). We did still do a bit of manual work (every export we sampled from our word processing program had limitations), but it wasn’t too bad.

Eventually, I got back over to my Swing code and eliminated a lot of duplication. I’m working on extracting all view/presentation code away from the code that I need to test. I’m not, for instance, going to bother with a test to make sure that the background color is blue. Among other benefits, this will make it clear to me when I’m finished, as I go through and add tests. I read the chapter in Programming in Scala last night on pattern matching, and I’m seeing uses for it everywhere now. I’m going to be very careful to avoid switch statements where polymorphism is possible, but I’m starting to get more comfortable with Scala and find multiple solutions pretty quickly.

There’s been some talk recently on the JRuby mailing list about using Jemmy to write integration tests on Swing code, so I’m excited about its prospects as I delve into my GUI tests.

Permalink 1 Comment

Constant improvement does not require judgmental reflection

June 9, 2009 at 6:49 pm (Scala, Week 12) (, , , , )

I spent much of the morning wrapping tests around the state machine code I’d written last week and over the weekend. Obviously, this isn’t the ideal way to write tests. I want to be a programmer who does TDD all the time, but I wasn’t that programmer on parts of this project. In the sections of the application where I’d done similar things before (the board and the players, for instance), I had no problem incrementally describing the functionality in specs and implementing it. But as I wrote my first state machine code and experimented with a new interface to Swing, I found myself implementing more and testing less.

As I gain experience and learn from colleagues through pair programming, I imagine that my discipline and abilities with regard to TDD will continue to improve as they have in the past few months. In the time being, I’m proud of the amount of code I’ve been able to delete as I write tests and discover the functionality that is really necessary. There is plenty left to do, but my Scala code is much simpler and easier to modify than the Java version of Tic-Tac-Toe, even though the language is still pretty unfamiliar, and the documentation sparser than Java’s.

I was complaining to Doug late this afternoon about the variations in GUI frameworks that make it difficult to get started in a new one, and I realized that what I really want is to know Swing and Limelight as well as I know XHTML/CSS. Again, I think this is a case of frustration based on lack of experience: once I have years of day-to-day Swing experience under my belt, that will feel great, too. I’m slowly learning to reflect on my coding in a less judgmental way. Bruce Eckel’s recent blog post, “A Career in Computing”, advises “There is no right answer … and always a better way. Show and discuss your code, without emotional attachment. You are not your code.” This gels with my experience in music, where I find it very easy to beat myself up mentally for mistakes that I’m not yet skilled enough to avoid. My goal here is not to feel good about bad code, it’s to learn from my mistakes and engrain a healthy state of mind when coding. If I’m frustrated when coding, I’m teaching myself (unconsiously, of course) that it’s the correct way to feel when coding, and inevitably I’m going to make less progress.

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


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 = { =>
     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

Next page »