月頭訓話で話すこと

■全体を通して伝えたいこと

「多くのことは意外と身近にある」

(but 何でもできるわけではないし、簡単にできることばかりでもない。)

 

■導入

・自己紹介(東大のことや自分の高校時代など身近に感じられるようなこと?)

 ー東大生って意外と普通だよ、と。バスケと筋トレしてー、

 ー高校生の頃はバスケ部で西村先生にしょっちゅ怒られて-、、、

 ーあの頃から10年くらい経ったけどその頃と違うことと言えば、、、肌に潤いがなくなったことと額が広くなったことくらい。

 

■本題

・自分の経験に即して身近になった例を話す。(プログラマーや旅行の話など、少し外に目を向けたら色々なことが実現できる範囲にあることを話す)

 ー高校生の頃っていろんなことがすごく遠く感じてた。テレビに流れることって全部自分には関係ない違う世界のことみたいに。例えば東大だってそう、海外だってそう、いろんなサービスがあるけど、それに関わるなんて考えも及ばなかった。

 ー旅行の話。

 

■備考

・いろんなことに興味を持ってやってみるといいと思う。先生、自分や友達の親とかいろんな人に話聞いたり、テレビやネットで出てくるような職業を調べてみたり。

・今日自分が言ったプログラマーってのもその1つだし、旅行をして世界を自分の目で見てみたいってのもその1つだと思う。

 

パワポ

・自己紹介用のスライド ー 自分の経歴

・旅行写真 ー 自分の髭面、NBA、中東

Getting Real

・ライバルを持ち、相手が強調している点と異なる点を強調する。先駆者の追随になってはならない。競合比較ではなく、何が根本原因なのかを考えなければならない。

・アプリケーションのポイントを決め、それに基づいたビジョンを定め、ビジョンに沿って行動する。

・成功と満足の秘訣はディテールにあるが、完璧主義者になるのは後回しで。

・アプリケーションのコア市場を見つけ、ターゲットを絞り込む。

・不完全な製品ではなく、本当に必要な機能を持った半分の製品を作る。機能を削る。

・追加機能はノーから入る。いらない機能を尋ねる。

・できるだけ早く実現させる。現実のものにする。

 

■アイディアを現実に

1.インスピレーション ー プロジェクト全体を見渡せる大局観、俯瞰図

 そのアプリケーションは何が必要なのか?それがいつ役に立つのか、どのように知るのか?いったい何を作ろうとしているのか?

2.紙スケッチ

3.HTML

4.コードにする。

 

・環境設定を委ねすぎない。苦情があれば変更する。

・実行すること。

・各タスクのスケジュール、規模を細分化しよう。

・干渉されない時間を作る。

・ミーティングをできるだけしない。する時には、必要最低限のメンバー、タイマーをセットして、話の内容が定めてから。

・小さな成功を見つけて自分をチームをモチベートする。

・良い文章を書く。

・インターフェースから作る。インターフェースがデザイン。

・ページの中核部分()から始める。ロゴやフッターなどはいったん無視。

・ソフトウェアの導入部分が評価を決める大きな要素になる。

・インターフェースには必ずしも一貫性は不可欠ではなく、ユーザーがその時点で本当に必要なものを与えることが重要。

・より少ないソフトウェア。より少なく、きれいなコード。

・説明ではなく、体験を書く。

・バグに重要度をつける。

・無料登録やブログとか使うとかってプロモーションとか運用してく話が後半にある。

プリンシプルオブプログラミング ー 1 ~ 4 章 ー

ーー まえがき --

 

■プリンシプル

・プログラミングの指針となる、「前提」「原則」「思想」「習慣」「視点」「手法」「法則」など

 ≒ よいプログラミングのためのエッセンス

・プリンシプルを学ぶことで、技術を習得した際に「なぜ必要なのか?」が分かるため、習得が早く、深くなる。

 

 

ーー 第1章 前提 --

 

■プログラミングに銀の弾丸はない

・プログラミングの成果物であるソフトウェアは本質的に困難(複雑性、同調性、可変性、不可視性)であるため、特効薬はない。

 → ソフトウェア開発の歴史を学び、様々な手法や考え方を学んで地道に複雑さを軽減していく。

 

■コードは設計書である

・プログラミングにおける設計は、「基本設計」「詳細設計」「プログラミング」「テスト」「デバッグ」、製造は「ビルド」「リリース」。

 → 分担するより、全員が行うべき。

 → コードが設計なら、できるだけ早くコードを書き始めなければ不明確な部分ばかりで設計が完了しない。

 

■コードは必ず変更される

・変更に強いコードを書かなければならない。可読性が重要。

 

 

ーー 第2章 原則~プログラミングのガイドライン~ --

 

■KISS( Keep It Simple, Stupid )

・コードには必ず変更が入って無秩序に向かうため、コードの最優先価値を「単純性」「簡潔性」に置く。

・次のことに注意 - 「新しい技術を使いたい」「将来の必要に備えたい」「勝手に要件を加えてしまう」

・コードだけでなくソフトウェアにも適用できる。

・less is more

・「オッカムの剃刀」何かについていくつかの説明が可能なら、もっとも単純なものが正しい

 

■DRY ( Don't Repeat Yourself )

・コードを読む・修正する作業が難しくなる、テストがないので、コードの繰り返しを避け、抽象化する。

 

YAGNI(You Aren't Going To Need It )

・拡張性を考慮してもたいていは外れるので、コードは今必要な最低限にとどめる。

・「DTSTTCPW」Do The Simplest Thing That Could Possibly Work 

  うまくいく方法のうち、もっともシンプルなもので行う。

 

■PIE( Program Intently and Expressively )

・意図を表現してプログラミングせよ

・コードだけがソフトウェアの動作を「正確に」「完全に」知るための手がかりなので、読みやすさを最優先に。

・コードは「What」「How」しか表現できないので、「Why」はコメントする必要がある。それ以外でも適宜行う。

 

■SLAP(Single Level of Abstraction Principle )

・コードに「要約性」と「閲覧性」を与えるために、コードの抽象度を合わせる。

・関数を構造化する。

 

■OCP(Open-Closed Principle)

・コードの変更に柔軟に対応するため、「拡張に対して開いている」「修正に対して閉じている」ことが重要。

・コードにインターフェースを用いて、「コードのふるまいを拡張できる」「コードのふるまいを拡張しても、そのほかのコードは全く影響を受けない」ようにする。

 

■名前重要

・コードを読む人への「UI」なので、命名は最重要課題。

・名前は、

 ーより多くの情報を詰め込む。

 ー誤解されることのないよう気を付ける。

 -「効果」と「目的」を説明する。

 ー自分でチェックする場合、処理を書く前にそのテストを書くようにする。

 -発音可能なものにする。

 -検索可能なものにする。

・「ループバックチェック」名前はその元となった内容の説明を復元できなければならないので、内容の説明文から名前を考えたら、再度説明文を考える。

 

 

ーー 第3章 思想~プログラミングのイデオロギー~ --

 

■プログラミングセオリー

・価値観を技術の選択基準に。

・3つの価値観

「コミュニケーション」「シンプル」「柔軟性」

・6つの原則

「結果の局所化」「対称性」「繰り返しの最小化」「宣言型の表現」「ロジックとデータの一体化」「変更頻度」

・「フォース」ある技術を適用すべき観点

 -解決策が満たすべき「要件」

 -課題に含まれている「制約」

 -解決策に望まれる「特性」など

・「形態は機能に従う」

 

 ー 価値観 ー

 

■コミュニケーション

・コードはコミュニケーションの場である。コードを読む側の視点に転回せよ、

 

■シンプル

・コードの玉石を分ける。本質的な部分を目立つようにし、それ以外の余分な部分がそこに紛れ込まないようにする。

 

■柔軟性

・コードに柔軟性を持たせるために拡張しやすく、かつ、拡張が他に影響しないような設計を心がける。

・ただし、複雑なコードや設計は正当化されないので、即効果のあるコード以外我慢する。

 

 - 原則 -

 

■結果の局所化

・関係性の高いコードを密集させることで、変更の影響が局所にとどまるようにコードを構成する。修正と確認も容易に。

・互いに頻繁に呼び出しあっている関数は本来同一箇所に置くべきかも。

 

■繰り返しの最小化

・大きなコードの塊は、他の大きなコードの塊と同じ部分があるはず。コードを小さな部分に分割して管理。

・修正の影響を局所化するため重複を排除。

 

■ロジックとデータの同一化

・データと操作を同じ場所において見通しをよくする。

・最初からベストな配置は分からないので、後から移し替える。

 

■対称性

・対称性を持ったコードは他の部分も類推できるので、コードに一貫性を持たせる。

・同じことは同じ表現で。

 ー「追加」メソッドがあれば、「削除」メソッドを

 ーあるグループにある関数は同じ引数を取らせる。

 -あるモジュール内のデータは全て同じ生存期間に

 -ある関数内で呼び出す関数の抽象度は全て同じレベルに

 

■宣言型の表現

・命令型ではなく宣言型のコードを取り入れる。 ・・・?

 

■変更頻度

・「変更頻度」コードを修正するタイミングが同じ。「変更理由」が同じということ。同じタイミングで変更される要素は同じ場所に、違うタイミングのものは違う場所に。

・グルーピングされたコード内で変更理由を複数持っているコードの場合、修正に関係ある個所と無関係な箇所が混在するため、関係ない部分まで修正の影響を受けてしまう可能性がある。

・ロジックもデータも変更理由で所属を決める。

・「単一責任の原則」モジュールを変更する理由は1つより多く存在してはならない。

 

 - アーキテクチャ根底技法 -

 

■抽象

・「捨象」「一般化」して複雑さをそぐ。

 

カプセル化

・関連のあるデータとロジックをグルーピングして、1つのモジュールを定義。

・関連のない要素が混じらないため、コードが見やすくなる。

・変更時の影響がモジュール内のみに。

・影響度が明確になるので、コード変更が容易に。

・それぞれが独立した部品になるので、再利用性が高まる。

・小さい単位に分割されるので、複雑な問題に対処できる。

 

情報隠蔽

・クライアントの実装を使用するクライアントから隠ぺいする。

・インターフェースが小さくなり、やりとりがシンプルになり、コード全体の複雑性を下げられる。

・クライアントから見ても、余計な情報が見えないので、モジュールの使い方がシンプルに。

 

■パッケージ化

・モジュールを意味毎にグルーピング。=ソフトウェア全体を意味のある単位に分割すること。

・開発が進む中でボトムアップで行う。

メリット

・ソフトウェア全体がパッケージ単位になるので複雑度が下がる。

・パッケージには関連のないモジュールが混ざらないので、モジュール管理が容易に

・修正時に影響がパッケージ内に留まる可能性が高い。

・依存関係が整理されるので、パッケージ単位で再利用しやすい。

 

■関心の分離

・「関心」ソフトウェアの機能や目的

・関心単位でモジュール化することで、変更が容易、並行開発できる。

 

■充足性、完全性、プリミティブ性

・モジュールが提供する関数が「十分で」「完全で」「純粋な」ラインナップにする。

 

■ポリシーと実装の分離

・ソフトウェアの前提に依存する「ポリシーモジュール」と「実装モジュール」を分離する。

 

■インタフェースと実装の分離

 

■参照の一点性

・変数に対して値の再代入を行わない。

 

■分割統治

例えば、

・ソフトウェア全体設計は、独立して設計できる部分に分割してから取り組む。

・モジュールを設計するときは、「責任・責務」の観点からモジュール分割。

アルゴリズムを設計するときは、マージソートのように分割して解決できないか

 

 - アーキテクチャ非機能要件 -

機能面以外の全般についての要件で、リリース後の開発や保守、運用、リソースの効率活用に大きな影響を及ぼすので、アーキテクチャ設計の際には非機能観点も 考慮に入れなければならない。

 

■変更容易性

・容易に改善できるようにして、長期間使えるソフトウェアを作る。

・「保守性」変更箇所の局所化で、障害時に修正しやすく。

・「拡張性」モジュール間の結合度が弱く、新機能の追加、モジュールの置き換えや除去が容易に行える。

・「再構築」モジュール間の関係の再構築

・「移植性」ソフトウェアを他の言語や実行環境で行えるように設計する。

 

■相互運用性

・標準規格を選択して、他のソフトウェアと連携できるようにする。

 

■効率性

・コンピュータリソースを最大限引き出せるようアーキテクチャを設計する。

・「間接化」モジュール間の直接の結合を避けるため、それらの間に介在する「媒介モジュール」を導入すること。ただし、「効率性」とのバランスを考慮する。

 

■信頼性

・「冗長化」「フェールソフト」「フェールセーフ」を行う。

 

■テスト容易性

・テストの品質が本体の品質であるので、テストを容易にするアーキテクチャが求められる。

・テストも考慮した本体設計が必要なので、テストのためのコードが本番にあってもよい。

 

■再利用性

・再利用することで開発効率を上げるため、アーキテクチャの構成を、既存の構造やモジュールにプラグインできるようにする。

・再利用の3の法則

「難易度3倍の法則」再利用可能なモジュール開発は、単一のソフトウェアで使うモジュールを開発する場合に比べ3倍難しい。一般化した問題の処理を考えなければならないため

「テスト3種類の法則」3つの異なるソフトウェアでテストする必要がある。実際に使われてみるまで分からないため。

 

 ー 7つの設計原理 ー

コード価値観が「漏れない」「ぶれない」ため、コードレビュー時、あるいはコードを作りこむときに考慮すべき観点。

 

■単純原理

・シンプルで自然なコードを書く。

 

■同型原理

・一貫性のあるコード書く。

 

■対称原理

・コードの形に対称性があると、予測がつきやすく、コード理解のスピードが速まる。

 

■階層原理

・抽象階層構造のあるコードを書く。

 

■線形原理

・可読性、保守性、保守性が向上するので、処理の流れは直線にこだわる。

・そのためには分岐の少ないコードを書く。

 

■明証原理

・ロジックが明瞭なコードを書く。

 

■安全原理

・必然性のないところや曖昧なところは安全サイドにコードを書く。

・要件や機能の仕様書は必要条件なので、エラー時の処理、ログ出力など十分条件を満たすコードは個々のプログラマによる。

 

 - UNIX思想 -

1969年に生まれ、いまなお使われているUNIXの設計思想。

 

■モジュール化の原則

・モジュールのインタフェースを狭くして、関係性の高いもののみ集める。

 

明確性の原則

・コードを読むとき、分かりにくいコードの「解読」を3回以上繰り返してはいけない。2度目に読まなければならないとき、修正あるいはコメント等の対策すべき。

 

■組み立て部品の原則

・ソフトウェアを相互接続できるよう、データストリームを受けつけ、加工し、別のデータストリームとして出力するフィルタにして組み立てる。

・テキストストリームを読み書きするコマンドラインで使用できるソフトウェアを設計する。

 

■分離の原則

・ソフトウェアの前提に依存し不安定な「ポリシー」と独立し安定的な「メカニズム」を分離する。

・分離したポリシーを改善する。

 

■単純性の原則

・コードはシンプルに。シンプルを美しいとする文化に。

 

■倹約の原則

・コードの分量も複雑度も大きなコードを書かない。

・まず小さなコードを書く。大きくなったら分割。

 

■透明性の原則

・設計時に下記2点を意識。

「透明性」ソフトウェアの動作が、一目で何をどうしているかが分かる。

「開示性」ソフトウェアの内部状態にすいて、監視、表示できる。

デバッグ機能を設計の最初の段階から組み込む。

 

■安全性の原則

・ソフトウェアを堅牢にするため、コードを「透明」かつ「単純」にする。

・そのためにコードレビューや、特異な入力や極端に大きな入力に耐えられるか検証する。

 

■表現性の原則

・データはロジックよりも扱いやすいため、避けられない複雑さはロジックよりもデータに寄せる。

 

■驚き最小の原則

・予想通りのインタフェースを設計する。

・よく似たソフトウェアのインタフェースをモデルにする。

・想定ユーザーの特徴を考慮する。

・伝統に注意を払う。

・「一見似ているが異なる」ということを避ける。

 

■沈黙の原則

・表示を最小限のみに抑える。

-本当のエラーだけを標準エラー出力に表示。

デバッグの目的で、進行状況についてメッセージを表示した場合はそれ用のスイッチ。

 

■修復の原則

・修復失敗時は処理停止。エラー通知は大きく。

 

■経済性の原則

プログラマの時間節約のため開発環境のためのハードウェアやソフトウェアに投資する。

 

■生成の原則

・コードジェネレータを作る。

 

■最適化の原則

・早い段階での最適化は、透明性や単純性が犠牲になり、半端な最適化が全体最適化の妨げになるので、まず正しいコードを書いてから最適化を行う。

・プロトタイプをまず作ることは有効。

 

■多様性の原則

・唯一の正しいやり方は存在しないので、選択の受容性を許容し、よりよりやり方を求め続ける。

 

■拡張性の原則

・ソフトウェアを接続可能な設計にし、その用途などを明記する。

 

 - UNIX哲学 -

UNIXの背後にある設計の哲学。UNIXという考え方。

 

■小は美なり

・小さく作って小さく保つ。

ー理解が容易、保守が容易、マシンリソースに負担をかけない、他のソフトウェアと組み合わせやすい。

・大きなソフトウェアは複雑でコードの理解が困難、不測の事態に対応できない。

 

■1つ1つ仕事

・1つのソフトウェアは1つの仕事に集中することで、コードの不要部分がなくなる。

 

■即行プロトタイプ

・プロトタイプをできるだけ早く作ることで、前提の誤りを早期に発見でき、要件不備による手戻りを減らせる、早いうちから誤りを取り除く作業を始められる。

 

■効率性や移植性

・ハードウェアに依存しないコードを書く。

 

■データはテキスト

・バイナリではなくテキストで。ユーザーにもプログラマにも優れている。

CSVやHTMLを選択して、他との接続制を高める。

 

レバレッジ・ソフトウェア

・既存のソフトウェアをできるだけ利用する。

・単機能で単価値に集中したソフトウェアを作り、それらをグルー言語で組み合わせる。

 

シェルスクリプト活用

シェルスクリプトによって、梃の効果と移植性を高める。

・グルー言語はシェルスクリプトを用いる。

 

■対話インタフェース回避

・コマンドインタプリタに制御を返す設計

対話インタフェースのデメリット

・ソフトウェアごとに独自の対話方法が必要になる。

・ソフトウェア同士が対話できなくなる。

・待ち時間が多くなる。

・入力部分の解析コードが大きく、醜くなる。

・「大は美なり」的なアプローチになる。

 

■フィルタ化

・「フィルタ」入力ストリームをデータとして受け取り、何らかの加工を施し、加工したデータを出力ストリームに送り出すこと。

・ソフトウェアとはフィルタである。

・データの入出力には標準入出力、エラー情報は標準エラー出力を使用する。これによってソフトウェア同士が接続可能になる。

 

 

ー 視点 プログラマの観る角度 ー

 

■凝集度

・モジュールに含まれている機能は純粋に。混じりけのあるモジュールは脆い。

・凝集度の高いモジュールは

 ーコード設計の明確さと理解のしやすさが高まる。

 ーコードの保守と拡張が容易になる。

 ーコードの再利用性が促進される。

 ーモジュール間の疎結合性も同時に促進される。

 

■結合度

・モジュール間は疎遠に。結合な密なモジュールは、互いに依存し、影響し合うので様々な問題が発生してしまう。

・モジュールの結合度を下げるには

 ーデータの受け渡しは引数で

 ーデータの置き場所にグローバル変数をできるだけ用いない。

 ー渡す値に応じて動作が変わるようなコードを書かない。

 

■直交性

・コードは独立させよ。

・モジュール間の結合度を下げることで実現可能。

 

■可逆性

・問題があったときにやり直しができる設計にする。

・コードに柔軟性を持たせる。特定技術に依存するのはやめ、コードを独立して変更しやすい状態にする。

 

■コードの臭い

・コードの中で、理解しにくい、修正しにくい、拡張しにくい、と感じられる部分を適切なコードに改善していく。

・似たコードをよく見るとか、長すぎるとか、大きすぎるとか、多すぎるとか、名前が合わないとか。

 

■技術的負債

・問題コードを管理する。一時的に負債となるコードを書いても、リリース後に再度修正する。暫定ソリューションをそのままにしない。

HTTPの教科書

ーー 第1章 Web とネットワークの基本を知ろう ーー

 

TCP / IP 

アプリケーション層。HTTPやFTP

トランスポート層TCPが信頼性を担当。データ(HTTPメッセージ)を通信しやすいようにバラバラにしたり、スリーウェイハンドシェイクで確実に相手に送信する。

ネットワーク層。IPが配送を担当。宛先としてMACアドレスを追加。

 

URI(Uniform resource Identifier)のフォーマット

http://user:pass@www.example.jp:80/dir/index.html?uid=1#ch1

・「スキーム名」リソース取得に用いるプロトコルの指示(ex)https. http, ftp

・「資格情報」サーバーからリソースを取得するのに必要なアイパスなど(オプション)

・サーバーアドレス、ポート番号、ファイルバス、クエリー文字列、フラグメント識別子

 

 

ーー 第2章 シンプルなプロトコルHTTP ーー

 

■HTTPは状態を保持しないステートレスなプロトコル

・状態の保持には Cookie を用いる。

・あるサーバーへの1度目のリクエストに対するレスポンスの際に、Set-Cookie というヘッダーフィールドでCookieをクライアントに保存するよう指示。同一サーバーへの2回目以降のリクエストの際には、Cookieをヘッダーフィールドに付加することで同一のクライアントであると認識される。

 

■HTTPメソッド

・「GET」リソースの取得

・「POST」エンティティボディの転送

・「PUT」ファイルの転送。セキュリティ上の問題があるので、Webアプリケーションの認証機能やWeb同士が連携するRESTという設計様式を利用する場合に利用されることが多い。

・「HEAD」メッセージヘッダーの取得。URIの有効性やリソースの更新時間を確かめる目的で使われる。

・「DELETE」ファイルの削除。PUTと同様セキュリティ上の問題。

・「OPTIONS」サポートしているメソッドの問い合わせ。

・「TRACE」経路の調査。

・「CONNECT」プロキシへのトンネリング要求。

 

■通信量の節約

・「持続的接続」クライアントとサーバーいずれかが明示的に接続を切断しない限り、TCP接続を持続する。リクエスト毎の前にTCP接続を行う必要がなくなる。

・「パイプライン化」レスポンスを待たずにリクエストを発行できる。

 

 

ーー 第3章 HTTPの情報はHTTPメッセージにある ーー

 

■メッセージの転送

・「コンテンツエンコーディング」圧縮して送る。gzip, compress, deflate, など

・「チャンク転送コーディング」大きなサイズのデータの時分解して送る

・「マルチパート」MIMEの仕組みを使って、テキストや画像など異なるデータを送信できる。MIME・・画像などのバイナリデータをASCII文字列にエンコードする方法や、データの種類を表す方法を規定している。

・「レンジリクエスト」エンティティの範囲を指定してリクエストを行う。

・「コンテンツネゴシエーション」言語や文字セット、エンコーディング方式毎に最適なリソースを提供する仕組み。サーバー、クライアント、両方が駆動するタイプがある。

 

 

ーー 第4章 結果を伝えるHTTPステータスコード ーー

 

ステータスコードのクラス

・1XX リクエストが受け付けられて処理中

・2XX リクエストが正常に処理を完了した。

・3XX リクエストが完了するには追加動作が必要(リダイレクトとか)

・4XX クライアントエラー

・5XX サーバーエラー

 

 

ーー 第5章 HTTPと連携するWebサーバー ーー

 

■バーチャルホスト

・1台のサーバーで複数ドメインを実現する。

・同じIPアドレスで異なるホスト名やドメイン名を持った複数のWebサイトが稼働しているバーチャルホストの仕組みがあるため、FQDN( Fully Qualified Domain Name )かHostヘッダーフィールドでの指定が必要。

 

■通信を中継するプログラム

・「プロキシ」サーバーとクライアントの両方の役割をする中継プログラム。キャッシングプロキシと透過型プロキシがある。

・「ゲートウェイ」HTTPサーバー以外のサーバーへの中継。データベースへの接続やクレジットカードの決済など。

・「トンネル」クライアントとサーバーが安全に通信を行うための通信路を確立する。HTTPリクエストを解釈しない。

 

・キャッシュはクライアントとサーバーの双方に存在する。

 

 

ーー 第6章 HTTPヘッダー ーー

 

・HTTPヘッダーフィールドは、HTTPメッセージを構成する要素の1つで、HTTPプロトコルの中で、メッセージボディのサイズや、使用している言語、認証情報などをブラウザやサーバーに伝える。

 

■4種類のHTTPヘッダーフィールド

・「一般ヘッダーフィールド」リクエスト、レスポンス両方で用いられる。

・「リクエストヘッダーフィールド」

・「レスポンスヘッダーフィールド」

・「エンティティヘッダーフィールド」

 

 

ーー 第7章 Webを安全にするHTTPS ーー

 

■HTTPの弱点

・通信が平文(暗号化しない)なので盗聴可能

・通信相手を確かめないのでなりすまし可能

・完全性を証明できないので改竄可能。

 

HTTPS = HTTP + 暗号化 + 認証 + 完全性保護

公開鍵暗号方式共通鍵暗号方式を併用して暗号化。

・ネットワークに負荷がかかることから通信が遅くなる。

・暗号化や復号化の必要があるのでCPUやメモリを使い処理が遅くなる。

 

 

ーー 第8章 誰がアクセスしているかを確かめる認証 --

 

■HTTP/1.1 で利用できる認証方式

BASIC認証

・DIGEST認証

SSLクライアント認証 - HTTPSのクライアント認証を利用した証明方式で、利用するのにコストがかかる。

・フォームベース認証 - 認証の大半はフォームベース認証が用いられ、セッション管理とCookie による実装が行われている。

 

 

ーー 第9章 HTTPに機能を追加するプロトコル --

 

■HTTPのボトルネック

・1コネクションで1リクエストしか送れない。

・リクエストをクライアントからしか開始できない。レスポンスだけを受け取れない。

・ヘッダーが圧縮されずに送られる。ヘッダーが冗長。

・データの圧縮は任意だが、圧縮して送られることが強制ではない。

 

■解決方法

・「Ajax

・「Comet」サーバーに更新があるまでレスポンスを保留。(疑似的サーバープッシュ)

・「SPDY」多重化ストリーム、リクエストの優先順位付け、HTTPヘッダーの圧縮、サーバープッシュ機能、サーバーヒント機能

・「WebSocket」ブラウザで双方向通信を行う。通信料削減

 

WebDAV(Web-based Distributed Authoring and Versioning)

 Webサーバー上のファイル管理を行う。

 

 

ーー 第10章 Webコンテンツで使う技術 --

 

・「CGI」リクエストのたびにプログラムを起動するので、大量にアクセスがあるとWebサーバーに負担がかかる。

・「サーブレット」Webサーバーと同じプロセスの中で動作するので、負荷を軽減できる。

XMLAtomRSSJSON

 

 

ーー 第11章 Webへの攻撃技術 --

 

・出力値の不備による脆弱性

・設定や設計の不備による脆弱性

・セッション管理の不備による脆弱性

など

 

 

ーー 感想 --

 

・基本情報を取った人には重複した内容も多く、簡単すぎるかもしれない。とはいえ、HTTPヘッダーの各ステータスやHTTPSなど、中身については知らないものも少なくはなかった。

・最初に入るには悪くはないかもしれないがオススメはしない。難易度がとても半端で、もう少し解説があったらという用語がいきなり出てきたりする。

金持ち父さん 貧乏父さん

■6つの教え

 

1 金持ちはお金のために働かない

 

 <=> お金のために働くこと。

 

2 お金の流れの読み方を読む

 

・金持ちになりたければお金について勉強しなければならない。

・資産と負債の違いを認識し、資産を増やすこと。

 資産 ー 収入になるもの(株式、債券、不動産、知的財産等)

 負債 ー 支出になるもの(ローン、クレジットカードの未払い分等)

・損益計算書と賃借対照表からお金の流れを読むこと。

・「金持ちは資産を買う」

 「貧乏人の家計は支出ばかり」

 「中流の人間は資産と思って負債を買う」

 

3 自分のビジネスを持つ

 

・自分がその場にいなくても収入を生み出すビジネス。

マクドナルドは不動産ビジネス。

 マクドナルドのフランチャイズ権を買う人はその土地の代金を肩代わりしている。

 マクドナルドは世界で一番土地を所有している。

 

4 会社を作って節税する

 

・ファイナンシャルインテリジェンス

 1 会計力(ファイナンシャルリテラシー

  財務諸表を読んで理解できる能力。

 2 投資力

  戦略と方式が必要

 3 市場の理解力

  投資のファンダメンタルな側面やテクニカルな側面を知ること。

 4 法律力

  会社にすることで税制面での優遇を受けることができる。

 

5 金持ちはお金を作り出す

 

・ファイナンシャルインテリジェンスを高めること。

・市場の動向に合わせて投資対象を変化させることや不動産買い替えなど。

・度胸を持って臨むこと。

 

6 お金のためでなく学ぶために働く

 

・お金のためでなく学ぶために働くこと、そして長い目で見て学ぶこと。

 

■TIPS

・資産形成や教育等、自分への支払いを先に済ませる。

・強い目的意識を持つ。

 ー「やりたいこと」と「やりたくないこと」を明確にする。

・贅沢品は資産に買わせる。

・投資を容易に感じさせるヒーローを持つこと。

・欲しい、知りたいと思ったらまずは与え、教えること。

 

 

■感想とか

・資産を増やさなあかん。不労所得を生み出す株、不動産、債権などはもちろん、自分の能力という意味でも。

・お金のためでなく学ぶために働く。

・不動産や会社の設立なんかは日本の法律や状況によってどうなんか分からん。

 

コーディングを支える技術

ーー 第1章 言語を深く効率的に学ぶには ーー

 

■「比較から学ぶ」

・複数の言語を比較しながら学ぶ。

・何がいくつもの言語で共通していることなのかを学べる。

 

■「歴史から学ぶ」

・言語がどう変わったか、変わる前にはどういう問題点があったかを学ぶ。

・言語が持ついろいろな機能がなぜ生まれたのかを学べる。なぜ存在するのか。

 

 

ーー 第2章 プログラミング言語を俯瞰する ーー

 

プログラマの三大美徳ー無精・短気・傲慢ー

・「無精」エネルギーの総支出を減らすために、多大な努力をするようにあなたを駆り立てる性質。

 

■言語により「楽さ」は異なる

・高速なコードを書くのが楽な言語、可読性の高い言語、言語仕様を把握するのが楽な言語など、楽なことはそれぞれ。

・目的によって適切な言語は異なる。

 

 

ーー 第3章 文法の誕生 ーー

 

文法とはどういう文字列を書いたらどういう構文木ができるか、というルール

簡単な文法ではなく、自然と思える書き方を実現できる文法が受け入れられた。

 

 

ーー 第4章 処理の流れのコントロール ーー

 

while は条件式、for は回数で繰り返しを制御。

if や for や while などの制御構文は、これらがなくとも go to を使うことで実現できる。この意味で、制御構文は 「 制限付きのgo to 」と言える。しかし、可読性や簡易さを考慮すると制御構文を使うべき。

 

 

ーー 第5章 関数 ーー

 

■関数の役割

「理解」意味的にひとかたまりのコードをくくり出して名前をつけることで、そのコードが何をしているか把握しやすくなる。

「再利用」プログラムが短くなる。何度も同じコードを読む必要がなくなる。

 

 

ーー 第6章 エラー処理 ーー

 

■エラー処理の2つの方法

「返り値で伝える」失敗を見落としたり、コードが読みづらくなったりすることが。

「例外処理」対にしなければならない処理を正しく対にしづらくなったり、関数がどんな例外を投げるかが、その関数のコードからは伝わらなくなる。

 

 

ーー 第7章 名前とスコープ ーー

 

ローカルな「静的スコープ」とグローバルな「動的」スコープ

 

 

ーー 第8章 型 ーー

 

正直あんまりよく分からんかった。

以前は「静的型付け」が多かったが、最近は「動的型付け」が増えている。

「静的型付け」ー「変数名」「値が保存されているメモリ上の位置」「そのメモリの内容はどういう種類の値か」をセットにして持っている。

「動的型付け」ー上記の「種類の情報」に加えて、値自体までセットになっている。

 

 

 ーー 第9章 コンテナと文字列 ーー

 

■配列と連結リスト

・多くの言語が配列と連結リストともにサポートしている。

・「配列」メモリ上に連続して値を格納している。

 ○ n番目の要素をすぐに取り出せる。(O(1))。メモリの容量が少ない。

 × 値の挿入には時間がかかる。

・「連結リスト」メモリ上で値と次の値のアドレスを連続して格納する。

 ○ 挿入が容易。

 × n番目の要素の取り出しに時間がかかる。

 

■ハッシュテーブルと木

・辞書、ハッシュ、連想配列の格納にはハッシュテーブルか二分木が用いられる。

・「ハッシュテーブル」キーをハッシュ関数を使って整数に変換し、その整数のアドレスに値を格納する。

 ○ 計算量が少ない、被りがなければO(1)。

 × ハッシュテーブル用の大きな配列を用意する必要があるため、メモリを消費する。

・「二分木」右を大きい、左を小さい値として、木を形成する。

 ○ メモリの消費が少ない?

 × 計算量がかかるO(log n)。

 

■文字列

・何が文字であるかは、取り決めによって決まる。

文字集合文字符号化方式、文字列の実装は言語によって異なっている。

 

 

ーー 第10章 並行処理 ーー

 

これでプロセスとスレッドの違いや仮想アドレスなんかをまず見てみよう。

http://moro-archive.hatenablog.com/entry/2014/09/11/013520#

 

■処理を切り替える2通りの方法

・「協調的マルチタスク」区切りのいいところでタスクを交代する。タスクが無限ループになった場合などは変更されないなどのデメリット。

・「プリエンティブマルチタスク」強制的にタスクが交代される。現在のOSで採用されている方法。

 メモリを複数のプログラムで共有するか否かで問題が起こった。トランザクションなどの解決策が模索されている。

 

 

ーー 第11章 オブジェクトとクラス ーー

 

■オブジェクト

オブジェクト指向は現実世界のモノの模型を作るために生まれてきた。

・言語によって言葉自体の意味や実現方法は異なる。

 

 ■クラス

・まとまったものを作る生成器

・どういう操作が可能かという仕様

・コードを再利用する単位

 

 

ーー 第12章 継承によるコードの再利用 ーー

 

■3種類の継承

・一般化 / 抽象化

・共通部分の抽出

・差分実装

 

■多重継承による名前解決の問題へのアプローチ

・多重継承自体の禁止

・メソッド解決順序自体の工夫

・Mix - In による処理の混ぜ込み

・トレイト

 

■クラスの役割

・「再利用の単位」機能ごとの、余計なものを持っていない、小さなクラス

・「インスタンス生成器」完結した、必要なものを全部持った、大きなクラス

 

 

 

ーー 感想 ーー

・後半になるにつれてちょっと難しくなった。ある程度の具体を経験していないと分かりにくかったり、例外処理や並列処理なんかは前提がないと分からなかったりするのではないかな、と。

・とはいえ、この本の目的である、比較や歴史からプログラミングを学ぶという目的はある程度は達成できたのではないかと思う。

・後半はもう少し経験を積んで、あるいは他の言語を自分で学んで違いを実感した上で再読したいと思った。

プログラムはなぜ動くのか(前編)

ーー第1章 プラグラマにとってCPUとはなにかーー

 

■プログラム実行のイメージ

1、高水準言語でプログラムを記述する。

2、プログラムをコンパイルしてマシン語のEXEファイルに変換する。

3、プログラムの起動時に、EXEファイルのコピーがメモリー上に作成される。

4、CPUがプログラムの内容を解釈・実行する。

 

■CPU

・メモリー ー 大抵の場合は、メイン・メモリー(主記憶)。CPUと制御用チップなどを介して繋がっていて、命令とデータを格納する。

・機能面から考えると、「レジスタ」「制御装置」「演算装置」「クロック」の4つの装置から構成されている。

・「レジスタ」処理対象となる命令やデータを格納する領域。

・「制御装置」メモリー上の命令やデータをレジスタに読み出し、命令の実行結果に応じて、コンピュータを制御する。

・「演算装置」メモリーからレジスタに読み出されたデータを演算する役目を持つ。

・「クロック」CPUが動作するタイミングとなるクロック信号を発生させる。

 

■条件分岐と繰り返しの仕組み

・プログラムの流れはプログラムカウンタによって決められる。

・プログラムの流れは3種類

「順次進行」アドレスの値の順に命令を実行すること

「条件分岐」条件に応じて任意のアドレスの命令を実行すること

「繰り返し」同じアドレスの命令を何度か繰り返し実行すること。

 

■関数呼び出しの仕組み

・コール命令とリターン命令によって実現される。

・「コール命令」関数の入り口のアドレスをプログラム・カウンタに設定する前に、関数呼び出しの次に実行すべき命令のアドレスをスタックに格納。

・「リターン命令」スタックに保存されたアドレスをプログラム・カウンタに設定する。

 

■TIPS

・ベースレジスタとインデックスレジスタによって配列を実現する。

・CPUで主にできること

「データ転送命令」「演算命令」「ジャンプ命令」「コール/リターン命令」

 

 

ーー第2章 データを2進数でイメージしようーー

 

2進数について、シフト演算、補数とか

 

 

ーー第3章 コンピュータが少数点数の計算を間違える理由ーー

 

浮動小数点数やそれに用いられる、正規表現やイクセス表現など

 

 

ーー第4章 四角いメモリーを丸く使うーー

 

モリーの仕組みや、スタック、キュー、リスト、二分探索木など。

 

 

ーー第5章 メモリーとディスクの親密な関係ーー

 

ストアドプログラム方式、ディスクキャッシュ、仮想記憶、ページング、DLLファイルの関数共有など。