Les Techdays sont l’occasion pour Microsoft de présenter chaque année à ses utilisateurs, du plus geek au plus boss, sa gamme de produits, d’outils sous forme de présentations, d’ateliers ou de retour d’expérience. Difficile de couvrir complètement cet événement tant l’offre de sessions est pléthorique, nous vous proposons donc, à travers une série de posts, sur les sessions que nous avions choisi et de partager avec vous notre ressenti.
Ce premier post revient plus particulièrement sur le lancement des nouveaux frameworks.
En mission chez un client, vous l’aiderez à optimiser ses pratiques de la technologie PHP : vous lui apporterez votre expertise technique et votre savoir-faire méthodologique pour animer leurs équipes de développement au quotidien et les aider à mieux développer, de façon plus robuste et évolutive. En interne, vous participerez à une communauté PHP OCTO dont l’objectif est double : vendre du PHP : industrialiser / faire de l’industriel en PHP, et faire « grandir les gens » : apprendre / améliorer son niveau en PHP et capitaliser sur les bonnes pratiques PHP.
Vous avez une expérience en architecture applicative avec une expertise PHP (au moins deux ans),
Vous savez/aimez parler de PHP et des bonnes pratiques,
Vous avez l’expérience de gestion de comptes ou de phase d’avant-vente,
Vous aimez ou avez envie de découvrir les méthodes Agiles…
OCTO Technology a le plaisir d’organiser une formation sur Domain Driven Design et son application dans la pratique les 8,9 et 10 mars 2010 à Paris.
Cette formation sera par donnée par Greg Young, grand spécialiste du sujet.
Vous pouvez retrouver plus d’informations sur cet intervenant de haut vol sur son blog ou au travers de son interview par Eric Evans.
Cette formation sera très ancrée dans la pratique, sur la plateforme que vous choisirez d’utiliser.
L’ensemble des informations (programme, tarif) est disponible ici.
J’ai eu le plaisir de donner une présentation sur le framework Wicket au JUG de Lausanne. Je tiens à remercier organisateurs et spectateurs pour leur accueil chaleureux ! Voici le support de la présentation :
Vous pouvez aussi télécharger les sources de l’application utilisée sur GitHub.
Avec l’ajout du support de Java sur la plateforme Google App Engine en avril 2009, l’étendue des possibilités offertes aux développeurs de tout bord s’est vue considérablement augmentée.
Il est notamment possible grâce à JRuby, l’implémentation en Java du fameux langage Ruby, de combiner la simplicité de ce langage avec la puissance du Cloud de Google pour développer rapidement des applications web évoluées et performantes.
Etant encore totalement novice dans le domaine il y a quelques mois, j’ai pris plaisir à découvrir ces technologies au cours de mon dernier projet. Je vous propose d’en faire vous aussi l’expérience à travers ce billet maintenant qu’elles ont atteint un niveau de maturité raisonnable.
Chez un client, j’ai du récemment vérifier que l’on pouvait facilement utiliser l’API SOAP de Crowd en Java. J’ai donc pour cela utiliser les 2 principaux framework de web service du monde Java Open source : CXF et Axis2. L’idée de cet article n’est pas de comparer fonctionnellement ces 2 frameworks, mais juste vous livrer les résultats numériques de ces essais.
Les ventes de smartphones sont des boosters d’ARPU (Average Revenue Per User): les smartphones, et en particulier l’iPhone, ont fait émerger de nouveaux usages spécifiques à la mobilité et liés aux nouvelles fonctionnalités offertes par ces téléphones intelligents (géolocalisation, connectivité sans fil, accéléromètre, …). Pour les opérateurs, la conséquence immédiate de la consommation de ces nouveaux usages est une explosion de l’usage data, qui leur permet de commercialiser des offres ‘Internet mobile illimité’ qui génèrent en moyenne 30% de revenus en plus que les offres classiques. C’est pourquoi ils se sont battus pour distribuer les smarphones. En France par exemple, l’ARPU moyen est de 39 € contre 86 € pour les utilisateurs d’iPhones (Source SiaConseil, ARCEP et INSEE 2009).
Pour autant, derrière l’engouement de la première heure, se profile un double danger pour les opérateurs : celui d’être réduit au rôle de fournisseur passif de « tuyau », le contenu leur échappant, et celui de perdre l’exclusivité du lien avec le client final. Car l’accès aux applications qui permettent les nouveaux usages ne passe pas nécessairement par l’opérateur. Avec l’appstore qui permet aux utilisateurs de télécharger en toute simplicité des applications, tout en étant facturé directement, Apple a créé un modèle économique solide duquel l’opérateur est totalement écarté. Et ce modèle tend à être reproduit par les autres constructeurs de smartphones _ RIM a lancé son propre kiosque à applications_ ou encore par Google avec l’Android Market.
Il est d’autant plus important pour les opérateurs de se repositionner sur le marché du contenu que les utilisateurs de smartphones pourraient s’avérer être des surconsommateurs de bande passante, avec pour conséquence la saturation des réseaux, ce qui mettrait à mal l’actuel modèle économique des opérateurs. Il leur faut donc trouver des relais de croissance dans la sphère smartphone. (Lire la suite…)
Je travaille sur un projet GWT depuis un peu plus d’un an (26K lignes de Java, à peu près autant de code en test, GWT 1.7.1). GWT 2 est sorti récemment, avec son lot de nouveautés. Plusieurs questions se posent donc :
Dois je migrer vers GWT 2 ? (ou « Qu’est ce que GWT 2 va apporter à mon projet ? »)
A-t-on vraiment le choix ?
Combien cela va t il me coûter ?
Comment vendre ce coût à ma MOA ?
Afin de répondre à ces questions ô combien importantes, j’ai donc fait quelques essais avec GWT 2. Voici le résultat.
Vendredi dernier s’est déroulé dans nos locaux l’OCTO day, une journée où nous nous sommes tous réunis dans les locaux pour améliorer notre vie à OCTO et réaliser des choses que nous ne faisions pas les autres jours. La seule contrainte étant de délivrer avant la fin de la journée !
Au final cet OCTO day a réellement dépassé nos espérances aussi bien pour le plaisir que nous y avons pris que pour la quantité et la variété de chantiers qui ont été menés à bien lors de cette journée !
Voici un compte rendu illustré de nos accomplissements !
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).
