Windowsストアアプリ: 第十四工房

プライバシーポリシーとサポート情報 - Subnet Designer U ― 2018年11月09日 09:00

本アプリについて (About this app)

※本アプリは、2018年11月、ストアでの新規配信を終了しています。

This app was unpublished at Nov. 2018.

本アプリは、IPv4のSubnetの設計において、必要なSubnetの数と1つのSubnetが収容するホスト数をもとに、最適なSubnetを求める作業を支援します。

Windows8.1用のストアアプリを、Windows10向けのUWPアプリとして移植したものです。

This app helps you design a subnet based on number of subnets and number of hosts per subnet. This Windows10 UWP app is ported from a previous Windows8.1 store app.

プライバシーポリシー (Privacy statement)

対象アプリ：Subnet Designer U

本アプリの製作者であるThe Fourteenth Lab （第十四工房）は、本アプリによって、お客様の個人情報およびプライバシーに関する情報を収集しません。

This app uses no Internet connection. No information of any kind, personal or otherwise, is transmitted or collected by The Fourteenth Lab.

サポート情報 (Support)

ご質問や不具合のご連絡は、このページの「コメント欄」をご利用いただくか、「このブログについて」に記載の連絡先までお願いします。

If you have any questions or bug information, please fill in the comment field below or email me. The email address is printed in the left side.

あらかじめのおことわり (FAQ)

１）wildcard mask（または、inverse mask）は、Ciscoのルータでアクセスリストを設定する際などに用います。

Wildcard mask (or inverse mask) is applied to access list configuration in cisco routers.

※Ciscoのページ

http://www.cisco.com/c/en/us/support/docs/security/ios-firewall/23602-confaccesslists.html

CNTKでConvolutional Neural Networkの学習 ― 2018年11月08日 20:41

CNTKでConvolutional Neural Network(CNN)を用いたモデル構築。GitHubにあるサンプルを参考に、とりあえずアプリを動かすところまで到達。データの準備を除き、50時間ほど。

試走とはいえ、エラー率が7割と惨憺たる結果。データによっては、9割に達するものも。ここから、どうやって精度を上げていくか。ドキュメントを読む限り、パラメータを変えて対象のデータの性質を見極める、試行錯誤に尽きるらしい。データの数も増やしていかないと。

さて、ここから面白くなるのか、途方に暮れて飽きてしまうのか。「AI技術者」の端くれになるのもなかなか大変な予感。めざしてはいないけど。

C#でCNTK - 起動時のDLL読み込みエラー対応 ― 2018年11月01日 19:39

CNTKでMLに挑戦。学習用のデータの準備に目処がついたので、モデルの学習と検証のアプリの構築に取りかかる。いまさら、Pythonに取り組むのもなんなので、C#で頑張ってみる。こちらのライブラリも順次拡張中。

UWP向けには、C++のライブラリしか用意されていないので、WPFによるデスクトップアプリで実装。nugetからパッケージを導入。計算用のデバイスを確認するコードで動作確認。すると、DLLの読込で例外発生。

C++のEEMessageExceptionが発生し、System.TypeInitializationExceptionがスローされている。

調べてみると、CNTKのライブラリはx64のみで提供されるところ、アプリをx64でビルドしないと発生するとの記事が見つかる。デフォルトの「Any CPU」でも自動判別されるはずだが、それではうまくいかないらしい。

構成マネージャを起動すると、デスクトップアプリのプラットフォームでは、「Any CPU」しか選択できない。プルダウンメニューで[<新規作成>」を選び、「x64」を追加しようとするが、うまく追加できない。

ポイントは、「新しいソリューションプラットフォームを作成する」のチェックを外すこと。図では、後からキャプチャしたのでx86になっているが、「x64」を選択後、チェックを外して、OKを押下する。

ビルドして実行すると、無事に起動。ただし、アプリのサイズはかなり大きくなる。GPUの無い環境でGPUを選択したので、例外発生のメッセージを表示している。

Windowsアプリケーションパッケージプロジェクトを追加し、デスクトップブリッジに対応しておけば、GPUのあるリモート環境への配置やデバッグ実行も容易にできる。

画面属性と制御 - アプリリリース ― 2018年10月17日 12:40

「画面属性と制御」の名称でWindowsストアアプリをリリース。デスクトップブリッジを用いたふたつめ。Windowsストアの方で通常の手続で審査を受け付けるようになってからは、ひとつめ。審査を通すのにそれなりに苦労したのは既述の通り。

※アプリのページ

https://www.microsoft.com/store/apps/9NGHTL0WFGFH

もともとは、複数のディスプレイをつなげた環境で、ディスプレイのオンオフを行う意図。ディスプレイの消費電力はかなり大きい。なかでもIPSパネルは大きめ。しかし、個別のディスプレイの電源制御は、ドライバが対応していないことが判明し、そのあたりの属性の確認と、システム全体でのディスプレイのオフを実装したもの。オフ自体は、スクリーンセーバで電源を切るのと同じ。

システム全体のディスプレイのオフでも、それなりには役立つ。手動でディスプレイの電源を切っていくと、Windows10のバージョンにもよるが、アプリが点いているディスプレイに移動する。ディスプレイの電源を戻す度に、アプリを手で戻さなければならない。本アプリでオフにすると、アプリのウインドウの移動は起こらない。

開発時間は、30時間ほど。うち4分の1ほどは、Windowsにおけるディスプレイの扱いや、属性の理解に使ったもの。10S環境でのテストや、使用不可のAPIのUWP版での置き換えなど、いろいろ課題を見つけた開発だった。

サニティテストの結果見落とし - デスクトップブリッジ ― 2018年10月13日 10:07

デスクトップブリッジを用いたアプリの登録に苦戦。Windows 10S向けのテストの件もそうだが、なんとか突破。

Windows App Certification Testの実行後、表示されるダイアログでは、「合格」。これが曲者。

結果を表示してみると、「省略可能なテストの結果」の「サニティテスト」、「ブロック済みの実行可能ファイル」のテストが不合格。これが、「Windows 10Sで起動に失敗」とストア担当者から指摘されていた原因の模様。毎回、きちんと中を確認しなくては。

問題となっていた「System.Diagnostics.Process.Start()」は、プライバシーポリシーを掲載するWebページを開く際に用いていたもの。引数に「new ProcessStartInfo(Uri)」を指定。これについては、UWPのAPIである「Launcher.LaunchUriAsync()」で代替。

代替フォントを避けてフォントの字体を確認する ― 2018年10月11日 16:58

字体を確認するツールを作っているが、フォントが用意していない文字コードを指定すると代替フォントが表示され、混乱する。

代替フォントが表示された後、XAMLのFontFamilyを確認するも、指定したFontFamilyの値を返すばかりで、代替フォントであるかどうかの判別はできない。

探してみると、Win2DでCanvasFontFaceを取得すると、そこからUnicodeRanges属性が得られ、フォントが定義されているかどうか判別できそう。

59行；システムで利用可能なフォント一覧の取得。

60行；フォント一覧のCanvasFontFaceの取得。

89行；UnicodeRangesの取得。

UnicodeRangesは、FirstとLastのペアの配列。First～Lastの範囲でフォントが定義されていることを示す。

行176；与えられたUnicodeについて、UnicodeRangesで定義された範囲内かどうかを判別。効率が悪いやり方なのはご容赦。

行170；与えられたUnicodeについて、UnicodeGeneralCategoryを取得し、未設定や記号を排除しているが、代替フォントがある場合は排除できない。ちなみに、漢字はOther Letterになる。

実際にツールを動かしてみたところ。「丙」の文字。U+4E14からU+4E19の範囲内にあり、フォントが定義されている。次は、U+4E1Eに飛ぶ。この範囲だが、かなり細切れ。UnicodeRanges配列の要素はかなり多い。

これで、ゴシックを表示していたら明朝が混じる、といったことを防ぐことができる。これで、ようやくWindowsアクセサリの「文字コード表」と同じところ。

Windows 10S 向けのテスト - デスクトップブリッジ ― 2018年09月29日 18:02

ふと気がつくと、以前いろいろ苦労した、デスクトップブリッジを用いたアプリのWindowsストアでの認証手続が、通常のUWPアプリと同じになっている。

それではと、溜まっていた手続を進めてみると、不合格の通知。アプリが起動しない、という。環境を見ると、Windows 10Sで失敗している。忘れていた、ということで、Windows 10Sのテストを実施することに。

Windows 10Sのテストといっても、手許に実機はない。後で述べるが、仮にあったとしても、ストアから配布されるものでないとインストールできない。そこで、Windows 10 Proの環境にDevice Guard整合性ポリシーをセットアップしてテストを行うという。

VMwareでProの環境を一つ作り、ダウンロードしたポリシーを当てる。3種のポリシーがあり、再起動で切り替える。

ひとつめのAuditモードでは、不整合がイベントビューアに記録される。作成した環境をリモートコンピュータに指定して、Deployしたアプリを実行する。致命的でないメッセージも出力されるので、判別が難しい。

ふたつめは、テスト用に用意された証明書を使って確認するもの。手作業でパッケージを作成することになるので、それなりに手間。

手順に従い、signtoolを用い、用意された証明書を使ってサインをするが、エラー。PowerShellのコンソールメッセージに従い、調べてみると、manifestにある「発行者」に不整合がある。

手順に、AppxManifest.xmlファイルを暫定的に書き換える、とあるが、実際は2箇所。

一つは、

bin\(architecture)\Debug\AppX

にあるもの。

もう一つは、

bin\(architecture)\Debug

にあるもの。

両方の発行者を、用意されたテスト用の証明書にしたがって書き換える。VisualStudioで編集するPackage.appxmanifestはいじらない。これでエラーは解消。

用意したWindows 10Sの方では、テスト用の証明書を受け容れる準備。手順に「証明書ストアの選択」で「Trusted People」を選ぶ、とあるが、日本語の環境では、「信頼されたユーザー」。少々訳がわかりにくい。

OneDrive経由で、サインしたパッケージをWindows 10Sのテスト環境に転送し、appxファイルをダブルクリックすると、App Installerが起動し、インストールが完了。PowerShellでAdd-AppxPackageを使いたいところだが、ポリシーによってはPowerShellが起動しない。App Installerは、追加でセットアップされるので、Windows Updateで最新の状態にしておく。

これで問題なく起動すれば、OK。

ちなみに、ストアに提出用のappxuploadファイルの拡張子をzipにしてから展開し、中のappxやappxbudleをインストールしようとすると、証明書まわりのエラーになる。Windowsストア経由で入手したものでないといけない。したがって、3つめのポリシーを用いたテストは、開発段階で使えるものではない。

結果、どのテストでも問題はなく、不合格の理由は、Windows 10S由来のものではなさそう、とのオチ。