Undolog.com

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...

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...

La neo mania sul Web2.0 colpirà anche il mercato ludico dei giochi on-line? Forse ciò è già accaduto da tempo. Alcuni dei concetti che stanno alla base del web2.0 sono stati utilizzati da tempo da numerose esperienze ludiche sul web. Gli appassionati di giochi Online sono abituati ad utilizzare interfacce stile Ajax e conoscono bene il vantaggio di avere parte del software – di gioco – su un server remoto.

Inoltre, questo popolo di giocatori in rete, non ha avuto nessun problema ad interfacciarsi con le nuove politiche di prezzo relative a queste esperienze. Pagare solo quando si gioca o iscriversi con una tassa annuale per accedere al server centrale non sembra aver impedito la massiccia diffusione di giochi Online! Anzi! A ben vedere molti “giocatori” sono estremamente soddisfatti del rapporto prezzo/qualità rispetto ad un approccio di tipo consolle o DVD acquistato in negozio. Tutto ciò dimostra anche quanto sia stato sottovalutato l’aspetto del pagamento Online. Risulta evidente, dal numero di giocatori Online sparsi nel mondo – e in Italia – che non esiste nessun tipo di problema con carte di credito e operazioni protette Online. Infine, aggiornare il proprio gioco Online con un semplice click rende i ludico-dipendenti molto felici.

Quello che andrebbe sottolineato, tuttavia, è che le differenze con le web application che usano Ajax e derivati, sono tante, se non tantissime. Se l’approccio – ormai – è un simpatico ritorno al concetto di main-frame, i giochi hanno dalla loro la capacità di utilizzare connessioni proprietarie che vanno ben oltre il semplice HTTP.

Continua...