Category Archives: generale

My first year at Microsoft

Time can pass very quickly. This has been definitely the case when I think that one year ago I was starting my new job at Microsoft.

The joy of being part of this amazing amazing company was flowing through my veins.

Fast forward a year and the feeling is the same. I can’t count how many skills I learned or improved. I’ve met people from all over the world, travelling for business or training purposes.

New challenges are waiting for me this year and I’m ready to take the game to the next level. Always learning, always improving!

3 anni di blogging

Mi sento un po’ in colpa perché arrivo 3 giorni in ritardo a festeggiare i tre anni di questo blog. Un po’ come quando ti ricordi in ritardo del compleanno di un tuo amico importante. Questo blog per me è a tutti gli effetti un amico importante. Non si lamenta quando lo frequento poco ed è sempre disponibile ad ascoltarmi quando ho voglia di scriverci qualcosa sopra.

Agosto per me rappresenta da qualche anno un momento dell’anno di riflessione dove faccio un punto della situazione famigliare, personale e professionale. Di solito inizio anche un progetto personale di studio o miglioramento.
Il progetto di quest’anno è imparare una terza lingua: il tedesco. Chissà, magari tra qualche mese proverò a scrivere anche qualche articolo in tedesco per sperimentare come feci con l’inglese a suo tempo. Ho iniziato seriamente proprio oggi trovando un buon canale per assoluti niubbi su YouTube. Tutti mi dicono essere difficile ma non sono uno che si fa spaventare dall’imparare qualcosa di nuovo. Dirò la mia tra qualche tempo!

Ciao!

My first six months at Microsoft

Today it’s an important day because it’s six months that I’m working at Microsoft and it’s the end of the probationary period.

I’ll remember forever my first day when I entered from main entrance at the Microsoft House in Milan and asked for a temporary badge because I was a new hire. One year and half before I entered the same door to attend a free workshop about Desktop Bridge and asked for a guest badge. I looked at everything with different eyes and many emotions. Life can be very rewarding if you have an objective and you work for it.

That day, I put the badge onto a sensor near a door and the door opened, I thought: “It’s real! I’m not dreaming!”.

Continue reading

Hard work does not pay off

Today I was chatting with a friend about working late hours and he said that he has to much to do and he’s stressed.

This piece from Olve Mundal in 97 things Every Programmer Should know came to my mind.

As a programmer, working hard often does not pay off. You might fool yourself and a few colleagues into believing that you are contributing a lot to a project by spending long hours at the office. But the truth is that by working less you might achieve more — sometimes much more. If you are trying to be focused and ‘productive’ for more than 30 hours a week you are probably working too hard. You should consider reducing the workload to become more effective and get more done.
This statement may seem counterintuitive and even controversial, but it is a direct consequence of the fact that programming and software development as a whole involve a continuous learning process. As you work on a project you will understand more of the problem domain and, hopefully, find more effective ways of reaching the goal. To avoid wasted work, you must allow time to observe the effects of what you are doing, reflect over the things that you see, and change your behavior accordingly.
Professional programming is usually not like running hard for a few kilometers, where the goal can be seen at the end of a paved road. Most software projects are more like a long orienteering marathon. In the dark. With only a sketchy map as guidance. If you just set off in one direction, running as fast as you can, you might impress some, but you are not likely to succeed. You need to keep a sustainable pace and you need to adjust the course when you learn more about where you are and where you are heading. In addition, you always need to learn more about software development in general and programming techniques in particular. You probably need to read books, go to conferences, communicate with other professionals, experiment with new implementation techniques, and learn about powerful tools that simplify your job. As a professional programmer you must keep yourself updated in your field of expertise — just as brain surgeons and pilots are expected to keep themselves up to date in their own fields of expertise. You need to spend evenings, weekends, and holidays educating yourself, therefore you cannot spend your evenings, weekends, and holidays working overtime on your current project. Do you really expect brain surgeons to perform surgery 60 hours a week, or pilots to fly 60 hours a week? Of course not, preparation and education is an essential part of their profession.
Be focused on the project, contribute as much as you can by finding smart solutions, improve your skills, reflect on what you are doing, and adapt your behavior. Avoid embarrassing yourself, and our profession, by behaving like a hamster in a cage spinning the wheel. As a professional programmer you should know that trying to be focused and ‘productive’ 60 hours a week is not a sensible thing to do. Act like a professional: prepare, effect, observe, reflect, and change.

2 anni di blogging: cosa ho scoperto che può tornarti utile

Oggi questo blog compie 2 anni. Solo a scriverlo mi sembra impossibile. Ma cosa mi sta insegnando questo viaggio?

gray steel chain on orange surface

Photo by Miguel Á. Padriñán on Pexels.com

 

Continue reading

I principi di Dale Carnegie

Sto ripassando, dopo un po’ troppi mesi, i testi di Dale Carnegie.

Metto qui a futura memoria e per rapida consultazione l’elenco dei principi trattati.

Principi Dale Carnegie

Tecniche fondamentali per trattare con la gente

  1. Non criticare, non recriminare, non giudicare.
  2. Siate prodighi di apprezzamenti onesti e sinceri.
  3. Suscitate negli altri la vostra stessa volontà.

Sei modi per farsi benvolere

  1. Interessatevi sinceramente delle altre persone.
  2. Sorridete
  3. Ricordatevi che per una persona il suo nome è il suono più importante e più dolce in qualsivoglia lingua.
  4. Siate buoni ascoltatori. Incoraggiate gli altri a parlare di se stessi.
  5. Parlate di quello che interessa agli altri.
  6. Fate in modo che gli altri si sentano importanti con la massima naturalezza e sincerità.

Come convincere il prossimo a condividere le vostre opinioni

  1. Il modo migliore per avere una discussione consiste nell’evitarla.
  2. Mostrate rispetto per le opinioni altrui. no dite mai: “Lei ha torto!”.
  3. Se avete torto, ammettetelo subito e spassionatamente.
  4. Cominciate sempre col mostrarvi amici
  5. Fate in modo che il vostro interlocutore sia indotto a rispondere sì sin dal principio.
  6. Lasciate che i vostri interlocutori chiaccherino quanto vogliono.
  7. Date agli altri la sensazione che siano stati loro per primi ad avere l’idea giusta.
  8. Cercate di vedere onestamente le cose dal punto di vista del vostro interlocutore.
  9. Siate comprensivi nei confronti delle idee e dei desideri altrui.
  10. Fate appello ai motivi più nobili.
  11. Drammatizzate le vostre idee.
  12. Lanciate una sfida.

Essere un leader: come far cambiare opinione agli altri senza offendere e suscitare risentimenti

  1. Iniziare sempre con le lodi e l’apprezzamento sincero.
  2. Richiamate l’attenzione degli errori altrui in maniera indiretta.
  3. Parlate dei vostri errori prima di sottolineare quelli altrui.
  4. Fate domande invece di impartire ordini diretti.
  5. Fate in modo che l’altra persona salvi la faccia.
  6. Lodate ogni più piccolo progresso. Siate calorosi nell’approvazione e prodighi di lodi.
  7. Date agli altri l’impressione di avere una reputazione da difendere.
  8. Usate l’incoraggiamento. Mostrate quant’è facile correggere gli errori.
  9. Fate sì che l’altra persona sia felice di fare quello che le suggerite.

SOLID principles by examples: Liskov Substitution Principle

In this post we’re going to explore the third of the SOLID principles: the Liskov Substitution Principle (LSP).

The most practical definition of this principle was written by Robert C. Martin in his book Agile Software Development, Principles, Patterns, and Practices.

Subtypes must be substitutable for their base types.

The concept was introduced by Barbara Liskov in 1987. The formal definition is:

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

For our daily activities we must remember that a subclass should override the parent class’ methods in a way that doesn’t break functionality from a consumers’s point of view.

Example


abstract class MusicalInstrument
    {
        public abstract void PlayANote();
    }

class Piano : MusicalInstrument
    {
        public override void PlayANote()
        {
            PressKey();
        }

        private void PressKey()
        {
            //Press a piano key.
        }
    }

class Saxophone : MusicalInstrument
    {
        public override void PlayANote()
        {
            Blow();
        }

        private void Blow()
        {
            //Blow air into the instrument.
        }
    }

The evergreen example

To better underestand LSP let’s examine this classic example. It’s a classic because it’s easy to understand and very meaningful. We start with this question:

Is a square a special rectangle in OOP?

We try to answer this question with this simple class hierarchy: a Rectangle as base class and a Square class that inherits from it. In the Square class we override the behavior of the setters to enforce that the the Heigth and Width properties have the same value.

class Rectangle
    {
        public virtual float Heigth { get; set; }
        public virtual float Width { get; set; }
        public virtual float Area
        {
            get { return Heigth * Width; }
        }
    }

class Square : Rectangle
    {
        private float _heigth;

        private float _width;

        public override float Heigth
        {
            get
            {
                return _heigth;
            }
            set
            {
                _heigth = value;
                _width = value;
            }
        }

        public override float Width
        {
            get
            {
                return _width;
            }
            set
            {
                _width = value;
                _heigth = value;
            }
        }
    }

Now we have to remember that a subclass must override the base class in a way that it doesn’t break functionality from a client’s POV. We write these two tests to check.


[TestClass]
    public class UnitTest1
    {
        [TestMethod]
        public void TestWithRectangle()
        {
            Rectangle sut = new Rectangle();
            sut.Heigth = 3;
            sut.Width = 7;

            Assert.AreEqual(21, sut.Area);
        }

        [TestMethod]
        public void TestWithSquare()
        {
            Rectangle sut = new Square();
            sut.Heigth = 3;
            sut.Width = 7;

            Assert.AreEqual(21, sut.Area); //This test will fail. Area equals 49.
        }

    }

So it’s clear that in OOP a square isn’t a particulare case of a rectangle. How can we do to better organize these classes? The typical approach consists of creating an abstract class (or an interface). For example

abstract class Shape
    {
        public abstract float Area { get; }
    }

 class Rectangle : Shape
    {
        public float Heigth { get; set; }
        public float Width { get; set; }
        public override float Area
        {
            get { return Heigth * Width; }
        }
    }

    class Square : Shape
    {
        public float Edge { get; set; }

        public override float Area
        {
            get { return Edge * Edge; }
        }
    }

Now our code states that both the Rectangle class and the Sqare class are Shapes which is true. Our code is also safer and we don’t have any situation where a client will receive unexpected values.

TL;DR

In this post we explored the Liskov Substituion Principle (LSP) and we learned that it’s not true that real-life objects always maps to the same OOP structure / class ecosystem. When also tried to improve the wrong example with the simple technique of adding an abstraction layer (the Shape class).

1 anno di blogging

Oggi questo blog compie 1 anno.

Nonostante tante cose è sempre rimasto attivo e ne sono orgoglioso. Ok, non è così attivo come vorrei (ha vissuto un paio di mesi di pause) ma ha attraversato eventi decisamente importanti come:

  1. La nascita del mio secondo figlio;
  2. Picchi lavorativi dovuti a nuovi clienti;
  3. Un trasloco verso una casa nuova;
  4. Notti insonni dovute al punto 1.

È nato per sfida personale sull’argomento costanza: spesso mi dico che non sono bravo a portare avanti le cose per lunghi periodi di tempo e volevo migliorare. È nato anche perché sono stato influenzato da Jeff Atwood, Scott Hanselman, Frank Bettger e da tantissimi blog-post che indicano come scrivere articoli, anche semplici, ci rende più ferrati sull’argomento.

Ho iniziato così a sperimentare per trovare la mia voce, il mio modo di raccontare le cose e di trasmetterle.

Un grosso cambiamento è avvenuto a maggio quando sono stato alla Microsoft House per un evento sul Dekstop Bridge. Parlando con Matteo Pagani e altri ragazzi ho scoperto quanto un blog sia un esercizio svolto da molti. È stata un’iniezione di motivazione e allo stesso una scoperta perché ha cambiato il contenuto dei miei articoli. Ho scoperto quanto mi piaccia scrivere dei miei esperimenti che svolgo per curiosità su tecnologie informatiche che non utilizzo nella mia quotidianità al lavoro: mi aiuta a fissare i concetti e ciò che scopro può essere utile a qualcun altro.
Alcuni esperimenti con UWP si sono trasformati in un possibile business per un conoscente che mi ha chiesto informazioni. Le prove con Prism sono state impiegate per un prodotto nuovo in azienda portato avanti da dei colleghi. Gli articoli su DZone condivisi da questo blog raggiungono migliaia di visite e questo blog ha raggiunto 200 visitatori unici al mese in luglio. Certo altri blogger fanno queste cifre al giorno ma per me è già tanto.

Il mio caloroso consiglio è quello di cominciare un blog anche voi se siete indecisi: condividete il vostro interesse per qualcosa per il puro piacere di insegnare, per divertirvi e per imparare. A me ha portato solo cose buone. Trovate un ritmo che siete in grado di mantenere e mantenetelo a tutti i costi. Non traete conclusioni prima di un anno di blogging più o meno continuo.

Queste sono le mie conclusioni: ne vale la pena e continuerò più che posso.