Superstition is a bad thing. At least that's what I have always believed, regarding myself as totally devoid of the stuff. I mean, me, Mats Henricson, superstitious? No way!

But superstition grows out of ignorance, and that's a valley I must admit I have walked in. And some time ago it struck me that I am indeed plagued by superstition as a developer. Let me elaborate.

Suppose you're in a slow edit-compile-debug cycle, and suddenly your changes to file X aren't deployed to Tomcat any more. After some brief investigation it turns out you can get your changes through to Tomcat by prepending your Maven command with "clean", i.e. a clean compile, instead of just incremental.

At this moment your are in dangerous territory, because if you never find the root cause to the problem you are quite likely to ALWAYS do clean builds, thus slowing you down forever!

Does this resemble a situation in your past? If so, then you are also superstitious!

I have added all sorts of shit procedures to my daily work. I do WAY to many clean builds. I restart my laptop twice a day because I can't get it to dynamically go from wireless to wire, or from my second screen at work to my second screen at home, since they are of different size. My Ubuntu 9.10 distro have problems with that, and I just haven't found the root cause to it.

Staving off superstition is simple in theory but hard in practice, since it requires you to go to the root of the cause of problems. I have suddenly gotten much more respect for stubborn people!

Four years ago I spent a few months assembling a rather wide-spread document which I named "State of the art in Server Side Java". It was at the time well researched enough to end up as an entry on The Server Side.

Soon thereafter I got sidetracked to follow Ajax for a few years. I even went as the only Swede to the first ever Ajax conference in San Francisco, and blogged a lot from there.

These days there are simply so much things going on in Server Side Java land to have a slight clue as to where that freight-train is heading. There's Hadoop and all its cousins for distributed computing, Actors, Terracotta, a school of new whacky persistence paradigms, a handful of JVM-based languages that only Ola Bini has the energy to follow. Annotations have, as I predicted, totally changed the way we program, and just about every day I bump into a new annotation I've never seen before (yesterday it was @PathParam).

It would feel OK if this plethora of technologies were somewhat obscure, but in my current project we use a lot of stuff I don't know well enough, such as Maven, Jersey, WebLogic, Spring transactions and JPA, just to mention a few.

And even though the Ajax anarchy has somewhat collapsed into a few leaders, such as jQuery, Dojo, DWR and GWT, the whole arena is just all over the place. I've stopped following Ajax these days, there is just too much going on.

So, what do I spend time on, if I don't stay up-to-date with server side Java or Ajax? Well, I'm swamped by RSS and Twitter. I abuse technology news like a drug addict, and believed I was reasonably knowledgeable, until I read this blog post yesterday which listed 14 technologies to follow at JavaOne. I had heard of 3 of them, which made me start thinking.

What the heck is going on? Is this technology race accelerating, not just at the rate of the SW industry expanding, but at a pace where it is getting out of control? Have humans triggered the singularity themselves, without the need for a Super Intelligence? Well, perhaps not. The slice of knowledge any human can follow has been shrinking constantly for a long time. But I can't help getting this idea that the explosion of open source software is giving us the shoulders of giants we can stand on to accelerate our knowledge. And more of it is coming from unexpected countries. Recently I bumped into Debasish Ghosh. Following this guy from India on Twitter is like riding a rollercoaster - new exciting stuff all the time.

So, should we panic? Should we give up? Will every future job search have a list of required skills from a potential list of skills so huge that nobody will ever have a full set? What if we go with maximum speed into polyglot programming, and fragment even further in all directions? Today I heard about two sites where they used Clojure on the server, with Rails as UI. Who the hell can fill that skill set?

På Artima har en mycket intressant diskussion brutit ut under rubriken "Getting Dynamic Productivity in a Static Language". Bill Venners, Martin Odersky (skaparen av Scala), den ibland obegripligt teoretiske James Iry, min favorit i blogosfären Cederic Beust och ett flertal andra brottas igenom långa intressanta diskussioner om statisk och dynamisk typning, "structural typing", klasser versus typer, och en massa annat som ligger strax över min nivå (det är då jag lär mig mest, har jag upptäckt). Är man över huvud intresserad av detta så bör man koka sig en stark kopp kaffe och läsa igenom de nästan 80 kommentarerna.

Webbramverket Lift, skrivet i Scala, har precis släppts i version 1.0. Mycket spännande, tycker jag. Citat från Michael Galpin:

Lift is the only new framework in the last four years to offer fresh and innovative approaches to web development. It's not just some incremental improvements over the status quo, it redefines the state of the art.

Alex Miller har precis bloggat om vad han tycker verkar ske när det gäller Java 7. Vi kan få en preview till JavaOne 2009 (dvs juni) och ett teoretiskt releasedatum på januari 2010, men Miller tycker det är för mycket osäkerheter för att tro på en så pass snabb release.

Generellt sett så tror jag han verkar tycka att det ändå blir en rätt intressant release, trots att den inte kommer att ha closures. Man kan tro att jag har massiv kritik mot Sun och Java 7 utifrån rubriken på den artikel i Computer Sweden där jag citeras, men så är inte fallet. Jag tror väldigt mycket utmärkt mjukvara kommer att kunna utvecklas i Java 7 utan dessa closures.

Aleksey Shevchenko have on developer.com published 10 commandments for Java Developers, and they are of such lousy quality that I just have to respond (this vaguely resembles a xkcd cartoon :-). His commandments are:

1. Add comments to your code
2. Do not complicate things
3. Keep in Mind – "Less is more" is not always better
4. No hard coding please
5. Do not invent your own frameworks
6. Say no to Print lines and String Concatenations
7. Pay attention to the GUI
8. Always Prepare Document Requirements
9. Unit-test. Unit-test. Unit-test
10. Remember – quality, not quantity

Lets have a meta discussion about programming guidelines. In my not so humble opinion, they must fulfil at least these requirements:

• Programming guidelines must be relevant. None of the commandments above have anything to do with Java. What was he thinking?
• Programming guidelines must be helpful. Take "No hard coding please" as an example. How the hell is that helpful?
• Programming guidelines must stand on their own in one or two sentences. As an example, "Remember - quality, not qualtity" is just sloppy wabbly gibberish. It does not help me at all in my day-to-day programming.
• If you feel like writing commandments, better make damned sure they are important. First, is the issue you are adressing severe? If so, is it common? It has to be both severe and common to grant status as commandment. Is "No hard coding please" among the 10 most important programming problems we're wrestling with in Java-land? No. It is at most annoying, and can easily be refactored.

After frothing at the mouth like this, lets go into details:

1. Add comments to your code.
   
   My reaction is that this is just the wrong way to go. Instead extract methods with names describing what is going on. If you've added a comment, such as "Calculate interest rate according to RFC 666", extract the relevant code into a function named calculateInterestRateAccordingToRfc666(). Much better!
   
   
2. Do not complicate things
   
   I feel like using the cane to punish such useless meaningless drivel.
   
   
3. Keep in Mind – "Less is more" is not always better
   
   Have a look at the original examples and ask yourself, what is the correct thing to do? My suggestion is, again, to extract a function, and use constants.
   
   
4. No hard coding please
   
   To be helpful he should have written "Literals should only be used in the definition of constants and enumerations".
   
   
5. Do not invent your own frameworks
   
   Yes yes yes, but what has this to do with Java?
   
   
6. Say no to Print lines and String Concatenations
   
   Is this important? Is it common? If so, you really have a serious problem.
   
   
7. Pay attention to the GUI
   
   Well, what can I say? Aleksey have realized that "The GUI is an essential part of a successful application". What can I say? It seems... profound!
   
   
8. Always Prepare Document Requirements
   
   In the description he elaborates thus: "Every business requirement must be documented." This guy seriously needs to be hit by the 26 ton agile bus.
   
   
9. Unit-test. Unit-test. Unit-test
   
   TDD, TDD, or BDD, BDD. Much more important than unit tests.
   
   
10. Remember – quality, not quantity
    
    Has he stumbled upon something important here? No, I will, as always, prefer quantity over quality every day of the week. Code is an asset, as well all know. The more the merrier!
    

As a warning to anyone with a severe case of Moses complex out there, think again before you start whacking away with chisel on stone.

Hur många av er har inte läst om misslyckade projekt, som blivit mycket dyrare än planerat? Jag har svalt detta sätt att resonera, skakat på huvudet, och tänkt "Jaja, vilka kretiner". Men nyss pekade min kollega Mattias Skarin på ett mailinlägg av Roy Morien på en mailinglista med namnet scrumdevelopment (hur hinner han läsa allt?) som vände upp och ner på min hjärna. Jag har insett att det är helt befängt att sitta långt i förväg och planera in i minsta detalj hur ett projekt ska drivas under lång tid framöver, men samma sak måste rimligen även gälla för ett projekts budget!

Citat från Roy:

If a project substantially exceeds the budget, is that a project failure, or a budgetting failure?

Och:

Unfortunately, there are so many examples of 'failed' (exceeding the budget, exceeding the time, delivering unwanted and unuseable functionality) because of the emphasis on 'up front' prophecy, often called project estimating. When the Australian Customs Service spent $250 million on a $35 million project, and took 5 years to complete a 3 year project, and the outcome almost brought Australian international trade to its knees, one must ask the serious question 'How the hell could that happen'? Perhaps if they had developed iteratively, with regular and frequent deliveries (giving the frequent opportunity for verification and validation of requirements, of functionality, of progress) then the cost may have been the same, the development period may have been the same, but the functionality may have been proven at every step, and the initial budgets demonstrated to be totally inadequate.

Mycket tankvärt, tycker jag.

En fördel med denna kris är att vi IT-folk, så fort någon sneglar i vår riktning, kan slå ut teatraliskt med händerna och säga "Nonononono, titta inte på oss - vi är oskyldiga". Dock kan den svida nog så illa, speciellt om man är konsult.

Så, hur djup blir krisen för oss? Enligt den ansedda tidningen The Economist blir den troligen inte alls så djup som vid förra krisen. Det som talar för vår sak denna gång är bland annat:

• Den gången var IT själva roten till krisen, så inte idag.
• Dagens IT-företag har från förra krisen lärt sig att vara mycket smartare. Dessutom har de som oftast mycket sundare affärsmodeller.
  
• IT är inom många företag redan så pass slimmat att ytterligare nedskärningar skulle behöva omorganisationer, vilken The Economist inte tror är så attraktivt.
• Det är idag lättare att starta nya företag, eftersom man kan bygga lösningar på open source och cloud computing, vilket är bra mycket billigare än förra gången IT-branschen dök.

Den som lever får se.

Några kollegor på Crisp gav tipset att titta på videon från David Andersons presentation Future Directions for Agile från Agile 2008 Conference. Väldigt väldigt intressant, och emellanåt ganska provocerande, så det kan inte bli speciellt mycket bättre. Real Options Theory var ett intressant nytt område som jag skulle vilja läsa mer om (närbesläktat med Lean), samt naturligtvis Kanban, och att CMMI tydligen skrivit ett dokument där de förklarar vad de tycker om Agile. Mycket väl värda 90 minuters tittade på grynig webbvideo!

När jag började lära mig Scala så stötte jag direkt på Actors, ett koncept snott från (om jag förstått det hela korrekt) Erlang. Actors är ett sätt att få till concurrency genom att skicka meddelanden, till skillnad från det vi alla under ett decennium svettats med i Java, trådbaserad concurrency. Tanken är att det ska vara ett lättare sätt att programmera inför den multi-core framtid vi står inför.

Att skriva om sin applikation så att den kan hålla ett par kärnor varma låter sig kanske göras, men hur ska en vanlig applikation rimligen få mer än en handfull kärnor att komma över rumstemperatur?

Så kom Kilim, och jag gjorde ett försök att skriva ett enkelt exempel, men min förståelse för hur Kilim fungerade var för ytlig för att jag skulle ro det hela iland. Jag försökte skriva om min primtalsberäknare från JavaSpaces till Kilim, men det visade sig att att ha en master och många workers inte är det gängse sättet att använda sig av actors.

Nå, för en dryg vecka sedan bloggade Sujit Pal om alla de Actors-ramverk som nu dykt upp som svampar ur jorden. Han har fungerande kodexempel för Kilim, Scala Actors, samt Jetlang, ActorFoundry och Actor's Guild (hehe, fyndigt namn)! Har man en gång utvärderat ett bleeding edge ramverk av den här typen så inser man vilken herkulisk insats han har gjort för att utvärdera fem ramverk!!

Om man detaljstuderar exemplena så ser man en del eleganta detaljer, men också för varje ramverk en del som ger mig lite ont i magen och gör att jag slipar tänderna mot varandra med ett ohälsosamt ljud. Med lite tur sätter sig de olika programmerarna samman och gör en AOP, dvs mergar sina respektive ramverk på samma sätt som AspectWerkz (drivet av en av våra svenska superprogrammerare Jonas Bonér) och AspectJ slog sina påsar samman och skapade den industristandard som vi nu åtnjuter.

Anne Thomas Manes förklarade den 5:e januari SOA som dött, och ett flertal personer har inspekterat liket och godkänt dödsprotokollet. Själv är jag inte bland de närmast sörjande, och sörjer inte heller. Good riddance, som det heter. Tvingade mig själv för ett par år sedan att läsa en hel bok i ämnet för att försöka förstå vad som menades, och sedan dess har jag varje natt legat i fosterställning mellan kalla svettfuktiga lakan.

Det som skrämde mig mest var SOA Governance, som enligt den bok jag läste var en ofantlig överbyggnad på alla de services som ett företag skulle ha, och SOA Governance skulle naturligtvis i sig implementeras med SOA!

Andra har sagt att det är ett "A" för mycket i SOA, att man borde ha koncentrerat sig på Services, och inget annat. Bokstaven "A" luktar BDUF (Big Design Up Front).

Andra har kritiserat SOA att vara inkompatibelt med Agile. Jag tycker den diskussionen är intressant, men exempelvis Scott Ambler håller i kommentarerna inte med, utan tycker att de kan vara kompatibla om man jobbar på rätt sätt. Men jag tycker att fokuseringen på Services är rätt osund. Bokstaven "S" luktar YAGNI (You Ain't Gonna Need It).

Sedan har vi Carlos Perez som hoppas på SOA 2.0, men frågan är om inte just den bokstavskombinationen har blivit radioaktiv, att man måste använda något annat. Min kollega Per Lundholm brukar säga att huvudfokuset för Agile är affärsvärde (Business Value), och det är kanske så man kan starta om hela denna debatt, genom att kalla det BVO(A). Hm, kanske inte ligger helt rätt i munnen.

Cory Doctorow (som bland annat är känd som intressant SF författare) har sammanfattat varför han inte tror att metadata (dvs data om data) kommer att lyckas i Putting the torch to seven straw-men of the meta-utopia. Kort och kärnfull spark i skrevet på de som tycker den semantiska webben är intressant. Ouch!

Alex Miller har haft den intressantaste bloggen för de som intresserat sig för Java 7, och han har en speciell sida där han summerat all information han kommit över.

Java har känts lite övergivet på Sun, tycker jag. Det har inte funnits någon kapten på skeppet. Gosling gör lite som han vill, men driver inget på egen hand som har med Java att göra, verkar det som. Neil Gafter jobbar nu för Microsoft (burr), och Josh Bloch har bytt till Google. Kvar på Sun fanns Gilad Bracha, mannen med den bästa titeln - Computational Theologist - som hade sitt eget språk han snickrade på, Newspeak. Han blev också lockad över till Microsoft, och min gissning var att han blev ditlockad av att få en grupp som kunde driva hans språk framåt. Nå, Microsoft hoppade av, och jag vet inte vad han sysslar med nu.

Kvar på Sun finns Danny Coward. Vet inte om han har karisma och guts nog att driva fram Java 7 med den pondus som behövs. Ett språk behöver en järnhand för att drivas fram i rätt riktning, tror jag.

Hur som helst så har Alex Miller nu gjort en ny gissning av vad Java 7 kommer att innehålla. Inga closures, vilket många tycker är konstigt, med tanke på all den brouhaha som genererats under den rubriken de senaste åren. Jeez. Hur som helst är det rätt intressant läsning!

I Alliansens uppgörelse om FRA-lagen från 25:e september finns 15 punkter beskrivna. Punkt 11 lyder:

En underrättelseskyldighet till enskild införs.

I min naivitet trodde jag att det betydde att en individ som felaktigt blev avlyssnad skulle få veta det. Helt fel, visar det sig, enligt interna dokument innifrån alliansen, för ansvaret ligger på oss individer att fråga, högst en gång per år, om vi blivit felaktigt avlyssnade. Det svar man kommer att få är endera "Ja, du har blivit felaktigt avlyssnad, vänd dig till JK så ska vi se om du har rätt till ersättning", eller "Det finns ingen orsak till ersättning".

Så, om min privata kommunikation felaktigt avlyssnats, då får jag skadestånd? Nej, du kan bara få ersättning om dessa fyra villkor är uppfyllda:

1. Du blev avlyssnad genom direkt avlyssning av just dig, personligen. Blir du avlyssnad för att FRA råkade få en träff på dig när de sökte på någon annan, så har du ingen rätt till ersättning.
2. Du är hemhörande i Sverige, vilket troligen betyder svensk medborgare eller person med uppehållstillstånd i Sverige. Är man turist på besök, eller väntar på uppehållstillstånd, eller utlänning på affärsresa i Sverige, så kan man känna sig blåst. Och naturligtvis alla andra, misstänkta utlänningar som bor utanför Sverige.
3. Du anses ha blivit felaktigt avlyssnad, dvs man trodde att du var bin Ladins högra hand i Sverige, men det visade sig vara fel.
4. Avlyssningen inte är sekretessbelagd. Men det kommer ju allt att vara, så det lär ju alltid gälla.

OK, så om jag får reda på att jag inte har rätt till ersättning, vad betyder det? Ingenting! FRA kan ha massor av avlyssnad kommunikation från dig, men de behöver inte avslöja det, enligt punkterna ovan.

Men all trafik som startar och börjar inom Sverige ska ju inte avlyssnas, eller hur? Fel. Det står nu klart att från och med 1:a januari kommer all kommunikation som FRA kan få sina fingrar på kommer att skickas till dem. Den trafik som startar och slutar i Sverige ska raderas, men först efter att det loggats, vilket troligen betyder att man behåller kopplingarna i våra sociogram, dvs vem som pratar med vem, men raderar själva meddelandet. I alla fall från datorerna. Om någon anställd på FRA ser att du sexchattar med grannen, och sedan raderar den informationen från FRA:s datorer, så finns ju informationen kvar i den anställdes huvud. Den kan inte raderas, vilket betyder att den kan missbrukas, exempelvis genom utpressning.

Välkomna till det nya Sverige! Jag hoppas ni kommer att trivas!

I Alliansens uppgörelse om FRA-lagen från 25:e september finns 15 punkter beskrivna. Punkt 8 lyder:

Sökbegrepp som är direkt hänförliga till en viss fysisk person får inte användas utan särskilt tillstånd.

Vad betyder detta? Jag menar att det inte betyder något alls. För det första så måste alla sökningar föregås av ett särskilt tillstånd från en speciell domstol, så vari ligger det speciella här? Måste man fylla i ett speciellt formulär? I så fall vill vi se hur det ser ut! Måste speciella krav vara uppfyllda för att man ska få göra denna typ av sökningar? I så fall vill vi se de kraven. Utan en sådan specificering kan vi som medborgare inte lita på lagen.

Men även om det nu finns ett sådant formulär, eller speciella krav så går de ju enkelt att kringgå. Lägg märke till det lilla ordet "direkt"! Om man indirekt gör en sökning på en specifik person, exempelvis genom att använda sökbegrepp som i praktiken bara passar in på en enda person, så blir ju resultatet detsamma. Istället för att prata om Putin så kan man säga "högsta ledaren i Ryssland" (ingen tror väl något annat).

Och även om man inte ens får göra den typen av indirekta sökningar så kan man söka på en liten grupp. "De två högsta ledarna i Ryssland" ger ju nästan samma resultat.

Min analys är att punkt 8 inte betyder ett smack!

Martin Fowler, mångas favoritförfattare inom mjukvarubranschen (mig inkluderad), håller på att skriva en bok om DSL (Domain Specific Languages) som ska bli färdig 2010. Det borde väcka min nyfikenhet, men jag får bara ont i magen. Teknostress? Kanske det, men det är något med DSL som inte är nyttigt. Tyvärr har jag har inte kunnat sätta fingret på det, tills Jonas Bandi bloggade med titeln "Have I lost my faith?"

Det Jonas säger, framför allt, är att en DSL ganska snart stöter på 80/20 regeln - helt plötsligt måste man löda och svetsa in features i sin DSL för att lösa de där svåra 20% problemen. Då sitter man med ett språk som börjar bli mer och mer komplext, plus att det är designat av en amatör. För det är svårt att utveckla ett språk.

Är detta önskvärt? Roligt, javisst, men är det rätt sätt att använda produktägarens pengar?

En av Silicon Valleys mest respekterade venture capital företag, Sequoia Capital, hade i veckan ett all-hands möte med de som driver firmans investeringar. De 56 PowerPoint slidsen beskriver i detalj hur illa den amerikanska ekonomin mår, och presentationen kallas av TechCrunch för Presentation of Doom. Rätt intressant om man vill följa hur det går i Silicon Valley.

Jonas Bonér har bloggat om Dependency Injection i Scala. Han presenterar tre olika sätt att göra det på, och hans favorit är rätt elegant. Ingen XML, och helt statiskt typat, men det känns ändå som lite av ett hack. Att ha en trait innanför en annan trait? Hm... som lite av de hack jag såg när jag var djupt nere i C++ träsket.

Senaste listan på programmeringsspråk från Tiobe bjuder på en snabb klättring på ca 10 platser för Scala, som nu återfinns på plats 37, strax före Groovy på plats 39.

Mina nyhetskanaler är lite skeva, men jag tycker ändå att det är rätt tyst runt Groovy. Ett halvintressant inlägg om Grails är det enda jag sett på länge. Har rörelsemängden försvunnit? Ett tag hypades ju Groovy som det bästa sedan skivat bröd.

Ryan de Laplante kollade upp med SpringSource, företaget där de flesta utvecklarna av Spring kommer ifrån, och frågade vad en enterprise licens skulle kosta. Han hade en del problem som han inte fick svar på via de vanliga Spring Forumena. Svaret blev den nätta summan US$22,500. Det ska bli intressant att se hur Rod Johnson ska besvara detta, eller om de bara bestämmer sig för att tiga ihjäl hela incidenten.