Introduction

Le développement d’applications pour terminaux mobiles (iPhone, iPad, Android, Blackberry, Windows Phone, Nokia Symbian, Samsung Bada…) se heurte à la fragmentation des technologies de développements: environnement iOS/Objective-C pour l’iPhone et l’iPad, SDK Java spécifique pour Android, J2ME pour Symbian, etc.

Deux approches possibles lorsque l’on débute un projet d’application ciblant plusieurs de ces plateformes sont de développer une application pour chacune d’elle, ou de développer un site Web compatible.

Dans le premier cas, l’inconvénient concerne bien évidemment le coût des développements. Dans le deuxième, on sera limité en richesse de l’application par les possibilités du Web.

Ce fut l’objet d’un précédent article sur notre blog: http://blog.octo.com/debat-web-apps-vs-natif/.

Entre ces deux approches se situe une offre assez fournie de solutions de développement multi-plateforme, proposées par des éditeurs proposant leurs propres plateformes d’exécution et leurs outils de développement.

Parmi celles-ci, nous nous sommes concentrés dans cet article sur PhoneGap et Titanium Mobile, qui sont aujourd’hui parmi les plus abouties et sont représentatives des deux principales approches de développement multi-plateforme: l’utilisation des moteurs de rendus Web pour PhoneGap, et la translation de code source vers la plateforme cible pour Titanium.
(Lire la suite…)

En présentant les tests fonctionnels automatisés chez un client la semaine dernière, plusieurs questions ont été soulevées. La principale était celle-ci:

- Pourquoi écrire ces tests FitNesse/GreenPepper alors que j’ai déjà des tests unitaires JUnit qui couvrent la même fonctionnalité ?

La question est justifiée. Voici quelques éléments de réponse, tirés de nos échanges sur les mailing-lists OCTO…

(Lire la suite…)

A moins de s’être limité à dessiner des ronds et des carrés avec Silverlight, vous avez sans doute déjà tenté d’utiliser un des templates de projets du Silverlight Toolkit permettant de faire des tests unitaires pour vos applications RIA! Plein de bonne volonté, vous vous êtes heurtés aux multiples inconvénients de cette solution :

• Framework de tests spécifique à Silverlight
• Obligation de lancer une application « conteneur » pour lancer vos tests
• Usabilité plus que discutable de cette même application
• Impossibilité d’utiliser une métrique comme la couverture de code
• et j’en passe…

N’abandonnez pas encore ! Je vous proposer ici une solution pour venir à bout de ces limitations… plus d’ excuses, vous pourrez tout tester …

la suite par ici en anglais…

Uniformiser vos environnements de développement – Gagner en productivité

Marre des merges galères pour cause de formateurs différents ?

Ce tip & trick est pour vous !

Le grand oubli dans l’industrialisation des développements est la base de données, cette chose monolithique et statique qui n’évolue pas aussi vite et aussi aisément que le code. Au même titre que l’intégration continue et les systèmes de gestion de version pour le code source, il existe des outils permettant de fluidifier et d’automatiser le travail autour du schéma physique des données. Travailler avec ces outils permet de compléter une démarche Agile en permettant une réactivité forte face aux changements.

Une première partie de cet article concernera les principes et pratiques autour de ces outils (partie « boss compliant »). La deuxième est orientée technique (partie « geek aware »).

(Lire la suite…)

Ce n’est pas la nouveauté de l’année mais Swing, bien que présent en entreprise, n’évolue que très peu. Le kit de développement offre nativement toujours aussi peu de composants évolués (tableaux triables…) même s’il faut avouer que certaines librairies commerciales compensent à merveille ces manques. Les APIs et le développement Swing est toujours aussi verbeux et finalement assez peu productif (de mon humble avis). Et ce n’est malheureusement pas les quelques JSR en stand by qui vont y changer quoique ce soit : Beans Binding est au statut inactif, Beans Validation, drafté en 2008 n’est toujours pas inclus dans le JDK (peut-être pour la version 7 ?) et la JSR 296 (qui définit au travers de 4 callback le cycle de vie standard d’une application) ne représente pas non plus la plus importante des améliorations qu’ait connu un framework (si si je vous jure j’aime Swing…)

Alors il est nécessaire de compenser ces manques…
(Lire la suite…)

[MAJ 17/03] Les slides de la session sont désormais disponibles à la fin de cet article.

Nous serons présent le 17 mars 2010 au salon Solutions Linux. J’aurai le plaisir d’y co-animer une session avec Benoît Lafontaine sur l’industrialisation des développements Java.

Qu’entendons nous par industrialisation ? Principalement 3 activités :

• l’intégration continue. Nous commencerons par à un retour sur l’état de l’art de cette pratique agile aujourd’hui largement démocratisée, puis nous verrons comment faire face aux nouveaux défis rencontrés : réduction du temps de build, constructions d’applications profilées par environnement, build distribué ou encore build incassable.
• le développement piloté par les tests. Depuis 4 ans, les outils de tests fonctionnels automatisés comme FitNesse s’efforcent de remettre le besoin et les maitrises d’ouvrage au coeur du développement logiciel. Nous ferons le bilan sur ces outils et balayerons les perspectives offertes par de nouvelles approches et de nouveaux types d’outils (BDD).
• mesure continue de la qualité. Nous verrons comment utiliser la mesure de la qualité comme une dynamique d’amélioration continue et comment en éviter les dérives comme le « flicage ».

(Lire la suite…)

Octo a récemment participé à la réalisation de l’application iNomineo pour iPhone (cf  OCTO Technology accompagne Generali sur l’iPhone ) :

Pourquoi avons nous mis en place une usine de développement (UDD) suite à ce projet ? A première vue, cela soulève plusieurs questions :

• La mise en place d’une UDD relève d’une problématique d’industrialisation : comment rendre plus productif un process que l’on maîtrise. Alors qu’un projet iPhone évoque plutôt l’innovation : un langage peu connu, de nouveaux outils, une nouvelle plateforme.

• Une UDD a pour vocation de simplifier le travail d’intégration entre les différents développeurs : plus ceux-ci sont nombreux, plus l’UDD se révèle payante. Or nous n’étions que 3 développeurs sur ce projet, on aurait tendance à penser que l’on peut gérer cet effort d’intégration « à la main ».

• L’UDD a également pour rôle d’automatiser l’exécution des tests, or une des particularités d’une application iPhone c’est la prédominance de l’interface graphique (réputée couteuse et compliquée à tester), de plus quels outils peut-on utiliser ?

• Pour finir, l’iPhone souffre encore de l’image du jeune étudiant faisant fortune sur l’appstore : ce type de projet véhicule pour certains une image d’amateurisme, « c’est un travail à confier à un stagiaire ».

Pourtant l’expérience nous a montré qu’une UDD et la pratique des tests unitaires apportent des solutions à des problèmes récurrents sur le projet.

De plus, la mise en place d’une UDD avec une couverture de test conséquente et les métriques associées sont un moyen d’apporter un gage de qualité et de professionnalisme à un projet iPhone.

Dans cet article, nous couvrirons les raisons concrètes qui nous ont poussé à le faire, et comment nous y sommes parvenus.

Dans un prochain article, nous verrons quelles pratiques de test mettre en place sur un projet iPhone (les outils, les méthodes, les bonnes pratiques).

(Lire la suite…)

Les méthodes agiles recommandent la colocalisation des acteurs (i.e. une localisation physique dans un même bureau) pour une meilleure communication, une meilleure collaboration et globalement une équipe ou un processus projet plus performants. Par exemple Ken Schwaber dans The Enterprise and Scrum :

« High-bandwidth communication is one of the core practices of Scrum… The best communication is face to face, with communications occurring through facial expression, body language, intonation, and words. »

Que disent les sciences de ce sujet aujourd’hui âprement discuté dans la communauté agile et ô combien toujours délicat à mettre en œuvre dans les faits ?
(Lire la suite…)

Dans un projet d’entreprise, il est important de vérifier continuellement la non-régression du produit réalisé. Au même titre que les tests unitaires, les tests d’acceptance font partie intégrante du harnais de tests à mettre en place sur un projet. FitNesse est une des solutions à ce besoin.

FitNesse / Slim

FitNesse dormait jusqu’à Juillet 2008. Mais il suffit de voir le rythme des releases depuis cette date, pour se rendre compte qu’il s’est réveillé ! Avec une nouvelle version presque tous les mois entre Juillet 2008 et Juillet 2009, et l’arrivée de Slim, on obtient un produit qui a sensiblement changé.

Mais avec une évolution aussi soudaine, on ne peut malheureusement pas éviter les effets de bords. Notamment dans le monde des outils qui tournaient autour de la sphère FitNesse. Par exemple, je recherchais un plugin Maven pour FitNesse. Mais la plupart des liens que me renvoie mon moteur de recherche préféré, pointe sur des outils incompatibles avec les nouvelles versions de FitNesse.

Il faut creuser un peu avant de trouver les perles rares…

(Lire la suite…)