Nok en dag går mot slutten. De voksne har vært på jobb, de minste har vært i barnehagen. Middagen og kveldsmaten er spist og fordøyd. Tannpussen og eventyrlesing unnagjort. Da er det vel bare å krype til køys? Niks, ikke uten favorittkosedyret! Og hvor i alle dager har det blitt av, i dag igjen..

Høres det kjent ut? Dette var en del av den daglige rutinen hos oss i lang tid. Hver eneste kveld gikk med til leting etter favoritt-kosedyrene, og det ble ikke ro i huset før disse var funnet. Så, fremfor å irritere seg over problemet, bestemte vi oss for å heller prøve å løse det. La oss snakke litt om Apple Airtag.

Apple AirTag kom i 2021, og reklamerer med slagord som “Mist evnen til å miste ting”, og “superlett å holde styr på tingene dine”. Har du allerede iPhone, iPad eller Mac, og er i Apple-økosystemet, kan dette produktet være et fornuftig tillegg for å samle verdifull ting i “Hvor er?”-appen. Skulle du miste tingene dine utendørs, som har en AirTag festet på seg, så holder det at noen med iPhone, iPad eller Mac er i nærheten av det du mistet, og disse vil hjelpe deg med å lokalisere AirTagen. Du kan lese mer om AirTag på Apple sine egne hjemmesider.

Men, tilbake til det forsvunnede kosedyret. Vi skjønte raskt da vi ble foreldre at barn velger sine egne favoritter blant kosedyr, og at disse favorittene er uvurderlige. Så, vår første taktikk var å kjøpe inn flere av samme type, så kunne vi rullere hvis noen av dem ble borte.

Dessverre viser det seg at disse ikke er like. De ser veldig like, og oppleves kanskje som den samme, men spør du fireåringen er de helt forskjellige. Så, her må vi tydeligvis klare å skille ut den ene fra resten.

I stedet for å bruke hver eneste kveld på leteaksjoner og tårer i øyekrokene, kjøpte vi inn to AirTags som vi så sydde inn i favoritt-kosedyrene til ungene våre. 

Kosedyrene har nok fyllvatt til at en hard AirTag ikke merkes på utsiden, og batterilevetiden er såpass lang at man glemmer av at man har gjemt en liten dings inne i kosedyret.

Og resultatet? Helt fantastisk! I starten merket vi faktisk at vår eldste datter gjemte kosedyret litt ekstra, da det var så morsomt å kunne bruke telefonen og lyd for å finne det igjen. “Å nei, jeg har glemt hvor jeg la kosen i dag også..” sa hun med et smil om munnen, og da var det bare å begynne den målrettede skattejakten. Nå, noen måneder etter Operasjon Bamselege hvor vi sydde inn AirTags, bruker vi "Hvor er?"-appen bare når kosedyrene faktisk har forsvunnet og blitt lagt et lurt sted.

Hvor er kosen..?

Fra barndommens dager har jeg alltid vært drevet av nysgjerrighet og gleden ved å fikle og bygge ting. I denne bloggposten deler jeg min nostalgiske reise med å skape et laserprojektor-drevet Pong-spill. Og når du har en makerspace på Bekk som lekeplass, blir ingenting umulig. Bli med på en reise fra idé til ferdig produkt.

Jeg har alltid vært interessert i lyd og lys. Da jeg var 12 år brukte jeg sparepengene mine på å kjøpe røykmaskin, diskokule, strobelys og en laser spirograf. Jeg fikk miksebord til jul og rigget om kjellerstua hjemme til et diskotek. Jeg var et sånt barn som skrudde opp alt mulig for å undersøke hvordan det egentlig fungerte. Det gjør jeg fortsatt, også bygger jeg ting...

En ting som fasinerte meg spesielt, var laser spirografen. Den besto av en enkel mekanisme med en laser diode og to motorer med hvert sitt vinklede speil på enden. Laserstrålen var pekt slik at den gikk via de to snurrende speilene. Snurret et speil tegnet den en sirkel, og når begge speilene snurret ble resultatet mønstre likt det man får med en spirograf  på papir.


En spirograf er et geometrisk tegneverktøy bestående av en indre ring og tannhjul. Den brukes til å lage intrikate mønstre ved å føre en penn gjennom sporene mens man roterer tannhjulene.



Laserprosjektor sier du?

20 år senere snubler jeg over en bloggpost om hvordan man kan bygge sin egen laserprojektor.  Jeg tenker tilbake på diskoteket jeg bygde i kjelleren, og synes dette virker utrolig kult. Jeg bestemmer meg for at dette er noe jeg må prøve å lage selv.



Men hvordan fungerer det egentlig?

En laserprojektor kan tegne opp bilder og animasjoner ved hjelp av laserlys. Dette er mulig ved hjelp av to galvo-motorer som styrer hvert sitt lille speil. En Galvo-motor er en type motor som kan rotere svært raskt og nøyaktig til gitte posisjoner innenfor en begrenset vinkel. Motorene med speil står vinkelrett over hverandre, slik at det ene speilet vil flytte laserstrålen horisontalt langs x-aksen og det andre flytter strålen vertikalt langs y-aksen. 

Ved å bevege laserstrålen i x og y aksen i kombinasjon med å skru av og på laseren, er det mulig å tegne rette linjer mellom to punkter. En rimelig Galvo-motor er rangert i området rundt 20 Kilopulser per sekund. Det betyr at den i teorien skal kunne flytte laserstrålen til 20 000 forskjellige punkter i sekundet. Ved å tegne linjer mellom flere punkter, kan man lage strektegninger og animere disse.

Det trengs en del verktøy

I Bekk er vi så heldige at vi har vårt eget makerspace. På "Verkstedet" som det blir kalt, har vi flere forskjellige maskiner og verktøy. Det er 3D printer, laserkutter, CNC fres, utstyr for å lage elektronikk og mer. Dette passet perfekt nå som jeg skulle bygge min egen laserprojektor.



Hvordan bygger man egentlig en laserprosjektor?

Deler ble bestilt inn fra Aliexpress og satt sammen etter guiden jeg hadde funnet tidligere. Jeg brukte Fusion 360 til å teste og designe delene som trengtes til montering. Fusion 360 er et kraftig 3D CAD verktøy som gjør det mulig å modellere og analysere deler i 3D før produksjon. Når alt var ferdig designet produserte jeg de forskjellige komponentene ved hjelp av laserkutter og 3D-printer.



Noe for fagdagen?

Nå var laserprojektoren ferdig, men jeg følte at jeg måtte gjøre noe mer. Jeg bestemte meg for å melde inn en stand på den neste fagdagen i Bekk. Fagdagene arrangeres et par ganger i året, og er litt som en mini konferanse med talks, stands og sosialisering. Etter litt brainstorming landet jeg på at det hadde vært kult å lage dette som et laserspill som kunne stå fremme hele dagen.


Hva om jeg lagde et retro spill?  Laser Pong!!!!

Etter litt frem og tilbake bestemte jeg meg for å lage det ikoniske arkadespillet Pong. Atari som produserte spillet tidlig på 70-tallet laget det som et enkelt bordtennis simulering spill der to spillere styrer hver sin vertikale racket. En ball beveger seg frem og tilbake mellom spillerne, og hver spiller har en kontroll for å styre racketen sin opp og ned. Målet er å treffe ballen slik at den går forbi motstanderens racket og treffer bakveggen, når dette skjer får spilleren et poeng. Den som først når en forhåndsbestemt poengsum vinner spillet.







Spillkontroller var en utfordring

For å spille Pong trenger man en spillkontroller. Heldigvis hadde jeg flere deler liggende fra et tidligere havarert hobbyprosjekt. Første steg var å lage en prototype på papir. Det var viktig å finne et bra oppsett for knapper, lys og poengvisning. Jeg brukte et gratis online verktøy Boxes.py til å generere utkastet til kassen. Layouten til kontrolleren ble tegnet inn på lokket, og tilslutt laserkuttet jeg alt i sort mdf og plexiglass og monterte det sammen.

Både kontrollen og laserprojektoren er styrt av hver sin Arduino mikrokontroller. Kontrollen og projektoren kommuniserer ved å sende meldinger frem og tilbake via en vanlig hodetelefonkabel. Et problem når man lager elektronikk er at det ofte dukker opp feil, og gjerne i kombinasjon med bugs i koden. Hardwareproblemer har vist seg å være tidkrevende og vanskelig å finne ut av. Det ble mange sene kvelder med koding, feilsøking og hat, men til slutt hadde jeg endelig et fungerende Pong spill.

Jeg trenger vel et par spirografer?

Et par år tidligere hadde jeg startet på et prosjekt for å gjenskape laser spirograf fra barndommen. Dette passet veldig bra til Laser Pong spillet, og endelig fikk jeg det lille dyttet jeg trengte for å få denne ferdig.

Laser spirografen bygger på samme prinsipp som spirografen jeg hadde 20 år tidligere. Forskjellen er at min versjon også skulle ha et speilhode som lot den styre mønsteret rundt i rommet. Den er designet med samme fremgangsmåte som laser projektoren, men for å få alt til å fungere måtte jeg også lage et kretskort fra bunnen av. Jeg designet kretskortet i Eagle PCB og produserte det via DirtyPCB.

Jeg endte opp med å lage to laser spirografer. Spirografene er satt opp til å kommunisere med projektoren, og dette gjør at de kan reagere på hendelser i spillet. F.eks gjøre en spesiell lyseffekt når en spiller bommer.


Kommer det til å fungere?

Så var dagen kommet. Den siste ledningen ble loddet på plass kvelden før, og spillelisten med arkademusikk var klar. Jeg hadde fått et eget rom til å kjøre utstillingen, og mot alle odds fungerte alt som det skulle gjennom hele dagen. Det ble en stor suksess og Laser Pong var en realitet.



Lær deg noe nytt, bli selvbygger!

Jeg anbefaler alle som har en interesse for å bygge noe på egen hånd, om å bare kaste seg ut i det. Jeg kunne lite om elektronikk før jeg startet, men man lærer så utrolig mye av å bare prøve seg fram og løse problemene underveis. Det finnes enormt med bloggposter og guider på internett, og det er lett og billig å få tak i deler. Det finnes også flere tilgjengelige makerspace og biblioteker i de fletse større byer og her får du tilgang til maskiner som 3D printer og laserkutter. Følelsen av å lage noe fysisk som ender opp med å fungere sånn som man har tenkt. den er helt magisk.

Fra Laser- til mekanisk Pong!

Nå jobber jeg på et nytt hobbyprosjekt. Etter inspirasjon fra denne lager jeg en mekanisk versjon av Pong. Kanskje dukker det opp en artikkel om dette i neste års julekalender?









Laser PONG!

Løs sjakkoppgaver på Advent of Chess hver dag i advent, og få muligheten til å vinne et sjakkbrett signert av Magnus Carlsen!

Hva er Advent of Chess?

Mitt hobbyprosjekt er enda en julekalender! I Advent of Chess (med et navn sterkt inspirert av Advent of Code) får man én sjakkoppgave hver dag frem til julaften. Som i Advent of Code har man ett døgn på å løse hver oppgave, der løsningen blir publisert når det stenges for besvarelser. Jeg lager kalenderen for Offerspill sjakklubb, og vi kan derfor tilby et sjakkbrett signert av Magnus Carlsen som premie, der hver løste oppgave gir ett lodd i trekningen.

Bak hver luke gjemmer det seg ganske vanskelige sjakkoppgaver, men ingen vanlige sjakkoppgaver der man skal finne beste trekk. Dette for å unngå at man skal kunne jukse ved å bruke en sjakkmotor. Noen oppgaver er selvlagde, noen er nøye utvalgte fra gamle sjakkblader, og flere brukere har sendt inn forslag til sjakkoppgaver de har komponert selv (det høres kanskje pretensiøst ut, men man komponerer sjakkomposisjoner!). Til eksempel så er gårsdagens oppgave fra mars-utgaven av British Chess Magazine fra 1913!



Teknologi

Første versjon av kalenderen oppsto da jeg var med i Bekks kodehjørnet-faggruppe i 2020, en faggruppe der man jobber med egne hobbyprosjekter. Denne versjonen ble lagd som en en kjapp MVP med en React-frontend, Sanity for lagring av oppgavene, og Google Sheets (!) som database for å lagre besvarelser! Dette var ikke en veldig skalerbar løsning, men det funket i starten.

I år bestemte jeg meg for å skrive om nettsiden fra bunnen av. Dette var ikke bare for å forbedre brukeropplevelsen, men også for å tilrettelegge for en rekke funksjoner som skulle gjøre administrering av nettsiden, spesielt håndtering av besvarelser, enklere. Jeg forkastet den gamle kodebasen, og starte et nytt Remix-prosjekt med Tailwind til styling, SQLite med LiteFS som database, hostet på Fly. Kun Sanity ble beholdt. Oppgraderingen viste seg å være helt nødvendig, for antall brukere økte betydelig i år! Her følger et par av funksjonene som ble nødvendig å implementere med økningen i antall brukere.



Automatisk retting av svar

Tidligere måtte alle svarene, som er i fritekst og på ulike formater, rettes manuelt. Dette er en tidkrevende jobb, men det har gått fint tidligere. I år har derimot antall brukere, og dermed også besvarelser, økt såpass at jeg innså rundt 2. desember at jeg måtte få på plass automatisk retting av besvarelser, slik at jeg unngår å bruke hver kveld frem til julaften på manuell retting!

Løsningen ble å sjekke alle innsendte svar mot et regulært uttrykk (regex) som prøver å gjenkjenne riktige svar. Hver oppgave har forskjellige svar, så dette håndteres ved å lagre det regulære uttrykket sammen med oppgaven i Sanity. Dersom den ikke klarer å automatisk verifisere at besvarelsen er korrekt, sendes den til manuell retting. Det skjer heldigvis ikke så ofte lenger – mer enn 90% av svarene sendt inn i går ble rettet automatisk!

Mulighet for å sende inn svar på ny

Kalenderen tillater bare ett svar per oppgave. Dersom det første svaret man sender inn er feil, får man ikke gjort noe med det. Dette har også fungert greit tidligere år, men et annet problem som oppstod med økningen i antall brukere, er at det skal veldig lite til for at én bruker feiltolker en detalj i oppgaveformuleringen, og derfor sender inn feil svar på grunn av det. Jeg trengte en måte å nullstille feil svar dersom det skyldtes at jeg hadde formulert oppgaven unøyaktig. Jeg implementerte derfor muligheten for å nullstille en besvarelse, samtidig som det sendes ut en e-post til brukeren om at formuleringen er endret og de kan prøve på ny.


Det var også flere brukere som spurte om de kunne endre besvarelsen mens den hadde status PENDING, altså mens den venter på manuell retting. Dette fikk jeg også nylig på plass, noe som har hjulpet på å få ned antall henvendelser.



Stjerne til de 10 første!

Alle nye funksjoner har ikke strengt tatt vært nødvendige. Jeg vet for eksempel ikke hvor lurt det var å gi de 10 første som løser hver oppgave en stjerne ved siden av brukernavnet sitt på ledertavlen. Etter dette ble implementert, har det ikke tatt mer enn rundt 4 minutter for topp 10-listen å fylles hver dag, og rundt 200 brukere ser ut til å holde seg våkne til midnatt for å ta fatt på den nye oppgaven med en gang den blir publisert.







Status

Til nå i år har Advent of Chess hatt over 25,000 unike besøkende, 76,000 sidevisninger, 1920 registrerte brukere, og 8167 innsendte besvarelser. Vi i Offerspill sjakklubb opprettet en Discord-kanal for å ta i mot tilbakemeldinger, og der har det vært fullt kjør hele desember.

Og det er selvfølgelig ikke for sent å delta. Lag deg en konto på Advent of Chess og prøv deg på dagens oppgave, så kan du være med i trekningen av et sjakkbrett signert av Magnus Carlsen!

Hobbyprosjekt: Advent of Chess

Norway is known for its fjords, glaciers and cold winters. The latter is suboptimal for cyclists, which is why we ended up creating dundring.com; a free and open source in-browser training application created to control and track your training with a smart bike trainer ⚡️

This article will go through the magical story of how our hobby project dundring.com was made 🎅

Norwegian weather and cycling during the winter

Cycling during the winter in subzero temperatures and snow is something only a fraction of the Norwegian cyclists endure. Most of us take our cycling sessions indoors with a bike trainer, which can be thought of as a treadmill for bikes. However, working out indoors on a bike trainer can be monotonous and feels harder than riding outdoors, which may tempt you to join the ranks of the tough winter cyclists. 

Fortunately, there are applications that strive to make this experience as bearable as possible, such as Zwift, the leading bike trainer software.

Zwift is a massively multiplayer online cycling and running physical training program that enables users to interact, train, and compete in a virtual world. - Wikipedia

Zwift has many great features, and it's really fun to see a 3D version of yourself cycling in the virtual world, especially when you are able to overtake lots of other virtual cyclists. 

As we were using Zwift, we realized that we did not really use the killer features of Zwift; the massive living world, group rides and races. We were mostly using Zwift to control the pedaling resistance over time, and were not really looking at anything else than the real time numbers such as Watt, heart rate and elapsed time. 

This sparked a question; why can't we create our own bike trainer app using Web Bluetooth?

Creating a minimum viable product

After experimenting with Web Bluetooth for reading heart rate data, the next step was being able to control the bike trainer. One thing was reading the power data, but actually being able to send commands to the device was not straight forward for someone new to Web Bluetooth. 

Combining data from a heart rate monitor with power data from a bike trainer with some nice graphs, and some power controls, resulted in our first minimum viable product of dundring.com.

Workouts don't create themselves

The ability to create custom workouts is a fundamental feature of any cycling trainer app.

Every workout in dundring.com is built around ERG mode, a setting on smart trainers that automatically adjusts resistance to match your cadence, essentially turning the bike trainer into a "cycling treadmill".

The workout editor on dundring.com allows you to predefine the resistance for different stages of a workout. This feature is ideal for creating interval sessions with varying power intensity and for easier rides with consistent and low intensity.

As shown in the current interface of the workout editor, a workout is a sequence of time intervals, each with a targeted power output, measured in watts and percentages.

But what do these percentages represent?

They are calculated as a percentage of your Functional Threshold Power (FTP). FTP is essentially the average power you can sustain for one hour. In the cycling community, it's common to base power targets on this metric. Using percentages of FTP, rather than fixed numbers, makes the workouts adaptable and applicable to every cyclist. The workouts automatically adjust to the rider's current level by scaling based on their FTP. This is handy when sharing workouts with your friends, which dundring.com allows you to do.

In addition to the workout editor, dundring.com also offers a library of workouts you can use out of the box, or use as template for your own custom workouts.

You didn't workout if it isn't on Strava

In the cycling community, there's a popular saying: "If it's not on Strava, it didn't happen". Recognizing this, we've made it possible for users to upload their rides from dundring.com to Strava. Our current approach allows users to export and download their session data, which includes data about laps, heart rate, power, cadence and simulated gps points based on estimated speed and distance.

The speed and distance are estimated based on the rider's current power output, using approximations for factors like gravity, rolling resistance, and aerodynamic drag. For those interested in the specifics, the full formula is available here: Cycling Wattage Calculator.

Group sessions

One of the primary reasons people ride bikes is to enjoy group rides with friends in the sun. Even though the weather might not be on our side during the winter, it might still be nice to be able to ride together. This led us to implement a group session feature, allowing users to create a live group for others to join. Everyone in the group are able to see each other's live data. 

Tech stack

For the nerds, dundring.com is written in TypeScript. The frontend is React using Chakra UI components, the backend is Node using Express and also Prisma as an ORM connected to a Postgres database. The project is structured as a monorepo using Yarn Workspaces with Turborepo 🤓

Where is dundring.com headed?

Our goal with dundring.com is to have an easy to use and lightweight application with all the necessary features needed to make the indoor cycling season alright. It also serves as a playground where we can explore new ways of indoor training, potentially making the winter a bit less unbearable for cyclists in colder parts of the world. ☃️



Try the app at dundring.com or check out the source code on GitHub! 🤠

If you want to contribute or have any questions, head over to the dundring.com Slack workspace 🤓

Surviving the Norwegian winter as a cyclist with dundring.com

Det er lite som er like inspirerende som å kunne løse sine egne problemer med teknologi! Les om hvordan jeg, som ivrig toppturentusiast, har tilgjengeliggjort snøskredvarselet fra varsom.no som app til Garmin-klokker.

Når vinteren kommer, og det endelig kommer snø i fjellene, drar jeg på tur. Aller helst med toppturski på beina. Og når man går på topptur er det veldig lurt å ha kontroll på skredvarselet! NVE publiserer daglige skredvarsler for de fleste regioner i Norge mellom mellom 1. desember og 31. mai årlig på varsom.no, og disse varslene kan være livsviktig informasjon som bidrar både i turplanlegging, og til å ta trygge valg underveis på turen.

Inspirasjon 💡

Varsom tilbyr allerede apper for å lese skredvarselet på mobilen, men når eks-kollega Jonas Follesø lagde en app for å vise skredvarselet på Apple Watch, fikk jeg inspirasjon til å lage en app for Garmin også, siden jeg har vært fan av Garmin sine klokker helt siden jeg kjøpte min første fēnix for mange år siden.

Jeg hadde også flere ganger irritert meg over at Varsom sin iOS-app ikke synkroniserer varselet offline til telefonen. Det gjør at det er litt vanskelig å sjekke varselet ute i felt eller på parkeringen, hvis man skulle ha glemt å sjekke det før man drar hjemmefra. Derfor var en av hovedprioriteringene for appen min at varselet skulle synkroniseres til klokka, slik at man kunne få lest det også uten internett.

Monkey C, monkey do 🐒

Da jeg startet på prosjektet hadde jeg ingen tidligere erfaring med klokkeprogrammering av noe slag, og da iallefall ikke Garmin sitt økosystem. Det ble derfor tidlig klart at prosjektet kom til å ha en relativt bratt læringskurve. 

For å programmere apper til klokkene tilbyr Garmin en SDK som benytter et hjemmesnekra programmeringsspråk som heter Monkey C 🐵. Monkey C er litt som om Javascript og Java fikk et barn sammen, så heldigvis føles språket relativt kjent hvis man har programmert med noen av de før. Visual Studio Code er den anbefalte IDEen å bruke, og Garmin har en offisiell plug-in som anbefales brukt til utvikling. Totalt sett har det gått veldig greit å komme i gang med, bortsett fra to ting: Minne og skjermplass.

Minne 💾

I tillegg til utfordringene med programmeringsspråk og SDK, ble det også ganske raskt klart at et av hovedproblemene med å få appen til å kjøre, kom til å være tilgjengelig minne på klokkene. Jeg ønsket å støtte så mange klokker som mulig når jeg først var i gang, og ble da raskt klar over at mange av de litt eldre klokkene har særdeles begrenset minnekapasitet. Noen klokker har så lite som 20kb(!) tilgjengelig minne når appen kjører. 

Så på grunn av dette ble det raskt klart at jeg ble nødt til å skrive et proxy-API mellom Varsom sitt API og klokkene, slik at klokkene ikke gikk tom for minne når de spurte Varsom om skredvarselet. I tillegg måtte appen tilpasses relativt grundig slik at jeg ikke gjorde for mye fancy greier samtidig, og gikk tom for minne 💥. 

Det var egentlig ganske artig å forholde seg til at man har en minnebegrensning, siden det er sjeldent man tenker på minnekostnaden av programmeringen man driver med i det daglige.

Skjermplass ⌚️

En annen interessant problemstilling når man jobber med klokke som flate, er mengden tilgjengelig skjermplass. I det daglige er jeg vant med å å jobbe på vesentlig større flater, og jeg trenger egentlig aldri å tenke på om det jeg vil vise får plass på skjermen eller ikke. På klokker er det helt motsatt: Man har nesten ingen plass til å vise den informasjonen man vil.

Et skredvarsel består av flere deler. Det viktigste er selvsagt selve faregraden, som går fra 1 til 5, samt en beskrivende tekst. Men det er også en annen veldig viktig del av varselet: Aktuelle skredproblemer.

Skredproblemene for et gitt varsel sier noe mer spesifikt om hvilke farer som befinner seg i fjellet. Hvilke himmelretninger er farlige, hva slags type skred er forventet, og hvor høyt eller lavt må man befinne seg for å være i faresonen. Det var viktig for meg å få med disse skredproblemene inn i appen når jeg først skulle vise skredvarselet på klokka, og jeg ble derfor nødt til å legge inn en stor innsats for å få vist en oppsummering av skredproblemene uten at all skjermplass ble brukt opp.

Betaling 💸

Når jeg først måtte etablere en backend for å kunne støtte appen, bestemte jeg meg for at jeg ville ta litt betalt dersom den skulle ut til massene, slik at jeg kunne få dekket serverkostnader og litt til uten å gå i minus. Jeg endte derfor med en sum på 30kr per år for å bruke appen. 

I motsetning til Apple og Google, tilbyr ikke Garmin noen direkte måte å ta betalt for apper på i sin app store, så det må man ordne selv.

Jeg hadde ingen erfaring med integrering mot betalingsløsninger, men Vipps virket som et naturlig alternativ, siden omtrent alle har det, og det er veldig enkelt for brukere å gjennomføre betalinger. Jeg integrerte derfor med Vipps som betalingsløsning, og i høst har jeg også integrert med Stripe, slik at også folk som ikke har Vipps kan få skaffet seg appen.

Backend ⚙️

Appen består av to deler: Selve klokke-appen, og en backend som ligger på skredvarsel.app. Backenden fungerer som API for klokka og frontend for betaling av abonnement.

Backenden er skrevet i .NET, med PostgreSQL som database, og Hangfire for å kjøre periodiske jobber for å synkronisere mot Vipps. Frontendløsningen er en veldig enkel React/Vite-app, som bruker Chakra UI som komponentbibliotek. Backenden integrerer med Vipps Recurring og Stripe Subscriptions for å gjennomføre betalinger, og man kan logge inn med Vipps, Google eller Facebook.

Ønsket mitt når jeg lagde backenden var å bruke flest mulig kjente teknologier, siden jeg allerede hadde mer enn nok med å lære meg Garmin SDKen og Monkey C for å lage klokkeappen.

Både appen og backenden er åpen kildekode, og kildekoden kan finnes på GitHub.

Status 🏔️

Jeg begynte å jobbe med appen i februar 2023, og satte meg et mål om å prøve å få lansert før skisesongen var over. I starten av april fikk jeg ut første versjon, og etter litt blæsting på diverse Facebook-grupper for toppturer, fikk jeg raskt mine første brukere. Jeg var også så heldig å få en artikkel om appen min i Fri Flyt, noe som virkelig satte fart på nedlastingene. 

Jeg har lært masse om både klokkeprogrammering, små skjermer, minneoptimalisering, og integrasjon med betalingsløsninger. Alt i alt har det sålangt vært et veldig givende prosjekt, og det har gitt meg kunnskap som jeg allerede har fått bruk for i jobbsammenheng.

I tillegg til å kontinuerlig støtte nye klokker, har jeg i fremtiden planer om å få inn støtte for å automatisk velge region basert på GPS-posisjonen til klokken, samt støtte planlagte endringer som Varsom innfører rundt skredvarslingsregioner i 2024/2025 sesongen.

I skrivende stund har appen litt over 500 brukere, og ser ut til å fungere fint for de aller fleste. Den støtter omtrent alle Garmin-klokker som er lansert de siste 5 årene, og henter automatisk skredvarselet hver time hele vinteren. Så hvis du skal på topptur i vinter, ta en titt da vel?

Du finner mer informasjon her ➡️ skredvarsel.app

Skredvarsel for Garmin ⛷️⌚️

Pull request, backlog, Kotlin og Kafka...

Hva betyr ordene, og hvorfor har utviklere så vanskelig med å snakke så alle forstår? Hobbyprosjektet Teknisk ordbok prøver å gjøre hverdagen litt lettere for ikke-teknologene i teamet ditt.

Hva er Teknisk ordbok?

Teknisk ordbok er en liten nettside som har som mål å gjøre hverdagen litt enklere for ikke-teknologer. Mange team i dag er kryssfunksjonelle, det vil si at man har utviklere, jurister, produktledere, teamledere og designere i samme team. Alle disse rollene skal jobbe godt sammen og til det må man kommunisere med et språk som alle forstår.

Uheldigvis kommer man ikke alltid unna å bruke tekniske begreper når man skal forklare en problemstilling, spesielt hvis flertallet av et møte består av utviklere. Teknisk ordbok er derfor et forsøk på å forklare en del av disse tekniske begrepene utviklere bruker på en enkel måte.

Motivasjon og inspirasjon

Motivasjon og inspirasjon til løsningen kom når min kone gikk fra en lederstilling i en del av bedriften og over i en produktlederrolle som plutselig skulle jobbe i et team med utviklere. 

Hun fortalte ofte at hun var helt utslitt av lange møter der utviklerne snakket over hodet på henne. Hun sendte meg ofte spørsmål som hva betyr event-drevet arkitektur eller hva er webhooks? 

Siden problemløsing er en stor del av min jobb som utvikler tenkte jeg at det måtte være en måte å samle alle disse ordene. Jeg har selv erfart ikke-teknologer i møter som nikker som om de forstår alt som blir sagt, bare for å si etter møte at det ikke var alt de forsto. 

Tech-stack

Nettsiden er skrevet i Typescript og med rammeverket Remix. Intensjonen har vært å holde kompleksiteten på et minimum, så her finnes ingen database, bare en hardkodet typescript-fil med et Javascript-objekt som holder på alle ordene og beskrivelsene som er lagt inn. Styling gjøres via Tailwind.



Innholdet er i stor grad "skrevet" av ChatGPT 3.5. Jeg har gitt ChatGPT et prompt og matet ChatGPT med tekniske ord. ChatGPT har så returnert en ikke-teknisk forklaring på ordet som jeg så har lagt inn i det hardkodete objektet.

Status

Status på løsningen er at det finnes mange ord der som forhåpentligvis har enkle forklaringer. I tillegg finnes det noen scenarioer som er forklart på en ikke-teknisk måte. For eksempel, hvordan integrere mot andre tjenester, hva er testdrevet utvikling?, og andre spørsmål.

Jeg legger inn nye ord i løsningen etter hvert som jeg selv hører tekniske ord vi bruker i møter. I tillegg har jeg en liste med ting som hadde vært kult å implementere på sikt.



Oppsummert

Vi som teknologer har et særlig ansvar når vi snakker i møter. Vi bør etterstrebe å gjøre oss forstått på en måte så alle i møtet forstår oss, men vi kommer ikke alltid unna å bruke tekniske ord og uttrykk. Hobbyprosjektet mitt, Teknisk ordbok har som mål å ta ned barrieren mellom teknologer og ikke-teknologer. 

Så om du kjenner noen som kunne hatt nytte av å lære seg noen nye ord, så er det bare å like og dele som ungdommen sier! 



Her finner du løsningen Teknisk ordbok



Hobbyprosjekt: Teknisk ordbok for ikke-teknologer

Ahh, synthesizers, the modern marvels of music creation. Loved or hated, but never ignored. What makes them tick? I’m on a journey to find out, building an analog synthesizer from scratch.

I’ve always been incredibly fascinated by synthesizers. Growing up in the 80s and early 90s, the first golden age of the synth, I used to play air synth when others played air guitar. My interest however, goes deeper than playing. I always wanted to know what made a synth do what it does, so what better way to find out than building one myself?

I started with very basic electronics years ago. I built my first midi controller in 2004, around the same time I started collecting synthesizers. I built a TB-303 and a TR-909 clone, and got into making modular synth modules, etching my own circuit boards and hand soldering everything. All the time though, I had a greater goal in mind. I wanted to build a full size, polyphonic keyboard synthesizer.




But what is a synthesizer?

A synthesizer is a general term describing a device that makes sound. It may be a physical instrument or it could be completely virtual, running as software on a computer. It can have an attached keyboard or it can be controlled by other means. It can make sounds tuned to a specific musical scale or just abstract sounds and noises. And finally, it may be digital, using some sort of computer or microcontroller to generate sound, it may be analog and use the flow of electricity through electronic components, or it can be a mix of digital and analog.



Building the beast

Every sub genre of synth has its dedicated following, and as with all fields where people are passionate about what they do, there is a lot of friendly fighting between the supporters of each type. Coming from an engineering background, I tend to think that whatever gets the job done without sacrificing the essentials is a good choice.

There are many directions to take a project like this, so I started with a list of requirements. When finished, my synth:

Plays notes, it can be used for playing melodies and chords. None of that droning nonsense

Is polyphonic, it can play multiple notes at the same time, because chords

Is multi-timbral, meaning that the same instrument can generate multiple different sounds at the same time

Has a keyboard and an extensive physical user interface where most of the functions are directly available, essentially “one knob - one function”.

Is computer controlled but generates the sounds using analog electronics, because nothing beats the sound of electrons flowing through a transistor.

Is physical, because where’s the fun in software, right? Right.

Is professionally built and looks smashing!

…and sounds great too. Let’s not forget that.



Now, those are some ambitious requirements. I’ll try to break them down a bit to show what is actually going on.

Analog circuits

At the heart of the synth sits the analog voice cards. I use electronic components - resistors, capacitors, op amps, transistors etc - to shape an electrical current into sound. In general, everything that touches the sound wave, from its source - oscillators that generate a pitched sound wave - through mixers and filters that shape the wave and remove or accentuate frequencies - is analog. I either design these circuits myself, or copy them from old synthesizer service manuals. I’ve spent countless hours studying the theory behind the circuits to be able to modify them.

Each voice card is capable of generating a single note at any time, so to get polyphony multiple voice cards are needed. I aim for 16 notes of polyphony, meaning every circuit has to be repeated 16 times.



My process of designing circuits usually begins with simulating the circuit in LT Spice, a free electronics simulator. I then breadboard the simulated circuit to see how it performs in real life, before entering the schematics into Eagle PCB*, a schematics capture and circuit board layout tool where I also design the circuit board. Finally, the circuit boards are produced and populated with parts by JLCPCB in China.

* I use Eagle as it was the only simple option available when I started designing circuits. Today I would have chosen to learn KiCad instead.





Control circuits

While the sound generating circuitry is analog, it needs something to control it. To be feasible, a polyphonic synthesizer uses digital control, and the easiest way to do this is to use microcontrollers.

When I started playing around with microcontrollers there was no Arduino, not a lot of available libraries to help out, and the microcontrollers were slow and 8 bit, running at 16MHz. Luckily the world has caught up, and now we can use the Teensy 4.x controllers and the full Arduino suite of tools and libraries. The Teensy is 32 bit, runs at 600MHz and can reach an effective throughput of around 1GHz.



In my system, I use one Teensy per voice card. It is responsible for generating 64 control voltages with a 12kHz refresh rate, and does this using a four channel 16 bit DAC that is time-multiplexed through 64 sample-and-hold circuits. The voltages control things like oscillator pitch, amplifier volumes, filter cutoff frequency and resonance and all kinds of modulation. Envelopes and LFOs are digitally generated, which to some analog purists is a death sin, but it simply opens up so many possibilities that I found it the only sane option.

I have not found the ultimate tools for doing microcontroller development yet. At the moment I do most of the coding in IntelliJ, simply because that’s the IDE that I know best, though it sucks as a C/C++ editor. I do compilation through the Teensyduino editor as it has a serial monitor where I can get feedback from the microcontroller. I know there are better options out there but I have not prioritized learning them yet.

UI

The synth needs a way for the user to control it, and one of the main motivations for making my own synth in the first place was to have a very hands-on interface. I have physical knobs and buttons for almost all functions, so no menu diving is needed to find controls.

As a synth needs to be able to store and recall various sounds - patches - we quickly run into a major issue with the UI. We need the knobs to reflect whatever setting that parameter currently has. If we use normal potentiometers, these will not be at the correct position when a patch is loaded. To solve this, I’m using a ring of LEDs around the potentiometer indicating its current position, and endless potentiometers that do not have defined start and stop positions.



Getting a physical UI right is a hard task. At the same time the UI is the most expensive part of a synthesizer, so proper prototyping is essential. I’ve solved this by making a working UI as a web app. I use React-controlled SVGs for the front panel as that lets me use precise units, meaning what you see on screen is what you get on the panel. The web app communicates with the microcontrollers through WebMIDI.

Changing the layout of the web app is of course much simpler than rearranging a physical UI. It is however essential to make physical prototypes along the way to get a feel of the spacing and size of things. I’m lucky enough to have access to an Epilog laser cutter at the Bekk workshop, so I cut test panels from MDF. Also, playing around with different potentiometers and buttons to get the feel of everything juuust right is a lot of fun!



Physical design is mostly done in Fusion 360, and the final production will be partially on the Bekk CNC machine and partially using online services such as eMachineShop and Front Panel Designer/Schaeffer-AG

GUI

While the one knob - one function principle works great for most things, there are some that benefit from having a screen. I have included a high res 9 inch multitouch screen at the center of the UI. This lets us see the envelope shape, do advanced LFO and arpeggiator settings, route modulation in a modulation matrix, and of course do any kind of configuration as well as patch storage operations.



The GUI is a React app with a node backend, currently running on a Raspberry PI and communicating with the Teensy microcontrollers over SPI.

An added benefit of having the UI prototype as a web app is that I can develop the UI and the GUI at the same time, in the same app. The GUI on the synth then becomes a subset of the prototype app.

State of this madness

Where am I at right now? I have completed almost all research, and made physical circuit boards for most functions. Five new boards are sent to production this week, and I have everything hooked up on a huge breadboard.



Before I design the final voice card I need to verify my architecture with people that actually play synths to see if my ideas make sense in the real world. Once that’s finished, I’ll start assembling multiple voice cards into a polyphonic synth, still with a virtual UI. Only then will I commit to the final layout and start producing the physical control surfaces.

My passion project

I’ve come to realize that my project is so huge that I will probably only do this once, which means I need to do it properly. It will take a long time to complete, and from the start I’ve talked about it as my ten year project. I’m now in my eight year and still going strong - and I’ve learned so much and had so much fun along the way!

To me, that is the essence of everything. The process and journey in itself is what’s important. The dream of building something great is inspiring, but without partial goals and small successes along the way it would be impossible to stay motivated.

So, will I manage to finish this within my original 10 year time frame? Probably not, especially not the control surfaces, and I’m a bit more stressed out by this than I’d like to admit. I will however definitely have a working, playable, polyphonic, multitimbral, analog-digital hybrid instrument, and that’s awesome!




PS: I love talking synth, especially hardware, so feel free to contact me. I have a blog documenting everything I do at http://atosynth.blogspot.com, and while it is written mostly to document things for myself it may be of some interest to other very nerdy people out there too!

Hobby project: Synthesizer

Hils på OPRA - et hobbyprosjekt som gir bedre kjøpekraft til folk som jobber i operative yrker.

Hobbyprosjekter er en utrolig fin måte å lære seg produktutvikling på for utviklere. Ikke bare lar det oss ta fullt ansvar for selve produktet, men man blir tvunget til å ta stilling til ting som vekst, sluttbrukere og tilbakemeldinger. Også er det veldig gøy da, det skal sies.

Jeg har – sammen med et par andre venner – jobbet med et hobbyprosjekt som vi kaller OPRA – kort for Operativ Rabatt. Det er en tjeneste som fremforhandler og tilgjengeliggjør ekstra gode rabatter for en kritisk del av samfunnet vårt – operative.

Om “operativt personell” er et nytt uttrykk for deg, så er det helt okei. Operativt personell er folk som jobber i forsvaret, politiet, brannvesenet og ambulansetjenesten. Det er folk i den frivillige redningstjenesten. Det er rett og slett folk som gjør en helt fantastisk og kjempeviktig jobb for samfunnet, slik at oss andre kan sove trygt om natten.

Ulempen med å jobbe i mange av disse yrkene er at de er veldig dårlig betalt i forhold til innsatsen – og risikoen – som legges inn. Derfor tenkte vi at å øke kjøpekraften deres, gjennom gode rabatter på ting man trenger, var en fantastisk måte å gjøre de yrkene mer attraktive for de beste folka blant oss.

Hva er OPRA

OPRA er en nettside (og snart en app) som gjør det enkelt å finne og bruke en rekke forskjellige rabatter. Vi fremforhandler rabattene selv med møter med forskjellige bedrifter, eller så får vi tilgang til rabatter gjennom såkalte affilatenettverk vi samarbeider med. Den forhandlingen går overraskende enkelt – folk er nemlig veldig villige til å strekke seg litt lenger for å tilby tjenestene og varene sine til denne brukergruppen.

Per i dag har vi over 100 rabatter som folk kan bruke. Og det er ikke bare tullerabatter heller – vi snakker alt mellom 10 til 40 prosent rabatt på kjente merkevarer! Og det hjelper på bunnlinja i familier som ellers kanskje ikke kan påspandere seg altfor mye.

For å bli medlem må du laste opp et bevis på at du er kvalifisert for å delta i OPRA. Teamet undersøker dokumentasjonen som lastes opp, og så godkjenner vi (eller en sjelden gang underkjenner) søknaden. Så er du logget inn og har tilgang til kjempegode rabatter – helt gratis.

Hvordan vi jobber

OPRA er drevet av meg, Eric og Sissel – to som jobber i nettopp disse operative yrkene. Eric er helikopterpilot for redningstjenesten i Stavanger, og Sissel jobber på AMK-sentralen (de som tar telefonen når du ringer 112). Sammen er vi en skikkelig fin gjeng som har fått til dette med arbeidsfordeing.

Eric og Sissel fremforhandler rabatter, og jobber aktivt ut mot interesseorganisasjoner som fagforbund og arbeidsgivere for å onboarde nye brukere. Jeg utvikler løsningene våre, og passer på at alle. Og sammen godkjenner vi brukere, svarer på henvendelser og tenker ut strategi for både å vokse, ekspandere til nye markeder og lage det beste produktet vi kan.

Arbeidet tar endel tid, men ikke mer enn at det passer inn i en hektisk hverdag, med både jobb, familie og fritidsaktiviteter. Vi har lagt stor vekt på at vi skal ha det gøy med dette prosjektet, og at det ikke skal spise mer av fritiden vår enn vi er komfortable med.

Penger og sånn

OPRA har hatt to forskjellige forretningsmodeller opp gjennom. Da vi startet kostet det 30 kroner måneden å være medlem. Det dekket alle utgiftene våre, og ga oss et lite overskudd. Det overskuddet brukte vi til å dele ut det vi kalte OPRAs takknemlighetspris. Denne prisen består av en statuett vi har laget, samt 25.000 kroner. Den blir delt ut et par ganger i året til nominerte operative som har gjort en ekstraordinær innsats. Du kan lese mer om hvem som har vunnet her.

Målet med OPRA var ikke å tjene masse penger, men å tilby bedre kjøpekraft til folk som fortjener det. Derfor gikk vi i år vekk fra en betalt modell, og over til å tilby denne tjenesten gratis ut mot sluttbrukerne. Istedenfor tjener vi penger gjennom såkalte affiliate-avtaler, der vi får betalt noen prosent av hva brukerne våre bruker penger på. Kjøper noen en TV for 5000 kroner, tjener vi for eksempel 150 kroner.

Det skal sies at betalingsmodellen vår var ganske mye mer innbringende enn denne affiliate-løsningen, men det betaler fortsatt nok til at vi kan dekke kostnadene våre, og spare opp litt penger til OPRAs takknemlighetsfond. Og om vi blir skikkelig populære en dag, kan det jo hende at det blir litt penger igjen til oss som bruker fritiden vår på det her.

Teknologi, da?

OPRA består av to tjenester – opra.no og en (straks ferdigstilt) mobilapp.

OPRA.no er basert på Next.js, Chakra UI og Firebase. Disse tre teknologiene ble valgt rett og slett fordi det var de teknologiene jeg kunne best da jeg startet arbeidet, og vi hadde et stort behov for å få noe ut til brukerne våre raskest mulig. Det har vist seg å være gode valg vi fortsatt er komfortable med i dag – selv om det innfører noen begrensninger man ellers ikke ville hatt.

Appen vi jobber med nå er basert på React Native og Firebase, og er i stor grad en mobil-implementering av det samme vi har på nettsiden vår – pluss noen ekstra features som push-varsler og andre finurligheter.

Status

Status per i dag er at OPRA er en høyt elsket organisasjon blant operative. Vi har over 17.000 aktive medlemmer, med over 30.000 sidevisninger hver eneste måned. Vi har avtaler med en rekke forskjellige interesseorganisasjoner og får massevis av henvendelser fra folk som ønsker å tilby rabatter til folka våre.

Vi har planer om å ekspandere til andre land også – men det tar vi som et mål for 2024. Det haster liksom ikke altfor mye heller, men det er jo gøyalt å legge strategier for.

Om du kjenner noen som jobber i operative yrker, så kan du jo tipse dem om OPRA – kanskje de ikke har hørt om oss enda?

Hobby