Code-for-fun som drivkraft

Hobbyprojekt

Jag har nu jobbat 27 år som utvecklare. Många i min ålder har bytt inriktning och släppt det där med att koda. Det kanske jag också borde göra? Men å andra sidan så är det ju så himla roligt! Jag kan fortfarande känna den där lyckokänslan när jag fattat något nytt eller gjort något riktigt snyggt. Men för att kunna behålla motivationen så har det varit viktigt för mig att odla min entusiasm. Det är ju inte alltid man får göra roliga saker på sitt kunduppdrag. Min lösning på det har varit att hålla på med en rad olika hobbyprojekt.

Det är då viktigt att det känns roligt och inte har några krav inbyggt, så jag utgår ofta från aktuell teknik som jag vill lära mig mer om. Under perioder då jag har ett litet ensidigt uppdrag på jobbet så blir hobbyprojekten en nödvändig ventil på kvällarna. Min fru gillar att lägga sig tidigt, så kl.22-01 har jag ofta ett bra fönster med ensamtid då jag hinner göra en hel del. Ett annat kriteria som jag har är att det ska vara en ganska konkret uppgift som åstadkommer något riktigt. Att bara göra halvfärdiga ToDo-listor med ny teknik blir snart alldeles för tråkigt. Det ska helst vara något som löser ett riktigt problem eller blir användbart som en färdig produkt.

Exempel på tidigare projekt

Genom åren har det blivit en del olika varianter som medvetet spänner över ganska olika områden:

• SchoolAdmin är ett komplett adminsystem för att stödja verksamheten i en F-9 grundskola. Elever, föräldrar, kölistor, betyg, etc. Det användes live i ca 10 år.
• SQLGenerator utgår från flera typer av datafiler och skapar automatiskt INSERT satser som kan appliceras på valfri databas. Vi hade ofta behov av det på mitt uppdrag och då blev det ett användbart verktyg.
• POCOParser läser av innehållet i en databas och skapar upp klasser i C# för att bygga kod. Det var användbart på den tiden då det inte fanns inbyggt stöd för det.
• Bokföring. När jag startade eget företag så kunde jag inget om bokföring. De program som fanns gjorde mig besvikna för de var rätt fula och svåra att använda. Att bygga ett eget system var ett bra sätt för mig att lära mig hur bokföring fungerar. Jag baserade det på de vanliga filformaten så att jag kunde utbyta information med min revisor. Alla typer av rapporter som man kan behöva fanns med: momsrapport, balansräkning, resultaträkning etc. Man kunde även läsa in alla transaktioner direkt från internetbanken och göra automatkontering av alla återkommande transaktioner.
• MyMovies. Jag gillar att titta på film och sparade på mig rätt mycket DVD. Det blev litet av en hobby så när vi i familjen ville se en film så kändes det bra att ha en sökbar databas. När det är filmkväll så kan alla i familjen lägga in sina önskemål och poängsätta litet olika förslag. Genom att koppla upp mig mot IMDB så kunde jag läsa ut bilder och metadata som vi sedan kunde bläddra igenom i lugn och ro. Jag har genom åren byggt om den med många tekniker och databastyper bara för att träna mig.
• ChurchWebAdmin har använts under 20 år i vår församling för att informera, hålla reda på ansvarslistor, etc.
• SongService är ett program där alla våra 10-15 musiker kan sitta hemma och söka bland drygt 1000 sånger. När de plockat ihop de sånger som de vill använda på en gudstjänst så blir de automatiskt tillgängliga på projektorn under gudstjänsten. För de personer som numera sitter hemma och deltar via Zoom så finns det nu även en mobilsida där de kan följa samma sånger.
• Teenstreet är en årlig konferens i Tyskland för 3000 ungdomar från hela Europa. Jag byggde ett bokningssystem som använts 3-4 år.
• RadioRecorder. När min pappa var gammal så hörde han att Sveriges Radio skulle sända hela serien med "Så ska det låta" vilket var hans favoritprogram på radio. De skulle sedan aldrig sändas igen eller exponeras i något arkiv. Han ville verkligen spara undan alla avsnitt och komma åt dem i efterhand. Då byggde jag en digital radiomottagare som automatiskt gick in varje vecka på rätt tid och sparade ner den strömmade sändningen till MP3 filer.
• GedcomToGraph. För några år sedan blev jag väldigt intresserad av grafdatabaser som har en unik förmåga att hålla många relationer mellan många objekt. Det kändes som en klockren teknik för släktforskning. Men släktforskning visade sig vara en ganska traditionell gren där man håller fast rätt hårt vid ett gammalt och mycket komplext teckenbaserat filformat. Jag bestämde mig för att försöka skapa en parser som läser ut data från GED filer till en struktur som kan tankas rakt in en modern grafdatabas som t.ex. Neo4j. Till min förvåning var det sedan ett företag i Utah, USA som hörde av sig och ville basera sitt nya system på mitt lib. De återkopplar nu regelbundet med ny input och förslag på lämpliga utökningar.

Schack

Denna gång valde jag som sagt att rikta in mig på att bygga ett schackspel med webteknik. Idén kom upp när jag fick frågan inför vår årliga konferens på Squeed som i år skulle vara 3 december. Kriterierna som jag ställde upp var följande:

• Webteknik för att det är så generellt och fungerar överallt.
• Blazor som plattform eftersom jag just nu är mycket förtjust i det och vill lära mig mer.
• Drag-and-drop för att det för mig är ett nytt sätt att hantera UX.
• Riktiga regler är önskvärt så att det inte blir för enkelt. Den ska gärna hålla koll på att man bara kan flytta sina pjäser till giltiga ställen.

Hur gick det

En av anledningarna att jag satte igång var för att jag hittade ett Nuget paket som gjorde att man kunde använda drag-and-drop direkt i Blazor. Men jag upptäckte snabbt att det blev onödigt krångligt. Efter att ha stångats en kväll med det paketet så tog jag ett steg tillbaka och läste istället på hur drag-and-drop fungerar i web. Det var förvånansvärt enkelt. Genom att göra allting själv kom jag framåt mycket fortare. Ikoner till pjäserna gick att hämta direkt från ett vanligt ikonbibliotek. Schackmotorn byggde jag i C#. Det tog litet tid men blev till slut inte så hemskt komplicerat ändå. Gränssnittet gick att separera ganska naturligt i fristående komponenter för bräde, rutor, pjäser, loggning, etc.
När jag jämför med andra websidor för schackspel så ser det ungefär likadant ut, så det kändes ju som en rätt bra bekräftelse.

Så här ser det ut i sin nuvarande form:

Vill man kolla koden så finns den på GitHub: https://github.com/jaklithn/Chess

Take-aways

• Code-for-fun som drivkraft ska inte underskattas
  Nu tog detta litet längre tid än vad jag trodde. Jag lade kanske 6-7 kvällar för att få allt att fungera. Hade jag inte haft stimulansen av att göra något riktigt till konferensen så hade jag säkert släppt det efter en kort demo på en timme. Nu tvingades jag att jobba igenom en del problem som gjorde att jag lärde mig det där lilla extra som ofta behövs för att komma hela vägen.
• Drag-and-drop är enklare än vad man tror
  Det är egentligen bara några event som man behöver implementera så är man igång. Det gav mersmak och kan säkert användas i många fler sammanhang.
• Schack är svårare än vad man tror
  Jag underskattade komplexiteten som behövdes för att skapa en fungerande schack-motor. Det var å andra sidan roligt och nyttigt.
• Våga vägra externa komponenter
  Jag kommer tillbaka till detta om och om igen. Det finns många bibliotek med UI komponenter som är väldigt kapabla att göra en massa saker. Det kan kännas lockande eftersom de är snygga och ger mycket funktionalitet out-of-the-box. Men i praktiken så skapar de nästan alltid mycket mer problem än vad de löser. De är stora och klumpiga och när man ska göra de justeringar man vill så blir det ofta väldigt ansträngt och komplicerat. Med enkel logik och vanlig HTML/CSS så kommer man fantastiskt långt och har fullständig kontroll på allt man vill göra.
• Blazor fortsätter att ge mersmak
  Det är verkligen befriande att kunna jobba transparent med ett högnivå-språk som C# för både backend och frontend.

Tänkbara utökningar

Man kan ju alltid göra saker bättre. Någon gång när jag får tid så kanske jag fortsätter att följa upp någon av följande spår:

• Deploya till en riktig server så att det kan bli publikt åtkomligt för alla.
• Snygga till med litet stylade element, typ färgtoningar och andra effekter.
• Om man skapar en backend som kan förmedla dragen så skulle man kunna ha spelare som sitter på olika platser och spelar mot varandra. Blazor WebAssembly hosting har redan integrerad websocket så att pusha ut ändringar till den andra klienten bör gå att åstadkomma ganska lätt.
• Man kan även tänka sig ett läge där man kan spela mot datorn. Jag har redan påbörjat det litet genom att datorn kan slumpa fram nästa drag. Genom att kolla av vilka drag som innebär att man tar en av motståndarens pjäser så kan man i alla fall få till ett drag som är hyggligt bra på kort sikt.