git pre-commit hook and hspec

While working on some hspec stuff, I decided to try out git's pre-commit hook and see if I can make it refuse to commit unless the unit tests pass. It was easy. Here's what I came up with:

#!/bin/sh
echo "Running specs.hs"
exec runhaskell hspec.hs --format=progress --specs specs.hs


Where specs.hs are the file with the specs for the hspec library and the --specs option tells the hspec executable to run it's own specs.

On my Mac I need to make the hook executable by running chmod +x .git/hooks/pre-commit

Some roguelike ideas

I've always got a few ideas for roguelikes in my mind so I figured I should write some down before I forget.

Allied chat. Instead of having some command list, telling allies what to do would involve typing out a command like you're talking to another player. If NPC's understand a few verbs (attack, go to, defend, follow, help, get, etc.), adjectives (fire, nearby, weak), and nouns (me, the skeleton, a sword, etc.) then you could give simple commands to specific allies, or whoever is in earshot of you.

• follow me
• Mr Wizzard: defend the temple
• get better armor
• give me your weapon
• priests: help the king
• use frost weapons on fire imps

Allies could be made even smarter by having default ones or keeping a history of certain commands and the most recent ones take precedence. So if you tell your allies "defend villagers" then "attack archers", they will attack archers if there are any visible, otherwise they will defend any visible villagers. Or that may be more frustration than it's worth; I don't know.

Random monsters. Each game has several species of monsters that have random attributes for each game. Identifying what their strengths and weaknesses are is part of the fun, just like with potions and scrolls. So in one game Forest Monsters can fly, are immune to poison, and have strong armor; in the next game they leave poisoned corpses, regenerate quickly, and can summon insect swarms. Imagine if none of the random monsters leave corpses or if they're all resistant to magic.

Nomic. A nomic is a type of game that is played by changing the rules of the game. I've seen some very strange things happen so it would need to be limited and simplified for a computer game. Imagine if a roguelike let you vote on new rules from time to time. Maybe you could make using magic a crime, grant money to players for each rat they kill, create a fee for those who want to use large weapons, or even crown yourself emperor. Influencing the other voters could become a game in itself.

ANNOUNCING www.LatinLiteracy.com

Using the Java Play Framework and hosting on www.playapps.net was so easy that I went ahead and bought my own domain: www.LatinLiteracy.com.

It's just a small start for now, but as I learn more Latin I will continue to add to it. I hope that, in time, it will help me and others learn to read and write Latin.

Play framework

I took a look at the Play Framework for java web apps and while poking around and trying this and that, I ended up implementing most of my Latin app. I wasn't really trying to, I was just testing how to do certain things and before I knew it, I had a working web app. So far, it's been really easy to work with and really fun.

No longer fit

I recently added long vowels to my latin project. When spoken, long vowels are held a little longer than regular ones and are indicated by putting a little bar, called a macron, above the vowel: ā, ē, ī, ō, or ū. Java can handle these unicode characters if you specify "-encoding utf8" when compiling but apparently fit can not; so any fit tests that were comparing strings that had macrons were failing. I tried changing my code to convert long vowels into regular vowels when comparing but that was messy and didn't always work right since long and regular vowels are different phonemes. Eventually I decided to do away with fit and switch to JUnit. I lost at least two programming sessions to fiddling with fit, working around fit's limits, and finally reimplementing the tests in JUnit.

So even though I was really looking forward to using fit and I think it could solve many problems I've seen with the *Unit frameworks, for me, at least this time, the costs of using fit vastly outweighed the supposed benefits.

Finally fit

I'm finally using Fit. I've been interested in it for a long while but I've never had a side project where I really though it would be useful, until lately.

One of my new years resolutions is to learn Latin. And, as usual, while learning that I began thinking about ways to apply it to programming such as an Android app to help someone learn and review Latin. Latin is like everything else invented by people: it's got complicated rules with many exceptions and special cases; perfect fit for TTD and Fit in particular.

I don't have tests around the android specific stuff like moving between actions and handling the gui and persistence, just around conjugating, declining, and translating Latin. Although it's been very helpful it has slowed large scaled refactoring. As I learn more about Latin I have to make major changes to how words and phrases are implemented and then I have to rewrite all the tests so they pass.

It feels helpful but I'll have to wait and see if maintaining all these tests really is worth the extra time and effort.

Does work encourage bad habits?

"these virtues are formed in man by his doing the actions" -- Aristotle, Nicomachean Ethics

Sometimes I wonder about programming as a job. Does having to add new functionality as fast as possible change how I act when programming for fun? Does having to follow the patterns and decisions others have laid out before me close my mind to better ideas when I'm working on my own projects? At home, I can polish a rough working prototype into something works well and that I'm proud of. At work, I often struggle with what's already there to do even the simplest things and I rarely want others to know I had a hand in the final result.

I'm able to use TTD, BDD, constructor injection, profiling, and all kinds of other techniques on my side projects but for some reason, trying those things at work brings only frustration. They don't work with the frameworks we use, the processes we use, other people don't like them, we don't have time to do it that way, or I'd have to rewrite large sections of code just to get it to work. I work with a lot of smart people and, over the last 6 or 7 years, they've created a product that deals with an amazing amount of externally imposed complexity, but the best advice of the best developers rarely helps. My best attempts almost always fall far short and if statements and hard coding rule the day; I consider it a good day if I'm able to use polymorphism instead of scattered if statements.

One small example: I recently noticed my git commits are too large and include too many changes - just like at work. It's like that at work because of the source control tool and our processes for dealing with it encourage few large commits rather than many small ones. It's very frustrating to try and determine what changed in a file, finding that 60 lines changed, then finding that 50 of those lines were just formatting, and the other 10 lines were for several different reasons. Small and focused commits can prevent this, but if you're not in the habit of doing that, then you forget about it even when you have the chance to. I'm beginning to wonder how much of what I do is due to habits that serve me well enough at work but that I don't want to carry into my personal projects.