Hacks

In de laatste 10 jaar is er een explosieve belangstelling geweest voor “scientific computing” en “data science”: dat wil zeggen, de toepassing van computation om vragen te beantwoorden en gegevens te analyseren in de natuur- en sociale wetenschappen. Om aan deze behoeften te voldoen, hebben we een renaissance gezien in programmeertalen, tools en technieken die wetenschappers en onderzoekers helpen om gegevens en wetenschappelijke concepten te verkennen en te begrijpen, en om hun bevindingen te communiceren. Maar tot nu toe zijn er maar weinig tools die wetenschappers helpen om ongefilterde toegang te krijgen tot het volledige communicatiepotentieel van moderne webbrowsers. Daarom introduceren we vandaag Iodide, een experimenteel hulpprogramma waarmee wetenschappers prachtige interactieve documenten kunnen schrijven met webtechnologieën, binnen een iteratieve workflow die aanvoelt als andere omgevingen voor wetenschappelijk computergebruik.

Iodide in actie.

Iodide is niet alleen een programmeeromgeving voor het maken van levende documenten in de browser, maar probeert ook de wrijving uit communicatieve workflows te halen door het bewerkingsprogramma altijd te bundelen met het schone leesbare document. Dit wijkt af van IDE-achtige omgevingen die presentatiedocumenten als .pdf-bestanden produceren (die dan gescheiden zijn van de originele code) en cel-gebaseerde notebooks die code en presentatie-elementen mixen. In Iodide krijg je zowel een document dat eruit ziet zoals jij dat wilt, als gemakkelijke toegang tot de onderliggende code en bewerkingsomgeving.

Iodide is nog steeds in een alpha-staat, maar volgens het internet aforisme “Als je niet in verlegenheid wordt gebracht door de eerste versie van je product, ben je te laat gelanceerd”, hebben we besloten om een zeer vroege soft launch te doen in de hoop feedback te krijgen van een grotere gemeenschap. We hebben een demo die je nu kunt uitproberen, maar verwacht veel ruwe kantjes (en gebruik deze alpha release alsjeblieft niet voor kritisch werk!). We hopen dat u, ondanks de ruwe kantjes, de waarde van het concept zult inzien en dat de feedback die u ons geeft ons zal helpen uit te zoeken hoe we verder moeten.

Hoe we bij Iodide kwamen

Data science bij Mozilla

Bij Mozilla is het overgrote deel van ons data science-werk gericht op communicatie. Hoewel we soms modellen inzetten die bedoeld zijn om de ervaring van een gebruiker direct te verbeteren, zoals de aanbevelingsengine die gebruikers helpt browserextensies te ontdekken, analyseren onze datawetenschappers onze gegevens meestal om inzichten te vinden en te delen die de beslissingen van productmanagers, engineers en leidinggevenden kunnen onderbouwen.

Data science-werk brengt met zich mee dat er veel code wordt geschreven, maar in tegenstelling tot traditionele softwareontwikkeling is het ons doel om vragen te beantwoorden, niet om software te produceren. Dit resulteert meestal in een soort rapport – een document, enkele plots, of misschien een interactieve datavisualisatie. Zoals veel data science-organisaties, verkennen we bij Mozilla onze gegevens met fantastische tools zoals Jupyter en R-Studio. Wanneer het echter tijd is om onze resultaten te delen, kunnen we meestal geen Jupyter-notitieblok of een R-script aan een besluitvormer overhandigen, dus uiteindelijk doen we vaak dingen zoals het kopiëren van kerncijfers en samenvattende statistieken naar een Google Doc.

We hebben gemerkt dat het maken van de rondreis van het verkennen van gegevens in code naar het maken van een verteerbare uitleg en weer terug niet altijd gemakkelijk is. Onderzoek toont aan dat veel mensen deze ervaring delen. Wanneer een datawetenschapper het eindrapport van een ander doorleest en de achterliggende code wil bekijken, kan er veel wrijving ontstaan; soms is het eenvoudig om de code te achterhalen, soms niet. Als ze willen experimenteren met de code en deze willen uitbreiden, wordt het natuurlijk nog moeilijker. Een andere datawetenschapper kan uw code hebben, maar heeft mogelijk geen identieke configuratie op hun machine, en het opzetten daarvan kost tijd.

De virtueuze cirkel van data science-werk.

Waarom is er zo weinig web in de wetenschap?

Tegen de achtergrond van deze data science-workflows bij Mozilla, ondernam ik eind 2017 een project dat opriep tot interactieve datavisualisatie. Tegenwoordig kun je interactieve visualisaties maken met behulp van geweldige bibliotheken voor Python, R en Julia, maar voor wat ik wilde bereiken, moest ik afzakken naar Javascript. Dit betekende een stap weg van mijn favoriete data science omgevingen. Moderne web development tools zijn ongelooflijk krachtig, maar extreem ingewikkeld. Ik wilde echt niet uitvinden hoe ik een volwaardige Javascript build toolchain met hot module reloading aan de praat kon krijgen, maar kort daarvoor kon ik niet veel vinden dat gericht was op het maken van schone, leesbare webdocumenten binnen de live, iteratieve workflow die ik ken.

Ik begon me af te vragen waarom deze tool niet bestond – waarom er geen Jupyter is voor het bouwen van interactieve webdocumenten – en zoomde al snel uit naar het denken over waarom bijna niemand Javascript gebruikt voor wetenschappelijk rekenwerk. Drie grote redenen sprongen eruit:

  1. Javascript zelf heeft een gemengde reputatie onder wetenschappers omdat het traag en onhandig is;
  2. er zijn niet veel wetenschappelijke berekeningsbibliotheken die in de browser draaien of die met Javascript werken; en,
  3. zoals ik had ontdekt, zijn er maar weinig wetenschappelijke codeertools die een snelle iteratielus mogelijk maken en ook ongefilterde toegang bieden tot de presentatiemogelijkheden in de browser.

Dit zijn zeer grote uitdagingen. Maar toen ik er meer over nadacht, begon ik te denken dat het werken in een browser wel eens echte voordelen zou kunnen hebben voor het soort communicatieve datawetenschap dat we bij Mozilla doen. Het grootste voordeel is natuurlijk dat de browser aantoonbaar de meest geavanceerde en goed ondersteunde set presentatietechnologieën op de planeet heeft, van het DOM tot WebGL tot Canvas tot WebVR.

Doordachtend over de hierboven genoemde workflowfrictie, kwam een ander potentieel voordeel bij me op: in de browser hoeft het uiteindelijke document niet gescheiden te zijn van het gereedschap dat het heeft gemaakt. Ik wilde een tool om wetenschappers te helpen itereren op webdocumenten (in principe webapps voor één doel om een idee uit te leggen)… en veel tools die we gebruikten waren zelf in feite webapps. Waarom zou je voor het gebruiksdoel van het schrijven van deze kleine web-app-documenten het document niet bundelen met het gereedschap dat wordt gebruikt om het te schrijven?

Door dit te doen, kunnen niet-technische lezers mijn mooi ogende document zien, maar andere datawetenschappers kunnen direct terug naar de oorspronkelijke code. En omdat de rekenkern de JS-engine van de browser is, kunnen ze de analysecode meteen uitbreiden en ermee experimenteren. En ze zouden dit alles kunnen doen zonder verbinding te maken met externe computerbronnen of software te installeren.

Towards Iodide

Ik begon met mijn collega’s te discussiëren over de mogelijke voors en tegens van wetenschappelijk rekenen in de browser, en in de loop van onze gesprekken merkten we enkele andere interessante trends op.

Binnen Mozilla zagen we veel interessante demo’s waarin WebAssembly werd getoond, een nieuwe manier voor browsers om code te draaien die is geschreven in andere talen dan Javascript. WebAssembly maakt het mogelijk om programma’s te draaien met een ongelooflijke snelheid, in sommige gevallen dicht bij native binaries. We zagen voorbeelden van computationeel-intensieve processen zoals volledige 3D game engines die zonder problemen binnen de browser draaiden. In de toekomst zou het mogelijk zijn om de beste bibliotheken voor numerieke berekeningen in C en C++ te compileren naar WebAssembly en ze te verpakken in ergonomische JS API’s, net zoals het SciPy project doet voor Python. Inderdaad, projecten waren hier al mee begonnen.

WebAssembly maakt het mogelijk om code op bijna-native snelheid in de browser te draaien.

We hebben ook gemerkt dat de Javascript-gemeenschap bereid is om nieuwe syntaxis te introduceren wanneer dit mensen helpt om hun probleem effectiever op te lossen. Misschien zou het mogelijk zijn om enkele van de belangrijkste syntactische elementen te emuleren die numeriek programmeren begrijpelijker en vloeiender maken in MATLAB, Julia, en Python – matrix vermenigvuldiging, multidimensionale slicing, broadcast array operaties, enzovoort. Opnieuw vonden we andere mensen die in dezelfde richting dachten.

Doordat deze lijnen samenkwamen, begonnen we ons af te vragen of het webplatform misschien op het punt stond een productieve thuisbasis te worden voor wetenschappelijke berekeningen. Op zijn minst leek het erop dat het zou kunnen evolueren om enkele van de communicatieve workflows te dienen die we bij Mozilla tegenkomen (en die zo vele anderen tegenkomen in de industrie en de academische wereld). Met het steeds verbeteren van de kern van Javascript en de mogelijkheid om syntaxis-uitbreidingen voor numeriek programmeren toe te voegen, zou JS zelf misschien aantrekkelijker gemaakt kunnen worden voor wetenschappers. WebAssembly leek een pad te bieden naar grote wetenschappelijke bibliotheken. De derde poot van de kruk zou een omgeving zijn voor het creëren van data science documenten voor het web. Dit laatste element is waar we besloten onze eerste experimenten op te richten, wat ons bij Iodide bracht.

De anatomie van Iodide

Iodide is een tool ontworpen om wetenschappers een vertrouwde workflow te geven voor het maken van geweldig uitziende interactieve documenten met gebruikmaking van de volledige kracht van het webplatform. Om dat te bereiken, geven we je een “rapport” – in feite een webpagina die je kunt invullen met je eigen inhoud – en een aantal tools voor het iteratief verkennen van gegevens en het aanpassen van je rapport om iets te maken dat je klaar bent om te delen. Zodra u klaar bent, kunt u een link sturen naar uw definitieve rapport. Als uw collega’s en medewerkers uw code willen bekijken en ervan willen leren, kunnen ze met één klik teruggaan naar de verkenningsmodus. Als ze met de code willen experimenteren en deze als basis voor hun eigen werk willen gebruiken, kunnen ze met nog een klik de code forken en aan hun eigen versie werken.

Lees verder om meer te weten te komen over enkele ideeën waarmee we experimenteren in een poging om deze workflow vloeiend te laten aanvoelen.

De verken- en rapportweergave

Iodide wil de lus tussen verkenning, uitleg en samenwerking nauwer aanhalen. Centraal daarbij staat de mogelijkheid om heen en weer te gaan tussen een mooi ogend verslag en een bruikbare omgeving voor iteratief rekenonderzoek.

Als je voor het eerst een nieuw Iodide-notitieboek maakt, begin je in de “verken”-weergave. Dit biedt een aantal vensters, waaronder een editor voor het schrijven van code, een console voor het bekijken van de uitvoer van code die u evalueert, een werkruimte viewer voor het onderzoeken van de variabelen die u hebt gemaakt tijdens uw sessie, en een “rapport preview” deelvenster waarin u een voorbeeld van uw rapport kunt zien.

Een Markdown-codeblok bewerken in de verkenningsweergave van Iodide.

Door op de knop “REPORT” in de rechterbovenhoek te klikken, zal de inhoud van uw rapport-preview het hele venster vullen, zodat u het verhaal dat u wilt vertellen, vooraan en centraal kunt zetten. Lezers die niet weten hoe te coderen of die niet geïnteresseerd zijn in de technische details, kunnen zich concentreren op wat je probeert over te brengen zonder door de code te hoeven waden. Wanneer een lezer de link naar de rapportweergave bezoekt, wordt uw code automatisch uitgevoerd. Als ze uw code willen bekijken, brengt een eenvoudige klik op de knop “Verkennen” rechtsboven hen terug naar de verkenningsweergave. Van daaruit kunnen ze een kopie van het notitieblok maken voor hun eigen verkenningen.

Verplaatsen van de verkennings- naar de rapportweergave.

Wanneer u een koppeling naar een Iodide-notitieblok deelt, heeft uw medewerker altijd toegang tot deze beide weergaven. Het schone, leesbare document is nooit gescheiden van de onderliggende uitvoerbare code en de live bewerkingsomgeving.

Live, interactieve documenten met de kracht van het Web Platform

Iodide documenten leven in de browser, wat betekent dat de berekeningsmotor altijd beschikbaar is. Telkens wanneer u uw werk deelt, deelt u een live interactief rapport met draaiende code. Bovendien, omdat de berekening in de browser gebeurt naast de presentatie, is het niet nodig om een taal backend in een ander proces aan te roepen. Dit betekent dat interactieve documenten in real-time worden bijgewerkt, waardoor naadloze 3D-visualisaties mogelijk worden, zelfs met de lage latentie en hoge framerate die nodig zijn voor VR.

Bijdrager Devin Bayly verkent MRI-gegevens van zijn hersenen

Delen, samenwerken en reproduceerbaarheid

Het bouwen van Iodide in het web vereenvoudigt een aantal van de elementen van workflowfrictie die we in andere tools zijn tegengekomen. Het delen is eenvoudiger omdat de tekst en de code beschikbaar zijn op dezelfde URL in plaats van, bijvoorbeeld, een link naar een script in de voetnoten van een Google Doc te plakken. Samenwerken is eenvoudiger omdat de rekenkern de browser is en bibliotheken kunnen worden geladen via een HTTP-verzoek zoals elke webpagina scripts laadt – er hoeven geen extra talen, bibliotheken of tools te worden geïnstalleerd. En omdat browsers een compatibiliteitslaag bieden, hoef je je geen zorgen te maken of het gedrag van notebooks reproduceerbaar is tussen computers en OS’en.

Om collaboratieve workflows te ondersteunen, hebben we een vrij eenvoudige server gebouwd voor het opslaan en delen van notebooks. Er is een publieke instantie op iodide.io waar je kunt experimenteren met Iodide en je werk publiekelijk kunt delen. Het is ook mogelijk om je eigen instantie achter een firewall op te zetten (en dit is inderdaad wat we bij Mozilla al doen voor wat intern werk). Maar belangrijk is dat de notebooks zelf niet sterk gebonden zijn aan een enkele instantie van de Iodide server. Mocht dat nodig zijn, dan zou het eenvoudig moeten zijn om uw werk naar een andere server te migreren of om uw notebook te exporteren als een bundel om te delen op andere diensten zoals Netlify of Github Pages (meer over het exporteren van bundels hieronder onder “What’s next?”). Door het rekenwerk in de client te houden, kunnen we ons richten op het bouwen van een echt goede omgeving voor delen en samenwerken, zonder rekenhulpbronnen in de cloud te hoeven bouwen.

Pyodide: The Python science stack in the browser

Toen we begonnen na te denken over het beter maken van het web voor wetenschappers, richtten we ons op manieren waarop we het werken met Javascript beter konden maken, zoals het compileren van bestaande wetenschappelijke bibliotheken naar WebAssembly en ze te verpakken in gemakkelijk te gebruiken JS API’s. Toen we dit voorstelden aan Mozilla’s WebAssembly wizards, boden zij een ambitieuzer idee: als veel wetenschappers Python prefereren, kom ze dan tegemoet waar ze zijn door de Python science stack te compileren om in WebAssembly te draaien.

We dachten dat dit ontmoedigend zou klinken – dat het een enorm project zou zijn en dat het nooit bevredigende prestaties zou leveren… maar twee weken later had Mike Droettboom een werkende implementatie van Python draaien in een Iodide notebook. In de volgende maanden hebben we Numpy, Pandas en Matplotlib toegevoegd, die veruit de meest gebruikte modules zijn in het Python wetenschap ecosysteem. Met de hulp van Kirill Smelkov en Roman Yurchak van Nexedi, kregen we ondersteuning voor Scipy en scikit-learn. Sindsdien zijn we beetje bij beetje doorgegaan met het toevoegen van andere bibliotheken.

Het draaien van de Python interpreter in een Javascript virtuele machine voegt een prestatieverlies toe, maar dat verlies blijkt verrassend klein te zijn – in onze benchmarks, ongeveer 1x-12x langzamer dan native op Firefox en 1x-16x langzamer op Chrome. De ervaring leert dat dit zeer bruikbaar is voor interactieve verkenning.

Het draaien van Matplotlib in de browser maakt de interactieve functies mogelijk, die niet beschikbaar zijn in statische omgevingen

Het inbrengen van Python in de browser creëert een aantal magische workflows. Bijvoorbeeld, je kunt je gegevens importeren en opschonen in Python, en dan de resulterende Python objecten benaderen vanuit Javascript (in de meeste gevallen gebeurt de conversie automatisch), zodat je ze kunt weergeven met behulp van JS bibliotheken zoals d3. Nog meer magie, kunt u toegang krijgen tot browser-API’s van Python-code, waardoor u dingen kunt doen zoals het manipuleren van de DOM zonder het aanraken van Javascript.

Natuurlijk is er veel meer te zeggen over Pyodide, en het verdient een artikel van zijn eigen – we zullen in meer detail gaan in een vervolg post volgende maand.

JSMD (JavaScript MarkDown)

Net als in Jupyter en R’s R-Markdown mode, kun je in Iodide code en schrijfwerk door elkaar halen zoals je wilt, door je code op te splitsen in “code chunks” die je kunt aanpassen en als aparte eenheden kunt uitvoeren. Onze implementatie van dit idee is vergelijkbaar met R Markdown en MATLAB’s “cell mode”: in plaats van een expliciete cel-gebaseerde interface te gebruiken, is de inhoud van een Iodide notebook gewoon een tekstdocument dat een speciale syntax gebruikt om specifieke celtypes af te bakenen. We noemen dit tekstformaat “JSMD”.

In navolging van MATLAB worden code chunks gedefinieerd door regels die beginnen met %% gevolgd door een string die de taal van de chunk eronder aangeeft. Momenteel ondersteunen we chunks met Javascript, CSS, Markdown (en HTML), Python, een speciale “fetch” chunk die het laden van bronnen vereenvoudigt, en een plugin chunk waarmee u de functionaliteit van Iodide kunt uitbreiden door nieuwe celtypen toe te voegen.

We hebben gemerkt dat dit formaat erg handig is. Het maakt het gemakkelijk om tekst-georiënteerde tools te gebruiken zoals diff viewers en je eigen favoriete tekst editor, en je kunt standaard tekst operaties uitvoeren zoals knippen/kopiëren/plakken zonder dat je sneltoetsen hoeft te leren voor cel management. Voor meer details kun je lezen over JSMD in onze docs.

Wat is de volgende stap?

Het is de moeite waard om te herhalen dat we nog steeds in alpha zijn, dus we zullen doorgaan met het verbeteren van de algehele oppoetsing en het verwijderen van bugs. Maar daarnaast hebben we een aantal functies in gedachten voor onze volgende experimenteerronde. Als een van deze ideeën eruit springt als bijzonder nuttig, laat het ons weten! Nog beter, laat het ons weten als je ons wilt helpen om ze te bouwen!

Extra samenwerkingsmogelijkheden

Zoals hierboven vermeld, hebben we tot nu toe een zeer eenvoudige backend gebouwd waarmee je je werk online kunt opslaan, werk van anderen kunt bekijken, en snel bestaande notitieblokken van andere gebruikers kunt forken en uitbreiden, maar dit zijn slechts de eerste stappen in een bruikbare samenwerkingsworkflow.

De volgende drie grote samenwerkingsfuncties die we willen toevoegen, zijn:

  1. Google Docs-stijl comment threads
  2. De mogelijkheid om wijzigingen aan het notitieblok van een andere gebruiker voor te stellen via een vork/samenvoeg-workflow, vergelijkbaar met Github pull requests
  3. Simultaan bewerken van notitieblokken zoals in Google Docs.

Op dit moment geven we ze ongeveer in die volgorde prioriteit, maar als je ze in een andere volgorde zou willen aanpakken of als je andere suggesties hebt, laat het ons weten!

Meer talen!

We hebben met mensen uit de R en Julia gemeenschappen gesproken over het compileren van deze talen naar WebAssembly, waardoor ze in Iodide en andere browser-gebaseerde projecten gebruikt kunnen worden. Ons eerste onderzoek geeft aan dat dit mogelijk zou moeten zijn, maar dat het implementeren van deze talen een beetje uitdagender zou kunnen zijn dan Python. Net als met Python kunnen er een aantal leuke workflows ontstaan als je bijvoorbeeld statistische modellen kunt fitten in R of differentiaalvergelijkingen kunt oplossen in Julia, en vervolgens je resultaten kunt weergeven met behulp van browser-API’s. Als het je interesseert om deze talen naar het web te brengen, neem dan contact met ons op – in het bijzonder zouden we graag hulp krijgen van FORTRAN en LLVM experts.

Export notebook archief

Eerdere versies van Iodide waren op zichzelf staande uitvoerbare HTML-bestanden, die zowel de JSMD code bevatten die in de analyse werd gebruikt, als de JS code die werd gebruikt om Iodide zelf uit te voeren, maar we zijn van deze architectuur afgestapt. Latere experimenten hebben ons ervan overtuigd dat de samenwerkingsvoordelen van een Iodide server groter zijn dan de voordelen van het beheren van bestanden op je lokale systeem. Desalniettemin hebben deze experimenten ons laten zien dat het mogelijk is om een snapshot te maken van een Iodide notebook door de Iodide code samen met alle data en bibliotheken die door een notebook gebruikt worden in één groot HTML bestand te stoppen. Dit kan een groter bestand worden dan je aan gewone gebruikers zou willen aanbieden, maar het kan nuttig blijken als een perfect reproduceerbare en archiveerbare momentopname van een analyse.

Iodide to text editor browser extension

Weliswaar zijn veel wetenschappers gewend om in browser-gebaseerde programmeeromgevingen te werken, maar we weten dat sommige mensen nooit code zullen bewerken in iets anders dan hun favoriete teksteditor. We willen echt dat Iodide mensen tegemoet komt waar ze al zijn, inclusief degenen die liever hun code in een andere editor typen, maar toegang willen hebben tot de interactieve en iteratieve functies die Iodide biedt. Om in die behoefte te voorzien, zijn we begonnen met het maken van een lichtgewicht browserextensie en enkele eenvoudige API’s om Iodide te laten praten met client-side editors.

Feedback en samenwerking welkom!

We proberen niet alle problemen van data science en scientific computing op te lossen, en we weten dat Iodide niet ieders kopje thee zal zijn. Als u terabytes aan gegevens moet verwerken op GPU-clusters, heeft Iodide u waarschijnlijk niet veel te bieden. Als je tijdschriftartikelen publiceert en je hoeft alleen maar een LaTeX-document op te stellen, dan zijn er betere tools voor je behoeften. Als de hele trend om dingen naar de browser te brengen je een beetje ineen doet krimpen, geen probleem – er zijn een heleboel echt geweldige tools die je kunt gebruiken om wetenschap te bedrijven, en daar zijn we dankbaar voor! We willen de manier waarop iemand werkt niet veranderen, en voor veel wetenschappers is web-gerichte communicatie niet het punt. Rad! Live your best life!

Maar voor de wetenschappers die wel content voor het web produceren, en voor degenen die dat misschien zouden willen doen als je tools zou hebben die ontworpen zijn om de manier waarop je werkt te ondersteunen: we zouden heel graag van je horen!

Bezoek iodide.io, probeer het uit, en geef ons feedback (maar nogmaals: houd in gedachten dat dit project zich in de alpha-fase bevindt – gebruik het alsjeblieft niet voor kritisch werk, en wees je ervan bewust dat zolang we in alpha zijn alles aan verandering onderhevig is). U kunt onze snelle enquête invullen, en Github issues en bug rapporten zijn zeer welkom. Feature requests en gedachten over de algemene richting kunnen worden gedeeld via onze Google-groep of Gitter.

Als u betrokken wilt raken bij het helpen bouwen van Iodide, we zijn open source op Github. Iodide raakt een breed scala aan software disciplines, van moderne frontend ontwikkeling tot wetenschappelijk rekenen tot compilatie en transpilatie, dus er zijn een hoop interessante dingen te doen! Neem contact op als dit je interesseert!

Heel veel dank aan Hamilton Ulmer, William Lachance, en Mike Droettboom voor hun geweldige werk aan Iodide en voor het reviewen van dit artikel.

Over Brendan Colloran

Meer artikelen van Brendan Colloran…

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.