Mon classement des trucs les plus cools avec Ruby :

• Mixin (Ruby)
• Minimal Syntax for DSL (Ruby)
• MVC (Rails)
• URL Routing (Rails)
• Eval family (Ruby)
• Pure OOP (Ruby)
• ActiveRecord (Rails)
• Introspection (Ruby)
• Functionnal Programming (Ruby Procs/Blocs)
• Automatisation (Rake, Capistrano, Rdoc)
• Migration (Rails)
• Shell scripting (Ruby)
• Active Resource (Rails)
• Generators (Rails)
• irb (Ruby)
• Gem (Ruby)

Sacrée liste! je ne pensais pas qu'elle serait si longue quand je l'ai commencée. Ya pas à dire Ruby est vraiment cool!
On pourrait presque faire un bouquin avec ca, il devrait s'appeler: "Ruby is so cool !" (en fait je pense que Why est déja en train de l'écrire).

J'ai eu envie de me simplifier la vie aujourd'hui. J'ai décidé d'écrire une tâche Rake pour uploader des fichiers souvent mis à jours, sur un serveur distant.
Je n'avais aucunes idée de la meilleure solution et comme souvent dans ces cas là, ca n'a pas été simple de la découvrir.

Je me suis d'abord intéressé à Capistrano mais je l'ai trouvé surdimensionné par rapports à mes besoins personnels. Je croyais que rsync serais à ma mesure mais le manque de documentation m'a freiné.
Et puis j'ai réalisé qu'un simple sftp me convenait parfaitement. Cela avait plusieurs avantages : possible connection automatique (il semble que ce soit la différence avec scp) et possible utilisation de la librairie Net::SFTP.
Mais mauvaises surprises: je n'aime pas la syntaxe de Net::SFTP (NB: et il existe déja un script pour la synchronisation à distance) et la connection automatique de sftp par batchfile n'accepte pas les passwords!
Il a donc fallu générer des clés partagées avec la commande (ssh-keygen -t rsa) et après un peu de shell scripting via le Kernel, voici donc une tâche Rake muy buena :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#Attention, n'utilisez pas ce script si vous ne le comprenez pas!
#Nécessite d'avoir sftp d'installé et une clé partagée avec le serveur

desc "sftp command to customize"
task :sftp do
        #server address
        server_address = "you@example.com"
        #sftp command
        source_dir = "#{RAILS_ROOT}/dir_to_upload/*"
        destination_dir = "remote_dir/"
        command = "put "+ source_dir
        #sftp call
        call = "sftp -b /dev/stdin" + " " + 
                server_address + ":" + destination_dir + 
                " <<EOF\n" + command + "\nquit\nEOF\n"
        puts call
        system(call)
end

Pour ceux qui ne connaissent pas sftp, voici les principales commandes qu'il supporte :

• cd : changement de répertoire distant.
• lcd : changement de repertoire local.
• ls : liste des fichiers distants.
• lls : liste des fichiers locaux.
• put : upload de fichier.
• quit : fin de la connection.
• get : download de fichiers.
• mget : multiple get.

J'ai décidé de partager une petite méthode qui génère le cache d'une page..
Comment ca? ca existe déja! Ha non attendez, c'est très différent regarder bien le nom des fonctions : caches_page (!=) caches_page_now.

Vouz avez compris? Non! Bon arrêtons de perdre notre temps, allez lire un autre billet et revenez quand vous aurez besoin d'exporter des pages web.

1
2
3
4
5
6
7
8
9

def caches_page_now(attrs)
    #be carefull to add a route for '.html'
    path = "#{RAILS_ROOT}/public/#{attrs[:controller]}/#{attrs[:action]}.html"
    #don't forget to instanciate the action variables
    content = render_to_string(:action => attrs[:action])
    File.delete(path) if File.exists?(path)
    FileUtils.makedirs(File.dirname(path))
    File.open(path, "wb+") { |f| f.write(content) }
 end

Envie d'une url se terminant en .html pour votre application Rails?
Dans X_controller.rb, redéfinissez la méthode default_url_options qui sert aux UrlHelper :

1
2
3

def default_url_options(options)
  { :format => 'html' }
end

Dans routes.rb on définit le format des urls manipulées par Rails.

1
2

map.connect ':controller/:action.:format' # pour action.html
map.connect ':controller/:action/:id.:format' # pour id.html

Pour ceux qui s'amusent des confrontations libres/propriétaires, standart/innovation, normes/agilité... Je vous conseille les excellentes parodies de "Hi, I'm a mac.." version Rails, Java, Php.., réalisées par les deux compères de railsenvy.com et que j'ai découvert via le blog de laurent Bois.

Connaissez vous l'émission Hanselminutes podcastée par Scott Hanselman? Moi non plus ! Et pourtant on y retrouve d'excellents invités issus du monde ruby : Martin Fowler, DHH, John Lam...

Je vous invite donc à écouter son entretien de Mai dernier avec Martin Fowler (Thoughtworks) et David Heinemeier Hansson (37 signals).

A l'occasion de la Rails conf, ils y évoquent le rôle essentiel du Xhtml, page blanche idéale face aux trop grande libertés offertes par Flash. Un plaidoyer pour un langage qui en 10 ans à fait ses preuves malgrés ses faiblesses, et un doute sérieux face à la vague actuelle des RIA et l'extension des interactions desktop sur le Web qui ne s'adressent qu'aux Geeks (Desktop et Web correspondant à des modèles mentaux différents chez les utilisateurs, la trop grande liberté offerte aux développeurs et designer graphiques y sont vus comme des sources d'égarement alors que les besoins basiques du web ne sont toujours pas remplis et connus).

C'est aussi l'occasion de célébrer des mantra chers à 37signals sur l'importance de "Getting Real", de se confronter avec le medium Web et pas un autre tel Photoshop, de ne pas utiliser des documents d'apaisement (les interface sont les spécifications), de faciliter la vie du développeur en terme de convention-"best practises", et mon petit préféré face à l'evil-itude de M$ : "Action can speak more than words..".

En joke de fin, on apprend qu'il existe une règle pluralize pour "octopus", just for fun !

Petite métrique intéressante découverte au hasard sur le site de ThoughtWorks : plus de 40% de leurs nouveaux projets aux états-unis sont développés avec Ruby on Rails.
Voila une companie qui se donne les moyens de satisfaire ses clients :) !

Vous avez fait un site dynamique avec rails (ou un autre langage dynamique, pour ce tuto c'est kif kif) pour vous simplifier la tâche mais désormais vous apprenez qu'il va être héberger statiquement, et vous n'êtes pas responsable de sa mise à jour...aie!
La personne en charge de sa maintenance souhaiterait une version html avec un template Dreamweaver.

Ca doit pas être méchant mais retranscrire toute l'architecture à la mano, hum... non merci! (NB: je vous le dis tout de suite je n'aime pas dreamweaver, je préfère un bon éditeur de texte comme textmate).
Heureusement j'ai trouvé le moyen de m'en accomoder et comme les exemples sont rares sur le web, voici mon petit cours : les templates dreamweaver comme relais entre un développeur et un webmaster/designer. Ouvrez vos cahiers.

Notez tout d'abord : les balises dreamweaver pour le template sont inclus dans des commentaires html. Je vous conseille donc de transposer directement votre layout en balises dreamweaver avec des conditions logiques identiques à celles utilisés par votre langage préféré. En fouillant, on peut faire pas mal de chose avec les expressions logiques de Dreamweaver, je vais vous présenter les principale.

Dans Dreamweaver les balises sont présentes dans Insertion>Objets de modèle.
On doit déclarer les variables dans le "head" du template, elles peuvent être du type boolean, text, number, color, ou URL. Voici leur syntaxe :

<!-- TemplateParam name="page_id" type="text" value="id='current_page'" -->

Ensuite on peut appelé la variable n'importe ou dans la page avec la syntaxe suivante:

@@(page_id)@@

Il existe une structure conditionnelle (région facultative en dreamweavlang) de la forme :

<!-- TemplateBeginIf cond="boolean_var==true" --><!-- TemplateEndIf -->

Pour avoir plusieurs conditions il faut les imbriquer entre des balises :

<!-- TemplateBeginMultipleIf --><!-- TemplateEndMultipleIf-->

Pour modifier un bout de texte du template (dreamweavlang --> région modifiable) :

<!-- TemplateBeginEditable name="doctitle" -->texte modifiable<!-- TemplateEndEditable -->

Autre chose, pour associer votre template à chaque page, il faut ajouter en haut de chaque "head" de page :

<!-- InstanceBegin template="/dir/template.dwt" codeOutsideHTMLIsLocked="false" -->

Simple non? Mais tout ceci n'est que configuration et je vous conseille de faire le pré-test dans Dreamweaver. Ce qu'il faut savoir c'est que sur chaque page utilisant le template, une instance de la variable doit être présente dans le "head", sa syntaxe est identique, exepté que le terme Template devient Instance, par exemple :

<!-- InstanceParam name="title" type="text" value="Page d'accueil" -->

C'est la valeur de cette variable que je vous conseille de générer avec votre langage dynamique avant d'exporter le tout. De la même manière, je vous conseille de le faire d'abord sur une page dans Dreamweaver.

Une fois le site configuré, généré et importé dans dreamweaver (Site> nouveau site...), le responsable de la maintenance peut ensuite facilement modifier les variables de chaque page an appelant la boite de dialogue (Modifier > Propriétés du modèle...).

Conclusion

On peut passer d'un site dynamique à un logiciel comme Dreamweaver sans trop de difficultés à conditions de penser à utiliser une génération automatique des variables d'instance qu'il attend.
Ce sera tout pour aujourd'hui. Fermer vos cahiers.