.NET Interactive の C# REPL を Jupyter で

今回は、 .NET Interactive を利用し、ローカルマシンで C# や PowerShell Core の REPL を利用するまでをまとめる。

なお、 とりあえず動かしてみたいだけであれば、 launch binder バッジのリンクをクリックして、 オンライン上の Binder にブラウザにアクセスするだけで、利用することができる。
Use Jupyter with .NET Interactive on Binder

.NET Interactive とは

.NET Interactive は、 以前 Try.NET と言う名前で提供されていた、 .NET のインタラクティブな機能を提供する API スイートだ。
JupyterLab に .NET カーネルを追加する形で、 REPL の実行やノートブックの作成する仕組みを提供することが、 主なユースケースとなっている。

REPL ではコード補完も効くので、非常に便利なものになっている。

Jupyter について

まず、 Jupyter についても軽く説明しておく。
既にご存じなら読み飛ばして欲しい。

JupyterLab とは?

続きを読む

Linux や Windows で大量の nanaco ギフトを自動登録して、オトクに税金を支払う

突然だが、自動車税や固定資産税などの税金を、どのように払っているだろうか?
支払う額も大きくなりがちなので、なるべくお得に支払いたいのではないだろうか。

そこでオススメなのが nanaco ギフト だ。

クレジットカードで直接納税したり nanaco 残高にチャージする場合、手数料がかかったり、ポイントがたまらなかったりと、あまりお得にならない。
しかし nanaco ギフトであれば、お得に購入する手段が知られている。

  • ベネフィット・ステーション
    • 福利厚生型の会員制割引サービス。
    • 2020年4月現在、 毎月 10万 円分まで 額面の 2% OFF で nanaco ギフトを購入できる。
    • 所属組織による団体加入か、 「ベネフィット・ステーション プライベート」 や 「デイリーPlus」 といった個人向けの有料サービスで利用できる。
  • Kiigo (廃止)
    • 以前はクレジットポイントを貯めながら nanaco ギフトを購入できたのだが、 2019年 に nanaco ギフトの取り扱いがなくなってしまった。

また nanaco 残高と違ってセンターお預かりへのチャージなので、 チャージ残高の上限が非常に高く (50万円以上も可能らしい)、 nanaco 残高のチャージ上限である 5万円を超えるような金額の支払いでも使える大きなメリットがある。

nanaco ギフトでのお得な納税の話は、他のサイトでもっと詳しくわかりやすく書かれているだろうから、これくらいにしておく。

nanaco ギフトの登録がめんどくさい

さて、 ここからが本題だ。

そんな nanaco ギフトにもひとつ 大きな欠点がある。
それは、 1,000 円単位で提供されることが多い ということだ。

例えば 10万円分 チャージしようとすると、 100 回も nanaco ギフトID のコードを入力しなくてはならないのだ。

更に、 nanaco ギフトの登録を行う UI が、大量のギフト登録に とても優しくない
1回 コードを入力する毎に nanaco にログインしたり、 コードを 4文字 ずつテキストボックスに入力しなくてはならなかったりと、 数をこなすのにとにかく手間がかかるのだ。

10万円 の納税で 2,000円 得するために、 2,000円分 相当以上の手間をかけるのでは愚の骨頂だ。
こうなったら、自動入力させるしかない。

続きを読む

タスクトレイで指令を待ち続ける健気な PowerShell スクリプト

この記事は PowerShell Advent Calendar 2019 の 23日目 の記事だ。
日程が埋まりきっていなかったので、適当な内容で埋めていこう。

あなたは、 PowerShell の短いコードを、 デスクトップのアイコンをクリックするのも億劫なほど、手軽に実行したいと思ったことはないだろうか?

ないって?
私はある。

例えば、ブラウザなどでコピーして WYSIWYG エディターにペタリと貼り付けるときに、クリップボード内の装飾情報を削除したいとか。

(Get-Clipboard -TextFormatType UnicodeText -Raw) -replace '^[ \r\n\t]*|[ \r\n\t]*$','' | Set-Clipboard

PowerShell なら上記のような一行コード実行すれば済む話だ。 しかし、 ウィンドウをシェルに切り替えたり、 ショートカットクリックするのも面倒。 タスクトレイのアイコン一つクリックして実行できたらいいのに。

はい、それを叶えます。

続きを読む

同一ファイルに対して、 複数種類のファイルハッシュを高速に計算する

ネットワークドライブ上の GB オーダーのファイルに対して、複数のハッシュアルゴリズムでファイルハッシュを計算する必要に駆られていた。
「そんなシチュエーションが本当にあるのか?」と思うかも知れないが、あったのだから仕方ない。

最初は、 PowerShell を使って 愚直に Get-FileHash を 2回 計算していた。
しかし当たり前だが、 2回ファイルをダウンロードすることになるこの方法は遅くて仕方ない。

ということで、 C# でコンパイルしたコード上で、 一度メモリに読み込ませてから複数のハッシュアルゴリズムで計算できるようなコードを作成した。

バッファーサイズを 80KiB 程度とすると、 .NET の仕様で 85KB を境にメモリの扱いが変わる (LOH と呼ばれる特別なヒープに移動する) ことから、 このサイズを超えると一般的に動作速度が下がると言われている。
しかし、今回のコードの場合バッファーが小さいと、 Task 周りの処理がボトルネックになってしまうので、 8MiB くらいのサイズとしている。

80KiB としているのは、 .NET mscorlib の System.IO.Stream.CopyTo メソッドなどでもおなじみなのだが、これが必ずしも正解とは限らないわけだな。


パフォーマンス

800Mbps 位でシーケンシャルリードできるリモート上の 4GB のファイルを、 4回 ずつ計測した平均を計測した。
Get-FileHash の 2種類目 以外はクライアントキャッシュが効かないように注意し、 計測の各回でハッシュを計算するファイルはそれぞれ別のファイルで、中身はランダムバイナリとした。
Get-FileHash については、 計測の各回では同じファイルに対して -Algorithm パラメータを変えて複数回連続で呼び出した。

計算したハッシュの種類 Get-FileHash 上記の改良スクリプト
1種類 (SHA1) 48.8s 43.3s
2種類 (MD5, SHA1) 60.4s 44.2s
3種類 (MD5, SHA1, SHA256) 83.3s 48.2s

ん? 計算したハッシュが 1種類 の場合でも、改良スクリプトの方が早いぞ?


うわっ… HashAlgorithm.ComputeHash の実行速度、低すぎ…?

PowerShell v5 相当

PowerShell v6 相当

上記のように、 Get-FileHash は、内部的に HashAlgorithm.ComputeHash でハッシュ計算を実行している。

で、その HashAlgorithm.ComputeHash がどうなっているかというと、 4KiB 毎に ファイルの読み込みと、 ハッシュストリームへの書き込みを 同期的に 行っている。

ファイルの読み込みも、 (使うアルゴリズムにもよるけど) ハッシュの計算も、 どちらもコストがかかるので、同期的にやってたらそりゃ遅いわ。

ZoneId を PowerShell を使って一括削除 [v3 以上]

Windows では、リモートからダウンロードしたファイルに、 "ZoneId" という物が付加される。
このID が付加されたファイルは、 exe として 実行する際にセキュリティ警告が表示されたり、 .NET アセンブリ dll として PowerShell に読み込む際に、

Add-Type : ファイルまたはアセンブリ 'file:///*.dll'、またはその依存関係の 1 つが読み込めませんでした。操作はサポートされません。 (HRESULT からの例外: 0x80131515)
発生場所 行:1 文字:1
+ Add-Type -Path 'C:\*.dll'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Add-Type], FileLoadException
    + FullyQualifiedErrorId : System.IO.FileLoadException,Microsoft.PowerShell.Commands.AddTypeCommand

などとエラーになってしまう。
160925_1

ファイルが一つだけなのであれば、ファイルのプロパティから『ブロックの解除』をチェックすれば、簡単に ZoneId を削除することができる。
160925_2
しかし、複数個のファイルの ZoneId を一回の操作で同じように削除することができないため、 ZoneId を削除したいファイルが大量にある場合はなかなかウザい。

PowerShell v3 以上を使えば、この ZoneId 削除をいとも簡単に行うことができるので、紹介しよう。

続きを読む

PowerShell バージョンごとのスクリプティング機能の新機能概略

PowerShell v3 以降のそれぞれのバージョン毎のスクリプティングを中心とした新機能のうち、私の独断で選んだ主な機能を列挙してみた。
(PowerShell の本来の役割のはずの) コンピュータ管理機能などはばっさり省いている。

意外と、そういう情報まとまっているのを見たことなかったので。。。

続きを読む

PowerShell の組織の中で使えそうで使えないニッチな Tips

この記事は、 PowerShell Advent Calendar 2015 の 18日目 の記事だ。
私はこれまでずっとネットヒッキーだったので、ネット上でほかの人とのかかわりを持ったことがほとんどなかったが、今回意を決して参加させてもらうことになった。

バリバリの 情シス や プログラマ ではなくても、日常のちょっとした業務で PowerShell を使っている人もいるだろう。
そういったひとびと(主に私)が、組織の中で使えそうだと思ったニッチな話題を書こうと思う。

  • PowerShell Tools for Visual Studio を商用利用する環境は、無料でできる
  • コンソールウィンドウを極力表示せずにスクリプトを実行
  • ネットワーク共有上の DLL を読み込む

続きを読む

SQLite の フィールド数 によるパフォーマンス

対策:SQLite データベースのパフォーマンスの最適化 - Data Storage - 開発ガイド - BlackBerry Java SDK - 6.0 に、「行のサイズを最小限にする: 幅の広い列がある場合、個別のテーブルにすることを検討します。」 なんて改定あるので、実際のところ行サイズはどれぐらいパフォーマンスに影響するのか気になってきた。

せっかくなので、レコードのデータをすべてフィールドにしてしまった場合と、すべて別テーブルにしてしまっている場合と、どちらがよいパフォーマンスを示すのかについて、 RAM メモリ, SSD, HDD でそれぞれ読み書き速度を比較してみた。

あくまで、私の環境においてなので、参考ぐらいにしておいていただければ幸いだ。

検証コード

一応、以下の様な配置で、bundle 版 System.Data.SQLite.dll を配置していることが前提。

続きを読む

PowerShell で 配列をシャッフルする

コード

PowerShell で 極力簡単に配列をシャッフル (ランダムにソート) する方法。
速度や制度などはガン無視して、簡単に書けることを重視。

$shuffled = $array | sort -prop @{Exp={[Guid]::NewGuid()}}

ハイ終わり。

検証

ホントに実用的なシャッフルになっているか心配なので、実際に 0~19 のシャッフルを 2000 回行って、先頭に来た数字と、10 が来たインデックスを集計してみる。

$r = 0..1999
$r | %{ $r[$_] = 0..19 | sort -prop @{Exp={[Guid]::NewGuid()}}; }
$r | %{ $_[0] } | group | Format-Table -AutoSize
$r | %{ $_.IndexOf(10) } | group | Format-Table -AutoSize
Count Name Group
----- ---- -----
  104 16   {16, 16, 16, 16...}
   91 19   {19, 19, 19, 19...}
  111 8    {8, 8, 8, 8...}
  102 7    {7, 7, 7, 7...}
   95 18   {18, 18, 18, 18...}
  105 3    {3, 3, 3, 3...}
   95 12   {12, 12, 12, 12...}
   83 15   {15, 15, 15, 15...}
  100 17   {17, 17, 17, 17...}
   89 5    {5, 5, 5, 5...}
  103 13   {13, 13, 13, 13...}
  103 11   {11, 11, 11, 11...}
  101 10   {10, 10, 10, 10...}
  110 4    {4, 4, 4, 4...}
  100 6    {6, 6, 6, 6...}
   88 2    {2, 2, 2, 2...}
  123 9    {9, 9, 9, 9...}
   92 1    {1, 1, 1, 1...}
  107 0    {0, 0, 0, 0...}
   98 14   {14, 14, 14, 14...}

Count Name Group
----- ---- -----
  102 17   {17, 17, 17, 17...}
   93 15   {15, 15, 15, 15...}
  100 9    {9, 9, 9, 9...}
  109 18   {18, 18, 18, 18...}
   91 4    {4, 4, 4, 4...}
  104 5    {5, 5, 5, 5...}
  111 3    {3, 3, 3, 3...}
  107 7    {7, 7, 7, 7...}
   83 1    {1, 1, 1, 1...}
  106 10   {10, 10, 10, 10...}
  101 13   {13, 13, 13, 13...}
   93 8    {8, 8, 8, 8...}
  111 16   {16, 16, 16, 16...}
  101 0    {0, 0, 0, 0...}
   83 2    {2, 2, 2, 2...}
  104 14   {14, 14, 14, 14...}
  103 12   {12, 12, 12, 12...}
   98 11   {11, 11, 11, 11...}
   81 19   {19, 19, 19, 19...}
  119 6    {6, 6, 6, 6...}

だいたい 100 に収束しているし、問題ないんじゃない?

とはいえ、 Guid クラスは、一意性はある程度期待できると書かれているものの、ランダム性は特に言及されていない。
出現にパターンがある可能性もあるし、厳密にランダムである必要がある場合は、使わない方がいいかもしれない。

続きを読む

スクリプト言語などから、共有フォルダにある .NET アセンブリを完全信頼で読み込む

PowerShell や IronPython などで ネットワーク共有フォルダに置かれている .NET アセンブリを読み込むと、このアセンブリのパスが実行ファイルの起動パスと異なるため、部分信頼での実行となってしまい、ファイルの読み書きなどの多くのコードが実行できない。
参考: MSDN | イントラネット アプリケーションの完全信頼での実行

一旦バイナリファイルをメモリに読み込んでから、アセンブリとしてロードするなどと言う方法もあるが、アセンブリからの相対パスなどが利用できなくなったりと、若干使い勝手が悪くなってしまう。

その回避方法として、Vista 以降限定ながら、アセンブリのフォルダをローカルにシンボリックリンクを貼って、そのシンボリックリンクを経由してアセンブリにアクセスすれば、完全信頼として実行することができる。

例えば、複数の PC で同じスクリプトを実行する様な場合、バージョンアップするときに全部の PC をもれなく更新するなど環境をそろえるが面倒だ。
このようなとき、イントラネットの共有ディレクトリにスクリプト置いて、ローカルからシンボリックリンクを通して実行すれば、更新するときはネットワーク共有のスクリプトを書き換えるだけで済み、コードも完全信頼で実行されるので、なかなか便利になる。

サンプルコード

実際に nasne の共有ディレクトリに、ファイルの読み込みを行えるコードを持ったアセンブリを作成して、読み込んでみよう。

続きを読む