Quite often in online forums, there will be an exchange something like this:

Over time, large systems come to resemble human civilizations that have evolved over centuries or millennia. Cities are built upon the remains of older cities; cultural norms are handed down from generation to generation; revolutions come and go; architectural styles and tastes change; modernization happens.

Yesterday, I had the pleasure of speaking at Mountain West Ruby Conference again. I spoke about writing a solver program for the Ricochet Robots board game described in this earlier post.

For my conference talks last year, I used Showoff which I really like. I can edit my slides in Markdown and it is really easy to include source code that is automatically syntax-highlighted.

I’m excited to announce that I’ll be speaking at my first ever RailsConf in April. I’ll be leading a workshop session, Getting a Handle on Legacy Code, where everyone can get hands-on experience working with some legacy code. We’ll put test coverage in place and then use baby-step refactoring to get the code into shape, all without doing a big rewrite.

My family and I enjoy playing board games. In the last few years, we’ve been introduced to several new games that have unique game play aspects.

As I’ve started doing more JavaScript programming, I’ve been looking at different libraries and frameworks for the language.

In my last post I talked about some handy Jasmine matchers. Within hours after publishing that post, I discovered another interesting use for the matchers.

I’m super excited to announce that I’ll be speaking at Mountain West Ruby Conference again this year. I’ll be presenting “Solving Ricochet Robots”, a talk about how to build a program to solve a puzzle game. I’ll explore graph search algorithms, data representation, heuristics, pruning, and optimization using a fun vehicle. I plan to bring my copy of the game to play in the hallway track with anyone who’s interested.

I have a number of rules of thumb that I use when doing TDD. One of them is to test only the essential aspects of the code I’m writing. I want to make sure that the key parts of my code work the way I want without over-constraining the rest. That way, my tests stay robust and don’t break as often when unrelated code changes.