D'après Slashdot, la version 11 de DirectX, qui pourrait arriver à la fin de cette année, supportera le rendu en mode raytracing en plus de l'habituelle rasterization.
Truc de ouf, j'trouve (ou serait-ce un poisson d'avril ?).
Si vous aussi vous développez des sites web et qu'on vous impose des exigences déraisonnables du genre "le site doit se charger rapidement" ou "le site doit être identique sous Internet Explorer et Firefox", ce post est fait pour vous.
J'ai remarqué ces derniers mois que le développeur web moyen, malgré un travail pas toujours facile, est rarement bien outillé. Pourtant, chercher une balise dans une soupe HTML de 400ko, tester une modification de CSS, débugger du Javascript, bref, toutes ces tâches qui vous font souffler un grand coup avant de vous y mettre, deviennent triviales pour peu qu'on soit bien outillé.
Voici donc la liste des outils que j'utilise quotidiennement pour me faciliter la vie.
Ceux que vous *devez* avoir : Firebug : l'arme ultime du développeur web, sous forme d'extension pour Firefox. Vous chercher à voir le code html d'une cellule perdue au milieu d'un tableau dans un tableau dans un tableau dans un tableau ? Faites un clic droit sur cette cellule puis choisissez "Inspect element", et Firebug vous montrera tout. Vous voulez tester un changement de CSS ? Pas de problème, Firebug permet d'éditer les styles à la volée. Un développement Javascript à débugger ? Facile, vous pouvez mettre des points d'arrêt et faire du pas-à-pas dans le code. YSlow : cette extension Firefox, qui peut s'intégrer à Firebug, permet de faciliter la mise en pratique des bonnes pratiques professées par Steve Souders et son équipe. Rien à ajouter, si ce n'est que si vous ne connaissez pas ces règles, allez les lire, ça vaut franchement le coup. Web Developer Toolbar : encore une extension Firefox, plus orientée graphisme, puisqu'elle permet par exemple de redimensionner la fenêtre de votre navigateur de façon à simuler une certaine résolution d'écran, de désactiver le Javascript et/ou les CSS, de valider votre code auprès du W3C, d'afficher les bordures des tableaux/cellules, etc. Je pense n'utiliser que 10% des possibilités de cette extension, mais ces 10% suffisent largement à la faire figurer dans cette liste. IETab : cette extension permet de tester vos créations sous Internet Explorer sans quitter Firefox. Le changement de moteur de rendu se fait en cliquant tout bêtement sur une icone, on ne fait pas plus simple. IE Developer Toolbar : un semblant de Web Developer Toolbar dédiée à Internet Explorer. Rien d'aussi impressionnant que sa consoeure sous Firefox, mais c'est déjà un bel effort qui fait gagner beaucoup de temps.
Ceux dont on n'a pas besoin tous les jours mais qu'on est bien contents de trouver : Ruler : une règle, qui vous permet facilement de mesurer des choses à l'écran (en pixels). Fiddler : Cet outil permet de suivre toutes les échanges HTTP entre votre navigateur et l'internesque qui clique. Très pratique pour par exemple vérifier que la compression, le cache et les dates d'expirations fonctionnent bien. L'outil fonctionne tout seul avec Internet Explorer, mais avec Firefox il faudra modifier la configuration du proxy pour que ça fonctionne (mettre le proxy à localhost sur le port 8888). SwitchProxy Tool : une extension Firefox qui permet de changer de réglages du proxy en un clic (je vous laisse deviner à quoi il est particulièrement utile) (indice : ça a un rapport avec Fiddler :-]). TcpView : un des nombreux utilitaires des extraordinaires Mark Russinovich et Bryce Cogswell, qui permet de voir les connexions réseaux ouvertes sur une machine. C'est donc une espèce de netstat graphique, parce que de temps en temps c'est bien de pouvoir vérifier que "attends, je serai pas connecté au mauvais serveur de base de données, là ?".
Voilà, avec tout ça vous n'avez plus d'excuses, il faut faire des sites qui déchirent, maintenant :-)
Bienheureux l'homme qui a fait l'acquisition sur ebay d'un Apple //c tout neuf, jamais déballé depuis tout ce temps (!).
Personnellement, je ne saurais pas quoi en faire (enfin, je saurais quoi en faire pendant quelques semaines, mais après...), mais la gallerie photo du déballage de la bête m'a rappelé de très bons souvenirs.
Amis nostalgiques, tous à vos glandes lacrymales.
Voici une vidéo où il montre comment transformer ses doigts en Wiimote (ou presque) :
Vous vous souvenez de Surface ? Mais si, rappelez-vous, l'espèce de table magique de Microsoft. Une des fonctionnalités de la bête qui avait été mise en avant était le multi-touch, où le fait d'avoir un écran tactile sur lequel on peut interagir à plusieurs endroits en même temps (si vous ne vous souvenez pas, pensez iPhone, il en fait autant). D'après ce que j'ai pu lire un peu partout, ce genre de chose coûte cher. Johnny, lui, fait ça avec quelques dollars de matériel et une Wiimote :
Pour terminer, une démo de head tracking, autrement dit le fait de savoir où se trouve la tête du joueur et d'adapter l'image en conséquence de façon à présenter une image en "vraie" 3D (regardez la vidéo, c'est limpide une fois qu'on l'a vue ^_^), toujours avec l'aide d'une Wiimote :
Comme vous pouvez le voir Johnny est quelqu'un de très actif :-)
Si vous voulez suivre ses projets, il a créé un blog à cet effet.
Les exceptions, c'est comme le fugu : si c'est bien cuisiné, c'est classe, sinon, on meurt.
Ayant récemment changé de mission, j'ai eu l'occasion de lire pas mal de code dernièrement, et disons que, pour garder la métaphore culinaire, c'est plus souvent du Tricatel que du Bocuse.
Ca n'est pas si atroce que ça (mais si j'en rajoute pas c'est pas drôle), cela dit j'ai trouvé quelques perles, et c'est l'une d'entre elles qui m'a amener à écrire ce post. Le morceau de choix qui m'a poussé à poster ici consistait à utiliser des blocs try..catch comme une structure de contrôle, autrement dit là où une paire de if aurait fait l'affaire.
Voici un petit exemple pour illustrer : on souhaite afficher le titre d'un livre (n'importe lequel) en français, et s'il n'y en a pas, en afficher un en anglais. S'il n'y en a pas non plus, on devra afficher un message d'erreur. Pour ce faire, nous avons à notre disposition une méthode GetBookTitles, qui nous renvoie tous les titres de livres dont on dispose dans la langue demandée. Ces titres sont renvoyés sous forme de tableau de chaines de caractères, et si aucun titre n'est disponible dans la langue demandée, ce tableau sera vide. On devra donc prendre garde à vérifier que le tableau n'est pas vide avant d'aller lire dedans... ou pas :
try
{string title = GetBookTitles("fr")[0];
DisplayTitle(title);
}
catch
{
try
{string title = GetBookTitles("en")[0];
DisplayTitle(title);
}
catch
{string title = "Impossible de charger le titre.";
DisplayTitle(title);
}}
Dans le premier bloc try, on récupère les titres de livres en français et on essaye tout de suite de lire le premier, sans vérifier qu'il existe. Si ça fonctionne, on affiche ce titre, sinon l'exécution passe au bloc catch. Ici, on applique la même technique pour récupérer les titres en anglais. Si ça ne fonctionne pas, on passe au bloc catch suivant, où on affiche le message d'erreur.
Voyons à présent le même code, écrit cette fois avec des if :
string[] titles = GetBookTitles("fr");
if(titles.Length > 0){string title = titles[0];
DisplayTitle(title);
}else{
titles = GetBookTitles("en");
if(titles.Length > 0){string title = titles[0];
DisplayTitle(title);
}else{string title = "Impossible de charger le texte.";
DisplayTitle(title);
}}
On récupére les titres des livres en français. S'il y en a, on affiche le premier, sinon on récupère les titres des livres en anglais. S'il y en a, on affiche le premier, sinon on affiche un message d'erreur.
Quel code vous semble le plus facile à relire ? :-)
En vrai, on écrirait d'ailleurs plutôt ça :
string title = "Impossible de charger le texte.";
string[] titles = GetBookTitles("fr");
if(titles.Length == 0){
titles = GetBookTitles("en");
}if(titles.Length > 0){
title = titles[0];
}
DisplayTitle(title);
Et là, quel code vous semble le plus facile à relire ?
Au-delà des problèmes de lecture, et donc de maintenabilité, que pose l'emploi de cette technique vient s'ajouter le problème des performances. En effet, si le coût d'un bloc try..catch est nul tant qu'il n'y a pas d'erreurs, l'addition devient salée en cas de problèmes. Voici des captures d'écran d'une petite application de test que j'ai écrit. Je pense que les chiffres parlent d'eux-mêmes (si ça vous intéresse, vous pouvez télécharger le code source de l'application de test).
Si tout se passe bien, les deux méthodes sont quasi-équivalentes.
Si on ne dipose pas de la version française des titres de livres, le code est plus de 400 fois plus rapide lorsqu'on utilise des if.
Si on ne dispose des titres les livres dans aucune langue, bizarrement le if est encore plus rapide qu'avant (peut-être parce dans ce cas on n'a pas de lecture à faire dans un tableau ?), ce qui le rend 1200 fois plus rapide.
Je répète : dans le pire des cas, le code qui utilise des exceptions est 1200 fois plus lent que son homologue utilisant des if.
Voilà, conclusion : utiliser les exceptions comme structure de contrôle, c'est tordu et lent. J'espère que ça aura convaincu ceux d'entre vous qui écrivent ce genre de choses que ce n'est pas une bonne idée.
Mais vraiment pas.
Si vous aussi, après plusieurs années d'abstinence, vous replongez vos p'tites mains délicates dans la boue verdâtre et bouillonnante du C++, je vous promets de nombreuses séances d'arrachages de cheveux. Pour vous en éviter une et ainsi contribuer à leur préservation, voici un tutorial trodlabal intitulé :
Déclarer une variable membre privée statique en C++<
// Dans la classe, ça se passe comme on s'y attendrait// (modulo le fait qu'on ne peut pas initialiser les variables si elles ne sont pas const)class MaSuperClasse
{public:
staticint m_publique;
private:
staticint m_privee;
};
// En revanche, ensuite ça devient surnaturel :// Il faut *redéclarer* les variables// (cette correction vous est offerte par snihf)// avec du code en vrac, comme ça.int MaSuperClasse::m_publique = 0;
int MaSuperClasse::m_privee = 0;
}
Voilà, moralité : C# et Java sont quand même bien confortables :)
Petite explication de cette bizarrerie par l'ami snihf :
Une variable membre d'instance d'une classe est déclaré dans la déclaration de la classe, et défini lors de l'instanciation de la classe. Pour un membre statique, il n'y a pas d'instanciation, il est donc nécessaire de le définir à part, dans un fichier de définitions.
J'ai récemment remplacé un Winamp de plus en plus AOLisé par XmPlay, un lecteur qu'il est bien pour vos oreilles.
Il propose de base le support d'un grand nombre de formats, et si votre favori n'en fait pas partie (SPC par exemple), les plugins répondent à l'appel, d'autant que la bête accepte les plugins de Winamp (ceux dédiés à la lecture d'un format particulier, pas les autres).
Il dispose également d'une foule de fonctionnalités en standard, comme les raccourcis clavier system wide, le support CDDB, les inévitables skins, et moultes autres joyeusetés.
Il ne manquait plus qu'un plugin RisoliVillard, qui permet à n'importe quelle application de récupérer le nom de la chanson courante en se connectant au port 8462 de votre machine (c'est de cette façon que j'indique quelle chanson j'écoute lorsque je poste sur peuw) (ça et phpMyAdmin, parce que des fois je triche :-]), ce qui est maintenant chose faite \0/
Pour télécharger le plugin ainsi que son code source, cliquez ici.
Je trouve l'argument un peu simpliste, mais peu importe, pour moi l'intéressant dans ce post, ce sont les deux images. Elles représentent les appels systèmes effectués par le couple IIS/Windows et Apache/Linux lorsqu'ils servent une simple page HTML contenant une image.
Et il s'en passe, des choses.
Voilà, c'est tout, je cherche pas à lancer le débat, je trouvais juste les images intéressantes ^_^
Eek Aak Ook !
