blog.name.nil? :

rafraîchir les miniatures générées par attachment_fu

Sat, 19 Jul 2008 01:14:00 +0200

Vous gérez l’upload d’images sur votre projet rails avec attachment_fu. Vous avez une belle miniature générée toute seul lors de l’upload. Mais vous venez d’apprendre que vous allez devoir générer une autre miniature d’une taille différente et le projet en production à déjà quelques centaines d’images uploadées derrière lui.

Pour regénérer la totalité des miniatures présentes sur le serveur, il faut juste lancer une petite commande dans la console rails : attachment_fu utilise une fonction déclenchée après sauvegarde en base de données de l’image principale pour générer les miniatures : after_process_attachment.

Problème, cette fonction est privée. On va donc forcer le déclenchement de l’appel en re-sauvegardant toutes les images :

Picture.all.each &:save

Développer sur le serveur de production, quelle bonne idée !

Thu, 17 Jul 2008 14:28:00 +0200

Posons le décor :

base de données aussi imposante qu’inexportable sur un poste de développement
temps d’import trop long pour être opérationnel avant la fin du contrat
performances devant être maintenues à toute heure sur le serveur de production, rendant la création d’une base de test caduc

Comment faire pour tester des modifications devant passer en production ASAP …

PostgreSQL est là pour nous sauver/aider !

Tout d’abord, utiliser des transactions pour s’isoler des données accessible par les autres services. Il s’agit d’un segment dans lequel toutes les modification sont cloisonnées, identique aux branches utilisées dans les arbres de développement d’un projet : les modifications faites dans une transaction ne seront répercutées sur l’ensemble de la base qu’au moment du commit la fermant. Le début d’une transaction est marqué par la commande BEGIN et 2 choix sont possibles à la fin d’une transaction : COMMIT ou ROLLBACK.

Mais, les transactions ont un petit inconvénient quand on travaille directement avec et non dans un script : elles n’acceptent plus de nouvelle commande si jamais une erreur s’est produite, il faut alors rollback au début de la transaction. Plutôt gênant quand une opération est chronophage.

C’est là qu’entre en jeux les points de sauvegarde : exactement comme la plupart des jeux vidéos, il permet de revenir en arrière.

Mais pourquoi PostgreSQL alors que MySQL supporte les transactions et points de sauvegarde ? Tout simplement parce que les transactions de PostgreSQL supportent les modifications de structure des tables.

BEGIN;

DELETE FROM users WHERE is_bot;
SAVEPOINT bot_deleted;

CREATE INDEX idx_users_email ON users(email);
SAVEPOINT index_created;

ALTER TABLE users OOPS_I_MADE_A_MISTAKE;

ROLLBACK TO index_created;

SELECT * FROM users;

COMMIT;

premier plugin

Fri, 27 Jun 2008 13:21:00 +0200

Et voila, enfin … Ma première vrai contribution au monde du libre et plus particulièrement à celui de ruby on rails : http://agilewebdevelopment.com/plugins/named_fixtures_exporter

Rails plugin: named fixtures exporter

Thu, 26 Jun 2008 18:48:00 +0200

Pour ceux qui comme moi utilisent des fixtures nommées dans rails 2.x, vous avez sans doute été confrontés au problème de maintenance de ces pas si petits fichiers yaml.

Le problème quand on travaille sur un projet faisant des calculs sur plusieurs modèles et donc tables, c’est qu’on doit tester un maximum de cas afin d’être sûr de ne rien broyer en cas de mauvaise optimisation. Il faut donc des jeux de données assez conséquents et les fixtures peuvent jouer ce rôle. La blague, c’est qu’en simplifiant les liaisons entre les fixtures en utilisant des noms et non plus les id, on se retrouve avec un système encore plus complexe à gérer quand le volume de données grandit.

Pour répondre à ce problème, voici un petit plugin pour rails 2.x permettant d’exporter le contenu de la base de données dans des fichiers de fixtures. La différence avec ceux existant déjà tient dans un fait simple : les relations belongs_to et has_and_belongs_to_many sont gérées avec le nom des fixtures.

Un exemple sera plus parlant :

class Message < ActiveRecord::Base
  belongs_to :sender
  belongs_to :recipient

  has_and_belongs_to_many :medias
end

$> rake db:fixtures:display_named
---
sent_message_751373555: 
  body: qu'en penses-tu ?
  sender: fabien
  type: SentMessage
  sent_at: 2008-06-12 15:28:43 Z
  subject: de bien belles fraises
draft_message_893975074: 
  recipient: etienne
  sender: fabien
  type: DraftMessage
  subject: "RE : invitation jacuzzi"
sent_message_751373556: 
  body: le meilleur jus d'oranges du monde!
  recipient: etienne
  sender: fabien
  type: SentMessage
  sent_at: 2008-06-19 15:25:43 Z
  subject: tropicana 2
  read_at: 2008-06-26 14:40:53.707300 Z
  medias: strawberry_sunset
received_message_507475146: 
  body: everything's ok
  recipient: fabien
  sender: etienne
  type: ReceivedMessage
  sent_at: 2008-06-19 15:29:00 Z
  subject: test
  read_at: 2008-06-26 13:54:50.333372 Z

Le plugin va regarder pour chaque modèle spécifié les relations à prendre en compte, parcourir chaque entrée dans la base de données et pour chaque relation le plugin va chercher dans les fichiers de fixtures le nom de la fixture associée à l’entrée lue. Si aucun nom de fixture n’existe, il est crée en se basant sur la colonne title, name ou le nom de la classe suivie de l’id. L’écriture du fichier se faisant après le traitement, il est possible de rafraîchir les fixtures d’un modèle sans perdre les noms déjà présents.

2 rake tasks sont disponible : export_named et display_named. En installant le gem progressbar, vous aurez une barre de progression vous indiquant l’avancement si vos fixtures sont conséquentes.

Il y a encore des lacunes (doublons non gérés) et il manque quelques tests, mais la base du plugin est présente et fonctionnelle.

Pour l’installation du plugin :

$> ./script/plugin install http://named-fixtures-exporter.googlecode.com/svn/trunk/named_fixtures_exporter

Rails plugin: named fixtures exporter

Thu, 26 Jun 2008 18:39:00 +0200

Pour ceux qui comme moi utilisent des fixtures nommées dans rails 2.x, vous avez sans doute été confrontés au problème de maintenance de ces pas si petits fichiers yaml.

Rails plugin: named fixtures exporter

Thu, 26 Jun 2008 18:39:00 +0200

Pour ceux qui comme moi utilisent des fixtures nommées dans rails 2.x, vous avez sans doute été confrontés au problème de maintenance de ces pas si petits fichiers yaml.

PostgreSQL & Rails

Sat, 10 May 2008 12:13:00 +0200

Après migration sur PostgreSQL et discussions avec koollman connaissant bien cette base de données, j’ai pu faire quelques optimisations. L’authentification installée par défaut avec macports se fait par la méthode ‘trust’, ce qui permet à tous les utilisateurs locaux passant par une socket de se faire passer pour un autre utilisateur.

En passant sur une authentification ‘ident sameuser’, on se protège donc de cette faille et cela permet toujours d’accéder à la base de données sans mot de passe. Modifiez ceci dans le fichier pg_hba.conf dont le path est /opt/local/var/db/postgresql83/defaultdb/pg_hba.conf :

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
local   all         all                               ident sameuser

On précise au serveur qu’il faut reload le fichier :

$> sudo su postgres
$> pg_ctl reload -D /opt/local/var/db/postgresql83/defaultdb

La création de l’utilisateur en super-utilisateur peut se faire en utilisateur normal ayant le droit de créer des base de données. Le script createuser posera les questions sans que vous ayez à spécifier de flag avec la commande.

Enfin, une entrée database.yml peut maintenant être simplifiée : l’utilisateur / mot de passe ainsi que l’hostname ne sont plus nécessaire.

development:
  adapter: postgresql
  encoding: utf8
  database: my_great_project_development

RAILS sur PostgreSQL pour lÃ©opard

Fri, 09 May 2008 13:57:00 +0200

Vous avez déjà franchi le pas du système d’exploitation en passant sur un vrai système pleinement utilisable en tant que développeur mais aussi utilisateur final voulant du fonctionnel sans taper 15k commandes, c’est bien.

Vous avez aussi fait l’étape d’arrêter d’essayer de refaire le monde avec votre framework web et utilisez un vrai framework objet comme il se doit, c’est bien.

Il ne reste plus qu’à faire de même avec votre base de données. Seul soucis, mysql (voir sqlite) est agréable par sa simplicité et son zeroconf ou presque. Mais installer postgreSQL n’est pas si difficile que cela … en quelques étapes. De plus, RoR offrant maintenant des rake tasks pour créer et supprimer les base de données, vous n’aurez pas ou presque pas de commande spécifique à mémoriser.

Première étape : mettez à jour votre ports et les logiciels présents.

$> sudo port selfupdate
$> sudo port upgrade outdated

Seconde étape : installation de postgreSQL serveur et client.

On va se simplifier un poil la tâche en installant le serveur seul, les dépendances installant le client.

$> sudo port install postgresql83-server

--->  Fetching postgresql83
--->  Attempting to fetch postgresql-8.3.1.tar.bz2 from http://ftp8.us.postgresql.org/postgresql/source/v8.3.1/
--->  Verifying checksum(s) for postgresql83
--->  Extracting postgresql83
--->  Configuring postgresql83
--->  Building postgresql83
--->  Staging postgresql83 into destroot
--->  Installing postgresql83 8.3.1_0

To use the postgresql server, install the postgresql83-server port
--->  Activating postgresql83 8.3.1_0
--->  Cleaning postgresql83
--->  Fetching postgresql83-server
--->  Verifying checksum(s) for postgresql83-server
--->  Extracting postgresql83-server
--->  Configuring postgresql83-server
--->  Building postgresql83-server with target all
--->  Staging postgresql83-server into destroot
--->  Creating launchd control script
###########################################################
# A startup item has been generated that will aid in
# starting postgresql83-server with launchd. It is disabled
# by default. Execute the following command to start it,
# and to cause it to launch at startup:
#
# sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql83-server.plist
###########################################################
--->  Installing postgresql83-server 8.3.1_0

To create a database instance, after install do
 sudo mkdir -p /opt/local/var/db/postgresql83/defaultdb
 sudo chown postgres:postgres /opt/local/var/db/postgresql83/defaultdb
 sudo su postgres -c '/opt/local/lib/postgresql83/bin/initdb -D /opt/local/var/db/postgresql83/defaultdb'

To tweak your DBMS, consider increasing kern.sysv.shmmax by adding an increased kern.sysv.shmmax .. to /etc/sysctl.conf
--->  Activating postgresql83-server 8.3.1_0
--->  Cleaning postgresql83-server

On va se contenter d’écouter ce qu’on nous dis et exécuter les commandes suivantes (vous pouvez aussi copier-coller depuis votre shell pour simplifier):

$> sudo mkdir -p /opt/local/var/db/postgresql83/defaultdb
$> sudo chown postgres:postgres /opt/local/var/db/postgresql83/defaultdb
$> sudo su postgres -c '/opt/local/lib/postgresql83/bin/initdb -D /opt/local/var/db/postgresql83/defaultdb'

The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locales
COLLATE: C
CTYPE: UTF-8
MESSAGES: C
MONETARY: C
NUMERIC: C
TIME: C
The default database encoding has accordingly been set to UTF8.
initdb: could not find suitable text search configuration for locale UTF-8
The default text search configuration will be set to "simple".

fixing permissions on existing directory /opt/local/var/db/postgresql83/defaultdb ... ok
creating subdirectories ... ok
selecting default max_connections ... 20
selecting default shared_buffers/max_fsm_pages ... 2400kB/20000
creating configuration files ... ok
creating template1 database in /opt/local/var/db/postgresql83/defaultdb/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... ok
creating dictionaries ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the -A option the
next time you run initdb.

Success. You can now start the database server using:

/opt/local/lib/postgresql83/bin/postgres -D /opt/local/var/db/postgresql83/defaultdb
or
/opt/local/lib/postgresql83/bin/pg_ctl -D /opt/local/var/db/postgresql83/defaultdb -l logfile start

Troisième étape : lancement du serveur au démarrage de la machine

$> sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql83-server.plist

Quatrième étape : modification de l’environnement

Les binaires de postgreSQL ne sont pas accessibles directement, une petite modification de votre variable PATH vous donnera pleinement accès à tous les binaires et les scripts rails de création/suppression de base de données marcheront comme un charme. J’ai effectué cette modification dans le fichier .bash_login de mon utilisateur normal :

export PATH=~/bin:/opt/local/bin:/opt/local/sbin:/opt/local/apache2/bin:/opt/local/lib/postgresql83/bin:$PATH

Détail ayant son importance, il vous faut soit relancer un shell, soit lancer la commande dans le shell courant pour pouvoir espérer poursuivre l’installation.

Cinquième étape : installation pour rails

Il y a 3 gems ruby différents pour postgreSQL. Ca fait un peu beaucoup. Quelques recherches nous orientent rapidement vers postgres :

officiellement maintenu par la communauté postgreSQL
support natif et rapide comme le gem mysql
dernières releases datent de cette année, alors que pour d’autres on remonte à 2006

On tente donc une installation qui va échouer vu que le postgres à été compilé avec le seul support de l’architecture i386. Il nous faut donc lancer la commande suivante :

$> sudo env ARCHFLAGS="-arch i386" gem install postgres
Building native extensions.  This could take a while...
Successfully installed postgres-0.7.9.2008.01.28
1 gem installed
Installing ri documentation for postgres-0.7.9.2008.01.28...
Installing RDoc documentation for postgres-0.7.9.2008.01.28...

Sixième étape : gérer les droits et accès sur une machine de développement

Vous développez sur votre machine personnelle et voulez donc éviter la complexité d’avoir un serveur SQL avec une authentification … comme votre setup actuel sur MySQL. Pour cela, il vous faudrait vous connecter en user postgres avec le role postgres mais ca semble compliqué. Soit, créons donc un autre super-utilisateur pour votre login. Je vous laisse faire la substitution vous même :

$> createuser --superuser rider -U postgres

On me signale qu’il est bon de rappeler que cette configuration est à proscrire en environnement de production ;)

Dernière étape : tester dans une application existante utilisant l’antique MySQL

On substitue l’adapter et l’user dans le fichier database.yml :

  adapter: postgresql
  username: postgres

Et on lance les petites commandes pour tester que tout va bien :

$> rake db:create:all
$> rake db:migrate
$> rake db:fixtures:load
$> rake test:units

Sources :

dynamisme du langage et patch

Fri, 18 Apr 2008 00:32:00 +0200

Développant un projet faisant un appel à un webservice pour un client, je dois passer des Arrays tel un formulaire html classique. J’ai donc naturellement utilisé les fonction réseau du langage Ruby, vu que le framework que j’utilise pour ce projet n’est autre que le Ruby on Rails. Je me retrouve donc avec une librairie maison pour gérer mes appels vers ce webservice, mais petite surprise dans l’encodage des fameux Arrays : les entrées du tableaux sont simplement concaténées les unes aux autres.

On est loin de ce que devrait faire un Array dans ce cas précis !

Pour rappel, un Array nommé test avec 3 valeurs passé dans une requête POST devrait ressembler à ceci :

test[]=one&test[]=two&test[]=three

En fouillant quelque peu sur le net, on trouve en effet mention de ce bug dans la fonction censée encoder les paramètres dans un format de formulaire web. Bug ouvert il y a environ un an et toujours pas fermé bien que le patch ait été posté. On trouve même un exemple du comportement normal avec … PHP.

Ne souhaitant pas modifier les sources du langage installé sur mon système pour éviter de devoir reproduire la même chose sur les serveurs en production, j’ai décidé de tirer partie du côté dynamique du Ruby en redéfinissant la fonction dans ma petite librairie.

module Net::HTTPHeader
  def set_form_data(params, sep = '&')
    params_array = params.map do |k,v|Â 
      v.inject([]){|c, val| c << "#{urlencode(k.to_s)}=#{urlencode(val.to_s)}"}.join(sep)
    end
    self.body = params_array.join(sep)
    self.content_type = 'application/x-www-form-urlencoded'
  end
end

Ca fait vraiment plaisir de travailler avec un langage certes imparfait mais qui permet des corrections dynamiques sans hack immonde ou patch totalement horrible à maintenir en production.

Paris, 7 avril 2008

Mon, 07 Apr 2008 02:15:00 +0200

il neige !

Je ne sais pas trop si on doit voir cela en bien ou en mal …