私はApeeScapeのエンジニアを約1年間務めており、ネットワークに参加してから同じWebRTCフレームワークプロジェクトに取り組んでいます。 オンデッロ 、医師と患者をつなぐサービス WebRTC 。ヘルスケア向けのGoogle+ハングアウトを考えてみてください。

（（ WebRTCは、Webブラウザーを介したリアルタイム通信を可能にするテクノロジーです。繰り返しになりますが、最良の例はGoogle+ハングアウトです。外部アプレットがなくても、リアルタイムのビデオチャットを利用できます。良い記事があります ここに 。 ）

私が最初にオンデッロに入社したとき、私はとして雇われました シニアRubyonRails開発者 、任務 サービスを構築する ゼロからアップ。最近、私たちはかなり大規模で複雑なシステムに取り組んでいる複数の開発者のチームです。

この投稿で、オンデッロの裏話を共有したいと思います。具体的には、次のことについてお話ししたいと思います。

1. 最先端のテクノロジー（WebRTCなど）が独自に難しい方法…
2. 単純なWebRTCRailsアプリケーションがそれほど単純ではなくなった理由と…
3. 雇われたRuby開発者がRubyコードをほとんど書かないことになった経緯。

最先端の技術とそれらがもたらす問題

先に述べたように、OndelloはすべてWebRTCプラットフォームに関するものです。だけ Chrome、Firefox、Opera 現在、プラグインを使用せずにWebRTC呼び出しをサポートしています。私たちの目的はすべてのブラウザをサポートすることでした（SafariとInternet Explorerは上記のリストから明らかな省略です）。そのため、比較的若いプラグインを使用する必要がありました。

プラグインを使い始めたとき、非常に優れたドキュメントと公式のWebRTCチュートリアルとガイドがあったため、問題はスムーズに進みました。しかし、製品が拡大し、要件が複雑になるにつれて、事態は悪化しました。これは、Railsの問題のトラブルシューティングほど簡単ではありませんでした。

WebRTCサポートコミュニティの欠如

WebRTCはやや最近のテクノロジーであり、特にこのプラグインは非常に新しいため（まだ招待のみで、かなり高い使用料がかかります）、WebRTC Rails開発者はもちろん、人々のためのガイドやチュートリアルを作成するために、多くの開発者を引き付けていません。私のような。これらの要因は、本質的に存在しない周囲の開発者コミュニティに重大な損害を与えます。

ElasticsearchRailsガイドと例

見逃すまで、これが大きな問題だとは思っていませんでした。ほとんどのアプリプラットフォームとテクノロジーでは、一般的なケースは簡単に処理できますが、非常に特定の期限の下で非常に特定の方法で物事を機能させるには、テクノロジーに関する深い知識が必要です。 または 仲間の開発者へのアクセス。

ない世界でのプログラミングを想像してみてください スタックオーバーフロー —あなたの生産性はどれほどひどく妨げられますか？

もちろん、プラグインの開発者にはある程度アクセスできました。彼らは私が期待できる限り役に立ちました。これによりいくつかの問題が軽減されましたが、単にグーグルすることと同じではありませんでした 「バーが原因でWebRTCプラグインfooが機能しない」 。

誰が責任を負っていますか？

そこにあるすべてのソフトウェアにはバグがあります。

しかし、これらの新しいWebRTCテクノロジーの場合、誰が父親で誰が子供であるかを知ることは困難でした。言い換えれば、失敗したテストケースまたは明らかなバグを見つけたとき、それが 私達 障害があったか、コードベースにバグがあった場合は、活用していました。

Googleでほとんどのテクノロジーを簡単に検索できるものは、巨大なメールチェーンになり、コードレビューが続き、場合によってはWebRTC開発者との会議が続きました。

ほとんどのテクノロジーについてGoogleで簡単に検索できるものは、巨大なメールチェーンになり、コードレビューが続き、場合によっては開発者との会議が続きました。

さらに言えば、プラグインの開発チームと私たち自身のせいで、バグの発生率は約50〜50でした。

WebRTCプラットフォームの頻繁な更新

このWebRTCプラグインの比較的初期の段階の別の結果は、 更新レート 。若いソフトウェアはより頻繁に更新され、これらの更新はしばしば壊れています。プラグインでは、古いバージョンを使い続けることができなかったため（テレコム技術として、すべてのユーザーが同じバージョンを使用して相互に通信する必要がありました）、リリースごとにリファクタリングが必要でした。

富裕層ファミリーオフィス

これらの更新は苦痛でした。多くの場合、最新の変更と同期するために完全に書き直す必要のある安定したコードがあります。場合によっては、説明なしにテストが失敗することがあります。コミュニティがない場合、どこに助けを求めますか？

場合によっては、説明なしにテストが失敗することがあります。コミュニティがない場合、どこに助けを求めますか？

WebRTCモバイルサポートに関する問題

私たちの製品が成長するにつれて、ほとんどのクライアントがモバイルサポートについて質問し始めました。

WebRTC JavaScriptライブラリが難しい場合、Androidライブラリは2倍に困難でした。サンプルアプリケーションをコンパイルするだけで2日かかり、その仕組みを理解するだけで5時間以上かかりました。プロセス全体で、「痛い」という新しい意味が生まれました。

コンパイルに10時間失敗した後、私は神経衰弱を起こし、少し泣きました。一緒になって、私はさらに2時間後に物事を機能させることができました。 Pff-そして オバマはあなたがあなた自身のビデオゲームを作るべきであると言います 。

WebRTC iOSライブラリはより簡単で、開発チームは明らかにそれに多くの時間を費やしていました。ほんの数時間で動作させることができました。

WebRTCとJavaScriptの出会い

WebRTCプラグインを超えて、JavaScriptコードベースは私に複雑さについて多くを教えてくれました。ほとんどのWebRTCフレームワークは、構成用のJavaScriptに基づいているため（例： VoIP用のPlivoのWebフレームワーク ）、それは私がオンデッロで最初の3か月間使用した唯一の言語でした。

そして、コードベースが成長するにつれて、当然、管理しにくくなりました。深くネストされたコールバック、不十分なモジュール化などがありました。これは、WebRTC JavaScriptアプリケーションでのスタートアップの最初の取り組みであり、ご想像のとおり、少し面倒でした。

最終的に、私たちはに移行しました CoffeeScript 。これにより、 サイズ 私たちのコードベースの 読みやすさ 大幅にですが、真の複雑さの問題に取り組むには十分ではありませんでした。

PubSub

すると、 PubSub 、JavaScript用のすばらしいパブリッシュ/サブスクライブライブラリであり、強くお勧めすることはできません。この小さな男は、JavaScriptロジックのかなりの部分を切り離すのを手伝ってくれました。私たちのリファクタリングプロセスは、その発見によって最善を尽くしました。

PubSubがとても便利だったのはなぜですか？ WebRTCは本質的にメディアと接続に関連しているため、イベントでいっぱいです。 PubSubを使用すると、特定のイベントを高レベルの抽象化で簡単に監視できます。これは素晴らしいソリューションであり、解決された問題を解決しなかった素晴らしい例でした。コードベースを簡素化し、開発をスピードアップする、十分に記述され、十分に文書化されたオープンソース（またはプロプライエタリ）ソリューションがある場合、 それらを使用する 。

具体的には、PubSubがないと、ユーザーのカメラがオフになるたびに、カメラのステータスを表す3つのチェックボックスを更新する必要がありました。

camera_went_off = function() { $(''#checkbox1').removeAttr('checked'); $(''#checkbox2').removeAttr('checked'); $(''#checkbox3').removeAttr('checked'); }

PubSubを使用すると、「camera_went_off」イベントをトリガーして、3つのチェックボックスすべてでそれをリッスンすることができます。さらに、誰かがこれらのチェックボックスの1つをクリックした場合、このイベントを公開して、他のチェックボックスに自分自身を更新するよう通知することもできます。

AngularJSを使用したシングルページWebRTCアプリケーションの作成

前述のように、WebRTCプラグインを使用して、より幅広いブラウザーをサポートしていました。ただし、このプラグインは、ユーザーが新しいページをロードするたびにロードする必要があります。これは、パフォーマンスや流動性などにひどい影響を与える可能性があります。

唯一の答えは、ユーザーがサイトに入るとすぐにプラグインをロードしたままにし、ユーザーが別のWebページをリロードしたり入力したりしないようにすることでした。これは不可能に聞こえます。しかし実際には、それは シングルページアプリケーション （スパ）。

データベースのパフォーマンスを向上させる方法

この時点で、 AngularJS 登場しました。

Angularを使用して、SPAに移行しました。ユーザーがサイトに入ると、プラグインを1回だけロードしました。パフォーマンスの向上は瞬時に行われました。

Angularを使用すると、SPAを構築できました。これにより、プラグインを1回（ユーザーがシステムに入ったとき）、1回だけロードできました。その後、プラグインがすでにロードされているため、ユーザーによる呼び出しはほぼ瞬時に行われます。これには多くの作業が必要でしたが、成果が得られました。パフォーマンスの向上は瞬時に行われました。

Angularはまた、JavaScriptコード全体を改善し、 MVC 構造。 JavaScriptのほとんどはAngularパターンとメッシュするように書き直す必要がありましたが、それは価値のある取り組みでした。

WebRTCはCSSに適合

CSSでも同様の複雑さの問題が発生しました。モジュール化が正しくなかったり、スタイルが重複していたなどです。他の多くのシステムと比較して、コードベースが巨大であると言っても過言ではありませんが、スタートアップで働く小さなチーム：1）時間は不可欠であり、2）組織は重要です。

CSSの複雑さを軽減するための鍵は、 サス そして 方位磁針 。

初めてSassを使用したときは、あまり満足していませんでした。しかし、今日、私はそれなしの生活を想像することはできません。要するに、 SassはCSS拡張言語です これにより、Sass構文でスタイルシートを記述し、CSSにコンパイルすることができます。

素晴らしい機能をたっぷり使ってください： 変数 、 制御ディレクティブ 、 SassScript 一般的に、そしてもっと。しかし、それで本当に私を売ったのは、そしてオンデッロに本当に大きな違いをもたらしたのは、サスの ネストされたルール 。

攻撃者が暗号化されていない状態でアクセスできる方法の1つ

これらは例によって最もよく示されています。 Sassがないと、次のようなCSSコードが作成される可能性があります。

.container_div { float: left; height: 10px; width: 20px; } .container_div a { margin-left: 15px; }

しかし、Sassを使用すると、これを次のように簡略化できます。

.container_div float: left height: 10px width: 20px a margin-left: 15px

この些細な例では、ほんの数行節約できます。しかし、Sassで次のように表現できる業界レベルのCSSコードがあると想像してみてください。

.admin-section-menu width: 270px float: left margin-right: 8px padding-top: 30px ul padding-right: 10px li width: 230px a float: left text-align: right letter-spacing: 1px font-size: 20px color: #666 width: 220px margin-bottom: 20px &.active a width: 230px color: #52672d &:after content: '25b8' display: inline position: relative left: 10px

方位磁針 はSass上に構築されたCSSオーサリングフレームワークであり、インターフェイスデザインを本当に助けてくれました。コンパスを使って作りました スプライト —すばらしいチュートリアルがあります ここに 、興味があれば。

Compassを使用すると、複雑なボタンの作成を高速化できます。ボタンの画像の状態をフォルダに入れるのと同じくらい簡単でした。その時点で、コンパスはボタンを含むスプライトを生成しました。

この例では、Compassは内のすべてのファイルを読み取ります Administration_buttons フォルダを作成し、それらを単一のスプライトファイルに入れます。

@import 'administration_buttons/*.png' @include all-administration_buttons-sprites .add-user-button width : 37px height : 37px cursor : pointer float: right @include administration_buttons-sprite(add_user) &:hover @include administration_buttons-sprite(add_user_rollover)

@include administration_buttons-sprite(add_user)を通じてコマンド、ファイルを追加します add_user.png add-user-buttonの背景画像としてクラス。

コンパスでは、いくつかの画像をフォルダに入れるだけでした。

コンパスがなければ、私は次のことをしなければならなかったでしょう。

c＃ユニットテストの例

1. すべての画像を1つのファイルに入れます。
2. 各画像のすべての座標を取得し、クラスに配置します。

特にそうではない私のような開発者のために Photoshopに精通している 、これは大幅な時間の節約になりました。そして、繰り返しになりますが、この段階では時間が重要です。

WebRTC Meets Rails

JavaScriptとCSSを数か月使用した後、ようやくRuby onRailsバックエンドに移行しました。

Railsパターンは、MVC構造で非常に明確に分割されるため、プロジェクトをシンプルに保つのに最適です。システムが成長し始めた場合、Railsパターンだけでは不十分な場合があります。代わりに、問題を解決するための新しい高レベルの方法、つまり新しい抽象化の手段について考える必要があります。

私たちは皆、コードパターン、イデオロギー、チュートリアル、ガイドなどを研究しました。ロジックをクラスに分割し、クラスを関数に分割することなどについては、誰もが知っています。しかし、めったに教えられません ソリューション 。私はそれについての本を読んだことがなく、それに関するコースを見たことがありません。

Railsでしばらく作業した後、問題はコードではなく、クライアントの問題を解決するための解決策であることがわかりました。

OndelloのWebRTCに戻る：具体的な例として、Rails上に構築された非常に単純なメールシステムがありました。しばらくの間、これは私たちにとってうまくいきました。しかし、最終的には、すべてのクライアントに特別な種類の電子メールが必要になりました。時間が経つにつれて、電子メール間の変更はますます大きくなり始めました— ????結局、すべてのクライアントは完全に異なる電子メールを必要としました。

システムが成長し始めた場合、Railsパターンだけでは不十分な場合があります。代わりに、問題を解決するための新しい高レベルの方法、つまり新しい抽象化の手段について考える必要があります。

コードベースが大きくなるにつれて、この種の機能がWebRTCフレームワークとメールシステム全体に大きな影響を与えることに気づき始めました。そのとき、あらゆる種類のメッセージの処理を担当する、メールシステム専用の別のプロジェクトを作成することにしました。メインプロジェクトは（経由で）送信するだけです 残り ）いくつかのパラメータとクライアント識別子。次に、メールシステムが電子メールの組み立てと送信を処理します。

プロジェクトを異なるプロジェクトに分割するというこのアプローチは、Ondelloを開発するときに役立ちました。これにより、メインプロジェクトはシンプルで、不必要な責任がなくなりました。

この種の問題解決は私が呼んでいるものです ソリューションアプローチ 。複雑なアプリケーションを開発するために不可欠だと思います。

結論

Ruby、Java、またはPHPの開発者であるかどうかに関係なく、Web開発に関しては、非常に多くのフレームワークとテクノロジーがあり、システムを機能させるために使用できる、または使用する必要のあるさまざまなツールがあります。私の目、見づらい 誰でも 単なる「Ruby」プログラマーまたは「Java」プログラマーとして。

大規模なシステムに関しては、クライアントのニーズに対応する巧妙に作成されたソリューションを設計する必要があります。これは、お気に入りのテクノロジーや、快適なテクノロジーにさえ常に適合するとは限りません。 Ondelloの開発における共通のテーマは、自分の好みに関係なく、いつでも利用できる最適なテクノロジーを使用して、柔軟で機敏でなければならないということでした。

Ondelloを開発するにあたり、私たちは何よりも、エンジニアでなければならず、可能な限り最高のツールで問題を解決し、効率的でスケーラブルで実用的な方法で仕事を成し遂げなければならないことを思い出しました。