Comme Maxence le précisait dans son article traitant du sujet, les notifications push ne fonctionnent qu’à partir du SDK 8 (2.2). On pourrait se contenter de migrer vers cette version mais on perdrait alors 16% des utilisateurs (contre 40% en février 2011).
Que se passe-t-il exactement ? Sur un device au SDK antérieur, vous aurez l’erreur PHONE_REGISTRATION_ERROR au moment de vous enregistrer au service de Google.

Le problème ne vient pas du code écrit pour s’enregistrer (un simple Intent), ni même de la configuration du manifest (des permissions et un receiver), et pas non plus du code pour recevoir les messages (un BroadcastReceiver).

Tout ceci est disponible dans le SDK 4, et on peut donc le mettre en place sans risquer d’avoir une UnsupportedOperationException. Par contre, afin d’éviter l’erreur à l’enregistrement du device, on va ajouter le bout de code suivant :

if (SysUtils.getSystemVersion() >=  {
	// register to C2DM
}

On n’utilise pas la constante Build.VERSION_CODES.FROYO qui n’est disponible qu’à partir du SDK 8 et donc on utilise sa valeur (8). Cette petite astuce permet de mettre le push à disposition des téléphones récents tout en supportant les téléphones plus anciens.

Support des tablettes

Écrans XL

La logique voudrait que les tablettes soient des écrans xlarge (>= 960dp x 720dp). Dans les faits ce n’est pas tout à fait vrai, il existe des tablettes dans la catégorie large (>= 640dp x 480dp). Google fournit dorénavant la propriété smallestWidth pour déterminer à partir de quelle largeur minimum un layout doit être sélectionné mais ce n’est disponible qu’en version 3.2. Nous avons pris le parti d’utiliser xlarge.

Pour ce faire, vous aurez besoin d’un répertoire layout-xlarge dans les ressources (et éventuellement layout-xlarge-land pour le mode paysage plus fréquemment utilisé pour les tablettes) : aucun problème pour ajouter ce répertoire même dans un projet en 1.6.

Le second point important est la quantité de données à afficher sur un écran de cette taille. On a tendance à regrouper plusieurs écrans en un seul pour profiter de tout l’espace et par conséquent de créer une nouvelle activité. Le problème qui se pose alors est comment réutiliser le code des mes deux, voire trois activités smartphone pour en constituer une seule pour tablette ?

Comme un exemple et un dessin valent tous les blablas, prenons l’exemple d’Appaloosa, notre service de store privé :

Le client Android fournit plusieurs activités pour les smartphones (liste d’applications, détail d’une application et commentaires d’une application) et une seule pour les tablettes. La première chose à faire est donc de choisir la bonne activité en fonction du device. Pour cela on créé une activité de démarrage :

public class LaunchActivity extends Activity {
	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);

		Intent startActivity = null;
		if ((getResources().getConfiguration().screenLayout & Configuration.SCREENLAYOUT_SIZE_MASK) >= 4) {
			startActivity = new Intent(this,
					AppListAndDetailActivity.class);
		} else {
			startActivity = new Intent(this, AppListActivity.class);
		}
		startActivity(startActivity);
		finish();
	}
}

Comme pour le push, on utilise la valeur de la constante Configuration.SCREENLAYOUT_SIZE_XLARGE (4) plutôt que la constante elle-même, disponible à partir du SDK 9. Pour le reste, il s’agit simplement de lancer la bonne activité.

Défragmentation des écrans

Concernant le layout, on pourrait se contenter de concevoir un layout adapté mais ce serait dommage d’aborder les tablettes sans faire usage des Fragments. D’autant que Google fournit depuis mars 2011 une librairie de rétrocompatibilité (Compatibility Package) permettant d’utiliser les fragments dans toutes les applications avec un sdk >= 1.6.

Avant la bataille

• res/layout/app_list_screen.xml : layout contenant la ListView des applications.
• AppListActivity.java : contenant le code pour charger la liste des applications (AsyncTask pour l’appel du web service, ListAdapter pour l’affichage des lignes…).
• res/layout/app_detail_screen.xml : layout contenant les différentes info de l’application.
• AppDetailActivity.java : contenant le code pour charger le détail d’une application (divers AsyncTask pour le détail, les screenshots, le téléchargement du binaire…)

Utilisation des fragments

Après découpage en fragments, on a… beaucoup plus de fichiers ! Oui, en effet, mais c’est nécessaire pour éviter la duplication de code. Reprenons chaque fichier un par un :

Déménagement des layout.xml dans les fragment.xml

L’essentiel du fichier app_list_screen.xml se retrouve dans app_list_fragment.xml : la liste, le loading (chargement de la liste), l’empty message (message en cas de liste vide). Ne reste dans le fichier initial que le code suivant (entête et fragment) :

<LinearLayout
	android:orientation="vertical"
	android:layout_width="fill_parent"
	android:layout_height="fill_parent">

	<include layout="@layout/header_layout"></include>

	<fragment class="com.octo.appaloosa.activity.AppListFragment"
			android:id="@+id/appListFragment"
			android:layout_width="fill_parent"
			android:layout_height="fill_parent"></fragment>

</LinearLayout>

Des activités au fragments, il n’y a qu’un pas

AppListActivity.java (après refactoring) ne contient plus grand chose et étends FragmentActivity au lieu d’une simple Activity. Tous les événements onClick restent dans l’activité :

public class AppnListActivity extends FragmentActivity {

	private AppListFragment listFragment;

	@Override
	public void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.app_list_screen);
		listFragment = (AppListFragment) getSupportFragmentManager().findFragmentById(R.id.appListFragment);
	}

	@Override
	protected void onResume() {
		super.onResume();
		listFragment.loadApplications();
	}

AppListFragment.java contient dorénavant le code pour interagir avec la vue, utiliser les AsyncTask pour les web services, etc… :

public class AppListFragment extends Fragment {
	private List<Application> mApplicationsList = new ArrayList<Application>();
	private ListView mApplicationsListView;

	private AppListListener listener = new AppListListener() {
		public void onComplete(List<Application> apps) {
			mApplicationsList = apps
			((BaseAdapter)mApplicationsListView).notifyDataSetChanged();
		}
	};

	public View onCreateView(LayoutInflater inflater, ViewGroup container,
			Bundle savedInstanceState) {
		View view = inflater.inflate(R.layout.app_list_fragment, container, false);
		mApplicationsListView = (ListView)view.findViewById(R.id.applicationListView);
		mApplicationsListView.setAdapter(new AppListAdapter(mApplicationsList, getActivity()));
		return view;
	}

	public void loadApplications() {
		new AppListAsyncTask(getActivity(), listener).execute();
	}
}

Le mécanisme est assez proche d’une activité, les termes changent un peu (onCreateView au lieu de onCreate par exemple). Par ailleurs, il existe un fragment tout fait pour les listes (ListFragment), que nous n’avons pas utilisé car le layout contenait un peu plus qu’une simple liste (loading notamment).

La version tablette

Je vous épargne l’écran de détail qui est basé sur le même principe pour aborder l’écran tablette qui cumule la liste et le détail. app_list_detail_screen.xml est donc relativement simple puisqu’il utilise les mêmes fragments que les smartphones :

<LinearLayout
  	android:orientation="horizontal"
  	android:layout_width="fill_parent"
  	android:layout_height="0dp"
  	android:layout_weight="1">

  	<fragment class="com.octo.appaloosa.activity.AppListFragment"
		android:id="@+id/appListFragment"
		android:layout_weight="1" android:layout_width="0dp"
		android:layout_height="fill_parent"></fragment>

	<fragment class="com.octo.appaloosa.activity.AppDetailFragment"
		android:id="@+id/appDetailFragment"
		android:layout_weight="2.5" android:layout_width="0dp"
		android:layout_height="fill_parent"></fragment>
</LinearLayout>

Faire le bon choix

Un point intéressant à regarder est l’action d’un click sur un élément de la liste. En effet, si on se trouve dans le cas du smartphone, on lance l’activité de détail (AppDetailActivity). Si on se trouve dans le cas de la tablette, on charge le détail dans le fragment associé :

public void onItemClick(AdapterView<?> parent, View view, int position, long id) {
	AppDetailFragment detailFragment = (AppDetailFragment) getFragmentManager().findFragmentById(R.id.appDetailFragment);
	if (detailFragment == null) {
		Intent intent = new Intent(getActivity(), AppDetailActivity.class);
		intent.putExtra("application", mApplicationsList.get(position));
		startActivity(intent);
	} else {
		if (detailFragment.getCurrentApplication() == null || detailFragment.getCurrentApp().getId().equals(mApplicationsList.get(position).getId()) == false) {
			detailFragment.loadApplicationDetail(mApplicationsList.get(position));
		}
	}
}

Au final, on a beaucoup plus de classes et de fichiers, mais les fragments (java + xml) sont réutilisables, ce qui nous permet d’envisager toute sorte d’interface et surtout envisager les tablettes, voire les TV…

Conclusion

En l’état actuel des choses, il possible de couvrir un spectre de SDKs relativement large (1.6 -> 4.0) et un spectre d’écrans complet (small -> xlarge) avec une seule application. Toutefois, Google fournit la possibilité de proposer plusieurs apk pour une même application, par exemple si la version tablette contient des images HD assez lourdes que l’on souhaite épargner aux smartphones…

On dit souvent qu’Android est fragmenté (je ne le nierai pas complètement) mais cet article démontre que malgré la multitude de devices (qui fait aussi la richesse de la plateforme), on peut adresser 99% des utilisateurs sans trop de difficultés.

La sortie récente de Android 4.0 (Ice Cream Sandwich) promet de réunir les développements tablettes et smartphones mais en attendant d’avoir un parc conséquent d’appareils basés sur cette dernière mouture, il faudra continuer a jouer d’astuces pour cibler le plus grand nombre d’utilisateurs.

Gridgain est un framework open source permettant de développer des applications en cloud ou en grille. Basé sur des annotations, il permet depuis la version 1.6 de distribuer les tests :

public class GridTests extends TestSuite {

	@GridifyTest
	public static Test suite()
	{
		TestSuite suite = new TestSuite("Test for fr.javasioux.gridgain");
		suite.addTestSuite(ClientDaoTest.class);
		// ...
	}
}

L’annotation @GridifyTest permet d’exécuter la suite de tests sur la grille, de même que si j’avais déclaré GridJunit3TestSuite au lieu de la simple TestSuite.

C’est censé fonctionner avec JUnit 4 également (GridJunit4Suite) mais j’ai essuyé quelques exceptions m’empêchant d’aller au bout…

Alors bien sûr, ce n’est pas magique et pour distribuer les tests, il faut bien un ou des noeuds sur lesquels les distribuer. Dans le répertoire bin de l’installation de grigain se trouve un fichier gridgain-junit.bat (ou .sh). Lancez le autant de fois que vous souhaitez de noeud. Bien entendu il s’agit du mode le plus simple de tester, en local tout sur la même machine.

Mais ce n’est pas tout. Plusieurs choses restent à configurer. Et plutôt que de le faire dans eclipse comme la vidéo d’exemple le montre, je vais le faire dans Maven…

Maven

Dépendances

Avant de rentrer dans les détails techniques, quelques généralités. Tout d’abord, les dépendances :

	
		gridgain
		GridGain Repository
		http://www.gridgainsystems.com/maven2/
		
			false
		
		
			true
		
	



	
		junit
		junit
		4.4
		test
	
	
		org.gridgain
		gridgain
		2.1.1
		test
	

Il faut ajouter le repo gridgain car les dépendances ne sont pour le moment pas dans le repo central.

Compilation 1.5

Compilation en 1.5 pour le support des annotations :

			org.apache.maven.plugins
			maven-compiler-plugin
			
				1.5
				1.5
			
		
		
	

Exécution de la suite sur la grille

	1.6.4




			org.apache.maven.plugins
			maven-surefire-plugin
			2.4
			
				
				
					**/GridTests.java
				

				
				-javaagent:${basedir}/target/libs/aspectjweaver-${aspectjweaver-version}.jar
				${basedir}/target/libs/
			
		

		

			org.apache.maven.plugins
			maven-dependency-plugin
			
				
					copy
process-resources
					
						copy
					
					
						
							
								org.aspectj
								aspectjweaver
								${aspectjweaver-version}
								${project.build.directory}/libs/
							
						
					
				
			
		
	

• Premièrement, j’exclue les tests pour n’ajouter que la ou les suites de tests.
• Ensuite, on a besoin de préciser le javaagent (doc officielle), en l’occurence aspectj weaver.
• Et pour que le javaagent retrouve ses petits, il faut copier le jar dans le répertoire pointé par le javaagent.

Un point important qu’on ne voit pas dans le pom est la présence du META-INF/aop.xml (disponible dans gridgain-x.x.x/config/aop/aspectj/) dans les ressources du projet (src/test/resources). Effectivement ce répertoire doit être dans le classpath.

Exécution

Comme je le disais plus haut, il faut lancer autant d’instances que nécessaire dans le répertoire bin de gridgain. Ensuite, depuis votre projet mave, lancez simplement un mvn test -DGRID_ROUTER_PREFER_REMOTE=true

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running fr.javasioux.gridgain.GridTests
[00:56:01,906][INFO ][main][GridKernal%junit]
  _____      _     _  _____       _
 / ____|    (_)   | |/ ____|     (_)
| |  __ _ __ _  __| | |  __  __ _ _ _ __
| | |_ | '__| |/ _` | | |_ |/ _` | | '_ \
| |__| | |  | | (_| | |__| | (_| | | | | |
 \_____|_|  |_|\__,_|\_____|\__,_|_|_| |_|

...

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------

Et voilà ! On a un build Maven qui exécute les tests en parallèle sur plusieurs noeuds.

Conclusion

Ecrire des tests, c’est bien… Les executer, c’est mieux ! Et donc si vous avez arrete de les executer car vous etes perpetuellement en train d’attendre qu’ils soient termines, gridgain peut vous aider. Ce framework de cloud permet (entre autre) de dispatcher les tests en parallele sur differents noeuds et ainsi diminuer la duree du build.

Toutefois, lancer plusieurs fois gridgain-junit.bat sur son poste fini par plomber le temps de build plutot que de l’ecourter. Il faut donc mettre en place une vraie infrastructure de cloud sur des serveurs / VM distantes pour y gagner. Je suis parvenu à utiliser gridgain dans un JBoss local (Mac OS) depuis une VM Windows (Gridgain peut découvrir les noeuds faisant partie de la grille) :

Sur l’integration continue, cela peut egalement etre utile pour alleger la charge sur serveur. L’ideal serait de pouvoir combiner cette fonctionnalite avec les possibilites de build distribue fournies par les principaux acteurs du marche (Teamcity, Hudson) et ainsi lancer les tests sur lea agents deja configure. A quand un plugin Hudson Gridgain ?!

Suite à cela, proposition de sujets. Tous ceux qui le souhaitaient, passaient au tableau présenter rapidement un sujet. C’était très varié : quelques topics orientés outils (Plugins Hudson, futur de l’IC…), pas mal autour des tests (accélérer les tests, les mocks, les UAT, les tests sur la bdd), l’agile (scrum) et j’en passe.

Samedi matin, 10h00, première session sur les plugins Hudson, où comment développer un plugin hudson, quels plugins manquent, etc…

Douglas Squirrel nous présente un plugin qu’il a développé pour voir le status d’agents depuis Nagios (par exemple lorsque le serveur maître est down). Son retour d’expérience est que la documentation pour créer des plugins est relativement bien faite et que l’utilisation de maven facilite la chose (mvn hpi:create). Par contre, l’utilisation de jelly pour la création de vue est assez déroutante ainsi que savoir où placer son code. Heureusement la communauté est là et Kohsuke Kawaguchi aussi ! Une fois votre plugin codé, la commande mvn hpi:run lance un hudson en local et vous pouvez tester votre création. Donc n’ayez pas peur de vous lancer, ca fait pas mal normalement. Je vais peut-être tenter…

On est ensuite parti sur les plugins et améliorations à avoir : meilleure gestion des dépendances entre build avec par exemple la possibilité d’avoir un graph des dépendances entre build, la distribution des tests unitaires : j’ai bien envie de tenter de distribuer les tests avec gridgain sur les agents configurés dans hudson (un article devrait arriver d’ici peu sur le sujet).

11h15, deuxième session. J’ai commencé par aller voir le sujet du déploiement en continu, mais étant arrivé après le départ, j’ai eu du mal a entrer dans la discussion. Ils parlaient de pipeline de build avec toutes les étapes de l’intégration continue. Ca m’a paru bien loin du sujet initial et j’ai donc changé de salle (c’est le principe des open spaces, si ca ne vous plait pas, partez) pour aller discuter release de (gros) projets. Vincent Massol se pose la question de comment automatiser la release : quand un produit (au hasard XWiki ) est composé de nombreux modules (qui n’ont pas forcément tous bougé et n’ont dont pas forcément à être releasé), le mvn release n’est pas forcément adapté puisqu’il descend dans les sous modules et les release tous. Après nous avoir présenté sa manière de faire pour les releases XWiki (une belle et longue procédure), on part sur la réalisation d’un algo pour trouver les dépendances d’un projet qui ont évolué depuis la dernière release :

// En récursif sur le projet parent et tous les modules :
List currentDependencies = getDependencies();
// Faire de même avec la version précédente du projet (avec le scm, récupérer la version tagé antérieure)
List previousDependencies = getPreviousDependencies();
// Faire le diff des deux listes sur les versions => on obtient les modules ayant évolués
// On peut ainsi releaser ce qui a été modifié
// On peut avoir les évolutions de version pour la release note

On s’est ensuite plongé dans le code du plugin dependency pour essayer d’y inclure le mojo diff permettant d’avoir le différentiel entre deux versions sans toutefois aller bien loin puisque le déjeuner nous appelait.
On a également mentionné un plugin Maven que je ne connaissais pas : versions-maven-plugin et qui permet, comme son nom l’indique, de jouer sur les versions des artefacts et entre autre de setter une version pour un projet et tous les modules qui le constituent (fini les grep !) ou encore d’avoir la liste des dépendences et plugins qui sont disponibles dans une version plus récente.

Le déjeuner est l’occasion de discuter avec Hervé Boutémy d’OSS : Apache, Maven, Archiva, Continuum, Jason Van Zyl… discussion intéressante sur le passage de l’open source au gain de sa vie (distinction avec « se faire de l’argent »).

14h00, session sur la rapidité des tests. La session commence par une question : « combien de temps prennent des tests rapide ? », sans toutefois préciser de quel type de test on parle. On en arrive à généraliser à comment avoir un feedback rapide (pas seulement les tests mais le build complet) et il émerge que 5 minutes est le maximum raisonnable.
Douglas Squirrel nous présente son expérience avec selenium : 12 agents hudson, 15 agents pour selenium pour tester sur différents browsers. Avec cette technique, il en a pour 25 minutes à faire ses tests d’IHM.
Par la suite, différentes propositions sont faites :

• Exploiter au mieux les différents cœurs des processeurs (chose qui n’est actuellement pas le cas avec surefire par exemple et qui pourrait s’avérer vraiment bénéfique)
• Distribuer les tests avec Gridgain (pour JUnit) ou TestNG
• Utiliser une base mémoire (HSQL, H2) pour les tests unitaires. On s’est attardé sur le fait de commiter ou pas les requetes mais étant en mémoire, je ne vois pas le problème de commiter.
• Le personnal build (fonctionnalité de Teamcity) pour permettre de continuer à coder pendant que l’intégration continue déroule le build (sans toutefois commiter le code pour ne pas perturber les autres développeurs).
• Et une fois que toutes les solutions annexes ont été mentionnées, quelqu’un a tout de même dit : « et si c’était les tests qui étaient pourris ». Donc plutôt que de chercher à améliorer le build, améliorer les tests eux-mêmes. Il parle de réduire le nombre de tests, qui en soit peut être une bonne chose si la couverture reste équivalente. Mais pour cela, il souhaite utiliser des valeurs aléatoires. Je l’interpelle « comment on peut connaître le résultat attendu en faisant du random ? » Alors effectivement, c’est pas tout à fait du random. On a une map avec les valeurs d’entrée et leurs sorties attendus et on test un cas au hasard. Avec le nombre de builds joués par jour, on s’attend à avoir couvert l’ensemble. On diminue effectivement le nombre de tests mais je ne suis pas convaincu de la reproductibilité, du moyen de corriger une erreur détectée par un test…

15h15, session Cloud, le sujet du moment. Avant toute chose, on a décrit les raisons pour lesquelles on veut aller sur le cloud :

• Réduction des coûts d’infrastructure (serveurs), maintenance et mise à jour des outils
• Optimisation du coût d’utilisation du CPU.
• Gérer au mieux les pics de charges. Comme vous pouvez le voir sur le graphique, le serveur d’intégration continue n’est utilisé qu’à certains moment (en bleu) et donc le reste du temps, on paye pour rien (en rouge).
  

Ensuite, on a parlé des différents problèmes que l’on peut avoir à mettre le serveur sur le cloud (Amazon EC2 par exemple). Plusieurs choses :

• La première à mon sens est la sécurité. Tout le monde n’a pas d’algo de pricing ultra protégé mais pour ceux la, le code n’est pas prêt d’être déporté. J’ai récemment vu dans une grande banque d’investissements française que d’une équipe à une autre, il ne souhaitait pas diffusé le code donc ce n’est pas encore pour tout le monde. Mais il existe des solutions, il est effectivement possible de mettre en place un VPN et ainsi limiter le risque. J’ai beaucoup aimé la remarque de Nicolas Martignole qui « fait plus confiance en Amazon qu’en son équipe IT » et qui imagine bien dans quelques mois ou années coder sur son poste et compiler/tester… sur le cloud.
• Autre problème mentionné, les latences réseaux
• Les limitations en cas d’environnement complexes… on ne peut pas tout déporter.

Une des personnes présentes a mentionné Eucalyptus Cloud et en est plutôt satisfait.

Conclusion, je n’ai pas pu participé à la dernière session, mais je suis assez satisfait de ma journée. Des discussions intéressantes, des gens intéressants, bien entendu, vu le nombre de sujets en parallèles à chaque session, il m’a fallu choisir mais aucun regret sur mes choix. L’une des sessions consistait à choisir le prochain pays d’Europe à accueillir CITCON et donc, on verra l’année prochaine si je pourrai remettre ça.

Sur métroide (mon application de calcul d’itinéraire de metro pour Android), j’ai un grand nombre d’images pour toutes les lignes du métro (+rer et tram) que je dois afficher dynamiquement sur l’itinéraire.

Comme un exemple vaut mille paroles, exemple :
J’ai l’itinéraire suivant : nation (« m1″: ligne 1 du métro), porte d’italie (« m7″).
Je vais donc avoir besoin des images R.drawable.m1 et R.drawable.m7. Mais je n’ai qu’une chaine de caractère pour spécifier le nom de l’image. J’aurais aimé faire un truc du genre R.drawable["m1"] ou R.drawable.get(« m7″)… mais malheureusement, ce n’est pas possible. Je dois avouer que pour le concours SFRJTD, je n’ai pas poussé plus loin mes recherches et j’ai fait un switch en découpant ma chaine (m1 -> m et 1, donc m me dit metro, 1 ligne 1, je prend donc R.drawable.m1)… berk !

Cette solution ne me convenant pas et n’ayant pas trouvé de réponse à ma question, je me suis dit : « tant qu’a faire crade, pourquoi ne pas faire de l’introspection ? » Et c’est comme ca que j’ai réduit un switch de 40 lignes en 5 lignes comme ceci :

try {
	Field f = R.drawable.class.getField(line); // line = "m1" ou "rb" ou "t3"...
	return f.getInt(null); // class static et champs static dans R, on peut laisser à null
} catch (Exception e) {
	return R.drawable.empty;
}

Je ne suis pas encore complètement convaincu et je me dis que j’ai du me prendre la tête à faire compliqué alors que c’est prévu dans le SDK. Si tel est le cas, je suis preneur de vos solutions…

Je ne vais pas m’étendre sur la première partie présentée par Erwan Alliaume et Cyrille Le Clerc de Xebia ainsi que Jean-Michel Bea de FastConnect, le touilleur a encore une fois fait un bon résumé. La session était dense mais très intéressante.

Javarebel

Je vais m’attarder un peu plus sur la deuxième partie (qui n’a duré qu’une demi heure) dont le sujet me correspond plus : la productivité des développements avec JavaRebel. C’est Toomas Römer de ZeroTurnaround qui nous présente l’outil.

La démo de l’outil est toujours aussi bluffante (dispo ici et là), d’autant que pressé par le temps, Toomas l’a déroulé assez vite, ajoutant du punch à la démo :

• Modification d’une jsp => rafraichissement instantané de la page web
• Modification d’un validator => rafraichissement instantané de la page web
• Ajout de méthode, de paramètres => rafraichissement instantané de la page web
• Ajout d’un bean spring et d’une jsp => rafraichissement instantané de la page web

Aucun repackaging, aucun redéploiement, aucune perte de temps ! C’est l’objectif de Javarebel : éviter de devoir recompiler, retester, repackager et surtout redéployer l’application à chaque modification du code.

La démo nous laisse à penser : « mais comment j’arrive à supporter mes builds Maven de plusieurs minutes ? » Probablement parce qu’on n’a pas goûté à ce plaisir…

A la fin de la session, on a le droit à une question intéressante qui est de savoir s’il (Toomas ndlr) n’avait pas peur que les développeurs ne prennent plus le temps de réfléchir à leur code (modélisation, archi…) mais se contentent de coder / tester / coder… pour se rendre compte au bout de plusieurs heures que leur code n’est pas bon. Ce à quoi Toomas a répondu que l’outil était là pour éviter de perdre du temps au redéploiement (10 minutes par ci, 10 minutes par là) et ne devait pas changer la manière dont travaillent les développeurs. Et Antonio d’ajouter qu’on ne pourrait plus prendre autant de pauses cafés !

A l’issue de la présentation, en discutant avec Erwan (qui avait blogué sur le sujet), il s’avère que l’outil n’est pas tout à fait aussi magique, tou au mions pas tout le temps. Notamment sur un gros projet, Javarebel rame et finit même par planter. Je présume qu’il doit bien s’appliquer sur des appli webs relativement simples.

En tout cas je suis persuadé que la démo plus quelques chiffres pourraient convaincre quelques managers de l’intérêt de l’outil.
Pensez donc : 10 développeurs qui redéploiement environ 10 fois par jours au prix de 5 minutes à chaque fois (maven + serveur d’app) : 500 minutes (8h), soit 1j.h perdu par jour ! Au regard du prix de la license (150 $ pour une entreprise), ca donne à réfléchir !

La torture

Il y a quelques techniques pour contraindre et forcer les gens à faire attention à l’intégration continue :

• Verser quelques centimes d’euros dans une cagnotte à chaque fois que l’on fait échouer un build. Doubler la mise si le build n’est pas réparé dans l’heure et payer les croissants si le build est toujours rouge le lendemain… C’est assez sévère mais si ça peut permettre de nourrir l’équipe en même temps, pourquoi pas ?!
• Afficher la photo du plus mauvais builder de la semaine dans l’open space. Pareil, ça peut ne pas plaire et donc inciter chacun à y mettre du sien. Je vous conseille l’image de fond suivante, ca fera du plus bel effet :
  
• Sinon, à l’ancienne, le bonnet d’âne, ridicule à souhait
• … à vous de trouver ceux qui s’adapteront le mieux à votre équipe !

Le fun

On va arrêter de terroriser les développeurs… Le bâton n’est pas forcément le meilleur moyen de faire avancer les choses. On peut donc tenter la carotte, ou tout au moins essayer de dédramatiser le cassage d’un build sans pour autant oublier de le corriger !

Les lampes

Utiliser une Ambient Orb permettra de donner un peu de couleurs au plateau. Pour les détails d’implémentation, vous pouvez lire ce post assez complet. Pour les plus courageux d’entre vous, vous avez aussi les lava lamp et là attention, c’est assez teutchi de par l’utilisation du protocole X10 ! On doit pouvoir en trouver en usb pour simplifier la tâche. Remarque: préférez les lampes vertes et rouges, enfin vertes surtout

Le lance-missile USB

Je remercie Erwan Alliaume qui m’a récemment donné cette idée. Effectivement, il existe des lance missile USB que vous pouvez programmer pour lancer un missile sur la personne qui a fait échouer le build. A condition toutefois d’avoir une petite équipe sur un petit open space. J’adore !

Le Nabaztag

Enfin, un peu plus connu mais tout aussi efficace, le lapin wifi, Mr Nabaztag ! De même que pour les gadgets ci-dessus, il existe une api permettant de manipuler le lapin. Il a d’ailleurs eu tellement de succès auprès de tous les amateurs d’intégration continue qu’il existe des plugins pour hudson, teamcity ou encore cruise control, hallucinant !

Conclusion

Voilà la preuve qu’on peut travailler en s’amusant et joindre l’utile à l’agréable ! Fini la corvée de réparer un build cassé, ça sera désormais avec le sourire et la bonne humeur qu’on le fera. Comme j’aime à le dire : on peut avoir « le fun et l’argent du fun » (© VDL) ! Je vous souhaite donc une bonne année 2009 pleine de Nabaztags, de lances missiles… mais surtout pleine de builds verts et de logiciels de qualité !

PS: n’hésitez pas à nous faire découvrir vos systèmes de notifications les plus funs, ou même les plus efficaces.

Après avoir lu la release note, Netbeans ne semble pas avoir à rougir de son concurrent…

Premier pas…

Contrairement à Eclipse qui se décompresse tout simplement, Netbeans s’installe. La première méthode a le mérite d’être simple et de ne pas nécessiter les droits administrateurs, problématique chez certains clients…

Plugins

On fait souvent l’éloge des nombreux plugins disponibles pour Eclipse et effectivement ils sont nombreux. Le problème, c’est que la plupart ne fonctionnent pas, ou pas sur notre version d’Eclipse ou bien encore rendent l’environnement instable, bref c’est pas la panacé !

Je me lance donc à la recherche des plugins que j’ai l’habitude d’utiliser :

Maven

J’ai entendu beaucoup de bien à propos du plugin Maven. Je m’empresse de l’installer via le menu Tools/Plugins. Tout comme son copain Eclipse, il faut le redémarrer pour prendre en compte l’update… dommage. Je créé une webapp maven en quelques clicks :

En moins de temps qu’il n’en faut pour le dire, je peux déployer l’application sur un glassfish installé pour l’occasion avec Netbeans. Deux petites modifications dans l’index.jsp, un refresh dans le browser et magie, mes modifications sont là sans redéploiement. Ca me plait bien, je verrai après ce que ça donne pour le rechargement de classes à chaud !

Revenons-en à nos moutons et ajoutons Spring à nos dépendances. Intuitivement je fais un click droit sur Libraries, et je trouve mon bonheur avec « Add Library ». Monsieur a même profité du temps que je passais à jouer pour m’indexer le repo central et ainsi me proposer les groupId, artifactId et version :

J’importe un projet multi module existant sans problème, quelques clicks pour lancer des goals maven, bref la base est là. Par contre, pas d’éditeur avancé du pom (même si je ne m’en sers jamais), pas d’analyse graphique des dépendances (très pratique pour faire du ménage), des absences que propose m2eclipse. Cependant, l’ensemble est bien mieux intégré à l’éditeur : j’ai souvent des problèmes avec m2eclipse et je dois désactiver la gestion des dépendances puis la réactiver…

Spring

J’ai passé un peu de temps à chercher un équivalent de Spring IDE. J’en trouve un sur la page des plugins mais ne parvient pas à l’installer. Finallement, je me dis que c’est peut être déjà intégré, sait-on jamais ? Et effectivement, il est bien là !

Navigation dans les beans, autocomplete, les basiques encore une fois mais intégrés directement à l’éditeur. Je retrouve mon Ctrl + click pour aller directement dans les classes Spring (après récupération du code à l’aide de Maven) ou dans mes propres beans.

Contrôle qualité

J’aime bien disposer sur mon IDE des différents outils dont on dispose sur l’intégration continue. Cela me permet de découvrir un problème dès le moment où il est écrit, plutôt que d’attendre le retour du maven site quotidien effectué sur l’intégration continue. Bref…

Checkstyle

Le plugin Checkstyle (que je peux configurer avec mon fichier de règles) me permet d’avoir quelques alertes sur la qualité de mon code.

PMD

Tout comme checsktyle, PMD s’installe très facilement et fonctionne ! Sur Eclipse, je ne sais plus trop où nous en sommes à ce niveau étant donné que ça ne marche jamais avec ma version et donc j’avais un peu abandonné l’idée… Là, j’ai mes alertes (configurées avec les mêmes règles que l’intégration continue) et en plus c’est joli :

Seul bémol, l’outil ne me propose aucune correction, mais rare sont ceux qui le font.

Niveau plugins, je suis donc plutôt satisfait et grâce à ces quelques outils supplémentaires (mais très bien intégrés), je vais pouvoir être productif et efficace !

A l’utilisation

Rapidité de l’IDE

Les déplacements de fichiers (refactoring) sont lonnnnnnnngs, chaque action (ctrl + espace, click droit, …) bloque l’éditeur quelques secondes, à la longue ça devient fatiguant ! Assez étrange pour un outils de cette facture… Je test donc sur un autre PC (sans vista cette fois ) et là rien à voir, quelques lenteurs « habituelles » pour du java, mais ça reste du niveau d’Eclipse. Grosse frayeure !

Raccourcis claviers et refactoring

Je parviens à retrouver mes raccourcis préférés :

• Ctrl + O remplace le Ctrl + Shift + T pour rechercher un type. Alt + Shift + O remplace Ctrl + Shift + R pour une ressource.
• Le raccourci Alt + Insert propose quelques « générateurs automatiques » :
  
• On peut remonter dans la hiérarchie (classe mère ou interface) d’une classe avec Alt + F12 ou Ctrl + Shift + P pour une interface.
• L’optimisation des import se fait avec Ctrl + Shift + I (Ctrl + Shift + O sous Eclipse).
• Le Ctrl + Shift + V est une belle alternative au copier-coller puisqu’il permet de coller du code directement formaté. Plus besoin de faire Ctrl + V, Ctrl + A puis Alt + Shift + F (Ctrl + Shift + F sous Eclipse).
• Niveau exécution et debug on peut vite s’emmêler les pinceaux : F11 buid sous Netbeans et debug sous Eclipse, F6 run sous Netbeans et step over sous Eclipse, Ctrl + F5 debug sous Netbeans et F5 step into sous Eclipse !
• … Netbeans propose un pdf regroupant les différents raccourcis (disponibles sur la version 6.1 mais qui pour la plupart fonctionnent aussi sur la 6.5), très pratique quand on découvre l’outil.

Quelques critiques :

• Le quick fix (Alt + Entrée) est loin d’être si évolué que le Ctrl + 1 contextuel d’Eclipse.
• Je n’ai pas trouvé comment rechercher les implémentations d’une interface (Ctrl + T sous Eclipse), on doit faire un Find Usage (Alt + F7) puis rechercher les sous-types.

Ecriture / Formatage du code

Concernant l’aide à la saisie et malgré l’absence du Ctrl + 1, Netbeans fournit de nombreux templates de code. Tapez « forl » puis Tabulation, il vous génèrera une jolie boucle for… C’est juste dommage qu’on ne puisse pas utiliser le Ctrl + Espace au lieu de la tabulation.
J’ai été déçu de ne pas trouver « sysout », mais Netbeans permettant d’ajouter ses propres templates, j’ai rapidement résolu le problème.

D’autre part, vous avez comme dans Eclipse tout un module de gestion du formatage, pour ajouter des espaces après les ; dans les boucles for, aligner les paramètres de méthodes sur plusieurs lignes, j’en passe et des meilleurs.

Rien de bien extraordinaire mais l’essentiel est là.

Warnings

Au niveau des alertes, on peut comme sous Eclipse personnaliser le niveau. On retrouvera quelques problèmes que peuvent remonter checkstyle, findbugs ou PMD :

Actions à la sauvegarde

Malheureusement aujourd’hui, Ctrl + S ne fait rien de plus que sauvegarder votre fichier dans Netbeans. C’est déjà pas mal me direz vous mais comparé à Eclipse qui permet de formater le code, organiser les imports et plus encore, c’est assez décevant. On perd donc pas mal de temps avec les raccourcis de formatage et d’organisation des imports…
Il y a une issue sur le sujet ouverte chez eux depuis… juillet 2008. Mais pourquoi ne pas l’avoir intégré à la version 6.5 ?!

Gestionnaire de sources

Pour le coup, j’ai utilisé le gestionnaire de source de mon client (Clearcase UCM) et je suis assez content de voir qu’il existe un plugin clearcase (disponible dans l’IDE sans googler !).
Pour ceux qui ne connaissent pas, tous les fichiers sur le poste de travail sont en lecture seule. Lorsqu’on veut travailler sur un fichier, on le « checkout » en précisant une activité (une sorte de tâche). Il est alors possible de le modifier puis de faire un « checkin » pour le remettre au source control.
Le problème que j’ai rencontré, c’est l’impossibilité de choisir mon activité lors du checkout ! Du coup, je modifie du code avec la dernière activité créée.

NB : CVS, SVN et Mercurial sont directement intégrés.

Tests unitaires

Je ne suis pas aidé pour faire du TDD : la création de classes se fait dans le même package que le test, donc dans le répertoire src/main/tests/… Pas de problème pour refactorer et déplacer ma classe mais c’est un peu gênant. Pour la création des méthodes manquantes, pas de problème.

Par contre, je suis agréablement surpris lorsque je vois que l’exécution des tests est faite avec Maven (mvn -Dtest=EmptyJUnitTest test-compile surefire:test) et le résultat est disponible dans l’interface (pas besoin d’aller dans les fichiers surefire). Plus de différence de comportement entre mon IDE et mon build .

Debug / Exécution

Concernant le debug, tout est là, j’attache mon debugger par dt_socket sur le port qui va bien et roulez jeunesse. Nous avons vu plus haut que nous disposons de nombreux raccourcis pour le pas à pas mais si vous êtes habités à Eclipse, vous risquez de vous embrouiller les premières fois…

Pour en revenir au rechargement à chaud des classes modifiés dans ma webapp, ça ne marche pas, je dois arrêter et relancer le serveur.

Conclusion

Après quelques jours d’utilisation en remplacement d’Eclipse, je suis assez content. J’avais un peu peur des lenteurs chez moi sur un Vista mais au boulot sur XP ou sur Ubuntu, tout roule. Pour le reste, pas mal d’éléments bien intégrés (maven, spring) peuvent servir d’exemple à Eclipse.

De surcroît, il fournit pas mal de fonctionnalités en plus (que je n’ai pas testées) : php, groovy & grails, un éditeur swing sympa, le profiling, un designeur html/ jsp / jsf à étudier, un éditeur avancé de web.xml ou de faces-config.xml… bref pas mal d’éléments pour commencer rapidement à développer.

Par contre, il manque quelques raccourcis pour faciliter la navigation, les actions à la sauvegarde également. On perd donc un peu de temps de ci de là.
De même, j’ai été assez gêné avec le plugin clearcase : obligé de créer une activité en dehors de l’IDE avant de modifier des fichiers… Je ne doute pas que CVS et SVN soient bien mieux gérés.

Alors, abandon d’Eclipse ou pas ? Si le plugin clearcase me permettait de créer mes activités, je pense que j’essaierai. Malgré quelques raccourcis manquant, il est très agréable à utiliser, relativement fluide au final et répond à mes besoins. J’essaierai au moins dans un premier temps pour valider cette semaine de test et si tout va bien, souhaiterai bon vent à Eclipse. Donc à voir sur un projet sans Clearcase

Prochaine étape : tester IntelliJ. Affaire à suivre sur javasioux !

On entend souvent ici ou là des plaintes quant à la qualité et la quantité de documentation sur Maven. Je pense qu’Apache peut effectivement fournir des efforts, ainsi que tous les plugins mais globalement, on va dans le bon sens :

• Les Guides Maven, fournissent un bon point de départ à Maven
• L’ebook Better Build with Maven, écrit par Jason Van Zyl en personne, et Vincent Massol, qui au delà de l’utilisation simple de l’outil décrit comment réaliser un plugin, comment migrer un projet vers Maven (la fameuse « mavenisation »), travailler en équipe avec Maven…
• L’ebook Maven Definitive Guide, aussi publié chez Oreilly et un poil plus récent, décortique Maven en long, en large et en travers. Tout y passe, jusqu’au plugin m2eclipse en passant par le repository manager Nexus. Tout y est décrit et illustré par des exemples… en un mot, la référence venu de Sonatype (dont Jason Van Zyl est CTO).

Avec environ 1000 pages de documentation sur Maven, rien que dans ces 2 livres, vous n’avez plus d’excuses pour vous y mettre !

La productivité des développements

Sans rentrer dans les détails du document, je vous laisse le télécharger et le lire mais voici les points qui me semblent clés :

• Disposer d’un socle technique (jdk, frameworks…) qui permet d’être productif. La sphère java est très nébuleuse et il est parfois difficile de s’y retrouver dans tous les frameworks disponibles. Privilégier les standards de fait, autrement dit les frameworks qui, à force d’utilisation, sont devenus des références et qui grâce à cette renommée, ont également pu s’améliorer. On citera notamment hibernate pour le mapping objet relationnel, spring qui couvre pas mal de domaines aujourd’hui (configuration, injection de dépendances, sécurité, batch, IHM web…). Ce dernier est particulièrement productif, tout au moins dans ses dernières versions, où la configuration XML a laissé place aux annotations. Annotations d’ailleurs apparues avec le jdk 5, qui apporte beaucoup du point de vue productivité et efficacité.

• Disposer d’un environnement de développement optimum sur le poste de travail du développeur; à savoir un éditeur efficace (Eclipse, IntelliJ) et correctement configuré (raccourcis, syntaxe du code…) avec des plugins additionnels aidant à être productif (Spring Ide si on fait du Spring par exemple). Mais ca ne s’arrête pas à l’éditeur. Le serveur d’application, si l’on développe une application JEE, est tout aussi important. Comptez le nombre de minutes passées à attendre qu’un ear se déploie et multipliez par le nombre de déploiement effectués par jour, vous allez simplement haluciner. Personnellement, j’apprécie beaucoup jetty qui est simple à configurer, démarre très vite et peut être lancé depuis Maven. Vous verrez que vous aurez moins peur de votre code quand vous saurez qu’en moins de 30 secondes, c’est plié, comparé à un certain serveur qui commence par web et fini par sphere…

• Disposer d’une usine de développement et tous les composants qui s’avèrent nécessaires :
  • Gestionnaire de sources, dans un premier temps, afin de garantir un échange plus fluide entre les développeurs et un gain de temps sur l’intégration du code.
  • Mécanisme et process de build, autrement dit un outil à la Maven et les bonnes pratiques qu’il apporte, afin de se baser sur un standard éprouvé et ne pas chercher midi à 14 heures où sont vos fichiers et comment construire votre application.
  • Intégration en continue, pour éviter l’ »effet tunnel » et les longues soirées la veille d’une livraison parce que le module foo ne correspond pas à ce qu’appelle le module bar…
  • Outil de suivi de tâches et anomalies, au moins pour faciliter les échanges MOA/client  – MOE.

• Enfin, rester « aware » concernant la productivité. JCVD, sors de mon corps ! Blague à part, on est productif si on est dans un état d’esprit productif, c’est à dire qu’on cherche à limiter les tâches répétitives manuelles en les automatisant, on ne reste pas dans l’inconfort (je citais Websphere plus haut : si vous perdez une heure par jour au moins à déployer votre application, remontez le au manager qui généralement n’aime pas ce temps gaspillé, ça facilitera peut-être un changement), on parle de productivité et on lève les problèmes pour les résoudre au plus tôt mais sans tout changer…

• J’allais oublier quelque chose qui me semble prépondérant et qui va faire la transition avec la deuxième partie : les tests. Bien sûr, certains médisants diront que les tests consomment du temps et qu’ils sont contre-productifs. A ceux-là, je dirai faites un calcul simple : comptez le nombre de bugs dans vos applications, multipliez par le temps de correction et par le taux de réapparition moyen :

nombre de bugs  x  temps de correction  x  taux de réapparition moyen  =  consommé

Exemple :  50  x  1j.h  x  0.30  =  15

Maintenant, pour chaque bug apparu et chaque nouvelle fonctionnalité, ajoutez un ou plusieurs tests unitaires (JUnit par exemple) qui valident (et valideront au cours du temps) le bon fonctionnement et la non-régression. Refaites ensuite le calcul précédent au cours du temps. Non seulement vous réduirez le nombre de bugs, mais vous réduirez également le temps de correction et le taux de réapparition : les tests permettent de cibler plus rapidement un bug qu’en passant au travers de tout le code avec un debugger, et ils limitent également les régressions.

Exemple : 30  x  0.5j.h  x 0.10  =  1.5

Alors, c’est pas de la productivité ça ?

Et la qualité ?

On a souvent tendance à délaisser la qualité au profit de la productivité et des coûts. Rappelez vous du fameux triptyque coûts – délais – qualité :

Le problème c’est qu’on oublie tout aussi souvent que les trois sont étroitement liés et qu’une mauvaise décision sur l’une des branche peut impacter les deux autres :

• « Il faut livrer vite, à telle date, je veux tout ça ! »
• Pour palier à la réduction des délais de livraison, on augmente généralement le nombre de développeurs, c’est à dire les coûts. De même, on met de côté la qualité (doc, tests…) pour s’attacher aux fonctionnalités.
• Le problème en délaissant la qualité, est qu’on augmente les délais (cf. calcul ci-dessus) et généralement aussi les coûts (100j.h, c’est plus cher que 50…).
• Au final, on a voulu réduire les délais et c’est le contraire que l’on a obtenu.

Maintenant on peut envisager les choses autrement :

• On mise sur la qualité. Cela passe par tout un tas de choses dont nous parlerons ensuite et notamment les tests.
• Soyons honnêtes, à court terme, cela augmente les coûts et les délais : développer des tests en plus du code est consommateur, mettre en place une usine de développement prend du temps, configurer correctement un environnement de développement peut sembler futile…
• Par contre, à moyen et long terme, cela s’avère payant, les développeurs sont plus efficaces (intégration continue, IDE configuré), plus sereins (couvertures des tests).

Combien de projets en échecs pour un réussi ? combien de budgets dépassés pour un tenu ? Cela se produit encore trop souvent parce qu’on se borne à vouloir faire comme on a toujours fait, à savoir mal !

Je n’ai pas de chiffre précis pour comparer les deux cas cités ci-dessus mais simplement un retour d’expérience :

Je travaille pour le compte d’une grande banque française sur le développement d’un outil de provisionning d’habilitations. En 3 semaines, avec des tests unitaires (JUnit), des tests d’interface (Selenium), un serveur d’intégration continue (Hudson), on a mis en production une première version simple mais qui marchait.

Aujourd’hui, 6 mois et 1600 tests plus tard, on a à tout casser 5 bugs bloquants et tout au plus une dizaines de majeurs (en préprod) et aucun bug important sur la prod… Un nouveau développeur arrivé récemment a pu, grâce aux tests et sans souffrir, faire un gros refactoring au bout d’une semaine sur le projet. Le temps de correction d’un bug est inférieur à la demi journée, voire à l’heure… bref, on a misé sur la qualité et aujourd’hui, l’application est stable, évolutive, l’équipe est efficace et la MOA commence a comprendre l’intérêt d’être un peu patient.

Conclusion

Je ne suis pas entré dans les détails sur la qualité des développements, les différents types de test, les méthodologies de tests, les outils annexes pour faire de la qualité (métriques diverses)… et tout ce dont nous avons à disposition pour faire des logiciels de qualité. Je traiterai plus en détails de ces aspects dans un prochain article. Je voulais surtout mettre l’accent sur le fait que la productivité n’est pas incompatible avec la qualité, voire bien au contraire : faire du travail propre permet d’être efficace !

Encore une fois : faites l’expérience et prenez le temps de mesurer les gains de la mise en place de tests par rapport à une politique de debug intensif. Vous verrez que vous y gagnerez en qualité et en productivité…

Et surtout, n’hésitez pas à lire le livre blanc Octo