ZoomではスペースキーでMute解除ができますが、Teamsの会議では特許の関係でミュート解除がCtrl-Shift-Mになっています。
マウスをクリックしたり、Ctrl-Shift-Mを押すのに時間がかかるので、一発キーでできそうなマクロ可能なキーボードを購入しました。
1つのキーで良いのですが、1つでも値段は変わらず、さまざまな種類があります。300円のものもありますが、送料が1,500円かかるものもあるので、Amazon Primeで1,299円のものを選びました。
キートップにCopyやPasteなどの文字が書いてあるのは気にしません。
]]>AmazonのページにはWindows用のマクロ登録プログラムのURLが書いてあり、同梱のマニュアルにはQRコードが付属していますが、私はLinuxを使用しているので、
$ lsusb
...
Bus 001 Device 109: ID 1189:8890 Acer Communications & Multimedia
上記のコマンドを実行し、1189:8890を検索した結果、GitHubでkriomant/ch57x-keyboar-toolを見つけました。
README.mdによると、このタイプのミニキーボードはみなさんが1189:8890を使用しているようです。
ビルドおよびインストールツールとしてRustupというものが必要なようなので、Debianパッケージをインストールします。
$ rustup default stable
$ cargo install ch57x-keyboard-tool
上記のコマンドを実行すると、ビルドされたファイルが~/.cargo/bin/ch57x-keyboard-toolにインストールされます。
MINI KeyBoardはレイヤーがなく、横に並んだ2つのキーがありますので、以下のようなファイルを作成します。
orientation: normal
rows: 1
columns: 2
knobs: 0
layers:
- buttons:
- [ "<179>", "ctrl-shift-m" ] # 好きなキーに
knobs:
上記の設定をyour-config.yamlという名前のファイルに保存し、以下のコマンドで確認および書き込みを行います。
$ ~/.cargo/bin/ch57x-keyboard-tool validate < your-config.yaml # 確認
$ sudo ~/.cargo/bin/ch57x-keyboard-tool upload < your-config.yaml # 書き込み
これで簡単にMute解除ができるようになり便利です。
]]>毎回のことですが、今月も新しいGitLabのバージョンがリリースされたのでアップグレードしました。しかし、またしてもエラーによりアップグレードができませんでした。
以下のエラーメッセージが表示されました。
gitlab-ce-gitlab-ce-1 | PG::UndefinedObject: ERROR: constraint "fk_262d4c2d19" for table "ci_pipelines" does not exist
gitlab-ce-gitlab-ce-1 | /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migrations/constraints_helpers.rb:253:in `rename_constraint`
同様のエラーが以前にも発生していないか調べてみました。以下の情報を見つけました:
gitlabhq_development=# \d+ ci_pipelines
...
Referenced by:
TABLE "ci_pipelines" CONSTRAINT "fk_262d4c2d19" FOREIGN KEY (auto_canceled_by_id) REFERENCES ci_pipelines(id) ON DELETE SET NULL
TABLE "ci_pipeline_chat_data" CONSTRAINT "fk_5b21bde562" FOREIGN KEY (pipeline_id_convert_to_bigint) REFERENCES ci_pipelines(id) ON DELETE CASCADE
TABLE "p_ci_builds" CONSTRAINT "fk_87f4cefcda" FOREIGN KEY (upstream_pipeline_id) REFERENCES ci_pipelines(id) ON DELETE CASCADE
TABLE "p_ci_builds" CONSTRAINT "fk_a2141b1522" FOREIGN KEY (auto_canceled_by_id) REFERENCES ci_pipelines(id) ON DELETE SET NULL
TABLE "p_ci_builds" CONSTRAINT "fk_d3130c9a7f" FOREIGN KEY (commit_id) REFERENCES ci_pipelines(id) ON DELETE CASCADE
[Ensure that all tables that reference ci_pipelines have partition_id columnより引用]
上記の情報から、ci_pipelinesを参照しているテーブルにfk_262d4c2d19という制約が存在しないことがわかりました。
次に、以下の手順で修正を試みました:
上記の手順で修正を行ったところ、次のエラーが発生しました:
gitlab-ce-gitlab-ce-1 | Caused by:
gitlab-ce-gitlab-ce-1 | PG::UndefinedObject: ERROR: constraint "fk_fb57e6cc56" for table "ci_stages" does not exist
gitlab-ce-gitlab-ce-1 | /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migrations/constraints_helpers.rb:253:in `rename_constraint
ので、同様に
Foreign-key constraints:
"fk_c5ddde695f" FOREIGN KEY (pipeline_id_convert_to_bigint) REFERENCES ci_pipelines(id) ON DELETE CASCADE
"fk_fb57e6cc56" FOREIGN KEY (pipeline_id) REFERENCES ci_pipelines(id) ON DELETE CASCADE
[Prepare foreign key constraints for bigint ci_stages.pipeline_idより引用]
上記の情報から、ci_pipelinesを参照しているテーブルにfk_262d4c2d19という制約が存在しないことがわかりました。
次に、以下の手順で修正を試みました:
$ docker compose exec gitlab-ce bash
root@gitlab-ce:/# gitlab-ctl status
run: gitaly: (pid 307) 30s; run: log: (pid 305) 30s
run: gitlab-kas: (pid 373) 19s; run: log: (pid 372) 19s
run: gitlab-sshd: (pid 311) 30s; run: log: (pid 310) 30s
run: logrotate: (pid 309) 30s; run: log: (pid 306) 30s
run: postgresql: (pid 375) 19s; run: log: (pid 374) 19s
run: redis: (pid 312) 30s; run: log: (pid 308) 30s
run: sshd: (pid 38) 80s; run: log: (pid 37) 80s
root@gitlab-ce:/# gitlab-psql
psql (13.11)
Type "help" for help.
gitlabhq_production=# ALTER TABLE ci_stages ADD CONSTRAINT fk_fb57e6cc56 FOREIGN KEY (pipeline_id) REFERENCES ci_pipelines(id) ON DELETE CASCADE;
ALTER TABLE
gitlabhq_production=# \q
root@gitlab-ce:/# exit
としらたら、無事にマイグレーションが終わって無事に16.6.0が起動しました。
GitLabのissueに入れるべきだけど、午前4時で眠いのでまた
]]>CodyはSourcegraph製のGitHub Copilotです。
今まで似たようなものとして、Emacsでも使えるCodiumや、AWS CodeWhispererを使っていましたが、これはその一環です。
Sourcegraph Enterpriseのライセンスがある人は、Self Hostedの人もSourcegraph Codey Gatewayを利用してコード補完やChatが使えますが、試してみたところうまく行きませんでした。
Sourcegraph Cloudのサブスクリプション画面を開いてみると、CodyはEnableになりません。
確かに、Soucegraph 5からは有料になりましたが、Sourcegraph 4からUpgradeしたユーザーに配布された無料ライセンスでは無理かもしれません。
というわけで、OpenAIをLLMプロバイダとして利用します。
]]>Debian用のものは見つからなかったので、Ubuntu用のgoogle-drive-ocamlfuseを使用します。
# cat < /etc/apt/sources.list.d/alessandro-strada-ubuntu-ppa-bionic.list >> EOF
deb [signed-by=/usr/share/keyrings/google-drive-ocamlfuse.gpg] http://ppa.launchpad.net/alessandro-strada/ppa/ubuntu xenial main
deb-src [signed-by=/usr/share/keyrings/google-drive-ocamlfuse.gpg] http://ppa.launchpad.net/alessandro-strada/ppa/ubuntu xenial main
EOF
# gpg --keyserver keyserver.ubuntu.com --recv-keys AD5F235DF639B041
# gpg --export AD5F235DF639B041 >/usr/share/keyrings/google-drive-ocamlfuse.gpg
# apt update
# apt install -y google-drive-ocamlfuse
使い方
$ google-drive-ocamlfuse -docsmode msoffice
$ mv ~/.gdfuse ~/.config/gdfuse
で認証しconfigをMS Officeモードで作って、.configの下のほうが好みなので移して
$ google-drive-ocamlfuse ~/GoogleDrive
でマウントします。
$ google-drive-ocamlfuse -cc
調子が悪い場合はキャッシュをクリアしてください。
参考:
]]>問題点:
AirCampusの視聴中にメモ欄を使う場合に、右側に表示されるメモ欄では、CTRL + ENTERでメモが保存されます。しかし、下のスクリーンショットに示す、ビデオの下の「メモ」タブの場合には、「保存」ボタンを押さなければメモが保存されません。
このため、視聴中にキーボードからマウスに手を移動しなければならず、集中力が途切れるという問題があります。
解決策:
上記の問題を解決するために、UserScriptを作成しました。このUserScriptを導入すると、「メモ」タブでも、CTRL + ENTERでメモが保存されます。これにより、視聴中にキーボードから手を移動する必要がなくなり、集中力を保ったままメモを作成できます。
これにより、AirCampusでのメモ作成がよりスムーズに行えます。
これにより、メモ作成の効率が向上し、集中力を保ったまま学習を進めることができるようになると思います。
]]>昨日、BBTアルムナイセミナーに参加したら、OpenAI APIを試してみるためのAPIを公開してくれました。tDiaryのプラグインを使用して、本家のOpenAI APIでも正常に動作するかテストしてみます。
残念ながらGPT-4は使用できないAPIキーでしたが、本家のOpenAI APIでのテストは成功しました。
]]>今日の学び「ChatGPTでも入れたものしか返ってこない所詮は計算機」
最近、GitHub yGuy/chatgpt-mattermost-botを利用して、SlackもどきのMattermostでChatGPTもどきをやっているのだけど、オープンソースなので、色々手を入れている。
今回は、「トークン数が分かったほうが良いよな」と、返信の最後にトークン数を入れるようにした。
そしたら、最後の一行に足したつもりが、なんか二行出るようになった。
なんか、間違えたかな? と思って調べてみると、これチャットなので、過去の会話をassistantとしてプロンプトに入れているのだけど、それを見てChatGPTが真似して最後の行に自分でトークン数を入れて回答するようになっていた🎇
なんて素直な。いや、これは意図を理解して、入れてほしくなかったんたけど・・・
システムメッセージは別のPostについて、assistantに入れないように改良してあげないとな!
OpenAI APIの活用方法を考えて進めていると、色々な気づきがあります。
]]>- auto-commit ChatGPT以前のOpenAI API公開で作られているので、わりと早かった。去年から使っているけど、PullRequestは投げてない。
- di-sukharev/opencommit TypeScriptなのとカラフルなUI、絵文字を使ったメッセージを作ってくれるし。大きな変更はコミット単位、ファイル単位、行単位に分割して生成してくれる。
- shanginn/git-aicommit プログラムが小さい
]]>- /nfacha/OpenAI-Gitlab-PR-Review どんな修正をしたか、無駄なコードはないか? バグやセキュリティリスクが無いかレビューしてくれる。バグとかセキュリテイの問題を発見してくれたことはないし、無駄なコードの修正方法はバグっていた。
]]>- yGuy/chatgpt-mattermost-bot Mattermostのスレッドを追っかけてChatGPTが返事をしてくれる。
]]>- tdiary/tdiary-contrib plugin/chatgpt_elaborate.rb 日記を推敲してくれる。自分で作った。
]]>今日の学び「jornalctlはロケールに合った日付で返す」
最近、logcheckのメールが大きくなっています。内容を見てみると、以下のようになっていました。
5月 30 12:05:54 on-o.com sm-mta[1699926]: 34U35qGY1699926: milter=greylist, action=data, continue
5月 30 12:05:54 on-o.com sm-mta[1699926]: 34U35qGY1699926: milter=greylist, action=eoh, continue
5月 30 12:05:54 on-o.com sm-mta[1699926]: 34U35qGY1699926: milter=greylist, action=header, continue
時間が日本語になっているため、フィルターをすり抜けてしまっている可能性があり、ロケール設定が悪いことが原因かもしれません。ただ、システムロケールを変えるのは面倒です。今回、調べてみたところ、システムロケールをLANG=ja_JP.UTF-8にしているため、rsyslogのロケールがja_JPになっていてログの日付が日本語になっているのだと思いましたが、/var/log/mail.logを見ると時間は正しくなっていました。
2023-05-28T00:02:28.983494+09:00 on-o.com sm-mta[2451659]: 34RF2S4v2451659: milter=greylist, action=connect, continue
2023-05-28T00:02:29.008603+09:00 on-o.com sm-mta[2451659]: 34RF2S4v2451659: milter=greylist, action=helo, continue
一部だけ日本語になっているのかとgrepで探し回ったけど、見つかりませんでした。
そうこうしているうちに、logcheckがjorunalctlでログを取得していることに気がつきました。以下がそのログです。
$ journalctl |grep milter=greylist|head
5月 29 21:40:30 on-o.com sm-mta[4067371]: 34TCeUN04067371: milter=greylist, action=connect, continue
5月 29 21:40:31 on-o.com sm-mta[4067371]: 34TCeUN04067371: milter=greylist, action=helo, continue
あたり🎯今回の問題はこれによるものでした。
--- /etc/cron.d/logcheck.org 2010-01-03 15:18:23.000000000 +0900
+++ /etc/cron.d/logcheck 2023-06-03 06:04:02.863906271 +0900
@@ -2,6 +2,7 @@
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
+LANG=C
@reboot logcheck if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck -R; fi
2 12 * * * logcheck if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck; fi
対策として、cronで起動されるlogcheckにLANG=Cを加えて、様子を見ることにしました。
]]>Today's lesson: "journalctl returns a date that matches the locale"
Recently, logcheck emails have become too large. Upon reviewing the content, it appears as follows:
Since the time is in Japanese, it may have slipped through the filters and the cause may be due to bad locale settings. However, changing the system locale is a hassle. Upon investigation, it was found that rsyslog's locale was ja_JP because the system locale was set to LANG=ja_JP.UTF-8, causing the date on the logs to be in Japanese, but upon checking /var/log/mail.log, the time was correct.
Although I searched with grep to find parts that were in Japanese, I couldn't find any.
In the meantime, it was noticed that logcheck was obtaining logs with jorunalctl. The following is the log:
This was the cause of the problem.
As a countermeasure, LANG=C was added to logcheck launched by cron, and the situation will be monitored.
]]>一度メンションしたスレッドには答えてくれるけど、最初はメンションしないと出てこないのが面倒だけど、ChatGPTを普通に使えるのは便利。
いつものように、Azure OpenAI Serviceで使えるようにする、Pull Requestを投げた。
]]>