モヤイ像の絵文字の話

https://turingcomplete.fm/12 を聞いていて、モヤイ像について昔ちょっと調べたのを思い出したので掘り起こしてみる。

Unicodeに収録された絵文字のなかに「モヤイ像」というものがある。これ、モアイ像ではなくて “Japanese stone statue like Moai on Easter Island”、つまり「イースター島にあるモアイ像みたいな日本の石像」として定義されている。ちなみにモアイ像の絵文字というものはないのであった。マジで? マジで。

モヤイ像というのは東京の渋谷駅のランドマークになっているアレであって(細かく言うと色々あるのだがそれについては後述)、イースター島のモアイ像とは似せたようなかんじであってもまあ違う。髪もあるし。上述リンクの図像もまさに渋谷のモヤイ像のような見た目になっている。どうしてこんなことになっているのだろうか?

いっぽうemojipediaで見てみるとほとんどみんなモアイ像っぽい見た目になっているのであった。モヤイ像っぽいやつ、HTCとかぐらいしかないぞ。説明もMoyai (also spelled as Moai)だし、これでいいのか??

たぶん、これでもいいんじゃないかとおもう。

そもそもこの絵文字がどこから来たのかというと、日本の携帯キャリアの絵文字だ。で、どのキャリアから来ていてもともとどうなっていたのかというと、これは調べられる。Unicodeに絵文字の編入を提案する際、グーグルのチームが絵文字のリストおよび当時の携帯キャリアの文字との対応関係をまとめたemoji4unicodeというプロジェクトがある。このdata/emoji4unicode.xmlを見てみると、モヤイ像の絵文字はもともとKDDIの絵文字からきていてドコモとソフトバンクにないことがわかる。そして名前はMOYAIだがテキストフォールバック(対応しない環境でテキスト化して表示する場合の文字列)は「モアイ」となっている。いったいどっちなのか?

さてKDDIの絵文字の仕様はまだウェブで見ることができて、この文字はタイプDの表に含まれている。ここにそのスクリーンショットを見せよう。

Screenshot 2018-04-12 at 23.09.40

なんともともと図像のほうはモアイ像なのであった。でもたしかに説明はモヤイ像となっていて、なんだかよくわからない。

更に調べてみると、当時のKDDIの携帯電話では「しぶや」を変換するとモアイ像の絵文字が出てくるらしいことがわかる。つまり確信的にモヤイ像として扱われている、が、それだけでは用途が限られすぎているのでモアイ像としての利用もできるよう、意図的に曖昧にしてどっちでもありとしたのではないかと思われる(そこまで深く考えてなくて同じようなもんだろうと思っていた可能性もある)。

ではUnicode 6.0ではなぜモヤイ像という説明が採用されたのか、については定かではないのだけど、そもそもオリジナルのほうでの説明がモヤイ像なのでUnicodeの仕様としてはそちらを採用したのだろう。テキストフォールバックがモアイなのは、そのほうが現実の使われ方や見た目を反映していたからではないかとおもう。

そういうわけで、もともと曖昧な絵文字だったのでわりとどっちでもいいのではないか、というふうに思うし、そんなにだれもかれもモヤイ像のことを知っているわけでもないわけで、モアイ像が採用されるのもむべなるかな、である。

ところで、モヤイ像のほう、よくかんがえると作者もいる芸術作品であって、そういうものがUnicodeみたいな国際規格に含まれているというのはなんだか不思議な気分である。もちろん自由の女神像とか東京タワー(エッフェル塔)みたいな巨大でシンボリックな構築物の絵文字はあるのだが、それらにくらべればあまりにもローカルで、あまりにも小さなものではないか。たとえばモナリザとかミケランジェロ像とかの絵文字があるわけでもないのにモヤイ像、と考えるとなんだか不思議なものだ。そういえば誰がいつ作ったものなんだっけ?

というわけでウィキペディアで調べてみるとモヤイ像というのは、新島出身の芸術家である大後友市という人の芸術活動なのだそうである。島で産出される石をつかった彫像ということで、渋谷以外にもあちこちあるのだそうだ。新島には100体以上あるという。

渋谷に設置されたのは1980年のこと、新島が東京に編入されて100年を記念してのことだったというから、ずいぶん前からあるわけだ。

この大後友市さんという作者は残念ながらすでに亡くなっている。2010年9月11日、脳梗塞のため。享年79という。Unicode 6.0でモヤイ像が国際規格の一部になったのは2010年10月11日のことだから、そのわずか1ヶ月前のことだった。

自身の芸術作品が国際規格になりつつあることを知っていたかどうかについては記録にない。

スプラトゥーン2のスペシャルのはなし

https://note.mu/r_nikaido/n/ncac16b5a1001

これを読んでの反論というか雑感。

なお自分の腕前はざっくりいうとS+下位、おもにスピナー使いのエンジョイ勢。1のときはS+に上がれたことがあったかどうか、という程度のS帯。

share_picture (2)

で。

自分の違和感というか異論の根幹は

ゲージを溜めに溜めた貴重な必殺技

というスペシャルの位置づけではないかとおもった。スペシャル、そういうんじゃないでしょ……。名前がいうほどには特別感はないし、せいぜいブキの機能のひとつぐらいでしかないようにおもう。それに必殺技ってのもちょっとちがう。

敷衍して、また全体的な論旨からかんがえるに、この文章の著者はスプラトゥーンをFPS/TPSの一種であって、スペシャルを発動させて敵を蹂躙するなどのアクションを楽しむゲームとして位置づけているのではないか?

自分はあんまりそうおもってない。キル数そのもので勝敗が決するわけじゃないわけで、ある特定のルールの上での勝敗を決するゲームであるとおもっている。敵と戦って撃ち勝つのは大事なんだけど、それだけじゃないし、だからこそユニークな面白さのあるゲームなんではないか……べつないいかたでいうと、ぶっちゃけ自分はエイムもゴミだしぜんぜん戦えないプレイヤーなわけなんで、そういうゲームだとつらい。よくつかってるスピナーもだいたい補助的な役割が多いし。

そういう観点からいうと、スペシャルは状況におうじて的確につかうもので、キルをねらいにいくときもあれば、それ以外の目的でつかうこともある。たとえばマルチミサイルやハイパープレッサーはたいしてキルをとるのには向いてないけど、敵を移動させたり妨害したりといった使い方がある。

これに比べると1のころのスペシャルはつかいみちも限定されてて、それこそキルを取るぐらいしかできないものばっかりで、ゲームプレイを単調にしていたのではないか。

その意味で、

・1のスペシャルは、「キルできたのは自分が上手かったから」
・2のスペシャルは、「キルできたのは相手が下手だったから」

というのは全く違うとおもう。キルをとれたかどうかに限定せずスペシャルが有効に使えたかどうかで考えてみると、「相手が下手だったから」なんてことはまったくなくて、状況をちゃんとみて必要な行動を理解する必要があって、1のころより2のほうがずっと、プレイヤーの習熟を必要とする。

あとチャクチ狩り、S+下位でもふつうによく見られるとおもうんだけど。ヘタな人が無敵状態になる前に落とされるやつ。むしろS+ぐらいだとそこまでヘタな人がすくないのであんま見られないかも。

これは「eSportsに寄せた調整」というべきなのか? 自分は、戦闘アクションやスペシャルで一掃する「爽快感」ではない、スプラトゥーンのもっていたゲーム性というものがあって、そちらによせてきた、ということではないかとおもう。

さっきもかいたけど、自分がよくつかうのはキルのとりやすいブキじゃなく、どっちかというと補助的な役割のほうがおおきい。そもそもそんなに上手くないのでキルはぜんぜんとれない。そういう人間からすると、キルのとりあい一辺倒なゲームよりも、いろんなタイプのブキがそれぞれに意味があって、それぞれのプレイスタイルが噛み合わないと勝ちづらい、そんなゲームのほうが優れたゲームではないか、とおもえる。それがeSports的だ、というなら反論はしないけど、であればべつに実況や大会を志向しているってことではないとおもう。

でもそうだとすると、1のほうが初心者向けでわいわいたのしめたよね、2は玄人向け、ということはあるだろうか? 自分は1をやっていたから、そこはわからない……けど、2がかならずしも玄人向けってことはないんじゃないかとおもう。それぞれのブキによるプレイスタイルの多様さ、シューター系ゲーム経験者じゃなくてもたのしめる間口のひろさ、っていう言い方もあるのではないかなあ。

ただ、このゲーム性の関係上、スプラトゥーンは複数人がきちんと協力しないと勝ちづらいつくりになっているのは確か。1ではそれでも単独で無双していれば勝てたりしたんではないかとおもうけど、2ではこれがかなり難しくなったように調整されているとおもう。新ルールのガチアサリもこの方向性で、あれマジで一人でがんばってもまったく勝てない。開始当初のC帯のつらさよ……。

その結果、ランダムなガチマッチがつらい、ボイスチャットしながらリーグマッチするほうがたのしい、という話は、わかる。自分はリーグマッチとかプライベートマッチとかあんまりしてなくて、ふつうのガチマッチもたのしいと思っている。こまかい意思疎通できないなかだからこそおもしろいってのはあるんじゃないかとおもうけど、マッチングした味方がヘタでまけたりするとつらいしな……。真剣なガチ勢はストレスをためがちかも、っていいう気はする。

なおボイスチャットなしの非常にかぎられたコミュニケーションしかないセッティングは正しかったんじゃないか。いやたぶんこれはゲーム性とはあんま関係なく、見知らぬ人とのランダムプレイにボイスチャットがあると罵詈雑言のとびかうイヤな世界になっただろうからだが。

ともあれ、スプラトゥーンは2において、キルのとりあいなシューターゲームとはまたちがった、独特の立ち位置を志向したのだとおもっている。もちろんそれがうまくいっているかどうかとか、バランス調整がうまくいっているか、というのは別な話であるけれど、でもスペシャルのこの方向性は、理不尽がどうとかいうことではなくて、そういうゲームの方向性の話ではないか(だいいち理不尽さが課題なら1確のブキとかもっと調整するはずでは)。で、自分はその方向性じたいは支持する。

まあそんなかんじです。

 

今時のウェブアプリのローカルストレージ事情

ウェブ系のストレージやクォータまわりのことをあんまり追ってなかったらけっこうかわっていたのでメモ。

そもそもは、 https://voice-memos.appspot.com/ というウェブアプリがあって録音ができるんだけど、で録音したデータはローカルに保存してるっぽいんだけど(IndexedDBを使っているっぽい)、どれぐらい長時間の音が録音できるんだろうか?ってのが気になったのだった。せいぜい数分なのか、それなりの時間でもオッケーなのか? というのは気になるところではないか?

ストレージ容量

クォータはnavigator.storage.estimate()という関数でとれる。ふつうにpromiseをかえすので、console.logなどしてみれば、てもとの端末だと(Chrome 64, Pixelbook)、

> navigator.storage.estimate().then(({quota}) => console.log(quota / 1024 / 1024 / 1024))
Promise {<pending>}
7.009137216955423

7GBくらい。意外とある。

ただ、実際にいろいろためしてみると(Chromeの場合)どのサイトにいっても同じ容量が提示される。もちろんそんなに無制限にストレージがつかえるわけがない。基本的にはこうしたデータは一時的なストレージであって、実際につかえるストレージを使いはたしそうになると問答無用に消されていく。

このへんの挙動やクォータ設定は、もちろんブラウザごとにいろいろちがう。https://developers.google.com/web/fundamentals/instant-and-offline/web-storage/offline-for-pwa に情報がまとめられているが、Chrome / Firefox はデバイスの残容量にもとづいてクォータを設定していて、ストレージを使いまくるとLRUでふるいデータを消していく。SafariとEdgeは消されないけどクォータはかなりすくないようにみえる。

さていきなり消されてしまうとこまるので、persistent storageとしてつかいたい、というリクエストを発行するAPIが用意されている。APIをよびだして許可されれば、つかったストレージはLRUにもとづいて消されたりせず永続化する。ただ許可といっても一般的なパーミッションAPIと(Chromeの場合は)ちがって、ユーザに許可をもとめるのではなく一定の条件で自動的に許可が降りるようになっている。詳しくは  https://developers.google.com/web/updates/2016/06/persistent-storage に記載がある。

ストレージの種類

かつていろんなストレージ系APIがあった。webSQLとか、filesystem APIとか、なんやかんや……。だいたいみんな消えた。現状、このへんはだいたい3種類に絞られてきているようだ。localStorage、CacheStorage、IndexedDBのみっつ。

localStorageとIndexedDBは前からあるけど、CacheStorage?っておもったのだが、service workersの文脈でよく登場するので誤解していたけれど、じつはふつうのブラウザ内のJSからもふつうに使える。ふつうのKVSとしても使える。IndexedDBとくらべるとだいぶ使うのがラクに思える。ただ、httpsでしかつかえないし、名前的にもフェッチ結果等のキャッシュにかぎって使ったほうがいいのだとおもう。swに保持してほしいデータをページからコントロールしたいときとかに使うべきなのだろう。

まあこのへんは直接さわるよりはなんかwrapしてくれるAPIを使うことのほうが多いんじゃないか、という気がするが。


そういうわけでもとの疑問に戻ると、当該ウェブアプリはストレージにIndexedDBを使っているので、Chromeとかであればわりとまともな時間でも保存できるようだ(iOS Safariだと無理かも)。ただpersistent storageは要求していないので、あんまり昔に録音したデータとかがいつのまにか消えている、てことはある。常識的な範囲内でつかえば意外とふつうにつかえそう。

スプラトゥーン2の英語

1のときにも記事かきましたけど。

2における最大にして重大な変更といえば、なにをおいても

カモンがC’mon!からThis way!になった

ことでありましょう。

1のとき、日本語版における「カモン!」のメッセージは、英語版では(おそらく深い考えなしに)「C’mon!」と訳されていました。が、英語でcome on!といえば、日本語における「カモン」のように「来い」という意味もある一方で、こう、相手を煽るというか、けなすというか、そういった意味合いもありました。実際、ヘマして水に落ちるとc’mon!連打する人とかもいた。

これはよろしくないので本来の意味がより直接的につたわるよう、This way!となったわけで、まぎれがなくなりました。

それにしてもこの翻訳、「いわれてみればなるほど」だけど、おそらく非ネイティブであればなかなか見逃してもしかたないようなミスだよなあ。あらためて、ゲーム翻訳の世界における興味深い事例といえるのではないかなあとあらためて思った次第。

マニューバはdualies、シェルター類はbrella

ほかだと新武器類であるマニューバ、シェルターはどうか。マニューバは英語でmaneuverですがこれだと意味は通らないからか、dualiesという名前になっています。dualは二重という意味。他の言語でもだいたい二重とか2つといった意味の語が選ばれているようです。

シェルター系。パラシェルターはsplat brella、キャンピングシェルターはtent brella、スパイガジェットはundercover brellaというように、brellaを武器種名としてつかっています。umbrella(傘)からの語ですね。これはまあわかりやすい。というかパラシェルターのほうがよくわからないよな。

ガチアサリはClam Blitz

新ルールのガチアサリですが、英語版ではClam Blitzとなっています。Clamはアサリみたいな貝のこと。Blitzはドイツ語の「電撃戦」(blitzkrieg)から転じて急襲といった意味のある語……ただこれ、アサリの形状がどうみてもアメフトボールなので、まあアメフト用語のブリッツ(blitz)を念頭において考えられた語だろうな、とおもいます。

バッテラストリートがThe Reef

新ステージ名はバッテラだの海女だのガンガゼだのフジツボだのエンガワだのと、なかなか翻訳がむずかしそうな語がおおいですが、だいたい適当にぜんぜん違う海産物系の名前をつかってます。

が、バッテラストリートについてはもうなんか完全にあきらめたのか、The Reefとなっていました。Reefは岩礁といった名前の語です。某ウィキによると、他の言語ではスシなんとか、みたいな名前のようなので、なぜ英語だけおもいきって変えたのかは、ちょっと謎ですが。

海女美術大学はInkblot Art Academy。まあ海女は訳せないよな、訳しても意味ないし。Inkblotはインクのシミといった意味。

ただ完全にそのまんまな例もあり、たとえばManta Maria(マンタマリア号)。そのまんまでわかりやすいときはそのまんまにしてるようです。

デボン海洋博物館の裏設定?

こないだでてきたデボン海洋博物館ですが、英語版ではShellendorf Instituteとなっていました。Instituteは研究所、といったところなので博物館とはちょっとちがうけれどもそう遠からずですが、さてShellendorfとは?

とおもったら、なんとこれ、1で言及のあったブキチ(英語版Sheldon)のおじいちゃん、日本語版でいうカンブリヤ・ブキノサイの英語名がAmmoses Shellendorfなんだそうで。

するってーと、このおじいちゃんが設立した、といった裏設定があったりするのか? とか想像するのもちょっとおもしろい。それにしてもどうして英語版にだけこんな名前を採用してるんだろ。

そんなこんなで、ローカリゼーションにしても翻訳にしても、逐語的に訳してるわけじゃないんだよなー、まあいろいろがんばってんだな、とおもうなどしました。

Goのオプショナル引数

そういえば、Goには可変長引数でナントカオプションみたいなデータをわたす、というパターンがよくある。これってGoに特有のパターンだなとおもう。

とくに顕著な例として、たとえばgRPCがある。gRPC/Goには、たとえばDialOptionという型があって、gRPCサーバにつなぐときに、

conn, err := grpc.Dial(target, grpc.WithInsecure(), grpc.WithCompressor(grpc.NewGZIPCompressor()))

などのようにconnをカスタマイズするためにつかう。

DialOptionは型のなかみとしては関数になっていて、privateなdialOption型をうけとって何らかの処理をすることになっている。dialOptionは外からはみえないが実際にはただのstructで、いろんなオプション(たとえばSSLするかどうかとか、圧縮するかとか)をそれぞれフィールドとして持っている。個別のDialOptionはこれらのデータをセットする関数になっている。

func WithInsecure() DialOption {
  return func(o *dialOptions) {
    o.insecure = true
  }
}

といった具合。こういうデータを受け取る関数の側では、

func Dial(target string, opts ...DialOption) (ClientConn, error) {
  opt := defaultOptions()
  for _, o := range opts {
    opts(opt)
  }
  ...
}

といったふうに適用していく。

こういう “dialOptions” みたいなstructがほしいんだとすると、単純にその型をexposeしておいて、指定させておけばいいのではないか?とおもうかもしれない。つまり、

func Dial(target string, opt *DialOptions) (ClientConn, error) {
  ...
}

こんなかんじで定義しておいて、

conn, err := grpc.Dial(target, &grpc.DialOptions{})

こんなふうにつかうイメージ。

この手法と比較すると、可変長引数のオプションをつらねる方式の利点はいくつか考えられる。

  • そもそもオプションをとくに指定したくない場合には何もかかなくてもよい
  • デフォルト値をゼロ値と想定しなくてよい
  • それなりに記述的な表現ではある

いっぽう、欠点としては、

  • gRPCの例でもそうなんだけど、なんとかオプションみたいなものが多種類あるとあつかいがめんどうになりうる。おなじような意味で対応するDialOptionとServerOptionを指定したいときに関数名をかえないといけなかったりとか(がんばればできるかもしれないが、型が微妙にちがう場合などもありうるとすると限度がある)
  • 可変長引数としてつかえるのは一種類のデータだけなので、何種類も使えない

でもまあおもしろいイディオムだなーとおもう。Goのシンボル可視性、可変長引数の挙動、関数型の扱い、などが絶妙にくみあわさっているようにかんじる。

それにしても、おもしろいとおもうのにGo以外でぜんぜんみたことないパターンだよな、なぜだろうか……とつらつらかんがえてみたところ、なんのことはない、ほかの言語にはふつうにデフォルト値指定できるラベル引数があるからであった。どっちかというと言語レベルでラベル引数あればよかっただけで、いまはこういうパターンでしのいでいるとみるべきだろう。ガッカリおち。

本場の浮かれ電飾鑑賞2017

クリスマスのなんだか浮かれた電飾、いわゆる浮かれ電飾の本場といえば、やっぱりアメリカなのではないでしょうか。いや知らんけどイメージ的に。実際そのへんの家とかでもけっこうやってる浮かれ電飾ですが、なんらかの理由によりものすごくなってしまった電飾がつどった場所というのが、あちこちにちらほらあるという状況のようです。

たとえばサンカルロス市のとある通り。レッドウッドシティやサンマテオのちかくの、どちらかといえばちいさなパッとしない市ですが、なんだかすごいことに。おなじ場所に4年前にもいったのですが、ことしもいってみました。

Maker:S,Date:2017-9-18,Ver:6,Lens:Kan03,Act:Lar02,E-ve

Maker:S,Date:2017-9-18,Ver:6,Lens:Kan03,Act:Lar02,E-ve
この家、FAQの看板が立ってた。80万個ほどの電球をつかっているらしい
Maker:S,Date:2017-9-18,Ver:6,Lens:Kan03,Act:Lar02,E-ve
巨大ツリー健在
Maker:S,Date:2017-9-18,Ver:6,Lens:Kan03,Act:Lar02,E-ve
プロペラとかがくるくる回ってました
Maker:S,Date:2017-9-18,Ver:6,Lens:Kan03,Act:Lar02,E-ve
大量のキティさんたち
Maker:S,Date:2017-9-18,Ver:6,Lens:Kan03,Act:Lar02,E-ve
サンタ発着所

まあそんなこんなで、すげーあかるいし、とにかくこう、すごい。人通りもおおく、車での見物客もおおくて渋滞しているし、まあすごい。

ときどき住人とおぼしき人々もみえ、住人たちはどうおもってるのかな……でもみてもらったほうがいい気分なのかな……などとモヤモヤしたり、すごかったです。

4年前とくらべると、だいたいおなじようなかんじで踏襲されていますが、細々とアップデートがあるようにおもいました。これを維持しつつ更新していくの、たいへんそうだなあ。

このやつとかも4年まえとだいたいおなじ構成でありつつ追加要素がいっぱいあるかんじだしなー。

あと4年前とくらべると、カメラの性能が格段にあがり、夜のちょっと暗いところでもきれいにとれるようになりましたね。Pixel2よいですね。

GoでどれぐらいDIするか

https://recruit-tech.co.jp/blog/2017/12/11/go_dependency_injection/

この記事をみた。ここからは個人的な雑感だけど、結論からいえばGoではここまでのDIは必要ないことがおおいとおもう。

DIがなぜ必要なのかというと、テストをしたいからだ。しかもたいていはユニットテストだとおもう。UserServiceとUserRepositoryみたいなのがあったとして、UserServiceの挙動をテストするために、UserRepositoryがある特定のふるまいをしたときのことをテストしたい、みたいなやつ。

Goのばあい、ユニットテストは元のコードとおなじパッケージに存在していて、テストコードは内部構造もしっているし直接さわれる。だからこんなに頑張ってビルダをそとからわたさなくてもいいことがおおい。

具体的には、たとえば

package user

type Service struct {
  repo Repo
}

func NewService(opts... ServiceOptions) *Service {
  return &Service{repo: initRepo(opts...)}
}

みたいなservice.goファイルがあるとすると、service_test.goファイルでは、

package user

func TestService(t *testing.T) {
  s := &Service{repo: mockRepo}
  ...
}

などのようにNewServiceをつかわずに初期化していい。

もちろんこのとき、初期化関数(NewServiceなど)じたいのテストができないという難点がある。でもこうした初期化関数はほんとうにインスタンスをつくるだけのような自明なものにすれば、テストする必要性はそれほどない。

もちろん、ほかにいろんなパターンがあるので、DIする必要がまったくないということはない。たとえば、インテグレーションテストの環境のために外部サービスをきりかえる、ということはある。ほんとうは外部のストレージサービスに接続するが、テスト用にはオンメモリな実装をつくって、テストデータでうごかしたいときとか。そういうばあいには、インタフェースをパラメータとしてうけとるような構造をつくってDIすることにはなるとおもう(ただ、ビルダが必要になるかはわからない。インスタンスをつくって渡すのでいいんじゃないかなあ)。ほかにも実際の実装モジュールがいろいろあって設定できりかえたいとか、DIしたいパターンはおおいとはおもう。

とはいえ、そのようにきりわけられるべきレイヤはそこまで大量にはならないので、こういうJavaみたいな壮大なDIフレームワークがほしいことは、あまりないんじゃないか。ふつうにmainでわたすとか、カスタマイズしたいときだけオプショナルなパラメータを指定するとか、そういうのであまりこまらないと、個人的にはおもう。といった雑感です。

豆腐づくり

料理ネタ。にがりと大豆があれば豆腐は作れるらしい、という話をきいて、つくってみた。

比較的簡易なのは、いわゆる寄せ豆腐(汲み取り豆腐)というやつで、これは雑に言うと、

  1. 豆乳をあたためる(75-80℃程度)
  2. にがりをまぜ、少しだけ撹拌する
  3. 20-30分ほど放置してから、布巾をしたザルの上にあげ、水分とにがりが流れ出るのを待つ

というだけでできる。にがりは日本食スーパーで入手できる……という話だったが、Marukaiになかったので、アマゾンから購入した。

IMG_20170917_194233.jpg

これはスーパーで買ってきた豆乳で作ったもの。豆乳は成分無調整がよいとされるが、成分調整って砂糖とかで甘くしているだけという話らしいので、成分調整豆乳でもできるとは思う(味は変になるかもだけど)。

次は豆からに挑戦、ということで、大豆から作る場合は、まず豆乳を作ってから上の行程を経ることになる。

IMG_20170924_013457.jpg

大豆。中国語では黄豆というらしい。これを水につけて一晩とかおく。水を吸ってふくらむ。ふくらんだら水と大豆をあわせ、ミキサーで粉砕。

IMG_20170924_192142.jpg

これは粉砕後。大豆はサポニンが豊富なのでめちゃくちゃ泡だらけになる。これを火にかけて加熱。沸騰後弱火で10分とか。で、熱々のところを布巾にとり、がんばって絞る。とっても熱い。なんでこんなことやってるのかなと思う。

IMG_20170924_194306.jpg

しぼった豆乳は少し冷まして、75-80℃程度になるまでふたたび加熱。

IMG_20170924_200953.jpg

にがりをいれて放置。

IMG_20170924_201010.jpg

IMG_20170924_204417.jpg

放置のあと、布巾にふたたび汲み取り。

IMG_20170924_214032.jpg

できました。これはちょっとにがりが残っていてあまりうまくなかった。

豆乳をしぼる行程がひたすらめんどう&熱いなど難点があり、ぶっちゃけ買ってきた豆乳でもいいのではないか、という疑念は拭えないものの、科学実験ぽくてそれなりにおもしろさがあります。味はよいです。しかし買ってくる場合とのコスパを考えると……や、考えたら負けか。ベイエリアはサンノゼ豆腐など地元の豆腐屋があるので、買ってくる豆腐には事欠かないのでした。

そういうわけで豆腐でした。

Googleに入社して10年たった

2007年10月1日に入社したので、10年が経過したことになる。10年! ずいぶんな長さだなあ。すっかりグーグラーとして慣れてしまったような気がする。渋谷ではたらいていたころ、まさか自分がシリコンバレーに移住するとは微塵も思ってもいなかった。

それなりにいろんなチームでの仕事もしてきた。はじめはモバイル検索のことをやってて(モバイルといってもフィーチャーフォン向けの検索ですが)、Google日本語入力、ChromeOS。一瞬のAndroid業を経て、いまはクラウド。

ひとくちにグーグルといってもそれぞれ仕事の内容や扱うテクノロジは違っていて、検索のころはmapreduceを書いてデータパイプラインをうんぬんしていたりウェブページや自然言語を相手にしていたわけだし、Google日本語入力は多少の自然言語処理と動作プラットフォームの知識、ChromeOSのころはおもにUIでウィンドウマネージャやウィンドウシステムやモダンなGUIシステムの話になったし、クラウドではAPIとかサービス管理。むだにいろんなことをやってる。

いろいろやってきたけど個別の成果は大したことなくて、まあたいして出世もしていないけれど、いちおう今のところなんとかかんとか生き延びている。

2012年9月にアメリカに移住してきたので、そこからすでに5年。ていうかグーグルの東京オフィスでの勤務期間よりアメリカのほうが長かったりして、これもあまり実感もないものだ。英語がうまくなった実感もまったくないな……。

そういえばメインの仕事がオープンソースになって久しい。ChromeもOSSプライマリだし、今のプロジェクトもgithubで仕事してる。数えてみれば、自分のグーグル内キャリアのうち半分以上はオープンソースで給料をもらっているわけで、自分がそういう立場になりえるとは学生時代とかは思ってもみなかったなと感慨にふける。これはもちろん時代の変化もある。いまどき、企業が自社の製品や成果の一部をOSSとしてリリースするなんて、ふつうのことだし。

まあ一種の記念カキコなのでオチとかはないですが、そんなかんじでぼちぼちやっております。

GoとBazel

最近、メインの仕事ではGoで書かれたサーバをいじっていて、ビルドするのにBazelを使っている。使っているとBazelなかなかいいやつだな、と好感を持つのだけど、でもGoの場合、標準ツールとの相性というのがなあ、という微妙さもある。

その辺の個人的な雑感です。

Bazelとは

Googleが公開しているオープンソースのビルドシステム。もともと社内に存在していたビルドシステムのオープンソース版という位置づけ。社内版と何がどう違うのかはよく知らない。BUILDという名前のファイルにビルドレシピを書く。構文はそこそこ簡潔で、わりと宣言的に書ける。ちなみに構文はPythonのサブセットなのだけど、Bazel自体はJavaで書かれている。なぜ……いやまあそれはべつにいい。

社内版ビルドシステムと構文が同じなので、社内版プロダクトがわりとそのまま(もしくは構文解析後のノードの簡単な書き換えによって)オープンソース化できる、とか、両者の行き来が楽になってうれしい、といったあたりがオープンソース化した存在意義かと思われる。

Bazelはサーバプロセスとコマンドラインツールに分かれていて、サーバプロセスは適宜自動的に起動され、依存グラフの情報などを保存してくれる構成になっている。サーバからはイベントデータが取ってこれて、これをフックして各種のバックエンド拡張を行えているんじゃないかなとおもう。Bazelそれ自体には、グーグルの巨大な社内レポジトリを扱うほどの機能はビルトインされていないと思うけれど、そうやって社内依存度の高い部分は切り離す設計になっているとおもわれる。

GoでBazelを使う意味

ところで、Goは標準のツールチェインがよくできていて、ビルドとかの面倒を見てくれる。go getとかgo buildとかすればいいわけで、なぜBazelを使うのか?というのはあまり自明ではない。実際、チームのみんなもBazelが好きだから使いたいというのでもなく、実際には必要だから使っている、といったところではないかと思う。

WORKSPACEと依存関係の固定

Bazelにはワークスペースという概念があって、このワークスペースに依存する外部ライブラリのレポジトリを指定できる。Bazelはビルドレシピを解析して、依存する先が外部ライブラリになっていると、当該のgitレポジトリを自分でpullしてリビジョンを維持してくれる。リビジョンを指定しておけばそのリビジョンに固定される。

ビルドシステムが外部の依存ライブラリのリビジョンも管理している、というのは一見するとちょっとキモい構造なのだけど、いい面もある。というのは、新しいリビジョンへの同期などがビルドの作業の途中の、依存性として表現されるからだ。ようは、誰かがワークスペースを編集したり、あるいは自分のローカルな作業ブランチの一部が古いワークスペースになっていても、開発者はあまり気にせず、bazel buildするだけで勝手に現在の環境に更新しつつビルドしてくれて、問題が顕在化しない。

実際、repoやgclientを使っていると、git bisectがそこそこ手間なのだけど、ビルドプロセスと外部依存ライブラリの管理が統合されていると、そこの手間が全然ない。

Goの場合、いまはvendorディレクトリもあるし、godepみたいなツールもある。でもまあ、なんだかんだでビルドプロセスと一緒になっているのは便利だなと思う。

ちなみにbazelの場合は外部ライブラリにもBUILDファイルが必要になるので、下手をするとぜんぶ手書きする必要があるのだが、bazel用にgazelleというツールがあって、Goプログラムを解析してBUILDファイルを自動生成してくれるので、ふつうはそういう手間は存在しない。

コード生成

Bazelは一般的なビルドツールなので、Go以外のコンパイルもできるし、コード生成もできる。仕事のプロダクトではProtocol Buffers / gRPCを多用しているので、そういうコード生成が大量発生しているし、自前のコード生成ツールも使ったりしている。

Goでコード生成というとgo generateコマンドがあるのだけど、このコマンドはさすがにちょっとシンプルすぎると思う。というか、用途と想定されるワークフローが違うということだろうか。

go generateは自動的には動作しない。レポジトリには生成されたGoのファイルをチェックインすることが前提になっていて、開発者は必要に応じて手動でgo generateを走らせて再生成してチェックインしてね、という仕組みだ。なのでgo getなどは.goファイルだけを相手にすればいいし、コードジェネレータに対する依存関係とか、ややこしい問題が発生しない。

しかし正直に言って、ジェネレータが生成したコードとかチェックインしたくない。生成物に依存する入力ファイルや生成ツールの依存関係もわかっていることなので、どういうときにどのファイルを生成するか、というのはビルドプロセスの一部であってほしい。

Bazelはごくふつうの汎用ビルドツールなので、この辺は(ルールをちゃんと書けば)きちんとやってくれる。当たり前のことですがね……。とくにprotobufまわりのサポートは充実しているので、まあ、楽。

GoでBazelを使うと困るところ

そういうわけでなかなかいいのだけれど、困っている面もあって、具体的にいうと、ふつうのgoコマンドはまともに動かない。

わたしがかかわっているプロダクトは、最終的にバイナリをつくってdockerイメージとかを作るので、まあいいのかもしれない。でもこれがライブラリとか外部ツールだった場合、ふつうみんなはgo getしたら使える、というのを想定するだろう。go getだけじゃ動かない、なぜならコード生成が……とか言われたら、常識的にいって何らかの罵声が飛んでくることであろう。

それだけじゃない。いろんな外部ツールが、goコマンドの動作やその想定するgopath環境というものを前提につくられている。ようするにリントチェッカやコード書き換えツール(gofmt、gosimpleなど)が動かない。テスト、raceチェッカ、ベンチマーク、などは動くが、なぜかBazelのテストはコードカバレッジの情報を取得できないというバグがあるので、現状ではカバレッジを取りたかったらgo testする必要がある。

自分たちのプロジェクトでは、Bazelがとってきた依存ライブラリへのシンボリックリンクをvendorの下に展開するスクリプトがあるけれど、まあこんなのはハックであって、何もしなくてもうまいこと動いてくれたらいいのにな、とは思う。

まとめ

あくまでも雑感なので、とくに有意義な結論はないのだが、BazelとGoがうまくまとまるような、いい方法はないものかな、と思っている。

ひとつにはBazelがワークスペース(~/.cache下の領域)にGOPATHと同じような環境を構築できたら良いのかもしれない。そうすればもっと簡単にリントツールとか外部ツールを動かしたりできる。

ライブラリなどの用途を考えた場合とコード生成の成果物はチェックインしたくない、というのを両立させるには、コード生成等の処理を済ませたあとのソースコードを配布する場所がやっぱりあるとうれしい。CPANとかgemsとかnpmとか……いや、それならgopkg.inでいいのかも。ビルドツール側がコード生成やvendorディレクトリの作成、さらにはパッケージ参照なども書き換えた上で別ブランチにマージでき、そのブランチをgopkg.inか、あるいは別のURLから参照できるようにすればいいのかなと思う。kubernetesはそういうことをやってそうな気配がある。この辺はCI/CDまわりで頑張るべきか。

Goのツールチェインから歩み寄る方向性はあるだろうか? go buildやgo testにフックがあるといろいろ捗るだろうな、とは思う。ただ、どういうフックがどう設定できたらいいのか?go getとかでどういうフックがどう動くべきで、レポジトリにどう設定できるのか?とか、考え出すときりがない。

ローカルなワークスペースについては、vendorディレクトリが解決してくれた感はあるが、vendorディレクトリ以下の管理はそんなに自明ではない。godepが標準ツールと統合されたりするとうれしいだろうか?


なんだかんだ書いたが、BazelとGoはちゃんと動くような整備がかなり整っている方だと思う。cgoがあってもコンパイルできるし、go_proto_libraryとかは全然心配しなくていいし、カバレッジがとれないのは困るけどrace testingが動くのはうれしい。総じてなかなかよくできている。このへん見てるとyuguiさんが尽力した後が垣間見えて、お世話になってるなあと思ったりしている。