JP'zlog

Ceux d'entre vous qui ont régulièrement à faire des présentations scientifiques connaissent très probablement LaTeX Beamer qui permet de faire de très belles présentations. Les possibilités d'animation sont correctes pour le milieu scientifique (comprendre animations statiques), mais un peu de fantaisie ne fait parfois pas de mal

Une alternative possible pour les Mac-users est de combiner l'excellent Keynote avec LaTeX-it pour obtenir des formules. Cependant on peut préférer Beamer pour de nombreuses raisons, y compris celle que l'on ne peut pas toujours présenter avec son Mac.

J'ai découvert un outil fort sympathique nommé KeyJnote, opensource, écrit en Python et s'appuyant sur OpenGL, GhostScript et pdftk. A partir d'un document PDF ou d'une suite d'images, il permet de présenter des slides en plein écran avec les fonctionnalités suivantes.

• Transitions fluides entre slides (et pas gadget, on se croirait presque avec Keynote pour le coup).
• Zoom sur des portions de slides.
• Mise en évidence par jeu de lumières de zones et/ou du curseur.
• Affichage de la mosaïque des slides, très utile pour revenir sur un slide donné, le tout avec des animations de zoom du plus bel effet.

L'essayer, c'est l'adopter Il marche parfaitement sous X11 (moyennant un support 3D de la carte graphique), Mac OS X (là pas de soucis pour OpenGL !) et Windows. A noter qu'il existe un bundle pour Windows avec tout ce qu'il faut pour faire marcher l'application. Enfin vous aurez noté que KeyJnote travaille avec un PDF ou des images, donc vous pouvez l'utiliser aussi pour des slides faits avec OpenOffice.org, PowerPoint ou autre. Vous pouvez même l'utiliser pour faire défiler vos photos de vacance

Un dessin vaut bien de nombreuses explications, aussi je vous recommande de lire cet artice qui compare de manière illustrée un EULA type Microsoft (beeeuuurrrrk !!!), la GPL (boooouuuu !!!), la CDDL (bien !!!) et la BSD (bien !!!). Très instructif.

D'ailleurs ces dessins ne se limitent pas à ces licences et restent valables pour la licence MIT (~BSD) ou MPL (la CDDL en dérive).

When it comes to deploying a HTTP webserver, you will most probably think about using Apache HTTPD. After all, this is the most used and versatile web server around there. It also comes under the very nice Apache software license. There are fortunately other server choices (remember that a monopoly is never fruitful, even if the software is opensourced).

If you were on crack and stupid forced to, you could deploy the second most-used web server: Microsoft IIS. But of course you are not dumb you'd rather deploy on a Unix-style box, so you may prefer using something else. An increasingly popular choice is LightHTTPD.

As the name suggests, it is (ways!) lighter than Apache HTTPD. It is especially efficient on static files and FastCGI applications. It is interesting to note that it can run this crap of PHP faster using FastCGI than Apache does with mod_php which is the most common way of deploying it. It also has many of the features that you want (rewriting, proxy-ing, authentification, caching, ...) and some others that are quite innovative (ex: FLV files seeking). It's been already in use by some of the most popular websites: Wikipedia, Youtube and Meebo to name a few.

If you have been striked by the grammar of Apache HTTPD configuration files (do you like mod_rewrite?), you will also enjoy the (arguably) better syntax of the LightHTTP configuration file. For an excellent introduction to LightHTTP, I suggest that you read this Oreilly ONLamp article.

Don't get me wrong: if you have stable servers running Apache HTTPD, it may not be worth making a migration. But if you start experimenting scalability issues, or if you are planning to deploy a new web server, then you might seriously think about using LighHTTPD for a change!

Google vient de sortir une version de Google Desktop pour Mac ! C'est un pari assez intéressant dans la mesure où Mac OS possède depuis longtemps des outils d'indexation :

• Spotlight : la recherche de documents et applications intégrée de Mac OS X
• Quicksliver : un desktop shell plus efficace pour le lancement d'applications que pour la recherche de documents par contenu

Autant Google Desktop venait combler un vide sous Windows en apportant ce qui se faisait sous Mac (et dans une moindre mesure sous Linux/BSD avec Beagle), autant le pari du portage sous Mac OS X est franchement osé. En effet, Google Desktop pour Mac restera t-il une curiosité, ou bien alors se révèlera t-il assez puissant pour que les utilisateurs désactivent Spotlight à son profit ?

Je vais tester ça ce soir, mais je suis curieux d'avoir l'avis des Macounets qui sont parmis vous, comme ce gourou Objective-C ou ce geek qui travaille dans les caves du 20ème sous-sol de Google

L'injection de code SQL est une plaie classique et majeure des applications web. Si vous ne connaissez pas le principe, l'explication suivante devrait suffire.

Un trop grand nombre de développeurs réutilisent tel-quels les valeurs récupérées dans les champs de formulaires ou dans les paramètres d'une requête HTTP GET. Et bien trop souvent ces valeurs sont réutilisées pour construire des requêtes SQL vers une base de données relationnelle. L'injection de code SQL consiste alors à passer des valeurs détournées de façon à modifier la requête SQL. Le grand classique est de contourner des vérifications, insérer des données, ou supprimer purement et simplement des tables.

Petit exemple : considérons un formulaire pour se connecter à une application. La requête SQL qui vérifie l'authentification peut alors se construire comme ceci :

select * from USERS where LOGIN = ? and PASSWORD_MD5 = ?

Le grand classique consiste à construire cette chaîne par concaténation :

$sql = "select * from USERS where LOGIN =" + $login + "and PASSWORD_MD5 =" + $password_md5;

Si ce code vous semble familier, réfléchissez à ce qui se passe si un visteur saisi admin'-- pour valeur de $login :

select * from USERS where LOGIN = admin'-- and PASSWORD_MD5 = blablabla

Autrement dit, la requête se retrouver fermée brutalement et le reste de celle-ci est passé en commentaires par '--'. Dans bien des cas, la vérification dans l'application consiste à vérifier si la requête a retourné une réponse, ce qui sera sûrement le cas ici, et le visiteur va alors se retrouver administrateur sans pour autant connaître le mot de passe de admin !

J'ai trouvé cet excellente référence sur l'injection de code SQL. Je vous encourage vivement à la lire.

Sachez enfin qu'en utilisant un framework web solide et agile, vous pouvez vous simplifier grandement la vie. Pour Rails, vous pouvez suivre ce guide sur la sécurité. Ainsi plutôt que de faire un :

Email.find_all "owner_id = 123 AND subject = '#{@params['subject']}'"

préférez cette forme qui protège des injections SQL :

Email.find_all [ "owner_id = 123 AND subject = ?", @params['subject'] ]

Le dormeur a encore frappé, cette fois-ci chez Apple où il nous présente comment réaliser des widgets Dashboard utilisant Quartz. Plutôt sympa non ?

Il me vient du coup une idée saugrenue : serait-il intéressant d'utiliser des bibliothèques JavaScript type Prototype et script.aculo.us dans des widgets Dashboard ? Ou bien la fatigue me fait-elle dire n'importe quoi ?

Le billet précédent expliquant comment réaliser de la composition BPEL de web services avec Netbeans a été rédigé avec Google Documents. J'ai été bluffé par cette application qui est vraiment facile à prendre en main. Entre outre, l'export PDF marche parfaitement, et l'intégration pour publier vers un blog proposant une interface XML-RPC est vraiment utile. Je suis curieux d'essayer l'édition collaborative d'un document. En tous cas si vous possédez un compte Google jettez-y un oeil, ça fera des données supplémentaires pour que Google fasse son data-mining sur les données de votre vie