2020-07-02

またこっちで日記を書こうと思いリハビリ。何度リハビリしているのだろう。

先月読んだ アンガーマネジメント実践講座 - kenchan をscrapboxに書いた。内容の通り、特に目新しいものはなかったのだけど、いくつか語彙を増やせたので良かった。

社のブログでポストコロナの商売を支えるカラーミーショップのアーキテクチャ - ペパボテックブログを公開した。今までは、ほとんど発表原稿を書いていなかったのだけど、最近はほぼ全部書いている。言うことを整理できるというメリットが非常に大きいし、最近のリモート開催のカンファレンスは録画前提なので、その場のアドリブのリスクが高すぎるというのもある。

2020-07-01

下期が始まった!

本日辞令が出て、チーフテクニカルリードという職種はシニアエンジニアリングリードというものになった。名前が変わっただけでなく、社内規定上の職務が増えていたり、評価においてマネジメント領域(主にヒューマンマネジメント)が含まれるようになった。つまり、技術的なリーダーシップは今まで通りエンジニア専門職としての期待があり、それに加えてマネジメント職としても期待される部分が明確になったという感じ。引き続きがんばります。

そんな中、明日公開する予定の社のブログの記事をmasterブランチのレビューなしでpushしてしまい、失敗であった。そんなことをしてしまうSELがいるペパボを今後ともよろしくおねがいします。

生誕祭

本日6/21は、ミッフィーとウィリアム王子と私と息子の誕生日ですね!ちなみにウィリアム王子と私は同い年で、18歳と240ヶ月になりました。

今年は状況もあるのと、猫の体調がよくないのもあり、自分は動物病院、息子と奥さんは買い物をして、夜は家で過ごした。たまにはこういうのも良いかと思ったのだけど去年もほぼ同じだったw

息子はゲームのポケモン期が終わり、あつ森期に突入したらしく、ついに我が家にも森がきてしまった……あつ森、青いバラを作るゲームということしか知らないんだよなぁ……

今年は、津田沼に住んで20年目にして初めてル・パティシエ ヨコヤマでケーキを頼んだのだけど、晩ごはんでお腹いっぱいになってしまったのでまた明日。

いつものやつはこちら。くんさんのwishlist

新しい散髪様式

例のマスクが届き、新しい生活様式でやっていくぞという意気込みを込めて散髪に行ってきた。前回からは2ヶ月くらい。

美容院にも新しい生活様式が取り入れられており、マスクをしたままの散髪体験となった。マスクをしたままといっても、ゴムを耳にかけたままだと散髪にも支障が出てしまう。カットが始まる前にマスキングテープ的なものでほっぺたにマスクをくっつけて、ゴムを外してからカット開始という感じ。

入った瞬間は異様な光景びっくりしてしまったが、これが新しい散髪様式ということで受け入れていこうと思う。たしかに、長時間座ったままだし、人の入れ替わりが多いし、窓開けっ放しというわけにもいかないから何か対策をしないといけないんだろうな。

SCRUM BOOT CAMP THE BOOK 増補改訂版は入門書を兼ねたスクラムの基礎の本

実は、改定前の方は読んでいなかったので、ちょうどよい機会だと思って一通り目を通した。

本書は、漫画パートと文章パートを交互に繋ぎながら、はじめてスクラムマスターを経験する主人公(?)の悩みや課題、それらの解決方法や考え方を学んでいくことができる。漫画パートがおさえているポイントと文章パートの見出しが秀逸なので、これだけをざっと流し読みしてもよいと思う。

これからスクラムを始めようという人はもちろん、既にスクラムや何らかのアジャイルな開発プロセスを実践している人の頭の整理にもちょうどよいボリュームで、改めて自分たちがやっていることの意味や目的を再確認することにも役立つと感じた。

自分にとっては

  • リリーススプリントの必要性と、リリース作業としてそこに回すということは問題を先送りすることにもつながるという話
  • 開発チームのプロダクトバックログと同様に、スクラムマスターが対処する障害リストも可視化すること

の2つがあまり意識していなかったことだったのでとても勉強になった。

さて、この日記のタイトルにも書いた通り、本書は、入門書の皮を被った「スクラムの基礎」つまりスクラムというフレームワークの土台となる知識や考え方を紹介する本なんだと思う。もう既にスクラムを導入して組織にうまく適合させている人にとっても、明日からプロジェクトを少しでも良くするためのネタが手に入る素晴らしい本ではないだろうか。

最近、会社でも近くのチームでスクラムを導入してみたいという話があったので、そのチームのメンバーにおすすめしようと思う。

scrapboxの読書メモはこちら

P.S. 謝辞も更新されていてほっこりしました。

楽天でんきに切り替えて電気料金は下がったのか

こんばんは。電力自由化してますか?

去年の末に切り替えるだけでn%安くなるよという話を聞いたので、さっそく年初に申し込みをして3月2日から楽天でんきとの契約になっていた。 初月の電気料金が確定したという連絡があったのでみてみると、たまたま切り替え前後でほぼ同じ電力消費量だったのでちょうどよい機会と思い公開しておく。

  • 東京電力(2020-02)
    • 674kWh 19,102円
  • 楽天でんき(2020-03)
    • 678kWh 18,549円

(どちらも40A契約)

比べると3~5%くらい安くなっているだろうか。こんなもんかという額ではあるけど、楽天ポイントや楽天でんきを使っていることによる優遇とかを考えると、そこそこの差にはなってくるかな。

意識を高めて、クリーンエネルギーのところにお金を落とすというのが良いのだろうけど、まずは先立つものということで。

あと、これは会社概要などをみて気づいたんだけど、楽天でんきをやっているのは、会社としては楽天モバイルなんだね。結構以外だったので、見間違いかと思ってしまって利用規約など社名の出てるところを見て回ってしまった。楽天モバイルは応援したいのでちょうどよかったかもしれない。

はじめての自作キーボードとしてChoco60を作った

はじめての自作キーボードとして recompile keysさんのChoco60を作ってみた。

なぜChoco60にしたのか

私のキーボード遍歴を紹介すると、学生時代から仕事を初めてしばらくはJIS配列のMajestouchを使っていた。JIS配列だったのは、スペースの隣りに「変換・無変換」といったリマップしやすいキーがあったからだったと思う。その後、Kinesis Advantage 2を使っていた同僚の影響で、かれこれ10年くらいはKinesisを使っていることになる。

Kinesisに特に不満はないのだけど、会社の同僚で自作キーボードが盛り上がっていることもあり、自分も一度経験してみたくなったというのと、普段と違う配列やスイッチのキーボードがあってもいいかなと思ったので今回チャレンジすることにした。

自作キーボードキットは国内で買えるものでもかなりの数があるが、recompile keysは個人的にも応援したいし、HHKB配列は今まで一度も使ったことがなかったのでChoco60を作ってみることに決めた。また、一般的な配列であれば自分以外の家族が使うこともできるだろうという思いもあった。

買ったもの

買ったもの一覧

キットは、遊舎工房でChoco60キットを買った。

キースイッチについては、新型コロナ前に遊舎工房でスイッチを触った結果、リニアの静音が良いなと思ったのでGateron Silent RedをMKzealots Storeで買った。65個入を買ったら66個入っていてラッキー(?)だった。

キーキャップはKBDfansでPBT XDA 143keys Keycap setというのを買った。recompile keysにサイトにはChoco60のキーキャップを選ぶ際のポイントが挙げられているので、これを見ながら色々なサイトを見て回った。ただ、1万円未満ですべての条件を満たすものは見つけられなかったので、比較的キー数が多くて好みのデザインのものとしてこれにした。

また、XDAプロファイルのスペースキーがKPREPUBLICでバラ売りされているのを見つけたのでこれも買っておいた。

その他、電子工作用品やルブのための道具は、練習としてmeishiキットを作ったときに揃えておいたので今回のために買ったものはなかった。スイッチオープナーはDMM.makeで公開されているものを購入して使っている。

ビルド!

まず、キットを組み立てる前にすることはルブとモゲマイクロ対策。ルブのやりかたはキースイッチ ベストプラクティス – recompile keysの通りにやれば良いと思う。また、meishiキットにはなかったスタビライザーというパーツがあることに気づき、スタビライザーのルブの話 - 自作キーボード温泉街の歩き方を参考にルブをした。何度か外して組み直すを繰り返しながらパーツがぶつかる部分を把握して、少し多めにルブをした。この記事ではかなりベタベタにしているのだけど、これよりはかなり控えめに仕上げた。

作る過程は 分割HHKB配列が実現できる自作キーボードキットChoco60を買った - ぽよメモが丁寧にまとめてくれているので、ほぼこの通りに仕上げた。

なお、スタビライザーの下に絆創膏のテープ部分を貼ることで音対策になるというのを見かけたのでそれもやってみた。

スタビライザーの下にテーブを貼る

制作時間は計5時間くらい。前半は向きや方向があっているかを確認しながらだったので結構時間がかかってたと思う。

  • ルブが2時間ちょっと(名探偵ピカチュウを通しでみおわるくらい)
  • ダイオードのはんだ付けなどスイッチ以外をつける前まで2時間くらい
  • スイッチのはんだ付けから動作確認までが1時間ちょっと

完成!

この投稿をInstagramで見る

choco60 完成

Kenichi TAKAHASHI(@_kenchan)がシェアした投稿 -

まず、普段の仕事道具であるキーボードを作るという体験はとても良い。ファームウェアを書き込んで、恐る恐るPCにつなぎ、全てのキーが反応することを確認できたときの達成感はすごかった。作る過程で、少しではあるけどキーボードのしくみを知ることができるし、形や配列、キースイッチやキーキャップを選ぶということは、それらの違いを知ることにつながる。知らなかったことを知る機会と考えても作って良かったと思う。

ただ、この記事は完成したChoco60で書いているが、まだ慣れずにタイピングにかなり時間がかかってしまっている。ラップトップのキーボードとKinesisを切り替えても頭は混乱しないが、肩を開いてキーボードに手を置くと自然とKinesisの指使いになってしまうようだ。キーマップを考えるのも自作キーボードの醍醐味だと思うので、この形と自分にあったキーマップを考えていきたい。

最後に、素晴らしいキーボードを設計してくれたrecompile keysさん、それを販売している遊舎工房さんありがとうございました。

KinesisのWindowsモードにおけるWindowsキーは右Winのキーコードが割り当てられている

だから何?という話なんだけど、どうもこの違いによってWindowsのスナップ機能またはPowerToysに入っているFancyZonesの挙動がおかしくなる気がしている。

キーイベントについては、 https://w3c.github.io/uievents/tools/key-event-viewer.html を使って確認したのだけど、こんな感じでになっていた。92となっているところがKinesisのWinキーを押したときのキーコードで、91[Meta]となっているのが、ラップトップのWinキーを押したときのキーコード。

FancyZonesの詳細については、また別途書くつもりだが、とにかくこの機能が右Winキーのキーコードだとうまく動かない。

というわけで、どうにかKinesisから左Winのキーコードを入れれないかとマニュアルを見ていたら、Macモードにすると左右にCommandキーが割り当てられることに気付く。これなら左Winキーを入力できるのではないかと思いやってみたらビンゴ。自分は、親指のエリア両方にWinキーをリマップしているのだけど、両方とも左Winキーにすることで問題解決。よかったよかった。

Google Nest WifiをやめてASUS RT-AX3000 にした

Nest Wifiをmy new gear...したのが5/2で、10日後の5/12にRT-AX3000をmy new gear...した。間取りの都合上、Nest Wifi1台では家全体をカバーすることができなかったというのが一番大きな理由なんだけど、元々解決したかった問題なども記録しておく。

ネット環境

我が家の環境としては、J:COMのネットパックの1Gコースを契約している。ネットパックというプランだけど、ケーブルテレビの契約は無しで、回線とプロバイダのみの契約。ただ、このプランはインターネットには載っていなくて、よくわからんという感じ。機器込で月額5000円未満くらい。

J:COMの回線は、インターネットではすこぶる評判が悪い。しかし、自分の環境ではそれほど困ったことはなく、メールで問い合わせたらすぐに返事は来るし、故障や障害の対応についても不満はなく、そこそこ満足している。

ちなみに、我が家でJ:COMのネット回線を使っている一番の理由は、J:COMの回線がテレビのケーブルを使っているため、ルーターをテレビの近くに置けて便利というところ。光ケーブルの出てくるところが、間取り的にあまりよいところではないし、テレビの近くならゲーム機を有線でつなぎやすい。

肝心の速度については、日中は下りが400Mbpsで上りが80Mbpsくらい。レイテンシは20msecくらい出るので若干遅い方だと思う。夜のピークでもそれほど変わらず、家族がストリーミングしたりしてると下りが100Mbpsで上りが30Mbpsくらいまで落ちることがある。ただ、これくらい出れば日常生活やdocker pullで困ることはない。

調子がよいときは500Mbpsくらいでる

そうだ、ルーターを変えよう

今までは、J:COMの終端装置的なものがルーター機能もついているものだったのでそれをそのまま使っていた。しかし、今年の1月から在宅勤務が本格的に始まり、ビデオチャットなど動画をストリーミングする機会が増えると、途中で切れてしまったり明らかに品質が落ちるのが気になるようになった。この現象は、MeetでもZoomでも、奥さんのニコ生でも起きていたので、自宅の環境の問題だなと思い、まずはすぐに変えられそうなルーターを変えることにした。

そこで、たまたま奥さんのPixel 4を買ったときのクーポンの使いみちがなかったことから、とりあえずNest Wifiを買ってみるかと買ってみたのだった。

Nest Wifi、通信は安定するけど壁を挟むとすぐ2.4GHzになる問題

Nest Wifiが届いたので使ってみると、まず初期設定やスマホアプリの素晴らしさに感動し、さらにストリーミングで切れることはなくなって一時は優勝かと思ったけど、壁や扉を挟むとすぐに2.4GHzに切り替わってしまうという問題発生した。また、電波の届き具合も最初にあったルーターよりも弱く感じたので初期不良なども疑ったのだけど、Google Wifiをマンションで使った感想とオススメしない理由 - Koichiro, Sumi - Medium を見たら自分と同じ状況だったので、こういうものかと納得した。

こんにちは「RT-AX3000」

で、今使っているのがASUS RT-AX3000というやつ。これは、自分の用途と家の間取り的には不満がないという状況。良いところと良くないところを上げるとするとこんな感じ。見た目以外は満足している。

  • 良い点
    • 最初の不満であったストリーミングで切れなくなった
    • Nest Wifiの不満であった寝室や風呂場でも十分な速度がでるようになった
    • Wifi 6とWPA 3に対応してる
  • 良くない点
    • アンテナがのびてるデザインが好みじゃない

Wifi 6対応とかはあまり興味がなかったのだけど、ようやくエントリーモデルがで始めたところらしいので、価格.comなどで比較してこれにした。選んだポイントとしては、発売年月が新しいことと、WPA3対応くらい。あとはもちろん値段。

おわりに

というわけで、ここ最近のmy new gear...である無線ルーターについてまとめた。Nest Wifiでメッシュを組む手もあったのだけど、都会のマンションで壁を超えるためだけにメッシュ組むのかと思うとつらい気持ちになったので、思い切って買い替えたのであった。

ペパボテックフライデーでWordPressプラグイン開発について動画発表した

毎月第2金曜はペパボテックフライデー。今回は最近取り組んでいるカラーミーショップWPプラグインについて、開発環境周りの話をした。動画はこちら。

カラーミーショップWordPressプラグイン開発における最近の改善 - ペパボテックフライデー2020-05-08 - YouTube

ここ数日お仕事が立て込んでいたので、ゆっくり発表する余裕がないかもしれないと思い、事前に動画を撮っておいた。なんとか顔を出すくらいはできそうだったのでmeetを繋いだのだけど、「自分のPCから自分のYouTube動画を画面共有する」という今まで体験したこと無い発表体験ができたのでよかった。

撮影の環境などについては、こなれて来たらまとめようと思う。

GitHub ActionsでRailsアプリをロリポップマネージドクラウドにデプロイする

ロリポップ!マネージドクラウド(以下マネクラ)へのRails(Ruby)アプリケーションのデプロイは、Herokuと同じようにgit pushをすることでbundle installやDBのマイグレーションなどが自動で行われるようになっている。このウェブ日記もRailsで作っていて、そのデプロイをGitHub Actionsで自動化したのでそのやり方や試行錯誤の過程を記録しておく。

2020-05-02時点で利用している完全なYAML

「結論ははじめに」ということで、以下ようなYAMLと2つのsecrets(SSH_PRIVATE_KEYとLOLIPOP_REPOSITORY_URL)を用意すれば、masterへのpushをトリガーにしてマネクラにRailsアプリケーションがデプロイされる。

name: deploy

on: 
  push:
    branches:
      - master

jobs:
  deploy_to_lolipop_mc:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
      with:
        fetch-depth: 0

    - uses: webfactory/ssh-agent@v0.2.0
      with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
    
    - name: add known_hosts
      run: cat .github/workflows/known_hosts >> ~/.ssh/known_hosts
    
    - name: git remote add
      run: git remote add lolipop ${{ secrets.LOLIPOP_REPOSITORY_URL}}

    - name: git remote update
      run: git remote update

    - name: deploy
      run: git push lolipop HEAD:master

各stepを簡単に解説する。

  • checkout@v2にfetch-depth: 0を設定する。デフォルトでは1となっていてgitの履歴をとってこない設定になっているため、マネクラ側にpushする際にnon-fast-forwardと判定されてしまう。デフォルトのままにしてgit push -fとする手もあると思う。
  • webfactory/ssh-agentを使ってsshの秘密鍵を使えるようにする。(後述)
  • webfactory/ssh-agentはknown_hostsの管理はやってくれないので、リポジトリ上にknown_hostsをコミットしておいてそれを書き込む。(後述)
  • マネクラのgitリポジトリをremoteに追加する。
  • git pushのためには一度fetchしてくる必要があるのでremote updateする。
  • マネクラのgitリポジトリにpushする。

今回は、テストの実行などはステップに含めていない。デプロイだけであればこれくらいのステップ簡単にできる。

webfactory/ssh-agent でsshの秘密鍵をメモリ上で管理する

SSHの鍵認証しか許していないサーバにGitHub Actionsの中からアクセスするためには、GitHub Actionsが動作している環境に秘密鍵を置く必要がある。 GitHub Marketplace · Actions to improve your workflowをsshで検索するといくつかsshができるようにするActionsがあることがわかるが今回はwebfactory/ssh-agentを利用した。

sshとその秘密鍵を利用可能にするActionsは大別すると以下の2種類がある。

  • ssh-agentを実行する(webfactory/ssh-agent)
  • ~/.ssh に秘密鍵を書き込む

GitHub Actionsの実行モデルはよく理解できていないが、実行環境のローカルファイルシステム上に秘密鍵を書き込むよりはメモリ内に留められる方法のほうがよかろうと思い、このActionsを使うことにした。なお、公式のactions/checkoutでも秘密鍵を扱う仕組みはあって、ファイル名をランダムにして書き込むということをしている。

https://github.com/actions/checkout/blob/94c2de77cccf605d74201a8aec6dd8fc0717ad66/src/git-auth-helper.ts#L186-L197

Secretsに登録する秘密鍵とURLを準備する

デプロイに使う秘密鍵は、GitHub Actions専用のものを用意したほうが安全だろう。マネクラではキーペアを簡単に作成・登録できる仕組みがあるので、この機能を使ってデプロイ用のキーペアを作っておく。Ed25519の鍵ができるので強度も安心。

マネクラのコンパネでSSHのキーペアを作成する

ここで作成してダウンロードされた秘密鍵の中身をそのまま、GitHub側に SSH_PRIVATE_KEYというsecretsに登録すればOK。

GitHub側でのsecretsの登録

また、LOLIPOP_REPOSITORY_URLという名前で、マネクラのコンパネに書かれているリポジトリ「ssh://xxxxxx@yyyy.lolipop.jp:port/」を追加しておく。

マネクラでの接続先情報

Actionsの実行に必要な秘匿情報の追加はこれでおわり。

known_hostsをリポジトリに入れる

sshで初めて接続しようとしたときにプロンプトが出てくるアレのこと。何らかの方法でマネクラサーバのホストキーをknown_hostsにいれないとgit pushができないのだ。webfactory/ssh-agentのREADMEでは、actionsの中でssh-keyscanを使って書き込むか、この内容は秘匿情報ではないのでリポジトリにコミットするとよいと書かれている。このファイルの目的は、READMEにもあるとおり接続先のサーバが正しいものか、MITM攻撃にあっていないか、を検証するためのものなので、Actionsの中で毎回取得するよりは同じものを使ったほうが良いだろうと思い、コミットすることにした。

マネクラのコンパネからリモートリポジトリの情報を元に、以下のコマンドで実行することでホストキーを取得することができる。しかし、マネクラ側のSSHコンテナが起動していないと鍵がうまく取れないことがあるので、事前に別のターミナルなどでSSHをつないでおいたほうがいい。

ssh-keyscan -p <your port> -H <your ssh host>

上のコマンドを実行したときに、stderrに以下のような文字列が出てきたら、一度SSHしてから試してみるとうまくいく。

xxxx.mc.lolipop.jp: Connection closed by remote host

この問題のせいで、Actionsの中でssh-keyscanするのはひと手間掛かりそう。

おわりに

GitHub Actionsを使ったマネクラへのデプロイは、sshの秘密鍵をどう管理したらいいかわからずに二の足を踏んでいたのだけど、改めて学習し直して自分なりに安全な方法を考えてみた。マネクラでもこれで継続的なデプロイをGitHubだけで完結させることができるので、かなり便利ではないかと思う。

この方法でも危険な部分などあったら、是非コメントやツイッターなどで教えてください。

おまけ

テックブログでのロリポ関連の記事を読んだことで、この記事を書くモチベーションがあがりました。@antipopと@linyowsに感謝!

snapがうまく動かないのはmake 4.3とAppArmorの組み合わせのせいだった話

久しぶりにsnapで入れたmicrok8sを動かそうとしたら全然動かなくて、調べていくとAppArmorが動かなくなっていることに気付いた。

AppArmorの起動ログには、以下のようにcapabilityがおかしいというエラーがたくさんでていたのだけど、さすがに sys_admin がないというのはおかしい。

AppArmor parser error for /etc/apparmor.d/sbin.klogd in /etc/apparmor.d/sbin.klogd at line 17: Invalid capability sys_admin.

インターネットの海をさまようと、AppArmorのissue Make.rules fails to generate cap_names.h and af_names.h (#74) · Issues · AppArmor / apparmor · GitLab と、Gentoo側のissue 714158 – sys-apps/apparmor-2.13.4 -> ? fails at runtime if built with sys-devel/make-4.3をみつけて、なるほどとなった。

Gentoo側のissueの通り、make 4.3をmaskして4.2に落として、再度コンパイルしたら動くようになったのでよかったですね。

laymanからeselect-repositoryに移行した

数日前のGURUの記事に対してursmがmentionをくれたので早速移行した。

移行といっても、実際はemerge eselect-repositoryをするだけでよいので楽ちん。layman -leselect repository list -iを見比べて、有効になっているoverlayが同じだったらOK。

[11:20:33] in ~ via 💎 v2.7.1
❯ layman -l

 * dotnet                    [Git       ] (https://github.com/gentoo/dotnet.git                                              )
 * go-overlay                [Git       ] (https://github.com/Dr-Terrible/go-overlay.git                                     )
 * guru                      [Git       ] (https://anongit.gentoo.org/git/repo/proj/guru.git                                 )
 * jorgicio                  [Git       ] (https://github.com/jorgicio/jorgicio-gentoo.git                                   )
 * snapd                     [Git       ] (https://github.com/zigford/snapd.git                                              )


[11:23:36] in ~ via 💎 v2.7.1
❯ sudo eselect repository list -i
Available repositories:
  [99]  dotnet # (https://github.com/gentoo/dotnet)
  [148] gentoo * (https://gentoo.org/)
  [163] go-overlay # (https://github.com/Dr-Terrible/go-overlay)
  [168] guru # (https://wiki.gentoo.org/wiki/Project:GURU)
  [197] jorgicio # (https://github.com/jorgicio/jorgicio-gentoo)
  [276] pepabo @
  [349] snapd # (https://github.com/zigford/snapd)

eselect-repositoryの方は、privateなリポジトリもでて便利。よかったよかった。

see also: eselect/repository - Gentoo Wiki

procsのebuildをGURUにコミットした

Rustで書かれたモダンpsことdalance/procsのebuildファイルをGURUにコミットした。

Rustのツールをebuildにするのはcardoe/cargo-ebuildというコマンドを使うと一撃でできるのだけど、出来上がったebuildファイルにコメントがあるとおり、このツールではライセンスのリストがうまく出せないことがある。

cargo-ebuildが出力するebuildファイルのLICENSEの部分は、リンクする全てのライブラリのライセンスを集めてきて出してくれるのだけど、

  • 2つのライセンスが設定されている場合は両方でてくるが、実際にはどちらか一方となっているものも多い
  • portageのLICENSE名と必ずしも一致していない

という問題がある。

最終的にどういうライセンスにすればよいかは、onur/cargo-licenseというものを使えと書いてあって、これがメチャクチャ便利…すごい。これの出力をみながら、最小限のANDをとっていくとよさそう。

portageのライセンス名とのマッチングは License groups - Gentoo Wiki このあたりを見ながらマッチングしていけば良さそう。procsのebuildを作るにあたり困ったのは、BSD-3-Clauseというライセンスで、これはportage的にはBSDというライセンスだったので直したりした。

gnome-lightからの依存でClutterが入らなくなってた話

日課のうどんワールドとdepcleanの後、ChWick/gnomesome が動かなくなっているのに気付いて、GNOME Tweaksを見てみるとClutterがないよーというエラーが出ていた。

eix -e clutterを見てもたしかに入ってないし、/var/log/emerge.logを見るとdepcleanでも消えてることに気付いた。

とりあえず復旧させたいのだけど、Clutterを直接入れるのも違うよなーと思って、一番それっぽいgnome-shell-extensionsを入れてお茶を濁す子にした。

depcleanするときはよく画面を見ましょう。

Social Media Distancing

june29の Social Distancing と 2020 年 - #june29jp を楽しく読ませてもらった記憶も薄れないうちに、緊急事態宣言のニュースが飛び込んできた。

この発表内容およびスピーチについて、自分の立場と今の家庭環境においては、よいスピーチだと感じたし、内容についても引き続き頑張っていこうと思えるものだった。

さて、GMOインターネットグループの在宅勤務が始まったのは2020-01-27なので今月末で3ヶ月だ。この期間、インターネットを介さずに会話をした人は、家族、お隣さん、マンションの清掃の方、お店のレジの人、配達業者の方、これくらいだ。知人と呼べる人とはすべてインターネットでのみ繋がっている。自分と社会の接点はインターネットになったように思えた。

今の自分は、「インターネットでも繋がっている」と「インターネット繋がっている」の違いに戸惑っているのかもしれない。インターネット大好きだと思っていた自分が、「繋がり」の手段がインターネットに限定されたことによってストレスを感じているのかもしれない。

昨日、新型コロナウィルスと私と - 良いあそなすちゃんを読み、似たような思いをもっている人がn人いることを知って、心が少しだけ穏やかになった気がした。数ヶ月前なら許容できた言葉や、素直に受け止めることができたであろう言葉に、今は強く心を動かされてしまっている自分を許すことができるようになった気がした。

「今はしょうがないよ」。そう思いながら、青い鳥のアイコンを長押しして、左上に出てきた☓ボタンを押した。

NewRelicを使って特定のエラーの発生を検知する

NewRelicには、NRQL(New Relic Query Language)というクエリ言語を使って、NewRelicに溜まっている様々なデータを検索したりする仕組みがある。

NRQLについては、社内でもたまに勉強会が行われていて(New Relic勉強会をペパボ社内で開催しました - ペパボテックブログ)、うまく活用しているサービスも多い。

これとAlertsを組み合わせると、特定のエラーの発生や、エラーの傾向の変化でアラートを発生させることができるようになる。

NRQLとデータ構造

NRQLで扱うことのできるデータは NRQL入門 | New Relicのドキュメント あたりにまとまっており、アプリケーションのエラー情報は TransactionError に入っている。

さて、次はこのデータ構造がどうなっているかを調べる必要があるのだけど、それは New Relic data dictionary | New Relic Documentation を見るとわかる。もしくは、Insightsという機能で

SELECT * FROM TransactionError

といったクエリを流してみると、具体的にどういう情報が入っているかわかると思う。error.classerror.messageにどういった文字列が入るかは言語に依るところがあるので、実際のデータをみるのはどちらにしても必要だろう。

ドキュメントにはなさそうだけど面白いカラムとしてaggregateFacetというものがある。NewRelicやこの手のエラートラッキングシステムでは、類似のエラーをまとめる機能がだいたいついているが、このキーとなるのがaggregateFacetというカラムのようだ。今回は使わなかったが、このカラムのユニークカウントの傾向で、新しいエラーが起きているかを検知できそう。

NRQLでAlertsを設定する

TransactionErrorの内容はわかったので、これをアラートに適用していく。今回は「PHPを使ったアプリケーションで、WARNINGもNewRelicに通知しているが、E_ERRORが一定数を超えたときにアラートにしたい」ということをやった。

「Alerts poricies」がなければ新しく作り、あるものに追加するのであればそれを選び、「add a Condition」を選ぶと「Categories」の中に「NRQL」があるので選ぶ。

今回設定したクエリは以下の通り。PHPアプリケーションの場合は、error.classにはE_ERRORE_WARNINGといった文字列が入っていることがわかったので、これをつかってWARNINGを除いた単位時間あたりの数をアラートのしきい値にすることにした。

select count(*)
from TransactionError
where appName = 'your-app-name' and error.class not in ('E_USER_WARNING', 'E_WARNING')

アラートのしきい値の設定方法は以下の3つがあり、今回は「Static」を選んだが、他2つも便利そうなのでいつか使ってみようと思う。

  • 固定値の「Static」
  • 傾向を見る「Baseline」
  • 2つの値の関係をみる「Outliner」

実際に設定したのは画面はこんな感じ。時間や縦軸はぼかしてある。

NewRelic Alertsのスクリーンショット

おわりに

NewRelic(NRQL)を使って、特定のエラーの発生を通知する仕組みについて紹介した。エラーのトリアージが必要な場合もあると思っていて「新しい機能をリリースしたのでその機能に関係するエラーについてのみ知りたい」「特定の画面は特に重要度が高いので、通知のポリシーを分けたい」といったような使い方にも応用できると思う。

「エンジニアのためのリスクマネジメント入門」を読んだ

タイトルには「エンジニアのための」とあるが、3章の事例がエンジニアにとって身近な話題というだけで、一般的なリスクマネジメントの歴史から言葉の定義、関連する標準規格まで幅広くおさえられる書籍だと感じた。

特に、リスクコントロールの4つのパターン、「保有」「低減」「回避」「移転」という考え方を知ることができたのは、明日から役立つ内容でよかった。

仕事でもリスクの評価と対応について検討する機会があるが、リスクの評価については書籍のとおり「発生可能性」と「影響度」でマッピングしているものの、その後の対応をどうするかというのは迷うことがあった。この本のおかげで、より自信をもって論理的に判断できるようになったと思う。「リスクを保有する」と判断することもコントロールしていることなのだ。

また、3章のコラム的なところで、「防止的コントロール」と「発見的コントロール」という概念を知ることができたのも収穫だった。リスクに対処しようとすると、発生要因を潰す防止的コントロールを選択しがちだ。しかし、リスクの評価結果によっては、リスクが顕在化してからのダメージを軽減するための「発見的コントロール」でも十分のケースもあり、多くの場合は発見的コントロールのほうがコストが低いのだ。

このあたりも、なんとなくそういう選択をしていることはあったように思うが、これからはより意識的に選択することができるように思う。

本書を読んだことで、リスクマネジメントについての語彙や考え方を身につけることができ、今までやってきたことの意味を再確認できた。

エンジニアはもちろん、情報技術に関わる人で、リスクマネジメントを学ぶ際に最初に読む一冊としてとても良い内容ではないかと思った。索引や参考文献が数多く載っているので、より深く学びたいときのポインタも十分にあるのもおすすめポイントだ。

より細かい読書メモはscrapboxの エンジニアのためのリスクマネジメント入門 - kenchan にあるので、興味のある方はぜひ。

散髪ログ

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

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

highlight.jsからPrismなどWeb日記いじり

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をなんとかしたほうが良いと思うのだが、腰が重いのでまずはこのへんから。

Docker Desktop for Windows (Edge)でinotifyがうまく動いていなかった話(解決)

家のマシンを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にghqをインストールするにはGURUが便利

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

しかし、少し前に 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を書いていれていくぞ〜。

家の作業環境 2020/02

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

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

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

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

iOSショートカットでヘルスケアとPixelaに水分摂取量を記録する

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