Twitterの勉強会に行ってきた話
以前から一度行ってみたかったTwitterの勉強会に初参加してきました。
参加目的は漠然と、勉強会の雰囲気を感じることと、人と交流することです。もちろん技術的なお話を聞けるのも楽しみにしていました。
今後は、Twitterに限らず色々な勉強会に参加してみようと思っているので、まずは第一弾、といったところです。
Twitter 勉強会 #twtr_hack @デジタルハリウッド東京本校(@dh_tokyo)
詳細や当日資料は、主催者の@yusukeyさんのサイトに纏めてあるのでご覧いただければ。
全ビデオ、スライドがそろいました - 8月1日 Twitter 勉強会を開催しました #twtr_hack - 侍ズム #samuraism http://t.co/hx7HfN7S
— 山本裕介(きのこの山派) (@yusuke) August 3, 2012
会場のWifi環境は快適でした。さすがデジハリさんです。こうですかわかりまｓ
講演内容ですが、giftee（RoR）、Twitter利用統計、ATTACCA（iOS TwitterFramework）、チャーハン諸島（Java）と普段触れることのない技術に触れられて、「私も何か作ってみようか」と思うほど刺激になりました。
会場は、皆さんTwitterという同じものに興味を抱いているので、一体感というか仲間意識みたいなものが感じられて心地よかったです。今後の勉強会参加のハードルも下がった気がします。
忙しそうな山本さんのところに押しかけて挨拶だけして来ました。今度ゆっくりお話してみたいです。生Mocel氏は拝めましたが、残念ながら見失ってしまってお話は出来ませんでした。こちらもまたいつか。自宅が遠方のため懇親会には参加できませんでしたが、次は参加しようと思います。
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では問題なく使えました。よって、これで運用しようと思います。
