Hackathon DevDays'19(パート1):推奨事項のある日記、ウォーキングと液体民主主義の旅程の生成者

最近、私たち JetBrainsとITMO大学の企業修士プログラム「ソフトウェア開発/ソフトウェアエンジニアリング」について話しました。 4月29日月曜日のオープンデーに関心のあるすべての人を招待します。 大学院の利点、学生に提供するボーナス、および見返りに必要なものについて説明します。 また、お客様の質問にも必ずお答えします。



オープンデーは、大学院生が学ぶタイムズビジネスセンターのJetBrainsオフィスで開催されます。 17:00から。 すべての詳細を確認し、 mse.itmo.ruでイベントに登録できます。 是非、後悔しないでください!



プログラムのトレーニングの主な要素の1つは練習です。 学生には、毎週宿題、学期のプロジェクト、ハッカソンなど、たくさんのことがあります。 勉強しながら現代の開発方法論と技術に完全に没頭しているおかげで、卒業生はすぐに大規模なIT企業の作業プロセスに参加します。



この投稿では、6か月ごとに行われるDevDaysハッカソンについて詳しく説明します。 ルールは簡単です。3〜4人のチームが集まり、3日以内に学生は自分のアイデアを実現します。 これから何ができますか? 学生自身からこの学期のハッカソンプロジェクトに関するストーリーの最初の部分を読んでください:)



映画のおすすめ日記







アイデアの著者

イワン・イルチュク

チーム構成

Ivan Ilchuk-映画プロットの解析、サーバー

Vladislav Korablinov-日記の近接性と映画のプロットを比較するためのモデルの開発

Dmitry Valchuk-UI

Nikita Vinokurov-UI、デザイン



私たちのプロジェクトの目的は、デスクトップアプリケーションを作成することでした-日記は、そのエントリに従ってユーザーに映画を推奨します。



この考えは、大学に行って自分の問題について考えたときに思いつきました。 「人が直面する問題が何であれ、いくつかの古典はすでにこれについて書いています」と私は思いました。 「そして誰かが書いたので、それは誰かがすでに撮影したことを意味します。」 それで、同じ精神的苦痛を持つ男性についての映画を見たいという欲求は、それ自体で現れました。



明らかに、多種多様な個別の日記と個別の推奨サービスがあります(ただし、通常、推奨は以前に気に入ったものに基づいています)。 原則として、このプロジェクトには重要なポイントで映画を見つけることと共通点がありますが、それでもまず第一に、アプリケーションは日記の機能を提供します。



これをどのように実装しましたか? マジックボタンが押されると、日記はサーバーにエントリを送信します。サーバーでは、Wikipediaからの説明に基づいて映画が選択されます。 私たちのフロントエンドはElectronで作られました(最初はサーバーではなくローカルにユーザーデータを保存することを決めたため、サイトではなく使用します)、サーバーと推奨システム自体はPythonでした:TFは説明から取得されました-日記入力ベクトルに近接して比較されたIDFベクトル。



チームの1人のメンバーはモデルのみに関与し、もう1人はフロントエンド全体に関与していました(最初は3番目のメンバーとともに、後にテストに切り替えました)。 私はウィキペディアとサーバーから映画のプロットを解析することに従事していました。



段階的に、結果に近づき、多くの問題を克服しました。最初はモデルに大量のRAMが必要であったという事実から始まり、データをサーバーに転送することが困難でした。



今、夜の映画を見つけるために、あなたは多くの労力を必要としません。3日間の作業の結果は、デスクトップアプリケーションと、ユーザーがhttps経由でアクセスするサーバーであり、簡単な説明とポスターを含む5つの映画の選択を受け取りました。



このプロジェクトには非常に前向きな印象があります。仕事は早朝から深夜まで刺激的で、結果のアプリケーションは、大学での宿題に関する日記や初日の初日に関する映画に「眠れない夜」のスタイルで非常に面白い結果を定期的に与えます部門で。



関連リンク、インストーラーなどはこちらにあります



ルートジェネレーター



アイデアの著者

アルテミエワイリーナ

チーム構成

Artemyeva Irina-チームリーダー、メインループ

Gordeeva Lyudmila-音楽

プラトノフヴラディスラフ-ルート



街を歩き回るのが本当に好きです。建物、人、歴史について考えてください。 しかし、私の居住地を変更しても、遅かれ早かれ、ルートを選択するという問題に直面します。思いつくすべてが過ぎ去りました。 そこで、ルートの生成を自動化するというアイデアが生まれました。ルートの開始点と長さを指定すると、プログラムがオプションを提供します。 ウォーキングは長くなる可能性があるため、このアイデアの論理的な発展は、噛んでリラックスできる「停止」の中間点を指定する機能を追加しているようです。 開発の別の部門は音楽でした。 音楽に行くことは常により楽しいので、生成されたルートのプレイリストを選択する機能を追加することは素晴らしいことです。



既存のアプリケーションの中には、そのようなソリューションが見つかりませんでした。 最も近い類似物は、ルートプランナーです:Googleマップ、2GISなど。



このようなアプリケーションは、電話で使用するのが最も便利であるため、Telegramを使用することが適切なオプションになりました。 マップを表示して音楽を再生することができ、ボットを書くことでこれらすべてを管理できます。 マップの主な作業は、Google Map APIを使用して行われました。 Pythonを使用すると、両方のテクノロジーの友達を簡単に作成できます。



チームには3人がいたので、タスクは2つの独立したサブタスク(カードでの作業と音楽での作業)に分割されたので、みんなが独立して作業できるようになり、結果を処理しました。



Google Map APIを使用してTelegramボットを作成した人は誰もいなかったため、主な問題はプロジェクトに割り当てられた時間の長さでした。 また、TelegramボットAPIを選択することは困難でした。ブロックのため、すべてのユーザーが機能するわけではなく、すべてを構成するために苦労する必要がありました。



それとは別に、ルートを生成するタスクがどのように解決されたかに言及する価値があります。 2つの場所の間でルートを作成するのは簡単ですが、ルートの長さしかわからない場合にユーザーに提供するものは何ですか? ユーザーが10キロメートル歩くことを望みます。 ランダムな方向では、直線距離が10キロメートルのポイントが選択され、その後、実際の道路に沿った実際のポイントへのルートが構築されます。 ほとんどの場合、直接ではないため、指定された10キロメートルに短縮します。 そのようなルートには多くのオプションがあります-実際のルートジェネレータがあります!



最初は、散歩に最適なルートを取得し、これらのセクションに従って音楽を生成するために、マップを堤防、中庭、道路などの緑のゾーンに対応するセクションに分割しました。 しかし、Google Map APIを使用してこれを行うのは簡単ではありませんでした(彼らはこの問題を解決できませんでした)。 ただし、特定の種類の場所(店舗、公園、図書館)を通るルートの構築を実現することが判明しました:ルートが指定されたすべての場所をバイパスしたが、目的の距離がまだ移動していない場合、ランダムな方向にユーザーが指定した距離まで延長されます また、Google Map APIを使用すると、推定所要時間を計算できるため、正確な所要時間のプレイリストを選択できます。



その結果、開始点、距離、中間点によってルートを生成することが判明しました 。 ルートのセクションに応じて音楽を分類するための準備はすべて整っていましたが、時間がないため、単に追加のUIブランチとしてプレイリストを選択する可能性を残すことにしました。 したがって、ユーザーは、聴く音楽を独自に選択することができました。



音楽を扱う際の主な問題は、ユーザーがサービスのアカウントを持っている必要がないように、mp3ファイルの入手先がわからないことでした。 ユーザーに音楽を要求することにしました(UserMusicモード)。 これにより、新しい問題が発生します。すべての人がトラックをダウンロードできるわけではありません。 1つの解決策は、ユーザーからの音楽を使用してリポジトリを作成することです(BotMusicモード)-サービスに関係なく、そこから音楽を生成できます。



完全ではありませんが、なんとかタスクに対処することができました。使用したいアプリケーションが手に入りました。 一般に、これは非常にクールです。3日前にはアイデアがあり、それをどのように実装するかは考えていませんでしたが、現在は有効なソリューションがあります。 私にとって、それは非常に重要な3日間でした。 知識が足りないものを思いつくのはもう怖くありません。チームリーダーになることは信じられないほど面白かったです。そして、チームに行った素晴らしい人たちをよりよく認識しました。



液体民主主義







アイデアの著者

スタニスラフ・シチェフ

チーム構成

スタニスラフシチェフ-チームリーダー、データベース

Nikolay Izyumov-ボットインターフェイス

アントン・リヤブシェフ-バックエンド



異なるグループ内では、多くの場合、決定または投票が必要です。 通常、そのような場合、彼らは直接民主主義に頼りますが、グループが大きくなると、問題が発生する可能性があります。 たとえば、グループの人は、質問に頻繁に答えたり、特定のトピックに関する質問に答えたりすることを望んでいない場合があります。 大規模なグループでは、問題を回避するために、他の人を選択の負担から解放するすべての人々から「代議員」の別個のグループを選択するときに、 代表的な民主主義に頼ります。 しかし、このシステムには欠点があります。



両方のシステムの問題を解決するために、ブライアンフォードは液体民主主義の概念を提案しました。 このようなシステムでは、単純に希望を表現するだけで、誰でも普通のユーザーまたは代理人の役割を自由に選択できます。 任意の人が独立して投票するか、1つ以上の問題について代表者に投票することができます。 代理人も投票できます。 さらに、代表者が有権者の手配を中止した場合、投票はいつでも取り消すことができます。



流動的な民主主義の使用例は政治に見られますが、さまざまな人々のグループで日常的に使用するために同様のアイデアを実装したかったのです。 次のDevDaysハッカソンで、私たちは流動的な民主主義の原則に投票するためにTelegramボットを書くことにしました。 同時に、私はそのようなボットの頻繁な問題を回避したかった-ボットからのメッセージで一般的なチャットを詰まらせる。 解決策は、できるだけ多くの機能を個人的な会話に組み込むことです。



このボットを作成するために、Telegram APIを使用しまし 。 投票と委任の履歴を保存するために、PostgreSQLデータベースが選択されました。 データベースと通信するためにボットはFlask-serverを上げました。 これらのテクノロジーを選んだのは、 私たちはすでに、マジストラシーで勉強しているときに彼らと交流する経験がありました。 プロジェクトの3つのコンポーネント(データベース、サーバー、ボット)の作業は、チームメンバー間で正常に分散されました。



もちろん、3日間は短い時間なので、ハッカソンの間にプロトタイプのレベルのアイデアを実現しました。 その結果、投票の開始と匿名の結果に関する情報のみを一般チャットに書き込むボットを作成しました。 投票し、投票する機会は、ボットとの個人的なやり取りを通じて実現されます。 投票するために、直接の注意が必要な問題のリストを表示するチームが導入されます。 個人的なやり取りでは、デリゲートのリストと以前の投票を確認できます。また、トピックの1つに対する投票を行うことができます。



作業例付きのビデオ



プロジェクトに取り組むのは面白かったです、私たちは真夜中まで大学にとどまりました。 これは非常に疲れるが、これは研究から気をそらすための素晴らしい方法であると思われる。 緊密なチームで楽しい経験がありました。



PS:次の学年の政権への入学はすでに開かれています 。 今すぐ参加しよう!



All Articles