Par Marc Bojoly,
mardi 25 novembre 2008 à 00:06 ::Java
Les applications informatiques ont toujours été gourmandes en ressources, les besoins en nouvelles fonctionnalités ou l'accroissement du nombre d'utilisateurs étant une constante des applications réussies. Face à cet état de fait, les constructeurs informatiques ont bâti d'années en années des ordinateurs de plus en plus puissants. Aujourd'hui doit-on attendre l'arrivée de nouveaux ordinateurs pour disposer de meilleurs temps de réponse? Quelles sont les autres alternatives?
Par Marc Bojoly,
vendredi 14 novembre 2008 à 23:31 ::Java
La nouvelle version de Java 7 est en cours de préparation. Malgré le retard et les incertitudes sur le contenu, nous considérons que Java 7 constitue une opportunité intéressante pour le langage. Après un premier article consacré aux nouvelles librairies proposées pour Java 7, ce second article introductif vous propose de découvrir les nouvelles fonctionnalités du langage et de la JVM. Là encore, en cas de doute sur le contenu de la version finale, nous préciserons les réserves concernant une librairie ou une syntaxe en indiquant si l'exemple de code proposé compilait avec la version de prévisualisation 1.7.0-ea-b37.
Par Marc Bojoly,
mercredi 5 novembre 2008 à 01:10 ::Java
La nouvelle version de Java 7 est en cours de préparation. Le passage de la licence propriétaire à un développement open source a introduit un certain retard et beaucoup d’incertitudes concernant son contenu et sa date de release. Cependant, nous considérons que les nouvelles fonctionnalités proposées constituent des opportunités fortes intéressantes pour ce langage, et qu’il est utile de les étudier, indépendamment des doutes qui peuvent encore les entourer. En cas de doute, nous préciserons les réserves concernant une librairie ou l'exemple de code proposé compilait avec la version de prévisualisation 1.7.0-ea-b37.
Pour cela nous allons réaliser une série d’articles, permettant de prendre connaissance de ces fonctionnalités de manière concise. Le premier de cette liste décrira brièvement la majorité des fonctionnalités et renverra la description des fonctionnalités les plus complexes à de prochains articles.
Par Luc Bizeul,
lundi 6 octobre 2008 à 22:09 ::Java
Tout d'abord un grand merci à Grégoire Japiot et Mathieu Coste deux amis Barcamper qui m'ont aidé à monter ce premier BarCamp Java et à lui donner une touche de terroir (enfin une soirée de geek avec de la vraie nourriture :) ), sans oublier les OCTOs qui ont participé pour l'organisation.
La soirée s'est très bien passée, avec une trentaine de personnes en moyenne (la liste est ici ) et de nombreux sujets ont été proposés.
Par Jérôme Van Der Linden,
lundi 6 octobre 2008 à 21:49 ::Java
Après avoir vu comment améliorer notre intégration continue, tant au niveau performance (Part #1) que sur sa bonne utilisation (Part #2), nous allons ici essayer de pousser le bouchon un peu plus loin... jusqu'à la production !
Par Julien Jakubowski,
vendredi 3 octobre 2008 à 17:33 ::Java
Spring-Batch répond à un besoin récurrent : la gestion des programmes batchs écrits en Java. Si le framework semble de plus en plus complet et fonctionnel, celui-ci souffre de sa complexité de configuration et reste un peu difficile d'accès malgré les efforts de l'équipe de développement. Personnellement, j'ai passé quelques heures pour faire fonctionner mon premier batch. Les exemples fournis fonctionnent rapidement, et illustrent très bien les possibilités qu'offre Spring-Batch. Mais, comme ces possibilités sont très riches, les exemples sont nombreux et (nécessairement) complexes. On lit la documentation, on regarde les multiples exemples en détail, et au moment d'implémenter notre premier batch et de plonger pleinement dans le cœur du sujet, on se pose la question "Mais par quel bout je commence ?".
Donc, pour permettre aux gens qui, comme moi, aiment bien créer leur "hello-world" afin de bien comprendre ce qu'ils utilisent, voici un exemple minimal d'un projet Spring-Batch.
Par Jérôme Van Der Linden,
mardi 30 septembre 2008 à 21:39 ::Java
Dans la première partie de ce billet, je mentionnais divers solutions (bonnes pratiques, outils) pour optimiser les performances du serveur d'intégration continue et faire face au nombre croissant de projets gérés par ce serveur.
Dans cette seconde partie, j'aborde un sujet récurrent lorsque l'on fait de l'intégration continue : les erreurs (compilation, tests, packaging) sur le serveur. Effectivement, mieux vaut découvrir ces erreurs en continue sur le serveur plutôt que la veille de la livraison. Mais, ne serait-ce pas mieux si on pouvait simplement les éviter ?
Par Benoit Guillou,
samedi 27 septembre 2008 à 15:28 ::Java
La JSR 311JAX-RS est le pendant REST de la JSR 224 JAX-WS.Elle marque la volonté de la part de la communauté Java de cadrer, tout comme pour la stack WS-*, le développement des applications JAVA orientées ressources. Bien qu’étant sur le point d’être finalisée (elle vient de passer le Final Approval Ballot), elle est déjà implémentée par la plupart des frameworks REST du moment (Jersey, RESTeasy, CXF, une extension existe pour Restlet, …). La suite de ce billet présente les annotations de la JSR en regard des principes REST qu’elles mettent en œuvre.
Par André Nédelcoux,
jeudi 25 septembre 2008 à 17:12 ::Java
Aaaah, cette fabuleuse "feature" de Internet Explorer : lorsqu'on presse F1, la fenêtre d'aide d'IE s'ouvre... sauf que lorsque l'on a besoin d'utiliser F1 comme raccourci dans une application web métier, on constate vite la gestion de F1 est enfouie profondément dans le code IE et qu'il est difficile de reprendre la main sur cet événement. Voici donc le hack en 5 étapes qui permet de récupérer la main sur F1 - comme c'est un classique du développement Javascript, je vous fais la version "implémentation avec GWT" pour changer un peu.
Par Jérôme Van Der Linden,
mercredi 24 septembre 2008 à 22:37 ::Java
Alors que l'intégration continue fait son bonhomme de chemin dans les développements en entreprise, plusieurs constats peuvent être fait.
La généralisation de cette pratique n'est pas égale chez tout le monde :
Chez certains, des usines de développement (plus communément appelées Software Factory) fleurissent par ci par là sous l'impulsion de développeurs chevronnés ou d'expert techniques mais se cantonnent la plupart du temps au développement d'un projet. Résultat : pas d'uniformisation (utilisation d'outils redondants, de méthodologies variées...) mais les équipes sont contentes de leurs usines car elles rendent le service attendu.
Chez d'autres, une seule usine d'entreprise existe (ou est censé exister). Résultat : l'usine croule sous le nombre de projets (configurés plus ou moins anarchiquement), la durée des builds augmente et les équipes finissent par remonter une petite usine dans leur coin pour pallier à la lenteur du serveur.
Au milieu de ça, il y a ceux qui sont dans le premier cas et qui veulent industrialiser. La plupart du temps, ils n'ont pas les moyens nécessaires (support aux équipes, serveur suffisamment puissant) et surtout ils manquent cruellement d'appui des supérieurs et/ou de la production. Résultat : l'usine est peu ou pas utilisée, les projets ne sachant parfois même pas qu'il en existe une centralisée.
Et enfin à l'extrême, il y ceux qui n'en ont pas du tout. Résultat : ils se passent d'une pratique, qui, si elle est mise en œuvre correctement, apporte énormément tant sur la productivité que sur la qualité des applications.
L'industrialisation de cette pratique amène donc les limitations suivantes (pas vraiment nouvelles [1]) :
Le serveur d'intégration ne tient pas la charge lorsque de nombreuses applications y sont construites.
Malgré tous les apports de l'intégration continue, il arrive encore trop régulièrement de casser le build si un développeur peu rigoureux omet de publier un fichier, en ajoute un qui ne compile pas ou qui ne passe pas les tests... bref l'intégration se fait encore trop tardivement !
L'intégration continue ne fait pas partie intégrante du cycle développement / production d'applications, en tout cas pas suffisamment pour être exploité au mieux par toutes les équipes projets.
Ce billet (1er d'une série de 3) traitera des performances des serveurs d'intégration continue.
Par Bernard Notarianni,
jeudi 22 mai 2008 à 11:18 ::Java
Le framework GWT fait couler beaucoup d’encre depuis plusieurs mois. Est-il vraiment si facile à mettre en œuvre ? Est-il pérenne ? Il marche ou pas ? Et puis, tout ce javascript compilé, est-ce que cela ne va pas planter et faire écrouler les performances ?
Les mêmes questions se posent aussipour la dernière technologie proposée par Google : le Google App Engine.
Didier Girard nous propose de tester les deux par nous même en grandeur nature. Il organise un benchmark « in real life » sur les technologies Google. Si comme Didier, vous être convaincu que ca va déchirer, please join the fest !
Inversement, si vous pensez que Google ce n’est que du flan, venez aussi pour participer à faire écrouler le système ;-)
Bonjour à tous,
Spring-Batch répond à un besoin récurrent : la gestion des programmes batchs écrits en Java. Si le framework semble de plus en plus complet et fonctionnel, celui-ci souffre de sa complexité de configuration et reste un peu difficile d'accès malgré les efforts de l'équipe de développement. Personnellement, j'ai passé quelques heures pour faire fonctionner mon premier batch. Les exemples fournis fonctionnent rapidement, et illustrent très bien les possibilités qu'offre Spring-Batch. Mais, comme ces possibilités sont très riches, les exemples sont nombreux et (nécessairement) complexes. On lit la documentation, on regarde les multiples exemples en détail, et au moment d'implémenter notre premier batch et de plonger pleinement dans le cœur du sujet, on se pose la question "Mais par quel bout je commence ?".
