torsdag den 11. oktober 2007

Slow development cycles? Try something old-school.

Does this scenario sound familliar?

"Quality Assurance just discovered a logical error in your presentation of the customers product.. instead of the 'Two-month no credit limit' - product, the 'Three-month no credit limit' - product emerges,
Thinking you have the answer, you are remembering the pesky ProductNameProvider you wrote, and you guess it's a one-off error here. You seem to remember that the first two OR three records in its output are just static titels. You can't remember if it was the first two OR three, so you try incrementing your reference-index by 1. You then restart the server, deploy the application and wait patiently for a result...

After replicating the error in 42 easy steps, you conclude this wasn't the right fix, now it's showing a completely wrong 'One-month no credit limit' - product.

You suddenly realize that this could be an error in the actual product request or maybe the text formatting or maybe it's the caching?
- so you try every possible path for the error and try out 3-4 different scenarios for 3-4 different paths only repeating the 42 easy steps... again... and again..."

Such slow processes of bugfixing are caused by ONE thing.. lack of unit tests and proper structure. This cycle of fixing said bug, should have an obvious solution. A unit test somewhere should test that the output of a ProductNameProvider is fixed. Having an automatic testframework and supporting stubbing(maybe mocking), would allow you to test this functionality exclusively and not the entire application at once, which is too complex for any human to handle... well some applications are, especially if you like me only handle applications for shorter periods(READ 3-6 months).

I have just begun working on an assignment at a large danish company. Their applications are mainly J2EE with some heavy junk in the trunk.
My task there involves developing portlets in WebLogic 10. This is a nice platform for portals because of their intuitive CMS and flexibility in layout. BUT since its a J2EE platform, it's inherently slow, because of lots of configuration and stuff under the hood that does lots of... well.. stuff.

To test an application developers tend to restart the server, because we are neurotically inclined to think that an incorrect state of the configuration involved is the main cause of our bugs, and it's understandable. Although 99% of the time, we just fucked up, we do however restart the server about 5 times before admitting it..

NONE of my tasks will ever involve extending the CMS or directly interfacing with the CMS in ANY manner, so why would I need to EVER start this up when doing a simple two-page portlet.. or a complex seventy-page one for that matter.. case is.. I don't and I certainly won't. So, my advice is to avoid that the running of your code requires a running server. A common mistake is to run code, right there in your main methods.. for an example in a struts action, a beehive controller or whatever. Delegate, delegate, delegate all responsibility to classes with limited responsibility.. atleast 1 class, that doesn't require you to load a shitload of code or annotated compiles.

Even a simple ProductNameProvider will eventually be executed atleast 10 times in its development stage and atleast 10 times (maybe hundreds) in its lifetime for debugging purposes.. so lets do the math.

total runs = 20
Writing the ProductNameProvider in a unit test friendly environment = 15 min
Restarting a shitload of applications on a J2EE server + replicating bug = 2 min (atleast)
running a single unit test = 1 sec (atmost)

60 x 15 (unittest creation) + 20 x 1 (unittest running) = 920 seconds
60 x 2 x 20 = 2400 seconds

I am not counting in maintenance of unit tests, this is parrallel to development and should not acquire extra time.. unless you implement a completely new feature..

I'm not even getting in on how unit testing reduces bugs, facilitates refactoring, reduces the footprint of your code etc etc.. there are tons of documented experienced of that out there.. read it.. read it all... now!

Running/testing your code, should be as easy as ALT + SHIFT + x, t

tirsdag den 14. august 2007

Hilbert curve

Is it nerdy when playing with a folding measure, you implement a Hilbert curve?



Hilbert curve

fredag den 27. juli 2007

Synger af vrede

Iliaden er en episk fortælling om grækernes invasion af Troja. Den beskriver det hele, lige fra det politiske spil, til den menige soldats kamp imod overmagten og gudernes indblanden.

Oversættelsen jeg har læst, er skrevet i et moderne sprog, der til tider kan forvirre mig om jeg nu læser et moderne action eventyr, eller om det virkeligt er en fortælling der blev skrevet for over 2500 år siden. I begge tilfælde kan jeg sige at der ikke er nogen mangler på nogen fronter, der kan sætte tvivl ved at dette er den oprindelige fortælling, det oprindelige eventyr.

Akilles er født af guder og dennes kendskab til egen usårlighed og oprindelse giver ham et noget aggressivt væsen, der ikke accepterer et nej. Agamemnon, overkongen, har et udestående med kong Priamos af Troja og inden man er noget ret langt ind i bogen er der så mange årsager til at angribe Troja at det snart bliver uundgåeligt at grækerne samler deres styrker.

Det overrasker mig hvor let bogen springer fra drama til action til erotik og hele vejen tilbage igen ret hurtigt. Det virker fuldstændigt og man får en fornemmelse af at alt kan vende på et øjeblik. Gudernes indblanden i menneskenes affærer retfærdiggøre 100% dette skift i fortællingen og når man kommer til slutningen er man knap i tvivl om at det virkelige drama er sket blandt guderne, på trods af at en af menneskenes byer står i brand(Spoiler! :D).

Odyssus og de andre tapre kriger begår konstant heroiske gerninger, men det er blot opvarmning til det store slag der kommer da Akilles beslutter sig for at drage i krig. Det sker efter at hans bedste ven(og muligvis elsker?) bliver sloget ihjel af troerne. Til sidst dør han dog, som guderne havde bestemt på forhånd og Troja falder. Ingen guder er dog døde, enekelte er knap forurettede, men slaget blev afgjort på Olympen.

Dante's helvede

Den Guddommelige Komedie starter med lyrikken: "Midtvejs på vor rejse igennem livet, finder jeg mig selv i en mørk skov"

Der refereres til at vi alle har en sti vi følger igennem livet, her vågner Dante op og ser sig omkring. Inden længe er hans rejse begyndt og den fører ham igennem helvede, purgatoriet og paradiset. I dette indlæg vil jeg kun kort nævne nogle ting jeg bed mærke i.

Oversættelsen jeg har fundet indeholder oversætterenes noter, hvilket skal vise sig at være helt uvurderligt, da Dante ofte refererer til begivenheder omkring hans hjemstavn i Florence, Italien.

Han tur gennem helvede starter uden for de ni kredse, hvor afdøde der ikke troede på Gud i livet tilbringer evigheden. Her findes alle former for kættere som f.eks. vikinger. Stedet kaldes for limbo.

Dante bruger desuden referencer til Homer's værker, hvilket i en sammenhæng hurtigt kan tilbyde en hel historie til selv den, ellers, mest ubetydelige genstand. Denne egenskab giver fortællingen meget historie, men hvis baglandet mangler, som i mit tilfælde bliver det svært at få det hele med.

Hans tur igennem helvede fortæller om alskens pinsler overgået mest hans landsmænd, men også andre af historiens store personligheder. Yderst finder man de mest larmende, støjende straffe, som de døde der bliver hugget i af djævle, mens de koges i lava. Det er som om at den der straffes mest med sin egen samvittighed betragtes som hårdere ramt. Én undtagelse er der dog Judas, der i en evighed bliver gnavet på af én af djævlens tre hoveder i den inderste kreds.

Jeg glæder mig til at læse om hans rejse igennem de to sidste dødsriger, men først vil jeg have baglandet på plads. Jeg starter med Illiaden.

De episke værker

Jeg har altid haft en vis interesse i oldtiden, som jeg først udforskede i folkeskolen, hvor jeg kunne læse større historiebøger om grækenland og det gamle Persien.

Interessen falmede dog, da de bøget jeg læste manglede indlevelse og overaskelser, det var som om at forfatterne kun beskrev, men aldrig selc lagde en mening eller fortolkning i deres fortælling om hvordan tingene var.

Det kan man ikke bebrejde dem, hvis jeg havde indset at det var ikke den virkelige historie jeg var interesseret i, men mere hvad mennesker på den tid drømte om, hvad de forundrede sig over og hvordan de formulerede deres tanker der ikke var konkrete.

Fornyligt har jeg genoptaget min betagelse af oldtiden og valgte at kaste mig over de episke værker, hvoraf verdens historier og uvirkelighed udspringer.

Jeg refererer til værker som Iliaden, Odysseen, Aeneid og Den Guddommelige Komedie. Dette er listen af bøger jeg har tænkt mig at læse. Listen opstod efter at jeg havde læst første del af Den Gudommelige Komedie. Halvdelen af referencerne forstod jeg knap, jeg opdagede så at de var taget fra ovennævnte bøger, med stor reference til Virgil's Aeneide, da Virgil er Dante's 'guide' igennem de 3 dødsriger.

søndag den 1. juli 2007

Lol@my cat

I just had to attach captions to my cat Maximus. His formal name is Baron von Maximus.. the whiskered beard adds credibility to his noble origin.

So I found some snapshots from when he was kitty. I lol'ed em' up, or rather.. tried to.

Lottery numbers

Hey! Last payout from the danish lottery was a staggering 10 million some euro. I'd like to get a piece of that. So what can we do to improve our chances?

Well, we assume it's impossible to just pick the right numbers, so we'd had to calculate a bit on the chances of a random hit.


In the danish lottery there are 36 different numbers, put together in 10 lists of seven to complete one row and one shot at the big bucks. That equals to 36^7 different possibilities for a row and 36^7 / 10 for a chance on a single ticket. So we'd have to buy 8 million tickets and assemble the orders to make sure there are no duplicates. That would cost 40 million euro's, not counting the hours of work filling in the tickets.

1 way of increasing our chances would be to know all drawn numbers so far and work on a kind of probablity. So what I did was find a way getting all 17 years worth of numbers out of the national lottery's webpage.

I went to the list of draws here: http://www.danskespil.dk/spil/lotto/indhold/resultater.php
But I found it only shows the last 2 years worth. I examined the html and found that an attribute was set to a draw for retrieving your selection. So I put it on the request like this: ?draw=1. I now have access to the last 17 years worth of numbers, so far so good.

I don't want to sit and retrieve all the numbers manually so I had to conjure a script for it. I would've used Python, but I don't know the framework well enough yet, so I ended up using Java. And ofcourse I started of by writing a test:


@Test
public void TestSingleExtract() throws Exception{
LottoDataExtractor lde = new LottoDataExtractor();
String numbers888 = lde.extract(888);

assertEquals("01 - 03 - 12 - 15 - 18 - 22 - 31:08",
numbers888);

String numbers1 = lde.extract(1);

assertEquals("04 - 06 - 10 - 14 - 17 - 22 - 33:02 - 21",
numbers1);

String numbers127 = lde.extract(127);

assertEquals("02 - 04 - 10 - 13 - 15 - 16 - 26:11 - 17 - 35",
numbers127);
}


In the above code I test on the extraction of numbers far between because I found out the html shifted a little in characters and the first version of my LottoDataExtractor simple counted characters. So I had to smarten up the program a bit by looking at tags instead.

I now have the lottery numbers from 17 years back. I will have to analyze these a bit, to hopefully find a trend or something, but I don't expect it to give me an immense advantage.

get the neatly formatted numbers here. Note, the last line is draw 889, which is 30/06/07, every line is a new draw.