Digital Fashion - environnement

Linux + gVim + Rox-filer = Mon IDE.

Geoffrey — Tue, 28 Nov 2006 22:39:00 +0100

Une des questions cruciales qui se pose à tout développeur à au moins un moment de sa vie (souvent plusieurs en fait) est le choix d'un environnement de développement. J'en ai testé pas mal, plus ou moins longtemps, et bien que je ne sois jamais complètement satisfait, l'idée de perdre du temps à développer le mien m'indispose. J'ai donc opté pour l'environnement qui me va le mieux: Linux + gVim + Rox-filer.

Note: je ne couvre pas ici les fonctionnalités de débuging avancé, que je n'utilise pas encore, mais pour lesquelles j'ai déjà en tête des solutions qui me conviendront bien mieux que les outils intégrés à un quelconque IDE (je pense fortement à Xdebug).

Comment définir un IDE ?

Commençons par le début: qu'est-ce qu'un IDE ? Acronyme de Integrated Development Environment, le terme peut prendre pas mal de signification selon la personne à laquelle on s'adresse. Pour certains, le plus c'est le mieux, alors que pour d'autre, le moins c'est le pas plus mal finalement. On pourra citer quelques exemples connus d'IDE full-featured, tels que les incournables Zend Studio, Eclipse et autres phpEdit, mais ce n'est pas le but de cet article. Ici, je vais vous expliquer pourquoi et comment j'utilise quotidiennement gVim et Rox-filer, et le tout sous Ubuntu.

Revenons en à nos moutons, un environnement de développement, c'est constitué de quelques briques primordiales:

Un éditeur de code
Un navigateur de fichier
Un truc qui fait tourner tout ça

Peu importe qu'ils soient intégrés ou non, finalement. Personnellement, je suis un fervent adepte du précepte une tâche, un outil, donc je preferre qu'ils soient dissociés.

L'éditeur de code: gVim

Certains perdent leurs moyens à la simple évocation de son nom, vim n'est pourtant rien de plus que le plus puissant des éditeurs de fichier aujourd'hui disponible dans le monde (un troll s'est malicieusement glissé dans cette affirmation, saurez-vous le retrouver ?). Ce qui déroute au premier abord dans vim, c'est finalement ce qui fait toute sa puissance: le mode commande. J'ai longtemps utilisé bluefish, et finalement las de ses quelques bugs bien énervants (wtf syntax color ?), j'ai décidé de faire le grand pas, et d'utiliser vim. J'avais bien sur déjà une expérience de cet éditeur, mais retenez bien que le meilleur moyen de maitriser un outil aussi puissant que vim, ce n'est pas de se jeter à corps perdu dans la doc, mais c'est d'investir du temps incrémentiellement: commencer à utiliser vim, et quand on souhaite faire quelque chose qu'on ne sait pas faire, lire la doc correspondante^[1]. Pour finir, j'ai traduit il y a quelque temps un excellent tutoriel sur vim: L'édition efficace avec vim, donc n'hésitez pas.

Un .vimrc qu'il est joli

Comme la plupart des applications *nix, vim autorise l'utilisation d'un fichier ~/.vimrc. S'il peut paraitre compliqué au premier abord d'élaborer un .vimrc efficace, il ne faut pas se décourager, car comme d'habitude, il y a tout ce qu'il faut sur le net. J'en veux pour preuve les excellents articles de Tobias Schlitt à ce sujet.

Pour info, quelques directives de configuration utiles qu'on peut trouver dans mon .vimrc:

" Supprime un buffer de la mémoire via le raccourci clavier Ctrl+W
noremap <C-W> :bdel!<CR>

" Active l'indentation automatique
set autoindent

" Active les plugins de type de fichier
filetype plugin on

" Active la coloration syntaxique
syntax on

" Thème de couleur pour gVim
colorscheme desert

" Utiliser des tabs de 4 caractères pour l'indentation
set noexpandtab tabstop=4 shiftwidth=4

" Activer la souris (molette, sélection, etc)
set mouse=a

" Afficher des infos dans la barre de status
set ruler
set laststatus=2

" Activer la numérotation des lignes
set number

" Utiliser la recherche incrémentielle
set incsearch

" Ne pas surligner les résultats de recherche
set nohlsearch

Quelques unes (beaucoup en fait) de ces directives sont tirées du .vimrc de Tobias.

Dernier détail pour les réfractaires de la ligne de commande, gVim s'execute en mode graphique, avec une interface GTK conviviale qui permet d'apprendre les raccourcis aisément, et qui gère la souris (défilement à la molette, etc, et d'ailleurs, même en console ça gère la souris, il suffit d'un :set mouse="a" pour l'activer).

Un ftplugin pour le PHP

Ce qu'on appelle ftplugin dans vim permet de configurer vim en fonction du type de fichier que l'on édite. Tobias fournit un ftplugin spécialisé dans l'édition du PHP plutôt bien foutu, qui gère la plupart des features convi-enabled des soit disants IDE évolués:

Complétion des fonctions
Complétion des mots-clés
Auto-fermeture des crochets, parenthèses, etc.
Auto-génération des docblocks PHPDoc
Vérification de syntaxe du fichier édité
Et d'autres trucs merveilleux !

La classe non ?

Un navigateur de fichier kirox (tm)

C'est pas moi qui le dit, en fait c'est comme le port-salut, rox-filer rox, c'est tout. Pour ceux que ma puissance de persuasion ne suffit pas, et bien rox-filer offre tout ce que vous pourriez attendre d'un gestionnaire de fichier moderne:

Navigation spatiale avec technologie oupas (tm)
Prévisualisation des images
Personnalisation (aisée !) des applications utilisées pour lancer les fichiers (en fonction du mimetype)
Navigation one-click (oupas (tm))
Navigation aisée au clavier
Monitorage des fichiers en cours d'utilisation (ils apparaissent en gras, ce qui est pratique).
Et j'en passe et des meilleurs.

Bref, il fait tout ce que ferait un filebrowser intégré, mais en mieux, puisqu'il est dédié dès le début à cette tache. Afin de le faire interragir au mieux avec gVim, j'utilise la Run action suivante sur le mimetype text/*:

gvim --servername ash0 --remote-silent-tab "$@"

Qui permet d'ouvrir le fichier dans un nouveau tab de vim, en créant une instance d'un server vim à la volée si il n'existe pas déjà (ici le server s'appelle ash0, mais vous pouvez bien évidemment en changer le nom).

Une distribution du bien: Ubuntu

Et parcequ'il faut bien faire tourner tout ça, j'utilise un système d'exploitation du bien (tm): GNU/Linux. Mais comme j'ai la flemme, j'utilise une configuration convi-enabled: Ubuntu. Pas besoin de s'étaler je pense, Ubuntu c'est bien, tout le monde en conviendra.

Un window-manager léger et puissant: fluxbox

Le choix du gestionnaire de fenêtre peut par contre préter a controverse. En effet, c'est ici avant tout une question de gout et de puissance de machine. J'ai personellement un penchant pour les logiciels puissants et légers. Là je vous vois venir avec vos gros sabots: tout le monde veut ce genre de logiciel. Et bien j'ai envie de répondre que non. La majorité des neo-geeks de la génération Ubuntu s'en donnent à coeur joie sous Gnome et/ou KDE, qui est loin de ce qu'il convient d'appeler un logiciel puissant et léger, sous prétexte que les autres WM (à part KDE), saitrocomplicai. Bon là ok, j'amalgame surement un peu (beaucoup même, tous les gens sous Gnome ne sont pas des neo-geek, et l'inverse également), mais il manquait un peu de trollitude dans cet article. Bref, quand on veut, on peut, et comme les gens ne switchent pas de Gnome à un WM plus puissant et plus léger, j'en conclus (peut-être à tord hein) qu'ils ne veulent pas.

Tout ça pour dire que j'utilise fluxbox, et ce depuis ma plus tendre enfance. Fluxbox est léger (osez prétendre le contraire...) et puissant: il permet:

de reconfigurer l'intégralité du comportement de vos fenêtres
une gestion fine et puissante des raccourcis claviers (j'ai pu reconfigurer les touches convi de mon clavier convi en quelques minutes dans mon .fluxbox/keys grâce à xev).
de controler facilement quelles applications se lancent au démarrage
de controler encore plus facilement sur quels bureaux se lancent les sus-citées applications

Par exemple, mon .fluxbox/startup démarre sur le premier bureau quelques terminaux, un gaim et un exaile; sur le deuxième bureau un firefox sur le troisième bureau: sylphee, et sur le quatrième bureau, un rox-filer. A coté de ça, je dispose de raccourcis claviers conviviaux pour lancer mes logiciels favoris: le terminal (Mod4^[2]+e), rox-filer (Mod4+r), etc. J'ai également à ma disposition des raccourcis claviers pour gérer mes fenêtres: maximiser (horizontalement (Ctrl+Alt+H), verticalement -Ctrl+Alt+V), ou les deux (Ctrl+Alt+M)), enrouler (Mod4+S), sticker (Ctrl+Alt+S), enlever les décorations (Ctrl+Alt+T), et j'en passe.

Enfin, et le plus important pour moi, fluxbox est non-intrusif. Par défaut, un bureau standard de mon fluxbox ne contient rien. Pas de barre des taches, pas d'icones, pas de menu, rien. Question de gout je vous l'accorde, mais là encore, notez que "c'est faisable": fluxbox ne vous impose rien, et surtout pas les choix discutables car subjectifs des développeurs.

Subversion en ligne de commande

Enfin, j'utilise le client subversion en ligne de commande. D'une part parceque je ne connais pas de client digne de ce nom en GTK (ma religion m'interdit d'utiliser Qt), d'autre part pour profiter pleinement de la puissance qu'offre un shell quand on sait un minimum s'en servir. Pouvoir passer mes commandes svn dans des awk, sed, et autres grep (surtout grep en fait), ça n'a pas de prix, et je pense vraiment qu'aucune interface graphique n'arrivera jamais à la cheville de la puissance d'un shell.

Deuxième avantage à utiliser svn en ligne de commande: le jour où je serais obligé de le faire, je saurais le faire.

Conclusion

Voilà, vous savez (presque) tout de mes habitudes de travail (il reste pas mal de domaines à couvrir quand même, je n'ai pas parlé par exemple de mes extensions firefox favorites, ni de mon utilisation intensive de trac, et encore moins des tests unitaires, peut-être une prochaine fois), et j'espère vous avoir donné l'envie de regarder d'un peu plus près ces outils à la réputation peut-être un peu geek, mais d'une puissance incomparable une fois maitrisés :-)

Notes

[1] :help commande est en général d'une grande utilité

[2] Le petit nom de la touche Windows

Discussion sur l'optimisation en PHP chez NiKo

Geoffrey — Thu, 23 Nov 2006 13:40:00 +0100

Une petite discussion sur l'optimisation en PHP à lieu en ce moment chez NiKo ! Ce n'est pas souvent que je link directement comme ça, donc dites vous que quand je le fais, c'est que ça en vaut la peine ;-)

L'environnement d'execution

Geoffrey — Thu, 12 Oct 2006 21:51:00 +0200

Voilà un article que j'avais déjà proposé sur un site a caractère privé, un peu remis au gout du jour et étoffé de quelques informations et ressources non négligeables. Nous verrons ici comment mettre en place un environement d'execution standard du Zend Framework, également appelé bootstrap de l'autre coté de l'atlantique.

Un petit dessin valant mieux qu'un long discours, entrons dans le vif du sujet. On assume ici un environnement préinstallé: Apache / PHP5 / MySQL, avec une copie du Zend Framework dans /usr/share/zend/, ainsi que le .htaccess suivant à la racine de votre site (il semblerait que cette dépendance à mod_rewrite soit sur la liste des choses à éliminer avant la release):

RewriteEnfine On
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php

On peut également utiliser les règles suivantes, qui comportent l'avantage d'une plus grande simplicité pour intégrer des éléments d'application externe:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php

L'environnement

Les plus perspicaces d'entre vous l'auront surement déjà deviné, le fichier www/index.php servira de bootstrap, c'est à dire de point d'entrée unique pour toute l'application. Le Zend Framework se chargera lui même de décortiquer l'URL pour tenter de deviner ce à quoi l'utilisateur pouvait bien penser quand il a cliqué !

Pour ce qui est de l'arborescence de fichiers conseillée, un peu d'organisation est recommandée.

Pour utiliser le Zend Framework en toute quiétude, il nous faut nous assurer qu'il pourra accéder à ses propres composants. La première chose à faire est donc de modifier l'include_path:

set_include_path(get_include_path().PATH_SEPARATOR.realpath(dirname(__FILE__).'/../library/'));

Il n'est pas inutile également de prendre quelques précautions d'usage:

ini_set('error_reporting', E_ALL); # | E_STRICT);

if (get_magic_quotes_gpc()) {
	die('<strong>E_NOOB_ERROR</strong>: magic_quotes_gpc must be turned off.');
}

set_magic_quotes_runtime(false);

Last but not least, on charge la librairie Zend:

require_once 'Zend.php';

Ainsi préparés, nous pouvons nous plonger en toute quiétude dans la mise en place de quelques objets qui nous serons bien utiles tout au long du développement de notre application.

Les objets

La mise en place des objets est on ne peut plus claire. On configure le front controller (Zend_Controller_Front) pour lui dire où trouver les controllers, puis on configure les vues (Zend_View) pour leur dire où trouver... les vues :-) On enregistre ensuite l'objet $view dans le registre, qui n'est rien de plus qu'un endroit pratique où stocker des objets/données pour y avoir accès plus tard (Zend::register($name, $value) et $var = Zend::registry($name);).

Une petite liste (non exhaustive) d'objets interressants à stocker dans le registre:

Zend_Db

Zend::loadClass('Zend_Db');
Zend::loadClass('Zend_Db_Table');

$params = array(
	'host' => 'localhost',
	'username' => 'someobscureusername',
	'password' => 'someobscurepassword',
	'dbname' => 'yourdbname'
);

$db = Zend_Db::factory('PDO_MYSQL',$params);
Zend_Db_Table::setDefaultAdapter($db);

Zend::register('db', $db);

Zend_Config

Je vous renvois à mon article sur la gestion de la configuration :-)

Zend_View

Zend::loadClass('Zend_View');

$view = new Zend_View;
$view->setScriptPath(realpath(dirname(__FILE__).'/../app/views/'));

Zend::register('view', $view);

Le Dispatch

Dernière étape, le dispatch, qui utilise les objets Zend_Controller_Router et Zend_Controller_Dispatcher. Ces deux objets sont au coeur du processus de sélection du controller à executer. Le Router va déterminer, à partir de l'environnement (en général l'URL, via $_SERVER['REQUEST_URI'] par exemple) quelle action executer et dans quel controller, tandis que le Dispatcher va s'occuper lui de les trouver (par exemple dire FooController::bar(), dans controllers/FooController.php).

Le Zend Framework gère en natif les friendly urls, et ça c'est chouette. Par exemple: les urls suivantes:

http://example.com/foo/bar
http://example.com/foo
http://example.com/

Seront analysées comme suit par le Routeur par défaut:

controller: foo, action: bar
controller: foo, action: index
controller: index, action: index

Dernières choses à savoir sur la théorie:

quand le controlleur est défini par l'url mais non trouvé par le Dispatcher, celui ci execute index/noRoute.
les controllers sont des classes qui étendent Zend_Controller_Action (ou une classe qui elle même l'étend)
le Dispatcher par défaut va executer(en supposant une url type http://example.org/foo/bar) FooController::barAction dans FooController.php (modulo le path déterminé avec Zend_Controller_Front::setControllerPath)

Les vues

Dernier point de cette brève excursion dans le Zend Framework, les vues. Pas grand chose à en dire pour le moment, si ce n'est que par défaut l'objet Zend_View se contente d'include() les fichiers templates. Il parait que l'intégration avec des moteurs de template (Smarty par exemple) est très aisée, mais comme je ne suis pas fan de ce genre de choses, ce ne sera pas couvert ici :-)