Nelle mie peripezie nel web ho incontrato un altro articolo piuttosto interessante riguardo la programmazione ed il modo di lavorare.

Questo articolo in particolare affronta alcuni aspetti molto interessanti su come mantenere un'elevata produttività quando si lavora a casa.

Ecco il link: 20 aspetti da considerare per migliorare la produttività del lavoro da casa

Ecco i diversi punti affrontati:

1. Etica del lavoro: cercare di fissare degli obiettivi di lavoro minimi, e cercare di migliorarli.
   
2. Non sovrastimare la produttività: è importante cercare di migliorare la produttività con piccoli passi.
   
3. Non considerare le attività di basso valore: è fondamentale concentrare i propri sforzi sulle attività più importanti, tralasciando quelle attività che sono poco importanti e poco redditizie.
   
4. Eliminare le distrazioni: il lavoro da casa espone a molte distrazioni... chat, rss, email... è fondamentale concentrarsi sul lavoro principale eliminando le distrazioni, perché impediscono di lavorare al meglio.
   
5. Svegliarsi presto: iniziare a lavorare il prima possibile è una buona idea, consente di pianificare le attività con più calma durante la giornata.
   
6. Consapevolezza della propria energia: è molto importante conoscere il livello della propria produttività, nel caso in cui la produttività scenda molto, una pausa è necessaria per riprendere fiato.
   
7. Imparare a dire no: lavorando da casa è molto probabile che qualche amico, parente o conoscente possa distrarre dal lavoro... bisogna imparare a dire di no in queste occasioni, altrimenti la produttività ne risentirà.
   
8. Impostare obiettivi giornalieri: cercare di fissare degli obiettivi di lavoro da raggiungere a fine giornata aiuta molto a migliorare l'organizzazione del lavoro.
   
9. Usare la legge di Parkinsons: la legge di Parkinsons sostiene che un'attività si espande fino alla durata che noi gli concediamo. Da questo deriva che bisogna cercare di finire al più presto quelle attività dove il completamento è più importante della perfezione.
   
10. Imparare ad agitarsi: a volte capita di bloccarsi mentre si sviluppa qualcosa e di agitarsi... in quei casi prendere del tempo aiuta a calmare l'agitazione.
    
11. Ceare un ambiente professionale: l'ambiente di lavoro è importante, perché deve trasmettere professionalità, troppa "fantasia" può disturbare la produttività.
    
12. Fissare un orario di lavoro: avere un orario di lavoro aiuta a massimizzare la produttività, perché consente di mantenere l'equilibrio tra vita privata e lavoro.
    
13. Qual'è l'attività più importante? Bisogna sempre conoscere l'attività più importante da svolgere, in modo da non perdere di vista l'obiettivo del proprio lavoro. Anche nelle giornate meno produttive, portare a termine l'attività più importante può far bene.
    
14. Vita sociale: il lavoro da casa elimina una buona fetta di vita sociale che invece si ha in molti posti di lavoro... per questo è importante cercare di mantenere un buon livello di vita sociale anche quando si lavora da casa.
    
15. Variare le attività: la diversificazione delle attività da svolgere durante la giornata aiuta molto a mantenersi "freschi", per contro, la monotonia tende ad aumentare la percezione di noia e stanchezza.
    
16. Noia prima di mollare: quando un'idea su cui lavoriamo non ci piace, annotiamo quanto tempo passa prima che venga un'idea nuova. Cercare di resistere alle distrazioni in quei casi può essere importante... magari cercando di insistere altri 5 o 10 minuti.
    
17. Prospettive esterne: lavorando da soli può accadere di non avere più idee, per questo è importante costruire un network di persone (online) che possono offrire punti di vista e prospettive diverse.
    
18. Straordinari: quando si è coinvolti in un lavoro importante, spesso capita di dover fare degli straordinari per completare delle sezioni. In questo caso può essere utile prendersi del riposo extra il giorno dopo, per evitare che il lavoro invada troppo il tempo da dedicare a noi stessi.
    
19. Altri 15 minuti: quando non si riesce ad andare avanti, o si sente un forte bisogno di smettere, a volte può essere utile concedersi altri 15 minuti di lavoro. Se la situazione non si sblocca, allora una pausa è sicuramente necessaria.
    
20. Sfruttare la flessibilità: bisogna trarre vantaggio dalla flessibilità del lavoro da casa. Ciò significa che è molto importante tarare il proprio orario di lavoro in funzione anche della nostra vita privata. Con un po' di disciplina si può raggiungere un equilibrio.

Ho tradotto i vari punti cercando di interpretare il punto di vista dell'autore, aggiungendo di tanto in tanto qualche piccola considerazione personale.

In particolare tra i vari punti quelli che mi hanno più colpito sono quello della sveglia mattutina e della vita sociale.

Sul punto della "vita sociale" sono pienamente d'accordo con l'autore, e trovo che una delle cose più alienanti del lavoro da casa è spesso la mancanza di confronto. Il confronto aiuta molto lo sviluppo di nuove idee, e nella maggior parte dei casi aumenta la produttività.

Riguardo invece la "sveglia mattutina" io credo che sia importante capire i momenti della giornata in cui la produttività è maggiore, e questi variano da persona a persona. Io in particolare sono molto produttivo la mattina e la notte, mentre il pomeriggio assolutamente no. Soprattutto, alcune fasce della giornata facilitano la "tranquillità" dell'ambiente: lavorando dopo mezzanotte ad esempio si ha una tranquillità unica (poche persone "in giro" e poco inquinamento acustico).

E voi? Vi piacerebbe lavorare da casa?

Vi siete mai chiesti come valutare un buon team di sviluppo software? Quali requisiti deve possedere secondo voi una buona squadra di programmatori?

Ci sono dei questionari molto complessi che possono aiutare a fare una Due Diligence su una Software House (o più semplicemente un gruppo di freelancer).

Ad esempio, su questo link SEMA trovate una società molto famosa nel settore nel valutare l'intero processo produttivo e la capacità di rispettare le consegne controllando al massimo i flussi dei processi decisionali ed operativi.

Qualche giorno fa però ho letto un articolo molto interessante sul blog di un programmatore della MicroSoft ed ho trovato diversi spunti di riflessione molto utili per qualunque programmatore.

L'intero articolo lo trovate a questo link (in inglese): 12 Passi Per Migliorare La Qualità Dello Sviluppo Software

L'autore sviluppa 12 punti che secondo lui sintetizzano al meglio gli aspetti più importanti di un buon team di sviluppo.

Passi per migliorare la qualità dello sviluppo software

1. Sono disponibili strumenti di controllo per il codice sorgente?
   
2. E' possibile creare un pacchetto completo e funzionante tramite una sola procedura?
   
3. Vengono generate build (release, versioni) giornaliere?
   
4. Esiste un database per monitorare i bugs?
   
5. Vengono corretti i bugs prima di scrivere nuovo codice?
   
6. Esiste una pianificazione delle scadenze aggiornata frequentemente?
   
7. Esiste una lista di specifiche da seguire?
   
8. I programmatori lavorano in un ambiente sereno?
   
9. Vengono utilizzati i migliori strumenti a disposizione?
   
10. Esiste un team che si occupa di testare il software?
    
11. In caso di colloqui a nuovi candidati, viene fatto scrivere loro del codice?
    
12. Vengono effettuati test di usabilità?

L'autore ironizza sostenendo che questo test è semplicissimo... le risposte sono SI o NO, e basta contare 1 punto per ogni SI.

Secondo lui un punteggio da 10 in su indica una buona e solida struttura, mentre al di sotto di tale livello, le cose peggiorano avvicinandosi allo 0. In particolare sostiene che buona parte delle Software House non arrivano neanche a 3, mentre compagnie come la MicrosSoft (per la quale lavora... sarà mica un'opinione distorta?) lavorano costantemente ad un livello di 12 su 12.

Ovviamente questo test non indica il grado di successo di una società: anche avendo 12 su 12, non è detto che i software sviluppati siano di qualche interesse per qualcuno!

Questo test dunque serve solo per avere delle indicazioni sulla affidabilità e la qualità del processo di sviluppo. E' fondamentale invece per il successo avere delle idee geniali ed originali, e saperle poi rivendere sul mercato.

Personalmente condivido abbastanza il punto di vista di questo programmatore. Sviluppando software da diversi anni ed in maniera amatoriale, ho imparato sulla mia pelle diversi aspetti che all'inizio ignoravo sul modo di programmare.

In particolare sottolineo solo alcuni aspetti che mi riguardano più da vicino (dal momento che gestisco un team di sole 3 persone):

• Sono disponibili strumenti di controllo per il codice sorgente?
  
• E' possibile creare un pacchetto completo e funzionante tramite una sola procedura?
  
• Esiste un database per monitorare i bugs?
  
• Vengono corretti i bugs prima di scrivere nuovo codice?
  
• Esiste una pianificazione delle scadenze aggiornata frequentemente?
  
• Esiste una lista di specifiche da seguire?

Controllo del codice sorgente
Soltanto da poco più di un anno ho imparato ad utilizzare un repository online per il codice sorgente (SVN). Questo strumento di controllo è fondamentale, perché consente a più programmatori di lavorare contemporaneamente su un progetto senza dover stare attenti a sovrascrivere files usati e/o modificati dagli altri. Un software di controllo infatti tiene traccia di tutte le modifiche effettuate al codice da parte dei diversi programmatori, ed in caso di errore consente con pochi click di ripristinare files magari cancellati o modificati per sbaglio. Un'altra caratteristica importante è quella che consente di unire con un solo click le modifiche apportate dai diversi programmatori che lavorano sullo stesso codice. E' fondamentale avere dunque uno strumento che consente di avere tale tipo di controllo, soprattutto quando a sviluppare il software è coinvolta più di una persona.


Creazione pacchetti completi con un click
Un'altra cosa che ho imparato solo un paio di anni fa è l'importanza di avere una procedura che generi pacchetti funzionanti in maniera automatica e veloce. Spesso è necessario testare "live" delle funzionalità, e per farlo è importante avere un pacchetto pulito su cui lavorare. I primi tempi perdevo almeno 30 minuti quando dovevo creare un pacchetto pulito... con il poco tempo a disposizione ho capito che non me lo potevo più permettere. Per questo ho programmato diverse procedure che mi consentono di avere in un paio di minuti diversi pacchetti da poter utilizzare per i test (ed anche per aggiornare il repository) ed eventualmente distribuire a persone che mi aiutano con il beta testing. Beh, da quando l'ho fatto, la mia produttività è migliorata nettamente.


Database monitoraggio bugs
Ahimé questa è una nota dolente... è normale in fase di sviluppo scrivere del codice che abbia degli errori. I bugs sono all'ordine del giorno, qualunque programmatore lo sa. Ovviamente ciascuno ha il suo stile, c'è chi preferisce scrivere da subito del codice pulito ed efficiente, mentre c'è chi preferisce buttare prima giù una bozza (anche se piena di errori) ed aggiustare il tiro strada facendo. Ovviamente è importante tenere traccia dei bugs, perché altrimenti si rischia di dimenticarsi delle correzioni da fare, e soprattutto è molto più efficiente correggere velocemente il codice scritto male piuttosto che farlo a distanza di mesi. Personalmente ho creato un database per il monitoraggio dei bugs, ma purtroppo ancora non lo uso a pieno regime come invece dovrei.


Quando correggere i bugs?
L'autore dell'articolo sostiene che i bugs vanno corretti quanto prima, perché si ha in testa il codice ancora fresco. Per contro, se passassero diversi giorni, è probabile che si perda molto tempo perché bisogna dapprima rileggere il codice scritto giorni prima per rinfrescare la logica. Su questo c'è poco da aggiungere... la penso esattamente come lui, e personalmente do sempre massima priorità ai bugs appena li scopro.


Pianificazione attività
Fortunatamente gran parte dei progetti che seguo sono amatoriali, e non c'è uno scheduling (pianificazione) molto rigido. Però mi pare ovvio che pianificare nel tempo delle scadenze per il completamento delle cosiddette "milestones" (pietre miliari, obiettivi intermedi) è molto importante quando si sviluppa un software in team. Certo, i programmatori non adorano di certo le scadenze... però il rischio di non avere nessuna scadenza è di gran lunga più elevato del rischio di averne. A condizione che le scadenze siano stabilite in maniera oculata. Ad esempio avere scadenze troppo ravvicinate o ambiziose, forza i programmatori a scrivere codice molto velocemente, il che spesso si concretizza in un elevato numero di bugs o funzioni incomplete. Per contro, non avere scadenze affatto può invece indurre i programmatori più "pignoli" ad "innamorarsi" troppo del loro codice, a cercare di perfezionarlo sempre di più senza mai arrivare ad una conclusione. Per cui questo aspetto è sicuramente molto importante in team di sviluppo (anche per evitare che alcune porzioni di software siano pronte prima di altre con cui devono interagire, rallentando poi anche i test e gli sviluppi successivi), a condizione che chi decida le scadenze abbia le competenze giuste per stabilirle in maniera corretta.


Specifiche del software
Anche questo punto è piuttosto autoesplicativo. Prima di programmare qualcosa ho imparato che è importante stilare una lista di requisiti e funzionalità, perché altrimenti si rischia di sprecare tempo prezioso durante lo sviluppo. Soprattutto quando si lavora in team, se le specifiche non sono chiare, il rischio che un programmatore vada "off topic" è elevatissimo. Non solo è importante avere specifiche chiare, ma è altrettanto importante che ci sia qualcuno (di diverso dal programmatore che ha scritto il codice) che regolarmente controlli l'aderenza tra specifiche e codice scritto.


Ovviamente se avete degli spunti di riflessione anche voi, sono ben accetti!

Ho letto un articolo molto interessante riguardo gli elementi da considerare per individuare i bravi programmatori da assumere per lo sviluppo di un'attività economica.

L'articolo si trova qui:
How To Recognize A Good Programmer

Dal momento che ho trovato diversi spunti di riflessione validi, ne faccio una sintesi aggiungendo mie considerazioni.

Partiamo dalla tabellina a fondo pagina che riassume gli elementi positivi e negativi della valutazione.

Indicatori Positivi:

• Appassionato di tecnologia
  
• La programmazione è anche tra i suoi hobby
  
• Se stimolato può parlare per ore di argomenti tecnici
  
• Ha seguito diversi progetti amatoriali / open source nel corso degli anni
  
• E' un autodidatta nel campo della tecnologia
  
• E' in grado di classificare strumenti tecnologici in base al miglior uso che se ne può fare
  
• Si trova a disagio nel lavorare con tecnologie in cui non crede
  
• Persona molto sveglia in grado di fare conversazione su molti argomenti diversi
  
• Ha iniziato a programmare prima dell'università o del suo primo lavoro
  
• Segue progetti anche molto grandi non indicati nel CV
  
• Conoscenza di una vasta varietà di tecnologie non correlate tra loro

Indicatori Negativi:

• Programma solo in orario di lavoro
  
• Non ama conversare di tecnologia anche se invitato a farlo
  
• Apprende nuove tecnologie soltanto se l'azienda lo invia ad un corso di aggiornamento
  
• E' contento di utilizzare qualunque tipo di tecnologia ("tutte le tecnologie sono valide")
  
• Non appare molto intelligente
  
• Ha iniziato a programmare all'università
  
• Tutte le esperienze di programmazione sono incluse nel CV
  
• Focalizzato principalmente su poche tecnologie senza grosse competenze sul resto

Devo dire che leggendo questi indicatori mi sono trovato in accordo per la maggior parte dei punti.

Mi pare ovvio (anche se è meglio precisarlo) che essere d'accordo non vuol dire che non esistano ottimi programmatori che lo fanno solo per lavoro o che non siano curiosi di apprendere nuove tecnologie... In questo caso essere d'accordo significa semplicemente che (a mio modo di vedere) buona parte dei programmatori validi hanno diversi punti in accordo con gli "Indicatori Positivi" e raramente troveremo ottimi programmatori che hanno solo "Indicatori Negativi".

Io programmo per passione, per me è un passatempo al pari di fare un cruciverba o giocare a giochi di ruolo. Lo trovo estremamente stimolante perché mi costringe ad usare la logica in contesti spesso molto complessi e che abbracciano diversi aspetti. Nel mio caso specifico seguo un progetto amatoriale piuttosto vasto che include oltre 300.000 righe di codice e migliaia di files, il che richiede molto spesso un livello di concentrazione e "multitasking" piuttosto elevato. Faccio questa premessa perché secondo me è davvero molto importante, se non fondamentale, che un programmatore ami programmare anche nel proprio tempo libero.

Nel corso degli anni ho avuto modo di conoscere diversi programmatori, alcuni molto validi, altri meno. Devo dire che spesso mi è capitato di notare dei tratti comuni tra i programmatori che ho stimato di più. Proviamo ad analizzarne qualcuno in comparazione con i punti indicati nell'articolo da cui ho preso spunto.

1. Passione
   Sicuramente sono d'accordo con l'autore su questo punto. Un bravo programmatore deve avere la passione per la programmazione. Certo, questo è valido praticamente in ogni settore, se uno è appassionato rende meglio, perché ha una motivazione in più a spingerlo. Ci sono anche alcuni casi famosi nella storia di persone magari appassionate di altro che però rendevano meglio in altri settori: il caso che più mi ha colpito è stato quello di Michael Jordan, re indiscusso del basket USA per diversi anni che però è sempre stato appassionato di Baseball tanto da fargli lasciare il basket. In ogni caso tornando alla programmazione, se io dovessi assumere un programmatore, ne vorrei uno appassionato, che pensi al codice anche quando non è pagato per farlo, che trovi stimoli a sviluppare quando ha le intuizioni giuste, non necessariamente negli orari convenzionali di lavoro.
   
   
2. Autoapprendimento E Curiosità
   Anche su questo punto sono d'accordo con l'autore. Quello che fa la differenza tra un buon programmatore ed un ottimo programmatore (al di là del bagaglio di conoscenze e dell'esperienza) è la curiosità di apprendere cose nuove e la volontà di farlo anche da solo, senza la necessità di seguire qualche corso o la pigrizia di avere qualcuno che lo istruisca a riguardo. Spesso quando si sviluppa del codice ci si trova di fronte a problemi mai affrontati prima, è in quei momenti che deve venir fuori la curiosità di trovare il modo migliore per risolverli anche ricorrendo a tecniche e strumenti nuovi. Certamente questo richiede del tempo (e non sempre i datori di lavoro o i committenti te ne danno...) però è importante saper investire in sé stessi curiosando di qua e di là per il web o tra i libri per trovare nuovi spunti ed idee.
   
   
3. Intelligenza
   Questo punto è sicuramente uno dei più complessi e controversi. Esistono diversi tipi di intelligenza, per cui definire un soggetto più intelligente di un altro può essere molto complesso. Spesso si confonde tra l'altro intelligenza con cultura, il che porta a conclusioni errate. L'autore si sofferma molto sull'aspetto sociale, sottolineando come troppo spesso si confonde una persona poco socievole con una persona poco intelligente. Secondo l'autore si può trovare una persona molto socievole ma poco intelligente, ma mai (o molto raramente) una persona che sia allo stesso tempo molto intelligente e poco socievole. Su questo punto devo dire che non sono molto d'accordo. Il motivo è semplice, ci sono persone molto timide e riservate che prima di "aprirsi" dal punto di vista sociale hanno bisogno di comprendere bene "l'ambiente" in cui si trovano e i soggetti con cui hanno a che fare. E ciò non vuol dire che siano necessariamente persone poco intelligenti. Tra l'altro spesso mi è capitato che persone molto intelligenti fossero anche poco "tolleranti", il che in un certo senso non è propriamente amore per la vita sociale. Di certo però è fondamentale per un buon programmatore detenere una buona dose di intelligenza logico / matematica, senza la quale lo sviluppo di applicazioni complesse sarebbe oltremodo difficile.
   
   
4. Esperienza "Nascosta"
   L'autore stressa particolarmente questo punto come estensione della Passione. In particolare sostiene che la maggior parte dei buoni programmatori ha iniziato a programmare in età molto giovane, sviluppando magari progetti per conto proprio che però non vengono inseriti nei CV perché non ritenuti importanti. Personalmente non avrei separato questo punto dal primo, perché secondo me in fondo si tratta dello stesso aspetto. Se non altro aver separato questo punto consente di focalizzarsi su alcune domande che potrebbero essere fatte in fase di colloquio per determinare il grado di "Passione" verso la programmazione. Ad esempio facendo domande specifiche su progetti seguiti non inclusi nel CV sarebbe possibile cogliere degli aspetti che magari non sarebbero stati considerati.
   
   
5. Varietà Di Tecnologie
   L'autore sostiene che un buon programmatore (ovviamente che non sia troppo giovane, nel qual caso non avrebbe avuto tempo materiale per apprendere) debba conoscere diverse tecnologie possibilmente non strettamente correlate tra loro. Per contro un programmatore "over" specializzato potrebbe non essere il programmatore che stiamo cercando. Su questo punto sono solo parzialmente d'accordo. E' vero che la curiosità di apprendere cose nuove rientra nel punto 2 e dunque a parità di requisiti sceglierei un programmatore più curioso. Però non me la sento di etichettare un programmatore come non valido solo perché è specializzato eccessivamente in una tecnologia. A volte ci sono dei programmatori che vogliono imparare a governare alla perfezione tutti gli aspetti di una tecnologia e non è detto che non siano in grado di espandere le proprie conoscenze ove richiesto. Certo aver già mostrato in passato di essere molto flessibili ed essere curiosi può essere un punto a favore... ma non dimentichiamoci che ci sono molti programmatori che (sebbene molto curiosi) non riescono a portare a termine i propri progetti. Si tratta di quei casi dove l'eccessiva curiosità si trasforma in disorganizzazione ed incapacità di avere una visione di insieme. Questo punto lo ricondurrei dunque al secondo: è fondamentale riuscire ad individuare il giusto equilibrio tra curiosità, voglia di apprendimento e capacità di organizzazione.
   
   
6. Qualifiche Formali
   Questo aspetto viene definito come un "non indicatore" piuttosto che un indicatore. Il motivo è semplice: ci sono molti programmatori che tendono ad inserire nel CV qualunque tipo di corso o qualifica ottenuto nel tempo. L'autore sostiene che non bisogna fossilizzarsi troppo sul titolo e sull'esperienza, perché ci sono programmatori altrettanto validi che magari non hanno un diploma specifico nel settore. Su questo sono d'accordo. Ho conosciuto ragazzi di 16 anni in grado di programmare cose "inconcepibili" per programmatori di 25 anni magari con già diversi anni di esperienza sul campo e qualche diploma. Per cui direi proprio che è fondamentale non soffermarsi superficialmente sui "titoli" detenuti da un potenziale candidato, perché in alcuni casi potrebbero essere fuorvianti. L'invito è dunque quello a indagare a fondo sulle effettive competenze piuttosto che affidarsi ad un certificato rilasciato (o non rilasciato) da altri!
   

Dopo aver analizzato i diversi punti, ed aver riflettuto sull'argomento, mi sento di poter definire i miei punti focali per valutare la qualità di un programmatore:

1. Passione per l'informatica: un buon programmatore mediamente scrive codice per passione, non soltanto nell'orario di lavoro, ma anche nel tempo libero.
   
2. Curiosità ed autoapprendimento: la programmazione è un mondo costantemente in evoluzione, è fondamentale per un buon programmatore essere curioso sulle nuove tecniche e tecnologie ed essere in grado di apprenderle per conto proprio (senza la necessità di avere un "tutore).
   
3. Capacità di organizzazione e di lavorare per obiettivi: è molto importante riuscire ad avere una visione di insieme quando si programma, soprattutto in progetti piuttosto vasti e complessi. Non tutti i programmatori sono in grado di averla, e spesso capita che alcuni programmatori siano in eterna fase "beta" incapaci di arrivare ad una release. Non è facile valutare questo aspetto ovviamente, però qualche elemento si può riuscire ad estrarlo analizzando le esperienze ed i progetti passati.
   
4. Intelligenza logico / matematica: senza questo tipo di predisposizione a mio avviso non si può essere buoni programmatori. Finora non mi è mai capitato di trovare programmatori (che io ritengo) validi senza questo tipo di requisito. Certo è difficile riuscire a valutare questo tipo di intelligenza con pochi elementi, magari dei test possono risultare utili.
   
5. Autoironia e simpatia: si avete letto bene... autoironia e simpatia. Questo elemento è mio personale e non è citato dall'autore, mentre gli altri in qualche modo sono stati affrontati. Aggiungo questo elemento per un motivo molto semplice: lo sviluppo di programmi complessi spesso richiede tempi molto lunghi, con molta attività di debugging. Il debugging è molto frustrante e mette il programmatore costantemente di fronte ai propri errori. Un buon programmatore deve saper comprendere ed affrontare i propri errori. Senza un minimo di autoironia (il che presuppone autocritica) e di spirito di divertimento potrebbe essere molto difficile saper affrontare lo sviluppo di codice complesso. Non pretendo che siate d'accordo su questo punto... ma a mio avviso è un requisito molto importante. E l'ho riscontrato praticamente in tutti i programmatori che finora ho ritenuto "validi". Forse una sola eccezione!

Spero che qualcuno trovi utili questi spunti, e ovviamente resto aperto al confronto nel caso aveste delle osservazioni.

Una collezione di foto fantastiche... provate a dare uno sguardo!

• 100+ Beautiful Examples of Black and White Photography
  
• Mix Collection of 88 Stunning Photographs to Refresh Your Mind
  
• 100+ Examples of Brilliant Tilt-Shift Photography
  
• 88 Examples of Incredible Aerial Photography
  
• Mix Collection of 99 Stunning Photographs to Refresh Your Mind
  
• Enjoy Moments Of Reflective Photography – Part I, Part II
  
• Rainbow Colors Inspired Photos and Pictures – Part I, Part II
  
• Motion and Blur Photography for Inspiration – Part I, Part II
  
• Strange and Fantastic Buildings Architecture – Part I, Part II

Ciao a tutti,
eccomi qui con il mio solito monologo natalizio.

Quest'anno non ho granché da dire, siete fortunati...

Natale anche quest'anno capita a fine anno... periodo di riflessioni e di contabilità per chi come me ha un diploma da ragionere.

Quest'anno ho deciso che è meglio lasciar da parte la contabilità, perché è stato un anno molto complicato.

Era tempo che non provavo sensazioni così forti e contrastanti nel corso dello stesso anno... e se da una parte è un bene, dall'altra... non sono affatto soddisfatto di come ho gestito la mia vita.

Vorrei chiedere a Babbo Natale di donarmi un po' di forza di volontà, perché quest'anno ne ho bisogno come non mai.

Auguro a tutti voi di trascorrere un allegro natale, un natale vivo, insieme alle persone a cui volete più bene.

Un caro abbraccio a tutti.

Vi siete mai chiesti se esistano delle regole scientifiche per vincere a Black Jack?

Nel 1977 Jerry L. Patterson ha pubblicato un libro sul black jack intitolato "Blackjack: A Winner’s Handbook" ossia "Manuale per vincere a Black Jack". In questo libro vengono descritte numerose strategie da poter seguire nel gioco del Black Jack.

Con l'avvento dei casinò online, nuovo interesse è nato verso il mondo dei giochi d'azzardo, in particolare Poker e Black Jack. Tanto interesse ha spinto l'autore nel 2001 a pubblicare una nuova edizione del proprio libro introducendo anche strategie riguardanti il gioco online.

Molti giocano soltanto per il gusto di giocare, affidandosi totalmente al caso... invece per poter diventare giocatori professionisti è molto importante affrontare anche aspetti scientifici per poter minimizzare il rischio di perdite e/o massimizzare i guadagni. Nel libro di Patterson si possono trovare diverse tecniche di conteggio e di Money Management che consentono di migliorare le capacità previsive e di gestione del proprio capitale durante il gioco. Non solo, nel testo viene descritto anche un nuovo modo per affrontare il banco al tavolo di black jack, ossia il cosiddetto "card-clumping" adatto a tutti i giocatori di black jack che hanno visto fallire i propri metodi di conteggio delle carte a causa delle contromisure adottate dai casinò nel mischiare i mazzi di carte.

Nel Black Jack ovviamente non conta soltanto l'aspetto scientifico, ma anche quello emotivo, perché in fin dei conti ogni gioco viene eseguito da esseri umani. Nel libro infatti vengono affrontati anche concetti relativi a tale aspetto. Ad esempio viene introdotta una strategia non basata su sistemi di conteggio delle carte, chiamata TARGET 21, ed elaborata da Eddie Olsen, che porta i giocatori di black jack a dividersi fondamentalmente in due categorie distinte: la prima può essere definita come quella dei giocatori tradizionali, cioè coloro che continuano ad usare sistemi di conteggio delle carte per ottenere dei risultati al tavolo di black jack nel lungo termine; nella seconda categoria rientrano invece i giocatori della nuova era, ossia quelli che tentano di evolvere insieme al gioco che con il passare del tempo cambia esso stesso, e cercano quindi di adottare strategie per vincere nel breve termine.

Come ogni gioco che si rispetti dunque, esistono delle strategie che se conosciute ed usate regolarmente possono portare il giocatore a risultati migliori, e magari a vincere qualcosa di più...

Mi fermo qui con la recensione del libro... se volete saperne di più, leggete "Blackjack: A Winner’s Handbook" di Jerry L. Patterson.

Caro Diario,
giuro che non lo faccio apposta... ma cavolo... ogni anno a dicembre ho bisogno di te.

Eddai su... non fare così, ti voglio bene lo sai.

Ok ok... la smetto di fare il cretino e arrivo al sodo... tanto ormai mi conosci, per cui sai che sono fatto così!

Stavolta vorrei parlarti del "ruolo" e degli "atteggiamenti" che io ho con le persone a me care e che loro hanno con me.

In particolare mi riferisco al fatto che in ogni rapporto (dubito che qualcuno ne sia esente...) ci sono delle piccole menzogne, delle verità non dette... qualcosa che non si ha il coraggio di dire perché ci si vergogna, o perché si ritiene che possa far male o ancora più semplicemente perché non si ha il coraggio di essere sinceri.

Già altre volte su questo sito abbiamo parlato di sincerità, di cosa significhi per noi, di quanto sia importante tutelarla sempre e di quando (ahimé) invece possa essere "meglio" nasconderla o alterarla.

Per me la sincerità è un fattore importante, imprescindibile... anche quando fa male la vorrei e la vorrei donare. Su certe cose sono sempre stato un idealista e mi infervoro molto quando vengono in qualche modo scalfiti i miei ideali. Ricordo in particolare una discussione di qualche anno fa in cui c'era chi sosteneva che a fin di bene poteva essere necessario non essere del tutto sinceri... anche conoscendo la volontà dell'altra persona. Ricordo che anche allora io difesi "a spada tratta" la mia tesi... sincerità sempre... no way in the middle! Con il mio modo di difendere i miei ideali ferii diverse persone che avevano le loro ragioni per sostenere un'altra tesi. Beh questo è un mio difetto "certificato" lo conosco e ci convivo... a volte mi sento un po' il Dr. House, incapace di trattenere ciò che penso quando si tratta di difendere la propria "razionalità" (concetto molto soggettivo...) ed incapace di capire che si può anche ferire molto con questo modo di fare.

Dopo tanto tempo e tante discussioni fatte sia su forum che tra amici, oggi questo argomento della sincerità mi "tormenta" non poco. Non solo dal lato attivo... ma anche dal lato passivo. In che senso? Semplice... per lato attivo intendo sincerità totale che mi sento in diritto di donare alle persone care (ma che per qualche ragione non riesco a donare)... mentre per lato passivo intendo sincerità totale che alcune persone a me care non riescono a donarmi.

Quali sono le ragioni che bloccano questo "flusso" di sincerità?

Ovviamente se ne possono elencare diverse, anche perché dipende dal tema... e poi la mente umana è così complessa!

Al di là delle ragioni legate al fatto che la controparte potrebbe non essere in grado di intendere e di volere completamente (insanità mentale, infanzia, depressione, etc...) credo che la maggior parte delle volte la mancanza di sincerità sia legata ad insicurezza.

Ora vi faccio un paio di esempi, altrimenti qui continuiamo a parlare di teoria e non riesco a farmi capire...

• Supponiamo che voi siate idealisti come me e vorreste essere sinceri sempre con le persone a voi care... supponiamo che un vostro caro parente abbia una malattia mortale e voi ne siate a conoscenza... mentre il vostro caro parente ha espresso la volontà di non volerlo sapere. Voi cosa fareste? Da una parte il rispetto verso l'altra persona vi spinge a rispettare la sua scelta, anche se il vostro atteggiamento sarà per ovvi motivi "castrato"... dall'altra il vostro ideale vi spinge a voler essere sinceri e magari affrontare il discorso. Insomma... Cosa fareste voi?
  
• Supponiamo sempre che voi siate idealisti della sincerità... supponiamo che voi scoprite per caso che la moglie di un vostro caro amico lo tradisce e ne avete le prove... voi che fate? Parlate con il vostro amico? Gli mandate un'email anonima? Parlate con la moglie? Complichiamo le cose... supponiamo che sappiate anche che il vostro amico non vorrebbe saperlo... Cosa fareste voi?
  
• Supponiamo ora che voi NON siate idealisti della sincerità... supponiamo che avete un rapporto molto importante con un'altra persona e portate una cosa dentro che non avete il coraggio di dire, ma il vostro partner invece è idealista della sincerità (può capitare no?) e sapete che vorrebbe saperla. Come vi comportate?

Potrei continuare con altri esempi... l'obiettivo non è capire come affrontare queste situazioni, le ho inventate, sono esempi su cui rifletto da tanto (e che spesso propongo agli amici quando parliamo di questo tema), perché sono situazioni di vita che potrebbero non essere remote, e a me piace vagare con la mente e calarmi in situazioni non reali, perché adoro pensare e riflettere sul modo migliore di affrontare determinate situazioni... forse per essere pronto in caso ne avessi bisogno.

L'obiettivo di questa discussione è più che altro questo...

E' giusto che qualcuno si arroghi il diritto di decidere per noi su faccende importanti che ci riguardano? E' giusto che qualcuno si comporti dunque come un "tutore" per noi?

Ed ora il risvolto della medaglia...

E' giusto che qualcuno si arroghi il diritto di volerci "tutori" costringendoci in qualche modo a decidere per loro e portarci dentro dei "pesi"?

Ecco io oggi mi chiedo questo... non riesco a trovare risposta... forse perché non ne esiste una razionale... forse perché dipende troppo dai singoli casi e non si può scrivere una regola... ma cavolo, dovrà pur esserci qualche indizio che ci aiuti ad affrontare queste situazioni no?

Caro Diario... per oggi ho finito, se hai qualche spunto... sono qui.

Grazie!

Finalmente MG.COM ha una casa tutta sua e più veloce che mai...

Il trasloco è durato diversi giorni, spero che sia tutto a posto... se notate qualcosa che non va, fatemelo sapere!

Buon Natale a tutti... a ciascuno nel modo in cui lo vuole intendere e trascorrere.

Io credo sia normale che per molte persone il Natale o le feste siano più un "fastidio" che un momento di felicità vera e propria.

La voglia di sognare e di immaginare un mondo bello e buono è una cosa che ci viene insegnata fin da bambini (almeno per i più fortunati di noi). Il bisogno di sognare e di credere in qualcosa è insito nell'uomo da sempre, e lo dimostrano le tantissime "religioni" che ci sono... insomma, qual'è il motivo per cui siamo a questo mondo?

Non voglio fare un discorso filosofico o teologico, anche se ho letto e riflettuto tanto su questo argomento, e credo che ognuno di noi si è posto questa domanda più di qualche volta nella vita.

Il Natale è uno di quei momenti dell'anno in cui si provano sensazioni forti... soprattutto legate all'amore (non in senso restrittivo di solo amore di coppia). Si sta bene perché si ama e si è ricambiati, o si sta male perché magari non abbiamo l'amore che vorremmo. E' normale ed umano essere un po' più "sensibili" quando sentiamo che ci manca qualcosa o che semplicemente qualcosa intorno a noi non è come vorremmo.

Non si tratta di pazzia... tutt'altro... si tratta proprio dell'essenza dell'essere umano e ciò che (nel bene e nel male) lo distingue (fino a prova contraria) dalla maggior parte degli altri esseri viventi.

Credo sia normale (in questi giorni di festa) ricordare anche persone che per qualche ragione non sono accanto a noi... per scelta di vita o semplicemente perché non sono più fisicamente in questo mondo. Chi di noi non ha almeno qualcuno che vorrebbe riabbracciare in questo periodo in cui fin da bambini ci hanno convinto che "Babbo Natale" può tutto?

Io sono ottimista per natura, lo sono sempre stato, e spero di continuare ad esserlo... mi piace sognare e spero sempre di riuscire a distinguere i sogni dalle illusioni, trovando anche il coraggio di accettare la realtà quando serve. Il Natale per me è da sempre il momento di riflessione più intenso dell'anno, faccio un po' di bilanci di quello che mi è successo, faccio un po' di "sogni" per il mio futuro... non sempre sono felice a Natale, ma ricordo molti Natali in cui lo sono stato... in particolare uno di molti anni fa in cui "decisi" di innamorarmi.

Al di là del significato religioso, per me Natale è importante perché vivo da tanti anni lontano da quella che chiamo "casa" nel vero senso della parola, dove c'è sempre qualcuno che ti aspetta o dove c'è sempre qualcuno che ti abbraccia anche dopo che l'hai trattato male perché sei "nervoso" o "stressato"... e a Natale posso stare un po' di più in quella "casa"... fisicamente intendo, perché sentimentalmente non me ne sono mai allontanato.

Il mio augurio per il Natale di quest'anno e per l'anno nuovo che deve venire è che ognuno di noi trovi equilibrio e coraggio. Soprattutto il giusto equilibrio tra il coraggio di sognare ed il coraggio di accettare la realtà.

Buon Natale

Stamattina stavo pensando a dei problemi sul lavoro e mi è venuta in mente questa frase...



Non so se siete d'accordo, ma volevo condividerla...