🥇Kodieren–Pizza

Hallo, Habr. Wir haben spontan unseren ersten internen Hackathon durchgeführt. Ich wollte meine Schmerzen und Schlussfolgerungen zur Vorbereitung innerhalb von 2 Wochen mit euch teilen, sowie die Projekte, die entstanden sind.

Langweilige Teile für diejenigen, die sich für Marketing interessieren

Ich beginne mit einer kleinen Geschichte.

Anfang April. In unserem Büro findet der erste Hackathon der MskDotNet Community statt. Der Kampf um Tatooine ist eröffnet, diesmal in unserer Galaxie. Samstag. 20 Teams. Pizza. Alles ist sehr herzlich (Beweise). Ein aufblasbarer R2-D2 schwebt durch den Raum. Die Teams schreiben die besten Algorithmen, um das gefährlichste Rennen auf der Karte zu gewinnen. Wir verschieben den Start der ersten Rennen. Kekse und Kaffee retten uns. Wir, die Organisatoren, hatten erwartet, dass viele am Samstag nach dem Mittagessen gehen würden. Aber nicht. 12 Stunden Programmierung liegen hinter uns. Finale. Etwas fällt aus, etwas startet nicht. Aber alle sind glücklich. Unser Team gewinnt. Wir sind doppelt glücklich.

Ich teile meine Freude in Slack und mir kommt die Idee: "Wir sollten unseren eigenen Hackathon veranstalten". Ich schreibe unserem CTO Sascha. Stille.

Morgen. Ich trinke Kaffee im Büro. Ich sehe Sascha von hinten auf mich zukommen. "Lisa, das ist großartig! Wir haben genau am 21. April ein wichtiges Datum. Lass es uns machen!" WTF!? So schnell? Hä? Was? Ich muss Mitte April nach Syktyvkar zur Ausbildung fliegen. Egal, lass es uns machen.

Es bleiben 2 Wochen. Ich war noch nie die alleinige Organisatorin eines Hackathons. Auch nicht eines internen. Ich lese Artikel zu diesem Thema. Wahnsinn. Man braucht mehrere Monate. Man braucht mehrere Personen. Man muss Merchandise, Preise, Bedingungen, einen Zeitplan ausdenken, Interesse wecken, Ziel verstehen, Budgets. Vielleicht muss ich sogar den Sinn des Lebens herausfinden. Es wird ganz sicher nichts. Und während du gelesen und dich vorbereitet hast, ist bereits eine Woche vergangen. Es ist die höchste Zeit, die Artikel zu ignorieren und mit der Arbeit zu beginnen.

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

Plan: Du setzt dich ruhig hin und schreibst eine Liste von Dingen, die für den Hackathon erledigt werden müssen. 30 Minuten.
Aufgabe: Die Teilnehmer schlagen selbst die Projekte vor und wählen sie aus, die sie in Google Sheets erstellen möchten. Hintergrundaufgabe, 2 Stunden.
Zeitplan: Du schreibst schnell einen kurzen Zeitplan mit 3 Pausen und dem Finale. 20 Minuten.
Befehle: Du veröffentlichst eine Nachricht über den Hackathon mit dem Zeitplan vom CTO in den IT-Kanälen in Slack/E-Mail/etc. und erstellst einen separaten Kanal für den Hackathon. Dort teilen sich alle in Teams auf, und diejenigen, die sich nicht entschieden haben, tun dies in den ersten 5 Minuten des Hackathons. Hintergrundaufgabe, 2 Stunden.
Anreize: Du planst Merchandise mit zwei Entwicklern, gibst es dem Designer zur Ausarbeitung und erhältst das Ergebnis. Hintergrundaufgabe, 3 Tage.
Hackathon: Du kommst ins Büro, koordinierst am Anfang alle, kümmerst dich um deine eigenen Sachen, liest Reddit, informierst mit ernstem Gesicht über jede Pause über frische Pizza, machst Fotos vom Sonnenuntergang, kündigst das Finale an, wählst zusammen und wählt den Gewinner aus. 1 Tag.
Unter dem Sternchen: Natürlich denkst du ständig daran, dass alles gut verläuft. Natürlich werden nicht alle deine Nachricht sehen und mit einigen ist es besser, persönlich zu sprechen. Natürlich, wenn dir jemand hilft, wird alles doppelt so einfach (mir hat die wunderbare Aljena geholfen).

Der weniger langweilige Teil über das Datum des Hackathons

Warum der 21. April? Dieser Tag ist für uns bedeutend. Genau vor einem Jahr, am 21. April, sind wir während der ersten Osterferien nach der Start der Bundeswerbungskampagne unter Last zusammengebrochen. Am nächsten Tag, am Sonntag, war unser Team ab 8 Uhr morgens bei der Arbeit. Damals haben wir im Trello-Board sundayhackathon erstellt, und die Woche mit 12-Stunden-Schichten begann. Die Situation war so kritisch, dass wir nicht einmal Zeit zum Essen hatten und uns von Leuten aus anderen Teams verpflegt wurden.

Eine detailliertere Geschichte kannst du auf Fjodor Owtschinnikows Seite (unserem CEO) lesen. Seitdem haben wir viel verändert, aber das Datum werden wir jetzt ganz sicher nicht vergessen.

In diesem Jahr haben wir beschlossen, dass dieses Ereignis in Erinnerung bleiben sollte, und in bester Tradition organisierten wir den ersten internen Hackathon in der Geschichte von Dodo, der 10 Stunden dauerte.

Der interessanteste Teil über die Projekte des Hackathons

Haftungsausschluss: Alle Beschreibungen wurden von den Jungs selbst geschrieben, daher gehört das Urheberrecht nicht mir.

Oleg Learning (Machine Learning)

Dima Kochnev, Sasha Andronov (@alexandronov)

Wir wollten ein neuronales Netzwerk erstellen, das erkennt, welche Pizza auf dem Foto abgebildet ist, ohne irgendwelche Vorkenntnisse. Am Ende haben wir ein sehr einfaches und spielerisches gemacht – es erkennt 10 Pizzen und wir haben ungefähr verstanden, wie alles funktioniert, so gut es eben an einem Tag (~10 Stunden) möglich ist.

Insbesondere haben wir verstanden, dass die Branche einen Punkt erreicht hat, an dem ein gewöhnlicher Entwickler fertige Bibliotheken nutzen, die Dokumentation lesen und sein eigenes neuronales Netzwerk ohne tiefgehende Fachkenntnisse trainieren kann. Und es wird ausreichend gut für die Lösung realer Aufgaben funktionieren.

Die Werkzeuge, die wir verwendet haben:

imageai — eine benutzerfreundliche und einfache Bibliothek für maschinelles Lernen und Computer Vision.
Wir haben zwei Modelle ausprobiert – ResNet50, Yolo.
Der Code wurde, wie sollte es auch anders sein, in Python geschrieben.

Wir hatten 11.000 Fotos, aber fast 3/4 davon waren unbrauchbar, und bei den verbleibenden gab es verschiedene ungeeignete Perspektiven. Letztendlich haben wir ein fertiges Modell genommen (das einfach in der Lage ist, Pizza zu erkennen) und damit den größten Schrott aussortiert. Danach war im Namen des Fotos der Name der Pizza enthalten — so haben wir sie in Ordner sortiert, aber es stellte sich heraus, dass die Namen nicht mit der Realität übereinstimmten, sodass wir manuell nacharbeiten mussten. Letztendlich blieben etwa 500-600 Fotos übrig, was zwar eine verschwindend kleine Menge ist, aber trotzdem reichte, um 10 Pizzen voneinander zu unterscheiden.

Für das Training des Netzes haben wir die günstigste virtuelle Maschine in Azure auf NVIDIA Tesla K80 genommen. Darauf wurde über 100 Epochen trainiert, doch es war nach 50 Epochen schon zu sehen, dass das Netzwerk gesättigt war, da der Datensatz klein war.

Das eigentliche Problem besteht in der Abwesenheit guter Daten.

Wir haben möglicherweise bei den Begriffen etwas durcheinandergebracht, aber man muss berücksichtigen, dass wir in dieser Hinsicht keinerlei Erfahrung haben.

GUI für NOOBS (Konsole zum Bestellen von Pizza)

Misha Kumachev (Ceridan), Zhenya Bikkinin, Zhenya Vasiliev

Wir haben einen Prototyp eines Konsolenanwendungs für Nerds entwickelt, mit dem man über das Terminal oder die Eingabeaufforderung Pizza bestellen kann, oder sogar in die Deployment-Pipeline integrieren kann, um bei erfolgreichem Release Pizza ins Büro zu liefern.

Die Arbeit wurde in mehrere Teile gegliedert: Wir haben herausgefunden, wie unser API für mobile Anwendungen funktioniert, und haben unser eigenes CLI mit Hilfe von oclif gebaut und die Veröffentlichung des von uns erstellten Pakets konfiguriert. Bei dieser letzten Aufgabe gab es gegen Ende des Hackathons einige unangenehme Minuten. Bei uns hat alles lokal funktioniert und sogar die alten veröffentlichten Versionen des Pakets liefen, aber die neuen (in denen mehr coole Funktionen und Smileys hinzugefügt wurden) weigerten sich, zu funktionieren. Wir haben etwa 40 Minuten damit verbracht zu klären, was schiefgelaufen ist, aber am Ende hat alles auf magische Weise von selbst funktioniert.)

Unser größtes Ziel beim Hackathon war eine echte Pizza-Bestellung ins Büro über unser CLI. Wir haben das zehnmal auf der Testumgebung durchgespielt, aber meine Hände zitterten trotzdem, als ich die Kommandos im Produktivsystem eingab.

Am Ende — wir haben es trotzdem geschafft!

CourierGo

Anton Bruzhmeljow (Autor), Wanja Zverev, Gleb Lesnikow (entropy), Andrei Sarafanow

Wir haben die Idee "App für Kuriere" aufgegriffen.

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

Die App loggt sich mit einem Code in die Lieferkasse ein.
In der App sind sofort die verfügbaren Aufträge sichtbar, die Aufträge, die abzuholen sind.
Der Kurier markiert den Auftrag und nimmt ihn mit auf die Fahrt.
Es wird ihm die geschätzte Ankunftszeit angezeigt und ob er es rechtzeitig schafft oder nicht.
Der Kunde sieht, dass der Kurier losgefahren ist.
Der Kunde sieht die Position des Kuriers auf der Karte sowie die geschätzte Ankunftszeit.
Der Kurier kann dem Kunden über einen Chat in der App schreiben.
Der Kunde kann dem Kurier über einen Chat in der App schreiben.
Fünf Minuten vor der Ankunft erhält der Kunde eine Nachricht, dass der Kurier in der Nähe ist, seien Sie bereit.
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 (kommt, angekommen ist usw.)
Der Kunde nimmt den Auftrag an und gibt den PIN-Code aus der App oder der SMS zur Bestätigung der Lieferung ein. (wie eine Unterschrift) Damit der Kurier die Lieferung nicht vorzeitig abschließen kann, wenn er verspätet ist.
Der Auftrag wird im System als geliefert markiert.

Außerdem ein paar alternative Szenarien:

Der Kurier kann den Auftrag als nicht geliefert kennzeichnen und einen Grund auswählen.
Bei verspäteter Lieferung kann der Kurier auf Knopfdruck ein elektronisches Zertifikat per SMS ausstellen. Oder das Zertifikat wird automatisch versendet, wenn die Lieferfrist nicht eingehalten wird.

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

Am nächsten Tag sind wir mit dem Team zum Mittagessen gegangen und haben besprochen, wie die minimalen Funktionen der App aussehen werden.

Letztendlich entstand folgende Liste von Aufgaben, die wir während des Hackathons erledigen sollten:

Login in die Lieferkasse.
Aktuelle Position anzeigen.
Daten an eine externe API senden (Koordinaten, Auftrag angenommen, Auftrag geliefert).
Daten aus einer externen API abrufen (aktuelle Aufträge des Kuriers).
Ereignis senden, dass der Auftrag zur Lieferung angenommen wurde / geliefert wurde.
Aktuelle Position des Kuriers auf der Karte auf der Webseite anzeigen.

Die Hauptarbeit, wie ich es sah, lag in der Erstellung des Backends, der App selbst (nach Diskussionen entschieden wir uns für ReactNative zur Entwicklung der App, genauer gesagt für die Bindung über – expo.io, die es ermöglicht, überhaupt keinen nativen Code zu schreiben). In Bezug auf das Backend gab es zunächst die Hoffnung auf Wanja Zwerew, als einen erfahrenen, der mit unserer Servicemuster und k8s arbeitet (die Arbeit, die er übernommen hat). ReactNative haben Andrej Sarafanov und ich ausprobiert.

Ich beschloss, sofort ein Arbeitsrepository für das Projekt zu erstellen. Um 12 Uhr nachts stieß ich darauf, dass die Geolokalisierung in ReactNative im Hintergrund schlecht funktioniert, wenn man keinen nativen Code schreibt, was mich ein bisschen frustrierte. Später ließ es nach, als ich merkte, dass ich nicht die Dokumentation des Frameworks expo.io las, sondern die von ReactNative. Am Ende des Abends war mir bereits klar, wie ich bei expo.io die aktuelle Position abrufen und separate Bildschirme (für die Anmeldung, die Anzeige von Bestellungen usw.) erstellen kann.

Am Morgen beim Hackathon wurde Gleb in unser vielversprechendes Projekt hineingezogen. Schnell skizzierten wir einen Plan, was zu tun ist.

Wir haben einen Fehler gemacht, als wir versuchten, die Kommunikation nicht über HTTP, sondern über GRPC gemäß dem Projektschema zu realisieren, da niemand wusste, wie man einen GRPC-Client für JavaScript erstellt. Letztendlich haben wir etwa anderthalb Stunden darauf verwendet und die Idee aufgegeben. Deshalb begannen die Jungs auch im Backend, den fertigen Server von GRPC auf WebApi umzubauen. Nach einer halben Stunde konnten wir dann endlich die Kommunikation zwischen der App und dem Backend einrichten, welch Wunder. Aber zur gleichen Zeit war Gleb fast mit dem Deployment auf k8s fertig und zudem mit dem Autodeploy bei einem Commit in den Master. 🙂

Als Speicher haben wir MySQL gewählt, um nicht wenigstens in Bezug auf die Datenbank zu riskieren (es gab Überlegungen zu CosmosDb).

Insgesamt:

Wir haben die Speicherung der aktuellen Koordinaten des Kurier in der Datenbank aus der App realisiert.
Wir haben RabbitMQ angeschlossen und uns auf Nachrichten über das Annehmen von Bestellungen durch den Kurier angemeldet, um die Bestellung sofort im App des Kuriers anzuzeigen.
Wir begannen, die Lieferzeit des Auftrags in der Datenbank zu speichern, nachdem der Kurier den Knopf in der App gedrückt hatte. Wir haben es nicht geschafft, das Ereignis zurück an Rabbit zu senden, dass die Bestellung geliefert wurde.
Ich habe eine Kartenanzeige auf der Seite currentorder der Website mit der aktuellen Position des Kurier erstellt. Aber diese Funktionalität blieb etwas unvollständig, da es uns nicht gelang, CORS in der Umgebung für den Abruf der Koordinaten aus unserem neuen Dienst einzurichten.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artyom Trofimushkin

Wir wollten einen OpenID Connect-Anbieter implementieren, da wir derzeit ein selbstentwickeltes Authentifizierungsprotokoll verwenden, was eine Reihe von Schwierigkeiten mit sich bringt: kundenspezifische Client-Bibliotheken, umständliche Zusammenarbeit mit externen Partnern und möglicherweise Sicherheitsprobleme (schließlich kann man OAuth2.0 und OpenID Connect in ihrer Referenzimplementierung als sicher betrachten, aber bei unserer Lösung bin ich mir nicht sicher).

Wir haben einen separaten Dienst erstellt, der einen Dienst zur Speicherung personenbezogener Daten emuliert, um ein kleines Modell eines länderunabhängigen Authentifizierungsanbieters zu schaffen, der die personenbezogenen Daten von einem separaten Dienst abruft (das würde perspektivisch die Möglichkeit bieten, sich mit einem Konto aus jedem Land anzumelden und dabei die DSGVO und andere gesetzliche Regelungen einzuhalten). Diese Teile haben wir gemacht, sowohl den Anbieter als auch die Integration erfolgreich umgesetzt. Als nächstes musste eine API erstellt werden, die durch Token geschützt war, die der Anbieter ausgibt, die deren Inspektion über den Anbieter unterstützen und geschützte Daten zurückgeben, wenn die Anfrage die Autorisierungsrichtlinien erfüllte (wir prüfen, ob der Benutzer nach dem Bearer-Schema authentifiziert ist, ob sein Token einen bestimmten Scope enthält und ob der Benutzer eine Erlaubnis hat, den Aufruf auszuführen). Auch dieser Teil wurde umgesetzt. Der letzte Bestandteil war ein JavaScript-Client, dem ein Token ausgehändigt wird, mit dem er die geschützte API aufruft. Diese Funktion konnten wir nicht rechtzeitig umsetzen. Das heißt, der funktionale Teil war vollständig bereit, aber der Front-End-Bereich zur Demonstration der Funktionalität des gesamten Systems war noch nicht fertig.

Ä-Ä-Ä (Spiel)

Dima Afonchenko, Sasha Konovalov

Wir haben ein Minispiel in Unity erstellt, in dem flinke Hände Würstchen auf eine Pizza legen. Wenn du das Würstchen falsch gelegt hast, erscheint auf dem Bildschirm die traurige Nachricht „Abgelehnt“, und wenn das gesamte Würstchen richtig platziert ist, wird eine zufällige Tatsache über Pizza angezeigt.

Wir wollten eine zweite Stufe mit dem Hinzufügen von Tomaten machen, aber das haben wir nicht geschafft.

Kurze Fortsetzung: Wer hat gewonnen?

Vor dem Hackathon haben wir mit den Jungs gesprochen und ich habe gefragt, welchen Preis sie gerne erhalten würden, wenn sie gewinnen. Es stellte sich heraus, dass der wertvollste Preis „der Weg in die Produktion“ wäre.

Deshalb erwarten Sie in naher Zukunft die Ankündigung eines Spiels mit Händen, die Peperoni auf die Pizza streuen.