🥇Code und Pizza

Hallo, Habr. Wir haben spontan unser erstes internes Hackathon veranstaltet. Ich möchte meine Erfahrungen und Erkenntnisse über die Vorbereitung in den letzten zwei Wochen sowie die entstandenen Projekte mit euch teilen.

Der langweilige Teil für diejenigen, die sich für Marketing interessieren.

Ich fange mit einer kleinen Geschichte an.

Anfang April. In unserem Büro findet das erste Hackathon der MskDotNet Community statt. Der Kampf um Tatooine ist in vollem Gange, diesmal in unserer Galaxie. Samstag. 20 Teams. Pizza. Alles sehr herzlich (Beweise). Ein aufblasbarer R2-D2 schwebt durch den Raum. Die Teams entwickeln die besten Algorithmen, um das gefährlichste Rennen auf der Karte zu gewinnen. Wir verschieben den Start der ersten Rennen. Kekse und Kaffee helfen uns. Wir hatten von den Organisatoren erwartet, dass viele am Samstag nachmittags gehen würden. Aber das passierte nicht. 12 Stunden Programmierung sind vorbei. Das Finale. Etwas fällt aus, etwas lässt sich nicht starten. Aber alle sind glücklich. Unser Team gewinnt. Wir sind doppelt glücklich.

Ich teile die Freude im Slack und mir kommt die Idee: „Wir sollten unser eigenes Hackathon veranstalten“. Ich schreibe unserem CTO Sascha. Stille.

Morgen. Ich trinke Kaffee im Büro. Ich sehe Sasha, die von hinten näherkommt. „Lisa, das ist großartig! Am 21. April steht uns ein wichtiges Datum bevor. Lass uns das angehen!“ Was zum Teufel!? So schnell? Häh? Ich muss Mitte April nach Syktyvkar für mein Praktikum fliegen. Aber egal! Lass uns loslegen.

Es bleiben noch 2 Wochen. Ich war noch nie der alleinige Organisator eines Hackathons. Auch nicht intern. Ich lese Artikel zu diesem Thema. Das ist verrückt. Man braucht Monate. Man braucht ein paar Leute. Man muss Merchandise, Preise, Bedingungen, den Zeitplan durchdenken, die Leute begeistern, das Ziel verstehen, Budgets festlegen. Vielleicht sogar über den Sinn des Lebens nachdenken. Ich werde es auf keinen Fall schaffen. Während du gelesen und dich vorbereitet hast, ist bereits eine Woche vergangen. Es ist höchste Zeit, die Artikel zu ignorieren und endlich etwas zu unternehmen.

Hier ist unsere Checkliste zur Durchführung eines internen Hackathons in 1 Woche.

Gliederung: Du setzt dich entspannt hin und schreibst eine Liste der Dinge, die für den Hackathon erledigt werden müssen. 30 Minuten.
Ziel: Die Teilnehmer schlagen selbst Projekte vor und wählen, an denen sie in Google Sheets arbeiten möchten. Hintergrundaufgabe, 2 Stunden.
Zeitplan: Du schreibst schnell eine kurze Zeitaufteilung mit Berücksichtigung von 3 Pausen und dem Finale. 20 Minuten.
Befehle: Du veröffentlichst eine Nachricht über den Hackathon mit dem Zeitplan vom CTO in IT-Kanälen auf Slack/E-Mail/etc. und erstellst einen eigenen Kanal für den Hackathon. Dort bilden sich die Teams, während die Unentschlossenen dies in den ersten 5 Minuten des Hackathons erledigen. Hintergrundaufgabe, 2 Stunden.
Extras: Du entwickelst Merchandise mit zwei Entwicklern, gibst es dem Designer zur Illustration und erhältst das fertige Produkt. Hintergrundaufgabe, 3 Tage.
Hackathon: Du kommst ins Büro, koordinierst zu Beginn alle, kümmerst dich um deine Aufgaben, liest Reddit, informierst mit wichtiger Miene in jeder Pause über frische Pizza, machst Fotos vom Sonnenuntergang, kündigst das Finale an, wählt gemeinsam aus und kürt den Gewinner. 1 Tag.
Unter dem Sternchen: Natürlich denkst du ständig darüber nach, dass alles gut laufen sollte. Sicherlich werden nicht alle deine Nachricht sehen, und mit einigen ist es besser, persönlich zu sprechen. Natürlich wird es doppelt so einfach, wenn dir jemand hilft (die wunderbare Alena hat mir geholfen).

Weniger langweiligen Teil über das Datum des Hackathons

Warum der 21. April? Dieser Tag ist bedeutend für uns. Vor genau einem Jahr, am 21. April, sind wir unter der Last während des ersten Wochenendes nach dem Start der Bundeswerbung zusammengebrochen. Am nächsten Tag, am Sonntag, war unser Team ab 8 Uhr morgens bei der Arbeit. Da haben wir im Trello ein Board namens sundayhackathon erstellt und eine Woche mit 12-Stunden-Schichten begonnen. Die Situation war so kritisch, dass wir nicht einmal Zeit zum Essen hatten und von anderen Teams versorgt wurden.

Eine detaillierte Erzählung können Sie lesen auf Fjodor Ovchinnikovs Seite (unserem CEO). Seitdem haben wir viel geändert, aber dieses Datum werden wir sicher nicht vergessen.

In diesem Jahr haben wir beschlossen, dieses Ereignis für die Nachwelt festzuhalten und haben in besten Traditionen den ersten internen Hackathon in der Geschichte von Dodo veranstaltet, der 10 Stunden dauerte.

Der interessanteste Teil über die Projekte des Hackathons

Disclaimer: Alle Beschreibungen wurden von den Teilnehmern selbst verfasst, daher ist der Text nicht von mir.

Oleg Learning (Machine Learning)

Dima Kochnev, Sasha Andronov (@alexandronov)

Wir wollten ein neuronales Netzwerk entwickeln, das ohne jegliches Wissen erkennen kann, um welche Pizza es sich auf einem Foto handelt. Am Ende haben wir eine sehr einfache und spielerische Version geschaffen – sie erkennt 10 Pizzas und wir haben grob verstanden, wie alles funktioniert, so weit dies an einem Tag (~10 Stunden) möglich ist.

Insbesondere haben wir festgestellt, dass die Branche ein Niveau erreicht hat, bei dem ein normaler Entwickler fertige Bibliotheken nutzen, die Dokumentation lesen und sein eigenes neuronales Netzwerk ohne tiefgehende Kenntnisse des Themas trainieren kann. Und es wird ausreichend gut funktionieren, um reale Probleme zu lösen.

Verwendete Werkzeuge:

imageai – eine benutzerfreundliche und einfache Bibliothek für maschinelles Lernen und Computer Vision.
Wir haben zwei Modelle ausprobiert – ResNet50 und Yolo.
Den Code haben wir, wie sich versteht, in Python geschrieben.

Wir hatten 11.000 Fotos, aber fast 3/4 davon waren unbrauchbar, und die verbleibenden hatten verschiedene, ungeeignete Perspektiven. Schließlich haben wir ein fertiges Modell verwendet (das einfach in der Lage ist, Pizza zu finden), um den größten Müll herauszufiltern. Dann haben wir die Fotos mit dem Namen der Pizza sortiert – aber es stellte sich heraus, dass die Bezeichnungen nicht mit der Realität übereinstimmten, also mussten wir manuell nachbearbeiten. Am Ende blieben etwa 500-600 Fotos übrig, was natürlich eine sehr geringe Anzahl ist, aber dennoch genug, um 10 Pizzen voneinander zu unterscheiden.

Für das Training des Netzwerks haben wir die günstigste virtuelle Maschine in Azure mit NVIDIA Tesla K80 genommen. Damit haben wir in 100 Epochen trainiert, aber es war bereits nach 50 Epochen zu erkennen, dass das Netzwerk gesättigt war, da der Datensatz zu klein war.

Die eigentliche Problematik liegt im Fehlen guter Daten.

Wir haben vielleicht die Begriffe etwas durcheinandergebracht, aber man muss berücksichtigen, dass wir überhaupt keine Erfahrung mit all diesen Dingen haben.

GUI für Anfänger (Konsole zum Bestellen von Pizza)

Misha Kumachev (Ceridan), Zhenya Bikkinin, Zhenya Vasiliev

Wir haben einen Prototyp einer Konsolenanwendung für Enthusiasten entwickelt, mit dem man Pizza über das Terminal oder die Kommandozeile bestellen kann, oder sogar in den Deploy-Pipeline integrieren und bei erfolgreichem Release Pizza ins Büro liefern lassen kann.

Die Arbeit wurde in mehrere Teile gegliedert: Wir haben uns damit beschäftigt, wie unsere API für mobile Anwendungen funktioniert, und haben unser eigenes CLI mit Hilfe von oclif erstellt und die Veröffentlichung unseres Pakets konfiguriert. Bei dieser letzten Aufgabe hatten wir einige unangenehme Momente gegen Ende des Hackathons. Alles funktionierte lokal, und sogar ältere veröffentlichte Versionen des Pakets liefen, aber die neuen (die mehr coole Funktionen und Emojis enthielten) weigerten sich zu arbeiten. Wir haben etwa 40 Minuten damit verbracht, herauszufinden, was schiefgelaufen war, aber schließlich funktionierte alles auf magische Weise von selbst.)

Unser maximales Ziel beim Hackathon war eine echte Bestellung von Pizza ins Büro über unser CLI. Wir haben alles ein Dutzend Mal auf dem Teststand durchgespielt, aber ich hatte trotzdem zitternde Hände, als ich die Befehle im Produktivsystem eingab.

Als Ergebnis – wir haben es tatsächlich geschafft!

CourierGo

Anton Bruzhmelov (Autor), Vanya Zverev, Gleb Lesnikov (entropy), Andrey Sarafanov

Wir haben die Idee für die „Kurier-App“ aufgegriffen.

Hintergrund zur Vorbereitung.Zunächst habe ich überlegt, welche Funktionen die App haben könnte. Dabei entstand ungefähr folgende Liste an Funktionen:

Die App loggt sich mit einem Code in das Liefersystem ein.
In der App sind die verfügbaren Aufträge sowie die Aufträge, die übernommen werden müssen, sofort sichtbar.
Der Kurier markiert den Auftrag und übernimmt ihn für die Fahrt.
Es wird ihm die voraussichtliche Ankunftszeit angezeigt und ob er es rechtzeitig schafft oder nicht.
Dem Kunden wird angezeigt, dass der Kurier aufgebrochen ist.
Der Kunde sieht den Standort des Kuriers auf der Karte und die voraussichtliche Ankunftszeit.
Der Kurier kann dem Kunden über den Chat in der App schreiben.
Der Kunde kann dem Kurier über den Chat in der App schreiben.
Fünf Minuten vor der Ankunft erhält der Kunde eine Nachricht, dass der Kurier bald da ist, er sollte bereit sein.
Der Kurier markiert in der App, dass er angekommen ist und wartet.
Der Kurier kann mit einem Klick aus der App anrufen und mitteilen, dass er (angekommen ist, sich nähert usw.).
Der Kunde nimmt den Auftrag an und gibt den PIN-Code aus der App oder SMS zur Bestätigung der Lieferung ein (wie eine Unterschrift). Damit der Kurier die Lieferung nicht vorzeitig abschließen kann, falls er verspätet ist.
Der Auftrag wird im System als geliefert gekennzeichnet.

Zusätzlich einige alternative Szenarien:

Der Kurier kann die Bestellung als nicht zugestellt markieren und einen Grund wählen.
Wenn der Kurier verspätet ist, kann er mit einem Klick ein elektronisches Zertifikat per SMS ausstellen. Oder das Zertifikat wird automatisch verschickt, wenn die Lieferfrist nicht eingehalten wird.

Das Gefühl der Perspektive und Notwendigkeit dieses Projekts hat natürlich motiviert.

Am nächsten Tag gingen wir mit dem Team zum Mittagessen und besprachen, wie das minimale Funktional des Apps aussehen würde.

Insgesamt entstand die folgende Liste von Aufgaben, die wir während des Hackathons erledigen wollten:

Einloggen in die Lieferkasse.
Aktuellen Standort anzeigen.
Daten an eine externe API senden (Koordinaten, Bestellung abgeholt, Bestellung geliefert).
Daten von einer externen API abrufen (aktuelle Bestellungen des Kuriers).
Event senden, dass die Bestellung zur Lieferung abgeholt wurde / geliefert wurde.
Den aktuellen Standort des Kuriers auf der Karte auf der Website anzeigen.

Die Hauptarbeit lag, wie es schien, in der Erstellung des Backends und der Anwendung (nach Diskussionen wählten wir ReactNative für die Entwicklung der App, genauer gesagt das Binding darüber — expo.io, die es ermöglicht, überhaupt keinen nativen Code zu schreiben). Im Backend gab es zunächst die Hoffnung auf Wanja Zvereve, der erfahren mit unserem Service-Template und k8s ist (welche Arbeit er sich auch gleich vorgenommen hat). ReactNative haben Andrej Sarafanov und ich uns angeschaut.

Ich habe beschlossen, sofort ein Arbeitsrepository für das Projekt zu erstellen. Um Mitternacht stieß ich darauf, dass die Geolokalisierung in ReactNative im Hintergrund schlecht funktioniert, wenn man keinen nativen Code schreibt, was mich etwas frustrierte. Dann beruhigte ich mich, als ich erkannte, dass ich die Dokumentation des Frames von expo.io anstatt von ReactNative las. Am Ende des Abends war mir schon klar, wie ich in expo.io meinen aktuellen Standort erhalten und separate Bildschirme gestalten kann (für den Login, die Anzeige der Bestellung usw.).

Am Morgen des Hackathons wurde Gleb für unser vielversprechendes Projekt gewonnen. Wir haben schnell einen Plan für die notwendigen Aufgaben aufgestellt.

Wir haben einen Fehler gemacht, als wir versuchten, die Kommunikation nicht über HTTP, sondern über gRPC gemäß dem Projektschablone aufzubauen, da niemand wusste, wie man einen gRPC-Client für JavaScript erstellt. Letztendlich haben wir etwa anderthalb Stunden damit verbracht und die Idee verworfen. Deshalb begannen die Kollegen, den fertigen Server von gRPC auf WebApi umzustellen. Nach einer halben Stunde gelang es uns schließlich, die Kommunikation zwischen der Anwendung und dem Backend einzurichten. O Wunder. Gleichzeitig war Gleb fast mit dem Deployment in k8s fertig und hatte zudem das Auto-Deployment bei jedem Commit in den Master eingerichtet. 🙂

Als Datenbank haben wir MySQL gewählt, um zumindest mit der Datenbank kein Risiko einzugehen (wir hatten auch über CosmosDb nachgedacht).

Ergebnis:

Wir haben die aktuellen Koordinaten des Kuriers aus der Anwendung in der Datenbank gespeichert.
Wir haben RabbitMQ integriert und uns für die Nachrichten über die Annahme von Bestellungen durch den Kurier angemeldet, um die Bestellung sofort im Anwendungsfenster des Kuriers anzuzeigen.
Wir haben begonnen, die Lieferzeiten in unserer Datenbank zu speichern, nachdem der Kurier auf die Schaltfläche in der Anwendung gedrückt hatte. Wir haben es nicht geschafft, das Ereignis zurück an RabbitMQ zu senden, dass die Bestellung geliefert wurde.
Ich habe auf der Seite currentorder eine Kartenansicht mit dem aktuellen Standort des Kurriers implementiert. Dieser Funktionsumfang ist jedoch noch nicht ganz vollständig, da es in der Umgebung nicht gelungen ist, CORS für den Zugriff auf die Koordinaten aus unserem neuen Dienst einzurichten.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artyom Trofimushkin

Wir wollten einen OpenID Connect-Provider implementieren, da wir derzeit ein selbst entwickeltes Authentifizierungsprotokoll verwenden, was einige Schwierigkeiten mit sich bringt: benutzerdefinierte Clientbibliotheken, unkomfortable Zusammenarbeit mit externen Partnern und möglicherweise Sicherheitsprobleme (denn OAuth2.0 und OpenID Connect gelten in ihrer Referenzimplementierung als sicher, während ich bei unserer Lösung nicht ganz sicher bin).

Wir haben einen separaten Dienst erstellt, der einen Service zur Speicherung personenbezogener Daten emuliert, um ein kleines Modell eines länderunabhängigen Authentifizierungsanbieters zu schaffen. Dieser würde personenbezogene Daten an einen separaten Dienst weiterleiten (langfristig würde dies die Möglichkeit bieten, einen einzigen Dienst zu nutzen, mit dem man sich mit einem Konto in jedem Land anmelden und dabei die GDPR sowie andere gesetzliche Anforderungen einhalten könnte). Diese Komponente haben wir erfolgreich mit dem Anbieter verknüpft. Der nächste Schritt war die Erstellung einer API, die durch Tokens geschützt ist, welche der Anbieter ausstellt, sowie die Introspektion dieser Tokens über den Anbieter. Geschützte Daten sollten nur ausgegeben werden, wenn die Anfragen den Autorisierungsrichtlinien entsprachen (wir überprüfen, ob der Benutzer gemäß dem Bearer-Schema authentifiziert ist, ob sein Token einen bestimmten Scope enthält und ob der Benutzer die Berechtigung zur Durchführung des Aufrufs hat). Auch dieser Teil wurde umgesetzt. Der letzte Bestandteil war ein JavaScript-Client, dem ein Token zugewiesen werden sollte, um den geschützten API-Aufruf durchzuführen. Dieser Teil konnte nicht rechtzeitig abgeschlossen werden. Das komplette funktionale Modul war zwar fertig, jedoch die Frontend-Komponente zur Demonstration der gesamten Systemfunktionalität nicht.

E-E-E (Spiel)

Dima Afonchenko, Sasha Konovalov

Wir haben ein Mini-Spiel auf Unity erstellt, bei dem flinke Hände Wurststücke auf die Pizza werfen. Wenn du die Wurst falsch wirfst, erscheint auf dem Bildschirm der traurige Hinweis „Abgelehnt“. Wenn jedoch die Wurststückchen richtig platziert sind, wird ein zufälliger Fakt über Pizza angezeigt.

Wir wollten ein zweites Level mit dem Werfen von Tomaten machen, hatten aber nicht genug Zeit.

Kurze Fortsetzung: Wer hat gewonnen?

Vor dem Hackathon haben wir mit den Teilnehmern gesprochen und ich fragte sie, welcher Preis sie bei einem Sieg gerne erhalten würden. Es stellte sich heraus, dass der wertvollste Preis „die Reise ins Prod“ sein würde.

Erwartet also bald von uns die Ankündigung eines Spiels, in dem Hände Peperoni auf die Pizza werfen.