読者です 読者をやめる 読者になる 読者になる

Anonymous Function

tmaesaka の lifelog | カルチャー、ときどきテクノロジー

ネタバレのない「シン・ゴジラ」の感想

少し出遅れて、シン・ゴジラMX4D で見てきました。とても面白かったです。大事なシーンで職場がやたら出てきてテンションが上がりました。

shin-godzilla

見終わってからレビューをいろいろ読んでみると、この作品には賛否両論があるようです。特に CG に対する突っ込みが目立ちます。庵野監督が狙ったのかは解りませんが、古き好き日本の特撮と現代の融合と考えると、むしろ独特の良い味が出ていて素晴らしいと自分は思いました。少なくとも英語に比べるとまったく気になりません。

そう、自分はどちらかというと英語の方が気になりました。石原さとみさんは多分、普段ならもっと綺麗に発音することが出来ると思うのですが、「英語で演技」という不慣れな無理ゲーによって、本来の能力が出せなかった感がありました。見ていて劇場版サイコパスを思い出しました。

庵野ワールド全開のシン・ゴジラは自信をもって人に勧めることができる良いエンターテイメントでした。MX4D は凄いけど疲れるので、次回は標準スクリーンで見ます。

Fastly Altitude 2016 参加録

Tech Travel

Altitude という、勤務先の Fastly が主催するカスタマーサミットに参加しました。

altitude

Altitude は端的にいうと、Fastly のお客さまやスタッフによる、エッジの未来やテクノロジーに関するコンテンツ満載のカンファレンスです。プロダクトの近況報告や今後のロードマップが紹介され、自分も最近まで担当していたプロジェクトのお披露目や、その啓蒙活動もかねてライトニングトークをしました。

サミットで個人的に一番楽しかったのは、Fastly ユーザたちによる実際の開発現場や運用まわりのトークでした。生々しい DDoS 体験談、VCL と IaC、VCL をそこまで使い倒すの?など、ひらすら感心しながら聞いていました。こういった話は日々の仕事の励みになるので、とてもありがたかったです。

サミットの 〆 は、CTO の @tbmcmullen による、現状の CDN モデルの限界と、それにどう挑戦するかといった未来感あふれる話でした。サミットの動画はいずれ公開されるので、その際は Twitter などでシェアできればと思います。

最近つかわなくなった英語、呼びかけ編

このブログ初の英語トピックのエントリです。実は英語は関係ない説。

some-programmer

昔は一般的だったのに、今では見なくなった表現というのは言語関係なく存在します。今回は自分が子どものころからカジュアルに使っていたのに、最近は使わなくなった英語の呼びかけ表現を紹介します。

性別は無意味

自分はグループに呼びかけるときに、"hey guys" や "hey fellas" などの言葉を使わないようにしています。性別という概念をコミュニケーションに持ち込みたくないからです。言葉狩り、と思うかもしれませんが、気にする女性は必ず一定数いて、そもそも性別という概念を不愉快に感じる人もいます。無用な情報が人に不愉快を与え得るのであれば、最初から含まなければ良い、というのが自分の考えです。多様性が認めらるべき現代への敬意でもあります。

必ずってわけではない

これは少なくとも職場での話で、プライベートなシーンでは例外がいくつもあると思います。まったく気にしない人たちもいます。とはいえ、職場で日常的にこういう思いやりを意識していれば、プライベートでの発言にも自然と反映されると思います。

npm 社の "Guys Jar"

Node.js のパッケージマネージャーを開発・メンテしている npm 社では、会社としてこの課題に取り組んでいることをブログで発表しています。超要約すると、"Guys jar" といって、"guys" という言葉が男女差別につながると信じているのに、たまたま "guys" という言葉を mixed-gender な場面で使ってしまったら、自分から $1 支払うという仕組みです。ジャーの中身が $50 に達するたびに、そのお金はチャリティーに寄付されます。

代わりに何を使うか

要は、性別や外見的特徴に触れなければ良いわけです。なので、シンプルに "hey, <用件>" だったり、"hey team" と自分は言っています。"hey engineers" のように、職種名でグループに呼びかけるのも良いですね。この応用で "hey friends" など、"hey <適切な名詞>" というパターンを使うと良いと思います。

思いやり

冒頭でも書いたように、このエントリの話って、実は英語は関係なくて、思いやりをもって人と接しようというシンプルな話でした。あるいは、余計なことを言わない。別に "hey guys" が悪いと言っているわけではありません。

全ての人間を不愉快にしないというのは、さすがに無理ですが、こういう思いやりを重ねることで、その可能性を少なくしていきたいと、最近考えるようになりました。

Dogpatch Boulders でボルダリングを再開しました

Travel Fitness

同僚たちとサンフランシスコの Dogpatch Boulders に行ってきました。このジムはアメリカ最大規模らしく、10 年以上のブランクがある自分には贅沢な再出発点でした。

dogpatch-boulders

シューズはあらかじめ REIファイブテンのモカシムを購入しました。決め手はスリップオンで楽なことと、初心者から上級者まで長年愛されている王道のシューズだからです。

ほんとに初心者向け?

まずは感覚を取り戻すために V0 と V1 の課題に挑戦しました。が、このジムのレベルはどこかおかしくて、V0 でも超ハードに感じました。さすがに久しぶりだったので、1 時間もしないうちに身体がギブアップしました。

有酸素運動と筋肉

休憩がてら見学していると、トレッドミルで走っている人たちや、筋肉ムキムキのお兄さんがトップレスでベンチプレスをしているなど、異様な光景が目に入りました。クライミングジムってこういうとこだっけ?とクライマーの同僚に聞いてみたところ、最近はどこもそんな感じらしいです。

ジムの雰囲気はとてもよく、いろんな人がフレンドリーに話しかけくれました。

運動すると腹が減る

運動後はすぐ近くの Smokestack で食事をしました。この店の趣向は古き良き雰囲気の中で、ビールを飲みながらマッケンチーズとブリスケットを楽しむことのようでした。残念ながらブリスケットは売り切れていたので、特製のパストラミをいただきました。店員が何度もオススメするだけあって、たしかにうまかった。途中からウィスキー好きの同僚の勧めで、飲み比べがはじまりました。自分は途中でリタイア。

whisky

今後も引き続き頑張る

とても良い感じにボルダリングを再開することができました。シューズを買ったことだし、ちゃんとコミットしないといけませんね。帰国してから APEXT-WALL に行きましたが、まだまだ先は長そうです。体重を落とさねば。

ターバンカレー本店で金沢カレーに目覚める

Food

前回の金沢旅行エントリの続きです。

kanazawa-curry

滞在最終日に家族の一人が「カレーが食べたい」と言い出したことから、老舗のターバンカレー本店に行ってきました。当時、金沢カレーというジャンルを知らなかった自分は、なんで金沢に来てまでカレーを食べるんだ?という疑問を抱いていました。いざ店に着くと、そこには行列が。これは何かあるなと期待が高まります。

turban-curry

生卵 (割り込み)

ロースカツカレーにオプションで「生卵 (割り込み)」を注文しました。割り込みってなんだろう?と妄想を膨らませながら待つこと 10 分弱、カレーが目の前に運ばれます。衝撃的でした。見たことのないドロドロで色の濃いカレー、ロースカツにはソースがかかっている、そして生卵は本当に割り込んでいる。味の方は辛さと甘さのバランスが絶妙 (少し辛め) で、そこに生卵を加えると新たな味わいが生まれます。そして、極めつきに、あえて少し薄切りでサクサクのロースカツ。たまらないですね。

美味しかったし、勉強にもなったし、良い体験ができました。義弟よありがとう。

近江町市場で生牡蠣を立ち食い

Travel Food

少し前に家族と北陸新幹線で金沢旅行にいってきました。

kanazawa-oyster

金沢駅に着いてからレンタカーを借り、その足で近江町市場に向かいました。金沢の台所と呼ばれるだけあって、日本海の魚介類や加賀野菜などの専門店がひたすら並んでいました。場内は活気があり、歩いていると店頭で牡蠣が食べられるお店をいくつか発見しました。自分たちが訪れた店は牡蠣 1 杯 850 円と、なかなか強気な価格設定でしたが、旅行中だしまあいいやと納得しました。期待通りのプリプリでジューシーな味わいでした。

念願のノドグロ

近江町市場ではないですが、滞在中にのどぐろの姿焼きも食べました。味は言語化するのがむずかしい、噂どおりの美味でした。なるほど、これが高級魚か。

nodoguro

金沢には食だけでなく、心地の良い大人の空気があって、また行こうと思いました。次回は行きそびれた 21 世紀美術館や、Jazz Spot 穆然に行こう。

関連リンク

Microservices Casual Talks で話してきました

Startup Tech

株式会社オライリー・ジャパン主催の「マイクロサービスアーキテクチャ」出版記念イベントで数年ぶりに人前で話してきました。

travis-luna

制限時間 20 分で Microservices を語るのは厳しいと判断し、自分のトークは開発現場でありがちな面白い話や、Microservices の難しさなどのトピックに絞りました。

どの帽子をかぶるべきか

Microservices を人前で語るときは、どの帽子をかぶるべきかで悩みます。

ひとりのエンジニアとしては、必要がなくても Microservices アーキテクチャに手を出したくなります。自宅で無駄に巨大なファイルシステムを構築して、ニヤニヤするのと似た感覚ですね。対して、例えば幼いプロダクトを育てている立場だと、手間のかかる Microservices アーキテクチャに否定的になるでしょう。

今日の正解は明日の不正解

テクノロジー業界は動きが速く、システムというものは状況の変化に弱いものです。例えば、ひとつの大きな案件によって設計の前提が変わってしまうという話は、テック業界ではよくあることです。エンジニアが心底嫌うやつですね。プロダクトがうまくいっていると、必ずこういう状況に遭遇します。したがって、過去の選択を後悔せず、常に頭を柔軟にしながら、前に進むのが大事という話をしました。

流行るものは流行る

Microservices アーキテクチャを採用したからといって、プロダクトは流行りません。まずは頑丈なユーザベースを築き、成長軌道に乗ることが最優先です。そういったステージでは、モノリシックな設計のほうが圧倒的に合理的です。ステージによって、そのとき最良と考えられる手を選びながら前進しましょう。

最初から 100 万人を快適にサーブできるシステム開発に尽力しても、そこに到達するよりも先にチームが解散する可能性の方が高い、という論点に似ていますね。

キラキラネーム現象

Microservice は API が公開されるだけであって、プロジェクト名やリポジトリ名が外部に露出することがありません (たまにエラー出力で漏れてる会社もあるけど)。したがって、エンジニアやアーキテクト間の利便性のために、よくコードネームが Microservice につけられます。自分の観測範囲内だと、コードネームは作者やチームの趣味で、面白い名前がよくつけられています。

Fastly の場合、創業者がスキー好きなので、初期から存在する Microservices には、スキーリゾートの名前がつけられています。最近はいろいろです。

モニタリングの重要性

Microservices アーキテクチャは動くパーツが多いので、モニタリングが極めて重要です。James LewisMartin Fowler を引用しつつ、Datadog や New Relic などの紹介をしました。Fastly では迅速に障害に対応するために、社内でもいろんなモニタリングが実装されています。

開発環境

とてもディープなトピックです。プログラマの日常的な視点から考えると、ある瞬間の興味対象の Microservice って、担当プロジェクトに関連するひとつやふたつだけではないでしょうか。とはいえ、依存している Microservice (たとえば監査サービスなど) があると、動作確認ができなくて困ります。したがって、良い感じに自動で開発環境が構築される仕組みがあると生産的という話をしました。

Fastly では、エンジニアはほとんど Mac を使っていて (一部 Linux)、仮想マシン上に複数の LXC が立ち上がっている環境で開発しています。各 LXC がサービスを表すノードということになります。この開発環境は専門のチームがメンテしてくれていて、困ったことがあるとチャットで助けてくれます。

レジリエンスのテスト

プログラマからすると、ある Microservice がどこで動いているかは本来どうでもいいことです。同じホスト内、別ホスト、別 IDC などです。しかも、Microservices アーキテクチャは動いているパーツが多かったりなどで、外部要因 (物理障害など) による影響を受けやすいアーキテクチャです。

上記の理由から、Microservices アーキテクチャでは、レジリエンス (回復力) のテストが極めて重要になってきます。レジリエンスのテスト手法として、Shopify が公開している toxiproxy という簡易的に厳しいネットワーク環境をエミュレートできる仕組みや、NetflixChaos MonkeyChaos Kong といった常識はずれのテスト手法を紹介しました。

Fastly の Polyglot な環境

以前このブログで紹介したように、Fastly ではいろんなプログラミング言語を活用して全体的なシステムを構築しています。結論からいうと、狙ってそうなったのではなく、必然的に複数の言語が活用される環境になったのではないかと自分は考えています。

Fastly は課題に合わせて適切な言語とテクノロジーを活用しています。たとえばスループットが死活問題なリアルタイム処理などの課題に、表現力が豊かなものの、計算速度に難のある言語を選択するメリットはありません。逆に、文字列操作や、テンプレートエンジンを使い倒すウェブ系のプロジェクトには、スクリプト言語の方が理にかなっています。健全な Microservices の成り立ちと、あり方ではないかと思います。

大事なこと

Microservices という言葉をよく耳にするようになったものの、結局はアーキテクチャのひとつです。万能なアーキテクチャは存在せず、誤った選択は逆に技術者の生産性や幸せ度を低下します。Microservices も例外ではありません。大事なことは、自分や仲間にとってのメリットを冷静に考えて、合理的な選択をすることではないでしょうか。

Microservices Casual Talks はソフトウェア開発のむずかしさや、奥の深さを再確認できた良いイベントでした。これを機にもっとイベントに顔を出していければと思います。

関連リンク