Sette app in pochi giorni

A inizio ottobre uno sviluppatore di Atlanta, Brandon Thomas, ha pubblicato ArtCraft: sette applicazioni open source che rifanno Photoshop, Lightroom, Illustrator, Premiere e le altre della suite Adobe. Scritte in Rust, con Claude Opus 5.5, rilasciate con licenza MIT o Apache 2.0. Qualche giorno dopo sono arrivati anche i cloni di Word, Excel e PowerPoint.

In otto giorni i repository hanno superato le 42.000 stelle su GitHub. Il clone di Photoshop da solo ne aveva più di 23.000, insieme a 447 issue aperte.

La reazione è stata quella che vi immaginate. Sui social e su Reddit si legge che il software proprietario è finito, che Adobe ha i giorni contati, che finalmente l’open source si riprende quello che le Big Tech gli hanno preso. Uno dei fondatori di ArtCraft l’ha chiamato una specie di karma cosmico. Intanto tra i repository più in tendenza su GitHub è finito uno strumento che promette di far smontare a un agente qualsiasi applicazione.

Capisco l’entusiasmo. Chi ha pagato per anni un abbonamento Adobe, con penali di disdetta e il cloud obbligatorio, ha più di un motivo per godersi il momento. Però da tech lead, e da persona che il software lo costruisce per i clienti, sento il bisogno di frenare un attimo. Ci sono due domande che in questo coro non sento fare.

L’open source vive se qualcuno ci investe

Sia chiaro: l’open source è uno dei motori di innovazione più potenti che abbiamo. Linux, PostgreSQL, Kubernetes, gran parte dello stack su cui lavoro ogni giorno. Nessuno di noi tornerebbe indietro.

Ma questi progetti non sono nati dal nulla e non stanno in piedi da soli. Dietro Linux ci sono aziende che pagano migliaia di sviluppatori. Dietro Kubernetes c’è stato Google, e poi una fondazione finanziata da chi su Kubernetes ci guadagna. L’open source che dura è quasi sempre quello attorno a cui qualcuno ha costruito un modello economico.

Quando quel modello si rompe, succede quello che abbiamo visto con Elastic, Redis, HashiCorp. Aziende che avevano scelto l’open source hanno cambiato licenza, perché altri prendevano il loro lavoro e lo rivendevano senza restituire nulla. Ogni volta la comunità si è indignata. Ogni volta il problema era lo stesso: chi investe deve poter recuperare l’investimento.

C’è poi l’altro lato, quello di chi il software lo adotta. Un’azienda che sceglie uno strumento non compra solo funzionalità. Compra la ragionevole certezza che tra tre anni esisterà ancora, che le vulnerabilità verranno corrette, che i file di oggi si apriranno domani, che ci sarà qualcuno da chiamare quando qualcosa si rompe.

Un clone in alpha con centinaia di issue aperte e un team di quattro persone non offre niente di tutto questo. Può diventarlo, e glielo auguro. Ma oggi è un prototipo impressionante, non un’alternativa su cui un’azienda può basare il proprio lavoro. Chi lo confonde con una sostituzione pronta all’uso fa lo stesso errore di chi giudica un progetto dalla demo.

Se copiare costa una settimana, chi paga la ricerca?

La seconda domanda mi preoccupa di più. Photoshop non è diventato Photoshop in una settimana. Dietro ci sono più di trent’anni di tentativi, funzioni nate e abbandonate, migliaia di conversazioni con fotografi e designer per capire cosa serviva davvero. Quel lavoro è la parte costosa. Scrivere il codice, a un certo punto, è stato il meno.

Il reverse engineering, anche nella versione “clean-room” che ArtCraft rivendica, parte dal comportamento osservabile. Copia la risposta. Non rifà il percorso che ha portato a quella risposta, e non saprebbe rifarlo per la prossima.

Ora provate a mettervi nei panni di chi decide un budget di ricerca e sviluppo. Se una qualunque innovazione visibile può essere replicata in pochi giorni da un piccolo team con un modello, il ritorno di quell’investimento si accorcia drasticamente. La conseguenza razionale è investire meno, o chiudersi di più: brevetti, codice offuscato, funzioni spostate sul server dove nessuno le può osservare. Non a caso ad aprile Airbus ha annunciato l’acquisizione di un’azienda specializzata proprio nel proteggere il software dal reverse engineering fatto con l’AI.

Qui c’è un paradosso che i più entusiasti non vedono. I cloni copiano lo stato dell’arte di oggi. Se smettiamo di finanziare chi lo spinge avanti, tra cinque anni avremo ottimi cloni di software fermo al 2026. Il copiatore vive del lavoro dell’innovatore. Senza l’innovatore resta poco da copiare.

E vale la pena notare un dettaglio: nemmeno ArtCraft è beneficenza. Le app sono gratuite, ma il progetto si finanzia vendendo l’accesso al proprio modello di generazione di immagini, integrato nelle app stesse. L’open source, qui, è un canale di distribuzione. Legittimo, ma è un modello di business come gli altri.

Quello che non si copia guardando lo schermo

Non credo però che la ricerca sparisca. Credo che si sposti. Se le funzionalità visibili diventano facili da replicare, il valore si concentra su ciò che dall’esterno non si vede.

• La conoscenza del dominio. Sapere perché un fotografo lavora in un certo modo vale più dello strumento che lo asseconda.
• I dati e l’integrazione. Un prodotto inserito nei processi di un cliente, collegato ai suoi sistemi, non si sostituisce clonando l’interfaccia.
• L’affidabilità nel tempo. Aggiornamenti, sicurezza, compatibilità, supporto. Tutto quello che un’azienda compra quando sceglie un fornitore.
• La relazione. Chi conosce il cliente sa cosa costruire dopo. Il clone sa solo cosa è già stato costruito.

Il vantaggio competitivo basato sulle feature si sta comprimendo. Quello basato sulla fiducia e sulla continuità, secondo me, vale ogni giorno di più.

Cosa ne faccio io, da tech lead

Nel mio lavoro questa storia si traduce in due abitudini.

La prima riguarda le scelte tecnologiche. Quando il team propone uno strumento open source, la domanda non è “è gratis?” e nemmeno “funziona?”. È: chi lo manterrà tra tre anni, e con quali soldi? Se la risposta è “quattro persone entusiaste e tante stelle su GitHub”, ci va un piano B.

La seconda riguarda il valore di quello che facciamo per i clienti. Se un’interfaccia si può rifare in un pomeriggio con un modello, il nostro valore non è mai stato l’interfaccia. È capire il problema, mantenere il sistema, farlo evolvere quando il contesto cambia. È lo stesso discorso che faccio da mesi sul software generato con l’AI: scriverlo è diventato facile, tenerlo in piedi no.

L’open source resta una delle cose migliori che il nostro settore abbia prodotto. Proprio per questo merita più di un applauso ogni volta che qualcuno clona un prodotto famoso. Merita la domanda scomoda su chi pagherà la prossima idea, quella che oggi ancora nessuno può copiare.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Ogni generazione di sviluppatori senior ha pensato che quella dopo avesse la vita troppo facile. Chi ha imparato senza Stack Overflow ha guardato con sospetto chi ci è cresciuto dentro, e chi è cresciuto con Stack Overflow ha detto le stesse cose sui framework che nascondono tutto. Quasi sempre si sbagliavano: gli strumenti alzavano il livello del punto di partenza e la competenza si ricostruiva un po’ più in alto.

Prima di scrivere il resto di questo articolo mi sono chiesto se non stia facendo esattamente lo stesso errore. Non ne sono del tutto sicuro. Però credo che questa volta ci sia una differenza che vale la pena guardare da vicino, e non riguarda quanto è potente lo strumento: riguarda in quale punto del percorso toglie attrito.

Lo stesso strumento fa due cose opposte

Quando io uso l’intelligenza artificiale per generare un modulo, sto delegando qualcosa che so fare. Leggo il risultato e vedo subito se la gestione degli errori è messa dove serve, se quella query diventerà un problema con dieci volte i dati, se quella scelta mi vincola su una cosa che tra sei mesi dovrò cambiare. Non lo vedo perché sono più intelligente: lo vedo perché quelle tre cose le ho già sbagliate, e le ho pagate.

Quando un junior usa lo stesso strumento, sta delegando qualcosa che non ha mai fatto. Il risultato è identico. Quello che manca è tutto quello che succedeva prima che il risultato arrivasse.

È lì che si formava la competenza. Non nel codice finito, che era anzi la parte meno interessante, ma nelle quattro ore passate a capire perché non partiva, nel dead end preso e abbandonato, nell’errore letto tre volte prima di accorgersi che diceva esattamente cosa fare. Quelle ore sembravano tempo perso, e in senso stretto lo erano: producevano poco. Producevano però un modello mentale di come le cose si rompono, che è l’unica cosa che poi permette di guardare del codice e sentire che qualcosa non torna prima di sapere perché.

Quell’attrito non era un difetto del processo. Era il processo.

Il plateau invisibile

C’è un effetto collaterale meno ovvio e secondo me più insidioso.

Prima, il livello di un junior si vedeva dal suo output. Il codice diceva dov’era: cosa aveva capito, cosa stava ancora imitando, cosa non aveva mai incontrato. Era un segnale rumoroso ma leggibile, e serviva a due persone — a chi lo seguiva, per calibrare il lavoro da assegnargli, e a lui, per sapere dove si trovava.

Oggi quel segnale è quasi sparito. L’output di un junior con un buon assistente è spesso indistinguibile da quello di una persona con cinque anni di esperienza. Sembra una buona notizia, e in parte lo è. Ma significa anche che nessuno dei due — né chi guida né chi impara — ha più un modo semplice di sapere a che punto è la crescita. La differenza salta fuori tutta insieme, e sempre nel momento peggiore: il primo problema che non assomiglia a niente di già visto, il primo incidente in produzione, la prima volta che lo strumento propone una soluzione plausibile e sbagliata.

Il rischio non è avere junior meno capaci. È avere junior che sembrano competenti, si sentono competenti, e scoprono di non esserlo in una situazione dove quella scoperta costa cara a tutti.

E poi c’è il problema economico

Qui la faccenda smette di essere pedagogica.

I compiti che davamo ai junior avevano tutti le stesse caratteristiche: ben delimitati, a basso rischio, ripetitivi, con un risultato verificabile. Erano i gradini bassi della scala, e servivano esattamente a quello — far salire qualcuno.

Sono anche, con precisione quasi comica, i compiti che oggi l’intelligenza artificiale svolge meglio. Più veloce, a costo quasi nullo, senza bisogno di supervisione.

Quindi il problema non è solo “come faccio a insegnare”. È che il lavoro con cui si insegnava non ha più una ragione economica per esistere. Chi decide come allocare le persone su un progetto si trova davanti a una scelta che dieci anni fa non c’era: quel task lo do a una persona che deve imparare, sapendo che ci metterà tre giorni invece di venti minuti e che il risultato sarà peggiore, oppure lo chiudo stasera. La seconda opzione è sempre difendibile sul singolo progetto, e sistematicamente disastrosa sui tre anni.

Nessuno prende mai la decisione di smettere di formare le persone. Si arriva lì una consegna alla volta.

Cosa provo a fare, senza sapere se basta

Non ho una risposta pulita. Ho alcune cose che sto provando, con risultati diseguali.

Prima scrivi, poi confronta. Su un pezzo scelto — non su tutto, sarebbe insostenibile — chiedo che la prima stesura sia fatta a mano, e solo dopo generata. Il valore non è nella versione scritta a mano, che quasi sempre è peggiore. È nel confronto: perché lo ha risolto così, cosa non avevo considerato, cosa invece nel mio era meglio e va tenuto. Il confronto insegna moltissimo, ma funziona solo se hai qualcosa da confrontare.

La review si sposta dal codice al ragionamento. Non chiedo più solo se funziona. Chiedo perché quella scelta, cosa è stato scartato, cosa si rompe se il carico decuplica, cosa succede se quel servizio esterno risponde lento invece che dare errore. Se le risposte non ci sono, il codice non passa — anche quando funziona perfettamente. Non è pignoleria: è che il codice che nessuno sa spiegare è codice che nessuno potrà cambiare.

Il debug di roba scritta da altri, presto. Un incidente in produzione insegna in un pomeriggio quello che un task assegnato non insegna in un mese, e non è delegabile: l’assistente ti aiuta a leggere lo stack trace, non ti toglie la responsabilità di capire perché quel sistema è fatto così. È anche l’unico attrito rimasto che non si può comprimere.

Proprietà lunga su qualcosa di piccolo. Un componente vero, in produzione, seguito per mesi. Le conseguenze delle proprie scelte che tornano indietro dopo sei mesi sono il maestro più efficace che conosco, e sono l’esatto opposto della logica del task chiuso in venti minuti.

La cosa che non so

Resta aperta un’obiezione seria, che mi faccio da solo.

Forse la competenza che stiamo cercando di preservare non è più quella che serve. Forse il mestiere si sposta davvero verso il giudizio, la revisione, la capacità di decidere cosa vale la pena costruire — e forse quelle si possono allenare direttamente, senza passare dalle quattro ore sull’errore di compilazione. Se è così, quello che ho scritto qui sopra è nostalgia travestita da metodo, e tra dieci anni farà sorridere come le prediche su Stack Overflow.

Non riesco a escluderlo. So solo che il giudizio, per come l’ho visto formarsi nelle persone con cui ho lavorato, è sempre arrivato dopo aver sbagliato abbastanza volte da riconoscere le forme. E che non ho ancora visto nessuno svilupparlo guardando funzionare cose che non ha capito.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Il debito tecnico ha una qualità che oggi rimpiango: si vede.

Lo riconosci mentre leggi. La funzione da quattrocento righe, il campo chiamato flag2, la logica di business finita dentro il controller, il modulo che tutti sanno di dover riscrivere e nessuno riscrive mai. Fa male al momento del contatto, e questo è esattamente ciò che lo rende gestibile: un dolore immediato è un segnale, e sui segnali si può decidere. Sai cos’hai, sai più o meno cosa costerebbe sistemarlo, e se scegli di non farlo è una scelta.

Da un paio d’anni sto vedendo accumularsi qualcosa di diverso, che non ha nessuna di queste proprietà. Lo chiamo debito di comprensione, per mancanza di un nome migliore.

Definizione

È codice corretto, funzionante, spesso scritto meglio della media del progetto che nessuno in azienda sa spiegare.

Non “nessuno ha letto”. Nessuno sa spiegare: perché quella scelta e non un’altra, quali alternative sono state scartate, cosa succede se l’input arriva in un formato leggermente diverso, quale vincolo del sistema quel pezzo sta rispettando senza dirlo. Il codice è lì e fa il suo lavoro. Il modello mentale che lo ha prodotto non è mai entrato in nessuna testa.

La differenza rispetto al debito tecnico è che qui non c’è niente da vedere. Il linter è verde. La copertura dei test è buona, perché i test li ha generati lo stesso strumento. La complessità ciclomatica è più bassa della media del repository. Nessuna metrica che usiamo oggi si accorge di questo debito, per la semplice ragione che tutte le nostre metriche guardano il codice, e il codice non ha alcun problema. Il problema è dall’altra parte, nelle persone, e lì non misuriamo niente.

Non è nuovo, è solo accelerato

Vale la pena essere onesti: questo debito è sempre esistito. La persona che se ne va portandosi via l’unico modello mentale di un sottosistema. Il modulo scritto in una notte prima della consegna e mai più guardato. La libreria integrata copiando l’esempio della documentazione e funzionante per motivi che nessuno ha indagato. Codice che nessuno capisce ne abbiamo sempre avuto.

Quello che è cambiato è il tasso di accumulo. Prima il debito di comprensione cresceva alla velocità con cui una persona poteva produrre codice senza capirlo e quella velocità era bassa, perché scrivere codice che non capisci è comunque faticoso e lento. C’era un limite fisico che faceva da freno, non per virtù ma per attrito.

Quel limite non c’è più. Oggi una persona può immettere in un sistema, in una settimana, più codice non compreso di quanto ne avrebbe prodotto in un anno. E può farlo mentre tutti gli indicatori di qualità migliorano.

Come si manifesta

Il debito di comprensione non si annuncia. Si vede di riflesso, e quasi sempre in fenomeni che attribuiamo ad altro:

La modifica piccola che nessuno vuole prendere in carico. Un cambiamento apparentemente banale su una certa area, e in pianificazione cala il silenzio. Non è pigrizia: è che nessuno sa cosa si romperà.

Le stime che si gonfiano su zone precise del sistema senza che nessuno sappia dire perché. Se chiedi, ti risponderanno “quella parte è delicata”. Delicata di solito significa opaca.

“Funziona, non toccarlo”. La frase più costosa dell’intero mestiere, e il sintomo più diretto.

I bug risolti aggiungendo codice invece che togliendolo. Chi ha il modello del sistema rimuove la causa; chi non ce l’ha aggiunge una condizione attorno al sintomo. È un indicatore che si legge nei diff, ed è piuttosto affidabile.

La riscrittura che sembra più economica della modifica. Su un componente di sei mesi fa. Quando arriva questo, il debito non è da pagare: è già stato pagato, in perdita.

Un modo per misurarlo

Non ho una metrica automatica da proporre e diffido di chi la propone. Ho un esercizio, che si fa in mezz’ora su una lavagna.

Si elencano le aree del sistema, e per ognuna si scrive quante persone sono in grado di spiegarla senza aprirla: cosa fa, perché è fatta così, cosa la rompe. Non “quante ci hanno lavorato”. Quante la sanno spiegare.

È il bus factor applicato alla comprensione anziché all’accesso, e il risultato è di solito peggiore di quanto chiunque si aspettasse soprattutto sulle parti costruite di recente e in fretta, che sono anche quelle che in retrospettiva sembravano essere andate meglio.

Cosa lo riduce

La regola del “spiegamelo”. In revisione non passa ciò che l’autore non sa spiegare, anche quando funziona perfettamente. Il criterio non è “l’ho letto”, è “so dirti cosa succede se”. Va detto chiaramente al team che questo non è un test di lealtà verso gli strumenti: vale identico per il codice scritto a mano, e ha sempre dovuto valere. È solo che prima capitava di rado di scrivere qualcosa che non si sapeva spiegare.

Documentare le decisioni, non il codice. Il codice generato è già ampiamente commentato, spesso più del necessario, e quei commenti dicono cosa fa che era la parte già leggibile. Quello che manca è il perché: quali alternative sono state considerate, quale vincolo ha deciso, cosa era vero al momento della scelta e potrebbe non esserlo più. Bastano dieci righe per decisione, tenute vicino al codice.

Chiedere le alternative scartate al momento giusto. Il momento in cui il contesto è massimo è quando il codice viene generato, non sei mesi dopo. “Cosa hai considerato e perché hai escluso il resto” è la domanda che trasforma un output in una comprensione, e costa trenta secondi allora contro tre giorni poi.

Rotazione deliberata. Chi non ha scritto una parte deve metterci le mani prima che sia un’emergenza. È l’unico modo per scoprire quanto è opaca mentre scoprirlo costa poco.

E contrarlo consapevolmente, quando serve. Come per il debito tecnico, non è la contrazione il problema. Per uno script interno, un prototipo, una cosa che vivrà tre settimane, generare qualcosa che nessuno capisce è perfettamente razionale. Il debito diventa pericoloso quando è una scoperta invece che una decisione — quando ci si accorge di averlo il giorno in cui bisogna ripagarlo.

Perché conta più di prima

Il debito tecnico ha un’ultima proprietà consolante: è ripagabile con lavoro. Anche molto, anche noioso, ma lavoro e oggi il lavoro di riscrittura costa meno di quanto sia mai costato.

Il debito di comprensione no. Non si ripaga generando altro codice, perché il codice non è mai stato il problema. Si ripaga solo con il tempo di persone che si siedono e ricostruiscono un modello mentale che nessuno ha mai avuto, partendo da un artefatto che non è stato scritto per essere spiegato. È l’unica forma di debito che gli strumenti che lo producono non aiutano a estinguere.

Il debito tecnico si vede nel codice. Il debito di comprensione si vede solo nelle persone — e per questo, quando lo vedi, di solito è tardi.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

L’Intelligenza Artificiale (IA) sta vivendo una fase di crescita tumultuosa. Ogni giorno vediamo nascere modelli sempre più potenti, capaci di svolgere compiti complessi con una rapidità e un’accuratezza inimmaginabili solo pochi anni fa. Ma quanto è veloce davvero questo progresso? Negli ultimi giorni, un confronto diretto tra due protagonisti del settore, Claude 4 di Anthropic e Gemini 2.5 Pro di Google, ci offre un chiaro indicatore della velocità con cui le tecnologie IA stanno evolvendo.

La sfida tra Claude 4 e Gemini 2.5 Pro: numeri e performance

Google annunciava con orgoglio Gemini 2.5 Pro come il modello più performante per il coding, con un’accuratezza del 63% sul benchmark SV bench, uno standard riconosciuto per valutare la capacità di scrivere codice.

Tuttavia, la leadership è durata pochissimo. Solo pochi giorni dopo, Anthropic ha rilasciato due versioni aggiornate di Claude — Sonnet 4 e Opus 4 — che hanno rapidamente superato Gemini con un’accuratezza rispettivamente dell’82% e dell’80,2%. Questo significa un miglioramento di oltre 17 punti percentuali in meno di un mese, un ritmo di crescita impressionante e senza precedenti.

Oltre i numeri: le capacità pratiche che fanno la differenza

Non si tratta solo di benchmark teorici. Nei test reali, Claude 4 ha dimostrato di saper tradurre queste performance in vantaggi concreti:

• Velocità e qualità nel coding: nel creare un gioco endless running, Claude Opus 4 ha prodotto codice più velocemente e una UI più gradevole rispetto a Gemini 2.5 Pro.
• Anteprima del codice in tempo reale: Claude è in grado di mostrare un’anteprima del codice p5.js direttamente nel browser, una funzionalità che Gemini attualmente non offre.

L’“AI super agent”: il controllo diretto su browser e sistema operativo

Un’altra caratteristica innovativa di Claude 4 è la sua capacità di:

• Interagire con il browser: navigare su siti web e recuperare informazioni aggiornate.
• Controllare il laptop dell’utente: monitorare parametri come la batteria e interagire con il sistema operativo.

Questa capacità di agire autonomamente, senza interruzioni per ore (fino a 7 ore consecutive), trasforma Claude in un vero e proprio “super agente” digitale, capace di gestire compiti complessi e prolungati. Google sta sviluppando un progetto simile, Project Marina, ma attualmente risulta meno performante.

Implicazioni sul futuro del lavoro

L’emergere di agenti IA capaci di controllare browser e dispositivi solleva riflessioni importanti sul mondo del lavoro, in particolare per attività amministrative e di routine. Se queste AI possono svolgere tali compiti meglio, più velocemente e senza stancarsi, molte professioni potrebbero subire una trasformazione radicale o addirittura scomparire.

Gemini Ultra e la sfida multimediale

Il confronto non è però a senso unico. La versione più avanzata di Gemini, Gemini Ultra, ha un vantaggio che Claude non possiede ancora: la capacità di creare video sincronizzati perfettamente con l’audio, grazie alla tecnologia Veo3. Questo apre nuovi scenari per la produzione di contenuti multimediali, un campo dove l’IA sta guadagnando terreno a grandi passi.

Conclusioni: la corsa all’innovazione è appena iniziata

La sfida tra Claude 4 e Gemini 2.5 Pro è un chiaro esempio di quanto velocemente stia evolvendo il settore dell’Intelligenza Artificiale. Le capacità tecniche, le applicazioni pratiche e le nuove funzionalità stanno ridefinendo costantemente i confini del possibile.

Questa accelerazione non solo migliora gli strumenti che abbiamo a disposizione, ma ci proietta verso un futuro in cui la super intelligenza non è più fantascienza, ma una realtà concreta e imminente.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Introduzione

C’è una narrazione diffusa, soprattutto in certi ambienti aziendali tradizionali, secondo cui lo sviluppatore sarebbe una figura puramente esecutiva. Una persona a cui viene detto “scrivi questo codice” da un architetto o un analista, e che si limita a trasformare specifiche in righe di codice senza metterci nient’altro. Questa percezione non solo è riduttiva, ma alimenta anche un’idea pericolosa: se il programmatore è un semplice esecutore, allora un’intelligenza artificiale può facilmente sostituirlo.

Ma c’è un’altra prospettiva. Ed è quella in cui credo fermamente: quella dello sviluppatore come figura creativa, capace di dare forma alle idee e trasformare intuizioni in realtà digitale.

La visione esecutiva: il programmatore come “operaio del codice”

Questa visione nasce da un’impostazione fortemente industriale del lavoro. In passato, con i modelli a cascata e la netta separazione dei ruoli, il flusso di lavoro era molto rigido: analisi, progettazione, sviluppo, test. Ogni anello della catena aveva un compito definito e poco spazio di manovra.

Il programmatore diventava così l’ultimo anello della catena, responsabile solo di tradurre in codice specifiche già decise altrove. In questo contesto, l’idea che un’IA possa sostituire questa figura è comprensibile: se si tratta solo di eseguire istruzioni, l’automazione sembra inevitabile.

La visione creativa: il programmatore come architetto delle soluzioni

Ma la realtà di chi sviluppa software è ben diversa. Programmare non è solo scrivere codice: è risolvere problemi complessi, prendere decisioni di design, trovare soluzioni eleganti e scalabili. Ogni riga di codice racconta una storia di scelte, di compromessi, di intuizioni.

Un buon sviluppatore non si limita a ricevere istruzioni: partecipa attivamente alla definizione della soluzione, propone alternative, anticipa problemi futuri. In altre parole, crea.

Pensiamo a quando ci viene proposta un’idea vaga: “Vorrei un’app che aiuti le persone a organizzare meglio il loro tempo”. Non esistono specifiche dettagliate, né flussi definiti. Tocca a noi, come creativi del codice, dare forma a quell’intuizione, immaginare l’interfaccia, scegliere la tecnologia giusta, costruire l’esperienza utente.

In questo, l’intelligenza artificiale non è una minaccia, ma uno strumento potente. Ci libera dal lavoro più ripetitivo e ci permette di concentrarci ancora di più sugli aspetti creativi e strategici del nostro mestiere.

Conclusione: riscoprire la creatività nello sviluppo

Il programmatore non è un mero esecutore, ma un artigiano digitale, un creatore di esperienze e soluzioni.

Riconoscere questa dimensione creativa non è solo un modo per valorizzare il nostro lavoro, ma anche per guardare con maggiore lucidità al futuro: un futuro in cui l’IA sarà alleata e non sostituta, e in cui la nostra capacità di immaginare e costruire continuerà a fare la differenza.

“La creatività è solo connettere le cose.” — Steve Jobs

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Da diversi anni lavoro a progetti legati alla pubblica amministrazione. Nel tempo mi sono reso conto di cosa voglia dire realizzare un sito/app accessibile. Imparare ad usare screen reader, i giusti costrutti, come strutturate le pagine e usare gli attributi corretti per far capire ad una persona con handicap visivi o auditivi, come poter capire meglio e più velocemente i contenuti proposti.

La prima cosa che posso dire è questa, una persona disabile ha meno difficoltà di quelle che possiate pensare, sono abituati a superare gli ostacoli (non solo nel software) e questo in molti casi li rende più smart di noi utenti “normali” che dobbiamo capire con occhi e udito quello che ci viene proposto. Mi è capitato di lavorare con alcune persone non vedenti e sono rimasto ammirato dal loro approccio, capivano i contenuti della pagina (fatta con i giusti criteri) prima e meglio di me. Loro puntano al contenuto e alle informazioni, noi ci perdiamo nei fronzoli della pagina.

Con questo non voglio dire che non serve rendere accessibile il software, il contrario, noi sviluppatori con uno sforzo minimo possiamo aiutare queste persone, e non solo, a capire con più facilità quali siano i contenuti che proponiamo sul nostro sito o nella nostra applicazione.

Di seguito vi riporto i ventidue miti da sfatare sull’accessibilità suggeriti da a11ymyths.com e riportati nel mio progetto calendario dell’avvento per sviluppatori (sono aperte le iscrizioni per il 2022). Approfitto per ringraziare tutte le persone che si sono iscritte e che mi hanno dato suggerimenti su come migliorare e rendere i contenuti interessanti.

Iniziamo…

#01 L’accessibilità riguarda solo un piccolo gruppo di utenti

Non così piccolo. Circa il 15% della popolazione mondiale, o circa 1 miliardo di persone, vive con disabilità, sono la più grande minoranza del mondo. Il numero delle persone con disabilità è in forte aumento.

Una curiosità… una delle migliori App completamente accessibile al mondo (sia web che mobile) è quella di Amazon, il loro obiettivo è vendere e se non fossero accessibili si perderebbero una fetta del mercato.

Maggiori informazioni

#02 Gli utenti disabili non utilizzano il mio sito web

Come puoi essere così sicuro? Molte persone con disabilità come daltonismo, capacità motorie limitate, ecc. utilizzano i siti Web proprio come gli altri utenti. Inoltre, molte tecnologie assistive non sono rilevabili in alcun modo.

Maggiori informazioni

#03 Rendere accessibile un sito Web è costoso e richiede tempo

Potrebbe non essere così se l’accessibilità fosse considerata dall’inizio del progetto grazie ad un team di sviluppo con le competenze adeguate. Quando l’accessibilità è diventata un’abitudine, il tempo di sviluppo non cambia o cambia di poco.

Implementare l’accessibilità by design ha un costo molto ridotto rispetto ad un adattamento a posteriori.

#04 Possiamo aggiungere rapidamente l’accessibilità prima del rilascio

Non funzionerà. Forse alla fine potrebbero essere aggiunte cose semplici come testo alternativo o etichettatura dei moduli, ma alcune UX complesse dovrebbero essere pianificate per essere accessibili. In alcuni casi, rendere accessibili le funzionalità al termine del processo di sviluppo può richiedere il refactoring completo.

#05 L’accessibilità riguarda solo l’aggiunta di testo alternativo alle immagini

In effetti, la mancanza di testo alternativo per le immagini è uno dei maggiori problemi di accessibilità . Ma oltre a questo, ci sono molte cose da considerare mentre si rende accessibile la struttura dei titoli del sito Web, i controlli funzionali , il contrasto del colore e molto altro.

#06 L’accessibilità al Web è solo una responsabilità dello sviluppatore

È un lavoro di squadra. I progettisti creano interfacce utente accessibili, gli sviluppatori le realizzano, gli ingegneri QA eseguono i test di accessibilità, i PM si assicurano che l’accessibilità sia inclusa nei processi del team, il team legale verifica se un prodotto sia privo di rischi dal punto di vista dell’accessibilità, i gestori dei contenuti regolano il contenuto per renderlo conforme.

Maggiori informazioni

#07 L’accessibilità aiuta solo le persone con disabilità

Fortunatamente aiuta tutti . È risaputo che l’applicazione dei principi di accessibilità migliora l’esperienza complessiva dell’utente e rende un sito Web più comodo da usare.

#08 Rendere accessibili i siti Web non comporta vantaggi aggiuntivi

Per elencarne solo alcuni: più utenti, più entrate, migliore reputazione, meno rischi di essere citati in giudizio, migliore competenza dei team di sviluppo e molto altro. Alla fine, fare una cosa buona non deve sempre richiedere una ragione redditizia.

#09 L’accessibilità può essere riparata dall’overlay di accessibilità

Assolutamente no. C’è un’iniziativa firmata da centinaia di professionisti che sostiene la rimozione dell’overlay di accessibilità web.

Questo a mio avviso è un punto di discussione molto interessante relativo al lungo termine e come integrazione a strumenti che già l’utente possiede e che possono andare in contrato con queste pratiche

#10 L’utilizzo di strumenti automatizzati è tutto ciò che devo fare per rendere accessibile il mio sito web

Sarebbe facile, ma no. Di solito i test di accessibilità automatizzati possono rilevare solo il 30-50% di tutti i problemi di accessibilità . In effetti, alcuni siti Web possono essere costruiti in modo tale da superare i test automatici anche se il sito Web è totalmente inaccessibile.

#11 L’accessibilità è riservata agli utenti non vedenti

Certamente, l’accessibilità influisce sull’esperienza degli utenti non vedenti, ma riguarda anche gli utenti con altre disabilità visive come il daltonismo. Naturalmente avvantaggia anche le persone con altre forme di disabilità, legate all’udito, alla mobilità, alla parola o alla cognizione. Funziona anche per utenti anziani. In breve, per tutti gli utenti. È essenziale per alcuni ma utile per tutti.

Maggiori informazioni

#12 L’accessibilità è facoltativa

Fino a quando la tua azienda non è stata citata in giudizio. Scopri le cause di Netflix e Domino per capire che il prezzo per non essere accessibile potrebbe essere troppo alto. Ci sono molte leggi che possono richiedere l’accessibilità di un sito web.

#13 L’accessibilità riguarda solo la prevenzione di azioni legali

L’accessibilità riguarda i tuoi utenti. Ovviamente, prevenire le azioni legali è importante per qualsiasi azienda, ma anche la soddisfazione degli utenti e la reputazione dell’azienda apportano molto valore.

#14 L’accessibilità consiste solo nel seguire le WCAG

Di solito parte da WCAG, ma nella vita reale un sito Web conforme potrebbe non essere ancora completamente accessibile. L’accessibilità riguarda la comprensione dei bisogni di tutti gli utenti, nonché l’empatia e la consapevolezza.

#15 L’accessibilità può essere ottenuta solo aggiungendo attributi ARIA

Naturalmente, ARIA è una parte importante dell’accessibilità, ma la regola d’oro di ARIA è “Non usare ARIA”. Molti attributi ARIA potrebbero non essere necessari se vengono utilizzati tag HTML semantici.

#16 Non abbiamo bisogno di essere conformi

Forse ne hai bisogno. Esistono numerose leggi e regolamenti che possono richiedere a un sito Web di seguire i principi di accessibilità. Vale sicuramente la pena controllarli.

Maggiori informazioni

#17 Solo gli esperti di accessibilità possono implementare correzioni di accessibilità

Per fortuna no. Chiunque abbia alcune capacità di accessibilità può implementare e testare i siti Web per l’accessibilità. In effetti, non è solo facile da imparare, ma a volte è un processo piuttosto divertente. Non richiede un’esperienza specifica per eseguire i controlli facili.

#18 L’accessibilità è come una funzionalità: lo fai una volta e poi ce l’hai

L’accessibilità è una pratica, non una caratteristica. Significa che bisogna prendersene cura regolarmente, sia quando si lavora su funzionalità che quando si eseguono lavori di manutenzione. La conoscenza dell’accessibilità dovrebbe essere trasmessa quando un nuovo membro del team si unisce o quando i requisiti cambiano.

Maggiori informazioni

#19 L’accessibilità può essere risolta fornendo una versione del sito Web separata per le persone disabili

Quella è sempre stata un’ipotesi sbagliata. Molti team di sviluppo hanno imparato a proprie spese che mantenere diverse versioni del sito Web e mantenere tutti i contenuti aggiornati costano molto di più rispetto alla creazione dell’unico sito Web completamente accessibile.

#20 Le persone con disabilità non usano il web

È sbagliato. Infatti, in alcuni casi internet è l’unico modo con cui le persone disabili possono comunicare con il mondo. Inoltre, laddove le “persone abili” utilizzano le loro sensazioni naturali come la vista e l’udito, le persone con disabilità devono fare affidamento sulle tecnologie.

Maggiori informazioni

#21 I ciechi non guardano i film

Lo fanno sicuramente. Con l’aiuto delle descrizioni audio possono guardare e ascoltare qualsiasi contenuto multimediale come fanno tutte le altre persone.

Maggiori informazioni

#22 L’accessibilità può essere verificata solo da persone disabili

Bene, di solito le persone disabili sono i migliori tester: usano le tecnologie assistive a tempo pieno. Tuttavia, tutti possono imparare a testare l’accessibilità dei siti Web.

Maggiori informazioni

Conclusione

Quindi amici sviluppatori e designer, da domani sforziamoci un po’ di più a migliorare il mondo per tutti quanti.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

E’ una cosa che non ho mai fatto, sapevo però che prima o poi avrei infranto questa regola.

Mi è capitato sotto click il link ad una pagina di presentazione di un prodotto, non faccio nomi e premetto (sono l’uomo che premette, Cit.), non conosco il prodotto. Questo post fa riferimento a cosa hanno scritto nella pagina di presentazione del prodotto per poterlo vendere. Sicuramente la versione italiana è stata tradotta in modo automatico, c’è qualche problema qua e là, ma vediamo insieme cosa hanno scritto.

La pagina contiene tre punti chiave che descrivono il prodotto, si parte con questa.

C’è una ragione per cui lo sviluppo software tradizionale non giova al vostro business. È il codice software. Il modo in cui istruiamo oggi i computer non è tanto diverso da come lo facevamo 50 anni fa: specialisti digitano simboli criptici all’interno di file di testo. Assembler. COBOL. Java. Sono tutti la stessa cosa. Cambia solo il nome.

Certo, ogni programmatore che conosce il “codice software” e che scrive “simboli criptici” in file di testo, sa benissimo che tutti i linguaggi sono uguali e che cambia solo il nome.

La liberazione dalle catene del codice software fornisce risultati immediati. Creerete e modificherete le applicazioni più rapidamente. Vi estenderete in nuovi canali e lancerete nuovi prodotti quando vorrete. Darete straordinario valore al vostro business.

Anche questo passaggio è un punto chiave della presentazione, quando ci liberiamo dalle catene del “Codice Software” abbiamo subito risultati, cosa perdiamo tempo a scrivere codice, ormai non serve più a nulla. E poi…

Una volta tolto di mezzo il codice software, le possibilità sono illimitate.

…, questo era scontato, ma poi continua dicendo che…

Quando si crea il software utilizzando codice software, solo le persone che comprendono tale codice possono svilupparlo

…ma dai, pensavo che a tutti fosse chiaro il “codice software”, ma in compenso loro hanno un’aiuto…

Utilizziamo l’intelligenza artificiale per individuare gli ostacoli alle prestazioni e fiutare le violazioni delle migliori pratiche

Adesso va di moda mettere l’AI ovunque quindi anche a loro non manca.

Altro passaggio fondamentale, tutto cambia troppo velocemente e noi semplici programmatori non riusciamo a stargli dietro.

La tecnologia avanza rapidamente. Quella fantastica libreria JavaScript di cui il vostro addetto alla User Experience vi ha parlato? Già obsoleta. L’app mobile che avete lanciato l’anno scorso? Antiquata.

Quindi il risultato e quello di…

Progettate invece la vostra applicazione e  **** terrà il codice software aggiornato per voi. Modellate la vostra User Experience reattiva in **** e noi genereremo il codice software che integra la più recente tecnologia UX. Pensiamo noi a riscrivere il codice software, così non dovrete farlo voi.

E poi si chiude in bellezza con…

E se volete passare a una nuova piattaforma cloud o passare da un database a un altro, **** genera codice software ottimizzato per la nuova infrastruttura. Nessuna necessità di necessario riscrivere il codice software.

Questo non è solo a prova di futuro. Questo è “Future Empowered”

Io non mi stupisco di quello che è stato scritto, oggi si scrive qualsiasi cosa pur di vendere un prodotto e lo accetto. Non riesco però a comprendere come qualcuno possa crederci. Di certo presentazioni come questa sono fatte per quelle persone che “contano” all’interno dell’azienda e che possiedono il fatidico BUDGET da poter investire, ma sono prive di una qualsiasi base tecnica che possa fargli comprendere quanto cose come queste siano gonfiate rispetto alla realtà.

Ecco l’intera pagina di presentazione.

Happy

0

0 %

Sad

0
0 %

Excited

0
0 %

Sleepy

0

0 %

Angry

0
0 %

Surprise

0
0 %

Settimana scorsa si è svolto il //Build 2016, per chi non sapesse di cosa si tratta, è l’evento Microsoft dedicato agli sviluppatori.

Nei mesi scorsi, sia in ufficio (ringrazio i Team Verde per la sopportazione) che sui social in generale mi sono lamentato molto di Microsoft, e non sono stato l’unico, in quanto non era chiara la direzione, gli obiettivi che si volevano raggiungere, quali sarebbero stati gli “investimenti” che noi sviluppatori avremo dovuto fare.

Certo, abbiamo cercato di dare un senso alle strategie guardando cosa faceva Microsoft, il nuovo Asp.Net Core 1.0 (ex asp.net 5/vNext) ci ha fatto capire che la direzione era il multipiattaforma, poi ci sono stati altri segnali come l’interesse verso Xamarin e la conseguente acquisizione, insomma tra notize non molto chiare e smentire altrettanto confusionarie, qualcosa si era intravisto.

Il Build ha fatto luce su tutto questo. Per il dettaglio su cosa è stato detto, vi rimando a Channel9 dove potete riguardarvi Keynote, singole sessioni e interviste. Tiriamo le somme e facciamo qualche considerazione.

La notizia di fondo è vera, Microsoft punta al multi piattaforma, quindi direzione Cloud-First, Mobile-First, il progetto è quello di portare il più possibile tutto sul cloud ed essere presenti con i servizi su tutte le piattaforme.

Questo cosa significa per lo sviluppatore Microsoft/.Net? Che da oggi abbiamo più strumenti e linguaggi che possiamo utilizzare per creare le nostre applicazioni, certo rispetto a prima non cambia nulla per il mondo NON Microsoft ma l’idea è quella di portare anche loro (chi lavora su Linux o comunque con altri ambienti) verso Windows.

Quest’estate verrà rilasciato un nuovo e corposo aggiornamento a Windows 10 che comprenderà tutte le novità presentate a Build, l’aggiornamento si chiamerà “Anniversary Update“.

La prima novità è il rilascio di Bash nativo su Windows, questo ha portato molti a pensare che andrà a sostituire PowerShell o diventerà la nuova command line, credo sia invece un modo utile per permettere a chi è già abituato a questa modalità di lavoro su Linux, dove la riga di comando la fà da padrone, di essere più agevoltato nel passare a Windows o comunque sia meno restio.

L’acquisizione di Xamarin è forse la migliore nelle notizie, sopratutto se si pensa che sarà gratuito con tutte le versioni di Visual Studio, compresa la Community Edition e Xamarin Studio gratuito per Mac. Non voglio dilungarmi su cosa è Xamarin e cosa fà, certamente è uno strumento utile in caso si voglia sviluppare per IOS, Android e Windows Phone senza dover riscrivere l’intera applicazione, è ovvio che ci sono da tenere in considerazione diverse cose e che è comunque un ambiente di terzi quindi non consente di fare tutto quello che può essere fatto con gli ambienti di sviluppo naviti come XCode a Android Studio ma è ovvio che dipende dal risultato che vogliamo ottenere.

Visual Studio continua a crescere, rilasciata in beta la versione 15 e Visual Studio 2015 Update 2 con un pò di cose nuove:

• Nuovo editor di IOS Integrato (Xamarin)
• Svilupppo C++ nativo multipiattaforma (Linux, Android, Raspberry, ecc.)
  • C’è una sessione dedicata dove mostrano il debug in tempo reale da Windows verso una macchina virtuale Linux
• e molto altro…

Le altre informazioni importanti venute fuori da Build riguardano i nuovi servizi:

• Office 365 sempre più aperto verso gli sviluppatori
• Cognitive services
• Bot Framework permette di creare Bot virtuali che rispondono all’utente via Skype, Twitter, Slack tramite servizi totalmente personalizzabili.
• Azure integra nuovi servizi e migliora quelli esistenti per gli sviluppatori.
• …

Insomma un sacco di cose nuove, a voi giudicare se sono belle o brutte, molto di quello che è stato presentato è intessante, la conferma dell’esistente permette di cominciare a pianificare cosa fare, nei prossimi mesi ci sarà molto da fare cose nuove da studiare e provare.

Chiudiamo però con notizie meno belle, Microsoft, ma lo si era già capito da un pò, sempre che non abbia messo nelle sue priorità Windows Mobile. Il progetto UWP continua a essere importante, nuove librerie e nuovi strumenti, sono stati confermati i Brige che permettono di portare le applicazioni Win32 sullo store e le Web Store App ma purtroppo Windows Mobile non è stato mezionato.

Come sviluppatore Windows Phone questa cosa mi è dispiaciuta, ho sempre visto la piattaforma di Microsoft come un’ottima concorrente ma a IOS e Android ma purtroppo loro stessi sono stati i primi a non crederci e non metterla come priorità, ci stà dopo quello che hanno presentato il loro obiettivo è nel futuro essere presente con i loro servizi ovunque.

Non scordiamoci di HoloLens, intanto cominciamo a vedere dove ci porteranno queste cose nuove in attesa della nuova versione di Windows.

Happy

0

0 %

Sad

0
0 %

Excited

0
0 %

Sleepy

0

0 %

Angry

0
0 %

Surprise

0
0 %

Devo dire che nell’ultimo periodo sono un po’ critico rispetto a Microsoft, questo non per un presa di posizione a prescindere ma per motivazioni reali legate a ciò che faccio quotidianamente, sono uno sviluppatore e quello che faccio è fare App e scrivere codice.

Chi mi conosce sa che sono stato (al momento parlo al passato) un grande sostenitore di Windows Phone, Microsoft era partita con buoni propositi che, secondo me, ha perso lungo la strada ed è ovvio che sia un strada sulla quale hanno parecchie indecisioni.

Ho assistito allo streaming di #futureDecoded e la sola cosa che mi è saltata all’occhio è stata … Ma quanto siamo belli ma quanto siamo bravi e meglio di noi nessuno … OK, l’evento gratuito serviva proprio a questo, ma quando poi andiamo al sodo cosa vediamo?

Non pensate subito male, ripeto non sono contro a priori ma ho le mie motivazioni e magari possono servire come punto per una riflessione più ampia.

Parliamo di Windows 10.

Certamente una scelta radicale (che secondo me avrebbero dovuto fare da tempo) un “nuovo” sistema operativo che taglia rispetto al passato che adesso è su tutti i device

Questa immagine usata in tantissime occasioni che dimostra questa nuova strada che hanno intrapreso.

Tornando al nostro discorso…
Windows 10 ha moltissime cose interessanti ma da sviluppatore cosa vedo:

• Strumenti di sviluppo ancora acerbi o comunque non ancora concreti e certi
• App desktop che non hanno appeal ne verso l’utente ne verso chi le deve sviluppare
• L’azzeramento delle linee guida per la UI, Windows Phone con Metro aveva dato una strada interessante che tutti hanno apprezzato e che ad oggi si sta’ sgretolando perché a tutti è permesso di realizzare l’interfaccia come gli pare e questo per l’utente finale non è un pregio.

Poi la cosa che mi lascia perplesso quando leggo articoli o sento interviste è sentire discorsi tipo questo

… La prossima versione che faremo sarà la versione più bella e la più figa di tutte …

Il problema è che questa frase la sento per ogni versione di qualsiasi cosa, Windows Phone 7 era giovane e pieni di difetti, quindi abbiamo aspettato l’8 poi l’8.1 ha cambiato un po’ le carte in tavola ma ci siamo adattati, per le Universal App (che così non erano), Windows 10 Mobile è meglio, ma meglio di cosa visto che non c’è ancora? Belle le Universal App ma di nuovo ci hanno cambiato i controlli e il modo di creare le App, bello Metro ma non c’è più, o almeno non è così importante.

Utilizzo Windows 10 desktop da un bel pò grazie al programma Insider e l’ho visto crescere a cambiare ad ogni release e vedo che le app native hanno UI/UX che lasciano a desiderare, non hanno la stabilità ti aspetti da un sistema che dovrebbe essere stabile ma lo perdoni perché è appena uscito ma quindi? la posizione di noi sviluppatori Windows è quello di essere felici perché Microsoft cambia sempre le carte in tavola, ci da strumenti che poi cambia, ci dice che farà cose che poi NON porterà a termine, perché mi vengono chieste Apps per IOS e Android e non per Windows Phone? la risposte è certamente … perché sono i più diffusi … e quindi una domanda seria non ce la facciamo?

La mia visione è diretta sopratutto al mercato Business, Windows la fa ancora da padrone per numero di installazioni e utenti su PC, certamente non sono in discussione questi numeri ma il mercato sta’ cambiando come la stessa Microsoft ci mostra, quando fa una nuova app o un nuovo servizio è sempre multi-piattaforma ma questo però indica anche che noi sviluppatori forse non dobbiamo investire così tanto su una cosa come i device mobili con Windows perché tanto non saranno così numerosi come i concorrenti.

Le mie sono riflessioni personali, come detto legate a ciò che faccio ogni giorno, ci sono tempi e modi di fare le scelte ma ad oggi non avevo mai realmente riflettuto su un cambio almeno per quello che riguarda il Mobile.

Il discorso comunque è molto più ampio, Microsoft ha tantissime cose all’attivo e per questo ha pregi e difetti perché dal punto di vista di uno sviluppatore vede che le cose cambiano in fretta e abbiamo sempre nuove possibilità ma vediamo anche che ciò su cui ha investito non sono più utilizzabili o comunque cambiano senza che tu possa aver avuto il tempo per assorbirle.

L’unica cosa che possiamo fare è stare alla finestra, guardiamo cosa ci passa davanti e valutiamo volta per volta ma dovrebbe tornare una visione delle cose che possa portare almeno ad un anno e non solo a pochi mesi.

Happy

0

0 %

Sad

0
0 %

Excited

0
0 %

Sleepy

0

0 %

Angry

0
0 %

Surprise

0
0 %

Vi sarà capitato, almeno per il 90% dei casi è così, di dover avere impostazioni diverse nel web.config relative a stringhe di connessione oppure o settings generici che utilizzate nella vostra applicazione.

La strada messa disposizione da Microsoft per risolvere questo problema è la gestione della configurazione di pubblicazione dell’applicazione associando web.config diversi come in questa immagine

La procedura è semplice, basta modificare il file associato alla pubblicazione che facciamo inserendo gli attributi di trasformazione

xdt:Transform="SetAttributes" xdt:Locator="Match(name)"

se volete saperne di più…

Questa modalità è molto utile perché permette la trasformazione di tutti i nodi presenti nel web.config dando maggiore flessibilità in fase di pubblicazione ma… questo non è sempre un vantaggio, in quanto, almeno nel mio caso, i web.config delle applicazioni che pubblico non sempre sono gestiti e manutenuti nel tempo solo da me quindi può valere per la prima pubblicazione ma in seguito il file non viene più ripubblicato perché quello della macchina di destinazione è certamente quello da utilizzare.

Altro svantaggio di questo modello è, sempre per la mia esperienza, non pratico da gestire nel tempo, spesso, da clienti, una singola applicazione che scrivo viene pubblicata su diversi server con procedure automatiche di validazione, quasi mai la mia applicazione sulla macchina di sviluppo finisce diretta in produzione ma ci sono uno o più livelli di validazione e in queste fasi avere web.config diversi non è praticabile.

Per questo motivo mi sono scritto una semplice classe che permette di leggere la configurazione di appSettings e connectionStrings (sono gli unici casi nella quale serve realmente) da un singolo web.config in base nome della macchina.

Ovviamente questo modello può essere integrato alla trasformazione dei nodi descritta sopra.

Facciamo un esempio…

web.config:
<add key="working.directory" value="C:\temp\cartelladilavoro" />

codice C#:
var cartella = ConfigurationManager.AppSettings["working.directory"];

Su una diversa macchina potrebbe essere diverso quindi avrei necessità di modificarlo prima della pubblicazione. La mia soluzione è la seguente:

web.config:
<add key="working.directory" value="C:\temp\cartelladilavoro" />
<add key="[www.sito.it]working.directory" value="D:\temp\Web1\cartelladilavoro" />

codice C#:
var cartella = ConfigurationManagerEx.AppSettings["working.directory"];

Utilizzando la classe che ho creato chiamata ConfigurationManagerEx prelevo il valore corretto in base al nome dell’host che ospita la mia applicazione, in caso questo non esista nella mia lista, viene sempre preso il valore predefinito definito senza il nome macchina specificato. Questo modello mi permette di avere tutti i valori in un unico file, posso sempre distribuire tutto e chiunque può modificarlo e copiarlo rispettando la semplice regola del nome macchina.

Potete trovare la classe a questo indirizzo:

http://configurationmanagerex.codeplex.com/

Happy

0

0 %

Sad

0
0 %

Excited

0
0 %

Sleepy

0

0 %

Angry

0
0 %

Surprise

0
0 %