Dansk regnskabsprogram er kodet i ren JavaScript

22. juli 2014 kl. 15:5614
Dansk regnskabsprogram er kodet i ren JavaScript
Illustration: Jakob Møllerhøj.
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.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

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.

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.

Artiklen fortsætter efter annoncen

»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.

Artiklen fortsætter efter annoncen

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.

Artiklen fortsætter efter annoncen

»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.

14 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
7
23. juli 2014 kl. 11:14

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.

1
22. juli 2014 kl. 20:20

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#)

2
23. juli 2014 kl. 09:29

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

6
23. juli 2014 kl. 10:55

Det der er vrøvl i artiklen er at der snakkes om C# og Java på frontend delen inden snakken går over til backend.

9
23. juli 2014 kl. 16:22

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.

4
23. juli 2014 kl. 10:25

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

5
23. juli 2014 kl. 10:34

Hvis man ikke ved hvad et floating-point tal er, skal man nok ikke kaste sig ud i at implementere et økonomisystem :)

11
23. juli 2014 kl. 19:59

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.

13
23. juli 2014 kl. 22:02

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.

15
29. juli 2014 kl. 15:59

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...

14
24. juli 2014 kl. 21:17

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.

12
23. juli 2014 kl. 20:09

Man kan også komme langt med at runde fejl af til Kundens fordel for systemer der er tilstrækkeligt simple i deres udformning.