Nu er konferencedelen af GOTO cph 2017 slut efter tre intense dage med utallige talks om vidt forskellige emner, nye trends, seje tools, networking, samtaler og hygge. Der var mange talks især omkring microservices, om “serverless” applikationer der kører i produktion, om machine learning, AI, agile, security og en hel del flere.
Af nye værktøjer kan nævnes Axon Framework som især er velegnet til at udvikle message-driven microservice applikationer, der bygger på arkitekturprincipperne bag Domain Driven Design (DDD), Command-Query Responsibility Segregation (CQRS) og Event Sourcing. Et andet framework er React Native, hvori man kan udvikle hybride apps, ligesom med ionic frameworket. Med begge udviklingsframeworks kan man udvikle mobile apps ud fra én og samme kodebase, men køre app’en på forskellige platforme. Med ionic udvikler man app’en i typescript/javascript samt HTML5 og CSS, og derefter wrapper man app’en til enten iOS eller Android og deployer app’en som var det en native app. Ved at bruge tools som PhoneGap eller Cordova kan man gøre brug af telefonens indbyggede features såsom GPS eller kamera etc. Forskellen på React Native og ionic er at ionic bygger på Angular, hvorimod React Native bygger på Javascript-framework’et React. Nogle mener at med React Native får man hybride apps, der er hurtigere og mere responsive over for slut-brugerne, fordi React gør brug af native rendering, hvorimod ionic apps kan føles nogle langsommere sammenlignet med native apps og apps udviklet i React Native. Men det hele kommer an på dine præferencer, dit team, dine brugerkrav, krav til app’en, og hvad der vægtes højest af disse.
Der var også en hel del foredrag omkring Amazon Web Services og deres utallige produkter. Der var specielt en præsentation om AWS Lambda som fremhævede hvor nemt, hurtigt, sikkert, skalerbart og ikke mindst billigt det er at bruge AWS Lambda til at køre sine applikationer op imod. Med traditionelle softwaresystemer er det imod alle regler, at en brugergrænseflade har direkte kontakt med fx en database, men med AWS Lambda er det netop det der sker. “Backend” resourcer er nu pludselig blevet til frontend. Med AWS Lambda betaler man kun for det totale antal requests, der bliver sendt mod Lambda – og du får de første 1 million requests om måneden gratis. Du betaler også for tiden der tager at udføre et request, og prisen afhænger også af hvor meget hukommelse der skal allokeres til at udføre det. Du slipper for at bekymre dig om server overhead, vedligehold, administration etc. Det hele lød meget lovende ifølge de forskellige talere, der havde AWS på programmet. Tjek i øvrigt denne serverless chat ud.
Til sidst vil jeg nævne Martin Thompsons keynote fra den første konferencedag, der handlede om hvad der karakteriserer en god software engineer, og om hvordan vi i IT-branchen opfører os som en slags alkymister. Dvs. vi prøver os lidt frem, gætter, tilføjer lidt magi – og på denne måde håber at opfinde “guldet”. Men dette vil næppe føre til noget godt. Vi skal i stedet opføre os som software engineers: vi skal øve os i vores daglige arbejde. Især bør softwarearkitekter også kode af og til. Processen omkring softwaredesign er en iterativ process hvor det er vigtigt at have alle aspekter af systemet med ind i designprocessen så tidligt som muligt – såsom sikkerhed, skalerbarhed, fejltolerance etc. Og vi bør alle øve os i og lære (eller lære en gang til) om algoritmer og datastrukturer, design principper, forskellige programmeringsparadigmer etc. Når et projekt, vi arbejder på, kommer under tidspres, falder vi (under pres) naturligt tilbage på vores basale “træning” dvs. hvad vi har oprindeligt lært eller er vant til. Så for ikke at miste kvaliteten i software eller i processen, når en hård deadline nærmer sig, så skal man have et solidt fundament at falde tilbage på.
Vi kan lære os selv disse færdigheder ved at øve os, ligesom musikere øver sig hver dag på deres instrument, og vi kan lære ved at snakke med andre fra team’et eller organisationen, gå til konferencer, læse artikler, og specielt forskningsartikler – som denne keynote netop handlede om. Vi skal lære ved at læse hinandens kode, og her kommer github og open source software os til hjælp. Start med at læse koden bag alle de seje, nye tools der dukker op, eller som har været banebrydende for mange af de store, internationale IT virksomheder. Sørg for at eksperimentere og måle på det du udvikler. Gå eksempelvis tilbage til noget du har kodet for en uge siden, og gennemgå koden, ændre det der trænger til at blive skrevet påny – idet du først et stykke tid senere kan reflektere over din kode og se hvilke fejl eller uhensigtsmæssigheder du i første omgang lavede. Læs bøger så du tilegner dig nye skills, eller læs om noget helt nyt du ellers aldrig ville have kastet dig over.