Category: Thoughts

Sviluppatore senior chi è costui ?

– Colui che lavora sempre sullo stesso progetto da almeno 4 anni, facendo ogni giorno sempre le stesse cose;

– Colui che usa come DAL il DataSet a go-gò, vantandosi di come lo sa utilizzare bene, non sapendo che forse c’è qualcosa di meglio in giro;

– Colui che riempie il codice di cast, rendendolo perfettamente funzionante ma praticamente illeggibile ad altri sviluppatori;

– Colui che usa la tecnica di scrivere chiamate a metodi innestati tra loro, rendendo il codice illegibile;

– Colui che usa quotidianamente un linguaggio di programmazione ad oggetti come se fosse procedurale;

– Colui che pensa che lavorando sempre sullo stesso progetto è diventato ormai indispensabile;

– Colui che prende in giro gli sviluppatori junior vantandosi della sua seniority;

Scusate lo sfogo….

Mini rivisitazione dei progetti a cui ho partecipato

Avendo visto negli ultimi anni un bel pò di applicazioni .Net di ogni tipo, avendo partecipato ad un bel pò di progetti e conseguentemente visto una quantità considerevole di righe di codice, di seguito elenco (in ordine sparso) le mie considerazioni sulla qualità media del codice sorgente da me visionato e su cui spesso e volentieri sono intervenuto in prima persona per correzioni e/o nuove funzionalità (leggasi elenco di brutture e/o coding horror):

– La visibilità delle classi è una questione non tenuta nella giusta considerazione. Quando si crea una classe la si marca come “public”, e tale resta per sempre, anche se la classe potrebbe essere “internal”;

– il paradigma “Object Oriented Programming” è scarsamente applicato, ed anche scarsamente conosciuto, e cosi si finisce spesso per avere, solo a titolò di esempio, codice duplicato, scarsamente coeso e altamente accoppiato;

– Boxing e unboxing: concetto non conosciuto dai più, e cosi accade che il tipo “object” è usato a sproposito, e la tipizzazione dei dati diventa una rarità;

– Concatenazioni di stringhe a go-gò, anche se è arcinoto che questa operazione non è performante a causa dell’immutabilità dell’oggetto stringa che “stressa” parecchio il garbage collector;

– Utilizzo delle eccezioni nella logica di business dell’applicazione per notificare situazioni particolari;

– Utilizzo indiscriminato di Dataset/Datatable in ogni layer applicativo (front-end compreso), al posto di oggetti di dominio non anemici, cioè dotati di attributi e di comportamento (sì lo so, chiedo forse troppo, questo è Domain Driven Design…), con conseguente profilerazione di classi per la gestione delle entità trattate dalla applicazione, es. CustomerManager, OrderManager, ecc.
Su questo argomento potrei aprire una lunga discussione, circa colui che io definisco “il programmatore del dataset”;

– La modularità di una applicazione e il concetto di “Separation of Concern” (Soc)  non attira l’interesse della maggior parte degli addetti ai lavori. Come già discusso qui, è più importante rispettare i termini di consegna puttosto che creare software di qualità, ed ecco che si finiisce per scrivere software quasi monolitici, dove le responsabilità si “accavallano” in modo netto ed evidente tra i vari moduli. In applicazioni ASP .Net il code-behind si è spesso rivelato una trappola, nel senso che la classe “pagina” contiene una quantità spropositata di codice, ad esempio negli event handlers, alla faccia del concetto di basso accoppiamento;

– Assenza di Unit Test, non nel senso che nessuno li scrive ma nel senso che il Test Driven Development per molti è una sigla non pienamente compresa; in quei pochi scenari in cui ho visto scrivere Unit Tests questi non erano mai strutturati nel modo corretto secondo lo schema arrange-act-assert ma erano per lo più invocazioni di metodi a scopo di debugging. In pratica, più che “Sviluppo guidato dal test” ho visto l’esatto opposto.

Fortunatamente ho anche visto codice scritto benissimo, bene, o almeno in modo decente

Settore ingegneristico o artigianale ?

Poichè mi piace tenere insieme i miei pensieri su questo blog, riporto la mia risposta all’amico Andrea Saltarello sullo spinoso tema da lui sollevato in un thread sul forum di GUISA, ovvero “ma siamo solo artigiani ?”

“Hai perfettamente ragione quando affermi che “siamo un settore artigianale”, e ciò dipende a mio avviso
dal fatto che non tutti sono disposti a migliorarsi professionalmente per comprendere “il perchè” piuttosto del “come”.
Molti sanno come impiantare un sito Web MVC; pochi conoscono però il pattern, ancora meno sanno che quel pattern si chiama “Model 2” e non MVC; qualcuno addirittura non conosce nemmeno il significato dell’acronimo, ma tutti però ci spacciamo come architetti poichè, come affermi giustamente, “architetto” è una buzzworld figa da mettere sul bigliettino da visita o nella firma elettronica della mail.
Questo è solo un esempio, ma ne potrei citare molti altri.
Come sicuramente ben sai, esistono realtà IT dove ad una applicazione è richiesto solo che funzioni; non è minimamente richiesto e non si ha nemmeno la consapevolezza dell’importanza di avere software modulare che evolve nel tempo con il minimo impatto sulle funzionalità esistenti.

La qualità del prodotto software è una caratteristica scarsamente apprezzata, anche dagli stessi addetti ai lavori; ciò che conta è consegnare la versione 1 funzionante, per poter fatturare, non importa come viene sviluppata.

Qesto è un settore dove “i fiorellini” non sono richiesti.

Quindi, altro che TDD e sviluppo incrementale… “

Quando applicare una metodologia alla cieca è controproducente…

Spesso applicare una metodologia per il gusto di farlo, oppure solo perchè si è un profondo sostenitore di una certa tecnica ignorando completamente il contesto in cui si sta operando, può essere più deleterio che non applicarla proprio, e si finisce per avere una attenzione maniacale ai dettagli (che di norma costtuiscono il dogma della metodologia / tecnica che si sostiene), anche ai più insignificanti e più difficili anche solo da notare, e contemporaneamente una completa disattenzione per aspetti molto più evidenti che emergono giorno per giorno, ai quali si finisce poi per non dare il giusto peso.

L’argomento di questo post sono le metodologie di gestione di un progetto software con elevata complessità e criticità, ed il post è volutamente ermetico, ma sicuramente, rileggendolo a distanza di tempo, mi ricorderò molto bene del contesto che mi ha portato a sfogarmi con un post come questo.

Considerazioni molto personali sul lavoro nel mondo IT

Negli ultimi tempi sono stato coinvolto in una attività di recruitment mirata a reperire figure professionali nel mondo IT con skill particolarmente elevato, diciamo una figura di senior developer con conoscenze anche in ambito architetturale. Ho accettato con entusiasmo questa attività poichè ero curioso di capire se la preparazione universitaria in ambito informatico fosse sufficientemente in grado di reggere l’impatto con il mondo del lavoro e con la realtà di tutti i giorni (questo ovviamente per i laureati, ma lo stesso discorso può essere applicato anche per chi laureato non è).

E le sorprese non sono mancate.

Ecco, in sintesi, le mie considerazioni:

– Una laurea non è assolutamente garanzia di preparazione e competenza. Spesso i neolaureati, si “adagiano sugli allori”, pensando che il loro titolo di studio basti e avanzi, ma in realtà non è così, poichè i ritmi con cui si evolve la tecnologia sono talmente elevati che solo con una spiccata dose di passione e/o sacrificio è possibile essere aggiornati in modo almeno sufficiente;

– L’attività di senior developer o comunque qualsiasi attività prettamente tecnica spesso sono viste come attività “rognose” e molto impegnative, per cui le ambizioni dei candidati a volte si spostano verso ruoli di più alto livello, o comunque non a stretto contatto con la tecnologia (es. coordinatore di risorse o addirittura analista funzionale);

– I cv sono spesso gonfiati a sproposito. Per un appassionato non c’è nulla di male nell’inserire “ottima conoscenza teorica di …..” senza aver avuto la possibilità di mettere in pratica questa conoscenza. Diverso è inserire esperienze anche pluriennali senza alcuna valenza. Non è possibie sentirsi dire che non si sono mai utilizzate le caratteristiche più elementari del polimorfismo quando sul cv è scritto “pluriennale esperienza nella programmazione ad oggetti”, oppure “ottima conoscenza di ASP. NET” e poi non si sa a cosa serve il ViewState;

– L’atteggiamento del candidato durante una intervista non è spesso quello giusto da tenere in situazioni del genere, dove, a mio avviso, occorre mostrare soprattutto umiltà di fronte a ciò che si conosce e soprattutto di fronte a ciò che non si conosce;

Fortunatamente si incontrano anche persone appassionate di questo lavoro e competenti, che ripagano ampiamente gli sforzi effettuati.

Visual Basic Tips & Tricks Community Day a Milano

Ieri pomeriggio ho partecipato al Visual Basic Tips & Tricks Community Day tenutosi a Milano.

Devo dire che è stato un pomeriggio decisamente interessante dal punto di vista tecnologico, permettendomi di focalizzare alcuni concetti su tecnologie che uso o che vorrei usare, e mi riferisco a TFS 2010 ed Entity Framework 4.0

L’evento si apre con una sessione di Lorenzo Barbieri che parla delle varie versioni di Visual Studio 2010 che saranno disponibili a breve e delle novità, veramente tante, della nuova versione dell’IDE.

In ordine sparso:

  1. Possibilità di effettuare ricerche parziali con l’Intellisense;
  2. Intellisense nei file Javascript migliorato, ora vengono risolti anche i simboli presenti nei files inclusi, e non solo quelli del file in debugging;
  3. Funzionalità di “search a you type”, per intenderci tipo Google quando ci presenta i risultati della ricerca mano a mano che scriviamo il testo da ricercare;
  4. Funzionalità di “Call Hierarchy”, per il momento presente solo con il linguaggio C#, ovvero la possibilità di navigare a partire da un metodo / proprietà / costruttore verso il codice chiamante / chiamato a partire dal punto di navigazione scelto;
  5. Modalità “Web only” dell’IDE, ovvero la possibilità di utilizzare un IDE con il solo codice in primo piano e tutte le finestre di dialogo minimizzate;
  6. Selezione del testo per colonne;
  7. Gestione degli add-in con un apposito Extention Manager dedicato;
  8. Intellitrace (feature molto molto utile ed interessante per troubleshooting), ovvero un componente capace di registrare tutto quello che avviene nel codice quando questo è in esecuzione, una specie di scatola nera dell’applicazione, utilizzabile su applicazioni scritte con la versione 2.0 del Framework in poi ;
  9. Test di automazione della UI;

Poi è stata la volta di Alessandro Del Sole, che ha mostrato le novità di Team Foundation Server 2010 in ottica singolo sviluppatore o piccoli gruppi di lavoro.

Successivamente Antonio Catucci ha mostrato le novità di Entity Framework 4.0, ovvero:

  • Possibilità di gestione della Foreign Key nel modello dati, senza che la stessa sia nascosta (come è noto nel mondo dei database relazionali una relazione tra 2 tabelle si traduce con la presenza di una colonna in comune tra le due tabelle, che costituisce appunto la relazione, nel mondo OOP una relazione di questo tipo si traduce con la presenza di una proprietà tipizzata nell’oggetto “padre”);
  • “Lazy Loading” attivo sempre di default;
  • “Pluralization” dell’Entity Set basato sulla grammatica inglese. Con Entity Framework 1.0 questa mancanza mi ha provocato qualche problema, in quanto va gestito a manina;
  • “Model-First Design”, feature decisamente interessante che consente di creare un domain model senza che sia necessariamente presente un database da cui partire. Con la versione 1.0 il domain model è forzatamente creato a partire da una base dati esistente;
  • “T4 Code Generation”. Con questa feature il codice generato da Entity Framework può essere basato su template, fornendo quindi la possibilità di generazione personalizzata dello stesso.
  • “POCO Entity (Plain Old CLR Objects)”, anche questa è una feature molto interessante, ovvero la possibilità di usare nel Domain Model della classi “pulite”, magari già esistenti senza che debbano per forza di cose ereditare da una classe specifica di Entity Framework;
  • Gestiona automatica delle relazioni molti a molti, senza la visualizzazione della terza tabella di legame tra le due relazionate;
  • Nuovo controllo EntityDataSource per il binding dei dati in ASP .NET.
  • Metodo “ApplyCurrentValues”. Permette di gestire le modifiche apportate su oggetti “detached”, ovvero al di fuori dell’ObjectContext attivo, e di propagare le stesse modifiche sull’oggetto avente la stessa chiave presente nell’ObjectContext (oggetto “attached”).
    Come è evidente la versione 4.0 di Entity Framework contiene una pletora di novità, che sicuramente consentiranno a questo ORM made in Microsoft di superare alcuni limiti di “gioventù” della precedente versione.

Anobii, la mia libreria virtuale

Finalmente ho modo di mettere un pò in ordine la mia libreria, non fisicamente ma almeno virtualmente. Ho infatti creato su Anobii, un social network incentrato totalmente sui libri, la mia libreria virtuale dove piano piano organizzerò per argomento i numerosissimi libri in mio possesso, tecnici e non, onde consentire anche ai più curiosi di darci una sbirciatina per curiosare cosa conservo gelosamente sui miei scaffali.

Qui è accessibile il mio scaffale virtuale, per il momento ancora molto limitato.

Java meglio di .NET ?

Il titolo di questo post è volutamente ironico, ed affronta un argomento all’ordine del giorno in ogni ambiente di lavoro e/o community in cui si ha a che fare con le tecnologia legate al mondo del software.
In questi ambienti capita spesso infatti di sentire o di partecipare a discussioni circa il fatto che quella o quell’altra tecnologia prevale a parità di contesto di utilizzo, es. Java è meglio di .NET,  Oracle è meglio di Sql Server, o viceversa.
Questi dibattiti, per quello che è la mia esperienza sul campo, sono spesso e volentieri condizionati dalla unilaterale conoscenza di una particolare tecnologia, e raramente colui che l’appoggia ha una consolidata esperienza su entrambe le piattaforme.
Ho assistito molto spesso a discorsi tipo:

“questo pezzo di codice se fosse scritto in Java non avrebbe quel bug…“,

oppure

“se questa query fosse in PL-SQL le prestazioni sarebbero sen’altro migliori“.

In questo interessantissimo post di Scott Guthrie in merito all’ultimo dibattito tecnologico in essere tra gli sviluppatori web (meglio ASP .NET Web Forms o ASP .NET MVC ?), è sintetizzato il mio pensiero sull’argomento:

“Great developers using bad tools/frameworks can make great apps. Bad developers using great tools/frameworks can make bad apps. Be very careful about making broad assumptions (good or bad) about the quality of the app you are building based on the tools/frameworks used”.

Sono le persone che partecipano allo sviluppo a rendere vincente o perdente un software, a prescindere dalla particolare tecnologia applicata, ed è un grave errore pensare che solo perchè si è scelto di utilizzare l’ultima moda tecnologica un progetto software debba per forza essere vincente.

Piccolo sfogo…

Una pensiero che spesso mi viene in mente guardando il codice sorgente è: ma perchè scrivere in 10 righe di codice quello che potrebbe essere scritto in una o due righe ?

Le direttive using devono essere poste all’interno del namespace

Questo post inizia con una frase tratta da un post di Scott Hanselmann con cui mi trovo completamente d’accordo:

Don’t believe everything you read, even on a Microsoft Blog.             

Don’t believe this blog, either!

Decide  for yourself with experiments if you need a tiebreaker!

Credo sia proprio vero, mai fidarsi ciecamente di quello che si legge in giro, soprattutto quando seri dubbi farebbero pensare il contrario.

Il motivo è presto detto: utilizzo normalmente FxCop come strumento di analisi del codice sorgente, lo trovo molto completo e ben fatto. Spinto dalla curiosità ho voluto utilizzare Source Analysis, un tool gratuito fornito da Microsoft ed integrato nell’IDE di Visual Studio. Dopo la primissima prova fatta mi ha incuriosito una sua segnalazione:

SA1200 – All using directives must be placed inside of the namaspace.

Per farla breve, tutti i files sorgenti del mio progetto provocavano una segnalazione di questo tipo poichè le direttive using erano poste esternamente alla definizione del namespace, così come automaticamente viene creato uno scheletro di una classe all’interno dell’IDE. La segnalazione in questione invita invece ad includere le direttive using all’interno della definizione del namespace, semprecchè sia presente. Facendo qualche ricerca in giro ho scoperto che in questo modo il compilatore segnala immediatamente una eventuale ambiguità tra i nomi dei tipi creati all’interno del proprio namespace e i tipi presenti nei vari namespace del .NET Framework. E fin qui nulla di strano.

Ho scoperto inoltre che questa guideline servirebbe anche ad aumentare le prestazioni, almeno nei casi specifici, in quanto forzarebbe il “lazy loading” degli assembly e non il caricamento immediato. In altre parole, quando il viene invocato un metodo di una classe e viene compilato il codice “just in time” (JITTED) il lazy loading permette di caricare in memoria solo gli assembly referenziati che servono all’invocazione del metodo stesso, e non tutti gli assembly referenziati da una classe, a prescindere se utilizzati o no da una specifica invocazione di un metodo. Questo permette di caricare solo lo stretto necessario anche se una classe referenzia un assemby non utilizzato da un metodo.

Sinceramente non mi è venuto in mente un solo valido motivo per cui una direttiva using posta in un certo modo potesse influenzare l’attività del CRL a runtime, e sono rimasto alquanto dubbioso sulla effettiva validità. Prima che potessi avere il tempo di fare una prova specifica mi son trovato questo post di Scott Hanselmann, al quale rimando per una esauriente spiegazione, che dimostra come purtroppo ciò non sia affatto vero, cioè gli assembly referenziati vengono caricati tutti i memoria immediatamente, a prescindere se il metodo in questione li usa oppure no, ed a prescindere se le direttive using vengono poste all’interno o all’esterno della definizione di namespace.

Quindi la morale è: non credere mai a quello che leggi, neanche se lo leggi da questo blog :), ma sperimenta sempre.

Tecnologia in evoluzione ed il suo utilizzo

In questi giorni mi è capitato frequentemente di leggere su blogs e forum vari commenti entusiastici sull’adozione delle ultime tecnologie appena sfornate – parlo di Silverlight, Ajax e LINQ, le quali hanno ormai preso prepotentemente piede nello sviluppo di applicazioni. Premesso che utilizzo anch’io sia Ajax che LINQ, ritengo che il tutto debba essere calato nel contesto opportuno di utilizzo, senza lasciarsi prendere troppo dall’entusiasmo come invece vedo che accade. Può sembrare scontato ma la realtà è ben diversa. Comprendo perfettamente che lo sviluppatore esperto e soprattutto appassionato affronti le sfide tecnologiche che molto frequentemente il nostro mestiere ci offre, con l’entusiasmo di un ragazzino, ma credo che ultimamente si stia un po’ esagerando. Sembra quasi che oggiogiorno ogni applicazione web debba essere necessariamente Ajax-enabled e sembra che LINQ to SQL, o meglio gli ORM in generale, abbiano sostituito di colpo l’utilizzo di strumenti per così dire tradizionali quali le store procedure, diventate improvvisamente uno strumento superato. Riflettendo un attimo, questo entusiasmo non è certo una novità nel mondo delle tecnologie software: come esempio non isolato, ricordo che  successivamente all’introduzione dei web services tutti gli utilizzatori di software hanno adottato incondizionatamente questa tecnologia anche se le loro applicazioni non erano affatto interoperanti se non con sè stesse…L’unificazione del paradigma di sviluppo in funzione dei diversi contesti di utilizzo si è verificata solo con l’avvento di WCF. Accadrà lo stesso con le attuali tecnologie ?

Ugialt.net

Prendo a prestito delle parole di Antonio Carpentieri per descrivere il perchè ho aderito con entusiasmo all’iniziativa ugialt.net:

“…..Ha un mix di agile + object-orientation + patterns + TDD + DDD. Perchè per ognuno dei punti di cui sopra esistono degli strumenti che permettono di applicarli in .net, perchè li USO, perchè spesso ho dei dubbi, delle perplessità ma nonostante queste effettuo delle scelte sia di design, che di processo e VOGLIO informarmi su come altri stanno lavorando, fanno evolvere i pattern di design o del processo perchè cerco il modo migliore di comunicare e motivare delle scelte tecniche che agli occhi di un manager che vede solo “the microsoft way” possono risultare solo le scelte di un geek… ecco, io mi sento a casa in mezzo a persone che hanno questo spirito. Condividere per crescere. Creare senza aspettare.”

I want to be a developer

Chi svolge l’attività di consulente informatico, magari con mansioni di senior developer o affini, potrebbe a volte trovarsi nella condizione di vedersi offerta una attività di più alto livello rispetto al “semplice” sviluppatore, es. team leader, analista funzionale e via dicendo. Normalmente questa nuova attività porta inevitabilmente ad un progressivo allontanamento da quelli che sono gli aspetti tecnici più spinti, per concentrarsi maggiormente sul coordinamento di persone e/o attività. Questa tendenza è più accentuata in coloro che hanno maturato anni di esperienza nell’applicare sul campo la tecnologia appresa sui libri, e che arrivano ad un bel momento in cui si stancano di rincorrerre le nuove tecnologie, e preferiscono consolidare e mettere a disposizione la propria esperienza a favore di gente più giovane è più fortemente motivata a crescere. Questa è la situazione più comune in cui ci si può imbattere. Al contrario, chi mi conosce sa come la penso, ovvero che non esiste altra attività che possa regalarmi soddisfazioni se non quella di scrivere codice. Una volta, ad un colloquio di lavoro, non molto tempo fa, l’esaminatore mi chiese: “Ma Lei vuole fare il programmatore tutta la vita ?”. La mia risposta fu ovviamente SI. Non c’è nulla che possa regalarmi più soddisfazioni professionali di star dietro alle nuove tecnologie e di metterle in pratica.

Quindi:

I WANT TO BE A DEVELOPER !!!

Considerazioni molto personali sui blog ed i loro utilizzo

Questo post è da un pò di tempo che mi frullava per la testa. Riguarda l’utilizzo del proprio blog, o meglio di cosa scrivere e soprattutto non scrivere. L’occasione di decidermi (ma soprattutto di trovatre il tempo) finalmente a postare su questo argomento l’ho avuta leggendo la recentissima diatriba scatenatasi su ugidotnet sul  corretto utilizzo del proprio blog nel contronti dell’aggregatore, ovvero del muro. Premesso che il blog di ugidotnet è quello che leggo più spesso e più volentieri, insieme ai blogs di Devleap, perchè trovo interessanti i diari dei rispettivi blogger.

Qui sta il nocciolo della questione, ovvero l’utilizzo di uno strumento quale il blog viene a volte frainteso o forse viene frainteso il vero significato della parola blog.

Esso è un diario elettronico visibile pubblicamente, ma non obbligatoriamente, e di natura strettamente personale; quindi uno sul proprio blog può scrivere quello che preferisce e trattare gli argomenti che preferisce, entro i limiti della decenza e dell’educazione. Trovo assurdo il comportamento di chi si permette di censurare il contenuto dei post altrui solo perchè ritenuti fuori contesto o forse solo non graditi, o forse con il difetto di essere presenti sul muro. Leggere il blog altrui è assolutamente non obbligatorio; non è necessario sottoscrivere l’intero muro, basta sottoscrivere solo i blogs preferiti. Ma anche sottoscrivendo l’intero muro non occorre un grande sforzo a saltare i post ritenuti poco interessanti.

Molti blog che leggo o che mi passano sotto gli occhi nell’aggregator contengono post che reputo interessanti, ma anche post di autocompiacimento ed autocelebrazione, pensati soprattutto per far colpo su chi legge, moltissimi inerenti le certificazioni Microsoft o il superamento di un esame. Sia chiaro, non trovo nulla di male ad autocompiacersi per aver superato un esame di certificazione, fa parte del diario personale di una persona, e se lo trovassi noioso salterei il post, come mi capita spessissimo di fare. E’ invece un errore, a mio avviso, censurare i post altrui perchè ritenuti fuori luogo o addirittura nocivi all’immagine di una community. L’errore sull’errore sta nel pensare che altri debbano scrivere post in linea con i propri gusti, e nel sentirsi in dovere di censurarli. Questo post di Alessandro Scardova è la perfetta sistesi del mio pensiero, e su cui mi trovo perfettamente d’accordo.

Questo è anche il motivo per cui ho preferito scrivere i miei post su xplayn.org, da me fondata insieme ad un amico, e non su community certamente più affollate e sicurissimamente con un numero di pageview molto maggiore. Io non scrivo solo perchè altri possano leggere i miei post; anzi, se nessuno li leggesse per me non cambierebbe nulla, io scrivo per me stesso; se poi qualche lettore trova interessante quello che scrivo è tanto di guadagnato per me, ma non è certamente questo il mio obiettivo.

Taggato !!

Speravo di farla franca ma l’amico Mighell ha pensato bene di taggarmi ! Quindi adesso tocca a me: ecco le 5 cose che pochissime persone (forse nessuna…) conosce di me:

1) Ho tante passioni che non riesco a vivere come vorrei causa mancanza di tempo (chiamateli hobby….) e sono, in ordine sparso: astronomia, astrofisica, fisica quantistica, scacchi (il mio sogno è stato sempre battermi con l”International Woman Grandmaster Alexandra Kosteniuk, senza però che pensate a male ), tecnologia in generale. Insomma, roba pesante, e qui mi fermo perchè altrimenti divento prolisso! E’ chiaro che sono sempre stato attratto dalle cose complesse….il primo linguaggio di programmazione che ho affrontato sul serio è stato il C.

2) All’età di 5-6 anni ho rischiato seriamente di morire bevendomi, a causa della mia curiosità già supersviluppata, nientepopodimeno che …..la varechina ! Mi ha salvato una immediata lavanda gastrica (fortunatamente l’ospedale era giusto di fronte a casa mia…)

3) Il mio più grande cruccio è quello di non aver affrontato sul serio la scuola (anche se sono riuscito comunque a diplomarmi), e soprattutto di non aver intrapreso gli studi universitari (non è mai troppo tardi direbbe qualcuno, ma…)

4) Adoro la musica rock-blues e la chitarra elettrica; la folgorazione è avvenuta all’età di 15-16 anni ascoltando i mitici Led Zeppelin, e la musica dei Doors

5) Ho 4 nipotini a cui voglio un mondo di bene; uno in particolare, si chiama Alessandro, mi somiglia tantissimo, in tutti i sensi, è come se vedessi me stesso allo specchio quando avevo 8-9 anni.

E adesso, tagghiamo, tagghiamo, anche se sono arrivato tardi e la lista si è alquanto ristretta: Francesco Quaratino, Gianluca Cannalire, Marco Russo, Vito Carella, Antonello Tesoro

BizTalk o Workflow Foundation ?

Mi è capitato spesso di assistere a dialoghi tecnici del tipo: ‘ma conviene usare Workflow Foundation oppure BizTalk per quel particolare progetto ?’. A prima vista questi 2 prodotti sembra che si sovrappongano; infatti, semplificando parecchio, ambedue forniscono funzionalità per costruire un processo basato su workflow. Ma è solo una impressione poichè sono profondamente diversi. Un utilissima check-list che aiuta a capire quale strumento si adatta meglio allo specifico progetto è disponibile attraverso questo post di Irena Kennedy. La checklist inquadra i requisiti che giustificano l’uso di BizTalk, oppure in loro assenza di Workflow Foundation.

Molto interessante questo estratto:

…….  Biztalk is product that provides scalable deploying and hosting model, built-in integration with many applications and protocols, a runtime configurable instrumentation framework, central management, monitoring and tracking, message mapping and transformation services, batch processing, publish/subscribe mechanism, engine throttling, scale out support, reliability, fail over, deployment tools, business rules engine, etc. 

WinWF is a set of class libraries, it’s a developer framework used to build workflow into custom applications.

 

So, are you creating an intra-application workflow (page flow wizard, control flow, a business logic implementation that has multiple activities, state machine, etc)?  Will your application host the workflows itself?  If yes, WinWF will likely satisfy your needs.

 

Mi piacerebbe conoscere il pensiero dell’amico Mighell sull’argomento, che di Workflow Foundation sicuramente ne sa parecchio, visto l’evento del maggio scorso, l’ultimo webcast, e soprattutto il prossimo workshop “.NET Present & Future” che si terrà a Bari il prossimo 26 Ottobre.

Fonte: http://blogs.msdn.com/irenak/archive/2006/10/11/sysk-216-biztalk-orchestration-or-windows-workflow-foundation.aspx

Da VB6 a VB.NET ….

Premessa:
ho iniziato a programmare seriamente (per lavoro) utilizzando il linguaggio Visual Basic; ho utilizzato questo linguaggio per parecchi anni nelle varie versioni che via via si sono succedute (3.0, 4.0, 5.0, 6.0). Su questo linguaggio ho investito parecchio tempo sia per apprenderlo che per approfondirlo, ricevendo un enorme aiuto dalle community quali Visual Basic Tips & Tricks, solo per citarne una. Ho anche investito del denaro, in quanto i primi esami di certificazione Microsoft che ho passato riguardavano VB6 Desktop & Enterprise, comprandomi libri sull’argomento e pagandomi i test di tasca mia.
Ho scritto parecchie linee di codice in VB6, e le soddisfazioni professionali non sono mancate; ho considerato questo linguaggio altamente produttivo e facile da imparare, ma, confesso, alcune volte mi sono scontrato con problemi non facili da superare dovuti essenzialmente alla intrinseca facilità del linguaggio che tende a mascherare dettagli importanti della programmazione a beneficio della velocità di scrittura del codice.

Con l’avvento di .NET  ho utilizzato da subito il linguaggio Visual Basic .NET, soprattutto perchè provenivo dal VB6 e mi è sembrato naturale continuare ad utilizzare la stessa sintassi, conscio però del fatto che la semantica era completamente diversa. Ho approfondito parecchio la conoscenza del .NET Framework, e questa conoscenza mi ha agevolato tantissimo quando ho dovuto per forza di cose programmare in C#; infatti questo linguaggio l’ho appreso nel giro di pochi giorni poichè il tutto si limita all’apprendimento della sintassi tipica dello stesso, e questo grazie all’indipendenza del Framework .NET dal linguaggio utilizzato.

Adesso uso i due linguaggi in modo intercambiabile, ma la mia preferenza è senza ombra di dubbio per il C#, poichè, a mio avviso, nonostante il VB .NET sia completamente diverso dal suo predecessore, sia finalmente un vero linguaggio ad oggetti e fornisca la stessa potenza del C#, soffre ancora di qualche retaggio del suo passato di linguaggio “facile” ed alla portata di tutti.
 
Sono sicuro che se dovessi aver bisogno di programmare in un altro linguaggio .NET compliant, l’apprendimento dello stesso non durerebbe più di qualche giorno,e questo non per merito mio ma del framework .NET.

Questa lunga premessa mi è saltata in mente leggendo queto interessantissimo post di Diego Cattaruzza in risposta a questo articolo dove si pone in risalto il fatto che Microsoft “costringerebbe” i programmatori VB6 a passare forzatamente a Visual Basic .NET poichè il supporto per VB6 terminerà a Marzo del 2008.

La mia opinione è che Microsoft abbia fatto tantissimo per agevolare questo passaggio, in ordine sparso:

  • Eventi gratuiti dove si cerca di fornire una risposta agli interrogativi di chi ha codice VB6 da migrare;
  • Rilascio di Visual Basic .NET 2005 Express, versione gratuita dell’ambiente di sviluppo che, seppure con qualche limitazione, permette quantomeno di provare in prima persona la nuova tecnologia;
  • Disponibilità gratuita di blocchi di codice (Application blocks) già pronti all’uso per fornire immediatamente le funzionalità comuni di ogni applicazione (log, configurazione, accesso ai dati,ecc)
  • il termine della fine del supporto per VB6, inizialmente fissato a Marzo 2005, è stato spostato a Marzo 2008, anche grazie alla famosa petizione internazionale sottoscritta da oltre 10000 programmatori;

Inoltre, come sottolinea chiaramente e giustamente lo stesso Cattaruzza, la vecchia infrastruttura basata sull’accoppiata Win32/COM+ è assolutamente inadeguata a sostenere l’evolversi dei sistemi di comunicazione attuali; la nuova infrastruttura è basata sul .NET Framework e quindi non ha assolutamente senso continuare a supportare un linguaggio basato su una piattaforma ormai superata.

Questo discorso resta valido anche per il cosiddetto “programmatore hobbysta”, perchè se cambia l’infrastruttura sottostante lo sviluppo di software basato su Win32 e COM+ perde di significato.

Infine, un parere personale che ritengo di fondamentale importanza: l’evoluzione tecnologica per un informatico deve essere un aspetto da non mettere mai in discussione; è errato pensare che solo perchè si è speso tempo e denaro per essere padroni di una tecnologia non ci si possa rimettere in discussione spendendo altro tempo per impararne un’altra, più evoluta della precedente che permette di essere più produttivi e di scrivere software più efficiente. Questo lo afferma una persona che ha speso tantissimo tempo e denaro su VB6, ma cha ha fatto altrettanto quando l’evolversi della tecnologia lo ha messo di fronte a strumenti più evoluti.
Se si pensa che aver fatto sacrifici per impadronirsi di una tecnologia basta per mantenersi a galla nel mondo informatico sempre in continua evoluzione si commette un grave errore che può riflettersi negativamente sul proprio futuro professionale.

 

xplayn.org sponsorizza la DevCon2006

Con grande piacere mio e degli amici di xplan.org siamo tra gli sponsor della DevLeap Conference 2006, un evento annuale organizzato da DevLeap e dedicato agli approfondimenti delle nuove tecnologie legate al mondo degli sviluppatori.

Ho sempre apprezzato DevLeap per i contenuti tecnici di altissimo livello che è possibile consultare attraverso il loro sito, pieno zeppo di articoli tecnici di approfondimento, adatti quindi a lettori in possesso di una certa esperienza della tecnologia e non già alle prime armi.

Circa 2 anni fa ho avuto la fortuna di conoscere personalmente Marco Russo, a Bari per una conferenza Microsoft sulla sicurezza della piattaforma .NET, e di partecipare ad una cena post-evento organizzata dall’amico Gianluca Cannalire.

Non mi lasciai sfuggire l’occasione di parlare con Marco degli argomenti più svariati, non ultimo le certificazioni Microsoft visto che lui ne possiede “qualcuna”.

Sinceramente rimasi sbalordito dalla vastità delle sue conoscenze informatiche, che spaziavano dallo sviluppo puro del codice all’architettura Win32, alla Business Intelligence ed a molto altro Già durante la conferenza Marco aveva dato prova della sua abilità mostrando, ricordo, alcune tecniche di “code injection” effettuate con una semplicità disarmante da un programmino C++ di poche righe.

Da allora, anzi da prima ancora, il suo blog (ma anche quello delle altre persone di DevLeap, come Paolo Pialorsi e Roberto Brunetti) è oggetto di quotidiana lettura da parte mia, dove è possibile leggere riflessioni molto interessanti sulla programmazione e sulla Business Intelligence.

Ho partecipato e partecipo tutt’ora ad un sacco di eventi per sviluppatori, ma ricordo ancora l’evento di Bari e soprattutto l’incontro con Marco con molto piacere.

"In pair programming" – Riflessioni

Leggendo questo interessante post di Luca Minudel  voglio dire la mia su un argomento per me di estrema attualità.
Sicuramente l’applicazione del cosiddetto “in pair programming” può dare i suoi benefici e rivelarsi determinante nei contesti opportuni circa la buona riuscita di un progetto; mi riferisco a:

1) Raggiungimento degli obiettivi
2) Rispetto dei tempi previsti (o anche riduzione degli stessi)

Il problema è che questa metodologia non può essere applicata alla cieca. Voglio dire con questo che se le forze in gioco sono complementari ed equilibrate e non manca il giusto spirito di condivisione della conoscenza, l’obiettivo è sicuramente raggiunto, anche con qualche difficoltà oggettiva dovuta agli strumenti che si utilizzano che spesso non sono così efficienti da gestire in modo sicuro il lavoro di due persone sullo stesso argomento.

Se invece le forze in gioco non hanno equilibrio si finisce per sovrapporsi creando inutili perdite di tempo, soprattutto quando la conoscenza è vista come un qualcosa di strettamente personale da non condividere con nessuno.