The Weekly Talk Review #2 – Patterns that Pay Off by Matt Stauffer

My choice for this second issue of “The Weekly Talk Review” is another Laracon 2018 talk: “Patterns that Pay Off” by Matt Stauffer.

It kept me glued to the screen, and I am not exaggerating. I love practical and pragmatic talks. After listening to a lot of talks, I learned how to recognize speakers that have broad, practical experience with the topic they have chosen for the talk.

Do not be fooled by the title: it’s not about design patterns in a traditional way. This talk is about a lot of practical dos and don’ts that you can apply in your everyday job. I loved how he managed to explain the importance of the value you give to your customer. I also appreciated a lot the concept of “posture” towards patterns, or how we approach them.

Also, the “Test to save your job” and “Monolith first” parts are pure gold. However, I am not going to spoil it, so watch it and enjoy!

The Weekly Talk Review

First time here? Welcome to The Weekly Talk Review, here on FrancescoCodes.

Every week I will make a short review (~100 words) of a talk that I liked and found interesting enough to share here with you. I am not going to review only Laravel related talk: why limit myself when there is a lot of stuff to learn?

Have fun and feel free to suggest a talk in the comments if you want to share it with us. I will be more than happy to see it and publish it here!

The Weekly Talk Review #1 – Design Patterns with Laravel by Colin DeCarlo

For this first issue of “The Weekly Talk Review”, my choice is this fantastic talk by Colin DeCarlo at Laracon 2018: “Design Patterns with Laravel”.

I must admit it: I have a thing for everything that makes learning way easier than expected. In this talk, Colin tells us about his struggles with the Design Patterns book first impact, and how things can be explained differently. Then, he makes some perfect, real-life examples of code refactoring while implementing these patterns. The code highlighting style is the cherry on top.

I think this talk will be particularly useful to all those developers that are starting refactoring their first codebases into something more structured and well written.

Timing is also perfect: in ~32 minutes everything fits in it perfectly without any sense of haste. I am not going to tell you which patterns he has chosen; you will do it by yourself 🙂

Also liked a lot the quote from Kent Beck:

“Make the change easy, then make the easy change”.

Enjoy it!

The Weekly Talk Review

First time here? Welcome to The Weekly Talk Review, here on FrancescoCodes.

Every week I will make a short review (~100 words) of a talk that I liked and found interesting enough to share here with you. I am not going to review only Laravel related talk: why limit myself when there is a lot of stuff to learn?

Have fun and feel free to suggest a talk in the comments if you want to share it with us. I will be more than happy to see it and publish it here!

The 2018 Mighty Laravel Application 20 Optimization Ideas Checklist

Here we go! Your Laravel application is now in production. You are online, ready to start making a lot of mecha-gazillion dollars.

Roses are red, violets are blue, tests are green and you feel so cool.

First user. Ten users. One hundred users. A thousand users! Suddenly, the more you go forward, the more your application becomes slower.

What should you do? Well… Devil is in details.

After some searching, I decided to create this list of 20 tips you can use to boost your Laravel application to a new level.

I will start with the basic stuff, mostly something you can apply in seconds. Then, I will introduce you to something at an intermediate level. Finally, the advanced things. If you follow the next steps in a proper way, I am sure your application will get a real boost.

Enjoy it! If you want to suggest something, leave a comment below! I will be more than happy to add it.

Basic Stuff

Ok, let’s see what we can do in seconds.

Route Caching

Every time your server execute a request, all the routes are registered. It takes some time. However, you can choose to cache them to skip the step instead of doing it.

Caching your routes is easy. All you have to do is to execute a command after you deploy your application:

However, if you add new routes or edit something don’t forget to clear the route cache and re-execute the command.

Note this only work with Controller routes.

Config Caching

Just like routes, you can also cache configuration files of your application.

Think about it: every single time you send a request to your app, Laravel needs to load different configuration files, and the .env file must be opened to read its contents. This approach is not performance oriented, huh?

Don’t worry; there is an Artisan command for that.

You can use it after your deploy. Just like routes, don’t forget to clear the config cache if you edit something.

Optimize the Composer Autoloader

Usually, the autoloader file generated by Composer is quite fast. However, in a production environment, things can get slower if PSR-4 and PSR-0 autoload rules are set up.

You can optimize the autoloader file creation process by adding the

command to your deploy script. Don’t forget it 😉

False Myths: “Don’t Use a Lot of Blade Views”

I have heard this a LOOOOOOT of times.

“Don’t use a lot of Blade views because application performance will decrease!”

Totally – not – right. Seriously.

Remember: Laravel compiles Blade views. Compiled means that at the end of the process you have a compiled, complete file that is going to be used instead of multiple files.

So, don’t worry 😉

Intermediate Stuff

Switch to Another/Better Cache/Session Driver

By default, when you start a new Laravel project the default driver for Cache and Sessions is “file”. It is ok for the local development environment and small projects, but wrong when things are getting serious.

So, think about moving on to something better like Redis. Laravel has built-in support for it, and all you need to do is to install Predis.

More details here and here.

Update Laravel Version ASAP

Remember to update Laravel as soon as possible when a new version comes out. It’s not just about features: when possible, all the contributors spend time fixing performance issues around the codebase.

So, stay tuned and keep your code up to date.

Unused Service Removal

This one is a trick a lot of people often forget. The fundamental question is the old one:

“Do I need it?”

Now, we know that Laravel has a lot of stuff inside of it. After all, we are talking about a full-stack framework, made to solve a lot of specific issues. That said, the perfect weapon does not exist.

Spend some time checking the config/app.php file to see if you can find a service provider you don’t need. Try to remove it and test your application if everything is ok.

It should help (a little bit)!

Use Eager Loading for your Queries

If you know what Laravel is, you probably also know what the Eager Loading is. In case you live under a rock, Eager Loading is a way to improve Eloquent performance by using a specific syntax to reduce the number of queries it sends to the database.

This problem is known as N + 1 query problem. Let’s make an example. You have two models: Book and Author. Every book has its author.

Imagine that you have 1000 books in your database. Now, this code is going to execute 1001 queries to retrieve the author name for 1000 books.

1 (query to fetch data for 1000 books) + 1000 (queries to fetch author data for every book) = 1001.

However, if you write this code like

the underlying query is changed to avoid this performance problem. You will execute only two queries instead of 1001! A huge performance improvement.

Cache Query Results

Sometimes, caching specific queries results can be a great idea.

Imagine this situation: you are showing a “Top 10 Albums” in the home page of your application. The job is done by a query that fetches data from the database (maybe involving artists and other tables). Your home page is seen 1000 times/hour.

1000 queries per hour for that widget. 24000 queries/day for a f*****g widget.

Now, let’s say the Top 10 is updated hourly. So, what about caching the result for an hour?

With the remember method of the Cache component you will be able to fetch data from the database, save it on the cache storage and use it for 60 minutes. After that period, “fresh” data will be fetched again from the database.

From 24000 to 24 queries/day.

Add Indexes to your Tables

Remember to add indexes to your tables when necessary. It may seem a trivial tip, but it’s not. I saw a lot of applications without indexes on their tables.

You can do it easily with a new migration and dedicated code inside of it.

You can’t just create indexes wherever you like it. You must study your business, your code and queries, understand where it is necessary and then add the required indexes.

Too Many Middlewares?

Under the hood, Laravel does a lot of (pre/post) calls for every middleware you register in the application code. So, be sure to double check them and remove what you don’t need.

You can find the list, as usual, in the Kernel.php file.

Time to Use Queues!

Sometimes, Laravel applications are way slower than expected because you can asynchronously implement synchronous tasks and you don’t do it.

The most used example is the welcome email sending. Let’s imagine a flow:

  1. user filled our form;
  2. we save his/her details on the database;
  3. we send him/her an email with a welcome message and a confirmation link;
  4. we show him/her a “Thank you!” view;

Well, a lot of times a saw all this stuff entirely done in a controller and sequentially.

My suggestion here is to learn how to use events and queues. You could use them to delegate the email sending procedure to another dedicated process and improve the final user experience.

Advanced Stuff

Use Pusher to Improve Async Tasks

Just a couple of lines above I wrote about queues. Well, you can also use queues to improve user-facing tasks, sometimes.

Imagine that you are creating a heavy (in terms of calculations) procedure and you want to show a progress bar for your user. You can easily use an async job on a queue and an integration with Pusher to send messages to your frontend even if the task is not complete yet.

Another often used example is a way to send notifications to your user without the need to reload the page.

Think about it!

Use Logs / Debugbars / Laravel Telescope to Measure Stuff

There is a quote that I love about what you can improve. I’ve heard from my CEO (thanks Massimo!) quoting Peter Drucker.

You can’t improve it if you can’t measure it.

This concept fits perfectly in the context of web applications. There is a lot of stuff to be measured to improve requests management times. Luckily for us, there are also a lot of excellent tools to do it.

  • Slow query logs: in MySQL, MariaDB and other databases you can enable a dedicated log for slow queries to track what is taking a lot of time. You can use this data to understand if a specific piece of code (or query) must be changed or optimized;
  • Debugbar: Laravel Debugbar is a fantastic package you can use to collect data about a lot of your application aspects. Queries, views, times and so on;
  • Laravel Telescope: another cool tool is Laravel Telescope, defined as “an elegant debug assistant” for a Laravel application. If you are interested, I have already written an article about it here;

Update PHP

It is quite simple, but I decided to add it to the Advanced group, because if your codebase is a large one this could be a difficult task.

Consider updating your old application to PHP 7.* if you have not done it. Of course, don’t also forget that you will also need to update your Laravel version.

Consider Lumen for Services

If your application is growing a lot, start considering a way to split stuff into separate services. There is not a clear guide for doing this: the perfect splitting criteria depends on many factors, from the domain of your application to the work you need to do to split all the necessary stuff.

However, when you start to “break the monolith” your application can breathe again.

If you are interested in the subject, this article can be a good start:

Serve Assets with a CDN

I am quite sure you have a lot of frontend assets, like CSS files and JS scripts.

You can reduce the amount of data you send to your users in many ways:

  • Assets minification;
  • Assets bundling;
  • Enable gzip compression;

However, if you experience a lot of traffic you can host your assets to a dedicated CDN service, like:

  • Akamai
  • Max CDN;
  • Cloudflare;
  • Amazon AWS Services (S3 + CloudFront);

Use Advanced Measurement Tools

Installing the Laravel Debugbar or Telescope can be a good start, but for more significant applications, it could not be enough.

You should choose more advanced tools like:

  • New Relic;
  • AppOptics;
  • Datadog;
  • Sentry;

Applications in the list above do not do the same thing: they are made for different purposes. Spend some time studying them to understand how they can help you.

Vertical Scaling

You have done everything to optimize every single bit of your code, but your application is growing. Sooner or later you will need to scale your application vertically.

It’s a simple concept: more RAM, more space, more bandwidth, more CPU.

Note that this is a quite common practice for a lot of startups that do not have enough time to schedule a refactoring/optimization procedure. It’s perfectly ok, so consider it like a temporary solution to give you some breath.

Horizontal Scaling

Another approach to scaling, different from the traditional vertical scaling, for two reasons:

  • Instead of raising your resources on the current configuration, you will add more items to it to deal with the traffic increase differently. While in the context of vertical scaling you merely raise the level of your server configuration, scaling your application horizontally means that it will run on different machines, maybe behind a load balancer and other services. It means more setup and configuration; it’s not so simple as it may seem;
  • Not all applications are written to be scaled horizontally in a matter of hours. Sometimes you will need to refactor and isolate some code; sometimes you will need to split your application in different, smaller services that are going to scale differently;

There is a lot of work to do, but when you can horizontally scale your application, the benefits are incredible.


Enough stuff for today! I have created this list by merging my personal experiences and some research I have done for it.

If you want, feel free to suggest new items, I will be happy to update it accordingly.

Monitoring a Laravel Application with Telescope

I am always excited when a new Laravel ecosystem product comes out. I am not a fanboy, I have always been skeptic and critic about some parts of the framework when I don’t like them, but there is something (among many others) I love about Laravel: its pragmatism.

So, every single time they release something new I am 100% sure that it’s something that can be useful, no matter if paid or not (the cure the team put in it makes nearly impossible to feel the difference).

Today I want to talk a little bit about Laravel Telescope, a debugging tool for Laravel applications. On the Telescope Github page is defined as an “elegant debugger assistant”.

You can use it to monitor a lot of stuff:

  • Requests
  • Commands
  • Exceptions
  • Logs
  • Queries
  • Events
  • Mail

… and more. In this article, I will show you how to install it and then use it in your workflow.

Installing Telescope is easy. All you have to do is to add it as a dependency of your project with Composer.

Once done, you only have to run a couple of commands:

The first one is used to scaffold everything is necessary. Then the migrate command will take care of the database schema Telescope requires.

That’s it!


The installation command added a new telescope.php file in your config folder. The documentation suggests spending a little time exploring it.

In the file we can count four items:

  • Path: it’s just the path we will use to access Telescope. By default, its value is “telescope”. That means you will be able to access it at /telescope;
  • Storage: here we can define everything about where we are going to save Telescope related metrics. By default, Telescope saves data on specific MySQL tables we created during the install procedure;
  • Middleware: here you can define a list of middleware to be assigned to every single telescope route. By default, it includes the “web” group and the specific Telescope “Authorize”;
  • Watches: every single item Telescope is monitoring has its own “watcher”. Exceptions? ExceptionWatcher. Queries? QueryWatcher. The list goes on following this rule. Here you can customize this list to define what you want to track and what you don’t need;


Now we know how to install Telescope and how to configure it. Let’s use it! I will assume your Laravel project is accessible at http://myapp.test.

Let’s open it by going to http://myapp.test/telescope. Here’s the main dashboard:

Right now we are in the “Requests” section of Telescope. Try to visit, then come back here or refresh the page.

Yeah, it’s working! For every request, we can see the HTTP verb, the complete path (in this case we have an empty value because we requested the home page) and when the event happened. We also have an eye icon. It’s a button we can click to access more details about the request.

Let’s click on it!

For every request, we can see everything, from basic details to headers, related session data, and some metadata about the response.

One of the most useful features is also the ability to see “related” Telescope records. Example: in this request, we set a new cache item, the “a66bs…” one. We can look at its details by clicking on the eye icon again.

I like this feature. It is handy to debug in depth what can go wrong and have a better understanding of the app we are building.

Oh, talking about what can go wrong: let’s test one of my favorite ones. Exceptions!

First of all, go to the routes/web.php file and add this code.

Great. Now go to http://myapp.test/error. You should see the classic exception screen. Let’s go back to Telescope and click on the Exceptions in the menu.

Yeah, we got it! Let’s click on the eye icon to see some details about this exception.

I love this one.

With a little effort (installing and configuring Telescope required nearly no time) we have a lot of data about this exception message, location and stack trace. Also, we can quickly check other occurrences for the same exception or access the related request!

I think this is one of the most amazing features of Telescope. Yeah, I already know that the sea is plenty of advanced software already doing this. I am thinking about Sentry because I use it in my everyday job.

However, what if are you just bootstrapping a product and you want to have an excellent debugging tool with nearly no install effort? Telescope is the perfect fit.

Huh, talking about production…

Should I Use it in Production?

By default, Telescope is visible in the local environment only. However, you can easily modify this behavior by editing the app/Providers/TelescopeServiceProvider.php file.

There is a method called “gate()”. You can edit it with your custom logic to decide if a specific authenticated user can see the Telescope dashboard or not. The documentation suggests a straightforward approach: define an email whitelist. However, you can decide to stick with it or implement your logic.

So… Should you use it in production?

Given my previous experiences, I think I will do it for my next project. Especially in a first bootstrapping phase, it could save me a lot of time.

Have you already tried it? What do you think about it? Let me know in the comments.

Il mio nuovo package per Laravel 5.6: Circuit Breaker!

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.

Continue reading

Deploy di un’Applicazione Laravel 5.6 con ECS + Fargate

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.” Continue reading

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

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à

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.

“What You Give is What You Get” – Costruire una Community – Lo Scopo

Un paio di mesi fa, in quella che è stata (per me) l’edizione di Codemotion più bella di sempre, ho avuto il piacere di tenere un talk dedicato alla costruzione di una community. Qui è possibile vedere il video completo:

Il mio discorso ha coperto principalmente tre argomenti:

  • cosa mi ha portato a creare la community;
  • a cosa mi ha portato il creare la community;
  • cosa ho imparato nel mentre;

Sui primi due punti si potrebbe dire tutto e nulla: trattare questi argomenti mi ha portato anche a metabolizzare alcune cose che probabilmente sapevo già da prima ma non avevo mai “formalizzato” in questo percorso durato ben cinque anni.

Spoiler: ho lasciato ufficialmente Laravel-Italia qualche mese fa.

That said, qualche giorno fa mi sono ritrovato a pensare che forse sarebbe stato il caso di approfondire un po’ alcuni di quei concetti che, per ovvie questioni di tempo, mi sono ritrovato a “limare” per poter rimanere nei quaranta minuti.


Cosa ho imparato nel mentre?

Quello che voglio raccogliere (e raccontare) nei prossimi post è un insieme di nozioni, trucchi e accorgimenti che ho imparato (o scoperto) con la pratica di tutti i giorni per cinque anni di fila, tenendo le redini di Laravel-Italia.

Sono sincero: avrei voluto scrivere tutto in un unico articolo.

Poi il word count è schizzato alle stelle in un attimo e, per fortuna, l’angelo custode delle mie questioni grammaticali (e dintorni) ha ben pensato di suggerirmi un po’ di tagli e suddivisioni. Ragion per cui al posto di un singolo articolo con dieci (lunghissimi) concetti ho deciso di scrivere un articolo per punto.

Ad ogni modo, se chi ben comincia è a metà dell’opera, tocca iniziare dal…

Definire lo scopo della community

Una delle prime cose che ho scoperto è che spesso la definizione dello scopo della community viene sottovalutata.

Ogni cosa deve nascere con uno scopo specifico e, soprattutto nei primi momenti di vita, più tale scopo è “verticale” su qualcosa e maggiori sono le possibilità che questa “cosa” funzioni.

Per spiegare meglio il concetto mi viene subito in mente la nascita di Amazon: prima di vendere qualsiasi cosa, dalle mutande ai lampadari, il suo scopo era esclusivamente vendere libri. Punto. Niente di più, niente di meno. Una volta raggiunta l’eccellenza in quel settore è riuscita a primeggiare in tanti (ma tanti) altri.

Per quanto riguarda le comunità di sviluppatori mi vengono in mente due categorie ben distinte:

  • le community che vogliono diffondere una tecnologia in una specifica area geografica;
  • le community che vogliono mettere insieme delle persone per creare qualcosa di specifico;

Nel mio caso, Laravel-Italia è un buon esempio della prima categoria. Il suo scopo, fin dall’inizio, è stato quello di produrre dei contenuti in lingua italiana, non troppo avanzati ma perfetti per l’utente che si sta avvicinando per la prima volta ad una certa tecnologia e vuole abbassare il più possibile la difficoltà di accesso ad essa. Certo, alla lunga le cose possono diventare leggermente noiose (non dover dare mai per scontati alcuni concetti, anche i più basilari, perché chiunque potrebbe essersi “appena connesso”). In questo genere di comunità la priorità è unire il maggior numero di persone per diffondere il più possibile la tecnologia in questione.

Un discorso diverso invece va fatto per la seconda categoria. Nel talk, per rendere meglio l’idea, ho chiamato queste community “gruppi di studio”. Sono l’esatto opposto del caso visto in precedenza: l’obiettivo non è più creare una massa notevole di utenti e favorirne l’accesso alla tecnologia ma formare un piccolo gruppo di utenti più avanzati (già preparati) per “spingere” la tecnologia stessa con un obiettivo molto preciso. Mi viene in mente un gruppo in cui si affronta un argomento specifico in modo più avanzato, o magari un gruppo di persone esperte in una certa tecnologia che decidono di usarla per creare qualcosa di nuovo, “spingendone” appunto i limiti.

Ecco, dare da subito una direzione specifica alla community che si sta creando è una delle prime cose da fare, secondo me. Perché così si può:

  • capire da subito che tipo di materiale bisogna preparare;
  • iniziare a pensare al modo migliore di trovare altre persone;
  • decidere da subito un livello al di sotto (o al di sopra) del quale non vale la pena spingersi;

Riprendendo l’esempio di Amazon, tra l’altro, bisogna dire che nulla ci vieta di “espanderci” in un’altra categoria. Raggiunto un buon livello, infatti, si può sempre decidere di creare un sottoinsieme di utenti motivati e partire con un nuovo progetto.

Lesson Learned: scegli lo scopo, rimani il più possibile verticale su quello scopo (all’inizio soprattutto) e prenderai una direzione. Giusta? Nessuno può dirlo. Almeno ne hai presa una e non è cosa da poco.

E con questo per oggi è tutto.

La prossima volta parlerò di un altro concetto fondamentale che spesso tendiamo a perdere di vista.

La semplicità.