Perché avviare un progetto Laravel non dovrebbe significare aprire sei terminali diversi

Laravel ha reso estremamente semplice e produttivo sviluppare applicazioni web.

Con il tempo, però, ci siamo accorti di una piccola contraddizione: mentre il framework semplifica moltissime attività, avviare ogni mattina il proprio ambiente di sviluppo può diventare sorprendentemente macchinoso.

Un progetto Laravel moderno, infatti, raramente si limita a:

php artisan serve

Molto più spesso ci troviamo ad avviare anche:

npm run dev
php artisan queue:work
php artisan horizon
php artisan reverb:start
php artisan schedule:work

A questi possono aggiungersi Laravel Sail, più queue worker, processi custom o comandi specifici del singolo progetto.

Il risultato?

Prima ancora di iniziare a scrivere codice, il desktop può facilmente trasformarsi in qualcosa del genere:

Terminale 1: Laravel
Terminale 2: Vite
Terminale 3: Queue Worker
Terminale 4: Horizon
Terminale 5: Reverb
Terminale 6: quel comando specifico del progetto che bisogna ricordarsi ogni volta

Non è un problema enorme.

È semplicemente una di quelle piccole frizioni che si ripetono ogni giorno.

Ed è proprio da questo tipo di problemi che spesso nascono gli strumenti più utili.

---

Il problema non è il terminale

Ci piace lavorare da terminale.

LaraDeck non nasce per sostituirlo.

Il problema è dover ricordare e gestire continuamente gli stessi processi, soprattutto quando si lavora contemporaneamente su più applicazioni Laravel.

Durante la giornata capita continuamente di chiedersi:

• Ho avviato il queue worker?
• Vite sta girando?
• Questo progetto usa Horizon oppure queue:work?
• Reverb è già attivo?
• Quale terminale appartiene a questo progetto?
• Su quale porta sta girando l’applicazione?
• Devo avviare Sail?
• Qual era il comando custom necessario per questo progetto?

Nessuna di queste operazioni è realmente complessa.

Ma ognuna richiede un piccolo cambio di contesto.

E quando i cambi di contesto si ripetono continuamente, iniziano a pesare.

L’obiettivo di LaraDeck è eliminare proprio questa frizione.

---

E se un progetto Laravel si potesse gestire come una normale app Mac?

Da questa domanda è nata l’idea di LaraDeck.

Volevamo uno strumento che fosse realmente integrato con macOS.

Non un altro pannello web.

Non una nuova astrazione sopra Docker.

Non un sostituto del terminale.

Ma una piccola applicazione nativa, veloce e sempre disponibile, capace di capire cosa serve a un progetto Laravel e mostrarlo in maniera semplice.

Apri LaraDeck.

Selezioni il progetto.

Vedi immediatamente quali servizi sono disponibili e quali stanno girando.

Avvii ciò che ti serve.

Fermi ciò che non ti serve.

Tutto qui.

Qualcosa di simile a:

My Laravel Project

● Laravel Server
● Vite
● Queue Worker
● Horizon
○ Reverb

[ Start All ]

Non dovrebbe essere lo sviluppatore a ricordarsi ogni volta che un progetto usa Horizon mentre un altro utilizza un semplice queue worker.

Il progetto contiene già queste informazioni.

LaraDeck dovrebbe essere in grado di scoprirle.

---

Convention over configuration, anche nell’ambiente di sviluppo

Uno degli aspetti che abbiamo sempre apprezzato di Laravel è il principio di convention over configuration.

Laravel sa dove trovare i controller.

Sa dove sono le migration.

Conosce la struttura delle queue, degli eventi, dei command e della configurazione.

Abbiamo voluto applicare lo stesso principio a LaraDeck.

Quando LaraDeck incontra un progetto dovrebbe cercare di comprenderlo automaticamente.

È presente il file artisan?

Probabilmente è un progetto Laravel.

È installato Laravel Sail?

LaraDeck può proporre di utilizzarlo.

È presente Horizon?

Può mostrare Horizon tra i processi disponibili.

Il progetto utilizza Reverb?

Può rilevarlo.

È presente una configurazione Vite?

Può proporre il processo frontend.

E per tutto ciò che non può essere dedotto automaticamente, sarà sempre possibile definire dei comandi personalizzati.

Il principio alla base è semplice:

Aggiungi il progetto, non configurare ogni singolo processo.

Quando possibile, deve essere LaraDeck a fare il resto.

---

Un control center, non un nuovo stack di sviluppo

Questa distinzione per noi è importante.

Esistono già strumenti eccellenti per gestire un ambiente di sviluppo PHP e Laravel su macOS.

Laravel Herd semplifica enormemente la gestione di PHP e dei siti locali.

DBngin rende molto semplice eseguire database come MySQL, PostgreSQL e Redis.

Docker e Laravel Sail risolvono un’altra serie di esigenze.

LaraDeck non vuole sostituire questi strumenti.

Al contrario, l’idea è riuscire sempre di più a convivere e integrarsi con loro.

LaraDeck lavora su un livello differente: quello del progetto e dei processi utilizzati durante lo sviluppo.

Possiamo immaginare lo stack in questo modo:

macOS

    ↓

Herd / Valet / PHP / Docker
    ↓

MySQL / PostgreSQL / Redis
    ↓

Progetto Laravel
    ↓

Laravel Server
Vite
Queue
Horizon
Reverb
Scheduler
Processi custom

              ↑
           LaraDeck

È proprio nell’ultimo livello che LaraDeck vuole intervenire.

Quello in cui, concretamente, passiamo buona parte della nostra giornata di sviluppo.

---

Perché un’app nativa macOS

Fin dalle prime prove abbiamo deciso che LaraDeck sarebbe dovuta essere una vera applicazione nativa per macOS.

Sarebbe stato sicuramente più semplice realizzare un’applicazione multipiattaforma utilizzando tecnologie web.

Ma LaraDeck è il tipo di utility che immaginiamo sempre aperta durante tutta la giornata lavorativa.

E per questo tipo di software i dettagli contano.

Contano i tempi di avvio.

Conta il consumo di memoria.

Contano le scorciatoie da tastiera.

Conta l’integrazione con la menu bar.

Contano le notifiche.

Conta il comportamento delle finestre.

E conta quella sensazione difficile da definire che distingue un’applicazione realmente integrata con macOS da una semplice interfaccia web inserita all’interno di una finestra desktop.

Vogliamo che LaraDeck sembri appartenere al Mac.

Esattamente come gli altri strumenti che utilizziamo quotidianamente.

---

Open source fin dal primo giorno

LaraDeck nasce anche come progetto open source.

Non è una decisione arrivata successivamente.

Laravel stesso esiste grazie a un ecosistema open source straordinario, e sappiamo bene quanto possano essere personali le abitudini di sviluppo.

Ogni developer lavora in modo leggermente diverso.

Ogni progetto Laravel ha le proprie particolarità.

Pretendere di immaginare da soli tutti i possibili workflow sarebbe impossibile.

Aprire il progetto permette invece alla community di:

• capire esattamente cosa fa LaraDeck;
• segnalare problemi;
• suggerire nuove integrazioni;
• proporre nuovi workflow;
• contribuire direttamente allo sviluppo;
• adattare LaraDeck a scenari che oggi non abbiamo ancora immaginato.

Ma soprattutto ci aiuta a mantenere chiaro l’obiettivo del progetto.

Non vogliamo costruire un nuovo IDE.

Non vogliamo creare un enorme ambiente di sviluppo che faccia qualsiasi cosa.

Vogliamo realizzare un piccolo strumento capace di risolvere molto bene un problema preciso.

---

Dove vogliamo arrivare

Le prime versioni di LaraDeck sono volutamente semplici.

L’obiettivo iniziale è:

• individuare automaticamente i progetti Laravel;
• capire quali servizi utilizzano;
• avviare e fermare i relativi processi;
• mostrare immediatamente cosa è attivo;
• semplificare l’accesso agli strumenti utilizzati ogni giorno.

Da qui, però, le possibilità sono molte.

Tra le funzionalità che stiamo esplorando ci sono:

• rilevamento automatico di Laravel Sail;
• gestione di Horizon e queue worker;
• supporto a Laravel Reverb;
• processi scheduler;
• comandi personalizzati;
• visualizzazione dei log;
• controlli dalla menu bar;
• informazioni sullo stato del progetto;
• rilevamento dei database gestiti tramite DBngin;
• integrazione con Laravel Herd;
• apertura rapida del progetto nell’IDE;
• apertura del terminale direttamente nella directory del progetto;
• apertura dell’applicazione nel browser;
• informazioni sull’ambiente PHP;
• avvio di tutti i servizi con un singolo click;
• ripristino automatico della propria sessione di sviluppo.

L’obiettivo, nel tempo, è rendere l’apertura di LaraDeck al mattino equivalente all’apertura del proprio workspace.

Selezionare il progetto.

Premere Start.

E iniziare a sviluppare.

---

Per adesso è ancora un esperimento

LaraDeck è ancora molto giovane.

Ed è esattamente così che vogliamo che sia.

Invece di passare mesi a decidere cosa potrebbe servire agli sviluppatori Laravel, preferiamo iniziare a metterlo nelle loro mani e raccogliere feedback reali.

Ci interessa capire:

Quali processi avviate normalmente?

Utilizzate Sail?

Herd?

Valet?

Horizon?

Più queue worker contemporaneamente?

Reverb?

Docker?

Vorresti che LaraDeck avviasse automaticamente tutto l’ambiente?

Quali informazioni sarebbero davvero utili da vedere a colpo d’occhio?

E soprattutto:

cosa non dovrebbe mai cercare di diventare LaraDeck?

In questa fase, le risposte a queste domande sono probabilmente più importanti di molte nuove funzionalità.

---

Cerchiamo beta tester

Stiamo quindi cercando sviluppatori Laravel che lavorano su macOS e abbiano voglia di provare LaraDeck sui propri progetti reali.

Non cerchiamo tester di un prodotto già perfetto.

Cerchiamo persone disposte a installare una versione ancora giovane, provarla nel proprio workflow quotidiano, trovare casi limite e dirci senza troppi giri di parole:

“Questa cosa non funziona.”

Oppure:

“Qui la farei completamente diversa.”

È esattamente il tipo di feedback di cui abbiamo bisogno.

Se lavori con Laravel su macOS e anche tu passi parte della giornata a saltare tra terminali, queue, Vite, Horizon, Sail e altri processi, ci farebbe piacere sapere cosa ne pensi.

👉 https://laradeck.brokenice.it

LaraDeck è open source.

E siamo soltanto all’inizio.

Meno terminali da gestire. Più tempo per sviluppare.