Firefox20にしたらハマったこと(Vimperator)
丸一日原因が分からなかったのでメモ。
先日Firefoxが20へバージョンアップしたので更新したところ、VimperatorのプラグインfeedSomeKeys_3が使えない症状が発生しました。
↓<追記 2013/05/17 16:26>
各プラグインで対応が進んでいました。
Firefox21以降では下記の方法では対処出来ません。
こちらをご覧ください。
↑<追記終わり>
ネットを探すも同様の現象は見つからず。半日待っても同様の声が上がってこないので、自分で原因を調べて見ることにしました。
先に、解決方法を書きますが、about:conifgをいじるので自己責任で。
- about:config開く
- javascript.options.xml.chromeを見つけて、trueに変更
- 再起動
これだけ。
↓<追記 2013/04/04 17:27>
本来的にはE4X依存部分を書き換えたほうが良いとのこと。HTMLタグで書いてるところとかね。vimpの各プラグインが対応してくれるかは分からないけど、対応版が出たら、もしくは自分で書き換えたら上の設定は戻したほうが良さそう。Fxの次のバージョンでは設定自体なくなるかもしれないですし。
↑<追記終わり>
以下、手順や参考ページなど。
まずは、vimperatorrcのverbose上げて再起動し、:messagesを見るとsyntax errorでプラグイン読めていないっぽい。頭のPLUGIN_INFOあたりでコケているので手の施しようがない。
自力での解決を諦めてさらにネットを彷徨うと下記を見つけた。
http://code.google.com/p/vimperator-labs/issues/detail?id=820
症状は同じっぽい。対策は「PLUGIN_INFO セクションを削除」とのこと。やってみたけけど、症状悪化するだけだった。よく見ると、
"This is caused by the removal of E4X in Firefox 18."
って書いてある。E4XがFxから削除されたのが原因らしい。そもそもE4Xって何?ってことでさらにネットを彷徨うと下記を見つけた。
http://vimperator.g.hatena.ne.jp/teramako/20120829/1346245324
なるほど。よく分からない。
が、Fxのオプション(about:configの方)を弄ることで切り替えができる・・・かもしれない感じ。なのでやってみた。
上に書かれている
javascript.options.xml.chrome
が存在するか確認。存在したので、trueに変更。再起動。
ちゃんと動くようになりました。
以上
Twitterの勉強会に行ってきた話
以前から一度行ってみたかったTwitterの勉強会に初参加してきました。
参加目的は漠然と、勉強会の雰囲気を感じることと、人と交流することです。もちろん技術的なお話を聞けるのも楽しみにしていました。
今後は、Twitterに限らず色々な勉強会に参加してみようと思っているので、まずは第一弾、といったところです。
Twitter 勉強会 #twtr_hack @デジタルハリウッド東京本校(@dh_tokyo)
詳細や当日資料は、主催者の@yusukeyさんのサイトに纏めてあるのでご覧いただければ。
全ビデオ、スライドがそろいました - 8月1日 Twitter 勉強会を開催しました #twtr_hack - 侍ズム #samuraism http://t.co/hx7HfN7S
— 山本裕介(きのこの山派) (@yusuke) August 3, 2012
会場のWifi環境は快適でした。さすがデジハリさんです。こうですかわかりまs
講演内容ですが、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側の仕様変更があった時でも追従してくれると期待しています。欠点としては、少々メモリ食いで重く、さらにアップロード速度が遅いこと。それでも、手間をかけずに忘れずアップロードできる、というメリットと比較すれば問題ないと思っています。