前回から2ヶ月くらいかな。

かなりのびてしまっていたのでいつもどおりばっさりと。今日の人は思い切りのいい人なので安心。髪を切るのとか、色を入れるとか、パーマとか、美容院の人は常に不可逆なことをしないといけないから大変だなぁと思うのであった。

Windows + VS Code Remote(Container) + Docker Desktop for Windows(WSL2)の練習を兼ねて、Web日記いじりをしていた。

• コードハイライトをhighlightjs/highlight.js: から Prism にする
• Google AdSenseを削除する
• AMPページのフォントをちゃんとする
• AMPページからshareボタンを削除する

コードハイライトのライブラリであるhighlight.jsは、コードの自動判定などが便利なので使っていたが、その仕組み上読み込むだけではハイライトされなくて、document.onloadなどにくっつけないといけない。もしくは、READMEにある通りWeb Workerを使う。

一方のPrismは、自動判定が無いために<code>にclass=language-*というクラスをつけるのが必要になっている。しかし、それ利用することを前提として言語毎のJavaScriptを分離していて、結果として読み込むJavaScriptの量を減らすことができている。

なお、Markdownでは以下のようにコードブロックに言語を書くことができ、多くのMarkdownライブラリはPrism.jsが処理するclassのついたタグを出力ができる。便利。

def hello
  puts hello
end

↑のブロックは、こういうhtmlになっている。

<pre class="language-ruby">
  <code class="language-ruby">
...

そんなことよりも、試しにいれてるCSPをなんとかしたほうが良いと思うのだが、腰が重いのでまずはこのへんから。

家のマシンをSurface Proにしてから、仕事以外のことはだいたいWindows上でやっていて、このブログをいじるときもVisual Studio CodeのRemote Development(Container)でやっている。

で、今日久しぶりにいじっていたら、 エディタでファイルを編集してリロードしても変更が反映されなくなってしまっていた。ただ、サーバプロセスを再起動すると反映されたので、ファイルの変更がうまく検知されてなさそうということがわかった。

さて、ファイルの変更を検知して読み込みなおすような仕組みは inotify を使って実現されていて、Railsでは guard/listen というラッパーライブラリを使っている。まずはイベントがちゃんと起きているのかを調べる必要があるので、inotifywaitというコマンドを使ってみる。inotifywaitコマンドは、debian系ならinotify-toolsというパッケージに入っている。

コマンドが使えるようになったら、inotifywait -m .などとしてイベントをモニタリングする。案の定、VS Code上でファイルを変更してもイベントが通知されず、コンテナ内で直接ファイルを操作した場合には通知されることを確認した。

docker/for-winのissueを眺めてみると、inotify絡みの問題は度々起きているようで、最近だと File not changing inside docker container after updating from 2.1.0.5 to 2.2.0.0 · Issue #5530 · docker/for-win というissueがあった。これによると、stableの2.2.0.4だと問題がなさそうとのこと。

EdgeをアンインストールしてStableをインストールして無事解決したのであった。最初は、WSL2絡みのバグかなぁと思ったのだけど、Stableを使えばWSL2でもHyper-Vを直接使った場合もでどちらでもうまく動いた。めでたしめでたし。

2020-03-23 追記

やっぱりうまくうごいていないときがある。ただ、Dockerをrestartするとうまく行くことがあったり、原因がわからん。具体的には、inotifywaitを実行するディレクトリはうまく拾えるのだけど、-r オプションをつけて再帰的にモニタリングするとダメな感じ。悩ましい。

2020-03-23 追記2

WSL2の問題っぽいことがわかったので戻した。さすがexperimental。

Gentooのパッケージ管理システムであるportageは、野良パッケージリポジトリを使うのが容易なので、自分が必要だけどメインツリーや信頼できるoverlayに存在しないものは、以下のような自分でメンテナンス可能なリポジトリで管理していた。(この他にも、社内でしか使わないであろうものはGitHub Enterprise上にもリポジトリを作っている)

• kenchan/portage-overlay: My Personal Portage Overlay
• esminc/esm-overlay: ESM’s portage overlay. It’s useful for especially Ruby/Rails application development.

しかし、少し前に Project:GURU - Gentoo Wiki というものを知ったので、これからはなるべくこちらに入れるようにしようと思っている。GURUはArchでいうAUR、つまりユーザによるコミュニティ公式のパッケージリポジトリである。

ここにebuildファイルを追加する方法はプロジェクトページに書いてあるので割愛するが、私がghqのebuildファイルをdevブランチにpushしたところ、若干の手直しがあって翌日にはmasterブランチで公開されていた。

さて、実際にgentooにghqをインストールしたい場合は、おそらくみなさんlaymanをお使いだと思うので以下の2コマンドでOK。

# layman -a guru

# emerge ghq

レビュー込みでこれだけの早さで公開されるのはとてもよい体験だったので、細かい修正をしてくれるTrusted Contributorsの方々に感謝するばかり。これからも足りないソフトウェアはどんどんebuildを書いていれていくぞ〜。

ペパボのパートナーの自宅作業デスクまとめ - ペパボテックブログ には残念ながら採用されなかったので、こちらで晒しておく。

間取り的に固定席を作るが難しいので、キャスター付きの昇降机になっている。この机はキーボードスライダーがあることによってKinesisをおいても圧迫感がないし、自然な感じで打てるので気に入ってる。普段はスライダーを出さずに、写真のままの状態で使っている。

ディスプレイは、今回の在宅勤務期間で購入したもので、机を移動させる都合上モニターアームで取り付けている。ただ、そのせいで昇降時の耐荷重(5kg)を超えてしまったようで、スムーズな昇降ができなくなってしまった。無念。

詳細は Scrapboxの 津田沼オフィス - kenchan にアサマシリンクと一緒に載せているので、これはなんじゃ？というがあったら見てもらえれば。

2020年のテーマは計測。計測すれば改善できる!

現代人は水不足と言われているらしい。自分自身の生活をふりかえっても、水分をとるのはごはんのときだけということも少なくないので、水分摂取量を記録して改善しようと試みている。

iOSのヘルスケアアプリには水分摂取量を記録する機能があり、それを利用するアプリもいくつかある。また、アプリを使わなくても、iOSのショートカットのサンプルにも水分量を記録するものがあるので、それを使えば簡単に記録することができる。ただ、やっぱりインターネットで見たい！

というわけで、ヘルスケアアプリと同時にPixelaにも記録するようにした。

ヘルスケアアプリに記録する部分は、ショートカットのサンプルと同様。

選択肢については、普段使っているマグカップやタンブラーの容量を量っておいた。目安としては、マグカップや小さいペットボトルが300ml、多めのタンブラーが400ml、大きいペットボトルが500mlという感じ。たまに小さいカップを使うことがあるので、それ用に200mlを追加しておいた。登録する部分はそのまま、単位を間違えなければ大丈夫。

ちょっと難しいのはPixelaに送る部分。というのも、Pixelaの数字を更新する方法はincrement(decrement)とupdateの2つがあるが、たとえばincrementでは+200のようなことができないし(200回叩けばいいけど……)、updateではその日の合計をどうにかして計算しないといけない。

これは、ショートカットの中でヘルスケアアプリの情報を集計する機能を利用して、当日の摂取量を計算することにした。ここがこの仕組みで一番苦労した部分。

あとは、URLを叩く機能をうまく使えばできあがり。

出来上がった草がこちら。

kenchan/水分 | Pixela

Pixelaは、本家(?)GitHubと同様に相対的な大きさで色が変わるようなので、よく飲んだ日とあまり飲まなかった日が視覚的にもわかりやすくてとてもよい！

iOSのショートカットは、広く共有できるような仕組みがたぶんないし、トークンをハードコードしちゃってるので、同じようにやってみたい人はスクショを参考にしてください。

まだ1週間くらいだけど、若干体調もよくなったような気がしてる。特にお通じ面はだいぶよくなったように感じるので、今後も続けて経過観察していこうと思う。

11/13~11/14にペパボグロースキャンプ(通称PGC)に参加していた。

PGCとは

以前は「マネージャ合宿」という名前だったように記憶しているが、各事業部のマネージャ以上が集まって、泊りがけで来年の予算やその他についてディスカッションする会となっている。 ただ、「グロースキャンプ」という名前にあらわされているように、ペパボはもちろん、参加するマネージャ個人の成長のきっかけとなるような場となることも期待されているように思う。

今年のPGC

初日は各事業部から2020年の予算についての共有とディスカッション、その後に10年後世の中がどのようになっているかについてグループに分かれてディスカッションをした。

2日目は、初日のディスカッションの発表を聞いてから、事業部毎のグループで10年後に向けて自分たちが何をしていくかを話し合い、それを発表して終わりという流れだった。

PGCと私

CTLになった年かその次の年に初めて参加して、今年で2回目の参加となった。

数年ぶりの参加であるのと、事前にディスカッションのテーマは公開されていたので、できる範囲で事前準備をして参加した。また、直前にあんちぽさんから10年後の未来を考える上でのベースとなる資料が公開されたので、それらを読みながら足りないところを埋めたりした。

具体的には、次の本を改めて読み直したり、直前に買って流し読みをしたりした。

• [イラスト解説]ティール組織――新しい働き方のスタイル
• 未来に先回りする思考法
• プラットフォーム革命
• 5Gビジネス(日経文庫)
• SDGs入門 (日経文庫)

当日の様子

最初に、社長であるけんたろさんから全社方針についてのお話。今回のディスカッションのテーマである10年後の世の中につながる話もあり、なるほどーと思いながら聞いていた。また、最後にはマネージャ含む個々人の成長を期待しているという言葉もあり、PGCの狙いもよく理解できるお話だった。

各事業部の予算の発表では、各事業部の計画がわかってよかったのはもちろん、質疑の中では新しいチャレンジに繋がるような質問・意見があってとても参考になった。

その後の2つのディスカッションについては、普段話すことが少ないメンバーとたっぷりと議論できたので、視野を広げるという点についてはとても有意義だったと思う。

一方で、個人的には非常に反省点が多く、自分のふがいなさを感じる点が多かった。終わってから「ワークショップデザインとかファシリテーションとか偉そうに言ってたじゃん。あれはなんなん？（誇張）」と自分自身に語りかけていた。

それはそれとして、私たちのグループは「10年後に向けて何をするか」というテーマのワークで「10年後の カラーミーショップ大賞のオープニングトーク」という発表をした。ECプラットフォームとして、次の10年に向けた技術についても考えるきっかけとなったのはとてもよかった。

早速、翌日その方面に強い人に相談したが、まだアクションを起こせてないのでやっていくぞ！

おわりに

PGCには2回目の参加で、参加する前はいろいろな点で不安があったのだけど、参加してよかったなと思える会だった。

また、開催前に@june29が「PGCについて社内外へのアウトプットをしよう」という声かけをしていてとてもよかった。このエントリも、それに影響を受けて書いたものです！ありがとうございました！

これは GMO Pepabo Managers Advent Calendar 2019 - Adventar 1日目の記事です。

社内勉強会として、エンジニアリングマネジメント学習会というものを始めていたので、その目的や開催の様子を紹介します。

学習会の意義と狙い

ペパボでは2016年にエンジニアのキャリアラダーの一つとして、エンジニアリングマネジメントの領域が生まれ、CTLやTLが職務を全うすべく試行錯誤してきました。2016年当時は、国内ではエンジニアリングマネジメントという領域は現在ほど一般的なものではなく、muddydixonさん主催のエンジニアリングマネージャ勉強会(第1回 エンジニアリングマネージャ勉強会を開催し、因数分解でメンタリングをすることを発表してきました - PolyPeaceLight)などで少しずつコミュニティができあがりつつあるような状況でした。

そんな中、EM.FMというpodcastが始まったり、エンジニアリング組織論への招待やエンジニアのためのマネジメントキャリアパスなどが出版され、エンジニアリングマネジメントの体系だった学習ができる下地が整いつつあるように思います。

また、私自身も EOF 2019 - connpass に登壇・参加させていただいたことで、エンジニアリングマネジメントについて知る・議論する機会を作りたいという思いはより一層強くなりました。(その時の資料はこちら ペパボのエンジニアリングマネジメント一問一答 / engineering-management-q-and-a-in-gmo-pepabo - Speaker Deck)

エンジニアリングマネジメントという言葉が指し示すスコープや、使う語彙についての共通認識がないまま議論をしても生産的ではありません。そこで、前述の2冊の読書会を通して、ペパボにおけるエンジニアリングマネジメントの議論のベースとなる語彙を共有しながら、参加者の課題やこれからについて議論したいと考えています。

こんな人に参加して欲しい

前提として、エンジニアリングマネジメントは「エンジニアのマネジメント」でもなければ「エンジニアが知るべきマネジメント」でもありません。当然、職種や職位に制限はありません。以下に当てはまる人に参加してほしいと思っています。

• エンジニアリングマネジメントの知識を深めたい人
• エンジニア専門職(シニア、プリンシパル、シニアプリンシパル、TL、CTL)になりたいと思っている人
• 現在エンジニア専門職で、エンジニアリングマネジメントについて悩んでいる人
• エンジニアリングマネジメントについてうまくいった・いかなかった経験を共有したい人

※ 「エンジニア専門職」はペパボの職位制度で定義されているものです

進め方

社内で以前に開催されていた 「アジャイルサムライから学ぶ、友の会」と同じく、章単位で担当を決め、まとめを作ってきて発表するスタイルでやっています。なお、「エンジニアリング組織論への招待」の方が議論のベースを作るのに便利そうなのでこちらからはじめました。

開催の記録を残す場所としては、Notion.soを使っています。

事前に担当部分をNotionのページとして作成し、会の中ではそれを見ながら、気になった人はインラインでコメントしたりしながら進めています。

まとめ

今日は、ペパボの社内勉強会として開催している、エンジニアリングマネジメント学習会というものについて紹介をしました。まだ始まったばかりですが、エンジニアリングマネジメントに関わる人の横の繋がりを作る場として、続けていきたいと考えています。

人生で初めて「日記」や「日報」を書く習慣が定着したかもしれない - #june29jp を見てなるほどーと思い、日々の出来事や考えたことを吐き出す場をScrapboxに移して半月くらいが経った。

https://scrapbox.io/kenchan/

朝起きたら新しいページを作って、「ALT-t」を二回打つ(Scrapboxの現在日時を入力するショートカットをカスタマイズして日記のテンプレートを差し込む)のも慣れたものだ。今日一日のタイトルをどうするか、今日を表現する一枚の写真をどうするかを考えるのも日々の楽しみになっている。

iPhoneには‎Porter for Scrapboxを入れて使っているが、ショートカットの入力などもできるようになっていてとても便利。ありがとうございます！

Scrapboxのよさはリンクだと感じていて、文章が繋がっていく感覚はとても気持ち良く、内発的動機付けがうまくいっているように感じる。

一方で、お仕事ではNotion.soを使うようになった。先日、Notion導入の先導者である小田さんが書いた私たちがNotionを使う理由 - ペパボテックブログという記事が公開されたように、社内でも利用が広がってきている。

Notionのdatabasesという機能？データ構造？は本当に超強力で、ドキュメントにメタデータをつけることができ、それによるソートやフィルタリングがインラインでできるというのがとても気に入っている。「日報や議事録に欲しかったのはこれ！」という気持ちになっている。

databasesの紹介は Intro to databases。

しかし、Notionの豊富な機能や高い自由度を考えると、Notion職人のような人が生まれるであろうことは容易に想像できる。ただ、どういうツールであってもそのツールに精通した人がいたほうがいいとは思うので、それによって今よりも多くのドキュメントが残り、活用されていくならそれも歓迎すべきことかもしれない。

さて、このサイトはどうするの？というと、つぶしたりはせずに、自分にとってのWebの実験場としてこれからも使っていくつもり。

csexton/trailertrash.vim というvimプラグインがある。これは名前の通り、行末の余分な空白を視覚化したり(自動で)消したりすることができるもので長らく愛用していた。

最近、pythonやgoを読み書きする機会が増えてきたので(昨年比)環境を見直していたところ、dense-analysis/ale の組み込みのfixerで行末空白を削除してくれるやつがあることに気付いた。

設定はALEのREADMEにある設定例のままで、全ファイルに2つのfixerを設定するといいかんじに動いてくれた。

さらにおまけとして、let g:ale_fix_on_save = 1 と 907th/vim-auto-save、各言語のlintツールのfixerを全部有効にすると、書いてるそばからどんどんfixされてこれが令和時代の開発…という気持ちになったのであった。