Ricordate: riportare la vostra esperienza ed il vostro materiale aiuta chiunque, SEMPRE.
Non fare il perocchio e spendila mezz'ora per contribuire alla causa.
Scusate ragazzi, ma su questo corso sto per essere cattivo e politicamente molto scorretto. È stato più forte di me.Non fare il perocchio e spendila mezz'ora per contribuire alla causa.
Spero solo che, se proprio uno dei prof capiti a leggere questo post, non la prenda tanto male e spero davvero che approfitti di questa spruzzatina di sincerità per analizzare un feedback senza veli e, magari, migliorarsi.
Info sul corso
Questo corso affronta argomenti affascinanti che ampliano enormemente le conoscenze sui calcolatori e sui meccanismi che li governano e prevede l'apprendimento di logiche di programmazione mai affrontate nei corsi precedenti.
Purtroppo il corso si regge su una didattica davvero scadente da troppi punti di vista, sebbene i professori/assistenti/folletti/gremlins/unicorni/capocantieri/avvocati/T-Rex/wrestlers/locandieri siano evidentemente preparati in materia ma utilizzino un approccio che ho trovato tutt'altro che "student-friendly".
Il prof. Cotroneo, quel 50% e meno di volte che si presenta in aula, sembra padrone della materia e riesce a destreggiarsi tra gli argomenti, ma sembra poco incline a rispondere alle domande e spesso e volentieri comincia a far divergere la spiegazione verso argomenti o nozioni non fondamentali o, a volte, non attinenti al corso.
L'altro, il braccio destro del prof (considerando anche il fatto che sia l'unico a mettere mano al codice), noto nelle contrade anche come "quello con gli occhiali", è molto meno capace nella didattica e più che spiegare si limita a raccontare in maniera alquanto confusionaria, a volte titubante e sempre poco accattivante gli argomenti del corso, dei quali si perde facilmente il filo non avendo una chiara visione dell'iter concettuale delle lezioni mal collegate.
Una menzione speciale va fatta alle famosissime "ESERCITAZIONI", e qui si riprende a maggior ragione il discorso dello "student-friendly":
Ho capito che vuoi farci utilizzare Linux, ma introducilo come si deve.
Mostraci una chiarissima e pulita procedura di creazione dei file essenziali per un programma, illustracela e commentala passo passo, semplifica la parte sulla shell e lascia perdere quel cazzo di Vim che nessuno si vuole inculare.
Utilizza Gedit che è così semplice e meraviglioso (...E orientato allo sviluppo ...E lo possiamo utilizzare senza problemi all'esame) e lasciaci vedere con calma i comandi che impartisci alla shell mentre svolgi dalle più banali prima alle più complesse poi procedure, magari tenendo una metà della schermata su Gedit e l'altra metà sulla shell.
Ma no! Digita con velocità supersonica i tuoi comandi, cambia tra shell e Vim con destrezza e stupisciti delle nostre espressioni stralunate mentre a stento abbiamo cominciato a masticare l'interfaccia di Ubuntu (che non utilizziamo in sede d'esame) e ancora incespichiamo nel sintetizzare un makefile con un programma main ed un header.
Fallo, per uno dei corsi più importanti di questo ramo ingegneristico.
Ah, e per la famosa "esercitazione" che dovrebbe aiutarci visto che contiene un po' di tutto quello che verrebbe chiesto allo scritto:
grazie per averci fucilato in faccia un programma chilometrico dalle complesse meccaniche da analizzare molto lentamente ed accortamente con la traccia in mano senza considerare che tali argomenti andrebbero affrontati uno per volta.
Mostraci una chiarissima e pulita procedura di creazione dei file essenziali per un programma, illustracela e commentala passo passo, semplifica la parte sulla shell e lascia perdere quel cazzo di Vim che nessuno si vuole inculare.
Utilizza Gedit che è così semplice e meraviglioso (...E orientato allo sviluppo ...E lo possiamo utilizzare senza problemi all'esame) e lasciaci vedere con calma i comandi che impartisci alla shell mentre svolgi dalle più banali prima alle più complesse poi procedure, magari tenendo una metà della schermata su Gedit e l'altra metà sulla shell.
Ma no! Digita con velocità supersonica i tuoi comandi, cambia tra shell e Vim con destrezza e stupisciti delle nostre espressioni stralunate mentre a stento abbiamo cominciato a masticare l'interfaccia di Ubuntu (che non utilizziamo in sede d'esame) e ancora incespichiamo nel sintetizzare un makefile con un programma main ed un header.
Fallo, per uno dei corsi più importanti di questo ramo ingegneristico.
Ah, e per la famosa "esercitazione" che dovrebbe aiutarci visto che contiene un po' di tutto quello che verrebbe chiesto allo scritto:
grazie per averci fucilato in faccia un programma chilometrico dalle complesse meccaniche da analizzare molto lentamente ed accortamente con la traccia in mano senza considerare che tali argomenti andrebbero affrontati uno per volta.
Scusate raga, mi sento davvero stronzo in questo momento ma è più forte di me e devo sfogarmi. È ridicolo che questo corso sia organizzato da cani, contando anche l'alternanza con altri assistenti (per un totale di 5 diverse personalità, almeno durante l'anno in cui ho seguito) che rendono la già compromessa fluidità tematica un vero inferno.
L'esame scritto
Codice utile allo scritto fatto in aula: 2%
Codice utile appreso dalle soluzioni online + prove di altri studenti: 298% (con complicatissime tecniche di reverse engineering che la NASA può solo bramare nelle notti di insoddisfatta passione).
Lo scritto, che è parte essenziale di questo esame senza il quale non si può passare all'orale, è tutto da scoprire. È una magica avventura tra documenti mal commentati dai prof (o, spesso, per nulla commentati) e strutturati in maniera estremamente più complessa e confusionaria di quanto il problema stesso richiedesse.
Non riesco neanche lontanamente a giustificare una tale inadeguatezza didattica.
Lo scritto, inoltre, è valutato molto pignolamente: la prima volta mi è stata chiesta una struttura a multieseguibile con due client, un server ed una interfaccia tra client e server che intermediasse i messaggi. Tra interfaccia e server la send doveva essere sincrona, ma molti furono colti alla sprovvista (tra cui io) e provarono quel che poterono ma fallirono. Risultato: tabula rasa (se non per quattro gatti), nonostante molti di noi avessero fatto impeccabilmente il resto del programma, quella sola richiesta della send sincrona è stato il pretesto per bocciare su due piedi, nonostante il programma prevedesse l'utilizzo e le richieste di molti più requisiti. I prof hanno aggiunto un'altra data sotto le sentite richieste di chi, come me, si è sentito alquanto preso in giro per la bocciatura ad alto threshold.
La seconda volta mi è stata chiesta una struttura produttore-consumatore con vettore di stato e pthread con cui non ho avuto nessun problema.
L'esame orale
L'orale non mi è sembrato particolarmente "deviato". Sembrava abbastanza equilibrato nella sua difficoltà. Le domande, mie e quelle che ho ascoltato degli altri, coprivano tutta la parte teorica del corso.
I professori, in particolare Cotroneo, ci tengono molto (come è ovvio che sia) alla perfetta conoscenza dei concetti fondamentali del corso (cos'è un processo, differenze con i threads...), senza i quali si rischia facilmente la bocciatura immediata. L'unico problema, in questo caso, è che potrebbe non andargli bene la spiegazione fornita, anche se, magari, per lo studente poteva essere una spiegazione più che ragionevole.
Una cosa è certa: all'orale bisogna andare preparati, non prendetelo alla leggera.
Materiale mio
Ho scritto un documento simpatico che mi ha aiutato molto durante l'esercitazione per tenere sott'occhio tutte le funzioni per i problemi fondamentali di ogni programma. Ricordate sempre, però, di fare pratica con il comando MAN della shell.
