Sviluppare un plugin WordPress da zero - WordCamp Bologna 2018Marco Chiesi
Se sei un programmatore interessato a WordPress ma non hai mai sviluppato un plugin, il WordCamp Bologna è l’occasione giusta per iniziare. Seguendo questo talk introduttivo avrai modo di scoprire i concetti di base, le convenzioni, le buone pratiche, le misure di sicurezza, l’architettura e le principali funzionalità messe a disposizione dalla piattaforma. In questo modo potrai riuscire a muovere i primi passi nel mondo dello sviluppo WordPress e a orientarti meglio in mezzo all’enorme mole di materiale informativo disponibile in rete.
Tightening the screws è lo slogan che caratterizza questo nuovo rilascio di TYPO3 CMS. La versione 8.1 introduce aggiornamenti sull'interfaccia grafica del modulo workspace, la gestione dei database con Doctrine e molti altri miglioramenti.
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.
Apache Maven è un software per la gestione di progetti. Basato sul concetto di project object model (POM), un punto centralizzato di informazione, Maven può gestire la build, i report la documentazione, e molto altro.
Il 10 novembre 2015 viene rilasciato TYPO3 CMS 7.6, la nuova versione LTS con supporto fino al 2018. Queste le differenze con la versione 7.5 e fra qualche giorno i documenti con tutte le differenze tra TYPO3 CMS 6.2 LTS e TYPO3 CMS 7 LTS
Sviluppare un plugin WordPress da zero - WordCamp Bologna 2018Marco Chiesi
Se sei un programmatore interessato a WordPress ma non hai mai sviluppato un plugin, il WordCamp Bologna è l’occasione giusta per iniziare. Seguendo questo talk introduttivo avrai modo di scoprire i concetti di base, le convenzioni, le buone pratiche, le misure di sicurezza, l’architettura e le principali funzionalità messe a disposizione dalla piattaforma. In questo modo potrai riuscire a muovere i primi passi nel mondo dello sviluppo WordPress e a orientarti meglio in mezzo all’enorme mole di materiale informativo disponibile in rete.
Tightening the screws è lo slogan che caratterizza questo nuovo rilascio di TYPO3 CMS. La versione 8.1 introduce aggiornamenti sull'interfaccia grafica del modulo workspace, la gestione dei database con Doctrine e molti altri miglioramenti.
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.
Apache Maven è un software per la gestione di progetti. Basato sul concetto di project object model (POM), un punto centralizzato di informazione, Maven può gestire la build, i report la documentazione, e molto altro.
Il 10 novembre 2015 viene rilasciato TYPO3 CMS 7.6, la nuova versione LTS con supporto fino al 2018. Queste le differenze con la versione 7.5 e fra qualche giorno i documenti con tutte le differenze tra TYPO3 CMS 6.2 LTS e TYPO3 CMS 7 LTS
La versione 10.1 di TYPO3 è la seconda versione dello sprint per arrivare alla versione LTS (supporto a lungo termine) nel 2020.
La nuova release ingloba più di 240 commit di Git (modifiche del codice sorgente revisionate, testate e approvate) dalla sua versione precedente la 10.0 pubblicata dieci settimane prima.
Sebbene gli utenti di backend non vedranno molti cambiamenti evidenti o nuove funzionalità importanti, TYPO3 versione 10.1 racchiude una serie di miglioramenti nel core.
Come installare Liferay 7 su JBOSS EAP con il supporto Oracle DatabaseAntonio Musarra
Nel corso di questa guida vedremo come installare Liferay 7 Community Edition su JBOSS EAP 6.4 con il supporto a Oracle Database. Chi di voi mi segue sul mio blog, saprà che subito dopo l’uscita della prima GA di Liferay 7 ho aggiunto il supporto per Oracle Database rimosso dalla Community Edition da Liferay.
1. Repository liferay-7-jboss-eap-home con la struttura e file di configurazione di Liferay e JBOSS EAP 6.4.0.GA -https://github.com/amusarra/liferay-7-jboss-eap-home
2. Liferay 7 Wildfly: How to add support for Oracle DB - Antonio Musarra’s Blog YouTube Channel - https://www.youtube.com/watch?v=7fojCjko7Ac
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
La versione 10.1 di TYPO3 è la seconda versione dello sprint per arrivare alla versione LTS (supporto a lungo termine) nel 2020.
La nuova release ingloba più di 240 commit di Git (modifiche del codice sorgente revisionate, testate e approvate) dalla sua versione precedente la 10.0 pubblicata dieci settimane prima.
Sebbene gli utenti di backend non vedranno molti cambiamenti evidenti o nuove funzionalità importanti, TYPO3 versione 10.1 racchiude una serie di miglioramenti nel core.
Come installare Liferay 7 su JBOSS EAP con il supporto Oracle DatabaseAntonio Musarra
Nel corso di questa guida vedremo come installare Liferay 7 Community Edition su JBOSS EAP 6.4 con il supporto a Oracle Database. Chi di voi mi segue sul mio blog, saprà che subito dopo l’uscita della prima GA di Liferay 7 ho aggiunto il supporto per Oracle Database rimosso dalla Community Edition da Liferay.
1. Repository liferay-7-jboss-eap-home con la struttura e file di configurazione di Liferay e JBOSS EAP 6.4.0.GA -https://github.com/amusarra/liferay-7-jboss-eap-home
2. Liferay 7 Wildfly: How to add support for Oracle DB - Antonio Musarra’s Blog YouTube Channel - https://www.youtube.com/watch?v=7fojCjko7Ac
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
Come portare il profiler di symfony2 in drupal8Luca Lusso
Molti progetti PHP open source hanno adottato Symfony2 come base per la loro prossima versione, tra questi c'è anche il CMS Drupal (http://drupal.org). In questo talk vedremo come scrivere un modulo per Drupal8 in modo da sfruttare il più possibile il suo nuovo motore Symfony2, dall'integrazione con il service container alla gestione degli eventi, dal routing a Twig. Verrà usato come esempio il modulo webprofiler (http://drupal.org/project/webprofiler) per dimostrare come un bundle per Symfony2 possa essere trasformato in un modulo per Drupal8 e integrato facilmente nel sistema.
Quali strumenti utilizzare per migliorare il workflow di uno sviluppatore? Oggi strumenti come git, docker, gitlab e kubernetes ci aiutano a gestire meglio il nostro tempo permettendoci di focalizzarci di piu' sul codice che sulla customizzazione dell'ambiente.
1. Roma, 5 Marzo 2011
Pacchi e pacchetti
Introduzione al packaging RPM
Gianluca Sforna
Fedora Project contributor
Questa presentazione è disponibile con la licenza Creative Commons Attribution-ShareAlike (BY-SA) 3.0
ad eccezione dei logo e dei trademark Red Hat e Fedora, usati con permesso.
3. Cosa è RPM
sia formato che gestore
pacchetti
basato su database
traccia dipendenze
verifica dei pacchetti
Image CC-BY
http://www.flickr.com/photos/leecannon/4832542876
incluso in LSB
usato da Red Hat Enterprise
Linux, Fedora e altri
4. Perchè pacchettiziamo
standardizza deployment
sicuro di averlo installato
semplifica l'ambiente
sicuro di come trovarlo
gestione conformità
sicuro di cosa è presente
5. Miti da sfatare
non funziona molto bene
difficile creare pacchetti
difficile installare pacchetti
difficile rimuovere pacchetti
incubi da dipendenze
dependency hell
Image CC-BY
http://www.flickr.com/photos/miheco/2167149428/
6. Il mostro non esiste!
RPM è spesso sottovalutato
funziona molto bene
creare pacchetti è più facile
di ciò che si crede
facili da installare...
facili da rimuovere...
... se sono fatti bene!
7. Il nodo dipendenze
le dipendenze sono utili
ma possono diventare un
problema
yum risolve il problema
metadati estratti dai pacchetti
yum usa i metadati per
Image CC-BY
http://www.flickr.com/photos/psyberartist/3483489839/
risolvere le dipendenze
installa il necessario, rimuove
quello che non serve più
8. Packaging come norma
controllo utilizzo del software
cosa, dove, quando?
controllo versione
integrazione kickstart
minimizzazione rischi
sicurezza
applicazioni indesiderate
licenza
9. Concetti base RPM
pacchetto binario:
goldfish-1.0.0-1.i386.rpm
goldfish - nome
1.0.0 - versione
1 – release
i386 - architettura
10. Operazioni
installazione => nome del file
rpm -ivh goldfish-1.0.0-1.i386.rpm
i: install, v: verbose, h: mostra hash (#)
interrogazione => nome pacchetto
rpm -ql goldfish
q: query, l: list files
rimozione => nome pacchetto
rpm -e goldfish
e: erase
11. Source RPM (SRPM)
pacchetto sorgente
goldfish-1.0.0-1.src.rpm
gli SRPM contengono
tutto il necessario per
generare i pacchetti RPM
binari
file spec
sorgenti (tar.gz)
patch
12. Operazioni SRPM
installazione => nome del file SRPM
rpm -ivh goldfish-1.0.0-1.src.rpm
i files finiscono nella source directory
Red Hat default:
/usr/src/redhat/SOURCES
SRPM non entrano del database RPM
rimozione => spec file name
rpmbuild --rmsource --rmspec goldfish.spec
13. Dai sorgenti al binario
creazione dei pacchetti binari dal SRPM:
rpmbuild --rebuild goldfish-1.0.0-1.src.rpm
creazione rpm dal file spec
rpmbuild -ba goldfish.spec
-b: build, -a: all packages (src e binari)
i sorgenti con le patch applicate vanno nella
"builddir"
Red Hat default:
/usr/src/redhat/BUILD
15. Build da utente
creare ambiente di build nella propria home
mkdir -p ~/rpmbuild/
{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
mkdir -p ~/rpmbuild/RPMS/{noarch,i386,i686}
aggiungere in ~/.rpmmacros:
%_topdir %(echo $HOME)/rpmbuild
in Fedora, lo stesso risultato si ottiene col
comando 'rpmdev-setuptree' (presente in
'rpmdevtools')
16. Macro
Simili alle variabili negli script shell
possono comportarsi da stringhe o interi ma è più
semplice trattarle sempre da stringhe
le più comuni macro sono già definite
rpm --showrc mostra tutte le macro definite
rpm --eval %{macroname} mostra l'espansione
della macro
quasi tutte le macro di sistema inziano con _
(es. %{_bindir})
17. Macro utente
~/.rpmmacros
permette di avere macro specifiche per utente
attenzione se si usano nello spec
le macro definite per utente non saranno presenti
in altri sistemi
18. Preparare un RPM
il file spec è come una ricetta
simile ad uno script shell
elenca i contenuti dell'RPM
sorgenti
patch
altri file
descrive il processo di build
Image CC-BY-SA
http://www.flickr.com/photos/ted_major/5045483028
19. Anatomia di uno spec
preambolo
%prep (setup)
%build
%install
%clean Image CC-BY
http://www.flickr.com/photos/27620885@N02/2671077524/
%files
%changelog
20. spec file: preambolo
sezione iniziale
proprietà del pacchetto
Name/Version/Group/License
Release (revisione del pacchetto)
Source/Patch
Require (dipendenze)
compilazione e installazione
Summary/Description
definizione macro locali
21. Esempio di preambolo
Name: helloworld
Version: 1.1
Release: 3
Summary: An application that prints “Hello World!”
License: GPLv2+
Group: System Environment/Base
Source0: http://helloworld.com/helloworld-1.1.tar.gz
Patch0: fixtypo.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
%description
This program prints hello world on the screen to avoid the “programmers
curse”. The Programmmers Curse states that unless your first example is
“Hello World!”, then you will be cursed, and never able to use that tool.
23. spec file: build
creazione componenti binarie
macro %configure
utile per progetti basati su autotools
esegue ./configure con sane opzioni di default
24. esempio %build
%build
%configure
make %{?_smp_mflags}
da adattare a seconda del metodo di build
usato (scons, cmake, etc) dal progetto
25. spec file: install
creazione della buildroot
preparazione struttura del filesystem
copia dei file compilati nella buildroot
eventuale pulizia file installati non necessari
26. esempio %install
%install
rm -rf %{buildroot}
mkdir -p %{buildroot}%{_bindir}
cp helloworld.sh %{buildroot}%{_bindir}/helloworld
%{_bindir}
macro che espande a /usr/bin.
%{buildroot}
directory in cui vengono installati i files prima di
essere copiati negli RPM binari
definita nel preambolo
27. spec file: clean & files
clean cancella la buildroot
files: elenca il contenuto del
pacchetto
se non appare in %files, non c'è
nel pacchetto
RPM si fermerà in presenza di
file non pacchettizzati
MAI cercare di aggirare il controllo
28. esempio %clean e %files
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%attr(0755,gold,fish) %{_bindir}/helloworld
29. spec file: changelog
usato per annotare i cambiamenti al pacchetto
non è una alternativa al changelog dei sorgenti
da aggiornare ad OGNI cambiamento
esempio di sezione %changelog:
%changelog
* Mon Jun 2 2008 Gianluca Sforna <giallu@gmail.com> 1.1-3
- minor example changes
* Mon Apr 16 2007 Gianluca Sforna <giallu@gmail.com> 1.1-2
- update example package
* Sun May 14 2006 Gianluca Sforna <giallu@gmail.com> 1.1-1
- initial package
30. Best Practices
K.I.S.S.
una patch per ogni modifica
evitare pre/post quando possibile
usare sempre il changelog
ispirarsi a pacchetti Fedora
usare macro (correttamente)
essere coerenti
preferire macro di sistema
31. Altre Best Practices
usare rpmlint, correggere gli errori
segnalati
includere config/script come files
(Source#)
Commenti!
...ma che lo spec rimanga leggibile
pensare a chi dovrà lavorare al
pacchetto dopo di noi.
MAI eseguire rpm da uno spec file
come in Ghostbusters.
Incrociare i flussi? male.
32. Errori di inesperienza
generatori di pacchetti
"funziona" non è lo stesso di
"fatto bene"
pacchettizzare binari, non
partendo dai sorgenti
non sempre evitabile, ma potendo
scegliere meglio non farlo
disattivare controllo file non
pacchettizzati
solo se si è in cerca di guai...
33. Link utili
Linee guida per il packaging:
http://fedoraproject.org/wiki/Packaging:Guidelines
http://fedoraproject.org/wiki/Packaging:ReviewGuidelines
Maximum RPM:
http://rpm.org/max-rpm-snapshot/
Fedora GIT Tree (contiene migliaia di spec)
http://pkgs.fedoraproject.org/gitweb/
Rpmlint website:
http://rpmlint.zarb.org