メモの日々

■ 会社

• 10:20 部会終わってだいぶ経ったところ。やること山積みだ。一つずつこなすしかない。SFAが一番悩ましい。とりあえず掲示板に拡張子なしのファイルを添付したときの動作を確認するのだ。
• 14:45 なんだよー、フルバックアップ取れてないじゃんかよー。BackupExec嫌いだ。本所へ行かねば。
• 14:55 なんだよー、気付いたらバックアップ開始してんじゃんかよー。どうしてだよー。分からん。
• サンイーピー450はアドレス変わるだけでこのまま使えそうなので大丈夫です。でも万が一駄目な場合はHPを使わせてもらいたいかも。でもそれってちゃんとLAN上にあるのでしょうか。
• 15:40 今日は腰が痛い。
• 16:20 本所に行ってテープを交換してきた。特に問題なし。帰りにJavaWorldを買ってきた。あー、家賃を払わねば。金おろさねば。
• 16:40 社内報を見てみると内定者の方々が載っている。なんと瀬田くんの名前が見つからない。佐伯さんはいたので少し持ち直す。瀬田くんなんでだー。
• 18:50 oomtgmのユーザデータを各社へメイルで送った。とても大変。こんなの手作業でやるもんではない。もう7時だ。ちぇ。
• 19:50 土曜日書きかけだったメイルをやっと出せたところ。もう皆帰った。えーい、今日は大残業だー。
• 20:50 拡張子なしファイル問題の原因がわかった。ソースを見せてもらえれば皆分かるのだよ。直してもらえるだろうか。

■ テレビ

• キャノンボール2。途中だけを見た。話の流れがさっぱり分からなかった。ジャッキーチェンはまだ線が細くてそんなに強くない。
• ちびまる子ちゃん。さくらさん佐々木小次郎役で卑怯者が宮本武蔵役になったところ。後編へ続く。
• ガキの使いやあらへんで。大喜利。あまり面白くない。来週も大喜利だ。

■ [dev] 河童

ユニットテストツール河童のWebサイト。XP-jp MLより。Zopeで構築しているようだ。Zopeって何ができるのだ？

■ [mobile] KPilo V1 の公開場所

PiloWebの後継者になれるかKPilo。PalmFanより。求めていたソフトだがβ版なのとPiloWebからのデータ移行の面倒さが気になってインストールに踏み切れず。

■ [java][web] 「J2EEアプリの開発をもっと簡単にしたい」---Strutsの開発者McClanahan氏に聞く

Struts開発者のインタビュー。struts-user MLより。どうということはないが今後のロードマップが分かる。

■ Cプロジェクト

• 機能設計書は書いた。たった2ページだが。

■ Kプロジェクト

• 20:00〜21:00 SSL更新作業。ベリサインの書いている手順書通りに実施し特に問題なし。やっとやることリストの項目を1つ減らせた。

■ その他

• 13:50〜14:25 避難訓練の一環で119の仕方と消火栓の使い方を勉強。119は向こうの質問に答えればいいのだ。消火栓は危ないから手を離してはいけないのだ。
• 14:40 続いて避難訓練。外へ出て消防署の人の話を聞いた。消防隊は大変な仕事だろうなあ。
• 18:40 Axisは大体分かったつもり。説明できんが。クライアント側にもAxisのライブラリが必要なのが少し面倒。CLASSPATHの設定とかも。あとjavaは長い文字をコマンドラインで入力しなければならないのが面倒だなあ。IDEがないとつらいかも。
• 19:25 なんとエニックスとスクウェアが合併だそうで。スクウェアは資金繰りに苦しんでいたのか。ゲーム業界も大変だ。
• 21:40 もうこんな時間かよ。

■ [howto] CVSで変更・追加したファイル一覧を得る

ソース一式を入手→一式をCVSへ登録→独自の改造を加える、とした場合に、独自の改造を加えたファイルの一覧を得たかった。

cvs diff --brief -r1.1.1.1 | grep Index

とすると

cvs diff: Diffing ディレクトリパス

という余計な行が出力されてしまう。標準エラー出力をリダイレクトして（tcshを使っている）

cvs diff --brief -r1.1.1.1 |& grep Index

としてうまくいったと思ったら、これだと変更したファイルの一覧は出力されているが追加したファイルは出力されていなかった。後から追加したファイルにはリビジョン1.1.1.1が振られておらず、標準エラーに

cvs diff: tag 1.1.1.1 is not in file ファイルパス

という出力がなされていた。

cvs diff --brief -r1.1 |& grep Index

とすればいいかと思ったが、これだと変更していないファイルも出力されてしまう。それではと

cvs diff --brief -r1.1.1.1 |& grep 'Index\|is not in file'

としたら一応一覧を得られた。grep中の正規表現のor指定は「\|」とエスケープする必要があるみたい。で、このままだと出力がかっこ悪いので、覚えられないawkの使い方を調べながら

cvs diff --brief -r1.1.1.1 |& awk '/^Index|^cvs diff: tag 1.1.1.1 is not in file/ {print $NF}'

とした（正規表現も直した）。これでOK。awkのときは「|」にエスケープ要らないみたい。

もっと素直にできるやり方あるのかな。

(追記）

F先生からcvs updateでできるのでは、と言われたけど、

cvs -n update -r 1.1

だと変更していないファイルにもUマークが付いてしまい、

cvs -n update -r 1.1.1.1

だと後から追加したファイルに対して

cvs update: ファイルパス is no longer in the repository

のように出力されてしまうのでやっぱりawkなどで頑張る必要がある。

■ やること

• プリンタ処分
• リンク元のスリム化
• ナンバーアナウンス解約
• スーツをクリーニングへ
• tDiaryバージョンアップ
• FSWikiバージョンアップ
• AVGバージョンアップ
• バックアップ
• JREバージョンアップ

■ [java] JOptionPaneが閉じる前に処理をしたい

JOptionPaneで表示できるダイアログはボタンを押すと必ず閉じてしまうので、閉じる前にテキストフィールドの値をチェックしたりすることができない。

ダイアログが閉じる前に処理をする方法を調べていて、

• JOptionPane - check user input and prevent from closing until conditions are met (Stack Overflow)

が参考になったのでメモ。

• JDialog.html#setContentPane()でJOptionPaneのインスタンスを設定すると、JOptionPaneが作るのとほぼ同じダイアログを作れる。
• JOptionPaneのインスタンスにPropertyChangeListenerをセットすると、ダイアログ上のどのボタンが押されたのかを調べることができる。JOptionPaneのドキュメントに「 選択が変更されると、setValue が呼び出され、PropertyChangeEvent が生成されます。JOptionPane がすべての入力 setWantsInput に設定されている場合、バウンドプロパティーの JOptionPane.INPUT_VALUE_PROPERTY を待機することによっても、ユーザーが値を入力または選択した時点を判定することができます。 」とあるのがその説明だと思う。

■ [life] 免許証を更新した2022

前回から5年経った。都庁にある免許更新センターへ行く。3度目。

最初の受付に結構人が並んでいて心配になったが、それほど待たされることはなかった。受付で貰った用紙に名前電話番号生年月日などを記入して用紙裏面にいくつかチェック。4番に用紙を見せて3000円を支払う。5番で視力検査。

視力検査は器械が2台あるが、その片方は夫人に付き添われた老人が眼鏡を取っ替え引っ替えしながらずーっと検査をし続けていた。なのでもう片方はスムーズに進めなければならない。用紙と旧免許証を提出してマスクをずらして本人確認の後に器械を覗きこむ。片目の検査は見えたが両目が見えない。1度目は間違えてしまった。もう一度質問され、長いこと見つめた後になんとか正解。時間がかかってしまい申し訳ない。

次の6番で旧免許証に穴を空けられたのかな。その次の窓口で少し待った後に新免許証の情報が印刷された紙を受け取り内容を確認。その次で暗証番号4桁を2種類入力。番号が印刷された紙を貰う。その次で写真撮影。

次が講習。資料は椅子の上に置かれていた。一番前の席に座った。15分くらい待たされただろうか。講習は30分間。講師の話はほとんどなくて、音声付きのスライドを見せられた後に映像を見ておしまい。その部屋で新免許証を受け取る。一番前に座っていたので一番に免許証を受け取れた。暗証番号の確認をせよとは言われなかった。

14:25に受付をして、終わったのは15:15くらいか。

■ [android][net] AndroidのBLEを使った通信で512バイトを超える送信データが破棄される

AndroidのBluetooth APIを使ったBLE通信で、送信データが破棄されれ送信されないことがあったので調べた。

原因はAndroid 13と14での動作の変更だった。

Android 13での変更

ちゃんとした資料は見つけられなかったが、Android 13から512バイトを超えるデータを送受信できなくなったというissueがちらほら見つかる。これなど。

次の変更が原因のようだ。

• Set maximum attribute value to defined by spec Core 5.3 (android.googlesource.com)

この変更は、次に示すBluetoothの仕様でattribute valueの最大長が512バイトに制限されていることへ準じるために行われている。

• 3.2.9. Long attribute values (Bluetooth Core Specification 6.0)

The maximum length of an attribute value shall be 512 octets.

どうも、Bluetoothでデータ送信を行う際のデータ長の上限としてATT（Attribute Protocol）のMTUサイズから3バイト引いた値を使うコードが多いようで（手元のコードもそうなっていた）、AndroidのATT MTUサイズは最大で517バイトになり得て、そうなったときに 517 - 3 = 515 バイトのデータを送信しようとしてしまい、その結果Android 12までであれば送信できていたのにAndroid 13になったら送信できなくなったという問題があるようだ。

Android 14での変更

Android 14では次の変更がされたとある。

• MTU is set to 517 for the first GATT client requesting an MTU (Android Developers)

これは、BluetoothGatt#requestMtu()によりMTUサイズの拡張を要求したときに引数の値によらず常に517バイトが使われるということのようだ。

手元のコードでは、上述したAndroid 13での変更に対する対策として BluetoothGatt#requestMtu() で515を使うようになっていたが、この対策はAndroid 14以降では意味がなくなってしまうことになる。

変更への対応方法

送信データの長さの上限を (MTUサイズ - 3) とするだけでは問題があるということになる。

送信データの長さの上限は (min(512, MTUサイズ - 3)) とする必要がある。

AndroidのATT MTUサイズの上限が517バイトなのは何故か

検索すると、AndroidのATT MTUサイズの上限は517バイトではなく515バイトであるべきだと書いている人を見かける。これに対しては、次のissueにGoogleの人による説明があった。

• [BLE] - Incoming packets longer then 515 dropped after BluetoothGatt.requestMtu(517) used, even though remote peer supports MTU 517 (Android Public Tracker)

I would like to provide you more details about why 517 was chosen instead of 515:

The number 517 was selected because the GATT_MAX_MTU_SIZE constant was set to 517 since the initial drop of Android Bluetooths stack in 2012.

A deeper reason is that the Bluetooth Specification allows the maximum size of an ATT attribute to be 512 bytes and the largest command ATT_PREPARE_WRITE_REQ has 5 bytes of header. Hence 512 + 5 = 517.