Urban Tech Challenge Hackathonでビッグデータトラックを獲得した方法と理由

私の名前はドミトリーです。 そして、私たちのチームがビッグデータトラックでアーバンテックチャレンジハッカソンの決勝に到達した方法についてお話したいと思います。 これは私が参加した最初のハッカソンではなく、賞を獲得した最初のハッカソンでもないことをすぐに言わなければなりません。 これに関して、私の話では、ハッカソン産業全体に関するいくつかの一般的な観察と結論を表明し、アーバンテックチャレンジの終了直後にネットワークに現れたネガティブなレビューとは対照的に、私の視点を与えたいと思います（たとえば、 これ ）。



それで、最初に、いくつかの一般的な観察。



1.ハッカソンは最高のコーダーが勝つ一種のスポーツイベントであると単純に考える人がかなりいるのは驚くべきことです。 そうではありません。 私はハッカソンの主催者自身が彼らが何を望んでいるかわからない場合を考慮しません（私もこれを見ました）。 しかし、原則として、ハッカソンを手配する会社はその目標を追求します。 それらのリストは異なる場合があります。いくつかの問題に対する技術的な解決策、新しいアイデアや人々の検索などです。 これらの目標は、イベントの形式、そのタイミング、オンライン/オフライン、タスクの定式化方法（および定式化されるかどうか）、ハッカソンでのコードレビューの有無などを決定することがよくあります。 チームと彼らがしたことの両方が、この観点から正確に評価されます。 そして、会社が必要とするポイントに到達するのに最適なチームが勝ち、多くの人がスポーツ競技に本当に参加していると思い込んで、無意識のうちに偶然このポイントに到達します。 私の観察では、参加者をやる気にさせるために、主催者は少なくともスポーツ環境と同等の条件の外観を作成する必要があります。そうしないと、上記のレビューのように否定的な波を受けます。 しかし、私たちは迷いました。



2.したがって、次の結論。 主催者は、自分のアイデアでハッカソンに参加する参加者に興味があります。時には、オンライン通信のステージでさえ特別に手配されます。 これにより、より強力な出力ソリューションが可能になります。 「自分の仕事」の概念は非常に相対的であり、経験豊富なプログラマなら誰でも、最初のコミットで古いプロジェクトから数千行のコードを蓄積できます。 また、事前に準備された営業時間になりますか？ しかし、いずれにしても、ルールは適用され、有名なミームの形で表現しました。







勝つためには、何らかの競争上の優位性が必要です。過去に行った同様のプロジェクト、特定のトピックに関する知識と経験、またはハッカソンの開始前に完了した作業。 はい、スポーツではありません。 はい、これは労力を返さないかもしれません（ここで、全員が夜に3週間、賞金10万をチーム全体で割ってコーディングするかどうかを決定します。 しかし、多くの場合、これが先に進む唯一の機会です。



3.チームの選択。 ハッカソンチャットで気づいたように、多くの人がこの問題をかなり軽視しています（ただし、これはハッカソンでの結果を決定する最も重要な決定です）。 活動の多くの分野（スポーツとハッカソンの両方）で、強い人は強い人と、弱い人と弱い人と、スマートな人とスマートな人と団結する傾向があることがわかりました。まあ、これはチャットルームで起こることです。すぐに、貴重なハッカソンスキルを持たない人はチャットに長時間かかり、誰かがそれを採用した場合、原則に従ってチームを選択します。 一部のハッカソンでは、チームのランダムな分散が実践されており、主催者は、ランダムなチームがすでに確立されているチームよりも悪い結果を示さないと主張します。 しかし、私の観察によれば、やる気のある人は原則としてチームを自分自身で見つけます。誰かを配布する必要がある場合、多くの人はハッカソンに来ません。



チームの構成に関しては、非常に個性的で、タスクに大きく依存しています。 最低限の実行可能なチームは、デザイナー-フロントエンドまたはフロントエンド-バックエンドであると言えます。 しかし、フロントエンドのみで構成されるチームが勝った場合、node.jsに単純なバックエンドをアタッチしたり、React Nativeでモバイルアプリケーションを作成した場合も知っています。 または単純なレイアウトを作成したベッカーからのみ。 一般に、すべては非常に個性的であり、タスクに依存します。 ハッカソンのチームを選択する計画は次のとおりです。チームを編成するか、フロントエンドバックエンドデザイナーのようなチームに参加することを計画しました（私は自分自身です）。 そして、すぐに彼はpythonバックエンドと私たちに参加する招待を受け入れたデザイナーとチャットを始めました。 少し後に、ビジネスアナリストの少女が参加しました。彼女はすでにハッカソンで優勝した経験があり、これが彼女の参加の問題を決定しました。 短い会議の後、幻想的な4との類推でU4（URBAN 4、都市4）を呼び出すことにしました。 そして、彼らは私たちの電報チャンネルに対応する写真を載せさえしました。



4.タスクの選択。 私が言ったように、競争上の優位性を持っている必要があり、ハッカソンのタスクはこれに基づいて選択されます。 これから進んで、 タスクのリストを見て、その複雑さを評価して、DPiIRの革新的な企業のカタログとEFKOのチャットボットの2つのタスクを決めました。 Institute for Industrial and Industrial Developmentのタスクはバックエンダーが選択し、EFKOのタスクは私が選択しました。 node.jsおよびDialogFlowでチャットボットを作成した経験があります。 EFKOタスクにもMLが関係していましたが、私はMLでそれほど大きな経験はありません。 そして、問題の状況に応じて、MLではほとんど解決されないように思えました。 この感覚は、主催者がEFCOデータセットを示したアーバンテックチャレンジ会議に行ったときに強化されました。EFCOデータセットには、さまざまな角度から撮影された製品レイアウトの写真が約100枚、レイアウトエラーが約20クラスありました。 同時に、タスクの顧客は、分類成功率90％を望んでいました。 その結果、私はMLなしでソリューションのプレゼンテーションを準備し、バックエンダーはカタログに従ってプレゼンテーションを準備し、一緒にプレゼンテーションを完成させて、それらをUrban Tech Challengeに送りました。 すでにこの段階で、各参加者の意欲と貢献度が明らかになりました。 私たちのデザイナーは、議論に参加せず、遅く答え、最後の瞬間のプレゼンテーションで自分自身に関する情報を記入しました。一般的な疑問が生じました。



その結果、私たちは建設設計局のタスクを通過しましたが、EFKOを通過しなかったことにまったく動揺しませんでした。



5.ハッカソンの準備。 私たちがハッカソンに行ったことをようやく知ったとき、私たちはワークピースの準備を始めました。 そして、ここでは、ハッカソンの開始の1週間前にコードの作成を開始することをお勧めしません。 最低限、ボイラープレートを用意しておく必要があります。これにより、ツールを調整する必要なく、ハッカソンで初めて試すことにしたあらゆる種類のバグにぶつかることなく、すぐに作業を開始できます。 私はハッカソンに来てプロジェクトアセンブリのセットアップに2日間を費やした釣り人についての話を知っているので、すべてを事前に準備する必要があります。 私たちは次のように職務を分配することになっています：バッカーはインターネットをスキャンしてデータベースに収集されたすべての情報を置くクローラーを作成し、node.jsでAPIを作成します。 これに関して、私はexpress.jsで事前にサーバーを準備し、反応でフロントエンドの準備を行いました。 私はCRAを使用せず、常に自分用にWebpackをカスタマイズし、これがどのようなリスクを伴う可能性があるかをよく知っています（釣り人の話を思い出してください）。 この時点で、私が何を課すかについてのアイデアを得るために、インターフェースのブランクまたは少なくともモックアップをデザイナーに要求しました。 理論的には、彼も彼の準備を行い、私たちと調整する必要がありますが、私は答えを受け取りませんでした。 その結果、古いプロジェクトの1つからデザインを借りました。 そして、このプロジェクトのすべてのスタイルがすでに書かれているため、さらに速くなり始めました。 したがって、結論：デザイナーはチームで常に必要とされるわけではありません）））。 これらの開発により、ハッカソンに来ました。



6.ハッカソンに取り組みます。 私は最初、私のチームがCDPのハッカソンのオープニングでのみライブを見た。 私たちは会い、解決策とタスクの作業段階について議論しました。 そして、開店後は10月の赤までバスに乗らなければなりませんでしたが、9時までに家に来ることに同意したので、家に帰って寝ました。 なんで？ 主催者は、どうやら参加者を最大限に絞りたいと思っていたので、まさにそのようなスケジュールを整えました。 しかし、私の経験では、通常、1晩寝なくてもコーディングできます。 2番目については、よくわかりません。 ハッカソンはマラソンです。自分の強さを適切に計算して計画する必要があります。 さらに、空白がありました。







したがって、寝た後、9.00に私たちはDewocracyの6階に座っていました。 それから私たちのデザイナーは、ラップトップを持っていないこと、そして自宅で仕事をし、電話でコミュニケーションを取ることを思いがけず発表しました。 これが最後のストローでした。 チームの名前は変更しませんでしたが、4から3に変わりました。 繰り返しますが、これは私たちにとって大きな打撃にはなりませんでした。私はすでに古いプロジェクトのデザインを手に入れました。 一般に、最初はすべてが順調に計画どおりに進みました。 革新的な企業のデータセットを主催者からデータベースにアップロードしました（neo4jを使用することにしました）。 私は組版を始め、node.jsを採用し、その後不発が起こりました。 以前neo4jで作業したことはありませんでしたが、最初にこのデータベースの動作するドライバーを探してから、クエリがどのように書かれているのかを見つけました。そして、このデータベースがノードオブジェクトとそのエッジの配列の形でエンティティを返すことに驚きました つまり 単一の組織オブジェクトではなく、TINとその上のすべてのデータで組織を要求すると、この組織とそれらの関係に関するデータを含むオブジェクトの長い配列を返しました。 配列全体を横断するマッパーを作成し、組織内のすべてのオブジェクトを1つのオブジェクトに接着しました。 しかし、戦いで、8000の組織のベースを照会すると、20〜30秒ほど極端に遅くなりました。 最適化について考えました...そして、時間内に停止してMongoDBに移動しました。約30分かかりました。 neo4jでは合計で約5時間が失われました。



覚えていない、あなたが精通していないハッカソン技術を決してとらないでください、驚きがあるかもしれません。 しかし、一般的に、この失敗を除いて、すべては計画通りに進みました。 そして、すでに12月9日の朝、完全に機能するアプリケーションがありました。 残りの時間は、追加機能を追加する予定でした。 将来的にはすべてが比較的スムーズに進みましたが、バックエンドには、検索エンジンでのクローラーの禁止、特定の企業ごとに検索結果の最初の場所に来た合法的なアグリゲーターのスパムに関する問題が山積していました。 しかし、これについては、彼はもっとよく言うでしょう。 私が台無しにした最初の追加機能は、フルネームによる検索です CEO VKontakte。 数時間かかりました。



そのため、アプリケーションの会社のページには、ゼネラルディレクターのava、彼のVKページへのリンク、およびその他のデータが表示されていました。 それは私たちに勝利を保証しなかったかもしれませんが、それはケーキの良いチェリーでした。 それから、分析をまとめたかった。 しかし、オプションの長い検索の後（UIには多くのニュアンスがありました）、彼は経済活動コードによる組織の最も単純な集約に落ち着きました。 すでに夕方、最後の数時間で、私は革新的な製品を表示するための空白を作成していました（アプリケーションのセクション「製品とサービス」が想定されています）。 同時に、ベースは飛躍的に膨らみ、クローラーは機能し続け、バックエンドは革新的なテキストと非革新的なテキストを区別するためにNLPを実験しました））。 しかし、もう最終プレゼンテーションの時間でした。



7.プレゼンテーション。 私自身の経験から、プレゼンテーションの3〜4時間前にプレゼンテーションの準備に切り替える必要があると言えます。 特にビデオがその中にあると想定される場合、それを撮影および編集するには多くの時間がかかります。 ビデオがあるはずだった。 そして、これに携わった特別な人がいて、他の多くの組織的な問題も解決しました。 この点で、最後の瞬間まで、私たちはコーディングに気を取られませんでした。



8.ピッチ。 プレゼンテーションと決勝が別の平日（月曜日）に行われるのは好きではありませんでした。 ここでは、ほとんどの場合、主催者は参加者の最大数を絞る方針を継続しました。 休みを取るつもりはなかったので、ファイナルのみに行きたかったのですが、残りのチームは週末を過ごしました。 しかし、ハッカソンへの感情的な没入感はすでに非常に高かったので、朝の8時にチーム（ハッカソンチームではなく作業中）のチャットに書きました。 私たちの仕事は純粋な科学者の多くの日付であることが判明し、これは問題を解決するアプローチに大きく影響しました。 多くの人は優れたDSを持っていましたが、誰も実用的なプロトタイプを持っていなかったので、多くは検索エンジンでクローラーの禁止を回避できませんでした。 プロトタイプを実際に使用できるのは私たちだけです。 そして、タスクを解決する方法を知っていました。 最終的に、私たちはトラックで優勝しましたが、最も競争力の低いタスクを選んだことは非常に幸運でした。 他のトラックのピッチを見ると、そこにはチャンスがないことに気づきました。 また、審査員と非常に幸運だったと言いたいです、彼らは細心の注意を払ってコードをチェックしました。 そして、レビューによると、これはすべてのトラックで発生したわけではありません。



9.最終。 コード審査のために審査員に何度か呼ばれた後、私たちは最終的にすべての問題を解決したと思い、バーガーキングで夕食に行きました。 そこで、主催者から再度電話があり、急いで注文をまとめて戻ってきました。



主催者はどの部屋に入るかを示し、そこに行くと、優勝チームのための人前で話すトレーニングに参加しました。 ステージで演じることになっていた男たちは十分に充電され、誰もが本当のショーマンとして出てきました。



そして、最終的に、他のトラックの最強チームを背景に、私たちは青ざめたように見えました。州の顧客の指名での勝利は、チームを不動産技術トラックから当然離れました。 トラックでの勝利に貢献した重要な要因は、既製のブランクが入手可能だったため、プロトタイプをすばやく作成できること、プロトタイプに「熱意」が存在すること（ソーシャルネットワークのゼネラルディレクターを検索すること）、およびバックベンダーのNLPスキルだと思います。審査員にも非常に興味がある人。







そして、結論として、私たちをサポートしてくれたすべての人々、私たちのトラックの審査員であるEvgeny Evgrafiev（ハッカソンで解決したタスクの作者）、そしてもちろん、ハッカソンオーガナイザーに感謝します。 これはおそらく私が参加したすべての中で最大かつ最もクールなハッカソンであり、そのような高いブランドなどを維持することを人々に願うだけです！