Undolog.com

La versione 7 del browser Microsoft è stata (finalemente) rilasciata in lingua inglese (quasi contemporaneamente è stata rilasciata la release 2 di FireFox). A breve – tramite il servizio di aggiornamenti automatici di Windows – sarà installata su milioni di macchine, come patch del sistema. Qualcuno ha già criticato questa mossa di Microsoft gridando all’ennesimo comportamento scorretto. Agli sviluppatori Web, tuttavia, interessa più sapere che fine farà Internet Explorer 6 (IE6) e come dovranno comportarso nello sviluppo di siti Web.

Il rilascio tramite Windows Update è previsto per l’inizio di novembre! Ne deriva che nel giro di una settimana IE6 sarà bello che sepolto. Gli sviluppatori Web dovranno ovviamente aggiornare il proprio PC, ritrovandosi quindi sprovvisti di una versione 6 su cui effettuare le canoniche prove di compatibilità.

Risulta infatti evidente che chi – come noi – è maniaco degli aggiornamenti e deve assolutamente possedere l’ultima release di un software, si trova tra l’incudine e il martello. Inoltre – come è ovvio – IE6 è morto! Ed era anche ora! Un browser candidato ad essere sicuro – se mai ce ne sarà uno – nel prossimo futuro (prossimi giorni) è sicuramente IE7, visto che sarà quest’ultimo a subire patch (service pack) di sicurezza.

Da sviluppatori comprendiamo che IE6 è ormai abbandonato! Inoltre Microsoft ha esplicitamente consigliato di passare urgentemente alla versione 7, se ci fosse bisogno di ribadirlo. Gli sviluppatori Web dovranno dotarsi di una macchina con IE6 per eseguire i test? Evitando di aggiornarla? Subendo così possibili attacchi da tutte le parti o evitando di andare in rete?

La soluzione più ovvia – e vantaggiosa per Microsoft – è che sviluppatori ed end user passino immediatamente a IE7, che lo vogliano o no!

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