Bonjour à tous, communauté JavaRush ! Un peu de moi : je travaille comme ingénieur logiciel Java depuis le printemps 2016. J’aime venir ici et résoudre des problèmes que je n’ai pas résolus pendant mes études. Aujourd'hui, je vais vous parler de la bibliothèque - Comparaison d'images . Il s'agit d'une bibliothèque open source disponible publiquement sur GitHub . Le but de cet article est de faire comprendre que créer un produit open source n'est pas qu'une perte de temps, non ! Il s'agit d'une expérience riche qui s'inspire de différents côtés, lorsque vous contrôlez l'ensemble du processus de développement, lorsque vous devez approfondir chaque détail. L'Open Source, c'est le monde qui vous entoure. Je ne plaisante pas, au cours de l'existence de cette bibliothèque, j'ai communiqué avec des personnes de différents pays, comme les États-Unis, l'Inde, la Chine, l'Égypte, la Russie, l'Allemagne, l'Ukraine, la Suède, la Nouvelle-Zélande et la Norvège. Autrement dit, il s'agit d'une véritable expérience de développement conjoint, de recherche de compromis, de vérification du code, etc. C'était l'introduction, commençons maintenant dans l'ordre :
Test. Début août 2017
Tout a commencé avec le fait que j'ai eu un entretien avec l'une des entreprises, où la première étape consistait à rédiger une tâche de test. La tâche consistait à écrire un code permettant de comparer deux images de même taille, de trouver les différences entre elles, de les regrouper et de dessiner un rectangle autour d'elles. Voici la première photo :
Il y a une deuxième photo :
Il fallait trouver les différences et les encercler comme indiqué ci-dessous :
Comme vous pouvez le constater, il y a une différence dans le champ Nom d'utilisateur , qui est entouré d'un triangle rouge. Description plus détaillée de la tâche . J'ai décidé que je voulais le faire non seulement correctement d'un point de vue fonctionnel, mais aussi magnifiquement, pour que ce ne soit pas gênant. Pour ce faire, j'ai décidé de publier ceci en tant que projet sur GitHub . J'ai longtemps voulu étudier GitHub et acquérir de l'expérience en travaillant avec lui. Après un rapide coup d'œil, j'ai trouvé qu'il serait bien d'ajouter des services tiers pour analyser la qualité du code, générer une couverture de code avec des tests, etc. Ajout des outils suivants :
Codacy - qualité du code. Cela vaut vraiment la peine d'y prêter attention.
Travis CI est un outil CI (intégration continue) qui crée un projet, exécute des tests et indique si le projet a été construit avec succès. Par exemple, si l'un des tests n'a pas réussi à la suite des nouvelles modifications, il indiquera que la construction du projet a échoué et le colorera en rouge.
Coveralls est un outil qui montre quel pourcentage de votre code est couvert par les tests.
BetterCode Hub est un autre outil d'analyse de la qualité du code. Une chose très utile qui non seulement vous dira ce qui ne va pas, mais décrira également pourquoi et donnera un lien vers un livre où vous pourrez acquérir des connaissances à ce sujet.
Chacun de ces services possède son propre badge avec les résultats des données, comme un projet de couverture de code. Et ce badge peut être ajouté dans la description principale du projet - fichier README. La tâche était prête - je l'ai envoyée pour examen. Après l'examen, j'ai immédiatement, de mémoire fraîche, créé un problème Github pour chaque commentaire , ce qui m'aiderait ensuite à améliorer ce projet. Il n'y avait aucune tâche d'amélioration de la part de l'employeur, alors j'ai oublié le projet pendant un moment...
Chemin de la bibliothèque. juillet 2018
Logo
À un moment donné, j’ai découvert que les gens visitaient souvent mon projet, et cela arrive tous les jours. J'ai été étonné par cela, et encore plus étonné par le fait qu'environ un an plus tard, un NUMÉRO a été créé, dans lequel il était écrit qu'un certain graphiste me proposait de créer un logo pour mon projet. Ils disent qu'il adore faire cela pour les produits Opensource et qu'il le fera absolument gratuitement. Nous avons commencé à collaborer. Plusieurs options ont été proposées, mais nous avons finalement opté pour celle-ci :
J'étais alors encore jeune et peu familier avec la communauté open source, et le fait même d'une telle offre me paraissait fou et j'ai demandé : pourquoi fait-il cela ? Ce à quoi il a répondu : "Mdr oh, juste parce que j'aime contribuer à des projets open source. Une sorte d'objectif de vie..." ( le problème lui-même est ici ). C’est à ce moment-là que j’ai ressenti pour la première fois à quel point il était formidable que différentes personnes vous trouvent à travers des projets open source et proposent des choses aussi intéressantes !
Défaut du premier côté
J'ai remarqué qu'un certain développeur chinois avait créé un problème pour moi dans lequel il décrivait qu'il avait trouvé un défaut dans le travail de la bibliothèque, que si vous utilisez de grandes images, vous obtenez une StackOverflowError . L'homme a décidé d'en profiter et a trouvé une erreur. Et je ne l'ai pas seulement trouvé. et a également écrit sur elle. Il s'agit d'une nouvelle étape dans le développement de la bibliothèque. De plus, je n’avais pas vraiment de solution. À un moment donné, l’un des testeurs russes a proposé une solution. Mais c’était cru et mal fait et je ne l’ai pas accepté. Et quand il était temps de publier la bibliothèque dans Maven Central, il fallait résoudre quelque chose avec ce défaut ; je ne voulais pas la publier avec. De plus, il y avait un autre défaut que je n'ai jamais corrigé et qui a également apporté beaucoup de désagréments.
Utilisation de la ligne de commande. Automne 2018
L'étape suivante du développement a été la communication avec un Suédois (Renato Athaydes), qui souhaitait utiliser la bibliothèque via la ligne de commande et pour cela, il a fallu apporter quelques modifications et ajouts. J'en ai été à nouveau étonné et surpris. Après que le graphiste m’ait écrit, ma surprise a été un peu moindre, mais néanmoins très élevée. L’idée que quelqu’un avait vraiment besoin de mon code m’a rempli de sentiments incroyables. Il a apporté les modifications nécessaires et préparé le code. J'ai effectué une révision du code, c'est-à-dire que j'ai regardé les modifications, il y avait des commentaires qui ont été modifiés et les modifications étaient déjà dans la bibliothèque. J'ai désigné ces modifications comme version v2.0. L'étape suivante consistait à ajouter la bibliothèque à Maven Central - un référentiel central, à partir duquel vous pouvez la télécharger pour n'importe quel projet et l'utiliser comme dépendance. À cette époque, je ne savais pas comment faire, même à distance, alors j'ai dit que j'étais occupé et je lui ai demandé d'effectuer toutes les étapes nécessaires à la mise en place du projet. Mais cela s’est avéré insuffisant et le plus intéressant a été d’établir une connexion avec Maven Central. C’est une véritable galère, ce que je n’ai pas pu faire la première fois, et ce n’est que le 15 avril que j’ai pu publier le projet sur Maven Central. Cela n'a pas été facile, mais comme d'autres aiment le dire, "tous ceux qui souhaitent publier leur code Java passent par là". Avant de publier la bibliothèque, j'ai enfin trouvé quoi et comment faire avec des défauts qui duraient depuis longtemps et j'ai publié une nouvelle version v2.0.2 , dans laquelle j'ai remercié tous ceux qui m'ont aidé, décrit ce que j'ai fait et comment .
Publication sur Maven Central. Printemps 2019
Pour publier correctement une bibliothèque, vous devez avoir une bonne compréhension du versioning et de la manière de définir correctement les versions. Je vais m'en tenir à ce schéma :
XX.YY.BBBB , où XX est une mise à jour majeure de la version qui entraîne des modifications incompatibles avec la précédente (par exemple, la modification du résultat renvoyé dans les méthodes) ;
YY est une mise à jour mineure - une modification ou une extension interne qui ne change pas ce qu'est BBBB - ce sont des défauts qui ont été corrigés.
Par exemple, la version 2.0.2 signifie que la version majeure est la 2, qu'il n'y a pas eu de mises à jour mineures et qu'il y a deux mises à jour pour les défauts.
Ensuite, il était important de comprendre comment définir correctement groupId etartefactId . Ils devaient être sélectionnés une fois et utilisés ultérieurement. Et ils constituent le package dans lequel le code est stocké. Était : ua.comparison.image Maintenant : com.github.romankh3.image.comparison Et c'est clairement mieux, puisque tout le monde sait qu'il s'agit d'un projet de GitHub et peut être trouvé auprès d'une personne avec le surnom de romankh3. Quand j'ai fait tout cela, j'ai publié une nouvelle version v2.1.0 .
Communication avec les Suédois. mai 2019
Après avoir publié la bibliothèque, un autre Suédois (Mika Kytöläinen) m'a envoyé un e-mail et a demandé à son ami d'apporter des modifications à ma bibliothèque. Il dit qu'il en a vraiment besoin et qu'il sera très heureux si nous le faisons et le faisons rapidement. Bien entendu, je n’étais pas contre les changements nécessaires. Il a suggéré d'ajouter une configuration d'épaisseur de ligne qui dessine un rectangle. Par exemple, pour ceux qui ont une mauvaise vision, ce sera un changement utile. J'ai préparé le code . Après avoir ajouté quelques modifications supplémentaires, j'ai publié la version v2.2.0
Communication avec un Allemand. mai 2019
Après cela, un Allemand a créé un problème dans lequel il dit qu'il souhaite l'utiliser pour des tests, mais qu'il manque de fonctionnalités. Il a fait de nombreuses propositions très intéressantes, il a suggéré qu'au lieu de renvoyer uniquement l'image résultante avec le résultat de la comparaison, renvoie un ensemble de données : ce qui a été comparé, le résultat (si nécessaire) et l'état dans lequel il y a sera MATCH, MISMATCH, SIZE_MISMATCH . J'ai même fait les changements. Mais ils n’ont pas du tout tenu compte du code précédent et ont été réalisés à la hâte. Je les ai rejetés et j'ai proposé de les exécuter comme je l'entendais. Malgré cela, il a répondu davantage et j'ai décidé de le faire moi-même et de publier une nouvelle version. Dans le même temps, Mika Kytöläinen a proposé une autre fonctionnalité intéressante : l'ajout de zones qui ne seraient pas incluses dans la comparaison. C'est un cas réel. Et tout cela est sorti dans la v3.0.0
Utilisation dans un projet réel
Fin mai, m'a écrit un testeur d'automatisation de Kiev, qui s'est intéressé à la bibliothèque et souhaite l'utiliser dans un vrai projet qui rapporte de l'argent. C'était une percée ! L’utiliser quelque part dans un projet familier est une chose, mais l’utiliser dans un projet réel est une tout autre affaire. Nous avons discuté de quoi et comment cela fonctionne. L'application est très intéressante : dans leur application ils ont des chèques qui sont imprimés et il fallait vérifier que les chèques sont créés selon un certain modèle et que cela ne change pas. Mais il y avait un problème : des sections telles que la date et l’heure changeaient toujours et devaient être ignorées. Nous avions déjà ajouté des fonctionnalités pour ignorer certaines zones, mais cela s'est avéré encore très brut pour une utilisation réelle et nous avons quand même travaillé fructueusement ensemble pendant plusieurs semaines là-dessus. Le résultat a été la sortie de la version v3.1.1
Trouver un créneau
Après cela, j'ai réalisé que le véritable créneau de ma bibliothèque était de l'utiliser dans les tests. Pour ce faire, j'ai décidé de trouver une sorte de forum pour les testeurs et de leur écrire à ce sujet afin d'obtenir des retours et d'augmenter ma notoriété. J'ai trouvé un forum en russe et y ai publié un article : Organisation des tests d'images - comparaison de deux images similaires . J'y ai reçu de vrais retours sur le code et les fonctionnalités, que j'ai appliqués et publié une nouvelle version v3.2.0 , puis v.3.3.0 .
Maintenant
La bibliothèque compte actuellement 60 étoiles sur Github et 33 forks. Je pense que c'est très cool, étant donné que je n'en ai fait la promotion d'aucune manière, à l'exception d'un article sur le forum des automates. Merci à tous ceux qui ont lu jusqu'au bout. En fait, l’article s’est avéré beaucoup plus long que ce à quoi je m’attendais. Un article sur la façon de publier une bibliothèque sur Maven Central. Si vous avez quelque chose à ajouter, écrivez ! Si vous avez quelque chose à suggérer pour améliorer la bibliothèque, écrivez ! Je vais tout lire et y consacrer le temps nécessaire. Tous ceux qui ont aimé l'article et l'ont trouvé utile, notez-le et écrivez dans les commentaires. Abonnez-vous également à mon compte github romankh3. Voir aussi mes autres articles :
GO TO FULL VERSION