la mia presentazione all'incontro di novembre 2013 del PUG Roma, su come gestire le librerie di frontend (tipicamente css e javascript) in un progetto PHP, con alcune considerazioni finali specifiche per Symfony2
Manuele Menozzi - Gestione delle dipendenze con Composer in Magento 2Meet Magento Italy
Una delle caratteristiche più importanti introdotte da Magento 2 è sicuramente la presenza nativa di un sistema di gestione delle dipendenze e del fatto che questo è stato completamente integrato nell’architettura di base.
In questo talk vediamo come la gestione delle dipendenze, che era comunque possibile in Magento 1, sia stata notevolmente migliorata in Magento 2 e quali vantaggi saranno portati a tutta la community grazie a questi miglioramenti.
2. Il problema della gestione delle dipendenze affligge da tempo qualsiasi sviluppatore che non voglia reinventare la ruota. Questo problema può essere affrontato da due punti di vista: quello dello sviluppatore che ha bisogno di usare una libreria e quello dello sviluppatore che ha creato la propria libreria e vuole distribuirla
3. Una prima possibile soluzione al problema è: scaricare i sorgenti della libreria e installarli a mano. Questa soluzione ovviamente è molto scomoda e ha molti difetti: difficoltà di manutenzione, difficoltà di replicazione, difficoltà o impossibilità di versionamento. È stata mostrata solo per motivi "storici"
4. PEAR è stato per molto tempo lo standard de facto per la gestione delle librerie. Il suo problema principale era nella necessità di dover installare le librerie a livello di sistema, mentre spesso è necessario gestire versioni diverse su progetti diversi. Un altro problema è che è rimasto poco sviluppato e ancorato alla compatibilità con PHP4
5. Un altra possibile soluzione è la gestione delle dipendenze nel sistema di versioanmento: externals per subversion, submoduli per git, eccetera. Difetti di questo approccio: lo sviluppatore di librerie dovrebbe tenere un repository per ogni sistema, l'utilizzatore è costretto a gestire in contemporanea aggiornamenti delle revisioni del suo progetto e aggiornamenti delle librerie
6. Un approccio più recente e interessante è stato quello adottato da Symfony 2.0, cioè uno script di gestione scritto ad hoc. Purtroppo non era in grado di gestire le dipendenze indirette ed era legato strettamente a git
8. Il primo passo per usare Composer è installarlo. La procedura è molto semplice, trattandosi di uno script PHP da linea di comando: basta scaricare l'installer ed eseguirlo. Non obbligatorio, ma consigliato, spostare l'eseguibile sotto a un percorso incluso in $PATH. Pper sistemi non Unix-compatibili... non lo so! Arrangiatevi
9. L'installazione delle librerie è facile: basta eseguire il comando seguito dal parametro "install". Occorre però preparare un file di configurazione
10. Questo esempio di file di configurazione di Composer è tratto da Symfony Standard Edition, con alcune righe tagliate per questioni di spazio.
11. Vediamo ora un esempio su come pubblicare la propria libreria, tratta da un caso reale; un bundle per Symfony2 creato sotto PUGX. Il primo passo è quello di pubblicare il progetto su github
12. Questo è il file composer.json del bundle, con le sue dipendenze e le impostazioni per l'autoloading
13. Il passo successivo consiste nel pubblicare la libreria su Packagist, configurando le impostazioni relative all'integrazione con github
14. Tutto qui! Come direbbe il Principe, è fatta! Non serve niente di più di questo, è molto facile e consente di gestire dipendenze a cascata.
15. Ma se io avessi l'esigenza di usare una libreria che non è open source e quindi non posso mettere su github? Si possono impostare altri reposi
Manuele Menozzi - Gestione delle dipendenze con Composer in Magento 2Meet Magento Italy
Una delle caratteristiche più importanti introdotte da Magento 2 è sicuramente la presenza nativa di un sistema di gestione delle dipendenze e del fatto che questo è stato completamente integrato nell’architettura di base.
In questo talk vediamo come la gestione delle dipendenze, che era comunque possibile in Magento 1, sia stata notevolmente migliorata in Magento 2 e quali vantaggi saranno portati a tutta la community grazie a questi miglioramenti.
2. Il problema della gestione delle dipendenze affligge da tempo qualsiasi sviluppatore che non voglia reinventare la ruota. Questo problema può essere affrontato da due punti di vista: quello dello sviluppatore che ha bisogno di usare una libreria e quello dello sviluppatore che ha creato la propria libreria e vuole distribuirla
3. Una prima possibile soluzione al problema è: scaricare i sorgenti della libreria e installarli a mano. Questa soluzione ovviamente è molto scomoda e ha molti difetti: difficoltà di manutenzione, difficoltà di replicazione, difficoltà o impossibilità di versionamento. È stata mostrata solo per motivi "storici"
4. PEAR è stato per molto tempo lo standard de facto per la gestione delle librerie. Il suo problema principale era nella necessità di dover installare le librerie a livello di sistema, mentre spesso è necessario gestire versioni diverse su progetti diversi. Un altro problema è che è rimasto poco sviluppato e ancorato alla compatibilità con PHP4
5. Un altra possibile soluzione è la gestione delle dipendenze nel sistema di versioanmento: externals per subversion, submoduli per git, eccetera. Difetti di questo approccio: lo sviluppatore di librerie dovrebbe tenere un repository per ogni sistema, l'utilizzatore è costretto a gestire in contemporanea aggiornamenti delle revisioni del suo progetto e aggiornamenti delle librerie
6. Un approccio più recente e interessante è stato quello adottato da Symfony 2.0, cioè uno script di gestione scritto ad hoc. Purtroppo non era in grado di gestire le dipendenze indirette ed era legato strettamente a git
8. Il primo passo per usare Composer è installarlo. La procedura è molto semplice, trattandosi di uno script PHP da linea di comando: basta scaricare l'installer ed eseguirlo. Non obbligatorio, ma consigliato, spostare l'eseguibile sotto a un percorso incluso in $PATH. Pper sistemi non Unix-compatibili... non lo so! Arrangiatevi
9. L'installazione delle librerie è facile: basta eseguire il comando seguito dal parametro "install". Occorre però preparare un file di configurazione
10. Questo esempio di file di configurazione di Composer è tratto da Symfony Standard Edition, con alcune righe tagliate per questioni di spazio.
11. Vediamo ora un esempio su come pubblicare la propria libreria, tratta da un caso reale; un bundle per Symfony2 creato sotto PUGX. Il primo passo è quello di pubblicare il progetto su github
12. Questo è il file composer.json del bundle, con le sue dipendenze e le impostazioni per l'autoloading
13. Il passo successivo consiste nel pubblicare la libreria su Packagist, configurando le impostazioni relative all'integrazione con github
14. Tutto qui! Come direbbe il Principe, è fatta! Non serve niente di più di questo, è molto facile e consente di gestire dipendenze a cascata.
15. Ma se io avessi l'esigenza di usare una libreria che non è open source e quindi non posso mettere su github? Si possono impostare altri reposi
Il Symfony CMF è maturo e ci permette di creare le basi per un content manager integrandolo direttamente in applicazioni Symfony nuove o già esistenti.
Una user story non è completa finché non è nelle mani di chi la deve usare. Solo da lì inizia a produrre valore, sia esso economico o sia feedback. Che si tratti di master, preview o production, con l’automazione delle build si possono evitare operazioni ripetitive, complesse, risparmiare tempo, ottenere interessanti metriche sul codice, tutto al fine di arrivare a poter rilasciare ogni poche ore (o, se volete, ogni volta che la build è verde!). Farlo in modo frequente è possibile anche con Symfony2. Mettiamo in pratica con un esempio una delle 12 pratiche di Extreme Programming: continuous delivery e integration tra git, bash, Jenkins e strumenti deploy.
Apache Maven - Gestione di progetti Java e build automationTiziano Serritella
Apache Maven è un tool per la gestione di progetti e build automation, utilizzato principalmente per progetti Java, il cui obiettivo è: semplificare, uniformare e automatizzare il processo di build di sistemi complessi.
In questa presentazione / guida verranno illustrati i problemi e le criticità dei tool di build automation tradizionali: make e Apache Ant, vedremo poi come installare e configurare Maven, le caratteristiche, gli obiettivi e i punti di forza del tool, le fasi del ciclo di vita, i plugin e i goal, le dipendenze, gli scope e la risoluzione di eventuali conflitti, i repository, i plugin "esterni" e i progetti multi-modulo.
La presentazione è ricca di esempi pratici.
Durante la mia lunga e intima amicizia con Lotus Holmes, non lo avevo mai inteso parlare del package “com.ibm.notes.java.ui” prima del rilascio della versione 8.5.
Presente inizialmente come "undocumented feature", il mistero fu svelato grazie all'aiuto degli Irregolari di Eclipse Street.
Da quel giorno fu possibile creare plug-ins per il client Notes in grado, ad esempio, di interagire con i documenti selezionati in una vista, evitando di replicare lo stesso agente su ciascun database per tutte quelle sempreverdi necessità di front-end (modifica di campi, aggiunta di autori e lettori, e così via) o di esportare dati dal documento o dalla vista attivi a fogli di calcolo o documenti Lotus Symphony.
Un'ulteriore prova, se mai ce ne fosse stato bisogno, che l'unica risposta possibile per tutte quelle domande relative al miglior software per la collaborazione e il group working, orientato all'integrazione con strumenti di desktop office è una e una soltanto: «Elementare: Notes!».
Caso risolto.
Grunt: automazione per sviluppatori “pigri” - WordCamp Bari 2019Marco Chiesi
Nel lavoro quotidiano di uno sviluppatore capita spesso di dover eseguire azioni ripetitive e noiose. Per fortuna esistono strumenti come Grunt che consentono di automatizzare tali operazioni permettendo al programmatore di concentrarsi sugli aspetti importanti del proprio lavoro. Grunt è un task runner molto versatile grazie alla sua struttura a plugin ed è ampiamente diffuso nell’ambito dello sviluppo di plugin e temi per WordPress.
Distribuire una libreria Java per usarla come dipendenza gradlePaolo Montalto
L'utilizzo di dipendenze software è una tecnica entrata già da tempo nella pratica quotidiana di ciascun buon programmatore. I suoi vantaggi sono indubbi ma non tutti sanno come funzionano le dipendenze e come sia possibile rendere disponibile pubblicamente la propria libreria.
In questo talk cerco di spiegare per quale motivo è importante utilizzare dipendenze software, come funzionano, perché può essere utile pubblicare le proprie librerie e come è possibile farlo, mostrando un caso reale basato su Gradle.
Il Symfony CMF è maturo e ci permette di creare le basi per un content manager integrandolo direttamente in applicazioni Symfony nuove o già esistenti.
Una user story non è completa finché non è nelle mani di chi la deve usare. Solo da lì inizia a produrre valore, sia esso economico o sia feedback. Che si tratti di master, preview o production, con l’automazione delle build si possono evitare operazioni ripetitive, complesse, risparmiare tempo, ottenere interessanti metriche sul codice, tutto al fine di arrivare a poter rilasciare ogni poche ore (o, se volete, ogni volta che la build è verde!). Farlo in modo frequente è possibile anche con Symfony2. Mettiamo in pratica con un esempio una delle 12 pratiche di Extreme Programming: continuous delivery e integration tra git, bash, Jenkins e strumenti deploy.
Apache Maven - Gestione di progetti Java e build automationTiziano Serritella
Apache Maven è un tool per la gestione di progetti e build automation, utilizzato principalmente per progetti Java, il cui obiettivo è: semplificare, uniformare e automatizzare il processo di build di sistemi complessi.
In questa presentazione / guida verranno illustrati i problemi e le criticità dei tool di build automation tradizionali: make e Apache Ant, vedremo poi come installare e configurare Maven, le caratteristiche, gli obiettivi e i punti di forza del tool, le fasi del ciclo di vita, i plugin e i goal, le dipendenze, gli scope e la risoluzione di eventuali conflitti, i repository, i plugin "esterni" e i progetti multi-modulo.
La presentazione è ricca di esempi pratici.
Durante la mia lunga e intima amicizia con Lotus Holmes, non lo avevo mai inteso parlare del package “com.ibm.notes.java.ui” prima del rilascio della versione 8.5.
Presente inizialmente come "undocumented feature", il mistero fu svelato grazie all'aiuto degli Irregolari di Eclipse Street.
Da quel giorno fu possibile creare plug-ins per il client Notes in grado, ad esempio, di interagire con i documenti selezionati in una vista, evitando di replicare lo stesso agente su ciascun database per tutte quelle sempreverdi necessità di front-end (modifica di campi, aggiunta di autori e lettori, e così via) o di esportare dati dal documento o dalla vista attivi a fogli di calcolo o documenti Lotus Symphony.
Un'ulteriore prova, se mai ce ne fosse stato bisogno, che l'unica risposta possibile per tutte quelle domande relative al miglior software per la collaborazione e il group working, orientato all'integrazione con strumenti di desktop office è una e una soltanto: «Elementare: Notes!».
Caso risolto.
Grunt: automazione per sviluppatori “pigri” - WordCamp Bari 2019Marco Chiesi
Nel lavoro quotidiano di uno sviluppatore capita spesso di dover eseguire azioni ripetitive e noiose. Per fortuna esistono strumenti come Grunt che consentono di automatizzare tali operazioni permettendo al programmatore di concentrarsi sugli aspetti importanti del proprio lavoro. Grunt è un task runner molto versatile grazie alla sua struttura a plugin ed è ampiamente diffuso nell’ambito dello sviluppo di plugin e temi per WordPress.
Distribuire una libreria Java per usarla come dipendenza gradlePaolo Montalto
L'utilizzo di dipendenze software è una tecnica entrata già da tempo nella pratica quotidiana di ciascun buon programmatore. I suoi vantaggi sono indubbi ma non tutti sanno come funzionano le dipendenze e come sia possibile rendere disponibile pubblicamente la propria libreria.
In questo talk cerco di spiegare per quale motivo è importante utilizzare dipendenze software, come funzionano, perché può essere utile pubblicare le proprie librerie e come è possibile farlo, mostrando un caso reale basato su Gradle.
Similar to Gestire librerie di frontend in php (20)
My short presentation at Symfony Live 2008 unconference, about translating Symfony docs (notice: this is a repost, since Slideshare deleted original one and has not be able to recover it. Shame on you, Slideshare!)