Dave's No Tests Challenge
I've mentioned before my difficulties in the 2014 IPSC. But taking one beating is no reason not to try again. The first loss just showed me that the contest still had more to teach me.
A buddy of mine has spent some time with the crossword problem and told me that he enjoyed it. I didn't try this problem during the actual event, but I was a little familiar with it from my friend's description.
To add to the fun, I decided this would be a great excuse to take up the recent challenge Dave Thomas gave to the Ruby Rogues: "Stop writing tests."
Step 1: Feedback Loops
Without tests to guide me, I really want to see what's going on. One of the biggest advantages of tests, in my opinion, is the feedback loop it provides. So I set out to provide my own feedback.
Since the problem at hand involves filling in a crossword board, the easiest feedback loop I could think of was to see the board as it fills in. The final board is also the required output. Therefor, I decided a good first step would just be to read the board into some data structure and write it back out. Once I had that, I could insert code between those steps to fill it in. And constantly seeing the board evolve would let me eyeball things for obvious mistakes.
The Definitive Guide to SQLite
I'm a huge fan of SQLite. Every time I do something with the little database it always manages to impress me in new ways. Here's a pop quiz for you:
- Did you know SQLite is totally free? I mean really free. All the code is in the public domain, protected by affidavits, and you can literally do anything you like with it.
- Did you know SQLite uses "manifest typing" which is similar to Ruby's dynamic typing? The database engine will really allow you to handle field types in whatever way is best for your needs. Of course, you can do type checking in triggers if you prefer to be more strict.
- Everyone knows SQLite shoves an entire database in one file, but did you know that it can work with more than one of those files at once? Yes, SQLite can query across multiple databases.
I could go on and on. Really, I could. SQLite is that cool.
It's almost silly to use flat files these days. If you find yourself needing one, you can load one gem instead, stick a full database in the file, take advantage of transactions and locking (very multiprocessing friendly), gain a full query language for working with the data, and have a prebuilt human interface completely separate from your code (the command-line tool is great for debugging). It's hard to beat that.