『Web技術の重要用語解説』書評
エンジニアになってからの最初の一年間は、とにかく動くコードを書く事に必死だった。それ以外の事はどうでも良かった。
自分が使う言語、フレームワーク、DB以外の技術を学習する事は、無駄とは言わないまでも、優先度は低いと思っていた。
ましてや、それがコーディングに直ぐには役立たない「即効性の低い」知識ならば尚更だった。
HTTP？ああ、URLの頭に付いてるやつね。ステータスコード？何それ？あ、404なら知ってるよ。リンク切れの時に出てくるやつでしょ？
TCP/IP？SSH？おいおいやめてくれ！そんなのインフラ屋が知ってればいいんだよ！俺はプログラマーなんだ！
出来るだけバグの少ないコードを出来るだけ早く書く！それが俺らの仕事で、それ以外の事は後回しでいいんだ！
そんな調子で、Webエンジニアとして当然知っていなければならない知識の学習は後回しにしていた。当然社内での評価は低かった。
また、「動くコードが書ければいい」の精神で書いたコードは悉く正常に動作しなかった。
今思えば当たり前だった。Webエンジニアを名乗りながら、「Web」とは何なのかさえ知らなかったのだから。
エンジニアとしてのキャリアが３年目に差し掛かった今、少しずつHTTPやインフラ寄りの知識の重要性が分かってきた。
レスポンスのステータスコードの意味が分かっていれば、不具合が起こった時に何処に原因があるか当たりを付けられるし、
自分達が作ってるシステムがロードバランサー付きのサーバ２台構成と知っていれば、
どうして処理を実行してもログが出力されないのかが分かる(別のサーバに切り替わってる)。
何より、今作ってるシステムのアーキテクチャや動作の仕組みを理解していれば、
他のエンジニアとの意思疎通もスムーズになるし、信頼もされやすくなる。
そして、自分が受け持っている仕事の手戻りも少なくなる。
基礎技術の重要性を理解し始めた今、１から学習を始めようと思って、この本を読んだ。
感想
普段何となくで理解しているWeb技術の知識が、一言でビシっと説明されていて分かりやすかった。
初歩的な説明が多いが、中堅エンジニア(業務歴3～5年)でも正確に把握していないだろう知識もチラホラ紹介されていた。
以下の質問の中に答えられないものがあったら、読んでみる価値がある。
採用面接だと思って答えてみて欲しい。実際、面接でWebの基礎知識への理解を問われる事は多いようだ。
Q: Webって何？
「WWW」の略。インターネットを介してコンテンツを公開、または閲覧する仕組み。
Q: Webを構成する３つの技術は？
URL、HTML、HTTP
Q: DOMとは？
アプリケーションからHTMLやXMLを操作する仕組み。
Q: HTTPステータスコードで使用される頻度の高いものを挙げよ。
| コード | 内容 | 詳細 |
|---|---|---|
| 200 | OK | リクエスト成功 |
| 201 | CREATED | リクエストに成功し、新しいコンテンツを作成した |
| 301 | Moved Permanently | 指定のURIは別のURIに移転している |
| 302 | Found | 指定のURIは一時的に別のURIに移転している |
| 304 | Not Modified | 指定のURIは更新されていない |
| 401 | Unauthorized | 指定のURIはユーザ認証を必要とする |
| 403 | Forbidden | サーバにリクエストを拒否された |
| 404 | NOt Found | 指定のURIは存在しない |
| 500 | Internal Server Error | サーバで予期しないエラーが発生した |
| 503 | Service Unavailable | サーバに一時的に不可がかかっているため、結果を返すことができない |
Q: サーバはどうやってセッション管理してる？
サーバはユーザ毎にセッションIDを割り当てて保存し、CookieとしてIDをクライアントに送信
↓
クライアントはリクエスト毎にCookieを送信
↓
サーバはCookieのIDを元にユーザを識別する。
Q: クエリパラメータでパスワードを送るのは何故危険？
Q: ポート番号は何のために使用される？
サーバ上で稼働しているどのプログラムと通信するかを特定するため
Q: Well-Knownポート番号で使用される頻度の高いものを挙げよ
| ポート | プロトコル | 詳細 |
|---|---|---|
| 20 | FTP | ファイルを他のサーバに転送する |
| 21 | FTP | 同上。20はデータ転送用。21は制御用 |
| 22 | SSH | 暗号化された安全なリモート通信 |
| 23 | TELNET | 端末間、プロセス間での通信 |
| 25 | SMTP | メールを転送する |
| 53 | DNS | ドメインからIPアドレスを問い合わせる |
| 80 | HTTP | Web通信 |
| 110 | POP3 | メールを受信する |
| 143 | IMAP | 電子メールを操作する |
| 443 | HTTPS | 暗号化を伴うWeb通信 |
Q: Webサーバって？
HTTPリクエストに対して、レスポンスを返すサーバ
Q: Apacheの公開領域フォルダは？
htdocs
Q: RDBにおける正規化とは？
重複したデータの発生を防ぐ仕組み
Q: JavaのWebアプリケーションでよく使用されるLog4Jのロギングレベルは？
| ログレベル | 概要 |
|---|---|
| DEBUG | デバッグ時に参考になる詳細な情報 |
| INFO | プログラムの実行情報(メソッドの入出力など) |
| WARN | 処理が止まるほどではないレベルで問題が起きた際の警告 |
| ERROR | エラー |
| FATAL | 致命的なエラー |
Q: スケールアップとスケールアウトの違いは？
スケールアップ…サーバの性能をUP
スケールアウト…サーバの台数を増やす
リファレンス
「基礎の初歩」が学び終わったら、実際に「基礎」を学んでみよう。
RFC(Request For Comment)というインターネット上に公開されている文書が、Web技術における正式なドキュメントとなる。
つまり、このドキュメントが「基礎」という訳だ。
Webエンジニアなら、少なくとも以下の二つは読んだ方がいいと思う。
このような技術に関する正式なドキュメントは基本的に英語で書かれているし、難解で取っつきにくい印象を抱きがちだが、
実際は理解しやすいように分かりやすく書かれてる。
日本語約された文書もあるけど、まずは原文を読んでみる事をすすめる。
先述の通り、Web技術の正式なドキュメントは基本的に全部英語だから、英語を読んで理解する事に慣れた方が良い。
それに、個人的な意見だが、日本語で書かれた技術文書は、英語で書かれたものより難解で取っつきにくい傾向にある。
息抜きがてら、以下のエイプリルフールに公開されたジョークRFCを読んでみると面白いかもしれない。
優秀なエンジニアの笑いのセンスがどんなものか分かる。
| No. | 概要 |
|---|---|
| RFC 1149 - Standard for the transmission of IP datagrams on avian carriers | 伝書鳩などの鳥類を利用してデータ転送を行うという、ものすごく時間のかかる、まったく実用的でない通信手段の提案 |
| RFC 2322 - Management of IP numbers by peg-dhcp | DHCPのIPアドレス管理を選択ばさみを使って実現するという不毛な仕組み |
| RFC 2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) | コーヒーポットをHTTPを使って操作する方法を提案した、どうでもいい文書 |
| RFC 3514 - The Security Flag in the IPv4 Header | 他者を攻撃するような悪意を持った通信をする際は、「evil bit」と呼ばれるフラグを立てなければならないという、誰も守らないこと請け合いな仕組み |
