Geek, alcool et rock'n'roll

Allez, je place ça dans ma liste "à lire" : Bonnes pratiques de conception de formulaires Web, présentation de Luke Wroblewski.

Ça a l'air bien !

(via Yves chez Vincent)

- Et donc, c'est quoi ce que tu voulais dire ?

Là, on repense à ces mots et ces phrases, pensés, travaillés, puis retravaillés, recomposés, depuis des jours, tellement rabâchés qu'ils en perdent leur sens. Et puis finalement ils sortent de la bouche, un peu l'air de rien. On se dit, merde, c'est inutile, ça sert à rien de faire de la peine à la personne qu'on a en face de soi, finalement on est bien comme ça on a qu'à continuer encore un peu, c'est plus facile, et ainsi tout le monde est content.

Et puis, non, on laisse ces phrases aller, comme un texte appris par coeur. On reste fidèle à sa ligne de conduite et puis après on se demande vraiment si on a pris la bonne décision. On voit l'autre être triste, on est triste soi-même, ça sert juste à rien. Je découvre que les ruptures, c'est aussi difficile pour les deux côtés.

Allez, ça ira mieux demain, comme toujours.

Mise à jour : C'est demain et ça va mieux. Merci pour les ptits messages les copains !

Oui, oui, encore un post de geek...

Bon, je me suis aperçu que Hibernate n'échappait pas les tables et les colonnes des tables. Ainsi, si on a une classe User (pas très courant, n'est-ce pas ?), Hibernate va essayer de générer une table User, et ça va échouer car c'est un mot-clé SQL^[1]. Et c'est la même chose pour les champs.

La méthode préconisée par Hibernate est de rajouter des guillemets inversées, avec @Column ou @Table lorsqu'on utilise des annotations JPA.

Bon, moi je me voyais pas faire ça, alors j'ai plutôt utilisé une NamingStrategy que vous voyez ci-dessous:

package mon.package;

import org.hibernate.cfg.ImprovedNamingStrategy;

public class JujuNamingStrategy extends ImprovedNamingStrategy {

	@Override
	public String columnName(String columnName) {
		return "`" + super.columnName(columnName) + "`";
	}

	@Override
	public String tableName(String tableName) {
		return "`" + super.tableName(tableName) + "`";
	}

	@Override
	public String classToTableName(String className) {
		return "`" + super.classToTableName(className) + "`";
	}

}

Et ça se met en oeuvre simplement dans notre fichier de configuration Spring, lorsqu'on définit les propriétés de l'EntityManagerFactory, dans la jpaPropertyMap qui sert à définit les propriétés spécifiques à Hibernate :

<entry key="hibernate.ejb.naming_strategy" value="mon.package.JujuNamingStrategy" />

Certes, peut-être manque-t-il certaines méthodes dans ma classe; je les ajouterai lorsque j'en aurai besoin, pour l'instant ça marche bien comme ça !

Dans flickr, parfois, certaines images sont protégées. C'est le cas de certaines photos de Paris-Web (et néanmoins superbes).

J'avais besoin d'en télécharger quelques-unes pour faire une présentation interne, et donc j'ai essayé de comprendre ce qui empêche le téléchargement. Et en fait, c'est très simple: flickr pose une image invisible (spaceball.gif) par dessus l'image normale. Ainsi, si on cherche à la sauvegarder, c'est l'image invisible que l'on sauvegarde.

Une première manière consiste à utiliser l'excellente extension Firebug. On clique avec le bouton droit de la souris sur l'image, puis on choisit "Inspecter un élément". Là, la fenêtre de Firebug s'ouvre, avec l'image invisible sélectionnée. Il suffit de cliquer avec le bouton droit de la souris sur l'élément, puis de choisir "Supprimer l'élément". Après cela, vous serez alors en mesure de sauvegarder l'image dans la fenêtre principale.

Mais bon, c'est quand même pas super pratique. Alors, j'ai eu l'idée d'utiliser la non moins excellente extension Adblock Plus. Cliquez donc avec le bouton droit de la souris sur votre image spaceball, puis choisissez "Bloquez l'image avec Adblock...". Une boîte de dialogue s'ouvre alors, et il faut choisir la première option (celle sans "*"), puis cliquer sur "Ajouter l'adresse". Et voilà, vous n'aurez plus de protection dans Flickr !

Certes, je n'ai pas fait de LateX depuis longtemps. Mais cette étude sur les polices mathématiques pour LateX peut aussi servir de pense-bête le jour où j'en aurai besoin.

C'est chose faite :-)

Pourtant, en pénétrant chez les Frères Mousse, je m'étais dit: "non, cette fois, je n'achèterai pas de bières, il m'en reste plein à l'appart, et je déménage bientôt."

Et voilà. Les bières de Noël sont arrivées, et j'ai été obligé d'acheter de la Leffe de Noël, de la Corsendonk de Noël, de la Barbar de Noël, et de la Carolus de Noël... (il me reste encore de la Bush de Noël de l'année dernière... ;-) )

Et je me suis laissé tenter par la Bush des nuits... Il va falloir l'apprécier en petit comité, comme là DeuS jadis :-)

Et samedi soir, c'était soirée whiskies. J'ai goûté deux Signatory Vintage assez fantastiques: celui de cette année avec Bunnahabhain, et celui de l'année dernière avec Laphroaig. Après, on a changé de bar pour un autre qui avait un choix plus limité, et j'ai dû me contenter d'un classique Oban, que je n'ai pas autant apprécié.

Promis, la prochaine fois qu'on va au Mans, on ira dans ce premier bar à la collection de whiskies très sympathique... et pas cher (8 euros) !

Ouéééé encore un billet de geek ! (Ça veut dire que si vous êtes non-geek, vous ne comprendrez qu'un mot sur deux, et encore, les autres paraîtront des gros mots)

Vous pestez, vous avez votre document HTML en UTF-8, vous avez bien mis la ligne suivante :

<meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />

Et pourtant, non, ça veut pas, vous avez toujours è à la place de è, ou é à la place de é ou encore î à la place de î. Ça vous emmerde, vous n'avez certainement pas envie de remettre (respectivement) des è, é, ou î, et laisser ces entités là où elles étaient, à savoir au placard.

Si vous regardez les headers HTTP de réponse (grâce à l'excellente Web Developer Extension), vous voyez ça :

Content-Type: text/html; charset=ISO-8859-1

Or, il est vrai, cela force l'interprétation du charset; cette information a priorité sur celle définie dans la page (et j'avoue que je ne comprends pas vraiment pourquoi, la logique aurait plutôt voulu l'inverse, selon moi).

Il se trouve qu'Apache, par défaut^[1], et pour des raisons obscures qui n'ont rien à voir, configure la propriété suivante :

AddDefaultCharset On

Il suffit de la changer en Off, ou bien d'ajouter AddDefaultCharset Off dans votre .htaccess.

Attention, si un Apache joue le rôle de Reverse-Proxy chez vous (c'est le cas chez moi), il faudra aussi changer ça chez lui.

Si si, c'est marqué sur l'emballage. Et le fait que je viens de m'en enfiler 5 ne change pas ce fait.

Ah oui, ça fait du bien de se poser un peu pendant une journée, à rattraper son retard sur certaines choses à faire en rapport avec le Viet-Nam (billet à venir ;-) ), Paris-Web, le sommeil.

Je suis retourné hier au Bataclan pour la deuxième fois en peu de temps; la dernière fois, c'était pour les Silver Mt Zion Memorial Orchestra and Tra-la-la Band, hier c'était pour les Girls in Hawaii. Bon, ça m'a bien réconcilié avec eux; la dernière fois que je les avais vus, au festival des Inrocks, j'avais été bien déçu par la durée du set, mais là ils ont duré assez longtemps et j'étais bien bien dedans. Et bien qu'auparavant je déniais cela, je dois dire que j'apprécie bien plus un concert lorsque je connais les chansons (et encore plus quand c'est par coeur). Et décidément, j'aime beaucoup le Bataclan qui a toujours une acoustique impeccable (dommage, il n'y a plus de place pour dEUS).

Bon, et puis Dotclear 2.1 est sorti, et puis mon hébergeur lost-oasis propose enfin PostgreSQL 8. Je vais peut-être enfin pouvoir passer à dotclear 2 (youpiii). En plus, DC2.1 inclut un gestionnaire de mise à jour automatique... donc à partir de top, ce devrait être trivial de le mettre à jour !

Pas fini de geeker, moi... :-)

Which Classic Arcade Game Are You?

J-15 ! (ou 16, je sais pas bien compter)