L’ABC del Web

Condivido, ma solo in parte. La presentazione dei contenuti non serve solo a “godere mentre leggiamo”, spesso è assolutamente necessaria per rendere i contenuti digeribili dall’utente. Così come leggere il grafico di una curva sotto forma di coordinate (x,y) o di funzione, è ben diverso dall’osservarne la rappresentazione grafica.

La posizione di Igor è comune a chi non capisce una tecnologia o non la usa, quindi arriva a snobbarla fino al punto di minimizzarla..

Se avesse capito le dinamiche dello sviluppo sul web, dei suoi molti lati positivi, avrebbe capito che i (molti) compromessi tecnologici fanno parte del gioco..

@Vittorio: hai ragione, sono perfettamente conscio del valore della presentazione e del valore dell’estetica delle cose. Grazie della precisazione.

@Marco: si ma si sta parlando di uno sviluppatore software che sfrutta il web (col blog e con il suo sito personale ad esempio), non di una persona che non ha mai visto un personal computer… è questo che mi ha lasciato rammaricato

vedo di chiarirmi meglio, se posso. Non ho detto che il Web non debba essere formattato, colorato, resa gradevole, comprensibile ai nostri occhi e quant’altro. Dico solo che quando si fa un sito Web non si dovrebbe pensare solo alle Webform, ma si dovrebbe pensare alla struttura. Che guarda caso è la tendenza chiara ed evidente del video su YouTube.

Quando si fa un app WinForms si disegna l’object model e via via si costruiscono sopra i servizi, usando una tecnologia e una serie di framework uniformi, puliti e complementari. Quando si fa un sito Web, raramente lo si pensa in questo modo: si pensa alla grafica, alla pubblicità, senza pensare – per esempio – a fornirlo di webservices. Ed il tutto avviene come dicevo prima con tecnologie molto diverse l’una dall’altra, che si devono incastrare per raggiungere un buon risultato: HTML, JScript, Flash, Ajax, CSS, ASP.Net, ActiveX, etc.

E ripeto: ho lavorato per quasi 10 sul Web, usando ASP-classic, VBScript, CSS e così via. Credo che le cose siano cambiate, ma certe altre sono proprie intrinseche del Web.

Personalmente ritengo che ci sia molto di buono nel “web 2.0″. Quello che non mi piace è lo hype e la fuffa che ancora ci gira intorno.

Quando si fa un sito Web, raramente lo si pensa in questo modo: si pensa alla grafica, alla pubblicità, senza pensare – per esempio – a fornirlo di webservices.

Il fatto che WinForms ti obblighi a fare una certa sequenza di operazioni, vincolando la struttura, non significa che un sistema più aperto non ti consenta egualmente di creare la stessa logica.

Stai confondendo certe scelte architetturali e generalizzandole. E soprattutto, pensi ancora da programmatore. L’interfaccia, l’utente, è un componente essenziale. Poi, il tutto può essere fatto con una tecnologia o miliardi, l’importante è progettare intorno all’utente.

Un WebService di per sé non ha senso. Non ha senso perché non è detto che serva.

Al contrario, una interfaccia è estremamente plausibile che serva, perché sicuramente ci dovrà mettere mano una persona.

Anche il fatto che tu parli di “grafica” e non “interaction design” o “interface design” è significativo di come tu ignori totalmente una enorme componente di sviluppo, che non è appunto programmazione.

…ma, tutto questo, non capisco che inerenza abbia con il web. Il tuo discorso è applicabile a qualunque contesto, anche ai WinForms che citi.

allora, questo richiede quasi un post nuovo sul mio blog.

WinForms non mi obbliga affatto a fare un bel nulla. Semplicemente quando disegno un’app Windows penso alle basi partendo dal domain model? Perchè in questo modo compongono la mia app e costruisco gli oggetti in modo tale che essi possano essere utilizzati in diversi contesti: WinForms, WPF, tool a linea di comando, siti Web. Sì, anche siti Web. Tutta la logica DEVE essere nel domain model, e nei layer intorno. Questa è buona progettazione, che secondo me chi programma per il Web non considera mai. Un buon sito Web deve fornire contenuti attraverso un domain model forte, che vengono consumati lato client.

Prima ho citato il web-services. Sono d’accordo con il Folletto: non sempre serve, ma secondo me quello che serve sempre al giorno d’oggi è poter interoperare con altri sistemi. Invece, ripeto: i siti Web oggi non forniscono nulla di tutto ciò, tranne alcune eccezioni.

Appunto: “Tutta la logica DEVE essere nel domain model”. Ecco l’obbligo che intendevo.

In secondo luogo, il punto è che citi tu è che “chi programma per il Web non considera mai”.

A parte che potrei dirti: e tu gli utenti li consideri?

Però, stai facendo una generalizzazione un tantino campata in aria. Se io voglio, posso realizzare una architettura sul web strutturata bene, come strutturata male.

Che c’entra il web in tutto questo? Niente. Stai semplicemente dicendo che “qualche programmatore non studia il design architetturale delle proprie applicazioni”. E la novità dove sta?

@Igor: partiamo dal presupposto che nel tuo post hai asserito una cosa mentre qui ora ne stai asserendo un’altra. Prova a rileggere il tuo post da cui è scaturito il tutto e ti renderai conto che la tua era (è?) una posizione molto estremista su ciò che deve o non deve essere il web (tipo la frase che ho citato qui sopra).

Se vuoi solo asserire che programmare per le applicazioni desktop dal punto di vista dell’interfaccia è più facile… certo! Ma il web è fatto così, libero e democratico anche nelle tecnologie. Quello che vorresti tu è una corporation che possa controllare tutto ciò che va bene o non va bene in modo tale da avere una “bibbia” uniforme a cui tutti possono attingere e imparare il solo modo per fare web. Non è così e spero che non lo diventi mai. C’è un motivo per cui il web s’è evoluto così, le cose possono migliorare o peggiorare, ma sta ai vendor cercare di limare le diversità interpretative delle tecnologie. Non è di certo imponendo una tecnologia dall’alto che si risolvono i problemi (sempre che sti problemi poi ci siano per davvero).

Aggiungo poi che come dice Folletto la tua è una visione meramente da programmatore ma il web non è Eclipse o Visual Studio, è per gli utenti, non per chi crea programmi.

Poi non comprendo bene la tua frase sui Web Service (che mi puzza di “voglio SOAP o qualche sbobbata XML”, cosa che genera più problemi di quanti ne risolve). HTTP permette di creare risorse univoche che tramite HEAD, GET, POST, (e DELETE e PUT) possono essere accedute, quindi diventare servizi web. Questo lo si fa usando il concetto di architettura e applicandolo al web (leggasi REST). Non si capisce bene perché secondo te il web dovrebbe essere una accozzaglia in cui la gente smette di usare le buone pratiche che ha imparato sui manuali.

Salto il resto della terminologia .NET che è decisamente fuori luogo nel contesto della discussione

Purtroppo mi pare di leggere una “sparata” generalizzata. Credo che la discussione per continuare positivamente necessiterebbe di qualcosa di più “succoso” che le tue asserzioni piovute dall’alto (e facilmente confutabili perché non obiettive).

Ciao

il post perfetto, Lawrence, non esiste. Il fatto che in un post dica una cosa e poi qua ne dico un’altra credo sia normale (soprattutto perchè le due cose non si contraddicono). Un post non è solo di chi lo scrive, ma anche di chi poi interagisce e commenta. Rispondo a qualche punto.

1) non sto affatto dicendo che fare interfacce desktop sia più semplice. Dove lo leggi? E’ solo più coerente, coeso ed uniforme. Dici poco. 2) perchè dici che voglio una corporation? dove lo leggi? 3) via HTTP, è vero, tu accedi a qualsiasi cosa su Web. Ma SPESSO le pagine html mischiano forma e contenuto. E’ come se tu entrassi in un centro commerciale dove vedi tutti i prodotti senza alcun ordine, senza etichette, senza modo di reperirle, senza sapere costi. Internet oggi è questo: per sapere dove si trova una cosa, devi chiederla ad un motore di ricerca che continua a scandagliare la mole illimitata di dati per aiutarti quando ne hai bisogno. sei d’accordo? 4) il mio pensiero sui web-services è questo: qualsiasi informazione sul Web non deve essere acceduta solo da webform come succede oggi. Non dico che sia sempre così, occhio, però tu dimmi: può il sito xyz “esportare” le proprie “informazioni” per fare in modo che possano essere fruibili in n ambienti diversi (browser su IE/Mozilla per Windows/Linux/MacOS, pocketpc, console, cellulare)?

La risposta alla domanda (4) è il fulcro del mio discorso. Se un sito non è solo webform, ma c’è una struttura fatta di RSS/ws/varie, posso renderlo interoperabile con tutti gli altri siti, e con programmi client su Windows/Linux/MacOS/altri. Ti faccio un esempio, e poi finisco: il sito MSDN espone dei ws. MSDN non è solo un sito, quindi, e difatti esistono tool che chiedono info a MSDN da console. Amazon è un altro di questi, e stessa cosa eBay e con altri. Questo è il succo. Poi la formattazione ci sta tutta, sia chiaro, capisco che sia un programmatore, ma sono il primo che rimane affascinato dal buon gusto nei siti. Ma il centro di tutto deve essere l’informazione.

@Igor:

mai detto che il post perfetto non esiste ma tu hai detto “chiarisco questo punto” dicendo cose che (a mio avviso) contraddicono il tuo sbotto originale. Comunque non fossilizziamoci su questo aspetto.

1) L’ho dedotto dal tuo fastidio nella non uniformità della programmazione web rispetto alla programmazione desktop (soprattutto in ambienti “controllati” come .NET). Per controllati intendo dove la quasi totalità degli sviluppatori usa la stessa tecnologia che ha la stessa resa e ti garantisce la stessa interfaccia utente su qualsiasi macchina che abbia tale libreria. Nel web il 100% di uniformità non si può avere ma con determinati accorgimenti ci si può avvicinare e far degradare la UI in maniera corretta nel caso di dispositivi mobili o browser carenti. Si può fare, ma oltre a smazzarsi il manualetto che te lo spiega bisogna avere senso estetico, cosa in cui noi programmatori in genere siamo abbastanza carenti.

2) Vedi 1, era un mio pensiero, non ho mai detto “tu hai scritto cosi”. Leggendo il tuo post originale e i tuoi inverventi successivi ho pensato che la tua idea di web fosse lontana da quella attuale.

3) Io ho detto via HTTP, non che la stessa risorsa (pagina HTML con immagini suoni e quant’altro) debba essere la stessa risorsa a cui accedi via API. delicious (come tanti altri) espone un API via HTTP che ha una URL diversa da quella per i browser, proprio perché è un API e non una pagina web. Fai una GET e ti pigli i tuoi dati via JSON o quello che è. Non mi pare rocket science. La parte difficile sta nel cambiare modo di pensare rispetto a XMLRPC e SOAP e imparare come creare queste architetture (leggasi REST). Se è delle lacune degli architetti del web che ti lamenti ok, ma sul web non c’è mai stata una sola scuola di pensiero. Ci vorrà tempo.

Non ho capito che problema ti crea il motore di ricerca però. In un centro commerciale sei tu l’agente di ricerca che gira nei corridoi e negli scaffali organizzati (meglio tirare fuori l’esempio della biblioteca). Su Internet Google lo fa per te. Non capisco il problema. Non vorrai mica scaricarti un file.txt da qualche miliardo di giga con scritto tutti gli URL e tutte le risorse ?

4) Primo: webform è un termine che non esiste. O meglio, esiste nella solita terminologia MS che si occupa di cambiare termini già esistenti e perfettamente consolidati per confondere i lavori del settore (come potenzialmente un me stesso) quando approdano sulle vostre risorse. Secondo: la risposta è si e si chiama HTTP. Cerca “REST” su google e capirai cosa intendo. HTTP è uno standard completissimo (e complesso) che permette di fare tutto quello che ti serve.

Non capisco bene se il succo del tuo discorso è che alcuni siti che ti piacciono non espongono un API (il che non c’entra nulla con il modo in cui questa API è esposta) oppure sei tu che non hai idea di come trovarla. Giuro che dopo la tua precisazione mi son perso. Qual è il tuo problema? Se hai bisogno di un API su abcxyz.com lamentati con loro, no?

@Igor: dal tuo primo post tu stai dicendo, aggiustando il tiro via via e come è giusto che sia visto che ti stai chiarendo le idee tu stesso, quello che da anni i seguaci del semweb e dei web standard stanno predicando.

Ti faccio due esempi.

Tutto lo sforzo profuso nello spingere RDF e tecnologie collegate tendono appunto a rendere utilizzabile il web anche dai cosiddetti “agenti”, ovvero software istruiti per consultare dati e tirare conclusioni logiche — l’obbiettivo è affascinante ma forse utopico.

Lo sforzo profuso nello spingere cose come i CSS è un piccolo passo per lo svuotare il più possibile HTML di ogni traccia di presentazione delle informazioni (con gli ovvi compromessi, HTML ha un “vocabolario” ristretto). Lasciandoci alle spalle robaccia come bgcolor=… e nozioni sballate come “h1 serve per fare un testo grande” si permette al Google di turno di fare meglio il suo lavoro e di capire che h1 è il titolo principale della pagina.

Riguardo al punto 4: personalmente a me fa sempre piacere quando un sito che offre un servizio ha delle API per accedervi programmaticamente. Ma già accade, e mi sembra che i major player (MS, Google, Yahoo…) lo abbiano capito da un pezzo. Gli altri seguiranno.

I motori di ricerca non spariranno di certo, io spesso non so e non devo necessariamente sapere “dove” sta una informazione, ma se la situazione migliorerà forse questi daranno risultati più precisi.

Se vogliamo migliorare il web bisogna che noi addetti facciamo la nostra parte. Ti risparmio il solito rant MS e web standard…

ok, così son contento perchè sento di aver detto quello che avevo da dire. Io, ecco, mi rendo conto di bloggare male, o di fretta, con un po’ di superficialità e così via. Però queste discussioni mi piacciono, perchè anche se non siamo tutti d’accordo, alla fin fine saltano fuori i punti oscuri. Quando io dico “odio programmare per il web” lo dico perchè sono sicuro che cadrei nella trappola di fare un sito inutile, un altro sito che intasa la Rete invece di farne parte davvero. Non voglio che il Web sia standardizzato, assoluatemente, perchè sarebbe un incubo per tutti, però ritengo che tante tecnologie che vengono divulgate non portino nulla di nuovo: escono nuovi Dreamweaver, Flash, WPF/E…ma nulla di tutto ciò aiuta davvero a dare struttura alla Rete. deelan dice che molti siti espongono un’API per dialogare gli uni con gli altri, e dice anche che molti altri siti seguiranno. Non ci credo molto, perchè i siti vetrina esisteranno sempre. Però…prendete un sito di un qualsiasi produttore hardware: perchè non dotarli di API di ogni tipo per chiedere nuove release di software/driver? Siti dei cinema: perchè devo essere obbligato ad andare sul sito per vedere la programmazione? Siti dei centri commerciali: perchè devo essere obbligato ad andare sul sito per vedere offerte o orari di apertura? Siti di palestre, creme abbronzanti, videogiochi, di playboy, scrittori, medicina, banche, di storia, fantascienza, fantasy, musica, giardinaggio, TUTTO: tutto il loro contenuto deve essere usufruibile indipendentemente dal fatto che ci siano pagine web. Di questo sono convinto, e difatti XML, RSS e ditorni servono proprio a questo, ma non è ancora abbastanza. Il sito non deve essere pagine Web, deve essere il suo contenuto. Che poi contenga anche html,dhtml,wpf/e,flash per la formattazione e l’aspetto, ci sto al 100%, su questo siamo d’accordo. Mettiamola così: vorrei un futuro dove gli url non finiscano più con .html, ma sempre con .xml (formattato, d’accordo, con un po’ di XSLT).

@Igor: finalmente un po’ ci capiamo. Il fatto che tu tema la possibilità di fare un sito di merda è obiettivamente un problema tuo, nel senso che non puoi odiare qualcosa perché tu non hai ancora imparato a farla. Io non odio la cucina perché non so cucinare. Non so cucinare e basta ma so che con un po’ di sbattimento posso imparare. Non diventerò mai un guru della cucina (o del web) ma il gap è colmabile, nello stesso modo in cui studi libri sui design patterns o sulle motociclette.

Il web interconnesso con API per tutti però è una utopia, perché è una questione di libera scelta. Se noti nemmeno l’utopia SOAP + UDDI “web service interoperabili per tutti” ha mai funzionato. Prova ad attaccare un WS fatto in .NET da Java o che e cominciano i problemi. Fare un programmillo però che ti fa il controllo della versione del drive hardware porta via dieci linee di codice però… non è rocket science e le API non servono per forza. Ok se ci fossero è meglio, ma non ci sarà mai un API per tutto.

Evito di dirti cosa ne penso dell’idea XML per tutti che esprimi alla fine

Ciao!