|
|
It's Official
I suck.
I'm 47 hours into work so far, and probably going to hit 55 this week. Suddenly, these past weeks, I've been totally swamped. Not a little, but completely. So, alas, the controller isn't going to get done.
Oddly enough, I've been holding on to the hope that I could get it done for the past week or so, but no, there's just no way.
Python (Monty)
"Because Kilimanjaro is a pretty tricky climb you know. Most of it's up until you reach the very very top, and then it tends to slope away rather sharply..."
Been banging around Python a bit. It's certainly a different feel than the classic Java/C++/C#/Delphi OO paradigm that I've been used to. I've finally gotten a basic class and unit test up and running. It's a pretty simple rectangle/area thing, but it works and it gets me one step closer to understanding Python.
I also got PyUnit to work and did some Test First coding. I actually found a bug in my dinky little rectangle class. I had wanted it to throw an exception when I set width or height to a negative number, so I wrote tests to expect an error for setWidth, setHeight and the __init__ method. But when I wrote the code, I forgot to check the input for the constructor. Fortunately, PyUnit caught the oversight. Bad job Peter; good job PyUnit.
Meanwhile, I'm watching classic Monty Python sketches as I work. Perfectly appropriate I think, but it makes it more difficult to concentrate.
More on Python over the weekend, as I progress.
Game/Board
Dave had a few questions about the possible design of a game/board set of objects. I've posted them here, with my responses, slightly edited to remove some of our rambling:
Dave: Now storing the game is something that I'm very interested in. I guess in the abstract it shouldn't be controlling what it looks like exactly because the user-preferences is allowed to affect that. I'd love to work on that, with the only caveat being that I'd like to consult with some group of others about what the structure of the object should be like... what methods are people expecting, etc.
Peter: Imagine a Go board. Imagine that some entity can only communicate via methods on an object and needs to be able to play Go.
Design that.
The Go board itself should be Go-Stupid. It shouldn't know anything about the game of Go, only about its size and what's on it. In fact, if I were clever enough, I should probably be able to use it to play Pente or Othello. You'd probably also want a "game" object that stored game state: players, turns, last move, etc.
Dave: Interesting. Since we're going to want the ability to "replay" the
game do you think the board should be storing the order in which moves
occurred? Or do you think that would eventually be up to the game?
Peter: I was thinking about XP and the design and having a separate board and game object is typical OO design. However, it kinda violates the XP mantra: "As simple as possible to get what you need."
For the history, I'd definitely say, "Don't worry about it." Don't worry about the history, because we aren't doing the history part. We just want a game that stores today's state, and enough other info to present
what we said we'd present for Release 1.
History is complicated, and will certainly involve extensions to the game object and possibly the board object. But we can do that later, when we've had more experience with our objects and we've played with the game a little.
For the board/game objects, having a separate board and game object might theoretically violate the "simple
as possible" mantra, but for me it doesn't. I think it'd actually more difficult for me to program it as one piece, because it feels so wrong to me.
Also, it doesn't cost much (if any) extra time, it's almost certainly going to need to be done, and redoing it later will cost more time than doing it the first time.
History, on the other hand, will cost extra time, may not need to be done (if we never get that far), and the little bit of refactoring that will be needed should not be that expensive, especially if we have tests to make sure we haven't messed anything up.
I think that's the right call, but I'm open to suggestions.
As for game state, all game validation should be done by a "judge" object which we'll tackle later.
Dave: Righto. The Board will presumably enforce some rules though. For instance, that one can't play "off the edge" of the board, and you can't play where a stone already is, eh? I guess in a game like
Othello, you might actually want to change the color of an existing spot on the board. But playing "off the edge", seems undefined, and as such I would expect the object to reject it.
Peter: Yeah, the board needs to enforce the physical rules of the board. We are only programming a Go board, so don't worry about functionality you won't need. ("As simple as possible") So you should assume one piece per square and you should only worry about Go style moves on the board. That is, adding/removing pieces, I think. Not changing colors, not moving a stone from one place to another.
To imagine your interface, the ins/outs, model it after your hand touching a Go
board. What are all the things you might need to do to that board? That's how I usually tackle it.
Book
We're going out of town and I wasn't going to be able to have internet access. Still, I wanted to work on Python this weekend, so I buckled down and bought a Python book today. It's an O'Reilly, of course, Python in a Nutshell.
There's some things that you can do with a book over a computer. You can take it on the pot, you can read it in bed, you can take it to a restaurant or out camping. Someday it will be less of an issue. But today, I'm glad I have my book.
Studying Containers
We broke up the work for the first iteration. I took the Container, which is something I've been wanting to study and work with for a while.
I know, you're thinking, "What, you don't work with MVC today?" Actually, no. Where I work we somehow got stuck in model 1 MVC, with JSPs in charge of shuffling the user around. It's a pain, but that's the framework we have.
A while ago I was studying up on the MVC as part of a review of enterprise programming and I ran across an interesting (to me, probably old hat to you) way to implement containers. (Designing Enterprise Applications with the J2EE Platform, Second Edition) Rather than just run a ton of if-then-else statements, it uses the command pattern, pulling the command from the URL and using it to look up an action in a hashtable. If you're clever enough, you can even use XML to configure it. Then you just stick in a new class and update the config file.
I'll be turning that into Python, which shouldn't be too hard. It's a pretty simple pattern, and Python is OO. I wonder if Python has anything that makes this especially easy. I guess we'll find out.
Meeting
This weekend's meeting was interesting. John, Tom and Dave had all implemented Story 0, but mostly in true XP fashion: doing the needful as simply as possible. They all used DTML to generate the basic welcome page. But in the meantime, everyone got Zope installed and got some familiarity with how it worked.
I'd say that's a success.
This time we talked a lot about Zope and how it was different than lots of other things we'd used in the past. Then we attacked the stories.
The first step was to choose the items that made sense for the first release. We figured, for the first release, we'd concentrate on allowing a player to play a single game. No history, just enough to actually play a game against someone else. So, you'll be able to start a new game, quit a game, or play the game in progress. We realized that we needed to add "quit" as a feature, because if you were invited to a game, there'd be no way to play any other game. That would be bad.
Also, since there's no scoring and no validation, there's no way to end the game and declare a winner. So, someone just quits and the game ends.
Which is fine.
Next, we took the stories for the first release and pulled out the ones we wanted for the first iteration. We decided to tackle user login, preferences and a main menu first. Which makes sense. As XP suggests, the dependencies sort of work themselves out.
We divided up the stories into tasks and doled them out. It's a small start, and we really had enough to comfortably fit 3 people, so we are a little uncertain about the fourth person. We suggested possibly starting the board rendering, as this is next on the list, and can be done comfortably apart from everything else. But that's up to them. They may even want to just tackle the next iteration all together.
That's going to be tricky though, to keep the un-present in sight.
The funny thing is, I was uncertain about how much we had to do and how it would get done. If it would get done. But afterwards, I felt supremely comfortable that we could handle the chunk we had taken. It might be close, but it was definitely doable. At which point, the whole project became doable.
That was a nice feeling.
|
|
|
|
