An overview of technologies and best practices for the development of a full-stack web application using JavaScript. How to realize an entire Application Server with a single programming language, the use of event-driven logic and the potential of Node.js.
Sempre più di frequente sentiamo parlare di nuove librerie, framework o linguaggi. Tutte queste nuove tecnologie promettono miracoli ma il nostro tempo è una risorsa finita e non abbiamo il lusso di poter approfondire ogni novità.
Le PWA si basano su tecnologie che già usiamo tutti i giorni nello sviluppo WEB quindi, senza farci intimidire, possiamo approcciare qualcosa che effettivamente rivoluzioni il nostro lavoro e che possa farlo con il minimo sforzo da parte nostra.
Biglietti, prego! - A ticket for the (command) busFrancesco Face
Usare command bus e event bus in progetti symfony, per scrivere software facilmente adattabili a nuove necessità.
Codice di esempio: https://github.com/magobaol/ticket-office
How to use command bus and event bus in symonfy project to create easily adaptive applications.
Final sample code: https://github.com/magobaol/ticket-office
An overview of technologies and best practices for the development of a full-stack web application using JavaScript. How to realize an entire Application Server with a single programming language, the use of event-driven logic and the potential of Node.js.
Sempre più di frequente sentiamo parlare di nuove librerie, framework o linguaggi. Tutte queste nuove tecnologie promettono miracoli ma il nostro tempo è una risorsa finita e non abbiamo il lusso di poter approfondire ogni novità.
Le PWA si basano su tecnologie che già usiamo tutti i giorni nello sviluppo WEB quindi, senza farci intimidire, possiamo approcciare qualcosa che effettivamente rivoluzioni il nostro lavoro e che possa farlo con il minimo sforzo da parte nostra.
Biglietti, prego! - A ticket for the (command) busFrancesco Face
Usare command bus e event bus in progetti symfony, per scrivere software facilmente adattabili a nuove necessità.
Codice di esempio: https://github.com/magobaol/ticket-office
How to use command bus and event bus in symonfy project to create easily adaptive applications.
Final sample code: https://github.com/magobaol/ticket-office
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!)
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
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
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!)
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
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