あるゲームのアップデートの配信をいちはやく検知したい要件が発生したので、そういうツールを作りました。
現時点で、Steam と Epic Games と Microsoft Store に対応しています。事前に指定したゲームのアップデート有無を一定の間隔で監視し、アップデートがあった場合に Discord でメンションを飛ばして通知してくれます。
このツールは、詳細なパッケージやバージョンの生の情報を取得して監視 するため、既存のツールと違って、リリースノートの更新などを伴わない小さなアップデートでも検知できる のが大きな特徴です。
AWX の 18.0 から、インストールには AWX Operator の利用、すなわち Kubernetes や OpenShift 上へのデプロイが推奨されるようになりました。それ以前のバージョンでは Docker Compose ベースのデプロイも選択肢として用意されていましたが、現在では（開発やテスト目的を除いて）非推奨になっています。
とはいえ、気軽に使いたいだけ、シングルノードの可用性で充分、などの軽めのユースケースに対しては、すでに Kubernetes を使っている環境でない限り、AWX のためだけに Kubernetes 環境を作る（そして運用していく）のも少々大袈裟で大変です。かといって、公式のインストール手順 で気軽に試せる手段として紹介されている minikube は、プロダクション用途が想定されていない開発や学習用のツールのため、AWX をもう一歩踏み込んで日常的に使っていきたい場合には、逆に少し心許ないところがあります。
そんなわけで、ふたつの選択肢の間でほどよく使えるように、
感じのを、K3s で作ることにしました。
続きを読む
様々な興味と関心が脱線し続けた結果、OBS で Among Us を生配信するときに便利かもしれないオーバレイ表示を実現するツール、AmongUsOverlay ができました。例えばこんなことができます。
動作イメージは次のとおりです。
また、簡単な HTML と CSSで、上記のような画面を自分で簡単に作れるようになっています。例えば、上記のうち、ロビーでだけ表示される画像 は、次のたった一行の HTML で実現できます。
<img class="per_state only_lobby" src="<path/to/image>">
すぐに使えるデモ兼実装例も併せて配布しています。
続きを読む
Among Us でゲームの状況に応じて自動でミュート・アンミュートしてくれる便利なボットこと AutoMuteUs、ほんとうに便利ですよね。
簡単な使い方であればインタネットの各所に解説記事がたくさんありますが、実は AutoMuteUs には、さらに便利に活用できるいろいろな機能 が用意されています。
本エントリでは、他の解説記事ではあまり触れられていない機能 を中心に、AutoMuteUs をさらに活用するための情報 を紹介します。
なお、文中で 公式サービス と記載していますが、これは AutoMuteUs 開発者が直々に運営しているサービス というだけの意味であり、Among Us の公式サービス ではない ことは念のため明記しておきます。
続きを読む
NUC 8 のオンボード NIC は、ESXi 7.0 U1 から、組み込みのドライバではうまく認識されなくなっています。このため、NUC 8 の ESXi を 7.0U1 以降にアップグレードするには、これまでは対象のドライバ ne1000 だけ旧バージョン（7.0b 世代）にダウングレードする必要がありました。この目的で、以前のエントリ では、特定のドライバだけダウングレードしたカスタムイメージプロファイルの作成と、それを利用したアップグレードを紹介しています。
が、先日、VMware Flings でこの問題を解決できる新しいドライバがリリースされました。
このドライバは、ne1000 ではなく別の新しい e1000-community（と igc-community）として認識されるため、組み込みの ne1000 ドライバと一切競合せず、共存できる 点がポイントです。NIC は ne1000 でなく e1000-community を使って動作するようになるため、ne1000 のバージョンは気にする必要がなくなり、ダウングレードが不要 になります。
プライベート CA が ACME プロトコルを喋れれば、ACME クライアントを使った証明書の発行や更新を気軽に試せて便利です。
もちろん正規の証明書は得られませんが、その代わり、インタネットにポートを露出することなく HTTP-01 チャレンジや TLS-ALPN-01 チャレンジが行えます。公開認証局のリソース負荷やレート制限、CT ログなども気にする必要はなくなりますし、上位の DNS で応答をコントロールすれば、実在しない TLD の証明書も発行できます。
このエントリでは、気軽に実現できる方法のうち、実際に試した次の三パタンを紹介します。
ACME クライアントを試す目的では、ふたつめの Caddy 案が個人的にはいちばん手軽で小回りが効く印象でした。
続きを読む
Caddy の Automatic HTTPS で、DNS-01 チャレンジ に Azure DNS を利用するためのモジュールをリリースしました。
Among Us のゲームの進行に応じて Discord 上の各参加者のミュート・アンミュートを自動制御してくれるとても便利なボット、AutoMuteUs を初めて触りました。
動作にはボットのインスタンスを立てる必要があり、公開インスタンスが満員だったため、その場で自前サーバでのセルフホスト構成を作ったのですが、Docker でホストできることもあって、動かすだけならとても簡単です。Discord でのボット操作を一手に引き受けられるのであれば、インタネット上で公開する必要すらなく、LAN 内に配置するだけで済みます。
が、自分が居ないときでも仲間内で共同利用できるようにしたい場合、どうしてもボットのインスタンスはインタネット上でホストする必要があり、であれば少しでもセキュアにしたい感触があります。
そんなわけで、平文で行われている一部の HTTP や WebSocket の通信を、Let’s Encrypt の SSL 証明書とリバースプロキシ（Nginx）で暗号化したので、実装例の紹介です。
追記： Caddy でも実装 しました。エントリ末尾の追記部分 で紹介しています。
続きを読む
前回のエントリ で、AfterShokz のフラグシップモデルである Aeropex の音質を紹介しました。その中では、骨伝導であることそれ自体や防水・防塵のメリットは非常に大きい一方で、特に マイクの音質については厳しさがある 旨の記載をしていました。
根本的には Bluetooth のプロファイル（HFP）の仕様の限界があるので、有線のマイクと同等の高音質にはどうやってもできない（サンプリングレートが 16 kHz なので波形は 8 kHz で頭打ちする）のは仕方がないのですが、それにしても常用は厳しいと言わざるを得ない音質でした。
マイクの性能を重視するのであれば、Aeropex ではなく通話に特化した OpenComm の発売を待った方が良さそうです。
AfterShokz Aeropex の快適さと、音質の正直なところ | kurokobo.com
今回、この中でも言及している、通話に特化したモデルであるところの AfterShokz OpenComm を入手したので、主にマイクの性能の観点で、Aeropex と比較しました。
結果として、OpenComm のマイクは、Bluetooth 自体の仕様上の音質の限界はあるものの、Aeropex のそれとは比較にならないくらい充分常用できるレベルで音がよく、総じて満足できそうでした。
続きを読む