Sante parole quelle trovate in questo articolo:

Dear Microsoft, Please Use WebKit

Citazione:

I'm tired. I'm tired of looking at one browser and seeing a result only to find that another browser decided to see things differently. I'm tired of reading CSS3 and HTML5 articles that show me hot new things only to tell me that they will work in some browsers and not others. I'm tired because it's 2010 and we are still dealing with the same issues that we thought we were solving with CSS back in 2002.

Traduzione:

Citazione:

Sono stanco. Sono stanco di guardare un sito in un browser per poi scoprire che in un altro browser lo stesso sito si vede diversamente. Sono stanco di leggere articoli su CSS 3 e HTML 5 che mostrano nuove funzionalità molto belle che in realtà funzionano solo in alcuni browser ma non in altri. Sono stanco, perché è il 2010 e stiamo ancora parlando dei soliti problemi che pensavamo fossero stati risolti con l'introduzione dei CSS nel 2002.

Non credo ci sia molto da aggiungere.

Davvero HTML 5 e CSS 3 promettono funzionalità molto avanzate... ma fin quando i browser non seguiranno alla lettera gli standards, la vita degli stilisti del web continuerà ad essere molto dura.

E soprattutto, invece di investire tempo in creatività, si investirà tempo su come rendere il codice compatibile indipendentemente dal browser utilizzato...

Buona fortuna!

Ciao a tutti,
ho una bella domanda da porvi.

Ma prima... vlolevo parlarvi di Circle Of Concern e Circle of Influence... immagino già la vostra prima riflessione: perché questo qui ci parla in inglese?

La risposta è semplice: ci sono delle parole tecniche che non si riescono a tradurre facilmente, per cui a volte è importante usare un termine in lingua madre piuttosto che tradurlo con un termine inesatto o improprio.

Ecco comunque un tentativo di traduzione veloce:

• Circle Of Concern: cerchio delle preoccupazioni
  
• Circle Of Influence: cerchio di influenza

Proviamo comunque a dare un senso un po' più ampio a questi due termini:

• Circle Of Concern: abbiamo molte preoccupazioni... la nostra salute, i figli, problemi al lavoro, il debito pubblico, il terrorismo. Possiamo separare queste preoccupazioni da altre, che ci riguardano meno da vicino e che non implicano un nostro coinvolgimento emotivo o mentale, creando un nostro Circle Of Concern.
  
  
• Circle Of Influence: all'interno del nostro Circle Of Concern possiamo distinguere tra cose, su cui non abbiamo un reale controllo ed altre, che invece possiamo influenzare in qualche modo.

Riflettendo su quale dei due cerchi ci focalizziamo maggiormente, investendo tempo ed energia, possiamo capire molto rispetto il nostro grado di proattività.

A questo punto possiamo distinguere in:

• Focus Proattivo: chi è proattivo, concentra le sue energie e sforzi sul proprio "Circle Of Influence". Lavora su cose che può realmente influenzare, modificare. Possiede un’energia positiva che serve ad ingrandire le dimensioni del proprio "Circle Of Influence".
  
  
• Focus Reattivo: chi è reattivo focalizza i suoi sforzi sul proprio "Circle Of Concern", vale a dire su problemi e circostanze che non ha il potere di controllare. L’energia negativa che viene così generata e il trascurare aree in cui si potrebbe invece realmente intervenire, causa un rimpicciolimento del suo "Circle Of Influence".

Allego un'immagine per sintetizzare...




Un modo per determinare su quale cerchio siamo focalizzati è la distinzione nel linguaggio che usiamo tra se avessi e posso essere.

Il Circle Of Concern è pieno di se avessi:

• Se avessi un capo più comprensivo...
  
• Se avessi la laurea...
  
• Se solo avessi più tempo...

Ogni volta che siamo convinti che il problema sia "là fuori", diamo a ciò che è "fuori" il potere di controllare le nostre azioni, i nostri pensieri.

Il paradigma del cambiamento è "outside-in": ciò che è fuori deve cambiare prima che possiamo cambiare noi.

Il Circle Of Influence è pieno di posso essere:

• Posso essere più paziente
  
• Posso essere più cooperativo
  
• Posso essere pieno di risorse
  
• Posso essere più affettuoso

L'approccio proattivo è "inside-out": io posso cambiare, essere diverso, e essendo diverso posso generare cambiamenti positivi in ciò che è "là fuori".


_________________

E voi come vi sentite?

Proattivi o reattivi?



P.S.: mi pare evidente che il tema trattato non vuole essere una regola di vita... non ha nessuna pretesa se non quello di offrire qualche spunto di riflessione...

Recentemente (per lavoro) ho seguito un corso di formazione sulla gestione delle risorse umane (quanto suona brutto detto così...) ed alcuni spunti di riflessione li vorrei condividere con voi.

In particolare oggi vorrei parlarvi della perdita del carico informativo nella comunicazione, che secondo me in un forum ha ancora più rilevanza di quanto non l'abbia nella comunicazione verbale.

Ecco uno schema molto sintetico di come si può banalmente sintetizzare una comunicazione:

1. Ciò che vogliamo dire: 100%
   
2. Ciò che diciamo: 80%
   
3. Ciò che si vuole comprendere: 60%
   
4. Ciò che viene compreso: 50%
   
5. Ciò che si ricorda nel breve termine: 30%
   
6. Ciò che si ricorda nel lungo termine: 10%

Per metterla in maniera discorsiva... spesso abbiamo chiaro in mente qualcosa che vogliamo dire... già mentre la diciamo ci rendiamo conto che a parole si riesce ad esprimere l'80% del significato di quello che intendiamo... chi ci ascolta con molto impegno pensa di aver capito il 60%, ma in realtà comprende il 50% dell'informazione iniziale. Nel breve termine poi la percezione di quello che abbiamo capito ci lascia un solo 30%... e nel lungo termine, per ovvi motivi (la memoria umana non è illimitata, le percezioni cambiano...) ci resta solo un 10% di tutto il carico informativo iniziale, lasciandoci soltanto poche informazioni frammentarie di sintesi.

E' evidente che un flusso di questo tipo è molto semplificato e banalizzato, perché ci sono molti fattori che influenzano le percentuali... ad esempio la confidenza e la conoscenza che si ha con chi si comunica, il nostro stato d'animo, l'esperienza specifica legata all'informazione... insomma una marea di fattori influenzano la comunicazione e quante più "distorsioni" si introducono, tanto più le percentuali diminuiscono, alterando l'informazione iniziale.

La cosa secondo me poi più interessante è che in una comunicazione, soltanto le prime due fasi sono controllate direttamente da chi trasmette l'informazione, mentre tutte le restanti sono prerogativa di chi l'ascolta...

Concludo ribadendo che questo schema è volutamente semplificativo... ma a me ha fatto molto riflettere, perché soprattutto in un forum (dove spesso le persone non si conoscono "dal vivo") è molto facile essere fraintesi.

Esiste anche l'altro risvolto della medaglia... in alcuni casi particolari ci sono persone che riescono a comunicare meglio in forma scritta (si ha modo di riflettere meglio e di rileggere...), e persone (caso più raro) che recepiscono meglio leggendo piuttosto che ascoltando.

Voi che ne pensate?

Che esperienza avete?

Non seguo più il calcio dei campionati nazionali da oltre 10 anni... mi sono disaffezionato quando lo "spirito mercenario" ha iniziato a guidare sopra lo "spirito sportivo", l'attaccamento alla maglia, l'agonismo vero (quello sportivo, non quello violento). Però i grossi appuntamenti dello sport (olimpiadi soprattutto) e dl calcio mondiale (partite importanti di coppe internazionali, campionato europeo per nazioni, mondiali di calcio...) quelli non li ho mai mancati, perché a me piace respirare l'aria di evento sportivo multietnico e che coinvolge tutti ben al di là dei soli principi economici. A molti questo sembrerà il discorso banale come se ne fanno tanti, del tipo "non ci sono più le mezze stagioni" o "non ci sono più i giovani di una volta"... ma non è così, stavolta credo davvero che siano stati superati tutti i limiti (beh, non ancora tutti... ne teniamo qualcuno per i prossimi eventi sportivi...).

Già con le ultime olimpiadi e olimpiadi invernali avevo molta amarezza dentro a non poter vedere tutti gli sport minori o eventi secondari, perché la TV pubblica (quella non a pagamento di canone) non ha più interesse economico a mostrare questi eventi, anche perché ormai l'evento sportivo si vende con i famosi "diritti". La RAI, che è la televisione pubblica nazionale (un po' un controsenso chiamarla così visto che fa pagare un canone obbligatorio a tutti i possessori di un apparecchio in grado di riprodurre segnali audio o video...), ha ormai preso a tutti gli effetti la via dei soli interessi economici, dimenticandosi che vive anche grazie agli introiti pagati direttamente dai cittadini tramite il famoso canone.

Ieri ero contento che iniziassero i mondiali di calcio... non ho preso nessun impegno per il weekend, perché pensavo di potermi guardare tutte le partite in programma, avevo già pianificato le mie giornate dalle 13.30 (prima partita della giornata) alle 23.00 (orario indicativo di fine partite...) per poterle vedere tutte. Adoro lo spirito sportivo di questa manifestazione, vedere le nazioni unite (una volta tanto) da un'evento sportivo... vedere i tifosi di diverse squadre festeggiare insieme (invece di picchiarsi). Alle 20.30 ho avuto l'ennesima conferma di essere un cretino. Accendo la tv sulla RAI e vedo quello splendido programma dell'AZZECCA MESTIERI... tra me e me pensavo... beh, come sempre ci faranno vedere la partita già dopo il calcio di inizio... macché... poco dopo capisco di essere molto più stupido di quanto pensassi solo qualche istante prima. Cambio canale, giro tutta la RAI, tutti quei nuovi dannati canali digitali (io non guardo tv, per cui per me era tutta roba nuova, mai vista prima)... e niente... allora penso, "la faranno vedere sul web in streaming..." ILLUSO!!! Nel web me la cavo un po' meglio che con un telecomando in mano e dopo solo pochi minuti scopro che l'intero mondiale funziona esattamente come ogni dannato campionato di calcio: hanno venduto i diritti, per cui daranno in "chiaro" (se così si può definire visto che paghiamo un canone!) solo una partita al giorno!!!

La gioia per l'inizio dei mondiali di calcio (non vorrei dire una castroneria, ma credo che sia l'evento sportivo più seguito, anche più delle olimpiadi) è stata sopraffatta in pochi secondi da una rabbia atroce e da una delusione davvero enorme... solo chi ha SKY in Italia (o magari altri canali dello stesso tipo a pagamento) potrà seguire tutte le partite dei mondiali!!! Neanche lo streaming via web che mi aveva "salvato" durante le olimpiadi questa volta è efficace... addirittura una commissione Europea si è disturbata a bloccare lo streaming (a seconda del paese in cui viene fatta la richiesta, e di come sono stati venduti i diritti) via web per "costringere" a pagare la mazzetta a SKY.

Certo, io non metto in dubbio che SKY ha i suoi costi, ha i suoi contratti, ha i propri interessi economici... ma qui parliamo di sport... non veniamoci a lamentare se poi noi Italiani (ma non è un problema solo legato all'Italia) non abbiamo abbastanza spirito sportivo, o non riusciamo più a fare la differenza nello sport come diversi anni fa di tanto in tanto capitava (nonostante siamo una nazione molto piccola, abbiamo sempre avuto discrete soddisfazioni nel mondo sportivo).

Scusatemi per lo sfogo, ma sono davvero deluso ed amareggiato... lo sport ha perso ancora una volta.

Viva il progresso e la libertà.

Quante volte mi capita di sentirmi dire frasi che iniziano in questo modo: "Tu che ne capisci..." "Tu che con il PC ci lavori..." etc.

Beh ecco, ogni volta che sento queste parole (o simili) letteralmente rabbrividisco. Perché? Il perché è molto semplice... queste premesse non promettono (scusate la cacofonia...) nulla di buono.

Qualche giorno fa leggevo questo articolo:
Gli 8 più grandi favori richiesti ai web designers

Dopo qualche riga di lettura ho cominciato ad annuire come un cretino... perché molte volte mi sono ritrovato nelle situazioni descritte dall'autore.

Ormai la tecnologia è ovunque e se prima bastava saper usare un 286 per sentirsi all'avanguardia, oggi la tecnologia (e soprattutto il web) è permeata in molte delle attività giornaliere della società che ci circonda (certo parlo essenzialmente per le città più grandi dei paesi "sviluppati") ed anche se i software e le periferiche diventano sempre più semplici da usare (user friendly) c'è chi proprio non digerisce tutto ciò che si basa su circuiti.

Non me ne vogliano gli amici che leggeranno questo articolo (per fortuna pochi ), ma spesso mi sento in difficoltà quando mi capita di essere chiamato in causa con un banale "quale computer mi consigli?", o con "credo di avere un virus" o con un po' più complesso "vorrei fare un sito, mi aiuti?". Non vorrei essere frainteso, ma le persone avverse alla tecnologia spesso non riescono neanche a capire quanta complessità ci sia dietro una domanda che di primo acchito può sembrare banale.

Se ad esempio dare un consiglio per un PC può sembrare una cosa innocua... dietro si celano dei tranelli davvero pericolosi: una volta acquistato il PC ha bisogno di software, di configurazione... e questo implica del lavoro ben più complesso ed impegnativo del semplice consiglio. Configurare un PC per bene ed installare del software a dovere può richiedere ore... io stesso spesso sono riluttante ad aggiornare il mio PC per evitare tutta la trafila delle installazioni e personalizzazioni, figuriamoci quanta voglia ho di farlo per un'altra persona!

Certo, per amicizia sono sacrifici che si fanno... però quello che voglio dire è che le conoscenze informatiche spesso sono ritenute come cose senza un grande valore aggiunto se chieste a chi "le sa fare".

Una delle domande che temo di più in assoluto è quando un amico ti dice:

Citazione:

Il mio PC va lento, si blocca, temo di avere un virus...

Quando sento queste parole letteralmente mi manca l'aria ed avrei voglia di gridare a squarciagola. E' in quei momenti che capisco perché molti dipartimenti IT non aggiornano l'hardware ed il software della propria azienda. E' risaputo che il modo più veloce per "sistemare" un PC che abbia un virus o sia semplicemente "sovraccarico" è quello di reinstallare il sistema operativo. Ma avete idea di come è organizzato il PC di qualcuno che non ne ha dimestichezza? Io sì. Ed è un incubo, fidatevi.

Perché? Il perché è semplice: per reinstallare il sistema operativo è necessario archiviare prima i dati personali per poterli ripristinare (in modo da non far perdere nulla al malcapitato). Come fate ad essere sicuri di archiviare tutti i dati personali dell'utente se lui stesso non sa neanche di averne? Un utente poco pratico, non capisce il senso di re-installare il sistema operativo, non ne capisce le implicazioni: re-installare un OS (dall'inglese Operating System) significa radere al suolo ciò che c'è e ricominciare da zero. Per fare un esempio pratico, se doveste rifare una casa, tirereste prima fuori i mobili, i libri, i quadri... poi buttereste giù tutto, ricostruireste e riportereste dentro i vostri averi: con un PC è la stessa cosa. Se buttaste giù la casa con mobili ed averi dentro, perdereste tutto... stessa cosa con il PC! Puntualmente quando si re-installa il sistema operativo ad un amico (dopo avergli chiesto almeno 15 volte se non ha nulla che gli serva!) di ricevere questa domanda al primo riavvio: "Le foto delle ferie di quest'estate non ci sono più... e neanche il filmino del battesimo di mio figlio!". A quel punto tu che sei lì per fare un favore (e stai impiegando ore del tuo tempo libero) devi anche sentirti in colpa perché non hai pensato che l'utente potesse avere ad esempio il certificato di accesso per il conto corrente online o l'unica copia digitale esistente della tesi di laurea...

Beh ragazzi, non dovrei dirlo, ma ultimamente quando mi chiedono aiuto di questo tipo cerco sempre di glissare...

Altra cosa che mi terrorizza quasi (e forse più) della richiesta di re-installazione è la richiesta di aiuto per i siti web. Ormai in molti sanno che nel tempo libero mi diletto a creare e gestire siti internet... per cui quando qualche amico intende fare qualcosa nel campo web la prima cosa che fa è contattarmi. Per alcune persone fare un sito web è come scrivere un'email... che ci vuole! In pochi sanno invece che gestire un sito web richiede competenze polivalenti (e questo è forse l'aspetto che più mi affascina). Bisogna capire cosa sia un hosting, come registrare un dominio... sarebbe bene sapere almeno cosa siano php, mysql, css, html... è opportuno avere nozioni di base di grafica, arte, teoria dei colori... Insomma, ho citato solo alcuni aspetti, e se è vero che al giorno d'oggi ci sono servizi e pacchetti integrati che offrono funzionalità complete di gestione anche per i meno esperti, qualunque pagina web (anche se curata poco) richiede comunque ore di lavoro. Ci sono persone che chiedono decine di euro l'ora per questo servizio... Certo io non voglio mica essere pagati dagli amici che chiedono un consiglio, assolutamente no. Quello che voglio dire è che ciò che si pensa sia un cubo di ghiaccio, in realtà è un iceberg... e a malincuore a volte sono costretto ad essere molto conciso nelle spiegazioni (confesso a volte di aver finto perfino ignoranza...), per evitare poi di dovermi far carico dell'iceberg!


Un abbraccio a tutti gli amici che leggeranno questo articolo... vi voglio bene!

Oggi ho letto un articolo molto interessante su Internet Explorer 9: IE 9 Preview

Non vengono discussi molti dettagli del nuovo browser, più che altro è una discussione filosofica (più o meno neutrale) sulle politiche di sviluppo della Mircrosoft ed in particolare sull'attenzione rivolta al mondo web.

In particolare mi ha colpito una frase:

Citazione:

On the other hand, Microsoft’s refusal to switch to Webkit gives Apple and Google a competitive advantage, and that is good because a web in which one browser has a monopoly stifles standards and innovation alike. By torturing the IE rendering engine every couple of years instead of putting it out of its misery, Microsoft contributes to the withering away of its own monopoly. That might not be good for the shareholders, but it is great for everyone else.

Cerco di tradurla:

Citazione:

D'altro canto, il rifiuto di Microsoft ad usare tecnologie non proprietarie (come Webkit) per sviluppare il proprio browser offre ad Apple e Google un vantaggio competitivo: questo è un bene, perché in un web dove un browser ha il monopolio blocca l'innovazione e la creazione di nuovi standard. Invece "torturando" IE ogni paio di anni (ndr: introducendo patch piuttosto che riscrivere il motore di rendering), Microsoft contribuisce alla eliminazione del suo stesso monopolio. Certamente non è un bene per gli azionisti, ma è una grande cosa per tutti gli utenti del web.

Credo che questa frase sintetizzi davvero molto di quello che penso riguardo la politica della Microsoft nel settore Web. Internet Explorer è utilizzato quasi solo esclusivamente da chi non ha dimestichezza con il PC e probabilmente neanche sa che esistono dei browser alternativi (leggevo qualche tempo fa di un sondaggio fatto alla gente comune, in cui solo l'8% degli intervistati sapeva cosa fosse un browser!). Dai tempi di IE 6 il mondo si è evoluto, ma purtroppo a causa dei reparti IT troppo pigri ed inefficienti, nessuna società troppo burocratica aggiorna i propri sistemi operativi ed anche browsers. Dicono di non farlo per i rischi operativi legati agli aggiornamenti software... ma non tengono conto di tutti i rischi operativi di utilizzare sistemi operativi e browsers ormai datati e per certi versi insicuri. Non solo... qualunque programmatore WEB sa cosa comporta programmare un'interfaccia web per IE 6... e le aziende neanche immaginano quanto risparmierebbero se IE 6 non fosse così popolare, perché buona parte del costo di sviluppo di un sito web è legato alla compatibilità tra browser ed in particolare con IE 6.

Non mi dilungo oltre... spero vivamente che con IE 9 la Microsoft decida finalmente di adeguarsi ai nuovi standard del web, semantica W3C, proprietà CSS, immagini PNG, canali alpha di trasparenza... insomma, tutti i browser moderni supportano in maniera più o meno efficiente questi standard... perché Microsoft ancora non si decide a fare il passo?

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