Kodim - pizza

Salut, Habr. Nous avons spontanément organisé le premier hackathon interne. J'ai décidé de partager avec vous mes douleurs et mes conclusions sur sa préparation dans 2 semaines, ainsi que les projets qui se sont avérés.

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

Je vais commencer par une petite histoire.

Début avril. Le premier hackathon MskDotNet Community a lieu dans nos bureaux. La bataille pour Tatooine bat son plein, cette fois dans notre galaxie. Samedi 20 équipes. La pizza Tout est très sincère ( preuves ). R2-D2 gonflable se profile autour du hall. Les équipes écrivent les algorithmes les plus corrects pour passer la course la plus dangereuse sur la carte. On décale le lancement des premières courses. Les cookies et le café économisent. Les organisateurs et moi nous attendions à ce que samedi, beaucoup quittent après le dîner. Mais non. 12 heures de codage derrière. La finale. 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 à Slack et l'idée me vient à l'esprit: "Nous devons faire notre propre hackathon." J'écris à notre station-service Sasha. Le silence.

Le matin Je bois du café au bureau. Je vois Sasha venir de derrière. «Lisa, c'est génial! Nous avons une date importante le 21 avril. Faisons-le! » WTF!? Si vite Hein? Quoi? Je dois me rendre à Syktyvkar pour un stage à la mi-avril. Oui, et au diable avec lui! Allez.

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. Étain. Cela prend quelques mois. Besoin de quelques personnes. Il est nécessaire de réfléchir sur le merch, les prix, les conditions, le calendrier, l'intérêt, de comprendre l'objectif, les budgets. Ou peut-être même comprendre le sens de la vie. Je n’aurai certainement pas le temps. Et pendant que vous lisez et préparez, une semaine s'est écoulée. Il est temps de marquer des articles et de commencer à faire quelque chose.

La partie la moins ennuyeuse de la date du hackathon

Pourquoi le 21 avril? Cette journée est importante pour nous. Il y a exactement un an, le 21 avril, nous sommes tombés sous charge pendant le premier week-end après le début de la campagne de publicité fédérale. Le lendemain, dimanche, notre équipe était au travail à partir de 8 heures du matin. Nous avons ensuite créé une planche de sundayhackathon à Trello et commencé une semaine de travail de 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 la page de Fedor Ovchinnikov (notre PDG). Depuis lors, nous avons beaucoup changé, mais maintenant nous n'oublierons certainement pas la date.

Cette année, nous avons décidé que cet événement devait être immortalisé dans la mémoire des descendants, et dans les meilleures traditions 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 Lörning (voitures lörning)

Dima Kochnev, Sasha Andronov (@alexandronov)

Ils voulaient créer un réseau de neurones qui déterminerait le type de pizza sur la photo sans aucune connaissance. En conséquence, ils en ont fait un très simple et jouet - il reconnaît 10 pizzas, a compris comment tout fonctionne, combien c'est possible en une journée (~ 10 heures).



En particulier, nous avons réalisé que l'industrie a atteint le point où un développeur ordinaire peut prendre des bibliothèques prêtes à l'emploi, lire la documentation et former son réseau de neurones sans connaissance approfondie du sujet. Et cela fonctionnera assez bien pour résoudre de vrais problèmes.

Outils qui utilisaient:

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

Nous avions 11 000 photos, mais près des 3/4 d'entre elles se sont avérées être des ordures, et les autres ont montré des angles différents et inappropriés. En conséquence, nous avons pris le modèle fini (qui sait juste trouver la pizza) et avec son aide, nous avons séparé le plus de déchets. De plus, au nom de la photo, il y avait le nom de la pizza - c'est ainsi que nous les avons mis dans des dossiers, mais il s'est avéré que les noms ne coïncidaient pas avec la réalité et nous devions les nettoyer avec nos mains. En conséquence, il restait environ 500 à 600 photos, il est clair que c'est une quantité insignifiante, mais néanmoins, cela s'est avéré suffisant pour séparer 10 pizzas les unes des autres.

Pour former le réseau, ils ont pris la machine virtuelle la moins chère d'Azure sur la NVIDIA Tesla K80. Il a été formé dans 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 est le manque de bonnes données.



Nous avons peut-être un peu mélangé en termes, mais nous devons garder à l'esprit que nous n'avons généralement pas d'expérience dans le traitement de toutes ces questions.

GUI pour NOOBS (console de commande de pizza)

Misha Kumachev ( Ceridan ), Zhenya Bikkinin, Zhenya Vasiliev

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



Le travail a été divisé en plusieurs parties: nous avons trié la façon dont notre API pour les applications mobiles est organisée, assemblé notre propre CLI à l'aide d' oclif et mis en place la publication du package que nous avons assemblé. La dernière tâche a été associée à plusieurs minutes désagréables vers la fin du hackathon. Tout a fonctionné pour nous localement et même les anciennes versions publiées du package ont fonctionné, mais les nouvelles (dans lesquelles des fonctionnalités et des émoticônes plus intéressantes ont été ajoutées) ont refusé de fonctionner. Nous avons passé 40 minutes pour comprendre ce qui n'allait pas, mais au final, tout a fonctionné comme par magie).

Notre programme de hackathon maximum était une vraie commande de pizza au bureau via notre CLI. Nous avons tout piloté une douzaine de fois sur le banc d'essai, mais mes mains tremblaient quand je marquais des équipes au prod.



En conséquence - nous l'avons toujours fait!

Courier go

Anton Bruzhmelyov (auteur), Vanya Zverev, Gleb Lesnikov ( entropie ), Andrey Sarafanov

Nous avons pris l'idée de «Demande de courrier».




Le matin du hackathon, Gleb a été entraîné dans son projet super prometteur. Ils ont rapidement établi un plan de ce qui doit être fait.



Ils ont fait une erreur lorsque, conformément au modèle de projet, ils ont tenté de communiquer non pas via HTTP, mais via GRPC, car personne ne savait comment créer un client GRPC pour JavaScript. En conséquence, après avoir consacré environ une heure et demie à cela, ils ont abandonné cette idée. Pour cette raison, les gars et à l'arrière ont commencé à refaire le serveur fini de GRPC à WebApi. Après une demi-heure, finalement, nous avons pu configurer la communication de l'application avec le backend, et voilà. Mais en même temps, Gleb a presque terminé le déploiement en k8 et en plus l'auto-acte en s'engageant auprès du maître. :)

En tant que référentiel, nous avons choisi MySQL pour ne pas risquer même la base (il y a eu des réflexions sur CosmosDb).



En résumé:

• Implémentation de l'enregistrement des coordonnées de messagerie actuelles de l'application dans la base de données.
• Ils ont foutu RabbitMQ et se sont abonnés à des messages sur le courrier prenant la commande afin d'afficher immédiatement la commande du courrier dans l'application.
• Nous avons commencé à gagner du temps pour la livraison de la commande à notre base de données, après que le coursier ait cliqué sur un bouton dans l'application. Nous n'avons pas eu le temps d'ajouter le renvoi de l'événement au rebbit pour indiquer que la commande a été livrée.
• J'ai fait un affichage de carte sur la page de commande actuelle sur le site avec la position actuelle du courrier. Mais cette fonctionnalité est restée un peu inachevée, car l'environnement n'a pas pu configurer CORS pour obtenir les coordonnées de notre nouveau service.

M87

Roma Bukin, Gosha Polevoy ( georgepolevoy ), Artyom Trofimushkin

Nous voulions implémenter le fournisseur OpenID Connect, car pour le moment nous utilisons un protocole d'authentification de notre propre conception, ce qui crée un certain nombre de difficultés: bibliothèques clientes personnalisées, travail incommode de partenaires externes, et éventuellement problèmes de sécurité (après tout, OAuth2.0 et OpenID Connect dans la mise en œuvre de référence peut être considérée comme sûre, mais comme pour notre solution - je ne suis pas sûr).



Nous avons créé un service distinct émulant un service de stockage de données personnelles afin de créer un petit modèle du fournisseur d'authentification Country-Agnostic qui irait à un service distinct pour les données personnelles (cela permettrait à l'avenir d'avoir un service avec lequel vous pourriez vous connecter avec votre compte enregistrer dans n'importe quel pays, et en même temps se conformer au RGPD et à d'autres lois fédérales). Nous avons fait cette partie, comme le fournisseur, et avons réussi à les relier les uns aux autres. Ensuite, nous devions créer une API qui serait protégée par des jetons émis par le fournisseur, prendre en charge leur introspection via le fournisseur et envoyer des données protégées si la demande satisfaisait aux politiques d'autorisation (nous vérifions que l'utilisateur est authentifié à l'aide du schéma Bearer, son jeton contient une certaine étendue + l'utilisateur dispose lui-même des autorisations lui permettant de passer l'appel). Cette partie est également terminée. Le dernier composant était un client JavaScript qui recevrait un jeton, avec lequel il appellerait une API sécurisée. Nous n'avons pas réussi à faire cette partie. Autrement dit, la partie fonctionnelle entière était prête, mais la partie frontale n'était pas prête à démontrer l'opérabilité de l'ensemble du système.

Euh (igruha)

Dima Afonchenko, Sasha Konovalov

Nous avons fait un mini-jouet sur un petit où les poignées fringantes mettent la saucisse sur la pizza. Si vous avez mal lancé une saucisse, le triste message «Rejeté» apparaît à l'écran et si la saucisse entière est lancée correctement, un fait aléatoire sur la pizza apparaît.



Ils voulaient faire le deuxième niveau avec une tartinade de tomates, mais n'avaient pas le temps.

Courte 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 la route de la nourriture serait le prix le plus précieux.



Par conséquent, attendez bientôt de nous l'annonce du jeu avec des poignées garnissant le pepperoni sur la pizza.

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