Hoppa till innehåll

Sammanfattning - "Stå-upp"-vlogg (2024)

Inspelningen gäller 1DV026:s kursvecka 14-15.

Veckan inleds med deadline för CRUD-applikationen B1, klockan 17.00. Före dess ska du både ha skapat din Merge Request och bokat en tid för den muntliga examinationen på Moodle. Finns det inga lediga tider kvar, skicka ett direktmeddelande till kursledningen före deadline, så ordnas en tid. Vid den muntliga examinationen ställs förberedda frågor, och du presenterar delar av din applikation. Kursledningen hinner inte gå igenom all kod, utan fokuserar på vissa avsnitt.

Det första steget kring lösenord är att veta att de ska hashas, inte krypteras. Att bygga inloggning själv på rätt sätt är svårt, och professionellt används ofta tjänster för Identity as a Service. I den här kursen skrivs dock allt från grunden.

Många har i sina reflektioner kommit fram till att A2 inte främst handlade om att skriva en skrapa, utan om att förstå HTTP: förfrågningar och svar, statuskoder och hur cookies fungerar. Koden var i år generellt välorganiserad. Några återkommande iakttagelser:

  • Hårdkoda med omdöme. Det är rimligt att anta att biografen visar filmer fredag till söndag, men filmtitlar, antal filmer och tider ändras naturligt och måste skrapas. Hårdkodade filmtitlar är den vanligaste orsaken till komplettering.
  • Parallellt eller sekventiellt. Att skrapa kalendrarna parallellt med flera fetch-anrop och Promise.all är en snygg konstruktion, men med tre kalendrar är skillnaden knappt mätbar. Med hundratals sidor hade det spelat roll.
  • Checka inte in node_modules. Det gör kodgranskningen omöjlig, eftersom varje rad i paketen räknas som en ändring i Merge Requesten. Lägg till en .gitignore innan första commit. Har mappen redan hamnat i versionshanteringen räcker det inte att lägga till den i .gitignore i efterhand, utan den måste också tas bort ur versionshanteringen, till exempel med git rm -r --cached node_modules.
  • Välskrivna CSS-selektorer gör skrapandet mycket enklare, eftersom de pekar ut exakt det man vill ha.

Det mesta som dyker upp på handledningarna rör driftsättning. Felet kan sitta i Express-applikationen, i klienten eller i nginx däremellan. Fungerar applikationen lokalt är den sällan det första stället att leta. Börja med miljövariablerna och därefter nginx-konfigurationen, till exempel ett snedstreck som fattas i proxy_pass.

  • 502 Bad Gateway betyder att nginx fungerar men inte når applikationen. Antingen är portnumret fel, eller så startar inte applikationen, till exempel för att den inte kan ansluta till databasen. Använd PM2:s loggar: kör pm2 monit i ett terminalfönster och starta applikationen i ett annat, så ser du direkt om anslutningen till MongoDB misslyckas.
  • 404 – titta på hur sidan ser ut. Kommer den från din applikation har den startat, och felet ligger troligen i routingen, oftast i BASE_URL. Kommer den från nginx ligger felet i nginx-konfigurationen.

Kursblock 14-15 handlar om realtid: hur data når applikationen utan att klienten själv frågar. Klientsidan av WebSockets känner du redan till. Nu är det serversidan, och dessutom webhooks, som är vanliga när servrar ska meddela varandra om händelser. Efter en kort introduktion följer två exempel som bygger på Just Task It. Exemplen bygger på en variant med mer avancerad loggning, vilket förklarar att koden ibland kan se lite annorlunda ut.

Examinationsuppgiften B2 brukar inte upplevas som alltför tung, eftersom exemplen hjälper till mycket. Det nya är kopplingen till GitLab: applikationen hämtar issues via GitLab-API:t och tar emot händelser via en webhook. B2 ska också driftsättas, men det går till på samma sätt som för B1, bara med en annan URL.

Exempelinspelningarna använder Socket.IO, medan exempelkoden numera använder webbläsarens inbyggda WebSocket. Socket.IO är ett omslag runt WebSocket. Med standard-API:t slipper man tänka på hur Socket.IO-klienten laddas, men i gengäld får man hitta på ett eget litet protokoll för meddelandena. Båda är enkla att använda, och vilket du väljer är upp till dig.

CCBY