Mon premier article expliquait comment créer un dépôt local, ce qui n’est naturellement pas suffisant pour travailler en collaboration avec d’autres personnes. Git est un système de gestion de sources décentralisé, il est assez simple de créer un dépôt distant afin de partager votre travail, que ce soit sur un de vos serveurs où en utilisant un service d’hébergement. GitHub (mon compte) est donc un de service offrant la possibilité d’héberger un dépôt distant pour vos projets agrémenter de fonctionnalités supplémentaires. Il existe bien entendu une version gratuite qui vous permettra de créer des projets publics dans un espace limité à 100 Mo, des plans payants (dès 7$ par mois) permettent d’augmenter cet espace mais également de bénéficier de dépôts privés (indispensable pour les entreprises il va de soit). Il est bien entendu possible de donner des accès en écriture aux dépôts publics et privés à d’autres comptes (qu’ils soient payants ou non) .

Le service vous crée une page de profile simple où vous pouvez afficher votre nom, email, entreprise, localisation et site internet. Cette page affichera également votre activité (commit, ajout de suivi, …) et vos dépôts. Vous pouvez également décider de recevoir les mises à jour (commit, comment) concernant un projet ou une personne, elles seront affichées sur votre page d’accueil avec la liste des projets afin d’y accéder plus rapidement. Vous avez également accès à un système de messagerie et de recherche de projet.

Les pages d’un projet commencent par une série d’onglet permettant de parcourir les sources (page par défaut), d’accéder à la liste des commits, un wiki, le network (voir ci-dessous), a la liste des watchers (personnes suivants le projet) et enfin, si vous êtes le propriétaire, un accès à l’administration. Une seconde série d’onglets donne accès au menu de la section (liste des branches et tags par exemple). On trouve ensuite boite contenant les informations de base sur le projet, celle-ci est présente sur toutes les pages et contient le nom du propriétaire et du projet, une série de bouton d’action (dont fork et pull request que nous verrons plus loin, ainsi que watch et download qui permet de télécharger une archive de la branche sur laquelle vous êtes). Suis une description, l’adresse du site du projet et enfin les adresse Git (public clone, private clone, push).

L’explorateur des sources est classique, mais bien réalisé, notez tout de même que si un fichier README est présent à la racine, il sera affiché sur la première page en dessous de l’arborescence et que si celui-ci à une extension du type rdoc par exemple, le contenu sera formaté. Il est aussi possible de laisser un commentaire sur un commit en particulier.

Revenons sur ce qui fait la force d’un système décentralisé et plus particulièrement sur son intégration dans GitHub qui en facilite et favorise grandement l’utilisation. Le bouton fork permet de créer un clone du projet dans votre compte (un peu comme si vous utilisiez la commande git clone en locale), vous allez donc pouvoir travailler sur votre propre branche d’un projet et en publier les modifications dans votre espace public très facilement. Quand vous faites ceci vous entrez dans le network du projet et c’est là que GitHub est également intéressant puisqu’il permet de retrouver les branches d’un projet maintenu par d’autres personnes assez facilement. Vous pouvez ensuite utiliser depuis votre dépôt (ou un commit en particulier) le bouton pull request afin de proposer au mainteneur de la branche d’origine (ou d’autres branches éventuellement) d’intégrer vos modifications. Précisons également que si vous faites un fork d’un projet privé auquel vous avez accès, il sera également privé chez vous et ceci sans que vous ayez besoin d’un compte payant.

C’est probablement ici qu’on sent la force de Git et de GitHub, en favorisant la collaboration et la participation.

Concrètement, comment mettre mon projet sur GitHub ?

Pour commencer il va vous falloir une clef ssh afin de vous connecter aux projets auxquels vous avez accès. Attention, une clef ne peut être utilisée que par une seule personne, c’est elle qui vous identifies en plus de vous authentifier. Je rappelle également que dans Git les commit sont signés par un nom et une adresse email et c’est grâce à celle-ci que vos commits seront liés à votre profil.

Pour créer une clef (avec MSysGit sous Windows le fonctionnement est le même que sous Linux, je ne fais donc aucune distinction dans la suite de l’article).

$ ssh-keygen -C yann.lugrin@... -t rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in .ssh/id_rsa.
Your public key has been saved in .ssh/id_rsa.pub.
The key fingerprint is:
c0:0c:27:7e:4b:c9:0d:f7:14:c2:de:78:54:0e:32:bb yann.lugrin@...

La passphrase est importante afin de protéger votre clef privée, si vous n’en mettez pas et qu’elle est utilisée par quelqu’un d’autre il pourra se connecter sans problème à votre compte. Voici à quoi ressemble une clef publique (il n’y a pas de retour à la ligne en réalité) :

$ cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA1x36C/Aur4KYHAL6I2m3FRoc3ixPFO/+9+ITyeM3FdCP
zPJ5fyMyNy+vkZm9zpbCsxjVGAjCSpYfQ4ins+U3CVMgAJnpNLtTri9f5EswkwSTGNhFomwuGb1RZOeg
ZPX/oveY2qylS+aOBY8/W2sICTOKsVDTWShc3P/bAtLxxPq3VdX73x70cRW1yVPthRPcci4QRWMFkyCY
TLrmH8C7I2KGffU7NUm1RzW9ym34TapZI5UKRq3jCx3kmiUjYVyf1Qqo9Dk5Xn855Uvk0/CAZnITQsfP
mhMYwLcp7K2zD9WbnljTtVO3PDRU4HaXQOPR7gcgNTN/xMuZruEZUGPDnw== yann.lugrin@...

Maintenant vous pouvez créer un compte sur GitHub, votre username sera utilisé pour identifier votre profil et votre compte (il sert donc de préfixe à vos projets en quelque sorte). Comme je vous l’ai déjà dit votre adresse email permet de lier vos commits à votre profil (vous pourrez en ajouter d’autres plus tard si besoin) et enfin dans le champ SSH Public Key vous pouvez entrer le contenu du fichier id_rsa.pub (vous pouvez aussi en ajouter d’autres plus tard).

Créer un nouveau projet est simple, suivez le lien qui se trouve sur la droite de la page d’accueil une fois que vous êtes connecté. Donnez un nom à votre projet et éventuellement une description et l’adresse d’un site. Vous pouvez également définir s’il est public ou privé (si vous en avez le droit naturellement). La page suivante vous explique comment envoyer votre travail sur GitHub. Parant du principe que vous avez déjà un dépôt local, avec une console, allez dans le répertoire de celui-ci et en utilisant les informations données sur GitHub tapez les commandes suivantes :

$ git remote add origin git@github.com:yannlugrin/test.git
$ git push origin master
Enter passphrase for key '/home/yann/.ssh/id_rsa':
updating 'refs/heads/master'
  from 0000000000000000000000000000000000000000
  to   5ef08e8fc190c49a73a0eb246255b454a8a0f56b
 Also local refs/remotes/origin/master
Generating pack...
Counting objects: 26
Done counting 407 objects.
Deltifying 407 objects...
 100% (407/407) done
Writing 407 objects...
 100% (407/407) done
Total 407 (delta 192), reused 0 (delta 0)
refs/heads/master: 0000000000000000000000000000000000000000 -> 5ef08e8fc190c49a73a0eb246255b454a8a0f56b

La passphrase de votre clef vous sera demandée et vos précédents commits seront transmis vers votre dépôt sur GitHub, vous pouvez maintenant accéder à votre projet et y voir vos fichiers.

Pour créer un clone de votre projet en local (par exemple lors du fork d’un autre projet) vous pouvez utiliser la commande suivante :

$ git clone git@github.com:yannlugrin/test.git

ou pour un projet dont vous n’avez pas d’accès en écriture :

$ git clone git://github.com/yannlugrin/test.git

Vous pouvez maintenant continuer à travailler sur votre dépôt local, faire vos commits et régulièrement utiliser la commande git push pour mettre à jour GitHub ou git pull pour mettre à jour votre dépôt local.

$ git push origin
$ git pull origin master

Articles relatifs

• Git, une petite introduction
• Ruby On Rails est ce qu’il vous faut !
• Rails, version 1.1.2
• Rails 1.2.2 et petite note sur Globalize
• Rails 1.2, quoi de neuf ?

Avant d’entrer dans le vif du sujet, je rappelle que je découvre Git actuellement, et que cet article peut contenir des imprécisions, voir quelques âneries (ne pas hésiter à me les signaler). Cependant, il ne contient aucun Troll, ce n’est pas parce que je décris quelques choses que je prétends que c’est la solution parfaite ou qu’elle n’est pas disponible ailleurs, c’est simplement un choix.

Git ?

Linus Torvalds, créateur de Linux, a commencé l’écriture de Git en avril 2005 afin de remplacer le logiciel BitKeeper. Cet outil propriétaire étais utilisé jusque là pour la gestion des sources du Kernel Linux, jusqu’à ce que la possibilité d’utiliser gratuitement le logiciel soit révoqué par son auteur, Larry McVoy (les raisons de cet événement sont assez controversées, je n’entrerais donc pas dans les détails ici). La première version a été publiée le 7 avril 2005, en juillet Linus annonçais que le Kernel serait dorénavant développé avec Git et que la maintenance de ce nouvel outil était confié à Junio Hamano. La première version stable (1.0) est quant à elle sortie le 21 décembre 2005.

Git fait partie de la famille des gestionnaires de sources décentralisée, tout comme BitKeeper ou Mercurial par exemple et au contraire de Subversion ou CVS. Le principe consiste à permettre à chacun de travailler à son rythme, de façon désynchronisée des autres, puis d’inclure leurs modifications dans son travail et mettre les siennes à leur disposition. Un dépôt de référence est en général défini (par convention, pas pour des raisons techniques), depuis lequel chacun peut partir afin de faire ces développements, avant de les y faire éventuellement intégrer.

Comment ça marche ?

La plupart des distributions Linux doivent contenir un package avec Git, sinon vous pouvez le télécharger et le compiler vous-même (je ne vais pas entrer dans les détails, si vous devez le faire, c’est que vous êtes un grand garçon ou une grande fille ;-)). Sous Windows il existe MSysGit, celui-ci permet d’installer tout ce qu’il faut pour que ça marche (vous aurez une console comme avec CygWin et un outil GUI), lisez bien les informations lors de l’installation afin de faire les choix qui sont le mieux adapté à votre utilisation (en cas de doute choisissez la solution la moins intrusive pour votre système).

Avant toute chose, une petite opération simple de configuration afin de vous identifier correctement lors de vos commit. L’option –global permet de définir ces informations pour tout votre système, si vous utilisez les mêmes commande dans un dépôt sans cette option vous pouvez définir un nom et une adresse spécifique pour celui-ci. Vérifier que tout est en ordre avec l’option –get.

$ git config --global user.name "Yann Lugrin"
$ git config --global user.email "yann.lugrin@..."
$ git config --get user.name
Yann Lugrin
$ git config --get user.email
yann.lugrin@...

Pour créer un nouveau dépôt, rien de plus simple. Déplacez-vous dans le répertoire de votre application (ou créez-en un) et tapez la commande suivante :

$ cd ./MyApp
$ git init
Initialized empty Git repository in .git/

Comme vous pouvez le constater, votre répertoire de travail et votre dépôt ne font qu’un, vous allez donc commiter toutes vos modifications en local. Nous verrons plus tard (avec GitHub) comment utiliser un dépôt distant. Mais attention, dans tous les cas vous aurez cette configuration, vous n’enverrez jamais vos modifications directement vers un autre dépôt.

Petite précision sur les commandes, une commande notée git init est un “proxy” vers la commande git-init, si vous voulez de l’aide sur une commande, utilisez cette seconde notation avec man afin de l’obtenir.

$ git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)

Notre dépôt est créé, mais ne contient naturellement encore rien.

$ touch README
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       README
nothing added to commit but untracked files present (use "git add"
to track)

$ git add README
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file: README
#

Le fichier README est créé, noté que nous avons dû explicitement l’ajouter avec la commande git add et qu’il existe également les commande git rm et git mv.

$ git commit -a -m "Initial commit"
Created initial commit b3037e7: Initial commit
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README

$ git status
# On branch master
nothing to commit (working directory clean)

$ git log
commit b3037e7f45f65d1003eada3248e8541f459085ac
Author: Yann Lugrin <yann.lugrin@...>
Date:   Mon May 5 15:29:01 2008 +0200

    Initial commit

L’option -a pour la commande git commit permet de tout envoyer, l’option -m permet d’écrire un commentaire. Si vous ne la spécifiez pas, l’éditeur par défaut du système sera ouvert afin de vous permettre de le faire. On peut ensuite vérifier le résultat avec la commande git log.

Si vous êtes un utilisateur de SVN, vous pouvez jeter un œil à ce guide afin de faire le pont avec les commandes de Git. Vous pouvez aussi lire la Cheat Sheet (SVG, Medium PNG, Large PNG).

Ceci était une introduction basée sur ma courte expérience, dans le prochain article je parlerais de GitHub, un service d’hébergement pour Git. Si vous avez des compléments d’informations à donner sur Git elles sont les bienvenues.

Articles relatifs

• Mise à jour de mon environnement de développement
• GitHub, vos dépôts distants pour Git
• Ruby On Rails est ce qu’il vous faut !
• Rails 1.2.2 et petite note sur Globalize
• Globalize Rails Core team

Il faut bien se rendre compte que dans le cas d’une application à forte charge comme celle-ci, beaucoup d’aménagements ont dû être fait afin d’essayer d’en optimiser les performances. Twitter n’est pas si simple et ce n’est pas un changement de langage qui y changera quelque chose, en déplaise à tous les trolleurs et autres développeurs à l’esprit étroit qui pense qu’il y a un langage universel. Utiliser Ruby, PHP ou Java est un choix, chaque plateforme à des avantages et inconvénients, aux développeurs de trouver celui qui leur convient le mieux dans un contexte précis.

Update : Vue mon état  semi-comateux (bronchite viral, une température ayant du mal à passer en dessous de 39°C depuis deux jours) ce message de Matt Aimonetti sur la mailing-list de Rails France m’a échappé, il donne quelques éclaircissements sur le sujet. Merci à Nicolas pour avoir fait passé l’info (et moi je ne suis pas en état de ne pas dire du mal des trolleurs professionnels).

Articles relatifs

• Ruby On Rails est ce qu’il vous faut !
• Rails, version 1.1.2
• Rails 1.2.2 et petite note sur Globalize
• Rails 1.2, quoi de neuf ?
• Rails 1.1, quoi de neuf ?

Je vous conseille vivement d’essayer NetBeans 6.0 ou 6.1 comme IDE pour le développement d’une application Ruby on Rails. Après avoir longtemps utilisé Eclipse il m’a fallu un temps d’adaptation mais j’ai rapidement été séduit par le fonctionnement et l’ergonomie de ce logiciel qui s’ouvre enfin à d’autres langages que Java.

Avec un peu de chance cette publication va me motiver à publier plus souvent du contenu sur ce blogue (car c’est pas les sujets qui manquent).

Articles relatifs

• Mise à jour de mon environnement de développement
• Ruby On Rails est ce qu’il vous faut !
• Rails, version 1.1.2
• Rails 1.2.2 et petite note sur Globalize
• Rails 1.2, quoi de neuf ?

Je ne ferais pas de résumé de la conférence, d’autre l’ont fait avant moi :

• L’article du groupe IDG sur InfoWorld en anglais (j’espère ne pas pas avoir dit trop de conneries).
• Le blogue de Sunny Ripert.
• Le blogue de Christian Corsano.
• Le blogue de Fréderic Delorme.
• Le blogue de Hortis (article par Laurent Bois).
• Petit entretient avec DHH fait à l’occasion de Paris on Rails et de son intervention par vidlo-conférence.

Pour terminer l’article sur LinuxFr après la sortie de Rails 2.0 le 7 décembre (la version 2.0.2 est sortie le 18 décembre avec quelques corrections et l’utilisation de sqlite3 par défaut au lieu de MySQL entre autre).

Articles relatifs

• Ruby User Group pour la Suisse Romande
• Préparation de Paris on Rails 2007
• Globalize @ Paris on Rails
• Ruby On Rails est ce qu’il vous faut !
• Rails, version 1.1.2

J’aurai également le privilège de faire une présentation au sujet de l’internationalisation des applications et de Globalize afin de mieux vous préparer au développement d’une application multilingue.

Une belle journée dont le prix est de 70 € jusqu’au 15 novembre 2007, 100 € pour ceux qui voudraient s’y prendre au dernier moment. Je vous recommande donc fortement de vous y rendre (et si vous allez au Web 3, faite d’une pierre deux coups).

Articles relatifs

• Ruby On Rails est ce qu’il vous faut !
• Rails 1.2.2 et petite note sur Globalize
• Préparation de Paris on Rails 2007
• Après Paris on Rails 2007
• Mener plusieurs projets de front

J’ai sorti la version 0.2.0 aujourd’hui, voici les nouveautés :

• Utilisation de la class ‘Logger’ pour le système de log (la sortie standard est utilisé par défaut, mais lors des tests un fichier de log est utilisé).
• Ajout de callbacks lors des événements.
• Ajout d’une tâche ’server’ au Rakefile afin de lancer le serveur d’exemple.
• Plurialisation du nom des méthodes ‘Tserver.listeners’ et ‘TServer.waiting_listeners’.
• Une méthode ‘reload’ a été ajouté afin de permettre de redémarrer le serveur sans coupure du service.
• ‘TServer.process’ ne prend plus d’argument et les méthodes suivantes sont maintenant disponibles : ‘TServer.connection’, ‘TServer.connection_addr’ et ‘TServer.terminate_listener?’.
• Un certain nombre de corrections ont étés faites et les tests améliorés.

Les sources et un gem sont disponibles depuis le trac du projet, j’espère pouvoir ajouter le gem à rubyforge bientôt.

Le serveur fonctionne bien, bien que je ne l’ai pas encore testé dans des conditions réels. Je pense que je devrais faire une class pour les Listener, ceci permettrais d’être plus facilement “thread  safe” en plus d’un certain nombre davantage pour l’implémentation je pense. Par contre, j’ai de la peine à évaluer les incidences sur les performances. Ce changement serais important, je vais y réfléchir et décider si je prends cette option dans le but de sortir une version 1.0.

Naturellement tout commentaire est le bienvenu.

Articles relatifs

• Créer un serveur TCP multithread en Ruby
• Mise à jour de mon environnement de développement
• Git, une petite introduction
• Variable aléatoire et répartition selon la loi normale
• Site officiel de Ruby en français

I have registered to play in the PokerStars World Blogger Championship of Online Poker!

This Online Poker Tournament is a No Limit Texas Holdem event exclusive to Bloggers.

Registration code: 6494624

Articles relatifs

• Petit tournoi entre amis
• Blog poker tour
• Pourquoi je joue au poker ?
• Poker, jeu de hasard ou d’adresse ?
• EPT de Londre: table TV en direct

Pour ma part je me suis remis au poker, même si je n’ai pas beaucoup de temps (1 ou 2 heures en soirée de temps en temps, un peu plus en fin de semaine), je me suis mis au CG en NL10 mais je fait quelques Sit&Go et tournois pour le plaisir, pour l’instant ça ne se passe pas trop mal, mais il ne sert à rien de faire un bilan après à peine plus de 1000 mains.

Articles relatifs

• Poker, jeu de hasard ou d’adresse ?
• Petit tournoi entre amis
• Blog poker tour
• World Blogger Championship Of Online Poker 2007
• Pourquoi je joue au poker ?

Bien sur créer un serveur TCP acceptant des connections tient en 2 lignes :

<br /> server = TCPServer.new('127.0.0.1', 10001)<br /> socket = server.accept<br />

Mais un serveur comme celui-ci est un peu limité (surtout quand il doit accepter 2000 connections toutes les deux minutes), la suite est logiquement de trouver une solution multithread permettant de recevoir plusieurs connections simultanément. On trouve GServer dans la libraire standard de Ruby qui permet d’implémenter ceci très facilement (exemple tiré de la documentation) :

<br /> require 'gserver'</p> <p>#<br /> # A server that returns the time in seconds since 1970.<br /> #<br /> class TimeServer < GServer<br /> def initialize(port=10001, *args)<br /> super(port, *args)<br /> end</p> <p>def serve(io)<br /> io.puts(Time.now.to_i)<br /> end<br /> end</p> <p># Run the server with logging enabled (it's a separate thread).<br /> server = TimeServer.new<br /> server.audit = true # Turn logging on.<br /> server.start<br /> server.join</p> <p># *** Now point your browser to http://localhost:10001 to see it working ***<br />

Si cette solution fonctionne mais j’ai tout de même rencontré quelques problèmes, pour commencer la méthode “shutdown” ne fonctionne pas correctement et ce serveur crée un nouveau Thread à chaque connexion et le détruit une fois les traitements de celle-ci terminé. Et vu que j’étais intéressé par faire quelques expériences avec les Thread de Ruby j’ai décidé de créer mon propre serveur multithread avec les spécifications suivantes :

• Thread persistants en attente de connexions.
• Gracefull shutdown.

Ce petit teste à finalement donnée naissance à une librairie complète, la classe TServer permet maintenant de créer un serveur multithread pouvant être arrêté en douceur et dont les listener (Thread traitant les connections) sont persistants. Lors de l’initialisation il est possible de configuré le nombre maximum de connections que le serveur peut traiter en même temps et le nombre de listener qui doivent toujours être à l’écoute (il est possible de configurer cette variable à 0 pour avoir un comportement identique à GServer).

L’utilisation des Thread est intéressant, mais demande de faire attention à ce qu’on fait (le contenu des variables n’est pas toujours celui auquel on s’attend) et à bien utiliser les outils de synchronisation à notre disposition (Monitor, Mutex, ConditionVariable, Queue). Faire des testes unitaires n’est pas évident puisqu’il est difficile de tester un serveur dont on ne connait pas l’état actuel. J’ai pu m’en sortir en contrôlant l’évolution du serveur avant de faire certains testes et en utilisant la classe Timeout pour m’assurer que son état change dans un temps raisonnable. Je ne suis pas complètement satisfait du résultat et j’ai probablement encore des choses à découvrir pour le faire correctement (pour l’instant je n’arrive pas a faire passer les testes sous Windows, apparemment ils attendent sur quelque chose lors d’un test et je doit tuer le process).

Mon prochain objectif est de remplacer le système de log (utilisation de la librairie logger et utilisations de diverses méthodes afin de permettre la collecte de stats plus complète comme dans GServer), mais également de permettre un reload du serveur sans interruption du service. En attendant, voici un exemple d’implémentation de TServer (tiré de la documentation) dont j’ai mis les sources et un gem à disposition ici :

<br /> require 'tserver'</p> <p># A server can return<br /> class ExempleServer < TServer<br /> def serve(conn)<br /> conn.each do |line|<br /> break if line =~ /(quit|exit|close)/</p> <p>log '> ' + line.chomp<br /> conn.puts Time.now.to_s + '> ' + line.chomp<br /> end<br /> end<br /> end</p> <p># Create the server with logging enabled (server activity is displayed<br /> # in console with received data)<br /> server = ExempleServer.new<br /> server.verbose = true</p> <p># Shutdown the server when script is interupted<br /> Signal.trap('SIGINT') do<br /> server.shutdown<br /> end</p> <p># Start the server (joined is set to true and the line wait on server<br /> # thread before continue, the default values of this parameter is set to<br /> # false, you can also use 'server.join' after server.start)<br /> server.start(true)</p> <p># Now you can open a telnet connection to 127.0.0.1:10001 (telnet 127.0.0.1 10001)<br /> # and send text (use exit to close the connection)<br />

Articles relatifs

• TServer 0.2.0
• Mise à jour de mon environnement de développement
• Git, une petite introduction
• Variable aléatoire et répartition selon la loi normale
• Site officiel de Ruby en français