Urban Tech Challenge ハカソンでビッグデータ トラックで優勝した経緯と理由

私の名前はドミトリーです。そして、私たちのチームがビッグ データ トラックでのアーバン テック チャレンジ ハカソンで決勝に進出した経緯について話したいと思います。すぐに言っておきますが、私がハッカソンに参加したのはこれが初めてではなく、賞を受賞したのも初めてではありません。この点に関して、私の話では、ハッカソン業界全体に関するいくつかの一般的な観察と結論を表明し、アーバン テック チャレンジの終了直後にオンライン上に現れた否定的なレビューとは対照的に、私の見解を述べたいと思います。例 この).

それでは、最初に一般的な観察をいくつか示します。

1. 驚くべきことに、ハッカソンとは、最も優れたプログラマーが優勝するスポーツ競技会のようなものだと素朴に考えている人が少なくありません。これは間違っています。ハッカソンの主催者自身が自分が何を望んでいるのか分かっていない場合は考えていません（私もそれを見てきました）。しかし、通常、ハッカソンを主催する企業は独自の目標を追求します。彼らのリストは異なる場合があります。それは、いくつかの問題に対する技術的な解決策、新しいアイデアや人材の探索などである可能性があります。これらの目標は、多くの場合、イベントの形式、タイミング、オンライン/オフライン、タスクがどのように策定されるか (そしてそもそもタスクが策定されるかどうか)、ハッカソンでコード レビューがあるかどうかなどを決定します。チームと彼らの行動は両方ともこの観点から評価されます。そして、会社が必要とするポイントを最もうまく達成したチームが勝利し、多くのチームは完全に無意識かつ偶然にこのポイントに到達し、自分たちが本当にスポーツ競技に参加していると考えています。私の観察によると、参加者のモチベーションを高めるために、主催者は少なくともスポーツ環境と平等な条件の外観を作り出す必要があります。そうしないと、上記のレビューのように、参加者は否定的な波を受けることになります。しかし話は逸れます。

2. したがって、次の結論になります。主催者は、自分の作品を持ってハッカソンに参加する参加者に興味を持っており、場合によっては、この目的のためにオンライン通信ステージを特別に企画することもあります。これにより、より強力な出力ソリューションが可能になります。 「自分の作品」という概念は非常に相対的なものであり、経験豊富な開発者は誰でも、最初のコミットで古いプロジェクトから何千行ものコードを蓄積する可能性があります。そしてこれはあらかじめ用意された展開なのだろうか？しかし、いずれの場合にも、私が有名なミームの形で表現したルールが適用されます。

勝つためには、過去に行った同様のプロジェクト、特定のトピックに関する知識と経験、またはハッカソンの開始前に完了した既成の作品など、何らかの競争上の優位性が必要です。はい、スポーツではありません。はい、これは費やす労力に見合う価値はないかもしれません (ここでは、3 万の賞金をかけて、チーム全体で分配し、賞金を獲得できないリスクを冒してでも、100 週間夜中にコーディングする価値があるかどうかを全員が自分で判断します)。しかし、多くの場合、これが先に進む唯一のチャンスです。

3. チームの選択。ハカソンのチャットで気づいたように、多くの人はこの問題に非常に軽率に取り組んでいます (ただし、これはハッカソンでの結果を決定する最も重要な決定です)。多くの活動分野 (スポーツとハッカソンの両方) で、強い人は強い人同士、弱い人は弱い人、賢い人は賢い人と団結する傾向があるのを見てきました。チャットでは大まかにこれが起こります。それほど強くないプログラマーはすぐに雇われ、ハッカソンに必要なスキルを持たない人は長時間チャットに留まり、誰かがそれを引き受けてくれればという原則に基づいてチームを選びます。 。一部のハッカソンでは、チームへのランダムな割り当てが行われており、主催者は、ランダムなチームのパフォーマンスは既存のチームよりも悪くないと主張しています。しかし、私の観察によると、やる気のある人は原則として自分でチームを見つけますが、誰かを割り当てなければならない場合、多くの場合、彼らの多くはハッカソンに来ません。

チームの構成に関しては、非常に個人的なものであり、タスクに大きく依存します。実行可能な最小限のチーム構成は、デザイナー - フロントエンド、またはフロントエンド - バックエンドであると言えます。しかし、フロントエンダーのみで構成されたチームが勝ったケースも知っています。チームは、node.js で単純なバックエンドを追加したり、React Native でモバイル アプリケーションを作成したりしました。または、単純なレイアウトを行ったバックエンダーのみからのものです。一般に、すべては非常に個別であり、タスクによって異なります。ハッカソンのチームを選ぶ私の計画は次のとおりです。私はチームを編成するか、フロントエンド - バックエンド - デザイナーのようなチームに参加する予定でした (私自身はフロントエンドです)。そしてすぐに、参加への招待を受け入れた Python バックエンダーおよびデザイナーとチャットを開始しました。少し後、すでにハッカソンで優勝した経験のあるビジネス アナリストの女の子が私たちに加わり、これが彼女の参加の問題を決定しました。短いミーティングの後、私たちはファンタスティック・フォーになぞらえて自分たちをU4（URBAN 4、アーバン・フォー）と呼ぶことにしました。そして、彼らは私たちの電報チャンネルのアバターに対応する写真さえ載せました。

4. タスクの選択。すでに述べたように、競争上の優位性が必要です。ハッカソンのタスクはこれに基づいて選択されます。これを踏まえて調べてみると、 タスクリスト そしてその複雑さを評価した結果、DPiIR の革新的な企業のカタログと EFKO のチャットボットという 100 つのタスクに落ち着きました。 DPIiR からのタスクはバックエンダーによって選択され、EFKO からのタスクは私によって選択されました。 Node.js と DialogFlow でチャットボットを作成した経験があります。 EFKO タスクには ML も含まれており、私は ML に関して、それほど広範囲ではありませんが、ある程度の経験があります。そして、問題の状況からすると、ML ツールを使用して解決できる可能性は低いように思えました。この思いは、アーバン テック チャレンジのミートアップに行ったときにさらに強くなりました。そこで主催者が EFKO のデータセットを見せてくれました。そこには、約 20 枚の製品レイアウトの写真 (さまざまな角度から撮影したもの) と約 90 クラスのレイアウト エラーが含まれていました。そして同時に、タスクを発注した側は XNUMX% の分類成功率を達成したいと考えていました。その結果、私は ML を使用しないソリューションのプレゼンテーションを作成し、バックエンダーはカタログに基づいてプレゼンテーションを作成し、一緒にプレゼンテーションを完成させた後、Urban Tech Challenge に送信しました。この段階ですでに、各参加者のモチベーションと貢献のレベルが明らかになりました。私たちのデザイナーは議論に参加せず、返信が遅く、最後の瞬間にプレゼンテーションに自分自身についての情報さえ記入したため、一般的に疑念が生じました。

結果として、私たちは DPiIR からのタスクをパスしましたが、控えめに言ってもそのタスクは私たちにとって奇妙に思えたので、EFKO にパスしなかったことにはまったく動揺しませんでした。

5. ハッカソンの準備。ようやくハッカソンへの出場資格を獲得したことが分かり、私たちは準備を始めました。ここで私は、ハッカソンが始まる 2 週間前にコードを書き始めることを推奨しているわけではありません。少なくとも、ツールを設定したり、ハッカソンで初めて試すことにしたライブラリのバグに遭遇したりすることなく、すぐに作業を開始できるボイラープレートを準備する必要があります。ハッカソンに来て、プロジェクト ビルドのセットアップに XNUMX 日間を費やした Angular エンジニアの話を私は知っています。そのため、すべてを事前に準備する必要があります。私たちは次のように責任を分散することを意図していました。バックエンダーはインターネットを探索し、収集したすべての情報をデータベースに入れるクローラーを作成します。一方、私はこのデータベースにクエリを実行してデータをフロントに送信する API を Node.js で作成します。そこで、事前にexpress.jsでサーバーを用意し、reactでフロントエンドを用意しました。私は CRA を使用しません。常に Webpack を自分用にカスタマイズしており、これがどのようなリスクを引き起こす可能性があるかをよく知っています (Angular 開発者の話を思い出してください)。この時点で、何をレイアウトするのかを把握するために、デザイナーにインターフェイス テンプレート、または少なくともモックアップをリクエストしました。本来であれば、彼自身も準備をし、我々と調整すべきであるが、返答は得られなかった。その結果、私の古いプロジェクトの XNUMX つからデザインを借用しました。そして、このプロジェクトのすべてのスタイルがすでに書かれていたため、作業はさらに速く進み始めました。したがって、結論は次のとおりです。デザイナーはチームに常に必要なわけではありません)))。私たちはこうした展開を持ってハッカソンに臨みました。

6. ハッカソンで働きます。私が初めて自分のチームを生で見たのは、中央流通センターでのハッカソンの開会時でした。私たちは会って、解決策や問題に取り組む段階について話し合いました。そして、開場後はバスでレッドオクトーバーまで行かなければなりませんでしたが、9.00時までに到着することに同意して、家に帰って寝ました。なぜ？主催者は参加者に最大限の効果を発揮したいと考え、このようなスケジュールを組んだようです。ただし、私の経験では、一晩寝なくても普通にコーディングできます。 XNUMX番目については、もうわかりません。ハッカソンはマラソンのようなもので、自分の体力を適切に計算して計画する必要があります。さらに、私たちには準備がありました。

したがって、一眠りした後、9.00時に私たちはDewocracyの4階に座っていました。その後、デザイナーはラップトップを持っていないため、自宅で仕事をし、電話で連絡を取ると突然発表しました。これが最後の藁でした。それでチーム名は変えませんでしたが、４チームから３チームになりました。繰り返しますが、これは私たちにとって大きな打撃ではありませんでした。私はすでに古いプロジェクトからデザインを持っていたからです。一般に、最初はすべてが非常にスムーズに、計画どおりに進みました。私たちは主催者から提供された革新的な企業のデータセットをデータベースにロードしました (neo4j を使用することにしました)。私は植字を開始し、その後、node.js を始めましたが、その後、物事がうまくいきませんでした。私はこれまで neo8j を使用したことがありませんでした。最初はこのデータベース用に動作するドライバーを探していました。次にクエリの書き方を見つけました。その後、このデータベースがクエリされるとエンティティを返すことを発見して驚きました。ノード オブジェクトとそのエッジの配列の形式。それらの。 TIN によって組織とそのすべてのデータをリクエストすると、20 つの組織オブジェクトではなく、この組織に関するデータと組織間の関係を含むオブジェクトの長い配列が返されました。私は配列全体を調べ、すべてのオブジェクトを構成に従って 30 つのオブジェクトに結合するマッパーを作成しました。しかし、戦闘中、30組織のデータベースをリクエストすると、実行が非常に遅くなり、約4～5秒かかりました。最適化について考え始めました...そして時間内に停止して MongoDB に切り替えました。所要時間は約 XNUMX 分でした。 neoXNUMXj では合計で約 XNUMX 時間が無駄になりました。

覚えておいてください、ハッカソンに慣れていないテクノロジーを決して持ち込まないでください。驚くようなことが起こる可能性があります。しかし、この失敗を除けば、全体的にはすべて計画通りに進みました。そして 9 月 XNUMX 日の朝には、すでに完全に動作するアプリケーションが完成していました。その日の残りの時間は、機能を追加する予定でした。将来的には、すべてが比較的スムーズに進みましたが、バックエンダーは、検索エンジンでのクローラーの禁止や、リクエスト時に検索結果の最初の場所に表示される法人のアグリゲーターのスパムなど、多くの問題を抱えていました。特定の企業ごとに。しかし、それについては彼自身が話したほうが良いでしょう。私が追加した最初の追加機能はフルネームによる検索でした。 VKontakteのゼネラルディレクター。数時間かかりました。

そのため、私たちのアプリケーションの会社のページには、ゼネラルディレクターのアバター、彼のVKontakteページへのリンク、およびその他のデータが表示されました。勝利には結びつかなかったかもしれないが、素晴らしい収穫だった。次に、いくつかの分析を実行したいと思いました。しかし、オプションを長い間検討した結果 (UI には多くの微妙な違いがありました)、私は経済活動コードによる最も単純な組織の集約に落ち着きました。すでに夕方、最後の数時間で、バックエンドの準備ができていませんでしたが、革新的な製品を表示するためのテンプレート (アプリケーションには製品とサービスのセクションがあるはずです) をレイアウトしていました。同時に、データベースは飛躍的に膨張し、クローラーは動作し続け、バックエンダーは革新的なテキストと非革新的なテキストを区別するために NLP を実験しました)))。しかし、すでに最終プレゼンテーションの時間が近づいていました。

7. プレゼンテーション。私自身の経験から言えば、期限の約 3 ～ 4 時間前にはプレゼンテーションの準備に切り替える必要があります。特に動画の場合は撮影や編集にかなりの時間がかかります。ビデオがあるはずだった。そして、私たちにはこれに対処し、他の多くの組織上の問題も解決する特別な担当者がいました。この点で、私たちは最後の瞬間までコーディングから気をそらすことはありませんでした。

8. ピッチ。プレゼンテーションと決勝が別の平日（月曜日）に行われたのが気に入らなかった。おそらくここでも、参加者から最大限の利益を絞り出すという主催者の方針が継続したのだろう。私は仕事を休むつもりはなく、チームの他のメンバーが休みを取ったにもかかわらず、決勝戦に行きたかっただけでした。しかし、ハッカソンへの感情的な没入感はすでに非常に高まっていたため、午前 8 時にチーム (ハッカソン チームではなく作業チーム) のチャットにその日は自費で参加する旨を書き、中央センターに行きました。ピッチ用のオフィス。私たちの問題には純粋なデータ サイエンティストが多数関与していることが判明し、これが問題解決のアプローチに大きな影響を与えました。多くの人は優れた DS を持っていましたが、誰も動作するプロトタイプを持っておらず、多くの人は検索エンジンでのクローラーの禁止を回避できませんでした。私たちは、動作するプロトタイプを持っている唯一のチームでした。そして私たちは問題を解決する方法を知っていました。最終的に、私たちはこのトラックで優勝しましたが、最も競争力の低いタスクを選択したのは非常に幸運でした。他のトラックのピッチを見て、そこにはチャンスがないことがわかりました。また、私たちは陪審員たちにも非常に幸運だったと言いたいのですが、彼らはコードを注意深くチェックしてくれました。そして、レビューから判断すると、これはすべてのトラックで起こったわけではありません。

9. ファイナル。コードレビューのために何度か陪審に呼ばれた後、私たちはついにすべての問題を解決したと思い、バーガーキングに昼食をとりに行きました。そこで主催者から再び電話があり、急いで注文品をまとめて戻らなければなりませんでした。

主催者は私たちにどの部屋に入るべきかを案内し、中に入ると、そこは優勝チームのためのスピーチの練習セッションでした。ステージでパフォーマンスするはずだった人たちは十分な準備を整えていて、誰もが本物のショーマンのように出てきました。

そして、決勝戦では、他の分野の最強チームを背景に、私たちは青ざめていたことを認めざるを得ませんが、政府の顧客指名での勝利は、当然のことながら、不動産テック分野のチームが勝ち取りました。トラックでの勝利に貢献した主な要因は、既製のブランクが入手できたこと、そのおかげでプロトタイプをすぐに作成できたこと、プロトタイプに「ハイライト」が存在したこと（CEO を検索）ソーシャル ネットワーク上) とバックエンダーの NLP スキルも審査員の大きな関心を集めました。

最後に、私たちをサポートしてくれたすべての人々、私たちのトラックの審査員、エフゲニー・エフグラフィエフ（ハッカソンで私たちが解決した問題の作者）、そしてもちろんハッカソンの主催者に伝統的に感謝します。これはおそらく私がこれまで参加したハッカソンの中で最大規模で最も素晴らしいものでした。今後もこのような高い水準を維持してくれることを願うばかりです。

出所： habr.com