Commuting in Victoria

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.

/blog/entries/2008/05/25/commuting-victoria/my_bike_-64ac24125221.min.jpg

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.

/blog/entries/2008/05/25/commuting-victoria/to_work-1f2f0bf41ced.min.png

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.

/blog/entries/2008/05/25/commuting-victoria/to_work_douglas-a2bfa605c117.min.png

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.

Munchkin Mayhem

Munchkin Mayhem

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.

With Statement (Redux)

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:

with(open("hello.txt")){|f|
    with(open("bonjour.txt")){|g|
        puts f.read()
        puts g.read()
    }
}

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.

def with(*managers, &block)
    def with_(managers, resources, block)
        if managers.nitems > 0
            begin
                resource = managers.delete_at(0)
                resources << resource.enter()
                with_(managers, resources, block)
            ensure
                resource.exit()
            end
        else
            block.call(*resources)
        end
    end

    with_(managers, [], block)
end

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:

with(open("hello.txt"), open("bonjour.txt")) {|f, g|
    puts f.read()
    puts g.read()
}

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.

[1]As it is called by pylint.

With Statement in Ruby

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.

require 'thread'

class Mutex
    def enter
        lock
    end

    def exit
        unlock
    end
end

class IO
    def enter
        return self
    end

    def exit
        close
    end
end

class ContextManager
    def enter
    end

    def exit
    end
end

def with(resource)
    begin
        yield(resource.enter())
    ensure
        resource.exit()
    end
end

This implementation allows for such beautiful usage as:

require 'thread'
require 'with_statement'

with(File.open("hello.txt")) {|f|
    puts f.read()
}

lock = Mutex.new
with(lock){
    puts "Yay! Synchronized!"
}

Constructor Ideas

Overloaded Constructors

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.

public class Thing{
        private final int id;
        private final String name;
        private final boolean unique;

        public Thing(int id, String name){
                this.id = id;
                this.name = name;
                this.unique = false;
        }

        public Thing(int id, String name, boolean unique){
                this.id = id;
                this.name = name;
                this.unique = unique;
        }
}

Much preferable is the solution that follows:

public static class Thing{
        private final int id;
        private final String name;
        private final boolean unique;

        public Thing(int id, String name, boolean unique){
                this.id = id;
                this.name = name;
                this.unique = unique;
        }

        public Thing(int id, String name){
                this(id, name, false);
        }
}

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.

Interfaces are simpler than protocols.

public class Thing{
        private int id;
        private String name;
        private boolean unique;

        public Thing(){}

        public void setId(int id){
                this.id = id;
        }

        public void setName(String name){
                this.name = name;
        }

        public void setUnique(boolean unique){
                this.unique = unique;

        }

        public static void main(String[] args){
                Thing thing = new Thing(){{
                        setId(1);
                        setName("Aaron");
                        setUnique(true);
                }};
        }
}
public class Thing{
        private final int id;
        private final String name;
        private final boolean unique;

        public Thing(int id, String name, boolean unique){
                this.id = id;
                this.name = name;
                this.unique = unique;
        }

        public static void main(String[] args){
                Thing thing = new Thing(1, "Aaron", true);
        }
}
[1]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.