Øredev är en konferens för IT-utvecklare som hållits sedan 2005. I år gick den av stapeln i Malmö på Malmö Mässan, Exhibition & Conference Center, under två och en halv dag. Från Magello var Eric von Knorring och Per Hagsten på plats, här är deras guldkorn från årets konferens.
Temat för årets Øredev var Halt and Catch Fire. Vad vi som människor skulle förändra om det var möjligt att helt stanna upp, och återuppfinna tekniklandskapet. Det vill säga hållbar utveckling mellan människan och tekniken vilket är frågor som Magello verkligen brinner för.
Build vs Buy?
Tänka efter om teamet verkligen måste bygga nytt eller om går att använda redan existerande kod så som open source bibliotek, köpa in tjänster etcetera?
Det finns för- och nackdelar, tänk på:
- Bygger teamet lösningen själva så äger teamet lösningen. Inklusive support!
- Behövs verkligen en helt unik lösning? Går de att integrera mot något som redan finns. Tänk efter noga om teamets behov verkligen är så unikt?
- Är de som ska göras utanför teamets nyckelkompetenser? Om svaret är ja är de antagligen bättre att använda något färdigt!
- Är teamet verkligen beredda att investera den tid som behövs för att ta fram och underhålla ett nytt paket? Kanske kostar de mindre att köpa något färdigt ändå, än de timmar som går åt för att utveckla det? Kom ihåg att ta höjd för underhåll och support!
The Ten Commandments of Egoless Programming
Egoless programming är en arbetsmetodik för hur man arbetar med kod, framför allt med code reviews. Där man försöker minska personliga känslor kring kod och i stället fokuserar på koden i sig. Metodiken föreslogs redan 1971 i boken, The Psychology of Computer Programming. Nedan följer de tio reglerna som ett smakprov! Läs gärna boken för att få mer kontext!
- Understand and accept that you will make mistakes.
- You are not your code.
- No matter how much ”karate” you know, someone else will always know more.
- Don’t rewrite code without consultation.
- Treat people who know less than you with respect, deference, and patience.
- The only constant in the world is change.
- The only true authority stems from knowledge, not from position.
- Fight for what you believe, but gracefully accept defeat.
- Don’t be ”the guy in the room.”
- Critique code instead of people – be kind to the coder, not to the code.
Attackvektorer finns genom hela kedjan
När man tänker på IT-säkerhet är de väldigt lätt att snöa in sig på en specifik del av säkerheten kring en applikation. Försök i stället att lyfta blicken och se hela livscykeln för din kod, från att en utvecklare skriver koden på sin dator, tills den är sjösatt och används av slutanvändaren. Skadlig kod kan komma in från byggsystem, dependencies, buggar i koden eller attacker i slutkundssystemet etcetera. Detta ämne är långt mer komplext och kan inte sammanfattas i ett blogginlägg men denna artikel från Google är ett bra ställe att börja läsa vidare.
Organisera din kod i lager med hjälp av koncept från Functional Programming
Genom att nyttja principer från Functional Programming så kan man bygga en applikation som är enklare att både skala och testa.
Det första steget man bör göra är att identifiera de funktioner i sin applikation som påverkas av extern vid exekvering, så kallade funktioner med sidoeffekter, och vilka som inte påverkas externt, så kallade rena funktioner
En funktion med sidoeffekt kan till exempel vara en funktion vars utfall påverkas anrop till en databas eller läsning från en fil medan en ren funktion vars utfall endast påverkas av dess in-parametrar som till exempel parse:a en sträng eller göra en matematisk beräkning.
Nästa steg är att sedan dela upp sina funktioner i lager där man lägger sina funktioner med sidoeffekter ytterst i ett integrationslager. Sedan lägger man det rena funktioner som är domänspecifika i lagret innanför integrationslagret. Innanför domän-lagret lägger man sedan mer generella funktioner.
På det sättet bygger sin applikation med lager som en lök, så kallad Onion Architecture. Med denna struktur så hindrar man att sina domänfunktioner behöver ta hänsyn till externa beroenden och generella underliggande funktioner inte behöver ta hänsyn till ändringar i domänen. Det gör att koden blir lättare att underhålla och skapar tydligare testdomäner.
Bygga Event Sourcing på JVM:en
Event Sourcing går ut på att bygga sina applikationer så att allting som sker är en reaktion på events. Detta brukar oftast implementeras att man låter sina applikationer prenumerera på events från en eventbuss. Några av fördelar som man får ut av det är:
- Audit Trail vilket gör att man håller en detaljerad historik över systemändringar.
- Temporal Querying som låter dig fråga och rekonstruera tidigare tillstånd.
- Replayability som gör att händelser kan spelas upp igen för felsökning eller återskapa en tidigare state.
Om man vill bygga applikationer med event sourcing på JVM:en kan man använda sig av biblioteket Occurent. Occurent har innehåller grunderna med helpers man behöver. Stöd för ramverk så som spring. Samt även stöd för ’Cloud Event’-standarden. Det finns även en kotlin DSL under utveckling.
Hitta buggar med Property Testing
Property Testing kan man använda för att uppnå en robustare testning av sin mjukvara. I stället för att traditionella enhetstest där man testar ett specifikt scenario i taget så testar man en funktion efter dess generella egenskaper. Man testar de egenskaperna mot en stor mängd in-data som generas automatiskt. På det sättet kan man hitta buggar och edge-cases som inte är triviala att upptäcka och skriva tester för genom att bara granska koden själv.
Ett JVM-ramverk som stöder property testing är kotest.
Hoppas vi ses nästa år!
Tack till arrangörerna för en väldigt bra konferens med många insikter och intressanta diskussoiner, vi hoppas vi ses nästa år igen med flera Mageliter!
