Jeg jobbet en gang et sted der utviklerne ikke fikk lov å lage blogg. Da er det stas å nå oppleve at ikke bare én, men to konserndirektører har heiet fra sidelinjen, på at utviklere selvfølgelig kan skrive om teknologi på internett. Å skrive er å tenke. Jeg har tenkt ganske mye på hvorfor denne fagbloggen ble satt opp radikalt minimalistisk, da jeg rigget opp repoet og en hei verden for 2½ år siden. Prinsipp høres strengt ut… Filosofi? Intensjon? Uansett! Til poenget:

• Jotter er en fagblogg for og av fagfolk i Amedia Produkt og Teknologi
• Det er et mål å optimalisere for lav terskel for å skrive 👈
• Bloggpostene ligger åpent på internett, og det er ment som en kikk bak kulissene, en uhøytidelig «sving innom kjøkkenet» for andre fagfolk, ikke et offisielt «besøk i restauranten»
• Folk som skriver her kommuniserer på vegne av seg selv, ikke på vegne av Amedia. Derfor brukes ikke logo, farger, typografi eller andre virkemidler fra profilhåndboken
• Et minimalistisk design, nært nettleser default, er et aktivt valg for å understøtte at dette er fagnerding fra grasrot, uoffisielt med vilje og med all fokus på innhold

Logo? Neitakk!

Amedia fikk ny visuell identitet i fjor. Profilhåndboken har retningslinjer for at konsernet skal kommunisere helhetlig, men det betyr ikke at logo klistres på alle flater vi finner. Om noen fra konsernledelsen deltar i en paneldebatt om mediemangfold, tipper jeg hen ikke stiller der i t-skjorte med Amedia-logo. Det blir annerledes når utviklere holder presentasjon på konferanser, der vil klesplagg med logo fra arbeidsgiver være helt forventet. Bruk av virkemidler fra en profilhåndbok skal alltid vurderes utifra kontekst. Jeg vil ha logo på hettegenser, ikke logo på fagblogg. Det er viktig å sikre en lav terskel for å bidra, at folk som skriver her ikke skriver på vegne av noen andre enn seg selv. Det hjelper i alle fall meg å skrive her.

Markdown fremfor CMS

Det fins mange måter å ordne seg en skriveflate som publiserer tekst på internett. Valget om Markdown handler om minst mulig vedlikehold, og kortest mulig vei for GitHub-brukere å publisere sine bidrag. Det har funket veldig bra for at du nå kan lese:

• flere 🦀 ulike 🦀 bidrag om Rust 🦀
• om matten involvert i å kalkulere sannsynlighet for Nordlys
• varl's nixtapes vol.1 og vol.2 og vol.3
• Cronjobber i Kubernetes
• hva som egentlig er forskjellen på terminal og shell
• eller om Distribuert sporing og ytelse i opptegning av nettsider (for å nevne noen)

Markdown i et repo har ikke vært optimalt for å få bidrag fra andre enn utviklere. Men stay tuned, skal nok få faglige innlegg om for eksempel design og analyse etterhvert også.

Minst mulig kode

Internett har millioner av pene blogger uten innhold. Spesielt utviklere er skikkelig flinke til å bruke mer tid på å kode funksjonalitet til bloggen sin enn å faktisk skrive. Eleventy er en relativt enkel statisk sidegenerator og min favorittmåte å bruke Eleventy er å bruke så lite av det som overhodet mulig. De såkalt minimalistiske starter-prosjektene på 11ty.dev er altfor kompliserte for min smak, jeg har laget mitt eget utgangspunkt der jeg har strippet vekk absolutt alt utover det mest essensielle og sitter igjen med dette: tiny11ty 👌 Se! Her er verdens minste omskriving fra CommonJS to ESM med +3 -2 lines changed i denne commit-en.

• Jo færre features, jo mindre vedlikehold
• Sånn at bidragsytere kan fokusere på å skive

Navnet Jotter

Denne beskrivelsen fra en avis i Skotland var litt morsom:

a note, memorandum, now especially applied to a pupil’s rough exercise book. Jotter was originally very informal, as in the following example from … (1854): “Not book-keeping, only a jotter, only a memorandum”

Jeg skriver dette i en markdown-fil i et repo på Amedia sin GitHub-organisasjon. Repoet er satt opp med automatisk publisering, når jeg merger en PR vil GitHub Workflow automatisk bygge og publisere på GitHub Pages. Dette var den korteste veien til mål, og jeg liker litt at denne teksten ikke kommer på et offisielt domene og heller et amedia.github.io. Fordi lav terskel for å skrive er fint.

Nettlesere har innebygget CSS

Om du er en frontender med svart belte i rammeverk og bibliotek, eller en utvikler som er vant med at andre fikser frontend, så er det fort gjort å ikke være kjent med hvor utrolig mye styling som er innebygget i nettleseren og kommer rett ut av boksen:

• <h2> blir større enn <h3> helt av seg selv
• en <ul> ser ut som en liste uten at jeg gjøre noe som helst
• og dersom jeg ikke begynner ødelegge det innebygde utgangspunktet, så er faktisk layout 100% ekte responsiv til ulike skjermstørrelser, helt automatisk, uten en eneste manuell media query

Det har vært et prinsipp at Jotter har fått minimalt med CSS. Jeg strør på pittelitt for å forbedre lesbarhet, men ellers så lite som det går an å slippe unna med.

God typografi uten fontfiler ⚡️

Jeg begynte kode på et CSS-kurs i 2006, og den gang brukte ingen webfonter. Regelen @font-face eksisterte allerede i spesifikasjonen, men det fantes ikke fontfiler som ble distribuert i et filformat eller med lisenser som gjorde det kurant.

Vi brukte font-family og definerte en stabel med verdier som representerte fontfiler man kunne regne med at var installert på brukernes maskiner. Dette ble omtalt som «web safe fonts» eller «system fonts» fordi operativ systemet hadde installert dem — brukernes nettlesere trengte ikke laste dem ned. Seinere gikk folk bananas med webfonter, men det er en annen historie.

/* Old school web safe fonts fra 20+ år siden */

font-family: `Arial, Helvetica, sans-serif`;

Det er fort gjort å tenke at det der 👆
er omtrent det samme som dette 👇

/* Moderne CSS som refererer til nye system UI fonter */

font-family: system-ui;

Forskjellen er resultatet i nettleseren. Arial er en sliten gammel klassiker fra 1982. Siden den gang har det vært noen tiår med modernisering av skriftdesign for skjerm og optimalisering av fontfiler. Den moderne system-ui er en CSS-verdi som vi nå kan bruke med god støtte siden 2021. Verdien gjør at nettleseren bruker den samme fonten som operativsystemet selv benytter for å vise tekst i sitt UI. Vi får ulik font på MacOS, Linux og Windows — men alle får samme font som i sitt eget operativsystem. Det er dritfett!

The fastest fonts available. No downloading, no layout shifts, no flashes — just instant renders. — github.com/system-fonts/modern-font-stacks

Toppmoderne fonter fra dagens operativsystemer

• MacOS — San Francisco: https://developer.apple.com/fonts/
• Windows — Segoe UI: https://en.wikipedia.org/wiki/Segoe#Segoe_UI
• Linux — Ubuntu: https://design.ubuntu.com/font
• Linux med Gnome — Cantarell: https://cantarell.gnome.org/
• Andriod — Roboto: https://en.wikipedia.org/wiki/Roboto

Det ligger mye arbeid i å designe og utvikle en font av høy kvalitet med god lesbarhet i brukergrensesnitt, og det kommer stadig ny teknologi også her.

En variabel fontfil til å regjere over alle vektene

Variable fonts are an evolution of the OpenType font specification that enables many different variations of a typeface to be incorporated into a single file, rather than having a separate font file for every width, weight, or style. — mdn web docs: variable fonts guide

Dette er kjempekult! Og er noe som vi nå kan bruke med god støtte siden 2018. Det er visstnok ganske komplisert å designe en skrift og utvikle en fontfil som er så fleksibel, derfor er det enn så lenge et mindretall av fonter som tar i bruk denne snasne teknologien.

A new font specification that can significantly reduce font file sizes
— web.dev/articles/variable-fonts

var(--variableFontBold)

Man må ikke høre på metall for å jobbe som utvikler i Amedia. Men det er ikke en musikksjanger man vil være helt alene om å sette pris på i dette utviklingsmiljøet. Det er ingen som har lagt merke til påskeegget jeg har kodet inn i valg av font-weight der alle tall mellom 0 til 1000 kan brukes, så jeg får peke: