Dansk regnskabsprogram er kodet i ren JavaScript

Kerneproduktet hos Billy's Billing er et regnskabsprogram, der er kodet i JavaScript, så det kan køre i en browser, uafhængigt af det underliggende operativsystem.

Version2's sommertour er nået omkring Billy's Billing på Gothersgade i København. Den danske virksomhed laver et regnskabsprogram, der kører i en browser udelukkende via HTML5 og JavaScript.

»Fordelen med JavaScript er, at så meget kan foregå i browseren. Det får det hele til at virke mere flydende, og giver en bedre oplevelse, når man sidder med det,« fortæller udvikler hos Billy's Billing gennem tre år Michael Storgaard.

Han er en del af et udvikler-team på fire, hvoraf de tre andre befinder sig i USA. Billy's Billing anvender JavaScript-frameworket Ember. Det er velegnet til at strukturere de forskellige dele i regnskabsprogrammet og binde dem sammen, fortæller Michael Storgaard.

Udvikler gennem tre år hos Billy's Billing Michael Storgaard tegner en grovskitse af backend og frontend-delen i virksomhedens regnskabsprogram.

Ember følger en såkaldt MVC-model - model, view og controller. Hvor model-delen repræsenterer datalaget, view er brugergrænsefladen og controlleren er det funktionelle lag, der eksempelvis tager sig af, hvad der skal ske, når brugeren trykker på en knap.

»Der er nogle strikse konventioner for, hvordan koden skal struktureres i Ember. Eksempelvis hvor filerne skal placeres i henhold til MVC-modellen. Og det hjælper med at bevare en rigtig god struktur på hele projektet,« siger Michael Storgaard.

JavaScript har ikke givet problemer i sig selv

JavaScript-fundamentet bevirker, at regnskabsprogrammet kører i diverse moderne browsere og på tablets uafhængigt af det underliggende operativsystem. Michael Storgaard fortæller, at valget af JavaScript som programmeringssprog til regnskabsprogrammet frem for klassiske sprog som eksempelvis Java eller C# ikke i sig selv har været et problem.

»Rent kodemæssigt er det ikke et problem at skrive det i Javascript. Vi har haft samme mulighed for at teste det hele igennem, som vi ville have med andre sprog. Tidligere har det måske været sådan, at JavaScript blev betragtet som lidt for løst struktureret, men det har blandt andet sådan noget som ember-frameworket hjulpet med at rette op på,« siger han.

Selvom regnskabsprogrammet kan køre i en browser, er det dog ikke optimeret til den mindre skærm på mobiltelefoner, fortæller Michael Storgaard. Men Billy's Billing har dog planer om at lave en version af programmet som app til telefoner.

Grovskitsen viser de forskellige elementer i regnskabs-systemet fra Billy's Billing. Nederst er frontenden, der kører i brugerens browser, og som er kodet med Javascript-frameworket ember. Dernæst et plugin til ember kaldet billydata, som samler og strømliner kommunikationen til backenden. Backend-delen kører i Amazons skytjeneste AWS og består af en database og et REST-baseret API kodet i PHP. Api'et bliver både tilgået af Billy's Billings frontend program og af eksempelvis webbutikker, der opdaterer informationer om ordrer direkte i databasen.

Der findes ganske vist en mobilapp fra Billy's Billing, men det er ikke det egentlige regnskabsprogram, men en slags tilføjelse til programmet, der gør det muligt at uploade regninger til det bagvedliggende system, når man er på farten.

Backend-systemet

Mens den del af regnskabssystemet, som ligger ude hos brugerne, er kodet i ember og HTML5, så er backend-systemet en lidt anden historie.

Billy's Billing har lavet en plugin til Ember-frameworket kaldet billydata, som også ligger i brugerens browser. Den del sørger for at samle og optimere kommunikationen fra frontend-systemet til backenden, som ligger i Amazons skytjeneste AWS.

Her bliver data lagret via et REST-baseret API kodet i PHP. Altså en grænseflade, som kommunikation til og fra databasen foregår via.

Både Billy's Billings eget regnskabsprogram og virksomhedens eksterne kunder anvender dette API for at tilgå regnskabsdata i databasen.

»At vi sidder og arbejder op mod vores eget offentlige API, betyder, at vi skal være opmærksomme på hvilke ændringer, vi laver på det. Vi kan ikke lave drastiske ændringer, bare fordi vi har behov for det. Andre skal kunne stole på API'et. Men at vi arbejder op mod det betyder på den anden side også, at vi støder på de samme udfordringer som kunderne, som vi så kan løse,« siger Michael Storgaard.

De kunder, som tilgår databasen via api'et kan eksempelvis være webbutikker, der automatisk opdaterer regnskabsdata i databasen, når nye ordrer tikker ind.

Omkring valget af Amazons skytjeneste, fremhæver Michael Storgaard fordelen ved hurtigt at kunne opskalere og nedskalere antallet af servere, så det passer til kundernes behov.

En drilagtig bug

I sine tre år som udvikler er Michael Storgaard selvsagt stødt på et par umiddelbart uforklarlige bugs. En af dem handlede om de danske bogstaver æ, ø og å, eller i hvert fald et af dem.

»Vi fik en melding fra nogle kunder om, at der var problemer med at uploade filer, og at det måske var noget med æ, ø og å i filnavnene,« siger han.

Efter at have forsøgt med filnavne med danske bogstaver, uden der var problemer, fandt udviklerne langt om længe frem til, at det faktisk kun var det danske bogstav å, der fik uploaden til at gå i skuddermudder.

»Vi lavede en generel funktion, der rettede alle specialtegn, så det var sikret fremover,« siger Michael Storgaard.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Følg forløbet

Kommentarer (14)

Niels Henriksen

Der er fravalgt Java og C# til fordel for JavaScript fordi så kan det køre i forskellige browsere. Men alligevel er det baseret på REST og PHP. Det er vrøvl.

Men smart nok at der er rigtigt meget JavaScript der så sender data til en server som er baseret på PHP (som også udemærket kunne være C#)

Karsten Garborg

Eftersom det er backend påvirker det jo ikke frontend brugernes oplevelse. Frontend kunne vel sagtens laves i en Java applet, som så kræver et specielt setup hos brugeren - går ud fra det er det der menes.. det er lang tid siden jeg har rodet seriøst med Javascript, men alle beregninger bliver nok foretaget i backend, da JS har "problemer" med dens floating point precision, som kunne give noget forfærdeligt rod i sådan et økonomisystem

Jonas Høgh

JS har "problemer" med dens floating point precision, som kunne give noget forfærdeligt rod i sådan et økonomisystem


Javascript implementerer IEEE 754 Double Precision standarden helt efter bogen. Hvis du har brug for noget andet, fx en decimalrepræsentation med arbitrær præcision, findes der masser af "BigDecimal" libraries til den slags, helt analogt til tilsvarende Java-komponenter

Karsten Garborg

Derfor jeg skrev "problemer" i anførselstegn.. Ved godt det er helt efter bogen, men det kan stadig give noget rod, hvis man ikke er klar over det.. var ikke klar over der var en løsning på det, ud over at skære resterende decimaler væk

Jakob Jensen

Har selv lavet et komplekst timeregistrerings system med javascript/jQuery og MS WepApi/REST.
Men jeg håber der er bedre dokumentation af projektet, end hvad man ser på grovskitsen her. Jeg ser desværre alt for mange frontend udviklere som glemmer at dokumentere og tror deres kode er selvforklarende, fordi de bruger Ember, Knockout, Backbone etc. Der er alt for få specialister i disse framework, hvorfor man ikke kan regne med at folk automatisk genkender kode.

Baldur Norddahl

Man kan sagtens lave frontend og backend i samme sprog. Det mest åbenlyse er naturligvis JavaScript med Node.js på serveren. Men der er også mange andre sprog, som kan oversættes til JavaScript og dermed køres i browseren.

Jeg arbejder med http://www.scala-js.org/ som er en Scala til JavaScript oversætter. Man kan dele kode som kan køres på både server og klient. Det er f.eks. praktisk når man udvikle et API, fordi dataobjekter kan serialiseres og modtages på den anden side med samme kode. At flytte opgaver mellem klient og server er trivielt.

Java har et lidt ældre projekt kaldet GWT der gør det samme: http://www.gwtproject.org/

Dart kan køre både i browser og på serveren.

Rigtig mange sprog har mindst et projekt på at kunne oversætte til JavaScript.

Jacob Christian Munch-Andersen

Og selvom man ved hvad floating-point er, skal stadig ikke gå i gang med at implementere et økonomisystem med floats :)


Det er der såmænd heller intet galt i, man skal bare sørge for at det mindste værdispring som man ønsker at kunne håndtere er lig 1 i intern repræsentation, præcis som når man bruger integers. Den eneste egenskab som gør at en float ikke trivielt kan erstatte en integer er overflow, så længe man ikke har brug for integer-overflow kan en 64 bit float alt hvad en 54 bit signed integer kan.

Sune Marcher

Det er der såmænd heller intet galt i, man skal bare sørge for at det mindste værdispring som man ønsker at kunne håndtere er lig 1 i intern repræsentation, præcis som når man bruger integers.


Hvis du er ude i at lave den slags krumspring, hvilken værdi giver det dig så at bruge floats? (Udover at du kan bruge et handicappet sprog til noget det ikke er super velegnet til, naturligvis).

Det kræver en del disciplin at anvende floating-point korrekt, og det er desværre ret nemt at fucke up... derudover har jeg indtryk af at mange (ellers kompetente) programmører har en idé om "vi skal ikke bruge floats til currency stuff", men ellers ikke kender så meget til de forskellige faldgruber.

Jacob Christian Munch-Andersen

Hvis du er ude i at lave den slags krumspring, hvilken værdi giver det dig så at bruge floats? (Udover at du kan bruge et handicappet sprog til noget det ikke er super velegnet til, naturligvis).


Som du selv hinter, det krumspring sætter mig i stand til at bruge JavaScript, hvilket gør at hele molevitten kan køre i en browser, det er efterhånden en ret efterspurgt feature, ikke mindst fordi det betyder at koden kan køre på alverdens operativsystemer uden nogen som helst form for tilpasning.

Det ville da være rart at have integers, samt to forskellige operatorer til henholdsvis addition og konkatenering, og det ville da også være fint hvis sproget var lidt mere compilervenligt så det kunne komme op i hastighed uden for mange krumspring. Til gengæld savner jeg som rutineret JavaScript-programmør indre funktioner i de fleste andre sprog, og det kan virkelig være latterligt kompliceret at sætte et simpelt grafisk interface op i mange af de gængse sprog. DOMen er ikke så genial til store grafiske udfoldelser, men til interfacet til et regnskabsprogram forekommer det umiddelbart at være et rimeligt godt værktøj.

Det kræver en del disciplin at anvende floating-point korrekt, og det er desværre ret nemt at fucke up... derudover har jeg indtryk af at mange (ellers kompetente) programmører har en idé om "vi skal ikke bruge floats til currency stuff", men ellers ikke kender så meget til de forskellige faldgruber.


Altså: Det kræver en del disciplin uanset om man bruger floats eller integers. Jeg tror umiddelbart at der er en del flere programmører som kan finde ud af at bruge floats som integers, end programmører som kan finde ud af at gange en arbitrær procentsats på et tal med korrekt eksakt afrunding.

Jesper Udby

Det kræver en del disciplin at anvende floating-point korrekt, og det er desværre ret nemt at fucke up...


Enig. Faktisk er floats helt og aldeles uegnede til decimaltalsaritmetik. Hvis altså man interesserer sig for at summen af en stribe tal passer på sidste decimal, og på dette område er regnskabsfolk så underligt krakilske...

At bruge floats som 54-bit integers kræver godtnok man holder tungen lige i munden.
En enkelt "hurtig" eller uerfaren progammør der lige kommer forbi med en mindre rettelse og din (64-bit)float er ikke længere en 54-bit integer...

Det kunne være interessant at få lidt feedback fra folkene bag Billy's Billing om hvordan de konkret løser den slags udfordringer...

Log ind eller opret en konto for at skrive kommentarer