Métadonnées
Talend propose la notion de métadonnée pour éditer des schémas qui reviennent souvent. Les données à ajouter à ce niveau sont tous les schémas des données que vous utilisez : tables de base de données, fichiers, services web, …

Contextes
Les éléments de contexte sont les éléments qui vont paramétrer vos jobs. Tout ce qui est variable doit donc être ajouté comme élément de contexte. On y retrouve en général les informations de connexion à une base de données, des noms de fichiers, des adresses de services web, …
Ces paramètres pourront être fixés avant l’export des jobs (autonomes, services web, …) ou passés en paramètres lors de leur appel.

Performances
Un gros piège quand on débute avec Talend, c’est son côté user friendly. Tout se fait intuitivement et on ne sait pas toujours ce qui se passe. Cela se traduit par des problèmes de performances ou des comportements inattendus.

• Réutilisez vos connexions
  Avant d’utiliser des éléments d’I/O sur des SGBD (tMySQLInput, tOracleOutput, …), ajoutez un composant tXXXConnection et cochez la case « Utiliser une connexion existante » dans les paramètres de vos composants d’I/O, sans quoi Talend rouvrira une connexion pour chaque élément.
• Paramétrez vos tMap
  Le composant tMap, puissant et simple d’utilisation est un piège courant dans l’utilisation de Talend. Son fonctionnement par défaut consiste à charger toutes les lignes du mapping en mémoire. Si vous manipulez des volumes importants, songez à utiliser un fichier de stockage temporaire. Les paramètres du tMap vous permettent d’utiliser un tel fichier à partir d’un nombre limite de lignes chargées.
• Privilégiez le SQL
  Les composants de Talend (tMap, tJoin, …) chargent tout en mémoire. Les filtres sur les composants en entrée, les jointures sont réalisées sur les données déjà chargées en mémoire. Par ailleurs, le comportement par défaut des tXXXInput consiste à faire un « select * from … ». Vous chargez donc l’ensemble des tables en mémoire, puis filtrez/joignez sur ces données. Pour améliorer les performances : ne sélectionnez que les éléments donc vous avez besoin dans les tXXXInput, filtrez directement en SQL (ajoutez une clause WHERE dans les tXXXInput) plutôt que dans les tMap et en règle générale, limitez le nombre d’éléments que vous remontez en mémoire.

Pièges
Une petite liste de pièges :

• Vous utilisez un composant tXXXConnection pour chaque I/O avec une source de données pourtant, les insertions ne se font pas. Pensez à ajouter un tXXXCommit sur réussite du sous job qui contient l’insertion.
• Vous utilisez un composant tXXXConnection pour chaque I/O avec une source de données. Tout se déroule bien quand vous exécutez le job depuis Talend, mais dès que vous l’exportez vous obtenez un NullPointerException. Pensez à lier votre composant tXXXConnection à votre job avec un lien « OnComponentOK » ou « OnSubjobOK » (dans le cadre d’un composant isolé comme une connexion, l’effet est le même).
• Votre job plante et finit par corrompre votre base de données. Ajoutez un composant tXXXRollback sur erreur du sous job. Attention, cela ne fonctionnera que pour les données qui n’ont pas été committées pour la connexion que vous choisissez. C’est à dire qu’il faut absolument que tous les composants d’I/O sur la source de données utilisent cette connexion.
• Pour être sûr de faire le bon mapping dans un tMap, vous exécutez d’abord une requête dans un client SQL quelconque. Une fois que ca fonctionne, vous la transposez au monde Talend en testant au fur et à mesure et surprise, ca ne fonctionne plus. Certains SGBD ne sont pas sensibles aux accents ou à la casse tandis que Talend l’est. Une requête de comparaison entre deux chaînes peut fonctionner dans votre client et échouer dans Talend. Vous pouvez transformer un peu les chaînes chargées à l’aide des routines Talend (TalendString et sa méthode removeAccents par exemple…)
• Vous obtenez des messages indiquant des erreurs sur le type. Lorsqu’il récupère des schémas à partir de sources de données, Talend a tendance à modifier les types des données. C’est ainsi que, sur MySQL, les int deviennent des long par exemple. De même, il se peut que vous vouliez utiliser un wrapper java pour un type primitif (Integer au lieu de int…). Dans ce cas pensez à cocher l’option « Nullable » lors de la définition du schéma.

DLL Hell :
Problème survenant au fil des installations, mises à jour, et désinstallations de produit d’éditeurs multiples manipulant des DLLs communes, ce qui aboutit à la mise en place de versions incompatibles, de sorte qu’il n’est pas rare que l’installation d’une application ou sa mise à jour cause la perte de fonctionnement d’une autre application, notamment d’un autre éditeur.

Jar Hell :
Le format Jar est difficile à gérer, à packager et à distribuer. Des dépendances incompatibles, des versions en conflits sont autant de problèmes connus et identifiés dans le monde Java sous le nom de Jar Hell.

Solutions
Avec .NET, Microsoft a pallié au problème du DLL Hell en refondant en profondeur les mécanismes des DLL. Le packaging et la distribution sont un des points forts de .NET : plusieurs modules peuvent cohabiter sous des versions différentes. La solution mise en oeuvre prend en compte des métadonnées d’assembly (numéro de version, clé publique, langue, …) pour créer un nom fort unique pour une DLL.

Java, de son côté, a commencé à parler de Java Module System en 2005 via la JSR 277 qui devrait permettre de modulariser Java et de résoudre le Jar Hell. Ainsi, plusieurs versions d’un module pourront cohabiter et les dépendances à une version seront indiquées dans les métadonnées du module. On pourra ainsi dire que le module A utilise les version 3 et + du module B par exemple.

Pour conclure…
Les technologies concurrentes Java et .NET ont dû faire face au problème du packaging et de la gestion des versions. Chacune à sa manière a dû trouver une solution. Je regrette seulement que la solution de Java ait été aussi longue à apparaitre sur la RoadMap alors que .NET a pris le problème à bras le corps assez tôt (2000).

Non pas de grande explication sur la façon dont sera implémenté Java Module System dans Java 8. Pour cela je vous invite à jeter un oeil sur le projet Jigsaw et à lire les excellents articles sur les blogs de Xebia et d’Ippon Technology. L’article suivant explique la solution mise en oeuvre par Microsoft avec .NET : http://msdn.microsoft.com/fr-fr/library/ms973843.aspx

Définitions

• Une expression lambda est une fonction anonyme qui peut contenir des expressions et des instructions, et peut être utilisée pour créer des délégués ou des types d’arborescence d’expression (MSDN).
• Lambda expressions are anonymous functions, aimed at addressing the « vertical problem » by replacing the machinery of anonymous inner classes with a simpler mechanism (OpenJDK).
• Une expression lambda est une fonction anonyme qui capture son environnement : λ xy.5+x capture x et y.

Un peu d’histoire
Historiquement, les lambda expressions nous arrivent tout droit du lambda calcul.

Le lambda-calcul (ou λ-calcul) est un système formel inventé par Alonzo Church dans les années 1930, qui fonde les concepts de fonction et d’application. Il a été le premier formalisme utilisé pour définir et caractériser les fonctions récursives et donc il a une grande importance dans la théorie de la calculabilité, à l’égal des machines de Turing et du modèle de Herbrand-Gödel.

Le lambda calcul définit des entités syntaxiques que l’on appelle des lambda-termes (ou parfois aussi des lambda expressions) et qui se rangent en trois catégories :

• les variables : x, y… sont des lambda-termes ;
• les applications : u v est un lambda-terme si u et v sont des lambda-termes ;
• les abstractions : λ x.v est un lambda-terme si x est une variable et v un lambda-terme.

L’application peut être vue ainsi : si u est une fonction et si v est son argument, alors u v est le résultat de l’application à v de la fonction u. L’abstraction λ x.v peut être interprétée comme la formalisation de la fonction qui, à x, associe v, où v contient en général des occurrences de x (wikipédia).

Le lambda-calcul est à l’origine du paradigme fonctionnel qui s’est illustré au début de l’informatique par les langages suivants (entre autres) :

• Lisp (1959)
• Scheme (1975)
• ML (1897)
• Erlang (1987)
• Haskell (1990)

Après avoir été délaissé au profit de langages orientés objets tels que C++, Java et C#, le paradigme fonctionnel revient sur le devant de la scène. C’est ainsi que chacun de ces langages se dote à son tour de traits fonctionnels (closure pour Java 8, lambda pour .NET 3).

Pourquoi ce retour ?
Si les langages les plus utilisés se dotent de traits fonctionnels, ce n’est pas par hasard. Ceci est étroitement lié à la multiplication des nombres de processeurs dans les machines actuelles.

Le paradigme fonctionnel (pur) permet d’écrire du code dénué d’effets de bords, ce qui le rend sûr, prouvable mais surtout facile à paralléliser. L’absence d’effets de bords permet d’éliminer une partie des problèmes inhérents à la programmation concurrente. C’est ce qui fait le succès d’Erlang (RabbitMQ, Riak, Zotonic, …).

Scénarios types des langages fonctionnels :

• Calcul formel
• Compilation/Interprétation
• Structures de données arborescentes

Conclusion
Je ne pense pas que les langages fonctionnels puissent vraiment revenir dans une industrie où C++, Java et .NET sont aussi présents. Nous assistons pour le moment à l’arrivée de traits fonctionnels dans ces langages et cela s’arrêtera probablement à la notion de fonction anonyme et de fermeture. En revanche, avec le niveau de sûreté nécessaire dans certains systèmes, le paradigme fonctionnel a encore de beaux jours devant lui.

Pour l’anecdote de fin, le concept de map/reduce, utilisé dans les bases de données est une notion empruntée aux langages fonctionnels.