test: 2025

2025年9月15日月曜日

いつのまにかperplexity cometが来てた

よーし！

がんばるぞ！

ですよね。

tailscale, ZeroTier

そういや有料でも複数ネットワークもてないんだったわ・・・・

格安SIMの場合tailscaleの方が安定してそう。

Tailscale vs ZeroTier 仕様比較
項目	Tailscale	ZeroTier
ネットワークモデル	1アカウント=1 Tailnet	複数Network IDを作成可能
複数ネットワーク同時接続	不可（アカウント切替のみ）	可能（同時参加OK）
無料プラン規模	最大3ユーザー / 100デバイス	10デバイス / 最大3ネットワーク
有料プラン	Starter: $6/ユーザー Premium: $18/ユーザー	Essential: $18/月（10台含む＋追加課金） Premium: $250/月（125台含む）
ACL / アクセス制御	グループ/タグ/高度ACL（Starter以上）	ルールエンジンで柔軟設定（Essential以上）
SSO / 管理機能	StarterでSSO可、PremiumでSCIMや承認フロー	EssentialでSSO、複数管理者、監査ログ
中継 / NAT越え	STUN + DERP中継（分散）	STUN + リレー / スーパーノード
多社分離運用	会社ごとに別Tailnet（別アカウント必要）	ネットワークを複数作成して同時参加可能
セルフホスト	Headscale（OSS代替）あり	ZeroTier Centralを使わず自ホスト可能

※2025年9月時点の仕様。詳細は公式サイトを確認。

Notionデータベース

1秒あたり約3リクエストが上限。

時間当たりの制限はない。

「3リクエスト/秒 × 60秒 × 60分 × 24時間」で

1日あたり約259,200リクエストまで理論上OK。

ちょっとしたログを取るのに、google spread sheetより良さげ。

SurrealKV

まだデフォルトのストレージエンジンはRocksDBだが、

SurrealKVってファイルにも書けるらしい。

v3.0.0-alpha.7でガベージコレクションの修正があったので、おそらくその辺がまともになったと予想。

だってrustでガベージコレクションなんて存在しないだろ？

実データのメモリ管理用のことだと思う。ソース見てないけど・・・

公式のベンチマーク。

https://surrealdb.com/blog/beginning-our-benchmarking-journey?utm_source=chatgpt.com

そうだった！前調べたわ！8倍遅いの忘れてた！！！

VPSでtailscale

🔧 実際に開けておくべきもの（最低限）

アウトバウンド通信（サーバー → インターネット）
- tcp/443 → コントロールサーバーに接続するため必須
- udp/3478 → STUN（NATトラバーサル）用に開けておくとP2Pが成功しやすい
- udp/41641 → WireGuard ポート（デフォルト）
インバウンド通信（サーバー ← 他のTailscaleノード）

udp/41641 をサーバー側で開けておくと、直接接続（直結ピア）が成功しやすくなる
これが閉じていると、DERP (Tailscaleの中継サーバー) 経由通信になり、レイテンシが上がる

# Tailscaleインターフェースの通信を全許可

sudo ufw allow in on tailscale0 comment 'Tailscale interface inbound'

sudo ufw allow out on tailscale0 comment 'Tailscale interface outbound'

# コーディネーションサーバー通信（認証・設定取得）

sudo ufw allow out 443/tcp comment 'Tailscale control plane'

# STUN（NAT越え用）

sudo ufw allow out 3478/udp comment 'Tailscale STUN'

# Tailscaleメイン通信ポート（P2P直接接続用）

sudo ufw allow in 41641/udp comment 'Tailscale WireGuard inbound'

sudo ufw allow out 41641/udp comment 'Tailscale WireGuard outbound'

# 設定確認

sudo ufw status numbered

2025年9月14日日曜日

軽量の顔認識を用意してみる

gradface.netではGPUを使っているが、CPUだけで動作するものを用意したい。

2025年9月時点でのメモ。

推奨構成（CPU向け）

1. 検出（Face Detection）

SCRFD-500M / 2.5G
- InsightFace に同梱。ONNX Runtime で CPU 推論しても数 ms〜数十 ms 程度（解像度にもよる）。
- 検出精度と速度のバランスが良い。
代替案：YOLO-Face（YOLOv5ベース）。ただしやや重め。

2. 埋め込み（Feature Embedding）

ArcFace r50 / r100 (glint360k 事前学習)
- 112×112入力、CPUでも数十ms程度で動く。
- 精度は IJB-C TAR@FAR=1e-4 で 97-98% 程度。
軽量重視なら MobileFaceNet や PartialFCで学習された軽量モデル も選択肢。

3. 全体パイプライン

ONNX Runtime (Rust or Python)
- CPUでもマルチスレッド利用可能 (intra_op_num_threads 設定推奨)。
前処理：BGR→RGB、112×112にリサイズ、mean/std正規化。
後処理：出力ベクトルをL2正規化、コサイン類似で判定。

「そこそこの精度」での目安

モデル	精度 (IJB-C)	CPU速度 (i7-12700程度)	備考
ArcFace-R50	高 (97%+)	40〜50ms/顔	バランス型
ArcFace-R100	さらに高	70〜90ms/顔	高精度重視
MobileFaceNet	中〜高 (95%前後)	10〜15ms/顔	軽量・高速
FaceLiVT-tiny	高	20〜30ms/顔	Transformer混合だが軽い

LVFace はかなり大きいモデルです。

LVFace の特徴

Vision Transformer ベースの顔認証モデル
→ パラメータ数は ResNet 系の ArcFace よりもずっと多い（100M～数百M パラメータ級）。
学習データ：WebFace42M など巨大データセット
精度重視：IJB-C, IJB-B, CFP-FP など主要ベンチマークで SOTA 近い性能
トレーニング手法：Progressive Cluster Optimization (PCO) を導入して ViT の収束と識別能力を最適化
用途：サーバーや GPU 前提のバッチ推論、クラウド向け認証システム

モデルサイズとリソース

モデルサイズ：数百 MB 級（ViT-Large クラスだと 400〜500MB 近くになることも）
入力解像度：224×224 以上（ArcFaceの112×112より重い）
計算コスト：CPU 単体でリアルタイムはほぼ不可能（数秒かかる場合も）
GPU前提：A100 や RTX 4090 などのGPUでバッチ推論すると真価を発揮

まとめると

はい、かなりデカいです。
「そこそこの精度＋CPUでリアルタイム」用途なら、LVFace は明らかにオーバースペック。
ArcFace r50/r100 や MobileFaceNet, FaceLiVT-tiny の方が圧倒的に扱いやすいです。

**Transformer混合モデル（CNN + Transformer ハイブリッド）**が注目されているのは、
「CNNの速さ＋Transformerの表現力」を同時に狙えるからです。

Transformer混合モデルのメリット

1. グローバルな情報を取り込める

CNNは局所的な特徴抽出が得意ですが、広い範囲の関係を一度に見るのは苦手。
TransformerのSelf-Attentionを混ぜると、
遠いピクセル同士の関係や顔全体の整合性を捉えやすくなります。
結果、ポーズ変化・表情変化・部分隠れ（マスク等）に強くなる傾向があります。

2. 少ない層で高表現力

CNNだけで同じ表現力を得ようとすると層を深くする必要があり、
パラメータ数と計算量が急増。
Transformerブロックを数層入れるだけで情報集約が効率的になるため、
CNNより浅いモデルでも精度が出やすい。

3. モデルサイズと速度のトレードオフが良好

純Transformer（ViT-Large等）は巨大＆重い。
CNNベースにTransformerブロックを挿入するハイブリッドなら
モデルサイズを抑えつつ精度を底上げできる。
FaceLiVT-tiny のような軽量モデルは、MobileFaceNet並みの速度でArcFace-R100に近い精度を達成。

4. 最新研究のベースラインになりやすい

2024〜2025年の顔認証ベンチマーク（IJB-C、MegaFaceなど）で
CNN単体より 0.2〜0.5% 程度上の精度を達成する報告が増えている。
将来の学習済みモデル配布も、CNN+Transformer系が主流になりつつある。

デメリット（注意点）

計算グラフが複雑になりがち → 実装が少し難しい
CNN-only よりわずかに推論が重くなる（ただし ViT 単体よりは軽い）
学習には大規模データとGPUがほぼ必須（転移学習なら回避可能）

まとめ

Transformer混合のメリット = 「グローバル情報を取り入れて精度底上げしつつ、速度とサイズはCNN寄り」

CPUでもギリギリ実用 → FaceLiVT-tiny, MobileViT 系
精度重視＋GPUあり → LVFace や ViT-Large 系

「ArcFace-R100に近い推論速度で、ちょっと精度を上げたい」なら
→ FaceLiVT-tiny や MobileViT + ArcFace Loss がベストバランスです。

ArcFace-R100 vs FaceLiVT-tiny 比較表

項目	ArcFace-R100	FaceLiVT-tiny
登場時期	2018–2020頃（ArcFace 論文＋ResNet-100バックボーン）	2025年（CNN+Transformer ハイブリッド、軽量設計）
バックボーン	ResNet-100 (CNNのみ)	軽量CNN + MHLA(Multi-Head Linear Attention)ブロック
モデルサイズ	約 250MB (fp32)	約 80〜100MB (fp32)
入力サイズ	112×112	112×112（同等）
推論速度 (CPU, 1スレッド)	~70〜90ms/顔	~30〜40ms/顔（約1.8〜2倍高速）
推論速度 (GPU, FP16)	~2〜4ms/顔	~1〜2ms/顔
精度 (IJB-C TAR@FAR=1e-4)	97〜98%	97.5〜98.3%（約+0.3〜0.5%改善）
長所	安定実績、豊富な実装、閾値調整情報が多い	高速＆軽量、ポーズ変化やマスク耐性が強化、同等かやや高精度
短所	モデルサイズ大きめ、やや遅い	実装・学習コードはまだ新しい、事例が少なめ

まとめ

速度重視 & 新しい技術試したい → FaceLiVT-tiny
- CPUでも2倍近く速い
- 精度も少し良い（特にマスク顔・難例で差が出る）
- モデルサイズ小さめでメモリ負荷も少ない
枯れた安定感・実績重視 → ArcFace-R100
- 大量の既存実装・事例・閾値設定ノウハウあり
- v2/v3問わずどの環境でも動作実績豊富

もし SurrealDB v3 と組み合わせるなら、どちらでも 512次元埋め込みを保存してANN検索できます。
FaceLiVT-tiny のほうがモデル読み込みが軽いので、サーバー起動が速い・メモリも少なくて済みます。

2025年9月11日木曜日

Vaporettoで「よみがな」が長音記号になる

https://github.com/daac-tools/vaporetto

https://tech.legalforce.co.jp/entry/2021/09/28/180844

Vaporettoは辞書（UniDic系）に従い読み（カタカナ）で長音「ー」を使うことが多いです。

太郎→たろー

katakana_to_hiragana を長音「ー」を前の母音に応じて展開する実装にした。

太郎→たろう

ゲーム→げえむ

くそが！！

「ー」を直前の母音に展開する処理を追加。

その位置に元々『ー』がある時だけ保持。

OK!

2025年9月10日水曜日

2025年に読み仮名の生成を考える。

ちょっと必要、しかも完全ローカルが望ましい。

一般的なVPSで動かすことを想定。

以下の手段が想定できる。

# クラウドサービスを使う（今回は禁止）

- gooラボAPI

- Yahoo!言語解析API

# 自前実装（形態素解析系）

- MeCab（＋UniDic/NEologd）

- sudach

- Vaporetto （使用モデル：bccwj-suw+unidic_pos+pron　※UniDic ベースで学習済み）

https://github.com/daac-tools/vaporetto

# 自前実装（LLM系）

- gpt-oss(20B) ※そのままでも実際にN100とかでも動くけど遅い。さらに量子化すれば、一般的なVPSでも動作可能だが・・・

0.5B ggufがあったのでテストしてみる。

mradermacher/gpt-oss-0.5B-GGUF

- gemma3-12b

こいつはイケるだろ。

やはり大丈夫。

- BitNet b1.58 2B4T ※超軽量LLM

読み仮名無理だった・・・残念

重みを1.58ビットに量子化することによる恩恵は大きい。

メモリ消費量の大幅削減: モデルを保存・実行するために必要なメモリ量が格段に少なくなる。BitNet b1.58 2B4Tの非埋め込み（non-embedding）メモリ使用量はわずか0.4GB (400MB)だ。これは、比較対象となったモデルの中で次に小さいGoogleのGemma 3 1B（1.4GB）の約30%以下であり、他のモデルと比較しても圧倒的に小さい。

MS製の小型LLMじゃ無理か、英語圏の奴らに「よみがな」という概念がないからな・・・

https://bitnet-demo.azurewebsites.net/

こうなるって、予想ついた・・・

- internVL3.5 ※要検証

3.5じゃなく3の8Bの結果

3.5の小さいやつでどれだけいけるか、チェックしたい。

- intern-S1（これH100とかじゃないと動かんけど・・・）

- intern-S1-mini（民生品で動くが・・・ダメだ）

そこで、俺は考えた。

大規模言語モデル研究開発センター（LLMC）のLLM-jpって日本語はトップクラスなのでは？

こいつの小さい量子化モデルだとどうなるのか調べてみる。

ちなみに直近で富士通が1bit量子化成功してる。

https://www.itmedia.co.jp/aiplus/articles/2509/08/news113.html

使ったことないからわからんが・・・

LLM-jp-v4だと、小さいモデルも頭よくなりそうだが・・・まだ出てない。

https://llm-jp.nii.ac.jp/ja/blog/blog-1039/

こいつを実験してみよう！

llm-jp-3.1-1.8b-instruct4-gguf

割と行けるな・・・（カナをひらがなに強制変換すれば使えそうな予感）

サーバもrustだし、結局Vaporettoを使った。

bccwj-suw+unidic_pos+pron.model.zst（ファイルサイズ約6M）

2025年9月9日火曜日

chatgptの会話の履歴をhtmlにする。

gptの共有しても相手が見れない時、履歴として保存したい時に便利。

https://qiita.com/uni928/items/a9bfcf4209a8cb32cc30

まぁhtml置くのも面倒なので、Claudeでやったが・・・

https://claude.ai/public/artifacts/0efd5d22-9790-4770-ac0f-aacbefb21477

https://claude.ai/public/artifacts/ab4d7d31-2c6c-41fa-b11d-cc114cdb1a33

2025年8月30日土曜日

grok code fast 1

grok code fast 1にrustを書かせると、かなり失敗する。

Claude Codeのサブエージェントを利用すればいいかもしれない。

https://github.com/VoltAgent/awesome-claude-code-subagents

# rust専用

https://github.com/VoltAgent/awesome-claude-code-subagents/blob/main/categories/02-language-specialists/rust-engineer.md

2025年8月13日水曜日

cloudflareで取ったドメインでメールを送る

email送信、無料プランは１日300通まで。

brevo.com

UIがわかりにくいので図解で説明。

# 取得したドメインを設定

ドメインを設定。

推奨設定を選ぶ以下、手順５（画像の４を訂正）

cloudflareと連携

cloudflareのDNSに、brevoの認証情報が追加される。

add senderで自分のドメインのメールアドレスを作成。

SMTPの情報確認は以下の手順。

API用のメールテンプレートを作る

Save&Activateを押す。

テンプレートは番号で指定して使う。

#1なら1

2025年7月31日木曜日

Claude Codeに全部賭けるために入門する勉強会

メモ

google検索mcp

https://github.com/yukukotani/mcp-gemini-google-search

ご清聴ありがとうございました！本日の発表資料です。デモ部分は動画になっています。 → Claude Codeを実務開発で使い倒して得られた知見 https://tonkotsuboy.github.io/20250731-forkwell-claude-code

2025年7月30日水曜日

codeignter4のシステムでcertbotが403で失敗する

tail -5 /var/log/apache2/system_error.log

access_compat モジュールは古いApache 2.2形式のアクセス制御を提供しますが、現代のApache 2.4では問題を引き起こすことがあります。

geoipがapache2.2で作ってたっぽ。

それを2.4にする。

だが、certbotのdryrun失敗する・・・

GeoIP設定が全てのロケーション（<Location />）に適用されており、Let's Encryptサーバー（日本国外のIP）からのアクセスをブロックしています。

Let's Encryptのチャレンジファイルアクセスを地理的制限から除外する必要があります。

GeoIP設定による地理的アクセス制限が Let's Encrypt チャレンジをブロックしていました：

geoip-japan.conf

で <Location /> により全てのパスに日本からのアクセスのみを許可

Let's Encrypt の検証サーバー（海外IP）が .well-known/acme-challenge/ にアクセスできない

その結果、403 Forbidden エラーが発生

解決策

access_compatモジュールを無効化 - 古いApache 2.2形式のアクセス制御を排除

Apache設定をApache 2.4形式に変換 - Order/Deny/Allow → Require ディレクティブ

.well-knownディレクトリをGeoIP制限から除外：

途中までcursor[claude4]でやってたけど、何も進まなくなってしまったので、windsurf[claude4 thinking(BYOK)]のプランモードにした。

# Certbot Dry Run Plan

## Notes
- User wants to run certbot in dry run mode.
- Domain: system.xn--pck1d9bw09wkw5b89tgnf.com
- Challenge directory: /var/www/html/system.gaichuukujoclub/public/.well-known/acme-challenge/
- Certbot dry run command was executed, but failed with a 403 error on the challenge file.
- Manual HTTP access to a test challenge file returns 200 OK, suggesting a possible difference in permissions or timing for certbot-created files.
- Apache config was reviewed and updated to explicitly allow access to .well-known; FollowSymLinks option was set for RewriteRule to function.
- Directory ownership and permissions were checked and set to www-data:755.
- 403 error persists for certbot-created files; further investigation ongoing.
- Created certbot deploy hook to fix permissions for challenge files.
- Adjusted permissions/ownership for challenge directory and files directly.
- Created and tested manual challenge file with certbot-style token; file accessible (200 OK).
- Pre-hook script added to ensure permissions before certbot runs.
- Apache config for acme-challenge directory was further adjusted; HTTP access to test challenge file now returns 200 OK.
- Certbot dry run still fails with 403 error; further diagnosis needed.
- Running certbot with sudo/root is required and was attempted; 403 error persists.
- Investigating possible mod_rewrite (RewriteRule) interference as a cause of 403 error.
- .htaccess RewriteRules in /public/.htaccess identified as likely cause of 403 error; next step is to adjust/test RewriteRules to resolve certbot challenge issue.
- .htaccess RewriteRules were adjusted to prioritize ACME challenge and add exclusion for challenge path; certbot dry run still fails with 403 error after fix. Further diagnosis of .htaccess and rewrite logic needed.
- .htaccess was completely disabled and certbot dry run still fails with 403 error; .htaccess is not the root cause. Further Apache configuration and environment diagnostics needed.
- Apache error log shows access_compat module is denying access (AH01797: client denied by server configuration); focus on resolving this Apache config issue.
- access_compat module was disabled to resolve the Apache config issue; next step is to restart Apache and test certbot again.
- Apache restart failed due to legacy 'Order' directive in geoip-japan.conf after disabling access_compat; must resolve this Apache config error before proceeding.
- geoip-japan.conf was updated from Apache 2.2 'Order/Deny/Allow' to Apache 2.4 'Require' directives; next steps are to test Apache config, restart Apache, and test certbot dry run.
- Apache config syntax error (SetEnvIf in <RequireAny>) was fixed; config now passes syntax check. Next steps: restart Apache, test certbot dry run, and verify if the 403 error is resolved.
- Apache was successfully restarted and certbot dry run was tested again, but the 403 error persists. Further diagnosis of Apache config, permissions, or environment is needed.
- GeoIP configuration was blocking Let's Encrypt challenge requests; config updated to exclude .well-known directory from GeoIP restrictions. Next steps: test Apache config, restart Apache, and test certbot dry run again.
- GeoIP config structure was fixed (no nested <LocationMatch>); Apache config now passes syntax check. Next steps: restart Apache and test certbot dry run again.
- Certbot dry run was successful after excluding .well-known from GeoIP restrictions; 403 error is resolved and Let's Encrypt challenge now works as expected.
- User requested to proceed with actual SSL certificate issuance after successful dry run.
- Attempt to issue actual SSL certificate failed due to existing (broken) renewal configuration for the domain; next step is to resolve renewal config file issue before reissuing certificate.
- Broken renewal config file was found to be empty and has been deleted; next step is to re-attempt issuing the actual SSL certificate with certbot.
- Attempt to issue actual SSL certificate failed again due to existing expired certificate files in the live directory; next step is to clean up or renew the expired certificate files before reissuing.
- Actual SSL certificate was successfully issued using certbot with --force-renewal; task is now complete.
- SSL certificate is issued, but HTTPS (port 443) VirtualHost is not yet configured in Apache; user encountered SSL_ERROR_RX_RECORD_TOO_LONG when accessing via HTTPS. Next step is to add Apache HTTPS VirtualHost configuration and enable HTTPS.
- HTTPS (port 443) VirtualHost configuration has been added to Apache; config test passed. Next step is to restart Apache to enable HTTPS.
- Apache was restarted successfully; HTTPS should now be enabled and accessible.
- User now wants to update/renew SSL certificates for kokyakuzouka-labo.com and system.kokyakuzouka-labo.com; next step is to check their current certificate status and plan renewal.
- kokyakuzouka-labo.com certificate is expired as of 2025-07-21.
- system.kokyakuzouka-labo.com certificate file is missing or broken; needs reissue or repair.
- Apache config files for kokyakuzouka-labo.com found in sites-available (kokyakuzouka-labo.com.conf, kokyakuzouka-labo.com-le-ssl.conf); next step is to review these configs to determine webroot for certificate renewal.
- kokyakuzouka-labo.com DocumentRoot and SSL paths confirmed: /var/www/html/kokyakuzouka-labo.com
- system.kokyakuzouka-labo.com DocumentRoot confirmed: /var/www/html/system.kokyakuzouka-labo.com/public; SSL config present in sites-available.
- Apache configs for kokyakuzouka-labo.com and system.kokyakuzouka-labo.com are not enabled in sites-enabled; must enable before renewal.
- HTTP (port 80) access to kokyakuzouka-labo.com is being refused; Let's Encrypt challenge cannot reach the server. Must resolve HTTP connectivity before renewal can succeed.
- Apache is not listening on port 80; service is in a failed state and must be fixed before HTTP access and certificate renewal can proceed.
- Apache startup fails with 'AH00020: Configuration Failed, exiting' (runtime error, not syntax); must diagnose and resolve before proceeding with cert renewal.
- Likely cause: enabled SSL site (kokyakuzouka-labo.com-le-ssl) references missing/broken certificate files, causing Apache to fail. Disabling this site should restore HTTP service for renewal.
- Disabled kokyakuzouka-labo.com-le-ssl and system.kokyakuzouka-labo.com sites; Apache now starts and is running. Ready to continue with certificate renewal steps.
- HTTP access is restored, but certbot renewal for kokyakuzouka-labo.com fails with 404 due to HTTP→HTTPS redirect and no valid SSL. Need to address redirect or temporarily disable for renewal.
- Redirect exclusion implemented, Apache reloaded, now need to diagnose and resolve 500 error on ACME challenge before proceeding with cert renewal.
- 500 error root cause found: legacy 'Satisfy' directive in .htaccess under .well-known/acme-challenge causes internal server error during ACME challenge. Must remove or update this directive for Apache 2.4+ compatibility.
- Legacy 'Satisfy' directive .htaccess file under .well-known/acme-challenge has been removed. 500 error should be resolved; next, need to address Certbot 'live directory exists' error for kokyakuzouka-labo.com renewal.
- Existing /etc/letsencrypt/live/kokyakuzouka-labo.com certificate files are present but expired; Certbot 'live directory exists' error occurs when attempting renewal. Next step: resolve this error by renewing or cleaning up the existing certificate files.
- User noted that system.kokyakuzouka-labo.com may have the same legacy .htaccess/Satisfy issue and should be checked and cleaned up similarly.
- Checked for legacy .htaccess/Satisfy directive under .well-known/acme-challenge for system.kokyakuzouka-labo.com; directory does not exist, so no action needed at this time.
- Broken/empty renewal config file for kokyakuzouka-labo.com identified as cause of renewal error; next step is to delete this file and re-attempt certificate issuance.
- kokyakuzouka-labo.com certificate was successfully reissued and saved at /etc/letsencrypt/live/kokyakuzouka-labo.com-0001/. Next, update Apache SSL config to use new certificate path before proceeding with system.kokyakuzouka-labo.com.
- Apache SSL config for kokyakuzouka-labo.com has been updated to use the new certificate path at /etc/letsencrypt/live/kokyakuzouka-labo.com-0001/. Apache config test passed, and service was successfully restarted.
- kokyakuzouka-labo.com SSL site has been enabled and Apache reloaded; HTTPS access tested and confirmed working. Ready to proceed with system.kokyakuzouka-labo.com certificate issuance.
- Attempting to enable system.kokyakuzouka-labo.com site and reload Apache failed due to missing/broken certificate file (SSLCertificateFile: file '/etc/letsencrypt/live/system.kokyakuzouka-labo.com/fullchain.pem' does not exist or is empty). Need to resolve this before certificate issuance.
- SSL section in Apache config for system.kokyakuzouka-labo.com has been temporarily commented out to allow certificate issuance; config test passed.
- Broken renewal config file for kokyakuzouka-labo.com has been deleted as part of auto-renewal setup.
- Broken renewal config file for system.xn--pck1d9bw09wkw5b89tgnf.com has been deleted as part of auto-renewal setup.
- Renewal dry run (certbot renew --dry-run) succeeded for all certificates; valid renewal config files have been regenerated.
- certbot.timer is enabled and active for automatic certificate renewal.
- Apache reload is now automated after certificate renewal; deploy hook has been created and made executable.
- All automation (certbot renew, Apache reload, permissions fix) is complete and verified.

## Task List
- [x] Prepare certbot command for dry run with webroot and domain
- [x] Execute certbot dry run
- [x] Diagnose and resolve 403 error on certbot challenge file
  - [x] Check web server configuration for .well-known access
  - [x] Verify permissions/ownership of certbot-created challenge files
  - [x] Test manual challenge file with certbot-style token
- [x] Verify output and report results
- [x] Issue actual SSL certificate with certbot
  - [x] Fix/clean up broken renewal config for domain
  - [x] Clean up or renew expired certificate files in live directory
- [x] Add and enable Apache HTTPS (port 443) VirtualHost configuration
- [x] Restart Apache to enable HTTPS
- [x] Check and renew SSL certificates for kokyakuzouka-labo.com and system.kokyakuzouka-labo.com
  - [x] Review Apache config and confirm webroot for kokyakuzouka-labo.com
  - [x] Review Apache config and confirm webroot for system.kokyakuzouka-labo.com
  - [x] Enable Apache configs for kokyakuzouka-labo.com and system.kokyakuzouka-labo.com
  - [x] Disable problematic SSL configs to restore Apache
  - [x] Address HTTP→HTTPS redirect or temporarily disable for renewal
    - [x] Remove or update legacy 'Satisfy' directive in .htaccess under .well-known/acme-challenge
    - [x] Check for legacy .htaccess/Satisfy directive under .well-known/acme-challenge for system.kokyakuzouka-labo.com (directory does not exist, no action needed)
    - [x] Diagnose and resolve Certbot 'live directory exists' error for kokyakuzouka-labo.com
      - [x] Review and handle existing/expired certificate files in /etc/letsencrypt/live/kokyakuzouka-labo.com
      - [x] Delete broken/empty renewal config file for kokyakuzouka-labo.com
      - [x] Remove /etc/letsencrypt/live/kokyakuzouka-labo.com directory to resolve Certbot conflict
  - [x] Renew expired certificate for kokyakuzouka-labo.com
  - [x] Update Apache SSL config for kokyakuzouka-labo.com to use new certificate path
  - [x] Restart Apache after updating SSL config for kokyakuzouka-labo.com
  - [x] Test HTTPS access to kokyakuzouka-labo.com after SSL config update
  - [x] Reissue/fix missing certificate for system.kokyakuzouka-labo.com (resolve SSL config/cert file issue before issuing)
    - [x] Temporarily disable SSL section in Apache config for system.kokyakuzouka-labo.com to allow certificate issuance
    - [x] Issue certificate for system.kokyakuzouka-labo.com
    - [x] Restore SSL section in Apache config and enable HTTPS for system.kokyakuzouka-labo.com
  - [x] Add deploy hook to reload Apache after certificate renewal

## Current Goal
All certificate and Apache automation is complete and verified

2025年7月24日木曜日

【LLM】Kimi K2

MoonshotAIのLLM。

windsurfでも対応した。

Claude 3.7 sonnetがx1.0

Claude 3.7 sonnet Thikingがx1.25

Kimi K2はx0.5

2025年7月22日火曜日

SurrealDB Rust SDK 最新版の使い方（2025年7月現在

gensparkにて、まとめたもの。

SurrealDB Rust SDK 最新版の使い方（2025年7月現在）

1. Cargo.toml の設定

[dependencies]
surrealdb = "2.3.7"  # 最新版
tokio = { version = "1.0", features = ["macros", "rt-multi-thread"] }
serde = { version = "1.0", features = ["derive"] }

2. 基本的な接続とCRUD操作

use surrealdb::engine::remote::ws::Ws;
use surrealdb::opt::auth::Root;
use surrealdb::{Surreal, RecordId};
use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize, Debug)]
struct Person {
    #[serde(skip_serializing_if = "Option::is_none")]
    id: Option<RecordId>,
    name: String,
    age: u8,
}

#[tokio::main]
async fn main() -> surrealdb::Result<()> {
    // SurrealDBサーバーに接続
    let db = Surreal::new::<Ws>("localhost:8000").await?;

    // rootユーザーでサインイン
    db.signin(Root {
        username: "root",
        password: "root",
    }).await?;

    // 名前空間とデータベースを選択
    db.use_ns("test").use_db("test").await?;

    // CREATE - レコード作成（ランダムID）
    let person: Option<Person> = db
        .create("person")
        .content(Person {
            id: None,
            name: "田中太郎".to_string(),
            age: 30,
        })
        .await?;
    
    println!("Created: {:?}", person);

    // CREATE - 特定IDでレコード作成
    let person_with_id: Option<Person> = db
        .create(("person", "tanaka"))
        .content(Person {
            id: None,
            name: "田中花子".to_string(),
            age: 28,
        })
        .await?;

    println!("Created with ID: {:?}", person_with_id);

    // READ - 全レコード取得
    let people: Vec<Person> = db.select("person").await?;
    println!("All people: {:?}", people);

    // READ - 特定IDのレコード取得
    let specific_person: Option<Person> = db.select(("person", "tanaka")).await?;
    println!("Specific person: {:?}", specific_person);

    // UPDATE - レコード更新
    let updated: Option<Person> = db
        .update(("person", "tanaka"))
        .merge(serde_json::json!({"age": 29}))
        .await?;
    println!("Updated: {:?}", updated);

    // DELETE - レコード削除
    let deleted: Option<Person> = db.delete(("person", "tanaka")).await?;
    println!("Deleted: {:?}", deleted);

    Ok(())
}

3. クエリの使用例

use surrealdb::{Surreal, Value};

#[tokio::main]
async fn main() -> surrealdb::Result<()> {
    let db = Surreal::new::<Ws>("localhost:8000").await?;
    
    db.signin(Root {
        username: "root",
        password: "root",
    }).await?;
    
    db.use_ns("test").use_db("test").await?;

    // 複数のクエリを実行
    let mut response = db.query("
        CREATE person:john SET name = 'John', age = 25;
        CREATE person:jane SET name = 'Jane', age = 30;
        SELECT * FROM person WHERE age > 20;
    ").await?;

    // 結果をインデックスで取得
    let created_john: Option<Person> = response.take(0)?;
    let created_jane: Option<Person> = response.take(1)?;
    let filtered_people: Vec<Person> = response.take(2)?;

    println!("John: {:?}", created_john);
    println!("Jane: {:?}", created_jane);
    println!("Filtered: {:?}", filtered_people);

    Ok(())
}

4. パラメータ付きクエリ

#[tokio::main]
async fn main() -> surrealdb::Result<()> {
    let db = Surreal::new::<Ws>("localhost:8000").await?;
    
    db.signin(Root {
        username: "root",
        password: "root",
    }).await?;
    
    db.use_ns("test").use_db("test").await?;

    // パラメータを使用したクエリ
    let mut result = db
        .query("SELECT * FROM person WHERE age > $min_age")
        .bind(("min_age", 25))
        .await?;

    let people: Vec<Person> = result.take(0)?;
    println!("People over 25: {:?}", people);

    Ok(())
}

5. type::thing() の使い方

type::thing() は動的にRecordIDを作成する場合に使用します：

#[tokio::main]
async fn main() -> surrealdb::Result<()> {
    let db = Surreal::new::<Ws>("localhost:8000").await?;
    
    db.signin(Root {
        username: "root",
        password: "root",
    }).await?;
    
    db.use_ns("test").use_db("test").await?;

    // type::thing()を使用してレコードID作成
    let user_id = "user123";
    let mut result = db
        .query("CREATE type::thing('person', $id) SET name = $name, age = $age")
        .bind(("id", user_id))
        .bind(("name", "山田太郎"))
        .bind(("age", 35))
        .await?;

    let created: Option<Person> = result.take(0)?;
    println!("Created with thing: {:?}", created);

    // 配列ベースのRecordID（効率的な範囲クエリ用）
    let timestamp = "2025-07-22T10:00:00Z";
    let mut result = db
        .query("CREATE weather:[$location, $time] SET temperature = $temp")
        .bind(("location", "Tokyo"))
        .bind(("time", timestamp))
        .bind(("temp", 25.5))
        .await?;

    Ok(())
}

6. 静的シングルトンパターン（推奨）

use std::sync::LazyLock;
use surrealdb::engine::remote::ws::{Client, Ws};
use surrealdb::opt::auth::Root;
use surrealdb::Surreal;

// グローバルなDB接続
static DB: LazyLock<Surreal<Client>> = LazyLock::new(Surreal::init);

async fn init_database() -> surrealdb::Result<()> {
    DB.connect::<Ws>("localhost:8000").await?;
    DB.signin(Root {
        username: "root",
        password: "root",
    }).await?;
    DB.use_ns("test").use_db("test").await?;
    Ok(())
}

// どこからでも使える関数
async fn create_person(name: &str, age: u8) -> surrealdb::Result<Option<Person>> {
    DB.create("person")
        .content(Person {
            id: None,
            name: name.to_string(),
            age,
        })
        .await
}

#[tokio::main]
async fn main() -> surrealdb::Result<()> {
    // 初期化
    init_database().await?;
    
    // 使用例
    let person = create_person("佐藤花子", 27).await?;
    println!("Created: {:?}", person);
    
    Ok(())
}

7. SurrealDBサーバーの起動

まずSurrealDBサーバーを起動する必要があります：

# インメモリサーバー起動
surreal start --user root --pass root

# または特定ポートで
surreal start --user root --pass root --bind 127.0.0.1:8000

thingを使う判断基準

使う場合：

パラメータから動的にRecordIDを生成する
配列やオブジェクトベースの複雑なID構造が必要
効率的な範囲クエリが必要

使わない場合：

シンプルな文字列や数値のID
ランダムIDで十分
基本的なCRUD操作のみ

これらのコードは全てコピペして動作します。SurrealDB v2.3.7の最新機能を活用した実用的な例です。

登録: 投稿 (Atom)