Day 82

My tags are, I think, going to be things like the ticket numbers of what I was working on and the milestone it's for.

I'm a bit worried about ticket proliferation. When I made my latest milestone, I created a few tickets for it. These were some domain objects, and a few conditions and actions I wanted. It now seems that conditions and actions are dead easy to create and test. If I made a ticket for every possible condition and action in the game, I'd have a ton of them.

Thus far my strategy has been to only create tickets for things I need to remember to do but can't do right now, or things I'm not done fixing at the end of a session so I know where I left off. It's worked so far, but I worry about not knowing when I made a fix/change because it wasn't in the bug tracker. For instance, assigning the player missions was never in the tracker but I got it done today. Hopefully the blog will help with this.

As mentioned, today's work was assigning missions to the player. The mission object itself is capable of determining if the player can have it (by seeing if all its conditions are met), and also capable of giving itself to the player. I feel somewhat bad about having this sort of stuff (what more seasoned professionals might call 'business logic') in the model classes. While it makes it easier to unit test (by far!), I can't get the image out of my head of someone taking a picture of me doing it and adding the LOLCat style caption: "OOP: Ur doin it wrong".

Other stuff I wanted to mention:

I've got a spreadsheet which tells me, among other things, how long I've been working on this. I've decided to name the blog entries after the day. My entry as of today looks like:

Hours worked: 1.25
Goal for today: 1
Total Hours Worked: 132
Lines of Code: 7465 (as counted by CLOC)

If this was livejournal, I'd make my current mood the results of my unit tests. It's not, but today only I think I'll do so.

Current mood: 37 tests, 98 assertions, 0 failures, 0 errors