Ricordo dei blog di personaggi curiosi, ex-colleghi, che scrivevano due righe anche solo per dire di aver trovato la mirabolante patch per la vulnerabilità xyz di microsoft sql server
o che il tal servizio quando si impianta si può riavviare solo andando nel registry di windows, magari compiendo due giravolte, alluci incrociati e una danza della pioggia
personaggi, per capire, che sul proprio pc personale hanno solo gli utenti admin e sysadmin (leggi: stare male)
e io che non avevo mai dato peso a queste cose, riguardando la densità di novità, competenze e ragionamenti sull’esperienza di questi ultimi mesi, i primi nel nuovo posto di lavoro, ho riflettuto sulla commistione tra interesse puramente tecnico e valore alto del quadro finale, e mi son detto, ci scrivo sopra
scrivo per esempio che l’utilizzo di Zend Framework non è la panacea e non è una scelta a costo zero, in termini umani e tecnologici, ma ripaga in termini di robustezza e di completezza di un impianto, magari non documentato al 100%, è dotato di ciò che serve per scrivere un’applicazione web solida
ho visto, sia ora che in passato, colleghi ed ex-colleghi formatisi in ambienti ms-visual studio, che hanno faticato a capire come fare un’applicazione web, senza un intermediario che nascondesse, con l’apparente comodità di un ambiente integrato, i veri meccanismi che fanno funzionare l’applicazione, il protocollo, la sessione (che dal punto di vista reale non esiste, ma è un ponte costruito con due arcate facilmente scostabili), l’interazione con database e file system, etc.
viene un parallelo con sistemisti di provenienza ms e unix, i secondi abituati a risolvere problemi e trovare soluzioni partendo dalla conoscenza, i primi da nozioni (chiamate poi skills e condensate in buffe formule da biglietto da visita)
questa differenza di approccio è evidente, è molto di più di un semplice pregiudizio,
è una cartina al tornasole di come questi background diversi formino in modo indelebile il modo di porsi nei confronti di un problema
laddove sei abituato prima a studiare, a conoscere (anche intimamente), ad avere un metodo, la soluzione arriva come frutto di ragionamento prima e sperimentazione poi
dall’altra, ho riscontrato la superficialità del “datemi quell’oggetto che fa quella cosa“, ovvero il non-metodo, la scorciatoia che ti permette di non ragionare troppo su quello che stai facendo ma di produrre, quasi sempre di grandi copia&incolla, un pezzo di software in cui il tuo valore aggiunto non c’è, e la prossima volta sarà lo stesso vacuo processo di sterile trasferimento di byte in cui il cervello di scrive non si è impegnato poi tanto
le librerie, i framework, gli ambienti integrati, tutto ciò che rende il lavoro più rapido e produttivo, non sono il male, anzi
la vera differenza è l’approccio di chi li usa: ti interessa sapere quello che stai facendo, apprendere qualcosa, essere portatore sano di ragionamenti e competenze?
detto questo, il vero turning point dell’esperienza fatta finora è stato lo studio e la personalizzazione del lazy-load dei moduli di una Zend Application, a partire da questo articolo di Stephen Roades
il problema fondamentale di un’applicazione fatta con Zend Framework 1.x è che i moduli sono una mera suddivisione funzionale del codice, sono risorse di norma sempre incluse a ogni esecuzione
il goal è quello di caricare on-demand solo i moduli che servono
ciò è ottenuto intervenendo nella catena del dispatch dell’applicazione Zend, analizzando la URL richiesta su quale route custom venga mappata e leggendo file ini di configurazione (per modulo e/o centralizzato), costruendo di fatto un’associazione request=>modulo da caricare
attraverso la configurazione è possibile specificare dipendenze tra moduli (o fisse, in modo da avere uno o più moduli sempre caricati), in modo da caricare altri moduli che servono al modulo caricato on-demand
studiare, capire, analizzare, modificare questo processo mi ha aiutato non solo a metabolizzare l’architettura di una zend application nel suo interno – imparando la gerarchia tra le varie risorse del framework, quali vengono caricate e dove – ma anche ad apprezzare i vincoli interni posti come framework, in virtù del fatto che un impianto solido che non dia sorprese amare, deve essere strutturato e usato con certe regole
regole e condizioni da assimilare come competenza organica, a cui non sopperirebbe la presenza di un ipotetico IDE completissimo: anche sviluppando in Java, con Eclipse o Netbeans, abbiamo a disposizione visual designer, autocompletamento, wizard anche potenti di terze parti, ma ciò non ti esime dal dover sapere la gerarchia delle classi, come esse si usino, quali siano “i mattoni giusti” da usare e per quale motivo siano meglio di altri
dico ciò perché mi fa sorridere (o a volte sbadigliare con disgusto) quando sento le solite lamentele di chi vorrebbe un simil-visualStudio per sviluppare in php con zend
non capisce che non è lo strumento a fare il programmatore
o forse proprio perché lo capisce, vuole quella roba, cosciente della propria pigrizia e/o delle proprie lacune
come al solito l’approccio giusto ha pagato per come mi ha fatto conoscere ZF 1.x, ora sto cominciando a guardare Zend Framework 2, anche se non è ancora uscito ufficialmente (è in RC2), che tratta i moduli finalmente come tali, oltre a un utilizzo totale dei namespaces, e altre caratteristiche che sto via via scoprendo
