40 000 ans de prison

En triant mes vieux mails, je viens de me marrer un bon coup. Merci à Yoyo sur ce coup-là :

Question idiote, réponse idiote - Vidéo

Danseuse : quel côté de votre cerveau utilisez-vous le plus ?

Je viens de recevoir cette image par mail, je vous mets le texte explicatif, sans préjuger de la véracité des propos. Ce qui est sûr, c’est que le résultat parmi les collègues que j’ai autour de moi est déroutant. Certains voient tourner cette danseuse dans un sens, d’autres dans l’autre sens, d’autres la voient changer régulièrement…

Nous utilisons les hémisphères gauche et droit de notre cerveau pour des tâches bien différentes. Pas étonnant dès lors, que notre caractère détermine l’hémisphère que l’on sollicite le plus souvent. Ca vous laisse dubitatif ? Faites le test ! Le test est simple. Regardez cette danseuse et dites-nous dans quel sens elle tourne.

Pour une grande majorité, la danseuse tourne dans le sens contraire des aiguilles d’une montre; ceux-là utilisent surtout l’hémisphère gauche. Pour les autres en revanche, elle tourne dans le sens des aiguilles d’une montre ; ces derniers utilisent plus souvent l’hémisphère droit.

Mais qu’est-ce que cela signifie ?

* L’hémisphère gauche du cerveau est le côté de la logique, des sciences et des faits purs et durs. Vous faites attention aux détails, aux mots que vous utilisez et reconnaissez des patrons. Vous êtes ancré dans la réalité, et vous basez sur ce que vous savez et comprenez. Vous vous préoccupez du présent, et du passé et avez tendance à ne prendre aucun risque. Vous êtes concret et élaborez des stratégies.

* L’hémisphère droit du cerveau est caractérisé par les sentiments, l’imagination, la philosophie et la religion. Vous vous préoccupez des images, des symboles et des concepts. Vous n’avez pas besoin de tout savoir ; parfois, il vous suffit de croire. Vous êtes compréhensif, impulsif et prenez des risques. Vous êtes plus préoccupé par l’avenir que par le passé.

Personnellement, jusqu’à présent, ça ne tourne QUE dans le sens des aiguilles d’une montre.

Optimisation GWT 1.4

Wouah, je viens de regarder l’interview de Bruce Johnson par InfoQ à propos de GWT.

Bruce explique les nombreuses optimisations qu’ils effectuent au niveau du compilateur GWT. Il explique notamment qu’ils (les développeurs GWT) cherchent sans cesse à optimiser le compilateur, pour cela il comparent par exemple les requêtes qu’une webapp classique effectue vers le serveur et les requêtes que GWT fait.

Et en exemple, autour de la dixième minute, il explique l’optimisation concernant les images : l’ImageBundle. Dans une application classique, il y a des dizaines d’images, souvent toutes petites (icônes, fonds…). Le problème, c’est que le navigateur, même pour se voir répondre que l’image est à jour ouvre très souvent des connexions, d’autant plus qu’il y a d’image ! Ça peut créer (dixit Bruce) une contention en raison du grand nombre de sockets ouvertes côté serveur.

Et bien si vous utilisez cet objet ImageBundle, GWT construit côté serveur une image composite. Comme ça, le navigateur n’a qu’une seule image à télécharger puis vérifier, et les morceaux sont déconstruits côté client en récupérant les bouts de la grosse image et en les plaçant au bon endroit (cf. 10m40s). C’est quand même génial comme idée.

Bon après, il faut que la machine sur laquelle le navigateur tourne dépote d’autant plus, mais on n’a rien sans rien.

PS : Ce que je viens de dire n’est que le reflet de ce que j’ai compris de l’interview. Je n’ai pas testé cette fonctionnalité.

Ça y est, @Override fonctionne enfin comme je l'ai toujours voulu :-)

Depuis Java 5, les annotations ont été ajoutées. L’une des premières a été @Override, une annotation destinée à informer le compilateur que la méthode ainsi annotée redéfinit une méthode parente.

Le problème, c’est qu’en Java 5, cette annotation ne pouvait être utilisée que sur des méthodes en provenance d’une classe parente, pas d’une interface.

Je l’ignorais jusqu’à hier soir, mais en posant la question de la justification de ce choix d’implémentation sur ma liste de diffusion favorite, c’est mon ancien prof de Java et de Génie Logiciel qui m’a répondu que c’était possible depuis Java 6. Cf. le blog de Peter Ahé.

En clair :

public interface MonInterface
{
    void methode();
}

class MonImpl implements MonInterface
{
    // L'annotation suivante est valide depuis Java6, mais produit à la compilation le 
    // message suivant en Java5 :
    // "The method methode() of type MonImpl must override a superclass method"
    @Override
    public void methode()
    {
    }
}

Ça fait un outil de plus pour augmenter la qualité du code, en l’occurrence en diminuant le risque de se retrouver avec du code mort.

How to load a XML Spring context lazily by default

Say you want to change the default-lazy-init attribute programmatically. The most common use case for this seems to appear with unit-testing. In fact, you probably want to load everything when starting a production server, even if it costs you more time. But when testing, and particularly on your machine, you might want to inverse this behaviour. In fact, you might be interested in not loading every 1000 beans of your context when you just need less than 10 for example…

A (beginning of) solution

If you crawl Google, you might find this entry that links to this other one that explains how to programatically modify the lazy-init attribute of each bean of your context. In fact, before the loading occurs, you can iterate through the bean list and call setLazyInit using the method AbstractBeanDefinition.setLazyInit(true). This will be roughly equivalent to manually put lazy-init="true” on every single bean of your context files.

The problem

The problem with this is that you override everything that was declared in the XML context file. You might want a particular bean be instantiated lazily or eagerly for some reason. But iterating through the whole list like this won’t let you keep what was explicitly defined and only redefine the default value. Another problem is that you may have to exclude some bean from this loop, ending up with a condition that really looks like an ugly hack :

for (String beanDefinitionName : context.getBeanDefinitionNames()) {
    AbstractBeanDefinition beanDefinition = (AbstractBeanDefinition)context
            .getBeanDefinition(beanDefinitionName);
    System.err.println(beanDefinitionName);
    // FIXME : ugly hack
    if (!"org.springframework.aop.config.internalAutoProxyCreator".equals(beanDefinitionName)) {
        beanDefinition.setLazyInit(true);
    }
}

Having to exclude the one bean that’s (according to its name) responsible for proxying beans that have to be lazy-loaded seems quite reasonable. But the thing is you obviously don’t have to do it when you put the default-lazy-init manually…

So I looked for a way to simply replace the default value of this attribute instead. After some time digging into Spring code, I finally found it.

When parsing context definition written in XML (since writing it in XML is no requirement), Spring will use an instance of BeanDefinitionReader that will then call DefaultBeanDefinitionDocumentReader to parse the Document instance. Searching a bit more lets us find where the default values are initialized : BeanDefinitionParserDelegate.initDefaults().

LazyInitByDefaultBeanDefinitionDocumentReader

public class LazyInitByDefaultBeanDefinitionDocumentReader extends DefaultBeanDefinitionDocumentReader
{
    @Override
    protected BeanDefinitionParserDelegate createHelper(XmlReaderContext readerContext, Element root)
    {
        root.setAttribute(BeanDefinitionParserDelegate.DEFAULT_LAZY_INIT_ATTRIBUTE, "true");
        return super.createHelper(readerContext, root);
    }
}

I would have preferred to use the seemingly more dedicated method preprocessXml(Node root)], but this method is called after createHelper(), so the default values are already initialized when calling preprocessXml()… So overriding preprocessXml() is “too late”.

I think I’m going to submit a patch into the Spring bug tracker about this problem.

Unit-testing

When you do unit-testing with Spring, you generally inherit the AbstractDependencyInjectionSpringContextTests class. Add this method redefinition to enable the “lazy by default” behaviour :

@Override
protected BeanDefinitionReader createBeanDefinitionReader(GenericApplicationContext context)
{
    XmlBeanDefinitionReader r = new XmlBeanDefinitionReader(context);
    r.setDocumentReaderClass(LazyInitByDefaultBeanDefinitionDocumentReader.class);
    return r;
}

Plain old Java (Spring) code

When you want to create an XML context, you generally use a ClassPathXmlApplicationContext instance. If you want to modify the default behaviour like here, you have to use a GenericApplicationContext. Note that this is what is adviced in the javadoc of ClassPathXmlApplicationContext :

This is a simple, one-stop shop convenience ApplicationContext. Consider using the GenericApplicationContext class in combination with an org.springframework.beans.factory.xml.XmlBeanDefinitionReader for more flexible context setup.

Here is the code using this GenericApplicationContext that enables the lazy-loading :

GenericApplicationContext context = new GenericApplicationContext();
XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(context);
reader.setDocumentReaderClass(LazyInitByDefaultBeanDefinitionDocumentReader.class);
reader.loadBeanDefinitions("/yourApplicationContext.xml");
context.refresh();

When is it needed ?

At the moment, I see two reasons for enabling the lazy-loading by default :

1. When unit-testing, this lets you test a part of the code a bit more quickly, since not every single beans needs to be instantiated.
2. When using code-coverage tools to evaluate a part of the code, this prevents totally unrelated code to appear with non-null percentage.

Hope this small article will help some other people :-).

The Mythical 5%

Via InfoQ, voici un article de Bruce Eckel sur l’informatique aujourd’hui.

Il commence par parler du “fascinant” “5% des programmeurs sont 20 fois plus productifs que les autres 95%.”, et élargit ensuite au monde de l’informatique : jeune, immature, …

Note : Le titre de l’article de Bruce fait très certainement référence au célèbre livre “The Mythical Man-Month” de Frederick P. Brooks. C’est de ce livre qu’est issu la plus célèbre encore “loi de Brooks” :

Ajouter des ressources à un projet en retard le rend encore plus en retard

Je vous conseille aussi la lecture de cet ouvrage, ça se lit très bien et c’est très instructif.

Paranoïa

Extraits de Wikipedia :

Dès lors, la paranoïa est définie comme un délire chronique, organisé, structuré, logique dans son développement, comportant le plus souvent un sentiment de persécution, entraînant une forte adhésion du patient, mais n’entravant pas les autres fonctions psychiques. Ce type de délire, dit délire paranoïaque apparaît préférentiellement chez des sujets marqués par un trouble de la personnalité paranoïaque pré-existant.

Et aussi

Ce trouble affecte 0,3 à 2,5 % de la population générale. D’un point de vue sémiologique les personnalités paranoïaques se caractérisent par quatre traits fondamentaux qui entraînent à terme une inadaptabilité sociale :

​1. la surestimation pathologique de soi-même ;
2. la méfiance extrême à l’égard des autres ;
3. la susceptibilité démesurée ;
4. la fausseté du jugement.

Et pour finir :

La dangerosité psychiatrique des patients affectés par des psychoses paranoïaques n’est pas à négliger. Elle est d’autant plus à craindre :

* qu’il existe un persécuteur désigné, c’est-à-dire un individu précis, jugé comme étant responsable des persécutions que le sujet pense endurer
* que le délire évolue de longue date et s’est enrichi au cours du temps
* qu’il existe un trouble de l’humeur concomittant
* qu’il existe un alcoolisme et/ou une consommation excessive de cannabis

Do Interfaces have semantics ?

When I saw the title of this entry in my feed reader, my first thought was “who the f*** could be wondering if interfaces have semantics ?”. Happily, that’s not Gavin who thinks this.

The assertion is the following :

Interfaces in Java don’t have any semantics attached. Only a concrete class can define the semantics of a method.

In my opinion, that’s even what interfaces are designed for, defining semantics…

I totally agree with Gavin when he says semantics is defined in the Javadoc and the “name of the things”. I always find myself taking a long time to carefully choose the naming of my objects, since I want those names to be the most meaningful possible (same for method parameters, method names, and so on. Naming meaninfully local variable is also important, but it goes beyond the scope of the current subject).

Using polymorphism let you see different implementations as the same thing, thanks to the defined contract. Maybe I’m only viewing interfaces throught the Liskov principle. But for me contract is a synonymous for semantics when it comes to programming, although I’d be glad to hear explanations of where it differs in your opinion.

Even more, I think that today, as everybody gets more and more used to using the dependency injection pattern, some concrete classes are not even known to the code they’re used by. It’s becoming common to use classes only through their interfaces only (services, for example). In those case, semantics resides in the interface only, and implementations obviously have to respect it very carefully.

J'ai un différentiel de 500 ou 300mA et je vais mourir si je touche le jus

Attention, ce qui suit est issu de ma compréhension du domaine de l’électricité et plus particulièrement de la sécurité électrique. Ne prenez donc pas mes dires pour argent comptant. Si j’ai dit une bêtise, n’hésitez pas à me corriger dans les commentaires. Tout le monde en profitera :-).

J’ai trouvé ce petit sondage via google sur le forum Santé de hardware.fr. passons sur la question : “mais que vient f***re un forum santé sur Hardware.fr”. Faut que j’arrête d’être mauvaise langue, cette page contient quelques informations intéressantes.

En plus, en recoupant avec les informations de connaissances plus au jus (haha) que moi et ma récente formation de Sauveteur Secouriste du Travail, on comprend mieux cette phrase. En effet, sachez qu’en gros, la mort se trouvera presque toujours si vous prenez 50mA en touchant un fil dans lequel circule le courant. Et même à partir de 25mA, vous serez pas en grande forme.

La question qui se pose donc est la suivante : est-ce que je peux faire quelque chose au niveau de mon installation pour que si je touche d’une façon ou d’une autre quelque chose qui serait en contact avec le courant électrique de ma maison ? (l’un des deux fils, la phase, plus précisément).

Allez voir à l’entrée de votre maison. Vous devez avoir un truc qui permet de faire une coupure générale de l’électricité de votre maison. C’est ça qu’on appelle le disjoncteur. Regardez ce qu’il y a écrit dessus. S’il ressemble à ça : Si vous touchez le courant, vous êtes mort…

Que faire ?

Derrière le disjoncteur, que vous ne pouvez pas changer sans faire appel à EDF, vous pouvez installer un dispositif différentiel plus sensible que les 500mA comme celui que j’ai, par exemple. La norme est aujourd’hui à 30mA. Mais il est quand même flippant de voir des statistiques annoncées qu’au vu du parc électrique français, 50% des foyers sont encore équipés de différentiels comme le mien, inutiles pour protéger les humains…

Par contre, je n’ai pas encore bien compris s’il fallait mettre un interrupteur ou un disjoncteur différentiel. D’après cette réponse sur leurs différences sur Yahoo Questions/Réponses, je comprends que le disjoncteur est juste un peu mieux parce qu’il va aussi protéger les installations des surintensités, alors qu’un interrupteur grillera tout simplement.

Ce que j’en comprends aussi, c’est que disjoncteur ou interrupteur, l’important est qu’il soit différentiel pour protéger les humains. Au choix du propriétaire de choisir ou non de mieux protéger aussi son installation.

En vrac

Quelques trucs marrants reçus ou trouvés ces temps-ci :

Le karaté à la Star Ac’ :

Via Géraud, le Rap de l’Aveyron :

Via BienBienBien, le nouveau teckto-tube pour les moins de 15 ans, flippant :

Et pour finir, cours de strip-tease :