# Projektiblogi-pohja
## Ketterä kehitysprojekti, syksy 2021
### Tekijä: 2006296, Juha Oinonen

## Viikko 11

Tutustumista projektiin, aloitusluento ja aloituspalaveri.

## Viikko 12

- Työkalujen haltuunotto
- Kehitysblogi
- Clockify
- Viestintäkanavat
- Azure Devops
- Yhteys hollantilaiseen opiskelijapariin tehtävää varten

Otin pariin yhteyttä maanantaina ja sain tiistaina viestin että hän ei suorita enään kurssia heidän puolellaan. Keskiviikkona tuli viesti että parit menivät uudestaan ja otin yhteyttä "ryhmän" jäseneeni Suomen puolella, jonka kautta sovimme keskiviikon ja torstain aikana meille sopivat ajat, jonka jälkeen otimme yhteyden uuteen Hollantilaiseen pariin ja sovimme ajan viikolle 13.

Muuten viikko meni aikalailla tehtävänantoon tutustuessa. Olen todella huono keksimään mitä kirjoittaa näihin kehitysblogeihin, joten toivottavasti ei tule liian typpeitä päivityksiä.


## Viikot 13-14 (Sprint 1, 29.03-04.04)

Tälläviikolla työskentelin tutustumaan uudelleen NodeJS ja Express-työkaluihin, opetelemaan Azure DevOpsin käyttöä koska se on itselleni kokonaan uusi työkalu sekä käytin aikaa projektin esittelyn suunnittelemiseen sekä esittelyyn hollantilaiselle parille. Sain valmiiksi tehtyä sprintin aikana niin sanotun "Hello World"-api tuotoksen Expressillä. Viikon aikana myös tutustuin parhaisiin NodeJS-käytäntöihin, arkkitehtuuriin ja erilaisiin ohjelmointimalleihin joita voisimme käyttää projektin aikana.

Sitten näitä haluttuja aiheita, käyn vaikka läpi tasot 1 ja 3 (ja osassa 5) näin alkuun:

### Työpanokseni ja sitoutumiseni projektiin

Varmistan omien tehtävien suoritetuksi tulemisen pyrkimällä arvioimaan työtehtävät mahdollisimman realistisesti, mieluusti yläkanttiin, jotta ajallisesti minulla riittää aikaa tehdä ne. Pidän itseni selvillä työn jakaatumisesta käyttämällä hyväksi Taskboardia Azuresta, sekä osallistumalla projektiryhmän kokouksiin. Varmistan seuraavani ryhmän ohjeita ja sovittuja suunnitelmia olemalla osa niiden kehitystä ja sitoutumaan niihin parhaani mukaan.

Tarkastelen omien työtehtävien suhdetta projektin kokonaistavotteisiin Azuren tarjoamien työkalujen avulla, kuten Burndown- ja velocity-kuvaajan avulla. Arvioin ryhmän työnjaon tasapuolisuutta ottamalla itselleni tehtävät joita uskon itse pystyvän tekemään sprintin aikana sekä auttamaan muita mahdollisten ongelmatilanteiden saapuessa. Varsinaista holhousta en tule tekemään projektin aikana vaan uskon että jokainen tekee parhaansa projektin eteensä. Tutustun muiden ryhmien toimintaan tarjottujen tilaisuuksien kautta parhaani mukaan.

### Oman työn seuranta ja kehittäminen

Pidän kirjaa kaikesta projektiin kuuluvasta työajasta (kokonaistyöaika, kehittäminen, yhteydenpito) Clockify-työkalun avulla. Valitettavasti tästä ajasta ei tule kuitenkaan ilmi koko projektiin käytetty aika kun tykkään työskennellä erilaisissa sarjoissa tai työryppäissä (1h, 3h, 6h jne esimerkiksi), joissa ei tule ilmi niitä pieni taukoja joita kokonaisen työpäivän aikana tulisi aina vastaan. Erottelen työtehtävät Clockifyssä työtehtävien perusteella. Tällähetkellä en varmista työtehtävien jakaantumista järjestelmällisestki koko projektin ajalle tai työajan rahallista kokonaisarvoa.

### Reflektio- ja itseohjautuvuusosaaminen

Työroolini tässä projektissa on kehittäjä ja alaroolina back-end puolen kehittäjä, joka toimii NodeJS ja Express työkalujen avulla luodakseni API:n, jota front-end kehittäjät voivat käyttää hyväkseen. Työrooliini kuuluu osallistua SCRUM-palavereihin, kehittää ohjelmistoa eteenpäin erilaisten määrättyjen työtehtävien avulla ja varmistaa niiden sisältö käyttäen hyväksi Azure DevOps-palvelua tai kysyä lisää infoa tarvittaessa tuoteomistajalta.

Kehittäjänä työroolini sijoittuu projektin kokonaistoiminnassa toiminnallisuuden luomiseen ja on vastuussa että saadaan jokaisen sprintin aikana kehitettyä projektia eteenpäin.

Pyrin varmistamaan kehittäjänä että saamme kehitettyä projektia eteenpäin mahdollisimman sujuvasti mahdollisen palautteen avulla. Omat vahvuuteni kehityksessä on vahva into oppia aina uutta ja opin asiat yleensä todella nopeasti. Olen myös todella nopea työskentelijä kun olen sisäistänyt asian. Heikkouteni tai kehityskohteeni projektityöskentelijänä on että haluaisin tehdä kaiken aina itse, tai oman standartin mukaan. Kehittäjänä haluan myös tehdä kaikesta mahdollisimman jatkokehitettävän tai dynaamisen, jolloin työ jossa normaalisti menisi noin 30 minuuttia voi venyä vaikka 6 tuntiin.

### Omien työtehtävien hallinta

Kehitystiimin jäsenenä teen tietenkin kehitysjonon sisällöstä julkaisukelpoista toiminnallisuutta. Kehittäjänä myös osallistun sprintin suunnitteluun, daily-kokouksiin ja sprintin katselmukseen. Sprintin suunnittelu valitaan seuraavaan sprinttiin mahdolliset työt tuotteen kehitysjonosta. Kehitystiimin harteilla on myös pilkkoa nämä työt pienempiin palasiin, joista kokonaisuus muodostuu. Pidän kirjaa työtehtävistäni käyttämällä Azuren Boards-toimintoa.

Tällähetkellä ei ole vielä ilmentynyt kehityskohteita tai vahvuuksia työtehtävien hallinnassa, kun olemme vielä niin alkutekijöissä tämän projektin suhteen.

### Oma viestintä

Olen säännöllisesti yhteydessä ryhmään. Käytämme tässä hyväksi Discrod-ohjelmistoa jossa käymme kaikki palaverit läpi, tai tarpeen vaatiessa vastaan kysymyksiin tai viesteihin myös tekstimuodossa. Vastaan myös ryhmän jäsenten viesteihin nopeasti ja aina asiallisesti, kun minulla on jotakin lisättävää keskusteluun tai ratkaisu kysymykseen. Arvioin omaa viestintääni itsenäisesti aina viestiä kirjoittaessa (kuinka tämä viesti havaitaan) tai myöhemmin viestiä lukiessa jos tulee mieleen että se olisi voitu ymmärtää myös toisella tavalla. Arviointia myös tapahtuu sprintin katselmuksessa tarpeen mukaan.

Varmistan omalta osaltani ryhmän keskinäisen viestinnän riittävyyden palavereiden aikana tai ottamalla yhteyttä meidän sovittujen keskustelukanavien kautta. Tämä sama myös koskee arviointia ja kehittämisideoita viestintäkäytänteiden käytössä. Meillä on myös viestintäsuunnitelma tehty, jota voimme tarpeen vaatiessa muokata ja sopia lisää käytänteitä.

Tällä hetkellä en ole vielä saanut palautetta viestinnästä.


***

## Viikot 14-15 (Sprint 2, 06.04-19.04)

Tässä sprintissä alettiin saamaan kehitystä jo eteenpäin:

Tässä sprintissa otin kehityskohteeksi yhteydenottolomakkeen toiminnallisuuden backendin puolella, eli sähköpostin luominen dynaamisesti muuttujien avulla. Käytän tässä hyväkseni Nodemailer-moduulia joka on julkaistu MIT-lisenssillä. Käytän myös hyväkseni gmailin smtp-palvelua prototyypin kehityksessä, koska uskon että se on tarpeeksi yleinen protokolla että semmoinen löytyy asiakkaalta projektin luovutusvaiheessa. Gmailin sisältä täytyi muistaa ottaa pois secure connections (tai hyväksy vähemmän turvalliset yhteydet) jotta sain smtp:lla yhteyden ja sähköpostin lähetettyä.

Nodemailerissa suurin osa ohjeista löytyi callbackeja käyttämällä, joten tutustuin niihin uudelleen, mutta jotta saataisin luettavampaa ja selvempää koodi tutkin myös että onnistuuko uudella async/await-toiminnolla teko. Hetken googleteltua tämä mahdollisuus löytyi ja muutin toiminnallisuuden käyttämään tätä.

Seuraavaksi lähdin työstämään HTML:n luomista dynaamisesti, jotta saataisiin personaallinen viesti tehtyä ja kaikki tarpeellinen tieto eteenpäin. Tutkin paljon erilaisia tapoja exportata tekstiä/objekteja ja lopulta päädyin tekemeään tämän JavaScriptin uusien luokkien ja constructorin avulla.

Samalla myös kertasin vanhaa oppimaa hieman ongelmatilanteiden avulla. Ensin koodia debugatessa koitin ajaa pelkästään tiettyä moduulia, mutta .env tiedosto oli väärässä paikassa (pääkansio moduulin sijasta).

Kun sain ensimmäisen version tehtyä, rupesin refaktoroimaan koodia. Kun minulla ei ollut paljon kokemusta ohjelmonnista, tyydyin yleensä vain siihen ensimmäiseen versioon joka syntyi koodatessa ja ajatus meni asiasta toiseen. Nyt kun olen saanut jo hieman kokemusta alle, siirryn ensimmäisen version jälkeen refaktoroimaan luotua funktiota ja pyrin käyttämään toimivaksi tunnettuja toimintatapoja kuten jokaisella funktiolla tai luokalla pitäisi olla vain yksi tehtävä, parametrit objektina jos ne liittyvät toisiinsa, kaikki toiminnallisuus try catch sisään ja otetaan virheet talteen, heitetään virhe virhetilanteissa JA otetaan virhe ylös ongelmatilanteissa. Tässä kohtaa myös tutkin hieman lisää try catchien toimintaa JavaScriptin sisällä, kuten keskeyttääkö se koodin ajon vai tarvitaanko vielä erikseen return-käsky (ei tarvita).

Näiden hommien jälkeen saatiin tieto, että mahdolliset turvallisuusosaaminen täytyy ottaa mukaan näihin projekteihin (ja tietenkin täytyy). Koska olen ainoa backendin puolella jolla on hieman kokemusta ohjelmoinnista, otin tämän omalle vastulleni tähän ja seuraavaan sprinttiin. Tässä on hieman listaa mitä kaikkea otamme huomioon turvallisuuden varmistamiseksi ja kirjoitan ensi viikolla enemmän minkä takia tämä on tärkeää:

* Käyttäjien antaman syötteen validoiminen sekä sanitointi (SQL-inject)
https://github.com/mikeerickson/validatorjs
https://www.npmjs.com/package/escape-html
Parameterisoidut queryt
* Käyttäjien authentikaatio
OAuth, Bcrypt, 2FA
https://www.npmjs.com/package/node-2fa
https://www.npmjs.com/package/speakeasy
https://www.npmjs.com/package/bcrypt
* Ei kerrota virheilmoituksissa liikaa infoa, jota voidaan käyttää hyväksi pahantahtoisesti
* Tietojen lokaaminen ja seuranta
Helppo toteuttaa, vaikea tietää mitä tietoa tarvitaan
* Salaisuuksien kryptaus (voi ottaa mukaan CI/CD-pipelineen?)
Ympäristömuuttujat
* HTTP vastauksen headerien piilottaminen (helmet, cors)
https://www.npmjs.com/package/helmet
https://github.com/helmetjs/helmet#reference
* Jokainen api-kutsu vaatii pääsynhallintaa
* HTTPS pakottaminen
* Cross-Site Request Forgery
https://www.npmjs.com/package/csrf
* API-kutsujen rajoitus ja lokaaminen (brute force hyökkäykset)
https://www.npmjs.com/package/express-rate-limit
* Käytettyjen pakettinen turvallisuus
Ajetaan pakettimanagerin oma turvallisuustarkastus sekä päivitys tietyin väliajoin (esim. jokaisen sprintin päätteeksi)
npm audit
npm outdated
(snyk?)
https://www.nearform.com/blog/comparing-npm-audit-with-snyk/
* Kehitystyössä tietoturvalintterin käyttö
https://github.com/nodesecurity/eslint-plugin-security
* Kaikissa mahdollisissa paketeissa LTS-version käyttö
* Ei ajeta nodea roottina
* Vaihdetaan NODE_ENV ympäristömuuttuja productioniin

Kysymyksesi jaa myös vielä esimerkiksi mitä tehdään GDPR kanssa yrityksen/muiden tietojen kanssa. Tätä täytyisi mahdollisesti tutkia vielä lisää.


## Viikot 16-17 (Sprint 3, 20.04-03.05)

Aloitan tämän sprintin kehitysblogin ottamalla selvää tarkemmin tietoturvahaasteista ja minkä takia ne vaikuttavat meidän projektiimme ja kuinka voimme torjua niitä.

**SQL-injektio**
Hyökkäyskohde: Tietokanta
Kuvaus: Hyökkääjä käyttää haavoittovuutta koodissa, jossa ei tarkisteta käyttäjän syötettä ennen tietokantakomentojen suorittamista.
Kuinka torjutaan: Parameterisoidaan käyttäjän antama syöte
Esimerkkejä: [MySQL](https://www.w3schools.com/sql/sql_injection.asp), [MongoDB](https://dev.to/nulldreams/beware-of-the-findone-function-15g)

**CSRF-haavoittovuus**
Hyökkäyskohde: Authentikoituneen käyttäjän haavoittovuus
Kuvaus: Hyökkääjä käyttää hyväkseen kirjautunutta käyttäjää ja saa hänet tekemään toimintoja, joita käyttäjä ei ole tarkoittanut tekevän.
Kuinka torjutaan: csurf-moduuli(?), vielä mietinnässä.

**Liiallinen tiedon antaminen virheilmoituksessa.**
Hyökkäyskohde: Tiedon saaminen ja sen hyödyntäminen
Kuvaus: Käyttäjän antaman syötteen perusteella palautetaan ylimääräistä tietoa, jota hyökkääjä voi käyttää hyväkseen.
Kuinka torjutaan: Rajoitetaan tiedon anto ja/tai peitetään tieto että ei saada yksityiskohtaista tietoa käyttäjistä.
Esimerkkejä:

"Käyttäjänimeä ei löydy"
Jos ilmoitetaan että käyttäjää ei löydy, hyökkääjä tietää että tällästä käyttäjää ei vielä ole ja hän saattaa koittaa lähteä luomaan käyttäjän kiristystarkoituksessa tai yksinkertaisesti jatkaa seuraavan käyttäjänimen tarkistusta.

"Antamasi salasana on virheellinen"
Tämä ilmoittaa että käyttäjä on oikea mutta salasana on väärä - lähdetään siis tutkimaan muita mahdollisia tunnettuja salasanoja ja/tai koitetaan löytää se brute force hyökkäyksellä.

"Et voi käyttää edellistä käyttämääsi salasanaa"
Hyökkääjä lähtee käymään muita palveluita läpi samalla tunnuksella ja samalla salasanalla - salasana on joskus ollut toimiva, joten käyttäjä on voinut käyttää sitä muualla.

Täytyy siis ottaa aina huomioon virheilmoitusta antaessa käyttäjällä minkälainen tieto on tarpeellinen ja antaa pelkästään se. Tässä esimerkissä ilmoitettaisiin että Käyttäjä ja/tai salasana on virheellinen ja ei anneta näin ylimääräistä tietoa.

**HTTP-otsikointi (headers)**
Hyökkäyskohde: Selaimen HTTP-otsikot
Kuvaus: Hyökkääjä käyttää hyväkseen annettua tietoa ja/tai haavoittovuuksia ladatessa dataa muilta sivuilta
Torjunta: Rajaamme tiedon antamista/sisällön lataamista muilta sivuilta
Moduuli: helmet

[Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)
Tarkoituksena on torjua hyökkäys, joka hyödyntää selaimen luottamusta muihin sivuihin, joilta ajettavat scriptit voidaan ladata. Torjumme myös hyökkäyksen joka koittaa etsiä dataa lähetettävien pakettien välillä pakottamalla HTTPS-protokollan käyttöön ja asettamalla cookiet "secure"-muotoon.

[Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer)
Hyökkäys voi muodostua kun esimerkiksi ilmoitamme meidän käyttäjän tulevan käyttäjän salasana resetointisivulta vierailemaan jotakin ei-luotettua sivua jonka takia tämä ei-luotettu sivu voisi saada pääsyn käyttäjän tietoihin/asettamaan oman salasanan tälle käyttäjälle. Poistamme tämän mahdollisuuden kieltämällä antamaan tätä tietoa eteenpäin (no-referrer).

[Strict-Transport-Security](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security)
Hyökkäysmonetti jota torjumme tässä on Man-in-the-middle attack eli jokin ei-luotettava palvelin toimii välikätenä meidän palvelun ja käyttäjän välissä, joka luo turvallisuuden tunnelman mutta todellisuudessa kaikki meidän ja asiakkaan lähettämä data tallentuu hyökkääjän käyttöön. Tämä torjutaan pakottamalla HTTPS käyttöön hsts-asetuksella.

[X-Content-Type-Options](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options)
MIME-tyypin nuuhkinnan estoon. "nosniff"

[X-DNS-Prefetch-Control](https://https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-DNS-Prefetch-Control)
Ei sallita ennaltalataamista linkkeihin, joita käyttäjä VOISI käyttää. Mahdollisesti pienentää vähän suorituskykyä mutta lisää käyttäjän tietoturvaa.

[X-Download-Options](https://docs.microsoft.com/en-us/archive/blogs/ie/ie8-security-part-v-comprehensive-protection)
Torjutaan Internet Explorer 8-hyökkäys, jossa tietyt ei-turvalliset lataukset saattoivat ajaa ei-toivottua koodia.

[X-Frame-Options](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options)
Tällä torjutaan hyökkäys, jossa käyttäjä luulee klikkaavansa jotakin linkkiä, mutta todellisuudessa klikkaus osuukin johonkin pahantahtoiseen linkkiin. Lisää tietoa [täältä](https://en.wikipedia.org/wiki/Clickjacking).

X-Permitted-Cross-Domain-Policies
Kerrotaan tietyille selainasiakkaille meidän linjauksemme muiden domainien sisällön lataamisestä.

X-Powered-By
Emme kerro maailmalle minkä tekniikan alla meidän sovellus pyörii (Express). Tästä löytyy paljon keskustelua että tämä ei tarjoa varsinaisesti turvallisuushyötyä - mutta kaikki esteet mitä eteen laitetaan on plussaa.

[X-XSS-Protection](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection)
Auttaa vanhojen selainten turvallisuutta. Lopetetaan sivuston lataus kun tunnistetaan hyökkäys ladattaessa muilta sivuilta sisältöä.

**API-kutsujen pääsynhallinta**
Hyökkäyskohde: API-kutsut, joissa ei vaadita käyttäjän tunnistautumista
Kuvaus: Käydään läpi kaikki tunnetut API-reitit ja koitetaan hyväksikäyttää pääsynhallinnan puuttumista että saadaan tuhoa aikaan tai kerättyä suojattua dataa
Kuinka torjutaan: Vaaditaan tunnistautuminen jokaista API-kutsua vastaan
Moduuli: Oma middleware

**Brute Force**
Hyökkäyskohde: API-kutsut
Kuvaus: Pommitetaan APIa tuhansilla kutsuilla, yrittämällä kirjautua vaikka erilaisilla salasanoilla sisään
Moduuli: Express-rate-limit

**DDoS**
Hyökkäyskohde: Vastaanotettavat kutsut
Kuvaus: Pommitetaan palvelinta kaikenlaisilla tuhansilla paketeilla/api-kutsuilla, jotta saataisiin palvelin kaatumaan tai negatiivisesti vaikuttamaan oikeiden käyttäjien kokemukseen
Kuinka torjutaan: Asetetaan rajoitus kuinka monta pakettia/kutsua esimerkiksi 1 IP voi lähettää tietyn ajanjakson sisällä.
Moduuli: Express-rate-limit

**Salaisuuksien julkistaminen**
Hyökkäyskohde: Salaisuuksien jakaminen
Kuvaus: Hyökkääjä käyttää hyväkseen jonnekkin julkisesti laitettua salaisuutta, joka on hyvin usein esimerkiksi git-palvelimelle epähuomiossa laitettu ympäristömuuttuja (.env).
Kuinka torjutaan: .env sisällytetään .gitignore-tiedostoon ja tarjotaan .sample-env tiedosto jonka käyttäjä itse täyttää asennusvaiheessa
Moduuli: dotenv

**Käyttäjän tunnistaminen**
Hyökkäyskohde: Selkokielinen salasana, tietokantamurto
Kuvaus: Hyökkääjä pääsee käsiksi selkokieliseen salasanaan, jonka avulla hän voi saada paljon tuhoa aikaan
Kuinka torjutaan: Käytetään jo-hyväksi todettuja ratkaisuja, eikä lähdetä toteuttamaan omaa tietoturvaratkaisua
Moduuli: bcrypt, speakeasy

**Logaus ja monitorointi**
Hyökkäyskohde: Palvelimen ylläpitäjä ei pidä kirjaa käyttäjistä
Kuvaus: Palvelimella ei ole mitään tapaa tarkistaa kuka/mikä yrittää käyttää palveluita ja kuinka he/se yrittävä hyväksikäyttää palveluita
Kuinka torjutaan: Logataan kaikki yhteydenotot tiedostoon sekä palvelimen konsoliin seurantaa varten.
Moduuli: morgan

**Pakettien turvallisuus**
Hyökkäyskohde: Vanhat paketit, joissa on ilmennyt tietoturvaongelmia
Kuvaus: Ei-päivitetyt paketit voivat olla todella suuri riski tietoturvan kannalta, kun niistä löytyy haavoittovuuksia
Kuinka torjutaan: Ajetaan npm audit & npm outdated tietyin väliajoin. Koitetaan korjata mahdolliset tietoturvaongelmat npm audit fix-komennolla, tai vaihdetaan paketti johonkin toiseen toimivaan ratkaisuun. Jos paketti on vanha (outdated) pyritään se päivittämään uusimpaan LTS-pakettiin (Long-term support).

**Noden ajaminen roottina**
Hyökkäyskohde: Mikä tahansa tietoturva-aukko, joka antaa oikeuden toimia palvelimella
Kuvaus: Hyökkääjä saa palvelimen kautta oikeudet koko palvelimen käyttöön
Kuinka torjutaan: Teemme tietokannalle JA palvelimelle omat käyttäjät, joille emme anna ylimääräisiä oikeuksia.

**Yleinen turvallisuus**
NODE_ENV täytyy asettaa productioniin, jos käytetyissä paketeissa käytetään esimerkiksi joitain oikoteita tai suorituskykyä parantavia ominaisuuksia jotka eivät tietoturvallisesti ole aivan oikein.

On myös erilaisia tietoturvalinttereitä jotka osaavat ilmoittaa mahdollisista tietoturvariskeistä ohjelmakoodia tehdessä. Tässä on yksi [esimerkki](https://github.com/nodesecurity/eslint-plugin-security).

### Käyttäjän- ja pääsynhallinta

Tietoturvatutkimuksen ja toteutuksen jälkeen lähdin työstämään käyttäjän- ja pääsynhallintaa. Tarkoituksena oli luoda turvallinen kirjautuminen ylläpitäjälle, jonka kautta hän voi lisätä, poistaa tai muokata yhteistyökumppaneita turvallisesti, ilman mahdollisuutta väärinkäytölle. Olen jo aikaisemmin tutustunut aiheeseen parin projektin kautta, mutta kertasin kuitenkin alkuun aihetta, jotta mikään osa-alue ei jää pois huonon muistin takia. Käyttäjänhallinta toimii JSON Web tokeneiden avulla joita luon jsonwebtoken-moduulilla. Käyttäjän salasanan hashaus ja salttaus toimii bcrypt-moduulilla joka on tällä hetkellä suosituin toteutus npm-pakettien kanssa.

Tämänhetkinen toteutus sisältää seuraavat ominaisuudet:
* Kirjautuminen (annetaan tokenit + tallennetaan refresh token tietokantaan)
* Uloskirjautuminen (poistetaan refresh web token)
* Kirjautumisen uusiminen (refreshTokenilla, voi käyttää "muista minut"-toimintoon jotta käyttäjä ei joudu kirjautumaan 15min välein uudestaan)
* Salasanan & sähköpostin vaihto
* Salasanan nollauksen pyyntö
* Salasanan nollaus

Kuinka käyttäjänhallinta toimii käytännössä: Käyttäjä lähettää kirjautumistiedot (käyttäjänimi ja salasana) ja saa niitä vastaan pääsynhallintatokenin ja refreshtokenin. Pääsynhallintatokenia vaaditaan kaikissa tarpeellisissa API-kutsuissa Authorization-headerissa ja on voimassa 15 minuuttia. Refresh tokenia käytetään käyttäjän kun halutaan että käyttäjä pysyy kirjautuneena yli 15 minuuttia, ja hänen asiakasohjelmisto voi pyytää hiljaisesti taustalla vaikka joka 10minuuttia uuden pääsynhallintatokenin, jolla taas pystyy käyttämään API-kutsuja 15 minuuttia. Refresh tokenin kesto on joko 6 tuntia, tai jos käyttäjä kirjautuu ulos niin poistamme refresh tokenin tietokannasta, jolloin se ei enään toimi.

Jos käyttäjä unohtaa salasanan hän voi pyytää salasanan nollausta, joka lähettää sähköpostiviestin käyttäjän sähköpostiin, josta löytyy linkki varsinaista nollausta varten. Näin pyrimme varmistamaan että väärinkäyttöä ei pääse syntymään.

Näiden toiminnallisuuksien lisäksi otin käyttöön myös express-validator moduulin, jolla voimme vaatia tarvittavat objektit/muuttujat käyttäjän API-kutsuihin ja sanitoida ne middlewarena, ennekuin varsinainen toiminnallisuus lähtee ajoon.

Käydään tässävälissä taas apukysymyksien avulla hieman läpi yksilöarviointia:

### Työpanokseni ja sitoutumiseni projektiin
#### Taso 1
Varmistan omien tehtävien suoritetuksi tulemisen osallistumalla Sprinttien suunnittelun ja aktiivisesti keskustelemalla mitä uskon että saamme tuotettua sprintin aikana pysymällä tässä. Omien tehtävien varmistus myös tapahtuu Azuren Sprint-boardilla, josta näen reaaliajassa mitkä tehtävät minulle on sijoitettu.


Samalla myös varmistan että ryhmän työ jakaantuu ryhmän jäsenten kesken varmistamalla että kaikilla on työtä ja osaamista tuottaa tämä työ sprintin suunnittelussa sekä myös back-end palavereissa, jossa jaan omaa osaamistani ja katsotaan tarkemmin kuinka toteutukset lähdetään viemään eteenpäin.

Näiden todentaminen löytyy Azuren wikista, sprinttien suunnittelupalavereista:
https://dev.azure.com/tiko-toimeksiantoprojekti2021/R3/_wiki/wikis/R3.wiki/50/Sprinttien-suunnittelut-ja-retrot

Varmistan seuraavani ryhmän ohjeita ja sovittuja suunnitelmia olemalla osana niiden suunnittelua ja sitoutumalla niihin.

#### Taso 3
Tarkastelen omien työtehtävien suhdetta projektin kokonaistavotteisiin muun muassa velocity ja burndown-chartilla, joka on minun dashboardillani.


Ryhmän työnjaon tasapuolisuuden arviointiin en varsinaisesti ota huomioon, muutakuin patistamalla ihmisiä tekemään sovitut asiat tarvittaessa. Jokaisella ryhmänjäsenellä pitäisi olla oma vastuuntunto, jotta saa hommat hoidettua oman kapasiteettinsä mukaan ja pyritään pitäytymään siinä.

Minulla on ollut 2 aikaisemmassa projektissa kontollani melkein koko kehitystyö ja olen tyytyväinen kunhan saadaan projekti ryhmänä kasaan ja ei tule burnouttia projektin loppuun. Työmäärän arvioinnissa käytän apuna Clockifyn tuntimäärätarkkailua kuinka paljon kukin henkilö on panostanut projektiin tietyin väliajoin.


Tutustun toisten ryhmien toimintaan osallistumalla mahdollisuuksien mukaan ohjaajien järjestämiin tilausiiksiin kuten esimerkiksi viikolla 14 oli.

#### Taso 5

Tarkastelen omien työtehtävien merkitystä projektin kokonaistavotteisiin vertaamalla omia työtehtäviä haluttuun MVP-tuotteeseen ja esimerkiksi tässäkin käyttämällä hyväksi burndown ja velocity charttia.


Työnjaon tasapuolisuutta olen itse tietoisesti edistänyt antamalla muille tilaa tehdä haluamaansa työtä joka heitä kiinnostaa ja löytyy osaamista. Minulla on ollut paha tapa aikaisemmin haluta itse valita kaikki kiinnostava työ ja lähteä toteuttamaan sitä käyttä projektia eteenpäin, mutta tällä kertaa toimin enemmän "senior"-kehittäjänä ja jaan osaamista ja tehtävien tekoa eteenpäin erityisesti back-endin puolella meidän palavereissa.

Valitettavasti koska en saa tietooni muiden ryhmien käytänteitä kontaktien puuttumisen takia, en saa muita käytänteitä sisällytettyä meidän ryhmään. Minulla kuitenkin on jo jonkin verran kokemusta projektityöskentelystä sekä ohjelmistokehityksestä, pyrin jakamaan omia oppimia käytäteintä mahdollisuuksien mukaan projektin edetessä.

### Oman työn seuranta ja kehittäminen
#### Taso 1
Pidän kirjaa käyttämistäni ajasta Clockify-palvelussa, jossa erottelen kehittämisen ja yhteydenpidon erilaisten tagien ja kuvauksen avulla.


#### Taso 3

Erottelen työtehtävittäin käyttämän työajan tagituksen ja kuvauksen avulla, kuten edellisessä kuvassa näkyy.

Työajan järjestelmällinen jakaantuminen tapahtuu tehtävänhallinnan avulla. Teen tehtäviä omaan työtahtiin ja lopetan työteon jos alkaa tulla tuntumaan että tunteja alkaa tulla liikaa per päivä/viikko.

Arvioin käyttämäni työajan rahallista arvoa vain hyvin karkeasti. En ota ajanhallintaan mukaan aivan kaikkea ajatustyötä sekä pyrin vain ottamaan mukaan tarpeellisen tutkimustyön, joka vaaditaan projektin sen hetkisen työtehtävän toteuttamiseen.

#### Taso 5

Erottelen jokaiseen iteraation käyttämän työajan Clockify:n suodatintoiminnolla.


Iteraatioiden työajan rahallisen arvon arviointi tapahtuu samalla tapaa kuin kuin yleinenkin arviointi. Pyrin saamaan aikaan mahdollisimman paljon arvoa projektin työtehtävien kannalta priorisoimalla MVP-tuotteen priorisointilistaa, jonka meidän tuoteomistajamme on luonut asiakkaan kanssa.


Työajan seuraamisen soveltaminen uusien työtehtävien aika-arvioiden tekeminen jokaisessa iteraatiossa tulee luonnollisesti osana jokaista työtehtävää, kun saan paremman käsityksen omasta osaamisestani kokoajan töitä tehdessä. Näin saan joka iteraatio paremman ja paremman käsityksen omasta osaamisestani ja saan arvioitua tarkemmin käytettyä aikaa.

### Reflektio- ja itseohjautuvuusosaaminen

Kirjoitin mielestäni tästä aiheesta hyvin aikaisemmassa välietapissa, joten lainaan itseäni tässä vaiheessa.

"Työroolini tässä projektissa on kehittäjä ja alaroolina back-end puolen kehittäjä, joka toimii NodeJS ja Express työkalujen avulla luodakseni API:n, jota front-end kehittäjät voivat käyttää hyväkseen. Työrooliini kuuluu osallistua SCRUM-palavereihin, kehittää ohjelmistoa eteenpäin erilaisten määrättyjen työtehtävien avulla ja varmistaa niiden sisältö käyttäen hyväksi Azure DevOps-palvelua tai kysyä lisää infoa tarvittaessa tuoteomistajalta.

Kehittäjänä työroolini sijoittuu projektin kokonaistoiminnassa toiminnallisuuden luomiseen ja on vastuussa että saadaan jokaisen sprintin aikana kehitettyä projektia eteenpäin.

Pyrin varmistamaan kehittäjänä että saamme kehitettyä projektia eteenpäin mahdollisimman sujuvasti mahdollisen palautteen avulla. Omat vahvuuteni kehityksessä on vahva into oppia aina uutta ja opin asiat yleensä todella nopeasti. Olen myös todella nopea työskentelijä kun olen sisäistänyt asian. Heikkouteni tai kehityskohteeni projektityöskentelijänä on että haluaisin tehdä kaiken aina itse, tai oman standartin mukaan. Kehittäjänä haluan myös tehdä kaikesta mahdollisimman jatkokehitettävän tai dynaamisen, jolloin työ jossa normaalisti menisi noin 30 minuuttia voi venyä vaikka 6 tuntiin."

### Omien työtehtävien hallinta
#### Taso 1
Tälläkin tasolla lainaan itseäni aikaisemman perusteella:

"Kehitystiimin jäsenenä teen tietenkin kehitysjonon sisällöstä julkaisukelpoista toiminnallisuutta. Kehittäjänä myös osallistun sprintin suunnitteluun, daily-kokouksiin ja sprintin katselmukseen. Sprintin suunnittelu valitaan seuraavaan sprinttiin mahdolliset työt tuotteen kehitysjonosta. Kehitystiimin harteilla on myös pilkkoa nämä työt pienempiin palasiin, joista kokonaisuus muodostuu. Pidän kirjaa työtehtävistäni käyttämällä Azuren Boards-toimintoa."

Pidään kirjaa työtehtävien hoitamissa käyttämällä hyväksi Sprint-boardia.


#### Taso 3

Kehityskohteita oman roolini (kehitystiimin jäsen) työtehtävien hallinnassai:
* Voisin kuvata paremmin taskit ja niiden arvon jonka asiakas saa

Vahvuuksia:
* Osaan selittää selkokielellä mitä ja miksi tarvitsemme tietyn toiminnallisuuden
* Osaan selittää kuinka tietty toiminnallisuus on mahdollista toteuttaa muille kehittäjille
* Neuvon mielelläni muita kehittäjiä ja jaan osaamistani eteenpäin



* Ymmärrän hyvin mitä projekti vaatii valmistuakseen ja osaan kysyä kysymyksiä eteenpäin asiakkaalta tarvittaessa


#### Taso 5

Kehittämistä olen pyrkinyt saamaan eteenpäin kuvaamaan paremmin työtehtäviä Azuressa ja kommentoimaan taskin edistymistä.


Mahdollisena kehityskohteenä näen vielä että tämän kuvaamisen voisi muuttaa muotoon mitä arvoa asiakas saa tästä toiminnallisuudesta PBL-itemeiden kanssa.

### Oma viestintä
#### Taso 1

Olen säännöllisesti yhteydessä ryhmään niin Discordissa yleisen keskustelun kanssa sekä osallistumalla sovittuihin palavereihin mahdollisuuksien mukaan.

Tällähetkellä olen joutunut jättämään vain yhden ohjaajatapaamisen ja dailyn väliin, mutta kommunikoin kuitenkin Discordin kautta omat asiani koskien dailyä ja ilmoitin mahdollisesta poissaolostani kahdessa eri palaverissa.


Pyrin vastaamaan ryhmän jäsenten viesteihin aina mahdollisuuksien mukaan nopeasti sekä asiallisesti.

Tästä löytyykin pari esimerkkiä pari kuvaa taaksepäin.

Arvioin omaa viestintääni kokoajan aina viestittelyn jälkeen, sen aikana ja ennen viestin lähettämistä. Pyrin että viestini on aina asiallinen ja ajankohtainen ja että se antaa kaiken tarvittavan tiedon, ilman että sen voisi ottaa väärällä tavalla vastaan.

#### Taso 3

Pyrin varmistamaan ryhmän keskinäisen viestinnän riittävyyden projektin kannalta pitämällä Scrum Masterin puolta, kun hän haluaisi esimerkiksi pitää Dailyn mutta ryhmä ei välttämättä näe sen tarpeellisuutta.

Arvioin ryhmän viestintäkäytäntöjä ongelmatilanteiden tullessa ilmi - joita ei vielä hirvästi ole tullut esille. Esimerkiksi juuri tuo Daily-tilanne oli yksi tilanne jossa otin ohjat käteen ja varmistin että palaveri pidetään.

#### Taso 5

En ole vielä kokenut että oma viestintäni on ollut puutteellista ja en ole saanut palautetta siitä. Pyrin kuitenkin ottamaan tämän puheeksi seuraavassa ajankohtaisessa palaverissa ja pyydän palautetta jotta saan todennettua myös tämän kohdan. Otan myös mahdolliset kehittämistoiminnot mukaan seuraavassa päivityksessä.

## Viikot 18-19 (Sprint 4, 04.05-18.05)

Mitä tein:

* Reactiin tutustuminen
* Yhteydenottolomakkeeseen liittyen:
* Formin tekoon tutustuminen ja luonti
* Formin validoiminen
* Kuvan lähettäminen palvelimelle
* Kuvan vastaanotto palvelimelle
* Kuvan esittäminen Expressin avulla
* Kuvan lisääminen liitteeksi sähköpostiin ja sähköpostin lähetys
* Sähköpostin dynaaminen muokkaus muuttujien avulla
* Valmistautuminen kansainvälistä yhteistyötä varten


## Viikko 20 (Sprint 5, 18.05-24.05)

Mitä tein:

* Admin-paneelin luominen
* Kirjautuminen
* Yhteistyökumppanin lisääminen
* Yhteistyökumppanin muokkaaminen
* Yhteistyökumppanin poistaminen

Ongelmia:

formDatan muokkaamisessa ja tyhjentämisessä tuli ongelma kun koitin käyttää sitä monessa eri lomakkeessa. Korjasin ongelman kun refaktoroin koodia ja muutin ne eri tiloiksi.

Toinen ongelma tuli taulukkoa luodessa ja React ei tykännyt kun koitin esittää olioita JSX:ssä, mutta ongelma korjautui kun mappasin objektista toimivan version.

Yksi virhe kanssa mikä tässä sprintissä tuli oli "Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.", ja valitettavasti aika ei riittänyt löytämään ratkaisua tähän. Tämä ei kuitenkaan rikkonut toiminnallisuutta, joten jätin tämän mahdolliselle jatkokehittäjälle selvitettäväksi.


Mietteitä scrumista kehittäjänä:

Pidän scrumista ideana, mutta valitettavasti minun kokemukseni siitä ovat olleet koulun kursseilla hyvin vähäiset. Konseptit kuten product backlog, iteratiiviset sprintit ja boardit ovat erinomaisia, mutta niiden ylläpito vaatii paljon työtä niistä vastaavilta henkilöiltä. Valitettavasti kurssiprojekteilla niistä vastaavien henkilöiden kokemus, motivaatio ja vastuuntunto työstään ei ole ollut riittävää että tämä ei ole tapahtunut riittävässä määrin.

Näiden lisäksi kurssiprojekteissa on käynyt usein niin, että projektin toteutusteknologia on kokonaan uusi muille ryhmän jäsenille ja sen takia projektin toteutuksessa iso osa ajasta menee kokonaan sen opetteluun. Mielestäni projekteja pitäisi miettiä kokonaan uudelleen että ne vastaavat opetettua ja saadaan tuotettua asiakkaille mahdollisimman paljon arvoa ja samalla saadaan muutettua odotuksia realistisemmaksi.

Sprintit ja dailyt ovat hyvä tapa pitää projektin kehitystiimi ja asiakas yhteydenpidossa, mutta mielestäni tapaamisten pito liian usein tai väärin (dailyt venyvät) voivat olla harmillista projektin etenemistä koskien. Tässäkin kokenut tuoteomista ja scrummaster voivat ratkaista ongelmat joita koen näiden tapaamisten aiheuttavan.

Kehitystyötä valvovista toimenpiteistä, kuten tästä kehitysblogista ja oman ajanhallinnan ylläpitämisestä en pidä, vaan uskon että se pitäisi olla enemmänkin esimiehen vastuulla.

## Viikko 21 (Arvioinnit)

Vertaisarviointi
---

## Mika Marjomaa

**Yleinen panos projektityöhön (esim. asteikolla 0-5 + perustelu)?**

4
Mika oli aktiivisena osana projektia ja oli osana kaikissa projektiin vaadittavissa työtehtävissä.

**Roolin sopivuus?**

Mika onnistui hyvin hänelle annetuissa työtehtävissä ja uskon että hän sopii hyvin minkä tahansa kehitystiimin osaksi.

**Onnistuminen roolin mukaisissa työtehtävissä?**

Mika onniistui erinomaisesti hänelle annetuissa työtehtävissä.

**Oma näkemyksesi: jäsenen keskeisimmät vahvuudet ja kehittämiskohteet projektityössä?**
Vahvuudet:
* Itsenäinen
* Oma-aloitteinen
* Luotettava
* Aktiivinen

Kehittämiskohteet:
* Työpanoksen määrä
* Jotkut ideat jäivät ensimmäiselle ajatustasolle

**Omien työtehtävien hallinta (esim. asteikolla 0-5 + perustelu)**

4

Mika onnistui hyvin työtehtävissään, teki niitä aktiivisesti ja oma-aloitteisesti.

**Työpanos ja sitoutuminen projektiin esim. asteikolla 0-5 + perustelu)**

3

Työpanos ja sitoutuminen projektiin oli riittävää ja hän sai paljon aikaa projektin aikana.

**Viestintä (esim. asteikolla 0-5 + perustelu)**

5
Viestintä oli ammattimaista, aktiiviista ja asiallista.

## Teemu Lintunen

**Yleinen panos projektityöhön (esim. asteikolla 0-5 + perustelu)?**
3
Osallistui aktiivisesti ryhmän palavereihin ja kaikkiin projektin töihin. Kuitenkin vielä panostettavaa muussa osallistumisessa.

**Roolin sopivuus?**
Tuoteomistajan rooli sopi Teemulle todella hyvin.

**Onnistuminen roolin mukaisissa työtehtävissä?**
Teemu onnistui hyvin pitämään asiakkaan ja kehitystiimin keskustelun yhtenäisenä ja ammattimaisena. Kuitenkin ongelmia oli backlogin ylläpitämisessä, eri työtehtävien priorisoimisessa ja sprinttien suunnittelussa.

**Oma näkemyksesi: jäsenen keskeisimmät vahvuudet ja kehittämiskohteet projektityössä?**
Vahvuudet:
* Positiivinen, rauhallinen luonne
* Hyvä kommunikoija

Kehittämiskohteet:
* Itsenäinen työskentely
* Oma-aloitteisuus
* Tiedonhaku

**Omien työtehtävien hallinta (esim. asteikolla 0-5 + perustelu)**
3

**Työpanos ja sitoutuminen projektiin esim. asteikolla 0-5 + perustelu)**
3
Työpanos oli hieman vähäistä, suoritti tuoteomistajien hommia hyvin, mutta työpanos jäi kuitenkin hieman vähäiseksi.

**Viestintä (esim. asteikolla 0-5 + perustelu)**
5
Viestintä oli aktiivista, asiallista ja luontevaa.

## Tuomas Welling

**Yleinen panos projektityöhön (esim. asteikolla 0-5 + perustelu)?**
0
Tuli projektiin mukaan myöhään ja lopulta ei saanut juuri mitään konkreettista aikaan.

**Roolin sopivuus?**

Ei mahdollista arvioida aktiivisuuden ja työtehtävien tekemättömyyden takia.

**Onnistuminen roolin mukaisissa työtehtävissä?**

Ei onnistunut.

**Oma näkemyksesi: jäsenen keskeisimmät vahvuudet ja kehittämiskohteet projektityössä?**
Kehittämiskohteet:
* Aktiivisuus
* Oma-aloitteisuus
* Vastuunotto omasta työstä

**Omien työtehtävien hallinta (esim. asteikolla 0-5 + perustelu)**

Ei mahdollista arvioida aktiivisuuden ja työtehtävien tekemättömyyden takia.

**Työpanos ja sitoutuminen projektiin esim. asteikolla 0-5 + perustelu)**

0, ei sitoutunut projektiin ja työpanos oli minimaalista.

**Viestintä (esim. asteikolla 0-5 + perustelu)**

2, osallistui scrum palavereihin ja viestintä oli asiallista.

## Valeria Vasylchenko

**Yleinen panos projektityöhön (esim. asteikolla 0-5 + perustelu)?**

2
Oli aktiivinen osa ryhmän toimintaa, mutta vain pintapuolisesti. Olisin toivonut että kun scrum masterin työtaaka lievenee niin olisi osallistunut muihin työtehtäviin aktiivisemmin.

**Roolin sopivuus?**

Scrum Masterin rooli vaatii aktiivista ongelmien tunnistamistaitoa ja konfortaatiotataitoja. Valitettavasti Valeria ei osoittanut että hän omaa näitä taitoja tämän projektin puitteissa joko kokemattomuuden tai luonteensa vuoksi joten en usko että tämä rooli on hänelle sopiva.

**Onnistuminen roolin mukaisissa työtehtävissä?**

Scrum Masterina Valeria toimi alussa hyvin, mutta kurssin edetessä ongelmien tunnistaminen ja niiden korjaaminen ei jatkunut aktiivisesti. Tämän lisäksi yksi iso asia joka jäi mieleen oli että esimerkiksi dailyt venyivät joka viikko yleisiksi kokouksiksi ja 15 min rajan sijasta ne kestivät usein jopa 50 minuuttia.

**Oma näkemyksesi: jäsenen keskeisimmät vahvuudet ja kehittämiskohteet projektityössä?**
Vahvuudet:
* Positiivinen
* Sovittelija

Kehittämiskohteet:
* Oma-aloitteisuus
* Aktiivisuus
* Vastuu omasta työpanoksesta

**Omien työtehtävien hallinta (esim. asteikolla 0-5 + perustelu)**

2
Hoiti kurssin alkupuolella hommiaan hyvin, mutta työtehtävien tekemisen aktiivisuus laski huomattavasti kurssin edetessä.

**Työpanos ja sitoutuminen projektiin esim. asteikolla 0-5 + perustelu)**

2
Hoiti työtehtäviään omaan tahtiin, mutta jätti paljon toivomisen varaan työpanoksen ja projektiin sitoutumisesta.

**Viestintä (esim. asteikolla 0-5 + perustelu)**
5
Hyvää ja aktiivista viestintää koko kurssin ajan.

## Ville Niemi

**Yleinen panos projektityöhön (esim. asteikolla 0-5 + perustelu)?**
3

Oli aktiivisesti mukana kehityksessä tietokannan puolella, osallistui aktiivisesti palavereihin ja muihin ryhmän yhteisiin asioihin. Kuitenkin olisi ollut mahdollisuus panostaa projektiin enemmän.

**Roolin sopivuus?**

Sain kuvan että Villeä ei välttämättä yleinen ohjelmistokehitys kiinnosta, mutta hänellä on paljon hyviä piirteitä jotka sopivat kehittäjälle. Tulevaisuudessa jos hän päättää ruveta harjoittamaan kehitystaitoja, uskon että kehittäjän rooli sopii hänelle mainiosti.

**Onnistuminen roolin mukaisissa työtehtävissä?**

Paljon kehitettävää mutta onnistui suurimmassa osassa tehtävissän ohjauksen avulla.

**Oma näkemyksesi: jäsenen keskeisimmät vahvuudet ja kehittämiskohteet projektityössä?**
Vahvuudet:
* Neuvokkuus
* Nopea ymmärtämään kuinka tekniikka toimii
* Lähtee mielellää toteuttamaan haastavaakin työtehätävää
Kehittämiskohteet:
* Oma-aloitteisuus
* Tyytyy odottamaan muiden aktiivisuutta ongelmatilanteissa kuin ottaa asian itse aktiivisesti haltuun

**Omien työtehtävien hallinta (esim. asteikolla 0-5 + perustelu)**

3

**Työpanos ja sitoutuminen projektiin esim. asteikolla 0-5 + perustelu)**

3
Työpanoksessa ja sitoutumisessa olisi hieman petrattavaa.

**Viestintä (esim. asteikolla 0-5 + perustelu)**

5
Ammattimaista ja aktiivistä viestintää kaikissa kurssin projektiin liittyvissä asioissa.

## Teemu Tuomela

**Yleinen panos projektityöhön (esim. asteikolla 0-5 + perustelu)?**

**4**

Ei kokemusta kehitystyöstä NodeJS puolella, mutta suoritti samaan aikaan projektikurssin kanssa NodeJS Express REST-api kurssin, josta sai paljon osaamista. Hän osallistui myös aktiivisesti ryhmän palavereihin ja erilaisten artefaktien toteutukseen. Osasi pyytää aina apua ja palavereita kun oma osaaminen ei riittänyt.

**Roolin sopivuus?**
Vaikka kehittäjäkokemusta ei hirveästi löytynyt, Teemu suoriutui hyvin tehtävistään oman aktiivisuutensa ansiosta. Koodin tasossa on vielä kehittämisen varaa, mutta uskon että se tulee kokemuksen mukana tulevaisuudessa.

**Onnistuminen roolin mukaisissa työtehtävissä?**

Onnistui hyvin työtehtävissään.

**Oma näkemyksesi: jäsenen keskeisimmät vahvuudet ja kehittämiskohteet projektityössä?**

Vahvuudet:
* Aktiivinen, oma-aloitteinen
* Tunnistaa oman osaamisen ja osaa pyytää apua
* Erinomainen asenne

Kehittämiskohteet:
* Itsenäinen ongelmanratkonta

**Omien työtehtävien hallinta (esim. asteikolla 0-5 + perustelu)**
4

**Työpanos ja sitoutuminen projektiin esim. asteikolla 0-5 + perustelu)**
3
Työpanos ja sitoutuminen projektiin oli hyväksyttävää, mutta se olisi voinut olla mahdollisesti vielä parempaa.

**Viestintä (esim. asteikolla 0-5 + perustelu)**
5
Osallistui aktiivisesti ja hyvällä asenteella kaikkiin kurssiin liittyvien asioiden hoitamiseen ja viestintä oli ammattimaista.

## Jani Hyvönen

**Yleinen panos projektityöhön (esim. asteikolla 0-5 + perustelu)?**
0

Osallistui pakollisiin tapaamisiin, mutta en osaa oikein sanoa mitä teki niiden ulkopuolella. Ei ottanut vastuuta omasta työstään tai aktiivisuudestaan kurssin tehtävien teossa.

**Roolin sopivuus?**

Omien sanojensa mukaisesti hänellä oli kokemusta Reactista ja sen kanssa työskentelystä, mutta tämän osaamisen näkyminen ei näkynyt hänen työssään. Ainoa toiminnallisuus jonka hän teki jäi kesken ja tekosyynä oli endpointin puuttuminen, jota hän ei kuitenkaan aktiivisesti kysellyt tai aloittanut mitään muutakaan tehtävää oma-aloitteisesti.

**Onnistuminen roolin mukaisissa työtehtävissä?**

Ei onnistunut työtehtävissä.

**Oma näkemyksesi: jäsenen keskeisimmät vahvuudet ja kehittämiskohteet projektityössä?**

Hän ei tuonut esille vahvuuksia projektin kurssia suorittaessa. Kehittämiskohteita on aktiivisuus, ammattimaisuus, oma-aloiteesuus ja vastuunotto omasta työstä sekä projektista.

**Omien työtehtävien hallinta (esim. asteikolla 0-5 + perustelu)**
0
Ei saanut työtehtäviään tehtyä.

**Työpanos ja sitoutuminen projektiin esim. asteikolla 0-5 + perustelu)**
0
Työpanos oli minimaalista ja ei sitoutunut projektin tekemiseen. Uskomukseni mukaan koittaa päästä vain kurssin läpi hommia tekemättä.

**Viestintä (esim. asteikolla 0-5 + perustelu)**
0
Osallistui vain pakollisiin toimintoihin ja ei ollut aktiivinen osallistuja. Kun kysyin projektin front endin puolelta aktiivisuutta että saadaan yhdistettyä toiminallisuutta, sain vastaani häneltä vihamielistä palautetta että jos minulla ei itsellä ole kokemusta Reactista niin minun ei pitäisi puhua asiasta.

## Clockify koko kurssin osalta


### Yksityiskohtainen