Blogs

Scalaは昔少し勉強して挫折した経験があります。月並みにいえば、その時こういう本があったらなぁという感想です。

そもそも会社でのポジションはSREなので、Scalaを実務で書くことはほとんどありません。Pythonは書くシチュエーションがありますが、関数型を多用することもありませんでした。

本書の読了が見えてきた頃からこの本を片手にScalaでCodility の問題を解く会社内の集まりに参加させてもらっています。Atcoder にも参加するようになりScalaプログラミングを楽しんでいます。

構成

Scalaの基本的な使い方からScalaプロジェクトを管理する上で必須のsbtやユニットテストなども含まれており、業務でScalaを使い始める人もは網羅的な内容となっています。 もちろんこの本を読んだだけでScalaを使いこなせるわけではなく、最終章の締めくくりにあるようにどんどん書いていくことが必要ですが、この本の内容を知っていたらどれだけとっかかりがスムーズだろうとか思います。

新人が入ってくるこの時期、Scalaをメインの言語として扱っている会社はこの本をとりあえず渡しておくのもありかと思います。

感想

そもそものきっかけはScalaでバックエンドを書いている会社に入ったのでScalaかけるようになりたいなと購入しました。 普段はPythonを利用していて、昔はJavaを書いていた頃がありましたが、基本的にはインフラ関連の業務が多く、Terraformと戯れることが多い毎日です。

この本の前提である1つ以上のプログラミング言語に慣れていることという点はクリアしていますが、第2章のScalaの基礎や第4章のコレクションについてはなかなか苦労しました。ここはひたすら写経ですね。

苦労したとはいえ、著者の方々がScalaに対して敷居を下げようと努力している所は随所に感じました。 サンプルプログラムや図を用いたり言い換えを行ったりして置いてきぼりにならないような配慮が随所に見受けられました。

例外処理や並列処理にも言及してあるのも良買ったです。特に例外処理はTryとかEitherとかこれまでの経験とは一味違う機構をScalaは備えているので助かりましたし、そもそも業務では必須の知識なので。本書の構成としても第3章という前の方に置いてある点から重要視しているのかなと思いました。

並列処理についてもサンプルを写経することで理解が進みました。ただ、競技プログラミングをやっているだけではなかなか登場することがないので、もうちょっと何らかの他の本を読むなりして補強していかないといけないと感じている部分です。

非機能系としてはログに関しては言及がなかったように思います。是非ログについても取り上げて欲しいですね。

そして9章、10章では何をとっかかりに調べれば良いかわからない応用的な部分や、より良いコーディングの指針などが書いてあって、これでScalaはとりあえず書けるという気にさせてくれました。 一旦かける気になったら、あとは書くだけ。おかげで前述の通り、CodilityやAtcoderでScalaプログラミングを楽しんでいます。

まとめ

初学者に優しい本書だからこそ、誤植が一部あった点が残念でした。 技術評論社さんへ連絡したらすぐにサポートページを更新してくれましたが、そもそもサポートページにたどり着くまでのステップはないに越したことはありません。

ただ、その点を差し引いても非常に網羅的で、Scalaへのいろんな障害を乗り越える上で非常に有用な本でした。

Terraformのリファクタリング楽しいですね。ついついいろんなハードコードを変数化するのに熱中してしまいます。

AWSをTerraformで構築・運用するときAWSのアカウントIDが必要になることがあります。 特にVPC Peering、Private Link, SNS, S3のBucket Policyなど、クロスアカウントで利用できるリソースなどは別アカウントのIDが欲しくなる事があります。 一つならまだしも2つ以上アカウントIDと連携したりすると混乱するので、ここにハードコードしたIDではなくわかりやすい変数名、しかもリモートステートで別アカウントのIDが参照できれば良いなと思いました。

自アカウントであれば、aws_caller_identityを利用すれば簡単に取得することができます。

1

data "aws_caller_identity" "self" { }

どこかに上記のような記述をすると、下記のような形でアカウントIDを参照できます。

1

"${data.aws_caller_identity.self.account_id}"

これにリモートステートの仕組みをプラスすることで、別アカウントのIDを変数化できました。 参照される側のアカウントをA, 参照する側のアカウントをBとしています。

参照される側のアカウントの設定

まずは参照されるアカウントAの設定です。 別アカウントBに変数を公開するにはoutputとして登録する必要があります。 今回は変数名をaccount_idとして、AWSのアカウントIDを公開しています。

1
2
3
4
5

data "aws_caller_identity" "self" {}

output "account_id" {
  value = "${data.aws_caller_identity.self.account_id}"
}

また、S3のバケットポリシーを編集して、TerraformのStateをアカウントBが閲覧できるように設定をする必要があります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ExampleStatement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::[アカウントBのID]:root",
                ]
            },
            "Action": [
                "s3:GetBucketLocation",
                "s3:ListBucket",
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::[アカウントAのStateが入っているBucket]",
                "arn:aws:s3:::[アカウントAのStateが入っているBucket]"/*"
            ]
        }
    ]
}

参照される側のアカウントの設定

参照する側のアカウントBでは参照するアカウントAのStateを参照する設定を追加します。

1
2
3
4
5
6
7
8
9

data "terraform_remote_state" "account_a" {
  backend = "s3"

  config {
    bucket = "[アカウントAのStateが入っているBucket]"
    key    = "state"
    region = "ap-northeast-1"
  }
}

例えばアカウントAとBのVPC Peeringの設定とかで利用できます。

1
2
3
4
5
6

resource "aws_vpc_peering_connection" "acount_a_b" {
  peer_owner_id = "${data.terraform_remote_state.account_a.account_id}"
  peer_vpc_id   = "[アカウントAのVPC ID]"
  vpc_id        = "[アカウントBのVPC ID]"
}

アカウントAのVPC IDもリモートステートで取得する手もありますが、今回は割愛しました。

まとめ

Terraformを書いていていろんなアカウントと連携する設定を書くときに、アカウントID部分が数字の羅列だと混乱するので変数化してみました。 クロスアカウントの機能は充実していますし機能拡張もされ続けています。 何かと使い所はあるのではないでしょうか。

最近はDockerの環境を運用することが多いので、すっかりEC2に対してAnsibleで環境を構築したりメンテナンスしたりすることが減りました。 それでもAWS上のECSをEC2ベースで運用していて、EC2に監視用のエージェントなどをインストールしているケースなどもあると思います。 例えば自分の場合だとPrometheusの監視モジュール、node exporterを各EC2にインストールしています。

今後もECS OptimizedなEC2はどんどん更新されていくので、これを機にPackerを導入してベースイメージの作成をすることにしました。 ちなみにPackerを導入しようと思ったのは先日発表されたDockerの脆弱性対応のためEC2をアップデートしないといけなかったことがきっかけです。

というわけでPackerは初めて触ったわけですが、ほとんどはまることもなくAnsibleをプロビジョナーとする構成を作ることができました。 それでも何点かつまずいた点があったので、残しておきます。

環境は下記の通りです。

• Mac OS Mojave 10.14.3
• Packer 1.3.4
• Ansible 2.6.5

Packerのインストール

Macを前提とします。brewで簡単にインストールできます。

$ brew install packer

最終的にbuild.jsonは下記のようになりました。 ECS用のEC2の最新版を取ってきてansibleでプロビジョンしています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

{
    "provisioners": [
	{
	    "type": "ansible",
	    "playbook_file": "./playbook.yml"
	}
    ],
    "builders": [{
	"type": "amazon-ebs",
	"region": "ap-northeast-1",
	"source_ami_filter": {
	    "filters": {
		"virtualization-type": "hvm",
		"name": "amzn-ami-*-amazon-ecs-optimized",
		"root-device-type": "ebs"
	    },
	    "owners": ["591542846629"],
	    "most_recent": true
	},
	"instance_type": "t3.nano",
	"ssh_username": "ec2-user",
	"ami_name": "amzn-ami-amazon-ecs-optimized-20190225",
	"subnet_id": "subnet-xxxxxxxxxx",
	"associate_public_ip_address": true
    }]
}

つまずきを何点か

default subnetが存在しない場合

今回、Ansibleでプロビジョンするにあたり、インターネット上のモジュールをダウンロードする必要がありました。 インターネットにアクセスできない状態だとAnsibleが途中で落ちます。

PackerはPublic IPを取得できるdefault subnet上でAMIを起動しようとします。 default subnetが存在しない環境だとSubnetを指定してあげる必要があります。 そこで上記のようにsubnet_id でsubnetを指定しています。

PublicIPが自動割り当てされないSubnetの場合

Subnetの項目のうち、Auto-assign public IPv4 addressがNoになっている場合、Public IPが自動で割り当てられません。 “associate_public_ip_address”: true　としてPublic IPが割り当てられるようにしましょう。

Ansibleを含めたディレクトリ構成

ansibleのPlaybookをどこに設置すれば良いか、一瞬悩みました、 なんのことはない、build.jsonと同じ階層に置けば良いだけでした。 ディレクトリ構成はこんな感じになりました。

├── build.json
├── playbook.yml
└── roles
    └── exporter
        ├── handlers
        │   └── main.yml
        ├── tasks
        │   └── main.yml
        ├── templates
        │   ├── node_exporter.default
        │   └── node_exporter.init.d.amzn.j2
        └── vars
            └── main.yml

まとめ

Packerはやれることも単純なこともあり、そこまで複雑でハマることもないツールです。 何点かつまずきポイントを載せましたが、エラーメッセージを見ればわかるっていうものでした。 単純ですが、OSのバージョンアップに追従したベースイメージを作成する際に非常に重宝しています。

バックアップは取っていてもリストアできないと宝の持ち腐れですね。

ibdataのコールドバックアップは取っていて、サクッと一部のテーブルのデータのみリストアする方法です。 稼働中のMySQLを止める必要がないので、一部のテーブルだけ復旧したい場合や、とりあえず昔のテーブルの状況を見たい場合などに利用可能です。 データベース全体のリストアではないので、リストアの時間を短縮したいときに使えるかと思います。

やり方としては公式のドキュメントに書いてある通りなのですが、もうちょっと細かくやり方を見ていきます。 innodb_file_per_tableがONになっていて、テーブル毎にibdataが作成されていることが前提になります。

大まかな手順は下記のようになります。

1. 復旧したいデータベース・テーブルがない場合はあらかじめ作成しておく
2. 該当テーブルへの変更をLOCKする
3. テーブルスペースを削除(ibdファイルを削除)
4. 復旧したいibdファイルをコピーする
5. テーブルスペースをインポート
6. Lockを解除

下記のバージョンで検証しました。

• MySQL: 5.6.42
• CentOS: 7.5

準備

テストのためのデータベースとテーブル・テストデータを作成します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

mysql> CREATE DATABASE `test`  CHARACTER SET utf8mb4;
mysql> use test;
mysql> CREATE TABLE `test_table` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(255),
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

mysql> insert into test_table (name , updated_at, created_at) value ('hoge', now(), now());
mysql> insert into test_table (name , updated_at, created_at) value ('fuga', now(), now());

mysql> select * from test_table;
+----+------+---------------------+---------------------+
| id | name | updated_at          | created_at          |
+----+------+---------------------+---------------------+
|  1 | hoge | 2018-12-01 11:11:37 | 2018-12-01 11:11:37 |
|  2 | fuga | 2018-12-01 11:11:57 | 2018-12-01 11:11:57 |
+----+------+---------------------+---------------------+

MySQLを止めて、/var/lib/mysql/test/test_table.ibd をバックアップします。

1
2

$ sudo systemctl stop mysqld.service

リストア

1. リストア先のデータベース・テーブルの準備

復旧したいデータベース・テーブルがない場合はあらかじめ作成します。

1
2
3
4
5
6
7
8
9

mysql> CREATE DATABASE `test`  CHARACTER SET utf8mb4;
mysql> use test;
mysql> CREATE TABLE `test_table` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(255),
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

もちろんこの段階ではデータは存在しません。

1
2

mysql> select * from test_table;
Empty set (0.00 sec)

2. 該当テーブルへの変更をLOCK

該当テーブルへの変更をLOCKします。

1
2

mysql> LOCK TABLES test_table WRITE;
Query OK, 0 rows affected (0.00 sec)

3. テーブルスペースの削除

テーブルスペースを削除(ibdファイルを削除)します。

1
2

mysql> ALTER TABLE test_table DISCARD TABLESPACE;
Query OK, 0 rows affected (0.00 sec)

4. 復旧するファイルの移動

復旧したいibdファイルをコピーします。

権限も正しくmysqlユーザーで読み書きできるように設定しましょう。

1
2
3
4
5
6

$ sudo ls -la /var/lib/mysql/test/
drwx------. 2 mysql mysql  4096 Dec  1 11:44 .
drwxr-xr-x. 6 mysql mysql  4096 Dec  1 11:42 ..
-rw-rw----. 1 mysql mysql    67 Dec  1 11:42 db.opt
-rw-rw----. 1 mysql mysql  8670 Dec  1 11:42 test_table.frm
-rw-r-----. 1 mysql mysql 98304 Dec  1 11:45 test_table.ibd

5. テーブルスペースをインポート

テーブルスペースをインポートします。

1
2

mysql> ALTER TABLE test_table IMPORT TABLESPACE;
Query OK, 0 rows affected, 1 warning (0.02 sec)

6. Lockを解除

ロックを解除します。 また、データが存在することが確認できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

mysql> UNLOCK TABLES;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from test_table;
+----+------+---------------------+---------------------+
| id | name | updated_at          | created_at          |
+----+------+---------------------+---------------------+
|  1 | hoge | 2018-12-01 11:11:37 | 2018-12-01 11:11:37 |
|  2 | fuga | 2018-12-01 11:11:57 | 2018-12-01 11:11:57 |
+----+------+---------------------+---------------------+

まとめ

AWSのRDSなど、マネージドのデータベース環境を利用することが最近は多くなりました。 RDSならリストアもマネージコンソールでぽちぽちやれば簡単に切り戻せて便利ですね。

とはいえ、まだMySQLを様々な理由で自分達で運用している環境もあるかと思います。 コールドバックアップから手軽にテーブル単位でリストアできるのは便利ですね。

OreillyのDocker本に続いて読んだのが、現時点では比較的最近出版された本書でした。

出来るだけ新しいDocker本で最近の情報で知識をアップデートしたかったのと、Kubernetesの説明が充実してそうというのが本書を手に取った動機です。

Dockerに正式採用されたKubernetesと、Swarmの違いなんかも体験できればなと思いました。

内容

Dockerの基本的な使い方から入るところは、先に読んだOreilly本と同じでしたが、目論見通りOreilly本の時点から色々変化があった事を知ることができました。 大きな変化はKubernetesの正式採用などがありました。 小さな変化ははDockerコマンドについてのコラムにあった docker container というコマンド形式で、 以前は省略していた “container"の指定が現在は推奨されつつある等です。 dockerコマンドではpruneオプションなんかも知ることができました。

構成としてはDockerの基本を学び、オーケストレーションを体験し、実際に運用する上での知識をつけていく流れなのですが、 サンプルで作成したToDoアプリを題材に、Swarmを経て Kubernetesへ載せていく流れでオーケストレーションについての知識が深められ非常に分かりやすかったです。 また、本番で使っているからこその著者のDockerについての考え方や知見が随所に散りばめられており、 後半の章、特に9章での軽量なDockerイメージの作り方はDockerの内部構造を意識する上でも非常にためになりました。

特に面白かった所

docker-composeで作成したToDoアプリが、最終的にKubernetesに載る所が、１つのクライマックスかと思います。 本書ではGCPでKubernetesを利用していますが、私はEKSでサンプルを試していきました。 ロードバランサの取り回しなど、細かい点は考慮が必要ですが、どちらのプラットフォームでも動作させれる点が、Docker, Kubernetesの強みであると実感できました。

また、コラムが非常に充実していて、日々運用する上で何に困って、どういうツールで解決していったかを知ることができ、運用の雰囲気を知る上で有用でした。

まとめ

Dockerの進化を感じつつも、実践という名を冠しているだけあって、著者が本番でDockerを運用し、格闘して得た知識が詰まっています。 私自身はKubernetesに移行するかは検討段階で、まだまだやる事が山積みですが、本書を片手に現在のDockerの運用を改善しつつ、来るべきオーケストレーションに備えたいと思います。

Dockerのチュートリアルを軽く触った事しかなかったのですが、本番でDockerを運用しているシステムを触ることになったので手に取りました。 しかしDockerは進化のスピードが早くてどの本を買おうか非常に迷いましたね。

この本は2016年の出版ですが、パッと見た所そこまで難しすぎず、手を動かしながらDockerを体験できそうだったのと、 迷ったらオライリーでしょっていう安易な考え方で選びました。

2年の月日はこの分野では大きな差がありそうですが、 特に進化が激しそうなオーケストレーション周りはこの本とは別に直近に出版されたものも読んで、 Dockerの進化を疑似体験しつつ知識をアップデートしていこうという目論見です。

内容

DockerでHello Worldする所から始まり、簡単なWebアプリケーションの構築を通して、Dockerの基本的な操作を学べました。 これまでVMを触る事が多かった身としては、VMとの違いや利点も知りたい所でしたが、その点もしっかり押さえられている印象でした。 ただ単にVMに比べて起動が早いというわかりやすい利点の他に、Docer Hubを介したエコシステムが開発効率を上げてくれることを体感できます。 やはりその可搬性からデプロイまでも含めた流れが、VMとの大きな違いですね。 例えばサンプルにも出てきますが、既存の構成にキャッシュを組み込む際に、redis用のコンテナをサクッとpullしてリンクしてあげるような基本的な部分から Docker HubでのAuto Buildやステージング・本番で同一コンテナを利用する方法なども記載があり、 Dockerの思想を学びながら実際の現場で使えるようなイメージが湧きました。

要素としては、dockerコマンドやDockerfile, docker-compose, docker-machine等の基本的なコマンドや設定ファイルについて、 丁寧なサンプルが載っているので、写経していくには良かったです。 Dockerを利用したWebアプリケーションの構築やそのエンハンスを手を動かして一通り体験できるので、分かった気にさせてくれます。

特に面白かった所

これまで存在を知っていたconsul等のサービスディスカバリに触れられたことは、予想外の利点でした。 AWSのRDS等の各サービスを利用している際は内部DNSが裏で運用されて、利用する際はDNS名を意識すればよいだけですが、 Dockerで各コンテナ間で通信を行う際は、DNSでやるかどうかも含めて通信先を管理する必要があります。 そこでサービスディスカバリが必要になるわけです。 このDocker間の通信やサービスディスカバリがDockerで重要な位置を占めている点が知れた事が大きな収穫でした。

サービスディスカバリとコンテナの登録・削除を自動的に連携させるところまで細かく触れられていませんが、 手動でconsulやetcdのAPIを叩く事でコンテナの登録・削除を行う事でサービスディスカバリの働きを知る事ができました。

またホスト間をまたがったネットワークを構築するとなると、linkほど簡単に行かない点も興味深い点でした。 これまでAWSでEC2+RDSのようなオーソドックスな構成を運用する事が多かったため、 コンテナならではの考慮点がしっかり記載してある点は非常にためになりました。

まとめ

コンテナの良い所と苦労する点が非常にまとまってる本でしたが、 サンプルの通りに動かない点なども少々ありました。

それだけこの界隈の進化のスピードが早いという事でしょう。 やはりこの本だけでDockerを学ぶのではなく、直近に出た本でも知識のアップデートをしておく必要があると感じました。 特に、ネットワークやオーケストレーション周りですね。

とはいえ、Dockerをあまり触ったことのない方が一通り体験するには良い本だと思います。

AWS 認定 DevOps エンジニア – プロフェッショナル に合格しました！ これでAWS認定5冠達成です！

AWSの経験値

ここ3年間くらいはAWSでインフラ運用・構築したり、アプリケーション基盤作ったり。 TerraformとAnsibleで環境作ることが多いけど、試験範囲であるElastic BeanstalkやOpsWorksはほとんど使ったことがなく。 CloudFrontは少々使ったことがある程ででした。

勉強方法

これまでAWSの試験対策はもっぱら Linux Academy っていうオンラインの対策コースをやってきたのですが、 今回はA CLOUD GURUに浮気しました。

A CLOUD GURUは動画による講義とクイズにより構成されています。Linux Academyと違ってハンズオンがなかったのが残念な点です。 動画のクオリティはいいんですけどね。 Linux Academy 同様、英語なんで辛い部分もありますが、スライドと見ながら聞けば、何とかついていけるレベルです。

また、上司がこの試験の推奨セミナー「DevOps Engineering on AWS」を受講させてくれたのですが、 これは試験対策という意味合いは薄かったです。 試験では出ないCode CommitやCode CompleteなどのCode 5兄弟の話にだいぶ時間が割かれていたのが要因の一つですが、 AWSでのDevOpsを学ぶ上ではCode 5兄弟の話は欠かすことのできないものであると感じれたので、トータルでは無駄ではありません。 デプロイ戦略などの話も、良い復習になりました。

勉強期間

期間としては4ヶ月ほど。すごくダラダラと勉強してました。 勉強時間はちゃんと測ってないけど、60時間くらいかな。

内訳は

• A CLOUD GURU 15H
• 各サービスを触ってみる 10H
• AWSのドキュメントを読む 10H
• セミナー受講+復習 25H

試験を終わって振り返ると、業務でIAMのクロスアカウントを設定したり、 Terraformで環境を構築してきた経験が非常に効いたなと感じました。 勉強ではAWS固有のテクノロジーや用語を抑えて行きました。 例えばCloudFormationのWaitHandlerとかは勉強しとかないとですね。

模擬試験

1ヶ月前にうけた模試は、40%で不合格。 トピックレベルスコアリングの"Security, Governance, and Validation"なんて0%。 が、この模擬試験をしっかり復習したのは、合格のポイントだったと今では思います。 サンプル問題も解いておいて損はないです。 復習の甲斐あってか、本試験では"Security, Governance, and Validation"のスコア100%まで行きました。

最後に

実は一度は不合格をくらい、半額のバウチャーチケットがあったとはいえ16000円がパー。 非常に痛かった。。。。 2度目の受験では結局71%で合格しました。

セミナーでも話があったのですが、はDevOpsは文化なので、ツールだけでは実践できない面が多々あります。 先日読んだ、「The DevOps　逆転だ！究極の継続的デリバリー」の話なんてまさにそうでした。 どういう文化を作っていくかということを考えるときに、どういうツールがあるかを知っていると実現性に現実味が増します。 とはいえ、文化を作っていくのは試験に合格するなんかより相当難しいですね。

「データベース実践入門」]] を読んでいて、これは論理学を学んでおかないと歯が立たないなと感じ、急遽読むことにしました。 論理学はプログラマが勉強すべき内容として、こちら でも紹介されていますね。

難しさに挫折するのは悔しい所ですが、ここは自分の知識のなさを素直に認めて急がば回れで行くことにしました。

内容

命題論理を中心に進めながら、述語論理にも触れていく構成になっています。 この本自体は著者も書かれていますが、式をバンバン出していくのではなく、敷居を下げつつ nnある程度内容を絞った上で論理学の入り口に連れていってくれます。

特に面白かった所

この本で扱う論理学では、公理と呼ばれる前提とされるもの、つまり証明せずに使って良いものは非常に少ないです。 否定、連言、選言、条件。この4つです。 この4つを用いて証明を進めていくことになります。

使って良いものが少ないので、証明の過程は最初は回りくどく感じます。

どれくらい回りくどいかというと、 「((Aではない) ではない) かつ B」 から 「AかつB」を証明するのに、 4ステップ必要なのです。

(1) ((Aではない) ではない) かつ B  ...前提
(2) (Aではない)ではない ...(1)より
(3) A ... (2)より
(4) B ... (1)より
(5) AかつB ... (3),(4)より

読み進めていくうちに、この回りくどさが納得感に変わっていくのが不思議な感覚でした。

仮定として述べられていないことはしつこいくらいに証明を重ねていく考え方は、 論理学に限らず非常に有用に感じました。 「AならばB」とした時に「BならばA」(逆) 「AでないならばBではない」(裏)は、必ずしも成り立たないのですが、 裏とか逆とかは日常では曖昧にされつつ、暗黙的に成り立つとみなされることもあります。 この辺りをはっきりしていくと、いろんな誤解も防げそうですね。

まとめ

とにかく論理学の雰囲気を楽しんでほしいという、著者の意図が非常にありがたい一冊でした。 おかげで論理学で使われる堅苦しい言葉にも少しは慣れました。 ド・モルガンの定理などは昔習ったことのあるものでしたが、 この本にそって再度学び直すことで、また違った景色を手に入れた気分です。

この本を読み終わって 「データベース実践入門」 を再度眺めて見ました。 ありがたいことに「読める、読めるぞ！」という気分に浸れました。 この本はデータベースの理論を学ぶ上で非常に良い導入になるんだと思います。

実際に仕事でも使ってるAnsibleだけど、使い始めた頃から本書にはお世話になってます。

改めて読み返してみると、最初のハードルから様々なプロダクトとの連携や高速化など、 痒いところに手がとどく内容だなと思います。

初めてAnsibleを触る人にも良いと思います。 あまり馴染みのないPython製のCRMをベースに話が進んでいく箇所は若干難儀しましたが。

特に面白かった所

前述の通りAnsibleの初歩から丁寧に解説してくれた上で、応用までしっかり導いてくれる一冊でした。 ある程度仕事で使った今でも、変数の付け方や高速化の手法など、細かな書き方の指針なんかも書いてくれていて、 はっとさせられます。

考えたこと

DockerやVagrantとの連携に関してはやはり実際に書いてみるのが一番だなと感じました。 それぞれのツールの役割が読んでるだけではよくわからなくなってしまいます。 写経の大事さが身にしみました。 ただ、Dockerのサンプルソースが一部分現時点では動かなくなっていました。 本書は1系の頃に書かれたこともあり、賞味期限も切れかけているのかなとも思います。

まとめ

この分野も日々進化しており、原著は2nd Editionが出ているようです。 まだ翻訳は出ていませんが、GitHubのサンプルソースをちらっとみた限り、 章立てもだいぶ変わっているようです。翻訳版は出るのでしょうかね、楽しみですね。

これまで、Googleの成長をリアルタイムで体験しながらネットを利用してきたわけですが、 Googleが企業し、小さな企業から大企業へとなっていく華やかな成長の裏で、 中の人は何を考え、苦悩してきたのかがわかる本です。

内容

検索エンジンのキラーアイデアとなったページランクから始まり、打ち出の小槌のAdwardsにより、お金の心配なく企業を運営してきたGoogle。 そんなGoogleが「邪悪になるな」をモットーにしながらも、プライバシーや著作権の問題で、リアル世界では批判にさらされていく様子が克明に描かれています。 小さな企業だった頃はグレーゾーンを突き進んでイノベーションを起こしてきたGoogleが、 大企業になって無茶はできなくなっていき、リアルな世界と調整していくに当たって保守的にならざる得なくなるところが印象的でした。

特に面白かった所

ペイジが書いた初期の検索エンジンはJavaで書かれていたが、バグだらけで後にPythonで書き直されたそうです。 また、インデックスの更新に非常に時間がかかったりと、技術的には今のGoogleからは考えにくいようなレベル感の話がありました。 そんな中で、今では常識となっているメモリを使った高速化の手法を編み出していくわけですが、 当時としては画期的な訳で、それをゼロから考えついたというところは流石と思いました。

また、自由に見えるGoogleも思ったよりと不自由な状況になっている点も印象的でした。 大企業のしがらみからか、徐々にイノベーションを起こすだけの小回りが効かなくなっていく様が本書でも克明に描かれています。 そんな中でYoutubeという、著作権ギリギリの中でサービスを展開していく存在が非常に対照的に描かれています。 色々配慮したGoogle Videoは敗れ、Youtubeを買収することでイノベーションに乗っかることを選んだGoogle。 今後のGoogleはどうなっていくか考えさせられる買収劇でした。

考えたこと

ソーシャルの波にはすかり乗り遅れ、Facebookの後塵を拝しているGoogleですが、 最近は人工知能の分野で盛り返しているように感じます。 ブリンとペイジは創業当初から常にGoogleは人工知能の会社であると定義していたことを考えると、 大きな企業がイノベーションを起こすことは難しいと言われていますが、そこを覆す何かが起こらないかなと期待してしまいます。

まとめ

今となっては息をするように利用しているGoogleのサービスですが、 こんなにも著作権やプライバシーの問題に晒され、苦しんできたのかと驚かされました。 僕の中に漠然とあった、やんちゃなイメージのGoogleは実はもう存在していなくて、大人な会社がそこにはありました。 日本では特にGoogleのこういった苦悩は知られていないのかなとも思います。 多くのインタビューと取材によって書かれた本書は、本当のGoogleを知る上で良い一冊だと思いました。