Webフロントエンド

Init.js：フルスタックJavaScriptの理由と方法のガイド

物語

それで、あなたとあなたの共同創設者は、ビジネスのためのこの素晴らしいアイデアを持っていますよね？

あなたは頭の中で機能を追加してきました。

多くの場合、あなたは潜在的な顧客に彼らの意見を求めます、そして彼らは皆それを愛しています。

さて、人々はそれを望んでいます。儲かるお金さえあります。そして、彼らがそれを持てない唯一の理由は、あなたがまだそれを実装していないからです。

それで最後に、あなたはある日座って、「やってみよう！」と言います。間もなく、アプリのビジネスロジックを実装する方法を理解しようとしています。これは、製品を前進させるキラー機能です。その方法を理解していて、自分を知っています。 できる やれ。

「完了！できます！'あなたは言う。概念実証は成功です！あとは、ウェブアプリにパッケージ化するだけです。

「OK、サイトを作成しましょう」とあなたは言います。

そして、あなたは真実に気づきます。プログラミング言語を選択する必要があります。（最新の）プラットフォームを選択する必要があります。いくつかの（最新の）フレームワークを選択する必要があります。ストレージ、データベース、およびホスティングプロバイダーを構成（および購入）する必要があります。管理インターフェースが必要です。権限システムが必要です。コンテンツマネージャーが必要です。

あなたはスリムになりたい、アジャイルになりたい。短期的および長期的に成功するのに役立つテクノロジーを使用したいと考えています。そして、それらを見つけるのは必ずしも簡単ではありません。

あなたは数十から数十を持っていますアーキテクチャ上の決定作る。そして、適切なものを作りたいと考えています。迅速な開発、一定の反復、最大の効率、速度、堅牢性などを可能にするテクノロジーを使用したいと考えています。あなたはスリムになりたい、アジャイルになりたい。短期的および長期的に成功するのに役立つテクノロジーを使用したいと考えています。そして、それらを見つけるのは必ずしも簡単ではありません。

「私は圧倒されます」とあなたは圧倒されていると感じながら言います。あなたのエネルギーはかつてと同じではありません。あなたは物事をつなぎ合わせようとしますが、それは大変な作業です。

あなたの概念実証はゆっくりと枯れて死んでいきます。

提案

このように自分でたくさんのアイデアを捨てた後、私は解決策を設計することにしました。私はそれを「初期化 ’プロジェクト（またはinit.js）。

アイデアの核心は、それらすべてを開始する単一のプロジェクトを持ち、開発者または、技術創設者はこれらの重要な決定をすべて一度に行い、それらの決定に基づいて適切な開始テンプレートを受け取ります。私は、中傷者が「1つの解決策がすべての問題に適用できるわけではない」と言うことを知っています（嫌いな人は嫌いです）。そして、彼らは正しいかもしれません。しかし、私たちはおおよその解決策を作成するために最善を尽くすことができ、Initはかなり近いと思います。

この目的を最もよく達成するには、いくつかの重要なアイデアを念頭に置く必要があります。 Initを開発するとき、私は次のことを考慮しました。

コンポーネント

コンポーネント化は、さまざまなプロジェクト間でソフトウェアコンポーネントを再利用できるため、あらゆるシステムの重要な特徴です。これがInitの主な目的です。しかし、コンポーネント化には副産物である「交換可能性」も伴います。これは、「ほぼ」同じソリューションでいくつかの異なる問題を攻撃する上で最善の味方になります。
開発のしやすさ

いくつかの問題、どこかに最もよく書かれた解決策があります Brainf * ck 。しかし、そのソリューションを（Brainfuckで）実装することは、読むことはもちろん、書くこともほぼ不可能です。それはあなたに時間と途方もない量の努力を要します。一般に、開発を容易にする言語とプラットフォームを使用する必要がありますが、自分（または後で作業する可能性のある人）にとっては難しくありません。
コミュニティ

どのプラットフォームを選択する場合でも、大きなコミュニティがあり、最も一般的な問題と一般的でない問題を解決できるコミュニティがあることを確認してください。注意：jQueryは最速、最もきれい、または最もエレガントなライブラリ-しかし、その理由だけで勝者ですコミュニティ。

これらの目標を念頭に置いて、次に、Initを作成する際に私がどのように自分で決定したかを示します。

Initは、その核となる部分で「フルスタックJavaScript ’パラダイム（一部の人々はそれまたはそのサブセットを、 MEANスタック）。そのようなと作業することによってスタック、Initは、Webアプリを開発するための非常に柔軟で完全な機能を備えた環境を作成しながら、単一の言語を使用することができます。つまり、Initを使用すると、JavaScriptをクライアントとサーバーの開発だけでなく、ビルド、テスト、テンプレート作成などにも使用できます。

しかし、少し減速して、自問してみましょう。JavaScriptを使用するのは本当に良い考えですか？

JavaScriptを選んだ理由

私は1998年からWeb開発者です。当時はPerlを使用していましたほとんどのサーバー側の開発では、それ以来、クライアント側でJavaScriptを使用しています。それ以来、Webサーバーテクノロジーは大きく変化しました。ほんの数例を挙げると、PHP、AP、JSP、.NET、Ruby、Pythonなどの言語とテクノロジーの波が次々と発生しました。開発者は、クライアント環境とサーバー環境に2つの異なる言語を使用すると、事態が複雑になることに気付き始めました。単一の言語で統合する最初の試みは、サーバー上にクライアントコンポーネントを作成し、それらをJavaScriptにコンパイルしようとしました。これは期待どおりに機能せず、それらのプロジェクトのほとんどは失敗しました（例：ASPMVCの置き換え ASP.NETWebフォーム、および GWT 間違いなく近い将来に置き換えられますポリマー）。しかし、それは本質的に素晴らしいアイデアでした。クライアントとサーバー上の単一の言語により、コンポーネントとリソースを再利用できるようになりました（これがキーワードです。 リソース ）。

答えは簡単でした。JavaScriptをサーバーに配置します。

実際にJavaScript JavaScriptサーバーサイドで生まれた Netscape Enterprise Serverにありますが、その時点では言語の準備ができていませんでした。何年にもわたる試行錯誤の末、 Node.js ついに登場し、JavaScriptをサーバーに配置するだけでなく、ノンブロッキングプログラミング、「フレッド」（I / O）の書き方を永遠に変える（読むここに多くのための）。

一言で言えば、ノンブロッキングプログラミングは、通常、これらのタスクが完了したときに何をすべきかを指定し、その間にプロセッサが他の要求を処理できるようにすることで、時間のかかるタスクを脇に置くことを目的としています。

しかし、これらのアイデアは新しいものではありませんでした。それでは、なぜNode.jsでそれほど人気が出たのでしょうか。シンプルでノンブロッキングのプログラミングは、いくつかの方法で実現できます。おそらく最も簡単なのは、コールバックとイベントループ。ほとんどの言語では、これは簡単な作業ではありません。「コールバック」は他の一部の言語では一般的な機能ですが、イベントループはそうではなく、外部ライブラリ（例：Python、ツイスター）。しかしJavaScriptでは、コールバックイベントループと同様に、言語に組み込まれており、JavaScriptに手を出したことのあるほとんどすべてのプログラマーは、それらに精通しています（または、少なくともそれらを使用したことがあります。イベントループが何であるかを完全に理解していない）。突然、Earthのすべてのスタートアップは、クライアント側とサーバー側の両方で開発者（つまり、リソース）を再利用して、「Pythonの達人が必要」を解決できるようになりました。仕事のポストの問題。

突然、Earthのすべてのスタートアップは、クライアント側とサーバー側の両方で開発者（つまり、リソース）を再利用して、「PythonGuruNeeded」の求人問題を解決できるようになりました。

だから今私たちは信じられないほど高速なプラットフォーム（ノンブロッキングプログラミングのおかげで）信じられないほど使いやすいプログラミング言語で（JavaScriptのおかげで）。しかし、それで十分ですか？それは続くのでしょうか？ JavaScriptは将来重要な位置を占めると確信しています。理由をお話ししましょう。

関数型プログラミング

JavaScriptは最初のプログラミング言語でした機能パラダイムをもたらす大衆に（もちろん、Lispが最初に来ましたが、ほとんどのプログラマーはLispを使用して本番用のアプリケーションを構築したことがありません）。 LispとSelf、 Javascriptの主な影響、革新的なアイデアがいっぱいです。これらのアイデアは、私たちの心を解放して、新しい技術、パターン、およびパラダイムを探求することができます。そして、それらはすべてJavaScriptに引き継がれます。を見てみましょうモナド、教会番号、または（より実用的な例として） Underscore.js のコレクション機能、行とコード行を節約できます。
動的オブジェクトとプロトタイプの継承

クラスなし（およびクラスの無限の階層なし）のオブジェクト指向プログラミングは、迅速な開発（オブジェクトの作成、メソッドの追加、およびそれらの使用）を可能にしますが、最も重要なことは、プログラマーが代わりにオブジェクトのインスタンスを変更できるようにすることで、メンテナンスタスク中のリファクタリング時間を短縮しますクラスの。このスピードと柔軟性は、迅速な開発への道を開きます。
JavaScriptはインターネットです

JavaScriptはインターネット用に設計、最初からここにあります消えない。それを破壊するすべての試みは失敗しました：例えば、の没落を参照してください Javaアプレット、VBScriptの置換 MicrosoftのTypeScript （JavaScriptにコンパイルされます）、そしてモバイル市場とHTML5の手によるFlashの終焉。何百万ものウェブページを壊さずにJavascriptを置き換えることは不可能なので、今後の目標はそれを改善することです。そして、その仕事に勝る人は誰もいない技術委員会39 ECMAから。

わかりました。JavaScriptの代替は毎日生まれます。 CoffeeScript 、 TypeScript そしてその JavaScriptにコンパイルされる何百万もの言語。これらの代替案は、開発段階で役立つ可能性があります（ソースマップ経由）が、2つの理由から、長期的にはJavaScriptに取って代わることができません。コミュニティが大きくなることはなく、最高の機能がECMAスクリプト（JavaScript）に採用されることです。 JavaScriptはアセンブリ言語ではありません。理解できるソースコードを備えた高級プログラミング言語なので、理解する必要があります。

今のおかげで Expressプロジェクト、ソースコードを操作するための独自のツールを作成し、ソースコードを変更し、スタイルを変更し、コメントを追加し、インストルメント化するなど、プログラムの抽象構文木を操作するように操作することで、想像できるあらゆる種類のツールを作成できます。 DOMツリー。

エンドツーエンドのJavaScript：Node.jsとMongoDB

したがって、これらがJavaScriptを使用する理由です。ここで、Node.jsとMongoDBを使用する理由としてJavaScriptを使用します。

Node.js

Node.jsは、高速でスケーラブルなネットワークアプリケーションを構築するためのプラットフォームです。これは、Node.jsサイトが言っていることとほぼ同じです。ただし、Node.jsはそれだけではありません。I/ Oアクセスを備えたJavaScriptアプリケーションに適したランタイム環境です。 Node.jsを使用してメインサーバーアプリケーションを作成する予定がない場合でも、Node.js上に構築されたツールを使用して開発プロセスを改善できます。例えば： Mocha.js ユニットテスト用、 Grunt.js 自動化されたビルドタスク、またはブラケットフルテキストコード編集用。

したがって、サーバーまたはクライアント用のJavaScriptアプリケーションを作成する場合は、いくつかを確認する必要があります。 Node.jsの例、毎日必要で使用するためです。興味深いものがいくつかあります代替案、しかしそれらのどれもNode.jsコミュニティの10％にさえありません。
MongoDB

MongoDB は NoSQL クエリ言語としてJavaScriptを使用するドキュメントベースのデータベース。これにより、エンドツーエンドのJavaScriptプラットフォームを完成させることができます。しかし、それがこのデータベースを選択する主な理由でもありません。

MongoDBはスキーマレスデータベースこれにより、オブジェクトを柔軟な方法で永続化できるため、要件の変化により迅速に適応できます。さらに、それは非常にスケーラブルそして map-reduceベース、ビッグデータアプリケーションに適しています。 MongoDBは非常に柔軟性があるため、スキーマのないドキュメントデータベース、リレーショナルデータストアとして使用できます（ただし、トランザクション）、または応答をキャッシュするためのKey-Valueストアとしても使用できます。

Express.jsを使用したサーバーのコンポーネント化

サーバー側のコンポーネント化は決して簡単ではありません。しかし、 Express.js （そして Connect.js ）「ミドルウェア」のアイデアが生まれました。私の意見では、ミドルウェアはサーバー上のコンポーネントを定義するための最良の方法です。既知のパターンと比較したい場合は、パイプやフィルターにかなり近いです。

基本的な考え方は、コンポーネントがパイプラインの一部であるということです。パイプラインはリクエスト（入力）を処理し、レスポンス（出力）を生成しますが、コンポーネントはレスポンス全体に責任を負いません。代わりに、必要なものだけを変更してから、パイプラインの次の部分に委任します。パイプラインの最後の部分が処理を終了すると、応答がクライアントに返送されます。

これらの「パイプラインの一部」を「ミドルウェア」と呼びます。明らかに、2種類のミドルウェアを作成できます。

中級者 ：要求と応答を処理するが、応答自体に対して完全な責任を負わないため、次のミドルウェアに委任するもの。
決勝：最終的な対応に全責任を負う者。リクエストとレスポンスを処理および変更しますが、次のミドルウェアに委任する必要はありません。実際には、アーキテクチャの柔軟性を考慮して（つまり、後でミドルウェアを追加する）、そのミドルウェアが存在しない場合でも（この場合、応答はクライアントに直接送信されます）、とにかく次のミドルウェアに委任することをお勧めします。

具体的な例として、サーバー上の「ユーザーマネージャー」コンポーネントについて考えてみます。ミドルウェアに関しては、決勝と中間の両方があります。決勝戦では、ユーザーの作成やユーザーの一覧表示などの機能があります。ただし、これらのアクションを実行する前に、認証用の中間体が必要です（認証されていないリクエストが着信してユーザーを作成することは望ましくないため）。これらの認証中間体を作成したら、以前に認証されていない機能を認証された機能に変換したい場所にプラグインするだけです。

シングルページアプリケーション

Initプロジェクトは作成に焦点を当てていますシングルページアプリケーション（SPA）。ほとんどのWeb開発者は、SPAを試してみようと何度も誘惑されてきました。私はいくつか（ほとんどがプロプライエタリ）を構築しましたが、それらは単にWebアプリケーションの未来であると自信を持って言えます。 SPAをモバイル接続の通常のWebアプリと比較したことがありますか？応答性の違いは数十秒のオーダーです。

SPAをモバイル接続の通常のWebアプリと比較したことがありますか？応答性の違いは数十秒のオーダーです。

SPAはWebの未来です。では、なぜレガシー形式で製品を構築するのでしょうか。私が聞く一般的な議論は、人々がSEOについて心配しているということです。しかし、物事を正しく処理すれば、これは問題にはならないはずです。Google自体にはとても良いチュートリアルそうする方法について、そしていくつかの良いコメントがありますここに同じように。

Backbone.js、Marionette.js、およびTwitterBootstrapを使用したクライアント側MV *

多くのことが言われています SPA用のMVC *フレームワーク。難しい選択ですが、上位3つは Backbone.js 、 Ember.js 、および Angular.js 。

3つすべてが非常に高く評価されています。しかし、どれがあなたに最適ですか？

残念ながら、私はAngular.jsの経験が非常に限られていることを認めなければならないので、この議論から除外します（これについて詳しくは、 Angular.jsチュートリアル）。現在、Ember.jsとBackbone.jsは、同じ問題を攻撃する2つの異なる方法を表しています。

Backbone.js は最小限で単純であり、単純なSPAを作成するのに十分なだけの機能を提供します。一方、Ember.jsは、SPAを作成するための完全でプロフェッショナルなフレームワークです。それはより多くの鐘と笛を持っていますが、より大きな学習曲線も持っています。

アプリケーションのサイズに応じて、featuresUsed / featuresAvailableの比率を確認するのと同じくらい簡単に決定できます。これにより、大きなヒントが得られます。

Initの場合、ほとんどのシナリオをカバーしたかったので、SPAを簡単に作成するためにBackbone.jsを選択し、コンポーネント化のためにBackbone.Marionette.Viewを選択しました。このように、すべてのコンポーネントは単純なアプリケーションであり、最終的なアプリは必要に応じて複雑にすることができます。

スタイリングも課題ですが、フレームワークを頼りに私たちを救済することができます。 CSSの場合、これ以上のことはありません。 Twitterブートストラップ、これは、箱から出してすぐに使用できるスタイルとカスタマイズが簡単。

ブートストラップは、もっと少なく言語であり、オープンソースであるため、必要に応じて変更できます。それはであるUXコントロールのトンが付属しています Bootstrapサイトで十分に文書化されています。さらに、カスタマイズモデルそれはあなたがあなた自身を作成することを可能にします。それは間違いなくその仕事の人です。

ベストプラクティス：Grunt.js、Mocha.js、Chai.js、RequireJS、CoverJS

最後に、いくつかのベストプラクティスを定義し、Initがそれらの実装と保守にどのように役立つかを確認する必要があります。私たちのソリューションは、Node.js自体に基づくいくつかのツールを中心としています。

Mocha.js そして Chai.js ：

これらのツールを使用すると、適用することで開発プロセスを改善できます。 TDD または BDD 、ユニットテストを整理するためのインフラストラクチャとそれらを自動的に実行するためのランナーを提供します。

がある数千人 JavaScriptのユニットテストフレームワークの。では、なぜMocha.jsを使用するのでしょうか。簡単な答え：それは柔軟で完全です。

長い答え：2つの重要な機能（インターフェース、レポーター）と1つの重要な欠如（アサーション）があります。説明させてください。
- インターフェイス ：スイートと単体テストのTDDの概念に慣れている場合もあれば、「説明する」と「すべきである」という動作仕様のBDDの概念を好む場合もあります。 Mocha.jsでは、両方のアプローチを使用できます。
- 記者：テストを実行すると、結果のレポートが生成され、さまざまなレポーターを使用してこれらの結果をフォーマットできます。たとえば、継続的インテグレーションサーバーにフィードする必要がある場合は、それを実行するレポーターを見つけることができます。
- アサーションライブラリの欠如 ：問題になるどころか、Mocha.jsは、選択したアサーションライブラリを使用できるように設計されており、さらに柔軟性があります。があるたくさんのオプション、しかしここでChai.jsが活躍します。
Chai.jsは、次の3つの主要なアサーションスタイルのいずれかを使用できる柔軟なアサーションライブラリです。
- 主張する ：TDDオールドスクールのクラシックなアサーションスタイル。例えば。：
  assert.equal(variable, ”value”);
- 期待する ：チェーン可能なアサーションスタイル。BDDで最も一般的に使用されます。例えば。：
  expect(variable).to.equal(“value”);
- すべき ：BDDでも使用されますが、動作仕様「it（“ should do some ..”）」で繰り返し聞こえるはずなので、Expectの方が好きです。例えば。：
  variable.should.equal(“value”);
Chai.jsはMocha.jsと完全に結合します。これら2つのライブラリだけを使用して、TDD、BDD、または考えられる任意のスタイルでテストを記述できます。
Grunt.js ：
財務モデリングの方法

Grunt.jsを使用すると、ファイルの単純なコピーアンドペーストや連結から、テンプレートの事前コンパイル、スタイル言語（SASSおよびLESS）のコンパイル、単体テスト（mocha.jsを使用）、リンティング、コードの縮小（例： UglifyJS またはクロージャーコンパイラ）。独自の自動化されたタスクをGruntに追加するか、 Gruntレジストリ、何百ものプラグインが利用可能です（ここでも、背後に素晴らしいコミュニティがあるツールを使用すると効果があります）。グラントもできますファイルを監視する変更されたときにアクションをトリガーします。
RequireJS ：

RequireJSは、モジュールをロードする別の方法のように聞こえるかもしれません。 AMD 、しかし私はそれがそれ以上のものであることをあなたに保証することができます。その理由を理解するには、最初にモジュールの名前空間（demo.views.helloなど）のアイデアに言及する必要があります。これにより、各モジュールを独自の名前空間でラップすることにより、グローバル名前空間の汚染を回避できます。問題は、これらのモジュールは再利用できないことです。1つの「インスタンス」の名前空間を変更すると、すべての「インスタンス」の名前空間が変更されます。それとは対照的に、RequireJSでは最初から再利用可能なモジュールを定義できます。（さらに、それはあなたが受け入れるのに役立ちます依存性注入にモジュールがグローバル変数にアクセスすることは避けてください。）
CoverJS ：

コードカバレッジテストを評価するためのメトリックです。名前が示すように、現在のテストスイートでカバーされているコードの量がわかります。 CoverJSは、（次のようなコード行の代わりに）ステートメントをインストルメント化することによってテストのコードカバレッジを測定します JSCoverage ）コード内で、インストルメント化されたバージョンのコードを生成します。それはまたあなたを養うためにレポートを生成することができます継続的インテグレーションサーバ。

ブランチを使用して機能を切り替える

Initを開始したとき、ユーザーがプロジェクトに必要なさまざまな機能をアクティブ化および非アクティブ化する方法が必要でした。この機能を実装するために、gitのブランチシステムに根本的なアプローチを取ることにしました。

本質的に、各ブランチは、ユーザーが含めることができる1つまたは複数の機能を表します。プロジェクトをゼロから開始する場合は、必要な最小限のブランチから始めてから、目的のブランチとマージして他のテクノロジーを追加します。たとえば、Backbone.jsとMarionette.jsを使用してプロジェクトを開始するとします。さて、Backbone.jsブランチから始めて、それをMarionetteブランチとマージし、追加したい機能のすべてのビットを続けていくことができます。

init.jsとJavascript