#gotocph; Konferencens først dag

Konferencens åbnings-keynote kom fra Anita Sengupta, der præsenterede data fra Mars. Jeg forstod, at hendes oprindelige talk, var centreret om hendes arbejde på Curiosity rover, men i lyset af de seneste opdagelse, var vægten skiftet til at handle mere om denne, end om hendes arbejde. Det var spændende nyt og for en som mig, lidt af en oplevelse at høre på en, som arbejder med det, jeg drømte om som barn.

Den næste talk jeg deltog i, var om Basho. Der blev ikke talt så meget teknik, men der blev fokuseret på nogle af de nye ting, som de arbejder med i forbindelse med time series data. For mig var dette ret interessant, da det er den type data jeg analyserer til dagligt, men jeg fik indtrykket af, at deres Spark integration ikke var så udviklet som jeg havde håbet. Kunne godt have tænkt mig, at der var blevet gået mere i dybden. Det kom mest til at lyde som en salgstale.

Videre til selvbyggende robotter, for hvilken robot, tager man med til Mars, når man ikke ved hvilke opgaver robotterne skal løse? Løsningen er, at medbringer selvbyggende robotter. Selvom det var primitive prototyper, blev der demonstreret nogle ret imponerende ting. Robotter der i bedste transformerstil kan skifte form og robotter der kan reparere sig selv, hvis du bliver slået fra hinanden. Den store udfordring lader til at være, hvordan man programmerer disse robotter. Derfor havde de udviklet et DSL, der kunne programmere de små enheder, ved at beskrive opgaverne dem som en samlet enhed i DSL’et og så lade compiler nedbryde opgaven, så den kan løses ved at lade enhederne kommunikere om deres individuelle fremskridt i den samlede opgave. DSL’et er sekventielt, hvilket giver den fordel, at programmerne kan køres både forlæns og baglæns. På denne måde kan et program for at samle en enhed også bruges til at skille den igen. Ret interessant.

Var kort inde og høre om RavenDB. Gik igen. Jeg havde ellers savnet, at præsentationerne var lidt mere tekniske, men denne virkede for teknisk – på den måde, hvor det virkede indforstået. Jeg kom også lidt for sent til præsentationen og manglede derfor muligvis lidt kontekst, men formåede ikke at få noget ud af den del jeg overværede så jeg smuttede igen. Derfor fik jeg ikke begyndelsen af The New Frontier of Robotics med, men det var en gennemgang af status indenfor forskellige typer af robotter, f.eks. humanoids, smartphones and robotics. Det lader til, at det mindst dårlige værktøj til at programmere robotter, i øjeblikket er ROS (Robotics Operating System) fra ros.org og at der er mange “legetøjs-applikationer”, men ingen killer apps endnu samt at miljøet savnede flere systemudviklere.

Dagen bød også på en præsentation om droner – eller nærmere een drone, et projekt. En fyr havde lavet en app, så en drone kunne følge en mobiltelefon. Det var et meget sjovt projekt, men burde nok ikke have været en præsentation på en konference. Dertil var præsentationen lidt for tynd.

Den afsluttende keynote var underholdende. Erik Meijer var i hopla og fik knebet nogle provokerende erklæringer. Han fik forklaret sit frygtelige forløb med leukumi i programmeringstermer. Et barsk forløb, som han fik forklaret humoristisk og underholdende. Dog understregede han alvorligt, at vi alle kunne blive garbage collected lige om lidt, og at man skal udnytte sin tid.
Scrum fik også en tur i manegen. F.eks at ethvert minut der bruges på at tale om kode frem for at skrive kode, er spildt og at Scrum behandler udvikleren som en teenager ansat hos McDonalds. Scrum er alt for rigidt til at give effektivitet og man gør gøre alting modsat af hvad Scrum anbefaler.

Generelle indtryk af dagen: Udover de to keynotes, synes jeg ikke at det faglige niveau er så højt som det plejer. Jeg synes ikke at jeg bliver udfordret eller bliver præsenteret for væsentligt nyt. Jeg håber dog stadig, at dagen i morgen kan byde på mere.

#gotocph; Mit umiddelbare indtryk.

Lad mig først slå en ting på plads: Jeg er imod al forandring – også selvom det er til det bedre. Derfor er det også med en hvis skepsis, at jeg er mødt op til årets danske GOTO; Konference, som i år afholdes i København.
Jeg har været stor fan af konferencen i Aarhus. Dels har jeg nydt at komme nogle dage væk, dels har jeg nydt at møde venner og bekendte – hvoraf jeg har mødt mange af dem gennem konferencen – og dels har jeg nydt det faglige input som konferencen har givet.
Sidste år valgte konference at skære en dag. Det syntes jeg var ret trist, da jeg synes konferencen bliver for kort og af en eller anden årsag, var der pludselig en del overlap af interessante talks, så jeg var nødt til at vælge fra. Nettoresultatet var, at jeg syntes jeg havde fået mindre ud af det. I år afholdes konferencen kun i København, hvilket giver nogle udfordring, da det er et nyt sted og intet er som det plejer. Jeg savner derfor allerede fra morgenstunden konferencen i Aarhus. Konferencens valg at af emner, gør desværre også konferencen mindre relevant rent arbejdsmæssigt for mig i år. Emnerne er stadig interessante, blot ikke ligeså arbejdsrelevante. Jeg har ikke fået billetten betalt af min arbejdsplads men har selv stået for den, så det gør mig ikke så meget, men jeg antager, at andre kan have svært ved at overtale deres arbejdsgivere, hvis konferencens emner er for langt fra deres dagligdag.

Stedet de har valgt er utroligt trangt. Salene for præsentationerne foregår er små, og der er ikke altid plads til alle interesserede. F.eks kunne min medblogger, Kim, ikke komme ind til en af de præsentationer som han havde forberedt sig på. Det synes jeg er ret ærgerligt. Det var helt umuligt at komme rundt i pauserne, da pauseområderne består af smalle gange gange, hvor alle kæmper for at få kaffe, snacks eller bare et sted at stå. Det blev lidt bedre i løbet af dagen, men aldrig helt godt. Der er simpelthen bare for lidt plads og ingen steder hvor man kan trække sig hen og hvile hovedet mellem præsentationerne. Det får mig virkelig til at savne Aarhus. Hørte dog nogle rygter om, at de til næste år vil forsøge sig med Bella Centeret istedet, hvilket jeg synes lyder som en fantastisk god ide.

Tom Baker

Måske tænker du: Hvem er ham Tom Baker og hvad laver han her på bloggen? Forhåbentlig ikke, men her er en forklaring.

Tom Baker er en engelsk skuespiller, der lagt stemmer til karakterer i animationsfilm og computerspil, samt spillet med i blandt andet Black Adder. Men vigtigst af alt, var han den 4. doktor i den Bristiske serie “Doctor Who” – endda den doktor der levede længst, nemlig 7 sæsoner. Han er også den doktor, som var min indgang til serien, som jeg som barn slugte råt. For mig er han nok den eneste Doctor.

Tom Bakers inkarnation af The Doctor var angiveligt medvirkende årsag til, at Anita Sengupta endte i Nasa’s Jet Propulsion Laboratory (Ja, ved det godt. Collect underpants -> profit, men pointen er, at Science Fiction er inspirerende). Det var også science fiction, der vakte min egen interesse for computere og software. For mit eget vedkommende, var det en kombination af Doctor Who, Star Trek, 2001: A Space Odyssey og Alien der gav en diffus drøm om at sende intelligent software ud i rummet.

Kilden til inspiration er sammenlignelig og Sengupta og jeg er åbenbart noget der ligner jævnaldrende, dog er Sengupta væsentlig mere badass end mig, hvilket gør, at jeg nu glæder mig ustyrligt til at høre hendes Keynote på GOTO; i København. Her vil hun tale om en opgave, som hun løste for Nasa: Den 5. august, 2012 landede Curiosity på Mars overflade. Senguptas arbejde er årsagen til, at Curiosity landede på Mars og ikke blev knust mod overfladen – og det glæder jeg mig til at høre om. Hun har gjort, hvad jeg stadig kun drømmer om. Indtil GOTO; må jeg nøjes med dette interview fra BBC.

Legacy systems revisited

This post is actually not inspired by this years GOTO Conference, but the one 2 years ago in Copenhagen. I can’t remember if it was in a talk or it was during my discussing with Dave Thomas in one of the breaks, that he started talking about “Legacy systems”. I was kind of star struck, so I didn’t question anything he said – well, not until I got home anyway. When I was looking through my old posts, I found this entry, where I asked how others would define the term “Legacy System”. Nobody really coined it and I’ve been meaning to follow up on this post for 2 years now, but never got around to it before now, so here goes. This is my definition.

Technology needs to be dead or dying
If the system is build on a brand new techology, it is hard to argue that is has any kind of legacy to it. It has to be something that has been, something that was state of the art, but not any longer. The technology was either adequate or simply the best available at the time the system was build, but the world/company moved on and the chosen techology had a hard time keeping up with new demands.

Systems has to have substantual/significant value to the company
If the systems does not have any value to the company, it can be turned off. The revenue stays the same and nobody will miss it, therefor the cost of having it running needs to be less than the loss of shutting it down.

The rate of new features added is going towards zero
If features are still add to the system at a high rate, I would argue that it is a system still under development. This to me indicates, that its technology can keep up with demands, thus it is not dying. The system needs to be in a state where it either sufficiently solves the business needs or the pain and cost of adding extra features are higher than the revenue from adding them.

The time spent on new features is less than time spent on bugfixing and maintenance
Though the rate of adding new features is going towards zero, I will still argue, that if more time is spent adding features that maintaining the system, it is still under development. Every time a feature is added, the value of the system increases and if it increases more than the cost of running it, the company is investing thus the system is still under development, therefor it is not a legacy system. It has to be in a state where the company invests less in adding new features than the cost of running the system.

* * *

So this basically sums up to be an old system that have a substantual/significant value to the company, a system that does not grow in value but needs to be maintained, so it does not devaluate.

What is “simple”

So I was all high on simplicity yesterday and of course Frank had to ask me the question that made me crach land again: “So, what do you mean by ‘simple’?” I almost didn’t hear this mornings talk from Brian Goetz about lambdas in Java, since me head was crunching that question. What is “simple”, what does it all mean?

It struck me that I need to be able to measure complexity to answer that question. I need some way of comparing to things and say, that one is more complex than the other. Looking at code, at a system, at a framework, we have en intuitive understanding of simple. But it is not only intuitive, it is subjective. If something is easy to do or easy to understand. Does that make i simple?

I’ve been doing karate for years and it is pretty easy for me to round house kick someone and kill them 3 times before they hit the ground. Does that make it easy to do, thus simple? Not really. Karate is hard and complex, I just practiced a lot. So easy to do, does not make simple.

What about easy to understand? I understood most of Brian Goetz talk about lambas in Java without a big effort. Of course I had to think really hard about some af the stuff, but in overall, it was pretty straight forward. But I’ve been programming for 25 years now in anything from assembler to prolog, and I’ve been a full time clojure programmer for almost 2 years now. I should know about lambdas and low level stuff by now. That gives me an edge. It is only easy because of all the other stuff I know about the subject.

That still leaves the question unanswered. Should complexity then be messaured by LOC? That’s at least a objective messaurement and maybe better. If I can express the same algorithm in half the lines of code, it is simpler right?

Here’s the Adler checksum algorithm in C:

const int MOD_ADLER = 65521;
uint32_t adler32(unsigned char *data, int32_t len) 
{
    uint32_t a = 1, b = 0;
    int32_t index;
    for (index = 0; index < len; ++index)
    {
        a = (a + data[index]) % MOD_ADLER;
        b = (b + a) % MOD_ADLER;
    }
    return (b << 16) | a;
}

12 lines of code

and here it is in clojure:

(def base 65521)
(defn cumulate [[a b] x]
    (let [a-prim (rem (+ a (bit-and x 255)) base)]
         [a-prim (+ b a-prim)]))
(derive clojure.lang.LazySeq ::collection)
(defmulti checksum class)
(defmethod checksum String [data]
    (checksum  (lazy-seq (.getBytes data))))
(defmethod checksum ::collection [data]
    (let [[a b] (reduce cumulate [1 0] data)]
          (bit-or (bit-shift-left b 16) a)))

11 lines of code

The latter should the be less complex, right?

I’ll leave this one open and hope for a discussion in the comments.

On Ticket goto GOTO;

Whoop, whoop. I’m in luck. It seems I have found a sponsor for a ticket for GOTO;!

Now that I dare hoping to attend, I have started to study the details of the program. One of the tracks has a day called “Distributed Systems Renaissance”, and that caught my interest, because distributed systems is a part of my day job.

One talk in particular caught my interest: “The Smallest Distributed System”. In distributed systems, one of the challenges is being robust to systems falling out and comming back online. This could be due to errors like network problems or due to planned downtime. No matter what, the rest of the system should continue to run and when the missing part is back online, it should be able to catch up whith what have happend while being down. Think of cash machines, that can run whithout connection to the bank. It happily hands out money and when it reconnects to the bank, all of the transations are transmitted. This also implies, that the account balance might not reflect how much money you actually have left the account, as some transactions might still be only in the cash machine. But eventually all transactions will be transmitted, so eventually the balance will be correct. This is more or less what eventual consistency is about, and this talk promis to address these issues.

Where I work, we have a produktion system holding about 1.2 million customers. Most of it is build from the ground up, and for the newest and most central parts, we have used things like Clojure and Datomic – and it’s distributed. Though I have been interested in and been building distributed systems for years now, there a still loads of stuff I should and could learn. I’m really hoping this talk can give me some more insight.

But man – when a glance through the program. It’s like a candy store and I’m starving.