2020-10-30

自分の生産性について考えてみる

雑記

組織の生産性を上げるために何かアクションを取りたいのだけど、今は何も計測できていないし、改善案も出せていない。組織はいろいろな人が同時に動いていて難しいので、まずは自分自身の生産性について考えてみる。

自分はWFHで生産性が下がっているような気はしていたけれど、WFHだから下がっているのか、立場が変わって下がっているのか、そもそも実は下がっていないのかもしれない。自分の生産性をどう評価するかは置いておいて、まずは素朴にパフォーマンスがでることとでないことを考えてみた。普段はこういうことは外には書かないんだけど、恥を忍んで出してみる。

得意なこと

一ユーザーとして不満に思っていたことの改善
課題感や解決方法に納得のいくタスク
- 電気系出身なので「共振」できることってイメージだけど他の人に伝わらないから「共感」とか「納得」って言ってる
ユーザー目線でサービスを触ったり告知を読んだりする
一つのものを集中して作り上げる
技術的に正しい改善
- ライブラリ・ミドルウェアバージョンアップ
- パフォーマンス改善、コスト改善、クラウド移行
既存の実装のリファクタリングまたは再実装
- 仕様を整理し直してきれいに作りたい
- 長年の課題を再設計して解決したい
既存の実装の別言語での実装
- よくやる
実行パスのカバレッジを脳内で上げる
- 不具合の原因を探る時によくやる
シンプルに作り保守的にメンテしていく
- シンプルな仕様を考えるのもわりと得意
データ構造やファイルフォーマットの設計
- 単に好きってだけ
好きなことなら休日でもコードを書いている
OSSを触る、OSSを直す、OSSを作る

苦手なこと

課題感や解決方法に共感できないタスク
- 仕事はやらねばならぬことは理解している
- やれといわれたらやるがスピードは出ない
複数のタスクを同時に進める
- とくに面倒なタスクが同時に目の前にあると急激に集中力が落ちる
自分から様子を見に行く
- 組織の生産性が上がることはわかるがポーリングは大変
- 呼びつけてくれ…
隙間時間に仕様を把握する
- 一日集中したい
旗振り役
- アサイン決めたり期限を決めたり…
組織の問題点を指摘する
- 現状維持になってしまう
- 変えていくのが正義なのは知っている
- 組織がどうあるべきかの知識がない
評価のためのアクションプランを考える
- したことを評価基準にあわせてそれっぽく書いている
本を読む
- 一年に一冊くらいしか読まない

苦手なことを減らすには

意識して苦手なことを克服する時間を取る
- 意識して本を読む
  - 自分はもっと本を読むべきって数年思ってるけど、目の前に面白い問題があったらコード書いちゃう
それっぽい本を読んで方法論を学ぶ
- 積読は多い
タスクを直列にしてそれぞれに集中して片付ける
- 意識してこれもやる
  - 昔ためしたポモドーロは合わなかった
苦手なことを補ってくれる人を捕まえる
- 自分が苦手なことが得意な人はいるので相談する
- 苦手なことは移譲する
  - やりすぎると自分の成果は？となる
得意なことを活かせるロールにつく

この休日でもう少し深堀りして考えてみる。

2019-12-31

2019年を振り返って

雑記

今年は仕事の部署異動があり気分一新したわけですが、思うようにパフォーマンスを出せず悩んでいたような気がします。前半もチームのために頑張っていた気がするんですがすべて忘れました。

今日は実家でgoreのGo modules対応をやってました。いい加減modules対応していないのやばいよなと思って一所懸命packagesパッケージのコードを読んでいます。まだ確認しないといけないパターンは沢山ありそうですが、年始にはマージする予定です (と書いて追い込んでおく)。goreは本当に便利なのでmodulesごときで死なせたくないですね…

今年はgojqを作れたのは大きいですね。これは本当にいいプロダクトなはずなんですが、宣伝がうまく行ってなくてイマイチですね。docker関連ツールの組み込みあたりを狙えたら本望なんですが、その前に英語で紹介記事を書かないとだめですね。しかしこれを作ったことで一年前よりも言語処理系に対するイメージがはっきりしてきたような気がします。jqのセマンティクスは結構特殊なんですけどね。

社内の諸事情から作ったgithub-migratorも便利なツールなのですが、ユースケースがニッチ過ぎてイマイチですね… 社内ドキュメントは書いてあるのでみんな移行してね。

今年は社用パソコンが変わってかなり快適になりました。自作cliツールのHomebrew tapリポジトリとsetupリポジトリを整備できたのは大きいですね。環境セットアップが (理想的には) コマンド一つで立ち上がるようになりました。環境セットアップスクリプトがCIを通っている安心感もありますね。

最近社内で圏論勉強会をやっていて、圏論に対する理解がかなり深まったのは大きな収穫です。随伴とか普遍的構成、極限あたりの考え方がだいぶ理解できて自信が付きました。普遍的構成の考え方ってプログラミングと相性がいいんですよね (一意の射が存在することが関数を定義できるのと同じなので)。ちゃんとプログラミングの世界に成果を持ち帰りたいところです。

旅行は夏に長崎に行きました。色づく世界の明日からやsolaの聖地を訪れることは良かったのですが、坂道の多い街なので歩きまわって疲れましたね。色づく世界の明日からのカットを回るにはもうちょっと下調べが必要でしたね。とある公園から山を降りるときにミスって墓地に迷い込んで大変でした。稲佐山からの夜景はめちゃくちゃきれいでした。

今年の良かったアニメは『ベルゼブブ嬢のお気に召すまま。』『やがて君になる』『かぐや様は告らせたい～天才たちの恋愛頭脳戦～』『女子高生の無駄づかい』『まちカドまぞく』『鬼滅の刃』あたりでしょうか。かぐや様の古賀葵さんめっちゃくちゃ良かったですね。ラジオ『令和最初の告RADIO』も良かった。

来年もいい一年になりますように、きっとなりますように。

錆兎「努力は、どれだけしても足りないんだよ。知ってるだろ、それはお前も」
鬼滅の刃第四話

2018-12-31

2018年を振り返って

雑記

今年は仕事を淡々とこなしつつ、自分の技術の方向性に悩みながらも、ずいぶんとだらけてしまった一年だったと思います。技術面での成長に伸び悩んでいます。

Mackerelのコードの整理や改善は無限にやることがあるのですが、平日夜や休日をそれで潰す生活をしていると、頭の切り替えがうまく行かなくなり仕事中に集中できなくなってしまいました。フロントエンドはかなりコードの整理が進み、SPA化できたのはよかったですね。コンテナ周りはチョットワカルと言えるようになりたいですね。

春先にバイナリエディタをリリースしました。まだ実装したい機能はたくさんありますが、リリースしたら燃え尽きてしまってあまりコードを触れていません。Goを書き続ける良い遊び場なので、今後もきちんと開発を続けていきたいですね。

バイナリエディタの後は特に何かを作ることもなく、また新しい技術を学ぶこともなく、のんびり過ごしてしまいました。以前は仕事から帰ってからも3〜4時間コードを書くことができましたが、夏頃に小指の痛みがひどくなり、夕食をとってからベッドでだらだら過ごす日が多くなりました。好きなYouTuberを見つけたのも今年のことでした。

プログラミング以外の趣味を持たなければ人生が薄っぺらいまま終わってしまうのではないかという危機感をいだき、12月に入ってから思い切ってピアノを購入しました。音楽は良いものですね。最近は毎日最低でも二時間は練習時間に取れていると思います。小学生の頃にピアノを習っていましたが、中学受験のために辞めて以来なので、実に十数年のブランクがあります。基礎練習が大事だというのは嫌というほど知っているので、単調な練習曲を5回10回と繰り返しながら、指を動かす感覚を取り戻しているところです。実家から教本を何冊かもらって帰るつもりです。ショパンが大好きなので弾けるようになるといいですね。

ウェザーニュースLiVEを頻繁に見るようになったのも今年に入ってからです。個性的なキャスターがみな魅力的で、番組の内容は聞き続けても飽きません。声も個性的なので今では聞くだけで誰かすぐわかるようになりました。SOLiVE24時代をリアルタイムに楽しめなかったのがすごく残念です。

ルービックキューブも今年に入ってから始めました。昔から日本配色のキューブを持っていましたが、会社で流行したタイミングでMoYuのGTS2Mを買いました。興味は次第に多次元・多面体キューブに移っていき、LanLanやYuXinのキューブを集めて遊んでいます。未だにGreg's Multi Cubeの解き方がわかっていません。commutatorとconjugateは回し方を整理するのには便利ですが、新しいキューブを解くのは私にはまだ難しいです。

Vim本体の最新パッチを追う情熱は持てなくなり辞めてしまいました。今年はプラグインも作れてないですね。最近入れたプラグインの中ではtraces.vimはかなり便利なプラグインだと思います。lightline.vimは3300スターを超えて、今もなお増え続けています。つい先日vim-winfixのバグを直したので、こういう小粒便利プラグインの紹介でも書いてみようかなと考えています。git系のプラグインはなかなか手になじまないことが多いので自分で作ろうかなと考え始めています。

今年もたくさんのアニメを見ました。中でも『多田くんは恋をしない』『はるかなレシーブ』『色づく世界の明日から』『やがて君になる』は印象に強く残っています。来年は『マギアレコード』『フルーツバスケット新』『ストライクウィッチーズ 501』そして『PSYCHO-PASS 劇場版』に期待しています。

今後もブラウザ、言語処理系、機械学習という三分野を深掘りしていきたいという気持ちは変わっていません。仕事と趣味そして休息のバランスを取りながら来年も頑張っていきましょう。

風野あさぎ「あいかわらずが続くのって、つらくないですか」
色づく世界の明日から第八話

2017-12-31

2017年を振り返って

雑記

今年は仕事で関わっているプロダクトが大きな転換期を迎えて、様々な経験ができました。ミドルウェアを自ら作り上げ、データをオンラインで移行し、運用を始めるというのはなかなか経験できないことだと思います。サービスは以前より安定し、穏やかな年末を過ごしています。

今年は初めてカンファレンスで登壇しました。慣れないことばかりで色々と戸惑いましたが、沢山の方に発表を聞きに来ていただいて嬉しかったです。マネージドサービスを組み合わせて1つのソフトウェアを作り、それをサーバーレスミドルウェアとして抽象度を上げて捉えることができるようになったもの、このカンファレンスに参加してよかったことでした。

今年は19記事書きました。特に、以下の記事は多くの方に読んでいただきました。

一年の後半にアウトプットが減速しているのは、カンファレンスの登壇に体力を使ってしまったこと、Prime VideoやAbemaTVを見ながらぼーっとする時間が増えたこと、プロダクトコードのリファクタリングに随分と入れ込んでしまったことなどが原因だと思います。

年始はコンパイラーやインタープリターに興味があり、インタープリターを書いてみたりLLVMを試したりしていたのですが、3月ぐらいには興味も薄れていきました。8月くらいまでは仕事が忙しく余裕がありませんでしたね。その後Rustを真面目に書き始め、システムコールに興味を持ち、そしてMackerelのシステムメトリックに興味が移り、go-osstatを作り始めました。最近はエディターの実装に興味を持ち、色々と調べています。ことごとくトレンドを外した感じに共感を持てますね、まぁ自分のことですが。

Vim周辺の変化で言うと、vimshellを辞めてterminalを使いだしたことくらいですが、他はほとんど変化はありませんでした。lightlineのスター数は順調に伸び、2500を突破しました。ユーザー数は増えてもissue報告はそんなに増えていないし、ほとんどが設定の仕方に関する質問なので楽なものです。

今年は投資を始めた年でした。これまで一切経済のニュースとか興味がなかったのですが、今のペースで経済が成長していくと現金で持っているのがアホらしく思えてくるので、少しずつ時間を取って勉強し始めています。まだド素人なので特に語れることはありません。

生活面、仕事面共に大きな変化はありませんでしたが、緩やかに成長できた一年だったと思います。来年は少しずつアクセルを踏んで頑張っていきましょう。

山村美和「なんでも本気でやるから楽しいんじゃん。」
ばらかもん

2017-10-10

負荷を均すための『時間軸シャーディング』という考え方

雑記

ウェブアプリケーションを作っていると、負荷を分散させるために「タイミングをばらけさせる」場面に時々遭遇します。データの更新、キャッシュのフラッシュ、バッチ処理など様々な問題で、同じ構造が見られます。

例えば、スマホアプリからバックグラウンドで1時間ごとに何らかの情報をサーバーに送りたいとします。愚直に毎時0分に更新処理を行うようにすると、すべてのユーザーから同じタイミングでリクエストが来てしまいます。ですから、リクエストのタイミングをユーザーごとにばらして負荷を均す必要があります。

他のケースを考えます。 5分ごとにジョブを投入して何らかの更新を行うタスクがあるとします。本来ならデータベースに更新を行いたいのですが、データベースのハードウェアの限界が近いので、更新データをまずキャッシュに乗せるようにしました。何らかのタイミングでキャッシュからデータベースにフラッシュする必要があります。データベースに書き込むタイミングをジョブによってばらして負荷を均したいという要求が出るのは自然なことです。

負荷を均すときに考える基本的なことは、何が時間軸上でばらけるかということです。例えばインストール時刻がばらけるならば、インストール時刻から1時間ごとに更新するという処理でユーザーごとにばらけるでしょう。そんな都合のいいタイミングがない場合や、ストレージに情報を持てない場合には、id番号のようにすでにばらけているものから処理する時刻を決めるのが有効です。例えば5分毎のジョブ投入のケースの場合、id番号のmod 12を取った値が分を5で割った値と同じになったタイミングで処理を行うようにすると、重い処理を1時間に一回にしてかつ負荷を分割することができます。

func shouldUpdate(job: Job) bool {
    return (job.ID % 12) == (time.Now().Minute() / 5)
}

idが文字列の場合は文字コードの和をとる、SHA-1を取って文字コード和をとる、CRCをとるなど、とにかくmodでばらけるような数字を作れたら成功です。

本来なら毎回行う更新処理を数回に一回にしてばらけさせる、あるいはリクエストの集中を避けるためにタイミングをばらけさせる。このように、負荷を分割して均す目的で時間軸上でばらけさせる処理は、時間軸方向のシャーディングと言うことができます。

一般にシャーディングというと、データベースやストリームをスケールアウトさせて負荷を分散させる、空間軸方向のシャーディングを指します。一つのデータベースに集中させていたものを、ハードウェアの限界などのためにデータベースを分割して負荷を軽減させるのがよくあるケースです。何らかのハッシュ関数のmodからノードを決定してデータを書き込む。ハッシュ値のmodが均等に分散すれば、各ノードの負荷は1/(ノード数)に軽減されます。

更新リクエストを時間軸上で分散させるときも、idから計算したハッシュ値のmod (単純なケースではidのmod) を取ります。 1時間を5分毎に分割するときは、ノード数が12ですからmod 12を取ってノードを決定します。 15ノードに分けても30ノードに分けても構いません。一日一回の更新タスクを24分割するならmod 24を取って時刻と比較するとか、96分割してその日の経過した分を15で割った数字と比較するなど、分割方法はいくらでもあります。ノードの分割方法は、タスクの投入の仕方、どれくらいの失敗が許容されるか、短い期間で同じ処理を行なっても大丈夫かなど、問題の性質によって変わってきます。いずれにしても、idや名前などの固定値からハッシュ値を作ることが大切です。

もっと古典的なユースケースとして、重いバッチ処理をmodで分割するのも、時間軸のシャーディングと言えます。偶数番号と奇数番号でバッチを分割するというのは最も単純なシャーディングです。

これまで「タイミングをばらけさせる」と言っていたものを「時間軸のシャーディング」という言葉で表現することで、空間軸のシャーディングの用語を類推して用いることができます。例えば「シャードが偏る」という言葉がありますが、時間軸シャーディングの場合で偏る場合はだいたいハッシュ関数か元の値の選び方が悪いでしょう。「シャードを分割する」場合は、特定の一つのシャードを分割するよりも、10分毎のノードを5分毎に分割するという風に時間軸上のノード数を増やすのが有効だと思います。空間軸シャーディングとは違って、時間軸シャーディングの場合はデータ移行を考えなくて良いので、ハッシュ関数やノードの分割方法を変えて「リシャーディング」を行うことでうまくいく場合が多いと思います。

上記で書いた内容は、特に新しいことはやっていませんし、タイミングをいい具合にばらけさせるコードを書いたことがある人はたくさんいると思います。そういう処理を時間軸のシャーディングと捉えることで、言葉を類推して用いることができるようになり、空間軸シャーディングと対比して利点と欠点を比較し、より良い方を選ぶことができるようになると思います。

「更新が多くてハードウェアの限界に来てますが、仕様としてもう少し更新回数減らしてよさそうですね。ただ、タイミングがばらばらになるとよさそう」のようなあやふやな言葉で伝えていたものを、「時間軸シャーディングするとよさそうですね。1時間を12ノードに分けましょう。1時間に一回の更新で仕様上は問題はありません。空間軸シャーディングはこれでだめになった時にまた考えましょう」のようにはっきりと伝えられるとかっこいいですね。

追記: ジョブキュー使いましょうというのは真っ当なご意見ですし、負荷のパターンと工数によってジョブキューを作るべき場面もあるでしょう。もともと時間軸シャーディングを考えたのは負荷が一定でスパイクのない系で工数をかけずにタイミングをバラすというものだったので、負荷を均す一つの解法にすぎないことは把握しております。