Android版Google日本語入力で、「○○は」「○○が」みたいな変換をしやすいように辞書登録する方法

奥さんの名前がGoogle日本語入力で登録されていない漢字のようなので、辞書登録して使っているのだが、カテゴリを「名」にしても「人名」にしても変換がどうもおかしく、

○○は
○○が
○○の
○○を

あたりをタイプしても、変換候補に出てこなかったり、出てきてもかなり後ろになって不便だった。

いろいろ試したところ、どうも「名詞」にするとうまく変換されるようだ。名詞に辿り着くまでに試したのは「名」「人名」のほか、「姓」「固有名詞」など。どれも適切に変換されてしかるべきだと思うのだが、なんでされないのやら。

LaravelやRailsでcollationをデフォルトのまま使ってしまった時は

utf8mb4_unicode_ciは「か」と「が」を同一視したりするので、日本語アプリケーションでは使えない。のだが、日本語対応が十分でないフレームワークなどではよくデフォルトになっている。

最初からちゃんと設定しておけばいいのだが、忘れたまましばらくしてから気付いてしまった場合は、修正が面倒だ。

MySQLでは、collationはデータベースのデフォルト、テーブルのデフォルト、カラムのデフォルトと3段階ある。そのうちデータベースのデフォルトについては多分フレームワーク側では関与していないので、今回は無視する。

テーブルとカラムのデフォルトは、以下のクエリで変更できる。

ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

-- あるいは、utf8mb4のデフォルトのcollationはutf8mb4_general_ciなので、これでも同じ
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4;

残念ながらMySQLではALTER TABLEを繰り返して実行することはできないので、データベース内のすべてのテーブルを一括で変更するには、シェルスクリプトなりで対応するしかない。zshならこんな感じとか。

for table in $(mysql DATABASE -BNe 'show tables')
mysql DATABASE -e "ALTER TABLE $table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci"

注意

ALTER TABLE ... CONVERT TO CHARACTER SET ...は、今回のようにCHARACTER SETを変更しないような場合はおそらく安全に使えるが、CHARACTER SETを変更する場合は文字列系のカラムのサイズが変更されてしまう場合がある。

データ型が VARCHAR か、またはいずれかの TEXT 型であるカラムに対して、CONVERT TO CHARACTER SET は、新しいカラムが確実に元のカラムと同じ数の文字を格納できる十分な長さになるように、必要に応じてデータ型を変更します。 https://dev.mysql.com/doc/refman/5.6/ja/alter-table.html

特にフレームワークでmigratorを使っているような場合致命的な問題が発生しかねないので気をつけた方がいいかもしれない。

plackup -Iで一貫性のないモジュール読み込みになる場合がある

plackup -Iは、perl -Iと同様にinclude pathを追加できるオプションなのだが、ちょっと特殊な挙動になっていて、問題が起きる場合がある。

plackup -Iでは、plackup自身の実行時に使用するモジュールのinclude pathは指定できない。これはまあ当然なのだが、なんとplackupの実行時に読み込まれたモジュールは、その後PSGIアプリケーションを実行する時点でも残ってしまっている。

これにより、「plackup自身が読み込んだモジュールは、-Iで指定されたパスにあっても読み込まれない」ということになる。

さらにモジュールによってはやっかいな問題につながる。

たとえば古いCarpモジュールではCarp::Heavyを遅延ロードしているのだが、plackup時に古いCarpを読み込んで、しかし-Iで指定したパスには新しいCarpが入っている場合、その後PSGIアプリケーション側でCarp::Heavyを遅延ロードするようなことをすると、新しいCarpCarp::Heavyは古いバージョンのCarpとは互換性がないためdieするようになっているため、アプリケーションが落ちる。

なお回避策は簡単で、-Iオプションを使用せず、PERL5LIB=... plackupとするだけである。-Iオプションはなくしてもいいのではないだろうか。

Steamの支払い情報で市区町村が2つある件

2020-06-27追記

かなり久々に支払い情報入力画面見てみたら、直ってました。まあ、しばらく前からアクセス数減ってたんでなんとなくそうなんだろうなと思ってましたが。

なお"City"の方が「都道府県」になった模様。

シルバー事件はまだクリアしてません。


インターフェイスを英語にしてみるとわかるけど、"City"と"Billing address"をどちらも市区町村と翻訳してしまっているようだ。多言語化ってほんと難しいとはいえ、こういう大事なところくらいなんとかしてくれ。

f:id:xxmagai:20180218174520p:plain

f:id:xxmagai:20180218174545p:plain

ということで、"City"相当部分には都道府県と市あたりまで、"Billing address"相当部分には残りを、一応番地の前まで入れる、みたいな感じでいいんじゃないかな。

なおセールでシルバー事件を買いました。ゲームをいちばんやってた時期に、気になって、でもプレイできてなかったんだよね、このゲーム。

Eloquentのモデルのイベントをリスニングする

ドキュメントにも一応書いてあるけどなんか半端なので。

https://laravel.com/docs/5.6/eloquent#events https://readouble.com/laravel/5.5/ja/eloquent.html#events

  1. モデルの$dispatchesEventsに、['イベント名' => イベントクラス::class, ...]の形の配列を指定する。
  2. artisan make:eventなどで、イベントクラスを作る。必須のメソッドはコンストラクタだけ。make:eventではbroadcastOn()もできるけど、これはブロードキャスト用なので必要なとき以外は必要ない。

これだけでOK. Eloquentモデルのイベントをリスニングするだけなら、ほかでの登録などは不要。そこをねー、ちゃんとドキュメントに書いておいて欲しいんだが。$dispatchesEventsの挙動を。

コード的にはIlluminate\Database\Eloquent\Concerns\HasEventsに書いてある。

最近のAutoHotkey(AutoHotkey_L)でWinキーを無効にしたままWinキーと組み合わせたキーを有効にできなくなっていた件

2019-03-15追記

最近Windows 10にしたんだけど、下のSend {vk07}使ったハックだと、Win+Gにフックされているゲーム関係の謎機能が起動して変な感じになっていた。キーによってはほかのが出る。

{vk99}とかありえなさそうなのにした方がよさそう。

あるいはWindows 10ならスタート画面じゃなくてスタートメニューでそこまで困らないので、Winキー単独を有効にしてしまってもいいかも。というか俺はそうした。

追記ここまで


昔のAutoHotkeyは、以下のようなスクリプトを実行することで単独でのWinキー操作を潰しつつ、Winキーとほかのキーとの組み合わせは有効にする、ということができていた。

~*LWin::
~*LWin Up::
    return

サイトによってはもっと単純な形で書かれていたりもするが、LWinなりLWin Upなりでなにもしないように設定するだけでよかった。

最近ちょっとしたミスでAutoHotkeyの最新版を入れてしまったところ、これが効かなくなっていた。

いろいろ調べた結果、以下の公式フォーラムの回答にある方法で対処できそうなので試したが、タイミングの問題か、これだとたまにスタートメニュー(Windows 8なのでスタート画面?)が開いてしまって鬱陶しい。どうにかならないものか。

LWin hotkey suppresses WM_INPUT message - AutoHotkey Community

じっさいに使ったコードはこんな感じ。{vk07}は無効なキーならほかでも変わらなさそう。

~LWin::
    Send {vk07}
    return

炭水化物からのカロリー摂取が7割超えると死ぬとかの件

あれこれ引用してるだけの糞記事です。


だいぶ前だけどこういう記事があって気になった。

1) 炭水化物:最高群の死亡リスクは28%増 (中略)  摂取量の増加とリスク上昇の関係を調べたところ、総死亡のリスクは、総エネルギー量に占める炭水化物由来のエネルギーが60%を超えたあたりで上昇傾向を示しました。おおよそ70%を超えると、リスク上昇は統計学的に意味のあるレベルになり、それ以降も上昇は続くことを示す結果が得られました。

style.nikkei.com

食品の成分表示とかちゃんと見てみるとわかるけど、雑な食事してると炭水化物7割超えは普通になっちゃう。コンビニおにぎりとかそんな感じだし。

ただ、

平成27年国民健康・栄養調査によると、日本人の炭水化物由来のエネルギーが総エネルギーに占める比率の平均は58.4%で、どの年代でもほぼ同様であり、最も多かった70歳以上の人々でも60.8%でした。

なので、そこまで気にする必要もないのかなー、とか。


なおこういう研究もある。マウスでの実験の話ではあるが……。

寿命については,餌が低タンパク・高炭水化物ほど長生きし,逆に高タンパク・低炭水化物ほど短かった.

https://www.jstage.jst.go.jp/article/faruawpsj/50/11/50_1147/_pdf


突っ込みも入ってるらしい。

「炭水化物」も「脂質」も、やはり記事以上に細かい分析がなされいるようには見えません。そこでさらに調べてみると、ハーバード大学公衆衛生大学院が、この論文に疑問を呈していたのです。「PURE研究は見出しを飾ったが、結論は誤解を招く」と題し、次のような指摘をしています。

robust-health.jp


けっきょく現状での個人的な結論は、偏食は避ける、と現状維持な感じになった。