Recentemente (il 15 marzo 2018) ho conseguito la Laravel Certification.

Se sei interessato anche tu a conseguirlo, spero che queste poche righe possanno esserti d’aiuto nel chiarirti qualche dubbio o darti qualche informazione. Se hai ulteriori dubbi o domande, commenta pure questo articolo o contattami in privato, sarò lieto di rispondere!

Come ci si iscrive?

Occorre innanzitutto acquistare un voucher su https://laravel.com/certification. Io l’ho acquistato quando era ancora in promozione e non era ancora possibile sostenere l’esame, quindi i tempi sono stati decisamente più lunghi. Ad ogni modo, dopo aver effettuato l’acquisto (suppongo qualche giorno dopo), riceverai una mail contenente un link che consente di iniziare la sessione di esame. Dalla ricezione di quest’ultima mail, hai tre mesi di tempo per sostenere l’esame.

Come si svolge l’esame?

L’esame dura circa 50 minuti (il tempo preciso non lo ricordo, comunque parliamo di un’ora o poco meno) e consiste in esattamente 45 domande a risposta multipla (4 o 5 risposte, mi pare) su argomenti inerenti Laravel 5.5 (es. route, controller, middleware, eventi, model, collection, Composer ecc.); sono esclusi i vari “prodotti dell’ecosistema Laravel” (es. Homestead, Cashier, Horizon, ecc.). E’ interamente in inglese (almeno per il momento), quindi è ovviamente richiesta una buona comprensione dell’inglese scritto (devo ammettere che mi è toccato rileggere un paio di domande per capirne il significato preciso).

Per sostenere l’esame occorre utilizzare il browser Chrome, installando un plugin che verifica innanzitutto che i requisiti minimi siano rispettati: banda sufficiente, presenza di una webcam e così via. A cosa server questo plugin? E’ una sorta di esaminatore: si occupa di registrare audio, video e contenuto dello schermo. Insomma, viene registrato tutto ciò che succede sullo schermo, ciò dici o fai davanti alla webcam. In pratica, è impossibile barare.
Una volta superata la fase di verifica da parte del plugin, ti viene richiesto di mostrare un documento di identità, assieme al tuo volto; durante l’esame non è possibile uscire dalla stanza, non ci possono essere altre persone, non puoi consultare libri, manuali (e credo anche altri dispositivi, nonostante non mi pare ci fosse scritto esplicitamente).

La maggior parte delle domande consiste in un frammento di codice da leggere, comprendere ed “eseguire mentalmente”; spesso le risposte sono molto simili tra loro, per cui un po’ per la “tensione”, un po’ per il poco tempo a disposizione, è facile farsi venire dei dubbi, te lo assicuro!

E’ possibile saltare una o più domande e riprenderle successivamente; è consentito non rispondere ad una o più domande; una risposta sbagliata è più penalizzante di una risposta saltata.

A fine esame cosa succede?

Una volta terminata la sessione, occorre attendere qualche giorno per ricevere i risultati.
Nel mio caso, ci sono voluti una decina di giorni. La mail diceva “una settimana circa”, tant’è che a un certo punto ho iniziato a pensare “magari ti avvisano solo se l’hai passato…”.
La correzione viene effettuata da un bot (così dicono), in modo da garantire imparzialità.

Hai qualche consiglio?

Primo fra tutti: sostieni l’esame quando sei riposato! Non fare come il sottoscritto che, spinto dalla curiosità, ha cliccato sul link un lunedì sera alle 21.30, dopo una giornata lavorativa di dieci ore. E’ andata bene lo stesso, ma ero davvero stanco e ho fatto fatica a mantenere la concentrazione. Siamo d’accordo: non è né l’esame di maturità né una certificazione CISCO, ma se puoi scegliere quando sostenerla, tanto vale farlo in un giorno in cui non lavori o sei maggiormente riposato.

Se leggi una domanda, sei fortemente in dubbio sul significato o sei indeciso fra due o peggio ancora più risposte, il mio consiglio è di saltare la domanda e riprenderla più avanti. Se perdi troppo tempo, soprattutto sulle prime domande, non ti rendi bene conto di quanto tempo stia passando… E ti troverai a dover rispondere alle ultime domande di corsa!
Alla fine, se sei ancora indeciso fra le risposte di una domanda, a meno che tu non voglia sfidare la sorte, meglio saltarla che rispondere in maniera errata: il secondo caso è più penalizzante del primo.

Riguardo alla preparazione: limitatamente alla mia esperienza, posso consigliare, ad esempio, di provare prima dell’esame tutti metodi delle Collection, dato che mi sono capitate 2-3 domande inerenti. Un conto è aver dato un’occhiata a grandi linee a ciascun metodo, sapere che esiste e più o meno ricordarsi cosa faccia; tutt’altra cosa è averlo utilizzato e assimilato stabilmente. Lo dico perché, ad esempio, io non ero preparatissimo su ciascun metodo, anzi: sinceramente, qualcuno non l’ho mai utilizzato, dato che non mi è capitato di doverlo fare. Sembra una banalità, ma un po’ per il tempo limitato, un po’ per la “tensione”, è facile farsi venire dubbi sul risultato quale risultato preciso produca un determinato metodo.

Un paio di domande erano sui middleware (before e after); altre riguardavano la validazione, il valore e/o la visibilità di alcune proprietà di un model in presenza di accessor, mutator, $hidden e $appends (tutto assieme – era un po’ contorto). C’era un po’ di tutto: eventi e listener, route, eager loading, domande più teoriche, altre (la maggior parte) più “pratiche” (codice di casi d’uso reali).

Sì, ma quanto mi costa?

Il costo per sostenere l’esame è di € 249 + IVA.

E’ anche possibile certificare un team, ovvero un gruppo di 5 o più sviluppatori. Costi a partire da € 1120,50 + IVA.

Per ogni informazione, è possibile consultare il sito ufficiale: https://laravel.com/certification. Dopo aver consultato le FAQ, è anche possibile lasciare un messaggio: verrai ricontattato e ti forniranno le risposte alle vostre domande.

In bocca al lupo per la tua certificazione!

Torno a scrivere su queste pagine dopo qualche mese di silenzio stampa per un annuncio molto, molto importante.

In realtà l’avevo annunciato già sulla nostra pagina Facebook ma adesso ci sono più informazioni e vale la pena buttare giù due righe.

L’agenda del LaravelDay, il primo LaravelDay, è pronta!

Ed è possibile trovarla qui.

Prima di procedere con il darvi qualche informazione in più, c’è da fare una precisazione doverosa. In tanti mi hanno chiesto come mai non terrò un mio talk durante l’evento.

La spiegazione è semplice: la community nel corso di questi anni è cresciuta un sacco. Questa community è un insieme di persone e queste persone hanno avuto, con Laravel, esperienze esattamente come le ho avute io.

Della mia esperienza ho parlato un sacco: fino a qualche giorno fa, durante Codemotion 2017 a Milano.

Stavolta è il turno della community: ho preferito lasciare spazio a tutte queste “nuove leve” che la scena offre. Fidatevi: ho fatto bene. Io sarò comunque presente: farò una breve presentazione della community all’inizio della giornata.

I Talk

Ok, veniamo alla parte più succosa. Quali talk ci aspettano?

• “RESTful API: la novità in Laravel 5.5” di Christopher Pecoraro;
• “Deploy di applicazioni Laravel con le pipeline di Bitbucket” di Simone Gentili;
• “Codemotion, Laravel & me: 3 anni in un’azienda in rapida crescita” di Tsuneo Kurihara;
• “Playmoove: Shared mobility within everyone’s reach (developers included)” di Riccardo Scasseddu;
• “Using Repository Pattern with Eloquent for Code That Lasts” di Damiano Petrungaro;
• “Laravel Doctrine: a Data Mapper approach” di Christian Nastasi;
• “Automatizzare i test sulla UI con Dusk” di Gianfranco Castro;
• “Designing Virtual Reality App with Laravel Integration” di Danilo Costa;
• “12 Factors Laravel” di Dario Tranchitella;

Insomma, una giornata bella piena di roba interessante. Molti di questi ragazzi li conosco già. Christopher lo conosco praticamente da quando conosco Laravel. Damiano e Christian mi daranno una mano nella gestione della community e, onestamente, sono curiosissimo di sentire il buon Tsuneo e la sua esperienza.

Ci divertiremo.

Era un po’ che volevo scrivere questo articolo: ed in un certo senso era anche l’ora, visto che non pubblico da queste parti da… quanto? Un mese e più?

Insomma, è passato un po’ di tempo dall’ultimo articolo, dedicato alla configurazione base di TravisCI per un progetto Laravel. Da quel punto in poi non ho praticamente scritto più nulla, e sono diventato anche un “latitante” tra Forum e Slack (ok, su Slack un po’ di meno).

Insomma: cosa è successo? Laravel-Italia è fermo? Proprio in questo periodo di fermento?

Assolutamente no.

So Far, So Good

Semplicemente ho avuto molto poco tempo. Lo ammetto, anche un po’ di voglia è venuta a mancare: in questo periodo mi sto dedicando ad una marea di cose diverse tra loro. Da cose inerenti all’informatica (Elixir ed il suo framework, Phoenix, realtà molto interessante) al premere tasti su altre tastiere (non è mai troppo tardi per imparare a suonare uno strumento, pare).

Quando ho creato Laravel-Italia, verso la fine del 2013, ero in un territorio inesplorato ai più. L’obiettivo? Esplorarlo. Giocare per amore del gioco (cit.). Ad intuito sentivo che c’era del potenziale, e quel potenziale l’avevo scoperto proprio facendo fare a Laravel ciò in cui eccelle: darmi una mano a consegnare i miei progetti ai miei clienti più velocemente, senza però scrivere codice di pessima qualità.

Un esperimento nato quasi per gioco: chiesi a Dayle Rees di poter tradurre alcuni articoli dal suo blog. Dagli articoli si è passati ai libri e… alla fine ne ho tradotti sei. Laravel però mi ha dato ancora di più. Mi ha permesso di farmi un’esperienza bellissima su Sitepoint, come editor. Ciliegina sulla torta, tutte queste esperienze due anni fa mi hanno permesso di scriverne uno tutto mio, di libro.

Dico questo per ostentare qualcosa? No, in realtà è per provare che dietro Laravel si è creato un interesse pazzesco. Certamente non sono il solo, ma sono sicuro che una piccola parte, con questo sito e questa community, l’ho fatta, qui in Italia. Tant’è che, qualche giorno fa, al PHPDay di Verona hanno annunciato il primo LaravelDay. A tal proposito vi terrò informati nel corso dei prossimi mesi.

So… What?

Bisogna soltanto capire, a questo punto, come evolverà la storia.

Al momento, questa nostra community conta:

• una pagina Facebook con più di 1000 seguaci;
• un forum con più di 700 utenti
• uno Slack in cui più di 400 persone, giornalmente, si scambiano idee e pareri, aiutandosi.

C’è poi un sito, questo sito, con un bel po’ di articoli. Quasi 180.

Sarò sincero: non so dare una risposta alla domanda “quando tornerai a scrivere articoli per il sito?”

Semplicemente adesso non ne ho tempo. Seguo la scena Laravel, mi guardo intorno continuamente, stanno per succedere un sacco di cose (Laravel 5.5, la prossima LTS, ad esempio). Il periodo è pieno, il tempo poco. Ribadisco però quello che dico sempre: Laravel-Italia è sempre aperta a contributi esterni di qualsiasi tipo, purchè interessanti e ben scritti.

Per quanto riguarda il Forum e Slack, invece, ho le idee più chiare: mi piacerebbe andare verso il secondo, più moderno. Prima di scegliere

Discourse per il forum attuale, ne ho provati tantissimi. Discourse in un certo senso è stato un trade-off accettabile ma il concetto stesso di forum non rende più come una volta. Nonostante le statistiche di Discourse mi dicono che abbiamo un forum attivo ogni giorno, sono convinto che Slack, se ben usato e strutturato, possa dare molto di più.

Una cosa, per il futuro, è certa. Mi concentrerò molto di più sullo sviluppo di un servizio più utile, e lo farò usando Slack.

Finisco questa breve nota con un ringraziamento a tutti coloro che ogni giorno danno forza a queste pagine, a questo forum, a questi canali.

Ne vedrete (ancora) delle belle.

Grazie a tutti,

Francesco

Qualche mese fa abbiamo parlato di LaraDock, un ottimo ambiente di lavoro che invece di affidarsi a Vagrant e VM fa uso di Docker per preparare tutto il necessario ad essere operativi.

Indubbiamente un progetto interessante: ha una marea di servizi già pronti ad essere usati e configurati.

Tutti quei servizi e quei file di configurazione sterminati mi hanno fatto riflettere. Mi ritrovo spesso a dover fare delle prove, anche piuttosto basilari. Altre volte mi ritrovo a voler configurare da zero un ambiente di lavoro per un progetto: non voglio mettermi a dover rimuovere tutto quello di cui non ho bisogno. Volendo usare LaraDock, la lista di servizi da rimuovere sarebbe infatti notevole.

Ho così iniziato a lavorare ad un ambiente “minimalista” per Laravel, basato su Docker, e sono arrivato a…

DoMinEnv!

Il risultato di questi miei esperimenti è DoMinEnv, un’abbreviazione di “Docker Minimal Environments”. La filosofia di fondo è semplice e si riassume in due semplici concetti:

• nessun servizio superfluo, solo il minimo indispensabile per essere up and running in poco tempo;
• voglio fare in modo che sia tutto pronto con un solo comando;

Se si vuole provarlo, è possibile prendere DoMinEnv da qui. Di default, include e configura autonomamente:

• PHP7.1;
• MySQL;
• Nginx;
• Composer;

Installazione

DoMinEnv è stato creato in modo tale da avere soltanto due prerequisiti:

• Git;
• Docker + Docker Compose;

… e nulla di più!

Una volta clonato il repository non bisogna fare altro che avviare lo script ./init, il quale si occupa di inizializzare tutto l’ambiente di lavoro. Se è la prima volta che stiamo avviando DoMinEnv, tocca pazientare qualche minuto: lo script di setup infatti capisce se è già stato creato un progetto Laravel, e se non trovato ne crea uno.

Inoltre, se è la prima volta che avviamo l’ambiente di lavoro, Docker si prende del tempo in più per scaricare le varie immagini (PHP, MySQL…) di cui ha bisogno. Questa procedura comunque avviene soltanto la prima volta. Già dal secondo uso, l’avvio richiede appena qualche secondo!

Uso

Una volta completata la fase di inizializzazione,

Andando in giro su GitHub, alla scoperta di package e progetti, avremo sicuramente visto dei badge come questi:

Si tratta fondamentalmente di piccoli widget che vanno ad integrarsi con servizi esterni, che offrono le funzioni più disparate. Uno di questi servizi è Travis CI, che offre (gratuitamente per progetti open source) un’infrastruttura già pronta per testare il nostro codice.

Come fa? Semplice: lavorando con un apposito file di configurazione, TravisCI automaticamente:

• scarica il codice del repository;
• effettua le operazioni di installazione (dipendenze, configurazioni);
• lancia il tool dedicato al testing che preferiamo (PHPUnit, nel nostro caso);
• se è andato tutto bene avremo davanti agli occhi un’accogliente schermata come quella nello screenshot di seguito;
• in caso di errori verremo notificati via mail;

Una volta registrati TravisCI permette di “aggiungere” il repository di un nostro progetto.

Un’altra cosa più interessante di TravisCI consiste nella possibilità di configurare GitHub in modo tale da impedire il merge di un branch in caso di test non passati. Un ulteriore occhio a conferma della qualità del codice dei nostri progetti, e meno lavoro noioso per noi developer.

Arriviamo quindi a noi: cosa succederà in questo articolo?

• scopriremo come usare TravisCI per un progetto Laravel, seguendo passo passo la procedura di preparazione di un file di configurazione;
• faremo esempi per due tipi di test. Unit test ed integration test nello specifico;
• vedremo infine come GitHub si integra automaticamente con TravisCI, in modo tale da segnalare una PR i cui test non passano oppure mostrarci un bel pulsantone verde nel caso sia andato tutto bene, aggiungendo quindi una buona pratica al nostro flusso di lavoro;

Il codice che scriverò in questo progetto sarà disponibile anche su GitHub, in questo repository.

Pronti? Si comincia!

Primo Impatto con TravisCI

Prima di entrare nel vivo dell’articolo, cerchiamo di capire bene come effettivamente TravisCI funziona.

Come già detto, è possibile aggiungere un proprio repository a Travis effettuando l’accesso da qui con il proprio account GitHub. Aggiungere un repository significa fare in modo che Travis, ad ogni push:

• si scarichi l’ultima versione della codebase;
• effettui una serie di operazioni preliminari (installazione delle dipendenze, preparazione dei file e così via);
• avvii i test usando un qualsiasi tool/framework a nostro piacimento;

Queste cose non avvengono in automatico: dobbiamo dire noi a Travis cosa deve fare, e come.

Dovremo aggiungere, al nostro progetto, un file .travis.yml, che conterrà queste istruzioni in formato Yaml.

Ecco un esempio di .travis.ci specifico per Laravel che ho trovato con una semplice ricerca. Non è detto sia quello che useremo per il nostro progetto: diamoci soltanto uno sguardo per farci un’idea.

language: php

php:
- 5.6

before_script:
- cp .env.travis .env
- mysql -e 'create database homestead_test;'
- composer self-update
- composer install --no-interaction

script:
- vendor/bin/phpunit

Proviamo a capire cosa signfiica:

• all’inizio diamo a TravisCI un paio di informazioni di base. Il progetto è di tipo PHP, la versione (di PHP) che ci interessa per fare i test è la 5.6;
• nella sezione before_script stiamo specificando alcuni comandi che dovranno essere eseguiti prima di avviare i test. In questo caso copiamo il file .env, creiamo un database, installiamo le dipendenze;
• in script avviamo effettivamente i test, usando phpunit;

Niente di troppo complesso comunque: la guida di TravisCI per un progetto PHP spiega abbastanza bene tutte le basi di cui avremo bisogno.

Adesso sporchiamoci un po’ le mani!

Iniziamo dalle Basi: Unit Test!

Ok, si parte dal primo livello. In questa sezione creeremo un semplice unit test, lo manderemo su e ci assicureremo che passi, configurando TravisCI per questa prima operazione di base.

Chiaramente, assicuriamoci di aver aggiunto il nostro nuovo progetto su GitHub tra quelli tenuti sotto controllo da TravisCI, altrimenti sarà tutto tempo perso!

Avremo bisogno di un progetto Laravel su cui fare esperimenti: assicuriamoci di aver preparato tutto. Se stiamo usando Linux o MacOS, possiamo usare Vagrant velocemente tramite LaraPrep.

Nella cartella tests/Unit togliamo di mezzo i test già esistenti e creiamone uno nostro. Lo chiameremo CalculationsTests.php.

<!--?php

namespace TestsUnit;

use TestsTestCase;
use IlluminateFoundationTestingDatabaseMigrations;
use IlluminateFoundationTestingDatabaseTransactions;

class CalculationsTest extends TestCase
{
    /**
     * Un semplice test di base.
     *
     * @return void
     */
    public function testAdd()
    {
        $this--->assertEquals(
4,
2 + 2
);
}

/**
* Un altro semplice test di base.
*
* @return void
*/
public function testMultiply()
{
$this->assertEquals(
9,
3 * 3
);
}
}

Possiamo quindi procedere con il creare il file .travis.yml di cui avremo bisogno per spiegare a TravisCI come comportarsi.

Torniamo nella root directory del nostro progetto e creiamo .travis.yml con un primo setup di base.

language: php

php:
- 5.6

before_script:
- cp .env.travis .env
- composer self-update
- composer install --no-interaction

script:
- vendor/bin/phpunit

Come la prima linea di before_script suggerisce, una buona pratica è quella di creare un apposito file .env dedicato a Travis, che dovremo copiare prima di eseguire i test. In questo modo sarà più semplice avere delle variabili d’ambiente specifiche per l’ambiente di testing.

Per ora basta copiare il file .env.example che già abbiamo a disposizione di default in un nuovo progetto Laravel.

Ci siamo! Se i file sono tutti possiamo procedere con il push e attendere l’esecuzione dei test su TravisCI.

E infatti…

I test sono stati eseguiti e passano!

Level Up: Integration Test!

Le cose iniziano a farsi divertenti: abbiamo visto come impostare il nostro progetto per poter lavorare con i test unitari… ma come configuriamo TravisCI per gli integration test?

La prima cosa di cui abbiamo bisogno è… un integration test! Creiamone uno al volo usando il model User, già presente in Laravel di default.

Il file sarà tests/Integration/UserTest.php.

<!--?php

namespace TestsIntegration;

use AppUser;
use TestsTestCase;
use IlluminateFoundationTestingDatabaseMigrations;

class UserTest extends TestCase
{
    use DatabaseMigrations;

    public function testItShouldCreateUser()
    {
        $user = User::create([
          'name' =--> 'Francesco',
'email' => 'hey@hellofrancesco.com',
'password' => 'such-security'
]);

$this->assertDatabaseHas('users', [
'name' => 'Francesco',
'email' => 'hey@hellofrancesco.com'
]);
}
}

Definiamo anche una suite integration, visto che non è presente nel file phpunit.xml.

<testsuites>
<testsuite name=""unit"">
<directory suffix=""Test.php"">./tests/Unit</directory>
</testsuite>
<testsuite name=""integration"">
<directory suffix=""Test.php"">./tests/Integration</directory>
</testsuite>
</testsuites>

Non credo che il codice appena visto abbia bisogno di spiegazioni. Vediamo però, adesso, cosa c’è da aggiungere al file .travis.yml.

language: php

php:
- 5.6

services:
- mysql

before_script:
- mysql -e 'CREATE DATABASE travis_test;'
- cp .env.travis .env
- composer self-update
- composer install --no-interaction
- php artisan key:generate
- php artisan migrate

script:
- vendor/bin/phpunit

Abbiamo aggiunto l’item services, specificando che avremo bisogno di MySQL. TravisCI metterà su automaticamente un database per i nostri test. Dopodichè abbiamo aggiunto alcuni elementi a before_script, chiedendo a MySQL di creare un nuovo database il cui nome è travis_test. Infine, tramite php artisan migrate prepariamo tutto il necessario.

Manca ancora qualcosa però… dobbiamo inserire le credenziali giuste nel file .env.travis per connetterci al database che avremo sulla macchina di test! Aggiungiamole subito…

...
DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=travis_test
DB_USERNAME=root
DB_PASSWORD=
...

Di default, sulla macchina di test di Travis usiamo root come user ed il campo password vuoto. Non sono cose inventate ovviamente: basta dare uno sguardo alla documentazione di TravisCI per farsi un’idea di quello di cui possiamo aver bisogno.

Ci siamo: commit, push e mandiamo su il test. Dovrebbe essere tutto ok: adesso Travis riesce a gestire tranquillamente anche i test che richiedono un database.

Integrazione con GitHub

Come già detto in precedenza, è possibile integrare TravisCI con GitHub per bloccare eventuali PR i cui test sono falliti, evitando merge pericolosi.

Di default, questa integrazione è già parzialmente attiva: il servizio infatti verrà richiamato ad ogni nuova push su un qualsiasi branch che fa parte di una PR. Ecco cosa ho visto su una PR di esempio aperta al volo che è possibile vedere qui.

Tuttavia, è possibile aumentare il controllo sui singoli branch e addirittura impedire del tutto il merge nel caso in cui i test siano falliti.

Tutto quello che bisogna fare è andare in “Settings” del nostro repository, cliccare quindi su “Branches” e scegliere il branch che vogliamo “proteggere”. Ci ritroveremo davanti una schermata come questa:

Basterà selezionare continuous-integration/travis-ci tra i servizi legati alla regola “require status checks to pass before merging” e cliccare su “Save Changes”.

Adesso, infatti, la nostra PR apparirà così…

Conclusioni

In questo semplice articolo mi sono limitato a dare quella che può essere definita “un’infarinatura di base” su TravisCI e la sua configurazione per un progetto Laravel. In verità c’è tanto da vedere: bisognerebbe scriverci un libro, più che un articolo, per poter coprire tutto.

Come punto di partenza, però, dovrebbe essere perfetto per farsi un’idea di come configurare correttamente un progetto per la prima volta. Soprattutto, perfetto per iniziare ad intuire i benefici che può portare al proprio flusso di lavoro.

E voi? Usate TravisCI nei vostri progetti? C’è qualche consiglio in particolare che volete condividere? Fatelo nei commenti qui di seguito, oppure venite a parlarne nel canale Slack di Laravel-Italia.

Se non abbiamo passato gli ultimi due anni in una grotta, sicuramente ci siamo imbattuti in una parola: Bot.

Wikipedia dice: Il bot (abbreviazione di robot) in terminologia informatica in generale è un programma che accede alla rete attraverso lo stesso tipo di canali utilizzati dagli utenti umani (per esempio che accede alle pagine Web, invia messaggi in una chat, si muove nei videogiochi, e così via). Programmi di questo tipo sono diffusi in relazione a molti diversi servizi in rete, con scopi vari ma in genere legati all’automazione di compiti che sarebbero troppo gravosi o complessi per gli utenti umani.

C’è da dire che il bot non è un concetto nuovo. Nell’ultimo periodo però, con l’affermarsi del machine learning e grazie a realtà come Facebook e Telegram, una nuova generazione di bot sta prendendo piede. Si tratta fondamentalmente di bot con cui possiamo chattare, e sulla base di questo input ottenere un output specifico.

Gli usi sono molteplici: basti pensare a Bot che si possono integrare con servizi web specifici, o magari con altri servizi nel mondo IoT, e così via. Gli usi sono praticamente illimitati. Non a caso, è possibile trovare bot di ogni tipo.

Come è facile immaginare, di conseguenza, non mancano all’appello SDK e strumenti di ogni genere per svilupparne a volontà. Un ottimo punto di partenza, per chi volesse iniziare a farsi una cultura in materia, è Chat Bots Magazine.

Quando ho iniziato a muovere i primi passi in questo ambito, chiaramente, mi sono chiesto: quanto è difficile creare un bot?

La risposta è ovviamente “dipende”, ma se si vuole iniziare ci sono strumenti per qualsiasi linguaggio, framework e tecnologia.

Laravel e PHP, ovviamente, non fanno eccezione!

Un paio di cose importanti prima di proseguire:

• questo articolo è stato realizzato partendo da un’installazione di Laravel 5.4;
• se hai domande o perplessità, lascia un commento in fondo. Inoltre, se non l’hai già fatto, sbrigati a raggiungerci sul canale Slack di Laravel-Italia! Ah, e abbiamo anche un bel forum a cui iscriverti;

Quale Bot?

Prima di mettere le mani sul codice però, fermiamoci un secondo. Non ancora abbiamo scelto cosa vogliamo realizzare!

Nessuna idea? No problem, ne ho una io!

Da qualche tempo sto seguendo con interesse il mondo delle cryptocurrency. Soprattutto Bitcoin ed Ethereum, che allo stato attuale sono quelle più “quotate”. Perchè non costruire un semplice bot al quale poter scrivere per chiedere il prezzo di un certo token (Bitcoin o Ethereum) in quel momento?

Niente di particolarmente complesso a livello di interazione.

Il nostro bot si comporterà così:

• se il messaggio inviato al bot è /quote eth, l’utente riceverà un messaggio con il prezzo di Ethereum (in €) in quel momento;
• se il messaggio inviato al bot è /quote btc, l’utente riceverà un messaggio con il prezzo di Bitcoin (in €) in quel momento;
• qualsiasi altro messaggio inviato al bot che non sia uno dei due appena visti permetterà all’utente di ricevere un messaggio di “aiuto” per capire cosa fare;

Come caso base è più che sufficiente per iniziare a progettare qualcosa. Chiaramente servirà una fonte dalla quale attingere il prezzo di volta in volta: userò le ottime API di Coinbase, uno degli exchange più famosi.

Per i non addetti ai lavori, un exchange è una piattaforma sulla quale poter comprare e vendere delle cryptocurrency. Per ciò di cui abbiamo bisogno non avremo la necessità di implementare nessun tipo di autorizzazione per le API, il che significa che potremo concentrarci al meglio sul codice e sul bot.

Pronti?

Ah, prima che mi dimentichi: tutto il codice è disponibile in questo repository.

Registrare il Bot

Per poter creare un Bot Telegram c’è bisogno innanzitutto di registrarlo… usando un altro bot!

Basta, infatti, contattare su Telegram il buon BotFather. Non si deve fare altro che scrivergli qualcosa, anche solo “ciao” ed inviare il messaggio per ricevere un messaggio con tutti i comandi da usare per poterlo usare.

Quello che a noi interessa è /newbot, che ci consentirà di registrare un nuovo bot nel database di Telegram.

Bisognerà specificare un nome e scegliere un “nickname” che verrà poi usato per identificare univocamente il bot. Una volta terminata la procedura, BotFather ci manderà un token, molto importante perchè sarà la chiave per le API di cui avremo bisogno per leggere i messaggi in arrivo del bot, rispondere agli utenti e così via.

Una volta completata la registrazione, inoltre, potremo usare BotFather per personalizzare ulteriormente il nostro bot: dalla modifica della descrizione all’immagine del profilo, e così via.

Implementare il Bot

Arriviamo finalmente al punto. Come si fa a creare un bot Telegram con Laravel?

Facendo una semplice ricerca vengono fuori vari package e guide. Noi, oggi, ci concentreremo sul package più famoso, Telegram Bot SDK di Irazasyed.

In questo articolo scopriremo come usarlo per raggiungere il nostro obiettivo.

Ambiente di Lavoro

Da qualche parte bisogna iniziare: direi dall’ambiente di lavoro! Creiamo un nuovo progetto Laravel usando il sistema che preferiamo. Per questo tutorial ho usato uno script che mi sono scritto, compatibile sia con Linux che con MacOS: LaraPrep!

Una volta creato l’ambiente, possiamo passare a…

Installare il Package

Per installare il package basta un

$ composer require irazasyed/telegram-bot-sdk

ed un po’ di configurazione. In primis l’aggiunta del service provider in config/app.php

TelegramBotLaravelTelegramServiceProvider::class,

ed eventualmente la Facade. Non è obbligatoria comunque.

'Telegram'  => TelegramBotLaravelFacadesTelegram::class,

Dopodichè c’è da pubblicare i vari file del package con un

$ php artisan vendor:publish --provider="TelegramBotLaravelTelegramServiceProvider"

Volendo basta anche un semplice

$ php artisan vendor:publish

visto che l’aggiunta del flag --provider serve a scegliere per quali vendor copiare i file.

Non rimane che l’ultimo step: aggiungere il token del nostro Bot al file di configurazione config/telegram.php. Lo abbiamo ottenuto prima, durante la registrazione.

...
'bot_token' => '1234:ABCD',
...

Codice #1 – Il Primo Comando Telegram

Abbiamo configurato tutto: siamo pronti ad iniziare. La prima cosa che faremo sarà creare il comando di default, quello che verrà mostrato quando l’utente scriverà al bot /help, o /start.

Uno degli aspetti più interessanti del package che abbiamo appena installato è il sistema di “comandi” Telegram. In poche parole, è possibile definire dei comandi Telegram per il nostro bot come delle classi simili ai comandi Artisan che noi conosciamo già.

Una volta creato questo comando tutto quello che bisogna fare è registrarlo nel file config/telegram.php, nell’array commands.

Eccolo qui, il nostro HelpCommand, nella cartella app/TelegramCommands.

<!--?php

namespace TelegramBotTelegramCommands;

use TelegramBotCommandsCommand;

class HelpCommand extends Command
{
    /**
     * @var string Command Name
     */
    protected $name = "help";

    /**
     * @var string Command Description
     */
    protected $description = "Comando di benvenuto, eseguito di default";

    /**
     * @inheritdoc
     */
    public function handle($arguments)
    {
        $this--->replyWithMessage(['text' => 'Ciao! Sono TokenBot! Scrivi "/quote btc" per conoscere il prezzo di un Bitcoin, oppure "/quote eth" per conoscere il prezzo di un Ethereum.']);
}
}

Si, tutto qui. Cerchiamo però di capire cosa succede:

• la classe estende TelegramBotCommandsCommand, base di partenza per creare altri command per Telegram. Ha a corredo una serie di metodi utilissimi per poter interagire con gli utenti;
• l’attributo $name definisce il comando. Di conseguenza, help equivarrà al comando /help inviabile da un utente. Un po’ come accade già per le route, insomma;
• perchè proprio help? Perchè è quello “di default” per Telegram in caso di invio di un comando, da parte dell’utente, non riconosciuto;
• il metodo replyWithMessage appartiene alla classe base e consente di inviare all’utente che ha inviato il comando un semplice messaggio testuale come risposta;

Codice #2 – Il Comando Artisan “process”

Il primo comando Telegram c’è: tocca provarlo! Per farlo, ci “aiuteremo” con un semplice comando Artisan. Creiamolo al volo eseguendo

$ php artisan make:command ProcessCommand

che si occuperà di creare, appunto, un nuovo comando Artisan chiamato “ProcessCommand”. Quello che dovrà fare sarà “gestire” le richieste in arrivo dagli utenti su Telegram. Per fortuna, il nostro package ha un metodo della facade Telegramche fa tutto in modo praticamente automatico: commandsHandler.

Il nostro comando Artisan apparirà così:

<!--?php

namespace TelegramBotConsoleCommands;

use IlluminateConsoleCommand;

class ProcessCommand extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'bot:process';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Processa i messaggi in arrivo del bot';

    /**
     * Execute the console command.
     *
     * @return mixed
     */
    public function handle()
    {
      try {
        $result = Telegram::commandsHandler(false);
        $this--->info('Processati ' . count($result) . ' messaggi.');
} catch (Exception $e) {
$this->error('Errore: ' . $e->getMessage());
}
}
}

Vediamo cosa succede qui:

• il comando Artisan bot:process si occupa di chiamare commandsHandler, che chiama le API di Telegram per vedere se sono arrivati nuovi messaggi. Se sono arrivati, controlla se questi corrispondono a comandi definiti nell’applicazione;
• se ci sono dei comandi da eseguire, per il comando specifico viene effettuata una chiamata al metodo handle;

Come è possibile notare, in questo caso stiamo facendo del long polling: ogni volta che verrà eseguito questo comando tratteremo “in blocco” i nuovi messaggi degli utenti.

Esiste anche un’altra modalità di interazione che prevede un webhook da configurare, ma per questa guida la eviteremo. C’è da tenere a mente però che in caso di bot più “carichi” di messaggi da gestire il webhook è praticamente una scelta obbligata.

Comunque sia, manca solo il comando “/quote”, che useremo per ottenere la quotazione, in quello specifico momento, di una currency. Prima però, dobbiamo creare al volo un piccolo servizio per poterci interfacciare con Coinbase.

Codice #2 – Il Servizio Coinbase

Per creare un servizio connesso a Coinbase le possibili scelte sono due:

• trovare un package che mi permetta di interagire con Coinbase;
• scrivere al volo ciò che mi serve implementando chiamate HTTP con un client;

La soluzione migliore? Nel nostro caso la seconda: non dobbiamo fare nulla di complesso, a pensarci bene. Scaricare e configurare un package solo per recuperare un numero è sicuramente un overhead.

Questo numero sarà lo “spot price”, un prezzo indicativo che le API ci mettono a disposizione (qui la documentazione, sotto “get spot price”).

Avremo comunque bisogno di un client HTTP per poter lavorare: ho scelto Guzzle, installandolo con un semplice

$ composer  require guzzlehttp/guzzle

Una volta installato il package, possiamo procedere. Creiamo una nuova cartella in app, chiamata Services, ed al suo interno una nuova classe, Coinbase, in un file Coinbase.php.

<!--?php

namespace TelegramBotServices;

use GuzzleHttpClient;

class Coinbase
{
    const COINBASE_API_URL = 'https://api.coinbase.com/v2/';

    /** @var Client **/
    private $client;

    public function __construct(Client $client)
    {
        $this--->client = $client;
}

public function getPriceFor($currencyCode)
{
if(!in_array($currencyCode, ['BTC', 'ETH'])) {
throw new Exception('Currency code must be BTC or ETH');
}

$response  = $this->client->get(self::COINBASE_API_URL . 'prices/' . $currencyCode . '-EUR/spot');
$decodedResponse = json_decode($response->getBody()->getContents(), true);

return $decodedResponse['data']['amount'];
}
}

Capiamo, riga dopo riga, cosa succede qui:

• la prima costante dichiarata nella classe serve a tenere “separato” dal resto del codice l’url base che useremo per le nostre chiamate alle API;
• nel costruttore della classe iniettiamo il client HTTP che useremo, Guzzle. Ci permetterà di effettuare le chiamate alle API di Coinbase con una sintassi semplicissima e semplice da comprendere;
• nel metodo getPriceFor controlliamo innanzitutto se il valore di $currencyCode è “ETH” o “BTC” (gli unici due consentiti). Altri valori non sono consentiti, e verrà lanciata un’eccezione in tal caso. Se il controllo invece non rileva problemi effettuiamo la chiamata a Coinbase, verso l’endpoint formato dalla stringa “/prices”, una combinazione di currency (in questo caso, quella da noi scelta e l’euro, per ottenere il prezzo in euro), ed il segmento finale /spot;
• il metodo getPriceFor prende l’amount di cui abbiamo bisogno nell’array risultante (dopo aver fatto passare il JSON arrivato dalle API attraverso un json_decode);

Il valore ritornato, a questo punto, è esattamente quello di cui abbiamo bisogno.

Nota: essendo un tutorial a scopi puramente illustrativi, non ho implementato dei test optando invece per una gestione molto “semplificata” della cosa. In un’applicazione da mondo reale, per carità, scrivete i maledettissimi test.

Detto questo, non rimane altro che finire l’opera! Costruiamo il secondo comando Telegram, “/quote”!

Codice #3 – Il Comando Telegram “/quote”

Prima di metterci a costruire l’ultimo comando, c’è una piccola accortezza da prendere. Supponiamo di voler usare il nostro servizio appena creato. La sua costruzione è piuttosto semplice:

// il client guzzle di cui avremo bisogno
$client = new Client();

// il nostro servizio
$coinbase = new Coinbase($client);

Dopo questa costruzione possiamo usare il servizio come meglio crediamo. Tuttavia, possiamo fare di meglio!

Aggiungiamo, nel metodo boot del nostro TelegramBotProvidersAppServiceProvider:

// dopo il namespace, all'inizio del file...
use GuzzleHttpClient;
use TelegramBotServicesCoinbase;

// nel metodo boot()
$this->app->bind(Coinbase::class, function(){
return new Coinbase(new Client());
});

Cosa è successo? Semplice: stiamo istruendo il nostro service container riguardo come va creata un’istanza del nostro servizio Coinbase.

Ecco quindi che arriviamo al nostro comando Telegram: creiamolo, in app/TelegramCommands/QuoteCommand.php.

<!--?php

namespace TelegramBotTelegramCommands;

use TelegramBotCommandsCommand;
use TelegramBotServicesCoinbase;

class QuoteCommand extends Command
{
    /**
     * @var string Command Name
     */
    protected $name = "quote";

    /**
     * @var string Command Description
     */
    protected $description = "Restituisce la quotazione attuale di una currency";

    /**
     * @inheritdoc
     */
    public function handle($arguments)
    {
      /** @var Coinbase **/
      $coinbase = app(Coinbase::class);
      $currencyCode = trim(strtoupper($arguments));

      switch ($currencyCode) {
        case 'ETH':
        case 'BTC':
          $quote = $coinbase--->getPriceFor($currencyCode);
$this->replyWithMessage(['text' => 'Quotazione ' . $currencyCode . ': €' . $quote]);
break;

default:
$this->replyWithMessage(['text' => 'Mmmh... non conosco questa currency! Specifica "eth" o "btc" dopo il /quote.']);
break;
}
}
}

La logica è piuttosto semplice:

• creiamo l’istanza del servizio Coinbase, usando il service container. Il service container di Laravel me lo restituirà esattamente come ci serve, perchè abbiamo definito un binding nel provider AppServiceProvider;
• facciamo un po’ di pulizia del dato in input, e se il valore è ETH o BTC viene effettuata una chiamata al servizio di Coinbase. In caso contrario, invece, viene inviato all’utente un messaggio di fallback, in modo tale da guidarlo verso l’uso migliore;

Non scordiamoci di registrarlo nel file config/telegram.php, nell’array commands.

Direi che ci siamo, ed il nostro bot è pronto!

… e ora?

Il bot è pronto a essere usato… e ora che succede?

Beh, volendo ci sono un sacco di idee interessanti da implementare: le lascio qui come “ispirazione”.

Esercizio 1 – Questione di Risparmio

Quando si usa un’API è bene ottimizzare il numero di chiamate da fare. Sia per questioni di performance della propria applicazione, ma anche perchè alcuni servizi (giustamente) pongono un limite al numero di chiamate che si possono fare in un certo lasso di tempo.

Ecco un’ottima idea per un primo esercizio: un sistema che mette in cache il valore ottenuto dal servizio Coinbase per un certo tempo.

Suggerimenti:

• usa il sistema di Cache di Laravel!

Esercizio 2 – Avvisami!

Un bot che controlla l’andamento di una cryptocurrency è comodo. Dopo un po’ però è noioso scrivergli, magari più volte! Perchè non implementare un bel sistema di avvisi? Qualcosa come

• se il valore della cryptocurrency X scende oltre Y, avvisami;
• se il valore della cryptocurrency X sale oltre Y, avvisami;

Suggerimenti:

• sarà necessario “registrare” gli utenti, in modo tale da avere a disposizione il loro ID univoco Telegram in futuro;
• sarà necessario anche gestire gli avvisi (dove memorizzarli? quando eliminarli? ogni quanto fare i controlli? e così via…);

Buon lavoro 😉

Ehilà! Come procede l’inizio della settimana? Spero bene.

Quelli che ci seguono da un po’ lo sanno, mi piace cambiare le carte in tavola di tanto in tanto, per proporre cose nuove, nuovi contenuti e nuovi tipi di articoli.

Per trenta settimane, la rubrica dedicata ai package della settimana ha visto più di cento package recensiti. La cosa ha interessato non poche persone, vista la crescita nell’ultimo periodo. Sono convinto, però, che si può fare ancora di più.

E, volendo, si possono cambiare un po’ di cose. Negli ultimi sette giorni ci ho pensato bene, ed ecco a che conclusioni sono giunto:

• la rubrica dei package della settimana non mi stimola più come prima;
• sarebbe interessante fare qualcosa di più approfondito, che dia ancora più valore al lettore;

Per questo motivo, da oggi la rubrica dei “Package della Settimana” si ferma. Al suo posto, cercherò di scrivere articoli più “completi” e più interessanti. Scriverò quando avrò tempo: allo stato attuale sono praticamente solo, e fidatevi, è sempre un casino riuscire a fare tutto. Ah, chiaramente c’è sempre spazio per chi vuole contribuire. Non serve essere dei provetti Umberto Eco, basta un po’ di volontà! Forza!

Il prossimo, ad esempio, riguarderà la Creazione di un Bot Telegram con Laravel. Spiegherò un po’ tutto il procedimento, dalla creazione del progetto base a quali package installare, e così via.

Le novità però non finiscono qui: mi piacerebbe sapere di cosa avete bisogno. Per questo motivo, ho creato una nuova sezione sul Forum dedicata alle richieste di nuovi articoli. C’è qualcosa in particolare che vorresti sapere, ma non sai come fare? Valuterò proposta per proposta e, se abbastanza interessante, ci farò un articolo sopra.

Insomma… si ricomincia!

La rubrica I Package della Settimana si propone, ogni Lunedì mattina, di suggerire cinque package per Laravel descrivendoli brevemente. L’obiettivo? Riuscire a dare nuovi spunti ai lettori, far conoscere nuovi tool ed ottimizzare il flusso di lavoro. Durante la pausa caffè.

Vediamo cosa c’è questa settimana!

I Package della Settimana

• Eloquence: questo package raccoglie una serie di “estensioni” per Eloquent, con l’obiettivo di semplificarci la vita di tutti i giorni. Si tratta fondamentalmente di una serie di trait che aggiungono determinate funzionalità, dalla ricerca fulltext alla gestione di metadati, passando per il mapping e model auto-validanti;
• Rememberable: Rememberable permette, tramite un comodo trait, di aggiungere un layer di cache alle nostre query, in maniera tale da poter “tenere da parte” i risultati di alcune nostre query più comune in modo abbastanza comodo. Se ce lo stiamo chiedendo, si: praticamente reintroduce una funzionalità che non si vedeva da Laravel 4.2;
• ApiGuard: abbiamo costruito delle API e vogliamo proteggerle attraverso un sistema di autenticazione basato su API Key e Secret. Come poter risolvere? Semplicemente con ApiGuard, che offre un’implementazione già pronta di questo layer di protezione. Fa uso inoltre di Fractal di philsturgeon e di api-response di maximebeaudoin;
• Laravel GitScrum: GitScrum è un interessantissimo progetto completo, realizzato con Laravel, che consente di gestire il lavoro del proprio team facendo uso di Git e Scrum, giorno dopo giorno. Oltre ad essere molto utile, quindi, può anche essere un ottimo modo di studiare l’organizzazione di un progetto;
• Socialite Coinbase Provider: le vie di Socialite sono infinite. Davvero: con questo package è infatti possibile aggiungere a Socialite il provider per Coinbase, ed iniziare a sviluppare applicazioni che consentono di usarne l’utenza. Particolarmente interessante di questi tempi, vero?

E tu, hai qualche package da suggerire? Lasciaci le tue impressioni qui sotto, in un commento, o faccelo sapere sullo Slack di Laravel-Italia!

Ci vediamo la prossima settimana.

La rubrica I Package della Settimana si propone, ogni Lunedì mattina, di suggerire cinque package per Laravel descrivendoli brevemente. L’obiettivo? Riuscire a dare nuovi spunti ai lettori, far conoscere nuovi tool ed ottimizzare il flusso di lavoro. Durante la pausa caffè.

Vediamo cosa c’è questa settimana!

I Package della Settimana

• “Unique With” Validator: questo interessante package aggiunge al Validator di Laravel una regola “unique with” che funziona esattamente come la già presente unique, con la possibilità però di fornire una lista di campi al posto del singolo, in maniera tale da poter fare dei controlli più complessi;
• Laravel Exceptions: questo interessante lavoro di Graham Campbell consente di lavorare profondamente sulle eccezioni e sul loro rendering, in maniera tale da poter gestire al meglio ogni errore ed averne un controllo completo al 100%. Sarà possibile infatti definire dei transformer per l’output, filtri, displayer e così via;
• Agent: Agent di jessengers contiene tutto quello che serve per lavorare sul rilevamento degli user agent. Particolarmente comodo se si vuole profilare al meglio ogni richiesta in arrivo. Consente anche l’uso di una comoda Facade per velocizzare il lavoro;
• Laravel Rollbar: Rollbar è un ottimo Saas da usare per il monitoring delle proprie applicazioni. Questo package, sempre del buon jessengers, consente di avere un ponte pronto e comodamente configurabile per la nostra applicazione Laravel. Da provare!
• Former: ad alcuni non piace scrivere il codice dei form, neanche un po’… Succede! Former è un package dedicato esattamente a questo, con la possibilità però di gestire tutto tramite codice PHP. Il package in questione è automaticamente integrato con Laravel, ma è compatibile con qualsiasi framework in circolazione (oltre ad essere usabile anche con PHP puro e semplice);

E tu, hai qualche package da suggerire? Lasciaci le tue impressioni qui sotto, in un commento, o faccelo sapere sullo Slack di Laravel-Italia!

Ci vediamo la prossima settimana.