在宅勤務でMTGをバックレないような仕組みを作る

以前から在宅勤務を行っているのだが、「会議が始まることを教えてくれる同僚が居ない」というのは在宅勤務における大きい課題だと思う。オフィスで働いていれば、ゾロゾロと移動するチームメンバーを見て気付けたり、声の掛け合いができる。在宅勤務だと会議に出てこないと「アイツ絶対寝てるだろ」思われるリスクが非常に高い。

会議のバックレを防ぐために私は、朝にその日に開催されるMTGの時間を調べiPhoneのタイマーをセットするという作業を行っていた。会議の予定は全て社内のグループウェアGaroonに登録されているので、そこから転記する。幸いなことに私は平社員なので1週間あたりの会議の数も少なく、この運用でもまぁまぁ上手く回っていた。ただ、日を重ねる毎に段々と面倒な気持ちが大きくなってきたので、仕組みで解決しようと考え始めた。

今回のピタゴラスイッチの全体像はこのような感じになる。極力コードを書きたくないという怠惰な気持ちが全面的に現れた設計となっている。

社内グループウェア Garoon

就業先の会社で予定管理に利用されているのが、Cybozu社のGaroonというグループウェアである。UI等に若干レガシーを感じつつも、5年も使ってるので使いにくいとは感じることは少ない。

ただ、予定が始まることをユーザに通知する方法は限られている。Windows,Mac,iPhone,Android向けに公式のアプリケーションが提供されているものの、なんとなく惜しい。

  • スマホ向け「Kunai」: 予定の取得を行うためにアプリを開いて更新ボタンを押す必要がある。毎日朝更新しても、突然昼あたりに入った会議には気付けない。とてもつらい。
  • PC向け「Cybozu Desktop」: Windowsデフォルトのトーストではなく独自の通知を出してくる。非常に稀にCPUを1コア分使い切って固まっている。(自分の環境だけ？)

Cybozu Garoon → Google Calendar

個人の予定管理にも利用しているGoogle Calendarに予定を転送すれば、普段の予定調整も楽になるはずだ。適当に検索してみると公式のドキュメントが見つかる。しかし初っ端の1行で既に終わっている。

こちらのサンプルプログラムは Java 9 以降では動作しません。 https://developer.cybozu.io/hc/ja/articles/204426680

さあどうしよう。作るか。

Go言語でGaroonのREST APIを叩くためのクライアントライブラリが提供さていた。オンプレ版に対応していなかったが、PRを投げたら爆速で対応して頂き感謝… こちらのライブラリを利用して、Garoonの予定をGoogle Calendarに転送するコードを記述した。Google Calendarに存在してGaroonに無い予定は問答無用で消されてしまうので、新規カレンダーを作成するのが良いはず。

社内のグループウェアへのリンクや、コメント欄も転記される。コメントにZoomのアドレスが貼っていればそのまま参加が可能だ。（何を隠せば良いのか分からず、とりあえずほとんど塗りつぶしておいた…）

dont forget meeting 2020 09 06 21 31 09

特に凝った事は行ってないが、最近流行りのGitHub Actions,Packagesを利用し、ついでにWorkflowsへの対応を行っておいた。別のリポジトリにて以下のようなWorkflowとアクセストークンを仕込めば勝手に平日の日中に同期が始まる。ログの事も考える必要はないし、ジョブが異常終了すればメールが飛んでくる。CIにも使えるし日常作業の自動化にも使えるGitHub Actionsは最高だ。CRONジョブもサーバレスの時代だ。

# .github/workflows/schedule.yml
name: schedule
on:
  schedule:
    - cron: '0 0-10 * * 1-5' # At minute 0 past every hour from 9 through 19 on every day-of-week from Monday through Friday.
  push:
jobs:
  run_sync:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: login
      run: echo ${GITHUB_TOKEN} | docker login -u ${GITHUB_ACTOR} --password-stdin docker.pkg.github.com
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    - name: build and push
      run: |
        docker run --env-file=.env -v $PWD/token.json:/token.json docker.pkg.github.com/kamijin-fanta/grn-gcal-sync/grn-gcal-sync:v1.0.0 /grn-gcal-sync --gcal-token-path=token.json sync

1回あたりのジョブ実行時間は15~30秒程度だった。Actionsのページで表示される実行時間は、課金対象の時間より少し長めに表示されている。実行マシンが割当されるまでに10秒～数分掛かるが勿論この時間は課金対象ではない。平日日中に1時間毎というスケジュールであれば、十分にGitHubの無料プランでもまかなえるようだ。

dont forget meeting 2020 09 06 21 19 32 dont forget meeting 2020 09 06 21 20 29

SmartBandでの通知

iPhoneへのイベント通知は、Google Calendarのアプリを設定するだけで出る。ただ、大体通知に気付かない。なので観測範囲で少し流行っているSmartBandのXiaomi Mibandを購入した。今はMiband 5が出ているようだが、自分が買ったタイミングでは4だった。

iPhoneへの対応に少々不安があったものの、特に問題は無く同期することが出来た。専用のアプリで設定することで、iPhoneの通知を全てスマートバンドへ転送できる。通知が有るたびにﾌﾞﾌﾞｯと少し震える。自分しか気付けないくらいの振動だ。

おわり

これで在宅勤務中にも会議をバックレない仕組みが構築できた。毎日何度か行っている作業がなくなったのは精神的にも楽になった。しかしSlackの通知が全部飛んできては1週間で精神を病みそうなので、通知の取捨選択は今まで以上に慎重に行う必要が有るように思った。

利用画像

続きを読む

WSL2でX11 GUIがスリープ時に消える

wsl2 x11 about

去年の暮に投稿した Windows10 WSLのターミナル事情 記事内で、WSL1でのシェルにVcXsrv+gnome-terminalを利用すると良いという記事を書きました。 状況はそれから少し変わっていて、

  • Windows Terminalがマトモになってきた(明るいテーマで常用するのはまだ難しい…)
  • 2020年5月にWSL2がリリースされ、WSL1の方法でX11転送を行うことができなくなった

という感じです。 WSL2時代のGUI環境の整え方をメモしておきます。

WSL2+VcXsrvの問題点

WSL1ではカーネルが共有されていたので localhost 等のネットワーク空間も全てが共有されていたが、WSL2では基本的にカーネルもネットワーク空間も共有されていません。Windows上からWSL2上のポートへのアクセスは localhost:80 等でアクセスできるが、逆のWSL2→Windowsの接続にはIPアドレスを指定する必要が有ります。

WSL1では単にVcXsrvを起動して export DISPLAY=:0 するだけでXウインドウが動作していました。これは localhost への接続を意味します。 WSL2では export DISPLAY=172.20.0.1:0 などとする必要があります。IPアドレスはWSL2側から見えるWindowsのアドレスを指定する必要があります。

このIPアドレスは、 /etc/resolv.conf からgrep,awkを利用して抽出する事が可能です。 .profile 等で以下のようなシェルを実行すれば、今まで通りVcXsrvを動作させることが可能です。

# .profile
# ref: https://github.com/microsoft/WSL/issues/4106#issuecomment-501885675
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0

しかし、しばらく使えば今までと状況が異なることが分かると思います。 WindowsをスリープするとX11転送したGUIが消えます。

理由を想像すると簡単で、単にTCPセッションが終了しているのでしょう。WindowsとWSL2上でのドメインソケット等が提供されていない現時点で、直接的にこれを解消するのは難しそうです。

WSL2+Xpraでスリープ後もウインドウを維持

そこで利用したのが、Xpraです。 複数OSで動作するスクリーン・X11転送ソフトウェアです。 TCPセッションが切断されてもGUIを再接続できるようです。GUI版のtmuxみたいな感じですかね。

リモート側のLinuxマシン・ローカル側のWindowsマシン、それぞれにXpraをインストールします。

リモートのLinuxマシンでXpraサーバを起動します。 追加でDISPLAY環境変数を指定し、以後起動されるGUIアプリケーションの接続先をXpraサーバに設定します。

xpra start --bind-tcp=0.0.0.0:10000 --daemon=yes :10000
export DISPLAY=:10000

Windows上のXpraを起動し、 Connect メニューよりLinux上で起動したXpraサーバへ接続します。この時に指定するホスト名は localhost で構いません。

wsl2 x11 2020 05 30 11 24 11

次にリモートのLinuxマシンで、適当なGUIアプリケーションを起動します。

gnome-help

wsl2 x11 2020 05 30 11 25 59

無事起動できました。試しにスリープ状態移行してもウインドウは維持されています。

参考資料

続きを読む