1 Webの技術とは（後半）
06 Webページが表示される流れ
●URLを使ってWebサーバーにアクセス
1 URLで取得したWebページをWebブラウザに指定する
URLには「どの手順で」、「どのWebサーバーに」、「何のコンテンツを」取りに行くかという情報が含まれている
2 Webブラウザは指定されたURLを元に、Webサーバーからコンテンツ（HTMLファイル）を転送してもらう
3 Webブラウザでコンテンツを解釈して人間が見やすいように整形して表示する
4 HTMLの解釈の結果、画像などの他のファイルが必要になったときは、再度Webサーバーからそのファイルを転送してもらってHTMLの表示画面にはめ込む
07静的ページと動的ページ
●静的ページ
何度アクセスしても毎回同じものが表示されるWebページ
例：会社のホームページ
●動的ページ
アクセスしたときの状況に応じて異なる内容が表示されるWebページ
例：Twitter
08動的ページの仕組み
WebサーバーがWebブラウザからの要求に応じてプログラムを起動させるための仕組み
この仕組みのおかけでWebページから同じ要求が送られてきても、Webサーバーから毎回異なったコンテンツを送信することができる
●サーバーサイド・スクリプト
CGIから呼び出されるプラグラム
一般的には文字列の扱いに長けたスクリプト言語で記載される
●クライアントサイド・スクリプト
Webブラウザによって読み込まれる際に実行されるプログラム
主にJavaScriptで記載される
09 Webの標準化
●なぜ標準化するのか？
Webブラウザの機能拡張をそれぞれの開発者が独自に行ってしますと複雑になってしまうため
●標準化を進める団体
W3C（World Wide Web Consortium）
10 Webの設計思想
●Restful
「RESTの原則」を守って設計されたWebシステム
1 統一インターフェース：あらかじめ定義・共有された方法で情報がやりとりされる
2 アドレス可能性：全ての情報が一意なURLの構文で示される
3 接続性：やりとりされる情報はリンクを含めることができる
4 ステートレス性：やりとりは一回ごとに完結し、前のやりとりの結果に影響されない
多くのWebアプリケーションがRestfulになるように設計されている
ティム・バーナーズ＝リーが提唱している構想
Webページの情報に意味（セマンティック）を付け加えたもの
既存のWebページでは不可能な技術のため、Web全体への普及はまだまだ先である
担当：やし
Chapter1 Web技術とは（01〜05）p.11
01 Webとは
web：正式名称はWorld Wide Web（世界に広がるクモの巣）。WWWとも。
文書の公開・閲覧のためのシステム。
Web上の文章（Webページ）はハイパーテキストと呼ばれる言語で構成されている。
→1つのWebページを複数のWebページと関連付けることで、全体で大きな情報の集合体とすることができる。
●世界中の情報をクモの巣状に関連づける
Webの大きな特徴：Webページ同士がリンクして別のWebページへとつながっていること。
02 インターネットとweb
インターネットとWebは、元々別の目的のために開発された。
各国の実験者がすぐに情報へアクセスできるようにするため開発。
ENQUIRE（Webの原型）→World Wide Web（改良型）
開発者のティム・バーナーズ＝リーはその後、自身でWebブラウザとWebサーバーを開発し、
インターネット上で公開を始めた。
●インターネットの普及に貢献
ARPANET（原型）→インターネット（拡大・通信方法見直し後の呼称）
Webはインターネットで使えるシステムの一つ。
03 さまざまなwebの用途
●文書の閲覧
Webサイト：1つのドメインにある複数のWebページの集まり。
Webページ同士はハイパーリンクによって相互につながっている。
ユーザーインターフェース：コンピューターの機能とユーザーのやりとりの橋渡しをする機能
ユーザーの操作の橋渡しを行う。
●プログラム用API
API：アプリケーションプログラミングインターフェース。
ソフトウェア同士のやりとりの橋渡しをする機能。
スマートフォンのアプリのデータ送受信の処理によく使われる。
04 HTMLとWebブラウザ
●記述言語HTML
HTMLで記述された文書をコンテンツと呼ぶ。
タグ：文章の表示方法やハイパーリンクを表現するためのマーク。
●表示プログラムWebブラウザ
05 WebサーバーとHTTP
●配置プログラム Webサーバー
コンテンツはWebサーバーによって配信されることでWebページと呼ばれるようになる。
●やりとりの手順 HTTP
HTTP：HyperText Transfer Protocol。世界共通のハイパーテキストのやりとりの手順。
Webページの表示手順
担当：やし
14章『テストと読みやすさ』P.179
14章における「テスト」……他の（「本物」の）コードの振る舞いを確認するためのすべてのコードのこと
14.1 テストを読みやすくて保守しやすいものにする(P.180)
テストコードを読みやすくすることは大切。本物のコードの動作が理解しやすくなる。
テストコードは「本物のコードの動作と使い方を示した非公式的な文書」といえる。
鍵となる考え
他のプログラマが安心してテストの追加や変更ができるように、テストコードを読みやすくする。
ダメなテストコードが引き起こすこと
- 本物のコードを修正することを恐れる
- 新しいコードを書いたときにテストを追加しなくなる
テストコードを変更したことで既存のテストが壊れたとしても、簡単に原因が突き止められるなら安心してテストを追加できるようになる。
14.2 このテストのどこがダメなの？(P.180)
実例
14.3 テストを読みやすくする(P.181)
14.2の解説。
大切ではない詳細はユーザから隠し、大切な詳細は目立つようにするべき。
- 最小のテストを作る
⇨コードが簡潔で読みやすくなる。テストケースの追加が簡単になる。
- 独自の「ミニ言語」を実装する
14.4 エラーメッセージを読みやすくする(P.185)
エラーメッセージはできるだけ役に立つようにするべき。
- もっといいassert()を使う
どの言語を使っていても、役立つライブラリやフレームワーク（xUnitなど）がきっとある。ライブラリのことを知っておこう！
- 手作りのエラーメッセージ
14.5 テストの適切な入力値を選択する(P.188)
テストの適切な入力値を選択するには優れた技能が必要。
適切な入力値＝コードを完全にテストするもの かつ 簡単に読めるような単純なもの
鍵となる考え
コードを完全にテストする最も単純な入力値の組み合わせを選択しなければいけない。
- 入力値を単純化する
テストには最もキレイで単純な値を選ぶ。
- 1つの機能に複数のテスト
○小さなテストを複数作る
簡単で効果的で読みやすい。
複数のテストで別々の方向からバグを見つけ出すようにする。
テストケースが分割されていれば、次の人がコードを扱いやすくなる。
意図せずにバグを発生させたとしても、失敗したテストによってその場所がわかる。
14.5 テストの適切な入力値を選択する（P188）
・コードを完全にテストする最も単純な入力値の組み合わせを選択しなければならない。
→テストコードを書く際、最もキレイで単純な値を選ぶ
・1つの機能に複数のテスト
→小さなテストを複数作る方が単純で読みやすい
例：ソート、重複は許可
14.6 テストの機能に名前をつける（P190）
・テストコード（関数）に名前をつける
例：Test_SortAndFilterDocs() など
その際、名前が長くなっても良い。コメントだと思えば良い。
14.7 このテストのどこがダメだったのか？（P192）
具体例だったので飛ばす
14.8 テストに優しい開発（P194）
テストコードを書くつもりでコードを書くと、
テストしやすいコードを設計しやすいようになり、いいコードが書けるようになる。
14.9 やりすぎ
テストに集中しすぎる可能性もあるので注意する。
・テストのために本物のコードの読みやすさを犠牲にしてしまう。
・テストのカバレッジを100%しないと気がすまない。
・テストがプロダクト開発の邪魔になる。
担当：やし
13章 短いコードを書く（P168）
#キーとなる考え方
最も見やすいコードは、何も書かれていないコードだ
##その機能の実装について悩まないで（きっと必要ないから）
エンジニアいうのは、見積を過小評価するため、
プロジェクトに欠かせない機能を過剰に必要だと錯覚する。
##質問と要求の分割
要求事項を詳しく調べていれば、機能を簡単にすることができる。
##コードを小さく保つ
プロジェクトが大きくなるにつれてコードが増えていき、
管理はしづらくなっていくが、コードはなるべく小さく軽量に維持する。
そのために以下のことを実践すると良い。
・汎用的な「ユーティリティ」コードを作って、重複コードを削除する。
・未使用のコードや無用な機能を削除する。
・プロジェクトをサブプロジェクトに分割する。
・コードの「重量」を意識する。軽量にする。
##身近なライブラリに親しむ
たまには標準ライブラリの全ての関数・モジュール・型の名前を15分読んでみよう。
ライブラリを再利用することによって時間の節約になるし、書くコードも少なくなる。
Unixでコマンドを打つだけで良い。（ソースを書くより簡単だということ）
担当：らうみー
12章『コードに思いを込める』P.157
コードは簡単な言葉で書くべき
---
手順
- コードの動作を簡単な言葉で同僚にも分かるように説明する。
- その説明のなかで使っているキーワードやフレーズに注目する。
- その説明に合わせてコードを書く。
---
12.1 ロジックを明確に説明するP.158
具体例:説明することで解決策を思いつくことがある。
12.2 ライブラリを知るP.159
具体例:説明をもとにコードを書き直すと、人間がどのように考えるかを重視したコードにできる。
簡潔なコードを書くのに欠かせないのは、ライブラリの有効活用。何を提供してくれるかを知るのが大事。
12.3 この手法を大きな問題に適用するP.161
具体例:やりたいことを簡単な言葉で説明→書き換え→やりたいことを簡単な言葉で説明→書き換え
繰り返すことでコードはどんどんキレイになる。
12.4 まとめP.165
プログラムのことを簡単な言葉で説明することで、コードがより自然になっていく。
問題や設計をうまく言葉で説明できないのであれば、何かを見落としているか、詳細が明確になっていないということ。
関連:ラバーダッキング
担当：やし
11章『一度に１つのことを』P.143
一度に複数のことを行うコードは分かりづらい
■コードは１つずつタスクを行うようにする
手順
- コードが行っている「タスク」をすべて列挙
- タスクをできるだけ異なる関数に分割する（少なくとも異なる領域に分割する）
11.1 タスクは小さくできる(P.145)
一目見ただけではわからないコードは、複数のタスクを同時に行っている場合がある
複数のタスクを別々に解決する→読みやすいコードになる
具体例（JS）
スコアを更新するコードと見せかけて２つのタスクを内包
- old_voteとnew_voteを数値に「パース（解析）する」
- scoreを更新する
11.2 オブジェクトから値を抽出する(P.147)
タスクを分割する→コードが分かりやすくなる→リファクタリングしやすくなる
具体例（JS）
まずはタスクを書き出す→関数または領域で分けて個別に解決していく
11.3 もっと大きな例(P.151)
具体例（JS）
もっと長いコードでも同じ
タスクを書き出す→関数または領域で分ける（他の領域のことを考えずに済む）
11.4 まとめ(P.155)
タスクを分割することが大事
読みにくいコードがある→そこで行われているタスクをすべて列挙
→別の関数（やクラス）に分割
→分割できないものは関数の論理的段落といえる
担当：やし
10章 無関係の下位問題を抽出する P129
#キーとなる考え方
無関係な下位問題を抽出することだ
つまりプロジェクト固有のコードから汎用コードを分離することだ
以下に考え方を記載する
1. 関数やコードブロックをみて、このコードの高レベルの目標は何か？を自問自答する
2. コードの各行に対して高レベルの目標に直接的に効果があるのか？あるいは無関係の
下位問題を解決しているのか？自問自答する
3.無関係の下位問題を解決しているコードが相当量あれば、それらを抽出して別の関数にする
##入門的な例
このコードの高レベルの目標は何かを考える
→低レベルの問題は関数かしてしまう
例 与えられた地点からもっとも近いところを探す 高レベルの目標
その中の処理で2つの地点の球面距離を算出するは、別の関数にまとめると良い
##純粋なユーティリティコード
プログラムの基本的な核となるコードはライブラリにない場合、
関数にまとめる
例 ファイルの読み込みなど
##その他汎用コード
無関係な下位問題は関数にまとめる
##思いも寄らない恩恵
コードが独立している場合、修正が簡単にできる
##汎用コードをたくさん作ることのメリット
プロジェクトから切り離されていることによって、
横展開が可能であり、テストも簡単になる
##プロジェクトに特化した機能
抽出する下位問題というのはプロジェクトから完全に独立したものである方がよいが、
下位問題を別の関数にまとめることに意味がある。
##既存のインターフェースを簡潔にする
汚いインターフェースは自分でラッパー関数を用意して覆い隠す
##やりすぎ
やりすぎるとよくない。関数を増やすことは読むコストが増える。
他の部分から再使用できるものであれば、関数を追加することに意味があるかもしれない。
担当：らうみー
