Apple remercie le service contrôle qualité ?!

Jan
28

Contrairement à mon habitude, je vais me pencher aujourd’hui sur du matériel: l’iPad d’Apple. Comme à peu près tous les fanboys de la firme de Cupertino, j’avais pu suivre les différentes rumeurs autour de la tablette de la marque à la pomme et bizarrement, je n’avais pas spécialement d’attente par rapport à ce produit.

Baptisé iPad, ce nouveau produit de la collection est assez… surprenant: un format digne d’un cadre photo numérique, les fonctionnalités d’un iPod — notez la nuance de nom ! — puisqu’on ne retrouve plus les fonctionnalités téléphoniques (S/MMS y compris) d’un iPhone. En plus, la disparition du clavier peut déjà laisser entrevoir la galère que ça peut devenir pour écrire un simple mail. Impossible donc de se projeter en train de travailler sur une version plus grande de ce produit.

Mais la seule vraie raison pour laquelle j’ai écrit ce billet était uniquement pour pousser un coup de gueule. Pas contre ce nouveau produit, puisque c’est déjà fait un peu partout, mais plus généralement contre Apple.

J’ai acheté mon premier mac, un mac mini, dès le lancement du produit, à l’époque où mettre des processeurs intel dans des mac était encore une aberration. Panther faisait très bien son boulot et le tout avait complètement réussi à me donner une idée de l’informatique beaucoup plus simple, même si elle m’était complètement différente et nouvelle. J’en était tellement satisfait qu’en moins d’une semaine, cette machine était devenue la seule que j’utilisais désormais, quitte à sacrifier les jeux. La grande histoire d’amour était en marche et m’a même conduit à aller jusqu’à en acheter des actions en bourse ! J’ai toujours aimé cette qualité de finition qui va jusqu’à optimiser le packaging, chose qui, à mes yeux, est un bon indicateur du sérieux d’une marque, un peu comme on jauge les toilettes d’un restaurant. Elle se préoccupait et dépendait complètement de ses clients.

Pourtant, quelques machines en tous genres utilisées plus tard, je suis déçu. Déçu justement par ces mêmes détails qui m’avaient autant plu au départ et qui, aujourd’hui ne laisse plus transparaitre cette préoccupation . Il suffit de prendre un exemple bien concret: les accessoires fournis avec l’iPhone. Avec l’iPhone EDGE (américain), il n’y avait rien pour sortir sa carte SIM. Le temps de nous arriver en France, une petite broche métallique avait fait son apparition. Finalement, elle a disparut des accessoires lors de la sortie de la version 3G du téléphone… et n’est pas réapparue non plus avec le 3GS. Il y’a fort à parier que cette suppression est motivée par la baisse incroyable des prix mais aucune alternative n’a pu/su être pourtant proposée. Ceci est bien évidemment un exemple dérisoire mais le seul qui me venait en tête à cette heure.

Je pourrais également aborder la fréquence des mises à niveau des composant des produits mais ce point serait beaucoup plus discutable.

Je fais parti de ces gens qui, une fois séduits, estiment tout à fait normal de mettre le prix demandé même s’il pourrait paraitre particulièrement élevé. Question de reconnaissance pour la qualité du travail effectué. Aujourd’hui, plus que d’être de qualité, les produits estampillés d’une pomme sont devenus des produits pour monsieur tout le monde, super trendy,  et Apple va donc préférer les écouler en quantité plutôt que d’en soigner au plus haut point la qualité — même si elle reste très correcte. Il m’arrive même parfois d’imaginer retrouver cet univers idyllique grâce la venue de Chrome OS. Dans quelques années peut-être !

Bonne année

Jan
5

Je vous souhaite à tous et à toutes, vous les geeks, plein de bonnes pratiques, des tests unitaires et fonctionnels positifs et bien sur, plein de clients !

Les Criteria de Propel deviennent plus sympas

Dec
14

Traduction de l’article original Propel’s Criteria Gets Smarter par François Zaninotto sur le blog officiel de Propel.

J’ai toujours été frustré par les Criteria de Propel. Malgré son API orientée objet pour effectuer des requêtes vers une base de données, je ne trouve pas ça terrible et difficile à apprendre. C’était un des inconvénient de Propel. Mais à partir de Propel 1.5, vous pourrez constater que les Criteria deviendront plus cool.

Les inconvénients des Criteria

Permettez moi d’être plus précis. L’objet Criteria n’a pas connaissance de votre modèle de données et vous force à répéter l’assignation des jointures à chaque fois que cela est nécessaire.

$c = new Criteria();
  1. $c->addJoin(BookPeer::AUTHOR_ID, AuthorPeer::ID);

Avec un Criteria, vous ne pouvez pas écrire de requêtes qui effectuent deux jointures sur la même table. Vous ne pouvez pas non plus écrire facilement de code SQL qui effectueront correctement les associations.

Les Criteria permettent également une syntaxe que vous ne pouvez deviner et vous devez donc avoir la documentation ouverte en permanence jusqu’à ce que vous arriviez à déterminer ce que va réaliser un bout de code de ce genre:

$c = new Criteria();
  1. $c1 = $c->getNewCriterion(BookPeer::TITLE, '%Leo%', Criteria::LIKE);  
  2. $c2 = $c->getNewCriterion(BookPeer::ISBN, '1234', Criteria::EQUAL);  
  3. $c1->addOr($c2);  
  4. $c->add($c1);  
  5. $c->addAscendingOrderByColumn(BookPeer::CREATED_AT);

Après avoir dispensé de nombreuses formations sur Propel, je vois toujours des développeurs lutter pour écrire des requêtes simples. Les Criteria de Propel sont clairement l’une des fonctionnalités les moins intuitives, et ce n’est pas l’une des API les les plus performantes du monde non plus.

La puissance des Criteria

J’ai déjà essayé de mettre en avant ces lacunes il y’a un an et demi à travers un plugin pour le framework symfony appelé DbFinder. Grâce à DbFinder, coder sur des modèles basés sur Propel et apprendre à l’utiliser devient plaisant.

DbFinder se reposait grandement sur les Criteria, mais ajoutait beaucoup de code personnel. Une partie de ce code était nécessaire pour la génération de la structure du modèle. Propel 1.4 a récemment introduit les classes RelationMap, et la possibilité pour un modèle de connaître toutes ses relations à l’éxecution. C’était la première pierre vers une implémentation native de DbFinder dans Propel.

Ajouter les possibilités de DbFinder directement dans les Criteria de Propel était l’étape suivante mais son implémentation devait différer de celle de DbFinder. Il y’a une chose que j’ai pu comprendre ces derniers mois, et c’est la puissance beaucoup plus importante de Propel: le fait que Propel puisse générer des objets au moment de la construction le rend plus rapide que ses concurrents. J’ai donc utilisé le générateur de Propel conjointement à la puissance de DbFinder pour créer la classe ModelCriteria et le générateur PropelQuery.

En initialisant un objet Criteria avec un nom de modèle, il est maintenant possible d’écrire les requêtes de la façon suivante:

$books = PropelQuery::from('Book b')
  1.   ->join('b.Author a')  
  2.    ->where('a.FirstName = ?', 'Leo')  
  3.   ->orderBy('b.Title')  
  4.   ->limit(10)  
  5.   ->find();

Derrière ce “PropelQuery”, ce sont les vieux Criteria qui fonctionnent. Cela veut dire que la nouvelle syntaxe est complètement rétro-compatible. Vous pouvez voir ça comme une couche utilisateur au dessus des Criteria, qui ne détruit aucune application existante. La nouvelle syntaxe a déjà été commitée dans la version 1.5 de Propel, complètement testée et documentée dans un chapitre flambant neuf.

Il y’a une façon de faire

Vous avez certainement compris que cette nouvelle syntaxe peut remplacer complètement l’utilisation des classes “Peer” dans Propel. Mais pour l’instant, cela veut dire qu’il y’a deux façons d’écrire et d’exécuter des requêtes avec Propel. L’ancienne façon, en utilisant des Criteria et des classes “Peer”, et la nouvelle façon, en utilisant PropelQuery.

Et c’est un bon fil conducteur de ne pas laisser trop de choix afin d’éviter que les utilisateurs soient perdus.

L’ancienne façon doit rester par soucis de rétro-compatibilité. Elle restera tant que les version 1.X existeront.

La nouvelle façon deviendra la méthode par défaut dans le futur — peut-être à l’occasion de la sortie de la 1.5. Cela signifie une grande réécriture de la documentation actuelle ainsi que des behaviors, mais ce n’est pas une si conséquente. Plus spécifiquement, la documentation principale ne prendra plus en compte la méthode Criteria et classes Peer. Mais soyez rassuré, le “cookbook” proposera toujours un chapitre sur la façon de les utiliser.

Propel ne devient pas Doctrine

Je sais ce que la plupart des utilisateurs chevronnés de Propel se diront: Propel est en train de devenir Doctrine et abandonne son âme au nouvel ORM superstar. Dans un sens, je suis d’accord avec ça. Cette nouvelle fonctionnalité s’inspire de ce qui a fait la réussite de Doctrine, et que Doctrine a repris depuis d’autres projets. C’est ce qu’on appel le “Open-Source cross-pollinisation”. Réutiliser les meilleures idées trouvées ailleurs ne rime pas nécessairement perdre son âme. L’âme de Propel vient du fait qu’il permette d’interroger une base de données à travers une API orientée objet. C’est toujours le cas, et mieux que jamais.

Maintenant la nouvelle API de PropelQuery possède des différences signifiantes avec celle de Doctrine. Tout d’abord, elle est plus rapide. Propel s’appuie toujours sur du code généré pour exécuter des requêtes en deux fois moins de temps qu’il n’en faut à Doctrine. Les requêtes de Propel n’ont pas besoin de l’implémentation d’un Parser/Lexer puisqu’elles n’acceptent que des clausses simples, décrites de façon standard. En combinant ces clauses multiples, vous pourrez écrire des requêtes complexes. Vous pouvez également étendre les objets PropelQuery afin d’écrire des requêtes nommées qui sont des objets embarquant des requêtes pour une utilisation ultérieure. Ce sera la vraie révolution dans vos habitudes de développement. Le code de vos modèles sera plus lisible, plus facile à faire évoluer et plus solide que jamais.

Le futur de Propel

Un dernier mot: cette nouvelle fonctionnalité n’est pas destinée principalement aux utilisateurs actuels de Propel. Vous les gens qui maîtrisez les Criteria, vous qui avez des Criteria partout dans le code de vos applications, vous serez toujours en mesure de l’utiliser jusqu’à l’extinction des version 1.X. Si vous souhaitez ignorer le nouveau PropelQuery, alors foncez comme d’habitude et ne prenez pas ça en compte, ça n’interférera pas avec votre code.

Mais les nouveaux utilisateurs qui devront choisir un ORM aujourd’hui ont deux choix, et je ne souhaite pas qu’ils ignorent Propel pour de mauvaises raisons. La difficulté d’utilisation des Criteria de Propel était habituellement une raison de ne pas choisir Propel. Ce ne sera plus le cas.

Maintenant, Propel est un ORM facile d’utilisation. Faites passer le mot.

Symfony 1.3 et 1.4 implémentent Propel

Dec
11

Traduction de l’annonce officielle faite par François Zaninotto sur le blog de Propel: Symfony 1.3 and 1.4 released with Propel support.

Symfony vient de franchir un cap inédit dans son histoire: la sortie simultanée des versions 1.3 et 1.4. Ces deux versions incluent Propel et vous pouvez donc déjà commencer vos nouveaux projets avec votre ORM préféré.

Symfony est, pour résumer, le meilleur framework PHP qui existe. Et je n’écris pas ça car que j’ai fais partie de l’équipe de développement initiale — les concurrents ne peuvent pas l’égaler en terme de robustesse, d’architecture, de fonctionnalité, de cohérence ou même à propos de sa facilité d’utilisation et d’intégration dans le cadre d’un développement web professionnel. Le travail effectué pour les versions 1.3 et 1.4 est tout simplement stupéfiant, rendant symfony encore meilleur qu’il ne l’était. Félicitations à l’équipe de développement et à tous les contributeurs du framework pour ce travail génial. C’est un grand jour pour symfony.

C’est également un grand jour pour Propel, pour les développeurs et pour la communauté des utilisateurs. Propel va gagner en visibilité grâce à symfony et les nouveaux utilisateurs ainsi que les volontaires continueront de l’améliorer jours après jours.

Propel 1.4 bénéficiera des corrections mineures

Dec
11

Comme d’hab, traduction de l’article Propel 1.4 will have minor bugfix releases posté sur le blog officiel de Propel.

La version 1.3 de Propel n’a jamais eu de mise à jour mineure avec seulement des corrections de bugs — principalement dû au planning serré de la sortie de la 1.4. Mais ça ne sera pas le cas de la version 1.4. Même si le développement de la prochaine version majeure (1.5) a déjà débuté, les utilisateurs de la version 1.4 n’auront pas à attendre la 1.5 pour pouvoir bénéficier des corrections de bugs ni même à envisager nécessairement une mise à jour vers cette version à venir qui apportera un certain nombre de nouvelles fonctionnalités.

C’est pourquoi Propel 1.4 bénéficiera de corrections de bugs tous les 2 mois environ. La première, la version 1.4.1 est déjà plannifiée pour mi-Janvier et inclura les premières corrections de bugs qui ont été apportées à la 1.5.

À partir de maintenant, toutes les corrections de bugs seront effectuées à la fois sur la version 1.4 ET la version 1.5 alors que les améliorations se trouveront uniquement sur la version à venir. Bien sûr, toutes les corrections apportées aux versions 1.X seront rétro-compatibles et une application développée en utilisant Propel 1.3 ou 1.4 fonctionnera parfaitement avec la version 1.5 ainsi que les suivantes.

Celà veut malheureusement dire que la date de sortie de Propel 1.5 sera légèrement repoussée. Il n’y a aucun intérêt à sortir à la fois des versions majeures et mineures tous les deux ou trois mois car cela impliquerait d’effectuer les mêmes modifications sur 4 versions différentes à l’avenir. Propel 1.5 est donc programmé pour l’instant à fin Février ce qui laissera à l’équipe le temps nécessaires pour rajouter plein de nouvelles fonctionnalités.

Si vous souhaitez savoir où en est le projet, allez jeter un oeil sur le planning de Propel. Cette page affiche la progression de chaque version ainsi que les dates de sortie et l’état actuel de chacune des versions.

Propel 1.4 déjà intégré à symfony

Dec
11

Petite traduction de l’article Propel 1.4 already integrated to symfony tout droit venu du blog officiel de Propel par François Zaninotto. À noter que ce billet n’est plus d’actualité à l’heure où j’effectue cette traduction…

La dernière version de Propel n’a que quelque jours mais fait déjà parti du framework symfony. Symfony 1.3, qui est toujours en version beta, prends en compte les nouvelles fonctionnalités apportées par Propel 1.4 au sein même du framework.

Le plugin sfPropelPlugin qui implémente les fonctionnalités de l’ORM au framework a été partiellement réécrit afin de prendre en compte les nouveaux behaviors plutôt que des générateurs “fait maison”. Si vous souhaitez écrire vous-même des behaviors pour Propel 1.4, le code du sfPropelPlugin est sans aucun doute un très bon exemple de la façon de procéder. Il permet de rendre les fonctionnalités ajoutées par symfony à l’ORM plus robustes et évolutives.

Le planning de symfony prévoit une sortie de la version 1.3 stable pour fin Novembre. Que vous souhaitiez débuter un nouveau projet ou faire une mise à jour, Propel 1.4 peut déjà être l’ORM de votre choix.

Merci à Kris Wallsmith et Fabian Lange, de la core team symfony, pour leur travail rapide et méticuleux concernant l’intégration de Propel à symfony!

Le sfValidatorPropelUnique dans symfony

Nov
17

Aujourd’hui, j’ai voulu créer un formulaire d’enregistrement d’utilisateur avec une seule entrée possible par personne. Après quelques recherches, je suis tombé sur deux problèmes.

Comme je voulais faire la distinction sur le champs “email_1″, je me suis dit “trop simple, j’vais faire un truc dans ce genre:”

$this->validatorSchema['email_1'] = new sfValidatorAnd(array(
  1.     new sfValidatorEmail(); ,
  2.     new sfValidatorPropelUnique(array(
  3.             'model' => $this->getModelName(),
  4.             'column' => 'email_1'
  5.          ),
  6.          array(
  7.              'invalid' => 'This email address is already assigned to an account.',
  8.          )
  9.     )
  10. ));

Mais… après quelques essais, je suis tombé sur une erreur que je n’avais jamais vue, m’indiquant qu’il fallait l’utiliser en tant que postValidator. Avant que je capte d’où venait le problème, je me suis dit qu’effectivement, c’était encore plus simple que ce que je n’imaginais puisqu’il me fallait tout simplement rajouter ceci dans le champs “email_1″ de mon schema:

  1. index: unique

… Merde… Mais comme je suis carrément 2 cool, voilà la syntaxe correcte à utiliser dans le UserForm.class.php (normalement, il n’y a jamais de raison de l’utiliser si vous avez défini correctement votre schema.yml!) :

$this->validatorSchema->setPostValidator(
  1.             new sfValidatorPropelUnique(array(
  2.                 'model' => 'User',
  3.                 'column' => array('email_1')
  4.             ),
  5.             array(
  6.                 'invalid' => 'Un compte est déjà enregistré avec cette adresse.',
  7.             )
  8.         ));

Encore une fois, merci symfony de nous éviter autant d’emmerdes !

La version stable de Propel 1.4.0 est là

Nov
8

La version stable de Propel 1.4.0 a eu lieu aujourd’hui même. Aussi, à cette occasion, un blog rédigé en anglais vient de faire son apparition: le blog officiel de Propel.

Voici donc une petite traduction de l’annonce officielle faite un peu plus tôt.

Propel 1.4 est sorti. C’est splendide, il est aussi rapide que la version précédente (certains diront plus rapide), apporte un nombre important de nouvelles fonctionnalités, totalement compatible avec la version précédente. Si vous utilisez Propel 1.3, vous n’avez aucune raison de ne pas procéder à la mise à jour, vous rateriez quelque chose !

Pour le détail des nouvelles fonctionnalités qu’apporte Propel 1.4, allez jeter un oeil sur mon article “Quoi d’neuf dans Propel 1.4 ?” (ou sur la documentation officielle “What’s new in Propel 1.4 ?”). Des behaviors aux Joins avec plusieurs conditions en passant par des améliorations au niveau du processus d’introspection, vous n’imaginez pas tout ce qui a pu être implémenté dans cette version en seulement 2 mois. Il est vrai que le développement de Propel 1.4 a débuté début Septembre 2009 et pourtant, est déjà là dans sa version stable. Vous pourrez noter que la documentation a été retravaillée et partiellement réécrite afin de faciliter l’utilisation quotidienne de Propel.

Pour installer cette version, vous pouvez effectuer un checkout ou updater vos externals vers le tag 1.4.0 dans le repository subversion:

  1. svn checkout http://svn.phpdb.org/propel/tags/1.4.0 propel_1.4

Autre alternative, vous pouvez installer les packages PEAR:

  1. pear install phpdb/propel_generator-1.4.0
  2. pear install phpdb/propel_runtime-1.4.0

Ensuite, il ne vous reste plus qu’à regénérer vos modèles sans avoir besoin de retoucher votre code existant.

Maitenant que Propel 1.4 est là, nous avons besoin de vous pour ébruiter cette information. Si vous utilisez Propel, n’hésitez pas à faire savoir à quel point Propel est rapide et à quel point son développement est actif. Et si vous aimez les nouvelles fonctionnalités, merci de les utiliser dans vos tutoriaux et vos projets opensource afin d’en faire une vitrine pour l’ORM Propel.

La prochaine version “rétro-compatible”, nommée 1.5, est prévue pour le début 2010 et inclut déjà un nouveau behavior. Pensez donc à garder un oeil sur le blog officiel — ou celui-ci! — afin d’être informés de l’avancement de cette version ainsi que des nouveaux ajouts.

Quoi d’neuf dans Propel 1.4 ?

Oct
13

Propel 1.4
Read more »

Intégrer WordPress dans une application symfony – Part 1

Aug
3

Le client: “Alors on voudrait un site e-commerce avec [... *utilisation de symfony envisagée*] et il faudrait aussi y intégrer un blog WordPress
- Obligatoirement WordPress?!
- Oui, oui”

En avant Guingamp, nous voilà parti à l’aventure!
Read more »