結論
components: { Hoge } と書くべきところを component: { Hoge } と書いていたから（複数形にしていなかった）。
感想
一度通っておけば以後は間違えないタイプのやつです*1。
*1:そういう意味では一度通ったというのは意義があったことなのかもしれない
ArchiveBox の使いどころ
ArchiveBox とは
いわゆる「魚拓」の OSS 版です。
スクリーンショット
使い方
使い方は簡単です。公式で推奨されているように Docker Compose でほぼ事足りると思います*1。
設定
設定はデータボリュームのディレクトリ内の ArchiveBox.conf に書きます。WGET_USER_AGENT と TIMEOUT を適切に設定しないとダウンロードに失敗することが多かったので、そのあたりの設定をいい感じにいじります*2。
使いどころ
ここからが本題です。
いわゆる「魚拓」がしたいならばそれこそ特化したウェブサービスを用いるほうが簡単です。たとえば archive.today や Raindrop などです。僕は Raindrop に課金して使用しています。
となると、ArchiveBox の使いどころは「手元で気軽に取得データを再利用できる」ことにあると思います*3。
使ってみると分かりますが、ArchiveBox は Webアプリ として操作することが主体ではなく、コマンドで取得することが主体となっているように感じます。すなわちこれは、コマンドをパイプしたり cron で定期取得したりシェルスクリプトなどで一連の動作に組み込んだりといった目的で用いることを念頭に置いていそうです。そして現状の他 Webサービス の存在を考えると、それこそが ArchiveBox の使いどころであると感じています。
あとは気軽にスクショや PDF、warc が取得できることは魅力でしょう。さらに archive.org に登録してくれるということもなかなかに便利です。これらのことをコマンド一発でシュッとやってくれるということに ArchiveBox のアドバンテージを見ています。
さらに、既存サービスだと取得に失敗したり文字コードが期待どおりでなかったりする場合の補助的な用途にも便利です。
補足
このような OSS やツールで気になったものは、まずとにかく Docker で入れて使ってみるのが良いと思います。使っているといろいろと分かってくることもありますし*4、データの永続化や設定を煮詰めた上で改めて初期構築する、ということもできるからです。
机上で設定をしていざ本格運用、というのは現実のプロダクト同様に手戻りのリスクが高いでしょう。
Yarn v3 (v2) を入れたら "scripts" が実行できなくなった場合
結論
ワイルドカードが含まれている場合はクォートでくくりましょう。
具体例
例えば、以下のような書き方だとエラーになります。
"scripts": { "hoge": "yarn clean && run-s -c hoge:*",
ワイルドカードが含まれる場合は以下のようにクォートでくくります。
"scripts": { "hoge": "yarn clean && run-s -c \"hoge:*\"",
補足
シングルクォートでくくるかダブルクォートでくくるかですが、エスケープする手間と可読性を考えるとシングルクォートの方がいい気がします。
Windows 11 では Serato で Mixtrack Pro II は使えないっぽい
注意
2021/09/29 現在の情報です。
結論
標題のとおりです。接続するとステータスバーに「接続中……」というメッセージが出ますが、数分後に接続が失敗した旨が表示されます。
Windows 自体にはデバイスは正しく認識されています。
Serato とは
DJ ソフトウェアです。
Mixtrack Pro II とは
Numark の DJ コントローラです。
購入したのは 2014年 でした。
補足
VirtualDJ 2021 では正しく認識されました。
GitHub Actions の Runner を自前で立てる（セルフホスト self-hosted）ことについて
箇条書きで書いていきます。
公式ドキュメント
大前提
- パブリックリポジトリでは使う意義はほぼ無いと思います
- パブリックリポジトリは GitHub謹製 のランナーの時間制限がないから
- セルフホストのランナーにはセキュリティ上の懸念が生じる可能性があるから
- つまり、以下の内容は全てプライベートリポジトリで利用することが前提となります
インストールについて
- 出てきたスクリプトをコピペして実行するだけなのですぐにできる
- arm64 にも対応しているほか、Windows や Mac にも対応している
実行について
- 永続的に実行指定ならば
nohup ./run.sh &とかしたほうがいい- 止める際には
bin/Runner.Listener runのプロセスを止める
- 止める際には
- 複数台ランナーを立てればそれだけ並列実行ができる
- GitHub謹製ランナーだと並行数は（確か）3
- ワークフローの YAML の中の
runs-on:に、インストールする際に命名した「タグ」を指定することで実行するランナーを振り分けられる- インストールマシンごとの特性に合わせて振り分けられる
良さそうなところ
- 属人化がしなさそう
- self-hosted 自体ではいじるところはなにもない
- workflow の YAML だけに集中できる
- Jenkins の苦労はない
- ランナーがインターネットから見える必要はない
- ランナー側から GitHub につなげてトンネル作っている（はず）から
- 必要に応じて起こしたり寝かしたりできる
- 家でラズパイ買って置いとけばいい気がする
- あるいは安心定額のVPS
- 並列数を 4 以上にしたい場合にはバカバカ立てるとGitHubホストランナーに勝てる
- あくまで並列数についての話
注意したほうがいいところ
- ランナー専用のマシンを用意すべき
- マシングローバルにインストールしたものは「掃除」ができないで永続的に残る
- 依存が生じてしまう可能性がある
- OS のパッケージやE2Eテスト用のブラウザのインストールで問題になる
- マシングローバルにインストールしたものは「掃除」ができないで永続的に残る
- GitHub謹製のホストランナーが落ちていたからといって、これで保険になるわけではない（はず）
- GitHub Actionsというシステムが落ちていたら意味がない
- ただしホストランナー「だけ」が落ちている場合にはこれで救われるかもしれない（推測）
- 「ホストのインストールコマンドを実行したときのユーザがコマンドの実行ユーザになる」ので sudo などの権限に注意する
- 環境汚染を考慮すると専用ユーザを作るのは必須
- そして専用マシンにすべき
- sudoersでパスワードいらずの専用ユーザを作って対応
- しかしpublicリポジトリで他人にSSHに入られたら死ぬ
- 結論としては sudoers しないほうがいいと思う
- グローバルインストールでアーキテクチャ依存のライブラリがあるとハマる
- たとえば
deb [arch=amd64] https://packages.microsoft.com/repos/edge stable main- 上記は arm64 は提供されていない
- 提供されていたとしても、OSを調べて if 文で分岐してインストールパッケージを分けるみたいなところまで掘る？
- たとえば
- 環境汚染を考慮すると専用ユーザを作るのは必須
結論
- APIを定期的に叩いたりバッチ処理をしたり単体コマンド実行をしたりするcronを走らせるのが現実的
- ナイトリービルドとかナイトリーテストとか
- Release Drafter とか PR Labeler とか
- そのジョブだけ self-hosted に分散する
- 時間が長いものについては時間消費を防ぐために有用
