L'antre à Duo

Introduction à Sinatra - 1ère Partie

Voilà la première partie d'un petit tutorial pour se mettre à Sinatra, un micro-framework en Ruby, basé sur Rack.

Vous n'avez pas réellement besoin de connaitre ruby pour suivre ce tutorial mais c'est toujours un plus. Je considère aussi que vous avez déjà ruby d'installé ainsi que gem (sinon vous trouverez très facilement les tutos nécessaires).

Je vous propose donc de construire un clone simpliste de Pastebin !

Commençons par le commencement, créez un dossier dédié à votre application. Appellons-la Duopaste. Créez donc simplement un fichier duopaste.rb contenant ceci :

Ici rien de fantastique, on inclue simplement les gemmes nécessaires au bon fonctionnement de Sinatra.  

La syntaxe de Sinatra est extrêmement simple et claire. Pour preuve voilà notre première méthode :

• Dans ce tout petit bout de code, il se passe plusieurs choses :
• On indique à Sinatra ce qu'il faut faire lorsqu'on accède à la racine du serveur par une requête GET
• On affiche un template ERB (Embedded Ruby)

Et c'est tout !

Cela dit avant tout, il faut penser à stocker nos snippet de code. Pour cela je vous propose d'utiliser DataMapper, un ORM bien connu dans le monde du Ruby.

Pensez d'abord à rajouter au début de votre fichier :

afin d'importer les ressources nécessaires à DataMapper.

Et voilà, avec ce petit bout de code, on a un modèle fonctionnel composé de :

• Un id de type Serial, qui représente généralement une colonne autoincrement
• Un champs body de type Text où l'on va stocker le contenu du snippet

Il nous faut ensuite créer un template pour ajouter des snippets :

Pas besoin d'explications, c'est un formulaire tout ce qu'il y a de plus banal. Ensuite il faut créer un autre template pour afficher nos snippet :

À nouveau rien de magique, on affiche simplement le contenu du snippet. Pensez à mettre les templates dans un sous-répertoire Views.

Il nous reste maintenant à créer la logique pour que tout ça se mette en place ! Il nous faut 3 actions :

• Afficher le formulaire de création
• Créer un snippet
• Voir un snippet

Tout simple encore une fois :

La touche finale pour pouvoir lancer notre petit site, créez un fichier config.ru :

C'est nécessaire pour lancer votre site. Ensuite un simple :

Et vous pouvez utiliser votre site en vous connectant sur localhost:4567 !  

Si vous voulez le code "complet", vous pouvez jeter un coup d'oeil sur le repository GitHub : duopaste

Pour le reste je vous conseille de jeter un coup d'oeil à la documentation de Sinatra et de DataMapper.

Dans la deuxième partie nous verrons comment mettre un peu de coloration syntaxique, et comment déployer tout ça sur Heroku !

Pourquoi je n'aime pas coder en PHP

Ceux qui me connaissent le savent déjà, mon métier c'est développeur web. Plus spécifiquement PHP, et actuellement je travaille la majorité du temps avec Symfony.
Ceux qui me connaissent savent aussi que pour moi, coder en PHP relève de la torture.

Je me suis rendu compte qu'il fallait que j'explique un peu pourquoi.

Disclaimer: cet article est purement subjectif et complètement gratuit ! Les paramètres des fonctions sont chaotiques. Pourquoi le needle est en premier dans in_array() mais en deuxième dans strstr() ? (en fait le needle est en premier dans les fonctions de tableau, et en deuxième dans les fonctions de chaine. Pourquoi ? Aucune idée.)

• Même chose qu'au dessus, pourquoi certaines fonctions modifient directement la variable (comme sort()) alors que d'autres renvoient la valeur modifiée ? (array_reverse())

• Des fonctions plutôt que des méthodes. Pourquoi faire array_reverse($array) plutôt que $array->reverse() ? Ça vaut pour la majorité des fonctions PHP.

• La gestion des erreurs est chaotique. Entre les exceptions, trigger_error et le errors codes, c'est l'horreur. Évidemment en fonction de l'environnement ou du framework utilisé, les conventions sont différentes. Parfois on retourne false, parfois null, parfois une exception, parfois … bref.

• Les variables de variables … pas besoin d'en dire plus.

• Devoir utiliser un tableau intermédiaire si une fonction renvoie un table. Pourquoi on peut pas tout simplement écrire foo()[‘bar’] ?

• Tout une paquet de trucs est false : false, 0, “”, null, array() … ben voyons.

• Devoir mettre $this partout dans son code. Pourquoi PHP n'est-il pas capable de mieux gérer la portée des variables ?

• Pas de différence entre un array et un hash. Pire, on peut mélanger les deux.

• En parlant de tableau, pourquoi on est obligé d'utiliser array() pour créer un tableau plutôt qu'une syntaxe courte comme {‘key’ => ‘value’} ou [‘foo’, ‘bar’] ? C'est rapidement illisible quand on veut des tableaux imbriqués.

• Les fonctions de base sont souvent incompréhensibles : sans regarder la doc, que fait array_intersect_uassoc() ? Quelle est la différence entre usort(), uksort() et uasort() ?

• Il n'y a pas de package manager efficace et standard. Ne me parlez pas de PEAR.

• Goto, sérieusement … ?

• Pas de lambda/closure (spécifique à PHP < 5.3)

• Pas de namespace (idem)

• Pourquoi parfois les erreurs sont en hébreu ? (T_PAAMAYIM_NEKUDOTAYIM)

Conclusion

Je vous avais prévenu, c'était gratuit, mais rahhhh ça fait du bien :)
Je rajouterai probablement quelques horreurs quand elles me viendront à l'esprit !

Git et SVN - Partie 2

Suite du premier article sur l'utilisation conjointe de Git et SVN. Je vais surtout vous donner en vrac quelques astuces et cas d'utilisations utiles.

1 – Travailler sur des branches/tags de SVN

D'abord il faut consulter la liste des branches :

$ git branch -a
master
remotes/experimental
remotes/tags/1.0.1
remotes/trunk

Ici par exemple, nous voulons travailler sur la branche “expérimental”. Pour cela rien de plus simple :

$ git checkout -b local/experimental experimental
Switched to a new branch 'local/experimental'

Rappel : l'option -b de checkout crée une branche et checkout directement cette dernière. Vous pouvez constater que la branche locale et le remote pointent sur le même commit :

$ git show-ref
e287424206398aecfcb4f4fa68d16c22f5e9455c local/experimental
e287424206398aecfcb4f4fa68d16c22f5e9455c refs/remotes/experimental

Ici j'ai préfixé ma branche avec “local/” mais vous pouvez tout à fait l'appeler comme vous voulez. Vous pouvez maintenant travailler sur votre branche comme avec le master, et commit puis dcommit comme expliqué dans la première partie.

2 – Merge ou Rebase ?

Un des gros avantage de Git est qu'il permet une utilisation abusive des branches et autres merge, sans se prendre la tête à résoudre des milliers de conflits (mais non je ne pense pas à un autre VCS …) Bref, après avoir fait vos commit sur une branche, vous avez deux possibilités :

• Merger la branche dans une autre (le master par exemple)
• Rebase la branche dans une autre

Je vous laisse consulter les autres tutos pour comprendre exactement la différence (ce (chapitre)[http://progit.org/book/ch3-6.html] de ProGit par exemple), mais dites vous que globalement SVN fonctionne seulement avec un historique linéaire. Aussi pour éviter les prises de tête et les nuits blanches, je vous conseille fortement de rebase vos branches plutôt que de merger. Encore une fois c'est très simple :

$ git checkout master
$ git svn rebase
$ git rebase experimental
$ git svn dcommit

et c'est tout ! En cas de conflit, le rebase s'arrête et vous laisse la main. Une fois vos conflits résolus il faut stager vos fichiers et continuer le rebase :

$ git add monfichierenconflit.txt
$ git rebase --continue

Si résoudre le conflit est vraiment trop galère vous pouvez tout annuler :

$ git rebase --abort

Notez que ces options (abort, continue) fonctionnent de la même façon pour un merge.

3 – Faire moins de commit (squash)

Avec Git on a facilement tendance à commit à tour de bras, et c'est tant mieux. Le problème c'est que lors du dcommit vers SVN, chaque commit va devenir une nouvelle révision, et c'est pas toujours le fonctionnement le plus apprécie.
Pour ça vous avez une solution, c'est encore le couteau-suisse : rebase. Imaginons que vous voulez avoir seulement une révision SVN pour vos 3 derniers commit git :

$ git rebase -i HEAD~3

Votre éditeur de texte va alors s'ouvrir et vous aurez la possibilité d'éditer votre historique. Pour faire simple, si vous voulez un seul commit, laissez le premier commit à “pick” et mettez les autres à “squash”.

pick 3e6e88b changed README
squash 8ea73c7 added licence to README
squash f287124 added README file

Attention: Si vous supprimez un commit de ce fichier, il sera définitivement supprimé !

Si vous vous décidez d'abandonner, supprimez tout le contenu du fichier et fermez votre éditeur, rebase ne fera rien.

Lorsque vous sauvegarderez le fichier, votre éditeur va s'ouvrir à nouveau et va vous proposer de réécrire le log du nouveau commit. Quittez à nouveau l'éditeur, et magie de Git, vous avez maintenant un seul commit :)

Conclusion

Et voilà pour cette deuxième partie. Je reviendrai probablement dessus pour rajouter des infos utiles pour dompter Git et SVN.
Have fun :o)

Git et SVN - Partie 1

A moins d'avoir vécu sous un rocher pendant les dernières années, vous n'avez pas pu rater l'apparition d'un outil de gestion de version décentralisé : Git.

Je ne vais pas revenir sur les avantages et inconvénients de Git, vous trouverez largement ce qu'il vous faut dans une multitude d'articles et autres blogs.

Git est un outil remarquable, mais je me suis rapidement heurté à un problème dans mon entreprise (EP Factory) : on utilise Subversion. Plutôt que d'essayer de migrer, chose pas forcément aisé en milieu de projet, je me suis mis en tête d'utiliser Git pour travailler sur le serveur SVN.

Dans ce tuto je vais vous expliquer comment importer votre repository SVN en local ainsi que tout l'historique des versions, puis comment travailler avec des branches et enfin commiter votre travail sur le serveur SVN, tout ça sans toucher à une seule commande SVN.
Notez que je considère que vous connaissez au moins les bases de Git. Si ce n'est pas le cas je vous conseille de consulter Pro Git ou GitRef.

Étape 1 : Cloner le repository

Étape qui va nécessiter du café, non pas à cause de sa difficulté mais à cause de sa longueur si votre repository SVN contient beaucoup de commits. En effet, Git étant décentralisé, il a besoin de cloner tout l'historique SVN, c'est à dire commit par commit. Je vous laisse imaginer le temps que ça peut prendre avec une dizaine de milliers de commits … :)

$ git svn clone -t trunk -T tags -b branches http://monrepo.com monprojet

Si votre structure est “classique”, c'est à dire le trio trunk/tags/branches, vous pouvez remplacer les options par un simple -s. C'est le moment où vous prenez un café.

C'est fini ? Et bien, profitez-en pour vous faire un autre café et lancez cette commande :

$ git svn show-ignore >> .git/info/exclude

Concrètement cela va juste copier la liste des fichiers ignorés par SVN … et c'est long.

C'est bon ? Ok. Maintenant vous pouvez essayer :

$ git svn info $ git branch -a

et vous constaterez vous avez un clone git fonctionnel, qui a importé toutes les branches et les tags depuis SVN.

Étape 2 : Commiter sur SVN

Maintenant faites quelques modifs dans des fichiers et commitez vos changement :

$ git commit -am "Changed file.php, fixed #1023"

N'oubliez pas que la notion de commit avec Git est différente de Subversion : commiter se fait simplement en local et n'envoie absolument rien au serveur. Pour envoyer votre commit vers SVN, il vous reste à faire un dcommit :

$ git svn dcommit

Normalement tout s'est bien passé et Git vous renverra le numéro de la révision SVN correspondante.

Étape 3 : Récupérer les changements depuis SVN

Tout comme avec SVN, si un développeur a fait des modifications pendant que vous travailliez sur le même fichier, vous ne pourrez pas dcommit.

$ git svn dcommit Merge conflict during commit: Your file or directory 'file.php' is probably out-of-date

Rien de plus simple, il suffit de faire :

$ git svn rebase

Cette commande va se charger d'aller chercher les nouveaux commits sur le serveur SVN, les appliquer sur votre copie locale puis appliquer vos commits par dessus. Vous pouvez maintenant dcommit tranquillement.

Conclusion

Et voilà pour ce premier vrai article. J'ai essayé de faire clair et concis mais je suis conscient que c'est pas encore terrible. N'hésitez pas à donner votre avis dans les commentaires, ou par Twitter (@DuoSRX).

À bientôt pour la deuxième partie où j'aborderais les branches avec Git et SVN !