Qualche giorno fa, mentre leggevo Peopleware (portate pazienza per la recensione: arriverà) mi sono reso che gestire un “team di sviluppo” non è affatto semplice…
Qualche giorno fa, mentre leggevo Peopleware (portate pazienza per la recensione: arriverà) mi sono reso che gestire un “team di sviluppo” non è affatto semplice…
“Standards are just papers. Yes, they’re important, but they are definitely not more important than anything else, and they are a lot _less_ important than some people seem to think.”
Si può dire tutto ed il contrario di tutto su Linus Torvalds, ma non si può dire che non offra spesso interessanti spunti di riflessione.
Quando verso la fine del 2007 ho letto la frase sopra-citata non ne ho capito immediatamente il significato: sembrava una frase detta dal solito bastian-contrario per screditare il lavoro di altre persone.
Eppure sapevo già che aveva ragione…
Qualche giorno fa, per motivi lavorativi, avevo necessità di gestire in modo decente il logging di un programma.
Nel mio caso l’intera gestione del log era rigorosamente in memoria e lì doveva rimanere, a meno di una richiesta esplicita di salvataggio su file, quindi su disco. Inoltre, per evitare problemi, il log non doveva superare una dimensione prefissata, espressa come numero massimo di elementi memorizzabili.
La struttura ideale che mi serviva doveva quindi:
Un buffer circolare era ovviamente la scelta più semplice.
I database rappresentano un aspetto importante della “programmazione moderna” tanto che la conoscenza di almeno una implementazione/tecnologia rappresenta un requisito minimo nella maggioranza delle offerte di lavoro in questo ambito.
E’ la facilità d’uso dei DB a renderli comodi e impiegabili pressochè sempre, ovunque serva memorizzare qualcosa.
Sfortunatamente la facilità e la flessibilità d’uso di una qualunque cosa, la rende anche facilmente sovvertibile e quindi abusabile.
Recentemente ho avuto l’onore ed il piacere di dare qualche suggerimento ad una mia conoscenza che vuole iniziare a programmare.
Qualche giorno fa il buon Martino ha scritto un bel post in cui presentava dell’uso delle asserzioni (assert) in C++, incluso il come ometterle in blocco quando non servono.
Un estratto dal suo codice:
#ifndef _DEBUG
#define std_assert(condition)
#define full_assert(condition, description)
#define fail_assert(description)
#else
#define std_assert(condition) \
{ \
do \
{ \
if(!(condition)) \
{ \
std::cerr << "ASSERT FAILED: " << #condition << " @ " << __FILE__ << " (" << __LINE__ << ")" << std::endl; \
__debugbreak(); \
} \
} while(0); \
}
[...]
#endif
Successivamente, verso la fine del suo post, ha posto la seguente domanda:
“[1] Come in tutte le cose del C++, anche per questa ci sono mille teorie. L’assert di default in release è definita come ((void)0). In altre implementazioni ho visto sizeof(x) etc…io ho semplicemente definito la/le macro vuote e visualizzando l’assembly generato dal compilatore ho notato che non viene aggiunto nessun comando. Chi avesse maggiori informazioni su questo è il benvenuto.”
Qualche giorno fa per motivi lavorativi ho ridato un’occhiata al libro “Modern C++ Design” di Andrei Alexandrescu.
Si tratta di un eccellente libro, pubblicato nel 2001, che ha portato aria fresca alla programmazione in C++ e che in qualche modo ha lasciato un segno indelebile. Da Wikipedia:
“Several phrases from the book are now used within the C++ community as generic terms: modern C++ (as opposed to C/C++ style), policy-based design and typelist.”
Nel mentre lo rileggevo, è sorto dentro di me un interrogativo, che posso sintetizzare in:
“fin dove l’utilizzo di tecniche in qualche modo avanzate in un progetto rappresenta un buon modo per migliorarsi (nonchè aumentare la qualità dei risultati) e non solamente un esercizio di stile, un semplice sfogo per il proprio ‘ego tecnologico‘?
