Jeg ville måle kropsfedt og endte med at bygge over hundrede beregnere

Den oprindelige plan var pinligt enkel. Efter tre måneder med konsistent træning på fitnesscenter bevægede vægtskalaen sig ikke meget, men spejlet fortalte en anden historie. Tøjet passede anderledes. Energiniveauerne var oppe. Folk lavede bemærkninger. Det åbenlyse spørgsmål var, om kropssætningen skiftede, selvom den samlede vægt forblev nogenlunde den samme, og det åbenlyse svar krævede at kende kropsfedt procent snarere end bare kropsvægt. Et hurtigt søgeresultat for "kropsfedt beregner" returnerede et dusin annoncesvære websteder med små inputformularer klemte mellem bannerannoncer og popup-nyhedsbreve. De arbejdede teknisk set, men oplevelsen var grusom. Indtast nogle målinger, klik beregn, vent på at siden genindlæses gennem tre lag annoncer scripts, og se endelig et tal uden kontekst om, hvad det betyder, eller hvordan det sammenlignes med sunde områder for nogen i den alder og aktivitetsniveau.

Den tankegang, der fulgte, var den slags, som udviklere genkender øjeblikkeligt, og civile finder forvirrende. "Denne regnemaskine er forfærdelig. Hvor svært kan det være at bygge en bedre?" Svaret på det spørgsmål er altid det samme: at bygge den første version er let, og så tager scope creep over med den stille beslutning af engelsk vedbend, der klatrer op ad en mur. Kropsfedt regnemaskinen var færdig på en eftermiddag. Det brugte Navy-metoden, tog fire målinger (hals, talje, hofter, højde) og viste resultatet med kontekst om sunde intervaller. Rent grænse flade, ingen annoncer, hurtig. Færdig. Undtagen det var ikke færdigt, fordi næste tanke var "ja, hvis nogen tjekker kropsfedt, vil de sandsynligvis også gerne have deres BMI." Så blev en BMI-beregner tilføjet. Og så en BMR-beregner, fordi at kende basale metaboliske hastighed er vigtig for alle, der styrer kaloriindtag. Og så en daglig kaloribehovsregner. Og så en makroregner. Og så en vandindtagsregner. Hver tog en dag eller to, og hver føltes som en naturlig udvidelse af den foregående. Omfanget kryber, men det kryber i en retning, der gjorde mening.

Pivoten fra sundhed til finans skete en onsdag aften, mens vi gennemgik realkreditoptioner. Bankens hjemmeside tilbød en realkreditberegner, der på en eller anden måde var endnu værre end kropsfedt beregner fra det oprindelige søgeresultat. Det krævede oprettelse af en konto før visning af nogen resultater. En faktisk konto, med en e-mail bekræftelsestrinn, for privilegiet at multiplicere en principal med en rente og dividere med tolv. Det eksisterende beregner-rammeværk var lige der, allerede håndtering af input-validering og resultatvisning. Tilføjelse af en realkreditberegner tog mindre tid end bankens tilmeldingsproces ville have.

Den uundgåelige udvidelse til alt, der involverer tal

Når først barrieregang mellem sundhed og finans blev brudt, åbnede flodportene på en måde, der var både spændende og lidt bekymrende. Renters rente beregnere kom næste, fordi personlig finansplanlægning afhænger af at forstå, hvordan penge vokser over tid, og de fleste eksisterende værktøjer gør konceptet vanskeligere at forstå end nødvendigt. Derefter amortiseringslån beregnere, fordi enhver der sammenligner realkreditoptioner også har brug for at se den fulde betalingsplan med rentefordelinger efter måned. Derefter ROI-beregnere, fordi investeringsbeslutninger kræver hurtige tilbage-på-kuvert-estimater før detaljeret analyse kommer. Derefter valutakonvertering, derefter tipsberegnere, derefter opsparingsmål-projektioner, derefter estimater for pensionsplanlægning. Hver beregner delte samme underliggende arkitektur: tag strukturerede input, anvend en kendt formel, og præsenter resultatet med nok kontekst til at være umiddelbart brugbart.

Matematik-kategorien opstod, da en ven, som underviser på gymnasiet, spurgte, om platformen kunne omfatte en procentberegner for studerende, der kæmper med konceptet. Den enkelte anmodning affødte en serie grundlæggende matematiske værktøjer: procentberegnere (hvad er X% af Y, X er hvad procent af Y, procentvis stigning og fald), brøk-til-decimal-konvertere, kvadratrods berechnere, område- og volumeberechnere for almindelige former og enhedskonvertere dækkende længde, vægt, temperatur og hastighed. Ingen af disse er teknisk komplekse. En procentvis beregning er triviel kode. Men at inpakke denne trivielle kode i en ren grænseflade med klare mærker, hjælpsomme forklaringer og øjeblikkelige resultater uden side genindlæsning skaber et værktøj, der er genuin mere nyttig end at gøre matematik ved hånden eller søge efter det på en rodet hjemmeside.

Kryptovaluta profit beregnere kom i en periode, hvor flere kryptovaluta-positioner havde brug for vurdering. Spørgsmålet "hvis jeg købte 0,5 ETH til $2.400 og det er nu $3.100, hvad er mit overskud efter et 0,1% handelsgebyr?" er ligetil aritmetik, men at gøre det gentagne gange på tværs af flere mønter med varierende købepriser, mængder og gebyrstrukturer bliver hurtigt tedious. Kryptovaluta beregneren håndterer købeprisen, salgsprisen, mængde og gebyrer i en enkelt form og viser absolut fortjeneste, procentvis afkast og netto provenu efter gebyrer. Det opretter forbindelse til nogen udveksling og trækker live-priser. Det er rent et beregneværktøj, hvilket er alt det skal være. Live-prisen er på børsens hjemmeside. Beregningen er på calculator.yeb.to.

Hvordan en beregner blev til en arkitektur

Den tekniske historie bag væksten fra en beregner til over hundrede er en historie om arkitektur-beslutninger taget tidligt, som viste sig at være overraskende skalerbar. Den første kropsfedt beregner blev bygget som en standalone-side med hard-coded HTML-formularfelter og en JavaScript-funktion, der kørte Navy-metode formlen. Ved femte beregner var mønsteret åbenlyst: enhver beregner tager et sæt navngivne input (højde, vægt, sats, hovedstad, hvad som helst), anvender en formel og viser et eller flere navngivne output (kropsfedt procent, månedlig betaling, sammensat total). Den delte struktur betød, at en generisk beregner-komponent kunne håndtere gengivelse, validering og visningslogik, mens hver enkelt beregner kun var nødt til at definere sine input, dets formel og hvordan resultaterne skulle vises.

Denne abstraktion er hvad der gjorde eksplosionen fra tyve beregnere til hundrede følte sig håndterbar snarere end overvældende. Tilføjelse af en ny beregner kræver ikke opbygning af en ny side fra bunden. Det kræver at definere input (navn, type, enhed, valideringsregler), skrive beregningsfunktionen og angive, hvordan resultaterne skal vises. Rammeværket håndterer alt andet: reaktivt layout, input-validering, fejlmeddelelser, resultat-formatering og endda forklarende tekst, der hjælper brugerne med at forstå, hvad tallene betyder. Hele platformen er i det væsentlige en motor med hundrede konfigurationsfiler, hvilket er hvorfor den kan vokse uendeligt uden at kodebasen bliver uoverskuelig.

Regnemaskine API'et udsætter den samme motor programmatisk. Eksterne applikationer kan sende inputværdier og modtage beregnede resultater uden nogen grænseflade. Dette er nyttigt for applikationer, der har brug for beregnekapabilitet indlejret i deres egne arbejdsgange. En fitnessapp, der vil vise BMI sammen med træningsstatistikker, kan kalde API'et snarere end reimplementere BMI-formlen. Et økonomisk planlægningsværktøj, der har brug for renters rente-projektioner, kan kalde API'et snarere end vedligeholde sin egen compounding logik. Formlerne er velkendte og ikke proprietær, men at implementere dem korrekt (håndtering af kanttilfælde, afrunding passende, regnskabsføring for skudår i datoberede beregninger) er den slags arbejde, som hver udvikler gør lidt anderledes og ofte lidt forkert.

Hvorfor en samlet platform giver mere mening end spredte værktøjer

Alternativet til en samlet beregner-platform er hvad de fleste mennesker oplever i dag: en separat hjemmeside for hver beregnetype. Et bogmærke til realkreditberegneren. En anden for BMI-beregneren. En tredje for kryptovaluta-profit-værktøjet. Hver site har sit eget design-sprog, sine egne annonceplaceringer, sit eget cookie-consent pop-up, og sin egen måde at præsentere resultater på. Den kognitive overhead ved at skifte mellem disse frakoblede værktøjer er real, selvom den er lille nok til at blive ubemarket, indtil nogen oplever alternativet.

At have alt under ét tag på calculator.yeb.to eliminerer denne overhead. Grænseflade er konsistent på tværs af hver beregner. Indgangene fungerer på samme måde. Resultaterne er formateret på samme måde. Den forklarende kontekst følger samme struktur. En bruger, der har brugt BMI-beregneren, ved præcis, hvordan man bruger realkreditberegneren, fordi interaktionsmønstret er identisk. Denne konsistens kan virke som et design-dille, men den har en målbar indvirkning på brugervenlighed. Brugere bruger mindre tid på at finde ud af, hvordan værktøjet fungerer og mere tid på at få det svar, de kom for.

Der er også en omdagelses-fordel, som spredte værktøjer ikke kan replikere. Nogen, der besøger platformen for at beregne deres BMR, kan bemærke vandindtags berechneren på samme side og indse, at de aldrig har faktisk beregnet, hvor meget vand de skal drikke. Nogen, der kontrollerer en realkreditbetaling, kan opdage renters rente berechneren og begynde at køre pensionsplanerings projektioner. Nærhed af relaterede værktøjer skaber en naturlig udforskningsvej, som isolerede hjemmesider ikke kan replikere, fordi en isoleret hjemmeside optimeret til en beregning har ingen grund til at overfladeisole urenlagte berechnere. Den samlede platform kan og gør, og brugsdata viser, at en betydelig procentdel af brugerne interagerer med to eller flere berechnere pr. besøg.

Tal bag tallene

Bygning af over hundrede berechnere har produceret nogle virkelig interessante observationer om hvad mennesker beregner og hvornår. Sundhedsberechnere stiger i januar, når det nye år opløsnings-skare stiger ned på BMI og kalori-berechnere med entusiasme over friske fitnesscenter medlemskaber. Realkreditberechnere stiger når centrale banker annoncerer rentesatsændringer, nogle gange inden for timer af annoncering. Kryptovaluta profit berechnere korrelerer næsten perfekt med Bitcoin-prisvolatilitet, stiger under tyremarkedsbevægelser og bliver stille under bjørnemarkedsbevægelser. Skatteberechnere topper de uger før ansøgningsfristerne. Selv det grundlæggende procentberechnere har et sæsonmønster, med bruger brug under eksamen-perioder.

Den mest populære berechnere på platformen, med et betydeligt margin, er ikke en af de sofistikerede sundhed eller finans værktøjer. Det er den simple procentberechnere. "Hvad er 15% af 230?" Mennesker søger efter den slags spørgsmål millioner af gange pr. dag verden over, og svaret er blot aritmetik, som enhver telefonens indbyggede berechnere kunne håndtere. Men mennesker tænker ikke det på den måde. De tænker på det som et procentproblem, og de ønsker et værktøj mærket "procent berechnere", der tager deres specifikke input og giver dem det specifikke svar. Lektionen er, at værdien af en berechnere ikke er i kompleksiteten af sin formel. Det er i klarhed af dets grænseflade og hastighed af sit svar.

Når man ser tilbage på rejsen fra denne første kropsfedt beregning til en platform med over hundrede værktøjer, er den mest overraskende realisering, at intet individuelt berechnere var svært at bygge. Vanskeligheden lå i at erkende, at efterspørgslen var universel, og at det eksisterende udbud var fragmenteret, annonce-fyldt og fintlig til brugeroplevelsen. Hver berechnere er triviel isoleret. Sammen danner de noget, der er helt genuint brugbart, netop fordi det er omfattende, konsistent og hurtigt. Kropsfedt-spørgsmålet, der startede det hele, bliver stadig besvaret af det samme værktøj, og gymfortunaget det hjalp med at spore har været betydeligt mere konsistent end den oprindelige plan at bygge "bare en berechnere."