#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.

Konferencer i efteråret

Det er ikke nogen hemmelighed, at jeg holder af konferencer. Henover sommeren har jeg kigget på efterårets konferencer, og jeg har også kigget på budgettet, så jeg har udvalgt to, som jeg har tænkt mig at tage på.

GOTO; – 5-6. Oktober
Dette er en fast, tilbagevendende konference på mit program. Den er vigtig for mig af flere årsager. Dels er der det faglige input, men også det at møde de andre deltagere, at sludre med talerne fylder meget.
I år afholdes konferencen i København og jeg er meget spændt på hvordan det bliver. Trifork har tidligere forsøgt sig med at afholde Goto i København, men jeg kan forstå det var med begrænset succes. Jeg deltog, og jeg syntes den var meget anderledes en konferencen i Aarhus. Jeg kunne bedst lide Aarhus. Det er måske også derfor, at jeg er en smule skeptisk overfor at konferencen nu flytter til Hovedstaden. Det ærgrer mig også en smule, for jeg holder meget af Aarhus by og det var rart at få et par dage væk, hvor dagligdagen kom på behørig afstand. Jeg er bange for det ikke sker denne gang. Jeg overvejer endda at booke hotel, selvom jeg kunne cykle hjem, blot for at få fornemmelsen af, at hverdag og arbejde er langt væk.

Til dagligt arbejder jeg med Big Data, Predictive Analysis og Machine Learning, så det er selvfølgelig med det i baghovedet, at jeg kigger på årets program. Det er ikke noget spor, der er decideret navngivet “Big Data”, men noget der ligner: “The State of Data”. I beskrivelsen nævnes “machine learning”, “data analytics” og “scalability techniques”, hvilket jeg i min naive, håbefulde verden, læser som værende netop mit område. Heldigvis er hele tirsdagen sat af til dette spor.

Mit barnehjerte kan selvfølgelig også blive tilfredsstillet, håber jeg, med sporet “Robotics and Drones” mandag eftermiddag. Her glæder jeg mig til at høre “The New Frontier of Robotics”, som jeg håber handler om krydsfeltet mellem robotter og kunstig intelligens. I hvert fald er dette taleren Søren Tranberg Hansens bagrund.
…og så selvfølgelig keynoten “Curiosity’s Entry Descent and Landing on Mars”, vis titel vist giver sig selv.

Normalt kigger jeg også talerlisten igennem og vælge nogle talks på den baggrund, men i år synes jeg ikke rigtig at der er nogen som springer i øjnene. Jeg skal selvfølgelig høre Dave Thomas, fordi han er Dave Thomas. Det er ikke så vigtigt hvad han taler om, han er altid værd at lytte til. I år taler han så tilfældigvis om The State og Data, så jeg er dobbelt heldig.
Et andet navn der springer i øjnene, er Janne Jul Jensen, der skal tale om UX og det heldigvis som keynote, så det kommer ikke til at kollidere med mine andre ønsker.

Spark Summit, Amsterdam – 27-29. oktober
Spark Summit er for mig en ny konference, der – som navnet angiver – er centreret om Apache Spark projektet. Da jeg ikke har været til denne konference før, ved jeg selvfølgelig ikke hvad jeg skal forvente. Der er dog nogle interessant punkter i planen, som har fanget min interesse og er årsagen til, at jeg tager til konferencen:

“Building a REST Job Server for interactive Spark as a service”
At the moment we are running a lot of batch jobs, and I’m very interested to see, if I could transform some of them to more interactive services. My hope is to get some pointers from this talk.

“A Scalable Implementation of Deep Learning on Spark”
I also use a lot with Machine Learning algorithms in my daily work, but not any deep learning algorithms, but is of course interested to learn about the possibilities in Spark.

“Using Natural Language Processing on Non-Textual Data with MLLib”
Sidste sommer kodede jeg en dims der kunne klassificere tekster. Den var ret god til at klassificere og kunne klassificere i 3 niveauer:

  • Hvad man kunne kalde “den større sammenhæng” – om det var nationalt, europæisk eller globalt emne.
  • Tekstens overordnede emne, f.eks. kultur, økonomi, politik og et par stykker mere.
  • Tekstens indhold, f.eks. VM i fodbold, Tour de France eller koncertanmeldelse – for at nævne nogle stykker.

Algoritmen var en Bayesian learning algoritme, som jeg havde hånd-tweaket med lidt ML-fu fra min værktøjkasse. Algoritmen fungerede ret godt. Jeg har siden brugt samme algoritme til at klassificere andet data en tekster, og har haft en del succes med det. Derfor er jeg ret spændt på at høre, hvad andre har forsøgt sig med og hvilke resultater de har fået.

“Combining the Strengths of MLlib, scikit-learn, and R”
Jeg er storforbruger af både MLlib og scikit-learn, men dog ikke R, så hvis de på nogen måde kan kombineres på måder jeg ikke har tænkt på, er jeg interesseret i at høre om det. Om ikke andet, finder jeg det enormt motiverende at høre, at andre har tænkt tanker, der minder om mine egne.

Verbose

I do most of my development in python and scala these days. I totally forgot how verbose java is until I saw some Apache Spark coding examples.

Code in python

file = spark.textFile("hdfs://...")
errors = file.filter(lambda line: "ERROR" in line)
# Count all the errors
errors.count()
# Count errors mentioning MySQL
errors.filter(lambda line: "MySQL" in line).count()
# Fetch the MySQL errors as an array of strings
errors.filter(lambda line: "MySQL" in line).collect()

The same code in Scala:

val file = spark.textFile("hdfs://...")
val errors = file.filter(line => line.contains("ERROR"))
// Count all the errors
errors.count()
// Count errors mentioning MySQL
errors.filter(line => line.contains("MySQL")).count()
// Fetch the MySQL errors as an array of strings
errors.filter(line => line.contains("MySQL")).collect()

And finally in Java:

JavaRDD<String> file = spark.textFile("hdfs://...");
JavaRDD<String> errors = file.filter(new Function<String, Boolean>() {
  public Boolean call(String s) { return s.contains("ERROR"); }
});
// Count all the errors
errors.count();
// Count errors mentioning MySQL
errors.filter(new Function<String, Boolean>() {
  public Boolean call(String s) { return s.contains("MySQL"); }
}).count();
// Fetch the MySQL errors as an array of strings
errors.filter(new Function<String, Boolean>() {
  public Boolean call(String s) { return s.contains("MySQL"); }
}).collect();

Twice as many lines of code.

Nye græsmarker

Jeg har fået nyt job. Det lyder uvirkeligt for mig, når jeg siger det, men det har jeg altså. I mange år har jeg lavet software i telebranchen, hvilket har været spændende, men min oprindelige specialisering fra universitetet lå et andet sted: Maskinindlæring. Ja, jeg bruger et dansk ord for Machine Learning; jeg kan godt lide danske ord. Nå, men jeg har altså været heldig og fik tilbudt et job i en virksomhed, hvor jeg skal arbejde med netop maskinindlæring.

I virksomheden modtager vi enorme mængder at data, som vi laver analyser på. Big Data, som det jo populært hedder. Når virksomheden siger Big Data, er det ikke blot et buzzword, for der er tale om virkelig store mængder af data. Det jeg hørte var, at de har i omegnen af 100 maskiner, som ikke laver andet, end at modtage og forbehandle data. En af kunderne er Google. Det de gerne vil nu, er at finde yderligere information i en data, end de de allerede kan grave ud af den, med almindelige statistiske metoder. Det er her maskinindlæring, og derved jeg, kommer ind i billedet. Det kommer der et blogindlæg ud af snart, men først lidt om årets goto.

I de sidste par år, har min fokus mest ligget på funktionelle sprog og jeg har blandt andet været på rene clojurekonferencer. I september tager jeg på årets goto i Aarhus, og jeg har tænkt mig at prioritere det spor, der omhandler “Enterprise Architectures”. Årsagen er, at sporet blandt andet berører Big Data og at Mr. Scala, Dean Wampler kommer og taler om Spark, som er en af de teknologier jeg arbejder med nu.

Desværre ser den nye form ikke ud til at passe helt til mine interesser, for det ser ud til, at de mest spændende ting kommer til at foregå samtidig, bare i forskellige spor. Det er ærgrer mig en del, men til gengæld glæder jeg mig til at mødes med mine kollegaer i branchen, hvoraf en del af dem betragtes som venner, efter vi har mødtes så mange gange på konferencer, opgaver og arrangementer i andre sammenhænge.

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 &lt; len; ++index)
    {
        a = (a + data[index]) % MOD_ADLER;
        b = (b + a) % MOD_ADLER;
    }
    return (b &lt;&lt; 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.

Keep it simple

To sum up the first part of day 1 of GOTO Conference, I must say there’s a pattern in otherwise unrelated talks: simplicity.

“Programming is hard”, says Donald Knuth. It seems that the speakers all agree, we should stop making it even harder. We tend to, says Russell Miles. “We do it out of boredom”. He argues, that if the task at hand is boring, doesn’t inspire us or is simply just to simple, we tend to try and make it interesting, by making it more complicated. “Uh, I always wanted to look into python. Maybe and can solve the task using that”. And – oh – look and behold. Trouble down the road. But Russel also have a suggestion on how to avoid the complexty we tend to introduce our selfes. He call it O.R.E. – or Organize, Reduce and Encapsulate.

He argues that organizing is nothing more than identifying if a part of a module has to know about the outside world or not. If it does, it is integration, if it doesn’t it is core. Database access? Integration. Rest services? Integration. Business rule? Well, if all data is supplied by the integration parts, I guess it’s core.
He also argues, that integrations should be kept at a minimum af knowledge about the other parts to avoid entanglement. Just pass simple data documents and parse whatever you can understand. “Be liberal in what you accept”. By deciding that data should be immutable, he argues that this also helps in reducing complexity. He says, that to his experience, it will end up looking like functional programming and have a reduce complexity and entanglement. I’m already doing functional programming in clojure, so if it is true, that it ends up looking like functional programming, I would say that he is more or less correct in the rest of his arguments.

Simplicity also seems to be the keyword in the next talk with Mathias Meyer about Travis CI, a hosted,continous integration platform. In the talk, he tels the story about how they redesigned the system from a monolithic architecture to a scalable architecture, build from small, distributed parts. But more about that in a later post. Still have some digesting to do.