Most organizations eventually encounter the need to automate and schedule repetative tasks. A common approach to this is using shell scripts and cron jobs. This article is a quick introduction to an alternative way of doing this: By writing python code and using Cloud Composer.

What is Cloud Composer?

Cloud Composer is a managed Apache Airflow service running on Google Cloud. Apache Airflow was created by Airbnb to manage and monitor their workflows . It has since been added as an Apache Foundation project. Many traditional workflow orchestration systems rely on XML configuration files. Airflow, on the other hand, lets a user write workflows using normal Python code. This simplifies integrations with other services (you can use normal Python libraries). I also makes it easier for developers to express logic in the workflows.

Using a managed Airflow service eliminates the need for maintenance and operations. We also leverage the benefits of integration with GCP services such as authentication, monitoring, and logging.

Example use cases

Some use cases where we have successfully used Cloud Composer include:

Moving files from SFTP servers to Google Cloud Storage.

Scheduling and monitoring BigQuery queries.

Monitoring BigQuery tables to ensure that new data is added at the expected rate.

How workflows are defined

Workflows are defined as directed acyclic graphs (DAGs) witten in Python. The DAG file defines tasks and dependencies between tasks. Tasks can be anything, and are implemented by operators. Here are some examples of operators:

BigQuery Operator: Query tables, export data, etc.

Kubernetes Pod Operator: Execute tasks on a Kubernetes pod.

Bash Operator: Execute bash commands.

Python Operator: Execute python functions.

It is also very simple to define your own operators if you have custom requirements. To do this, you simply extend the BaseOperator class and write your own logic.

A special type of operators called sensors are used to monitor for changes. A sensor can for example poll a storage bucket and trigger a DAG if a new file appears.

Creating an environment

The first step is visiting the Google Cloud Console and create a new environment. You should be fine using the default settings.

Cloud Composer will create a Kubernetes cluster for your Airflow environment. If you want to avoid any costs, consider running Airflow locally.

Once the environment is created, you can click the Airflow link to visit the Airflow web server. Here you can see all DAGs, previous runs and trigger new runs manually. By default, Cloud Composer includes an airflow_monitoring DAG to monitor that the environment is working. The web server is protected by Google IAP, so only authorised users can access it.

To add new DAGs click the DAGs link in the right side of the environments table. This opens a storage bucket. By adding a python script here the DAG will be discovered and run by Cloud Composer.

A sample DAG

We will deploy this simple DAG to illustrate how Cloud Composer works. The DAG consists of three tasks:

A bash operator that prints "Hello World"

A bash operator that pings google.com

A python operator that prints "Hello from the python operator!"

Task two and three can run in parallel, but they both depend on task one. Airflow uses bit shift operators to describe dependencies between tasks.

In the DAG constructor we specify the name of the DAG and how often we want it to run (every 5 minutes). After uploading the file to GCS it will appear in the Airflow UI. This may take a few minutes.

Clicking on the name of the DAG shows us more detailed information about the DAG. We can see a visual representation of the graph, historical runs, and even the code that defines the DAG. It is also possible to manually trigger a run from here.

After a short while the borders around the tasks should turn green. This indicates that the task executed successfully. Just above the graph there is a legend explaining the different colors codes.

If we click on a task we can see the parameters passed to the task and access the logs. Below we can see the logs from the task pinging google.com.

The task sent five pings to google, exactly what we expected it to do. The logs also include some information about the worker that ran the task.

There are a number of advanced features that are out of the scope of this article. Combining them makes it possible to create very powerful workflows. Some of them include:

Jinja templating to create macros and pass parameters to operators.

Backfilling which allows us to run a DAG for a specific time range.

XCom, a key-value store that allows tasks to communicate with each other.

Pros & Cons

Cloud Composer / Airflow is a very powerful tool, but it might not be the right tool for your use case. Here is a short list of some advantages and disadvantages.

Pros:

We can create complex workflows with dependencies and parallel execution of tasks.

A large set of community operators. Creating your own is easy.

You can use a familiar language (Python).

Open source, and you can run Airflow on your own if you want.

Cloud Composer has great integration with GCP. You do not need to worry about things like authentication.

With monitoring, retries, etc. Airflow DAGs are far more robust than classical cron jobs.

Airflow can also monitor external sources (e.g. SQL Databases) for changes, and trigger workflows based on these.

Cons:

Airflow is complex. There is a lot of configuration options available.

Understanding the scheduling may be a challenge.

Airflow does not version your DAGs.

Running workflows locally can be challenging.

Cost. Cloud Composer requires a kubernetes cluster to run. If you only have a few simple tasks you want to schedule this may be overkill.

Alternatives to Cloud Composer

AWS just launched a managed Airflow service.

Self hosting is always an option.

Combining managed services such as Cloud Scheduler and Cloud Functions (or similar services from other cloud providers).

Kubernetes CronJobs.

Task Orchestration using Cloud Composer

Vi har skrevet om det velkjente sitatet til Peter Drucker før; at kultur spiser strategi til frokost.

Vi har blant annet snakket om at dersom det finnes et gap mellom selskapets strategi og kultur, vil det være vanskelig å lykkes med målene vi setter oss. I dette julekalenderinnlegget tar vi et steg tilbake, til der det begynner.

Det begynner med menneskene

En organisasjon virker ikke uten menneskene, og når vi snakker om mennesker blir ting med en gang komplekst.

Tar vi en kikk innover, så kan nok alle anerkjenne at vi mennesker er nettopp komplekse vesener. Vi tolker situasjoner, danner oss erfaringer — og igjennom livet bygger vi ubevisst mentale modeller som hjelper oss med å navigere i våre omgivelser. Vi er ikke alltid så rasjonelle, selv om vi skulle ønske vi var det. I stedet har vi ulike måter å tolke ting på, ulike måter å reagere på.

Når vi samhandler med andre prøver vi å fortolke, passe inn og lære av andres adferd. Dette er mer tidkrevende for oss når omgivelsene er ukjente, eller føles utrygge. Jo tydeligere normene og verdiene rundt oss er, jo enklere blir det for oss å navigere i omgivelsene våre — og desto tryggere blir vi. Trygghet skaper igjen selvtillit, som fremmer prestasjoner.

I samhandlingen mellom mennesker formes det altså et sosialt system. Det er der normer og regler skapes; gjennom adferden mennesker har, viser vi hva som er akseptert i denne gruppen. Når slike normer og uskrevne regler er tydelig etablert for en gruppe mennesker er det enklere for hver enkelt deltaker å navigere og å føle seg trygg. Slike sosiale systemer formes i all samhandling mellom folk, det skjer i privatlivet og det skjer på jobb. En organisasjon er et godt eksempel på et sosialt system, der mennesker interagerer på ulike måter for å oppnå noe — sammen.

Det sosiale systemet i en organisasjonskultur

For å beskrive det abstrakte, det sosiale systemet i en organisasjon, snakker vi om en organisasjonskultur. Det kan best og enklest beskrives som hvordan vi gjør ting her. Det er virkelighetsoppfatningene, verdiene og normene som binder en gruppe mennesker sammen.

Organisasjonskulturen formes over tid og bygges av menneskenes adferd. Det finnes mekanismer vi kan iverksette for å fremme ønsket adferd og dermed forme kulturen, men det er ikke fokus i denne kalenderluken. Det viktige her er at vi selv er med på å skape kultur i måten vi er på, gjennom å observere måten andre er på, og ved at vi er sensitive for hva som er akseptert og ikke.

Vi bruker ofte isfjellet for å illustrere at noen deler av en kultur er synlig, mens det meste ved kultur er usynlig. Eksempler på de synlige delene av kulturen er det vi kan se, slik som kontorbygningen, logoen og hvordan folk kler seg på jobb. De usynlige delene handler om uskrevne regler, felles verdier og erfaringer som former de grunnleggende antagelsene vi styrer etter. Dette bygges opp av menneskers adferd og samhandling over tid, og er ikke like enkle å observere fra utsiden.

Så, kulturen i en organisasjon kan aller best merkes på kroppen. Se for deg at du kommer til kontorbygningen til et selskap du ikke kjenner, for første gang. Der har du raskt følerne ute. Skal jeg gjøre slik eller sånn? Slenge jakken på en stol og lene meg tilbake, eller henge jakken i garderoben og sitte mer oppreist? Du følger litt ekstra med. Alt fra tonen medarbeidere har seg imellom, til atmosfæren i situasjoner som møter eller pauser og hvordan noe markeres eller snakkes om. Det er gode indikatorer for å observere samspillet mellom folk i organisasjonen og det gir deg en anelse om hvilke verdier som ligger til grunn i hvordan vi gjør ting her.

Fordi en organisasjonskultur formes av samhandling mellom individene i den, er ingen organisasjonskulturer like. Men det som er likt for alle, er at kulturen i et selskap er svært definerende for hvorvidt selskapet lykkes med å nå sine mål.

Hvorfor er kulturen så viktig?

Når et selskap skal lykkes med sin visjon, og sin strategi for å komme dit, vil premissene som ligger til grunn blant menneskene som deltar være førende for hvordan veien mot målet blir.

Som nevnt krever det hjernekapasitet å tolke våre omgivelser. En uro og utrygghet krever mer, og hemmer våre prestasjoner - mens trygghet fremmer dem. Det kan vi bruke som den korte og enkle forklaringen for at en sterk og trygg organisasjonskultur også er definerende for et selskaps suksess. (Du kan høre mer om pyskologisk trygghet i vår podcast Drypp).

Hvis vi skal forsøke å si noe om hva som kan defineres som en sterk kultur, kan vi trekke frem noen kjennetegn. Det er en kultur med:

Klare normer og verdier

Vektlegging av menneskelige ressurser

Karismatiske ledere, helteskikkelser eller felles historier som gir tilhørighet

Ritualer og seremonier for å markere hendelser og forsterke positiv adferd

Klare forventninger til styring som stemmer overens med virkeligheten

En sterk kultur er altså en tilstand der folk er samstemte om hvordan vi gjør ting her. Når vi er trygge på hvordan det fungerer hos oss, er det enklere å navigere i det sosiale systemet og det stjeler mindre krefter til tolkning og vurdering. En sterk kultur har mange fordeler når den støtter strategien, men kan gi desto større barrierer dersom den bryter med strategien. Alt avhenger av konteksten, og om en kultur er ødeleggende eller oppbyggende ligger i uttrykket til Peter Drucker;

Kulturen som spiser strategi til frokost

Det velkjente begrepet er veldig beskrivende. En strategi er planen vi har for å nå et mål. Hvis den planen bryter med hvordan vi gjør ting her, uten at det tas grep for å justere det, står vi i stor fare for å mislykkes.

Når vi i det overnevnte har etablert at kultur er et sosialt system, og at det er formet av hvordan individene i en organisasjon samhandler, forstår vi også at kulturen som spiser strategi til frokost er helt reelt. De etablerte normene og verdiene til menneskene i organisasjonen, som definerer adferden til hver enkelt, er en utrolig sterk kraft når disse er godt etablert. Samsvarer strategien dårlig med de fundamentale verdiene i kulturen, vil den ikke resonnere godt nok hos menneskene som skal utføre den. Da sier det seg selv at uavhengig av hvor god strategien din er — i teorien — vil den ikke lykkes i praksis dersom kulturen i organisasjonen ikke er i stand til å ta den imot. Når man arbeider med strategi og endring er det derfor sentralt å forstå om kulturen støtter oppunder, eller skaper barrierer for de nødvendige endringene en ny strategi medfører.

Selv om kultur er et abstrakt begrep, går det an å jobbe med å forme kultur. Det går an å jobbe med å skape endringskapasitet og fleksibilitet, for å få igjennom nye og fremtidsrettede strategier. Hvordan vi kan påvirke kulturen i en organisasjon skriver vi mer om i morgen.

Hvorfor kan kultur spise strategi til frokost, egentlig?

Simula har, sammen med FHI, fra starten prioritert sikkerhet og personvern svært høyt i utviklingen av appen.

Ulike varianter av dette sitatet finner vi mange intervjuer om Smittestopp. Politikere, helsebyråkrater og utviklerne forsikrer at sikkerhet og personvern er ivaretatt. Kontrasten til Smittestopp-havariet er oppsiktsvekkende. Hvordan kan dette forstås?

Personvern og Smittestopp

Den primære årsaken er en grunnleggende mangel på forståelse for personvern. Spørsmål og innsigelser om personvern besvares med utsagn om at sikkerheten er ivaretatt. Men personvern er noe annet - og mye mer - enn sikkerhet.

La oss se på årsakene til at Datatilsynet la ned forbud mot behandling av personopplysninger i Smittestopp

Forholdsmessighet og nytteverdi

Datatilsynet mente at FHI ikke hadde dokumentert appens nytteverdi. Forholdsmessighetsprinsippet sier at nytteverdien må være større enn ulempene ved inngrepet. Hvis man ikke vet nytteverdien, kan man heller ikke forsvare personverninngrepet.

Her kan det se ut som FHI og Simula hadde blind tro på at Smittestopp kunne stoppe pandemien. I flere sammenhenger refererer de til Oxford-rapporten, som hevder:

A contact-tracing app that builds a memory of proximity contacts and immediately notifies contacts of positive cases can achieve epidemic control if used by enough people.

Vi kan kjenne igjen denne overoptimismen fra et intervju med Olav Lysne i mai:

En vitenskapelig artikkel i Oxford viste at om vi klarer å finne fram til 60 prosent av smittebærerne, og få dem i karantene, er det nok til å holde smittetallet nede, sier Lysne og fortsetter:



- Om vi klarer det, kan vi gå tilbake til å ha fotballkamper, gå på festivaler og gi hverandre klemmer igjen. Appen vil være med og redusere, sier Lysne.

Vi kan imidlertid konkludere med at mobil kontaktsporing langt ifra har vært en gamechanger i noen land. Rotårsaken er at smittespredning og Bluetooth-nærkontakter er vesensforskjellig, som mange innvendte helt fra starten.

Forskrift, frivillighet og formål

Smittestopp var hjemlet i egen forskrift. Mona Naomi Lintvedt skriver i en kommentar om Smittestopp 2 at myndighetene bør ha hjemmel for slike tiltak: "Hjemmel gir forutsigbarhet og åpenhet for borgerne, og det vil være mulig å kontrollere underveis at appen faktisk er utformet i tråd med regelverket og at FHI utøver sin myndighet i tråd med hjemler de er gitt. Og ikke minst kan det sikre den legitimitet og tillit dette tiltaket sårt trenger dersom det skal ha effekt".

Datatilsynet bemerket at "I og med at behandlingen gjennom Smittestopp er hjemlet i forskrift, kan endring av formålet også skje ved forskriftsendring, og det er verdt å merke seg at forskriften ble vedtatt uten å bli sendt på høring".

Et sentralt poeng var at bruken av appen måtte være frivillig, og det gjentas i mange sammenhenger i argumentasjonen fra FHI. Imidlertid kan man innvende om bruken reelt sett er frivillig når Statsmininsteren oppfordrer til å laste ned Smittestopp "hvis vi skal få hverdagen og friheten tilbake". Selv opplevde jeg pålegg om bruk av Smittestopp i den lokale håndballklubben, en dyrepark og flere kafeer. Dessuten var det åpenbart at Simula ikke hadde fått med seg at bruk av appen var frivillig, da de beskyldte kritikerne for å være ubarmhjertige egoister som satte eget personvern framfor andres helse.

Smittestopp hadde to uttalte formål: Kontaktsporing samt overvåkning på befolkningsnivå for å bidra til å følge smitteutbredelse og vurdere effekt av smitteverntiltak. Datatilsynet bemerket at formålene også omfattet analysearbeid og forskning. I tillegg var det problematisk at befolkningen ikke kunne velge mellom ulike formål, eksempelvis bare bidra til kontaktsporing. FHI hadde forøvrig fått råd om å hente inn delt samtykke for Smittestopp før lansering fra De nasjonale forskningsetiske komiteene. Stortinget vedtok også å be FHI å dele opp i to ulike samtykker i tumultene rundt havariet.

Dataminimering og innebygd personvern

Innebygd personvern er et sentralt krav i personopplysningsloven og betyr at det tas hensyn til personvern i alle utviklingsfaser av et system eller en løsning. Åpenhet er et nøkkelord i regelverket og det er også avgjørende når man bygger personvern inn i programvaren.

Simula valgte å holde kildekoden lukket, begrunnet i "å tilgjengeliggjøre kildekoden fører ikke til økt personvern". Dette er direkte feil. Et viktig prinsipp i innebygd personvern er at behandlingen for de registrerte fremstår som åpen og rimelig.

Prinsippet om dataminimering innebærer å begrense mengden innsamlede personopplysninger til det som er nødvendig for å realisere innsamlingsformålet. Datatilsynet påpekte at innsamling av lokasjonsdata ikke var nødvendig for smittesporing og varsling, og dermed et brudd med dataminimeringsprinsippet. I tillegg var det tvilsomt om sentral innsamling av data var nødvendig gitt at det fantes desentraliserte tilnærminger der data ble lagret på mobilene.

Det er også interessant å lese vurderingene fra FHIs personvernombud til DPIAen for Smittestopp. Her diskuteres dataminimering i kontekst av å slette data når de ikke lenger er i bruk. Imidlertid betyr dataminimering primært å unngå å samle inn mer info enn nødvendig til formålet i utgangspunktet.

Masseovervåkning og anonymisering

Smittestopp ville blitt den mest inngripende og omfattende masseovervåkningen av Norges befolkning gjennom tidene. Det er problematisk av mange grunner. I tillegg til risikoen for tyveri og lekkasje, var også formålsutglidning heftig diskutert. Data som finnes vil bli brukt. Nedkjølingseffekten er også en konsekvens, ved at befolkningen endrer adferd under overvåkning og begrenser privat og offentlig meningsbryting. På sikt er den mest alvorlige konsekvensen at vi ville endret toleransegrensen for når og hvorfor overvåkning var nødvendig. Det er ironisk at Simulas Kyrre Lekve anerkjenner at masseovervåkningen er problematisk, men svarer ved å peke på sikkerhet samt oppfordre befolkningen til å stole på myndighetene: "Det er veldig mange land jeg mener ikke bør ta i bruk den norske løsningen...".

Et svar fra Simulas Smittestopp Q&A sier mye om hvordan de tenkte rundt masseinnsamlingen av data. Simula bagatelliserer innsamlingen ved å framstille det som behandlingen starter først ved bruk. Dette er hårreisende lesing:

Blir jeg sporet hele tiden?



Nei. Programmet søker bare etter tilfeller av nærkontakt etter at en bruker er testet og bekreftet smittet. Den følger ikke individers bevegelser og heller ikke hvor de befinner seg. Den finner bare tilfeller der en bruker har vært mindre enn 2 meters avstand for mer enn 15 min fra en konstatert smittet bruker. Telefonnumrene til telefonene som har vært i nærkontakt vil brukes av helsemyndighetene til å sende ut varsling.

Som en forutsetning for analyseløsningen skulle innsamlede data anonymiseres. Det første problemet var at FHI begynte å samle inn data før analyseløsningen var på plass. Store mengder personopplysninger ble fortløpende samlet inn, uten at FHI hadde praktisk mulighet til å gjøre bruk av dataene. Datatilsynet fant dette særlig kritikkverdig. Den andre problemstillingen, som man aldri fikk svar på, er om det faktisk er mulig å anonymisere dette datasettet. NRK viste i denne perioden hvor enkelt det var å identifisere enkeltindivider ved å analysere lokasjonsdata. Sist men ikke minst fremsto det som uklart om FHI forsto personvernsforskjellen mellom pseudonymisering og anonymisering, og at pseudonymiserte personopplysninger fremdeles er personopplysninger.

Personvern != sikkerhet

Smittestopp hadde altså en rekke personvernsproblemer. Sikkerhet er ikke relevant for brorparten av dem. Eksempelvis kan nytteverdien umulig bli bedre på grunn av sikkerhet. Problemene med forskrift, frivillighet og formål avhjelpes heller ikke med sikkerhet. Tilsvarende kan ikke dataminimering eller innebygd personvern løses kun ved å forbedre sikkerheten.

Når det er sagt, er det riktig at personvern forutsetter god sikkerhet og beskyttelse av personopplysningene som behandles. Autentisering, tilgangskontroll, innsynslogging og kryptering er viktige sikkerhetstiltak som brukes for å sikre dataene. Men selv om sikkerhet er en viktig del av personvern, er det bare en begrenset del. Sikkerhet kan bare på spesifikke områder kompensere for noen av personvernsvakhetene beskrevet ovenfor.

Smittestopp hadde forøvrig også en rekke rene sikkerhetssårbarheter og -svakheter:

Permanente, enhets-spesifikke identifikatorer mellom enhetene, som åpnet for å kunne utlede andres identitet eller smittestatus. På tross av at dette var en kjent feil, valgte FHI å lansere appen til hele befolkningen.

Manuelt oppsett av skyløsningen i Azure. Åpner for menneskelige feil ved endring og vedlikehold, infrastrukturen kan ikke gjenskapes, vanskelig å gjøre en sikkerhetsanalyse.

Bruk av en preview-feature i Azure IoT-Hub som leverandøren selv sier man ikke skal bruke til å prosessere personopplysninger.

Bruk av SMS for varsling medførte en risiko for svindel og forfalskning.

Dårlig kodekvalitet som gjør det vanskelig å vedlikeholde, forstå og feilsøke.

Manglende automatiserte tester.

API nøkler og passord i kildekoden og Git-historikken.

Funnene indikerer manglende sikkerhetskompetanse og -kultur. Dette er fullstendig uakseptabelt når man skal passe på sensitive data om store deler av befolkningen. En løsning som er hasteutviklet vil dessuten være mer utsatt for feil og sårbarheter enn løsninger som har hatt bedre tid til sikring og vært i bruk lenge. Det er nærmest parodisk når Simula hevder at "Appen er akkurat like sikker som andre tjenester".

Skrikende behov for personvernkompetanse

Det er underlig og skremmende å lese at personvern har vært prioritert svært høyt i utviklingen av Smittestopp. Selv med tydelige tilbakemeldinger fra Datatilsynet, Amnesty, EUs personvernsråd, ekspertgruppen samt eksperter på teknologi og personvern, fortsatte Helseministeren og FHI å si at de var uenige i Datatilsynets vurdering. Simula prøvde å redde stumpene ved å hevde at Smittestopp havarerte fordi inngrepet ikke lenger var forholdsmessig når smittetallene hadde blitt så lave. Som vi har sett ovenfor var Smittestopp ulovlig av mange grunner.

Det er forsåvidt greit å være uenig i Datatilsynets vedtak. Men da er man sannsyligvis uenig i selve Personopplysningsloven. FHI valgte forøvrig ikke å klage på vedtaket fra Datatilsynet.

Smittestopp har avslørt et skrikende behov om bedre personvernkompetanse i offentlig forvaltning. Sentrale politikere og beslutningstakere er ute av stand til å innse sin manglende kunnskap, mens de ignorerer faglig kritikk uten engang å forstå den.

Personvern er obligatorisk

Smittestopp har vist at manglende forståelse og respekt for personvern kan velte en løsning. Behandling av personopplysninger starter ved innsamling, ikke ved bruk. Personopplysningsloven krever at den som behandler personopplysningene dokumenterer forholdsmessighet, nødvendighet og nytteverdi.

Sikkerhet er viktig i personvernsammenheng, og det krever tid og kompetanse å lage sikre løsninger. Men sikkerhet kan ikke kompensere for de ulike kravene og praksisene som loven pålegger. Tilliten til en løsning krever åpenhet, kritisk drøfting av tiltak, at man er villig til å erkjenne feil og viser at man lærer av dem. Sist men ikke minst: Personvern dreier seg om hva Personopplysningsloven sier, ikke om hva man synes.

Smittestopps prislapp på 45 millioner er et røverkjøp hvis den har ført til økt kunnskap og forståelse for personvern i offentlig forvaltning og i befolkningen generelt.

Personvern != Sikkerhet

For deg som er ute etter artikkelen om hvordan du kan bli en bedre designer på tre minutter – dette er ikke den artikkelen. Dette er en historie, eller en samling av historier, fra meg og fra mine kollegaer, til deg. Om hva året 2020 har gitt oss - på godt og vondt, hardt og mykt. Denne artikkelen skal ikke konkludere med noe som helst, og får deg ikke nødvendigvis til å rope heureka. Tvert i mot, det skal bare fortelles og deles, rives og åpnes. Jeg håper du liker det du får!



Den første historien starter en tirsdag, i midten av november i 2020. Jeg sitter på sofaen i stua, og på skjermen ruller nok en episode av Friends av lerretet. Jeg ser på klokka og innser at jeg har hatt lunsjpause i over en time. Litt skuffa ser jeg også at jeg fortsatt sitter i pysjbuksa. Det er 3 minutter til jeg skal være i et møte. Ikkeno stress tenker jeg, for kontoret mitt er knappe 13 skritt unna.

Jeg setter meg ned ved arbeidspulten, og kollegaen min og jeg setter i gang med møtet. Vi går gjennom samme tørrprat-tralten – “Ja du er på hjemmekontoret? Ja, går vel for det meste i det. Var en tur innom kontor-kontoret for to uker siden, det var ganske sweet… Yes, la oss sette i gang med møtet”.

Etter møtet sitter jeg igjen med hånden halvveis i været, med smilet limt på ansiktet frem til jeg er helt sikker på at videoen er slått av. Rommet fylles av stillheten og aleinetiden som bare hjemmekontoret kan by på.

La oss spole tilbake til mars i år. Norge er gått i sosial lockdown, og ingen av oss aner hva dette egentlig innebærer, sånn in the long run. «I disse koronatider» begynner å bli de mest beskrivende orda vi har. Vår arts tilpasningsevne får muligheten til å virkelig briljere. Vi rigger oss til i den kroken vi har, med det hjemmekontoret vi trenger. Vi ringer hverandre over video, og forteller energisk om hvor deilig det er å gå en runde rundt blokka før dagen starter, for å skille mellom jobblivet og ikke-jobblivet. På internett ser vi filmsnutter fra hele verdenen av folk som danser til balkong-konserter, og vi klapper for helsearbeiderne. Sistnevnte dog for å overdøve den høye summetonen som kommer når 5G-nettet skal testes. Barn tegner regnbuer og henger de opp i vinduene, signert «Alt vil bli bra». Om ikke, så går det over sant? Sånn, etter sommeren i verste fall.

Nå er det november, og jeg sitter i møter med kollegaen min i pysjbuksa.

Året så langt har vært bare myke pakker. Og ja, jeg er redd det er for sent å ta det pent. Jeg føler meg ikke helt ferdig snakka om hvor skoddete, seigt og spesielt det er å leve under en pandemi.

Så det er det jeg har lyst til nå da - snakke, fortelle og dele. Jeg håper at ved å få flere til å dele, jo sterkere blir budskapet om at det er helt innafor å miste maska når du atter en gang strekker deg mot en myk pakke under juletreet med ditt navn på, og innser at det er hjemmestrikka grytekluter. Spesielt siden du har hundre av de fra før, og alt du ønska deg til jul var lego.

Som en liten inspirasjon, så har jeg nådd ut til mine design-kollegaer i Bekk og spurt om de vil dele hvordan dette året har vært for de. Jeg håper at dette setter i gang refleksjons-tannhjulene også hos deg som leser. For om ikke jula er tida for refleksjon og ettertanke, når da?







Live

“Jeg har lært utrolig mye om mitt eget sosiale behov, og hvor stort det egentlig er. Jeg er jo en introvert av natur, men en veldig sosial introvert. Tidlig i juli flyttet samboeren min midlertidig til en annen by i forbindelse med jobb, og jeg husker at da jeg la meg den kvelden, så tenkte jeg at det var første gang jeg hadde vært alene, sånn på ordentlig, siden 12. mars. Det varte heldigvis ikke så lenge. Jeg tror jeg hadde flere middagsbesøk i juli og august enn resten av året sammenlagt. Det jeg har lagt merke til, både på jobb og ellers, er at jeg har begynt å ta mye mer aktivt ansvar for å få litt sosialt påfyll. Enten gjennom å invitere venner på middag, sette opp en fast kaffeprat på jobb eller andre ting. For min del har rutine vært nøkkelen til hjemmekontor. Det å sminke seg og ta på seg kontortøy før man “går på jobb” er en veldig fin måte å sette seg i riktig mindset for dagen, synes jeg.

Det jeg synes har vært best med denne tiden er at jeg føler man snakker mer om de viktige tingene. Det er mindre “fluff” fordi det er mindre som skjer, og da dukker de ekte temaene opp i stedet. Alle er jo preget av det som skjer i større eller mindre grad, og jeg tror at det også gjør det lettere for oss å svare ordentlig på spørsmålet “Hvordan har du det?”. Når man først deler selv, kommer det ofte tilbake, og man blir dypere kjent. Men jeg har også merket en tendens til “jeg har jo ikke noe å klage over, for alle andre sitter i det samme”, og det er jeg ikke helt enig i. Om man har det bra eller ikke er ikke noe man skal finne ut av ved å sammenlikne seg selv med andre, synes jeg.”







Åshild

"2020 har lært meg at eg må konsentrere meg om meg sjølv og kva eg gjer og ikkje gjer – i starten blei eg så utruleg stressa av alle som ikkje fulgte korona-reglene, at eg blei heilt bitter og sliten av det. Eg har lært at folk bretter opp ermene og bidrar. Eg hadde aldri i min villaste fantasi trudd at eg i året 2020 skulle ta på meg munnbind for ein snartur inn på Kiwi og antibace opp og ned i mente.

Det har vore utruleg kjipt med alle jobb-arrangementene som har måtte blitt avlyst som jo ofte er høgdepunkt i løpet av året. Sommarfest, Bekk sitt 20-årsjubileum (som eg har gleda meg til sidan forrige jubileum i 2015), fagdager, julebord… Eg vil berømme alle som har lagt ned ein innsats for at det likevel har blitt gjennomført enkelte arrangement, og eg er veldig takknemleg for det. I koronaåret 2020 må me berre bukke, nikke og neie for alt me har fått til å gjennomføre.

Det har vore trist å ikkje kunne klemme vener og familie, og at eg ikkje har fått sett dei like ofte som eg har ønska sjølv. Eg er jo utruleg ekstrovert, så eg merker jo godt at det kribler i sosial-cellene mine etter ein meir normal kvardag.

Sist men ikkje minst: eg har lært at eigentid er gull – det har vore veldig deileg å stresse ned. Ikkje føle at ein må vere med på alt. Og berre vere heime."







Ola

"Ja, hva fanken har jeg lært av dette året. Jeg får litt dårlig samvittighet når jeg blir spurt om noe er annerledes etter dette året. Føler at jeg burde ha sett kollegaer eller teamet mitt på en annen måte. Det gjør meg kanskje litt egoistisk? Jeg vet ikke om jeg har gjort andres eller min egen hverdag bedre, FAKK. Føler egentlig at 2019 Ola er ganske lik 2020 Ola…

Jeg hadde en liten meltdown etter påske. Da følte jeg at jeg ikke klarte å levere i hele tatt. Å lede kreative møter når alle kan slå av mic og video, det synes jeg var ganske tøft. Nå i høst har hjemmekontoret heldigvis gått litt bedre. Jeg opplevde jo å være på et møte der noen sovnet, og vi andre som satt i møtet kunne høre at han snorket. Og det første jeg tenkte var; åh heldiggris – det der vil jeg også. Prosjektlederen min brukte 10 minutter på å prøve å unmute han, for Teams var nytt og greier. Man ser veldig fort hva som er et nyttig møte, og hva som ikke er det. Når jeg kan brette tøy og vaske på innsiden av skap, kjøre støvsugeren frem og tilbake, da tenker jeg at dette møtet trengte jeg kanskje ikke være med på.

Jeg er utrolig dårlig på faste lunsjtider, spiser kun når jeg har behov for det. Spiser et eple, drikker 1,5 liter kaffe frem til kl. 11:00-14:00, inni der en plass spiser jeg 2 brødskiver. Kl. 16:00 tar jeg enda et eple, og slenger jeg meg på sofaen og scroller på TikTok i 20 minutter. Jeg har kanskje blitt mer åpen for ungdommelige sosiale medier dette året, hehe. Nei, jeg er bare lei jeg, ønsker bare at det skal gå over. Ønsker at folk skal ta vaksiner. Det er så kjedelig dette her. Den er så lite sexy den pandemien, den er så utrolig lite spennende. Hadde det vært en ny istid eller noe, hadde det i hvert fall vært litt interessant!

Forrige lørdag fikk jeg en skikkelig god følelse. Jeg hadde på Nyhetsmorgen, og en av FHI-toppene sa at hjerte-og karsykdommer, slag og hjerteinfarkt har gått ned dette året. Da tenkte jeg: shit, kanskje 2020 er året alle bare slapper av.”







##Linn

"Jeg er over middels glad i å planlegge hverdagen. Og den siste tiden, så kan jeg vel si at jeg har fått øvd meg på å ikke planlegge så mye. Ta en dag om gangen. Jeg kan late som at det liksom har vært deilig og rolig. Og det har det jo av og til vært. Men egentlig har det bare gjort meg latere. Det har blitt mindre trening og færre spennende ting som skjer gjennom dagene.

Jeg har lært og opplevd å ta hensyn til at folk reagerer på disse situasjonene helt forskjellig og at det er helt greit. Ingen shaming! At det som var helt greit og innafor én uke, plutselig ble sett på som en lite gjennomtenkt beslutning uka etterpå. En uke er en venn mer bekymret og ønsker ikke å møtes fysisk, en annen uke er det noen andre. Noen Bekkere ønsker å møte fysisk til fagdag, andre tenker det er det siste de ønsker å utsette seg for. Og jeg håper virkelig at vi kan være åpne og se alles behov og ønsker i dette.

Jeg jobber i NAV og med fokus på arbeidssøkere. Å se tallene stige dag for dag, time for time i de verste periodene – det har vært rart og nesten uforståelig. Å vite at det er så mange skjebner og livssituasjoner som er endret. Da har jeg kjent på mange følelser. Blant annet både håpløshet og sterkt engasjement.

Jeg synes det har vært skikkelig vanskelig at arbeidsplassen er samme sted som avslappingen. I sommer, da det var tre dager igjen av sommerferien, så gruet jeg meg skikkelig til å komme hjem til leiligheten. Det var jo der jobben var. Jeg var bekymret for at jeg ikke skulle klare å slappe av de siste feriedagene. Nå har jeg blitt flinkere og flinkere til å virkelig rydde bort jobben når arbeidsdagen er over. Å bare se en tom post-it lapp er nok for å få hjernen til å spinne og spinne."







##Anders

"De første ukene av pandemien var jo nesten litt spennende. Jeg var på Hurtigruta, og her traff det kanskje hardest for Bekk. Det føltes som at vi håndterte noe viktig. Deretter kom bølge to rundt august, og det var veldig tøft å komme i gang igjen for folk flest. Den siste bølgen nå føles nok for mange som en slags resignasjon - jeg har stor forståelse for at noen opplever det utmattende og krevende.

I Bekk er det cirka 500 ansatte. Dette året har vært en solid bekreftelse på homo sapiens sin omstillingsevne til en veldig annerledes hverdag. At selskapet vårt i løpet av noen få uker fikk nesten 500 mennesker til å fortsette å opprettholde fremdrift i prosjektene, og kvalitet på leveransene, det var utrolig gøy å se på. Samtidig har det vært viktig å forstå at disse 500 er enkeltpersoner, og det som i utgangspunktet er superenkelt for en person kan være vanskelig for andre. Jeg er jo en særing. Jeg har lært at den isolasjonen som oppstår med et hjemmekontor, ikke preger meg så mye. Folk er flinke til å stå med lua i hånden, det er liksom skambelagt å klage. Det finnes nok fortsatt folk som ikke tør, eller føler de kan si at de hæler ikke å sitte på hjemmekontoret.

Det er nyanser på ulike fag. Satt på spissen – teknologene kan blomstre om de ikke blir forstyrra, de får gå inn i flyten sin og skrive poesi i kodeform. Dette er ikke like lett for designerne - de trenger å møte løpende motstand og reaksjoner i arbeidet sitt, og dette blir vanskeligere fra hjemmekontoret. Tavla og papiret har en viktig oppgave i det å vise arbeidet til en designer. Å designe i et vakuum er ikke like enkelt. Dette kan skape usikkerhet på eget arbeid. De små bekreftelsene på riktig eller feil kurs mister man i en sånn solo-greie som hjemmekontoret blir.

Midt i koronakrisa sto jeg med kniven på strupen og skulle håndtere Bekk og smittevernsreglene – samtidig som at jeg hadde en far hjemme som venta på hjerteoperasjon. Han kunne jo på ingen måte få korona, og den generasjonen klarer jo ikke å ta dette på alvor. De tenker at ved å dyppe hendene i lunka vann så har man vaska de, og klemmer man bare lett på kinnene så er man forsiktig. Men så har jo det gått fint, han har kommet seg gjennom det. Jeg har jo aldri før vært bekymra for at foreldra mine skal bli forkjøla."





De harde og myke pakkene i 2020

Most of us feel very uneasy before going on a stage or in front of a live tv-camera. Rationally you can tell yourself that even if it all goes wrong, in a few hours you will still be alive, that you’ll still have your friends and your job. And you’ll be right. Even if you forget what to say, stutter and run crying off stage, the actual impact on your life is not that important. It’s not a matter of life and death, is it?

As an evolutionary biologist who’s been fortunate to appear on some tv- and radio shows, I’ve wanted to understand why we feel so nervous before appearing in front of an audience and how to overcome it. To hack your stage fright away, you must first understand why your mind is designed this way.

Mismatch

Evolution is a very slow design process as it takes many generations for even the most important adaptations to become a part of our nature. Even fundamental traits like being able to digest a new easily available energy source will take one hundred thousand years to become common. As a result, our emotions are not perfectly designed to reflect how dangerous a situation really is in modern life. Speaking up in front of an audience is not a matter of life and death. Not now.. but it probably was in most of our earlier history. And because evolution takes ages to redesign us to match this new reality, “stage fright” is still part of our psychological wiring.

Our natural environment consists of people

Other humans and what they do are important parts of the environment for us humans. “People” is probably the most important environmental factor in our lives. To put it in evolutionary terms: the most important thing affecting the number of grandchildren a human could get, is other people. One of my favorite recent scientific discoveries highlight just how extremely wired we are to care about what other people think.

The Brain’s default mode network

For several decades scientists have used MRI-machines to study how different areas in the brain get activated when a person is given a specific task. Some areas, aka “language centers”, light up when the research subject is asked to speak or read. Other areas are activated when solving math problems or listening to Beethoven.

But what happens in the brain when a person is resting? Does the brain deactivate?

Some researchers continued the scan after telling the person in the MRI-machine to relax. What they found was that other areas in the brain lit up. It turned out that this was not some random brain activity, but areas that are active in most people when they relax and do nothing. It’s like a default state that the brain returns to after finishing work. Because of this it was called “The Brain’s default mode network” and thought to be like a screensaver that keeps the brain healthy until it gets something useful to do again.

Only recently have neuroscientists discovered that the default mode network overlaps almost perfectly with the brain areas that get active when people think about their social relationships.

This is mindblowing. Literally.

Instead of going to a default “screensaver” when there is nothing better to do, our brain spends as much time as it can to think about other people. We simulate complex social relationships whenever we can. “What would he do if I said..”, “what if she knew, that I know..”, “how can I get back at that guy who told everyone that…”. This is what we, as humans, are designed to do when we relax.

(Ever sat down a friday evening with social media on your phone or a soap opera on TV? Yup. That’s you putting your brain’s default mode network to work.)

Stage fright

Other people’s opinion of us affect who we can form an alliance with, who will protect you, who will go against us, who you can attract as a partner, which opportunities you get and much more. This is far from trivial. These are central evolutionary problems (see our blog post ux.christmas/2019/4) for a social species such as ours. And that is why your brain and emotional systems get so fired up before talking to a crowd.

The hack(s)

So, doesn’t this mean that it’s only natural to be scared to death over a presentation? Yes, it does. But realizing this is helpful. Because you have to trick your paleolithic mind into believing it’s in a slightly different situation. Here’s how I do it:

Pretend you’re just going to talk to your friends about something you know really well (and most of the time, this is sort of true)

Try to feel like when you are about to give your friends a gift (you really are, by sharing something you know)

Remember that you really know how to speak. You’ve done it almost every single day of your life

Don’t worry about saying something wrong. Any mistakes you talk yourself into, you can talk yourself out of.

And if none of these hacks work: hey, you’ve found a cool and relatable topic for your next talk! Share it!

Hack your paleolithic mind to overcome stage fright

Today we'll look at an interesting property of Elm known as currying. We will only explain the principle today, then spend the next two days seeing how it can be useful in practise.

Have you ever wondered why type signatures look the way they do? They seem intuitive for simple functions such as this:

Here we can see that aboveZero is a function which takes an Int and returns a Bool. Seems straightforward. Now look at this function:

Many will read this type signature in a different way compared the the easier definition we saw earlier. They might say that isBetween is a function which takes three Ints and returns a Bool. But if that's the case, why are we forced to write all those arrows? Especially considering arrows seemingly work both as a input separator and as a separator between inputs and outputs.

Actually, arrows only seperate one input value and a return value. The type signature for isBetween should be read as 'a function that takes an Intand returns a function that takes an Int and returns a function that takes an Int and returns Bool'. This is the same type signature, but written differently:

For esthetic reasons, Elm allow us to write the type signature without the parentheses.

The key thing to learn from this is that there is no such thing as a function taking multiple arguments. All functions take exactly one argument, and returns something else. That something else might be another function. This also means that when calling a function with more than one argument, it's not only valid to call it in the following way, it's also what conceptually happens:

This property of functions only taking one argument is known as currying, and is a defining feature of languages like Elm and Haskell. But why should you care about this? When is this knowledge ever useful?

That's what we'll explore in the coming days.

Hurry, curry!

With the release of Kotlin 1.4 we got a new treat; kotlinx.serialization. A new tool to help us with the cumbersome task of converting our objects to and from Json.

We've previously seen how some libraries may not support kotlin completely, but this is obviously not the case with kotlinx.serialization as it is written in Kotlin and supported for all Kotlin multiplatform targets.

kotlinx.serialization provides a framework for converting an object into a sequence of bits and bytes, and of course a way of converting it back into an object. It ships with support for Json, Protobuf, CBOR, Properties and HOCON, albeit all except Json are at this point considered experimental.

To achieve this level of flexibility the process is split into two distinct phases; serialization and encoding. The serialization phase is shared between all data formats, and is responsible for converting a object into a serial sequence of primitives. The sequence of primitives is then passed on to encoding, where the data format specifics are responsible for converting those primitives into their correct output format.



The process of serialization and deserialization are encapsulated within the KSerializer<T> interface, whereas encoding and decoding have their own aptly named interfaces; Encoder and Decoder.

To get started using kotlinx.serialization you will have to make some changes to your build configuration. First you'll need to add the compiler plugin used to generate the serializers for your classes. This is needed as kotlinx.serialization does not rely on reflection, and as such needs to generate code at compile-time to know how a class should be serialized. Lastly, you'll need to add a dependency to the data format encoder, which in this example just so happens to be JSON.

At this point you may try to convert an object into JSON, but unfortunately this will lead to an exception that spoils all your Christmas jolly;

As briefly mentioned earlier this framework does not rely on reflection, and therefore needs to generate some code during compilation in order to work. But, how could the compiler ever know which classes it should support? Creating KSerializers for every class seen in the classpath would make the compile time excruciatingly slow (the hint is in the exception). The @Serializable interface serves as the entrypoint to the serialization process, and instructs the serialization plugin to automatically generate the appropriate KSerializer for the annotated class.

At this point you are ready to convert your object to Json (or Protobuf if you want);

And of course you'll be able to convert the output back into an object;

One caveat to bear in mind is however to what degree your codebase uses java classes, whether they are defined in your codebase or provided by the java runtime environment. This relates to the fact that the framework depends on having access to KSerializer's in order to work, which classes defined in or by java does not provide. And as such if you try to convert a java.util.UUID you'll see a similar exception to the one we got before adding @Serializable to MyFavoriteObject.

To remedy this you must create and register you own serializer;

We've reused the String.serializer() to implement our serializer, we registered the serializer, and then successfully converted a UUID to JSON. Since we were able to reuse String.serializer() the implementation became rather simple, but more complex data structures will undoubtedly require more complex serializers.

So, should you start porting all your apps to kotlinx.serialization? Possibly, if your app is entirely written in Kotlin it will probably work almost right out of the box, and potentially even fix some issues. However, if your app is heavily dependent on java classes it may be better to just stick with what you've got or switch to a library which do more of the heavy lifting for you.

Serialization: New player has joined

Skal alle ansatte være med på å skape noe nytt? Eller er det bedre å overlate slikt til innovasjonseksperter i en egen innovasjonslab? Hvilke modeller er vanlige, og hvilke ulike situasjoner passer hver modell for?

Pia Solheim, Hilde Marie Flesland Torall og Jens Andreas Huseby diskuterer.

Hvordan organiserer man seg best for innovasjon?

Often when we write code we have a clear idea in our minds of how to write the code, but when we actually write it, the compiler steps in and points out a few things for us. In statically-typed programming languages, we can get a lot of help from the compiler. One especially nice feature is compile-time checked exhaustive pattern-matching. As an example, let's look at some Elm code (if Elm is unfamiliar, go check out elm.christmas 😉):

If we try to compile this piece of code, we get this friendly response from the compiler:

This is really nice as a lack of errors from the compiler means that we've handled all cases. Let's quickly fix the error by adding another case:

Now the compiler doesn't complain, so all our cases are covered!

A very nice result of exhaustive pattern-matching is that if we add another variant to the union type (or discriminated union, tagged union, sum type, or any of the many other names it goes by), and haven't covered the new variant, and thus all cases, the code won't compile. For the most part, this is awesome. It makes refactoring code so much simpler as you can just recompile and follow the trail of errors after changing, adding or removing variants of union types. However, you often stumble upon situations where you as the programmer know that a situation can't happen, but the compiler insists that it could. Let's see an example:

Ignoring the nonsensical code above 😅, assume that we know that when displayAges is called, we know that ages is a list with at least one item in it. This assumption doesn't help us, as Elm's List.head function returns a Maybe Int in our case, which will fail to type-check further down. Let's see the compiler-error:

As we can see, an Int is expected, but a Maybe Int is given. The compiler even suggests using Maybe.withDefault to handle the Nothing case. We could do that, or we could case-split the first-value, but we know that ages isn't empty, so there should be a better way, right? This is where we (finally) introduce dependent types!

Dependent types

Dependently-typed programming languages are languages which support types that are dependent on values of types. Well... What does that mean, then? 🤔 An example of a dependent type is a list that is dependent on the value of a natural number, encoding the list's length into its own type. This means we can specify a function that only accepts lists with at least one element. Unfortunately, Elm does not have support for dependent types, and relatively few languages do. Common examples are Agda and Idris. Let's look at some Idris code, which has a similar syntax to Elm:

Above is a declaration of a head-function in Idris, with a function signature similar to Elm's. Idris has function-level pattern matching, like Haskell, so the first line is the function signature, and the two succeeding lines are possible patterns of the input list. Idris also has a dependent list-type called Vect, which takes two type arguments, a value of a natural number and the type of the elements in the list. This means we can define a head-function that can guarantee a list has at least one element and can always return the head of the list. Let's call it head1:

Now, let's break down that code. head1 is the name of the function, then comes the input and output types. Vect (S n) a is the type of the input value, a dependent list-type. S n is the successor of n, where a successor of a number just means the next in-line. S n and n is a natural number, or the type Nat as it is called in Idris. The successor of 0 is 1, so even if n is 0 or something greater, S n will always be at least 1.

Let's take a look at the definition of Nat to see if we better understand how this all works (stolen directly from the source):

A quite simple recursive definition, with only two constructors. A value of 0 is written as the constructor Z, with successive numbers written as S n, where n is a Nat (read more on Peano numbers). Here are some values:

You'll hopefully understand more of how Vect (S n) a now is a vector of at least one in length. But how does the vector implementation know the length? Let's look at the definition (also harvested ripe from the source):

The top line describes that Vect is a type that first accepts the type-parameter len of type Nat, then the element's type Type (a universe-type), and finally returns a new type of type Type describing the actual vector with elements' type. As we see, it also has two constructors, Nil and (::), the list append-constructor. The Nil-case is simple, it has no input and returns a list that is dependent on Z, or 0, meaning an empty list is returned. (::) accepts an element, then another Vectxs that already has len elements, and the constructor finally returns Vect (S len) elem, meaning a list that has one more element than the input xs. This means the compiler can follow the size of vectors as they are constructed:

As the Idris compiler recognizes list sizes, it will disallow function calls such as head1 []. Let's see what the compiler says when we try this:

The output is:

Quite a long output, but essentially it says it expected a String, but found a list, specifically a Vect, of length 0, but expected a list of length S n, or at least 1. val = head1 [ "A value" ] works just fine, as it has at least one element.

Now, all of this might seem a little complicated, and it is, especially when we consider larger programs. However, dependently-typed programs are capable of carrying their own proofs, meaning a successfully compiled program is equivalent of the program being proven correct (look up the Curry-Howard correspondence for some nerdy Christmas-readings 🤓). This does, however, come with a lot of asterisks attached **😅 It requires sufficiently typing your program with strict, narrow and highly-defined types.

There are several other really cool possibilities that dependent types provide us, such as compile-time checked correct usage of protocols, compile-time safety of datastore-usage, numbers bounded within a range, and more. It truly opens a world of possibilities, though it has a steep learning curve. We've only looked at one of the most basic examples.

Side-note: by providing strict dependent types, the compiler is able to reason more clearly about your program. Idris has an Atom-plugin that enables a more interactive form of programming than other languages, and is even able to automatically implement functions for you if the types are descriptive enough. Go and try it with the head1 : Vect (S n) a -> a signature and Ctrl-Alt-G, it's so fun! 🤩

What about other languages?

Is there no hope for these nice things if we use other languages, such as Elm, which doesn't support dependent types? Well, of course there is!

In our example, we've only really created a non-empty list. Some languages already provide support for this specific example, such as Haskell's non-empty list, and others provide other types that provide similar guarantees, such as Rust's non-zero integers.

We could create our own non-zero list in practically any language, but might miss out on some of the ergonomics. Let's see an Elm implementation:

This single-case union ensures that we have at least one instance of the type a, and is such a non-empty list! A clean head-function could be written easily as:

This is becoming a long article, so I would recommend you to go on reading some fantastic reading-material, all linked below, such as Parse, don't validate and Designing with types: Making illegal states unrepresentable. For longer reads, the book Type-Driven Development with Idris by Edwin Brady, the author of Idris, is a fantastically exciting read on dependent types and Idris that anyone fond of strong types would love to read for the Christmas holiday, at least I did last year 🎄🎁🎅

Dependent types and Idris

As a developer, you have surely wondered if the web can do full 3D beyond tweaking the z-index and fiddling with CSS 3D transforms. WebGL is the API for making such fully customizable visualizations in all dimensions. We can use this together with de facto standard framework three.js to unlock this mysterious domain.

Let us make a red christmas cube that reacts to our interaction. All the actual running code can be found in our repository. But don't worry, I will show what it looks like here.

Boil up some boilerplate

The best reason to use three.js is to avoid the obscene amount of boiler plate needed to get something on the screen with WebGL. But, some setup code is still needed.

We start with a renderer that will make the image on the screen:

The screen is of course a web site, and the image will actually be a canvas-element. So we append this to the DOM:

Then we need to make a camera that will represent the view angle and perspective of what we are looking at. Doing that, we need to specify the height-to-width aspect of the screen:

The fov is the field-of-view in degrees. All you gamers out there know that it can be very important!

Then we make a scene, which is going to hold all the stuff to be shown on the screen; like red christmas cubes and other things:

Now we render our empty scene and get a look at the nothingness there:

Making something from nothing

As developers, our joy is to make something from nothing. We are going to add a cube to our scene, and then make it pop. In 3D, things consist of the geometry defining their shape (like polygons!) and the material defining their looks (like textures!).

We make a boxy geometry, sized 1 by 1 by 1 units:

Then we make a red material to slap on it:

These two ingredients are then mixed to make the actual box. It is called a Mesh in three.js:

I promised you that the scene was going to hold all the stuff. And I intend to keep that promise, so we add our fresh box to the scene:

Does it work? Can we see it now?

No!

Why? Because there is no light. The last piece of the boiler plate puzzle. three.js use these as representations of the light sources, and for our example it is absolutely necessary. Let us make a white light that points down slightly slanted on our box:

It is beautiful! Look at those tight corners:

Shake it baby

Now that we have full frontal 3D on the web, we are of course going to animate it, right?

Animations are simply many, many renders in a row. Like a stop motion movie. We wrap our render call in a function that requests to be run again and again as fast as the browser can manage:

We are going to make the cube shake when we click on it. There are many ways to do animation. But a solid tip from me to you is to define a value animationTime that is supposed to go from 0.0 (start of animation) to 1.0 (end of animation):

Now we can use animationTime to calculate the cube shake (brand new sentence!). To rotate something, we simply change the values of the field .rotation. It is a 3 part vector with the object's rotation around the X, Y and Z axis:

We are going to model our shaking on the mathematical sine wave. Because all beautiful things are sine waves, that is an undisputed fact. Sine waves have frequency and amplitude:

And if we use animationTime cleverly, we can start with strong shaking, and then cool down to a chill:

Check out those moves:

Sandbox and final code

You find all the working code in our repository. You can also play around in the sandbox below:

3D with WebGL and three.js 

He couldn't believe it. This certainly couldn't be true. Someone else must have made a mistake here. He read the email a second time. Maybe he missed something and the whole thing was just a big misunderstanding? But he didn't, of course. He is the kind of person who always pays attention to typos, therefore reading it again was quite pointless. Anger started spreading through him. How dare they? It felt so incredibly stupid and unfair. Especially considering he was such a law-abiding citizen. He despised those who didn't follow rules. They couldn't possibly mean that he was one of them? Yet this is exactly what the email was saying: "We can inform you that you unfortunately have used the wrong licence plate in the app, which is why you have been given a fine. In this case the fine is issued on AB12345, while parking was activated for AB1234 in the app.". Filled with rage, he locked his phone and shoved it back into his pocket. He missed one bloody number!

Validation to the Rescue

In Norway, license plates for cars follow a certain pattern: they consist of two letters and five digits (there are some exceptions, such as personal license plates). Considering this, we realize that the above scenario could have been avoided merely by adding some form validation! For this, we will utilize React Hook Form, which has become quite popular over the last year. React Hook Form is easy to use, quite lightweight and very performant. It has built-in validation, but also supports schema-based form validation with other tools such as Yup, Superstruct and Joi.

Let's assume we have this very basic skeleton for a parking app:

The app contains a form with a text input and a button. We also added an onSubmit method that prevents the form from being submitted and the page from being refreshed. Apart from that, the app doesn't really do anything meaningful. Let's add some validation:

As you can see, we don't need to add much code to set up React Hook Form. We have to call the useForm hook which returns a bunch of methods. For the time being, we simply use handleSubmit and register. We then wrap the onFormSubmit method into the handleSubmit method. This will take care of only invoking onFormSubmit and pass the form data when all fields are valid (it also prevents the form from submitting, so we don't need to explicitly call the preventDefault method). Finally, we need to set the register method as the input field's ref attribute. But this is not the end of the story! The form allows any input, even if it is left empty. This is why we have to specify some validation rules:

When registering the input field, we can add several options to adjust how the field should be validated. In the above example, we tell our form that the field is required and that the value must match a specific regex pattern. We also define some error messages. If we try to submit the form, but validation fails, the error message is returned by useForm as an object called errors. Every form field gets its own error message corresponding to the field's name attribute:

Alternatively, we can use a simple component, ErrorMessage (we must first install a separate NPM package):

This is all we need to avoid registering an invalid license number! However, there are some more concepts we should have a look at.

Controlled vs. Uncontrolled

React Hook Form is designed to work best with uncontrolled components. This means that form data is handled by the DOM itself and can be accessed directly using refs (which is why we put the register method there). Controlled components on the other hand, use event handlers such as onChange to update values at state change. Many third-party libraries use controlled components, and luckily there is a way we can use those together with React Hook Form:

We add a React Select for choosing the cars fuel type by wrapping it inside a Controller component using the as prop. The Controller automatically injects the onChange, onBlur and value props into the wrapped component. The same applies to other props that may be required by the underlying component (in this case the props options and isClearable). Validation rules are applied by setting the rules prop. Although this is the preferred syntax, you sometimes need to use the render prop instead of the as prop, which lets you customize events, value and ref:

Form Context

When moving input fields to shared components in order to make them reusable, you can of course pass all neccessary methods from useForm as props. In many cases, it would be a more elegant solution to put the whole form into a FormProvider and access the context of the form with useformContext:

The LicenseNoInput component can then access the form methods as simple as this:

Let's pack it all up, add a little more logic and styling and voilà – we have a parking app with form validation that actually works!

Like a Swiss Army Knife

There is so much more you can do with React Hook Form! It's too bad I can't cover it all in a single article. I can recommend a look at the official documentation, which also provides many useful examples. Personally, I have been using this tool for about a year now and have never been in a situation where it couldn't solve a problem. If you are still not convinced, the fact that TypeScript is fully supported will hopefully change your mind.

9-Dec

Today's posts