私たちのプロジェクトは、ソーシャルネットワークでのアイドルの生活に関心のあるサッカーファンのためのサイトです。Sportfor Social Fansです。
以下は、5つのキャラクターと休憩を含む2つの行為での小さな遊びです。
ブランチワン
前文
手紙の最初の行で、トピックを検索し始めました。 ブレーンストーミングの結果、ほぼ20の異なるアイデアが得られました。 最も有望なのは、スポーツ、旅行、開発に関するものでした。 議論の後、スポーツがトップになりました-そして私たちは掘り始めました。
進行中の議論とブレインストーミングセッションに3日間ゆっくりと費やしました。
外来業務
この段階で最も困難だったのは、将来のサービスのアイデアを具体化することでした。 そして、これを空気のない空間ではなく、競技の条件に基づいて行うために、私たちは48時間以内に4人の人材を育成します。 もちろん、勝利は主なものではなく、参加が主なものですが、サービスはユーザーを引き付け、裁判官を手配する必要があります。
それは最も難しいステージの一つでした。 取り消し線の原則に基づいて行動し、ズームのロジックは次のようになりました。
スポーツ->人気スポーツ->サッカー->ファン->クラブ/プレーヤーフォロー
出口では、ファンがソーシャルネットワーク（Facebook、Twitter、Instagram）でチームのソーシャルアクティビティを追跡できるWebサイトを作成するというアイデアがありました。
別の日かかりました。
お母さん、お母さん、私は何をしますか
このアクションで最も難しかったのは、誘惑に負けず、少なくとも1つおきの機能に関する文に「いいえ」と答えることでした。 合計で、たとえば、ユーザーのバッジ、登録、事前調整など、約10回「いいえ」と回答しました。 そして今のところ、彼らはそれを後悔していない。
ダースの「いいえ」は、いくつかの太い「はい」を提供しました。チームとプレーヤーによる検索、公式ユーザーアカウントの翻訳、ハッシュタグによる投稿、小さな統計です。 静的情報を収集し、設計に取り組み始めました。
ある日過ごした。
ここで魚が包まれた
この場所で休憩を取ります-おそらくデザインについては、それほど面白くないでしょう。 魅力と使いやすさに焦点を合わせたとだけ言います。
私はデザインでユーザーを惹きつけたかったが、コンテンツと利便性を維持したかった。 うまくいくようです。
休憩前に最後に追加したいことは、私たちは（正直に、正直に）不正行為をせず、戦いが始まる前にコードに触れなかったことです。 デザインは最後の収穫前でした。
プロトタイプのインターフェースと設計には2日かかりました。
休憩
エスプレッソのキャップ（もちろんコニャック入り）とキャビアのサンドイッチの列に並んでいる間に、戦いの前の私たちの気質について少しお話しします。 そのため、私たちの一団には、1人のデザイナー、1人のフロントエンド、2人のバックエンド開発者がいます。 そして、監督であるマネージャーが舞台裏にいます。
地理：ノヴォクズネツク、トリアッティ、マリウポリ、グアダラハラ（予想外）。 これが私たちの切り札でした-開始後、私たちはすべての48時間にわたって連続してコードを書くことができました。 * 3番目のベルが鳴る*
最後の枝
スピーチテクニック
技術面では、トップになりたかった。 取った：
Ruby on Rails 4 、
nginx + ユニコーン + capistrano
Postgres + redis
フェイ
coffeescript 、 ember.js
チームの全員の責任を明確に定義しました。 バックエンドでは大量の作業が行われたため、開発者の地理的な位置が非常に役立ちました。
データベースに入力される膨大な量のデータに問題がありました。
Facebook、Twitter、Instagramの3つのソーシャルネットワークで、400を超えるハッシュタグとプレーヤーのアカウント、チームを追跡します。 1秒ごとに、100を超えるメッセージが生成され、ベースが横行しているため、負荷（およびhabr効果）に耐える必要があります。 タスクは興味深いです。
まず、ユーザーの投稿をPostgresに保存することにしました。 redisがなければ、できませんでした、なぜなら メッセージがストリームに入れられ、これがデータベースにあるかどうかをチェックするたびに、無駄になりすぎます。
Redisは、メッセージIDによってキャッシュを整理しました。 SortedSetが使用されました。追加とチェックの操作にはlog（n）の複雑さがあるため、このパフォーマンスが低下しないように計画しました。 優先度パラメーターは、追加の時間でした。 すべてのidレコードを永久に保持したくなかったため、優先度の低い投稿を削除しました（この場合、これは時間の尺度です）。
redisを使用する2番目のポイント（到達しませんでした）：fayeはpub / subを使用するという事実にもかかわらず、すべての着信メッセージを送信することを恐れました。 ユーザーがサイトに入ると、フロントがメッセージを必要とするエンティティのIDでリクエストをコントローラーに送信するスキームを使用することにしました。 そして、ユーザーがページを閲覧している間、彼は毎分行います。
このロックはredisに書き込まれ、2番目の要求が到着しない場合、約1分後に削除されます。 一方、メッセージを作成する場合、fayeで公開するフックは、試行ごとに、このメッセージを待機しているユーザーがいるかどうかを確認します。 そして、誰も待機していない場合、このアクションをスキップします。
前に述べたように、ember.jsの前面。 これは、簡単な1ページのアプリケーションに最適な選択肢であることがわかりました。 確かに、Webアプリケーションを開発するという彼のイデオロギーからわずかに逸脱していても困難が生じるため、ソリューションの検索が失敗した後、そのためのインターフェイスをやり直す必要がありました。
マラソン
パーティーラインを遵守することは困難でした-ミニマリズム。 48時間は必要な時間よりはるかに短いです。 そして、あなたは自分の欲望で自分自身を制限し続けなければなりませんでした。
時間はあまりありませんでした。たとえば、ユーザー向けのコンテンツよりもコードに関心がありました。 サイトを訪れたときに、誰もがすぐにその理由を理解するわけではないという問題があります。
カーテン
デブリーフィング
審査員に目を向け、ユーザーに対して少し中途半端であることが判明したのは大きな省略であると考えています。 アプリケーションが必要な理由とその使用方法の説明はありません。つまり、実質的にプロモーションコンテンツはありません。
正面のすべてが完璧というわけではありません。 インターフェースを最後まで磨く時間はありませんでした。
ソーシャルネットワークからコンテンツを収集する悪魔を完全にテストする時間はありませんでした。 問題が発生した場合、もちろん、神はすべてを再起動しますが、それらのいくつかはまだ明確ではありません。
fayeを使用してプロジェクトにリアルタイムを追加するのに十分な時間はありませんでしたが、すべての準備は整っていました。 計画どおり、投稿、サブスクライバー、および新しい投稿の数は自動的に更新され、すごい効果をもたらし、拍手を引き起こします。
しかし、全体的には、完了した作業に満足しています。 そして、私たちがどれだけ成功した興味深いプロジェクトを成功させたかはあなた次第です。
あとがき
ロシアからのすべてのチームに幸運を祈っています。
これが私たちが見つけたもののリストです。おそらくもっとたくさんあるでしょう。
rb.r13.railsrumble.com
octoscrum.r13.railsrumble.com
listio.us
object.r13.railsrumble.com
undev-angels.r13.railsrumble.com
talk-tree.r13.railsrumble.com
www.trackcha.com
railsrumble.com/entries/54-sevastopol-rb
plugin.r13.railsrumble.com
getbacktoreading.com
tip4commit.com