Daily Archives: March 23, 2014

En af de gængse teorier om, hvordan Jorden fik liv, går ud på, at det blev bragt hertil af meteoritter og herefter udviklede sig.

Men den britiske kemiker dr. Terry Kee fra University of Leeds mener, at livet sagtens kan have udviklet sig uden hjælp udefra.

Livet formodes at handle om, at celler har fået et stofskifte, og det er dette stofskifte eller forbrænding, Terry Kees forskergruppe har koncentreret sig om.

»Vi prøver at bygge bro mellem den tidlige Jords geologiske processer og fremkomsten af biologisk liv her på planeten,« siger Terry Kee i en pressemeddelelse.

Forskergruppen har taget fat i antagelsen om, at livet udviklede sig dybt på havets bund fra livløst stof, såsom kemiske forbindelser i gasser og mineraler.

Terry Kee holder fast i, at denne proces handler om, at der har eksisteret en slags geologisk liv, før det biologiske opstod.

»Det virker måske usædvanligt at snakke om, at geologi som sten og mineraler kan være levende. Men hvad er liv?« spørger Terry Kee, som i mangel på et tilfredsstillende svar har besluttet sig for at se på det på samme måde som den energi, der skabes i f.eks. brændselsceller.

Her handler det om at danne elektrisk energi, når et molekyle bliver oxideret og mister elektroner, mens et andet får elektroner.

Det er nogenlunde samme proces som i fotosyntesen i planter, hvor CO2 bliver til sukkerstoffer og vand til ilt, eller i mennesker, når vores celler omdanner sukker til CO2 og ilt til vand.

I den britiske undersøgelse af forholdene har Terry Kee og hans hold fremstillet en simuleringsmaskine i form af en brændselscelle, som skal vise, hvordan livet på Jorden kan være opstået ved de samme energiskabende processer.

Forskerne kigger især på de elektrisk ledende mineraler jern og nikkel, da de var til stede meget tidligt i Jordens historie, og de beviste, at både jern og nikkel kunne generere energi i deres proof-of-concept-brændselscelle.

De er dog stadig ikke helt sikre på, hvordan det geologiske liv blev til biologisk, men understreger, at de mener at være et skridt på vejen mod en forståelse.

Forskningen er publiceret i tidsskriftet Astrobiology, og det er forskernes håb, at deres simulering kan vise, om samme proces kan lade sig gøre eller har været i spil på andre planeter.

Se Terry Kee vise maskineriet frem i videoen nedenfor og fortælle om sammenhængen mellem livet på Jorden og en brændselscelle.

Næste version af programmeringssproget JavaScript ES6, også kendt under kodenavnet harmony, indeholder rigtig mange forbedringer. En af dem er generators, som rummer nogle interessante muligheder for asynkron JavaScript-kode.

Kort introduktion til generators

Generators er en speciel ny type funktion. Generator-funktionen er en slags constructor.

At kalde generator-funktionen giver dig et objekt, der kan generere værdier, en værdi ad gangen, efterhånden som du beder om den næste værdi.

Det kunne for eksempel være en generator, der giver dig heltallene fra 1 og opefter (1, 2, 3, 4, 5, 6, …):

Læg mærke til stjernen * efter function. Stjernen gør funktionen til en generator, og dermed får du muligheden for at bruge yield-kommandoen.

Du kalder generator-funktionen som en constructor, det giver dig et generator-objekt. Generator-objektet har metoden next(), som du kalder for at få den næste værdi i rækken:

Første gang du kalder next() svarer det til, at heltalGenerator-funktionen bliver kørt som en normal JavaScript-funktion.

Det nye er, at heltalGenerator har en yield-kommando.
Når funktionens eksekvering ramme yield-kommandoen, bliver værdien der yield-es returneret som value i det objekt, som du får tilbage, når du kalder next(). Herefter er generatoren “sat på pause” på det punkt i koden, hvor yield blev kaldt.

Næste gang next() kaldes, genoptager heltalGenerator-funktionen eksekveringen fra det sted den blev sat på pause. Alstå eksekveringen genoptages det sted, hvor heltalGenerator kaldte yield. Reultatet er, at heltalGenerator-funktionen yield-er n og tæller den en op hver gang next() kaldes, og dermed generer tallene 1, 2, 3, 4, …

Hvis nu vi omskriver heltalGenerator-funktionen en smule:

… kan vi tildele variablen nyStart en værdi, når vi kalder next(). Dermed kan vi få generatoren til at genere tal fra et nyt startpunkt:

Der hvor generator-funktionen blev “sat på pause” af at kalde yield, kan vi sende en værdi tilbage i funktionen, til når den genoptager sin eksekvering.

Som du måske kan se, kan generators bruges til mange spændende ting. Lad os kigge på en måde at bruge dem på i forhold til asynkrone kald.

Asynkrone IO-kald

Lad os først kigge på et meget forsimplet eksempel:

Resultatet af at køre kode er, at der efter 100 millisekunder udskrives:

De første tre linjer er de vigtige i eksemplet. Jeg kalder den asynkrone databaseOpslag-funktion, og giver den en callback-funktion, som skal kaldes når databaseOpslag-funktionen er færdig med I/O-operationen og har et resultat klar.

Det er et meget brugt pattern i JavaScript. Både i browseren og på serveren i node.js. Nogle gange er det lavet med promises eller andre måder at lave flow-control. I node.js er det mest almindelige at bruge callbacks, som i eksemplet.

Problemet

Problemerne med denne måde at skrive sin kode er blandt andet:

• Den “støj” det giver i koden at du skal definere en callback-funktion. Function er et langt keyword, og der skal også skrives paranteser og tuborg-klammer.
• Callbacks giver et niveau af indentering. Koden rykkes et niveau ind med tab eller spaces. Dette kan delvist afhjælpes med function-hoisting, men ikke helt.
• Når der tilføjes fejlhåndtering i hver callback, giver det endnu mere støj i koden. Dette kan afhjælpes en del med fx promises, eller andre former for flow-control-hjælpere. Jeg er ikke særlig vild med nogen af dem. Blandt andet på grund af det simple faktum, at stort set alle node.js-moduler bruger callbacks.
• Hvis det logiske flow i koden kompliceres af forgreninger i if-else-statements, kan koden blive meget svær at læse. Og her er det ligemeget om du bruger callbacks, promises eller andre flow-control-libraries. Der er simpelthen for meget syntaktisk “støj” i koden, i alle de løsninger jeg har set.

Generators brugt til at gøre kode med asynkrone kald mere læsevenlig

Generators giver en spændende ny mulighed for at takle problemerne beskrevet ovenfor.

Forklaring af koden:

• run-funktionen fungerer på en sådan måde, at den generator-funktion run kaldes med som parameter, forventes at lave asynkrone operationer. I dette eksemplel er det code-funktionen der laver den asynkrone operation, nemlig database-kaldet.
• code-funktionen skal yield-e når den laver den asynkrone operation i kaldet til databaseOperation og bliver dermed sat på pause.
• code-funktionen sørger for at bruge resume-funktionen som den callback-funktion der skal kaldes når den asynkrone databaseOperation er færdig og har resultatet klar.
• resume-funktionen kalder next() med resultatet af den asynkrone operation, og sender dermed resultatet tilbage ind i code-funktionen, der hvor den blev “sat på pause”

Resultatet af at køre kode er igen, at der efter 100 millisekunder udskrives:

Slutresultatet er at den oprindelige kode:

… nu kan skrives som:

Det virker måske ikke så imponerende. Men hvis vi nu forestiller os en funktion med fire databaseoperationer, der skal udføres serielt efter hinanden, fordi resultatet af hver database-operation skal bruges til den videre behandling:

… så kan vi bruge run til at skrive det samme sådan:

.. så kan du måske ane nogle muligheder?

Discalimer

Koden ovenfor er kun ment som meget forsimplede eksempler. Koden skal illustrere generators og konceptet med at bruge dem til asynkrone kald. Det er på ingen måde ment som kode, der skal bruges til noget som helst andet end at illustrere disse koncepter.

Hvis du vil se en produktions-klar implementation af konceptet, kan du kigge på suspend-modulet, som jeg synes har den bedste implementation. Suspend-modulets implementation har også håndtering af fejl, kan bruges med asynkrone kald med promises eller thunks og kan håndtere at køre flere asynkrone kald parallelt.

Et andet populært modul er co.

Jeg siger ikke, at du skal til at skrive al din asynkrone kode med det pattern beskrevet ovenfor. Jeg bruger det ikke selv (endnu). Dette er bare et debat-oplæg.

Hvornår kan jeg bruge ES6?

I første omgang har ES6 nok størst interesse for programmører der bruger JavaScript på serveren i node.js. Det kommer til at tage mange år, før du kan regne med, at alle dine brugeres browsere understøtter de nye features. Der er dog en mulighed for at bruge ES6-features i din kode i dag, og samtidigt sikre at dit website virker i browsere der kun har ES5. Du kan bruge traceur-kompileren der kompilerer ES6 til ES5.

For at bruge ES6 i node.js kræver det at du kører den ikke-produktionsmodne version 0.11 af node.js (tag den nyeste).

Du skal køre node.js med kommandoline-parameteren –harmony. Det er sådan, jeg har testet kode-eksemplerne i denne blogpost.

Jeg vil tro, at generators er med i version 0.12 af node.js, som er den næste stable release.

ES6 har meget andet spændende

Hvad bruger du til flow-control i din JavaScript-kode?

ES6 har mange andre spændende nye features. Har du en favorit?