jeudi 8 octobre 2009

Offre de poste : ingénieur des technologies web

Description du poste

Le LIRIS (laboratoire CNRS, UMR5205) / Université Lyon 1 recrute un ingénieur expérimenté au 1er janvier 2010 pour une durée de 20 mois. L'ingénieur travaillera dans l'équipe SILEX dans le cadre du projet ITHACA en lien avec des scientifiques du LIRIS, de l'Université Lyon 2 et du TECFA-Genève. Le projet ITHACA a pour objectif de mettre en place une plateforme web synchrone dédiée au tutorat dans l'enseignement supérieur, dotée de capacités réflexives permettant de favoriser la conscience d'activité de groupe et l'apprentissage. La plateforme sera spécialisée pour être utilisée dans le cadre de plusieurs formation universitaires à distance. Elle utilisera une plateforme de gestion de traces d'utilisation développée dans l'équipe SILEX du LIRIS, appelée SGBT (Système de gestion de bases de traces).

Les missions du candidats seront les suivantes :

  • développement de la plateforme Ithaca et du SGBT
  • coordination des développements de la plateforme Ithaca et du SGBT en liaison avec l'équipe technique de Lyon 2, et avec les autres projets de l'équipe SILEX
  • encadrements de stagiaires et intégration de leurs travaux, etc.

Les technologies utilisées sont des technologies web au sens large : serveur de médias Red5/java, Flex/Flash, python. Une connaissance de frameworks tels que Cairngorm ou Spring serait un plus, ainsi que de REST et RDF.

Le candidat devra justifier de quelques années d'expérience dans le domaine ou dans un domaine proche, il devra avoir des qualités relationnelles, de rédaction, de travail en équipe, etc. Il devra être capable d'être à la passerelle entre des utilisateurs non-techniques et des chercheurs en informatique.

Le poste sera situé à l'Université Claude Bernard Lyon 1

Salaire : > 2200 € net

Contact : envoyer CV + lettre de motivation à Pierre-Antoine.Champin@liris.CNRS.fr et Yannick.Prie@liris.CNRS.fr

Précisions

Rapidement, il s'agit de participer au développement d'une application Flash qui gère des flux audio/vidéo en simultané, avec en parallèle de transactions rapides sur des bases de données et différents services.

C'est un contrat de 20 mois, dans le cadre d'un projet de recherche. Il s'agit pour le candidat d'être leader sur sa partie du travail, mais il pourra (un peu) s'appuyer sur d'autres membres du projet pour des points précis. Nous recherchons quelqu'un qui soit immédiatement opérationnel sur les technologies web utilisées; il est important de bien maîtriser développement d'interfaces graphiques, y compris de nouveaux composants.

Globalement, c'est un boulot sympa, avec du volume mais rien de bien extraordinaire niveau complexité. Les partenaires du projet (différents universitaires) sont dynamiques, avec des profils variés (enseignement de langues, modélisation, visualisation interactive, suivi de l'activité, web sémantique...)

Je peux répondre à toutes vos questions sur ce poste, en privé ou en commentaire de ce billet.

En savoir plus :

Précisions diverses :

  • tout le développement informatique est placé sous des licences libres (GPLv2 et v3, précisément)
  • l'employeur est particulier, puisqu'il s'agit d'un projet de recherche universitaire (CNRS)
  • le projet comporte des personnes fortement impliquées dans le logiciel libre, qui contribuent au noyau linux ou à VLC
  • c'est une possibilité intéressante de travailler dans le logiciel libre : mission longue, correctement rémunérée
  • le projet s'appuie sur de nombreuses technologies libres déjà existantes (java, mysql, python, GNU/linux, HTTP, REsT, RDF, XML, apache), ainsi que sur des outils de recherches libres eux aussi (advene, SGBT)

lundi 10 novembre 2008

Outil d'exploration du web

TouchGraph Google Browser : « The TouchGraph Google Browser reveals the network of connectivity between websites, as reported by Google's database of related sites. »

TouchGraph Google Browser est une version simplifiée et spécialisée de TouchGraph, un outil d'exploration du web. Il suit les liens des pages pour réaliser une cartographie de haut niveau.

Une utilisation concrète est de lancer une exploration sur le nom d'une personne pour découvrir les sites sur lesquels elle apparait, et quelles sont les liaisons entre les informations. On peut alors découvrir des sous-groupes de pages formant des centres d'intérêts et des thématiques globales.

mercredi 3 septembre 2008

Problème d'encodage avec Java sous MacOS X Léopard

Sous Léopard, la machine virtuelle java (JVM) d'Apple se lance par défaut avec l'encodage MacRoman. Si choix est compréhensible au vu de l'histoire des technologies d'Apple, il est toutefois de nos jours rendu obsolète avec le passage à l'unicode. Pire, les développeurs et administrateurs systèmes s'attendent désormais à des outils fonctionnant en UTF-8, ce qui pose donc des problèmes d'intégration.

Pour les systèmes GNU/linux, les différentes JVM travaillent avec l'encodage du système qui est désormais l'UTF-8. Mais la JVM d'Apple se comporte différemment, avec un réglage défini en interne.

Faisons quelques essais avec ce jeu de test.

Commençons avec GNU/linux :

$ uname -a
Linux liristpq.Univ-Lyon1.fr 2.6.27-2-generic #1 SMP Thu Aug 28 17:18:43 UTC 2008 x86_64 GNU/linux

$ java GetEncoding 
Random bytes
encoding: UTF8

$ LC_ALL=ASCII java GetEncoding 
Random bytes
encoding: ASCII

Comme on peut le constater, l'utilisation de l'encodage est dynamique, avec par défaut celui du système.

Regardons maintenant ce que cela donne sur Léopard. Nous commençons par lancer la même commande que pour GNU/Linux, et ensuite nous affinerons manuellement l'encodage UTF-8 avec l'option -Dfile.encoding=UTF-8 :

$ uname -a
Darwin arda.local 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun  9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386 i386 iMac6,1 Darwin

$ java GetEncoding
Random bytes
encoding: MacRoman

$ java -Dfile.encoding=UTF-8 GetEncoding
Random bytes
encoding: UTF8

$ LC_ALL=ASCII java GetEncoding
Random bytes
encoding: MacRoman

La différence est flagrante. La JVM d'Apple sous Léopard utilise par défaut l'encodage MacRoman et ne supporte pas la sélection par les locales, ce qui pose de réels problèmes d'interopérabilité.

Une solution simple est d'appeler systématiquement la JVM en spécifiant l'encodage UTF-8, mais elle n'est pas idéal.