C’è un motivo per cui i migliori script Python vengono lanciati alle tre del mattino, mentre noi cerchiamo disperatamente di capire perché quel modulo non si importa della nostra sandbox.

Se siete come me, avete passato ore a configurare task scheduler, cron job su server Linux dimenticati o script che si interrompono perché qualcuno ha resettato la sessione SSH. La buona notizia? Sembra che Kimi abbia deciso di risolvere questo dramma con il lancio di «Kimi Work». Non è la solita supercazzola di marketing per vendere abbonamenti cloud, ma un tentativo di integrare un motore Cron robusto direttamente nel workflow degli LLM Agent.

In parole povere: l’idea è quella di far girare tutto in background, 24/7. Immaginate di impostare un agente che, ogni mattina alle 07:00, si sveglia, mastica i dati del vostro database, analizza i log e vi prepara un briefing pronto per la colazione. Oppure, se siete dei veri maker che amano processare dataset massicci, potete lanciare script Python che si auto-eseguono a mezzanotte senza che dobbiate restare svegli a fissare una barra di caricamento.

Il concetto di «Set It & Forget It» è affascinante, ma sappiamo tutti che nel mondo tech il «forget it» spesso si traduce in un alert critico che ti sveglia durante una serata di gaming. Però, l’integrazione di un motore Cron all’interno di un ecosistema di agenti è una mossa intelligente. Automatizzare non significa solo far girare un comando, ma dare una logica temporale a entità che possono effettivamente «ragionare» sui task.

Naturalmente, c’è sempre il solito tema: tutto questo avviene dentro il loro ecosistema. E noi sappiamo bene che quando i processi diventano troppo integrati e automatizzati, uscire da quel perimetro diventa un’impresa degna di un film di spionaggio della Guerra Fredda. Se il vostro workflow diventa dipendente da un motore interno, la libertà di migrare tutto su un server self-hosted in garage diventa un po’ più complicata.

Detto questo, l’idea di avere un orchestratore che non richiede che io stia lì a fare da babysitter ai miei script è decisamente allettante. Se riusciranno a rendere la gestione dei task fluida e non troppo ancorata ai loro standard proprietari, potrebbe essere lo strumento definitivo per chi vuole automatizzare la parte noiosa del lavoro per concentrarsi su quella divertente: rompere le cose e cercare di ripararle.

Source: Kimi Work

Quanto tempo abbiamo perso a sentirci dei geni dell’informatica solo perché siamo riusciti a configurare un file .dotfile per tre ore, ottenendo come risultato un terminale che finalmente ha il colore che ci piaceva?

C’è una tendenza pericolosa che attraversa le community di hacker e maker: l’idea che se un tool è difficile, frustrante e richiede macro assurde per fare una semplice operazione di refactoring, allora è «potente». È un po’ come se andassimo in pizzeria e dicessimo: «Questa pizza è fantastica perché per mangiarla devo prima smontare il forno e rimetterlo insieme». No, amici miei, quella non è efficienza, è solo un maledetto puzzle game che stiamo pagando con il nostro tempo.

Recentemente è uscito un pezzo che scuote un po’ le fondamenta del nostro ego digitale. Il punto è semplice, ma brutale: un buon tool deve essere invisibile. Quando sei nel flow, l’editor di testo, la shell o il debugger non dovrebbero essere protagonisti della scena; dovrebbero essere come l’aria che respiri. Se ti accorgi che l’editor esiste perché devi combattere contro un limite strutturale, allora quel tool ti sta interrompendo, non ti sta aiutando.

Il problema è che molti di noi hanno trasformato la scelta del software in una questione di identità tribale. Usare Vim o Emacs non è solo una scelta tecnica, è un segnale di status: «Sono un vero hacker perché so gestire questa complessità». È un loop tossico. Vendiamo i difetti dei nostri strumenti preferiti come se fossero feature, spacciando la fatica per competenza. Ma la verità è che la produttività si misura con il tempo di clock, non con quanto ti sei sentito un eroe mentre cercavi di far funzionare un plugin che ha rotto tutto l’ultimo aggiornamento.

E non parliamo poi della mania per la configurabilità estrema che spesso maschera una pigrizia del designer. Dire che un software è «altamente configurabile» è spesso una scusa elegante per dire: «Non ho voglia di prendere decisioni, quindi ti lascio tutto il lavoro sporco». Un buon toolmaker dovrebbe offrirci dei default eccellenti, pronti all’uso, lasciando le ‘escape hatch’ (le vie d’uscita) solo per chi ha esigenze davvero particolari.

Non sto dicendo di abbandonare i terminali o di tornare a usare Notepad. Usate quello che preferite, ma fate un test onesto: il vostro tool scompare mentre lavorate o è un ostacolo che cercate di superare con l’astuzia? Se la risposta è la seconda, forse non siete dei super-programmatori, siete solo vittima di un ottimo storytelling legato a un software mediocre. La vera maestria non sta nel padroneggiare lo strumento difficile, ma nel raggiungere il risultato senza nemmeno accorgersi che lo strumento esiste.

Source: Good Tools Are Invisible

Se la tua cronologia di Git somiglia a un museo di file temporanei, log spazzatura e configurazioni personali che non dovrebbero mai vedere la luce di un commit, non sei solo. Siamo tutti sulla stessa barca (o meglio, nello stesso container Docker mal configurato).

Per anni abbiamo agito come se il file .gitignore fosse l’unica linea di difesa tra noi e il disastro. Ma la verità è che Git offre delle scorciatoie molto più eleganti per ignorare tutto ciò che è inutile, senza dover sporcare il repository con regole che valgono solo sulla tua macchina. È un po’ come quando in un film sci-fi il protagonista trova un comando segreto per bypassare la sicurezza del mainframe senza lasciare tracce nel log.

Il primo livello, quello che conosciamo tutti, è il classico .gitignore. È il colpo pesante, quello che viene pushato nel repo e che tutti vedono. Va bene per i file che *tutti* devono ignorare, tipo la cartella ‘node_modules’ o i file di build. Ma se devi ignorare quel tuo file ‘appunti_segreti_e_piani_per_la_conquista_del_mondo.txt’ che usi solo tu per gestire il tuo workflow, metterlo nel .gitignore è un suicidio professionale.

Qui entra in gioco il secondo livello: .git/info/exclude. Questo file vive dentro la cartella .git del tuo repository locale e, la cosa fondamentale, non viene mai pushato. È il posto perfetto per le tue personalizzazioni ‘sporche’ che restano confinate solo al tuo progetto, senza infastidire i tuoi colleghi o contaminare la repo ufficiale. È il rifugio sicuro per chi vuole customizzare il proprio ambiente senza lasciare impronte digitali nel codice condiviso.

E se proprio vuoi fare il pro e pulire l’intera tua workstation, esiste il terzo livello: il file di ignore globale. Se usi macOS, ad esempio, puoi dire a Git di ignorare per sempre i fastidiosi .DS_Store in ogni singolo progetto che toccherai, senza dover scrivere una riga di codice in ogni repo. Basta configurare un file in ~/.config/git/ignore (o dove preferisci) e Git lo applicherà come un filtro universale su tutta la tua macchina.

La parte più divertente? Se un giorno ti svegli nel caos e non capisci più perché un file non viene tracciato, esiste il comando ‘git check-ignore -v’. Ti dice esattamente quale file, in quale riga e in quale percorso sta facendo da guardiano. Niente più misteri degni di un episodio di Black Mirror.

In un mondo dove tutto cerca di essere tracciato, monitorato e analizzato, imparare a usare questi livelli di esclusione è un piccolo atto di resistenza tecnica. Meno rumore nel repo, meno fuffa nei commit, più focus sul codice che conta davvero.

Source: .gitignore Isn't the only way to ignore files in Git

Chi ha bisogno di un MacBook Pro da duemila euro quando puoi avere un vecchio laptop che prende polvere nel cassetto e una dose massiccia di determinazione?

Siamo onesti: la nostra capacità di concentrazione è ormai ridotta a quella di un pesce rosso sotto caffeina. Ogni volta che apriamo un browser per cercare una reference su Stack Overflow, finiamo in un loop infinito di video su YouTube o distrazioni social. Ma c’è un modo per hackerare il proprio workflow e creare una bolla di focus impenetrabile. È quello che ha fatto recentemente una sviluppatrice con il suo ‘writerdeck’.

L’idea è brutale nella sua semplicità: installare una versione di Debian totalmente priva di desktop environment. Niente GNOME, niente KDE, niente animazioni fluide che servono solo a far consumare batteria. Solo una console nuda e cruda. Ma non è solo ‘minimalismo per il gusto di essere minimalisti’ (che a volte è solo una scusa per farsi venire il mal di testa con la configurazione dei driver); è una vera e propria ingegneria del focus.

Il setup che ha descritto è un piccolo capolavoro di smanettamento intelligente. Ha usato kmscon per gestire font custom e una palette di colori più ricca del solito TTY, trasformando la console in qualcosa di esteticamente accettabile per i nostri occhi abituati a Blender o Godot. Ha poi stratificato tmux per gestire i vari pannelli, con una barra di stato che monitora tutto, dai processi alla batteria. E il cuore pulsante? Neovim, con il plugin vim-wiki per gestire tutto il sapere personale in un unico posto, e Syncthing per sincronizzare i file senza dover pregare un cloud proprietario.

Per noi che amiamo smontare hardware e scrivere codice, questo è il tipo di approccio che ci fa battere il cuore. È l’essenza del maker: prendere qualcosa di obsoleto, spogliarlo del superfluo e dargli una nuova, specifica funzione. È una sfida al modello ‘compra l’ultimo modello con l’AI integrata che non sa fare altro che spiare i tuoi dati’.

Certo, non è per tutti. Se la vostra idea di scrittura include guardare GIF animate o fare ricerca su Wikipedia con mille tab aperti, questo setup vi farà impazzire dopo dieci minuti. È un setup ostico, quasi un esercizio di ascetismo digitale. Ma per chi cerca il flow puro, dove l’unico input è il tasto e l’unico output è il testo, trasformare un vecchio laptop in una workstation terminal-only è un progetto che merita un posto in cima alla lista delle ‘cose da provare questo weekend’.

In un mondo di software sempre più pesante, opaco e pieno di telemetria, tornare alla console è un atto di resistenza. E onestamente? È anche decisamente figo.

Source: Time to talk about my writerdeck

Se c’è una cosa che fa impazzire chiunque abbia mai passato una notte insonne a risolvere un bug di dipendenza, è il ciclo infinito di Pull Request. Quelle volte che devi fare dieci piccole correzioni, ognuna un PR separato, e poi devi stare a guardare che il sistema le accetti una dopo l’altra, come se stessi aspettando il boot di un vecchissimo sistema operativo.

Ecco, GitHub, in un colpo di genio (o forse solo in un colpo di marketing), ha lanciato Stacked PRs. In pratica, ti permette di prendere un gruppo di PR collegate, quelle che rappresentano strati logici diversi di un cambiamento più grande, e di mergirle tutte insieme, in un unico, epico, «merge». Un click. Basta.

Non è una rivoluzione del genere che ti fa dimenticare il compilatore C++ o il debugger di IDA, ma per noi che viviamo respirando Git, è un miglioramento di workflow che sembra uscito direttamente da un manuale di Sci-Fi. Prima, ogni PR era un mini-evento, richiedeva revisioni singole, e ti faceva perdere tempo prezioso a fare i salti tra i vari thread di discussione.

Il bello di Stacked PRs è che non stai solo accorpando commit, stai accorpando *pensieri*. Ogni PR è vista come uno strato di cambiamento ben definito, che è stato rivisto indipendentemente, ma che arriva insieme come un unico pacchetto funzionale. È come passare da sistemare il motore pezzo per pezzo, a far scendere l’intera macchina dall’autotrappa in un unico, fluido movimento.

Per noi maker, hacker e chiunque abbia mai tentato di programmare un robot senza che sembri un incidente, questo è oro. Significa meno overhead mentale, meno PR da tenere d’occhio, e più tempo per passare al bello: smontare il prossimo hardware o scrivere quel microservizio che ci farà sentire dei veri maghi della programmazione.

Ovviamente, qui ci vuole un pizzico di scetticismo da veterano. Ogni volta che un gigante come GitHub introduce una feature che sembra risolvere un problema di workflow, mi chiedo sempre: «Quanto ci sta dietro? E cosa ci tolgono per farlo?» È un miglioramento, certo, ma non dimentichiamoci che stiamo sempre un passo più vicini al ‘vendor lock-in’ del nostro flusso di lavoro. Siamo dipendenti dalle loro API e dai loro pulsanti magici.

Detto questo, per chi lavora su progetti collaborativi grandi, dove la gestione delle dipendenze e delle revisioni è un incubo quotidiano, Stacked PRs è un salvagente. È un esempio perfetto di come l’ottimizzazione del processo possa essere altrettanto figa quanto l’algoritmo che stai costruendo. Quindi, se la vostra community sta lavorando a qualcosa di grosso, provatela. E se funziona, godetevi la sensazione di chiudere quel merge con un singolo, soddisfatto *clic*.

Adesso, se mi date scusa, devo tornare a smanettare con Blender. Ho una versione 3D di questo processo da rendere realtà.

Source: GitHub Stacked PRs

Ok, gente. Fermate i saldatori, e soprattutto, allontanatevi dal manuale di istruzioni del Dock di macOS.

Diciamocelo chiaro: macOS è un sistema operativo fantastico, ma il suo meccanismo di gestione delle finestre e il Dock, pur essendo iconici, sono stati progettati più per la *nostalgia* che per l’efficienza di un hacker che ha 17 finestre aperte e tre desktop di lavoro diversi. Ogni volta che devi passare da un’app all’altra, o saltare tra gli spazi, è un piccolo, irritante balletto di clic e animazioni.

È qui che arriva boringBar, il nuovo “dock replacement” che sta facendo parlare di sé in HN. A prima vista, sembra solo un bel gadget, ma se ci smontiamo un po’, è un pezzo di ingegneria di workflow che risolve problemi reali. L’idea di avere un unico punto di accesso che non solo mostra le app, ma anche gli *stato* di quelle app—con anteprime in thumbnail e badge di notifica—è oro colato per chiunque viva tra i monitor e le finestre.

Le feature sono un tripudio per chi ama il controllo: desktop switcher rapido, possibilità di raggruppare finestre per app, e la funzione di scroll per passare tra gli spazi. È tutto pensato per ridurre la frizione, quel piccolo attrito tra la tua intenzione e l’azione fisica del click. È il tipo di miglioramento che non ti accorgi di aver chiesto, ma senza il quale non riesci a tornare indietro.

Ma ora, veniamo al succo, quella parte che fa impallidire ogni maker o sviluppatore: le premesse tecniche e il business model.

Per far funzionare questa roba, boringBar richiede due autorizzazioni macOS: Accessibility e Screen Recording. Non è la cosa più strana che ci chiedano, ma è sempre un piccolo campanello d’allarme che ci fa pensare: ‘Ma cosa sta guardando esattamente?’. Il team ha fatto un ottimo lavoro nel rassicurare che lo Screen Recording è usato solo per i thumbnail, ma è un promemoria costante che anche i migliori strumenti di produttività si nutrono di permessi profondi del sistema operativo.

E poi arriviamo al coltello dalla due punte: la monetizzazione. Abbiamo il classico modello ‘Perpetual’ (paghi una volta, fai i conti) contrapposto al ‘Yearly’ (paghi ogni anno). È la battaglia eterna del software: la libertà del costo iniziale contro la sicurezza del servizio continuo. Per noi nerd, che amiamo le licenze open source o almeno i modelli a pagamento *unico*, il Perpetual è un attrazione, ma bisogna stare attenti a cosa significa ‘2 anni di supporto’ e cosa succede dopo.

In conclusione? Se sei un utente macOS che si sente soffocare tra il Dock e le limitazioni di Mission Control, boringBar è un’ottima soluzione tecnica. È l’ottimizzazione che ci piace tanto, quella che ci fa sentire più vicini al controllo del silicio. Solo ricorda che, anche se il software è figo, la parte più difficile rimane sempre negoziare con il sistema operativo e, soprattutto, con il portafoglio.

Source: Show HN: boringBar – a taskbar-style dock replacement for macOS