Rails Rumble Experience

先週末(10月13日と14日)、 aishekと2人の同僚がRails Rumble 2012ハッカソンに参加しました。 競争によると、48時間で完成したRailsアプリケーションをデプロイする必要があります。



私は、ビールや他の楽しみの酔った箱に加えて、本当に良い経験を得たと言わなければなりません。



ユーザーからフィードバックを収集し、タイプ(スパム、アイデア、感謝など)で自動的に分類し、その後の処理のためにシステムの別のユーザーにメッセージを割り当てる可能性があるアプリケーションを作成することにしました。



この問題の声明に基づいて、システムに次のものがあると判断しました。



コンテストの開始までに、アプリケーションの設計とアーキテクチャの非常に一般的な概要を準備することができました。



イベントのクロニクル



10月13日土曜日



04:00始めましょう。 サーバーのセットアップ、分類子の作成、フレームのレイアウトの責任を共有します。 新しいRailsアプリケーションを作成し、デプロイを開始します。



07:30最初の展開では、メインページに壊れたリンク、検索フィールド、テキストがあります。 認可を開始します。 テキスト分類子の準備ができていません。



10:00ユーザーの登録/承認、完成したレイアウトがあります。 会社概要を作成し始めました。 分類器はまだ準備ができていません。



13:00テキスト分類子の準備ができました。ユーザーは会社を持っています。 朝食、昼食です。 すべてが少しショック状態にあり、最初の疲労が現れます。



14:00テキスト分類子に問題のある場所が見つかった場合、すでに完成したアプリケーションのデザインはうんざりしているようです。 より多くの場合、「What the f *** o?」という叫びが聞こえます。 まったく何も起こりません。



16:00仕事が起きて、店に行くことにしました。



17:00店から来て寝ました。 後に判明したように、これは重要な決定でした。



20:00再び上昇。 働くために!



21:00分類器が修復されました。 メッセージングシステムの作成を開始しました。



10月14日日曜日



00:00メッセージが送信され、ユーザーが働いており、会社が作成されていますが、計画されたすべてをマスターできないという永続的な感覚があります。 インターフェイスはまだ非常に生です。



02:00デザインのやり直し、バグの修正



04:00眠りにつくことにしました。 仕事初日の結果によると、メインページ、ユーザーと会社のプロファイル、メッセージの送信と分類がありました。 会社の公開部分はありませんでした。 一般に、アプリケーションは機能しましたが、それでも理想からはほど遠いものでした



10:00寝坊 食べて仕事に走る。



12:00ソーシャルネットワークを介した承認があります。 同僚の1人が「私に触らないで!」という言葉で座って、アプリケーションの外観を取り上げました。



16:00統計機能の半分が準備できたので、そこで停止することにしました。 誰もがすでにこのアプリケーションを気に入っています(同僚に感謝します)。そして、ようやく何が機能し、どのように機能するかをようやく理解できました。



20:00ますます貴重な時間を費やし始めるあらゆる種類の小さなタスクがあります。会社の公開部分であるメッセージにコメントを作成しました。 生産性が再び低下し始めます。



23:00リフレッシュするために、再び店に行くことにしました。



10月15日月曜日



00:00ユーザーへのタスクの割り当てが完了しました。 統計の作成を開始しました。



02:00メッセージに対する正しい応答としてコメントをマークする準備ができた機能。



03:00けいれん的な「 即興生産」が始まります。



04:00アプリケーションが実行され、競争は終わりました!



結論



彼らは意図したものの約半分(それ以上)を作りました。 インターフェイスを調整し、エラーをキャッチするのに多くの時間がかかりました。 動作中のアプリケーションと使いやすい動作中のアプリケーションの間には、多くの作業があります(そのため、見積もりに2を掛ける必要があります)。 12時間の連続稼働後、生産性はゼロに低下します。リラックスすることを恐れないでください。 目的の機能の一部を捨てることによって、1つの方法でのみ目標日付に追いつくことができます。



この段落をマネージャーに見せてください



マネージャーがこのようなイベントに参加することは非常に便利です。 彼の役割は次のように見えます。これは、プログラマーが連続して4時間以上働くことを許可しない人です。 彼は常に機能の優先順位を知っており、機能のどの部分を放棄できるかを理解しています。 マネージャーは、アプリケーションの「焙煎」の程度も管理する必要があります。48時間(だけでなく)でプロジェクト全体を完璧にする時間はありませんが、一部の部分を輝かせて、このタスクをマネージャーに任せてください。



ここに私たちが得たものがあります: http : //ideahq.r12.railsrumble.com



ハッカソンに参加してください!



PS Rails Rumbleまたは私たちのアプリケーションについて質問がある場合は、コメントでお気軽にお問い合わせください。喜んでお答えします。



All Articles