cloned.log

DEATH STRANDINGをクリアした感想

Wed, 08 Jan 2020 00:26:16 +0900

DEATH STRANDINGをクリアした。The Witcher 3以来の心に残るゲームだったので感想を書く。

作者:
出版社/メーカー: ソニー・インタラクティブエンタテインメント
発売日: 2019/11/08
メディア: Video Game

ゲームプレイを始めた当初はクリアまで到達しなさそうに思えた。元々告知されていた有名俳優が全て何かしらの形で早々に登場してしまい世界観の狭さを感じてしまったのと、ゲームプレイのコアが「物を配達すること」の繰り返しだと感じたから。僕はいわゆる「お使いクエスト」がとても嫌いなのでやや失望した。

小島監督の作品でなければ早々に辞めていたかもしれないけれど、そんな単調で面白くないゲームであるはずがないと思ってプレイを進めた。そしたら全然違った。

繋がり

最初にこのゲームの見え方が変わったのは建設ができるようになったとき。オンラインの繋がりを明確に感じるようになった。小島監督自身が #デスストでつながれのハッシュタグをつけてよくツイートしているけれど、まさに繋がった。他人が置いたものを活用し、自分が置いたものは活用される。一切のデメリットがなく完全な協力関係にあるオンライン。自分のゲームプレイのためなのに「誰かが使うかも」と考えるようになる。無意識に繋がりを意識する。

配達の意義

お使いクエストと心配していた配達はプレイを進めていくとその意義が明確になり、これこそが自分の仕事だと認識するようになった。もはや配達クエストではなくストーリーを支える根幹作業。レベルデザインが素晴らしいこともあり、まんまと配達員になってしまった。

SF？ミステリー？あるいは詩？

一見するとSFなストーリーだけど体感としてはミステリー小説に近かった。大量の謎が徐々に解明され、解明されたと思ったら実は違って、もっと本質的な真相があり、といった展開が魅力的だった。でも振り返ってみると詩に感じる。全ての言葉に意味が込められて作られた世界だったことに気付く。クリア前とクリア後でここまで印象が変わるストーリーも珍しいと思う。

ちょっと辛いと思ったこと

ノーマンの疲れ顔が辛いし配達体験がリアルすぎるので「なんでゲームで仕事してるんだろ」って本気で思った。BTに襲われるのが辛すぎた。なんとか工夫してやろう、とは思えずひたすら苦痛だった。辛かったので難易度をeasyに落とした。操作が難しかった。クリア寸前でやっと慣れた感じ。

クリア後

クリアは達成感よりも、自分がプレイしていたあれはなんだったのか、と思いふけることになった。ストーリーの序盤から記憶を辿ってあれはこうだったのかと頭の中でパーツを埋めていく。心に残る不思議なゲーム。

「正義の教室」を読んだ

Thu, 11 Jul 2019 23:52:12 +0900

正義の教室善く生きるための哲学入門

作者: 飲茶
出版社/メーカー: ダイヤモンド社
発売日: 2019/06/20
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

飲茶著の本を連続で4冊読んだ後にちょうど新刊が発表されていた。もちろん買って読んだ。この本はアマゾンのランキングにも入っているし売れているみたい。

小説なんだけど登場人物は数人で舞台のほとんどが学校の教室というとても小さな世界。でもそこで語られる話は人類が数千年かけても結論を出せずに悩み続けていること。

SAWというスリラー？映画があるけれどあれの第1作目は1つの部屋だけで話が終始して登場人物も非常に少ない低予算映画だったにも関わらず、話の展開や演出が完璧で観終わった後はしばらく呆然とした。この本も読み終えた後は同じような感覚になった。

善悪に関する価値観を提示するストーリーはよくあるけれど、天才的な哲学者たちが考え抜いた話を土台に展開する本書は一線を画する超良書。大変おすすめの一冊。

「史上最強の哲学入門」を読んだ

Sat, 18 May 2019 22:36:27 +0900

史上最強の哲学入門 (河出文庫)

作者: 飲茶
出版社/メーカー: 河出書房新社
発売日: 2015/11/05
メディア: 文庫
この商品を含むブログ (2件) を見る

史上最強の哲学入門東洋の哲人たち (河出文庫や 33-2)

作者: 飲茶
出版社/メーカー: 河出書房新社
発売日: 2016/10/05
メディア: 文庫
この商品を含むブログ (2件) を見る

先日読んだ「哲学的な何か、あと科学とか (二見文庫)」と「哲学的な何か、あと数学とか (二見文庫)」と同じ著者。赤い表紙が西洋哲学者で、青は東洋哲学者。

作風はどちらも同じで、ある時代で超偉大な哲学者の論を時代背景を交えて解説した後、次世代の哲学者がダメ出しして新しい論を打ち出し、そしてさらなる次世代の哲学者が…という流れ。

時系列ではあるけれど突然数百年飛ぶこともあるし歴史としてみると大雑把だけど、うまく前世代と次世代の論を比較しているのですごく面白い。

2冊とも作風は同じだけど読み応えはだいぶ違う。西洋哲学は論理構築の歴史といった感じでひたすらどうすれば真実と言えるか探求が続く感じだけど、東洋哲学は中国哲学（思想？）と仏教が主な内容で、深く内容を追いかける感じだった。

全体を通して最も良かったのは仏教の部分。ちゃんと釈迦の時代、というより釈迦以前のインドから始まっているし、悟りは体験によってしか起き得ないということをびっくりするくらい丁寧にあの手この手で説明している。知識だけでは悟りにならないこと自体は知っていたのだけど、なるほどこう説明するのかわかりやすい！と頷きながら読んでいた。

哲学、というとポエムっぽいというか浮世離れというか思想的というかそいういうイメージも世間一般にはありそうだけど、哲学がいかにガチ論理であるかをわかりやすく伝えていると思う。最高。特に西洋哲学は勉強不足で知らないことも多かったのでまた読み返すと思う。

「哲学的な何か、あと科学とか」を読んだ

Fri, 03 May 2019 22:01:42 +0900

哲学的な何か、あと科学とか (二見文庫)

作者: 飲茶
出版社/メーカー: 二見書房
発売日: 2018/12/01
メディア: Kindle版
この商品を含むブログを見る

「哲学的な何か、あと数学とか」を読んだ - cloned.log に続いて読んだ。この「哲学的な何か、あと科学とか」の方が哲学と科学のバランスが良くタイトルによく馴染む感じになっている。前回読んだ「哲学的な何か、あと数学とか」はフェルマーの最終定理にまつわる数学と数学者に交えて哲学、という感じで、やや哲学がサブな感じになっている。書籍の時系列としても「科学とか」が先で「数学とか」が後みたい。

どちらの書籍にも言えるけれど、とにかく文章が読みやすいしわかりやすい。実際の哲学や科学の話なのにファンタジー小説の一部であるかのような面白さがあった。

特に良かったのは量子力学の章。2重スリット実験を十二分に解説した上で（その理解を助ける波動と粒子の話が前段にある）、コペンハーゲン解釈、シュレディンガーの猫を繋げていく説明はお見事。シュレディンガーの猫はその話自体は超有名だけど、どうしてこれが解決困難な思考実験であるかということがよくわかる説明になっていた。

2冊とも良かったけれど特にこの「哲学的な何か、あと科学とか」は良かった。

「哲学的な何か、あと数学とか」を読んだ

Tue, 30 Apr 2019 23:31:46 +0900

哲学的な何か、あと数学とか (二見文庫)

作者: 飲茶
出版社/メーカー: 二見書房
発売日: 2018/02/01
メディア: 文庫
この商品を含むブログを見る

フェルマーの最終定理をテーマに歴代の数学者による情熱的な戦いを描いた本。フェルマーの最終定理については12年前にサイモン・シンの本を読んでおり大体の知識があったけれど、忘れていることも多かったし、サイモン・シンの本とは文体や視点がかなり異なるので新鮮に楽しむことができた。

ノーゲーム・ノーライフの著者榎宮先生の絶賛を見て買ったら当然の大当たり。

まあ、このラインナップはね……榎宮史上トップやしね( https://t.co/AzIYeBYLhv
— 榎宮祐🎮帰国📖🍿 (@yuukamiya68) April 20, 2019

僕たちは（特に初等教育で）数学を計算ツールとして教わるけれど、解を求めるのは数学の一部でしかなくて、むしろ式が成り立つことを考えるのが数学だろうし、そういう視点を持ったこの本は数学嫌いをマシにする一歩に感じる。

「データの見えざる手」を読んだ

Sat, 09 Feb 2019 11:51:05 +0900

結構前に買って第1章までは読んでいたのだけど、その後そのままになっていた。最近KindleをiOSのスピーチに読ませることで本を読む（聞く）時間が取れるようになったので第2章から最後まで一気に読んだ。

データの見えざる手: ウエアラブルセンサが明かす人間・組織・社会の法則

作者: 矢野和男
出版社/メーカー: 草思社
発売日: 2014/07/17
メディア: 単行本
この商品を含むブログ (24件) を見る

本のタイトルだけ見ても何の本かわかりにくいけれど、センサで人間を細かく測定したデータから人間の心や行動を判定し、どのような行動が業績に影響を与えるか、さらにはどのような施策を打つべきかAIに示させるといった内容になっている。

具体的で応用的な内容が素晴らしい

ただの仮説や理論の提示ではなく、著者らが実験してきた内容が具体的に記されているので読み応えがある。考察も十分あり単なる事例紹介にとどまらない。

前半はウェアラブルセンサでどのような測定ができて何がわかるのか解説されている。どの人と会話したかといった粒度のものから会話中に（物理的に）よく動いているかといった細かな人間行動まで、粒の大きさが異なる様々なデータから人間の行動を解き明かしていくのが面白かったし、最終的にAIにより導かれた施策で効果を出すところにも未来を感じる（実際には現在起きていることだけれど）。

コンピューター将棋のように人間だとまず考えつかないような施策で普通に考えると全く効果が期待できなさそうなのにきっちり効果があったところもいかにもAIらしい。どういう施策だったのかはぜひ本を読んでもらえればと思う。

文章として読みづらいところもあった

一方で読みづらいと感じるところもいくつかあった。一つは説明の重複が多いこと。言葉を変えてわかりやすく説明しているのだと思うけれど、何度も似通った説明を聞いている感じになり話が進まないと感じることが度々あった。

次に細かい脱線が多かった。著名な経営学、経済学者、物理学者などの主張がデータからも正しいと考えられるという説明がたくさん入るけれど、これが分脈を切ってしまい読みにくかった。また日本の現状はこれが原因ではないかといったかなりスケールの大きい推測が断定に近い口調で入ったりするのもやや読むのに障壁だった。著者にとっては確信があるのかもしれないけれど本書の説明内容だけでは言い過ぎに感じる。

著者が考える過去と未来については章を分けて書いてある方が良かったように思う。

ビッグデータの応用事例として欠かせない一冊

とはいえ、やはり内容は良かった。ビッグデータがあってディープラーニングのような手法があってもそれを使って解析するのは結局データサイエンティストによる人力、という状況を変える試みについて良い学びを得たと思う。

FACTFULNESSを読んだ

Sun, 03 Feb 2019 22:23:10 +0900

FACTFULNESS(ファクトフルネス)　10の思い込みを乗り越え、データを基に世界を正しく見る習慣

作者: ハンス・ロスリング,オーラ・ロスリング,アンナ・ロスリング・ロンランド,上杉周作,関美和
出版社/メーカー: 日経BP社
発売日: 2019/01/11
メディア: 単行本
この商品を含むブログ (1件) を見る

KindleでページがNo.5237までと表示されていたのにNo.3974に「おわりに」が登場して不意打ちを受けたように読み終えてしまった。最後に付録がたくさんあるからだけど、No.5237まで文章が続いていたとしてもすぐに読み切ったと思う。

読み終えたら感想を書こうと思っていたけれど、読み終えてみるとどこかの文章をつまみ出して感想を書く気はなってしまった。自分なりに要約したり良かったところを紹介したりはできると思うけれど、この本には必要ないと思う。将来の自分がこの本はどんな内容だったかなと思ったらまた最初から読み直せばいいと思う。

よく編集されており読みやすく重複もないスッキリした本だった。日本語訳も良かった。読み終えた後にハンスのTEDの映像を観てみたけど、日本語訳はハンスの人柄を捉えた語調をうまく選んでいると思うし、英語の原著を無料で読める数ページ見てみたけど違和感はなかった。

世界で起きていることを偏見なく認識するために。素晴らしい一冊。

他人がすぐに気付く問題を先に自分で気付くための方法

Sun, 06 Jan 2019 22:29:17 +0900

よく考えたコードや設計であっても他人が見るとすぐに問題が見つかることがある。知識差が原因のこともあるけれど他人だからこそ気付けたという場合も多い。

これは客観的に見ると気付く、というよりも視点を変えると見え方が変わる（よって問題に気付く）ということだと思う。他人は自分と少なからず違う視点（思考）になるので手っ取り早いというだけ。自分の視点を変えられれば問題に気付きやすくなる。

僕が普段無自覚にやっている方法を整理すると次の2つをやっているみたいだった。

ロール（役割・役職）を変えて考える

プログラムの設計やコーディングは基本的にプログラマーとして作業してしまう。例えばDBAになりきるとプログラム上は楽でもパフォーマンスなどで問題のある部分が見えてくるし、仕様を考えた人になりきるとプログラムの都合で元の仕様設計の意図を歪曲したり複雑化していないかが見えてくる。インフラエンジニアになりきると本番デプロイ時に問題になることなどが見えてくる。

こうやって違うロールになりきって考えると結構色々問題が見えてくる。ただ経験したこともないロールになりきるのは無理があり（単に机上の空論となる）経験に左右されるから、色々なことをやってみるのは大切だと改めて思う。

脳内の一時メモリをリセットする

これはライフハック的に言われてることだと思うけど、今やっている作業状態を一旦忘れてから再度考えることで強制的に違う視点にする方法がある。お風呂に入る、散歩する、一晩寝かすなど。僕の場合、だいたい数回自転車に乗ると「あー、そうじゃないや、こうだな」と違う視点のアイデアが出てきたりすることが多い（子供の送り迎えや買い物で毎日何回か自転車に乗る）。

奥の手として潔く信頼できる人に見てもらうというのがある。ブログタイトルと明らかに矛盾するけれどコードレビューやテストなどの決まったサイクルを待たずに自主的に第三者視点を求めるのは良いと思う。自分で気付ける方法を書いてみたもののどうしてもカバーできない部分はあると思うので。

SymfonyはなぜTwigを採用したのか ~ Jinjaとの関係

Mon, 10 Dec 2018 00:00:00 +0900

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がリリースされています。彼がこの時期にどのようなテンプレートが望ましいか考え悩んだ結果が吐露されています。

記事の最初に「私と意見が合わなくて殺したい人がいるかも」という注意が書いてあることから当時のテンプレートエンジンに対する議論の白熱？具合が伺えます。

記事に書かれていること

PHP自体が良いテンプレートとは思えない

この記事の前半ではDjango（Pythonのウェブフレームワーク）のテンプレートと比較して次のようなことが書かれています。

PHP自体がテンプレートだという主張があるが…
- PHPは（言語としては進化してるが）テンプレートとして進化していない
  - 短く書けない
  - ありがちな処理をサポートしていない（例えばfor-else）
  - 再利用性がない（継承など）
    - 注: クラス継承ではなくテンプレート継承の意です
  - エスケープが大変（DjangoやRailsは自動エスケープなのに）
  - サンドボックス化できない

PHPの既存テンプレートに良いものがない

中盤では既存のPHP製テンプレートエンジンを探してみたけどいいのがない、ということが書かれています。Smarty、PHPTAL、eZ Components Templates、Dwoo、Calypsoを取り上げています。

Twigとの出会い

後半ではTwigにたどり着いた経緯が書かれています。

Djangoのテンプレートっぽいものを探したところTwigを見つけた
TwigはJinja作者であるArmin Ronacherによって書かれたもの
- 注: JinjaはPython製のテンプレートエンジンでDjangoのテンプレートと似ているけど別もの
2008年にとあるサービス向けにTwigが作られたがArminはPythonで仕事してる
彼に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 4をDeployerでデプロイしてSlackに通知する

Sun, 09 Dec 2018 00:00:00 +0900

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のインストール

Deployerは dep というコマンドを使って操作します。インストール方法は Deployer — Installation を参照してください。pharをダウンロードして配置する方法でもcomposerでインストールする方法でも dep というコマンドが利用できればOKです。

設定ファイル deploy.php を配置

dep コマンドが使えるようになったら、今度はデプロイするための設定ファイル deploy.php が必要です。このファイルは次のコマンドで雛形を作成することができます。

$ dep init

LaravelやSymfonyなど色々な選択肢が用意されており便利そうなのですが、この選択肢の Symfony は Symfony 2 を想定しているのと、この手の設定はまず動く最小限を用意してから必要に応じて増やす方が理解しやすいので、ここでは最小設定の deploy.php を用意しました。

<?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リポジトリ）を設定する
Symfonyのenvがprodになるように APP_ENV を設定する
デプロイ対象のホストとパスを設定する

それぞれ少し解説します。

レシピに `symfony4.php` を利用する

Deployerにはレシピ（recipe）というものが用意されています。と書くとそのような仕組みがあるかのようですが実際のところ「良くあるタスクをあらかじめ定義しておいたPHP」というだけで、利用するにあたっては require するだけです。

ここで利用している recipe/symfony4.php はDeployer公式のものなのでcomposerなどで追加する必要はなくそのまま参照して利用できます。内容は直接コードを見た方がわかりやすいです。

deployer/symfony4.php at master · deployphp/deployer

設定を変更していく際に symfony4.php の定義をみて既にある定義を使うのか、上書きするのか、追加するのか、など考えますので元のレシピ（設定）を把握しておくことは重要です。といっても symfony4.php に関していえば数十行しかなく簡単に把握できると思います。

envをprodにする

<?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 のパスに対してデプロイが行われます。

<?php
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 に次の記述を追加します。

<?php
set('shared_dirs', ['var/log', 'var/sessions', 'var/files']);

元のレシピの symfony4.php に既に shared_dirs が定義されていますが var/files を追加して上書きしています。このように元のレシピを確認しながら必要に応じて設定を変更することができます。

他にも例えば symfony4.php には database:migrate タスクが定義されているので、デプロイ完了前にマイグレーションを実行するような設定を行うこともできます。

Slackに通知する

おまけですがデプロイが完了したらSlackに通知する設定も追加します。Slackに通知する実装はDeployer本体には含まれていませんが、別のリポジトリで色々なレシピが公開されておりそこにSlackのレシピが存在します。公式サイトにドキュメントも存在します。

Deployer — Slack recipe

まずはcomposerで各種レシピを追加します。

$ composer require deployer/recipes --dev

次に deploy.php にSlackに関する設定を追加します。成功時に通知したいだけであれば次の3行を追加するだけです。

<?php
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を支える技術を読んだ ~ 中の人しか知り得ない貴重な記録

Sat, 24 Nov 2018 23:43:29 +0900

ドラゴンクエストXを支える技術 ── 大規模オンラインRPGの舞台裏 (WEB+DB PRESSプラスシリーズ)

作者: 青山公士
出版社/メーカー: 技術評論社
発売日: 2018/11/14
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

発売されることを知って予約注文していた本。読み終えたので感想文。先に一言で結論を書くと素晴らしい本だった。

この本の良いところ

この本が素晴らしいのはゲーム開発の実録になっていること。一般的な技術解説本の場合、著者が経験してきたことの集大成になることが多い。つまり色々なプロジェクトを経験した上でこれが最も良かったと思う内容がピックアップされる。効率よく学習したい読者にとっても普通はそのほうが良い。

しかし、この本では「ドラゴンクエストXで何をしたのか」しか書いていない。もちろんお手本になるものが中心ではあるけれど、失敗したこと、そしてそれがどのような大規模障害に繋がったのかが解説されている。

これはすごいことで、著者は自分（達）の失敗を明らかにするような本を書きたくないし、失敗する方法よりも成功する方法を伝えたいものだから。でも、この本には失敗談がたくさん盛り込まれている。失敗談をたくさん記述してくださった著者に敬意を表して失敗談の有用性について少しだけ書きたい。

失敗経験がないと良い方法を蔑ろにする

本（に限らないけれど）に書いてあった良い方法を学んで実践する。通常はこれで良い。けれども、悪いものを知らないとそれがどれだけ良いのかわからない。良さの程度がわからないと良い方法を蔑ろにする。

「こうした方が良いのだろうけど今回はその場凌ぎの対応をしておこう」というのは現場で頻繁にある。時間が限られているので仕方がないところもあるけれど、悪いものを知らないと「その場凌ぎであっても選択してはならない重大な欠陥がある方法」をあっさりやってしまったりする。

悪い方法について知らないからというのもあるけれど、何より失敗経験がないとその悪さを重大なものとして認識しにくい。

実際に失敗した人は違う。この悪い方法を選択したばかりに開発/運営チームは数日対応に追われお客様から大量の叱咤を受けたという経験から、時間がなくてもその方法を選択してはいけない、時間がないならリリースを延期してでも違う方法にしないとダメ、と言えるようになる。

こういった判断力を培うには普通は自分で失敗するしかないのだけど、この本はなんとその失敗経験をたったの2680円+税で提供しているのだから値千金ということ。しかも実際にドラゴンクエストXにどのような影響を与えたのかが常に記載されており社外の人間が読んでも臨場感のある内容になっている。

広範囲な内容

目次を見るとものすごい広範囲な内容になっていて、これだけ読めばオンラインゲームの全貌が掴めそうな感じ。とはいえ実際のところは次の点が中心だったように感じる。

ゲームサーバーのプロセス設計やDBの使い方
制約に対するアプローチ（メモリが足りない、アクセスが多くて高負荷など）

ページ数だけでみると他の章も結構紙面を割いているのだけど、開発体制やプログラミング言語に関するところ、グラフィックに関するところは基本的な内容が多いように感じた。

あまり公開されないチート対策についても記述されているので必見。

読み手を選ばない配慮の行き届いた文章

この本はドラゴンクエストXについてしか書いていないので当然ゲームとしてのドラゴンクエストXを知らないと理解しにくい部分があるのだけど心配無用でゲーム仕様どころか次のような解説からスタートしている。

RPGは、役割（Role）を演じる（Playing）ゲーム（Game）のことです。

p3より

また専門用語は使われているものの専門用語の使い始めに説明を記していることが多い。「フラグ」のような開発者でなくても知っていそうな言葉でも解説が入っている。

期待外れにならないように

この本では大体のことが方法論までしか触れておらず実装説明はあまりないので各部門の専門の人が読んだ際には物足りない感じはあるかもしれない。企業秘密的な側面もあるだろうし幅広い読者層を意識してのことだと思う。

プログラミング視点だとウルティマ開発者のこの本が具体的でかつ実践的だった。

ゲームコーディング・コンプリート一流になるためのゲームプログラミング (Professional game programming)

作者: Mike Mcshaffry,手島孝人,山下恵美子,依田光江,大貫宏美,廉典子,田中幸,宮本寿代
出版社/メーカー: ソフトバンククリエイティブ
発売日: 2010/03/31
メディア: 大型本
購入: 21人クリック: 265回
この商品を含むブログ (29件) を見る

オンラインゲーム設計視点だとやはりこの本を外せない（「ドラゴンクエストXを支える技術」の中でも言及がある）。

オンラインゲームを支える技術　　??壮大なプレイ空間の舞台裏 (WEB+DB PRESS plus)

作者: 中嶋謙互
出版社/メーカー: 技術評論社
発売日: 2011/03/24
メディア: 単行本（ソフトカバー）
購入: 33人クリック: 1,696回
この商品を含むブログ (57件) を見る

とはいっても各専門の人が読んでも期待外れに思うことはないと思う。なぜならこの著者ほどオンラインゲームの全体を把握し責任を持つ立場になっている人は日本にそれほどいないだろうから。

読み終えて思ったこと

買いましょう。読みましょう。良い本です。好きな呪文はベホマラーです。嫌いな呪文はマホトラです。

はてなブログに移行したついでに振り返りや近況など

Fri, 23 Nov 2018 09:46:57 +0900

はてなダイアリーからはてなブログに移行した。はてなダイアリーの最初の投稿は2005年11月22日のようなので昨日で13周年だったみたい。

Javaについて書くところから始めて、インターネット全般、読んだ本、写真のこと、いろいろ書いた。今では年に数回しか書いてない。

ブログを書かなくなったのはTwitterやFacebookでパッと書きたいことを書けるようになったからというのもあるし、以前よりもインターネットに情報が充実していて自分が書くまでもないと感じて書かないことも多かった。

インターネットに思うこと

最近は穏やかではないこともよく目にするけれど、自分が思ったことを検閲されずに広く公開できる場所は今でもやはりインターネットしかないと思う。検閲は国によるし日本でも最近話題に新しいけれど、なんの背景も持たない小さな個人が平等に扱われる場所としてインターネットはあり続けて欲しいと思う。

子供に思うこと

子供ができて感じるのはとにかく子供の能力を甘く見ていたなということ。5歳というとまだ幼児、つまり言葉は話せるけどまだまだ幼いというイメージだったけれど、本当に謝罪の上で撤回。論理的な思考ができるし社会性もある。身体能力も跳び箱9段跳べるとかびっくり。

今日のこと

下の子を朝寝から起こしてしばらくしたら離乳食をあげる。その頃には奥さんが起きてくるので（奥さんは夜中対応してくれているので午前中長めに寝る方針）、そしたら上の娘を連れてスケートに行ってくる。またスケートができるシーズンになって喜ばしい。

冬は大好きなので寒さも乾燥も大目に見るけれど静電気だけは消滅して欲しい。痛いの嫌い。ぺんてるの静電気除去グッズが手放せない毎日。

目的のために「手段」認定すると楽しくない

Sat, 04 Aug 2018 00:00:00 +0900

手段であって目的ではない、とよく言われる。現代の格言と言っても良い。英語を使って何をするかが重要なのだから英語を覚えることは手段でしかない。いかにももっともらしい。

ここでいう手段は目的を達成するための方法という意味だから、目的を何にするかによって何が手段になるのか異なる。目的によって変動する定義なのだから一般論として「○○は手段だ」と断じるとおかしい。宇宙全体の幸せが目的の人にとってはそれ以外の行為全てが手段でしょう。

一人の人間に対して目的が1つ、という決まりもない。同じ人間でも目的はいくつもある。ゲーム開発者がゲームプレイすると遊んで楽しい（プレイヤーとしての目的そのもの）と知見が増えた（開発者としての手段）と両方共存する。

手段であって目的ではない論法を目にした時、近視眼的で今まで見えていなかった目的が見えてよかったと思うなら良いけれど、自分のやっていることは手段でしかないのかと卑下するなら良くない。結局のところ、何をしたいの？どうしたいの？というのを自覚しましょうということでしかない。

これは経験的にだけど「手段」認定するとその行為が楽しくなくなるので基本的には目的であり手段でもある方が良い。よくプログラミングも手段であって目的ではないと言われる。確かにアプリケーションを作るためのプログラミングは手段だけど、より美しく保守性の高いプログラミングを考えてるときはそれ自体が達成したい目的だったりする。そう感じて頭を使う方が楽しいし創造的になる。もちろんそれを客観的に俯瞰してみれば「手段」認定できるけれど、そんなに手段手段言わなくても良いのではと思う。

noteでプログラミング超超超入門を書いてみる

Thu, 26 Apr 2018 00:00:00 +0900

プログラムが魔法でないことを知ればあなたもプログラマになれる

noteデビューしてみた。プログラミングの入門書って入門の割に初心者ブレイカーなことが多いとずっと思っていて、今日ふと思って書き始めてみた。プログラミング超超超入門として時間を見つけて書いてみたい。

家事分担における不平等感の解決

Fri, 23 Feb 2018 00:00:00 +0900

家事を分担すると、不平等に感じることがよくある。この不平等感の原因に「隣の芝生は青い」問題と「隣の芝生は本当に青い」問題を挙げたい。

「隣の芝生は青い」問題

Aはお風呂掃除を担当し、Bはトイレ掃除を担当するような場合。Aはトイレの方が掃除する面積が狭いから自分より楽だろうと思い、Bはお風呂は汚くないから良いなと思う。

このように自分が担当していないものの方が楽だと思ってしまいがち。とはいえ、気をつけて直せるようなものでもない（そう思ってしまうのは仕方がない）。

「隣の芝生は本当に青い」問題

Aは育児を担当し、Bはお風呂掃除とトイレ掃除と他にもたくさんの掃除を担当するような場合。仮にBが時間的に育児に匹敵するほど掃除をしていたとしても、実際のところ、精神的な負荷は圧倒的にAの方が大きい。そのため作業時間が同じでも不平等。Bは（時間的に）自分もたくさんやっていると感じているので、すれ違いになりやすい。仕事担当と育児担当で相殺しようとするとこれになりやすい。

※育児の方が圧倒的に大変かどうかは個人差があるので決め付けられないけれど、わかりやすそうな例として。

解決方法

私はXをするので、あなたはYをする、といった異なる作業で分担するのをやめる。私はXを1日10回する、あなたは仕事があるので回数は少なくて良いけれど同じXを1日2回する、のように時間や回数の比率で分担をすると良い。

時間/回数が異なっても作業内容が同じなので、隣の芝生にならず自分の芝生になる。自分の方が大変だ、という見解になりにくい。何より相手の大変さが理解できるようになるので誤解が少なくなり、必然と不平等感も少なくなる。

会社のブログを書いた

Mon, 11 Dec 2017 00:00:00 +0900

テストコードを簡単に書くための方法（PHPUnit）
http://developer.suzna.com/entry/2017/12/11/104228

前回書いたのがなんと2016-12-05なので1年ぶりになってしまった（一年間ずっと忙しかった）。

VRオフィスを使う10年後のリモートワーク

Sun, 15 Oct 2017 00:00:00 +0900

主にIT分野を中心にリモートワークが普及してきているように思う。もちろんメリットはあるけれど、デメリットもあるので、リモートワークの方が良いと断言できるようなケースはむしろ希であるように思う。

リモートワークのメリットとしては、遠隔の人を採用できる、家に一定時間居なければならない人でも働ける、通勤時間がなくなる、などがあり、デメリットとしては、コミュニケーションが難しい、作業管理が難しい（本当に働いているのかどうか）、などがある。

僕は将来リモートワークは採用する、しないではなくて当然になると思っているけれど、デメリットをどうやって克服するのかが問題。

オフィスに出勤している（リモートではなく）による恩恵は次のようなものがある。

その場所にいる（確実に仕事をしていることの証拠（ネットサーフィンしてるかはさておき））
状況が読み取れる（忙しそう、休憩中、話しかけても良いか）
会話に使えるツールが豊富（表情や動作を見ての会話、ホワイトボード、紙、その他多数）

つまり、空間を共有しているということが大きい。

ビデオ会議でも表情や簡単な身振りは読み取ることはできる。ただ、同じ空間で感じられる情報に比べればかなり欠落している。例えば、向こうで何か音がなったから少し振り向いた、といったことがあっても、立体的な音を共有していないので伝わらない。

この「空間」を全部VR（Virtual reality）に持っていけたら、物理的オフィスの意義がほとんどなくなる。

ただ、持っていけたら、というがもちろん現時点では難しい。実現にあたっては次のような点が必須だと思う。

VRに入ることが非常に簡単なこと
リアル空間と同等のツールが使え、同じ情報量が存在していること

10年後、どうやってこれを実現しているだろうかと考えると、きっと部屋ごとVRだと思う。

オフィスと個人の部屋やVR専用スペース（カフェ？）などを全て連結して一つの空間を作り、その映像を壁全体に投影して、共有空間を作る。音も方向に応じて鳴る。

スーパーの商品棚の端が鏡になっているのと似ていて、鏡の先が反射した商品ではなく本当に別の空間になっている感じ。

壁に向けてプロジェクタを設置するだけだと臨場感が低すぎるので、壁一面ディスプレイや非常に高解像度な投影など設備が必要になるし、音も環境音と主音をうまく制御できないと聞き取りが難しい。

だから、全員在宅勤務というよりは、専用の場所を使ったり、数人だけの小さなオフィスだったりが多いのではないかと思う。もちろん個人向けのツールも普及すると思う。

主に社内（勤務）を想定してここまで書いたけれど、これが実現すると営業活動、取引先との会議など社外での利用も当たり前になると思う。

現在はゲームを中心に第一人称カメラによる臨場感（没入感）が重要視されているけれど、今後、環境的なリアリティも重要になってくると思う。

こういうのはVRではなくMRではないかと言われそうだけど、おそらく単なるR（リアルが繋がってるだけ）か、やはりVR（みんなでバーチャル）か、という感じがする。

将来、賃貸の情報に「VR対応」とか書かれている日が来るかもしれない。

弦をDRに変えたらコシのあるサウンドで満足

Mon, 18 Sep 2017 00:00:00 +0900

最近のアーニーボールは以前ほど寿命が短くないと言う話をネットで見かけて、それならあのギラギラをと思って張り替えてみたのだけど、記憶のギラギラはなく（記憶なので不正確）少しまったりした感じの音だった。

それ自体は単なる記憶との差なので、まぁこんなものかなと思っていたら、弾いている最中に1弦を切ってしまった。

もう何年もギターを弾いている最中に弦を切っていないので、アーニーボールの印象が大分悪くなってしまった。

ダダリオやディーンマークレーに戻るのも面白くないので、改めてネットで評判の良い弦がないか探したところ、最終的に DR にしてみた。

なかなか良い。金属感はほどほどで高音の煌びやかさはそこまで強くないけれど、中音がしっかり鳴る。ディストーションとの相性もよく存在感のある音がする。手触りも良い。

張り替えてから十日ほど経っているけれど、あまり劣化していない。

知らなかったけれど、ダイムバッグ・ダレルが使っていたみたい。

DR エレキギター弦 TITE-FIT ニッケルメッキ .010-.046 MT-10

出版社/メーカー: DR
メディア: エレクトロニクス
この商品を含むブログを見る

しばらく DR を使ってみようと思う。

子供にレッテルを貼らない

Mon, 21 Aug 2017 00:00:00 +0900

「魔の2歳児」という言葉がある。「悪魔の3歳児」「天使の4歳児」というのもあるみたい。魔の2歳児はイヤイヤ期とも言われている。

子供が0歳〜1歳くらいの時に先輩パパ・ママたちに「今が一番可愛いいですよ。2歳になったら大変よ」とたくさん脅された。

子供はその時々でそれぞれ可愛いだろうし成長による充実もあるだろうから、先輩方のお話は話半分に、いや本当のところは話一厘くらいにしか聞いてなかった。

そして、2、3歳が過ぎて感じるのは、やっぱりそんなことはない、だ。

子供は脊髄反射でイヤイヤ言っているわけではなくて、もっと遊びたい、などのやりたいことの裏返し表現であることが多いように思う。そして、それは多くの大人たちと同じだと思う。ドラクエをもっとやりたいのに皿洗いしろだの早く寝ろだの言われた時の気分を考えて欲しい。子供の嫌がる気持ちはほとんどの場合で共感できた。

もちろん、子供のやりたいことを全て叶え続けることはできず、子供の嫌を押し切って進める結果、泣かれることもあるし、それ自体は親にとってストレスである。ただ、だからと言って、子供の主張が理不尽というわけではない。

僕は「魔の2歳児」という表現は良くないと思う。このようにレッテルを貼ってしまうと、子供が嫌と言う理由が「2歳だから」になってしまう。子供を「どうせ子供だから」と決めつけずに、大人と同じと考えれば、不思議な行動なんてないし「魔の」（や、悪魔の）などと揶揄されるような邪悪なものでは決してないと思う。

親が推測しきれなくてわからないことはたくさんあるけれど、それも単にわからなかっただけ。大人同士でもよくあること。というか日常的なこと。

未だに「今が一番可愛いですよ！」と言われることがあるけれど、今も将来も可愛いでしょ？と心の中でつぶやいている。

phpunitのUndefined class constant ’PARSE_CUSTOM_TAGS’の対処

Mon, 17 Jul 2017 00:00:00 +0900

はてなダイアリーのタイトル文字数の制限でSymfonyと入れられなかったけれどSymfonyの話。

The PHPUnit Bridge (The Symfony Components) を使う。

もしくは、PHPUnitを6.2.3にアップグレードしたら解決した。

■個人的に発生した環境
PHPUnit 5.7.2（phar）、Symfony v3.3.4

■参考
https://github.com/symfony/symfony/issues/19532

iPhone 7 Plusを買った

Fri, 18 Nov 2016 00:00:00 +0900

iPhone 7 Plusを買った。10/8に注文して11/13に届いた。色はローズゴール。ジェットブラックは店舗で見てみたけど指紋が目立ちすぎで僕には無理だった。

Apple Storeで購入して（SIMフリー）、LINEモバイルを契約した。色々速度比較サイトを見て通信環境が良さそうなのと、フリーカウント大きいなというところ。速度に関しては、通信環境の不満が大きくなった時に会社的に対応が早いだろうという憶測もして（ビジネスに直結だろうから）LINEモバイルに決めた。

届いたらまずは買ってあったガラスフィルムを貼った。

Farfalla iPhone7plus ブルーライト92%カット強化ガラス液晶保護フィルム 0.3mm

出版社/メーカー: Farfalla
メディア: エレクトロニクス
この商品を含むブログを見る

子供が触ることもあるのでブルーライトカット。この商品、なかなかよくて、変色した感じがほとんどしない。触り心地は程よく抵抗感がありつつもちゃんとスベスベしているし、汚れも簡単に拭き取れる。貼る時に入る気泡も簡単に追い出せたしとても気に入った。

iPhone 7 Plus posted by (C)cloned

この大きさだと落とさない方が奇跡だと思って、ケースも買った。ケースは11/11に注文して11/18に届いた。とても長く待った気分。きっとAmazon慣れのせい。買った商品はこれ。 http://propeller-design.jp/item/1750.html かわいい。

ポートレートモード、デジイチで撮るのに比べると被写体深度が浅すぎる（近いはずなのにボケる）、輪郭がやや不自然、というのがあるけれど、それでもエフェクトでぼかすのに比べたら格段に良いし、何よりカメラそのものの写りが綺麗だから楽しい。

容量は256GBにしたので、やっとそれなりに好きな音楽を適当に入れられるようになった。1TBくらいあれば全部入るので、そういう時代になりますように。

あとはなんだろう。前がiPhone 6だったので動作が速くなったのは嬉しい。あとバッテリーが長く持つようになったのも嬉しい（iPhone 6の劣化が激しかった）。

PSVRを買った

Sun, 23 Oct 2016 00:00:00 +0900

予約しようとしたら予約開始早々にどこも売り切れになってしまったので、Amazon.co.uk（イギリス）で予約した。

到着は10/20予定となっていたけれど、発売日（10/13）に発送され10/17に届いたので、割とすぐに手元に来た感じ。

価格は42,240円（290.83ユーロ）で買えたので、定価48,578円に比べると結構安く買えた。

PSVR posted by (C)cloned

梱包が大きい。開けてみたらPSVR本体が結構大きかった。

PSVR posted by (C)cloned

電源ケーブルの形状が海外仕様だったので、家にある別のケーブルを付け替えた。それ以外は説明書が英語なくらいで、問題なく動作した。

付属のdemoをやってみて、あとは評判の良いRez Infiniteを購入してやってみてる。まだArea Xをちゃんとプレイできていないので、Rez Infiniteの感想はまた今度。

ディスプレイの解像度はドットが視認できるので気になるといえば気になる。シネマティックモードで映画を観ると大画面の迫力は素敵である反面、たまにドットが気になって没入感が薄れることがある。

ジャイロセンサー、加速度センサーやリフレッシュレートなどは今の所気になるところはなく、自分の動きにしっかり追従してくれていると感じる。音もちゃんと自分の位置、向きに対応していて臨場感がある。

接続ケーブルや端末が多くて辛いけれど、PSVRに対応した大御所ゲームの発売が待ち遠しい。

音楽のレコメンド機能を作るには音源の解析が必要に思う

Fri, 16 Sep 2016 00:00:00 +0900

Apple Musicなどのアプリでレコメンドされる音楽はなかなか好きに出会えない。

人によるだろうけれど、音楽は好き/嫌いと感じるポイントが非常に細かくあり、ちょっと違うとあまり好きではないものになる。

例えば、僕はDream Theaterが好きだけど、プログレッシブ・メタルというジャンルだけで好きに出会うことはほとんどない。Dream Theaterが好きな理由を列挙すると

音色/和音/旋律/展開/テンポなどが基本的に好み
歌にメロディーがある方が好き
綺麗に歌うボーカルが好き
和音が感じられる楽曲が好き（必然とキーボードの音がある楽曲の方が好き）
一塊のメロディーがたまたま変拍子であった、と感じられるような変拍子が好き（ランダムに切り取られたような激しすぎる変拍子は嫌い）
速い奏法を生かしたソロフレーズが好きだが、緩急がなくずっと速いだけであったり、メロディー性が薄いソロは嫌い
ドラムやベースに繰り返しパターンが少なく聴き飽きないリズムが好き（特にポートノイ時代）
楽曲としても繰り返しが少なく展開するものが好きだが、旋律が頭に残らないほど展開しすぎると嫌い
ヘビーなサウンドが好きだが、ドンシャリだったり低音を強調しすぎていると嫌い

キリがないけれども、こういう細かいポイントがいろいろあって好きなのであって、とあるジャンルが好き、というのでは全然ない。

また、上はDream Theaterが好きな理由であって、例えば、たかじんの歌が好きな理由は全く異なる。

こうしたことを考えると、好きな（好きそうな）音楽を提案するプログラムを作るのであれば、音源を解析し一つ一つの音楽がどういう情報を持っているのかを把握できないと難しいだろうなと思った。

Symfonyから手早くYAMLのFixtureを読み込めるAliceFixturesBundle

Thu, 03 Dec 2015 00:00:00 +0900

この記事は Symfony Advent Calendar 2015 の4日目の記事です。

開発環境向けのテストデータ（Fixture）作成は hautelook/AliceBundle を使えば便利だけど、テストコードからFixtureを読み込もうとすると一手間かかるので、何かないものかと探したところ h4cc/AliceFixturesBundle に出会った話。

データベースを利用したテストコードを書く場合、テストデータの準備が必要になることが多い。「テストコードを書く労力を減らす」「テストコードの見通しを良くする」という観点から、テストコードのためのデータ準備は極力簡単にしたいところ。

Symfony + Doctrineを利用している場合に真っ先に選択肢に上がるものとして DoctrineFixturesBundle があるけれど、見ての通りFixture自体がPHPコードであり、テストデータの準備に苦労が絶えない。

そこで登場するのが nelmio/alice を利用できる hautelook/AliceBundle で、これについては去年の Symfony Advent Calendar 2014 の記事である [Symfony] AliceBundleで自動テストのfixtureをyml化しようが詳しい。すごくわかりやすいのでご一読を。

どういうYAMLになるかというとこういう感じ。

AppBundle\Entity\User:
    user{1..10}:
        username: <username()>
        fullname: <firstName()> <lastName()>
        birthDate: <date()>
        email: <email()>
        favoriteNumber: 50%? <numberBetween(1, 200)>

これで10件のuserが作成され、それぞれにFakerを利用したランダムな名前や誕生日、メールアドレスなどが設定される。

PHPコードでテストデータを用意する苦労からは解放されたものの、まだ面倒な点があり、先に紹介した [Symfony] AliceBundleで自動テストのfixtureをyml化しようから引用させていただくと、

<?php
$this->loadFixtures(
    array(
        new UserFixtureLoader(),
    )
);

このように一つのFixtureごとにPHPのクラス（ここではUserFixtureLoaderのこと）を作らなければならない。これは結構面倒だ。

それで色々と探していたところ h4cc/AliceFixturesBundle を発見した。DoctrineFixturesBundle に依存しないため、より簡潔なFixtureの読み込みを実現している。

具体的な実装はデモのテストコード、AliceDemo/src/h4cc/AliceDemoBundle/Tests/Controller/UserControllerTest.php を見るとわかりやすい。

抜粋すると、

<?php
public static function setUpBeforeClass()
{
    $client = static::createClient();
    $manager = $client->getContainer()->get('h4cc_alice_fixtures.manager');
    static::$fixtures = $manager->loadFiles(array(__DIR__ . '/DataFixtures/Alice/alice.yml'));
    $manager->persist(static::$fixtures);
}

こういう感じで直接AliceのYAMLを指定するだけとなっており、Loaderクラスを作成する必要がなく大変便利。

ということで、 h4cc/AliceFixturesBundle の紹介でした。なんと Symfony Advent Calendar 2015 の次の日、12/5はまだ空いているので、どなたかよろしくお願いします！

「フラットデザインで考える新しいUIデザインのセオリー」を読んだ

Sat, 17 Jan 2015 00:00:00 +0900

フラットデザインで考える新しいUIデザインのセオリー

作者: 宇野雄
出版社/メーカー: 技術評論社
発売日: 2014/11/21
メディア: 単行本（ソフトカバー）
この商品を含むブログ (2件) を見る

Modern UI 、Material Design、iOSなど、フラットデザインを冠するUIの違いを比較しながら、みんながざっくり呼んでいる「フラットデザイン」の正体を概観しつつ、それを踏まえてこれからのUIデザインを考えるための基本的な考察を提供するような感じになっている。

概観している部分の一例としては

つまり人が触るパーツを丸く、それ以外の要素をすべて角のある矩形で構成するのです。これはGoogleが非常にうまく実現している手法です。
フラットデザインで考える新しいUIデザインのセオリー P84

例えばiOS 7以降のiOSでは、基本のキーカラーを水色と定めて、水色になっている部分はすべて押せるパーツというルールを作り、その他の色を基本的に排除しました。
フラットデザインで考える新しいUIデザインのセオリー P109

こういう感じで、それぞれどのようなアプローチでフラットデザインを実現しているのかを具に解説している。世の中的にはどうしてもiOSとAndroidにフォーカスしがちなところを、Windowsやフラットデザイン的なウェブサイトなど、幅広く扱っているところが良い。

フラットデザインの特徴を踏まえつつ、これからのUIデザインを考えるための考察として、配色、余白、フォント、各種UIパーツ（ボタンやチェックボックスなど）の表現手法など、フラットデザインに触れつつ解説されている。

最近、我々がよく見るソフトウェア上のUIデザインを改めて解説されてみる、というテーマとして良書だと思う。案外気付けていなかった部分や、普段自分が使っていないOSのデザイン手法など、なるほどなーと思うところが多かった。

iPhone 6を買った

Wed, 29 Oct 2014 00:00:00 +0900

iPhone 6 posted by (C)cloned

手元のiPhone 4sが下取りされる運命にあると知ったので、購入日からずっと貼っていたフィルムを剥がして新品同様の美しいiPhone 4sを使っていたら、iPhone 6の在庫があっさり見つかった。

iPhone 6は吹き付け仕上げな感じで、今までの金属感がなく安っぽい。Touch IDは便利だし、画面が広いのも左上が届かない以外は見やすいし良いのだけれど、良いものを手にした感は薄れたかなぁ。

UnityのWWW、WWWFormのハマりどころ

Mon, 09 Jun 2014 00:00:00 +0900

UnityにバンドルされているWWWクラスを使うと簡単にHTTP通信を行うことができて便利なのだけど、色々やろうとするといくつか判り難い挙動があったので、その辺りをメモ。

Unityのバージョンは4.5。

WWWのコンストラクタには下記の4つ（最後のものは非推奨）がある。ドキュメントはUnity - Scripting API: WWW.WWW。

WWW(string url);
WWW(string url, WWWForm form);
WWW(string url, byte[] postData);
WWW(string url, byte[] postData, Dictionary headers);
WWW(string url, byte[] postData, Hashtable headers); // deprecated

ここでまず気をつける必要があるのが、WWWFormクラスをそのまま渡す場合は、第三引数にHTTPヘッダを渡すことができない点。下記、ここから引き起こされるハマりどころ。

ファイル添付したらヘッダを追加できない？

WWWForm.AddBinaryData() を使うとファイルアップロードが可能だけど、HTTPヘッダも同時に変更したい場合に困ったことになる。

Dictionary<string, string> headers = new Dictionary<string, string>();
headers.Add("Cookie", "a=b");

WWForm form = new WWWForm();
form.AddBinaryData("foo", binary, "foo.png", "image/png");

WWW www = new WWW("http://example.com/", form.data, headers);

このようにすると正しくファイルアプロードができない。ここでHTTPヘッダを変更せずに WWW(string url, WWWForm form); コンストラクタを利用すると正しく動作するようになる。

WWForm form = new WWWForm();
form.AddBinaryData("foo", binary, "foo.png", "image/png");

WWW www = new WWW("http://example.com/", form);

ということは、コンストラクタの第二引数がformそのものではなくform.dataなのが駄目で、WWWFormインスタンスだから動作するのか、と結論付けてしまうとヘッダの変更ができなくなってしまう。

実際にはそうではなくて下記の挙動が考慮できていないことが原因。

WWW(string url, WWWForm form); コンストラクタを利用するとヘッダは内部でWWWForm.headersの値が利用される。
WWWForm.AddBinaryData() を呼び出すとWWWForm.headersにContent-Typeが自動的に追加される。
- 実際の値は multipart/form-data; boundary="xxxx"' という感じ

つまり、WWWForm.AddBinaryData() 後に追加されているContent-Typeヘッダの存在を無視して自前のヘッダのみを追加したことが原因なので、下記のようにWWWForm.headersを値を最後に設定するようにすれば動作するようになる。

Dictionary<string, string> headers = new Dictionary<string, string>();
headers.Add("Cookie", "a=b");

WWForm form = new WWWForm();
form.AddBinaryData("foo", binary, "foo.png", "image/png");

foreach (DictionaryEntry entry in form.headers)
{
    headers[System.Convert.ToString(entry.Key)] = System.Convert.ToString(entry.Value);
}

WWW www = new WWW("http://example.com/", form.data, headers);

GETだとHTTPヘッダを追加できない？

WWWクラスはコンストラクタ呼び出し時にWWWForm、もしくはpostDataが存在するとPOSTと解釈するようになっている。POSTの場合は単に第三引数にヘッダのDictionaryを渡せば良いが、GETの場合は適切なコンストラクタがない、ように見えるけれど、nullを渡せばGETでもヘッダを追加できる。

WWW www = new WWW("http://example.com/", null, headers);

POSTでpostDataがない場合はHTTPヘッダを追加できない？

応用編。POSTにも関わらず、POSTするデータはない。けれどもHTTPヘッダを追加したい。みたいな場合はどうしようもないので

form.AddField("dummy", "dummy");

とでもするしかないと思われる。postDataが空の場合は下記エラーになる。

Error when creating request. POST request with a zero-sized post buffer is not supported.

GET、POSTだけではなくPUT、DELETEも使いたい

使えない。上述のように、GETとPOSTが自動判定されるような機構で、PUT、DELETEはサポートされていない。

そういうわけでWWW用の便利なクラスを書いた

こういったハマりポイントを解決しつつ、もう少し楽にWWWとWWWFormを使いたいと思って、一つクラスを書いたのでGistに貼っておいた。

WWWClient.cs

特徴としては

コルーチンを使わないでコールバック（Delegate）で終了後の処理を書ける（内部ではコルーチンを使っている）
タイムアウトをサポート（地味に必要ですよね）
上述の複雑なコンストラクタのハマりどころをできるだけ解決

タイムアウトに関してはDEBUG.LOG (WWWクラスのタイムアウト処理)を参考にさせてもらいました。

使い方は下記な感じ。

using WWWKit;

public class WWWClientExample : MonoBehaviour
{
    void Start()
    {
        // 単純なGETリクエスト。終了処理はOnDoneプロパティにDelegateを代入。
        // DelegateにはおなじみのWWWクラスが渡されるのでレスポンスに関する
        // 処理は今まで通りWWWクラスのノウハウが利用可能。
        WWWClient client = new WWWClient(this, "http://example.com/");
        client.OnDone = (WWW www) => {
            Debug.Log(www.text);
        };
        client.Request();

        // POSTリクエストの場合は、WWWクラスの思想を継承して、下記のように
        // postDataを設定したらPOSTになる、という仕様。
        WWWClient http = new WWWClient(this, "http://example.com/");
        client.AddData("foo", "bar");
        client.OnDone = (WWW www) => {
            Debug.Log(www.text);
        };
        client.Request();

        // ファイル添付したい場合。下記はstringをbyte[]にしてるけど画像など
        // 何でも可能。
        byte[] binary = System.Text.Encoding.Unicode.GetBytes("bar");
        WWWClient http = new WWWClient(this, "http://example.com/");
        client.AddBinaryData("foo", binary, "test.txt", "application/octet-stream");
        client.OnDone = (WWW www) => {
            Debug.Log(www.text);
        };
        client.Request();

        // エラーハンドリングをする場合は、OnFailプロパティにDelegateを代入。
        // 正常終了のハンドリングと同じくWWWクラスが渡されるのでごにょごにょする。
        client.OnFail = (WWW www) => {
            Debug.Log(www.error);
        };

        // タイムアウトの場合はWWWクラスがDispose()された後で利用できなくなって
        // いるので、引数なしのDelegateをOnDisposedプロパティに代入する。
        client.OnDisposed = () => {
            Debug.Log("Timed out");
        };

        // タイムアウトを設定する場合はTimeoutプロパティに値を代入（float）。
        // デフォルトはタイムアウト設定なし（無制限）。
        client.Timeout = 10f;

        // ヘッダを追加する。
        client.AddHeader("Cookie", "cookiename=cookievalue");   
    }
}

WebKitは欧文フォントによって和文フォントを切り替えている

Mon, 24 Mar 2014 00:00:00 +0900

知らなかった。CSSで和文フォントが指定されていない場合、ブラウザのデフォルト指定フォントで表示されるものだと思っていたけど、WebKit（Safari）やWebKitからフォークしたBlink（Chrome）では、欧文フォントによって和文フォントが切り替わるようになっているみたい。Safariは7.0.2、Chromeは33.0.1750.152で確認。

それぞれ和文フォントを指定していないのに欧文フォントの空気を読んで和文フォントまで明朝体、ゴシック体、ボールドに切り替わっている。ここに表示しているのは画像で実際のHTMLサンプルはこちら。

ただ、WindowsだとChromeでもこうならない。Linuxは未確認。

日本人が日本語のウェブサイトを作るときは日本語フォントを指定すると思うので気にするまでもないけど、最近Facebookのニュースフィードのシェアに明朝体が表示されるようになって、そういう趣味になったのかと思ってフォント指定を調べたら、欧文フォントしか指定されていなかったので、もしかしてと思ったらそうだった。

SLAの稼働率がどのくらいのダウンタイムなのか計算するツール作った

Thu, 13 Feb 2014 00:00:00 +0900

稼働率 => 月間ダウンタイム計算ツール
http://cloned.jp/sla-calc/

ついでなので、有名どころのSLAを調べて載せたんだけど、Google App Engineの95.0％未満で50%返金や、Amazon EC2の 99.0％未満で30%返金みたいな返金レートは国産だと見つけられなかった。みんな10%で統一されていて15%というのが1件見つかったくらい。

そんなにたくさん調べていないのでざっと見た感じだけど、IDCフロンティアの稼働保証が 99.999% と高かった。

topよりグラフィカルで操作性の良いhtopを使ってみた

Sun, 22 Dec 2013 00:00:00 +0900

htop - an interactive process-viewer for Linux

topに色を付けたいと思っていたらhtopというのがあったので使ってみた。SourceForgeに初めてコミットされたのが2006年3月4日となっていてそんなに新しいプロジェクトではないけれど、4日前にもコミットされていて、ちゃんとメンテされている模様。

Amazon Linuxだとyum リポジトリに入っているので下記だけでインストールできる。

$ sudo yum install htop

色が付いた以上に、CPUやメモリのグラフィカルな表示が可愛い！！

表示中のプロセスをスペースキーで選択状態にできて（画像だと黄色の行）、その場でF9を送信すると選択中のプロセスをkillできる強者。とはいえ、（プロセス番号ではなく）かなりカジュアルにkillできてしまうので本番で使うには恐いなーと思った。

操作性が良くて、表示されていない箇所は下にも上にもスクロールできて、プロセスの選択はマウスでポチっとできるし、各操作もキーバインドを覚える事無く明記されているファンクションキーから各操作ができる。上の画像はF6 SortByを選択したときのもの。topのキーバインドは全く覚えられなくて困る（hでヘルプ出せばわかるっちゃわかるけど）。

開発環境でしばらく使ってみよう。