peterjc

  • Så er GOTO CPH 2017 i fuld gang. Er fornyligt kommet på et projekt der efter alt sandsynlighed kommer til at leve som mikroservices i skyerne. Efter at have arbejdet i en branche der som udgangspunkt hold s […]

  • Det er efterhånden en del år siden jeg var til min første software konference. De har og vil sikkert altid bla. handle om hvad der er nyt og hvor vi er på vej hen.

    Men hvor meget af det der bliver hypet og […]

  • Sidder og bladre i dette års GOTO CPH program, og falder over en af deres søndags tracks, med titlen 360 Degree Developer. Det er tilsyneladende det nye, at nu skal man ikke KUN være udvikler, nu skal man væ […]

  • Det at skrive software er en kompliceret proces. Hvilket sprog, værktøjer for slet ikke at nævne valg af editor. Har man forstået domænet og meget andet.

    Men i sidste ende handler det om mennesker, og h […]

  • På dette års GOTO. Er der en masse stande fra diverse firmaer der har smarte logoer pamfletter mm. Midt bland dem står der med hvide bogstaver på konge blå baggrund “Skatteministeriet”. For at finde ud af hv […]

  • peterjc wrote a new post, GOTO new idea, on the site Peter Juhl Christiansen 2 years ago

    Disclaimer følgende tekst kan indeholde lommefilosofisk, højtravende humanist agtigt løsslupne tanker, uden egentlig hold i fakta.

    Software udvikling handler ofte om at få en go ide, hvilken løs […]

  • Ved en pool på Kreta står en strandstol og et lille bord. På bordet står et glas med White Russian og der ligger en bog, men hvilken bog? En bog om Phoenix. Men hvorfor en ikke en Stig Larson Roman eller til […]

  • Har tilbragt den første dag på GOTOcph med at se en masse spændende præsentationer.

    Havde på forhånd givet mig selv det lille benspænd, at fokusere på hvad der kunne give mig ideer og inspiration til at lave ko […]

  • I forbindelse med GOTOcph, har jeg i min kapasitet af blogger kastet mig ud i et interview med Ulrik Pagh Schultz .

    Giv en kort introduktion af hvem du er?
    Jeg er lektor ved Mærsk Instituttet, Syddansk […]

  • peterjc commented on the post, Et sip Elixir, on the site Peter Juhl Christiansen 3 years ago

    Tak for kommentaren! Godt at vide der er nogen der læser mine indlæg 😉

  • At skrive software er ikke just raketvidenskab men måske burde det være bare lidt mere som det. Tillad mig at forklare.

    I 2004 Fik jeg et job der sende mig til Bremen for at arbejde for på ESAs bidrag til de […]

    • Jeg havde også høje forventninger til Anita Senguptas præsentation til Goto; og jeg synes bestemt ikke at hun skuffede!

  • peterjc commented on the post, Et sip Elixir, on the site Peter Juhl Christiansen 3 years ago

    Du har ret der var gået noget galt med enkodningen af koden, har fikset det, tak for tippet

  • peterjc wrote a new post, Et sip Elixir, on the site Peter Juhl Christiansen 3 years ago

    Sidste år var jeg afsted på GotoCPH14, og skrev om det her på qed.dk. En af de ting der vakte min nysgerrighed var Elixir.

    Så efter konferencen besluttede jeg at det var noget jeg måtte lære. Følge […]

    • Du har ret der var gået noget galt med enkodningen af koden, har fikset det, tak for tippet

    • Tak for kommentaren! Godt at vide der er nogen der læser mine indlæg 😉

  • photo 1Har sat mig et mål, skjult dagsorden, for min deltagelse i GOTO.
    Det overordnede mål er at få noget med hjem, andet end kuglepenne og tømmermænd. Det er min holdning at hvis man ikke gør det på enten den korte eller lange bane så er det bare hygge og underholdning.
    Har en passion for bla. både Ruby og Clojure som begge er ting jeg har opdaget og fået med hjem fra en konference, og ved at lære og bruge disse sprog har jeg fået smag for at forbedre, optimere og refakturere selve udviklingen, både for mig personligt men også undersøge på et mere generelt plan hvordan vi som industri kan gøre ting bedre.
    Hvad der følger er resultatet af min søgen efter netop det.
    Swift er super-interessant, bla fordi det indeholder en masse ideer fra funktionel programmering, som jeg selv er blevet begejstret for ved bla. at kode Clojure. At de nu lever i Apples økosystem betyder at de er ved at blive mere udbredt. Mere specifikt understøtter Swift brugen af Map-Reduce og filter som enhver FPer elsker. Når man først får styr på dem, er det overraskende mange problemer, der blot er en liste af ting man enten laver om til en liste af andre ting, tager en del mængde af eller aggregere til en (eller flere ting), det er ganske enkelt en meget brugbar abstraktion som ikke bliver brugt nok.
    Det er for mig også tydeligt at mere og mere af vores software er drevet af events, og køre som en service, det gør at det giver mening at tænke og programmere mere event-orienteret, reactive og ved brug af async. Selv er jeg stor fan af CSP-modellen som man bl.a. finder den i Go-lang og helt sikkert noget jeg gerne vil dykke mere ned i.
    Når man har sagt “event” er det meget oplagt at sige Erlang, og det er uden tvivl en interessant platform og sprog, for mig er det mest det første. Ideerne og muligheden for at have milioner af processor på samme tid og trivielt distribuerer, observerer og kommunikerer med dem er super-brugbart. Netop derfor er Elixir klar noget jeg skal lege med, for det er et sprog der køre på Erlangs miljø, men har for mig at se en mere interesant syntax, og et par andre features som Erlang ikke har.
    Den måde jeg koder Java på har ændret sig efter jeg er bleve smittet med FP “buggen” bl.a. gør jeg mig umage for at så vidt muligt at undgå at lave “setters” til mine klasser, hvis jeg ikke har brug for dem. Blot lave en constructer, der spiser det, den skal bruge. Selvfølgelig kan man ikke undvære at sætte og ændre ting, men der forbavsende meget man ikke behøver at ændre, når man først tænker over det, og ved at have færre klasser og objekter, der indeholder “mutable state”, gør man livet nemmere for sig selv. Det var derfor også super-cool at se at C# har tænkt nøjagtigt det samme og bygget det ind i sproget at det er syntaktisk trivielt at lave “setter”-løse objekter. Lever godt nok ikke i C#-land men hatten af for at folkende bag gør, hvad de kan for at følge med tiden og gøre deres sprog nemmere at bruge. Kan så bare håbe deres ideer breder sig.
    En af de andre ting jeg utrolig gerne vil lege med er H2O som er et bibliotek til Machine Learning, det er open source og kan arbejde på store mængder data, super-effektivt. En af mændene  bag dette er Cliff Click, som jeg tidligere har hørt tale om, hvordan man gør ting smart og hurtigt. Efter min overbevisning er han blandt de ypperste eksperter inden for at få en computere til at gøre ting hurtigt, og han brugte ordet “fast” mange gange i sin gennemgang af H2O, og når har siger “fast”, mener han det og ved hvad han snakker om. Har leget med ML og synes det er super-cool, så ser frem til at kunne bruge H2O til at tygge på store mængder data.
    Det som var den mindst tekniske talk, men alligevel den der var bedst og gjorde størst indtryk var Russ Olsens “To the Moon”. Det var en meget medrivende gennemgang af, hvordan noget så nærmest sindsygt og umuligt som at komme til månen alligevel, med nød og næppe lykkedes tilsidst. Der var mange ting man kunne lære af de skøre “Rocket Scientist”, men mest af alt var det, at man aldrig skal sige noget er umuligt, og at vi alle bør lade os inspirere af Kennedys famøse citat:
    “We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard”
    Lad os huske det var ingeniører som os der gjorde det, og gå ud og gøre noget der er svært.

  • photo 2Som opvarming til GOTO skrev jeg et indlæg om immutability, hvor jeg MEGET kort forklare hvad det er og hvorfor jeg klart skulle se David Nolens indlæg om netop det her på GOTO. Så hermed opfølgeren.

    Fordraget startede med et hurtigt historisk view, hvor han nævnte at nogle af ideerne bag immutability i virkeligheden har mange år på bagen, men at det først er for nyligt at det faktisk er udmundet i konkrete implementationer. Derefter gik han et skridt dybere og gav en kort forklaring af hvordan en immutable datastruktur kan implementeres på en effektiv måde, med brug af et koncept kaldet Tries (som er en speciel type søgetræer), og hvordan man med strukturel deling kan gøre det rimeligt effektivt at konstruere en ny “kopi” af datastrukturen, hvor den primære del (som så ikke er ændret) kan være delt. Som han nævnte, er det nemmere at forstå, hvorfor de er værd at bruge, når man kender principperne bag og har en basal forståelse af hvordan det virker, hvilket hans gennemgang meget klart gav.

    Efterfølgende viste han at det i den naive tilgang kostede ca. en faktor to at bruge immutable arrays frem for klassiske JavaScript-arrays, samt at der i Clojurescript, som er en dialekt af Clojure der oversættes til JavaScript, faktisk findes simple tricks der gør at “opdateringer” af en immutable array var hurtigst.

    Ind på scenen fra venstre kommer React, som er et facebook-bibliotek til at lave brugerflader i JavaScript. Måden det virker på er, at det har den aktuelle tilstand af din DOM. Du fortæller den hvordan du ønsker DOMen skal se ud, og den beregner en diff som den så på snedig vis kan bruge til effektivt opdatere din DOM og din webside.

    Den ide som Nolen fik, var at koble Reacts og Clojurescripts fikse ide med immutable datastrukturer til et bibliotek kaldet OM, som pudsigt nok faktisk var hurtigere end standard brug af React. Derefter opdagede han at når man nemt kan beregne forskellen mellem A og B for at komme til tilstand B, kan man også vende det om og trivielt gå baglæns, hvilket gør “undo” trivielt.

    Vi kan vel alle blive enige om at det der internet ikke forsvinder sådan lige med det samme, og React er opstået fordi Facebook, ønsker at udvikle hurtigere og bedre web applikationer, og formodentligt også med brug af bedre abstraktioner. Derfor er det særdeles interessant at det kan gøres både simple og mere effektivt med brugen af immutable datastrukturer, hvilket må siges at være en rigtig god grund til at tage konceptet alvorligt og undersøge om det også i andre sammenhænge er en bedre og mere effektiv abstraktion.

    Nolen er en god og passioneret taler og jeg synes han kom udover rampen og fik tilhørene interesseret i, hvad han havde at sige. Ville dog ønske at han havde diskuteret flere af de interessante egenskaber ved disse datastrukturer. Det er til dels forståeligt at han valgte at fokusere, men omvendt er det jo den overordnet ide med immutable datastrukturer som er værd at fremhæve og diskutere. De spørgsmål der kom fra salen gav dog mulighed for at fremhæve nogle af disse, fx at de er “lock fri” og derfor er geniale i en multi-trådet verden.

    Der er meget der tyder på, at det er noget man kommer til at se mere til f.eks. har Facebook lavet en håndfuld immutable datastrukurer i JavaScript, som folk så bl.a. kan bruge sammen med React, og der skal ikke meget fantasi til at gætte hvor de har den ide fra.

    Desuden dukkede immutable også op i et oplæg om SWIFT som jeg så tidligere på dagen. Hvor langt Apple og SWIFT folkene er gået med immutability ved jeg ikke, men med udbredelsen af iPhones og React mm. er der noget der tyder på at funktionel programmering og ideerne derfra, er ved at blive mere og mere udbredt i takt med at flere og flere mærker bagsiden og ulemperne ved at vi i nogle år troede at svaret på alt universet og alting var OO. Det er det efter min mening ikke nødvendigvis. Så lad os forsætte søgen efter bedre måder at lave software på …“we are not there yet”.

  • DSC_0524

    Forestil dig, man har en data struktur S lad os kalde den D0. Ønsker man at “ændre” noget putter man den fx. i en funktion f(D0,x) => D1. D0 er helt som den var før, og D1 er frisk og ny.

    Hvis du er bekendt med “immutable” data-strukturer, tænker du sikkert; ja ja, det ved enhver jo. Hvis du ikke er, så tænker du nok, det lyder dyrt at lave en kopi hver gang man skal lave en opdatering, og hvorfor skulle det overhovedet være smart?

    Den første del er i teorien simpel. D0 og D1 deler det der er det samme, så man ikke behøver at lave en kopi for hver ændring. Rent praktisk er der en masse voodoo og snedige algoritmer i spil, men det overlader jeg til læseren. Det som jeg hellere vil grave i er, hvorfor betale den, ganske vist lille pris for at opnå immutability?

    Lavpraktisk er multitrådede programmer pludseligt blevet trivielt og “lock free”, hvilket er en ikke uvæsentlig gevinst, og ifølge den famøse artikel “Out of the Tar Pit”, er den vigtigste kilde til unødig kompleksitet “shared-mutable-state”. Unødig kompleksitet definerer de som den kompleksitet der ikke kommer fra selve det problem man prøver at løse, men fra måden man løser det på.

    Desuden er immutability konceptuelt tættere på, hvordan den virklige verden vi prøver at emulere faktisk ser ud, noget som Rich Hickey glimrende uddyber i sin GOTO Copenhagen keynote “The value of values” fra 2012. Mens jeg her til aften skriver dette blogindlæg hedder jeg Peter. Det er et faktum der ikke vil ændre sig – det kan være min numerolog finder et nyt navn til mig på mandag, men hvad jeg hedder på dette tidspunkt kommer ikke til at ændre sig. Det lyder jo oplagt og burde vel også være måden man betragter verden med software-briller på.

    Af historiske grunde er det bare ikke sådan vi programmører har lært at tænke, og alle de gange jeg med begejstring over en øl skulle forklare mine software-skrivende venner hvorfor Clojure og dets immutable data strukturer er super-cool er jeg kommet til kort. Den gammeldags “mutable” måde at tænke på sidder fast i de fleste, og altså med til at gøre vores software mere komplekst end det behøver at være.

    Mit gæt er at David Nolen, der taler torsdag eftermiddag på GOTO Copenhagen, netop om Immutability, også har forsøgt at forklare, hvorfor det er så smart, og derfor har valgt det emne. Det er helt klart mit håb både at få yderligere viden om anvendeligheden af immutability, og også få en håndfuld argumenter til næste gang jeg over en fredagsøl, skal forklare det geniale ved uforanderlig data.

  • ns14Var for nogle dage siden på musikfestivalen Northside, og lad mig lige starte med at sige det var en fantastisk festival med mange gode optrædender, og at dømme efter stemningen lykkedes det også de fleste at købe de øl de gerne vil have, men ikke uden lidt mere besvær end normalt.

    Man havde nemlig på dette års NorthSide festival valgt at prøve noget nyt og smart: Payband, hvor man med en chip der sidder på ens festivalarmbånd kan foretage betalinger. Det spændende initiativ blev jeg og alle de andre gæster informeret om via en mail, et par dage før det hele gik i luften.

    Ved at oprette en  my.beeptify.dk-konto inden kunne man spare at skulle stå i kø ved en såkaldt PayBand-station, hed det sig.

    Som arbejdende i informations-teknologi-branchen, var jeg på en gang nysgerrig og en anelse skeptisk. Det lød jo smart, men ville det nu virkelig være så smart som vi blev stillet i udsigt? Hvem vil ikke gerne IKKE stå i kø, tænkte jeg og hoppede ind på beeptify-hjemmesiden og oprettede mig. Det gik sådan set nemt, overførte 200 til min nye beeptify-konto med det samme, så havde jeg da lidt til den første øl, men som erfaren festivalgænger valgte jeg nu at medbringe både mit dankort og en håndfuld kontanter, (klogt træk skulle det vise sig).

    Frisk ankommet til festivalen iført armbånd med en tilhørende payband-plastikbrik, gik jeg direkte efter den første bar. Min logiske sans sagde mig, at på en eller anden måde, skulle min fikse plastikbrik parres med min online beeptify-persona og forventede egentlig ikke det var noget de kunne klare i baren, men tog chancen. Ganske rigtigt, man skulle forbi en PayBand-station for at aktivere armbåndet (så meget for ikke at skulle stå i kø), mindre forhindring men pyt, havde jo god gammeldags kongens mønt (god robust, decentral, offline, skalerbar og særdeles enkelt betalingsteknologi).

    Med øl i hånd så afsted til PayBand-stationskøen. Efter lidt kø-ståning kom en flink og hjælpsom mand hen og spurgte mig og de to foran mig i køen helt nøjagtigt hvad vi skulle i PayBand-stationskøen. Efter at have afgivet en kort forklaring blev vi informeret at jo vi skulle stå i den kø vi stod i. Pyhh det var heldigt… noget der er mere æv end kø-ståning er unødvendig, forkert eller forgæves kø-ståning.

    Fremme ved en PC, kunne armbåndet endelig aktiveres, og parres med min beeptify-konto, naiv som jeg var, troede jeg, at de penge jeg havde overført til beeptify nu var klar til brug. Næ nej, min “armbånds-konto” var tom og så skulle jeg endnu engang give beeptify mine kortoplysninger?? Og ingen af de skærmbilleder jeg var i stand til at frembringe, antydede eksistensen af de 200, jeg havde overført for nogle dage siden. Gad vide om mine 200 er blevet væk i deres system, var min første tanke. Det viste sig senere, da jeg fra min egen PC loggede på, at det var de ikke. Nu havde jeg bare to konti, og heldigvis kunne jeg så flytte fra en konto til en anden, så mine 200 endelig kunne blive til øl og burgere.

    Alt hvad jeg har beskrevet indtil nu var bare bump på vejen og børnesygdomme som systemet nok ikke skulle være taget på festival med, det egentlige spørgsmål var hvordan det så ville virke når man så endelig kom igang.

    Desværre var det også en lidt blandet oplevelse, de første par betalinger gik helt som planlagt, uden at have tænkt over det, havde jeg nok troet, at det ville være nok at flashe sin chip en gang til chiplæseren pr. betaling, men man skulle åbenbart først indlæses for at se om der var penge nok, derefter skulle man indlæses igen for at udføre betalingen. Som bruger synes det som unødigt omstændig, men trods alt stadig lettere end dankort eller kontanter.  Men der skulle ikke gå længe før jeg oplevede at systemet svigtede, først ved at den der stod foran mig i køen fik at vide de ikke kunne betale med chip, og uden alternativ betaling måtte de forlade baren uden to kander øl plus det løse som ellers lige var sat på disken. Så var der en bag mig der gik frem og spurgte om det nu var rigtigt at man ikke kunne betale med chip, for så var der ingen grund for ham til at stå i kø. Heldigvis for mig havde jeg de gode gammeldags kontanter som plan B, så jeg slap for en gang forgæves kø-ståning.

    Lignende episoder oplevede jeg flere gange, frustrede kunder og stakkels bartender der måtte råbe ud over menneskemængden “kun kontanter”. En af de sidste gange jeg brugte min chip, hvor det ellers forløb som det skulle spurgte ekspedienten om jeg kunne bekræfte at jeg var personen tilknyttet kontoen, hvor til jeg svarede ja (fordi hun heldigvis sagde mit navn), hvortil jeg så sagde “det plejer jeg da ikke at blive spurgt om”, og fik svaret at der havde været problemer hvor systemet havde indlæst en forkert konto – ups, ikke godt!!

    Til beeptifys forsvar skal det siges de var massivt til stede og det virkede da også lidt som om det blev bedre hen ad vejen, men det ændrer ikke ved at det langtfra løb efter planen og bestemt ikke virkede som et 100% modent produkt, da festivalen gik igang.

    Som en helt almindelig øl-drikkende bruger har jeg ikke mulighed for at vurdere, hvad de forskellige problemer skyldes, om det blot var børnesygdomme der skyldes det ikke var testet så godt som man kunne have ønsket, eller om det var selve arkitekturen og systemet der simplethen ikke er robust nok, og har for mange “single points of failure” og for lidt fejlhåndtering og resistens bygget ind.

    Det sidder der forhåbentlig nogen og grubler over nu. Så håber jeg da at at næste gang jeg skal betale med chip, at det går lidt bedre.

    Inden for udvikling af kritiske systemer arbejder man med at være “one failure tolerant”, dvs. hvis en del af systemet eller en komponent fejler så fejler systemet som helhed ikke, specielt propagerer fejl heller ikke. Typisk vil man analysere alle de mulige fejlscenarier man kan komme i tanke om at verificere, og så vidt muligt teste at systemet kan håndtere dem, således at systemet først går ned når to uafhængige komponenter svigter samtidig.

    En øvelse jeg bestemt håber folkene bag payband har gjort, for som festivalgæst er det, ikke at kunne få en øl, rimelig kritisk.

    Kan ikke lade være med at tænke, kan vi som branche og industri ikke snart komme videre og komme ud af “har du husket at reboote” tidsalderen? Folkene bag “the Reactive Manifesto” synes det er tid og har sammenfattet en liste af ting man bør tage i betragtning, når man lave systemer idag, hvilket Helena så udmærket har beskrevet i sit blogindlæg om emnet og som, GOTOerne i år har gjort til et tema ved at dedikere en eftermiddag til at fremlægge det og forhåbentligt få en diskussion i gang.

    Men hvorfor vente? Lad os starte diskussionen nu, og fortæl gerne om dine oplevelser med nogle af de IT-systemer vi omgiver os med som godt kunne have haft glæde af lidt “Reactive” tænkning.

  • Ja og tænk de faktisk har studier der viser at man bliver mere kreativ af at gå tilfældigt rundt

  • Glimrende artikel, det fænomen du beskriver er faktisk velkendt inden for physkologien og hjerne forskning, og siden jeg første gang læste om det har det også ændret den måde jeg arbejder på.

    Det hænger […]

  • Er meget enig, og kunne ikke have udtrykt det bedre selv. For mig handler det bestemt både om nysgerrighed og ydmyghed. føler at hvis jeg ikke flytter mig, så bliver jeg hægtet af! Der er så mange kloge og seje […]

  • Load More