Windows PowerShell, WinFS, IQueryable
Windows PowerShell
- 特集:Windows PowerShellレビュー(前編)次世代Windowsシェル「Windows PowerShell」を試す
- 特集:Windows PowerShellレビュー(後編) Windows PowerShellのパワーの源は.NETオブジェクト
ブックマークコメントを見ても概ね好評な模様.
- はてなブックマーク - 次世代Windowsシェル「Windows PowerShell」を試す(前編) − @IT
- はてなブックマーク - Windows PowerShellのパワーの源は.NETオブジェクト − @IT
自分が PowerShell で記事を書くと「関数型言語とは」とか「Monadとは」とかにページを割いてグダグダになりそうな気がするだけに,「まずどうやって使い始めるか」「何ができるのか」「何が便利か」をきちんと説明できているこの記事はやっぱり偉いかなと.
WinFS
んで,はてなブックマーク経由でまわっているとおもしろい話が.
『ラシウラ』より.
MacはシェルにObject指向プログラミングを組み込んだけど、VistaはシェルにOOに関数型の汎用コマンド演算体系(Monad)を組み込んだ感じだ。
これで任意のコマンドから利用できるデータソースたりうるWinFSがないのは正直もったいないと思った。これは、個別にコマンドを実装すらいいって話なのだろうけど、そうなるとfilterとデータ型は相互作用的に広がりることは起こらないだろう。結局、いままでのアプリと同じく、テキストやwell-known XMLといった共通フォーマットでない限りは、データとその処理は一体で一緒に普及させるしかなくなる。
これを読んでなんとなくセマンティックウェブを巡るいつもの議論を思い出したり.
http://slashdot.jp/article.pl?sid=06/07/20/1845249
もし仮に WinFS が登場していたとしても,「メタデータスキーマは魅力的か」「そもそもメタデータをみんなに入力してもらえるか?」という点では,やっぱり越えるべきハードルはまだまだあるんじゃないかなと.
例えば手元の PowerPoint 2003 で,ファイルのプロパティから「ユーザー設定」というタブを選ぶと,実に多くのメタデータが設定可能でびっくりします.
- グループ
- タイピスト
- プロジェクト
- メールボックス
- リファレンス
- リンク元
- 宛先
- 確認者
- 完了日
- 記録者
- 記録日
- 言語
- 顧客
- 行先
- 差出人
- 事業所
- 事業部
- 所有者
- 進捗状況
- 電話番号
- 内容
- 配置
- 発行側
- 部署
- 編集者
- 目的
さて,遙か以前から存在する Office のこれらのメタデータですが,一体どの程度利用実績があるのでしょうか?
ひとつは UI の問題がありそうです.そもそもプロパティのこんな奥底に入力インターフェイスを用意して,ちゃんと入力してくれる人がいるかどうか.
もうひとつは,そもそもこのスキーマが魅力的か? というものでしょう.まあ意識的に使えばいくつかのメタデータはそのまま使えそうな気はします.しかし,「汎用的なオフィス文章用のテーブルを設計してください」というお題でみて,このテーブル設計はどうなんでしょうかね?
結局のところ,先ほどの /.J のトピックで紹介されていた Google の主張のように,データごとにカスタムなロジックを用意するという場当たり的な方法の方が,今現在は勢いがあるという印象を受けます.Windows のデスクトップ検索もこの方向です.IFilter という以前から存在した仕組みを利用し,PDF,Excelファイルといった各データフォーマットごとにデータ抽出コードを作成する方法で,利用者が満足するならそれでいい,と.
そんな中,万能データストレージの計画が凍結され,代わりに万能変換フィルタとしての LINQ が生き残っているのはまあそれ程不思議でもないのかもしれません.
IQueryable
某スレで名無しさん♯が紹介されていたこれなどは,既存のデータをクエリ可能オブジェクトに見せかける例として非常に興味深いものです.
IQueryable インターフェイスと,Expression Tree によって,Amazon の Web Service をクエリ可能ソースにしてしまうというサンプルです.
PowerShell の Custom Provider がどこまでできるかは調べていませんが,LINQ が遅延評価を前面に押し出しているのは明らかで,単なるパイプ処理とは一線を画しています.
PowerShell, WF, LINQ
『ラシウラ』より.
現状はまだそんなにフィルタ化できるものはないけれど、フィルタ化するといいというものは実はかなりあったりする。とくにWebリソース(YouTube、2ch、RSS、はてブ、などなど)やOffice文書はそんなの多いわけだし。いまは、まあPlaggerを使えばいいのかもしれない。それよりもミクロレベルから、それと同じようなことがやりやすくなる可能性があるということだ。
あとGUIと合わないということもない。GUIのメニューは実質的にコマンド発行でしかないのだから。要はいかにフィルタ抽象できるかを解決できれば、むしろカスタマイズシステムとしてCmdletを起動するGUIを作ることが簡単になる。とくにWPFと組み合わせたらおもしろいだろう。
Microsoft 界隈でフィルタ指向のプログラミングというと,とりあえず次の 3 つが思い浮かびます.
- PowerShell
- Windows Workflow Foundation (WF)
- LINQ
これらはいずれも .NET Framework 3.0 かそれ以降の技術であるものの,基本的に別個の技術であるところがおもしろいです.ベクトルとしては共通性を持ちますが,実装技術では実はそれほどリンクしていなくて,むしろかぶっている部分もちらほら.
- PowerShell
- バッチファイルに取って代われるかは未知数.実行エンジンを再利用可能なので,アプリケーション組み込み等マクロ言語への応用も可能.
- Windows Workflow Foundation (WF)
- Office 2007 のパートナーの座を射止めたという噂.Office 製品に対するバッチ処理やパイプライン処理の記述はこちら?
- LINQ
- プログラミング言語に最も接近した (密着した) 技術.Orcas 世代の目玉商品.XML (+Web),SQL Server (+ADO.NET vNext)と仲良し.
そのうち,LINQ と PowerShell の連携させる話だとか,LINQ でフィルタを書く話などがわらわら出てくるようになるかもしれませんね.
任意長整数/任意精度浮動小数点数
COM Interop, Marshal.ReleaseComObject
「じゃんぬねっと日誌」より.
コメント欄でちょこっと書きましたが,C# から COM の参照カウントを扱うのが面倒なら,自動コード生成を行ったり,参照カウント向きの言語*1を併用したりするのがむしろ正攻法かと思います.餅は餅屋.いっそのこと言語自作もありかなと.
以下はコメントで書いたサンプルの再掲.
// 参照設定 // "Microsoft Excel 11.0 Object Library" // "Microsoft Script Control 1.0" using System; using System.Collections; using MSScriptControl; using Excel = Microsoft.Office.Interop.Excel; using System.Threading; using System.Runtime.InteropServices; class Program { static void Main(string[] args) { ArrayList rcws = new ArrayList(); try { ScriptControl scl = new ScriptControl(); rcws.Add(scl); Excel.Application excel = new Excel.Application(); rcws.Add(excel); scl.Language = "VBScript"; scl.AddObject("objExcel", excel, false); scl.ExecuteStatement("objExcel.Visible = True"); scl.ExecuteStatement("Set objWorkBook = objExcel.WorkBooks.Add"); scl.ExecuteStatement("objExcel.ActiveCell.Value = \"hoge\""); scl.ExecuteStatement("objWorkBook.Saved = True"); scl.ExecuteStatement("objWorkBook.Close"); scl.ExecuteStatement("objExcel.UserControl = False"); Thread.Sleep(1000); } finally { foreach (object obj in rcws) { try { Marshal.ReleaseComObject(obj); } catch { } } } } }
VisualBasic 6 で ActiveX コンポーネントを作って,Reg-Free COM ってのもありでしょうね.
参照カウントベースのライブラリとのミスマッチは,Managed DirectX でもしばしば問題になります.
多いのがこのパターン.
Texture texture = ...;
int width = texture.GetSurfaceLevel(0).Description.Width;
GetSurfaceLevel が返す Surface クラスは実は IDisposable で,さらに Dispose を呼ぶことで内部 COM オブジェクトの Release が呼ばれるという仕組みです.そのため,このコードでは Surface オブジェクト (の内部の IDirect3DSurface9* が指すオブジェクト) の解放が次回の GC まで遅れます.元々 C++ で DirectX を使っていた人は,Unmanaged オブジェクトとの対応から危なそうな場所が予想できるでしょうが,そうでない人にとっては難しい問題に見えるかも知れません.