<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2014-12-30 0:01 GMT+01:00 Carlos Catucci <span dir="ltr"><<a href="mailto:carlos.catucci@gmail.com" target="_blank">carlos.catucci@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><span class=""><br>5. HTML/Templating, verosimilmente con CSS e quel minimo di Javascript che tende a saltare fuori ovunque<br><br></span></div><div>No, perdonami, ma io separo frontend e backend. La parte "browser" la fa una figura diversa e per essere formata richiede altri tempi (javascript senza contare poi css e compagnia, e' motlo piu' complesso.). Io parlavo di Python e Django.<br></div></div></div></div></div></blockquote><div><br></div><div>Continuo a vedere un problema di fondo... oh, de gustibus. Ma questa e' una figura proprio *non* autonoma. Cioe' tu dici si, che non e' autonoma. Ma questa e' una figura che gli dici fai una funzione che divide per due ogni elemento di un array e fine della fiera. Cioe' se non sai con chi parli sopra e sotto... boh, non mi e' nemmeno chiaro se sia utile o se il tempo che si perde a dire cosa deve fare per filo e per segno sia piu' di quello che ci va per farsele da soli. Ma qui divaghiamo.</div><div><br></div><div>Dopo di che, sei tu ad avere tirato in ballo django. A me sembra che parlare di Django ed escludere meta' delle cose che fa django sia un po' controintuitivo.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>5b. Forms e compagnia<br><br></div><div>Anche qui non e' strettamente necessario. Io le forms non le ho mai usate in progetti fino ad ora. Sono belle, sono comode, ma non indispensabili.<br></div></div></div></div></div></blockquote><div><br></div><div>Hei, ci sono le django form e le form HTML. Cioe' il fatto che il poverino non possa scrivere un coso che prende un qualche tipo di input dall'utente per fare una modifica sul db e' parecchio limitante....</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span class=""><div>6. Come si gestiscono e come non si gestiscono gli errori, quando usare None, quando tirare un'eccezione, quando fare altro. Come gestire le eccezioni, quando rilanciarle, quando gestirle, quando fare cosa<br><br></div></span><div>Le eccezioni si, fanno parte del linguaggio<br></div></div></div></div></div></blockquote><div><br></div><div>Non e' solo le eccezioni come concetto astratto. Ma *come* e *quando* usarle (e quando non usarle), come e quando gestirle e quando non farlo. Io vedo che la gente prima di progettare la gestione dell'errore in modo robusto ci mette *parecchio* tempo e a volte cazza anche la gente esperta (cazza di rado, certo). Il che mi fa pensare che la gente *poco* esperta... cazzi molto di piu'.</div><div><br></div><div>Ma tu parli di codice robusto e mantenibile. Il che vuole dire che stai sostenendo che in 10 giorni, insieme a tutto il resto, spieghi una cosa difficile di suo, che richiede sapere esattamente cosa e quando possa andare male, per fattori spesso esterni dipendenti dal sistema operativo, da altri sistemi, dalla rete, dal carico, da chenneso'... io qui dubito molto.</div><div><br></div><div>Oh, ma tu sostieni anche di spiegare la OOP, in due giorni o giu' di li (visto tutto il resto che devi spiegare nei 10 giorni).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div><span class=""><div>7. Testing (che non vorremo mica sviluppare senza test, spero)<br><br></div></span><div>Si i test li prepara e esegue una persona diversa, Con il tempo e l'esperienza imparera'. Ma per scrivere dei buoni test devi prima conoscere bene il linguaggio ed il framework<br></div></div></div></div></div></blockquote><div><br></div><div>Ah, ok. Allora *non* stiamo parlando di codice robusto e mantenibile. Era quello che sostenevo da subito.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div><span class=""><div>9. Quel poco di SQL (o meglio, di db relazionali) che ti serve per capire come accidenti Django salva e legge dati, fra le altre varie cose per non inchiodare tutto appena la gente comincia ad usare il servizio<br><br></div></span><div>Per questa fase gli basta di sare eseguire le query con gli statement dell'ORM. Le raw query servono solo in casi particolari che esulano, per la fase iniziale.<br></div></div></div></div></div></blockquote><div><br></div><div>Nessuno ha parlato di raw query. Ma non mi e' chiaro come puoi scrivere codice robusto usando un'astrazione senza sapere quello che astrai e quello che generi. Mi sembra il classico caso in cui uno si trova con qualcosa che funziona male ma non ha idea del perche'. Ma anche cose facili tipo quando e dove mettere gli indici, i vincoli vari, le fkeys... tutto dall'orm, eh. Ma roba che va fatta... ma che per essere fatta ha bisogno di sapere i concetti sottostanti (da cui parlavo di sapere come funzionano i db relazionali).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>11. Come funzionano le fixtures e come si scrivono i test che interagiscono con il db<br></div><div><span class=""><br></span>No perche' qui pure siamo nel "e' compito di altra persona", in questa fase-</div></div></div></div></div></blockquote><div><br></div><div>Boh... non mi e' chiaro come pensi che uno scriva codice robusto senza fare i test, vomitando fuori codice che poi qualcun altro dovra' testare. Il che genera un monte di ritardi, espone a problemi di comunicazione fra le due persone, riduce la validita' e l'utilita' dei test stessi.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="">12. cosa loggare e cosa non loggare, quando, come leggere e capire un log</span></div></div></div><br></div><div class="gmail_extra">Beh fa parte della programmazione, senza log non fai debug</div></div></blockquote><div><br></div><div>In realta' dissentireri... i log hanno soprattutto un'altra funzione, ma tant'e'.</div><div>Cioe' il debug fatto a print mi fa cosi' tanto ... vabbe'. </div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>