モルタルコのプログラマ日記

Weather Typing 3.3をMicrosoft/Google/Appleのストアに申請した。Windows/Androidは既に公開済みでiOS/MacOSは申請中。

久しぶりに申請した感想としては，Windowsストアが一番楽。Appleストアはきつい。Windowsストアはアプリが少ないのでできるだけ登録しやすくしていて，Appleはアプリが多すぎて質が落ちるのを嫌って障壁を作っているんじゃないかと邪推してしまう。

Microsoftストアは特に何もつまづくことなく申請と登録が完了した。前回の申請からそんなに期間が空いてないのもあるのかもだけど，一番申請しやすい気がする。

Googleプレイは特に前と変わらずだが，元々見づらいというか・・・。申請しようとしたら，もうすぐ古いOS（API）のアプリは申請できなくなるという警告が出た。でAPIレベルを上げたら，パーミッションの設定の方法が変わっていて動かなくなった。とりあえずアプリ起動時に，パーミッション許可をユーザに聞くようにして，許可されなかったら終了するようにした。本当は許可しなくてもある程度使えるようにするのがいいんだろうけど。

Appleストア。どのストアも必要なスクリーンショットやアイコンがかなりあるんだけど，Appleはビルド，アップロード，サブミットと色んな段階で少しずつエラーにしてくるのがつらい。スクリーンショットも，厳密にピクセル数が決まっているのに，シミュレータではどうやってもその解像度の画像を作れないとか。最終的に「アップロードして完了したけどiPadのアイコンはなかったよ」とか言われて，修正するにはアプリのバージョンを上げないといけないとか。ちゃんとしたアプリを開発している人は途中で投げ出して，スパム業者だけはちゃんと頑張るみたいな状況になったりしないのかな。

ただ，輸出管理のことをちゃんと出してきたのはAppleストアだけかな。Mac版を申請しようとしたら，HTTPSを使っているだけでも輸出管理が必要だ，と言われて，なるほど，的な。denasu.comのHTTPS化でここに影響があるのか。結局，年次レポートを米国に出せばいいのかな。

Xamarin.FormsにWPFが追加されたので，Xamarinで実装できなかった既存機能をXamarinに入れている。あとはプラグインくらいなのだが，1つ問題が発生。

今回，プラグイン共通DLLであるWeatherTypingPlugin.dllを，PCLから.NET Standardに変更したりいくつか修正をした。でもこのDLLはStrong Nameになっているので，DLLのロード元をリビルドする必要がある。Denasu System公式プラグインはリビルドすればいいのだが，非公式のものもリビルドが必要になる。

V1共通DLLとV2共通DLLを両方読み込むと型が衝突してしまうし，V1共通DLL用のAppDomainとV2共通DLL用のAppDomainを分離して両方読み込んでみるというのも試したけど，結局，V1プラグインが作成した共通DLL内のインスタンスの型をコンパイルできず，うまくいかなかった。正攻法はGACに入れることなんだろうけど，やっぱり抵抗がある。

てことで，WeatherTypingPlugin.dllのStrong Nameを外すことに。これならファイル名が合っていて後方互換性を確保してあれば読み込める。今まで作られていた非公式プラグインは一度リビルドしてもらわないと動かなくなってしまうが，今ならまだ大丈夫だろうという判断。

ちなみに。UWP，つまりWindowsストアアプリでも.NET StandardなDLLを使ってプラグイン的なものは作れそう。AppDomainは作ることはできないのだが，DLLのLoadはできる。UWP自体サンドボックスで，ファイルアクセスなどが制限されているのでセキュリティ的にはそれほど問題はないのかな。ただ，DLLの置き場所が特殊すぎるので，プラグインのダウンロード機能は必須。

大学の頃の開発仲間の人達と15年ぶりに会ってきた。普通の飲み会ってあまり面白くないのでもうあんまり出ないけど，普通とちょっと違う生き方をしている人と話すのはやっぱり楽しい。

せっかくなのでその前にってことでラズパイワークショップ。前までは喫茶店とかでやっていたんだけど，機器を広げたりできないので，レンタルスペースを借りてみた。喫茶店で飲み物を頼むより少し高いけど，ホワイトボードもあって快適。さすがにハンダ付けは無理そうだから，そういうときはアキバの作業スペースなのかな。

議題はIoT版ウェザタイで，メインになるところはそろそろ動いてきそうなんだけど，ハードウェアというか，首から下げるキーボード的なというか，どうするかなあ。

WTマルチプラットフォーム版。Android版のテストが終わったので次はWindows 10 Mobileかな、と思って試してみたところ一つ問題が発生。どうもIMEの入力をキャンセルできないみたいで、CoreTextEditContext.NotifyTextChangedを呼ぶと勝手にIMEの変換履歴に残ってしまう。これだとひらがなの意味不明な文章が大量に履歴に出てしまうのでよくない。UWPサンプルを動かしてみようと思ったけど、何故かOSのアップデートができない。でいろいろしらべてみると、去年の10月頃、「Windows 10 Mobileは撤退？」のような話が出ているのか。日本以外ではそれなりに使われているのかと思ってたけど、そうでないなら対応する意味はほとんどないかな。てことでWindowsはデスクトップだけにするつもり。

マルチプラットフォーム版WTの開発は，Windows版のテストが完了した。次はAndroid版をテストしているのだが，Bluetoothキーボードがどうしても101キーボードとして認識されている。どうもキー入力を取得すると101のキーコードが来て，通常はIME側で106に変換しているっぽい。携帯だけならいいけど，raspberry pi版もあるのでどうしてもBluetoothキーボードに対応したい。ということで101->106変換を実装。

現状のWTでは101/106の2次元キー配列（1列分のキー×5段）を既に持っている。これを変換するマップを作ればいいわけで，普通に作ると2重のループで2次元配列のそれぞれを対応づけて，Dictionary<KeyCode, KeyCode>を作る感じ。こういう手続き型のコードはささっと書ける。

ただ，最近関数型言語を勉強していて，写像とか圏論に興味がある。なので関数型で書けないかな，って考えると，101キー集合から106キー集合への写像を作ればいいということなので，あえてLinqで書いてみた。んだけど慣れてなくてすごく分かりづらいものになってしまった。関数型に慣れてる人は簡単に書けるのかなあ。理解しづらいのは置いておいて，コンパイルできるようにするまでは大変なんだけど，書き終わって実行すると一発で動いた。このあたりは手続き型に対する関数型の強みになるのかな。

// KeyLine1をインデックス付きにする
x.KeyLines.Select((xLine, i) => new { index = i, line = xLine.KeyTops })
    // KeyLine2をインデックス付きにする
    .Join(y.KeyLines.Select((yLine, i) => new { index = i, line = yLine.KeyTops }),
        xLine => xLine.index,
        yLine => yLine.index,
        // indexが同じキー行でInner Join
        (xLine, yLine) =>
            // KeyTops1をインデックス付きにする
            xLine.line.Select((xKey, i) => new { index = i, key = xKey.KeyCode })
                // KeyTops2をインデックス付きにする
                .Join(yLine.line.Select((yKey, i) => new { index = i, key = yKey.KeyCode }),
                    xKey => xKey.index,
                    yKey => yKey.index,
                    // indexが同じKeyTopでInner Join
                    (xKey, yKey) => new { xKey = xKey.key, yKey = yKey.key }))
     // key1->key2のmapがキー行数分得られたので1次元配列にする
     .SelectMany(xLine => xLine)
     // キーとキーのDictionaryを作る
     .ToDictionary(item => item.xKey, item => item.yKey);

関数型言語だけど，元々Cマガの千言万語で興味があったのだが，最近いろんな言語で関数型言語的な書き方ができてきているので，Haskelを勉強してみた。で，やっぱりモナドで引っかかるので圏論を勉強し始めたのだが，むずい。群論とか線形空間とかの例はなんとなく分かるんだけど，位相空間とかになると分からない。と思っていたら丁度数学ガールの新刊で位相空間を説明していて助かった。

ウェザタイ。ついにテストに入って、ゴールデンウィークにはマルチOS対応をリリースできそう。各ストアも英語圏に登録して本格的に世界進出しよう、というところなんだけど、シリコンバレーシーズン4を見ていて、ちょっと怖くなった。

お話は、すごい圧縮率のアルゴリズムを使ったチャットサービスを運営してユーザがどんどん増えたけど、COPPA（児童オンライン保護法）に違反していてものすごい罰金を払わないと、っていうもの。話自体は相変わらず面白いんだけどそれは置いておいて、ヨーロッパのGDPRとか、知らないと大変なことになるものが出てきて、個人で作ってるアプリでは把握しきれない。みんなどうしてるんだろう。

ウェザタイも見直してみた。ウェザタイはユーザ登録はあるけど、ハンドルとパスワードだけ。パスワードは暗号化しているし、チャットデータとかはもちろん保持していない。DBに入っている情報は、そもそもランキングとかで公開しているわけで、盗まれても何の情報も漏洩しない。ってことでデータ自体に問題はないと思ってるんだけど、規約までいくとなかなか。

ただ、ランキングのWebサイト欄にメールアドレスを入れている人がいて、その場合は個人と紐付いてしまうわけで、そこだけDBから消してみた。ウェザタイ側でメールアドレスを入れても、今は登録されないようになっている。

第9回タイピングサミットで発生していた「一瞬でワードが消える問題」が解決。先週からずっと、サミットの時に取ってもらったリプレイを唯一の手がかりにして調査をしていた。

リプレイを見ていると、どうも他の人が打ち終わった次のフレームで、前回のワードを打ち終わって次のワードに行ってしまっている。なので、まずはラグを疑ってラグをシミュレートしてみたが、全然再現しない。

次にログを増やして何度もリプレイしていると、1人だけフレームがずれていることが分かった。でも入力不能時間に入力してみたりワード送信メッセージを遅延させてみたり、あらゆることをやって、再現しない。

結局、一番最初からフレームがずれていることが分かって、対戦開始画面でEnterが連打されているのが原因だと分かった。Enterを押す度にメッセージが送信されて、フレームがずれていた。

なかなか再現しないバグってのはたくさん経験したが、だいたい再現しなくていろんな特殊な条件を試しても再現せず、結局普通のことが原因なことが多い。今回もEnterを何度か押すという普通にやりがちな操作。少ない手がかりから原因を推理して、シンプルな結論を導き出していくっていうのはプログラミングの醍醐味ですね。プログラマに推理力は必須。

手元の資料によると、Denasu Systemという名前ができたのは1997年12月30日。ということは今日で20周年らしい。おめでとうございますありがとうございます。ウェザタイは2001年なのでもう少し先。

20周年記念に、ウェザタイのマルチプラットフォーム版の動画を置いておこう。まだまだバグが多いので、バグを踏まないよう動画を撮るのに苦労した。

Windows vs Mac vs iPad vs Androidと、ホスト用に従来のPC版を使った5人対戦動画。

オールフリーソフトさんでウェザタイを紹介してもらった。最近はストアが中心になっているので、フリーソフト紹介サイトが目立ってないイメージがあるけど、twitterを見ると結構アクティブに追加されていますね。

Twitterでいろいろやりとりしていたのだが、WTのプラグイン機能を実装して下さっている方がちらほらと。

月配列（permilさん）

なるほど、githubからforkするとこうなるのか。githubでちゃんとオープンソース運営するって手もあるけど、それだと普通の人が手軽にダウンロードして使うのが難しいし、やっぱりダウンロードサイトかな。ただ、まだ先になりそうなのでそれまでは結局日記で紹介していくしかないか。

Weather Typing 3.2.1がベクターの新着レビューに掲載された。しばらくベクタートップページにリンクされる。

前回のレビューがWT1.5の頃。15年前でずいぶん経ったので、先月更新の案内が来ていた。ちょうどRealforceイベントの件があったのでPocariさんに聞いてみたらOKってことだったので作者のひとこと欄にサミットについても触れておいた。ベクターのレビューは毎回結構深いところまで書いてくれるので読むのが楽しい。今回もWT2のときのマニュアルの情報にまで言及してくれていたり、、、ってWT3でマニュアル作れって話ではあるんだけど。