C6/C7ステートは無効にせよ

家にあるPCは、部品寄集めの所謂、自作機。Haswel Core i7 と Gigabyte製のM/B。

(4年前の画像が残ってた)

Windows7の時は特にこれといって不満はなかったんですが・・・Windows10にした頃から、なんだかフォルダウィンドウが開くの妙に遅く感じてた。開くだけでなく、ウィンドウの切り替えが全体的にもっさり。タスクバーに登録したフォルダのショートカットをクリックしてウィンドウが現れるのに最悪2秒くらいかかる。

会社で使っているPCは 第二世代のCore i5 なんですが、それよりも遅い・・・今までいろいろググってみたけど、分からず・・・。
でも、つい最近なんですが、動画エンコード中にフォルダウィンドウを開くと、普通に速く開くのにやっと気付く(遅ッ)・・・あれ? もしかしてCPUの省電力が無駄に働いてんのかな・・・。
早速ググると、どうやら デスクトップPCではM/Bの設定でC6/C7ステートは無効にする、っていうのは FAQ らしい・・・。今更・・・気付いても・・・もうじきリプレースしようしているのに・・・(笑)

再起動しDELキーでBIOS画面に入り、無効化したら、今までの不満はなんだったのか?というほど嘘みたいに普通になる・・・。ウィンドウ間の切り替えもフツーの速さに・・・。

ああ、自作機においてデフォルト設定はダメなのね・・・。やっぱり僕みたいなのは、大人しくメーカー製のPCの方がいいかもしれませんね。。。

この夏もグチで終わり。。。

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はグッとハードルが下がりましたよねぇ。。。

CentOS から Windows上のSQLServerへの道のり

副題: Road to SQLServer on Windows. (^^;

【追記 2019年3月12日】
CentOS7 と PHP7系については、こちらにまとめてます。
https://ptsv.jp/repository/rhel7-php71-sqlserver/


備忘録です。

今まで、CentOS6からSQLServerへのアクセスは、FreeTDS を使っていました。PHPからはPDO_DBLIB 経由。これは結構簡単にセットアップできました。yum で FreeTDSとか、もっと簡単に、php-sybaseなりphp-mssqlなり入れれば依存関係で必要なライブラリは勝手にインストールされますしね。設定自体も、/etc/freetds.conf と /etc/locales.conf とかいじればあとは、PDOからアクセスできます。

で、非常に疎かったので知らなかったんですが、Microsoftから Linux向けのSQLServer ODBCドライバが供給されている、とのこと。

今更何言ってんの??? って感じですが、知らなかったものはしょうがない。説明通りにやってみます(^^;

# curl https://packages.microsoft.com/config/rhel/6/prod.repo > /etc/yum.repos.d/mssql-release.repo
exit root

$ sudo ACCEPT_EULA=Y yum install msodbcsql
$ sudo ACCEPT_EULA=Y yum install mssql-tools
$ sudo yum install unixODBC-devel
$ sudo ln -sfn /opt/mssql-tools/bin/sqlcmd /usr/bin/sqlcmd
$ sudo ln -sfn /opt/mssql-tools/bin/bcp /usr/bin/bcp

エラーもなく、インストール完了。
ここまでは説明書通り。

さて、ここから設定。

/etc/odbcinst.ini を開くと、以下のセクションが追加されているはず。

[ODBC Driver 13 for SQL Server]
Description=Microsoft ODBC Driver 13 for SQL Server
Driver=/opt/microsoft/msodbcsql/lib64/libmsodbcsql-13.1.so.6.0
UsageCount=1

そして、/etc/odbc.ini を編集します。僕の環境ではodbc.ini は空のファイルでした。
データソースを記述していきます。

[Development]
Driver = ODBC Driver 13 for SQL Server #odbcinst.ini に追加されたセクション名
Description = for development databse #適当
Trace = Yes #わからん。 
Server = 10.1.1.1 #稼働中のSQLServerのIPアドレスもしくはホスト名 ファイヤーウォールでアクセス許可を出すこと。
Port = 1433 #SQLServer Configuration Manager で TCP/IP を有効に。
Database = Sample  #データベース名

この状態で、まず、isql コマンドで接続してみます。書式は、isql [データソース名] [ユーザー名] [パスワード]ですね。

$ isql Development dbuser dbpass
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+
SQL> select count(*) from hogehoge
+------------+
|            |
+------------+
| 5500       |
+------------+
SQLRowCount returns 0
1 rows fetched
SQL>

無事接続できました!

今度は、マイクロソフトが提供しているツールを使用してみましょう。

$ sqlcmd -S 10.1.1.1  -U dbuser
Password: xxxxxx
1> use Sample
2> go
データベース コンテキストが 'Sample' に変更されました。
1> select count(*) from hogehoge
2> go

-----------
       5500

(1 rows affected)
1>

接続できました。

次に、PHP で PDO_ODBC経由で接続してみます。
DSNには、odbc.ini で設定した、データソース名ではなく、ドライバ名・サーバー名・データベース名をそれぞれ直接指定してみました。

$ php -a
Interactive shell

php > $pdo = new PDO('odbc:Driver={ODBC Driver 13 for SQL Server};Server=10.1.1.1;Database=Sample','dbuser','dbpass');
php > $sth = $pdo->query('select count(*) from hogehoge');
php > echo $sth->fetchColumn();
5500
php >

接続できました。

日本語(UTF-8)が正常にCRUDできるか、まだテストしていませんが、とりあえずは、正常に接続できることを確認できたことでヨシとしましょう。

:continue 続きはこちら

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)