一人情シスのつぶやき

名古屋の中小企業で一人情シスをしている作者が、日々の業務で思うことをつぶやきます。

Visual Studio CodeでMarkdownのPreviewカスタマイズ

Markdown

はまった。

Windows上のVisual Studio CodeでMarkdown Previewをcssでカスタマイズすることがどうしてもできない。指定した cssファイルがないと言われる。

cssを絶対パスでは指定できないことは認識しており、Markdownファイルと同じパスにcssを置き、setting.jsonでファイル名のみ指定してもダメ。各種記事を見てそのままやってみたつもりでもうまく行かない。 markdown-pdf.styles で指定してPDF出力する分には問題ないのだが。

結論としては、ファイルサーバにおいてあるファイルの場合はダメなよう。ネットワークドライブを設定してもダメ。 ローカルに持ってきたら普通に動作した... 半日無駄にした... なお、ファイルサーバに置いていると画像も表示されない。Visual Studio CodeのMarkdown編集はファイルサーバ上のファイルとは相性が悪いと認識した。

WPFのMVVMについて考える

最近、Windows FormをやめてWPFのプログラムを書き始めている。

WPFは正直必要となる知識レベルが高く難しいというイメージで手が付けにくかった。今もそうだが。 何が難しいかといえば、MVVMの考え方をどこまで徹底するかに尽きるのではないかと思う。

MVVMについてまだまだ分からないことも多いが、今の認識をまとめる。

  • MVVMは、ModelとViewの間にViewModelという層を挟み、ModelとViewの依存関係を疎にするモデル
  • WPFの場合、ViewとViewModelの間でデータを複雑なコード不要でやりとりするBindingという機構があるので、うまく記述すればViewとViewModelの間も疎にできる
  • そうすると、Model, ViewModelは変えずにViewだけ差し替えることも可能となる。
  • Windows Formの場合は、Viewの一部であるコードビハインドに処理もがっつり書いてしまうため、Viewだけ差し替えるということはできず結構な書き換えが必要となる。
  • Windows Formもそうだが、何も考えずに書くとどうしてもViewに処理を書いて肥大化しがち。そこで、ViewはViewModelの処理の呼び出しのみにする方が良いとされ、コードビハインドには極力コードを書かない方が良いとされる。
  • 逆にViewModel側もViewに依存してしまうと別のViewに差し替えることができなくなるので、Viewに関するコードは書かない方が良いとされる。
    • MessageBoxのようなダイアログや、別のWindowを直接起動する処理すら良くないとされる。
      • じゃあどうするんだというと、Blendと言う部品や直接呼び出さずにInterface経由とすることで直接依存を避ける手段を取るべきとされる。これが初心者には超絶難解だと思う。
  • 逆に、上記のようなViewを差し替える事態がそもそも考えなくて良いのであれば、今まで通りコードビハインドにコードを書いても問題はない。それでもWindows Formより洗練された部品が使えるのでメリットはある。

さしあたって、すぐに直面するのはViewModelからMessageBoxのような利用者への通知処理をどう行うか。行いたいのはMessageBoxを出すことではなく利用者にメッセージを伝えることと抽象化し、ShowMessageのようなメソッドをもつInterfaceを定義してこれを利用する形とする方法をとっている。以下のページが参考になった。

sourcechord.hatenablog.com

このパターンは、コンストラクタに引き渡す処理に気をつければViewModelからのViewの呼び出しが簡単にできるため、よく使っています。

ClosedXMLによるExcel編集がVirusBusterに強制終了させられる

C# ClosedXML

ClosedXMLで、ファイルサーバの雛形ファイルをもとに編集して出力するということをよく行います。 この際、ClosedXMLの保存先がファイルサーバだと、当社のVirus Buster Business SecurityにUnauthorized Encryptionと言われて 強制終了させられることがあります。Excelファイルは作成できず、exeも消されてしまうので再インストールとなります。

テストした結果、ClosedXMLでの保存先がローカルであれば問題ないことが確認できたので、ClosedXMLではローカルに一時フォルダを作成してそこに保存し、System.IO.File.Copyでコピーすることで解消しました。

うっかりmasterリポジトリでcommit

Git

git管理していて、ローカルリポジトリでブランチ切り忘れてmasterブランチで作業、ローカルcommitまでして気付いた。 このままpushしても、当然リモートのmasterブランチにダイレクトにpushはできず、弾かれる。 PRも出せない、と思っていたが。

pushでは、ローカルとリモートの両方のブランチを指定できる。

git push origin <local_branch>:<remote_branch>

local_branchにmaster, remote_branchに本来切ろうと思っていたブランチ名を指定し、そのブランチでPRを出す。

ClosedXMLでWindows7だけレイアウトが崩れる

アホな話です。

ClosedXMLで、一部コードでうっかり以下のようなコード書いてました。

            using (IXLWorkbook targetBook = new XLWorkbook(filePath))
            {
                using (IXLWorksheet targetSheet = targetBook.Worksheet(1))
                {

                }

                targetBook.Save();
            }

usingの入れ子です。 普通、入れ子になるような階層があれば一番上位のクラスが下位のDispose呼んでくれるっと思いますよね〜。 でも、このときはusing句覚えたてで、とにかく使いたかったんです、using入れ子かっけ〜って思ってたんです...

症状としては、Windows 7の場合のみシートのフォーマットが崩れます。なぜかWindows 10は大丈夫。OSによって症状が違う理由は不明。 sourceを見ると、XLWorksheetのDisposeでrange情報をクリアしてるっぽいから、そこで情報が消えて、そのまま保存すればそりゃレイアウトは崩れるな〜と。

追記) どうも、最新の0.93.1で発生し、0.92.0では発生しなかったようだ。ライブラリのバージョンアップした途端に大量に問い合わせが...

今日のクソVBAコード 

stDocName = ChrW(xx) & ChrW(yy) & ChrW(zz) & ChrW(abc) & ChrW(def) & ChrW(ghi) & ChrW(jkl) & ChrW(mno) & ChrW(pqr) & ChrW(stu)
DoCmd.OpenReport stDocName, acPreview

ChrWの引数は実際にはコードが入る。 式の右辺をイミディエイトウィンドウに入力すると、日本語のレポート名が表示される...

暗号化?なんのために? あとで見る人への嫌がらせか? ちょっと意味がわからない

CIの導入について検討

一人で開発していても、テストやデプロイにミスが出る可能性はある。 CIの導入を検討した。

結論としては、CI用途のサーバーを別途導入することはしない。現在主に開発しているC#プロジェクトでは、CIにもWindowsが必要となる。ライセンス費用が必要だし、Dockerでお手軽に再構築できる環境としたいため。

やりたいことは以下の通り

  • リポジトリのPRコードのビルド
  • テスト、結果通知、OKならmerge
  • DBの構成情報に関して、リポジトリと実環境で差異がないかチェック

1,2点目はWindowsを避ける以上、不可能。開発時に自端末でテストを行い、PRのコメントに記載する運用で対応。 3点目は、毎日定時に実行する普通のバッチでなんとかなるレベル。

テストに関して、DBに関連するところは一切やっていない。面倒なので。 一方で内製アプリの殆どはDBのデータを持ってきてそのまま表示し、加工して更新する程度のものがほとんどのため、結果ほとんどテストがない状態。 本番環境に接続する際には専用のクラスを利用しているので、テスト環境用にも同様のクラスを作成し、テスト実行時にはそちらを利用してDB接続するようにしてテストを行うようにする。まずこちらが優先。

Dockerでdumpファイルから空のデータベースを作成するDockerfileを作成し、開発にすぐに利用できるようにする。

その上で、上記の運用で品質をさらに高めていく。