Proudly debugging the system since 1981

Tag: programmazione (Pagina 1 di 4)

Audio To Text arriva alla 1.0.0: ecco che cosa è cambiato

Dal post di fine agosto è successo parecchio. L’ultima volta vi raccontavo della versione 0.6.3 e dell’avvio del closed testing su Google Play; oggi Audio To Text (ex phone-whisper) è arrivato alla 1.0.0, una release stabile pronta per la fase di test. In questi mesi il lavoro è stato enorme, soprattutto su interfaccia e affidabilità. Vi riassumo i punti principali.

Un’interfaccia tutta nuova

La novità più visibile è la riscrittura completa dell’interfaccia con Jetpack Compose e Material 3. Fino a qualche mese fa la UI era costruita con le classiche View di Android, ora è tutta basata su Compose: tema chiaro/scuro che riusa la palette esistente, animazioni e componenti moderni.

A cambiare è anche la navigazione: al posto dei vecchi bottoni è arrivata una barra di navigazione fissa in basso con tre sezioni — Home, Catalogo e Maggiori informazioni — ognuna con la sua icona (Material Symbols Outlined). La voce attiva è in azzurro, le altre in grigio, e la barra resta sempre visibile. L’onboarding resta una schermata separata, senza barra, con il solo pulsante “Chiudi”.

Un dettaglio che in orizzontale faceva la differenza: nella schermata principale titolo e testo informativo restano fissi, mentre stato e modelli installati scorrono verticalmente. Ora anche con il telefono ruotato tutto funziona come deve.

Download che non si interrompono

Prima, se chiudevi il catalogo mentre uno scaricamento era in corso, il download si fermava. Ora i modelli si scaricano tramite un foreground service: la scaricamento continua in background anche dopo aver premuto Indietro, con una notifica che mostra il progresso. A fine installazione la lista dei modelli installati e il catalogo si aggiornano da soli. È stato anche corretto un bug che, premendo il tasto Indietro durante un download, poteva congelare l’app (ANR).

Catalogo modelli più ricco e gestibile

Il catalogo è cresciuto e ora è più pratico:

  • Nuovi modelli, tra cui Kroko Italiano, dedicato alla trascrizione dell’italiano, scaricato come file singoli direttamente da Hugging Face.
  • Rimozione dei modelli: i modelli installati si possono eliminare (con conferma) per liberare spazio; il modello attivo, se rimosso, viene riselezionato automaticamente con il primo installato rimasto.
  • Nomi più chiari: ogni modello indica la lingua di destinazione (es. “Whisper Base – English”, “Parakeet 0.6B – Multilanguage”).
  • Supporto per modelli compressi e non, e per fonti di download diverse.

Onboarding e piccoli grandi fix

Alla prima apertura ora compare una guida introduttiva con tre schermate scaricabili che spiegano come scaricare il modello, attendere l’installazione e trascrivere un messaggio; si può rivedere in qualsiasi momento dalla sezione “Maggiori informazioni”, dove i link GitHub e Issues sono tornati attivi e aprono correttamente il browser.

Sono stati sistemati anche il crash di Kroko al caricamento (era un modello streaming, ora caricato con il riconoscitore giusto) e il progresso di download per i modelli compressi, che prima saltava da 0% a 100% senza valori intermedi. Le icone del download e del cestino usano ora gli icon set Material Symbols, decisamente più pulite.

Piattaforma

Sotto il cofano: target SDK 36 (Android 16), supporto a tutti gli ABI (arm64, arm, x86, x86_64) per una compatibilità più ampia, e interfaccia multilingua italiano/inglese.

Changelog in breve (0.6.3 → 1.0.0)

  • v1.0.0 — Prima release stabile per il closed testing: consolida tutta la serie 0.9.x.
  • v0.9.x — Migrazione Jetpack Compose Material 3, barra di navigazione in basso, download in background (foreground service), fix ANR/auto-riselezione/link/scroll orizzontale, icone Material Symbols, fix Kroko, progresso download compressi, chiarezza catalogo, nuovi modelli (Kroko Italiano), onboarding e indicatori.
  • v0.8.x — Rimozione modelli installati, supporto a tutti gli ABI, promozioni al closed testing.
  • v0.7.0 — Promozione al closed testing.
  • v0.6.4–0.6.6 — Target SDK 36, schermata “Maggiori informazioni”, fix UI e contrasto.

Come provarla

La 1.0.0 è pronta per il closed testing su Google Play. Per partecipare basta iscriversi al gruppo dei tester (accesso libero, nessuna mail): https://groups.google.com/g/testers-community/ . Serve solo un dispositivo Android e, se trovi qualcosa che non va — crash, modelli che non si scaricano, traduzioni imprecise — segnalalo pure via Issues o nel gruppo.

La trascrizione resta completamente locale e on-device, con modelli sherpa-onnx: nessuna dipendenza dal cloud. Grazie a chi sta testando e continua a segnalare problemi: è ciò che rende l’app migliore.

Audio To Text in closed testing su Google Play

Con la versione 0.6.3 di Audio To Text (ex phone-whisper) è partita la fase di closed testing su Google Play. È il passaggio successivo dopo il rebrand e la rimozione delle funzionalità cloud raccontati nel post precedente.

Cos’è il closed testing

Google Play richiede una fase di test con un gruppo ristretto di utenti prima di poter aprire l’app al pubblico. È un passaggio utile anche a prescindere dall’obbligo: permette di verificare il funzionamento su dispositivi e versioni di Android diverse dalla mia, cosa che da solo non riesco a coprire.

L’app è visibile alla pagina Google Play di Audio To Text, ma per installarla in questa fase è necessario essere inseriti nella lista dei tester.

Come partecipare

Chi vuole provarla lo può fare iscrivendosi al gruppo dei tester su google group: https://groups.google.com/g/testers-community/ . Il gruppo è ad accesso libero e non manda nessuna mail. Non serve nessuna competenza particolare, solo un dispositivo Android e la disponibilità a segnalare eventuali problemi — crash, modelli che non si scaricano correttamente, traduzioni imprecise o altro.

Cosa trovare nell’app

La versione in test corrisponde a quella descritta nel post precedente: trascrizione locale con modelli sherpa-onnx, nessuna dipendenza cloud, interfaccia in italiano o inglese in base alla lingua del dispositivo.

Changelog

v0.6.3 (2026-08-27)

Da phone-whisper a Audio To Text: rebrand, local-only e UI più chiara

C’è stato un cambiamento importante: nasce Audio To Text

Ad aprile avevo raccontato la nascita di phone-whisper, l’app Android per trascrivere audio offline sul dispositivo usando sherpa-onnx (potete rileggere il post originale). Da allora il progetto è cresciuto, e con la versione 0.6.1 arriva un cambiamento che va oltre il semplice numero di release: l’app cambia nome e diventa Audio To Text.

Cosa cambia davvero

Il progetto nasceva già con un forte focus sulla privacy, ma manteneva un’integrazione opzionale con OpenAI per la trascrizione cloud e il post-processing del testo. Con la 0.6.0 questa parte è stata rimossa completamente: niente più chiamate cloud, niente API key da gestire, nessun dato che lascia il telefono. L’app oggi funziona esclusivamente con i modelli sherpa-onnx scaricati e installati in locale, il che significa anche una base di codice più semplice da mantenere — sono stati eliminati interi componenti come TranscriberClient, PostProcessor e WavWriter, insieme ai relativi test.

Questa scelta ha richiesto anche una riscrittura della privacy policy, per rimuovere ogni riferimento alla gestione delle chiavi API e alle modalità cloud che non esistono più.

Il rebrand: da phone-whisper a Audio To Text

Il nome phone-whisper aveva senso quando il progetto era ancora legato all’idea di Whisper e a un’integrazione cloud. Ora che l’app è diventata a tutti gli effetti uno strumento locale, ho deciso di rinominarla Audio To Text, un nome più diretto e descrittivo di quello che fa realmente. Il cambiamento non è solo estetico: il package dei sorgenti è stato spostato da com.kafkasl.phonewhisper a net.b0sh.audiotext, con la cronologia Git preservata grazie a un git mv mirato invece di una semplice riscrittura dei file.

Miglioramenti all’esperienza utente

Con la 0.6.0 e la 0.6.1 ho lavorato molto anche su come l’app comunica il proprio stato all’utente:

  • Durante l’installazione di un modello, ora viene mostrato il progresso di estrazione con numero di file completati e file corrente in lavorazione, così sai esattamente a che punto è il processo.
  • È stata aggiunta una sezione informativa sullo stato del modello nella schermata principale, per capire a colpo d’occhio se un modello è installato, pronto o ancora da scaricare.
  • Con la 0.6.1 arriva il supporto multilingua dell’interfaccia: l’app segue automaticamente la lingua del dispositivo tra inglese e italiano. Nome dell’app e nomi dei modelli restano invariati, per evitare ambiguità.

Perché questo cambiamento

L’obiettivo originale di phone-whisper era offrire una trascrizione privata e locale, ma la presenza di un’opzione cloud era in qualche modo in contrasto con quella filosofia. Rimuoverla non è stata solo una semplificazione tecnica: è stata anche una scelta di coerenza. Audio To Text è oggi un’app che fa una cosa sola, la fa completamente offline, e non ha bisogno di chiedere permessi di rete o gestire credenziali di terzi.

Changelog completo

v0.6.1 (2026-08-25)

  • Interfaccia multilingua: supporto inglese e italiano, in base alla lingua del dispositivo. Nome app e nomi modelli non tradotti.
  • Aggiornamento versione: 0.6.0 → 0.6.1 (versionCode 8).

v0.6.0 (2026-08-25)

  • Rimossa l’integrazione OpenAI: eliminate trascrizione cloud e post-processing. L’app supporta ora solo la trascrizione locale con modelli sherpa-onnx scaricati.
  • Rebrand: l’app è stata rinominata Audio To Text, package spostato in net.b0sh.audiotext.
  • Aggiornamento versione: 0.5.0 → 0.6.0 (versionCode 7).

Link utili

Audio To Text resta un progetto piccolo, ma ora è coerente al 100% con la sua promessa iniziale: nessun dato lascia il tuo telefono, mai.

Claude Code + Ollama/Qwen3.5

È possibile usare Claude Code con un modello locale — decisamente migliorato rispetto alle versioni precedenti — come Qwen3.5 per realizzare una piccola app Android senza scrivere una riga di codice?

L’impressione è che sì, si possa fare. Il modello configura tutto, scarica i framework, e dietro mio suggerimento si costruisce una lista di task da completare uno alla volta. Gli chiedo poi di riverificare il lavoro svolto, e in circa un quarto d’ora l’applicazione è pronta. In teoria.

Gli chiedo di riverificare tutto…

Il problema? Ha usato una versione del framework non ancora compatibile con Expo Go per i test diretti sul telefono. Da lì è partita una serie infinita di prompt di debug per abbassare la versione e aggiornare tutte le API interne, apparentemente diverse tra una release e l’altra.

Il risultato rimane comunque notevole, soprattutto considerando che tutto è generato da un modello da soli 9 miliardi di parametri, che gira su una scheda video nata per i videogiochi e tutt’altro che all’ultimo grido. Forse se non lo avessi forzato a passare dalla versione 55 alla 54 di React Native me la sarei cavata con meno litigi. Ma il limite vero sembra essere sempre lo stesso: la rifinitura del codice generato. O funziona subito, oppure ci vuole dieci volte il tempo che si impiegherebbe a scriverlo a mano.

Come piccolo aiuto ho agganciato Context7 come MCP server, per evitargli di allucinare le API dei framework — ma con successo solo parziale.

AI e Programmazione: Un Reality Check

L’evoluzione dell’Intelligenza Artificiale nella programmazione ha suscitato grandi aspettative, ma la realtà è più complessa. Questo articolo esamina i limiti dell’AI nel generare codice, i tentativi di integrare agenti di programmazione e le sfide nella collaborazione tra umani e macchine.

I Limiti dell’AI nella Scrittura del Codice

Il modello mentale del developer è la comprensione profonda dell’architettura, della data flow e delle relazioni tra componenti di un sistema. Quando l’AI genera codice, questa comprensione viene oscurata, rendendo difficile mantenere la coerenza del sistema. Ad esempio, nel progetto dei test branch-specifici, l’AI ha introdotto funzionalità senza considerare l’impatto sull’intero codice, creando incoerenze. La fiducia nei confronti dell’AI si basa sull’incapacità di autovalutazione: l’AI sovrastima le proprie capacità, come nel caso del test su URL, dove ha ignorato regole fondamentali. Questo mancanza di introspezione rende difficoltoso valutare la qualità del codice generato. La collaborazione futura tra umani e AI dipende da un equilibrio: l’AI può assistere in compiti specifici, ma non sostituirà la capacità umana di comprendere il contesto globale. La fiducia deve essere costruita attraverso revisioni umane e una consapevolezza delle limitazioni dell’AI.

La Perdita del Modello Mentale e la Fiducia

La scomparsa del modello mentale del developer nel codice generato da AI rappresenta un problema profondo nel processo di sviluppo. Quando l’AI produce code chunks senza comprendere l’architettura globale del sistema, nasconde la complessità che un developer umano avrebbe chiarito. Ad esempio, un’implementazione di un feature senza tenere conto delle interazioni con altri moduli crea un’astrazione che rende difficile il mantenimento e l’estensione del sistema. Questo è particolarmente critico in contesti con alta coesione e bassa coupling, dove una modifica apparentemente marginale può scatenare errori di difficile tracciabilità. La fiducia nei confronti dell’AI si basa su un’autovalutazione che essa non possiede. Mentre un developer umano riconosce i propri limiti e corregge errori, l’AI tende a sovrastimare la qualità del proprio lavoro, ignorando edge cases o pratiche consolidate. Questo porta a code che funzionano in modo superficiale ma mancano di robustezza. La collaborazione futura tra umani e AI dovrà quindi bilanciare l’automazione con la supervisione critica, garantendo che l’AI agisca come strumento di supporto, non come sostituto. Solo integrando la capacità di riflessione umana con la velocità dell’AI si potranno sfruttare al meglio le potenzialità di entrambi.

Conclusioni

L’AI non sostituirà i programmatori, ma agirà come strumento ausiliario. La collaborazione tra umani e macchine richiede una critica consapevole, con il focus su task specifici come testing e refactoring. Per ulteriori dettagli: Why agents DO NOT write most of our code – a reality check.

Ridondanza vs Dipendenze: Qual è il Peggior Nemico del Codice?

La tensione tra ridondanza e dipendenze definisce la qualità del codice. Mentre la ridondanza sembra un problema marginale, le dipendenze possono paralizzare un sistema. Questo articolo esplora come bilanciare questi due aspetti per creare software robusto e mantenibile.

La Tensione tra Ridondanza e Dipendenze

La progettazione di moduli sostenibili richiede un equilibrio tra ridondanza e dipendenze, privilegiando l’efficienza e la manutenibilità. Un modulo ben progettato dovrebbe avere un’interfaccia stabile, documentazione completa e proprietà chiare, evitando di diventare un ‘trash can’ di funzioni disordinate. L’interfaccia deve essere minimalista, limitata a ciò che è realmente necessario, per ridurre la complessità e prevenire errori. La documentazione, invece, è essenziale per garantire che altri sviluppatori possano integrare il modulo senza confusioni. Un esempio emblematico è il caso del parsing dei comandi riga: creare un modulo concreto per questa funzione, anziché dipendere da un ‘utilities module’ sovraccarico, riduce i rischi di instabilità. L’over-engineering, come in alcuni strumenti come XParam, può portare a soluzioni complesse e poco utilizzate, aumentando la manutenzione. La chiara proprietà di un modulo, con un unico responsabile, evita conflitti e garantisce un ciclo di vita prevedibile. La gestione delle dipendenze, quindi, non deve essere vista come un nemico, ma come un’opportunità per costruire sistemi robusti, purché guidata da principi di progettazione rigorosi.

Progettare Moduli Sostenibili

Un modulo sostenibile deve essere un’unità autonoma, con un’interfaccia compatta e stabile. Evita di esporre modelli complessi o classi sovraccariche, che aumentano la dipendenza e la fragilità. La documentazione completa è essenziale: senza essa, un modulo diventa inutilizzabile. Testa l’interfaccia pubblica, non singole funzioni, per garantire coerenza. La dimensione deve essere equilibrata: troppo grande è incontrollabile, troppo piccola genera overhead. Un chiaro proprietario assicura responsabilità e stabilità. La gestione della vita del modulo, con versioni ben definite, evita conflitti. Il rischio maggiore è il “trash can”: un modulo connesso a troppe dipendenze diventa un deposito di codice incoerente. L’esempio del parsing dei comandi riga mostra come un’over-engineering possa generare un’infrastruttura complessa e inutilizzata. Priorizza moduli piccoli, focalizzati, e evita di affidarti a soluzioni generali che non risolvono problemi specifici.

Conclusioni

La ridondanza è meno rischiosa delle dipendenze, ma entrambe richiedono attenzione. Per sviluppare software di alta qualità, è essenziale comprendere i trade-off tra questi due elementi. Scopri di più.

L’AI e il Futuro dei Junior Developer

In un’epoca in cui l’intelligenza artificiale sta rivoluzionando il mondo del lavoro, il ruolo dei junior developer si sta trasformando. AWS CEO Matt Garman ha espresso la sua visione su come l’AI possa integrarsi con le competenze umane, piuttosto che sostituirle.

L’AI e la sua applicazione nel programming

Nonostante l’AI possa semplificare alcune attività ripetitive, come la generazione di codice o l’ottimizzazione del debugging, non rappresenta una minaccia per i programmatori inesperti. Al contrario, offre loro strumenti potenti per imparare più velocemente e sviluppare competenze avanzate. I junior developer possono sfruttare l’AI per automatizzare compiti che richiederebbero tempo e pazienza, concentrando quindi le loro energie su aspetti più creativi e strategici del coding.

Con l’AI a disposizione, i junior developer possono ricevere feedback immediati durante lo sviluppo del software, migliorare la loro capacità di risolvere problemi complessi e affinare le loro abilità di pensiero critico. Questo non solo accelera il loro apprendimento, ma li prepara a svolgere ruoli più avanzati in futuro. Inoltre, l’AI può fungere da strumento di supporto per i junior developer, guidandoli attraverso processi di sviluppo complessi e aiutandoli a comprendere meglio i concetti di programmazione.

L’evoluzione del ruolo del junior developer nel contesto dell’AI richiede una visione proattiva: imparare a utilizzare queste tecnologie non come sostituti, ma come alleati. Questo approccio non solo rafforza il loro valore nel mercato del lavoro, ma li posiziona come attori chiave nell’innovazione tecnologica futura.

Il ruolo dei junior developer nel futuro del lavoro

Il ruolo dei junior developer nel futuro del lavoro è un tema cruciale in un contesto in cui l’intelligenza artificiale sta trasformando il mondo del programming. Matt Garman ha sottolineato che i junior developer non devono essere visti come una risorsa da sostituire con l’AI, ma come una opportunità di investimento per le aziende. I junior developer, infatti, sono i meno costosi e i più adattabili alle nuove tecnologie, rendendoli un elemento chiave per il successo delle organizzazioni.

Il loro ruolo non è solo di apprendere le competenze tecniche, ma anche di sviluppare abilità come il pensiero critico, la creatività e la capacità di risolvere problemi complessi. Queste competenze saranno sempre più importanti in un mondo in cui l’AI diventa un alleato, non un sostituto. I junior developer possono sfruttare gli strumenti AI per migliorare la loro efficienza e la loro produttività, senza perdere la capacità di pensare in modo autonomo e innovativo.

L’AI non eliminerà il ruolo dei junior developer, ma lo trasformerà. I programmatori del futuro non saranno semplici codificatori, ma problem-solver e gestori di agenti AI. Questo richiederà una continua formazione e un’adattabilità ai nuovi strumenti e alle nuove tecnologie. I junior developer dovranno imparare a utilizzare l’AI come un supporto per il loro lavoro, piuttosto che come una sostituzione.

Il futuro del lavoro per i junior developer è quindi un’opportunità, non una minaccia. Con l’adeguata formazione e l’uso intelligente dell’AI, i junior developer potranno diventare sviluppatori più efficienti, creativi e adatti alle esigenze del mercato del lavoro in evoluzione.

L’evoluzione del ruolo del developer

In questo capitolo, affronteremo l’evoluzione del ruolo del developer in un mondo dominato dall’AI. Matt Garman ha sottolineato che i programmatori non saranno sostituiti, ma il loro lavoro si trasformerà. Questo capitolo analizzerà come i developer passeranno da semplici codificatori a problem-solver e gestori di agenti AI. Verranno esaminate le nuove competenze necessarie per i developer del futuro, tra cui la capacità di prendere decisioni critiche, risolvere problemi complessi e gestire strumenti AI avanzati.

Garman ha sottolineato che il ruolo del developer non si limiterà a scrivere codice, ma si estenderà a comprendere e gestire le soluzioni AI. Questo richiederà una forte capacità di adattamento e una visione strategica per identificare quando e come l’AI può essere utilizzata per migliorare la produttività. I developer del futuro dovranno anche imparare a lavorare in sinergia con gli strumenti AI, interpretando i risultati e correggendo eventuali errori.

Inoltre, Garman ha sottolineato che l’AI non eliminerà il lavoro, ma lo trasformerà. I developer dovranno evolvere le loro competenze per rimanere rilevanti nel mercato del lavoro. Questo richiederà un impegno costante nell’apprendimento continuo e nell’adattamento a nuove tecnologie. Il ruolo del developer si trasformerà in un ruolo più creativo e strategico, dove il pensiero critico e la capacità di decisione saranno fondamentali.

Questo capitolo conclude che l’AI non eliminerà il ruolo del developer, ma lo trasformerà in una figura più versatile e strategica. I developer del futuro saranno chiamati a sfruttare l’AI come strumento di supporto, non come sostituzione, per raggiungere obiettivi più complessi e innovativi. Questo richiederà una combinazione di competenze tecniche, creative e strategiche, che renderanno i developer sempre più indispensabili nel mondo del lavoro.

L’importanza delle competenze umane nell’era dell’AI

L’evoluzione del ruolo del developer non è l’unica trasformazione in atto nell’era dell’intelligenza artificiale. I junior developer, in particolare, stanno assumendo un ruolo sempre più centrale nel mondo del lavoro tecnologico. Nonostante l’AI possa semplificare molte attività di programmazione, come la scrittura di codice ripetitivo, è chiaro che le competenze umane restano irrinunciabili. I junior developer, pur essendo alle prime armi, rappresentano una risorsa preziosa grazie alla loro capacità di apprendimento rapido e alla loro adattabilità ai nuovi strumenti e tecnologie.

Garman ha sottolineato che i junior developer non sono solo il futuro della programmazione, ma anche un’opportunità per le aziende di investire in talenti emergenti. Questi giovani professionisti possono imparare a lavorare in sinergia con l’AI, utilizzandola come strumento di supporto per migliorare la produttività e la qualità del lavoro. Inoltre, le capacità umane, come la creatività, la capacità di risolvere problemi complessi e il pensiero critico, sono fondamentali per guidare l’AI e massimizzare il suo potenziale.

I junior developer, quindi, non devono temere di essere sostituiti dall’AI, ma anzi, devono imparare a integrarla nel loro lavoro. Questo richiede una formazione continua e l’acquisizione di nuove competenze, come la gestione di strumenti AI avanzati e la capacità di prendere decisioni etiche e creative. Solo chi si adatta a questa nuova realtà potrà prosperare nel mercato del lavoro del futuro.

Conclusioni

L’AI non eliminerà i lavori, ma li trasformerà. I junior developer hanno un ruolo cruciale nel futuro del programming, e l’adattamento a nuove tecnologie sarà la chiave per successo e crescita professionale.

Questo post e’ realizzato tramite intelligenza artificiale basandosi su questo articolo: AWS CEO Says Replacing Junior Developers with AI Is the Dumbest Thing He’s Ever Heard

Il problema non è la velocità, ma il caos

Il tema non mi è nuovo, aumento di complessità, stack che diventano troppo profondi, impossibilità di conoscere tutto, almeno ad un livello di efficienza lavorativa in tempi accettabili e conseguente frustrazione, frammentazione dei framework, dei linguaggi e delle metodologie.

Sono incappato in una riflessione e conseguente proposta/lancio di un software per risolvere il problema dello sviluppo software (sembra un gioco di parole).

Le riflessioni sono interessanti.

“Every team’s setup is a unique snowflake. Even within the same programming language ecosystem, different teams will set up their dev process completely differently. Completely different build, test, packaging logic. Completely different runtime versions. Completely different eng culture. So on and so forth. This craziness is now the norm.”

“You can’t have strong innovation without freedom. You can’t have high-quality engineering and security without standardization.”

https://earthly.dev/blog/lunar-launch

Che poi la soluzione passi attraverso una verifica automatica ho qualche dubbio.

Gli sviluppatori junior vanno in burn-out prima di diventare senior?

Credo ci siano una serie di condizioni che spingono verso questa fine:

  • L’ossesione per la ricerca del nuovo
  • La facilita’ nel trovare soluzioni pronte senza necessita di apprendere
  • La tendenza a ridurre il tempo in cui si riesce a rimanere attenti e focalizzati

Segnalo questo articolo che tratta due di questi tre argomenti.

Why Junior Developers Are Burning Out Before They Bloom: Surviving Tech’s Obsession With ‘New’

Un estratto:

Tattica 2: Il gioco del “Perché?”
La prossima volta che utilizzi una funzionalità di un framework, chiediti:

  • “Quale problema risolve questa funzionalità?”
  • “Come implementerei questa funzionalità senza il framework?”
  • “Quali sono i compromessi in termini di prestazioni/memoria?”

Plugin gradle per la migrazione da javax a jakarta

Il plugin si trova qua : https://plugins.gradle.org/plugin/com.netflix.nebula.jakartaee-migration

La spiegazione su cosa puo fare e come si usa qua : https://github.com/nebula-plugins/gradle-jakartaee-migration-plugin

Lo scenario in cui l’ho utilizzato e’ quando si devono usare due librerie o framework, una con dipendenze “vecchie” sotto javax e una con dipendenze “nuove” sotto jakarta su un application server “nuovo”.

Il plugin aggiorna automaticamente le dipendenze vecchie, al momento della compilazione, rendendo tutto funzionante e interoperabile.

Un sentito ringraziamento a chi ha reso necessario il cambio di nome.

« Articoli meno recenti

© 2026 b0sh.net

Tema di Anders NorenSu ↑