Petite revue des points essentielles que j'ai noté sur les nouvelles technologies de l'année 2007.
Je ne traite pas des technologies Web et Open-sources qui occupent des niches souvent prometteuses mais moins diffusées dans l'industrie. Je ne traite pas non plus des technologies Sun par gout personnel...

Les technologies microsoft :

• Xaml est définit à un niveau de granularité plus faible que le mxml, il est donc plus flexible mais nécessite de manipuler plus de code.
• WPF est intégré à vista mais nécessite l'installation du Framework .net 3.0 pour les autres windows. C'est un chargement très lourd et peu pertinent. Une application WPF ayant une interface Xaml reste facilement skinnable. .net CLR intègre de plus en plus de languages avec notamment ruby.
• Silverlight sera intégré à Visual studio 2008 que microsoft propose déja une beta. Comme WPF il repose sur une interface Xaml. Ces principaux point faibles sont le manque de références, une littérature encore limitée (Les bouquins amériquains sur silverlight 1.0 vont sortir à partir d'octobre). Les démos techniques sont prometteuses, et disposent de bonnes performances.

Les technologies Adobe :

• ActionScript 3.0 dispose d'un compilateur JIT (just-in-time) très performant. Il permet notamment l'utilisation de technologies 3D avancées.
• AIR est très facile d'installation (moins de 10 mega), il intégre un browser webkit et permet à chaque application de s'auto-updater selon son numéro de version.
• L'intégration de flex avec AIR serait finalisée avec flex 3. La principale faiblesse de .air reste ses limites en terme de protocoles de communication en raison d'une sécurité élevée : .air peut seulement lire et écrire des fichiers, appeler des Webservices et accéder à une base de données SQLite.
• L'interface mxml est plus facilement skinnable que celles reposants sur des composants flash (à travers des attributs et la CSS).

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.

Vous avez remarquez ? ce billet est dans la section agilité, et bien ce n'est pas une technologie mais une philosophie qui participe à l'écriture de bon programmes.
Tout ca pour écrire ce que j'entends par agile :

• Une automatisation de tous les workflows répétitifs.
• Des fonctions organisées de facon à être testées et DRY.
• Une séparation souple de la configuration du programme et de ses règles logiques.
• Une approche pragmatique et itérative de la gestion de projets.
• Pas de sur-optimisation et de sur-spécification.

C'est ma vision personnel de ce que certains appellent Getting Real.

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

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.

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.