以前、.NET Interactive の C# REPL を Jupyter で などで紹介していた、 .NET Interactive が、 Visual Studio Code (VS Code) の Stable 版で使えるようになっていた。
まぁ、昨年 9月 の .NET Interactive Preview 3: VS Code Insiders and .NET Polyglot Notebooks | .NET Blog の時点で、 VS Code の Insiders ビルドでは使えていたのだが、 最近晴れて Stable 版の VS Code でも動作するようになったようだ。
……まぁ、 .NET Interactive Notebooks 拡張機能自体は、まだ Preview リリースではあるのだけれど。
この記事は、「C# Advent Calendar 2020」 9日目の記事、かつ 「PowerShell Advent Calendar 2020」 9日目の記事だ。
スミマセン。横着した。
この時期になれば .NET Interactive の Preview 4 が出てるだろうしその記事でも書こうかな～ などと目論んでいたものの、 残念ながら登場しなかった。
このため、 .NET Interactive .NET 5 対応版の導入と、 Variable sharing の内容でお茶を濁そうと思う。
.NET Interactive のなんたるかについては、以前の以下の記事で取り扱っているので、そちらを参照願いたい。
いきなり本題とは関係ない話になるが、 せっかく .NET 5 がリリースされたところなので、 .NET Interactive を .NET 5 で動かしてみよう。
今回は、 .NET Interactive を利用し、ローカルマシンで C# や PowerShell Core の REPL を利用するまでをまとめる。
なお、 とりあえず動かしてみたいだけであれば、 
バッジのリンクをクリックして、 オンライン上の Binder にブラウザにアクセスするだけで、利用することができる。
→ Use Jupyter with .NET Interactive on Binder
.NET Interactive は、 以前 Try.NET と言う名前で提供されていた、 .NET のインタラクティブな機能を提供する API スイートだ。
JupyterLab に .NET カーネルを追加する形で、 REPL の実行やノートブックの作成する仕組みを提供することが、 主なユースケースとなっている。
REPL ではコード補完も効くので、非常に便利なものになっている。
まず、 Jupyter についても軽く説明しておく。
既にご存じなら読み飛ばして欲しい。
本記事は、 CUI のコンソール画面から使用する中級者向けのツールのに関する内容だ。
別途、 簡単に使用できる GUI 版も作成したので、そちらについては、以下の記事も参照。
突然だが、自動車税や固定資産税などの税金や、公共料金などの払込票などを、どのように支払っているだろうか？
支払う額も大きくなりがちなので、なるべくお得に支払いたいのではないだろうか。
そこでオススメなのが nanaco ギフト だ。
クレジットカードで直接納税したり nanaco 残高にチャージする場合、手数料がかかったり、ポイントがたまらなかったりと、あまりお得にならない。
しかし nanaco ギフトであれば、額面よりも安く入手する手段が知られている。
|
また nanaco 残高と違ってセンターお預かりへのチャージなので、 チャージ残高の上限が非常に高く (50万円以上も可能らしい)、 nanaco 残高のチャージ上限である 5万円を超えるような金額の支払いでも使える大きなメリットがある。
nanaco ギフトでのお得な納税の話は、他のサイトでもっと詳しくわかりやすく書かれているだろうから、これくらいにしておく。
さて、 ここからが本題だ。
そんな nanaco ギフトにもひとつ 大きな欠点がある。
それは、 1,000 円単位で提供されることが多い ということだ。
例えば 10万円分 チャージしようとすると、 100 回も nanaco ギフトID のコードを入力しなくてはならないのだ。
更に、 nanaco ギフトの登録を行う UI が、大量のギフト登録に とても優しくない。
1回 コードを入力する毎に nanaco にログインしたり、 コードを 4文字 ずつテキストボックスに入力しなくてはならなかったりと、 数をこなすのにとにかく手間がかかるのだ。
10万円 の納税で 2,000円 得するために、 2,000円分 相当以上の手間をかけるのでは愚の骨頂だ。
こうなったら、自動入力させるしかない。
ネットワークドライブ上の 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 毎に ファイルの読み込みと、 ハッシュストリームへの書き込みを 同期的に 行っている。
ファイルの読み込みも、 (使うアルゴリズムにもよるけど) ハッシュの計算も、 どちらもコストがかかるので、同期的にやってたらそりゃ遅いわ。
しばやん御大の Entity Framework Core についての以下の記事を読んで、
データベースは、扱いが簡単な SQLite にする。
記事の最後に、 Visual Studio 2015 ですぐに使えるサンプルプロジェクトを用意しているので、 手っ取り早く結果を見たければ、 そのサンプルプロジェクトを見てみてほしい。
まずは、何を実現させるのかをハッキリさせておこう。
ここで言う EF Tools とは、Entity Framework Core の コマンドラインツール のことだ。
このツールを使うと、 パッケージマネージャーコンソールから Add-Migration とか Update-Database と実行したり、 dotnet.exe から dotnet ef コマンドを 実行することで、 コード生成やマイグレーションなど を利用することができる。
EF Tools でデータベースを取り扱う際、その接続文字列は DbContext に設定されたものが使用される。
コード内に接続文字列を書いてしまうと、マイグレーションするためのデータベースファイルが決め打ちになってしまい、変更ができなくなる。
このため、 EF Tools を実行した際も、依存性の注入が行えるようにしたい。
.NET で 単体テストと言えば、いまや xUnit.net が事実上の標準となっている。
ASP.NET Core や .NET Core のドキュメントでも、単体テストは xUnit.net を使うように案内されている。
ところが Visual Studio の Express Edition 系列 の テストエクスプローラは、 xUnit.net に対応していない。
それでも Full .NET Framework や dnx では、そのままテストプロジェクトを「実行」してしまえば、とりあえずデバッグ実行はできていた。
しかし、 .NET Core + dotnet-test-xunit では、それすらもできなくなってしまい、 dotnet test コマンドの出力を確認するしかなくなってしまった。
デバッグ実行ができないのは流石に不便… ということで、デバッグ実行を行うハックを紹介しよう。
# ライセンス的に Visual Studio Community 使えるのなら、そちらを使うべき。
# ただ、たとえ Express ではなくても、 この方法を使うと xUnit.net の出力が文字化けする問題も防げるぞ。
だいぶ予定が遅れたようだが、 .NET Core 1.0 の RC2 が5月中旬にリリースされた。
2000年に初めて .NET がリリースされてから、 mono が登場したりといったことはあったものの、 16年越しでついに クロスプラットフォームのアプリケーションを作成できる環境が、マイクロソフト公式から提供された。
ということで、さっそく .NET から VS2015 DotNetCore Tools Preview 1 をインストールして、 Hello World を書いてみよう。
using System;
using System.Text;
namespace netcore_console_test_01 {
public class Program {
public static void Main(string[] args) {
Console.WriteLine("はろー わ～るど！");
}
}
}
…文字化けするぞ!!?