Un tel snippet semblera peut-être quelque peu ambitieux pour ceux qui ne jurent que par la programmation impérative. PHP, Java, C++ et consort. C’est pourtant une ligne parfaitement valide en Haskell. Bienvenue dans l’univers de la programmation fonctionnelle. On ne gère plus des changements d’états, mais des évaluations de fonctions.

Des bouquins

C’est un univers que j’avais découvert avec OCaml durant mes classes prépa, et voilà que je replonge dedans. La « faute » à un excellent bouquin, « Hasard et complexité en mathématiques », écrit par Grégory-J Chaitin, le découvreur du nombre oméga « Ω » – mon nombre préféré, mais ce n’est pas le sujet ici.

Dans son ouvrage, Grégory Chaitin avoue son amour sans nom à Lisp, un des plus anciens langages apportant le paradigme de programmation fonctionnelle. Un amour qu’il a ma foi su fort bien communiquer puisqu’il ma donné envie de remettre en questions mes développements actuels.

J’étais assez rebuté par la lisibilité du code en Lisp et après pas mal de lectures auxiliaires, je découvre à quel point Haskell est séduisant autant dans ses concepts que dans sa syntaxe. Gérer des ensembles infinis, ou des nombres à précision potentiellement infinie n’est sans doute pas une situation que tous les développeurs rencontrent tous les jours, mais c’est toujours source de nombreux problèmes dès que le cas fait surface. Ceux qui aiment les problématiques de typage seront ravis d’apprendre que Haskell est, parait-il, muni d’un système de typage à toute épreuve. J’aurai sans doute l’occasion de vous en dire un peu plus une fois mon apprentissage approfondi. Toujours est-il que j’ai commandé au monsieur tout-en-rouge le livre de la collection d’O'Reilly :

Voir sur O’Reilly

Un autre langage, qui fait sans doute plus parler de lui : Scala. Comme OCaml, il est multi-paradigme. Utilisé notamment chez Twitter, LinkedIn, Foursquare ou d’autres grands noms de la toile, on peut sûrement expliquer cette nouvelle popularité par son interopérabilité avec Java. Le langage fonctionne en effet tout aussi bien sous forme de scripts que de bytecode compilé à destination de la JVM, et il est en ce sens possible – et aisé – d’exécuter du code Java depuis Scala. Sans avoir encore trop farfouillé, j’ai tout de même l’impression que l’approche est assez différente de ce qu’on retrouve en Haskell ; j’ai ainsi constaté que beaucoup de codes ne pouvait s’offrir le luxe de faire l’impasse sur le cas des valeurs null. Peut-être du travail à faire du côté des monades ? J’en saurai sûrement davantage après une vraie découverte du langage et une lecture approfondie de cette autre idée cadeau :

Voir sur O’Reilly

Pourquoi quitter le monde impératif ?

Pourquoi un attrait si soudain pour la programmation fonctionnelle ? Pourquoi devriez-vous essayer, à votre tour, de voir autrement vos suites de 0 et de 1 ? En ce qui me concerne, le livre de Grégory Chaitin fut le véritable élément déclencheur, mais c’est aussi le désir de remettre plein de choses en question, de continuer à se maintenir éveillé sur ce qui se fait de nouveau (Scala), et peut-être de reprendre davantage de plaisir à développer en utilisant de nouvelles approches lorsque cela est nécessaire.

Je suis par exemple régulièrement amené à développer de nouveaux outils statistiques (des simples moyennes arithmétiques ou harmoniques aux matrices de covariance) et il n’est pas rare d’observer que le langage fait parfois partie integrante du problème que de la solution, pour reprendre l’expression de certains auteurs : dépassement de capacité des types integer et assimilés ; jonglage fréquent entre types signés, non signés, flottants ; impossibilité de redéfinir l’opérateur « + » dans certains langages, etc.

Je ne sais pas vraiment ce que j’attends de la programmation fonctionnelle dans mon usage quotidien, ou si Haskell sera strictement supérieur à Scala dans mon cas ou s’il sera juste un complément pertinent. Des concepts tels que les flèches me laissent penser que mes systèmes hautement concurrents pourraient s’en retrouver un peu plus concis et formels qu’avec les actuels langages impératifs. Alors, je vous donne rendez-vous pour de prochains billets pour de nouvelles critiques !

Bien connu des développeurs Java, Ant est un build-system, à l’instar des Makefiles, permettant d’automatiser le déploiement d’un projet. Bon nombre de projets PHP ne sont en effet pas directement utilisables tout de suite après récupération des sources, et/ou nécessitent un certain nombre d’adaptation en fonction du serveur sur lequel le projet est déployé. Voire même, parfois, certaines tâches de maintenances assez rébarbatives pourraient être automatisées.

Je ne connais même pas Ant !

Pour ceux qui ne connaissent pas du tout Ant (et je ne parle pas d’un diminutif d’Antoine…), les rouages tournent concrètement grâce à un fichier XML classiquement nommé « build.xml », comprenant une succession de balises du style :

<target name="NOM_REGLE" depends="REGLES À EFFECTUER AUPARAVANT">
     <actions à effectuer ... />
</target>

Une fois ce fichier XML dûment rempli, vos règles s’exécutent par le biais d’une ligne de commande, après bien entendu avoir vérifié qu’Ant était bien installé sur votre machine :
> ant NOM_REGLE

Il y a un certain nombre d’options disponibles, il est par exemple possible d’afficher les règles disponibles et leur rôle respectif via ant -p pour peu que vous ayez renseigné un champ « description » dans le fichier build.xml.

Bon, et pour mon projet, ça sert à quoi ?

Vous manquez d’imagination ? Voici à titre d’exemple la liste de règles que j’ai définie pour Piwam :

• init: Créer les répertoires manquants (log, cache, build…
• cc: Vider le cache
• doc: Générer la documentation Doxygen
• up: Update SVN
• phpcpd: Cherche le code PHP dupliqué au sein du projet
• pdepend: Génère un rapport de dépendance des classes
• phpcs: Vérifie la conformité du code avec une norme donnée
• lint: Vérifie qu’aucun fichier ne contient une erreur de syntaxe
• test: Lance les tests unitaires et fonctionnels
• css: Concatène l’ensemble des fichiers CSS en un seul grand fichier CSS
• css.min: Minimise la taille du gros fichier CSS. (appelle automatiquement la règle css en amont)
• clear: Nettoie les fichiers générés
• build: Lance l’ensemble des tâches permettant de vérifier la qualité du projet

je vous invite à découvrir le fichier XML correspondant sur le dépôt SVN du projet. Ce fichier vous permet alors d’effectuer toute une batterie d’actions de manière extrêmement simplifiée. Ant est utilisé au sein d’une multitude d’outils du monde Java, des IDE (Eclipse…) aux outils d’intégration (Hudson, CruiseControl…). En pratique, ces outils vont aller lire votre fichier build.xml et appeler les commandes correspondant aux tests (dans mon cas : phpcs, pdepend, etc.) de manière 100% automatisée afin de vous permettre de suivre l’évolution de votre projet au fil des révisions.
Sur ce, je vous laisse rédiger votre propre antfile, en attendant de vous présenter comment l’exploiter au sein d’Hudson dans un projet article !

Liens utiles

• http://ant.apache.org : Site officiel de Ant, par la fondation Apache
• http://phing.info : Alternative à Ant spécialement conçue pour les outils PHP. (Basée sur Ant)
• http://hudson-ci.org : Hudson, outil d’intégration continue

Aux débuts de Piwam, les relations décrites dans le fichier schema.yml n’étaient pas nommées explicitement. Du coup, lors de la génération du schmilblick par Propel (Model + SQL), c’est InnoDB qui s’occupait de trouver un nom à ces relations.

Aujourd’hui, j’écris le script permettant de migrer de Piwam 1.1.2 vers Piwam 1.2, script qui nécessite d’effectuer des opérations sur des foreign keys, en l’occurence les supprimer… Comment diable alors faire référence à une clé étrangère dont on ne connait pas le nom ? Après avoir farfouillé partout sur la toile, il apparaît qu’il n’y a pas moult solutions pour arriver à mes fins. On se retrouve ainsi soit à écrire des procédures, soit à faire appel à l’information_schema. Enfin, certains proposent une utilisation de SHOW TABLE avec les arguments qui vont bien, puis parser la sortie pour récupérer les noms des contraintes. J’ai pu par ailleurs découvrir la version Firebird :

SELECT RDB$CONSTRAINT_NAME
FROM RDB$RELATION_CONSTRAINTS
WHERE RDB$CONSTRAINT_NAME LIKE 'FK%' AND
RDB$RELATION_NAME='MATABLEAMOI'
ORDER BY RDB$CONSTRAINT_NAME

Ne pouvant exécuter de requêtes propres à Firebird, ni même de procédures (Piwam tourne sous trop de types de serveurs différents aux configurations et autorisations bien différentes), j’ai finalement opté pour une solution ma foi fort simple. Accrochez-vous, c’est du SQL de très haut niveau (hum…).

CREATE TABLE ma_table_copy AS SELECT * FROM ma_table;

Une copie réalisée de la sorte a pour effet de ne copier que la structure et la table, en omettant indexes et contraintes. Lent, mais portable (je ne sais pas si l’adjectif est vraiment adapté) et pratique. Tout ça pour dire, bordel, une bonne fois pour toutes, n’oubliez pas de nommer vos contraintes explicitement, ça facilite grandement la maintenance !

Aujourd’hui, je vous propose, et vous n’avez pas vraiment le choix, de découvrir la manière dont je teste le déploiement de l’application. Quels sont les pièges, les méthodes, bref, tout.

Virtualiser, c’est la mode.

Je ne possède pas de serveur de test. Et de toute manière, si j’en possédais un, je me servirais tout de même d’un système virtualisé, afin d’éviter d’utiliser inutilement le vrai serveur. Voilà donc le premier point : le déploiement est testé en conditions réelles au sein d’une machine virtuelle. Le système virtualisé est le plus proche possible de celui qui tourne en production : OS, noyau, mémoire disponible, swap, version de PHP, MySQL, fichiers de configuration…

Serveur Debian virtualisé, lancé depuis WindowsXP

Cette précaution permet de s’affranchir au maximum des mauvaises surprises liées à l’environnement. Imaginez un peu, votre système sur lequel vous développez possède le paramètre memory_limit fixé à 128M. Tout fonctionne parfaitement. Sans passer par le scénario de test de déploiement présenté ici, vous décidez de mettre tout de suite à jour la version en production. Tout fonctionne parfaitement. Erreur. Tout semble fonctionner parfaitement. C’était sans compter cet utilisateur qui, voulant lister 100 résultats de recherche par page, obtient une magnifique erreur d’explosion de la mémoire allouée, dont le maximum était fixé à 64M sur le serveur de production.

Quelle solution choisir ?

Les solutions de virtualisation ont le vent en poupe actuellement. Citons VM Ware, VirtualBox, Parallels (MacOSX)… Pour laquelle opter ? Après un essai des différentes solutions, je ne peux que vous conseiller la solution de Sun (Oracle…) : VirtualBox. Disponible sous toutes les plate-formes, gratuite, libre, cette box magique satisfaira toute nos exigences. Une fois installée, installez votre système virtualisé (dans mon cas : Debian 5.0), installez / configurez vos applications (ici : Apache 2, PHP 5.3 + modules, MySQL 5.1, symfony 1.2).

Envoyer ses fichiers au serveur

C’est bien joli d’avoir maintenant une réplique de son serveur de production, mais comment y tester son application ? Plusieurs solutions :

1. Vous recodez intégralement votre projet au sein de votre serveur virtualisé (…)
2. Vous avez pris la bonne habitude d’utiliser un serveur CVS, SVN ou Git. Dans cas là, un commit d’un côté et un update de l’autre fera très bien l’affaire.
3. Vous avez configuré un répertoire partagé sous VirtualBox, accessible aussi bien sous votre système hôte que depuis votre serveur. Placez donc juste l’archive du projet à tester dans ce répertoire.

Et maintenant, je fais quoi ?

Pour résumer, vous possédez maintenant une version à jour de votre application, disponible sur un serveur (virtualisé), réplique parfaite (normalement) du serveur qui l’accueillera. Et bien, rappelez vous pourquoi vous venez de faire toutes ces manipulations : pour tester ! Suivez donc la procédure de déploiement de votre application que vous avez pu décrire au sein de votre documentation. Pour certains projets, il n’y a rien à faire de particulier, le projet est directement fonctionnel, mais pour d’autres, c’est le moment de vérifier que votre documentation, bêtement suivie à la lettre, permet d’arriver à une application qui fonctionne ; quelques exemples en vrac :

• Configuration de l’accès au SGBDR
• Droits en lecture/écriture de certains répertoires
• Mises à jour de fichiers
• Exécution de requêtes pré-requises

Si, une fois, les instructions de la documentation suivies, votre application ne fonctionne pas, c’est qu’il y a bien un problème, lié à la documentation ou à l’application.

Youpi ! Ça fonctionne !

Allons allons, calmons nous. Le déploiement du projet (ou de la mise à jour) fonctionne. Nous ne sommes pas encore en mesure de savoir si le projet fonctionne à 100% comme il devrait. Il vous faut maintenant torturer votre application dans tous les sens afin de déceler les bugs éventuels. Ou alors, et je vais peut-être créer une certaine frustration en m’arrêtant ici, c’est le moment de lancer vos 2000 tests unitaires et fonctionnels, qui vérifieront automatiquement le bon fonctionnement de votre application sur le système courant.

Virtualiser, encore +

Il est fort possible que votre application ne soit pas destinée à une plate-forme en particulier mais  à être déployée sur un grand nombre de serveurs très différents, aux versions et configurations de PHP différentes. Vous pouvez alors virtualiser d’autres OS, aux configurations différentes. Ou vous pouvez pousser la virtualisation encore plus loin en optant pour VServer. Une fois VServer installé sur votre serveur de test, vous serez en mesure d’isoler parfaitement différents « sous-environnements » différents et de switcher d’une configuration à une autre extrêmement facilement, rapidement, et de manière très fiable, sécurisée parfaitement isolée.

En bref :

1. Installez VirtualBox
2. Virtualisez l’OS de votre choix
3. Configurez cet OS virtualisé
4. Testez, lancez vos tests

On regrette très vite de ne pas tester son application. Pendant les différentes phases du développement, il est on ne peut plus utile d’avoir un aperçu fidèle à la réalité de la qualité du produit qu’on s’apprête à délivrer.

Tests unitaires, tests fonctionnels. tests de déploiement, tests de non-régression… la batterie n’est pas mince, et automatiser un maximum de tâche s’avère payant.

La raison d’exister de cette nouvelle série d’article ne vas pas être de vous présenter une énième fois des cours théoriques sur les méthodologies de tests, mais de faire le point sur certaines problématiques, et d’apporter un élément de réponse parmi tant d’autres : le mien.

Vous retrouverez donc dès la rentrée une série d’articles sur cette passionnante thématique, permettant à chacun d’améliorer :

• sa productivité
• la qualité de son travail
• ses habitudes de développement

Le premier article est prévu pour la fin du mois, avec un case-study sur la manière dont je teste le déploiement de Piwam.

PS : Vous noterez les images très très drôles qui accompagneront dorénavant les articles dans la mesure du possible.

C’est aujourd’hui que je viens d’achever ma première application Flex. Flex ? Kézako ? Pour ceux qui ne connaîtraient pas du tout ce terme, Flex est une technologie développée par Adobe, basée sur ActionScript. Flex permet de mettre en place facilement des RIA (application avec interface riche) et, nous le verrons, c’est dans ce domaine qu’il excelle. Concrètement, une fois votre projet Flex compilé vous obtenez une application exécutable au sein d’un player Flash (ou très facilement en tant qu’application desktop grâce à Adobe Air). Des exemples d’utilisation de Flex :

• Un explorateur de styles
• Plein de samples sur les possibilités offertes
• Applications professionnelles

PureMVC est un framework MVC à l’origine mis en place pour ActionScript, qui depuis a été porté pour différentes plate-formes : PHP, ColdFusion, Java…

• Exemples d’utilisations de PureMVC

AmfPHP est une implémentation PHP de Action Message Format (AMF). AmfPHP permet ainsi une communication entre votre application Flex et un service écrit en PHP.

• Exemples d’utilisations d’AmfPHP

Maintenant que les présentations sont faites, l’heure des comptes est venue. Je viens de réaliser un gestionnaire de quizz. Mon application permet de gérer des listes de questionnaires, d’y ajouter des questions, réponses, images d’illustration… puis de « jouer » à ces questionnaires. L’application Flex, développée autour de PureMVC, appelle donc sans cesse mon script PHP s’occupant d’interagir avec MySQL pour enregistrer une nouvelle question, récupérer la liste des quizz, etc.

Ce que je retiens au final, c’est :

Une mise en place très rapide. L’installation de Flex Builder (l’IDE est basé sur Eclipse, disponible par ailleurs directement sous forme de plug-in),  de PureMVC et d’AmfPHP est très rapide, sans mauvaise surprise. La seule surprise était un soucis de fonctionnement du plugin Flex Builder avec Eclipse 3.5, qui venait juste de sortir à ce moment là. On excusera donc Adobe. Attention toutefois, Flex Builder n’est PAS gratuit, sauf pour les étudiants (licence sur simple demande).

L’apprentissage de Flex est assez rapide, l’IDE aidant. Le bon lot de composants existant permet de concevoir visuellement ses interfaces en Wysiwyg. Un des concepts à bien maitriser pour bien positionner ses éléments est celui des layouts assurant la mise en place des éléments, concept qu’on retrouve déjà dans pas mal d’autres technos. On apprend très vite à apprécier une propriété, [Bindable], permettant de lier constamment des éléments et valeurs. Le thème de base lassera très vite celui qui connaît bien la technologie mais est tout de même très agréable à l’oeil. Les composants sont immédiatement exploitables pour une vraie application, il y a même un système de barre de chargement lancée automatiquement au chargement votre interface.

PureMVC, quant à lui, nécessite une phase un peu plus longue d’apprentissage. Les notifications sont utilisées à outrance, ce qui autorise le développeur à commettre les pires goritudes dans son code. Les différentes couches (modèle, vue, contrôleur) communiquement efficacement entre elles, mais dans le cadre d’un développement en équipe, il faut bien veiller à ce que chacun aie les même habitudes que son collègue. Autrement, c’est l’anarchie chez les notifications.

En ce qui concerne AmfPHP, c’est quasiment que du bonheur.  Ça fonctionne très vite, très bien, il est vraiment aisé et rapide de transmettre des objets, des tableaux, du XML entre Flex et PHP.

À noter, une communauté vraiment active, et une documentation que je considère « correcte », qui manque peut être d’exemples. Au final, cette première expérience avec Flex, AmfPHP et PureMVC est plutôt concluante. Flex est à ce jour une solution qui commence à devenir assez mature. À retenir pour la réalisation d’interfaces homme-machine, de backoffices ou applications mettant en oeuvre génération de graphiques, saisie de données…

N’oubliez pas de visiter les démonstrations !

Sismo est un outil d’intégration continue développé par Sensio Labs (vous savez, symfony…). L’intégration continue, c’est la possibilité de détecter tout ce qui ne va pas au fil des versions. Du vert ou du rouge, ça passe ou ça ne passe pas, Sismo présente une interface très simple permettant de contrôler le comportement de ses projets au fil des releases. Fabien Potencier a annoncé sur le groupe de discussion « symfony developers« , une éventuelle disponibilité de ce projet libre à la fin du mois de juin.

Une démonstration en ligne du produit est disponible sur http://ci.symfony-project.org. Hâte d’essayer cette alternative à Xinc et consorts.

Dans les grandes lignes, on retrouve :

• Le trunk est toujours laissé dans une qualité de beta
• Les GA sortiront tous les 12 à 18 mois
• Pas plus de 2 releases avec un support actif
• Les milestones commencent lors de beta (jamais lors d’alpha) par un merge entre le trunk et le stage tree.

Pourquoi cet article ? Pas seulement pour relayer l’actualité MySQL, mais aussi pour tenter de sensibiliser un maximum de lecteurs sur l’importance d’un modèle de release adapté. Pour un logiciel prétendant à un minimum d’évolutions et d’activité, il est capital de trouver un compromis entre ce que je nommerai la rétro-utilisabilité et la publication des nouvelles versions. J’entends par « rétro-utilisabilité » le fait d’assurer aux utilisateurs des versions passées un support, un moyen de passer aux versions supérieures efficacement.

Source : Planet MySQL (En)