Inlämningsuppgift 3

Betyg

Denna uppgift bedöms på skalan IG/G.

Uppgiftsbeskrivning

I den här uppgiften ska ni kombinera två API:er - OMDB (Open Movie Database) och SMHIs öppna väder-API.

Uppgiften är att skapa en webbtjänst där man, beroende på väderlek, får tips om filmer eller en uppmaning att gå ut och hitta på något.

Använd webbläsarens inbyggda geolocation-API för att få fram latitud och longitud (GPS-koordinater för ens aktuella plats). Vi kan förutsätta att platsen är i Sverige. (Vi har inte gått igenom geolocation så här är er utmaning att läsa dokumentation/testa/labba och våga lita på att ni kan klura ut det!)

Om geolocation inte är tillgängligt ska användaren antingen kunna välja en större ort i en lista, alternativt skriva in sin position. Här får ni anpassa uppgiften lite utifrån er tidigare erfarenhet och er tid. Men det ska finnas en "felhantering" för om geolocation inte är tillgängligt.

Exempel: om geolocation är tillgängligt, platsbestäm automatiskt var användaren är. Om det inte är tillgängligt, visa ett meddelande om att platsen inte kunde bestämmas automatiskt och erbjud en dropdown med Sveriges 10 största städer eller motsvarande. Var kreativa!

Om det förutspås "dåligt väder" den närmaste tiden så får man förslag på två slumpmässiga filmer. (Här är utmaningen att generera ett slumpmässigt IMDB-ID i stil med tt0166925, eller ett slumpmässigt ord som förekommer i filmtiteln att söka på). OMDB har stöd för att söka på ett ID eller titel.

Utmaningen här är att vara kreativ när det finns begränsningar man inte kan rå över.

Det ska också finnas en knapp som genererar ett nytt filmförslag om användaren inte är nöjd med det som den har fått. Sidans innehåll ska då uppdateras.

Därutöver ska ni komma på en egen "feature" att implementera i ovan beskrivna "tjänst". Här får ni gå loss kreativt: det kan vara onödigt, tokigt, tråkigt, ironiskt, eller varför inte användbart!

Det är fritt att vara kreativ med uppgiftens utformning i övrigt (t.ex. vad avser utseende/CSS, och om det finns tid, lägga till ytterligare features). Vill ni ändra någonting/tänka annorlunda så hör av er innan ni sätter igång, så att vi kan säkerställa att betygskriterierna för uppgiften uppfylls.

Koncept som inte ingår i uppgiften från videosarna (om ni t.ex. vill träna på något av dessa i er "extra feature"):

• Sortering och filtrering av data
• Datum
• Timers

Övningsmoment/examinationsmoment/lärdomar

Examinationsmoment

Följande saker examineras från kursplanen:

• Beskriva hur API:er, parprogrammering och agilt arbetssätt används inom team
• Samarbeta i team genom parprogrammering och versionshantering i git

Varför ni gör uppgiften

• Lära sig skaffa en API-nyckel, och vad det är.
• Lära sig att använda ett API.
• Lära sig att planera ett applikationsflöde/programstruktur.
• Läsa dokumentation/lära sig om en funktion vi inte har gått igenom (geolocation).
• Samarbeta i grupp genom agila metoder.
• Lära sig läsa andras kod och ge konstruktiv feedback.
• Bryta ner en större uppgift i hanterbara, små delar.
• Tidsestimera uppgifter.

Tips inför uppgiften

• Om ni inte använder er av Vite, så rekommenderar jag i alla fall att ni jobbar med JavaScript-moduler. Då får ni mindre kodkonflikter när ni kan jobba i separata filer.
• Av samma anledning rekommenderar jag att ni jobbar med Sass.
• Lägg in luft i er planering för ni kommer att få kodkonflikter. Det tar tid att lösa dessa. Våga be om hjälp ifall ni kör fast! Handledningen finns till för bland annat det.
• Använd Co-authoring-funktionen är ni committar om ni har jobbat i grupp! VIKTIGT!

Att göra

Steg 1. Skriv gruppkontrakt

Se sidan om "Gruppkontrakt" under vecka 4. Committa gruppkontraktet till repot.

Bonus: kom överens om hur ni skriver commit-meddelanden. En bra praxis är att commit-meddelandena bör besvara frågan "if applied, this will…". Exempelvis: "(if applied, this will) create mobile menu toggle button". Delen "if applied, this will" exkluderas - commit-meddelandena ska vara kärnfulla. Behöver du skriva mycket text är commit:en för stor. Gör hellre flera commits i sådana fall.

Steg 2. Initial backlog refining

Bryt ner uppgiften i issues i ett GitHub-projekt, se "Backlog refining"-avsnittet under vecka 4.

Glöm inte att du själv ska läsa igenom uppgiften och fundera på potentiella uppgifter innan er session (annars kommer den bli vääääldigt lång om alla kommer oförberedda).

Prioritera er backlog; viktigaste uppgifterna först (t.ex. dom som gör att ni kommer igång).

PS. Glöm inte att komma överens om hur er sida ska se ut 😉 Det räcker med en enkel linjeteckning i t.ex. Microsoft Whiteboard i Teams, men alla bör vara med på hur flödet i programmet fungerar och var element ska placeras.

Steg 3. Kör en planning poker

Se till att ni har i alla fall tillräckligt med uppgifter för er första vecka. T.ex. om ni är 4 personer och 8 SP motsvarar en veckas arbete, då ska ni ha 4 * 8 = 32 SP att tillgå. Ju mer ni hinner estimera desto bättre såklart (kortare sessioner framöver).

Steg 4. Gör en sprint-planering

Kom överens om vad ni ska göra först. Det bör vara hyfsat snabbt och lätt om ni har gjort er refining ordentligt.

Flytta dessa uppgifter till er "Ready"-kolumn så att man kan börja arbeta med dessa.

Steg 5. Skaffa API-nyckel till OMDB

Skaffa en (förslagsvis gemensam) API-nyckel hos OMDB. ⚠️ OBS! Gratisversionen tillåter max 1 000 "förfrågningar" om dagen, så se till att spara ner en lokal kopia av resultaten som ni kan "labba" med (det är 250 "siduppdateringar" per person per dag, där slår ni snabbt i taket). Glöm ej att aktivera nyckeln via länken i mailet.

Steg 6. Dokumentera era daily standups & koda

I repot ska ni dokumentera era daily standups. Det räcker med kortfattade meningar enligt mallen ni har fått.

Koda på.

Steg 7. Retrospective i slutet på veckan & ny sprint planning

I slutet på veckan (förslagsvis fredag) håller ni ett retrospektiv. Följ eller anpassa mallen som ni har fått i repot.

Upprepa sedan backlog refining, planning poker, sprint planning, retrospective tills grupparbetet är slut.

Steg 8. Dokumentera projektet

I er README.md ska ni göra följande:

• Beskriva projektet
• Infoga en skärmdump på projektet
• Skriva vilka tekniker ni har använt (t.ex. "Badges")
• Länka till deltagarnas GitHub-profiler under avsnittet "Authors" (eller "Deltagare" om ni föredrar att dokumentera på svenska)
• Lessons Learned (några få meningar om vad ni lärt er)

Här, här och här kan ni se ett exempel på bra dokumenterade skolprojekt.

(Tro mig, ni VILL dokumentera direkt efter varje projekt så att ni har era "portfolio case" redo när ni ska söka LIA. Man kommer aldrig att gå tillbaka och göra ett lika gediget arbete med dokumentationen som precis efter projektet, och det är ett ess att ha i kortärmen när ni konkurrerar med andra på arbetsmarknaden)

Steg 9. Förbered redovisning

Redovisningen ska ta max 10 minuter. Ni får 2 minuter till teknikstrul (skärmdelning funkar inte, osv.). Dvs. 12 minuter.

Under redovisningen ska ni:

• Visa det visuella resultatet av vad ni har gjort
• Berätta 3 saker som var utmanande med grupparbetet (och hur ni eventuellt löste det)
• Berätta 3 saker om agila metoder utifrån ert grupparbete, typ vad funkade, vad funkade inte, osv.
• Berätta 3 saker ni ska göra annorlunda nästa gång
• Valfria inslag

Code review/Pull Request

• Ni ska också utföra minst 2 code reviews per person under projektets gång.
• Ni ska också skapa minst 2 pull requests per person under projektets gång.

Detta innebär att när ni är klara med en uppgift, så skapar ni en "pull request" för att "merge:a in" (sammanfoga) er kod till main-branchen. De andra i gruppen kommer sedan att titta på er kod och skriva eventuell återkoppling. Ungefär som jag har gjort med Feedbacken, med den skillnaden att ni sedan då merge:ar in koden i main.

Det är viktigt att träna på att läsa och förstå andras kod, samt att våga ställa frågor på sådant man inte förstår. Det gör att koden blir bättre - för alla.

• Otydlig loop? Skriv ut den i ett längre format. Kognitiv belastning när man läser kod är bara jobbigt.
• Oklar variabelnamngivning? Föreslå något bättre!
• Saknar en funktion dokumentation? Säg det!

Ni vet hur man blir "hemmablind" för sitt eget arbete. Reviews motverkar detta och på så vis håller vi också kodbasen bättre!

⚠️ Avsätt minst 30 minuter/dag för att faktiskt gå igenom andras kod så att man inte "fastnar" för att en feature som man har gjort inte blir godkänd. Det är mycket frustrerande att behöva vänta 2-3 dagar på att ens kamrater/kollegor har tid att granska ens kod.

itslearning

Glöm inte att lämna in länken till gruppens repo på itslearning och infoga alla gruppmedlemmars namn i inlämningen på itslearning.

Detta ska finnas med

• En sida med CSS (eller Sass) där användaren kan utföra uppgiften beskriven ovan.
• Om platsen inte kan bestämmas med geolocation så ska användaren få ett meddelande om detta (felhantering).
• Om platsen inte kan bestämmas med geolocation så ska användaren erbjudas möjlighet att manuellt ange en plats (t.ex. välja från en dropdown).
• Om endera API inte fungerar så ska ett felmeddelande visas. Var gärna användarvänlig i felmeddelandet, dvs. skriv inte "Error 123 inträffade", utan exempelvis: "Vädret kunde inte bestämmas på grund av att vi inte kunde ansluta till SMHI.".
• Om ni använder Vite (frivilligt!), lagra API-nyckeln i en .env-fil.
• Uppgiften ska ha med alla punkter från beskrivningen.
• Sidan ska vara tillgänglighetsgranskad och -anpassad.
• Hantera om filmen inte finns - t.ex. om ID:t inte existerar, på valfritt sätt.
• Ett "offline-läge", dvs. där man kan använda dummy-data från respektive API för att inte överbelasta förfrågningarna/bli blockad. Exempelvis en variabel som heter const DEVELOPMENT = true; (eller om ni använder Vite så kan ni köra import.meta.env.DEV (boolean)).
• Sidan ska vara responsiv: anpassa för mobil, tablet och desktop. Se t.ex. breakpoint-förslag här.
• Skärmdumpar på slutresultatet i README:n. Om ni använder Vite så ska sidan vara publicerad på GitHub Pages (kör ni fast så hör av er så hjälper jag till).
• Slumpa fram ett film-ID: generera en "random" siffra och prefixa med "tt". Prova några gånger och validera att det faktiskt fungerar mot ID:n på IMDB. T.ex. kan ni ändra den sista parametern i URL:en: https://www.imdb.com/title/tt0166924
• Våga be om hjälp med klurigheter och om ni kör fast! Låg tröskel! Endast 🥔-frågor välkomna!
• ❗️Viktigt! Du kommer inte att bli godkänd på grupparbetet om du t.ex. bara har gjort HTML och/eller CSS. Det är viktigt att alla gruppmedlemmar kodar såväl HTML, CSS som JavaScript. Det går alltså inte att bara "ta" CSS-uppgifter från backlogen, exempelvis. Även om det är ett grupparbete så får man i slutändan ett individuellt betyg (jag kommer att titta på individuella commits till grupparbetet), så det går inte att "flyta med" och förvänta sig att gruppen gör jobbet åt en. Det går att se commits och den kod man skrivit individuellt på GitHub i en "Insights"-flik, ⚠️ så använd Co-authoring-funktionen om ni kodar ihop!

📚 Resurser

Kodexempel SMHI

Här är ett exempel för att hämta data för Gustav Adolfs Torg i Stockholm, som har latitud 59.3293 och longitud 18.0686:

const latitude = '59.3293';
const longitude = '18.0686';

const apiUrl = `https://opendata-download-metfcst.smhi.se/api/category/pmp3g/version/2/geotype/point/lon/${longitude}/lat/${latitude}/data.json`;

/**
 * This function fetches weather data for a given location
 * from the SMHI API.
 */
async function getWeatherData() {

  // Get all weather data for the location provided in the API URL,
  // and return the JSON data so we can access it.
  const weatherData = await fetch(apiUrl)
    .then((data) => {
      return data.json();
    });

  // console.log('All available data', weatherData);

  // The JSON object contains a key named "timeSeries", which contains the
  // forecasts for the next hours (and days).
  const hourlyForecasts = weatherData.timeSeries;

  // The weather for the next hour is stored in the first "slot" in the array
  const weatherInOneHour = hourlyForecasts[0];
  logWeatherData(weatherInOneHour, 1);

  // The weather for the second hour is stored in the second "slot" in the array
  const weatherInTwoHours = hourlyForecasts[1];
  logWeatherData(weatherInTwoHours, 2);
}

/**
 * This functions prints weather data to the console.
 * @param weatherInfo - A weather info object from SMHI
 * @param hour - A number to represent the future hour, used to print the console message
 */
function logWeatherData(weatherInfo, hour) {
  const weatherParams = weatherInfo.parameters;

  console.group('☁️ Weather forecast in', hour, 'hour(s)');

  const time = new Date(weatherInfo.validTime);
  console.log('Forecast for', time);

  const temperature = weatherParams.find(data => data.name === 't');
  console.log('🌡️ Temperature:', temperature.values[0]);

  const precipation = weatherParams.find(data => data.name === 'pmean');
  console.log('🌧️ Precipation:', precipation.values[0]);

  console.groupEnd();
}

getWeatherData();

OMDB-exempel för en specifik film

const OMDB_API_KEY = 'abcdef'; // TODO: Lägg in API-nyckeln här
const randomMovieId = 'tt0166924'; // TODO: Slumpgenerera denna typ av ID med "tt0" i början

async function getMovieInfo() {
  // Fetch movie info and return the JSON result
  const apiRequest = await fetch(`https://www.omdbapi.com/?apikey=${OMDB_API_KEY}&i=${randomMovieId}`)
    .then((data) => data.json());
  
  console.log('Here is all the info I have about the movie:', apiRequest.Title);
  
  // Print the movie info to the console
  console.table(apiRequest);
}

getMovieInfo();

• LatLong Finder - För att testa/hårdkoda in GPS-koordinater
• readme.so - Inspiration för en bra README