Archives par mot-clé : programmation

NoCode : Vraiment ?

La mode est au No Code.

En fait cela fait très longtemps qu’on parle de ça :

Philippe Desfray avait dans les années 90 sorti un livre : La fin de la programmation.

L’idée générale est que programmer est compliqué, mais qu’on peut « faire des choses » sans apprendre à programmer.

Si on pense à une application web « classique », on peut découper le travail en trois couches :

Interface : comment l’application s’affiche, comment sont structurés les pages, avec quels contenus et quelle présentation ?
Données : comment les données sont stockées, quelles sont les tables, les champs dans ces tables ?
Logique applicative : quelle est la logique de l’application, quels sont les choses à faire en fonction des actions des utilisateurs et des données stockées ?

Ces grosso modo ce qu’on appelle la modélisation MVC.

L’approche No Code doit couvrir ces trois sujets.

Pour la partie interface, il est clair que de bons outils de conception et d’édition WYSIWYG doivent pouvoir faire le job. C’est d’ailleurs ce que j’utilise en ce moment pour éditer ce billet 😉 dans WordPress, il y a plusieurs outils d’édition HTML intégrés.

Pour les données, ça se fait également très bien : au lieu d’apprendre à manipuler une base de données, une interface où l’on peut définir des tables et des champs fait très bien l’affaire.

Pour la partie logique : on peut imaginer des blocs avec des traits entre les blocs pour définir le comportement de l’application.

Alors, on est bon ? On peut vraiment réaliser une application sans coder ?

Oui on peut réaliser une application avec des outils comme Bubble.io sans écrire une ligne de code.

Mais au fond, qu’apporte le NoCode ?

Qui a dit que programmer c’était forcément ouvrir un éditeur de texte pour écrire le code ?

En fait, quand on défini la logique avec des blocs, on programme ! Simplement on utilise un langage et une représentation du langage qui n’est pas du texte, mais des boites, avec des boutons « DropDown ».

Et pour réaliser une vrai application, il va falloir passer du temps à apprendre ce langage.

Alors je comprends bien que pour un débutant en programmation, cela peut sembler plus facile de faire les choses dans un environnement graphique qu’avec un éditeur de texte.

Pourtant, la programmation a beaucoup évoluée, et les outils d’éditions sont aujourd’hui extrêmement puissants.

Au final, je trouve que les solutions de type Bubble.io sont très bien, mais que l’appellation NoCode est bullshit : ces solutions permettent de réaliser des applications, mais demandent du temps pour bien s’y mettre et bien comprendre la logique de la solution. Au final, on doit apprendre un langage, qui a l’avantage d’être très guidé graphiquement, mais qui a l’inconvénient d’être spécifique à une solution, et forcément moins puissant qu’un « vrai » langage de programmation.

Une autre piste est également possible : on peut utiliser l’IA pour générer automatiquement un programme, à partir d’une description du besoin exprimée en « français ». C’est une piste intéressante, mais j’en parlerai dans un autre billet ;).

Concours du « meilleur programmeur »

Je suis tombé sur cet évènement : le concours du meilleur programmeur.

Super initiative, qui permet de mettre en valeur le métier de développeur.

Le hic, c’est que le critère pour gagner c’est la vitesse… Et comme le dit fort justement l’un des vainqueurs, ce critère n’est pas le seul à prendre en compte.

Je me mets à la place des organisateurs : l’avantage de cette mesure, c’est qu’elle est objective et facile à mesurer.

Par contre, dans un « vrai » projet, la capacité à comprendre le besoin, à échanger avec ses collègues, a faire du code lisible et réutilisable, et donc à réduire la « dette », tout ces critères sont extrêmement important.

Je me demandais si l’objectif de ce concours ne traduit pas une vision déformé du métier ? Un bon développeur doit développer très vite, point barre.

J’en discutais ce midi avec l’équipe.

Il semble que le modèle Hackathon soit bien plus intéressant : ça prend en compte la créativité, la réponse à un besoin métier, …

Programmer

J’ai commencé dans la vie professionnelle comme développer.

« Programmateur » comme m’avait dit un gars rencontré à qui j’expliquais ce métier, il y a 25 ans 😉

programmateur

J’ai fait ce boulot à fond, pendant 10 ans, en 4D, C++, Java, plus tout un tas de langages que j’apprenais par plaisir (comme H d’Objecteering 😉 )

Puis j’ai bossé à la R&D de France Télécom, et paradoxalement, cela m’a éloigné de la programmation : il fallait monter les projets, les encadrer, les présenter… et j’ai perdu petit à petit le contact avec la programmation… en apparence. En fait, j’ai gardé un contact étroit avec cet « art », a lire beaucoup, discuter, tout regarder…

En montant Araok, je n’avais plus l’occasion de programmer, puisque le travail de consultant n’est clairement pas sur ce plan là.

Et puis je suis reparti sur une startup, dont je vous parlerais bientôt.

Au sein de la petite équipe, Thomas m’a « subtilement » convaincu que ça serait bien si je pouvais participer aux développements.

J’étais réticent au début, pensant qu’en tant que patron je ne pourrais pas tout faire.

Je travaillais avec les équipe en mode « coatching » : assi derrière eux, à regarder ensemble le code, à le commenter.

Et puis j’y suis allé.

oldrevolver

Et j’en suis très heureux 🙂

C’est, j’en suis convaincu, bien pour la boite.

Bien sûr cela me donne un surcroit de travail assez énorme.

Mais quel plaisir de « faire du légo ».

Finalement, j’ai arrêté de programmer pendant quasiment 15 ans.

On s’y remet très très vite 😉

Et les fondamentaux n’ont pas changés.

Bien sûr, il y a des nouveautés. Les outils pour développer (en Java en l’occurrence) ont fait d’énorme progrès. Par exemple, sous éclipse, la compilation est pratiquement transparente et les erreurs remontent en temps réel.

Et je dois encore creuser les annotations, et sans doute pleins de choses.

Et par rapport au job de patron, cela me semble tout à fait compatible. Je ne dis pas que ça durera comme ça longtemps, mais là, ou l’on construit les bases, cela rend il me semble les choses plus simples, plus naturelles.

Bon, je vous laisse, j’ai un programme sur le feux 😉

Programmation performante des serveurs web

La performance des serveurs web est un vrai sujet : on a besoin de sites qui répondent vite, pour vendre plus 😉

Et un serveur web peut être amené à répondre à « pleins » de requêtes simultannées.

On peut palier de manière superficielle à ces problèmes avec du cache. Bonne idée… mais les sites doivent de plus en plus être personnalisés, dynamiques. On peut donc « cacher » certaines ressources, mais pour les parties dynamiques, il faut faire autrement.

Au coeur des serveurs web se pose donc la question de la programmation parallèle : faire tourner plusieurs programmes en parallèles pour répondre en même temps à plusieurs utilisateurs.

Quand on programme avec les technologies « normales », on ne se rend pas compte de tout ça : c’est le serveur web qui gère, de manière transparente pour le programmeur. en fait, à chaque appel au serveur web, un fork est créé. Un fork, c’est une unité d’exécution indépendante. Chaque programme, pour chaque appel, est donc « dans son coin ».

C’est une bonne idée, parce que on masque ce problème technique… Sauf que la gestion des forks n’est pas très optimisée, et qu’à créer trop de forks, on fait rapidement tomber les serveurs.

D’ou l’idée de faire autrement. C’est en particulier ce que propose certains environnements, tel node.js, basés sur des serveurs webs spécifiques (autre que apache donc).

Dans ces environnements alternatifs, les différents programmes ne sont pas exécutés dans des forks indépendants.

Pour gérer la continuité entre les différentes fonction, le programmeur doit mettre en place des procédures de call back, …

Bref, je ne veux pas trop rentré dans les détails (d’ailleurs, je ne suis plus programmeur, j’atteints vite mes limites 😉 ).

Mon sentiment sur cette histoire :

Je comprends le chemin emprunté par ces solutions, c’est pragmatique : puisque les serveurs web rament avec les technos de forks, on descend d’un niveau, et on gère la programmation parallèle directement.

Mais sur le fond, je suis convaincu que la solution n’est pas là. Cela me semble complètement indispensable de masquer ces problématiques au programmeur, qui a déjà bien de quoi s’occuper. Et si la programmation parallèle n’est pas efficace, et bien il faut revoir l’architecture du système !

Javascript comme langage universel ?

Javascript est aujourd’hui très populaire pour une bonne raison : c’est le langage de programmation utilisé côté client : inclus dans les pages HTML et interprété par les navigateurs.

Mais Javascript est un langage informatique à part entière : rien n’empêche de l’utiliser pour d’autres choses.

On pourrait par exemple imaginer un environnement de développement de services web en Javascript…

Avantage : le programmeur ne doit apprendre qu’un seul langage de programmation : le Javascript. Ce langage serait utilisé côté client et côté serveur.

(Bon, le programmeur web doit toujours en plus bien maîtriser les différents langages du Web : HTML, CSS).

Cette approche existe, via plusieurs projets.

C’est par exemple ce que propose wakanda, framework de développement d’applications Web, basé sur le Javascript.

Pour info, ce Framework a pour initiateur 4D, et un certain Laurent Ribardière…

Voici un exemple de vidéo de présentation de l’outil :

Vous pourrez trouver toutes les vidéos sur l’outil ici.

Je n’ai pas testé l’outil, mais je pense que l’approche est intéressante.

Et vous ?

La courbe d’apprentissage pour coder

Au bout de combien de temps un programmeur est il vraiment au top dans un environnement de programmation donné ?

J’ai discuté de ce sujet avec Thomas.

Sa réponse, c’est que, quand on est un bon, on rentre assez vite dans un nouvel environnement.

Mais ce n’est qu’au bout de 2 ou 3 ans qu’on se sent vraiment au top.

D’après Thomas, la courbe est par paliers :

On est à 20% en 1 jour, 40% en 1 semaine, 60% en 1 mois. 80% en 1 an…

Les derniers 20% sont les plus longs !

Bon, ce que cela montre, c’est que si vous démarrez un projet sur une plate forme donnée, avec des équipes qui ne connaissent pas la technologie, vous allez perdre du temps, et l’équipe risque de faire des mauvais choix, par méconnaissance technique.

Alors, pour vous, c’est quoi la courbe d’apprentissage ?

Faire du logiciel, c’est une histoire de processus et de culture

Bon, je commence par expliquer que faire du logiciel, c’est de l’artisanat.

Et ensuite, je fait un billet ou je parle de processus ?

Oui, et les deux sont parfaitement compatibles !

Dans le billet précédent, j’explique, pour faire simple, que ce qui compte, avant tout, c’est la compétence des équipes. Chaque développeur doit être au top.

Après, il ne s’agit pas simplement de mettre X développeurs et d’attendre que le temps passe.

S’il est complètement fondamental de responsabiliser au maximum chaque développeur, il est également indispensable de mettre en place des méthodes, des processus très précis.

A ce titre, je vous conseille de regarder cette vidéo, qui explique les processus en place chez Facebook :

Facebook a un processus de mise à jour qui permet une mise en production tous les jours (!!!)

Donc, pour reprendre le titre :

La culture, c’est celle du dieu code.

Les processus, ce sont toutes ces méthodes et outils qui permettent d’automatiser au maximum la chaîne de production, tout en gardant le maximum de responsabilité entre les mains des développeurs.

Les méthodes à mettre en place sont bien sûr basées sur les méthodes agiles.

Les outils pour enrichir le CSS

Le CSS, c’est le langage qui permet de faire la mise en forme des pages web.

Cela permet de séparer le fond de la forme : le HTML contient le fond (le texte en particulier), et la décoration se fait via le CSS (la police, la taille, les bordures, …).

Bon, ça, c’est la théorie ;).

Dans la pratique, écrire une couche présentation en CSS est très technique, avec certaines parties plutôt répétitives et impossible à factoriser. Exemple : un site utilise une palette de couleurs. Impossible, en CSS, de définir des constantes avec ces codes couleurs.

Sinon, quand on n’arrive pas à faire ce qu’on veut en CSS, on le fait en Javascript.

Certains proposent d’améliorer tout ça avec des « méta langages » au dessus de CSS.

Exemples : SASS, LESS, …

SASS est une technologie côté serveur, on passe son code CSS enrichi dans la moulinette SASS et ça ressort un code CSS standard.

Si j’ai bien compris, LESS permet à peu près la même chose, avec une technologie Javascript, qui peut être côté client ou serveur.

Je ne rentrerais pas dans le détail, ce n’est pas l’objet de ce blog.

Je trouve que c’est une super bonne idée, que de proposer des langages, ou méta langages, qui permettent de programmer plus propre, plus court.

Mais cela ouvre la voie suivante :

Le code que j’écris n’est pas le code envoyé côté client.

Avantage : le code que j’écris est plus court, de meilleure qualité.

Inconvenient : ce que je vais débuggé n’est pas ce que j’ai écrit.

Mon avis, très clairement, est que c’est bien l’avenir !

Je pense depuis longtemps qu’à moyen terme, les langages du web n’ont pas vocation à être manipulés directement : ce sont, de mon point de vue, des langages de trop bas niveaux, avec des contraintes beaucoup trop complexes. Je pense bien sûr en particulier au problème de multi-terminal / multi navigateur.

Pour prendre une analogie, cela me fait penser au Postscript : c’est un langage de bas niveau pour piloter les imprimantes (ou autres interfaces d’ailleurs). Mais personne n’aurait l’idée d’écrire à la main du code Postscript !

J’ai donc la conviction qu’il devrait sortir des systèmes qui vont bien plus loin dans cette voie :

C’est une voie étroite, parce que, de mon point de vue, ces systèmes doivent être spécifiques web, alors que ce qu’on voit bien souvent, ce sont des frameworks génériques, et je ne crois pas du tout à cette approche.

C’est pour cela que je trouve les initiatives type LESS ou SASS particulièrement intéressantes : on améliore la qualité, de manière très spécifique au Web.

Et vous, qu’en pensez vous ?

Interface or not interface

Discussion passionnante, hier, avec Theodo.

On a pas mal échangé, en particulier sur les interfaces.

Bien sûr, côté Front Office, la question ne se pose pas : on se doit de proposer des interfaces faciles à utiliser, intuitives, rapides, …

Mais la question peut se poser côté back office.

Autant il est évident que certaines fonctions se font très bien via des interfaces, bien souvent web. Exemple : ajouter ou mettre à jour un produit dans le catalogue, ajouter une image, …

Mais pour certaines fonctions bien plus avancées, la question peut se poser.

Exemple : gestion des processus (workflow).

Est-ce vraiment une bonne idée que de développer un moteur graphique, pour représenter des choses aussi complexe que la modélisation des processus ?

Regardons les deux faces du sujet :

Si on a une interface :

L’interface donne un cadre, et elle permet de contrôler qu’on reste dans ce cadre.

Si on prend l’hypothèse que cette interface est bien faite, (hum hum), cela va permettre d’aider l’utilisateur à paramétrer le système.

Exemple intéressant de mon point de vue : le module de paramétrage des promos sur Magento.

Bon, l’exemple est certe particulier, parce qu’on voit bien que le résultat est finalement très très proche d’un programme…

Si on n’a pas d’interface :

Si on n’a pas d’interface, on va devoir utiliser un langage de description du sujet.

Ce langage peut être un langage hôte (PHP, Java, …) ou une syntaxe XML ou YAML, ou enfinun nouveau langage spécifique.

Si on prend un langage hôte, l’avantage est qu’on peut exprimer directement le problème sous forme d’un programme.

L’énorme avantage est qu’on n’aura pas à développer d’interface, complexe et très cher.

L’inconvénient est qu’on a probablement perdu 99% des utilisateurs métiers du back office. Pour modifier un élément, il faudra faire appel aux développeurs.

Alors, en synthèse ?

C’est un vrai sujet, il faut voir au cas par cas.

en fait, il y a toujours une limite, entre ce qu’on peut faire avec le back office, et ce qui doit être programmé. Certains systèmes essaient de repousser très loin la bascule vers la programmation, mais cette bascule existe toujours, et c’est pas prêt d’être fini : je ne crois absolument pas en « la fin de la programmation » avec la « programmation graphique » type UML… C’est un leurre marketing !

Quelques idées en vrac :

Si il s’agit d’une opération répétée régulièrement par les utilisateurs du back office, pas d’hésitation, il faudra une interface, et plus l’opération sera répétitive, et plus l’interface devra être soignée, pour faire gagner du temps aux équipes ;
Si l’interface s’avère très complexe, il arrive que la question prenne du sens : développer l’interface peut être très coûteux, et finalement pas rentable du tout, parce qu’en réalité, les utilisateurs n’utiliseront pas cette interface. Exemple : qui utilise un modeleur de processus d’un ETL ? Des informaticiens, qui iraient bien plus vite en programmant…
Si on doit « modeler » un problème via un langage de programmation, il est fondamental de développer des couches qui permettent d’exprimer le problème avec un bon niveau d’abstraction. C’est très important, parce que sinon, la mise à jour du programme sera compliqué, cher, … On ne fait pas toujours ce travaille, et c’est un vrai problème !

Programmer simplement pour iOS : Codify

La meilleure expérience, sur un terminal, reste de développer une application native.

Cela fait longtemps que je me dis qu’il manque une application, pour coder plus simplement sur iOS (iPhone, iPad, …).

C’est bien ce que propose Codify, avec un mélange de code « normal » (du texte) et des outils graphiques.

Le plus simple est de voir la vidéo pour comprendre ce que propose Codify :

Alors, qui sera le premier à utiliser un tel outil pour développer une application e-commerce ?