Presentazione

[mikedepetris]

Google Slides vecchio progetto: https://docs.google.com/presentation/d/1q83NLGfJcev7uOpZvD9PzoA-GifXhy-1fgU_pTwdRJ8/edit?usp=sharing nuovo: https://docs.google.com/presentation/d/1kHyKYBpzUTJgBSQuHRTkj8Rv4EyRiEjVH6XfeHFQSPA/edit?usp=sharing

Requisiti: 6. Present your project.#87

• Show a live demo (working software is the primary measure of progress).
• Describe what steps you took, how you worked together, what tests you used (the commit history could help in doing this).
• Show us the code, highlight design choices you made and why you made them.
• We will ask questions about the code, your design choices, and the development approach you used.

Elementi da aggiungere alla presentazione:

• uso di un github project con la board per lo issue tracking
• descrizione del ciclo: creazione di issue nella board, assignazione, spostamento in stato "work in progress", pull/update, nuovo branch, change code, commit (commento), push, pull request, richiesta di review, review e merge su master, aggiornamento della issue con eventuale chiusura in stato completato
• TDD
• agile: implementazione iniziale molto semplice con successivo sviluppo incrementale di funzionalità incremental feature in release successive
• meetings settimanali, gruppo WA
• aggiunti setter e getter (in automatico) nella classe GUI perché servono per i test, un punto centrale potrebbe essere discutere come abbiamo aggiunto la GUI dopo la CLI ed il refactoring necessario e come adattare i test e farli girare anche headless su circleCI

Use PR associated with github issues for tracking #7

Try to use the cycle: assign an issue, put into work in progress status, pull, branch, change code, commit (comment), push, pull request, merge to master and update the issue eventually closing it.

Tutto il pensiero di git si basa sui branch. Se io devo lavorare su una nuova issue o feature stacco un branch da main, e comincio a lavorarci. Pusho il mio branch, così posso lavorarci i giorni successivi senza perdere nulla, altri possono riprendere il lavoro, e nel frattempo non sporco il branch originale. Posso addirittura riscrivere la history senza rischio di rompere le scatole a nessuno, squashando i commit Quando secondo me il lavoro è completo allora apro la PR. Scrivo la mia descrizione, la gente vede cosa è cambiato, commenta, modifico, e poi una volta che ho l'OK mergio Se qualcosa si rompe ho la possibilità anche di revertare la PR, togliendo da main il codice che ho aggiunto, e lasciare main pulito.

[mikedepetris]

Email screenshot by circleCI with failed build notification #70

[mikedepetris]

Screenshot della Project Board al 20/01/23

[mikedepetris]

Insights grafico con il numero di issue per ciascuno stato

[mikedepetris]

[mikedepetris]

[mikedepetris]

Esempi circleCI mentre esegue la build ed i test che poi falliscono miseramente

[martat97]

Lascio uno screenshot per la static code analysis fatta su intelliJ

[martat97]

Comunque, avevate già in mente uno strumento da usare per creare la presentazione? Ne ho usati di diversi, sicuramente con Overleaf mi sono trovata molto in difficoltà ad allineare immagini, andava bene per scrivere le formule, però invece con altri strumenti come Google presentation o Canva abbiamo avuto meno problemi

[mikedepetris]

Google slides

[mikedepetris]

[mikedepetris]

Pareggio GUI

[mikedepetris]

Code inspection, analisi statica in Intellij IDEA

[biagiolicari]

Static Code Analysis

[biagiolicari]

SonarLint CodeSmell

[mikedepetris]

https://github.com/mikedepetris/Gomoku-SDM/network

[mikedepetris]

http://gomokuworld.com/gomoku/1 spiegazioni regole e strategie con esempi di situazioni di gioco

[mikedepetris]

TDD: esempio, voglio cambiare la formattazione della stampa della board, preparo il test che fallisce uso del TODO per identificare facilmente il punto del codice da modificare: // numero di riga a sinistra TODO: 19-->1 ma poi cambiano gli inserimenti coordinate stringBuilder.append(String.format("%1s", row)).append("\t");