Web技術基礎 for インターン
 2021.09.13

　 2 ● 慶應SFC大学院 → 新卒でゲーム系ベンチャー
 → 新卒1年目の1月からfreee
 ○ この頃のfreeeは20人弱の小さな会社
 ● freeeで5年半エンジニア
 → 2019年7月からデザイナー
 ● エンジニアとして、freee会計の経費精算とか
 freee人事労務のいろいろを作ってました
 ● freee社内のデザインシステム整備とか、
 アクセシビリティ向上とかをやりながら、
 UI/UXデザインの仕組みを作ってます
 ● 1年半くらいこの姿で仕事してます
 
 ＠ymrl
 UXデザイナー / アプリケーションエンジニア
 山本 伶


3 ● 現代のWebアプリやモバイルアプリの仕組みをざっくり理解するのが目的
 ○ 今回のインターンに（たぶん）役立つだろうと思っています
 ● ある程度経験ある人にとっては当たり前の内容も多いので、
 みなさんの反応を見ながら部分的に飛ばしたりするかもしれません
 ● 途中の演習は、共有ノート (Google Docs) に書き込んでください
 ● 知らないことは恥かしいことではないので、どんどん質問してください
 ○ あなたが質問すれば、他の人が質問しやすくなります
 ○ あなたの質問のおかげで、他の人も知識を得ることがあります
 ○ あなたの質問で、私の講義の足りない部分を見つけることができます
 この時間について


演習1


5 ● アドレスバーにURLを入力されてEnterキーを押したときに起きることを
 なるべく細かく書き出してみよう
 ○ 目に見える変化、見えない場所で起きていること
 ○ ブラウザの中で起きること、ブラウザの外で起きること
 ○ クライアント側で起きること、サーバーサイドで起きること
 ● TwitterやGitHubなど、具体的なWebサービスで想像してみてください
 ● 3分くらいでできる範囲で、なるべく細かく書いてみてください
 
 （ちなみにこれはエンジニアの採用面接の有名な質問だったりします）
 ブラウザやWebアプリがやっていることを書き出してみる


6 ● URLを解析して、ホスト名を抽出。DNSでIPアドレスを特定する
 ● 上記のサーバーに、URLがhttpsならHTTPSでリクエスト
 ● サーバーは受け取ったリクエストをもとにレスポンスを生成して返す
 ● ブラウザは受け取ったレスポンスをHTMLとして解析
 ● HTML内で参照されているCSSやJavaScriptや画像をリクエスト
 ● HTMLをレンダリング
 ● JavaScriptを実行して、さらに追加で通信して情報を取得、
 HTMLを書き換えてレンダリング
 演習1の解答例


7 ● Uniform Resource Locator 統一資源位置指定子
 ○ Web上の情報の位置を指定するための統一された書式
 ● https://example.com/path/to/resource?query=value#hash
 ○ https:// 暗号化されたHTTP (Hypertext Trasfer Protocol) を使い
 ○ example.com というサーバーの
 ○ /path/to/resource という資源（情報）に
 ○ query には value を指定してアクセスし
 ○ hash という部分を表示しろ
 URL


8 ● HTTP: Hypertext Transfer Protocol
 ○ Protocol: 通信のやり方の規格（Protocolは外交儀礼みたいな意味）
 ○ Webでデータをやり取りするのに使われる仕組み
 ● HTTPS は Secure な（暗号化された） HTTP
 ○ 暗号化されていないHTTPは通信経路上で盗聴できてしまう
 ○ HTTPなページは「保護されていない通信」と表示される
 ■ 阿部寛のホームページを見てみよう
 ○ Webサービスの提供にはHTTPSが必須
 HTTPとHTTPS


9 ● サーバー
 ○ ネットワーク越しにサービスを提供するコンピューター
 ○ あるいはそのコンピューター上でサービスを提供するソフトウェア
 ● クライアント
 ○ サーバーからのサービスを受ける側のコンピューター
 ○ あるいはそのコンピューター上のWebブラウザ
 ○ あるいはそのWebブラウザ内で動くソフトウェア
 ● サーバーサイド・クライアントサイドという呼び方がわかりやすいかも
 サーバーとクライアント


演習2


11 ブラウザのやっている通信を見てみよう
 ● 好きなWebページを開く
 ● Chromeメニューで「その他のツール」→「デベロッパーツール」を開く
 ● Networkタブを開く
 ● Clearボタン🚫を押した上で、ページを再読み込み
 ● たくさん通信してるのがわかるはず


12 ● Clearしてから通信して
 ● 通信をDocで絞り込んで、最初のリクエストを見てみる
 とりあえずページの最初のリクエストを見る


13 ● HTTPはリクエストに対するレスポンスによってやり取りをしている
 ○ クライアントからサーバーへリクエストを送信すると
 ○ サーバーからクライアントへレスポンスが返る
 ● リクエストとレスポンスは、それぞれ Header と Body がある
 ○ Header には Body のデータの形式や認証まわりの情報などが入る
 ○ Body にはやり取りするデータそのものが入る
 ■ リクエストの種類によっては Body がない場合も多い
 ■ レスポンスの状態によっては Body がない場合も多い
 HTTPのリクエストとレスポンス


14 ● リクエスト時に GET, POST, PUT, DELETE などのメソッドを指定する
 ○ 実際はほとんどの通信が GET と POST で行われている
 （歴史的経緯で、PUT や DELETE は後から追加された）
 ○ POST や PUT ではリクエストの Body としてデータを送信できる
 ● レスポンスには 200, 404, 301… のような状態 (Status) が表現される
 ○ リクエストされたリソースの状態を表現している
 ○ 2xx はリクエスト成功、4xxはクライアント起因のエラー、
 5xxはサーバー側のエラーのようなコード体系になっている
 HTTPステータスコード (Wikipedia)
 HTTPのリクエストの種類・レスポンスの状態


15 ● サーバーがブラウザに set-cookie という Header で情報を与えておくと
 次のリクエストでクライアントが cookie という Header で送ってくる
 ● Cookieはドメインごとに保存されている
 ● ユーザーを識別したり、ちょっとした設定を保存したりするのに使える
 ● デベロッパーツールのApplicationタブで一覧を見られる
 Cookie


16 ● HeaderやCookieを眺めてみよう
 ● 気付いたことをメモしてみよう
 演習2のつづき


17 ● WebページをリクエストするとレスポンスのbodyにHTMLが乗ってくる
 ● HTML と CSS
 ○ Webページは HTML (Hyper Text Markup Language) で描画される
 ○ Webページの見た目は CSS (Cascading Style Sheets) で修飾される
 ● Webブラウザが HTML を読み込むと、その中の CSS や画像や JavaScript など のアセットをリクエストして、それらを使ってページを表示する
 ページの表示


18 ● Webブラウザの上で動く唯一のプログラミング言語
 ● ブラウザの上で JavaScript が動くことで、快適なWebアプリが実現する
 ○ ページの一部分だけを書き換えられる
 ■ ユーザーの操作にすぐ反応することができる
 ■ ページ全体のHTMLを毎回リクエストしなくていい
 ● 最近のWebアプリは、ほぼ全てのUIをJavaScriptで構築したりする
 ○ Twitterがそうで、HTMLにはJavaScript not Availableって書いてある
 ○ Networkのリクエストを選択してPreviewを見てみよう
 
 JavaScript


19 ● JavaScript で書かれたプログラムがサーバーとの通信に使っている機能
 ○ もともとは XML 形式のデータをやり取りする機能なのでこんな名前
 ○ 実際にはいろんな形式のデータをやり取りできる
 ○ 最近では fetch API に取って替わられつつある
 ● Ajax: Asynchronous JavaScript And XML
 ○ 細かい単位で必要に応じてJavaScript が通信してページを書き換える
 ○ 2005年の造語（死語）
 ■ Google Maps や Gmail が画期的だった時代
 ■ 今ではもう当たり前のことなので、誰も Ajax とは言わなくなった
 XMLHttpRequest


20 ● JavaScript の通信に一般的に広く使われているデータ形式
 ○ JavaScript Object Notation
 ○ JavaScript だけでなく、いろんなプログラミング言語で使える
 ■ freeeのアプリのサーバー側では、Ruby で JSON を出力している
 ● HTMLではなく、JSONをやり取りするURLをAPIと呼んでいたりする
 ○ API = Application Programing Interface
 ○ HTMLは人間（ブラウザ）向け、JSONはアプリケーション向け
 ○ APIの仕様を公開しているサービスもある
 ■ freeeもやっている
 JSON


演習3


22 ● 開発者ツールの Network タブで Fetch/XHR で絞り込みをする
 ● その状態で、いろいろ操作をしてみる
 ○ フォームの送信とか
 ○ ページ遷移とか
 ● 発生した通信のHeaders, Preview, Responseを見てみる
 
 JavaScriptがやっている通信を見てみよう


23 ● JavaScript で書かれたプログラムが
 ○ サーバーから情報を取得する
 ○ HTML を書き換えて、UI を描画する
 ○ ユーザーの入力を受け取ったり、送信したりする
 ● ユーザーと サーバーの間に立って、ユーザーとのインタラクションと
 サーバーサイドとの通信を受け持つ役割
 ○ これを iPhone 上の Swift や Android 上の Kotlin でやっているのが
 モバイルのネイティブアプリ
 Webアプリケーションのクライアントサイド


24 ● クライアントサイドのブラウザ、 JavaScript、ネイティブアプリに向けて
 ○ ブラウザが表示する HTML を提供する
 ○ JavaScript やネイティブアプリが使うJSONを提供する
 ○ それらを作るためにデータベースに保存されている情報を取得したり
 送られてきた情報をデータベースに保存したりする
 ● 情報がサーバーサイドのデータベースに保存されているおかげで、
 どこからでも利用でき、ユーザー間で共有したりすることもできる
 ● サーバーサイドがいかに早くレスポンスを返すかはUXに大きく影響
 Webアプリケーションのサーバーサイド


25 ● サーバーサイドで情報を保存する方法は目的によって変わってくる
 ● Webアプリケーションで扱うほとんどの情報はDBMS (Database Management System) に保管しておくことが多い
 ○ 情報を高速に絞り込んだりしながら読み出したり書き込んだりできる
 ○ SQLという言語を使って操作するものが多い
 ■ MySQL, PostgreSQLなど
 ● 画像や動画などをファイルのまま保管するストレージのシステムもある
 ○ ファイル名を指定してアクセスする（検索はしない）
 ○ Amazon S3などが代表的
 データベース・ストレージ


26 ● 大昔のWebアプリ: 画面を書き変えるたびにHTMLを配信していた
 ○ 何かするたび毎回真っ白になってから描画されるので体験が悪い
 ● ひと昔前のWebアプリ: 画面の一部を JavaScript で書き換える
 ○ ページを跨ぐときだけ画面が真っ白になるが、わりと快適
 ○ サーバー・クライアントで同じようなことをすることになってしまう
 ● SPA: すべての UI を JavaScriptで描画する
 ○ ページを跨ぐときもすべてクライアント側だけの処理になる、爆速
 ○ フロントエンドはUIの構築、サーバーはデータの入出力に集中できる
 SPA: Single Page Application


27 ● イラスト図解式 この一冊で全部わかるWeb技術の基本
 ● ネットワークはなぜつながるのか 第2版
 ● Real World HTTP 第2版
 ○ Real World HTTP ミニ版
 ● Webを支える技術 -HTTP、URI、HTML、そしてREST
 
 もっと詳しく


28 ● Webにはどんな長所・短所があるのか考えてみよう
 ○ Webでは実現が難しいことは何があるだろう
 ○ それを別の手段で乗り越えているアプリはあるだろうか
 ● サーバーサイドとクライアントサイドのエンジニアが、
 それぞれ大事にしているものは何だろう
 ● 身近なWebサービスはどんな構成になっているのか、
 調べたり妄想したりしてみよう
 ディスカッション