Codons–pizza

Bonjour, Habr. Nous avons spontanément organisé notre premier hackathon interne. J'ai décidé de partager avec vous mes douleurs et mes conclusions sur la préparation qui a duré deux semaines, ainsi que sur les projets qui ont émergé.

Partie ennuyeuse pour ceux qui s'intéressent au marketing

Je vais commencer par une petite histoire.

Début avril. Notre bureau accueille le premier hackathon de la communauté MskDotNet. La bataille pour Tatooine est en cours, dans notre galaxie cette fois. Samedi. 20 équipes. Pizza. Tout est très convivial (preuves). Un R2-D2 gonflable se dresse dans la salle. Les équipes écrivent les algorithmes les plus précis pour réussir la course la plus périlleuse sur la carte. Nous avons retardé le lancement des premières courses. Les biscuits et le café sauvent la mise. Nous, les organisateurs, nous attendions à ce que beaucoup de personnes s'en aillent après le déjeuner. Mais non. 12 heures de codage derrière nous. Finale. Des choses qui se déconnectent, d'autres qui ne démarrent pas. Mais tout le monde est heureux. Notre équipe gagne. Nous sommes doublement heureux.

Je partage ma joie sur Slack et l'idée me vient : « Il faut faire notre propre hackathon ». J'écris à notre CTO Sasha. Silence.

Matin. Je bois un café au bureau. Je vois Sasha s'approcher par derrière. « Liza, c'est génial ! Nous avons une date importante le 21 avril. Allons-y ! » Quoi !? Si vite ? Hein ? Je dois m'envoler pour Syktyvkar pour un stage à la mi-avril. Peu importe ! Allons-y.

Il reste deux semaines. Je n'ai jamais été l'organisatrice unique d'un hackathon. Même s'il est interne. Je lis des articles sur le sujet. Horreur. Il faut plusieurs mois. Il faut plusieurs personnes. Il faut penser au merchandising, aux prix, aux conditions, à l'emploi du temps, intéresser les gens, comprendre l'objectif, les budgets. Peut-être même réfléchir au sens de la vie. Je suis sûre que je ne vais pas y arriver. Et pendant que tu lisais et te préparais, une semaine est déjà passée. Il est temps d'abandonner les articles et de commencer à faire quelque chose.

Voici notre checklist pour organiser un hackathon interne en une semaine

• Plan: assieds-toi tranquillement et fais une liste de ce qu'il faut faire pour le hackathon. 30 minutes.
• La tâche: les participants proposent et choisissent eux-mêmes les projets qu'ils souhaitent créer dans Google Sheets. Tâche de fond, 2 heures.
• Calendrier: tu écris sur le pouce un bref programme horaire en tenant compte de 3 pauses et de la finale. 20 minutes.
• Commandes: tu publies un message sur le hackathon avec le calendrier du CTO dans les canaux IT sur Slack/email/etc. et tu crées un canal séparé pour le hackathon. Dans celui-ci, tout le monde se divise en équipes, et ceux qui ne sont pas encore décidés le font dans les 5 premières minutes du hackathon. Tâche de fond, 2 heures.
• Avantages: tu crées des produits dérivés avec deux développeurs, tu les envoies à un designer pour la création, tu reçois le produit fini. Tâche de fond, 3 jours.
• Hackathon: tu arrives au bureau, tu coordonnes tout le monde au début, tu t'occupes de tes affaires, tu lis Reddit, avec un air sérieux tu annonces chaque pause la livraison de la nouvelle pizza, tu photographies le coucher de soleil, tu annonces la finale, vous votez ensemble et choisissez un gagnant. 1 jour.
• Sous les étoiles: bien sûr, tu penses constamment à ce que tout se passe bien. Évidemment, tout le monde ne verra pas ton message et il est préférable de parler en personne avec certains. Évidemment, si quelqu'un t'aide, tout devient deux fois plus facile (la merveilleuse Alena m'a aidé).

La partie moins ennuyeuse sur la date du hackathon

Pourquoi le 21 avril ? Ce jour est significatif pour nous. Il y a exactement un an, le 21 avril, nous avons été submergés par la charge pendant le premier week-end après le lancement de la Campagne Publicitaire Fédérale. Le lendemain, dimanche, notre équipe était au travail dès 8 heures du matin. À ce moment-là, nous avons créé un tableau sundayhackathon dans Trello et a commencé une semaine de travail par shifts de 12 heures par jour. La situation était si critique que nous n'avions même pas le temps de manger et nous étions nourris par des gars d'autres équipes.

Vous pouvez lire un récit plus détaillé sur la page de Fiodor Ovchinnikov (notre PDG). Depuis, nous avons fait beaucoup de changements, mais nous n'oublierons plus la date.

Cette année, nous avons décidé que cet événement mérite d'être gravé dans les mémoires et, dans la meilleure tradition, nous avons organisé le premier hackathon interne de Dodo, qui a duré 10 heures.

La partie la moins ennuyeuse sur les projets du hackathon

Avertissement : toutes les descriptions ont été rédigées par les gars eux-mêmes, donc la paternité du texte ne m'appartient pas.

Oleg Learning (apprentissage automatique)

Dima Kochnev, Sasha Andronov (@alexandronov)

Nous voulions créer un réseau neuronal qui puisse déterminer quelle pizza se trouve sur la photo sans aucune connaissance préalable. Au final, nous avons créé un modèle très simple et ludique – il reconnaît 10 types de pizzas, et nous avons à peu près compris comment tout fonctionne, autant que possible en une journée (~10 heures).

En particulier, nous avons compris que l'industrie a atteint un niveau où un développeur ordinaire peut utiliser des bibliothèques prêtes à l'emploi, lire la documentation et former son propre réseau neuronal sans connaissances approfondies. Et cela fonctionne assez bien pour résoudre des problèmes réels.

Outils que nous avons utilisés :

• imageai — une bibliothèque pratique et simple pour le travail avec l'apprentissage automatique et la vision par ordinateur.
• Nous avons essayé deux modèles – ResNet50, Yolo.
• Le code a été écrit, bien sûr, en Python.

Nous avions 11000 photos, mais presque 3/4 se sont révélées inutilisables, et parmi les restantes, il y avait différents angles inappropriés. En fin de compte, nous avons utilisé un modèle prêt (qui sait simplement identifier des pizzas) pour séparer les images les plus inutilisables. Ensuite, le nom de l'image comportait le nom de la pizza – nous les avons donc classées dans des dossiers, mais il s'est avéré que les noms ne correspondaient pas à la réalité et il a donc fallu faire un nettoyage manuel. Au final, il restait environ 500 à 600 photos, ce qui est un nombre insignifiant, mais néanmoins, cela s'est avéré suffisant pour distinguer 10 pizzas les unes des autres.

Pour entraîner le réseau, nous avons pris la machine virtuelle la moins chère sur Azure avec un NVIDIA Tesla K80. Nous avons entraîné pendant 100 époques, mais il était clair que le réseau était devenu saturé après 50 époques, car le jeu de données était petit.

En fait, tout le problème provient du manque de bonnes données.

Nous avons peut-être un peu mélangé les termes, mais il faut comprendre que nous n'avons absolument aucune expérience dans tout cela.

GUI for NOOBS (console pour commander des pizzas)

Misha Kumachyov (Ceridan), Zhenya Bikkinin, Zhenya Vasiliev

Nous avons créé un prototype d'application console pour les geeks, qui permet de commander une pizza via le terminal ou la ligne de commande, ou même de l'intégrer dans un pipeline de déploiement afin de livrer la pizza au bureau après un déploiement réussi.

Le travail a été divisé en plusieurs parties : nous avons exploré la façon dont notre API pour les applications mobiles fonctionne, avons construit notre propre CLI avec oclif et avons configuré la publication de notre paquet. La dernière tâche a donné lieu à plusieurs minutes désagréables vers la fin du hackathon. Tout fonctionnait localement et même les anciennes versions publiées du paquet marchaient, mais les nouvelles (qui contenaient plus de super fonctionnalités et d'émoticônes) refusaient de fonctionner. Nous avons passé environ 40 minutes à comprendre ce qui s'était mal passé, mais finalement, tout a fonctionné comme par magie).

Notre objectif principal lors du hackathon était de passer une commande de pizza réel au bureau via notre CLI. Nous avons passé tout en revue une dizaine de fois sur notre environnement de test, mais j'avais quand même les mains tremblantes lorsque je tapais les commandes en production.

Au final — nous l'avons quand même fait !

CourierGo

Anton Bruzmelëv (auteur), Vania Zvereva, Gleb Lesnikov (entropie), Andrey Sarafanov

Nous avons pris l'idée d'une « Application pour les livreurs ».

Contexte sur les préparations.Au départ, j'ai réfléchi aux fonctionnalités possibles de l'application. Voici une liste approximative des fonctionnalités :

• L'application se connecte à la caisse de livraison par un code.
• Dans l'application, les commandes disponibles et les commandes à prendre sont immédiatement visibles.
• Le livreur marque la commande et part avec.
• Il voir le temps estimé et s'il sera à l'heure ou non.
• Le client voit que le livreur est en route.
• Le client peut voir la position du livreur sur la carte et le temps estimé.
• Le livreur peut écrire au client dans le chat de l'application.
• Le client peut écrire au livreur dans le chat de l'application.
• Cinq minutes avant son arrivée, le client reçoit un message indiquant que le livreur est proche, soyez prêt.
• Le livreur marque dans l'application qu'il est arrivé et attend.
• Le livreur peut appeler depuis l'application d'un clic et informer qu'il (arrive, est là, etc.)
• Le client accepte la commande et saisit le code pin de l'application ou reçu par SMS pour confirmer la livraison (comme une signature). Pour empêcher le livreur de terminer la livraison à l'avance s'il est en retard.
• La commande est marquée comme livrée dans le système.

Plus quelques scénarios alternatifs :

• Le livreur peut marquer la commande comme non livrée et choisir la raison.
• En cas de retard, le livreur peut émettre un bon électronique par SMS d'une seule pression. Ou le bon arrive automatiquement en cas de non-respect des délais de livraison.

La perspective et l'utilité de ce projet étaient évidemment motivantes.

Le lendemain, l'équipe est allée déjeuner et a discuté de la manière dont les fonctionnalités minimales de l'application seraient.

Au final, voici la liste des tâches à accomplir lors du hackathon :

• Connexion à la caisse de livraison.
• Afficher la position actuelle.
• Envoyer des données à une API externe (coordonnées, commande prise, commande livrée).
• Obtenir des données d'une API externe (commandes actuelles du livreur).
• Envoyer un événement signalant que la commande a été prise pour livraison / livrée.
• Afficher la position actuelle du livreur sur la carte sur le site.

Le principal travail, comme il se voyait, était la création du backend et de l'application elle-même (après discussions, nous avons choisi ReactNative pour le développement de l'application, plus précisément l'enveloppement autour — expo.io, permettant de ne pas écrire de code natif en général). En ce qui concerne le backend, il y avait initialement de l'espoir en Vanya Zverev, en tant qu'expert travaillant avec notre modèle de service et k8s (le type de travail qu'il a pris en charge). J'ai touché à ReactNative avec Andrey Sarafanov.

J'ai décidé d'essayer de créer directement un dépôt de travail pour le projet. À 12h, je me suis rendu compte que la géolocalisation dans ReactNative ne fonctionnait pas bien en arrière-plan sans écrire de code natif, ce qui m'a un peu frustré. Puis, cela s'est calmé quand j'ai compris que je lisais la documentation du framework expo.io, et non celle de ReactNative. Au final, en une soirée, j'avais déjà compris comment obtenir la position actuelle dans expo.io et dessiner des écrans séparés (pour la connexion, l'affichage de la commande, etc.).

Le matin du hackathon, nous avons séduit Gleb dans notre projet ultra-prometteur. Nous avons rapidement esquissé un plan de ce qu'il fallait faire.

Nous avons fait une erreur en essayant de faire communiquer en suivant le modèle du projet non pas via HTTP, mais via GRPC, car personne ne savait comment assembler un client GRPC pour JavaScript. Au final, après avoir passé environ une heure et demie là-dessus, nous avons abandonné cette idée. À cause de cela, les gars ont commencé à retravailler le serveur prêt sur le backend de GRPC à WebApi. Après une demi-heure, nous avons enfin pu établir la communication entre l'application et le backend, quel miracle. Mais à ce moment-là, Gleb presque terminé le déploiement dans k8s et le déploiement automatique lors de chaque commit sur master. 🙂

Comme stockage, nous avons choisi MySQL pour ne pas prendre de risques avec la base (nous avons envisagé CosmosDb).

En résumé :

• Nous avons mis en œuvre la sauvegarde des coordonnées actuelles du livreur à partir de l'application dans la base.
• Nous avons intégré RabbitMQ et nous nous sommes abonnés aux messages concernant la prise de commandes par le livreur, afin d'afficher immédiatement la commande pour le livreur dans l'application.
• Nous avons commencé à enregistrer dans notre base l'heure de livraison de la commande, après que le livreur ait appuyé sur le bouton dans l'application. Nous n'avons pas réussi à ajouter l'envoi de l'événement de retour à RabbitMQ indiquant que la commande a été livrée.
• J'ai affiché une carte sur la page currentorder du site avec la position actuelle du livreur. Mais cette fonctionnalité est restée légèrement inachevée, car nous n'avons pas réussi à configurer CORS pour obtenir les coordonnées de notre nouveau service.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artyom Trofimushkin

Nous souhaitions mettre en œuvre un fournisseur OpenID Connect, car actuellement nous utilisons un protocole d'authentification développé en interne, ce qui crée plusieurs difficultés : bibliothèques clientes personnalisées, travail compliqué pour les partenaires externes, et potentiellement des problèmes de sécurité (tout de même, OAuth2.0 et OpenID Connect dans leur mise en œuvre de référence peuvent être considérés comme sécurisés, mais en ce qui concerne notre solution — j'ai des doutes).

Nous avons créé un service distinct émulant un service de stockage de données personnelles, afin de créer un petit modèle de fournisseur d'authentification Country-Agnostic, qui irait chercher des données personnelles dans un service distinct (ce qui à terme permettrait d'avoir un service unique, avec lequel on pourrait se connecter avec un compte dans n'importe quel pays, tout en respectant le RGPD et d'autres législations). Cette partie a été réalisée, tout comme le fournisseur, et nous les avons liés avec succès. Ensuite, il fallait créer une API qui serait protégée par des jetons délivrés par le fournisseur, supporter leur introspection via le fournisseur et donner des données protégées si la demande satisfaissait les politiques d'autorisation (nous vérifions que l'utilisateur est authentifié par le schéma Bearer, que son jeton contient un certain scope + que l'utilisateur lui-même a un droit autorisant l'exécution de l'appel). Cette partie a également été réalisée. Le dernier composant était le client JavaScript, à qui un jeton serait délivré, grâce auquel il appellerait l'API protégée. Nous n'avons pas eu le temps de finaliser cette partie. Ainsi, toute la partie fonctionnelle était prête, mais la partie front-end pour démontrer le fonctionnement de l'ensemble du système ne l'était pas.

E-E-E (petit jeu)

Dima Afonchenko, Sasha Konovalov

Nous avons fait un mini-jeu sur Unity où de petites mains lancent de la saucisse sur une pizza. Si tu lances mal la saucisse, un message triste apparaît à l'écran « Rejetée », et si la saucisse est bien placée, un fait aléatoire sur la pizza apparaît.

Nous voulions faire un deuxième niveau avec des tomates, mais nous n'avons pas eu le temps.

Brève suite : qui a gagné ?

Avant le hackathon, nous avons discuté avec les gars et j'ai demandé quel prix ils aimeraient recevoir s'ils gagnaient. Il s'est avéré que le prix le plus prisé serait « un accès en production ».

Ainsi, attendez-vous bientôt à une annonce de notre jeu avec des petites mains qui ajoutent des pepperonis sur la pizza.

Comme un lecteur attentif a pu le remarquer, l'équipe «E-E-E (jeu)» a gagné. Félicitations aux gars !

Seuls les utilisateurs enregistrés peuvent participer au sondage. Connectez-vous, s'il vous plaît.

Quel projet vous a le plus plu ?

• Oleg Learning (apprentissage automatique)

• GUI pour NOOBS

• CourierGo

• M87

• E-E-E

5 utilisateurs ont voté. 3 utilisateurs se sont abstenus.

Source : habr.com