This summer I'm participating in Extreme Blue which is an internship program where a team of students collaborate with experienced IBM engineers and managers to produce high value technology. The teams attempt to bring innovative solutions to real business problems. All in all it's pretty exciting.
I'm working with an IBM team based in Victoria, BC which is quite removed from my current home: Ottawa. While I'm in Victoria, I'm staying in one of the UVic residences, which presents a bit of a challenge in terms of commute. I don't have a car, it's a little far to walk which leaves taking the bus or getting creative. Since I'm not overly fond of relying on taking the bus, last weekend I picked up a bicycle at a local bike shop and have started commuting by bicycle.
My new bike. It's grey and not particularly exciting.
Now that I've got a bike, I have to find a route to and from work that I'm happy with. The first is 7.8 km and dead simple. I take one of the main roads leading away from the university (Mackenzie) and follow it until I hit a second major road (Quandra), which I follow north until I get to work. While direct, this route has substantial traffic, intersections and inconsistent bike lanes that make it less than pleasant.
The direct, though not particularly pleasant route from the University of Victoria to the IBM campus.
While, the second route under consideration is slightly longer, 10.8km, and not quite as dead simple to follow, it takes the rider along the ocean and through Mt. Douglas Park while subjecting them to less traffic and controlled intersections. While, the second route is unmistakably nicer, I'm not sure I'm up to handling the marginal 3.0km. Maybe as I get back into the habit of cycling, I'll consider taking the route through the park, particularly on a leisurely bike home.
The more pleasant, though slightly longer route from UVic to IBM.
Next week is Bike to Work Week, so I'll be practicing my commuting skills and planning to hit up at least a few of the celebration stations throughout the week. At the very least I'll be hitting up the wrap-up barbecue.
Here are some Munchkin cards that I've been thinking about for a while. I am always most interested in cards which simultaneously have benefits and drawbacks. While cards which are purely deleterious are kind of fun if you can compel others to use them, cards which are deleterious but used anyway because of the twisted psychology of a munchkin are far more entertaining.
Break Down a Door: Draw Three Cards
Type:
Door
Discard this card to draw three door cards face down and put them in your hand.
Discussion
This card addresses the fact that there's no way to straight up replenish a depleted hand, despite that fact that many abilities are powered by discarding cards.
Curse: Draw Three Cards
Type:
Door (Curse)
Draw three door cards face up. All curses drawn this way effect you and all monsters must be fought as if you broke down a door. If your are already engaged in combat, any monsters drawn join in the fray.
Discussion
The substantially more dangerous and wacky version of the preceding card. This curse could easily be seen as beneficial as it essentially allows the target to engage in an additional combat; however, there is serious risk in self-application as any curses drawn take effect, and more/more-powerful monsters than are easily handled could be drawn. Such a curse may also make a munchkin rue the day they equipped a curse-reflective helmet.
Loot the Room: Pendant of Pedantry
Type:
Treasure
Bonus:
+3
Size:
Small
Value:
No Value
When a player engages in pedantry roll a die. On a one, the pendant explodes and kills the munchkin that owns the pendant along with any munchkins that may be helping her in combat. On any other roll, give the pendant to the pedantic munchkin and gain a level. This item cannot be sold.
Discussion
Whether this item encourages pedantry or discourages it really depends on the perceived risk/reward balance and the number of (re)loaded dice available to the players. This may simply introduce chaos into the game, but that's what Munchkin is all about anyway :P.
My previous implementation of the with_statement in ruby had one major flaw: It allowed only a single context manager per with block. While effective, it leads to cluttered code, like the following:
Effective, but it isn't as clear as it could be and introduces more nesting than is really necessary. This coupled with my desire to explore varargs methods and blocks in ruby has lead me to a more robust implementation that can take an arbitrary number of managers as a parameter.
The preceding implementation is more complex than the original. In addition to introducing "star magic"1, it relies on recursive creation of begin-ensure blocks which complicates exception handling; however, this implementation allows for such beautiful usage as:
Should a manager's exit method raise an exception, that exception will supersede any exception raised within the block, though it will not interfere with exiting other managers.
An implementation and unittests are available in a Mercurial repository. The implementation can be retrieved as follows:
hg clone http://hg.crimzon.ath.cx/with_statement
Both the implementation and unittests are licensed under the MIT license.
One of the things that I do enjoy about Ruby is the ability to use blocks to synthesize control structures that may be missing. For instance, I'm a big fan of python's with statement. Through a combination of guerilla patching and blocks, the with statement can easily be added to the ruby language as a library.
Convenience constructors should always call a more general constructor, rather than duplicating the work performed by other constructors. If the general constructor does nothing other then set a few fields, it is tempting to set the fields directly rather than call another constructor; however, doing so invites defects by duplicating code.
Not only is the latter shorter, but should the constructor be modified in the future to establish an invariant, it is much simpler to implement the invariant establishment code in a single location.
Never Do With a Setter That Which can be Accomplished in the Constructor
One of the key benefits of this strategy is that if all parameters needed to initialize the object are available at the time of construction, then fields can be declared final and Immutable objects are simpler than mutable objects.
DRY: Don't Repeat Yourself. The idea that any piece of information in a software system should be specified in one canonical location. This principal applies both in the small: avoiding code duplication and the large: ensuring that configuration information is not duplicated throughout the system.