Log

Configurer Virtualbox avec IE7, IE8, IE9 sous Debian GNU/Linux

mathieu — Fri, 03 Feb 2012 19:49:06 +0000

(initialement écrit le 2010-03-13, mis à jour le 3 février 2012)

Je dois régulièrement vérifier sites web pour m'assurer qu'ils fonctionnent correctement sous Internet Explorer. Jadis j'utilisais ies4linux (et wine), mais c'est lent, peu fiable (polices de caractères) et ne supporte que IE6.

Voici comment installer VirtualBox, un émulateur libre (GPL) qui fonctionne sous GNU/Linux, Windows et Mac.

Installer VirtualBox sur Debian

Voici comment l'installer pour Debian (squeeze):

# apt-get install virtualbox virtualbox-guest-additions-iso virtualbox-guest-utils

Le paquet Debian s'occupe de créer le bon groupe (vboxusers) et compiler les trucs nécessaires pour le noyau.

Obtenir des images VHD de Windows

Ensuite:

Télécharger les images Windows de Microsoft: Internet Explorer Application Compatibility VPC Image. Par exemple, pour IE7 sous Vista, il faut IE7-VIS1.exe, IE7-VIS2.rar et IE7-VIS3.rar. Attention, les fichiers font à peu près 700 Mo chaque.
Décompresser l'archive (unrar x IE7-VIS1.exe), ce qui décompressera un fichier "vhd".

Démarrer VirtualBox (du menu gnome ou de la ligne de commande) :

Cliquer sur le bouton "Créer" (ou "Machine" -> "Créer")
Donner un nom à la machine virtuelle (ex: "Windows 7 IE 9"), sélectionner le type de système d'exploitation (MS Windows, Version "Windows 7")
Choisir suffisamment de mémoire vive (512 Mo est parfois un peu bas, j'ai tendance à allouer 768 Mo).
IMPORTANT: pour IE8 / IE9, ne pas choisir de "disque d'amorçage". Décocher l'option complètement (virtualbox avertira que la machine ne sera pas fonctionnelle, continuer quand même).

Une fois l'assistant terminé, de retour au panneau principal de VirtualBox, aller dans les configurations de la machine virtuelle:

Sous l'onglet "Stockage", cliquer sur l'icône "+" à côté de "Contrôleur IDE". (Ne pas utiliser "SATA", car ceci causera un" écran bleu de la mort" (BSOD) de Windows.)
puis sélectionner l'option "Choisir un disque existant", ce qui ouvrira un dialogue de sélection de fichier
dans le filtre sous la liste de fichiers, sélectionner "tous les fichiers de disque dur virtuels" (si ce n'est pas déjà le cas), puis sélectionner le fichier "vhd".

On peut maintenant retourner à l'écran principal et démarrer la machine virtuelle:

Le mot de passe dministrateur est "Password1".
On peut sauter par dessus l'étape d'activation de Windows.

Dans un terminal de Windows (command prompt), écrire:

slmgr –rearm

Ceci permettra d'utiliser Windows pendant 30 jours. On peut faire un "snapshot" de l'image et re-utiliser cette image sans problème, pour éviter de tout refaire l'installation après 30 jours.

Configurer la carte réseau

Mise à jour du 3 février 2012: ceci ne semble plus nécessaire.

Pour faire fonctionner la carte réseau dans Windows7+IE8, j'ai dû faire les étapes suivantes:

installer le paquet "virtualbox-guest-utils" pour avoir la fonctionalité de partage de répertoire entre Linux et Windows
configurer la carte réseau dans VirtualBox pour qu'elle soit émulée en tant que "Intel PRO/1000"
télécharger un pilote (driver) d'Intel pour Windows ici
activer le répertoire partagé dans Windows, puis installer le pilote (en exécutant le fichier, ce qui après 1001 avertissements et trucs légaux incompréhensibles, lance ensuite l'installation du truc)

Références

Make the Drupal 7 language switcher work with multi-lingual CiviCRM

mathieu — Mon, 30 Jan 2012 23:05:47 +0000

The theme() function in Drupal 7 offers the possibility to specifiy a "context". This means that modules who used to call :

theme('list', $stuff);

Can now do:

theme('list__mystuff', $stuff);

Which allows themers to override the theme function for that specific case.

In my use case, I want a language switcher that supports multi-lingual CiviCRM forms. The language switcher provided by the default locale block will drop any arguments in the URL, which means that pages such as:

/en/civicrm/contribute/transact?reset=1&action=preview&id=3&lcMessages=en_US

Would be transformed to:

/fr/civicrm/contribute/transact

Therefore causing CiviCRM to output an error, since the page ID was not provided in the request.

I'm not sure if this is the cleanest solution, but it works for me:

/**
 * Implements hook_links__locale_block()
 * make the language switcher work with civicrm
 * adapt and insert into your theme's template.php
 */
function yourthemename_links__locale_block($variables) {
  if (arg(0) == 'civicrm') {
    foreach ($variables['links'] as $lang => $attr) {
      $query = $_REQUEST;
      unset($query['IDS_request_uri']);
      unset($query['IDS_user_agent']);
      if ($lang == 'fr') {
        $query['lcMessages'] = 'fr_CA';
      }
      else {
        $query['lcMessages'] = 'en_US';
      }
      $variables['links'][$lang]['query'] = $query;
    }
  }
  return theme('links', $variables);
}

Meta: site web mis à jour à Drupal 7

mathieu — Wed, 30 Nov 2011 04:48:28 +0000

J'ai mis à jour ce site web de Drupal 6 à 7. Comme vous pouvez le constater, ça brise une bonne partie du site (listes trop longues, titres en double, encore plus laid, etc).

Pour le visuel, j'ai installé le thème sky, basé sur Adaptive Theme.

Je me suis dit que ça prendrait une éternité avant que je termines la mise à jour correctement, alors autant mieux faire la mise à jour et réparer plus tard. :-)

Mise à jour:

J'ai réussi à faire un visuel qui fait un peu mal aux yeux, mais quand même divertissant, en jouant 1-2h avec le thème Sky, et un peu de CSS maison. Je me suis amusé avec "-moz-transition".
Je n'ai toujours pas réglé mon problème que Panels ne respecte pas les limites d'items configurées (i.e. afficher max 10 items). Alors pour l'instant j'ai changé la configuration de la page d'accueil pour avoir une seule vue. Les "bookmarks" font dur à cause de ça, mais je pense faire une refonte de ça.
Le module boost ne fonctionnait pas très bien, et le principal développeur n'est pas très actif dernièrement, alors j'ai offert de lui donner un coup de main et j'ai obtenu les accès au dépôt git. Ce qui m'a fait perdre au moins 4-5 heures à lire les très intéressants rapports de bugs ouverts (environ 150, et 300 demandes de support).
Toujours pas trouvé de solution aux titres en double, quoique je n'ai pas vraiment cherché non plus. Résolu: étrangement le thème imprimait le titre dans page.tpl.php et node.tpl.php. Il y a sans doute une option dans le thème que je n'ai pas compris, mais bon, j'ai mis en commentaire l'impression du titre dans node.tpl.php.

Autre mises à jour:

J'ai laissé tomber Panels, puisque je n'en avais pas vraiment besoin, et gérer les fils RSS est plus facile avec Context (permet de gérer les blocs plus rapidement). Il faut par contre que je trouve une solution pour faire revenir la 3e colonne, mais je vais trouver une façon de le présenter autrement (c'est pas du contenu qui change souvent, et ça surchargeait la page).
J'ai porté les petits trucs qui fait plier/déplier les fils RSS, afficher le contenu des items (pour le faire flotter quand on place la souris sur le titre), etc. Le module "aggregator" semble s'être amélioré par rapport à D6, du moins j'ai trouvé ça beaucoup plus facile à modifier par des templates.

Installing CiviCRM SVN trunk with Aegir (on Debian/Ubuntu)

mathieu — Wed, 26 Oct 2011 17:53:33 +0000

To install the latest SVN trunk version using Aegir (and provision_civicrm), the process is rather equivalent to the usual CiviCRM installation, except that you have to run "GenCode" (more on that later). The following instructions are for Debian/Ubuntu, mainly because installing Aegir on those environments is easier.

Aegir installation

Check the official installation instructions for more information. In a nutshell:

Add the following package repositories to your /etc/apt/sources.list:

deb http://debian.aegirproject.org stable main
deb http://backports.debian.org/debian-backports squeeze-backports main

Update the package database:

apt-get update

Install Drush and Aegir:

apt-get install -t squeeze-backports drush
apt-get install aegir
apt-get install sudo

There is a known bug in Aegir 1.4: if you had an issue with the drush_make installation, you can manually install it in /var/aegir/.drush/drush_make :

su - aegir
drush dl drush_make-6.x-2.3 --destination=~/.drush

Then continue the Aegir installation if it had failed:

apt-get -f install

Configure sudo so that your user can sudo to the aegir user easily. If you are running Debian "squeeze" or later, you can add the following to a file such as /etc/sudoers.d/aegir-local (otherwise, use "visudo" to add to the main sudo config file):

your-username-here ALL=(aegir) NOPASSWD: ALL

Installation of provision_civicrm

For the moment there are no regular releases of provision_civicrm, so doing a git checkout is recommended:

su - aegir
cd /var/aegir/.drush/
git clone --branch 6.x-1.x git://git.drupal.org/project/provision_civicrm

Create a new Aegir platform

Here is a sample drush make "makefile" for creating the platform (i.e. code base):

; drush make API version
api = 2

; Drupal core
core = 7.x

; Download Drupal core
projects[] = drupal

; Modules
projects[admin_menu][subdir] = contrib
projects[admin_menu][version] = 3.0-rc1

projects[devel][subdir] = contrib
projects[devel][version] = 1.2

projects[views][subdir] = contrib
projects[views][version] = 3.0-rc1

projects[ctools][subdir] = contrib
projects[ctools][version] = 1.0-rc1

projects[webform_civicrm][subdir] = contrib
projects[webform_civicrm][version] = 2.0

; Download CiviCRM from SVN
libraries[civicrm][type] = "module"
libraries[civicrm][destination] = "modules"
libraries[civicrm][directory_name] = "civicrm"
libraries[civicrm][download][type] = "svn"
libraries[civicrm][download][url] = "http://svn.civicrm.org/civicrm/trunk"

libraries[civicrm_l10n][destination] = "modules"
libraries[civicrm_l10n][directory_name] = "civicrm"
libraries[civicrm_l10n][download][type] = "get"
libraries[civicrm_l10n][download][url] = "http://downloads.sourceforge.net/project/civicrm/civicrm-stable/4.0.7/civicrm-4.0.7-l10n.tar.gz"
libraries[civicrm_l10n][overwrite] = TRUE

Save this in a file such as /var/aegir/makefiles/civicrm-4-svn.make

Run drush make to create the platform:

sudo -i -u aegir
mkdir ~/platforms/civicrm-4-svn-2011-10-26
cd ~/platforms/civicrm-4-svn-2011-10-26
drush make --working-copy ~/makefiles/civicrm-4-svn.make

The "--working-copy" parameter tells drush make to keep the ".svn" (or .git) files, so that you can use the platform for development.

Run GenCode

cd ~/platforms/civicrm-4-svn-2011-10-26/sites/all/modules/civicrm/xml
php GenCode schema/Schema.xml

Add the platform to the Aegir front-end

Create content -> Platform
- Enter a name, e.g. "CiviCRM SVN 2011-10-26"
- Path: /var/aegir/platforms/civicrm-4-svn-2011-10-26

You are now ready to create sites.

Common Drupal module developer beginner errors

mathieu — Sun, 14 Aug 2011 01:59:10 +0000

Lately, I have been working with a few big and small web companies on Drupal-based projects. Whether it's for project analysis, training, debugging or performance, I often have to jump into other people's code which was rushed into production on short deadlines, as I have also received a lot of feedback.

Here are a few simple tips for beginner Drupal module developers who are in a rush and will very likely need to cut corners by lack of budget or time, but who must at least make sure that the next person will not panic when reading their code.

Sidenote: while a good project manager is essential in facilitating the whole process, they usually focus on facilitating (or moderating) the communication between parties (and taking care of paperwork, such as finalizing the contract and billing). Developers must also bear the responsibility of "delivering a project on time, on budget and with acceptable quality". (or am I making up excuses to justify cut corners? ;-)

[toc]

Where is the custom code?

In your sites/all/modules directory, create 3 sub-directories:

contrib: modules downloaded from drupal.org
custom: home made modules
patched: contrib modules which have been modified for some reason (usually because you applied a patch which is waiting to be reviewed in the project's issue queue, and each patched module has a clear documentation of why/how it was patched).

I have seen some projects with modules all over the place, to the extent where I have gotten used to run a "find ./ -name '*.module'" to find them, or to look in the "system" table of the site database.

Since I use Aegir for development and hosting, I also recommend putting all the commonly used modules (views, devel, admin_menu, etc) in sites/all/modules (and using "drush_make" to create those platforms). Less commonly used (including site-specific custom modules) should go in sites/[example.org]/modules. This way, we can quickly see the site-specific modules. Do not place modules in sites/default/modules, you may later on have multiple sites sharing that same Drupal code installation.

Custom code and namespace prefixes

A namespace is a short word that provides information about the context (ok, it's more than that, but I'm trying to be brief). It helps making sure that two modules do not use the same function or object name.

For modules specific to the site, I usually prefix modules names with initials or an abbreviation referring to the site. For example, on "bidon.ca" I use the prefix "bdn" ("bidon" is French for "barrel", "container" or "useless").

Some sample modules names could be: "bdnforms" (with all the hook_form_alter fun), bdnsnippets (for those small PHP snippets which may be included from nodes/blocks/views), etc.

The only exception would be if creating a sub-module. For example: uc_bdn would have the code for use-cases specific to the store on my site (all Ubercart modules are prefixed with "uc").

For service providers who re-use modules with various clients, instead of using a site-specific prefix, use a company-specific prefix.

Drupal.org is the reference for module names. Unless you have published your module on drupal.org, you should not expect the module name to be unique.

PHP snippets should be in files, not nodes/blocs/views, and don't forget about the cron

There are times when it is necessary to enter PHP code directly in a node, block or view. Usually it's a last-resort hack.

For example, maybe you need to write a very specific block to display on some pages. Usually this is done with a custom module that generates a block. Sometimes it may be a block that admins need to be able to update its content easily, but needs to include a few lines of PHP to calculate something dynamic (ex: the number of people who have signed a petition).

If you don't have time to create a full custom module, create a function for that PHP snippet and store it in a general module or in your theme's template.php. This way, the code will be easy to find, re-use, maintain and there will be less risk that a site admin deletes the code by mistake. Don't forget to pass any variable to that function that would otherwise be available globally in the node/block/view.

(thanks to mvc for this one!)

On putting PHP snippets in nodes and how it will likely break the cron: it is common to put a PHP snippet in a node in order to do a quick hack (run a db_query to fix a table, print something, etc.). However, when cron will run, it will try to index each node for the search engine, therefore executing the PHP code.

This is very hard to debug once it happens (I usually end up doing a query in the database for nodes who have a PHP input filter, or inserting debug messages in the core cron indexing function).

Here are two incidents I have noticed recently:

a PHP snippet in a node was used to quickly export the contents of a table. It was generating a CSV file then calling the "die" function, hence halting the cron (and allowing anyone to download the CSV file just by running the cron.php).
a PHP snippet in a node was doing a "drupal_goto" to redirect the visitor to another page (shame on me, I think I was responsible for that one).

In both cases, the cron would simply stop running and would not display an error in the watchdog. We only noticed a week later in the status page that the cron had not run for a long time.

Correct use of the SQL functions to avoid injection attacks

The database functions in Drupal is a pretty big topic. For those in a very big rush, consider especially the following bad code:

db_query('INSERT INTO mytable (email, newsid)
    VALUES (' . $_POST['email'] . ', ' . $_POST['newsid'] . ')');

The correct way in Drupal 6 should be:

db_query('INSERT INTO {mytable} (email, newsid)
    VALUES ("%s", %d)', $_POST['email'], $_POST['email']);

The correct way in Drupal 7 should be:

db_query('INSERT INTO {mytable} (email, newsid)
    VALUES (:email, :newsid)', 
        array(
            ':email' => $_POST['email'],
            ':newsid' => $_POST['newsid'],
        ));

First, developers often forget to wrap table names in curly brackets, i.e. {mytable}. This is not for security, but for making it easier to prefix tables names if necessary (ex: if using simpletest).

More importantly, in the initial example, the input was not validated at all. Hence, someone could enter the following string in the e-mail field: '; UPDATE {users} SET name = 'admin', pass = MD5('test') WHERE uid = 1; [...] and change the username and password to your superadmin account.

If you are not familiar with the topic, search the web for "sql injection attacks".

Note that the %s placeholder is for strings and %d is for decimal numbers, %f for floats, %b for blobs. In Drupal 7, it is no longer required to wrap %s placeholders in quotes. For more information: Drupal 7 database abstraction layer, or db_query in Drupal 6.

Note that it is very rare to have to manipulate $_REQUEST variables directly. Usually in the form API you have access to the $form_state['values'] variables.

You may also want to read about the drupal_write_record() function.

Custom scripts should use the Drupal API (don't hardcode database credentials!)

Whether it's custom migration scripts (in most cases the migrate module is much more practical), a quick script to fix something in the database or a custom cron that doesn't play well with hook_cron, beginner Drupal developers (which doesn't mean that they are beginner developers) may try to save time by not using the Drupal API. After all, if it's a write once, use once, who cares.

Here's how Drupal, or more precisely drush, can save you time:

use "drush php-script" to execute the script. This way, drush does a full bootstrap of Drupal and everything is available, including db_query(). So there is no need to hardcode the database credentials in the script (those credentials will likely change often as you copy a site from various dev environments, to staging, to production).
drush has a helpful drush_log function to log notices, success or error messages. Notices can be printed out from the command line by adding the "--debug" option.
you can use the full Drupal API from drush, and drush itself also has a very useful API for creating new users and manipulating fields, plus many drush sub-modules which can save you a lot of time.

Sanitize output

This is straight from the excellent writing secure code page on drupal.org:

Use check_plain or theme('placeholder') for plain text.
Use check_markup or filter_xss for markup containing text.
Use the t() function with @ or % placeholders to construct safe, translatable strings.

A common mistake is to use arbitrary data in a call to "drupal_set_title":

drupal_set_title(t("Something: %name", $node->title));

Should be:

drupal_set_title(t("Something: %name", check_plain($node->title)));

As with any other situation where you need to display data which had been entered by users. Data is not always filtered when it is stored in the database, so it needs to be filtered when it is displayed since this can affect other users (especially site administrators). Fore more information, search the web about cross-site-scripting (XSS).

Use git for change management

Help track down bugs and avoid really silly mistakes by using change management for your code, themes and Drupal configurations.

My favorite trick is to version control Views by using the drush_views module to regularly export all views into a directory, then to commit the changes. This makes it easy to "diff" two revisions to see exactly what has changed and when. Using the features module may be a cleaner solution, and since Features generates a bunch of code, you can do version control on that too.

Git is easy to adopt. While the idea of having a "distributed source revision control system" may sound scary, in short, all it means is that you can have a git repository locally, without a server, or you can share changes to other servers too.

If you don't have any experience with Git or with other source code revision tools (CVS, SVN), at the very least, create a local repository.

On the command line, go to the top-level directory of your module or theme, then type:

git init
git add *
git commit -m "initial repository creation"

Every time you do a change, you can review and commit your changes:

git diff [optionally with the name of the file]
git add [name of file]
git commit -m "a summary description of your changes here"

And then you can review changes with:

git log

All that information to track the changes in your code are stored locally in a ".git" directory

Git is easy to install on most Linux distributions ("apt-get install git" on Debian/Ubuntu or "yum install git-core" on CentOS/Fedora). There is also a lot of documentation for Mac OSX and Microsoft Windows. Windows users may also want to look at tortoisegit.

There is also great documentation to learn Git:

git-scm.com, more specifically see the [documentation](http://git-scm.com/documentation] section.
The Pro Git book and website has a lot of freely available resources (the whole book is available online)

Different philosophies: how many code repositories?

There is no consensus on how to best manage the code:

one repository per custom module, theme, configurations? (This is what I do, since if I want to version-control everything include code from drupal.org, I will create a "drush_make" makefile and put that into my version control. Has the inconvenience that if you are pushing your code to a remote server, you must have a repository for each of those modules, which may be a bit annoying to manage.)
using git sub-modules? (Some people find this hard to use and confusing, not obvious how it works out when pulling modules from drupal.org)
one repository for all custom modules? or all the sites/example.org/ directory? (This has the advantage of reflecting the fact that your site is "one project" and everything must be at a same given version, without the hassle of tracking core and contrib modules)
one repository for the whole Drupal, include Drupal core (I find this unpractical when using Aegir, and do not feel the need to version-control contrib modules).

In my opinion all of these options are valid. Use whatever suits you.

Use an issue tracking system and cross-reference with your code

An issue tracker, or bug tracker, helps track the feature requests and bug reports that help evolve your project.

Instead of managing a pile scrap paper, napkins and random e-mails as a documentation for your project, enter them as feature requests and bug reports in your issue tracker. This is the best short and long term documentation for your project. Get your clients and colleagues to use it too. Instead of receiving e-mails from clients, ask them to open a new issue or comment in an existing one.

Redmine, for example, is a fast and simple to use. It installs easily with Debian (apt-get install redmine).

A few recommendations:

Refer to certain bugs or requests with their issue number, ex: "in feature #1234 about some-fancy-idea, ...". Even if it sounds weird, at least everyone can quickly access the issue and be sure of exactly what you are talking about. It also helps to keep discussions on focus.
In meetings, get people to update the issues as you go, otherwise the comments get lost on random pieces of paper.
A good issue title is probably as valuable as a good newspaper title. It also makes it easier to find old issues after some time.
Cross-reference your issues (related to, child ticket of, ...). Makes it easier to find related issues and get a global idea. For example, if you have a issue about the theming of your website, and your site has 10 sections to theme, open one "meta" ticket for all the theming, then one child ticket for each section. If there have been 10 bugs reported about a specific functionality, mark them as related, eventually it will be handy (avoids regressions).
Open one issue per topic. For example, if you had only one issue for the theming, but then in the comments you start having discussions about the bugs in the various sections, it will be very hard to see what is the overall status of the theming, and if the bugs reported in the comments really are being resolved.

Ticket workflow: the status of your issue will evolve until it is closed. Make sure everyone has the same understanding of what each status means. For example:

New: the issue was created (either by a developer or a client)
Open: the issue was accepted by a developer and work has started on the issue
Fixed: the issue is considered to be fixed by the developer
Closed: the client has accepted the fix (the client should always be the one who closes the issue, especially if she created the issue initially)

Should I go on? There are probably a lot of good references on this topic (please leave a comment if you have any suggestions).

Simplify the requirements, don't complicate the code

Often the client does not know what they want, want everything, they will learn as the project starts going live. The first iteration is always a big step for the client. The new project will have a lot of impact on their staff and users/clients, and they may want to change the priority of some aspects once they start testing/using it. Developers should not be afraid of raising issues about the relevance of feature requests.

A few rules:

If the requirements are hard to understand, don't work on assumptions, simplify the requirements first and have them validated by the client (write a short spec).
If edge cases are hard to automate, the client probably may not mind not automating it (will it provide a good return on investment?)
- or postpone it to a second phase, where those edge cases will become more clear ("we can automate it later, but first see if it's really worth it, how often this issues comes up").
Compare to the existing/previous process. While the new one may not be perfect, is it better? How much do they want to invest to make it perfect? Can those improvements be made later?
How many people are affected by the edge cases?
Do you really want to have all those exceptions in your code? Can you move them to a separate sub-module?

Important for developers: make sure you clearly document edge cases in the code, with a reference to the issue number.

Use Drupal coding standards

I initially found the Drupal coding standards a bit ridiculous and annoying at first, especially the "two spaces" indentation. Just get used to it. There's nothing worse than having to read through code that has been formatted in many various ways.

Use the coder modules to validate your code. It has a lot of other good advice too.

Conclusion

What started out as an idea to write a quick "10 tips" article could almost be expanded into a book. It has helped me a lot to reflect on my work, and I hope it has given you a few ideas too. I didn't try to make it a how-to for anyone starting to work for Drupal, but rather a few words of caution for anyone already writing code, hacking, patching or tweaking Drupal code, especially to those who, like me, often write that code in a rush and forget about it afterwards.

I tried to stick to the essentials, avoid the obvious comments. I assume that if a specific topic has raised an interest you will search for web for more information. Feel free to leave a comment or contact me if you have any feedback.

Many thanks to fellow colleagues, especially those from Koumbit, who have been the biggest influence of my current work habits (well, at least, the good ones!).

Montréal - Saint-Sauveur, en vélo

mathieu — Sun, 24 Jul 2011 17:03:46 +0000

Je suis monté en vélo de Montréal à Saint-Sauveur (Laurentides). Ça devait faire au moins 2 ou 3 ans que je ne l'avais pas fait. Voici quelques notes pour mieux préparer le trajet la prochaine fois (dans 2 semaines!). Montée:

0h : Métro de la Concorde (9h15)
1h15 : Blainville (10h30)
2h15 : Saint-Jérôme (11h30)
3h45 : Pont de la rivière, Piedmont, ~ kilomètre 18 (13h00)
4h00 : Chemin Avila (13h15)

Notes:

Du métro de la Concorde, la piste cyclable est parallèle à la ligne de train. Il faut prendre le côté droit.
Après l'axe Sainte-Rose (i.e. une fois rendu à la Gare Sainte-Rose), j'ai tourné à gauche pour traverser la rivière par la route 117 (où il y a une piste cyclable, mais ensuite il faut faire quelques kilomètres sur la route 117, jusqu'au Chemin de la Côte Saint-Louis E), ce qui est un peu plus court que de passer par le détour qui va au Bois-des-Filion.
Ça m'a pris beaucoup de temps pour monter après Saint-Jérôme, puisqu'il était rendu midi et le soleil tappait fort. J'aurais dû partir plus tôt et faire une pause à Prévost.

Retour:

0h : départ Chemin Avila (9h00)
0h45 : parc régional de la Rivière du Nord (9h40)
2h15 : berge nord de Laval, petit parc près de la route 117 (11h10)
3h00 : métro de la Concorde (12h00)

Métro de la Concorde à Lionel-Groulx: 35 minutes (hors-pointe), le billet coûte 3$.

Autres constatations:

j'aurais dû prendre un cadenas plus léger que mon énorme cadenas Planet Bike (gros «U») que j'utilise à Montréal. Je barrais rarement mon vélo plus de 5 minutes et c'est loin d'être aussi risqué que le centre-ville de Montréal...
j'avais encore mon lourd rack à vélo pour le siège de ma fille (en acier). Rendu à Saint-Sauveur, je l'ai changé pour un rack en aluminium.
Open Street Map ont d'excellentes cartes de pistes cyclables (voir le "cycle layer", accessible par l'icône bleu "+" dans le coin supérieur gauche de la carte)

Netsweeper Inc: Système de censure «made in Canada»

mathieu — Mon, 11 Jul 2011 12:00:23 +0000

Cette compagnie basée en Ontario se vante d'aider les gouvernements à censurer l'accès à Internet:

«A recent trend gaining more traction each day is Government bodies taking more responsibility and controlling what information is available and being viewed on the Internet within their region or country. Taking control of this resource for the protection of the greater population is termed Lawful Interception. Implementing Netsweeper in the core of national, government owned Telcos enables legislative bodies to enforce safe and positive Internet environments.»

Voir: http://www.netsweeper.com/index.php?page=netsw_gov

Mise à jour:

12 juin 2011: Canadian-made censorship (The Star)
10 juillet 2011: Canada needs clear cyberspace censorship policy, watchdog says (The Star)
12 juillet 2011: Censurer Internet avec de la technologie canadienne (Le Devoir)

Désirez-vous vraiment utiliser votre voiture tous les jours?

mathieu — Tue, 21 Jun 2011 14:23:08 +0000

Même si on me dit qu'il y a encore des gens qui ressentent le besoin de méticuleusement imprimer chaque courriel, je suis un peu tanné de ces petits messages moralisateurs en pied de page de courriels.

Tant qu'à être moralisateur, allons-y pour du vrai changement! Désirez-vous VRAIMENT prendre votre #@! de char tous les jours?

Pour le pied de page de courriels

Un classique ...

Et sur la Rive Sud...

«Un État qui n'a pas les moyens d'effectuer des changements n'a pas les moyens de se maintenir.» Source: Le Devoir.

Même votre GPS vous aime pas...

Using the dynamic DNS feature of dns.he.net

mathieu — Thu, 16 Jun 2011 17:15:41 +0000

tunnelbroker.net (by Hurricane Electric) offers a free IPv6 tunnel service that you can use for at home or with servers in order to encourage IPv6 adoption. Since I'm using it for my home network, which includes a few minimal servers as well, I also use their excellent free DNS service. The DNS service includes "dynamic DNS" support, meaning that a computer on an IPv4 network can update its DNS regularly. For people like me using a lousy throttled by telecom monopolies home DSL connection with a dynamic IP, it can be useful to find my way back home if I'm on an IPv4 network (my IPv6 addresses being static).

The feature is not very well documented in the DNS management interface, so in short:

when creating a new "A" entry, check the box "Enable entry for dynamic dns" (it may display 127.0.0.1 as your IP, if you are connecting using IPv6, don't worry)
after adding the new entry, a "refresh" icon will appear in the "DDNS" column of the DNS listing
click on that icon to generate a new key which will be used as your password.

We are now ready to configure it on the client (e.g. the computer on the lousy home DSL connection):

install "ddclient" (apt-get install ddclient, on Debian/Ubuntu)
the remote server is dyn.dns.he.net
the username is the subdomain name, ex: www.example.org
the password is the key that was generated earlier
and enter again the subdomain, as being the entry that will be updated

If you don't have the Debian installation-wizard, in other words, you need to put something similar to this in your /etc/ddclient.conf:

pid=/var/run/ddclient.pid
protocol=dyndns2
use=if, if=ppp0

server=dyn.dns.he.net
login=www.example.org
password=somerandomkey
www.example.org

Disque dur ressuscité

mathieu — Tue, 12 Apr 2011 22:47:36 +0000

J'ai un disque dur qui est mort suite à une panne de courant. Je pensais que c'était juste le boîtier d'alimentation, mais le disque aussi ne fonctionnait plus. Près du connecteur électrique du disque on pouvait clairement voir qu'un bout avait brulé. J'avais des copies de sauvegardes, mais .. un répertoire en particulier où j'ai les photos de ma fille depuis un an n'étaient pas incluses dans la sauvegarde.

En cherchant par hasard sur Internet, je suis tombé sur deadharddrive.com, où quelqu'un explique qu'il a changé le contrôleur de son disque dûr (le PCB, printed circuit board) pour récupérer les données. Il y explique, entres autres, l'importance de la version du firmware (micro-logiciel) gravé dans la puce du contrôleur. Donc il ne fallait pas juste que je retrouve un Seagate de 500 Go, mais aussi avec le modèle ST350063AS, firmware 3.AAC, "site code" TK, etc. C'est un disque de quelques années, donc ce modèle exact ne se vend plus nulle part.

En lisant les forums de deadharddrive.com, j'ai trouvé deux solutions pour remplacer le contrôleur:

Trouver un modèle usagé sur eBay, avec les exactes mêmes caractéristiques
Commander le contrôleur à partir d'un magasin, ex: hkmingdi.com (approx 15$ + frais d'expédition) et onepcbsolution.com (approx 50$ + frais d'expédition)

Pour les deux magasins, j'ai dû leur écrire directement pour trouver le bon modèle de contrôleur. Seul hkmingdi.com l'avait en stock.

Ce qu'il faut savoir pour trouver le bon modèle:

Modèle, ex: Seagate Barracuda 7200.10 ST350063AS
P/N, ex: "98J146-500"
Firmware, ex: "3.AAC"
Site code, ex: "TK"
Date code, ex: "07423"
Main chip number, ex: "100404225" - ceci est écrit sur une des grosses puces du PCB
PCB number, ex: 100406533 REV A - ceci est écrit sur l'arrière du PCB, il faut donc le dévisser

Voici des photos du PCB, où l'on peut voir le bout brulé ainsi que le numéro principal de la grosse puce:

L'autre côté du PCB, où l'on voit le "PCB number" dans le coin:

Une chose importante à savoir: en usine les disques sont optimisés selon des micro-détails spécifiques à chaque unité. Il est donc possible qu'un PCB, même s'il est exactement du même modèle, ne fonctionne pas. Dans ce cas, une option est de demander à onepcbsolution.com de faire le transfert du firmware de l'ancien PCB au nouveau.

Bref, dans mon cas, ça s'est adonné que j'ai trouvé un disque de l'exact même modèle. J'ai changé les PCB (il suffit de dévisser/revisser, rien de compliqué, pas de soudure, pas d'ouverture du boîtier) et hop, disque ressuscité!

À savoir pourquoi le disque a eu ce genre de problème, et pourquoi mon boîtier d'alimentation Antec généralement de bonne qualité a explosé malgré le fait qu'il était branché sur une batterie APC... mystère... En attendant, je vais m'assurer de vérifier mes copies de sauvegarde plus souvent, sans oublier que ceci est arrivé peu après le "world backup day" (31 mars).

AVERTISSEMENT: ceci est pour divertissement seulement. Si vous essayez ceci sur votre disque, c'est à vos risques et périls, ne me demandez pas pour de l'aide, allez lire des sources mieux documentées (telles que deadharddrive.com et ses forums).

Log

Configurer Virtualbox avec IE7, IE8, IE9 sous Debian GNU/Linux

Installer VirtualBox sur Debian

Obtenir des images VHD de Windows

Configurer la carte réseau

Références

Tag:

Make the Drupal 7 language switcher work with multi-lingual CiviCRM

Tag:

Meta: site web mis à jour à Drupal 7

Tag:

Installing CiviCRM SVN trunk with Aegir (on Debian/Ubuntu)

Aegir installation

Installation of provision_civicrm

Create a new Aegir platform

Run GenCode

Add the platform to the Aegir front-end

Tag:

Common Drupal module developer beginner errors

Where is the custom code?

Custom code and namespace prefixes

PHP snippets should be in files, not nodes/blocs/views, and don't forget about the cron

Correct use of the SQL functions to avoid injection attacks

Custom scripts should use the Drupal API (don't hardcode database credentials!)

Sanitize output

Use git for change management

Use an issue tracking system and cross-reference with your code

Simplify the requirements, don't complicate the code

Use Drupal coding standards

Conclusion

Tag:

Montréal - Saint-Sauveur, en vélo

Tag:

Netsweeper Inc: Système de censure «made in Canada»

Tag:

Désirez-vous vraiment utiliser votre voiture tous les jours?

Pour le pied de page de courriels

Un classique ...

Et sur la Rive Sud...

Même votre GPS vous aime pas...

Tag:

Using the dynamic DNS feature of dns.he.net

Tag:

Disque dur ressuscité

Tag: