削除した方がいいかなあ。
Excel で
worksheet['Cells', 1,1] = 10
は、OKで
worksheet['Cells', 1,1]
がエラーになるのは、バグだと判断した。
それでも、誰も文句を言わなかった(過去に文句を言われたという認識が私にはない)ということは、 [] は本当に使われていないのかも知れない。
普通は
worksheet.cells(1,1).value = 10
や
worksheet.cells(1,1).value
と書くよな。
とりあえず、それっぽく動いているので、1.9にコミットしてみました。
今までできたことができなくなるのは嫌なので、そうなっていた場合、元に戻すかも知れません。 そんなことを考えてしまうということは、この変更は良くないのかも知れません...。
まだ、1章を読んだだけですが、興味深いというか面白いというか。 C++ から COMへと発展していく解説は、良質のミステリの謎解きを読んでいるかのようだ。 そして、C++ をすっかり忘れている自分に気づかされたりするのだった。
[] と []= はやっぱりあまり使われてないみたいですね。 自分でも、どうして [] や []= が必要なのか考えれば考えるほどわからなくなってしまいました。 結局、必要ないんじゃないかと考え始め、 逆にどうしてこんなものを作っちゃったんだろうと悩み始めました。 多分、深く考えずに、実装も仕様もPerlに合わせて作ったからではないかという結論になりました。
[ruby-talk:185857]は興味深いです。 良いヒントをもらったような気がします。 もう少し考えてみたいと思います。 []の中身がSymbolだったらプロパティとして特別扱いするというアイディアは、今のWin32OLEの実装とは矛盾しません。 だから、そのまま取り込むこともできます。 ですが、もう少し、このアイディアをこねくり回してみたいと思います。
勧善懲悪のハードボイルド・ミステリー。 典型的なストーリー展開だし、主人公はタフで冷静。 命を狙われる美女を守るというありがちなパターン。 そうは言っても、事件の全貌はうまく隠してあるし、カタルシスも味わえる。 すっきりした読後感だし、楽しめます。
若干ムキになって翻訳作品ばかり怒濤のように読んできた。 もうちょっとペースを落とそう。
次のような Excel VBA のプロシージャについて考える。
Sub Foo1()
Cells(1,1) = 10
Cells(1,2) = Cells(1,1)
End Sub
結果はどうなるかというと、A1セルの値が10、B1セルの値も10になる。 では、A1セルの値とB1セルの値を削除してから次のプロシージャを実行するとA1とB1の値はどうなるか？
Sub Foo2()
Cells(1,1) = 10
c11 = Cells(1,1)
c12 = Cells(1,2)
c12 = c11
End Sub
A1の値は10で、B1には何も入らない。ちょっと紛らわしい。 Excel VBAでは、Valueを省略しても補ってくれる。 省略しないでFoo2を書き直すとわかりやすくなる。
Sub Foo2withValue()
Cells(1,1).Value = 10
c11 = Cells(1,1).Value
c12 = Cells(1,2).Value
c12 = c11
End Sub
ここで、
c12 = Cells(1,2).Value
の行に注目する。c12は、Cells(1,2)に入っている値になる。c12はCells(1,2)そのものではない。 つまり、
c12 = Cells(1,2)
と書いても VBAが気を利かせてCells(1,2)の後にValueを補うために c12は B1セルそのものではなく、B1セルに入っている値になる。
このため、
c12 = c11
の行で、c12が10に変化するだけで、B1のセルは変化しない。
Foo2のような書き方でFoo1のような効果を得るためには、
Sub Foo2()
Dim c11 As Range
Dim c12 As Range
Cells(1,1) = 10
Set c11 = Cells(1,1)
Set c12 = Cells(1,2)
c12 = c11
End Sub
と書く。
RubyのWin32OLEだとどうなるか。Win32OLEでは、Valueを省略できない。
たとえば、次の例はエラーになる。
require 'win32ole'
excel = WIN32OLE.new("Excel.Application")
excel.visible = true
book = excel.Workbooks.Add
sheet = book.Worksheets(1)
sheet.cells(1,1) = 10 # syntax error
Valueを省略せずに書くしかない。
require 'win32ole'
excel = WIN32OLE.new("Excel.Application")
excel.visible = true
book = excel.Workbooks.Add
sheet = book.Worksheets(1)
sheet.cells(1,1).Value = 10
では、次の例はどうなるか？
require 'win32ole'
excel = WIN32OLE.new("Excel.Application")
excel.visible = true
book = excel.Workbooks.Add
sheet = book.Worksheets(1)
sheet.cells(1,1).Value = 10
sheet.cells(1,2).Value = sheet.cells(1,1)
実は、A1もB1も10になる。これは、Excelが気を利かせてくれているだけである。 Win32OLEは別にValueを補ったりしない。 その証拠に
puts sheet.cells(1,1)
と実行しても、10とは出力しない。
Foo2みたいなことをやるとどうなるか？
require 'win32ole'
excel = WIN32OLE.new("Excel.Application")
excel.visible = true
book = excel.Workbooks.Add
sheet = book.Worksheets(1)
sheet.cells(1,1).Value = 10
c11 = sheet.cells(1,1)
c12 = sheet.cells(1,2)
c12 = c11
単にA1に10が入るだけである。 ここで、VBAと違うのは、
c11 = sheet.cells(1,1) c12 = sheet.cells(1,2)
で、c11はA1セルそのものを、c12はB1セルそのものになっているところである。 Win32OLEは、valueを補うという気の利いたことはしない。 だからc11, c12ともに見た目どおりセルそのものになる。 次の
c12 = c11
では、c12は、A1セルそのものになるだけで、決して10になったりしない。 試しに、
c12 = c11
の次の行に続けて
puts c12.Address
と実行してみればわかる。
では、B1にも10を入れるにはどうするか？ Valueを省略しないで書けばいい。
require 'win32ole'
excel = WIN32OLE.new("Excel.Application")
excel.visible = true
book = excel.Workbooks.Add
sheet = book.Worksheets(1)
sheet.cells(1,1).Value = 10
c11 = sheet.cells(1,1)
c12 = sheet.cells(1,2)
c11.value = c12.value
Win32OLEは見た目通りに動く。勝手にValueを補うような余計な真似はしない。
以上、わかったようなわからないような言い訳を長々と書いてみたが、 本当は、Valueを補いつつ破綻しないようなWin32OLEを実装する方法がわからないだけである。
試しに Win32OLE の手元のソースをちょっと修正して、こんなスクリプトを動くようにした。
require 'win32ole'
sh = WIN32OLE.new("WScript.Shell")
env = sh.Environment("User")
p env["TMP"]
p env["FOO"]
env["FOO"] = "BARBAZ"
p env["FOO"]
env.remove("FOO")
一見、良さそうなのだが、
env["ITEM"]
が破綻する。 元々、Win32OLEでは、env["HOGEHOGE"] は、 env の "HOGEHOGE"プロパティを求めることを意味する。 env.HOGEHOGE呼び出しと同じなのである。 とりあえず手元の修正では下位互換性を保つようにしている。だから
env["ITEM"]
は今まで通り env.ITEM 呼び出し引数が不足して失敗する。
そこで、思い切って、[]、[]= の挙動を変更して、env["HOGEHOGE"] は、env.HOGEHOGEを呼び出さないことにしようと考えたりしている。 かなり影響は大きくて動かないスクリプトが出てくることは必至なのだが、どのくらい被害が大きいかなあ？
つまり、
excel = WIN32OLE.new('Excel.Application')
excel['Visible'] = true
という書き方は駄目で、
excel = WIN32OLE.new('Excel.Application')
excel.Visible = true
という書き方しか許さなくなるとしたら、困る人はどれくらいいるだろうか？
Win32OLEのスクリプトをあまり書かないから良くわからないんだよなあ。 とりあえず、手元の奴をさらに修正して、すべて禁止にして様子を見よう。
あとは、ruby-list、 ruby-talkあたりで聞いてみよう。
よせばいいのに今頃こんな本を斜め読みしておりました。 簡単でもいいから、ATLに頼らない完全な動くコードが見たかった。 VBAなんかで省略できる valueは、Win32OLEでは省略できそうにないことが自分なりに再確認できた。
vtable呼び出しをどうすれば実現できるのか相変わらずよくわからないなあ。
[] の扱いをもう少し賢くしたり、Itemを省略できるかも知れないヒントを得たような気がする。 けれど、考えがまとまらない。
なんか、でも下手なことすると逆に混乱を招きそうだなあ。
うーむ。あれこれ悩むより試しに実装してみるか...。
「なぞなぞに答えられなければ、3分後に爆発させる。」という電話がかかってきた。 これが神学生ケヴィンを襲う連続爆破事件の始まりだった。
わりと早い段階で、犯人は、アレじゃないかと予想はついてしまった。 最後のこのオチはちょっとどうかと思う。 人によっては腹が立つかも知れません。 私は、腹が立つほどじゃないけど、ちょっとがっかりしてしまった。
ハルお婆ちゃんが謎を解く連作ミステリ。 犯罪絡みの謎もあるが、どちらかというと日常の謎を解くほのぼのとしたミステリ。 読んでいてほっと一息つける。 「走る目覚し時計の問題」が好み。
ちょっと試してみた。 てっきりIEが動いて画面が出てくるものと勘違いしていた。 NUnitAspは、NUnit を拡張する形で提供されている。 NUnitAspでは、URLを指定してページを取得して、その中身に対してのテストコードを書く。 さらに、そのページのボタンを押すということもテストコードで書ける。 NUnit GUI から実行できる。
ASP.NETのアプリをデバッグモードでコンパイル。
NUnitAspで、ASP.NETアプリのテストコードをコンパイル。
NCover.Console.exe //iis を実行。
NUnit GUI で テストコードを実行する。
これによってテストコードを実行した結果とそのテストコードによってASP.NETアプリのコードのどこが実行されたかわかる。
Perl や Python に合わせて
obj = WIN32OLE_VARIANT.new("ABC", WIN32OLE::VARIANT::VT_UI1|WIN32OLE::VARIANT::VT_ARRAY)
p obj.value
は、
"ABC"
を返すようにた。今のところ
obj = WIN32OLE_VARIANT.new("ABC", WIN32OLE::VARIANT::VT_UI1)
というVT_ARRAYを省略した書き方は認めていない。
以下のときは、WIN32OLE::VARIANT::VT_ARRAY の指定を省略できるというのを今思いついた。
第1引数が配列のとき。
第1引数が文字列で、第2引数が WIN32OLE::VARIANT::VT_UI1 のとき。
Rubyの配列から、WIN32OLE_VARIANT オブジェクトを生成するときに VT_ARRAYでないVariantに変換したい場合があるかないか...。
何はともあれ、Ruby 1.9 では、次のようなスクリプトが動きます。
require 'win32ole'
url="https://app.cocolog-nifty.com/t/app"
postdata=WIN32OLE_VARIANT.new("username=user&password=pass", WIN32OLE::VARIANT::VT_ARRAY|WIN32OLE::VARIANT::VT_UI1)
header="Content-type: application/x-www-form-urlencoded"
ie = WIN32OLE.new('InternetExplorer.Application')
ie.visible = TRUE
ie.navigate(url, nil, nil, postdata, header)
ちなみに、 Ruby 1.8 では、Win32OLE 活用法 【第 6 回】 Web 自動巡回にあるように WIN32OLE#_invoke を使うしかありません。
テンポのよい軽いノリの冒険ミステリ。 意外性がなくて、ちょっと都合が良すぎる展開のため少し白けてしまった。
女性警察官たちを主役にした短編集。 いわゆるミステリを期待したり、警察小説を期待したりするとがっかりするかも。 また軽い息抜きに読む本でもないです。 事件に関わる女性警官たちの心情を描いたずっしりと重い読み応えのある短篇集です。
フランスの田舎町に引越してきたブレイク一家。 この家族4人が4人ともとんでもないのである。 やることがムチャクチャである。 かなり過激なギャング小説ではあるが、語り口のせいかあまり陰惨さはない。
Ruby の コマだけ参加。 家を出たのが遅すぎて到着がギリギリになってしまった。 教室がどこだか確認してなかったので、 一旦8Fまで上がってから地下2Fの教室までずっと階段で移動することになり、 ヘロヘロになってしまった。
何度もずっと言っているがRailsはやってみないことには何とも言えないな。 RAD Railsって結構良くできているように見えた。
NCover.Console.exe //iis
と実行してから、ASP.NETのアプリをデバッグモードで実行する。 実行終了後、
iisreset
でIISを再起動すると、カバレッジの結果ファイルができる。 IISを再起動しないで、結果ファイルを作る方法は無いものだろうか。
NCoverとNUnitAspを一緒に使うといいかも知れない。 今度はNUnitAspを試そう。
なにかやりたいことがあると、他人の作った道具を再利用しようとせず、 一からプログラミングして道具を作ろうとする。 趣味でやる分には(プログラミングは楽しいこともあるので)それでもいいが...。
その一方で、他人の作った道具は、細かいところで、帯に短したすきに長しと感じることもある。
を試してみた。
NCoverは、てっきりC#専用かと思ったら、VB.NETのソースもカバレッジを測定してくれた。 FxCopもVB.NETのソースをチェックしてくれた。
NCoverを使って、NUnitを起動してカバレッジを測定する方法がわからない。 きっと、nunit-console.exeの使い方がわかってないだけだと思う。 もう一度、明日、ドキュメントをちゃんと読みながら挑戦しよう。
どうでもいいけど、nunit って小文字で書くと runit と見間違えてしまう。
PerlのWin32::OLE::Variantでは文字列とVT_U1の組み合わせでは、ちょっと特殊な動きをする。
use Win32::OLE::Variant; $v = Variant(VT_UI1, "ABC"); print $v->Type(), "\n"; # => VT_UI1|VT_ARRAY print $v->Get(), "\n"; # => "ABC" print $v->Get(0), "\n"; # => 65 print $v->Get(1), "\n"; # => 66 print $v->Get(2), "\n"; # => 67 $v = Variant(VT_UI1|VT_ARRAY, "ABC"); print $v->Type(), "\n"; # => VT_UI1|VT_ARRAY print $v->Get(), "\n"; # => nil print $v->Get(0), "\n"; # => nil
さて、Win32OLEでは、どうしようか。
require 'win32ole'
v = WIN32OLE_VARIANT.new("ABC", WIN32OLE::VARIANT::VT_UI1|WIN32OLE::VARIANT::VT_ARRAY)
p v.value
としたとき、"ABC"の方がよい？ それとも、あくまでも、VT_ARRAY|VT_UI1 なんだから、[65, 66, 67] の方がよい？
あと、
v = WIN32OLE_VARIANT.new("ABC", WIN32OLE::VARIANT::VT_UI1)
を受け入れるかどうか悩むなあ。 つまり、VT_UI1に変換してくれと要求しているにも関わらず、 気をきかせて VT_UI1|VT_ARRAY に変換しちゃうのは、Rubyらしいかどうか...。
それはさておき、new するときは WIN32OLE_VARIANT で、 定数は、 WIN32OLE::VARIANT になっているのはどうしてだろう？
WIN32OLE::VARIANT をクラスにしちゃうと、
include WIN32OLE::VARIANT puts VT_UI1
とできなくなるからだっけ？
うーむ...。
どうやら、Python(ActivePython)では、VT_UI1 の場合、配列を返す仕様から bufferオブジェクトを返すように変更したらしい。 win32com readme のwin32all-127 fixesのあたり。
ということで、Python, Perlに合わせて
require 'win32ole'
v = WIN32OLE_VARIANT.new("ABC", WIN32OLE::VARIANT::VT_UI1|WIN32OLE::VARIANT::VT_ARRAY)
p v.value
は、Arrayを返さず、Stringを返すのがいいのかな...。
ところで、Pythonのbufferオブジェクトって何？
初めて試してみた。
メソッドは、testで始めなくてもいいし、テストのクラスは、TestCaseを継承しなくてもいい。
<TestFixture()>
や
<Test()>
などの属性を使うらしい。
Imports NUnit.Framework
<TestFixture()> _
Public Class AClassOfTest
<Test()> _
Public Sub OneTest()
....
End Sub
End Class
みたいな感じ。
独自の進化を遂げている。 実行したAssertの数はレポートしてくれないみたい。
Virtual PCで作ったイメージファイルも実行できるとのことでVMWare-Playerを試す。 既に他の人がWMWare Playerを試していて、VMWare用に変換された設定ファイルを VMWare Playerに読み込ませたら、あっさり動きました。
『Essential .NET』のレビューに「COMの改良版としてとらえたCLRの概念」というフレーズを見て、 なるほど、そういう捉え方があるのかと思ってしまった。 そこで、思ったのであるが、『Essential COM』を読んでから、 『Essential .NET』に読み進むというのはどうだろうか。
オックスフォード大学に留学した奨学生が主人公のミステリ。 主人公は数学を専攻していて、数学や哲学に関する話題が展開される衒学趣味に満ち溢れたミステリ。 最初に指摘される犯人の動機には説得力があり、なるほどと思わせるものがある。 更にその後に明らかとなる真相には、ちょっと驚かされる。 なんか日本の新本格ミステリみたいである。
解説で言及されているアメリカの作品とはアレのことだろうか。 アレと比べると、こちらの方が盛り上がりに欠けるように感じる。 英国ミステリのような淡々とした渋い筆致のせいだろうか。
また、真犯人の隠し方から、もう一つ別の作品を連想してしまう。 その作品と比べてもやはり盛り上がりに欠けているように思う。
傑作になり損ねているように感じてしまうのも、盛り上がりに欠けているせいかも知れない。 書き方次第では、本格ミステリの傑作になっていたんじゃないだろうかと思う。
ようやく、SAFEARRAYの仕組みが見えて、配列の場合も、(私の作った通りで、しかも、)私の意図した通りに動くようにした。
Perlとは違って
WIN32OLE_VARIANT.new([1.0, 2.0], WIN32OLE::VARIANT::VT_ARRAY|WIN32OLE::VARIANT::VT_R8)
で 1.0と2.0を要素として持つ1次元の配列を作るようにした。
Perlで同じことをやるには、
Win32::OLE::Variant->new(VT_ARRAY|VT_R8, 2)->Put([1.0, 2.0]);
となる。
RubyのWin32OLEでは失われてしまうものがある。 Perlのように配列の次元を自由に指定することができないのである。
私は、Win32OLEの方が直感的でわかりやすいと思うのだが、できないことがある。 できないよりできた方がいいのかも知れない。 でも、できるとどのくらい嬉しいのかがわからない。
だから、次元を自由に指定する機能を犠牲にして、配列の次元の指定という面倒な作業を隠すことを優先させた。 実際に、WIN32OLE_VARIANTを使う場面に遭遇していない私には、これでいいのかどうか今のところわからない。
ちなみに、Win32OLEの方には、今のところ Put に相当するメソッドはない。 あった方が嬉しいと思われる。まだ、どのように実装するかは、考えてない。 多分、Perlに合わせるんじゃなくて、RubyのArrayなどを参考にすると思う。
その他にもWIN32OLE_VARIANTについては足りない部分がいっぱいありそうだ。
結局のところ、WIN32OLE_VARIANTを相手してくれるちゃんとしたCOMサーバーがいないとテストができない。 自前で超適当なCOMサーバー作っちゃうとテストにならない気がする。 Excelが使えそうな感じ。 結局、配列の扱いは、全部一から作らないと駄目かなあ。
どうもWin32OLEが(私の作った通りに動いて、)私の意図した通りに動かないので、 Perlはどうやっているのかと思って、Perlのソースを眺めてみた。
Win32::OLE::Variant->new()
のときに、どこで配列の要素の初期値を設定しているのかわからなかったのであるが、 Win32::OLE::Variantモジュールの説明 を読んでやっとわかった。 設定してなかったのである。
てっきり私は、
Win32::OLE::Variant->new(VT_R8|VT_ARRAY, [1,2])
とすると、[1.0, 2.0] という配列ができるもんだとばかり思っていた。 実はそうじゃなくて、実数(double)を要素とし、要素の添字が1から2の配列を作るだけなのである。
Cの
double ary[2];
に近いんだけど、要素にアクセスするときは、ary[1], ary[2] となる。
完全にCと同じ感じにするには
Win32::OLE::Variant->new(VT_R8|VT_ARRAY, [0,1])
か
Win32::OLE::Variant->new(VT_R8|VT_ARRAY, 2)
と書く。
SAFEARRAYのすべてをカバーするためには、こういうやり方になるのかも知れないけど、わかりにくいなあ。
昨日夜遅かったせいか頭がぼーっとしている。今日はここまで。
そうか、MS Projectは、ソフトウェア開発のスケジュール管理には向いてないのか。 開発の仕事はしてませんが、Joelを見習ってExcelによる管理を試し始めたところ。 これがいいのは、初期見積と現在見積がある点だと感じてます。 XPでもプロジェクト速度を計って見直してとか書いてましたが、Joelの方が具体的なので私にはわかりやすいです。
ATLすらないVC++2005EEでCOMプログラミングを試そうとする物好きな人間は、少数派のうちでも少数派なんだろうな。
挑発的な書き方をしていて、今一つ同意できないというか反論したいけど反論できないみたいなもやもやした気持ちがあったり (そんなこと言われたって、メモリを増設した人が劇的に快適になったと喜んでいる姿を 昨日目にしたばかりの私には、やっぱりWindows(上で動くソフト)を快適に使うにはそれなりの資源が必要だと思う訳です。) するのですが、読み物としても面白いです。
Linuxの方が軽快だと言うつもりはありません。 だって同じ性能のマシンにLinuxをインストールしてWindowsで普段やっているのと同じ(ような)ことをして比較したことがありませんから。
ほったらかしにしていたWIN32OLE_VARIANTの実装の続きをやる。 テストスクリプトを書いて実行してみたら、やっぱり予想通り配列はうまくいかない。 実装した記憶が無いから当たり前です。 うちは、小人さんが来てくれるような居心地のいい場所でもないし。
Googleなんかで調べれば、慣れてないプログラム言語でもそれなりに書けるのでいいかななどと思っていた。 でも、やっぱり特に調べなくても簡単なことはすんなり書けないと話にならない。 VBScriptやVB.NETやC#は繰り返しの処理すら調べないと書けないし。 Googleで調べれば、ある程度のことまでは書けるとは思うが、きっと、書くスピードは、お話にならないお粗末な状態のはず。 最近、特にプログラミングする機会が減っているので、まずいと感じている。
時間をかければ問題を解けるけど、受験生のように一定時間内に解く訓練をしていないから試験に不合格になるみたいな感じ。
賞金2800万ドルの当たりクジ2枚を巡って繰り広げられるドタバタ・ピカレスク。
テンポが良くて意外な展開の陽気な犯罪小説。 主人公のジョレインといい、ウェイトレスのアンバーといい女性が活躍します。 悪党がちょっと間抜けなところも、最後は納まるべきところに話が納まって終わり良ければすべて良しな感じも ハイアセンらしくていい。
大魚の一撃以来、久々に読みましたが、ハイアセンは相変わらず変で面白かったです。
USBとSCSIの変換ケーブルを買いに行った。
そういう訳で、PC周辺機器コーナーをうろちょろしていたのですが、 なんかちょっと欲しいかも知れないと思ったのは、 直刺しIDEとか 1分BOXの進化版とか。
世の中省スペースの時代なので、職場も自宅もノートパソコンが主流。 自宅はともかく、会社では検証環境を作って検証をしたいことがないこともないのです。 1台マシンを用意するなんて贅沢はできないので、Virtual PCとかVMWareとかに頼ることになるんじゃないかと思います。 ですが、ノートPCだとディスクが足らなくてイメージファイルが作れなかったりするかも知れません。 そんなときにイメージファイルを入れたハードディスクを気軽に交換しながら使ったりできるんじゃないかと思うのです。
まあ、ちょっと熱が気になりますが...。
短篇集。奇想コレクションだけあって、変な話が並びます。 「サシェヴラル」のリドル・ストーリーぽい終わらせ方とか 「そして赤い薔薇一輪を忘れずに」の暗示的な終わらせ方とか何とも言えない味があります。 最後の最後にホロリとさせるオチがある「パシャルーニー大尉」が好き。