FlickUpperでAPIの非同期パラメータ追加
Flickrのアップロード用APIに非同期のものが用意されているので見てみたら、単に同期アップロードのAPIにasync=1を追加指定するだけだった。
これを指定すると非同期通信になるのかというとそんなことはなくて、アップロードが終わるとさっさと応答を返してくれるようになる。サーバー側の後処理を待たされなくなるので、無通信時間を減らすことが出来る。
これで並列処理せずに順次処理しても、まぁまぁ効率的になるかな、と。
ということで、FlickUpperを再度更新。これでほぼ問題ないと思う。
https://dl.dropbox.com/u/261733/FlickUpper.zip
2012/06/26 zipに通信用のライブラリDLLが同梱されてなかったので差し替えました。
あとやるとしたら、順次処理・並列処理を切り替えできるようにするぐらい。これは気が向いたら。
OAuth関連のライブラリ作成
FlickUpperの通信部分作成に伴い、主にOAuth関連のロジックが入った通信部分を過去の遺産から取り出して、ライブラリとして独立させて使うことにしました。
バイナリ
色々問題がありそうなので、ソースでの公開は控えることにします。
今のところ自分専用ツールなので、特になんやかんや言われることも無いだろうな、とは思うんですけど。
ライブラリはVB.NETで作成してあります。C#変換は面倒なのでやめました。このライブラリで、Twitter、Flickr、Dropboxには対応出来てます。Google APIもOAuthだった気がしますが、動作確認してません。使う機会があれば拡張なりなんなりすればいいかな、と。
OAuthのライブラリとはいえ、非同期通信をサポートしてなかったり、Webサービスでのoauth_callbackをサポートしてないので、デスクトップ向けがメインです。ちょこっと弄れば使えると思うんですけど、検証環境ないので。あと、.NET Compact Frameworkも環境ないので試してないのですが、多分使えるんじゃないかなー。使えなくても、ちょっと手を入れるだけで済むはずです。
FlickUpperは、初回起動時にエラー吐きまくる問題を直したり、ファイル走査とか状態変更がすごく遅かった問題に対処しました。通信部分のライブラリ差し替えで認証方式が変更になりました。ついでに通信速度は想定通りの速度が出るようになりました。
簡易アップロードアプリFlickUpper公開
Flickr用のアップロードアプリを作ったので公開しました。
概要
特定のフォルダを指定しておき、そこに新しいファイルがあったらまとめてアップロードする、というもの。サブフォルダも対象です。
バイナリ
https://github.com/downloads/kirifeather/FlickUpper/FlickUpper.zip
https://dl.dropbox.com/u/261733/FlickUpper.zip
ソース
https://github.com/kirifeather/FlickUpper
手抜きな点
アップロード時の公開設定やタイトル・Setsなど選べません。私が付けないので。公開範囲は自分のみ、としています。リサイズ機能や回転機能もありません。アップロード済・未はフルパスファイル名でのみ判断しています。サイズとか更新日とか考慮してハッシュでも持てばいいんでしょうけど、そこまでやってませんです。ファイルIDなるものがあるんですが、これも同様保持してません。あと、動画だと特にファイルサイズ上限があるんですけど、それもチェックしてません。アップロード失敗したらリストに残るので、後からチェックしてみて貰えればいいかと。
用途
デジカメや携帯で撮った写真を母艦PCに取り込んだあと、差分となる取り込んだ写真のみをアップロードできます。Flickrの私的用途はバックアップなので、もれなく手間を掛けずにアップロード出来ればOKなのです。よって、Proアカウント推奨。
通信速度
アップロードを並行してやると順序が入れ替わっちゃうので、1つずつアップロードしてます。何か良い手があれば教えてください。
2012/06/14 やっぱり遅いので並行してアップロードするようにしました。通信部分を自前で作ったので、速度的には問題なくなりました。
開発動機
Flickr Schedulrが遅いし重いし不安定だし、ってんで作ったんですけど、アップロード速度については変わりませんでした。Flickr本体側の帯域制限だかなんだかじゃなかろうか、と思っています。
システム要件
動作には.NET Framework 4.0 ClientProfileが必要です。つまり、XP以上ですかね。
自分的にはめずらしくC#で作ったので、結構時間がかかってしまいました。通信部分作るのがダルかったので、Flickr.NETというライブラリを使ってます。いましたが、通信速度が遅かったので自分で作ったものに置き換えました。このライブラリはLGPLとCPLのデュアルライセンスとのこと。ライセンス関係は問題ない、はず。
http://flickrnet.codeplex.com/
ライセンスといえば、FlickUpper自体はBSDで公開してます。したんですけど、色々面倒なのでやめました。要望があれば公開しますけど。ライセンス回りは未だにムズカシイです・・・もっとストレートに、やるべきことを解説しているサイトはないものか・・・
自分用としてはとりあえず満足なんですが、何か要望があれば対応するので連絡ください。
最後に、このソフトを使ったことによって発生した損害は云々なので、自己責任でお願いします。
2012/06/14追記
OSSでのソース公開はやめました。また、OSSライブラリの使用もやめました。
最初に公開したものは初回起動時にエラーが出たりとイマイチだったので色々見直してバイナリでの公開を再開しました。
写真ストレージとしてのFlickr
デジカメを使い始めて随分経ちますが、画像ファイルの保管についてずっと頭を悩ませていました。
保存しておきたいデータというのは色々ありますが、中でも写真は一生、下手すれば後世まで残しておきたいものです。パソコンが故障したぐらいで喪失されてはたまりません。その点ではプリントして残す、というのはかなり信頼性のある手段でした。（嵩張る、劣化する、という問題はありますけど。）
しかしながら、印刷するのは手間と時間とお金がかかるので、出来ればデータで保管したいところ。
保管手段としての印刷を除き、かつパソコンの故障でも影響を受けない保管手段となると、定期的にバックアップをとることになるでしょう。バックアップ先としては、DVDなどのメディアや、外付けHDDになります。
これで万全か？と言われると、DVDなどのメディアは劣化のリスクがあり、保管状態によっては数年で読み出しができなくなる場合があります。これでは数十年の保管は困難です。この回避策として、数年ごとに焼き直しをすれば良いのですが、これを継続するのは自分には無理です。
後は、外付けHDDやNASへのバックアップ。パソコンと外付けHDDの両方にデータがあれば、どちらかが故障してもほとんどの場合データを失うことはないでしょう。ただし、バックアップは時間がかかりますし、写真は増えていく一方なので、最近の高画質化と相まって容量の問題が出てきます。私はそうでもありませんが、よく写真を撮る人だとあっという間にHDDがいっぱいになってしまうでしょう。バックアップデータの中で一番容量を食うのは写真・動画データというのはよくある話です。
故障のリスクなく、容量の心配をせずに済むバックアップ先を（出来ればお安く済むものを）探した所、目についたのがオンラインストレージサービスです。代表的なところでは、古参のDropboxが挙げられます。
パソコンに専用アプリをインストールすれば取り扱いは非常に楽ですし、信頼性もあると思います。複数のパソコンでデータを同期できるメリットのおまけ付き。しかし、問題は容量です。月額料金を払えば容量は増えますが、無制限にはならないので、一生涯のデータを溜めておくには少々不安が残ります。
次に、これもオンラインの写真保管・共有サービスです。日本ではフォト蔵がメジャーですね。これもネックは容量です。その中で唯一、有料ではありますが容量無制限なのがFlickrです。お値段も月額100円、とは行きませんが、年間約25ドルと手頃感があります。
無料での使用ももちろんできますが、月間のアップロード量制限と、写真サイズの制限などがあるので、写真をオリジナルサイズのままバックアップしたい場合は有料のProアカウント契約をすることになります。
現状の私の運用は次のようになっています。
写真・動画撮影：コンパクトデジカメとiPhone
データ管理：パソコンで吸い上げて特定のフォルダへ集約
バックアップ：月一回、外付けHDDへのバックアップ＋Flickrへのアップロード
HDDへのバックアップはWindows7の標準機能でOSイメージに加えて別途写真データをバックアップしています。月一回のスケジュールで行っています。
Flickrへのアップロードは、まだソフトの評価段階ですがFlickr Schedulrを使うことになりそうです。フォルダー監視と定期アップロード機能があるので、手間をかけずにバックアップできるはず。開発も継続的に行われているので、今後不具合が見つかったりFlickr側の仕様変更があった時でも追従してくれると期待しています。欠点としては、少々メモリ食いで重く、さらにアップロード速度が遅いこと。それでも、手間をかけずに忘れずアップロードできる、というメリットと比較すれば問題ないと思っています。
Hyper-VでUbuntu
Ubuntu 10.04 LTSを使っているのですが、これをP2VしてHyper-V 2.0に載せました。（移行手順等は別途書く予定です。）
運用に関するアレヤコレヤを簡素化したいと思っていたのですが、単にHyper-Vに載せただけだとホスト側から管理が出来ません。ハードウェア一元化による効果はありますが、バックアップを考えるとホストからレジュームなどキックできないと運用に耐えません。
ホストから管理するには、Linux Integration Services関係をインストールすれば良いのですが、サポートしているディストリビューションはRHELとCentOSのみとなり、Ubuntuでは使えません。
よくよく調べてみると、GPLv2版のLinux ICsがあり、一部カーネルに取り込まれていることが分かりました。Ubuntu 10.04 LTSのKernel 2.6.32でもモジュールが存在していることが分かったので、どの程度使えるのかテストしてみました。
ネットワークアダプタとの関係やhv_vmbus等のロードの手順については省いて検証結果のみ簡潔に書きます。主目的は、ホストOSでWindowsバックアップを実行し、正常に完了後仮想マシンが復帰することです。
とりあえず、仮想ドライバ関係を読み込ませてWindowsバックアップを実行してみたところ、仮想マシンが保存状態へ移行し、バックアップ完了後に復帰しました。復帰したは良いのですが、操作を受け付けません。topで見てみると、ksoftirqdがCPUを占有している状態になっています。試行錯誤の末、ネットワークをアタッチしていると発生するところまでは分かりましたが、これといった対策は見つかりませんでした。ただ、カーネルのバージョンによってはうまく稼働している、との情報もあるので、いくつかカーネルを差し替えて検証してみました。
Kernel 2.6.32
稼働中にネットワークアダプタのアタッチ・デタッチ：応答停止（kernel panic?）
稼働中に仮想マシンの保存： 復帰後操作できない（ksoftirqd）
Kernel 2.6.39.4
稼働中にネットワークアダプタのアタッチ・デタッチ：応答停止（kernel panic?）
稼働中に仮想マシンの保存： 復帰後操作できない（ksoftirqd）
Kernel 3.2.7
稼働中にネットワークアダプタのアタッチ・デタッチ：問題なし（リンク状態の認識は出来ていない？）
稼働中に仮想マシンの保存： 問題なし
Kernel 3.3-rc4
稼働中にネットワークアダプタのアタッチ・デタッチ：問題なし（リンク状態の認識は出来ていない？）
稼働中に仮想マシンの保存： 問題なし
ということで、2.6系での運用は難しそうです。3.3系はまだRC段階ですがstagingにあった仮想ドライバのほとんどがが標準ドライバに昇格しており、Hyper-V対応だけを見れば運用に耐えられそうです。ただ、安定重視のサーバー環境なので大幅なカーネルバージョンアップは悩ましい所。だからと言って、LTSなので次のバージョンアップで最新カーネルが使われるのかも微妙です。動いたからといってRC版を使うのは論外。
3.2までのChangeLogを追った所、仮想ドライバ関係は3.1と3.2.1で結構手が加えられたようで3.2.7では問題なく使えました。よって、これで運用しようと思います。
Linux Mint 12
相変わらずミドルタワーに収まっているGF9300-D-Eなのですが、ちょっと気紛れにLinux Mint 12をインストールしてみました。
CD/DVDドライブは外付けのUSBなのですが、なぜかブートせず。初っ端で躓きましたが、ブートシーケンスからHDDを外して、自動ブートデバイス検出も無効にしたらようやくブートできました。こんなに面倒じゃなかった気がしたんだけどなぁ。
ようやくインストールまで漕ぎ着けたかと思ったら、ブート中に固まります。原因はWiFiモジュールらしかったので、これを外したところ無事インストール完了しました。（M/BからUSB端子を引っこ抜いた。）
インストール完了後、MENU->システムツール->システム設定->追加のドライバー からNVIDIAのドライバが選択できるのですが、推奨ドライバを入れたらブート中に固まります。面倒なのでOSから再インストールしました。
NVIDIA公式のドライバを入れるのも手なのですがメンテナンスが面倒そうですし、WiFiを使うための対処方法もこれといったものが見つからなかったので常用はやめることにしました。古いバージョンのUbuntuでは問題なく動いたという情報を見かけたのでそのうち対応されるのかもしれませんが、それなら別のDistribution試したほうが早いかもしれないなーという感じ。
せっかく入れたMintの感想ですが、可もなく不可もなく。日本語環境を整えるのも至極簡単ですし、Windowsからの乗り換えでは困ることはなさそうです。逆に、特に目的がなければWindowsのままで良い気がします。
ケースファンの交換で熱対策
メインPCのケースはCF-A8989RD150を使っています。先日起動しなくなりCPUとM/Bを取り替えたのですが、不調に至った原因として熱の影響は大きかったのではないかと思いました。AtomならともかくCore 2 DuoやCore i5でこのケースは無理があるのかもしれません。先日の温度計測では冬場のためとりあえずは問題ありませんでしたが、このまま対策せずにいて、せっかく新調したCPUとM/Bがまた壊れてはたまりません。しかしケースを買い換える余裕はないので、何か方法がないか考えてみました。
- AC電源化して熱源を撤去
- 熱が篭らないようエアフローの改善
AC電源化はうるさいファンともおさらばできるので前々から考えていたのですが、容量150Wは高いのです。この値段ならケース買えちゃいます。ということで却下。
エアフロー改善は大掛かりな工作（ケースに穴を開けたりとか）は無理にしても、ファンの増設や交換であれば8cmの汎用ファンですからミドルタワーのファンを流用できるのですぐに着手できます。
よってエアフローの改善に取り組むこととしました。
現状
現状のエアフローは、横から吸って前後から出す形です。
吸気：サイドパネル通気穴より自然吸気（結構小さい）
排気：リアケースファンとフロント部電源ファンより排気
しかしリアケースファンは全開で回しても壊れているのかと思うぐらい風量が乏く、前面の電源ファンはケースのフロントパネルに向けて排気しているためそのままケース内に拡散しているようです。（フロントパネル下部のスリットから排気できるよう考えられた作りですが、理論通りには行っていない様子。）
つまり、ほとんど排熱出来ていない。思っていたより重症です・・・。
考察
吸気ファンについて
サイドパネル吸気口は小さいので、ファンを付けても意味がなさそう。フロントには電源が鎮座している上、排気しているので無理。また、どちらもケースのスペース的に無理です。ではリアケースファンを吸気に変えるのは？ODD載せてないので、リアから吸気するとそのままケース前面まで流れて詰まってお終いな上、高い所から吸気して低い所から排気するのも無理がありそう。
ということで吸気は諦めます。
排気について
サイドパネル吸気口は上と同じ理由でスペース的にも無理。残るはリアケースファンの強化です。リアファンを風量のあるものに交換し排気を強化＆自然吸気を促進。ただし、あまり風量を上げるとフロントパネルスリットからも吸気してしまい電源の排熱が心配ですが、現状でもあまり上手くいっていないので大丈夫でしょう。
よって、リアケースファンを風量のあるものに交換することにしました。
交換作業
旧PCからケースファンを借用します。フロントとリアの２つあるのでフロントを使用。フロントパネルを外す必要があり少々面倒でした。このファンもケース同様埃まみれで少々ノイズ音がありますが、電源の方がうるさいので気にしないことにします。これはかなり昔に購入したものですが特別なスペックではなく風量もそれなり。メインPCの付属リアファンは2ラインで回転数取れないものだったので、これだけでも交換の意義があります。
交換ついでにケース内の配線処理を微調整。小さいケースは処理が難しいです・・・
最終調整
最後にBIOSからファン回転数の調整をします。使用M/Bは「ASRock Z68M-ITX/HT」で、Lv1～10までの10段階調整に加えターゲット温度を指定することで自動調整が効きます。自動調整は、ターゲット温度以下では指定レベルで動作し、これを超えると温度と比例して回転数が上がって行くようです。まずはLv10にしてみましたが風切り音がして五月蝿い。Lv1だと風量は気持ち程度ですがほぼ無音。この風量でも付属ファンと同程度でしたけど・・・。パーツを長持ちさせるため、なるべく高い回転数で音が気にならないレベルになるよう調整を進め、最終的に回転数Lv7、ターゲット温度を最低の45℃としました。
ついでにCPUファンの設定も見直しました。元々Lv1にしていたものをLv9でターゲット温度45℃に変更。主に電源が五月蝿いためCPUファンの回転数を上げても体感ノイズは変化がなかったためです。ちなみにファンはリテール。
10分のOCCTを何度か回して問題ないことを確認しました。
が、なぜかCPUのクロック数が上がりません。ターボ・ブースト・テクノロジーが効いてない。ターボ・ブースト・テクノロジー・モニターを導入して確認してもやっぱり上がっていない。よくよく調べると、BIOSのCPU RATIO SETTINGがManualになってました。何かの拍子に変更してしまったらしい。Autoに戻したらターボブーストが効きました。
変更前（OCCT 1時間）
CPU 63℃
M/B 43℃
変更後（OCCT 10分）
CPU 56℃
M/B 39℃
測定条件が全然違いますが、一応効果はあったようです。五月蝿くなりましたが。
ちょっとした調整やハードウェアモニタとしてASRock Extream Tuning Utilityを使っていたのですが、間違ってCPU設定を変更してしまったりOSの電源プランが変更されてスリープしなくなったりと少々厄介。安定したらアンインストールしようと考えています。
