LeetCode 01: Two Sum

 長い間ウワサは聞いておりますが、初めて触りました。リートコード(LeetCode)という中国発のネットジャージシステム。一応自分が登録したのはアメリカサーバですけどね。

多分アルゴリズム上ではそこまで最適化していませんが、一応コードを記録しておくことに：

public class Solution {
    public int[] TwoSum(int[] nums, int target) {
            int index1=0;
            int index2=1;

            int maxindex = nums.Length;

            while (true)
            {
                int solution = nums[index1] + nums[index2];
                if (solution == target)
                {
                    int[] result = new int[] { index1, index2 };
                    return result;
                }

                index2++;

                if(index2 >= maxindex)
                {
                    index1++;
                    index2 = index1 + 1;
                }
            }
    }
}
            

在多個專案中同時設定依賴專案版本

如果你像我在做Blazor的披薩工作坊時，執行build卻發生像下面的錯誤:

warning NU1604: Project dependency 'PackageA' (<= 9.0.0) does not contain an inclusive lower bound. Include a lower bound in the dependency version to ensure consistent restore results.

很好，第一步你找對地方了。這是一個msbuild的問題，也是這個工作坊內容的一個小問題。

這個專案中牽扯到了nuget包裝版本問題。而通常我們在github等上傳資料時，並不會包含nuget引用的封包(可以自己抓的就不要浪費網路流量啦)。

基本上專案用的方法並沒有錯，他只是少傳了一個檔案。在這個檔案中，我們可以將多個proj所需的最低版本放到同一個檔案中集中管理，這樣升級的時候就不需要一個一個去打開專案檔修改參考版本。

你所需要做的動作如下:

1. 在Solution檔案夾下放一個共通的檔案。如果你像我常常使用VSCode，那就是把檔案放在sln檔的同一個目錄中。在標準設定中，他會被叫做Directory.Build.props

2. 修改檔案內容，改成像下面這樣:

<Project>
    <PropertyGroup Label="Package Dependencies">
        <AspNetCoreVersion>5.0</AspNetCoreVersion>
        <EntityFrameworkVersion>5.0</EntityFrameworkVersion>
        <BlazorVersion>5.0</BlazorVersion>
        <SystemNetHttpJsonVersion>5.0</SystemNetHttpJsonVersion>    
    </PropertyGroup>
</Project>

3. 如果你是用dotnet cli或是Visual Studio，恭喜你，你已經可以正常build了。
如果你不是使用標準build。那你就繼續做下一步。

4. 打開你的各個專案檔(就是那些csproj檔)。在<Project>的最上層添加下面這行

<import Project="..\Directory.Build.props" />

5. 結束。這樣應該又恢復正常了。未來有升級的時候，自己進去修改所需最低nuget的版本，看是要改成6.0還是什麼的，就看大家造詣了。

ref: https://github.com/dotnet-presentations/blazor-workshop

keyword: asp.net, dependencies.props, Directory.Build.props, .net core

DataGridCheckBoxColumn動作模式變更

參考: http://tawamuredays.blog.fc2.com/blog-entry-265.html

DataGridCheckBoxColumn裡的CheckBox，在預設狀態下，必須先點一次，Row取得focurs之後才能改變狀態。使用上不是很直覺，跟一般的CheckBox不太一樣。

背後的原因是因為DataGridCell本身有分成顯示用的ElementStyle跟編輯用的EditElementStyle兩種模式，為了做出區分，犧牲了CheckBox的直覺性。

可以依靠設定Style的方法，使操作更為直覺。

修改方式如下:

在各自的Style設定中(可以放在上位DataGrid的DataGrid.Resource裡)，加入以下程式碼

<Style TargetType="CheckBox" x:Key="CheckBoxCellStyle" />

或是

<Style TargetType="CheckBox" x:Key="CellCheckBoxStyle"
       BasedOn="{StaticResource {x:Type CheckBox}}" />

然後就可以在DataGridCheckBoxColumn上設定我們所需的ElementStyle

<DataGridCheckBoxColumn Binding="{Binding Selected}"
                        ElementStyle="{StaticResource CheckBoxCellStyle}" />

做完以上的設定，指定的DataGridCheckBoxColumn裡面的CheckBox就會是我們常用的單點就會有反應的CheckBox了。

以上。

SQL 改行コードの処理

SQL中に、改行コードはCHAR(13)あるいはCHAR(13)+CHAR(10)が該当します。 

それらを用いて保存すると、CSV出力やExcelにコピーする際にちょっと厄介です。

次のコードで、一括それら改行コードを削除できます。

UPDATE [TableName] SET [FieldName] = REPLACE([FieldName], CHAR(13) + CHAR(10), '') WHERE [FieldName] LIKE '%' + CHAR(13) + CHAR(10) + '%';

UPDATE [TableName] SET [FieldName] = REPLACE([FieldName], CHAR(13), '') WHERE [FieldName] LIKE '%' + CHAR(13) + '%';

PrismでDIコンテナを使用するRegister vs RegisterInstance vs RegisterSingleton

Prism 7以降に、サービスを注入する際に、Register, RegisterSingleton, RegisterInstance三つのメソッドが使えます。それぞれを使用する場面について、ちょっとした解説を書き残します。

実際にサービスを登録する場合、そのサービスを使用する場面によって、異なるサービスを使用するべきと言われていますが、次のように大まかに分けています：

• Register 該当Interfaceが注入された場合、DIコンテナが自動的に新しいインスタンスを生成し、終わったときにインスタンスを廃棄する。
• RegisterSingleton 全部の注入には同じインスタンスで対応する。
• RegisterInstance 主にRegisterSingletonと同じだが、生成されるInstanceは自分で管理する場合使用。

では、どれを使うほうか正解ですか？

まぁ、ほとんどなサービスはSingletonとして登録されます。ViewModelはそれらのサービスによって通信できるようにするためです。例えば、EventAggregatorサービスで、あなたが持つあるViewModelからEventを発行する際に、他の何かはそのことを知らせたいですが、それは同じインスタンスのサブスクリプションを発行者サービスとして登録している場合受け取ることができます。とはいえ、WCFクライアントは、同じシングルトンを使用する必要はありません。なぜならば、その処理はサーバー側が処理すべきなのです。

場合によっては、インスタンスを登録することは嫌がります。特に登録(register)と逆解析(resolve)が混在している場合。インスタンスを作成する際にそのインスタンスの依頼先をすべて確保する場合も。（だからResolveを呼び出す。その呼び出す自体がやや気に障るが。）

ひとつのメソッドですべての必要項目を全部登録してしまえば問題は減りますが、複数の交互依頼モジュールがある場合にはちょっと頭痛いです。

訳者注記

最近のプロジェクトでDBのアクセスサービスに、Singletonの登録にはちょっと問題あると気付きました。EntityFrameworkのDbContextを利用していますが、すべての画面が同じDbContextを登録した場合、DB側に更新がある場合、リアルタイムにReloadができません。渋々にSingletonを解除して、画面ごとに新しいDbContextを使うことにしたら、キレイに解決しました。ネットで検索したら、DbContextは長時間メモリに滞在するようには良い影響はしないようです。とりあえずEntityFrameworkのDbContextはSingleton登録しないようにする方が良いです。あるいは必要の場合自分でインスタンスを管理する方が良いかもしれません。