Exam passed: “MCTS – Windows Applications Development with Microsoft .NET Framework 4”

I am definitely not a guru of WPF but recently in my company I had to play with it a little bit and it was the right opportunity to prepare the certification.

The 15th of August 2011 I passed the certification exam:
“MCTS – Windows Applications Development with Microsoft .NET Framework 4”.

This is how looks my certification logo at the moment:

For many people certifications are not important or required. However, I believe that setting goals and achieve them is very exciting. If you studied at the university like me, you know what means passing an exam. Well, that kind of emotion allow you to continue towards higher goals.
This time I want to achieve the professial level MCPD.

Before this, I have to pass other two MCTS level certifications:

  • MCTS: .NET Framework 4, Data Access
  • MCTS: .NET Framework 4, Service Communication Applications

Let’s start 🙂

Before to finish, I want to underline some important aspects when you want to prepare a Microsoft certification:

  1. Don’t use only the official preparation book because it contains a subset of the required arguments.
  2. Read carefully the section “Skills Measured” and check that you covered all the subjects
    1. In this case, for example, it was easy to unnote that the exam included the Task Parallel Library and Parallel LINQ
  3. Take practise tests on MeasureUp is a big help and you shouldn’t understimate this

One thing that I liked is that, comparing to the last time I did an exam (two years ago), the complexity was higher. Questions were less trivial that asking what is the name of a certain method (useless questions). Questions were about concepts in order to test your deep knowledge of certain subjects. It seems clear the work that Microsoft is doing to make certifications more valuable.

Unit Test Lab il 24 Settembre 2011 – Tenetevi pronti

Ciao a tutti,
appena prima delle meritate vacanze estive DotNetToscana vuole rivelare alcuni dettagli del prossivo evento laboratorio.

La data à già stata fissata a Sabato 24 Settembre 2011 mentre il luogo deve ancora essere confermato.

Il laboratorio sarà guidato da Matteo Baglini mentre gli altri membri dello staff forniranno supporto tecnico ai partecipanti.

Segue una breve descrizione dell’evento:

Uno degli aspetti più controversi dello sviluppo software è sicuramente il test.
Pratica da molti reputata importante per ottenere un software di qualità ma allo stesso tempo snobbata. La realtà è che gli sviluppatori preferiscono progettare e realizzare il software piuttosto che testarlo lasciando quest’ultimo compito al team di tester. Esistono molteplici tipologie di test, lo Unit Test è uno di questi e rappresenta uno strumento importante per i tester, ma soprattutto per gli sviluppatori.
Durante questo laboratorio potrai provare con mano la pratica dello Unit Test e trovare risposta alle tipiche domande: perchè, come e quando effettuare Unit Test. Imparerai i principi che guidano lo Unit Test passando dalla teoria alla pratica, applicando questa tecnica in svariati contesti.
Maggiori dettagli seguiranno alla fine del mese,

Buone vacanze a tutti,

Vi aspettiamo,

Andrea

101 Ways to Motivate Yourselft and Others – My favourites

Recentely Sources of Insight published a really interesting post: 101 Ways to Motivate Yourselft and Others.

As a reminder, I would like to write the points I considere more important for me and where I want to work:

  • Act on your inspiration
    • “Use your best energy for your best results”
    • “Your passion can expire, if you wait too long or miss the window of opportunity”
    • “A common way to kill idea or momentum is to spread them out over time, or keep pushing them out”
  • Be a coach, not a critic
    • “Use your inner coach for constructive feedback, and give your inner-critic a break”
  • Be on fire
    • “You know when you’re on fire. You kno what you’re like when you’re in the zone and you’re fully engaged and you’re at your best. Sometimes, the easiest way to get back to this mode is to simply remember what if feels like”
  • Be YOUR best
    • “Compete with yourselft and make it a game”
  • Build your band of merry men
    • “Surround yourself with the people that inspire and deligh you, wherever you go”
  • Change the frame, to change your game
    • “Problems aren’t problems when you reframe them as challenges. Challenges are opportunities for growth, excellence and your personal best”
  • Chart your progress
    • “If you want to motivate, find a way to keep the score. Progress is the top motivator of performance. Even incremental progress boosts motivation”
  • Choose significant tasks that are meaningful for you
    • “If you like excellence, then challenge yourself to shine”.
  • Create a wall of inspiration
    • “Put those pictures up that show you the greates things in life and what’s possible. Get those hopes and dreams up on the wall that remind you what’s worth fighting for.”
    • “Put those wards on the wall and quotable quotes that fire you up and make you feel alive”
  • Decide
    • “Nothing builds momentum like decisive action. Just Decide.Decisive action is motivation, it build momentum and it crowds out excuses”
  • Do worst things first
    • “Don’t let things loom over you. Once they’re out of the waym the rest is a glide-path”
  • Don’t let feat stop you
    • “A great way to conquer fear is to put the fears on the table and find a way to take away the thread or prepare for the worst case scenario”
    • “The only thing we have to fear is fear itself”, Roosevelt
  • Don’t be perfectionist
    • “Perfection is a fallacy and it’s over-rated. A better focus is to be effective. Make it work, then make it right. Think of perfection as a process of improvement.”
    • “Focus on good enough for now. and satisfice”.
    • “Taking action is a key way to stay out of analysis paralysis, and keep your motivation strong. Don’t worry about the perfect place to start, just start”
  • Don’t look for execuse
  • Don’t take yourselft too seriously
    • “Build your sense of humor”
  • Eat, sleep and exercise on a cadence
    • “Your cadence will serve you emotionally, mentally and physically”
  • Find your “one thing”
    • “One thing matters to you most. Do more of that. That’s the thing to focus on”
  • Finish faster
    • “The faster you finish, the more you will finish. The more you finish, the easier it gets”
  • Focus on what you want
    • “Get a clear and compelling picture of what you do want and focus on that”
  • Play your favorite music
    • “Play the songs that make your spirit soar”
  • Reming yourself how short life is
    • “One way to give your fall is to remember that nothing lasts forever”
  • Set a deadline
    • “Knowing when something is due can help you funnel and focus your action and attention”
  • Set extreme goals
    • “Sometimes goals have to be extreme to feel worth it. Dream big. Set crazy limits or hurdles”
  • Want it with a passion
    • “Nothing beats the pursuit of a worhy and compelling objective”
  • Keep in mind that knowing and doing are two different things
    • “You hold the keys to unleashing what you’re capable of”

17 Discussione: metodi efficaci di apprendimento.

Ciao a tutti ragazzi,
sto leggendo il libro “Pragmatic Thinking and Learning” e mi sto soffermando su alcuni punti interessanti legati all’apprendimento.

In particolare io mi riferisco al nostro settore quindi all’apprendimento in ambito IT (tecnologia, design, architettura, metodologie, …).

Come sappiamo esistono differenti modi di apprendere:

  • Leggere libri
  • Realizzare un progetto personale
  • Apprendimento tramite esperienza in azienda
  • Apprendimento tramite corsi offerti dall’azienda
  • Partecipazione a sessioni tecniche e a community
  • Webcast
  • Podcast
  • Lettura di articoli / blog sul web
  • Mentoring
  • Gruppi di studio

Sicuramente tutti dobbiamo lavorare e quindi l’apprendimento tramite esperienza in azienda e’ abbastanza scontato ma a mio parere non e’ sufficiente per costruirsi una brillante carriera. Spesso in azienda sei costretto a compiere decisioni con una conoscenza incompleta mentre a me spesso piace un approccio graduale all’apprendimento che al lavoro non e’ quasi mai praticabile. Inoltre al lavoro non utilizzerai mai tutte le tecnologie ed e’ quindi necessario un lavoro esterno di compensazione e di espansione delle proprie conoscenze. Nonostante la partecipazione a community, il guardare webcast la mia fonte preferita di apprendimento sono i libri. Il motivo principale e’ che dietro al libro c’e’ un lavoro immane di raccolta materiale e riorganizzazione che e’ estremamente utile per il lettore che si ritrova una esposizione dei contenuti in maniera lineare e chiara. Tuttavia e’ noto che leggere richiede tempo e non e’ la forma preferita di apprendimento per l’essere umano che spesso impara piu’ velocemente imitando e osservando invece che leggendo.

Ci sono tantissimi professionisti che stimo e rispetto (e molti sono qui su ugi) con un bagaglio di competenza tecnica immenso che spazia campi di applicazioni diversi e sorge spontanea la domanda:

Qual e’ il vostro modo efficace di apprendere?

Come e’ evoluto nel corso degli anni?

Una classica risposta e’ con la pratica! Si e’ vero, capisco che la pratica e’ la chiave ma qui entra in gioco il fattore tempo.

Quanto tempo extra-lavoro dedichi all’apprendimento?

Io personalmente ne dedico molto in quanto sono estremamente appassionato ma misuro che i progressi non sono rapidi come vorrei.

Il mio manager dice che e’ solo una questione di esperienza ma non condivido la sua affermazione. Voi?

Condividete la vostra esperienza perfavore, penso che possa nascere una discussione interessante.

Per concludere vorrei riportare una frase significativa del libro:

“There’s always going to be a new technology or a new version of an existing technology to be learned. The technology itselft isn’t as important; it’s the constant learning that counts.”

Coding under pressure with TDD/BDD – Fantastica giornata

Ieri ho partecipato ad un originale evento open-space su TDD/BDD a Cambridge organizzato da Alan Hemmings e guidato da Alan Dean, il Chairman di ALT.NET UK nonche’ l’inventore degli Open Spaces Coding Days.

E’ stato davvero un fantastico evento e voglio condividere con voi la giornata.

Luogo
L’evento si e’ tenuto all’interno di una piccola azienda agile chiamate “The Agile Workshop”. Ringrazio Ronnie Barker e Stephen Oakman per l’accogliente ospitalita’ e la condivisione della loro profonda esperienza.

La mattina – Discussioni aperte
Prima di tutto a turno ci siamo presentati e abbiamo espresso le nostre aspettative per l’evento che si stava per svolgere. In questo modo Alan ha creato sulla lavagna un elenco puntato dei temi principali di discussione. Fatto questo abbiamo analizzato i vari punti e li abbiamo raggruppati in sezioni che alla fine erano praticamente due. Abbiamo quindi formato due gruppi di discussione indipendenti cercando di rispondere e condividere le proprie esperienze sui punti individuati. Fatto questo poi abbiamo unito tutti i gruppi e tratto alcune considerazioni finali. A turno ci e’ stato chiesto quale fossero le cose portate a casa da questa discussione.

Pranzo
La discussione ovviamente e’ continuata a pranzo in un pub inglese.

Il pomeriggio – Laboratorio
I temi di discussioni e una votazione preliminare hanno fatto emergere l’interesse di creare due laboratori paralleli:

  • Laboratorio base di TDD
  • Laboratorio avanzato di TDD/BDD

Sono stati nominati due persone per guidare ciascuno dei laboratori.
Io ho partecipato al laboratorio di base su TDD guidato da Alan Dean dove abbiamo svolto in pair programming un kata tratto dalla lista di eserci TDD per principianti: http://sites.google.com/site/tddproblems/

Il giudizio complessivo della giornata e’ veramente ottimo e mi ha permesso di conoscere molti appassionati programmatori inglesi allargando la mia rete di contatti professionali.

[Books] Coders at Work – Jamie Zawinski

Il libro Coders at Work contiene interessanti interviste a famosi programmatori.

In questo post voglio scrivere qualche commento all’intervista a Jamie Zawinski:

Cosa condivido:

  • Il modo migliore per immergersi in un pezzo di codice e’ prendere un task che si vuole realizzare e provare a farlo.
  • Se vuoi che il prodotto sia realmente cross-platform, devi rilasciarlo per tutte le piattaforme simultaneamente. Il risultato di un porting e’ un prodotto schifoso sulla seconda piattaforma.
  • La caratteristica che rende il codice piu’ facile da leggere sono i commenti. Scrivere le assunzioni e cosa fa un certo pezzo di codice.
  • Non essere spaventato dalla tua ignoranza. Se tu non capisci come qualcosa funziona, chiedi a qualcuno che lo sa. Non conoscere qualcosa non significa che sei stupido, semplicemente significa che tu non la conosci ancora.
  • Considera persone laureate che hanno utilizzato Java e mai C/C++ bizzarro e sbagliato.
  • Un aspetto chiave di un programmatore deve essere la curiosita’, voler sapere come le cose funzionano “under the hood”
  • Una importante capacita’ e’ essere capace di esplorare il codice scritto da qualcun altro e come utilizzarlo/modificarlo.

Cosa non condivido:

  • Gli Unit tests non sono critici. Se non ci sono unit test il cliente non si lamenta.
  • Il libro “Design Patterns” fa’ schifo. E’ giusto programmazione via taglia e incolla.

Insegnamenti e spunti per il futuro:
Ho meno di un anno di esperienza commerciale nello scrivere software e fino ad allora non avevo mai messo mano a software scritto da altre persone al di fuori di me. La prima grossa difficolta’ che ho provato dal primo giorno di lavoro e’ proprio quella di avere davanti una marea di codice gia’ scritto e doverlo capire e modificare. Credo sia abbastanza facile farsi prendere dal panico e imparare a farlo e’ veramente di una importanza cruciale nei nostri giorni dove e’ praticamente impossibile realizzare software di una certa rilevanza da soli chiusi in camera. Sembra proprio che non ci siano libri che trattino questo aspetto in una maniera sufficientemente chiara. D’altronde e’ un tema estremamente generico e l’esperienza e’ completamente diversa da software a software e da team a team. Una cosa pero’ ho capito dalla mia esperienza. Ho avuto modo di lavorare su codice legacy, senza test e senza una forte struttura e ho avuto modo di lavorare su codice veramente di ottima qualita’, ben commentato, ricco di test e con una struttura e dipendenze chiare. Inutile dirvi quanto l’immersione nel secondo progetto sia stata decisamente piu’ piacevole ed agile. Scrivere sofware di qualita’ ha molti vantaggi e questo e’ senz’altro uno di quelli.
Ho sempre avuto un approccio molto accademico alla programmazione: acquistare un libro, leggere gli esempi di codice, provarli e imparare creando qualche demo. Tuttavia questo approccio e’ particolarmente lento e forse per certi versi anche un po’ noioso. Ho sempre avuto un po’ di paura nel prendere e leggere codice scritto da altri, questo e’ stato il mio principale freno. Mi piace una introduzione sequenziale ad una tecnologia, con esempi di complessita’ crescenti che aiutino a comprenderla a fondo (appunto un approccio accademico). Tuttavia mi rendo conto che la fuori (anche in questa community) ci sono persone che imparano estremamente in fretta e forse uno dei motivi e’ proprio perche’ leggono (e scrivono) molto codice. Grazie a sofware open source abbiamo a disposizione una valanga di codice da cui trarre spunto e riflettere. Si tratta solo di iniziare a farlo sul serio…
Sito web del libro:
http://codersatwork.com/

[Books] Coders at Work – Brad Fitzpatrick

Il libro Coders at Work contiene interessanti interviste a famosi programmatori.

In questo post voglio scrivere qualche commento all’intervista a Brad Fitzpatrick.

Cosa condivido:

  • Io giusto assumo che qualcun altro non capira’ alcune delle invarianti che ho. Cosi’ praticamente mi assicuro di avere un opporunto test.
  • Tipizzazione statica e controlli a tempo di compilazione sono di grande importanza.
  • C++ ha una sintassi terribile e totalmente inconsistente e i messaggi di errore, almeno da GCC sono ridicoli. Puoi ottenre quaranta pagine di errori semplicemente perche’ hai dimenticato un punto e virgola.
  • Conosco persone molto intelligenti che conoscono solo Java. Io penso che e’ realmente importante conoscere l’intero stack anche se tu non operi all’interno dell’intero stack.
  • Un consiglio ai programmatori:
    • Sempre provare a fare qualcosa un po’ piu’ difficile, fuori dal quello che puoi pensare di realizzare.
    • Leggere codice. Non essere spaventato dal farlo. Dopo un po’ inizierai a vedere “pattern” nel codice scritto dagli altri.
  • E’ importantissimo avere un consistente stile di codifica all’interno del team/progetto che sia documentato e rispettato
  • Penso che la “pair programming” sia divertente. E’ ottima per molte cose e forza a non annoiarsi.
  • Non penso che il codice debba essere posseduto. Il codice e’ scritto dal team nella sua interezza e le revisioni di codice sono importantissime per mantenere alta la sua qualita’.
  • Un grande programmatore ad un colloquio si riconosce anche da cose che ha fatto nel tempo libero senza avere obblighi. Questo dimostra passione.
  • Non pensare di conoscere un algoritmo senza averlo mai scritto personalmente. Scrivere un algoritmo ti forza a capire tutti i casi limite e quindi lo imparari veramente
  • Le persone non vogliono scaricare programmi ora che esiste il web.
  • Essere personalmente coinvolti in community permette di crescere e incontrare persone di grande rispetto.
  • Non fidarti ciecamente del codice scritto da terzi o della documentazione. Prima scrivi un test che usa le funzioni che intendi usare per assicurarti che funzionino.
  • E’ importante pensare come uno scienziato. Avere pazienza e provare a capire la casa principale delle cose. Impara a scrivere le cose in modo incrementale cosi che in ogni fase tu possa verificarle.
  • Puo’ essere utile qualche volta scrivere qualcosa in un linguaggio nuovo e con cui non sei a tuo agio in modo da migliorare come programmatore.
  • Ricordati che in un team tutti dipendono da tutti. La collaborazione e’ fondamentale.

Insegnamenti e spunti per il futuro:
Condivito praticamente tutti gli aspetti principali sollevati da Brad.
Anche lui come Jamie Zawinsky riflette sull’importanza di imparare a leggere il codice scritto da altri, qualcosa sui devo assolutamente lavorare.

Sito web del libro:
http://codersatwork.com/

4 Il mio anno 2010 e i miei piani per il futuro.

Ciao a tutti ragazzi.
Con estremo ritardo voglio pubblicare anch’io la mia lista di cose fatte nel 2010.
Questo anno e’ stato veramente intenso e puo’ essere considerato come un anno di svolta nella mia vita.
E’ praticamente l’anno in cui ho iniziato a lavorare e a diventare indipendente dai miei genitori.

Cosa ho fatto nel 2010 (cercando di mantenere un certo ordine temporale):

  • Sono rientrato dall’Italia dopo le vacanze natalizie.
  • Ho preso un appartamento in condivisione a Londra.
  • Ho spostato la mia roba dalla casa famiglia in cui ero durante il mio corso di inglese nel nuovo appartamento.
  • Ho iniziato a cercare lavoro e a prepararmi ai colloqui.
  • Una macchinetta a Londra mi ha mangiato la carta postepay e ho dovuto sopravvivere con pochi contanti in attesa di aiuto dalla madre patria (i miei genitori).
  • Ho aperto un conto corrente bancario in UK.
  • Ho fatto due colloqui uno a Londra e uno a Cambridge ma non sono stato assunto.
  • Ho fatto un altro colloquio a Cambridge e mi ha assunto Autonomy.
  • Sono andato sulla ruota panoramica di Londra a San Valentino con la mia ragazza e ho festeggiato un anno insieme il 21 Marzo.
  • Ho vissuto due settimane in una casa temporanea offerta da Autonomy con un altro collega.
  • Il 15 Febbraio ho iniziato a lavorare ad Autonomy come Software Developer.
  • Ho cercato e trovato una casa in condivisione a Cambridge e quindi nuovo trasloco.
  • Ho avuto le mie soddisfazioni in Autonomy entro i miei primi tre mesi come spiegato in un precedente post.
  • Ho fatto l’esame FCE della Cambridge con un risultato di 58 su 100 e quindi non sono passato (minimo 60).
  • Ho fatto l’esame del Mensa UK ma non sono passato. Da riprovare quest’anno ma in Italia.
  • Ho aperto il mio blog UgiDotNet in inglese
  • Non essendo particolarmente soddisfatto in Autonomy ho iniziato a cercare altrove e a prepararmi di nuovo ai colloqui. Un grazie particolare ad Alessio Marziali per i suoi suggerimenti e ovviamente alla mia ragazza e alla mia famiglia per avermi sopportato durante questo periodo molto stressante.
  • Mi sono iscritto al corso di laurea magistrale in Matematica all’universita’ di Pisa
  • Ho fatto una operazione chirurgica per rimuovere tutti e quattro i denti del giudizio.
  • Ho vinto la competizione della battaglia navale organizzata da Luca Minudel insieme al mio ex-collega e amico Valerio Vitacolonna.
  • Ho acquistato un Windows Phone 7 (LG Optimus 7) il giorno del lancio
  • Ho partecipato a una conferenza del massimo esperto al mondo di cibernetica: Kevin Warwick
  • Ho fatto due collqui per grosse aziende informatiche a Dublino e a Londra ma non sono andati bene.
  • Ho fatto e superato il colloquio telefonico e in sede per Citrix UK in Cambourne (vicino Cambridge) Sorriso
  • Mi sono licenziato da Autonomy.
  • Ho iniziato a lavorare per Citrix UK il 13 Dicembre come Software Development Engineer con un notevole aumento di stipendio.
  • Ho quindi affittato una casa (non fornita) tutta per me su due piani con cucina, sala, due camere, bagno e giardino. Terzo trasloco… Triste
  • Ho comprato da IKEA in Londra divano, tavolo, sedie, mobile TV, attaccapanni, letto, due cassettiere, libreria e altro.
  • Ho dormito in terra sulla moquette in attesa della consegna IKEA (rimandata due volte per neve).
  • Sono rientrato in Italia per passare il natale in famiglia.
  • Ho smesso completamente di bere Coca-Cola e bibite in generale in quanto ne abusavo.

Visto che ci sono completo l’opera dicendo cosa ho fatto nelle prime tre settimane del 2011:

  • Ho dormito sul materasso in terra per piu’ di una settimana in attesa dell’installazione IKEA (rimandata una volta).
  • Ho fatto montare tutti i mobili IKEA da un tecnico professionista.
  • Ho comprato il frigorifero e la lavatrice.
  • Ho comprato uno schermo 42 pollici al plasma.
  • Ho comprato la XBOX con KINECT e due controller wireless Sorriso
  • Ho sistemato tutte le bollette di casa.
  • Ho comprato la bici nuova.
  • Ho ottenuto la certificazione “CCSP (Citrix Certified Sales Professional) Virtual Computing”.
  • Il 20 Gennario mi hanno attivato la linea telefonica ed Internet. E questo e’ il motivo principale per cui scrivo solo adesso questo post.
  • Il mio amico Stefano D’Onofrio e’ venuto a trovarmi e abbiamo passato un weekend di puro divertimento a Cambridge e a Londra.

Tutto sommato il 2010 e’ stato un anno che mi ha regalato molte emozioni e mi ha insegnato molte cose della vita. Dal punto di vista tecnico tuttavia non sono cresciuto abbastanza soprattutto perche’ in Autonomy non utilizzavo le tecnologie Microsoft che amo. Ora finalmente ho trovato una azienda veramente eccezionale che utilizza le tecnologie che amo, dove le persone sono molto in gamba. L’ambiente estremamente collaborativo con forte comunicazione a tutti i livelli, l’orario flessibile e la condivisione della visione aziendale con tutti i dipendenti rende questa azienda ottima dal mio punto di vista. Spero di crescere molto e di farmi valere!!!
Per i curiosi sono entrato nel team dei “Delivery Services”. Mi occupo di sviluppare la parte di middleware tra il client (Citrix Receiver) e la parte server/data center/cloud (dominata da XenApp e XenDesktop ma anche App-V). Seguiranno in futuro post sulle mie esperienze. Per chi di voi che non conosce Citrix puo’ farsi una idea dei suoi prodotti relativi al mondo della virtualizzazione nel canale video Citrix TV. In particolare consiglio i video della conferenza Synergy Berlin 2010.
Ora che mi sono sistemato, ho una casa e un ottimo lavoro come Software Developmente Engineer posso finalmente concentrarmi sui contenuti e iniziare a crescere professionalmente in tutti i sensi.

Ecco un breve elenco delle cose che voglio fare/ottenere nel 2011:

  • Dedicarmi alla mia salute iniziando ad andare regolarmente in palestra.
  • Prendere almeno una certificazione Microsoft MCTS.
  • Prendere almeno una certificazione come Basic Administrator di un prodotto Citrix. Probabilmente XenApp.
  • Riprovare e possibilmente superare la prova del Mensa Italia.
  • Riprovare e possibilmente superare un esame di certificazione della lingua.
  • Superare un esame di matematica.
  • Lanciarmi con il paracadute.
  • Scrivere articoli per DotNetToscana e cercare di aiutare la community a crescere.
  • Scrivere decisamente di piu’ sul mio blog che nel 2010 e’ stato particolarmente trascurato.
  • Iniziare a fare brevi vacanze per conoscere il mondo (a partire dall’Europa) insieme ad amici e fidanzata.
  • Aggiornare e creare una versione localizzata e piu’ professionale del mio sito web www.angellaa.it

Vorrei concludere con un post a cui tengo particolarmente:
“An investment in knowledge always pays the best interest”, Benjamin Franklin
Ciao a tutti

4 [BOOKS] – Ingegneria del codice, Seconda Edizione

Tutti quelli che mi conoscono sanno quanto mi piace leggere e imparare cose nuove. In particolare adoro leggere libri tecnici per aumentare le mie competenze e imparare dall’esperienza di tanti altri che mi hanno preceduto. Per questo motivo ho deciso che ogni volta che terminero’ la lettura di un libro scrivero’ un post in cui racchiudero’ l’essenza del libro e le mie considerazioni. Lo scopo e’ riassumere il contenuto, evidenziando i punti principali e piu’ importanti. Spero che possa anche accendersi un dibattito e un confronto costruttivo sui contenuti con le persone che hanno letto il libro o quelle che desiderano acquistarlo.
Ho deciso di inaugurare questa sezione del mio blog con un testo classico che ho recentemente finito di leggere:
Ingegneria del Codice, Seconda Edizione” di Steve McConnell

Questo libro mi e’ stato regalato da alcuni amici dell’universita’ di Pisa per la mia laurea triennale nel 2006. Il libro e’ in italiano. La traduzione non e’ particolarmente brillante, quindi per coloro che avessero intenzione di acquistarlo consiglio il testo in lingua inglese:
“Code Complete, Second Edition”
Il libro e’ un mattone di 900 pagine che affronta a 360 gradi tutto cio’ che riguarda la costruzione del software. Esso presenta una serie di pratiche di programmazione che servono a mantenere sotto controllo, a manutenere e a modificare grossi e complessi progetti. Il libro e’ una raccolta di innumerevoli fonti integrate con anni di esperienza professionale. Dal mio punto di vista, il suo valore e’ altissimo e molto probabilmente dovro’ leggerlo una seconda volta, magari in inglese.
Uno degli aspetti interessanti del libro e’ il numero di ricerche statistice che vengono riportate per supportare le tesi sostenute.
Ecco alcune frasi significative estratte dal testo:

  • Il prodotto della costruzione, il codice sorgente, e’ spesso la sola descrizione accurata del software. Di conseguenza, e’ imperativo che il codice sorgente sia della piu’ alta qualita’ possibile.
  • I rischi di progetto piu’ comuni nello sviluppo del software sono i prerequisiti scarsi e una scarsa pianificazione di progetto
  • Parte del lavoro di dipendente tecnico consiste nell’educare il personale non tecnico che vi circonda sul processo di sviluppo
  • In generale, il principio e’ trovare un errore nel momento il piu’ vicino possibile a quando e’ stato commesso
  • Il primo prerequisito che si deve soddisfare prima di iniziare la costruzione e’ una formulazione chiara del problema che si vuole risolvere: la mission del prodotto
  • I prerequisiti stabili rappresentano il sacro Graal dello sviluppo del software
  • I programmatori che non dimenticano di considerare l’impatto business delle loro decisioni valgono tanto ora quanto pesano
  • Una delle maggiori sfide che si presenta a un architetto software e’ rendere l’architettura abbastanza flessibile da favorire le probabili modifiche
  • Prima che la costruzione inizi, specificate le convenzioni di programmazione che utilizzerete.
  • I tool di programmazione utilizzati non devono determinare come si interpreta la programmazione
  • Il design e’ l’attivita’ che collega i prerequisiti alla codifica e al debugging.
  • L’imperativo tecnico principale del software e’ gestire la complessita’
  • Abituatevi a chiedervi “Cosa devo nascondere?”. Resterete sorpresi dal come molti difficili problemi di design si dissolveranno davanti ai vostri occhi
  • Talvolta non si puo’ realmente sapere se un design funzionera’ finche’ non si comprendono meglio alcuni dettagli di implementazione.
  • Il design e’ euristico. Una adesione dogmatica a qualsiasi singola metodologia danneggia la creativita’ e danneggia i programmi
  • I programmatori nel corso dell’esistenza di un sistema spendono molto piu’ tempo a leggere il codice che a scriverlo
  • Le revisioni rappresentano un meccanismo importante per fornire ai programmatori un feedback sul loro codice
  • La scrittura dei test case prima del codice richiede la stessa quantita’ di tempo e impegno della scrittura dei test case dopo il codice, ma accorcia i cicli difetto-rilevazione-debug-correzione
  • Neanche l’esperienza aiuta molto con l’ottimizzazione. L’esperienza di una persona puo’ essere stata acquisita su una macchina, un linguaggio o un compilatore ormai datato: se cambia uno di questi aspetti, tutte le certezze sono errate. Non si puo’ mai essere certi sull’effetto di una ottimizzazione finche’ non si misura l’effetto.
  • Piu’ cervelli bisogna coordinare, piu’ documentazione formale e’ necessaria per coordinarli
  • Utilizzare il sistema di benefit della propria azienda per incentivare le buone pratiche di codifica
  • Gestire un progetto software e’ una delle imprese piu’ eccezionali del ventunesimo secolo, e stimare le dimensioni di un progetto e l’impegno richiesto per terminarlo e’ uno degli aspetti piu’ impegnativi della gestione di un progetto software
  • I buoni programmatori tendono a raggrupparsi
  • I manager dei progetti di programmazione non sono sempre consapevoli che certi aspetti della programmazione sono questioni di religione
  • Nello sviluppo del software, i manager non tecnici sono comuni, come lo sono i manager che hanno esperienza tecnica ma che e’ obsoleta di 10 anni. I manager tecnicamente competenti, e tecnicamente aggiornati sono rari. Se si lavora con uno di essi, fate di tutto per mantenere il vostro lavoro. E’ un piacere insolito.
  • La soddisfazione visuale e intellettuale del codice ben formattato e’ un piacere che pochi non programmatori possono apprezzare
  • Il Teorema Fondamentale della Formattazione dice che una buona disposizione visuale mostra la struttura logica di un programma. Se una tecnica mostra meglio la struttura e un’altra conferisce un aspetto migliore, utilizzare quella che mostra meglio la struttura
  • Molti aspetti del layout sono aspetti religiosi. Cercate di separare le preferenze di obiettivo da quelle soggettive.
  • I commenti inadeguati sono peggio di nessun commento
  • Commentare il codice complicato e’ esattamente l’approccio errato da seguire. Non documentare il codice pessimo: riscriverlo.

Una cosa interessante che ho scoperto da questo libro e’ che il mio stile di codifica pur essendo esteticamente valido viola quello che l’autore chiama il Teorema Fondamentale della Formattazione. In pratica io preferisco mettere la prima parentesi di un blocco nella riga successiva. Lo trovo estremamente leggibile anche se talvolta porta ad un aumento del numero di linee di codice.

Come dice Steve: I buoni programmatori devono essere di larghe vedute sulle proprie pratiche di layout e accettare le pratiche che si sono dimostrate migliori di quelle a cui sono abituati, anche se adattarsi a un nuovo metodo comporta un disagio iniziale.

I motivi per cui questo approccio e’ sconsigliato sono:

  • Begin e End (le parentesi) non fanno parte del costrutto di controllo, ma non fanno neanche parte della istruzione seguente

Onestamente tuttavia non lo trovo un motivo sufficiente per farmi cambiare il mio stile di formattazione dei blocchi. Sarei curioso di sapere il vostro. Qual e’ ?
Altre frasi:

  • Se siente un ingegnere del software, il materiale di base di costruzione e’ intelletto umano e il vostro strumento primario siete voi. Piuttosto che progettare una struttura fino all’ultimo dettaglio e poi passare i disegni a qualcun altro per la costruzione, sapete che dopo aver progettato un blocco di software fino all’ultimo dettaglio, e’ fatta. L’intero lavoro della programmazione e’ realizzare castelli in aria: e’ una delle attivita’ piu’ puramente mentali che si possa fare.
  • Se volete essere validi, e’ vostra la responsabilita’ di rendervi tali. E’ una questione di carattere personale.
  • Nello sviluppo di un ottimo programmatore la curiosita’ sugli argomenti tecnici deve essere una priorita’.
  • Un modo particolarmente valido per apprendere la programmazione e’ studiare il lavoro di ottimi programmatori.
  • Alcuni programmatori creativi vedono la disciplina degli standard e le convenzioni come qualcosa di asfissiante per la creativita’. E’ vero il contrario.
  • Dijkstra ha costantemente sottolineato il messaggio che il compito essenziale della programmazione e’ padroneggiare l’enorme complessita’ della scienza dei computer.
  • Per sperimentare efficacemente, si deve essere disposti a modificare le proprie opinioni in base ai risultati dell’esperimento

Il libro e’ una vera miniera di consigli e linee guida. Tuttavia e’ solamente un punto di partenza in quanto vengono elencate una raccolta sterminata di ulteriori libri/articoli/fonti su cui approfondire ed espandere gli argomenti trattati. Un intero capito e’ dedicato a questo scopo.

>