Archives de Catégorie: Java

Java / Javascript / PHP / etc.

Au vu du nombre de langages disponibles dans le secteur des nouvelles technologies il devient de plus en plus difficile de choisir de s’investir sur un langage ou un autre. Je pratique le Java depuis maintenant 12 ans et il faut dire que ces dernières années l’informatique a changé à un point que je n’aurais pu imaginé 12 ans auparavant.

Le moteur de ces changements c’est le tout connecté donc Internet et les périphériques mobiles. Ainsi pour une entreprise moderne suivre ce mouvement impose d’avoir un système d’information (ou du moins une partie) pouvant suivre ces évolutions.

En clair pour créer un nouveau produit / une nouvelle prestation quelle technologie utiliser en 2014 ? Supposons qu’il faille partir de zéro, quoi choisir ? Il y a 12 ans s’il s’agit d’un site Internet cela aurait été du PHP avec du MySQL et un frontal Apache (souvenirs souvenirs). Dans un contexte d’entreprise avec plusieurs développeurs le Java était aussi un très bon choix, moins facile à aborder mais plus puissant.

Maintenant … je n’arriverais pas à choisir. Il s’agit parfois plus d’une question de philosophie et/ou de compétences que de pertinence. PHP ? OK mais par exemple avec le framework Symfony. Et encore je me porterais plutôt sur d’autres choix : soit Javascript (avec Node.JS) soit Java (avec Spring Boot). Le premier sera idéal pour démarrer ou avec des contraintes de charges mais le deuxième sera plus judicieux dans un contexte d’entreprise (attention c’est un choix strictement personnel, il existe tellement de langages / plateformes …).

L’évolution de l’informatique (et de ses services) s’accélère et c’est bigrement motivant. Mais aussi frustrant car il est plus en plus difficile de faire les bons choix.

Au final dois-je laisser tomber Java au profit de Javascript ? Non ! Mais apprendre les deux et concilier deux mondes différent oui !

Publicités

JHipster

Hier j’ai parlé de Spring Boot qui fait parti des projets Hype du moment pour tout développeur Java. En fait la problématique c’est comment démarrer rapidement un projet web (ou autre) ? Spring Boot répond à ce besoin de pouvoir faire un site web ou une API Rest (ou encore une fois autre) en quelques lignes de code.

Cependant en parallèle Node.JS est devenu très populaire car le Javascript est devenu très populaire (Node.JS c’est du Javascript coté serveur ET en asynchrone : bonus XXL).

Mais voilà Spring Boot est un bon départ mais après il reste à faire une interface avec Angular JS (ça aussi c’est Hype, enfin surtout pour un backoffice ou une application de gestion, mais en tout cas j’adore), mais aussi lier à une une base de données (MongoDB c’est Hype, MySQL/PostgreSQL c’est aussi pas mal pour structurer ses données), loguer, mesurer, déployer, etc …

La solution ? Le projet JHipster ! Il s’agit d’un projet géré via yeoman c’est à dire qu’il faut installer Node.JS (tiens encore lui) et d’installer yeoman via npm, le gestionnaire de package de Node.JS pour enfin avoir la commande yo afin de faire un petit yo jhipster et de répondre à toute ses questions (choisir sa base de données, son gestionnaire de package, la manière d’identifier un utilisateur, etc.). JHipster consiste à la fois à du code Java (une API Rest + des templates délivrés à Angular JS) mais aussi à une interface de type SPA avec Angular JS, BootStrap, etc avec l’utilisation, en bonus de très bonnes librairies comme Metrics ou Swagger.

Jusqu’à maintenant je connaissais les archétypes maven, notamment le kickstart de Spring 4 MVC ou encore les quickstarts de JBoss ou encore JBoss Forge mais aucun ne faisait du fullstack en alliant le monde Java (via Spring) et le monde Javascript (via Grunt/Bower/etc.). C’est donc chose faite via JHipster et en plus via une SSII français aka Ippon Technologies (société auquelle j’avais postulé en 2008, je regrette parfois de ne pas avoir accepté la proposition finale). Le site web lié explique très bien comment cela fonctionne, comment l’installer, comment le déployer, etc. Bref, bravo. Après certaines choses ne me conviennent pas (je suis très difficile) à savoir que je préfère utiliser un serveur Java EE plutôt que tomcat et donc d’utiliser des DataSource(s) (tomcat peut le faire) l’utilisation de JTA/JPA et si possible de JAX-RS (via Jersey ou RestEasy) voir plus si possible (qui peut le plus peut le moins).

Donc JHipster est une très bonne base pour un projet Hype, mais, comme toujours, demande de l’ingénierie pour l’adapter à son propre contexte.

Note à part : JHipster fonctionne sous WildFly 8.1 il suffit juste de ne pas intégrer les librairies tomcat-*.jar dans le WAR généré. Par contre je ne suis pas arrivé à intégrer Spring Boot en tant que module dans WildFly. Donc le WAR fait plus de 50Mo et n’est pas allégeable avec WildFly. Si le serveur d’intégration continue est en entreprise mais que le déploiement est dans un cloud privé alors cela est problématique de transférer 50 Mo à chaque déploiement … A travailler.

Design pattern : Double-checked locking

Un article intéressant sur Wikipedia concernant le design (anti) pattern « Double-checked locking »

Double-checked locking

C’est subtile, pas toujours évident au premier coup d’oeil mais finalement on comprend qu’il s’agit d’un risque elevé d’erreurs … bien après avoir exploité le pattern.
Et puis c’est toujours bon de se rafraîchir la mémoire concernant le mot clé « volatile » introduit par Java 5.