Home Blog Page 4

Functional Developer Italiani – Un Nuovo Gruppo Facebook

0

Alcuni di voi sapranno che, da qualche tempo, sono uno degli amministratori di Web Developer Italiani, uno (se non il) gruppo più forte in Italia per tutto quello che riguarda (you don’t say) lo sviluppo web, che conta undicimila sviluppatori iscritti.

Qualche giorno fa ho fondato il “fratellino minore”, in un certo senso, del gruppo: Functional Developer Italiani!


>> Functional Developer Italiani <<

Il gruppo è pubblico e aperto! Ti aspettiamo!


Sarà dedicato TOTALMENTE allo sviluppo con linguaggi funzionali.

Il lancio è stato spaziale, abbiamo raggiunto velocemente più di 100 iscritti!

L’obiettivo è semplice:

  • creare un centro di discussione attivo sull’argomento, tirando in ballo un po’ tutti i linguaggi che abbracciano questo paradigma. Niente fondamentalismi, niente estremismi di sorta;
  • “accogliere” anche chi è totalmente a secco sull’argomento, attraverso la diffusione di risorse entry-level più adatte a chi il paradigma non lo mastica per niente;

Ti aspettiamo su Functional Developer Italiani! 🙂

Come Configurare un Primo Progetto Elixir (ed effettivamente è semplicissimo)

1

Qualche giorno fa ho scritto un post per spiegare, in più o meno poche righe, cosa diamine è l’actor model. Come già scritto proprio in quelle righe, negli ultimi tempi mi sto (ri)avvicinando ad Elixir. Stavolta, però, ho deciso di trovare quello che poteva essere un buon modo di imparare ad usarlo (senza dover partire dalle basi più banali) e nel contempo tenere un “diario” dell’avventura.

Ho una mia teoria sui “diari” nello sviluppo. Se ben tenuti, è molto più semplice scrivere materiale che sarà, a sua volta, molto più semplice da consultare per il lettore. Del perché, tuttavia, parleremo un’altra volta, oggi non siamo qui per questo.

Va bene, quindi cosa succede oggi?

Ecco cosa faremo:

  • innanzitutto, installeremo Elixir e tutto quello che serve per iniziare a lavorarci;
  • una volta installato tutto scopriremo Mix, uno dei tool più importanti di Elixir;
  • scopriremo un po’ di comandi aggiuntivi interessanti;
  • vedremo come mettere su un ambiente di lavoro decente in cui scrivere il nostro codice;

Cosa diamine è l’Actor Model, spiegato in poche righe

2

Prefazione (salta pure se vuoi, non è essenziale)

L’idea di questo post/traduzione mi è venuta leggendo un articolo di Brian Storti.

Di tanto in tanto cerco di (ri)avvicinarmi ad Elixir, per poterci mettere le mani in maniera sensata e tirare fuori un po’ di codice con cui divertirmi. Chi mi conosce bene tra l’altro sa che ho sempre avuto il pallino per le spiegazioni semplici. Sono convinto che l’apprendimento non debba essere una cosa noiosa, per quanto possibile, e che la capacità di sintesi è una cosa importante. Stasera, troppo stanco per scrivere del codice, mi sono detto: “ok, magari trovo qualche articolo interessante in giro“.

Mi sono messo così a pensare ai vari talk che ho sentito in giro ultimamente, alle discussioni che leggo sui vari forum/slack/chat e così via. Si parla spesso di Actor Model. Un concetto spesso descritto come “semplicissimo” (e lo è) ma raramente spiegato davvero. Non so dire con precisione perché, anche se una mezza idea ce l’ho: tendiamo a dare un sacco di cose per scontate, quando cerchiamo di spiegarne altre.

Ad ogni modo, del mio metodo di lavoro/studio/scrittura parlerò in un altro post. Torniamo all’articolo dell’ottimo Brian.

Ho trovato la domanda a cui rispondere: che cosa diamine è l’actor model? Il post che ho trovato è secondo su Google. La parte divertente arriva adesso però: cercando pagine in Italiano per “actor model”… non trovo nulla! Anzi, ad essere onesti ho trovato:

  • un link ad un libro su Amazon (in inglese);
  • un altro link ad un libro su Amazon (in inglese);
  • un link ad un account instagram (non riguarda l’actor model, ovviamente, ma un tizio che fa l’attore ed il modello);

Insomma…

Cos’è l’Actor Model (ecco, leggi qui)

Partiamo da un principio semplicissimo. Fino a qualche anno fa le nostre CPU raddoppiavano di potenza senza problemi a ritmo quasi regolare. Adesso le cose sono cambiate e il miglioramento non segue lo stesso trend. Succede una cosa diversa: aumentano il numero dei core. Di conseguenza, per trarre il maggior vantaggio dai nostri software dobbiamo riuscire a scrivere del codice che può essere eseguito su più core. Concurrency, la chiamano.

Il mio nuovo package per Laravel 5.6: Circuit Breaker!

0

Di tanto in tanto mi capita di buttare giù due righe in PHP e scrivere dei package “ispirati” a qualcosa che ho visto a lavoro, o di cui magari ho avuto necessità nella stesura di questo o quel side-project. Qualche giorno fa, a lavoro, mi sono ritrovato a parlare con un collega del Circuit Breaker pattern, di cui si può trovare un’ottima spiegazione qui.

Circuit What?

Niente di complesso, ad essere onesti. Fondamentalmente si tratta di un pattern grazie al quale è possibile, in parole poverissime, “wrappare” una funzione/oggetto in modo tale da poterne monitorare lo “stato di servizio”. Per capirci meglio facciamo un esempio:

  • immaginiamo di avere un’integrazione con un gateway di pagamenti per il nostro store/applicazione;
  • in caso di malfunzionamenti abbiamo un meccanismo di fallback, che ci permette di segnare gli ordini che non possono essere processati se il gateway è giù;

Implementando un circuit breaker monitoriamo l’esito delle chiamate al gateway di pagamento. Se più di X chiamate in un certo periodo T non vanno a buon fine, allora possiamo marcare per un certo lasso di tempo il nostro gateway come “failed” ed usare direttamente il meccanismo di fallback, senza dover aspettare tutte le volte il gateway che, sappiamo, ormai è andato.

Abbiate pazienza, è sabato sera e non ho una gran fantasia.

Interessante! Cosa c’entra con Laravel?

C’entra perché chiunque può sviluppare la propria “versione” di un circuit breaker. Nel mio caso, ho deciso di creare un package per Laravel (dalla 5.6 in poi) che mi permetta di realizzare velocemente una cosa del genere.

Watson Text-to-Speech vs. Google Cloud Text-to-Speech, ecco com’è andata

0

Qualche giorno fa ho pubblicato un articolo dedicato al nuovo servizio di text-to-speech basato su WaveNet offerto da Google. Com’è andata? Una bomba. Ho così deciso di far girare un po’ l’articolo, soprattutto per ricevere dei feedback e capire se c’è un servizio che se la cava meglio.

In tanti mi hanno consigliato di dare uno sguardo a IBM Watson e al mondo che ci gira intorno. Così ho scoperto che anche IBM ha la sua API di Text-to-Speech.

Perché non provarla?

“What You Give Is What You Get” – Costruire una Community – Articoli Atomici ed Interconnessi

0

Ok, vediamo di riprendere in mano questa serie di post dedicata alla costruzione di una community. Oggi continuiamo il discorso che abbiamo iniziato la scorsa volta, sui contenuti. Si è parlato di serie e di come gestirle, oggi parliamo di singoli articoli e del fatto che debbano essere il più possibile atomici ed interconnessi.

Immagine trovata su Hackernoon

Cosa significa?

Partiamo dalle due definizioni dei termini in questione.

  • Atomico: In alcune correnti filosofiche contemporanee, è usato talora con il sign. generico di elementare, non riducibile a parti più semplici.
  • Interconnessione: connessione tra due o più fatti, avvenimenti, fenomeni. Nella tecnica, connessione tra due o più sistemi, che rende possibile l’interazione.

Ho praticamente detto tutto ma vedo di spiegarmi meglio.

Ho provato Google Text-to-Speech (con PHP) ed è una vera bomba

1

Alcuni di voi sanno che circa tre mesi fa ho lanciato un piccolo esperimento / side project, cryptoaud.io. Si tratta di un semplice aggregatore di notizie del mondo cryptocurrency con l’aggiunta di un insieme di integrazioni che si occupano di creare un riassunto della notizia e “leggerla” all’utente usando la sintesi vocale di Amazon Polly.

Il mondo della sintesi vocale mi ha sempre appassionato ed è stato molto piacevole scoprire un servizio come Polly, che fa molto bene il suo lavoro nonostante ci sia ancora tanta ricerca da fare in questo campo.

Poi, nemmeno una settimana fa, durante il mio consueto giro mattutino di lettura delle notizie, un articolo su TheVerge ha catturato la mia attenzioneGoogle ha da poco rilasciato un suo servizio di cloud TTS (text-to-speech). Indoviniamo il nome? Cloud Text-to-Speech.

Such originality, tuttavia non è per il nome che ho deciso di scrivere questo articolo. L’elemento fondamentale che mi ha fatto drizzare le orecchie, infatti, è che a differenza degli altri sistemi in circolazione questo ha un motore, nel cofano, da non sottovalutare: WaveNet, prodotto creato dall’inglese DeepMind.

Dovevo provarlo

Deploy di un’Applicazione Laravel 5.6 con ECS + Fargate

0

Ultimamente mi ritrovo spesso a giocare con AWS. In primis perché sto studiando per la certificazione come Associate Developer, certo, ma anche perché sto scoprendo una marea di roba nuova che mi facilita (enormemente) la vita.

Nel frattempo, ho iniziato a lavorare ad un side-project. Non per studiare qualcosa di nuovo ma proprio per “lanciare” qualcosa di mio. Ho deciso così di scegliere una tecnologia che conosco già molto bene e ho scelto Laravel. Per quanto riguarda lo sviluppo in locale non c’è problema: Vessel di ShippingDocker ha tutto quello di cui ho bisogno (per i più pigri, sappiate che con il mio caro e vecchio Laraprep tiro su tutto il dev env in due minuti).

Rimane quindi una sola domanda: cosa scelgo per l’ambiente di produzione?

Tendenzialmente per i side-project vado di deploy su Forge. Approccio quick and dirty e ho tutto quello che mi serve in tempo zero.

Che gusto c’è, però, se non imparo nulla di nuovo?

Ne ho parlato con un mio collega, Eraclitux, che per queste cose è sempre molto sul pezzo. Anche stavolta non mi ha deluso. Gli ho detto che mi sarebbe piaciuto giocare con i container anche in produzione e non solo in locale. La sua risposta è arrivata subito:

“Prova ECS + Fargate.”

“What You Give Is What You Get” – Costruire una Community – Serie di Articoli

0

Abbiamo parlato di scopi, abbiamo parlato di semplicità. Tutto bello, bravi tutti, ma ora sporchiamoci un po’ le mani e parliamo di serie di articoli e di come (e quando) organizzarle.

Tra le varie cose a cui avevo pensato durante il lancio di Laravel-Italia ne ricordo una in particolare: “scriverò tante serie di articoli, da come si crea un blog con Laravel a cose molto più complesse e dedicate all’approfondimento”.

Un’ottima idea, certo, ma anche una pessima idea.

La prima serie che avevo scritto, “Making of Larabox“, non era andata affatto male. Anzi. Era piaciuta molto e a tanti utenti, che avevano iniziato a chiederne altre. Prendendo la richiesta alla lettera (anche con tanto ingenuo entusiasmo) mi ero messo di nuovo a scrivere e… puff: era nata anche Laravel… in Profondità”. A mio parere una delle più interessanti: una traduzione di una serie scritta da Christopher Pitt sul “viaggio” all’interno del codice di Laravel durante una richiesta all’applicazione. Un must per capire come funziona “under the hood” il framework.

Insomma, un successo? Macché. Una tragedia.

Il primo articolo, quello introduttivo, era stato letto circa 600 volte. Quello conclusivo? Appena venti.

Anche 600 non è una grande statistica, a ragionarci un attimo su: basta pensare che il capitolo introduttivo della serie Creare un Blog con Laravel 5″ conta più di 4000 visualizzazioni.

Cosa diamine è successo?

Semplicemente, ci sono serie e serie di articoli. Che ci piaccia o meno, si devono ricollegare agli scopi della community. Se stiamo portando avanti una community locale/nazionale, i contenuti dovranno essere entry-level o comunque molto pratici. Making of Larabox Creare un Blog con Laravel 5 avevano funzionato esattamente per questo motivo. Le serie più avanzate e di approfondimento sono state sicuramente un contributo lodevole, che però hanno fatto felici poche persone.

Se proprio vogliamo approfondire qualcosa, una mini-serie può essere un buon compromesso. Non risulta troppo pesante e al tempo stesso, se siamo dotati di un po’ di capacità di sintesi, possiamo comunque dare un bell’input al lettore. Un esempio che mi viene in mente, su Laravel-Italia, è quella dedicata alla scoperta dei JSON Web Token, oppure quella dedicata ai principi S.O.L.I.D.

In ogni caso, nelle mini-serie occhio alla scorrevolezza: pochi fronzoli e tanti esempi pratici sono un requisito indispensabile.

Volendo riassumere:

  • una serie di approfondimento rimane appunto d’approfondimento, per quanto interessante (e stimolante anche per il traduttore stesso)  e non tutti gli utenti possono avere il desiderio di sviscerare il tema;
  • una serie orientata all’entry level è sicuramente una scelta più azzeccata, in una community il cui scopo è facilitare l’accesso alla tecnologia in questione;

Lesson Learned: è bello fare cose stimolanti, ma c’è tempo e luogo per farle. Una serie di approfondimento e una community locale non vanno d’amore e d’accordo. Se proprio bisogna scriverla, una serie… che sia corta, scorrevole e ben fornita di esempi pratici.

That’s all, per oggi. La prossima volta, per rimanere in tema di contenuti, parleremo di articoli atomici ed interconnessi tra loro, con l’obiettivo di creare un’esperienza più interessante per il lettore.

“What You Give is What You Get” – Costruire una Community – La Semplicità

0

Qualche giorno fa abbiamo parlato, nell’ottica di creazione di una community, del concetto di scopo di una community. Oggi, amici miei, parliamo di semplicità. Concetto bellissimo e raramente raggiungibile in modo soddisfacente.

Come iniziare un articolo sulla semplicità? Proviamo con un’ammissione.

Noi sviluppatori abbiamo tanti problemi.

Ne abbiamo tuttavia uno più grande di tutti gli altri: l’impeccabile capacità di complicare cose assolutamente semplici. Se non ci fossero (e per fortuna ci sono) esigenze terrene a fermarci, di tanto in tanto, saremmo capaci di scriverci un blog in C++. Da zero. Non scherzo.

Ho imparato “sulla mia pelle” questa lezione proprio quando ho iniziato a pensare al come lanciare Laravel-Italia. La faccenda è cominciata con un dialogo tra me e me stesso ed è andata più o meno così.


Coscienza di Francesco: ok, rifletti bene. Devi lanciare un blog per Laravel-Italia. Ci scriverai articoli e serie di articoli, quindi avrai bisogno di un backoffice dove accedere, salvare le bozze, pubblicarle… cosa fai?

Francesco: beh, logico, me lo scrivo da zero usando Laravel, no?

Subsconscio di Francesco:


Nel mio caso ci tengo a dirlo: è stato un colpo di fortuna. Non si è trattato di qualcosa che già sapevo. Semplicemente la mia pigrizia ha vinto su tutto e ho deciso di iniziare Laravel-Italia con la piattaforma più adatta e logica per lo scopo: WordPress. Per i curiosi, ecco come appariva all’epoca:


Tornando a noi: ammetto di aver metabolizzato dopo la lezione, fortunatamente imparando qualcosa senza commettere un errore.

Cosa??? WordPress? Ma sei serio? E le buone pratiche, e il uebdesain, e i cugini?

Silenzio e rifletti: è un processo mentale semplice, alla fine.

Cosa dovevo fare? Scrivere articoli.

Perché non avrei dovuto usare WordPress per farlo? Non c’era un vero motivo che andasse oltre il “un blog su Laravel deve essere fatto con Laravel“.

Ecco, diciamo che quando stiamo pensando al magico “me lo scrivo da zero”, nove volte su dieci dovremmo fermarci e rifletterc per almeno un’oretta. Facendoci qualche domanda:

  • esiste qualcosa di pronto che può aiutarmi a raggiungere lo scopo?
  • se esiste, posso usarlo (magari personalizzandolo un minimo) per fare quello che mi serve?
  • dovrei scrivermelo da zero? Cosa manca a ciò che già c’è in giro?

Fatto? Risposto onestamente? Bene. Breaking news:

  • si può scoprire che novantanove volte su cento la risposta alle prime due domande sarà positiva, la terza negativa;
  • se ci troviamo in quel singolo caso su cento c’è una discreta possibilità che stia per nascere un’azienda, ma questo trascende gli scopi del post;

Lesson Learned: non complichiamo le cose, soprattutto quando non ne abbiamo bisogno. La mia necessità era scrivere articoli su un argomento, non usare per forza Laravel. 

Bisogna saper riconoscere quando è il caso di avere qualcosa di strutturato da subito e quando è il caso di partire agili, magari assemblando pezzi già pronti. Magari mandando a quel paese le “buone pratiche” per un po’. Non muore nessuno.

Per oggi è tutto. La prossima volta ci sporcheremo un po’ di più le nostre belle mani e parleremo di serie di articoli.