En attendant l’arrivée du week-end, quelques liens intéressants glanés durant la semaine:

PHP

- Fabien Potencier: Pourquoi PHP n’est pas un bon langage de templates (EDIT: il a ensuite publié un follow-up suite aux 70+ commentaires reçus sur l’article original)
- Federico Cargnelutti propose une idée de database replication adapter pour Zend Framework pour gérer les connexions à vos DB dans le cas de réplications single-master ou multi-master
- Petite série de 7 articles d’introduction au unit testing, et surtout à PHPUnit
- Arrivée de l’extension Solr en 0.9.0 pour PHP
- Joobsbox, un Job Board opensource développé avec Zend Framework, toujours intéressant de voir comment les autres s’en servent

Android

- Nouvelle API de gestion des gestures, dans la version 1.6 d’Android

Et pour le fun: La Bande Pas Dessinée, le remède à votre productivité

Si vous avez essayé d’utiliser la fonction de scheduling de post dans WordPress 2.8, peut-être vous êtes vous aussi heurté au seul message d’erreur de WordPress vous signalant « missed schedule », et du coup, pas de post publié.
Après avoir fouillé leur forum, trouvé moulte utilisateurs à la recherche d’un correctif éventuel (apparemment cela fait déjà plusieurs versions que ce « bug » subsisterait), passé en revue plusieurs hacks en tout genre, je suis finalement tombé sur un message plutôt clair qui dit que le problème n’est pas du côté WordPress, mais bien du côté serveur.

Pour faire court, la solution à tenter, si vous êtes victime de ce « Missed schedule », est la suivante:
editez votre fichier wp-config.php, et ajoutez-y

define("ALTERNATE_WP_CRON", true);

Le commentaire original à ce sujet est fait par Otto32 sur le forum WordPress, pour ceux qui voudraient en lire plus sur le problème.

Afin de pouvoir indexer ces valeurs, et effectuer des recherches les prenant en compte, changez simplement l’analyzer (la classe en charge de traiter chaque terme à indexer) par défaut, qui ne traite que les caractères ‘lettres’, par un analyzer qui traite également les valeurs numériques.  Par exemple, en insérant dans votre bootstrap:

1

Zend_Search_Lucene_Analysis_Analyzer::setDefault(new Zend_Search_Lucene_Analysis_Analyzer_Common_TextNum_CaseInsensitive());

Il est important que cette opération soit faite AVANT toute indexation ET AVANT toute recherche.

Plus d’infos dans la doc du framework.

Problème

Vous avez développé un moteur de recherche qui interroge une base de données MySQL.  Or, lorsque vous effectuez des requêtes avec des termes accentués, MySQL vous retourne également les résultats non-accentués.  Dans certains cas, ce peut-être très utile.  Ceci dit, quelle en est la raison?

Collation = comparaison et regroupement

MySQL (>=4.1.3) se base sur le COLLATE du champ à comparer pour déterminer le type de comparaison qu’il va effectuer.   Une collation (COLLATE) détermine les caractères qui doivent être regroupés et considérés comme équivalents (ex: les caractères accentués ‘à’ et ‘â’ faisant partie du groupe ‘a’, ou encore les caractères ‘A’ et ‘a’.).
Vous déterminez la collation lors de la création de votre table, via le mot-clé COLLATE, ou lors de la création du champ dans cette table (si vous désirez un collation différente pour chacun des champs).

Quelques exemples de COLLATION:
* Dans le charset latin1:
- latin1_swedish_ci (probablement la plus utilisée au monde, étant la collation par défaut de MySQL dans le charset latin1)
- latin1_bin
* Dans le charset utf-8:
- utf8_bin
- utf8_general_ci
… et j’en passe.

Suivant la collation que vous aurez choisie, les comparaisons seront ainsi sensibles (ou non) à la casse et aux accents.
Par exemple, latin1_bin sera sensible à la casse et aux accents tandis que latin1_general_ci ne le sera pas.

Remarque:
Il est à préciser que si vous créez votre table avec une certaine collation, et que vous la changez ensuite (sans utiliser le ALTER TABLE…CONVERT), la collation des champs déjà créés dans cette table ne changera pas, seuls les nouveaux éléments utiliseront la nouvelle collation.  Ce qui pourrait vous induire en erreur…

Testons!

Prenons la table suivante, tout ce qu’il y a de plus banal:

mysql> CREATE TABLE `contacts` (
`lastname` varchar(100) DEFAULT '',
`firstname` varchar(100) DEFAULT ''
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
Query OK, 0 rows affected (0.02 sec)
 
mysql> INSERT INTO contacts VALUES ('andre','ludovic');
Query OK, 1 row affected (0.00 sec)
 
mysql> INSERT INTO contacts VALUES ('Andre','Ludovic');
Query OK, 1 row affected (0.00 sec)

=> COLLATE non spécifié, les champs auront donc comme collation: latin1_swedish_ci (vu que nous sommes dans le charset latin1).

Pour s’en assurer:

mysql> SHOW FULL COLUMNS FROM contacts;
+-----------+--------------+-------------------+------+-----+--------...
| FIELD     | Type         | Collation         | NULL | KEY | DEFAULT
+-----------+--------------+-------------------+------+-----+--------...
| lastname  | varchar(100) | latin1_swedish_ci | YES  |     |
| firstname | varchar(100) | latin1_swedish_ci | YES  |     |
+-----------+--------------+-------------------+------+-----+--------...
2 rows IN SET (0.15 sec)

Tentons notre recherche (les tests ci-dessous sont basés sur la problématique case-sensitive, mais sont tout aussi valables pour celle accents-sensitive):

mysql> SELECT * FROM contacts WHERE lastname = 'andre';
+----------+-----------+
| lastname | firstname |
+----------+-----------+
| andre    | ludovic   |
| Andre    | Ludovic   |
+----------+-----------+
2 rows IN SET (0.00 sec)

Les résultats ne sont pas case-sensitive.  Tout à fait normal donc, car comme expliqué plus haut, la collation latin1_swedish_ci n’est pas case-sensitive.

Il est possible de forcer la collation d’un champ lors de la query, pour passer en mode case-sensitive sur un champ spécifique:

mysql> SELECT * FROM contacts WHERE lastname COLLATE latin1_bin = 'andre';
+----------+-----------+
| lastname | firstname |
+----------+-----------+
| andre    | ludovic   |
+----------+-----------+
1 row IN SET (0.00 sec)

Pour éviter de devoir le faire à chaque requête de comparaison, on peut évidemment modifier la collation du champ lastname:

mysql> ALTER TABLE contacts MODIFY lastname VARCHAR(100) COLLATE latin1_bin;
Query OK, 2 rows affected (0.01 sec)
Records: 2  Duplicates: 0  Warnings: 0
 
mysql> SHOW FULL COLUMNS FROM contacts;
+-----------+--------------+-------------------+------+-----+--------...
| FIELD     | Type         | Collation         | NULL | KEY | DEFAULT
+-----------+--------------+-------------------+------+-----+--------...
| lastname  | varchar(100) | latin1_bin        | YES  |     | NULL
| firstname | varchar(100) | latin1_swedish_ci | YES  |     |
+-----------+--------------+-------------------+------+-----+--------...
2 rows IN SET (0.00 sec)

On peut également convertir tous les champs d’un seul coup, ainsi que la table elle-même:

mysql> ALTER TABLE contacts CONVERT TO CHARSET latin1 COLLATE latin1_bin;
Query OK, 2 rows affected (0.03 sec)
Records: 2  Duplicates: 0  Warnings: 0
 
mysql> SHOW CREATE TABLE contacts;
+----------+-----------------------------------------------------+
| TABLE    | CREATE TABLE                                                                                                            |
+----------+-----------------------------------------------------+
| contacts | CREATE TABLE `contacts` (
`lastname` varchar(100) collate latin1_bin DEFAULT NULL,
`firstname` varchar(100) collate latin1_bin DEFAULT ''
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_bin |
+----------+-----------------------------------------------------+
1 row IN SET (0.00 sec)
 
mysql> SHOW FULL COLUMNS FROM contacts;
+-----------+--------------+------------+------+-----+--------...
| FIELD     | Type         | Collation  | NULL | KEY | DEFAULT |
+-----------+--------------+------------+------+-----+--------...
| lastname  | varchar(100) | latin1_bin | YES  |     | NULL    |
| firstname | varchar(100) | latin1_bin | YES  |     |         |
+-----------+--------------+------------+------+-----+--------...
2 rows IN SET (0.00 sec)

Comme mentionné dans l’introduction de cet article, il faut obligatoirement effectuer un ALTER TABLE…CONVERT pour que MySQL prenne en charge la modification du COLLATE des champs dans cette table. Sans quoi, via un ALTER TABLE CHARSET latin1 COLLATE latin1_bin, seul le COLLATE de la table sera modifié.

Voila, j’espère que vous y voyez un peu plus clair sur l’usage de ce COLLATE, bien que je ne sois pas rentré dans les détails très techniques, mais cela constitue une base suffisante pour en comprendre l’usage.  Je vous conseille également de lire ce très bon PDF, qui vous en apprendra encore d’avantage!

A partir de là, vous pourrez vous aventurer dans la problématique du CHARSET (jeu de caractères), encore plus vaste

Ressources

Quelques tableaux décrivants les regroupements de caractères pour certaines collations
De la doc MySQL sur les charset et les collations
Un tutoriel détaillé, en PDF, sur les charset et les collations

[code]
uninitialized constant RubiGen
[/code]

La version 0.9.9 de Sproutcore provoque apparement ce problème, mettez-la simplement à jour et tout rentrera dans l’ordre (0.9.13 à l’heure de cet article).

• 22 millions de membres
• 4+ millions de visiteurs uniques/mois
• 40 millions de pages vues/jour
• 2 millions de recherches/jour
• 250.000 invitations envoyées/jour
• 1 million de réponses envoyées
• 2 millions de messages email/jour

mais aussi que l’entierté du network graph est stocké en RAM (22 millions de membres, ne l’oublions pas), et qu’il faut 8h pour recréer une instance en RAM (dans le Cloud) à partir des données sur disque…  Quelques astuces ont d’ailleurs été utilisées pour éviter de perdre du temps à recalculer toutes les relations d’un utilisateur, comme par exemple stocker en cache le résultat après le login, résultat qui ne se mettra à jour que si l’utilisateur-même apporte des modifs, pas ses relations.

Vous trouverez (en anglais) un article sur blog d’Oren Hurvitz, qui reprend les grandes lignes de la présentation.  Pour les slides de la conférence:

- LinkedIn – A Professional Social Network Built with Java™ Technologies and Agile Practices
- LinkedIn Communication Architecture

Pour vous y connecter, prenez votre plus beau Safari Mobile, et rendez-vous sur http://www.google.com/talk

D’autres alternatives pour iPhone existaient évidemment, comme Fringe niveau software (nécessitant un jailbreak de la version actuelle de l’iPhone), ou encore Meebo niveau web (présentant déjà son interface optimisée pour le client mobile, mais pas très utf-8 friendly par contre ).  Ceci dit, j’ai toujours eu un peu de mal avec ces clients qui, via une seule appli, vous connectent à tous vos comptes… C’est sûr, c’est très pratique, mais devoir leur communiquer tous mes identifiants me rebute toujours un peu.

Après avoir fait votre checkout depuis l’IDE, allez dans le dossier du projet, éditez le fichier caché .project et remplacez le contenu des tags buildSpec et natures par :

<buildSpec>
<buildCommand>
<name>org.eclipse.php.core.PhpIncrementalProjectBuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>org.eclipse.php.core.PHPNature</nature>
</natures>

Sauvegardez les changements, et faites un refresh de votre projet.

Remarquez aussi le (c) 2005