俺には勉強しかない

幸運なことに、俺は文字が読める!

『Web技術の重要用語解説』書評

エンジニアになってからの最初の一年間は、とにかく動くコードを書く事に必死だった。それ以外の事はどうでも良かった。
自分が使う言語、フレームワーク、DB以外の技術を学習する事は、無駄とは言わないまでも、優先度は低いと思っていた。
ましてや、それがコーディングに直ぐには役立たない「即効性の低い」知識ならば尚更だった。

HTTP?ああ、URLの頭に付いてるやつね。ステータスコード?何それ?あ、404なら知ってるよ。リンク切れの時に出てくるやつでしょ?
TCP/IPSSH?おいおいやめてくれ!そんなのインフラ屋が知ってればいいんだよ!俺はプログラマーなんだ!
出来るだけバグの少ないコードを出来るだけ早く書く!それが俺らの仕事で、それ以外の事は後回しでいいんだ!

そんな調子で、Webエンジニアとして当然知っていなければならない知識の学習は後回しにしていた。当然社内での評価は低かった。
また、「動くコードが書ければいい」の精神で書いたコードは悉く正常に動作しなかった。
今思えば当たり前だった。Webエンジニアを名乗りながら、「Web」とは何なのかさえ知らなかったのだから。

エンジニアとしてのキャリアが3年目に差し掛かった今、少しずつHTTPやインフラ寄りの知識の重要性が分かってきた。
レスポンスのステータスコードの意味が分かっていれば、不具合が起こった時に何処に原因があるか当たりを付けられるし、
自分達が作ってるシステムがロードバランサー付きのサーバ2台構成と知っていれば、
どうして処理を実行してもログが出力されないのかが分かる(別のサーバに切り替わってる)。

何より、今作ってるシステムのアーキテクチャや動作の仕組みを理解していれば、
他のエンジニアとの意思疎通もスムーズになるし、信頼もされやすくなる。
そして、自分が受け持っている仕事の手戻りも少なくなる。

基礎技術の重要性を理解し始めた今、1から学習を始めようと思って、この本を読んだ。

[図解満載] Web技術の重要用語解説

[図解満載] Web技術の重要用語解説

感想

普段何となくで理解しているWeb技術の知識が、一言でビシっと説明されていて分かりやすかった。
初歩的な説明が多いが、中堅エンジニア(業務歴3~5年)でも正確に把握していないだろう知識もチラホラ紹介されていた。
以下の質問の中に答えられないものがあったら、読んでみる価値がある。
採用面接だと思って答えてみて欲しい。実際、面接でWebの基礎知識への理解を問われる事は多いようだ。

Q: Webって何?

「WWW」の略。インターネットを介してコンテンツを公開、または閲覧する仕組み。

Q: Webを構成する3つの技術は?

URL、HTML、HTTP

Q: CGIって何?

Common Gateway Interfaceの略。Webサーバ上でプログラムを実行して、出力結果を返す仕組み

Q: CGIの欠点は?

リクエストの度に「起動」→「結果生成」→「終了」の順に処理が走るため、ターンアラウンドタイムが長い。

Q: クラウドサービスの特徴は?

利用した分だけ請求されるため、初期費用を抑えられる。また、急なリクエスト増加にも耐えられる。

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: クエリパラメータでパスワードを送るのは何故危険?

  • HTTPリクエストは、送信先サーバに届くまでにいくつものサーバを経由するため、途中でパスワードを盗聴される恐れがある
  • HTTPにはリファラという遷移元URIを送信する機能があり、なおかつリファラはクエリパラメータを含むため、別のサーバにあるWebページへ遷移した際に、相手のサーバのアクセスログにパスワードが残ってしまう

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: プロキシサーバを使用するメリットは?

  • キャッシュによる通信の高速化
  • 不正アクセスの遮断
  • アクセスするサイトのフィルタリング

Q: RDBにおける正規化とは?

重複したデータの発生を防ぐ仕組み

Q: JavaのWebアプリケーションでよく使用されるLog4Jのロギングレベルは?

ログレベル 概要
DEBUG デバッグ時に参考になる詳細な情報
INFO プログラムの実行情報(メソッドの入出力など)
WARN 処理が止まるほどではないレベルで問題が起きた際の警告
ERROR エラー
FATAL 致命的なエラー

Q: スケールアップとスケールアウトの違いは?

スケールアップ…サーバの性能をUP
スケールアウト…サーバの台数を増やす

Q: コンパイル方式、インタプリンタ方式、JiT(Just in Time)方式、それぞれの違いは?

コンパイラソースコード機械語に翻訳してからでないと実行できない
インタプリンタ … 実行時にソースコードを一行ずつ読んで実行する
JiT … 実行直前にソースコード機械語コンパイルする

Q: O/Rマッピングとは?

SQLを使わずにDBを操作する仕組み

Q: MVCモデルにおける、ユーザからのリクエスト処理を行うのは?

C(Controller)

Q: プロジェクトの開発言語を選ぶ上で考慮するポイントは?

  • アプリケーションの複雑さ(例:並列処理が多いならJava等)
  • 想定PV
  • 改修頻度(例:多いならコンパイル無しで修正出来るPHP等)
  • ライブラリ
  • 信頼性(例:金融系システムにPHPは使いたくないよね…)
  • 人の集めやすさ(例:Javaなら集まりやすい。Scalaの場合は?)

リファレンス

「基礎の初歩」が学び終わったら、実際に「基礎」を学んでみよう。
RFC(Request For Comment)というインターネット上に公開されている文書が、Web技術における正式なドキュメントとなる。
つまり、このドキュメントが「基礎」という訳だ。
Webエンジニアなら、少なくとも以下の二つは読んだ方がいいと思う。

tools.ietf.org
tools.ietf.org

このような技術に関する正式なドキュメントは基本的に英語で書かれているし、難解で取っつきにくい印象を抱きがちだが、
実際は理解しやすいように分かりやすく書かれてる。
日本語約された文書もあるけど、まずは原文を読んでみる事をすすめる。
先述の通り、Web技術の正式なドキュメントは基本的に全部英語だから、英語を読んで理解する事に慣れた方が良い。
それに、個人的な意見だが、日本語で書かれた技術文書は、英語で書かれたものより難解で取っつきにくい傾向にある。

息抜きがてら、以下のエイプリルフールに公開されたジョークRFCを読んでみると面白いかもしれない。
優秀なエンジニアの笑いのセンスがどんなものか分かる。

No. 概要
RFC 1149 - Standard for the transmission of IP datagrams on avian carriers 伝書鳩などの鳥類を利用してデータ転送を行うという、ものすごく時間のかかる、まったく実用的でない通信手段の提案
RFC 2322 - Management of IP numbers by peg-dhcp DHCPIPアドレス管理を選択ばさみを使って実現するという不毛な仕組み
RFC 2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) コーヒーポットをHTTPを使って操作する方法を提案した、どうでもいい文書
RFC 3514 - The Security Flag in the IPv4 Header 他者を攻撃するような悪意を持った通信をする際は、「evil bit」と呼ばれるフラグを立てなければならないという、誰も守らないこと請け合いな仕組み