L'avis de Nicolas B.

Aller au contenu | Aller au menu | Aller à la recherche

mercredi 23 mai 2012

Programmation désorientée objet

Ou comment petit à petit, ne plus vouloir crééer de classes...

Jeune et innocent

Lors de mes études universitaire, la programmation objet avait fortement le vent en poupe. Les langages procéduraux qui en était dépourvu comme PHP les intégraient doucement, même les langages fonctionnels y prenaient gout, comme ML avec par exemple OCAML. Bref, il semblait difficile de remettre en question les avantages du paradigme objet. C’est qu’on nous promettait le Graal. Meilleure modularité, regroupement du code logique, meilleur contrôle, façon de penser plus naturelle... Bref,à l’époque, sans (trop de) recul sur le métier, il semblait difficile de remettre tout ça en cause. Alors j’ai fait de l’objet. Et, c’est là peut être une impression tout a fait personnelle, j’ai commencé à me sentir mal à l’aise. Notamment quand j’ai commencé à regarder comment les objets étaient utilisés.

Les racines du mal

Prenons un exemple: une société développe un très beau concept autour des objets Foo, elle en développe de nombreuses variantes avec toujours la même interface, on a donc une interface Foo et des instances FooBar, Foobaz, FooWazaaa, etc. Elle rend le tout disponible, et ça correspond aux besoins de plein de monde. Comme souvent malheureusement, les fonctionnalités de l’objet Foo sont légèrement insuffisantes. On aimerait pouvoir manipuler l’objet Foo d’une certaine manière, mais ce n’est pas prévu. Hériter des classes pour étendre les objets seraient possible mais... quelques classes sont déclarées comme finales et surtout on serait obligé d’étendre toutes les sous classes, ça serait très pénible. Cherchant une solution, on propose finalement une classe utilitaire FooUtils, remplis de méthode statique qui vont permette d’ajouter ce qui manque. Et là, pour moi, c’est le drame. Tout d’abord, dans le concept objet, la notion de méthode statique m’a toujours semblé bancale. On a là une méthode qui n’est pas issue d’un objet, il s’agit en soit d’une entorse à une vue “pure” du concept. Mais admettons, le pire est à venir. Car maintenant, en fonction de la fonctionnalité de l’objet Foo que vous voudrez utilisé, vous aurez deux syntaxes très différentes : une orientée objet, où l’objet appelle la méthode, et une fonctionnelle, où vous appelez une méthode qui transforme un objet donné en paramètre. Oh bien sûr, on s’en sort. Mais je trouve ça horriblement pénible. Pour pallier à un système d’encapsulation du code dans un objet non adapté à la réutilisation, on se retrouve avec un mélange de concept pour faire le boulot. Je tiens à remercier les classes de la librairies collection de java et la classe java.util.Collections pour leur rôle de doublure lumière de la famille Foo et de la classe FooUtils.

Programmons en objet des services non objets

Si seulement le malaise s’arrêtait là. Seulement, comme beaucoup de développeurs Java, j’ai eu à faire aux merveilleux monde des EJB, qui repoussent ces limites du paradigme. Chez nos amis les EJB, un entity bean est principalement un ensemble de données, que l’on manipule à l’aide de session beans. Et la plupart des sessions beans ne sont pas dépendants d’un état, ils ne sont donc qu’un ensemble de fonctions. On est là dans un monde formidable. Où un énorme framework a accouché de class “données” et de fonctions. Comme en dehors du java, il y a aussi un monde, regardons ce que l’on fait avec nos langages. Prenons les webservices: on envoie des données, on reçoit une réponse. Sauf dans de rare cas où les données contiennent aussi un peu de logique, on est de nouveau dans un monde purement fonctionnel, dépourvu d’objet. Bref, nous manipulons un concept qui est principalement un frein au raisonnement, uniquement par habitude. Il s’agit moins de remettre en cause l’approche objet que sa prédominance et son implémentation dans les langages actuels. En fait, en cherchant un peu, on peut retrouver traces de discussions où l’on remet en cause l’approche objet des langages modernes, exception faite peut-être de Erlang, que je n’ai pas assez pratiqué pour pouvoir juger.

Et après?

Chez moi, ce constat est venu en reprenant la programmation fonctionnelle, plus précisémment Haskell. D’un seul coup, cette gêne est devenue évidente. Du coup, la prochaine fois, je vous parlerai de programmation fonctionnelle, de Haskell et de typeclasses, juste pour partager comment les choses pourraient être autrement.

mercredi 11 janvier 2012

Les fabuleuses legendes d'internet: La migration de free

Cher lecteur rebonjour et bonne année ! Nous ne nous étions pas parlé ici depuis longtemps. Ne te réjouis pas trop vite, on va parler internet et informatique. Ou alors réjouis toi, si c'est ton truc. Dans tous les cas on va essayer de pas faire trop chiant.

Cette histoire commence avec le lancement de Free Mobile, les internautes, par les boniments et le buzz alléchés, se jettent sur le site de Free et ce qui arrivent parfois arriva : pouf, un gros message d'erreur apparu en lieu et place du dit site. En général, dans ce genre de situation, les gens sont mécontents, c'est que attendre quelques jours pour souscrire c'est un peu comme si tu devais attendre 2012 pour essayer de changer de président: c'est long.

Le lendemain, le site fonctionne, je ne vais pas dire qu'il marche parce que les problèmes sont légions : certains ne peuvent pas s'enregistrer, d'autres voient leur RIB refusé alors qu'il paye leur abonnement ADSL à la même compagnie avec ce même compte, bref, c'est mieux, mais on tend le dos en attendant l'appréciation du maître de stage.

Pendant ce temps là, la rumeur enfle sur twitter et finis par être reprise par le journal du geek : si ça fonctionne c'est parce que dans la nuit, Free a passé son site de Java à PHP. Certes, si tu n'es pas informaticien, cette phrase semble anodine. Si tu es un bon informaticien, elle te fera sourciller, si tu es un informaticien bovin fan de PHP, elle te fera reprendre l'info la bave au lèvres, en entonnant une messe dont le final est "PHP vaincra, nous aurons la peau de Java".

Peite séance d'explication. Tout d'abord pour les non informaticiens. Il existe différents langage de programmation, la plupart permettent de faire les même choses plus ou moins facilement, plus ou moins différemment (tiens, un jour peut être que je vous ferai un billet sur l'expressivité des langages de programmation, vous serez pendu à mes mots, j'en suis sûr). Les informaticiens ont souvent leur petit préféré, ce qui chez certain, leurs font oublier que le principal atout pour qu'un langage soit bon, c'est que celui qui l'utilise ait une capacité cognitive supérieure à celle d'un militant en période électorale. Ces personnes fan de leur langage ont en général un meilleur ennemi. C'est un peu comme au foot, pour les marques de téléphones, pour les batailles de clocher, pour les partis politiques, pour la marque de céréales du petit déjeuner, bref, pour tous les trucs ou tu peux faire un choix. Chez les fans de PHP, ce langage ennemi souvent, c'est Java. C'est principalement dû au fait que les deux langages sont populaires et qu'ils ont des approches très différentes de la programmation.

Maintenant que tu saisis un peu mieux le réflexe pavlovien de quelques informaticiens à oeillères, regardons un peu mieux pourquoi ceux-ci auraient mieux fait d'utiliser leur cerveau pour comprendre qu'il valait mieux se taire. Tout d'abord, aussi bon que soit un langage, cette migration en une nuit semble difficile. Free n'est pas le marchand de pistache du quartier est doit donc avoir, surtout en cette période, un nombre de visiteurs simultanés que lui envierait la plus délurée des nymphomanes. Par conséquent, on peut se douter que l'infrastructure qui fait tourné un tel site, Free ne se contente pas d'une seule machine. Une application PHP et une application Java ne fonctionnant pas sur les mêmes architectures logicielles, cette migration impliquerait non seulement de refaire le code de l'application mais également de modifier tout l'environnement existant. Le tout en une nuit, dans une période critique. Cela s'apparente au démineur qui, voyant le gros compte à rebours digital d'une bombe approcher le 0, décide que le plus simple est certainement d'arracher tous les fils.

Mais admettons que cela soit possible, est entrons donc dans un monde parallèle, où le bon sens nous a donc définitivement quitté. La prochaine question est qui a donc fait cette nouvelle version ? C'est que, comme on l'a expliqué, l'architecture pour ce genre de site est complexe. Il est donc conseillé d'avoir une très bonne expérience dans les technologies que l'on utilise. Free a donc soit fait travailler deux équipes différentes pour les deux version (une de spécialiste Java, une de spécialiste PHP), soit la même équipe a fait une version dans une technologie qu'elle ne maîtrise pas du tout. Dans le premier cas, je pense que la première équipe peut dès maintenant mettre son CV à jour en évitant de mettre en avant son expérience en Java chez Free. Dans le second cas, c'est juste le chef de projet que l'on peut pendre par les tripes à un croc de boucher rouillé. Dans tous les cas, on entre ici dans un nouveau monde parallèle, basé sur le précédent avec en plus de la drogue dure gratuite et à volonté.

Dans ce nouveau monde prenons donc un rail de coke et analysons sereinement la situation. Free se fait chier à lancer un site utilisant des technologies Java et voyant que ça ne marche pas, refait tout dans la nuit en PHP (avec les mêmes gens ou une autre équipe, peu importe) ce qui lui sauve la mise. Conclusion normale d'un informaticien: cette boite fait n'importe quoi. Conclusion d'un fan de PHP : "haaaa c'est la preuve que PHP est super mieux que Java" (ajouté ici un filet de bave et un rire bête). Puisque suivant ce dernier raisonnement, le langage est le seul responsable (l'informaticien servant juste de relais), regardons alors la réaction des utilisateurs à ce messie numérique. Et là, c'est le carnage : des identifiants free refusés, des RIB rejetés alors que Free les connais déjà, des parties toujours inaccessibles, bref, le messi numérique a une putain de gastro. La démonstration faite par les fan de PHP devient alors : "Regardé, quand on sait pas faire un truc qui supporte la charge en Java, on peut faire un truc bancal en PHP à la place". Oui, comme soutien à son langage préféré, on peut faire mieux.

Que s'est-il passé exactement ? J'avoue que je n'en sais rien. La migration en une nuit ne me semble pas crédible ou sérieuse et, si elle l'est, elle me donnerait envie de rester assez éloigné de free. De plus, je n'ai pas regardé suffisamment en détail le site avant et après pour affirmer s'il y a eu ou non des changements entre les deux versions et si oui, lesquels. Le problème c'est que personne n'a d'éléments factuels. Comme trop souvent, on a fait enfler une rumeur sans même se demander si elle était crédible.

mercredi 13 mai 2009

Données, contexte, interactions… RDF ?

Dans un article très intéressant, Trygve Reenskaug and James O. Coplien propose un autre modèle d'architecture en alternative au très usé et très malmené modèle MVC (modèle, vue, contrôleur). Ce modèle se nomme DCI. D pour données, C pour contexte, I pour interactions. L'idée est de dire qu'un objet représentant une donnée n'a pas en soit à avoir de comportement évolué. Il doit être uniquement capable de présenter son état et de lui appliquer des modifications basiques. La plupart des modifications (ou interactions) avec ces objets dépendent alors de ce que l'on veut en faire, et n'ont pas nécessairement à être attachées à l'objet, elles dépendent du contexte dans le quel on se trouve.

Si l'on regarde dans les langages existants, ce modèle fait penser à la différentiation Entitée / Session que l'on retrouve dans les java beans, ou de manière plus simple et intuitive, à la notion de traits qui sont très à la mode actuellement dans les langages de programmation.

Maintenant, gardez tout cela dans un coin de votre tête et allons voir ce qui se passe du coté du web sémantique. Nous avons un ensemble d'informations sur des identifiants. Cet ensemble d'informations peut être vu comme un amas difforme, difficile à manipuler avec un haut niveau d'abstraction. On peut alors compter sur les ontologies pour regarder cet amas d'information différemment. L'ontologie permet de s'assurer que l'ensemble d'information que je détiens me permet de manipuler un objet plus clairement défini. Les ontologies définissent quelles informations sont disponibles, pas comment les modifier.

Revenons un instant à l'architecture DCI, le web sémantique, à travers les ontologies, me fournit des données qui correspondent exactement aux données du modèle DCI. Reste alors à définir, en fonction du contexte, quelles interactions sont possibles pour nos objets. Là, à ma connaissance, la galaxie de spécifications du web sémantique n'apporte pas de réponse, du moins pas de réponse autre que l'utilisation de ces objets dans un langage classique via un ORM. Par contre, l'utilisation du web sémantique et des ontologies permettrait encore une clarification à la correspondance entre données stockées et données représentées. En effet, dans la proposition de Reenskaug et Coplien, le contexte n'a d'impact que sur la façon dont on manipule les objets. Or, en fonction du contexte, la façon dont on voit les objets est également différente. Ainsi, en partant de mon ensemble de données brutes, je dois pouvoir, en fonction du contexte, choisir non seulement les interactions que je souhaite pour mes objets, mais également la représentation que je me faits de ceux ci.

J'essaierai d'illustrer cela prochainement, pour l'instant le temps manque.

mercredi 10 septembre 2008

C'est pas la taille qui compte

TinyURL est un service, parmi d'autres, permettant de créer un alias court d'une adresse internet. C’est vrai qu’une URL trop longue est pénible : affichée en clair, elle prend de la place, elle peut casser la mise en page d’une page HTML, elle utilise une grosse partie des caractères d’un message twitter, etc. Bref', il y a plein de bonnes raisons pour utiliser les réducteurs de taille (en disant ça, j’imagine les spams "shrink your URL" et je souris, il m’en faut peu, c’est le retour des vacances)…

Mais bordel de merde, est ce que les gens qui découvrent ce système peuvent aussi comprendre qu’il y a un tas de bonnes raisons pour ne pas utiliser ces services systématiquement ?! À chaque fois que vous avez la possibilité de faire un hyperlien propre, ou que la place n’est pas un problème, utilisez plutôt l’adresse initiale. Peut-être que je suis malade et que je devrais consulter, mais je n’aime pas du tout suivre un lien sans pouvoir voir où il m’emmène. C’est tout bête, mais il est plus facile de choisir de ne pas suivre un lien quand il est explicite, qu’on a un minimum de culture internet et pas envie de vomir : http://goatse.cz/ que quand il est caché derrière une tinyURL : http://tinyurl.com/jaydk (en plus, là, tinyURL rallonge le lien).

mercredi 6 août 2008

Perdre la main

Monday afternoon, after lunch, Nick came back from lunch to find out that he couldn’t get into his Gmail account. Further, he couldn’t get into anything that Google made (beside search) where his account credentials once worked. When attempting to log in, Nick got a single line message:

> Sorry, your account has been disabled. ?

[…]

Suddenly, Nick can’t access his Gmail account, can’t open Google Talk (our office IM app), can’t open Picasa where his family pictures are, can’t use his Google Docs

– Chris Brogan, When google owns you

Le cas de Nick est assez extrême et se termine bien (il a retrouvé l'accès à ces application dans l’après-midi) mais il illustre bien le risque que prennent beaucoup d'entre nous en utilisant des services tiers pour gérer ses informations personnelles. La facilité d’utilisation de ces services en ligne nous a fait oublié que nous n’étions plus maitre de nos informations. Chaque fois que j’utilise un service externe pour y placer des informations personnelles, je limite un peu plus mon indépendance.

La solution serait de prendre le temps de construire un espace personnel remplaçant ces services. Le principal problème alors reste la participation à l’aspect social développé par certains de ces sites. Il faut donc choisir des alternatives permettant de s'interfacer avec eux. Reste à savoir si avec cette restriction, on arrive encore à trouver des solutions ou si cela défini un espace pour innover.

lundi 26 mai 2008

Les sites mobiles pour firefox

Je viens de passer à firefox 3. C'est beau, ça semble diablement plus performant, mais ça nécessite un peu de boulot pour récupérer ses extensions. Parmi celles que j’ai perdu, Twitbin, et vu ma dépendance à Twitter, c'est impensable. Il fallait donc une solution rapide. J’ai trouvé, et j’ai même trouvé une solution qui me plait beaucoup plus que twitbin car plus générique.

L’explication en quelques étapes :

  1. Prenez un site web quelconque disposant d’une adresse pour la navigation depuis un mobile. Ici la version mobile de twitter. C'est fait pour des écrans qui ont une faible largeur, c’est parfait pour la suite.
  2. Rajoutez ce site à vos favoris firefox.
  3. Faites un petit clique droit sur le favoris ainsi créé, ouvrez le spropriétés du favoris et validez la petite cases permettant d’ouvrir ce favoris dans le panneau latéral.
  4. Ouvrez votre favoris, vous avez une sidebar pour twitter.

C'est certainement pas nouveau, mais je viens d ele découvrir. Et soudain, l’envie de me faire une page personnalisée pour faire mon propre panneau latéral en HTML me fait envie.

vendredi 28 mars 2008

User-generated functionnalities

Le modèle économique de nombreux sites web 2.0 consiste à utiliser la valeur du contenu produit par ses utilisateurs pour générés des revenus publicitaires. Cela représente un avantage énorme : les utilisateurs ont généralement un coût très faible pour le site, et je litote pas mal en disant ça.

Avec l’ouverture des API de développement aux utilisateurs, une étape supplémentaire est franchie. Les utilisateurs n’apportent plus seulement le contenu mais également les fonctionnalités. Certes, ce n’est pas nouveau, on retrouve là une des spécificités du monde du logiciel libres et des systèmes ouverts. Toutefois, certains sites, comme Twitter ou Seesmic (ce n'est pas une liste exhaustive) poussent ce principe très loin. Des fonctionnalités de base (comme la recherche) ne sont plus implémentées, laissées au bon vouloir d’utilisateurs passionnés. J’en ai fait la cruelle expérience en cherchant un moyen de trouver les références au si cher à celui dans twitter : j’ai été obligé de passé par un moteur de recherche tiers.

Il y a quelque chose qui me gène fortement dans cette pratique. Sans doute le prix de la gratuité des services qui a du mal à passer.

mercredi 26 mars 2008

URI sympas et web sémantique

Le W3C a publié il y a quelques jours une nouvelle version d’un document très intéressant sur les URI pour le web sémantique, qui ressemble à une version plus spécifique du très bon Cool URIs don’t change. On y retrouve des réflexions très intéressantes sur la négociation de contenu, dont je parlais il y a peu dans un billet sur RDFa. Une très bonne lecture pour ceux qui s'intéressent au web sémantique (qui a même réussi à infléchir sensiblement ma position sur le sujet).

jeudi 28 février 2008

RDFa était-il utile ?

Got lance une suite de billets sur RDFa, où il explique d’abord ce que c’est puis comment le mettre en pratique. À la fin de la première partie présentation, un paragraphe rejoint ma principale préoccupation sur le sujet :

Mais, je vous vois venir. Vous allez me répondre que c'est très joli, mais que la syntaxe est tout de même un poil complexe. Je ne peux pas vous donner tort. Mais, entre nous, n'est-ce-pas le but du Web dynamique et des CMS de générer le code HTML ? Toutes les données d'un CMS ne sont-elles pas parfaitement structurées dans une base de données ?

Je suis parfaitement d’accord avec lui. Allons même plus loin : le but de RDFa est de permettre l'extraction de donnée d’un document HTML, pour fournir normalement des données au format RDF. Très bonne idée… Mais Got et moi sommes d'accord, c'est à un programme de rajouter ces informations. Et s’il doit le faire, pourquoi ne pas le faire directement au format RDF ? La réponse usuelle, c’est que justement, on ne peut pas embarquer facilement le RDF dans du HTML. C’est vrai mais il est également vrai qu'avec HTTP, le client peut demander au serveur le format qu’il préfère (en précisant le format désiré dans le champ Accept, d'une requête). Ainsi, un serveur pourrait fournir pour une même page, soit les données au format HTML, soit les données au format RDF, soit dans tout autre format, y compris du HTML avec du RDFa dedans (beurk).

Quelle différence ? Peu et beaucoup à la fois. Tout d’abord, on évite d’alourdir le document de base. Certes, ce n’est que quelques données supplémentaires, mais ce raisonnement vaut pour plein de choses : javascript, feuilles de style, pour tout cela, la séparation est préférable, pourquoi les données sémantiques devraient elles avoir un traitement particulier ? Ensuite, on évite de se mordre la queue : RDF fournit des informations sémantique d’un document HTML qui contient des informations sémantiques au format RDFa. Cette phrase vous semble redondante et absurde ? C’est que vous devriez également trouver RDFa absurde.

mardi 26 février 2008

Programmer avec style

Après avoir pris le temps de trouver Smalltalk élégant, je me suis mis en tête de lire un peu de documentation sur le sujet. J'ai trouvé en ligne le très bon "Smalltalk with Style" qui doit être lu absolument, non seulement par ceux qui s'intéresse à Smalltalk, mais également par tous ceux qui aiment écrire du code proprement. Ce livre est une mine de bons conseils pour formater son code et ses commentaires. Il y a certes beaucoup de choses évidentes mais c'est toujours bon de faire un bref rappel. Bien sûr, les exemples peuvent être déroutants pour ceux qui ne connaissent pas Smalltalk mais comme ce langage est vraiment très agréable à lire quand on en connait les bases, ça vaut aussi le coup de prendre le temps de lire un didacticiel le concernant.