Ah internet, un endroit fabuleux où l’on peut trouver réponse à toutes ses questions. Mais encore faut-il avoir la question1, et une méthode pour y répondre.
Ce billet est un retour d’expérience sur un problème que j’ai eu à résoudre dans le cadre de mon travail sur une pile technologique à base de java.
-
Ceci est une subtile référence à H2G2 et sa Question sur l’Univers le Sens de la Vie et le Reste. ↩
Phase 1 : identifier le problème
Le titre peut vous paraître évident – et donc inutile – : pour résoudre un problème, encore faut-il l’identifier.
Pourtant, ce n’est pas aussi simple que cela et le problème qui m’a tenu n’était pas aussi bien identifié que cela au départ.
Le contexte
Je développe donc un outil qui permet d’étudier et de détecter les phishing sur les sites web tout en étant suffisamment avancé pour trouver quelle est la marque qui est attaquée par cet hameçonnage.
Cet outil est sensé se baser sur le machine learning mais par expérience, nous savons que certaines méthodes empiriques permettent, dans certains cas, d’être plus efficace.
Figure: pour ceux que ça intéresse, c’est comme ça qu’on définit l’efficacité d’une méthode.
Le machine learning se base énormément sur le principe d’extraction de feature (j’y peux rien, c’est le mot) et ce, peu importe si on utilise des classifieurs1 tels que SVM ou des algorithmes comme les arbres de décision.
Le but de notre outil est donc de mettre les uns à la suite des autres :
- des extracteurs de features ;
- des classifieurs ;
- des moyens pour choisir comme il se doit les classifieurs en fonction de la situation.
Et il est où le trou problème?
Bah en fait, le problème c’est de savoir comment on rend ça très souple. La méthode qu’on a choisit : on rend chaque méthode de classification instanciable dynamiquement en fonction d’un paramètre qu’on met dans un fichier de configuration.
Au début tout va bien : on n’a qu’une seule méthode de disponible alors on choisit d’utiliser l’introspection2 pour tout charger.
Rapidement, on veut que cette fonction soit configurable. Alors on crée des getter et des setter pour que l’introspection fonctionne.
Et puis on en arrive au moment où notre objet de classification dépend d’un modèle (cf le tuto sur SVM). Le truc ne peut plus du tout être mis dans le fichier de configuration.
Et là on commence à être dans une impasse, mais la grande question est : quelle est notre vrai problème?
- est-ce l’utilisation de l’introspection?
- est-ce le fait d’avoir choisi de rendre le système configurable dans un fichier?
- est-ce notre arbre de classe?
- est-ce le fait de vouloir instancier dynamiquement des objets qui dépendent d’objets qu’on n’a pas au début?
C’est là que parler à quelqu’un est salvateur. Si vous n’arrivez pas à expliquer un point de votre programme, il y a de forte chance que ça soit ça le problème. Si la personne (pour le coup ça marche moins bien avec une peluche) qui vous écoute vous pose une question, il mettra sûrement le doigt sur le problème. Mais dans mon cas c’est le simple fait d’expliquer à mon collègue en dessinant sur un tableau blanc que j’ai pu comprendre que mon problème était que je n’utilisais pas à bon escient notre injecteur de dépendance pour faire ce travail.
Phase 2 : trouver ce qu'on cherche
C’est probablement la partie la plus complexe. Notamment car elle requiert deux choses :
- on sait ce qu’on cherche ;
- on sait comment le chercher.
En effet, si on en croit M.Serre de l’Académie Française, l’arrivée d’Internet a surtout changé notre rapport à la connaissance : désormais, il ne suffit plus de connaître par coeur le savoir obtenu par nos ancêtre, il suffit de savoir le chercher sur les moteurs de recherche.
Si cela est si compliqué c’est probablement parce qu’ici, je n’avais justement pas les mots adéquat.
En effet, j’avais :
- un besoin : "instancier dynamiquement"
- deux contraintes : depuis un fichier de conf, en prenant en compte les dépendances créées durant l’exécution du logiciel
- une piste : utiliser l’injecteur HK2 pour qu’il crée les objets.
Et j’ai passé quelques – trop longues– heures à chercher comment je pouvais passer mon injecteur à la fabrique de classifieur, ou encore comment je pouvais utiliser des design pattern comme le "proxy" pour régler mon problème. Je n’ai rien trouvé, rien de rien.
J’ai donc décidé de poser la question sur zeste de savoir.
A ma grande joie, deux personnes ont décidé de s’abonner à mon sujet : ça devait donc être intéressant. Mais apparemment la réponse n’était pas si évidente que ça.
Je me suis donc armé de mon anglais et j’ai posé la même question sur stackoverflow. Et là ça a été totalement différent. Les personnes qui m’ont aidé, sans me donner la solution totale à mon problème m’ont donné deux mot clefs : named instance et IterableProvider. J’avais deux mots clefs efficaces pour trouver ma solution, et ça fonctionne !
Phase 3 : partagez
Lorsque vous avez résolu un problème, profitez de ce doux sentiment qui mélange fierté, accomplissement et soulagement. Profitez-en pour expliquer à quelqu’un, que ça soit à l’oral ou sur un forum ce que vous avez fait pour résoudre votre problème. En plus de permettre à vos interlocuteurs de prendre eux-mêmes connaissance des mots clefs associés à votre problème, cela vous permettra de faire naître des débats, de trouver de nouvelles idées, voire d’améliorer encore la manière de résoudre votre problème.
C’est dans ce cadre que j’ai donné la solution à mon problème sur le forum de zds: grâce à cela des francophones auront accès à une aide dans leur langue natale. Et pour le débat et les idées? Ce billet est là pour ça.
Voilà, en conclusion, je dirai simplement :
- n’ayez pas peur de la documentation ;
- n’ayez pas peur de poser la question, qu’elle vous paraisse trop "complexe" ou trop "basique", au mieux les gens ont déjà une solution pour vous, au pire ils vous aiguilleront vers le ou les bons mots clef ;
- partagez avec les gens la résolution de votre question.
En espérant que ce texte vous a plu :).