翔星 Be ランド日記 : 2019年06月 - livedoor Blog（ブログ）

2019年06月

2019年06月30日22:13

カテゴリ

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

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

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

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

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

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

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

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

画面に案内が表示されますので、案内に従って操作をして下さい。

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

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

ダウンロード
- ゆかりすたー METEOR 公式サイト
- http://shinta.coresv.com/software/yukalister-meteor-jpn/

旧作について

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

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

タグ：: ゆかりすたー

2019年06月30日14:07

カテゴリ

ゆかりすたー 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 公式サイト
- http://shinta.coresv.com/software/yukalister-meteor-jpn/

旧作について

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

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

タグ：: ゆかりすたー

2019年06月29日14:43

カテゴリ: ソフトウェア－開発全般

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

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

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

	フォームゆかりすたー Ver 7.51	WPF / コードビハインドゆかりすたー METEOR Ver 1.50	WPF / MVVM ゆかりすたー METEOR Ver 2.02
保守容易性指数	82	84	86
サイクロマティック複雑度	3888	3933	4480
継承の深さ	7	9	9
クラス結合	431	466	465
コード行	12498	9685	9333

保守容易性指数

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

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

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

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

保守容易性指数（というかクラス結合以外）に変化がない。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 はシンプルさで売ってないし……。

タグ：: MVVM; CSharp

2019年06月23日10:30

カテゴリ: リサーチ

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

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

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

相性の悪い USB メモリ

USB メモリ 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 を挿して動画情報更新をしても終わらない。なお、以降はすべてハブ経由の接続。

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

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

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

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

ストレージ 5 本挿し

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

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

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

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

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

すると、今まで使えていた 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 はたぶん認識されたと思う。

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

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

タグ：: PetitKara

2019年06月16日20:34

カテゴリ: ソフトウェア－開発全般

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());
}

タグ：: CSharp; MVVM

翔星グループ

月別アーカイブ

カテゴリ別アーカイブ

その他 (17)

リサーチ (142)

ソフトウェア－HaikuOS関連利用 (10)

ソフトウェア－UTAU関連利用 (14)

ソフトウェア－利用全般 (19)

ソフトウェア－HaikuOS関連開発 (2)

ソフトウェア－UTAU関連開発 (18)

ソフトウェア－Web関連開発 (8)

ソフトウェア－携帯端末開発 (1)

ソフトウェア－開発全般 (40)

環境構築 (45)

お知らせ (252)

ソフトウェア－ニコカラ (6)

イベント (11)

ゲーム (13)

記事検索

翔星 Be ランド日記

2019年06月

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

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

旧作について

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

更新内容

Windows Defender について

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

旧作について

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

保守容易性指数

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

継承の深さ

クラス結合

コード行

まとめ

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

相性の悪い USB メモリ

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

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

ストレージ 5 本挿し

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

MVVM ダメ Tips

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