Progetto Tecnologie WEB 2019/2020
Prima di fare qualsiasi modifica al codice coordinarsi con il resto del gruppo e creare e/o assegnarsi una Issue, al fine di limitare al minimo il lavoro in doppio.
Se vi vengono in mente più modifiche da fare scrivete pure più Issue ed incaricatevi solo quelle che riuscite a gestire in breve tempo, lasciando le altre al resto del gruppo così da lavorare in parallelo.
CODIFICA: impostare l'IDE o l'editor che utilizzate con la codifica Unicode (UTF-8 without signature) - Codepage 65001
al fine di evitare i warning di validazione segnalati nella issue #18 .
E' buona norma seguire le indicazioni delle prime lezioni di TOS: a nostra scelta se adottare gitflow o feature-flow come workflow di lavoro. Gitflow è un tantino più "costruito" però sarebbe ottimo, in ogni caso per questo progetto dovrebbbe bastare anche il feature-flow.
Idealmente ogni Issue va sviluppata su un suo branch dedicato. Ogni branch può avere (e normalmente ha) più commit al suo interno. Effettuare il merge del branch sul ramo principale solo dopo aver controllato di non aver introdotto bug che possano minare il lavoro degli altri.
Una volta effettuato il merge del branch sul trunk principale eliminare il branch temporaneo su cui si era lavorato.
NOTA BENE: ogni volta che si vuole fare un merge, bisogna accertarsi che il codice sia valido XHTML. Per validare il codice: https://validator.w3.org/.
Cercare di tenerli il più possibile "atomici" e collegarli sempre al codice della Issue. Atomici significa che ogni commit dovrebbe registrare solo un tipo di modifica, non una lista. Ag ogni Issue possono corrispondere più commit e viceversa.
Questa è secondo me una buona linea guida su come scrivere messaggi di commit efficaci.
Coordinarci dovrebbe rendere il lavoro più semplice e veloce per tutti, aiutando anche a dividere in modo equo il carico di lavoro. Implementare le linee guida alla lettera sarà complicato però provarci dovrebbe aiutare sia in TOS che SWE. In caso di casini si può comunque sistemare il codice visto che è versionato e decentralizzato. Aggiungere in questo file ogni altra indicazione che può essere utile come regola di gruppo.
deve essere accompagnato da una relazione
che ne illustri le fasi di progettazione, realizzazione e test ed evidenzi il ruolo svolto dai singoli componenti del gruppo.
Viene richiesta un'analisi iniziale delle caratteristiche degli utenti che il sito si propone di raggiungere. Le pagine web devono essere accessibili indipendentemente dal browser e dalle dimensioni dello schermo del dispositivo degli utenti. Considerazioni riguardanti diversi dispositivi (laddove possibile) verranno valutate positivamente.
Il non rispetto di anche una sola di queste specifiche comporta la non sufficienza
del progetto.Il non rispetto di anche una sola di queste regole può comportare l'esclusione dalla consegna o una penalizzazione nella valutazione
:
in prima pagina
:
tecweb.studenti.math.unipd.it
, sulla home page di uno dei componenti del gruppo (questa login verrà bloccata per il tempo necessario alla correzione, in genere una settimana).
-Tramite un form di consegna che verrà attivato ad ogni sessione d’esame all’interno della piattaforma moodle alla pagina del corso
Le istruzioni per l'accesso alla macchina tecweb.studenti.math.unipd.it si trovano su questa pagina, gestita dal servizio di calcolo.Oltre alla consegna del progetto sull’account designato nel server tecweb, è necessario consegnare una copia del progetto attraverso la pagina del corso presente sul moodle. Ad ogni sessione di consegna, verrà attivata una form tramite la quale il responsabile del gruppo deve caricare un file zip contenente tutto il codice sorgente del progetto (ovvero, i file presenti sull’account del server tecweb) e la relazione. Il file deve essere caricato entro la scadenza fissata per la consegna del progetto, pena l’esclusione dalla correzione (il progetto dovrà quindi essere riconsegnato la sessione successiva).