Next 17 September will be a full immersion day of Windows Phone 7 Mango
Be passionate, enthusiast, curious, motivated and ambitious. Communicate, collaborate, share and learn constantly!
Wednesday, 31 August 2011
Tuesday, 23 August 2011
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:
Before to finish, I want to underline some important aspects when you want to prepare a Microsoft 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
Before to finish, I want to underline some important aspects when you want to prepare a Microsoft certification:
- Don't use only the official preparation book because it contains a subset of the required arguments.
- Read carefully the section "Skills Measured" and check that you covered all the subjects
- In this case, for example, it was easy to unnote that the exam included the Task Parallel Library and Parallel LINQ
- Take practise tests on MeasureUp is a big help and you shouldn't understimate this
Friday, 12 August 2011
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
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
Saturday, 23 July 2011
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:
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”
Saturday, 25 June 2011
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:
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."
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
- …
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."
Sunday, 27 February 2011
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:
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.
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
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.
Sunday, 6 February 2011
[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:
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/
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.
- 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.
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:
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/
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.
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/
Tuesday, 25 January 2011
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):
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:
"An investment in knowledge always pays the best interest", Benjamin Franklin
Ciao a tutti
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)
- 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…
- 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.
- 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
- 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.
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
"An investment in knowledge always pays the best interest", Benjamin Franklin
Ciao a tutti
Subscribe to:
Posts (Atom)