前提知識: はじめにWebありき

  • 本文書では、"Web (World Wide Web; WWW)"は、大枠を既知とする
    • Web を実現している数々の要素技術について、概略として想像が及ぶこと
    • 系統的な教育を受けていなくても、Webがどういったものかについて一般的な知識があれば今は充分
    • 以下のようなキーワードについて、何を指しているかぐらいはわかっていれば問題なし
      • TCP
      • HTTP
      • DNS
      • URI / URL
      • HTML
  • クライアント・サーバ(Client and Server)モデルの概念も既知とする

暗黙の前提1: 自ら調べられること

  • 本文書は網羅的な教科書となることを目指さない。できねぇし
  • 従って文章中にわからないことが出てきたら 自分で調べられること を前提とする
    • 「そのときすぐ」でなくて良い。いずれ思い出して気になったとき、でも良い。脳内の「知らないこと領域」に追加すればよい
    • この領域は面白いデータ構造をしている。 cf. Algorithms and Data Structures; アルゴリズムとデータ構造
      • 追加した順に取り出せる(Queue)とは限らない。追加したのと逆順に取り出せる(Stack)とも限らない
      • 「重要かどうか」など、何らかの指標によって順序付けられている(Heap)わけでもない
      • 追加したが二度と取り出されないことが頻繁にあり得る
      • それどころか 追加したのに知らぬ間に消滅することもある
  • なにごとも、いきなり全て完璧に定義や公理まで遡って理解できなくても良い
    • そのとき興味のある部分までとりあえず掘り下げる
    • 過程で必ず新たな新事項がでてくるはずだが、時間があるならそこも掘ればいいし、なければ 遅延評価(Lazy evaluation) する
      • 「知らないこと領域」にやはり突っ込んでおき、同じプロセスを辿らせる
      • 「そう言えば前もこの単語わからなかったな」という「気づき」はいわば duplicated insert である
        • とはいえ厳密な 一意性(uniqueness) が存在する 集合(Set) なのかはよくわからない
        • なんにせよ別々の機会に渡って複数回疑問を抱くというのは自分にとって重要である可能性と相関するはず
    • これを繰り返していけば、自然と源流まで遡っていくことができる
  • そのようにして順に「知らないこと」を調べていくのが 何よりも重要な技術
    • ちなみにいざ調べることが必要になったときにも「戦略」がありうる
      • 当座の対象について、大まかな理解を優先するなら 幅優先(Breadth-first)探索 する
      • どんどん掘り下げたい気分なら 深さ優先(Depth-first)探索 する
        • 深夜にやるのがオススメである。会社には遅刻する
  • 本文書が伝えたいことのうち、 実に7割くらいがこの「調べられること」の重要さ である
    • そもそも「サーバ開発の基礎」だって、皆が個別に調べられるならば講義しなくても良いのだ
      • 並列(Parallel) かつ 非同期(Asynchronous) な形態である
      • 逆に複数人がこの資料を同時に読み進めながら座学講義するのは 同期的(Synchronous) な処理である
        • 進捗は全員同じペースとなる
        • 全員の理解度を都度確認しながら進めるような場合は、最も理解に手こずっている人の速度に全体が合わせることにもなる
        • 一方で、よくわからなかった部分は「あとで調べればいいよ」などといって先に進むかも知れない
          • これは「時間のかかる処理単位を非同期的実行に切り替える」行為である。"Asynchronous job dispatch"などという
          • もしもこの「あとで」が、「必要になったときに改めて」などと読み替えられたならば、 遅延評価 にも該当する
  • はじめはどんな分野でも知らないことのほうが多いので、「何から手を付けていいかわからない」状態になりがち
    • 索引(index)なしで辞書を読むようなもの。たまに辞書を最初から最後まで読む輩とかもいるが。。。
  • 本文書は、サーバ開発に関して「この辺が頻出/基礎/重要」「この辺がキーワード」「この辺が面白い」などを、 ちょっとしたストーリーに沿って挙げていく。いわば分厚い辞書に付箋をうつことを目的とする
  • 従って、 この文書を読みつつ、ポイントとなりそうな事柄を自分で調べて、枝葉を広げるように進める のが使い方となる
  • 既に気づいているかも知れないが、そのためにいくつか仕掛けがある
  • 太字 になっていたり、対応する英単語が併記されていたりするのは、 筆者が重要だと思っているポイントや、「気になったら調べて欲しい事柄」である
    • 特に、固有名詞っぽいものや専門用語っぽいものは興味を持って欲しい
    • 英単語を付してあるのは、概して英語の方が資料も多く、権威ある情報源は英語であることが多いため
  • リンクはあえて、ほとんどつけていない。(片っ端から付けるのが面倒だったというのもあるが、) 権威のありそうな情報源を特定する のはこれもまた技術であり、練習してみてほしいからだ
    • 「一次情報源」の特定
    • とはいえそんなに難しいものでもなく、慣れを要する程度の話。どんどんやってみよう
  • 同じ単語が再登場することが複数回ある。行き来して文脈を確認してみて欲しい
    • 同じ意味で登場していることもあれば、
    • 文脈によって微妙に意味が異なっていることもあるはず
      • ソフトウェア開発の世界ではよくある

「調べ方」の手引き

  • Web関連の技術要素で広範に利用されているものであれば、 Internet Engineering Task Force; IETF が中心となって業界関係者からなるグループで議論した上で、 RFC(Request For Comment) としてまとめてあることが多い
    • 長期間の議論と公開されたレビューのプロセスを経ており、権威ある情報源であることが多い
      • このことが保証するのは説明・定義として誤謬がなく信頼できるという点であって、 その内容が現代の実務状況に照らして「使いやすい」「ベストな」ものとは限らないのは注意
    • 例) RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax
    • 読むときは、
      • "Status"や、
      • "Obsoletes: ..." 「〜を廃止する」(廃止して置き換える)や、
      • "Updates: ..." 「〜を更新する」に注意する
    • その文書が現在どのような扱いであるのか確認してから読む。既に廃止されたバージョンかもしれない
    • 演習1: 2018年5月現在有効な HTTP version 1.1 の標準仕様を定めたRFC群(複数ある)を特定してみよう。手段は問わない
  • ものによっては、その技術や概念は論文として発表されているかもしれない
    • Google Scholar はその検索のための極めて有用なサービス
    • 査読付き論文誌などに採択されていないものでも、 arXive で発表されているかも知れない
  • 何らかのアプリケーションやフレームワークについて調べる際には、基本的にはそれらの開発元が提供している文書が確実である
    • ニュアンスとしては以下のような感じ(異論は認める):
      • "Guide": 実際に使用する方法を順序立てて流れとして説明する文書
      • "Reference": アプリケーションのコマンドやAPIなど、一つ一つの細かな仕様をまとめた文書
      • "Documentation": GuideとReferenceの中間。どっち寄りかはものによる
  • ある分野に関連する語彙や概念についてまとめて一度に知りたいのであれば、書籍や解説サイトが有効
    • 書籍にはレビューがつきものなので、良し悪しを判定してから買うのが容易。先輩に聞くのも良い
      • 特に、既にある程度枯れた技術で、定番の解説書がある、といったケースではそれを読むのが手っ取り早い
      • 新卒研修サイトに推薦図書集もあるので利用しよう。図書予算というのもちゃんとある
    • 解説サイト・ブログなどはまさに玉石混淆なので油断ならない
      • 一般に、権威ある情報源や、関連する文書へのリンクを付与しつつ、 その上で自分の言葉による噛み砕いた説明に落とし込もうとしている文書は、内容はともかく姿勢として信頼に値する
        • 要は書籍や論文と同じ
      • RFCや論文などへのリンク(参考文献リスト)がきちんとまとめられている限りにおいて、Wikipediaなどの記事も十分役立つ
  • 大切なのは、どんな過程であれ 信頼できる情報に辿り着くための努力を惜しまない こと
    • よくあるアンチパターン1: 「検索して最初にでてきたサイトを斜め読みしてわかった気になる」
    • よくあるアンチパターン2: 「StackOverflowからコピペ」
  • 慣れてくれば、信頼できる情報に辿り着くための ホップ数(hop count) を減らせるようになる
    • RFCや公式ドキュメントなどの一次情報源を検索エンジン化して、ダイレクトに検索可能にする
    • その分野の代表的な研究者・開発者・開発企業をSNSでフォローしたり、ブログを購読したりして、最新情報を早く掴む
    • 情報の流入量を増やしすぎて圧倒されないように、定期的にフィルタリングを改善する

暗黙の前提2: 実践

  • 「調べる」ことに重きをおいて訴えているが、当然ながら調べただけでは人間間違いなく忘れるので、 何らかの形で手を動かして実践することをしないと知識は内面化(internalize)しない
    • 複数回調べることで反復によって覚えるというのもありだが、やっぱり肌感覚、体得というのは重要
    • 何かを行動に移したとき、必然的に外界からのフィードバックを受けるが、 このときの不安、圧力のようなものが技術・知識の体得を促す燃料になる
  • とはいえ、業務において必要な内容については、自然と業務の中で体得する機会を得られると思っているので、ここは楽観視している
  • 逆に、 普段業務で直接使うことがあまりないが、ある程度理解しておかないとサービス・案件の全体設計・実装・運用に響いてくる分野 というのがクセモノ
    • 自分にとってそういった「畑違い」の分野こそ、意識的にキャッチアップするよう取り組んだり、 ときにはコードを書いてみたりすることが大切だと思う

さて、ここまでが長い前置きで、ようやくサーバの話に入る

results matching ""

    No results matching ""