NDC Oslo 2018 – Dag 2

with No Comments

From SQL to Azure Cosmos DB

Jimmy Bogard är MS MVP och skapare av det populära biblioteket AutoMapper

Jimmy hade varit med om en migrering från SQL-server till MongoDB och senare Azure Cosmos DB.
Han beskrev lite om skillnaderna mellan relationsdatabas och dokumentdatabas.När man skapar upp en CosmosDb ställs man direkt inför frågan om vilket API man tänker använda.
Det finns API för SQL, MongoDB, Cassandra, Azure Table och Gremlin.

Av dessa nämde han att MongoDB-kompabiliteten är väldigt hög, men inte 100%. Man kan använda de flesta verktyg som fungerar med MongoDB.

Det största problemet han stötte på var avsaknaden av transaktioner i Cosmos DB. Han nämde dock att det finns viss transaktions-funktionalitet via Javascript-Stored-Procedurer.

De hade valt ett eget sätt med en variant av event-sourcing med in/out messageboxes. Det kändes lite som hemsnickring av något som borde lösas på ett annat sätt.

Det finns färdiga Cosmos DB emulatorer i docker-containers för utveckling och integrationstester.

Totalt var det som en intressant genomgång (Patrik)

How to be a better interviewer

Suzi Edwards-Alexander har jobbat både med utveckling och HR och är anställd på konsultfirman ThoughtWorks
Superkul att jag trillade in på den här föreläsningen när jag satt i “Overflow” och tittade på en ointressant föreläsning. Overflow är ett ställe med gigantiska TV-skärmar där man kan se valfria föreläsningar live. Alla har headset där man kan välja en önskad föreläsning.Suzi berättade väldigt insiktsfullt och intressant om hur man bör intervjua programmerare.

Man ska undvika att framställa intervjun som en tävling, där det upplevs att den som svarar rätt på flest frågor “vinner”. Det är troligtvis inte den tävlingsinriktade man vill få in i sitt team.
Tänk istället på den ansökande som en framtida kollega istället.

En intressant idé var att man ska fråga vad vi kan göra/ändra för att hen skulle vilja jobba här.

En annan inställning hon tyckte man kunde ha var att se om vi kan vara smarta tillsammans och spåna på någon idé direkt i intervjun.

Kolla inte bara om personen passar in utan även på vad hen tillför till företaget och teamet.

Börja alltid intervjun med enkla frågor och gå sedan vidare genom att borra ner i några få ämnen hellre än få en generell uppfattning, eftersom det är de saker den ansökande kan ha pluggat in svar för.
Ställ gärna frågor och och knuffa den ansökande i rätt riktning istället för att vänta och se om hen kan svara själv.
Hon tryckte hårt på att man alltid ska förbereda sej på en intervju. Minska hellre intervjutiden än skära i förberedelserna.
HA alltid med en kollega vid intervjuer. Hon hade även en kul idé att man skulle fråga sin kollega något och försöka få den ansökande att hänga med i diskussionen som uppstår.
Avsluta gärna med att fråga om vad hen skulle gjort annorlunda om hen fick starta om intervjun.

Mycket bra idéer! (Patrik)

How to pronounce code

Felienne är assisterande professor på ett universitet i Holland.
Egentligen skulle hon hålla en föreläsning om “How to teach programming”, men hon ändrade sig efter alla redan kommit in i lokalen.
Detta betydligt flummigare ämne kändes lätt off-topic.Hon pratade t.ex. om hur man uttalade t.ex. x = 5 jämsides x == 5. Hon beskrev problemet som att en utvecklare ringer upp en annan utvecklare och ska berätta vad som ska stå i en kodfil.

Mellan flummigheterna dök en del intressant upp. Det finns ju faktiska tillfällen, då t.ex. en synskadad ska beskriva koden verbalt. Hon menade att vi måste få en standard på hur kod uttalas.

En annan slutsats som dök upp lite utanför huvudämnet är att all programmering är “riktig programmering”. Man ska inte se ner på Phyton eller VB-utvecklare utan omfamna dom som utvecklare. Hon gick så långt som att kalla alla som kunde Excel rimligt bra kunde kalla sig utvecklare. Hon pekade på andra communities som normalt är glada att träffa personer med liknande intressen.

Som sagt var detta lite för långt från huvudämnet för mej, men hon hade några fina poäng. Jag ska aldrig mera använda uttrycket “Riktig programmerare”…:-)  (Patrik)

Mötley Crüe and Mödern JavaScript

Mötley Crüe and Mödern JavaScript var en av dagens rockigaste föreläsning. Föreläsaren Eric Brandes inspirerade hela sin föreläsning av olika rockband och drog paralleller mellan JavaScriptens framväxt med Rockens. Det första som föreläsaren visade var en bild med en hel bunt rockbandloggor från 70-90 talet bredvid en annan bild med massor loggor på de JavaScript bibliotek som finns därute. Kort därefter slängde han ur sig kommentaren, bara för att det finns många rockband så behöver inte alla vara bra, likaså med JavaScript bibliotek.

Det som var intressant med denna föreläsning var att föreläsaren till skillnad mot många andra faktiskt pratade om att det i många lägen var bättre och lättare förr att använda JavaScript i browsern. Idag behöver man först veta vilken av de alla ramverk/bibliotek man ska använda, sen måste man sätta upp WebPack, NPM, kanske någon CSS preprocessor och sen ha en massa olika programvara installerat på sin utvecklingsmaskin. Om man ville ändra innehållet dynamiskt på sin hemsida innan alla SPA-ramverk fanns så räckte det många gånger att dra in jQuery på sin site och sen skriva några få rader JavaScript för att dynamiskt ändrat innehåll. Det föreläsaren ville komma till var att det många gånger från kundens perspektiv räcker att använda enkla metoder för att få problemen lösta, användaren bryr sig inte om ifall siten använder React, Vue eller Angular.

Eric tipsade även om Gatsby vilket är ett litet bibliotek för att rendera statiska HTML-sidor. Han tipsade även om ett annat som heter PJAX som även Github använder idag vilket är ett litet bibliotek som möjliggör att dynamiskt byta ut delar av sidan mot html hämtad ifrån en server. Föreläsaren var väldigt skämtsamt men tog även upp delar som man vanligtvis inte tänker på tycker Dennis.

Serverless with Firebase in the wild

Duncan Hunter höll i en föreläsning som hete Serverless with Firebase in the wild. Föreläsningen handlade om hans erfarenhet att bygga om sin befintliga webbapplikation skriven i ASP .NET och Webforms till NodeJs och molnplattformen Firebase. Föreläsaren gick igenom vad Firebase är och vilka styrkor och svagheter som plattformen har. Firebase är alltså en molnplattform skapad av Google där det tillhandahålls databaser, webhosting och molnbaserade funktioner.

Tidigt under föreläsningen nämnde han om något som lät mycket intressant, och det var att Firebase använder ”by default” websockets, alltså kommunikation från server till klient. Vad Firebase gör är att så fort den känner av att någon data har förändrats i databasen så trycker den ut dessa förändringar till alla klienter. En svaghet som Duncan berättade var att Firestoredatabasen(som är en del av Firebase plattformen) är helt och hållet molnbaserad. Detta gör att man helt och hållet är beroende av att ha uppkoppling, vilket inte gör så mycket för en produktionsmiljö, men om man sitter och ska jobba på ett tåg med svajigt internet så kan det bli lite trassligt. Föreläsaren var väldigt rutinerad och pedagogisk, dock är det lite skrämmande vad man helt låser in sin applikation för en och samma plattform genom att använda Firebase tycker Dennis.

Architecting your next SPA

Architecting your next SPA var en föreläsning som handlade om vad man bör tänka på när man sätter upp en ny SPA(Single Page Application) och lite matnyttig information om de SPA-ramverk som finns idag. En rolig throwback som föreläsaren Guy Nesher nämnde var att begreppet SPA fanns redan år 2002 då när Flash var populärt i browsern. En annan jämförelse som föreläsaren nämnde var att React har ca 2 500 000 nedladdningar per vecka till skillnad från Angular som har ca 700 000, de övriga SPA-ramverken ligger någonstans under 300 000.

När det kommer till att strukturera sin kod fick vi tips om att inte bryta isär HTML-markupen ifrån sina JavaScript-filer utan att behålla båda två i samma fil. Olika SPA-ramverk/bibliotek har olika sätt att hantera HTML-markup, vissa har den direkt i JavaScript-filen, som i React och vissa andra har den i en separat HTML-fil som Angular. Men varför han ansåg att dessa skulle ligga tillsammans var för att en komponent ska vara så liten att den ska vara behändig att ha i en och samma fil, och där av blir det mer lättjobbat när man kan överblicka hela källkoden på en gång.

Något som man behöver tänka på i SPA-ramverk är applikationens state, alltså det data som applikationen har i minnet. Att jobba med applikationens state mellan olika komponenter kan ibland bli lite trassligt, därför ansåg föreläsaren att man så tidigt som möjligt ska implementera hjälpbibliotek/mönster som t.ex. Redux. Redux hjälper till med att hantera statet separat ifrån sina komponenter, och gör det lättare att komma åt data ifrån olika delar av applikationen. Föreläsaren var aldrig på något sätt partisk mot något ramverk/bibliotek och gick igenom alla delar på en lagom nivå tycker Dennis.

Follow wspaal:

Latest posts from

Leave a Reply