Un nuovo video molto piacevole che ci invita a riflettere sui noi stessi ma soprattutto su quello che trasmettiamo ai nostri figli.
Originally found: http://www.hrdonline.it/risorsa/videoDetail.action?item=570
Allo stesso indirizzo ho con piacere ed emozione visto anche un video di un discorso Jobs del 2005 (con sottotoli in italiano 1 e 2)
mercoledì 13 gennaio 2010
Importante iniziativa
Trovo la nuova iniziativa di Marco molto lodevole, sono convinto che AssoPrestigio abbia per sua stessa natura un suo spazio nel panorama associativo Italiano. Non pensiamo agli “eletti” quando parliamo di AssoPrestigio, pensiamo alle persone che per loro stessa natura, inclinazione e arte sono prestigiose, questo è innato: non si compra, non si vende, non si crea. Si possiede e lo si esercita, lo si subisce e se ne viene inebriati.
Ma che cos’è il prestigio e perché è così importante da permeare tutta la nostra vita, subito o esercitato?
L’etimologia della parola non chiarisce: “illusione prodotta con destrezza di mano e quindi impostura, fallacia inganno”. Eppure nel nostro uso corrente assume una semantica totalmente opposta, e quella che preferisco attribuirgli è la “la capacità di sedurre e di imporsi alla fantasia altrui”.
In questo tutta la socialità del prestigio: non si può essere soli nell’esercitarlo occorre una comunità che lo riconosca e lo esalti. Per ciò trovo lo statuto tremendamente chiarificante.
Auguro a tutti i soci ogni bene, che ci siano di guida e illuminino con le loro gesta i nostri momenti di buio e sconforto.
Grazie Marco e a presto per nuove iniziative.
Ma che cos’è il prestigio e perché è così importante da permeare tutta la nostra vita, subito o esercitato?
L’etimologia della parola non chiarisce: “illusione prodotta con destrezza di mano e quindi impostura, fallacia inganno”. Eppure nel nostro uso corrente assume una semantica totalmente opposta, e quella che preferisco attribuirgli è la “la capacità di sedurre e di imporsi alla fantasia altrui”.
In questo tutta la socialità del prestigio: non si può essere soli nell’esercitarlo occorre una comunità che lo riconosca e lo esalti. Per ciò trovo lo statuto tremendamente chiarificante.
Auguro a tutti i soci ogni bene, che ci siano di guida e illuminino con le loro gesta i nostri momenti di buio e sconforto.
Grazie Marco e a presto per nuove iniziative.
lunedì 21 dicembre 2009
Technical debt
In un mondo perfetto non ci sono Technical Debt (TD). Ma noi non viviamo in un mondo perfetto e e questo non è un male!
Le (mie) tre vie al TD:
- Lo si compie inconsciamente e non lo si riconosce
- Lo si compie consciamente e lo si ignora
- Lo si compie consciamente, lo si valuta e lo si annota (è di fatto un bug)
Noi viviamo di TD perché se non ci fossero vorrebbe dire semplicemente che abbiamo costruito un sistema perfetto, che non esiste, quindi lo sforzo più grande è capire quando ci si deve fermare.
Un esempio di TD ambiguo é secondo legato agli aspetti di Premature Optimization (PO: la radice di tutti i mali); eppure nel fluire del codice dalla nostra mente al nostro editor di fiducia occorre ignorare il TD per non incorrere nella PO.
Certo identificare un TD a livello micro è forse scorretto e va contro la logica del TD, ma la stessa cosa si può applicare salendo di livello al design: se decidiamo di implementare una funzionalità utilizzando una tecnica semplice e inefficiente al posto di una complessa e efficiente (assumendo che l’efficienza sia un requisito) abbiamo un TD, d’altra parte sforzarsi prematuramente per rendere del codice efficiente già a partire dal design ritorna ad essere una PO.
La chiave di tutto deve naturalmente essere il contesto e l’analisi dei tradeoff che si hanno quando ci si trova a scegliere una strada piuttosto che un’altra quindi se da una parte occorre combattere l’ignoranza (propria o degli altri) che causa TD senza accorgersene, educare o educarsi all’analisi dei tradeoff è un requisito altrettanto fondamentale.
Inspired by:
http://blog.objectmentor.com/articles/2009/10/15/we-must-ship-now-and-deal-with-consequences
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
http://blog.objectmentor.com/articles/2009/09/22/a-mess-is-not-a-technical-debt
Must learn: tradeoff analysis
Le (mie) tre vie al TD:
- Lo si compie inconsciamente e non lo si riconosce
- Lo si compie consciamente e lo si ignora
- Lo si compie consciamente, lo si valuta e lo si annota (è di fatto un bug)
Noi viviamo di TD perché se non ci fossero vorrebbe dire semplicemente che abbiamo costruito un sistema perfetto, che non esiste, quindi lo sforzo più grande è capire quando ci si deve fermare.
Un esempio di TD ambiguo é secondo legato agli aspetti di Premature Optimization (PO: la radice di tutti i mali); eppure nel fluire del codice dalla nostra mente al nostro editor di fiducia occorre ignorare il TD per non incorrere nella PO.
Certo identificare un TD a livello micro è forse scorretto e va contro la logica del TD, ma la stessa cosa si può applicare salendo di livello al design: se decidiamo di implementare una funzionalità utilizzando una tecnica semplice e inefficiente al posto di una complessa e efficiente (assumendo che l’efficienza sia un requisito) abbiamo un TD, d’altra parte sforzarsi prematuramente per rendere del codice efficiente già a partire dal design ritorna ad essere una PO.
La chiave di tutto deve naturalmente essere il contesto e l’analisi dei tradeoff che si hanno quando ci si trova a scegliere una strada piuttosto che un’altra quindi se da una parte occorre combattere l’ignoranza (propria o degli altri) che causa TD senza accorgersene, educare o educarsi all’analisi dei tradeoff è un requisito altrettanto fondamentale.
Inspired by:
http://blog.objectmentor.com/articles/2009/10/15/we-must-ship-now-and-deal-with-consequences
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
http://blog.objectmentor.com/articles/2009/09/22/a-mess-is-not-a-technical-debt
Must learn: tradeoff analysis
Iscriviti a:
Post (Atom)