いろいろあった

I'll leave the current job at the end of December. The reason is a difference of a direction of my musicality from the company's one.

Of course, there were bunch of things. I can talk about their details but I seem it would not be nice case study. I can only say the difference of the direction. I think everything was caused by it.

Next year....... I'm planning to start a work as a freelance. I know well that this is not a best direction for me. However, I don't have any other choice. One thing I can say for sure is that I will not have a plan to work as a freelance for many years - ideally I'd like to finish and join to a nice company in several month~1 year.

Happy holidays. Have a happy new year.

アートとサイエンスのはざまで

例えばパフォーマンスエンジニアリングは定式化されたアクティビティをどれだけ回していくかのサイエンスだと思う。けれども、一般には秘伝の最適化手法を感性で駆使したアートのように思われていることが多いのはなぜなのか。「〜すると速い」みたいな真偽不明のマントラが多いからそのように見えるのか。

僕からすると、ソフトウェアの設計やリファクタリングの方がよっぽどアートだと思う。問題構造をどのように認識して、どのような形であるべきかを解いて、具体的なコードとして落とし込んで行くアクティビティであって、それは思想や哲学の叙述という行為に近しいからだ。パターン言語とかもあるけれども、ある思想体系において理論立てられた説明と用語を用いているという感覚。

styled-componentsへの最近の感想

今の職場で既に組まれたシステムが既にstyled-componentsにべったり依存していて、別に積極的に入れ替える理由もないので普通に使っているけれども、やっぱりこれ微妙だなと思った話。

そもそもとして、ビルドシステムへの介入が多くて不必要にロックインになったり、提示されてる手法がだいたいイマイチで普通にCSSとかSCSSを書く以上の意義が見出せないので、僕は基本的に「JS中にCSSを書いたり、ES Moduleのimportを使ってCSSを読み込むタイプのアプローチ(以下CSS-in-JS)」がそんなに好きではない・大人しくCSS書く方が好きではあるんだけど。色々あった理由はこちら:

感想

上のリンク先にも色々書いてる微妙に感じる点を全部見なかった事にしても、やっぱり微妙だと思う。

  1. 何を作るにもstyled-componentsで包まれた(ファクトリ)コンポーネントを作る事になるので、ラムダ(匿名関数)を書いて済ませたい箇所で、古のJavaのCallbackクラスを書くのを強制される気持ちになる
    1. 具体的には調整用のdivやspanをぺろっと置きたいだけなのに、わざわざ書く事になる
  2. 結果、包まれた(ファクトリ)コンポーネントは変数定義順の問題があり、function宣言のhoistingなどに頼ることができないので、 BEMのelement定義してからBlock書く感じになる。なので、抽象化されたコンポーネントを定義したいのに、まず具象化された細部から書いていく必要があるし、既存のコードもそのように書かれる
    1. ここら辺、人によって書き方変わるし、lintなどのしばり方次第で如何様にも書けるだろうけど、temporal dead zoneを考えると宣言してない変数を使うのはありえないのは共通認識とする
    2. 末節・BEMでいうelement側の定義をファイルを分けてimportすれば解決する問題だが、繰り返すようにラムダ(匿名関数)を書いて済ませたい箇所でCallbackクラスを定義するような事になる
  3. そもそもテンプレートリテラルで文字列として記述しているのが、非常に中途半端に見える
    1. JSX記法がDSLとしてセマンティクスを持つ事による教訓が活かされていないのは釈然としない

イマイチだと思ったのはここら辺。他にも色々あるけれども。

かつてのCoffeeScriptを持て囃す論説への拒否感と似ているものの、そんなことをいうとCoffeeScriptに失礼だな。

それとstyled-componentsに限った話題ではないけれども、いわゆる「GUIのTheme実現が可能」みたいな売り文句は実際には十中八九使わないタイプの機能だと思っていて、なぜかというと

  • 現実にはダークモード+alphaくらいしかテーマを作らない
    • そもそもテーマ機能を真面目に用意してるプロダクトを見た数の方が少ない
  • 仮に実装するとしても、起こり得るテーマの変更はCSS custom propertiesで使って色やサイズやbackground-imageなどの変数定義で解決するのが大半なので、標準化された方法に依存した方が良い
  • もっと複雑なことをやりたい場合は、大抵はGUIの実装部分が別になるので「一つのファイル・コードで複数のテーマを実現可能」にお世話になることは(あんまり)ない
    • ユーザー定義スタイルを許容する場合、尚更public interfaceとしてclass属性などは必須だし.

から。 ちなみに自分の好きなアプローチは上の方に貼ったリンク先に全部書いてあって、それを超えるものではなかったかな。

Facebookのリデザインに見る、CSS-in-JSの良さそうな方向

色々ぐだぐだ書いているけれども、 https://engineering.fb.com/web/facebook-redesign/ に載っているサンプルコードの方向性は、良さそうに見える。実際にこの通りに書かれてるかはわからないけどね。

なぜかというと、

  1. CSSで書きたい構造をJSのオブジェクトリテラルとして透過性を持って表現しているから
    1. 生成されるCSSの構造が非常に透過的
    2. いくらなんでも文字列リテラルCSS書くとかないわーと思っていたら、オブジェクトリテラルを上手く使って表現してるのは流石
  2. Reactに対しても透過的なアプローチである(下手に依存させていない)から
    1. emotionみたいにpragmaを使うのは、Reactとの間に抽象が挟まるので僕は好きではない

という具合に見えるから。Facebookオープンソースにしてくれるといいですね。

BlinkとWebKitの違い(大雑把)

「〜がChromiumベースに!」なことが起こるたびに「Chromium/BlinkはWebKitを源流とするエンジンでしかじか」みたいな話が出てきて、「実質WebKitだから同じだね」という反応が出てくるのが恒例行事っぽくなってるけど、結構モニョモニョする。

先祖が同じなら子孫も同じ、ってそんな単純な話じゃない。

fork前、BlinkがChromium WebKitというかWebKit Chromium portと呼ばれていた頃でさえ、Chromium portとApple portの2つが同じエンジンと呼べる箇所って、layoutとかdomとかstyleとかブラウザエンジンのコア部分だけで、他はV8とJSCとか、SkiaとCore Graphicsとか、そもそもプロセス分けてる方法も違うし、呉越同舟というか寄り合い所帯感だった。composition周りだってApple portはCore Animationにべっとり依存するような実装じゃなかったけ。

それで、数少ない共有部なコアでさえ、fork後に色々変わっている。自分の知っている・思い出せる範囲で大きいやつだと

  • layout
    • ChromiumはlayoutをLayoutNGって書き直しをやった
    • WebKitもLFCってコードネームで書き直し中
  • style
    • Chromiumは大きな書き直しは(僕の聞いた限りだと)ない、はず
    • WebKitCSS JITを投入した。その時にJITの有無に関わらずに色々変更が入った
  • DOMのオブジェクト管理
    • ChromiumはOilpan GCとかやってるし
    • WebKitはconstraintsとかいう魔術的な仕組みが投入された模様

とかとか。細かいあれこれを挙げだすとキリがない。

GeckoやEdgeHTMLと比較した場合、WebKitとBlinkは近縁種だと思うけど相対的なものでしかなくて、それぞれが呉越同舟していた時代に追加された仕様未定義な挙動に箇所に関するテストケースや、同祖であることに由来する箇所くらいしか、同じエンジンとは言えない。ましてや最近実装されたものは以下略。

リポジトリを境界としたコードベースとしては、WebKitは変わらずライブラリ指向だけど、Chromium/Blinkはプラットフォーム志向で、リポジトリの成長の方向性としてはFirefox/Geckoの方が近くなってきている

でも、そう変わるのも当然で、当代で世界トップクラスにお金を持っている二社が別々の方針で(数十人とか数百人のオーダーで)エンジニアを7年も張り付けていて、しかもそれぞれプロジェクトが実現したいWebに対するスタンスは結構違っているのに色々変わらない訳が無い。

でも、一方でWebGLの実装とかはWebKit(のApple port)もANGLE使おうとしてて、このままだとGecko/Blink/WebKitのどれもANGLEになろうとしているんだから、面白い。

JSConf 2019 Postmortem

JSConf 2019で Your benchmark may not guide real application performance という話をしてきました。 寒い中お越しいただいた皆様。ありがとうございました。

話さなかったこと

「そうは言ってもベンチマークを組み込むのつらいよね」な話

自分の体験談、身の回りの同僚知人各位の体験談も合わせていくとそれだけの一本のコンテンツにできますが、今回は単純にスコープ外かつ30分に収まらないので諦めました。私の力量の問題もあります

後からベンチマーク足そうと思うと本当に大変。まあ最初からやっても大変だとは思うけども、ゼロからやる方が"ちょっとだけ"簡単だと思う。

詰まるところカルチャーの問題なので、うまくチームや会社を巻き込まないといけない。「ソフトウェアパフォーマンスは究極的には組織文化である(要約)」というJoe Duffyの主張はとても正しい。「パフォーマンス専任担当者・チーム」が、どこからともなくやってきて、ベンチマーク足して帰って行ってもあんまりうまくいかない。文化として根付いていないからだ。

プロダクトを主に書いているチームの人間が自分たちで取り組まない限り、途中から現状維持でさえキツくなったり、ベンチマークスコアがどんどん遅くなるのを眺めて何もできないままとなっていくみたいな話。「遅い変更は強制revert」ルールとかも、ちゃんと(評価など含めて)カルチャー化してないと、ひたすら疲弊するだけですし。

再現性は手軽さも重要みたいな話

動かすだけで一苦労みたいな、手軽に再現できないベンチマークは誰も試さなくなる。「一回動かすのにセットアップで1人/週かかって、実行に5時間かかります」みたいなのは絶対に続かない。

わかりやすいボトルネックが本当に見当たらなくて「全体的に遅い」みたいなことになってる問題に対処する話

わかりやすいボトルネックを1~2つ潰したらこうなることが多い気がする。最初からそうなってることも、それなりにある(気がする)。

原因はクリティカルパスが隠れている以外にも、「どうしようもなく全体が遅い」「全体を速くしないと速くならない」みたいなこともあって、それはプログラミング慣習の問題だったり、ソフトウェアアーキテクチャだったり、そもそもの機能要求に起因したり、まあ色々。徹底して分析するしかないと思っている。

この手の話で好きなのはAndroidの豪傑Dianne HackbornがGoogle+で書いていた話なのだけど、もう消えちゃったんだよねえ.....(と思ったらアーカイブが残っていた)。これは少々極端だしOSやフレームワーク層の意見で、アプリケーション層とはまた少し違うと思うけれども、態度として敬意を払いたい。

「単純なボトルネックなんて早々に消え失せてしまった」系の話だとMozillaのQuantum Flowの時の話とかも個人的には好きです。

そもそもコアバリューってなんだよ・ちゃんと自分たちのコアバリュー考えて仕事してるんだっけ話

複数の友人から指摘されたけど、これ言い始めるともう少しメタな話になるので省きました。指摘をくれた友人各位には「俺よりもお前の方が適任だと思うぞ」と返信していたので、彼らがやってくれるかもしれません。

Q&A形式のまとめ

友人に勧められたのですが、(英語力の問題で)面白いやりとりが思い浮かばなかったor身も蓋もなさすぎるのでボツになりました。

よかったこと

話が刺さってくだすった観客が何人かいたこと。 その後、直接感想をくださった皆様、ありがとうございます。楽しんでもらえらた人がいるだけで何よりです。

やっちまったなと思うこと

動画が公開されるかもしれませんので、現時点で気づいたことを予め懺悔しておきます

  • 観客の目を見て喋る機会が少なかった
    • 「下ばっかり見て何だコイツ」と思われた方もいると思います。申し訳ありません。カンペ読んでました
  • しゃべるの速すぎる
    • すいません。練習が足りませんでした。
  • 序盤、「自分たちでコントロールできない指標」のくだりでしどろもどろになってしまったこと
    • うっかり口が滑ってしまった
    • 多分意味不明なこと言ってます。本当に申し訳ない。
  • ベンチマークは指標に過ぎないという話が弱かったかもしれない
    • あくまでも実現したいコアバリュー・目標としての速度があって、ベンチマークはそこに向かって進むためのテストケースに過ぎないという話です
  • Causal Profilingの話への理解が微妙に甘い。たぶん変なこと言ってる気がする
    • 理解が甘いのに無理に言及してしまった
    • 詳しく知りたい方は元論文を参照してください

謝辞

運営の皆様、二日間開催お疲れ様でした。来年はUDXカンファレンスや大田区産業プラザPioでの開催となれば駅近なので嬉しいです。途中で帰ってしまったため、もしアンケートフォームなどありましたら公式Twitterでシェアいただければ幸いです。

当日お越しいただいた皆様、ありがとうございました。楽しんでいただけたなら幸いです。

観客の皆さんは金と時間を使って観に来てくださっているわけで、やはり楽しんでもらえないことには自分が発表する意味はないわけです。無闇に客に媚びれば良いというものでもありませんが、ちゃんと一人でもいいから需要のある話を提供できないといけないわけです。そうした中で何かしら刺さってくれる人がいたのであれば、登壇者冥利に尽きます。

資料のレビューやアイデア出しに参加いただいた友人各位、本当にありがとうございました。無事形になりました。皆さんのおかげです。本当にありがとうございました。

Leave my work

I was fired 😫

Sorry, this is a bit clickbait phrase. My contract was ended due to various reasons. This primary reason is that I could not pass the interview by an industrial doctor and I ended over the period my employer allows me to rest.

Thank you for my colleagues.

By the way, I'm finding my next job. I don't have any concrete next plan. I consider all options about my next position since I can no longer to work for CyberAgent Inc. If you have an opportunity which I may suite for, I’ll appreciate to let me knows about it. Please contact me via my email address which I listed to GitHub.

I'd like to work to continue software engineer and I'm interested in to challenge to shape a platform service provides high availability, performance, and reliability.

However, this my hope might too long jump if you know my career. But I'd like to challenge it.

Finally, I appreciate my colleagues. I’m looking forward to see you again. Bye.