Danes will be getting a new drivers license - at some time in the future, as Netcompany has just won a tender for building and managing just that: a drivers license system. Which made me contemplate how such a system would actually be designed.

[ I will use "he" when in fact acknowledging the non-masculine, non-binary he/she/it/they
– but for simplicity restraining from using all, some, intermittently. ]

Abstraction

A legal body [ a driver, case in question ] will a some point in time be required to document a certain set of attested competencies (his ability to command a vehicle).
This requirement presents 2 problems.

Authentication & authorization

Solving both, the driver could (always) travel with the attester or he could 'facetime' the attester when required to document and hand the phone to the requesting body. This would redirect the authorization (and authentication) to the attester, and not further the case!

Digital sovereignty

Under EU 2016/679 any system to control and/or process personal data is required to be designed for privacy - with the legislative intent being sovereignty as a matter of fact.

Some licenses are more sensitive than others. A license to operate (read 00- like in 007) within the borders of another country will be rather sensitive. A drivers license lesser so but still quite sensitive depending upon the driver's demonstrated abilities - ie if he manages to compile a long list of "likes" the license will possibly be quite sensitive at least in other situations: applying for a job as a chauffeur eg.

Autonomy

So far I am pretty sure you have considered legal bodies to be biological ones only! An extremely edge case as of writing, I concede, would be one in which an autonomous vehicle (AV) gets "pulled over" by another AV.

The example most likely will be reality – albeit in an unforeseeable future, but suffice to say a requirement for automaticity is obvious.

Design

Authentication

The legal body (autonomous entities no doubt will become legal bodies, eventually) should present something he knows, something he has, and something he is – and at least 2 of the 3 artifacts should be 'on record'.

1. the "knows" part could be a pin code, one that makes sense to the body in question, like a date, height, or other set of digits,
2. the "has" thing could be a public/private key – when asked to encrypt a given word the result can be diff'ed and hence validated,
3. finally the "is" issue could be biometric (robots could offer their MAC address of sorts),
4. and adding a one-time-password SMS/Text sent on request would further increase confidence in the authenticity of the legal body

Why not use MitID (current authentication solution currently deployed by danish public offices and private enterprises alike)? One word: automation
The sketched solution can be automated and kept on one device, and integrated with other apps.

Frontend
Users could download an app with the authentication process being the main feature (or the authentication process could be integrated into other apps like fx a driver's license app). The pin-code will open the app (and send a request for the one-time-password) and allow the user to process the encryption of a data package provided by the requesting body (to accomplish item 2), further allowing the user to present either fingerprint or face to camera (accomplish item 3), and finally once the SMS arrives, the user will have a QR code to present to either a robot or another legal body to scan.

Backend
Each user will have his own event journal/witnessed ledger and safe keep his data 'on device'. Public systems will keep whatever data points they require in a similar construct. The essentiel (core) table will hold the user's pigeon, public key and the phone number to forward one-time-passwords to (the system should have a semi-self-service system allowing users to switch phone number when necessary), and possibly autonomous system's MAC address. Initial authentication could/should be required to perform at municipal or notary offices.

In countries that keep a uniq ID on each citizen (in Denmark it is labeled CPR) any attempts to keeping this ID with the authentication core table should be avoided at all costs as this ID probably is spread across a huge number of systems and thus will be violating the user privacy severely!

At initial authentication at a municipal office, presenting the officer with the ID would be acceptable but persisting the ID with the authentication not!

Authorization

Demonstrating attested competencies is easily added to this 'app' as a "plugin" and adding a plugin for a driver license is no different.

Frontend
Any user of a smartphone could download a "driver license reader" and should be able to read the token of a driver license, and to submit a "traffic incident ticket" with his personal (and geo location) information attached, possibly some attachments like audio/video too.

Any further reading/writing below will follow this (happy path) workflow:

1. requesting body will submit a request attaching the (pigeon) token - WD1CKM4NN
2. the user with the token receives a notification requesting his accept
3. the user accepts the action/request
4. the requesting body receives the information

In some use cases (like if the user does not accept the action/request) the requesting body will have to elevate the request to a police office, and if not solved with the police as requester, elevate the request to the legal system - and eventually the user will lose his license.

Insurance companies should be able to read attested competencies as well as registered "likes" when submitting a token. They should be able to write insurance information.

Attesters should be able to read token and address information, and write competencies attested, and his token.

Police offices should be able to read and write all information.

Judicial offices should be able to read and write all information.

Backend
The core table holds the license number and the token attached to it, and the competencies attested, when and where attestation was given, and a token of the attester. A supporting (like) table holds the token of the user and a token of the body offering the "like", when it was inserted and any consequences, possibly a time range for deactivation of the license, more. A further supporting table holds the token of the user, a vehicle ID, a token of the insurance company, and the time range where the insurance is valid, and insurance specifics.

Infrastructure and budget

What amount of infrastructure are we looking at?
Building on Erlang/Elixir for a 'telecommunications kind of app' (I am aware that the initial use cases does not prescribe any tele communications per se, but a number of use cases down the road may prove it to be a fitting decision) will allow for upwards of 2mio connections per server, which when considering the danish scope, would ask for 3-4 servers – if all danish citizens were to be 'online' at the same time.

What budget will that ask for?
Building out the infrastructure in 2-3 small clusters located in the north, the south, and the east, with a primary and a secondary/fallback server will set the budget to a mere 3-400.000/yr on hosting and maintenance.

Using Phoenix with Erlang/Elixir will afford a single source stack building backend and frontend in one project with extremely high availability and modest requirements on deployment. The client application could easily be deployed as a progressive web application.

Developing/building the 2 applications (authentication & authorization) and the driver license plugin could be a 2-3man task for 6-12months and see costs top at 3.000.000DKK, and probably in the 250-400.000/yr for continues development.

With the core implementation down we can turn our attention to the business side of things: the organizational considerations and the business model

Organizational considerations

Affording a possibly global tracking of asset ownership will have to address issues like audit trail, accountability, verification, division of labor, antitrust

Audit trail

The NUG will have to afford an audit trail to introspect transactions. This tool probably will have to be a paid service in order to reduce the number of users wanting to 'follow the money' but idealistically anyone with a terminal and enough time on their hands should be able to 'walk the audit trail' all the way back to the very first transaction!

Accountability

Underwriters are the cornerstone within the NUG. They will have to be trusted with the right to declare assets, update assets, and retire them eventually. Constructs will have to be installed in order to secure their accountability. Underwriters will be able to "create wealth" and thus should be accessed thoroughly, and repeatedly!

Verification

One way of accessing underwriters will require auditing their modus operandi - how they do business. How do they verify the existence of users assets!?
In order to make good on threats of banning users that do not play nice but sells assets they do not have, try to lure assets from other users, etc, it will be necessary to identify every user beyond any doubt! Whether be it by some combination of biometrics, or otherwise.

Division of Labor

The way the Domain Name System is run could be the way to go! Delegating responsibility for supervising, controlling, validating, and verifying underwriters to national bodies will create a hierarchical structure

Antitrust

The NUG will protect itself from antitrust by being non-profit and allowing everyone access to its books.

Business model

The underwriters will be able to sell one basic service: controlling an asset, but the underwriters will eventually be able to do a lot more;

• issue loans
• issue insurances
• offer escrows
• etc

Services will be cheap (as it is really just software) but some customers will warrant personal service, better coverage, better security, faster services, etc.

Banks and other financial institutions are the obvious candidates to try to take control of this market, and with the trust invested in them by customers today, they probably will seize quite a large part of this market.

- så "smukt" formulerer en AI (ansat hos Google) digital suverænitet; pænt dækkende skulle jeg mene, men samtidig også 100% varm luft; så jeg tænker her at (prøve) at lukke luften ud, og se om det er muligt at materialisere det floromvundne.

IP - Indflydelses Perimeter

Grænsen for, hvilke data og hvormeget, jeg kan kontrollere dem, er på samme tid både flyttet tættere på, og rykket længere væk! Før kommunereformen i 1970 kunne alle danskere går til deres sognerådsformand og "bede om godt vejr" = blive "lignet" lempeligt i skat. Der er mange grunde til at staten gerne så ligningssystemet centraliseret, men mindst én af grundene var, at nærhedsprincippet var voldsomt udfordret af de personlige relationer – så har jeg vist ikke sagt for meget 😎
På det punkt er grænsen rykket super tæt på mig; i dag kan jeg næsten nøjes med at skrive under (digitalt) og så er den selvangivelse afleveret. Da jeg startede med at programmere, var grænsen for, hvad jeg kunne kontrollere, nærmest på lårene af mig. I dag kan jeg teoretisk set kontrollere data uanset hvor i verden de måtte befinde sig, fysisk.

Samtidig var jeg i dag nødt til at forklare en kunde, at deres ønske om at sende billeder, direkte fra produktionen, med deres iPhone/iPad, til leverandører rundt om i verden, via email og iMessage, var lidt rigeligt ambitiøst, især når et voksende antal virksomheder helt ureflekteret brutalt flår alle vedhæftninger af emails, og fascistoide IT driftsansvarlige fra deres MDM værktøj (jeg vil gætte på at en række produkter af samme kategori og funtionalitet, må kategoriseres under "utællelige" – men spørg hellere Sophie Egede-Schrøder) arm- og benamputerer kollegaers forsøg på at finde en work-life balance midt i bleskift, kundesupport, og personlig udvikling.

Infrastrukturen har det altså vanskeligt - og det mærkes, når man som jeg gik fra at kaste en aldrende MB 200D hårdt rundt i svingene i Odense i et tidligere årtusinde, i et forsøg på at aflevere et brev (indeholdende min selvangivelse) personligt på skattekontorets parkeringsplads på fristnatten lidt i 23:59, til i starten af det friske årtusinde, uden væsentlige svedskjolder at kunne rykke store dele af M$'s dokumentationsbibliotek ned fra hylden i Seattle (ganske vist over en nat, men alligevel). Hastigheden fejler med gigabit fiberforbindelser her i 2025 intet, men i konkurrencen med de over 50% af den samlede IP trafik, som enten er af NSFW karakter, andet video/underholdningsindhold eller direkte har ilde hensigter, er min suverænitet begrænset til mit eget hjem (og det er i bedste fald).

Hvorvidt jeg kan kontrollere infrastrukturen og indirekte de anvendte teknologier i mit eget hjem kan der være delte meninger om. Spørger du min hustru vil svaret næppe imponere. Uanset evner og ambitioner, er situationen imidlertid den, at jeg er i færd med at "migrere" fra et 25 år gammelt, kuldsejlet, IHC projekt som aldrig rigtig fik flyvehøjde – til i dag med ZigBee, WiFi6 (802.11ax), Home Assistant, og produkter fra bla IKEA, faktisk at kunne realisere drømmen om at tænde lyset hele vejen ud på toilettet om natten – automatisk, forstås 😅

Mine data tager nogle gevaldige tæv, dagligt. Mit iWatch afleverer mit blodtryk, hjerterytme, og alt muligt andet, til hvem ved hvilken "harddisk", i en ikke nærmere angivet region af - ja, gad vide hvor, men sikkert ikke (kun) de 45.000kvm i Foulum ved Viborg. Dertil naturligvis rå mængder af målepunkter fra min gøren og laden på LinkedIn, krydset, Fjæsen, Insta, foruden Discord, Slack, og så har jeg sikkert glemt et par stykker. Min holdning er at hvis nu jeg sammen med 1-200mio andre ivrige brugere går 110% balalejka, så drukner vi big-tech'erne i deres egne datasøer – så kan de lære det! Da jeg var barn, handlede det om at sidde i bestyrelsen for frysehuset, den lokale brugs, borgerforeningen, og ellers huske at møde op, når der blev inviteret til kaffeslapperas rundt i de kropsdampfugtige utætte æ pæn' stouw, langs landevejen fra stationsbyen til havet – for her var SoMe gerne forsamlet 3-4 gange i løbet af ugen, samt naturligvis før under og efter indkøb hos købmanden, og kirkegangen ikke at forglemme. Jeg kunne trygt lade stearinlysene brænde, hver tirsdag, når jeg kørte til spejder - alle vidste, hvor jeg var og hvis noget brændte, vidste de også, hvor de fik fat på mig. Nu ved Mark Zuckerberg og et par af hans håndgangne mænd(-inder) det også - og det er måske lige så meget i kontrol, som før.

Når jeg, sammen med min grandfætter, i en alt for tidlig alder købte cigaretter hos købmanden, fik jeg en formaning med; den stod ikke på pakken, men kom fra købmanden selv, der pulsende på en Manne, lige skulle høre, om jeg ikke troede at det var bedre at lade være – og jeg kunne være helt sikker på, at alle der skulle, eller burde vide, hvad jeg havde været i gang med, var velinformeret, næsten før jeg var hjemme igen! Sognerådet (og dermed store dele af sognet) kendte min privatøkonomi, måske bedre end jeg selv, og Lækre Lotte, der ikke var karrig med ret meget, var det heller ikke med at dele mine "tilbøjeligheder" hos frisøren. Nu deler vi selv materialet i vore feeds – same but different.

Så når jeg spekulerer over, hvad min digitale skæbne er, hvad mit lod er, må det nok først og fremmest være, en erkendelse af ikke at være i kontrol og handle derefter. Når jeg kender hensigten med at overdænge mit tiltagende konsum af korte video stumper med stadig vildere tryllekunster, forvandlinger af skrotbunker til mageløse boliger, opfindelser der dagligt frelser verden 11 gange, horder af nyudsprungne sangere og performere den ene dygtigere end den forrige, velkrydret med sponsorerede indslag med alt fra gardinopstrammere til elbiler, fikse plastikindretninger jeg ikke kan lave mad uden, og ikke mindst, et svimlende antal digitale løsninger, der med 3 hurtige klik med musen laver mit regnskab, redder min rapportering af mit overforbrug af el, vand, plastik, varme, kaffe, alt - så kan jeg handle derefter, og trygt hælde en frisk portion HavreFras blandet med Guldkorn op, spæde den grundigt op med dark Cocio og Tvis' sødmælk, for "de" har altid gerne måttet snage i mine "data", sålænge jeg selv får lov at føde dem; mine data er ren og forjættende open source – have a swing at it!

Jeg ville ønske at jeg kunne tage æren for at have møntet udtrykket – men det kan jeg ikke. Om det er Andrej Karpathy ved jeg ikke, men i den her youtube bruger han det i det mindste overordentligt effektivt!

Hvorfor er (endnu) en versionering af et begreb relevant? Jeg skal prøve at gengive en af videoens centrale indsigter:

Andrej deler den indsigt at software i starten var instruktioner, der kunne styre en computer, som så til gengæld fx kunne anvise den korrekte bane for et objekt, hvis man ønskede at dette objekt ramte et andet. Det kalder Andrej software 1.0. Det var den måde, hvorpå vi var i stand til at interagere med en computer – i stand til at få computeren til at udføre "arbejde" for os.

Software 2.0 er, for ham, ikke længere instruktioner, men ( kæmpe datasæt af matricer af) vægte [ værdier mellem 0 og 1 ], der kan "styre" et neuralt netværk til at udføre det samme arbejde, som ovenfor under software 1.0. Vores interaktion med computeren har flyttet sig milevidt fra de første simple instruktioner, og hvor vi tidligere måtte "føde" computeren med stakke af papkort og senere diske igennem særligt indrettede indlæsningsveje, lærer computeren nu vores hensigt ad mere menneskelignende indlæsningsveje; mikrofon og kamera.

Med software 3.0 har vi nået et abstraktionsniveau i vores interaktion med computere, hvor vi ikke længere (nødvendigvis) skal fortælle computeren, hvordan vi ønsker at den skal opføre sig (for at sikre at et objekt fx rammer et andet – det kunne være en bil i en rundkørsel), men hvad vi ønsker at opnå; at ramme den tredje udkørsel fra rundkørslen! Vores dialog med computeren har nået et abstraktionsniveau, hvor det (indtil videre i helt afgrænsede og klart definerede domæner) lige så godt kunne være en [menneske]kollega, vi taler med.

Konsekvens/perspektiv

Der er vidtrækkende perspektiver i denne indsigt. Her er blot 3 af de mest umiddelbare:

Tilpasning af software
Det vil ikke være relevant at tale om "standard software" eller om kunde tilpasninger til standard løsninger! Al software vil være standard, fordi brugeren igennem sin interaktion definerer løsningen. Læs eventuelt sætningen én gang til 😉 og tænk så på de mange situationer, hvor det vil ændre din hverdag -

• "bogfør fakturaen på kortfristet gæld, åbne kreditor poster, indgående moms, varekøb, og øg beholdningen af antal på lager for hvert produkt nævnt på fakturaen, og mærk linje 1 og 2 som bestilt til ordre. Gør det for alle de fakturaer vi får. Giv mig en notifikation, når det er gjort, så jeg kan godkende arbejdet."
  Det vil givetvis afføde en mindre byge af spørgsmål/forslag fra agenten, men når de er afklaret, og begreber som "kortfristet gæld" og "indgående moms" er indlært – så vil der ikke være brug for kontering længere. Det "arbejde" skal kun gøres én gang, og så kan alle nyde godt af det!
• "præsentér dig som kontorets receptionist, og spørg hvad henvendelsen drejer sig om. Du kan viderestille alle henvendelser til John, medmindre det drejer sig om de her emner. Salg skal du viderestille til Jane. Reklamationer skal du viderestille til Erik. I næste uge har vi efterårsferie og der beder du om at man enten ringer igen eller sender en email. Er opkaldet fra en agent som dig selv, må du gerne stille om til MCP."
  Digitale omstillingsborde (såkaldte PBX eller Private Branch Exchange) har været vældigt populære, ikke mindst siden hovedparten af al telekommunikation (læs: telefonsamtaler) er blevet flyttet over på VoIP (Voice over IP), men deres anvendelse og optimale udnyttelse har været voldsomt hindret af vanskelige brugergrænseflader; det vil være historie lige om lidt!
• "Lær reglerne om værdiansættelse af ejendomme i den vedhæftede tekst, og gennemse derefter de domme, der i de seneste 10 år har været, hvor søgsmålet har været relateret til uenighed om korrektheden og rimeligheden af den tilmålte værdiansættelse. Foretag derefter en værdiansættelse af alle ejendomme i Danmark. Først for den enkelte matrikel, brug derefter værdien for matriklen til at udregne et gennemsnit for alle matrikler på hver vej, brug derefter disse gennemsnit til at udregne et gennemsnit for alle veje i hvert kvartér. Send mig en notifikation når du er færdig"
  Sådan bruger man 4 milliarder 😎 Jeg er helt på det rene med, at agenten ikke er gratis, og at systemet Danmark bruger i dag, ikke kun udregner en værdi, men samtidig støtter de ansatte i dialogen med ejerne/"kunderne" – mæææn

Gentrificering
Adgangen til vand er afgørende for en bonde i Afrika. En brønd - uanset at han deler den med mange andre - gør det muligt for ham at være en bedre bonde, dyrke flere afgrøder, få bedre råd, og endelig øge hele områdets værdi og lokke flere/andre mere velstående til området. Præcis den samme udvikling sås igennem de seneste 40-50 år i hele området syd for San Francisco, i dag omtales det som Silicon Valley.

Konsekvensen er øgede indkomster, højere priser på ejendom og varer, og højere skatter, et rigere samfund med bedre råd til at hjælpe de, der ikke kan selv.

Økonomisk 'revolution'
Det sidste perspektiv er af en lidt mere spekulativ karakter, omend hverken urealistisk eller særligt originalt – men stadig; spekulativt!
Den herskende økonomiske model, som har bevist sig værd igennem alle slags prøvelser, siden Adam Smith's usynlige hånd, baserer sig på udbud og efterspørgsel. Ifølge den vil udbuddet rette sig efter efterspørgslen og vil man ændre på det, må man ændre efterspørgslen. De seneste årtier har illustreret, hvordan evnen til at forme efterspørgslen, har drevet udbuddet af alt fra surdej til "plastiske forbedringer af legemsdele".
I hver fase af markedsøkonomiens udvikling, har det været en knap ressource, der har haft betydning for, hvordan og hvilke konkurrenter i et marked, der er lykkedes. De klassiske 3 M'er – Materialer, Mandkraft, og Moneter. For 30-40 år siden begyndte verden at flytte fremstillingsprocessen til Kina/Østen - fordi der var adgangen til 2 af de 3 m'er billigst (sikkert velvilligt hjulpet af det kinesiske kommunistparti, der givetvis spillede det lange spil).
Med automatiseringer og built-to-order af alt fra middagsretter til raketmotorer, fjernes Østens konkurrencefordel på i det mindste det ene 'm' – og en række faktorer vil sikkert fjerne det andet 'm' også (økologi, jord-til-bord, miljøhensyn, social ansvarlighed, cirkulær økonomi, mm).
Bevæger samfundet sig tilbage mod et "håndværksbaseret" punkt, hvor masseproduktionen ikke kan konkurrere. Vil individdets tidsalder skabe fundamentet under en ny økonomisk revolution, hvor din indsats måske stadig er afgørende for, hvor "velstående" du er, men ikke for din deltagelse i samfundet eller din overlevelse. Vi er i dag langt tættere på at kunne realisere drømmen om Universal Basic Income end på noget tidligere tidspunkt, men måske er vi også nødt til det på grund af den koncentration af magt, velstand, og indflydelse som vi har været vidne til de seneste 10-15 år?!

Udnyttelsen af software 3.0 – denne "nye" (industrielle) revolution – har så mange konsekvenser for det danske samfund (alle samfund i verden, i realiteten) at det ikke er muligt at sammenfatte dem, men forestil dig rent afslutningsvis, at du stod i James Watt's garage i midten af 1700-tallet og betragtede hans arbejde med dampmaskinen! Du havde med garanti ikke kunnet forestille dig, hvad det i løbet af ganske få årtier fik af betydning for samfundet.

Den aktuelle dialog om digital suverænitet tog vel strengt taget en drejning af nærmest bibelske dimensioner, her til morgen - da jeg åbnede min indbakke kunne jeg nemlig læse: MitID er afhængig af USAs tech-giganter. I mit hoved blev det til at vi har valgt den forkerte tro.

TL;DR; der er behov for en åben kilde løsning til integration af 2 systemer (maskin-til-maskin) hvor godkendelse er et krav.

Tillid er en altoverskyggende kvalitet, i et samfund, såvel som i en økonomisk transaktion mellem 2 parter, eller derhjemme i ægteskabet (eller hvilket forhold I nu lever under). IRL (nydansk for i virkeligheden) bruger du din "mavefornemmelse", når du står og overvejer, om den her kebab nu også er "frisk" – der er mange overvejelser som vejer ind: sult, tidspunkt på døgnet, alternativer, mm. Denne 'fornemmelse' styrkes i mange sammenhænge af biometriske artifakter, her især 2: øjenkontakten og håndtrykket. Digitalt har du meget mindre at arbejde med. Du kan (og det er blevet så meget mere relevant de seneste år, desværre) browse sælger for at se om der skulle være spor som peger på, at det er et scam; et forsøg på en erstatning for øjenkontakten. Du forlader dig på de forsikringer, som udstyret kommer med, efter at have indledt dialogen med et hand-shake; en digital version af håndtrykket, hvor sælgers maskine og din enes om 2 ting, at begge er den, de udgiver sig for at være, og hvilken protokol dialogen skal følge (en slags aftale om hvilket sprog, der skal tales).

MitID er det seneste bud på, hvor danskere skal håndtere etableringen af dette krav/behov for tillid, digitalt. Vi taler her om essensen af kritisk infrastruktur, der er afhængig af app-stores (der hvor app'en kan hentes og installeres fra). Det er imidlertid ikke den eneste infrastruktur, som dette værktøj er afhængig af. Driften og udviklingen ligger i hænderne på en fransk virksomhed. Transporten af data sker på udstyr, der for en stor dels vedkommende er produceret i Kina (hvad er efterhånden ikke det?), med protokoller og styremekanismer, der på øjeblikke kan dirigere al trafik omkring eksempelvis NSA, og som drives af et par håndfulde virksomheder, her især TDC (ejet af en australsk kapitalfond), Telia/Telenor/Norlys (stærke indbyrdes kapitalinteresser, men Norlys er ejet af 800.000 el-kunder - et andelsselskab), og 3 (overvejende HongKong baseret konglomerat).

I den 'suppe' virker det lidt Ulven kommer agtig at skyde "skylden" på Apple og Google!?

Har vi teknologien og "kræfterne" til at sikre en reel digital suverænitet på dette punkt? Både ja og nej.

Ja; fordi etableringen af et statsligt ejet teleselskab er lykkedes én gang tidligere - i slutningen af 1800-tallet, fordi vi har stærke kræfter indenfor udviklingen af optisk transmission af data, fordi landets topografi tillader etablering af "luftbåren" kommunikation relativt omkostningsnådigt, og fordi vi har et højt niveau indenfor forskningen i, og anvendelsen af kryptografi.

Nej; fordi Danmark er en del af EU og derfor "tvunget" til at gennemføre en række EU direktiver og her således eksempelvis eIDAS (910/2014) og det vil derfor være kontraproduktivt at udvikle et særskilt dansk værktøj, og MitID er efter Digitaliseringsstyrelsens udsagn således allerede i stand til at servicere borgere fra andre landes behov for at identificere sig med deres tilsvarende eID. EU har i øvrigt udgivet 2 glimrende PDF'er, som i meget overskuelige illustrationer giver dig et hurtigt overblik over hvordan du kommer igang, og hvilke værktøjer der potentielt ligger i værktøjskassen.

Men plejer du ikke at bjæffe 'open source' ved enhver lejlighed? Det har denne post ikke meget af?!

MitID kan man mene meget om – og det skal man helt sikkert også, men bortset fra et helt åbenlyst behov for en dyb integration til brugerens fortrukne browser, fungerer værktøjet efter hensigten; til konsumenter. Der findes danske MitID-brokere (som kan tilbyde at løfte en del af opgaven med at integrere løsninger med behovet for authentication [godkendelse af at du er den du siger du er]). Maskine-til-maskine er en noget andet størrelse.

Og her kommer så et par bjæf! For agentic behaviour (opførsel på dine vegne) vil uden al tvivl komme til at fylde for såvel private virksomheder som offentlige ditto, og med rette, for arbejdet med at udveksle data mellem systemer, baseret på at en medarbejder skal sidde og håndstyre det, er svær at forestille sig i 2025. IT industriens seneste forsøg på at finde et fælles fodslaw omkring udveksling af data har udmøntet sig i MCP (ja, branchen er om nogen tynget af et overdrevent brug af TLA's [Three Letter Acronyms] 😎), der lover at give AI (agenter) adgang til at bruge/fjernstyre et system og data – og i den kontekst vil MitID i øjeblikket være en kæp i hjulet (jeg underholder gerne med, hvordan en jysk bank har løst opgaven).

Så, i min kikkert er der et tydeligt behov for at Digitaliseringsstyrelsen udbyder en opgave, der kunne hedde: Fremstilling af en åben kilde løsning til integration af 2 systemer (maskin-til-maskin) hvor godkendelse, der overholder 910/2014, og mere snævert, MitID (eller dennes kommende afløser), er et krav. Så er det op til markedskræfterne at konkurrere om at levere den bedste og billigste drift.

Ordet udnytte er måske den første fodfejl! Måske skal vi slet ikke udnytte open source, men snarere anerkende modellen under/bagved og værdien af den og derefter deltage i communities bag de open source produkter, vi gerne vil bruge. Så i stedet for at betale en leverandør for at udvikle en løsning til vores specifikke organisation eller virksomhed, kan vi betale den samme leverandør det samme beløb, for at udvikle en løsning til "alle" 😲

Den holdning skal jeg nok blive populær på! 😎

Udviklingsmodellen bør dog ikke fortjene så meget modvind, som jeg forventer. Fordi:

1. først skal domænet og scope't klarlægges. De traditionelle workshops og foranalyser skal afholdes og et system skal designes.
2. dernæst kommer et exploratorisk trin som (måske / måske ikke) findes og eller allerede benyttes i dag. Her kortlægges systemets mulige open source komponenter. Hvilke der allerede findes. Hvilke nye systemet potentielt indeholder, og endelig hvilke komponenter, der er så specifikke, at de skal "tilpasses" til den konkrete brugergruppe. At det findes ved jeg – men det er muligvis ikke "slutkunde" transparent 😉
3. dernæst allokeres ressourcer i en forholdsmæssig størrelse, til de valgte open source komponenters udvikling og vedligeholdelse.
4. sideløbende udvikles de nye komponenter, open source såvel som closed source. For at understøtte anvendelsen af open source bedst muligt, sikres det under reviews og revisioner at opdatering af åbne lister over eksisterende og anvendte open source komponenter bliver foretaget.
5. endelig samles alle komponenterne og løsningen overgår til en driftsmodel

Der er ikke anvendt færre ressourcer, snarere tværtom! System/integrations leverandøren har altså ikke (endnu) mistet nogen omsætning, men fået solgt det samme eller flere konsulent timer.

Nu bemærkede jeg parentetisk - endnu - ovenfor, fordi det må forventes at AI støtte kommer til at gøre et endog meget mærkbart indhug i det mindste i pkt 2-4, men det er en trend som ikke skyldes open source! Open source vil muligvis speed'e transformationen op, men den vil ikke isoleret set være skyld i de fleste ændringer!

Der ligger ihvertfald én altoverskyggende hindring for at alle vil kunne acceptere denne model:

når du går til en SKODA forhandler, må du indstille dig på, at de (sjældent) sælger dig en Renault!

Det betyder at forudsætningen for at tage hul på et nyt mindset omkring integration og udvikling af IT løsninger fordrer

1. at køber vælger en leverandør, der har tilkendegivet at ville arbejde på de nævnte vilkår og efter udviklingsmodellen
2. at IT branchen eller muligvis et uafhængigt organ udarbejder og vedligeholder en oversigt over system leverandører og deres performance – en slags AirBnB for IT projekter
3. at bestyrelser i såvel offentlig som også meget gerne i privat regi driver denne omstilling, kommunikeret i deres forventninger til direktioner og ledelser – med den motivation, at de (for the greater good) tjener aktionærernes interesser bedst ad den vej!

Debatten om open source demonstrerer hvor værdiladet et begreb, der er tale om. Her er et par vinkler på, hvorfor det er et meget værdiladet begreb:

buzzword

Open source er ikke noget nyt og spændende, som f.eks AI. Når det alligevel bliver et buzzword skyldes det markedspotentialet. Det er ikke særskilt for open source, mere et grundvilkår. I modsætning til begreber som GDPR, NIS2, AI, CO2, og mange flere, er markedspotentialet imidlertid ikke en konsekvens af brugen af begrebet i en målrettet markedsføring, i første "bølge". Potentialet ligger i de strukturelle konsekvenser, som et øget fokus og interesse for open source har. Jeg fristes til at sige pull i stedet for push.

Uanset – som buzzword får begrebet med den øgede fokus, også værdi for de virksomheder, der gerne vil "hægte sig på"; lidt i stil med da rap kulturen blev mainstream og alle artister skulle "tale" ind over deres numre. Det er den "anden bølge", den traditionelle målrettede markedsføring af systemer med et særligt sæt af funktionalitet, til en konkret brugergruppe, nu blot påklæbet etiketten "open source", eller ingen er nogensinde blevet fyret for at vælge IBM.

Open source fortolket som

free as in beer...

Mange, måske reelt set de fleste, går skævt af begrebet open source og kommer nemt til at lægge noget deri, som det slet ikke kan levere på. I udgangspunktet er det software kildekode, der er tilgængelig, så du kan læse den, forstå den, afteste den, og for den sags skyld reproducere den. Begrebet open source siger intet om i hvilket omfang, du må udnytte det, dvs enten i privat/hobby regi eller for profit. Det er strengt taget blot en "etiket". Et eksempel er Google Chrome (browseren rigtig mange bruger på Internettet). Den er ikke open source, men gratis at hente. Det betegnes freeware. Det er der vittige hoveder som har benævnt free as in beer – altså gratis øl. Du kan drikke det, men du får ikke opskriften på det.

Hvad er værdien af freeware? Hvem kan have en interesse i at udvikle meget avancerede programmer, for derefter at forære dem bort? Tidligere var der 2 grupper

• hackere som skulle bruge en vej ind på din computer
• afprøvning af ny teknologi, hvor producenten, mod at du bruger det gratis, får lov at indsamle data om brugen

De fleste er nok klar over at gruppe 2 i dag har fået en altoverskyggende "undergruppe", hvor det er dig, som bruger, der reelt er producenten af indholdet til programmet, og at programmets succes afhænger af at flest mulige "producerer" indhold. Gevinsten ligger i at udnytte "programfladen" til at sende reklamer med, eller udnytte dine vaner og præferencer, når du bruger programmet, til at udregne, hvilke andre produkter og tjenester, du ville kunne finde på at købe, og derefter målrette markedsføring mod dig, for dem.

free as in speech...

I modsætning til det står "ægte" open source, der typisk følges af et tekstdokument med navnet LICENSE, hvor du som læser bliver gjort opmærksom på, under hvilke betingelser, du må benytte kildekoden. Ofte anvendes GPL (General Public License) og den type software betegnes også mere specifikt som free software – fordi du må gøre med den hvad du lyster.

Chrome i eksemplet før, er baseret på et open source project, Chromium, som følges af en BSD-3 licens, som fastslår at du kan bruge kildekoden, blot du

• husker at vedlægge copyright betegnelsen (typisk én linje der siger hvem der er forfatter til kildekoden) hvis du distribuerer kildekoden
• husker at gøre opmærksom på copyright (igen, hvem forfatteren er) hvis du distribuerer eksekverbart, dvs programmer, du kan starte
• ikke bruger forfatterens navn/mærke til at markedsføre dit eget produkt

Hvor er værdien?

Hvad er værdien af open source? Skriver du en tekst og eller en melodi blot for at give den væk? Hugger en skulptur, anlægger en have, pudser naboens vinduer?

I modsætning til skulpturen, haven og vinduerne, har du ikke "mistet" noget. Du har ganske vist brugt noget tid, men hvis det var tid, du var indstillet på at bruge i alle tilfælde – måske fordi du skulle bruge funktionen eller programmet selv – så er din grænseomkostning (omkostningerne ved at "producere" én mere magen til) uendeligt lille, hvis ikke nul. Så du har ikke mistet noget.

Så, det at du åbner et produkt og giver andre indsigt og adgang, risikerer du ikke noget ved, men har potentielt muligheden for at få et bedre produkt ved, hvis de, der vælger at bruge produktet, giver feedback, ændringsforslag, påpeger fejl og sikkerhedsbrist. Værdien i open source er returløbet.

Der er en udbredt forestilling om at hvis noget er gratis, er det ikke noget værd. I rigtig mange sammenhænge er det rigtigt (Trabant var et eksempel på, at du ganske enkelt ikke kan bygge en bil af øldåser), og isoleret set gælder det også software, men fordi (som jeg nævnte ovenfor) grænseomkostningen ved at fremstille én kopi mere af et program – i modsætning til at fremstille én bil mere – nærmest er nul, opstår nogle meget "mærkelige" markedsmekanismer, ganske vist ceteris paribus (alt andet lige)!

For, hvis omkostningen er nul, mister virksomheden ikke noget ved at lade endnu en bruger benytte kode, virksomheden allerede er blevet betalt for at skrive. Læs lige sætningen igen, og fokusér på ordene "allerede er blevet betalt for" – den kommer vi tilbage til!

Hvis nytteværdien for den enkelte bruger er konstant, er værdien af "koden" lig med summen af brugeres nytteværdi, og hvis grænseomkostningen er nul, vil overskuddet stige eksponentielt med hver ny bruger – eller sådan var mantraet i det mindste i starten af årtusindet, og en del af forklaringen på, hvorfor Internet virksomheder blev solgt til astronomiske beløb; deres værdiansættelse var baseret på den driftsøkonomiske kalkulation! Dertil kunne lægges den indirekte omsætning som en række af disse virksomheder "så" som en slags flødeskum på kagen: brugerens brug af tjenesten kunne gøres til genstand for monetization (brugernes brug = transaktionsdata = et produkt i sig selv = salgbar).

Ceteris paribus er, som du måske kan forestille dig, en noget illusorisk situation; for der er et hav af andre variable, som har indflydelse på prisdannelsen – heriblandt det åbenlyse behov for infrastruktur! Internet båndbredde, processorkraft og datalagerplads i særdeleshed. Så, måske er koden "gratis" for bruger 2 - ∞ men hver ny bruger øger kravene til infrastruktur. Anskaffelsen af kunder skulle også nytænkes. Tidligere solgte produkter igennem magasiner, på messer, og mund-til-mund. I dag "købes" kunder med kæmpe reklamekampagner på alle "platforme" (især de elektroniske og helt særligt de sociale medier). Lægger 'man' de omkostninger til, er grænseomkostningen ikke længere nul, men dog stadig forunderlig lille, fordi den sidste kunde ikke belaster serverparken eller marketingbudgettet med noget reelt måleligt tal!

Prøver vi at anskueliggøre det i et diagram, får vi (i hele træskolængder) en graf, der nogenlunde ser sådan ud:

Den første bruger koster en bondegård! Ikke infrastrukturen (hvilket er en anden besynderlighed, som vi kan komme ind på senere), men koden. Den er hundedyr at anskaffe. Dagsprisen for en udvikler i den spidse ende, i Chicago fx, ligger fra 250.000 US$ om året, og de arbejder bedst i teams af minimum 2-3 stykker, og ikke mange timer om dagen (netto).

Den anden og om muligt endnu mere besynderlige kurve er grænseindtægtskurven – altså hvormeget den sidste kunde omsætter for (og her husker vi på at 'kunden' ikke betaler [direkte] for produktet, men kun i kraft af sin gøren og laden "i" produktet, danner transaktionsdata, der kan udnyttes kommercielt. Den kurve har fået et navn: hockey-stick, fordi den starter og i lang tid er en ret linje (få brugeres data er ingenting værd), men lige med et når datamængden et punkt, hvor dets evne til at sige noget har relevans (hvis 5 kunder køber salte fisk fra Katjes er der ingen, der lytter, men hvis 500.000 gør det er historien en helt anden)

Tidligere bad jeg dig læse en sætning 2 gange. Den er essentiel for forståelsen af værdiansættelsen af open source! Tyskerne siger: von nix kommt nix; vi siger først yde så nyde (uden at det helt er det samme), men engelsk har udtrykket TINSTAAFL (there is no such thing as a free lunch). Den virksomhed, der "sælger" open source, gør det altså med en bagtanke (som heroin pusherens first trip is on the house) om at sælge bedre versioner af produktet med mere funktionalitet eller helt andre produkter, hvor open source produktet så måske erstattes af closed source, eller, som det er tilfældet med megen freeware, for at sælge brugerens transaktions- og metadata.

Noget software er tilgængeligt af andre grunde, fx fordi selskabet bag var nødt til at lukke og opførte sig anstændigt i processen [ved at open source dets produkt(er)]. Producenten kan også være en enkelt-person, der som en del-leverance i forbindelse med en eksamen eller anden uddannelsesopgave har skullet fremstille kode med en særlig funktionalitet, som vedkommende efterfølgende har haft lyst til at dele [måske dybest set fordi vedkommende kunne]. Der er også den altruistiske person/organisation, som alene med henblik på samfundets vel, bygger og udbyder software til fri afbenyttelse. Fælles for de fleste af disse eksempler er imidlertid, at det kræver, at du selv finder ud af at udnytte den software: installation, opsætning, drift, tilsyn og pasning, mm.

Værdiansættelsen af open source er altså ikke, som med eksemplet en bil, mulig at beregne ud fra hverken produktets omkostninger, eller dets nyttefunktion! Den kan i bedste fald sammenlignes med den måde hvorpå såkaldte "strøvarer" eller brand merchandise (merch eller swag) værdiansættes - og selv her er det kun en tilnærmelse.

Samfundsnytten

Med de briller og i den kontekst er det svært at se hvordan open source kan bidrage positivt; at det har nogen reel samfundsnytte! Jeg vil dog alligevel forsøge at tegne et billede, hvor open source har en funktion og en positiv samfundsnytte!

Digital suverænitet

Hvad ingen skænkede en tanke for blot 6 måneder siden, er blevet måske dét største selling point for leverandører af digitale produkter og tjenesteydelser. En forunderlig verden!

En hjørnesten i denne suverænitet er risiko afdækning; altså at brugeren uanset om det er en virksomhed, en organisation, eller et helt samfund, suverænt kan (for)sikre sig mod de risici, som anvendelsen af et digitalt produkt eller en tjenesteydelse (automatisk) introducerer. Skal denne afdækning være effektiv, kræver det at produktets funktion, dets processer, datastrømme, og -behandlinger kan revideres, efterprøves, og reproduceres. Til det formål er open source – altså adgangen til kildekoden – essentiel!

Tilpasningsevne

De samfundsstrømninger vi er vidner til, her i midten af '20-erne, kræver i endnu større omfang end for 10 år siden, at vi er omstillingsparate. For at udnytte nye teknologier, som eksempelvis LLM'er (large language models) der er, i det mindste en væsentlig del af, grundlaget for AI, vil det kræve at processer og arbejdsgange forandres i en takt og omfang, som ikke er set tidligere. Det vil ikke være muligt med closed source alene af den grund at AI modeller ikke kan "se" ind i de sorte bokse, som closed source produkter reelt er. Leverandører kan vælge at bygge MCP'er til deres proprietære systemer, men adgangen til kildekoden vil være langt at foretrække, fordi det vil sætte AI agenter i stand til at forbedre produktet i stedet for at skulle nøjes med at arbejde videre med / uden om produktets data leverancer.

Skalérbarhed

Prisen på at udvikle software (på traditionel vis) stiger både fordi kvalitetskravene stiger, men især fordi produktiviteten falder (den får jeg sikkert hug for, men sådan må det være, når man husker på at Simonyi og Brodie skrev Word, i øvrigt anekdotisk på pizza og Jolt Coke [se dog her], på mindre end 2 år i starten af '80-erne, mens skat.dk vel er på mindst 10-ende år i det aktuelle "rul", og helt sikkert har mere end 2 personer på opgaven) – jeg finder selv ud...

Uanset; en omfattende ændring/omkalfatring af hele eller store dele af det kompleks af systemer, som kommuner, region og stat bruger, vil kræve så enorme ressourcer, at en traditionel tilgang til opgaven ganske vil sande til (som det desværre er set ske i, nå ja, nu nævnte jeg Skat, men der er uheldigvis rigeligt af eksempler i hatten, og at det må være sådan forklarer eksempelvis LinearB).

Sker udviklingen imidlertid på helt andre licensieringsvilkår, hvor leverandørerne ikke "får lov" at tjene pengene mere end én gang, men må nøjes med at tage sig betalt for at levere en open source, vil det være muligt at skalére løsninger på tværs af kommuner, kontorer og styrelser til ganske anderledes overskuelige omkostninger og ikke mindst tidsrammer (blandt andet fordi reproduktionen af løsningen kan ske parallelt i alle sammenhænge, med samme behov.

Kompleksiteten

Endelig vil open source kunne spille en afgørende rolle i en tiltrængt og nødvendig reduktion af kompleksiteten.

Her tjener et eksempel måske. I et tænkt kontor behandles ansøgninger om tilladelse til at udvide byggeprocenten på matrikler. Dialogen med ansøger sker, af hensyn til regelsæt om åbenhed i den offentlige forvaltning, i et journaliseringssystem, der er bygget sammen med en unavngiven, omend særdeles velkendt, kontorpakke, primært for at tilgodese brugernes user experience (brugeroplevelse). Opdateringer af kontorpakken, der i løsningens levetid de første par gange medførte først mindre men senere mere omfattende ændringer/tilretninger i grænsesnittet og brugerfladen i journaliseringssystemet, er de seneste år blevet opgivet pga bekosteligheden i kravene til ændringer/tilretninger, for endeligt helt at blive gjort umulige, da afviklingen af kontorpakken blev flyttet "i skyen". Kontoret ønsker sig aktuelt et nyt journaliseringssystem, der kan integreres med kontorpakken i skyen.

Eksemplet er sikkert fuldstændig hypotetisk og helt ude af trit med virkeligheden, men tjener også mest for at pege på et par pinde

• en digital mange-sidet dialog orienteret løsning, hvor den enkelte dialog på anfordring kan præsenteres i et særskilt digitalt format (aktindsigt), bør være lige så efterspurgt på ethvert kontor i størstedelen af den offentlige sektor, som en regnemaskine på et revisionskontor (læs: noget der “lugter” langt væk af standard)
• løsningen vil være et oplagt "offer" for et utal af integrationer
• fokus på det essentielle i løsningen risikerer på kort tid at blive afløst af en myriade af feature-creep (også benævnt scope-creep) fordi systemets mange interessenter ser hver deres subjektive interesse i "forbedringer" – eksempelvis at benytte en kontorpakke til at "fremstille" hhv præsentere indholdet af dialogen (den faktiske ordlyd) i stedet for at 'nøjes' med få tekst formateringsmuligheder
• den eneste måde en leverandør kan tilføre produktet merværdi vil være igennem udbygning af produktets scope, hvorfor det ad åre nemt kommer til at løse alt fra OCR scanning til email (integration til kontorpakken vel at mærke – for det er brugerne vant til og nødt til at have, til den interne kommunikation, og det vil jo være ubrugeligt og håbløst tidsspilde, hvis der var flere systemer til den opgave) – en passant: forestil dig en tømrer stolt vise dig deres nye hammer, der også kan bryde murværk ned og stifte indramninger af billeder (fordi det jo ville være tidsspilde at have flere værktøjer, der kan slå søm i)

Open source har meget at tilbyde her:

1. en række dialog orienterede løsninger at starte på/med
2. åben kildekode, og typisk veldokumenterede api'er, som vil lette behovet, ved etableringen af integrationer (når dette er uafvendeligt)
3. feature-creep er et grundvilkår; der hjælper ingen kære mor (eller open source)
4. et afleveret open source system kan konkurrenceudsættes i en helt anden grad end løsninger, hvor leverandøren står for at skrive kravspecifikationen til det næste "ehhh offentlige" udbud, hvor behovet for udbygning vil være brugernes behov for øget funktionalitet i større udstrækning, og leverandørernes behov for øget omsætning i mindre udstrækning

OSS — Open Source Software — hvorfor taler alle pludselig om det? Fejlede den “gamle” source da noget? Er det endnu et i en uendelig række af buzz-words som IT branchen er så berygtet for at være god til at opfinde? Måske kan du bare nøjes med at spørge ChatGPT: why did open source happen? 😉

Antitesen

For at forstå begrebet er vi nødt til først at forstå begrebets antitese: closed source.

For over 60 år siden byggede ingeniører computere, og så "byggede" de et program (kode) der kunne køre på computeren. Helt specifikt til den computer. Når astrofysikere og nationaløkonomer skulle "knuse store talmængder" tegnede de streger på kæmpestakke af papkort, som så både var program og data, og lod computeren læse dem, og så ventede alle i spænding på resultatet, timer og dage senere. Det var overvejende stater som havde råd til at have en hær af ingeniører gående og bygge udstyret og programmerne (stakkene af papkort). Universiteterne var først til at forske i bygningen af udstyr og programmer. I de miljøer deler man gerne – fordi forskere alle står på skuldrene af andre forskeres arbejde; samarbejde gør stærk.

Der var virksomheder, som så muligheder i computerne – og blev rigtig dygtige til at bygge maskinerne, og "programmere" dem (tegne streger på papkort). En af dem var IBM. Der blev snart hård konkurrence i feltet, fordi perspektiverne var overvældende, og kompetencerne blev konkurrencefordele, som man nødigt delte med konkurrenterne. Konkurrenterne forsøgte i stedet at lokke dygtige medarbejdere til sig i håbet om at de ad den vej kunne få adgang til kompetencerne. Modtrækket var patenter og intellectual property som tvang konkurrenter til at betale licens for at bruge en konkurrents design og metoder (selv om de måske havde lokket "opfinderen" over til sig). Sådan gik designet af udstyret og papkortene fra at være noget man delte, til at være closed source. I takt med at virksomheder blev dygtigere, faldt prisen på begge dele, og flere kunne få råd til elektronikken og papkortene der nu for længst var blevet effektiviseret til fleksible folier belagt med magnetiseret materiale - bånd, skiver, osv.

Tilgængeligheden satte flere og flere i stand til at lære (sig selv) at programmere og fordi virksomhederne kunne se økonomiske fordele ved at standardisere dele af udstyret, blev det muligt at programmere til flere leverandørers udstyr. Det skabte virksomheder i en helt ny branche: software udvikling.

I et helt andet spor og med et helt andet formål, fødtes en "ting" som sammen med computeren og programmets fødsel, skulle ændre verden aldeles: Internettet.

Det var igen universiteterne som var spydspidsen, og som i '60-erne havde overtalt det amerikanske forsvar til at kaste penge efter udviklingen af en sikker og ikke mindst fejltolerant måde at kommunikere på (mellem f.eks. atommissil siloerne og Forsvarskommandoen). Forskerne nød snart godt af at kunne dele viden mange gange hurtigere end tidligere (hvor viden først skulle trykkes og derefter omdeles i i bøger og rapporter). Det var der også virksomheder, som kunne se perspektiver i, og som blev dygtige til både at bygge udstyret, og programmere det effektivt. Hvor effektivt Internettet er som distributionskanal for alt digitalt indhold er de fleste klar over i dag.

Med computere, programmer, og distributionskanaler, har vi nu næsten alle byggestenene på plads – men hvorfor ændre noget, der virker som en særdeles effektiv (og indbringende) cocktail? Idealisme måske?! Hvad var motivationen?

Programmører er/var en slags "håndværkere" og når de ikke kan få et program til at virke, som de gerne vil, skriver de det om. Det var let i starten, fordi de nemlig skrev alt selv. Med tiden blev det nemmere/billigere at købe dele af programmet af andre, og selv kun ændre noget af programmet. Men når den del, man havde købt, så pludselig indeholdt en fejl, kunne man vente fuldstændig paralyseret indtil leverandøren havde rettet fejlen. Ønskede man at delen skulle indeholde en funktion, som ikke fandtes, og leverandøren ikke havde lyst til at bygge den funktion ind i delen – så var man paralyseret igen!

Reaktion

Hos nogen programmører affødte det den holdning at alle skulle have ret til at skille deres programmer ad, forstå hvordan de virkede, og ændre dem, hvis de mente det var nødvendigt.

Andre programmører var mere optaget af at få programmer til at virke på forskelligt udstyr, minimere sikkerhedsrisici ved at bruge programmerne og øge deres pålidelighed og effektivitet.

Jeg bliver nødt til at fremhæve én person, som i særdeleshed har været instrumentel for dannelsen af begrebet open source. Hans navn er Linus Torvalds og han er oprindeligt finne. Hans evne til at bygge meget effektive programmer er bevaret for altid i 2 "produkter" som er hans værk: kernen til operativsystemet Linux, og software-versionsstyring værktøjet Git. Han er håndværkeren, der kan se noget ineffektivt, og bygger noget, der er bedre. I tilfældet Linux fandtes allerede operativsystemer, som Windows og UNIX, men sammen med mere end 16000 frivillige hjælpere, er det lykkedes at gøre Linux så populært at selv IBM begyndte at pege på det, som svaret på, hvordan deres udstyr kunne styres – og, vel at mærke, uden at Linus Torvalds kørte en eneste avisreklame, TVspot eller Facebook kampagne (Mark Zuckerberg var først lige begyndt i skole, da Linus i 1991 frigav de første linjer af koden til Linux).

Grunden til at nævne Linus frem for en lang, lang række af andre betydningsfulde, er den, at han med sin frigivelse af koden til operativsystemet, på sin vis skabte præcedens for at stille adgangen til koden frit tilgængelig – ikke at han nødvendigvis var den første, men den kode, han delte, fik kolossal betydning for en hel branche siden da; og med Git gjorde han det 14 år senere muligt, for mange udviklere (programmører) at arbejde sammen om at bygge på det samme program, samtidigt, uden (eksempelvis) at skulle koordinere deres indsatser "a priori".

Når organisationer og virksomheder i dag i stigende grad begynder at interessere sig for, om der mon skulle være et open source alternativ til netop deres behov, så skyldes det, med titlen på Lemony Snickets bogserie, a series of unfortunate events.

1. De fleste kan se et monopol, når det findes. Det er der ikke i IT branchen, men den er foruroligende tæt på et oligopol, bestående af meget få, meget store amerikanske tech-virksomheder, med Microsoft, Google, og Amazon som de helt centrale aktører – det er skidt for konkurrencen og især: prisdannelsen
2. Den geopolitiske scene viser tegn på at et magtskifte er undervejs, og derfor sikrer især virksomheder sig ved, med Hr Møllers ord: at udvise rettidig omhu og undgå at et tab rammer dem
3. Risikoen for databrist har været tilstede i en årrække/altid. EU forsøgte i midten af 10'erne at sætte det i fokus med GDPR (det blev uheldigvis en papirtiger som fodrede advokater, revisorer og konsulentbranchen). Med den siddende administration i USA er risikoen mangedoblet
4. Manglende skalérbarhed i omkostningerne. Det har aldrig været en hemmelig, at der er en meromkostning forbundet med at uddelegere ansvar og kompetence, men det er sandsynligvis kommet bag på en del, hvor stor meromkostningen er – og at den ikke skalerer godt
5. Kompleksiteten i forretningssystemerne (de mange programmer, som medarbejdere benytter i både produktion og administration) har nået et omfang, der truer med at ødelægge virksomheders stordriftsfordele, og begrave dem i hvad der til alle tider har været enhver organisations og forretningsidés banemand: bureaukrati.
6. Professionaliserede købere. Private virksomheders (men også succesfulde offentlige institutioners) konkurrencemæssige fordele ligger i deres unikke håndtering af kunden, produktet, distributionen, og/eller transaktionen, og det DNA afspejles altid i forretningssystemerne. IT branchen har solgt "standard systemer" siden jeg var lærling, men leveret (og levet af) tilpasninger til de samme, og det "lock-in" (hvor man låses til en leverandør og deres "tilpasninger") er købere i dag i stigende grad blevet så erfarne i at gennemskue, at et alternativ bliver relevant

Er open source løsningen?

Løser åben kildekode de problemer? Ja, hvis efterspørgslen efter fx Microsoft's produkter udebliver, reduceres deres markedsrolle. Spredes efterspørgslen på et utal af konkurrerende produkter (eksisterende såvel som nye der måtte opstå som følge af muligheden), vil det øge konkurrencen, fremme prisdannelsen og innovationen.

Værktøjers kompleksitet har en afgørende indflydelse på deres ibrugtagning, accept blandt brugere, og udnyttelsesgraden af dem. Adgangen til at tilpasse eller direkte fjerne funktionalitet vil uomtvisteligt reducere kompleksitet, og skabe muligheden for at fjerne eller mindste risikoen for databrist (når værktøjets virke kan analyseres, revideres, og reproduceres).

Skalérbarheden i anvendelsen (og givetvis også omkostningerne) vil øges drastisk i takt med reduktionen i kompleksitet. IT branchen har vist det i mindst 15-20 år! SaaS (hvor du betaler hver måned for at bruge et værktøj) var svaret på en række spørgsmål: hvordan kan vi maksimere indtjeningen på den kode vi skriver? hvordan kan vi reducere dybden af 'salgstrakten' = gøre det nemmere at sælge kunden på løsningen? hvordan kan vi sikre vores customer retention (hvordan holder vi kunderne fast)? Fjern kompleksitet (gør det nemmere for kunden at "forstå" produktet) ved at begrænse produktets funktionelle domæne.

Der venter en ny verdensorden, nye værdikæder, måske en ny "basis valuta" til erstatning for dollaren. Der venter en næsten overvældende strukturel ændring af samfundet, hvor teknologi kommer til at spille en endnu større rolle. Vi kender nogle få af begreberne allerede: robotter, AI, mfl. Vi ved også at big is beautiful men at complexity kills og måske lever softwareløsninger ikke længe nok til at de kan retfærdiggøre fler-faktor omkostninger i tilpasninger – og hvis det så er standard, som alle bruger, vil det så ikke være nærliggende at forlange, at dette "fundament" er kendt, revidérbart, reproducérbart; at det er standarden, at det er open source?

I dén kalejdoskopiske kontekst er open source måske det bedste svar, i det mindste på den kortere bane.

We found ourselves wanting a tagging engine for M O R T I M E R – your fastest way from job done to invoice sent BTW; and when evaluating the existing gems my hands trembled just slightly: the 'best in class' with 20+ mio downloads and shy of 200 contributors and yet well over 250 issues – nah, don't think so...

So then, surely someone else did this years ago, right? Well - José Farias shared hotwire_combobox about 2 years ago, that's how close I've been able to get. A programmer, Yair Even Or, did start sharing Tagify 9 years ago, and that project indeed has a lot of potential, but again - 70 issues - and it's a js-soup, but then again, it's been a valuable smorgåsbord of implementation details! We will not even reach it to it's socks – for a long, long time, if ever...

Ohh - and in case you wonder - I've got a Copilot eagerly chiming along the way which will have us go back and do 're-runs' on a number of occasions but that's 2025 for you right there I guess 😜

Use cases

I better get the use cases straight, first! This sketch done in one of my top favorite tools, Whimsical (yes I'm a customer, and no, I do not get credits for mentions) should give you a sense of the domain:

Whether the input comes verbatim through some AI speech-to-text or will be even further digested by other LLM's spitting out stuff like

{
  time_material: {
    time: "1.25",
    task: "QA",
    location: "Lab1",
    user: "bio intern",
    started_at: "6:45PM"
  }
}

really is non-essentiel.

UI - framing use cases

With the title encompassing hotwire I bet you're on the edge of your stool waiting for the implementation details, but we need to set the expectations - so here is the "MVP" so to speak:

Looking like an ordinary input - but it has a trick or two up it's sleeves 😉

Like when you start typing the input will assist you with suggestions matching what you have typed so far

To mobile users what follows is of no interest.

From here you can go different ways. Input a comma or period to tell the input field that your tag is done and should be added as is. Use the arrow keys Up and Down to navigate the suggestions. Use Enter to select a particular suggestion. Use Escape to remove the dropdown

When selected you can use Backspace to go back and start editing the tag or start typing the next tag.

There is one more frame to consider. With very long tags (multi-word tags like non-stick polycarbonate based appliances) or a whole cloud of tags you will find yourself running out of chrome so to speak – so the input field should (automagically preferably) consider where to place the added tags, inline or below

UI - implementation

Finally – that was quite a, ehhh foreplay, don't you think? Let's get dirty, shall we?

Initial Frame

We use Phlex extensively in M O R T I M E R and because Brad Gessler did such a tremendous job on Superform, our 'forms' – at least the CRUD ones, mostly looks like this:

class Projects::Form < ApplicationForm
  def view_template(&)
    row field(:name).input().focus
    row field(:description).input()
    row field(:start_date).datetime(class: "mort-form-datetime")
    row field(:end_date).datetime(class: "mort-form-datetime")
    row field(:state)
      .select(Project.project_states, class: "mort-form-select")
    row field(:budget).input()
    row field(:is_billable).boolean(class: "mort-form-bool")
    row field(:is_separate_invoice).boolean(class: "mort-form-bool")
    ...8<..
    row field(:actual_minutes).input()
  end
end

If you'd like to read more about how M O R T I M E R utilises Phlex leave a comment. Anyways, we're not ready to build the 'shrink-wrapped' version just yet so we'll start with the first "frame" and write the necessary test – by the way: Phlex is sooo easy to test being just PORO (plain old ruby objects), but first let's make sure the basic input field is in place

require "application_system_test_case"

class TagTest < ApplicationSystemTestCase
  # setup do
  #   @tenant = tenants(:one)
  #   @user = users(:superadmin)
  # end

  test "the tag to have an input field" do
    output = render TagComponent.new
    assert_match "<input", output.to_s
  end
end

That obviously does turn out red – but is easily fixed with

class TagComponent < ApplicationComponent
  def view_template
    input(type: "text", value: "tag1, tag2")
  end
end

Ok - we're moving, GREAT! The input element is BTW the element holding on to what every values are provided up front as well as added during an editor session (a lot more on this later).

Time for som Hotwiring - don't you think? Here we go: The <turbo-frame></turbo-frame> will allow Rails and Turbo/Stimulus to update the DOM 'in flight':

  test "the tag to have a turbo_frame " do
    output = render TagComponent.new 
      resource: TimeMaterial.new, 
      field: :task_comment
      
    assert_match "<turbo-frame id=\"tag", output.to_s
  end

The component arguments is just us slowly preparing to move this into actually serving proper values for ActiveRecord objects. Making this test green requires a few changes, the important ones being

  include Phlex::Rails::Helpers::TurboFrameTag

  def view_template
    turbo_frame_tag "#{Current.get_user.id}_tag" do
      div(data: { controller: "tag" }) do
        @editable ? editable_view : show_view
      end
    end
  end

This is a naiive implementation (think: multiple forms in the view, multiple fields in a form, more contexts, and what not) but will restrict the turbo_stream to whatever the current_user is meddling with, at least.

We will skip adding any label to the field, and styling is also of lesser interest right now.

Lookup Frame

Building a list of autocomplete elements is what we will focus on. We will need a test for that (and add 2-3 tags to the fixtures/tags.yml

  test "the tag to have a lookup container" do
    @tags = Tag.all
    m = "<div id=\"time_material-task_comment-lookup-container\""
    output = render TagComponent.new 
      resource: TimeMaterial.new, 
      field: :task_comment, 
      resources: Tag.all,
      search: "do"
      
    assert_match m, output.to_s
    assert_match tags(:one).name, output.to_s
  end

We also make sure the tags are listed with the last assert_match. In order for this to turn green we will change the component to look like this:

class TagComponent < ApplicationComponent

  def initialize(resource:, field:, resources: nil, search: "")
    @resource = resource
    @field = field
    @resources = resources
    @search = search
  end

  def view_template
    turbo_frame_tag "#{Current.get_user.id}_tag" do
      div(data: { controller: "tag" }) do
        input(type: "text",
          data: { tag_target: "input", action: "keyup->tag#keyup" },
          name: resource_field("%s[%s]"),
          id: resource_field,
          class: @field_class,
          value: @search)
    
        render_tags_list      
      end
    end
  end

  def render_tags_list
    return if @resources.nil?
    
    div(id: resource_field("%s-%s-lookup-container") do
      @resources.each do |tag|
        a(href: "#", data: { action: "click->tag#pick" }) { tag.name }
      end
    end
  end

  def resource_field(joined = "%s_%s")
    joined % [ @resource.class.to_s.underscore, @field.to_s.underscore ]
  end
  
end

We like the 🟢 so much! Now for this 'frame' to ever come to fruition, we'll have to add some stimuli or rather just one and we'll use this command to do it: rails g stimulus tag that we then edit and make look like this

import { Controller } from "@hotwired/stimulus"
import { get } from "@rails/request.js";

// Connects to data-controller="tag"
export default class extends Controller {
  static targets = [
    "input",
    "output",
    "selectedTags",
    "tagList"]

  lastSearch = null;

  connect() {
    setTimeout(() => {
      if (this.inputTarget.textContent == undefined)
        this.inputTarget.textContent = "";
      this.lastSearch = this.inputTarget.textContent;
    },10)
    this.inputTarget.focus();
  }

  // put the cursor at the end of the 'input'
  focus(event) {
    event.preventDefault();
    let caret = document.createRange();
    caret.selectNodeContents(this.inputTarget);
    caret.collapse(false);
    const sel = window.getSelection();
    sel.removeAllRanges();
    sel.addRange(caret);
  }

  keyup(event){
    this.lookup(event);
  }

  keydown(event) {
  }

  lookup(event) {
    if (event.target.value.length > 1) {
      get(`/tags/tags?search=${event.target.value}`, {
        responseKind: "turbo-stream"
      })
    }
  }
}

We are not nearly there - and we are not doing any system tests yet, but that calls for a fresh cup of coffee I think! We're not home yet but gettin' there, and while you get that ☕ here is the controller handling the 'get' action

class TagsController < MortimerController
  def tags
    tags = Tag.by_tenant
      .where("name LIKE ?", "%#{params[:search]}%")
      .order("name ASC")
      .limit(10)
    respond_to do |format|
      format.turbo_stream { 
        render partial: "tags/tags", locals: { tags: tags } 
      }
    end
  end
end

it's not done - don't worry, but more like a WIP. I know – it's not RESTful as such but one extra route on the tags resource for this specialized purpose seems like a small price to pay.

The accompanying partial with the "tags/tags" reference above:

<%= turbo_stream.replace("#{Current.get_user.id}_tag") do %>
<%=   render TagComponent.new(resource: Tag.new, 
        field: :name, 
        resources: tags, 
        search: params[:search], 
        show_label: true, 
        field_class: "mort-form-text", 
        label_class: "text-red-500", 
        value_class: "mr-5", 
        editable: true) %>
<% end %>

That, mostly, finished the lookup frame in our first run (yes I reckon there will be at least a second run). Now on to the

Selected Frame

We'll press on with a test

test "the tag to have a selected container with a selected tag" do
    @tags = Tag.all
    m = "<div id=\"time_material-task_comment-selected-container\""
    output = render TagComponent.new 
      resource: TimeMaterial.new, 
      field: :task_comment, 
      resources: @tags, 
      value: [ tags(:one).name ]
      
    assert_match m, output.to_s
    assert_match tags(:one).name, output.to_s
  end

Hmmm 🔴 – not totally unexpected but; 😮 Second run so soon?! Who'd guess 😎

Here's the predicament we're in: As per our use case #1 (initial frame) we're good, but now we need to paint a box inside the input box! That's totally not going to fly. What to do?

First we have to go back and refactor the initial frame - yep, second run! While we're at it let's clean up the methods

class TagComponent < ApplicationComponent

  def initialize(resource:, field:, resources: nil, search: "", value: "")
    @resource = resource
    @field = field
    @resources = resources
    @search = search
    @value = value.class == String ?
      value :
      value.join(", ")
  end

  def view_template
    turbo_frame_tag "#{Current.get_user.id}_tag" do
      div(class: "mort-field", data: { controller: "tag" }) do
        #
        # making the input a hidden one!
        input(type: "hidden",
          name: resource_field("%s[%s]"),
          id: resource_field,
          value: @value,
          data: { tag_target: "output" })
        @editable ? editable_view : show_view
      end
    end
  end

  def editable_view
    div(class: "flex flex-col", data: { action: "click->tag#focus" }) do
      label_container
      div(class: "inline-flex w-full \
        rounded-md border-0 bg-white py-1.5 pl-1 \
        text-gray-900 shadow-xs ring-1 ring-inset ring-gray-300 ") do
        selected_container
      end
      div(class: "relativ") do
        render_tags_list
      end
    end
  end

  
  def selected_container
    div(id: resource_field("%s-%s-selected-container"), 
      data: { tag_target: "selectedTags" }, class: "flex flex-wrap") do
      @value.each do |tag|
        span(class: "flex items-center") do
          a(href: "#", 
            data: { action: "click->tag#removeTag", 
            id: tag.id }, class: "ml-0.5 mb-0.5") do
            span(class: "flex items-center bg-gray-200 \
              text-gray-700 px-2 py-1 rounded-md text-sm") do
              span { tag.name }
              render Icons::Cancel.new(css: "ml-2 h-4 w-4 text-gray-400")
            end
          end
        end
      end
      editor_field
    end
  end


  def editor_field
    span(contenteditable: true,
      data: {
        tag_target: "input",
        action: "keydown->tag#keydown keyup->tag#keyup focus->tag#focus",
        placeholder: I18n.t("components.tag.#{@field}")
      },
      # hmm CSS does not seem to bite!?
      style: "border: none; outline: none;",
      class: "grow ml-0.5 px-1",
      name: resource_field("%s[%s]-input"),
      id: resource_field("%s_%s-input")) { @search.html_safe }
  end
  
end

(The backslash on the attributes means you should keep the strings together – only there for readability here!)

Much better - now we just need to sprinkle CSS all over the place (under the influence of Tagify, remember?)

.mort-form-tag {
  @apply inline-flex w-full rounded-md border-0 bg-white py-1.5 pl-3 text-gray-900 shadow-xs ring-1 ring-inset ring-gray-300;
}

[contenteditable="true"]:active,
[contenteditable="true"]:focus {
  border: none;
  outline: none;
}

.tag-input {
  flex-grow: 1;
  display: inline-block;
  position: relative;
  margin: 5px;
  padding: var(--tag-pad);
  line-height: normal;
  white-space: pre-wrap;
  box-sizing: inherit;
  overflow: hidden;

  &::before {
    content: attr(data-placeholder);
    width: 100%;
    height: 100%;
    margin: auto 0;
    white-space: nowrap;
    text-overflow: ellipsis;
    overflow: hidden;
    pointer-events: none;
    position: absolute;
    opacity: 0;
    transition: all 0.5s;
  }
  &::after {
    content: attr(data-suggest);
    display: inline-block;
    vertical-align: middle;
    position: absolute;
    min-width: calc(100% - 1.5em);
    text-overflow: ellipsis;
    overflow: hidden;
    white-space: pre;
    opacity: .3;
    pointer-events: none;
    max-width: 100px;
    transition: all 0.5s;
  }
}

The .mort-form-tag and 5 topmost lines of CSS are of my own 'googling', though. Turns out (at least some) browsers by default decorate a contenteditable element.

The tag_controller.js even had to have a few "coats of paint" :

  lookup(txt) {
    if (txt.length > 1 && txt !== this.lastSearch) {
      this.lastSearch = txt;
      get(`/tags/tags?search=${txt}`, {
        responseKind: "turbo-stream"
      });
    }
  }

  addTag(event) {
    event.preventDefault();
    let tags = this.outputTarget.value;
    let data = this.inputTarget.textContent;
    let url = encodeURI(`/tags/tags?add_tag=${data}&value=${tags}`);
    get(url, {
      responseKind: "turbo-stream",
    });
  }

  removeTag(event) {
    event.preventDefault();
    const tag = event.currentTarget;
    const selectedTags = this.selectedTagsTarget;
    if (selectedTags) {
      const tagItem = selectedTags
        .querySelector(`[data-id="${tag.dataset.id}"]`);
      if (tagItem) {
        let tags = this.outputTarget.value.split(",");
        tags = tags.filter(t => t !== tag.dataset.id).join(",");

        let url = encodeURI(
          `/tags/tags?` +
          `search=${this.inputTarget.textContent}&` +
          `value=${tags}`
        );
        
        get(url, {
          responseKind: "turbo-stream",
        });
      }
    }
  }


  pick(event) {
    event.preventDefault();
    if (this.outputTarget.value === undefined) {
      this.outputTarget.value = "";
    }
    if (this.outputTarget.value != "") {
      this.outputTarget.value = this.outputTarget.value + ",";
    }
    let url = encodeURI(
      `/tags/tags?`+
      `value=${this.outputTarget.value}${event.target.textContent}`
    );
    
    get(url, {
      responseKind: "turbo-stream",
    });
    this.tagListTarget.classList.add('hidden');
  }

Now we are getting the hang of it – so let's refactor somewhat, again.

First, we need to realize that keeping a tab on the tags is a challenge with words - so we will hold their ID's instead. value = [ ID, ID, .., ID ]

Let's have a test for that – in fact all we need to do is change the last test ever so much:

  test "the tag to have a selected container with a selected tag" do
    tags = []
    m = "<div id=\"time_material-task_comment-selected-container\""
    output = render TagComponent.new 
      resource: TimeMaterial.new, 
      field: :task_comment, 
      resources: tags, 
      value: [ tags(:one).id ]
      
    assert_match m, output.to_s
    assert_match "data-id=\"#{tags(:one).id}\"", output.to_s
    assert_match tags(:one).name, output.to_s
  end

Now, here's one for the "buffs" reading this: the second assert_match probably does not sit well with you! "Don't test the implementation - test the consequence/result" I hear you yell, and you're right, alright?! (and I'm painfully aware that with this entire post I probably commit enough 'design/developer sins' to only ever be ridiculed and made the laughing stock – but such is life) 🤷‍♂️

The TagsController was long overdue for some serious refactor

  def tags
    if params[:add_tag].present?
      tag = Tag.find_or_create_by(name: params[:add_tag], 
        tenant_id: Current.get_tenant.id, 
        created_by: Current.get_user)
    end
    unless params[:search].blank?
      tags = Tag.by_tenant
        .where("name LIKE ?", "%#{params[:search]}%").order("name ASC")
        .limit(10)
      search = params[:search]
    else
      tags = []
      search = ""
    end
    if params[:value].blank?
      value = tag.present? ? [ tag ] : []
    else
      ids = params[:value].to_s.split(",").map(&:strip)
      ids.push tag.id if tag.present?
      value = Tag.by_tenant.where(id: ids) rescue []
    end

    respond_to do |format|
      format.turbo_stream { 
        render partial: "tags/tags", locals: { tags:, search:, value: } 
      }
    end
  end

Four issues remain (+ the ones you might spot):

1. doing the persistence of tags on any particular resource — like a TimeMaterial ActiveRecord
2. Test how editing existing ActiveRecord objects fare
3. Solve the layout automagically when tags get crowded in the input
4. Adding more than one tag input field on a form

Leave a note - or perhaps your take on this. You are always welcome to visit with us at M O R T I M E R.

🙏

What is a modal even? How could it be generic? Questions seems to pile easily. I'll do my best to answer them as we build exactly that - a generic modal.

I'm using the SaaS product we're building – it's called M O R T I M E R and it affords you the fastest from job done to invoice sent.

It's a Rails 8 application but you could strap this on a Rails 7 application as well, I believe.

A modal

Modals are a graphical control element subordinate to an application's main window according to Wikipedia. Usually it's implemented with a backdrop indicating that focus has now shifted to the modal element only.

Javascript fellows prompt and alert displays modals of sorts. We can go quite further than that but we will start there.

Modals will have 3 variables defining their capabilities:

Flavor

We will say that modals have a flavor. From very basic to very advanced flavors will tell us what the modal will be capable of. alert is one flavor that only is capable of posting a 'warning sign'. prompt is just a bit more advanced affording a accept or refuse reply - think deleting posts etc. guide is – at the moment – the most advanced modal I can think of. It provides information, allows for inputting information, and may advance forward or go backwards in a preset number of views/steps.

Modal_form

Modal form partials are labeled by their name in the views/modal/ folder - like fx '_delete.html.erb'

Modal_next_step

The last piece of information is of a "cursory nature" – it points to the next expected user action. Like 'accept' will set things in motion, and ‘step_1’ will move to just that.

Modals in the Hotwired context

We will build the generic modal aided by Hotwire – if this is "new territory" to you go study it by all means; I'm pretty sure you'll like it!

We will need somewhere to place the modal content so our first test must verify that we do allow for the content to be 'placeable'

require "application_system_test_case"

class ModalTest < ApplicationSystemTestCase
  setup do
    @tenant = tenants(:one)
    @user = users(:superadmin)
  end

  test "visiting the index" do
    login_as(@user)
    visit root_url
    # assert <remote-modal-container></remote-modal-container>
    assert_match "remote-modal-container", page.html
  end
end

This custom tag <remote-modal-container> will allow us to inject HTML into the DOM using Turbo.

From some link that you'd like to open a modal - fx confirm a delete action - we would like to inject HTML. Turbo will 'by default' fetch ie use AJAX to request the endpoint / the HTML and inject it into the DOM.

The link could look like this

# views/components/context_menu.rb
class Contextmenu < Phlex::HTML
  include Phlex::Rails::Helpers::Request
  include Phlex::Rails::Helpers::Routes
  include Phlex::Rails::Helpers::LinkTo
  include Phlex::Rails::Helpers::ButtonTo
  include Rails.application.routes.url_helpers

  attr_accessor :resource, :resource_class, :list

  def initialize(resource: nil, list: nil, resource_class: nil, turbo_frame: "_top", alter: true, links: [], cls: "relative flex")
    @resource = resource
    @resource_class = resource_class || resource.class
    @list = list
    @turbo_frame = turbo_frame
    @alter = alter
    @links = links
    @css = cls
  end

  def view_template
    div(data_controller: "contextmenu", class: @css) do
      contextmenu_button
      case true
      when !list.nil?; list_dropdown
      when !resource.nil?; dropdown
      end
    end
  end

...
      resource_class.any? ?
        link2(url: helpers.new_modal_url(
          all: true,
          modal_flavor: "prompt",
          modal_form: "delete",
          modal_next_step: "accept",
          resource_class: resource_class.to_s.underscore,
          search: request.query_parameters.dig(:search)),
          action: "click->contextmenu#hide",
          icon: "trash",
          label: I18n.t(".delete_all")) :
        div(class: "disabled_context_link") { I18n.t(".delete_all") }
...


    def link2(url:, 
      label:, 
      action: nil, 
      data: { turbo_stream: true }, 
      icon: nil, 
      css: "context_link")
      
      data[:action] = action if action
      link_to url,
        data: data,
        class: css,
        role: "menuitem",
        tabindex: "-1" do
        render_icon icon
        span(class: "text-nowrap pl-2") { label }
        span(class: "sr-only") do
          plain label
          plain " "
          plain resource.name rescue ""
        end
      end
    end


    def render_icon(icon)
      return if icon.blank?
      render "Icons::#{icon.camelcase}".constantize.new(cls: "contexticon")
    end

        

If you'd like to read about using view components leave a comment 😄

The 'soup' to emerge from all of this is something a lot like this

So, when a user tap's the [delete all] context menu item Turbo will send a request that looks like this (with 'as TURBO_STREAM' being one of the essential things to note):

15:16:32 web.1  | Started GET "/modal/new?
  all=true&
  modal_flavor=prompt&
  modal_form=delete&
  modal_next_step=accept&
  resource_class=time_material" for 127.0.0.1...
15:16:32 web.1  | Processing by ModalController#new as TURBO_STREAM
15:16:32 web.1  |   Parameters: {
  "all"=>"true", 
  "modal_flavor"=>"prompt",
  "modal_form"=>"delete", 
  "modal_next_step"=>"accept", 
  "resource_class"=>"time_material"}

So next up we'll need a controller to handle the(se) endpoint(s) - again if you have questions regarding the before_actions especially the resources drop me a comment below

# controllers/modal_controller.rb
class ModalController < MortimerController
  before_action :set_vars
  before_action :set_batch
  before_action :set_filter
  before_action :set_resources
  before_action :set_resources_stream

  def new
    # resource
    @resource = find_resource
    @ids = @filter.filter != {} ||
      @batch&.batch_set? || 
      @search.present? ? 
      resources.pluck(:id) : 
      []
      
  end
  
  private

    def set_vars
      @all = params[:all] || "false"
      @modal_form = params[:modal_form]
      @modal_flavor = params[:modal_flavor]
      @modal_next_step = params[:modal_next_step] || "accept" rescue ""
      @url = params[:url] || resources_url rescue root_url
      @search = params[:search] || ""
    end

The view part of things is where the Turbo really shines. We start by adding a helper to ease the repetitive task affording us a method show_remote_modal

# helpers/turbo_stream_actions_helper.rb
module TurboStreamActionsHelper  
  def show_remote_modal(&block)    
    turbo_stream_action_tag(:show_remote_modal,
      template: @view_context.capture(&block)    
    )  
  end
end
Turbo::Streams::TagBuilder.prepend(TurboStreamActionsHelper)

That method comes to good use in the 'new' view template like this

<!-- views/modal/new.turbo_stream.erb -->
<%= turbo_stream.show_remote_modal do %>
  <dialog 
    id="new_form_modal" 
    aria-labelledby="modal_title" 
    data-controller="modal" 
    data-action="keydown->modal#keydown">

    <!-- take your modal of choice from tailwindui.com -->
    <div class="tailwindclasses">
      <div 
        class="more-tailwind-classes">
        <div class="lots-of-classes">
          <div class="absolute right-0 top-0 pr-4 pt-4 sm:block">
            <form 
              id="dialog_form" 
              method="dialog">
              <button 
                aria-label="close" 
                type="submit" 
                formmethod="dialog" 
                data-action="click->modal#close" 
                class="close_modal_button">
                <span class="sr-only">Close</span>
                <svg 
                  class="h-6 w-6" 
                  fill="none" 
                  viewBox="0 0 24 24" stroke-width="1.5"
                  stroke="currentColor" aria-hidden="true">
                  <path 
                    stroke-linecap="round" 
                    stroke-linejoin="round" 
                    d="M6 18L18 6M6 6l12 12" />
                </svg>
              </button>
            </form>
          </div>
          <div 
            id="modal_container" 
            data-action="modalClose@window->modal#closeDialog" 
            data-dialog="new_form_modal">
            
            <%= render @modal_form %>
          </div>
        </div>
      </div>
    </div>
  </dialog>
<% end %>

Stimulus - the missing link

It's not missing per se, more like untouched until now 😀

Hotwire packs a good punch - with Turbo controlling the navigation and loading of resources, and Stimulus allowing for custom building actions. Read more about Stimulus.

We connect a javascript controller to a DOM element - the dialog element in this case:

// javascript/controllers/modal_controller.js

import { Controller } from "@hotwired/stimulus"

// Connects to data-controller="modal"
export default class extends Controller {
  static targets = ["backdrop", "dialog", "dismiss", "submitForm"];

  connect() {
    document.documentElement.classList.add('lock-scroll');
    document.body.classList.add('lock-scroll');
  }

  disconnect() {
    this.removeScrollBlock()
  }

  keydown(e) {
    e.stopPropagation();
    switch(e.key) {
      case "Escape":
        this.close(e);
        break;
      case "Enter":
        this.submitFormTarget.click();
        break;
    }
  }

  removeScrollBlock(){
    document.documentElement.classList.remove("lock-scroll");
    document.body.classList.remove("lock-scroll");
  }

  submitForm(event) {
    this.removeScrollBlock()
  }

  show(event) {
    const dialog = document.getElementById(event.params.dialog);
    dialog.showModal();
  }  

  closeDialog(event) {
    const dialog = document.getElementById(event.target.data.dialog);
    dialog.close();
  }

  closeModal(e) {
    const modal = document.getElementById("new_form_modal");
    modal.close();
  }

  close(e) {
    this.removeScrollBlock()
  }
}

The modal is, by now, entirely generic and we can throw (almost) anything in there. In the link we decide by setting a @modal_form and a @flavor. The _new partial looks like this:

<% url = resource.id.present? ?
  modal_url(resource) : 
  modal_url(resource_class.first) %>
<%= form_with(url: url, method: :delete, multipart: true) do |form| %>
  <div class="sm:flex sm:items-start">
    <div class="tailwind-classes-galore">
      <%= render Icons::Trash.new cls: "h-6 text-red-500" %>
    </div>
    <div class="mt-3 text-center sm:ml-4 sm:mt-0 sm:text-left">
      <h3 
        class="text-base font-semibold leading-6 text-gray-900"
        id="modal_title">
        
        <%= delete_modal_title %>
      </h3>
      <div class="mt-2">
        <p class="text-sm text-gray-500 pb-3">
          <%== delete_modal_instruction %></p>
          <%= form.hidden_field :all, value: set_all_true %>
          <%= form.hidden_field :modal_form, value: @modal_form %>
          <%= form.hidden_field :modal_next_step, value: @modal_next_step %>
          <%= form.hidden_field :modal_flavor, value: @modal_flavor %>
          <%= form.hidden_field :resource_class, value: resource_class %>
          <%= form.hidden_field :id, value: resource&.id %>
          <%= form.hidden_field :search, value: params.dig(:search) %>
          <%= form.hidden_field :url, value: @url %>
        </p>
      </div>
    </div>
  </div>
  <div class="mt-5 sm:mt-4 flex justify-between flex-row-reverse">
    <%= form.button
      t("#resource_class.to_s.underscore}.modal.delete.button"), 
      data: { 
        modal_target: "submitForm", 
        action: "modal#submitForm"
      }, 
      class: "mort-btn-alert sm:ml-3" %>
      
    <%= button_tag t(:cancel), 
      form: "dialog_form", 
      formmethod: :dialog, 
      data: { action: "click->modal#close" }, 
      class: "mort-btn-cancel" %>
  </div>
<% end %>

This 'model_form' sets all the variables for the form and when submitted returns a request like this:

17:14:07 web.1  | Started DELETE "/modal/388" for ...
17:14:07 web.1  | Processing by ModalController#destroy as TURBO_STREAM
17:14:07 web.1  |   Parameters: {"authenticity_token"=>"[FILTERED]",
  "modal_flavor"=>"prompt", 
  "modal_form"=>"delete", 
  "modal_next_step"=>"accept", 
  "resource_class"=>"TimeMaterial", 
  "all"=>"true", 
  "attachment"=>"", 
  "id"=>"388", 
  "search"=>"", 
  "url"=>"https://localhost:3000/modal", 
  "button"=>""}

Back in the controller we handle this like so:

# controllers/modal_controller.rb
class ModalController < MortimerController
  def destroy
    params[:action] = "destroy"
    params[:all] == "true" ? process_destroy_all : process_destroy
  end


  private
 

    def process_destroy_all
      begin
        DeleteAllJob.perform_later 
          tenant: Current.tenant, 
          user: Current.user, 
          resource_class: resource_class.to_s,
          ids: resources.pluck(:id),
          batch: @batch,
          user_ids: (
            resource_class.first.respond_to?(:user_id) ?
            resources.pluck(:user_id).uniq : 
            User.by_tenant.by_role(:user).pluck(:id)) rescue nil
            
        @url.gsub!(/\/\d+$/, "") if @url.match?(/\d+$/)
        flash[:success] = t("delete_all_later")
        respond_to do |format|
          format.turbo_stream { }
          format.html { 
            redirect_to @url, 
            status: 303, 
            success: t("delete_all_later") 
          }
          format.json { head :no_content }
        end
      rescue => e
        say "ERROR on destroy: #{e.message}"
        redirect_to 
          resources_url, status: 303, error: t("something_went_wrong")
      end
    end
 
end

I'll have to save building the guide flavored modal for another day – but here you have it: a generic modal ready for display just about anything you can think of.

Enjoy

Got a great product and now you would like your consumers to start paying for it! Doesn't sound too far fetched and quite reasonable in fact – but how does the mechanics work at all? Like, where do I sign to make this happen? If you are like I was, right now you got a lot of questions!

This post is about how you go from running/providing a service to see money getting into your bank account.

Disclaimer: I did not receive any kick backs or advertisement benefits for doing this post nor am I an affiliate partner of any service provider mentioned in this post!

Who will collect the money on my behalf?

One of my first questions was just that! I knew I (designed an inter-National Banks cheque exchange system back in the early 90's, so I probably) could build an integration with a bank – a number of banks to be more precise – using the PSD2 (EU 2015/2366 Directive) but that would require me to handle a lot of regulation and compliance myself!

An easier (and a lot faster) way is to pay someone else to do that for me just like I plan to get paid by my customers to do something for them. A payment gateway that is called. The one that comes to mind (and mentioned a lot when you google it) obviously is Stripe. There are many like Stripe and some that are less costly but one reason to go with Stripe is the api documentation which Stripe has taken to a whole different level! 🥳

Where to start?

There are a number of issues to tick off and I made a list for your benefit:

• get a bank account
• setup an account with Stripe
• install the 'stripe' gem
• generate the payment link
• add callback route

The rest of this post will go through each issue and solve them.

Get a bank account

This may sound crazy but even in 2025 you still need to have one of these archaic constructs: a bank account! I have a lot to say about that but let's focus here.

You need a bank account that will do IBAN/SWIFT payments (that's international money wiring). I'm doing this from Denmark so I'm not sure if you can get away with just your Apple Pay account in the US but anyways...

An account with Stripe

Setting up an account with Stripe is fairly easy. Go to stripe.com and sign up and then start setting up your account by following a very crafty made setup guide (thank you Stripe - job well done)

Install the 'stripe' gem

This one was easy as pie – I just ran bundle add stripe and almost was done!

Generate the Payment Link

From somewhere, probably the UI, you'll call the generation of the Payment Link and you can make it as customized and fancy as you like (there is a ton of API calls to that end) or you can lock in on a select few things, like a product, a price and boom. Once generated you'll show that to the user somehow - a modal, an email, whatever - and then just sit tight and wait for the callback 😆

Add callback route

You could argue that a callback route is of less value in a workflow like this one – being variably asynchronous; but it actually makes a lot of sense – if you take the same route I did, that is!

I use the Payment Link API to generate a unique link to every new customer (a user that selects one of the payable services to choose from in Mortimer) and this link may live (forever?) a long time, until the user decides to use it. This way I get to do this, eventually/hopefully always:

class Stripe::PaymentController < ApplicationController
  # Stripe callback from completed payment
  # GET "/stripe/payment?ci=cs_test_a1M01tZueaLHFtv...Cwn5tgV61"
  #
  # param 
  #   ui = user_id
  #   ci = checkout_session_id
  #
  def new
    Current.system_user = User.find(params["ui"])
    ss = Stripe::Service.new user: Current.get_user
    if ss.confirm_payment(params["ci"])
      redirect_to edit_tenant_url(Current.get_tenant), 
        success: t("payment_successfully_confirmed")
    else
      redirect_to edit_tenant_url(Current.get_tenant), 
        warning: t("payment_not_confirmed")
    end
  end
end

Done

That's about it actually – you'll want to keep stuff together (I keep stuff in a folder labeled 'services' and below that I have a 'stripe' folder with a class like this

class Stripe::Service < SaasService

  def payment_link url, price
    Stripe.api_key = settings["api_key"]
    pl = Stripe::PaymentLink.create({
      line_items: [
        {
          price: price.id,
          quantity: 1
        }
      ],
      after_completion: {
        type: "redirect",
        redirect: {
          url: url
        }
      }
    })
    return pl.url if pl.active
    false
  end
  
  def confirm_payment checkout_session_id
    Stripe.api_key = settings["api_key"]
    scs = Stripe::Checkout::Session.retrieve checkout_session_id
    if scs["payment_status"] == "paid"
      invoice = Stripe::Invoice.retrieve scs["invoice"]
      prod = Stripe::Product.retrieve(invoice
        .lines.data.first.pricing.price_details.product)
      if prod.present?
        case prod.name
        when /pro/; Current.get_tenant.update license: 3
        when /essential/; Current.get_tenant.update license: 2
        end
      end

      TenantMailer.with(tenant: Current.get_tenant, 
        user: Current.get_user, 
        recipient: Current.get_tenant.email, 
        invoice_pdf: invoice.invoice_pdf)
        .send_invoice.deliver_later
      Current.get_tenant.update license_changed_at: Time.current,
        license_expires_at: Time.at(invoice
          .lines.data.first.period.end).utc
      true
    else
      false
    end
  end

but that's just smoke and mirrors 😉 - the Stripe gem does all the heavy lifting, really!