2019年06月

ゆかりすたー METEOR Ver 2.15 α 公開

MainWindowゆかりすたー METEOR(メテオ)の新バージョン、Ver 2.15 α を公開しました。

立て続けの公開となりましたが、インポート時などに ID 接頭辞を設定する際のチェックが抜けていた不具合を修正しました。

また、環境設定ウィンドウでも ID 接頭辞を設定できるようにしました。

更新・新規インストール方法

ゆかりすたー METEOR は自動更新機能を搭載しています。既にゆかりすたー METEOR をお使いの方は、ゆかりすたー METEOR を起動すると、3 日以内に更新のアナウンスが表示されます。

すぐにアップデートしたい場合は、環境設定ウィンドウのメンテナンスタブを開き、「今すぐ最新情報を確認する」ボタンをクリックすることで、アップデートを開始することができます。

Ver150to168右のようなダイアログが表示されますので、「はい。今すぐ更新します」をクリックしてください。

ゆかりすたー更新版インストール画面に案内が表示されますので、案内に従って操作をして下さい。

ゆかりすたー更新完了ほどなくして、ゆかりすたー METEOR の更新が完了します。

これから初めてゆかりすたー METEOR を使う方(新規の方)や、手動でゆかりすたー METEOR を更新したい方は、下記サイトからどうぞ。

旧作について

ニコカラりすたーおよびゆかりすたー(初代)は開発を終了しました。

今後はゆかりすたー METEOR をご利用下さい。

ゆかりすたー METEOR Ver 2.12 α 公開

MainWindowゆかりすたー METEOR(メテオ)の新バージョン、Ver 2.12 α を公開しました。

ゆかりすたー METEOR はニコカラ動画ファイルを整理し、「ゆかり」(持ち込みカラオケ用のブラウザリクエストツール)から検索できるようにするツールです。データベースを活用することにより、タイアップしている番組名や歌手名などの付加情報を含めて整理するので、単なるファイル名検索にとどまらない高い検索性を提供することができるようになります。

ゆかりすたー METEOR は、ニコカラりすたーおよび初代ゆかりすたーの後継ソフトとして開発しています。ニコカラりすたーは一時点でのリスト化機能のみを提供していましたが、ゆかりすたー METEOR は、ゆかりと連携した高度な検索性の提供を目的に、リアルタイムでのリスト化機能と検索用データベース構築機能を提供します。

更新内容

今回のバージョンから、ゆかりすたー METEOR の動作には .NET Framework 4.5.2 以上が必要となります。今までは .NET Framework 4.5 以上で動作していましたので、.NET Framework 4.5 または 4.5.1 をお使いの方は、.NET Framerork のバージョンアップが必要となりますのでご注意ください。

機能的には細かな内容のバージョンアップです。

メインウィンドウやファイル一覧ウィンドウにおいて、行の高さを細くして、一覧性を向上させました。

歌手の編集ウィンドウにおいて、人物が同姓同名の場合はキーワードを併記して見分けが付くように改善しました。

インポートウィンドウにおいて常に進捗を表示するようにしました。

その他、細かい改善をしています。今回の更新内容を含む課題対応履歴についてはこちらをご覧ください。

なお、内部的な構造を刷新し、MVVM プログラミングモデルを採用したため、プログラムはイチから作り直しています。

Windows Defender について

Windows Defender がゆかりすたー METEOR の動作に悪影響を及ぼす場合があり、エラーが発生したり、処理速度が異常に遅くなったりする例が報告されています。

ゆかりすたー METEOR を使う際は、Windows Defender を使わないことをお薦めします。

詳細についてはこちらをご覧ください。

更新・新規インストール方法

ゆかりすたー METEOR は自動更新機能を搭載しています。既にゆかりすたー METEOR をお使いの方は、ゆかりすたー METEOR を起動すると、3 日以内に更新のアナウンスが表示されます。

すぐにアップデートしたい場合は、環境設定ウィンドウのメンテナンスタブを開き、「今すぐ最新情報を確認する」ボタンをクリックすることで、アップデートを開始することができます。

Ver150to168右のようなダイアログが表示されますので、「はい。今すぐ更新します」をクリックしてください。

ゆかりすたー更新版インストール画面に案内が表示されますので、案内に従って操作をして下さい。

ゆかりすたー更新完了ほどなくして、ゆかりすたー METEOR の更新が完了します。

これから初めてゆかりすたー METEOR を使う方(新規の方)や、手動でゆかりすたー METEOR を更新したい方は、下記サイトからどうぞ。

旧作について

ニコカラりすたーおよびゆかりすたー(初代)は開発を終了しました。

今後はゆかりすたー METEOR をご利用下さい。

フォームと WPF でコードメトリックスを計算・比較してみた

MVVM
同等の機能を持つソフトでフレームワークが異なる場合、Visual Studio 2017 で計算できるコードメトリックスはどのくらい変わるのか、というのが気になったので、あまり意味はないけど測定してみた。

対象プロジェクトはゆかりすたー。バージョン間で細かな違いはもちろんあるものの、大まかに見れば機能的にはほとんど同等。結果は以下の通り。

フォーム
ゆかりすたー
Ver 7.51
WPF / コードビハインド
ゆかりすたー METEOR
Ver 1.50
WPF / MVVM
ゆかりすたー METEOR
Ver 2.02
保守容易性指数828486
サイクロマティック複雑度388839334480
継承の深さ799
クラス結合431466465
コード行1249896859333

保守容易性指数

公式解説によれば保守容易性指数の値が大きいほど保守性が高く、0~9 がダメ、10~19 がまぁまぁ、20~100 が OK とのこと。

いずれのフレームワークでも 80 以上なのでかなり良好と言えると思うが、WPF のほうが少し高い数値になっている。

ただ気になるのは、WPF の XAML 部分はあまり考慮されていないのではないかということ。WPF / MVVM で試しにメインウィンドウの XAML からコントロールをさくっと削り、メインウィンドウ部分の評価を比較したのが以下。

元の WPF / MVVMコントロール削除
保守容易性指数91
91
サイクロマティック複雑度11
継承の深さ99
クラス結合72
コード行22

保守容易性指数(というかクラス結合以外)に変化がない。XAML に複雑な表示ロジックをべた書きして、代わりに ViewModel からコードを減らしたら、保守容易性指数はあがってしまうのではないか。ちょっとインチキ臭い。XAML を考慮に入れると、フォームと WPF で保守容易性はほとんど変わらないと言えるかもしれない。

さて、総合的には保守容易性指数が 86 の WPF / MVVM でも、細かく見ていくと値が低い部分もある。最低は 0 で、ViewTFoundsWindowViewModel.cs の DataGridListSorting()。ソート基準項目によってひたすら switch するので低い評価になっている。

次に低いのが CsvOutputWriter.cs の Output() で 28。こちらも出力項目ごとに switch していて、switch の case が並ぶのは低い評価になりやすいのかもしれない。

サイクロマティック複雑度

Wikipedia を読むと、サイクロマティック複雑度(循環的複雑度)はプログラム実行時の経路数に関係する値で、大きいほど経路・分岐が多くなる。プログラムの動作を理解するのが大変になったり、テストケースが多くなって大変になったりするのだろう。

プログラムの規模が大きくなるにつれてサイクロマティック複雑度も大きくなっていく性質があるので、単純に数値だけを見て良い悪いは言えないが、相対的に WPF よりフォームの方が値が小さいので、フォームの方が理解しやすいという見方ができるのではないか。体感としても、フォームの方が簡単だと思う。

継承の深さ

使用しているクラスが、根源となるクラスである Object から何段階派生しているか。WPF のほうがクラス階層が深いが、最大の 9 となっているクラスはすべてウィンドウだった。WPF でウィンドウを使うと必ず 9 以上になるということからすれば、結果が 9 であるというのは少ない値と言えるだろう。

クラス結合

低い方が良い数値。フォームの方が低い。

コード行

ソースコードの行数ではなく、IL の数。ソースコードのコメント行や空行は数値に影響しないと思われるため、単純にソースコードの行数を数えるよりも実際的。

ソースコード行数より少ない数値となる傾向があり、例えば 最大値を記録した SyncClient はソースコード上は 2058 行だが、IL では 882 行と、半分以下になっている。

フレームワーク間で比較すると、WPF のほうがずっと少なくなっている。フレームワークに関係ないところで最適化してるところが(ソースコード行数ベースで)1000 行ほどあるが、それを差し引いても WPF のほうが少ない。

ただし、WPF は使用しているライブラリが多く、それらまで含めると、総合的なコード量はフォームのほうが少なくなるのではないだろうか。

まとめ

元々あまり意味のある比較とは思えないものの、傾向としては、フォームの方がシンプル・コンパクトということになるだろう。元々 WPF / MVVM はシンプルさで売ってないし……。


PetitKara のストレージ認識状況メモ

PetitKara にいくつか USB メモリや HDD を繋げた際の挙動をまとめてメモ。記憶を頼りにしている部分もあり、もしかしたら間違っている部分もあるかもしれない。

使用した PetitKara のバージョンは 1.4.19 で、WAN 側はインターネットに接続していない。

相性の悪い USB メモリ

transcendUSB メモリ A(JetFlash Transcend 2GB、NTFS、動画ファイルなし)を本体に直接挿して起動したところ、Debian のデスクトップまでは起動するが、PetitKara が起動しない。

Debian は USB メモリ A を認識していて、デスクトップに USB メモリ A のアイコンが表示されていた。

動画情報更新で読めない HDD

PetitKara が起動した状態で HDD E(Western Digital My Passport 4TB、青色、NTFS、動画ファイル 4 万個)を本体に直接挿し、動画情報更新をしたところ、10 分以上経っても動画情報更新が終わらない。HDD のアクセスランプが点滅しておらず、HDD にアクセスしている気配が無い。

セルフパワー型ハブ(Anker 10-Port USB 3.0 Hub)に HDD E を挿して動画情報更新をしても終わらない。なお、以降はすべてハブ経由の接続。

guruguru2動画情報更新を中断し、ログインして動画を検索すると、ぐるぐるアイコンから先に進まない。

HDD F(4TB、黒色)についても同様で、起動後の動画情報更新で認識してくれない。

動画情報更新可能な USB メモリ

sonyUSB メモリ B(SONY Storage Media 32GB、NTFS、動画ファイル 250 曲)は、PetitKara 起動後に挿して動画情報更新をしたら認識してくれた。

ストレージ 5 本挿し

storage5a起動後の動画情報更新ではなく、起動時に挿しておくと認識してくれることに気がついた。

USB メモリ B、USB メモリ C(水色)、HDD E、HDD F、HDD G(Buffalo HD-PNFU3、1TB、黄色、動画ファイル 1.3 万個)の 5 つを接続した状態で起動すると、Debian のデスクトップにすべてのストレージのアイコンが表示された。

41709aPetitKara でも基本的には認識されたが、HDD E については認識してくれなかった。検索結果は 42,000 件ほど。

この状態でしばらく運用していたところ、2 回ほど、曲が途中で終了してしまう状況が発生した。

Debian では認識されているが PetitKara からは認識されていない HDD E が何らか影響しているのかと思い、HDD E を外してみた。本来は外した後で動画情報更新を行うべきであるが、動画情報更新はうまくいかないことが分かっているので、動画情報更新はしていない。

notfoundすると、今まで使えていた USB メモリ B の中の動画について、検索結果には引き続き出てくるものの、リクエストしようとすると「動画が見つかりません」というエラーとなった。

USB メモリ B の中には、HDD E と同じファイルの一部が入っている形になっており、ファイル名だけで見れば HDD E と重複しているが、それが何か関係しているのであろうか。

別の組み合わせでストレージ 5 本挿し

USB メモリ B、HDD E、HDD F、HDD G、HDD H(Western Digital My Passport 4TB、黄色)の 5 つのストレージを起動時から接続しておいたところ、先ほど認識されなかった HDD E も含めて 5 つすべてのストレージが認識されたのではないかと思うが、ファイル数が多すぎて今ひとつ自信が無い。HDD E のパスをキーワードにして検索した結果の数から見て、HDD E はたぶん認識されたと思う。

100kキーワードを空にした場合、検索結果が省略されてしまっているが、10 万件ということだと思う。

5087検索結果ページ数は 5087 ページ。





MVVM ダメ Tips

使ってはいけない Tips。コードは Livet 環境前提。

ViewModel から直接 View を参照してしまう

最早 MVVM ではないが、添付ビヘイビアとか作るの面倒くさい時に。
Initialize2() の引数に Window オブジェクトが渡される。

XAML 側コード

<i:EventTrigger EventName="ContentRendered">
    <l:LivetCallMethodAction MethodTarget="{Binding}" MethodName="Initialize"/>
    <l:LivetCallMethodAction MethodTarget="{Binding}" MethodName="Initialize2" MethodParameter="{Binding ElementName=MyWindow}"/>
</i:EventTrigger>

ViewModel 側コード

public void Initialize2(Object oParam)
{
    Debug.WriteLine("Initialize2() param type: " + oParam?.GetType().ToString());
}


月別アーカイブ
記事検索
最新コメント
  • ライブドアブログ