Programing…

WebClient派生クラスでのクッキー読み書きについて

Tweet image download agent で、致命的なエラーを放置してた件。
もともとファボったツイートの画像だけを自動ダウンロードするために書いたコード。最近はもともとの動機となった機能はほとんど使わず、ツイッター内で検索した画像を自動ダウンロードするために使っていたので、いつの間にかログインできない状態になっていて、それにも気づかず・・・。コメントで報告してもらって初めて気づいたという、お粗末さ(^^;;;

それはともかく、原因は、ログイン後のクッキーの取り扱い。それが雑だったという、二重のお粗末さ・・・。C#使いとしては失格ですえ。

何が原因なのか、VisualStudio2015のIDEでとりあえず、該当箇所をステップ実行してデバッグしてたら、HttpWebResponse.Cookies に セッションクッキーしかストアされていないことに、まず気付いた。要するに、サーバーから返されたレスポンスヘッダ Set-Cookie の Expires が設定されていないものだけが HttpWebResponse.Cookiesにストアされている・・・。

どゆこと？

いくら実行しても、セッションクッキーしか保存されない・・・。これじゃログインが成功してたとしても、だめだわ・・・。
ChromeのDevToolsでTwitterサイトへのログインのレスポンスヘッダーを眺めてたら、あれ？ もしかして、Expires に記述されている日付書式のパースに失敗してんのかな？？？と、グーグル先生に聞いてみると、.NETのSet-Cookieヘッダのパーサーはバカだよ（超意訳）、みたいな投稿が StackOverflowに出てた。

ってなわけで、WebClient.GetWebResponseをオーバーライドして、

WebResponse.Headers[“Set-Cookie”] から自前でクッキーをパースして、CookieContainer.Add しちゃいなよ！

っていうアドバイスに従い、テキトーにパースして Add しちゃう、しちゃう。

でもなー、前はちゃんと動いてたのに・・・。やっぱり、Twitter が吐く Set-Cookieヘッダが変わったぐらいしか、原因が分からないすッ。

探せばもっとマトモなコードがあると思われるので後で探そう・・・とりあえず↓でヨシとする。（要点のみ）
※ すべてのコードは、https://osdn.jp/users/earlgreyx/pf/TwitterImageDownloadAgent/wiki/FrontPage。

シェルスクリプト右往左往

Bash on Ubuntu on Windows(以下BoWと略す)の環境下で作成したシェルスクリプト(ほとんどがImageMagickとffmpeg関連)がある程度貯まってきたので、CentOS側にコピーして動かしてみたら、エラーが出まくって動かなくなった・・・トホホ。

原因のほとんどが、basenameでのエラー。BoWは Ubuntuで、coreutilsのバージョンは 8.25。CentOS 6に標準で載ってる coreutilsのバージョンは、8.4・・・7年前にリリースされたもの・・・。

ってなわけで、 `basename -s <suffix> <filepath>` となっているところを片っ端から `basename <filepath> <suffix>` に変換してようやく動く。

今までシェルスクリプトは、「なんか覚えるのメンドーだなー」とか、「Perlで組めば大抵代用できるしなー」とか思ってて、あえて避けてきたんだけど、やっぱり画像の一括リサイズとか、画像への文字合成処理とかの単純作業は、Photoshopのアクション＆バッチ処理をするより、圧倒的に手間が少なく、ラクできる。 特定ディレクトリ下に無秩序に掘られたサブディレクトリに格納された画像1000枚以上にシリアル番号入れて一括リサイズなんてPhotoshopでやってらんねーーーーし！

とりあえず、if-elif-else、case、while、for、などの基本制御式さえ押さえれば、あとは manページ参照しながらやってると、よく使う find コマンドとか、imagemagickなどのオプションなんて自然とソラで書けるようになってくるのがアラ不思議(^^

google検索のおかげで、CLIはグッとハードルが下がりましたよねぇ。。。

Console.ReadLine(bool intercept ) が欲しい！

と、思いませんか？ うまいもんはうまい。by はや

コンソールなプログラムを C# で組んでいると、パスワードなど見せてはいけないものを入力するケースって意外にありますよね。そういうとき、Linuxとかだと、シェルスクリプトで stty でファイトー、一発！！ってなもんですが、かなしきかな、C#（というより、.Net Frameworkのクラスライブラリ）には、適当なものがありませぬ。

クラスライブラリの広大な海から、やっとこさ、System.Console.ReadKey(bool)というものを見つけました。が、やっぱりその辺は自作しないといけないようで・・・。Console.ReadKey(bool)ってのがあるんだから、Console.ReadLine(bool)くらい作っておいて欲しい・・・そこまで頼るな！って？

どうでもいいけど、拡張メソッドの静的バージョンって欲しいよう(^^;;; Consoleクラスに自作静的メソッドをバカバカ追加して自己満に浸りたい・・・。

愚痴はさておき・・・忘れないようにコード・メモです

追記：バグ修正 (2017/05/17)

開発環境の見直し。

「Byte range lock とは何ぞや？？？」

結論から言うと、その方面に詳しくないので全然わからない。検索結果を拾い読みしていくと、ファイル全体をロックするのではなく、バイト単位で範囲を指定してロックする、というものらしい。

事の始まりは、開発環境を一新したことがきっかけだった。

長年 Windowsユーザーである私は、Win32版のApache/MySQL/Perl,PHP（俗にいうWAMP環境）をセットアップして使ってきた。しかし、これらサーバー類のWindows版とLinuxなどのUNIX互換OS上のそれらとの挙動の違いなどが最近非常に気になり出しはじめ、その違いを吸収するようなコードをアプリケーションに組み込む量が多くなってきた。本来なら必要のないコード。

で、ApacheやMySQLなどのWindows版を使うのをやめ、Hyper-Vの仮想マシン(内部仮想スイッチ＋WinNATで外に出るよう構築)にサーバー類を移すことにした。幸いここ数年 CentOSをいじるようになってきたのでLinuxサーバーの構築は慣れているので開発環境の移行は結構すんなりできた。

仮想化ソフトは色々あるんですが・・・まぁある程度のスペックのPCとWindows8.1以降なら迷わずWindowsに標準でついてくるHyper-V がベストだと思います。

仮想マシンを立ち上げるには、 Powershell(要権限昇格) を使うとスマート。GUIなHyperVマネージャは仮想マシン作るときだけでいいかなと。

仮想マシンの列挙
>> Get-VM

起動とシャットダウンは・・・
>> Start-VM -Name CentOS7
>> Stop-VM -Name CentOS7

コンソールにアクセスしたければ、vmconnectを実行
>> vmconnect localhost CentOS7 

もし仮想マシンがWindowsなら、リモートデスクトップで立ち上げとか。
>> mstsc /v:仮想マシンのIPアドレス

しかし、ファイルの編集などは使い慣れた Windows上のエディタ環境を使いたいしソース管理もTortoiseSVNで引き続き行いたいので、仮想マシン上に cifs-utilsをyumでインストール。Windows上のDドライブをまるごと共有し、Linux側から マウントさせ、そのディレクトリをhttpd.confで適切なURLにマッピングしてやれることでWindows上でファイルを編集しつつ、そのコードは仮想マシン上のLAMPで動くという、理想的な環境のできあがり。
図にすると、下記のような感じ。

実際に、構築して使ってみると、これが快適すぎて、もっと早くにしとけばよかった。仮想マシンをエクスポートしてバックアップしとけばPC買い替えたときもラク。

はじめ仮想スイッチを内部専用にしたせいで仮想マシン側からホスト外にアクセスできず困ってたんですが・・・PowerShellの下記コマンドでNATを設置？することで解決。

PS>> New-NetNat -Name VMNatNetwork -InternalIPInterfaceAddressPrefix 10.0.0.0/24

確認には、
PS >> Get-NetNat | fl *
Store                            : Local
TcpFilteringBehavior             : AddressDependentFiltering
UdpFilteringBehavior             : AddressDependentFiltering
UdpInboundRefresh                : False
Active                           : True
Caption                          :
Description                      :
ElementName                      :
InstanceID                       : VMNatNetwork;0
ExternalIPInterfaceAddressPrefix :
IcmpQueryTimeout                 : 30
InternalIPInterfaceAddressPrefix : 10.0.0.0/24
InternalRoutingDomainId          : {00000000-0000-0000-0000-000000000000}
Name                             : VMNatNetwork
TcpEstablishedConnectionTimeout  : 1800
TcpTransientConnectionTimeout    : 120
UdpIdleSessionTimeout            : 120
PSComputerName                   :
CimClass                         : root/StandardCimv2:MSFT_NetNat
CimInstanceProperties            : {Caption, Description, ElementName, InstanceID...}
CimSystemProperties              : Microsoft.Management.Infrastructure.CimSystemProperties

しかし、問題が一つ。Windows側に置いておいた SQLiteのデータベースファイルに読むことはできても、変更(書き込み)することが一切できなくなっていた。どうやら仮想マシン上のPHP等から CIFS経由で変更しようとすると、ロックされてタイムアウトしてしまう事象が発生。

いろいろ調べた結果、どうやら 仮想マシンのCentOSからCIFS でホスト上の共有フォルダをマウントする際に、Byte range lock を無効しないとロックされてアクセスできないよー的な記事(ほとんど英語だらけの外国の方の記事ばっかりヒットする)を見つけ、下記のように /etc/fstab に記述すると解決できた。

/etc/fstab  -----

//10.0.0.1/Devel  /mnt/devel cifs user=nakagawa,password=xxxxxx,uid=nakagawa,gid=admin,nobrl,defaults  0 0

ポイントは、nobrl というオプション。これをつけるとバイト範囲のロックを無効にする・・・らしい。が、意味は分からんが、とりあえず、SQLiteファイルの変更中(書込み処理)ロックされることはなくなった。

めでたし、めでたし。

※追記）
Windows API の LockFile/LockFileEx とか、Linuxとかだとfcntl とか？ で CIFSマウントされたディレクトリ内のファイルの「byte range lock」に対応していないってことなのかな・・・う～む？

フォーム間の依存関係を最小限に

C#備忘ログ

C#でWindowsフォームを使うようなアプリケーションは殆ど書かないのであまり興味もなかったのですが、今回2つのフォームを使うツールを書いたときに困ったことがあった。

フォームＡ(class FormA : Form) ／ フォームB(class FormB : Form) の2つがあって、

1)フォームＡ内に配置したボタン(Button1)をクリックすると、フォームBを生成すると同時にフォームAは非表示へ。
2)フォームBを閉じると、フォームAを表示する。

通常ならたぶん、フォームAの button1の Clickイベントハンドラに フォームBをnewして Show()メソッドをコール。

//子フォームを生成して表示、自身は非表示にする
private void Button1_Click(object sender, EventArgs e)
{
  this.Hide();
  var formB = new FormB();
  formB.Show(this);
}

そしてフォームBを閉じたり、非表示になった時のイベントハンドラ(FormB_FormClosingとかFormB_VisibleChangeとか)でFormAのShow()メソッドをコール。

//親フォームを表示(復帰)
private void Form1_FormClosing(Object sender, FormClosingEventArgs e)
{
  this.Owner.Show();
}

のような感じになると思うんですが、フォームBを閉じたときに、フォームAを表示するだけじゃなくて、フォームA上のbutton1のTextプロパティの表示も変えたい！とか、button1のEnabledプロパティーを・・・とか、にしたいとき、FormA側にpublicなメソッドを一個追加してコールさせなければならない・・・。

つまり、フォームAの勝手な都合で、全然関係のないフォームBのソースも修正しなければならなくなる。フォームA,フォームBそれぞれがお互いのインスタンスを共有しなければならない、という非常に非効率な状態になる。２つのフォームだけならまだなんとかなるけど、フォーム10個とかになったときの事を考えると恐ろしい。。。

この場合の解決方法はやはり・・・フォームA側から直接フォームBのイベントに+= 演算子でラムダ式を注入するのが一番いい。Showメソッドで自分自身のインスタンスを渡す必要もない。フォームBのソースを汚染することもなくなる。

ま、ちゃんとメソッドを定義して・・・いう書き方の方がいいのか、インラインでラムダ式を放り込む方がいいのか、書き手側の好みの問題でしょうか。

//FormA
private void Button1_Click(object sender, EventArgs e)
{
  this.Hide();
  var formB = new FormB();
  formB.Show();

  //ラムダ式を注入
  formB.FormClosing += ( bs, be ) => {  Show(); button1.Text = "フォームBは閉じられた！";  };
  //デリゲートを追加
  formB.FormClosing += formBClosed; 
}
private void formBClosed(object sender, FormClosedEventArgs e)
{
    Show();
    button1.Text = "フォームBは閉じられた！";
}

また、FormBの子コントロールの特定のイベントにイベントハンドラを注入したければ、子コントロールにもフォームＡ側からイベントハンドラを注入してあげればいいが、フォームの子コントロールのアクセスレベルは private なので、単純に子コントロールへはアクセスできない。
そういうときは、フォームBのControlsプロパティから目的の子コントロールを得られる。

//FormA 
private void Button1_Click(object sender, EventArgs e)
{
  this.Hide();
  var formB = new FormB();
  formB.FormClosing += ( bs, be ) => {  Show();  };
  formB.Show();
  var ctrl = formB.Controls["button2"]);
  ctrl.Click += (bs,be) => button1.Text = "クリックされたよ";
}
//エラー処理はしていないよ

メインフォーム ⇔ 子フォーム間の依存関係はできるだけ避けたいし、子フォーム間同士の依存関係もできるだけ避けたい。お互いのフォームがお互いのインスタンス(正確にはインスタンスへの参照)を持ってコードを書くとフォームが増えるに従って グチャグチャになってしまう気がする。。。
気をつけよう。