Hacks

Under de senaste tio åren har intresset för ”vetenskaplig databehandling” och ”datavetenskap” ökat explosionsartat: det vill säga tillämpning av databehandling för att besvara frågor och analysera data inom natur- och samhällsvetenskaperna. För att tillgodose dessa behov har vi sett en renässans för programmeringsspråk, verktyg och tekniker som hjälper vetenskapsmän och forskare att utforska och förstå data och vetenskapliga begrepp och att kommunicera sina resultat. Men hittills har mycket få verktyg fokuserat på att hjälpa forskare att få ofiltrerad tillgång till den fulla kommunikationspotentialen hos moderna webbläsare. Så idag är vi glada att kunna presentera Iodide, ett experimentellt verktyg som är tänkt att hjälpa forskare att skriva vackra interaktiva dokument med hjälp av webbteknik, allt inom ett iterativt arbetsflöde som känns likt andra vetenskapliga datormiljöer.

Ovanför att bara vara en programmeringsmiljö för att skapa levande dokument i webbläsaren, försöker Iodide ta bort friktionen från kommunikativa arbetsflöden genom att alltid paketera redigeringsverktyget med det rena läsbara dokumentet. Detta skiljer sig från IDE-liknande miljöer som ger ut presentationsdokument som pdf-filer (som sedan skiljs från den ursprungliga koden) och cellbaserade anteckningsböcker som blandar kod och presentationselement. I Iodide får du både ett dokument som ser ut som du vill att det ska se ut och enkel tillgång till den underliggande koden och redigeringsmiljön.

Iodide är fortfarande i hög grad i alfa-stadiet, men i enlighet med Internet-aftorismen ”Om du inte skäms över den första versionen av din produkt har du lanserat den för sent”, har vi beslutat att göra en mycket tidig mjuklansering i förhoppning om att få feedback från en större gemenskap. Vi har en demo som du kan prova just nu, men förvänta dig en hel del ojämnheter (och använd inte den här alfaversionen för kritiskt arbete!). Vi hoppas att du, trots de grova kanterna, om du kisar på detta kommer att kunna se värdet av konceptet, och att den feedback du ger oss kommer att hjälpa oss att ta reda på vad vi ska göra härnäst.

Hur vi kom till Iodide

Datavetenskap på Mozilla

På Mozilla är den stora majoriteten av vårt datavetenskapliga arbete fokuserat på kommunikation. Även om vi ibland använder modeller som är avsedda att direkt förbättra en användares upplevelse, till exempel rekommendationsmotorn som hjälper användare att upptäcka webbläsartillägg, analyserar våra datavetare oftast våra data för att hitta och dela med sig av insikter som kan informera produktchefer, ingenjörer och chefer om deras beslut.

Datavetenskapligt arbete innebär att man skriver mycket kod, men till skillnad från traditionell programvaruutveckling är vårt mål att besvara frågor, inte att producera programvara. Detta resulterar vanligtvis i någon form av rapport – ett dokument, några diagram eller kanske en interaktiv datavisualisering. Liksom många datavetenskapliga organisationer utforskar vi på Mozilla våra data med hjälp av fantastiska verktyg som Jupyter och R-Studio. Men när det är dags att dela med oss av våra resultat kan vi vanligtvis inte lämna över en Jupyter-notebook eller ett R-skript till en beslutsfattare, så det slutar ofta med att vi gör saker som att kopiera nyckeltal och sammanfattande statistik till ett Google Doc.

Vi har upptäckt att det inte alltid är lätt att göra rundresan från att utforska data i kod till att skapa en lättsmält förklaring och tillbaka igen. Forskning visar att många människor delar denna erfarenhet. När en datavetare läser igenom en annan datavetares slutrapport och vill titta på koden bakom den kan det uppstå en hel del friktion; ibland är det lätt att spåra koden, ibland inte. Om de vill försöka experimentera med och utöka koden blir det naturligtvis ännu svårare. En annan datavetare kanske har din kod, men kanske inte har en identisk konfiguration på sin maskin, och att ställa in det tar tid.

Varför finns det så lite webb inom vetenskapen?

Mot bakgrund av dessa datavetenskapliga arbetsflöden på Mozilla, åtog jag mig i slutet av 2017 ett projekt som krävde interaktiv datavisualisering. Idag kan du skapa interaktiva visualiseringar med hjälp av fantastiska bibliotek för Python, R och Julia, men för det jag ville åstadkomma behövde jag gå ner till Javascript. Detta innebar att jag fick lämna mina favoritmiljöer för datavetenskap. Moderna webbutvecklingsverktyg är otroligt kraftfulla, men extremt komplicerade. Jag ville verkligen inte ta reda på hur man får igång en fullfjädrad Javascript build toolchain med hot module reloading, men kort sagt kunde jag inte hitta mycket som syftade till att skapa rena, läsbara webbdokument inom det levande, iterativa arbetsflöde som är bekant för mig.

Jag började undra varför det här verktyget inte existerade – varför det inte finns någon Jupyter för att bygga interaktiva webbdokument – och zoomade snart ut till att fundera på varför nästan ingen använder Javascript för vetenskaplig databehandling. Tre stora orsaker hoppade fram:

1. Javascript i sig har ett blandat rykte bland vetenskapsmän för att vara långsamt och besvärligt;
2. det finns inte många bibliotek för vetenskaplig beräkning som kan köras i webbläsaren eller som fungerar med Javascript; och,
3. som jag hade upptäckt finns det väldigt få vetenskapliga kodningsverktyg som möjliggör snabba iterationsslingor och som också ger ofiltrerad tillgång till presentationsmöjligheterna i webbläsaren.

Detta är mycket stora utmaningar. Men när jag tänkte mer på saken började jag tro att det kan ha några verkliga fördelar att arbeta i en webbläsare för den typ av kommunikativ datavetenskap som vi bedriver på Mozilla. Den största fördelen är förstås att webbläsaren har den kanske mest avancerade och välunderstödda uppsättningen presentationstekniker på planeten, från DOM till WebGL till Canvas och WebVR.

Tanken på den friktion i arbetsflödet som nämndes ovan slog mig en annan potentiell fördel: i webbläsaren behöver det slutliga dokumentet inte vara skilt från verktyget som skapade det. Jag ville ha ett verktyg som var utformat för att hjälpa forskare att iterera på webbdokument (i princip webbprogram med ett enda syfte för att förklara en idé) … och många av de verktyg vi använde var i sig själva i princip webbprogram. För användningsfallet att skriva dessa små webbapp-dokument, varför inte paketera dokumentet med verktyget som användes för att skriva det?

Därigenom kunde icke-tekniska läsare se mitt snygga dokument, men andra datavetare kunde omedelbart gå tillbaka till den ursprungliga koden. Eftersom beräkningskärnan skulle vara webbläsarens JS-motor skulle de dessutom omedelbart kunna börja utöka och experimentera med analyskoden. Och de skulle kunna göra allt detta utan att koppla upp sig mot fjärrberäkningsresurser eller installera någon mjukvara.

Till jodid

Jag började diskutera de potentiella för- och nackdelarna med vetenskaplig beräkning i webbläsaren med mina kollegor, och under våra konversationer märkte vi en del andra intressanta tendenser.

Integrerat i Mozilla såg vi en hel del intressanta demonstrationer som visade upp WebAssembly, ett nytt sätt för webbläsare att köra kod som är skriven i andra språk än Javascript. WebAssembly gör det möjligt att köra program med otrolig hastighet, i vissa fall nära inbyggda binärer. Vi såg exempel på beräkningskrävande processer som hela 3D-spelmotorer som kördes i webbläsaren utan problem. I framtiden skulle det vara möjligt att kompilera de bästa biblioteken för numerisk beräkning i C och C++ till WebAssembly och paketera dem i ergonomiska JS API:er, precis som SciPy-projektet gör för Python. Faktum är att projekt redan hade börjat göra detta.

Vi noterade också Javascript-gemenskapens vilja att införa ny syntax när det hjälper människor att lösa sina problem mer effektivt. Kanske skulle det vara möjligt att efterlikna några av de viktiga syntaktiska element som gör numerisk programmering mer begriplig och smidig i MATLAB, Julia och Python – matrismultiplikation, multidimensionell skivning, broadcast array-operationer och så vidare. Återigen fann vi andra personer som tänkte i liknande banor.

Med dessa trådar som konvergerade började vi undra om webbplattformen kunde vara på väg att bli ett produktivt hem för vetenskaplig databehandling. Åtminstone såg det ut som om den skulle kunna utvecklas för att tjäna några av de kommunikativa arbetsflöden som vi möter på Mozilla (och som så många andra möter inom industrin och den akademiska världen). Eftersom kärnan i Javascript förbättras hela tiden och det finns möjlighet att lägga till syntaxförlängningar för numerisk programmering, kanske JS i sig skulle kunna göras mer tilltalande för forskare. WebAssembly verkade erbjuda en väg till bra vetenskapliga bibliotek. Det tredje benet på pallen skulle vara en miljö för att skapa datavetenskapliga dokument för webben. Det är på detta sista element som vi bestämde oss för att fokusera våra första experiment, vilket förde oss till Iodide.

The anatomy of Iodide

Iodide är ett verktyg som är utformat för att ge vetenskapsmän ett välbekant arbetsflöde för att skapa snygga interaktiva dokument med hjälp av webbplattformens fulla kraft. För att åstadkomma detta ger vi dig en ”rapport” – i princip en webbsida som du kan fylla i med ditt innehåll – och några verktyg för att iterativt utforska data och ändra din rapport för att skapa något du är redo att dela. När du är klar kan du skicka en länk direkt till din färdiga rapport. Om dina kollegor och medarbetare vill granska din kod och lära sig av den kan de gå tillbaka till ett utforskningsläge med ett klick. Om de vill experimentera med koden och använda den som grund för sitt eget arbete kan de med ytterligare ett klick gaffla den och börja arbeta på sin egen version.

Läs vidare för att lära dig lite mer om några av de idéer som vi experimenterar med i ett försök att få det här arbetsflödet att kännas smidigt.

Vyerna Utforska och Rapportera

Iodide har som mål att strama åt slingan mellan utforskning, förklaring och samarbete. Centralt för detta är möjligheten att flytta fram och tillbaka mellan en snygg skrivning och en användbar miljö för iterativ beräkningsutforskning.

När du först skapar en ny anteckningsbok i Jodid börjar du i ”utforskningsvyn”. Denna ger en uppsättning rutor, inklusive en editor för att skriva kod, en konsol för att visa utdata från kod som du utvärderar, en arbetsrumsvisare för att undersöka de variabler som du har skapat under din session och en ”report preview”-ruta där du kan se en förhandsgranskning av din rapport.

Om du klickar på knappen ”RAPPORT” i det övre högra hörnet expanderar innehållet i din rapportförhandsgranskning så att det fyller hela fönstret, vilket gör att du kan placera den berättelse du vill berätta framme i centrum. Läsare som inte vet hur man kodar eller som inte är intresserade av de tekniska detaljerna kan fokusera på vad du försöker förmedla utan att behöva vada genom koden. När en läsare besöker länken till rapportvyn körs din kod automatiskt. Om läsaren vill granska koden klickar han eller hon helt enkelt på ”EXPLORE”-knappen uppe till höger för att komma tillbaka till utforskningsvyn. Därifrån kan de göra en kopia av anteckningsboken för sina egna utforskningar.

När du delar en länk till en anteckningsbok i jodid har din samarbetspartner alltid tillgång till båda dessa vyer. Det rena, läsbara dokumentet separeras aldrig från den underliggande körbara koden och den levande redigeringsmiljön.

Livande, interaktiva dokument med webbplattformens kraft

Jodide-dokument lever i webbläsaren, vilket innebär att beräkningsmotorn alltid är tillgänglig. När du delar ditt arbete delar du en levande interaktiv rapport med löpande kod. Eftersom beräkningen sker i webbläsaren parallellt med presentationen finns det dessutom inget behov av att anropa en språkbackend i en annan process. Detta innebär att interaktiva dokument uppdateras i realtid, vilket öppnar möjligheten till sömlösa 3D-visualiseringar, även med den låga latenstid och höga bildhastighet som krävs för VR.

Delning, samarbete och reproducerbarhet

Att bygga Iodide på webben förenklar ett antal element av friktion i arbetsflödet som vi har stött på i andra verktyg. Delning förenklas eftersom skrivelsen och koden är tillgängliga på samma URL i stället för att, till exempel, klistra in en länk till ett skript i fotnoterna i ett Google Doc. Samarbetet förenklas eftersom beräkningskärnan är webbläsaren och biblioteken kan laddas via en HTTP-förfrågan som vilken webbsida som helst laddar skript – inga ytterligare språk, bibliotek eller verktyg behöver installeras. Och eftersom webbläsare tillhandahåller ett kompatibilitetslager behöver du inte oroa dig för att notebookbeteendet ska vara reproducerbart mellan olika datorer och operativsystem.

För att stödja samarbetsflöden har vi byggt en ganska enkel server för att spara och dela notebooks. Det finns en offentlig instans på iodide.io där du kan experimentera med Iodide och dela ditt arbete offentligt. Det är också möjligt att sätta upp en egen instans bakom en brandvägg (och det är faktiskt vad vi redan gör på Mozilla för en del internt arbete). Men viktigast är att själva anteckningsböckerna inte är djupt bundna till en enda instans av Iodide-servern. Om behovet skulle uppstå bör det vara enkelt att migrera ditt arbete till en annan server eller exportera din anteckningsbok som ett paket för delning på andra tjänster som Netlify eller Github Pages (mer om export av paket nedan under ”Vad händer härnäst?”). Genom att hålla beräkningen i klienten kan vi fokusera på att bygga en riktigt bra miljö för delning och samarbete, utan att behöva bygga upp beräkningsresurser i molnet.

Pyodide: När vi började fundera på att göra webben bättre för forskare fokuserade vi på hur vi kunde göra det lättare att arbeta med Javascript, till exempel genom att kompilera befintliga vetenskapliga bibliotek till WebAssembly och paketera dem i lättanvända JS API:er. När vi föreslog detta för Mozillas WebAssembly-assistenter erbjöd de en mer ambitiös idé: om många forskare föredrar Python kan vi möta dem där de befinner sig genom att kompilera Pythons vetenskapliga stack så att den kan köras i WebAssembly.

Vi tyckte att detta lät skrämmande – att det skulle bli ett enormt projekt och att det aldrig skulle ge tillfredsställande prestanda … men två veckor senare hade Mike Droettboom en fungerande implementering av Python som kördes i en Iodide notebook. Under de följande månaderna lade vi till Numpy, Pandas och Matplotlib, som är de absolut mest använda modulerna i Pythons vetenskapliga ekosystem. Med hjälp av bidragsgivarna Kirill Smelkov och Roman Yurchak på Nexedi fick vi stöd för Scipy och scikit-learn. Sedan dess har vi fortsatt att lägga till andra bibliotek bit för bit.

Att köra Python-tolken i en virtuell Javascript-maskin innebär en prestandaförlust, men den förlusten visar sig vara förvånansvärt liten – i våra riktmärken är den ungefär 1x-12x långsammare än den ursprungliga tolken i Firefox och 1x-16x långsammare i Chrome. Erfarenheten visar att detta är mycket användbart för interaktiv utforskning.

Att föra in Python i webbläsaren skapar några magiska arbetsflöden. Du kan till exempel importera och rensa dina data i Python och sedan få tillgång till de resulterande Pythonobjekten från Javascript (i de flesta fall sker konverteringen automatiskt) så att du kan visa dem med hjälp av JS-bibliotek som d3. Ännu mer magiskt kan du få tillgång till webbläsarens API:er från Pythonkod, vilket gör att du kan göra saker som att manipulera DOM utan att röra Javascript.

Självklart finns det mycket mer att säga om Pyodide, och det förtjänar en egen artikel – vi kommer att gå in mer i detalj i ett uppföljande inlägg nästa månad.

JSMD (JavaScript MarkDown)

Just som i Jupyter och R:s R-Markdown-läge kan du i Iodide varva kod och skrivning som du vill, och dela upp din kod i ”kodbitar” som du kan modifiera och köra som separata enheter. Vårt genomförande av den här idén är parallellt med R Markdown och MATLAB:s ”celläge”: i stället för att använda ett explicit cellbaserat gränssnitt är innehållet i en Iodide-notebook bara ett textdokument som använder en särskild syntax för att avgränsa specifika typer av celler. Vi kallar detta textformat för ”JSMD”.

I likhet med MATLAB definieras kodbitar av rader som börjar med %% och följs av en sträng som anger språket för den underliggande biten. Vi har för närvarande stöd för chunks som innehåller Javascript, CSS, Markdown (och HTML), Python, en speciell ”fetch”- chunk som förenklar lastning av resurser och en plugin chunk som gör det möjligt att utöka Iodides funktionalitet genom att lägga till nya celltyper.

Vi har funnit att det här formatet är ganska bekvämt. Det gör det enkelt att använda textorienterade verktyg som diff-tittare och din egen favorittextredigerare, och du kan utföra vanliga textoperationer som klippa/kopiera/klistra in utan att behöva lära dig genvägar för cellhantering. För mer information kan du läsa om JSMD i vår dokumentation.

Vad händer härnäst?

Det är värt att upprepa att vi fortfarande befinner oss i alfa, så vi kommer att fortsätta att förbättra den övergripande poleringen och krossa buggar. Men utöver det har vi ett antal funktioner i åtanke för vår nästa experimentrunda. Om någon av dessa idéer framstår som särskilt användbar, låt oss veta! Ännu bättre, låt oss veta om du vill hjälpa oss att bygga dem!

Förbättrade samarbetsfunktioner

Som nämnts ovan har vi hittills byggt en mycket enkel backend som gör det möjligt för dig att spara ditt arbete online, titta på arbete som gjorts av andra och snabbt gaffla och utöka befintliga anteckningsböcker som skapats av andra användare, men detta är bara de första stegen i ett användbart arbetsflöde för samarbete.

De nästa tre stora samarbetsfunktionerna som vi funderar på att lägga till är:

1. Kommentartrådar i stil med Google Docs
2. Möjligheten att föreslå ändringar i en annan användares anteckningsbok via ett arbetsflöde för gaffelning och sammanslagning som liknar Github-utdragsbegäran
3. Simultan redigering av anteckningsböcker som i Google Docs.

I nuläget prioriterar vi dem i ungefär den ordningen, men om du skulle vilja ta itu med dem i en annan ordning eller om du har andra förslag, låt oss veta!

Mer språk!

Vi har talat med folk från R- och Julia-communityerna om att kompilera dessa språk till WebAssembly, vilket skulle möjliggöra användningen av dem i Iodide och andra webbläsarbaserade projekt. Vår första undersökning visar att detta borde vara möjligt, men att det kan vara lite svårare att implementera dessa språk än Python. Precis som med Python öppnas en del häftiga arbetsflöden om man till exempel kan anpassa statistiska modeller i R eller lösa differentialekvationer i Julia och sedan visa resultaten med hjälp av API:er i webbläsaren. Om det intresserar dig att ta dessa språk till webben är du välkommen att höra av dig – särskilt skulle vi vilja ha hjälp av FORTRAN- och LLVM-experter.

Export notebook archive

Främre versioner av Iodide var fristående körbara HTML-filer, som innehöll både JSMD-koden som användes i analysen och JS-koden som användes för att köra Iodide i sig självt, men vi har gått bort från den här arkitekturen. Senare experiment har övertygat oss om att samarbetsfördelarna med att ha en Iodide-server överväger fördelarna med att hantera filer på ditt lokala system. Dessa experiment visade oss ändå att det är möjligt att ta en körbar ögonblicksbild av en Iodide-notebook genom att lägga in Iodide-koden tillsammans med alla data och bibliotek som används av en notebook i en stor HTML-fil. Detta kan sluta med att bli en större fil än vad du vill servera till vanliga användare, men den kan visa sig användbar som en perfekt reproducerbar och arkiverbar ögonblicksbild av en analys.

Iodide to text editor browser extension

Men även om många vetenskapsmän är ganska vana vid att arbeta i webbläsarbaserade programmeringsmiljöer, så vet vi att en del människor aldrig kommer att redigera kod i något annat än i sin favorittexteditor. Vi vill verkligen att Iodide ska möta människor där de redan befinner sig, inklusive de som föredrar att skriva sin kod i en annan editor men som vill ha tillgång till de interaktiva och iterativa funktioner som Iodide erbjuder. För att tillgodose det behovet har vi börjat fundera på att skapa ett lättviktigt webbläsartillägg och några enkla API:er för att låta Iodide prata med klientredigerare.

Feedback och samarbete är välkommet!

Vi försöker inte lösa alla problem inom datavetenskap och vetenskaplig databehandling, och vi vet att Iodide inte kommer att vara allas kopp te. Om du behöver bearbeta terabyte av data på GPU-kluster har Iodide förmodligen inte mycket att erbjuda dig. Om du publicerar tidskriftsartiklar och bara behöver skriva ett LaTeX-dokument finns det bättre verktyg för dina behov. Om hela trenden med att föra in saker i webbläsaren får dig att krypa lite, inga problem – det finns en mängd riktigt fantastiska verktyg som du kan använda för att bedriva vetenskap, och det är vi tacksamma för! Vi vill inte förändra någons sätt att arbeta, och för många vetenskapsmän är webbaserad kommunikation inte aktuellt. Rad! Lev ditt bästa liv!

Men för de forskare som producerar innehåll för webben, och för dem som kanske skulle vilja göra det om de hade verktyg som är utformade för att stödja det sätt på vilket de arbetar: vi skulle verkligen vilja höra från dig!

Besök iodide.io, prova det och ge oss feedback (men återigen: tänk på att det här projektet befinner sig i alfafasen – använd det inte för kritiskt arbete, och var medveten om att allting kan komma att förändras medan vi befinner oss i alfafasen). Du kan svara på vår snabbundersökning, och Github-frågor och felrapporter är mycket välkomna. Funktionsförfrågningar och tankar om den övergripande inriktningen kan delas via vår Google-grupp eller Gitter.

Om du vill vara med och hjälpa oss att bygga Iodide är vi öppen källkod på Github. Iodide berör en mängd olika mjukvarudiagnoser, från modern frontend-utveckling till vetenskaplig beräkning till kompilering och transpilering, så det finns många intressanta saker att göra! Hör gärna av dig om något av detta intresserar dig!

Ett stort tack till Hamilton Ulmer, William Lachance och Mike Droettboom för deras fantastiska arbete med Iodide och för att de har granskat den här artikeln.

Om Brendan Colloran

Mer artiklar av Brendan Colloran…