Undolog.com

Qualche giorno fa ho installato – su una macchina apposita – la beta di Microsoft Internet Explorer 7. L’installazione è durata un’eternità, gonfiando il PC di robbaccia come al solito. I primi problemi sono arrivati al primo riavvio richiesto, come sempre; icone scomparsi, strani flickering, ecc…

Alla Microsoft sono anni che ci stanno lavorando e ancora non supportano i CSS come cristo comanda! Non si riesce proprio a capire come riescono a sviluppare così male. Avranno un team di 50 persone almeno, hanno tutti i soldi della terra ma, nonostante ciò, perseverano a creare immondizia software.

Complimenti invece al team di FireFox, che nella beta della versione 2 già guarda a Javascript 1.7!

Che dire… sarebbe meglio che Microsoft smettesse di produrre un suo browser, visto che non riesce assolutamente a stare al passo con i tempi. Ritardi e continue mancanze strutturali rendono IE sostanzialmente inutilizzabile. I bachi, poi, sembrano essere di casa a Redmond, quindi si consiglia vivamente di starne alla larga. Al team di sviluppo: per favore, supportate il formato PNG con la trasparenza a 24bit… sono secoli che FireFox l’ha implementata!! Andiamo…
Speriamo che FireFox 2.0 arrivi quanto prima!!

Continua...

A causa forse delle incompatibilità stilistiche e di output – ancora presenti – tra i vari browser, non tutti conoscono le innumerevoli potenzialità dei fogli di stile. Vogliamo mostrare, quindi, alcune caratteristiche della sintassi CSS sconosciute ai più e per ricordarci quanto poco – spesso – sfruttiamo a pieno gli strumenti che abbiamo a disposizione.

Nota: tutti gli esempio sono stati provati su Firefox 1.5.0.5

Selezione per attributi

Questa caratteristica, spesso indicata cone CSS2 avanzata, permette cose strabiglianti, se ci riflettiamo un attimo. Il maggior vantaggio lo si ottinene lato HTML, dove non sono necessarie classi o id per distinguere i TAG nel CSS. Sono proprio gli attributi – comunque presenti – nel TAG ad indicare quale stile associare. Inoltre qualsiasi attributo del TAG può essere preso come selettore: alt, title, accesskey, ecc…

Selezione per profondità

Questo tipo di selezione è a dir poco spettacolare, se considerate che può essere sommata a quella precedente. Essa permette di definire la gerarchia degli elementi. Guardando l’esempio qui sotto ci si rendo subito conto della straordinaria portata di questo tipo di selezione, che mantiene il codice HTML pulito e senza indicatori superflui.

Addirittura, giusto per concludere questo sorvolo, oltre a last-child esiste first-child e – fantastico – first-letter! Provate voi.
Abbiamo ovviamente appena sfiorato l’argomento, alquanto vasto a dire il vero, che vede i CSS come strumento evoluto per la definizione del layput di pagine. Esistono altri selettori e comportamenti e grandi novità per le specifiche dei file CSS di futura generazione.

Continua...

Finalmente ci siamo! Il Web, tramite il noto marchio Google, sbarca ufficialmente sui telefonini. Il fatto di aver lanciato una campagna pubblicitaria (TIM) che mostra l’utilizzo del motore di ricerca Google sui cellulari, illuminerà quei pochi che ancora non sapevavo che Internet – tutto sommato – era accessibile anche dal proprio telefono mobile.
In realtà non esiste una vera e propria novità tecnologica, nel senso stretto del termine. WAP e derivati (Flash Lite, ad esempio) sono disponibili e utilizzati da tempo, quello che invece rende il tutto interessante è la sponsorizzazione ufficiale dell’uso di Google via mobile.

Si apre ora un possibile nuovo mercato per le realtà IT che dovranno programmare, nel loro palinsesto di offerte, la possibilità di fornire una versione del Web anche per i navigatori mobili.

Ma quanto è diffuso l’uso del cellulare come browser Web?

TIM ha inviato, poco tempo fa, un SMS (pubblicitario) dove informava che le tariffe della navigazione Web (o WAP) via mobile erano variate! Nella fattispecie si paga solo lo scatto alla risposta (speriamo che sarà eliminato al presto anche questo) dopodichè si naviga gratis per quanto si vuole. Questo è un passo avanti che conferma il destino che – o presto o tardi – ci attende.

Risulta quindi evidente un movimento, un fermento in questo ambito, provato – ad esempio – da un accordo su una serie di linee guida per lo sviluppo di siti WebMobile tra Nokia, Vodafone e Google. Il W3C, dal canto suo, propone le sue linee guida.

Secondo una ricerca condotta dalla M:Metrics, il 19% degli utenti statunitensi di telefonia mobile consultano regolarmente il Web attraverso il proprio telefonino! Immaginiamoci i giapponesi!

Daniel Applequist, un dirigente di Vodafone, afferma che “ora sappiamo che gli apparecchi a disposizione degli utenti hanno la capacità di navigare su Internet, ma non sono usati tanto quanto potrebbero esserlo”. Ciò è vero e dipende, quasi unicamente, dai costi di connessione, ancora sostanzialmente diversi rispetto alle connessioni casalinghe e non ben pubblicizzati alla massa. In aggiunta a questo bisogna anche considerare che – almeno in Italia – è relativamente da poco che si sono diffusi i cellulari a colori!! Quesione da non sottovalutare!
Inoltre, Applequist, sostiene che “la maggioranza dei siti Web disponibili non funzionano bene coi cellulari”, e a ben vedere, aggiungeremo noi, non funzionano bene nemmeno con i normali browser sul PC!
La questione è – purtroppo – sempre la stessa! Lo standard – in questo ambito – sembra soffrire di enormi e insormontabili difficoltà. Gli sviluppatori già temono, infatti, che si ripresenti l’identico scenario rovinoso presente sui desktop, dove anche browser del calibro di Firefox soffrono ancora di funzionamenti diversi a seconda dei sistemi operativi su cui è installato. E’ difficile pensare ad uno standard robusto e sicuro per il mobile quando – ancora adesso – Microsoft IE rende una pagina in un modo e Opera in un altro!

Sicuramente parte della colpa va attribuita anche agli sviluppatori Web, che spesso utilizzano funzioni proprietarie specifiche di un determinato browser, rendendo di fatto la navigazione – se non addirittura la lettura – impossibile con altri sistemi. Tuttavia, per chi lavora nel Web, la prospettiva di avere un nuovo device da esplorare è sicuramente affascinante, qualche nube all’orizzonte potrebbe scoraggiare i più, ma noi siamo fiduciosi, un nuovo mercato si apre e forse potrebbe essere l’occasione per sistemare – una volta per tutte – l’incubo maggiore che assilla la maggioranza degli sviluppatori Web.

W3C propone le sue linee guida, starà a noi – però – cercare di seguirle e, non ultimi, ai costruttori di cellulari che presto potrebbero diventare Apple o Microsoft… o caso mai Adobe, visto che sta comprando di tutto!

Continua...

Lo sviluppo di web application con tecnologie di tipo Ajax ha messo in luce tutte le limitazione del protocollo di connessione Internet HTTP. Presto o trardi qualsiasi programmatore si scontra con l’esigenza – ad esempio – di avere una connessione permanete con il client. L’invio verso i client di un broadcast message è tutt’oggi impossibile senza ricorrere a qualche rischioso artifizio!

Nello scenario Internet, tuttavia, l’uso di componenti speciali come ActiveX Object, Flash o Java Applet, permettono di aggirare ottimamente il problema. Spesso, infatti, ci si chiede se l’oggetto HTTPRequest (mattone base per esperienze Ajax) non sia sostituibile da un componente ActiveX o utilizzando un filmato Flash casomai invisibile!

Questa è una delle questioni più struggenti nell’ambito dello sviluppo di web application di nuova generazione. A dimostrarlo, infatti, ci sono tutta una serie di “beta” web application che utilizzano tecnologie miste per risolvere le varie problematiche che si presentano – e che l’HTTPRequest non è in grado di svolgere. Lo stesso FlickR, uno dei photo-blog di maggior successo, ricorre all’uso di filmati Flash in alcune sezioni del sito. Ci sono poi realtà ancora più articolate dove sono presenti Applet Java o controlli ActiveX per arrivare li dove nessuno – Ajax – era mai giunto prima!

Quello che andrebbe fatto, a breve termine, è un nuovo standard per l’HTTPRequest, chiamandolo addirittura in un altro modo. Riuscire ad ottenere un oggetto, presente in tutti i browser, capace di realizzare connessioni permaneti e in grado di manipolare più protocolli. Tuttavia ciò sarebbe una fantasticheria per gli sviluppatori ma, ragionandoci bene, potrebbe portare alla morte di Internet come la conosciamo.

Quando l’HTTP fu ideato la rete globale come la conosciamo oggi aveva velocità e utenti ben differenti. I punti importanti dell’HTTP sono:

• Connessione al Web Server
• Richiesta di un file
• Disconnessione

L’HTTP nasce proprio con l’idea di base di non gravare sulla trasmissione via rete; minimo supporto di handshake! Ancora oggi quando il browser richiede una pagina ad un Web Server, svolge proprio i tre passi indicati sopra. E’ importante notare come Google abbia sviluppato un software come Google Earth per poter superare gli ostacoli di connessione e altre cosine. Internet è pronta a sopportare connessioni permaneti? Noi pensiamo che sia prematuro. La maggior parte degli hosting crollerebbe in pochi secondi. Banda e CPU dovrebbero essere ben più capaci per sopportare la mole di traffico che si produce oggigiorno.

Le realtà che supportano connessioni permaneti sono ben circoscritte e fanno sempre uso di componenti e tecnologie specifiche e sofisticate.

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