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

 

Read More »

Advertisements

Quella sottile linea invisibile

Camminando giusto giusto sul confine tra Italia e Austria nel percorso Water Trail.

Un passo sei di qua e un passo sei di là. Così semplice, quasi banale. Eppure la differenza è enorme. Sarà una fissa mia ma queste cose mi affascinano. E mi chiedo: perché proprio lì la linea di confine e non un metro prima o dopo? Come viene deciso?

Questi confini geografici mi scatenano poi dei pensieri piu generici o astratti. Quanti confini attraversiamo nella nostra vita? E quanti ammettono un tornare indietro?

I nostri confini sono anche ciò che ci caratterizza: i nostri limiti, i nostri princìpi, la nostra confort zone. Cosa facciamo quotidianamente e in modo tangibile per espandere noi stessi, le nostre abilità e le nostre conoscenze?

Detto questo mi fermo qua, potrei cominciare a farneticare e sconfinare in un territorio filosofeggiante che non mi appartiene.

A voi affascinano i limiti, i confini, le situazioni limite?

Keep it going

It has been nine months since the opening of this blog and it’s time to make a look back. I started this adveture to record some interesting readings, some thoughts and to exercise in writing. I also started because I read all over my Twitter timeline and other developers’ blog that opening a blog and start writing technical things down makes you a better developer. Being a better developer is what makes me tick and so this place was born.

9-cards-home-launcher-icon.png

In the very first period I updated my social profiles (LinkedIn and Twitter) and setup the basics of the blog: the name, the graphical theme and the pages where I talk about who I am.

The blog started in Italian because it was meant for my personal exercise. I found that it was true: writing things in a good form (not just tech notes or tech e-mail at work for you or your team) that is in a very minimal way pleasant to read improves your knowledge about a subject. I have to research, to read twice to provide scripts and images, and so on. Now I write in English because I want to practice and because English is the main language in the IT world. Anyway, I won’t stop to write some posts in Italian.

I’ve a schedule that I can live with of 2-3 posts a week. This is the most difficult part. It was easier at the beginning: everything was new but being constant is the hardest thing.

Conclusions

No matter what I have to keep up and go on because I’m receiving positive feedback from this experience that I want to maintain and possibly amplify. My plan for the near future is to became Always better in English technical writing about the subject I like the most: Windows, C# and possibly a bit of Unity 3D engine.

 

 

 

Tu sei il tuo peggior nemico

As a software developer, you are your own worst enemy. The sooner you realize that, the better off you’ll be-

– Jeff Atwood

Per quanto Jeff “Coding Horror” Atwood possa essere a volte schietto e brutale penso che sia difficile contraddirlo in questo contesto.

Il miglior codice di tutti è nessun codice.

Abbiamo tutti le migliori intenzioni quando scriviamo codice ma poi ogni riga di ciò che scriviamo deve essere debuggata, deve essere capita, documentata ecc…

Facciamo al mondo un favore, se possiamo scriviamo meno righe di codice possibile.

I test sono per le persone

State scrivendo test automatizzati per alcune parti del vostro codice in produzione. Congratulazioni! State scrivendo i test prima di scrivere il codice? Ancora meglio! Già fare ciò vi fa rientrare tra gli avanguardisti delle pratiche di ingegneria del software. Ma state scrivendo buoni test? Come si può dirlo? Un modo è chiedersi, “Per chi sto scrivendo i test?” Se la risposta è “Per me, per evitarmi di correggere bug poi” o “Per il compilatore, così possono essere eseguiti,” allora è possibile che non stiate scrivendo i test migliori possibili. Quindi, per chi dovremmo scrivere test? Per le persone che cercano di capire il vostro codice.
I buoni test servono anche da documentazione per il codice che stanno testando. Descrivono come il codice funziona. Per ogni utilizzo i test:

  1. Descrivono il contesto, il punto di partenza e le precondizioni che devono essere soddisfatte;
  2. Illustrano come il software viene chiamato;
  3. Descrivono i risultati attesi con le post-condizioni che devono essere verificate.

Le persone che cercheranno di capire il vostro codice dovrebbe guardare un paio di test, e confrontarli con le tre sezioni appena descritte e trovare in ciò una guida.