blog.comame.xyz

MetalLB が ARP 応答を返していなかった問題に対処した

2024-01-13T00:00:00Z

MetalLB が ARP 応答を返してくれなくなったことにより、自宅サーバで動かしているすべてのサービスに一切接続できない状況になっていた。

ロードバランサによって IP アドレスは割り振られるが、通信はできないという状況になるため、サーバへの通信が一切通らなくなってしまっていた。

原因

直接的な原因は L2Advertisements を設定していなかったこと。背景としては、MetalLB の設定方法を CRD を使うように変えたときに、きちんとドキュメントを見なかったこと。

作業ログ

L2 (ARP) で経路を設定している。 Service に IP アドレスは割り振られているので、speaker が仕事をしていないのだろうと推測。普段使いしている Windows マシンから Get-NetNeighbor したところ、案の定経路がわからない状態になっていた。

https://metallb.universe.tf/troubleshooting/#general-concepts-1 に従って kubectl describe svc <svc> をしてみると、イベントがない状態だった。 speaker が公告しない条件は以下であった。

Service に有効な Endpoint がない
Service が externalTrafficPolicy=local であり、speaker の Node で Endpoint がない
L2Advertisements が speakers の Node にない
Kubernetes API が 'network not available' と言っている

上から順に確かめると、IPAddressPool は存在するが、L2Advertisements を設定していないことに気が付いた。

https://metallb.universe.tf/configuration/_advanced_l2_configuration/ を見ながら L2Advertisements を設定したところ、治った。

設定ファイルの変更履歴を見ると、ConfigMap から CRD に変更するときに、L2Advertisements を作成せず、IPAddressPool だけ作成していることが分かった。

2023年を振り返る

2023-12-30T00:00:00Z

今年なにをやったっけという振り返り。

開発

Go 言語

今年に入ってから初めて使い始めて、手になじんだ道具として扱えるようになってきたような気がしている。GitHub のレポジトリを見ると、大体 20 レポジトリ程度を Go 言語で書いたことになるらしい。

自宅サーバー

自宅でシングルノードの Kubernetes を運用し始めて 2 年が経過した。oauth2-proxy のようなものを導入したことによって、ちゃんとユーザーを識別してアクセス制御ができるようになり、ネットワーク境界によるアクセス制御をしている部分を大幅に減らすことに成功した。

DJ

Music Unity 2023 に行ったことをきっかけに、月に 1 回程度のペースで身内で DJ を練習するようになった。

本当に幸運なことに、39noPops 5th Anniversary のオープニング DJ をやる機会に恵まれた。本当に楽しく DJ をさせてもらうことができ、今後もイベントなどで DJ をやる機会があるといいなという思いがある。

お絵かき

少しだけ練習して、しばらく放置している。

あそび

スプラトゥーン3

大量にやる月とまったくやらない月があった。その結果、結局ウデマエは最高 S のままとなった。スシコラを握るようになり、対面力は多少鍛えられたと思う。

TRPG

今年はエモクロアで 8 セッション、CoC で 11 セッション参加した。自分が入り浸っている Discord サーバーで頻繁にセッションが行われており、片端から手を挙げていた結果かなりの回数になっていた。自分のプレイスタイルが確立されてきたような気がする。

2024 年はどうする？

お仕事

引き続きがんばるぞい！

DJ

多少背伸びが必要な目標として、3 つのイベントにのれるように頑張っていきたい。

お絵かき

上手くなりたいので、継続して練習できるようにしていきたい。

自宅サーバー

SoftEther で VPN を運用しているが、これを捨てられるようにしたい。開発サーバーへの接続は SSH が必要なため、うまいやり方を考える必要がありそう。
HDD の速度面での辛さを実感することが増えてきたので、SSD を導入したい。
現時点では PPPoE (IPv4) 前提で構築しているが、将来的にネットワーク構成が大きく変わる可能性がある。そうなったときにもインターネットに引き続き公開し続けられるような方法を模索したい。
デプロイされているアプリケーションの数が増えてきた。ノード数を増やせるように、既存のアプリケーションの設定を見返す必要がある。
ログ収集に問題があるので、ログを適切に収集・利用できる方法を模索したい。

39noPops 5th Anniversary

2023-12-25T00:00:00Z

イベント

39noPops 5th Anniversary
12/24
nagomix渋谷

セットリスト

ロジクール K380S を買った

2023-11-16T00:00:00Z

ロジクール K380S を買ってしまった。普段は US 配列キーボードを使用しているが、見た目がよくて衝動買い。

感想

ファンクションキーに謎の機能が割り当てられているが、Fn + Esc で Fn ロックできた
- VSCode でファンクションキーを頻繁に使うので、Fn ロックできないと使い物にならないところだった
キートップを見るとなぜか US 配列も印字されている
- ソフトウェアで US 配列として認識している用途を想定しているのか...
- そんなことあるんだ
ロジクールのキーボードは初めて購入したが、Bluetooth の接続が爆速で驚いた
- 接続時のストレスが少なくてよさそう
乾電池で動作する
- 処分だったり充電だったりのことを考えると、個人的には内臓バッテリーより乾電池のほうが好き
- 普段であれば乾電池はどこでも買えるので、急に切れてもまあ困らない
ところで自宅にはすでにキーボードがあるので、使いどころはあんまりないかもしれない...
- 机にキーボードが2台鎮座することに

日本語配列のキーボードを英語配列設定で使っている

2023-10-25T00:00:00Z

自分は普段英語配列キーボードを使用しているが、英語配列キーボードを選べる Windows ノートパソコンの選択肢が少ないので、ハードウェアは日本語配列を選び、OS の設定で英語配列として認識させている。

運用・感想

Ctrl + Space で IME 切り替えをできるように設定している
- 半角/全角 が ` で置き換えられてしまうため
\\ の物理的な位置が英語配列と異なるため、打ち間違えることがある
- Enter キーが縦長なので仕方ない
Enter キーが遠い、Backspace が小さい
- 割と嫌だが、ノートパソコンのキーボードを使う頻度が比較的低いので、諦める
右 Shift が遠い
- それなりに多用するキーだが、あまり気にならなかった

多少の妥協をすることによって、ノートパソコンと一緒にキーボードを持ち運ぶ手間を捨てられた。

Kubernetes のログを DaemonSet で収集する

2023-10-16T00:00:00Z

Kubernetes で動かしているアプリケーションのログを収集するものを DaemonSet で動かすようにした。今までは温かみのある手作業でノードにセットアップしていたので、大幅に改善された。

環境

kubeadm でセットアップしたクラスタ
コンテナランタイムは Containerd

ログを取得する

ログは /var/log/containers/xxx.log に吐き出されるので、tail などで内容を取ればよい。

DaemonSet で配置する

各ノードで 1 つずつ実行されてほしいので、DaemonSet で配置する。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log
spec:
  selector:
    matchLables:
      name: log
  template:
    metadata:
      labels:
        name: log
    spec:
    containers:
    - name: log
      image: xxx
      securityContext:
        runAsUser: 0 # /var/log/containers へのアクセスが必要なため
      volumeMounts:
      - mountPath: /var/log/containers
        name: containers
      - mountPath: /var/log/pods
        name: pods
    volumes:
    - name: containers
      hostPath:
        path: /var/log/containers
        type: Directory
    - name: pods
      hostPath:
        path: /var/log/pods
        type: Directory

CRAZYBUS の BGM を生成する

2023-03-30T00:00:00Z

ベネズエラの有名なゲーム CRAZYBUS の BGM を流す Web アプリを作った。Web Audio API を使っている。

https://comame.xyz/crazybuz

やり方

ソースコードは GitHub にある。

十二平均律の周波数を求める

十二平均律では、半音の周波数比がすべて同じであり、1 オクターブで周波数が 2 倍になることから、半音の周波数比は

\begin{eqnarray} r = 2^{\frac{1}{12}} \end{eqnarray}

となる。音程の基準を $ 440 \ \mathrm{Hz} $ として、上下 2 オクターブずつ周波数を算出する。

`OscillatorNode` で矩形波を生成する

const context = new AudioContext()
const oscillator = context.createOscillator()
oscillator.type = 'square'
oscillator.frequency.value = 440

のようにして矩形波を作成できる。

CRAZYBUS の BGM を作る

CRAZYBUS の BGM は、音程をランダムに 2 つ選び、BPM 360 で音程を変えながら混ぜればよい。

ちなみに

バスの走行音は A2、クラクションの音は G5 らしい。

Music Unity 2023

2023-03-27T00:00:00Z

Day 1 は羽田空港で、Day 2 は Twitch で見た。最高の 2 日間だったし、音楽って本当に楽しい。

ローカルで動かしている開発環境のポートをインターネットからアクセス可能にする

2023-01-23T00:00:00Z

開発マシンの 8080 番ポートに、インターネットから https://dev-8080.comame.xyz のような形でアクセスできるようにした。

やり方

サーバの sshd の設定をいじる

GatewayPorts の設定をいじっておく。これによって、サーバの 0.0.0.0 で転送されたポートを待ち受けることができるようになる。

GatewayPorts=clientspecified

ロードバランサーを設定する

https://github.com/comame/kubernetes-manifests/commit/8a9d189ed4a6f3158798531db015389cc0dc548c

サーバに対して SSH ポートフォワードをする

開発マシンからサーバに対して SSH 接続する。

$ ssh -R 0.0.0.0:8080:localhost:8080 <server>

感想とか

開発中のものにインターネットからアクセスする必要があったときにデプロイしなくて済むようになったので、開発体験がよくなった。ロードバランサが動いているマシンに対して SSH 接続をしないといけないので、スケールはしなさそう？

アクセス制御はいずれやりたい

Chrome のパスワード同期を直す

2023-01-06T00:00:00Z

Chrome のパスワード同期がされなくなる問題を解決した。環境は Windows 版 Chrome 108.0.5359.125 (Stable)。

手順を試す前に

手元の環境で解決した手順であり、すべての場合に適用できない可能性があることに気を付ける。

ブラウザのデータをバックアップする。ブックマークのエクスポートは「ブックマークマネージャ」から、パスワードのバックアップは chrome://settings/passwords と https://passwords.google.com の両方からエクスポートしておく。

発生していた問題

Chrome でパスワードが同期されず、パスワードマネージャが使えない状態になってしまった。chrome://sync-internals を見ると、components/sync/driver/data_type_manager_impl.cc で datatype error was encountered: Preexisting controller error on Sync startup のようなエラーが表示されており、パスワードの同期に失敗していた。

手順

同期時のフォーマットエラーなので、エラーになるパスワードを Google のサーバとローカルから削除すれば直るのでは、という発想。

インポートエラーになるパスワードを削除する

エクスポートしたパスワードの CSV を chrome://settings/passwords でインポートし、エラーになる CSV の行を削除する。

同期データの削除

Google のサーバに保存されている同期データを削除する。https://chrome.google.com/sync から削除する。

Chrome を使用しているすべての端末で、保存されたパスワードを削除する。手順はヘルプページに従う。

Windows を再起動する

Windows を再起動する。

パスワードをインポートして、同期を再開する

chrome://settings/passwords でパスワードをインポートし、Chrome の同期を再開する。

VRoid でアバターになろう！

2022-12-02T00:00:00Z

どういうこと

VRoid Studio でアバターを作って、kalidoface 3D で動かそう！

必要なもの

ブラウザ (少なくとも Chrome では動作確認済み)
OBS
VRoid Studio (アバターを自作するなら)

Kalidoface 3D を試そう

Kalidoface 3D とは、VRM 形式のアバターをブラウザで動かすことのできる Web ツールです。PC のカメラを使ったフェイストラッキング、フルボディトラッキングに対応しています。フェイストラッキングはかなり精度が高く、カメラに向かって正面を向いていれば、正確に瞬きや口の動きを捉えてくれます。サンプルアバターも用意されており、手軽に試すことができます。

まず、ブラウザで https://3d.kalidoface.com/ にアクセスすると、何もせずともサンプルアバターが表示されます。

アバターの切り替え (サンプルアバターも選べる)
設定ボタン (押すと画像左側の設定項目が表示される)
左からフェイストラッキング、フルボディトラッキングの切り替え
カメラの選択

これでアバターを動かすための準備は完了です！

次に、実際にアバターを動かし、さらに OBS にアバターを移すための準備をしていきましょう。

トラッキング開始ボタン
背景の切り替えボタン (押すと画像左側のメニューが表示される)
背景をグリーンバックにする

以上で Kalidoface 3D の準備は終わりです。次に、アバターをビデオ会議アプリに映すために OBS の設定をしていきましょう。

OBS の設定

アバターを表示させるためのソースとして、ウィンドウキャプチャでブラウザのウィンドウを取り込みます。このとき、「ウィンドウの一致優先順」は「ウィンドウのタイトルに一致する必要があります」を選択することをお勧めします。うっかり別のウィンドウが映りこんでしまう事故を防ぐためです。

次に、グリーンバックを切り抜きます。追加したウィンドウキャプチャに対して、「クロマキー」フィルタを追加します。今回はグリーンバックなので、「色キーの種類」は「緑」です。アバターの色合いに合わせて背景色を変える必要があるかもしれません。

あとは「仮想カメラ開始」を押し、好きなビデオ会議アプリで入力カメラを「OBS Virtual Camera」にするだけです。

VRoid Studio

VRoid Studio とは、3D モデリングの知識がなくとも、自分のアバターを作成することができるソフトです。VRoid Studio の公式サイトからインストールできます。

VRoid Studio からは VRM 形式でアバターをエクスポートでき、Kalidoface 3D を含む様々なツールでアバターを使うことができます。自分で作ることが難しくても、BOOTH などで購入した服に着せ替えることができます。

最後に

通話するときにカメラをつけるのが恥ずかしくても、アバターなら解決できます。自分のアバターを通じて、新たなコミュニケーションのきっかけになるかもしれません。

サンプルアバターを動かしてみるだけでも、あるいはアセットを着せ替えるだけでも、それは立派な表現の一つです。ぜひ皆さんも試してみてください。

トラブルシューティング

Kalidoface 3D でカメラが選択できない

接続しているカメラが選択できないときは、ブラウザの設定でカメラへのアクセス権を許可してください。

Kalidoface 3D のアバターが動かなくなる

Kalidoface 3D が動いているブラウザのタブが非アクティブになると、自動的に停止します。Kalidoface 3D のタブが常に見えるようにしてください。

また、長い時間動かしたままにしておくと、なぜかアバターが動かなくなることがあります。諦めてタブを再読み込みしましょう。

Mastodon インスタンスを立てた

2022-11-21T00:00:00Z

モチベーション

Twitter のスレッドや Zenn のスクラップのような書き心地で、適当に書き殴れるメモ帳が欲しかった。そういう気持ちがあったところに、Twitter 騒動で Mastodon の話題を耳に挟んだので、じゃあやってみるかの気持ちでインスタンスを立ててみた。

やったこと

Mastodon のインスタンスを Kubernetes の上にデプロイした
OpenID Connect でユーザー認証ができるようにした

Mastodon の構築

Mastodon の GitHub レポジトリにおいてある、docker-compose.yml が参考になった。docker-compose.yml をもとに Deployment を作り、その後はコンテナ内で RAILS_ENV=production bundle exec rake mastodon:setup を叩くだけだった (セットアップのドキュメント)。

SMTP サーバの設定は、localhost にしても特に問題は起きなかった。当然メール送信には失敗するが、失敗したメールのログは Sidekiq で閲覧できるので、個人用途ならあまり問題になることはなさそうだと思っている。

Admin ユーザーの作成を行うかも問われるが、このバージョンでは Redis への接続に失敗するので、あとから自分で作成する必要があった。ユーザーを作成するには、コンテナ内で bundle exec tootctl accounts create ... のようにすればよい。role=Owner を指定する必要があったが、Owner の値はまだドキュメント化されていない様子。

OpenID Connect のセットアップ

このバージョンではまだドキュメントが揃っていなかったため、該当する GitHub の Issue を頼りに設定した。メールアドレスの情報がないと認証が通らないため、 scope の値に openid,email,profile を指定しないと動かないようである。メールアドレスが OP から渡されなかったときでもエラーにせず、Mastodon 側で改めてメールアドレスの設定ができると良いのになあと思いながら設定していた。

得られたこと

例えばブログの草稿を雑に書きなぐることができるようになった
- スレッド
使い方によっては、その時考えていたことを時系列に従って思い返すことができそう

Kubernete Dashboard の認証を通す

2022-11-03T00:00:00Z

Kubernete Dashboard に OpenID Connect でログインしたかったというメモ。

まずは、Kubernetes Dashboard のドキュメントに従って、Service Account を作っておく。

要するに、Kubernetes の認証を通すため、特定の Service Account に対する ID Token を発行できれば良い。

https://kubernetes.io/ja/docs/reference/access-authn-authz/authentication/#openid-connect%E3%83%88%E3%83%BC%E3%82%AF%E3%83%B3 に従って、kube-apiserver を Relying Party として設定する。

ID Token に含まれるユーザー ID のクレームに、そのまま Service Account の名前を指定すると、認証できない。そこで、ユーザー名を system:serviceaccount:<namespace>:<name> のようにしてやると、サービスアカウントとして認証してくれる。

kubectl create token <name> で取得できる JWT を https://jwt.io などに放り込むと、そうなっていることを読み取れる。

ところで

ID Token を発行できただけなので、そのトークンをどうやって Kubernetes Dashboard に渡すかというのは別問題。例えばプロキシサーバみたいなものを立てる必要があるかもしれない。

どうせ自分ひとりしか使わないなら、type: kubernetes.io/service-account-token の Secret を作っておいて、そのトークンをブラウザに覚えさせておけばよいのでは？

PowerShellスクリプトを特権で起動する

2022-06-26T00:00:00Z

PowerShell スクリプト (.ps1) をコマンドプロンプト (あるいはバッチファイル) から管理者権限で実行したかった。

次のようなスクリプトを置いておく。

# sudo.ps1

start-process powershell -ArgumentList @("-ExecutionPolicy", "Bypass", "-File", $Args[0]) -verb runas

呼び出すときは次のようにする。

powershell -ExecutionPolicy Bypass -File path\to\sudo.ps1 path\to\script.ps1

SoftEther で自宅ネットワークを公開する

2022-06-18T00:00:00Z

やりたかったこと

自宅のネットワークに対して外部から直接アクセスするのが難しい (ポート開放できないとか) ときに、VPS 等を経由すればよいのではないかというアイデア。SoftEther のカスケード接続を使ってみる。

手順

VPS

チャージ残高が余っていたので、ConoHa で Ubuntu 22.04 のサーバを作成した。

SoftEther VPN Server をインストールする。ローカルブリッジの設定で TAP デバイスを作成する。作成した TAP デバイスに対して、自宅ネットワークと同じセグメントの重複しない IP アドレスを割り当てる。

自宅

SoftEther VPN Bridge をインストールする。VPS に構築した仮想ハブに対してカスケード接続する。必要なインターフェースにローカルブリッジを設定する。

動作確認

VPS から、自宅ネットワーク内にあるホストに対して ping を投げてみる。あとは適当に NAT を設定すればよい。

考えていること

今回は SoftEther を使用したが、これは要するに拠点間接続なので、他の VPN を使っても同様のことができるのではないだろうかと思っている。

Kubernetes のコンテナランタイムを containerd にする

2022-06-03T00:00:00Z

Kubernetes 1.24 で Dockershim が廃止となったので、コンテナランタイムを containerd に変更した。

手順

手順としては公式ドキュメントに従えば問題ないが、おそらく自分の環境依存で、いくつか気になるところがあった。

Changing the Container Runtime on a Node from Docker Engine to containerd

`kubectl drain <node>` が正しく完了しなかった

kubernetes-dashboard の Pod を削除できないことが原因で kubectl drain に失敗しており、手動で kubernetes-dashboard の Deployment を削除したところ問題なく作業を進めることができるようになった。

containerd の cgruop ドライバー

手元の環境では containerd config default で出力されるものをそのまま使用すれば問題なかった。[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] に SystemdCgroup = true を追記せずとも動作した。

`kubeadm upgrade apply v1.24.1` で警告が出た

kubeadm upgrade apply v1.24.1 を実行したところ、initconfiguration.go:120] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future のエラーが出力された。/var/lib/kubelet/kubeadm-flags.env には --container-runtime-endpoint=unix:///run/containerd/containerd.sock" のように URL スキームを記述しており、心当たりがないので気にせずアップグレードした。次回のパッチアップグレードでこの警告が消えるかどうか確認したい。

kube-apiserver に接続できない

この問題については原因が不明である。6443 番ポートが Connection refused となり、クラスタが全く機能しなくなってしまう問題が発生していた。iptables のルールを見たところ、すべてのパケットを DROP する設定になってしまっていた (おそらく Kubernetes の初期状態) ことが理由であると考えている。kube-proxy の ConfigMap を書き換え、 mode を ipvs に設定してみたところ、動作するようになった。正しい対処法かどうかは分からず。

ワコムのペンタブレットドライバが応答しないときの対処法

2022-05-29T00:00:00Z

発生条件が不明だが、たまに Wacom のペンタブが正しく動作しない (ドライバの設定が反映されていない) ことがある。

手元の環境

One by Wacom small
Windows 11 Pro (21H2)

対処法

WTabletServicePro サービスの再起動

タスクマネージャの「サービス」タブを開き、「WTabletServicePro (Wacom Professional Service)」を右クリック、再起動する。

ワコムのドライバを起動する

スタートメニューから「ワコムタブレットのプロパティ」を起動すると、ドライバが正しく再起動する。

Kubernetes を 1.24 にしたら壊れた

2022-05-16T00:00:00Z

Docker サポートが削除される警告をきちんと読まずに Kubernetes を 1.24 にアップグレードしたらクラスタが壊れたという話。

経緯

`kubeadm upgrade plan` に警告がでる

apt update をしたところ Kubernetes 1.24 へのアップグレードができそうだったので、kubeadm upgrade plan を実行したところ、次のような警告が出た。

[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
W0505 14:28:42.708621  126359 initconfiguration.go:120] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme "unix" to the "criSocket" with value "/var/run/dockershim.sock". Please update your configuration!
[preflight] Running pre-flight checks

なにやら Docker 周りの警告のようだが、自動でスキームを付けるといったことが書かれているし問題ないだろうとおもってアップグレードを続行した。

Pod がスケジュールされなくなる

アップグレードが終わった直後から、HTTP が繋がらないというアラートが大量に飛んでくる。kubectl describe pod をしてみると、どうやら Node に Pod をスケジュールできないことが原因の模様。

kubectl describe nodes をすると、なぜか NodeNotReady の文字が。

原因の特定

Kubelet がうまいこと動いていないのだろうと当たりをつけ、Kubelet のログを確認する。そうすると、なにやら次のようなエラーを吐いて起動に失敗していることが判明した。

Error: failed to parse kubelet flag: unknown flag: --network-plugin

/var/lib/kubeadm-flags/env を見ると、(当時のファイルが残っていないので定かではないが) 確かに --network-plugin=cni のようなオプションが付けられていた。

ここで、はじめに kubeadm upgrade plan したときの警告に含まれていた dockershim.sock やオプションに含まれる CNI から、そういえば Kubernetes が Docker のサポートを打ち切るというような記事を以前に読んだことを思い出す。

慌ててリリースノートを読むと、確かに 1.24 から Docker をそのまま使い続けることができないことが書かれていた。

解決

FAQ を読むと、Docker のまま今回のアップデートに対応する方法が書かれていることに気がついた。

思い切って containerd に差し替えることも考えたが、とりあえずの対策として cri-dockerd をインストールして解決することにした。

その後

Flag --pod-infra-container-image has been deprecated, will be removed in 1.27. Image garbage collector will get sandbox image information from CRI.

 "--pod-infra-container-image will not be pruned by the image garbage collector in kubelet and should also be set in the remote runtime"

のような警告も出ていたので、該当のオプションも消した。

教訓

リリースノートを読むこと (特にマイナーアップデートをするときは)
警告をおろそかにしないこと

当然のことである。

Ubuntu でアプリケーションアイコンを手動で追加する

2022-05-10T00:00:00Z

.appimage 形式の実行ファイルをインストールするとき、手動でランチャーに登録しないとならないようだったので、その手順をメモ。

~/.local/share/applications/<app>.desktop あるいは /usr/share/applications/<app>.desktop を作成し、次のような内容を書き込む。

[Desktop Entry]
Name=Application
Commenct=Comment
Exec=/path/to/executable
Terminal=false
Type=Application

Icon や Categories も指定できるようである。

参考

毎回お世話になる ArchWiki。

デスクトップエントリ-ArchWiki

Chromebook のセットアップ

2022-04-26T00:00:00Z

Crostini を入れて使えるようになるまで

100.0.4896.133 時点

Chrome OS の設定

画面ロックの設定

PIN を設定する
Smart Lock を設定する (「デバイスのロック解除のみ」)

日本語入力の設定

辞書とかスペースとか

ネットワークの設定

Wi-Fi
VPN

Crostini の設定

Crostini を有効にする

設定アプリから

日本語入力をできるようにする

$ sudo apt install fcitx fcitx-mozc

# 自動起動
$ echo "/usr/bin/fcitx-autostart" >> ~/.sommelierrc

# IME 切り替えキーの設定 / Mozc の選択
$ fcitx-configtool

# 辞書とかスペースとかの設定
$ /usr/lib/mozc/mozc_tool --mode=config_dialog

/etc/systemd/user/cros-garcon.service.d/cros-garcon-override.conf に追記する。

Environment="GTK_IM_MODULE=fcitx"
Environment="QT_IM_MODULE=fcitx"
Environment="XMODIFIERS=@im=fcitx"

fcitx-configtool で Mozc を追加するとき、Only show current language のチェックに注意

konsole のインストール (追記あり)

日本語入力とクリップボードがどちらも動いたので、konsole にした。Terminator も問題なく動作しそうなので、好みで選ぶ。

gnome-terminal は日本語入力が正しく動かず、xterm は起動が速くて好みだったがクリップボードが動作せず。

$ sudo apt install konsole

(追記) xterm のインストール

クリップボードを動作させることができた。他のターミナルよりも圧倒的に起動が速い。

$ sudo apt install xterm
$ echo "XTerm*selectToClipboard: true" >> ~/.Xdefaults

# .xsessionrc などは実行されなかったので仕方ない
$ echo "xrdb ~/.Xdefaults" >> ~/.bashrc

MTU の設定 (VPN 接続時)

Chrome OS 側で VPN を設定していると、Crostini からネットワークにつながったり繋がらなくなったりする。必要に応じて MTU を小さくする。

$ echo "sudo ip link eth0 set mtu <MTU>" >> ~/.sommelierrc

普段使ってるアプリケーションを入れる

VSCode
LibreOffice (なんだかんだあると便利)

参考

主に日本語入力周りで参考にした文献。

VPN 設定時の MTU について。

VPN and Linux help : Crostini

gnome-terminal で日本語入力ができない問題について。

Xterm について。

Acer Chromebook Spin 311 を買った

2022-04-25T00:00:00Z

Amazon.com で Acer Chromebook Spin 311 CP311-2H-C7QD を購入したメモ。

選んだ理由

ノートパソコン型である
本体サイズが小さい (A4 程度)
キーボードが US 配列
自動更新が 2027 年まで保証されている
技適が通っている (Amazon.com で購入したため)
USB Type-A とイヤホンジャックがある
USB-C での充電ができる
安価

予想以上に良かったこと

USB Type-A と USB-C が左右両サイドにあること

残念だったこと

画面の反射が強すぎる (アンチグレアフィルムを貼ることで解決)
画面がやや暗い

需要が少ないから仕方ないのだろうが、US 配列のモデルも取り扱ってほしいと、ノートパソコンを選ぶたびに毎回思う

手抜きで自宅サーバを運用する

2022-02-25T00:00:00Z

個人向け落ちてもどうでもいいようなサーバの超手抜き運用。

落ちたときに気づけるようにする

Google Apps Scirpt で HTTP リクエストを叩くだけのスクリプトを書き、1 分おきのトリガーを設定する。エラー時のメール通知を即時にしておけば、落ちた時にメールが飛んでくる。

(補足)

GmailApp.sendEmail() を使わずとも、失敗時に例外を投げておけば、トリガーの失敗が自動的にメール通知される。

やらかしたときに対処できるようにする

Chrome Remote Desktop を入れておく。これは間違えて SSH を落としても、ファイアウォールの設定を間違えても (多分)、端末がインターネットに繋がっていれば繋がる。

出先で VPN に繋がらなくなって唸っていたら、yasu0796 さんにアドバイスを頂いてこの方法に気づいた。

MetalLB の設定に右往左往した

2022-02-22T00:00:00Z

2 日間ほど MetalLB と格闘していた。

経緯

シングルノード Kubernetes クラスターのノードと、SoftEther を 1 つのマシンに同居させていた

このマシンには 2 つの NIC が生えており、片方は SoftEther のローカルブリッジを設定することで、リモートアクセスに使用していた。そのマシンに MetalLB を Layer-2 モードでデプロイしたところ、SoftEther のローカルブリッジに使用しているインターフェースが MetalLB によって割り当てられた External IP の ARP 応答を行うことで、VPN でリモートアクセスしている環境から Pod にアクセスできなくなる問題が発生した (これは既知の問題であり、SoftEther のドキュメントにも振る舞いが明記されている)。

FortiGate を買った

せっかく BGP を喋るので、MetalLB を BGP モードにしてみたかった。

BGP モードがうまく動かない

MetalLB の Configuration を参考に設定したところ、BGP は確立し、ノード内から External IP を使用して Pod と通信できるものの、ノード外からの通信が Pod に到達しない問題が発生した。一晩かけて慣れないパケットキャプチャとにらめっこすると、どうやらマシンの物理インターフェースまではたどり着いているものの、そこから Pod までルーティングされていないことが判明した。

ノード内からは繋がることから、Kubernetes のネットワークアドオンとして使用している flannel や MetalLB が致命的な原因ではいだろうと推測した。1 日かけて MetalLB の Issue を漁り倒し、物理インターフェースに割り当てられているサブネットとは違う IP アドレスでパケットを受け取っているため、応答先が分からなくなっているのではないかという素人の適当な仮説を立てた。

試しに ip route add でルートを設定してみたところ、自宅のネットワーク内からは Pod と通信できるようになり、良かった良かったと思いきや、別の問題が発生した。意気揚々とバーチャル IP を割り当ててインターネットから到達できるようにしたところ、なぜかホストが RST パケットを返し、Connection Refused エラーが出現するようになった。おそらく iptables の設定をいじれば直るだろうと思ったが、Kubernetes によって複雑な設定が書き込まれていたため、解決する気力を失って放り投げた。

BGP を使うとどのようにパケットが飛んでくるか予測しやすくなりそうで嬉しいので、しばらくしたらまた再挑戦したい。

SoftEther のローカルブリッジと ARP 応答問題

MetalLB の Issue を漁っていたところ、「L2 モードでインターフェースを指定したい」(https://github.com/metallb/metallb/issues/277) というものを発見した。どうやらインターフェースを指定するオプションを導入する方向に議論が向かっているようなので、今後どうなるかが楽しみである。

とりあえず、ワークアラウンドが提案されていた (感謝) のでそれを導入してみることにする。

ところで

WireShark とにらめっこしていたら昨晩は 3 時間しか眠れなかった。自宅でサーバを運用するとありとあらゆるところで何かしら問題が起きるので、それが楽しいところではあるなあと思う。

SoftEther のローカルブリッジのドキュメントを読み直していたところ、ローカルブリッジに使用するインターフェースは TCP/IP を無効にするように書かれていた。この設定を行ったときに MetalLB はどう振る舞うか検証したい。

Rust から C のコードを呼び出す

2022-02-07T00:00:00Z

Rust のコードから C を呼び出して Hello, world! するだけ。

手順

C のコードを書いてコンパイルする

適当にコードを書く。

// /project_root/lib/hello_world.c

#include "stdio.h"

void hello_world() {
    printf("Hello, world!");
}

これをコンパイルして、静的ライブラリにする。ライブラリのファイル名の先頭には lib を付ける必要がある。

$ gcc -c hello_world.c -o hello_world.o
$ ar crs libhello_world.a hello_world.o

Rust から呼び出す

link attribute でライブラリを指定する。libhello_world を使いたいので、#[link(name="hello_world")] とする。build.rs で cargo:rustc-link-lib=hello_world を出力してもよい。

// /project_root/src/main.rs

#[link(name="hello_world")]
extern {
    fn hello_world();
}

fn main() {
    unsafe {
        hello_world();
    }
}

参考 (the book), 参考 (the 'nomicon)

ライブラリのファイルがある場所を指定する。

// build.rs

fn main() {
    println!("cargo:rustc-link-search=native=/project_root/lib");
}

参考 (cargo:rustc-link-search)

動かす

$ cargo run

ちょっとした疑問点

the book には extern "C" { }、the 'nomicon には extern { } と書かれていたが、何が違うのか
- C を Rust から呼び出すときはどちらでもよくて、Rust を C から呼び出すときに影響してくる？
- https://stackoverflow.com/questions/44056461/difference-externc-vs-extern/44056776

感想

C のことはよくわかっていないが、思ったよりも簡単に動かすことができた。実際には cc を使うべきだと思われる。

大抵のことは既存の Crate が用意されていると思うので、自分で使うことは当分の間なさそう。

参考

自宅に k8s を構築した

2022-01-23T00:00:00Z

以前からやりたいと思っていた自宅シングルノード Kubernetes クラスターをついに構築し、とりあえず動くまで至った。

やったこととハマったところ

Kubeadm を使ったクラスタのインストール

基本的には公式ドキュメントの指示に従っただけ。

cgroup ドライバが Docker と Kubelet で異なっていた

kubeadm init をしても Kubelet が動いていないというエラーが発生した。Docker は cgroupfs、Kubelet は systemd を使用していたことが原因だった。/etc/docker/daemon.json に "exec-opts": ["native.cgroupdriver=systemd"] を追記することで解決。

Pod ネットワークアドオンがうまくインストールできなかった

まだ挙動をよく理解できているわけではないが、現時点では Kubeadm を使用すると flannel が使用される模様。kubeadm init --pod-network-cidr 10.244.0.0/16 のようにアドレスを指定することで無事に構築できた。

また、Flannel のマニフェストを自分で読み込まないといけないことに気づかず、 CoreDNS の Pod が Pending のままになってしまった。

MetalLB のセットアップ

type=LoadBalancer を使いたかったので、MetalLB のセットアップをした。IP アドレスの範囲を指定する場面で少しつまり、ルータの設定が必要なのかと右往左往していた。ネットワークに対する理解の浅さが露呈した (友人に聞いたら MetalLB は ARP を喋るということを教えてもらった)。最終的に、自宅内ネットワークのサブネット内の IP アドレスを指定してみたところ、なぜかうまく動いた。

Ingress のセットアップ

ingress-nginx を使用した。svc/ingress-nginx-controller に .spec.loadBalancerIP を指定して、IP を固定化することにした。将来的に困ることがあればまた考えることにする。

cert-manager のセットアップ

CloudFlare API を使用して、dns-01 で検証するようにした。ClusterIssuer を使って Ingress を別の Namespace に配置しようと思ったが、dns-01 用の Cloudflare API トークンを保存している Secret を見に行けずにチャレンジが失敗するので、結局 Ingress 用の Namespace を用意することにした。

Docker Registry を構築した

HTTPS でないとエラーが出るため、comame.dev をローカルサブネットに向けて、Let's Encrypt で証明書を発行した。Ingress に nginx.ingress.kubernetes.io/proxy-body-size のアノテーションを指定しておかないと、大きいイメージをアップロードするときに怒られる。

インターネットからアクセスすることは想定していないものの、Ingress はインターネットから見えてしまうため、Host ヘッダフォージェリを恐れて一応認証を設定しておいた。

Kubernetes Dashboard を設置してみた

今動かしているクラスターのバージョンは 1.23 らしいので、ドキュメントに書いてあるコマンドを愚直に叩くと、絶妙に API リクエストが失敗するものがデプロイされてしまう。GitHub のリリースページにバージョンごとの対応表があるが、1.23 の情報はなかったのでとりあえず最新の 2.4.0 をいれておくことにした。

いまのところ、Pod のログが見れて便利だな程度なので、将来的にどうするかは検討したい。

考えている運用方針

HTTP サーバは Ingress を、それ以外は type=LoadBalancer の Service に loadBalancerIP を直接指定して IP を固定化してしまおうと考えている。Node を増やすつもりはないので、当面の間は困らないだろうと妄想している。

やりたいこと

というよりやらないといけないこと

cert-manager の導入 (やった)
証明書の自動更新

マニフェストのレポジトリ

https://github.com/comame/kubernetes-manifests

Chromebook は気軽に使えて良い

2022-01-07T00:00:00Z

去年の春に Lenovo Chromebook Duet を購入した。

なぜ買ったか

以前 ASUS Chromebook Flip C100PA を 2 年ほど使用していたことがあり、Crostini が使える端末であれば気軽に持ち出せる端末として便利だと思い、Chromebook を買うことにした。

とにかく気軽に使いたかったので、5 万円以内、小型サイズ (11 インチ以下)、タッチパネル対応ありの条件で端末を探したところ、キーボードを取り外せる Chromebook Duet が良さそうということになった。

なぜ Chromebook なのか

箇条書きでずらっと挙げていくと、次のような点を気に入っている。

Crostini があるので自宅のパソコンに接続すれば重たい作業でもできなくはないこと
Chrome OS はスペックが貧弱なコンピュータでも快適に動作すること
バッテリー持ちが良い (端末が多い) こと
ソフトウェアアップデートなどのメンテナンスをほぼ気にする必要がないこと
あくまでパソコンであること (Windows や Mac ほどの拡張性は無いにせよ)

実際使ってみてどうか

Chrome OS の使い心地は以前 Chromebook Flip を使用したことがあるので、ほぼ予想通りであった。Chromebook Flip では使用できなかった Crostini については、GUI アプリケーションが使用できることを知らなかったため、思っていたよりも幅広く使えることに気がついた。VSCode の Remote SSH で自宅のパソコンに繋いだり、GIMP でちょっとした画像の加工をしたりしている。

Chromebook Flip 固有の部分について、個人的にはキーボードが取り外せて便利だった場面はあまりなく、鞄の中でキーボードが外れたことで電源が入り、使いたいときに電池が切れている事故が何回かあった。それ以外に不満点はなく、常に持ち歩くようにしている。バッテリーは重たいことを長時間しない限り 1 日は余裕で持ち、10.1 インチと小柄なのでどこにでも持っていける機動性が気に入っている。

Chromebook から Windows のフォルダにアクセスする

2021-12-20T00:00:00Z

Chrome OS には、Windows のファイル共有 (SMB) にアクセスできる機能が標準で組み込まれている。従来 (2019 年頃まで？) は拡張機能をインストールする必要があったようだが、現在は「ファイル」アプリで初めから使用できるようになっている。

ファイル共有を有効にする

Windows で、ファイル共有の設定をする。共有したいディレクトリを右クリックし、「アクセスを許可する」>「特定のユーザー」と進む。「ネットワークアクセス」ダイアログが開くので、共有したいユーザーを設定し、「共有」をクリックする。Windows 11 では、右クリックメニューの「その他のオプションを表示」をクリックすると「アクセスを許可する」の項目が表示されるようになる。

次に、アクセスするためのネットワークパスを調べる。先程共有の設定をしたディレクトリのプロパティを開き、「共有」タブへ移動する。「ネットワークパス」という項目を控える。表示されるネットワークパスは \\[コンピュータ名]\[フォルダ名] という形式になっている。

必要に応じてファイアウォールやルータの設定をする (SMB のポートをインターネットに公開するのはやめたほうが良いと思う)。

Chromebook から接続する

Chromebook の「ファイル」アプリを開き、右上の三点メニューをクリックし、「サービス」>「SMB ファイル共有」を開く。

「ファイル共有 URL」には Windows に表示されたネットワークパスを入力する。ただし、「共有フォルダのマウントエラー。指定された共有フォルダがネットワークで見つかりませんでした。」のエラーが表示されるときは、ネットワークパスを \\[Windows マシンの IP アドレス]\[フォルダ名] と置き換える。例えば、Windows に表示されたネットワークパスが \\Desktop-ABC\Share で、Windows マシンの IP アドレスが 192.168.0.100 であるならば、\\192.168.0.100\Share と置き換える。

「ユーザー名」には Windows のユーザー名を入力する。スタートメニューやログインがメインに表示されるフルネームではなく、「コンピュータの管理」の「ローカルユーザーとグループ」>「ユーザー」に表示される「名前」を入力する。(Windows の仕様に詳しくないので不正確な可能性があるが、この名前はユーザーディレクトリのディレクトリ名と同じだと思われる)。

「パスワード」には Windows のパスワードを入力する。Microsoft アカウントでのサインインにしているときは、Microsoft アカウントのパスワードを入力する必要がある (PIN ではない)。

感想

Chrome OS が SMB に対応していることに気付くまでは WSL 2 に立てた SSH サーバに向けて Crostini から SFTP でファイルの転送をしていたので、作業が大幅に効率化されることになり、Chromebook の機動力をより活かすことができるようになったと思う。

Hyper-V の Windows 11 で WSL 2 を実行する

2021-09-23T00:00:00Z

Hyper-V にインストールしている Windows 11 で WSL 2 を動かすことができた。

手順

1. Hyper-V の管理機能を有効にする

「Windows の機能の有効化または無効化」で Hyper-V > Hyper-V 管理ツール > Windows PowerShell 用 Hyper-V モジュールを有効にする。

参考: https://docs.microsoft.com/ja-jp/skypeforbusiness/troubleshoot/server-install-or-uninstall/get-vm-not-recognized-during-install-cloud-connector

2. Hyper-V での入れ子になった仮想化を有効にする

PowerShell で以下のコマンドを実行する。<VMName> は Get-VM で確認できる。

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

WSL 2 は Hyper-V を使用しているため、この方法で仮想マシン内で仮想環境を使用できる。

参考: https://docs.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/user-guide/nested-virtualization

Windows 11 の Insider Preview を Hyper-V でインストールする

2021-07-04T00:00:00Z

前提条件

Windows 10 Pro を使用していること (Hyper-V を使用するため)
ホストが Windows 11 の動作要件を満たしていること (満たしていなくとも動作する可能性はあるが)

手順

Windows 10 の ISO を用意する

現時点では、公式に Windows 11 の ISO を直接入手することができない。なので、Windows 10 をインストールした後、Windows Update で Windows 11 にアップグレードする。

Download Windows 10 Insider Preview ISO - microsoft.com からダウンロードするか、あるいは Media Creation Tool で ISO イメージを作成する。

Hyper-V の仮想マシンを作成する

Windows 11 の動作要件を満たした仮想マシンを作成するため、設定を少し変更する。以下の項目以外については、自動的に Windows 11 の動作要件を満たすと思われるが、適宜変更が必要かもしれない。

「セキュリティ」の「トラステッドプラットフォームモジュールを有効にする」にチェックを入れる
メモリを 4 GB 以上割り当てる

Hyper-V のグラフィックは WDDM 1.3 にしか対応していないはずだが、今回はインストールを進めることができた。

Windows 11 にアップグレードする

Windows Insider Program を Dev チャンネルにすると、Windows 11 のアップデートを受け取ることができる。

ところで

WSL 2 がきちんと動作するかどうかテストしてみたかったが、Hyper-V 内部で仮想化をすることができないようで、インストールに失敗した、残念。

ピクシブのインターンに参加した

2021-04-01T00:00:00Z

ピクシブの春インターンに参加しました。インターンから少し時間が経ってしまいましたが、せっかくなので記事として残しておこうと思います。技術的な要素は控えめ。

どんなインターンだったか

これ

約 2 週間、「pixiv リクエスト」のチームに参加しました。自分の場合は Web フロントエンド (React) メインで必要に応じて PHP も書く、といった内容でした。

応募したきっかけ

そもそも pixiv は日常的に見ているサイトだった
最近の PWA 化や (招待制だから参加はできなかったけど) PIXIV DEV MEETUP などで技術面でも興味があった

やったこと

ユーザーによる直接の反応が目に見える部分の実装をタスクとして与えていただきました。

「リクエスト」への作品投稿時に行動を促す / 褒めるモーダルの作成

~~この機能の良いところは、Twitter でエゴサすると実際にこの機能を使ってもらっているのを見れる点です。~~ このモーダルがあると、「リクエスト」に作品を投稿したときに SNS にシェアする敷居が下がったり、受けたリクエストをプロフィールページに公開できたりします。

「リクエスト」の詳細ページの OGP をリッチに

従来は、「リクエスト」の詳細ページを Twitter などにシェアすると、「リクエスト」のロゴがプレビュー画像として表示されていました。そこで、その画像を「リクエスト」に投稿された作品やリクエスト文などをプレビューするように変更しました。~~これまたエゴサできて嬉しい~~

インターン期間中にいいなと思ったこと

生活習慣が圧倒的に改善されたこと

朝 10 時から始まるので、何としてもそれまでに起きなければいけませんでした。朝 6 時まで Discord でグダグダして 16 時に起きる、素晴らしく規則正しい生活習慣から脱却できました。

チームの方に気軽に話せること

常に Discord に繋がっているので、疑問点などがあったときに気軽に相談できました。真面目に仕事をしつつ雑談もするといった、仕事も楽しむという雰囲気を味わうことができました。

人のコードを読む機会を得られたこと

既存のプロジェクトに参加したため、元々あるコードを読みながら自分の実装を進める必要がありました。個人で趣味開発をしていると中々得られない経験だったと思います。

インターンでの成果を発表する機会を得られたこと

インターン期間の最終日に、インターン中の成果をスライドで発表する時間がありました。発表するときは緊張で震えていたのですが、優しく受け入れてくださいました。最後に成果を発表することで、自分のやったことはどのような意図があったのか、どのような結果となったのか、何を学ぶことができたかを振り返ることができました。

普段の業務に飛び込めること

チームの皆さんが普段使っているツールを使って、定例ミーティングに参加して...など、通常の業務に飛び込むことができました。本当に動いているコードに手を加えますし、本当に自分の作ったものがリリースされますし、本当にユーザーに使ってもらえますし、本当にアナリティクスの数字も出てきます。すごい。

インターンを終えてからしみじみと思ったこと

関わる人のことを考えるということ

サービスを使うユーザーのことを考えるのは当然です。しかし、ただユーザーのことだけを考えていれば良いのではなく、サービスを運営する立場としての嬉しさも追求していかなければならないということをふと思いました。

最後に

皆さん忙しい中インターンとして参加させていただいて、本当にありがとうございました！初インターンでこんなに楽しむことができて幸運でした。

(おまけ) pixiv の p は小文字

Pixiv だと思ってました。

Softether を systemd のサービスとして起動する

2021-03-16T00:00:00Z

Ubuntu 20.04 で Softether を systemd のサービスとして登録するには、/etc/systemd/system/vpnserver.service に次のように記述する。

Softether のドキュメントをほぼ移植しただけだが、今回はロックファイルの作成はしていない。

[Unit]
Description=Softether VPN
After=network.target

[Service]
Type=forking
User=root
ExecStart=/usr/local/vpnserver/vpnserver start
ExecStop=/usr/local/vpnserver/vpnserver stop
Restart=always

[Install]
WantedBy=multi-user.target

自分の作業環境のセットアップ

2021-02-12T00:00:00Z

めも

Windows

インストールするアプリケーション

CubePDF Utility
foobar2000
GIMP
Google Chrome
Google Drive
iTunes
Microsoft Visual Studio Code
Mozilla Firefox
OBS Studio
PowerToys
VLC media player
Windows Terminal

やること

WSL をセットアップする
各種設定ファイルを入れる
スリープ設定をいじる
高速スタートアップをオフにする
電源ボタンを押したとき、休止状態にする
ローカルグループポリシーエディター (gpedit.msc) で Aero Shake を無効にする (ユーザーの構成 > 管理用テンプレート > デスクトップ)
WSL 2 のポートを公開できるようにする
適当にエクスプローラーの設定をする

自作 PC を組んだ

2021-02-11T00:00:00Z

去年の年末あたりにパソコンを組んだ。

モチベーション

ノートパソコンには Macbook Pro 2018 をメモリ 16 GB、SSD 512 GB 積んだものを使用しているが、結局 Bootcamp しか使用していないし、グラフィック性能が足りない場面もあったので、自宅用にデスクトップマシンを組むことにした。

パーツ

ある程度の性能を確保しつつ、低予算を重視した構成で選んだ。

マザーボード

MSI B460M PRO-VDH WIFI

LGA1200 で MicroATX で Wi-Fi がもともと付いていて安いもの。Amazon で 12000 円程度で購入した。

CPU

Intel Core i5-10400F

今までノートパソコン向けの Core i5 のスペックで特に不満はなかったので、2 万円以下の価格で購入できる Core i5 にした。AMD ではなく Intel にした理由が特にあるわけではなく、今までのパソコンの CPU がすべて Intel だったため。

ビデオカード

MSI GEFORCE GTX 1660 SUPER AERO ITX OC

今までのパソコンではゲーム性能などが基本的に期待できなかったため、とりあえずゲームや VR が動くもののうち、安いものを選んだ。結局ゲームはほとんどやらないので、より高いグレードのものは必要ないと判断した。

メモリ

TEAM ELITE PLUS U-DIMM DDR4

はじめは 2 本刺し (16 GB) で、後から 4 本刺し (32 GB) に増設した。Amazon で適当に安かったものを選んだ。赤い。

SSD

Crucial P1 500GB

Macbook Pro の 500 GB では特に不満はなかったので、同じ容量の 500 GB を選んだ (後から HDD を増設した)。

電源

Thermaltake Smart 500W

ビデオカードの推奨電源ユニット容量が 450 W だったので、500 W の電源にした。配線するときはプラグイン式にすればよかったと思ったが、結局ペリフェラル電源以外のケーブルを使うことになったので気にしないことにした。

ケース

Thermaltake Versa H17

MicroATX 対応のケースで、3000 円程度で買えることで有名なケース。この値段で性能に全く不満がないので、大当たりだったと思う。

後から付け足したもの

3.5 インチ HDD

TOSHIBA の 1 TB のバルク品

ドスパラで安く売っていたバルク品を買った。

CPU クーラー

サイズ白虎

Intel のリテールクーラー (付属の CPU ファン) でも十分に冷やし切れていたが、夏になったときにやや不安があったので、買ってみた。懐中電灯を当てるとヒートシンクに反射して目がやられる。

合計金額

89,999 円 + Windows のライセンス

満足感に対してかなり安いという印象がある。自作なので、不足を感じるならばパーツを交換すればよいというのもパーツ選びには影響したと思う。

特定の Microsoft Office アプリのみインストールする

2021-01-26T00:00:00Z

Office Deployment Tool (Office 展開ツール) を使用することで、特定の Office アプリのみインストールできる。

ドキュメント

https://aka.ms/ODT

設定ファイルのサンプル

Excel, Word, PowerPoint のみをインストールするときの例。

<Configuration>
    <Add>
        <Product ID="O365ProPlusRetail">
            <Language ID="ja-jp"/>
            <ExcludeApp ID="Access"/>
            <ExcludeApp ID="Groove"/>    <!-- Onedrive for Business -->
            <ExcludeApp ID="Lync"/>      <!-- Skype for Business -->
            <ExcludeApp ID="OneDrive"/>
            <ExcludeApp ID="OneNote"/>
            <ExcludeApp ID="Outlook"/>
            <ExcludeApp ID="Publisher"/>
            <ExcludeApp ID="Teams"/>
        </Product>
    </Add>
</Configuration>

Windows 10 のロック画面でスリープさせない設定

2021-01-18T00:00:00Z

ロック中に Windows がスリープする

通常、ロック画面で放置しておくと勝手にスリープしてしまうようなのだが、この挙動で困ってしまうので、次の方法で対処した。

regedit.exe で HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\7bc4a2f9-d8fc-4469-b07b-33eb785aaca0 の Attribute を 2 にする
電源オプションの詳細設定で「スリープ」-「システム無人スリープタイムアウト」の時間を適当に設定する

ロック中にモニターが切れる

同様に、スリープ中にモニターが切れる問題。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\7516b95f-f776-4464-8c53-06167f40cc99\8EC4B3A5-6868-48c2-BE75-4F3044BE88A7 の Attribute を 2 にする
「ディスプレイ」-「コンソールロックディスプレイオフのタイムアウト」を適当に設定する

npm のパッケージをとりあえず全部アップデートする方法

2020-12-23T00:00:00Z

次のコマンドを叩く。

node -e "console.log(Object.keys(require('./package.json').dependencies).join(' '))" | xargs npm i

やっていることは単純で、package.json の dependencies のパッケージ名を Node.js で列挙して、 npm install の引数に渡している。package.json のバージョン指定をすべて無視して、とりあえず普通に npm install したときにインストールされるものにバージョンを揃えることができる。

WSL を引っ越す

2020-12-19T00:00:00Z

wsl --export ubuntu-20.04 <アーカイブのパス> でエクスポート
Ubuntu-20.04 のストアアプリをアンインストールしておく
wsl --import ubuntu-20.04 <インストール場所> <アーカイブのパス> でインポート
Microsoft Store から Ubuntu-20.04 をインストール
ubuntu2004 config --default-user <user> でデフォルトユーザーを普段のものに変更

少なくとも現時点では、ほぼ公式ドキュメントに書いてある手順そのまま。

なぜこうなるか

既に同じ名前のディストリビューションがインストールされている場合 wsl --import で弾かれるため、インポート時にはアンインストールしておく必要がある。アンインストールせずとも wsl --unregister <distro> だけで良いかどうかは未検証。

wsl --import だけでは ubuntu2004 コマンドが使用できず、デフォルトユーザーを root から変更できない。どうやら Microsoft Store からインストールしたディストリビューションでないとディストリビューション名のコマンドは使用できないようであるため、改めて Microsoft Store からディストリビューションをインストールする。この時、ストアアプリとしてインストールされる Ubuntu のディストリビューション名も ubuntu-20.04 だが、インポートしたデータは上書きされない。

参考

配布の既定のユーザーを変更する, Linux ディストリビューションの管理 | Microsoft Docs

[Pixel] ゲーム中にうっかりホーム画面に戻ってしまう

2020-12-10T00:00:00Z

Q. ゲームするときにうっかりホーム画面に戻ってしまうのが面倒

音ゲーなど、画面の上端や下端からスワイプするような操作を頻繁にするゲームだと、誤って通知バーを出してしまったりホーム画面に戻ってしまったりする事故が多発する (特にジェスチャーナビゲーションを使っている場合)。

A. 画面固定を使おう

画面固定モードを使うことで、通知センターとホーム画面に戻るジェスチャーを無効にできる。

https://support.google.com/pixelphone/answer/6118421?hl=ja

「戻る」ジェスチャーは相変わらず反応するので注意。

ブログを Next.js で作り直した

2020-08-30T00:00:00Z

このブログを Next.js で作り直した。以前に動いていたものをほぼ再現できたと思う。

嬉しくなった点

ソースコードが大幅に読みやすくなった

以前は自作ルーター + 巨大 app.js で全てを行っていたため、これは何ですかと言いたくなるようなコードになっていた。

アクセス時に読み込まれる CSS が少し小さくなった

以前はページごとに 3 つの CSS ファイルに分割し、minify したものを HTML に埋め込んでいた。今は Next.js がうまいことコンポーネント分割してくれている、らしい。

以前はインラインで記述していたためすべてのアクセスでダウンロード量に影響したが、今は <link> タグで埋め込まれているため、初回より後のアクセスでは読み込みが速くなると思われる。ただ、初回アクセスでどちらが速いのかはよく分かっていない。

GitHub Actions でのビルドが相当速くなった

以前は Puppeteer を使って静的サイトジェネレーションを行っていたが、それを Next.js がやってくれるようになったおかげで、ビルドが相当高速化した。以前は 1 分以上かかっていたものが、今は 30 秒程度で終わるようになった。

開発環境でのプレビューが容易になった

npx next dev を叩くだけで容易にプレビューできるようになった。

私はここで苦しみました

SSG をすると、`next/link` のリンクが機能しない

これは以前の URL 構造をそのまま保とうとしたことが原因であるため、どちらかといえば私の使い方の問題であろう。Next.js の Dynamic Routing では、各ページの URL に .html の拡張子を付与することはできないため、SSG したときにサイト内リンクが尽くリンク切れを起こす問題が発生した。例えば、SSG 後の URL は /tags/foo.html であるにも関わらず、サイト内リンクの href は /tags/foo のままである、といった具合である。

この問題は Next.js の設定を弄ることで容易に解消できる。next.config.js で <code>trailingSlash: true</code> を設定すればよい。しかし、私のブログの URL 構造を保とうとした場合、これでは過去のリンクがすべてリンク切れを起こしてしまう問題があり、この方法は導入できなかった。

そこで、<Link> をラップし、SSG を行うときは手動で <a> タグを返すようにした。SSG かどうかは環境変数によって判別することとした (NEXT_PUBLIC_ から始まる環境変数はブラウザからも参照できる) 。

参照: https://github.com/comame/blog.comame.xyz/blob/b7b80220685f6c568bcb9cfedf820db953899123/src/lib/link.tsx

GitHub Pages でうまいことホストされない

以前と同様に GitHub Pages でホストしようと思ったところ、なぜか docs/_next/ 配下のファイルが 404 を返してしまう問題に遭遇した。これは GitHub Pages に組み込まれている Jekyll が原因であり、_ から始まるディレクトリ名を持つディレクトリは配信されないようである。

これを解消するために、GitHub Pages で配信するディレクトリの最上位ディレクトリ (このブログでは <projectroot>/docs/) に `.nojekyll ファイルを置いた。

どうやらこの方法は GitHub のドキュメントには書かれておらず、GitHub Blog にしか公式の記事を見つけることができなかった。

TOTP をフルスクラッチした

2020-07-20T00:00:00Z

JavaScript で TOTP を実装してみたので、その実装メモなど。

https://github.com/comame/TOTP

TOTP

RFC 6238: TOTP: Time-Based One-Time Password Algorithm で規定される。Google Authenticator アプリなどを使って時刻ベースで生成される (大抵) 6 桁のワンタイムパスワードであり、2 要素認証に用いられる。

疑似コードで次のように表される。

K: 共有シークレット、QR コードとかで読み込むやつ
X: ステップ秒。大抵 30 秒。この値の周期でトークンが切り替わる
T0: Unix Time の開始秒。大抵 0

T = (Current Unix Time - T0) / X) as Integer

TOTP(K, T) = HOTP(K, T) = Truncate(HMAC-SHA-1(K, T))

トークンの生成アルゴリズムには HOTP を使用する。

のちに記述するように、HOTP では T の値が 32-bit までしかサポートされていないため、4.2 節では 32-bit より大きい整数をサポートするように規定されている。具体的にどう実装するのかは記述されていないので、Google Authenticator の実装などを見るのが良いと思われる。

HOTP

RFC 4226: HOTP: An HMAC-Based One-Time Password Algorithm で規定される。カウンターベースのワンタイムパスワード。

K: 共有シークレット
C: カウンター。8-byte の整数
HS: 20-byte
S: 31-bit
D: 桁数が Digit の HOTP トークン

DT(HS: bytes[20])
    OffsetBits = HS[19] & 0xF // HS[19] の下位 4-bit
    Offset = OffsetBits as Integer // 0 <= offset<= 15
    P = HS[Offset]...HS[Offset + 3]
    return P & 0x7FFFFFFF // 下位 31-bit

HS = HMAC-SHA-1(K, C)
S = DT(HS)
D = (S as Integer) mod 10^Digit

RFC の 5.4 節の例は次の通りである。

HS = {
    1F, 86, 98, 69, 0E,
    02, CA, 16, 61, 85,
    50, EF, 7F, 19, DA,
    8E, 94, 5B, 55, 5A
}

OffsetBits = 0xA
Offset = 10
P = 0x50EF7F19

S = 0x50EF7F19 & 0x7FFFFFFF = 0x50EF7F19
D = 872921

HMAC

https://www.ipa.go.jp/security/rfc/RFC2104JA.html に日本語での解説がある。

H: ハッシュ関数
K: シークレット
M: メッセージ

ipad = 0x3636...
opad = 0x5C5C...
// ipad, opad の長さはハッシュ関数のブロック長 (SHA-1 の場合 512-bit) と同一

||: ビットの連結

HMAC(K, M) = H((K xor opad) || H((K xor ipad) || M))

K と opad, ipad とで排他的論理和をとっていることから分かるように、K の長さもハッシュ関数のブロック長と同一にする必要がある。K は入力値であることから、長さを揃えるために次のような処理を順に行う。

K の長さがブロック長より大きい場合、K をハッシュ関数に通す。K の長さがブロック長より小さい場合、ブロック長と同一になるまで末尾に 0 を追加する。

SHA-1

https://www.ipa.go.jp/security/rfc/RFC3174JA.html に日本語での解説がある。

まずはメッセージのパディングを行い、メッセージ長を 512-bit の倍数にする。オリジナルのメッセージ長が 512-bit の倍数であった時にもパディングは行う。パディングは次の手順で行う。

末尾に 1-bit の 1 を付加する
メッセージ長が mod 512-bit = 448 になるまで 0 を末尾に付加する
オリジナルのメッセージ長を 64-bit で付加する

次の関数を定義する。

f(t; B, C, D) = (B & C) | ((~B) & D); (0 <= t <= 19)
f(t; B, C, D) = B ^ C ^ D; (20 <= t <= 39)
f(t; B, C, D) = (B & C) | (B & D) | (C & D) (40 <= t <= 59)
f(t; B, C, D) = B ^ C ^ D; (60 <= t <= 79)

K(t) = 0x5A827999; (0 <= t <= 19)
K(t) = 0x6ED9EBA1; (20 <= t <= 39)
K(t) = 0x8F1BBCDC; (40 <= t <= 59)
K(t) = 0xCA62C1D6; (60 <= t <= 79)

S^N(n) = (M << n) | (M >> (32 - n)) // 循環左シフト
A + B = (A + B) mod (2 ** 32)

複数の計算方法があるようだが、今回は次の方法で計算した。

M: 512-bit ごとに区切ったメッセージ

H0 = 0x67452301
H1 = 0xEFCDAB89
H2 = 0x98BADCFE
H3 = 0x10325476
H4 = 0xC3D2E1F0

for each M(i)
    W[16] = M(i) // M(i) を 32-bit ごとに分割する

    for t from 16 to 79
        W[t] = S^1(W[t - 3] ^ W[t - 8] ^ W[t - 14] ^ W[t - 16])

    A = H0; B = H1; C = H2; D = H3; E = H4

    for t from 0 to 79
        TMP = S^5(A) + f(t; B, C, D) + E + W[t] + K(t)
        E = D; D = C; C = s^30(B); A = TMP

    H0 += A; H1 += B; H2 += C; H3 += D; H4 += E

// H0 H1 H2 H3 H4 をこの順で並べる

実装で苦しんだところ (大体うっかり)

HOTP

C は 8-byte 整数。

HMAC

ハッシュ関数に SHA-1 を使用する場合、ブロック長は 64-byte、出力長は 20-byte であることから、K にハッシュを通した後に 0 を追加する処理を行う必要がある。

SHA-1

(追記あり) 左循環シフト。(n: number, x: number) => (x << n) | (x >> (32 - n)) と素直に書くと、x は 32-bit 整数、0 <= n < 32 であることからオーバーフローする。

参考にしたもの

IPA の RFC 日本語訳: HMAC と SHA-1 の実装
Golang のソースコード: テストケースや各アルゴリズムの実装。読みやすい。
RFC: テスト用のサンプルケースが Appendix に書いてあることを初めて知った

左循環シフトの高速化

https://github.com/comame/TOTP/compare/e495732d9156e805c78ff2626e95f09301123b32...361549fc64a207bcc402f48f802ee4d68b61cac6

オーバーフローをしないためにビットの配列に変換してシフト操作をしていたものを、number のまま計算できるように書き換えた。オーバーフローを起こさないため、32-bit 整数を 8-bit ずつに区切り、場合分けした。また、シフト演算子を使うとオーバーフローを起こすため、掛け算と割り算でシフト演算子と同等の計算を行うようにした。

次のようなコードで 10 回ずつ計測しそれぞれ平均をとったところ、高速化前は 616 ms、高速化後は 5 ms となった。

また、SHA-1 の計算自体も、おおむね半分から 5 分の 1 程度の実行時間に短縮された。

const t = Date.now()
for (let i = 0; i < 100000; i +=1) circularShift(16, 0x12345678)
console.log(Date.now() - t)

測定結果

高速化前 [ms]
    608 605 611 598 612 599 698 605 612 611
高速化後 [ms]
    4   4   6   4   5   5   5   4   5   5

Chrome の検索エンジン設定

2020-07-08T00:00:00Z

Chrome には、アドレスバーに特定のキーワードを入力すると、特定のサイト内を直接検索できる機能がある。手動で検索エンジンとキーワードを設定することもできるので、頻繁に検索するサイトは登録しておくと便利。

最近登録していた検索エンジンを整理したので、備忘録も兼ねて以下に記す。

辞書とか翻訳とか

英単語の意味を調べたり、言葉遣いに誤りがないか調べたりするときに便利。

キーワード	説明	URL (%s = 検索ワード)
translate	Google 翻訳	https://translate.google.com/#auto\|auto\|%s
en	Dictionary.com	https://www.dictionary.com/browse/%s
lexico	Oxford Dictionaries	https://www.lexico.com/definition/%s
jp	weblio	https://www.weblio.jp/content/%s

開発の資料とか

公式の資料に当たりたいときに関係ないサイトが検索結果に出てきたり、頻繁にサイト内検索するのに毎回 URL を直打ちするのが面倒なので設定。

キーワード	説明	URL (%s = 検索ワード)
caniuse	ブラウザごとの実装状況	https://caniuse.com/#search=%s
mdn	MDN Web Docs 内を Google で検索	https://www.google.com/search?q=site%3Adeveloper.mozilla.org%2Fja+%s
node	Node.js のドキュメントを Google で検索	https://www.google.co.jp/search?q=site%3Ahttps%3A%2F%2Fnodejs.org%2Fapi+%s
rfc	RFC を Google で検索	https://www.google.com/search?q=site%3Ahttps%3A%2F%2Ftools.ietf.org%2Fhtml+%s
npm	npm パッケージの検索	https://www.npmjs.com/search?q=%s
docker	Docker Hub	https://hub.docker.com/search?q=%s&type=image
eng	Google を英語で検索	https://google.com/search?gl=us&hl=en&gws_rd=cr&pws=0&q=%s

その他

その他、よく使うもの。

キーワード	説明	URL (%s = 検索ワード)
whois	whois	https://www.whois.com/search.php?query=%s
chrome	Google Chrome ヘルプ	https://support.google.com/chrome/search?hl=ja&q=%s
gmail	Gmail ヘルプ	https://support.google.com/mail/search?hl=ja&q=%s
accounts	Google アカウントヘルプ	https://support.google.com/accounts/search?hl=ja&q=%s

Docker を使用したGradle のビルドを高速化する

2020-07-02T00:00:00Z

問題

Docker で gradle build を実行すると、Starting a Gradle Daemon で 1 分近くかかってしまう。

解決法

適当に gradle clean などをあらかじめ実行しておく

  # Dockerfile

  FROM gradle

  COPY build.gradle.kt build.gradle.kt

+ RUN gradle clean

  COPY src src
  RUN gradle build

Daemon 起動中の出力を見る限り、依存関係の計算やダウンロード、build.gradle.kt のコンパイルに時間がかかっているように見える。一度 gradle clean を実行することによって、gradle build の実行時にはそれらを回避できる。また、src/ 以下を変更しただけの場合 RUN gradle clean はキャッシュが利用できるため、初回ビルドより後では高速にビルドできる。

測定

簡単な Hello, world! コードで検証した。次に記載するファイル以外は IntelliJ IDEA で生成されたものをそのまま使用した。

# src/main/kotlin/xyz/comame/test/Main.kt

package xyz.comame.test

fun main() {
    println("Hello,world!")
}

# Dockerfile

FROM gradle

RUN useradd -m user
USER user
WORKDIR /home/user

COPY gradle.properties gradle.properties
COPY settings.gradle.kts settings.gradle.kts
COPY build.gradle.kts build.gradle.kts

RUN gradle clean

COPY src src
RUN gradle build

初回ビルド

RUN gradle clean を追加した場合、RUN gradle clean は 49 秒、RUN gradle build は 18 秒かかった。一方、追加しなかった場合、RUN gradle build は 56 秒かかった。

2 回目のビルド

src/main/kotlin/xyz/comame/test/Main.kt の Hello, world! の文字列を変更して再度ビルドした。docker build のキャッシュは有効である。

RUN gradle clean を追加した場合、RUN gradle clean はキャッシュが使用され、RUN gradle build は 18 秒かかった。一方、追加しなかった場合、RUN gradle build は 1 分 3 秒かかった。

複数回測定を繰り返した場合でも、上記とおおむね同様の結果を得られた。

考慮事項

Dockerfile に USER root 、WORKDIR /root を指定した場合、RUN gradle build は高速化されなかった。root ユーザーでは効果がないのか、WORKDIR /root の場合に問題があるのか、あるいは他に原因があるのか、今回は未検証である。

Kotlin プロジェクトを作成する

2020-06-28T00:00:00Z

Gradle 周りの設定の備忘録。

Gradle Wrapper

Gradle Wrapper を準備する。

$ gradle wrapper

ビルド設定

gradle jar で実行可能な Jar ファイルを吐けるようにする。

// build.gradle.kts

  plugins {
+   application
  }

+ application {
+     mainClassName = "xyz.comame.project.MainKt"
+ }

+ val jar by tasks.getting(Jar::class) {
+     manifest {
+         attributes["Main-Class"] = "xyz.comame.project.MainKt"
+     }
+ }

ソースコード

src/main/kotlin/xyz/comame/project/ に置く。

最後に

正直よく分かっていない。gradle init を試してみたら、実はこれでもプロジェクト設定をしてくれるらしい。

Windows で動くおうちサーバにアクセスできなかった問題

2020-05-17T00:00:00Z

端的に

「プライベート」ネットワークとして接続する
ファイアウォールを確認する

環境

ネットワーク

+--------------------+
|       Router       |
|   192.168.0.1/24   |
+--------------------+
           |
           |---------------------------|
           |                           |
+--------------------+      +--------------------+
|       Windows      |      |       Android      |
|     192.168.0.2    |      |     192.168.0.3    |
+--------------------+      +--------------------+

HTTP サーバ

Windows で 8080 番ポートで待ち受け。

発生した問題

Windows マシンで動かしているサーバに、自宅内の他の端末からアクセスできなかった

Windows から curl http://localhost:8080 は問題なし
Windows から curl http://192.168.0.2:8080 は問題なし
Android から Chrome で http://192.168.0.2:8080 を開こうとするとERR_CONNECTION_REFUSED

原因と対処

Windows ファイアウォール

8080 番ポートへのアクセスが許可されていなかった。「受信の規則」に「TCP 8080番ポート」のアクセス許可を追加した。自宅のネットワークからのみアクセスできるようにするため、リモートアドレスは 192.168.0.1/24 のみとした。

ネットワークプロフィール

ネットワークプロフィールが「パブリック」になっていた。Wi-Fi 設定から「プライベート」に変更した。

PubSubHubbub について

2020-05-04T00:00:00Z

この記事は、pubsubhubbub.appspot.com で Subscribe した時の挙動について書く。

pubsubhubbub.appspot.com は PubSubHubbub Core 0.4 と Permanent subscriptions を除く PubSubHubbub Core 0.3 に従っている。

PubSubHubbub とは、Subscriber 側から見た場合は Webhook である。現在は W3C によって WebSub として公開されている。WebSub は PubSubHubbub Core 0.4 と概ね同じだと思われる (あまり読み込んでいない)。

PubSubHubbub Core 0.4

仕様を正確に翻訳したものではない。実装する際には元の仕様を参照することをおすすめする。

用語

Topic: HTTP の URL。変更を購読するリソースを一意に表す。
Hub: PubSubHubbub の Subscribing と Publishing をどちらも実装するサーバ。
Subscriber: Topic の更新を受け取るエンティティ。
Subscription: Topic とその更新通知を受け取る Subscriber の一意な関係。Topic URL と Subscriber Callback URL をキーとする。
Subscriber Callback URL: Subscriber が通知を受け取る URL。

参照: 2. Definitions

Subscribing

購読を登録するとき、次のような流れとなる。

Subscriber が Hub に Subscription Request を送信する
Hub が Subscription Request を検証する (OPTIONAL)
Hub が Subscriber に Verificatin Request を送信する
Subscriber が Hub に Verification Response を返す

参照: 5. Subscribing and Unsubscribing

Subscription Request

以下のパラメータを Content-Type: application/x-www-form-urlencoded で POST する。

hub.callback: REQUIRED. Subscriber Callback URL。配信通知はこの URL に対して POST される。クエリパラメータは保持される (5.1.1. Subscription Parameter Details)。
hub.mode: REQUIRED. subscribe あるいは unsubscribe のいずれかの値をとる。
hub.topic: REQUIRED. 購読する Topic の URL。
hub.lease_seconds: OPTIONAL. 購読の有効な時間 (秒)。Hub はこの値に従ってもよいし、従わなくともよい。hub.mode が unsubscribe の場合は無視される。
hub.secret: OPTIONAL. 後に Subscriber が更新通知を検証できるようにするための値。詳しくは後述。

既に有効な Subscription がある場合、Hub は Subscription を更新する。Subscription の確認に失敗した場合は、以前の購読状態を継続する。

参照: 5.1. Subscriber Sends Subscription Request

Subscription Response

Hub は HTTP 202 Accepted によって、Subscription Request が検証され、確認されることを示す。エラーが発生した場合、Hub は 4xx または 5xx を返す。

参照: 5.1.2. Subscription Response Details

Verification Request

Subscription Request が正しいものかを確認するため、Hub は Subscriber Callback URL に以下のクエリパラメータとともに GET リクエストを送信する。

hub.mode: REQUIRED. Subscription Request に指定した値と同じ値を示す。
hub.topic: REQUIRED. Subscription Request に指定した値と同じ値を示す。
hub.challenge: REQUIRED. Hub によって生成されたランダムな文字列。Subscriber はこの値をレスポンスとして返すことにより、Subscription を確認する。
hub.lease_seconds: REQUIRED/OPTIONAL. hub.mode が subscribe の場合、REQUIRED となる。Hub によって決定された購読の有効な時間 (秒) を表す。

参照: 5.3. Hub Verifies Intent of the Subscriber

リクエストされた内容が正しい場合、Subscriber は hub.challenge の値をレスポンスボディに含め、2xx を返す。リクエストされた内容が正しくない場合、Subscriber は 404 を返す。

その他のステータスコードを返した場合、またはレスポンスボディが hub.challenge の値と異なる場合、確認は失敗する。

参照: 5.3.1. Verification Details

更新の通知

コンテンツが更新された時、Hub は Subscriber Callback URL に POST リクエストを送信する。

リクエストを受け取ったとき、Subscriber は 2xx を返さなければならない。それ以外のステータスコードを返した場合、通知は失敗したとみなされる (リダイレクトも機能しない)。2xx のレスポンスはあくまで正常に通知を受け取ったことを表すのみであり、通知の内容が正しいことを示すものではない。

リクエストには、RFC5988 に規定される Link Header が付与される。rel=hub には Hub の URL を、rel=self には Topic の URL が指定される。

参照: 7. Content Distribution

検証可能な更新の通知

Subscription Request に hub.secret を含めた場合、Hub はペイロードの HMAC 署名をヘッダに付与する。署名は 40 バイトの 16 進数表示の SHA-1 である。ヘッダの形式は次のようになる。

X-Hub-Signature: sha1=<signature>

これにより、通知の内容が第三者に偽造されたものではないことを確認できる。

8. Authenticated Content Distribution

PubSubHubbub Core 0.3 による追加事項

メッセージの形式

更新の通知は Atom あるいは RSS の形式である。

参照: 4. Atom Details

Subscription Request

以下のパラメータが追加される。

hub.verify: REQUIRED. Subscriber が Subscription を確認する方法を指定する。sync あるいは async のいずれの値をとる。
hub.verify_token: OPTIONAL. 指定した場合、Hub はこの値を Verification Request のクエリパラメータに付与する。

参考: 6.1. Subscriber Sends Subscription Request

Verification Request

以下のクエリパラメータが追加される。

hub.verify_token: OPTIONAL. Subscription Request に指定した値をそのまま含む。

以下のパラメータが変更される。

hub.lease_seconds: OPTIONAL/REQUIRED. 値が含まれていた場合の挙動は PubSubHubbub Core 0.4 と同一である。値が含まれない場合、後述するように Subscription の更新の挙動が変わる。

参照: 6.2. Hub Verifies Intent of the Subscriber

自動的な Subscription の更新

注意: pubsubhubbub.appspot.com では非対応である。

hub.lease_seconds が経過する前に、Hub は自動的に Subscription の確認を行う。

参照: 6.3 Automatic Subscription Refresh

pubsubhubbub.appspot.com の挙動

筆者が自分の環境で確認したものである。仕様に定められた挙動ではないため、将来的に変更される可能性もある。

Subscription Request の宛先

送信先は https://pubsubhubbub.appspot.com/subscribe である。

Subscription Response のステータスコード

hub.verify が sync の場合、正常に Subscription Request が受理されたときは 204 No Content を返す。

Permanent Subscription の非対応

PubSubHubbub Core 0.3 の 6.3 Automatic Subscription Refresh には対応しない。Subscriber は hub.lease_seconds が経過する前に再び Subscription Request を行う必要がある。

補足・考察

pubsubhubbub.appspot.com は PubSubHubbub Core 0.4 に加えて PubSubHubbub Core 0.3 も参照するが、Permanent Subscription には非対応であるため、実用上は hub.verify_token が追加されることにだけ注意すれば良いと思われる。大抵の場合は hub.verify を sync として問題ないであろう。

PubSubHubbub Core 0.3 では更新通知のメッセージ形式が Atom または RSS と規定されているが、PubSubHubbub Core 0.4 および WebSub では撤廃されている。これにより、より汎用性の高いプロトコルを目指したと思われる。

また、新しいバージョンでは hub.verify_token も撤廃されている。このプロパティによって Verification Request を検証できるというメリットがあったが、これは Subscriber Callback URL に独自のクエリパラメータを付与することで代替できる。あるいは、第三者によって意図しない Subscription を登録されたとしても、更新通知を処理するかどうかは変わらず Subscriber の判断によるため、仕様から削除されたのかもしれない。

Automatic Subscription Refresh の撤廃は、より簡単な Webhook の登録を目指すという観点からは悪手であろう。一方、PubSubHubbub はそもそも RSS や Atom フィードのリアルタイム化を目指したものであること (Wikipedia を参照のこと) を踏まえれば妥当であるともいえる。もし Subscriber が Subscription の更新を忘れてしまったとしても、最新の更新情報は元のリソースを参照することで簡単に取得できるからである。

経緯 (余談)

YouTube Data API v3 について調べていたのだが、Search: list (100 Units/Request) をむやみに叩くとすぐに制限 (10,000 Units/Day) に達してしまう。特定のチャンネルのアップデートを素早く受け取るために、PubSubHubbub をサポートしていた。

WSL 2 のサーバをネットワークに公開する

2020-03-26T00:00:00Z

Hyper-V の NAT をこねくり回そうとしたけれども、うまくいかなかった。netsh コマンドを使うことで、簡単にポート変換ができる。

Workaround

Issue #4150 microsoft/WSL | GitHub

# PowerShell (Administrator)

> netsh interface portproxy add v4tov4 \
    listenport=<External Port> \
    listenaddress=<External Address> \
    connectport=<Internal Port> \
    connectaddress=<Internal Address>

connectaddress

WSL 2 に割り当てられた内部 IP を指定する必要がある。WSL 2 内で

# bash (WSL 2)

$ ip a show eth0

を叩くと取得できる。

netsh interface portproxy

Netsh interface portproxy コマンド | Microsoft Docs

サンプルスクリプト

$port = Read-Host 'Port'
$internal_ip = bash.exe -c "ip a show eth0 | grep -E '^\s*inet ' | xargs echo | cut -d ' ' -f 2 | cut -d '/' -f 1"

netsh interface portproxy delete v4tov4 listenport=$port listenaddress=0.0.0.0
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=$port connectaddress=$internal_ip connectport=$port

WSL 2 で Docker を自動起動する

2020-03-08T00:00:00Z

WSL 2 では systemctl が使えないため、システムの起動時に Docker を自動起動することができない。ただ、Windows 側のタスクスケジューラを使えばできるらしい。

方法

起動用スクリプトを書く

#!/usr/bin/env bash
# このファイルに実行権限も付与しておく
sudo service docker start

パスワードなしで実行できるようにする

#/etc/sudoers
user ALL=(ALL:ALL) NOPASSWD: /bin/sh /path/to/script

タスクスケジューラに設定する

全般「最上位の特権で実行する」
トリガー「ログイン時」
操作「C:\Windows\System32\bash.exe」「-c "sudo /bin/sh /path/to/script"」
条件「AC電源に接続されているときのみ」を外す

参考

こちらの Qiita 記事を参考にした。Automatically Docker Daemon Boot on Windows Subsystem Linux（WSLにおけるdockerデーモンの自動起動）

ブログシステムを新しくした (Blogger からの移行)

2020-03-07T00:00:00Z

新しいブログシステムを作成して、Blogger から移行した。今は静的ファイルとして静的ファイルサーバから配信している。GitHub でソースコードを公開した。comame/blog.comame.xyz

モチベーション

自分が制御可能な形でデータを置きたかった
自分の慣れているエディタで HTML を書きたかった
Blogger は読み込み速度が少し遅かった

仕組み

記事の管理

archives/ 配下にすべての記事データを置いている。タイトルやタグ、日付などのメタデータは archives/entries.json に記載する。

ページの生成

JavaScript で archives/entries.json を読み、記事データを展開している。これらは assets/js/app.js で処理している。History API を使って動的に URL を書き換えているため、Apache や Nginx で URL のリライトが必要。

静的ビルド

ユーザーが閲覧する環境で毎回スクリプトでページを生成するのは筋が悪いため、手元で静的ファイルとしてビルドを行う。ページは JavaScript を使って生成するため、Puppeteer でクロールしてスクリプト実行後の HTML を静的ファイルとして保存している。画像ファイルなどのアセットは、/assets に置いておけば /build/assets にそのままコピーされる。ビルド用のスクリプトは build.js である。

今後の運用

VSCode で記事を書き、手元でビルドし、GitHub にアップする。あとはビルド済みの静的ファイルを適当に配信すればよい。今回は GitHub Pages で公開することにした。自分の開発環境で記事をかけるため、かなり書きやすくなった。一方で、ビルドをするためだけにローカルサーバを立てなければいけないのは結構面倒くさい。

[追記] Git の post-commit フックを使って、自動的にビルドを走らせるようにしてみた。本当は GitHub Actions を使いたかったが、ビルド用のサーバを立てて、Puppeteer を起動して...とするのは厄介そうだったので妥協策ではある。post-commit フックは post-commit に置いておく。

[追記] GitHub Actions で push したときにビルドが走るようにした。

今後やりたいこと

Markdown で記事を書けるようにする
WebP などの画像フォーマットに自動的に変換できるようにする
OGP に対応
[DONE] RSS フィードを生成できるようにする

Windows 10 の ssh で Permission refusedが出る問題

2020-02-19T00:00:00Z

対処法

ssh-agent を有効にして、ssh-add する。

Set-Service -Name ssh-agent -StartupType Manual
Start-Service ssh-agent

ssh-add ~/.ssh/id_rsa

参考

Win10でssh-addがError connecting to agent: No such file or directory - Qiita

CNAME トラッキングについての議論

2020-01-20T00:00:00Z

先日割と感情的に呟いたものがそこそこ拡散されてしまって、「良くないものだ」という気持ちだけが広まってしまうのは本意ではないので、改めてきちんとした議論をしたいという思いでこの記事を書きます。

前提となる立場

トラッキングをすること自体の是非は問わない
トラッキングの手法についての議論である
ユーザーがトラッキングを望まない場合、積極的な対処をせずとも有効な選択肢が与えられる状態が望ましい

CNAME トラッキングの方法・背景

アドエビスによる解説がわかりやすいです。最近の Third-party Cookie に対する制限の回避策となり得ます。

セキュリティの懸念事項

不適切な設定をされた Cookie が、トラッキングサービスに送信されてしまう

Set-Cookie ヘッダに Domain ディレクティブを指定した場合、すべてのサブドメインに Cookie が送信されてしまいます。もし認証に用いる機密情報などをこの方法で設定した場合、CNAME レコードとして設定したトラッキングサービスにも Cookie が送信されてしまいます。Set-Cookie - HTTP | MDN

プライバシーの懸念事項

ユーザーに情報収集することについての選択肢が与えられない

Third-party Cookie を使用して情報を収集する場合、ユーザーが Third-party Cookie をブロックすればトラッキングを防ぐことができます。また、これによってトラッキング以外の要素に与える影響はあまり大きくありません (Third-party Cookie を認証に使うようなことがない限り...)。一方、First-party Cookie を用いてトラッキングをする場合、ユーザーができることは First-party Cookie を拒否することです。First-party Cookie は認証などの様々な用途に使われており、影響は大きくなると想定されます。

First-party Cookie をブロックすることによる影響が大きいことを鑑みると、これはユーザーによる積極的な行動とみるべきです。私の提案としては、ユーザーの不便が行動による効果を上回る場合、積極的な行動と取るべきだと考えています。積極的な行動か否かの判断は極めて難しいものであり、今後議論が進むことを期待します。

次に、ブラウザの拡張機能によって事前に DNS をクエリし、トラッキングサービスへの CNAME レコードがあればアクセスをブロックするという手法が考えられます。この手法にはいくつかの問題があります。すべてのリクエストごとに DNS クエリを走らせるため、パフォーマンスに影響が出ることが想定されます。ブラウザが拡張機能に対して DNS クエリを行う機能を提供するかどうかに依存します。

CNAME トラッキングに対する考察・提案

現時点において、有効な選択肢をユーザーに与えることが難しいこと・セキュリティの問題があることを踏まえると、代替手段が存在しない場合にのみ CNAME トラッキングを導入するべきだと考えます。

トラッキングサービスの提供者に期待すること

Set-Cookieの不適切な設定による機密情報の漏洩を防ぐため、導入者に対して必要十分な助言をすること
ユーザーの同意を得るためのプロンプトを表示させる等、ユーザーに選択肢を提示するよう導入者に指導すること
ユーザーの同意が得られるまでトラッキングを行わないようにする機能を提供すること
将来的に有効な代替手段が提案されたときは、CNAME トラッキングを停止すること

トラッキングの導入者に期待すること

Set-Cookieについて正しい知識を得て、Cookie の漏洩が起こらないようにすること
トラッキングを有効にする前に、個別のユーザーに対して有効な同意を得ること

Blogger のテーマ作成について

2019-12-10T00:00:00Z

Google Blogger Advent Calendar 2019 の 10 日目の記事です。

Blogger には、標準でおしゃれなテーマがいくつか付属しています。また、検索エンジンで少し調べてみれば、有志が作成した素晴らしいテーマを簡単に見つけることができます。しかし、こうは思ったことはありませんか？「自分だけのテーマを作ってみたい」と。

この記事では、Blogger のテーマを作成するためのチュートリアルと TIPS をお届けします。

前置き

HTML や CSS などの基本的な Web 技術が多少分かることを前提としています。また、SEO を目的としたテーマ作成について扱うわけではありません。

まずはじめに

Blogger のテーマってどこで作るの？

Blogger を開き、「テーマ」を開きます。「HTML を編集」のボタンをクリックすると、エディタが開きます。あとは自分の HTML を書いていくだけです。(このエディタは結構使いにくいので、手元で書いたものを貼り付ける方が良いかもしれません。テキストエディタは VSCode や Atom, Sublime Text などが有名です)

Blogger のテンプレートを記述する XML って何？

Blogger のテーマは HTML とは少し形式の異なる、XML という言語で記述します。大まかな違いとしては、HTML は多少誤った記述をしても寛大に解釈されます (例えば、閉じタグを忘れても自動的に閉じてくれます)。一方で、XML は文法に則った記述をしないと、エラーとなってしまいます。具体的な違いとしては、まず XML では閉じタグを省略できません。<img>などの閉じタグが不要なタグでも、必ず記述しなければなりません。

閉じタグを忘れるとエラーになる
ng -- <h1><h2>Heading</h1>

閉じタグを省略できない
ok -- <img src='https://example.com/foo.png'></img>
ok -- <img src='https://example.com/foo.png'/>
ng -- <img src='https://example.com/foo.png'>

また、ファイルの先頭に決められた形式の記述をしなければなりません。Blogger の場合は次のようになります。

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE html>
<html b:responsive='true' lang='ja' xmlns='http://www.w3.org/1999/xhtml' xmlns:b='http://www.google.com/2005/gml/b' xmlns:data='http://www.google.com/2005/gml/data' xmlns:expr='http://www.google.com/2005/gml/expr'>

<!-- Your cool things here -->

テーマの構成

Blogger のテーマには、決められた構成が存在します。これは皆さんが Blogger 管理画面の「レイアウト」で見慣れているものとほぼ同じです。Blogger のテーマで使用されるレイアウトのパーツには、b:section, b:widget, b:includable (b:include) があります。

Blogger のレイアウト構成は次のようになっています。

b:section

レイアウトの最上位に配置されます。日本語の管理画面では「セクション」と表示されていますね。セクションにはウィジェットだけを含むことができます。 id属性は必須です。他の ID と重複しない一意な文字列を指定します。

<b:section id='foo'>
  <!-- widgets -->
</b:section>

b:widget

セクションの中に配置されます。管理画面では「ウィジェット」と表示されています。皆さんが Blogger をカスタマイズするときには、最も良く扱う部分ではないでしょうか。ウィジェットの特徴としては、 Blogger によって用意されているものだけを使用できるという点が挙げられます。また、ウィジェット内には後述する b:includableのみを配置できます。

idとtype属性は必須です。type属性には BlogArchive, Blog, Header, LinkList, NavBar, BlogProfile などを指定できます。これらは管理画面から追加できるウィジェットと同じです。また、id属性は Type + 連番の形式にする必要があります。

<b:section id='foo'>

  <b:widget id='Blog1' type='Blog'>
    <-- includables -->
  </b:widget>

  <b:widget id='LinkList1' type='LinkList'>
    <-- includables -->
  </b:widget>

</b:section>

b:includable

ウィジェットの中で使用されるパーツです。includable という名前が表すように、他の場所で再利用可能です。セクションやウィジェットと異なり、この中では自由に要素を追加できます。

id属性は必須です。また、各ウィジェット内には必ずmainを ID とした includable が必要です。main以外を指定した includable は、b:includeで明示的に指定しない限り、表示されません。

<b:section id='foo'>
  <b:widget id='Blog1' type='Blog'>

    <b:includable id='main'>
      <p>やっと他の要素を書き込める！</p>
    </b:includable>

    <b:includable id='another-includable'>
      <p>まだ表示されない</p>
    </b:includable>

  </b:widget>
</b:section>

b:include

includable を再利用します。name属性を使用して include するものを指定します。

<b:section id='foo'>
  <b:widget id='Blog1' type='Blog'>

    <b:includable id='main'>
      <p>やっと他の要素を書き込める！</p>
      <b:include name='another-includable'></b:includable>
    </b:includable>

    <b:includable id='another-includable'>
      <p>main の中に表示された！</p>
    </b:includable>

  </b:widget>
</b:section>

データタグ / 制御タグ

ここまでは、Blogger のレイアウトを構成するタグを説明しました。実際にブログとして機能させるには、ブログのデータを埋め込んでいく必要があります。そこで使用するのがウィジェットタグです。ウィジェットタグは大まかに分類してデータタグと制御タグに分けることができます。

データタグは、ブログのデータを表現します。例えば、<data:blog.title/>というタグは、ブログのタイトルに置き換えられます。使用可能なデータタグはヘルプページに説明がありますが、いくつか補足があります。「グローバルに利用可能なデータ」は、テーマ内の任意の場所で使用可能です。セクションの外であっても、例えば<title>タグなどに使用できます。一方で、それ以外のデータタグは特定のウィジェット内でしか使用できません。例えば「ブログの投稿」で説明されているデータタグは、<b:widget id='Blog1' type='Blog'><b:widget>内でのみ使用できます。

制御タグを用いて、ループ (繰り返し) や条件分岐を記述できます。大抵の場合、ブログのトップページに表示する記事の一覧はループを用いることになるでしょう。また、特定の条件でのみ表示させたいタグがあるとき、条件分岐を使います。これは、例えば Blogger 内での記事検索を実装するのに使えるでしょう。条件分岐には b:if, b:elseif, b:else タグを、ループには b:loop タグを使います。

<!-- </b:loop> までを、記事の数だけ繰り返す -->
<b:loop var='post' values='data:posts'>

  <b:if cond='data:blog.pageType == "index"'>
    <!-- トップページや検索結果画面などで表示される -->
    <h2><data:post.title/></h2>

    <!-- それ以外で表示される -->
    <b:else/>
    <h1><data:post.title/></h1>
    <p><data:post.body/></p>
  </b:if>

</b:loop>

b:evalタグとexpr:属性 (Attribute) は特殊で難しい構文です。eval:属性は、HTML の属性にブログのデータを埋め込みたいときに使用します。例えば、ブログのホームページへのリンクは次のようなものになるでしょう。

<a expr:href="data:homepageUrl">ホームページ</a>

b:evalタグも同様の役割を持ちますが、これは属性ではなくタグです。

制御タグとb:eval、expr:についてのヘルプページはこちらです。

TIPS

SNS などへの共有時にプレビューを表示する

SNS に記事を共有したときにプレビューを表示させるには、OGP (Open Graph Protocol, ogp.me) を使用します。

<html prefix='og: http://ogp.me/ns#'>
  <head>
    <meta property='og:title' content='記事のタイトル'>
    <meta property='og:type' content='article (トップページなら website)'>
    <meta property='og:site_name' content='サイト名'>
    <meta property='og:url' content='記事の URL'>
    <meta property='og:image' content='記事のサムネイル画像の URL>
    <meta property='og:description' content='記事の概要'>
    <meta property='og:locale' content='ja_JP'>

読み込みを高速化する

Blogger のテーマは、そのまま書くと勝手に CSS や JavaScript を挿入されてしまいます。これらはレンダリングをブロックする要因になり、読み込みの低速化に繋がります。もしパフォーマンスにこだわりのある方は、次のような一手間を加えてみてください。

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE html>
<html b:responsive='true' lang='ja' xmlns='http://www.w3.org/1999/xhtml' xmlns:b='http://www.google.com/2005/gml/b' xmlns:data='http://www.google.com/2005/gml/data' xmlns:expr='http://www.google.com/2005/gml/expr'>

  <!-- head 開始タグ-->
  &lt;!--<head>--&gt;&lt;head&gt;
    <!-- ... -->
  <!-- head 終了タグ -->
  &lt;!--</head>--&gt;&lt;/head&gt;

  <!-- body 開始タグ (変更する必要なし) -->
  <body>
    <!-- ... -->
  <!-- body 終了タグ -->
  &lt;!--</body>--&gt;&lt;/body&gt;

</html>

ただし、これによって Blogger が用意している CSS が読み込まれなくなるため、公式のウィジェットは正常に機能しなくなる可能性があります。

凝りすぎない

自分のブログでしかテーマを使わないのであれば、汎用性にこだわりすぎる必要はありません。例えば、Blogger 公式テーマのように、ヘッダーやフッター、サイドバーなどのパーツに分けて、そこにウィジェットが挿入される可能性を考えて...などやっていると、軽く数日どころではなく日が暮れることになります。例えば Web に公開して誰でも使えるようなものにする、などの目的がないのであれば、「見た目が整えば OK!」という気持ちで挑むのがまずは良いと思います。これが辛いのは、後述するように公式情報が乏しいのも理由だったりするわけですけども...

例えば、このブログのテーマも1つの変更不可能な巨大ウィジェットだけで構成されています。

公式情報はあまり当てにならない...

Advent Calendar の前日の記事にも書かれていたように、テーマ作成について公式に出されている情報は非常に乏しいものになっています。英語のページですが、とてもわかり易く書かれたドキュメントが存在するため、困ったときはそちらも見てみると良いかもしれません (https://sites.google.com/site/templateofdoom/)。Google Developers にきちんとリファレンスを出してほしいな...

終わりに

参考に、これまでのことをまとめた最小のテンプレートを公開します。GitHub Gist

Blogger のテーマを作成するには、ループや条件分岐など、いくらか高度な概念を用いることになります。確かにやや難易度は高いですが、自作のテーマが完成した時は嬉しいですし、何より深い愛着が湧くものです。自分のブログを開くたびに少し嬉しくなるような、そんな素敵なテーマが完成することを祈っています。

次の記事は minato さんです。楽しい Blogger ライフを！

Google のエキスパートとして回答すること

2019-12-01T00:00:00Z

Google Products Advent Calendar 2019 の 1 日目の記事です。

こんな記事が初日を飾るのも申し訳ない気がしますが、私が数年間ヘルプコミュニティで回答してきた中で、なぜ自分は回答を続けているんだろう、ということを考えてみたポエムです。

Google Product Experts とは

Google Product Experts (PE) は、Google のヘルプコミュニティに日々投稿される質問に回答するユーザーのことです。コミュニティには、日々たくさんの質問が寄せられます。中にはよくある質問から、誰にも解決策が見つからないような問題まで投稿されます。

エキスパートは、全員がパソコンの前に座り続けている技術オタクというわけではありません (私はそうかもしれませんが)。様々な職業・立場・趣味の人が回答しています。

なぜ回答し続けるのか

これはエキスパートによって答えが変わるでしょう。なぜ回答し続けるのか、というのは非常に難しい問いになり得ます。

Help on Social という取り組みがありました (14 日目の yasu0796 さんの記事をお楽しみに！)。これは、Twitter 上で困っていそうな人を見つけ、リプライで回答をするものです。#gHelp のハッシュタグでご存じの方もいるかもしれません。Twitter でいきなりリプライを飛ばすという性質上、極稀に罵倒されるようなこともありました。これは Twitter に限ったことではありません。Google のコミュニティでも、直接的な表現で投稿するユーザーは存在します。回答者も人間ですから、当然嫌な気持ちになります。それでも、エキスパートは回答を続けます。なぜでしょうか。

エキスパートになることによって得られる特典でしょうか。ベータテストに参加できたり、イベントに参加できたりと、特典は嬉しいものがあります。では、もし仮に明日からこれらの特典を一切受けられなくなるとしたら、エキスパートは回答をやめるでしょうか。おそらく、多くのエキスパートは回答をやめることはないと思います。少なくとも僕は回答をやめません (Googler と連絡が取れなくなるのは、エスカレーションできなくてとても困るけど)。特典があるから回答を続ける、というのは不適切でしょう。

正直なところ、少なくとも私にとって習慣になってしまったから、というのは1つの正解なのかもしれません。朝起きたらコミュニティをチェックする、仕事が終わったら返信が来ていないか確認する、といったように、日々のルーティンに組み込まれているエキスパートもいるかもしれません。では、習慣になったから惰性で回答を続けているのでしょうか。エキスパートの皆さんの回答を見ていると、これも不適切です。

おそらく、最終的には「好きだから」「楽しいから」「色んな人に使ってほしいから」「知識を広めたいから」という理由に行き着くでしょう。Google の製品について日々真剣に議論し、アップデート情報に一喜一憂し、Google にフィードバックを送りまくるエキスパートの姿を見ていると、そう結論づけるのが妥当に思えます。

質問に答えるということ

質問に答えることによって質問者を助けるだけではなく、自分が得られるものも非常に大きいということが言えます。自身が回答することでより深い知識を得られる、他の回答者と交流できる、問題を解決したときの達成感を得られる、など様々なことが挙げられます。回答することでなにか得ることを目的にしているわけではないのに、「与えよ、さらば与えられん」とはよく言ったものです (旧 Top Contributor Program の日本語ページに書いてあった気がします、確か)。

Google の製品が好きな方、質問に答えるのが好きな方、ぜひヘルプコミュニティへの投稿をお待ちしています。次は仁田坂淳史さんによる Inbox なき後のメール管理についての記事です。お楽しみに！

Catalina で Chrome の画面共有が使用できない問題

2019-11-04T00:00:00Z

macOS 10.15 Catalina において、Chrome の画面共有が使用できない問題が発生しています。これにより、例えば Hangout で手元の画面を映すことできなくなってしまいます。

原因

Catalina でアプリケーションが画面を取得するには、ユーザーによる許可が必要です（システム環境設定 > セキュリティとプライバシー > プライバシー > 画面収録で設定)。Chrome 78 では、ユーザーが画面収録を許可していても、権限がないものとして扱ってしまうようです。

今後どうなるか

Chrome Canary 80.0.3955.4 ではこの問題が解決されていることを確認できました。今後のアップデートで修正されると思われます。

Issue Tracker

Unlimited Mirai に参加しました

2019-10-30T00:00:00Z

2019年10月29日に開催されたUnlimited Miraiに参加しました。

本編

クリプトン創設者の伊藤博之さんによる1時間の講演でした。クリプトンにとって初音ミクとは何であるか、どのような存在にしたいのかといったような内容でした。

初音ミク

初音ミクは仮想楽器であり、キャラクターでもある。仮想楽器 (Virtual Instruments) は、本物の楽器と異なり、個人で扱うことが容易である。

ビジネスにおける新規性

音声合成技術 (Text to Speech) とコンピュータミュージックは、それぞれ単独では特に新規性のあるものではない。一方で、2つを組み合わせた歌唱合成技術は今までになかったジャンルである。そこにキャラクターを組み合わせたのが初音ミク。

創作の連鎖・デジタルコンテンツは使えば使うほど価値が増える (いかに見てもらうか)

創作物を囲い込んで無断使用とみなすのではなく、創作の連鎖を共感 (使ってくれてありがとう) の連鎖にしたい。
著作権に絡んだ問題によって創作の連鎖を萎縮させたくないという思いから、ピアプロ・キャラクター・ライセンスとピアプロを用意。クリエイターには様々な人がいるため、簡単に内容をつかめるよう PCL は要約したものを正文に加えて表示している。また、創作の連鎖を生み出すために、ピアプロの利用規約には投稿物の2次創作を許可する項目を設けてある。
また、初音ミクをサブカルチャーの分野に限定しないために、様々なジャンルのものとコラボしている (ファッションや伝統芸能など)。マジカルミライでは、創作体験を得られるワークショップを開催している。雪ミクは、公募したミクのデザインから、ラッピング電車やグッズ販売など広げている。

コンテンツと技術の両面に明るいことを活かす

クリプトンでは、スタッフによる研究開発を行っている。素早い準備と撤収が求められるレディー・ガガの前座や、冨田勲のイートハーヴ交響曲やマジカルミライ2019などで使った現実に合わせて初音ミクを動かす技術を作った。また、不自然だった初音ミクの喋りのシステムも作った。

質疑応答

会場では30分ほど質疑応答が設けられました。

初音ミクを盛り上げるために、挑戦したいことは？

ミク自体は意思を持たないので、クリエイターがやりたいことを代弁できるようにしていきたい。

PCL では人を傷つけるコンテンツを禁止しているが、実際には死を連想させるような作品もある

PCL の目的は創作を萎縮させないことである。どのコンテンツは良くて何が悪いかの線引きは難しいので、ファンに一任している。

音を扱うクリプトンを立ち上げたきっかけは？

楽器をやっていたから。皆さんと違わない。

今後クリプトンがやっていきたいことは？

ソフトウェアとしての初音ミクができること (機能) の向上によって、クリエイターができることを増やしたい。創作の方向性についてはクリプトンとしてできることはない。

クリプトンの新社員に求めることは？

社員のやりたいことの積み重ねが会社なので、何がしたいかを大事にしている。

コラボしていくなかでの困難をどう乗り越えた？

初音ミクは通常のアーティストと異なり楽器なので、業界的な違和感もあった。伝統芸能やクラシックに参加するのは大変だったが、サブカルチャーに限らない幅広い分野に初音ミクを広げていく。

初音ミクより前に発売されたメイコ・カイトではなく、なぜ初音ミクがヒットしたのか？

ニコニコ動画や YouTube などの動画共有サイトの存在が大きい。メイコやカイトが出た頃は、創作物を音楽のコミュニティに投稿するしかなかった。一方初音ミクは音楽だけではなく動画をつけることができた。

ビジネスとアートをどうやって統合した？

初音ミクのモチーフを特定の分野だけにせず、様々な分野に存在を拡散したかった。陳腐化した伝統に初音ミクを入り込ませる。

技術が進歩すればもっと人の声に寄せられるはず。初音ミクをもっと人に近づけたいか、あえて機械的な面を残したいか？

リアルを突き詰めることは技術的には可能である。初音ミクを声優のクローンにせず、ミクっぽさを残すべきなのではないか？音色やイントネーションは改善すべきだが、ある種のたどたどしさ・機械らしさを残している部分はある。

まとめ・その他

創作の連鎖を大切にすること、特定の分野に限定しないことが強調されていました。動画から始まりイラストや 3DCG など幅広い分野に広まっていった背景を踏まえたからこその発想なのかなというように思います。

当日は Twitter で内容を実況していた方もいました。#UnlimitedMirai
講演の中で紹介された Google Chrome の広告。創作の連鎖を表現する動画で、Everyone, Creator のキャッチフレーズが印象的です。

Let's Encrypt (Certbot) でワイルドカード証明書を取得できないときの解決法

2019-10-03T00:00:00Z

発生する問題

Certbot でワイルドカード証明書を発行しようとしたときにThe currently selected ACME CA endpoint does not support issuing wildcard certificatesというお叱りを受ける。

解決方法

ACME v2 のエンドポイントを直接指定してやれば良い。

$ certbot certonly --server https://acme-v02.api.letsencrypt.org/directory

Let's Encrypt のエンドポイントはこのドキュメントに記載されている。

AdSense の申請が落ちた理由？

2019-09-27T00:00:00Z

結論を先に述べると、AdSense の審査は無事に通過しました。1度審査に落ちたため、その理由と思われるものを残しておこうと思います。

落ちた原因の仮説

はじめに審査に落ちた理由は「コンテンツの不足」でした。しかしこのブログにはすでに20ほど記事があり、またユーザーにとって無意味なコンテンツではないと思われます (少なくともそう思いたい)。そのため、ドメインを変更する前のデータを Google が何らかの原因で持っていて、参照しているのではないかという仮説を立てました。
ドメインを変更する経緯はこちらに書いてあります。

仮説の検証・対処

Google が持っているキャッシュの中でも、心当たりがあったのは Google 検索のインデックスでした。現在のインデックス状況を調べるために、Search Console の URL 検査を https://comame.xyz/ に行いました。そうすると、確かに変更前のものがインデックスされていることを確認できました。
そこで、検索のインデックスを更新させるために、インデックスの登録リクエストを送信しました。

結果

1日ほどインデックスに登録されるのを待ち、再度 URL 検査でブログがインデックスされていることを確認しました。その後再び AdSense の申請を行いました。その結果、無事に審査を通過しました。

疑問点

この仮説に対して、1点疑問が残ります。AdSense の審査をするときに、Google が指定する JavaScript のコードを Web ページに埋め込む必要があります。しかし、Google が元々インデックスしていたページには当然スクリプトを埋め込んでいませんでした。審査に落ちた理由はあくまでコンテンツの不足であり、指定するコードが見つからなかったことではありませんでした。

OpenSSL で自己証明書を作成する方法

2019-09-26T00:00:00Z

開発鯖用に毎回 Let's Encrypt で発行するのめんどいので、自分で発行しようと思った

通常の証明書

$ openssl genrsa -aes256 2048 > server.key
$ openssl req -new -key server.key > server.csr  # Certificate Signing Request
$ openssl x509 -req -days 90 signkey server.key < server.csr > server.crt

複数の Common Name に対応する

$ cat > altNames.txt
subjectAltName = DNS:foo.example.com, DNS:bar.example.com

$ openssl x509 -req -days 90 -signkey server.key -extfile altNames.txt < server.csr > server.crt

CSR を確認する

$ openssl req -in server.csr -noout -text

証明書の内容 (あるいは期限のみ) を確認する

$ openssl x509 -in server.crt -noout -text [-dates]

AdSense の申請をした

2019-09-24T00:00:00Z

今日このブログで AdSense の申請をしましたが、いくつか技術的な問題があったため、それの対処法を紹介します。

発生した問題

AdSense の申請をするには当然対象の URL が必要ですが、サブドメインでは申請できないという問題があります。このブログは blog.comame.xyz で配信していましたが、comame.xyz に付け替える必要がありました。
一方、comame.xyz はすでに自前のサーバに割り当てていました。このブログで使用している一部の画像やスクリプトなども comame.xyz から取得していました。そのため、DNS を書き換えるだけではブログのレイアウトが崩れてしまいます。

状況

comame.xyz 上では、すでにいくつかのサービスが動いています。一方で、過去に Docker を使用することで複数のサーバに分割させており、Nginx のリバースプロキシを使ってリクエストを振り分けていました。実際の Nginx のコンフィグの一部は以下のようになっていました。


server {
  location / {
    location / {
       # Docker Compose のサービスの1つとしてホームページを配信していた
       proxy_pass http://home/;
    }
    location /assets {
      # 画像や CSS、JavaScript はここから配信していた
      proxy_pass http://assets/;
    }
  }
}

この設定ファイルからわかるように、アセット配信サーバとホームページ配信サーバは別のコンテナで実行していました。

解決策

ルートディレクトリだけを blog.comame.xyz へのリバースプロキシとすることで解決しました。アセット配信サーバは変わらず /assets で配信しています。


server {
    location / {
        location / {
            # 今まではコンテナに向けていたものを、blog.comame.xyz に差し替え
            proxy_pass: https://blog.comame.xyz/;

            # TLS 周りのエラーが発生したので
            proxy_ssl_server_name on;
        }
        location /assets {
            # 変更なし
            proxy_pass: http://assets/;
        }
    }
}

現状

DNS をいじったわけではないので、blog.comame.xyz にアクセスすることでもブログにアクセスできます。comame.xyz にアクセスすると、今まで表示されていたホームページではなく、ブログが表示されるようになっています。
次のような流れになっています。
User Agent -> comame.xyz -(Nginx が代理アクセス)-> blog.comame.xyz

教訓

止めると影響が大きいサーバとそうでもないサーバは、分けておいたほうが後々役に立つ (適当)
AdSense の申請通るといいな

Ubuntu ユーザー作成

2019-09-18T00:00:00Z

adduser [user]
gpasswd -a [user] [group]

Rootless Docker のインストール方法

2019-09-13T00:00:00Z

今更感は否めないが、備忘録も兼ねて

手順

https://get.docker.com/rootlessからシェルスクリプトをダウンロードする
実行する
$HOME/bin/dockerd-rootless.sh --experimental --storage-driver vfsを実行する

補足

インストールスクリプトを覗いてみたところ、どうやら自動的に Service を作成してくれるらしい。

ドキュメント

https://github.com/moby/moby/blob/master/docs/rootless.md

comame.xyz を ConoHa に移した

2019-07-11T00:00:00Z

このはちゃんかわいい

Docker

今回は、Web サーバを Docker でコンテナに包んでみました。デプロイが圧倒的に簡単になりました。今まではマネージドサービスと自分でサーバを管理するのとの間で振り子のように動いていましたが、これからは移動も楽になる気がします。

速度

今までは Firebase Hosting の US リージョンに置いていたため、RTT が 300 ms くらいありました。流石に堪えられないなーと思っていたのが ConoHa に移した大きな理由の一つです。ConoHa は東京にリージョンがあるので、とてもはやいです (小並感)。

開発のしやすさ

今回は Nginx もコンテナに閉じ込めたので、リモートマシンでも完全に同じ環境でサーバを起動できるようになりました。これにより、今まではサーバにアップロードしないと確認できなかったようなこと (Secure Context で動く API とか) もローカル環境で手軽にできるようになりました。

改善したい点

ログ設定をきちんとしていないので、コンテナを止めるとログも消えてしまう
Nginx の proxy_pass でサービス名を直に指定しているので、すべてのコンテナを立ち上げないとエラーを吐いてしまう

このはちゃんかわいい

Web ページの読み込みパフォーマンスを改善する

2019-04-23T00:00:00Z

TL;DR

レンダリングブロッキング要素を減らす
1. <script>
2. <link rel="stylesheet">
Web フォントのロードを制御する
画像を最適化する
地理的に近い場所にサーバを置く

レンダリングブロッキング要素を減らす

ブラウザのレンダラは、HTML を上から順に (ファイルに記述してある順に) 解釈して DOM を構築します。途中で JavaScript や CSS が埋め込まれている場合は、スクリプトの実行やスタイルの計算が終わるまで DOM の構築は中断されます。これをレンダリングブロッキングと呼びます。

`<script>`

最も効果的な対処法は、async 属性をつけることです。async 属性が付与されたスクリプトは、DOM の構築を妨げません。特に、外部リソースを取得するような場合に効果が発揮されます。一方で、複数の <script> タグにそれぞれ async 属性が付与されていた場合、実行順序が保証されないことに注意が必要です。HTMLScriptElement.onload イベントを活用するのが良いでしょう。

`<link rel="stylesheet">`

<script> タグの場合は async 属性をつけるだけで済みましたね。しかし、<link> タグには非同期に読み込ませるような属性は存在しません。そのため、JavaScript を使用して非同期に読み込ませるような処理を書くことになります。

<head>
  <noscript id="async-styles">
  <link rel="stylesheet" href="style.css">
  </noscript>
  <script>
  window.requestAnimationFrame(() => {
    document.head.innerHTML +=
    document.getElementById('async-styles').textContent;
  });
  </script>
</head>

あるいは、<style> タグを使用して HTML に埋め込んでしまうのも有効です。ただし、再利用性が低いこと、Contents Security Policy との相性が悪いことに注意が必要です。

実際のところ、レンダリングブロックする要素を減らすだけでも相当な効果が見込めます。適切にレンダリングブロックを制御した場合、リソースのダウンロードがすべて完了していなくとも必要最低限の要素だけ表示させることができます。

一方で、JavaScript の実行が必須な Web アプリケーションの場合、表示されているのに操作できない時間が発生することになります。このような場合は、ローディングアニメーションを表示するか、あるいは意図的にレンダリングブロックを発生させるという手段も選択肢となり得るでしょう。

Web フォントのロードを制御する

Web フォントというのはとても便利なものです。導入が簡単にもかかわらず、Web ページの印象を大きく変えてくれます。

しかし、無頓着に Web フォントを使うのは考えものです。ネットワークの速度が遅い環境では、Web フォントのロードが終わるまで文字が表示されないかもしれません。(みなさんも経験ありませんか？) 酷い場合にはユーザーを5秒以上待たせてしまうこともあります。

これは CSS ファイルにほんの数行付け足すだけで解決できます。

@font-face {
  /* ... */
  font-display: swap;
}

この 1 行を付け足すだけで、ブラウザは Web フォントがロードされるまでは、オフラインで使用可能な他のフォントで代わりに表示してくれます！

画像を最適化する

Web ページの平均サイズはどんどん巨大化しています。そして、そのうちの大部分を画像が占めています。画像のファイルサイズを少しでも減らすことができれば、きっともう少しページの読み込みが早くなることでしょう。

WebP など最新のフォーマットを有効活用しましょう。フォーマットに気を配るだけで、ファイルサイズを大幅に削減できます。

<picture> タグを使って複数のフォーマットの画像を選択できるようにすれば、最新のフォーマットに対応していないようなブラウザでも正常に画像を表示させることができます。

最後に>

これらの対策を施したら、最適化の効果の程を確かめてみましょう。Chrome ブラウザを使用しているのであれば、DevTools の Audits タブでパフォーマンスを調査できます。

また、PageSpeed Insights を使用するのもおすすめです。

ここに紹介した以外にもたくさんの高速化の手法があります。調べてみると良いでしょう。

Resource Hints
Service Worker + Cache API
Lazy Load (Intersection Observer v2 とかいい感じに使えそう)
レイアウトを静的に指定する
AMP (Accelerated Mobile Pages)
SSR (Server Side Rendering)

2019/07/04 追記

上にメモした Lazy Loading ですが、Chrome に loading 属性が追加されました。まだ実用段階ではなさそうですが、注目していきたいです。

2019/07/10 また追記

今まで Google Compute Engine の US リージョンに置いていましたが、ConoHa の東京リージョンに置くようにしたらめちゃくちゃ速度が改善しました。地理的な要因も見過ごせませんね。

Safari のブックマークを Chrome にインポートできない問題

2019-04-22T00:00:00Z

現在、macOS 10.14 Mojave において、Safari のブックマークを Chrome にインポートできない問題が発生しているようです。

問題が発生しうる環境

macOS 10.14 Mojave がインストールされたすべてのコンピュータ

現象の回避方法

HTML でブックマークを書き出し、Chrome にインポートする。

Safari を開き、「ファイル」>「ブックマークの書き出し」を実行してください。
Chrome の設定画面を開いてください。
「ブックマークと設定のインポート」を開き、インポート先を「HTML ファイルをブックマークに登録」に指定してください。
「ファイルを選択」ボタンを押し、手順 1 でエクスポートしたファイルを選択してください。

原因

macOS のセキュリティ機能が原因のようです。

現在 Chrome は Safari のブックマークが保存してあるデータベースを直に読み出すようになっています。しかし、Mojave では Safari の閲覧履歴や Cookie を含む機密データを他のアプリケーションが読み取れないような変更が加えられたため、正常にブックマークをインポートできない問題が発生しています。

現在の対応状況

Apple からの情報待ちのようです。

参照

Issue 850225: Mojave: Review importers from other browsers

https://bugs.chromium.org/p/chromium/issues/detail?id=850225

Macbook Pro を買いました

2019-03-12T00:00:00Z

やったぜ！！！！！！！！！！！ これで Windows, Mac, Chrome OS が揃いました。もうちょっと使ってみてからそのうちきちんとしたレビューを書くかもしれません。おそらく。きっと。

ただいま Firebase Hosting

2019-02-04T00:00:00Z

comame.xyz を Google Compute Engine から Firebase Hosting に戻しました。やはり、自動ですべてを管理してくれるのは便利なものですね。
Cloud Functions と接続できるので、今まで Node.js で処理していたものも簡単に移植できました。Cloud Functions も Express ベースなので、コードはほとんどそのままでした。

ただし、HTTP ヘッダを自由に書き換えられないのは盲点でした。firebase.json で書き換えることはできるようなのですが、HSTS Preload だけは諦めるしかなさそうです。標準で HSTS は設定されているので、それで妥協することにします。
自分で Linux サーバを動かすのはとても勉強になりますが、静的なファイルを配信するだけであれば、既存のサービスを使ってしまうのがどうしても楽ですね。

Windows 10 の Media Creation Tool で USB インストールメディアの作成に失敗する

2019-01-25T00:00:00Z

Windows 10 の Media Creation Tool で USB インストールメディアの作成に失敗するなあ、と思っていたら、予想外のところに理由があったようです。すでに同じようなことを書いてある記事がたくさんありますが、備忘録程度に。

問題

USB メモリに Windows のインストールメディアを作成しようとすると、「失敗しました」のようなエラーが表示されてしまう。

解決方法

あらかじめ USB メモリを NTFS でフォーマットしておく。explorer.exe のクイックフォーマットで問題なし。

どうせ NTFS でフォーマットしないと書き込めないのならば、Media Creation Tool 側で自動的にフォーマットしてくれればいいのになあと思いました。

USB セキュリティキーを買った

2019-01-15T00:00:00Z

2 段階認証を楽にしたいと思って飛天の e-Pass FIDO-NFC を購入しました。
Google Authenticator などのコード表示アプリからコードをコピペしなくても、キーを USB ポートに入れるだけでログインできるようになります。フィッシング攻撃に対しても非常に有効です。

サービスごとの対応状況

早速、各 Web サービスごとに対応状況を確認してみました。
PC: ASUS Chromebook C100PA (Chrome OS 72.0.3626.49 Beta)
Android: Google Pixel 3 (Android 9, Chrome for Android 71.0.3578.99)

Google

USB, NFC ともに対応済みでした。Android 端末からでも NFC を利用して認証できます。

Twitter

USB のみ対応済みでした。PC からであれば USB を使って認証できますが、Android からは次のように表示されてしまいます。

Microsoft

設定項目を見つけられませんでした。FIDO 2 でのログインに対応したというニュースを見かけたので、できると思ったのですが。

Amazon

これまた設定項目が見つかりませんでした。「Amazon セキュリティキー」で調べると商品ページしか出てこないんですね...

GitHub

01/16 追記
GitHub を調べ忘れていました。GitHub でも USB, NFC ともに使用可能でした。

(少なくとも僕の身近なところでは) 思ったよりきちんと使えるサービスが少ないということが分かりました。WebAuthn 流行ってほしいです。

8.8.8.8 が DNS-over-TLS に対応したようです

2019-01-11T00:00:00Z

8.8.8.8 で知られる Google Public DNS が DNS-over-TLS に対応したようです。既に Cloudflare の提供する 1.1.1.1 は対応済みなので、耳にしたことはあるかもしれません。
DNS への問い合わせを TLS で暗号化することで、応答の改ざんを防ぐことができます。

Android 9 Pie 以降を搭載している Android スマートフォンであれば、簡単に設定ができます。Windows や Mac OS 等では、OS 標準では DNS-over-TLS がサポートされないようです。

参照: Get Started | Google Public DNS

設定方法

「設定」アプリを開き、「ネットワークとインターネット」>「詳細設定」>「プライベート DNS」と進みます。
「プライベート DNS プロバイダのホスト名」に dns.google と入力します。ブラウザを開き、Web サイトに正常にアクセスできたら完了です。

大事なことを書き忘れた: これは Pixel 3 での操作方法です。端末によって操作が異なるかもしれません。

Let's Encrypt でワイルドカード証明書を発行してみたお話

2018-12-18T00:00:00Z

Let's Encrypt でワイルドカード証明書を取得してみたら驚くほど簡単だったので、記事として残しておきます。

ワイルドカード証明書とは

ワイルドカード証明書とは、サブドメイン全てに一致する証明書です。例えば *.example.com で取得した証明書は、sub1.example.com や sub2.example.com に一致します。

ワイルドカード証明書を使用することで、サブドメイン全てに個別の証明書を発行する手間が省けるため、管理がぐっと楽になります。

手順

今回は Dry Run を使用して、証明書の発行ができることを確認するだけにします。

ワイルドカード証明書を発行するには、DNS を使用してドメインを検証する必要があります。

sudo certbot certonly --dry-run --manual --preferred-challenges dns-01

次に、発行先のドメインを聞かれます。
*.example.com のように入力するだけで、自動的にワイルドカード証明書として発行してくれます。便利ですね。

Please enter in your domain name(s) (comma and/or space separated)  (Enter 'c' to cancel):
*.example.com

最後にドメインの検証です。表示される案内に従って、DNS に TXT レコードを設定してください。

Please deploy a DNS TXT record under the name
_acme-challenge.example.com with the following value:

ランダムな文字列

Before continuing, verify the record is deployed.
Press Enter to Continue

DNS を設定したら、エンターキーを押すと証明書が発行されます。

注意事項・ハマったところ

サブドメインにしか適用されない

先程は *.example.com に対して証明書を発行しましたが、この証明書は example.com には使用できません。

example.com にも対応する証明書を作成するには、次のようにします。

Please enter in your domain name(s) (comma and/or space separated)  (Enter 'c' to cancel):
*.example.com example.com

証明書の自動更新がめんどい

ワイルドカード証明書を発行するときに --manual を指定する必要がありましたが、この影響でいつもどおり sudo certbot renew しても怒られてしまいます。シェルスクリプトを作成して、引数に渡す必要があるみたいです。

デフォルトの certbot の設定では自動更新がなされないので、注意が必要です。

LINE Pay を Google Pay で使ってみた

2018-11-30T00:00:00Z

LINE Pay を Google Pay で使用できるようになったので、早速使い始めてみました。今までスマホを使って支払いをしたことがなかったので、おサイフケータイを使うこと自体が初めてです。

便利なところ

まずはやはり、スマホだけを持って行けば支払いができるという点が最も便利です。近くのコンビニで買い物をしたいときなど、ちょっとした買い物のたびに財布を持ち出す必要がなくなりました。また、レジ前で焦って小銭を探す手間も無くなりました。
また、物理的なカードも併用できるため、非接触型決済に対応していない店舗でも LINE Pay を使用して支払うことは可能です。

不便・改善してほしいところ

端末のロック時は決済をできないようにする機能が欲しいと思います。LINE Pay はプリペイドなので悪用された際の被害はあまり大きくありませんが、やはり気にすると気になるものです。最近は指紋認証が搭載されている Android 端末も増えてきているので、ぜひロックを追加してほしいですね。

もしおサイフケータイに対応している端末をお持ちの方は、この機会にぜひ試してみてください。今なら LINE Pay を Google Pay に登録することで 1000 円分のクレジットを入手できます。
今まで「Suica でいいじゃん」などと思っていましたが、常に持ち歩くスマホだけで済むというのはやはり便利だと思いました。

「Google Pixel まだ見ぬ世界展」に行ってきた

2018-10-21T00:00:00Z

表参道駅前で28日まで行われている、Google Pixel まだ見ぬ世界展に遊びに行ってきました。このイベントでは、11月1日に日本で発売される Google Pixel 3 の実機を試すことができます。
会場は Pixel のカメラ性能を実感できるような造りになっていましたが、カメラ以外にもかなり自由に端末に触れることができました。

Pixel 3

サイズ感

僕は今 ASUS Zenfone Go を使用しているのですが、手があまり大きくないため片手での操作があまり快適とはいえません。しかし、Pixel は横幅が少し小さめにとってあるため、片手での操作も楽々といった印象でした。
逆に、動画やゲームを楽しみたいという方は XL でないと少し物足りないと感じるかもしれません。最も、僕があまりゲームや動画の閲覧をスマホですることが余りないので、あまり自信をもって言うことはできないのですが。

触り心地

裏面もガラスでコーティングされているのですが、手に持った時に落としそうという感じはあまりしませんでした。ツルツルではあるのですが、手に吸い付くような感じとでも言いましょうか。

物理ボタン

端末を握った右側面に、電源ボタンと音量ボタンが付いています。かなりしっかりとしていて、強く押し込む必要がありました。
上から順に電源ボタン、音量ボタンの順についているのですが、個人的には逆向きのが好きです。

カメラ

売りにしているだけあり、やはりすごいなあという印象でした。適当に撮影しても、それなりに絵になる写真は撮れるんじゃないかと思います。カメラについてはあんまりわからない...
この記事の上のほうにある写真も、Pixel で撮影したものです。結構いい感じじゃないですか？

Google Lens

ついにこの機能が日本にもやってまいりました！今まで Google Lens を使ったことがないのですが、結構きちんと認識してくれました。この機能はいろいろと遊べそうなので、今後ほかの端末でも使えるようになるのかが楽しみです。

Playground (AR)

Pixel のカメラアプリに搭載されている、ARCore を使用してマスコットや文字を空間上に配置することができる機能です。実際にこの機能を便利に使うかといわれると正直微妙ですが、床や壁を認識する精度は結構きちんとしている印象でした。少なくとも普通の部屋であれば問題なく使用できるかなという感じです。
空間に配置できるマスコットは Google Play Store からインストールして、自由に追加できるようです。

まだ見ぬ世界展

イベント会場は4階建てのビルになっていて、各階ごとにテーマが設定されています。それぞれの階でテーマに沿った体験をし、すべての階を回ると最後に飲み物がもらえます。
所要時間はおよそ30分程度ですが、同時に入れる人数が決まっている影響で、入場待ちに時間がかかります。

1F Cave

受付です。ここで端末を受け取り、上の階に上がっていきます。

2F Forest

この階では Google Lens を試すことができます。Pixel 3XL も展示してあります。

3F Sky

この階ではインカメラやポートレート撮影を試すことができます。

4F Beyond

この階では ARCore を使用したアプリケーションで遊ぶことができます。

発売前に自由に Pixel を触ることができる良い機会でした。時間があればぜひ足を運んでみてください。
「Google Pixel まだ見ぬ世界展」の詳細を確認する

ブログの新テンプレートが完成！

2018-10-20T00:00:00Z

やっと Blogger 向けのテンプレートが完成しました！
サンプル

HTML も CSS も全て手書きです。Blogger のテンプレートは XML の単一ファイルに書かなくてはならない上に、公式ドキュメントが非常に乏しいので、本当に苦労しました。
できる限り記事自体を読みやすいようなデザインを心がけてみたのですが、デザインが全く分からない人間なのでご意見あったらどんどんお寄せください。

せっかく作ったので、このテンプレートを GitHub かどこかで公開したいなーと思ったりしてますが、広告の配置を一切考えていなかったり、一部の URL をハードコードしていたりで、誰かに使ってもらうのはちょっと難しいかな？

GitHub で見つけたこちらのサンプルコードには非常にお世話になったので、リンクをしておきます。これがなかったらテンプレート造りを諦めてた！
lmatteis/blogger-skeleton | GitHub

今後検索結果画面とかはもうちょっと何とかしたいと思ってます。

App Engine から Compute Engine に移行

2018-08-19T00:00:00Z

今まで Google App Engine Node.js Standard Environment (GAE/Node.js SE) で動かしていた comame.xyz を、Compute Engine に移しました。

理由

Nginx をいじってたら楽しくなってきちゃったから。

感想

予想を遥かに上回るレベルで楽だった
環境依存するコードをほぼ書かなくて済むので、GAE/Node.js SE はいいぞ
Nginx 楽しい
Certbot (Let's Encrypt) すごい楽

環境

Google Compute Engine / f1-micro
Ubuntu 18.04
Nginx, Node.js

手順

GAE で動いていたコードを、Compute Engine に移す。
Nginx の設定ファイルにバーチャルホストの設定を追加する。
Node.js を systemd のサービスとして設定する。
Nginx の設定ファイルに Node.js へリクエスト回す処理を追記する。
Certbot で電子証明書を取得する。

コードを移す

GAE/Node.js SE は GAE に依存する部分が少ないため、ほぼそのままコードを移すだけで完了。静的なファイルを配信する部分だけ、Nginx 側に処理を回すためにコードを削除。

Nginx の設定をする

こんな感じ。80 版ポートの方は省略。

# /etc/nginx/sites-enabled/comame.xyz

server {
    server_name comame.xyz;
    listen 443 http2 ssl;

    # ....
}

systemd に Node.js をサービスとして登録する

多分落ちたときに自動再起動してくれると思う。まだ落ちてないからわからん。

# /etc/systemd/system/nodejs.service

[Unit]
Description=Node.js server

[Service]
WorkingDirectory=/home/hoge
Type=simple
ExecStart=/usr/bin/node /path/to/script.js
Restart=always
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=node
User=hoge
Group=hoge

[Install]
WantedBy=multi-user.target

$ systemctl start nodejs.service でサービスを起動。$ systemctl enable nodejs.service で OS の起動時にサービスを起動するよう設定。

Nginx から Node.js にリクエストを回す

# /etc/nginx/sites-enabled/comame.xyz

upstream node {
    # Node.js は 3000 番ポートで動かすことにした
    server 127.0.0.1:3000;
}

server {
    # ...
    location / {
        proxy_pass http://node;
    }
}

Certbot で電子証明書を取得

コマンド叩くだけで電子証明書が取得できるの、本当にすごいよね。あとは Nginx 側で証明書のパスを指定するだけ。

$ certbot certonly --nginx

Gmail アドレスにおけるピリオドの扱い

2018-07-28T00:00:00Z

Gmail ヘルプフォーラムで回答していると、それなりの頻度で次のような質問が届きます。

ピリオドの有無が違うだけのメールアドレス宛のメールが、私にも届いています。これは他人宛のものではないのですか？

Gmail の仕様では、@ より左側にあるピリオドの有無は無視されるようになっています。この仕様について、実験を交えて少し詳しく解説します。

どのような仕様になっているの？

以下のメールアドレスは、全て同じアカウントのメールアドレスとして扱われます。

example@gmail.com
exam.ple@gmail.com
e.x.a.m.p.l.e@gmail.com

他の人に届くことはないのか？

A. ありません。

実験

では、実験をしてみましょう。まずは、Gmail にアクセスし、新規メール作成ダイアログを開いてください。

ご自身の Gmail アドレスに適当にピリオドを挟んで送信してみる例: example@gmail.com → exam.ple@gmail.com
ご自身の Gmail アドレスから適当にピリオドを外して送信してみる例: your.address@gmail.com → youraddress@gmail.com

解説

手順 1 と 2 どちらの場合も、自分の受信トレイにメールが届いたはずです。 Gmail では、@ より左側にあるピリオドは無視され、全て同じアカウントのメールアドレスとして扱われます。つまり、ピリオドがあろうがなかろうが、全て同じ人に届くということがわかります。

他の人が使っている可能性は？

A. ありません。

実験

Google アカウントからログアウトする
再びログイン画面を開く
普段ログインしているメールアドレスに、適当にピリオドを挟んでログインしてみる
普段ログインしているメールアドレスから、適当にピリオドを外してログインしてみる
アカウントの作成画面を開く
Gmail アドレスの入力欄に、普段ログイン時に使用している Gmail アドレスを入力し、アカウントを作成しようとしてみる
普段ログイン時に使用している Gmail アドレスに適当にピリオドを挟んで入力してみる
普段ログイン時に使用している Gmail アドレスから適当にピリオドを外して入力してみる

解説

手順 3 と 4 どちらでも、ご自身のアカウントにログインできることが確認できたはずです。また、手順 6, 7, 8 では全て「すでに使用されています」と警告が表示されたはずです。つまり、ピリオドの有無が異なるだけの Gmail アドレスは、同一のアカウントとして扱われるということがわかります。同一のアカウントなわけですから、他人が使用している可能性はありません。

まとめ

以上より、Gmail では @ より左側にあるピリオドの有無は無視され、同一のアカウント・宛先として扱われていることがわかります。

Gmail のフォローアップ機能を停止する

2018-07-27T00:00:00Z

新デザインの Gmail には、返信し忘れたメールや対応が必要なメールを判別し、受信トレイの先頭に表示してくれる機能が追加されました。このフォローアップ機能は便利ですが、一方で不要な方もいるでしょう。この機能を停止する方法を紹介します。

モバイル

Gmail アプリを開く
左上のメニューアイコンをタップして、サイドバーを開く
最下部の「設定」を開き、フォローアップ機能を停止したいアカウントを選択する
「アクションの提案」セクション内の「返信とフォローアップ」を開く
停止したいもののチェックボックスを外す

デスクトップ

Gmail を開く
右上の歯車アイコンを押し、設定を開く
「概要」タブの「アクションの提案」セクションに移動する
チェックボックスを外す

有効にする手順もこれと同様です。

#31DaysOfKotlin Week 1 日本語訳

2018-04-30T00:00:00Z

この記事は、@AndroidDev による #31DaysOfKotlin — Week 1 Recap を勝手に日本語訳したものです。基本的な文法からちょっとした TIPS まで様々なことが紹介されているので、知らないものがあったらぜひ使ってみてください。

Day 1: Elvis Operator (エルビス演算子)

Null チェックをよりスマートにするには、エルビス演算子を使ってみましょう。 Null を別の値に置き換えたり、あるいはreturnしたりもできます！ Docs: Elvis Operator

val name: String = person.name ?: “unknown”
    val age = person.age ?: return

Day 2: String Templates (文字列テンプレート)

文字列に変数を埋め込むには、変数名の前に$を入れましょう。式を入れるには${expression}のようにしてください。 Docs: String Templates

val language = “Kotlin”

    // “Kotlin has 6 characters”
    val text = “$language has ${language.length} characters”

Day 3: Destructing Declarations (分解宣言)

Android KTX では、色の成分値を割り当てるのに分解宣言を使用します。自作のクラス内で分割代入を使用できますし、既存のクラスを拡張して追加することも可能です。(日本語名称について参考にした記事) Docs: Destructing Declarations

// 色要素
    val (red, green, blue) = color

    // 四角形
    val (left, top, right, bottom) = rect

    // 座標
    val (x, y) = point

Day 4: When Expression (When 式)

条件分岐をよりよく書くにはwhen式を使ってみましょう。 Kotlin のwhen式は、文字列リテラルや Enum、Range など何にでも使用できます！任意の関数を呼ぶことも可能です。 Docs: When

class Train(val cargo: Number?) {
        override fun toString(): String {
            return when (cargo) {
                null, 0 -> "empty"
                1 -> "tiny"
                in 2..10 -> "small"
                is Int -> "big inty"
                else -> "$cargo"
            }
        }
    }

Day 5: For loops, range expressions and destructing (For ループと Range、分解宣言)

forループは Kotlin の Range や分解宣言を使うと便利です。 Docs: Ranges, Destructuring

// 1 から 100　まで
    for(i in 1..100) {…}

    // 1 から 100 まで降順
    for(i in 100 downTo 1){…}

    // 配列の要素を1つ飛ばしで
    val array = arrayOf(“a”, “b”, “x”)
    for(i in 1 until array.size step 2 ){…}

    // 配列の要素を分解宣言で取り出す
    for((index, element) in array.withIndex()) {…}

    // Map の要素を分解宣言で取り出す
    val map = mapOf(1 to “one”, 2 to “two”)
    for( (key, value) in map){…}

Day 6: Properties (プロパティ)

Kotlin では、クラスのプロパティのゲッターとセッターが自動生成されます。必要に応じてカスタマイズすることも可能です。 Docs: Properties

class User {
        // properties
        val id: String = “” // 変更禁止。ゲッターのみ

        var name: String = “” // デフォルトのゲッターとセッター

        var surname: String = “” // カスタムゲッターとデフォルトのセッター
          get() = surname.toUpperCase() // custom getter declaration

        var email: String = “” // デフォルトのゲッターとカスタムセッター
          set(value) { // カスタムセッターの宣言
              // “value” = セッターのパラメータ
              // “field” = 自動生成されるバッキングフィールド
              if(isEmailValid(value)) field = value
          }
    }

Day 7: Data Classes and equality (データクラスと等価性)

データの保持だけが目的であれば、データクラスを使ってみましょう。構造的等価性 (Structual Equality) をチェックするequals()やhashCode(),toString(),copy()などの関数が自動生成されます。 Docs: Data Classes, Equality

data class User(
        val name: String,
        val email: String,
        val address: Address,
        …
    )
    public class UserListDiffCallback: DiffUtil.Callback() {
        override fun areContentsTheSame(
             oldItemPosition: Int,
             newItemPosition: Int
        ): Boolean {
        // 自動生成された比較メソッドを使用
        return newUserList[newItemPosition] ==
               oldUserList[oldItemPosition])
    }

新しいデザインの Gmail がリリースされました

2018-04-26T00:00:00Z

新しいデザインの Gmail が、昨日リリースされました！マテリアルデザインが適用されたほか、カレンダーや ToDo リストが使いやすくなっているようです。新しい Gmail をお試しください。- Google Japan Blog

変更点

スヌーズ機能が追加された

この機能は Inbox by Gmail からの逆輸入ですね。メールを一旦受信トレイから非表示 (アーカイブ) にし、指定した日付に再び受信トレイに戻す機能です。

メールに対しての操作が簡単になった

これまた Inbox からの逆輸入です。メールの一覧画面から、今までより簡単にアーカイブ、削除、移動などの操作が行えるようになりました。マウスカーソルをメールに合わせると、下の画像のようなアイコンが表示されます。

添付ファイルが見やすくなった

メールに添付ファイルがある場合、メールの一覧画面に今までよりわかりやすく表示されるようになりました。1つ面白いのが、Google ドキュメントのファイルでも添付ファイルとして表示される点です。これらのファイルは、Gmail 以外から見るとただの URL としてしか表示されません。Google だからこその連携といえますね。

Keep やカレンダー、ToDo リストがサイドバーに表示されるようになった

Google Keep や Google カレンダー、ToDo リストが画面の右側に常駐するようになりました。これらの機能をよく使う人にとっては、アクセスがかなり楽になると思います。

ローディングアニメーションがちょっとおしゃれになった

小さな変更点ですが、個人的にはかなり気に入っています。ロード時に表示される Gmail アイコンの封筒がスルッとアニメーションするようになりました。

移行方法

受信トレイの右上に表示されている歯車アイコンをクリックし、「新しい Gmail を試す」を選択してください。新デザインに切り替えたあとでも、同様の手順でいつでも従来のデザインに戻すことができます。

感想

今回のアップデートは、Inbox からの逆輸入が多かったように思います。どれも使いやすい機能ですので、ぜひアップデートしてみてください。

blog.comame.xyz

MetalLB が ARP 応答を返していなかった問題に対処した

原因

作業ログ

2023年を振り返る

開発

Go 言語

自宅サーバー

DJ

お絵かき

あそび

スプラトゥーン3

TRPG

2024 年はどうする？

お仕事

DJ

お絵かき

自宅サーバー

39noPops 5th Anniversary

イベント

セットリスト

ロジクール K380S を買った

感想

日本語配列のキーボードを英語配列設定で使っている

運用・感想

Kubernetes のログを DaemonSet で収集する

環境

ログを取得する

DaemonSet で配置する

CRAZYBUS の BGM を生成する

やり方

十二平均律の周波数を求める

OscillatorNode で矩形波を生成する

CRAZYBUS の BGM を作る

ちなみに

Music Unity 2023

ローカルで動かしている開発環境のポートをインターネットからアクセス可能にする

やり方

サーバの sshd の設定をいじる

ロードバランサーを設定する

サーバに対して SSH ポートフォワードをする

感想とか

Chrome のパスワード同期を直す

手順を試す前に

発生していた問題

手順

インポートエラーになるパスワードを削除する

同期データの削除

Windows を再起動する

パスワードをインポートして、同期を再開する

VRoid でアバターになろう！

どういうこと

必要なもの

Kalidoface 3D を試そう

OBS の設定

VRoid Studio

最後に

トラブルシューティング

Kalidoface 3D でカメラが選択できない

Kalidoface 3D のアバターが動かなくなる

Mastodon インスタンスを立てた

モチベーション

やったこと

Mastodon の構築

OpenID Connect のセットアップ

得られたこと

Kubernete Dashboard の認証を通す

ところで

PowerShellスクリプトを特権で起動する

SoftEther で自宅ネットワークを公開する

やりたかったこと

手順

VPS

自宅

動作確認

考えていること

Kubernetes のコンテナランタイムを containerd にする

手順

kubectl drain <node> が正しく完了しなかった

containerd の cgruop ドライバー

`OscillatorNode` で矩形波を生成する

`kubectl drain <node>` が正しく完了しなかった

`kubeadm upgrade apply v1.24.1` で警告が出た

`kubeadm upgrade plan` に警告がでる