Carlo Pescio - blog

E da qui sorge spontanea la domanda.

Come dev'essere un sito per apparire moderno?
 

Romano, provo a rispondere alla domanda di riserva :-), ovvero, come dev'essere un sito per essere moderno?

Ovviamente dipende dal target del sito; chissa', forse esiste anche un target che non odia quei siti con una introduzione di 2 ore :-) in flash, magari senza skip intro "perche' altrimenti la saltano tutti".

Rimanendo sul mio caso, il sito ha delle sedimentazioni tecnologiche ed altre di contenuto.

Ad esempio, all'epoca usare i frame aveva un minimo di senso, perche' snelliva i tempi di accesso (che spesso era in dial-up). Anche scrivere l'html col notepad :-), oltre ad essere un divertente esercizio, aveva un suo senso, perche' finivi per creare pagine molto leggere. Ricordo che nei primi tempi, un responsabile IT di una banca mi chiese "ma che server hai sotto?", vedendo che le pagine arrivavano molto rapidamente, mentre il loro sito, creato con strumenti elefantiaci, era lento come una lumaca anche su hardware potente. Io avevo un serverino Linux da tre soldi :-).

Aveva senso anche scrivere da soli alcune parti dinamiche, ad es. il motore di ricerca. Ai tempi i motori di ricerca erano meno potenti, aggiornavano gli indici con grande ritardo. Un motore di ricerca interno permetteva anche di discriminare meglio le ricerche. Ricordo che un visitatore mi scrisse che l'organizzazione della paginetta di ricerca (cosa / come / dove) era [all'epoca] la piu' chiara che avesse trovato.

Avevo anche creato una "mappa" degli articoli, basata sugli accessi. Una sorta di tagging implicito (curiosamente, molto tempo dopo un algoritmo del tutto analogo e' apparso su una rivista accademica; ed io che l'avevo scritto per gioco in un pomeriggio :-). Oggi, comunque, andrebbe piu' di moda un tagging esplicito. La mappa, peraltro, e' una di quelle cose che si sono rotte spostando il sito, e che non so se varra' la pena riparare, piuttosto che passare ad un meccanismo di tag.

Insomma, oggi molte delle cose fatte durante gli scorsi anni non hanno alcun senso. La banda si spreca, i tool producono un HTML compliant con le ultime fisime :-) del w3c, molte cose (come questo blog) si ottengono piu' facilmente con un mash-up che scrivendole da soli (modularita' alla riscossa :-).

Dove il sito e' piu' vecchio, pero', e' nella struttura dell'informazione, nei contenuti (al di la' degli articoli, tra cui ci sono alcuni sempreverdi), nel linguaggio usato. Riscrivendolo oggi, sarebbe meno orientato al "cosa posso fare per voi" e piu' al "cosa possiamo fare insieme", ma qui diventa un discorso molto lungo :-).

Prima o poi buttero' via tutto e ne pensero' uno "moderno", che rifletta il modo in cui vedo la mia professione oggi, ecc ecc. Nel frattempo, l'aver spostato il sito mi portera' a tagliare qualcosa qua e la', che comunque e' un primo passo...
 

Questo potrebbe diventare un ottimo "hands-on article" B)))... Mi candido per aiutarti a rifare il sito! Pietro
 

Allora ti pongo subito un quesito in cerca di risposte creative...

Se rifacessi il sito probabilmente userei ASP.NET, che permette un buon mix di design statico e [raro, per me] contenuto dinamico. Probabilmente userei una master page per impostare il layout complessivo.

Pero' continuerei ad usare servizi di terze parti, anche in misura maggiore: blogger, google, ecc.

Ovviamente (?) master page e utilizzo di pagine (non web services) create da terzi non vanno molto d'accordo. A questo aggiungerei che blogger, ad esempio, genera molte pagine in modo "autonomo" e le linka tra loro, sempre in modo autonomo. Il post-processing del suo html non mi fa impazzire.

Qualche soluzione in mente ce l'ho, ma niente di brillante. Tanto per giocare :-), qualcuno ha una buona idea su come colmare il gap? In fondo la problematica e' anche generale...
 

Beh se si utilizzano esclusivamente i servizi di Google si può sempre utilizzare le loro AJAX Search API per le ricerche e GData per l'interazione col blog, anche se non so fino a che punto si riesce a colmare il gap perchè non le ho mai usate. Potrebbe essere un'idea però...
 

Si ma non vale :-)), quando ho scritto "non web services" avrei dovuto scrivere, in senso piu' generale, che non vorrei usare API di vario tipo.

Insomma, vorrei includere le pagine dove e' possibile (soprattutto il blog, sul search e' meno importante).

Ovviamente la cosa e' da vedere piu' come stimolo intellettuale che altro, in molti casi un mash-up "interessante" si ottiene solo invocando web services e compagni, ma per una cosa "semplice" come un blog sarebbe tanto carino avere una soluzione alternativa page-based...

Al momento temo che la cosa migliore che ho in mente sia uno script dentro l'header customizzabile del blog, che ricarica la pagina se vede che non e' "dentro" un contenitore, unito ad un contenitore basato su master page che utilizza un tag object con tipo html in luogo del vecchio iframe, ma l'insieme e' relativamente ributtante...

Una alternativa allo script nella pagina e' ridirigere tutto lato server, che forse e' anche meglio.

Idee migliori?
 

Non sono sicuro di aver capito bene cosa intendi: vorresti fare in modo che le pagine di blogger e quelle del tuo sito viaggino all'interno di una struttura uniforme? Una specie di iframe 2.0?
 

Direi che il problema e' abbastanza generale.
Pensa ad un sito come il mio: almeno un menu ti serve, ed il menu sarebbe tanto comodo (se pensi di usare asp.net) metterlo in una master page.

A questo punto, se puoi rifare tutte le pagine (es. corsi ecc) in tecnologia aspx, diciamo che hai risolto.

Gia' "rifare" tutti gli articoli come aspx e' fastidioso, ma ci passi sopra.

Se pero' hai una entry del menu chiamata "blog" che rimanda (appunto :-) al blog, e le pagine del blog, come nel mio caso, le genera blogger.com come puro html, hai tre scelte (che mi vengono in mente):

1) far finta di niente :-), ovvero come oggi, il sito ed il blog sono totalmente separati. Oggi e' volontariamente cosi', nel senso che con i frame li avrei integrati senza problemi. Domani mi spiacerebbe.

2) trovare un modo per far "apparire" le pagine create da blogger in un "contenitore" basato su asp.net / master page. Questo e' cio' che in qualche modo suggerivo, ed ha tutta una serie di controindicazioni, prima di tutto la necessita' di url rewriting. Ti serve l'url rewriting in quanto le pagine generate da blogger si linkano tra loro, quindi non ti basta un container per la sola entry page.

3) "simulare" il codice inserito dalla master page nell'header customizzabile di blogger. In fondo "basta" copiare pezzi di html/jscript. Certo e' molto brutto per la manutenzione.

Va detto che l'opzione 2), volendo uscire dal caso specifico mio, non e' particolarmente semplice in .net se vuoi convivere con un sito messo in hosting su server non dedicato. Asp.net e' una extension per le pagine aspx e poche altre, le pagine con estensione html non le vede neppure. Occorre fare una isapi filter, e non e' detto che te la lascino installare (dettagli su url rewriting in asp.net sul blog di Scott Guthrie).

Il lato divertente e' che tutto diventa piu' semplice con apache, proprio perche' l'url rewriting lo fai con un modulo a livello di web server e non di estensione, ed il mod rewrite e' di norma installato / accessibile anche in casi di shared hosting.

Hmm ora che ci penso il problema e' semplice ma sfaccettato, quasi quasi lo uso come esempio parlando di forma, forcefield e notazioni di design :-)