martedì 12 giugno 2007

Letteratura Fiabesca Applicata all'Informatica



Suppongo siate in pochi ad essere a conoscenza del fatto che le fiabe e, più in generale, i racconti del folclore, sono classificabili secondo un sistema analitico, definito da Aarne e Thompson, che si sono presi la briga di leggersi migliaia di fiabe e di appiccicargli etichette tipo: AT 425A “Il mostro o animale come sposo”, o AT 0151 "Lezioni di musica da animali selvaggi".

Sarà anche probabile che non possa fregarvene di meno di questa notizia e che stiate già per cambiare blog, borbottando che cercherete di fare del vostro meglio per dimenticarvi queste inutili nozioni, come Sherlock Holmes quando Watson gli fece notare che la terra gira attorno al sole ("Uno studio in rosso").

Se decideste davvero di farlo sarebbe solo l'n-esima triste conferma che la scuola non prepara più come una volta, che stiamo perdendo l'interdisciplinarietà e potenziali Leonardo e Galileo, appiattiti in una bruttura informatico-virtuale, per la quale non dovrete stupirvi se incontrerete a breve qualcuno che, usando espressioni care al Manzoni, potrà giustamente apostrofarvi con nel mezzo, vile meccanico.
(se siete riusciti a sopravvivere alle contorsioni e forzature della frase precedente - n-esima triste conferma del fatto che la scuola non sa più insegnare a scrivere in italiano -, forse avrete anche speranze di salvarvi culturalmente, ma dovreste certamente preoccuparvi per potenziali problemi mentali latenti).

Quelli tra voi più illuminati ed abituati a ragionamenti elastici, invece, non si saranno certo fatti sfuggire l'evidente parallelismo tra questo tipo di tipizzazione e quella presente nei linguaggi di programmazione (converrete senza dubbio, invece, che sarebbe un po' forzato trovare somiglianze con i Design Pattern, per i quali potremmo, invece, spingerci a considerare lo Schema di Propp).

Sarà inoltre evidente a tutti che gli spunti provenienti da un umanesimo di alto livello adatti ad introdurre il mio contributo nell'arena della tipizzazione forte o debole nell'informatica avrebbero potuto essere molteplici (dal 'sono un tipo, anzi un topo' di Geronimo Stilton, ad approfondimenti su grammatiche e licenze poetiche, etc. etc.), ad ulteriore dimostrazione che non si tratta di un argomento ormai consunto, ma di parte integrante delle esigenze culturali fondamentali dell'uomo e, pertanto, degno di essere ancora una volta approfondito...

(per il mio e vostro bene, qualcuno mi tolga dalla testa lo scrittore barocco che sta suggerendo queste ultime righe, prima di continuare la lettura)



Prima di iniziare la tesi di laurea, pur conoscendo (ovviamente! spero non vi abbia neppure sfiorato il dubbio!) la differenza tra tipizzazione forte e debole (strong and weak o static and dynamic typing), avevo sempre affrontato il problema procedendo per istinto.

Esattamente al contrario del mio tutor, che usava il Common Lisp ricercando strutture e controlli sui tipi di dati come se stesse usando il C, io tendevo a programmare in modo volontariamente non tipizzato.

Quando due uomini forti si scontrano su argomenti così decisivi per il bene della comunità è quasi inevitabile che nasca una discussione (animata, ma divertente): io difendevo la flessibilità che un simile approccio poteva fornire (soprattutto in lisp e, caspita, se non si cerca il massimo della flessibilità proprio nell'AI...) e lui difendeva la correttezza formale ed il controllo a compile-time, necessario, in particolar modo, in caso di sistemi particolarmente complessi (e ulteriormente utile, nel caso si debba lavorare con risorse alle prime armi o quasi, per ridurre significativamente le probabilità di errori).

Ancora oggi, di fatto, mi piace ridurre al minimo i vincoli, soprattutto se posso fidarmi degli sviluppatori del team.
Mi piacciono e ritengo fondamentali i Generics, ma se programmo per mio divertimento (sia per attività AI-related che non), tendo a saltarli apposta e mi gioco con reflection, metadati, valutazione dinamica di espressioni e, in genere, di codice (e perchè no, generato automaticamente) ed ignoro i warning di non tipizzazione delle collection che rischiano di ridurre la flessibilità del mio sistema (ovviamente, il cast automatico delle classi è due volte essenziale).

Cerco la genericità anche a livello di database, nei pochi spazi concessi (se c'è un sistema giustamente tipizzato quello è il DB, converrete). Che so: quanto è meglio poter dire varchar2, al posto che varchar2(20)? oppure, e questo viene condiviso praticamente da tutti, quanto è bella la sintassi che permette di definire, in PL/SQL, una variabile come di tipo tabella.campo%TYPE? E, nonostante il rischio di ridotte performance (ma dipende dai casi) e la complessità nel costruire query dinamiche che siano anche solide, non posso evitare di essere attratto anche da questa ulteriore non tipizzazione.

Senza esagerare, chiaramente: non proponetemi campi di testo o LOB per contenere informazioni aggiuntive, neppure se state pensando di strutturarle in XML (anzi, peggio, se sono strutturate in XML - ma ne parlo un'altra volta, perchè i motivi non c'entrano con questo argomento).

Non sono un estremista, in questo senso: semplicemente ritengo, come in altri casi, che sia essenziale conoscere i pro e i contro di ogni approccio e che, evidentemente, le regole informatiche sono fatte per essere infrante, anche se solo quando si sa esattamente cosa si sta facendo, comprendendone appieno gli effetti collaterali.

Dobbiamo tener presente che siamo comunque costretti a trattare con la tipizzazione dinamica, anche perchè ne siamo circondati. Per esempio:
  • http: tutto è stringa (siamo noi che le riportiamo a tipi, una volta che estrapoliamo dalla request, cercando un mapping e binding più o meno esplicito, ma il protocollo non prevede altro)
  • Javascript: le dichiarazioni di tipo non esistono e possiamo cambiare allegramente il tipo dati (e nessuno dice che sia corretto o consigliabile o facilmente debuggabile - anzi, già che ci siamo: vi anticipo che ritengo che, laddove si usi Javascript lato client, sia veramente pericoloso ed inutile, per la povertà dell'ambiente di esecuzione, utilizzare coscientemente questa possibilità)
  • polimorfismo: nasce per migliorare il riutilizzo di codice: è una sorta di via di mezzo tra tipizzazione forte e debole, no? (tipizzate pure fortemente, tanto io vi referenzio ad un livello più astratto, meno caratterizzato, anche se proprio nelle vostre particolarità...). In realtà tende così tanto alla tipizzazione dinamica che non pochi linguaggi di ampio uso permettono quello che viene chiamato Duck Typing. Che ha un po' a che fare con l'induzione (ricado sempre nell'AI, non c'è verso...). Vi consiglio di approfondire in particolare l'estratto del precedente link riguardante il duck typing in Java e, in particolare, l'articolo di David Orme (il papà di Visual Editor Project di Eclipse) che riporta il pattern e i suoi dettagli implementativi
  • etc. etc.
Spingendo all'estremo l'interpretazione del concetto in esame fino alle generiche strutture dati, saltano agli occhi anche le seguenti alternative (da considerarsi come esempi non esaustivi):
  • ResultSet vs. Bean ORM: i ResultSet con i loro metadati sono una sorta di interfaccia non tipizzata (che, curiosamente, wrappa dati fortemente tipizzati), con ottimizzazioni basate sulla presenza di metadati, in contrapposizione ad un classico (da Hibernate, per intenderci) mapping tra tabelle e Java Bean
  • Bean vs. HashMap: si tratta di una alternativa simile alla precedente, che si può porre laddove preferiate non ricompilare, ma, piuttosto, gestire una configurazione, perdendo in controlli compile-time
Proviamo a ricordare, prendendo spunto dalla solita Wikipedia, le funzionalità principali che sono sostenute dalla tipizzazione forte:
  • sicurezza: il compilatore può già identificare codice errato, riducendo i costi di debugging. Posizioni estremiste arrivano a dire che una tipizzazione molto forte potrebbe evitare la gran parte degli errori del codice, nonostante l'esperienza insegni che, pur essendo indubbio il vantaggio fornito in questo senso, solitamente i bug più insidiosi non potranno mai essere individuati dal compilatore (anche perchè, nella maggioranza dei casi si tratterà di interpretazioni di business)
  • ottimizzazione: un controllo di tipo statico fornisce al compilatore informazioni fondamentali per creare codice più efficiente. Il vantaggio viene in parte compensato dal fatto che, mentre è innegabile che la generalizzazione implichi solitamente esecuzioni più complesse (quindi più lente - es.: reflection), è anche vero che richiede minori controlli per verificare che i tipi siano o meno rispettati. Inoltre, tipicamente, la tipizzazione debole richiede meno righe di codice sorgente, meno codice da rivisitare, cicli di edit-compile-test-debug ridotti.
  • documentazione: i tipi sicuramente aiutano ad indicare chiaramente le intenzioni del programmatore, migliorando complessivamente il passaggio di informazioni
  • astrazione e/o modularità: tipi complessi permettono ai programmatori di progettare ad un livello più elevato (es: stringhe e non array di bytes), semplificando la definizione delle interfacce tra componenti e sistemi. Migliorare la definizione delle interfacce è, ovviamente, particolarmente utile (meglio: fondamentale, inevitabile, basilare, essenziale, ...) nell'ambito della progettazione ad oggetti e nel caso di integrazioni con sistemi gestiti da altri team (con contratti chiari e fortemente tipizzati è più facile definire precisamente le responsabilità e ridurre i tempi complessivi, aumentando l'interoperabilità e riducendo le inconsistenze tra i sistemi).
Sempre la stessa voce della Wikipedia ricorda anche, però, che la tipizzazione dinamica si trova spesso nei linguaggi di scripting e nei linguaggi per il RAD (Rapid Application Development)

Per quanto riguarda i linguaggi di scripting, rimanderei alla conversazione tra Bill Venners e Guido van Rossum (il creatore d Python), veramente interessante sia da un punto di vista di progettazione software che da un punto di vista di gestione tecnica di progetto, un must sull'argomento, anche se, come me, non userete mai Python in vita vostra (a meno che non vi paghino bene, intendo...) e non sarete completamente d'accordo con Van Rossum: casomai non lo aveste già capito, personalmente sono per lo strong typing (soprattutto per progetti grossi, team giovani e laddove ci siano molte integrazioni), ma con tante scappatoie per poter lavorare in modo veloce e flessibile, tipiche di un weak o duck typing - leggermente più dinamico rispetto alla posizione espressa da alcuni esponenti di Microsoft, ma non troppo.

Per quanto concerne il RAD: qualcuno potrebbe sostenere che dire 'se volete programmare velocemente, usate dynamic typing' sia una visione errata dello sviluppo veloce, perchè si basa su una ipotesi di partenza che non considera la manutenzione, ma, sostanzialmente, si ferma alla prototipazione e/o primissimi rilasci, senza considerare che, quando cresce la complessità del sistema, è molto facile che si creino errori.
Questa considerazione è vera solo fino al punto in cui si presuppone che chi sta usando il sistema non si accorga del pericolo e non sappia cosa sta facendo. Cosa che può capitare, come già anticipato, se il progetto è grande e composto da molte risorse junior.
Certo che, se si riesce ad impostare un ragionevole modo di lavorare e un controllo appena decente, si possono ottenere tutti i vantaggi della R di RAD e ridurre a quasi nulla i possibili svantaggi.
Non è vero che i costi di controllo sono il prezzo da pagare: quelli fatti bene, con caratteristiche simili a quelli che servono in questo caso, dovrebbero esistere comunque (altrimenti i problemi non tarderanno a farsi vedere, con o senza strong typing).

Ovvero, per dirla con Bruce Eckel (che da anni, oramai, cerca di farci diventare poliglotti informatici), non abbiamo bisogno tanto di una forte tipizzazione, quanto di forti test.
Sorvolando sul fatto che, evidentemente, in Italia la parola test non è facile da tradurre e che, quindi, la frase precedente potrebbe non essere capita da tutti... ;)

La stessa dicotomia non può che porsi anche ad un livello architetturale più alto, come ben evidenziato dalla diatriba tra SOA e REST. Riporterò solo un interessante pezzo tradotto a braccio da un famoso articolo di Steve Vinoski:
Ironicamente, il fatto che SOA prescriva specifici contratti per le interfacce, di fatto insidia il suo obiettivo di separare l'interfaccia dall'implementazione, perchè interfacce specifiche tendono a rivelare più della sottostante implementazione di quanto facciano le interfacce generiche. Inoltre, interfacce specifiche - per definizione - vincolano la loro implementazione perchè modificarle spesso richiede dei cambiamenti nell'interfaccia. [...]
Stranamente, alcuni degli architetti e sviluppatori che conosco che lavorano su grandi sistemi SOA (come quelli di aziende nel campo delle telecomunicazioni e della finanza) si sono inventati per conto proprio i vincoli dell'interfaccia uniforme, senza aver mai sentito parlare del REST. Sfortunatamente l'hanno fatto nel modo più complesso, sviluppando e consegnando dapprima interfacce specifiche per un servizio e poi notando cosa si rompeva quando i loro sistemi crescevano in scala.
Direi che, per ora, mi sembra sufficiente, per farci meditare ancora sull'infinita saggezza popolare nascosta da secoli nella fiaba (della tipizzazione) del (brutto) anatroccolo...

Bye
    Depa

[... continua ...] Leggi tutto

mercoledì 6 giugno 2007

Condivisione e Collaborazione



I commenti relativi alla mancanza di rete durante i viaggi che ho letto (almeno io) su questo blog mi hanno fatto pensare.

Forse ha ragione chi sostiene che stiamo andando verso una società Web centrica, in cui l'accesso ad Internet sarà importante come l'energia elettrica?

A parte il fatto che, tolta l'energia elettrica, salta anche l'accesso ad Internet, mentre non vale (ancora) il viceversa, a parte il fatto che chi legge questo blog si sta preparando anche alla mancanza di corrente, effettivamente il fatto di non poter usufruire di Internet ovunque si fa già sentire (problemi da fighetti, peraltro, se ci scappa il pensiero, tra un click e l'altro, che non si può usufruire ovunque di cibo e pace).

Certamente è corretta la nota di James Fallows che ci ricorda come ancora non si viva online e che, quando manca la connessione, smettiamo di essere Homo Conexus e, per tutti gli scopi pratici, il Web 2.0 diventa Web 0.0.

Possiamo metterci una patch?
Ma soprattutto, ci serve davvero virtualizzare le nostre applicazioni sul Web?
Perchè?

Sempre a far domande, quando basta selezionare 'Leggi tutto'...



Da due giorni sto usando il blocco note di Google.
E' un simpatico oggetto che esiste su Web, ma rende meglio se viene anche installato sul PC come estensione di IE o Firefox.
Permette di prendere appunti mentre si naviga: basta selezionare il testo che interessa, tasto destro del mouse, invia al blocco note di Google.
Il testo selezionato e relativa url della pagina compaiono in una finestrella in popup. Possiamo aggiungere inostri commenti e catalogare il tutto.
Con vari livelli di sicurezza e/o condivisione con il resto del sistema solare ed altre galassie, che possiamo controllare da preferenze.

Ovviamente non è l'unico strumento del genere (questo post ne riporta altri - tra cui Zoho notebook che sembra dare un paglione a tutti, in quanto a feature e che cercherò di valutare nei prossimi giorni).
La scelta tra tutti, però, potrebbe anche essere guidata dal fatto che forse avete già la Google toolbar, forse avete già qualche account in GMail, etc. etc.

Ora, tutti quegli appunti mi servirebbero anche off-line (per esempio, per aiutarmi a scrivere un post come questo).
Mi servirebbe anche poterne scrivere altri in treno, dove non ho la connessione (potete scriverne anche a manina, non siete obbligati a ritagliarli dal Web).
Il primo problema sarebbe anche apparentemente banale da risolvere: basta andare sul block notes e salvare la pagina in locale. E se le pagine iniziano a salire in numero e dimensione? E se voleste farci su una ricerchina?
Off-line ho spesso anche bisogno del mio blog o di quello di altri, da consultare: per gestire diverse pagine di informazioni, con ragionevoli dimensioni e pur mantenendo la possibilità di fare una ricerca, ci pensa già il mio feed reader (oramai IE 7, per semplificare la selva di programmi che popolano il mio PC) a gestire tutte queste caratteristiche.
Ma se non posso tradurre la mia applicazione in feed?
E resta sempre aperto il problema di inserire e modificare off-line.

Beh, Google, come per tutti gli altri suoi prodotti, fornisce delle API (Java e non solo) per interagire programmaticamente con il blocco note (tra i suoi concorrenti, solo il su citato Zoho mantiene una marcatura stretta, fornendo non solo una suite alternativa per l'office, ma anche API per molti prodotti - non ancora per il suo blocco note, però...).

Questa è una possibile strada per patchare il problema del Web0.0: se non fossimo pigri (come al solito aspetteremo che lo faccia qualcun altro, così poi lo downloadiamo), potremmo farci il nostro client per lavorare off-line, sincronizzarci periodicamente, etc. etc.

Un po' come è già in grado di fare Calgoo con Google Calendar: mantenete scrupolosamente i vostri impegni su Google, ma avete un appuntamento nel deserto o in Siberia? Dovete ripassare gli impegni in treno? Avete dimenticato il cellulare (!!!! questo davvero non può più capitare, la prossima volta lascerete a casa la testa? cosa le fanno a fare tutte quelle pubblicità, se poi non vi ricordate neppure di spendere?) o comunque rischiate di non ricevere l'SMS che aspettate?
Sincronizzatevi.

E c'è qualcosa anche per Blogger? Giusto per rispondere a quelli che continuano a parlare di Wordpress e Splinder...
Ci sarà anche, ma io ho trovato solo le API, le solite API, che certamente già conoscete (fatemi sapere, se trovate dei tool decenti per amministrarlo da scollegati).

E, per continuare con gli esempi: YouTube? C'è modo di vedere i filmati offline? Ci sarebbe Democracy Player, ma siccome già sapete cosa ne penso, vi suggerisco di leggervi questo post. Se non vi fidate di siti intermedi, ci sono anche procedure manuali e script...

Vorrei scaricarmi anche la Wikipedia, ma c'è qualche giga di XML da importare... magari conviene aspettare la prossima release del Web, al posto che applicare la patch, in questo caso...

E comunque non avremo ancora bisogno di queste pezze per molto, no? Voglio dire: quanto ancora mancherà al poter usare ovunque Internet? Anche in metrò, intendo.
Ad essere onesti, per una fruibilità completa in metrò servirebbe anche qualcosa in più della connessione Web: es. PC grossi come un lettore di MP3 (o, comunque, indossabili), meglio se con Virtual Retinal Display o altri simili wearable display e riconoscimento vocale al posto della tastiera, perchè sulla verde non si riesce ad aprire un notebook, senza rischiare di farselo rompere alla prima frenata in ore di punta. Ma questo è un altro discorso...

Eppure, non sono così sicuro di voler lasciare anche le mie informazioni private su Google: mi va bene dipendere dal Web, inteso come insieme di siti e servizi, ma (se e) quando il servizio diventerà a pagamento, mi piacerebbe poter scegliere di far tornare l'informazione sul mio PC.

Anche perchè faccio fatica a capire perchè un foglio elettronico dovrebbe stare su Web, se non deve essere condiviso ed elaborato in collaborazione. Certo, possiamo pensare ai vantaggi della virtualizzazione, ad una architettura a stella in cui il Web è il centro, raggiungibile da tutti i nostri PC e palmari.

Personalmente credo poco a questa esigenza, che mi sembra più legata a difficoltà di sincronizzazione, che alla reale necessità di centralizzazione.
Senza aggiungere le considerazioni architetturali:

  • single point of failure nel centro della stella: siccome non stiamo parlando dell'intero Web (che nasce proprio, fin dai tempi di ARPANET per sopperire a simili problemi, distribuendo l'informazione e ridondandola, per evitare che un attacco nucleare potesse fermare le attività), ma di una applicazione specifica, non è inusuale che il servizio non sia garantito

  • per raggiungere il centro della stella serve il collegamento: se questo non è disponibile, non accediamo a nessuna delle nostre risorse


Questi motivi si aggiungono ai precedenti per suggerire backup e sincronizzazioni periodiche (non vi sto dicendo di non virtualizzarvi, sto dicendo di prestare attenzione e non fidarvi troppo).
Senza considerare che oggi potete ben spostare facilmente il vostro backup su una chiavetta, che basta inserire nel PC su cui andrete a lavorare.
Inoltre ci sarebbe da chiedersi perchè si usano tanti PC. Essenzialmente si tratta di limiti di risorse (alternativamente di distinzione tra lavoro e casa, ma è quasi lo stesso problema, scavando bene). Non è che, all'aumentare delle risorse, tornerà a scomparire l'esigenza di avere certe applicazioni online?

Certo, ha più senso se la vediamo dal punto di vista dell'erogatore, che può usare il servizio pubblico come pubblicità per i tool facilmente utilizzabili anche all'interno di Intranet (quindi rivendibili alle aziende), dove la collaborazione e la condivisione dei documenti è, semmai, un problema in quanto difficile da realizzare. E i vari office online coprono bene questa esigenza (oltre a quella di una riduzione dei costi dei vari pacchetti e loro installazioni).

Forse conviene, per avere un quadro complessivo, tornare ai fondamentali e richiedersi, per l'n-esima volta (perchè non impariamo mai), cosa porta in più la tecnologia Web, rispetto a quelle precedenti:

  • Unica installazione centralizzata e facilità di manutenzione (e riduzione complessiva dei costi, sia di manutenzione che di licenza): a parte il fatto che i tool di cui stiamo parlando (es: blocchi note vari) rendono meglio con una installazione sul browser (quindi, lato client, perdendo parte del vantaggio), dobbiamo notare che, nella maggioranza delle applicazioni professionali, anche in un paradigma client-server i client verifica(vano) l'esistenza di upgrade centralizzati e si re-installa(va)no (le parentesi sui tempi dei verbi sono, ovviamente, dovute al fatto che Internet non ha eliminato queste esigenze: molti programmi ancora oggi si comportano in questo modo, aggiornandosi da soli).

  • Interfaccia utente (GUI) standard e intuitiva: siccome siamo grandi, abbiamo già capito da alcuni anni che 'zero training' era solo l'n-esimo slogan marketing e che questo vantaggio, in gran parte legato alla specifica progettazione/realizzazione, non era impossibile da ottenere con altre tecnologie; inutile negare, poi, che in gran parte, deve il suo reale successo ad una pratica mancanza di alternative (Flex, Java FX e altre simili proposte RIA (Rich Internet Application), porteranno effettivi vantaggi? Meglio cambiare, no? ...no...? meglio, almeno, poter scegliere? se ne sta parlando molto, l'approfondiremo una delle prossime volte....

  • Trasferimento lungo reti con banda limitata e connessione non garantita: vantaggio indubbio dell'http, con effetti che ancora oggi si fa fatica a spiegare ad alcuni clienti e che si cerca di bypassare con AJAX e simili approcci (ma, se è vero che possiamo dare una maggiore interazione, l'effetto è sempre quello di non trasferire tutti i dati tutti assieme, ma di paginarli - eventualmente nascondendo tale paginazione all'utente - e di aumentare il numero delle richieste al server - con relativo aumento di carico e necessità di hardware centrali relativamente potenti -, per fare le stesse cose)

  • Condivisione e collaborazione: e questa la commento dopo, visto che sono anni che la ripeto e che ritengo che sia il reale plus aggiunto dalla rete, quello che basterebbe da solo a renderla vincente


Nella condivisione e collaborazione possiamo far entrare, giusto per esemplificare, non solo i social network, ma l'intero concetto di Intranet ed Extranet, la stessa virtualizzazione del proprio posto di lavoro (condividi con te stesso, ma sempre condividi), la possibilità di collaborazioni distribuite di elaborazione (Web Services, architetture SOA, Web 2.0, relativi mashup e compagnia bella) e anche tool oramai parte della vita di tutti i giorni, quali i motori di ricerca e la loro capacità di integrare le diverse fonti.

Tutti i progetti di successo su tecnologia Web-like degli ultimi anni si basano su questi concetti e tutte le volte che si è usata una simile tecnologia per realizzare una applicazione gestionale classica, senza puntare verso questi obiettivi aggiuntivi, si è solo riscontrato quanto fosse più facile e meno costoso usare PowerBuilder ed il vecchio VB. E pensare che, come dicevo sopra, la mancanza di collaborazione e condivisione di Know-how, almeno per la mia personale esperienza, è forse uno dei problemi principali di ogni azienda (con ripercussioni in costi più o meno evidenti in ogni fase del processo produttivo, nella retention del personale e al momento dell'ingresso di nuove risorse).

Tornando alle nostre applicazioni virtualizzate, provando ad analizzarle secondo i vantaggi sopra elencati, talvolta mi viene da pensare: se penso ad un Calendar online non mi convince la sola fruibilità da più PC, perchè basterebbe EssentialPim o Calgoo su una chiavetta. Anche la condivisione del calendario con altri utenti l'aveva già Outlook (o Lotus Notes) una decina di anni fa.

La differenza è nella mancanza (per il momento) del costo di licenza e nel fatto che il server è fruibile su Internet, portando a vantaggi quando si debba collaborare e condividere informazioni a grande distanza (che so, io viaggio e la mia segretaria aggiorna i miei impegni, poi quando arrivo vedo il Calendar aggiornato, ma lo consulto anche in aereo, nel frattempo, se l'ho sincronizzato in locale, mentre il resto del mio team sa che oggi non sarà in ufficio - ora non mi resta che trovare una segretaria...). Distanze grosse (ovvero, reti non affidabili e con poca banda) non possono essere coperte da Outlook o Notes, ma le basi logiche si trovano già in quei prodotti.

I veri vantaggi, però, li si vedono ancora quando i servizi permettono un completo sharing:
- i motori di ricerca mi mettono in relazione con il resto del mondo (e le traduzioni integrate, che certamente devono migliorare, mi permettono anche, tra una risata e l'altra, di comprendere il senso di siti in russo, che, altrimenti, mi sarebbe totalmente oscuro)
- i social network permettono di condividere risorse (testi, presentazioni, video, link, contatti, competenze, etc. etc.), conoscenze ed opinioni, in modo molto diverso dagli altri media
- le aziende possono ricevere immediati feedback impliciti ed espliciti dai loro clienti finali, dai loro collaboratori e dai loro partner, condividendo know-how e riducendo i costi di produzione, migliorando l'efficienza delle comunicazioni interne
- repository centralizzati permettono di far evolvere insieme (e trovare) prodotti ed iniziative (es: Wikipedia) così interessanti da diventare indispensabili
- etc. etc.

La condivisione e la collaborazione con gli altri (non la virtualizzazione di noi stessi) è la vera differenza.

Bye
    Depa

[... continua ...] Leggi tutto