Standout AB

Standout

Vi gör inte kassa system

Vår medarbetare Robert skriver lite om teknikvalen i ett nytt projekt som vi precis har startat upp. 

Vi gör inte kassa system. Vi gör kassasystem.

Vi gör mycket mer än så förstås, men just den här sprinten har jag suttit med ett nytt projekt här på Standout. Nya projekt är alltid roliga; och även lite spännande. Beslut man tar kommer följa med länge, så man får passa sig lite så man inte målar in sig i ett hörn; plötsligt sitter man där, flera år senare, med en monolit som bara går att förbättra i periferin, vars inre väsen är en svart massa av obskyra beslut och svårtolkad kod.

Kanske målar jag det för mörkt nu. Men en hel del saker kommer följa med rätt länge, i alla fall, så det kan vara värt att planera för det. I en perfekt värld ska man ju kunna byta ut varje val mot något annat, men det är sällan lösningarna blir så välskrivna att det i praktiken funkar. Det är något att sträva efter, dock.

Projektet är i ett tidigt stadie, så jag kan inte avslöja allt – men för den tekniskt bevandrade kan det vara intressant att höra vad vi arbetar med för uppsättning.

Teknologistack

React Native

För vyer. Även om projektet är för Android i dagsläget så har vi möjligheten att, utan allt för mycket ansträngning, porta det till iOS någon gång i framtiden.

Cucumber och Calabash

För våra integrationstester. Under min utbildning var jag inte en stor anhängare av BDD, men jag kan se värdet i det i kommunikation med kund/produktägare.

Jest

För våra enhetstester. Backend skrivs inte den här sprinten, och kommer ha sina egna enhetstester, men med Jest kan vi testa att vår Redux-lösning funkar.

Redux

State management. I vanliga fall brukar jag argumentera, som den fanboy av Dan Abramov jag är, att man kanske inte behöver ett state management-bibliotek från start; det går att lösa State på många olika sätt. Man kan ha local state i komponenter, man kan ha state I URL:en, React har ju gjort det enklare att undvika s.k. “props drilling” med sitt Context-API. Men när det kommer till en mobilapplikation känns det rätt okej ändå, speciellt om vi ska prata med backend.

TypeScript

Inte en officiell del av teknologistacken, men jag hade chansen att smyga in det, och tog den. TS har sina brister, men efter att ha suttit med NGRX och Angular så föll jag för det. Bara det att min editor vet formen av objekt som skickas runt gör så mycket för utvecklingstakten. Man undviker småfel enklare. Visst, det är inte gratis att skriva typer, men tiden man lägger på att skriva typer vinner man ganska snabbt tillbaka. Interfaces kanske inte gör något när man kompilerar, men de blir ändå kontrakt som jag som utvecklare håller mig till.

Och TS glänser när det kommer till Redux. Det är som gjort för Redux. Bara att kunna säga “så här ser state ut” vart som helst i flödet är värt hur mycket som helst, i mina ögon. Men, jag skriver inte för att sälja TypeScript, så låt oss gå vidare.

Ramverk för översättningar

Här letade vi upp något som liknande I18n i Ruby, och valet föll på i18n-js. Enkelt att skapa en locale-fil, och syntaxen är väldigt lik Rubys implementation. Skulle vår kund senare vilja erbjuda systemet vi bygger på något annat språk behöver de bara fixa en översättning av filen vi arbetar med. Skulle det visa sig att biblioteket vi valde inte håller måttet så är strukturen på det vi skrivit ändå så pass simpel att vi skulle kunna skriva en egen lösning, vid behov.

Jag tror det nog var “allt”, för den här gången.