In termini di gestione del tempo, purtroppo, non posso aiutarvi con dei numeri precisi: nonostante tutti i buoni propositi, infatti, non ho mai tracciato le ore impiegate a lavorare sul progetto.
Posso dire però con certezza che, nell’arco di quasi due anni di vita del progetto, non penso di averci speso, in totale, più di due mesi lavorativi (320 ore).
Ad ogni modo, posso “classificare” il tempo speso in due categorie ben distinte:
In questa sezione proverò a raccogliere qualche pensiero su tutte quelle cose che ho imparato sull’evoluzione del progetto nel tempo.
Non smettete mai di misurare tutto quello che è possibile misurare nel vostro side project. Soprattutto quando le cose iniziano a farsi più serie capirete quanto il tempo sia denaro.
Arriviamo al succo della questione. Se avviate un side project che:
… prima o poi vorrete vedere anche un po’ di $oldi. Sì ma… come fare? Ovviamente non ho una formula magica, però posso raccontarvi come ho fatto io con la mia app.
Qualcuno ha riconosciuto la citazione? Siamo in Iron Man, il film del 2008 con Robert Downey Jr. Una di quelle citazioni che per qualche motivo ti rimane impressa e, un bel giorno, ti torna utile.
La frase infatti viene usata quando, per scappare dai terroristi che lo tengono prigioniero, Tony Stark sta finendo di preparare la prima versione dell’armatura che lo renderà un eroe.
Ho sempre pensato di essere molto fortunato nell’amare il lavoro che faccio. Non giriamoci intorno: saper fare bene lo sviluppatore nel 2021 è una bomba. A patto di rimanere aggiornati e sufficientemente curiosi, le possibilità sono tante, stimolanti e discretamente remunerative.
Nel tempo ho conosciuto due categorie di sviluppatori: quelli che amano lo sviluppo in quanto tale e quelli che lo amano in quanto mezzo. Io sono nel secondo gruppo: per me lo sviluppo software è uno strumento potentissimo con cui fare altre cose, risolvere problemi, divertirmi ad automatizzare qualcosa di noioso.
No tranquilli, non partirò con un pippotto motivazionale. In realtà, voglio spendere qualche parola sul mio modo di vedere la vita ed il lavoro.
C’è una frase di Al Pacino che amo e riassume perfettamente la filosofia che più mi appartiene:
“Forget the career, do the work. If you feel what you are doing is on line and you’re going someplace and you have a vision and you stay with it, eventually things will happen.”
Poco prima delle ferie, mi sono trovato in 1:1 con il mio team leader in Hootsuite. Periodicamente, svolgiamo delle attività di confronto il cui obiettivo è capire se, come dipendenti, ci sentiamo “sulla strada giusta“. Queste call, per me, sono sempre un’occasione per fare un po’ il riassunto delle “puntate precedenti”.
Quando ha chiesto delle mie ambizioni, ammetto di aver avuto qualche difficoltà a rispondere in modo convenzionale. Non ho delle vere e proprie ambizioni: mi riesce da sempre difficile vedere la felicità e la realizzazione come una destinazione.
Oggi voglio parlare di un tema che mi è sempre stato molto a cuore: i side project.
Se sviluppate software per vivere, come faccio io, sicuramente ci avete fatto almeno un pensiero (almeno una volta). Non è solo questione di soldi in quanto tali: mi ha sempre attratto molto quell’idea (anche un po’ romantica, se vogliamo) di tirare su qualcosa che può essere utile ad altre persone in giro per il mondo. Magari sviluppata nel tempo libero, con la musica giusta in sottofondo, durante un weekend piovoso.
Qualcosa che a un certo punto diventa abbastanza utile e di valore che c’è chi è disposto a pagare per usarlo, questo qualcosa.
A me è successo: la mia prima app Shopify, Ahia! – Easy Price Changer è arrivata a quasi 150 clienti paganti in giro per il mondo. Piano piano continua a crescere, e prendersi la sua fetta di mercato nel piccolo (grande) mondo di Shopify.
L’articolo di oggi inizia con un problema: mi sono scordato di pagare un dominio. Sforo di poche ore, niente di pazzesco, e recupero tutto immediatamente. Il mancato pagamento in tempo, però, crea un po’ di casino nei DNS e, per un paio di giorni, il sito non è raggiungibile. Odio questi contrattempi.
Ora, per vari motivi mi capita di comprare un bel po’ di domini ogni anno. Il mio provider, nel mandarmi i reminder, fa un bel mischione e sempre più spesso i domini più importanti spariscono in mezzo ad altri cinque/dieci alla volta.
Come ogni dev che si rispetti, mi sono detto: “perché non scrivermi da zero un piccolo software che mi ricorda dell’imminente scadenza?”
Essendo appassionato di prodotto, secondo voi, potevo mai scrivermi un semplice tool da linea di comando? Certo che no. Così è nato domain-check.it.
E da qui la sfida che mi sono proposto: creare un piccolo Saas ed usare Laravel Jetstream insieme a Livewire, di cui ho parlato qualche tempo fa con l’ottimo Alessandro. Essendo un progetto piccolo ed avendo altre incombenze, mi sono messo una scadenza molto precisa: Domenica 2 Maggio 2021. Praticamente due giorni, considerando che sono partito Venerdì 30 Aprile, sul tardi (6 di pomeriggio).
In questo post racconterò com’è andata.
La chiacchierata con Alessandro mi aveva intrigato non poco. Chi mi conosce sa bene quanto amo fare prodotto, sperimentare, lanciare un progetto e capire se risolve un problema. Da fuori (non l’avevo mai provato prima) avevo fatto qualche ipotesi su Livewire e Jetstream:
In base a queste considerazioni mi sono posto i primi obiettivi:
Bene. Come si fa?
Più che “come si fa”, innanzitutto mi sono chiesto “che si fa?”
Ho iniziato a buttare giù una prima serie di idee di feature per la prima release dell’applicazione. Non importa da quanto tempo scrivi software, è sempre una delle cose più difficili, perché la mente viaggia ed inizi a tirare dentro di tutto.
Ho così delineato le prime feature di base:
Oltre a questa feature base, ne ho voluta aggiungere un’altra “bonus”:
Sono davvero due feature, nulla di più. La cosa bella, però, è che da ognuno di questi punti, apparentemente semplici, si possono scatenare un’infinità di domande:
Ecco, questo è il momento in cui scatta il panico, ed è notoriamente più difficile muoversi.
Quando entro in questa fase è davvero semplice perdere il controllo. Mi è capitato tantissime volte, in passato. Così adotto una tecnica semplicissima: parto da una feature e la riduco all’osso ogni volta che vedo possibilità di personalizzazione. Esempio:
Qui entra in gioco un concetto fondamentale che prima facciamo nostro e meglio è: le supposizioni che faccio sono, appunto, supposizioni. Possono essere vere o false, ma prima mi butto, prima so se effettivamente la mia supposizione è giusta, e se è sbagliata posso correggere il tiro velocemente.
Insomma, citando Tony Stark: “un bullone sì ed uno no, non devi farmi bello“.
Così alla fine ho delinato le feature principali in modo molto più preciso:
Per rendere l’app più “amichevole”, chiedo all’utente la sua timezone e faccio in modo che qualsiasi alert gli arrivi per le 9 di mattina nel suo fuso orario. Motivo: sono ragionevolmente certo che una mail di una scadenza alle 3 di notte non sia molto comoda.
Bene: possiamo scrivere codice.
Come prima cosa, ho avviato un nuovo progetto Laravel e ho installato Jetstream seguendo la documentazione, molto chiara. Ho deciso di installare la versione full-featured con i team (tanto all’inizio si possono disabilitare). Come il titolo lascia intendere, ho scelto il setup con Livewire.
Mi sono preso un po’ di tempo per esplorarlo. Un paio di chicche sono interessanti:
Spente le feature non necessarie (team, 2FA e qualche altra chicchetta) mi sono concentrato sulla creazione dei primi componenti. Il boilerplate di base che Jetstream offre è impressionante. A ben pensarci, la mia app deve “gestire” tre cose:
Già al momento zero Jetstream mi ha tolto il 33% del lavoro da fare.
Dopo aver creato le prime migration ed i model, passo a Livewire…
Livewire mi ha messo davanti ad una delle cose più difficili per uno sviluppatore: disimparare.
Ho notato, infatti, che spesso più andiamo avanti e più tendiamo a voler “fare le cose per bene”. Che è paradossale se ci si pensa: spesso studiamo cose che stanno agli antipodi (mi viene in mente lo studio di un linguaggio funzionale venendo dagli oggetti), ed applicare la nostra esperienza a quelle cose, per quanto naturale ci possa venire, è la cosa più sbagliata possibile.
Ci sono un po’ di cose che mi hanno fatto storcere il naso, di Livewire: una su tutte, il fatto che mi piazza le classi con le logiche dei componenti appena generati in “App/Http”, che generalmente associo al backend.
In un primo momento ho sentito un brivido percorrermi la schiena: venendo da React, vedere mischiato un metodo “render()” di una classe piazzata in una cartella chiamata “App/Http” mi ha fatto un po’ senso.
Poi ho ricordato: disimparare. E quindi sticazzi. Buttiamoci, vediamo come va e POI valuto.
Dopo la timidezza iniziale ho preso dimestichezza con il modo in cui i componenti vengono creati e mi sono messo l’anima in pace. Ho fatto tutto in poche ore riuscendo, comunque, a tenere i componenti abbastanza in ordine.
Per creare l’interfaccia utente, oltre a Livewire, mi sono affidato a TailwindCSS per avere un’impostazione decente di base.
Ora, il principio alla base di Tailwind è l’ampio uso di utility class. Questo significa che buona parte dei nostri tag HTML saranno infottati di classi css per qualsiasi cosa.
Il concetto è spiegato magnificamente qui.
Anche qui, questa faccenda può piacere o meno. All’inizio ero diffidente poi ho cercato di guardare le cose più dall’alto e ho capito meglio: ci sono talmente tante classi per tante situazioni che il 95% dei casi è abbondantemente coperto.
Per andare più veloce, ad ogni modo, ho “barato”: avendo bisogno di alcuni componenti leggermente più complessi (tabelle, widget ed altre piccole cose), ho comprato i componenti marketing + app su TailwindUI.
Nota: ho comprato il pacchetto completo (marketing + app) per potermi sbrigare anche a fare la home page.
Qui vale la pena fare un’osservazione: sono stati 200 euro ben spesi, se penso che mi hanno evitato ore ed ore di lavoro inutile.
Va detto che TailwindCSS di base è piuttosto scarno e manca di tanti elementi che secondo me andrebbero resi disponibili di default gratuitamente. Ma è una mia opinione e non vale una mazza. In ogni caso peace, non è una grande spesa quindi va bene così.
Alla fine della fiera, in questo modo, per un progetto piccolo o comunque poco esigente, hai tutto quello che serve per consegnare il tuo lavoro in tempi ragionevoli, se non record.
La cosa che mi piace di più dell’ecosistema di Laravel è che funziona. Ho tracciato un po’ il tempo usato per realizzare domain-check.it, ed ecco il breakdown:
Quindi sì, nel titolo ho detto una stronzata 🙂 Non 48 ore, ma 20.
Questo ovviamente non è stato possibile perché sono bravo o bello, ma perché semplicemente l’ecosistema di Laravel è composto da tanti piccoli strumenti, free o meno, che lavorano in perfetta sinergia tra loro.
Ho già citato Nova e Forge, ma è stato fondamentale avere un sistema di code up and running in poco tempo con Horizon. Gratuito. Anche Jetstream è gratuito, e fa uso di altri package come Fortify.
Insomma, tanta bella carne al fuoco.
Millecinquecento parole dopo, cosa ho imparato da questa esperienza?
All’inizio dell’articolo avevo supposto come use case ideale l’applicazione piccola.
Adesso inizio a pensare che anche per una di “media” grandezza (in termini sia di utenti che di feature) possa cavarsela senza troppi bagni di sangue.
Vi aggiorno 🙂
Direi che è arrivato il momento di concludere il nostro piccolo viaggio introduttivo alla scoperta di come creare un’API GraphQL con Laravel. Nell’articolo precedente, pubblicato un paio di settimane, fa, avevo spiegato le basi di Lighthouse e di come usarlo per creare, facilmente, un’API GraphQL usando il nostro framework preferito.
L’ultima volta ci siamo lasciati dopo aver visto, un po’ più da vicino, le prime query sulla nostra entità Movie.
Oggi vedremo più da vicino come funzionano le mutation, come vengono gestite le relazioni tra entità e, infine, qualche esempio su altri tool che Lighthouse ci mette a disposizione per facilitarci il lavoro. Pronti? Partiamo dalle…
Ultimamente, nel mio gruppo Facebook preferito, mi trovo spesso a parlare di quali argomenti affrontare su questo blog. L’ultima volta è toccato al Deploy di un’applicazione Laravel su Kubernetes, che pare abbia dato notevoli soddisfazioni.
E oggi? Beh, questa volta daremo uno sguardo, insieme, a come possiamo mettere su senza troppi problemi un’API GraphQL con Laravel. Con l’aiuto di un package davvero speciale: Lighthouse!
Tecnicamente, GraphQL è definibile come un linguaggio da usare per richiedere e manipolare dati via API. Lo ha tirato fuori dal cilindro Facebook, ormai nove anni fa, prima di essere rilasciato pubblicamente nel 2015. Se si vuole studiare nel dettaglio il linguaggio in questione, questa è la fonte ufficiale a cui attingere.
Non mi dilungherò in ulteriori spiegazioni albertoangiolesche, ma gli elementi che bisogna conoscere per iniziare lavorare con delle API GraphQL sono tre:
Rispetto ad una “classica” REST API, ovviamente, ci sono un po’ di differenze. Per citarne alcune:
Due delle API con cui ho lavorato di più in tutta la mia vita sono GraphQL: quelle di Facebook e Shopify.
Creare una GraphQL API con il nostro framework PHP preferito è, devo ammetterlo, sorprendentemente semplice. Esiste un package, infatti, chiamato Lighthouse, che semplifica di molto la vita dello sviluppatore in questo senso.
Vediamo quindi come installarlo e come prepararlo.
Supponendo di avere un progetto “fresco” di Laravel, la prima cosa da fare è installare il package in questione, insieme ad un comodo tool per fare qualche test.
|
1 2 3 4 5 6 7 8 |
# installiamo il package... composer require nuwave/lighthouse # installiamo Laravel GraphQL Playground composer require mll-lab/laravel-graphql-playground # pubblichiamo il file schema di default! php artisan vendor:publish --tag=lighthouse-schema |
Visto che so bene quanto vi piace mettere le mani nella ciccia già da subito, vi accontento. Proviamo subito questo package, no?
Andiamo a curiosare nello schema che è stato pubblicato in graphql/schema.graphql.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
"A date string with format `Y-m-d`, e.g. `2011-05-23`." scalar Date @scalar(class: "Nuwave\\Lighthouse\\Schema\\Types\\Scalars\\Date") "A datetime string with format `Y-m-d H:i:s`, e.g. `2018-05-23 13:43:32`." scalar DateTime @scalar(class: "Nuwave\\Lighthouse\\Schema\\Types\\Scalars\\DateTime") type Query { users: [User!]! @paginate(defaultCount: 10) user(id: ID @eq): User @find } type User { id: ID! name: String! email: String! created_at: DateTime! updated_at: DateTime! } |
Possiamo notare principalmente tre cose:
Possiamo trovare più informazioni su come leggere questo file qui, sul sito di GraphQL, nella sezione dedicata al linguaggio usato per lo schema. Detto questo… facciamo subito una prima chiamata!
Per prima cosa, accediamo a Laravel Tinker per aggiungere al volo un po’ di dati di prova.
|
1 2 3 4 5 |
# accediamo a Tinker! php artisan tinker # una volta entrati, eseguiamo >>> \App\Models\User::factory(10)->create() |
Fatto questo, accediamo al Playground andando a visitare http://localhost/graphql-playground. Inseriamo questa query nel pannello a sinistra:
|
1 2 3 4 5 6 7 |
{ user(id: 1) { id name email } } |
e clicchiamo sul tasto “Play” per eseguire la query.
Già qui possiamo testare una delle cose più interessanti delle API GraphQL: proviamo a togliere “email” dai campi richiesti. La query verrà eseguita lo stesso, ritornando effettivamente gli stessi dati senza, però, la mail dell’utente. Niente male, per non aver scritto nemmeno una riga di codice, no?
Ok, adesso aggiungiamo qualcosa di “nostro”.
Ho immaginato una piccola API per gestire film. Quelli che torneremo a vedere al cinema molto presto (spero). Senza strafare, partiamo da qualcosa di molto basilare.
|
1 2 |
# Generiamo il necessario con... php artisan make:model -m Movie --factory |
Questo comando genererà il model, la migration ed una factory. Nella migration, aggiungiamo due colonne:
Nella factory, modifichiamo il metodo definition così:
|
1 2 3 4 5 6 7 |
public function definition() { return [ 'title' => $this->faker->sentence, 'year' => $this->faker->numberBetween(1980, 2020) ]; } |
Non aggiungeremo altro per ora. Non scordiamoci di eseguire php artisan migrate e di generare qualche record di prova per la tabella dei film:
|
1 2 3 4 5 |
# Apriamo Tinker... php artisan tinker ... ed usiamo la factory! >>> \App\Models\Movie::factory(10)->create() |
Bene, è tutto.
Torniamo al nostro graphql/schema.graphql. Seguendo la traccia di quello che abbiamo visto prima, dobbiamo aggiungere una definizione per la nostra nuova query. Proprio come per gli utenti, infatti, definiamo…
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
"A date string with format `Y-m-d`, e.g. `2011-05-23`." scalar Date @scalar(class: "Nuwave\\Lighthouse\\Schema\\Types\\Scalars\\Date") "A datetime string with format `Y-m-d H:i:s`, e.g. `2018-05-23 13:43:32`." scalar DateTime @scalar(class: "Nuwave\\Lighthouse\\Schema\\Types\\Scalars\\DateTime") type Query { users: [User!]! @paginate(defaultCount: 10, type: CONNECTION) user(id: ID @eq): User @find movies: [Movie!]! @paginate(defaultCount: 10, type: CONNECTION) movie(id: ID @eq): Movie @find } type User { id: ID! name: String! email: String! created_at: DateTime! updated_at: DateTime! } type Movie { id: ID! title: String! year: Int! created_at: DateTime! updated_at: DateTime! } |
Cosa abbiamo aggiunto?
Fatto! Possiamo provare la nostra API. E no, non serve scrivere altro codice… bello, vero?
Riapriamo il playground e proviamo la query paginata:
|
1 2 3 4 5 6 7 8 9 10 11 |
query { movies(first: 10) { edges { node { id title year } } } } |
O magari quella di ricerca tramite ID:
|
1 2 3 4 5 6 7 |
query { movie(id: 1) { id title year } } |
Insomma, neanche una riga di codice da scrivere, solo la specifica da compilare. Certo, questo è un caso molto basilare… cosa succederà in situazioni più complesse?
Nella prossima parte di questo articolo, vedremo insieme:
La seconda parte arriverà tra qualche giorno (update, la seconda parte è qui)… quindi rimanete nei paraggi! Se volete, posso avvisarvi io tramite la newsletter! Potete iscrivervi su questa pagina oppure usare il form a lato.
A presto!
