Si vous utilisez Active Admin pour générer vos interfaces d’administration sous Rails, voici une technique pour définir des ressources depuis un engine.

Définir la ressource

Pour une question de simplicité, je place mes ressources dans un dossier admin situé dans le dossier lib/my_engine de mon engine.

# lib/my_engine/admin/articles.rb
if defined?(ActiveAdmin)
  ActiveAdmin.register Article do
    # personnalisez ici votre ressource
  end
end

Charger la ressource

Le problème auquel j’ai été confronté au début était celui du chargement de cette ressource.

Naïvement, je l’avais placée dans app/admin/articles.rb dans mon engine mais elle n’était pas chargée par l’application. Je l’ai ensuite placée dans lib/my_engine/admin et ai appelé require dessus. Le problème est que le modèle Article n’était pas encore défini au moment de l’appel à register.

J’ai donc fait appel à after_initialize dans la définition de l’engine:

# lib/my_engine/engine.rb
module MyEngine
  class Engine < Rails::Engine
    config.after_initialize do
      require 'my_engine/admin/articles'
    end
  end
end

Ce n’est peut être pas la solution la plus optimale ou la plus propre. Je serais d’ailleurs ravi d’avoir une solution alternative plus efficace. Celle-là a le mérite de fonctionner : ).

Requêtes N+1

Lorsque vous développez avec Rails, vous devez bien sûr faire attention aux requêtes qui sont effectuées et surtout éviter les requêtes N+1.

Les requêtes N+1 sont celles qui sont lancées pour chaque élément d’une liste.

Prenons l’exemple suivant :

# Dans le contrôleur

@articles = Article.all
# SELECT articles.* FROM articles

# Dans la vue

<% @articles.each do |article| %>
  ...
  Nombre de commentaires: <%= articles.comments.count %>
  # SELECT COUNT(*) FROM comments WHERE comments.article_id = XY
  ...
<% end %>

Pour chaque article listé, une requête va être lancée pour compter ses commentaires.

Heureusement pour nous, Rails fournit, dans l’API d’ActiveRecord un moyen d’éviter ces requêtes N+1. Il s’agit de la méthode includes qui s’utilise comme ceci :

@articles = Article.includes(:comments).all
# SELECT articles.* FROM articles
# SELECT comments.* FROM comments WHERE comments.article_id IN (1, 2, ..., 42)

On peut donc voir ici que l’ensemble des commentaires est récupéré d’un seul coup. Cela nous permet d’accéder aux informations des commentaires d’un article sans requête supplémentaire.

Size vs. Count

Le souci c’est que ça ne règle pas notre problème de count. En effet, si nous faisons de nouveau appel à count, les requêtes seront tout de même effectuées !

L’astuce est donc d’utiliser size plutôt que count sur l’attribut comments de nos articles, ce qui va simplement retourner la taille du tableau contenant les commentaires associés. Ces derniers étant déjà chargés, le compte est bon !

# Dans le contrôleur

@articles = Article.includes(:comments).all
# SELECT articles.* FROM articles
# SELECT comments.* FROM comments WHERE comments.article_id IN (1, 2, ..., 42)

# Dans la vue

<% @articles.each do |article| %>
  ...
  Nombre de commentaires: <%= articles.comments.size %>
  ...
<% end %>

Si vous vous retrouvez dans le besoin de faire des imports de données ou des insertions scriptées dans une application Rails, de nos jours vous n’avez pas vraiment d’autre choix que de créer des tâches rake (ou consorts) pour le faire.

Dans cette idée, j’ai écrit la gem versioned_seeds qui permet de stocker ces scripts dans un dossier spécifique et de les utiliser à la manière des migrations.

Son installation se fait grâce à l’ajout de la ligne suivante dans votre Gemfile :

gem 'versioned_seeds', require: false

Le principe est simple, vous appelez un générateur qui va créer au besoin le dossier et un script dans celui ci. Le nom du script commence par un timestamp, comme les migrations, ce qui va permettre à versioned_seeds de l’enregistrer et de ne pas l’exécuter plusieurs fois.

rails g versioned_seeds:seed_file nom_du_script
        create db/seeds
        create db/seeds/20111207201942_nom_du_script.rb

Vous n’avez plus qu’à écrire votre script puis, une fois terminé, à appeler une tâche rake qui va l’exécuter:

rake vs:next

Cette tâche va trouvé le prochain script non chargé jusqu’à présent et le lancer. Si vous avez généré plusieurs scripts, vous pouvez faire appel à

rake vs:all

Qui va les lancer un-à-un.

Pour savoir où vous en êtes de vos scripts, vous pouvez faire appel à

rake vs:status

Pour connaitre la version du dernier script chargé.

Pensez simplement à ignorer le fichier .versioned_seeds dans Git, il sert à stocker la liste des scripts déjà lancés et il ne doit pas être versionné puisqu’il est spécifique à chaque machine.

Le code est disponible sur Github et la gem sur rubygems.org.

Il y a quelques temps, j’avais besoin de lancer un script ruby avec cron. Le souci, c’est que sur mon serveur, tout est à base de rvm. De fait, cron ne sait pas trouver ruby puisque rvm est chargé par mon fichier .bashrc.

La petite astuce pour que ça marche, c’est de dire à cron de charger mon environnement pour ce script spécifiquement :

0 * * * * /bin/bash -l -c 'ruby mon_script.rb'

En clair, l’option -l permet de charger l’environnement bash et l’option -c indique la commande à exécuter.

Git permet d’afficher différentes informations en couleur. Cela se fait dans le fichier de configuration, ~/.gitconfig.

[color]
  ui = true

Une des commandes concernées est git-diff. Cette coloration est bien pratique mais peut avoir ses limites. En effet, lorsque la différence sur une ligne se joue à quelques caractères seulement, il peut être difficile de détecter les modifications.

  Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
  tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
- quis nostrud exercitation ullamco labaris nisi ut aliquip ex ea commodo
+ quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
  consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
  cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat
  non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Une petite astuce pour les voir plus précisément est l’utilisation de l’option –word-diff

git diff --word-diff=color

Voici le résultat obtenu :

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
quis nostrud exercitation ullamco laboaris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat
non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

L’option prend différentes valeurs qui peuvent être utiles selon les circonstances.

Une fonctionnalité bien pratique de OSX_ est la gestion du PATH. En effet un mécanisme permet de ne pas surcharger son .bashrc chaque fois que l’on doit rajouter une entrée dans le PATH.

La magie s’opère dans le fichier /etc/paths et dans le dossier /etc/paths.d.

Le premier est un listing des chemin généraux :

/usr/bin
/bin
/usr/sbin
/sbin

Le deuxième est un dossier permettant d’ajouter des fichiers contenant des listings en plus. Ces fichiers seront chargés à la suite de /etc/paths.

Exemple

Si vous avez installé MySQL avec le DMG fourni sur le site officiel, vous pouvez ajouter le chemin des exécutables mysql en créant un fichier /etc/paths.d/mysql et y écrire la ligne suivante :

/usr/local/mysql/bin

Collision

Si vous vous trouvez dans la situation où vous avez un exécutable dans un dossier non système et que vous souhaitez que ce dossier ait la priorité, mettez le en tête du fichier /etc/paths, les chemins sont chargés dans l’ordre.

En Ruby, il existe une méthode bien pratique nommée inject. Elle s’utilise de la manière suivante :

puts (0..10).inject(0) do |somme, x|
  somme += x
end
# => 55

Dans l’exemple précédent, on part d’une valeur de 0 que l’on modifie à chaque tour. Le code suivant est équivalent :

somme = 0
(0..10).each do |x|
  somme += x
end
puts somme
# => 55

De manière classique, on peut s’en servire pour générer un tableau ou une table de hash de la manière suivante :

@articles.inject({}) do |hash, article|
  hash[article.title] = article.body
end

Une autre utilisation interessante, est avec les booléens :

@plugins.inject(true) do |keep_going, plugin|
  keep_going &= plugin.some_method
end

On obtient donc en fin de parcours, true si tous les appels ont retourné true ou false si au moins un appel a retourné false.

Dans le cas où on veut stoper l’appel à inject dés qu’un appel retourne false, on peut utiliser l’instruction break :

@plugins.inject(true) do |keep_going, plugin|
  keep_going &= plugin.some_method or break(keep_going)
end

Cela permet de ne pas faire les appels suivants dés le premier retour négatif.

Un comportement plutôt gênant sous OS X est la création des fichiers ._ (point underscore). C’est souvent un problème quand on veut créer une archive .tar.gz ou avec certains SCM.

Voici une solution pour empêcher leur création.

Dans votre .bashrc et votre .profile, ajoutez la ligne suivante :

export COPYFILE_DISABLE=true

Chaque fois que j’installe un shell sous Mac OS X et que je le règle par défaut gràce à chsh, l’application Terminal refuse de se lancer et me dit :

Vous n’êtes pas autorisé à lancer cette application.
L’administrateur a donné à votre shell une valeur illégale.

Pour régler ce petit souci, il suffit d’ajouter le chemin vers votre shell dans le fichier /etc/shells :

cat /etc/shells
# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
# one of these shells.

/usr/local/bin/bash # bash installé avec homebrew
/bin/bash
/bin/csh
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh

C’est une erreur que l’on ne rencontre pas lorsque l’on utilise un terminal comme iTerm 2…

Il arrive qu’on ait besoin d’utiliser la sortie d’une commande comme si c’était un fichier. Voici une petite astuce pour ne pas passer par un fichier temporaire.

diff <(ls /un/dossier/au/pif) <(ls /un/autre/dossier/au/pif)

Et voilà avec cette syntaxe on a la différence entre deux dossiers sans utiliser de fichiers temporaires.

Sous Snow Leopard, l’installation de la gem mysql n’est pas toujours simple. Voici ce que j’utilise, sachant que mon MySQL est installé via le DMG fourni sur le site officiel.

export ARCHFLAGS="-arch i386 -arch x86_64";
sudo gem install mysql -v2.7 --no-rdoc --no-ri --         \
   --with-mysql-dir=/usr/local/mysql                      \
   --with-mysql-config=/usr/local/mysql/bin/mysql_config

Il y a quelques jours j’ai réinstallé un Snow Leopard sur un Mac Mini.

Lorsque j’ai lancé iTerm et TextMate, la police Monaco que j’utilise dans les deux n’était pas tout à fait comme d’habitude, plus fine et moins agréable.

Cela vient d’un bug Snow Leopard qui ne reconnait pas toujours les LCD : il les voit comme des écrans CRT et désactive l’anti-aliasing sur les polices !

Pour régler ce souci, tapez simplement ceci dans une console :

defaults -currentHost write -globalDomain AppleFontSmoothing -int 2

La prochaine fois que vous lancerez iTerm ou TextMate, ça devrait être bon.

Depuis la version 1.5 de Subversion, la résolution des conflits se fait de façon interactive lorsque l’on utilise svn update.

svn update
Conflict discovered in 'some/file/located/somewhere.rb'.
Select: (p) postpone, (df) diff-full, (e) edit,
        (h) help for more options:

Personnellement, je ne supporte pas ce nouveau mode. Je préfère de loin faire un update complet et corriger les conflits à posteriori.

Pour le faire de manière ponctuelle l’option –non-interactive permet d’obtenir ce comportement.

svn update --non-interactive

Pour le faire de manière permanente, éditez votre ~/.subversion/config et ajoutez la ligne suivante dans la section miscellany :

[miscellany]
...
interactive-conflicts = no

Aujourd’hui, j’ai eu besoin de surcharger une méthode Javascript. Premier réflexe, réécrire la fonction en y ajoutant le code voulu.

Soit le code qui suit :

mon_objet.fait_le_café = function() {
  var tasse = prendre_une_tasse();
  tasse.verser_café();
  tasse.faire_chauffer();

  return tasse;
}

Afin d’ajouter du sucre, on pourrait surcharger de la façon suivante :

mon_objet.fait_le_café = function() {
  var tasse = prendre_une_tasse();
  tasse.verser_café();
  tasse.faire_chauffer();

  tasse.ajouter_sucre();

  return tasse;
}

Jusque là, rien d’inhabituel. Mais quid du code propre, simple et surtout DRY ?

Voici donc une façon plus élégante d’obtenir le même résultat en écrivant juste le code nécessaire :

mon_objet.fait_le_café_sans_sucre = mon_objet.fait_le_café;

mon_objet.fait_le_café = function() {
  var tasse = mon_objet.fait_le_café_sans_sucre();

  tasse.ajouter_sucre();

  return tasse;
}

C’est tout simple, ça fonctionne et c’est DRY…

Pour information, l’idée m’est venue du framework Ruby On Rails (en) et de sa méthode

alias_method_chain (en)

J’ai eu l’occasion de me prendre un petit moment la tête aujourd’hui sur comment utiliser des feuilles de styles SASS au sein de thèmes dans une application Rails.

Pour la gestion des thèmes, j’ai utilisé theme_support qui permet de créer, pour chaque thème, un dossier ayant l’arborescence suivante :

un_theme
├── images
|   └── preview.png
├── javascripts
├── stylesheets
├── views
└── about.markdown

Ce que je cherchais à faire était de pouvoir mettre des fichiers SASS dans le dossier stylesheets, mais que les CSS compilées soient placées dans <app_root>/public/stylesheets.

Le plus simple moyen que j’ai trouvé pour faire ça, est d’ajouter le script suivant dans >app_root>/config/initializers/theme_sass.rb :

# :template_location est normalement une String, on la convertie donc en Array
Sass::Plugin.options[:template_location] = [[Sass::Plugin.options[:template_location], Sass::Plugin.options[:css_location]]]

# Pour chaque thème, on ajoute son dossier stylesheets à la liste des sources SASS
Theme.find_all.map(&:name).each do |theme|
  Sass::Plugin.options[:template_location] << ["#{RAILS_ROOT}/themes/#{theme}/stylesheets", Sass::Plugin.options[:css_location]]
end

Depuis quelques jours maintenant, Firefox 3.6 est sorti. Cette nouvelle version apporte un certain nombre de nouveautés, dont certaines qui peuvent être déroutantes (<troll>le nouveau système de skins uselessfull par exemple ?</troll>).

Bref ! Une nouveauté est l’ouverture des onglets relatifs (ouverture d’un lien de la page courante dans un onglet) à côté de l’onglet courant et non plus à la fin de la liste. Tout cela n’aurait rien de bien gênant si cette fonctionnalité pouvait être désactivée grâce à une simple case à cocher…

Voici un moyen simple de revenir à l’ancien fonctionnement.

Ouvrez l’URL about:config.

Dans la zone de filtre saisissez insertRelated cela devrait laisser seulement une entrée :

Double-cliquez dessus pour passer sa valeur à false.

C’est tout. Les nouveaux onglets devraient s’ouvrir maintenant en fin de liste.

EDIT: Je viens de trouver un lien avec quelques astuces supplémentaires

Quand on développe de nombreux sites, on n’a pas forcement envie de toucher à ses VirtualHosts pour chaque nouveau site.

Voici ce que j’ai mis en place sur mon serveur pour l’espace de démo de ce genre de sites.

Le but était d’avoir un dossier contenant un nombre non limité de dossiers nommés demo1, demo2, demo3, etc…

Pour cela, j’ai créé un dossier demos à la racine de mon serveur Apache. C’est ce dossier qui va contenir tous les dossiers demoXYZ.

J’ai ensuite ajouté un VirtualHost comme ceci :

<VirtualHost *:80>
  ServerName demos.exemple.com
  ServerAlias demo*.exemple.com
  DocumentRoot /var/www/demos

  <Directory />
    AllowOverride all
  </Directory>
</VirtualHost>

Le travail de dispatch entre les différents dossiers de démo est fait par un fichier .htaccess dans le dossier demos :

RewriteEngine On
RewriteCond %{HTTP_HOST} ^demo(\d+).exemple.com
RewriteCond %{REQUEST_URI} !^/demo
RewriteRule (.\*) demo%1/$1 [L]

Et voilà ! Après redémarrage du serveur, tout devrait fonctionner.

Dernièrement, lors de la copie de fichiers depuis le disque dur d’une amie, je me suis retrouvé avec de nombreux fichiers verrouillés. Verrouillés au sens OS X du terme.

Il est possible pour chaque fichier d’afficher ses infos et de décocher la case de verrouillage.

Mais lorsque cela concerne une centaine, ou un millier de fichiers, d’un coup, cocher une simple case peut devenir quelque peu fastidieux.

Pour effectuer cette action en ligne de commande, il suffit d’utiliser la ligne suivante :

chflags nouchg <fichiers>

Pour gérer l’upload de fichiers dans les applications Rails, un plugin fréquemment utilisé est Paperclip. Récemment, lors du développement d’un projet, je me suis retrouvé confronté à un problème lors de l’envoie des fichiers. En effet, ça ne fonctionnait pas et je recevais un message d’erreur à chaque fois.

Après quelques recherches, j’ai fini par trouver que cette erreur venait du fait que mon application ne trouvait pas son chemin vers les outils d’ImageMagick dont Paperclip dépend au travers de Rmagick.

Pour résoudre ce problème, il suffit d’ajouter un initialiseur à l’application.

J’ai donc ajouté le fichier RAILS_ROOT/config/initializers/paperclip.rb contenant ceci :

Paperclip.options[:command_path] = '/opt/local/bin'

J’ai utilisé ce chemin car j’ai installé ImageMagick en utilisant MacPorts.

Lorsque l’on édite un fichier, il peut arriver qu’en plus de simples modifications, certaines portions, voire le fichier entier, soient re-indentées. Malheureusement, Subversion étant bête et discipliné, un svn diff montrera les lignes modifiées mais également les lignes simplement indentées.

Cela peut devenir gênant lorsque, par exemple, tout le fichier s’en retrouve changé.

Pour ignorer ces différences d’espaces lors d’un diff, la commande à utiliser est la suivante :

svn diff --extensions -bu

Si vous utilisez des fichiers dont le nom contient des accents sur un dépôt SVN, vous avez de grandes chances de rencontrer quelques soucis sous Mac, si vous avez installé Subversion avec MacPorts. Le problème vient de la différence de stockage des caractères unicode entre les plateformes Unix et OS X.

Voici comment résoudre ce problème. C’est très simple, il suffit d’installer une variante du port subversion.

port install subversion +unicode_path

Si tout s’est bien passé, vous ne devriez plus avoir de problèmes.

NOTE: j’ai ajouté cette option dans la Formula subversion de Homebrew mais c’est toujours en attente de merge de leur part…

Lorsque l’on utilise un éditeur de texte particulier, on apprécie de pouvoir l’utiliser comme éditeur par défaut pour peu tout. Cela comprend également les messages de commit des outils tels que SVN ou Git.

Malheureusement, utiliser un éditeur graphique pour cela n’est pas toujours trivial.

La commande mate propose l’option -w qui permet de signifier que l’on veut attendre que TextMate en ait fini avec le fichier pour reprendre la main.

Il est vrai que TextMate intègre les fonctionnalités SVN et Git. Personnellement j'ai toujours préféré m'occuper de ces choses là en ligne de commande... chacun son truc...

Pour SVN

Il y a plusieurs façons de dire à subversion d’utiliser tel ou tel éditeur, le plus simple est de donner une valeur à la variable SVN_EDITOR :

export SVN_EDITOR="mate -w"

Pour Git

Pour rester dans l’utilisation habituelle de Git, on utilisera la commande suivante :

git config --global core.editor "mate -w"

Depuis plusieurs années maintenant, j’utilise pour lire mes mails le logiciel Thunderbird. Pratique et efficace, il n’en est pas moins doté de certains défauts plus que gênants…

L’un d’eux est que Thunderbird ne relève pas automatiquement les mails dans les sous dossiers. Cela devient très gênant lorsque l’on utilise un filtrage des messages à la source, autrement dit, côté serveur.

Il existe toutefois une solution. Il est possible de préciser, pour chaque dossier, que l’on souhaite que Thunderbird vérifie les nouveaux messages.

Pour ce faire, il suffit de faire un clic droit sur un dossier puis sur Propriétés….

Dans la fenêtre qui s’ouvre, cochez la case Surveillez les nouveaux messages dans ce dossier :

Voilà, à ce jour, le mieux que l’on puisse faire, mais c’est mieux que rien.

Voici deux petites astuces pour améliorer l’utilisation de ssh.

Complétion des noms d’hôtes

Pour obtenir la complétion des noms d’hôtes pour ssh et scp, il vous suffit d’installer le paquet bash-completion.

# Sous Debian et consorts
aptitude install bash-completion

# Sous Mac, avec macport
port install bash-completion

# Sous Mac, avec homebrew
brew install bash-completion

Alias

Il est possible de créer des alias pour les hôtes sur lesquels on se ssh. Cela se fait en éditant le fichier ~/.ssh/config :

Host somehost
  HostName     some.host.with.long.name
  User         someuser
  IdentityFile ~/.ssh/other_id_rsa

Ceci permet de se connecter à l’hôte some.host.with.long.name avec l’utilisateur someuser en utilisant la clé ~/.ssh/other_id_rsa :

ssh somehost

Comme de nombreux développeurs, je suis très souvent amené à utiliser SVN (Subversion). Comme de nombreux développeurs toujours, je suis amené à partir en mission chez différents clients qui ont chacun leur proxy. Pour peu qu’on en ait déjà un au boulot ou chez soi, ça devient vite fatiguant de jongler entre ces différentes configurations.

Voici donc une petite astuce toute bête pour se rendre la vie facile.

Configurer un proxy dans subversion

Première étape, savoir où se configure les proxies dans subversion. Tout cela se passe dans le fichier ~/.subversion/servers où l’on peut trouver les lignes suivantes :

# http-proxy-host = 
# http-proxy-port = 3128
# http-proxy-username = 
# http-proxy-password =

Comme on peut le voir, il est facile de configurer un proxy selon le serveur svn que l’on veut atteindre. C’est très bien, seulement ça ne nous aide pas. Nous ce n’est pas le serveur qui change mais l’environnement de travail !

Comment se sauver la vie

Tout d’abord il faut créer un fichier servers par environnement. Idéalement on les place dans le dossier ~/.subversion avec un nom comme env1_servers, env2_servers (en ce qui me concerne je prends 3 lettres représentatives de l’environnement).

Pensez à renommer le fichier servers existant, en def_servers par exemple car servers va devenir un lien symbolique vers le fichier qui nous intéresse.

On pourrait se contenter ce ça et s’amuser à appeler ln -s à tout bout de champ, voir même créer un alias comme “ln -s ~/.subversion/env1_servers ~/.subversion/servers” mais honnêtement, une solution pérenne (quel horrible mot) serait bien plus agréable.

Voici donc une petite fonction shell qui va nous faciliter grandement la vie !

# switch de profile svn
svnpro() {
  if [ -f ~/.subversion/$1_servers ]; then
    ln -nfs $1_servers ~/.subversion/servers
  else
    echo "$1\_servers n'existe pas."
  fi
}

Et voila, il nous suffit maintenant de l’appeler de la manière suivante et notre configuration de proxy changera.

svnpro env1
svnpro env2

Les diffs SVN peuvent parfois être longs et souvent pénibles à lire. Oui il y a des + et des - mais ça ne fait pas tout. Un bon moyen de simplifier cette lecture est l’utilisation de couleurs.

Un utilitaire bien sympathique, colordiff, permet justement de coloriser l’affichage des diffs. Packagé sous Debian ou disponible via MacPort.

Voici comment l’utiliser pour les diffs SVN.

Pour une utilisation occasionnelle :

svn diff --diff-cmd colordiff

ou

svn diff | colordiff

Pour l’établir de manière globale, il suffit d’éditer le fichier ~/.subversion/config et d’ajouter dans la section helpers :

diff-cmd = colordiff

EDIT: Pour afficher la sortie de colordiff dans less, il faut utiliser l’option -R de ce dernier :

svn diff | less -R

Pour aller plus loin, un autre utilitaire permet de coloriser bien plus de choses, il s’agit de colorsvn.

Il peut arriver que, sur un projet, chacun utilise son propre IDE. Le petit problème c’est que chaque IDE crée des fichiers qui lui sont spécifiques. Lorsque l’on utilise Subversion, gérer les svn:ignore devient vite lourd. Mais une solution existe ! Ignorer localement certains fichiers.

Je prendrai NetBeans comme exemple pour cet article.

Voici ce que l’on peut voir lors d’un svn status après la création d’un projet sous NetBeans depuis des sources existantes:

svn status
?      nbproject
M      some\_file

Dans le dossier ~/.subversion, il existe un fichier config. Dans ce fichier, sous le groupe miscellany, vous trouverez les lignes suivantes :

## Debian
# global-ignores = \*.o \*.lo \*.la \*.al .libs \*.so
#   \*.so.[0-9]\* \*.a \*.pyc \*.pyo \*.rej \*~ #\*# .#\* .\*.swp .DS\_Store

## Mac
# global-ignores = \*.o \*.lo \*.la #\*# .\*.rej \*.rej
#  .\*~ \*~ .#\* .DS\_Store

Il vous suffit de décommenter ces lignes et de rajouter les fichiers que vous souhaitez ignorer :

global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS\_Store nbproject

Voilà le résultat :

svn status
M      some\_file

En général, quand on me parle de remettre GRUB après une installation de Windows, la première chose à laquelle je pense est “bah tu mets un live-cd, tu montes ta partition /, tu te chroot et grub-install”.

En somme, ça se résume effectivement à ça. Mais, parfois, tout ne se passe pas comme prévu. En effet, lors de ma dernière expérience, lorsque je montais la partition / de ma Debian, aucune trace de hda ou sda. Rien du tout ! La raison, je ne la connais pas et, pour être honnête, je n’ai pas cherché (création dynamique, quelque chose comme ça ?).

Bref, rien à faire, ils sont introuvables. Voici donc la solution dans ce cas :

Lancer le CD d’installation de Debian (marche probablement avec d’autre mais c’est ce que j’ai fait donc…). Après le lancement, continuer jusqu’au moment de la sélection du réseau, passer cette étape puis, un petit ALT+F2 (ou CTRL+ALT+F2), pour passer dans une console. Ensuite, voici la marche à suivre (mon / se trouve dans /dev/sda6) :

$ mount /dev/sda6 /mnt
$ mount -o bind /dev /mnt/dev
$ mount -o bind /proc /mnt/proc
$ chroot /mnt
$ grub
Probing devices to guess BIOS drives. This may take a long time.
grub> root (hd0,5) # trouvé dans /boot/grub/menu.lst
grub> setup (hd0)
sortie de grub qui dit que tout s'est bien passé
grub> # CTRL+C pour sortir
$ update-grub
$ reboot

En ce qui me concerne, ça a fonctionné. Seul un dernier souci que j’ai eu, mes partitions /home et de swap ont été échangées. Donc, au redémarrage, si un problème se pose, pensez avant de tout envoyer valser à passer en console de maintenance, à tester le montage de vos partitions pour voir ce qu’il y a dedans et modifier votre /etc/fstab en conséquence…

Si, comme moi, vous êtes passe à la nouvelle version de VirtualBox, celle de Sun, vous avez peut-être de petits problèmes avec vos anciennes VM Windows.
Voici comment résoudre le problème du BSoD juste après l’affichage du logo Windows.

La manipulation est relativement simple. Il vous suffit d’aller des les réglages de votre VM. Puis dans la partie General » Advanced » IDE Controller Type de choisir PIIX3 a la place de PIIX4.

Et voilà le tour est joué !

Pendant un instant, j’ai crus qu’il n’était pas possible d’utiliser plusieurs fois un même fichier VDI avec VirtualBox.

En effet lorsque je copiais simplement une machine virtuelle, VirtualBox me disait que cette machine était déjà enregistrée.

Cette idée allant à l’encontre du principe même de la virtualisation, je me suis penché sur le problème.

Il se trouve que VirtualBox est livré avec un utilitaire : VBoxManage

VBoxManage permet différentes actions sur les fichiers VDI dont le ‘clonevdi’ qui justement répond au besoin de copie des machines virtuelles.

La commande suivante permet de créer un clone de MachineEnEntree :

VBoxManage clonevdi MachineEnEntree.vdi MachineEnSortie.vdi

Si vous êtes intéressé par un man en couleurs, voici un moyen de l’obtenir.

Commencez par installer most. Most est un pager assez sympa dans le style de more et less.

sudo aptitude install most

Pour faire un simple test.

man -P most commande

Si ça vous plaît et que vous comptez le garder voici la marche à suivre.

sudo update-alternatives --config pager

Choisissez most

Si most vous plaît mais que les couleurs vous insupportent vous pouvez les désactiver en réglant la variable d’environnement MOST_SWITCHES<br> (dans votre .shrc par exemple)

export MOST_SWITCHES="-C"