mercredi 27 avril 2011

Un tuto pour apprendre Ruby

Ruby est un langage interprété orienté objet et un environnement d'exécution permettant l'exécution des programmes écrit dans ce langage.

Ce tutorial permet d'en savoir plus sur le langage et la façon de programmer.

samedi 23 avril 2011

Installer Ruby 1.9.2 et Rails 3 sur Ubuntu 10.04

Dans le cadre d'une démarche de découverte de l'environnement Ruby et Ruby on Rails, j'ai été confronté au problème d'installation. En effet, sur la version 10.04 de Ubuntu, difficile d'installer la dernière version de cet environnement. Voici la recette qui a marché pour moi.

Installer Ruby 1.9.2


La version de l'environnement Ruby disponible dans les dépôts n'est pas assez récente pour les étapes à venir, donc il faut désinstaller tout ce que avoir été installé auparavant pour repartir sur une base saine.

Installation de RVM


Ruby enVironnement Manager et un script permettant d'installer et gérer plusieurs version de l'environnement Ruby. Son installation se fait en lançant la commande suivante:

$> sudo bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

Installation de Ruby 1.9.3


En utilisant RVM, on peut installer Ruby via la commande suivante:

$> sudo rvm install ruby-1.9.2

Finalisation de l'installation


Il faut maintenant ajouter l'environnement RVM via le fichier .bashrc
Remplacer :

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

Par :

# If not running interactively, don't do anything
if [[ -n "$PS1" ]] ; then
[[ -s "/usr/local/rvm/scripts/rvm" ]] && source "/usr/local/rvm/scripts/rvm" # This loads RVM into a shell session.
fi

Positionner la version courante de Ruby


Il faut maintenant indiquer la version courante de Ruby à employer via la commande suivante :

$> sudo rvm --default ruby-1.9.2

Installer Rails 3


Ruby est accompagner d'un utilitaire gem. Ce dernier est un gestionnaire de paquet propre à Ruby. Ainsi, un logiciel est empaqueter dans une archive (un gem) puis mise à disposition et peut être installer via l'utilitaire du même nom. Nous allons installer Rails via cette commande:

$> sudo gem install rails

J'utiliserai une base de données MySQL par la suite, j'installe donc les drivers adéquats:

$> sudo apt-get install libmysqlclient16-dev
$> sudo gem install mysql
$> sudo gem install mysql2

Tester l'installation


Rails permet de créer un projet via la commande suivante:

$> rails new /path/to/project -d mysql

Pour lancer le serveur et tester l'application:

$> rails server

Il ne reste plus qu'à naviguer vers la page http://localhost:3000/

Conclusion


L'installation, bien que plus compliquée qu'un simple «apt-get install», reste assez bien outillée. D'autres ticket viendrons tracer mes premiers pas sur ce nouveau continent.

jeudi 21 avril 2011

JConsole & Weblogic

Un article qui m'a été fort utile pour me connecter sur des instances weblogic afin d'en visualiser les entrailles à distance.
Tout est là.

vendredi 15 avril 2011

L'effaceur

Comment tuer certains processus lancés par un utilisateur ?

$> ps -aef | grep ^<USERID> | grep <PROCNAME> | awk '{ print "kill -9 " $2 }' | sh

Où <USERID> représente l'identifiant de l'utilisateur ayant lancé ses processus, et <PROCNAME> représente le nom du processus lancé par <USERID>.

Supprimez le dernier tube pour voir les commande que vous auriez lancées «manuellement» pour faire la même chose.

vendredi 1 avril 2011

«Git, dessine moi un mouton»

Il y a quelques mois je découvrai Git, un gestionnaire de sources distribué dont la réputation croît en ce moment. Ayant déjà vécu la montée en puissance de Subversion au détriment de CVS, je voulais me rendre compte des qualités/défauts du nouveau challenger.

Une nouvelle philosophie


Git fait partie de la famille des contrôleurs de sources distribués. Cela se traduit principalement par le fait que chaque membre d'une équipe collaborant à un même projet est en possession d'un dépôt contenant l'ensemble de l'historique du projet. Les publications se font ainsi en local, ne nécessitant alors aucune connectivité réseau. Seul les échanges entre dépôts se font via le réseau.
Une première question vient alors à l'esprit : Si tout le monde est un dépôt, d'où provient la version de l'application à livrer ? Plusieurs organisation sont possibles à ce sujet:

  • Une organisation par cercle de confiance, comme par exemple pour le développement du noyau Linux, où un membre de l'équipe représente le dépôt de référence que tout le monde utilise pour compiler sa version du noyau, alimenté par les dépôts de plusieurs lieutenant possédant chacun un dépôt alimenté par des dépôts considérés par ses derniers comme étant de confiance.

  • L'outil est suffisament souple pour reproduire les mécanismes des dépôts centralisés. Un dépôt sur un serveur sert de référence, utilisé par exemple par un automate de compilation permettant d'assurer une intégration continue des sources du projet, les développeurs de l'équipe déposent alors des lots de publication sur ce dépôts lors de chaque instruction git push

  • et bien d'autres ...


Une autre question suvient : Comment se joindre à un projet ? Il suffit tout simplement de cloner un dépôt avec la commande git clone /jango/fet.git et vous voilà avec un clone tout neuf, puis de commencer les développement. C'est un peu comme si chaque développeur avait forker le projet afin de produire une version. L'ensemble des développements publiés dans un dépôt représente alors un patch à appliquer aux autres dépôts pour contribuer au développement.

Une migration en douceur


Lors de la migration de CVS vers Svn, un utilitaire fournit (cvs2svn) permettait de migrer un dépôt CVS en dépôt Subversion tout en conservant l'historique. Une action one shot qui implique de synchroniser l'ensemble des membres de l'équipe utilisant le dit dépôt vers le nouvel outil.
Permier avantage de Git sur Svn : git-svn. Cet utilitaire fait la même chose que le précédent, c'est-à-dire de constituer un dépôt Git à partir d'un dépôt Subverion tout en conservant l'historique via la commande git svn clone. Mais il va plus loin en conservant une connectivité avec le dépôt Subversion lui servant d'origine. Ainsi le dépôt git et maintenu à jour en continu avec la commande git svn rebase.
Cela va encore plus loin en permettant de publier les commit effectués dans le dépôt Git vers le dépôt Subverion via la commande git svn dcommit. De cette manière, un développeur peut se mettre à utiliser Git tout en continuant de collaborer à un projet dont le référentiel de source est Subversion (ce que je fit pendant plusieurs mois).

Un bénéfice au quotidien


«Git est un nouvel outil!
- d'accord
-Il est plus fashion!
- OK, mais encors?»

«Wiiiilsooooon !!!!»


On peut aussi tout simplement utilser Git en mode seul au monde pour historiser tout ce qui se trouve sur un ordinateur. La création d'un dépôt se fait avec la commande git init, puis ont ajoute les fichiers à historiser via la commande git add monprecieux.fic puis on plublie les modification via la commande git commit. Pas besoin d'un serveur où d'un dépôt à créer et/ou administrer. C'est simple et efficace et l'on peut s'en servir pour maintenir l'historique des fichiers de configuration sur un serveur (<troll>bein oui un serveur Linux/UNIX, comment on ferait pour historiser les clics droits sous Windows®</troll>) et tout projet sandbox commencé mais jamais terminé. Je m'en sert également pour réaliser des kit de démarrage afin de savoir toutes les étapes que j'ai franchies et ainsi produire une documentation exhaustives.

«Release Early, Release Often»


Ce principe de livraison fréquente peut être appliquer au niveau du développeur qui va pouvoir publier fréquement ces modifications induisant ainsi une meilleur qualité de ces publications (fini le fichiers qui manquent, les modifications oubliées dans un coin ne sachant pas si elles concernaient la tâhes en cours, ...). Chaque modification faisant progresser le code d'un état stable à un autre (bien qu'intermédiaire) doit faire peut faire l'objet d'un commit ce qui n'est pas envisageable sur un projet centralisé.

Un build incassable


Cette capacité à pouvoir publier sans retenue permet la mise en oeuvre du build incassable. Dans la mesure où seul le dépôt local est touché par ces modifications une sécurité m'est offerte en clonant mon propre dépôt dans un endroit de mon ordinateur et en construisant mon projet à partir de ce clone afin de constater la fiabilité des mes développements avant le partage de mes travaux.

«cou roucoucou roucoucou stach stach»


Il y a des moments où le travail suit son cours, le soleil est radieux, la journée a bien commencé, quand tout à coup le ciel s'obscurci, un bug en prod doit être fixé de toute urgence sinon c'est la fin du monde. Avec SVN il me fallait alors créer une nouvelle copie de travail (ce qui peut être long sur de très gros projet) puis la supprimer une fois l'urgence traitée. Où alors de créer un patch, annuler toutes mes modifications en cours puis appliquer le patch après la tempête.
La commande git stash permet ainsi de mettre de côté (to stash = planquer) les modifications en cours pour repartir d'une version clean de la copie de travail puis de reprendre les travaux au moyen de la commande git stash pop, tout ceci avec une efficacité sans précédent pour moi.

Conclusion


En conclusion, je n'ai pas listé beaucoup de défauts (aucun pour être précis) mais je noterai tout de même l'effort à produire pour changer d'habitude et notamment le changement de philosophie induit par la distribution des dépôts.
Je m'y met de plus en plus serieusement ce qui implque d'autres publications à l'avenir sur cet outil qui fait maintenant parti de mes meilleurs amis en tant que développeur.