Kodim-pizza

Bonjour Habr. Nous avons spontanément organisé notre premier hackathon interne. J'ai décidé de partager avec vous mes peines et mes conclusions sur la préparation en 2 semaines, ainsi que les projets qui se sont révélés être.

La partie ennuyeuse pour ceux qui s'intéressent au marketing

Je vais commencer par une petite histoire.

Début avril. Le premier hackathon de la communauté MskDotNet a lieu dans nos bureaux. La bataille de Tatooine bat cette fois son plein dans notre galaxie. Samedi. 20 équipes. Pizza. Tout est très sincère (preuves). Un R2-D2 gonflable flotte autour de la salle. Les équipes écrivent les algorithmes les plus corrects pour réussir la course la plus dangereuse de la carte. Nous décalons le lancement des premières courses. Les biscuits et le café sauvent des vies. Les organisateurs et moi-même nous attendions à ce que beaucoup de monde parte après le déjeuner samedi. Mais non. 12 heures de codage derrière. Le final. Quelque chose tombe, quelque chose ne démarre pas. Mais tout le monde est content. Notre équipe gagne. Nous sommes doublement heureux.

Je partage ma joie dans Slack et l’idée me vient à l’esprit : « Nous devons faire notre propre hackathon. » J'écris à notre station-service Sasha. Silence.

Matin. Je bois du café au bureau. Je vois Sasha s'approcher par derrière. « Lisa, c'est génial ! Nous avons une date importante le 21 avril. Faisons-le!" WTF !? Si rapide? UN? Quoi? Je dois m'envoler pour Syktyvkar pour un stage à la mi-avril. Et au diable ! Allons.

Il reste 2 semaines. Je n'ai jamais été le seul organisateur d'un hackathon. Que ce soit interne. J'ai lu des articles sur ce sujet. Difficile. Cela prend plusieurs mois. Il faut plusieurs personnes. Vous devez penser aux produits dérivés, aux prix, aux conditions, au calendrier, à l'intérêt, comprendre l'objectif et les budgets. Ou peut-être même découvrir le sens de la vie. Je n'arriverai certainement pas à temps. Et pendant que vous lisiez et prépariez, une semaine s'était déjà écoulée. Il est temps d'oublier les articles et de commencer à faire quelque chose.

Consultez notre liste de contrôle pour organiser un hackathon interne en 1 semaine

• Plan: Vous vous asseyez calmement et rédigez une liste de ce qui doit être fait pour le hackathon. 30 minutes.
• Tâche: Les participants proposent et choisissent les projets qu'ils souhaitent créer dans Google Sheets. Tâche de fond, 2 heures.
• calendrier: sur votre genou vous écrivez un petit décompte de temps, en tenant compte de 3 pauses et du final. 20 minutes.
• Команды: publiez un message sur le hackathon avec un planning de la station-service dans les canaux informatiques de Slack/mail/etc et créez un canal séparé pour le hackathon. Dans ce document, tout le monde est divisé en équipes, et ceux qui sont indécis le font dans les 5 premières minutes du hackathon. Tâche de fond, 2 heures.
• Petits pains: vous proposez un produit avec deux développeurs, le donnez au concepteur pour le rendu et le recevez prêt. Tâche de fond, 3 jours.
• Hackathon: vous venez au bureau, coordonnez tout le monde au début, vaquez à vos occupations, lisez Reddit, annoncez surtout chaque pause pizza fraîche, prenez des photos du coucher de soleil, annoncez la finale, votez ensemble et choisissez le gagnant. jour 1.
• Sous l'astérisque: Bien sûr, vous pensez constamment que tout va bien. Bien entendu, tout le monde ne verra pas votre message et il est préférable d’en parler à certains en personne. Bien sûr, si quelqu'un vous aide, tout deviendra 2 fois plus facile (la merveilleuse Alena m'a aidé).

La partie la moins ennuyeuse du rendez-vous du hackathon

Pourquoi le 21 avril ? Cette journée est importante pour nous. Il y a exactement un an, le 21 avril, nous étions sous charge le premier week-end après le début de la campagne publicitaire fédérale. Le lendemain, dimanche, notre équipe était au travail dès 8 heures du matin. Ensuite, nous avons créé un forum de hackathon du dimanche dans Trello et une semaine de travail posté a commencé, 12 heures par jour. La situation était tellement 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 une histoire plus détaillée sur Page de Fiodor Ovchinnikov (notre PDG). Depuis, nous avons beaucoup changé, mais maintenant nous n'oublierons certainement pas la date.

Cette année, nous avons décidé que cet événement méritait d'être perpétué dans la mémoire de la postérité et, dans la plus pure tradition, nous avons organisé le premier hackathon interne de l'histoire de Dodo, qui a duré 10 heures.

La partie la plus ennuyeuse des projets de hackathon

Avertissement : toutes les descriptions ont été écrites par les gars eux-mêmes, donc la paternité du texte n'est pas la mienne.

Oleg Learning (apprentissage automatique)

Dima Kochnev, Sacha Andronov (@alexandronov)

Ils voulaient créer un réseau de neurones qui déterminerait quel type de pizza se trouve sur une photo sans aucune connaissance. En conséquence, nous en avons créé un très simple et jouet - il reconnaît 10 pizzas, nous avons à peu près compris comment tout fonctionne, autant que possible en une journée (~ 10 heures).

En particulier, nous avons réalisé que l'industrie a atteint un niveau où un développeur ordinaire peut utiliser des bibliothèques toutes faites, lire la documentation et entraîner son réseau neuronal sans connaissance approfondie du sujet. Et cela fonctionnera suffisamment bien pour résoudre de vrais problèmes.

Les outils utilisés:

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

Nous avions 11000 3 photos, mais près des trois quarts d’entre elles se sont révélées être des déchets, et le reste avait des angles différents et inappropriés. Du coup, nous avons pris un modèle tout fait (qui sait simplement comment trouver une pizza) et avec son aide nous avons séparé les poubelles. Ensuite, le titre de la photo incluait le nom de la pizza - nous l'avons donc trié dans des dossiers, mais il s'est avéré que les noms ne coïncidaient pas avec la réalité et nous avons dû la nettoyer avec nos mains. Au final, il restait environ 4 à 500 photos, il est clair que c'est une quantité insignifiante, mais néanmoins, c'était suffisant pour séparer 600 pizzas les unes des autres.

Pour entraîner la grille, nous avons pris la machine virtuelle la moins chère d'Azure sur une NVIDIA Tesla K80. Ils se sont entraînés dessus pendant 100 époques, mais il était clair que le réseau était sursaturé après 50 époques, en raison du petit ensemble de données.

En fait, tout le problème réside dans le manque de données fiables.

Nous avons peut-être un peu confondu les termes, mais nous devons tenir compte du fait que nous n'avons aucune expérience dans le traitement de toutes ces questions.

GUI pour NOOBS (console pour commander des pizzas)

Micha Koumachev (Céridan), Zhenya Bikkinin, Zhenya Vasiliev

Nous avons mis au point un prototype d'application console pour les geeks, grâce à laquelle vous pouvez commander une pizza via le terminal ou la ligne de commande, ou même l'intégrer dans le pipeline de déploiement et, en cas de sortie réussie, livrer une pizza au bureau.

Le travail a été divisé en plusieurs parties : nous avons compris comment fonctionne notre API pour applications mobiles, assemblé notre propre CLI en utilisant oclif et configuré la publication du package que nous avons collecté. La dernière tâche a nécessité quelques minutes désagréables vers la fin du hackathon. Tout fonctionnait localement pour nous, et même les anciennes versions publiées du package fonctionnaient, mais les nouvelles (qui ajoutaient des fonctionnalités et des émoticônes plus intéressantes) refusaient de fonctionner. Nous avons passé environ 40 minutes à essayer de comprendre ce qui n'allait pas, mais à la fin, tout a fonctionné tout seul, comme par magie).

Notre programme maximum pour le hackathon était une véritable commande de pizza au bureau via notre CLI. Nous avons tout exécuté une douzaine de fois sur le banc de test, mais mes mains tremblaient encore lorsque j'ai saisi les commandes en production.

Résultat, nous l'avons finalement fait !

CourrierGo

Anton Bruzhmelev (auteur), Vanya Zverev, Gleb Lesnikov (entropie), Andreï Sarafanov

Nous avons pris l’idée d’une « App pour Courrier ».

Contexte de la préparation.Au départ, je me demandais quels types de fonctionnalités pourraient être présentes dans l'application ? La liste de fonctionnalités suivante a émergé :

• L'application se connecte à la caisse de livraison à l'aide du code.
• L'application affiche immédiatement les commandes disponibles et les commandes à prendre.
• Le coursier note la commande et l'emmène en voyage.
• On lui montre l'heure estimée et s'il est à l'heure ou non.
• Montre au client que le coursier est parti.
• Le client commence à voir le point du coursier sur la carte et l'heure estimée.
• Le coursier peut écrire au client par chat depuis l'application.
• Le client peut écrire au coursier via le chat depuis l'application.
• Cinq minutes avant son arrivée, le client reçoit un message indiquant que le coursier est proche, soyez prêt.
• Le coursier note dans la demande qu'il est arrivé et qu'il attend.
• Le coursier appelle depuis l'application en un clic et signale que (se lève, est arrivé, etc.)
• Le client accepte la commande et saisit un code PIN depuis l'application ou un SMS pour confirmer la livraison (en guise de signature) afin que le coursier ne puisse pas 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 transporteur peut marquer la commande comme non livrée et sélectionner le motif.
• Si vous êtes en retard, le coursier peut émettre un certificat électronique par SMS avec un seul bouton. Ou bien le certificat arrive automatiquement si le délai de livraison n'est pas respecté.

Le sentiment de promesse et de nécessité de ce projet était bien sûr stimulant.

Le lendemain, nous sommes allés déjeuner avec l'équipe et avons discuté de ce à quoi ressemblerait la fonctionnalité minimale de l'application.

En conséquence, la liste suivante de ce qui devait être fait lors du hackathon a été dressée :

• Connectez-vous à la caisse de livraison.
• Afficher la position actuelle.
• Envoyer des données à une API externe (coordonnées, réception de la commande, livraison de la commande).
• Recevez des données d'API externes (commandes de messagerie en cours).
• Envoyez un événement indiquant que vous avez pris la commande en livraison/livrée.
• Affichez la position actuelle du coursier sur la carte du site Internet.

Le travail principal, semble-t-il, consistait à créer le backend, l'application elle-même (après discussions, nous avons choisi ReactNative pour développer l'application, ou plutôt le framework pour celle-ci - expo.io, ce qui permet de ne pas écrire du tout de code natif). En ce qui concerne le backend, il y avait au départ de l'espoir chez Vanya Zverev, car il avait de l'expérience dans le travail avec notre modèle de service et les k8 (travail qu'il a accepté). Andrey Sarafanov et moi avons essayé ReactNative.

J'ai décidé d'essayer de créer immédiatement un référentiel fonctionnel pour le projet lui-même. A minuit, je suis tombé sur le fait que la géolocalisation en arrière-plan ne fonctionne pas bien dans ReactNative, si on n'écrit pas de code natif, j'étais un peu frustré. Puis j'ai lâché prise quand j'ai réalisé que je lisais la documentation non pas du framework expo.io, mais de ReactNative. Du coup, au fil de la soirée j'ai déjà compris comment obtenir la position actuelle dans expo.io et dessiner des écrans séparés (pour la connexion, l'affichage des commandes, etc.).

Le matin du hackathon, ils ont attiré Gleb dans leur projet ultra prometteur. Ils ont rapidement élaboré un plan de ce qui devait être fait.

Nous avons commis une erreur lorsque, conformément au modèle du projet, nous avons essayé de communiquer non pas via HTTP, mais via GRPC, car personne ne savait comment créer un client GRPC pour JavaScript. Finalement, après y avoir consacré environ une heure et demie, nous avons abandonné cette idée. Pour cette raison, les gars du back-end ont commencé à refaire le serveur fini de GRPC vers WebApi. Au bout d'une demi-heure, nous avons enfin pu établir la communication entre l'application et le backend, et voilà. Mais en même temps, Gleb terminait presque le déploiement sur les k8 et le déploiement automatique d'un commit sur le maître. 🙂

Nous avons choisi MySQL comme stockage pour ne pas prendre de risques au moins avec la base de données (nous avions pensé à CosmosDb).

En résumé:

• Implémentation de l'enregistrement des coordonnées actuelles du coursier de l'application dans la base de données.
• Nous avons installé RabbitMQ et nous sommes abonnés aux messages concernant le coursier récupérant une commande afin d'afficher immédiatement la commande du coursier dans l'application.
• Nous avons commencé à enregistrer le délai de livraison de la commande dans notre base de données après que le coursier ait appuyé sur un bouton dans l'application. Nous n'avons pas eu le temps d'ajouter le renvoi d'un événement au rebbit indiquant que la commande a été livrée.
• J'ai fait un affichage cartographique sur la page de commande actuelle du site Web avec la position actuelle du coursier. Mais cette fonctionnalité restait un peu inachevée, puisqu'il n'était pas possible de configurer CORS dans l'environnement pour recevoir les coordonnées de notre nouveau service.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artyom Trofimushkin

Nous voulions implémenter un fournisseur OpenID Connect, car nous utilisons actuellement un protocole d'authentification de notre propre conception, ce qui crée un certain nombre de difficultés : bibliothèques client personnalisées, travail peu pratique de la part de partenaires externes, problèmes de sécurité possibles (après tout , OAuth2.0 et OpenID Connect dans l'implémentation de référence peuvent être considérés comme sûrs, mais je ne suis pas sûr de notre solution).

Nous avons créé un service distinct émulant un service de stockage de données personnelles afin de créer un petit modèle indépendant du pays d'un fournisseur d'authentification qui irait vers un service distinct pour les données personnelles (cela permettrait à l'avenir d'avoir un service avec lequel on peut se connecter avec un compte enregistré dans n'importe quel pays, et en même temps se conformer au RGPD et aux autres lois fédérales). Nous avons réalisé cette partie, tout comme le fournisseur, et les avons réussi à relier les uns aux autres. Ensuite, il a fallu créer une API qui serait protégée par des jetons émis par le fournisseur, prendrait en charge leur introspection via le fournisseur et renverrait des données protégées si la demande satisfaisait aux politiques d'autorisation (nous vérifions que l'utilisateur est authentifié selon le schéma Bearer , son token contient une certaine portée + y L'utilisateur lui-même dispose d'une autorisation qui permet d'effectuer l'appel). Cette partie a également été complétée. Le dernier composant était un client JavaScript, qui recevrait un jeton avec lequel il appellerait une API protégée. Nous n'avons pas eu le temps de faire cette partie. Autrement dit, toute la partie fonctionnelle était prête, mais la partie frontale n'était pas prête à démontrer la fonctionnalité de l'ensemble du système.

E-E-E (jouet)

Dima Afonchenko, Sacha Konovalov

Nous avons fabriqué un mini-jouet sur Yunka, où des mains fringantes jettent des saucisses sur une pizza. Si vous n'avez pas mis la saucisse correctement, un triste message « Rejeté » apparaît à l'écran, et si toutes les saucisses ont été mises correctement, un fait aléatoire sur la pizza apparaît.

Nous voulions faire un deuxième niveau en lançant des tomates, mais nous n’avions pas le temps.

Petite 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 précieux serait « le chemin de la nourriture ».

Attendez-vous donc à ce que nous annoncions bientôt un jeu avec des mains qui mettent des pepperons sur la pizza.

Comme l’aurait remarqué un lecteur attentif, l’équipe « E-E-E (jouet) » a gagné. Félicitations les gars!

Seuls les utilisateurs enregistrés peuvent participer à l'enquête. se connecters'il te plait.

Quel projet avez-vous préféré ?

• Oleg Learning (apprentissage automatique)

• Interface graphique pour NOOBS

• CourrierGo

• M87

• Euh

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

Source: habr.com