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

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

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

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

Testabilité des IHM : commençons (déjà) par Swing!

Tester l’IHM n’a jamais été chose aisée et globalement deux approches s’opposent :
Tester avec du code. Le principal inconvénient est que cela repose principalement sur le nommage ou l’agencement des composants et – suivant le framework utilisé – peut être assez sensible au refactoring et notamment au modification d’imbrication des composants.
Tester en mode recorder. Le principal inconvénient reste que ces tests ne peuvent être réalisés que très tardivement (et souvent pas par les équipes de développements) et sont sensibles aux modifications d’IHM (repositionnement d’un bouton etc…). Tout refactoring de ce type de tests est impossible et ces outils sont souvent croisés dans des contextes de pure non regression – ie. des contextes où le développement IHM est stable et où l’on souhaite facilement savoir si quelque chose a été cassée ou non.

Il existe quelques solutions de tests d’IHM pour Swing (Swing Unit, SpecUI4j…) mais j’ai envie de m’arrêter sur Fest Swing.
Lire la suite

AOP et Swing : un duo élégant

Ce n’est pas la nouveauté de l’année mais Swing, bien que présent en entreprise, n’évolue que très peu. Le kit de développement offre nativement toujours aussi peu de composants évolués (tableaux triables…) même s’il faut avouer que certaines librairies commerciales compensent à merveille ces manques. Les APIs et le développement Swing est toujours aussi verbeux et finalement assez peu productif (de mon humble avis). Et ce n’est malheureusement pas les quelques JSR en stand by qui vont y changer quoique ce soit : Beans Binding est au statut inactif, Beans Validation, drafté en 2008 n’est toujours pas inclus dans le JDK (peut-être pour la version 7 ?) et la JSR 296 (qui définit au travers de 4 callback le cycle de vie standard d’une application) ne représente pas non plus la plus importante des améliorations qu’ait connu un framework (si si je vous jure j’aime Swing…)

Alors il est nécessaire de compenser ces manques…
Lire la suite

Présentation industrialisation Java au salon Solutions Linux [MAJ 17/03]

[MAJ 17/03] Les slides de la session sont désormais disponibles à la fin de cet article.

Nous serons présent le 17 mars 2010 au salon Solutions Linux. J’aurai le plaisir d’y co-animer une session avec Benoît Lafontaine sur l’industrialisation des développements Java.

Qu’entendons nous par industrialisation ? Principalement 3 activités :

  • l’intégration continue. Nous commencerons par à un retour sur l’état de l’art de cette pratique agile aujourd’hui largement démocratisée, puis nous verrons comment faire face aux nouveaux défis rencontrés : réduction du temps de build, constructions d’applications profilées par environnement, build distribué ou encore build incassable.
  • le développement piloté par les tests. Depuis 4 ans, les outils de tests fonctionnels automatisés comme FitNesse s’efforcent de remettre le besoin et les maitrises d’ouvrage au coeur du développement logiciel. Nous ferons le bilan sur ces outils et balayerons les perspectives offertes par de nouvelles approches et de nouveaux types d’outils (BDD).
  • mesure continue de la qualité. Nous verrons comment utiliser la mesure de la qualité comme une dynamique d’amélioration continue et comment en éviter les dérives comme le « flicage ».

Lire la suite

Trois jours à QCon London 2010 : Tendances et Confirmations

« QConLondon 2010 : the place to be! » diront certains. Ce qui est certain c’est que c’était l’occasion de voir de grands speakers (Uncle Bob, Dan North ou Mickael T. Nygard…) et de sentir les mouvances de notre industrie. Trois jours intenses, 700 participants venus de plus de 50 pays, 6 tracks thématiques par jour en parallèle : difficile de tout voir et absorber mais voici les éléments que nous avons voulus retenir.

Lire la suite