*Allaolevien tehtävien deadline on *

Apua tehtävien tekoon kurssin Discord-kanavalla, kampuksella ja Zoomissa:

• Maanantaisin (poislukien 6.12.) klo 14-16 kampuksella BK107-luokassa
• Torstaisin (4.11. alkaen) klo 14-16 Zoomissa

Ohjauskalenteri:

Muista myös tämän viikon monivalintatehtävät, joiden deadline on .

Typoja tai epäselvyyksiä tehtävissä?

Tee korjausehdotus editoimalla tätä tiedostoa GitHubissa.

Tehtävien palauttaminen

Tehtävät palautetaan GitHubiin, sekä merkitsemällä tehdyt tehtävät palautussovellukseen https://study.cs.helsinki.fi/stats/courses/ohtu-avoin-2022

Katso tarkempi ohje palautusrepositorioita koskien täältä.

1. git: stash (versionhallinta)

tehtävien 1 ja 2 ei tarvitse näkyä palautuksessa, riittää kun teet tehtävät

Lue https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning kohtaan Creative stashing asti.

Oletetaan että olet repositoriossa, jossa on ainakin kaksi branchia: master ja joku toinen (kutsutaan sitä tässä nimellä toinen).

• ollessasi master-branchissa tee branchissa oleviin tiedostoihin muutoksia, joita lisäät staging-alueelle ja joitain muutoksia joita et vielä “äddää”, komennon git status tuloksen tulee näyttää siis suunilleen seuraavalta

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   README.md
    modified:   src/main/java/Main.java

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   src/main/java/Olutvarasto.java

• pomosi käskee sinua välittömästi tekemään pari muutosta branchiin toinen. Et kuitenkaan halua vielä comittoida masterissa olevia muutoksia
• jos siirryt branchiin toinen tekemättä comittia, tulee hirveä sotku, sillä muutokset pysyvät muutoksina toisessakin branchissa
• git stash pelastaa tästä tilanteesta, eli stashaa masterissa olevat muutoset
  • kokeile ennen ja jälkeen stash-komennon komentoa git status
• siirry branchiin toinen, tee sinne joku muutos jonka committaat
• palaa jälleen masteriin
• palauta stashatyt muutokset komennolla git stash apply
  • varmista että muutokset palasivat
  • kuten huomaat, staging-alueelle jo lisätty muutos ei palaa staging-alueelle, vaan joudut lisäämään sen uudelleen
  • jos edellisessä komento olisi annettu muodossa git stash apply --index, olisi tilanne palautunut täysin ennalleen

2. git: branchin “siirtäminen” (versionhallinta)

tehtävien 1 ja 2 ei tarvitse näkyä palautuksessa, riittää kun teet tehtävät

• tee repoosi branchi nimeltä haara ja tee masteriin ja haaraan committeja siten että saat aikaan seuraavankaltaisen tilanteen:

    ____master
__/
  \_____haara

• eli sekä master että haara ovat edenneet muutamien commitien verran haarautumisen tapahduttua
  • huom: komennolla gitk --all näet kaikki haarat, kokeile!
• yhtäkkiä huomaat, että master:iin tekemäsi asiat eivät olekaan kovin hyviä ja haara:ssa on paljon parempaa tavaraa, haluaisitkin että haara:sta tulisi uusi master
• tämä onnistuu kun menet masteriin ja annat komennon git reset --hard haara
  • varmista että komento toimii oikein
  • vanhan master-haarankaan tavarat eivät katoa mihinkään, jos niihin jostain syystä vielä halutaan palata
  • vanhaan committiin palaaminen onnistuu, jos commitin id on tiedossa – jos ei, on olemassa muutamia keinoja sen selvittämiseksi

3. ja 4. (kahden rastin tehtävä) KPS yksin- ja kaksinpeli

Kurssirepositorion hakemistosta koodi/viikko7/KiviPaperiSakset löytyy tutun pelin tietokoneversio.

• ohjelmassa on kolme pelimoodia: ihminen vs. ihminen, ihminen vs. yksinkertainen tekoäly ja ihminen vs. monimutkainen tekoäly
• koodi sisältää runsaat määrät copy pastea, muutenkaan oliosuunnittelun periaatteet eivät ole vielä alkuperäisellä ohjelmoijalla olleet hallussa
• poista koodista kaikki toisteisuus ja tee siitä rakenteellisesti materiaalin osan 4 hengessä oikeaoppinen
  • pelaa-metodi tulee toteuttaa template-metodina
  • sopivan peliolion (kaksinpeli, helppo yksinpeli, vaikea yksinpeli) luominen tulee toteuttaa staattisen tehdasmetodin avulla
  • pääohjelmalla ei saa olla riippuvuuksia konkreettisiin pelin toteuttaviin luokkiin

Jos teet tehtävän mielestäsi kaikkien tyylisääntöjen mukaan, merkkaa 2 rastia, jos ratkaisu ei ole kaikin osin tyylikäs, merkkaa yksi rasti.

Muista että voit suorittaa ohjelman ilman gradlen ikäviä välitulosteita antamalla komennolle gradle run seuraavat lisäoptiot:

gradle -q --console=plain run

Vihje: eräs tapa lähteä liikkeelle on muodostaa yliluokka KiviPaperiSakset, joka sisältää kaikille kolmelle pelityypille yhteisen koodin:

public abstract class KiviPaperiSakset {
    private static final Scanner scanner = new Scanner(System.in);

    // tämä on ns template metodi
    public void pelaa() {
        Tuomari tuomari = new Tuomari();
        // ...

        String ekanSiirto = ensimmaisenSiirto();
        System.out.print("Toisen pelaajan siirto: ");
        String tokanSiirto = toisenSiirto();

        while (onkoOkSiirto(ekanSiirto) && onkoOkSiirto(tokanSiirto)) {
           // ...
        }

        System.out.println();
        System.out.println("Kiitos!");
        System.out.println(tuomari);
    }

    protected String ensimmaisenSiirto() {
        System.out.print("Ensimmäisen pelaajan siirto: ");
        return scanner.nextLine();
    }

    // tämä on abstrakti metodi sillä sen toteutus vaihtelee eri pelityypeissä
    abstract protected String toisenSiirto();

    protected static boolean onkoOkSiirto(String siirto) {
        return "k".equals(siirto) || "p".equals(siirto) || "s".equals(siirto);
    }
}

Erilliset pelit sitten perivät abstraktin luokan ja erikoistavat sitä tarpidensa mukaan:

public class KPSPelaajaVsPelaaja extends KiviPaperiSakset {

    // funktio pelaa peritääm

    @Override
    protected String toisenSiirto() {
        System.out.print("Toisen pelaajan siirto: ");
        return scanner.nextLine();
    }

    // ...
}

5. Pull requestin mergeäminen (tätä tehtävää ei lasketa versionhallintatehtäväksi)

Mergeä jokin miniprojektillesi tehty pull request (myös toisen miniprojektisi jäsenen tekemän pull requestin mergeäminen käy). Voit tehdä tehtävän yhdessä muiden miniprojektisi ryhmäläisten kanssa. Jos olet jo mergennyt pull requestin miniprojektiisi kurssin aikana, se riittää tämän tehtävä merkkaamiseksi.

Laita palautusrepositorioosi tiedosto MERGE.md ja sen sisällöksi linkki mergettyyn pullrequestiin.

Vaihtoehtoinen tehtävä

lue joku alla olevista ja tee siitä noin 0.25 sivun referaatti

• Lauri Suomalaisen kandidaattityö Ohjelmistotuotantomenetelmien kehittyminen 1950-luvulta nykypäivään
• Tero Huomon kandidaattityö Ohjelmistoarkkitehtuurin sisällyttäminen ketteriin ohjelmistotuotantomenetelmiin
• Kasper Hirvikosken kandidaattityö Metriikat käytänteiden tukena ohjelmiston laadun arvioimisessa
• Kenny Heinosen kandidaattityö Ohjelmistoala ja ryhmätyöskentely
• Eero Laineen kandidaattityö Johtaminen perinteisissä ja ketterissä ohjelmistotuotantoprojekteissa
• Esa Kortelaisen kandidaattityö Jatkuva eksperimentointi ohjelmistokehityksen tukena
• Kalle Ilveksen kandidaattityö Scrumban-menetelmän käyttö ketterässä ohjelmistokehityksessä

6. Kurssipalaute

Anna kurssipalautetta täällä. Voit antaa palautteen myös kokeen jälkeen. Rasti tähän tehtävään on lupaus että annat palautteen jossain vaiheessa. Palautetta voi antaa välillä 25.3.2022 - 15.5.2022

Tehtävien palautus

Pushaa kaikki tekemäsi tehtävät (paitsi ne, joissa mainitaan, että tehtävää ei palauteta mihinkään) GitHubiin ja merkkaa tekemäsi tehtävät palautussovellukseen https://study.cs.helsinki.fi/stats/courses/ohtu-avoin-2022