2010年01月21日

僕の撮影環境とFiciaの事について

今年に入ってから単純に僕の使ってるカメラのアフィブログ書こうと思ってたらこんなタイミングになった。とは言っても撮影テクニックやら詳しい事は良くわかってナインすが。。。
せっかくえとらぼ、写真ストレージサービス「Ficia」の追加容量を値下げ:ニュース - CNET Japanという感じで料金が1/10になって動画が上げられるようになったんでFiciaの事もまとめて書こうとおもう。

前座

今日は二本立てなんだけど、その前にみて物足りない所を。

どんだけ使ってるか

何かある度に写真取りまくってて動画対応される前までは15GBくらい溜まってたんですが動画対応始まってから20GB一気に越えてる感じです。枚数は9000枚くらい。
昔のは電源入れてないサーバとかに入ってて引っ張り出すのめんどいので入れてません><
ちなみにFiciaに同期したら全部消してるので特にバックアップとってない。
ちなみにボスは数万くらい入れてるとか言ってた気がする。

リミッターが付いたよ!

利用料金が90%安くなって月々315円で100GB使えるというのも大きいですが、もう一つ目立たない所で利用出来るストレージにリミッターが付いた所ですね。

どういう事かと言うと、今までは利用した容量に見合うだけの料金が請求されていました。うっかりCドライブの中身を全部アップロードしてしまって削除し忘れたら、その分だけ料金請求されてたんですね。
それが今日から予め選択した容量を越えるファイルをアップロードが出来なくなるというリミッターが付いた感じなんです。
最初は決済登録されてなくて2GB未満使える無料プランになってるので、お試しだけしたい人でもうっかり2GBを越えてしまう事無くお試し出来ると思います。

いくら全部上げが売りだからと言っても「うっかり全部上げて想定外の利用料金が発生してしまうようでは恐くて使えないよ!」という意見も聞いていたんですが、今日からは利用料金大幅値下げとあわせて自分の意図しない料金が請求されないようになったので、ゆったりと全部上げライフが堪能出来るんじゃないかと思います。

サービス内容が安全側になったという事でしょうか。

プライバシー的なあれ

Ficiaはストレージサービスです。ストレージサービスである以上はアップロードされたファイルは常に非公開になっているべきです。なので、Ficiaにファイルを上げた直後は必ず非公開設定になってPublicにしたかったり特定の人に共有したい場合は共有アルバムに入れるまでは非公開になっています。
このへんは、利便性を考えて特定の方法でアップロードしたらtweetする的な事が出来るようになったりするかもしれないんですが、基本のポリシーはうっかり大事なデータを公開してしまわない配慮をするといった事があると思ってるので、うまく辻褄合うようになるんだと思います。

このへんも安全側に倒れるようにという強い思いはある所です。

写真撮影環境

デジタル一眼レフカメラ

僕はコンパクトデジタルカメラとデジタル一眼レフカメラの二通り持っていて、デジイチのほうはだいぶ前に Canon EOS KISS デジタル N を買いました。
ちなみに2台目に買ったシンセサイザーはEOS B700です。

Canon EOS KISS デジタル N ブラック Wズームキット 0208A004
キヤノン (2005-03-17)
売り上げランキング: 82835
おすすめ度の平均: 4.5
5 思い切って大正解!
4 きっかけとしては満足です。
4 良いんですが
4 価格対満足度はGood!
5 カメラ初心者でも簡単に使えます

僕は全くもって撮影技術が無いのでスペックとか関係無い感じですが、レンズさんのおかげで足りないテクニックを補正してもらってると思っています。

で、レンズなんですが去年の年末くらいに買った単焦点レンズを猿のように使っています。なんか道具の力で上手に撮れてる気がするので気に入ってます。

Canon EFレンズ 35mm F2
Canon EFレンズ 35mm F2
posted with amazlet at 10.01.20
キヤノン
売り上げランキング: 5249
おすすめ度の平均: 4.5
5 スナップ用に最適
5 良い!
4 多い日でも安心♪夜用。
4 3本目のレンズのはずがメインレンズに。
4 記録用として満足

よくわかってないけどF2というだけあって明るいレンズなので、この本体だけでも先日のふたご座流星群の写真とか撮れました。シャッターは30秒しか空けられないのに。

ふたご座流星群 - やっぽてぃ Ficia Photo ふたご座流星群 - やっぽてぃ Ficia Photo

あとは、暗い所でもフラッシュ焚かなくても撮れるのとかがいいです。個人的にフラッシュ嫌いなんで。プロの人を見てると室内だとばしばし焚いてるんでちゃんとした使い方覚えればいいんでしょうが。

やっぽてぃ Ficia Photo

ただ、50mm固定なんでちょっと離れて撮影しなきゃいけないのがいやんな感じです。。。

もういっこは最初に買ったズームレンズです。

Canon EF 90-300mm F4.5-5.6 USM
キヤノン
売り上げランキング: 115230
おすすめ度の平均: 5.0
5 純正ズームレンズで低価格

望遠レンズだと一番安かった気がしたんだけど、皆既月食やらご来光くらいは撮影出来るので良い買い物したなーと思ったですね。

元旦の皆既月食 - やっぽてぃ Ficia Photo ご来光 - やっぽてぃ Ficia Photo

後は高尾山から富士山撮るのも丁度良かった。

やっぽてぃ Ficia Photo

あと、ごく普通の標準レンズもあるけど割愛。

コンパクトデジタルカメラ

普段持ち歩き用です。

CASIO デジタルカメラ EXILIM EX-Z400 ゴールド EX-Z400GD
カシオ (2009-01-23)
売り上げランキング: 34253
おすすめ度の平均: 5.0
5 デジカメなんてどれも同じ・・・ではありませんでした!
5 メイクアップモードが楽しい
5 ベストショットモードが良い感じ。夜景+人物も良く撮れた。
5 車載に最適

普通の写真の上に動画を合成して撮影できるとかいう売りがあったのですが、あんまり面白い使い方が解らなくてスナップ写真くらいにしか使ってないす。
最近のカメラは設定とか適当でもそれなりに奇麗に撮れるのが嬉しいすね!

やっぽてぃ Ficia Photo やっぽてぃ Ficia Photo

最近はFiciaでも動画対応が始まったので、ごっそりアップロードもしてます。
最近のカメラは動画も大概奇麗に撮れるので普通のビデオカメラとか出番が少なくなってます。

やっぽてぃ Ficia Movie
やっぽてぃ Ficia Movie

ちなみに最初はEye-Fiを差してたんですが、いつの間にか接触が悪くなって手で強く押し込まないとカメラが認識してくれなくなったので最近使ってません。
8GB Eye-Fi Pro X2 速く欲しいんです!

携帯

携帯のカメラももちろん使ってるんですが割愛

Ficiaの事

主に外部的要因な事を個人的に出来たら良いなーと思ってる事。

YAPC::Asia 2009 画像関連サービス BOF を芝生でやってた時に「livedoor PICS」も「30days Album™」も競合じゃなくて共存する関係にあるんだよ的な事を話していたのですが、究極的にはFiciaから写真選んで30days Album™でシェアリングする、PICSに上げてそっからlivedoor Blogで画像使う、はてなフォトライフ(ry(日本のサービスだけ列挙したけど)とか出来る世の中になるといいなーと思っとります。

Ficiaはただのストレージなので、ミクシィやグリーやモバゲーなどで既にソーシャルグラフがあるのならソーシャルグラフを有効に使ったシェアリングは各サービスに任せてFiciaは大元のデータの管理のみに努めるとみんなenjoyしやすいと思う所存。

もちろん動画データも溜めてるので、ニコニコ動画,YouTubeなどにも簡単にoutputできるようにすべきでしょう。

ただ外部サービスに出すだけじゃ駄目で、どのようなデバイスからもデータを集めなきゃいけないですね。Eye-Fi, iPhone, ケータイ, CEREVO CAM, etc...

最近Eye-Fiカード壊れたので、コンパクトカメラも一眼レフもMac or Win 専用クライアントで勝手に同期される生活なんですが、よりもっとカメラに近い所で同期される生活になりたいすね。
ちなみにEye-Fiは野良Eye-Fiサーバ立ててメールでFiciaに送ると言う(ry
Ficiaは動画も対応したのでEye-Fi VIDEOで同期出来るようになると超嬉しい。

Ficiaをハードディスクの延長デバイスという利用が出来るようになった上で、新しい価値観が作れれば良いなと個人的に思ってる。

もちろん、Ficia本体のインターフェィスにも全く持って満足してないのでブラッシュアップしなきゃいけません!

外部API

なんだかんだで欲しいと思ってるけど、oEmbedぐらいなら外部から作れるから野良で作ろうかしら。とか今思った。
Echofon でも対応して欲しいなーと思ってる。

まとめ

今日は、僕のカメラ関連の環境について紹介する事とEOS B700ユーザのカミングアウトを行いました。

で、なんだかんだ僕の持ってるデジカメの事調べてたらKiss X3が欲しくなったんだけど(5万くらいで売ってる)、tsukimiyaさんからエントリー→エントリーはそこまで感動しないと教えてもらって50D(9万くらい)をおすすめされたので調べてたら7D(13万もする。。。)が欲しくなってきた。

なんか最近のはSDカードさしてフルHDで動画撮れるとか書いてあってすごい!
一眼レフで動画撮りたいとか言ってたらDISられるかと思ってたけどそうでもないらしく、よく考えたら一眼レフのレンズじゃないと撮れないような動画とか撮影出来るのかと思った。
とりあえずレンズはあるから本体だけ買えばいいと思ってる。

Canon デジタル一眼レフカメラ EOS 7D ボディ EOS7D
キヤノン (2009-10-02)
売り上げランキング: 1109
おすすめ度の平均: 5.0
5 キャノンEOS-7Dカメラについて
5 AF性能が抜群に良くなった
5 いい感じです♪
5 私個人としましては鉄道写真撮影用カメラの決定版です。
4 動画撮影は最高!

という事で EOS 7D と 8GB Eye-Fi Pro X2 が欲しいです!
あと CEREVO CAM も欲しいです!

Posted by Yappo at 00:27 | Comments (0) | TrackBack

2010年01月18日

kumofs での Data::Model の使い方

スケート頑張りすぎて足首が痛いYappoですみなさまウインタースポーチュしてますか?

本日kumofsが公開されたので、折角なので Data::Model から kumofs を実際にどうつかっているかを紹介しようかとおもいます。

kumofs については 分散Key-Valueストア「kumofs」を公開しました! - 古橋貞之の日記 を Data::Model::Driver::Memcached については dann さんによる Data::Model::Driver::Memcachedで超効率データ保存 - JPerl Advent Calendar 2009 を別途参照すると良いでしょう。

スキーマ定義

では実際に kumofs をつかった場合のスキーマ定義を下記に貼ります。
ちなみに、それらしいような定義をしてますが全部フィクションです。本当に。

解説 その1

Data::Model::Driver::Memcached のインスタンスを作る所で、 Cache::Memcached::Fast のインスタンスを指定する所で、3つのオプションを渡しています。

一つ目が、 serializer => 'Default', で、 Cache::Memcached 標準の直列化手段をつかわずに Data::Model::Driver::Memcached 標準の直列化手段を利用します。
即ち MessagePack を使った直列化を施します。 Data::Model で必要な MessagePack のコードは Pure Perl で内部的に実装されているのですが、実用的にするには Data::MessagePack をインストールしておくと、そっちを使って高速に直列化してくれます。

二つ目は、strip_keys => 1, です。
通常の方法だと、 primary key も KVS の Value として直列化してストレージに格納しようとするのですが、 KVS だったら既に Key のほうに値が入っているべきで、この重複が無駄なので削除して直列化します。
例えば、上記のコードを使った場合に以下のようなデータ構造だった場合に

{
    file_id    => 'dankogai',
    media_type  => 1,
    client_type => 5,
    is_broken   => undef,
},
file_id の項目を delete して、下記のような構造にしてから直列化します。
{
    media_type  => 1,
    client_type => 5,
    is_broken   => undef,
},

三つ目としては ignore_undef_value です。
これは何をする物かと言うと、カラムの値が undef だった場合は、その項目を DELETE してから直列化します。
そして lookup などで kumofs から Data::Model の Row オブジェクトに戻す時点で、直列化されてるデータにカラムのデータが無ければ value が undef だったと解釈をして復元するのです。
今回の例では、画像が壊れてた時だけ kumofs のストレージサイズが増加します。
上ので書いたデータ例に適用すると下記の用に is_broken が削除されて kumofs に格納されます。

{
    media_type  => 1,
    client_type => 5,
},

ユースケースとしては、稀にフラグを立てる必要があるんだけど、フラグ立って無いレコードに対してもディスク容量を消費するのが嫌だ!という時に使えます。
SQL だと、別途 file_broken 的なテーブルを作って JOIN すれば済む話でしょう。
あいにく kumofs では JOIN 出来ないので、このような時は別の Key-value にデータを突っ込まないといけません。
そうすると GET する時のクエリの数が倍になったりするのでトレードオフしてどっちにするか選ばなきゃいけなくなるんですが、 ignore_undef_value を使っとけば、必要な時に必要なだけストレージを使いつつ GET する時のクエリ数も増えないので良い感じになるんです。

細かいこと言うと SQL で別テーブル使って JOIN するよりかは空間効率やらなんやらは良いと思うすけど。特に比較検証してないんでこれ以上はやめとくす。

解説 その2

今度は model 定義部分をみてみましょう。ポイントは二つあります。

一つ目は schema_options model_name_realname => 'f_m'; です。
これは、 memcached protocol の key の所に入れる model namespace を短縮するのに使います。
例えば key=file_id が 'dankogai' だとして、 schema_options model_name_realname が指定されてない場合は、このコード例では

kumofsfile_meta:dankogai
という key で kumofs に SET します。
そして、今回の例の schema_options model_name_realname を使うと
kumofsf_m:dankogai
と短縮された key になります。

二つ目は schema_options column_name_rename の所です。
これは直列化する直前で Key を任意の値に変換してから直列化をかけます。
Data::Model 標準のシリアライザの MessagePack では、数値をとても効率よく直列化してくれるので、 media_type だとかいう長ったらしい key name を 2 とか言う数値に変換してしまいます。
2 とかという小さい値だと直列化後も1バイトしか容量食わなくて嬉しいんです!

実際、上のほうで書いてるデータ例だと以下の用になります。

{
    2 => 1,
    3 => 5,
},
とんでもなく圧縮出来ている事がお分かり頂けますか。

MessagePack の specをみても解るとおり、15要素以下の HASH に1バイト、 7bit 以下の unsigned int では1バイトの容量しかかからないので、上記の圧縮後の value は5バイトという驚異的なサイズとなって kumofs の value に格納されます。

まとめ

今日は kumofs 公開したということで、 Data::Model からだったらどう使えるか、どう使うかという視点で書いてみました。
Data::Model 側で用意してるオプションを使い切る事により、プログラムコードは書き易く、かつ空間効率を驚異的に高めて利用出来る事が解ったかと思います。
もちろん Data::Model::Driver::Mecached は kumofs 専用という訳でなく Tokyo Tyrant やらなんやらでも利用できますので、機会があればお試しください。

まぁ、もちろんこんなレイヤ介さずに直接使えばいいって話も出てきそうですがね。

あわせて読みたい:YappoLogs: KVSでORマッパーを使うという事

Posted by Yappo at 12:31 | Comments (0) | TrackBack

2010年01月09日

Mooseを使うべきでない理由とMooseを使う理由

twitterにでも書いて終りにしようと思ったけど140文字じゃ無理なんで。
Mooseの欠点やら利点やらMouseがどうだとかは今更感過ぎて割愛するし、下手な抽象的な表現も面倒なんでしない。

Mooseを使うべきでない理由

あなたが、再利用性の高いライブラリを作りたい場合はMooseを使うべきではない。
なぜならMooseはフレームワークだからであるからだ。
たとえ有用な再利用性の高いライブラリを作ったとしても、Mooseというフレームワークに依存してしまっては、あなたの有用なライブラリを選択してもらえない事もあるだろう。
誰かが小さいスクリプトを書くために、あなたが書いた有用なライブラリを使う事で楽が出来るとする、だがMooseというフレームワークに依存したばっかりに、その有用なライブラリの後ろに控えるものの大きさに臆して選択してくれないかもしれない。

もちろんMooseを使わなければ生産性が格段に落ちるだろう。メンテナンスも大変になるだろう。Mooseを使わないことによるペナルティの代わりに誰からも利用されるライブラリの作者になれると言うことだ。素敵だろ。

Mooseを使う理由

じゃぁCPANへ上げるライブラリはMooseを使うなってことか?いいや違う。
何度も言うがMooseは生産性を恐ろしく高める、だがしかし再利用性の高いライブラリでは使うべきでないと言っただけだ。
例えば App::* 名前空間のコードでは積極的に使っても良いだろう、Catalystだってそうだ。
え?Catalystは再利用性の高いライブラリじゃないか!だって?いいや、Catalystはとても有用なフレームワークだ。Catalystの中だけで世界が閉じているのだ。

総論

そう、Mooseを使う場面と使わない場面と言うのは、書こうとしているコードがそのコードの世界で閉じたものなのか、または閉じないものなのか。そういった基準を見るという視点があると良いのではないだろうか。
例えばDBICなんかは閉じた世界でないのでMooseに依存するべきでは無い。
たとえばDBI.pmがMooseに依存してたらどうする?
HTTP::Engineは?うーん微妙だ。
Plack何かは閉じた世界では無いので使うべきでは無い。
じゃぁFeyはどうだ、、、、うーんMooseをたくさん使うという世界に閉じた中で使うと言う点ではありなんじゃないか?

繰り返すがMooseを使わないべきとは言っていない。良く考えて使うべきだと言っているのだ。

Posted by Yappo at 01:07 | Comments (0) | TrackBack

2010年01月05日

Plack::Middleware::Debug のアイコンをどかす Middleware

Plack処女喪失したての金曜日の天使ですおげんきですか。

Plack::Middleware::Debug を使って Debug のメニューを消したときって

みたくなってなんか邪魔なので、端っこにどかすCSSを適用するMiddleware書いてみた。

やりたい事としては、アプリとは関係ないファイルの管理をしないで PM::Debug のcssだけを置換して使いたいって事。
Plack::Middleware::Debug は、必要なjsやらcssをshareディレクトリ以下に入れて自分の好きなように書き換えて使えるんですが、それやるとアプリ以外にファイル管理しなきゃいけないので面倒なのでやりたくないというワケ。

上のコードを app.psgi に入れとくと

な感じになってくれました。
とりあえず目的は達成。

この

builder{
    enable {
        my $app = shift;
        sub { $app->(@_) };
    };
    sub {};
};
するような使い方ってMiddlewareって呼んでもいいものなかしら?
< miyagawa> middleware でいいですよ
との事。

Posted by Yappo at 15:26 | Comments (0) | TrackBack