Irmen's blog

IT metrics fallacies

Interessante post van iemand op slashdot:

The major fallacy many big companies fall into is that some of these systems have been running flawlessly for years, because they hired a competent IT staff. They look at the price of those paychecks and shiver. Why are we paying so many high priced engineers when we've never had a problem, they think.

So they reduce staff and start to rely on support contracts instead of on-site gurus. The gurus are still there to solve any oh-shit moments. But that back investment in good engineers has produced a stable infrastructure that runs with few problems for years. So they reduce staff more, pay for more support contracts, and eventually the system critical mass is greater than the engineers who can support it. It's no problem until it's a problem.

Eventually something minor goes wrong, but nobody notices or if they do it's not really their field of expertise so they don't understand it's minor now but could escalate. When it does, something else goes wrong, and a cascade effect takes out more and more systems. With a full staff, you have enough guys that when the critical mass is reached, they can start defensive measures and get things back in working order in no time. With support staff only, things are going wrong faster than they can deal with it.

"Call on our support contracts," shout the bosses! So now your on-site staff are all on hold instead of troubleshooting. When they get through to someone, they have to spend the first hour or two describing their infrastructure to the technician on the other end, who starts making random suggestions that maybe help, but probably don't.

Het praktijkvoorbeeld dat hij vervolgens noemt is best wel erg te noemen...

sloc

Voor de grap sloccount van David A. Wheeler eens losgelaten op een paar van mijn programmeer-projecten:

Pyro4:

Total Physical Source Lines of Code (SLOC)                = 8,322
Development Effort Estimate, Person-Years (Person-Months) = 1.85 (22.20)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 0.68 (8.12)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 2.73
Total Estimated Cost to Develop                           = $ 249,966
 (average salary = $56,286/year, overhead = 2.40).

(helaas herkent scloccount de .rst documentatie sources niet)

Pyrolite:

Total Physical Source Lines of Code (SLOC)                = 9,799
Development Effort Estimate, Person-Years (Person-Months) = 2.20 (26.36)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 0.72 (8.67)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 3.04
Total Estimated Cost to Develop                           = $ 296,744
 (average salary = $56,286/year, overhead = 2.40).

Pyro3:

Total Physical Source Lines of Code (SLOC)                = 11,229
Development Effort Estimate, Person-Years (Person-Months) = 2.53 (30.41)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 0.76 (9.15)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 3.32
Total Estimated Cost to Develop                           = $ 342,373
 (average salary = $56,286/year, overhead = 2.40).

Snakelets:

Total Physical Source Lines of Code (SLOC)                = 16,383
Development Effort Estimate, Person-Years (Person-Months) = 3.77 (45.22)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 0.89 (10.64)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 4.25
Total Estimated Cost to Develop                           = $ 509,043
 (average salary = $56,286/year, overhead = 2.40).

Da's voor bijna $1.5 miljoen aan free open-source software mensen! (met de standaard parameters van sloccount wel te verstaan).

Use the index, Luke

http://use-the-index-luke.com/ - "A free tutorial to SQL indexing and SQL tuning for developers: It avoids unnecessary details about database internals."

Ziet er handig uit, toch maar eens rondneuzen

Simplicity made Easy

http://www.infoq.com/presentations/Simple-Made-Easy

"Rich Hickey emphasizes simplicity’s virtues over easiness’, showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path. "

Patchen van een library functie: niet zo innovatief hoor, Windows... Amiga was je voor

Ik kwam dit artikel tegen vandaag op proggit: Why do Windows functions all begin with a pointless MOV EDI, EDI instruction?

Het blijkt dat "[it] is just enough space to patch in a jump instruction so that the function can be updated on the fly."

Ik moest direct denken aan hoe dat vroeger op de Commodore Amiga ging eind jaren '80 begin jaren '90 (goeie ouwe tijd). Behoorlijk veel in 680x0 assembler en C geprogrammeerd op dat fabuleuze apparaat. Met heel veel dingen liep de Amiga ver voor op de concurrentie van toen, en blijkbaar ook al als het ging om het patchen van library functies. Want die MOV EDI,EDI van Windows DLLs voelt maar erg primitief aan ten opzichte van wat Amiga's operating systeem destijds al had: shared libraries met OS-support voor het patchen van de library functies.

Het patchen van library functies werd op de Amiga erg veel toegepast om bijvoorbeeld bugs te fixen in de libraries die in ROM werden geleverd en dus niet via een normale software update gerepareerd kunnen worden (zoals exec.library, graphics.library, intuition.library). Tevens waren er veel 3rd-party patch tools om bijvoorbeeld de performance van bepaalde functies te verbeteren (bijvoorbeeld CopyMemQuick). En zo waren er nog veel meer mogelijkheden: je kon elke library functie omleiden naar een nieuw stukje code, zonder daarvoor te hoeven hacken, want het was een officieel door het OS ondersteund mechanisme.

Hoe werkte het namelijk:

Een library op de Amiga werd in het geheugen geladen zoals getoond in het plaatje hiernaast. Je had de library base op offset 0. Op negatieve offsets t.o.v. de library base waren de officiële library functies die je kon aanroepen. In de header files voor je compiler/assembler werden ze als constanten gedefinieerd, b.v.

OpenLibrary  equ -552 
CloseLibrary equ -414 
AllocMem     equ -356

en een library call ging ongeveer als volgt:

move.l  ExecBase,a6    ; library base pointer van exec.library
move.l  #500,d0        ; functie parameter
jsr     AllocMem(a6)   ; roep functie aan

(De waardes kloppen niet en misschien de exacte syntax ook niet maar vergeef me, het is meer dan 15 jaar geleden dat ik 680x0 assembly op de Amiga programmeerde )

Omdat die laatste jsr AllocMem(a6) aanroep dus effectief naar een negatieve offset t.o.v. de library base springt, komt hij in de "LVO" jumptable terecht (Library Vector Offset). Hierin staat de feitelijke jump instructie naar de daadwerkelijke functie in de library (op positieve offset). Deze jump instructie in de LVO jump table kun je eenvoudig vervangen door een sprong naar een ander adres, waardoor de library functie gepatched wordt. De officiële manier om dat te doen was via de exec.library/SetFunction() call.

Omdat de LVO jump table negatief is t.o.v. de library base, en de library implementatie zelf positief, kunnen libraries gewoon uitgebreid worden met nieuwe functies. De LVO jump offsets van de library calls wijzigen nooit! De daadwerkelijke functie waar ze heen springen kan overal staan zonder dat de aanroepende code dat dus hoeft te merken.

Omdat de library base en jump table in RAM staan was het dus ook mogelijk om de libraries uit het ROM van de Amiga te patchen zonder dat er een nieuwe ROM in de computer gezet hoeft te worden

Hier nog wat linkjes met wat extra achtergrondinformatie:

• exec.library/SetFunction() autodoc
• Een beetje achtergrond over de werking van SetFunction()
• posting op comp.sys.amiga.programmer over hoe SetFunction() werkt

Soms mis ik het wel een beetje de verbluffende eenvoud en kracht van de Amiga

De eerste Github commit die een Meme werd

https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac

...De eerste Github commit die een Meme werd. Scroll ver door om alles te zien

The principles of good programming

'The principles of good programming'. Een soort van 18 geboden

Sleepsort, O(N) sorting algorithm

Sleepsort O(N) sorting. Implementation in Python:

import threading, sys, time
def sorter(number):
    time.sleep(number/10.0)
    print number
for number in sys.argv[1:]:
    threading.Thread(target=sorter, args=(int(number),)).start()

Un-comment your code

Hoezo "schrijf commentaar in je source code!"??

Het probleem is dat code vaak verandert, en het updaten van commentaar gebeurt niet altijd. Tevens is het idee niet "je moet commentaar schrijven!" maar "je moet duidelijke code schrijven die mensen snappen!". Als dat kan zonder commentaar, doe dat dan.

Zie ook: Uncomment your code (slideshow door Miki Tebeka)

We take shortcuts and write comments (which is easy)

to explain obscure code instead of writing clear code (which is hard)

Problem is: code always gets updated, but comments only sometimes

So we get obscure code with outdated comments. Not the place we want to be.

En een fragment uit een recente thread op comp.lang.python:

Richard Parker:

My experience is that comments in Python are of relatively low usefulness. (For avoidance of doubt: not *zero* usefulness, merely low.)

Grant Edwards:

I've seen plenty of comments who's usefulness was not zero. It was less than zero.

Ikzelf:

Someone once taught me, "There is one thing worse than having no comments in the source code: having incorrect (or 'lying') comments in the code."

Grant, I guess you hint at such comments?

Grant Edwards:

Yes.

When trying to find a bug in code written by somebody else, I often first go through and delete all of the comments so as not to be mislead.

The comments reflect what the author thought the code did at some point in the past. What matters is what the code actually does at the present.

Iemand heeft het al gemaakt

Waarom lijkt het dat elke keer als ik een aardig idee heb, dat iemand anders het al gemaakt heeft

Een paar voorbeelden:

Ik werd een beetje gestoord van de verbose syntax van CSS files, en het probleem om kleurcodes consistent te houden daarin. Dus ik dacht dat kun je wel met een soort macro preprocessor verbeteren. En als je dan toch bezig bent, misschien ook wat programmeer constructies erin (b.v. berekeningen om breedtes uit te rekenen op basis van variabelen). Nou blijken er al een paar van dit soort tools te bestaan zoals SASS en LESS maar ik wilde iets simpels maken in Python. Blijkt dat er al zoiets is: CleverCSS. Enige nadeel dat deze heeft is dat het geen CSS syntax meer is, maar een abstractie, dus je moet nog weer een nieuwe syntax leren. Gelukkig is hij wel erg simpel.

Verder had ik het idee om een soort van fasttracker achtige muziek/drum sequencer te maken maar dan zonder GUI. Het idee was om in textfiles drum/muziek patterns vast te leggen en die dan realtime te laten afspelen. Wie schetst mijn verbazing toen ik vorige week BEATS tegenkwam, dat bijna precies hetgeen is wat ik voor ogen had! Twee dingen die me niet bevallen: 1) het is Ruby 2) het speelt niet realtime maar maakt een output file. Dus misschien dat ik nog iets ga proberen zelf in elkaar te zetten met Python :)