Wednesday, March 31, 2010

The Time-Honoured Rules of Foursquare




While you may find variations on Foursquare rules in many places, the specific rules of this game are as follows:

The Playing Surface
  • 2 144 ft^2 squares divided into quadrants
  • Three squares will be labeled with a royalty mark (Ace, King, Queen); the fourth will be left blank. The blank square will contain a hashed box called the "service square" where serves must be delivered.
  • Outside lines are in, inside lines are out. Players waiting in line are considered out-of-bounds. Inanimate objects or passersby are considered in-bounds and are playable, assuming said objects do not actively attempt to redirect the ball.
















The Rules of the Game
  • The Player in the Ace square is responsible for serving.
  • There is "no blood on a serve" meaning the serve *must be returnable* by being 1) served to the player in the unmarked square, 2) bouncing once inside the service square (see wall photo).
  • Server gets one fault (i.e. the ball does not bounce inside service square) per round and may re-serve after the first fault is called. The fault must be called by the Player being served or the serve will be considered legal. Two called faults result in the Server being ejected from the Ace square.
  • A Player is out if the ball touches them last before landing on an inside line or outside the outer boundaries. The remaining Players then advance upwards in royalty.
  • The ball may be hit in any fashion with any part of the body. There will be no enforcement of the time-honored "Underhand Only" or "No Feets" rules. However, a hit must cause a perceptable change in direction or velocity.
  • Rolling the ball across the line shall be considered an illegal hit.
  • As this is a gentle(wo)man's game, it will be self-refereed under the honor system. If two Players cannot agree on a game decision, then the "Two (Wo)Men Enter, One (Wo)Man Leaves" rule comes into play. In this scenario, a two-square battle will be played, with the losing Player being ejected from their square.
Advanced Moves

  • If a ball bounces in a Player's square, the ball must be hit by that square's Player. Another Player may not steal the ball. However, a Player may reach across and steal the ball before the ball bounces. Such a move shall be called "The Snake."
  • If a ball is hit up into the air, a Player may stop the ball's trajectory and redirect it back into the square, but it must bounce once in the Player's square before being hit out. Such a move shall be called "A Bus Stop."
The tournament structure is as follows:
  1. A Player receives one point for each round survived in the King and Queen squares. A Player receives two points for each round survived in the Ace square as the Server.
  2. The first half of the Players that reach an arbitrarily decided number of points (100?) will be entered into the competitor's bracket for the prize. The remaining half will be continue to play for the lower bracket's prize.
  3. The bracket competitions will be Five-elimination. You continue to remain in the game until you have been eliminated 5 times. The game continues until 4 players remain. When four players remain, all eliminations are reset and the Final Round commences.
  4. In the final round, all players receive one point for surviving a round. The first player to reach 10 points is summarily declared the Winner of that bracket and receives the bracket's Prize.


Friday, August 21, 2009

Granularity in Kanban

Kanban is pretty freeform, I'll admit. Coming from Scrum, which is pretty free-wheeling in itself, I feel like there's very little I'm "required" to do. I can kind of make it up as I go. While I think that's intrinsic to the adaptive nature of lean, and kanban in particular, it does feel a little like I'm out on my own.

One thing that's painfully obvious: the ready, in progress, and complete states are not granular enough.

I know, I know. That's obvious.

Still, I find myself adding a state in the workflow every day or so. Fortunately, it's incredibly easy to tweak the workflow w/o disrupting forward progress. After a week, here's where I'm at.















As you can tell, granularity organically grew as I got more comfortable w/ the process. There are different WIP limits in each section of "in progress." My particular need is different, since I'm using my transition to a new gig as my backlog, but in software development you still have the "i'm doing R&D, i'm working on unit tests, i'm waiting on infrastructure" types of states. You'll have an incredibly amount of flexibility in determining how you should gate or throttle your work in progress, but it will take time for a team to figure out exactly how they should tweak their limits.

All in all, I'm really excited to apply this methodology to an actual software project....

Wednesday, August 12, 2009

New beginnings, new methodologies

So, I doubt more than a handful of people read this (I do this for my own cathartic purposes, really) and everyone that does knows that I've taken a new position starting in September. These same people also know I might be a bit of an Agile fanatic. Scrum (which, honestly, is still my fav methodology) has lost a bit of its well-earned sheen, Lean and, specifically, Kanban have become the new silver bullet.

So, being the sucker for shiny new toys, I need to try it out. So, I've decomposed all the items I need to transition into work items on a kanban board. While I won't have time here (I leave Sept. 4th) to see the fruits of it in a development sense, I do get a good sense of how to track work with it. I've been doing Scrum-ban for quite some time now so the pull concept of Kanban makes sense. There are so many interesting variations of how to limit work in progress and model workflow that I'm actually excited to try it.

More notes later...

(a pic of my kanban board is here)

Tuesday, May 19, 2009

TFS - Don't allow "Resolved" on checkins

This is the third or fourth time I've done this, so I thought I should put it here for the fifth or sixth time ;-) I have yet to find this away without getting dirty in the Xml (doing this in the GUI doesn't seem to work).

  1. In VS 2008, export the work item type (probably task, if you're using Agile 4.0) to an Xml file (if it asks you to include any Global Lists, just say no).
  2. Open w/ yr Xml editor (I use Notepad++)
  3. Find the TRANSITION node between the two states you care about. (Xpath would look much like "//WORKFLOW/TRANSITIONS[TRANSITION[@from='Active' and @to='Closed']])
  4. Under this node, you'll find an ACTIONS/ACTION node containing a value like "Microsoft.VSTS.Actions.Checkin".
  5. Delete that entire "ACTIONS" node.
  6. Save the file.
  7. Import the work item definition back into TFS, effectively overwriting the existing definition.
  8. Profit!
Note: As always, I googled to see if someone had figured out the GUI angle. Lo and behold, Martin Woodward has blogged about this before, bless his heart. Due credit goes here:

http://www.woodwardweb.com/vsts/000230.html

Tuesday, May 12, 2009

Team Build and NUnit - Together At Last!

Perhaps this is already well-known, but I've scoured a bunch of sites trying to find a simple, yet comprehensive plan for getting NUnit tests to run as part of a Team Build script. I had to explain this to someone earlier this week, and I would have loved to just point them to a simple doc. So, next time, I'll point them here:
















Tuesday, March 31, 2009

AOP in .NET

So, despite promising a treatise on REST in WCF/.NET, I realize that others have said it far better than I (e.g.):

Jon Flanders
Ryan Tomayko (i liked this a lot, despite the stupid complaints of sexism. sheesh.)
and, oh, this company called Microsoft.

So, on to another pet project: aspect-oriented programming.

I've been obsessed with writing really lean, tight code as of late. In looking back on some of my work in the last couple years, having a new perspective of (the lack of) ROI on some premature optomization, I can pick out dozens of places where I would have thought (then) "oh, some day someone will need this" whereas I'd say now "is anyone honestly going to use this?" Of course, following TDD as a methodology helps me there too ;-)

So, I want to log exceptions. I also, for debug purposes, might want to log, well, everything.

I have it narrowed down to two options: runtime weaving with Spring.NET and compile-time weaving with PostSharp. The terms are self-explanatory (unlike other AOP jargon). While I think either could be used in either case, they have clear strengths in their respective foci (or, focuses).

Spring.Net. It's all runtime, meaning it's .NET language agnostic, and it all plays very, very nicely with Spring's IoC containers. I noted it doesn't allow you to do field interception (cool idea, but the power is too ripe for abuse and leads to bad OO design), just method interception, but that lets you cover everything you honestly need to do . . . Still I hate it when I know I can't do something, even though I have no business needing to do it.

PostSharp, as I mentioned, does do runtime weaving, but it really does an amazing job with compile-time weaving. If you've dealt with this technique, your big objection is noted. Yes, it's dificult to debug and, yes, it is magic. I know, it scares me too. But, when, (as in the case of log4PostSharp) I can literally have system-wide logging with ONE line of code in AssemblyInfo, I'm hooked. It's a fair trade.

I'll see how it goes. Though, I've built fairly robust logging into three separate service stacks in the course of a few hours using PostSharp.

I think I'm hooked.

Thursday, February 26, 2009

WCF will do the REST of it for you...

So, in the interests of interop, we're going to be exposing all of our SOAP/WS-* services RESTfully too. Okay, I'm there conceptually, but I have some serious concerns about logistics.

So, I thought I'd detail what it takes to go from a "Microsoftie-thats-perfectly-happy-with-SOAP-because-Visual-Studio-does-all-the-hard-work-for-me" type to a "hey-lookee-lookee-I'm-interoperable-because-I've-been-freed-from-the-strictures-of-WS-*" type.

Note that this is, for some reason, a highly charged topic to discuss. While I'm sure I have enough say that I could put the kibosh on the whole thing, something tells me that there must be something to this or I wouldn't have a good 50% of developers jumping out of the woodwork yelling "POST is evil!!!!1111!!1" ;-)

See? http://cafe.elharo.com/web/rest-vs-soap-a-parable/

So, I'm curious on which side I will fall.

Let's see...