<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2015-08-28 16:52 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 class="gmail_extra">Nicola hai frainteso quello che volevo dire. </div><div class="gmail_extra">Il mio discorso era basato sul fatto che c'e' chi lavora su grandi sistemi, e cerca, giustamente, di avvantaggiarsi di ogni tecnologia nuova che possa essere di aiuto.</div></blockquote><div><br></div><div>Io direi proprio il contrario. Chi lavora su grossi sistemi non vuole tirare a mano 666 nuove tecnologie per ogni progetto.</div><div><br></div><div>Per dire, su ${Java} ho grosso modo presente come si comporta e soprattutto come falliscono i vari pezzi. So cosa va lento, so cosa va veloce. So gia' cosa non fare. So quali metriche andare a vedere se il servizio non si comporta come deve.</div><div><br></div><div>Allo stesso modo quando uso ${Redis} so cosa devo fare, cosa non devo fare. So come concepire le risorse. </div><div><br></div><div>Quando prendo un nuovo pezzo di tecnologia e lo butto nella selva, probabilmente sapro' prima di avere finito, esattamente come *funziona* il sistema. Pero' non sapro' come fallisce. Che e' qualcosa che mi preme ancora di piu', visto che il sistema, ad un certo punto, fallira'. E vorrei che le sue modalita' di fallimento mi siano note: perche' vuole dire che posso avere allarmi e metriche sensate che consentano a chiunque sia reperibile di mitigare la questione e di tirare fino a domani.</div><div><br></div><div>Quando ho un sistema nuovo, questa informazione *mi manca*. Manca a tutti quelli per cui il sistema e' nuovo. A volte e' un rischio necessario o addirittura inevitabile.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra">Viceversa chi lavora su progetti in scala piu' piccola puo' trovarsi a usare senza troppo sforzo strumenti anche meno aggiornati ma meglio conosciuti.</div></blockquote><div><br></div><div>E tipicamente ha meno "scuse", perche' i fallimenti sono meno spettacolari e meno frequenti. Se non vuole imparare lo "strumento giusto", e' perche' non ha voglia di imparare o ha fretta (ma fretta ce l'abbiamo un po' tutti, grandi e piccini -- ancora una volta... c'e' caso che una piccola startup abbia ben piu' fretta di una grossa corporation, e c'e' anche caso che una piccola startup debba scalare piu' rapidamente di una grossa corporation).</div><div> </div><div>Poi certo, ci sono una serie di aziende che non devono scalare (perche' non crescono). Non so... </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra">In pratica se io adesso devo mettermi a studiare Go e tutti i suoi sistemi, devo fermarmi per un tempo X (non saprei neppure quantificarlo) prima di poter svilupapre un progetto complesso.</div></blockquote><div><br></div><div>Tu come io. Infatti normalmente non si svolgono cose tipo:</div><div><br></div><div>riko: hey manager, ieri ho letto su stackoverflow che hanno buttato fuori ${cippadicazzo}, adesso riscrivo tutta la nostra infrastruttura in ${cippadicazzo}</div><div>manager: ma certo, ottima idea! pero' ti suggerisco di non fermarti ad imparare ${cippadicazzo}, tanto non sara' troppo diverso da ${ceppadiminchia} che usiamo gia'</div><div>riko: ovviamente! tanto non e' che dobbiamo poi mantenere il troiaio che avro' scritto in ${cippadicazzo}, visto che fra 3 giorni arrivera' Cpt. Bandana a riscrivere tutto in ${troncodinerchia} che dovrebbe uscire dallo stato di alfa primordiale appunto fra un paio di giorni. Anzi, ho sentito che oggi sono per la prima volta riusciti a buildare tutto anche su qualcosa di diverso dalla specifica versione di Archlinux che stavano usando per lo sviluppo.</div><div>manager: fico! quindi abbiamo materiale per lo sprint planning! tu parti oggi a riscrivere tutto, fra tre giorni parte Cpt. Bandana appena torna dalle vacanze. </div><div>riko: looks like a plan.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra">Se invece inizio a usarlo per delle parti dove mi posso avvantaggiare dei suoi indubbi meriti, mentre continuo a usare srumenti noti e con cui sono produttivo, nel giro di un tot (dove tot > x) potro' padroneggiarlo.</div></blockquote></div><br>Certo. E nessuno lo nega. La parte del mio messaggio che probabilmente non e' passata e' che Go fa bene una serie di cose. Tu volevi mettere in piedi un sistema che usa Python dove Python funziona male e usa Go su una configurazione assolutamente non testata dove porta benefici marginali. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Ti garantisco che ci metti meno a capire come tirare su un webserver in Go che a capire come interfacciare Go con Python. <br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>