Mon appareil de développement mobile est toujours un Nexus 4

Et ça va rester comme ça pour un bon moment. Demandez-moi pourquoi ?

Quand j’ai acheté ce smartphone, en 2015, je n’avais jamais eu de smartphone auparavant et je n’avais pas prévu d’en acheter.
Le coup de pouce qui m’a poussé à franchir le pas ? Un projet de développement :)
J’avais signé avec une startup pour développer une application mobile. À l’époque, les navigateurs étaient suffisamment avancés pour que vous puissiez écrire une application HTML/JS et la faire fonctionner dans un navigateur mobile.
Les PWA n’existaient pas encore. Le seul truc pour gérer le mode hors-ligne c’était l’appcache – un pur cauchemar ; merci à la divinité du micro-processeur, ce machin a été déprécié 🙏
En outre, il était plus facile de brancher un smartphone au débogueur à distance de Google Chrome que d’installer tout Android Studio pour avoir un émulateur.

C’est la stratégie que j’ai choisie depuis.
Toujours opter pour la solution la plus simple, la plus légère et la plus minimaliste.
À l’époque, le Nexus 4 avait déjà 3 ans.
Aujourd’hui, il a 9 ans. C’est toujours mon principal outil de développement. Et je n’ai aucune intention de le changer dans un futur proche.

Cet objet est devenu l’emblème de pourquoi je fais ce que je fais, et de la manière dont je le fais.

Avoir un ordinateur dans sa poche, disponible à un prix aussi bas, vous donne – que vous soyez un employé rock star sur-payé d’une start-up à la mode, ou une mère de famille rurale en difficulté dans un pays en développement – beaucoup de pouvoir : communication, calcul, collecte de données sur votre environnement.
Et vous pouvez le faire pendant vos déplacements, sur un chantier, dans votre champ, au milieu de nulle part. Même sans prise de courant ni connexion au réseau.

Ces deux derniers points : pas de courant et pas de connexion sont les 2 conditions primordiales qui donnent un sens au travail que je fais.
Ce qui est drôle, c’est que je suis mon propre cobaye, vu le temps que je passe à naviguer.
Eh oui, on a beau en France être leader des constructeurs de bateaux de plaisance, lorsqu’on est en mer, il faut quand même tenir compte de la quantité limitée d’énergie électrique disponible. Et non, Internet n’existe pas en dehors d’une bande côtière de 20 miles nautiques de large.
C’est ironique que les yachties (bien qu’ils fassent partie des super-privilégiées) partagent les mêmes conditions – en ce qui concerne les appareils électroniques – que la plupart des pays en dehors de l’UE, des États-Unis et de l’Asie du Sud.

Cela dit, cette convergence de deux préoccupations différentes : 1) être autonome en mer, 2) fournir des logiciels utiles aux personnes éloignées des villes, a forgé mon opinion sur les logiciels –comment nous devrions les appréhender. Qu’est-ce qui est le plus utile ?
Parmi toutes les formes de logiciels possibles, je pense que les applications mobiles sont les plus prometteuses car elles peuvent être utilisées par ceux qui ne sont pas devant un ordinateur, et ils sont les plus nombreux.

Voici mon manifeste sur le logiciel :

• les gens n’accordent pas d’importance à leur « expérience » en utilisant une application.
  • ils ont besoin d’accomplir quelque chose
  • ils doivent le faire en utilisant le moins de temps possible et revenir à ce qu’ils étaient en train de faire
• les gens veulent être rassurés quant à ce qu’ils essaient de faire
  • que l’application ne vas pas « casser »
  • que l’application fera de son mieux pour détecter et réparer d’éventuelles erreurs
• l’application doit toujours montrer l’état dans lequel elle se trouve.
• les gens n’ont pas d’appareils luxueux. Ils possèdent ce qu’ils peuvent se permettre. Et le changement climatique va nous obliger à réutiliser autant que possible, surtout les appareils électroniques.
• l’application devrait fonctionner sur n’importe quel appareil, pas trop ancien. Ma base de référence est Android 4.4
• les applications doivent être légères à installer. Ne forcez pas votre utilisateur à télécharger 350Mo sur une connexion lente.
• les applications doivent prendre toutes les mesures nécessaires pour ne pas vider la batterie de l’utilisateur.

C’est pourquoi je ne développe que des PWA

La seule et unique exigence de mon côté est de minimiser autant que possible la quantité de code que l’utilisateur doit télécharger.
La conséquence est que je n’utilise aucun framework.

Ça résout deux autres trucs pénibles

1. En écrivant du JS « goût vanille », vous utilisez l’API du navigateur. Vous n’avez pas besoin d’apprendre, de vous adapter à un autre paradigme qu’un framework vous jettera à la figure. Vos erreurs sont les vôtres. Vous ne passez pas du temps à débugger ce que fait le framework et qui n’est pas documenté (évidemment)
2. Vous n’avez pas besoin de compiler. Pas d’outil de compilation à installer, configurer et déboguer lorsque la chaîne de compilation est cassé.
   Je fait qu’utiliser gzip au niveau du serveur

Plus j’écris du code, plus je m’interroge sur la pertinence des niveaux d’abstraction élevés

C’est probablement intéressant dans les cas d’équipes énormes de centaines de développeurs, de projets gigantesques pour de grandes entreprises et de grandes agences.
Ma pratique est beaucoup plus proche des métiers. La plupart du temps, je suis la seule développeuse, le seul contact avec les parties prenantes et les utilisateurs.
J’apprends le métier, je questionne les processus et je ne livre que ce qui est nécessaire et qui sera utilisé.
Les règles métier ne devraient pas être enterrées/découplées dans de multiples fichiers. On ne comprend pas de quoi il s’agit, il faut ouvrir 12 fichiers pour reconstituer la pile d’appel et saisir le sens de la tâche à accomplir.
Cela s’accorde bien avec le type d’application mobile que je développe.

Les PWA sont parfaites quand :

Des collaborateurs sur le terrain doivent collecter des données et les renvoyer à d’autres entités éloignées. Siège, chef d’équipe, organisation régionale…
Ils ont besoin d’un outil qui ne videra pas leur batterie, qui sera facile à utiliser, qui fonctionnera hors ligne et qui se synchronisera dès que la connectivité sera rétablie et suffisante.
Comme je l’ai dit, les PWA offrent tout cela par défaut.
Le HTML vous fournit directement tous les contrôles de formulaires dont vous avez besoin, et en plus c’est accessible de base.
Les service worker vous permettent de naviguer de page en page sans avoir à les charger depuis un serveur.
Pas besoin d’un framework/routeur obésiciel.
La base de donnée intégrée au navigateur (indexedDB) stockera toutes les données en attente d’être synchronisées avec un serveur distant. Oui, même les fichiers audio et vidéo.

C’est ce que nous devrions tous viser :

écrire des applications avec le moins de code possible, avec la notion constante de la quantité d’énergie et de ressources que notre code consomme.

Le changement climatique est là. Les technologies de l’information n’ont jamais tenu leur promesse de réduire les ressources nécessaires au fonctionnement de la société. Au contraire, elles ont été un moteur constant de l’augmentation des émissions de CO2.
Il n’y a pas de fatalité dans tout cela.

J’ai décidé il y a longtemps d’être rigoureuse dans mes choix en matière de technologie.

La technologie du web n’est peut-être pas « la plus proche du métal ». Mais elle est universelle, bien documentée, rétrocompatible. Et comme je l’ai dit, elle fonctionnera sur tout type d’appareil offrant un navigateur.