難しい簡単にする方法。 「Project1917」の作成の歴史

2016年6月末に、ロシアでの10月革命100周年に捧げられたProject 1917のメンバーは、プロジェクトのWeb部分の実装を支援するよう依頼されました。 これは、ニコラスIIが彼の写真を投稿するソーシャルネットワークであると想定されていた、レーニンは彼が好きだ、とトロツキーはコメントしている。 私たちは彼らに目を向けた最初の人ではありませんでした。非常に短い時間でこれを行うことは不可能であるか、非常に高価になると誰かが言いました。







プロジェクトの作成者は、これは史上最高のソーシャルネットワークであると言います-すべてのユーザーが長い間亡くなっているからです。 これはソーシャルネットワークの形式のサイトで、ユーザーは100年前に起こった出来事について書いた本物の歴史上の人物です。 すべての資料は、実際の歴史的文書、手紙、ジャーナリスティック資料、写真アーカイブからのデータ、ビデオアーカイブからのデータに基づいています。 私たちの時代の読者は、これらの投稿にコメントしたり、ソーシャルネットワークで共有したりできます。







問題を研究した結果、それは非常に実現可能であり、示された時間にそれを行う時間があることがわかりました。 私たちの主なプロファイルは負荷の高いプロジェクトの管理とサポートであるという事実にもかかわらず、私たちはWeb開発から始めましたが、まだ開発に従事していることがあります）



キーポイント：締切日がありました-正確な分。 これは11月14日の15:00です。この時点で、プレスリリースはメディアに送られ、Yandexは自宅でプロジェクトを公開し、メガホンを持っている人がプロジェクトの公式発表を赤の広場で行います。 期限を少なくとも1時間ずらす確率はゼロでした。



クライアントとの作業の調整の段階で、プロジェクトの実施の明確なスケジュールを決定しました。 多くの資料があることは明らかであり、サイトはリリースの1時間前ではなく、はるかに早い段階でコンテンツを埋める必要があります。 8月上旬に、管理パネルをプロダクションにロールアウトし、組版を開始することにしました。 9月に-管理パネルを完成させてデータのバインドを開始し、10月に私たちの時代のユーザーとの対話を実装します（承認、共有、いいね、コメントの実装）。 11月7日（良い日）、負荷テストを実施することが決定されました。 11月14日-プロジェクトの開始、開始から1週間後、ユーザーをサイトに戻すためにプッシュ通知を実装します。 12月、このサイトは英語に翻訳される予定でした。

チームを結成して仕事を始めます

7月3日に、合意、作業計画に署名し、リポジトリで最初のコミットを行いました。







厳しい締め切りのある複雑なプロジェクトでは、チームが次のように見えないことが非常に重要です。Vasyaは働いており、10人のマネージャーがそれに取り組んでいます



タイミングは厳しいものの、最初の原則はロケット科学なし（ロケット技術なし）です。 私たちは、火星に飛んでジャガイモを使い果たした男を救うロケットを建設していません。 私たちはただソーシャルネットワークを作っています。





作業中のチャットの1つで問題を解決する過程でステッカーが表示された場合、それは次のことを意味していました。「みんな、何か問題があります。タスクを小さなサブタスクに分割し、個々に解決し、人生を複雑にしないでください」 「。



チームにはプロジェクトマネージャー、3人のプログラマ、2人の管理者、2人のテスターがいて、ある時点でチームを2つの地理的ゾーンに分割することが決定されました。イルクーツクで開発が最初に行われました）。



どのスタックが選択されましたか？ 毎日新しいテクノロジーが登場しますが、そのすべてにおいて、単にファッショナブルであるという理由だけで、不要なものを含めるのは非常に簡単です。 これを行う必要はありません-古いロシアのことわざを忘れないでください：「ジープが急なほど、トラクターを追いかけるのに時間がかかります。」 そして、プログラミングでは、このことわざが当てはまります。



どのようにしてスタックを構築することにしましたか？ Webサーバーとして、PHP-FPMでNginxをインストールし、データベースにMySQL 5.7を選択し、バックエンドのフレームワークとしてLaravelを選択しました-これが作業フレームワークです。 フロントエンドのフレームワークはAngular 1.5でした。



Angular 1.5を使用する主な原則の1つは、よく知っているものだけを使用することです。または、何も知らない場合はすぐに答えを見つけることができます。 2番目のAngularの最初の多かれ少なかれ安定したバージョンは、開発を開始してから2週間後にリリースされ、書き直す必要がなくなりました。 それ以前は、バージョン1.5、1.4で多くの作業を行い、すべての落とし穴を知っていたため、使用できることを行うことにしました。



グラフィックスの作業には、Imagemagicを使用し、ビデオとgifの作業にはFFmpegを使用しました。間違いなくMemcachedを使用し、独自のタスクでGulpを使用して静的データを収集および使用します。

管理パネルとタイプセットを作成します

1か月後、管理パネルを既に発行しました。 管理部分を構築する方法、サイトはどのようにコンテンツで満たされていますか？ L5-repositoryパッケージをベースとして使用しました-これは、わずか3チームでRESTful APIを実装し、すべてのモデルを作成し、複雑な関係を持つ移行ボックスから移行を作成し、1つの完全なコントローラーを生成して1つのルートでデータを操作できるようにするLaravelのパッケージです。 管理フロントエンドは、1ページのWebアプリケーションとして実行されました。ngResourceサービスは、APIとの対話に積極的に使用されます。 フロントエンド側では、自作のJSキャッシュを実装しようとしました。これにより、何かを一度ダウンロードした場合に管理パネルからサーバーにデータが常に要求されなくなり、クライアントでそれを処理できます。 すべての管理パネルは、Angularコンポーネント上に構築されています。



編集作業をどのように構築したいかをクライアントと話し合うことは非常に重要でした。 管理パネルの理想的なバージョンは、5人が同時に任意のセクションで作業している場合です。誰かが名前を更新し、誰かがテキストです。 クライアントは一貫した作業を計画しました。投稿のテキストを担当し、投稿の順序を担当する人がいます。 コンポーネントが重複しないようにし、動作するデータのみを更新するようにしました。 平均して、コンポーネントの開発には約1時間かかり、管理パネルの基本的に新しいセクションが1日で展開されました。







最も単純なコンポーネントはテキストエディターです。 これが通常のTinyMCEであることが明らかですが、わずかに変更されています。 「リンクを挿入」ボタン、「ヒーローを挿入」ボタンがあり、たとえばウラジミールレーニンへのリンクがテキストに挿入され、写真に美しいポップアップが表示されるなど、テキストにすぐに表示されていることがわかります。







これが編集委員会の外観です。初めて管理パネルが表示されました-彼らは非常に満足しており、非常に便利で簡単だったので、犬の使い方を教えることさえできます：

管理パネルを完成させ、データをバインドします

そこで、管理パネルを作成し、プロジェクトの公開部分であるフロントエンドに到達しました。 レイアウトが少し遅れて私たちに与えられ、タスクは外出先で毎日変わりました。 これは最初の警報ベルでした。私たちは間に合わないかもしれません。 すぐに活字に組んで、ライブデータに適応することにしました。



フロントエンドをどのように実装することにしましたか？ 検索、フィルタリング、ソートには、管理パネルで使用するパッケージ（L5リポジトリ）も使用します。つまり、すべてのデータをリポジトリとして使用します。 PHPコードの観点から、サイト上のいくつかのブロックを個別のサービスに割り当て、それらを単一のオブジェクトとして接続します。サイトから1つのコンポーネントを削除して別の場所に挿入する必要がある場合は、それらを構築する必要があります動作するはずです。







たとえば、このような基本的なコンポーネント-カレンダーがあります。 このコンポーネントからすぐに「ヘッダー」コンポーネントがあります。 これは人気のある投稿を含む美しい写真で、共有することができます：







次に、カレンダーと「通信」し、「何日描画する必要があるか」という外観の投稿のフィードがあります。







推奨ブロックとサブスクリプションブロックはテープによって異なります。 天気、通貨、誕生日などのブロックはカレンダーに依存します。 実際のFacebookのように、その日の全体像を一度に見ることができます。



バックエンド、つまりサーバーの負荷を予測できました-TORに一定量のRPSが示されましたが、サイトを表示するデバイスを予測することはできません。 したがって、フロントエンドの公開部分をできるだけシンプルにすることが決定されました。



まず、すべての静的はキャッシュから直ちに要求されます。動的な一意のユーザー情報のために、キャッシュされていないAPIを使用します。 すべての動的読み込みはHTMLを介して機能します。 サーバーは静的なテープを生成します。たとえば、スクロールします。新しいページがHTMLで到着しました。つまり、データはJSONではありません。 突然JavaScriptを使用してページで何らかの作業を行う必要がある場合、AngularJSの使用を最適化または最小化し、Bindonceライブラリを積極的に使用して、1回限りのバインディングを実装できます。 すべての画像は、Nginxツールを使用して、http_image_filterモジュールを使用して最適化されます。ピーク負荷が発生した場合、静的分布をCDNに転送します。

いいね、共有、コメントの作成

それらは1週間で実装されました。 まず、たとえば、likeやcommentは何ですか？ 実際、データベースの観点から見ると、これは多対多の関係を実装する通常のテーブルです。たとえば、投稿ID、ユーザーIDなどがあります。 別の方法でアプローチし、このリレーションをリレーションとしてではなく使用すること、つまり、投稿にコメントがある場合、hasOne投稿を持つ別のエンティティにコメントを割り当てることにしました。 同時に、Googleでは、「いいね！を書く方法」という要求に対して、たとえば、モーフバイマンなどの接続を使用することを提案しています。 テーブルが、接続するオブジェクトの2つの識別子ではなく、同じタイプ、同じIDを格納する場合。 たとえば、投稿や動画でいいねをしたい場合は、like-type、like-idを行うよう提案されます。 これは不要だと判断しました。いいね！テーブルは1つだけになります。



さらに。 たとえば、ページ上の共有数を1行で取得するために、ミューテーターメソッドを積極的に使用しました。たとえば、VK共有、OK共有、FB共有があります。 フロントエンドはLocalstorageを使用します。たとえば、ブラウザでサポートされていない場合、Cookieのレベルまで低下する可能性があります。 たとえば、ユーザーが投稿を気に入ったという情報を保存します。つまり、データベースへのリクエストを行わないたびに投稿のリストを受け取らないようにします。 Localstorageにすべてを一度保存​​し、ページがレンダリングされ、ハートが色付けされ、データベースに余分なリクエストを行うことはありません。



ユーザーと連携するためのAPIをキャッシュしません。たとえば、関連するコメントをリアルタイムで受け取る必要があります。 ユーザーに伝えることはできません。申し訳ありませんが、5分間のキャッシュがあります。5分間でコメントが表示されます。 また、突然サーバーとの動的な通信などが必要になった場合は、Node.jsで既に動作しているLaravelのチャネルでイベントを安全に使用できます。



共有について。 多くの人が、なぜこれに何らかの既成のソリューションを使用していないのかと尋ねます。 実際、コンテンツに加えて、テストを受けたり、写真をアップロードしたり、ハガキを作成したり、ソーシャルネットワークで共有したりできる特別なプロジェクトがたくさんあります。 同時に、他の人が友人のリボンでこの写真を見た場合、彼はそれをクリックして、テストページに移動する必要があります。 つまり、Ngnixレベルでは、ボットを必要な場所にリダイレクトするのではなく、ボットをスタブに送信します。



また、共有システムでは、独自のカウントメカニズムを実装しました。 この種のすべてのシステムでは、関連情報（再投稿の数）を表示し、特定の統計、評価などを計算するためにデータベースに保存することが非常に重要です。 非常に多くの場合、初めて共有に遭遇したプログラマーは、次のように計算を実装します。cronのタスクで、バックエンドはソーシャルネットワークのAPIにリクエストを行い、新しいデータを受信して​​保存します。 このアプローチには2つの重大な欠点があります。1つ目は、現在の情報が関連していない可能性があることです（たとえば、クラウンは10分ごとに1000件の投稿のデータを更新します）。アドレスはあなたを禁止するかもしれません。



私たちは反対に行きました。 ユーザーがソーシャルネットワークで投稿を共有する瞬間に、共有共有ポップアップを使用して、jsコードから（それぞれ、クライアントのIPアドレスから）ソーシャルネットワークapiに同時にリクエストを行い、実際の再投稿数を取得し、この数に1を追加します（ユーザーまだ行っていません）、データベースに保存します。 したがって、私たちは常に最新の状態でシリングの数のベースを維持します。たとえば、あなたが共有し、数が10増加したという影響もあります。だから誰かがあなたと共有しています、あなたはこのようです：好きなようにすべてがリアルタイムで機能します！」

プッシュ通知を作成して実行します

11月14日に近づいて、何も悪い兆候はありませんでした。私たちは冷静にストレステストに合格し、サイトのリリース準備を完全に整えました。 連中は考えを変えて、今のところプッシュの開発をプッシュすることにしました。 ピーク時のトラフィックはローンチ当日に予想され、その日に加入者ベースを収集する必要がありました。 プッシュ通知を開発するとき、人々は主な問題に注意を払いません。開発エラーの価格は新しいドメインであり、サブスクライバーベースを失います。 たとえば、あなたは長い間長い間考え、最終的にあなたのブラウザでこの「私は私に通知を送信することを確認します」チェックボックスを得たことを確認しました。 その時点でコードが次のようになっている場合（それ以上に、設定をプッシュするためのアクセス許可を落とすまで、人はこの死を目にすることはありません）：





トークンを保存しなかった、ただ保存した



プッシュ型の実装を決定した方法。 基本は、Google Fairbaseサービスです。 十分な時間が残っていないので、ドキュメントを間違いなく見て、それに応じてすべてを行います。 その人がサイトで許可されていない場合、彼らは非常に簡単にそれをすることにしました。 この人のためにユニークなCookieを生成し、それとともにデータベースにトークンを保存します。 次に、サイトにログインした人は、彼がCookieを持っていることを確認し、データベースにトークンが含まれていることを確認し、特定のユーザーにトークンを再バインドし、個人的な通知を送信します。



Laravel-FCMパッケージをメーラーとして使用することにしました。 FCMまたはFirebaseを使用した人は誰でも、メッセージを送信するには、すべてを1,000個のトークンのパックに分割し、個別の要求を行う必要があることを知っています。 Laravel-FCMが引き継ぎます。 同時に、非常に簡単にペイロードをプッシュ型で生成し、個人用のある種の個人的な写真、個人的な見出し、個人的なテキスト、個人的なリンクなどを作成することができます。



時間がありました。 彼らはリリースの1時間前にプッシュを開始しました。 翌日の夕方、ザヴィレッジ、メデューサ、CNN、BBCがプロジェクトについて書き、彼らはトレチャコフギャラリーでメディアの宴会を開催しました。 そしてそのような小さな皮肉：2016年12月まで、当社の本社は正式に森の真ん中にありました。 それがどれほどクールか想像してみてください。CNNで書いたプロジェクトを実行し、フォレストで実行しました。

ローカライズを行う

だから、私たちはプロジェクトを立ち上げ、それが機能し、バグを修正しました。12月は庭にあり、ローカライズを行う必要があります。 プロジェクトを2日でローカライズしました。



このようなデータベースに2つの言語バージョンに関する情報を保存することにしました。 別の言語（投稿、ヒーロー、グループ、ビデオ、地理位置情報）に翻訳できる各エンティティに対して、言語を格納するlang-ロシア語/ 1英語）と、コピー時に「バックアップ」レコードのIDが保存されるmirror_idフィールドを追加しました。



このようなコピーでは、たとえば、オブジェクトに何らかの関係がある場合（作成者が投稿、ジオロケーションを持っている場合）、さらにそのエンティティがすべてコピーされている場合（mirror_idが空でない場合）、そのエンティティへの関係がコピーされたレコードに再割り当てされますそうでない場合は、最初にコピーされてから再接続されます。



たとえば、ロシア語版では、ニコラスIIによって書かれた2つの投稿があります。最初の投稿をコピーすると、投稿と作成者の両方がコピーされ、2番目の投稿をコピーすると、2番目の投稿のみがコピーされ、作成者には以前にコピーされたNicholas IIが割り当てられます。

次は？

プロジェクトは現在どのように生きていますか？ 基本的な機能はすでに開発されており、実際には何も変更されておらず、 特別なプロジェクト （ゲーム、テスト）を行っています。これまでのところ、誰もがすべてを書き直そうとしています。 私たちは平和的な目的のためにエネルギーを送ります-特別なプロジェクトがあり、何かが完璧ではなかった場合、それを書き換えず、新しい特別なプロジェクトに実装します。



たとえば、私たちが作成した特別なプロジェクトから：

• 「レーニンをロシアに入れないでください」というゲームは猫に関する有名な論理ゲームです。レーニンを捕まえなければなりませんでした。
• 「 Tinder1917」 -革命の英雄と知り合いのサービス。
• 「1917年にあなたは誰ですか？」というテストが最も上位にランクされ、大勢の人が参加し、約150万件の結果が生成されました。

結論

1. 複雑さを単純にすることは簡単で、何かを複雑にし、単純なものを複雑にすることはさらに簡単です。
2. 物語を思い出してください。革命は必ずしも良い結果につながるとは限りません。
3. あなたの間違いから学びましょう。 サーバーを自分で設置するまで、なぜ寝たのか理解できません。 あなた自身が何らかの困難な間違いを犯すまで、何かが壊れた理由を理解することはできません。 腕立て伏せで失われたドメインは、最悪の事態ではありません。
4. ファッションを追いかけないでください。 あなたのスタックを見て、そこに大きな庭を作らないでください。 新しい問題を解決する必要がある場合は、それに合ったツールが既にあるかどうかを確認してください。新しいファッショナブルなフレームワークを見つける必要はありません。そのドキュメントは中国語のみで、次のようになります。試します。」 これは必要ありません。
5. そして、99.99の稼働時間の数値は制限ではありません。 いつでも改善できます。