Mats Henricson

Mats Henricson

Saker som blippar på min radar

Crisp DNA is now open source!

Crisp DNA screenshot

Crisp DNA screenshot

We get a lot of questions about how Crisp works and why, especially from other consultants looking to create something similar. After many years of experimenting we’ve converged on a model that works well, basically the sweet spot between being an independent consultant and being an employee. So we decided to open source it.

In January 2015, at Crisp Hack Summit 10, Mats Henricsson, Henrik Kniberg and Max Wenzin huddled up and created the first version of the open-sourced Crisp DNA. It is published at http://dna.crisp.se/

The Crisp DNA is version controlled using Git and both Crisp DNA repository and Crisp DNA web site is hosted at GitHub using GitHub Pages. The web site is a bunch of static web pages and images that is generated from Markdown and Textile files using Jekyll. This is the same setup that GitHub themselves use.

By using open, version-control friendly formats such as Markdown and Textile, we hope to benefit from the open source community which can fork our model, make changes and perhaps suggest improvements. This can actually change how Crisp works!

Detta kan vi på Crisp, vårt tag cloud

På Crisp har vi skapat ett Google Spreadsheet där varje rad är en teknik eller metod, såsom TDD, Java, JUnit eller Kanban. Sedan har vi en kolumn för varje konsult, där man efter egen bedömning kan skriva siffran 0-5, där 0 betyder att man är helt okunnig, medan

  1. Har hört förkortningen, kanske läst en artikel i CS
  2. Har läst eller hört om det, kanske labbat lite, men inte jobbat med det. Känner till styrkor och svagheter.
  3. Kan jobba med det, men behöver handledning
  4. Kan området bra, kan handleda andra
  5. Expert, troligen en av de bästa i landet

Man kan även färga sin ruta:

  • Rött = Totalt ointresserad, vill inte jobba med det
  • Orange = Vill helst inte jobba med det, men i brist på annat så…
  • Gult = Kan tänka mig att jobba med det
  • Ljusgrönt = Vill gärna jobba med teknikområdet
  • Grönt = Brinner för teknikområdet!

Med dessa siffror är det ganska lätt att räkna ut vad vi på Crisp tycker att vi kan bäst. Man kan även gissa vad vi tycker är hett och intressant. Vi bestämde oss för att göra ett tag cloud, där storleken på varje ord motsvarar ungefär hur bra vi kan något, och färgen, från ljust grönt till mörkt blått motsvarar ungefär hur hett ett område är.

Exempelvis är XML/XSD/XSLT skrivet med stora ljusa bokstäver, för vi har brottats med XML och dess kusiner under över 10 års tid, men vi gör helst annat. Samtidigt är git litet och mörkblått. Inte många Crispare har använt det, och ingen kan det bra, men vi inser att det är framtidsteknologi.

Vi har också tagit bort en hel del, helt enkelt för att det är helt ute, såsom Ada, eller för att vi i stort sett bara vet vad det är, men inga detaljer, såsom Jclouds.


Bilden ovan är bara en PNG, vi ska göra en ny i SVG format så fort vi kan, och små detaljer lär ändras, men this is it, detta är vad vi kan på Crisp.

Free Society Conference and Nordic Summit, Göteborg

FSCONS var nog den bästa konferens jag varit på. Inte för att jag egentligen pratade med så många, presentationerna var oftast för korta, och maten var inte så inspirerande. Inte heller egentligen på grund av all den coola teknik jag fick se. Det är när cool teknik förändrar världen som det blir RIKTIGT intressant! FSCONS är verkligen unik som konferens. Samtidigt som någon har en presentation med titeln "Gender, class and global flows" gör någon annan en presentation av GNU Parallel. Det låter som om det skulle krocka något vansinnigt, men det fungerar!

Jag är mest intresserad av ny teknik, speciellt federerade moln och liknande, och här är en lista över väldigt intressanta föredrag jag lyssnade på:

  • Designed For Decentralisation: Understanding the Internet
  • Centralised Internet Services and Problems of Power
  • Building Socially Responsible Social Networks
  • The Future of RepRap and Free and Open Hardware
  • The economics of open innovation and FOSS
  • Future Transports
  • Distributed email system
  • Keynote: Ethics of Intellectual Monopolies
  • Bits and bytes: the importance of free software in the industry
  • Web Search By The People, For The People

Här är föredrag jag gärna gått på, men inte kunde, eftersom det var tre eller fyra parallella tracks:

  • Kaizendo: Customizable schoolbooks
  • Open Hardware Repository
  • Scalable application layer transfers
  • Workshop: Packaging for Debian using Git
  • One Wire Sensor Networking
  • A Swedish Linux for Schools
  • File sharer? Go to jail!
  • Distributed Democracy
  • Workshop: Icelandic Modern Media Initiative
  • Challenges to Copyright: The shift towards collaboration
  • Self-organized Plenty: The Emergence of Physical Peer Production
  • Design Patterns between Free Software and Permaculture
  • GNU social and GNU FM: Empowering Communities
  • Public Sector ICT Procurement

Om inget av dessa ämnen intresserar, ja då är man genuint inte intresserad av vad som sker när internet med full kraft kör rakt in i förra seklets samhällsbygge!

Här kan du läsa mer om den konferensen. Vi ses nästa år!

Konsultmarknaden behöver inte vara en Market For Lemons

Ekonomen George Akerlof skrev 1970 en uppsats som beskrev informationsassymmetri i vad han kallade "Market For Lemons". Det exempel han använde var marknaden för begagnade bilar, där säljaren alltid vet mer om den bil som säljs än potentiella köpare. Säljaren vet oftast hur välskött den är, hur den körts, etc.

Köparen, däremot, har svårare att avgöra bilens kvaliteter. Visst, det finns ofta en servicehandbok han kan läsa, men hur är bilen körd? Buskörd av en yngling, eller av en försiktig 47-åring?

Detta skapar informationsassymmetri, vilket ger intressanta följder. Säljaren av en bra bil vill ha bra betalt, medan köparen sällan är villig att betala mer än för en bil som har genomsnittskvalitet. Detta gör att säljare av välskötta bilar missgynnas, vilket gör att de inte tycker det är lönt besväret. Kanske försöker de sälja bilen på annat sätt, exempelvis till en bekant som litar på kvaliteten. Detta betyder att de bästa bilarna sakta men säkert försvinner från den öppna marknaden, eftersom genomsnittspriset bara sjunker. Kvar blir bara dåliga bilar, och då har man fått en "Market For Lemons".

Denna terori om informationsassymetri gav Akerlof och två andra nobelpris i ekonomi 2001.

Men har detta någon som helst relevans för konsultmarknaden? Ja, jag menar det. I en säljsituation vet konsultsäljaren mycket mer än köparen om den konsult som är "till salu". Köparen vet ofta nästan ingenting, annat än vad som går att läsa utifrån den CV som presenteras. Med lite tur finns konsulten på plats under förhandlingarna, så att köparen kan ställa frågor. Ibland kan köparen också hitta lite information på nätet.

Men hur effektivt är detta?

  • Den CV som konsultköparen får se har ofta skrivits just för det uppdrag som diskuteras. Det ger ofta inte en rättvis bild av konsultens egentliga erfarenhet av de tekniker som ska användas.
  • De allra flesta konsultföretag döljer sina konsulter på nätet, av minst två anledningar. För det första är man rädd att konkurrenter ska ringa dem direkt och locka dem att byta arbetsgivare. För det andra så så vill man behålla informationsassymmetrin. Så länge ingen information finns att tillgå om någon av företagets konsulter så måste köparen förmoda att de är av genomsnittlig kompetens. Men så är naturligtvis inte fallet. Om de visste mer om de enskilda konsulterna så skulle de vägra hyra de som inte är duktiga, och insistera på att få plocka russinen ur kakan. Det är inte i det flesta konsultföretags intresse.
  • Konsulter uppmanas traditionellt inte att berätta något om sina svagheter under intervjuer.

Vi på Crisp tycker naturligtvis att vi är väldigt duktiga, och för att bevisa det så har vi sedan många år tillbaka bestämt oss för att göra vad vi kan för att upphäva informationsassymmetrin:

  • Alla Crisp-konsulter har en egen publik sida på www.crisp.se. Där finns telefonnummer och emailadresser. Här är min sida. Ring oss gärna, fråga om specifika tekniker. Om du vill kan du försöka värva oss till ditt företag. Lycka till! 😉
  • Våra CV:s finns också där, öppet på webben, vilket gör att om vi skriver en specifik CV för ett specifikt uppdrag, så kan du jämföra den med vår vanliga publika CV och avgöra om den du fått är skruvad på ett orimligt sätt för att passa just det uppdraget. Här är min CV i HTML-format.
  • Alla som vill har en egen blog. Där kan du avgöra om du tycker en kandidat kan förklara tekniska saker i text.
  • När vi på Crisp håller föredrag på konferenser, eller håller kurser, så publicerar vi ofta vårt material på vår blog. Samma sak gäller det material som används i vår internutbildning, där materialet ofta läggs ut. Ta en titt får du se.
  • Vi kan även berätta om våra svagheter.

Nästa gång du söker en konsult till ett uppdrag, ta en funderare över varför du inte kan hitta någon information om dem på konsultföretagets webb. Vem tjänar på att informationen är assymetrisk? På Crisp delar vi med oss av vad vi kan, vad vi tror, tycker och brinner för. Vi vill vara så transparenta som möjligt! Vi tror att det är i vårt, och ditt, intresse.

Det där kan jag (faktiskt) inte?

På mitt nuvarande uppdrag fick vi nyligen stora problem efter vi släppt senaste releasen. Jag försökte hjälpa till, men prestandaproblem är inte min starka sida. Det blev lätt att jag ville säga "Det där kan jag faktiskt inte".

Men vaddå "faktiskt"? Som om jag kunde allt annat, förutom prestandaproblem?

För att ge exempel på total transparens tänkte jag faktiskt skriva ner saker jag är riktigt dålig på, så att folk vet vad de får om de anlitar mig som konsult. Here we go!

  • CSS – varje gång jag tvingas skruva på CSS så är det mer tur än skicklighet ifall jag lyckas med annat än rent triviala saker. Jag saknar erfarenhet och förståelse för grundprinciperna.
  • JavaScript – den längsta JavaScript funktion jag någonsin skrivit var på typ 10 rader, och jag har aldrig skrivit något av någon som helst substans, så luta er inte mot mig när era closures krånglar!
  • Toolsmith – varje projekt behöver en toolsmith som ser till att continuous integration fungerar, att deployment fungerar, att properties-filer patchas automatiskt, installerar wikis och annan viktig mjukvara. Jag är riktigt usel på bash och liknande också, inklusibe sed, awk, grep, etc etc etc. Egentligen är det ett under att jag kunnat köra Linux i runt tre år. Jag hankar mig fram som glad amatör.
  • Maven – kan bara grundprinciperna, saknar kunnande för att göra annat än det enklaste. Har förut avskytt Maven, men det används överallt, så det är bara att bita ihop.
  • Prestanda – jag har läst 5 böcker i ämnet, men har ingen riktig erfarenhet av att tuna applikationer eller databaser.
  • Säkerhet – kan noll och intet, så jag hoppas andra kan hoppa in och göra det jobbet i de projekt jag sitter i. Finns det ingen annan så får jag naturligtvis göra det själv, men min startsträcka blir rätt lång.
  • Skalbarhet – här är jag lite kluven i mitt omdöme, för det kan också vara fallet att jag har en inbyggd känsla för skalbarhet som gör att jag aldrig tänker på det.
  • Subversion/Perforce/Git/Mercurial etc – jag saknar egentligen intresse, och blir nervös inför minsta merge. Jepp, så är det.
  • SQL – jag har blivit bra mycket bättre genom åren, men kan fortfarande inte skilja på en yttre och en inre join. Har faktiskt sumpat två jobbintervjuer på att inte kunna svaret på den frågan. Jag vet inte ens varför det är viktigt att kunna skillnaden!
  • Regexp. Så fort jag inser att jag måste skriva lite regexp så darrar fingrarna till lite. Som oftast ror jag hem det, men inte utan att kontakta någon av mina kunniga Crisp-kollegor.

Säkert många saker jag glömt. Vågar ni lista ner era svagheter, eller är det bara jag som har svagheter? 😉

Notes from NoSQL Europe in London, part 0

I am currently, after going overland from Scala Days in Lausanne by hitching, train and boat across the English Channel, in London for the NoSQL Europe conference today and tomorrow. I will try to blog from every session. It might be a bit incoherent and inconsistent, but it’s all I can offer.

You can also follow my tweets more directly.

Developer Superstition

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!

Technology stressed? Perhaps it is time to panic!

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?

Typning: Titanernas kamp

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.

Lift 1.0 !!

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.

Java 7 update från Alex Miller

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.

10 really lousy commandments for Java Developers

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.

Misslyckat projekt, eller misslyckad budget?

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.

Hur djup blir krisen för IT?

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.

Future Directions for Agile

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!

Actors Galore

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.

SOA är dött, länge leve SO?

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.

Vad kommer egentligen i Java 7?

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!

Analys av alliansens FRA-uppgöresle, punkt 11

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!

Analys av alliansens FRA-uppgöresle, punkt 8

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!

Därför får jag ont i magen av DSL

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?

RIP Good Times PowerPoint slides från Sequoia Capital

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.

Dependency Injection i Scala

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.

Scala klättrar snabbt på Tiobes lista – nu före Groovy!

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.

$22 500 för SpringSource Enterprise support?

Nej, FRA debatten är inte över

Många tidningar har basunerat ut påståendet att FRA debatten skulle vara över, eftersom det verkar som om alla inom alliansen var överens om ett antal ändringar. Tack och lov verkar Socialdemokraterna inte köpa det hela. Med lite tur så river de trots allt upp det hela när de vinner nästa val. För det lär de göra med tanke på hur alliansen kört över majoriteten av svenska folket som fortfarande inte gillar förslaget.

Så, varför är det fortfarande inte ett bra förslag?

  1. Det är inte Svenskar man är ute efter, säger glatt Fredrick Federley (c), men vad menar han? Och blir förslaget bättre av det? Om jag skickar email till min kompis Steve i USA, blir vi potentiellt avslyssnade då? Om jag skickar email till min kompis John som är från England men bor i Sverige, blir vi avlyssnade då? Om jag är på konferens i USA och skickar email till min kompis Lars i Stockholm, kan vi bli avlyssnade då? Om jag är på konferens i USA och skickar email till min kompis Sven som också är på konferens i USA, blir vi kanske avlyssnade då? Om Sven och jag använder Telias emailservrar i Sverige? Om vi använder Telias emailservrar i Finland? Om vi använder Google-konton, som Google av någon anledning som de bäst känner till flyttar runt från USA till Sverige, eller Tyskland, och tillbaka igen nästa vecka? Och vad betyder det att ha ett konto någonstans? Det hela är så sjukt dåligt genomtänkt! "Trafik mellan avsändare och mottagare i Sverige får inte signalspanas", men den som har det minsta koll på hur internet fungerar inser ju hur vagt och grumligt det påståendet är. Och hur ska de kunna veta att jag är svensk, men John som bor i Sverige är Britt? Eller att Osama och Moqdata som skaffat emailkonton på Telia i Sverige inte är svenskar, och båda bor i Pakistan?
  2. Bara trafik som korsar våra gränser ska avlyssnas. Hur smart är det, om man nu vill komma åt terrorister? Har de väl kommit in i Sverige från säg Pakistan, så vet de då att email är ett säkert medium (för de skickar ju naturligtvis sina bomb-planer via email)? Om båda terroristerna är äkta svennar? Är deras email säkra då? Hur logiskt är det?
  3. Bara regeringen och försvaret kan be FRA avlyssna saker, inte SÄPO eller Polisen. OK; och vad sker om SÄPO ber regeringen be FRA avlyssna någon? Till den som tror regeringen säger nej har jag en dyr bro att sälja.
  4. En hemlig specialdomstol ska pröva avlyssningsbehoven. Är det någon av mina läsare som kan säga "Hemlig Specialdomstol" utan att samtidigt vilja gnissla tänder? Nej, tänkte väl det. Vart är riket på väg? Det hela är ju helt huvudlöst!
  5. Sedan läser jag att "FRA kan spana mot internationella föreeteelser i övrigt av särskild betydelse för svensk utrikes- säkerhets- och försvarspolitik". WTF betyder det, om inte ett generellt carte blanche att köra som de vill?
  6. "FRA blir skyldig att underrätta personer som blivit utsatta för spaning." Hahahahahaha…
  7. "Inget råmaterial (trafikdata) får sparas i mer än ett år". Men slutsatser dragna från råmaterialet kan sparas hur länge som helst, förstås. Och skickar vi (regeringen, naturligtvis, inte aldrig någonsin FRA själva) slutsatser till Pakistan eller Saudi-Arabien, vilket ju får anses inte vara helt osannolikt efter Carl Bildts fadäs, så vet man ju aldrig vart det till slut hamnar, och hur länge.
  8. "FRA måste omedelbart förstöra information från själavårdande samtal"! Kan det ha varit någon KD-ledamot som fått kalla fötter här? Varför är själavårdande samtal undantagna? Att avlyssna email mellan en utsatt kvinna (som kanske inte är svensk medborgare) och en organisation som hjälper till med skyddat boende är tydligen helt OK. Och, om FRA bara ska lyssna på sådant som har med "yttre militära hot", vad har då själavårdande samtal med det hela att göra? Mellan ryska ubåtsamiraler med samvetsbetänkligheter?
  9. Källskyddet till press och tidningar står det inte ett smack om, och det borde ju oroa tidningarna som triumfierande skildrat att debatten var över…
  10. Hur ska information för övrigt kunna tas bort? Om någon på FRA råkat läsa något som sedan ska tas bort, ska man då också skjuta den anställde på FRA? Jag menar, viss information går ju inte att ta bort, exampelvis den som finns innuti människors hjärnor.
  11. Det nämns i tidningsartiklar att FRA ska spana på "yttre militära hot". Men den parlamentariska försvarsberedningen fastslog i somras att det inte finns något militärt hot mot Sverige, så vad blir kvar? När slutförslaget kommer (för vi har hittills bara sett preludiet) så ska ni noga lägga märke till om det står bara "yttre militära hot", eller något mer luddigt. Då vet ni att FRA har vunnit striden om att få sprida en mycket vidare avlyssning av nätet.
  12. Ett exempel: Jag och Göran chattar via en svensk server. Göran är ursvensk, och jag har bara lite norskt blod i ådrorna, så vi borde vara säkra. Helt plötsligt hoppar Emilio från Italien in i diskussionen. Han är en gammal kompis till Göran. Shit! Nu kan FRA avlyssna så mycket de vill. Men, får de bara se vad Emilio skriver i chatten, eller dyker min och Görans inlägg också upp i FRA:s loggar? Är det över huvud taget någon i regeringen eller riksdagen som tänkt igenom dessa scenarier? Min gissning är att ingen har någon aning om vad som ska ske!

Riv upp, gör om, gör rätt!

Cascading – MapReduce without the complexity

Just bumped into Cascading, which is an open source (GPL 3) framework "for defining and executing complex and fault tolerant data processing workflows on a Hadoop cluster". Hadoop is, I’m sure you all know, an implementation of MapReduce which is at the core of how Google does its processing.

Anyway, the Cascading API "lets the developer quickly assemble complex distributed processes without having to "think" in MapReduce", which can get really complex in non-trivial applications.

What is SpringSource doing with its license?

It appears as if SpringSource, the company doing most of the development of Spring, is doing an ExtJS, i.e. changing the license of its product to force users into paying for it, or its support. Lots of people are writing about this, such as

Regardless, I think it is now up to the community to start asking the maintainers of various emerging frameworks explicitly if they in the future will change its license. If they slipper and slide on the answer, then we know we’re in for a rough awakening.

Woohoo: Mixed Scala and Java projects in Eclipse

A few days ago Scala 2.7.2 RC2 was released. One of the new features is mixed Java and Scala support in both the compiler and the Eclipse plugin. I decided to try it out. Installation was very simple. I then set off creating a simplistic Java class side by side with the Scala object, in the same package. I then created such a Java object in my Scala code, and ran it. It just works!