Résultats de recherche pour Drupal

Drupal drush : comment ajouter un champ lié à un vocabulaire

La solution est simple mais pas forcément évidente.

Imaginez que vous ayez un vocabulaire « MonDico ».

Dans ce dictionnaire (ou « vocabulaire« , pour reprendre l’expression Drupal), vous avez ajouté plein de mots. Enfin, pas des mots, des « termes« , pour reprendre l’expression Drupal.

Imaginez que vous vouliez créer des champs pour ce « vocabulaire« .

Voici le code qui permet de faire cela :

<?php
$vocabulary = new stdClass();
$vocabulary->name = 'PAA';
$vocabulary->description = 'Paa - Description';
$vocabulary->machine_name = 'paa';
$vocabulary->help = 'Vocabulaire related to Paa';
$vocabulary->nodes = array();
$vocabulary->weight = 0;
taxonomy_vocabulary_save($vocabulary);

$vmn = $vocabulary->machine_name;
$vvid = $vocabulary->vid;
$term = new stdClass();
$term->vid = $vvid;
$term->name = 'MonTerme';
$term->description = 'Description of terme';
$term->format = 'text';
$term->parent = 0;
$term->vocabulary_machine_name = $vmn;
taxonomy_term_save($term);

$field = array(
    'field_name' => 'test_mon_type', 
    'type' => 'text', 
);
field_create_field($field);

// Create the instance on the bundle.
$instance = array(
    'field_name' => 'test_mon_type',
    'entity_type' => 'taxonomy_term',
    'label' => 'Mon nom de champ',
    'bundle' => 'taxonomy', 
    'required' => TRUE,
    'widget' => array(
        'type' => 'textfield',
    ), 
);
field_create_instance($instance);

Rien de plus simple (mais, comme pour toute chose concernant Drupal en général) : encore fallait-il le savoir !

Drupal : comment faire fonctionner la dernière version de CKEditor

Télécharger la dernière version ici : CKEditor Version 4.3.1 – 10 Dec 2013.

Ensuite cherchez dans le répertoire de Drupal, le fichier ckeditor.inc.
Éditez ce fichier et aux alentours de la ligne 77, dans la fonction
vous devriez trouver une ligne qui ressemble fortement à ceci :

while ($max_lines && $line = fgets($library)) {

(A la différence près qu’il ya a un paramètre supplémentaire à fgets();.
Remplacez le code existant par celui qui est ici.

Ensuite 3 à 4 lignes en dessous, il y a un filtre pour chercher la version de ckeditor. Ce filtre n’est plus valide parce qu’il filtrait sur des nombres, mais ils ont ajouté des lettres à la version de CKEditor. Il faut donc le modifier par ce qui suit :

if (preg_match('@version:\"(?:CKEditor )?([\d\.]+)(?:.+revision:\"([\da-z]+))?@', $line, $version)) {

Et tout cela pourrait presque fonctionner, mais il y a quelque chose de très déroutant : même si vous avez suivi tout cela pas à pas, l’éditeur n’affichera pas les « boutons », mais juste une petite ligne : c’est parce que par défaut, rien n’est coché, et donc aucun bouton n’est visible.

Éditez donc les options de l’éditeur et cochez les boutons que vous voulez voir apparaître dans l’éditeur. Personnellement, je coche tout.

Et voilà, vous aurez un éditeur qui s’intègrera parfaitement, de manière agréable, toutes les fois où vous voudrez ajouter du contenu.

Drupal : code pour les liens avec des URLs dynamiques

Drupal : comment s’adapter à une migration si le site n’est plus à la racine ?

Dans les modules, activation du module « Php filter », afin que le code Php soit exécuté.
Et dans le texte qu’il y a dans un bloc « menu », par exemple, vous pourriez vous inspirer d’un code comme celui-ci (sachant qu’il vous faut absolument revoir l’indentation, qui n’est pas acceptable pour un code digne de ce nom) 🙂  :

<?php /* Ce code sert à générer les URLs
 * de manière dynamique, afin que si l'installation
 * Drupal est dans un sous-répertoire, les liens
 * soient "automatiquement" adaptés, via
 * le code "'absolute' => TRUE", 
 */ ?>
<ol>
    <li>
        <?php echo l(t('Menu1'),
            'lien1',
            array( 'absolute' => TRUE, 'query' => array()
        )); ?>
    </li>
    <li>
        <?php echo l(t('Menu2'),
            'lien2',
            array( 'absolute' => TRUE, 'query' => array()
        )); ?>
    </li>
    <li>
        <?php echo l(t('Menu3'),
            'lien3',
            array( 'absolute' => TRUE, 'query' => array()
        )); ?>
    </li>
    <li>
        <?php echo l(t('Menu4'),
            'lien4',
            array( 'absolute' => TRUE, 'query' => array()
        )); ?>
    </li>
</ol>

Symfony 2 : avantages et inconvénients

Après bon nombre de commentaires, voire d’insultes (si si), je résume l’article qui suit :


Vous allez toujours entendre le même discours pour ceux qui commencent avec Symfony et qui n’ont jamais vraiment développé d’autres choses, qui est quelque part logique : Symfony c’est génial, c’est super, c’est la réponse à la vie, l’univers, et au reste, il aurait dû s’appeler « Php – 42 » ou quelque chose comme ça (et si vous ne comprenez pas l’allusion c’est qu’on n’a ni le même background, ni le même humour). C’est, de plus, très souvent le genre de personnes qui n’admettent pas qu’ils n’ont pas d’expérience et cela finit à l’insulte ou au pugilat.

S’ils avaient vraiment pratiqué d’autres choses, il verraient qu’il y a plein d’autres trucs ailleurs, et ils verraient qu’à d’autres endroits il y a des choses mieux.

Ceux qui n’ont pas d’expérience mais l’esprit ouvert me demandent ce qu’il y a comme autres choses à tester, et je leur réponds avec plaisir ! Ceux qui n’ont pas d’expérience et ont besoin de justifier leur existence diront « c’est un gros con il est dépassé il n’y comprend rien ». Je ne donne des cours que pour les premiers. Les autres je les laisse faire alt-tab en permanence entre Facebook et Symfony (et si vous saviez tout ce que je pense quand je parle ainsi…).


Après avoir développé deux applications relativement basiques, voici les inconvénients que j’ai relevé de Symfony :

  • Twig : c’est la seule chose qui semble vraiment pratique, utile et optimisée dans Symfony. A tel point que Zend l’utilisera comme moteur de templates, et Drupal 8 aussi. Un bon point pour Symfony, et le seul. Voici la suite.
  • Symfony prône les bonnes pratiques – ce qui est louable – pourtant j’ai dû faire trois fois du copier coller pour que ça fonctionne… Exemple le plus frappant : la bonne pratique (louable) est de séparer totalement la vue du modèle, et du contrôleur. Mieux : ils ont fait un endroit où on écrit toutes les requêtes complexes, afin de les séparer du modèle : ce sont les Repositories. Problème concret : quand on a un type fichier dans un formulaire qui est envoyé, le type « file » est posté. Si on veut écrire le fichier envoyé, ça passe par un contrôleur, et c’est lui qui est censé l’écrire en base de données ? Non ! Donc c’est côté de la base de données, côté modèle donc. Mais… les entités ne peuvent pas accéder à leur propre repository ! Si vous vous retrouvez dans ce cadre (hypra courant) alors vous allez devoir bidouiller, et créer une fonction statique qui renvoie le manager d’entités et demander à ce dernier de récupérer le repository de la classe en cours. Véridique. Bidouillage, bidouillage, bidouillage. Pourtant, j’insiste : Symfony prône les bonnes pratiques et essaie de faire au mieux, mais il échoue assez… attendez je cherche le qualificatif exact… j’ai trouvé : il échoue lamentablement.
  • Je pensais gagner du temps avec le bundle FOSUser. Faux ! En théorie il est censé simplifier la vie à mort et faire gagner énormément de temps. En pratique, c’est comme Symfony, il va vous falloir entrer dans son coeur, comprendre comment il a été écrit afin de pouvoir vous en servir. Exemple concret là aussi : il n’est fait que pour un seul type d’utilisateurs. Si on en veut plusieurs, il va vous falloir installer un bundle supplémentaire : le PUGXMultiUserBundle. Quelques heures plus tard après l’installation et la configuration, on m’a demandé de créer un rôle modérateur, qui doit pouvoir valider les fiches d’inscription, c’est à dire pouvoir afficher n’importe quelle fiche. Je ne peux même pas vous expliquer comment faire, car j’ai demandé aux experts Symfony – ce sont des personnes qui m’ont sous-traité le second travail que j’ai fait sur Symfony, de le faire eux même parce que je n’en pouvais plus de perdre autant de temps inutilement. J’ai beau chercher, mais un bon développeur Php va perdre beaucoup plus de temps à rechercher tout ça, installer, comprendre le fonctionnement, copier coller puis modifier le code, plutôt que de le faire direct à la main, avec des variables dans $_SERVER pour suivre quelques infos.
  • Symfony et le redimensionnement d’images. Je voulais juste, une fois qu’une image est arrivée en base de données, créer une vignette de cette dernière, afin de pouvoir l’afficher plus rapidement. J’ai donc cherché et voici le résultat – vous noterez bien qu’il est affligeant si on veut simplement redimensionner une image : en théorie  :
    • il faudrait mettre en place un service,
    • à partir de ce service, aller chercher des informations,
    • mettre en place toute une configuration, avec un système de hook (les « écouteurs »)

    … bref, refaire des milliers de choses d’une inutilité absolument affligeante, tout ça pour faire un simple resize. Après avoir passé plusieurs heures à installer le LiipImagineBundle : et m’être aperçu que pour faire un resize, il fallait déclarer vouloir utiliser un service dans ‘app/config/config.yml’, je vois qu’il y a un exemple qui est censé fonctionner sur stackoverflow ici. Et puis là le code qui fonctionne utilise getRequest(). Et le container. Moi j’en avais besoin dans l’entité, car c’est ici qu’on écrit les informations en base de données. Pour pouvoir accéder à un container dans une entité, il faut faire un méga hack, ou pire (lire les deux réponses ici). La seule réponse viable c’et de.. créer un service ! Non mais allô quoi ! Juste pour un crop ! Vraiment on est en plein délire. Hop, top chrono : google =» php imageresize, copier coller, et en moins de 5 minutes, tout fonctionnait. Symfony clame haut et fort qu’il vous fait gagner des heures de boulot ? C’est une blague, une grosse blague ! Posez les pieds sur terre, voici la réalité concrète du terrain : Symfony essaie de pousser encore et encore l’abstraction à son maximum mais on arrive à des non-sens comme celui-là : une entité qui appelle deux services différents, surchargés à mort, des centaines de lignes de code totalement inutiles, juste pour faire un resize. C’est tellement grossier comme problème qu’on en arriverait presque à croire que c’est faux… mais c’est vrai, et les liens que j’ai mis sont bien là pour le prouver.

  • Doctrine est quelque chose… que je ne comprends pas. Il a été crée pour « optimiser » les requêtes. Déjà, rien que d’écrire ça, c’est inévitablement un non sens : on n’optimise pas les requêtes via du Php… À moins que je ne me trompe, on n’a jamais besoin d’optimiser les requêtes à ce niveau ! L’optimisation et la mise en cache doit se faire au niveau du moteur de bases de données. Pourtant, là, on doit écrire du SQL, mais pas vraiment. Olivier arrête de dire n’importe quoi me direz vous. Pourtant ça n’est pas une blague, lisez tout ça ici. Tout y est expliqué : ils ont « surchargé » l’écriture de requêtes, afin de… pouvoir optimiser les requête et mieux faire du cache. Si si. Et ils ont même inventé un concept super novateur, que personne ne connaissait avant (grincement de dents cynique), j’ai nommé : l’hydratation (ou en anglais : « hydration »). Non non, j’insiste, arrêtez de rigoler, c’est pas une blague, ils prennent ça très au sérieux là bas, regardez sur la documentation officielle et cherchez « hydration ». Par contre pour bosser il faut absolument savoir ce que ce mot d’une débilité profonde – au sens informatique – signifie : j’ai mené un entretien d’embauche avec une personne (qui se disait expert), et comme je n’ai pas parlé d’hydratation des données, ça ne lui a pas plu. Bon quand je dis « expert », il faut dire qu’il s’était fait dégager à grands coups de pieds au derrière par sa précédente boîte… j’arrête là je vais être méchant 😉
  • Avec Doctrine, on se prend tout le temps la tête sur les requêtes, ce qui fait qu’au final, comme jamais rien ne fonctionne comme on voudrait avec Doctrine, on se retrouve à vouloir connaitre quelle est la vraie requête faite en base. Voir ici. Réponse officielle : on ne peut pas. On ne peut pas voir les requêtes qui sont envoyées au moteur de base de données. Mais si continuez de lire, arrêtez de pleurer de rire ! Allez vous chercher un mouchoir, essuyez-vous les yeux et revenez.
  • Doctrine est censé simplifier la vie en proposant un modèle d’héritage. Exemple de ce que j’ai réalisé : une personne est la classe de base, et de là descendent les professeurs et les étudiants. Pourtant il est lourd. Très lourd. Très (très³²) lourd. Tellement lourd, que même sur la documentation officielle ils reconnaissent que Doctrine est lourd. La preuve sur la documentation officielle. En fait il est censé simplifier la vie du développeur, mais avec Doctrine il faut une machine énorme pour pouvoir faire tourner la moindre requête un tant soit peu complexe.
  • Pire. Encore bien pire (si c’est possible !). Si, comme moi, vous voulez utiliser des requêtes comprenant des calculs de distance, il vous faudra utiliser des fonctions mathématiques et là, de base, Doctrine ne connait rien, et il vous faudra passer quelques heures à installer un bundle dans votre installation, en modifiant pas mal de fichiers un peu partout. Si, là aussi, essuyez vos larmes de rire et lisez bien ce qui suit, car c’est vrai : il est impossible de faire immédiatement cette requête sous Symfony : "SELECT COS(5) as distance;". Non non ça n’est pas une blague, c’est du sérieux. Voir tout mon article détaillé ici.
  • Symfony est tellement complexe qu’il faut absolument avoir un débogueur intégré tel que xdebug et pouvoir faire du pas à pas dans un environnement tel que PhpStorm qui donne la possibilité de suivre tout, avec la pile d’appel. Rendez vous compte : pour développer un site Web simple, des frameworks comme symfony sont tellement complexes qu’il faut obligatoirement pouvoir faire du pas à pas. Ce sont des experts Symfony qui me l’ont expliqué. Sur le coup j’ai sincèrement (honnêtement, ce n’est pas ironique, c’est véridique) cru que c’était une blague. Php est tellement simple et fluide quand il est bien développé que je n’ai jamais eu à utiliser de débogueur pas à pas en plus de dix ans ! Et ma dernière prestation était en tant qu’expert Web chez Business & Décision, prestation pour la banque, et on n’a jamais eu besoin de faire du pas à pas ! D’ailleurs pourquoi je me justifie ? N’importe quel béotien doit se douter de ça…

Je n’ai pas le temps de lister toutes les autres choses qui m’ont fait perdre un temps fou. J’ai vendu un site que je comptais faire en maximum dix jours, et je l’ai fait en un mois. Symfony était tout bonnement un mauvais choix.

En conclusion :

Symfony est censé faire gagner du temps mais en pratique, on est obligé d’apprendre la globalité de tout le framework et au final on ne gagne absolument pas de temps, et bien pire : si le projet est petit, il faut à tout prix éviter des usines à gaz telles que Symfony.

Pour la petite note, les personnes qui m’ont sous traité le projet – qui tourne bien actuellement – ont été déçues parce que je n’ai pas tenu mes délais, et que mes premières livraisons n’étaient pas de bonne qualité – alors que je « semblais » compétent. Je ne jette pas tout sur Symfony, mais bon sang quelle grossière erreur de ma part ! Pour vous donner une idée de comparaison : j’ai terminé en 3 jours un site qui devrait être mis en ligne incessamment sous peu : un site spécialisé la constatation fiable de sites Web. Il contient :

  • Un formulaire d’inscription contenant tout ce qu’il faut (CSRF protection, re-Captcha etc) ;
  • Un CSS full responsive ;
  • Un blog WordPress (évidemment full responsive) ;
  • Un outil complet de capture d’écran basé sur du Webkit (très gros boulot) ;
  • Du code pour gérer un multi-partenariat en marque blanche ;
  • Du templating Smarty pour modifier l’habillage rapidement ;
  • Une documentation entièrement compatible PhpDocumentor ;
  • Une classe (assez longue) pour le traitement des images (archivage, signature chiffrée etc) ;
  • Un ORM qui :
    • ne fait des requêtes que quand c’est nécessaire,
    • fait des requêtes en SQL pur. Ouf, je respire, des heures entières de gagnées.
    • délègue au maximum à la base de données, ce qui est absolument vital pour avoir une application stable, rapide et pérenne sur le temps.
  • Une classe simple d’envoi de mail, avec la possibilité d’envoyer le texte alternatif (= si jamais le client ne peut pas lire du HTML, on peut préciser le texte). Merci PHPMailer, un outil simple, ultra facile d’utilisation, et utilisé dans ma classe, finit par un code ainsi :
    $mail = new ObjetMail(
        EMAIL_DEFAUT_FROM,
        EMAIL_DEFAUT_FROM_NAME,
        EMAIL_DEFAUT_REPLYTO,
        EMAIL_DEFAUT_REPLYTO_NAME,
        $email,
        'Capture bien prise',
        /*... Texte HTML ...*/,
        /*... Texte alternatif ...*/
    );
    try {
        $mail->send();
        array_push(
            $this->_TabResult,
            $this->trad->get(
                'mail_envoye_en_attente_confirmation'
            )
        );
    } catch (Exception $e) {
        $this->addTabErr(
            $this->trad->get('err_envoi_email')
        );
        $ok = false;
    }
  • Tout est tracé et archivé, aussi bien en base que dans les captures d’écran, et tout est prévu pour une grosse évolution : un compte, ce compte pourra avoir plusieurs emails, plusieurs captures, toutes les connexions – réussies ou échouées – sont déjà tracées, ils pourront avoir une ou plusieurs adresses etc.

Faire la même chose avec Symfony ? Je vous laisse estimer le temps de faire les estimations, le cahier des charges, le devis, le développement, mais attention, grâce à Symfony vous allez gagner énormément de temps : Symfony peut générer le CRUD pour l’administration en ligne de commande, regardez ici. Oulah que de temps gagné ! Sachant que je génère un custom getter-setter en 3 touches avec vim, même s’il y a plusieurs centaines de champs, et plusieurs dizaines de tables, je ferais ça « à la main » au maximum en une journée… enfin bon en comparant avec Symfony je peux dire sans éxagérer : sans Symfony, une journée de perdue, mais dix d’économisées ! Mais pourquoi je continue à essayer de prouver que Symfony ne fait jamais gagner de temps, moi ? Même ces personnes expertes Symfony ont décidé de le laisser tomber et de n’utiliser que Silex pour tous leur nouveaux projets à moins qu’ils n’aient vraiment besoin de choses spécifiques à Symfony… et personnellement je n’arrive pas à voir ce que Symfony a de si spécifique dont on ne peut pas se passer 🙂 … A l’inverse, je vois vraiment toutes les raisons pour lesquelles on peut se passer de Symfony.

bazaar : tutoriel, et exemple concret d’utilisation

Je fais quelques petites notes personnelles au fur et à mesure de l’utilisation de Bazaar, au cas où cela serve à quelqu’un :

La première chose, la plus importante à savoir, pour les non-anglophones :

Du point de vue de bazaar, « checkout«  signifie « faire un lien entre« .

Par exemple :

  • on fait un lien entre deux répertoires A et B (« bazaar checkout A B »)
  • pour toute validation de modification avec bazaar (« bazaar commit » ou autre), que ce soit sur A ou sur B, bazaar va aussitôt les répercuter de l’autre côté (sur B ou A).

(1) Créer un dépôt « central » distant qui hébergera TOUS les projets

Ici, dans « /rep_bazaar/iwn_bazaar/ » :

> bzr init-repo --no-trees \
    sftp://bazaar@serveur_ftp/rep_bazaar/
bazaar@serveur_ftp's password:
Shared repository (format: 2a)
Location:
  shared repository: sftp://bazaar@serveur_ftp/rep_bazaar/
>

(2) Créer un projet distant : ici, le projet est « projet_web« 

– D’après la config précédente, il faut le créer dans une branche du dépôt central = « /rep_bazaar/projet_web/ » :

> bzr init sftp://bazaar@serveur_ftp/rep_bazaar/projet_web
bazaar@serveur_ftp's password:
Created a repository branch (format: 2a)
Using shared repository: sftp://bazaar@serveur_ftp/rep_bazaar/
>

(3) En local, initialiser un répertoire ‘vide’ qui sera celui de référence à partir duquel toutes les branches futures (dev, preprod et prod, etc.) vont dériver

(!!) dans la ligne de commande, il y a le répertoire distant ET un répertoire destination, ici « website_reference » :

> mkdir website_reference
> bzr  \
    checkoutsftp://bazaar@serveur_ftp/rep_bazaar/projet_web \
    website_reference

Attention !

D’après ce que j’ai compris, il ne faut pas toucher aux sources de références, parce qu’elles vont être copiées sur les environnements de dev, preprod et prod.

(4) Ajouter les fichiers source dans le répertoire de référence :

> cp -R website/* website_reference/

(5) Dire à bazaar d’ajouter tous les fichiers :

> cd website_reference/
~/website_reference # bzr add
(
Énorme liste de fichiers :
adding blabla/blabla.png
..
adding drupal/blabla/..
...
adding drupal/.../blabla.gif
)

(6) Valider les modifs en local avec un commentaire pour le dépôt #1 :

~/website_reference # bzr commit -m "Fichiers originaux"
(
Énorme liste de fichiers :
adding ...
..
added ws/blabla.php
...
added xml/xx/blabla.xml
)
~/website_reference #

(!!) On peut donner en local un nom différent du nom de la branche distante !

Mais comme ça risque de devenir rapidement le bazar (ahah), j’ai choisi de donner des noms identiques au répertoire du dépôt distant et aux répertoires locaux :

(7) Création de la branche de développement sur le dépôt distant :

> bzr branch sftp://bazaar@serveur_ftp/rep_bazaar/projet_web \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev

(8) Lier la branche distante à un répertoire local

(!) je répète : on peut donner en local un nom différent du nom de la branche distante, mais je pense que c’est à éviter, donc :

> mkdir projet_web
> mkdir projet_web/dev
> bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev \
    projet_web/dev
bazaar@serveur_ftp's password:
>

(9) Création de la branche de préproduction :

Deux mêmes ordres que pour la branche de développement (sauf répertoire final) :

> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/preprod
> bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/preprod \
    projet_web/preprod
bazaar@serveur_ftp's password:
>

(9) Création de la branche de production :

Deux mêmes ordres que pour la branche de développement (sauf répertoire final) :

> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/prod
> bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/prod \
    projet_web/prod
bazaar@serveur_ftp's password:
>

(10) Arrivé ici, le schéma est ainsi :

Sur le site de dépôt commun, mais aussi en local :

projet_web
  |
  +--- dev
  |
  +--- preprod
  |
  +--- prod

(11) Créer les sous-branches pour les développeurs :

> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/autre_dev
> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier

(12) Arrivé ici, le schéma est ainsi :

Sur le site de dépôt commun :

projet_web
  |
  +--- dev
  |     |
  |     +--- autre_dev
  |     |
  |     +--- olivier
  |
  +--- preprod
  |
  +--- prod

NB : en local, les branches n’ont pas été créées, donc en local c’est ainsi :

projet_web
  |
  +--- dev
  |
  +--- preprod
  |
  +--- prod

(13) Exemple personnel : ma branche de développement pour la cellule médicale v 2.0 :

Nb : on crée encore une branche distante, rien n’est encore fait en local :

> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier/nouveau_developpement

(13) Arrivé ici, le schéma est ainsi :

Sur le site de dépôt commun :

projet_web
  |
  +--- dev
  |     |
  |     +--- autre_dev
  |     |
  |     +--- olivier
  |            |
  |            +--- nouveau_developpement
  |
  +--- preprod
  |
  +--- prod

NB : en local, les branches n’ont pas été créées, donc en local c’est ainsi :

projet_web
  |
  +--- dev
  |
  +--- preprod
  |
  +--- prod

A partir de maintenant, on peut refaire en local toutes les branches qui n’y sont pas encore (autre_dev, olivier, nouveau_developpement).

Mais je choisis, par exemple, de ne faire que mes branche locales à moi (= olivier) :

Je fais le lien (= checkout) entre olivier et olivier distant :

>bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier \
    projet_web/dev/olivier

Je fais le lien (= checkout) entre nouveau_developpement et nouveau_developpement distant :

>bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier/nouveau_developpement \
    projet_web/dev/olivier/nouveau_developpement

(14) Résultat final :

Sur le site de dépôt commun :

projet_web
  |
  +--- dev
  |     |
  |     +--- autre_dev
  |     |
  |     +--- olivier
  |            |
  |            +--- nouveau_developpement
  |
  +--- preprod
  |
  +--- prod

En local, certaines branches n’ont pas été créées (volontairement) donc en local c’est ainsi :

projet_web
  |
  +--- dev
  |     |
  |     +--- olivier
  |            |
  |            +--- nouveau_developpement
  |
  +--- preprod
  |
  +--- prod

A partir de maintenant, en pratique

En pratique, il me suffit : de travailler sur le répertoire nouveau_developpement puis de faire toutes mes modifs, mes évolutions.

Une fois que je pense que tout est bon :

  • Aller dans le répertoire nouveau_developpement
  • Faire un commit :
    bazaar commit -m "Commentaire mise à jour"
  • Automatiquement, les modifications vont être répercutées sur ma branche distante (= sur le site de dépôt commun).

Dix façons de devenir un meilleur développeur PHP

Les 5 premiers conseils viennent d’ici

Les 5 conseils suivants venaient de ce lien d’http://www.hackingajax.com/2008/02/13/5-more-ways-to-be-a-better-php-developer/ mais il est mort…

Souvent, un développeur PHP inexperimenté va sauter sur IRC et poser une question sur Freenode##php. Et si la question est facile, il aura une réponse rapidement. Au début. Parce que par la suite, il va être bombardé de réponses du style « LOL », « ROFL », « Va apprendre PHP et reviens », « Vas te documenter un minimum », « On n’est pas ton prof personnel », etc. Donc, comment devenir un meilleur développeur PHP ? Dans ce post, je vais mettre en avant cinq façons d’être un meilleur développeur, d’être plus productif, d’écrire moins de code et de faire ainsi plus de choses avec vos applications web. Il y a toujours quelque chose de nouveau à apprendre quand on parle de développement PHP. Nouvelles fonctions internes, nouveaux frameworks, nouveaux design patterns, nouveau styles de documentation. Ci-suivent quelques-unes des façons les plus efficaces pour vous aider à être un meilleur développeur PHP.

  1. Lisez le manuel
    Je ne le dirai jamais assez : c’est là qu’il faut regarder en premier et il y a des tonnes de choses à apprendre simplement en lisant le manuel. Les problèmes les plus courants sont déjà résolus si vous lisez ce qui concerne les chaines de caractères (string), et les tableaux (array). Il y a plein d’exemples qui fonctionnent directement accessibles, et souvent, rien qu’en parcourant le manuel vous allez vous rendre compte que vous êtes en train de ré-inventer la roue, parce qu’une fonction que vous voulez faire existe déjà et, mieux, elle est directement d’origine dans PHP ! Le manuel PHP est votre ami. Note d’Olivier : une petite astuce supplémentaire : si vous voulez chercher quelque chose, il vous suffit de taper : php.net/[mot à chercher] et même si PHP ne le connait pas il vous donnera une liste de mots approchants ! Génial non ?
  2. Balladez vous dans le code d’autres personnes
    PHP a plein de code open source. Pourquoi ne pas apprendre grâce à ça ? Récupérez une application PHP open source et jetez un coup d’oeil dans le code. Les plus gros projets sont sûrement meilleurs, car, même s’ils auront des structures plus complexes, ils auront des systèmes fonctionnels mais derrière tout ça une documentation détaillée qui explique tout. Visitez SourceForge.net si vous n’arrivez pas à trouver un point de départ.
  3. Apprenez un nouveau framework
    Il y a plus de frameworks PHP que vous n’avez eu de diners galants qui se sont bien terminés (!) ; la plupart sont open source et disponibles en ligne si vous savez où regarder. Essayez les principale, par exemple phpframeworks.com a une excellente liste. Votre framework ne peut jamais être entièrement complet, votre prochain travail, ou projet, aura besoin de telle ou telle fonctionnalité, ou s’appuiera sur un framework différent et vous trouverez certainement que des idées des autres sont très utiles pour l’un de vos projets.
  4. Recherchez
    Vous avez probablement entendu plein de choses et de mots dans le contexte d’un développement Internet en PHP. En allant de OOP à MVC, en passant par KISS, DRY, YAML, INI, REST, XML-RPC, etc, il y a des centaines de termes techniques et de concepts ici qui pourraient être directement reliés à vos travaux. Peut-être avez-vous déjà une compréhension basique, ou grossière d’eux, mais est-ce que vous savez vraiment en profondeur ce qu’ils signifient pour vous ? Passez un peu de temps à faire de la vraie recherche, apprenez, formez vous un peu dessus. Wikipedia est un bon endroit pour commencer. Vous allez inévitablement apprendre des choses que vous ne connaissez pas, et ça ne peut que vous être profitable.
  5. Apprenez la programmation orientée objet
    C’est un peu lié au point précédent, mais la programmation orientée objet (POO, ou en Anglais, Object Oriented Programming, OOP), est beaucoup plus importante que vous ne pouvez l’imaginer : est-ce que vous connaissez vraiment la POO sur PHP 5 ? Par exemple, est-ce que vous manipulez facilement les classes abstraites, les interfaces, le mot clé implements, les méthodes et propriétés statiques, et les propriétés protected ? Beaucoup de développeurs PHP expérimentés ne sont pas compétents dans ce domaine, et pourtant, si vous utilisez ce genre de caractéristiques propres à la POO, vous construirez certainement des architecture beaucoup plus souples, évolutives, et vous gagnerez par là même beaucoup de temps de développement.
  6. Commencez un projet que d’autres personnes (développeurs et utilisateurs finaux) vont utiliser.
    Vous ne gagnerez jamais autant de respect (ou de dédain) plus rapidement qu’en écrivant un programme pour des étrangers qui doivent se servir de votre code. Que ce soit une application web pour des utilisateurs finaux, ou une extension PEAR pour les développeurs, ou un plugin WordPress pour le bloggeurs, le fait de mettre un logiciel, ou du code entre les mains d’autres personnes de manière à ce qu’elles puissent y réagir est la chose la plus efficace que vous puissiez faire pour devenir un meilleur développeur. Être mis dans la position de devoir répondre aux demandes des uns et des autres est aussi important et valorisant que le lien entre un journaliste et le journal publié. Tous ceux qui l’ont fait vous le diront, ce n’est pas facile mais une fois que vous arrivez à gérer ça, vous saurez écrire en étant sous pression, avec des délais à tenir, et éventuellement sous le feu d’une opinion publique qui peut ne pas être facile. D’ailleurs, écrire un programme en entier de bout en bout n’est pas si différent. Faites votre travail, donnez-le et attendez le retour. C’est cette boucle d’échanges qui fait les bons programmes et les bons développeurs. En fin de compte, c’est peut-être ce fameux feedback qui a principalement de la valeur.
  7. Apprenez un autre langage.
    Si vous commencez à peine avec PHP, ce n’est peut-être pas le moment de vous plonger dans quelque chose de nouveau, mais si vous connaissez le langage et que vous voulez amélorier vos compétences, vous verrez qu’il y a des avantages à ne pas être spécialisé uniquement dans un seul langage. Par exemple : Java vous oblige à comprendre la programmation orientée objet (P.O.O., en Anglais : O.O.P.), Ruby on Rails vous oblige à apprendre le principe Modèle – Vue – Conteneur (M.V.C.), C# vous oblige à apprendre ce qu’est la dépendance à l’autocomplétion (je blague, C# ne sert à rien, apprenez Java c’est déjà une excellente chose). Le fait d’élargir vos horizons vous offre la possibilité de comprendre comment d’autres langages ont résolu certains problèmes qui ne le sont pas encore, ou pas correctement, en PHP, ou bien qui ne sont pas évidents à résoudre, tout simplement. Par exemple, je vous certifie que je suis devenu un développeur PHP nettement plus compétent depuis que j’ai écrit un peu plus de 7,500 lignes de code pour Ruby on Rails. Apparemment, je ne suis pas le seul.
  8. Apprenez un autre langage à quelqu’un.
    Rien ne vous fait mieux apprendre que d’apprendre à quelqu’un d’autre. N’importe quelle personne qui est vraiment intéressée par ce que vous apprenez va inévitablement vous posez des questions sérieuses, des questions précises, des colles que vous aurez du mal à surmonter au début, mais qui vont vous amener à un degré de connaissance du langage insoupçonnable. Et puis au moins vous aurez un autre angle de vision sur ce qu’est la patience, lorsque vous aurez à répondre pour la vingtième fois à « Au fait, vous pourriez ré-expliquer ce qu’est une variable ? ». J’ai appris le langage Python à mon fils, récemment, après n’y avoir pas touché pendant 5 ans. C’était une expérience très intéressante pas uniquement dans le sens où j’ai réalisé à quel point j’avais tout oublié de Python mais surtout dans la manière de programmer qui est différente. Quand vous réussissez à apprendre à des jeunes de 13 ans pourquoi vous devez transformer des entiers avant de pouvoir les concaténer à des chaines de caractères en Python et pourquoi ce n’est pas nécessaire en PHP — et qu’il le comprennent — vous aurez d’ici là appris énormément de choses et vous serez forcément devenu un meilleur développeur.
  9. Demandez des suggestions et des solutions
    Si jamais vous n’arrivez pas à vous décoller d’IRC, assurez vous que vous avez vraiment recherché dans tous les sens la résolution d’un problème avant de demander de l’aide. Et lorsque vous demandez, montrez votre code. Si vous montrez que vous avez essayé quelque chose et que vous avez fait déjà un bon paquet d’efforts, croyez moi, vous aurez beaucoup plus facilement des réponses à vos questions.
    Vos question devraient ressembler plutôt à « je pense qu’ici je fais quelque chose qu’il ne faut pas, pouvez-vous m’aider » plutôt que « pourriez vous faire le travail pour moi. »
  10. Utilisez ce que vous lisez.
    Que dire de plus que cette loi de programmation simple, cardinale et fondamentale :
    C’est toujours plus dur de lire du code que de l’écrire. (Joel Spolsky) ?
    Après ces deux conseils de Lisez le manuel et Balladez vous dans le code d’autres personnes, vous allez apprendre beaucoup de choses, mais il ne suffit pas que de lire. Il faut aussi écrire. Vous ne pouvez pas lire 100 livres faits par des gens talentueux et pondre juste après Le Seigneur des Anneaux en une nuit. Ne faites pas que parcourir le code, utilisez le aussi dans le votre. Eventrez CakePHP et regardez comment ils gèrent la validation des formulaires. Ecartelez HTML_QuickForm2 et utilisez sa création d’éléments. Comprenez comment WordPress gère les transactions de sa base de données, et comparez avec Drupal. Ce sont toutes les choses que votre application, à un moment ou à un autre, devra pouvoir réaliser, donc vous devriez vraiment jeter un coup d’oeil et essayer de voir comment les autres ont résolu les problèmes auxquels vous êtes confronté. Et quand c’est adéquat, et légal, utilisez leur code. Vous apprendrez incroyablement plus si vous devez prendre un morceau de code, et le modifier afin qu’il fonctionne dans votre application que si vous ne faite que lire les branches SVN du projet.