|
|
PyUnit
I took a look at PyUnit this weekend, and it looks just like JUnit. Except I don't understand it, because I don't speak Python. But the structure is the same, which is funny because it still seems completely incomprhensible if you haven't worked with it. Somebody needs to sit down and write out a nice high-level diagram, in English with pictures, discussing how the different parts fit together. I wonder how others are fairing.
I did some more reading about stories and it looks like we've got the detail level pretty much exactly right on the stories. I'll add a tad more detail when I create the master story file.
Dave says he's done, with Zope installed and a page coming up, but we can't see it. I got a page coming up, and certainly the message is configurable, and being stored somewhere. But I'm not really sure I understand how the database works. So, I'm going to extend it out a little bit and create another page. This page will create a "message" object that is referenced by a tag. Then, when you pass the tag to the display screen, it presents the appropriate message. The question will be then, if I shut Zope down and bring it up, will all the created objects come back with it. In theory, I think that's how it works. But I'm not sure.
If it does work this way, I've got some real questions, mainly concerning memory usage. Will it swap necessary objects in and out, or try to store them all in memory? I'm also wondering how you query. Is there no such thing as traditional SQL querying then? Is a query pretty much always just creating and iterating through some sort of list structure? I guess we'll find out as we learn more.
Stories
I started creating the stories for the server. Having never done this before, I'm basically brainstorming one liners. Things like:
User should be able to choose graphics (board wood, stones, incl. size and color)
User should be able to view "most recent move"
The system should validate the move, reversing it if inappropriate.
The system should be available to score a board but only when game is over
Only allow user to play a single stone per turn.
System automatically removes captured stones.
Note how some say "should" and some don't. I'm not sure how to word them most effectively. I'm not sure how long they should be, how much they should say, how much design and detail they should include.
I'm not sure how to store them. I think we'll keep stories for a release in a text file, plus one file for all unsorted stories. Then, maybe a folder for each release, with a file for each story and its tasks. And then a file for each iteration in the release as well...
That seems overly difficult. What we really need is a web front end for a story-management system... Well. We'll stick with the simplest thing for now. Maybe that can be Scrum's second project.
Meanwhile, I've thought up 49 of them. I'm going back to the XP books to see whether I've got the right idea or not.
Meeting
The next meeting is Saturday, October 4th at 8am. Possibly at the Original Pancake House again. Or maybe just straight to the Starbucks. Maybe if we bug the hell out of the Starbucks guys, they'll get internet access sooner.
To Zope or Not to Zope
After poking around Zope at lunch, I noticed there's a lot of stuff that Zope does that's specific to Zope: DTML and ZPT templates and the built in OO database and scripts and all sorts of stuff.
This got me worried. I started thinking it'd be a "bad thing" if we got trapped into using Zope. I figured we ought to look into some of the other Python app servers and see if they were a little less proprietary.
I posted as such to the developer list.
Tom responds and asks what's wrong with that, and I answer that you need to be free to choose your server and not be tied down to a particular make and model. A classic response, but Tom's not convinced.
Then it occurs to me that Tom programs a lot of Microsoft, so "vendor-lock" isn't something he thinks about very often. And yet, he seems to get by just fine. Really, the more I thought about it, I realized my response was almost pure reflex, and I was making something out of nothing.
But we looked at it anyway. We batted it around, thinking about the risks, and we ended up deciding "what the hell". But we decided figured "what the hell" for good reasons.
1: Python is a scripting language and doesn't have a framework or template pages like JSP, ASP or PHP. So, if any server wants to make some, they're going to be proprietary anyway.
2: Where else would we go? To another fully-functional, easy-to-use, free Python server? Why, there are so many to choose from!
3: XP dictates you do the simplest possible thing. Right now, that means take Zope and go with it. I had concerns about what happens if we outgrow our local boxen and want to take this to a hosted solution. Uh, yeah, we'll worry about that should it ever happen. In the meantime, why penalize ourselves. Besides, who hosts Python apps right now anyway?
So, in short, we thought about it, and we're going deep in with Zope, as the risk is minimal, and the rewards are substantial.
It's pretty neato, really.
Zope and Salsa
I downloaded Zope (the Python app server) and Python itself, and installed both. I also downloaded a ton of documentation, but that's as far as I've gotten. Still, the deadline is September 30th. I'm curious how far everyone else has gotten.
In any case, tonight I'll be going over the Zope documentation to get a basic server up with maybe some example applications.
I've also got to draw up some stories by the 30th. Plus regular work and some other stuff I've got going on at home. But it's all good. I'm pretty sure I'll hit the deadline.
Meanwhile, I'm listening to Eminem's greatest hits and eating the best salsa in the world. It's from a restaurant called Baja Fresh, which I first ran across in California. They aren't around here in Cinci, but there's one off Polaris Parkway just north of Columbus, right next to a Starbucks. So, whenever we pull off there, I make sure to grab a couple tins. Sure, in the words of my three-year-old, "Ew, it looks like poop!" (that's the roasted tomatos), but it tastes like ambrosia. Or, well, as close to ambrosia as salsa can get.
Notes
One thing I got feedback on was the notes I took at the meeting. I was able to walk away from the meeting and put together about a page and a half on what we talked about. It looks like magic, but it's not really. It involves three things:
An agenda: Just write down the things you think you should talk about in the meeting. This helps make sure you don't forget anything, plus it helps keep direction if the meeting starts to wander.
Take notes: Not many, just enough about the key points. Since you already have a list of the things you will be talking about, half your notes are already taken for you. Just add any little tidbits you need to remember. Concentrate primarily on decisions that were made and things people need to do. You might also note some discussion if it was heated, or you got to the decision in a convoluted way.
Write 'em up: Right after the meeting, as soon as possible, sit down and type up the notes you took. The agenda and the notes will help to prime your memory, so at this point, dump as much detail as you think is important.
In the end, you'll have a solid page of stuff people need to remember, you'll feel like you're on top of things (which you are), and you'll look really good. And looking good with minimum effort is always a good thing.
Asynchronous
So, Nick asks: Is this really "asynchronous"? Asynchronous means that things can happen independently, but in a game, they can't. You can't make all of your chess moves whenever you want. You always have to wait for the other person. So even though you're not sitting together, and the moves have long pauses between them, the game is still played "synchronously", no?
Well, that's one definition. Asynchronous has a few. Others revolve more around concurrency, which is more of what we're going for.
The key might be in the definition of synchronous, which almost universally looks something like: occurring at the same time. In most games, the turns aren't exactly taken at the same time, but you are playing the game at the same time as someone else. We want to break that model, so you don't have to play the game at the same time. You can play it at different times.
Actually, when you think about it, "asynchronous" really means NOT occurring at the same time. We've taken that to mean things can happen whenever they want, but really, it's the other way around. If you can do something whenever you want, that's asynchronous, because by definition you don't have to do it at the same time as something else. But if you have an asynchronous process, it doesn't necessarily allow you to do something whenever you want.
That would be a bit like saying, since a yellow banana is not-green, all not-green things are yellow.
So, we're modelling more off asynchronous messaging, which means that a process can send a message, even if there's no-one to hear it right away. There's no need for concurrency. We want that with games.
On another tangent, one of the things we're looking at in the off-shore model is the problem with synchronous meetings. They're just really hard to have. So we rely on asynchronous communication models, where I can communicate with you without you actually having to be there.
We sort of already knew this, but once we pinpointed *why* some things worked better than others, we are now better able to address the situation.
Later, Rob adds:
Synchronous game, Asynchronous access
Case closed. Not guilcup.
Met
The first meeting went pretty well.
Well, honestly, the fact we had it was pretty neat in itself.
But we chatted, ate a great breakfast, and got some business done.
We talked a bit about a Go-Server vs. a generic game server. It's an interesting question, because our first instincts were to go for the abstract, but XP teaches to only program exactly what you need, and no more. So we were torn. Truthfully, while a generic game-playing server would be neat-o, once it was up and playing Go, we might not be interested in doing chess or checkers or dots.
Well, we liked the idea of Dots.
More important, if we got bogged down in solving problems of a generic game server, but not a Go-Server, we might lose the momentum.
On the other side (this thing had a lot of sides), none of us really play Go, so for most of us, it's an abstract concept anyway. I like Go, and actually, I'm hoping an asynchronous server will allow me to play more Go.
This one's still up in the air. Originally we decided to start with a Tic-Tac-Toe server, but after writing and erasing a paragraph that you'll never see, I'm not sure that's the write move. We'll see how it looks later.
Another discussion that came up was the idea that the server shouldn't be restricted to asynchronous interfaces.
An aside: I keep talking about the asynchronous server, or asynchronous Go playing. It's a long word for a simple concept. Most games are played synchronously. That is, you and I will sit down and play the game, one of us will win, and then we'll go do something else. Playing asynchronously means that we can play the game without actually both being at the game board at the same time. It's a bit like playing chess via the mail, or having a board set up in a study where you and I might happen to wander by throughout the day and make a move.
Also, it shouldn't be restricted to humans. What we'd like is a server that represents a game in progress, takes input, validates it, then takes care of notifying the opponent. This could be via email, as originally conceived. But it could also serve as a back-end for a more traditional web-based synchronous game. It could also allow Go-bots (heh) to play.
The funny thing is, even under XP, this decision is a no-brainer. I think it's because organizing the code this way won't cause much (if any) overhead, whereas creating a generic game server framework will. It just will.
For me, the questions in XP about whether to do it or not revolve around cost and return. If it takes a little bit longer to make it more flexible, and you know there's functionality down the line that you'll need to implement, it makes sense to work it in now. If the functionality isn't a given, or it'd take a lot of effort to do today, the return just isn't worth it. Take the more simple path.
Oddly enough, this ties into something I read just this morning on... I think, Martin Fowler's blog, where he talked about Technical Debt. The idea is that, just like financial debt, you can make decisions where you take a shortcut today, and pay off the result with interest tomorrow.
So, I can cheese out a quick and dirty solution to a problem, but I'll have to pay for it with maintenance at some point in the future.
The trick is, just like the more traditional debt, you can do this on purpose. It may make perfect sense to take the quick and dirty solution, as an investment in your software, in order to get functionality out the door faster. Even though you know you'll have to pay interest next time you need to maintenance it.
In fact, XP is sort of built on the idea that the interest you pay will be smaller when using it than the interest you'd pay in a more traditional development process. Which is why most traditional processes spend so much time trying to get all the ducks lined up in a row beforehand. They're trying to reduce their technical debt by paying for the whole thing up front.
Anyway, where was I? I got a little off-track there. Oh, okay. So, in a nutshell it went well.
Our first story will be Story Zero, which is getting the environment up and running. The story is: A hello world page, with the message read from a database, displayed by a Python app running under the Zope server, and including unit tests with PyUnit. This'll get us all up and running in the right environment and we'll be ready to tackle the real stories when they come along.
And the code needs to be checked into SourceForge. Tom thinks we might have a problem there, as it looks like Zope stores all its code in its OODB, so how will we check it in? It may be we don't need to, as Zope apparently also has version control, and you can change code via the web. Still, I'd rather go with something tried and true, even if it's something as complex as CVS.
This is due on the 30th.
Meanwhile, I'll scribe up the basic stories. We talked about how best to store these, and Cook and I think we might just store them as text files in CVS. This would allow us to version the stories, and we can use the directory structure to handle breaking the stories into tasks, separating them into Iterations, etc. It's a good solution for now. I'm sure time will help us shape a better one.
Finally, we invited two fellows from somewhere besides Cincinnati to get involved. They both were interested, but expressed reservations about being able to do anything. Hopefully we'll be able to get them over that and seriously involved. The tough thing will be doing things like estimating, breaking stories into tasks and assigning tasks without them present. I'm not sure it can happen properly without them. I'm confident we'll figure this out as well.
Is anyone interested in my setting up an RSS feed for this? I figured out how to create one. But I'm still at a loss on how to use it. Feedback greatly appreciated.
Meeting
We hold our first meeting tomorrow. I'm pretty excited. I've been boning up on XP methodology, primarily from Planning Extreme Programming by Kent Beck and Martin Fowler. I think there's a lot we can use, even if we aren't pair-programming. We can still use stories, short iterations and test-first programming. It should be good.
We'll probably get into Go a bit, maybe play a few games (if I can remember the rules, even). We'll probably also develop stories for the app, and break it into iterations.
XP uses this concept called "ideal days". If I could program all day with no interruptions, an ideal day is how much I could get done. Then it measures your velocity. That is, how many ideal days worth of programming you get done in a given period of time (say, a week). I'm thinking, I might have a velocity of 1 day/week. Or maybe even 1/2, depending on how hard I concentrate.
But it's cool to know that, because that helps you estimate better. It divides the actual effort from the calendar. So, if you know you'll be swamped, or are taking a vacation, or are about to get married, or are bringing on a new guy or contractor, you'll know your velocity will be lower, and you can adjust accordingly.
Also, your ideal days are not the same as mine. And neither is your velocity. Still, I estimate using my ideal days, and you use yours. Actually, you could use any unit you like, as long as it's granular enough and measurable against your velocity.
We'll take a look at all that tomorrow.
I've also looked at audio recording the meeting, but I don't think it'll work. I found a program, but I don't have the battery length to record 2+ hours of conversation, and I don't think the Pancake House has extra outlets. Maybe next time we'll go to Starbucks.
My next move is to draw up a bit of an agenda. Just something to keep us on track and help us not forget anything. We'll see how it turns out.
Update
John's set us up on SourceForge, including a developers mailing list. Tom sent out Python links, but I haven't even gotten around to looking at them yet. I've dug back into the Extreme Programming books, as I'd like us to run this thing using agile processes (but with some process), and XP is the thing I'm most familiar with.
I think we can do most of XP, not including the Pair-Programming. The keys would be defining stories, keeping iterations small, delivering complete working builds and test-first programming. All of these will keep the project moving, I think, in the right direction.
Anyway, I've got one small page of notes. And our first meeting is this Saturday. So, I'd better get cracking. In fact, I think I'll go take some notes right now.
Where It Came From
Really, I have a lot of ideas; cool things I'd like to do. My friends do too. We come up with interesting ideas all the time. Unfortunately, they either sit untouched forever, or they burst onto the scene with a flurry of energy and light, only to quickly cool into a extraordinarily dense, dark ball of matter. Or more accurately, they just sort of wind off once the basic functionality is up and running.
I can't speak for the other fellas, but I know I just never seem to have enough time. Or, as Kent Beck (Extreme Programming) said, it's not that I don't have enough time. I have too much to do. I have too many things that need done right away and I'm not getting to the things I'd really rather be doing.
Enter Scrum. Scrum is our group's way of elevating the merely fun to the status of "something that needs done, right away." See, by working on these things together as a group, we'll have things like deliverables and deadlines, which (stupid as it sounds) might drive us to spend a little more time working on this cool stuff. And yeah, one of us could blow it off, skip a delivery maybe, but that'd be pretty disappointing. Plus, we might call him names.
I'm not really sure what Scrum means actually. And I'm not going to look it up either, because if I find out it means something different than what I thought, I'm screwed. It's too late to change the name and all that. Plus it sounds cool. So, if I remember correctly, a scrum is a rugby thing where the entire team gathers around the ball, like a huddle, and moves together as a group to push the ball down the field.
Keeping the ball moving towards the goal, together.
And that's really what Scrum is about: moving the ball down the field together. The ball could be the program we deliver, or our growing skills, or maybe even our careers, depending on how you want to look at it. But we're doing it, pushing forward, one step at a time.
The Mission
Every good group needs a mission statement. Here's ours:
The intention of Scrum is to provide an avenue for our group to keep our skills sharp and build cool stuff.Scrum, which borrows its name from the most agile of Agile Processes, is a group of like-minded, idealistic, yet geographically diverse programmers that have gotten together to create and learn. We do this by actually implementing those inspired ideas for great projects that normally get pushed aside by day-to-day concerns. To keep the interest level high, we dabble with new or cutting edge technologies, languages and practices. By working together, we keep each other honest and on track to complete the projects we start. Thus, Scrum allows us a creative outlet, a means to experiment with new technologies, a way to learn new skills and improve existing ones, drive to finish what we've started, and a channel to share knowledge with each other in a real working environment. Plus, it sounds cool. We feel these are all good things.
Honestly, we're just getting started here in Topeka. In a few minutes, or perhaps in a few days, we'll have more information on Scrum. Meanwhile, feel free to grab yourself a cool beverage and kick back. Don't forget to hit refresh every few minutes or so.
We'll be back.
Honest.
|
|
|
|
