eCommerce
Systèmes d'abonnement
Cours en ligne
Réservation en ligne
Guide touristique
Evènements
Communication d'entreprise
Créateurs de contenu
Click & Collect
Journaux
Radio
Ecoles et Universités
Spiritualité
Associations
Restaurant
Epicerie
Créez votre app sur-mesure
RESSOURCES LIEES AU PRODUIT
THEMATIQUES
TECHNOLOGIE
REVENDEURS D'APPS
À DÉCOUVRIR
GoodBarber aux AppDays 2016: Feature Template, Open Product ...
Ecrit par Muriel Santoni le
Crédits Philippe Barbosa
Pour la deuxième année consécutive, nous avons participé aux AppDays. En 2014, la question s'était posée, mais vu que les dates étaient difficilement compatibles avec notre participation au Web Summit de Dublin, nous avions laissé tomber. Ensuite, deux facteurs nous ont convaincus de participer à l'édition 2015: le feedback positif d'amis bloggeurs et le fait qu'avec l'arrêt de Le Web , il n'y avait plus en France de conférences qui nous donnaient envie de nous déplacer. Notre participation aux AppDays 2015 à été une expérience positive et nous avons décidé de renouveler l'expérience en 2016, avec comme objectif de proposer un retour d'expérience concernant le développement logiciel chez GoodBarber.
A chaque fois que nous en avons la possibilité, nous essayons aussi de vous faire profiter de la conférence à laquelle nous assistons. Pour les AppDays 2016, nous avons pu distribuer une poignée d'invitations à quelques reseller. On aurait bien voulu en offrir davantage, bien sûr, et les organisateurs ont eu la gentillesse de proposer un tarif préférentiel aux clients de GoodBarber qui n'ont pas pu obtenir d'invitation.
Mathieu, Dominique, Jérôme et Muriel ont fait le déplacement. Comme à chaque fois, nous avons été plus que ravis d’échanger avec les autres participants de cette édition, et évidemment de rencontrer nos clients sur place, qui nous ont fait des feedbacks sur notre produit. Mention spéciale pour Olivier Waubant de l’Atelier des Applis ainsi que Julie et Gregory de happyngood .
Mathieu, Dominique, Jérôme et Muriel ont fait le déplacement. Comme à chaque fois, nous avons été plus que ravis d’échanger avec les autres participants de cette édition, et évidemment de rencontrer nos clients sur place, qui nous ont fait des feedbacks sur notre produit. Mention spéciale pour Olivier Waubant de l’Atelier des Applis ainsi que Julie et Gregory de happyngood .
Le Feature Templating
Crédits Philippe Barbosa
Cette année, nous vous avons eu l'opportunité de présenter notre philosophie de développement au public averti des AppDays.
Au cours de l’aventure GoodBarber, nous avons été confrontés à différentes problématiques liées au passage du développement d’apps dans le cadre de prestations de service, à un développement plus industrialisé qui a donné naissance à GoodBarber comme vous le connaissez aujourd’hui.
Pendant notre conférence, nous sommes revenus sur le cheminement que nous avons suivi pour gérer cette transition avec un enjeu principal en tête: conserver un haut niveau de performance, en minimisant la complexité et le cout en maintenance quand le nombre de projets en production augmente de façon constante.
Au cours de l’aventure GoodBarber, nous avons été confrontés à différentes problématiques liées au passage du développement d’apps dans le cadre de prestations de service, à un développement plus industrialisé qui a donné naissance à GoodBarber comme vous le connaissez aujourd’hui.
Pendant notre conférence, nous sommes revenus sur le cheminement que nous avons suivi pour gérer cette transition avec un enjeu principal en tête: conserver un haut niveau de performance, en minimisant la complexité et le cout en maintenance quand le nombre de projets en production augmente de façon constante.
Cette problématique, nous l’avons solutionnée en modifiant notre approche en se basant sur deux constats:
- Deux applications distinctes ont souvent plus de similitudes qu’on ne le croit.
- Plus on a d’applications en production, plus la maintenance devient complexe dans le temps.
Une fois ces constats posés, il nous est apparu comme évident que nos efforts devaient se concentrer sur un investissement de départ. Que pouvons-faire aujourd'hui qui nous évitera un travail important demain ?
La logique instinctive que nous suivions jusqu’alors était de créer un coeur d’application spécifique à chaque projet mettant en musique des modules génériques réutilisables.
L’idée aura été d’inverser cette logique en créant un coeur d’app générique, commun à l’ensemble de nos projets. Sur ce noyau générique, des briques spécifiques (réutilisables ou non) viendraient se greffer pour répondre au besoin des clients. Voilà la nouvelle approche !
Nous avons bâti notre philosophie sur un compromis entre deux tendances extrêmes:
1/ L'utilisation de micro composants, permettant de proposer une palette commerciale très large mais nécessitant d'effectuer le travail de mise en commun de chacun de ces modules à chaque projet.
2/ La création du projet sous forme de "moule", où l'application est un seul et unique composant, permettant de gagner énormément de temps de développement, mais réduisant considérablement l'offre commerciale.
Notre ligne directrice réside dans l'idée de créer des composants de taille moyenne indépendants et responsable d’une fonctionnalité donnée.
Ce parti pris amène un certain nombre de contraintes au départ du projet, mais permet d’optimiser de façon conséquente la phase de maintenance.
Pour conserver la stabilité de nos projets, nous avons pris la décision de paramétrer ces composants non pas grâce à des lignes code, mais avec des paramètres descriptifs.
L’investissement de départ consiste donc à évaluer l’ensemble des scenarii possibles d’utilisation d’une fonctionnalité, afin d’y intégrer les paramètres de customisation nécéssaires.
On obtient donc un assemblage de briques testées de façon unitaire facilitant ainsi leur mise en commun.
Si vous souhaitez en savoir plus sur notre façon d’utiliser le Feature Templating voici la totalité de la conférence ici:
- Deux applications distinctes ont souvent plus de similitudes qu’on ne le croit.
- Plus on a d’applications en production, plus la maintenance devient complexe dans le temps.
Une fois ces constats posés, il nous est apparu comme évident que nos efforts devaient se concentrer sur un investissement de départ. Que pouvons-faire aujourd'hui qui nous évitera un travail important demain ?
La logique instinctive que nous suivions jusqu’alors était de créer un coeur d’application spécifique à chaque projet mettant en musique des modules génériques réutilisables.
L’idée aura été d’inverser cette logique en créant un coeur d’app générique, commun à l’ensemble de nos projets. Sur ce noyau générique, des briques spécifiques (réutilisables ou non) viendraient se greffer pour répondre au besoin des clients. Voilà la nouvelle approche !
Nous avons bâti notre philosophie sur un compromis entre deux tendances extrêmes:
1/ L'utilisation de micro composants, permettant de proposer une palette commerciale très large mais nécessitant d'effectuer le travail de mise en commun de chacun de ces modules à chaque projet.
2/ La création du projet sous forme de "moule", où l'application est un seul et unique composant, permettant de gagner énormément de temps de développement, mais réduisant considérablement l'offre commerciale.
Notre ligne directrice réside dans l'idée de créer des composants de taille moyenne indépendants et responsable d’une fonctionnalité donnée.
Ce parti pris amène un certain nombre de contraintes au départ du projet, mais permet d’optimiser de façon conséquente la phase de maintenance.
Pour conserver la stabilité de nos projets, nous avons pris la décision de paramétrer ces composants non pas grâce à des lignes code, mais avec des paramètres descriptifs.
L’investissement de départ consiste donc à évaluer l’ensemble des scenarii possibles d’utilisation d’une fonctionnalité, afin d’y intégrer les paramètres de customisation nécéssaires.
On obtient donc un assemblage de briques testées de façon unitaire facilitant ainsi leur mise en commun.
Si vous souhaitez en savoir plus sur notre façon d’utiliser le Feature Templating voici la totalité de la conférence ici:
GoodBarber OpenProduct, on en est où?
Crédits Philippe Barbosa
L’année dernière au cours des AppDays 2015, nous vous présentions un nouveau projet, GoodBarber Open Product . Cette année nous aura permis de récolter de nombreux feedbacks qui nous ont permis de repenser ce projet.
GoodBarber Open Product a été ouvert à un cercle de partenaires très proches, en version alpha. Nous sommes content de l'avoir fait car ce n'est qu'en se confrontant à la réalité qu'on peut valider la pertinence d'une idée. Nous sommes aussi conscients que bon nombre d'entre vous auraient bien voulus faire partie de cette expérimentation, mais GBOP restant un side project, nous n'avions pas assez de ressources à lui consacrer pour augmenter le nombre d'alpha testeurs.
Sur la papier, GBOP est une bonne idée mais en pratique, nous avons fait le constat que nous mettions trop de contrainte sur les développeurs. La façon dont GBOP avaient été pensé leur impose de développer nativement pour iOS, Android et le web. Ca représente une charge lourde ! De plus, tous les développeurs nous ont indiqué que ne plus pouvoir utiliser le back office de leur app pour déclencher les compilations était une perte de fluidité importante pour vendre des projets à leurs clients. En effet, dès qu'il y a un fork du moteur GoodBarber, la compilation du projet doit s'effectuer en dehors de l'environnement GB.
Nous avons donc décidé de repenser GoodBarber Open Product, et de lui appliquer en quelques sorte la philosophie "Feature Template" que nous avons évoquée plus haut. L'idée est de conserver un coeur natif très générique, maintenu par GoodBarber, et évoluant indépendamment des interconnexions qu'il entretient avec d'autres modules. Parmi ces modules, pourront figurer des briques développées par les développeurs en Angular JS. Il sera possible d'enrichir vos applications en utilisant un seul et même langage.
Nous pensons que c'est une meilleur approche pour permettre à des tiers d'enrichir le périmètre fonctionnel de GoodBarber. Nous devons maintenant trouver le temps pour effectuer les adaptations nécessaires afin que ça fonctionne. On a envie de le faire, soyez rassurés, et dès qu'on le peut, on y consacre un moment pour faire avancer ce projet.
Sur la papier, GBOP est une bonne idée mais en pratique, nous avons fait le constat que nous mettions trop de contrainte sur les développeurs. La façon dont GBOP avaient été pensé leur impose de développer nativement pour iOS, Android et le web. Ca représente une charge lourde ! De plus, tous les développeurs nous ont indiqué que ne plus pouvoir utiliser le back office de leur app pour déclencher les compilations était une perte de fluidité importante pour vendre des projets à leurs clients. En effet, dès qu'il y a un fork du moteur GoodBarber, la compilation du projet doit s'effectuer en dehors de l'environnement GB.
Nous avons donc décidé de repenser GoodBarber Open Product, et de lui appliquer en quelques sorte la philosophie "Feature Template" que nous avons évoquée plus haut. L'idée est de conserver un coeur natif très générique, maintenu par GoodBarber, et évoluant indépendamment des interconnexions qu'il entretient avec d'autres modules. Parmi ces modules, pourront figurer des briques développées par les développeurs en Angular JS. Il sera possible d'enrichir vos applications en utilisant un seul et même langage.
Nous pensons que c'est une meilleur approche pour permettre à des tiers d'enrichir le périmètre fonctionnel de GoodBarber. Nous devons maintenant trouver le temps pour effectuer les adaptations nécessaires afin que ça fonctionne. On a envie de le faire, soyez rassurés, et dès qu'on le peut, on y consacre un moment pour faire avancer ce projet.
See you soon
Cette édition des AppDays aura donc été très enrichissante pour nous, et nous aura permis à la fois de récolter des retours sur notre produits, mais aussi de délivrer nos feedbacks concernant l'industrie florissante des apps mobiles.
A bientôt !
A bientôt !