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