Importare dati database vecchio o popolarlo ex novo?
In questi giorni sto per pubblicare un nuovo progetto di un’agenzia immobiliare. Si è giunti al momento in cui bisogna popolare il database con i dati reali e son sorti alcuni problemi con il committente nonostante gli accordi preliminari.
L’agenzia possiede già un sito web pubblicato alcuni anni fa e quindi un database già esistente. Dai colloqui preliminari con il cliente abbiamo stabilito che ogni singola tabella del database già esistente doveva essere riprogettata in quanto possedeva troppi campi in meno a quelli che il cliente richiede nel nuovo.
Fin qui nessun problema, nuova progettazione del database, testing effettuato con il cliente senza problemi. Risultato: il progetto piace al cliente.
Ora però arrivano i problemi. Nel momento in cui il cliente è venuto a sapere che dovrà reinserire a mano tutti gli immobili già presenti nel vecchio database si è risentito affermando di non avere tempo a disposizione per effettuare tale operazione.
Su questo punto pongo l’articolo di oggi.
La nuova tabella immobili contiene circa 15 campi in più rispetto alla precedente, oltre a collegamenti con altre tabelle che il db precedente non aveva. Ovviamente alcuni dei 15 campi non possono contenere valore NULL e quindi hanno bisogno di essere popolati con dati che non sono presenti nel database vecchio.
Secondo voi in questi casi quale è la strada più giusta?
Riprogettare il database in maniera che i vecchi immobili contengano solo i dati contenuti nel vecchio database, lasciando che i nuovi campi vengano riempiti con i nuovi immobili e quindi importare il database vecchio oppure cercare di far ragionare il cliente cercando di fargli capire il problema?
In questo caso sono solo un centinaio di entry quindi non un lavoro impossibile da realizzare ma, supponendo di avere un progetto molto più grande con migliai di valori, secondo voi quale è la strada più indicata?
Sicuramente giunto a questo punto posso trarre la conclusione di aver commesso un grave errore in fase di analisi del progetto web. Ora o per colpa mia che mi sono spiegato male con il cliente, o a causa del cliente che magari ha fatto “orecchie da mercante”, il problema resta. Nei prossimi progetti quale sarebbe secondo voi la scelta iniziale di progettazione?
Supporto CSS3 e HTML5 dei moderni browser
E’ ormai un po’ di tempo che sono state rilasciate le nuove versioni di CSS e HTML e sono tantissime le innovazioni che hanno apportano. Il CSS3 è sicuramente più anziano del neonato HTML5 e quindi più conosciuto e utilizzato ma anche quest ultimo si sta facendo spazio velocemente tra le righe di codice dei moderni web designer. In rete ormai sono presenti tantissime gallerie di siti web realizzati interamente con questi nuovi linguaggi e guide, tutorial, discussioni sono ormai all’ordine del giorno.
Condizione necessaria per sfruttare queste due nuove versioni però è il supporto dei moderni browser a tali innovazioni. Quando si pensa ad un browser di nuova generazione viene quasi naturale fare le seguente associazione: nuovo browser = supporto dei nuovi standard. Purtroppo non è cosi; anzi, per essere più precisi bisogna affermare che con nessun browser è cosi.
Le prove a dimostrazione di tale affermazione ce le offre un nuovo servizio online rilasciato da poco tempo, FindMeByIp. Servizio che fornisce molte informazioni sulla nostra connessione, sul browser con cui navighiamo e sul supporto che ha il browser alle nuove versioni di CSS e HTML.
Prima di provare tale servizio ero a conoscenza che molte delle nuove proprietà del CSS3 e dei tags HTML5 non fossero supportati dai browser ma non credevo che i risultati fossero cosi sconcertanti.
Vediamo insieme cosa è venuto fuori analizzando l’ultima versione dei 5 browser più famosi e utilizzati al momento: Mozilla Firefox 3.5, Google Chrome 3.0, Opera 10, Safari 4, Internet Explorer 8. Ovviamente da tale analisi sono state escluse eventuali versioni non ancora definitive.
Simple jQuery Ajax content loading: creare un sito utilizzando Ajax

Quante volte abbiamo a che fare con siti statici le cui pagine si differenziano soltanto per il contenuto lasciando costanti le altre parti della pagina?
Il problema di siti di questo genere è che passando da pagina a pagina dobbiamo comunque ricaricare anche quelle parti statiche, lo sfondo, le immagini e quant altro è contenuto nella pagina.
Una soluzione ovviamente esiste e può essere applicata anche a siti che non hanno solo pagine statiche ma, per iniziare, è sicuramente buona norma imparare a realizzare siti semplici con tale soluzione. Come molti avranno capito sto parlando della tecnologia Ajax che è sicuramente una delle più importanti innovazioni degli ultimi anni nel settore del web developing.
Per chi non sapesse di cosa sto parlando, diamo una definizione di Ajax, in modo da rendere l’articolo semplice e chiaro per chiunque.
La risoluzione giusta per un sito web
Qualche tempo fa ho aperto una discussione sull’argomento IE6 dove chiedevo consiglio sul fatto che fosse ancora corretto o meno realizzare layout IE6-compatible anche per quei siti che hanno una bassa percentuale di visitatori con tale browser. Oggi invece vorrei sapere cosa ne pensate sul fatto di realizzare o meno layout compatibili con risoluzioni molto inferiori alle reali statistiche di utilizzo di un sito web.
L’articolo proviene da una discussione avuta in questo fine settimana con altri “addetti ai lavori”. Come in ogni ambito riguardante il web-design, anche riguardo questo argomento le scuole di pensiero sono diverse. C’è chi ancora realizza layout compatibili con schermi 800×600, chi ormai è passato allo standard 960 pixel e chi preferisce layout fluidi che si adattano a tutti i monitor.
In un altro articolo, prendendo spunto da un post letto su Tomstardust, avevo precedentemente discusso anche sul fatto che molti utenti che hanno un monitor grande navigano con la finestra del browser ridimensionato e che quindi le statistiche possono essere falsate però, da allora, ho avuto diverse esperienze sia con clienti che con amici, conoscenti, ecc che hanno monitor di dimensioni piuttosto elevate. Ho potuto constatare che, a prescindere dal livello di conoscenza di internet e del pc in generale sono poche le persone che effettivamente ridimensionano molto la finestra del browser. Conclusione quindi, le statistiche sono piuttosto affidabili.
Come base per l’articolo prendo come riferimento proprio le statistiche di visita di questo blog che mi sembrano esempio lampante dell’argomento. I visitatori, in percentuale, utilizzano le seguenti risoluzioni:
-1280×800 21.6%
-1280×1024 21.4%
-1024×768 13.7%
-1680×1050 12.9%
-1440×90012.5%
-1920×12004.3%
-…..
-800×600 0.5%
-inferiori 0.2%
La mia domanda a questo punto è: vale davvero la pena effettuare rinunce o ammattirsi per realizzare layout compatibili con risoluzioni, ad esempio, di 800×600 quando rappresentano meno dell’1% dei visitatori?
Nel mio caso la risoluzione immediatamente prossima agli 800×600 è 1024×768 ed effettivamente rappresenta una buona fetta di utenza. Tale risoluzione garantisce una corretta visualizzazione di layout realizzati nei fatidici 960 pixel. Molti però ancora sostengono che non è giusto che un utente con risoluzione bassa debba essere costretto ad utilizzare la barra orizzontale per scorrere la pagina. Di contro però sappiamo benissimo che un sito ottimizzato per un monitor 800×600 che non utilizzi un layout fluido è qualcosa di aberrante per tutti coloro che hanno un monitor enorme.
Insomma, come sempre, ognuno ha il suo metodo, le sue tecniche e le sue preferenze. Voi che per quale scelta optate?





Facebook
FriendFeed
Delicious
Flickr
Twitter
LastFm
YouTube
Feeds










Back to top








Cellulare: (+39) 340-8652066
Mail:
WLM: