The way I work- Jason Fried of 37signals

PS: As global information,  37signals guys are the producers of BootCamp, CampFire, etc..

—————–

Un articolo interessante ci mostra la vita lavorativa di una società di successo.

The way I work- Jason Fried of 37signals

PS: Per chi non conoscesse la società 37signals, sono coloro che hanno sviluppato BootCamp, CampFire, etc.

Non posso che non supportare questo movimento nato su facebook che si prefigge di superare tutta la disinformazione che ruota intorno al mondo videoludico.

Supportate il Movimento Italiano Contro la Disinformazione sui Videogiochi!

You can download RockScroll (Thanks to Scott Hanselman) here

http://www.hanselman.com/blog/IntroducingRockScroll.aspx

—————–

RockScroll è un plugin molto utile per tutti gli sviluppatori che usano Visual Studio.
Questo tool sostituisce la normale scrolling bar di Visual Studio con una overview del codice contenuto nel file.
Una delle fratture che apprezzo maggiormente riguarda la selezione di variabili o nomi di funzioni: tutte le occorrenze della selezione sono infatti evidenziate all’interno di RockScroll offrendo una visione globale dei punti del codice che accedono specifiche variabili o funzioni.

Potete scaricare RockScroll (Grazie a Scott Hanselman per lo sviluppo) qui

http://www.hanselman.com/blog/IntroducingRockScroll.aspx

—

Grazie ad un mio collega ho trovato questo interessante link pieno di pubblicazioni storiche relative alla Computer Graphics. Buon divertimento.

—

http://www.stumbleupon.com/su/2QSFNv/graphics.cs.williams.edu/courses/cs371/f10/papers.html/r:f

—

Una lettura interessante per chi lavora con Xbox360 e PS3.

http://assemblyrequired.crashworks.org/2008/07/08/load-hit-stores-and-the-__restrict-keyword/

For example, what happens if we write the following code?


int i=10;
int n = i + i++;


In this case we are both incrementing i and adding his own value. Well, usually the behaviour is undefined because there is no sequence point defined by the + operator. So we don’t know if the compiler will evaluate i++ before i or viceversa. So the output can be both 21 or 22.

Understanding the “Sequence point” can give us a better knowledge to avoid bug that are hardly to be debugged.

–

Un interessante lettura riguardante i “Sequence point“.

Per sempio cosa accade quando scriviamo il seguente codice?


int i=10;
int n = i + i++;


In questo caso stiamo sommando i e il suo incremento. Bene, questo comportamento è indefinito perchè non c’è nessun “Sequence point” definito dall’operatore di somma, quindi non è chiaro quale addendo verrà valutato prima dal compilatore. L’output può,perciò, essere sia 21 che 22.

Capire bene i “Sequence point” può evitarci di avere bug veramente difficili da debuggare.

–

http://en.wikipedia.org/wiki/Sequence_point

++i

instead of

i++

The general rule should be to always use the prefix increment unless you really need the original value of the variable returned.

The prefix form is a little bit more efficient avoiding the creation of an extra variable.

Quoting Alexandrescu and Sutter (“C++ Coding Standard”, Addison Wesley), “This is not premature optimization, it is avoiding premature pessimization.”

–

Piccolo consiglio per i programmatori C++ : cercate di usare sempre il preincremento invece del postincremento sulle variabili numeriche scrivendo, per esempio

++i

invece di

i++

La regola generale dovrebbe essere di utilizzare sempre il preincremento a meno di avere bisogno di ottenere anche il valore originale della variabile.

Citando Alexandrescu and Sutter (“C++ Coding Standard”, Addison Wesley), “Questa non è prematura ottizzazione, ma evitare la prematura pessimizzazione”.

I’m not a complete fan of pair programming.

Having always two people working on the same part of code can be sometime frustrating and uneseful, in my opinion.

By the way, for some critical task, pair programming can be the perfect solution instead of using code reviews tools.
It gives you the chance to discuss choises directly during the “writing step” of the code instead of opening a review (maybe using Code Collaborator) and wait until the reviewer will have time for reading your work.

Discussing is always better than chatting!

Here there is an interesting point of view about pair programming by Obie Fernandez, CEO and Founder of Hashrocket.

–

Il “Pair programming” è una tecnica di programmazione nella quale due sviluppatori lavorano insieme sulla stessa workstation.

Non mi ritengo un vero fan del Pair programming per diverse ragioni: principalmente non credo che il pair programming sia necessario per qualsiasi task e che anzi, generalmente possa divenire frustrante e poco utile.

Diviene utile, secondo me, per particolari task critici dove discutere delle scelte prese in una parte del codice può essere utile durante la scrittura del codice stesso e non a posteriori. In questi casi infatti l’utilizzo di sistemi di review del codice può portare a fastidiosi delay nell’approvazione dei cambiamenti o delle nuove feature introdotte nel software.

Inoltre il dialogo permette sempre un migliore scambio di idee al contrario del chattare.

Per tutte le altre situazioni, invece, ritengo che un sistema di “Code review“, come Code Collaborator, possa essere molto utile soprattutto per la crescita tecnica del revisore e del revisionato.

Qui è possibile leggere un interessante punto di vista sul Pair Programming scritto da Obie Fernandez, CEO e Fondatore di Hashrocket.

–

http://blog.obiefernandez.com/content/2009/09/10-reasons-pair-programming-is-not-for-the-masses.html