Je code donc je suis

Mon logiciel iMotion avance doucement. Quelques optimisations du code avec GStreamer permettent maintenant de switcher d’effet très rapidement. En effet auparavant le changement d’effet réinitialisait le pipeline et donc la webcam. Maintenant je bloque le pad de la webcam, ce qui me permet de détruire l’ancien GstElement en charge de l’effet, le recréer avec le nouvel effet puis relier les pads. Le résultat est un changement très réactif, on peut s’amuser à jongler entre les effets sans latence. GStreamer me parait très puissant et est à mon avis mal exploité par les logiciels existants. Par exemple Cheese réinitialise la webcam à chaque changement d’effet, je la vois qui clignote…

Il y a je pense encore beaucoup à faire côté multimédia sur Linux, et si l’on veut un peu plus qu’un “simple” lecteur vidéo il nous faudrait de tout évidence un GIMP de la vidéo. Je n’ai bien sûr pas cette prétention, d’autant plus que je m’intéresse plus à l’aspect temps réel que post traitement. Sans aller vers un logiciel aussi poussé que vidvox GNU/Linux est à mon avis capable d’aller sur ce secteur dévolu à Apple. Encore faut-il accepter que cela sera impossible en utilisant de simple langage script comme Python ou Ruby, chose que j’ai fini par admettre :)

Il y a bien 12 ans j’étais convaincu qu’un jour je me mettrais vraiment au C++, juste que je n’avais pas prévu mettre autant de temps :) S’il y en a qui ont tendance à procrastiner comme moi, voici de quoi gagner quelques années.

J’ai découvert il y a peu 2 superbes tutoriels qui permettent d’apprendre les langages C et C++ : Apprenez à programmer en C ! , Apprenez à programmer en C++ !. Excellent car l’auteur est très pédagogue et a la capacité de poser les questions que l’on se pose à mesure de la lecture et d’y répondre.

Il n’y a pas photo, le C++ simplifie énormément le C … Par exemple le CIN et COUT qui remplacent aisément le printf, la possibilité d’utiliser des références à la place des pointeurs, le new qui détecte automatiquement la taille à allouer et donc nul besoin d’effectuer un sizeof, le type bool, le possibilité de déclarer une variable n’importe où même dans la déclaration d’une boucle, le typedef automatique, les valeurs par défaut dans les paramètres des fonctions, la surcharge des fonctions, les fonction inline, et bien sûr tout ce qui est spécifique à la POO.

A mon avis il est quand même nécessaire de comprendre un minimum le C même s’il est possible d’apprendre directement le C++ . Cependant je pense que Ruby est à mon avis un meilleur moyen d’apprendre la programmation et la POO avant d’attaquer le C++ . C -> Ruby -> C++ ou Ruby -> C -> C++ est un bon parcours d’apprentissage.

Évidement en C++ pur on ne fait pas grand chose et il est nécessaire d’apprendre l’usage d’une bibliothèque graphique si on souhaite faire des IHM. Mais quoi qu’il en soit ce langage ouvre toutes sortes de perspectives (embarqué, client desktop, serveur, extensions, ...) choses difficiles à obtenir avec des langages plus simple de haut niveau.

D’autres tutoriels complémentaires : Cours de C/C++ de Christian Casteyde , Introduction au langage C de Bernard Cassagne

Ah si en 1996 j’avais eu Internet, toutes ces docs, le GNU/Linux actuel et Ruby … Ils sont chanceux les gamins d’aujourd’hui :) < / mode papy aigri>.

J’ai enfin décidé de me mettre au C++ et pour débuter faire une IHM à effectv. Je sais qu’il existe Cheese mais effectv est beaucoup plus fourni en effets visuels et mon objectif n’est pas d’en faire un clone.

Pour l’instant rien d’extraordinaire vu que cette application me sert surtout d’apprentissage mais j’arrive néanmoins à afficher ma webcam et à utiliser des filtres d’effets visuels. Il n’y a que 8 effets qui ont été porté d’effectv en plugin GStreamer mais cela sera l’occasion de tenter de porter ceux qui manquent. Pour ceux qui veulent compiler le source voici le dépôt GIT. Attention je ne me suis pas encore mis aux autotools donc il faut lancer le script compile dans le répertoire script en ayant auparavant modifié la constante DATADIR dans imotionapp.h et installé les bibliothèques de développement gtkmm, libglademm et gstreamermm.

Merci au guru master Dodji pour ses tuyaux :)

un screenshot avec l’effet dicetv :

Ruby possède une sympathique lib pour générer des codes barre via la lib rmagick : barcode.

Cependant la doc est plutôt inexistante, la seule trouvée sur le net ne fonctionne pas via une installation en gem : http://jrhicks.net/123

Voici donc le bout de code qui va bien :

sudo gem install barcode 
sudo apt-get install librmagick-ruby

require 'rubygems'
require_gem 'barcode'
require 'barcode/code39'

myBarcode = Code39::new("Hello World")
myBarcode.to_img("helloWorld.gif",200,50)

Vu via la liste de Railsfrance et le blog de Laurent une excellente introduction à Ruby on Rails.

Simple curieux ou désireux de débuter en RoR, à lire absolument :)

Un courageux a lancé un Appel A Débattre sur usenet, pour proposer la création d’un forum dédié à Ruby dans la hiérarchie fr.*

L’Appel A Voter avait échoué au précédent vote en 2001. Il faut espérer qu’il en sera enfin autrement cette fois-ci … Il faut toujours au moins 80 votes positifs et 3 fois plus que le non.
A se demander comment on peut voter contre la création d’un forum dédié à un langage libre de programmation, mais ne sous-estimez pas la connerie humaine surtout sur Usenet.

Une annonce sur le forum Ruby de Linuxfr : http://linuxfr.org/forums/28/17013.html

L’annonce sur fr.usenet.forums.annonces, Message-ID:

<m2mzcyblkm.fsf@gimli.dustnet.teaser.fr>

Les débats sur fr.usenet.forums.evolution, Message-ID:

<m2mzcyblkm.fsf@gimli.dustnet.teaser.fr>

J’avais parlé d’interface asynchrone dans ce billet.

Cela consiste tout simplement à ce qu’une interface puisse continuer à prendre les évènements de l’utilisateur pendant qu’elle se met à jour.

L’exemple typique est celui d’un treeview mettant un certain temps à se remplir. Dans un programme classique, l’interface sera figée le temps que le treeview soit remplit.

Une interface asynchrone permet d’être mise à jour à mesure, et de répondre aux évènements de l’utilisateur. Pour faire cela le programmeur lambda (moi le premier :) pensera à un thread pour résoudre ce problème.
Le thread contenant la partie du code insérant les données dans le treeview. Il va s’en dire qu’un thread pour cette tâche est plutôt “overkill”. De plus on ajoute un élément rendant le programme difficile à débuguer.

La Glib propose la méthode g_idle_add. Cette fonction permet d’effecter un traitement lorsque la boucle d’évènement de GTK+ idle, c’est à dire lorsqu’il n’y a plus d’évènement hautement prioritaire à gérer.
Cette fonction est bien sûr bindé en RG2 :

GLib::Idle.add {
  traitement
}

Voir l’exemple dans le paquet libglib2-ruby : /usr/share/doc/libglib2-ruby/examples/idle.rb

Ensuite, si vous avez un traitement répétitif à effectuer, il existe la fonction g_timeout_add. Cette fonction exécute votre traitement dans un intervale régulier et selon une priorité définissable. Voir l’exemple dans /usr/share/doc/libglib2-ruby/examples/timeout.rb

Ces deux fonctions permettent d’éviter les threads et rendent votre IHM un peu plus asynchrone. Voir les explications détaillées en C sur ce billet : Lazy Loading Using The Main Loop et un exemple plus simple en python : Re: Lazy loading

Malgré ceci, il se peut que vous deviez forcer GTK+ à se mettre à jour :

while (Gtk.events_pending?)
              Gtk.main_iteration
end

En gros, tant que GTK+ a des évènement en attente, on lui laisse la main. Ceci me sert à forcer le rafraichissement du treeview des pages jaunes. Pour diverses raisons (callback SAX2) je ne peux pas mettre la boucle alimentant le model du treeview dans un g_idle_add. Cette boucle me permet donc d’arriver à un résultat similaire même si le g_idle_add est à privilégier.

Merci aux conseils de Dodji, teuf et HappyPeng.

Vous ne jurez que par Rails et donc l’utilisation d’un framework objet MVC ?

Votre boite s’est investie depuis longtemps sur PHP, et il y a peu de chance pour qu’elle accepte une nouvelle techno ?

Il existe une alternative au code PHP gruik. En effet le projet cakePHP est une adaptation en PHP du fameux framework Rails.

Certes il n’est pas entièrement comparable, et dans une vue vous devrez encore utiliser des tableaux :
$data[‘Publisher’][‘name’]

Alors qu’en Rails vous faites :
@publisher.name
, vous avez un vrai objet.

Mais c’est malgré tout une grande avancé dans le développement structuré en PHP. Attention vous ne pourrez plus programmer comme avant :)
Voir un tutoriel.

ps : Rails retourne tellement le web que même Apple a senti le besoin de fournir un tutoriel.

J’ai cédé à l’appel du Grand Geek il y a 2 semaines en migrant ma Breezy vers Dapper.

En passant, XGL ça rox, mais bon ça saoule assez vite aussi pour l’instant. Vivement des applets GNOME qui exploitent OpenGL.

Geekast fonctionne pas si mal en dapper. Il profite des améliorations de Gstreamer 0.8.12, la lecture vidéo et audio n’est plus saccadée. Le lecteur interne me parait exploitable dans une certaine mesure. En effet ca plante toujours si vous rafraichissez les pages jaunes pendant une écoute …
Enfin apparement la trayicon plante sur le clic droit dans un environnement PPC. Si des possesseurs de Mac/PPC veulent bien me confirmer la chose je ferai un bug report aux développeurs.

A part ces bricoles je vais sortir la 0.1 dans la semaine, puisque je n’ai pas eu de retour :/

Ensuite je vais intégrer la libgtk-mozembed-ruby qui permettra de consulter, via une page web directement intégrée dans Geekast, les statistiques d’un flux et son chat. Ces possibilités n’étant pas intégrées dans Peercast mais seulement proposées par le site des pages jaunes il n’y a pas d’autre moyen propre (pas question de parser un html). J’aurais bien utilisé la librsvg et cairo, si Giles (le développeur de Peercast) avait intégré les stats dans le flux XML…
A ce propos la version 0.1215 vient de sortir, elle corrige des buffer overflow, pas de nouvelles feature donc :/

Enfin j’envisage de réécrire Geekast en GTKmm (C++), d’une part pour apprendre et d’autre part pour lui ajouter des possibilités qu’il sera difficile d’implémenter en Ruby efficacement. Avoir voir si je ne ferais pas un autre projet parallèle en fait.
Mais ceci est une autre histoire assez lointaine dans l’année.

Laurent Julliard, le traducteur du livre sur Ruby on Rails répond à une interview fort intéressante chez Eyrolles. On comprend mieux les avantages de Ruby face à Python et surtout PHP :) . N’hésitez pas à consulter l’exemple associé pour être totalement convaincu.