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

冬休みの研究としてウェザタイをクライアントサーバ方式にしてみた。これをそのまま使えばポート開放しなくてよくなる。ただ，全部をサーバクライアント方式にすると，サーバの通信量的にどうなんだろう，というのがあるので，直接つながらなかったときだけウェザタイサーバを使うようにすることを検討中。ちなみに通信量を測ってみたら，4人対戦で30ワード打つとだいたい送受信2.5MB。1日100回対戦があっても250MBで，全部クライアントサーバにしたところで，まあたいしたことはないのかな，とは思う。

ちなみに，以前のネットワーク構成。ホストとゲストをP2Pで接続するので，全員にポート開放が必要。元々はホストもゲストも同条件にしたかったのでこういう構成にした。

今のネットワーク構成。ホスト側にサーバを分離して，ゲストからはサーバにつなぎにいくので，ホスト側だけポート開放が必要。遅延が大きい環境だと，多少ホスト有利になる可能性がある。

で，検討中のネットワーク構成。分離していたホストをdenasuサーバへ持って行くことで完全なサーバクライアントに。

一応もう一つ選択肢があって，サーバを公開して誰でもサーバをたてられるようにする，というのもある。Linuxに.NET Core runtimeを入れて，1.5MBくらいのサーバを実行するだけで，サーバを立てるのは割とお手軽。

RTC2018の本番前、TwitterでWeather Typingの指摘をもらった。内容は、左右のシフトを両方押して片方離すとシフトが押されていないことになるというもの。ウェザタイ2では問題ないようなので、ウェザタイ3くらいからのバグっぽい。

ひとまず左右のシフトを区別しないまま、シフトを押した回数をReference Counter的に解決してみたが、左右のシフトの押し離しイベントの数が合わないことがあるようでダメ。RTC2018では修正しないことにした。

で、落ち着いて直してみたが、WPFはいいけど、UWPだとそもそもKeyDown-KeyDown-KeyUpしかイベントが来ない。こんなところでハマるとは。とりあえずKeyStateをとってシフトが押されてなければKeyUpイベントを無理矢理送ることでとりあえず解決。

ウェザタイ、RTC2018バージョンで改造した部分を本体のカスタマイズでできるようにする計画。まずは背景画像を設定できるように。

やっているうちにいろいろ増えてしまったけど、これだけあればだいたいのニーズに対応できるかな。タイル表示は難しいので入れてないけど。

前の日記で書いていたREALFORCEの画像を背景に設定したのがこれ。公式背景にはできないので、ここに貼り付けるだけ。

D.E.放送局さんの「視聴者参加型 タイピング対決～負けたら台詞読み～」を見てみた。ちょっと前に配信に使って良いか問い合わせて頂いたのだが，twitterで情報が流れてきたので。

タイピングサミットでオフラインの大会は何度か見ていたのだが，配信だとこうなるのか，というのでタイピングの動画としても面白かったし，開発視点でも参考になった。いくつかメモ。

• 対戦できる人数。仕様としては8人まで。誰かがOKを押して「待機中」になると，その後の人が参加できなくなる。そのため，4人で締切になったりしていた。キャンセルすれば「待機中」を消せるとかあるけど，やっぱりここは分かりづらい。
• 5人以上だと画面表示や通信の問題があるので，対戦人数を制限するオプションはいるかも。オフラインの大会だと人数を制限できるのでよいが，配信だと必要になってくる。
• 4桁のゲーム番号はアプリを終了させるまでは変わらない。これは何度か連続で同じ人とやる場合を考えた仕様だけど，配信の場合，ゲーム番号をみんなに伝えて早い者勝ちにする，って感じになってて，毎回変わった方が便利そう
• 配信者も，見てる側も，配信動画を流しながらウェザタイの対戦もしてるわけだが，4人対戦くらいなら十分な速度が出るというのが分かった。8人はさすがに重そうだったけど。

ついでに，ちょくちょくウェザタイを○○に使いたい，っていうメールを頂いているので，「よくある質問」にOKって書いておいた。

Weather Typing 3.3がMacOSストアで公開された。これで予定していた全プラットフォームで公開されたことになる。GitHub更新がまだ残ってるけど。

各ストアの入り口はWeather Typingのページを参照。

明日から関西に別荘を作って仮住まいするので，なんとか間に合ってよかった。これから荷物を準備しないと。

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を何度か押すという普通にやりがちな操作。少ない手がかりから原因を推理して、シンプルな結論を導き出していくっていうのはプログラミングの醍醐味ですね。プログラマに推理力は必須。