Mein Name ist Dmitry. Und ich möchte darüber sprechen, wie unser Team das Finale des Urban Tech Challenge-Hackathons auf der Big-Data-Strecke erreicht hat. Ich sage gleich, dass dies nicht der erste Hackathon ist, an dem ich teilgenommen habe, und nicht der erste, bei dem ich Preise gewonnen habe. In diesem Zusammenhang möchte ich in meiner Geschichte einige allgemeine Beobachtungen und Schlussfolgerungen zur Hackathon-Branche als Ganzes äußern und meinen Standpunkt im Gegensatz zu den negativen Bewertungen darlegen, die unmittelbar nach dem Ende der Urban Tech Challenge online erschienen (z Beispiel ).
Also zunächst einige allgemeine Beobachtungen.
1. Es ist überraschend, dass viele Leute naiv denken, ein Hackathon sei eine Art Sportwettbewerb, bei dem die besten Programmierer gewinnen. Das ist nicht so. Ich berücksichtige keine Fälle, in denen Hackathon-Organisatoren selbst nicht wissen, was sie wollen (das habe ich auch gesehen). Doch in der Regel verfolgt das Unternehmen, das einen Hackathon veranstaltet, eigene Ziele. Ihre Liste kann unterschiedlich sein: Es könnte sich um eine technische Lösung einiger Probleme, eine Suche nach neuen Ideen und Leuten usw. handeln. Diese Ziele bestimmen oft das Format der Veranstaltung, ihren Zeitpunkt, online/offline, wie die Aufgaben formuliert werden (und ob sie überhaupt formuliert werden), ob es beim Hackathon ein Code-Review geben wird usw. Unter diesem Gesichtspunkt werden sowohl die Mannschaften als auch ihre Leistungen beurteilt. Und diejenigen Teams, die am besten den Punkt erreichen, den das Unternehmen braucht, gewinnen, und viele kommen völlig unbewusst und zufällig an diesen Punkt, weil sie denken, dass sie wirklich an einem Sportwettbewerb teilnehmen. Meine Beobachtungen zeigen, dass Veranstalter, um die Teilnehmer zu motivieren, zumindest den Anschein einer sportlichen Umgebung und gleicher Bedingungen schaffen sollten, sonst erhalten sie eine Welle der Negativität, wie in der obigen Rezension. Aber wir schweifen ab.
2. Daher die folgende Schlussfolgerung. Die Organisatoren sind daran interessiert, dass Teilnehmer mit eigenen Arbeiten zum Hackathon kommen, manchmal organisieren sie zu diesem Zweck sogar eigens eine Online-Korrespondenzbühne. Dies ermöglicht stärkere Ausgabelösungen. Das Konzept der „eigenen Arbeit“ ist sehr relativ; jeder erfahrene Entwickler kann bei seinem ersten Commit Tausende von Zeilen Code aus seinen alten Projekten ansammeln. Und wird dies eine vorbereitete Entwicklung sein? Aber auf jeden Fall gilt die Regel, die ich in Form eines berühmten Memes ausgedrückt habe:
Um zu gewinnen, müssen Sie etwas haben, einen Wettbewerbsvorteil: ein ähnliches Projekt, das Sie in der Vergangenheit durchgeführt haben, Kenntnisse und Erfahrungen zu einem bestimmten Thema oder eine fertige Arbeit, die vor Beginn des Hackathons erstellt wurde. Ja, es ist nicht sportlich. Ja, das ist den Aufwand möglicherweise nicht wert (hier entscheidet jeder selbst, ob es sich lohnt, drei Wochen lang nachts für einen Preis von 3 zu programmieren, der unter dem gesamten Team aufgeteilt wird, und das sogar mit dem Risiko, ihn nicht zu erhalten). Doch oft ist dies die einzige Chance, weiterzukommen.
3. Teamauswahl. Wie mir in Hackathon-Chats aufgefallen ist, gehen viele recht leichtsinnig an dieses Thema heran (obwohl dies die wichtigste Entscheidung ist, die über Ihr Ergebnis beim Hackathon entscheidet). In vielen Tätigkeitsbereichen (sowohl im Sport als auch bei Hackathons) habe ich gesehen, dass starke Menschen dazu neigen, sich mit den Starken zu vereinen, die Schwachen mit den Schwachen, die Klugen mit den Klugen, nun ja, im Allgemeinen versteht man... Das ist ungefähr das, was in Chats passiert: Weniger starke Programmierer werden sofort geschnappt, Leute, die keine für einen Hackathon wertvollen Fähigkeiten haben, bleiben lange im Chat und wählen ein Team nach dem Prinzip aus, wenn es nur jemand nehmen würde . Bei manchen Hackathons wird die zufällige Zuordnung zu Teams geübt und die Organisatoren behaupten, dass zufällige Teams nicht schlechter abschneiden als bestehende. Aber nach meinen Beobachtungen finden motivierte Menschen in der Regel alleine ein Team; wenn jemand zugewiesen werden muss, kommen viele von ihnen oft nicht zum Hackathon.
Die Zusammensetzung des Teams ist sehr individuell und hängt stark von der Aufgabenstellung ab. Ich könnte sagen, dass die minimal realisierbare Teamzusammensetzung ein Designer – Front-End oder Front-End – Back-End ist. Ich kenne aber auch Fälle, in denen Teams gewonnen haben, die nur aus Front-Endern bestanden, die ein einfaches Back-End in node.js hinzugefügt oder eine mobile Anwendung in React Native erstellt haben; oder nur von Backendern, die ein einfaches Layout erstellt haben. Generell ist alles sehr individuell und abhängig von der Aufgabenstellung. Mein Plan für die Auswahl eines Teams für den Hackathon war wie folgt: Ich hatte vor, ein Team zusammenzustellen oder einem Team wie Frontend-Backend-Designer beizutreten (ich bin selbst Frontend). Und ziemlich schnell begann ich mit einem Python-Backender und einem Designer zu chatten, der die Einladung annahm, sich uns anzuschließen. Wenig später schloss sich uns ein Mädchen an, eine Wirtschaftsanalytikerin, die bereits Erfahrung mit dem Gewinn eines Hackathons hatte, und dies entschied über ihren Beitritt zu uns. Nach einem kurzen Treffen beschlossen wir, uns in Analogie zu den Fantastic Four U4 (URBAN 4, urban four) zu nennen. Und sie haben sogar ein entsprechendes Bild auf den Avatar unseres Telegram-Kanals gestellt.
4. Auswahl einer Aufgabe. Wie ich bereits sagte, muss man einen Wettbewerbsvorteil haben, auf dieser Grundlage wird die Aufgabe für den Hackathon ausgewählt. Auf dieser Grundlage habe ich nachgeschaut Nach der Beurteilung ihrer Komplexität haben wir uns für zwei Aufgaben entschieden: einen Katalog innovativer Unternehmen von DPiIR und einen Chatbot von EFKO. Die Aufgabe von DPIiR wurde vom Backender ausgewählt, die Aufgabe von EFKO wurde von mir ausgewählt, weil hatte Erfahrung im Schreiben von Chatbots in node.js und DialogFlow. Die EFKO-Aufgabe beinhaltete auch ML; ich habe einige, nicht sehr umfangreiche Erfahrung in ML. Und je nach den Bedingungen des Problems schien es mir unwahrscheinlich, dass es mit ML-Tools gelöst werden kann. Dieses Gefühl verstärkte sich, als ich zum Urban Tech Challenge-Treffen ging, wo mir die Organisatoren einen Datensatz auf EFKO zeigten, der etwa 100 Fotos von Produktlayouts (aus verschiedenen Blickwinkeln aufgenommen) und etwa 20 Klassen von Layoutfehlern enthielt. Und gleichzeitig wollten die Auftraggeber der Aufgabe eine Klassifizierungserfolgsquote von 90 % erreichen. Als Ergebnis bereitete ich eine Präsentation der Lösung ohne ML vor, der Backender bereitete eine Präsentation basierend auf dem Katalog vor und gemeinsam, nachdem wir die Präsentationen fertiggestellt hatten, schickten wir sie an die Urban Tech Challenge. Bereits zu diesem Zeitpunkt zeigte sich die Motivation und der Beitrag jedes einzelnen Teilnehmers. Unser Designer beteiligte sich nicht an den Diskussionen, reagierte spät und gab in der Präsentation im allerletzten Moment sogar Angaben zu seiner Person ab, im Allgemeinen kamen Zweifel auf.
Infolgedessen haben wir die DPiIR-Aufgabe bestanden und waren überhaupt nicht verärgert darüber, dass wir die EFKO nicht bestanden haben, da uns die Aufgabe, gelinde gesagt, seltsam vorkam.
5. Vorbereitung auf den Hackathon. Als schließlich bekannt wurde, dass wir uns für den Hackathon qualifiziert hatten, begannen wir mit den Vorbereitungen. Und hier plädiere ich nicht dafür, eine Woche vor Beginn des Hackathons mit dem Schreiben von Code zu beginnen. Zumindest sollten Sie ein Boilerplate parat haben, mit dem Sie sofort mit der Arbeit beginnen können, ohne Tools konfigurieren zu müssen und ohne auf Fehler einer Bibliothek zu stoßen, die Sie zum ersten Mal bei einem Hackathon ausprobieren möchten. Ich kenne eine Geschichte über Angular-Ingenieure, die zu einem Hackathon kamen und zwei Tage damit verbrachten, den Projekt-Build einzurichten, daher sollte alles im Voraus vorbereitet werden. Wir wollten die Verantwortlichkeiten wie folgt verteilen: Der Back-End schreibt Crawler, die das Internet durchsuchen und alle gesammelten Informationen in die Datenbank stellen, während ich in node.js eine API schreibe, die diese Datenbank abfragt und die Daten an den Front-End sendet. In diesem Zusammenhang habe ich im Voraus einen Server mit express.js vorbereitet und ein Front-End in React vorbereitet. Ich verwende kein CRA, ich passe Webpacks immer für mich an und weiß sehr gut, welche Risiken dies mit sich bringen kann (erinnern Sie sich an die Geschichte über Angular-Entwickler). Zu diesem Zeitpunkt habe ich von unserem Designer Schnittstellenvorlagen oder zumindest Mockups angefordert, um eine Vorstellung davon zu bekommen, was ich gestalten würde. Theoretisch sollte er auch seine eigenen Vorbereitungen treffen und diese mit uns abstimmen, eine Antwort erhielt ich jedoch nie. Daher habe ich das Design von einem meiner alten Projekte übernommen. Und es begann noch schneller zu klappen, da alle Stile für dieses Projekt bereits geschrieben waren. Daher die Schlussfolgerung: Ein Designer wird nicht immer in einem Team benötigt))). Mit diesen Entwicklungen sind wir zum Hackathon gekommen.
6. Arbeiten Sie am Hackathon. Das erste Mal sah ich mein Team live bei der Eröffnung des Hackathons im Central Distribution Center. Wir trafen uns, besprachen die Lösung und die Schritte zur Bearbeitung des Problems. Und obwohl wir nach der Eröffnung mit dem Bus zum Roten Oktober fahren mussten, gingen wir zum Schlafen nach Hause und vereinbarten, um 9.00 Uhr am Ort zu sein. Warum? Die Organisatoren wollten offenbar das Beste aus den Teilnehmern herausholen und haben daher einen solchen Zeitplan zusammengestellt. Aber meiner Erfahrung nach kann man normal programmieren, ohne eine Nacht zu schlafen. Beim zweiten bin ich mir nicht mehr sicher. Ein Hackathon ist ein Marathon; Sie müssen Ihre Kräfte angemessen berechnen und planen. Darüber hinaus hatten wir Vorbereitungen.
Deshalb saßen wir nach dem Ausschlafen um 9.00 Uhr im sechsten Stock von Dewocracy. Dann verkündete unser Designer unerwartet, dass er keinen Laptop habe und von zu Hause aus arbeiten würde und wir telefonisch kommunizieren würden. Das war der letzte Tropfen, der das Fass zum Überlaufen brachte. Und so sind wir von einer Vier auf eine Drei umgestiegen, obwohl wir den Teamnamen nicht geändert haben. Auch dies war kein großer Schlag für uns; ich hatte bereits den Entwurf vom alten Projekt. Im Großen und Ganzen verlief zunächst alles ganz reibungslos und nach Plan. Wir haben einen Datensatz innovativer Unternehmen der Veranstalter in die Datenbank geladen (wir haben uns für neo4j entschieden). Ich habe mit dem Schriftsatz begonnen, mich dann mit node.js beschäftigt, und dann fingen die Dinge an, fehlzuschlagen. Ich hatte noch nie zuvor mit neo4j gearbeitet und war zunächst auf der Suche nach einem funktionierenden Treiber für diese Datenbank, dann habe ich herausgefunden, wie man eine Abfrage schreibt, und dann war ich überrascht, als ich feststellte, dass diese Datenbank bei einer Abfrage Entitäten in der Datenbank zurückgibt Form eines Arrays von Knotenobjekten und deren Kanten. Diese. Als ich eine Organisation und alle Daten dazu per TIN anforderte, wurde mir anstelle eines Organisationsobjekts eine lange Reihe von Objekten zurückgegeben, die Daten zu dieser Organisation und den Beziehungen zwischen ihnen enthielten. Ich habe einen Mapper geschrieben, der das gesamte Array durchging und alle Objekte entsprechend ihrer Organisation in einem Objekt zusammenfügte. Aber im Kampf, als eine Datenbank mit 8 Organisationen angefordert wurde, wurde die Ausführung extrem langsam durchgeführt, etwa 20 bis 30 Sekunden. Ich fing an, über Optimierung nachzudenken ... Und dann hielten wir rechtzeitig an und wechselten zu MongoDB, und es dauerte etwa 30 Minuten. Insgesamt gingen auf neo4j etwa 5 Stunden verloren.
Denken Sie daran, niemals Technologie zu einem Hackathon mitzunehmen, mit der Sie nicht vertraut sind, da es zu Überraschungen kommen kann. Aber im Großen und Ganzen verlief bis auf dieses Scheitern alles nach Plan. Und bereits am Morgen des 9. Dezember hatten wir eine voll funktionsfähige Anwendung. Für den Rest des Tages planten wir, weitere Funktionen hinzuzufügen. In Zukunft lief bei mir alles relativ reibungslos, aber der Backender hatte eine ganze Reihe von Problemen mit dem Verbot seiner Crawler in Suchmaschinen, im Spam von Aggregatoren juristischer Personen, die bei Anfragen an die ersten Stellen der Suchergebnisse kamen für jedes einzelne Unternehmen. Aber es ist besser, wenn er selbst davon erzählt. Die erste zusätzliche Funktion, die ich hinzugefügt habe, war die Suche nach vollständigem Namen. Generaldirektor von VKontakte. Es dauerte mehrere Stunden.
Auf der Unternehmensseite in unserer Bewerbung erschienen also ein Avatar des Generaldirektors, ein Link zu seiner VKontakte-Seite und einige andere Daten. Es war ein schönes Sahnehäubchen, auch wenn es uns vielleicht nicht zum Sieg verholfen hat. Dann wollte ich einige Analysen durchführen. Aber nach einer langen Suche nach Optionen (es gab viele Nuancen bei der Benutzeroberfläche) entschied ich mich für die einfachste Aggregation von Organisationen nach Wirtschaftsaktivitätscode. Bereits am Abend, in den letzten Stunden, habe ich eine Vorlage zur Darstellung innovativer Produkte erstellt (in unserer Anwendung soll es einen Bereich „Produkte und Dienstleistungen“ geben), obwohl das Backend dafür noch nicht bereit war. Gleichzeitig wuchs die Datenbank sprunghaft an, die Crawler arbeiteten weiter, der Backender experimentierte mit NLP, um innovative von nicht-innovativen Texten zu unterscheiden))). Doch die Zeit für die Abschlusspräsentation rückte bereits näher.
7. Präsentation. Aus eigener Erfahrung kann ich sagen, dass man etwa 3 bis 4 Stunden vor der Präsentation mit der Vorbereitung beginnen sollte. Insbesondere wenn es sich um Videos handelt, nimmt die Aufnahme und Bearbeitung viel Zeit in Anspruch. Wir sollten ein Video machen. Und wir hatten eine besondere Person, die sich darum kümmerte und auch eine Reihe anderer organisatorischer Probleme löste. In dieser Hinsicht haben wir uns bis zum letzten Moment nicht vom Codieren abgelenkt.
8. Tonhöhe. Mir gefiel nicht, dass die Präsentationen und die Abschlussprüfungen an einem separaten Wochentag (Montag) stattfanden. Hier wurde höchstwahrscheinlich die Politik der Organisatoren fortgesetzt, das Maximum aus den Teilnehmern herauszuholen. Ich hatte nicht vor, mir eine Auszeit von der Arbeit zu nehmen, ich wollte nur zum Finale kommen, obwohl der Rest meines Teams den Tag frei nahm. Allerdings war die emotionale Immersion beim Hackathon bereits so hoch, dass ich um 8 Uhr morgens im Chat meines Teams (dem Arbeitsteam, nicht dem Hackathon-Team) schrieb, dass ich den Tag auf eigene Kosten nutze, und zur Zentrale ging Büro für Stellplätze. Es stellte sich heraus, dass viele reine Datenwissenschaftler an unserem Problem beteiligt waren, was die Herangehensweise an die Lösung des Problems stark beeinflusste. Viele hatten einen guten DS, aber niemand hatte einen funktionierenden Prototyp, viele konnten die Verbote ihrer Crawler in Suchmaschinen nicht umgehen. Wir waren das einzige Team mit einem funktionierenden Prototyp. Und wir wussten, wie wir das Problem lösen konnten. Am Ende haben wir die Strecke gewonnen, obwohl wir großes Glück hatten, dass wir uns für die am wenigsten konkurrenzfähige Aufgabe entschieden haben. Als wir uns die Tonhöhen in anderen Titeln ansahen, wurde uns klar, dass wir dort keine Chance haben würden. Ich möchte auch sagen, dass wir mit der Jury großes Glück hatten, sie hat den Code akribisch geprüft. Und den Kritiken nach zu urteilen, geschah dies nicht bei allen Titeln.
9. Finale. Nachdem wir mehrmals zur Codeüberprüfung in die Jury gerufen wurden, gingen wir, weil wir dachten, wir hätten endlich alle Probleme gelöst, zum Mittagessen bei Burger King. Dort riefen uns die Organisatoren erneut an, wir mussten schnell unsere Bestellungen packen und zurückfahren.
Der Organisator zeigte uns, in welchen Raum wir gehen mussten, und als wir eintraten, befanden wir uns in einer öffentlichen Redetrainingseinheit für die Gewinnerteams. Die Jungs, die auf der Bühne auftreten sollten, waren gut besetzt, alle traten wie echte Schausteller auf.
Und ich muss zugeben, dass wir im Finale vor dem Hintergrund der stärksten Teams aus anderen Bereichen blass aussahen; der Sieg in der Nominierung für Regierungskunden ging völlig verdient an das Team aus der Immobilien-Technologie-Strecke. Ich denke, die Schlüsselfaktoren, die zu unserem Sieg auf der Strecke beigetragen haben, waren: die Verfügbarkeit eines vorgefertigten Rohlings, dank dem wir schnell einen Prototyp herstellen konnten, das Vorhandensein von „Highlights“ im Prototyp (Suche nach CEOs). in sozialen Netzwerken) und die NLP-Fähigkeiten unseres Backenders, die auch die Jury sehr interessierten.
Und zum Schluss ein traditioneller Dank an alle, die uns unterstützt haben, die Jury unseres Tracks, Evgeniy Evgrafiev (den Autor des Problems, das wir beim Hackathon gelöst haben) und natürlich die Organisatoren des Hackathons. Das war vielleicht der größte und coolste Hackathon, an dem ich je teilgenommen habe. Ich kann den Jungs nur wünschen, dass sie auch in Zukunft einen so hohen Standard beibehalten!
Source: habr.com