Java

Archi & techno

Utiliser Hadoop pour le calcul de la Value At Risk Partie 1

Après avoir introduit la Value At Risk dans mon premier article, je l’ai implémentée en utilisant GridGain dans mon second article. J’ai conclu dans ce dernier que les performances relativement bonnes obtenues étaient liées aux optimisations réalisées. L’une d’elles était basée sur l’hypothèse que les résultats intermédiaires – les prix issus de chaque tirage – pouvaient être oubliés. Cependant, ce n’est pas toujours le cas. Conserver les paramètres de génération et les prix des calls pour chaque tirage peut être très utile pour le métier afin de pouvoir analyser l’influence des différents paramètres. De telles données sont souvent traitées par des outils de Business Intelligence. Le calcul de la VAR n’est peut être pas le meilleur exemple pour illustrer ce besoin métier mais je vais le réutiliser car il a déjà été introduit dans un précédent artcile. L’objectif de cette série d’articles sera de calculer la Value At Risk et de conserver tous les résultats, de façon à pouvoir les analyser.

  • Dans la première partie, je décrirai comment conserver ces données aussi bien avec GridGain qu’avec Hadoop
  • Dans les trois parties suivantes, je décrirai en détail les implémentations avec Hadoop. Ces parties fournissent des exemples de code très utiles mais peuvent être ignorées au besoin en première lecture
  • Dans la cinquième partie, je montrerai comment utiliser Hadoop pour réutiliser de l’analyser décisionnelle sur ces données
  • Et dans la dernière partie, je donnerai quelques chiffres de performances et sur les possibilités d’amélioration

Lire la suite

Archi & techno

Utiliser GridGain pour le calcul de la Value At Risk

Après un premier article introduisant l’intérêt de la Value At Risk and du calcul en grille, nous allons désormais étudier l’implémentation de cet algorithme en utilisant un middleware de calcul en grille. J’ai choisi GridGain, un middleware open source qui implémente le pattern map/reduce (cf. mon précédent article). Pour commencer, je vais donner un aperçu de l’implémentation de la Value At Risk indépendamment de l’architecture de calcul en grille. Ensuite, je décrirai le middleware GridGain et les classes à implémenter pour tirer parti de la grille. Enfin, je fournirai quelques mesures de performances prises sur mon portable et proposerai quelques pistes d’optimisation.
Lire la suite

Archi & techno

Industrialisation des développements : automatisez votre base de données

Le grand oubli dans l’industrialisation des développements est la base de données, cette chose monolithique et statique qui n’évolue pas aussi vite et aussi aisément que le code. Au même titre que l’intégration continue et les systèmes de gestion de version pour le code source, il existe des outils permettant de fluidifier et d’automatiser le travail autour du schéma physique des données. Travailler avec ces outils permet de compléter une démarche Agile en permettant une réactivité forte face aux changements.

Une première partie de cet article concernera les principes et pratiques autour de ces outils (partie « boss compliant »). La deuxième est orientée technique (partie « geek aware »).

Lire la suite

Archi & techno

Problèmes courants: Imprécision des calculs mathématiques (2e partie)

Nous avons déterminé dans la première partie que les nombres à virgule flottante sont à proscrire.

Nos armes seront donc le BigDecimal en Java, le type decimal en .Net. Malheureusement, d’autres pièges pavent notre chemin.

Notes:

  • Sous Oracle, le type NUMBER(p,s) peut être soit décimal si p (et optionnellement s) est spécifié et sera à virgule flottante sinon. Conclusion, toujours spécifier p (et s pour avoir des décimales).
  • Pour un Web Service, la valeur d’un type xs:decimal sera sous forme texte (ie. « 123.456 ») et sera donc précis et mappé sans problème vers un BigDecimal (Java) ou decimal (.Net).

Lire la suite

Archi & techno

Problèmes courants: Imprécision des calculs mathématiques (1ère partie)

J’inaugure aujourd’hui une nouvelle chronique que j’ai appelée problèmes courants. J’y traiterai l’une après l’autre les erreurs classiques rencontrées à travers mes années d’informatique.

Ce premier article de la série visera à démystifier les calculs mathématiques et à établir de bonnes pratiques au sein d’une application d’entreprise. Par application d’entreprise, nous entendons une application gérant des montants d’argent, des prix, des quantités. Il a été coupé en deux, la première partie expliquant le problème, la deuxième montrant comment le gérer en Java et .Net.

Bill travaille sur un logiciel de paiement de commissions. Il doit ajouter une commission de 1,2$. Il se fait donc une petite méthode faisant cette opération et le petit test unitaire qui va avec.

 @Test
 public void testAddCommission() {
  double actual = addCommission(1000000.1);
  assertEquals(1000001.3, actual, 0);
 }

 public static double addCommission(double nominal) {
  return nominal + 1.2f;
 }

java.lang.AssertionError: expected:<1000001.3> but was:<1000001.3000000477>

« Ah ben zut alors! C’est pas le bon résultat ».

Qu’est-ce qui se passe?
Lire la suite

Archi & techno

Développer une application parallèlement sur iPhone et Android

Depuis sa sortie, l’iPhone fait une percée remarquable dans le marché du smartphone proposant toujours plus d’application sur son AppStore. Plus récemment, Android se répand à grande allure et les envies d’avoir son application sur l’Android Market se fait sentir. Mais alors comment développer la même application pour ces deux OS ? Comment profiter de leurs spécificités tout en sortant les applications en même temps ?
Lire la suite

Archi & techno

Un DSL SQL pour Java

Alors que Hibernate est très largement répandu dans les projets Java pour accéder à une base de données relationnelle, il arrive que l’utilisation en direct de l’API JDBC reste pertinente.
En effet, il demeure intéressant de rester en SQL « pur » plutôt que de sortir la grosse artillerie lorsque :

  • les données de la base sont plutôt pensées tuple qu’objet : le modèle de données ne présente pas de relations complexes entre
    elles.
  • lors de la reprise d’un existant, il arrive que du code métier soit implémenté en PL/SQL par exemple. Les requêtes peuvent alors faire régulièrement appel à ces fonctions.

Lorsque nous sommes arrivés sur un projet de migration d’une application existante qui cumulait les contraintes précédentes (surtout beaucoup de procédures stockées), JDBC nous semblait une bonne idée. Seulement voilà, lorsqu’il a fallu écrire la requête à 60 critères de recherche qui étaient présents selon les critères que l’utilisateur avait entré sur sa belle IHM, je me suis posé la question de comment faire pour construire ladite requête.
Fallait-il faire des tas de « if » pour tester la présence d’une valeur dans chacun des critères de recherche ? Faire les jointures nécessaires selon les critères fournis ? J’ai entraperçu quelque chose de pas très sympa à écrire et à maintenir.

Pourquoi ne pas encapsuler le choix d’ajouter les clauses SQL à ma requête derrière une API qui le ferait selon les valeurs que je lui donne ? Et puis pourquoi pas faire ressembler cette API à du SQL pour pas inventer une nouvelle API ?
Lire la suite