Camel: how to expose static resources in http with jetty component

Introduction

For easier developpement of the application, avoid the use of an apache http server configuration in developpement environment. Sometimes it can be interesting to embbed static resources such as html, javascript and css in the application.

An example of use case:

I expose some REST services consumed by an angularjs application. In development I like to have only my application running and I like to avoid a proxy configuration on apache.

My static files are under /static in my project and my rest services exposed on 8080.

My camel context looks like:

 
<restconfiguration bindingmode="off" component="jetty" host="localhost" port="8080"> 


</restconfiguration> 


<rest> <post consumes="application/json" produces="application/json" uri="/rest/search"> 


<to uri="direct:searchMediator"> </to>


</post> </rest>

Here I use the camel 2.14 include the rest dsl.
First I declared the jetty component to serve rest service.

For now only my rest service is declared no static resources are handled.
So if I try to do http://localhost:8080/static, so I get a 404. It's normal, because jetty only exposes the rest service.

How to deal with that ?

After some search about jetty and the camel component it is possible to define some request handlers in camel.
And we are lucky but jetty provide a ResourceHandler that handle the resources.

The solution:

 


<bean id="staticHandler" class="org.eclipse.jetty.server.handler.ResourceHandler">


<property name="resourceBase" value="static" /> 


</bean>

Here I instanciate a ResourceHandler which is a jetty class with spring camel dsl in specifying the resource base path. In my case /static.

After I declare to camel-jetty component that I will use this handler:

   
<route>


<from uri="jetty:http://localhost:8080?handlers=#staticHandler" /> 


<to uri="mock:empty" /> 


</route>

I just create a route that does nothing except declare the jetty component with handlers. Note the uri ending by ?handlers=#staticHandler . It's possible to add several handlers separated by a quote.

Now try it !

If I try  http://localhost:8080/static, so I can see my index.html file.

Maybe you will consider, Why does it work ? Because we declare two times the jetty component on 8080 ?

The trick is that camel instances only one time each jetty component for a specified host/port, so it means the jetty component between the route and the rest configuration, is exactly the same.

So enjoy your static resources in your camel projet !

Un vent d'indépendance - troisième partie

Trouver une mission

Maintenant que la création de l'entreprise est sur les rails il va falloir penser à trouver une mission.  

Après de nombreuses années à se faire amener ses missions par sa société de service, il fallait cette fois ci trouver une mission par sois-même. Ce qui demande plus d'effort mais aussi un nouvel aspect de mon travail que j'ai trouvé très intéressant.

J'ai commencé à mettre au courant tous les contacts que j'avais dans mon réseau, passer des coups de fils, demandé des recommandations sur linkedin ou viadeo. 

A ce moment là mes efforts étaient concentrés sur la recherche de la mission.
Lorsque l'on commence et que l'on est un peu à court d'argent on est pré disposé à accepter un peu n'importe quelle mission... Erreur ! Je pense que certaines sociétés en ont bien conscience et sont prêtes à faire des offres bien en dessous du marché.


Je me souviens d'un cas où on m'appelle pour une mission potentielle en GWT: "...le développeur devra avoir 3 ans d'xp minimum dans le framework...". Autant dire un profil qui ne courrait pas trop les rues à l'époque.

J'ai pris rendez-vous avec eux, le mec sympa, il m'expliquait un peu la mission, me demandait mon expérience... Rien d'extraordinaire.

On commençait à parler facturation, et là il m'a sorti son TJM à 300 €/J !

Si vous faites un calcul grosse maille avec 300€/J
Vous allez bosser environ 20jrs/mois à 300 € en comptant que vous preniez des vacances.

Soit 6000 €/mois HT vous aller devoir payer:

• Les impôts/l'URSSAF, le RSI
• Des charges inhérentes à votre société telle que la comptabilité
• Des inter contrats ou vous ne serez pas rémunéré.

Il ne vous restera donc que 3000€ environ dans votre poche.

Sachant que lorsque la mission sera terminée vous ne bénéficierez pas du chômage, vous allez devoir gérer plus de paperasse administrative et galérer pour trouver un nouveau logement.

Autant vous dire qu'à ce prix, il vaut mieux rester salarié pour le même poste.
En fait le commercial me faisait un peu penser à ça:

tux images


Après quelques semaines de "réseauttage" j'ai été mis en relation avec une SSII via un ancien collègue.
Entre-temps je suis parti en Chine pendant deux mois (la vie n'est pas chère là bas) . Trois jours après mon retour la SSII m'avait trouvé une mission qui débutait 3 jours plus tard.

Ce qu'il faut savoir sur les offres de mission pour les indépendants, c'est que dans la grande majorité des cas, ce sont des besoins ASAP. Tout peut se passer très rapidement.
Comme pour une mission en tant que prestataire vous allez passer un entretien et ensuite avoir un retour souvent dans la semaine pour commencer la semaine suivante.

Ce qui signifie que le commencement d'une mission peut aller très vite, il n'est donc pas nécessaire de chercher la mission trop longtemps en avance, car il y a peu de clients prêts à accepter d'attendre deux mois. Par contre, il faut quand même activer son réseau en avance de phase pour préparer le terrain.

Autre que le réseau, il existe des sites comme Freelance info ou HopWork qui permettent de trouver des missions en direct et aussi de se donner une idée des TJM.

La mission

Ici être indépendant diffère très peu que d'être prestataire de SSII. 

Peut être excepté quelques points:

• Parfois vous vous ferez charrier par vos collègues quand ils vous verront garder la note du repas. 
• Votre travail est le reflet de votre activité, tout problème peut nuire à la réputation de votre entreprise
• Vous travaillez pour vous ce qui est plus motivant. Sur ce sujet vous pouvez lire ce billet: Siffler en travaillant

Le premier paiement

Alors voilà, vous avez suivi toutes les étapes, émis votre première facture 2 mois plus tôt et vous recevez le premier virement sur votre compte professionnel. La totalité a de quoi vous faire tourner la tête comparé aux virements d'un salarié. 

Je me souviens encore du jour où j'ai vu des sommes d'argent à 4 zéros arriver sur mon compte pro, je n'étais pas habitué à ça. D'ailleurs le banquier non plus, qui si vous vous en souvenez m'avait refusé le crédit. D'un coup il était beaucoup plus enclin à m'offrir des crédits pour ma société, me faire de la publicité pour tous les services aux pros et m'appeler pour savoir si tout allait bien ! D'ailleurs ça doit vous rappelez une publicité (ridicule) avec Gad Elmaleh, oui oui c'est bien cette banque là ! 

  

Mais ne vous emballez pas trop vite ! Ce que vous n'aviez peut être pas vu, c'est Mr Etat, Mr Urssaf, Mr TVA et Mr RSI qui se sont cachés là au fond dans la cour derrière l'arbre !  

Je ne vais pas lancer un débat sur la fiscalité mais juste vous conseiller de garder de l'argent sur votre compte pro car ces messieurs ne sont pas très patients en ce qui concerne les paiements même quand ils envoient la lettre après la date butoir dans le courrier.

Et surtout de fonctionner en mode JMS avec les factures, vous recevez, vous traitez !

Il va donc falloir s'habituer à voir les 4 zéros se transformer en 3 zéros.

Un vent d'indépendance - deuxième partie

Prendre un bon départ

Ok j'ai décidé de devenir indépendant, mais par où commencer ? Je vais vous le dire tout de suite, le début est certainement le moment qui m'a semblé le plus difficile. Certainement le fait de ne pas savoir quoi faire, faire quelque chose de nouveau...

A ce moment là, j'ai eu beaucoup de chance d'avoir dans mon entourage des gens qui avaient déjà fait le pas. Si vous n'êtes pas entourés, ce n'est pas impossible, mais c'est plus compliqué et certainement plus anxiogène. Croyez moi ce n'est pas du luxe si vous n'avez jamais créé de société. 

De plus, je venais de démissionner et je n'avais pas énormément d'argent de côté, je devais donc créer la société et trouver une mission en parallèle.

Le comptable

Avant de penser à créer votre société, penser à trouver un comptable si vous n'avez aucune expérience dans le domaine. La fiscalité est assez complexe à appréhender, surtout la première année.

Le comptable va aussi vous aider à choisir la structure de votre société et vous aider dans les démarches, soit par des conseils, soit en faisant les démarches à votre place contre rémunération supplémentaire (ce que j'ai fait). Il pourra aussi vous donner des conseils afin d'optimiser votre fiscalité.

Des cabinets de comptable il en existe beaucoup, là aussi je vous recommande de prendre un comptable conseillé par quelqu'un de votre entourage, ca vous évitera quelques mauvaises surprises.

Pour ma part j'ai choisi un cabinet de comptable de type "low cost", qui fait tout par internet, ce qui est assez pratique pour un profil comme le mien qui est habitué à utiliser l'outil informatique. Après il faut savoir qu'avec ce type d'offre que le prix est certe "bas" autour de 100 €/mois mais que tout extra à un coût. Par exemple pour un rendez vous avec le comptable il faudra payer une certaine somme.  

Personnellement l'offre me convient. Maintenant je peux comprendre qu'elle puisse rebuter certains préférant avoir un contact plus direct.

L'ACCRE

Si vous avez bénéficié de la rupture conventionnelle ou d'un licenciement ce qui n'a pas été mon cas, vous pouvez faire la demande de l'accre qui peut vous permettre d'obtenir un versement anticipé de vos indemnités chômages. Ce dispositif est très intéressant car il peut vous permettre entre autre d'avoir d'un seul coup une grosse somme d'argent et vous permettre de commencer l'activité sereinement. Pour tous les détails: http://les-aides.fr/fiche/bpNgC3tGxfTeBGZeTUzZ4$Vm/pole-emploi/versement-en-capital-arce-ou-cumul-de-l-are-pour-reprise-ou-creation-d-entreprise.html

La banque

Vient le moment d'aller à la banque pour créer son compte professionnel et potentiellement demander un petit crédit histoire de compenser l'absence de revenu au début de votre activité. Oui le deuxième point n'est pas à négliger, car même si vous trouvez une mission rapidement, il se peut que le client vous payes jusqu'à deux mois après... Je reviendrai dessus plus tard dans l'article.

Pour créer son compte professionnel, rien de plus simple, on vous demandera votre kbis temporaire (sans numéro de siret), les statuts de votre société et le montant de votre capital. Théoriquement la société peut être créée à partir de 1€ de capital, mais je vous conseille de mettre un peu plus, le capital de la société est public et une société à 1€ ca fait pas très sérieux... D'autant plus que vous ne serez pas obligé de verser la totalité du capital.  

 Pour la demande de crédit les ennuis ont commencé... 

Je me considère comme un bon client de ma banque, pas de découvert, tous mes comptes chez eux, alors lorsque je leur ai demandé 10 000€ pour commencer sereinement ma nouvelle activité je pensais que ca passerait comme une lettre à la poste je me berçais d'illusion.

Première désillusion: On a commencé à me demander un prévisionnel du CA sur 3 ans alors que je venais tout juste de commencer. A savoir que ce document n'a aucune valeur, puisque c'est le responsable de l'entreprise en l'occurence moi et le comptable qui fournissons ce prévisionnel, WTF !

Deuxième désillusion:

La décision du prêt arriva moins d'une semaine après et refusé ! Pourquoi ? Parce que je ne suis pas salarié, l'obtention du crédit était trop risqué ! WTF !!!

Si j'avais été salarié et que je voulais faire un crédit conso pour m'acheter le dernier écran 3D à la mode je l'aurai eu sans problème !!! Mais créer sa société pour être freelance dans un secteur prospère il faut croire que c'est trop "risqué" pour nos amis les banquiers français. 

Donc un conseil assurez vos arrières au mieux pour éviter de vous retrouver dans une situation périlleuse qui a été mon cas.

Aussi il faut savoir qu'il est possible de négocier des avances de facturations notamment si vous passez par un intermédiaire type SSII.

Les fausses obligations

Dans les premiers mois, j'ai reçu beaucoup de courriers, certains officiels kbis, statuts, tva, urssaf, RSI et d'autres moins...

Dans ces derniers vous avez ce que moi j'appelle des escroqueries, ce que l'expéditeur appelle une obligation.

Il y en a un dont je me rappelle très clairement. J'ouvre l'enveloppe, je vois une lettre avec des couleurs bleu, blanc rouge, une facture dans les 700 € et un message sous entendant très fortement que cette somme est obligatoire. Méfiant je vais sur le site internet de la société qui m'a envoyé le courrier, je vois toujours un thème bleu/blanc/rouge et une photo du président de l'époque Nicolas Sarkozy. Donc tout a l'air d'être officiel. Mais dans le doute je demande à mon comptable. 

Il s'avère qu'en lui montrant le courrier ceci n'avait rien d'obligatoire et que ca s'apparentait plus à une arnaque en bande organisée qu'un document officiel. En réalité il s'agissait d'un référencement dans un annuaire privé d'entreprise qui n'a aucune valeur ajoutée dans mon cas...

C'est dans ces moments qu'on se dit qu'un comptable est utile.

Un vent d'indépendance - Première partie

Je sais qu'il y a déjà eu pas mal d'articles d'indépendants mais je tenais à vous partager mon expérience, car chaque indépendant est différent et chacun a son ressenti.

Comme beaucoup de développeurs java, j'ai fait mes armes dans des sociétés de services ou autres toutes leaders dans leur domaine:

1. Leader mondial dans le consulting informatique et fan de tiger woods
2. Leader français de l'open source 
3. Leader sur les annuaires BtoB
4. Leader français de l'intégration d'outil open source (non, non c'est une autre société !)

Si vous retrouver le nom des sociétés je vous paierai une bière. Interdit d'aller voir sur linkedin !!

Du coup un jour en voyant tous ces leaders je me suis dit que c'était mon tour de devenir un leader. A minima le leader mondial de moi même.

L'histoire de Walter

Ca commence par une histoire, celle de Walter qui débute sa carrière dans l'informatique il vient de se faire embaucher dans une société leader dans son domaine, il fait des missions chez des clients qui rémunèrent sa boîte pour le travail qu'il produit et ensuite sa boîte le rémunère à son tour en ayant fait un substentiel bénéfice.


Ok soit, Walter a parfois l'impression de se faire arnaquer mais il sait que c'est pour sa société, sa communauté, son clan, sa team, sa vie quoi.

Parce que sa société est bienveillante envers lui:

• Elle lui trouve des missions qui sont formatrices à la pointe de l'innovation, struts 1, EJB 2, JSP

• Elle lui propose des formations en n'oubliant pas de le faire signer le dédit de formation et surtout de l'envoyer chez un client pour vérifier que il a bien appris sa leçon.

• Elle organise des supers soirées où le pdg lui dit que sa société est la plus innovante qu'elle s'inspire de google, d'apple et d'amazon réunis. A vrai dire il a déjà bu plusieurs verres d'alcool et y croit !
• Elle aimerait bien l'augmenter, mais malheureusement c'est la crise, elle peut quand même faire un effort de 2% parce qu'il travaille bien. Il faut croire pas aussi bien que le nouvel arrivant qui touche 30% de plus que lui.

• Elle lui offre des T-Shirts et des mugs pour qu'il puisse revendiquer son appartenance à la société.
• Elle lui suggère même d'expliquer à son travail, sur son blog, à sa grand mère et son poisson rouge cette magnifique bienveillance.    

Mais un jour Walter se réveille et se demande si l'herbe est plus verte ailleurs, il a entendu parler d'un collègue qui vient de changer de boîte et faire une plus value de 30 % sur son salaire. 

Walter est impressionné qu'il existe des sociétés qui soient capables d'offrir un meilleur salaire que sa bienveillante société.

A vrai dire il commence à se demander si sa société est si bienveillante que ca, beaucoup de collaborateurs sont déjà partis, il se dit qu'il devrait changer.

Quelques temps après il se décide enfin à partir ! Avec un pincement au coeur. Il quitte son cocon. Il remet son costume laisser au placard pendant des années.

Il commence à faire des entretiens avec toutes les SSII avec des noms comportant "solutions" "future" "tech", où on lui pose plus ou moins toujours les mêmes questions: 

C'est quoi la dernière version de java, fait moi un singleton, c'est quoi volatile, c'est quoi synchronized etc. 

Walter répond correctement à la moitié des questions, il demande un salaire 30 % supérieur à celui qu'il avait, la RH n'a pas l'air de trop sourciller elle essaie juste de gratter 3k ou 4k en sortant l'argument de son "package".

Walter est embauché, il commence dans sa nouvelle boîte, on lui file un mug de la société, on lui dit q'il fait parti d'un groupe leader et qu'il y a une mission innovante pour lui en Struts...

Sur un air de Walter ! 

 Cette histoire inspirée de faits réels observés et entendus de ci de là peut paraître exagérée, mais je me plait à penser que tout presta a connu une partie de la vie de Walter. Il ne faut pas non plus ne voir que du négatif, la plupart de ces sociétés permettent aussi de se constituer un réseau et de monter en compétence.

C'est en prenant en compte ces observations et une envie de créer une entreprise que l'idée de l'indépendance a commencé à mûrir. 

De plus dans mon entourage je connaissais d'autre personnes qui avaient fait le pas et ne regrettaient pas de l'avoir fait. 

Contrairement à ce que certains peuvent penser, on devient rarement indépendant sur un coup de tête. 

Faire le premier pas, demande une maturité, une introspection sur soit, connaître ses propres qualités et ses défauts. Car passer indépendant c'est travailler d'abord pour soit même, sa réputation. 

Car jamais vous ne serez plus jugés sur votre travail que lorsque vous serez indépendants.

Il en va de la survie de votre société.

   

Les architectures applicatives client/serveur

Avec l'avènement des applications smartphones ainsi que celles exécutées sur le navigateur, nos applications n'ont jamais autant changé en un laps de temps aussi réduit. Les frontières entre client et serveur sont de plus en plus floues.

Dans ce contexte, je vais tenter de retracer les différentes étapes qui ont amené aux évolutions de nos applications et tenter d'entrevoir ce qu'elles pourraient dans un futur proche.

Etats des lieux

Les clients lourds

Je me souviens au début de ma carrière, ils y avaient des applications dites lourdes qui étaient déployées chez les clients.

Ces applications fonctionnent de cette manière:

Un client dit lourd sur chaque poste utilisateur qui envoie des requêtes en mode connecté sur un serveur centralisé effectuant des traitements de type appel à la bdd, connexion avec le mainframe maison etc.

Ces applications ont l'avantage de fonctionner de la même manière sur chaque client pour peu que la configuration soit identique sur chaque poste. Mais ont l'inconvénient d'avoir une lourdeur dans les déploiements de l'application qui doivent se faire sur chaque poste de chaque employé sans parler des mises à jours qui doivent se faire de la même manière.

Au niveau développement la grande majorité du code métier est géré sur le client.

Suite à la pénibilité de ce fonctionnement, de nouvelles approches de déploiement à partir du serveur apparurent.

Les clients lourds via déploiement à partir du serveur

Ici le client lourd est déployé via une interface web sur chaque poste client.

Il suffit à l'utilisateur d'aller sur une page web afin que le serveur déploie via une applet/un activeX l'application sur le poste de l'utilisateur.

Le déploiement est alors moins pénible au sein de l'entreprise.

  

Mais voilà, en parallèle les technologies web ont évolué, il est alors possible d'obtenir une application avec des fonctionnalités similaires à nos chers clients lourds. Ceci a favorisé l'abandon des applications lourdes au profit de clients légers.

Les clients légers

Un client dit léger est en fait un navigateur web capable d'interpréter des descriptions html servies par un serveur web.

La différence entre le client lourd et le client léger se situe dans le fait que le client léger a une attitude passive, c'est à dire qu'il ne s'occupe que du rendu de ce qui lui est décrit via le html envoyé par le serveur.

Bien que cette approche supprime les contraintes liées au déploiement des clients sur les postes utilisateurs, elle a aussi ses inconvénients:

• La réactivité du client léger est de très loin derrière la réactivité d'un client lourd notamment du au manque d'un langage dynamique côté client. L'utilisateur doit effectuer une nouvelle requête pour avoir accès à une nouvelle information du serveur et attendre le rafraîchissement de la page.
• La compatibilité entre chaque navigateur n'est pas toujours assurée, il se peut que le rendu diffère selon le navigateur
• Le rendu ne permet pas d'avoir un contenu riche, c'est à dire des interfaces graphiques semblables à celles des clients lourds qui intègre une multitude de composants.

Les clients légers avec JS

Pour pallier au manque de réactivité, les éditeurs ont inclus le langage javascript créé par netscape (RIP) dans leurs navigateurs respectifs. Ce langage a la particularité d'être simple à implémenter comparé aux langages que l'on rencontre sur nos clients lourds tels que C/C++ ou JAVA. Ceci a permis d'avoir des interactions dynamiques plus facilement au sein du navigateur.

La compatibilité a aussi été améliorée au fil du temps notamment par l'établissement d'un consortium W3C dédié aux fonctionnalités des navigateurs regroupant la plupart des éditeurs des navigateurs.

En ce qui concerne la richesse du client il a fallu attendre l'arrivée de la vague des clients riches et du HTML 5.

 Les clients riches (Flex (RIP), Silverlight, JavaFX (RIP))

Comme le javascript, le client riche s'éxécute au sein du navigateur web, mais à une différence prête que le rendu n'est pas effectué par le navigateur mais par un éxécutable préalablement installé sur le poste client.  Les clients riches ont la particularité de proposer des composants grahiques qui n'ont rien à envier à nos vieux clients lourds. Ces clients se reposent sur des langages relativement simples.

L'inconvénient est qu'il faille préalablement installer un plugin sur le navigateur (le fameux éxécutable) ce qui ne satisfait pas toutes les sociétés et aussi le fait que l'accessibilité soit difficilement prise en compte par ces clients.

HTML 5 et AJAX

En parallèle des clients riches, arrivèrent le HTML 5 qui améliore grandement les capacités du navigateur avec la possibilité par exemple de fournir du multimédia, stocker des données en base de données sur le navigateur et d'obtenir des connexions persistantes via WebSocket avec le serveur. Ces connexions persistantes permettent de pallier à la problématique de connexions successives faites par les navigateurs, comme le faisait déjà nos clients lourds.

De plus, la présence d'api AJAX simplifiées permet de créer des fortes interactions avec le serveur et ce de manière dynamique réduisant la contrainte d'effectuer des rafraîchissements du navigateur  ainsi que l''intégration du code de communication avec le serveur qui est pré-mâché par les API  javascript telles que JQuery, Prototype, Scriptaculous...

Il est alors possible d'avoir des rendus similaires aux clients riches, sans toutefois devoir installer un plugin sur les postes client.

Ceci a bien évidemment contribué au déclin des clients riches.

Les tendances actuelles

RestFul

L'approche RestFull sans rentrer dans le détail, permet d'associer une ressource à une uri. C'est à dire celà se traduit souvent par créer une url par ressource. Le grand intérêt est d'avoir une approche stateless (sans état) qui améliore la scalabilité des serveurs et délègue les états applicatifs sur le client.

Le tout JS

Avec l'arrivée de nouveaux frameworks JavaScript orientés Single Page Application (applications dans la même page) facilitant le développement de la navigation côté client, il est possible de créer une grosse partie de la logique de navigation en JS, le serveur n'a alors qu'un rôle de mise à disposition des données dans un format simple pour le Javascript (souvent en JSON) via une approche RestFul. 

Les applications mobiles

Les applications mobiles sont à leur manière des clients riches puisqu'ils reprennent point par point ce qui a fait leur succès. 

Ces applications tournent sur des terminaux de plus en plus puissant, ce qui présage un enrichissement continue des fonctionnalités présentes dans nos applications.

En voyant toutes ces évolutions on peut se demander quelles seront les architectures de demain.

Et si demain ...

Des applications conçues pour des périphériques hétérogènes

A l'instar du smartphone qui a révolutionné l'usage de nos applications, on peut se dire que d'autres périphériques connectés vont voir le jour. Cette tendance commence déjà avec par exemple les lunettes ou bien les montres connectées.

Ces nouveaux périphériques posent plusieurs questions dans le cadre du développement de nos applications:

Pourra t'on toujours développer des applications très riches sur des périphériques exotiques et limités ?

Comment les applications des différents périphériques vont elle dialoguer ?

Où seront stocker les données ? Dans le Cloud ? Sur les périphériques ?

On peut imaginer trois types d'approche:

• Tous ces nouveaux périphériques seront connectés au web et les données seront présentes chez les géants du web (google, microsoft, amazon etc.)

Les lunettes, le téléphone portable et la montre connectés à internet avec les données dans le cloud

• Les périphériques seront interconnectés, les données dispersées, avec certains périphériques connectés au web.

Les lunettes se connectent au téléphone et la montre aux lunettes etc. Avec certains se connectant à internet.

• Un seul périphérique connecté au web faisant office de serveur centralisé responsable du traitement des données.

Les lunettes et la montre se connectent sur le téléphone qui lui se charge de traiter la donnée, soit en local, soit dans le cloud.

Ceci impactera inévitablement notre vision de ce qu'est un client et un serveur.

Retour vers des clients lourds pour le web

Ne sautez pas de votre chaise en voyant le titre du paragraphe, il est intentionnellement provocateur.

Néanmoins nos clients légers/riches ont de plus en plus de points communs avec nos clients lourds:

• Une connexion persistante (WebSocket)
• Appel à une base de donnée
• Affichage de toute l'application dans une seule page web (single page application)
• Contenu multimedia

La grande différence se situe essentiellement sur la responsabilité du code métier qui est aujourd'hui principalement effectuée côté serveur, mais avec la simplification de l'utilisation du JS, il pourrait être tentant d'utiliser ce langage pour faire du traitement métier.

Si ce cap est franchi alors nos clients légers redeviendront des clients lourds.

L'avenir nous dira si l'informatique peut être comparée à l'Histoire où nous assistons à des cycles perpétuels.

Un merci à Patrice Chalcol et Patrick Guillerm d'avoir participé à la relecture de l'article.

Recettes de chiffrages de projet informatique

 Le chiffrage d'un projet en informatique se révèle souvent être une tâche ardue que ce soit dans la définition des besoins ou dans l'évaluation du temps de réalisation. Ceci a pour conséquence que le chiffrage se base souvent sur des paramètres assez subjectifs.

Dans cette idée, je me suis amusé à imaginer quelques techniques permettant de faire du chiffrage. Toutes ressemblances a des faits réels n'est que pure coïncidence ;).

Le compteligne

Cette technique prend en compte le nombre de ligne et la structure du document fournis par le client.

Etapes:

1. Découper le projet à chiffrer en tâches très macros. Le découpage revient souvent à reprendre les paragraphes de l'expression de besoin du client c.a.d 1 tâche égale 1 paragraphe ou 1 chapitre.
2. Prendre le nombre de ligne de chaque tâche et le multiplier par un autre coeff en fonction de ce que vous avez compris de la tâche à réaliser. Plus la tâche vous parait incompréhensible, plus le coeff doit augmenter.  
3. Ainsi vous obtenez un certain nombre de jours/homme. 
4. Adapter le chiffrage en fonction des remords suscités par ce dernier.

Exemple: Une expression de besoin faisant 3 chapitres

1er chapitre: 3 lignes
 Compréhension du chapitre: je n'ai rien compris => 3
2e chapitre: 5 lignes
Compréhension du chapitre: ca me paraît clair => 2
3e chapitre: 10 lignes
Compréhension du chapitre: J'ai tout compris =>1

Nombre de jour/homme = 3 x 3 + 5 x 2 + 10 x 1 = 29 jrs/homme
Nombre de jour/homme après remords = 24 jrs/homme

 Le comptemot (compteligne police proof)

Cette technique est une variante du compteligne mais a l'avantage de ne pas être sensible à la police. En effet le nombre de mot est pris en compte à la place du nombre de ligne.

Le mathétique

Cette technique est réservée aux psychopathes des mathématiques et aux fanas de préjugés.

Etapes:

1. Découper méticuleusement chaque besoin afin d'en faire des tâches très micros de l'ordre d'1j/h.
2. Avoir au préalable calculé la productivité de chacun de ses devs après une longue observation, en déduire des données en fonction de préjugés: Temps effectif devant le poste, temps passé à surfer sur le net, âge des développeurs, nombre de dev en couple, nombre de femmes etc. 
3. Prendre le résultat de ces calculs et le corréler aux tâches à réaliser.
4. Savourer le chiffrage obtenu avec un rire sadique.

Exemple:
Découpage du projet en 1101 micro-tâches d'1j/h. Dans l'équipe, il y a trois devs, deux hommes et 1 femme.
Un homme est marié, ce qui fait de lui un dev avec des obligations => 75 % de dev,
L'autre est célibataire à tendance nolife et à l'avantage d'être barbu => 120 % de dev,
La femme a un beau physique => 50% de dev car pour ce type de chifffreur, elle n'est qu'un demi développeur.

Résultat: 1101 * 125 / 100 * 80/100 * 150/100 = 1651.5 j/h
Résultat en prenant en compte les jours de maladies potentiels: 1651.5 * 110 % = 1816.65 j/h

Le coffreur

Cette technique est réservé aux chiffreurs codeurs et très simple à réaliser. A adapter selon le langage préféré du geek.

Etapes:

1. Découpage des tâches aléatoire.
2. En fonction de la compléxité ressentie, choisir un nombre de jour max.
3. Coder un algo du genre  Math.random() * nombre de j/h max.
4. Obtenez votre résultat.

Le lancé de dés

Cette technique est équivalente au coffreur mais à l'avantage d'être utilisable par n'importe qui sachant lancer des dés.

Etapes:

1. Découpage des tâches aléatoire.
2. En fonction de la compléxité ressentie, changer le nombre de dés.
3. Lancer les dés.
4. Obtenez votre résultat.

Le souk ou marchandage de tapis

Cette technique consiste à ne pas prendre en considération le besoin, mais uniquement à marchander avec le client.

Etapes:

1. Tenter de connaître la fourchette attendue par le client
2. Si la fourchette est connue, alors rendre un chiffre aléatoire contenu dans la fourchette.
3. Si la fourchette n'est pas connue, alors présenter plusieurs chiffrages successivement au client en prenant soin de temporiser avant chaque présentation. Si le client dit "c'est trop cher" alors rendre un chiffrage inférieur . Si le client dit "vous avez surement oublié quelque chose" alors gonfler le chiffrage. Réitérer jusqu'à ce que le client dise "Ok".
4. Le chiffrage est prêt.

Si vous avez d'autres idées, n'hésitez pas à m'en faire part.

camel create routes dynamically

Apache camel, create routes dynamically

Create camel routes dynamically

In this entry we'll create a camel route dynamically.
The route uses the camel-mail component that permits to connect to pop/imap/smtp mailboxs.

Dependencies

We use the version 2.9.0 of camel.
maven

  <dependency>
   <groupId>org.apache.camel</groupId>
   <artifactId>camel-core</artifactId>
   <version>2.9.0</version>
  </dependency>
  <dependency>
   <groupId>org.apache.camel</groupId>
   <artifactId>camel-mail</artifactId>
   <version>2.9.0</version>
  </dependency>

ivy

 <dependency org="org.apache.camel" name="camel-core" rev="2.9.0"/>
 <dependency org="org.apache.camel" name="camel-mail" rev="2.9.0"/>

RouteBuilder

In order to create a new Route it is necessary to create a class that extends RouteBuilder.
After you have to implement the method configure() that permits to configure your route.
Example for an imap email route

 public class MailRouteBuilder extends RouteBuilder {
 
  private String login;
  private String password;
  private String host;

  public MailRouteBuilder(String login,String password,String host){
   this.login=login;
   this.password=password;
   this.host=host;
  }


  @Override
  public void configure() throws Exception {
   fromUri=String.format("imap://%s?username=%s&password=%s",host,login,password);
   from(fromUri).to("mock:myMock");
  }
 }

If you use a processor, don't forget to assign an id to the bean inside the camel spring context ex:

 from(fromUri).processRef("imapProcessor").to("mock:myMock");

 
 <bean id="imapProcessor" class="myPackage.MyProcessor" />

Ok, now we have a builder for the new route in a very easy way.
Now it is necessary to create a new spring bean that implements CamelContextAware. If you use spring and annotation you can configure in a very easy way with the @Service annotation:

 @Service
 public class CamelRouteManager implements CamelContextAware { ...
  

If you don't use the annotation, so you have to edit the camel spring context:

 <bean id="camelRouteManager" class="myPackage.CamelRouteManager" />

The implementation of CamelContextAware need to implement the getter/setter for the camel context. It means you have to provide a camelContext field.

 protected CamelContext camelContext;

 public CamelContext getCamelContext() {
  return camelContext;
 }

 public void setCamelContext(CamelContext camelContext) {
  this.camelContext = camelContext;

 }

Now we can create a method named addMailRoute that creates a new imap route:

 public void addMailRoute(String login,String password,String host){
  MailRouteBuilder mailRouteBuilder=new MailRouteBuilder(login,password,host);
  this.camelContext.addRoutes(mailRouteBuilder); 
 }

If all is ok the route should start automatically.
Ok, but if I want to remove, stop or suspend a route, how can I do ?
Very easy, you have just to use:

camelContext.removeRoute(String routeId)

camelContext.stopRoute(String routeId)

camelContext.suspendRoute(String routeId)

Take care, for remove a route it is necessary to stop it before.
Ok, how can I retrieve the id of the route created dynamically ?
Just have to retrieve the routeDefinition object, go back in the MailRouteBuilder class:

 private RouteDefinition routeDefinition;

 
 @Override
 public void configure() throws Exception {
  fromUri=String.format("imap://%s?username=%s&password=%s",host,login,password);
  routeDefinition=from(fromUri).to("mock:myMock");
 }

 public RouteDefinition getRouteDefinition() {
  return routeDefinition;
 }

 

Now retrieve the routeDefinition object and extract the id in the CamelRouteManager class:

 public String addMailRoute(String login,String password,String host){
  MailRouteBuilder mailRouteBuilder=new MailRouteBuilder(login,password,host);
  this.camelContext.addRoutes(mailRouteBuilder);
  return mailRouteBuilder.getRouteDefinition().getId(); 
 }

It is also possible to create several routes in one shot. You can adapt the code to have a list of routeDefinition instead of a simple String
Now all is done, you can enjoy all your created routes.

apache camel official site