というわけで書いています。3回目のiOSDC、オフラインでの参加は2回目でした。day0〜day2まで3日間いました！

Optional<Bar>がよかった

会場にあったバー「Optional<Bar>」がとてもよかったです！

3日間、それぞれ違うカクテルが提供されていました。

写真のとおり、底のほうが濃い青緑で、上に向かってすっと色が抜けていくグラデーション。しっかり炭酸。カップに刷られたロゴが基板のパターンになっていて、すごい…!! (語彙力)

シークレットLTの「Optional<Bar>うらばなし」で裏側がのお話しも聞けて、運営の皆さんに感謝です！

CallKitの通話、やっぱり大変だよね

技術面でいちばん刺さったのこちらです！

通話はつながれば終わりじゃない ― CallKitで通話機能の裏側（金 瑠加須 / @LucasGoldner さん）

Agoraを使った音声通話を例に、CallKitとの組み合わせ方、通話ステートの設計、ライフサイクル管理、実装上の落とし穴とデバッグ方法を扱うセッションでした。

私自身、Flutterで通話のアプリを作っていたので、共感できる部分が多かったです。というか、聞きながら何度も「わかる〜」となっていましたw

通話機能って、外から見ると「つながればOK」に見えるんですよね。
発信して、相手が出て、話せる。PoC的な形だと意外とすぐできます。
でも実際に作ってみると、大変なのはその先でした。。。

私が特に苦しんだのは、セッションでも触れられていたこのあたりでした。

• 着信（PushKit）まわり。アプリがバックグラウンドにいるとき、あるいは落とされているときに、ちゃんと着信させる。ここが動かないと通話アプリとして成立しないのに、ここがいちばん手元で再現しづらい。
• 通話ステート管理。発信中、呼び出し中、通話中、保留、終了。紙に書くとただの状態遷移図なのに、実機では「終わったはずの通話が残っている」「切ったのにUIが戻らない」みたいなことが起きる。ネットワークが切れたときの扱いを決めていないと、あっという間に破綻します。
• 音声ルーティング。AVAudioSessionの設定、スピーカーとイヤホンとBluetoothの切り替え。音が出ない、意図しない出力先から鳴る、途中でデバイスを繋ぎ変えられる。ここは本当に、地道に潰していくしかない領域でした。
  

(世の中の通話機能があるアプリってすげぇ！ってなりますよね！)

ペンライトを自動制御したい！

iOSDCのペンライトを自動制御したい！（akkey / AkkeyLab さん）

Swiftでペンライトを制御する、という話です。
ライブ会場のRF制御、テーマパークのIR・音声信号制御、Bluetooth制御と、用途ごとの制御方式を整理したうえで、AVFoundationとAVAudioEngineで制御信号をリアルタイムに生成・出力して、実際にペンライトを光らせてみる。

見ていて、素直に「自分もやりたい！」と思いました。

10年くらい前はよりハードウェアに近い部分の実装をしていたので、懐かしいな〜と思うと同時に、またやってみたいな〜と思ったりしていました！

次は、登壇したい！

というわけで、次回は登壇したい！！(ペンライトを制御して、LTで登壇する側に回りたい。)

とりあえずテーマを考えておきます！

i will blog、ちゃんと書きました！

そのまま固まってしまったので、電源を落として GRUB のメニューから一つ前の 6.17 系カーネルを選んだところ、あっさり起動しました。パニックしたのはたぶん 7.0.0-28 だったと思うのですが、慌てていたので画面を控えておらず、ここは記憶が曖昧です。

何度か試してみましたが、7.0系を選ぶと毎回パニック、6.17を選ぶと毎回ちゃんと起動する、という具合にきれいに再現しました。たまたま一度コケただけならまだしも、これでは新しいカーネルが完全に使い物になりません。逆に言えば、まぐれや気まぐれな不具合ではなく、原因がはっきり存在するということでもあります。

とりあえず生きているカーネルで起動できたので、腰を据えて原因を追うことにしました。結論から言うと、NVIDIAドライバのカーネルモジュールがビルドできず、その巻き添えでカーネルのインストールが中途半端なまま放置されていたのが原因でした。

環境は Ubuntu 24.04、GPUはRTX 2060とRTX 3060の2枚挿しです。

aptが壊れていた

6.17で起動して apt を叩いたら、見慣れないエラーが流れてきました。

Error! Bad return status for module build on kernel: 7.0.0-30-generic (x86_64)
dkms autoinstall on 7.0.0-30/x86_64 failed for nvidia(10)
dpkg: パッケージ linux-image-7.0.0-30-generic の処理中にエラーが発生しました (--configure):
E: Sub-process /usr/bin/dpkg returned an error code (1)

これ以降、何をインストールしようとしても同じところで止まります。しかも処理中にエラーが出ていたパッケージの一覧に、パニックした 7.0.0-28 と、その次の 7.0.0-30 が両方並んでいました。

つまり僕が気づいていなかっただけで、カーネルのインストールはずっと前から失敗し続けていたわけです。エラーは apt upgrade の出力の中を流れていったはずなんですが、完全に見逃していました。再起動して初めて気づいたという。

パニックの直接の原因は、たぶんカーネルの設定が完了しなかったせいで initramfs やモジュール周りが不完全なまま残っていたことだと思います。ここは画面を控えていないので断定はできませんが、少なくとも「起動に必要な処理が最後まで終わっていないカーネル」で起動しようとしていたのは確かです。

先に結論

同じところで詰まった人向けに、直し方を先に書いておきます。

# 1. 詰まりの原因になっているDKMSを外す
sudo apt purge nvidia-dkms-590

# 2. 保留されていた設定を完了させる
sudo dpkg --configure -a
sudo apt --fix-broken install

# 3. 新しいドライバを入れる
sudo ubuntu-drivers install nvidia:610

apt purge が処理の冒頭で同じエラーを出して止まる場合は、dpkgで直接引き剥がします。

sudo dpkg --purge --force-depends nvidia-dkms-590
sudo dpkg --configure -a

ポイントは、ドライバのバージョンを上げるしかないということです。設定をいじって直る類のものではありませんでした。理由は以下。

何が起きていたのか

まず make.log を見ました。DKMSは失敗の詳細をここにしか書いてくれません。

sudo tail -n 50 /var/lib/dkms/nvidia/590.48.01/build/make.log

決定的だったのがこの行です。

nvidia/nv-mmap.c:928:42: error: ‘VMA_LOCK_OFFSET’ undeclared (first use in this function);
                          did you mean ‘VGA_CRTC_OFFSET’?
  928 |  detached = refcount_sub_and_test(VMA_LOCK_OFFSET, &vma->vm_refcnt);

カーネル7.0でper-VMAロックまわりの実装が変わり、VMA_LOCK_OFFSET が廃止されていました。NVIDIAドライバ側は古い前提のままなので、コンパイルが通らないというわけです。ヘッダもgccも揃っているし、Secure Bootも無関係。純粋にバージョンの非互換でした。

連鎖を整理するとこうなります。

1. HWEカーネルが6.17系から7.0系に切り替わった
2. 新カーネルのpostinstがDKMSを呼び、NVIDIAモジュールをビルドしようとする
3. API変更でビルドが落ちる
4. linux-image-7.0.0-XX-generic の設定が失敗する
5. dpkgが中途半端な状態で止まり、以降のaptが全部巻き添えになる
6. その状態で7.0系を選んで起動 → 毎回カーネルパニック ← イマココ

設定が完了していないカーネルは、何度起動し直したところで完了しません。毎回同じところでコケていたのはそういうことでした。

590は既に終わっていた

じゃあどのバージョンに上げればいいのか。ここで apt-cache policy が効きました。

$ apt-cache policy nvidia-dkms-590
nvidia-dkms-590:
  インストールされているバージョン: 590.48.01-0ubuntu0.24.04.4
  候補:               590.48.01-0ubuntu0.24.04.5

新しい .5 があるじゃないか、と思って中身を調べたら、変更内容がこれでした。

Transition the 590 driver to 595 (LP: #2146602)

.5 は中身のあるアップデートではなく、595へ移行させるためのパッケージでした。590はUbuntu側で既に終息扱いだったんですね。だから ubuntu-drivers list の選択肢にも590は出てきませんし、カーネル7.0対応のパッチも当たらない。590を直す道はそもそも存在しなかった、というオチです。

移行先を決めるときは、ビルド済みモジュールの有無を見ると確実です。

$ apt-cache policy linux-modules-nvidia-610-generic-hwe-24.04
  候補:               7.0.0-30.30~24.04.1

候補のバージョンが 7.0.0-30 になっています。これは「カーネル7.0.0-30用にビルド済み・署名済みのモジュールが実在する」という直接の証拠なので、対応状況を推測しなくて済みます。

僕の場合は最終的に595.84に着地しましたが、両方のカーネル向けにビルドが通ったので問題なしとしました。

$ dkms status
nvidia/595.84, 6.17.0-35-generic, x86_64: installed
nvidia/595.84, 7.0.0-30-generic, x86_64: installed

この状態で再起動したら、あれだけ毎回パニックしていた7.0系が何事もなかったように立ち上がりました。nvidia-smi もGPU2枚をきちんと認識してくれています。

次に同じことを起こさないために

今回の構成はDKMS方式なので、次にカーネルが上がるときも同じようにビルドが走ります。595系が終息扱いになった頃に、また同じことが起きる可能性があるわけです。

予防したいなら、linux-modules-nvidia-610-generic-hwe-24.04 形式のビルド済みモジュールに移しておく手があります。Canonicalがカーネルに合わせてビルドしたものが降ってくるので、手元でのビルド失敗という事故が構造的になくなります。Secure Boot環境でも署名済みなのでMOK登録が要らないのも地味に嬉しいところ。

とはいえ今は安定して動いているので、僕は次のカーネル更新のタイミングで移そうと思っています。

まとめ

• カーネルパニックの原因が、実は数日前の apt upgrade の失敗だったというパターンがある
• DKMSのビルド失敗は /var/lib/dkms/<name>/<version>/build/make.log を見ないと原因が分からない
• VMA_LOCK_OFFSET のエラーはカーネル7.0のAPI変更が原因。設定では直らないのでドライバを上げるしかない
• 移行先を選ぶときは apt-cache policy linux-modules-nvidia-XXX-generic-hwe-24.04 の候補バージョンを見ると確実

HWEカーネルはこれからも上がっていくので、同じ踏み方をする人はぼちぼち出てくる気がします。誰かの役に立てば嬉しいです！

最近 Ollama でローカルLLMにハマっています。

LAN内にあるOllama と Xcode を統合する手順をメモします。

公式ドキュメント) https://docs.ollama.com/integrations/xcode

構成

僕は手元のMacから、Ubuntu 上の Ollama を参照したい…

• 開発端末 (192.168.100.200)
  • MacBook Pro
  • Xcode 26.3
• ローカルLLMサーバー (192.168.100.201)
  • Ubuntu
  • RTX 3060

統合方法

Xcodeの設定画面から、Intelligence→「Add a Provider」をクリック

ローカル LLM サーバーのアドレスをポート番号込みで指定する

Models（モデル一覧）が表示されることを確認

これで、OllamaとXcodeの統合が完了しました！！

レート制限を気にせず、どんどんトライ&エラーができるので、家にGPUが余っている方は試してみてもいいかもですね！

エミュレータを一覧で取得

emulator -list-avds

Cold boot

emulator -avd {デバイス名} -no-snapshot-load

# 例
# emulator -avd Medium_Phone -no-snapshot-load

dart fix とは？

静的解析での警告やエラー等の修正を行うためのコマンド。

これまで、1個ずつ手動で修正していたが、それらを自動的に修正するコマンドがあることにAndroid Studioの通知をみていて気づいた。(もっと早く気づいていたら…)

ざっくりとした使い方

–dry-run

修正内容の確認を行うコマンド。

--dry-run オプションをつけて実行し、検出された問題を修正する場合は、--apply オプションで修正する。

実行すると以下のような形で、修正対象が列挙される。

-> % dart fix --dry-run 
Computing fixes in frontend (dry run)... 19.6s

4 proposed fixes in 3 files.

lib/src/presentation/screens/example_screen.dart
  unnecessary_import • 1 fix

lib/src/services/example_service.dart
  unnecessary_import • 2 fixes

pubspec.yaml
  missing_dependency • 1 fix

To fix an individual diagnostic, run one of:
  dart fix --apply --code=missing_dependency 
  dart fix --apply --code=unnecessary_import 

To fix all diagnostics, run:
  dart fix --apply 

–applyオプション

--dry-run を実行して、検出した問題を修正するコマンド。

--dry-run 実行時に下記のように、一部のみ修正する場合と、全て修正する場合のコマンドが記載されているので、必要に応じて選択する。

To fix an individual diagnostic, run one of:
  dart fix --apply --code=missing_dependency 
  dart fix --apply --code=unnecessary_import 

To fix all diagnostics, run:
  dart fix --apply 

今回は一部のみ修正を選択したため、実行すると以下のような形となった。

 dart fix --apply --code=missing_dependency 
Computing fixes in example... 8.6s
Nothing to fix!

まとめ

dartの静的解析の警告や、エラーは dart fix コマンドで修正できるので、使っていきましょう！

パスワードマネージャー何を使えばいいんじゃ…。2025年の終わりごろにそう思うようになった。

これまでSafariをメインのブラウザにしていたこともあって、パスワードマネージャーにあまりこだわりがなかった。

昨年末に重い腰をあげてChromeに移行することにしたので、パスワードマネージャーの導入を検討した。

1Passwordという選択肢

ログイン情報のほか、SSHキーも保存できることが結構良さそうに感じて、1Passwordを選ぶことにした。

そして、CLIが用意されているというところも開発者に優しいなと思った。
(ベータ版だけども、.envも管理できるっぽいのでこれも良さそう)

UIも良さげなので、しばらく使ってみることにした。

数日使ってみて

Chromeへの乗り換えも成功し、iPhone版のアプリを使えばiPhoneでも純正っぽく使えるのでかなり良さそうだ。

これならもっと早く乗り換えておけばよかったとちょっと後悔している…w

flutter で開発していますか？

ネイティブ(swift・kotlin)・react-native・.NET MAUIなど、アプリ開発の選択肢が多く、技術選定に悩むこの頃です…

クロスプラットフォームで開発したいな〜という時はflutterを選ぶことが多いのですが、そこで得た flutter コマンドのtipsを紹介します。

僕は ホットリスタート をしたい…

これまでホットリスタートする時に、毎回 flutter run を実行したいたのですが、Shift + R でホットリスタートができるらしい。

-> % flutter run
Connected devices:
macOS (desktop) • macos • darwin-arm64 • macOS 26.2 25C56 darwin-arm64
Chrome (web) • chrome • web-javascript • Google Chrome 143.0.7499.170

No wireless devices were found.

この状態でデバイスを選んで、Shift + R を入力すると、ホットリロードできました！！！(もっと早く知ってたら…)

他のコマンドも知りたい

flutter run でデバイスを選んだあと、h を入力するとヘルプが表示された。

(色々便利なコマンドがあるっぽい)

Flutter run key commands.
r Hot reload. 🔥🔥🔥
R Hot restart.
v Open Flutter DevTools.
w Dump widget hierarchy to the console.                                               (debugDumpApp)
t Dump rendering tree to the console.                                          (debugDumpRenderTree)
L Dump layer tree to the console.                                               (debugDumpLayerTree)
f Dump focus tree to the console.                                               (debugDumpFocusTree)
S Dump accessibility tree in traversal order.                                   (debugDumpSemantics)
U Dump accessibility tree in inverse hit test order.                            (debugDumpSemantics)
i Toggle widget inspector.                                  (WidgetsApp.showWidgetInspectorOverride)
p Toggle the display of construction lines.                                  (debugPaintSizeEnabled)
I Toggle oversized image inversion.                                     (debugInvertOversizedImages)
o Simulate different operating systems.                                      (defaultTargetPlatform)
b Toggle platform brightness (dark and light mode).                        (debugBrightnessOverride)
P Toggle performance overlay.                                    (WidgetsApp.showPerformanceOverlay)
a Toggle timeline events for all widget build methods.                    (debugProfileWidgetBuilds)
g Run source code generators.
h Repeat this help message.
d Detach (terminate "flutter run" but leave application running).
c Clear the screen
q Quit (terminate the application on the device).

表にまとめてみた

何が起きたか

IPv6のみのEC2にcloudflaredをインストールした際に、IPv4のアドレスで名前解決してしまい、タイムアウトが発生していた。

対処方法

/etc/systemd/system/cloudflared.service を変更し、IPv6のエッジサーバーに向けた。

変更前

[Unit]
Description=cloudflared
After=network-online.target
Wants=network-online.target

[Service]
TimeoutStartSec=0
Type=notify
ExecStart=/usr/bin/cloudflared --no-autoupdate run --token <token>
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

変更後

–edge-ip-version 6 を追記

[Unit]
Description=cloudflared
After=network-online.target
Wants=network-online.target

[Service]
TimeoutStartSec=0
Type=notify
ExecStart=/usr/bin/cloudflared --no-autoupdate --edge-ip-version 6 tunnel run --token
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

ことの始まり

clamav-milterの検証のため、すでに構築済みのメールサーバーに対して、clamav-milterを導入し運用していた。

導入してから、2～3日後にメールの送受信が行えなくなり、メールサーバーへのsshもできない状況になってしまった。。。(サーバー負荷だろうなと思っていた)

切り戻しをした

(自分一人しか使っていないけれども)メールの送受信ができないと困ってしまうので、一度切り戻しを行った。

切り戻し作業を行っているうちに、clamd, clamav-milterを動かすと、そこそこメモリを消費するということに気づいた。
もともとメールサーバー自体への負荷は低いだろうということで、 2vCPU / 2GB RAMのインスタンスとしていたのだが、2GBのRAMでは足りずハングアップしていたようだ。

htopで見ると、clamdがかなりのメモリを消費している。

スワップ領域を作成した

CPUへの負荷は低く、インスタンスサイズを変更するほどでもないと考え、スワップを領域を作成することにした。

スワップファイルの作成

sudo dd if=/dev/zero of=/var/swpfile bs=1M count=4096
sudo mkswap /var/swpfile
sudo chmod 600 /var/swpfile
sudo swapon /var/swpfile

/etc/fstabへ以下を追記

/var/swpfile none swap sw 0 0

スワップ追加後

スワップ領域に4GBほど割り当てたため、clamd, clamav-milterを動かしても安定して稼働するようになった。

この記事を書いた理由

AWS Amplify Gen2がリリースされたものの、日本語での解説記事が少なく(探し方が悪い？)、困っている人がもし居たら….と思い記事にすることにした。(特にモバイルアプリケーション向けの記事は少ない…)

そもそも、AWS Amplifyとは

AWS上のさまざまなサービスをラッピングし、Webやモバイルアプリケーションに特化したサービス。

詳しくは→https://aws.amazon.com/jp/amplify/

僕はプッシュ通知を送りたい

僕の中で、少し前までモバイルアプリケーション向けのプッシュ通知をAWSで実現したい場合には、Amplifyがすぐ候補となっていた。

周りを見てもPinpointでの実装は少なく、Amplifyでの実装例が多かった。

いつもの通り、amplify initしようとしたら、Gen2使ってねというメッセージが表示され、「せっかくだから…」という軽い気持ちで足を踏み入れることにした。(違いも何も調べずにね)

Get Startからはじめた

Get Startから始めたものの、プッシュ通知に関するサンプルが見当たらなかった。(もしかしたら今後更新されているかもしれない。)

公式ドキュメント以外も探したが、それらしきものは見当たらず…

Gen1のころを思い出した

Gen1の頃に使っていたライブラリと全く同じであることに気づいた。

Amplify Gen2では、バックエンドの構成がtypescriptによるCDKであるため、そこさえできれば実装できそうだ。

そして完成

backend.addOutput({
  /* 省略 */
  notifications: {
    aws_region: Stack.of(pinpoint).region,
    amazon_pinpoint_app_id: pinpoint.ref,
    channels: ['IN_APP_MESSAGING', 'APNS'],
  }
});

これをamplify/backend.tsに記載することで、プッシュ通知の配信対象となった。

addOutputに追加することで、amplify_outputs.jsonに出力されるためだと思われる。

この後について

• Pinpointプロジェクト上でAPNsのキーなどの情報をセットしているが、自動化できれば自動化したい。
• auth周りも実装してみたい。