旅とプログラミングを少々

趣味に関する記録などをします。おそらくプログラミング入門に関しての内容を連ねていきます。

なぜキャベツはAIやヤブ医者から尿路結石の原因の悪名を着せられているのか

まず大前提として、現代では食品からのシュウ酸摂取量制限だけでは尿路結石の予防に資すると考えられていない。食品中の可溶性シュウ酸の量は尿中のシュウ酸の量に対する寄与が25%～半分未満とされ、ただシュウ酸の摂取量を控えようとするだけではなく、医師の指導に従って水分やカルシウム等を摂取することが望ましいとされている。

とはいえ、シュウ酸の摂取量も大事なファクターだと信じられており、健康のためにほうれん草は生では食べずに茹でこぼそうといった話はよく語られる。そしてそういったシュウ酸摂取量抑制の話題のなかに、キャベツもほうれん草よりは少なくともシュウ酸が結構含まれているので生で大量に食べないようにしようというものがある。

特定の医院を非難したいわけではないので具体的なリンクの列挙は避けスクリーンショットを載せるに留めるが、まあこういう美容が押しだされている医院の宣伝によくある。食品中のシュウ酸が尿のシュウ酸に大きく寄与しており、生キャベツは結構シュウ酸が含まれているという主張だ。

とある医院の宣伝サイト内の記述
そしてヤブでも一応は医者の言葉。AIも学習している様子であり、尋ね方によって同様の内容の生キャベツのシュウ酸含有量として 300mg/100g を答える。

現代のキャベツのシュウ酸含有量

まともな医者が診断のよりどころにする専門医によるガイドライン、尿路結石症診療ガイドライン第3版( 尿路結石症診療ガイドライン 第3版 - Mindsガイドラインライブラリ ) 附表に様々な食品のシュウ酸含有量が記載されている。生キャベツは測定方法の異なる複数の論文をひいて可溶性シュウ酸が多いもので31mg/100g、総シュウ酸で0～125mg/100gという内容になっている。一方生ほうれん草は少ない測定でも可溶性シュウ酸349mg/100g、多いものでは946mg/100gとなっており、特にほうれん草では茹でる事でシュウ酸の量を大きく減らせる事を示すように茹でほうれん草と比較した種々の論文をひいている。雑にくくって生キャベツは生ほうれん草の1/10のシュウ酸含有量、嘘医院サイトの1/10のシュウ酸含有量だ。

誤解の原因その1 古い情報

実はヤブ医者の記述も昔は信じられていた。尿路結石症診療ガイドライン第2版pp.98-99に野菜とお茶のシュウ酸量の表が示されている。先のヤブ美容医院の内容と同じ内容で、キャベツ・ブロッコリー・カリフラワー・レタスをいっしょくたに扱う雑な表だ。 つまりヤブ医者は単に現代の医学に詳しくない、大昔の大学あたりで聞きかじった知識からブログを書いて宣伝に利用しているだけなのである。昔は信じられていたのだから情報の更新が遅いだけで仕方ないのだ。

……であればよかったのだが、これも実はおかしい。

誤解の原因その2 尿路結石症診療ガイドライン第2版が間違っている

さて、その古い雑な表の情報源はどこか。一応は医者のまともなガイドラインなので根拠とする文献も脚注で示されている。それが "Haytowitz DB, Matthews RH. Composition of Foods：Vegetables and Vegetable Products. In：Agriculture handbook. No. 8—11. Edited by Nutrition Monitoring Division, Human Nutrition Information Service, USDA, Washington DC, pp 502, 1984." だ。該当のp11のシュウ酸(Oxalic Acid)含有量のページ https://hdl.handle.net/2027/umn.31951002926106c?urlappend=%3Bseq=19%3Bownerid=21566572-18 を見るとキャベツ(Cabbage)は .10g/100g。そう、どう読みかえても100mg/100gなのだ。300mgではない。雑な表で挙げられていたキャベツ、ブロッコリー、カリフラワー、レタスはそれぞれ .10g、 .19g、.15g、.33g。ちなみにほうれん草(Spinach)は.97g/100g。どうがんばって読んでもキャベツのシュウ酸含有量は尿路結石症診療ガイドラインの雑な表として読めない。

つまり尿路結石症診療ガイドライン第2版を校閲する人は誰も真面目に参考文献を読んでおらずそれっぽくシュウ酸の量も書いてある野菜の成分表を載せただけで、適当な記述でキャベツのシュウ酸含有量を3倍にし、間違った情報を権威ある文章に載せていたわけだ。

結論

二重の馬鹿医者のせいで悪名が広がってしまったキャベツ。気にせずたくさん生でも食べよう。美味いから。

Firefoxのnightlyインストールメモ

たぶんまたUbuntu 26 LTSで調べなおすことになるので備忘録を残す。

レポジトリ

なんと今2026年はgithubにホストされているのが正式かつ、全ての関連プロジェクトが一体化してfirefoxレポジトリになっている。もうmercurialから分散したレポジトリ群を始めなくていい。 github.com

設定

最初はmozbootウィザードでいろいろ入力していく。Mozillaの社員かどうか答えたりしていくと~/.mozbuild/に初期設定が置かれるはずだ。 https://github.com/mozilla-firefox/firefox/tree/main/python/mozboot

よくあるソースからのインストール同様にconfigure, build, installをやるだけなのだが、firefoxではシェルスクリプトではなくmachコマンドによって管理している。

./mach configure --prefix=/opt/local --enable-artifact-builds
./mach build
./mach install

しかしこれだと一回きりのインストールで、更新のたびにオプションを忘れたりしてしまう。そこでmozconfigファイルを作っておく。

ac_add_options --enable-artifact-builds
ac_add_options --prefix=/opt/local

これらのオプションについては https://firefox-source-docs.mozilla.org/setup/configuring_build_options.html にあるようにビルドごとに指定できる。積極的にfirefoxの開発をしないのならばデフォルトの一個だけで十分だろう。 これを作っておけば毎度prefixはどうしていたか、バイナリで配布もされているコンポーネントはどうしていたか等覚えなくて済む。 このprefixがroot権限の不要な位置にあることで./mach installを一般の権限で走らせる事ができるようになる。これを忘れるとrootのmozbuildを読ませずに権限だけrootにしたりとmach内部でどうやってinstallを動かしているかよくわからないと修正できない面倒ごとを増やしてしまう。

更新

git pull で更新後、すぐに./mach buildできない事が多い。enable-artifact-buildsでバイナリコンポーネントを利用しているためだ。おそらく親切なメッセージも出ているだろうが

./mach clobber

でローカルのそういったコンポーネントを一掃してbuild時に新しいものを持ってこれる。

window manager

.local/share/applications/firefox-nightly.desktop がないとランチャーやwindow managerで見えないことがある。こういう内容のファイルがあればwindow managerの再起動後にはfirefoxもインストールされたアプリケーションとして扱われるだろう。

[Desktop Entry]
Encoding=UTF-8
Type=Application
Terminal=false
Exec=/opt/local/bin/firefox
Name=firefox
Icon=/opt/local/lib/firefox/browser/chrome/icons/default/default64.png
StartupWMClass=firefox
WMClass=firefox

DIYソフトガレージの風対策

バイク用ソフトガレージの台風対策の計算

あれからバイクに結構はまり、中型バイクとスーパーカブの二台を所有している。雨ざらしで保管するのも自分が乗る時に汚れていてちょっと嫌だったのでガレージやカーポートを検討したのだが建蔽率の都合や値段を加味してドッペルギャンガーのテント状のソフトガレージを購入した。

https://www.doppelganger.jp/product/dcc538w-gy/ バイクガレージ 2500 ワイドという製品だ。

ソフトガレージで一番の問題となるのが風対策だ。まず風で受ける力を概算する。国交省の定める基準風速は東京都あたりで34m/s。高さはせいぜい1900mmで住宅街なので地表面粗度はIIIと考えて速度圧qは0.6 * (1.7 * (5/450) ^0.2) ^2 * 2 * 34 ^2 = 662 N/(m ^2)となる。

バイクガレージが風を最大に受けるのは横から見たサイズの板と考えて面積は4.75m2。テントガレージは密閉されていないので本当は風力の係数を考えなければならないだろうが、窓サイズとか風向きとかをいろいろ考えるのは難しいので密閉の垂直の壁とみなして風上の係数0.8で済ませると、662 * 4.75 * 0.8 = 2515N (≒251kgf) の風荷重に耐えなければならない。

単純にガレージを250kgで押されるのを床支柱の固定で押さえると考える。風荷重は短期荷重なので、コンクリに打ち付けるオールアンカーの引っ張り強度を見るとM8の35mm埋め込みのアンカー1本の耐荷重がちょうどそれより少し大きい。推奨の固定箇所4隅で片側からの荷重は2箇所の固定で引っ張ると考え、安全率2でM8のオールアンカーに結びつけて固定した。

最初の試算では玉かけのように安全率6とか10とかで考えていたのだが、M12～のアンカーを打ち込む必要があり穴が大きすぎてDIYではコンクリに穴を開けてられないのでそこは目をつぶる事にした。

これでも風力の係数等をさぼったり安全率も2であったりとDIYなので許してほしいぎりぎりの固定強度であり、世の中のソフトガレージの大半は風対策がより不十分な状態にあって危険だと思われる。

スーパーカブC125を購入した

スーパーカブC125を購入した

近所のスーパーへ行くだけならば50ccで良いが、もう少し足を伸ばすと50ccはだいぶキツい。結局50ccカブでは足りないと判断して買いかえた。

まず免許。ATに乗ろうとのにATで卒検通るのは難しそうだと感じたので普通二輪コースで教習所に入校して予約はかなり先からしか取れなかったが夏の暑いうちに夜最後のコマをキャンセル待ちで1段階をクリアし、2段階を入校当初の予約分でなんとか埋めて一発で卒検合格。これでも2段階のシミュレータ部分が小型ATや大型バイクの人とも予約戦争状態で丸2ヶ月はかかった。一時期よりは取りやすくなっているらしいとはいえ、まだバイクは人気な様子。

2023年秋現在ようやくホンダバイクの需給関係は落ちついてきているようで、モンキーやGB350のような昨年から今年にかけて中古の方が高かった車種でも現物取り寄せが可能になっていた。目的のスーパーカブC125については最新より1年前の色だけ在庫から新車即納可能で最新の色は少しだけ待つということで色は夜に見にくい色でなければ何でもいいと思いトリコロールカラーのものを即時購入した。

さすがに風防などは流用できないが、保険関係やドラレコ類はそのまま置き換えで済み50ccカブの下取りもまあまあな値段であったので出費は多少は抑えられた、と思うことにしている。

まだ乗りはじめたばかりだが、50と比較して125Cはドコドコと低いおもしろいエンジン音がする。素のパワーがあり住宅街ではアクセルを吹かす必要がないので気持ち静かになったか。そして何よりも普通の道で5,60km/hを出して流れに乗ってよいことと、複雑な三叉路等で周りの車を困惑させながらの二段階右折をしなくて良いのが乗り替えて一番楽に感じる。本格的な山道はさすがに登りが遅そうだが、多少のツーリングならば全然問題なくこなせそうで実用じゃなく趣味として乗れる車種という下馬評にも納得で、良い買い物だった。

おかげで春の終わりからこのかた仕事と教習とバイクでずっと忙しく、私的なプログラミングはほぼ一切できていないが、たまにはこういう年もある。

スーパーカブ(50cc)を購入した

2023年夏現在、まだコロナ禍や熊本大地震の余波があり新車の在庫が無い場合1ヶ月～待つ。おかげでいい中古の値段も下がってないので価格差がないならと新車待って納車。

原付なんて30万円で釣りが来るだろと高をくくっていたら本体以外で結構金がかかった。

  • 任意保険

ビッグモーター事件のおかげでそもそも検討する保険会社が3社ほど減ってくれた。ノンフリート等級が完全1年目なので高い。6万円ほど。

バイク用のは振動対策とかがなされた専用品となり高かったので、じゃあもう正規で買ってしまえと取り付けも依頼して工賃入れて5万円ほど。

  • 風防、リアボックス

田舎なので風防は向かい風対策というよりは虫対策に役立つ。ドライブレコーダーの取り付けもお願いしたのでもう全部いったれと一緒に依頼し工賃まで合計して3万円弱。

  • ヘルメット

2りんかんに自転車で行き、なぜ自転車……という雰囲気の駐輪場のおっさん達がおもしろかった。試着して典型的原付おじさんらしさの溢れる白いジェットタイプのものを購入。1万円ほど。 本当はシステムヘルメットが欲しかったがやたらけばけばしいデザインで高い価格帯のものしか置いてなかったので断念。もうちょっとリーズナブルな目立つ色で単色のをそのうち買いたい。

  • 鍵

2りんかんでヘルメットと共にチェーンタイプのを購入。6000円。

  • グローブ

ホンダドリームでバイクと一緒に買うのでなんかいいの下さいと言って多少割引で4000円ほど。本当はヘルメットもバイクと一緒に買うからと割引してもらおうとしていたが、品揃えがフルフェイスのみかつデザインもゴツいバイクとかオフロード向けで結構高かったので諦めた。

  • ジャケット

原付だしいらんかなーと思っていたが事故時死亡率約4割カット装備がリアルマネー1.5万円は格安と言われると買ってしまうよね。

任意保険にもレッカーあるので少し迷ったが一応その他ロードサービス等もあるので加入。将来的にもう少しでかいバイク乗る時で良かった気がする。13000円。

  • Tile

AirTagでも何でもいいが、うちではTileを常用していたのでキーホルダー用にTileを追加購入。7000円ほど。

  • LED式非常信号灯、停止表示板

原付なので車検はないが一応公道走行するのでリアボックスに放りこんでおく用。合わせても2000円ほど。

既にこれで20万円ほど使ってしまったが、さらにバイク用の靴が欲しくなり2万円ほど、地球ロック用に家の駐車スペースにアンカー自前設置で諸々1万円ほど、冬用のジャケットとグローブ等でまた追加2万円～くらいの出費は見えている。原付とあなどっていたが意外と金がかかる。

2023年初頭のWaylandと多言語入力

このブログポストのきっかけ

先日IPAの未踏プロジェクトの発表会をWeb配信で見たが、そのなかでもKonjac と IMPlaneの発表がちょうど自分の関心領域であった。 プロジェクトではMacに翻訳機能付きIMを実装してデモしており、研究の展望としてIMPlaneが他環境にも実装できれば共通のIMをOSを越えて実装できるのではないかと語っていた。 MITOU2022 Demo Day／第29回 未踏IT人材発掘・育成事業 成果報告会 開催のご案内：IPA 独立行政法人 情報処理推進機構 (本人のツイート及び録画へのリンク https://twitter.com/k3k3h0/status/1627184019929722880 )

実際に、今そういったものが欲しい。現在のLinuxでの多言語入力の実装はとても難しい。

2023年初頭のWaylandと多言語入力

概要

キー入力およびそれに限らない全ての入力はwaylandの'Seat'と呼ばれる仮想レイヤーに集約される。一般的にはseatは一つだけでキーボードを複数繋ごうとseatは同一のものに集約され、それぞれのキーを打つたびにキー配列等を切り替えて処理するが、どう処理するかはCompositorの実装依存でありプロトコル等で決められているものではない。

文字入力の際にはIMEがwaylandクライアントとしてグローバルのwl_seatからwl_keyboardをgrabして全てのキー入力をもらう。

IMEはテキストの入力をwayland compositorに渡し、各プログラムはwayland compositorからテキストを受けとって入力として扱う。

Text-input protocol

(GUI) Program <-> Wayland Compositor 間のプロトコルが text-inputプロトコル v1-v4まである

v1: Compositor側では参考実装でwestonくらいしか対応してないはず。

プログラム側ではChromeで--enable-wayland-ime を有効にして起動すると一応まだ動くかも。

v2: wayland-protocols にマージされていない。多少は対応があった様子だけど、よく知らない。

Qtがサポートしている。

v3: wayland-protocolsにマージされているので、2023年現在多くのプログラムとCompositorが対応している。

Compositor側では mutter (GNOME shell のwindow composition manager), kwin (KDEの同上), wlroots(sway等) などの代表的なものは全てサポートしている。

Program側ではGtkがサポートしている

v4: wayland-protocolsのwip/text-input-next treeで現在進行で策定をしようとしている版 とはいえまだほぼv3と同じなので2023年現在は実質v3サポートとみなしてよい。

プログラム側ではQtがサポートしている。

zwp-input-method protocol

Wayland Compositor <-> Input Method 間のプロトコル。

v1: wayland-protocolsにマージされている。weston, kwinがサポート

v2: wlrootsがサポート(一部)

GNOMEは多言語対応がいろいろおかしいのはここでも発揮されていて、どれもサポートせず、IBusのプロトコルを使っているらしい。*1

zwp-virtual keyboard protocol

Wayland Compositor <-> Input Method 間のプロトコル

テキスト入力ではなくキー入力としてそのまま送りたい場合に使うことを想定されている。まだきちんと実装として対応しているものはないと思っていたが、wlrootsが実装した様子。しかしイベントを送るIMEは寡聞にして知らない。

まとめ

これらのプロトコル対応を見てわかる通り、waylandでの多言語入力はまだまだ発展途上の領域であり、実用上はXWaylandを介した古いプログラムのためXの対応まで必要となる。そのため実質的にfcitx5か、ある程度のwayland対応を無視してのIBusしか選択肢が無い。

参考文献

*1:Fcitx5はわざわざibusの非公開プロトコルまで一部実装してGNOME対応をしている。

最近(2022中期〜)のAWS Lambda + Rust

以前のRust製lambdaがたいへん古いのに、世間にあまりアップデートされた例が見られないためここに記録する。

比較的最近のやりかたの例 github.com

以前の書き方の例 AWS LambdaでRustを使う - 旅とプログラミングを少々

  • lambda向けコード

lambda_runtimeとaws_lambda_eventsが用いられる。Go用SDKからの変換でRustの型を作っているため稀に型がおかしかったが、両方ともに日進月歩で改良されておりおおむね実用可能。 https://github.com/naokiri/clean_house_public/blob/master/apiauth/src/main.rs の例のようにlambda_runtime::runでLambdaEvent<inputの型> -> Result<outputの型> の関数を書くだけでlambdaが起動した時にmainでのセットアップを、そして各コールでrunの内容を走らせてくれる。

  • AWS ライブラリ

rusotoはdeprecatedとなり、awslabsのSDKを用いるようになった。AWS SDK for Rust | aws-sdk-rust 非公式の間牽引してきたrusotoの作者の方々には感謝である。

  • ビルド+パッケージング

以前はまだAmazon公式にはRustをサポートしていなかったためmusl向けにビルドした後、さらにコンテナ化していた。最近は https://docs.aws.amazon.com/sdk-for-rust/ の通り公式に様々なRustライブラリをサポートしはじめており、それらのリポジトリから読む限りcargo-lambdaでビルドすることが一般的のようである。さらにAWSがGravitonコアを推奨しているのでそれに従うと

cargo lambda --arm64

とコマンドを打つだけでアップロードすべきbootstrapが作成される。muslライブラリやらlibcの互換性やらの問題はもう考えなくとも良い。