Blog Objet Direct

Nouvelle soirée au Lyon JUG, mardi 23 novembre : Gradle vs Maven 3.

Les JDuchess continuent leur teasing contributif avec des interviews des intervenants, permettant de venir profiter de la soirée plus armés sur les enjeux et perspectives de chacun de ces outils de construction : interview d’Arnaud Héritier sur Maven 3, et interview de Grégory Boissinot sur Gradle.

Inscription et informations pratiques, as usual, sur la page officielle.

Whooosh … ça décoiffe, au sortir de cette conférence j’ai l’impression d’être dans une de ces boules à neige (qui colle bien avec l’image qu’on se fait du Danemark qui plus est ) : on vient de secouer plein de choses et il faut maintenant attendre que les flocons se posent. Dans ma tête… et surtout sur le marché : qui travaille avec Git chez son client ?
En effet la conférence (Java And Object Oriented) qui s’annonçait de développeur à développeur n’a pas (plus autant ?) les pieds sur terre, d’où son changement de nom en gotocon (je n’ai toujours pas compris ce nouveau nom d’ailleurs… faire fuir les développeurs ?), plus particulièrement au vu du contenu du premier jour de conférence où Java était… absent !

Par contre, sur le côté novateur (pour notre réalité bien sûr, pas pour Google, Twitter et cie)  de cette conférence, petite soeur du QCon, est très intéressant. On y retrouve tous les sujets les plus récents que l’on peut suivre sur twitter et la blogosphère. On change ici totalement de monde : on est dans l’univers des leaders de pensée, déconnectés de notre réalité quotidienne. Les sujets majeurs tournent autour des grands du web dont on peut/doit prendre des idées mais qui resteront difficilement vendables à court terme dans notre réalité.
Un point très appréciable néanmoins: malgré cette volonté de ne montrer que des sujets de pointe, on a quasi systématiquement un rappel assez complet de l’historique du sujet.

Pour ma part, le message que je retiendrai de cette conférence (que ce soit pour les sessions que j’ai pu suivre ou non) c’est que ces gens, en avance (où sommes nous en retard ?) sur leur temps se battent contre 2 mastodontes qui a leur sens entravent la productivité :

• Les méthodologies lourdes dont certaines applications de Scrum notamment quand la méthode est mal utilisée voire incomprise (le backlog semble être dans la ligne de mire des prochaines évolutions de l’agilité)

• Java qui n’a pas (réellement) évolué depuis 6 ans et qui peine à évoluer (cf. le plan « B »)

Des retours plus précis suivront ce billet d’introduction … à bientôt !

Après une pause estivale, le Lyon JUG est de retour! Il reprend son rythme habituel, et son moyen quasiment mnémotechnique : chaque troisième mardi du mois, toujours à l’Epitech.

La soirée du 21 septembre sera consacrée aux nouveaux systèmes de gestion de configuration décentralisée : GIT et Mercurial.

Les développeuses seront plus que jamais conviées : on y annoncera la création de l’antenne lyonnaise de JDuchess. Leur activité commence par une interview des intervenants à cette soirée.

Inscription et informations pratiques sur la page officielle.

Vous avez besoin de savoir quel est le CMS le plus utilisé ? vous voulez connaitre l’évolution du marché des serveurs ? vous voulez dénicher les outils qui montent ? vous voulez comparer la popularité de tel ou tel framework ?  Toutes les stats dont vous réviez se trouvent sur le site BuildWith.com.

Ads, Analytics, Blog, CDN (content delivery network), CMS (content management system), DocInfo, Ecommerce, Encoding, Feeds, Framework, Library Javascript, Media, Server, Software, Widgets … tous les outils et solutions liés au Web ou à Internet, propriétaires ou non, sont classés, mesurés et comparés, les uns par rapport aux autres ou en évolution dans le temps.

Bien que très complet, l’App Engine de Google n’intègre pas la gestion des ressources REST. Voici comment la lui ajouter :

1. Télécharger la dernière version de jersey ou l’intégrer à maven ;
2. Ajouter les JAR suivants dans le répertoire /war/WEB-INF/lib :

asm-xxx.jar
jackson-core-asl-xxx.jar
jersey-client-xxx-ea-SNAPSHOT.jar
jersey-core-xxx-ea-SNAPSHOT.jar
jersey-json-xxx-ea-SNAPSHOT.jar
jersey-server-xxx-ea-SNAPSHOT.jar
jettison-xxx.jar
jsr311-api-xxx.jar

3. Modifier le web.xml comme suit :

<servlet>
	<servlet-name>Objet Direct Web Application</servlet-name>
	<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
	<init-param>
		<param-name>com.sun.jersey.config.property.packages</param-name>
		<param-value>com.objetdirect</param-value>
	</init-param>
	<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
	<servlet-name>Jersey Web Application</servlet-name>
	<url-pattern>/resources/*</url-pattern>
</servlet-mapping>

4. Générer l’objet xml réponse (à partir d’un xsd à l’aide de xjc par exemple) :

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<xsd:element name="weather">
		<xsd:complexType>
			<xsd:attribute name="type" type="xsd:string"/>
		</xsd:complexType>
	</xsd:element>
</xsd:schema>

5. Annoter les classes ressources :

package com.objetdirect;

@Path("/weather")
public class ObjetDirectResource {

	@GET
	@Path("/{city: [A-Z][a-z]+}")
	@Produces(MediaType.APPLICATION_XML)
	public Response getCityWeather(@PathParam("city") String cityName) {
		Weather weather = new Weather();
		weather.setType("Very clever on " + cityName);

		ResponseBuilder responseBuilder;
		responseBuilder = Response.status(Status.OK);
		responseBuilder = responseBuilder.type(MediaType.APPLICATION_XML);
		responseBuilder = responseBuilder.entity(weather);
		Response response =  responseBuilder.build();
		return response;
	}
}

6. Démarrer le serveur et accéder à la resource localhost:8888/resources/weather/Paris

Tout d’abord, les différentes annonces qui ont eu lieu durant la soirée hier :

• Alexandre Bertails nous présente rapidement son nouveau job au W3C ainsi que le fonctionnement de l’organisme avec un rapide retour sur ce qu’est le web et l’importance du consortium.

• Developpez.com est un JUG … qui n’envoie pas de représentant, ils font donc profiter de leur place à Jazoon’10 à un volontaire qui a été tiré au sort.

• Une boutade dans la semaine, deux offres d’emplois supplémentaires sur son site d’ « Offres d’emplois pour passionnés », et Nicolas Martignole se voit en « obligation » d’offrir le buffet. Merci à lui !
• L’ISEP prête la salle de 200 personnes gratuitement, Antonio les remercie et demande des volontaires afin de pouvoir leur rendre service en retour en proposant des cours à leurs étudiants.

Entrons dans le vif du sujet ! La première partie de soirée est orientée « Share » avec un retour d’expérience sur le passage d’un CVCS (Gestionnaire de sources centralisé) à un DVCS (Gestionnaire de sources distribué) suivi d’une présentation du DVCS qui monte : Git. La seconde partie de soirée nous fourni une présentation de Maven 3 et de Deploy It.

DVCS

La présentation du sujet a été faite par Sébastien Douche qui nous fait donc ici un retour d’expérience sur un ton décalé et des slides épurées … très agréable.

Arrivé il y a 2 ans dans son entreprise actuelle, il fait le constat de la (classique) sous utilisation de SVN et après analyse du problème, migre vers un DVCS. Son crédo : les tests automatisés et l’outil de versionning sont les 2 filets de sécurité indispensables à un développement logiciel.

Le problème :

Après avoir tenté une évangélisation des bonnes pratiques SVN, il constate tout de même une dégradation régulière de la qualité, impliquant une démotivation (il parle de souffrance) des développeurs allant se poser la question ultime : a-t-on fait le boulot qui nous a été demandé ?

Le problème ne se situe pas au niveau du travail effectué… mais vient plutôt du fait qu’il n’est pas bien partagé ! Notamment avec un phénomène de « micro-merge » : pour exagérer, les développeurs font des commit de chaque ligne de code modifiée pour éviter d’avoir un trop gros merge à faire par la suite ! Ce qui implique une version constamment instable sur le serveur d’intégration et des difficultés à savoir où l’on en est dans le projet.

Une première solution pointe le bout de son nez : si on faisait des branches SVN ? Hum … Attendez, je crois qu’on tente de nous expliquer comment éviter ça :-)

L’impact du DVCS :

En règle générale, les outils de versionning centralisés sont utilisés principalement pour faire du suivi d’historique … et non leur boulot. On souhaite donc : un environnement constamment stable afin de connaitre l’état du projet tout le temps !

Pour cela, on va isoler le travail des développeurs en repensant notre façon de travailler, via une analyse des besoins réels, 3 workflows sont identifiés :

• La méthode de l’organisation (donc la gestion du repository central), avec une façon de faire par organisation. En général, le workflow le plus connu puisque c’est celui qui est visé par SVN et consorts. L’idée ici, c’est que la méthode de l’organisation ne soit pas impactée par les deux workflows suivants. Le but à atteindre serait, par exemple, d’avoir un seul commit par fonctionnalité.
• Puis le workflow inter-personnel, nouveau donc, qui doit être mis en place justement pour éviter d’impacter le repository central : nouveau dépôt de développement, dépôt temporaire, échange de patchs (très utilisé dans le monde de l’open source), branche spécifique, … Il permet aux développeurs de travailler entre eux.
• Et finalement le workflow personnel, ici aussi à bien séparer des deux autres et chacun pourra travailler à sa façon.

L’important, donc, est que ces workflows soient déconnectés les uns des autres.

Une fois la mise en place effectuée, le constat est le suivant : le développeur est concentré sur SON travail et non sur celui du voisin par peur des impacts qu’il pourrait-y avoir sur le sien. Avec cette fois un commit par fonctionnalité sur le repository central, plus de souplesse avec notamment la possibilité de faire de la revue de code et/ou une démonstration pour une et une seule fonctionnalité !

Il est à noter que ces nouveaux outils sont orientés contenu et non changement. Je pense que tout le monde s’accorde pour dire que SVN ne sais pas gérer le renommage de fichiers par exemple ! On voit donc disparaitre les dossiers ‘.svn’ et l’on gagne énormément en place et en vitesse.

En bonus, des repository sont accessibles en ligne. Un outil de binding permet une transition douce en intercalant le DVCS entre le développeur et son SVN.

Conclusion

Je crois que sa conclusion était plutôt claire :

Libérez-vous : utilisez un DVCS

Git, la gestion de configuration qui vous veut du bien

Présentée par David Gageot, très proche et complémentaire de la session précédente. On part sur le même ton puisque qu’il commence par reprendre la conclusion de Sébastien Il insiste notamment sur le fait qu’un outil est fait pour ouvrir des possibilités … et non en fermer !

Git est donc un DVCS, le plus connu avec Mercurial. Pour faire court :

• Pas besoin de serveur !
• Chaque utilisateur a tout l’historique en détail
• Fonctionne en déconnecté

Mais pour l’utiliser à pleine puissance, il faut oublier comment SVN fonctionne !!!

En général, on ne fait pas de merge avec ce type d’outils.

Démo

Il nous fait ensuite une démo rapide d’une fonctionnalité majeure : bisect.

L’idée est de retrouver quel commit a cassé le build. Avez-vous déjà tenté le coup avec SVN ?

L’idée ici est de donner à cette commande un commit qui ne cassait pas le build ou les tests, celui qui ne fonctionne plus et le test à effectuer (manuel ou automatique). Et par dichotomie, elle va retrouver la version qui a cassé le build.

On peut pousser plus loin :de ce fait, il est possible de jouer un nouveau cas de test (qui devrait passer mais ne passe finalement pas), sur des anciens commit !

Et si on jetait les serveurs d’intégration continue ?

En effet, il est tout a fait envisageable (d’autant plus que c’est ce que David a mis en place dans son entreprise) d’écrire un script qui fait un « private build » avant de faire le commit réel seulement si ce build réussi. Cela est rendu possible par les performances de Git et il est tout à fait possible de travailler en même temps que ce script fonctionne.

Conclusion

Il y a énormément de nouveauté dans Git qu’il n’est pas possible de présenter dans le cadre du Paris JUG. Il nous conseille donc le livre Pro Git.

Il répète Sébastien en confirmant qu’il est possible de passer à Git en une commande : Git va importer le contenu du SVN et agir comme passerelle bidirectionnelle.

Maven 3

2 commiters Maven, Nicolas De Loof et Arnaud Héritier nous présentent Maven 3. La présentation est dynamique mais je reste sur ma faim quand aux nouveautés du produit : elles sont quasiment inexistantes … pour l’instant.

Le contenu :

En effet, le gros sujet, de cette version était une remise à plat des bases avec une refonte du produit (Passage à Java 5) et l’écriture d’une batterie de tests à priori impressionnante. L’écriture de plugins en revanche devrait être simplifiée grâce aux nouvelles API.

Un build plan est mis en place : les plugins pourront savoir ce qu’il s’est passé auparavant dans le buid et donc travailler en conséquence. Notamment le plugin Eclipse pourra laisser Eclipse faire sont boulot (compilation incrémentale) et en tirer bénéfice.

Les pom pourront être écrits dans d’autres langages (groovy, python, …) et les profils ont été revus.

Le résultat :

Une version 100% compatible avec les pom existants via un simple changement de MAVEN_HOME. Les impacts possibles se situent au niveau du plugin site qui n’est pas ou pas bien supporté et éventuellement dans les descripteurs de projet qui sont plus contrôlés.

Le gain que l’on peut avoir aujourd’hui en migrant se situe principalement sur les performances et de meilleurs logs.

Le futur :

• Ajout de la possibilité d’injecter de la configuration dans le pom (mix-in) afin de dépasser les limitations de l’héritage simple.
• Exclusions globales rendues possibles.
• Build parallèle sur multi-coeur
• Ajout d’une console (Maven Shell)

Conclusion :

Il y a peu de risques de régressions, et le passage de Maven 2 à Maven 3 devrait faire gagner du temps. Pour les développeurs Maven et/ou de plugins, le coût d’entrée est maintenant beaucoup plus bas étant donné la refonte. De ce fait la communauté revit et le produit se professionnalise.

Deploy It

La soirée se finit avec la présentation d’un outil d’automatisation des déploiements Java, réalisé par la société XebiaLabs. La présentation de l’outil est faite par Guillaume Bodet et Benoit Maussaud.

Le produit ne se contente pas d’une simple copie de WAR/EAR mais gère aussi :

• Binaire
• Ressources (datasource, securité, …)
• Fichiers de conf
• Base de données
• Réécriture apache
• Fichiers statiques (HTML, images, …)
• Batchs
• …

Je dois avouer que je me suis arrêté là dans la présentation, l’outil n’étant pas open source et ayant l’air plutôt complexe pour une problématique ne me concernant pas …

Intégrer Enterprise Architect dans une approche agile, outiller toute la démarche projet, promouvoir la modélisation UML, formaliser le contrat entre MOA et MOE, centraliser et partager l’information métier et technique, assurer la traçabilité entre les exigences et les processus métier, générer une documentation de qualité, formaliser et capitaliser le métier, …

Objet Direct a détaillé tous ces contextes d’utilisation à l’occasion des 3 événements organisés à Paris, Lyon et Grenoble ces jours-ci, sur le thème « Enterprise Architect, outil stratégique du dialogue entre le métier, l’IT et les applications », en s’appuyant sur les retours d’expérience projets menés chez Boiron, EDF, PSA, au Conseil d’Etat et au CHU de Grenoble.

Vous pouvez télécharger la présentation : ici

3 nouveaux événements techniques organisés et animés par Objet Direct, en avril : « Enterprise Architect, outil stratégique du dialogue entre le métier, l’IT et les applications »
… Pour des modèles UML utiles, à jour et partagés.

Quels sont les scénarios qui favorisent une utilisation pragmatique des modèles au sein des projets, petits, grands, agiles ou en cascade ? Quels sont les atouts d’Enterprise Architect ?
Réponses et démos lors de ces séminaires Objet Direct, avec les retours d’expérience projets menés chez PSA, EDF, au Conseil d’Etat et au CHU de Grenoble.

=> le 7 avril à Lyon, le 8 avril à Grenoble, le 14 avril à Paris, 9h-11h (accueil petit déjeuner)
Evénements gratuits, sur réservation ferme.
En savoir plus et s’inscrire en ligne sur le site d’Objet Direct.

Introduction à la programmation sur iPhone

Partie 1. Langage, interface & contrôles standards

Avec l’App Store, première boutique d’applications tierces sur mobile, l’iPhone d’Apple a donné un joli coup de pied dans la fourmilière de la mobilité. Bien que faisant partie du paysage depuis 2 ans et 100000 applications, son retentissement ne semble pas vouloir s’estomper.

Cela est du, en partie, à la pertinence des choix techniques et des outils – Objective-C et Cocoa Touch – retenus pour son développement. Conscients de l’impact avec lequel il a durablement changé la donne, nous consacrerons ici une série d’articles techniques permettant de s’y acclimater progressivement.

Le premier article sur le sujet – Partie 1. Langage, interface & contrôles standards – est disponible sur le wiki et en pdf.

Je continue mon tutorial sur soapUI. Voyons cette fois-ci comment utiliser soapUI pour réaliser des tests de charge.

Il faut ajouter un nouveau test de charge sur le TestCase voulu.
Note: il faut savoir que le test de charge va lancer tous les tests en parallèle, donc il ne faut pas qu’il y a de dépendance entre les services du TestCase, car ceci pourrait fausser vos résultats.

Une fenêtre s’ouvre, il est possible de choisir la stratégie de test et de la configurer.
A savoir : la durée du test, le nombre de threads à utiliser, le délai (aléatoire ou non) entre chaque nouvelle requête, etc.

Sur cette image on peut se rendre compte qu’un service qui renvoie une stacktrace d’exception est couteuse en temps et en données.

Le tableau de résultat affiche : le temps de réponse min max moyen, le nombre de requêtes totales lancées lors du test, le total de données transférées, le nombre d’erreur.

De plus, la console de log en dessous permet d’avoir des détails sur les tests déroulés, comme l’heure de début et de fin du test, les éventuelles erreurs, etc …