Hellre fåraherde

Woah de ska gifta sig!

2009-02-25T15:27:00.000-08:00

Hoppas att ironin i rubriken framgick iaf lite.

Idag åt jag lunch på Östra Station av alla ställen. Schysst hål i rymd-tid-väven med 50-tals-stuk på inredning, husmans och gubbar som faktiskt vissa förmodligen tror att det verkligen fortfarande är the good ole fifties.

Innan jag gick upp och åt min Mannerströmming (fick senare googla vem fan Mannerström kan tänkas vara och det visade sig vara nån kock), så shoppade jag efter lite lektyr i form av kvällstidning.

Jag borde inte köpa kvällstidningar, jag vet. Hela mitt jag föraktar denna hela-listan-av-farliga-födelsemärken-journalistik, men ibland faller jag till föga.

Dock inte idag. Idag var hela förstasidan på både A och E upptagen av två lyckliga ungdomar som bestämt sig för att slå sina säckar ihop. Inte nog med det. Nånstans i häraden av sidorna 2,3 4, 5 , 7-16, mitten och två extra bilagor.

Det blev DN istället. Med bara typ fyra sidor av eländet.

Jag har extremt svårt att förstå hela dealen. De ska gifta sig. Good for them. Men mitt liv påverkas inte alls. Jag har inget intresse överhuvudtaget.

Nu ska jag straffas månadervis med löpsedlar, tv-program, debatter där man funderar över om fanskapet ska få kallas prins eller inte.

I don't give a fuck. Och ärligt talat så är de enda som drar nån nytta av det här den värsta sortens skitmedia som i vanliga fall har scoop som Amy Winehouse hudproblem, Britneys trosor och Arnolds gubbtuttar på nån strand.

Monarkin borde avskaffas. I alla fall om man tänker på den stackars ovetande ofödda blivande avkomman som riskerar att få sin första fylla, första hångel, första misslyckade offentliga framträdande förevigat av vidriga gamar på Veckans Nu eller vad fan de kan tänkas heta.

Det bara underbygger min tes om att det värsta oket som kan tänkas läggas på en människa är kändisskap.

Bloggtoppen korrumperar

2009-02-20T15:28:00.000-08:00

Aaah. Har just tagit bort bloggtoppen-trackingen från sidan.

Ett steg på vägen i reningsbadet att frigöra mig från statistikens ok. Har tidigare varit inne fett många gånger och kollat hur många besök det varit. Också försökt luska i varför det gått bra en viss dag och försökt återskapa det genom att kommentera andra grejer på samma sajt som jag gjort då.

Vad trodde jag skulle hända? Det är ju för fan inget kommersiellt projekt - det är personlig terapi på ett offentligt plan.

Fast jag är fortfarande sucker för kommentarer - så pliiis, kommentera, uppmuntra, negga, skrik.

Between Topics

2009-02-20T15:04:00.000-08:00

Har just insett att mitt behov att negga kanske sträcker sig utanför mitt yrkesliv.
Jag utvecklas uppenbarligen som människa - varför skulle inte min blogg få göra detsamma?

Det är bara att inse när man ser på mitt track record vad gäller nya inlägg - när inriktningen på bloggen är systemutveckling och relaterade problem och negg, så tröttnar jag. Och ärligt talat, vem fan tror jag egentligen är intresserad?

Inte sagt att det inte blir nåt mer utvecklings-negg, men meet the new me: jag kan negga om allt!

Dessutom är det slut på alla patetiska försök att hora till sig uppmärksamhet genom att kommentera på andra forum och cross-länka och sån skit.

De som hittar hit är de utvalda få och så ska det förbli.

Off Topic

2009-02-20T10:44:00.000-08:00

Jag har blivit creationist. Jo, en av de där inskränkta jävlarna som tror att jorden skapades på sju dagar för 4000 år sen eller nåt.

Anledningen? Jo. Folk är så jävla fula.

Kolla själv på konsum, i tunnelbanan eller på lunch-restan.
Varenda en av de där skeva jävlarna med flyende haka, hängrövv och skepparkrans skulle alltså vara resultatet av 4 miljarder års sexuellt urval?

Smaka på det uttrycket 'sexuellt urval'. Efter fyra miljarder år borde vi för fan vara über-sexiga knullmonster. Men folk är fulare än stryk. Ergo - ingen evolution.

Istället - design. Fan vet hur intelligent dock.

Jag och Usama

2008-09-12T15:55:00.000-07:00

WTF?!? Fett mycket uppmärksamhet på nine-eleven (graf från bloggtoppen.se). Kan inte vara ett bra tecken. Kanske är det mrpi som lurat hit folk (se kommentar på förra inlägget). Tack i så fall, mrpi.

Skönt att någon hjälper mitt gnäll vidare ut i världen.

Personalities del 3

2008-09-09T11:32:00.000-07:00

OK, det jag nu beskriver kanske inte är så mycket en hel personlighet utan mer ett irriterande karaktärsdrag: att låta påskina att man hela tiden vet vad den andre skall säga.

Det är lite släkt med oskicket att ta äran för andras idéer, men här försöker man liksom få credit för nån annans idé redan innan man hört den, vilket är fett irri.

Scenario: Jag hade för ett tag sen kommit på en ganska briljant idé (jo, ibland händer det faktiskt!) för att fixa ett problem med buffring av meddelanden mot ett annat system - något som vi har haft en del problems med på senaste tiden.

Jag börjar dra idén för min kollega - låt oss kalla honom Greger (var kom det namnet ifrån?):

- Jo, Greger, jag tänkte att vi för att fixa problemet så kunde vi istället för att buffra alla...
- Ja! Jag vet vad du tänker säga!
- ...OK, jag tänkte vi dels kunde sätta ner TTL för....
- Precis, jag vet!
- ...och se till att vi bara buffrar...
- Ja just det!

Ok, ni ser mönstret. Vid det här laget har man liksom tappat sugen. Syftet är rimligen att få motparten att tro att alla möjliga idéer som nån annan kan tänkas komma med redan tänkts i Gregers mästerhjärna vid nåt tillfälle.

Nåväl. Häromdagen upprepar sig situationen. Jag ska dra en idé (om än inte lika briljant) om ett annat problem för Greger.

Skillnaden denna gång är att när han första gången avbryter mig och skriker att han vet vad som försiggår i min miniskula lilla patetiska hjärna, så synar jag bluffen:

-OK, Greger. Vad är det jag tänker säga?

Pinsam tystnad och nåt mummel om att "det är nåt med hummfrumm som vi...".

HA!

Nu kanske det dröjer innan han kör det tricket på mig i alla fall...

Mera Corporate Bullshit

2008-09-05T14:55:00.000-07:00

Kom just på lite mer saker som jag hatar med corporate bullshit-sajter. De har ofta bilder på kostym/dräkt-klädda unga skrattande människor politiskt korrekt av alla raser. Makes me wanna puke.

Och så har de nästan alltid blått i loggan och bakgrund. Jag börjar allvarligt tro att det inte är på riktigt utan att det är Satan själv som ligger bakom.

Corporate Bullshit

2008-09-05T14:11:00.000-07:00

Har suttit idag och researchat lite på nätet efter programvara vi behöver i projektet. Det är ganska så off-the-shelf vi behöver, men man vill ju veta vad man ska köpa och att man köper rätt.

Jag har gjort det förut och kommer göra det igen (försöka hitta vettig info om produkter alltså).

Sökning på nätet tillsammans med benägen hjälp av tips från kollegor om vilka produkter som gäller. Bara surfa dit och få no-nonsense beskrivning av programvaran. White papers som beskriver hur det används och hur man integrerar. Uppriktiga redogörelser för begränsningar och scenarion för vilka man faktiskt medger att produkten inte är lämpad.

As if.

"Fleekster Enterprise Edition (Gold) 4.2 allows you to leverage your Business Expertise by data mining your Enterprise giving unprecedented reporting and monitoring possibilites while maintaining data integrity and security over all your data sources. Internet, email, messaging, push and mobile channels allow for instant data awareness across your, and your partners' organizations. In fact, it will display business graphs on your pale hairy ass if you want it to."

En massa ord (ok, påhittade, men inte långt från verkligheten), men ingen information. Över huvud taget.

Det är så jävla avkönat så att det ofta inte ens går att förstå vad de säljer. Ens för nån som varit i branschen i decennier och letar efter just det deras programvara gör.

Vem har bestämt att det ska vara så? Hoppas de att nån kostymsnubbe ska köpa skitsnacket och bestämma att man ska köpa grisen i floskel-säcken?

Jag upprepar (för alla som vill lyssna): JAG FÖRSTÅR INTE VAD ERAN PRODUKT GÖR OCH VAD NI FÖRSÖKER SÄLJA!

Bifogar för säkerhets skull också den engelska versionen för att upplysa våra engelskspråkiga vänner:

I DON'T UNDERSTAND WHAT YOUR PRODUCT DOES AND WHAT YOU ARE TRYING TO SELL!

Och då tillhör jag ändå dem som (indirekt) bestämmer vilken programvara som skall köpas, så jag borde ju tillhöra målgruppen för dessa corporate bullshit-sajter.

Påminn mig förresten om att jag skall skalla alla som använder begreppet 'leverage'...

FRA

2008-08-15T11:38:00.000-07:00

Bara för att jag hållt käft på bloggen ett tag så betyder det inte att inte jag också kan snacka lite FRA. Sent ur startgroparna kan tyckas, men i alla fall.

Ungefär en vecka innan den olycksaliga lagen klubbades igenom försökte jag mig på lite direktdemokrati genom att maila ett urval av våra kära folkvalda för att försöka ingjuta lite folkvett och ryggrad hos dem. Jag cc:ade givetvis FRA:s generaldirektör Ingvar Åkesson så att han i lugn och ro, på kammaren, skulle kunna signalspana på mina mail även om serverparken inte snurrat igång ännu.

Reinfeldt låter ju som en repig skiva när han upprepar att lagens motståndare 'inte förstår' vad signalspaning innebär.

I så fall är vi i gott sällskap. En av riksdagsmännen (som iaf hade den goda smaken att inte svara med ett canned response, vilket de flesta gjorde), skrev bl a såhär:

... Sannolikheten att ett mejl från dig skulle fastna i FRA:s sökningar är så nära noll man kan komma - ÄVEN om du ägnade en hel vecka åt att försöka sätta ihop ett mejl som "fastnar"...

Hmm, antingen är det fullt med moroner på FRA som sitter och pillar sig i naveln. Eller också är det våra riksdagsmän som borde bli lite mer informerade.

Vad ska FRA spana på om inte innehållet i mailen? Givetvis kommer en del av spaningen innefatta en filtrering på en uppsättning nyckelord. Säkert också en hel massa andra kluriga algoritmer för att poängsätta mail på nån slags misstänkt-skala där de mest suspekta kommer granskas manuellt av nån 43-årig pot-bellied loser på FRA som aldrig riktigt blev av med sin acne.

Jag är nog rätt säker på att man skulle kunna fastna i nåt filter om man skickar lite jihad-mail mellan några yahoo-konton med arabisk-klingande användarnamn.

Sen sitter Federley och nästan gråter för att han fått smaka partipiskan. Vi har ju för f-n valt personer till riksdagen, inte partier. I annat fall skulle man ju kunna ha en person per parti och bara vikta rösterna efter valresultatet. Slut på pinsamma (för partierna) situationer där inte alla tycker som partiet.

Federley höll sen på att skita på sig av lycka när de 'tänkte om' och utsåg nåt nytt värdelöst tjänstemanna-organ som skall övervaka FRA. Då kunde han vika sig för partipiskan och slapp åka ur riksdagen och kanske faktiskt behöva söka ett riktigt jobb.

De här övervakarna över hemlige Ingvar och hans anhang kommer nog inte kunna uträtta så mycket misstänker jag. FRA:s verksamhet är ju det hemligaste som finns, så jag kan tänka mig att mötena kommer gå till ungefär så här:

Ingvar: Välkomna till juli månads möte mellan FRA och Datainspektionen

Övervakare: Hur går det egentligen till med spaningen rent tekniskt? Vad är det för begrepp ni filtrerar på? Vilka volymer av mail och annan kommunikation har blivit föremål för manuell inspektion? Har ni avvärjt några hot med hjälp av signalspaningen?

Ingvar: Nja, nu måste jag nog svara som jag gjorde vid vårt förra möte: Det är hemligt alltihop.

Övervakare: Ok, men lovar ni att ni inte gör nåt fuffens med all den här trafiken då?

Ingvar: Javisst lovar vi det. Precis som förra månaden.

Övervakare: Jahapp. Då får jag tacka så mycket, då.

Ingvar: Ja, tack själv för visat intresse!

Och vem vet? Den där kufiga snubben i din trappuppgång - han med den dåliga hyn och tveksamma hygienen. Du vet han som brukar öppna dörren bara en centimeter och stirra med ett blodsprängt öga när du är på väg upp till din lägenhet. Vem vet om inte det är vår FRA-loser som kan få för sig att privatspana lite på din trafik när ingen märker nåt.

Det är i alla fall säkert att ingen nånsin kommer få veta nåt om den saken...

No more AFK (Away From Keyboard)

2008-08-12T15:42:00.000-07:00

Hej igen.

Tröttnade av nån anledning på att blogga. Sen gick jag av en händelse alldeles nyligen in på bloggen och insåg att allt som stod där var precis som jag tycker! Briljant! (Kanske inte så förvånande när man betänker att det var jag som skrev det).

Nåväl. Jag måste se till att mina fans (alla nio) får vad de vill, så därför har jag beslutat att börja igen.

Inte utan problem dock. Eftersom man måste logga in med ett gmail-konto på denna bloggmotorn och jag, eftersom jag är paranoid, inte använder mitt riktiga konto så krävs det att man kommer ihåg sitt pseudo-konto.

Det gjorde jag inte, vilket fördröjde mitt återträde i bloggosfären (påminn mig förresten om att jag ska skalla alla som använder begreppet 'bloggosfären').

Till sist visade det sig att IE på min laptop kom ihåg mitt pseudo-username på gmail efter att jag gått igenom alfabetets bokstäver systematiskt. När det väl var klart var det bara att använda det universella slask-lösenordet så var jag back-in-business!

Sura nu inte för att jag inte hört av mig senaste tiden, utan var istället glad, säg emot, negga o bråka, för det är det jag tänker göra.

Code Review Part Two

2008-02-12T13:22:00.000-08:00

Kodgranskning är en vacker tanke och utförd regelbundet och med relativt korta mellanrum så blir det säkert en produktiv övning.

Alla kodgranskningar jag nånsin gjort eller varit utsatt för har varit one-offs, när nån chef får för sig att bedriva kvalitets-arbete.

Det är ju sällan så att nån ensam sitter och kodar årsvis och inte visar sin kod för nån - det är ju i princip alltid shared code ownership, så de andra i projektet är inne och pillar och fixar och det pågår såklart en ständig diskussion när man ser nåt tokigt nån gjort (för själv gör jag ju aldrig nåt tokigt ;-).

Tricket med kodgranskning är ju dock ofta att det kommer nån extern (=utanför projektet) och kikar på koden. Problemet som uppstår då är att det inte är rimligt att vederbörande läser all kod. Alternativen är stickprov, be utvecklarna plocka ut exempelkod, eller ta hjälp av nåt kodanalysverktyg som hittar skumheter i koden.

Det finns såklart svagheter med alla dessa approacher.

Alla system har sina ugly spots. Nästa kandidater för refactoring. De funkar, men koden ser för jävlig ut. Man kanske, för att spara fyra dagars utvecklingstid nån gång inför en release förra våren, la business-logik i en jsp-sida eller nåt. Man vet om det, man ska fixa det nån gång när man får tid.

Om stickprovaren hittar den koden så har man en del explaining to do. Om man själv får välja koden som skall reviewas så lär inte ful-bitarna komma med - alltså inte heller en representativ bild av systemet. Analysverktyg är bra och hittar död kod, tomma catchar och ostängda streams osv.

Problemet är att det kan bli väldigt mycket brus i rapporteringen från såna verktyg. Varningar ges ofta för saker som kan ses som kodstil snarare än suspekt kod (exempel är t ex huruvida man returnerar immutable collections, nåt som definitivt oftast är overkill utom i fallet då man bygger komponenter som skall användas av tredje part).

Ett annat problem är att man kan luras att lita på verktyget för mycket - en clean slate från analysverktyget ger en illusion av att allt är hunky-dory. Men den kan mycket väl släppa igenom en dylik kodsnutt skriven av nån projektmedlem (som borde skjutas):


public void criticalBusinessFunction() {
   try {
      // do a lot of stuff that definitely 
      // needs to be exception handled with care
   } catch(Throwable t) {
      t.printStackTrace();
   }
}

Det bästa är nog att göra kodgranskning till en del av ett projekt från första början - granska de tio första klasserna i projektet. Återkom sedan periodiskt för att sedan släppa projektet fritt när alla är överens om hur koden skall skrivas.

Ful-bitar i projekt finns alltid och är därför ok. Bör dock märkas upp med kommentarer som förklarar varför fulfixen finns och TODO:-markeras så att de snappas upp av din favorit-IDE.

Kodanalysverktyg skall användas från början och gärna köras som en del i continous builds (varför inte publicera resultatet på intranätet).

Kaos är kanske din granne?

2008-02-08T16:25:00.000-08:00

Yrkesmässigt så har jag bara funnits till i data-branschen. Från början till slut (inte slut, men nu) i ett ständigt tillstånd av kaos.

Ibland mindre kaos, ibland mer kaos än du skulle önska din KTH-polare-som-snodde-din-flickvän-på-tenta-puben.

Man undrar ju om livet i andra ingenjörs-vetenskaper är likadant. Är det kaos när man ska bygga en ny bro över Svartån i Örebro? Eller är det bara att använda vedertagna standarder, räkna lite på det och sen producera en ritning som den lokala byggaren omsätter i en stilig och hållfast bro?

Skillnaden i ett systemutvecklingsprojekt, om man fortsätter på bro-liknelsen, skulle kunna vara att man tre veckor innan leverans får veta att det måste gå att taxa trafikplan från den lokala flygplatsen över bron (= scope creep). Eller att skyltarna på bron måste visas i 15 språk beroende på var bilen som kör över den är registrerad.

Jag föreställer mig att bron över Svartån är mer lättspecad. Tyngden av bron plus max antal samtidiga fordon gånger pi eller nåt for safety. Rota upp nån gammal ritning över en liknande bro i Arboga, fippla lite i ett schysst CAD-verktyg och sen är man hemma.

Är det så? Har jag fel? Är det bara vi som bor i kaos? Jag uppmanar alla som jobbar med att designa broar att berätta hur det funkar i deras värld.

Code Review Part One

2008-02-08T16:13:00.000-08:00

En strip som träffar ganska rätt vad gäller kod-review: http://www.osnews.com/images/comics/wtfm.jpg

Société Degénérale

2008-01-29T14:46:00.000-08:00

Min första rubrik på franska! (och jo, "Degénérale" är menat som en ordvits...).

Har följt rapporteringen (http://www.svd.se/nyheter/utrikes/artikel_815041.svd) om mannen som sumpat 46 miljarder för den franska banken. Fyrtiosex tusen miljoner. I runda slängar en Ferrari 430 Scuderia om dagen i 63 år.

Alla hackar på den stackarn, men rimligen är det nåt ruttet i staten Danmark vad gäller övervakningen av dessa unga män i 30 000-kronors-kostymer som mäter sin manlighet i mätenheterna Rolex, Porsche och storleken på aktieaffärerna.

I en artikel (http://www.svd.se/nyheter/utrikes/artikel_807159.svd) står det att han "lyckades ta sig förbi de säkerhetssystem som banken satt upp". Hmm. Det måste ju ändå vara så att transaktionerna går att härleda till en viss person.

Man kan ju tro att det gått till så att vår käre vän Jerome Kerviel blivit fartblind; han har nog successivt ökat sin omsättning utan att nån slagit larm. Efter en tid känns säkert inte affärer i storleksordningen en miljard Euro som en big deal.

Man hade ju hoppats att följande konversation vid något tillfälle ägt rum på veckans personalmöte på Société Degénérale:

- Eh, bien. Låt se, denna vecka har vi en omsättning på Pierre på 650 000 Euro, Louise har omsatt 760 000 Euro. Olivier har tyvärr bara kommit upp i 270 000 Euro, skärpning Olivier.

- Oui, Monsieur Directeure.

- Bon. Sen har vi Jerome. Han har denna vecka omsatt 1800 000 000 Euro. Merde!

Inget sånt har uppenbarligen förekommit. Förmodligen en simpel rapport från trading-systemet som ingen brytt sig om att beställa.

Det går inte att förstå att de inte sett till att ha ordentlig övervakning av sina anställdas aktiviteter - speciellt i en bonusdriven ersättningsmiljö.

I alla fall är ansvaret delat mellan vår vän Jerome och de som ansvarar för säkerhet och övervakning på banken ifråga.

I värsta fall, och det är nog inte helt otroligt, kände ledningen till det och lät honom hållas så länge det gick bra. När kraschen kommer, så låter man Jerome smaka giljotin...

Ta steget?

2008-01-25T10:18:00.000-08:00

Satt idag och kodade ramverk för XML-ifiering av objekt som en del i ett projekt för en plattform vi ska använda inom organisationen.

Kul? Javars.
Gjort det förut? You bet. Inget nytt under solen. Visst finns det utmaningar, men det mesta har man sett förut och undviker därför tidigare pitfalls man trillat i (det är väl det som erfarenhet ger).

Blev jag gladare? Hmm. Det börjar snart bli dags att fundera på om jag ska fortsätta på utvecklarbanan och bli ett skägg eller ta steget till att bli nånslags chef (fast det känns inte riktigt rätt heller).

Talande är kanske att jag tycker det är roligare att rita streck och pilar och berätta för andra (=kodapor) hur saker och ting borde implementeras istället för att koda själv.

Kodar-mässigt är jag bättre än fler jag är sämre än - fast absolut ingen superkodare. Jag kommer inte att kläcka ur mig nästa 3D-motor för first-person-shooters eller nästa trådnings-stöd i Linux-kärnan. Det jag är vass på är att bygga på befintliga grejer och se helheten. Och det räcker för att tjäna ihop till blodpuddingen.

Det tråkiga med hela chefs-biten är att det finns ju få chefsjobb som inte innefattar personalansvar. Det brukar ju annars vara den karriärväg som erbjuds - från senior utvecklare till mellanchef med utvecklingssamtal, löneförhandlingar och snack med Nisse som har alkoholproblem.

Konstigt, det där. Ta en snubbe med vässad kompetens inom ett område och ge honom ett annat jobb (=mellanchef) för vilket han har nada utbildning, noll erfarenhet och tveksam entusiasm.

Det borde finnas fler jobb där man dompterar kodaporna (=ritar pilar och streck) men slipper MS Project, Gant-scheman, budgetar, personalplanering och utvecklingssamtal med folk man knappt känner.

Har du ett jobb som passar, så hör av dig...

Could have told you so

2008-01-20T10:54:00.000-08:00

Läste SvD om projektet GVD - Gemensam VårdDatabas (http://www.svd.se/opinion/brannpunkt/artikel_787511.svd)

En halv miljard bränd. 500 miljoner. 500 000 tusenlappar. Jag har sett det i ett liknande projekt jag själv var med i även om pengarna som brändes där kanske var en tiondel så mycket (fast 50 000 tusenlappar är ju också en slant).

Utan att veta ett skit om GVD förutom det jag läst i artikeln, så tror jag att jag har en bra idé om vad som gått snett:

Upphandling. Upphandling innebär såklart att den billigaste leverantören som uppfyller kriterierna skall göra jobbet. Det ställer dock enorma krav på de inblandade aktörerna. Att en leverantör kommer med en låg prislapp är knappast en garanti för att projektet skall lyckas (snarare tvärtom skulle jag vilja påstå).

Specning. Specningen måste vara immaculate för att det skall fungera. Upphandling innebär ju implicit en fastpris-approach och redan där har man byggt in en konflikt. I projektet jag var med i fanns det en diger spec. Diger i form av tjockleken på pärmen, kanske inte lika fyllig vad gäller innehållet. T ex specades rapportdelen sisåhär, och nu citerar jag: "Relevanta rapporter skall kunna genereras från systemet". Försök leverera till den specen i en fastpris-deal där beställaren försöker suga ut det yttersta och du som leverantör sätter klackarna i backen.

Integration. Från artikeln: "25 journalsystem av olika ålder och kvalitet". Hmm. Vi snackar säkert en härlig cocktail av system alltifrån nyutvecklat och stordatorsystem via OS/2 till Windows 3.1 med neandertal-version av Access. Helt säkert lösningar som evolverat patch-för-patch med features som styrs av semikolon-separerad data i fritextfält i databasen. En gränslös källa till problem.

Struts-mentalitet. Uppenbarligen har ledningen (som talande nog har slutat allihop enl artikeln) högaktningsfullt skitit i alla varningssignaler och istället snackat om hur bra det blir när visionen blir verklighet. As if.

Inkompetens. Jag tvivlar på att landets skarpaste hjärnor varit på plats när projektet planerades. Det finns såklart lagkrav (t ex att upphandling skall ske) som i viss mån bakbinder de inblandades möjligheter att styra projektets gång, men det är troligt att ingen från beställarsidan insåg att projektet, som det las fram, var i princip omöjligt att genomföra. Det är svårt att lägga skuld på leverantören i detta fall - det är ju inte deras sak att såga ett projekt för att det inte är genomförbart. Det enda resultatet är ju att det går till en annan leverantör.

Greed. Nu motsäger jag punkten ovan lite. Det finns självklart ett visst ansvar hos leverantören att backa ur om projektet inte är genomförbart. Här ser det ut som om de säkert insett att det här aldrig går att ro iland, men bedömt att de i alla fall kommer att få betalt för arbetet (=sno våra skattepengar). Så shame-on-you Oracle och WM-data.

Det som borde gjorts (och jag har såklart ingen aning om ifall det gjordes), är en förstudie som bedömde riskerna med projektet. Hade en bra sådan analys gjorts hade kanske vi kunde lagt 500 000 tusenlappar av våra skattepengar på äldrevård eller nåt annat nyttigt...

Personalities del 2

2008-01-19T08:29:00.000-08:00

Mera persönlichkeiten kommer här (läs den spännande första delen här: http://hellrefaraherde.blogspot.com/2008/01/personalities.html):

The Floater. En kille med teknisk kompetens, men inte tillräckligt för att kunna bidra effektivt till projektet. Börjar ofta som utvecklare, men får glida över till mer administrativa sysslor eftersom det han producerar i kodväg inte håller måttet. Plötsligt sitter The Floater som projektledare. Sen går det via mellanchef raka vägen upp i företagsledningen. Om fem år har han optioner, bonusprogram och tjänar dubbelt så mycket som du. Det är ju f-n att man är kompetent. Notera dock att det inte är en variant på 'skit flyter uppåt'-klyschan. Det är inget större fel på karln. Bara det att The Floater inte är tillräckligt vass för att faktiskt producera nåt produktionsmässigt.

The Bit Brain. Kan ibland överlappa med The Fresh Guy. Programmeringens motsvarighet till att ha gröna fingrar. Han gillar datorer och datorer gillar honom. The Bit Brain producerar reg expar lika fort som du skriver mail. Ovärderlig tillgång i projekt - det är alltid kvalitetskod producerad i rasande fart. The Bit Brain har sällan ambitioner att ta ledande roller och bestämma saker. Du måste mata honom med en spec.

Shit-for-brains. Ej att förväxla med The Slow Poke, som faktiskt ofta är kompetent. Shit-for-brains har helt enkelt inte begåvats tillräckligt förståndsmässigt för att kunna koda. Drar ner projektets produktivitet genom att ständigt behöva långrandiga förklaringar. De uppgifter som han får, efter ingående förklaringar komplett med pseudo-kod, blir alltmer triviala alltefter att han misslyckas med att leverera. Att få Shit-for-brains tilldelad till sitt projekt innebär dessutom att de som planerar resurser tycker att de har gett dig en ny resurs, vilket gör att du hamnar längst ner i prioritetslistan nästa gång resurser skall fördelas. Jag gillar svenska arbetsrättslagar, men det vore gött om man kunde få be security följa Shit-for-brains ut ur lokalerna bärandes på en papplåda med en krukväxt och fyra pärmar och personligen elda upp hans passerkort.

The Ego. Killen som har lite för hög uppfattning om sig själv och sina förmågor. Ofta kompetent, men inte i paritet med vad han låter påskina. En udda fågel i vårt svenska jante-landskap - lite typiskt amerikansk i sin framtoning. The Ego får en att gnissla tänder i tysthet när man hör honom gå på om hur saker och ting skall göras, gärna i möten med ledningen, när man själv läst hans mediokra kod och genomskådar the bullshit. The Ego har också ofta inga problem med att ta credit för andras idéer - något som får dig att vilja karva ut hans lever med en sked (ifall det är din idé han snor). The Ego går det såklart alltid bra för. De som bestämmer saker vet såklart inte att han är medioker utan sväljer hela grejen. De hör aldrig dina tänder som gnisslar...

Nu börjar jag få slut på karaktärer. Kanske återkommer i ämnet när jag funderat lite till på folk jag haft förmånen att jobba med.

Personalities

2008-01-18T16:32:00.000-08:00

Nu tänker jag försöka nagla ner karakteristika hos folk jag jobbat med. Alla har ju sina egenheter men vissa har fler.

The Fresh Guy - färsk från högskolan. Ivrig att lära. Ofta briljant kodare, men devoid of självförtroende. Inte sällan överglänser The Fresh Guy dig vad gäller regelrätt kodning. Du får lita till din erfarenhet och pondus (=kagge) för att hävda dig. Det funkar oftast väldigt bra eftersom The Fresh Guy saknar självförtroende och därför gärna undviker alla typer av beslut och överlåter det till dig. The Fresh Guy är en nära nog optimal tillgång i ditt projekt - produktiv, ambitiös och viker inte när det gäller att bygga tråkiga delar av systemet. Beware - The Fresh Guy kommer att försöka sno ditt jobb så fort han (eller tyvärr mer sällan hon) levlat lite på förtroendeskalan.

Pularen - ofta low-key kille (nu slutar jag lägga in tjej-brasklappar. Let's face it - det är bara grabbar i vår bransch). Säger inte mycket, men är alltid på jobbet. Kommer du in 7:22 så sitter Pularen där. När du går 17:56 så är Pularen där på sin plats och kommer så vara flera timmar till. Låt oss bara konstatera att det är Pularen som vet bäst hur man larmar på. Pularen levererar ofta bra (men vem fan skulle inte göra det om man jobbade 12 timmar om dan). Baksidan är det sociala - det är uppenbart nåt fel i huvet på Pularen, så det sociala samspelet med projektmedlemmarna blir lidande.

The Tech Guy - ultra-kompetent, ultra-insnöad. The Tech Guy har inget behov av sociala färdigheter. Root-login på samtliga miljöer smäller högre. The Tech Guy förstår inte att du inte har full kompetens på hans område. Det går aldrig upp för honom att du har andra prioriteter (typ bygga färdigt systemet). Att hantera The Tech Guy innebär att hålla honom nöjd (kom ihåg att han är ultra-kompetent ).

The Slow Poke - killen som inte tar för sig (om det inte gäller mormors-hosta-längd på 3-fikat). Ofta kompetent. Det som produceras håller bra kvalitet. Men det produceras inte mycket. Den ledande principen är att varje producerad kodrad kan betyda problem. Den rimligaste slutsatsen för The Slow Poke är att inte producera nån kod. Att hantera The Slow Poke är svårt. Regelrätt konfrontation kanske kan funka. Men sen kommer säkert facket och klagar på att arbetsgivaren vill att de anställda faktiskt ska jobba effektivt under arbetstid

Det är sent nu, så jag får fortsätta en annan dag...

Är du crappy?

2008-01-12T13:28:00.000-08:00

En ganska bra uppradning varningstecken på att du kanske är en crappy programmer:
http://damienkatz.net/2006/05/signs_youre_a_c.html

Complexity Killed the Cat

2008-01-11T15:35:00.000-08:00

Att utveckla system är en komplex verksamhet. Det ska fungera tekniskt, kommersiellt och användarna ska vara glada. Inte så att det krävs övermänniskor för att genomföra projekt, mer så att varje nytt projekt är så olikt det förra - det finns sällan ett facit.

Det känns som om risken att nåt ska gå snett och få ett projekt att gå i stöpet är så mycket större än möjligheten att det ska gå bra att det är helt magiskt att folk satsar pengar på systemutvecklingsprojekt. Det vittnar verkligen om människans obotliga optimism (och ofta också downright stupidity).

Nu menar jag inte att det är bara det tekniska som kan fallera. Riskerna är minst lika stora på business-planet.

Lek med tanken att alla de tiotals miljarder som brändes under IT-bubblan istället investerats i kort som vi alla vet är säkra (porr-, sprit- och vapenindustrierna), så hade de varit hundratals miljarder idag (jag förbehåller mig rätten att bortse från alla etiska implikationer ;).

Det finns såklart andra verksamheter som är så komplexa att det svindlar. Tänk t ex på det otroliga faktum att vi får en färsk nytryckt DN/SvD eller whatever i brevlådan varje dag. Ett journalistiskt (nåja inte alltid), tekniskt och logistiskt Labero-trick varje dag.

Skillnaden är att de utför samma trick varje dag. De har kunnat finslipa sitt projekt under årtionden och kan genomföra det med precision just för att det är same-old same-old varje dag.

Vi har sällan den lyxen.

Problemet är att själva kaoskomponenten i ett systems livscykel - från idé till fungerande system (eller kod i malpåse) - gör att det inte med framgång går att ta fram ett recept för hur man skall göra. Tumregler är det bästa vi kan hoppas på.

Och denna ovisshet går att slå mynt av. Det dyker oavbrutet upp folk som menar att de har svaret på alla frågor. Lösningen på alla problem. The silver bullet to rule them all...

Min tro är att tumregler är all we can hope for.

Det finns inte:

ett språk/miljö som löser alla problem
en metodik (vattenfall, scrum, xp, rup...) som passar alla utvecklingsprojekverktygsstöd
verktygsstöd (oavsett hur mycket man betalar) som gör projektet till en walk-in-the-park

En rimlig fråga är kanske 'Ge mig tumreglerna du jiddrar om, mannen?'.

Där kan jag inte ge nåt svar (jag vill ju inte vara killen med silverkulan)...

Det enda jag hoppas är att lite av min luttrade cyniska attityd kan smitta av sig lite lagom på alla entusiastiska oerfarna systemutvecklare out there.

Tänk efter innan ni hakar på the-most-recent-best-thing-since-sliced-bread, så slipper ni göra samma misstag som jag gjorde i min ungdom...

Success

2008-01-04T15:32:00.000-08:00

Vad är framgång för ett projekt?

Pengar givetvis. Vi gillar alla pengar. Dock är ju framgång ett djur med många personligheter (wow, going overboard with the liknelser där).

Frågar du projektledaren (=tid-, budgetstyrd), så handlar det om att leverera det som kunden frågat efter (dvs i princip leverera så mycket så att kunden kan övertalas att det räcker och därför ser sig tvungen att punga upp med stålarna).

Produktägaren vill se pengar över tid. Skit samma om fanskapet funkar som tänkt och byggdes på tid och pengar - nu ska det se till att dra in stålar också. Nya kunder och nya användare.

Ledningen sitter såklart och räknar pengar in och pengar ut (skit vore väl annars). Förhoppningsvis ser de också goodwill som ett värde; även om ett enskilt projekt/produkt går i stöpet av nån anledning, så kan kunden ändå tänkas beställa mer om projektet genomfördes på ett rätt och riktigt sätt.

Utvecklarna är nöjda i fallande ordning efter följande:

Systemet genererar inga problem som trillar ner så långt att jag behöver göra nåt
Systemet har användare
Systemet har glada användare
Systemet tjänar pengar

Notera att listan ovan gäller en luttrad utvecklare. En ung, oförstörd dito skulle kanske ha punkt 3 överst och punkt 1 längst ner.

Notera även att listan ovan gör en luttrad cyniker glad även om systemet aldrig kom i drift (ty ett system ej i drift genererar inga problem, se även http://hellrefaraherde.blogspot.com/2007/12/dlig-dag-p-jobbet.html).

Antalet problem som ett system genererar kan, i idealfallet, antas vara en linjär funktion av antalet användare.

Då utesluter man faktorer som att en dubbling av antalet användare kommer locka fram de där prestandaproblemen som ligger och lurar nånstans långt inne i buken på systemet; querysarna som funkar så fint i testmiljön, men som i verkligheten joinar de fetaste tabellerna i en 20 minuters full-table-search-fest.

Disk är billigt, det vet man. Raidade kanske inte lika. Vad man vet dock är att allt jävelskap loggar. Fett med gig med webserver-loggar (till 99,9999999 procent ointressanta, men man måste ju ha dem ifall det är nån som bråkar med systemet).

Backuperna på databasen måste såklart tas. Och sparas nånstans.

Rapporter måste filas på för att gå att köra i rimlig tid när datamängderna växer.

Kort sagt, ditt system blir som en trädgård du anlagt med gräs, fruktträds-yngel och buskar som sen gödslas och växer i en rasande takt så att du efter ett tag inte har tid att lägga ner häcksaxen ens för en kopp kaffe.

Resultatet blir att problemen växer med kvadraten på antalet användare.

Pengar kan antas växa linjärt med antalet kunder/användare på ett system.

See the problem here?

Eftersom man i slutändan (när man står framför Sankte Per?) mäts efter hur mycket pengar produkten drar in så kan man lakoniskt konstatera att om detta mått på framgång används (och vad annat vore rimligt), så gäller följande:

Om produkten blir riktigt framgångsrik så kommer du att sitta med arslet fullt, äta mer Losec än Kicki D äter falukorv och ha ett rätt ryckigt arbetsschema med nattmanglingar remote hemifrån).

Då är det dags att se till att man har ordentligt betalt eller att söka sig till greener pastures...

Scrumbled Eggs

2007-12-13T11:16:00.000-08:00

Vi kör ju Scrum. Såklart. Nåt annat (som inte på annat sätt är tillräckligt agilt typ XP) år 2007 vore som ta en helkväll på Stureplan iförd banlonpolo, terylene-byxor och helskägg - ganska bakåtsträvande/framstegsfientligt alltså.

Scrum hanterar i princip deadlines genom att säga 'den tredje november har vi release'. Vad som kommer med då är de högst prioriterade backlog items som vi hunnit med. Man har något körbart efter varje sprint som, i princip, kan tas i drift närsomhelst förutsatt att det iaf täcker in de mest basala (och högst prioriterade) backlog items som krävs för att systemet skall kunna ge nån affärsnytta.

I bästa fall får man kunden med sig på tåget genom att de inser att de kommer få ett bättre, mer ändamålsenligt system än om det utvecklas med mer traditionella metoder, gärna kryddat med en vag kravspec och framtaget till fastpris och med hård deadline.

Har suttit i mer än ett fastpris/vag kravspec/hård deadline-projekt och kan intyga att det tar fram de värsta sidorna hos människan. Kunden försöker knö in så mycket features som bara är möjligt givet den vaga kravspecen medan projektet stretar åt andra hållet och ledningen piskar utvecklarna till att jobba kväll och helg in absurdum.

Resultatet blir ofta minst ett av följande:

Kraschat projekt
Law suits och rättstvister
Pajade personliga relationer för de stackars utvecklarna
Brain drain på företaget när de utnyttjade stackarna flyr till grönare ängder
Total förtroendekris mellan kund och leverantör

Jag har suttit i ett projekt som prickade in fyra av de fem ovanstående punkterna (det blev aldrig law suit, men advokater togs in som lusläste kontrakt för att se om möjligheten fanns).

Så varför berättar jag då detta? Jo, vi som iaf officiellt höjer Scrum till skyarna har precis sålt in ett projekt till kund på fastpris, med vag kravspec och hård deadline.

Låt oss be till de högre makterna att det inte går som det brukar...

Läs mer om Scrum här: http://hellrefaraherde.blogspot.com/2007/11/15-minuter-daglig-masspsykos.html

Konflikträdsla

2007-12-12T10:06:00.000-08:00

Hur kan det komma sig att vuxna män (let's face it, det är mest Y-kromosomer i vår bransch) som utan att blinka droppar tabeller i produktionsdatabasen när så krävs, får en liten svettpärla i pannan när de får en konflikt i svn?

Så till den milda grad att de ger sig på att committa sina ändringar både på trunken och den branch vi fixar buggar på (och därmed bäddar för klart mer skumma mergningar senare).

Det är också de som får en osäkerhetsrynka i pannan när ändringar ska mergas mellan brancher.

Det är nåt med versionshantering som gör att folk regredierar till ett osäkert finnigt högstadietillstånd och med flackande blick väntar på att nån annan ska ta tag i det. När mergningar, commits och branchningar är det säkraste man kan hålla på med - gör man fel ber man bara "mamma svn" snällt att ta fram det man hade nyss. Det är det svn är bra på.

Testa att be mysql snällt att ta tillbaka tabellen du just droppade av misstag så märker du skillnaden...

Dålig dag på jobbet

2007-12-11T10:13:00.000-08:00

Hade en dålig dag på jobbet idag. Saker och ting går snett, vi får ta ner systemet oplanerat och får ett gäng arga användare och en del städa-upp-jobb i databasen.

Tänker nostalgiskt tillbaka på min tid i post-IT-bubble-Sverige. Det fanns fortfarande ett gäng företag som hade kvar pengar i sin säck från de galna dagarna då riskkapitalisterna kastade miljoner över vilken sunk-idé som helst. Har själv suttit med på ett möte med riskkapitalister i egenskap av tekniskt förkläde och hört dem kläcka ur sig att '35 miljoner? Vi går aldrig in med mindre än 50 miljoner' (företaget jag jobbade på hade räknat ut att de behövde 35 miljoner).

Att det var så ruggigt enkelt att äska pengar blev också indirekt the downfall för många projekt. Det måste vara det bästa sättet att ta död på ett företag: tvångsmata det med en gigantisk pengapåse (jag har sett det inifrån flera gånger). Sen mäts hur bra det går på hur snabbt stålarna rinner iväg, som om det fanns nån korrelation.

Det som egentligen betyder nåt - leverans - var helt underordnat. Detta ledde till (baserat på tron att botten på pengapåsen aldrig kommer dyka upp):

Hyreskontrakt mitt i stan på fett stor yta. Gärna bundet på 5 år så man helt säkert får sitta med ett osäljbart kontrakt i evigheter när hyresmarknaden viker.
Personalpyramiden (upp-och-ner-vänd). Ett järngäng på 5 utvecklare och sen en chefsorganisation värdig en tysk pansarkår. Inköpschef? självklart - det behövs såklart nån som köper fax-papper (detta var innan faxen var i princip helt utrotad) och pennor. Produktägare, marknadschef, säljchef, gruppchefer och fan och hans moster
Ingen leverans nånsin. Det mest inbitna vattenfallstänket möjligt med lång specfas och sen en implementation som sträcker sig över år. Eftersom ingen mätte framgång med nåt så påtagligt som en leverabel, så togs en dylik heller inte fram

Resultatet blev såklart det man borde ha kunnat se. Pengarna tar slut. Inget användbart har tagits fram. Företaget blöder som en gris från hyreskontrakt och onödig personal. Riskkapitalisterna drar öronen åt sig för att bubblan spruckit. De där 'bara' 25 miljonerna till som man räknat fram skall räcka kommer aldrig. Och sen varsel i omgångar och sen konkurs.

På plussidan måste framhållas den galghumor som utvecklas hos personalen, man har faktiskt ofta som roligast under den här tiden. Att man blir av med jobbet vet man ju redan så den tid man har kvar går åt till att snacka skit och utsätta kollegor för practical jokes.

Så varför blir jag då nostalgisk? Jo (i skenet av min dåliga dag på jobbet), så påminns jag om alla hyllkilometrar kod jag var med och skrev under denna galna tid. Kod som jag fick bra betalt för att skriva. Kod som aldrig nånsin kördes i produktion. Kod som aldrig nånsin ställde till med problem.

Eller för att travestera general William Tecumseh Sherman (1820-1891): The only good code is the dead code...

Fåraherde movin' up!

2007-12-08T08:51:00.001-08:00

Söker man på fåraherde på google.se så hamnar Hellre fåraherde på 5:e plats. Samma sökning på google.com renderar en 11:e plats.

Snart, om vi alla hjälps åt och cross-länkar, så kan vi ta den eftertraktade förstaplatsen för sökordet 'fåraherde'!

Moving up in the world!

Clusterfuck

2007-12-07T11:08:00.000-08:00

Ursäkta titeln (som faktiskt inte är snuskig, se http://www.urbandictionary.com/define.php?term=clusterfuck).

Det jag ska negga om idag är klustring. Möjligen går det ett sus i utvecklarleden när jag skriver detta (nåja, ett sus bland de typ 12 ynka själar som hittat hit).

Klustring är väl det vedertagna sättet att säkra skalbarhet?
Dissa inte klustring, len!

(eftersom jag redan börjat länka till ordlistesajter och din förortssvenska kanske är lika skral som min: http://sv.wikipedia.org/wiki/F%C3%B6rortssvensk_ordlista)

Alla har vi väl hört någon på tekniksidan säga (eller i värsta fall sagt själva) på ett möte där business case-killarna skissar på scenarier med 25000 samtidiga användare:
"Det är lugnt, vi klustrar lösningen och adderar bara noder för att skala. Vår applikationsserver stöder klustring och databasen med"

Det är här vi går på samma mina som management gör när grabbarna från Rational (se http://hellrefaraherde.blogspot.com/2007/11/uml-underliggande-megakomplext-elnde.html)

kommer och säljer in metodik och svindyra verktyg: Vi hugger på silver-bullet-wobblern som en vårpilsk gädda!

Vad gäller management så får de ett paket med verktyg och rigida dokumenteringsregler som ger en illusion av ordning och reda, effektiv utvecklingsprocess och ROI (påminn mig förresten att jag ska skalla alla som säger ROI i tid och otid - 'När kan vi få ROI på den här fitchjurn?')

Utvecklarna får en illusion av en lans med vilken den mest skrämmande av alla bestar - prestandaproblemen - kan dräpas.

Missförstå mig rätt - jag anser såklart inte att man ska ha en dunderburk till server som gör allt - självklart behövs lastdelning mellan maskiner med olika ansvarsområden och möjlighet att addera fler burkar när det behövs (och om det hjälper).

Skillnaden är då att man får en 'klustring' som är skräddarsydd för ditt system - en fast nyckel istället för en skiftnyckel (och som alla som testat vet, så spöar den fasta nyckeln skiftnyckeln every time)

Eller för att dra till med en annan liknelse - hur sugen är du på att köpa ett par unisex-byxor i one-size-fits-all-stretch? Låter inte optimalt...

Skiftnyckeln/byxorna i det här exemplet är din applikationsservers/databas/messaging engine eller whatever's inbyggda lösning för att klustra upp systemet i brygga. Den har säkert som fjäll i Feskekörka:

Kommit till främst för att tillfredsställa säljarna på produktföretagen som måste erbjuda klustring eftersom konkurrenterna har det
Blivit så generell att den inte löser något specifikt problem (dvs t ex ditt systems) bra
Blivit feature-bloated med distribuerade cachar, hot node deploying och fan och hans moster - inte ett öga torrt
Pga feature-bloatningen blivit helt omöjlig att konfigurera för en vanlig dödlig - specialkonsulter måste tas in för att vada i träsket med XML-config-filer

Ovanstående information och t ex en brasklapp om att inte alla system passar för att klustra med just applikationsserver X:s inbyggda klustringsstöd står ingenstans att finna.

T o m mysql har skitnödigt lagt till klustringsstöd som ingenstans marknadsförs som nåt annat än det bästa sen skivat bröd.

Vi gjorde ett testskott med ett mysql-kluster i ett projekt jag jobbade i förut.
Första setup (innan klustring):

Två servrar, en master och en replika som select-nod. Vi normaliserar prestanda på denna setup till 100%
Andra setup (med klustring):
Fyra servrar (minimalt mysql-kluster), samma applikation - Prestanda: 50%

Vi får en skalbarhetsfaktor på 4! Fast vänta... Åt fel håll. Hälften så snabbt med dubbelt så mycket hårdvara.

Hittade sen äntligen nåt obskyrt dokument på nätet som faktiskt erkände att mysql-klustring ställer en hel del krav på applikationens karaktär för att rocka. T ex gillar den inte joins så mycket. Då blir overheaden när servrarna pratar med varann så stor att systemet knäar.

Så om din applikation aldrig joinar tabeller utan bara gör uppslagningar på primary keys (fat chance) så kan mysql-klustring få din Volkswagen att bli en Porsche.

Men, vadå? Klustring funkar ju för världens mest använda gigantokluster Google?
Japp, men det gör det precis just för att de byggde en speciallösning för deras specifika behov, ett distribuerat operativsystem byggt enbart för snabb sökning och skalbarhet.

Hade de valt att sjösätta i WebLogic (eller insert valfri applikationsserver här) och klustra med deras stöd (vilken absurd tanke!) så skulle nog en google-fråga ge svar efter ett par kvartal istället för millisekunder...

Suboptimering

2007-12-06T07:55:00.000-08:00

Satt häromdan och peer-reviewade lite kod. En kollega hade gjort ungefär följande:

(om du inte är intresserad av detaljerna så räcker det med att sammanfatta med 'komplex och felbenägen', så kan du scrolla ner och läsa resten)

Skapat en klass som hette typ ValueCache vars syfte var att cacha 'semikonstanta' värden från databasen för att undvika databasåtkomster
ValueCache:n instansieras i class-loading-time, varför en speciell mekanism fanns implementerad för att undvika att den läste från databasen vid initiering, eftersom risken fanns att db-connection poolen inte alltid kunde antas vara igång vid den tidpunkten
Förra punkten innebär ju en risk att cachen är tom första gången nån frågar efter ett värde, så därför fanns en check som initierade cachen från databasen om den var tom
Cachen har en time-to-live efter vilken hela cachen läses om
Eftersom man då ibland joxar med hashmappen medan andra delar av systemet potentiellt läser samtidigt, så var anrättningen kryddad med synchronized-block till höger och vänster
En freakish detalj var att cachen själv kunde slå av sig om den inte funkade nåt bra. Om man ändrar ett value (som cachades i cachen själv) i runtime, så revertar cachen till att gå direkt mot databasen (dvs precis som innan tjogtals icke-triviala kodrader skrevs, med den skillnaden att alla trådar potentiellt måste köa i synchronized-blocken som lagts till)

Jag stirrade fåraktigt på koden som hade vuxit till en Behemoth från en i grunden (one could argue) sund tanke att cacha lite data för att minska databasåtkomster.

Testfallen var enkeltrådade (eftersom det ju är krångligt att skriva bra multitrådade testfall) vilket ju liksom förfelar hela syftet - det är ju först i en lastad multitrådad miljö cachen skulle kunna ha en positiv effekt och också då den visar om den inte funkar som den ska.

Här satt jag nu och tittade på en lösning på ett problem som inte fanns. Våra eventuella prestandaproblem kommer (och det vågar jag sätta en tusing på) inte bero på slagningar mot en tabell med namn-värde-par på ett par tjog rader (med index, no less).

Det vi snarare jobbar med prestandamässigt är att få IIS att serva content i tillräcklig fart vid hög last samt några queries som inte har ett jota med valuecachen att göra.

Min gissning är att (om vi inte rycker koden) och går live med lösningen, fortare än attan får använda avstängningsmekanismen och sen ha en bara lite sämre lösning än vi hade innan.

Koden riskerar att ligga kvar, lika död som en fallen gnu på stäppen. Alltför complex-looking för att nån annan, inte insatt, ska våga ta bort den eller ändra nåt (tar man bort den så kompilerar ju inte testfallet - hu så läskigt).

Slutsats (och det är ju en gammal sanning som verkar ha svårt att sjunka in hos folk):

OPTIMERA INTE
OM DU MÅSTE OPTIMERA - OPTIMERA RÄTT SAKER
OPTIMERA BARA SAKER SOM ÄR PROBLEM PÅ RIKTIGT OCH DÄR DET FINNS MÖJLIGHET ATT MÄTA INNAN OCH EFTER FÖR ATT SE ATT OPTIMERINGEN VERKLIGEN OPTIMERAT NÅT

Det finns en massa duktiga erfarna programmerare därute som räknar bytes och optimerar sina små uppslagningar i sina egna hemkokta datastrukturer med egna implementationer av B-träd.

Helt i onödan. Till gagn för ingen....

Caveat 1: Cachning funkar aldrig felfritt första gången du sjösätter det

Caveat 2: Komplex kod kan vara kul att skriva, men det är alltid den enkla lösningen som blir elegant

Better than Thou

2007-11-24T10:55:00.000-08:00

Återigen en engelsk titel, det bor uppenbarligen en liten Dolph i mig.

Ni har kanske råkat ut för den det här inlägget handlar om: idealisten, evangelisten. Då talar jag inte om alla de corporate evangelists det vimlar av från Sun och Microsoft främst, utan den verklige idealisten som har sett ljuset och sen inte kan låta bli att försöka sprida det till alla som vill (och efter ett tag inte vill) lyssna.

I mitt fall rörde det sig om Smalltalk. Alltså, det var Smalltalk som företeelse som var 'ljuset'. Och i min närhet fanns idealisten som höll Smalltalks fana högst i alla lägen.

Inget ont om Smalltalk och dess olika dialekter - mer OO-purism än så är svårt att tänka sig - allt är objekt - även klasser och integers (1+2 innebär att man skickar meddelandet '+' till objektet 1 med parameter objektet '2'). Para det med grymma utvecklingsmiljöer och en varm och cosy feeling som bara Smalltalk kan ge och man har en vinnande kombination. Eller?

Problemet kommer när man skall jobba kommersiellt tillsammans med idealisten. Kommersiellt innebär att man skall jobba för pengar som nån känner sig villig att hosta upp.

Det innebär ofta också att man ska jobba i ett team tillsammans med folk som har kompetens på den valda plattformen (och den valda plattformen är en kommersiellt gångbar plattform = inte Smalltalk).

Smalltalk hade kunnat vara vad Java och C# är idag - preferred choice of språk och utvecklingsmiljö för bulken av alla nystartade utvecklingsprojekt.

Det är som sagt squeaky (förlåt vitsen) clean vad gäller objektorientering. Det saknar också den ofta (enligt min mening) onödiga statiska typningen i Java/C++/C#.

Helt enkelt en produktiv miljö second to none.

Men, marknadens vägar äro outgrundliga, eller snarare beroende av smarta marknadsförare med stora pengasäckar i bakfickan (läs Sun, Microsoft).

Hade det funnits en dylik pengasäck bakom marknadsföring av Smalltalk på den tiden då Javas showcase var vinkande tomte-appleten, så hade Sun kunnat lägga ner den satsningen.

Då var Smalltalk sedan länge redan moget och hade bevisat vad det gick för (det var under en period ganska stort i USA som plattform för t ex banksystem och administrativa system).

Resultatet av den frånvarande marknadsföringspengapåsen är att det inte finns nån marknad (i alla fall inte i Sverige) för Smalltalk.

Då återkommer vi till problemet med idealisten. Att sitta i projekt med honom (i en kommersiellt gångbar miljö) blir en evig whine-fest.
"Aaargh. I Smalltalk hade det varit mycket enklare".
"Varför tycker alla Java/C#/C++-människor att det är så j-a bra. Det suger ju jämfört med Smalltalk".

Kort sagt ingen rolig person att dela skyttegrav med.

Och omöjlig (eftersom han är en idealist) att få att inse att det handlar om stålar. Den bästa teknologin vinner inte - det är den med mest buzz som vinner och på den fronten står sig Smalltalk slätt.

Jag älskar idealister - må de sprida sina tankar och visioner till massorna i evig tid - bara jag slipper sitta i samma projekt som dem...

Singing along with the Choir

2007-11-22T15:40:00.000-08:00

När jag ser tillbaka på mina inlägg hittills har de, till största delen, drupit av negg.

Uppenbarligen har en det öppnats en ventil, ett utlopp genom vilket jag kan negga om företeelser i systemutvecklingsbranschen.

Därför känns det jobbigt att, i strid med tidigare inlägg, verkligen plussa nåt:

Test-driven utveckling

När man insett storheten finns det inget sätt att vända åter. Att köra utan är samma känsla som att cykla mitt i stan (bilar är hårdare än människor) utan cykelhjälm (om man nu haft det alltid i 10 år (ja, jag är en farbror)).

Osäkert - minus frihetskänslan man får med vinden i håret.

Processen är solklar:

få en spec på en ny feature

skriv ett testfall som testar din nya feature

kör testfallet

Testa om det funkar. Om ja - avbryt

Ändra/bygg om tills du tror att det funkar

Gå till punkt 4 - lather, rinse, repeat!

Om alla gjorde så skulle världen be a better place...

Stating the Bleeding Obvious

2007-11-21T09:49:00.000-08:00

Jag har tidigare redovisat min personliga taxonomi över svenska utvecklingsbloggar (Someone else's News), men måste nu tillfoga en ny - The Bleeding Obvious-bloggen.

En dylik blog handlar om nåt extremt basalt och har lägre höjd än Nederländerna.

Nu kanske jag svär i kyrkan när jag pekar ut en medbloggare som hemmahörande i denna kategori, men den ligger 11:a på http://bloggtoppen.se (Data/IT), så så jävla synd är det inte om honom: http://www.svensk-server.info/

Det gick dessutom inte att kommentera utan att registrera sig först (och som jag har längtat efter ett membership på svensk-server.info - not), så han får finna sig i att jag gnäller här istf på hans blog.

Den första artikeln har the groundbreaking title HTML Dokument (jo det var utan bindestreck) och redovisar hur man ska använda bla <html>-taggen...

En blick på en bra html cheat sheet site (t ex http://www.psacake.com/web/dy.asp) ger massor mer info befriat från särskrivningar och putslustiga kommentarer.

Ibland önskar man att det inte var riktigt så enkelt att publicera saker på webben. Hade det bara varit lite svårare så hade vi sluppit en hel del bleeding obvious skräp producerat av medelmåttor...

Bjarne Spilling the Beans

2007-11-20T15:25:00.001-08:00

No Java pun intended (beans alltså).

Lyckades leta reda på den här intervjun som jag minns att jag läste för ett tag sen:

http://members.safe-t.net/jwalker/programming/interview.html (not working anymore)
http://artlung.com/smorgasborg/Invention_of_Cplusplus.shtml

Bjarne Stroustrup (mr C++ för oinvigda läsare) berättar vad han egentligen tycker om sin kreation.

Den bekräftar vad jag tyckt väldigt länge: C++ är datavärldens motsvarighet till att skruva i en spik med en fogsvans - du kommer slinta och såga dig i benet.

Det är ju faktiskt så att C++ nog inte är rätt verktyg nånsin; ska du skriva ett operativsystem eller drivrutiner så vill du inte ha overheaden som OO innebär med t ex traversering av funktionspekararrayer för att hitta rätt implementation - du väljer good ole' C istället.

Ska du bygga vilken-annan-applikation-som-helst så vill man ju ha:

bounds checking
garbage collect
ett språk som inte på ett så uppenbart sätt inbjuder till att skjuta sig själv i foten med

Hoppsan. Hamnade nästan in i en språk A är bättre än språk B-rant och sånt är ju aldrig roligt.

Roligt är det däremot när folk säger sanningar som man förvånas av.

Stå på dig, Bjarne. Tell it like it is...

Four Letter Word

2007-11-20T14:32:00.000-08:00

Påminn mig att jag ska skalla alla som använder ordet 'agil' i svenska språket.

Det är inte ett ord, har inte varit ett ord och kommer inte bli ett ord på svenska.

Det är nog irriterande med agile hit och agile dit på engelska.

15 minuter daglig masspsykos

2007-11-20T13:51:00.000-08:00

Varje morgon kl 09:00 samlas Sveriges alla (nåja majoriteten känns det som i alla fall) systemutvecklare i små grupper om 5 - 15 pers, berättar vad de gjort den senaste dagen och vad de tänker göra idag.

Nej, det är inte improviserade AA-möten som utspelar sig på landets alla IT-arbetsplatser. Det är såklart Scrum.

Inte nånsin har jag varit med om att någon metod/metodik/metodologi har fått en sån fullständig impact på så kort tid. Från att knappt ha hört talas om fanskapet till att folk inte gärna sitter bredvid en på tunnelbanan om man inte är Certified Scrum Master.

Det är inte så att jag tycker det är dåligt eller så, men jag blir alltid skeptisk när nåt nästan övergår i religion. "Vad säger Scrum att man ska göra i den här situationen" som om Scrum-väsenet tryckte i nåt dammigt hörn i konferensrummet och hade nåt viktigt att dela med sig av.

Backlogen är helig (ordet backlog betyder väl egentligen saker man borde gjort men inte hunnit. I Scrum (helgat varde dess namn) så är nåt man precis kommit på en backlog item (alltså nåt man redan borde gjort fast man precis kom på det)). Snacka om att ge Losec-marknaden en extra skjuts.

Finns det inte i sprinten så ska man inte göra det. Tanken är sund; isolera utvecklings-teamet från den yttre världens alla krav-glidningar och scope creeps. Sprinten blir ett 300 DPS Sword of Scope Defence som teamet kan vifta med när de bakåtslickade frisyrerna kommer och försöker få in lite features som kan hjälpa dem att kränga skiten till nån ny kund.

Problemet kommer då man inser att man faktiskt inte får med allt man verkligen gör i backlogen och senare i sprintarna. Man ser ut som en lat jävel när det visar sig att man har en sprint-velocity som Micke Persbrandt på väg hem från krogen.

Sprintplaneringen blir också en speciell upplevelse eftersom det (vad jag vet) inte finns nåt utrymme (=tidpunkt, dedikerad tid) egentligen för att _speca_ en backlog item. Den är oftast på formen 'Användaren ska kunna skicka meddelanden till andra och notifieras när han får ett meddelande sänt till sig'.
Spec behövs minst på områdena Info-design, databasdesign, protokollnivå, kravbild (ska t ex användaren kunna lägga upp nån på en ignore-list? Framgår inte av backlog-itemet).

Urspungskravet kommer ju oftast från nån som inte håller på med implementation och därför inte kan antas kunna speca på den nivån (eller ens veta att det behöver specas på den nivån).

Vad det hela kokar ner till är att man försöker tidsskatta i princip helt ospecade krav. Under upp-taskningen sker ju nån slags specning, men det sker inför hela gruppen och blir frustrerande efter fyra-och-en-halv timme, let me tell you.

Vet inte om det bara är jag som upplevt det, men det verkar som om Scrum (oh, herde på livets stig), inte riktigt tycker att man ska speca (= en (eller ett par tre) person(er) samlas, ritar pilar och streck, kommer överens och skriver ihop ett snärtigt dokument på 1-1,5 A4 som beskriver hur implementationen skall gå till).

Speca är fult. Luktar vattenfalls-modellen och gammal död hud. Fast där nånstans brister illusionen lite.

Behold, the revolting underbelly of Scrum...

Pärlor för ingen?

2007-11-17T17:10:00.000-08:00

Inser plötsligt att det jag jobbar med (och skriver om i den här bloggen) kanske intresserar ungefär en promille av Sveriges befolkning.

Det kanske kan översättas till en promille av en promille av världens befolkning, eftersom intresset för utveckling av datasystem (eller snarare nån som gnäller om detsamma) kan antas avta med kvadraten på risken att dö i svält/hamna i husarrest i Öst-Timor/få fågel-influensa/hamna under vatten pga växthuseffekten... etc you name it.

Är det då värt det? Hittills har ingen. Och jag menar _ingen_ hittat min blog. Inga kommentarer har reggats (utom mina egna patetiska). Jag skulle lika gärna kunna vara den sista utvecklar-gnäll-bloggen på jorden. Tänk er den filmen. 'Utvecklar-gnäll-bloggarnas planet'. På slutet hittar de frihetsgudinnan i sanden med the collective works of Donald Knuth under armen.

Sad sad developer.

Someone else's News

2007-11-17T14:30:00.000-08:00

Har ni nyligen läst svenska bloggar om systemveckling? Då har ni kanske märkt att de ofta är på nån av formerna:

"Har ni hört att Freakalizer (påhittad hajpad teknologi red. anm.) nu kommer i version 3.2? Det är jätteintressant och de har bland annat lovat högre prestanda och bättre interoperabilitet och antigravitationsflänsar. Cool! Can't wait to try it out!"
"Det är jättesvårt att välja mellan alla standarder och produkter som kommer. Och nu kommer alltså Freakalizer 3.2 som inte gör det lättare att välja, särskilt som MastaSoft precis släppt sin DudeMaster 6.2 i dagarna"
"Jag har testat Freakalizer 3.2 och gjort en test app som skriver ut 'Hello World'. Källkod finns att ladda ner. Jag är ju inte nån erfaren Freakalizer-utvecklare så jag har ju bara testat lite och här är vad jag tycker."

Alltså en av följande:

Halleluja-bloggen

Väljer ett spår (t ex Java, .Net eller Ruby/Rails t ex) och väljer sedan ut nyheter som sen helt okritiskt presenteras som 'mycket intressanta'.

Bloggaren utmålar sig själv som nån som nästan maniskt kastar sig över vilken alfa-release som helst som släppts av nån håglös open source-utvecklare bara det hamnar inom träffområdet för bloggens inriktning.

Detta är ofta fallet för bloggar som är show cases för företag (eller för enskilda konsulter som försöker profilera sig inom vissa områden). Konsultföretag har gärna teknikbloggar, men innehållet är så streamlined och devoid of personliga tyck och tänk för att undvika att (Gud förbjude) någon presumtiv kund skulle bli upprörd och låta bli att köpa företagets tjänster.

För oss som inte genomgått lobotomi så är detta uppenbart efter att ha läst ett par rader och därefter faller såklart hela bloggen.

Räkna-upp-alternativ-bloggen

Tar inte ställning. Försöker att täcka in området genom att räkna upp alla möjliga alternativ. Ger inte mer kött på benen än en tio minuters session med Google. Why bother? Tyck för fan nånting!

Jag-bara-testar-bloggen

Tycker att det räcker med att fluffigt beskriva den nya teknologin. Ursäktar sig hela tiden med att han/hon inte är expert, men kläcker ändå ur sig lite useless code som inte åstadkommer nåt, men finns att ladda ner!

Jag vägrar att läsa ytterligare en blog där mänskan inte påstår sig kunna det han skriver om!

Skriv för f-n om nåt du kan (eller ta reda på mer så att du kan det du vill skriva om)! Livet är för kort för bortförklaringar.

Pidgeon Swedish

2007-11-17T10:31:00.000-08:00

Tänkte hitta lite enkla sätt att marknadsföra min blog och googlade på 'blog java' - 'visa svenska sidor' (tanken var självklart att helt utan skam svara på nåt halvtrist inlägg och bifoga min blog-address (cross-linking rules!)).

Hamnade dock på "Enkel tanken Java & Spindelväv Teknologien Blog" på sajten som kallar sig för "Simple Thoughts - Enkel lösandet för komplex problemen". En hilarious babelfish-approach till Java-utveckling.

Rekommenderas.

Bland pärlorna finns "Hur Till Möjliggöra Befästa (SSL) IMAP & POP3 Med ( fri) Jag- Undertecknat Intyg" och t ex "Hur Till Skapa Jag- Undertecknat Intyg"

Priceless...

Här är länken: http://blog.taragana.com/index.php/sv/

UML - Underliggande Megakomplext eLände

2007-11-17T09:25:00.000-08:00

UML - the Entreprisest of them all.

Här har vi nåt som verkligen faller management i smaken. En rigid struktur av dokument, och diagram som specificerar systemet. En illusion av ordning, struktur och specifikation som får alla i beslutsfattande position att komma i brallan.

Optimalt skall man köpa in Rationals verktyg för en förmögenhet och sen ska man börja med, håll i er nu, ett projekt för att modifiera RUP (Right UP your ass) att passa det projekt man för tillfället skall bygga.

Rational har också (i enlighet med teoremet 'Management ska komma i brallan') låtit antyda att det är möjligt att, håll i er igen nu, grafiskt rita systemet i deras astronomically overpriced system och sen trycka på 'generate'-knappen och - vips!- så är systemet där. Färdigt att deployas och köras.

Hur har de då lyckats med detta? Jo, genom att sälja where the wallet is. Hos management. Kostymer möter kostymer och kommer överens om vad som ska gälla som strategi vad gäller systemutveckling. RUP/UML blir ett stridsrop, ett sätt att visa att 'vi har minsann ett enat grepp om systemutveckling'. Notera ingen inblanding av nån som faktiskt fattar nåt om systemutveckling (arkitekter, utvecklare).

Enter The Consultant. The Consultant har för länge sen slutat bry sig om vad som egentligen gör att systemutvecklingsprojekt blir framgångsrika. Istället har han (eller mer sällan hon) koncentrerat sig på att pricka in lämpliga buzzword technologies och methodologies.

Eftersom ingen in-house-utvecklare med självrespekt nånsin kikat åt RUP som lösningen på nåt (utom möjligen för att skriva ut specen ifall pappret är slut på muggen), så måste man ta in The Consultant för att ta fram en RUP-mod som passar projektet och införa den.

Resultatet blir en mängd dokument (artefakter som de j-a freaksen kallar't) som ingen nånsin läser. Undrar hur många hektar regnskog som gått åt i den dokument-bonanza som RUP/UML innebär.

On a side note så är själva grundtänket fel med UML vad gäller objektmodellering - det fokuserar på arvshierarki istället för objektmodell. Arvshierarki är bara kodhygien - hur objekten hänger ihop är det som är intressant.

Well, well. Para RUP med en hajpad Enterprise-technology of your choice (t ex den här: Följa John), och resultatet låter vänta på sig (resultatet i form av ett användbart system alltså).

Den som nöjt kan dra sig tillbaka efter projektets downfall är The Consultant, med 1200 kronor i timman i 1000 timmar och en ny entry i sin CV - klar för nästa uppdrag...

När mönster blir monster

2007-11-17T08:12:00.000-08:00

Boken Design Patterns av Gang of Four har varit och är required reading för utvecklare av alla slags system. Tanken är bländande - best practices abstraherade och nerkokade till en bukett av pärlor att plocka ur när man bygger sin applikation (ursäkta ett något utflippat bildspråk ("bukett av pärlor"?)).

Problemet uppstår när vi vanliga dödliga börjar gå loss i denna bukett. Exemplen är legio på när ett ordinärt order-lager-inköps-system (substituera mot valfri vanilla-applikation) blir en orgie i patterns.

Många av de mer basala patternsarna (heter det så?) är inte så svåra att knö in i ditt system. Kanske lite Composite, lite Delegate osv. Man får blodad tand. Lite Decorator ovanpå det här (lite krystat i order-lager-inköps-systemet, men what-the-heck).

The mother-of-all-patterns-you-don't-need: Factory ligger sen nära till hands. Och vad är en Factory utan en FactoryManager (som gärna ska instansiera sig från XML).

Rätt vad det är så har man slutat bygga systemet och börjat "The Race of Patterns". Det gäller att få med så många som möjligt. Flest patterns när man dör vinner.

Har vid tillfälle suttit med underhåll av ett system som var byggt på detta vis. En ordinär web request routades genom dispatchers, handlers och delegates så att inte ett öga var torrt. Detta ledde också till att (som ni kanske gissat) 80% av applikationen bestod av infrastruktur för att stödja alla dessa design patterns. Själva business-logiken var gömd långt inne i nån handler nånstans och det var i princip omöjligt (ok, nu tar jag i lite) att avgöra var man skulle hamna för ett givet anrop.
Att fixa buggar och lägga till funktionalitet blev också lite av en bygg-deploy-starta-håll-för-ögonen-övning eftersom man säkert som amen i kyrkan glömt att haka in sin nya handler i nån obskyr XML-fil.

Missförstå mig rätt - patterns rockar, men bara då dom verkligen behövs. Alltför ofta är det ingen som gör en rimlighetsanalys innan man tillför en eller ett par extra nivåer av indirection för att stödja ett till pattern - och kunna bocka av det i boken Design Patterns.

Såpa är bäst på TV

2007-11-17T07:19:00.000-08:00

Jag ska försöka att inte bara negga, men en nystartad blog kommer liksom ofta från ett inneboende behov att negga - nåt man kanske inte vill eller kan göra som 'representant' för ett företag eller ens när man skyltar med sitt eget namn. Vem vet var jag hamnar i framtiden där de tycker att teknologi X är the new black och då kan det ligga mig i fatet om jag har neggat upp X i brygga under mitt eget namn. Men, men - here goes nothing.

SOAP. Simple Object Access Protocol. Faller på första ordet som utgör "S" i dess akronym. Simple, I think not. Sällan har så många name spaces, externt deklarerade entiteter och dylikt samsats i en och samma XML-blobba som i ett ordinärt SOAP-meddelande.
Testa att skicka ett SOAP-meddelande med texten 'Hello World' till en intet ont anande mottagare och förundras sedan över hur detta meddelande kunde bli 3016 bytes långt (har inte räknat bytesen i just detta exempel, men ni förstår vad jag menar).

SOAPs styrka ligger i WSDL, dvs formatet för att beskriva ett protokoll (alltså vilka tjänster som finns i en web service och hur meddelandena är strukturerade). Det är barnsligt enkelt att definiera en web service i WSDL och generera en handler-klass som sen pratar med web-tjänsten ifråga med ett enkelt vanligt anrop med typade parametrar. Så långt allt väl.

Problemet uppstår när man försöker t ex köra igenom en rimligt strid ström av meddelanden och man inser att de informationsbärande bytesen man skickar ligger nånstans runt 5% av junket man skickar. Overhead är bara förnamnet.
Dessutom är min erfarenhet att messaging mellan system är något som är väldigt specifikt; man diskuterar ett API, kommer överens om format och dylikt och utvecklar det hela. Vid förändringar så måste självklart båda sidor byggas om. Behovet av att ha referenser till XML schemas för validering och namespaces för att undvika krockar måste i rimlighetens namn höra till de extrema undantagen.
Detta suger bandbredd och CPU till den milda grad att det i princip är helt oanvändbart, ja rent ut sagt oansvarigt, att använda SOAP i de allra flesta fall.

Ett Simple Object Access Protocol (över HTTP) bör tillåta:

GET-baserade anrop (skit i indempotensen). För ostrukturerad data t ex ett id, kör webtjänsten med get och en url-parameter. Går dessutom utomordentligt att provköra i browsern
POST-baserade anrop för mer strukturerad data (t ex resultatet av ett inmatat formulär)
Lean and mean XML-representation av ett objekt:


<user>
<username>leif</username>
<mailaddress>leif@leif.com</mailaddress>
</user>

Ett dylikt webservice-ramverk langar man ihop på en eftermiddag (nåja) - satisfaction guaranteed!

Följa John

2007-11-17T06:24:00.000-08:00

Jag har varit så pass länge i systemutvecklingsbranschen att jag insett ett par saker.

There is no silver bullet
Om något pushas som det bästa sen sliced bread så är det nåt grundläggande fel nånstans
Det är (faktiskt) inte alltid fel att uppfinna hjulet igen (eller kanske inte hjulet, men kanske chassit, karossen och inredningen för att fortsätta på den något krystade bil-liknelsen)

Låt mig ta några exempel. Jag tillhör, måste jag erkänna, dem som svalde krok, lina och fiskespö när J2EE-tåget lanserades med buller och bång på senare delen av 90-talet.
Här kom en spec, en standard som skulle lösa alla mina problem - persistens, distribuerade lösningar, messaging och en hel massa annat. Sun, i sin oändliga vishet, publicerade en "show case"-app i form av "pet store" full av
J2EE-patterns att använda för intet ont anande utvecklare världen över.
Inte nog med det - "Enterprise" i namnet gjorde att management i tusentals företag också svalde betet. Att använda J2EE blev ett slags kvalitetsstämpel; en garant för att lösningen var byggd på solid grund, lätt att underhålla och skala upp.

Hej vad vi alla bedrog oss. Om man bara hade använt sin (iofs på den tiden betydligt kortare) erfarenhet och utbildning och verkligen läst specen istället för att kasta sig över ett kodexempel och med ett fånigt flin på läpparna sjösätta sin första Entity Bean i nån mer än lovligt buggig och seg 'container'.

Vad som framgår som pinsamt tydligt nu i ett förklarat ljus är att J2EE-specen var ett typiskt 'Design by Commitee' piece of crap. En kopp komplexitet tillsammans med fyra liter configuration i form av XML och sex matskedar magi - vad containern har för sig under huven visste man inte riktigt (och det var ju inte meningen att man skulle behöva veta det heller). Lycka till förresten med att sätta en debug-stopp långt inne i JBoss mitt i nån ConfigurationFactoryManagerFactory eller nåt som är i full färd med att instansiera sig själv utifrån nån vidrig XML-blobba.

Applikationerna blev precis det motsatta mot vad som utlovades:

Skalbarhet - my ass. Nåt segare än en J2EE-applikation med Entity Beans går inte att uppbringa. Det är datavärldens motsvarighet till en bil med prestanda från en Trabant och komplexitet hos en Ferrari F1
Maintainability - tanken var att eftersom allt var byggt efter en enhetlig spec skulle man kunna byta utvecklare i ett projekt lika ofta som man byter kalsonger. Vem som helst skulle kunna kliva in och vara produktiv på en gång. Detta föll genast eftersom alla var tvungna att kringgå den vidriga specen med hembyggda lösningar (som ofta blev mer eller mindre de facto patterns för J2EE-utveckling) som t ex "fast lane" (dvs gå direkt med JDBC mot databasen för att göra saker som inte gick att göra med J2EE (som att läsa upp fler än 10 objekt t ex (hmm, ett persistensramverk som inte fixar att läsa upp ett tjog objekt eller så från databasen borde ju fått folk att tänka efter)))
En tredjeparts-marknad med färdiga komponenter färdiga att bara drag-and-droppa in i din container och vips så funkar allt! Att bygga ett system skulle bara kräva en systemdesigner (gärna i kostym) som i samråd med beställaren grafiskt drar-och-släpper komponenter i en grafisk högnivå-utvecklingsmiljö. En luttrad utvecklare inser kanske att det är omöjligt att t ex komma fram till en generell definition av ett så basalt begrepp som 'användare'. Vissa system behöver user name och mail address, medan andra behöver längd i cm och hårfärg. Marknaden för tredjepartskomponenter blir snabbt begränsad till komponenter för typisk generell funktionalitet - mail-skickning, och messaging t ex

De enda som drar nytta av eländet är företag som säljer J2EE-containers och de som konsultar i ämnet. Mest de som gör bådadera, t ex säljer en vidrigt komplex container (läs WebLogic) och sen säljer vidrigt dyra konsulttimmar för att röja upp i de katastrofprojekt som (naturligt nog) inte kan leverera utifrån en galen spec (läs J2EE) implementerad i en överkomplex container (läs WebLogic). Där har ni en bra affärsidé. Synd att det inte var jag som kom på det.

J2EE är en typisk 80-20 deal. Det går bra att utveckla 80 procent av din applikation (om du kan stå ut med att den är seeeeg), medans resterande 20 procent är omöjlig att utveckla eller måste byggas i strid med vett och sunt förnuft för att kringgå alla hinder som J2EE lägger i vägen.

First post!

2007-11-09T13:37:00.001-08:00

Hej, här är jag. Det här är tänkt att vara en blog om livet som systemutvecklare. Fett roligt är det också. Bloggen alltså. Jag lovar. Att det blir det.

Namnet 'Hellre fåraherde' är väl valt. Alla i branschen har upplevt ett 'Hellre fåraherde'-tillfälle (dvs man vill hellre stå på en äng och räkna får än sitta med nosen i en korrupt databas). Master-databasen ditchar. Oförklarliga core dumps. Mer problem than you bargained for. Men så är det. Det bästa systemet är, på ett perverst vis, det som aldrig gick i produktion (såtillvida det inte berodde på din egen inkompents (felstavat med flit för att det är skoj att felstava inkompetnes)).