Maxime’s blog

Bootstrap sous Zend Framework

Il existe un paquet d'exemples expliquant comment créer un fichier de bootstrap pour le Zend Framework. En revanche, je n'en ai croisé aucun présentant une manière élégante de le faire. Au fil du temps je me suis fait une petite classe en charge du process. Cette classe, que j'ai appelée App, permet de modulariser le bootstrap. J'ai par exemple créé les modules config, router et dispatch. Le premier charge la config, le deuxième le router et le dernier exécute le dispatch du front controller. Dans le fichier index.php, il ne me reste plus qu'a charger ces trois modules. Ce qui donne: 
1 App::load(array('config', 'router', 'dispatch'));
Il faut avant cela définir le dossier où sont stocké ces modules: 
1 App::setBootstrapDirectory('../bootstrap');
Le fichier index.php ne contient donc plus que quelques lignes (la définition du include path, le require de la classe App et les deux lignes précédentes). Tout le reste se passe dans les modules. La classe App est bien évidemment stockée dans /libraries/App.php. Dans l'exemple précédent, les modules sont stockés dans /bootstrap. Le module config sera par exemple dans /bootstrap/config.php. Les modules sont donc réutilisables d'application en application. Il suffit d'activer ceux nécessaires. On peut même avoir un dossier bootstrap partagé par plusieurs applications! Ci dessous vous trouverez un petit zip avec la classe et un exemple d'utilisation dans index.php. Pour ce qui est des modules, à vous de les imaginer! Il suffit de découper le process de bootstrap classique et on trouve des exemples de celui-ci un peu partout... Télécharger La classe App

Orange SMS API

Pour ceux qui ont testé ronchon.fr vous avez pu constater que l'on peut ronchonner par SMS. Avec un petit budget comme le mien (qui a dit pas de budget?) vous pensez bien que le service que j'utilise est gratuit. Il vaut donc le coup d'être partagé! C'est nos amis de chez Orange Partner qui nous font le plaisir de proposer le SMS API. Toujours en version alpha, la chose est néanmoins tout à fait opérationnelle! Très simple d'utilisation, il suffit de s'inscrire (c'est gratuit) puis de définir un mot clé (à mettre avant le message dans le SMS) et une URL. Celle-ci sera appelée avec deux paramètres GET à la réception d'un SMS. Ces derniers sont from (le numéro de téléphone) et content (le contenu du message). A vous de faire le traitement. Très très simple donc. Vous pouvez aussi rediriger les SMS vers un email. Le service permet aussi d'envoyer des SMS. En revanche, cela devient payant. En fait, ça fonctionne avec un système de crédits. Envoyer un SMS vous coute 10 crédits. En recevoir un vous en rapporte 2. Vous pouvez aussi acheter des crédits supplémentaires. Je n'ai pas tester l'envoi mais cela semble tout aussi simple. Il suffit d'appeler une URL avec le numéro du destinataire, le message et une API key. Très bon service donc. Un grand merci aux gars d'Orange!

Lancement de ronchon.fr

Après trois jours de coding, ronchon.fr est officiellement lancé. ronchon.fr c'est mon nouveau concept: un espace dédié pour râler! Sur le même principe que twitter, les utilisateurs envois leurs ronchonnements sur le site (depuis ce dernier ou par sms) et ceux ci défilent sur la page d'accueil. Je vous laisse le découvrir et j'espère rapidement vous voir inscrit! ;-)

Atomik 1.5 !!

Une nouvelle version dès le lendemain ! Bon je me suis décidé à ajouter les "déclencheurs", appelés "events" (évènements) dans le framework. On peut à peu près "hooké" de partout ! Du coup la plus part des fonctionnalités de base sont devenues des packages (mais qui restent activés par défaut). Le principe est qu'il faut "inscrire" une fonction à un évènement (ces-derniers peuvent être associés à plusieurs fonctions). Lorsque l'évènement sera déclenché, toutes les fonctions associés seront exécutées. Un design plutôt classique. Il n'a a donc pas de fonctions avec des noms pré-définie. Exemple: 
1 events_register('my_event', 'my_function1');
2 events_register('my_event', 'my_function2');
3 events_fire('my_event'); // les deux fonctions précèdentes sont exécutées.
On peut aussi passer des paramètres aux fonctions: 
1 events_fire('my_event', array('param1', 'param2'));
Il y a un paquet d'évènements qui sont déclenchés tout au long de l'exécution. Les packages sont maintenant tous architecturés autour de ce système. Par exemple: 
1 function package_test()
2 {
3     function my_func()
4     {
5         echo 'test';
6     }
7     events_register('core_before_print', 'my_func');
8 }
"test" sera affiché en haut de chaque page. Je vous laisse découvrir la nouvelle architecture des paquets dans le code. Le core lui même s'en trouve fortement réduit ! Comme je l'expliqua dans les commentaires du billet précédent, je ne veux pas qu'Atomik deviennent orienté objet. Ceci sera éventuellement réalisé dans une version distincte. C'est la raison pour laquelle les packages n'utilisent pas de classes. La chose reste donc au plus simple et je pense que le système d'évènements fera l'affaire. Il reste encore du debugage mais ça à l'air de marcher ;-) A propos d'un éventuel site, je devrais m'atteler à la tâche dans la semaine. Il y aura effectivement une section partage de packages (comme l'a proposé cperf3ct mais j'avais la même idée) et des tutos. ++

Nouvelle version d'Atomik

Après la discussion avec jjss dans les commentaires de mon article sur la structure d'un site php, il m'a incité à me relancer sur le développement d'Atomik Framework. Voici donc la nouvelle version 1.4. Quelques modifications!
  • Tout nouveau modèle de configuration
  • Système de package
Il reste surement du debugage à faire. Vous pouvez en découvrir plus dans le header du fichier. Je mettrai à jour la doc sur le site google code dans la semaine. Peut-être ferai-je un site spécifique aussi. Pour toutes questions ou suggestions, à vos commentaires !

un ruby sans sa bague

Ruby c'est le langage à la mode en ce moment. Il a une syntaxe très "belle", très intuitive. Cette dernière et sa nature 100% objet font de lui un langage promu à un bel avenir! Mais il manque toujours sa bague à ce petit "bijou"! Pour qu'un langage soit complet, une super syntaxe ne suffit pas! Il doit-être entouré de tout son petit monde, son écosystème. Et c'est là où je trouve que Ruby accumule les défauts. Tout d'abord dans sa philosophie: "le code est la doc"...je n'adhère pas du tout! Pour qu'un langage soit utilisé par le plus grand nombre, il doit se doter d'une riche documentation. Ruby propose juste un navigateur dans l'API avec les commentaires du code! Et qu'on ne vienne pas me dire, il y a de la doc un peu partout sur le web. Je n'ai pas envie de faire deux heures de recherche juste pour savoir pourquoi une obscure fonction ne se comporte pas comme attendu. Les autres "gros" langages tel que Java, C# (.NET) ou PHP proposent tous une documentation (très) très riche. Deuxième point: leur philisophie "on ne fait rien comme tout le monde"! Je suis d'accord qu'il faille innover et que la syntaxe de Ruby permette des choses assez uniques, cela n'empêche pas pour autant de rester dans les normes. Surtout que leurs tentatives de bouleversements ne sont pas des plus réussies! DOM par exemple. C'est un standard, une API très puissante qui permet une excellente manipulation des arbres XML. Eh bien, chez Ruby on a décidé qu'elle était trop "compliquée". En contre partie on hérite de REXML: une petite librairie qui atteint très vite ses limites et qui se permet même de se comporter différemment que DOM à certains moments! Hallucinant! Enfin, les librairies. Ruby étant plutôt jeune, le nombre de librairies est limité. M'enfin cela reste, je l'espère, un aspect temporaire. Voilà. On peut aussi citer la lenteur de l'interpréteur. La prochaine majeure promet de changer cela. Je trouve aussi que la syntaxe donne une impression un peu bordélique sur de grand projet. Mais c'est surtout les deux premiers points qui m'ont beaucoup dérangés. A mes yeux, Ruby n'est pas encore près pour le monde professionnel. Mais tout ceci n'est que mon impression sur le langage, je ne suis qu'un développeur "débutant" en Ruby!

bien structuré son site en php

J'aaaadoooorrrreee PHP ! Cela fait plusieurs années que j'utilise ce langage et j'en suis fan! Mes premiers pas avec remontent à PHP3...il y a bien longtemps! J'ai toujours été fasciné par sa facilité d'accès : pas de longue mise en place, un nombre conséquent de librairies disponibles et une documentation très bien faite (les gens oublient trop souvent php.net). Malheureusement, ses qualités font aussi ses défauts: beaucoup de sites sont codés "avec les pieds"! Plein de codeurs amateurs se sont attitrés "développeur PHP". Le résultat est qu'un grand nombre d'applications sont mal développées et très difficilement maintenable. Depuis PHP5, le modèle objet apporte une toute nouvelle approche et on peut vraiment appliquer des design patterns et avoir un code bien mieux structuré. Mais même sans PHP5 et sans connaître le modèle objet, il est tout à fait possible de faire des choses très propres. Il est donc temps de s'y mettre! Quand l'on débute en PHP, la structure généralement retenue est la même que pour un site statique sauf que l'on ajoute quelques morceaux de PHP par ci par là pour rendre le tout dynamique. Même si cela pouvait s'avérer tolérable en PHP3 (et je sais de quoi je parle!), ça ne l'est plus du tout avec la version 5. Tout d'abord parce que les possibilités de PHP ont grandement évoluées et deuxièmement parce que la façon de construire des sites en a fait de même. De plus en plus de technologies doivent cohabiter, souvent dans des environnements hétérogènes, et on ne parle plus de site web mais d'application web, ce qui en dit long! Tout le monde ne peux plus s'improviser développeur web et comme tout développeur web qui se respecte le sait, le contenu DOIT être séparé de la présentation. Pas seulement pour rendre le code plus clair, même si ça y contribue sérieusement, mais pour le rendre plus maintenable, plus accessible et plus modulaire. Qu'est ce que j'entends par là? Et bien avez vous déjà travaillé en équipe, du récupérer le projet de quelqu'un d'autre ou tout simplement reprendre l'un de vos sites après un long moment? vous comprendrez... Pourtant, il n'est pas difficile de mettre en place de tels mécanismes. Je me pencherai sur les deux approches que j'utilise: une simple, accessible à tous (pas besoin de OO) ou l'approche MVC, très répandue dans les frameworks.

Read the rest of this post »

web services vs. leurs implémentations

Cela fait un bout de temps que je voulais m'intéresser de plus près aux web services et l'occasion m'en a été donnée lors de mon stage de cet été. L'objectif été de créer une plateforme SOA et nous avons commencé à investiguer pour trouver la solution idéale. Sur le papier, les web services apparaissent comme quelque chose de fantastique. Et ça l'est si l'on regarde les différentes spécifications. Une parfaite utilisation d'XML et des namespaces permettent un nombre inconsidérable de possibilités. Seulement voilà, et vous ne pourrez pas me contre-dire, les spécifications et les implémentations sont rarement les meilleurs amis du monde! Lors de notre enquête, nous avons testé les principaux acteurs open source pour la mise en place d'un serveur sous linux: AXIS pour Java, gSoap pour C/C++, SOAP4R pour ruby, python et PHP. Je ne discuterai pas de python, 1) parce que je ne connais pas le langage et 2) parce que je ne l'ai pas testé, mais on ne m'a pas dit du bien de son implémentation des web services. Nos besoins étaient pourtant simples (!): un maximum d'interropérabilité (WS-I) dans une solution qui s'intègrerait bien à l'existentiel et facile à maintenir!

Read the rest of this post »