「あなたの1日は27時間になる」を読んだ。

はじめに

最近仕事に個人開発に読書に資格勉強にゲーム等やりたいことが多すぎて時間が全然足らない…と思っていたので、本書籍を読んだ。
「27時間になる」というのは、
忙しい毎日に誰にも邪魔されない「自分だけの3時間を作る（自分の時間が増える）」という意味で、その方法について説明されている。
参考になったものについて備忘録として残す。

超リアルで、超具体的な目標を決める

1日に使える自分の時間を増やすことを目標にするなら、
その目標を立てた理由を「1日を有意義に使えるようになりたい」という曖昧に考えるのではなく、 1日の時間を増やせたらどんな自分になれるのか具体的に考えることが必要だという。

著者の周りで税理士試験に合格されている方も、
「立派な税理士になって、中小企業のために尽くしたい」といった抽象的な目標ではなく、「青山に100㎡のオフィスを持って、従業員を30人くらい雇う！」とか「年収3000万で、〇〇という車を買うんだ！」と具体的なイメージを持っている人が合格しているとのこと。
1日を27時間にするという目標を途中で投げ出さないためにも、不純でも下世話でもいいので、超リアル・超具体的な目標を定めること。

自分締め切りを作る

相手と約束した締め切り期限を前倒しした「自分締め切り」を設けることで「時間に追われるのではなく、時間を飛び越す人」になれる。

チェックリストを作る

チェックリストを作ることで「最低限、ここだけ合わせれば良い」という思考停止状態を作ることができる。
結果、「これで大丈夫かな？」という迷いを無くせて作業スピードがアップできる。
チェックリストに盛り込むものは「ここだけは確実に合っていなくてはいけない、死守しなければならない」というポイントだけに絞ること。

時間の予実管理で、どんどん時間が増えていく

今日はXXとXXをやろうと決めたものの、予定通りに進まないことがある。
それは自分キャパ（自分が1日で何をどれくらいできるのか）を知らないために起こることだという。 まずは「自分キャパ」を正確に知るため、仕事やタスク1つのひとつの作業時間を見積もってみて、実際の作業はどれくらいかかるのか測ってみる。
この「時間の予実管理」の最大のメリットは、時間に対する感覚が研ぎ澄まされること。 時間が有限であることを意識しつつもその限られた予算の中で賢く時間を使うことができるようになる。

おわりに

仕事の時短術を中心に説明されていて参考になった。
自分の時間を作るためにも、自分の時間を作ったことでどうなりたいのか具体的な目標を考えてみようと思う。

「努力2.0」を読んだ。

はじめに

本書籍はプロゲーマーのときど氏が日々実践する「努力のやり方」をまとめたものである。
ときど氏はプロゲーマーになってから順風満帆な日々を送っていたが、あるとき全くと言っていいほど勝てない時期を経験したという。
その時期を乗り越えるため、今までの努力の仕方（努力1.0）を見直したのが「努力2.0」だという。
本書籍は格闘ゲームだけじゃなく、仕事にも人生にも役立つノウハウが記載されている。 その中でも私が特に参考になったものを備忘録として残す。

・負け試合には全てが詰まっている。

負けに不思議の負けなしという言葉の通り、負ける原因は可視化されている部分が必ずあるという。
負け試合を見返すとき大事なのは、最初の段階は「質より量」とのこと。
膨大な試合を次から次へと見返すことで、「また同じようなことをしているな」という
悪い癖やあからさまにはわからなかったミスに気付けるという。

・本番は本番に慣れる練習

本番には練習だけでは味えないプレッシャーがある。 本番慣れしてないことで失敗したとしても、正面からそれを受け止め経験することで、少しずつこなせるようになっていく。
普段の練習とは異なる場に立つからこその学びがあるという。

情報を共有することは自分にも相手にもメリットがある。

どんな天才でもたった一人で思いつけるアイディアの数には限界がある。 いろんな人との情報共有は、「普通はこうだよな」という思考の枠を取り払ってくれる。

・少し背伸びした環境を選ぶ

まずは集団の中で誰でもできることをきちんとできるようになる。これで60点。 そこから少しずつ75点から80点（上位20%くらい）を目指して達成したら次のレベルの環境に移る。 新しい環境では平均以下の存在からやり 直すことになるが、 再びその新しい環境での平均レベルを目指す。これを繰り返すことでより成長できるという。

おわりに

ときど氏の自伝として読んでも面白い本だった。
自分も対戦ゲーム（スマブラ）をやってるので インプット→アウトプット→フィードバックのサイクルを素早く回して勝率を高めたい。

「達人に学ぶDB設計」を読んだ。

はじめに

本書籍はデータベース設計の考え方、
実践ノウハウ、バッドノウハウ等について説明された書籍となります。

1章　

データベースがシステムおよび開発工程において持つ重要性を、
システムにおける位置づけや、開発プロセスとの関連から説明されていた。
「データベース設計を制する者はシステムを制す」と筆者が考える理由は、
システムに合わせてデータを作るのではなく、システムがデータのフォーマットに合わせて作られるからだと言う。

2章

論理設計／物理設計、RAID、バックアップ、リカバリとリストアについて説明されていた。
論理設計には大きく分類して4つのステップが存在し、
物理設計には大きく分類して5つのステップが存在する。
それぞれのタスクの内容と、行う時に気を付けるべきポイントについて説明されていた。
RAID、バックアップ、リカバリとリストアについて、
いくつか種類があり、それぞれのメリット、デメリットについて説明されていた。

3章

正規化について説明されていた。
正規化はデータの冗長性をなくしていく作業のこと。
その目的は更新時のデータ不整合を防止することにある。
第一正規化から第五正規化まで説明されていたが、
第三正規化までを考えれば十分とのこと。

4章

E-R図に関する説明がされていた。
エンティティ（テーブル）の数が増えると、
テーブル同士の関係がわかりにくくなり、設計に支障をきたす。
この問題を解決する手段がE-R図。
IE表記法と、IDEF1Xの記述方法について説明されていた。

5章

論理設計とパフォーマンスについて。
大原則として可能な限り、高次に正規化する必要があると述べたうえで
パフォーマンスのために非正規化をすることもあると説明されていた。

6章

インデックスと統計情報という二つの観点を通して、
ハイパフォーマンスを実現する方法について説明されていた。

DBのパフォーマンスを決める主な要因は、
ディスクI/Oの分散（RAID）、結合（正規化）、インデックスと統計情報とのこと。

インデックスとはプログラミング言語的な表現をすると（x,α）という形式のキーバリュー。
xはキー値、αはそれに結びつく情報（実データ、あるいはそれへのポインタ）を意味する。

統計情報はSQLの最適なアクセスパスを見つけるために必要な地図情報のこと。
SQLに「こんなデータがほしい」と依頼したら、カーナビのように、最短と判断した経路を選んでくれる。

7章

バッドノウハウ（アンチパターン）と呼ばれるろくでもない設計について説明されていた。
バッドノウハウの事例と、なぜバッドノウハウは生まれるのか、バッドノウハウの何が「悪」なのかを解説。
バッドノウハウがダメな理由は、システムの品質を左右する上に後から変更することが容易ではないこと、 なぜダメ設計が生まれるかというと「何も考えていない」ためとのこと。

主なバッドノウハウとして
列の値の意味が途中で変わる「ダブルミーニング」、
あらゆるマスタテーブルを一つのテーブルに放り込んでごった煮させた「単一参照テーブル」、
顧客マスタAと顧客マスタBといった感じで、同じ役割のテーブルが二つ存在する「ダブルマスタ」が存在する。

8章

グレーノウハウについて説明されていた。
論理設計には、バッドノウハウとまでは言えないものの、きわどいライン上に位置するグレーゾーンが存在する。
主なグレーノウハウとして
代理キー、列持ちテーブル、アドホック（臨時の）な集計キー、多段ビューが存在する。

9章

RDBで木構造を扱う方法について説明されていた。
木構造とフラットな二次元表は相性が悪くRDBで表現するには向かない構造らしい。
しかし、RDBもこの苦手を克服するため、
木構造を扱う方法として、隣接リストモデル、入れ子集合モデル、入れ子区間モデル、経路列挙モデルを生み出して苦手を克服しつつあるとのこと。

おわりに

私は仕事で主にバックエンドの言語を使って開発をすることが多いので、
DBに関してしっかり理解しておこうと思い本書籍を購入しました。
本書籍はDBの基本から、実際の開発で気をつけるべき点まで盛りだくさんの内容で
とても参考になりました。

「オブジェクト指向でなぜ作るのか」を読んだ。

はじめに

本書籍はタイトルにもある通り
オブジェクト指向でなぜ作るのか？
この質問にしっかり答えることを目的にした書籍となる。

読んだ感想

プログラミングの歴史を知ることで、
オブジェクト指向で開発する必要性について理解することができた。
オブジェクト指向は構造化プログラミングの限界を打ち破ることができる技術であるということがわかった。

オブジェクト指向とは

オブジェクト指向は、モノ中心に組み上げる開発手法で、
ソフトウェアの保守や再利用をしやすくすることを重視する開発手法のこと。

オブジェクト指向で作る理由

筆者は「ソフトウェアを楽に作りたいから」と答えると言う。

オブジェクト指向が難しいと言われる理由

・専門用語が多い
　→クラス、インスタンス、ポリモーフィズム、継承、オーバライド、属性…

・比喩を使った説明の方が強く印象に残ってしまう
　→たい焼きの型がクラスで、たい焼きがインスタンス。
　　ポリモーフィズムを使うことで、吠えろ（cry）と命令すれば、犬ならワンと鳴き、猫ならニャーと鳴くよう実装できる。

・オブジェクト指向というコンセプトが抽象的。

構造化プログラミングの限界

逐次、条件分岐、繰り返しの3つの構造だけで表現する構造化プログラミングによって、
プログラムをシンプルに作成できるようになったが、
構造化プログラミングには、
「グローバル変数」と「貧弱な再利用」という二つの大きな問題を抱えていた。

グローバル変数問題

ローカル変数や値渡しの仕組みを導入したことで、情報の受け渡しを必要最小限に抑えることが可能になったが
サブルーチンの実行期間を超えて保持する必要のある情報は、グローバル変数として保持せざるを得なかった。
グローバル変数の何が問題かというと、潜在的にプログラムのどこからでも使われる可能性があること。
何かの事情でグローバル変数を変更する時には、影響範囲を確かめるためロジックを全て調べないといけない。
この問題はプログラムの規模が大きくになるにつれ深刻になる。

貧弱な再利用問題

構造化プログラミングでは、共通部品として作れるものが限定的だった。
（数値計算や文字列処理など基本的な処理（サブルーチン）を共通部品として再利用することはできた）

オブジェクト指向

上記の問題を解決するため、オブジェクト指向が登場した。
オブジェクト指向では構造化プログラミングでは存在しなかった、クラス、ポリモーフィズム、継承が追加された。

クラスは、
「まとめて、隠して、たくさん作る仕組み」を提供する。
（クラスを定義することでサブルーチンと変数を「まとめ」、他のクラスから「隠し」、インスタンスを「たくさん作る」ことができる。）

ポリモーフィズムは、
サブルーチンを呼び出す側のロジックを一本化する仕組み、すなわち共通メインルーチンを作るための仕組みを提供する。
オブジェクト指向が登場する前は共通サブルーチンはあったものの、共通メインルーチンはなかった。
フレームワークやクラスライブラリと呼ばれる大規模な再利用部品群も、ポリモーフィズムがあったからこそ可能になったとのこと。

継承は、
クラスの共通部品を別クラスにまとめる仕組みを提供する。
この仕組みを利用することで、変数とメソッドをまとめた共通クラスを作って、
別のクラスからその定義を丸ごと拝借することが可能になる。

三大要素のまとめ

オブジェクト指向以前のプログラミング言語では、共通ロジックをまとめる仕組みはサブルーチンだけだった。
そして、サブルーチンとグローバル変数が独立していたため、グローバル変数をどのサブルーチンで変更しているのか
わかりづらいことが大きな問題になっていた。
オブジェクト指向では、グローバル変数問題を解決する仕組みとしてクラスを用意した。
さらに、ポリモーフィズムと継承の仕組みを提供したことで、サブルーチンではできなかったロジックの共通化が可能になった。

おわりに

本書籍では、オブジェクト指向でなぜ作るのか？について説明するだけでなく、
プログラミングから派生した応用技術（UMLやアジャイル開発手法）についても説明されている。

私は仕事でオブジェクト指向言語を使って開発しているものの、
オブジェクト指向でなぜ作るのか、何が便利なのかは理解できていなかったので、
本書籍はとても参考になった。