１、Web概論
・なぜWebサービスがこんなに広まったか？
→HTTP, URI, HTMLのおかげ。
→アーキテクチャスタイルRESTの登場
・クライアント/サーバ＋ステートレス、キャッシュ、統一インターフェイス等の特徴を推奨した設計方針のこと
２、URI
・URIの仕様
・URIの設計
３、HTTP
・HTTPメッセージの概要
・HTTPメソッド
・HTTPヘッダ
４、ハイパーメディアフォーマット
・情報のリンク方法、色んな種類の情報の結び付け方
５、Webサービスの設計
・URI, HTTP, ハイパーメディアフォーマットをどう組み合わせるか、実践的な考え方。外部設計
→読み取り専用の場合。どのようにデータを取得してもらうか？画面とか
→書き込み可能な場合。難しさが読み取り専用より跳ね上がる。バッチ処理、トランザクション、排他制御とか
→リソース設計
筆者は言っている。優れた音楽家は優れた開発者になることが多い。本当にそうなのかは分からないけど、音楽を志す者はもれなく偉大になろうとし、それはソフトウェアの領域でもいえるという言葉には納得するものがある。というか、それはソフトウェアの領域に限らないだろう。それでもソフトウェアは、変化が圧倒的に多くて、むしろ推奨されて、スキルや役割の重ね合わせもレパートリーが多くて、でも1つのことに固執もできて、そんな大航海時代ならぬ大開発時代(?)において、偉大を目指さなければ、どこに行きつけるというのだろうか？どこかに行きつけることすらできるのだろうか？
印象に残った箇所まとめ
※本書の面白さはそのトピックのエッセイ全体を読んだとき時に感じられると思う。難しいことは書いておらず、地道に努力を重ねていこうとする時の、考えるとよいポイントが散りばめてある。個人的にすごいと思うのは、どの取り組みも深さがあり、総じて目指している・当たり前に思っているレベルが高い。
P14 自分自身にとって「一番下手くそになる」状況を見つける。すごい人たちの間に紛れ込んで（例えばOSS）コードをマネするとか。
P16 Java経験者を探す時にあえてSmalltalkをやったことある人を探すことで、その人が好奇心を持っているか判断の手助けになる。
P17 新しい言語を学ぶ。できれば全然違うものを。本書例では、JavaならSmalltalkやRuby、オブジェクト指向ならHaskellやSchemeとか。
P24 自分自身の汎用性を高める。リーダー？マネージャー？アーキテクト？どう役割を重ね合わせる？
P27 スペシャリストになる。Java仮想マシンをクラッシュさせるプログラムをピュアJavaで書くとしたらどんな手段をつかいますか？何かのスペシャリストであることは、他に何も知らない意味とは決して違う。
P32 愛せよ、さもなくば捨てよ。とにかくやれ。やれないはずはない
言い切るのかっこいい。
P42 なぜ？どうして？常に疑問を持とう
P50 一に練習、二に練習。なぜ本番で練習できる？つまりなぜ仕事の最中にしどろもどろなコードを書くような状態になる？また、APIやライブラリを知ろう。
P72 報告できる成果を毎日あげろ
P99 あわてるな。筆者はパニック日記をつけて、振り返りとしてあわててしまった場合とどうすればよかったかを分析している。
P113 仕事をうまくやればマネージャーは見てくれるようにするのではなく、自分でアピールをしよう。
P115 顧客を怖がらせていないか？
※自分でもできてないことが多すぎて書いててしんどくなってきた。
※私見多め。
昔NativeCampを使ってたけど、先生の発音はだいたい同じだし（フィリピンとか）話す内容もたわいないし、レッスンの名前は忘れたけどひたすらAre you good? Yes, I am.のような反復練習を繰り返して英語を上手にしようとかいう謎のカリキュラムもあった。生徒も疲れるけど先生も頭が狂うと思う。
Camblyは本当にいろんな先生がいて、発音だけじゃなくて考え方もいろんな人がいる。合わないって思われた教師にはブロックされてるだろうなっていう感じのスケジュール表示になったし、気の合う教師でも、仕事の都合でレッスンを欠席したりしてたらブロックに。
それでも仲良くなる先生というか、話しやすい先生は一定数いて、すごくいろんな話をした。最近あった困ったことを話しても、励ましてくれたりアドバイスをくれたり、色んな反応があった。例えばビットコインの話でも、昔に仮想通貨を流行らせようとして失敗したから今そのお金を回収したくて売ろうとしてるだけ、っていうスタンスの鼻で笑ってる教師もいたし、みんな信じないけど私はビットコインの価値を信じるよ、っていう教師もいたし、買ったら損したよ～まあ他のところで取り返したけどね！っていう教師もいてびっくりしたし面白かった。
私が失敗した話をすると、たぶんそれは性格的にそう思っちゃうけど、今までの話を聞いてる限りだと僕はすごく頑張ってると思うし、大丈夫だよ、あなたはできる人だと思うよ、って励ましてくれたり、その時どんな気持ちになったの？そう言われる心当たりはあったの？のような掘り下げ型の話もあったし、性格タイプ的にそういう反応しちゃうのはしょうがないよ、そこで発揮しちゃうから弱みになっちゃうけど別にそういうもんだと思うよ、って開き直ってくれることもあった。
あとは、海外のリサイクル事情とかコロナ事情とか、物価事情とか国勢事情とか色々話した気がする。他にも、行って面白かった国とかおいしい食べ物の話もした。
総じて、価格は高いけど個人的にはめちゃくちゃならではの濃い体験ができて、大変面白かったしためになった。
＜全体概要＞
Webアプリケーション開発の仕組みについて、基礎を解説している。
＜全体所感＞
時系列やフロー的に説明していたり、理由とそれ故に開発された技術を解説してくれたりしていて分かりやすい。また、使っている言葉も分かりやすい。PHPやJavaのコードが使われているが、コードを読むことは目的ではなく、どんなことをサーバ側でしているのか？を言葉で説明してくれるので、コードが読めなくても問題ない。
2010年出版されたので、その頃のかなりオーソドックスなWebアプリケーション開発のやり方を解説している。現在と使っている技術が違うかもしれないが、Webアプリ開発の流れを汲む・基本理解という意味ではとても勉強になった。またJava関連（サーブレット・JSP・フレームワーク）情報が多いので、Java×Webアプリ開発×Web開発基礎を知りたい私にはうってつけだった。
＜内容概要＞
・Webの発展（HTTP, CGI, サーブレット・JSP, Webアプリ）
・Webアプリの構成要素、開発の仕組み・流れ
＜本書から得られた知見＞※個人の理解なので誤りの可能性有
・Webアプリ開発がなぜ難しいかというと、サーバとクライアント間で通信してWebアプリを構築するため、動作の起点や作動する場所（サーバorクライアント）、通信まで幅広く関わっていて、全体像が掴みにくいから
・CGIはサーバ側に行かず、クライアントPC内で完結する
・サーブレットはJavaプログラム中にHTML表示を埋め込み、JSPはHTML中にJavaプログラムを埋め込む
・URIはリダイレクトしても同じ名前を持つように考えられたプロパティ（統一）
・ポート番号でどのソフトウェアに送るかを決めている
・GETメソッドはURLに丸見えで、POSTはリクエストの中にリクエスト内容が入っている
・HTTPはログイン状況が記録できないステートレスプロトコルである（FTPはステートフル）→記録のためにCookieやセッションが使える
Cookie：例）ログイン状態を覚えておく
セッション：例）受付→選択→会計といった流れを覚えておき、その状態が終わり次第チェックをつける。それぞれの流れにセッションIDをつける
・Javaを使うとき、Webブラウザ←→Webサーバ←→APサーバ←→DBな感じ
Webサーバ：静的HTMLリクエストといった回数が多くて処理が軽いものの受付
APサーバ：動的リクエストといった回数が少なくて処理が重いものの処理、で役割分担が多い
・サーバのフォワード処理ではリクエストを複数発行せず、レスポンスに宛先のURLを含んで返す
・リクエストパラメータはHTMLからきた文字列なので使用するとサーブレット内部で処理するのに使えない、代わりにリクエストスコープを使い、リクエストとレスポンス間でデータを共有し、処理をする
・アーキテクチャ＝今まで開発に使ってきて便利だった考え方を実装するためのフレームワーク
アーキテクチャ：ロジックとデザインの分離（MVCモデル）を実現するためのフレームワークのStruts、レイヤパターン分離によるデータアクセス層分離を実現するためのO/RマッピングフレームワークiBatis
・フレームワークは設計を固める（自由度が下がる）ことで設計・開発工数を削減しており、学習コストを払うことで品質が保証できる（作成部が減る）。テスト工数も減らせるが、フレームワークは現技術の賜物の結晶なので、使えても原理が分からなければその場しのぎとなり、長期的な技術力にはならない（勉強しよ）
・クライアントはどんな使い方をするか？入力リクエストによってブラウザを操作されない、SQLを実行されない、個人情報を取得されない、成りすましができないために、SSL(HTTPS)を使う、セッションIDを判定に使う等する。
また、戻るボタンや処理遅さによる連続クリックでの複数リクエストを防ぐために、ワンタイムトークンを使う、グローバル変数に情報を持たせない等
面白そうだと思う方がいたらぜひ読んでみてください～
