Article publié par Xebia France le 20 juillet 2009.
Catégorie(s) : Revue de presse
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
RIA
SOA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Article publié par Xebia France le 13 juillet 2009.
Catégorie(s) : Revue de presse
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
RIA
SOA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Article publié par Xebia France le 2 juin 2009.
Catégorie(s) : Revue de presse
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
RIA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Article publié par Erwan Alliaume le 1 juin 2009.
Catégorie(s) : Java / JEE, Mobilité, RIA
Google I/O 2009 s’est tenu la semaine dernière à San Francisco. Il s’agit d’une des conférence destinées aux développeurs utilisateurs des applications et des API de Google. Faute d’avoir eu l’occasion de me rendre sur place, j’ai essayé de suivre d’aussi prêt que possible son déroulement. Vu de l’extérieur : du grand spectacle !
Dans cet article, je vais donc revenir sur les annonces et points marquants de ces deux jours de conférences.
D’autre part, les vidéos des keynotes sont disponibles, vous pouvez consulter celle du premier jour (html5, android, web components …) ou celle du second jour (google wave).
Google I/O 2009, voici ce que j’en ai retenu :
Article publié par Xebia France le 18 mai 2009.
Catégorie(s) : Revue de presse
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Agilité
SOA
Le coin de la technique
Article publié par Xebia France le 6 avril 2009.
Catégorie(s) : Revue de presse
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Agilité
RIA
SOA
Le coin de la technique
Article publié par Xebia France le 1 avril 2009.
Catégorie(s) : Divers
Voici la liste des billets les plus lus sur ce blog en janvier, février et mars :
En matière de sous-traitance du développement logiciel, la pratique contractuelle la plus fréquente est celle dite du projet au forfait. La notion de forfait n’a, en principe, pas de rapport avec le processus de développement ou les pratiques d’ingénierie utilisée dans la réalisation du projet. Il s’agit simplement, dans l’esprit des contractants, de fixer les contours exacts de leur relation commerciale, et de définir leurs obligations mutuelles – en terme de coûts, de délais, de mode de paiement et de livraison. Dans un État de droit, et pour autant qu’elles ne soient pas abusives, ces dispositions contractuelles ont force de loi, et protègent efficacement les parties prenantes.
A bien y regarder cependant la neutralité du forfait vis à vis du processus de développement est moins évidente. Conçu historiquement pour satisfaire aux exigences de mise en concurrence des fournisseurs du Département de la Défense américain, le contrat au forfait est né du même substrat que le processus de développement en cascade – initialement décrit en 1970 par Winston W. Royce dans Managing the developpement of large software systems.
Ce processus de développement est aujourd’hui fortement remis en question, sous le constat empirique de son échec relatif, et sous l’impulsion des méthodes agiles. Je pense quant à moi que la « cascade » sera perçue dans quelques années comme l’aveuglement juvénile d’une industrie encore adolescente, à la recherche de son identité.
La question qui nous intéresse ici est de savoir si le projet au forfait survivra à la cascade. Autrement dit s’il est possible de mener au forfait un projet agile sous-traité. Certains le pensent, et certains intégrateurs proposent au demeurant de tels contrats. J’entends quant à moi démontrer ici que l’agilité et le forfait reposent sur des logiques financières radicalement antinomiques, qui les rendent difficilement conciliables.
Vous avez peut-être assisté au Paris JUG sur GWT et vous vous êtes forcément dit en sortant de la conférence qu’il fallait absolument vous mettre à GWT. En plus, le pas à franchir n’est pas énorme : c’est du Java (ça devrait aller), agrémenté de nombreuses librairies comme dans le monde J2EE, des libraires graphiques qui en jettent sont disponibles… Que d’avantages ! Mais par où commencer ?
Nous allons donc faire un tour d’horizon non exhaustif, mais balayant une grande partie de ce qui est utilisé dans la galaxie GWT : les plugins, les frameworks et les APIs générales et graphiques.
Quartz pour ceux qui ne le connaissent pas encore, est un ordonnanceur. Il permet de planifier des tâches pour des exécutions ponctuelles ou répétées. Les planifications possibles vont de la simple répétition infinie, à la répétition calendaire utilisant la syntaxe de cron (tous les jours à minuit, le 31 janvier 2009 à 12h00, …). Quartz est prévu pour toutes sortes d’applications allant des programmes standalone basiques aux gros systèmes JEE distribués.
De son côté, Spring scheduling nous donne le choix entre les Timers Java et Quartz. Avec ses interfaces, Spring nous permet de planifier, très facilement, des Jobs directement dans l’ApplicationContext. En revanche, la gestion des planifications dynamiques est moins évidente. Dans cet article, je vous présenterai l’API Quartz dans les grandes lignes, puis on mettra en place la planification Quartz avec Spring Scheduling.
Article publié par Xebia France le 9 février 2009.
Catégorie(s) : Revue de presse
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Agilité
RIA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Vous avez peut-être assisté au Paris JUG sur GWT et vous vous êtes forcément dit en sortant de la conférence qu’il fallait absolument vous mettre à GWT. En plus, le pas à franchir n’est pas énorme : c’est du Java (ça devrait aller), agrémenté de nombreuses librairies comme dans le monde J2EE, des libraires graphiques qui en jettent sont disponibles… Que d’avantages ! Mais par où commencer ?
Nous allons donc faire un tour d’horizon non exhaustif, mais balayant une grande partie de ce qui est utilisé dans la galaxie GWT : les plugins, les frameworks et les APIs générales et graphiques.
Article publié par Xebia France le 2 janvier 2009.
Catégorie(s) : Divers
Voici la liste des billets les plus lus sur ce blog en octobre, novembre et décembre :
Après le Xebia Web Framework Contest de l’année dernière, le thème du XKE du mois d’Octobre était un nouveau contest dédié aux RIA.
Le but de cette journée était de développer une application de gestion de playlist de morceaux de musique. En promoteurs des méthodes Agiles, les spécifications furent données sous forme d’un Product Backlog. Trois sprints d’une durée de 90 minutes ont permis à tous de suivre l’évolution des différentes réalisations. Un web service SOAP fournissait les différentes données: Artiste, Album, Titres et Pochettes d’album.
Cinq équipes ont été constituées, cinq frameworks ont donc été choisis :
Au terme de cette journée, chaque équipe a pu exprimer un retour d’expérience significatif.
Développer une application Java, c’est bien. La rendre performante, c’est mieux.
Cependant, qui dit « performance », dit « mesure ». En effet, il est nécessaire de pouvoir :
Cet article va décrire dans une première partie les différents outils permettant de collecter ces informations en local. La seconde partie se concentre sur les moyens pour obtenir ces mêmes informations à distance.
Mardi, 10 heures
- La production « Allo, le projet, depuis 10 minutes on voit passer des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Augmentez la mémoire de la JVM, doublez-la valeur de l’option -Xmx «
Mardi, 13 heures
- La production « Allo, le projet, depuis 5 minutes on voit encore passer des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Augmentez la mémoire de la JVM, doublez encore la valeur de l’option -Xmx «
Mardi 18 heures
- La production « Allo, le projet, depuis 2 minutes on voit passer encore des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Tut, tut, tut,….. »
- La production « Plus d’équipe projet, la nuit va être longue… »
Cette petite scène est un classique, un air de déjà-vu mais que faire ? Si votre application a déjà subi une batterie de tests techniques, augmenter la mémoire est rarement la bonne solution. La scène décrite ci-dessus laisse penser à ce que l’on appelle classiquement une Fuite Mémoire (Memory Leak). En réalité, avec les JVM récentes, la fuite mémoire n’existe pas, je préfère parler d’accumulation d’objets non désirés. Cet article va vous montrer comment débusquer cette accumulation avec les outils jmap, jhat et Eclipse Memory Analyser.
blog.xebia.com xebee.xebia.inPage optimized by WP Minify WordPress Plugin
Complet
Twitter
