Archive

Archive for luglio 2011

L’estensione MySQL verrà rimossa da PHP?

21 luglio 2011 Lascia un commento

La notizia si è diffusa in seguito ad un intervento di Phillip Olson nella mailing list degli sviluppatori di PHP; il titolo del messaggio parla chiaro: “deprecating ext/mysql“, anche se dal contenuto della mail si evince la necessità di privilegiare un approccio più “morbido” possibile all’importante (e drastica) proposta effettuata.

Già dalle prime righe del messaggio si capisce che l’eventuale processo per l’eliminazione dell’estensione nativa di MySQL in PHP non potrebbe essere iniziato con la versione 5.4; l’obbiettivo sarebbe invece quella di cominciare a segnalarla da subito come deprecata nella sola documentazione, suggerendo nel contempo l’utilizzo di alternative come PDO o mysqli.

La documentazione dovrebbe poi integrare maggiori esempi relativi all’utilizzo delle estensioni da utilizzare in sostituzione, non solo nelle pagine dedicate ad esse, ma anche in quelle in cui vengono descritte le MySQL functions, così da proporne puntualmente le alternative.

Inizierebbe in questo modo un processo che potrebbe portare ad associare le notifiche E_DEPRECATED alle funzioni basate sull’estensione MySQL a partire dalla release 5.5 del linguaggio, fino alla possibile eliminazione nella da tempo promessa versione 6.

L’intenzione potrebbe quindi essere quella di convincere gli sviluppatori a mettere mano al proprio codice così da non dover intervenire in futuro per la risoluzione di problemi di retrocompatibilità.

Categorie:PHP Tag:, , ,

Consigli per il debugging CSS

21 luglio 2011 Lascia un commento

Molto spesso i layout che creiamo non funzionano come sperato. Le cause sono molteplici e di solito ci si concentra su questo o quel browser, ma in realtà i problemi che incontriamo dipendono più che altro dall’approccio che noi abbiamo al debugging CSS. In linea di massima, il debugging CSS dovrebbe essere impostato nel modo più neutrale possibile. Certo, il browser X necessita di quella regola speciale o di un hack, ma a parte questi casi specifici resta il fatto che in linea di massima i problemi possono sorgere in qualsiasi browser. Come fare?

Per prima cosa, occorre procedere per piccoli passi. L’errore più comune è quello di finire un layout, testarlo in un solo browser e poi rendersi conto che ci sono problemi in altri browser. Se il layout non è troppo complesso, possiamo anche in questa fase isolare la regola (o le regole) CSS che creano il problema e sistemarle. Ma se il layout è complesso, diventa difficile operare un tracking ed isolare le cause.

Quindi bisogna procedere a piccoli passi. Prima le regole di stile generale (e test su più browser), poi il posizionamento degli elementi e il loro dimensionamento (e test su più browser), poi la grafica e le immagini di sfondo (e test su più browser) e infine gli ultimi ritocchi (e test su più browser).

Le regole di stile vanno analizzate per dichiarazione. Dobbiamo essere certi che la dichiarazione che stiamo analizzando non crei il problema da noi riscontrato. Se siamo in dubbio, usiamo i commenti CSS su quella dichiarazione e proviamo poi a modificarla. Se il problema è sparito, allora era un valore di una proprietà la causa di tutto. Se il problema permane, commentiamo la dichiarazione e osserviamo il risultato senza modificarne i valori (in pratica la eliminiamo). Il problema è scomparso? Se si, allora era quella dichiarazione la causa. Altrimenti, passiamo alla dichiarazione successiva e ripetiamo la stessa operazione.

Spesso molti presunti bug dei browser non sono altro che regole di stile sbagliate che il browser ignora. Un’altra causa di problemi sono gli errori di sintassi: ecco perché è fondamentale sapere sempre se il nostro CSS è valido. Spesso un punto e virgola, una virgola o uno spazio fuori posto possono far si non solo che il browser ignori una dichiarazione, ma addirittura un intera regola o un gruppo di regole. In questo caso la conoscenza della teoria è basilare, poiché se conosciamo la sintassi di una proprietà evitiamo di cadere in questi errori.

E veniamo ai bug. In realtà non esistono solo i bug nei browser, ma anche la loro differente interpretazione delle specifiche. I bug di IE6 e 7, notissimi, sono tipiche violazioni delle specifiche.

Con IE il modo più indolore per gestire i suoi bug è quello di usare i commenti condizionali per dare a IE delle regole di stile per rimediare ai bug. Si tratta sicuramente di un metodo che mantiene il nostro CSS principale privo di hack e per questo motivo più semplice da gestire.

E per gli altri browser? Per Firefox, oltre alle risorse online rintracciabili con Google, esiste BugzillaOpera non dispone di un bug tracker come quello di Firefox, ma è possibile utilizzare i forum per gli sviluppatori messi a disposizione su Opera.com. Per Safari, il punto di partenza è sicuramente webkit.org, mentre per Chrome è il suo blog ufficiale.

Categorie:CSS Tag:,

Il rilascio di Linux 3.0 verrà posticipato a causa di un bug

21 luglio 2011 Lascia un commento

Con l’inizio dello sviluppo sul ramo 3.0 del kernel Linux, Linus Torvalds aveva fissato per oggi la data di rilascio del kernel 3.0 ufficiale. Così non sarà a causa di un bug scoperto che farà slittare di alcuni giorni il rilascio.

Da un post su Google+Torvalds spiega il perché del ritardo: “Hugh Dickins ha scoperto questo bug nel codice del kernel, abbiamo già la patch per correggere il tutto, ma non credo che il kernel sarà rilasciato subito dopo aver applicato la patch stessa. Hugh ha bisogno di un po’ di tempo per effettuare dei test molto precisi (stress test) in modo da riprodurre il problema e risolverlo in maniera definitiva.”

Il kernel 3.0, a detta di Torvalds, altro non sarà che una release aggiornata del codice incluso nel 2.6.39, quindi si tratta per lo più di una semplice rinumerazione senza grandi stravolgimenti di sorta. La questione che il “papà del kernel” sta ponendo ora è un’altra. Si sta prestando una maggiore attenzione alla qualità generale del codice rilasciato in modo da avere il minor numero possibile di bug. Anche solo avere scoperto e risolto uno solo di baco, non potrà che portare effetti positivi sulla stabilità generale del sistema. La decisione del rinvio del rilascio si rifletterà ovviamente anche su tutte le distro Linux che dovranno aspettare almeno un paio di settimane per includere il nuovo kernel nei loro repository, anche se poi alla fine non dovrebbe creare grossi problemi allo sviluppo delle distro stesse.

Categorie:SOFTWARE Tag:,