Undolog.com

Una questione trascurata nell’ambito del Web2.0 è la protezione del codice sorgente. In un ottica Open Source, dove il Web2.0 trova nella beta la sua massima espressione, condividere e far partecipare la comunità lascia sicuramente in secondo piano questioni legate alla protezione del codice sorgente. Ricordiamo, infatti, che gli script Javascript vengono scaricati all’interno del browser dal Web Server, come file testuali, quindi totalmente visibili all’utente finale.
Mentre il codice Server è protetto per definizione (è impossibile accedere al codice di una pagina PHP tramite il protocollo HTTP del browser, salvo i rari casi di malfuzionamento del Web Server), il codice client potrebbe essere soggetto ad un Reverse Engineering.

Esiste tuttavia una semplice protezione ideata, ai suoi esordi, per dimuire la dimensioni degli script Javascript; oggi diventati veri e propri framework in alcuni casi.
Esistono infatti applicativi e siti Web che permettono di comprimere (crunch) il codice Javascript, ma non solo. Questa caratteristica, in modalità diversa, può essere applicata anche al codice HTML e ai fogli di stile CSS. Il codice Javascript, in particolare, oltre ad essere compresso può essere nascosto, ottenendo così una protezione del codice (a vista) tale da rendere più articolata la procedura di Reverse Engineering.

Le differenze tra HTML, CSS e Javascript sono importanti e sostanziali. Mentre la compressione di pagine HTML e fogli di stile può solo agire sull’eliminazione di caratteri inutili o superflui, come ‘a capo’, ‘spazi doppi’, ecc…, Javascript è un linguaggio di programmazione che può quindi eseguire uno speciale codice per decomprimere se stesso.

JavascriptCompressor.com è un servizio gratuito, utilizzabile online, che permette di comprime un codice sorgente Javascript. Le opzioni lo rendono estremamente versatile, garantendo al contempo l’oscuramento del codice.

Esempio, codice di partenza:

Codice con compressione semplice:

Encoding normale:

Ovviamente questo è un esempio, con codici piccoli comprimere non ha davvero molto senso, si rischi di peggiorare le cose e basta (a meno che non siate interessati esclusivamente all’oscuramento del codice a vista).

MemTronic Cruncher Compressor è anch’esso un servizio online (come il precedente funzionano anche in modalità offline) parzialmente gratuito, nel senso che alcune funzioni sono disponibili solo nella versione a pagamento (come la funzione Obfuscade). Rispetto al precedende servizio dovrebbe offrire maggiori prestazioni e sicurezza nel crittaggio del codice. Io li uso indistintamente, a seconda dei casi.

Peterbe.com non permette di comprimere Javascript (salvo che elimando spazi e ‘a capo’), ma propone un compressor per HTML, CSS e XHTML. Io, ad esempio, lo uso per comprimere i fogli di stili.

A meno di usare algoritmi particolari di crunching, che tuttavia appesantirebbero l’elaborazione dei dati, è sempre possibile eseguire un Reverse Engineering del codice, anche quello compresso. O presto o tardi, infatti, il codice originale deve essere inviato all’interprete del browser, il quale lo riconosce (per ora) solo in chiaro. In un futuro, con nuove versioni dei browser, questo impedimento potrebbe essere superato. Sarebbe infatti vantaggioso se venisse implementata, all’interno dei browser, una qualche tecnologia in grado di accettare codice Javascript pre-compilato, in binario per intenderci (caso mai crittato). In questo modo si abbatterebbero i tempi di download degli script, consentendo una naturale protezione dal Reverse Engineering e, non ultimo, maggior performance a livello di esecuzione degli script.

Continua...

Xopus è un editor XML (HTML) in WYSIWYG mode funzionante all’interno del browser. L’avevo già notato qualche tempo fa, grazie ad un articolo uscito su Ajaxian. Ne parlo ora in quanto rimane un’interessante proposta nel panorama web2.0/editor. È un’esperienza interessante! Xopus è sviluppato davvero bene (con supporto italiano), con un’ottima implementazione del menu contestuale, anche se ancora non pienamente cross-browser; alla attuale release 3.1 è supportato solo Microsoft Internet Explorer (versione 6 e 7) tuttavia gli sviluppatori hanno promesso quanto prima una versione compatibile almeno con Firefox (il 1 febbraio è stata rilasciata in alpha la versione 3.1.1 compatibile in Firefox 2.0+).

Come già discusso altrove, la questione della compatibilità (il cross browser) attraverso i browser, rallenta e penalizza lo sviluppo di strumenti che, anche non ricorrendo a tecnologie particolari come Applet Java o Adobe Flash, potrebbero portare un notevole contributo alla Comunità! Conttibuto impedito – alla fine – dalle inutili lotte interne degli attuali produttori di browser: IE, Firefox, Opera, Mozilla, Safari, … !

Visionando i demo si intravede anche qualcosa in più del semplice editor HTML, per dirla in parola povere. Xopus propone infatti sia la struttura classica dell’editor, sia funzioni avanzate sullo stile di Microsoft Word. È possibile, infatti, inserire all’interno della pagina veri e propri oggetti intelligenti che rispondono a determinate caratteristiche, rendendo Xopus un caso particolare.

Come indicato sul sito:

Xopus is a good solution for any business that has a back-end content management system and a front-end publishing-system and therefore two systems which use the same information. To structure that information, to make both ends meet, is therefore a must.

Poete guardate il video dimostrativo che introduce le avanzate caratteristiche di editing. Inoltre potete provare direttamente una demo.

Continua...

È disponibile online la versione Alpha 2 di Firefox 3.0, nome in codice Gran Paradiso. Tra le novità annunciate (la versione definitiva è attesa per fine 2007) troviamo la possibilità di utilizzare il browser in modalità off-line. Tutto questo ricorda Adobe Apollo che, nonostante non si presenti come browser, ne evoca i tratti essenziali.

Continua...

È successo alla TV di trasformarsi in Net TV, come già era successo alla Radio di diventare Net Radio, per non parlare della musica! Ora, come anticipato in altri Post, è ufficiale anche per il Software di trasformarsi a breve in Net Software!

Adobe, che come sappiamo ha da poco acquisito Macromedia, ufficializza le Web Application – del Web 2.0 – in vere e proprie RIA (Rich Internet Applications) con l’annuncio di voler portare sul Web il noto software di fotoritocco Photoshop. È recente l’accordo tra Adobe e Photobucket per rendere disponibile online una tecnologia per l’editing e il remix video. Grazie alla nuova tecnologia sviluppata per Flash 9, con ActionScript 3.0, Adobe punta in alto, anticipando che entro sei mesi sarà disponibile online una versione di Photoshop basata, appunto, su tecnologia Flash.

Effettivamente le nuove potenzialità di ActionScript 3.0 (che coinvolgono progetti come Flex e Apollo – vedi anche Web2.0: Adobe ci prova con Apollo e Ajax: Rich Internet Application) lo rendono il candidato perfetto per l’implementazione di vere RIA sul Web. Ajax, dal canto suo, si vede spodestato dal suo trono in questo nuovo scenario. Nonostante gli innumerevole Framework Ajax, alcuni di ottimo livello, prodotti nel corso di questi ultimi anni, Flash garantisce un’ambiente più evoluto e semplice da manipolare. Inoltre parliamo di uno dei Plugin più diffuso al mondo: Flash ha infatti alle spalle qualche anno in più rispetto ad Ajax e derivati.

Inoltre risulta ovvio che Adobe scelga Flash, essendo oramai lui il produttore. Tuttavia ci sono da considerate questioni tecniche che possono – ad oggi – essere risolte in modo armonico unicamente ricorrendo a tecnologie come quella Flash. Dando uno sguardo al nuovo ActionScript 3.0 ci si rendo subito conto delle enormi possibilità di sviluppo che offre questa nuova piattaforma. Lo standard ECMA del linguaggio e i nuovi oggetti messi a disposizione dal Framework, permettono di arrivare ad un livello di dettaglio impensabile con le precedenti versioni di Flash: una su tutte, ad esempio, la possibilità di accedere ai dati Bitmap di un’immagine caricata da disco!

L’attacco da parte di Adobe sembra svolgerersi quindi su due fronti distinti che hanno in comune la tecnologia Flash (che ricordiamo ha da sempre la capacità di interagire attivamente con il browser e quindi con Javascript lato Client e Scripting lato Server).

Il primo attacco avviene dall’esterno, sul versante browser, dove la tecnologia Apollo si propone di fatto come alternativa ai Kernel usuali delle diverse piattoforme oggi disponibili (Windows, Mac OS, Linux, ecc…); usare Adobe Apollo, quindi, al posto del browser per ottenere prestazioni e applicazioni (vere e proprie RIA) impensabili, aggirando così le incompatibilità tra Internet Explorer, FireFox e compagnia. Inoltre Apollo garantisce una piattaforma unica di sviluppo, al pari di Javascript-Ajax, ma senza i problemi di compatibilità. Quest’ultimo punto è uno scacco notevole a tecnologie come Ajax che ancora oggi soffrono enormemente delle questioni legate alla compatibilità tra browser; non dimentichiamo, inoltre, tutta la questione legata alla resa (rendering) grafica dei CSS!

L’altro attacco avviene direttamente dall’interno, colpendo i Framework Ajax con la carta Flash. L’elemento vincente in questa strategia risiede nell’uso di Flash, della tecnologia Flash, che trova applicazione sia in Flex, sia in Apollo, sia in versione standalone come già siamo abituati a vedere (semplici file SWF per intenderci)! Non c’è dubbio che tale scenario è estremamente invitante per gli sviluppatori, Web e non. Ciò che realizzo in Flash diventa immediatamente riusabile in vari modi, senza costringermi a modificare una sola riga di codice e, inoltre, senza preoccuparmi della compatibilità!

Tutto questo, a mio avviso, è un’importante passo avanti, una svolta di proporzioni notevoli che coinvolge anche il mondo dei giochi e del Marketing. Ne parleremo ancora prossimamente, statene certi!

Continua...

Apollo è il nome in codice (per ora) di un ambizioso progetto Adobe destinato al mondo  RIA (Rich Internet Applications) e Web2.0, Ajax compreso. A qualcuno ricorda Macromedia Contribute, a qualcun’altro Macromedia Central. C’è, altresì, chi vede in Apollo la mera unione -  o possibilità – di far convivere elementi Flash e PDF (cosa tra l’altro già fattibile con Flash Paper)!

Continua...

Una caratteristica dei fogli di stili (i file .css) è quella di poter essere specificati a seconda del media di output. Gli Style Sheet permettono infatti di specificare la stessa classe, lo stesso ID lo stesso TAG, ecc… per media diversi. Ad esempio posso scrivere un file .css con la seguente sintassi:

Quello che ne deriva, alla fine, è che il contenuto del DIVcon id myBoxnon sarà visibile sul browser, sullo schermo, ma quando provo a stampare la pagina troverò un contenuto diverso da quello che mi aspettavo.
I motori di ricerca, spider, crawler o aggregatori, normalmente (per ora) non risolvono i file css. A loro interessa il contenuto non la formattazione visiva. Tuttavia questa tecnica potrebbe avere risvolti interessanti se non inquietanti. Proprio per le caratteristiche dei sistemi di indicizzazione una situazione come quella mostrata qui sotto sarebbe quantomeno curiosa:

Correlato con un file .css di questo tipo:

Google, ad esempio, indicizzerebbe entrambi i contenuti del nostro HTML, anche se a video saremmo in grado di vederne solo uno. Se stampiamo la pagina troveremmo con sorpresa un nuovo contenuto. Il trucco, tuttavia, sarebbe svelato eliminando l’applicazione degli stili nei browser che lo supportano. Normalmente nessuno esegue un’operazione di questo tipo quando naviga su Internet. Tale indagine scaturirebbe solo dopo aver trovato un’incongruenza tra ciò che è visibile a video e ciò che si è stampato!

Ad oggi non mi risultano casi eclatanti di questo tipo di manipolazioni tramite CSS. Un tempo si cercava di aumentare la visibilità su Internet inserendo una serie di testi, parole, dello stesso colore dello sfondo della pagina Web, così da rendere tale artifizio oscuro agli occhi dei navigatori. Con il tempo i motori di indicizzazione si sono cautelati contro queste “frodi”. Sarà forse il momento di anticipare qualche burlone prima di creare un precedente?

Attualmente gli Style Sheet consentono di specificare tutta una serie di media type di output. Per una lista completa vedi il W3C.

Continua...

Chris Pederick rilascia la nuova versione di Web Developer, comodo add-on per FireFox ed altri browser, che insieme a FireBug rende la vita degli sviluppatori Web migliore.
Segnalo questa release per le sue ottime novità rispetto alla versione predente. Le icone della toolbar sono state ridisegnate, ora molto più efficaci. È stato aumentato il numero di funzioni disponibili sui menu, come un comodo magnify in tempo reale, rules e linee guida, possibilità di editare l’HTML. Da installare quanto prima…

Continua...

Nel Post Creare un RSS Reader in PHP e Javascript abbiamo indirettamente incontrato una tecnica estremamente interessante che permetteva di creare – in pratica – un file Javascript da PHP.

Continua...

A Redmond devono avere qualche grosso problema di comprendonio! Risulta magnificamente assurdo che sul finire dell’anno 2006 ancora non ci siano le basi per una – anche – approssimata compatibilità tra IE7 e Firefox! Nonostante il rilascio ufficiale – anche se con un set limitato di localizzazioni – di Internet Explorer 7, l’engine di rendering delle pagine soffre ancora di evidenti difetti di programmazione! Senza infierire entrando in numerosi dettagli elenco solo due clamorosi bachi ancora presenti in questo rilascio ufficiale!!

Prima di tutto i PNG vengono resi differentemente dai GIF… e, peggio ancora, in position absolute subiscono strani contorni a seconda di come gira a IE!! Evidente baco? O follia di qualche junior-developer?

Sul fronte CSS la pseudo classe :hover continua a non essere supportata su tutti i TAG, nonostante molti blog la diano per funzionante! Ma su quale sistema? Vedi W3C…
Un semplice p:last-child è praticamente ignorato! Giustamente Microsoft ha supportato p:first-child. Ora, se implementi il first che cosa ti costa implementare anche last? Mistero…

L’apice dell’assurdo, poi, lo si ottiene con le liste puntate! Udite udite! IE7 si comporta esattamente come IE6! Della serie: vi siete portati appresso codice fallato? Troppi copia e incolla evidentemente! Se definitie una lista con i canonici UL LI e un’immagine personalizzata come list-point, non provate ad usare un float sull’elemento LI, l’immagine scomparirà misteriosamente, esattamente come accadeva su IE6!! L’unico, manco a dirlo, a rendere il tutto corretto è il solito – vecchio – FireFox!

Sul blog di IE7 sono numerose le lamentale. Nonostante sia apprezzato lo sforzo del pachiderma Microsoft di aprire un blog durante lo sviluppo di un software come IE7, rimane tuttavia il dubbio dell’efficacia di questa mossa. Hanno davvero ascoltato le richieste degli utenti-sviluppatori? Il blog di IE7 è stato aperto con troppo ritardo?

Ancora una volta non ci resta che attendere una service-pack prossima ventura…

Continua...

Ecco alcuni brevi consigli su come usare class e id nei fogli di stile. Tenete subito in considerazione che l’uso di tecniche Javascript avanzate, come lo stesso uso di motori Ajax, può entrare in conflitto con i consigli esposti qui! E vedremo alla fine il perchè.

Continua...