Il y a une semaine, j'ai participé à la conférence de Paris JUG sur NoSQL.
Voici les liens à mes articles chez JDuchess avec le retours de la soirée :
Introduction NoSQL - Olivier Mallassi et Michaël Figuière
Introduction NoSQL
Retour d'expérience de Steven Noels :
CMS on top of NoSQL
Merci pour cette soirée !!!
Merci Claude Falguière pour tes relectures, conseils sur le contenu et sur la mise en forme.
Affichage des articles dont le libellé est Paris JUG. Afficher tous les articles
Affichage des articles dont le libellé est Paris JUG. Afficher tous les articles
mercredi 22 septembre 2010
mardi 13 juillet 2010
Adam Bien - Lightweight Killer Applications
Il y a une semaine, j'ai participé à la conférence de Paris JUG avec Adam Bien et les LigthWeight Killer Applications avec JEE6. Adam Bien a été simplement superbe !
Voici les liens à mes articles chez JDuchess avec le retours de la soirée :
Les architectures opposées "Piloté par le domaine" et "piloté par le service".
Architecture JEE 6 Théorie : Les deux approches
La présentation pratique JEE 6 et les EJBs 3.x :
EJB 3.x et Adam Bien in action
Merci Adam pour tout !!!
Merci Etienne Seiter et Claude Falguière pour vos relectures, conseils sur le contenu et sur la mise en forme.
Voici les liens à mes articles chez JDuchess avec le retours de la soirée :
Les architectures opposées "Piloté par le domaine" et "piloté par le service".
Architecture JEE 6 Théorie : Les deux approches
La présentation pratique JEE 6 et les EJBs 3.x :
EJB 3.x et Adam Bien in action
Merci Adam pour tout !!!
Merci Etienne Seiter et Claude Falguière pour vos relectures, conseils sur le contenu et sur la mise en forme.
mercredi 30 juin 2010
Article pre Paris JUG - Soirée Adam Bien
Je viens de publier mon premier article dans le blog JDuchess.
J'ai fait un pré compte rendu qui introduit le speaker Adam Bien ainsi que les sujets qui seront présentés en détail lors de la conférence du dernier JUG avant la rentrée.
Adam nous promet d'illustrer sa présentation par des exemples pratiques.
Voici le lien :
Merci Claude Falguière, Laurent Guérin et Julien Maupoux pour vos relectures, corrections et conseils sur la mise en forme.
J'ai fait un pré compte rendu qui introduit le speaker Adam Bien ainsi que les sujets qui seront présentés en détail lors de la conférence du dernier JUG avant la rentrée.
Adam nous promet d'illustrer sa présentation par des exemples pratiques.
Voici le lien :
Merci Claude Falguière, Laurent Guérin et Julien Maupoux pour vos relectures, corrections et conseils sur la mise en forme.
mardi 18 mai 2010
Maven 3
Maven 3 est encore dans sa version bêta, mais il promet ! Au Paris JUG, Arnaud Heritier et Nicolas De Loof nous l'ont présenté. Voici mes retours !
Migrons à Maven 3 !
Est-il facile à migrer ?
Il suffit de changer votre version de maven ! Et voilà, c'est fini !
Est-il compatible avec les versions précédentes ?
Oui, la compatibilité est assurée à un 99,99%
Les exceptions qu'on peut trouver sont par rapport aux descripteurs de projet qui sont encore beaucoup plus stricts que dans ses versions précédentes, ainsi que le Maven Site ou la commande eclipse:eclipse qui sont en phase de correction.
Les développements de cette version ont été focalisés pour assurer la compatibilité descendante, affirmation avalisée par les efforts en développement des tests unitaires.
Cette nouvelle version est en effet une refonte complète. Elle se caractérise par les retours d'expérience et l'apprentissage que ses concepteurs et développeurs ont obtenu à partir des versions 1 et 2.
La version 1 de Maven était inmaintenable ; la version 2 était plus maintenable et incluait le support de plugins. L'architecture était améliorée, mais encore pas très extensible et elle manquait de souplesse rendant très compliqué (parfois quasiment impossible) d'entrer dans le code.
Nouveautés :
> Java 5
Et tous les avantages qui vont avec, les generics par exemple. Le code source est plus propre, et la documentation a été nettement améliorée, essentiellement pour bien distinguer les API publics des internes. Grâce à tout cela, le développement des nouveax plugins et fonctionnalités est rendu plus accessible.
> Plugins interactifs
Les plugins restent toujours indépendants, mais ils sont capables de s'adapter au contexte d'exécution, ce qui est traduit par la disparition du plugin Aggregator et la naissance de "Build Plan". On pourra, par exemple, lister les tests à exécuter à l'avance. Cela évitera de les passer plusieurs fois, contrairement à aujourd'hui où les plugins ne savent pas quels sont les tests qui ont été déjà joués.
> Rencontre OSGi
L'outil Tycho est une sorte de portage de Maven 2 pour les applications basées sur OSGi. Eclipse est basé sur un modèle OSGi. Maven 3 inclut Tycho, ce qui permet leur meilleure intégration. Le plugin M2Eclipse s'appuie sur Tycho.
> L'intégration avec eclipse
Maven 2 permettait seulement de réaliser des builds complets. Maven 3 permettra de laisser à eclipse l'ensemble des étapes qu'il sait faire, la compilation par exemple, et de réaliser en maven ce qui reste. Le plugin d'eclipse retirera les tâches du "build plan" évitant ainsi tout conflit.
> Pom Polyglotte
Maven 3 permettra d'écrire le fichier pom.xml en Groovy ou Python par exemple, en plus de XML.
Prochainement :
Ce n'est pas pour les nouvelles fonctionnalités que cette version apporte - on constate que n'il y en a pas trop encore - mais plutôt pour les raisons suivantes :
Apache Maven de Pearson, écrit par les deux speakers !
http://www.pearson.fr/livre/?GCOI=27440100730370
Lancez-vous, migrez !
Migrons à Maven 3 !
Est-il facile à migrer ?
Il suffit de changer votre version de maven ! Et voilà, c'est fini !
Est-il compatible avec les versions précédentes ?
Oui, la compatibilité est assurée à un 99,99%
Les exceptions qu'on peut trouver sont par rapport aux descripteurs de projet qui sont encore beaucoup plus stricts que dans ses versions précédentes, ainsi que le Maven Site ou la commande eclipse:eclipse qui sont en phase de correction.
Les développements de cette version ont été focalisés pour assurer la compatibilité descendante, affirmation avalisée par les efforts en développement des tests unitaires.
Cette nouvelle version est en effet une refonte complète. Elle se caractérise par les retours d'expérience et l'apprentissage que ses concepteurs et développeurs ont obtenu à partir des versions 1 et 2.
La version 1 de Maven était inmaintenable ; la version 2 était plus maintenable et incluait le support de plugins. L'architecture était améliorée, mais encore pas très extensible et elle manquait de souplesse rendant très compliqué (parfois quasiment impossible) d'entrer dans le code.
Nouveautés :
> Java 5
Et tous les avantages qui vont avec, les generics par exemple. Le code source est plus propre, et la documentation a été nettement améliorée, essentiellement pour bien distinguer les API publics des internes. Grâce à tout cela, le développement des nouveax plugins et fonctionnalités est rendu plus accessible.
> Plugins interactifs
Les plugins restent toujours indépendants, mais ils sont capables de s'adapter au contexte d'exécution, ce qui est traduit par la disparition du plugin Aggregator et la naissance de "Build Plan". On pourra, par exemple, lister les tests à exécuter à l'avance. Cela évitera de les passer plusieurs fois, contrairement à aujourd'hui où les plugins ne savent pas quels sont les tests qui ont été déjà joués.
En conséquence, le plugin Aggregator ne devra plus jamais être utilisé.
> Rencontre OSGi
L'outil Tycho est une sorte de portage de Maven 2 pour les applications basées sur OSGi. Eclipse est basé sur un modèle OSGi. Maven 3 inclut Tycho, ce qui permet leur meilleure intégration. Le plugin M2Eclipse s'appuie sur Tycho.
> L'intégration avec eclipse
Maven 2 permettait seulement de réaliser des builds complets. Maven 3 permettra de laisser à eclipse l'ensemble des étapes qu'il sait faire, la compilation par exemple, et de réaliser en maven ce qui reste. Le plugin d'eclipse retirera les tâches du "build plan" évitant ainsi tout conflit.
> Pom Polyglotte
Maven 3 permettra d'écrire le fichier pom.xml en Groovy ou Python par exemple, en plus de XML.
Prochainement :
- L'équipe maven vise à remplacer le conteneur Plexus par Google Guice ou Spring. Rien n'a encore été décidé.
- Éliminer la maintenance du nom de version sur le POM
- Mixins : Permettront de faire un héritage multiple mais pas forcement hiérarchique
- Évolution de la syntaxe : permettra, par exemple, de définir des exclusions globales et pas seulement au niveau de chaque dépendance
- Parallélisation des builds : permettra aux grosses applications multimodule de paralléliser les builds de ses modules indépendants en gagnant du temps de manière significative.
- Maven Shell
Ce n'est pas pour les nouvelles fonctionnalités que cette version apporte - on constate que n'il y en a pas trop encore - mais plutôt pour les raisons suivantes :
- Maven 3 est plus performant
- Les logs, en cas d'erreur, sont plus lisibles
- Le reporting est amélioré
- La communauté est mature et expérimentée. Nous comptons sur un grand nombre de développeurs et utilisateurs senior. De plus, la version 3 a attiré l'attention des nouveaux développeurs, ce qui a fait revivre le projet.
Apache Maven de Pearson, écrit par les deux speakers !
http://www.pearson.fr/livre/?GCOI=27440100730370
Lancez-vous, migrez !
mercredi 12 mai 2010
Mon premier Paris JUG
Hier soir je suis allée pour la première fois à la réunion mensuelle de Paris JUG. Je suis allée avec le groupe JDuchess. Ceci a été une expérience géniale. Jusqu'à hier, je connaissais les duchesses par la toile, et enfin j'ai pu les rencontrer et leur donner un visage (au moins à la dizaine de participantes)
Voici mes retours de la soirée
DVCS par Sebastien Douche
Git par David Gageot
Conférences très bien animées, avec beaucoup d'humour et très intéressantes. DCVS, Distributed Control Version System, est la version distribuée des systèmes comme CVS et SVN.
Sebastien et David, avec leurs nombreuses années d'expérience, ont constaté que :
- Chaque développeur a "sa façon de faire" : petits commits fréquents, gros commit à la fin, commiter toujours à la fin de la journée etc.
- Face à un développement assez important :
La solution :
Oublier l'utilisation des gestionnaires de versions comme CVS ou SVN et utiliser DVCS, notamment Git.
Principes : le workflow et l'orientation au contenu.
Workflow: Un développeur est confronté à plusieurs workflows.
Contrairement au CVS ou SVN (outils VCS) qui sont orientés au ChangeSet, les noms des fichiers sont dissociés aux contenus.
Chaque acteur compte avec son repository en local et peut s'organiser comme il veut. On fait tous les commits qu'on souhaite.
Une fois la fonctionnalité est finie, on "push" l'ensemble fonctionnel sur le repository central.
Ainsi :
- Nous nous focalisons sur notre code
- Nous avons tout l'historique en local
- La résolution de conflits est plus intelligent
- Nous pouvons travailler en mode déconnecté
- Il nous permet d'automatiser l'intégration continue en local et de pusher automatiquement au dépôt central si le build est stable.
- Il est capable de détecter les renommages des fichiers rendant faciles et rapides les refactoring du code.
- Non seulement toutes les utilités de SVN sont disponibles mais plus encore ; par exemple, "git bisect" nous aide à savoir quel commit a cassé notre build en l'absence d'erreur de la part du serveur d'intégration continue.
- Vitesse, souplesse et cherry picking entre autres caractéristiques.
Plus de .svn et .cvs partout ! Plus de regrets lors de la copie d'un répertoire !
Et pour commencer en douceur et convaincre le client ?
Binding ! On peut garder notre serveur SVN et travailler avec Git :o)
La meilleure façon de commencer est la pratique : GitHub !
J'ai déjà utilisé GitHub pour "Tapestwitter" http://github.com/lguerin/tapestwitter et je suis encore plus convaincue qu'hier matin !
Plus d'information sur le site : GIT - Fast Version Control System
ParisJUG : Paris JUG
Voici mes retours de la soirée
DVCS par Sebastien Douche
Git par David Gageot
Conférences très bien animées, avec beaucoup d'humour et très intéressantes. DCVS, Distributed Control Version System, est la version distribuée des systèmes comme CVS et SVN.
Sebastien et David, avec leurs nombreuses années d'expérience, ont constaté que :
- Chaque développeur a "sa façon de faire" : petits commits fréquents, gros commit à la fin, commiter toujours à la fin de la journée etc.
- Face à un développement assez important :
- Le développeur passe beaucoup de temps à "merger" les changements pour pourvoir après commiter
- Beaucoup de micro-merges sont effectués pendant la journée car la quantité de fichiers à merger est proportionnelle au temps passé sans commiter.
- Le développeur se dépêche de commiter principalement pour laisser la fastidieuse tâche de merger à son voisin.
- Commits fréquents, non testés, non finis, non validés
- Trop de temps perdu
- Un projet moins stable
- L'impossibilité de montrer le produit au client au fil de l'eau
- Un impact négatif sur la gestion du projet
La solution :
Oublier l'utilisation des gestionnaires de versions comme CVS ou SVN et utiliser DVCS, notamment Git.
Principes : le workflow et l'orientation au contenu.
Workflow: Un développeur est confronté à plusieurs workflows.
- workflow organisationnel : Il s'agit de la organisation qu'il faut mettre en place pour le développement d'un produit.
- workflow personnel : Il s'agit de la façon de travailler de chaque développeur
- workflow inter-personnel : Il s'agit de la façon dont chaque développeur travaille avec l'équipe autour de lui
Contrairement au CVS ou SVN (outils VCS) qui sont orientés au ChangeSet, les noms des fichiers sont dissociés aux contenus.
Chaque acteur compte avec son repository en local et peut s'organiser comme il veut. On fait tous les commits qu'on souhaite.
Une fois la fonctionnalité est finie, on "push" l'ensemble fonctionnel sur le repository central.
Ainsi :
- Nous nous focalisons sur notre code
- Nous avons tout l'historique en local
- La résolution de conflits est plus intelligent
- Nous pouvons travailler en mode déconnecté
- Il nous permet d'automatiser l'intégration continue en local et de pusher automatiquement au dépôt central si le build est stable.
- Il est capable de détecter les renommages des fichiers rendant faciles et rapides les refactoring du code.
- Non seulement toutes les utilités de SVN sont disponibles mais plus encore ; par exemple, "git bisect" nous aide à savoir quel commit a cassé notre build en l'absence d'erreur de la part du serveur d'intégration continue.
- Vitesse, souplesse et cherry picking entre autres caractéristiques.
Plus de .svn et .cvs partout ! Plus de regrets lors de la copie d'un répertoire !
Et pour commencer en douceur et convaincre le client ?
Binding ! On peut garder notre serveur SVN et travailler avec Git :o)
La meilleure façon de commencer est la pratique : GitHub !
J'ai déjà utilisé GitHub pour "Tapestwitter" http://github.com/lguerin/tapestwitter et je suis encore plus convaincue qu'hier matin !
Plus d'information sur le site : GIT - Fast Version Control System
ParisJUG : Paris JUG
Inscription à :
Articles (Atom)