この時期、業務で低パフォーマンスを出し続ける覚悟
今この時期、もちろん弊社もCOVID-19関連の事情を鑑みてテレワーク……とはあんまり自分の回りでは言わない、リモートワーク(もっと言うとWFH: Work From Home)してる。自分が完全WFHに切り替えたのは1月半ばくらいだったかなー。もう3ヶ月ですね。
で、どうかというと、業務のパフォーマンスで見ると、自分のいまのパフォーマンスは明らかに悪い。少なくとも良くはない。それは自分でもわかってる。
でももう、これはしょうがない、と思うので、覚悟している。高パフォーマンス出せたらいいとは思うけど、同時にどう考えても無理して仕事で高パフォーマンス出すような時期でもないと思う。
だからこのエントリは、まあしょうがないよね、というのを受け入れよう、という話です。*1
なおこのエントリは業種柄、リモートワークに移行しやすい自分の話しかしていません。生活必需品や医療品関連の小売店舗や病院、窓口が必要な店舗や役所、流通関連など、その他さまざまな職種の現場でいま現在も社会を支えてくださる方々には本当に感謝しかありません。ありがとうございます。
普段の話
COVID-19以前の弊社はといえば、基本的にはオフィスに行って仕事をしましょう、というのがルールだった。うちのチームのマネージャーはユルいんでいつWFHしても全く問題ないんだけど、まあ全体的にはそう。
で、自分も性格的にオフィスで仕事する方が気持ちの切り替えができて好きなので、通常は普通にオフィスに出勤して、仕事して、帰るという感じだった。自宅でコード書くときはラップトップのディスプレイとキーボードでもまあ別にいいや、という感じ。
一方ミーティングとかは、同僚がそもそも世界中に広がってることもあって常にZoomだったので、そこは基本的に変わってない。オフィス内でも同僚と会話するけど、それは運良くその仕事に関わっている同僚が同じオフィスにいればであって、いなければZoomで話すことになる。
いっしょのタスクをやっている同僚がバンクーバー在住の人になることが多かったので、そういう人達とは定期的にZoomで話す時間を作ったりしていた。
自宅の仕事環境の話
元々オフィスで仕事する前提でいたから、自宅に腰を落ち着けて仕事する環境がなにもない。外部ディスプレイや外付けキーボードすらなかった*2。場所もいまはダイニングテーブルを主に使ってるけど、自宅がそもそも生活のことだけ考えてたから個室がなくて、家族の生活とモロに筒抜け状態になってたりする。
なんでそんな環境なのと言われると、単に自宅にその必要を感じてなかったから、以外には何も理由がない。
で、これはもちろん効率が悪い。コードを書くときに集中するのも難しいし、Zoomで会議やるにも家族への配慮がいるし、雑談したいからZoom繋ぎっぱなし、みたいなのもほとんど不可能*3。お昼ごはんのたびにディスプレイやラップトップをどかしたりするのも地味にめんどい。
そもそもZoomで繋ぐこと自体が自宅全体へのストレスになる*4というのはちょっと発見だった。これ、同僚と常に話してるみたいなマネージャー陣は大変だろうな。
社会環境の話
もちろん、COVID-19まわりの情報も気になる。Twitterのタイムラインは荒れ気味だし、Facebookでもあれこれ声高に言う人もいるし*5、TVは……まあほとんど点けないけど。ゲームとかNetflixにしか使ってないな。
で、そういうあれこれに気が散る。政治の話もあるし、海外の状況も(特に同僚が多くいる国や地域の話は)気になる。あれこれ。これも集中を失わせる大きな要因になっている。
生活習慣の話
普段自分は休日にわりと外での活動でストレス発散することが多い。サイクリング、ドライブ、キャンプ、スキー、本屋めぐり、美術館や博物館、あれやこれや。全部できなくなった。
最近はだから自宅でゲームやって、あとは電子書籍やらAmazon経由で買った本やらを読むんだけど、もちろん普段のストレス発散方法がとれないのは大きい。平日の活動にも影響を与えていると思う。
最近の意識的な活動の話
とにかく休憩を頻繁に取ろうとする、昼休憩をだいぶ長めにとる、ようにはしている。夕方も、とにかく早目に仕事を切り上げるようにはしている。
あと水分補給をすぐ忘れるので、常に湯冷ましを手元に置くようにしている。日に1リットルくらいは飲んでるけど、もうちょっと多めにしたいなあ。難しい。
最近会社が会計年度の切り替わりをズラしたりみたいなのの副作用で手持ちの有給休暇残日数がかなりあるので、これを、意識してとろうかなと思っている。今週も火曜は意味もなく休みにしてのんびりしてた。これも馬鹿にならない効果があるなと思ったところ。継続的に週の真ん中の休みを入れていこうかなと思っている。
仕事以外にやっていた活動はほぼ全滅気味。やばい。関係者の方にはマジで申し訳もない、が、今のところどうしようもない。生活ペースをもうちょっとちゃんと組み立てられればなんとかなるかもしれないが、ならないかもしれない。
結論
というわけで、短い時間を集中しにくい環境で働いていて、パフォーマンスがいいわけがない。これはもうしょうがないな、と受け入れることにした。
会社側の評価どうなるとかいう話もなくはないだろう*6けど、それとは関係なく「低パフォーマンスしか出せない自分へのストレス」みたいなものがあって、これを直視できないうちは、そのストレスが雪だるま式にふくれてる気がした。2月〜3月中旬くらい、だいぶそういうストレスを感じていた気がする。
これはたぶん本質的に危険で、どうにかしたほうがいい。とはいえストレス解消のためのアクティビティも軒並み封じられているから、何か方法を考える必要がある。
自分はそのストレスを、直視して、無視することにした。無視するといっても心の中で思っているだけだと徹底できない部分もあるから、こうやって文章にして明示することにしてみた、というのがこのエントリでした。
うん、大変だけど、とにかく健康は大事。ウィルスのせいで肉体的な健康も危険だが、とはいえ、いやだからこそ、メンタルの健康も大事だと思う。大事にしていきたい。
*1:なおうちのチームのマネージャーは、常に健康第一、休憩をもっと頻繁に長くとれ、パフォーマンスとかよりそっちの方がはるかに優先だ、と毎週の1on1で常に言ってます
*2:これは最近オフィスのを送ってもらったが、特定の置き場所がないので使うたびに上げたり下げたりしている。めんどい。
*3:Zoom飲み会も、だからちょっと配慮というか心構えが必要になってしまう
*4:安心して生活音を立てられる、という状況がちょっとでも失われるのはストレスなんだなあ、と今回初めて実感した
*5:今回の情勢でこれはちょっとという人のフォローを外したりもした
*6:自分は弊社について、この状況下でのパフォーマンスを理由に理不尽なことをしないだろうと信頼しているけれど、まあそれはそれ
TokyuRuby会議13に行ってLTやって飯王を(また)とった
今年もまた行われたTokyuRuby会議に、先日のRubyKaigiでLTやったMaccroのネタをまた持って参加してきた。
TokyuRuby会議13 - Regional RubyKaigi
が、Maccroは進捗があまりなく、どっちかというと今回もサントリーさんのスポンサーによるビール飲み放題があるので、それにあわせてガッと食べられる食べ物を持っていったのが結果的にメインになってしまった感。
なんにせよ大変楽しいイベントでした。運営のみなさん、会場提供のSpeeeさん、ビール飲み放題のサントリーさん、ありがとうございました。
食べ物のはなし
去年は渾身の一品で狙いに狙って飯王をゲットしたのもあって、今年は少し前まではまあ頑張らなくていいかなーと正直思っていたんだけど、いろいろあって結構な額のふるさとアレをアレした結果、最近慢性的に冷凍庫が肉等で溢れる事態となっていた。
これがマジで困るので、しょうがないからそのキロ単位の肉塊をいくつか投入しておいしくして持っていけばいいのでは? というアイデアが降臨する。しかもAsakusa.rbの花見を切っ掛けにイノベーションのアイデアが降臨したのでそれも投入。結果として、単品飯王をぶっちぎりでいただき、かつ(他の2品もあって)合算飯王までゲットしてしまった。完全勝利だ。
ほかほか焼売をデプロイしました #tqrk13 pic.twitter.com/np0L3zcpeo
— tagomoris (@tagomoris) June 29, 2019
#asakusarb 花見の知見を活用し化学の力で火器が使えなくても蒸し料理を提供するモリスさん #tqrk13 pic.twitter.com/iXT4tfEavf
— ジョーカー 参戦！！ (@joker1007) June 29, 2019
豚しゃぶ！ #tqrk13 pic.twitter.com/UVWksgWwST
— tagomoris (@tagomoris) June 29, 2019
手羽先やわらか煮！ #tqrk13 pic.twitter.com/5ZUizX6E90
— tagomoris (@tagomoris) June 29, 2019
特に焼売は超ウケがよくて、ほかほかと湯気を上げてサーブしていたらサントリーさんのスタッフの方が「おなかがすいてきたんですが……」といらしたので、人数ぶん持っていってもらったりしてた。いつも座ってたらビールが運ばれてくるのだが、これで多少でもお返しができただろうか。
焼売はもちろん現地で蒸し上げたわけではなくて、実際には自宅で蒸したあと現地では蒸すことでほかほかに加熱する、というくらい。ただそれで十分おいしいくらいに温かくなった、はず、というかいま気付いたが俺は当日現地でひとつも食べていない!!!!!!!!!!!!!!!!!!!!!!!!
会場で電源を使わず*1に食べ物を温める方法に関しての今回のイノベーションは携帯おかん器だ。これはAsakusa.rbの花見で野外・火気禁止の公園においていかに日本酒を温めるかという議論の中で発見されたもので、実際に花見で役立ったんだけど、そのときに「これは食品も温められるのでは?」と思い付いてからはTokyuまでは黙ってたｗ
さすがに直接的な火力がそこまでないのでどう使うかな、という方向からそれに向く料理として焼売を選択したのが実際のところで、あとは冷凍庫に大量にあった鶏肉を見て鶏肉焼売にすることにした、という感じ。おいしくできてよかったよかった。
ほかに豚しゃぶ肉が3kgあったのでそのうち2kgを雑に豚しゃぶにした。冷凍庫が空いて助かりました。
あと手羽先は当日朝に存在に冷凍庫内の存在に気付き、これくらいで美味くなるやろ、という感じの適当な調味料といっしょに圧力鍋で煮込んだ。割とおいしくできてて本当によかったよ……。
*1:みんな使いはじめると会場の電力供給が保たないから禁じ手
高負荷システムでNVMeデバイス使用時のfstrimとdiscard mount optionの話
先にまとめると
- ディスクI/Oに高い負荷をかけるシステムでNVMeデバイスを使うときweekly cron jobでfstrimが走る状況になってたら停止しろ
- じゃないとfstrimが走った瞬間にI/Oパフォーマンスが刺さって死ぬ
- fstrimを停止するならdiscard mount optionを有効化しろ、ただしその状態でのI/O性能で問題ないかどうか測っておけ
- discard mount optionを有効化しても大きいファイルの削除には気をつけろ、プチfstrimみたいになるぞ
- 追記されるばかりで大きくなるファイル(そして削除されるファイル)はNVMeじゃないデバイスに置いとけ
高I/Oスループットを期待するシステムでのNVMeとfstrim
社内で小さめのインスタンスを多く並べてトラフィックを捌いてたのを色々要件があって大きめのインスタンスにまとめるようなシステムアップデートをやってたんだけど、ローカルファイルシステムに大量の小さいファイルを書く構造をとって、そこを高I/OパフォーマンスなデバイスつまりNVMeを使うことで全体の性能を上げる、みたいな構成にした。
ベンチマークをとってもだいぶ良い感じだったのであれこれ試してから万全の体制……のつもりで本番投入したところ、見事に刺さった。突然ストレージのI/Oパフォーマンスが劇的に下がって全プロセスがスタックするというトラブルが、しかも複数のAWSリージョンでなぜか同時*1に起きた。初回は混乱したままインスタンス増加や入れ替えなどを行って原因がわからねーなーと思ってたんだけど、どうも見てると毎週同じ曜日の同じ時刻に発生している。なんだこれは。
で、調べてみたらこの時刻は weekly crontab のジョブが実行されるよう /etc/crontab が設定されていて*2、 このタスクのひとつとして /etc/cron.weekly/fstrim というやつがあって、これが実行開始されたあとストレージI/Oのパフォーマンスが劇的に悪化するという現象が確認できた。
fstrimがなんなのか大雑把に言うと、SSDやNVMeはデバイス側で使用中のブロックを管理しているが、ファイルシステムは普通ファイル削除時にはファイルシステムのメタデータを削除するだけなので、デバイス側の使用中ブロック情報との間で齟齬が生まれる。fstrimコマンドはこれを解消するために、使用しなくなったブロックをデバイスに通知するためのTRIM命令をまとめて発行するコマンドだ、と自分は理解している。あとは他の解説とかを読んでくれ。例えばAWSのドキュメント "インスタンスストアボリュームの TRIM のサポート"にもこのあたりのことが書いてあって、fstrimを当たり前に使え、となっている。 で、I/O負荷がそう高くない普通の*3システムであれば、ヒマなときにやっとけばいいだろうということで、日曜早朝*4に実行するというcron jobの設定が行われていたのだった。
しかし自分の手元のこのシステムにおいては、ものすごい勢いでファイルを作っては削除してを繰り返す。そのパフォーマンスを担保するためにNVMeデバイスを使ってるんだから当然とも言える。そして大量にファイルが削除されているということはTRIMされるブロックもものすごい量に及ぶため、fstrimを実行した瞬間に大量のTRIMオペレーションが実行されて該当デバイスおよびファイルシステムのI/Oレイテンシが激増、システム全体が死亡するという状況になっていた。 ステージングなどの環境で気付けなかったのは、fstrimによるパフォーマンスの低下はブロックデバイスへの書き込み量に顕著に依存する、ということによる。本番環境のようなトラフィックが無い環境ではfstrimによる影響が軽微な範囲で収まってしまい、気付くのが困難だったためだ。
ということで、ファイルシステムでの高スループットI/Oを期待したシステムでfstrimが起動し、その瞬間I/Oパフォーマンスが劇的に低下して無事死亡することになっていた。これ、普通に他所でも起きるんじゃないのかなあ。AWSでNVMeのあるインスタンス使う人って高いI/O性能を期待する人が多いんだろうから、ドキュメントがfstrim実行しろってのは大丈夫なのかと思うけど。
discard mount optionの有効化と次なるI/O性能低下
ところでfstrimについて調べると出てくるドキュメントにはdiscardというmount optionについての記述が出てくる。これはファイルを削除したときにすぐにTRIMオペレーションをブロックデバイスに対して発行するためのもので、当然だがデバイスへの命令が増えるということは、全体のI/Oスループットはいくらか下がる。このためか、例えばRHEL8のドキュメントなどを見ると、避けられない場合を除いてはfstrimによるバッチ処理を推奨している……が、正直これもどうなんだと思う。 一般的にコンピュータシステムの性能をコントロールしやすいのは、時々やってくる高負荷のスパイクよりも、圧倒的に、普段の平均的に少し低い性能のほうだ。予測もコントロールもしやすい。しかもfstrimによる負荷はどのくらいファイルが削除されたか、という極めて変動しやすい要素に依存しているため、事前に予期するのは不可能といっていいと思うんだけど。
ということで、普通にNVMeデバイスを使用するシステムを運用するなら、discard mount optionは有効にするべきだと思う。ので、してみた。もちろんdiscard mount optionによるI/Oスループットの低下には注意する必要がある。各種メトリクスを監視しつつ、本番トラフィックからいつでも外せるようにして注意深くやってみた。 が、また変なことが起きた。全体の性能は問題ないものの、今度は毎時で小さいスパイクが発生するようになってしまった。fstrimによるほど致命的ではないが、本番トラフィックに晒しておくにはちょっとマズい感じのやつ。
これがなんなのかと悩んでみたんだけど、発生時間を手がかりに調べてたら、わかった。crontabによるhourly cronの起動時刻で、何が起きていたかというとlogrotateだった。いやー、まさかねー、って感じだったよ。
discard有効ボリュームにおけるアクセスログのrotate
まさか現代のマシンでlogrotateの負荷が問題になるか? と思ってしばらく自分も混乱していた。はるかな大昔はサーバのCPUコア数も少なく、その少ないコアがlogrotate時のgzip圧縮で持っていかれて全体のパフォーマンスが低下する、みたいなことを経験したことがある。そんなことが現代でまた起きるか? みたいな感じ。
まさか現代のマシンにおいてlogrotateの負荷を気にする日がまた来ようとは
— tagomoris (@tagomoris) June 7, 2019
実情として、このサーバ(で動いてるnginx)が処理してるトラフィックはそれなりにあるので、アクセスログについてはローカルストレージでの保存期間はとらず、hourlyでlogrotateにかけ、また保存世代数はゼロにしてある*5。これでも毎時40GBくらいの量にはなっている。
で、logrotateがこのアクセスログをrotateするということは、つまり、40GBぶんのブロックに対して一気にTRIMを実行する、ということだったのです。discard mount optionが有効の場合は。これに気付いたときは割とがっくりきた。discard mount optionを有効化することでBatch TRIMから逃げられたと思っていたのに、アクセスログのせいでMicro Batch TRIMとでも言うべきものが起きていたのだった。 これが即座に原因だと断定できなかったんだけど、その理由はファイル削除のタイミングとI/Oパフォーマンスの低下のタイミングが微妙にズレることがあるせいだった。これはTRIMオペレーションが実際に実行されるのは非同期化されており、ファイルの削除から少しのタイムラグがあるケースがあるためのようだった。
さてこれが分かれば結論は簡単で、アクセスログをNVMeじゃないデバイスに置いてやればいい。TRIMオペレーションが必要なければこの問題は起きない。問題のインスタンスにアクセスログ用の領域を確保したEBSボリュームをアタッチして、そこにログを書くよう変更してやった。解決!*6
まとめ
NVMeデバイスは高I/Oスループットを発揮できて便利だが、安定したスループットを期待したいのならdiscard mount optionを有効にして運用しよう。またそのデバイス上での巨大なファイルの削除は避けるべきで、そのような例としてはアクセスログなどがある。気をつけよう。
*1:日曜午後3時45分過ぎ
*2:なお全インスタンスのタイムゾーンはUTCにセットされているため、使用中の全リージョンで同一のタイミングでこのジョブが実行されていた
*3:サーバ用途でない
*4:日本時間で15:47はサーバのローカルタイム(UTC)で6:47である
*5:余談だが、このログはFluentdで即座に読み出して外に転送・保存しているので、この運用で良いのです
*6:なお選択肢としては、NVMeデバイスにアクセスログを書きつつもっと頻繁にlogrotateする、という手もなくはない。しかし結局負荷のスパイクの深刻さがファイルサイズに影響されるという状況は変わっておらず、将来的にアクセスログの成長速度がさらに増加したときにトラブルを起こすという潜在的な危険を抱えたままになるので、自分としてはその手段は避けたほうがよいと思う。
RubyKaigi 2019いってきた＆LTやってきた
はい、今年のRubyKaigi 2019は福岡でしたね!
私事でばたばたしてたんだけど、ずっと前から参加を予定してたものだしで、行ってきた。今回もいいカンファレンスだったし、福岡はいい街だしで、よかったですね!
LTやってきた
元々メイントークでproposal出してたんだけど落ちちゃって、LTに出したら通った、のでやってきた。時間がなかったので細かい説明をちゃんとやるより、インパクトとネタ重視で。
内容はRuby 2.6で追加された RubyVM::AbstractSyntaxTree を使ってマクロを実現するぜ! というやつ。コードはこちら。
これ自体はもうちょっと機能追加とか機能修正したりしてから別途エントリを書くつもり。GW後かなー。あとActiveRecordのプラグインとして一部機能を切り出したりしたほうが多くの人にはわかりやすいかもなあ、とも思っている。これは誰かに相談してみたい。
とはいえそれなりに使えるプロダクトを作ったと思っている。着眼点はそんなに悪くない気がするのでもうちょっとプロダクトとしてのアピールを別途してみたい。
LTとしては……こういうLTってだいぶ久し振りにやった気がするけど、当初時間がまったく足りないと思われていた割にちゃんと時間内に最後までしゃべれたし、ウケを狙ったところではちゃんと取れたし、よかったよかった。
そのほかカンファレンス
今年はとにかくパターンマッチがアツい! あと継続してJITと型とGit移行と……あれやこれや。
あと RubyVM::AbstractSyntaxTree には何人もの人が目をつけてて、あちこちでコード解析や書き換えみたいな話があった模様。自分が聞いてた @joker1007 さんのトークとかもやってることの共通点がめちゃくちゃ多くて一人でウケてた。
クロージングで言ってたことだけど、とにかく "We Code" に尽きるな、と思っている。また面白い/興味深いコードが書けたら、次回のRubyKaigiでもなんか話したい。
そのほか福岡など
今年はとにかくPartyがなんか色々とおかしくて、前日はESMのPre Partyでナイトクルージング。船。イベント感がすごい。
1日目のOfficial Partyは商店街の貸し切り……とはいえ通常営業の店もあったりで普通の歩行者なんかも混ざっててマジでカオス。クレイジーという言葉がぴったりだった。すごかった……。スタンディングで日本酒飲みながらダラダラしてた。
3日目はArm Treasure Data主催のAfter Party。テラスから外が開けてていい会場でしたね! ここはいろいろ見回ったり受付やってる時間もあったりで、個人的にはちょっとお仕事モードだった。まあ、まあ。今年も @tanaka_akr さんが「テンションが上がってきたのでスライド作った」というからゲリラテックトークをやってもらったのはすごくよかった。@a_matsudaさんに「録画しといてください」と事前に言われてましたがすっかり忘れてました。
RubyKaigi 2019 After Party で「autoloadの話」という発表をした。https://t.co/IShb0nzCPB#rubykaigi
— Tanaka Akira (@tanaka_akr) April 20, 2019
あとはもつ鍋食べたり水炊き食べたりお寿司食べたり。いやー、いい福岡だった。また行きたい。
まとめ
来年は松本でお会いしましょう。
TDのパーカー等をずらっと並べてみる
自分の勤務先であるところのTreasure Dataは昨年めでたく買収されてArm Treasure Dataとなったが、最近ちょっと必要に迫られてタンスなどを整理しているところ大量にTDパーカー等が出てきてちょっと馬鹿にならない量になった。まあ処分するしかないものの割とレアなやつも混ざっててこのまま闇に葬るのもアレだったので、ちょっとずらっと並べたので記録しとく。
歴代パーカー
知っている限りで最初のTDパーカー。前面がFluentdで背面がTDというのがなんか会社の成り立ちを表してるみたいでけっこう好き。この頃はTD社員じゃなかったのになんで持ってるかというと、最初のFluentd meetupでしゃべったときにスピーカーとしてもらったんじゃなかったかなー。この頃は数も作ってなかったと思うので、今となってはかなりレア度高いはず。CEOの芳川さん*1がいまだにMountain Viewのオフィスでよく着てる。
最初のTDロゴがメインの(おそらく)ゆいいつのパーカー。これ、生地もゴワゴワだしジッパーもないしデザインもいまいちで、誰も着てるの見たことがない。自分もほとんど着たことがない新品同様のはず。同じくTD社員じゃない頃にもらったんだけどなんでもらったんだかもう完全に覚えてない。社員も誰も着てないもんだから見付けたときに思わずこんなんあったなーとか声が出た。レア……かな?
なおこのロゴ、Big Dataをやるぞ! というノリが表されたHDDベースのデザインだったんだけど、後に「いまどき誰もHDDなんか知らんだろ」というツッコミにより変更された(らしい)。
自分が入社した2015年あたりのロゴ(3世代目)とデザインのやつ。この紺色に "WE LOVE DATA" のデザインは長く使われて、いくつも細部の違うバリエーションがある。TDユーザーとかにもだいぶ配ってたような気がするので、持ってる人も多いかも。これは東京オフィス側で作ったんだけど、よく配られてるノベルティのパーカーに較べて生地が断然良くて、嬉しがって使ってた覚えがある。持ってるやつもだいぶ古びてる。
なおこの前に2世代目のロゴがあったんだけど、パーカーは作られてないような気がする。ロゴがなあ……*2。
その次、2017年くらい? のやつ。これも生地がいい。あまりバリエーションは無いのと、これもユーザー企業やTD関連勉強会のスピーカーとかに配ってた気がする。これはいまだに外部の人達が着てるのを見ることがある。
たぶん去年(2018)のはじめとかに作ったやつ。あまり印象がない……のは、割とすぐあれこれ会社的には変わる話があったからかな。ロゴがこの時点で最新のもの(4世代目)になっている。数はけっこう作ったのかなあ。もしかしたらレア度高いのかも。
Arm Treasure Dataになって初めて作られたやつ。USオフィスで一回だけ作られたので最近のだけどかなりレア。日本では超レアかも。目にしたことがあったらラッキー。
はい、日本での現行 Arm Treasure Data パーカーです。あちこちのイベントとかでこれを着た人を見掛けたらぼくたちとあくしゅ!
Tシャツなど
Tシャツはかなりのバリエーションが作られてたはずだけど、いろいろ雑に扱ったりでまともに手元に残ってるのが少ない。手元にあったのをざっと。
このロゴが2世代目のやつ。だいぶレア。なんかイマイチなデザインなのと、3世代目に変わった直後に放映された下町ロケットの帝国重工のロゴがこれに激似だと社員の間でちょっと話題になった。背中のサービス説明が Big Data as a Service だった往時のTreasure Dataを思わせる。
これが3代目ロゴで、単色ピンクなのがポイントで、その色とグレーがコーポレートカラーとして指定されてた。わりと長くこのロゴだったなあ。
Armに買収されたので色がArm色のブルーになったやつと、その後にちゃんと Arm Treasure Data として作ったやつ。右側が最新(現行)のTシャツですね。
おまけ: Fluentd関係
だいぶ昔にごく少数だけ作られたFluentd開発者向け(?)Tシャツ。たぶん10枚とかそれより少ない数しか作られてないんじゃないかなあ。超絶レア*3。Linusのアレをベースにしていることは一目瞭然。
で、後にFluentdの新ロゴ(現行ロゴ)でも作り直された。こっちのほうがもうちょっと枚数があるはず。とはいえレア度高し。
これはCNCFが作ったパーカーで、なんとCNCF Storeで誰でも買える。Tシャツもあるよ。買おう!
写真はないがこのパーカーにTresure Dataロゴが追加されたマイナーバージョン違いが存在して、これはFluentdがCNCFに加わった直後に社員だけに配られたはず。なかなかレア。
まとめ
いかがでしたか?*4 パーカーもロゴもいろいろありましたね!
gradle installDist したときのディレクトリ名と実行ファイル名の設定
ビルドした環境に依存する起動スクリプトを生成してくれるように gradle installDist したとき、ディレクトリ名にはプロジェクトのディレクトリ名が使われる。
my-project$ ./gradlew installDist # すると以下のツリーができる # my-project/build/install/my-project/lib # my-project/build/install/my-project/lib/... # my-project/build/install/my-project/bin # my-project/build/install/my-project/bin/my-project (executable)
普段手元でやる分にはいいんだけど、うっかりcommit hashを使って git repo をチェックアウトしたツリーの下で実行したりすると my-project の部分が全部 commit hash になったりして超めんどくさい気分になったので、これを build.gradle の設定で固定しとけないかと思った次第。
installDistタスクは application プラグインによるものだが、これは Distribution プラグインによってディストリビューションを構成している。また実行ファイルの作成は CreateStartScript プラグインによって行われている……ので、このふたつを調べた。
- https://docs.gradle.org/current/userguide/application_plugin.html
- https://docs.gradle.org/current/userguide/distribution_plugin.html#distribution_plugin
- https://docs.gradle.org/current/dsl/org.gradle.jvm.application.tasks.CreateStartScripts.html#org.gradle.jvm.application.tasks.CreateStartScripts
で、結論としてディレクトリの指定には Distribution プラグインのとこに書いてある baseName をセットすればよく、実行ファイル名の指定は CreateStartScripts プラグインの applicationName をセットすればよい……んだけど CreateStartScripts プラグインのドキュメントに書いてあるとおり application プラグインは暗黙に startScripts タスクをデフォルト設定つきで作成するので、そのタスクの applicationName をセットしなければならない。
結果はこう。
apply plugin: 'application'
distributions {
main {
baseName = 'my-own-app'
}
}
startScripts {
applicationName = 'awesome-script'
}これで build/install/my-own-app/bin/awesome-script が常にゲットできる。
なんかちょっとググってみたらそのものの記述がなくて調べるのがめんどかったので書いておく。Gradle 5.0 のドキュメント読んでやってたけど Gradle 4 でも普通に動いた。
あと日本語で上のほうに出てくる Gradle 2.x ベースの日本語ドキュメントサイトは死んでほしい。
RubyConf 2018 に行ってきた＆しゃべってきた
タイトルの通り、と、ついでにシリコンバレー(Mountain View)にある自社オフィスに行ったり、バンクーバーに寄ってリモートで働いている同僚たちと会ってきたりしたので、合計3週間近くの長い北米出張をしてきた。
RubyConf 2018
プロポーザルを出したらRubyKaigiトラックで通ったので @joker1007 さんとふたりでしゃべってきた。内容は RubyKaigi 2018 で話した内容のほぼ再演*1なんだけど、もちろん英語で。
RubyConf 2018に登壇するためにL.Aまで行ってきた - joker1007’s diary
前に RubyConf 2014に行ったとき は、正直に言ってトークがぜんぜんダメダメ*2で、それに較べればだいぶマシに英語でプレゼンできるようになったとは思う。当たり前だけどその後に体験した場数が違いすぎるからというのもあるけど。内容が二人で協力した自身のものということもあって、成功と言ってよかったと思う。良かった。 @joker1007 さん、いっしょにやれてよかったです、ありがとう!
内容はいつもの通り、メタプログラミングであれこれ遊ぶぞ! ということで TracePoint や Binding や method hooks やらを使い倒す内容。
トーク直後に Ryan Davis (@the_zenspider)*3 から "You're terrible!" という非常に欲しかった反応をもらって、直接話しにも来てくれて、本当によかった。RubyConf でもこういうtechieなトークで聴衆を楽しませることはできる。できた。その後でもトーク聞いてたら「あのメタプログラミングのトークやった人?」って話しかけてもらったり、Twitterにもちょいちょい "crazy" と言及されてたりして、良かったなあ、という。「TracePointもBindingもmethod hookも単体では知っていたけど、ああいう風に組み合わせれば実際に使えるんだなと初めて知った」という反応もあったりして、これはもしかしたら世界に禁断の知識をバラ撒いてしまったかもしれんが、いやあ、いいんじゃないですかね。
RubyConf自体は4年前に来たときとあまり変わらず、soft talk *4が多いなー、という感じで、自分のトークが最終日だったこともあってあまり熱心にはセッションに参加せず、ふらふらしたりしてた。参加者の人とちょっと話したりすると割と技術の話が聞きたいよねーと言う人も多いので、もうちょっとそういうカンファレンスになってくれないかなとは思う。
今回は参加者*5に日本人の知り合いもけっこういたので、あまり英語でーとか考えずに知り合いとツルんでビールとか飲んでた。LAは初めてだったけどUS自体はもうけっこう慣れてきたので、その場その場でふらふら。
特にカンファレンス会場のすぐ近くに Karl Strauss Brewing Co. の店舗があるのを到着した直後に発見してしまい、ここで飲む店舗内で醸造されたビールがじつにうまくて通いまくってた。具体的にはLA滞在7日のうちに8回行った。最高*6。だってお昼に行ったら「いまそこで新しくできたビールなんだけど」って試飲を勧められて(おいしかった)、その夜にもう一度行ったらメニューに更にもうひとつ新作が追加されてるんだぜー? 南カリフォルニアに行く予定がある人はぜひ行ってみてほしい。
食事はとにかく肉。あとハンバーガー。USだとまじでこの選択が正義なので、連日外さずに食べてた。
肉だとカリフォルニアワインと組み合わせるのが正義で、行ったステーキハウスでオススメされたHALL St. Helenaのワインがじつによかった。日本で買えないかなあ。肉も、うっかり頼むとちょっと量が多過ぎることを除けば、じつにおいしかった。あとマッシュポテトは飲み物。
LAが発祥と言っていいっぽいカリフォルニアロールも、一度試したけどイマイチだった……んだけど、カンファレンスホテルのすぐそばにあったアメリカングリルの店を試してみたら美味しいやつが出てきたので最終的には成功。いい体験でした。
観光とか出張とか
Mountain Viewに行ってたけどあの地に観光ポイントなどほぼ皆無*7なのはよく知られた事実なので、週末の片方はSan Franciscoに遊びにいって知り合いとお昼を一緒にしてもらったあと、市内をふらふらしたりSF MoMAでよくわからないものを観たり、ビールを飲んだりしてた。
サンフランシスコの空が青くないのは山火事で流れてきてた煙のせい。こうして見ると本当に白いなあ。ひどい。街中はだいぶ煙くさかった。
日本でもニュースになってたみたいだけど、このときカリフォルニアは山火事がひどくて、San JoseからLAまでのフライトでちょうどLA北西で起きてた山火事の上空を通ったので、窓からその様子が見えていた。もう想像を絶する広範囲が黒く焼けていて、火事だとは信じがたい状況だった。こういう体験は日本にいるとできないなあ、とは思う。あとLAからバンクーバーに行く途中で日本人も大好き Mt. レーニア を見たり。おお、カッコいい山じゃん。
LA行くのは初めてだったので、カンファレンス後に3日オフをとってあった。1日目はAsakusa.rbなメンツでロングビーチに行って戦艦アイオワ観光。
もう戦艦、とにかくデカくてカッコいいというか。サンディエゴで観た空母ミッドウェーもそうだけど、これは日本で見られない。実に良かった。
あとはその周辺で、最近USに増えている電動キックボードサービスのLimeを試したりしつつ移動したり。写真はLimeを楽しむ某社CTO。個人的には直進安定性が悪過ぎるあんな乗り物であんなスピードを出すのは怖過ぎた。
あとロングビーチの反対側にある昔の豪華客船クィーン・メアリーも眺めてまわった。とにかくデカいよなー。
2日目はLAの南側にある公園の博物館に、スペースシャトル・エンデバーを観に @kakutani さんと。これも日本には無い……というかアメリカにしか無いやつ。じつに良かった。またしてもデカい。
博物館は主にNASAのものを中心にしつつ、自然科学一般も扱っているものだった。とにかくそこらじゅうに人工衛星だの飛行機だの戦闘機だのが置いてある。ブラックバードとかが野外に無造作に展示されててえええええってなったり、屋内に戦闘機やら飛行機やらが吊るされててどういうこっちゃってなったりした*8。実によかった。
3日目は一人だったので、まずハリウッド方面に行ってLA LA LANDで有名スポットになったグリフィス天文台に。人がめっちゃいた。あとどこまで眺めても陸地で、ちょっとよくわからない……みたいな景色になってる。遊歩道があったのでそのまま降りていってハリウッド中心部まで散歩。
その後はLAダウンタウンまで戻って、他のブルワリー巡りをやってた。リトルトーキョーの近くに集まってる場所があって、そこを4軒ハシゴ……したものの、うーん、Karl Straussがやっぱり一番美味しかったなーってことで、晩御飯はまたKarl Straussで食べてた。しかし街をあちこち歩きまわるのが好きで、今回は色々なものを見た。満足。
で、あとはバンクーバーに移動してあれこれ。カナダは初めてだったけど、バンクーバーは話に聞いていたとおりの綺麗で安全で住みやすそうな街だった。ダウンタウンは思ってたよりも都会という感じ。あと単位がメートル法で摂氏温度なのが最高です。この街でもこの数年でブルワリーがすごく増えたらしく、同僚にあちこち連れていってもらってた。
しかしこの時期はやっぱり寒くて夜が早い。滞在日数も少なかったのもあって、あんまりふらふら見て回るというのはできなかった。また春か夏に来る機会がありそうなのでそのときかな。
あとはいろいろ飲み食いしたものの写真があるので貼り付けておく。みんなも出張にいったらおいしいもの食べておいしいもの飲もうな!
