Google Reader kinda sucked¹ in many ways. It didn’t support authenticated feeds. If you had personal feeds for which you were the only subscriber, like issues assigned to you in your bug tracker or a Pinboard tag, it would only be updated once every 24 hours. And if you didn’t use the system for a week or so (ever heard of holidays?), those personal feeds would stop being updated altogether. That’s the kind of situation where the term UX actually makes sense, in that it’s a shitty experience for the user.

Now you might be inclined to to tell me that if I don’t like it, I should just not use it. I’ll love to, but currently, some 95% of feed readers rely on Google Reader for syncing, and the remaining 5% all suck. What’s ironic is that I don’t even need syncing: I exclusively read feeds in Reeder for iPad. I couldn’t care less (notice the proper use of this difficult expression) if my feed reader couldn’t sync. But those applications don’t just rely on Google Reader for syncing, they require it, plain and simple. So no matter how well done they otherwise are, you remain stuck by Reader’s limitations.

Now that Google Reader is dead, we can hope that existing feed readers won’t be abandoned and will either rely on other services (we’ll probably see a Fever-enabled Reeder for iPad before July 1st) or, more smartly, on no service at all, except if you need syncing. That a lot more than what we could hope for last week.

I ended up killing the mds process. I was treated with an Indexer unavailable (200), then another Waiting for index to be ready, then the backup completed successfully:

19.08.2012 14:25:34.270 com.apple.backupd: Waiting for index to be ready (100)
19.08.2012 14:26:34.352 com.apple.backupd: Waiting for index to be ready (100)
19.08.2012 14:27:34.429 com.apple.backupd: Waiting for index to be ready (100)
19.08.2012 14:28:13.502 com.apple.backupd: Indexer unavailable (200)
19.08.2012 14:28:35.520 com.apple.backupd: Waiting for index to be ready (100)
19.08.2012 14:30:14.957 com.apple.backupd: Copied 2944 files (5.2 MB) from volume filemate.
19.08.2012 14:30:15.574 com.apple.backupd: Copied 2955 files (5.2 MB) from volume 500GB.
19.08.2012 14:30:32.853 com.apple.backupd: Backup completed successfully.

(At the time of this writing, Incredibox had been 9gagged.)

Le “livre brun” Recettes Culinaires, que certains d’entre nous utilisaient à l’école ménagère, est enfin réédité et disponible en ligne.

Voir les articles sur le blog de Gasser Media :

• Recettes culinaires et hygiène alimentaire – un ouvrage incontournable réédité !
• Le livre de cuisine Recettes culinaires-hygiène alimentaire fait encore parler de lui…

et son passage au minimag de la TSR.

And here’s the antithesis to the previous one.

From CNN Tech, USB inventor is tech’s unlikely ‘rock star’:

In the early 1990s, [Ajay] Bhatt, like many people, was trying to hook up a printer to his computer. To do so, he first had to fiddle with a plug that had a dozen or more tongs on it. The plugs of the ’90s looked somewhat like acupuncture devices. They were difficult to use. Tiny screws held them in place.

[…]

“There’s got to be a better way to do this,” he recalled in a recent interview.

Note regarding the post title: “Scumbag Steve” is the Internet meme that inspired this montage. It’s not me being offensive (for once).

Just something I made to post on 9gag…

Oui, c’est un titre plutôt prétentieux étant donné que c’est la première fois que je réussis à installer une application Rails, et non, cela ne me dérange pas. C’était agréable comme un coup de pied au cul alors je dois documenter la façon dont j’y suis parvenu et cela pourrait rendre service à d’autres, alors si ça vous dérange, lisez-le comme ‘la façon correcte pour moi’.

Redmine (1.2.1 du 2011-07-11 au moment d’écrire ces lignes) est sacrément regardant en ce qui concerne ses prérequis: les gems (et aussi Ruby et RubyGems) ne doivent pas être trop anciens, certains ne peuvent pas être trop récents, et l’un d’eux (i18n) ne peut même pas être d’une version différente que celle spécifiée (0.4.2).

La page d’installation de Redmine indique qu’il nécessite:

• Ruby 1.8.6 ou 1.8.7, pas 1.9;
• RubyGems 1.3.7 ou plus récent, mais pas la 1.5.0 ni la 1.7.0 ou supérieure, parce que Rails 2.3.11 ne fonctionne pas avec celles-ci;
• Rails 2.3.11 (puis plus loin mentionne que la 2.3.14 fonctionne aussi);
• Rack 1.1.1;
• Rake 0.8.7 (pas la 0.9.x parce qu’elle n’est pas supportée par Rails);
• i18n 0.4.2 (la version 0.6.0 actuelle causera une erreur parce que la 0.4.2 est introuvable).

De plus, Redmine est distribué avec Rails 2.3.11 dans le dossier ‘vendor’, et utilisera celui-là à moins que vous ne l’en supprimiez et changiez la version désirée dans config/environment.rb. Ceci est élégamment documenté sur la page d’installation par une phrase très explicative: “read config/environment.rb first”. Simplement changer la version de Rails dans ce fichier n’aidera pas: si Redmine trouve Rails dans son dossier ‘vendor’, il utilisera celui-là.

La réalité des prérequis de Redmine est légèrement différente. Rake 0.9.x est supporté par Rails 2.3.14 (il installe la 0.9.2 avec ses dépendances), mais RubyGems 1.7.0 ou plus récent ne l’est quand-même pas. Alors pour réduire la quantité de software obsolète et buggué que l’installe et les soucis qui s’ensuivent, je vais utiliser Rails 2.3.14.

Utiliser RVM

Ruby Version Manager, ou RVM, permet d’utiliser une version de Ruby et une gamme de gems différents pour des projets différents, sans installer lesdits gems au niveau du système. I est similaire au virtualenv de Python. À mon avis, il est absolument vital de l’employer dès le départ. Vous ne savez pas quels autres programmes vous pourriez vouloir installer, programmes qui pourraient avoir des prérequis aussi délicats que Redmine mais dans des version différentes. 

RVM se trouve à l’adresse http://beginrescueend.com/ et s’installe comme ceci (apparemment il nécessite git, ce qui est un peu gonflant si vous ne vous en servez pas. Mais vous devriez l’essayer, couplé à la version d’évaluation de Tower, c’est fantastique une fois que vous commencez à piger):

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

Ajoutez ensuite ceci à votre fichier.bash_profile ou .zshrc (vous voulez clairement passer à zsh et utiliser oh-my-zsh, parce qu’ils sont fantastiques également), comme indiqué par le script d’installation (personnalisé pour votre  $HOME):

# This loads RVM into a shell session.
[[ -s "/Users/olivier/.rvm/scripts/rvm" ]] && source "/Users/olivier/.rvm/scripts/rvm"

Ensuite nous devons installer la dernière version de Ruby pré-1.9 pour utiliser avec RVM. RVM le compile depuis les sources, mais cela ne prends pas trop longtemps (et si vous trouvez que si, faites un saut sur 9gag.com). On peut lister les version disponibles de Ruby et ensuite installer celle que l’on veut, c’est à dire la 1.8.7 (qui donnera ruby-1.8.7-p352), comme suit:

$ rvm list known

# MRI Rubies
[ruby-]1.8.6[-p420]
[ruby-]1.8.6-head
[ruby-]1.8.7[-p352]
[ruby-]1.8.7-head
[ruby-]1.9.1-p378
[ruby-]1.9.1[-p431]
[ruby-]1.9.1-head
[ruby-]1.9.2-p180
[ruby-]1.9.2[-p290]
[ruby-]1.9.2-head
[ruby-]1.9.3[-preview1]
[ruby-]1.9.3-head
ruby-head
...

$ rvm install 1.8.7
...
$ rvm use 1.8.7

Une fois fait, nous allon créer un gemset pour Redmine, où RubyGems installera les gems dont nous avons besoin, dans les versions dont nous avons besoin, sans interférer avec l’installation système.

$ rvm gemset create redmine
'redmine' gemset created (/Users/olivier/.rvm/gems/ruby-1.8.7-p352@redmine).
$ rvm gemset use redmine

Notes:

1. La version de Ruby et le gemset employés sont liés à la session shell, ce qui fait que vous devez les changer à nouveau à chaque nouvelle session. Cela peut être effectué en une étape:

   $ rvm use 1.8.7@redmine
   Using /Users/olivier/.rvm/gems/ruby-1.8.7-p352 with gemset redmine
   

2. L’environnement en cours d’utilisation peut être vérifié avec rvm-prompt:

   $ rvm-prompt        
   ruby-1.8.7-p352@redmine
   

3. Vous pouvez repasser au Ruby système avec:

   $ rvm use system
   Now using system ruby.
   

4. Il n’y a pas besoin de sudo pour installer des gems dans un gemset RVM, parce que tous les fichiers sont contenus dans votre dossier Home.

5. Quand un gemset est en cours d’utilisation, les commandes Rake doivent être préfixées par rvm:

   $ rvm rake bla bla
   

Installer les gems

Tout d’abord, accélérons l’installation des gems d’un facteur 10, comme suggéré par The Budding Rubbyist. Ajoutez ceci à votre fichier ~/.gemrc, en le créant si nécessaire:

gem: --no-ri --no-rdoc

Cela ommettra la documentation (que nous ne lirons jamais, étant donné que nous ne sommes intéressés qu’à installer des programmes Ruby, pas à en développer) à l’installation des gems, une étape inexplicablement très lente, puisqu’elle dure généralement plus longtemps que l’étape “Building native extensions. This could take a while…” de certains gems.

Ensuite, assurons-nous que nous utilisons bien le Ruby et le gemset créés précédemment:

$ rvm use 1.8.7@redmine

Installons ensuite Rails 2.3.14 et i18n 0.4.2 (Rails installe i18n 0.6.0 mais souvenez-vous, Redmine ne la verrait pas même si on la bourrait dans son crâne épais avec une [we]brique):

gem install rails -v=2.3.14
gem install i18n -v=0.4.2

Note: pour déterminer que c’était Rails 2.3.14 que je voulais, j’ai listé toutes les versions disponibles et choisi la 2.3.x la plus récente:

$ gem query  --all --remote -n '^rails$'

*** REMOTE GEMS ***

rails (3.1.0, 3.0.10, 3.0.9, 3.0.8, 3.0.7, 3.0.6, 3.0.5, 3.0.4, 3.0.3, 3.0.2, 3.0.1, 3.0.0, 2.3.14, 2.3.12, 2.3.11, 2.3.10, 2.3.9, 2.3.8, 2.3.7, 2.3.6, 2.3.5, 2.3.4, 2.3.3, 2.3.2, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0, 2.0.5, 2.0.4, 2.0.2, 2.0.1, 2.0.0, 1.2.6, 1.2.5, 1.2.4, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.6, 1.1.5, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1.0, 1.0.0, 0.14.4, 0.14.3, 0.14.2, 0.14.1, 0.13.1, 0.13.0, 0.12.1, 0.12.0, 0.11.1, 0.11.0, 0.10.1, 0.10.0, 0.9.5, 0.9.4.1, 0.9.4, 0.9.3, 0.9.2, 0.9.1, 0.9.0, 0.8.5, 0.8.0)

La commande list est plus simple mais affichera tout ce qui commence par rails, ce qui est un peu gênant:

$ gem list --all --remote rails

*** REMOTE GEMS ***

rails (3.1.0, 3.0.10, 3.0.9, 3.0.8, 3.0.7, 3.0.6, 3.0.5, 3.0.4, 3.0.3, 3.0.2, 3.0.1, 3.0.0, 2.3.14, 2.3.12, 2.3.11, 2.3.10, 2.3.9, 2.3.8, 2.3.7, 2.3.6, 2.3.5, 2.3.4, 2.3.3, 2.3.2, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0, 2.0.5, 2.0.4, 2.0.2, 2.0.1, 2.0.0, 1.2.6, 1.2.5, 1.2.4, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.6, 1.1.5, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1.0, 1.0.0, 0.14.4, 0.14.3, 0.14.2, 0.14.1, 0.13.1, 0.13.0, 0.12.1, 0.12.0, 0.11.1, 0.11.0, 0.10.1, 0.10.0, 0.9.5, 0.9.4.1, 0.9.4, 0.9.3, 0.9.2, 0.9.1, 0.9.0, 0.8.5, 0.8.0)
rails-3-settings (0.1.1)
rails-action-args (0.1.1, 0.1.0)
rails-admin (0.0.0)
rails-and-solid (0.9.1, 0.9.0)
...

Je voulais utiliser SQLite (je n’ai pas pu compiler le gem mysql contre le MySQL de Zend Server, et je m’en fiche — oh, c’est notre shortstop), alors j’ai installé le gem sqlite3:

gem install sqlite3

Nous devons aussi downgrader RubyGems depuis la dernière version (1.8.10 au moment d’écrire ces lignes) vers une version qui est au moins la 1.3.7 mais pas la 1.5.0, ni la 1.7.0 ou plus récente. La version que nous voulons peut être déterminée de la même façon que pour Rails, en demandant le gem rubygems-update:

$ gem list --all --remote  rubygems-update

*** REMOTE GEMS ***

rubygems-update (1.8.10, 1.8.9, 1.8.8, 1.8.7, 1.8.6, 1.8.5, 1.8.4, 1.8.3, 1.8.2, 1.8.1, 1.8.0, 1.7.2, 1.7.1, 1.7.0, 1.6.2, 1.6.1, 1.6.0, 1.5.3, 1.5.2, 1.5.0, 1.4.2, 1.4.1, 1.4.0, 1.3.7, 1.3.6, 1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0, 1.2.0, 1.1.1, 1.1.0, 1.0.1, 1.0.0, 0.9.5, 0.9.4, 0.9.3, 0.9.2, 0.9.1, 0.9.0, 0.8.11, 0.8.10, 0.8.8, 0.8.6, 0.8.5, 0.8.4, 0.8.3)

Nous voulons donc la 1.6.2:

$ gem update --system 1.6.2
...
$ gem -v
1.6.2

Noter que d’anciennes versions de la commande gem, comme la 1.3.7 recommendée par Redmine, ne supportent pas de spécifier la version dans la commande gem update --system. Dans ce cas, vous devez d’abord obtenir la dernière version et ensuite la downgrader:

$ gem update --system
$ gem update --system 1.6.2

Passons maintenant à l’installation de Redmine.

Installer Redmine

Téléchargez la dernière version stable (1.2.1 du 2011-07-11 au moment d’écrire ces lignes) et décompressez-la.

Nous devons désactiver le Rails 2.3.11 livré et dire à Redmine d’utiliser notre version 2.3.14. Dans config/environment.rb, changer ces lignes:

# Specifies gem version of Rails to use when vendor/rails is not present
RAILS_GEM_VERSION = '2.3.11' unless defined? RAILS_GEM_VERSION

en:

# Specifies gem version of Rails to use when vendor/rails is not present
RAILS_GEM_VERSION = '2.3.14' unless defined? RAILS_GEM_VERSION

Ensuite, déplacez Rails hors du dossier ‘vendor’, sinon Redmine utilisera l’ancienne version, quoique la ligne ci-dessus dise. Je le fais comme ceci:

mv vendor/rails vendor.rails.disabled

Au fait, c’est le passage “read config/environment.rb first” dans la liste des prérequis et le “when vendor/rails is not present” dans le commentaire ci-dessus qui nous indique que nous devons enlever Rails du dossier ‘vendor’. Comme je l’ai dit, une phrase très explicative.

Procédons ensuite à l’installation. Avec SQLite, database.yml a l’allure suivante:

production:
  adapter: sqlite3
  database: db/redmine.db
 
development:
  adapter: sqlite3
  database: db/redmine.db

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  adapter: sqlite3
  database: db/redmine_test.db

Note: Chez moi, les commandes suivantes étaient infestées d’alertes d’obsolescence comme celle-ci:

rake/rdoctask is deprecated.  Use rdoc/task instead (in RDoc 2.4.2+)
Please install RDoc 2.4.2+ to generate documentation.
WARNING: 'task :t, arg, :needs => [deps]' is deprecated.  Please use 'task :t, [args] => [deps]' instead.
    at redmine-1.2.1/lib/tasks/email.rake:170

À ma connaissance elles ne dérangent pas, à part en rendant difficile de savoir si la tâche s’est achevée avec succès ou pas.

Créez un ‘session store secret’ (n’oubliez pas de taper rvm rake au lieu de rake):

rvm rake generate_session_store

Créez la structure de la base de données:

RAILS_ENV=production rvm rake db:migrate

Insérez la configuration par défaut dans la base de données:

RAILS_ENV=production rvm rake redmine:load_default_data

Testez ensuite votre installation. Cela prend un petit moment pour démarrer. Les deux premières lignes apparaissent rapidement et vous permettent de vérifier que Redmine utilise la bonne version de Rails:

=> Booting WEBrick
=> Rails 2.3.14 application starting on http://0.0.0.0:3000

Le serveur est prêt quand vous voyez ceci:

=> Call with -d to detach
=> Ctrl-C to shutdown server
[2011-09-25 14:28:09] INFO  WEBrick 1.3.1
[2011-09-25 14:28:09] INFO  ruby 1.8.7 (2011-06-30) [i686-darwin10.8.0]
[2011-09-25 14:28:09] INFO  WEBrick::HTTPServer#start: pid=39670 port=3000

Faire tourner Redmine sous Unicorn

Avertissement: Je n’ai aucune idée de si utiliser Unicorn pour faire tourner Redmine est une bonne idée. Je sais juste que WEBrick n’est pas destiné à la production et que Passenger est un module Apache, et je préfère l’éviter si possible. Après-tout, nous sommes arrivés jusqu’ici sans nécessiter de droits administrateur.

J’ai trouvé les instructions sur Install Redmine on Ubuntu Server dans la liste des HowTo de Redmine, sauf la partie concernant le wrapper RVM, qui vient de Brandon Tilley.

Installez Unicorn, toujours sous RVM:

$ gem install unicorn

Créez un wrapper pour unicorn_rails. Le wrapper fera tourner unicorn_rails avec la bonne version de Ruby et le bon gemset:

$ rvm wrapper ruby-1.8.7-p352@redmine redmine unicorn_rails

Cela crée une commande redmine_unicorn_rails qui utilise l’environnement ruby-1.8.7-p352@redmine.

Créez le fichier de configuration d’Unicorn, par example unicorn.conf dans le dossier config de Redmine:

# /var/www/redmine/config/unicorn.conf

# Number of CPU Cores
worker_processes 2

# Same Redmine User
user "redmine", "redmine"
working_directory "/var/www/redmine"

# Listen on Both UNIX and TCP Sockets for Testing
listen "/var/www/redmine/tmp/sockets/.sock", :backlog => 64
listen 8080, :tcp_nopush => true

# Default Timeout
timeout 30

# Pid/Logging Config
pid "/var/www/redmine/tmp/pids/unicorn.pid"
stderr_path "/var/www/redmine/log/unicorn.stderr.log"
stdout_path "/var/www/redmine/log/unicorn.stdout.log"

# Preload Rails App for Performance
preload_app true

before_fork do |server, worker|
  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.connection.disconnect!
end

after_fork do |server, worker|
  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.establish_connection
end

Cela suppose que vous avez décompressé Redmine dans /var/www/redmine et que vous avez un utilisateur redmine appartenant au groupe redmine. Si nécessaire, modifiez toutes les occurrences de /var/www/redmine vers le chemin où vous avez installé Redmine et la ligne user "redmine", "redmine" avec l’utilisateur et le groupe sous lesquels vous voulez que Redmine s’exécute. Pour mes tests j’ai utilisé mon compte utilisateur, mais ce n’est certainement pas recommandé:

user "olivier", "staff"

Démarrez ensuite Unicorn en utilisant le wrapper, ce qui signifie qu’il n’est pas nécessaire de changer l’environnement RVM. Cela sera pratique si vous utilisez launchd ou un autre gestionnaire de services pour lancer Redmine:

$ sudo -u redmine redmine_unicorn_rails -c /var/www/redmine/config/unicorn.conf -D -E production

Si comme moi vous avez utilisé votre propre compte utilisateur comme test, alors le sudo n’est pas nécessaire:

$ redmine_unicorn_rails -c /var/www/redmine/config/unicorn.conf -D -E production

D’après le fichier de configuration, Unicorn tourne sur le port 8080. Si vous avez un serveur Apache sur le port 80 et désirez que Redmine apparaisse sous un préfixe donné, alors vous pouvez probablement utiliser une réécriture de type proxy pour atteindre ce but, à condition d’avoir activé mod_proxy.

Pour arrêter Unicorn, tuez le process unicorn_rails master.

Conclusion

C’est tout pour aujourd’hui, j’espère que cela a été utile. Comme je l’ai déjà mentionné, je débute avec les applications Rails, alors j’ai probablement fait des erreurs. N’hésitez pas à les signaler dans les commentaires, j’essaierai de mettre à jour ce post en conséquence. Il se peut aussi que j’ajoute quelque chose concernant l’utilisation de launchd pour exécuter Redmine sous Unicorn et de mod_proxy pour l’intégrer avec un site web existant.

Yes, it’s a rather pretentious title, considering that it’s my first time succeeding at installing a Rails application, and no, I don’t care. It was a pain in the ass so I need to document how I did it, and it might help other people, so if it really bothers you, read it as ‘the correct way for me’.

Redmine (1.2.1 of 2011-07-11 as of this writing) is pretty touchy about its requirements: gems (and Ruby and RubyGems as well) cannot be too old, some cannot be too recent, and one (i18n) even cannot be anything other than the specified version (0.4.2).

The Redmine installation page says it requires:

• Ruby 1.8.6 or 1.8.7, not 1.9;
• RubyGems 1.3.7 or higher, but not 1.5.0 and not 1.7.0 or higher, because Rails 2.3.11 fails with it;
• Rails 2.3.11 (then later tells you that 2.3.14 works as well);
• Rack 1.1.1;
• Rake 0.8.7 (not 0.9.x because it’s not supported by Rails);
• i18n 0.4.2 (the current version 0.6.0 will give you an error that 0.4.2 cannot be found).

Moreover, Redmine comes with Rails 2.3.11 bundled in the vendor directory, and will use it unless you remove it from there and change the version you want in config/environment.rb. This is neatly documented on the install page with a very thorough explanation: “read config/environment.rb first”. Just changing the version won’t help: if Redmine finds rails in its vendor directory, it will use that one.

The reality of Redmine requirements is a bit different. Rake 0.9.x is supported by Rails 2.3.14 (it installs 0.9.2 as part of its dependencies), but RubyGems 1.7.0 or higher still isn’t. So to minimise the number of obsolete and buggy software that I run and the fuss that ensues, I am going to use Rails 2.3.14.

Using RVM

Ruby Version Manager, or RVM, allows you to use a different version of Ruby and a different set of gems for different projects, without installing said gems system-wide. It is similar to Python’s virtualenv. In my opinion, it is absolutely vital to use it right from the start. You never know what other software you might want to install later, software that might have requirements as tricky as Redmine’s, yet different in the actual versions.

RVM can be found at http://beginrescueend.com/ and is installed thusly (it apparently requires git, which is kind of a bummer if you don’t use it. But you should give it a try, it’s awesome once you start grokking it):

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

Then add the following to your .bash_profile or .zshrc (obviously you want to switch to zsh and use oh-my-zsh, because they’re awesome too) as the install script will tell you (personalised with your $HOME path):

# This loads RVM into a shell session.
[[ -s "/Users/olivier/.rvm/scripts/rvm" ]] && source "/Users/olivier/.rvm/scripts/rvm"

Next we need to install the latest pre-1.9 Ruby to use with RVM. RVM will build it from source, but it doesn’t take too long (if you find it does, just head over to 9gag.com. We can list the available Ruby versions, and then install the one we want, namely 1.8.7 (that will result in ruby-1.8.7-p352):

$ rvm list known

# MRI Rubies
[ruby-]1.8.6[-p420]
[ruby-]1.8.6-head
[ruby-]1.8.7[-p352]
[ruby-]1.8.7-head
[ruby-]1.9.1-p378
[ruby-]1.9.1[-p431]
[ruby-]1.9.1-head
[ruby-]1.9.2-p180
[ruby-]1.9.2[-p290]
[ruby-]1.9.2-head
[ruby-]1.9.3[-preview1]
[ruby-]1.9.3-head
ruby-head
...

$ rvm install 1.8.7
...
$ rvm use 1.8.7

Once done, we will create a gemset for Redmine, where RubyGems will install the gems we need in the versions we need, without interfering with the system installation.

$ rvm gemset create redmine
'redmine' gemset created (/Users/olivier/.rvm/gems/ruby-1.8.7-p352@redmine).
$ rvm gemset use redmine

Notes:

1. The Ruby version and gemset in use are tied to the shell session, so you have to switch every time you start a new shell. It can be done in one step:

   $ rvm use 1.8.7@redmine
   Using /Users/olivier/.rvm/gems/ruby-1.8.7-p352 with gemset redmine
   

2. The current environment can be queried with rvm-prompt:

   $ rvm-prompt        
   ruby-1.8.7-p352@redmine
   

3. You can switch back to the system Ruby with:

   $ rvm use system
   Now using system ruby.
   

4. You do not need sudo to install gems in an RVN gemset, because all the files are contained in your home directory.

5. Rake commands while using a gemset should be prefixed by rvm:

   $ rvm rake blah blah
   

Installing gems

First of all, let us speed up gem installs 10x, as suggested by The Budding Rubbyist. Add the following to your ~/.gemrc file, creating it if needed:

gem: --no-ri --no-rdoc

That will omit installing the documentation (that we will never read as we’re only interested in using Ruby software, not developing some) when installing gems, a step that is inexplicably very lengthy as it usually takes longer than the “Building native extensions. This could take a while…” step of some gems.

Next, make sure we are using the Ruby and gemset we created earlier:

$ rvm use 1.8.7@redmine

Then install Rails 2.3.14 and i18n 0.4.2 (Rails installs i18n 0.6.0, but remember, Redmine wouldn’t see this one if we forced it into its thick skull with a [we]brick):

gem install rails -v=2.3.14
gem install i18n -v=0.4.2

Note: To figure out that it was Rails 2.3.14 that I wanted, I listed all the versions available and picked the latest 2.3.x:

$ gem query  --all --remote -n '^rails$'

*** REMOTE GEMS ***

rails (3.1.0, 3.0.10, 3.0.9, 3.0.8, 3.0.7, 3.0.6, 3.0.5, 3.0.4, 3.0.3, 3.0.2, 3.0.1, 3.0.0, 2.3.14, 2.3.12, 2.3.11, 2.3.10, 2.3.9, 2.3.8, 2.3.7, 2.3.6, 2.3.5, 2.3.4, 2.3.3, 2.3.2, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0, 2.0.5, 2.0.4, 2.0.2, 2.0.1, 2.0.0, 1.2.6, 1.2.5, 1.2.4, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.6, 1.1.5, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1.0, 1.0.0, 0.14.4, 0.14.3, 0.14.2, 0.14.1, 0.13.1, 0.13.0, 0.12.1, 0.12.0, 0.11.1, 0.11.0, 0.10.1, 0.10.0, 0.9.5, 0.9.4.1, 0.9.4, 0.9.3, 0.9.2, 0.9.1, 0.9.0, 0.8.5, 0.8.0)

The list command is simpler, but it will list everything that starts with rails, which is a bit of a bother:

$ gem list --all --remote rails

*** REMOTE GEMS ***

rails (3.1.0, 3.0.10, 3.0.9, 3.0.8, 3.0.7, 3.0.6, 3.0.5, 3.0.4, 3.0.3, 3.0.2, 3.0.1, 3.0.0, 2.3.14, 2.3.12, 2.3.11, 2.3.10, 2.3.9, 2.3.8, 2.3.7, 2.3.6, 2.3.5, 2.3.4, 2.3.3, 2.3.2, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0, 2.0.5, 2.0.4, 2.0.2, 2.0.1, 2.0.0, 1.2.6, 1.2.5, 1.2.4, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.6, 1.1.5, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1.0, 1.0.0, 0.14.4, 0.14.3, 0.14.2, 0.14.1, 0.13.1, 0.13.0, 0.12.1, 0.12.0, 0.11.1, 0.11.0, 0.10.1, 0.10.0, 0.9.5, 0.9.4.1, 0.9.4, 0.9.3, 0.9.2, 0.9.1, 0.9.0, 0.8.5, 0.8.0)
rails-3-settings (0.1.1)
rails-action-args (0.1.1, 0.1.0)
rails-admin (0.0.0)
rails-and-solid (0.9.1, 0.9.0)
...

I wanted to use SQLite (I couldn’t make the mysql gem build against Zend Server’s MySQL, and I don’t care), so I installed the sqlite3 gem:

gem install sqlite3

We also need to downgrade RubyGems from the latest version (1.8.10 as of writing) to a version that is at least 1.3.7 but not 1.5.0 and not 1.7.0 or later. The version we want can be determined the same way as for Rails, by querying the rubygems-update gem:

$ gem list --all --remote  rubygems-update

*** REMOTE GEMS ***

rubygems-update (1.8.10, 1.8.9, 1.8.8, 1.8.7, 1.8.6, 1.8.5, 1.8.4, 1.8.3, 1.8.2, 1.8.1, 1.8.0, 1.7.2, 1.7.1, 1.7.0, 1.6.2, 1.6.1, 1.6.0, 1.5.3, 1.5.2, 1.5.0, 1.4.2, 1.4.1, 1.4.0, 1.3.7, 1.3.6, 1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0, 1.2.0, 1.1.1, 1.1.0, 1.0.1, 1.0.0, 0.9.5, 0.9.4, 0.9.3, 0.9.2, 0.9.1, 0.9.0, 0.8.11, 0.8.10, 0.8.8, 0.8.6, 0.8.5, 0.8.4, 0.8.3)

So we want 1.6.2:

$ gem update --system 1.6.2
...
$ gem -v
1.6.2

Note that some older version of the gem command, like the 1.3.7 recommended by Redmine, do not support specifying the version in the gem update --system command. In that case, you would need to get the most recent version and then downgrade it:

$ gem update --system
$ gem update --system 1.6.2

Now let’s proceed to installing Redmine.

Installing Redmine

Download the latest stable release (1.2.1 of 2011-07-11 as of this writing) and unpack it.

We need to disable the built-in Rails 2.3.11 and tell Redmine to use our 2.3.14 version. In config/environment.rb, change these lines:

# Specifies gem version of Rails to use when vendor/rails is not present
RAILS_GEM_VERSION = '2.3.11' unless defined? RAILS_GEM_VERSION

to:

# Specifies gem version of Rails to use when vendor/rails is not present
RAILS_GEM_VERSION = '2.3.14' unless defined? RAILS_GEM_VERSION

Next, move rails out of the vendor directory. If you don’t, Redmine will use the old version no matter what the above line says. I do this:

mv vendor/rails vendor.rails.disabled

By the way, it’s the “read config/environment.rb first” bit in the requirements list and the “when vendor/rails is not present” in the comment above that tell us that we must remove rails from the vendor directory. As I said, a very thorough explanation.

Next, proceed with installation. With SQLite, database.yml looks like this:

production:
  adapter: sqlite3
  database: db/redmine.db

development:
  adapter: sqlite3
  database: db/redmine.db

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  adapter: sqlite3
  database: db/redmine_test.db

Note: The following commands for me were littered with deprecation warnings like this one:

rake/rdoctask is deprecated.  Use rdoc/task instead (in RDoc 2.4.2+)
Please install RDoc 2.4.2+ to generate documentation.
WARNING: 'task :t, arg, :needs => [deps]' is deprecated.  Please use 'task :t, [args] => [deps]' instead.
    at redmine-1.2.1/lib/tasks/email.rake:170

As far as I know they don’t matter, apart from the fact that they render it quite difficult to determine whether the task succeeded or not.

Generate a session store secret (don’t forget to rvm rake instead of just rake):

rvm rake generate_session_store

Create the database structure:

RAILS_ENV=production rvm rake db:migrate

Insert default configuration data in database:

RAILS_ENV=production rvm rake redmine:load_default_data

Then test your installation:

ruby script/server webrick -e production

or

ruby script/server -p 3000 webrick -e production

It takes a little while to start. The first two lines appear quite quickly and let you check that Redmine is running the correct Rails version:

=> Booting WEBrick
=> Rails 2.3.14 application starting on http://0.0.0.0:3000

Then the server is ready when you see this:

=> Call with -d to detach
=> Ctrl-C to shutdown server
[2011-09-25 14:28:09] INFO  WEBrick 1.3.1
[2011-09-25 14:28:09] INFO  ruby 1.8.7 (2011-06-30) [i686-darwin10.8.0]
[2011-09-25 14:28:09] INFO  WEBrick::HTTPServer#start: pid=39670 port=3000

Running Redmine under Unicorn

Disclaimer: I have no idea if using Unicorn to run Redmine is a good idea. I just know that WEBrick is not for production and that Passenger is an Apache module, and I’d rather not bother with it if I can avoid it. After all, we reached thus far without need admin privileges.

I found the instruction at Install Redmine on Ubuntu Server from the Redmine HowTo’s list, except the part about the RVM wrapper that comes from Brandon Tilley.

Install Unicorn, still under RVM:

$ gem install unicorn

Create a wrapper for unicorn_rails. The wrapper will run unicorn_rails with the correct Ruby version and gemset:

$ rvm wrapper ruby-1.8.7-p352@redmine redmine unicorn_rails

This creates a redmine_unicorn_rails command that uses the ruby-1.8.7-p352@redmine environment.

Create the unicorn configuration file unicorn.conf, for example in Redmine’s config directory:

# /var/www/redmine/config/unicorn.conf

# Number of CPU Cores
worker_processes 2

# Same Redmine User
user "redmine", "redmine"
working_directory "/var/www/redmine"

# Listen on Both UNIX and TCP Sockets for Testing
listen "/var/www/redmine/tmp/sockets/.sock", :backlog => 64
listen 8080, :tcp_nopush => true

# Default Timeout
timeout 30

# Pid/Logging Config
pid "/var/www/redmine/tmp/pids/unicorn.pid"
stderr_path "/var/www/redmine/log/unicorn.stderr.log"
stdout_path "/var/www/redmine/log/unicorn.stdout.log"

# Preload Rails App for Performance
preload_app true

before_fork do |server, worker|
  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.connection.disconnect!
end

after_fork do |server, worker|
  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.establish_connection
end

This assumes that you unpacked redmine in /var/www/redmine and that you have a redmine user belonging to a redmine group. If needed, change all occurrences of /var/www/redmine to where you installed Redmine and user "redmine", "redmine" to the user and group you want Redmine to run as. For testing, I used my user account, but it’s certainly not recommended:

user "olivier", "staff"

Then start unicorn using the wrapper, which means we don’t need to enter the RVM environment. This should come in handy if you use launchd or another service system to launch Redmine:

$ sudo -u redmine redmine_unicorn_rails -c /var/www/redmine/config/unicorn.conf -D -E production

If like me you used your own user account for testing purposes, then you don’t need the sudo part:

$ redmine_unicorn_rails -c /var/www/redmine/config/unicorn.conf -D -E production

From the config file, Unicorn runs on port 8080. If you have an Apache web site on port 80 and would like Redmine to appear under a given prefix, and have mod_proxy enabled, then you can probably use a proxy rewrite rule to achieve this.

To stop Unicorn, kill the unicorn_rails master process.

Conclusion

That’s it for today, I hope this helps. As I already mentioned, I am new to Rails applications, so I probably made mistakes. Don’t hesitate to point them out in the comments, I’ll try and update this post accordingly. I might also add something about using launchd to run Redmine under Unicorn and mod_proxy to integrate with an existing web site.

Security: the federal administration privated of iPhone

The federal personnel will not receive temporarily more iPhone as mobile phone of service. The informatics department is fearing for the security of the transmitted datas. The Federal Council will decide at the fall on the maintaining or not of this measure.

Some 680 employees of the Confederation actually have an iPhone for professional. The moratorium hitting this type of telephone of capacities near a computer, announced by the “Berner Zeitung”, has been confirmed on Wednesday by the spokesperson of the Federal Department of Finances (FDF) Roland Meier.

At the general secretary of the FDF, the iPhones have even been replaced by other “smartphones”, seeing the collaborators are in narrow contact with the Federal Council. Mr. Meier could not precise if a such exchange has happened in other units.

If one takes to the foot of the letter lhe directives of the Confederation, the iPhones should not be autorized, explains Peter Fischer, delegated at the informatic strategy. “But there rules are technically overtaken.”

The iPhone must not notably be integrated at the informatic systems of the Confederation via iTunes and Apple has then no more access to the datas transferred. An analyse of the security of the telephones said intelligents will be given until the fall at the Federal Council, who will decide the ones to autorize.

Source: ATS
Translation: Oil Tree

The original text is here:

Sécurité: l’administration fédérale privée d’iPhone

Le personnel fédéral ne recevra temporairement plus d’iPhone comme téléphone portable de service. Le service informatique craint pour la sécurité des données transmises. Le Conseil fédéral tranchera à l’automne sur le maintien ou non de cette mesure.

Quelque 680 employés de la Confédération ont actuellement un iPhone à titre professionnel. Le moratoire frappant ce type de téléphone aux capacités proches d’un ordinateur, annoncé par la “Berner Zeitung”, a été confirmé mercredi par le porte-parole du Département fédéral des finances (DFF) Roland Meier.

Au secrétariat général du DFF, les iPhones ont même été remplacés par d’autres “smartphones”, vu que les collaborateurs sont en contact étroit avec le Conseil fédéral. M.Meier n’a pas pu préciser si un tel échange a eu lieu dans d’autres unités.

Si l’on prend au pied de la lettre les directives de la Confédération, les iPhones ne devraient pas être autorisés, explique Peter Fischer, délégué à la stratégie informatique. “Mais ces règles sont dépassées techniquement.”

L’iPhone ne doit notamment plus être intégré au système informatique de la Confédération via iTunes et Apple n’a donc plus accès aux données transférées. Une analyse de la sécurité des téléphones dit intelligents sera remise d’ici l’automne au Conseil fédéral, qui décidera lesquels autoriser.

Source: ATS

I mean, WOW!

No, not World of Warcraft. No, not “Wow, Mars will be as bright as the full Moon” either.

Rather, “Wow, I have friends who believe this shit, who believe it enough to forward it to me as a fact, not even to ask me if it’s true.” (I happen to have a teeny, tiny PhD in some branch of Physics. Not many people know that.)

What’s good with this joke is that, by a happy coincidence on the numbers involved, the calculations needed to debunk it can be done in your head. Well, maybe not in your head, but certainly in mine.

See, everybody knows that the Earth is 150 million kilometers away from the Sun. The e-mail tells us the Earth-Mars distance at its shortest will be 55 million kilometers, which happens to be the only correct information in the whole message. This gives us the Sun-Mars distance as 150 + 55 = 205, make is 200 million kilometers.

Now the amount of sunlight received by a celestial object (or any kind of object, really) is inversely proportional to the square of its distance to the Sun, meaning that if you double the distance, it receives four times less light. So the amount of light received by Mars compared to the Moon (which is at the same distance from the Sun than the Earth) is

Let’s keep it this way for now.

Then the amount of light reflected by the planet is proportional to its surface, which is proportional to the square of its diameter. Maybe not everybody knows that Mars (6772 kilometers in diameter) is twice as big as the Moon (3475 kilometers, I told you the numbers involved were convenient), but people know that Mars is “a bit like Earth”, which would make it four times bigger than the Moon, which would be in the benefit of Mars and still work. But let’s stick with the correct numbers. The amount of light reflected by Mars compared to the Moon is therefore

Finally, the amount of light received by the Earth from each of our objects is, like before, inversely proportional to the square of the distance. Again, everybody knows that the Moon is 384 thousand kilometers away from the Earth. That’s the average distance. The maximum distance is rather 406 thousand kilometers. I’ll round it to 440 thousand kilometers because it’s in the detriment of the Moon and it’s convenient. So the amount of light received by the Earth from Mars compared to the Moon would be (beware the units)

Now it might be that the surface of Mars reflects light better than the surface of the Moon. It’s even probable: Mars is red whereas the Moon is black (Don’t believe me? Remember those rocks they took back from there, like exactly forty years ago? Did they look bright white?). But I’ll assume they both reflect light equally so we can compare the numbers with real data in the end. We can make the calculation again with Mars ten times brighter than the Moon later if you want.

So, to sum up, we have:

• Amount of light received by Mars compared to the Moon: (3/4)²;
• Amount of light reflected by Mars compared to the Moon: 2²;
• Amount of light received by the Earth from Mars compared to the Moon: (8/1000)².

Let’s multiply all this (because the light reflected is proportional to the light received from the Sun, and the light received on Earth is proportional to the light reflected):

The light we get from Mars, in the best case ever, is almost seven thousand times less than the light we get from the full Moon. What a surprise! And if we had taken Mars to be as big as the Earth (four times bigger than the Moon instead of two, gives another factor 4 once squared) and ten times brighter than the Moon (i.e. very wrong numbers in its favour), it would still appear 170 times fainter.

Now let’s check this result quickly. The Wikipedia article on apparent magnitude tells us that the magnitude of the full Moon is -12.6 and the maximum brightness of Mars is -2.9. It also tells us that the ratio in brightness between two objects is given by

where x is the difference between the two magnitudes. In our case:

We weren’t far with our seven thousand, given the approximations we made, don’t you reckon?

Do we need to check the claim that Mars can appear as big as the Moon, too? That won’t take long, now that we’re experts in the field. The apparent size of an object in the sky is given by the angle under which you see its diameter. In radians and for such small angles, it’s calculated as diameter/distance. Hey, we happen to have all the necessary data already. For Mars:

For the Moon:

That is, Mars appears 70 times smaller than the Moon in the sky.

So next time you see a message that claims such unbelievable things, make a quick mental calculation before forwarding it to everybody. Or even easier, ask yourself if you have ever seen a celestial object that looked bigger than a dot to the naked eye, apart from the Sun and Moon, and check on the Internet. There are sites like Hoax-Slayer (English) or HoaxBuster (French) dedicated to this and checking the validity of such e-mails can be done very quickly.

Next time in this column: why doesn’t the height at which you must throw a grenade to have it explode the moment it touches the ground depend on the weight of the grenade?