Hacks

I de sidste 10 år har der været en eksplosiv interesse for “videnskabelig databehandling” og “datavidenskab”, dvs. anvendelse af databehandling til at besvare spørgsmål og analysere data inden for naturvidenskab og samfundsvidenskab. For at imødekomme disse behov har vi oplevet en renæssance inden for programmeringssprog, værktøjer og teknikker, der hjælper videnskabsfolk og forskere med at udforske og forstå data og videnskabelige koncepter og med at kommunikere deres resultater. Men indtil nu er der meget få værktøjer, der har fokuseret på at hjælpe forskere med at få ufiltreret adgang til det fulde kommunikationspotentiale i moderne webbrowsere. Så i dag glæder vi os til at præsentere Iodide, et eksperimentelt værktøj, der skal hjælpe forskere med at skrive smukke interaktive dokumenter ved hjælp af webteknologier, alt sammen inden for en iterativ arbejdsgang, der føles som andre videnskabelige computermiljøer.

Ud over blot at være et programmeringsmiljø til at skabe levende dokumenter i browseren forsøger Iodide at fjerne friktion fra kommunikative arbejdsgange ved altid at bundle redigeringsværktøjet med det rene læsbare dokument. Dette adskiller sig fra IDE-lignende miljøer, der udsender præsentationsdokumenter som f.eks. pdf-filer (som så er adskilt fra den oprindelige kode) og cellebaserede notesbøger, som blander kode og præsentationselementer. I Iodide kan du både få et dokument, der ser ud, som du vil have det til at se ud, og nem adgang til den underliggende kode og redigeringsmiljøet.

Iodide er stadig i høj grad i en alfatilstand, men i overensstemmelse med internetaforismen “Hvis du ikke er flov over den første version af dit produkt, har du lanceret det for sent”, har vi besluttet at lave en meget tidlig soft launch i håb om at få feedback fra et større fællesskab. Vi har en demo, som du kan prøve lige nu, men forvent en masse ujævne kanter (og brug venligst ikke denne alpha-udgave til kritisk arbejde!). Vi håber, at du på trods af de grove kanter vil kunne se værdien af konceptet, hvis du kniber øjnene sammen, og at den feedback, du giver os, vil hjælpe os med at finde ud af, hvor vi skal gå hen næste gang.

Hvordan vi kom til Iodide

Datavidenskab hos Mozilla

I Mozilla er langt størstedelen af vores datavidenskabelige arbejde fokuseret på kommunikation. Selv om vi nogle gange implementerer modeller, der har til formål at forbedre en brugers oplevelse direkte, f.eks. den anbefalingsmotor, der hjælper brugerne med at opdage browserudvidelser, analyserer vores datavidenskabsfolk for det meste af tiden vores data for at finde og dele indsigter, der kan informere produktchefer, ingeniører og ledere om deres beslutninger.

Datavidenskabsarbejde indebærer at skrive en masse kode, men i modsætning til traditionel softwareudvikling er vores mål at besvare spørgsmål, ikke at producere software. Dette resulterer typisk i en eller anden form for rapport – et dokument, nogle plot eller måske en interaktiv datavisualisering. Som mange datavidenskabsorganisationer udforsker vi hos Mozilla vores data ved hjælp af fantastiske værktøjer som Jupyter og R-Studio. Men når det er tid til at dele vores resultater, kan vi normalt ikke aflevere en Jupyter-notebook eller et R-script til en beslutningstager, så vi ender ofte med at gøre ting som at kopiere nøgletal og sammenfattende statistikker til et Google Doc.

Vi har fundet ud af, at det ikke altid er let at foretage rundrejsen fra at udforske data i kode til at skabe en letfordøjelig forklaring og tilbage igen. Undersøgelser viser, at mange mennesker deler denne oplevelse. Når en datamatiker læser en andens endelige rapport igennem og ønsker at se koden bag den, kan der opstå en masse gnidninger; nogle gange er det nemt at finde koden, andre gange ikke. Hvis de ønsker at forsøge at eksperimentere med og udvide koden, bliver det naturligvis endnu mere vanskeligt. En anden dataforsker har måske din kode, men har måske ikke en identisk konfiguration på sin maskine, og det tager tid at sætte det op.

Hvorfor er der så lidt web i videnskaben?

Med baggrund i disse datavidenskabelige arbejdsgange hos Mozilla påtog jeg mig i slutningen af 2017 et projekt, som krævede interaktiv datavisualisering. I dag kan du oprette interaktive visualiseringer ved hjælp af fantastiske biblioteker til Python, R og Julia, men til det, jeg ønskede at opnå, var jeg nødt til at falde ned til Javascript. Det betød, at jeg måtte gå væk fra mine foretrukne datalogi-miljøer. Moderne webudviklingsværktøjer er utroligt kraftfulde, men ekstremt komplicerede. Jeg ønskede virkelig ikke at finde ud af, hvordan man får en fuldt udbygget Javascript build toolchain med hot module reloading op at køre, men bortset fra det kunne jeg ikke finde meget, der var rettet mod at skabe rene, læsbare webdokumenter inden for den levende, iterative arbejdsgang, som jeg kender.

Jeg begyndte at spekulere på, hvorfor dette værktøj ikke eksisterede – hvorfor der ikke findes Jupyter til at bygge interaktive webdokumenter – og zoomede snart ud til at tænke på, hvorfor næsten ingen bruger Javascript til videnskabelig databehandling. Tre store grunde sprang i øjnene:

1. Javascript selv har et blandet ry blandt forskere for at være langsomt og besværligt;
2. der findes ikke mange biblioteker til videnskabelig databehandling, der kører i browseren, eller som fungerer med Javascript; og,
3. som jeg havde opdaget, er der meget få videnskabelige kodningsværktøjer, der muliggør hurtige iterationssløjfer og også giver ufiltreret adgang til præsentationsmulighederne i browseren.

Det er meget store udfordringer. Men efterhånden som jeg tænkte mere over det, begyndte jeg at tænke på, at det at arbejde i en browser kan have nogle reelle fordele for den form for kommunikativ datavidenskab, som vi laver hos Mozilla. Den største fordel er naturligvis, at browseren har det vel nok mest avancerede og velunderstøttede sæt af præsentationsteknologier på planeten, fra DOM til WebGL til Canvas til WebVR.

Idet jeg tænkte på den ovenfor nævnte friktion i arbejdsgangen, slog en anden potentiel fordel mig: I browseren behøver det endelige dokument ikke at være adskilt fra det værktøj, der skabte det. Jeg ønskede et værktøj, der var designet til at hjælpe forskere med at iterere på webdokumenter (grundlæggende webapps med et enkelt formål til at forklare en idé) … og mange af de værktøjer, vi brugte, var i sig selv grundlæggende webapps. I det tilfælde, hvor vi skrev disse små web-app-dokumenter, hvorfor ikke bundle dokumentet med det værktøj, der blev brugt til at skrive det?

Derved kunne ikke-tekniske læsere se mit flotte dokument, men andre dataloger kunne straks gå tilbage til den oprindelige kode. Da beregningskernen desuden ville være browserens JS-motor, ville de kunne begynde at udvide og eksperimentere med analysekoden med det samme. Og de ville kunne gøre alt dette uden at skulle oprette forbindelse til eksterne computerressourcer eller installere software.

Til Jodid

Jeg begyndte at diskutere de potentielle fordele og ulemper ved videnskabelig beregning i browseren med mine kolleger, og i løbet af vores samtaler bemærkede vi nogle andre interessante tendenser.

Inden for Mozilla så vi en masse interessante demoer, der viste WebAssembly, en ny måde, hvorpå browsere kan køre kode skrevet i andre sprog end Javascript. WebAssembly gør det muligt at køre programmer med en utrolig hastighed, i nogle tilfælde tæt på native binære filer. Vi så eksempler på beregningskrævende processer som f.eks. hele 3D-spilmotorer, der kunne køre i browseren uden problemer. Fremover vil det være muligt at kompilere de bedste biblioteker til numerisk beregning i C og C++ til WebAssembly og pakke dem ind i ergonomiske JS-API’er, ligesom SciPy-projektet gør det for Python. Faktisk var projekter allerede begyndt at gøre dette.

Vi bemærkede også Javascript-fællesskabets villighed til at indføre ny syntaks, når det hjælper folk til at løse deres problem mere effektivt. Måske ville det være muligt at efterligne nogle af de centrale syntaktiske elementer, der gør numerisk programmering mere forståelig og flydende i MATLAB, Julia og Python – matrixmultiplikation, flerdimensional slicing, broadcast array-operationer osv. Igen fandt vi andre mennesker, der tænkte i samme retning.

Med disse tråde konvergerende begyndte vi at spekulere på, om webplatformen måske var på nippet til at blive et produktivt hjemsted for videnskabelig databehandling. I det mindste så det ud til, at den kunne udvikle sig til at tjene nogle af de kommunikative arbejdsgange, som vi møder hos Mozilla (og som så mange andre møder i industrien og den akademiske verden). Med kernen i Javascript, der hele tiden forbedres, og muligheden for at tilføje syntaksudvidelser til numerisk programmering, kunne JS måske selv gøres mere attraktiv for forskere. WebAssembly syntes at tilbyde en vej til gode videnskabelige biblioteker. Det tredje ben på skamlen ville være et miljø til at skabe datalogiske dokumenter til internettet. Det er på dette sidste element, vi besluttede at fokusere vores første eksperimenter, hvilket bragte os til Iodide.

Anatomi af Iodide

Iodide er et værktøj, der er designet til at give forskere en velkendt arbejdsgang til at skabe flotte interaktive dokumenter ved hjælp af webplatformens fulde kraft. For at opnå dette giver vi dig en “rapport” – grundlæggende en webside, som du kan udfylde med dit indhold – og nogle værktøjer til iterativ udforskning af data og ændring af din rapport for at skabe noget, du er klar til at dele. Når du er klar, kan du sende et link direkte til din færdige rapport. Hvis dine kolleger og samarbejdspartnere ønsker at gennemgå din kode og lære af den, kan de gå tilbage til en udforskningstilstand med et enkelt klik. Hvis de ønsker at eksperimentere med koden og bruge den som grundlag for deres eget arbejde, kan de med endnu et klik gafle den og begynde at arbejde på deres egen version.

Læs videre for at få lidt mere at vide om nogle af de idéer, vi eksperimenterer med i et forsøg på at få denne arbejdsgang til at føles flydende.

Udforsknings- og rapportvisningerne

Iodide har til formål at stramme loopet mellem udforskning, forklaring og samarbejde. Centralt for dette er muligheden for at bevæge sig frem og tilbage mellem en flot udseende opskrivning og et nyttigt miljø til iterativ beregningsmæssig udforskning.

Når du først opretter en ny Jodid-notesbog, starter du i “udforsk-visningen”. Dette giver et sæt ruder, herunder en editor til at skrive kode, en konsol til at se output fra den kode, du evaluerer, en workspace viewer til at undersøge de variabler, du har oprettet i løbet af din session, og et “report preview”-rude, hvor du kan se et preview af din rapport.

Du kan klikke på knappen “REPORT” i øverste højre hjørne, og indholdet af din rapportforhåndsvisning udvides til at fylde hele vinduet, så du kan sætte den historie, du ønsker at fortælle, i centrum. Læsere, der ikke ved, hvordan man koder, eller som ikke er interesserede i de tekniske detaljer, kan fokusere på det, du forsøger at formidle, uden at skulle rode sig igennem koden. Når en læser besøger linket til rapportvisningen, kører din kode automatisk. Hvis de ønsker at gennemgå din kode, skal de blot klikke på “EXPLORE”-knappen i øverste højre hjørne for at komme tilbage til udforskningsvisningen. Derfra kan de lave en kopi af notesbogen til deres egne udforskninger.

Når du deler et link til en Iodide-notesbog, kan din samarbejdspartner altid få adgang til begge disse visninger. Det rene, læsbare dokument er aldrig adskilt fra den underliggende kørbare kode og det levende redigeringsmiljø.

Live, interaktive dokumenter med webplatformens kraft

Jodide-dokumenter lever i browseren, hvilket betyder, at beregningsmotoren altid er tilgængelig. Hver gang du deler dit arbejde, deler du en levende interaktiv rapport med kørende kode. Da beregningen foregår i browseren sideløbende med præsentationen, er der desuden ikke behov for at kalde en sprogbackend i en anden proces. Det betyder, at interaktive dokumenter opdateres i realtid, hvilket åbner mulighed for sømløse 3D-visualiseringer, selv med den lave latenstid og høje billedhastighed, der kræves til VR.

Deling, samarbejde og reproducerbarhed

Bygning af Iodide på nettet forenkler en række af de elementer af friktion i arbejdsgangen, som vi er stødt på i andre værktøjer. Deling er forenklet, fordi opskriften og koden er tilgængelige på den samme URL-adresse i stedet for f.eks. at indsætte et link til et script i fodnoterne i et Google Doc. Samarbejdet er forenklet, fordi compute-kernen er browseren, og biblioteker kan indlæses via en HTTP-forespørgsel som enhver webside indlæser script – der skal ikke installeres yderligere sprog, biblioteker eller værktøjer. Og fordi browsere leverer et kompatibilitetslag, behøver du ikke at bekymre dig om, at notebook-adfærd kan reproduceres på tværs af computere og operativsystemer.

For at understøtte samarbejdsbaserede arbejdsgange har vi bygget en ret simpel server til at gemme og dele notebooks. Der er en offentlig instans på iodide.io, hvor du kan eksperimentere med Iodide og dele dit arbejde offentligt. Det er også muligt at oprette din egen instans bag en firewall (og det er faktisk det, vi allerede gør hos Mozilla til noget internt arbejde). Men det er vigtigt, at selve notesbøgerne ikke er dybt bundet til en enkelt instans af Iodide-serveren. Hvis behovet skulle opstå, skulle det være let at migrere dit arbejde til en anden server eller eksportere din notesbog som et bundle til deling på andre tjenester som Netlify eller Github Pages (mere om eksport af bundles nedenfor under “Hvad er det næste?”). Ved at holde beregningen i klienten kan vi fokusere på at opbygge et virkelig godt miljø til deling og samarbejde, uden at vi behøver at opbygge beregningsressourcer i skyen.

Pyodide: Python-videnskabsstacken i browseren

Når vi begyndte at tænke på at gøre internettet bedre for forskere, fokuserede vi på måder, hvorpå vi kunne gøre det bedre at arbejde med Javascript, f.eks. ved at kompilere eksisterende videnskabelige biblioteker til WebAssembly og pakke dem ind i brugervenlige JS-API’er. Da vi foreslog dette til Mozillas WebAssembly-wizards, tilbød de en mere ambitiøs idé: Hvis mange forskere foretrækker Python, så mød dem, hvor de er, ved at kompilere Pythons videnskabelige stak til at køre i WebAssembly.

Vi syntes, at dette lød skræmmende – at det ville være et enormt projekt, og at det aldrig ville give tilfredsstillende ydeevne … men to uger senere havde Mike Droettboom en fungerende implementering af Python, der kørte i en Iodide-notebook. I løbet af de næste par måneder tilføjede vi Numpy, Pandas og Matplotlib, som er langt de mest anvendte moduler i Pythons videnskabelige økosystem. Med hjælp fra bidragyderne Kirill Smelkov og Roman Yurchak hos Nexedi fik vi understøttelse for Scipy og scikit-learn. Siden da har vi fortsat med at tilføje andre biblioteker lidt efter lidt.

Afvikling af Python-fortolkeren inde i en virtuel Javascript-maskine tilføjer en ydelsesmæssig straf, men denne straf viser sig at være overraskende lille – i vores benchmarks omkring 1x-12x langsommere end native i Firefox og 1x-16x langsommere i Chrome. Erfaringen viser, at dette er meget anvendeligt til interaktiv udforskning.

Den magiske arbejdsgang opstår ved at bringe Python ind i browseren. Du kan f.eks. importere og rense dine data i Python og derefter få adgang til de resulterende Python-objekter fra Javascript (i de fleste tilfælde sker konverteringen automatisk), så du kan vise dem ved hjælp af JS-biblioteker som f.eks. d3. Endnu mere magisk kan du få adgang til browser-API’er fra Python-kode, så du kan gøre ting som at manipulere DOM uden at røre Javascript.

Der er selvfølgelig meget mere at sige om Pyodide, og det fortjener sin egen artikel – vi vil gå mere i detaljer i et opfølgende indlæg i næste måned.

JSMD (JavaScript MarkDown)

Som i Jupyter og R’s R-Markdown-tilstand kan du i Iodide flette kode og opskrivning ind i hinanden, som du ønsker, og dele din kode op i “kodeklumper”, som du kan ændre og køre som separate enheder. Vores implementering af denne idé er parallel til R Markdown og MATLAB’s “cell mode”: I stedet for at bruge en eksplicit cellebaseret grænseflade er indholdet af en Iodide-notebook blot et tekstdokument, der bruger en særlig syntaks til at afgrænse specifikke typer af celler. Vi kalder dette tekstformat for “JSMD”.

I lighed med MATLAB defineres kodeklumper ved linjer, der starter med %% efterfulgt af en streng, der angiver sproget i den nedenstående klump. Vi understøtter i øjeblikket chunks, der indeholder Javascript, CSS, Markdown (og HTML), Python, en særlig “fetch”-chunk, der forenkler indlæsning af ressourcer, og en plugin-chunk, der giver dig mulighed for at udvide Iodides funktionalitet ved at tilføje nye celletyper.

Vi har fundet dette format ganske praktisk. Det gør det nemt at bruge tekstorienterede værktøjer som diff-fremvisere og din egen foretrukne teksteditor, og du kan udføre standardtekstoperationer som klip/kopier/klistre ind uden at skulle lære genveje til cellehåndtering. For flere detaljer kan du læse om JSMD i vores docs.

Hvad er det næste?

Det er værd at gentage, at vi stadig er i alpha, så vi vil fortsætte med at forbedre den generelle polering og udrydde fejl. Men ud over det har vi en række funktioner i tankerne til vores næste eksperimentationsrunde. Hvis nogen af disse ideer springer ud som særligt nyttige, så lad os vide det! Endnu bedre, lad os vide, om du vil hjælpe os med at bygge dem!

Forbedrede samarbejdsfunktioner

Som nævnt ovenfor har vi indtil videre bygget en meget simpel backend, der giver dig mulighed for at gemme dit arbejde online, se på arbejde udført af andre og hurtigt fork og udvide eksisterende notesbøger lavet af andre brugere, men det er kun de første skridt i en nyttig arbejdsgang for samarbejde.

De næste tre store samarbejdsfunktioner, som vi ser på at tilføje, er:

1. Google Docs-agtige kommentartråde
2. Muligheden for at foreslå ændringer til en anden brugers notesbog via en fork/merge-arbejdsgang svarende til Github pull requests
3. Simultan redigering af notesbøger som i Google Docs.

På nuværende tidspunkt prioriterer vi dem i nogenlunde denne rækkefølge, men hvis du vil tage fat på dem i en anden rækkefølge, eller hvis du har andre forslag, så lad os vide det!

Mere sprog!

Vi har talt med folk fra R- og Julia-fællesskaberne om at kompilere disse sprog til WebAssembly, hvilket ville gøre det muligt at bruge dem i Iodide og andre browserbaserede projekter. Vores indledende undersøgelse viser, at det burde kunne lade sig gøre, men at det måske vil være lidt mere udfordrende at implementere disse sprog end Python. Som med Python åbner der sig nogle fede arbejdsgange, hvis man f.eks. kan tilpasse statistiske modeller i R eller løse differentialligninger i Julia og derefter vise sine resultater ved hjælp af browser-API’er. Hvis det interesserer dig at bringe disse sprog til internettet, så tag endelig kontakt – især vil vi gerne have hjælp fra FORTRAN- og LLVM-eksperter.

Export notebook archive

Første versioner af Iodide var selvstændige kørbare HTML-filer, som indeholdt både den JSMD-kode, der blev brugt i analysen, og den JS-kode, der blev brugt til at køre selve Iodide, men vi er gået væk fra denne arkitektur. Senere eksperimenter har overbevist os om, at samarbejdsfordelene ved at have en Iodide-server opvejer fordelene ved at administrere filer på dit lokale system. Ikke desto mindre viste disse eksperimenter os, at det er muligt at tage et kørbart øjebliksbillede af en Iodide-notebook ved at indlejre Iodide-koden sammen med eventuelle data og biblioteker, der anvendes af en notebook, i én stor HTML-fil. Dette kan ende med at blive en større fil, end man ønsker at servere for almindelige brugere, men det kan vise sig nyttigt som et perfekt reproducerbart og arkiverbart øjebliksbillede af en analyse.

Iodide to text editor browser extension

Mens mange forskere er ganske vant til at arbejde i browserbaserede programmeringsmiljøer, ved vi, at nogle mennesker aldrig vil redigere kode i andet end deres foretrukne teksteditor. Vi ønsker virkelig, at Iodide skal møde folk, hvor de allerede er, herunder dem, der foretrækker at skrive deres kode i en anden editor, men som ønsker adgang til de interaktive og iterative funktioner, som Iodide giver. For at opfylde dette behov er vi begyndt at tænke på at skabe en letvægts browserudvidelse og nogle simple API’er, så Iodide kan tale med klient-side editorer.

Feedback og samarbejde er velkomne!

Vi forsøger ikke at løse alle problemerne inden for datalogi og videnskabelig databehandling, og vi ved, at Iodide ikke vil være alles kop te. Hvis du har brug for at behandle terabytes af data på GPU-klynger, har Iodide sandsynligvis ikke meget at tilbyde dig. Hvis du udgiver tidsskriftartikler, og du bare skal skrive et LaTeX-dokument, er der bedre værktøjer til dine behov. Hvis hele tendensen med at bringe ting ind i browseren får dig til at krybe lidt sammen, er det ikke noget problem – der findes et væld af virkelig fantastiske værktøjer, som du kan bruge til at lave videnskab, og det er vi taknemmelige for! Vi ønsker ikke at ændre den måde, som nogen arbejder på, og for mange videnskabsfolk er webfokuseret kommunikation ikke noget, der har noget at gøre med det. Rad! Lev dit bedste liv!

Men for de videnskabsfolk, der producerer indhold til nettet, og for dem, der måske gerne ville gøre det, hvis de havde værktøjer, der var designet til at understøtte den måde, de arbejder på: Vi vil virkelig gerne høre fra dig!

Besøg iodide.io, prøv det og giv os feedback (men igen: husk på, at dette projekt er i alpha-fasen – brug det ikke til kritisk arbejde, og vær opmærksom på, at mens vi er i alpha-fasen, kan alting ændre sig). Du kan tage vores hurtige undersøgelse, og Github-problemer og fejlrapporter er meget velkomne. Feature requests og tanker om den overordnede retning kan deles via vores Google-gruppe eller Gitter.

Hvis du gerne vil være med til at hjælpe os med at bygge Iodide, så er vi open source på Github. Iodide berører en bred vifte af softwarediscipliner, fra moderne frontend-udvikling til videnskabelig beregning til kompilering og transpilation, så der er mange interessante ting at lave! Tag endelig fat i os, hvis noget af dette interesserer dig!

En stor tak til Hamilton Ulmer, William Lachance og Mike Droettboom for deres store arbejde med Iodide og for at have gennemgået denne artikel.

Om Brendan Colloran

Mere artikler af Brendan Colloran…