※2015年5月12日 追記
グーグル検索などでこの記事に辿りつくアクセスが多いのですが、この記事はもう最新のバージョンにはあてはまりません。ご注意を。OneDriveにおいてあるファイルを最新のバージョンには絶対適用してはいけません。おそらくWorkbench自体がエラーで立ち上がらなくなるでしょう。記録のためだけに置いてあります。あしからず、ご了承くださいm(__)m
追記ここまで。 続きを読む
Windows
MySQL for Excel
知らない間に、MySQL for Excel という素敵なツールがあるのに気づき(遅すぎ)、会社のPCにダウンロードしてインストールして、テストサーバー(CentOS6 / MySQL 5.1)に接続してみました。。。
家のパソコンにはエクセルなんて無用の長物なのでインストールしていないし、持ってもいない。
結果、撃沈。
Authentication with old password no longer suppored. Use 4.1+ style….
とかいう、エラーダイアログが出て止まる。んー、ユーザーの設定は全部phpMyAdmin経由で使用しているから、古いパスワードが埋め込まれてんのかな？と思い、sshで接続してmysqlコマンドで、下記確認。
select user,host,password from mysql.user;
新しいパスワードは、アスタリスク(*)から始まるけど、全部16文字の古い形式やった。。。どおりで通らんはず。
全部パスワードを設定しなおしたった。
これで、MySQL for Excel で無事に接続でけた。
テーブルのインポートから・・・
でもデータのインポートだけなら、Connector/ODBCをインストールしてODBC 経由で普通にできるやん！という無粋なことは言っちゃいけない。
でもって、テーブルのレコード追加・編集まで・・・使い慣れた表計算グリッドでデータをぶち込めたり、上書きできたり、という。素敵！
しかし・・・結局のところ、エクセル使いの方は、アクセスを使うと思うし・・・Windowsで飯を食ってる人はそもそもSQLServer使うし・・・、MySQL for Excelは誰が何のために使うのだろうか・・・？ そもそもMySQLを日常的に使用する開発者がわざわざExcelなんて使うだろうか？ ふつうはOpen Officeでそ？僕なんて、いまだにIBMのLotus Symphony 3だし。
ってわけで、HDDの肥やしになる。
コマンドバーにボタンを追加
Windows7のコマンドバーネタ(備忘録)です(^^ゞ
会社のPCがやっとXPからWindows7になりました。ええ、やっとです。XPのサポートが完全に終了したので、たぶん、仕方なくです(笑) どうせなら、Windows8.1にして欲しいものです。
さて、Windows8以降はエクスプローラシェルにもリボンUIが採用され、Vista/7のフォルダウィンドウの上部にくっついていたコマンドバーが消えてしまいました。Windows8以降のフォルダウィンドウはなかなか使い勝手よく、色んな設定をわざわざコントロールパネルを辿らずとも変更できるのですが・・・Windows7ではその辺使い勝手が悪いです。まぁ、見た目は圧倒的にWindows7の方が好きなのですが・・・。
あ、そうそう、フォルダウィンドウ内で、CTRLキーを押しながらマウスホイールを回すとアイコンサイズが変わるって知ってました？ おいら、今日初めて知った・・・。ちょー便利。
と、そんなことは、どーでもよく。。。
隠し属性のファイルの表示・非表示を簡単に切り替えるようにしたくて、コマンドバーにスクリプトを登録しました。
コマンドバーへのボタン追加は、3年ぐらい前にコマンドバーの記事を書いていたので、隠し属性のファイルの表示・非表示を行うスクリプトを書いて、レジストリに登録するだけ。
/*
隠しファイルの表示・非表示トグル スクリプト
ちょいと変更 at 2014/4/28
*/
(function()
{
var wShell = WScript.CreateObject("WScript.Shell")
try
{
var Key="HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced\\Hidden";
var Value = parseInt(wShell.RegRead(Key));
// レジストリ・キー(Key)の値(Value)が、1の時は非表示、2の時は表示なので入れ替え。
// ・・・逆だったっけ？ま、いいや。
wShell.RegWrite(Key,(Value & 1) + 1,"REG_DWORD");
//現在開いているフォルダウィンドウのコレクションを得る。
var sWindows = WScript.CreateObject("Shell.Application").Windows();
/*
現在開いているフォルダの数だけ、ループを回して更新する。
Itemメソッドで得られるオブジェクトはInternetExplorerオブジェクトなので、
Refresh()メソッドで表示を更新させる(F5キーを押すのと同じ)。
*/
var i = sWindows.Count - 1;
while(i >= 0)
sWindows.Item(i--).Refresh();
}
catch(e)
{
WScript.Echo(e);
}
})();
レジストリへの登録は「エクスプローラー(Windows7)のコマンドバーにボタンを追加する」をご参考に。
TortoiseSVN 1.8.0 でクライアント認証ができず・・・
Subversionが1.8にアップデートしたので、TortoiseSVN 1.8.0を何も考えずクライアントPCにインストールした。作業コピーに変更があったみたいで、作業コピーを片っ端からアップデートアップグレードした。
・・・結果、「TortoiseSVN 1.7.7でクライアント認証が失敗する」の二の舞を踏むことに・・・orz
インストールする時一抹の不安が過ぎったけど、後先考えず、「エイヤ！」ってな感じで。結局、やっぱり失敗。
一応サーバーはCentOS 5でApache 2.2.3 + オレオレ認証局のSSL環境。TortoiseSVN1.7.12を使っていたときはちゃんとクライアント認証のプロセスが通ったが、またしても1.8.0に上げたら今度は固まったまま。subversion自体がダメなのか、それともTortoiseSVNの部分がダメなのか、調べるだけの知識がないので、もうお手上げ。
検索してみたけど、やっぱりリリース直後なのでバージョン1.8の情報が出てこない。
結局、Apacheの設定で、SSLクライアント認証を解除して、ダイジェスト認証に切り替えることで、事なきを得た。
・・・が、Windows7上でTortoiseSVN1.8.0をインストールすると、ダイジェスト認証すらなんか怪しい挙動をする。作業コピーの更新をすると、ユーザー・パースワード入力ダイアログが出るのですが、正しいユーザー名・パスワードを入れてもエラーになる、あきらめてキャンセルすると、今度は違うダイアログ(Windows7の資格情報のダイアログ？)が出てくる。なんかワケ分からない。
ダメもとで何回もユーザー・パスワードの入力をトライしてみると、認証された。
よく分からん。
とにかく、元に戻そうかと・・・思ったけど、十数個ある作業コピーのチェックアウト作業がメンドクサイので、Apacheの設定をこのままにして、バージョンアップを待つことにする。
サーバーがオレオレSSLだからダメなのかなー・・・・とか、CentOS5のApacheのバージョンが低いのが原因なのかなー・・・とか思ったけど、確かめようがない。
この際だから、サーバー上のSubversionのバージョンを1.6系列から1.7系列最新の1.7.10にソースからビルドしてアップデートした。念のため、レポジトリのダンプをとったが、こちらは何ら問題なくバージョンアップ完了。さすがにサーバー上のsubversionを1.8.0にする気がしない。。。
Vista以降では安易にスレッドを作るな！？
■2021年8月3日
gistにコードを移すとき、コピペした時に文字化けしてたところとか io_completion_port_xp.cpp/io_completion_port_vista.cppを諸々修正
LinuxやBSDなどのUNIX互換のOSと違って、Windowsではスレッドを起こすのは普通に行われてることだと思います。で、スレッドを起こすには、CreateThread API もしくは、Cランタイムライブラリの_beginthreadex関数を使うことになります。
が、一方でスレッドを生成するのではなく、スレッドプールを利用する、というケースもあり、パフォーマンス的な事を考えれば、むしろこちらの方が多いかもしれません。
Windows 2000/XPなどのNT5.x系では、QueueUserWorkItem APIというスレッドプールに関するAPIが使えます。。。けど、はっきりいって、このAPI、よほど簡単なロジックでないと使えません。いったんこのAPIでキューに入れてしまうと、もう手が出ません。外からキャンセルできないし、強制終了させようとしてもTerminateThread APIは使っちゃだめ！ですし・・・。
結局、ちょっと凝ったことさせようと思ったら、自前でI/O完了ポートを駆使してスレッドプールを実装する他なかったと思います。
しかし、Windows Vista以降のNT6.x系のWindowsでは、より進化したスレッドプールAPIが追加されています。もはや、Vista以降のWindowsで、CreateThreadや_beginthreadex関数を使ってスレッドを起こすコーディングはダサイといわざる得ません(^^;;;
というか、CPUがデュアルコアは当たり前、マルチコアがデフォルトってな状況の中で、これからはメニーコアだ！ っていう時代なので、アプリケーション開発者側が、コア数のことまで考えて組む・・・とかもう無理！そんなのは限られたスーパープログラマーしかできんわ(笑) ってことです。
だから、CreateThread APIや_beginthreadex関数でスレッドを起こす前提のロジックでコーディングしちゃだめ。ってことに。
ただ・・・スレッドを作ってそこにウィンドウを作成する、というようなケースには向きません。とどのつまり、プロセス開始から終了まで生存するようなスレッドの場合、スレッドプールに処理を投げる意味はありません。あくまで、一つのスレッドの生成・削除が頻繁に行われるケースや、スレッドの生存期間が短いケース等でスレッドプールの恩恵を受けることができると思います。
ま、今更ですが(^^;;; この新たに追加されたスレッドプールなAPI群は、スレッドの生成と管理をすべてWindowsが肩代わりしてマシンに積まれているCPUの数(コア数？)と負荷状態に応じて最適な性能を発揮できるようになっているようです(・・・なっているはずです)。
例えば、ちょっとしたユーティリティアプリなんかで、単純な処理を非同期(並行)処理させる場合、TrySubmitThreadpoolCallbackもしくは、CreateThreadpoolWork/SubmitThreadpoolWorkでほとんど事足りると思います。
CreateThreadや_beginthreadexのあの引数の多さにうんざりすることが無くなり、スレッドハンドルを管理するコード、同期のためにイベントオブジェクトを作成して待機するようなコード諸々を実装する手間が大幅に軽減されます。ヒャッホーーー！
当然ですが、上記はXPでは実行できません。
他にも、タイマーオブジェクトを利用した関数の繰り返し処理、jscriptでいうところのsetTimeout / setIntervalメソッドみたいな、一定時間毎にコールバック関数を実行してくれるCreateThreadpoolTimer APIや、カーネルオブジェクトがシグナル状態になったらコールバック関数を実行してくれる CreateThreadpoolWait API、ReadFile/WriteFileなどのI/O非同期処理に利用できるCreateThreadpoolIo API。
一連のスレッドプールに関するAPIは非常に強力で、使い勝手もいい。デフォルトのスレッドプールの動作が気に入らなければ、カスタマイズしたスレッドプールを利用することもできる。
自分的に便利だと思ったのが、ReadFIle/WriteFileでI/O非同期処理に利用できる、CreateThreadpoolIo/StartThreadpoolIo。
今まではI/O完了ポートで通知を受け取って・・・というようなコードを書いてましたが、Vista以降のOSに限定すれば、これらのスレッドプールAPIを使うことでコード量が減ります。
ReadDirectoryChangesW APIを使ったディレクトリへの変更を監視するコードをスレッドプールを使ったコードに強引にリプレースしてみました。
まずは、昔作った、WindowsXPで動作する、IO完了ポートとワーカースレッドを単純に作って利用したバージョン。
要点は、スレッドを作成して監視が終了するまで待機。ReadDirectoryChangeW APIの非同期処理が完了するとIO完了ポートのキューにI/O完了パケットが追加され、ワーカースレッドのGetQueuedCompletionStatus APIが制御を戻すことでReadDirectoryChangeW APIの処理結果のデータを得て、再びReadDirectoryChangeW APIをコールし非同期処理を継続します。
続いて、上記をVista以降のスレッドプールのAPIを利用したバージョン。
あまり違いがないように思いますが、スレッドを何個作るべき？だとか細々とした調整などが不要になり、何より_beginthread関数などのプリミティブなAPIを使わなくても良くなりました。以前なら、スレッド処理をラップする、なんらかのクラスライブラリが必須だったと思いますが、ちょっとしたツールを書くときはこれらの新しいスレッドプールなAPIを使えば良くなりました。
ま、ちょっとしたツールを作るにはC#を使えば済む話で、わざわざC++を使う必要性があるとは思えませんが・・・。ま、要するに自己満です(^^;;;