作者別: Jun Mukai

リック天文台にいった

サンノゼのそばの山にリック天文台という天文台があるらしい、予約すれば夜の天文台ツアーに参加できて天文台を見学したり星をみたりできるらしい、というのをききつけて行ってみた。夜のツアーはけっこうな予約難度のようだが(たとえば今年のぶんの予約はもう完売している)なんとか予約できた。

IMG_20180701_200924

リック天文台の場所はこのへん、サンノゼから山道を40分ほど走らせるとたどりつく山頂の天文台で、建設当時は世界最大の天文台であったらしい。むかしカリフォルニアにいたジェームズ・リックという大富豪(チョコレートのギラデリで有名)が私費をとうじてつくった天文台で、現在はUCサンタクルーズの管轄とのこと。ぼくが見学にいったときもUCサンタクルーズの学生の方が観測をしていた。

IMG_20180701_180553
天文台からの眺め。サンノゼとはちょっと思えない
IMG_20180701_181107
入ったらなぜかでかでかとグーグルが感謝されていたので記念に一枚。資金援助してたみたい

ツアー自体は、天文台のなかをみたり、観測している大学院生の人に話をきいたり、ジェームズ・リック氏の一生の話をきいたりしつつ、観測器でいくつか星をみさせてもらった。

MVIMG_20180701_190625

MVIMG_20180701_214703

リック天文台はかつては世界でも一二を争うぐらいの大きさの観測器を備えていたようだし、重要な研究施設としてそれなりに栄えていたらしい。ハッブルがいたこともあるとか、アインシュタインがいたこともあるとか。アポロ計画によって月に設置された反射器をつかったレーザー測距実験にも貢献したといっていた。いまはリモートから観測依頼もできるし、ほかにもいっぱい天文台があるからか、現地は閑散としている。とはいえ現役の天文台ではある。

歴史を感じさせる建物のかんじと先端的な施設が一体となっていておもしろかった。ツアーおすすめです。

IMG_20180701_223949
ジェームズ・リックの墓。かれの遺体はこの天文台に移され、いまもここにある。遺言によりつねに花が飾られているんだそうだ

英語メディアはgithubをどう紹介したか

マイクロソフトによるgithubを報じた日経新聞の記事のタイトルにおいて、githubのことを設計図共有サイトとよんでいて、開発者のみなさん総ツッコミ状態のようですね(現在は開発者向け共有サイトとなっている)。

個人的な感想としては、ソースコードを設計とみなすアナロジーはあって誤りであるとはいいがたいし読者層を念頭におけば気持ちはわかるものの、設計図共有サイトねぇ……という気持ちはないでもない。まあしかし、それ以上とくになにもいうことはない。

ただこれに対応して気になるのは、英語メディアではどのように紹介されてたのか、ってことだ。天下のマイクロソフトが$7.5Bもの額でユニコーン企業を買収となれば、一般紙でも紹介されるだろう。どんなふうに紹介してたんだろうか。

適当にgoogle newsで引っかかったテックメディアでない系の記事を眺めてみた。

Forbes。https://www.forbes.com/sites/amitchowdhry/2018/06/04/microsoft-monday-github-acquired-for-7-5-billion-xbox-one-x-discount-new-parental-controls/#54d32d046d98 という記事では、

GitHub is a leading software development platform where over 28 million developers share and collaborate.

と紹介している。「ソフトウェア開発プラットフォーム」といったところか。

WallStreetJournal https://www.wsj.com/articles/microsoft-to-acquire-github-for-7-5-billion-in-stock-1528118504?cx_testId=16&cx_testVariant=cx&cx_artPos=0&cx_tag=contextual&cx_navSource=newsReel#cxrecs_s

Microsoft Corp. agreed to buy coding-collaboration site GitHub Inc. for $7.5 billion in stock

coding-collaboration site。またこう訳しづらいなぁ。コーディングコラボレーション。ううーん。

New York Times https://www.nytimes.com/2018/06/04/technology/microsoft-github-cloud-computing.html

Microsoft, fully embracing a model it once saw as a threat, said on Monday that it was buying GitHub, an open software platform used by 28 million programmers, for $7.5 billion.

Open Software Platform。オープンソフトウェアプラットフォーム。英語でもわかるようなわからないような表現ですが、カタカナにしても一見アリでありつつ相当わけのわからない語になっている。ただこれぐらい煙に巻いたらいいのではないか、とも思ったりもします(記事内できちんと補足解説を入れる前提であれば)。

ほかにもあるかな。まあだいたいそのような感じです。けっこう各社それぞれですね。

さて、ふとした思いつきでgithubをincognitoで(つまりログインせずに)アクセスしてみたところ、

GitHub is a development platform inspired by the way you work.

と自己紹介していました。日本語では

GitHubは、ユーザのみなさんからヒントを得て作成された開発プラットフォームです。

となっていますね。この翻訳どうなのかな、っていう面はありますけど、開発者用のプラットフォームだという自己紹介になっています。

自己紹介がそうだから、っていうだけでもないですけお、そういった紹介のほうがよいのではないかなぁ、と思うのですよね。実際、githubはソースコードレポジトリ管理や共有がコアでありつつ、実際にはそれをとりまくプラットフォームであるわけだし、その意味で成功したサイトであるわけだし。「設計図共有」という表現のものたりなさは、そういう話でもあるのではないかなぁ。

モヤイ像の絵文字の話

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

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

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

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