月別アーカイブ: 2014年7月

Macでバッチファイル的なものを作成する

仕事上、Windowsのbatファイルを作成することがよくある。
パソコンをまともに触るまではコマンドラインすら使いもしなかったが、
意外といろんな操作を自動化できて楽しい。
で、batファイル的なものをMacでも作ろうかと思ったが、意外と落とし穴があったのでメモ。

  1. シェルスクリプトで実行内容をテキストに記述
    以下の様なスクリプトを任意のテキストエディタで記述する。

    このとき、改行コードをUNIX(LF)にする。
    そのため、テキストエディタは何でも良いが、改行コードを設定できることにすること。
    記述したら、このファイルの拡張子を”.command”として保存する。
  2. ターミナルからコマンドファイルの実行権限を付ける
    上記のファイルをそのまま実行しようとしても、「適切なアクセス権限がないため実行できません。」となり、実行できません。
    そこで、ファイルを実行できるようにアクセス権を設定します。

    1. ターミナルを開き、先ほど作成したファイルを保存したディレクトリに移動する。
    2. 以下のコマンドを実行し、実行権限を付ける。

後は.commandファイルを実行するだけでターミナルが開かれ、記述した操作内容が実行される。
実行後、ターミナル画面がそのまま残ると味が悪いので、終了後画面が閉じるようにターミナルを設定すると良い。

  1. ターミナルから、「ターミナル」→「環境設定」を開く
  2. 「設定」→「シェル」タブで、「シェルの終了時」を「シェルが正常に終了した場合は閉じる」にする

以上。
僕はC#で作ったファイル整理系コンソールアプリをmonoで実行させるのによく使っています。
コマンド内容は以下の通り。

来月には帰国できる・・・はず。

C#でEvernoteアプリを作る

Evernoteは言わずとしてたクラウドメモツールだ。
使い道は人それぞれだが、僕はwebクリップでプログラミング関連のページを保存したり、
2chで面白いと思ったスレやレスを保存したり、
画像スレの画像をページごと保存したり、
ロクでもない使い方をしている。
で、EvernoteはAPIを公開しており、これを使えば誰でもEvernote関連アプリケーションが作成できる。
C#でも公開されており、C#しか使わない僕にも使えた。
テキスト投稿アプリならすぐに作れてしまう程分かりやすい仕組みになっている。
何より日本語化されているのがいい。リファレンスは英語だけど。
備忘の為、0からの使い方を以下にまとめた。

  1. Developer登録をする
    1. https://dev.evernote.com/intl/jp/に行き、「APIを使いはじめる」をクリックする。
    2. APIドキュメントのページが表示されるので、「APIキーを取得」をクリックする。
    3. 申し込みフォームが表示されるので、必要事項を入力する。
      (API権限は作りたいアプリ種類によって選択する。投稿アプリならベーシックアクセスでいいし、既存Noteの編集を行うならフルアクセスが必要。
      とりあえず試すだけならフルアクセスにしておけばいいと思う)
    4. コンシューマーキーとコンシューマーシークレットが発行されるので、メモしておく。

  2. SDKを取得する
    1. APIドキュメントでC#の「SDKをインストール」をクリックする。
    2. Githubのページがでてくるので、右下の「Download ZIP」をクリックし、ソースコードを取得する。
      (勿論クローンでもいいです。お好きな方で)

  3. EvernoteSandbox(開発環境)のアカウントを取得する
    1. EvernoteのAPIはいきなり通常のアカウントに対しては使えず、
      まず開発環境内で動作検証をして、OKだと思ったら本番環境での使用許可を得る、という形になっています。
      開発環境はEvernote社が提供しているので、そのアカウントを取得します。
    2. https://sandbox.evernote.com/で「アカウントを作成」する。
      以下、手順にしたがってアカウントを作成してください。
      このときのアカウントとパスワードは自分のEvernoteアカウントとは全く無関係なものでOKです。

  4. デベロッパトークンを取得する
    1. いちいち自分の環境に対してユーザーIDとパスワードを入力して認証するのは
      面倒ですが、デベロッパトークンを用いることでその作業を省略できます。
    2. ここのページ中段の「サンドボックス用のデベロッパトークンを取得」をクリックする。
    3. 先程取得したSandboxのアカウントとパスワードを入力する。
    4. 「Creat a developer token」とクリックし、表示されたデベロッパトークンをメモする。

  5. Sampleアプリを動かしてみる
    1. 2でダウンロードしたSDKをZIPなら展開し、sample→client内のEvernote.slnをVisualStudioで開く。
    2. SampleAppプロジェクト内のEDAMTest.csを開く。これがサンプルアプリのコードです。
    3. 40行あたりにauthTokenが定義されているので、先程取得したデベロッパトークンに設定してください。
    4. VisualStudio上で実行してください。上手く実行されればsandbox環境内に新規ノートが作成されます。

後はソースを眺めてAPIの仕組みを大まかに把握し、色々変更してみたりして弄ってみてください。
なお、自分のアプリでAPIを利用する場合は、EDAMプロジェクトをビルドしてできた「Evernote.dll」と「Thrift.dll」をコピーし、アプリのプロジェクトのの参照設定に追加してください。
細かい使い方やリファレンスは他のページにまとまっていますので、そちらを参照したほうが良いと思います。
ちなみに、地味に躓くのが認証する所だと思います。
僕は下記のソースを参考にしています。
参考というか、利用させてもらっています。
MITライセンスだからね。本当に感謝しています。
https://github.com/matchy2/EvernoteOAuth
Sandbox上の検証が十分に完了したら、プロダクション用のデベロッパトークンを使って自分の本アカウントEvernoteに使ってもいいし、アクティベートしてコンシューマーキーをプロダクト環境で利用可能にして、一般公開してもいいと思う。
僕が作ったAppも一応このサイトに置いてあります。
クソコードなので中身はあまり見せられません。

InvokeでFormをCloseして、その後すぐに同じFormインスタンスを生成するときの注意点

タイトルが長くなった。
ちなみに検証できないので内容的に間違っているかもしれません。
解決方法も最善解ではないです。
完全に自分の覚え書き用の記事です。

おおまかに言うと、上記のようなコードを実装していた。
InvokeしてるのはこのメソッドがUIスレッドでない別スレッドで実行されるからです。
簡単に言うと「今表示されているSampleFormを閉じて、初期化して再度表示する」という実行内容。

で、これがいざ実行するとハングすることがある。
困ったのは、100%でなく、起こったり起こらなかったりするところである。

form.Show()の直前でブレイクしてデバッグすると、どうやらここでformがDisposeされていることがあるということが分かった。
しかし、// (中略2)や// (中略3)のどこにもformをDisposeする要素がない。
より詳細に見ようと、// (中略2)にブレイクポイントを置いてデバッグしたところ、問題が一切発生しなくなった。

しばらく頭を捻っていたが、ようやく尤もらしい仮説が見つかった。

InvokeされたCloseによるDispose処理が、「form=new SampleForm()」後に実行され、
折角初期化したformがDisposeされてしまった。

シナリオはこうだ。

1)(処理スレッド)CloseをUIスレッドに託す
2)(UIスレッド)formをCloseする
3)(処理スレッド)処理スレッドformを初期化する
4)(UIスレッド)Closeしたことだし、formをDisposeする
5)(処理スレッド)formをShowする
↓
formはDisposeされてるから無理ですよ〜だ。

4が3と5の間に起こると本件が発生する。
そのタイミングは環境の状態によるので、問題が発生したりしなかったりした訳だ。

で、以下のように1行追加して問題は発生しなくなった。

一度たまっている処理(Close含む、ってか多分Closeしかない)を全て実行させればいいのだ。
Mutexを使う等して排他制御をした方が正確だが、バグの温床に成りかねないのでこの方法にした。
ちょっと不安ではあるけど、これで問題なさそうならこれで行こうと思う。

昔「おまじないだ」と言われたApplication.DoEvents()を使うことになるとはなぁ。
ネットで調べたらあまり勧められない方法らしいけど、そこまで必死に直す箇所じゃないからね。仕方ないね。

DataViewでRowFilterを設定する場合の注意点

DataViewはDataTableと似たようなクラスだが、
インスタンス生成時に既にインデックスを貼ってくれていたり、
まぁ色んな違いがある（投げやり）。

で、最近いじっていたあるコードがある。

DataViewにRowFilterを設定し、その後の処理結果によってまた同じ操作を繰り返すというものだ。
（実際のコード上は無限ループにならないようになっています。念のため）
これがやけに時間がかかる。
原因はRowFilterがRowFilterを何度も行ったことだった。

なぜなら理由は単純で、RowFilterが実行された場合、DataViewは内部的にインデックスを設定してしまっているのだ。
インデックスを設定するために毎回全データを取得しに行っているわけで、これでは大変時間がかかる。

で、幸い「// (dvを使った実行内容)」の内容をRowFilterでなく、FindRowsに置き換えることが可能だったので、それでひとまず解決した。
FindRowsメソッドはインデックスを再設定しないのだ。
（参考：http://msdn.microsoft.com/ja-jp/library/bb669089(v=vs.110).aspx）

RowFilterで遅くなっている可能性を全く考えておらず、分かるのに時間がかかった。
ぱっと見、プロパティ設定してるだけに見えるからね、仕方ないね。

・・・修正したはいいけど、割と条件分岐が複雑なメソッドなので、テストに時間かかりそう。
（現に実装終わった後にバグを指摘されまくった）