I tried out Hatsuden

I bought a copy of Hatsuden at Tokyo Game Market, and was a bit saddened to see such a simple gem to be solely available with Japanese language rules.

The game itself is supposedly based on Battle-line, but it is very much its own game. You run a power company and are responsible for building a specific type of renewable power (Hydro, Biomass, Solar, Geothermal and Wave/Tidal). You take turns drawing power plants until you and your opponent have 5 cards each. After that, the game begins.

On your turn, you can put down a card in one of two rows in your tableau. These cards have a value written on them; this value is the amount of power they can provide. If you play the card regularly, you can then (in future turns) replace the card with a card of greater value. However, you also have the choice to place the card down face-down; in that case, it is worth zero points and can’t be replaced.

The amount of power provided has three important effects on the scoring at the end of the game.

First; if you have the most output of a certain type of power, you get one point as the “chief supplier” of that energy type.

Two; you can replace cards of a lower value with a higher value; a wind power plant of value “1” can be replaced with a “2” or a “3”. 4s cannot be replaced, and you cannot do anything with a card that has been flipped over.

Three; if the horizontal value of your “row” is equal to 10 points, you will be rewarded with 2 points for supplying a city with the exact amount of power it needs. Alternatively, you are safe with 9 or 11 units of power supplied. Any less than 9 and you lose points; any more than 11, and you must scrap power plants by flipping over their card (IE: make them worthless & non-replaceable) until you have 11 points or less of electricity in that horizontal.

The point system is what really makes this game shine and forces you to be strategic. There are two games that you handle at once; a strength game where you wrestle for control over a type of power, and a finesse game where you try to provide your two cities just with enough power. The strength game is a versus game with you and your friend; there are plenty of opportunities for strategy and bluffing, while the finesse game forces you to hold off on playing your largest cards.

The game continues until one player has used up all 10 spots on their tableau. The other player gets one last turn, and scoring beings. One point for each power source you control (0 for ties), 2 points for each city.

This game is satisfying and quick. It reminds me of Race for the Galaxy, in that I can have a full game with my wife that ends in 20-30 minutes. It definitely is a step up over other Japanese games I have played; it certainly is better than many of the Werewolf clones made over the past year, and it has visual panache without being gaudy.
Moreover, I don’t feel like it is a less interesting version of another game (ahem, Machikoro); this game has its own personality and at the price I paid, 1800 yen, is a steal.

**** would buy again.

Life without generics and list comprehensions

I make utilities for Apex because I miss list comprehensions, and I wind up missing generics instead..

    public static List filter(List Objs, String field, String comparator, Object value){
    	 Set VALID_COMPARITORS = new Set{'< ', '>', '< =', '>=', '=='};
    	if (!VALID_COMPARITORS.contains(comparator)){
    		throw new InvalidComparatorException();
    	List ret = new List();

    	Boolean gt = comparator == '>' || comparator == '>=';
    	Boolean lt = comparator == '< ' || comparator == '<=';
    	Boolean eq = comparator == '==' || comparator == '<='  || comparator == '>=';
    	for(SObject o: Objs){
    		Boolean valid_object;

    		valid_object = value instanceof Integer && (
	    			(gt && (Integer) o.get(field) > (Integer) value) || (lt && (Integer) o.get(field) < (Integer) value) || (eq && (Integer) o.get(field) == (Integer) value)
    			) || value instanceof Decimal && (
	    			(gt && (Decimal) o.get(field) >  (Decimal) value) || (lt && (Decimal) o.get(field) < (Decimal) value) || (eq && (Decimal) o.get(field) == (Decimal) value)
    			) || value instanceof Date && (
	    			(gt && (Date) o.get(field) > (Date) value) || (lt && (Date) o.get(field) < (Date) value) || (eq && (Date) o.get(field) == (Date) value)
    			) || value instanceof Datetime && (
	    			(gt && (Datetime) o.get(field) > (Datetime) value) || (lt && (Datetime) o.get(field) < (Datetime) value) || (eq && (Datetime) o.get(field) == (Datetime) value)
    			) || value instanceof Time && (
	    			(gt && (Time) o.get(field) > (Time) value) || (lt && (Time) o.get(field) < (Time) value) || (eq && (Time) o.get(field) == (Time) value)
    			) || value instanceof Long && (
	    			(gt && (Long) o.get(field) > (Long) value) || (lt && (Long) o.get(field) < (Long) value) || (eq && (Long) o.get(field) == (Long) value)
			if (valid_object) ret.add(o);
    	return ret;

Pencils and Erasers

I carry a 10-pack of pencils with me. It triggers some snickers at work, but I always felt they helped me retain more than the notepad app on my phone.

I love how they let me keep clues to my thought process. I can see the spelling mistakes, the scratched out lines, the thinned spots on the paper where I erased the contents a half-dozen times to get the right word. They are hints that bring me to the string of thought that lets me truly understand what I was thinking when I wrote whatever it is I wrote.

Pencils are like a version control system where someone kindly took the trouble to check in their half-finished code. A repo with the half-baked ideas still there, letting me see the journey from start to finish.

Credit Card Ads

When a fresh face joined my team in Japan from Canada, I recall sitting to him in a train and saying, “Every advertisement in this train is an invitation to self-harm.” The first thing my eyes fell upon when trying to clarify my statement was an advertisement for a Credit Card. It could hardly have been a better example.

I have a credit card. I acknowledge the value. I don’t have to mention that the desired usage pattern is incongruous with your fiscal health. Yet, as all ads do, it simplifies and hides that complexity. Just sign, swipe the card. There is no embarrassment involved; if buy the product online, and there isn’t even another human involved. You can’t afford it really, but who cares right?

Well – it’s debt, and debt always has its day. It is dishonesty based on implication rather than blurted outright.

Computer languages can be much the same. There is the obvious performance penalties involved in using a language like Python versus a language like C. However, this is an honest debt, a healthy debt, a way to build things or avoid an entire classes of bugs.  Python is not lying to you.

Yet, there is an insidious form of technical debt, a dishonest form of debt that is inbuilt in some languages. You can find that in Apex.

When my intern started to learn how to use Apex and Salesforce, I didn’t bother teaching him about the generator limits. It didn’t take him long to check in some code that he had made, and I imagine it looked something like this.

    trigger Basic_Trigger_v1 on Custom_Object__c (before update){
        if (Trigger.isBefore()){

    public class CommonObjectTriggerHelper{
        public static void IncrementCustomObjectLineItemCounter(List all_custom_objects){
            for (Custom_Object__c obj: all_custom_objects){
                List all_lineitems = [select id, name from Custom_Object_LineItem__c where parent_id=: obj];
                obj.lineitem_count__c = all_lineitems.size();

From a purely aesthetic point of view, this look like attractive code. It’s short, to the point, and seems to deal with only one task. Yet, what is simple, clean and beautiful is actually useless.

First, the number of SOQL (not a typo) queries in Salesforce are quite limited. Doing a query in a loop is the root of many bugs.

Two, there are multiple things being done in the IncrementCustomObjectLineItemCounter function, and some important work is being wasted / thrown away for no reason.

(Three, there probably is no need to use code as Salesforce has rollup fields that can handle this under some circumstances, but this story is needlessly complicated, so let’s skip it.)

Fixing this is not a particularly difficult issue. However, the code becomes ugly and difficult to read. This mismatch, between code aesthetics and code value, is a major problem with Apex, and a major reason why it is a dreaded language.

In that sense, Apex is a bad credit card ad. The debt you accrue is technical and may only manifest itself at the worst possible time (post go-live, during some sudden need for a mass data update, for example). It’s even worse if you have a vendor who is willing to bend the rules to get the hell out of dodge.

The only difference with credit card debt is Salesforce doesn’t make more money when you do things the wrong way. My feel is that they do, sincerely, want you to do things the right way.

Next time, I will discuss the downsides of trying to fix this through library functions alone, and the Apex Framework I have been working on to try to overcome this issue; Underscore.sfdc