Det er desværre tid til at svinge øksen over nogle af mine hobbyprojekter. Det er selvfølgelig hverken Handicapguiden.dk eller Fediverset.dk, der er tale om, men nogle lidt mere generelle projekter, der har lagt brak i op til 1 år.
Et gennemgående problem, for min hjerne i hvert fald, er at mine mange sideprojekter ligger i baghovedet og fylder, også selvom de er i dvale. Jeg ville gerne arbejde på dem allesammen og idégenererer derfor indimellem, selvom jeg ikke rører projekterne. Så for at fokusere, så må jeg mærke efter, hvad jeg brænder mest for, og rydde op.
Med tanke på, at der er særligt to projekter, der ligger langt væk i min bevidsthed, så er der to projekter på huggeblokken.
De to projekter, jeg tænker på, er hhv.
- Scriflow
- Untitled Spacegame
Jeg beskriver dem herunder, for det er ikke sikkert, at du har set mig nævne projekterne før - og det kan være, det kan tænde en gnist, så du får lyst til at udvikle noget lignende.
Scriflow (kodenavn)
Teknik: Go-backend og en React-frontend med FabricJS.
Et potentielt stort online DTP-projekt, inspireret af Scribus Open Source DTP-projektet, som jeg synes mangler en clouddel. Min tanke var, at f.eks foreninger og mindre virksomheder kunne bruge løsningen til at designe deres tryksager ganske gratis, og så kunne man bage en PDF som kunne downloades eller sende filen til tryk. Konceptuelt og teknisk synes jeg løsningen er spændende.
Jeg er ikke helt “ny” i forhold til at lave den slags: Tilbage i 2005-2006 lavede jeg to mindre, lignende løsninger for to lokale virksomheder, der havde behov for hhv. at printe labels og lave specialdesignede skilte. Løsningerne dengang bestod af en Adobe Flash-baseret frontend og ASP.NET-backend, så Scriflow ville være et naturligt step fremad imod et mere generelt produkt, baseret på moderne teknologier (heldigvis kan vi i dag undgå at kræve at folk skal installere bestemte browserplugins…).
Scriflow tog sin begyndelse, fordi jeg vil gerne hjælpe med minimere den byrde, det er at lave tryksager. Og med en webplatform, så er det nemmere for f.eks en forening at lave arbejdsdeling mellem to eller flere medlemmer, når designværktøjet blot kræver en browser.
Valget af sproget/platformen Go til backenden var lidt tosset, og valget skyldes nok mest min egen lyst til at arbejde med Go, for du skal have din egen server for at kunne afvikle det hele. Trods Python og Gos popularitet, så er der praktisk talt ingen danske webhosts, der beskæftiger sig med andet end PHP og Microsofts ASP.NET. Med tanke på knappe økonomi- og mandskabsressourcer i mange mindre foreninger, så ligger egen server nok ikke højt på ønskelisten. Ultimativt skulle jeg så selv hoste en server og evt. finde en bæredygtig forretningsmodel, men jeg kan bedst lide at udvikle, driften må andre godt tage sig af :-)
Jeg var sideløbende i gang med at definere rammerne for en PHP-backend API, men Go-backend’en trak mest, så jeg endte med at slette PHP-implementationen af serversiden ret hurtigt. Uklogt.
Prototypen kunne loade dele af en Scribus DTP-fil ind og præsenter basal indhold, men der var stadig en lang vej til et færdigt produkt. Særligt Scribus’ filformat er noget rod: Nogle XML-noder skrives med stort, andre med småt. Nodernes attributter er ikke altid beskrivende for, hvad de gør, så der var en del trial and error involveret, hvis jeg ikke kunne gætte det.
I bagklogsskabens lys skulle jeg have valgt definere mit eget interface udfra en generel datastruktur, og så føde data den vej. og så hhv. eksportere/importere Scribus-indhold o.a. ind i det format fremfor for at bruge Scribus’ filformat som “backbone”.
Det er generelt en god idé at basere sit dokumentformat på en ISO-standard, hvis man kan, fordi hjemmesnedkererede formater kan ændre sig med lynets hast, alt efter hvor bagudkompatibel projektet ønsker at være. Jeg lærte også noget der :) Fra et fugleperspektiv er filformater jo bare data med forskellige egenskaber. Jeg tror idéen med en generaliseret struktur kunne have virket.
“Om lidt” kan man givetvis compile Scribus til en WebAssembly-runtime (f.eks wasmer) og afvikle Scribus hvorend man har lyst, så der er faktisk ikke ret meget incitament til at forsætte med Scriflow i dens nuværende form. WebAssembly-platformens største akilleshæl er, at afviklingsmiljøet ikke understøtter multithreading, men det arbejdes der intenst på at få løst I sit corrected… WebAssembly Multithreading, se her.
Hvorfor ikke bare bruge Canva, spørger du måske?
Joh, Canva er da ultracool. Men der bør altid findes alternativer til globale cloud-produkter, så folk har noget at vælge imellem, hvis de vil noget andet. Og jeg mener self-hosting er et absolut must. Cloud-løsninger er fint som tilvalg, men vær opmærksom på, at de kan ændre pris- og produktvilkår med lynets hast. Hvis du bliver uenig med en udbyder af et Open Source-cloudprodukt har du altid muligheden for at hive dataene hjem og hoste løsningen selv.
Er du en del af en forening eller en lille virksomhed, så vil du gerne have at de produkter, du anvender ikke ændres grundlæggende over tid, og dermed tvinger dig til at ændre din arbejdsrutine. Der har Open Source en af sine forcer, fordi et projekt ikke nødvendigvis behøver følge industritrends. Når det så alligevel sker, sker det ofte med respekt for bagudkompatibiliteten.
Guleroden i Scriflow ville være et væsentligt simplere interface end tilfældet er i Scribus. Til gengæld ville Scriflow ovenpå en WASM-runtime betyde et konsekvent udviklingsmiljø, hvor man for det mest kan undgå at skulle “swappe” frem og tilbage mellem forskellige platforme, og jeg ville undgå at bygge til noget, der er et “moving target”. React vNext kunne i teorien se helt anderledes ud i morgen, end det gør i dag. Jeg priser mig lidt lykkelig for, at jeg ikke sprang på AngularJS sådan for alvor (v1 og v2 var vildt forskellige).
Jeg kiggede lidt på GIO til Go som GUI-lag, men var ikke helt tryg ved at skulle bruge et projekt, der ikke er nået v1.0 endnu. Selvom et projekt sagtens kan være stabilt allerede pre-1.0, så kan man i mange tilfælde godt forvente, at API’et ændrer sig fundamentalt undervejs.
Det er muligt, jeg bygger Scriflow igen i fremtiden, for jeg synes som sagt, at konceptet er spændende. Men så bliver det et bundkonservativt, homogent udviklingssetup. Da som før nævnt, at mange foreninger og mindre virksomheder vælger et simpelt PHP eller .NET-webhotel er det oplagt at bygge backenden på de platforme. Med et Docker-setup som muligt tilvalg til mere avancerede opsætninger/integrationer. Ah, ja - drømme er gratis.
Untitled Spacegame
Teknik: Godot, Rust/C-backend
Nok det projekt, der er nemmest at smide på blokken, for jeg mistede interessen helt og aldeles.
Jeg havde en idé til en Open Source spaceshooter a’ la Elite Dangerous, som man kunne spille både on- og offline. Problemet med moderne kommercielle spil såsom ED er, at de ofte kræver en server - og når udgiveren slukker den, så godnat, no more ED fun… Ift. ED så vil opensource-community’et nok stable en alternativ server på benene, som de gjorde med Star Wars: Galaxies. Men det kunne være fedt at skabe et community omkring en rigtig FOSS-spacesim, og ikke “en andens lukkede miljø”. Det er bare federe at have kildekoden, og derfra kunne udvikle spillet i forskellige retninger.
I forhold til en space shooter, må jeg nok sande, at jeg ikke aner en skid om 3D-grafik :-D. Jeg har selvfølgelig studeret emnet ret intenst, og har lavet lidt prototyper i Godot. Men jeg er efterhånden en halvgammel mand, og orker egentlig ikke at skulle kaste mig over et nyt område, og al den matematik, åh nej da… Hertil kommer, at jeg skal lære at 3D-modellere, hvis jeg skal lave nogle fede objekter såsom fly og planet-inventar. Måske kunne jeg få nogle interesserede til at bidrage henad vejen - men jeg vil heller ikke lege projektkoordinator, og vil langt hellere programmere. Bottomline, jeg lod mig nok rive med af idéen om et fedt slutprodukt i stedet for at overveje, hvad et sådan projekt egentlig kræver, hvis man pin’er det ud i detaljer.
Jeg synes egentlig, jeg havde afgrænset projektet fornuftigt ift. at kunne stable en prototype på benene: Lav en planet (Mars). Rendér Mars på baggrund af NASAs højdekort. Lav en mand/kvinde-model, der kan spankulere rundt. Byg en flymodel. Næste trin: Lav et univers. Jeg udforskede procedural generation, men tænkte det i vanlig Mass Effect-stil ville være bedre at holde antallet af planeter på et minimum. Elite Dangerous er en fænomenal spacesim, men føles stor og tom, fordi universet er gigantisk. Det fungerer godt på papiret, men ikke i et multiplayerspil. Til sidst: Smæk det hele sammen - i teorien forholdsvis simpelt, og så i praksis alligevel ikke… Skal man nogensinde gennemføre et projekt, så er afgrænsning nøglen, ellers kan du udvikle i 5 år uden at få noget udgivet (been there, done that). Jeg udvikler f.eks Handicapguiden i små ryk (iterationer), for ellers tror jeg, sitet havde gemt sig på min harddisk endnu.
Allerede her, kan det måske mærkes, at “Untitled Spacegame” var omfattende - jeg har allerede investeret en masse tid ift. at lære Godot at kende, og selvom jeg synes det er vildt cool, så må jeg begrænse mig. Der er så mange nye aspekter, jeg skulle lære, så mange forsøg.
I øvrigt kan du til enhver tid hente OoLite (open source) eller købe X4-serien (kommerciel closed source), hvis du skal have en solid spaceshooter, der fungerer offline. Online, ja - der kommer jeg lidt til kort, hvis jeg skal pege på en Open Source-løsning. Findes der overhovedet nogen? Skulle jeg bygge en OSS-variant, så ville den nok være inspireret af No Man Sky, for jeg synes designet og de afslappede hardwarekrav passer godt til lidt casual gaming.
Chop chop! Og så laserfokus. Jeg kan allerede nu afsløre, at jeg kommer til at brede Handicapguiden meget mere ud. Men mere om det, når der er noget at kigge på. Som en lille cliffhanger: Jeg brugte ordet hybrid-app under beskrivelsen af Scriflow, den sti har jeg tænkt mig at følge endnu mere. As always.. Stay tuned.