rebel update

a few days now using javarebel + wicket. quite an enjoyable experience. wicket is so heavy on anonymous inner classes and well, objects, that I am constantly making changes that go beyond the reach of regular hot code replace.

since creating new methods, and changing method signatures is allowed, I can go about restructuring my code as I go, to make it better, without having to worry about changes that will break HCR.

writing jdave specs after the fact isn't that bad either, if you anticipate how the specs will be written, and structure your code accordingly. and as someone very high up at work said to give us peace of mind: since we're writing code in the context of a framework, we couldn't use tdd to drive the design anyway, we have to let the framework drive the design.

java rebellion

while we have a varied stack at work right now, wicket seems to be the centerpiece. one problem with wicket is that the people who write it, don't use tdd in their work, so not only does wicket not have tests, but it is in fact designed against testability.

for example, on the wicket-dev mailing list:

Kent Tong:
Just that from the core Wicket code it seems the convention is to make methods final by default and make them non-final only when necessary.

Igor Vaynberg:
imho this shouldve been the default java convention. it takes more thought and analysis to design something to be overridable.

everyone who has tried to mock wicket objects knows what this design leads to.

while we're waiting for java7's hot code replace abilities like interface injection, there's a proprietary product called javarebel, that does almost all hot replaces on current vm's, including, changing method signatures and adding/removing methods. a bunch of guys at work have been using it, and they're quite happy with it. so happy in fact that they're now developing phpRoR-style, without tests, and just coding away and refreshing in the browser after each change. and sometimes writing tests afterwards.

no personal experience yet tho. also, there's a wicket-1.4m2 out, but we recently froze our dependencies to their current versions. :|

object oriented principles

There are two entities already breaking the rules, racing to capture the same resource. for example, two bicycles riding on the sidewalk in opposite directions. the side walk is so narrow that only one bike can pass. running into each other would be in neither's interest. who should yield? is it the one that is not only driving on the sidewalk but also in the direction opposing traffic? if so, he must cross the street and then keep going on his side of the road. the one going in the direction of traffic, need only drop down from the sidewalk to keep going legally. here the combined effort is minimized.

what if it is a car and a bike riding on the sidewalk. here the car clearly has the size advantage, but hitting a biker on a sidewalk, even if the biker is breaking the rules, is not going to feel good or look good. is a car driving on the sidewalk a bigger offense than a bike driving on the sidewalk?

once again, I had a good time delving into the principles of object oriented programming.

we had a hierarchy of objects. some of them editable.

someone wrote in this method:

public boolean isEditable(CoolStuff coolStuff) {
return coolStuff instanceof LulzyCoolStuff || coolStuff instanceof AwesomeCoolStuff;
}

basically a static method.

the great part is that he referenced it in a commons Predicate, with something like this:

public boolean accept(CoolStuff coolStuff) {
return WeatherReport.this.someField.lulz.epic.isEditable(coolStuff);
}

ok. so I suggest would there be a better way to do this... he admits that it's a bit ugly, but we don't need a complex visitor pattern here. well, it's true, since we don't need double dispatch.

I suggest adding isEditable() to the CoolStuff interface, and here comes the punch line.

according to the principles of object oriented programming, editability is not a feature of CoolStuff, so we can't put it there. balacing the ugliness of doing this versus what's already there, I'm ready to remind him that droids don't rip off wookies' arms. we could use a simple callback, to divide the CoolStuffs into two groups and decide the editability that way.

As soon I get the energy, I'm gonna implement my own checkcast and instanceof.

going to the doctor

you should never go to a hospital when you are sick. sick people are unable to play the game. of course when healthy people don't need to go, they don't need to go.

there's a great asymmetry of information between doctors and patients. both players also have complex and unclear motives. doctors want to make patients better, but they also must balance the agenda of the entity paying for the care, the harmful side-effects of treatment, and the fact that they don't know what's wrong with the patient.

the patient wants to get better, wants to avoid harmful side-effects, and wants the best possible treatment. the patient also doesn't want to cause another patient to miss critical treatment.

let's say there are 10 patients who have hit their head against the pavement in bike accidents. the doctor has one slot open at the X-ray to check for fractured skulls.

if all patients seem to be doing fine, no one needs to be sent to the x-ray. if more than one patient however is suspect, the doctor must decide which one to x-ray. if he leaves a fractured skull without x-ray it's bad. if the doctor has a healthy skull x-rayed, the patient misses an hour of work, and is exposed to a small amount of toxic radiation.

so, what should the patient say when they go to the doctor after their bicycle accident? different people exhibit different personalities and different levels of stoicity and talkativeness. the doctor must be able to make his/her decision without really knowing the patient.

if the patient feels only mild symptoms, and has checked the web to see that mild symptoms are generally not associated with serious hidden consequences, then it is in the interest of the patient to let the doctor know what his personality is, and what he feels his actual symptoms are, and let the doctor decide. knowing the patient's personality the doctor then has a frame of reference against which to measure the symptoms described and is able to tell whether this person needs the x-ray or not.

if however the patient has more severe symptoms, which are more likely to be associated with a hidden condition, such as a fractured skull, which can only be revealed by an x-ray, it is in the patients interest to ensure that he gets the available x-ray slot.

the patient can now study the symptoms associated with a powerful concussion, complain excessively about these, and try to persuade the doctor to x-ray him. the patient is now playing against all the other patients, who are candidates for the x-ray. the doctor is likely to choose the most vocal complainer. someone who has been hit on the head so hard he has lost his ability so communicate may not be able to explain his condition to the doctor and will miss out on the x-ray, or will have to wait another day, which may worsen his condition.

so, it's a prisoner's dilemma situation. where uncooperative play is rewarded.

in the previous example the unnecessary x-ray carries a small penalty. but what if the condition is a painful knee. there is one slot open for knee surgery. the penalty of performing surgery on a knee that is in pain, but does not require surgery is great. this puts the patient in a difficult situation, since he wants the best possible diagnostic tools: x-ray, MRI, etc. but no surgery, unless it is actually required.

however, the patient cannot leave himself at the mercy of the system either, since his actual symptoms will certainly be vague and difficult to describe, and without any conscious effort to secure treatment he will be given painkillers, 3 days sick leave and told to come back if symptoms do not subside. if the condition turns out to be mild, it will heal by itself. if it is not mild, it will become harder to treat and the healing process will be more extensive than if treatment had been started immediately.

so, in the end, because of limited resources in certain parts of the ecosystem, the value of the doctor diminishes, and the patient must take on dangerous parts of the doctor's role in diagnosing and researching his own ailment.

python

it seems there is no avoiding python with google app engine being so interesting.

so, after this and that, I'm ready to fly. one thing that eluded me in the google tutorial is that you have to give the directory as the parameter, and not your .py file. the only things I know about python are: it's dynamic, it can run on the jdk, it has django, and formatting matters.

new_project_template uses 2 spaces for indentation. if you want to use the same, window.. preferences.. pydev.. tab length.. 2 spaces. it works either way.

the meaning of adding the google_app_engine directory to your project is that PyDev (the eclipse python thingy) will be able to see the google libraries. in the runtime, the libraries come from $PYTHONPATH so it doesnt care about PyDev.

running your app on the development server is annoying, since you can run
dev_appserver.py from the windows command line, but not from eclipse, as an external tool. and PyDev won't let you start is as a python from your project, since it's part of the included libraries. running python.exe as an external program fails too since you have to give to separate sets of parameters, one for python and one for dev_appserver, blech. :|

so I made fail.bat which includes:

c:\python25\python.exe "C:\Program Files\Google\google_appengine\dev_appserver.py" src/helloworld/

and now I can run it as an external program. since python is interpreted, you don't need to keep restarting. so you're set.

game theory

What a fascinating field. and applicable to so many things, especially in consulting: dealing with customers, dealing with the customers of the customer, teams, editing the backlog, enforcing collective code ownership. I didn't get a chance to study it in school so I decided I'd order a book.

which book to order, and if I am to read more than one book what order to read them in? I have imperfect information, and the cost of acquiring the information is high. I don't have any trusted game theory study consultants. Experiencing the learning process one way takes effort, and after it's done, the opportunity cost of all the other solutions has been paid.

then there's the order process of the book. one of my favorite perks at work is that we get to order any work related books into the communal library. ordering the books includes editing an html table that freezes firefox for 2 whole minutes. then the chosen books get queued into the order process. when there are enough books in the queue, someone orders them to save on shipping. then it takes about 3 weeks to get all the out of stock books included in the order to arrive at [bookstore], then they ship them for a week, and then we get the books. so quite a pipeline.

If I order one book and it turns out to be crap, it takes at least 2 months for me to find out. and then 2 months to get a replacement book. or I could pay for the book myself, get it in about a week and iterate faster.

There used to be a saying, "never underestimate the bandwidth of a truckload of DAT-tapes". If I had to transfer an exabyte of data from one datacenter to another, at 10gbps it would take roughly 25 years. (right?) I'd probably be better off loading the whole datacenter into trucks and driving them to the new location.

I ended up starting with a tiny pocket book from the 70's. I found it fascinating that the book doesn't mention Nash at all (so far atleast). Since the movie makes him look like the god of game theory. However the awesome John von Neumann, invented not only the atomic bomb, the computer but also game theory.

Let's see where this leads me.

erasure

because of erasure java won't tell you what the type of your generification is,

i.e. you cannot know what the type of T is in:

public class Fruit[T] { }

but, as shown by Ian Robertson and Guice, the type of a super class' generification can be obtained.

so make your type abstract and instatiate it with an empty anonymous inner class:

public abstract class Fruit[T] { }

new Fruit[Pear](){};

and then getGenericSuperclass();

you have to do some more looping to get the type, it's explained in Ian Robertson's post.

The alternative to this is putting the same type as T in the constructor, but that defeats DRY.


new Fruit[Pear](Pear.class);


update. thanks Tillu. I put the type parameters in square brackets.