system-bus-radio という2015年からある由緒正しいプロジェクトがあり、なんか Gemini と会話してたら急に出てきたので、M1でも動かないかなあといじっていた。ごちゃごちゃやってたら任意 wav ファイル再生までできた。ちゃんとリサーチしてないので既にやってる人はいくらでもいるんだろうが……
元の実装は単音メロディーだけで任意wavを再生できる感じではなかったので適当に拡張してwav再生できるように。
これはどう考えても動画にしたほうが見栄えするので適当に作った。調子が悪すぎて声がおかしいし喋りもおかしい……
久しぶりにYouTubeのアナリティクスと収益タブみたけどほんの少しでも継続的に入っていてうれしい。iijmio の契約をまとめて100円節約して喜んでるおじさんだからな……
欲を言えばこの収益が100倍になってくれれば
https://github.com/cho45/uutransfer/blob/master/uutransfer-tmux-v2
ちょっとだけ賢い v2 を作ってみた。
ごく稀に scp が直接通らないが ssh ができるホストからデータをひっぱってきたいときがある。(例: 多段プロキシなどややこしいホスト)
こういう場合に、既にある tmux セッションを利用して、ファイルを手元に持ってこようというのが uutransfer。scp よりかなり効率は悪いものの手軽にリモートファイルを手元に持ってこれる。要はコピペでがんばって転送するのを自動化している。
従来は
uutransfer 1 で uutransfer の待受実行という2ステップ必要だったのを、単に
uutransfer-tmux 1 foobar.log
でいけるようにした。
Google の Family Safety (ペアレンタルコントロール) には発信先を制限する機能があるんだけど、これがバグっててひどい。
端的にいえば「許可した電話番号へ発信できない」問題が発生する。
まずFamily Safety 側からは常に正規化された +81 プリフィックスの国際電話番号形式しか入れられない。まぁこれは別に仕様としてはいい。
しかしコントロールされる側の Family Safety の設定画面にある同期された「保護者が管理する連絡先」などから発信しようとすると「保護者による使用制限（システム）から通話を発信することができません。別の通話転送アプリを使用するか、デベロッパーに問い合わせてみてください。」とでてブロックされる。
明示的に許可した一覧が表示されているのに、ここから発信するとブロックされる。は？
あるいはペアレンタルコントロールされる側は、ここで登録した連絡先が自動的に「編集不可」の「連絡先」として登録されるんだけど、この連絡先を使って通話することもできない (同様にブロックされる)
なおかつ、コールされた履歴からのかけなおし(コールバック)も制限される。
発信制限を解除するとかけられるので間違いなく発信先制限のせいなんだけど、本当にひどい。
ペアレンタルコントロールされる側のアカウントでも自力で「連絡先」を作って、「+81 90-XXXX-XXXX」形式で保存する。この状態で該当する連絡先を開くと、Family Safety で登録した「連絡先」とマージされて表示される。そしてなぜか
と二段で表示されるので、+81がついていないほうを選んでコールすると発信できる。上を選ぶとダメ。なんで？ バカなのか？
逆だろと思うかもしれませんが↑の挙動で間違いないです。
ダイアルパッドからかける場合は +81 からはじまる形式の入力でかけられる。
直前の挙動と矛盾してるじゃんと思うけど間違いないです。
この意味不明な挙動を子どもに説明するのは不可能なので、実質的には「発信は完全に封じる」機能として使うのが妥当でしょう。着信専用として使うしかない。
ペアレンタルコントロールを設定するみなさまにおかれましては、設定するだけで満足せずに動作確認を必ずしましょう。普通に動く機能だろうと思ったらゴミだった例です。
subtech.g.hatena.ne.jp/cho45 以下のデータをインポートした。
グループのサービス終了にともなってエクスポートだけはしたけど、放置してあった。ときたま「あぁサブテクグループに書いた気がする」と思っても検索不可能だったのが地味に自分にとって不便だった。
ということで2020年にグループが終わってるから6年越しに、ずっっっっとやってなかったのを Codex と共にやってみた。
/cho45/20100107/1262839487 → /2010/01/07/1262839487 となるようにインポートしたので基本的に機械的に遷移できるはず。
そして http://subtech.g.hatena.ne.jp/cho45/20100107/1262839487 みたいに貼り付けられているリンクも後処理時に書き換えるようにしたので、この日記内ではリンク切れが復活するつもり。
あと一律で subtechタグをつけるようにした。ほとんど gerry++ で埋まっとるが……
グループ関係のはてブは全部タイトルが一緒になってしまっていて終わっているので、このホッテントリのトップだけ雑に再現したリンク集をつくった。供養。
LLMエージェント自体はめちゃくちゃいいのだけど「レビュー不要!」みたいな楽観的なやつ見ると意味わからんなと思う。出力されたコードが伝えた要求を満たしているか確認する能力がないだけでは? と思う。
いちいちすべてサボろうとするし実装をTODOみたいにコメントだけ書いて終わらそうとするし、設計能力は本当にないし、言わないとテストもろくに書かないし、些細な(まさに人間がやるような)変更漏れも多いのに? 本当にエージェント使ってんの? 何やらせてんの?
as-is:
で一切家族割の恩恵を受けられていない
to-be:
で、子ども用の音声SIMの追加契約をしている。追加契約中だと名義変更の受け付けを拒否するようで順番にやる必要があるぽい。
端的に: eKYC (ウェブ認証というやつ) でやれば良い
本人確認の前提:
特殊な前提:
問題点:
eKYCのほうがそもそもアプリ入れる必要もないし、処理が遅いとかもないので、本人確認アプリ使うメリットがそもそもなさそう