Une fois n’est pas coutume (quoique…)… cet article ne sert à rien… mais a juste pour objectif d’annoncer que je quitte la société de service que j’ai rejoint il y a déjà 3 ans pour me lancer dans le vaste monde de l’indépendance…
Je quitte donc une société de service où j’ai eu la chance de rencontrer et côtoyer des personnes géniales (aussi bien humainement que professionnellement) et qui m’a donné ma chance pour essayer de suivre et de transmettre mon enthousiasme à mes joyeux camarades ;-)
Lorsqu’un projet débute, il est important (à mon avis) de se poser la question sur la façon dont celui-ci sera découpé. Pour être plus précis, il existe deux types d’approches :
le découper fonctionnellement, le découper techniquement. En outre, en plus de ce type de découpage, il est également important de s’interroger sur la façon dont il sera représenté dans le SCM : faut-il tout mettre dans le même projet (au sens SVN ou git du terme) en utilisant éventuellement des sous modules maven si c’est ce dernier qui est utilisé, ou faut-il en créer plusieurs?
Suite à de nombreuses présentations de Cassandra (faites, entre autre, par Michaël Figuière) et à une opportunité de regarder plus précisément ce qui se cachait réellement derrière cette implémentation d’une solution de la famille des produits NoSQL orienté colonnes, je vais, dans cet article, tenter de décrire ce que j’ai aimé et ce que je n’ai pas aimé sur Apache Cassandra.
Je tiens toutefois à préciser que je n’ai aucune expérience réelle sur le produit et que je ne m’appuierai donc que sur sa documentation officielle en version 1.
Bon, voilà, cela fait un moment que je n’ai pas bloggé… manque d’inspiration peut être… manque de temps ou changement des priorités pour consacrer plus de temps à la lecture de livres en retard…
Dans cet article, je voudrais revenir sur un point que j’avais légèrement abordé dans ce post portant sur les livrables mais en le développant pour se focaliser sur une petite réflexion portant sur l’importance de s’intégrer aux processus de compilation et de livraison au plus tôt… en fait, pour être plus précis, je n’avais pas vraiment abordé cette problématique mais cela vient du même constat… ;-)
Ce petit article est plus une tranche de vie ayant pour objectif de montrer l'importance de savoir lire une documentation qu'un "vrai" post intéressant... Il est vrai que savoir trouver son information s’applique énormément dans le monde Open Source où il est crucial de savoir fouiller (documentation, forum, …) lorsqu’un fait technique (anomalie? framework incomplet? cas d’usage délirant? …) a lieu mais cela s’applique aussi dans notre vie de programmeur de tous les jours.
Je n’ai encore fait aucun article sur JMX (Java Management eXtension). Pourtant, je pense qu’il s’agit d’une technologie indispensable pour toute application qui se veut un minimum sérieuse et industrialisable. Dans ce post, je ne parlerai pas de “comment ça marche” ou je ne fournirai pas de tutoriaux. Il s’agit juste d’un petit coup de gueule parce que j’en ai marre d’entendre toujours les mêmes inepties sur JMX…
Bon, pourquoi JMX me direz-vous?
