d3.jsの練習がてら、色を選ぶためのツール(ページ)「pcolors」を作った。色をマウスオーバーすると、いつもの16進のRGBの色がでてくるので、コピーすればOK。
使い方としては例えば、「ドミナントカラー」で「暖色系」かな、となったらじゃあ色相は2で統一、トーンはvとp+、じゃあv2とp2+かな、となると「#e60044」と「#fad5cf」か、みたいな感じで使う。詳しくはPCCSのことが書いてある本を読めば書いてあるはず(私は「配色&カラーデザイン ~プロに学ぶ、一生枯れない永久不滅テクニック~」で入った)
まぁこれは見ての通りPCCSトーンマップなのだけど、WebにあるやつはPCCSの主張と見た目がどうもあってない気がしたり(紙であれば納得できる雰囲気になるのだと思う)、ページの構成がいまいちだったりしたので、自分で作った。
ひとつひとつ埋めていったので、どこか間違っている色があるかも。こういう機能があれば便利、みたいなのも気が向けば実装するかもしれない。
2014-10-12
PythonでGIMPのスクリプトを書く(Python-Fuの書き方)
これはGIMPでスクリプトを使おう!と思ったものの久々のScheme (Script-Fu)にめげて「GIMPってPythonも普通に使えるんじゃね?」ってことで試してみたら罠もあったけどいい感じだったよって記事である。Linuxではもちろん、Windowsでもインストーラから入れればPythonが同梱されているので、気軽に使える。
もちろんGIMPを普段から使うのであれば、マクロ的に使ってもいいと思うのだけど、GIMPを使ってなくても「UIの必要な画像処理」には便利だと思う。画像の表示、範囲選択とか、そういうのが本筋じゃないプログラムにさらっと提供できる。たとえば、自前のOpenCVを使った画像処理ライブラリのフロントエンドとかね。
枝葉の処理が多いのでこのスクリプト自体は解説しないが、自分が作ろうと思って作ったもの(後述)はこちら:
これを、~/.gimp-2.8/plug-ins (WindowsであればC:\Users\{username}\.gimp-2.8\plug-ins)に適切なファイル名をつけて配置する。なお、Unix系では実行権が必要なのでつけておく。
詳しくは先のdeveloperworksの記事、あるいはGIMP Python Documentationを参照のこと。
基本的には見ての通りのところを直していけばいいのだが、引数と書いた部分の配列に、項目を設定しておくと、スクリプト起動時にダイアログが現れて選択させることができる。例えば、文字列を受け取りたければ、以下のタプルを配列に入れる。
ここに入れた項目は、設定した関数名の関数に渡るので、入れた項目を覚えておく。
引数は、現在のイメージ、レイヤーに続いて、先ほどregister関数で指定した引数を受け取るようにする。
中の実装に関しては、大きく分けて以下の2つの方法で関数を呼び出していく形になる。
例えば、このような形である。
どのようなプロシージャが存在するかは「ヘルプ>プロシージャーブラウザー」よりプロシージャーブラウザーを起動して検索することができる。
例えば、以下のようにするとメッセージを表示することができる。
実装されている関数についてはGIMP Python Documentationの「GIMP Module Procedures」に一覧がある。
あるいは、フィルター>Python-Fu>コンソールで、Python Consoleが動くので「help(gimp.Image)」などとしても良い。
また、関数部分のみ実行されるようにしてPythonコンソールからimportして呼び出してみたり、sys.stderrをopen("file/path", "a")で差し替えてみたりといったデバッグテクニックがあるので、GIMP Forumの「Debugging python-fu scripts 」の記事を参照されたい。
そういうときは、ウィンドウ>ドッキング可能なダイアログ>エラーコンソールで、リスト形式でエラーメッセージを見ると良い。
こちらの「Beginning GIMP: From Novice to Professional」にあるいくつかのサンプルスクリプトを読むともっとイメージがつきやすいと思う。
また、GIMP Plugin Registryの「python」タグでもPythonでの記述についてのサンプルが得られる。
先日、画像のピクセル数が見た目サイズの2倍の画像をベタなHTML+CSSに入れ込んでいくという作業があり、物理電卓をバチバチ叩きながら1/2サイズを作っていった。
「これは機械にやらせたほうがいい」と思って「画像... 自動化... UI作るの面倒... ここはGIMPじゃね?」ということで久々にScript-Fuを書こうとしたところ、どうもScheme脳に頭が切り替わらない。「Pythonも使えるんじゃね?Windowsも普通に入ってるわ」ということでPythonでGimpマクロ的なものを書いてみた次第である。
結果、SchemeによるScript-Fuに比べると素直じゃない感はあるものの、仕組みを掴んでしまえば、Lispを普段書かない自分には圧倒的にサクサク書くことができた。そのギャップから、普段Pythonは書けないのに「俺ひょっとしてPython書けるんじゃね?」という謎の錯覚が生まれた。
なお補足しておくと、どっちかっていうと今回は「これは覚えるチャンス」的な意味が大きくて、このケースでは実際にはCompassにサイズ計算させるとか、とか、sh+ImageMagickやPowerShellでディレクトリに置いたやつを一気に作る、とかのほうが現実的なアプローチだとは思うので、そちらを検討されたほうがよろしいかと。
もちろんGIMPを普段から使うのであれば、マクロ的に使ってもいいと思うのだけど、GIMPを使ってなくても「UIの必要な画像処理」には便利だと思う。画像の表示、範囲選択とか、そういうのが本筋じゃないプログラムにさらっと提供できる。たとえば、自前のOpenCVを使った画像処理ライブラリのフロントエンドとかね。
枝葉の処理が多いのでこのスクリプト自体は解説しないが、自分が作ろうと思って作ったもの(後述)はこちら:
PythonでのGIMPのスクリプトの書き方
基本的には、developerworksの記事「Python を使用して GIMP 用のプラグインを作成する」がわかりやすいので、詳しいチュートリアル的なものが必要であればそちらのほうで。こちらは、だいたいどんなことをすればできあがるのかなというのをイメージできるようざっくりと書くことにする。1. 雛形を持ってきて配置
雛形があれば余計なところに時間がかからないので、作ったのがこちら。これを、~/.gimp-2.8/plug-ins (WindowsであればC:\Users\{username}\.gimp-2.8\plug-ins)に適切なファイル名をつけて配置する。なお、Unix系では実行権が必要なのでつけておく。
$ chmod a+x helloworld.py
2. register関数を書く
まずプラグインをGIMP側に登録するregister関数の引数を埋めていく。詳しくは先のdeveloperworksの記事、あるいはGIMP Python Documentationを参照のこと。
基本的には見ての通りのところを直していけばいいのだが、引数と書いた部分の配列に、項目を設定しておくと、スクリプト起動時にダイアログが現れて選択させることができる。例えば、文字列を受け取りたければ、以下のタプルを配列に入れる。
(PF_STRING, "string", "説明", 'デフォルト値')PF_STRINGのような型にどんなものがあるかは、やはりGIMP Python DocumentationのPlugin Frameworkを参照。
ここに入れた項目は、設定した関数名の関数に渡るので、入れた項目を覚えておく。
実体の関数(雛形のplugin_main)を書く
plugin_mainとregister関数で指定してあるので、この関数に処理を実装していく。引数は、現在のイメージ、レイヤーに続いて、先ほどregister関数で指定した引数を受け取るようにする。
中の実装に関しては、大きく分けて以下の2つの方法で関数を呼び出していく形になる。
A. pdb.~で、プロシージャデータベースの関数を呼び出す
GIMP内部にプラグインの処理を登録しておくプロシージャデータベース(Procedual Database, pdb)というものが存在し、この関数をpdb.なんとかのような形で呼び出すことができる。例えば、このような形である。
pdb.gimp_image_scale(img, 640, 480)
どのようなプロシージャが存在するかは「ヘルプ>プロシージャーブラウザー」よりプロシージャーブラウザーを起動して検索することができる。
B. gimpモジュールに含まれる関数を呼び出す
レイヤーを作成したりといったベーシックな処理であれば、gimpモジュールにも関数が準備されている。例えば、以下のようにするとメッセージを表示することができる。
gimp.message("Hello, World")
実装されている関数についてはGIMP Python Documentationの「GIMP Module Procedures」に一覧がある。
あるいは、フィルター>Python-Fu>コンソールで、Python Consoleが動くので「help(gimp.Image)」などとしても良い。
Pythonで文法チェック
書き終わったら、そのスクリプトをpythonコマンド(Windowsではインストールパス\Python\pythonにある)で実行してみる。実行したとき、gimpfuモジュールがない旨のメッセージが出ればひとまずOK。これで文法的なミスがないか確認する。>"C:\Program Files\GIMP 2\Python\python" C:\Users\yoichi\.gimp-2.8\plug-ins\helloworld.py Traceback (most recent call last): File "C:\Users\yoichi\.gimp-2.8\plug-ins\helloworld.py", line 5, infrom gimpfu import * ImportError: No module named gimpfu
起動
ここでGIMPを起動し、メニュー項目に指定した項目があり、実行できれば成功である。罠
丁寧にチュートリアル通り作ればいいが、動けばいいやと雰囲気で適当に作ったらはまった。(Unixでは)実行権を与える必要がある
忘れがちであるが、Unix系ではplug-insに置いたスクリプトに実行権が必要である。main()を忘れない
register()のあとにmain()があるが、これがないと動作しない。詳しくは追いかけていないが、実行権が必要であるところからして、このスクリプトは単体のプロセスとして動作し、main()の中でGIMP本体と通信して動作しているのだと思う。image, layer引数が必要
引数の配列で宣言した項目のほかに、現在のイメージとレイヤーを受け取っておく必要がある。Windowsではデバッグしにくい
Unixではコンソールからgimpコマンドで起動すればエラーが出てくるが、Windowsではコンソールはデフォルトではない。そのため、困っているときは以下のように起動してみる。gimp --console-messages
また、関数部分のみ実行されるようにしてPythonコンソールからimportして呼び出してみたり、sys.stderrをopen("file/path", "a")で差し替えてみたりといったデバッグテクニックがあるので、GIMP Forumの「Debugging python-fu scripts 」の記事を参照されたい。
Windows版GIMPではメッセージボックスが出ない(ことがある?)
どっかの変数のデフォルト値の違いだと思うが、デフォルトではWindowsでインストールしたGIMPではgimp.messageでメッセージボックスが出なかった。そういうときは、ウィンドウ>ドッキング可能なダイアログ>エラーコンソールで、リスト形式でエラーメッセージを見ると良い。
参考
今までのリンクの他にも「Writing Python script for Gimp 」のブログ記事もわかりやすい。こちらの「Beginning GIMP: From Novice to Professional」にあるいくつかのサンプルスクリプトを読むともっとイメージがつきやすいと思う。
また、GIMP Plugin Registryの「python」タグでもPythonでの記述についてのサンプルが得られる。
何に使ったか?
ということで無事に書けるようになったわけだが、そもそもなぜ書くことになったか?先日、画像のピクセル数が見た目サイズの2倍の画像をベタなHTML+CSSに入れ込んでいくという作業があり、物理電卓をバチバチ叩きながら1/2サイズを作っていった。
「これは機械にやらせたほうがいい」と思って「画像... 自動化... UI作るの面倒... ここはGIMPじゃね?」ということで久々にScript-Fuを書こうとしたところ、どうもScheme脳に頭が切り替わらない。「Pythonも使えるんじゃね?Windowsも普通に入ってるわ」ということでPythonでGimpマクロ的なものを書いてみた次第である。
結果、SchemeによるScript-Fuに比べると素直じゃない感はあるものの、仕組みを掴んでしまえば、Lispを普段書かない自分には圧倒的にサクサク書くことができた。そのギャップから、普段Pythonは書けないのに「俺ひょっとしてPython書けるんじゃね?」という謎の錯覚が生まれた。
なお補足しておくと、どっちかっていうと今回は「これは覚えるチャンス」的な意味が大きくて、このケースでは実際にはCompassにサイズ計算させるとか、とか、sh+ImageMagickやPowerShellでディレクトリに置いたやつを一気に作る、とかのほうが現実的なアプローチだとは思うので、そちらを検討されたほうがよろしいかと。
2014-09-26
Linux版HipChatで日本語入力できないときの対処(Ubuntu + 野良Qt5アプリで日本語入力)
Linux版HipChatで日本語入力ができなくて、最初そんなもんかと思ったけど追っかけてみたら直せた。
結論的にはださいがこれでいけた:
今回はこうだったが、実際は環境によっていろいろだと思うので、進め方を残しておく。
以下のコマンド出力からわかるように、自前でQt5ライブラリを抱えており、シンボリックリンク"/usr/bin/hipchat"からのbash script "/opt/HipChat/bin/hipchat"からの/opt/HipChat/lib/hipchat.binで起動するようになっている。
fcitxに設定されているようだ。
ということで、fcitxはない。ibusはあるので、おそらくibusだったらそのまま入力できたのだろう。
Ubuntu側にあればもらってこようと思って調べたら、
そのため、以下のようにシンボリックリンクを張ることで日本語入力を行うことができるようになった。
/opt/HipChat/bin/hipchat抜粋:
自前のほうに向けないとあらぬプラグインを読んだりするかもしれないものね。こういうケースもあるので、野良アプリケーションでは起動するときの流れを確認されたい。
結論的にはださいがこれでいけた:
今回はこうだったが、実際は環境によっていろいろだと思うので、進め方を残しておく。
環境
- Distribution
- Ubuntu 14.04 Japanese Remix (amd64)
- Desktop 環境
- Cinnamon →第342回 デスクトップ環境Cinnamonを使用する:Ubuntu Weekly Recipeを参照
Qt5での日本語入力に必要なこと
Qt5でbuildされた QtCreatorで日本語入力をできるようにする(@Linux環境) によると、どうやら2つのことが必要らしい。- 環境変数QT_IM_MODULEの設定
- platforminputcontextsプラグインの配置(or 環境変数でプラグインパスの変更)
対象アプリケーションの構成の確認
HipChatのインストール方法はHipChat - Downloadsに書いてある通り、apt-lineを追加してapt-get install。つまり、公式ではない野良アプリケーション。以下のコマンド出力からわかるように、自前でQt5ライブラリを抱えており、シンボリックリンク"/usr/bin/hipchat"からのbash script "/opt/HipChat/bin/hipchat"からの/opt/HipChat/lib/hipchat.binで起動するようになっている。
$ dpkg -L hipchat /usr /usr/bin /usr/share /usr/share/applications /usr/share/applications/hipchat.desktop /usr/share/icons /usr/share/icons/hicolor /usr/share/icons/hicolor/256x256 /usr/share/icons/hicolor/256x256/apps /usr/share/icons/hicolor/256x256/apps/hipchat.png (略) /opt /opt/HipChat /opt/HipChat/bin /opt/HipChat/bin/linuxbrowserlaunch /opt/HipChat/bin/hipchat /opt/HipChat/bin/HipChatNowPlaying.rb /opt/HipChat/lib /opt/HipChat/lib/libvorbis.so.0.4.5 /opt/HipChat/lib/libvorbisfile.so.3.3.4 (略) /usr/bin/hipchat (略) /opt/HipChat/lib/hipchat.bin (略) /opt/HipChat/lib/libQt5Network.so.5 /opt/HipChat/lib/libvorbis.so /opt/HipChat/lib/libQt5Sql.so.5 /opt/HipChat/lib/libdbusmenu-qt5.so.2 $ file /usr/bin/hipchat /usr/bin/hipchat: symbolic link to `/opt/HipChat/bin/hipchat' $ file /opt/HipChat/bin/hipchat /opt/HipChat/bin/hipchat: Bourne-Again shell script, ASCII text executable $ tail -1 /opt/HipChat/bin/hipchat exec -a "$0" $commandtorun "$hipchatRoot/lib/hipchat.bin" $arguments
環境変数QT_IM_MODULEの設定
QT_IM_MODULEが設定されていることを確認する。$ env | grep IM_ CLUTTER_IM_MODULE=xim QT_IM_MODULE=fcitx QT4_IM_MODULE=fcitx GTK_IM_MODULE=fcitx
fcitxに設定されているようだ。
platforminputcontextsプラグインの確認
先ほどの記事によると、platforminputcontextsプラグインが重要らしい。ということでパッケージを調べてみると$ dpkg -L hipchat | grep platforminput /opt/HipChat/lib/plugins/platforminputcontexts /opt/HipChat/lib/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so /opt/HipChat/lib/plugins/platforminputcontexts/libcomposeplatforminputcontextplugin.so
ということで、fcitxはない。ibusはあるので、おそらくibusだったらそのまま入力できたのだろう。
Ubuntu側にあればもらってこようと思って調べたら、
$ dpkg -S fcitxplatform fcitx-frontend-qt5:amd64: /usr/lib/x86_64-linux-gnu/qt5/plugins/platforminputcontexts/libfcitxplatforminputcontextplugin.soということで、存在していた。なければapt-get install fcitx-frontend-qt5で入りそうである。
そのため、以下のようにシンボリックリンクを張ることで日本語入力を行うことができるようになった。
$ sudo ln -s /usr/lib/x86_64-linux-gnu/qt5/plugins/platforminputcontexts/libfcitxplatforminputcontextplugin.so \ /opt/HipChat/lib/plugins/platforminputcontexts/それぞれビルドされた環境が異なるし、いつまでこれができるかわからないので、いっそcpでコピーしたほうがいいかもしれない。
番外:環境変数QT_PLUGIN_PATHの設定
先ほどの記事からするとQT_PLUGIN_PATHを/usr/lib/x86_64-linux-gnu/qt5/pluginsに向ければいけそうであるが、そうはいかない。というのも、/opt/HipChat/bin/hipchatがunsetしているからである。/opt/HipChat/bin/hipchat抜粋:
thisfile="`readlink -f "$0"`" thisdirectory="`dirname "$thisfile"`" hipchatRoot=$thisdirectory/../ export HIPCHAT_LD_LIBRARY_PATH=$LD_LIBRARY_PATH export HIPCHAT_QT_PLUGIN_PATH=$QT_PLUGIN_PATH export LD_LIBRARY_PATH=$hipchatRoot/lib unset QT_PLUGIN_PATH exec -a "$0" $commandtorun "$hipchatRoot/lib/hipchat.bin" $arguments
自前のほうに向けないとあらぬプラグインを読んだりするかもしれないものね。こういうケースもあるので、野良アプリケーションでは起動するときの流れを確認されたい。
2014-09-20
WindowsアプリのUI自動操作をUI Automation PowerShell Extensionで行う
UI Automation PowerShell Extensionは、.NET Frameworkに付属するUI オートメーションライブラリのPowerShellラッパーで、UI自動操作(UIオートメーション)をPowerShellで記述できる。これにより、GUIしかないアプリの定型作業をスクリプト化したり、UIテストを行ったりすることができる。だいぶ前に書こうと思ったのだけど、思い出したのでようやく書くことにした。
結構簡単に操作できることがわかると思う。ではここから使い方を見ていく。
本当はこの中身をDocuments\WindowsPowerShell\Modules\UIAutomationに入れるのだけど、お試しなのでとりあえず
Get-Moduleして以下のようにでてくればOK。
UIAutomationSpy.exeを起動すると、ボタンが2つとテキストボックスがいくつかある画面が起動するので「Start」ボタンを押してから、マウスカーソルに適当なウィンドウに持っていくと、テキストボックスにコマンドが表示される。
欲しい部品が見つかったら、素早くStopボタンを押す。
一番下のテキストボックスにホバーしたUI要素を探すためのコマンドが書かれているが、基本的にはこれをそのまま使うのではなく、不要な部分を削ったり、ちょっと加えたりする。例えばさっきの電卓の例であれば、採取したタイミングでは以下のようになっている。
しかし、Get-Uiaシリーズは基本的に再帰的に要素を探してくれるので、ウィンドウを取得できたら、あとは特定できるのであれば詳しく書く必要はない。上記の例では、以下でもOK.
なお、Idというだけあって、通常はAutomationIdを使うのがおすすめ。上記の例では適切なものがついていないが、WPFアプリケーションならx:NameやNameに設定したものがついている。
コントロールするコマンドレットは自分で探すしかないが、基本的にSet-UiaやInvoke-Uiaがついているので、補完でだいたい探せる。例えば「Invoke-UiaWindowPattern -PatternName Close」や「Set-UiaTextBoxText」などである。
見つからないときは「Get-Command *uia*」とすれば一覧がでてくるので、これから探す。なお、テキストを取得するGet-UiaTextTextなど、取得する系のコマンドレットもあるので、テストなんかには活用されたし。
上記を組みわせていけば自動操作するスクリプトができる。
また、このライブラリはSystem.Windows.Automationのラッパーでしかないので、.NETのUI オートメーションの情報、例えばMSDNのドキュメント(UI オートメーションの概要)や既存の記事なども参考にできる。コマンドレットで不足があれば、.NETのAPIを得られたオブジェクトに対して実行してしまっても動作する。
なお、試してみてはいないが、Metro UIなんて記載もあるので、Windowsストアアプリも操作できそうである。興味があればぜひ。
以上、Happy UI Automation Lifeを。
例
まずは例として、Windowsに付属する「電卓」を使って1 + 2を計算してみるスクリプトを書くと以下のようになる。$process = Start-Process calc -PassThru $window = Get-UiaWindow -ProcessId $process.Id $window | Get-UiaButton -Name '1' | Invoke-UiaButtonClick | Out-Null $window | Get-UiaButton -Name '加算' | Invoke-UiaButtonClick | Out-Null $window | Get-UiaButton -Name '2' | Invoke-UiaButtonClick | Out-Null $window | Get-UiaButton -Name '等号' | Invoke-UiaButtonClick | Out-Null
結構簡単に操作できることがわかると思う。ではここから使い方を見ていく。
準備
まずは準備として、http://uiautomation.codeplex.com/ に行き、Downloadボタンを押してzipをダウンロード、どこかに展開する。本当はこの中身をDocuments\WindowsPowerShell\Modules\UIAutomationに入れるのだけど、お試しなのでとりあえず
Import-Module .\UIAutomation.dllとする。
Get-Moduleして以下のようにでてくればOK。
PS > Get-Module UIA*
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Binary 0.8.7.79 UIAutomation {Add-UiaBannerText...
作り方
作り方は、「UI要素を探す」「UI要素をコントロールする」を繰り返すだけ。UI要素を探す
UIをポイントするとUI要素を表示してくれるSpyツール「UIAutomationSpy.exe」が付属しているので、これを使ってコマンドを生成することができる。UIAutomationSpy.exeを起動すると、ボタンが2つとテキストボックスがいくつかある画面が起動するので「Start」ボタンを押してから、マウスカーソルに適当なウィンドウに持っていくと、テキストボックスにコマンドが表示される。
欲しい部品が見つかったら、素早くStopボタンを押す。
一番下のテキストボックスにホバーしたUI要素を探すためのコマンドが書かれているが、基本的にはこれをそのまま使うのではなく、不要な部分を削ったり、ちょっと加えたりする。例えばさっきの電卓の例であれば、採取したタイミングでは以下のようになっている。
Get-UiaWindow -Class 'CalcFrame' -Name '電卓' | ` Get-UiaPane -Class 'CalcFrame' | ` Get-UiaPane -Class '#32770' | ` Get-UiaButton -AutomationId '81' -Class 'Button' -Name 'クリア'
しかし、Get-Uiaシリーズは基本的に再帰的に要素を探してくれるので、ウィンドウを取得できたら、あとは特定できるのであれば詳しく書く必要はない。上記の例では、以下でもOK.
Get-UiaWindow -Class 'CalcFrame' | Get-UiaButton -Name 'クリア'
なお、Idというだけあって、通常はAutomationIdを使うのがおすすめ。上記の例では適切なものがついていないが、WPFアプリケーションならx:NameやNameに設定したものがついている。
UI要素をコントロールする
上記のGet-~で得られたオブジェクトを、コントロールするコマンドレットにパイプで渡せばコントロールすることができる。例えば、ボタンをクリックするなら以下の通りになる。$button | Invoke-UiaButtonClick
コントロールするコマンドレットは自分で探すしかないが、基本的にSet-UiaやInvoke-Uiaがついているので、補完でだいたい探せる。例えば「Invoke-UiaWindowPattern -PatternName Close」や「Set-UiaTextBoxText」などである。
見つからないときは「Get-Command *uia*」とすれば一覧がでてくるので、これから探す。なお、テキストを取得するGet-UiaTextTextなど、取得する系のコマンドレットもあるので、テストなんかには活用されたし。
上記を組みわせていけば自動操作するスクリプトができる。
もっと詳しく
ほとんど上記で行えているが、歯抜けではあるがドキュメントがあるので、こちらも参考にできる。また、このライブラリはSystem.Windows.Automationのラッパーでしかないので、.NETのUI オートメーションの情報、例えばMSDNのドキュメント(UI オートメーションの概要)や既存の記事なども参考にできる。コマンドレットで不足があれば、.NETのAPIを得られたオブジェクトに対して実行してしまっても動作する。
なお、試してみてはいないが、Metro UIなんて記載もあるので、Windowsストアアプリも操作できそうである。興味があればぜひ。
Tips
UI自動操作は対象によってTips的なものが使うほどにでてくるが、最初から大事そうなものを挙げておく。ウィンドウをプロセスで絞り込む
ウィンドウはプロセスを決めなくても検索できるが、自分で起動している場合など、限定できる場合は-ProcessIdで絞っておくと安全である。Get-UIAWindow -ProcessId $proc.Id -AutomationId hogehoge
UI要素をガイドする赤枠を外す
デフォルトでは選択した要素には赤枠がつくようになっている。しかし、通常は邪魔なので以下で外すことができる。[UIAutomation.Preferences]::Highlight = $false
タイムアウトを変更する
既定でもUI要素が出てくるまである程度待ってくれるが、足りない場合は-Secondsで延長できる。Get-UIAWindow -AutomationId hogehoge -Seconds 60
以上、Happy UI Automation Lifeを。
2014-09-19
一部のSSDとext4でWriteが激しく遅い問題に対処する
結論:dbench 5 -D .で3MB/s程度しか出ないときは、barrier=0マウントオプションを検討する。
それ自体はまぁいつもの感じでできて、グラフィックがサクサクになって期待通りの感じだったのだけど、ディスクI/Oが異常に遅い。apt-getすると「Unpacking~」で数十分とか待たされて、apt-get upgradeが全然終わらない。
これでは使い物にならないので、なんとかすることにした。
遅くなる事例がないかなと思って調べてみると、どうやら廉価なモデルらしく、painfully slowとか言われていて、機種のせいかとあきらめかけたら、まさかの日本のAmazonレビューに気になる記述を発見。
この中ではbarrier=0が気になったのでmount -o remount,rw,barrier=0 /でマウントしたらapt-getのひっかかりがなくなった。
体感と一致するありえないぐらいの遅さが数字に出ていた。3MB/sって光回線より遅いよ...
barrier=1がいつでもここまでインパクトを与えるかというとそうではなく、ずっと使っているノートPCのSSD(Crucial C300-CTFDDAC128M)では以下の通り。
確かに遅くはあるのだけど、桁が変わるほどではない。max_latencyを見ると、さっきのSSDは投げ捨てろって感じだけどね...
ついでなので、SSDにTRIMコマンドを発行するようになる「discard」オプションをつけて測ってみたが、特に変化はない様子。
大事なデータを扱っている機械なら、こんな個体に当たったら使うのをやめるべきと思う。
背景
Windows8.1の上のVirtualBoxにUbuntuを乗せて開発をしていたのだけど、開いたウィンドウがフルスクリーンの裏/表に回っちゃうとか、3D性能が下がるせいでウィンドウマネージャが限定されて効率が悪いといった不満があったので、今のご時勢にデュアルブートにすることにした。それ自体はまぁいつもの感じでできて、グラフィックがサクサクになって期待通りの感じだったのだけど、ディスクI/Oが異常に遅い。apt-getすると「Unpacking~」で数十分とか待たされて、apt-get upgradeが全然終わらない。
これでは使い物にならないので、なんとかすることにした。
対処
使っているSSDはcrucialの「CT256V4SSD2」。ファームウェアが更新されていて、変更内容がパフォーマンス改善だったので、更新してみるものの、改善されない(なお、ディスクは消去されるのでインストールし直した)。遅くなる事例がないかなと思って調べてみると、どうやら廉価なモデルらしく、painfully slowとか言われていて、機種のせいかとあきらめかけたら、まさかの日本のAmazonレビューに気になる記述を発見。
※2013/2/14追記http://www.amazon.co.jp/product-reviews/B0092LHA7Y
公式フォーラムでの情報を参考に、Linux ext4ファイルシステム環境において
ほぼ完全な動作を得られましたので一応追記しておきます。
mountオプションとしてnoatime,nodiratime,data=writeback,barrier=0,commit=180,nobhを指定することでフリーズを回避できるようです。
CD/USBブート後当SSDに対してtune2fs -o journal_data_writeback /dev/sd**を実行、
fstabのオプションフィールドに上記パラメータを追加することで、ようやく完全にSSDとしての性能を発揮するようになりました。
この中ではbarrier=0が気になったのでmount -o remount,rw,barrier=0 /でマウントしたらapt-getのひっかかりがなくなった。
計測
もう体感では明らかに速くなっているのでこれでもいいのだけど、検索してみると同じ症状ではないかと思われる人がベンチマークを取っている(ext4のボトルネック除去:(SSDの)命懸けベンチマーク編)ので真似して「dbench 5 -t 30 -D .」で1回だけざっくり測ってみた結果がこちら。| Throughput | max_latency | |
|---|---|---|
| 未設定 | 3.29658 MB/sec | 1222.288 ms |
| barrier=0 | 106.397 MB/sec | 841.859 ms |
| barrier=1 | 3.29504 MB/sec | 1100.531 ms |
体感と一致するありえないぐらいの遅さが数字に出ていた。3MB/sって光回線より遅いよ...
barrier=1がいつでもここまでインパクトを与えるかというとそうではなく、ずっと使っているノートPCのSSD(Crucial C300-CTFDDAC128M)では以下の通り。
| Throughput | max_latency | |
|---|---|---|
| 未設定 | 118.525 MB/sec | 52.287 ms |
| barrier=0 | 144.024 MB/sec | 29.145 ms |
| barrier=1 | 118.909 MB/sec | 44.737 ms |
確かに遅くはあるのだけど、桁が変わるほどではない。max_latencyを見ると、さっきのSSDは投げ捨てろって感じだけどね...
ついでなので、SSDにTRIMコマンドを発行するようになる「discard」オプションをつけて測ってみたが、特に変化はない様子。
結局
上記の結果と、たいして重要なデータを置いていない作業用PCだということを踏まえて「barrier=0,discard」を/etc/fstabにマウントオプションとして追記することにした。大事なデータを扱っている機械なら、こんな個体に当たったら使うのをやめるべきと思う。
2014-09-04
localhostへのリンクがFiddler経由になるようレスポンスを書き換える(スマホ開発用)
iPhone から開発マシンの localhost にアクセスする(Windows)のようにFiddlerの設定を変更し、「Allow remote computers to connect」をオンにすることで、iPhoneやAndroidのスマートフォンから開発者のPCにアクセスしてデバッグできるようになる。しかし、HTML内のURLにlocalhostや127.0.0.1が含まれている場合があり、そのリソースにはアクセスできない。
そんなときは、FiddlerでResponse bodyを置き換えることで、アクセスすることができる。
RulesメニューのCustomize Rulesから編集できるCustomRules.jsのOnBeforeResponse関数に以下を記述する。
もっと書き換えるべきヘッダがあったり、書き換えすぎちゃうものがあったりするかもしれないけど、そのとき適宜スクリプト書き換える方向で。
参考:Modifying a Request or Response
そんなときは、FiddlerでResponse bodyを置き換えることで、アクセスすることができる。
RulesメニューのCustomize Rulesから編集できるCustomRules.jsのOnBeforeResponse関数に以下を記述する。
もっと書き換えるべきヘッダがあったり、書き換えすぎちゃうものがあったりするかもしれないけど、そのとき適宜スクリプト書き換える方向で。
参考:Modifying a Request or Response
2014-08-29
LXDE (Lubuntu) でマルチディスプレイ設定を維持する
Lubuntu (LXDE) でのマルチディスプレイ設定画面を探したのだけど見つからなかったので、やりかたを書いておく。XubuntuやGNOMEだと画面があるのだけど。
まず、xrandr -qでモニタの一覧を出す。
モニタの名前がわかったら、--outputと--right-ofや--left-ofを使って、モニタの位置を指示する。
このあたりの操作は、ArandrというXrandrコマンドのフロントエンドがあるらしいので、Arandrを使うとGUIでできるのだと思うが、後述の自動起動のためにコマンドで行っておく。
参考:https://help.ubuntu.com/community/Lubuntu/MultiDisplay
上記のxrandrコマンドによる設定は、そのセッション限定なので、Xを使うたびに設定する必要がある。ただ、それは面倒なので、自動起動することにする。
~/.config/autostart/ に.desktopファイルを置くと、Xセッション起動時に自動起動が走るので、これを活用する。
具体的には、~/.config/autostart/multidisplay.desktopファイルとして、以下の内容を記述する。
参考:Autostarting (日本語) - ArchWiki
これで自動でマルチディスプレイ設定が毎回行われるようになる。
そのセッション限定でマルチディスプレイ設定を行う
LXDEに限った話ではないが、xrandrコマンドを使うとマルチディスプレイの設定ができるので、このコマンドで設定できる。まず、xrandr -qでモニタの一覧を出す。
$ xrandr -q Screen 0: minimum 64 x 64, current 3840 x 1080, maximum 16384 x 16384 VBOX0 connected 1920x1080+0+0 0mm x 0mm 1920x1080 60.0*+ 1440x1050 60.0 1280x960 60.0 1024x768 60.0 800x600 60.0 640x480 60.0 VBOX1 connected 1920x1080+1920+0 0mm x 0mm 1920x1080 60.0*+ 1440x1050 60.0 1280x960 60.0 1024x768 60.0 800x600 60.0 640x480 60.0
モニタの名前がわかったら、--outputと--right-ofや--left-ofを使って、モニタの位置を指示する。
xrandr --output VBOX1 --right-of VBOX0
このあたりの操作は、ArandrというXrandrコマンドのフロントエンドがあるらしいので、Arandrを使うとGUIでできるのだと思うが、後述の自動起動のためにコマンドで行っておく。
参考:https://help.ubuntu.com/community/Lubuntu/MultiDisplay
マルチディスプレイ設定を維持する
上記のxrandrコマンドによる設定は、そのセッション限定なので、Xを使うたびに設定する必要がある。ただ、それは面倒なので、自動起動することにする。
~/.config/autostart/ に.desktopファイルを置くと、Xセッション起動時に自動起動が走るので、これを活用する。
具体的には、~/.config/autostart/multidisplay.desktopファイルとして、以下の内容を記述する。
[Desktop Entry] Name=multidisplay Exec=xrandr --output VBOX1 --right-of VBOX0 Type=Application
参考:Autostarting (日本語) - ArchWiki
これで自動でマルチディスプレイ設定が毎回行われるようになる。
登録:
投稿 (Atom)




