Undolog.com

Snap fa parte di quegli straordinari servizi Web2.0 style che sempre più spesso vengono offerti in rete in modo totalmente gratuito. Il suo fuzionamento è semplicissimo, basta inserire il “solito” script Javascript sul vostro Web, Blog o qualsiasi altra cosa… e come d’inconato tutti i vostri link ora possiedono un simpatico preview in tempo reale.
Per provarlo l’ho inserito qui su undolog.com, provate a passare il mouse qui sopra. Fantastico!

Continua...

Domanda: possiamo considerare le applicazioni Ajax come vere e prorie RIA (Rich Internet Application – una RIA è un’applicazione web con tutte le caratteristiche e funzionalità di una tradizionale applicazione desktop per PC)?
Secondo Ryan Stewart, no – o almeno non ora.

The role of the desktop in Rich Internet Applications by ZDNet‘s Ryan Stewart — Rich Internet Applications have helped change the face of the web. It’s more interactive, designers have been able to leave their mark and innovation in web development has soared. Rich Internet Applications helped open up the web to better experiences and now they are doing the same for desktop applications. Where do RIAs fit into the world of desktop development?

In effetti la concorrenza con altri “approcci” – per così dire – è davvero elevata. La recente esplosione del fenomeno Net TV, ad esempio, dimostra che l’unione fa la forza. In “Ajax” non è possibile visualizzare un Video, tanto per dirne una. Come non è possibile realizzare tante altre cosine. Non credo che Ajax sarà il futuro assoluto. Io vedo in Ajax più che altro un’estensione del browser e un nuovo modo per affrontare alcune dinamiche relative all’UI prima neanche prese in considerazione.

Tuttavia, se qualcuno non se ne fosse accorto, esistono ancora degli ostacoli da superare. Ad esempio:

• Migliorare la compatibilità tra i vari browser in commercio, argomento largamento discusso su questo stesso Blog
• Permettere una maggiore interazione tra le pagine Web e il sistema operativo “ospitante”, ad esempio un Drag & Drop dal desktop alla pagina Web
• Standardizzazione degli scripting: JScript, Javascript (1.3, 1.7, …), VBScript
• Accessibilità, usabilità e sicurezza, vista che stiamo sulla rete!!

Librerie, Prototype/Script.aculo.us e YUI components: il vero intoppo?

Quando uno sviluppatore crea una libreria o un frame-work per risolvere (una volta per tutte) una serie di necessità, inizia a creare un mostro. Spesso non ce ne accorgiamo ma il legame sviluppatore end-user è davvero contorto. Si inizia, ad esempio, con la creazione di una libreria Javascript in grado di creare delle semplici finestre. Basta poco e qualcun’altro crea una libreria simile che permette di creare finestre modali, ridimensionabili e con la gestione dell’ordinamento e sovrapposizione. Dopo un po’ ne arriva un’altro che implementa anche la personalizzazione grafica… e così via.

In pratica quando si ottiene qualcosa, nell’istante immediatamente successivo questo qualcosa sembra non bastare più, sembra diventare lo standard e quindi si cercano nuovi accessori per migliorarne ancora di più le performance o l’aspetto. Tutte richieste dell’end-user! E lo sviluppatore corre, quasi come un cagnolino intimidito; l’end-user ha sempre ragione!

Questa continua corsa, in un universo come quello di Internet, rischia a lunga gettata di portare più confusione che altro.

Web 3.0?

Negli ultimi tempi esperienze (beta) nell’ambito del Web2.0 sono proliferate sulla rete a ritmi impressionanti. Ognuno ha portato all’attenzione la sua applicazione Ajax-style, ognuno con le sue soluzioni embedded, appoggiandosi a librerie note, scrivendo frame-work proprietari, ecc…
Ogni esperienza aveva le sue peculiarità: qualcuna era graficamente accattivante, alcune estremamente veloci, altre estrememente personalizzabili e altre estremamente usabili.
Ma nessuno, fino ad ora, è riuscito ad unire tutto questo in un unico ambiente.

Ragionandoci attentamente risulta evidente che il motivo è nello scarso supporto fornito dal browser stesso e dall’immensa complessità del problema.

Anche se qualcuno ha assimilato il browser ad un sistema operativo, quest’ultimo detiene ancora un’enorme vantaggio. Primo fra tutti è il cosidetto Kernel. Qual’è il Kernel di Explorer o di FireFox? Entrambi, come Opera o Safari, supportano a mala pena quel linguaggio di scripting chiamato Javascript (o JScript a secondo dei casi). Mozilla, nel suo FireFox sta per rilasciare la versione di Javascript 1.7, davvero interessante. Ma Microsoft Explorer che farà? Toccherà installare un ActiveX che lo emuli, attendere il 2012 per l’uscita di IE8 o utilizzare una miriade di if per capire su che piattaforma si sta lavorando?

Non posso che essere d’accordo con Ryan Stewart. Per il momento Ajax è un tecnica di notevole aiuto in ben determinati casi, ma paragonare questa tecnica (e sottolineo tecnica non tecnologia) ad una RIA mi sembra – almeno per ora – davvero eccesivo.

Macromedia/Adobe

Interessanti, invece, sono le tecnologie (e sottolineo tecnologie e non tecniche) Flex/Flash ed Apollo, che dopo l’acquisizione di Macromedia da parte di Adobe stanno per vivere una seconda giovinezza.
Consiglio vivamente a tutti gli interessati di visionare gli Adobe Labs, dove si evince una simpatica nuova politica che ispira sicuramente più fiducia nel futuro di Script.aculo.us – senza offesa e senza nulla togliere allo sviluppatore.

Tuttavia Internet ha una caratteristica unica, quella di sorprendere, quindi non mi stupirei affatto di aver detto – a breve – una miriade di sciocchezze!

Continua...

Geni! È proprio vero che la fantasia non ha limiti. Probabilmente Ajax ci porterà li dove nessun developer è mai giunto prima! Comunque bravi. Questo tool, free, è davvero simpatico. Permette di creare “al volo” il proprio albero genealogico, fatto salvo che abbiate tutti i dati. La registrazione è “nascosta” nel primo inserimento, ovvero voi stessi.

Si procede abbastanza spediti, tiene in cosiderazione praticamento tutto (divorsi, parenti in vita, sesso, …) ogni “persona” ha una vera e propria scheda personale, quasi da rubrica o agenda clienti. L’interfaccia princpale ha un risposta abbastanza rapida, cosa che non si può dire dell’interfaccia a schede per i singoli elementi aggiunti: ogni volta che si clicca su un TabStrip viene eseguita una richiesta Ajax davvero lenta.
A parte qualche “baghetto” quà e la, la lentezza cronica di alcune fasi, l’idea è simpatica. Da provare almeno una volta…

NOTE:
Fa uso di Prototype/Script.aculo.us e i componenti YUI (Yahoo). Forse è per questo che è molto lento.

Continua...

Come molti sviluppatori Web sanno, prima dell’avvento dell’oggetto XMLHttpRequest, il problema del ricaricamento di una pagina Web veniva risolto con la tecnica dei FRAME o IFRAME nascosti. Questo artifizio ha permesso per molti hanni di risolvere alcune problematiche di interfaccia altrimenti irrisolvibili. Un vantaggio nell’uso dei FRAME nascosti, tra l’altro, era la possibilità di mantenere l’HISTORY del browser! Cosa che l’oggetto XMLHttpRequest non permette.

Oltre a tecniche HTML che ricorrono a FRAME o IFRAME nascosti, esiste la possibilità di usare Flash come sub-canale di comunicazione tra la pagina e il Server. Alcune esperienze in tale direzione sono tuttora in sviluppo (vedi ad esempio Fjax). L’idea è quella di “nascondere” un filmato Flash all’interno della pagina HTML (come accadeva con i FRAME) e comunicare con esso tramite Javascript (o VBScript per il solo ambiente Microsoft).

Tuttavia questa tecnica nascoste una serie di insidie. Prima di tutto costringe l’utente finale ad installare il PlugIn di Flash, e quindi non rappresenta una soluzione HTML (pura) pulita. Inoltre richiede comunque l’uso spinto di Javascript come interfaccia tra Flash e la pagina, quindi tanto vale la pena usare l’oggetto XMLHttpRequest. Quando poi si inizia a scrivere un framework in ActionScript viene voglia di realizzare tutto in Flash. Ecco che la variante all’oggetto XMLHttpRequest comincia ad avere poco senso.
In definitiva se non si vuole usare l’oggetto XMLHttpRequest, conviene affidarsi all’ormai consolidata tecnica dei FRAME nascosti. Addirittura c’è chi usa proprio una tecnica mista: XMLHttpRequest + IFRAME!

Tuttavia, oramai, Ajax (nella forma dell’oggetto XMLHttpRequest) ha riscosso un così grande successo che in futuro l’oggetto XMLHttpRequest verrà sia supportato che migliorato dai produttori di browser (come Microsoft, Mozilla, Opera, ecc…). In pratica XMLHttpRequest diventerà un componente di default (come accade già in FireFox) all’interno del browser, raggiungibile via Javascript! Quindi perchè non usarlo?

Continua...

Su Ajaxan.com è comparso un articolo interessante su un’esperienza londinese davvero simpatica. Protopage è un piccolo sistema operativo dedicato allo condivisione. Il motore dell’ambiente è ben scritto e l’interfaccia risulta estremamente facile da usare. Questo è sicuramente un bell’esempio di come il Web sta evolvendo. Tuttavia rimangono ancora insidie di compatibilità, vedi ad esempio Explorer 7, ma la strada sembra densa di sorprese.

Continua...

Ajax, per qualcuno, è stata una rivoluzione. Per alcuni programmatori “navigati” è stato solo un modo diverso di fare quello che prima si realizzava sfruttando il TAG HTML IFRAME (o i FRAME stessi nascosti). Evidentemente hanno tutti ragione. Ajax è stata una rivoluzione perchè è capitato in un momento particolare, dove la diffusione della banda-larga e la maturità del Web (web 2.0?) hanno permesso un approccio completamente diverso rispetto al passato.

La proliferazione delle Web Applications da parte di grandi gruppi come Microsoft, Yahoo, Google ed altri, dimostra quanto si stia investendo in questo nuovo approccio. Il futuro – prossimo venturo – di Ajax è quindi luminoso, denso di novità e colpi di scena.

I browser e gli scripting server (come PHP) potranno dare ausilio a questo nuovo modo di vedere il Web e le sue risorse! Applick.com ne è una dimostrazione lampante!

Continua...

Dopo aver acquisito Macromedia, Adobe crea i suoi Labs, laboratori di sviluppo! Sulla scia del successo ottenuto da Microsoft con il suo Blog su Internet Explorer 7 – che gli ha (e ci ha) risparmiato un bel po di services pack – anche Adobe adotta la tecnica della beta version. In effetti, ed era ora, invece di attendere gli ormai lunghissimi tempi di sviluppo di un software (sia esso tradizione, sia una Web Application) perchè non proporre agli utente la versione ancora in sviluppo? In questo modo si ha un feedback in tempo reale sulle effettive qualità del software che si sta sviluppando.

Tuttavia, per onestà, le software haouse dovrebbero abbassare un po’ i prezzi dei loro software, visto che il beta testing – che si paga o si pagava – lo facciamo noi utenti!!

Con Adobe Soundbooth beta si va a sovrascrivere il noto SoundEdit. Adobe Photoshop Lightroom è un nuovo prodotto rivolto ai fotografi professionisti, con tanto di demo video online. Flash 9 con ActioneScript 3 compare anch’esso in versione alpha da scaricare! Nonostante sia indicato preview! Per il mobile troviamo Flash Lite 2.1 Authoring Update, che tuttavia sembra un rilascio definitivo più che un’anticipazione. A parte questa piccola miscellanea di beta, alfa e upgrade credo che l’iniziativa sia buona, se non ottima.
Insomma per i curiosi che vogliono anticipare i tempi e non vedono l’ora di assaporare una nuova versione di un software, Adobe Labs è un luogo di sicuro divertimento! Sottolineo nuovamente la tendenza a far partecipare gli utenti finali alle fasi di sviluppo, tendenza che deve la sua diffusione alla Web 2.0 generation. Molto probabilmente sarà una modalità che nel prossimo futuro si diffonderà a macchia d’olio ovunque è possibile. Si potrebbe provare un’appartamente o un’autombile prima che venga rilasciata, ad esempio…

Continua...

C’è un motivo molto importante per preferire l’inserimento dei contenuti via PHP – lato server – in una pagina Web rispetto all’uso di Javascript – lato client. Nello sviluppo degli strumenti di outing services del CMS getmePage utilizzato su applick.com era possibile sfruttare Ajax come engine di recupero HTTP dei dati server. Il problema, in questo caso, era che si aveva a che fare con i contenuti di un sito, contenuti che vengono indicizzati dai crawler di ricerca come googlebot! I crawler non eseguono Javascript, rendendo così vuota una pagina agli occhi di googlebot. Oggi sono i contenuti a fare la differenza nelle indicizzazioni nei motori di ricerca, quindi bisogna fare attenzione a come vengono generati i contenuti in una pagina. Quello che vede l’enduser non è quello che vede un tool come googlebot. Questo è uno dei motivi che hanno determinato la scelta di PHP nell’engine di recupero dati dell’applick getmePage. PHP, infatti, viene eseguito dal Web Server prima di inviare la pagina al client. Ne deriva, così, che quello che vede un crawler è quello che vede l’enduser.

Continua...

Come già affrontato su “Javascript vs PHP” (o altro: ASP, CFM, …), la questione di inserire o meno un kernel Web2.0 negli script Javascript, invece di lasciarlo – in maggiornaza – lato server, può creare confusione se non sconcerto. Tuttavia ci sono degli ottimi motivi per favorire il server rispetto al client, motivi che non hanno niente a che fare con il Web2.0 che, al contrario, punta i riflettori proprio sugli script Javascript.

Continua...

Corre voce che attualmente è in corso una discussione sull’uso di Javascript come costruttore di contenuti HTML. In particolare il dilemma assilla l’universo Ajax. Sotto questa sigla si cela un metodo che permette di contattare il Web Server tramite script Javascript, senza che il browser debba ricaricare l’intera pagina con il conseguente – e fastidioso – “fliker” video.

Il fatto che questa tecnica permetta di comunicare con il Web Server significa, in pratica, che si possono inviare – e ricevere – informazioni dal Web Server senza che l’utente – di fatto – se ne accorga! Su quest’ultima affermazioni sarebbe il caso di aprire una discussione a parte.

Tornando alla nostra questione la domanda principale è la seguente: una volta ricevuta la risposta dal Web Server chi deve costruire l’impalcatura HTML tale da poter inserire la risposta nella pagina corrente? Lo deve fare il Web Server al momento dell’invio della risposta o è un compito demandato a Javascript lato client ?

In pratica c’è chi sostiene che il modo migliore è quello di far impacchettare la risposta completa direttamente lato server; così che il client Javascript deve solo prendere ed inserire (get & insert). Altri, invece, sostengono che la cosa migliore sia ricevere i dati spuri, raw, in una struttura XML magari ed elaborare il tutto lato client, tramite Javascript, e sempre con Javascript creare l’impalcatura HTML necessaria per l’inserimento sulla pagina.

Sembra subito evidente, però, che non è possibile – a priori – sostenere un modello rispetto all’altro. Entrambi, evidentemente, devono essere contestualizzati. E’ possibile che in alcuni casi far impacchettare tutto al Web Server risulti effettivamente la scelta migliore, sia in fase di sviluppo che in velocità di trasmissione.

C’è da dire subito che l’idea di caricare grossi quantitativi di codice Javscript sul client non è una bellissima soluzione. Dico questo in ricordo della scalabilità. Un sistema che si presenta già pesante nelle sue fasi iniziali, ha ben poche possibilità di progredire in tranquillità in futuro. Inoltre le ancor diffuse incomptibilità tra i browser disponibili, quindi lato client, rendono stancante sviluppare codice Javascript troppo articolato. Tuttavia c’è chi lo fa! Indubbiamente.

La morale, ad oggi, con i browser e i sistemi operativi che abbiamo, sembra essere quella che ognuno deve scegliere la propria via, domani si vedrà. Nel nostro sito Web Applick.com, il codice è stato scritto utilizzando entrambi i metodi, a seconda del caso.

Domani, magari, usciranno dei browser con codice preconfezionato a bordo! Verrà sicuramente rivisto il componente HTTPRequest. Per ora questa tecnica deve la sua ri-nascita (vedi uso del TAG IFRAME) sia al minimo standard realizzato sul componente HTTPRequest, alla sua presenza e implementazione nei browser e sia all’aumento di banda-media disponibile ai navigatori Internet. L’HTTPRequest è comunque un subcanale HTTP, ne più ne meno. Inviare un codice XML invece che HTML non fa molta differenza, sniffando la rete ce ne rendiamo subito conto. Forse questi sono lamenti di qualche altra cosa che va al di là della questione Ajax. E’ innegabile che una certa parte della comunità Internet chiede un cambiamento, delle modifiche strutturali. Si è parlato – giustamente – delle connessioni pemanenti, che certo non hanno niente a che vedere con la politica attuale (e originaria) del protocollo HTTP.

La realtà, alla fine, potrebbe essere quella di ammettere che la tecnologia attuale di Internet è superata. I suoi protocolli, ideati per altre velocità di rete e altre condizioni, sono obsoleti.

Continua...