一般的な HTML と CSS の問題への対処 - ウェブ開発を学ぶ

一般的な HTML と CSS の問題への対処
=======================

* 前のページ
* Overview: Cross browser testing
* 次のページ

ここでは、HTML と CSS のコードで発生する可能性のある一般的なクロスブラウザーの問題、および問題の発生を防ぐため、または発生する問題を修正するために使用できるツールについて具体的に説明します。これには、コードのリンティング、CSS プレフィックスの処理、問題を追跡するためのブラウザーの開発者ツールの使用、ブラウザーにサポートを追加するための polyfill の使用、レスポンシブデザイン問題への取り組みなどが含まれます。

| 前提条件: | 主要な HTML、CSS、および JavaScript 言語に精通していること。クロスブラウザーテストの原則の高水準のアイデア。 |
| --- | --- |
| 目標: | 一般的な HTML と CSS のクロスブラウザーの問題を診断し、それらを修正するための適切なツールとテクニックを使うことができるようにする。 |

HTML と CSS の問題
--------------

 一部の HTML と CSS の問題は、両方の言語がかなり単純で、コードがうまく作成され、効率的であり、ページ上に「機能の目的」を意味的に記述していることを確認するという意味で開発者がそれらについて真剣に考えていないという事実にあります。最悪の場合、JavaScript を使用して Web ページのコンテンツとスタイル全体を生成するため、ページにアクセスできなくなり、パフォーマンスが低下します (DOM 要素の生成にはコストがかかります)。他のケースでは、初期の機能がブラウザー間で一貫してサポートされていないため、一部の機能やスタイルが一部のユーザには機能しないことがあります。
 レスポンシブデザインの問題も一般的です。デスクトップブラウザーで見栄えの良いサイトはモバイル端末だとひどい経験を提供するかもしれません、内容が読むには小さすぎるか、高精細なアニメーションのせいで遅いでしょう。

HTML/CSS に起因するクロスブラウザーエラーを減らす方法を見てみましょう。

まず最初に：一般的な問題を解決する
-----------------

このシリーズの最初の記事では、まずクロスブラウザーの問題に集中する前に、デスクトップ/モバイルの最新ブラウザーでいくつかテストしてコードが正常に機能するか確認することをお勧めします。

HTML のデバッグおよび CSS のデバッグの記事では、HTML/CSS のデバッグに関する基本的なガイダンスをいくつか提供しました。基本に慣れていない場合は、先に進む前に必ずこれらの記事をよく読んでください。

基本的には、HTML と CSS のコードが整形式で、構文エラーがないかどうかをチェックすることです。

**メモ:** CSS と HTML に関する一般的な問題の 1 つは、異なる CSS ルールが互いに矛盾が生じるときに発生します。 サードパーティのコードを使用している場合、これは特に問題になる可能性があります。たとえば、CSS フレームワークを使用して、それが使用しているクラス名の 1 つが別の目的ですでに使用されているものと衝突しているとします。 または、ある種のサードパーティ API (たとえば広告バナーの生成) によって生成された HTML に、すでに別の目的で使用されているクラス名または ID が含まれていることもあります。これが起こらないようにするには、最初に使用しているツールを調べて、それらを中心にコードを設計する必要があります。また、"名前空間" CSS も価値があります。ウィジェットがある場合は、それが明確なクラスを持っていることを確認してから、このクラスでウィジェット内の要素を選択するセレクタを起動します。そうすれば競合は起こりにくくなります。例えば、 `.audio-player ul a` です。

### 検証

HTML の検証では、すべてのタグが適切に閉じられてネストされていること、DOCTYPE を使用していること、およびタグを正しい目的で使用していることを確認します。良い戦略はコードを定期的に検証することです。これを可能にするサービスの 1 つに、W3C マークアップ検証サービスがあります。これを使用すると、コードを指定してエラーのリストを返すことができます。

![The HTML validator homepage](/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS/validator.png)

CSS にも同様の話があります — プロパティ名が正しくつづられていること、プロパティ値が正しくつづられていて、それらが使われているプロパティに対して有効であること、中括弧を見逃していないということです。この目的のために、W3C には CSS Validator も用意されています。

### Linters

取りうるもう一つの良い選択肢は、エラーを指摘するだけでなく、CSS の悪いプラクティスについての警告、および他の点にもフラグを立てることができる、いわゆる Linter アプリケーションです。Linter は一般的に、エラー/警告の報告においてより厳格またはより緩やかになるようにカスタマイズできます。

オンラインリンターアプリケーションは多数ありますが、そのうち最良のものはおそらく Dirty Markup (HTML、CSS、JavaScript)、および CSS Lint (CSS のみ) です。これらはコードをウィンドウに貼り付けることができ、十字でどんなエラーにでもフラグを立てるでしょう、そしてそれは問題が何であるかを知らせるエラーメッセージを得るためにそれから隠されることができます。Dirty Markup では、*Clean* ボタンを使用してマークアップを修正することもできます。

![Dirty Markup application displaying the message "Unexpected character in unquoted attribute" over the following incorrect HTML markup: <div id=combinators">](/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS/dirty-markup.png)

However, it is not very convenient to have to copy and paste your code over to a web page to check its validity several times. What you really want is a linter that will fit into your standard workflow with the minimum of hassle.

Many code editors have linter plugins. GitHub's Atom code editor for example has a rich plugin ecosystem available, with many linting options. To show you an example of how such plugins generally work:

1. Install Atom (if you haven't got an up-to-date version already installed) — download it from the Atom page linked above.
2. Go to Atom's *Preferences…* dialog (e.g. by Choosing *Atom > Preferences…* on Mac, or *File > Preferences…* on Windows/Linux) and choose the *Install* option in the left-hand menu.
3. In the *Search packages* text field, type "lint" and press Enter/Return to search for linting-related packages.
4. You should see a package called **lint** at the top of the list. Install this first (using the *Install* button), as other linters rely on it to work. After that, install the **linter-csslint** plugin for linting CSS, and the **linter-tidy** plugin for linting HTML.
5. After the packages have finished installing, try loading up an HTML file and a CSS file: you'll see any issues highlighted with green (for warnings) and red (for errors) circles next to the line numbers, and a separate panel at the bottom provides line numbers, error messages, and sometimes suggested values or other fixes.

![Screen shot showing how html tidy points out a missing quote.](/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS/atom-htmltidy.png)
![CSSLint lists errors including missing brackets, and warning such as too high specificity.](/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS/atom-csslint.png)

Other popular editors have similar linting packages available. For example, see:

* SublimeLinter for Sublime Text
* Notepad++ linter
* VSCode linters
### Browser developer tools

The developer tools built into most browsers also feature useful tools for hunting down errors, mainly for CSS.

**メモ:** ブラウザーが不正な形式のマークアップを自動的に修正しようとするため、HTML エラーは開発ツールではそれほど簡単には表示されない傾向があります。W3C バリデータは HTML エラーを取得するための最良の方法です — 上の Validation を見てください。

As an example, in Firefox the CSS inspector will show CSS declarations that aren't applied crossed out, with a warning triangle. Hovering the warning triangle will provide a descriptive error message:

![The developer tools cross out invalid CSS and add a hoverable warning icon](/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS/css-message-devtools.png)

Other browser devtools have similar features.

Common cross browser problems
-----------------------------

Now let's move on to look at some of the most common cross browser HTML and CSS problems. The main areas we'll look at are lack of support for modern features, and layout issues.

### Browsers not supporting modern features

This is a common problem, especially when you need to support old browsers (such as Internet Explorer) or you are using features that are implemented in some browsers but not yet in all. In general, most core HTML and CSS functionality (such as basic HTML elements, CSS basic colors and text styling) works across all the browsers you'll want to support; more problems are uncovered when you start wanting to use newer HTML, CSS, and APIs. MDN displays browser compatibility data for each feature documented; for example, see the browser support table for the `:has()` pseudo-class.

Once you've identified a list of technologies you will be using that are not universally supported, it is a good idea to research what browsers they are supported in, and what related techniques are useful. See Finding help below.

#### HTML fallback behavior

Some problems can be solved by just taking advantage of the natural way in which HTML/CSS work.

Unrecognized HTML elements are treated by the browser as anonymous inline elements (effectively inline elements with no semantic value, similar to `<span>` elements). You can still refer to them by their names, and style them with CSS, for example — you just need to make sure they are behaving as you want them to. Style them just as you would any other element, including setting the `display` property to something other than `inline` if needed.

More complex elements like HTML `<video>`, `<audio>`, `<picture>`, `<object>`,and `<canvas>` (and other features besides) have natural mechanisms for fallbacks to be added incase the resources linked to are not supported. You can add fallback content in between the opening and closing tags, and non-supporting browsers will effectively ignore the outer element and run the nested content.

For example:

```html
<video id="video" controls preload="metadata" poster="img/poster.jpg">
  <source
 src="video/tears-of-steel-battle-clip-medium.webm"
 type="video/webm" />
  <!-- Offer download -->
  <p>
    Your browser does not support WebM video; here is a link to
    <a href="video/tears-of-steel-battle-clip-medium.mp4"
 >view the video directly</a
 >
  </p>
</video>
```

This example includes a simple link allowing you to download the video if even the HTML video player doesn't work, so at least the user can still access the video.

Another example is form elements. When new `<input>` types were introduced for inputting specific information into forms, such as times, dates, colors, numbers, etc., if a browser didn't support the new feature, the browser used the default of `type="text"`. Input types were added, which are very useful, particularly on mobile platforms, where providing a pain-free way of entering data is very important for the user experience. Platforms provide different UI widgets depending on the input type, such as a calendar widget for entering dates. Should a browser not support an input type, the user can still enter the required data.

The following example shows date and time inputs:

```html
<form>
  <div>
    <label for="date">Enter a date:</label>
    <input id="date" type="date" />
  </div>
  <div>
    <label for="time">Enter a time:</label>
    <input id="time" type="time" />
  </div>
</form>
```

The output of this code is as follows:

**メモ:** You can also see this running live as forms-test.html on GitHub (see the source code also).

If you view the example on a supporting browser, you'll see the UI features in action as you try to input data. On devices with dynamic keyboards, type-specific keypads will be displayed. On a non-supporting browser like Internet Explorer, the inputs will just default to normal text inputs, meaning the user can still enter the correct information.

#### CSS fallback behavior

CSS is arguably better at fallbacks than HTML. If a browser encounters a declaration or rule it doesn't understand, it just skips it completely without applying it or throwing an error. This might be frustrating for you and your users if such a mistake slips through to production code, but at least it means the whole site doesn't come crashing down because of one error, and if used cleverly you can use it to your advantage.

Let's look at an example — a simple box styled with CSS, which has some styling provided by various CSS features:

![A red pill button with rounded corners, inset shadow, and drop shadow](/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS/blingy-button.png)

**メモ:** You can also see this example running live on GitHub as button-with-fallback.html (also see the source code).

The button has a number of declarations that style, but the two we are most interested in are as follows:

```css
button {
  /\* … \*/

  background-color: #ff0000;
  background-color: rgba(255 0 0 / 1);
  box-shadow:
    inset 1px 1px 3px rgba(255 255 255 / 0.4),
    inset -1px -1px 3px rgba(0 0 0 / 0.4);
}

button:hover {
  background-color: rgba(255 0 0 / 0.5);
}

button:active {
  box-shadow:
    inset 1px 1px 3px rgba(0 0 0 / 0.4),
    inset -1px -1px 3px rgba(255 255 255 / 0.4);
}
```

Here we are providing an RGBA `background-color` that changes opacity on hover to give the user a hint that the button is interactive, and some semi-transparent inset `box-shadow` shades to give the button a bit of texture and depth. While now fully supported, RGBA colors and box shadows haven't been around forever; starting in IE9. Browsers that didn't support RGBA colors would ignore the declaration meaning in old browsers the background just wouldn't show up at all so the text would be unreadable, no good at all!

![Hard to see pill button with white text on an almost white background](/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS/unreadable-button.png)

To sort this out, we have added a second `background-color` declaration, which just specifies a hex color — this is supported way back in really old browsers, and acts as a fallback if the modern shiny features don't work. What happens is a browser visiting this page first applies the first `background-color` value; when it gets to the second `background-color` declaration, it will override the initial value with this value if it supports RGBA colors. If not, it will just ignore the entire declaration and move on.

**メモ:** The same is true for other CSS features like media queries, `@font-face` and `@supports` blocks — if they are not supported, the browser just ignores them.

#### Selector support

Of course, no CSS features will apply at all if you don't use the right selectors to select the element you want to style!

In a comma separated list of selectors, if you just write a selector incorrectly, it may not match any element. If, however, a selector is invalid, the entire list of selectors and the selector block are ignored. For this reason, you never want to include a :-moz- prefixed pseudo class or pseudo-element in a group of selectors as all browsers other than Firefox will ignore the entire block.

We find that it is helpful to inspect the element you are trying to style using your browser's dev tools, then look at the DOM tree breadcrumb trail that DOM inspectors tend to provide to see if your selector makes sense compared to it.

For example, in the Firefox dev tools, you get this kind of output at the bottom of the DOM inspector:

![The breadcrumb of elements is html > body > form > div.form > input#date](/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/HTML_and_CSS/dom-breadcrumb-trail.png)

If for example you were trying to use this selector, you'd be able to see that it wouldn't select the input element as desired:

```css
form > #date
```

(The `date` form input isn't a direct child of the `<form>`; you'd be better off using a general descendant selector instead of a child selector).

#### Handling CSS prefixes

Another set of problems comes with CSS prefixes — these are a mechanism originally used to allow browser vendors to implement their own version of a CSS (or JavaScript) feature while the technology is in an experimental state, so they can play with it and get it right without conflicting with other browser's implementations, or the final unprefixed implementations. So for example:

* Mozilla uses `-moz-`
* Chrome/Opera/Safari use `-webkit-`
* Microsoft uses `-ms-`

Here's some examples:

```css
-webkit-transform: rotate(90deg);

background-image: -moz-linear-gradient(left, green, yellow);
background-image: -webkit-gradient(
  linear,
  left center,
  right center,
  from(green),
  to(yellow)
);
background-image: linear-gradient(to right, green, yellow);
```

While none of these properties requires a prefix, you may encounter this old CSS in a codebase. The first line shows a `transform` property with a `-webkit-` prefix — this was needed to make transforms work in older versions of Safari and Chrome until the prefix-free feature was supported.

The last three lines show three different versions of the `linear-gradient()` function, which is originally how linear gradient were written:

The first one has a `-moz-` prefix, the second a `-webkit-` prefix, and the third one has no prefix. This third version shows the final version of the syntax supported in all evergreen browsers.

Prefixed features were never supposed to be used in production websites — they are subject to change or removal without warning, and cause cross browser issues. This is particularly a problem when developers decide to only use say, the `-webkit-` version of a property — meaning that the site won't work in other browsers. This actually happened so much that other browsers implemented `-webkit-` prefixed versions of several CSS properties. While browsers still support some prefixed property names, property values, and pseudo classes, now experimental features are put behind flags so developers can test them during development.

If you insist on using prefixed features, make sure you use the right ones. You can look up what browsers require prefixes on MDN reference pages, and sites like caniuse.com. If you are unsure, you can also find out by doing some testing directly in browsers.

Try this simple example:

1. Open up google.com, or another site that has a prominent heading or other block-level element.
2. Right/Cmd + click on the element in question and choose Inspect/Inspect element (or whatever the option is in your browser) — this should open up the dev tools in your browser, with the element highlighted in the DOM inspector.
3. Look for a feature you can use to select that element. For example, at the time of writing, the main Google logo had an ID of `hplogo`.
4. Store a reference to this element in a variable, for example:

```js
const test = document.getElementById("hplogo");
```

5. Now try to set a new value for the CSS property you are interested in on that element; you can do this using the style property of the element, for example try typing these into the JavaScript console:

```js
test.style.transform = "rotate(90deg)";
test.style.webkitTransform = "rotate(90deg)";
```

As you start to type the property name representation after the second dot (note that in JavaScript, CSS property names are written in lower camel case, not hyphenated), the JavaScript console should begin to autocomplete the names of the properties that exist in the browser and match what you've written so far. This is useful for finding out what versions of the property are implemented in that browser.

At the time of writing, both Firefox and Chrome implemented `-webkit-` prefixed and non-prefixed versions of `transform`. As a general rule, put the prefixed version of a property name before the unprefixed version so that the unprefixed version overrides the prefixed version. Prefixed properties aren't guaranteed to perform well; unprefixed properties are.

Once you've found out which prefixes you need to support, you should write them all out in your CSS, for example:

```css
-webkit-appearance: none;
appearance: none;
```

Generally, you will rarely need to include a prefix; and you may want to delete them from old code basis you inherit as a maintainer. If you do need to include prefixed features or super modern features, test for feature support using `@supports`, which allows you to implement native feature detection tests, and nest the prefixed or new feature within the `@supports` block.

#### Responsive design problems

Responsive design is the practice of creating web layouts that change to suit different device form factors — for example, different screen widths, orientations (portrait or landscape), or resolutions. A desktop layout for example will look terrible when viewed on a mobile device, so you need to provide a suitable mobile layout using media queries, and make sure it is applied correctly using viewport. You can find a detailed account of such practices in The building blocks of responsive design.

Resolution is a big issue too — for example, mobile devices are less likely to need big heavy images than desktop computers, and are more likely to have slower internet connections and possibly even expensive data plans that make wasted bandwidth more of a problem. In addition, different devices can have a range of different resolutions, meaning that smaller images could appear pixelated. There are a number of techniques that allow you to work around such problems, from simple mobile first media queries, to more complex responsive image techniques.

Another difficulty that can present problems is browser support for the features that make the above techniques possible. media queries are not supported in IE 8 or less, so if you want to use a mobile first layout and have the desktop layout then apply to old IE versions, you'll have to apply a media query polyfill to your page, like css3-mediaqueries-js, or Respond.js.

Finding help
------------

There are many other issues you'll encounter with HTML and CSS, making knowledge of how to find answers online invaluable.

Among the best sources of support information are the Mozilla Developer Network (that's where you are now!), stackoverflow.com, and caniuse.com.

To use the Mozilla Developer Network (MDN), most people do a search engine search of the technology they are trying to find information on, plus the term "mdn", for example, "mdn HTML video". MDN contains several useful types of content:

* Reference material with browser support information for client-side web technologies, e.g. the <video> reference page.
* Other supporting reference material, e.g. the Guide to media types and formats on the web,
* Useful tutorials that solve specific problems, for example, Creating a cross-browser video player (en-US).

caniuse.com provides support information, along with a few useful external resource links. For example, see https://caniuse.com/#search=video (you just have to enter the feature you are searching for into the text box).

stackoverflow.com (SO) is a forum site where you can ask questions and have fellow developers share their solutions, look up previous posts, and help other developers. You are advised to look and see if there is an answer to your question already, before posting a new question. For example, we searched for "disabling autofocus on HTML dialog" on SO, and very quickly came up with Disable showModal auto-focusing using HTML attributes.

Aside from that, try searching your favorite search engine for an answer to your problem. It is often useful to search for specific error messages if you have them — other developers will be likely to have had the same problems as you.

まとめ
---

Now you should be familiar with the main types of cross browser HTML and CSS problems that you'll meet in web development, and how to go about fixing them.

* 前のページ
* Overview: Cross browser testing
* 次のページ


よくあるアクセシビリティの問題を扱う - ウェブ開発を学ぶ

よくあるアクセシビリティの問題を扱う
==================

* 前のページ
* Overview: Cross browser testing
* 次のページ

次に、私たちはアクセシビリティに注意を向け、一般的な問題、簡単なテストの方法、そしてアクセシビリティの問題を見つけるための監査/自動化ツールの使い方を説明します。

| 前提条件: | コア HTML、CSS、および JavaScript 言語に精通していること。 高水準のクロスブラウザーテストの原則の理解。 |
| --- | --- |
| 目的: | 一般的なアクセシビリティの問題を診断し、それらを修正するための適切なツールとテクニックを使用できるようにすること。 |

アクセシビリティとは？
-----------

ウェブ技術のコンテキストでアクセシビリティと言うとき、ほとんどの人は即座にウェブサイトやアプリが障碍のある人にも使えるようにすることを考えます。 例えば、

* 視覚障碍者は、スクリーンリーダーや拡大/ズームを使用してテキストにアクセスします。
* 運動機能障碍を持つ人々は、キーボード（または他のマウス以外の機能）を使用してウェブサイトの機能をアクティブ化します。
* 聴覚障碍を持つ人々は、音声や動画のコンテンツのキャプション/字幕またはその他の代替テキストに依存しています。

しかし、アクセシビリティが単に障碍に関するものであると言うのは間違っています。 実際、アクセシビリティの目的は、高性能デスクトップコンピュータを使用しているユーザーだけでなく、できるだけ多くのコンテキストで、できるだけ多くのユーザーがウェブサイトやアプリを使用できるようにすることです。 極端な例には次のものが含まれます。

* モバイルデバイスのユーザー。
* テレビ、腕時計などの代替ブラウジングデバイスのユーザー。
* 最新のブラウザーを搭載していない可能性がある古いデバイスのユーザー。
* 低速プロセッサを搭載している可能性がある、低スペックデバイスのユーザー。

ある意味では、このモジュール全体がアクセシビリティについてのものです — クロスブラウザーテストは、あなたのサイトができるだけ多くの人々によって使用できることを確認します。アクセシビリティとは？では、この記事よりも完全かつ徹底的にアクセシビリティを定義します。

とは言っても、この記事では、クロスブラウザーと障碍のある人々を取り巻く問題のテスト、そして彼らのウェブの使い方について説明します。 モジュール内の他の場所で、レスポンシブデザインとパフォーマンスのような他の分野についてはすでに説明しました。

**メモ:** ウェブ開発における多くのことと同様に、アクセシビリティは 100% 成功したかどうかではありません。 特にサイトが複雑になるにつれて、100% のアクセシビリティを全てのコンテンツに対して達成することはほとんど不可能です。 その代わりに、防御的なコーディングを介して、できるだけ多くの人があなたのコンテンツのできるだけ多くにアクセスできるようにし、ベストプラクティスに従うようにする努力をします。

よくあるアクセシビリティの問題
---------------

このセクションでは、従うべきベストプラクティスと共に、特定の技術と結びつけて、ウェブのアクセシビリティに関して生じる主な問題のいくつかと、サイトが正しい方向に進んでいるかどうかを確認するための簡単なテストについて、詳細を説明します。

**メモ:** アクセシビリティは道徳的に正しいことであり、ビジネスには適していますし（多くの障碍のあるユーザー、モバイルデバイスのユーザーなどが重要な市場セグメントを提示しています）、ウェブ資産を障碍のある人々がアクセスできないようにすることは、世界の多くの地域で法律にも違反しています。 詳しくはアクセシビリティのガイドラインと法律を読んでください。

### HTML

意味論的 HTML（要素が正しい目的のために使用されているもの）は箱から出してすぐにアクセスできます — そのようなコンテンツは晴眼者でも読めますし（CSS を使用して、テキストを小さくしすぎたり、隠したりするような愚かなことはしないでください）、スクリーンリーダー（文字通りウェブページをユーザーに読み上げるアプリ）などの支援技術でも使用可能になり、他の利点も付与されます。

#### 意味論的構造

意味論的 HTML で最も重要なすばやい勝利は、コンテンツに見出しと段落の構造を使用することです。 これは、スクリーンリーダーのユーザーが、必要なコンテンツをすばやく見つけるために文書の見出しを道標として使用する傾向があるためです。 あなたのコンテンツが見出しを持っていない場合、彼らが得るのは、何かを見つけるための道標のないテキストの巨大な壁だけです。 悪い HTML と良い HTML の例としては、

```html
<font size="7">私の見出し</font> <br /><br />
これが私の文書の最初のセクションです。
<br /><br />
ここにも段落を追加します。
<br /><br />
<font size="5">私の副見出し</font>
<br /><br />
これが私の文書の最初のサブセクションです。
私は人々がこのコンテンツを見つけることができるようにしたいです！
<br /><br />
<font size="5">私の2番目の副見出し</font>
<br /><br />
これは私のコンテンツの2番目のサブセクションです。
私は最後のものよりも面白いと思います。
```

```html
<h1>私の見出し</h1>

<p>これが私の文書の最初のセクションです。</p>

<p>ここにも段落を追加します。</p>

<h2>私の副見出し</h2>

<p>
  これが私の文書の最初のサブセクションです。
  私は人々がこのコンテンツを見つけることができるようにしたいです！
</p>

<h2>私の2番目の副見出し</h2>

<p>
  これは私のコンテンツの2番目のサブセクションです。
  私は最後のものよりも面白いと思います。
</p>
```

さらに、あなたのコンテンツはそのソース順で論理的に意味があるべきです — あなたは後で CSS を使い、いつでもそれを望んだ所に置くことができますが、最初から正しいソース順を手にするべきです。

テストとして、あなたはサイトの CSS をオフにして、CSS がなければそれがどれほど理解できるか見ることができます。 コードから CSS を取り除くだけでこれを手動で行うことができますが、最も簡単な方法はブラウザー機能を使用することです。 例えば、

* Firefox: メニューバーから [表示] > [スタイルシート] > [スタイルシートを使用しない] を選択します。
* Safari: メインメニューから [開発] > [スタイルを無効にする] を選択します（[開発] メニューを有効にするには、[Safari] > [環境設定] > [詳細] > [メニューバーに開発メニューを表示] を選択）。
* Chrome: Web Developer Toolbar 拡張機能をインストールしてから、ブラウザーを再起動します。 表示される歯車のアイコンをクリックしてから、[CSS] > [全てのスタイルを無効にする] を選択します。
* Edge: メインメニューから [表示] > [スタイル] > [スタイルなし] を選択します。

#### ネイティブなキーボード・アクセシビリティを使う

特定の HTML 機能はキーボードのみを使用して選択できます — これはデフォルトの動作で、ウェブの初期の頃から使用可能です。 この機能を持つ要素は、ユーザーがウェブページと対話することを可能にする一般的なもの、すなわちリンク、`<button>`、そして `<input>` のようなフォーム要素です。

native-keyboard-accessibility.html の例を使ってこれを試すことができます（ソースコードを見る） — これを新しいタブで開いて、そして `Tab` キーを押してみてください。 数回押すと、タブフォーカスがさまざまなフォーカス可能な要素を通過し始めます。 どの要素がフォーカスされているかわかるように、フォーカスされた要素には全てのブラウザーでハイライトされたデフォルトのスタイルが与えられます（ブラウザーによって若干異なります）。

![](/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility/button-focused-unfocused.png)

次に `Enter` / `Return` を押してフォーカスのあるリンクをたどるか、ボタンを押すか（ボタンにメッセージを知らせるための JavaScript が含まれています）、テキスト入力にテキストを入力するためにタイプし始めることができます（他のフォーム要素には異なるコントロールがあります。 例えば、`<select>` 要素では、`上下の矢印`キーを使用してそのオプションを表示したり切り替えたりできます）。

ブラウザーが異なれば、使用可能なキーボードコントロールオプションも異なることに注意してください。 最近のほとんどのブラウザーは上記のタブパターンに従いますが（フォーカス可能な要素を逆方向に移動するために `Shift` + `Tab` を押すこともできます）、次のようにブラウザーによっては独自の特徴があります。

* Mac 用の Firefox はデフォルトではタブ移動を行いません。 オンにするには、 [環境設定] > [詳細] > [一般] の順に選択してから、[常にページ内を移動するにはカーソルキーを使用する] のチェックを外します。 次に、Mac のシステム環境設定アプリを開き、[キーボード] > [ショートカット] の順に選択して、[全てのコントロール] ラジオボタンを選択します。
* Safari では、デフォルトではリンクをタブ操作することはできません。 これを有効にするには、Safari の [環境設定] を開き、[詳細] に移動し、[Tab キーを押してウェブページの各項目をハイライトする] チェックボックスをオンにする必要があります。

**警告:** あなたが書く新しいページのどれでも、この種のテストを実行するべきです — 機能がキーボードによってアクセスできることを確認してください。

この例では、正しい仕事に正しい意味論的要素を使用することの重要性を強調しています。 任意の要素を、CSS でリンクやボタンのように見せたり、JavaScript でリンクやボタンのように振る舞うようにスタイルすることは可能ですが、実際にはリンクやボタンにはならず、あなたはこれらの要素が無料で与えるアクセシビリティの多くを失うでしょう。 あなたがそれを避けることができるならばしないでください。

もう 1 つのヒント — 次の例に示すように、`:focus` 疑似クラスを使用して、フォーカス可能要素のフォーカス時の外観をコントロールできます。 フォーカスとホバーのスタイルを倍増するのは良い考えです。 それにより、マウスやキーボードを使用しているかどうかに関わらず、ユーザーがコントロールをアクティブにしたときに何かが行われるという視覚的な手がかりを得ることができます。

```css
a:hover,
input:hover,
button:hover,
select:hover,
a:focus,
input:focus,
button:focus,
select:focus {
  font-weight: bold;
}
```

**メモ:** CSS を使用してデフォルトのフォーカススタイルを取り除く場合は、デザインに適した他のスタイルに置き換えてください — これは非常に有用なアクセシビリティツールであり、取り除くべきではありません。

#### キーボード・アクセシビリティを組み込む

時にはキーボード・アクセシビリティを失うことが避けられないこともあります。 意味論的にあまり良くないサイトを継承したかもしれませんし（`<div>` で作られたボタンを生成する恐ろしい CMS に行き着くかもしれません）、HTML5 の `<video>` 要素のようにキーボード・アクセシビリティが組み込まれていない複雑なコントロールを使用しているかもしれません（驚くべきことに、Opera は `<video>` 要素のデフォルトのブラウザーコントロールをタブ操作できる唯一のブラウザーです）。 次のようないくつかの選択肢があります。

1. `<button>` 要素（デフォルトでタブ移動可能）と JavaScript を使用してカスタムコントロールを作成し、それらの機能を関連付けます。 これについての良い例は、クロスブラウザーのビデオプレーヤーの作成 (en-US)を参照してください。
2. JavaScript でキーボードショートカットを作成すると、キーボードの特定のキーを押すことで機能をアクティブにできます。 あらゆる目的に適応できるゲーム関連の例については、デスクトップのマウスとキーボードのコントロール (en-US)を参照してください。
3. 偽のボタンの振る舞いのために、いくつかの興味深い戦術を使ってください。 例えば、fake-div-buttons.html の例を見てください（ソースコードを見る）。 ここでは、それぞれの属性に `tabindex="0"` という属性を与えることで（もっと有用な詳細については WebAIM の tabindex の記事（英語）を見てください）、偽の `<div>` ボタンにフォーカスできるようにしました（タブを介すことも含む）。 これにより、ボタンにタブ移動することはできますが、
 `Enter`
 /
 `Return`
 キーでそれらをアクティブにすることはできません。 そのためには、次のちょっとした JavaScript トリックを追加する必要があります。

```js
document.onkeydown = function (e) {
  if (e.keyCode === 13) {
    // The Enter/Return key
    document.activeElement.onclick(e);
  }
};
```

ここでは、`document` オブジェクトにリスナーを追加して、キーボードのボタンが押されたことを検出します。 イベントオブジェクトの `keyCode` プロパティを使ってどのボタンが押されたかをチェックし、
 `Return`
 /
 `Enter`
 と一致するキーコードであれば、`document.activeElement.onclick()` を使用してボタンの `onclick` ハンドラに格納されている関数を実行します。 `activeElement` は現在ページにフォーカスしている要素を与えます。

**メモ:** この手法は、イベントハンドラ・プロパティ（`onclick` など）を使ってオリジナルのイベントハンドラを設定した場合にのみ機能します。 `addEventListener` は機能しません。 これは、機能を再構築するための非常に面倒な作業です。 それに他にも問題があるはずです。 そもそも正しい要素を正しい仕事に使うほうがよいでしょう。

#### 代替テキスト

代替テキストは、アクセシビリティにとって非常に重要です — ある人が視覚障碍または聴覚障碍を抱えているためにコンテンツを見たり聞いたりすることができなくなると、これが問題になります。 最も単純な代替テキストは、控え目な `alt` 属性で、関連するコンテンツを含む全ての画像に含めるべきです。 これはスクリーンリーダーが拾ってユーザーに読み上げるために、ページ上にその意味と内容をうまく伝える画像の説明を含むべきです。

**メモ:** 詳しくは、代替テキストをお読みください。

欠落している代替テキストは、アクセシビリティ監査ツールを使用するなど、さまざまな方法でテストできます。

代替テキストは、動画と音声のコンテンツにとってはもう少し複雑です。 テキストトラック（字幕など）を定義し、動画の再生時にそれらを `<track>` 要素と WebVTT 形式の形式で表示する方法があります（詳細なチュートリアルについては、HTML5 の動画へのキャプションと字幕の追加を参照してください）。 これらの機能に対するブラウザーの互換性はかなり良いのですが、音声用の代替テキストを提供したり、古いブラウザーをサポートしたりする場合は、ページのどこかや別のページに提示した単純なテキストトランスクリプトをお勧めします。

#### 要素の関係とコンテキスト

HTML には、他に存在しない要素間のコンテキストと関係を提供するように設計された特定の機能とベストプラクティスがあります。 最も一般的な 3 つの例は、リンク、フォームラベル、およびデータ表です。

アクセス可能なリンクテキストの鍵は、スクリーンリーダーを使用している人々が、ページ上の全てのリンクのリストを引き出すという共通の機能を使用することが多いということです。 この場合、リンクテキストはコンテキスト外で意味を成す必要があります。 例えば、「ここをクリック」、「ここをクリック」などのラベルが付いたリンクのリストは、アクセシビリティにとって本当に悪いものです。 リンクテキストはコンテキスト内でもコンテキスト外でも意味を成すのが得策です。

次に、フォームの `<label>` 要素は、フォームをアクセス可能にすることを可能にする中心的な機能の 1 つです。 フォームの悩みは、各フォーム入力にどのデータを入力するべきかを示すためにラベルが必要なことです。 各ラベルを `<label>` 内に含めて相方のフォーム入力に明確にリンクする必要があり（各 `<label>` の `for` 属性値はフォーム要素の `id` 値と一致する必要があります）、ソース順が完全に論理的ではなくても（これは公平であるべきです）、それは意味があります。

**メモ:** リンクテキストとフォームラベルの詳細については、わかりやすいテキストラベルを参照してください。

最後に、データ表について簡単に説明します。 基本的なデータ表は非常に簡単なマークアップで書くことができますが（bad-table.html のライブとソースを見る）、問題があります — スクリーンリーダーのユーザーがデータのグループとして行や列を関連付ける方法はありません — これを行うには、ヘッダー行がどれであるか、そしてそれらが行、列などを見出ししているかどうかを知る必要があります。 これはそのような表に対しては視覚的にしかできません。

代わりに punk-bands-complete.html の例（ライブ、ソース）を見ると、表のヘッダー（`<th>` と `scope` 属性）、`<caption>` 要素など、いくつかのアクセシビリティ補助機能が働いていることがわかります。

**メモ:** アクセス可能な表の詳細については、アクセス可能なデータ表を参照してください。

### CSS

CSS は HTML よりもはるかに少ない基本的なアクセシビリティ機能を提供する傾向がありますが、それでも誤って使用された場合、それはアクセシビリティにちょうど同じくらい多くの損害を与えることができます。 CSS に関するアクセシビリティのヒントをいくつかすでに説明しました。

* HTML においてさまざまなコンテンツをマークアップするには、正しい意味論的要素を使用してください。 別の視覚効果を作成したい場合は、CSS を使用します — 必要な外観を得るために HTML 要素を悪用しないでください。 例えば、もっと大きなテキストが必要な場合は、`<h1>` 要素ではなく `font-size` を使用してください。
* ソース順が CSS なしで意味を成すことを確認してください。 常に CSS を使用することで後で好きなようにページをスタイルできます。
* ユーザーに機能に関する視覚的な手がかりを与えるため、ボタンやリンクのようなインタラクティブな要素に適切なフォーカス/ホバー/アクティブ状態が設定されていることを確認するべきです。 スタイル上の理由でデフォルトを取り除いた場合は、代替スタイルが含まれていることを確認してください。

考慮すべき点が他にもいくつかあります。

#### 色とカラーコントラスト

ウェブサイトの配色を選択するときは、テキスト（前景）のカラーコントラストが背景色とよく合うことを確認するべきです。 あなたのデザインはかっこいいかもしれませんが、色覚異常のような視覚障碍を持つ人々がコンテンツを読むことができないならば、それは良くありません。 配色に十分なコントラストがあるかどうかチェックするために WebAIM のカラーコントラストチェッカー（英語）のようなツールを使ってください。

もう 1 つのヒントは、道標や情報を色だけに頼らないようにすることです。 これは、色が見えない人には良くないでしょう。 例えば、必須のフォームフィールドを赤でマークする代わりに、赤いアスタリスクでマークします。

**メモ:** コントラスト比が高いと、光沢のある画面を備えたスマートフォンやタブレットを使用している人は誰でも、日光のような明るい環境にいるときにページを読みやすくなります。

#### コンテンツを隠す

ビジュアルデザインでは、全てのコンテンツを一度に表示する必要がない多くの実例があります。 例えば、タブ付き情報ボックスの例（ソースコードを見る）には 3 つの情報パネルがありますが、それらを重ねて配置し、それぞれを表示するためにクリックできるタブを提供しています（キーボードからもアクセス可能です — 代わりに `Tab` と `Enter` / `Return` を使って選択することもできます）。

![](/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility/20191022144107.png)

スクリーンリーダーのユーザーは、このことを気にしません — コンテンツのソース順が意味を成す限り幸せで、全てに到達できます。 絶対配置（この例で使用されているような）は一般に視覚効果のためにコンテンツを隠す最も良いメカニズムの 1 つとして見られます、なぜならそれはスクリーンリーダーがそれに到達するのを止めないからです。

一方で、スクリーンリーダーからコンテンツを隠すので、`visibility``:hidden` や `display``:none` は使用しないでください。 正当な理由があるのでなければ、なぜこのコンテンツをスクリーンリーダーから隠したいのでしょうか。

**メモ:** スクリーンリーダーのユーザーには見えないコンテンツ（英語）には、このトピックに関するもっと有用な詳細があります。

### JavaScript

JavaScript はアクセシビリティに関して CSS と同じ種類の問題を抱えています — それが悪用されたり、乱用されたりするとアクセシビリティの災害になる可能性があります。 JavaScript に関連するアクセシビリティの問題、主に意味論的 HTML の分野についてはすでに示唆しています — 例えば、リンクやボタンを適切に使用するなど、適切な意味論的 HTML を使用して機能を実装するべきです。 可能であれば、JavaScript コードで `<div>` 要素を使用して機能を偽造しないでください — エラーが発生しやすく、HTML の無料機能を使用するよりも手間がかかります。

#### 単純な機能

一般的に単純な機能は HTML だけで適切に機能するはずです — JavaScript は機能を強化するためにのみ使用されるべきであり、完全には組み込みません。 JavaScript の良い使い方には次のものが含まれます。

* クライアント側のフォーム検証を提供します。 これは、サーバーがデータをチェックするのを待たずに、フォームエントリに関する問題をユーザーにすばやく知らせるものです。 利用できない場合でもフォームは機能しますが、検証が遅くなる可能性があります。
* キーボードのみのユーザーがアクセスできる HTML5 の `<video>` のカスタムコントロールを提供します（前述したように、デフォルトのブラウザーコントロールはほとんどのブラウザーでキーボードからアクセスできません）。

**メモ:** WebAIM のアクセス可能な JavaScript（英語）は、アクセス可能な JavaScript の考慮事項に関する有用な詳細をいくつか提供します。

より複雑な JavaScript による実装はアクセシビリティに問題をもたらす可能性があります — できる限りのことをする必要があります。 例えば、WebGL を 100% を使用して書かれた複雑な 3D ゲームを視覚障碍者が利用できるようにすることは期待できませんが、マウス以外のユーザーが使用できるようにキーボードコントロール (en-US)を実装し、色覚異常のある人にも使えるように配色に十分なコントラストがあるようにすることができます。

#### 複雑な機能

アクセシビリティにとって問題となる主な分野の 1 つは、（日付の選択のような）複雑なフォームコントロールを含む複雑なアプリと、頻繁に増分的に更新される動的コンテンツです。

ネイティブではない複雑なフォームコントロールは、ネストされた `<div>` が多数含まれる傾向があり、ブラウザーがデフォルトでそれらをどう処理するかわからないため、問題があります。 自分でそれらを考案しているのなら、それらがキーボードからアクセスできることを確認する必要があります。 何らかのサードパーティ製フレームワークを使用している場合は、利用可能なオプションを慎重に検討して、飛びつく前にそれらがどれほどアクセス可能かを確認してください。 Bootstrap は、アクセシビリティにはかなり適しているように見えます。 例えば、Rhiana Heath による Bootstrap をもう少しアクセス可能にする（英語）では、その問題のいくつかを調べ（主にカラーコントラストに関連した）、いくつかの解決策を検討しています。

定期的に更新される動的コンテンツは、スクリーンリーダーのユーザーがそれを見逃す可能性があるため、特に突然更新される場合は問題になる可能性があります。 XMLHttpRequest または Fetch を使用して定期的に更新されるメインコンテンツパネルを備えた単一ページのアプリがある場合、スクリーンリーダーのユーザーはそれらの更新を見逃す可能性があります。

#### WAI-ARIA

そのような複雑な機能を使用する必要がありますか、それともごく普通の意味論的 HTML が代わりにやりますか？ 複雑なものが必要な場合は、WAI-ARIA（Accessible Rich Internet Applications）を使用することを検討するべきです。 これは、ほとんどのブラウザーやスクリーンリーダーが理解できる複雑なフォームコントロールや更新パネルのような項目に（新しい HTML 属性の形式で）意味論を提供する仕様です。

複雑なフォームウィジェットを扱うには、さまざまな要素がウィジェット内でどのような役割を担っているか（例えば、タブなのか、タブパネルなのか）を示す `role`、コントロールが無効かどうかを示す `aria-disabled` などの ARIA 属性を使う必要があります。

定期的に更新されるコンテンツのリージョンを扱うには、更新されるリージョンを識別する `aria-live` 属性を使用できます。 その値は、次のようにスクリーンリーダーがどれほど緊急にそれを読み上げるべきかを示します。

* `off`: デフォルト。 更新はアナウンスされるべきではありません。
* `polite`: 更新はユーザーがアイドル状態の場合にのみアナウンスされるべきです。
* `assertive`: 更新はできるだけ早くユーザーにアナウンスされるべきです。
* `rude`: ユーザーに割り込んだとしても、更新はすぐにアナウンスされるべきです。

これが一例です。

```html
<p><span id="LiveRegion1" aria-live="polite" aria-atomic="false"></span></p>
```

Freedom Scientific の ARIA（Accessible Rich Internet Applications）のライブリージョン（英語）の例で実行中の例を見ることができます — 強調表示された段落はその内容を 10 秒ごとに更新し、スクリーンリーダーはユーザーにこれを読み上げるべきです。ARIA のライブリージョン - Atomic（英語）は別の有用な例を提供しています。

ここでは WAI-ARIA を詳細にカバーするためのスペースはありません。 WAI-ARIA の基本でもっと詳しく学ぶことができます。

アクセシビリティツール
-----------

今まで（キーボードナビゲーションやカラーコントラストチェッカーのような）いくつかのテストのテクニックを含め、さまざまなウェブ技術に対するアクセシビリティの考慮事項について説明してきました。 次に、アクセシビリティのテストを実行するときに使用できる他のツールを見てみましょう。

### 監査ツール

あなたのウェブページを指さすことができる利用可能な監査ツールがいくつかあります。 それらはページを見て、ページに存在するアクセシビリティ問題のリストを返すでしょう。 例えば次のものが含まれます。

* Tenon: 提供された URL でコードを調べて、メトリクス、WCAG 基準が影響を及ぼす WCAG 基準に沿った特定のエラー、および修正案を含むアクセシビリティエラーに関する結果を返す、かなりいいオンラインアプリです。
* tota11y: Khan Academy のアクセシビリティツールで、JavaScript ライブラリの形式を取り、ページに添付するいくつかのアクセシビリティツールを提供します。
* Wave: ウェブアドレスを受け入れて、そのページの有用な注釈付きビューを強調表示したアクセシビリティの問題とともに返すオンラインのアクセシビリティテストツールです。

Tenon を使って例を見てみましょう。

1. Tenon のホームページ（英語）に行きます。
2. bad-semantics.html の例の URL（または分析したい別のウェブページの URL）をページ上部のテキスト入力に入力して [Analyze Your Webpage] を押します。
3. 次に示すように、error/description のセクションが見つかるまで下にスクロールします。

![](/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility/tenon-screenshot.png)

また、Tenon をプログラム的に使用するための API と同様に、探索できるいくつかのオプション（ページ上部の近くにある [Show Options] リンクを参照）もあります。

**メモ:** このようなツールは、アクセシビリティの問題を全て自分で解決するのに十分ではありません。 全体像を把握するには、これらの組み合わせ、知識と経験、ユーザーテストなどが必要です。

### 自動化ツール

Deque の aXe ツール（英語）は、前述した監査ツールよりも少しばかり進化しています。 他のものと同様に、ページをチェックしてアクセシビリティエラーを返します。 その最もすぐに役立つ形式は、おそらく次のブラウザー拡張機能です。

* Chrome 用の aXe（英語）
* Firefox 用の aXe（英語）

これらはブラウザー開発者ツールにアクセシビリティタブを追加します。 例えば、Firefox 用のバージョンをインストールし、それを使用して bad-table.html の例を監査すると、次の結果が得られます。

![](/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility/aXe-screenshot.png)

aXe は `npm` を使ってもインストール可能で、Grunt や Gulp のようなタスクランナー、Selenium や Cucumber のような自動化フレームワーク、Jasmin のような単体テストフレームワークなどと統合することができます（やはり、詳細についてはメインの aXe ページ（英語）を参照してください）。

### スクリーンリーダー

重度の視覚障碍者がウェブをどのように使用しているかに慣れるには、スクリーンリーダーを使ってテストする価値があります。 次のように利用可能なスクリーンリーダーは多数あります。

* JAWS（Windows）や Window Eyes（Windows、販売終了）のような有料製品もあります。
* NVDA（Windows）、ChromeVox（Chrome、Windows、Mac OS X）、Orca（Linux）などの無料製品もあります。
* VoiceOver（Mac OS X、iOS）、ChromeVox（Chromebook 上）、および TalkBack （Android）など、一部はオペレーティングシステムに組み込まれています。

一般的に、スクリーンリーダーはホストオペレーティングシステム上で動作する独立したアプリで、ウェブページだけでなく他のアプリのテキストも読むことができます。 これは必ずしもそうとは限りませんが（ChromeVox はブラウザーの拡張機能です）、通常はそうです。 スクリーンリーダーは少し異なる方法で動作し、異なるコントロールを持つ傾向があるので、全ての詳細を得るためにはあなたが選んだスクリーンリーダーのドキュメントを参照しなければなりません — と言っても、それらは全て基本的に同じような方法で機能します。

いくつかの異なるスクリーンリーダーを使っていくつかのテストを行い、それらがどのように機能するのか、またどのようにテストするのかについての一般的な考えを説明しましょう。

**メモ:** WebAIM のスクリーンリーダーの互換性のための設計（英語）では、スクリーンリーダーの使用方法とスクリーンリーダーに最適な機能についての役立つ情報が提供されています。 いくつかの興味深いスクリーンリーダーの使用統計については、第 6 回スクリーンリーダーのユーザー調査の結果（英語）も参照してください。

#### VoiceOver

VoiceOver（VO）は Mac / iPhone / iPad には無料で含まれているので、あなたが Apple 製品を使っているならそれはデスクトップ/モバイルでテストするのに役に立ちます。 ここでは、MacBook Pro の Mac OS X でテストします。

オンにするには、`Cmd` + `Fn` + `F5` を押します。 今までに VO を使ったことがない場合は、ようこそ画面が表示され、そこで VO を起動するかどうかを選択できます。 また、使い方を学ぶためにかなり役に立つチュートリアルを実行することもできます。 再びオフにするには、もう一度 `Cmd` + `Fn` + `F5` を押します。

**メモ:** チュートリアルは少なくとも一度は実行するべきです — これは VO を学ぶ上で非常に便利な方法です。

VO がオンになっていると、ディスプレイはほぼ同じに見えますが、画面の左下に、現在選択されている VO に関する情報を含む黒いボックスが表示されます。 現在の選択範囲も黒枠で強調表示されます — この強調表示は **VO カーソル**と呼ばれます。

![](/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility/voiceover.png)

VO を使用するには、「VO 修飾キー」を多用します — これは、実際の VO キーボードショートカットに加えて、それらを機能させるために押す必要があるキーまたはキーの組み合わせです。 このような修飾キーを使用するのは、スクリーンリーダーに共通で、他のコマンドとコマンドが衝突しないようにするためです。 VO の場合、修飾キーは `CapsLock` または `Ctrl` + `Option` のいずれかです。

VO にはたくさんのキーボードコマンドがありますので、ここではそれら全てをリストしません。 ウェブページのテストに必要な基本的なものは、次の表のとおりです。 キーボードショートカットでは、`VO` は「VoiceOver 修飾キー」を意味します。

| キーボードショートカット | 説明 |
| --- | --- |
| `VO` + `矢印キー` | VO カーソルを上下左右に移動します。 |
| `VO` + `スペースバー` | VO カーソルで強調表示されている項目を選択/アクティブ化します。 これには、ローター（下記参照）で選択した項目が含まれます。 |
| `VO` + `Shift` + `下矢印` | （HTML の表やフォームなどの）項目のグループ内に入ります。 グループ内に入ると、通常どおり上記のコマンドを使用してそのグループ内の項目を移動して選択できます。 |
| `VO` + `Shift` + `上矢印` | グループから出ます。 |
| `VO` + `C` | （表内の場合）現在の列のヘッダーを読み上げます。 |
| `VO` + `R` | （表内の場合）現在の行のヘッダーを読み上げます。 |
| `VO` + `C` + `C`（2 つの連続した C） | （表内の場合）ヘッダーを含む現在の列全体を読み上げます。 |
| `VO` + `R` + `R`（2 つの連続した R） | （表内の場合）各セルに対応するヘッダーを含め、現在の行全体を読み上げます。 |
| `VO` + `左矢印`、`VO` + `右矢印` | （日付の選択や時刻の選択などの一部の水平オプション内の場合）オプション間を移動します。 |
| `VO` + `上矢印`、`VO` + `下矢印` | （日付の選択や時刻の選択などの一部の水平オプション内の場合）現在のオプションを変更します。 |
| `VO` + `U` | 簡単にナビゲーションできるように、見出し、リンク、フォームコントロールなどのリストを表示するローターを使用します。 |
| `VO` + `左矢印`、`VO` + `右矢印` | （ローター内の場合）ローターで利用可能な異なるリスト間を移動します。 |
| `VO` + `上矢印`、`VO` + `下矢印` | （ローター内の場合）現在のローターリスト内の異なる項目間を移動します。 |
| `Esc` | （ローター内の場合）ローターを終了します。 |
| `Ctrl` | （VO が話している場合）読み上げを一時停止/再開します。 |
| `VO` + `Z` | 読み上げの最後の部分をやり直します。 |
| `VO` + `D` | Mac の Dock に入るので、その中で実行するアプリを選択できます。 |

これはたくさんのコマンドのように思えますが、慣れればそれほど悪くはありません。 VO は、特定の場所でどのコマンドを使用するかについて定期的に注意を促します。 今は VO で遊びましょう。 その後、スクリーンリーダーのテストのセクションで例のいくつかを試してみることができます。

#### NVDA

NVDA は Windows 専用で、インストールする必要があります。

1. nvaccess.org からダウンロードしてください。 寄付をするか無料でダウンロードするかを選択できます。 ダウンロードできるようになる前にあなたのメールアドレスを与える必要もあるでしょう。
2. ダウンロードしたら、インストールします — インストーラをダブルクリックし、ライセンスに同意して指示に従います。
3. NVDA を起動するには、プログラムファイル/ショートカットをダブルクリックするか、キーボードショートカットの
 `Ctrl`
 +
 `Alt`
 +
 `N`
 を使用します。 起動すると NVDA にようこそダイアログが表示されます。 ここでは、いくつかのオプションから選択し、次に [OK] ボタンを押して作業を進めます。

これで NVDA はあなたのコンピュータ上でアクティブになります。

NVDA を使用するには、「NVDA 修飾キー」を多用します — これは、実際の NVDA のキーボードショートカットに加えて、それらを機能させるために押す必要があるキーです。 このような修飾キーを使用するのは、スクリーンリーダーに共通で、他のコマンドとコマンドが衝突しないようにするためです。 NVDA の場合、修飾キーは `Insert`（デフォルト）、または `CapsLock`（[OK] を押す前に NVDA へようこそダイアログボックスの最初のチェックボックスをオンにして選択できます）のいずれかになります。

**メモ:** NVDA は、VoiceOver よりも、それがどこにあるのか、また何をしているのかを強調する方法という点では微妙です。 あなたが見出しやリストなどをスクロールしているとき、あなたが選択している項目は一般的に微妙なアウトラインでハイライトされますが、これはいつも全てのことに当てはまるわけではありません。 完全に迷子になった場合は、`Ctrl` + `F5` を押して現在のページを更新し、もう一度上から始めることができます。

NVDA にはたくさんのキーボードコマンドがありますので、ここではそれら全てをリストしません。 ウェブページのテストに必要な基本的なものは、次の表のとおりです。 キーボードショートカットでは、`NVDA` は「NVDA 修飾キー」を意味します。

| キーボードショートカット | 説明 |
| --- | --- |
| `NVDA` + `Q` | 起動している NVDA を再びオフにします。 |
| `NVDA` + `上矢印` | 現在行を読み上げます。 |
| `NVDA` + `下矢印` | 現在位置から読み上げを始めます。 |
| `上矢印` と `下矢印`、または `Shift` + `Tab` と `Tab` | ページ内の前/次の項目に移動して、それを読み上げます。 |
| `左矢印` と `右矢印` | 現在の項目の前/次の文字に移動して、それを読み上げます。 |
| `Shift` + `H` と `H` | 前/次の見出しに移動して、それを読み上げます。 |
| `Shift` + `K` と `K` | 前/次のリンクに移動して、それを読み上げます。 |
| `Shift` + `D` と `D` | 前/次の文書のランドマーク（`<nav>` など）に移動して、それを読み上げます。 |
| `Shift` + `1` 〜 `6` と `1` 〜 `6` | 前/次の見出し（レベル 1 〜 6）に移動して読み上げます。 |
| `Shift` + `F` と `F` | 前/次のフォーム入力に移動して、それにフォーカスを当てます。 |
| `Shift` + `T` と `T` | 前/次のデータ表に移動して、それにフォーカスを当てます。 |
| `Shift` + `B` と `B` | 前/次のボタンに移動して、ラベルを読み上げます。 |
| `Shift` + `L` と `L` | 前/次のリストに移動して、その最初のリスト項目を読み上げます。 |
| `Shift` + `I` と `I` | 前/次のリスト項目に移動して、それを読み上げます。 |
| `Enter` / `Return` | （リンク/ボタンまたは他のアクティブ化可能項目が選択されている場合）項目をアクティブ化します。 |
| `NVDA` + `スペースバー` | （フォームが選択されている場合）個々の項目を選択できるようにフォーム内に入るか、すでにフォームに入っている場合はフォームから出ます。 |
| `Shift` + `Tab` と `Tab` | （フォーム内の場合）フォーム入力間を移動します。 |
| `上矢印` と `下矢印` | （フォーム内の場合）フォーム入力の値を変更します（選択ボックスなどの場合）。 |
| `スペースバー` | （フォーム内の場合）選択値を選択します。 |
| `Ctrl` + `Alt` + `矢印キー` | （表が選択されている場合）表のセル間を移動します。 |

#### スクリーンリーダーのテスト

スクリーンリーダーを使用することに慣れてきましたが、スクリーンリーダーがどのようにウェブページの良い機能と悪い機能に対処するかを理解するために、簡単なアクセシビリティテストを行うためにスクリーンリーダーを使用したいと思います。

* good-semantics.html を見て、見出しがスクリーンリーダーによってどのように見つけられ、ナビゲーションに使用できるかに注目してください。 では、bad-semantics.html を見て、スクリーンリーダーがどのようにしてこの情報を取得できないのかに注目してください。 本当に長いページのテキストをナビゲートしようとすると、これがどれほど面倒なことになるか想像してください。
* good-links.html を見て、コンテキストから見たときにそれらがどのように意味をなすかに注目してください。 bad-links.html ではそうではありません — それらは全てただの「ここをクリック」です。
* good-form.html を見て、`<label>` 要素を適切に使用することで、フォーム入力がラベルでどのように説明されるかに注目してください。 bad-form.html では、それらは「空白」の行に沿って役に立たないラベルを取得します。
* punk-bands-complete.html の例を見て、ヘッダーを正しく定義したので、スクリーンリーダーがどのようにしてコンテンツの列と行を関連付け、それらを全て読み取ることができるかを確認します。 bad-table.html では、どのセルも関連付けることができません。 1 つのページに 1 つの表しかない場合、NVDA はやや奇妙なふるまいをするようです。 代わりに WebAIM の表のテストのページ（英語）を試すことができます。
* 先ほど見た WAI-ARIA のライブリージョンの例（英語）を見て、スクリーンリーダーが絶えず更新されているセクションが更新されるたびにそれを読み上げていくかに注目してください。
### ユーザーテスト

上記のように、あなたはあなたのサイトのアクセシビリティ問題を決定するために自動化されたツールだけに頼ることはできません。 テスト計画を立てる際には、可能であればアクセシビリティユーザーグループをいくつか含めることをお勧めします（詳細については、コースの前半のユーザーテストのセクションを参照してください）。 必要に応じて、スクリーンリーダーを使用するユーザー、キーボードを使用するユーザー、聴覚を持たないユーザー、および他のグループも参加してください。

アクセシビリティテストのチェックリスト
-------------------

次のリストは、プロジェクトで推奨されるアクセシビリティテストを確実に実行したことを確認するためのチェックリストです。

1. HTML が意味論的にできるだけ正しいことを確認してください。 監査ツールを使用して、それを検証することは良いスタートです。
2. CSS がオフになっているときにコンテンツが意味をなすことを確認してください。
3. 機能がキーボードからアクセス可能であることを確認してください。
 `Tab`
 、
 `Return`
 /
 `Enter`
 などを使ってテストします。
4. テキスト以外のコンテンツに代替テキストがあることを確認してください。 監査ツールはそのような問題を捉えるのに適しています。
5. 適切なチェックツールを使用して、サイトのカラーコントラストが許容範囲内であることを確認してください。
6. 隠されたコンテンツがスクリーンリーダーに見えるようにしてください。
7. 可能な限り JavaScript がなくても機能が使えることを確認してください。
8. 適切な場合は、ARIA を使用してアクセシビリティを向上させます。
9. 監査ツールを通してサイトを運営してください。
10. スクリーンリーダーでテストしてください。
11. あなたが行ったことを言うために、あなたのサイトのどこかに見つけることができるアクセシビリティの方針/声明を含めてください。
助けを探す
-----

あなたがアクセシビリティに関して遭遇するであろう他の多くの問題があります。 本当に知っておくべき最も重要なことは、オンラインで答えを見つける方法です。 HTML と CSS の記事の助けを探すのセクションを参考にしてください。

まとめ
---

たぶん、この記事はあなたが遭遇するかもしれない主なアクセシビリティ問題とそれらをどうやってテストして克服するかについての良い下地を与えたでしょう。

次の記事では、機能の検出について詳しく説明します。

* 前のページ
* Overview: Cross browser testing
* 次のページ


完全なツールチェーンの導入 - ウェブ開発を学ぶ

完全なツールチェーンの導入
=============

* 前のページ
* Overview: Understanding client-side tools
* 次のページ

シリーズの最後の 2 つの記事ではケーススタディのツールチェインサンプルを構築するプロセスを通して、ツールに関する知識を理解していきます。理にかなった開発環境のセットアップと変換ツールの配置から、実際にNetlifyにアプリをデプロイするまでの全過程を説明します。この記事では、ケーススタディの紹介、開発環境のセットアップ、コード変換ツールのセットアップを行います。

|  |  |
| --- | --- |
| 前提条件： | 主要な HTML、CSS、と JavaScript 言語 |
| 目的： | ツールチェーンのケーススタディの演習を完了して、これまでに学んだことを確実に理解します。 |

ツールとその使用方法の組み合わせは実際に無限にあります。この記事と次の記事で説明したことは、プロジェクトで注目のツールを使用できる *1つの* 方法にすぎません。

**メモ:** これらのツールのすべてをコマンドラインで実行する必要があるわけではないことも繰り返し述べておきます。 現在のコードエディター (VS Code や Atom など) の *多く* は、プラグインを介して多数のツールの統合をサポートしています。

ツールチェーンのケーススタディの事例紹介
--------------------

この記事で作成しているツールチェーンは、地球上の私たちの存在を脅かす潜在的に危険な宇宙物体に関するデータ (NASA's open APIs の 1 つから取得) をリストするミニサイトを構築して展開するために使用されます。次のようになります。

![screenshot of the sample will it miss website](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Introducing_complete_toolchain/will-it-miss-screenshot.png)

このサイトのライブバージョンは、near-misses.netlify.com でご覧いただけます。

ツールチェーンで使用されるツール
----------------

この記事では、次のツールと機能を使用します。

* JSXは React に関連する構文拡張のセットで、 JavaScript 内でコンポーネント構造を定義するなどの作業を可能にします。このチュートリアルに行うのに React を理解する必要はありませんが、非ネイティブウェブ言語をツールチェーンに統合する方法を理解するためにこれを含めました。
* `import` などの最新の組み込み JavaScript 機能（執筆時点）です。
* フォーマット用の Prettier や lint 用の ESLint などの便利な開発ツール。
* PostCSS は、 CSS のネスティング機能を提供します。
* Parcel コードをビルドして縮小し、多数の構成ファイルのコンテンツを自動的に書き込みます。
* GitHub を使ってソースコードを管理しています。
* Netlify を使ってデプロイプロセスを自動化します。

上記の機能やツールが何をするものなのか、よく知らないかもしれないがパニックにならないでください。この記事を進めながら各部分について説明します。

ツールチェーンとその固有の複雑さ
----------------

他のチェーンと同様にツールチェーン内のリンクが増えるほどツールチェーンはより複雑になり脆弱になる可能性があります。たとえば構成がより複雑になり、壊れやすくなる可能性があります。 逆にリンクが少ないほど、ツールチェーンは壊れにくくなる可能性があります。

すべてのウェブプロジェクトは異なるためツールチェーンのどの部分が必要かを検討し、それぞれの部分を慎重に検討する必要があります。

最小のツールチェーンは、リンクがまったくないツールチェーンです。 HTML を手動でコーディングし、「 vanilla JavaScript 」(フレームワークや中間言語を使用しないことを意味します) を使用し、それをすべて手動でサーバーにアップロードしてホスティングします。

しかし、より複雑なソフトウェア要件の場合は開発プロセスを簡素化するツールを使用することで恩恵を得られる可能性があります。 さらに、本番サーバーにデプロイする前にソフトウェアが意図したとおりに動作することを確認するテストを含める必要があります。これはすでに必要なツールチェーンのように思えます。

サンプルプロジェクトではソフトウェア開発を支援し、ソフトウェア設計段階での技術的選択をサポートするために特別に設計されたツールチェーンを使用します。 ただし、複雑さを最小限に抑えることを目的としてて余計なツールは使わないようにします。

例えば、ビルド中に SVG ファイルサイズを最小化するツールを組み込むこともできたかもしれません。 しかし、このプロジェクトには SVG 画像が 4 つしかなくプロジェクトに追加する前に SVGO を使用して手動で縮小 しました。

いくつかの前提条件
---------

ツールチェーンに貢献するこれからインストールするツールの他に、上記のツールのリストで 2 つのウェブサービスを紹介しました。先に進む前にこの機会を利用して、セットアップが完了していることを確認しましょう。 チュートリアルを完了するには、GitHub と Netlify のアカウントを作成する必要があります。

* 前述したように、GitHub はソースコードリポジトリーサービスであり、課題の追跡やプロジェクトのリリースのフォローなどのコミュニティ機能を追加しています。次の章では、 GitHub のコードリポジトリーにプッシュして、すべてのソフトウェアをウェブ上のホームにデプロイする（はずの）カスケード効果を引き起こします。
* Netlify は、静的ウェブサイト (つまり、リアルタイムでは変更されないファイルで完全に構成されているウェブサイト) 用のホスティングサービスです。これにより、1 日に何度もデプロイすることができ、あらゆる種類の静的サイトを自由にホストできます。 Netlify は前述の「ウェブ上のホーム」、つまりテスト アプリをデプロイするための無料のホスティングを提供するものです。

GitHub にサインアップすると（まだアカウントをお持ちでない場合はホームページの *Sign Up* リンクをクリックし、指示に従ってください）、 Netlify での認証に GitHub アカウントを使用できるようになる(*Sign Up* をクリックし、[次のいずれかでサインアップ] リストから *GitHub* を選択してください)ので技術的には新しいアカウントを1つ作るだけで済みます。

後で、このプロジェクトをデプロイするために Netlify アカウントを GitHub リポジトリーに接続する必要があります。 その方法については次の章で説明します。

3 段階のツール
--------

クライアントサイドツールの概要で説明したようにツールチェーンは次のフェーズで構成されます。

* **セーフティネット**: ソフトウェア開発体験を安定させ、より効率的にします。 これを開発環境と呼ぶこともあります。
* **トランスフォーメーション**: 開発プロセスにおいて、ある言語 (JavaScript など) または別の言語全体 (JSX や TypeScript など) の最新機能を使用できるようにし、製品版がモダンなものから古いものまで様々なブラウザーで動作するようにコードを変換します。
* **ポスト開発**: 開発本体が終了後に、ソフトウェアがウェブに公開され、実行され続けることを保証するために使用するツールです。このケーススタディではコードにテストを追加し Netlify を使用してアプリをデプロイし、ウェブ上で利用できるようにします。

開発環境から始めて、これらに取り組みましょう。

開発環境の構築
-------

ツールチェーンのこの部分が実際の作業を遅らせているように見えることがあります。環境を「適切な」状態にするために多くの時間を費やすという、ツールの「ウサギの穴」にはまりやすい可能性があります。

しかし、これは物理的な作業環境を整えるのと同じように考えることができます。 椅子は快適であり、姿勢を助けるために適切な位置に設置されている必要があります。 電源、 Wi-Fi 、 USB ポートが必要です。あなたの精神状態を助ける重要な装飾や音楽があるかもしれません。これらはすべて可能な限り最高の仕事をするために重要であり適切に行われれば、セットアップは 1 回だけで済みます。

同様に開発環境のセットアップはうまくいけば一度だけ行えばよく、将来の多くのプロジェクトで再利用できるはずです。 おそらくツールチェーンのこの部分を半定期的に確認し、導入すべきアップグレードや変更があるかどうかを検討することをお勧めしますが、これはあまり頻繁に行う必要はありません。

ツールチェーンはユーザー自身のニーズによって異なりますがこの (可能な) 完全なツールチェーンの例では、事前にインストールされるツールは次のとおりです。

* ライブラリーインストールツール — 依存関係を追加するためのツール
* コードリビジョン管理
* コード整理ツール — JavaScript、CSS、HTML の整理
* コード lint ツール — コードを lint するためのツール
### ライブラリーインストールツール

第 2 章で初めて説明した npm を使用してツールをインストールします。Node.js と npm がすでにインストールされている必要がありますが、インストールされていない場合は、そのセクションを参照してください。

**メモ:** インストールプロセスから分かりませんが、 npm をインストールすると、 npx と呼ばれる補完ツールもインストールされます。 この章の後半では、プロジェクトのローカル依存関係としてインストールされているツールの実行に役立つ npx を使用します。

npm は、ツールチェーンの後続の部分をインストールするために使用されます。 ただし、まず最初に、リビジョン管理を支援するために git をインストールします。

### コードリビジョン管理

「 git 」について聞いたことがあるかもしれません。 Git は現在、開発者が利用できる最も人気のあるソースコードのリビジョン管理ツールです。リビジョン管理には作業内容を遠隔地にバックアップする方法や互いのコードを上書きすることを恐れずに同じプロジェクトでチームで作業するメカニズムなど、多くの利点があります。

当たり前のことかもしれないが、繰り返す伝える必要があります。Git は GitHub と同じではありません。 Git はリビジョン管理ツールですが、 GitHub は git リポジトリー (およびそれらを操作するための便利なツール)のオンラインストアです。この章では GitHub を使用していますが、 GitLab や Bitbucket などの代替手段がいくつかあり、独自の Git リポジトリーをホストすることもできます。

プロジェクトでリビジョン管理を使用し、ツールチェーンの一部として組み込むことはコードの進化を管理するのに役立ちます。 これは「 X 個の新機能が実装されました」または「 Y 個の変更によりバグ Z が修正されました」などのコメントとともに、作業の進行に合わせて作業ブロックを「コミット」する方法を提供します。

リビジョン管理を使用すると変更が元のコードに影響を与えることなく、プロジェクトコードを「分岐」して別のバージョンを作成し、新しい機能を試すこともできます。

最後にどこかに間違いが生じて修正が困難な場合に、変更を元に戻したり、コードを「動作していたとき」の状態に戻したりするのに役立ちます。これはすべての開発者が時々行う必要があります。

Git は git-scm をウェブサイトからダウンロードしてインストールすることができます。あなたのシステムに合ったインストーラーをダウンロードして実行し、画面の指示に従ってください。今のところ、必要なことはこれだけです。

コマンドラインを使ってコマンドを発行したり、git GUIアプリ を使ってボタンを押すことで同じコマンドを発行したり、あるいは以下の Visual Studio Code の例にあるように、コードエディターの中から直接操作したりと、さまざまな方法でgitと対話することができます。

![GitHub integration shown in VS Code](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Introducing_complete_toolchain/vscode-git.png)

とにかく、今のところやるべきことは git をインストールすることだけです。次へ移りましょう。

### コード整理ツール

このプロジェクトでは、第 2 章で最初に説明した Prettier を使用してコードを整形します。 Prettier のインストールセクションの指示に従っている場合は、すでに Prettier がインストールされている可能性があります。そうでない場合は、今すぐターミナルを使用して Prettier をグローバルユーティリティとしてインストールするように指示します。

次のコマンドを使用して、すでにグローバルにインストールされているかどうかを確認できます。

```bash
prettier -v
```

インストールされている場合は、 2.0.2 のようなバージョン番号が返されます。そうでない場合は、「 command not found 」のような内容が返されます。この場合は、次のコマンドを使用してインストールします。

```bash
npm install prettier -g
```

Prettier がインストールされたので、コンピューター上のどこからでもコマンドラインで個々のファイルごとにコードの実行と整形を行うことができます。次に例を示します。

```bash
prettier --write ./src/index.html
```

**メモ:** 上記のコマンドでは、 `--write` フラグを指定して Prettier を使用しています。 Prettier は、これが「コードフォーマットに問題があれば、それを修正してからファイルを保存してください」という意味であると理解しています。これは開発プロセスには問題ありませんがフラグなしで `prettier` を使用することもでき、ファイルのチェックのみが行われます。ファイルをチェックする(保存しない)ことはリリース前に実行されるチェック、つまり「適切にフォーマットされていないコードをリリースしない」などの目的に役立ちます。

各ファイルに対して最初のコマンドを実行するのは大変なので、これを実行する単一のコマンドがあれば便利です ( lint ツールにも同じことが言えます)。

この問題を解決するには多くの方法があります。ここにほんの一部を示します。

* npm スクリプトを使用して、コマンドラインから複数のコマンドを一度に実行します( `npm run tidy-code` など)。
* 特別な「 git hooks 」を使用して、コミット前にコードがフォーマットされているかどうかをテストします。
* コードエディタープラグインを使用して、ファイルが保存されるたびに Prettier コマンドを実行します。

**メモ:** git hooks とは何ですか? Git (GitHub ではありません) は、git で実行するタスク(コードのコミットなど)にプレアクションとポストアクションを付加できるシステムを提供します。 git hooks は(この著者の意見では)少し複雑すぎるかもしれませんが、一度導入すると非常に強力になります。 hooks の使用に興味がある場合は、 Husky を参照すると、 hooks を使用するためのルートが大幅に簡素化されます。

VS Code の場合、便利な拡張機能の 1 つは Prettier Code Formatter by Esben Petersen です。これを使うと、VSCode は保存時にコードを自動的に整形してくれます。これは、HTML、CSS、JavaScript、JSON、マークダウンなど、作業中のプロジェクト内のすべてのファイルが適切にフォーマットされることを意味します。エディターに必要なのは、「 Format On Save 」を有効にすることだけです。

最近作られた多くのツールと同様に、Prettier には「使いやすいデフォルト」が用意されてます。つまり、何も設定せずに Prettier を使用できるようになります。 (デフォルトに満足している場合)。これにより、重要な創造的な作業に取り組むことができます。

### コード lint ツール

lint はコードの品質を向上させるのに役立ちますが、開発中の早い段階で潜在的なエラーを発見する方法でもあります。これは優れたツールチェーンの重要な要素であり、多くの開発プロジェクトにデフォルトで組み込まれることになります。

ウェブ開発用の lint ツールは、主に JavaScript 用に存在します(ただし、HTML と CSS 用に利用できるツールもいくつかあります)。これは当然のことです。不明な HTML 要素または無効な CSS プロパティが使用された場合、これら 2 つの言語の回復力の性質により、何も壊れる可能性はありません。 JavaScript ははるかに脆弱です。たとえば存在しない関数を誤って呼び出すと、JavaScript が壊れてしまいます。したがって JavaScript の lint は、特に大規模なプロジェクトの場合には非常に重要です。

JavaScriptの lint に最適なツールは ESLint です。 ESLint は非常に強力で多機能なツールですが、正しく設定するのは難しいので、設定を正しくするのに何時間も費やしてしまう可能性があります。

ESLint を実行すると、そのままでは設定ファイルが見つからないというメッセージが表示されます。構成ファイルは複数の形式をサポートしていますが、このプロジェクトでは `.eslintrc.json` を使用します(先頭のピリオドはデフォルトで隠しファイルであることを意味します)。

ESLint は npm 経由でインストールされるため、第 2 章の説明に従って、このツールをローカルにインストールするかグローバルにインストールするかを選択できます。 両方を使用することをお勧めします。

* 共有するプロジェクトでは、独自のコピーを作成する誰もがプロジェクトに適用したルールに従うことができるように、常に ESLint をローカル依存関係として含める必要があります。
* ESLint をグローバルにインストールして、必要なファイルをすぐにチェックできるようにすることも検討してください。

わかりやすくするために、この章では ESLint のすべての機能については説明しませんが、特定のプロジェクトとその要件に適した構成を導入します。ただし、コードの外観(または検証)に関するルールを調整して強制したい場合は、適切な ESLint 構成を使用することで実現できる可能性が高いことに留意してください。

この章の少し後で、ESLint 構成を提供します。動作する構成が設定されたら、コマンドを実行すると有用な情報が得られます。 ESLint の出力例を次に示します。

```bash
./my-project/src/index.js
   2:8 error 'React' is defined but never used  no-unused-vars
 22:20 error 'body' is defined but never used   no-unused-vars
 96:19 error 'b' is defined but never used      no-unused-vars

✖ 3 problems (3 errors, 0 warnings)
```

**メモ:** 次のセクションでESLintをインストールしますが、今は気にしないでください。

他のツールと同様にコードエディターとの統合サポートは通常 ESLint に適しており、問題が発生したときにリアルタイムのフィードバックを提供できるため、より便利になる可能性があります。

![ESLint error integration shown in VS Code](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Introducing_complete_toolchain/eslint-error.png)

初期プロジェクトの設定
-----------

これらのツールを使用すると多くの「基本的な」問題が早い段階で発見されることがわかっているので、新しいプロジェクトを安全にセットアップできます。

コマンドラインを使用して、プロジェクトを作成し、初期ツールをインストールし、基本的な構成ファイルを作成できます。繰り返しになりますが、このプロセスを数回繰り返すと、デフォルトの設定がどのようなものであるかがわかるようになります。もちろん、これは可能な構成の 1 つにすぎません。

### 初期設定

OK、プロジェクトの初期設定を済ませましょう。

1. まずターミナルを開いて、見つけやすい場所に移動します。デスクトップ、あるいはホームフォルダーやドキュメントフォルダーでしょうか?
2. 次に以下のコマンドを実行してプロジェクトを保存するフォルダーを作成し、そのフォルダー内に移動します。

```bash
mkdir will-it-miss
cd will-it-miss
```

3. 次にウェブサイトのすべての開発コードが存在する新しいディレクトリーを作成します。今すぐ次のコマンドを実行します。

```bash
mkdir src
```

コードの構成は、チームごとにかなり主観的なものになる傾向があります。このプロジェクトの場合、ソースコードは `src` 内に存在します。
4. `will-it-miss` ディレクトリーのルート内にいることを確認し、次のコマンドを入力して、ディレクトリー上で動作する git のソース管理機能を開始します。

```bash
git init
```

これはフォルダーの内容のリビジョンを保存したり、リモートリポジトリーへの保存などを開始できることを意味します。これについては後ほど詳しく説明します！
5. 次に以下のコマンドを入力して、ディレクトリーを npm パッケージに変換します。これには、前の記事で説明した利点があります。

```bash
npm init --force
```

これにより、デフォルトの `package.json` ファイルが作成され、必要に応じて後で構成できます。 `--force` フラグを指定すると、コマンドは(前に見たように)どのようなコンテンツを含めるかについての通常の質問を一切せずに、デフォルトの `package.json` ファイルを即座に作成します。現時点ではデフォルトのみが必要なので、これにより時間を少し節約できます。

#### プロジェクトコードファイルの取得

この時点で、プロジェクトのコードファイル( HTML、 CSS、 JavaScript など) を取得し、 `src` ディレクトリーに置きます。この章の目的ではないので、これらのファイルがどのように機能するかについては説明しません。 この章では、ツールがどのように動作するのかを教えるために、単にツールを動作させるためのものです。

1. コードファイルを入手するには、https://github.com/remy/mdn-will-it-miss にアクセスし、このリポジトリーの内容をローカルドライブのどこかにダウンロードして解凍します。 *Clone or download* > *Download ZIP* を選択すると、プロジェクト全体を zip ファイルとしてダウンロードできます。

 ![The GitHub will it miss repo](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Introducing_complete_toolchain/github-will-it-miss.png)
2. プロジェクトの `src` ディレクトリーの内容を、現在空の `src` ディレクトリーにコピーします。

これでプロジェクトのファイルが揃いました。これでとりあえずは完了です！

**メモ:** ローカルマシンでプロジェクトをセットアップするには、解凍したフォルダーのルートディレクトリーに移動し、その場所でターミナルを開き、ターミナルで `npm install` コマンドを実行する。これにより、 `package.json` ファイルに記載されているプロジェクトの依存関係がすべてインストールされます。

#### ツールのインストール

それでは、開発環境で使用するツールの初期セットをインストールしましょう。プロジェクトのルートディレクトリー内から次のコマンドを実行します。

```bash
npm install --save-dev eslint prettier babel-eslint
```

先ほど実行したコマンドについて、注意すべき重要な点が 2 つあります。1 つ目は、依存関係をプロジェクトにローカルにインストールしていることです。特定のプロジェクトに対してローカルにツールをインストールする方が良いです。ローカルにインストールすること（`--global` オプションを含まない場合）で、他のマシンでも簡単に同じ環境を再現することができます。

このインストールコマンドの2つ目の重要な部分は、 `--save-dev` オプションです。これによって、 npm ツールに対して特定の依存関係が開発にのみ必要であることを伝えます（したがって、 npm はこれらの依存関係を `dependencies` ではなく `devDependencies` として `package.json` ファイルにリストします）。これはつまり、このプロジェクトが本番モードでインストールされる場合、これらの依存関係はインストールされないということです。一般的なプロジェクトでは、本番で実際にコードを実行するためには不要な開発用の依存関係が多数含まれることがあります。それらを別々の依存関係として保持することで、本番環境へのデプロイ時の不必要な作業を減らすことができます（次の章で見ていく内容です）。

実際のアプリケーションコードの開発を始める前に、ツールが適切に動作するように少し設定が必要です。これはウェブ開発の前提条件ではありませんが、開発中にエラーをキャッチするのに役立つため、ツールが正しく設定されていると便利です。特に ESLint はその点で特に役立ちます。

### ツールの設定

プロジェクトのルートディレクトリー（ `src` ディレクトリーではなく）に、いくつかのツールを設定するための設定ファイルを追加します。具体的には、 Prettier と ESLint の設定です。これは一般的なツールの設定方法であり、通常設定ファイルはプロジェクトのルートに配置されます。これらの設定ファイルには、 JSON 形式で表現された設定オプションが含まれています（ただし、私たちのツールやその他の多くのツールは YAML もサポートしており、もしそちらを好みの設定ファイル形式とする場合は切り替えることもできます）。

1. まず、 `will-it-miss` ディレクトリーのルートに `.prettierrc.json` という名前のファイルを作成します。
2. Prettier を設定するために、 `.prettierrc.json` に以下の内容を記述します：

```json
{
  "singleQuote": true,
  "trailingComma": "es5"
}
```

これらの設定を使用すると、Prettier が JavaScript をフォーマットする際には、すべての引用された値にシングルクォートを使用し、末尾のカンマは使用しません（ ECMAScript の新しい機能で、古いブラウザーでエラーが発生する可能性があるものです）。 Prettier の設定についての詳細は、公式ドキュメントを参照してください。
3. 次に、ESLintの設定を行います。 `will-it-miss` ディレクトリーのルートに `.eslintrc.json` という別のファイルを作成し、以下の内容を記述します。

```json
{
  "env": {
    "es6": true,
    "browser": true
  },
  "extends": "eslint:recommended",
  "parserOptions": {
    "ecmaVersion": 6,
    "sourceType": "module"
  },
  "rules": {
    "no-console": 0
  }
}
```

上記の ESLint の設定では、"recommended" ESLint 設定を使用し、ES6の機能（例： `map()` や `Set()` など）の使用を許可し、モジュールの `import` 文を使用できるようにし、 `console.log()` の使用も許可しています。
4. ただし、このプロジェクトのソースファイルでは、React JSX 構文を使用しています（実際のプロジェクトでは React や Vue などのフレームワーク、またはフレームワークを使用しない場合もあります！）。
 JSX 構文をJavaScriptの中に挿入すると、 ESLint は現在の設定ではすぐに警告を出すことになります。そのため、 ESLint の設定に少し追加の設定を行い、JSXの機能を受け入れるようにします。
 最終的な設定ファイルは以下のようになります。太字の部分を追加して保存してください：

```json
{
  "env": {
    "es6": true,
    "browser": true
  },
  "extends": ["eslint:recommended", "plugin:react/recommended"],
  "parserOptions": {
    "ecmaVersion": 6,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    }
  },
  "plugins": ["react"],
  "rules": {
    "semi": "error",
    "no-console": 0,
    "react/jsx-uses-vars": "error"
  }
}
```

設定が現在「 React 」という名前のプラグインを使用しているため、この開発用の依存関係もインストールする必要があります。これにより、実際に lint プロセスのこの部分を実行するためのコードが存在します。
5. プロジェクトフォルダーのルートで、以下のターミナルコマンドを実行してください。

```bash
npm install --save-dev eslint-plugin-react
```

ESLintのルールは、 ESLint rules のリスト があり、心のままに調整して設定することができます。多くの企業やチームが独自の ESLint 設定を公開しており、これらはしばしばインスピレーションを得るのに役立つこともありますし、自分の基準に合ったものを選択する際にも便利です。ただし、注意が必要です： ESLint の設定は非常に奥深いものです！

ここまでで、開発環境のセットアップが完了しました。これで、ついに（ほぼ）コーディングの準備が整いました。

ビルドおよび変換ツール
-----------

このプロジェクトでは前述した通り、 React を使用し、そのためにソースコードではJSXを使用します。また、プロジェクトでは最新の JavaScript 機能も利用します。

直近の課題として、ブラウザーは JSX をネイティブにサポートしていません。 JSX は中間言語であり、本番コードではブラウザーが理解できる言語にコンパイルする必要があります。

ブラウザーがソース JavaScript を実行しようとすると、すぐにエラーが発生します。このプロジェクトでは、ブラウザーが問題なく読み込めるようにソースコードを変換するためのビルドツールが必要です。

変換ツールはいくつか選択肢がありますが、特に人気のある WebPack の代わりに、このプロジェクトでは Parcel を使用することにします。 Parcel は設定が少なくて済むため、特にこの選択になりました。

Parcel は開発要件を自動的に設定しようとする仕組みで動作します。 Parcel はコードを監視し、開発中にライブリロードするウェブサーバーを実行します。これはまた、 Parcel がソースコード内で参照されると自動的にソフトウェアの依存関係をインストールすることも意味します（第 3 章で見た内容です）。

Parcel は、必要な変換ツールと設定を、私たちが介入することなく自動的に処理します（ほとんどの場合）。

そして最後の特典として、Parcel はコードをバンドルして本番デプロイの準備をし、最小化やブラウザーの互換性要件も対応します。

したがって、このプロジェクトには Parcel の依存関係もインストールする必要があります。ターミナルで以下のコマンドを実行してください。

```bash
npm install --save-dev parcel-bundler
```

### 将来使用出来る機能

このプロジェクトのコードは、完全に標準化されていない新しいウェブ機能を含むいくつかの新しいウェブ機能を使用しています。例えば、 Sass のようなツールに頼る代わりに、この特定のプロジェクトでは W3C の CSS ネスティングの提案を使用しています。 CSS ネスティングは CSS セレクターやプロパティを相互にネストできるため、より具体的なセレクタースコープを作成することができます。 Sass は最初のプリプロセッサのうちの 1 つであり、ネスティングをサポートしていた（もしくは最初のものであった）のですが、多年経過した現在、ネスティングは標準化される見通しとなり、これによりビルドツールを必要とせずにブラウザーで利用できるようになります。

それまでは、 Parcel が PostCSS のサポートを受けて、ネストされた CSS とネイティブにサポートされる CSS の間の変換を行います。 Parcel は PostCSS との統合をデフォルトで提供しています。このプロジェクトでは特に CSS ネスティング（ Sass の代わりに）を使用することに決めたため、プロジェクトには PostCSS プラグインを含める必要があります。

postcss-preset-env を使用し、「明日の CSS を今日使う」ことができます。以下の手順に従って設定を行います：

1. プロジェクトディレクトリーのルートに `.postcssrc` という名前の単一のファイルを追加します。
2. 新しいファイルに以下の内容を追加します。これにより、最新の CSS 機能を完全に使用できるようになります。

```json
{
  "plugins": {
    "postcss-preset-env": {
      "stage": 0
    }
  }
}
```

これで必要な作業はすべて完了です — なお、 Parcel はデフォルトで依存関係を自動的にインストールしてくれることを忘れないでください！

ツールチェーンのこの段階はかなり厄介なことがありますが、わざと設定や複雑さを減らすように意図して選んだツールのおかげで、開発フェーズで行うべき作業はこれ以上ありません。モジュールは正しくインポートされ、ネストされた CSS は正しく「通常の CSS 」に変換され、ビルドプロセスによる開発の妨げがありません。

さあ、ソフトウェアの開発が始められる準備が整いました！

変換の実行
-----

プロジェクトで作業を開始するために、コマンドラインで Parcel サーバーを実行します。デフォルトモードでは、コードの変更を監視し、自動的に依存関係をインストールします。これは便利ですね、コードとコマンドラインを行き来する必要がなくなります。

1. Parcel をバックグラウンドで起動するには、ターミナルに移動して以下のコマンドを実行します：

```bash
npx parcel src/index.html
```

依存関係がインストールされた後に、以下のような出力が表示されるはずです。

```bash
Server running at http://localhost:1234
✨  Built in 129ms.
```

Parcel は、react、react-dom、react-async-hook、date-fns、およびformat-numberを含む、コードで使用する依存関係もインストールします。したがって、最初の実行は通常のParcelの実行よりも時間がかかります。

**メモ:** もしプロジェクトでParcelを実行して `Error: ENOENT: no such file or directory` というエラーが表示された場合は、プロセスを`Ctrl` + `C`で停止してから再度実行してください。

サーバーは現在、表示されたURL（この場合は localhost:1234）で実行されています。
2. ブラウザーでこのURLに移動すると、サンプルアプリが動作しているのが見えるでしょう！

Parcel のもう一つの巧妙な仕掛けは、ソースコードの変更がブラウザーで自動的に更新されるという点です。試してみましょう。

1. 好きなテキストエディタで `src/components/App.js` ファイルを開きます。
2. "near misses" というテキストを検索し、代わりに "flying pigs" のような面白いテキストに置き換えます。
3. ファイルを保存し、ブラウザーで動作しているアプリに戻ります。するとブラウザーが自動的にリフレッシュされ、ページの上部にある "<date> there will be <number> near misses" という行が変更されていることに気付くでしょう！

また、 ESLint と Prettier も試してみることができます — ファイルから意図的に多くの空白を削除して、 Prettier を実行して整形してみたり、 JavaScript ファイルに構文エラーを導入して Parcel を使用して再ビルドした際に ESLint がどのようなエラーを表示するか確認してみたりしてください。

まとめ
---

この章では、かなり良いローカル開発環境を構築し、アプリケーションを作成する準備が整いました。

通常、ウェブソフトウェアの開発では、この時点で作成したいソフトウェアのコードを作成する段階に入ることになります。しかし、このモジュールはウェブ開発のコードそのものではなく、ウェブ開発周りのツールを学ぶことが目的ですので、実際のコーディングは教えません — 実際のコーディングについての情報はMDNの他の部分で見つけることができます！

代わりに、あなたがツールを使用するためのサンプルプロジェクトを用意しました。私たちは、残りの章でこのサンプルコードを使って作業することをお勧めします。そしてその後、 src ディレクトリーの内容を自分のプロジェクトに変更し、それを Netlify に公開してみることもできます！実際に次の章では Netlify へのデプロイが最終的な目標となります！

* 前のページ
* Overview: Understanding client-side tools
* 次のページ


アプリのデプロイ - ウェブ開発を学ぶ

アプリのデプロイ
========

* 前のページ
* Overview: Understanding client-side tools

シリーズの最後の記事では、前の記事で構築したサンプルツールチェーンを取り上げ、サンプルアプリをデプロイできるようにそれに追加します。 コードを GitHub にプッシュし、Netlify を使用してデプロイし、プロセスに簡単なテストを追加する方法も示します。

|  |  |
| --- | --- |
| 前提条件： | 主要な HTML、CSS、と JavaScript 言語 |
| 目的： | アプリのデプロイに焦点を当てて、完全なツールチェーンのケーススタディの作業を完了します。 |

開発後
---

プロジェクトのライフサイクルのこのセクションでは、解決すべき広範囲の問題が潜在的に存在します。 したがって、手動介入をできるだけ少なくする方法でこれらの問題を処理するツールチェーンを作成することが重要です。

この特定のプロジェクトに関して考慮すべき点がいくつかあります。

* 実稼働ビルドの生成: ファイルが最小化され、チャンク化され、ツリーシェイクが適用され、バージョンが「キャッシュが無効化」されていることを確認します。
* テストの実行: テストの範囲は、「このコードは適切にフォーマットされていますか?」などです。「これは期待どおりの動作をするか?」ということを確認し、テストが失敗することを確認すると展開が妨げられます。
* 更新されたコードを実際にライブデプロイした URL: または、最初に確認できるようにステージング URL にデプロイすることもできます。

>
> **メモ：** キャッシュ無効化は、このモジュールではこれまでに見たことのない新しい用語です。これはブラウザ自体のキャッシュメカニズムを破壊する戦略であり、ブラウザにコードの新しいコピーを強制的にダウンロードさせます。 Parcel (そして実際には他の多くのツール) は、新しいビルドごとに一意のファイル名を生成します。この一意のファイル名はブラウザのキャッシュを「破棄」し、デプロイされたコードが更新されるたびにブラウザが新しいコードをダウンロードするようにします。
>
>
>

上記のタスクはさらに別のタスクに分割されます。ほとんどのウェブ開発チームは、開発後のフェーズの少なくとも一部について独自の条件とプロセスを持っていることに注意してください。

このプロジェクトでは、 Netlify の素晴らしい静的ホスティングサービスを使用してプロジェクトをホストします。 Netlify は、プロジェクトをオンラインで表示し、友人、家族、同僚と共有するためのホスティング、つまり URL を提供します。

ホスティングへのデプロイはプロジェクトのライフサイクルの最後になる傾向がありますが、 Netlify などのサービスを使用すると、デプロイのコスト(金銭面と実際のデプロイに必要な時間の両方)が削減され、開発中にデプロイすることが可能になります。進行中の作業を共有するか、他の目的でプレリリースするかのいずれかです。

Netlify では、特に、デプロイ前のタスクを実行することもできます。これは、この場合、すべての実稼働コードのビルドプロセスを Netlify 内で実行でき、ビルドが成功すると、ウェブサイトの変更がデプロイされることを意味します。

Netlify は ドラッグアンドドロップデプロイメントサービスを提供していますが、 GitHub リポジトリーにプッシュするたびに Netlify への新しいデプロイメントをトリガーする予定です。

独自のビルドツールチェーンを決定する際に探すことをお勧めするのは、まさにこの種の接続されたサービスです。コードをコミットして GitHub にプッシュすると、更新されたコードによってビルドルーチン全体が自動的にトリガーされます。すべて問題がなければ、ライブ変更が自動的にデプロイされます。実行する必要があるアクションは、最初の「プッシュ」だけです。

ただし、これらの手順を設定する必要があるので、それについてはこれから見ていきます。

ビルドプロセス
-------

繰り返しになりますが、開発には Parcel を使用しているため、ビルドオプションの追加は非常に簡単です。 `npx parcel src/index.html` を使用してサーバーを実行する代わりに、 `npx parcel build src/index.html` を使用してサーバーを実行することができます。これにより、 Parcel は、単に開発やテストの目的で実行するのではなく、本番環境に備えたすべてのものを構築します。これには、コードの縮小とツリーシェイクの実行、およびファイル名のキャッシュ無効化が含まれます。

新しく作成された実稼働コードは、 `dist` という新しいディレクトリーに配置されます。このディレクトリーには、ウェブサイトを実行するために必要なすべてのファイルが含まれており、すぐにサーバーにアップロードできます。

ただし、このステップを手動で実行することが最終的な目的ではありません。私たちが望んでいるのは、ビルドが自動的に行われ、 `dist` ディレクトリーの結果がウェブサイトにライブでデプロイされることです。

GitHub のコードリポジトリーを更新するたびに、 Netlify がその変更を自動的に拾い上げ、ビルドタスクを実行し、最終的に新しいアップデートをリリースします。

ビルドコマンドを npm スクリプトとして `package.json` ファイルに追加して、コマンド `npm run build` がビルドプロセスをトリガーするようにします。このステップは必須ではありませんが、セットアップの習慣を身につけるのは良いベストプラクティスです。すべてのプロジェクトにわたって、 `npm run build` を利用して、覚えておく必要なく常に完全なビルドステップを実行できます。各プロジェクトの特定のビルドコマンド引数。

1. プロジェクトのルートディレクトリーにある `package.json` ファイルを開き、 `scripts` プロパティを見つけます。
2. コードをビルドするために実行できる `build` コマンドを追加します。次の行をプロジェクトに追加します。

```json
"scripts": {
  // …
  "build": "parcel build src/index.html"
}
```

>
> **メモ：** `scripts` プロパティ内にすでにコマンドが含まれている場合は、コマンドの末尾にカンマを入れます。 JSON を有効なままにしておきます。
>
>
>
3. これで、プロジェクトディレクトリーのルートで次のコマンドを実行して実稼働ビルドステップを実行できるようになります。(必要に応じて、まず最初に `Ctrl` + `C` を押して実行中のプロセスを終了します)

```bash
npm run build
```

これにより次のような出力が得られ作成された実稼働ファイル、そのサイズ、およびビルドにかかった時間が示されます。

```bash
dist/src.99d8a31a.js.map       446.15 KB     63ms
dist/src.99d8a31a.js           172.51 KB    5.55s
dist/stars.7f1dd035.svg          6.31 KB    145ms
dist/asteroid2.3ead4904.svg      3.51 KB    155ms
dist/asteroid1.698d75e9.svg       2.9 KB    153ms
dist/src.84f2edd1.css.map        2.57 KB      3ms
dist/src.84f2edd1.css            1.25 KB    1.53s
dist/bg.084d3fd3.svg               795 B    147ms
dist/index.html                    354 B    944ms
```

やってみましょう！

このプロジェクトの独自のインスタンスを作成するには、このプロジェクトのコードを独自の git リポジトリーでホストする必要があります。次のステップは、プロジェクトを GitHub にプッシュすることです。

GitHub への変更のコミット
----------------

このセクションでは、コードを git リポジトリーに保存するまでの手順を説明しますが、これは git チュートリアルとは程遠いものです。優れたチュートリアルや書籍が数多く提供されており、 Git and GitHub ページから始めるのが適しています。

先ほど作業ディレクトリーを git 作業ディレクトリーとして初期化しました。これを簡単に確認するには、次のコマンドを実行します。

```bash
git status
```

どのファイルが追跡されているか、どのファイルがステージングされているかなどのステータスレポートを取得する必要があります。これらの用語はすべて git 文法の一部です。 `fatal: not a git repository` というエラーが返された場合、作業ディレクトリーは git 作業ディレクトリーではないため、 `git init` を使用して git を初期化する必要があります。

今、私たちの前には 3 つのタスクがあります。

* ステージに加えた変更を追加します( git がファイルをコミットする場所の特別な名前)。
* 変更をリポジトリーにコミットします。
* 変更を GitHub にプッシュします。

1. 変更を追加するには、次のコマンドを実行します。

```bash
git add .
```

最後のピリオドに注意してください。これは「このディレクトリー内のすべて」を意味します。 `git add .` コマンドは、少し強力なアプローチです。これまでに行ったすべてのローカル変更を一度に追加します。追加するものをより細かく制御したい場合は、対話型プロセスに `git add -p` を使用するか、 `git add path/to/file` を使用して個々のファイルを追加します。
2. これですべてのコードがステージングされ、コミットできるようになりました。 次のコマンドを実行します。

```bash
git commit -m 'committing initial code'
```

**メモ:** コミットメッセージには自由に何を書き込んでも構いませんが、適切なコミットメッセージに関する役立つヒントがウェブ上にいくつかあります。変更の内容を明確に説明できるように、短く簡潔に説明するようにしてください。
3. 最後にコードを GitHub でホストされているリポジトリーにプッシュする必要があります。今すぐそうしましょう。
 GitHub で https://github.com/new にアクセスし、このコードをホストする独自のリポジトリーを作成します。
4. リポジトリーにスペースを含まない短くて覚えやすい名前 (単語を区切るにはハイフンを使用します) と説明を付けて、ページの下部にある *Create repository* をクリックします。
 これで、新しい GitHub リポジトリーを指す「リモート」 URL が作成されたはずです。

 ![GitHub screenshot showing remote URLs you can use to deploy code to a GitHub repo](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Deployment/github-quick-setup.png)
5. これで、コードを GitHub にプッシュする準備が整いました。 今すぐ次のコマンドを実行します。

```bash
git remote add github https://github.com/yourname/repo-name.git
```

したがって、上のスクリーンショットのように、「リモート」 URL が `https://github.com/remy/super-website.git` の場合、コマンドは次のようになります。

```bash
git remote add github https://github.com/remy/super-website.git
```

URL を独自のリポジトリーに変更し、今すぐ実行します。
6. これで、コードを GitHub にプッシュする準備が整いました。今すぐ次のコマンドを実行します。

```bash
git push github main
```

この時点で、 Git がプッシュの送信を許可する前に、ユーザー名とパスワードの入力を求められます。これは、前のスクリーンショットに見られるように、 SSH オプションではなく HTTPS オプションを使用したためです。このためには、 GitHub ユーザー名が必要です。次に、 2 要素認証 (2FA) が有効になっていない場合は、 GitHub パスワードが必要です。可能であれば 2FA を使用することを常にお勧めしますが、その場合は「個人アクセストークン」も使用する必要があることに注意してください。 GitHub のヘルプページには、その入手方法を説明する優れた簡単なチュートリアルが記載されています。

**メモ:** SSH オプションを使用して、GitHub にプッシュするたびにユーザー名とパスワードを入力する必要をなくすことに興味がある場合は、 このチュートリアルでその方法を説明します 。

この最後のコマンドは、ブランチ `main` を使用して、 `github` と呼ばれる「リモート」の場所（github.com でホストされているリポジトリーです。好きな名前にすることができます）にコードをプッシュする（別名パブリッシュする）ように git に指示します。ブランチにはまったく遭遇しませんでしたが、 `main` ブランチが作業のデフォルトの場所であり、git がそこから開始されます。これは Netlify が検索するデフォルトのブランチでもあり、便利です。

**メモ:** 2020 年 10 月まで、GitHub のデフォルト ブランチは `master` でしたが、さまざまな社会的理由により `main` に切り替えられました。この古いデフォルトブランチは、遭遇するさまざまなプロジェクトに表示される可能性があることに注意してください。ただし、独自のプロジェクトには `main` を使用することをお勧めします。

プロジェクトを Git でコミットし、GitHub リポジトリーにプッシュしたら、ツールチェーンの次のステップは、GitHub を Netlify に接続して、プロジェクトをウェブ上でライブデプロイできるようにすることです。

デプロイに Netlify を使用する
-------------------

GitHub から Netlify へのデプロイは、手順さえわかれば、特にこのプロジェクトのような「静的ウェブサイト」の場合、驚くほど簡単です。

**メモ:** 開発ワークフローの改善に役立つ Netlify のガイドとチュートリアルも多数あります。

これをやってみましょう。

1. https://app.netlify.com/start に移動します。
2. *Continuous Deploymen(継続的デプロイメント)* という見出しの下にある GitHub ボタンを押します。 *Continuous Deployment(継続的デプロイメント)* とは、コードリポジトリーが変更されるたびに、 Netlify がコードのデプロイメントを試みる(つまり *continuous(継続的)* である)ことを意味します。

 ![netlify deployment options, as described in the surrounding text](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Deployment/netlify-deploy.png)
3. 以前に Netlify を認証したかどうかに応じて、GitHub で Netlify を認証し、それを認証するアカウントを選択する必要がある場合があります(複数の GitHub アカウントまたは組織がある場合)。プロジェクトをプッシュしたものを選択します。
4. Netlify は、検索できる GitHub リポジトリーのリストを表示します。プロジェクトリポジトリーを選択し、次のステップに進みます。
5. Netlify を GitHub アカウントに接続し、プロジェクトリポジトリーをデプロイするためのアクセス権を付与したため、 Netlify はプロジェクトのデプロイメントを *どのように* 準備するか、 *何を* デプロイするかを尋ねます。
 *Build コマンド* としてコマンド `npm run build` を入力し、 *Publish ディレクトリー* として `dist` ディレクトリーを指定する必要があります。これには公開したいコードが含まれています。
6. 最後に、 *サイトのデプロイ* をクリックします。

 ![netlify distribution options, as described in the surrounding text](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Deployment/netlify-dist.png)
7. デプロイメントが行われるまで少し待った後、公開されたサイトを表示するためにアクセスできる URL を取得します。試してみてください。
8. さらに良いことに変更を加えてリモート git リポジトリー (GitHub 上) にその変更を *プッシュ* するたびに、 Netlify への通知がトリガーされ、指定されたビルドタスクが実行され、結果として得られる `dist` ディレクトリーが公開されたディレクトリーにデプロイされます。
 今すぐ試してください。アプリに小さな変更を加えてから、次のコマンドを使用して GitHub にプッシュします。

```bash
git add .
git commit -m 'simple netlify test'
git push github main
```

公開されたサイトが変更に応じて更新されるはずです。公開には数分かかる場合があるので、少しお待ちください。

Netlify については以上です。 必要に応じて、Netlify プロジェクトの名前を変更したり、独自のドメイン名を使用するように指定したりできます。 Netlify では、優れたドキュメントを提供しています。

ここで、ツールチェーンの最後のリンクとして、コードが機能することを確認するテストを説明します。

テスト
---

テスト自体は、フロントエンド開発の領域内であっても、広大なテーマです。プロジェクトに初期テストを追加する方法と、そのテストを使用してプロジェクトのデプロイメントの発生を防止または許可する方法を説明します。

テストに近づくとき、問題に対処する方法はたくさんあります。

* エンドツーエンドのテスト。訪問者が何かをクリックすると、別のことが起こります。
* 統合テスト。基本的には、「あるコードブロックが別のブロックに接続されても機能するかどうか」をテストします。
* ユニットテスト。機能の小さな特定のビットをテストして、期待どおりに動作するかどうかを確認します。
* その他にも多くの種類テストがあります。また多数の有用なテスト情報については、クロスブラウザテストモジュールを参照してください。

また、テストは JavaScript に限定されないことにも注意してください。テストはレンダリングされた DOM 、ユーザーインタラクション、 CSS 、さらにはページの外観に対して実行できます。

ただし、このプロジェクトではサードパーティの NASA データフィードをチェックし、それが正しい形式であることを確認する小さなテストを作成します。そうでない場合、テストは失敗し、プロジェクトは稼働できなくなります。それ以外のことを行うことは、このモジュールの範囲を超えます。テストは実際には独自の別個のモジュールを必要とする巨大な主題です。私たちは、このセクションが少なくともテストの必要性を認識してもらい、テストに行ってもっと学びたいという動機を与える種を植えることを願っています。

このプロジェクトのテストにはテストフレームワークは含まれていませんが、フロントエンド開発の世界のすべてのものと同様に、多数のフレームワークオプションがあります。

大切なのはテストそのものではありません。重要なのは、失敗または成功をどのように処理するかです。一部の展開プラットフォームには、パイプラインの一部としてテストのための特定の方法が含まれています。 GitHub、GitLab などの製品はすべて、個々のコミットに対するテストの実行をサポートしています。

このプロジェクトは Netlify にデプロイされており、 Netlify はビルドコマンドについてのみ尋ねるため、テストをビルドの一部にする必要があります。テストが失敗すると、ビルドは失敗し、 Netlify はデプロイされません。

始めましょう。

1. あなたの `package.json` を開いてください。
2. `scripts` を確認し、次のテストコマンドとビルドコマンドが含まれるように更新します。

```json
"scripts": {
  …
  "test": "node tests/\*.js",
  "build": "npm run test && parcel build src/index.html"
}
```

3. もちろん、コードベースにテストを追加する必要があります。ルートディレクトリーに test という名前の新しいディレクトリーを作成します。

```bash
mkdir tests
```

4. 新しいディレクトリー内にテストファイルを作成します。

```bash
cd tests
touch nasa-feed.test.js
```

5. このファイルを開き、 nasa-feed.test.js の内容を追加します。
6. このテストでは、axios パッケージを使用して、テストするデータフィードを取得します。この依存関係をインストールするには、次のコマンドを実行します。

```bash
npm install --save-dev axios
```

Parcel ではこの依存関係を解決できないため、 axios を手動でインストールする必要があります。私たちのテストは、 Parcel のシステムの範囲外にあります。 Parcel はテストコードをまったく参照したり実行したりしないため、依存関係を自分でインストールする必要があります。
7. ここでテストを手動で実行するには、コマンドラインから次のコマンドを実行します。

```bash
npm run test
```

成功した場合、結果は…何もありません。これは成功とみなされます。一般に、テストにノイズが多くなるのは、何か問題がある場合のみです。テストはまた、コマンドラインに成功を伝える特別な信号 (終了信号 0) で終了しました。失敗した場合、テストは終了コード 1 で失敗します。これは、「何かが失敗しました」というシステムレベルの値です。
 `npm run test` コマンドは、node を使用して、tests ディレクトリー内の `.js` で終わるすべてのファイルを実行します。
 ビルド スクリプトでは、 `npm run test` が呼び出され、文字列 `&&` が表示されます。 — これは、「左側の処理が成功した場合 (ゼロで終了)、右側の処理を実行する」ことを意味します。 つまり、これは、テストに合格したら、コードをビルドするということになります。
8. 以前に使用したものと同様のコマンドを使用して、新しいコードを GitHub にアップロードする必要があります。

```bash
git add .
git commit -m 'adding test'
git push github main
```

場合によっては、ビルドされたコードの結果をテストしたい場合があります(これは、私たちが作成したオリジナルのコードとは異なるため)。そのため、ビルド コマンドの後にテストを実行する必要があるかもしれません。独自のプロジェクトに取り組んでいるときは、これらすべての個別の側面を考慮する必要があります。

さて、最後に、プッシュ後 1 分ほどで、 Netlify はプロジェクトの更新をデプロイします。ただし、導入されたテストに合格した場合に限ります。

まとめ
---

サンプルケーススタディとモジュールはこれで終わりです。お役に立てば幸いです。自分をクライアント側ツールのウィザードとみなすまでには長い道のりがありますが、このモジュールが、クライアント側のツールを理解するための重要な第一歩となり、さらに学んで新しいツールを試す自信を与えてくれることを願っています。

ツールチェーンのすべての部分を要約してみましょう。

* コードの品質とメンテナンスは ESLint と Prettier によって実行されます。 これらのツールは、 `npm install --dev eslint prettier eslint-plugin-react` を介して `devDependencies` としてプロジェクトに追加されます（この特定のプロジェクトは React を使用しているため、 ESLint プラグインが必要です）。
* コード品質ツールが読み取る 2 つの構成ファイル: `.eslintrc` と `.prettierrc` です。
* 開発中、依存関係を処理するために Parcel を使用します。 `parcel src/index.html` はバックグラウンドで実行され、変更を監視し、ソースを自動的に構築します。
* デプロイメントは、変更を GitHub (「main」ブランチ上) にプッシュすることで処理されます。これにより、 Netlify でのビルドとデプロイメントがトリガーされ、プロジェクトが公開されます。この例の場合、この URL は near-misses.netlify.com です。独自の一意の URL が作成されます。
* NASA API フィードが正しいデータ形式を提供しない場合、サイトの構築と展開をブロックする簡単なテストもあります。

挑戦したい方は、このツールチェーンの一部を最適化できないか検討してください。自問すべきいくつかの質問

* ビルドステップ中に画像を圧縮できますか?
* React を もっと小さいもの に置き換えることはできますか?
* パフォーマンス監査 など、不正なビルドのデプロイを防ぐためのテストをさらに追加していただけますか?
* 新しいデプロイが成功したか失敗したかを知らせる通知を設定していただけますか?
* 前のページ
* Overview: Understanding client-side tools


クライアントサイドツールの概要 - ウェブ開発を学ぶ

クライアントサイドツールの概要
===============

* Overview: Understanding client-side tools
* 次のページ

この記事では、最新のウェブツールの概要、利用可能なツールの種類、ウェブアプリ開発のライフサイクルのどこでそれらのツールに使用するか、個々のツールのヘルプを見つける方法について説明します。

|  |  |
| --- | --- |
| 前提条件： | 主要な HTML、CSS、と JavaScript 言語 |
| 目的： | クライアントサイドツールの種類とその方法を理解する ツールを見つけて、それらのヘルプを取得します。 |

最新ツールの概要
--------

ウェブ用のソフトウェアの作成は、年月を経てより洗練されてきました。 HTML、CSS、および JavaScript を「手作業で」記述することは依然として完全に合理的ですが、開発者がウェブサイトまたはアプリの構築プロセスを高速化するために使用できる豊富なツールが現在あります。

開発コミュニティの間で一般的な「おなじみの名前」になっている非常に確立されたツールがいくつかあり、特定の問題を解決するために毎日新しいツールが作成およびリリースされています。 自分自身の開発プロセスを支援するソフトウェアを作成したり、既存のツールではまだ処理されていないように見える特定の問題を解決したりすることさえあるかもしれません。

1 つのプロジェクトに含めることができる膨大な数のツールに圧倒されがちです。 同様に、Webpack のようなツールの単一の構成ファイルは数百行の長さになる可能性があり、そのほとんどは魔法の呪文であり、動作をしているように見えますが、それはマスターエンジニアだけしか完全には理解できません！

最も経験豊富なウェブ開発者でさえ、ツールの問題で行き詰まってしまうことがあります。アプリケーションコードの 1 行に触れる前に、ツールパイプラインを機能させるために何時間も無駄にする可能性があります。過去に苦労したことがある場合でも、心配しないでください。あなたは一人ではありません。

これらの記事では、ウェブツールに関するすべての質問に答えるわけではありませんが、基礎を理解するのに役立つ出発点を提供し、そこから構築することができます。 あらゆる複雑なトピックと同様に、小さく始めて、徐々に高度な用途へと進めていくのが良いでしょう。

最新ツールのエコシステム
------------

今日の最新の開発者ツールのエコシステムは巨大であるため、ツールがどのような主な問題を解決しているかについて幅広い考えを持っていると役に立ちます。 お気に入りの検索エンジンで、"フロントエンド開発者ツール"と検索すると、テキストエディターからブラウザー、メモを取るのに使用できるタイプのペンに至るまで、膨大な範囲の結果が表示されます。

コードエディターの選択は確かにツールの選択ですが、この一連の記事ではそれを超えて、ウェブコードをより効率的に作成するのに役立つ開発者ツールに焦点を当てます。

大まかな観点から、クライアントサイドツールは、解決すべき問題を次の 3 つの大きなカテゴリーに分類できます。

* **セーフティネット** — コード開発時に役立つツール。
* **変換** — 何らかの方法でコードを変換するツール。 中間言語をブラウザーが理解できる JavaScript に変換します。
* **開発後評価** — テストツールやデプロイツールなど、コードを記述した後に役立つツール。

これらをそれぞれ詳しく見ていきましょう。

### セーフティネット

これらは、作成するコードを少し改善するためのツールです。

ツールのこの部分は、自分自身の開発環境に固有のものであるべきですが、すべての開発者が同じプロセスを使用するように、何らかのポリシーや 事前設定をインストールすることができる企業も珍しくありません。

これには、安定した信頼性の高いコードを開発するために、開発プロセスを容易にする何らかのものが含まれます。セーフティネット ツールも、コードを毎回触れることなく、間違いを防いだり、間違いを自動的に修正したりすることを支援するものでなければなりません。

開発者が使用している非常に一般的なセーフティネットツールの種類は次のとおりです。

#### リンター

**リンター**は、コードをチェックして、存在するエラー、エラーの種類、エラーが存在するコード行を通知するツールです。 多くの場合、リンターはエラーを報告するだけでなく、チームが使用している可能性のある特定のスタイルガイドの違反も報告するように構成できます (たとえば、インデントに間違った数のスペースを使用しているコード、または通常の文字列リテラルではなくテンプレートリテラルを使用しているコード）。

ESLint は、業界標準の JavaScript リンターです。これは、潜在的な構文エラーを検出し、コード全体で「ベストプラクティス」を奨励する高度に構成可能なツールです。 一部の企業やプロジェクトも ESLint 構成を共有しています。

csslint など、他の言語用の lint ツールもあります。

webhint も一見の価値があります。これは、アクセシビリティ、パフォーマンス、MDN のブラウザー互換性データを介したクロスブラウザー互換、セキュリティ、PWA のテストなどのアプローチを含むベストプラクティスを明らかにする、構成可能なオープンソースのウェブリンターです。 これは、Node.js コマンドラインツールおよび VS Code 拡張機能として利用できます。

#### ソースコード管理

**バージョン管理システム** (VCS) とも呼ばれる**ソースコード管理**は、作業のバックアップやチームでの作業に不可欠です。 典型的な VCS には、変更を加えるローカルバージョンのコードが含まれます。 次に、サーバーのどこかに保存されているリモートリポジトリー内のコードの「マスター」バージョンに変更を「プッシュ」します。 通常、コードの「マスター」"コピーに対してどのような変更がいつ行われるかを制御および調整する方法があるため、開発者のチームがお互いの作業を常に上書きすることはありません。

Git は、最近ほとんどの人が使用しているソースコード管理システムです。 主にコマンド ラインからアクセスしますが、使いやすいユーザー インターフェイスからアクセスすることもできます。 コードを git リポジトリーに格納すると、それを独自のサーバーインスタンスにプッシュしたり、GitHub、GitLab、BitBucket などのホストされたソース管理ウェブサイトを使用したりできます。

このモジュールでは GitHub を使用します。 詳細については、Git および GitHub を参照してください。

#### コードフォーマッター

コードフォーマッターは、コードのエラーを指摘するのではなく、通常、スタイルルールに従ってコードが正しくフォーマットされていることを確認し、理想的には見つけたエラーを自動的に修正する傾向があることを除いて、リンターに多少関連しています。

Prettier はコードフォーマッターの非常に一般的な例であり、モジュールの後半で使用します。

#### バンドラー/パッケージャー

これらは、実際に使用しているコードライブラリーの部分のみを最終的な製品コードに入れるための「ツリーシェーキング」や、すべてのコードを削除するための「ミニファイ」など、コードを製品用に準備するためのツールです。サーバーにアップロードする前に、本番コードの空白をできるだけ小さくします。

Parcel は、このカテゴリーに適合する特に賢いツールです。上記のタスクを実行できますが、HTML、CSS、画像ファイルなどのアセットを便利なバンドルにパッケージ化してデプロイできるようにし、依存関係を追加するのにも役立ちます。それらを使用しようとするたびに自動的に一部のコード変換作業も処理できます。

Webpack は、同様のことを行う別の非常に人気のあるパッケージング ツールです。

### 変換

ウェブアプリのライフサイクルのこの段階では、通常、「将来のコード」（ブラウザーでネイティブサポートされていない可能性のある最新の CSS や JavaScript 機能など）でコーディングするか、 TypeScript などの別の言語を完全に使用してコーディングすることができます。 変換ツールは、ブラウザーと互換性のあるコードを生成して、本番環境で使用できるようにします。

一般にウェブ開発は、HTML、CSS、JavaScript の 3 つの言語と考えられており、これらすべての言語に変換ツールがあります。 変換には、(とりわけ) 2 つの主な利点があります。

1. 最新の言語機能を使用してコードを記述し、日常の端末で動作するコードに変換する能力。 たとえば、最先端の新しい言語機能を使用して JavaScript を記述したい場合がありますが、それらの機能をサポートしていない古いブラウザーでも最終的な製品コードを動作させることができます。 ここでの良い例は次のとおりです。
    * Babel: 開発者が最先端の JavaScript を使用してコードを記述できるようにする JavaScript コンパイラー。Babel はそれを受け取り、より多くのブラウザーが理解できる旧式の JavaScript に変換します。 開発者は、Babel のプラグインを作成して公開することもできます。
    * PostCSS: Babel と同じようなことを行いますが、最先端の CSS 機能を対象としています。 古い CSS 機能を使用して何かを行う同等の方法がない場合、PostCSS は JavaScript ポリフィルをインストールして、必要な CSS 効果をエミュレートします。
2. コードをまったく別の言語で記述し、それをウェブ互換言語に変換するオプション。 例えば、
    * Sass/SCSS: この CSS 拡張機能を使用すると、変数、ネストされたルール、ミックスイン、関数、およびその他の多くの機能を使用できます。その一部はネイティブ CSS （変数など）で使用でき、一部は使用できません。
    * TypeScript: TypeScript は、多数の追加機能を提供する JavaScript のスーパーセットです。 TypeScript コンパイラーは、本番用にビルドするときに TypeScript コードを JavaScript に変換します。
    * React、Ember、Vue、 Svelte、Angular などのフレームワーク。フレームワークは多くの機能を無料で提供し、バニラ JavaScript の上に構築されたカスタム構文を介して使用できます。 バックグラウンドでは、フレームワークの JavaScript コードがこのカスタム構文を解釈し、最終的なウェブアプリとしてレンダリングするために懸命に働いています。
### 開発後評価

開発後評価ツールにより、ソフトウェアがウェブに公開され、実行され続けることが保証されます。 これには、展開プロセス、テスト フレームワーク、監査ツールなどが含まれます。

開発プロセスのこの段階は、アクティブな対話を最小限にしたい段階です。そのため、構成が完了すると、ほとんど自動的に実行され、何か問題が発生した場合にのみポップアップして通知します。

#### テストツール

これらは通常、コードに対してテストを自動的に実行して、先に進む前にコードが正しいことを確認するツールの形をとります（たとえば、変更を GitHub リポジトリーにプッシュしようとする場合）。 これには、リンティングだけでなく、コードの一部を実行して正常に動作することを確認する単体テストなどのより高度な手順も含まれます。

* テストを作成するためのフレームワークには、 Jest、Mocha、Jasmine が含まれます。
* 自動化されたテスト実行および通知システムには、 Travis CI、Jenkins、Circle CI、その他様々なツール があります 。

#### デプロイツール

デプロイシステムを使用すると、ウェブサイトを公開することができ、静的サイトと動的サイトの両方で使用でき、一般にテスト システムと一緒に動作する傾向があります。 たとえば、一般的なツールチェーンは、変更がリモートリポジトリーにプッシュされるまで待機し、いくつかのテストを実行して変更が問題ないかどうかを確認し、テストに合格すると、アプリを運用サイトに自動的にデプロイします。

Netlify は現在最も人気のあるデプロイ ツールの 1 つですが、 Vercel や GitHub Pages などもあります。

#### その他

開発後の段階で使用できるツールは、他にもいくつかの種類があります。たとえば、コード品質指標を収集するための Code Climate、クロスブラウザーの互換性やその他のチェックのランタイム分析を実行するための webhint ブラウザー拡張機能、より強力な機能を提供するための GitHub ボットなどがあります。 GitHub の機能、アプリの稼働時間の監視を提供する Updown など、他にもたくさんあります！

### ツールの種類に関するいくつかの考え

開発ライフサイクルでさまざまなツールタイプが適用される順序は確かにありますが、ウェブサイトをリリースするためにこれらすべてを用意する必要はありませんのでご安心ください。 実際、これらは必要ありません。 ただし、これらのツールの一部をプロセスに含めることで、独自の開発エクスペリエンスが向上し、コードの全体的な品質が向上する可能性があります。

新しい開発者ツールがその複雑さに慣れるまでには時間がかかることがよくあります。 最もよく知られているツールの 1 つである Webpack は、操作が非常に複雑であるという評判がありますが、最新のメジャー リリースでは、一般的な使用法を簡素化することが大きく推進されたため、必要な構成は最小限に抑えられています。

ツールの成功を保証する特効薬は絶対にありませんが、経験を積むにつれて、 適した 自分やチームとそのプロジェクトに ワークフローを見つけることができます。 プロセスのねじれがすべて平らになれば、ツールチェーンは忘れることができるものになり、機能する *はず* です。

特定のツールを選択してヘルプを表示する方法
---------------------

ほとんどのツールは、単独で作成およびリリースされる傾向があるため、ほぼ確実に利用可能なヘルプがありますが、同じ場所または形式になることはありません。 そのため、ツールの使用に関するヘルプを見つけることや、使用するツールを選択することさえ難しい場合があります。 どのツールを使用するのが最適かについての知識は少し部分的です。つまり、まだウェブコミュニティに参加していない場合、どのツールを使用すればよいかを正確に判断するのは困難です。 これが、このシリーズの記事を書いた理由の 1 つであり、他の方法では見つけるのが難しい最初のステップを提供することを願っています。

おそらく、次のものの組み合わせが必要になるでしょう。

* 経験豊富な教師、メンター、仲間の学生、または経験があり、以前にそのような問題を解決した経験があり、アドバイスを提供できる同僚。
* 検索するのに便利で最適な場所。 フロントエンド開発者ツールの一般的なウェブ検索は、検索しているツールの名前がわかっている場合を除き、通常は役に立ちません。
    + たとえば、npm パッケージマネージャーを使用して依存関係を管理している場合は、 npm ホームページ にアクセスして、探しているツールの種類を検索することをお勧めします。日付フォーマット ユーティリティ、または一般的なコードフォーマッターを検索している場合は「formatter (フォーマッター)」。 人気度、品質、メンテナンス スコア、およびパッケージが最後に更新されたのはいつ頃かを確認してください。 また、クリックしてツールページにアクセスし、パッケージの月間ダウンロード数や、必要な機能を備えているかどうかを判断するために使用できる適切なドキュメントがあるかどうかを確認してください。 これらの基準に基づくと、 date-fns ライブラリー は、使用するのに適した日付フォーマット ツールのように見えます。 このモジュールの第 3 章では、このツールの動作を確認し、パッケージマネージャー全般について詳しく学習します。
    + ツール機能をコードエディターに統合するためのプラグインを探している場合は、コードエディターのプラグイン/拡張機能のページを参照してください。たとえば、VSCode 拡張機能を参照してください。フロントページで注目の拡張機能を確認し、必要な種類の拡張機能（またはツール名、たとえば VSCode 拡張機能ページで "ESLint" を検索）を検索してみてください。 結果が得られたら、拡張機能の品質の指標として、星の数やダウンロード数などの情報を確認します。
* MDN Learn Discourse や Stack Overflow など、使用するツールについて質問するための開発関連のフォーラム。

使用するツールを選択したら、最初に立ち寄るのはツールプロジェクトのホームページです。 これは本格的なウェブサイトである場合もあれば、コードリポジトリー内の単一の readme ドキュメントである場合もあります。 たとえば、date-fns のドキュメントは非常に優れており、完全で、簡単に理解できます。 ただし、一部のドキュメントは技術的でアカデミックなものであり、学習ニーズに適していない場合があります。

代わりに、特定の種類のツールを使い始めるための専用のチュートリアルを見つけたいと思うかもしれません。 CSS Tricks、Dev、freeCodeCamp、Smashing Magazine などのウェブサイトは、ウェブ開発業界向けに作成されているため、最初に検索することをお勧めします。

繰り返しますが、おそらくいくつかの異なるツールを試して、適切なツールを探し、それらが理にかなっているか、十分にサポートされているか、目的の機能を実行しているかどうかを確認します. これは問題ありません。すべて学習に適しています。経験を積むにつれて、道はスムーズになります。

まとめ
---

これで、クライアント側のウェブツールのトピックの概要についての簡単な紹介を締めくくります。 次に、多くのツールが呼び出されるコマンド ラインの速習コースを提供します。 コマンド ラインで何ができるかを見てから、最初のツールをインストールして使用してみます。

* Overview: Understanding client-side tools
* 次のページ


コマンドライン短期集中講座 - ウェブ開発を学ぶ

コマンドライン短期集中講座
=============

* 前のページ
* Overview: Understanding client-side tools
* 次のページ

開発プロセスでは、ターミナル (または「コマンドライン」 — これらは事実上同じことです) でいくつかのコマンドを実行する必要があることは間違いありません。この記事では、ターミナルの概要、ターミナルに入力する必要がある重要なコマンド、コマンドを連結する方法、および独自のコマンドラインインターフェイス (CLI) ツールを追加する方法について説明します。

|  |  |
| --- | --- |
| 前提条件： | 主要な HTML、CSS、と JavaScript 言語 |
| 目的： | ターミナル／コマンドラインとは何か、学ぶべき基本的なコマンドは何か、新しいコマンドラインツールをインストールする方法を理解します。 |

ターミナルへようこそ
----------

端末は、テキストベースのプログラムを実行するためのテキストインターフェイスです。ウェブ開発用のツールを実行している場合、選択したツールを使用するために、コマンドラインを開いていくつかのコマンドを実行する必要がある可能性がほぼ保証されています (**CLI ツール** — コマンドラインインターフェイスツールと呼ばれるツールをよく見かけます）。

 コマンドラインにコマンドを入力すると、多数のツールを使用できます。多くはシステムにプリインストールされており、その他の膨大な数はパッケージレジストリーからインストールできます。
 パッケージレジストリーはアプリストアに似ていますが、(ほとんどの場合) コマンドラインベースのツールとソフトウェア用です。
 この章の後半でいくつかのツールをインストールする方法を説明し、次の章でパッケージレジストリーについて詳しく学びます。

 コマンドラインに対する最大の批判の 1 つは、ユーザーエクスペリエンスが大幅に不足していることです。
 コマンドラインを初めて見るときは、気が遠くなるような体験になる可能性があります。空っぽの画面と点滅するカーソルが表示され、何をすべきかについての明確なヘルプはほとんどありません。

 表面的にはそれらは歓迎とはほど遠いものですが、それらを使用してできることはたくさんあります。少しのガイダンスと練習を行うことで、それらをより簡単に使用できるようになることをお約束します!
 これが私たちがこの章を提供している理由です — この一見不親切な環境であなたが始めるのを助けるために。

### ターミナルはどこから来たのか？

ターミナルは 1950 年代から 60 年代頃に誕生し、その元の形は現在私たちが使用しているものとはまったく似ていません (感謝すべきことです)。ウィキペディアのコンピューターターミナル のエントリで歴史の一部を読むことができます。

それ以来、ターミナルは、デスクトップマシンからクラウドに格納されたサーバー、Raspberry PI Zero のようなマイクロコンピューター、さらには携帯電話に至るまで、すべてのオペレーティングシステムの一貫した機能であり続けています。コンピューターの基盤となるファイルシステムと低レベルの機能への直接アクセスを提供するため、複雑なタスクをすばやく実行するのに非常に役立ちます。

自動化にも役立ちます。たとえば、「ch01-xxxx.png」から「ch02-xxxx.png」など、数百のファイルのタイトルを即座に更新するコマンドを書くことができます。ファインダーまたはエクスプローラー GUI アプリを使用してファイル名を更新すると、長い時間がかかります。

とにかく、ターミナルはすぐにはなくなりません。

### ターミナルはどのように見えますか？

以下に、端末にアクセスできるさまざまな種類のプログラムをいくつか示します。

次の画像は、Windows で使用できるコマンドプロンプトを示しています。「cmd」プログラムから「powershell」まで、さまざまなオプションがあり、プログラム名を入力してスタートメニューから実行できます。

![A vanilla windows cmd line window, and a windows powershell window](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line/win-terminals.png)

そして、その下に macOS ターミナルアプリケーションが表示されます。

![A basic vanilla macOS terminal](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line/mac-terminal.png)

### ターミナルへのアクセス方法を教えてください

今日、多くの開発者は Unix ベースのツールを使用しています (例: ターミナルと、そこからアクセスできるツール)。今日ウェブ上に存在する多くのチュートリアルやツールは、Unix ベースのシステムをサポートしています (残念ながらそれを想定しています) が、心配する必要はありません。ほとんどのシステムで利用できます。このセクションでは、選択したシステムの端末にアクセスする方法を見ていきます。

#### Linux/Unix

上で記したように、Linux/Unix システムにはデフォルトで利用可能なターミナルがあり、アプリケーションの中にリストされています。

#### macOS

macOS には、グラフィカルユーザーインターフェイスの下に位置する Darwin と呼ばれるシステムがあります。Darwin は Unix に似たシステムであり、ターミナルと低レベルツールへのアクセスを提供します。macOS Darwin はほとんどの場合 Unix と同等であり、この記事を読み進める上で心配する必要はありません。

ターミナルは、Applications/Utilities/Terminal で macOS で利用できます。

#### Windows

他のプログラミングツールと同様に、Windows でターミナル (またはコマンドライン) を使用することは、従来、他のオペレーティングシステムほど単純でも簡単でもありませんでした。しかし、状況は良くなっています。

Windows には伝統的に cmd (「コマンドプロンプト」) と呼ばれる独自の端末のようなプログラムがありましたが、これは明らかに Unix コマンドと同等ではなく、古いスタイルの Windows DOS プロンプトと同等です。

Windows でターミナルエクスペリエンスを提供するための優れたプログラムが存在します。たとえば、Powershell (インストーラーを見つけるにはこちらをご覧ください) や Gitbash (git for Windows ツールセットの一部として提供されます)

ただし、現代の Windows に最適なオプションは、Windows Subsystem for Linux (WSL) です。これは、Linux オペレーティングシステムを Windows 10 内から直接実行するための互換性レイヤーであり、仮想マシンを必要とせずに、Windows 上で直接「真の端末」を実行できます。

これは、無料で Windows ストアから直接インストールできます。必要なすべてのドキュメントは、Windows Subsystem for Linux Documentation にあります。

![a screenshot of the Windows subsystem for Linux documentation](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line/wsl.png)

Windows で選択するオプションに関しては、WSL をインストールすることを強くお勧めします。デフォルトのコマンドプロンプト (`cmd`) をそのまま使用することもできます。多くのツールは正常に動作しますが、Unix ツールとの同等性が向上すると、すべてがより簡単になります。

#### 補足: コマンドラインとターミナルの違いは何か?

通常、これら 2 つの用語は同じ意味で使用されます。技術的には、ターミナルはシェルを起動して接続するソフトウェアです。シェルは、セッションおよびセッション環境です (プロンプトやショートカットなどをカスタマイズできます)。コマンドラインは、コマンドを入力してカーソルが点滅するリテラル行です。

### ターミナルを使用する必要がありますか？

コマンドラインから利用できるツールは豊富にありますが、Visual Studio Code などのツールを使用している場合は、プロキシとして使用できる拡張機能も多数あります。端末を直接使用せずに端末コマンドを使用します。ただし、やりたいことすべてに対応するコードエディター拡張機能が見つかるわけではありません。最終的には、ターミナルである程度の経験を積む必要があります。

基本的な組み込み端末コマンド
--------------

説明はもう十分です — いくつかの端末コマンドを見てみましょう! コマンドラインですぐに実行できることのほんの一部を、それぞれの場合に関連するツールの名前とともに以下に示します。

* 作成、コピー、名前変更、削除などの基本レベルのタスクとともに、コンピューターのファイルシステムをナビゲートします。
    + ディレクトリーを移動: `cd`
    + ディレクトリーの作成: `mkdir`
    + ファイルを作成 (およびそのメタデータを変更): `touch`
    + ファイルのコピー: `cp`
    + ファイルの移動: `mv`
    + ファイルまたはディレクトリーの削除: `rm`
* 特定の URL にあるファイルのダウンロード: `curl`
* より大きなテキスト本文内のテキストの断片を検索: `grep`
* ファイルの内容をページごとに表示: `less`, `cat`
* テキストのストリームを操作および変換 (たとえば、HTML ファイル内の `<div>` のすべてのインスタンスを `<article>` に変更します。): `awk`, `tr`, `sed`

**メモ:** ウェブには、ウェブ上のコマンドラインをさらに深く掘り下げた優れたチュートリアルが多数あります。これは簡単な紹介にすぎません。

これらのツールのいくつかをコマンドラインで使用する方法を見てみましょう。先に進む前に、ターミナルプログラムを開きます。

### コマンドラインでのナビゲーション

コマンドラインにアクセスすると、必然的に特定のディレクトリーに移動して「何かをする」必要があります。すべてのオペレーティングシステム (デフォルトのセットアップを想定) は、ターミナルプログラムを「ホーム」ディレクトリーで起動するので、そこから別の場所に移動したくなるでしょう。

`cd` コマンドを使用すると、ディレクトリーを変更できます。技術的には、cd はプログラムではなく組み込みです。これは、オペレーティングシステムがすぐに使用できることを意味し、誤って削除することはできません。コマンドが組み込みかどうかについてあまり心配する必要はありませんが、組み込みはすべての UNIX ベースのシステムに表示されることに注意してください。

ディレクトリーを変更するには、端末に `cd` と入力し、その後に移動先のディレクトリーを入力します。ディレクトリーがホームディレクトリー内にあると仮定すると、`cd Desktop` を使用できます (以下のスクリーンショットを参照)。

![results of the cd Desktop command being run in a variety of windows terminals - the terminal location moves into the desktop](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line/win-terminals-cd.png)

これをシステムの端末に入力してみてください:

```bash
cd Desktop
```

前のディレクトリーに戻りたい場合は、2 つのドットを使用します。

```bash
cd ..
```

**メモ:** 存在することがわかっている名前をすべて入力するのではなく、`tab` キーを使用して自動補完することは、非常に便利なターミナルのショートカットです。たとえば、上記の 2 つのコマンドを入力した後、 `cd D` と入力して `tab` を押してみてください。現在のディレクトリーに存在する場合、ディレクトリー名 `Desktop` が自動補完されます。前進するときは、このことを念頭に置いてください。

行きたいディレクトリーが深くネストされている場合、そこに到達するためのパスを知る必要があります。これは通常、ファイルシステムの構造に慣れるにつれて簡単になりますが、パスがわからない場合は、通常、`ls` コマンド (以下を参照) を組み合わせて、パスをクリックして見つけることができます。Explorer/Finder ウィンドウを使用して、現在の場所に関連するディレクトリーの場所を確認します。

たとえば、`Desktop` にある `project` というディレクトリー内にある `src` というディレクトリーに移動する場合は、次の 3 つのコマンドを入力して、ホーム フォルダからそこに移動できます。

```bash
cd Desktop
cd project
cd src
```

しかし、これは時間の無駄です — 代わりに、CSS、HTML、または JavaScript コードで画像やその他のアセットへのパスを指定するときと同じように、パス内のさまざまな項目をスラッシュで区切って 1 つのコマンドを入力できます。

```bash
cd Desktop/project/src
```

パスの先頭にスラッシュを含めると、パスが絶対パスになることに注意してください (例: `/Users/your-user-name/Desktop`)。上記のように先頭のスラッシュを省略すると、パスは現在の作業ディレクトリーからの相対パスになります。これは、ウェブブラウザーの URL で表示されるものとまったく同じです。先頭のスラッシュは「ウェブサイトのルート」を意味し、スラッシュを省略すると「現在のページに関連する URL」を意味します。

**メモ:** Windows では、スラッシュの代わりにバックスラッシュを使用します。`cd Desktop\project\src` — これは非常に奇妙に思えるかもしれませんが、その理由に興味がある場合は、マイクロソフトのプリンシパルエンジニアの 1 人のこの YouTube クリップをご覧ください 。

### ディレクトリーの内容の一覧表示

別の組み込み Unix コマンドは `ls` (list の略) で、現在のディレクトリーの内容を一覧表示します。デフォルトの Windows コマンドプロンプト (`cmd`) を使用している場合、これは機能しないことに注意してください。) — 同等のものは `dir`です。

ターミナルでこれを実行してみてください:

```bash
ls
```

これにより、現在の作業ディレクトリー内のファイルとディレクトリーのリストが得られますが、情報は本当に基本的なものです。ファイルやディレクトリーなどではなく、存在する各項目の名前のみを取得します。幸いなことに、コマンドの使用法を少し変更するだけで、より多くの情報を得ることができます。

### コマンドオプションの紹介

ほとんどの端末コマンドにはオプションがあります。これらは、コマンドの最後に追加する修飾子であり、コマンドの動作を少し異なるものにします。これらは通常、コマンド名の後にスペースがあり、その後にダッシュが続き、その後に 1 つ以上の文字が続きます。

たとえば、これを試してみて、何が得られるかを確認してください。

```bash
ls -l
```

`ls` の場合、`-l` (*dash ell*) オプションを指定すると、各行に 1 つのファイルまたはディレクトリーが表示され、さらに多くの情報が表示されます。ディレクトリーは、行の一番左側にある文字「d」を探すことで識別できます。これらは、`cd` できるものです。

以下は、上部に「普通の」macOS ターミナルが表示されたスクリーンショットと、生き生きと見えるようにいくつかのアイコンと色が追加されたカスタマイズされたターミナルのスクリーンショットです。どちらも `ls -l` を実行した結果を示しています。

![A vanilla macOS terminal and a more colorful custom macOS terminal, showing a file listing - the result of running the ls -l command](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line/mac-terminals-ls.png)

**メモ:** 各コマンドで使用できるオプションを正確に確認するには、man ページ を参照してください。これを行うには、 `man` コマンドの後に、検索するコマンドの名前を入力します ( `man ls` など)。これにより、端末のデフォルトのテキストファイルビューアー(たとえば、私の端末では `less`) で man ページが開きます。その後、矢印キーまたは同様のメカニズムを使用してページをスクロールできる必要があります。man ページには、すべてのオプションが非常に詳細にリストされています。最初は少し戸惑うかもしれませんが、少なくとも必要な場合はそこにあることを知っています。man ページを読み終えたら、テキストビューアーの quit コマンドを使用して終了する必要があります (`less` の "q"。明らかでない場合は、ウェブで検索して見つける必要がある場合があります)。

**メモ:** 複数のオプションを指定してコマンドを同時に実行するには、通常、 `ls -lah` や `ls -ltrh` のように、ダッシュ文字の後にすべてのオプションを 1 つの文字列に入れることができます。`ls` の man ページを見て、これらの追加オプションが何をするかを調べてみてください!

2 つの基本的なコマンドについて説明したので、ディレクトリーを少し調べて、ある場所から次の場所に移動できるかどうかを確認してください。

### 作成、コピー、移動、削除

端末で作業する際におそらくかなり頻繁に使用することになる、その他の基本的なユーティリティコマンドが多数あります。それらは非常に単純なので、前の2つのコマンドほど詳細には説明しません。

重要なものを誤って削除しないように、以下のコマンド例をガイダンスとして使用して、どこかに作成したテストディレクトリーでそれらを試してみてください。

* `mkdir` — これにより、現在のディレクトリー内に新しいディレクトリーが作成され、コマンド名の後に指定した名前が付けられます。たとえば、 `mkdir my-awesome-website` は `my-awesome-website` という名前の新しいディレクトリーを作成します。
* `rmdir` — 指定されたディレクトリーを削除しますが、それが空の場合のみです。たとえば、 `rmdir my-awesome-website` は上で作成したディレクトリーを削除します。空ではないディレクトリーを削除したい場合 (およびそこに含まれるすべてのものも削除したい場合)、`-r` オプション (再帰的) を使用できますが、これは危険です。ディレクトリーは永久に失われるため、後でディレクトリー内に必要なものがないことを確認してください。
* `touch` — 現在のディレクトリー内に新しい空のファイルを作成します。たとえば、`touch mdn-example.md` は `mdn-example.md` という新しい空のファイルを作成します。
* `mv` — 最初に指定されたファイルの場所から 2 番目に指定されたファイルの場所にファイルを移動します。たとえば、 `mv mdn-example.md mdn-example.txt` (場所はファイルパスとして書き込まれます)。このコマンドは、`mdn-example.md` 現在のディレクトリーにあるファイルに `mdn-example.txt` 現在のディレクトリーに。技術的にはファイルは移動されていますが、実用的な観点から見ると、このコマンドは実際にはファイルの名前を変更しています。
* `cp` — 使い方は `mv` と似ていますが、`cp` は指定された最初の場所と 2 番目に指定された場所にファイルのコピーを作成します。たとえば、`cp mdn-example.txt mdn-example.txt.bak` は、`mdn-example.txt.bak` という名前の `mdn-example.txt` のコピーを作成します (もちろん、必要に応じて別の名前にすることもできます）。
* `rm` — 指定されたファイルを削除します。たとえば、 `rm mdn-example.txt` は `mdn-example.txt` という単一のファイルを削除します。この削除は永続的であり、デスクトップユーザーインターフェイスにあるごみ箱から元に戻すことはできないことに注意してください。

**メモ:** 多くの端末コマンドでは、アスタリスクを「ワイルドカード」文字として使用できます。これは、「任意の文字列」を意味します。これにより、潜在的に多数のファイルに対して一度に操作を実行でき、そのすべてが指定されたパターンに一致します。例として、 `rm mdn-*` は `mdn-` で始まるすべてのファイルを削除します。`rm mdn-*.bak` は、 `mdn-`で始まり `.bak` で終わるすべてのファイルを削除します。

ターミナル — 有害と見なされますか?
-------------------

これについては以前にも言及しましたが、明確にするために、端末には注意する必要があります。単純なコマンドにはそれほど危険はありませんが、より複雑なコマンドをまとめ始めるときは、そのコマンドが何をするかを慎重に検討し、目的のディレクトリーで最終的に実行する前に、最初にそれらをテストする必要があります。

 ディレクトリーに 1000 個のテキストファイルがあり、それらすべてを調べて、ファイル名の中に特定の部分文字列を含むものだけを削除したいとします。注意しないと、重要なものを削除してしまい、その過程で作業の負荷が失われる可能性があります。
 良い習慣の 1 つは、端末コマンドをテキストエディター内に書き出し、それがどのように表示されるかを考え、ディレクトリーのバックアップコピーを作成し、最初にそのコマンドを実行してテストすることです。

もう 1 つのヒント — 自分のマシンでターミナルコマンドを試すのが苦手な場合は、 Glitch.com で安全に試すことができます。プロジェクトは、ウェブ開発コードを試すのに最適な場所であるだけでなく、端末へのアクセスも提供するため、これらすべてのコマンドをその端末で直接実行できます。自分のマシンを壊すことはないので安全です。

![a double screenshot showing the glitch.com home page, and the glitch terminal emulator](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line/glitch.png)

tldr.sh は、特定の端末コマンドの概要をすばやく把握するための優れたリソースです。これはコミュニティ主導のドキュメンテーションサービスで、MDN に似ていますが、ターミナルコマンドに固有です。

次のセクションでは、それを 1 段階 (実際には数段階) 上げて、コマンドラインでツールを接続する方法を見て、通常のデスクトップユーザーインターフェースよりもターミナルがどのように有利になるかを実際に見てみましょう。

コマンドをパイプで接続する
-------------

`|` (パイプ) 記号を使用してコマンドを連鎖させ始めると、ターミナルは真価を発揮します。これが何を意味するかの非常に簡単な例を見てみましょう。

現在のディレクトリーの内容を出力する `ls` については既に説明しました。

```bash
ls
```

しかし、現在のディレクトリー内のファイルとディレクトリーの数をすばやくカウントしたい場合はどうでしょうか? `ls` だけではできません。

`wc` と呼ばれる利用可能な別の Unix ツールがあります。これは、入力されたものの単語、行、文字、またはバイトの数をカウントします。これはテキストファイルである可能性があります — 以下の例は、`myfile.txt` の行数を出力します。

```bash
wc -l myfile.txt
```

しかし、**パイプ**された出力の行数をカウントすることもできます。たとえば、以下のコマンドは、`ls` コマンドによって出力された行数 (通常、単独で実行した場合に端末に出力されるもの) をカウントし、代わりにそのカウントを端末に出力します。

```bash
ls | wc -l
```

`ls` は各ファイルまたはディレクトリーをそれぞれの行に出力するため、実質的にディレクトリーとファイルの数がわかります。

それで、ここで何が起こっているのか？ (unix) コマンドラインツールの一般的な考え方は、テキストを端末に出力することです (「標準出力への出力」または `STDOUT` とも呼ばれます)。多くのコマンドは、ストリーム入力 (「標準入力」または `STDIN` として知られている) からコンテンツを読み取ることもできます。

パイプ演算子は、これらの入力と出力を一緒に *接続* できるため、ニーズに合わせてますます複雑な操作を構築できます — 1 つのコマンドからの出力が次のコマンドへの入力になる可能性があります。この場合、`ls` は通常その出力を `STDOUT` に出力しますが、代わりに `ls` の出力は `wc` にパイプされます。代わりに、そのカウントを `STDOUT` に出力します。

もう少し複雑な例
--------

もう少し複雑なことを見てみましょう。

 最初に、MDN の「fetch」ページ `https://developer.mozilla.org/docs/Web/API/WindowOrWorkerGlobalScope/fetch` を `curl` コマンド (URL からコンテンツを要求するために使用できる) を使用してコンテンツを取得します。
 やってみよう:

```bash
curl https://developer.mozilla.org/docs/Web/API/WindowOrWorkerGlobalScope/fetch
```

 ページが (/Web/API/fetch に) リダイレクトされているため、出力は得られません。
 `-L` フラグを使用してリダイレクトに従うように `curl` に明示的に指示する必要があります。

また `curl` の `-I` フラグを使用して `developer.mozilla.org` が返すヘッダーを見て、 `curl` の出力を `grep` にパイプすることにより、ターミナルに送信されるすべてのロケーションリダイレクトを出力します。(「 location」という単語を含むすべての行を返すように `grep` に依頼します)。

以下を実行してみてください (最終ページに到達する前にリダイレクトが 1 つだけあることがわかります)。

```bash
curl https://developer.mozilla.org/docs/Web/API/WindowOrWorkerGlobalScope/fetch -L -I | grep location
```

出力は次のようになります (`curl` は最初にいくつかのダウンロードカウンターなどを出力します)。

```bash
location: /en-US/docs/Web/API/fetch
```

 人為的ではありますが、この結果をもう少し進めて `location:` 行の内容を変換し、それぞれの先頭に基本オリジンを追加して、完全な URL を出力できるようにすることができます。
 そのために、`awk` をミックスに追加します (これは、JavaScript や Ruby、Python に似たプログラミング言語で、はるかに古いものです!)。

これを実行してみてください:

```bash
curl https://developer.mozilla.org/docs/Web/API/WindowOrWorkerGlobalScope/fetch -L -I | grep location | awk '{ print "https://developer.mozilla.org" $2 }'
```

最終的な出力は次のようになります:

```bash
https://developer.mozilla.org/en-US/docs/Web/API/fetch
```

 これらのコマンドを組み合わせることで、`/docs/Web/API/WindowOrWorkerGlobalScope/fetch` URL をリクエストしたときに Mozilla サーバーがリダイレクトしている完全な URL を表示するように出力をカスタマイズしました。
 システムを理解することは、今後何年にもわたって役立つことが証明されます。これらの単一サービスツールがどのように機能し、ニッチな問題を解決するツールキットの一部になることができるかを学びましょう。

パワーアップの追加
---------

システムに組み込まれている組み込みコマンドのいくつかを見てきたので、サードパーティの CLI ツールをインストールしてそれを利用する方法を見てみましょう。

 フロントエンドウェブ開発用のインストール可能なツールの広大なエコシステムは現在、主に npm 内に存在します。これは、Node.js と密接に連携する個人所有のパッケージホスティングサービスです。
 これは徐々に拡大しています — 時間が経つにつれて、より多くのパッケージ プロバイダーが表示されることが期待できます。

Node.js をインストールすると、 追加のコマンドラインツールをインストールするためのゲートウェイを提供する npm コマンドラインツール (および npx と呼ばれる補助的な npm 中心のツール) もインストールされます。Node.js と npm は、macOS、Windows、および Linux のすべてのシステムで同じように機能します。

上記の URL にアクセスし、お使いのオペレーティングシステムに適した Node.js インストーラーをダウンロードして実行することにより、今すぐシステムに npm をインストールします。プロンプトが表示されたら、必ず npm をインストールの一部として含めてください。

![the Node.js installer on windows, showing the option to include npm](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line/npm-install-option.png)

 次の記事以降ではさまざまなツールを見ていきますが、Prettier について詳しく説明します。
 Prettier は、「いくつかのオプション」しかない独自のコード フォーマッタです。
 オプションが少ないほど、シンプルになる傾向があります。
 複雑さの点でツールが手に負えなくなることがあることを考えると、「選択肢が少ない」ことは非常に魅力的です。

### CLI ツールをどこにインストールしますか?

Prettier のインストールに飛び込む前に、答えるべき質問があります — 「どこにインストールすればよいですか?」

`npm` を使用すると、ツールをグローバルにインストールする (どこからでもアクセスできるようにする) か、現在のプロジェクトディレクトリーにローカルにインストールするかを選択できます。

それぞれに長所と短所があります。グローバルにインストールする場合の以下の長所と短所のリストは、すべてを網羅しているわけではありません。

**グローバルにインストールする利点:**

* 端末のどこからでもアクセス可能
* 一度だけインストール
* 使用するディスク容量が少ない
* 常に同じバージョン
* 他の UNIX コマンドと同じ感覚

**グローバルにインストールすることの短所:**

* プロジェクトのコードベースと互換性がない可能性があります。
* チーム内の他の開発者は、これらのツールにアクセスできません。たとえば、git などのツールでコードベースを共有している場合です。
* 前のポイントに関連して、プロジェクトコードの複製が難しくなります (ツールをローカルにインストールする場合、ツールを依存関係として設定し、`npm install` でインストールできます)。

*cons* リストは短くなりますが、グローバル インストールのマイナスの影響は、メリットよりもはるかに大きい可能性があります。
 ここではローカルにインストールしますが、相対的なリスクを理解したら、自由にグローバルにインストールしてください。

### Prettier のインストール

Prettier は、JavaScript ベースの言語に焦点を当て、HTML、CSS、SCSS、JSON などのサポートを追加するフロントエンド開発者向けの独自のコードフォーマットツールです。

Prettier のできること:

* すべてのコードファイルで一貫したスタイルを手動で取得するための認知的オーバーヘッドを節約します。Pretier はこれを自動的に行うことができます。
* ウェブ開発の初心者がベストプラクティスの方法でコードをフォーマットできるようにします。
* 任意のオペレーティングシステムにインストールでき、プロジェクトツールの直接の一部としてもインストールできます。これにより、コードに取り組む同僚や友人が、あなたが使用しているコードスタイルを確実に使用できるようになります。
* 保存時、入力時、またはコードを公開する前に実行するように構成します (モジュールの後半で説明する追加のツールを使用)。

この記事では、Prettier インストールガイド で提案されているように、Prettier をローカルにインストールします。

ノードをインストールしたらターミナルを開き、次のコマンドを実行して Prettier をインストールします。

```bash
npm install prettier
```

npx ツールを使用して、ファイルをローカルで実行できるようになりました。
 他の多くのコマンドと同様に、引数を指定せずにコマンドを実行すると、使用方法とヘルプ情報が表示されます。
 これを試してください:

```bash
npx prettier
```

出力は次のようになります。

```bash
Usage: prettier [options] [file/glob ...]

By default, output is written to stdout.
Stdin is read if it is piped to Prettier and no files are given.

…
```

 たとえそれが長くても、少なくとも使用法情報に目を通すことは常に価値があります。
 ツールがどのように使用されることを意図しているかをよりよく理解するのに役立ちます。

**メモ:** 最初に Prettier をローカルにインストールしていない場合、`npx prettier` を実行すると、*そのコマンドだけ*で、Prettier の最新バージョンがダウンロードされて実行されます。
 素晴らしいと思われるかもしれませんが、Prettier の新しいバージョンでは出力がわずかに変更される場合があります。
 ローカルにインストールして、フォーマットに使用している Prettier のバージョンを変更する準備が整うまで修正します。

### Prettier を始める

Prettier で簡単に実行して、どのように機能するかを見てみましょう。

まず、ファイルシステムの見つけやすい場所に新しいディレクトリーを作成します。`Desktop` の `prettier-test` というディレクトリーかもしれません。

次のコードを test ディレクトリー内の `index.js` という名前の新しいファイルに保存します。

```js
const myObj = {
a:1,b:{c:2}}
function printMe(obj){console.log(obj.b.c)}
printMe(myObj)
```

コードベースに対して Prettier を実行して、コードの調整が必要かどうかを確認できます。ディレクトリーに `cd` して、次のコマンドを実行してみてください。

```bash
npx prettier --check index.js
```

次の行に沿って出力されるはずです:

```bash
Checking formatting...
index.js
Code style issues found in the above file(s). Forgot to run Prettier?
```

それで修正できるコードスタイルがいくつかあります。大丈夫です。`prettier` コマンドに `--write` オプションを追加すると、これらの問題が修正され、有用なコードを実際に書くことに集中できるようになります。

次のバージョンのコマンドを実行してみてください。

```bash
npx prettier --write index.js
```

このような出力が得られます。

```bash
Checking formatting...
index.js
Code style issues fixed in the above file(s).
```

しかしもっと重要なことは、JavaScript ファイルを振り返ると、次のように再フォーマットされていることがわかります。

```js
const myObj = {
  a: 1,
  b: { c: 2 },
};
function printMe(obj) {
  console.log(obj.b.c);
}
printMe(myObj);
```

ワークフロー (または選択したワークフロー) によっては、これをプロセスの自動化することができます。自動化は、ツールが優れているところです。私たちの個人的な好みは、何も構成する必要なく「ただ起こる」ような自動化です。

Prettier を使用すると、自動化を実現する方法がいくつかあります。それらはこの記事の範囲を超えていますが、役立つオンラインの優れたリソースがいくつかあります (その一部はリンクされています)。Prettier を呼び出すことができます:

* git リポジトリーにコミットする前に Husky を使用します。
* コードエディターで「保存」をクリックするたびに使用します。VS Code または Sublime Text。
* GitHub Actions などのツールを使用した継続的な統合チェックの一環として使用します。

私たちの個人的な好みは 2 番目のものです。たとえば、VS Code を使用しているときに、Prettier が起動し、保存するたびに必要なフォーマットをクリーンアップします。Prettier docs で、さまざまな方法で Prettier を使用する方法についてさらに多くの情報を見つけることができます。

その他の実行ツール
---------

さらにいくつかのツールを試してみたい場合は、試してみるのが楽しいツールの簡単なリストを次に示します。

* `bat` — 「より良い」`cat` (`cat` はファイルの内容を出力するために使用されます)。
* `prettyping` — コマンドラインでの `ping` ですが、視覚化されています (`ping` は、サーバーが応答しているかどうかを確認するための便利なツールです)。
* `htop` — プロセスビューアー。何かが原因で CPU ファンがジェットエンジンのように動作し、問題のプログラムを特定したい場合に役立ちます。
* `tldr` — この章で前述しましたが、コマンドラインツールとして使用できます。

上記の提案のいくつかは、Prettier で行ったように npm を使用してインストールする必要がある場合があることに注意してください。

まとめ
---

これでターミナル/コマンドラインの簡単なツアーは終了です。次はパッケージマネージャーで何ができるかについて詳しく見ていきます。

* 前のページ
* Overview: Understanding client-side tools
* 次のページ