scopyleft

Mix-IT 2013

Nous étions en force à Lyon pour rencontrer des personnes combinant une approche agile et technique aux profils très variés. Cette mixité se retrouve dans le programme sur 2 jours et dans les échanges que nous avons pu avoir, il était même possible de slalomer entre les interventions Java grâce aux 3 salles de conférences + 2 d'ateliers en parallèle.

Ces 2 jours nous auront permis :

• d'avoir des retours d'expériences suite aux pratiques agiles dans le monde réel ;
• de réfléchir à l'influence des objectifs que l'on soumet à une équipe ;
• d'avoir un aperçu du web de demain avec les Web Components, AngularJS ou Dart ;
• de discuter d'API HTTP et Hypermedia ;
• d'être confrontés aux problèmes de flux tendus déficients dans le domaine de la restauration ;
• de se faire une virée nocturne en vélo sur les quais lyonnais ;
• d'essayer ElasticSearch sans pouvoir aller jusqu'au facettes malheureusement ;
• d'avoir une démonstration de l'approche produit en version anglo-saxonne chez GitHub ;
• de découvrir le robot NAO et les possibilités offertes en terme de programmation à partir du langage Python !

Beaucoup d'échanges et de rencontres pendant et entre ces sessions, le tout en restant à taille relativement humaine, tout ce que l'on aime.

Du code acentré

Nous nous sommes retirés pendant 3 jours dans les Pyrénées en novembre dernier pour travailler ensemble sur un projet en mode mandala (les sources furent détruites à la fin). Ce fut l'occasion de tenter une approche non centralisée de notre travail. L’utilisation qui est faite aujourd’hui des Distributed Concurrent Versions System (DCVS) se focalise presque exclusivement sur une approche centralisée (bien souvent sur GitHub ou Bitbucket).

Or, il est tout à fait possible d’avoir des échanges de code locaux de pair à pair sans qu’il n’y ait de centre, chaque machine pouvant avoir une version différente du projet à différents stades de développement et incluant des fonctionnalités différentes. Cela peut poser problème dans un contexte de release, mais ce n’était pas notre objectif principal (et ça reste possible à partir du moment où une machine récupère l’intégralité des fonctionnalités développées sur les autres).

Pour mettre en œuvre par la pratique ces concepts, nous avons choisi Git — mais nous aurions pu tout aussi bien utiliser Mercurial, qui offre le même type de fonctionnalités.

Notre premier essai a été de tenter de passer par les dossiers partagés d’OS X mais Git ne permet malheureusement pas d’utiliser le protocole afp://, je me suis alors souvenu d’avoir déjà eu à servir mon dépôt Mercurial localement avec la commande serve et je me suis mis en quête de trouver la même commande en Git qui est la suivante :

$ git daemon --reuseaddr --base-path=. --export-all

qu’il est possible de mettre en alias dans son fichier de configuration global ~/.gitconfig :

[alias]
    serve = !git daemon --reuseaddr --base-path=. --export-all ./.git

Notez qu’il est possible d’ajouter l’option --verbose pour voir qui récupère quoi sur sa machine.

Une fois le dépôt servi par une machine source, il est possible de s’y connecter directement via son adresse IP, mais nous avons préféré utiliser la résolution du nom de la machine, ce qui s’avère plus pérenne si vous êtes en DHCP (il faut être sur le même réseau pour la résolution DNS, attention aux noms d’hôtes aussi ! La commande ping est votre amie pour tester ça) :

$ git clone git://nom_machine_source/

Ne surtout pas oublier le / final sinon la récupération ne pourra pas être effectuée. À partir de là, il est possible d’effectuer l’intégralité des commandes Git. Il peut être utile d’ajouter les machines concernées en remote pour éviter d’avoir à re-taper l’URL à chaque fois :

$ git remote add nom_source git://nom_machine_source/

Une fois cela mis en place, le workflow de travail est un peu différent puisqu’il n’y a jamais de push, chaque développeur récupérant ce dont il a besoin chez les autres pour avancer sans rien leur imposer.

L’expérience s’est avérée relativement concluante une fois les différentes commandes ci-dessus acquises, et permettra de mettre en pratique un tel workflow lors d’un futur /dev/fort où la connexion est par définition limitée.

Qu’il est bon d’enfin utiliser un DCVS à bon escient !

Innovation sociale

L'innovation sociale consiste à « répondre à des besoins sociaux et environnementaux mal ou peu satisfaits par des solutions entrepreneuriales ».

Les entreprises sociales sont des entreprises à finalité sociale, sociétale ou environnementale et à lucrativité limitée. Elles cherchent à associer leurs parties prenantes à leur gouvernance.

Nous avons été retenus en début d'année par ALteR'Incub pour une période de pré-incubation de 6 mois relative à l'activité sociale et solidaire que nous souhaitons développer au sein de scopyleft. Celle-ci sera suivie dans le meilleur des cas d'une période d'incubation d'un an au cours de laquelle le projet sera concrétisé.

Cet accompagnement nous permet de nous poser beaucoup de questions relatives au modèle économique de cette activité et aux différents partenariats et interlocuteurs que l'on peut avoir sur ce type de projet. Il nous permet également de rencontrer des « co-incubés » aux projets très intéressants qui enrichissent notre propre vision du produit proposé par leurs regards néophytes et citoyens.

Ce projet est une expérience nouvelle qui nous permet de mettre en pratique des outils de concertation propres aux méthodes Agiles sur une population non technique en impliquant tous les acteurs pouvant intervenir dans la mise en place de la plateforme et son utilisation. Il nous permet de mieux définir nos activités et de les rendre compréhensibles par tout un chacun.

L'objet même de la plateforme sera détaillé dans un prochain billet.

Applications mobile : Web vs. Natif

Nous avons récemment eu à enrichir une application Web d’intranet afin d’aménager un accès pour des utilisateurs de mobiles (parc de périphériques connu et contrôlé). Trois approches étaient possibles :

• l’utilisation d’un responsive design sur la version Web pour réutiliser l’existant mais cela posait des problèmes de performances (chargement inutile de l’intégralité du HTML et des ressources de la page, mise en cache complexe) ;
• l’utilisation de code natif — ou d’un intermédiaire comme Titanium pour bénéficier de la réactivité et des APIs — mais cela nous liait trop fortement aux plateformes propriétaires ;
• l’utilisation d’une version Web dédiée aux périphériques à petits écrans, c’est celle pour laquelle nous avons opté en misant sur la pérennité et l’évolutivité d’une telle approche.

Rapidement, nous avons été confrontés à plusieurs problèmes que nous souhaitions partager avec vous :

La réactivité

C’était la grande inconnue et nous avons rapidement opté pour une architecture permettant de servir les données en JSON via une API HTTP pour alimenter une application JavaScript en Backbone.js avec la possibilité de mettre en cache les données côté client (utile lorsque la connexion est aléatoire !).

La latence perceptible au tap sur un périphérique iOS pour afficher une page Web s’explique par une préconisation Apple à à patienter 300ms avant de prendre en compte l’action de l’utilisateur ; cela nous semblait trop important compte-tenu de la cible. Des solutions techniques comme celle proposée par la bilbliothèque FastClick permettent heureusement de s’affranchir d’une telle contrainte.

Côté performance et réactivité des interfaces, si nous (et notre client) sommes satisfaits des résultats obtenus vis à vis des usages cibles sur leur parc de machines (iPhone 5, iPad et machine Android récentes), il semble pour autant que cela ne soit malheureusement pas le cas pour tout le monde ; tout dépendra donc du type d’usages auxquels vous destinez votre application.

Le choix du framework Web mobile

Parmi l’offre pléthorique d’outils Open Source à disposition sur ce créneau en plein essor, nous avons évalué trois frameworks de développement Web mobile : iUI, jQT et jquery-mobile.

iUI

iUI est le moins complet et ne semble plus vraiment maintenu, il est néanmoins léger et très efficace pour un site basique. C’est par ailleurs le plus performant sur les animations de transition.

jQT

jQT est un projet relativement actif, mais qui manque cruellement de documentation et nous a posé de nombreux problèmes quand à la gestion des évènements spécifiques à une utilisation mobile. De plus, il est très difficile d’étendre ou de hooker l’API proposée, ce qui s’est avéré rhédibitoire eu égard aux besoins du projet.

jquery-mobile

jquery-mobile nous a finalement donné entière satisfaction, avec la possibilité de réaliser un thème rapidement, disposant d’une bonne extensibilité, la possibilité de débrayer tout ou partie des fonctionnalités de navigation intégrées (contrairement à jQT) et l’intégration native des fonctionnalités de FastClick.

Le catalogue de widgets est relativement complet, leur mise en place et leur configuration est rendue très aisée par l’utilisation des data attributes (même si l’on peut toutefois questionner la pertinence de les utiliser pour gérer la présentation par exemple…)

Appification et contextes

Sur iOS, il est possible de placer un site — ou plutôt une URL — en tant que raccourci d’application sur l’écran d’accueil ; celui-ci peut alors disposer d’une icône dédiée et d’un écran d’attente de chargement au lancement, tout en masquant l’interface utilisateur de Safari.

Si cette solution nous semblait satisfaisante dans un premier temps, elle s’est vite révélée problématique lors des changements de contextes :

• l’ouverture d’un lien externe au sein de l’application ouvre inévitablement un nouvel onglet dans Safari ;
• la sortie vers un lecteur PDF ne permettant pas de retrouver l’application dans l’état où elle avait été quittée (ce qui est plutôt gênant pour un moteur de recherche)

Sous Android, la situation est à peine meilleure avec Chrome, puisqu’un clic sur un lien vers un document PDF entraîne son téléchargement en tâche de fond… Ne reste qu’une obscure notification une fois l’opération effectuée, nécessitant une action utilisateur pour le visionner.

Dans les deux cas, l’utilisateur lambda risque vraisemblablement d’être a minima perdu ou plus vraisembalement agacé par ces modes de fonctionnement.

Au final, si certaines limites nous semblent justifiées, d’autres laissent à penser que les plateformes ont tout à gagner (environ 30% en fait) à encourager le développement d’applications natives en conservant de manière stratégique ces freins au développement d’applications Web.

Acte de naissance

« Ce n’est pas un signe de bonne santé que d’être bien adapté à une société profondément malade » — Krishnamurti

Le projet de monter une coopérative de développement Web avait germé il y a bien longtemps dans nos cerveaux épris d’équité et de démocratie solidaire ; nous sommes heureux de donner concrètement vie à cette idée en créant un outil de travail pleinement conforme à nos valeurs. Oui, nous venons de créer la boîte dont nous avons toujours rêvé.

Scopyleft est empreinte de nos convictions parmi les plus insensées ; celles de partager, d’échanger, de redistribuer, de s’ouvrir le plus complètement possible, de se donner les moyens de s’épanouir et d’être heureux dans l’exercice de notre activité professionnelle. Puisqu’on vous dit qu’on est fous.

Vaste programme

Évidemment, tout n’a pas été forcément facile durant cette phase de création. Et contre toute attente, les démarches administratives n’ont pas été les obstacles les plus difficiles à surmonter, malgré leur pénibilité. Le plus stimulant — bien qu’éprouvant — a été de confronter, valider et accorder nos principes et valeurs respectifs.

Ce travail de plusieurs mois, bien plus fastidieux qu’il peut n’y paraître de prime abord,  nous a permis d’engager de nombreuses discussions, de soulever tout autant d’interrogations et de prendre le temps d’y répondre, ensemble. Ces efforts ont débouché sur l’établissement d’un manifeste, dont la version la plus épurée accueille aujourd’hui les visiteurs sur le site. Une version plus détaillée de ce manifeste a été également ajoutée en préambule des statuts de la société.

Transparence

Si vous avez cliqué sur le lien précédent, vous vous êtes probablement rendu compte que nous avons mis à disposition les statuts de Scopyleft publiquement sur Github, ainsi que tout un ensemble de ressources liées à la constitution, mais aussi à nos encours quotidiens (excepté les échanges confidentiels avec nos clients bien entendu),  nos rétrospectives ou encore notre comptabilité !

Nous projetons de rédiger à terme des notices explicatives pour chacun des types de document que nous libérons et de régulièrement publier ici-même le fruit de nos expérimentations à ce sujet.

Bien évidemment, vous êtes encouragés à contribuer et vous approprier ces documents, leur amélioration collective étant l’un des principaux objectifs de cette libération.

Aspirations

Nous souhaitons avant tout mettre nos compétences individuelles et collectives au service de projets Web et mobiles utiles au plus grand nombre.

Nous avons à notre disposition une très bonne connaissance du Web en général et de technologies comme Python, Django et Javascript en particulier.

Nous abordons chaque nouveau projet avec un regard neuf et débutant. Nous prenons beaucoup de plaisir à échanger, à partager notre culture et nos valeurs en accompagnant partenaires et organisations dans leur transformation Agile ou vers le Lean thinking.

Nous n’attendons maintenant plus qu’une chose : concevoir et fabriquer de belles choses, avec vous.