CloudNativeDaysTokyo2020でカンファレンスプラットフォームを開発した

9月8日と9月9日に開催されたCloudNative Days Tokyo 2020の実行委員として、カンファレンスプラットフォームを開発しました。とても楽しく、良い経験ができました。

もともと、実行委員としては去年の末ごろから参加して準備を手伝っていました。その時の主な担当はウェブサイトで、Hugoで作ったりしていた。あとはコンテンツ周りも関わっていたかな。

これまでカンファレンスで登壇はしてきたのですが、開催する側はやったことがなかったんですね。ミートアップくらい。なので、開催する側もやってみたくて参加ました。

結果として、これまでのオフラインイベントの開催は体験できませんでした。しかし、オンラインカンファレンスという新しい体験に関わり、とても楽しく良い経験ができました。

cndt2020は去年と同様オフラインイベントの予定だったのだけど、新型コロナウイルスの流行により、オンラインイベントに変更しました。そして、オンライン化にあたり配信などをどうやるかが課題となりました。

いくつかのサービスを検討したが、結果としては自分たちで作る決断をし、自分は決断した後、7月ごろから開発に参加しました(雑誌の執筆でバタバタしていた)。

技術スタックとしてはRailsとHeroku、Auth0、Vimeo、sli.doを使用。時間もあまりなかったので、外に出せるものは出した。そのため技術的にめちゃくちゃ難しい、というものはそこまでなくて(websocket周りの経験が無かったくらい?)、素朴にモデル設計やUIをどうやるかというところが難しかった。

開発メンバーはメイン2名、スポットで時々参加する人が数人で、デスマーチではないがやや大変だったかなという印象です。

カンファレンスプラットフォームとして大事にしたのは使い勝手で、プレイベントのrejektsで分かったUIの問題などを本番までに改修できたのはよかった。

本番のイベント中は負荷の監視をしたり参加者のフィードバックやアイデアを実装、デプロイしていました。素早い対応ができたのは自前実装の利点ですね。

今後、カンファレンスで同じプラットフォームを使うとなると破壊的変更が難しくなるので、エンジニアリングとしても難易度は上がりそう。UIをよりよくするためにはReactやVueのようなフロントエンドフレームワークが必要かもしれないという話をしていて、ここは新たなチャレンジじゃないかなと思います。

UserScriptを使って、Confluenceエディタのショートカットを一部無効にする

僕は日本語のかなに切り替える際、Ctrl-Shift-jを使っている。Ctrl-Shift-k、英字なら Ctrl-Shift-;だ。かな・カナ・英字を瞬時に切り替えられてとても便利なのだけど、最近Confluenceを使い始めて困ったことが発生した。それは、 Ctrl-Shift-jのショートカットがConfluenceのエディタにもあり、かなに切り替えるとエディタ側のショートカットも発動してしまうのだ。ショートカットとしてはJiraのチケット検索ダイアログを表示するというもので、これはこれで便利なのだけど僕としてはかな切り替えの方が優先順位が高い。複数のマシンでCtrl-Shift-jをかな切り替えに使っているし、そこは譲れない。

Confluence側の設定でショートカットを無効にできればよかったけどどうもそうはいかないようだったので、10年ぶりくらいにUserScriptを書いて制御することにした。

// ==UserScript==
// @name        Disable ctrl+shift+j in Confluence editor
// @namespace    http://repl.info/
// @version      0.1
// @description  Disable ctrl+shift+j in Confluence editor
// @author       Ryo Takaishi
// @include */editpage.action?*
// @include */createpage.action?*
// @run-at document-idle
// @grant        none
// ==/UserScript==

document.addEventListener('DOMNodeInserted', function() {
    if (tinyMCE) {
        if (tinyMCE.activeEditor) {
            tinyMCE.activeEditor.shortcuts.remove("ctrl+shift+j");
        }
    }
}, false);

tinyMCEを使っているので、このようにショートカットを削除すればOK。JavaScriptを知っているとこういうちょっとした改善をシュッとできるので便利ですね。

Kubernetes Meetup Tokyo #31で「入門!ClusterAPI」というトークをした

Kubernetes Meetup Tokyo #31 で「入門!ClusterAPI 〜k8sクラスターもk8s APIで管理したい〜」というトークをした。スライドは以下。

セッションの後にsli.doを使った質問に何件か答えたのだけど、時間の都合上回答できなかったものが2つあったのでこちらで回答。

[ClusterAPIについての質問] ClusterAPI用のリソース管理ってどうしてますか?

Anonymous

ClusterAPI用のリソースというのがいわゆるマニフェストと仮定すると、他のk8sマニフェストと同じ様に管理すれば良いと思う。結局はyamlファイルなので、同じノウハウを使うことができる。

clusterAPIはclusterのバックアップについても面倒をみますでしょうか

Anonymous

クラスターのバックアップについては、ClusterAPI自身は面倒をみない認識でいる。Workload Cluster、Management Cluster共にVeleroの様なバックアップ専用のソリューションを使うのが良いかと思う。

さて、今回はオンラインでの登壇だったのだが、初めての体験で緊張した。

  • 聴衆の顔が見えないので雰囲気が掴みにくく、トークのペース調整が困難
  • 今回はモニタ2枚で片方に共有用の画面表示、もう片方に発表者ディスプレイを表示したのだが、これだと運営側とのやりとりが完全にできなくなることに発表中に気づいた。チャットなどで何か話しかけられていても気づけなかったかもしれないので、発表者ディスプレイは表示しない様にするなど対策が必要だろう。
  • sli.doを使った質問の仕組みはとてもよかった。これまでの登壇で、一番質問をもらったかもしれない。嬉しい。その一方、質問内容について質問者に確認できないので適切に回答できたかどうかが掴みにくいという課題は感じた。

いくつか課題は感じたものの、概ね体験としてはよかった。自宅にいろいろ設備を整える必要があるのでハードルはやや高いが、場所を選ばずミートアップに参加できるのは良い。他の方のトークもとてもよかったし、楽しかった!

kubectl -o custom-columnsで、配列内の任意のデータを表示したい

kubectlの–outputオプションを使うと、表示するデータとヘッダを自由に指定できる。これを使うと、例えばどのノードがDiskPressureやMemoryPressureのStatusがTrueか?を一覧で見ることができる。

方法としてはこんな感じ。costum-columnsは <header>:<json-path-expr> の形式で、これをカンマで区切って指定する。.status.conditionsは配列なのだけど、フィルタすることも可能で、以下のようにすれば良い。

~ $ k get node -o custom-columns='NAME:.metadata.name,DiskPressure:.status.conditions[?(@.type == "DiskPressure")].message'

これで、Nodeの名前とDiskPressure Conditionのメッセージを一覧で表示することができる。-o jsonpath でフィルタリングしてもいいけど、ヘッダ付きで一覧表示できるとやはり便利。

4Kディスプレイやめました。そして曲面ウルトラワイドディスプレイの道へ

1年と少しの間27インチの4Kディスプレイを使っていて、最近32インチの4Kディスプレイを購入した。しかし、その数週間後に4Kディスプレイを使うのをやめて、34インチウルトラワイド ディスプレイに乗り換えたのでその辺の話を書きます。

27インチ4K

2019年1月に購入して使っていた。悪くはないけど、27インチで4Kは持て余す。スケーリングして使っていた。後、MacBook Pro 13インチモデルだと4KでスケーリングするとGolandのようなJetbrains製IDEが滅茶苦茶重くなる。レンダリング周りが原因らしく、eGPUを繋ぐと快適になるので購入して運用していた。しかし、eGPUは接続が切れるとeGPUを使っていたアプリケーションが全てクラッシュするのが不便。

32インチ4K

2020年4月に購入。どうにも27インチだと厳しいなと思い、画面サイズを広げることにした。とはいえこれもスケーリングして使用。悪くはないが、画面の端をみるのが結構大変で、効率よく使えていないように感じられた。27インチを縦向きにしてデュアルディスプレイ状態にしていたが、これも上の方や下の方はほぼ使えず。

34インチUWQHD

自分のユースケースだと4Kはフル活用できないなということで再度吟味してウルトラワイドディスプレイであるU3419Wを購入。解像度は3440×1440と4Kに比べるとかなり下がるが、横幅が広く曲面になっており画面をフル活用できるだろうという判断。3840×1600(WQHD+)とどちらにするか悩んだが、横幅が広すぎると考えUWQHDにした。今日届いたので設置したのだが、最初からこれにすればよかったなあとしか言えない。幅が広いのでウィンドウを3枚並べても十分使用できる。僕は開発している時IDE、ターミナル、ブラウザの3ウィンドウは表示したいのでちょうどよかった。曲面ディスプレイ、端の方は想像以上に見やすい。解像度は下がりドットピッチ は4Kに比べて広がるので文字などの滑らかさは損なわれるが、プログラミングなどの作業に支障が出るほどではないと感じた。

さらに、4Kでは無くなったのでeGPUがなくてもGolandが快適に使えるのでは?と思い、数時間ほどMacBook ProからUSB Type-Cケーブルで直接繋いでみている。今のところキビキビと動いているように思える。Type-Cの給電も90Wまで対応なので、MacBook Pro 16インチを今後買ったとしても問題なく使えるだろう。

そういうわけで、4Kディスプレイから曲面ウルトラワイドディスプレイに移行して快適という話でした。