Visual Studio color schemes

Oggi parliamo di un argomento che mi sta molto a cuore.. la salute dei miei occhi 🙂 ..anche dei vostri dai!

Qualche giorno fa.. ho dovuto cambiare gli occhiali e così ho ben pensato di approfittarne per fare un’accurata visita da un optometrista.. è stato veramente illuminante!!! Anche se ora che ci penso non so se anche per lui è stata un’esperienza gradevole.. visto che l’ho letteralmente tempestato di domande (purtroppo sono un tipo un curioso) avrà pensato che invece di vole fare una visita agli occhi forse volevo prendermi una laurea in materia… 😀

Ma veniamo al motivo di questo post! …insieme a tutta una serie di attività che sto tentando di rispettare per prendermi un po’ più cura della salute dei miei occhi (anche se la soluzione ultima sarebbe spegnere definitivamente questo arnese infernale [Alias: PC, MAC, TABLET, SMARTPHONE, ecc…]) ho pensato di rendere “la faccia” di Visual Studio e similari un po’ meno stancante.. e così girando per la rete mi sono ritrovato su http://studiostyl.es/

Francamente oggi mi chiedo come mai non ci abbia pensato prima! ..infondo è una vita che Visual Studio implementa la possibilità di gestire i font ed i colori dell’area di lavoro.. spesso siamo talmente impegnati a risolvere i problemi degli altri che ci dimentichiamo di non crearne di nostri… 😀

Non mi sento ovviamente di consigliarvi un tema in particolare visto che non sono un optometrista o un oculista e di conseguenza potrei dire solo un sacco di eresie.. Ma per condividere la mia scelta posso dirvi che sto optando per un tema con lo sfondo mediamente scuro ma evitando alti contrasti…

..e tu che tema scegli?

L’approccio delle aziende alla tecnologia .Net

E’ sempre più facile trovare in rete tantissimi articoli sulle differenze tra la tecnologia .Net e altre tecnologie ritenute di fascia  Enterprise presenti sul mercato, ma ancora più frequenti sono quelli relativi alle diatribe tra i programmatori legati alle diverse piattaforme.
Per quanto mi riguarda non ho nessuna intenzione di esprimere il mio punto di vista sulla questione, per tre motivazioni:

  1. Non credo si possa generalizzare e semplificare questo discorso in poche rige di testo
  2. Svolgo attività di progettazione e sviluppo su tecnologie Microsoft principalmente .Net (rischierei di essere considerato di parte)
  3. Non ha senso scrivere un articolo su tale questione in attesa che diventi l’ennesima inutile guerra a colpi di commenti tra programmatori

Vorrei rivolgere invece la mia attenzione, magari con il vostro aiuto in termini di commenti a questo post, nell’analizzare il punto di vista che le aziende hanno su tale questione e come questa influenzi negativamente le attività degli addetti ai lavori.

Durante la mia esperienza professionale ho collaborato in diverse realtà informatiche e ciò che mi ha sempre lasciato perplesso è stato l’approccio, che nella maggior parte dei casi, viene utilizzato nella costruzione dei team di sviluppo per progetti legati alle diverse tecnologie (ovviamente mi riferisco a progetti di una certa dimensione) per non parlare poi delle suddivisione delle attività e dei tempi ritenuti sufficienti per la realizzazione dei prodotti finali (PRINCE2 ®).
Estremizzando la questione, e rispetto a quelle che sono state fino ad oggi la maggior parte delle mie esperienze, si potrebbe riassumere la questione come segue:

Le fugure “riconosciute” in un progetto Enterprise, indipendentemente dalla numerosità dei diversi ruoli, sono in genere

  1. Project Manager
  2. Project Officer
  3. IT Architect (Disegna e definisce la struttura dei sistemi informativi)
  4. Analisti Sr/Jr (Definizione degli obiettivi tecnici, progettazione della struttura della base dati, specifiche per il programmatore, ecc..)
  5. Sviluppatore Front-End Sr/Jr (Responsabile dello sviluppo per delle componenti per l’acquisizione dei dati di input e la presentazione di quelli in output)
  6. Sviluppatore Back-End Sr/Jr (Responsabile dello sviluppo della logica di business sui dati acquisiti)
  7. Specialista (Eventuale specialista di un particolare prodotto meno conosciuto dal resto del team)
  8. System integrator (Cura l’armonizzazione di sottosistemi di diversa natura e/o di diversi fornitori)
  9. Database Administrator (Progettazione fisica e della manutenzione del Data Base, delle utenze e delle funzioni dirette di gestione)
  10. Sistemista (Fornisce assistenza al team di sviluppo sull’utilizzo ottimale del software di base)
  11. Tester (disegno del piano del test, esecuzione dei casi di test e report dei risultati, interfacciamento con team di sviluppo)

Le fugure “riconosciute” in un progetto .Net, indipendentemente dalla numerosità dei diversi ruoli, sono in genere

  1. Project Manager
  2. Analista Programmatore Sr/Jr
  3. Programmatore Sr/Jr

Nel secondo caso ho omesso le responsabilità delle diverse figure in quanto sarebbe solo un’inutile provocazione specificarle 🙂

Tutto ciò mi ha portato  a riflettere sul fatto che moltissime aziende informatiche non riconoscono ancora la complessità e la completezza che oggi la tecnologia .Net offre senza nulla togliere alle altre.

Come ho già analizzato in un’altra serie di articoli non si può certo negare che le piattaforme microsoft abbiano “mascherato” per lungo tempo una certa complessità di sviluppo ai programmatori con un ricchissimo arsenale di strumenti RAD mancanti in altre tecnologie e che per tale motivazione il “programmatore Microsoft Base” rispetto agli altri abbia spesso ignorato una parte delle nozioni tecniche e/o filosofiche per l’implementazione di applicazioni “ben strutturate” (OOP, OOD, DDD, SOLID, Design Patterns, ecc..).

Tutto ciò ovviamente oggi si paga in termini di “cattiva pubblicità”, non tanto per la tecnologia .Net in se (in quanto ci sono comunque tantissime realtà che pur rimanendo un minima parte, ne hanno riconoscono il valore facendone un ulteriore punto di forza) ma soprattutto per gli addetti ai lavori che nella maggior parte dei casi non riusciranno a lavorare adeguatamente per il raggiungimento degli obbiettivi richiesti dal progetto sui quali saranno allocati come figura di factotum vedendo denigrata la propria professionalità.

Purtroppo non si può nemmeno negare che trovare programmatori .Net che abbiano una certa consapevolezza di ciò che sono i principi base per un corretto disegno architetturale non è semplicissimo, per diverse motivazioni:

  1. L’ambiente di sviluppo .Net offre tantissime facility erroneamente considerate analoghe agli strumenti, della stessa tecnologia, ma che dovrebbero essere utilizzati per la produzione di prodotti di fascia più alta.
  2. La presenza di una moltitudine di certificazioni raggiunte con kit di preparazione di dubbia moralità professionale che abbassano enormemente il livello medio della categoria.
  3. Il mancato investimento nella professionalizzazione dei propri dipendenti da parte di molte aziende informatiche.
  4. La svendita di tale professionalità da parte elle aziende informatiche nei confronti degli acquirenti.
  5. La pubblicizzazione del concetto di .Net = “Utilizzo un tool per una produzione senza scrivere una riga di codice”.