有効なものに差し替える必要があります。ライブラリやフレームワークは、組み合わせによっては複数のものを組み合わせて使用することも可能ですので(※だめなものももちろんあります)、各々の特性を調べて適宜組み合わせることでより効率の良い開発を行うことができるようになります。フレームワークが用意されています。ページに対し、デザイン性の高い一貫したテーマを提供します。デザインで作られているためスマートフォンのようなモバイルデバイスにも対応します。フレームワークのルールに合わせたマークアップをしなければならないケースも多々あるので、ドキュメント構造に書式の影響を及ぼしたくないのであれば、採用を充分に検討してください。サイトへのリンクが設定されているので、どのようなものがあるか参照してみてください。Handlebars,EJS,Mustache,Hogan,Underscore,jQuery.EJS,PURECSSフレームワークBootstrap,Foundation,Pure,Gumby,INK,Cardinal,Skeletonフレームワークのオーバーヘッドフレームワークの使用は、便利な反面、処理にオーバーヘッドが生じます。十分なパフォーマンスが得られない場合もあるので、スマートフォンをターゲットとする際は、必ず実機による検証を実施することをお勧めします。ブラウザーのバージョンが古い場合はどうするのか、を方針だてておきましょう。現在、非常にたくさんのライブラリやフレームワークが公開されており、評価もさまざまで、どれを選んだら良いのか分からないといった状況もあるかと思います。ライブラリ/フレームワークの選定について、検討すべき点を最大公約数的なものではありますが、以下参考となるものを示します。段階にわけて判断しています。ブラウザーで動作する必要があります。ブラウザーをサポートしている場合、あまり先進的な機能を持ったライブラリは動作しない可能性があります。ブラウザーのバージョンを確認するとともに、実際に支障なく動作するのか、使用予定の機能を前もって検証することをお勧めします。技術サポートが受けられるか否か製造元、もしくはサードベンダーで技術サポートが受けられるか確認しましょう。不具合の修正はもちろん、セキュリティ問題のような重大な問題が見つかった際の対応、連絡はどのように行われるのか確認しましょう。充分な情報があるかライブラリを使用するにあたって、使い方をはじめ充分に情報があるかを確認しましょう。インターネット上はもちろんですが、いくつか書籍が出ていたほうが安心です。段階の判断さらに絞り込んでいきます。使用するまでの学習コスト使用を開始するまでの学習コストが高すぎると、開発メンバーの追加や交代の際のスキルトランスファーや引き継ぎに時間がかかります。開発生産性そのライブラリを使用して、どれくらいの範囲の作業が賄えるのか?、また、そのライブラリを使用してスムーズに開発が行える環境用意されているのか確認しましょう。メンバーに精通して人間がいる、開発ツールがそのライブラリの入力支援機能をサポートしている等です。ロックイン度合い広い範囲をライブラリで賄ってしまうと、ロックイン度合いも広くなります。どれくらいそのライブラリにロックインして構わないのか検討しましょう。ライブラリの開発が終了してしまった場合にロックインされた部分をどうするか、少なくとも、プログラムのどの部分を依存させるかを明確にしましょう。運用コスト運用コストを測りましょう。必要なアップデートが頻繁に行われたりすると、検証の回数が増えコストがかさみます。酒巻瑞穂氏の記事の一部を、ご本人の了承を得て参考とさせていただきました。ライブラリやフレームワークの比較については、インターネット上にさまざまな記事が出ていますので、これらを参考に、どのライブラリが合っているのか、大まかなあたりをつけるに参考にすると良いでしょう。フレームワークを使用するさいのコードを比較することができますので、こちらもご活用ください。製品を使用する場合は、製品のサポート状況や、サポート体制について充分に確認しておくことをお勧めします。製品の不具合によるトラブルや、セキュリティホールが見つかった場合のアップデートの提供などがどのような行われるかを把握しておくことはとても重要です。含まれているため、マイクロソフトのサポート(有償)に問い合わせることができます。技術サポートのついた商用のフレームワーク販売されていますので、きちんとした品質と技術サポートが必要な場合はこういったものを使用することをお勧めします。プリプロセッサといったものがあります。記述するのではなく、記述が簡単、あるいは記述量が少なくて済む他の言語で記述を行い、コンパイルによりそれらを生成します。記述量が少なく容易になるように設計された簡潔な構造をもつマークアップ言語です。軽量マークアップ言語は、おもにテキストエディタを使用したマークアップ記述作業を軽減する目的で作られました。ように強力な入力補完機能を持ったエディタを使用する際にはあまり必要ではありません。ファイルを見るまでは分かりません。確認するためだけであってもコンパイルが必要になります。いった、さまざまな特性をもった言語があります。コーディングルールを統一させる目的として利用することもできます。呼ばれるものがあります。CSSファイルを出力するものです。プログラミング言語とは異なり、変数や関数といった概念がありません。セレクターと、それについてのプロパティと値のセットをひたすら列挙して記述していくことになるため、大規模複雑になりがちです。記述することができるため作業を効率化できます。プリプロセッサのリストです。サイトへのリンクが設定されているので、どのようなものがあるか参照してみてください。知識だけでは理解することができません。プリプロセッサのソースをレビューで使用することはできません。余分な情報を含んでいるため、配信用に最適化されているとは言えません。ポストプロセッサと呼びます。いったものなど、さまざまな機能を持ったものがありますので、用途に合わせ取捨選択するか組み合わせて使うと良いでしょう。テンプレート、さらにはフレームワークやツール、ベストプラクティスとなる設定を詰め込んだボイラープレートというものも提供されています。サイトを作成するさいに定型的に使用されるさまざまなものをあらかじめ含んでいるため、テンプレートやライブラリといったものを個別に集めてくる必要はなく、すぐにある程度の開発をスタートさせることができます。人気のあるボイラープレートとしては、以下のものがあります。標準に準拠していることです。標準に準拠しているかどうかを確認するための以下のバリデーションツールが公開されています。同様のバリデーションサービスを提供してしいます。バリデーションサイトを配置することができます。これは、インターネットに公開できない、イントラネット環境や、開発中のページを調べるのに便利です。バリデーションサイトをローカル環境に配置する方法については、以下の記事をご覧ください。上にも配置することができます。公開していますのでぜひご覧ください。ブラウザー毎に初期値が異なるために表示は微妙に異なってきます。ならべて、書式の設定していない文字列とテキストボックスを表示したところ。CSS」というアイディアが生まれました。ゼロにするという思い切った手法です。ブラウザーのエレメントの書式をゼロで統一するという、かつてない偉業を達した反面、サイズや枠線についてのプロパティをすべて設定しなければならないという多大な手間も生み出しました。いった弊害を避けるべく生み出され、現在も使用されているのが「Normalize.css」です。ブラウザのスタイルを消去するよりむしろ有用なデフォルトのスタイルを保存し、不具合とブラウザーごとのスタイルの違いを修正します。フォークされてたりしますが、以下から正式版を入手して使用することをお勧めします。開発製品スイートとして長い歴史とたくさん実績を持ち、ホビーユースから大規模開発までカバーできる機能と仕組みが揃っています。含まれる開発ツールの機能は、サービスパックによりアップデートされ、その分野での最新のトレンドが反映されます。できるものばかりです。フロントエンドで使用されている最新の技術を使用した開発を行うことができ、開発環境の準備も迅速に行えます。開発についてのチュートリアルを以下の記事にまとめましたのでご覧ください。開発チュートリアル開発環境の準備、開発生産性をぜひ、他のフロントエンドの開発環境と比較してください。テストとテストの管理コードであれページであれ、実際に機能の実装が済んだらテストを行い、テストケースあるいは、テスト用コードを作成しましょう。テストは、プログラムが仕様どおり動作していることを証明するものであり、テストケースやテストコードは、それを判断するための装置にほかなりません。ブラウザーがバージョンアップアップなどで変更された場合は、以前の状態での正常動作を保証していたテストを使用して、変更後の状態のものが以前とかわらず正常に動作するかを確認する必要があります。そのため、テストケースやテストコードは、検証/実行可能な状態で管理しておく必要があり、仕様そのものが変更された場合には、テストケース/テストコードにその変更を反映する必要があります。プログラムの開発で行われる一般的なテストとしては、以下のものがあります。テスト単体テストは、テスト対象となるクラスのメソッドや関数にテスト用の引数を渡し、実際に返された「結果」と仕様から想定される「期待値」の2つの値を比較しテストの合否を判断する方法です。このテストは、テストの対象となっているコードを実際に呼び出す必要があるため、テスト対象と同じプログラミング言語で記述する必要があります。ツール」と呼ばれるものは、この記述したテスト用コードを自動で呼び出すだけのもので、テスト用のコード自体はは開発者が手動で記述する必要があります。カバレッジ単体テストでは、どれだけのコードが調べられるかを把握することが重要です。関数は呼び出された際、内部の全てのコードが使用されるとは限りません。内部に条件分岐がある場合などは、引数によっては、内部のコードをほとんど使用しないまま値を返す可能性もあります。いった値を使用したテストは有効ではありません。関数の内のコードが充分に使用されるよう、きちんとシナリオを考える必要があります。この、テストによって関数内部のコードが使用される割合をコードカバレッジといいます。前後を目安とすることが多いようです。単体テストを行うタイミングテスト対象となるコードは開発は、すべての単体テストの成功によって完了となります。よって、開発のどのタイミングからはじめても構いませんが、なるべく早いタイミングでテストを開始することをお勧めします。早い段階から検証と修正を繰り返すことで不具合の早期発見を促し、作業の手戻りを防ぐとともに不具合の影響を小さく抑えることができます。テスト対象となるコードよりも先に、単体テストを作成してもかまいません。単体テスト用のコードは、テスト対象となるコードの使用方法を示すサンプルであるともいえます。この単体テストを先に作成してからテスト対象となるコードを開発する方法は「テストファースト(駆動)開発」と呼ばれています。いうアドインが用意されています。単体テスト実行環境に統合し、管理できるようになります。おける単体テストの方法については以下のページをご覧ください。テストは開発者が行う、クラスやメソッドというプログラムの最小単位を対象としたテストであり、システム全体が仕様を満たしているかを検証するためのテストではありません。単体テストの結果が正常でも、クラスやメソッドの組み合わせによってはシステムが仕様どうりに動作しないということもあるのでより上位のテストが必要となります。含めた一連の処理の流れを言います。サーバー上で動作するロジック、そこから呼び出させるバックエンドのデータベースなどの動作をふくめ、期待どおりの動作になるかどうか、です。テストは、要件ごとに正常系、異常系もふくめ綿密なテストシナリオを作成し、決められた手順に従い、ユーザーの操作を実際に行う必要があります。このテストのための手順とシナリオを「テストケース」といいます。テストケースを実行して発生した予期しない動作は、バグとしてテストケースに紐づけて管理します。操作が伴うテストは、ユーザーの操作を実際に行う必要があります。変更が頻繁なもの、制作期間が短いものについては、コストや工数の面から手動でのテストが向いています。逆に、頻繁な回帰テストや、テストケースの反復、大規模システムのテストにはソフトウェアによる自動テストが向いています。テストケースが複雑なものも、作業者のミスを避けるという意味で、手順の記録にかかるコストの折り合いがつくのであれば自動テストを使用したいところです。ページの自動テストを行うことができます。テストについては以下のページをご覧ください。ブラウザーで使用されるので、環境によっては表示や挙動が異なる場合があります。ブラウザーの組み合わせを使用してテストを行っておく必要があります。異ならない限りは必ず同じものを使用します。紹介しているので参考にしてください。ハードウェアのスペックに結果が左右されない、パフォーマンス関連のテスト以外は、多くの場合、仮想マシンでのテストで問題ありません。使用すると、複数の物理マシン、仮想マシンを含めた開発検証用のラボ環境を作成管理することができます。ついては以下のページをご覧ください。構成と管理バグの再現と管理バグが発見された際には、バグの再現手順を明確にしておくことが重要です。開発者がバグを再現できないと原因を究明することができず、修正も行えません。パグのレポートには、手順のほかにテストに使用した環境の情報も添付します。ブラウザーの種類とバージョンテストの管理についてこの項の最初に記述したように、テストはプログラムが仕様どおり動作することを証明するものです。テストをきちんと管理運用することがプログラムの品質保持に繋がります。そのためには、テスト自体の品質もきちんと管理されている必要があります。バグが発生した際の再現手順など、誰でも作業ができるように明確にしてチーム内で共有したり、実施した作業については、いつ、誰が、どのような作業を行ったか、そしてそれが今どんな状態であるかを明確に、すぐに確認できるようにしておきます。することによって、過去に作成したテストの用リソースを効率よく再利用して、テストのかかる工数を下げつつ、プログラムの品質を保持することが可能になります。テストマネージャーが付属しています。テストマネージャーの詳細については以下をご覧ください。ポイントにしぼって紹介しました。フロントエンドはインターネットのフロントエンドでもあり、それは変化していきます。ありました(まだあるけど)。現在は、スマートフォンなどのアプリがあります。普及してくると、いままでにないほどのクライアントの多様化がおこり、インターネットのフロントエンド技術も多岐にわたっていくことでしょう。なったときに、インターネットのサービスはどうなっていくのか、考えなければなりません。新しい時代のデジタルサービスは液体のように姿を変え、さまざまな機器に流れ込んでいきます。以外のフロントエンド技術とも相互運用可能な形態にしておくことをお勧めします。そのへんのお話についてはまだ後日。今年もやりマス!日本マイクロソフトが送る開発者の祭典『de:code』、今年もやります。4-8-1今なら早期割引やってますよ。お申し込みはいますぐ以下へ。amこの記事の内容ももうぼちぼち古いので、以下もお読みになることをおすすめします。