飲茶著の本を連続で4冊読んだ後にちょうど新刊が発表されていた。もちろん買って読んだ。この本はアマゾンのランキングにも入っているし売れているみたい。
小説なんだけど登場人物は数人で舞台のほとんどが学校の教室というとても小さな世界。でもそこで語られる話は人類が数千年かけても結論を出せずに悩み続けていること。
SAWというスリラー？映画があるけれどあれの第1作目は1つの部屋だけで話が終始して登場人物も非常に少ない低予算映画だったにも関わらず、話の展開や演出が完璧で観終わった後はしばらく呆然とした。この本も読み終えた後は同じような感覚になった。
善悪に関する価値観を提示するストーリーはよくあるけれど、天才的な哲学者たちが考え抜いた話を土台に展開する本書は一線を画する超良書。大変おすすめの一冊。
史上最強の哲学入門 東洋の哲人たち (河出文庫 や 33-2)
先日読んだ「哲学的な何か、あと科学とか (二見文庫)」と「哲学的な何か、あと数学とか (二見文庫)」と同じ著者。赤い表紙が西洋哲学者で、青は東洋哲学者。
作風はどちらも同じで、ある時代で超偉大な哲学者の論を時代背景を交えて解説した後、次世代の哲学者がダメ出しして新しい論を打ち出し、そしてさらなる次世代の哲学者が…という流れ。
時系列ではあるけれど突然数百年飛ぶこともあるし歴史としてみると大雑把だけど、うまく前世代と次世代の論を比較しているのですごく面白い。
2冊とも作風は同じだけど読み応えはだいぶ違う。西洋哲学は論理構築の歴史といった感じでひたすらどうすれば真実と言えるか探求が続く感じだけど、東洋哲学は中国哲学（思想？）と仏教が主な内容で、深く内容を追いかける感じだった。
全体を通して最も良かったのは仏教の部分。ちゃんと釈迦の時代、というより釈迦以前のインドから始まっているし、悟りは体験によってしか起き得ないということをびっくりするくらい丁寧にあの手この手で説明している。知識だけでは悟りにならないこと自体は知っていたのだけど、なるほどこう説明するのかわかりやすい！と頷きながら読んでいた。
哲学、というとポエムっぽいというか浮世離れというか思想的というかそいういうイメージも世間一般にはありそうだけど、哲学がいかにガチ論理であるかをわかりやすく伝えていると思う。最高。特に西洋哲学は勉強不足で知らないことも多かったのでまた読み返すと思う。
「哲学的な何か、あと数学とか」を読んだ – cloned.log に続いて読んだ。この「哲学的な何か、あと科学とか」の方が哲学と科学のバランスが良くタイトルによく馴染む感じになっている。前回読んだ「哲学的な何か、あと数学とか」はフェルマーの最終定理にまつわる数学と数学者に交えて哲学、という感じで、やや哲学がサブな感じになっている。書籍の時系列としても「科学とか」が先で「数学とか」が後みたい。
どちらの書籍にも言えるけれど、とにかく文章が読みやすいしわかりやすい。実際の哲学や科学の話なのにファンタジー小説の一部であるかのような面白さがあった。
特に良かったのは量子力学の章。2重スリット実験を十二分に解説した上で（その理解を助ける波動と粒子の話が前段にある）、コペンハーゲン解釈、シュレディンガーの猫を繋げていく説明はお見事。シュレディンガーの猫はその話自体は超有名だけど、どうしてこれが解決困難な思考実験であるかということがよくわかる説明になっていた。
2冊とも良かったけれど特にこの「哲学的な何か、あと科学とか」は良かった。
フェルマーの最終定理をテーマに歴代の数学者による情熱的な戦いを描いた本。フェルマーの最終定理については12年前にサイモン・シンの本を読んでおり大体の知識があったけれど、忘れていることも多かったし、サイモン・シンの本とは文体や視点がかなり異なるので新鮮に楽しむことができた。
ノーゲーム・ノーライフの著者 榎宮先生の絶賛を見て買ったら当然の大当たり。
僕たちは（特に初等教育で）数学を計算ツールとして教わるけれど、解を求めるのは数学の一部でしかなくて、むしろ式が成り立つことを考えるのが数学だろうし、そういう視点を持ったこの本は数学嫌いをマシにする一歩に感じる。
結構前に買って第1章までは読んでいたのだけど、その後そのままになっていた。最近KindleをiOSのスピーチに読ませることで本を読む（聞く）時間が取れるようになったので第2章から最後まで一気に読んだ。
データの見えざる手: ウエアラブルセンサが明かす人間・組織・社会の法則
本のタイトルだけ見ても何の本かわかりにくいけれど、センサで人間を細かく測定したデータから人間の心や行動を判定し、どのような行動が業績に影響を与えるか、さらにはどのような施策を打つべきかAIに示させるといった内容になっている。
ただの仮説や理論の提示ではなく、著者らが実験してきた内容が具体的に記されているので読み応えがある。考察も十分あり単なる事例紹介にとどまらない。
前半はウェアラブルセンサでどのような測定ができて何がわかるのか解説されている。どの人と会話したかといった粒度のものから会話中に（物理的に）よく動いているかといった細かな人間行動まで、粒の大きさが異なる様々なデータから人間の行動を解き明かしていくのが面白かったし、最終的にAIにより導かれた施策で効果を出すところにも未来を感じる（実際には現在起きていることだけれど）。
コンピューター将棋のように人間だとまず考えつかないような施策で普通に考えると全く効果が期待できなさそうなのにきっちり効果があったところもいかにもAIらしい。どういう施策だったのかはぜひ本を読んでもらえればと思う。
一方で読みづらいと感じるところもいくつかあった。一つは説明の重複が多いこと。言葉を変えてわかりやすく説明しているのだと思うけれど、何度も似通った説明を聞いている感じになり話が進まないと感じることが度々あった。
次に細かい脱線が多かった。著名な経営学、経済学者、物理学者などの主張がデータからも正しいと考えられるという説明がたくさん入るけれど、これが分脈を切ってしまい読みにくかった。また日本の現状はこれが原因ではないかといったかなりスケールの大きい推測が断定に近い口調で入ったりするのもやや読むのに障壁だった。著者にとっては確信があるのかもしれないけれど本書の説明内容だけでは言い過ぎに感じる。
著者が考える過去と未来については章を分けて書いてある方が良かったように思う。
とはいえ、やはり内容は良かった。ビッグデータがあってディープラーニングのような手法があってもそれを使って解析するのは結局データサイエンティストによる人力、という状況を変える試みについて良い学びを得たと思う。
FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣
KindleでページがNo.5237までと表示されていたのにNo.3974に「おわりに」が登場して不意打ちを受けたように読み終えてしまった。最後に付録がたくさんあるからだけど、No.5237まで文章が続いていたとしてもすぐに読み切ったと思う。
読み終えたら感想を書こうと思っていたけれど、読み終えてみるとどこかの文章をつまみ出して感想を書く気はなってしまった。自分なりに要約したり良かったところを紹介したりはできると思うけれど、この本には必要ないと思う。将来の自分がこの本はどんな内容だったかなと思ったらまた最初から読み直せばいいと思う。
よく編集されており読みやすく重複もないスッキリした本だった。日本語訳も良かった。読み終えた後にハンスのTEDの映像を観てみたけど、日本語訳はハンスの人柄を捉えた語調をうまく選んでいると思うし、英語の原著を無料で読める数ページ見てみたけど違和感はなかった。
世界で起きていることを偏見なく認識するために。素晴らしい一冊。
よく考えたコードや設計であっても他人が見るとすぐに問題が見つかることがある。知識差が原因のこともあるけれど他人だからこそ気付けたという場合も多い。
これは客観的に見ると気付く、というよりも視点を変えると見え方が変わる（よって問題に気付く）ということだと思う。他人は自分と少なからず違う視点（思考）になるので手っ取り早いというだけ。自分の視点を変えられれば問題に気付きやすくなる。
僕が普段無自覚にやっている方法を整理すると次の2つをやっているみたいだった。
プログラムの設計やコーディングは基本的にプログラマーとして作業してしまう。例えばDBAになりきるとプログラム上は楽でもパフォーマンスなどで問題のある部分が見えてくるし、仕様を考えた人になりきるとプログラムの都合で元の仕様設計の意図を歪曲したり複雑化していないかが見えてくる。インフラエンジニアになりきると本番デプロイ時に問題になることなどが見えてくる。
こうやって違うロールになりきって考えると結構色々問題が見えてくる。ただ経験したこともないロールになりきるのは無理があり（単に机上の空論となる）経験に左右されるから、色々なことをやってみるのは大切だと改めて思う。
これはライフハック的に言われてることだと思うけど、今やっている作業状態を一旦忘れてから再度考えることで強制的に違う視点にする方法がある。お風呂に入る、散歩する、一晩寝かすなど。僕の場合、だいたい数回自転車に乗ると「あー、そうじゃないや、こうだな」と違う視点のアイデアが出てきたりすることが多い（子供の送り迎えや買い物で毎日何回か自転車に乗る）。
奥の手として潔く信頼できる人に見てもらうというのがある。ブログタイトルと明らかに矛盾するけれどコードレビューやテストなどの決まったサイクルを待たずに自主的に第三者視点を求めるのは良いと思う。自分で気付ける方法を書いてみたもののどうしてもカバーできない部分はあると思うので。
Symfony Advent Calendar 2018 10日目の記事です。
SymfonyはテンプレートエンジンにTwigを採用しています。TwigはPython製のJinjaにシンタックスが似ていることで知られています。SymfonyがなぜTwigを採用したのか、なぜJinjaと似ているのかについて日本語の情報が少なそうなので書いてみようと思います。
ただ、内容としてはほとんどSymfonyの作者であるFabien Potencierのブログ記事で触れられているものです。
Templating Engines in PHP | Articles – Fabien Potencier
この記事は2009年10月にポストされたものです。この時のSymfony（当時はsymfony）のバージョンは1.3で11月に1系最後である1.4がリリースされています。彼がこの時期にどのようなテンプレートが望ましいか考え悩んだ結果が吐露されています。
記事の最初に「私と意見が合わなくて殺したい人がいるかも」という注意が書いてあることから当時のテンプレートエンジンに対する議論の白熱？具合が伺えます。
この記事の前半ではDjango（Pythonのウェブフレームワーク）のテンプレートと比較して次のようなことが書かれています。
中盤では既存のPHP製テンプレートエンジンを探してみたけどいいのがない、ということが書かれています。Smarty、PHPTAL、eZ Components Templates、Dwoo、Calypsoを取り上げています。
後半ではTwigにたどり着いた経緯が書かれています。
Symfony 2がリリースされたのは約2年後の2011年7月です。この時にデフォルトのテンプレートエンジンとしてTwigが採用されています。
Twigの最初のgitコミットを確認すると2009年10月7日となっています。そして先に紹介したFabienの記事の日付は同じく2009年10月7日です。この日のコミットは開発ではなくgit-svnを使ったSVNリポジトリ（おそらくArminが使っていたものと思われます）からのポーティングですが、これからやっていくぞという意気込みを感じるコミットです。
現在のTwigはSensioLabs（FabienがCEOの会社）やSymfony開発者によってメンテされ、9年間経った今でもSymfonyを支える重要なパーツとして生き続けています。
Symfony Advent Calendar 2018 9日目の記事です。
PHP製デプロイツールのDeployerを使ってSymfonyをデプロイする方法について書きます。おまけでSlackにデプロイ結果を通知する方法についても書きます。
Amazon Linuxで作業しました。Deployerのバージョンは 6.3.0 です。gitにあるSymfonyプロジェクトをデプロイする想定なのでGitHubに次のような準備を行いました。
$ composer create-project symfony/website-skeleton symfony4-deployer
$ cd symfony4-deployer
$ git add .
$ git commit -m "first commit"
$ git remote add origin git@github.com:cloned/symfony4-deployer.git
$ git push -u origin master
Deployerは dep というコマンドを使って操作します。インストール方法は Deployer — Installation を参照してください。pharをダウンロードして配置する方法でもcomposerでインストールする方法でも dep というコマンドが利用できればOKです。
dep コマンドが使えるようになったら、今度はデプロイするための設定ファイル deploy.php が必要です。このファイルは次のコマンドで雛形を作成することができます。
$ dep initLaravelやSymfonyなど色々な選択肢が用意されており便利そうなのですが、この選択肢の Symfony は Symfony 2 を想定しているのと、この手の設定はまず動く最小限を用意してから必要に応じて増やす方が理解しやすいので、ここでは最小設定の deploy.php を用意しました。
namespace Deployer;
require 'recipe/symfony4.php';
set('application', 'symfony4-deployer');
set('repository', 'git@github.com:cloned/symfony4-deployer.git');
set('env', [
'APP_ENV' => 'prod',
]);
host('localhost')
->set('deploy_path', '~/deploy-path/{{application}}');要点としては次のようになります。
symfony4.php を require するapplication（アプリ名）とrepository（gitリポジトリ）を設定するAPP_ENV を設定するそれぞれ少し解説します。
symfony4.php を利用するDeployerにはレシピ（recipe）というものが用意されています。と書くとそのような仕組みがあるかのようですが実際のところ「良くあるタスクをあらかじめ定義しておいたPHP」というだけで、利用するにあたっては require するだけです。
ここで利用している recipe/symfony4.php はDeployer公式のものなのでcomposerなどで追加する必要はなくそのまま参照して利用できます。内容は直接コードを見た方がわかりやすいです。
deployer/symfony4.php at master · deployphp/deployer
設定を変更していく際に symfony4.php の定義をみて既にある定義を使うのか、上書きするのか、追加するのか、など考えますので元のレシピ（設定）を把握しておくことは重要です。といっても symfony4.php に関していえば数十行しかなく簡単に把握できると思います。
set('env', [
'APP_ENV' => 'prod',
]);このように設定するとDeployerはコマンドを実行する際に先頭に export APP_ENV='prod'; と付け加えます。Symfonyのenvをprodにするためこのような設定を入れてあります。
この設定をせずにデプロイすると次のようなエラーになってしまいます。
PHP Fatal error: Uncaught Symfony\Component\Debug\Exception\ClassNotFoundException: Attempted to load class “WebProfilerBundle” from namespace “Symfony\Bundle\WebProfilerBundle”.
これは composer install を --no-dev で実行している（つまりrequire-devのものはインストールされない）にもかかわらず、SymfonyのenvはdevのためWebProfilerBundleクラスを読み込めずエラーになっています。
Symfonyのenvをprodにするには APP_ENV=prod と記述した .env ファイルを配置する方法もありますが、ここでは実行時の環境変数で設定を行いました。
APP_ENVについてはSymfonyの公式ドキュメントに記載がありますのでそちらも参照してください。
How to Deploy a Symfony Application C) Install/Update your Vendors
これで準備が整ったのでデプロイを実行します。
$ dep deployうまくいけば次のように実行されたタスクが表示されます。
デプロイ先は次のように設定していますので localhost にSSH接続して deploy_path のパスに対してデプロイが行われます。
host('localhost')
->set('deploy_path', '~/deploy-path/{{application}}');この例でのデプロイ後のアプリケーションパスは ~/deploy-path/symfony4-deployer/current になります。currentはシンボリックリンクで実体は~/deploy-path/symfony4-deployer/releases/以下に存在します。releases/に配備したコードへのシンボリックリンクを張り替えるという方法になっています。この辺りはDeployerのコピー元であるRuby製デプロイツールのCapistranoと同じです。
$ dep rollbackとすると直前のリリースにシンボリックリンクを張り替えます。これによりデプロイ前のコード（前回デプロイしたコード）にロールバックすることができます。ls -l current 等でシンボリックリンク先が変わっていることを確認すると理解しやすいと思います。
これで基本的なデプロイは完了です。ただ用途によって設定を変更したいことがあるかもしれません。例えば var/log と var/sessions はもともとデプロイごとに別ファイルになってしまわないようにcurrentと同じ場所にあるsharedディレクトリへのシンボリックリンクになるようになっていますが、var/files も同様にしたいとしましょう（var/filesは単にここでの例でSymfonyにはもともとありません）。
その場合は deploy.php に次の記述を追加します。
set('shared_dirs', ['var/log', 'var/sessions', 'var/files']);元のレシピの symfony4.php に既に shared_dirs が定義されていますが var/files を追加して上書きしています。このように元のレシピを確認しながら必要に応じて設定を変更することができます。
他にも例えば symfony4.php には database:migrate タスクが定義されているので、デプロイ完了前にマイグレーションを実行するような設定を行うこともできます。
おまけですがデプロイが完了したらSlackに通知する設定も追加します。Slackに通知する実装はDeployer本体には含まれていませんが、別のリポジトリで色々なレシピが公開されておりそこにSlackのレシピが存在します。公式サイトにドキュメントも存在します。
まずはcomposerで各種レシピを追加します。
$ composer require deployer/recipes --dev次に deploy.php にSlackに関する設定を追加します。成功時に通知したいだけであれば次の3行を追加するだけです。
require 'vendor/deployer/recipes/recipe/slack.php';
set('slack_webhook', 'https://hooks.slack.com/xxxxxxxx');
after('success', 'slack:notify:success');slack_webhook のURLはSlack側で作成しておく必要があります。うまくいくと次のような通知が来るようになります。
Deployerを使ってSymfony 4をデプロイする方法を解説しました。PHP製フレームワークのデプロイ設定があらかじめ用意されているのですぐに使い始められます。Symfony 4に限らず公式レシピをうまく使ってデプロイする際の参考になればと思います。
ドラゴンクエストXを支える技術 ── 大規模オンラインRPGの舞台裏 (WEB+DB PRESSプラスシリーズ)
発売されることを知って予約注文していた本。読み終えたので感想文。先に一言で結論を書くと素晴らしい本だった。
この本が素晴らしいのはゲーム開発の実録になっていること。一般的な技術解説本の場合、著者が経験してきたことの集大成になることが多い。つまり色々なプロジェクトを経験した上でこれが最も良かったと思う内容がピックアップされる。効率よく学習したい読者にとっても普通はそのほうが良い。
しかし、この本では「ドラゴンクエストXで何をしたのか」しか書いていない。もちろんお手本になるものが中心ではあるけれど、失敗したこと、そしてそれがどのような大規模障害に繋がったのかが解説されている。
これはすごいことで、著者は自分（達）の失敗を明らかにするような本を書きたくないし、失敗する方法よりも成功する方法を伝えたいものだから。でも、この本には失敗談がたくさん盛り込まれている。失敗談をたくさん記述してくださった著者に敬意を表して失敗談の有用性について少しだけ書きたい。
本（に限らないけれど）に書いてあった良い方法を学んで実践する。通常はこれで良い。けれども、悪いものを知らないとそれがどれだけ良いのかわからない。良さの程度がわからないと良い方法を蔑ろにする。
「こうした方が良いのだろうけど今回はその場凌ぎの対応をしておこう」というのは現場で頻繁にある。時間が限られているので仕方がないところもあるけれど、悪いものを知らないと「その場凌ぎであっても選択してはならない重大な欠陥がある方法」をあっさりやってしまったりする。
悪い方法について知らないからというのもあるけれど、何より失敗経験がないとその悪さを重大なものとして認識しにくい。
実際に失敗した人は違う。この悪い方法を選択したばかりに開発/運営チームは数日対応に追われお客様から大量の叱咤を受けたという経験から、時間がなくてもその方法を選択してはいけない、時間がないならリリースを延期してでも違う方法にしないとダメ、と言えるようになる。
こういった判断力を培うには普通は自分で失敗するしかないのだけど、この本はなんとその失敗経験をたったの2680円+税で提供しているのだから値千金ということ。しかも実際にドラゴンクエストXにどのような影響を与えたのかが常に記載されており社外の人間が読んでも臨場感のある内容になっている。
目次を見るとものすごい広範囲な内容になっていて、これだけ読めばオンラインゲームの全貌が掴めそうな感じ。とはいえ実際のところは次の点が中心だったように感じる。
ページ数だけでみると他の章も結構紙面を割いているのだけど、開発体制やプログラミング言語に関するところ、グラフィックに関するところは基本的な内容が多いように感じた。
あまり公開されないチート対策についても記述されているので必見。
この本はドラゴンクエストXについてしか書いていないので当然ゲームとしてのドラゴンクエストXを知らないと理解しにくい部分があるのだけど心配無用でゲーム仕様どころか次のような解説からスタートしている。
RPGは、役割（Role）を演じる（Playing）ゲーム（Game）のことです。
p3より
また専門用語は使われているものの専門用語の使い始めに説明を記していることが多い。「フラグ」のような開発者でなくても知っていそうな言葉でも解説が入っている。
この本では大体のことが方法論までしか触れておらず実装説明はあまりないので各部門の専門の人が読んだ際には物足りない感じはあるかもしれない。企業秘密的な側面もあるだろうし幅広い読者層を意識してのことだと思う。
プログラミング視点だとウルティマ開発者のこの本が具体的でかつ実践的だった。
ゲームコーディング・コンプリート 一流になるためのゲームプログラミング (Professional game programming)
オンラインゲーム設計視点だとやはりこの本を外せない（「ドラゴンクエストXを支える技術」の中でも言及がある）。
オンラインゲームを支える技術 －－壮大なプレイ空間の舞台裏 (WEB+DB PRESS plus)
とはいっても各専門の人が読んでも期待外れに思うことはないと思う。なぜならこの著者ほどオンラインゲームの全体を把握し責任を持つ立場になっている人は日本にそれほどいないだろうから。
買いましょう。読みましょう。良い本です。好きな呪文はベホマラーです。嫌いな呪文はマホトラです。