Wie und warum wir den Big Data Track beim Urban Tech Challenge Hackathon gewonnen haben

Ich heiße 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 muss sofort sagen, dass dies nicht der erste Hackathon ist, an dem ich teilgenommen habe, und nicht der erste, an dem ich Preise gewinne. In diesem Zusammenhang möchte ich in meiner Geschichte einige allgemeine Beobachtungen und Schlussfolgerungen in Bezug auf die Hackathon-Branche als Ganzes äußern und meinen Standpunkt darlegen, im Gegensatz zu den negativen Bewertungen, die unmittelbar nach dem Ende der Urban Tech Challenge (zum Beispiel dieser ) im Netzwerk erschienen sind.

Also zunächst einige allgemeine Beobachtungen.

1. Es ist überraschend, dass einige Leute naiv denken, dass ein Hackathon eine Art Sportwettbewerb ist, bei dem die besten Programmierer gewinnen. Es ist nicht so. Ich betrachte keine Fälle, in denen die Organisatoren des Hackathons selbst nicht wissen, was sie wollen (das habe ich auch gesehen). In der Regel verfolgt ein Unternehmen, das einen Hackathon organisiert, seine Ziele. Ihre Liste kann unterschiedlich sein: Sie kann eine technische Lösung für einige Probleme sein, die Suche nach neuen Ideen und Menschen usw. Diese Ziele bestimmen häufig das Format des Ereignisses, seinen Zeitpunkt, online / offline, wie die Aufgaben formuliert werden (und ob sie überhaupt formuliert werden), ob es eine Codeüberprüfung des Hackathons gibt usw. Sowohl die Teams als auch das, was sie getan haben, werden unter diesem Gesichtspunkt genau bewertet. Und diejenigen Teams, die am besten zu dem Punkt kommen, den das Unternehmen benötigt, gewinnen, und viele kommen völlig unbewusst und versehentlich an diesen Punkt, weil sie denken, dass sie wirklich am Sportwettbewerb teilnehmen. Meine Beobachtungen zeigen, dass die Organisatoren, um die Teilnehmer zu motivieren, zumindest das Erscheinungsbild eines sportlichen Umfelds und gleicher Bedingungen schaffen sollten, da sie sonst eine Welle der Negativität erhalten, wie in der obigen Bewertung. Aber wir sind verirrt.

2. Daher die folgende Schlussfolgerung. Die Organisatoren sind daran interessiert, dass die Teilnehmer mit ihren eigenen Ideen zum Hackathon kommen, manchmal ist sogar eine Online-Korrespondenzphase speziell dafür eingerichtet. Dies ermöglicht stärkere Ausgabelösungen. Das Konzept der „eigenen Arbeit“ ist sehr relativ. Jeder erfahrene Programmierer kann beim ersten Commit Tausende von Codezeilen aus seinen alten Projekten sammeln. Und wird es eine vorbereitete Betriebszeit sein? Aber auf jeden Fall gilt die Regel, die ich in Form eines berühmten Mems ausgedrückt habe:



Um zu gewinnen, müssen Sie einen Wettbewerbsvorteil haben: ein ähnliches Projekt, das Sie in der Vergangenheit durchgeführt haben, Kenntnisse und Erfahrungen in einem bestimmten Thema oder bereits abgeschlossene Arbeiten vor Beginn des Hackathons. Ja, es ist kein Sport. Ja, dies zahlt sich möglicherweise nicht aus (hier entscheidet jeder, ob er 3 Wochen in der Nacht für einen Preis von 100.000 codiert, der vom gesamten Team geteilt wird, und sogar mit dem Risiko, ihn nicht zu erhalten). Aber oft ist dies die einzige Chance, weiterzukommen.

3. Auswahl des Teams. Wie ich aus den Hackathon-Chats bemerkt habe, nehmen viele Leute dieses Problem eher leicht (obwohl dies die wichtigste Entscheidung ist, die Ihr Ergebnis beim Hackathon bestimmt). In vielen Tätigkeitsbereichen (sowohl im Sport als auch bei Hackathons) habe ich gesehen, dass starke Leute dazu neigen, sich mit starken zu vereinen, schwache mit schwachen, kluge mit klugen, im Allgemeinen verstehen Sie ... Das passiert in Chatrooms: mehr oder weniger starke Programmierer Sofort hängen Leute, die keine Hackathon-wertvollen Fähigkeiten haben, lange im Chat und wählen ein Team nach dem Prinzip, dass nur jemand daran teilnimmt. Bei einigen Hackathons wird eine zufällige Verteilung zwischen den Teams praktiziert, und die Organisatoren behaupten, dass zufällige Teams das Ergebnis nicht schlechter zeigen als bereits etablierte. Aber nach meinen Beobachtungen finden motivierte Leute in der Regel das Team selbst. Wenn jemand verteilt werden muss, kommen oft viele von ihnen nicht zum Hackathon.

Die Zusammensetzung des Teams ist sehr individuell und stark von der Aufgabe abhängig. Ich könnte sagen, dass das minimal lebensfähige Team ein Designer ist - Front-End oder Front-End - Back-End. Ich kenne aber auch Fälle, in denen Teams, die nur aus Front-Endors bestehen, gewonnen haben, die ein einfaches Back-End an node.js angehängt haben, oder eine mobile Anwendung auf React Native erstellt haben. oder nur von beckendern, die ein einfaches layout gemacht haben. Im Allgemeinen ist alles sehr individuell und hängt von der Aufgabe ab. 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 dem Front-End-Back-End-Designer beizutreten (ich bin selbst vorne). Und ziemlich schnell fing er an, mit einem Python-Backend und einem Designer zu chatten, der die Einladung annahm, sich uns anzuschließen. Wenig später kam ein Business-Analyst-Mädchen zu uns, das bereits die Erfahrung gemacht hatte, den Hackathon zu gewinnen, und dies entschied, dass sie zu uns kam. Nach einem kurzen Treffen beschlossen wir, uns U4 (URBAN 4, Urban Four) zu nennen, ähnlich wie die fantastischen Vier. Und sie haben sogar ein entsprechendes Bild auf unseren Telegrammkanal gesetzt.

4. Wahl der Aufgabe. Wie gesagt, Sie sollten einen Wettbewerbsvorteil haben, die Aufgabe des Hackathons wird auf dieser Grundlage gewählt. Nachdem wir uns die Liste der Aufgaben angesehen und ihre Komplexität bewertet hatten, entschieden wir uns für zwei Aufgaben: einen Katalog innovativer Unternehmen von DPiIR und einen Chat-Bot von EFKO. Die Aufgabe des Instituts für industrielle und industrielle Entwicklung wurde vom Geldgeber gewählt, die Aufgabe von EFKO wurde von mir gewählt, weil Ich hatte Erfahrung mit dem Schreiben von Chatbots auf node.js und DialogFlow. Die EFKO-Aufgabe umfasste auch ML. Ich habe einige, nicht sehr große Erfahrungen mit ML. Und je nach den Bedingungen des Problems schien es mir, dass es mit ML kaum gelöst werden konnte. Dieses Gefühl verstärkte sich, als ich zum Urban Tech Challenge-Meeting ging, wo mir die Organisatoren einen EFCO-Datensatz zeigten, in dem etwa 100 Fotos von Produktlayouts (aus verschiedenen Blickwinkeln aufgenommen) und etwa 20 Klassen von Layoutfehlern vorhanden waren. Gleichzeitig wollten die Kunden der Aufgabe eine Klassifizierungserfolgsrate von 90%. Als Ergebnis habe ich die Präsentation der Lösung ohne ML vorbereitet, der Backender hat die Präsentation gemäß dem Katalog vorbereitet, und nachdem wir die Präsentationen fertiggestellt haben, haben wir sie gemeinsam an die Urban Tech Challenge gesendet. Bereits zu diesem Zeitpunkt wurde das Motivations- und Beitragsniveau jedes Teilnehmers ermittelt. Unser Designer nahm nicht an den Diskussionen teil, antwortete spät und füllte im allerletzten Moment sogar Informationen über sich selbst in der Präsentation aus, im Allgemeinen traten Zweifel auf.

Infolgedessen haben wir die Aufgabe der Abteilung für Konstruktion und Design durchlaufen und waren überhaupt nicht verärgert darüber, dass wir EFKO nicht durchlaufen haben, da uns die Aufgabe, gelinde gesagt, seltsam vorkam.

5. Vorbereitung auf den Hackathon. Als endlich bekannt wurde, dass wir zum Hackathon gingen, begannen wir mit der Vorbereitung des Werkstücks. Und hier fordere ich Sie nicht auf, eine Woche vor Beginn des Hackathons mit dem Schreiben von Code zu beginnen. Zumindest sollten Sie eine Boilerplate bereithalten, mit der Sie sofort an die Arbeit gehen können, ohne die Werkzeuge einstellen zu müssen und ohne auf Fehler jeglicher Art zu stoßen, die Sie zum ersten Mal bei einem Hackathon versuchen möchten. Ich kenne eine Geschichte über Angler, die zum Hackathon gekommen sind und 2 Tage damit verbracht haben, die Projektversammlung einzurichten, daher sollte alles im Voraus vorbereitet werden. Wir sollten die Aufgaben wie folgt verteilen: Der Token schreibt Crawler, die das Internet scannen und alle in der Datenbank gesammelten Informationen speichern. Ich schreibe die API auf node.js, die diese Datenbank anfordert und die Daten an die Front sendet. In dieser Hinsicht habe ich den Server im Voraus auf express.js vorbereitet und das Frontend auf reagieren vorbereitet. Ich benutze kein CRA, ich passe das Webpack immer für mich an und weiß sehr gut, welche Risiken dies mit sich bringen kann (wir erinnern uns an die Geschichte über Angler). In diesem Moment habe ich die Schnittstellen-Leerzeichen oder zumindest Modelle von unserem Designer angefordert, um eine Vorstellung davon zu bekommen, was ich auferlegen würde. Theoretisch sollte auch er seine Vorbereitungen treffen und sie mit uns koordinieren, aber ich habe nie eine Antwort erhalten. Infolgedessen habe ich das Design von einem meiner alten Projekte ausgeliehen. Und so wurde es noch schneller, da alle Stile für dieses Projekt bereits geschrieben waren. Daher die Schlussfolgerung: Der Designer wird nicht immer im Team benötigt))). Mit diesen Entwicklungen kamen wir zum Hackathon.

6. Arbeiten Sie am Hackathon. Ich habe mein Team erst bei der Eröffnung des Hackathons im CDP live gesehen. Wir haben uns getroffen, die Lösung und die Arbeitsschritte für die Aufgabe besprochen. Und obwohl wir nach der Eröffnung Busse zum Roten Oktober nehmen mussten, gingen wir nach Hause, um zu schlafen, nachdem wir uns bereit erklärt hatten, um 9.00 Uhr zu uns zu kommen. Warum? Die Organisatoren wollten anscheinend das Beste aus den Teilnehmern herausholen, also arrangierten sie einen solchen Zeitplan. Aber meiner Erfahrung nach können Sie normalerweise codieren, ohne eine Nacht zu schlafen. Was das zweite betrifft, bin ich mir nicht mehr sicher. Hackathon ist ein Marathon, Sie müssen Ihre Kraft angemessen berechnen und planen. Außerdem hatten wir Leerzeichen.



Deshalb saßen wir nach dem Schlafen um 9.00 Uhr im sechsten Stock der Dewocracy. Dann gab unser Designer unerwartet bekannt, dass er keinen Laptop habe und von zu Hause aus arbeiten würde und wir telefonisch kommunizieren würden. Dies war der letzte Strohhalm. Und so sind wir von vier auf drei gewechselt, obwohl wir den Namen des Teams nicht geändert haben. Auch dies wurde kein schwerer Schlag für uns, ich hatte bereits das Design aus dem alten Projekt. Im Allgemeinen verlief zunächst alles reibungslos und nach Plan. Wir haben einen Datensatz innovativer Unternehmen von den Organisatoren in die Datenbank hochgeladen (wir haben uns für neo4j entschieden). Ich fing an zu setzen, nahm dann node.js an und dann gingen Aussetzer los. Ich hatte noch nie zuvor mit neo4j gearbeitet und zuerst nach einem funktionierenden Treiber für diese Datenbank gesucht, dann herausgefunden, wie die Abfrage geschrieben wird, und dann war ich überrascht, dass diese Datenbank auf Anfrage Entitäten als Array von Knotenobjekten und deren Kanten zurückgibt. Das heißt, Als ich nach der Organisation per TIN und allen darauf befindlichen Daten anstelle eines einzelnen Organisationsobjekts fragte, gab ich eine lange Reihe von Objekten zurück, die Daten zu dieser Organisation und die Beziehung zwischen ihnen enthielten. Ich habe einen Mapper geschrieben, der das gesamte Array durchquert und alle Objekte in der Organisation zu einem Objekt zusammengefügt hat. Im Kampf war die Abfrage einer Datenbank mit 8.000 Organisationen für etwa 20 bis 30 Sekunden extrem langsam. Ich habe über Optimierung nachgedacht ... Und dann haben wir rechtzeitig angehalten und sind zu MongoDB gewechselt, und es hat ungefähr 30 Minuten gedauert. Auf neo4j gingen insgesamt ca. 5 Stunden verloren.

Denken Sie daran, nehmen Sie niemals eine Hackathon-Technologie an, mit der Sie nicht vertraut sind. Es kann Überraschungen geben. Aber im Allgemeinen verlief bis auf dieses Versagen alles nach Plan. Und schon am Morgen des 9. Dezember hatten wir eine voll funktionsfähige Bewerbung. Für den Rest des Tages planten wir, zusätzliche Funktionen darauf zu installieren. In der Zukunft verlief alles relativ reibungslos, aber der Tokender hatte eine Menge Probleme mit dem Verbot seiner Crawler in Suchmaschinen, im Spam von Aggregatoren für juristische Personen, die bei der Anfrage nach einem bestimmten Unternehmen an erster Stelle der Suchergebnisse standen. Aber darüber wird er es besser erzählen. Die erste zusätzliche Funktion, die ich vermasselt habe, ist eine Suche nach vollem Namen Geschäftsführer VKontakte. Es dauerte mehrere Stunden.

Auf der Seite des Unternehmens in unserer Bewerbung wurden die Ava des Generaldirektors, ein Link zu seiner VK-Seite und einige andere Daten angezeigt. Es war eine gute Kirsche auf dem Kuchen, obwohl es uns vielleicht keinen Sieg gesichert hat. Dann wollte ich einige Analysen abschließen. Nach einer langen Suche nach Optionen (es gab viele Nuancen bei der Benutzeroberfläche) entschied er sich jedoch für die einfachste Aggregation von Organisationen nach wirtschaftlichem Aktivitätscode. Bereits am Abend, in den letzten Stunden, habe ich ein Leerzeichen für die Anzeige innovativer Produkte erstellt (der Abschnitt Produkte und Dienstleistungen wird in unserer Anwendung angenommen), obwohl das Backend dafür noch nicht fertig war. Gleichzeitig war die Basis sprunghaft angeschwollen, die Crawler arbeiteten weiter, das Backend experimentierte mit NLP, um innovative Texte von nicht innovativen zu unterscheiden))). Aber es war schon Zeit für die Abschlusspräsentation.

7. Präsentation. Aus eigener Erfahrung kann ich sagen, dass Sie 3-4 Stunden vor der Auslieferung eine Präsentation vorbereiten sollten. Insbesondere wenn das Video darin enthalten sein soll, nimmt das Aufnehmen und Bearbeiten viel Zeit in Anspruch. Wir sollten ein Video haben. Und wir hatten eine besondere Person, die sich damit befasste und auch eine Reihe anderer organisatorischer Probleme löste. In dieser Hinsicht wurden wir bis zum allerletzten Moment nicht von der Codierung abgelenkt.

8. Tonhöhe. Mir hat es nicht gefallen, dass die Präsentationen und das Finale an einem separaten Wochentag (Montag) stattfanden. Hier setzten die Organisatoren höchstwahrscheinlich die Politik fort, das Maximum aus den Teilnehmern herauszuholen. Ich hatte nicht vor, mir eine Auszeit von der Arbeit zu nehmen, ich wollte nur ins Finale kommen, obwohl der Rest meines Teams ein Wochenende brauchte. Das emotionale Eintauchen in den Hackathon war jedoch bereits so hoch, dass ich um 8 Uhr morgens an den Chat meines Teams (arbeitend, nicht des Hackathon-Teams) schrieb, dass ich den Tag auf eigene Kosten nahm und zum CDC ging, um Stellplätze zu bekommen. Es stellte sich heraus, dass unser Problem viele reine Wissenschaftlerdaten waren, was den Ansatz zur 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 die Aufgabe lösen konnten. Am Ende haben wir die Strecke gewonnen, obwohl wir sehr glücklich waren, dass wir uns für die am wenigsten wettbewerbsfähige Aufgabe entschieden haben. Als wir uns die Stellplätze in anderen Tracks ansahen, stellten wir fest, dass wir dort keine Chance haben würden. Ich möchte auch sagen, dass wir mit der Jury sehr viel Glück hatten, sie hat den Code sorgfältig überprüft. Und nach den Bewertungen zu urteilen, war dies alles andere als auf allen Strecken der Fall.

9. Das Finale. Nachdem wir mehrmals zur Überprüfung des Codes zur Jury gerufen worden waren, dachten wir, wir hätten endlich alle Probleme gelöst und gingen zum Abendessen bei Burger King. Dort riefen uns die Organisatoren erneut an, wir mussten hastig Bestellungen packen und zurückkommen.

Der Veranstalter zeigte, in welchen Raum er gehen sollte, und als wir dorthin gingen, befanden wir uns in einem öffentlichen Vortragstraining für die Gewinnerteams. Die Jungs, die auf der Bühne auftreten sollten, waren gut aufgeladen, alle kamen als echte Schausteller heraus.

Und ich muss zugeben, dass wir im Finale vor dem Hintergrund der stärksten Teams von anderen Strecken blass ausgesehen haben. Der Sieg bei der Nominierung des Staatskunden hat das Team zu Recht von der Streckenimmobilien-Technologie ausgeschlossen. Ich denke, dass die Schlüsselfaktoren, die zu unserem Sieg auf der Strecke beigetragen haben, waren: die Verfügbarkeit eines vorgefertigten Rohlings, aufgrund dessen wir schnell einen Prototyp erstellen konnten, das Vorhandensein von „Highlights“ im Prototyp (Suche nach Generaldirektoren in sozialen Netzwerken) und die NLP-Fähigkeiten unseres Backenders die auch sehr an der Jury interessiert sind.



Und abschließend ein traditioneller Dank an alle, die uns unterstützt haben, die Jury unserer Strecke, Evgeny Evgrafiev (der Autor der Aufgabe, die wir beim Hackathon gelöst haben) und natürlich die Organisatoren des Hackathons. Dies war vielleicht der größte und coolste Hackathon von allen, an dem ich teilgenommen habe. Es bleibt nur zu wünschen, dass die Jungs eine so hohe Marke und mehr behalten!

Source: https://habr.com/ru/post/de433802/


All Articles