<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/rss1full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/" xmlns:cc="http://web.resource.org/cc/" xmlns="http://purl.org/rss/1.0/" xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0">

<channel rdf:about="http://blog.yappo.jp/yappo/">
<title>YappoLogs</title>
<link>http://blog.yappo.jp/yappo/</link>
<description><![CDATA[Yappo運営者のメモとか色々<br>
blogって単語は好きぢゃ無いけどスクラッチ代わりに使います。<br>
]]></description>
<dc:language>ja</dc:language>
<dc:creator />
<dc:date>2010-03-09T12:35:04+09:00</dc:date>
<admin:generatorAgent rdf:resource="http://www.movabletype.org/?v=2.661" />


<items>
<rdf:Seq><rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000714.html" />
<rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000713.html" />
<rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000712.html" />
<rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000711.html" />
<rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000710.html" />
<rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000709.html" />
<rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000708.html" />
<rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000707.html" />
<rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000706.html" />
<rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000705.html" />
<rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000704.html" />
<rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000703.html" />
<rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000702.html" />
<rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000701.html" />
<rdf:li rdf:resource="http://blog.yappo.jp/yappo/archives/000700.html" />
</rdf:Seq>
</items>

<atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" type="application/rdf+xml" href="http://feeds.feedburner.com/yappo" /><feedburner:info uri="yappo" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com/" /><feedburner:browserFriendly>This is an XML content feed. It is intended to be viewed in a newsreader or syndicated to another site, subject to copyright and fair use.</feedburner:browserFriendly></channel>

<item rdf:about="http://blog.yappo.jp/yappo/archives/000714.html">
<title>トランザクションを使用したMySQLのおまとめINSERTはどれくらい速いか</title>
<link>http://feedproxy.google.com/~r/yappo/~3/jIUfpQHLE7Y/000714.html</link>
<description>元ネタはMySQL のおまとめINSERTはどれくらい速いか - bonar noteです。 トランザクションでまとめてInsertしてからcommitしたほうが速くなるので、元ネタのベンチマークをベースにして試してみました。 環境は macports で入れた mysql 5.1.44 です。 まぁnormalからbulk(100)くらいの差は出てなくても、トランザクション使ってまとめてコミットしても多少速くなっとりますね。 normal と txn の差よりも bulk(100) と bulk(100)_txn の差が小さいのは、 bulk insert で最初から効率的になってるぶん差が少なくなってるという感じでしょうか。 コードは以下の通り。...</description>
<dc:subject>tech</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2010-03-09T12:35:04+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000714.html</feedburner:origLink></item>
<item rdf:about="http://blog.yappo.jp/yappo/archives/000713.html">
<title>PHPの関数と同等の実装をPerlでどう書くリファレンスプロジェクト開始のお知らせ</title>
<link>http://feedproxy.google.com/~r/yappo/~3/-ufjFo20yzk/000713.html</link>
<description>ふとしたきっかけでPHPのリファレンスマニュアルにある関数と同等の機能をPerlで実装するにはどうするか?といったリファレンスを作るプロジェクトを始めました。 PHP使いの人がPerlを弄る時に「PHPのこれPerlでどうやれば良いんだ！」といった要望や、ごく普通のPerl使いの人が「これどうやって書けば良いのかな?」って時に使うcookbook代わりに使える事を想定しています。 ドキュメント管理にはgithubhttp://github.com/yappo/docs-php-funcref-in-perlを使い、ドキュメントのビューワーとしてwikihubWikiHub :: php-funcref-in-perl :: READMEを使っています。 書いて欲しいと思った人にはあらかたコラボレータ入れてるので、ドキュメント充実させたいと思ったらすぐにprivate repoをcloneして書けると思います。「俺入って無いし書きたいよ！」って人が居たら言ってもらえればコラボレータ追加します。 別にforkしてpull requestでもいいんですが、面倒なんでコラボにぶっ込みたい所。 書き方などはREADMEを読んでください。 今のところ書いてる人はPerl側の人間が多いので、もしPHPな人で気になった人が居たら参加してもらったら嬉しいなーとは思う所。なんかそのほうが完成度高くなりそう。 この形に落ち着くまでcodereposにしたりnim+perl-usersとか色々やってたんですが、miyagawa伝説とwikihubでの見た目が奇麗とsyntax highlightした時の組み込み関数にphp.netやperldoc.perl.org等にリンクされて便利ってのがwikihub採用の決め手でした。 とりあえず環境もろもろはいつも通り僕が用意したんですが、4000を越えるPHPの関数群のテンプレートファイルをyusukebeが用意してくれました。 ってことでどうぞよろしくです。...</description>
<dc:subject>perl</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2010-03-03T12:02:20+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000713.html</feedburner:origLink></item>
<item rdf:about="http://blog.yappo.jp/yappo/archives/000712.html">
<title>後方互換性を意識するというお話</title>
<link>http://feedproxy.google.com/~r/yappo/~3/kMw3D2zSfPs/000712.html</link>
<description>そろそろ金曜日の天使の元ネタが増えても良いのになーと思ってるyappoです。転職した先でブログ書かないんでしょうか。 あーもーイチから作ったがええんかなぁ・・・。HTTP::EngineもStandaloneがPlackのおかげでremoveされるし。てーかモジュールを簡単にリムーブしてくれるなと・・・。よくみんなついていくよな、こんな事に。 とか好き放題言われてるようなんで一言いっておくと、まったくの嘘っぱちでHTTP::Engine::Interface::Standaloneまだ削除されてませんね。 世のおーぷんなんちゃらな感じでライブラリとかを出してる人は、誰しもが自分のプロダクトの後方互換性くらい意識してるでしょう。 HTTP::Engineだって例外ではありません。Plack/PSGIが熱いだとかいっていて開発するリソースが減ったとしても、一度世の中に出て使われてる以上は採用した人が困らないようにバグを潰すなり何なりでメンテナンスするべきです。 出来ないのなら変わりの人をみつけるか諦めるのも自由なんですが。 まぁ、そんな訳でHTTP::Engineなんかは黙々とバグ潰しをしてたり、raw_bodyがメモリ馬鹿食いしてうざいよねって時には、既存の挙動を壊さないように新たなオプションを豆乳してたりします。after PSGIでも。 まぁ、2年ぶりくらいにCPAN関連のモジュールをアップデートしてはまったとかでいうんなら御愁傷様です。まぁそれで困るような所でいきなりupgradeしてはまるとかそういう事はあり得ないと思ってますが。 とも思ったけど Plack、::Server::*が全部DEPRECATEDになった。ひでぇなぁ・・・。Impl -&gt; Server -&gt; Handler。すばらしくどーでも良いリファクタだこと。表層の名前をぽこぽこ変える神経がすげぇよ・・・。 らしいので良くわかりませんね。 そもそも Plack::Handler になるのって正式リリースまえのDEVELOPER RELEASEなのに何を言っているんでしょうか。僕には理解出来ません。 という事で、ただでさえ後方互換性を意識してても酷い事言われるので、みなさんしっかり後方互換性を意識しましょうねというおとぎ話でした。...</description>
<dc:subject>think</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2010-02-18T20:20:57+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000712.html</feedburner:origLink></item>
<item rdf:about="http://blog.yappo.jp/yappo/archives/000711.html">
<title>僕の撮影環境とFiciaの事について</title>
<link>http://feedproxy.google.com/~r/yappo/~3/HcHdA7BCH64/000711.html</link>
<description>今年に入ってから単純に僕の使ってるカメラのアフィブログ書こうと思ってたらこんなタイミングになった。とは言っても撮影テクニックやら詳しい事は良くわかってナインすが。。。 せっかくえとらぼ、写真ストレージサービス「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 ブラック...</description>
<dc:subject>music</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2010-01-21T00:27:09+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000711.html</feedburner:origLink></item>
<item rdf:about="http://blog.yappo.jp/yappo/archives/000710.html">
<title>kumofs での Data::Model の使い方</title>
<link>http://feedproxy.google.com/~r/yappo/~3/ZA_9ovM8m4o/000710.html</link>
<description><![CDATA[スケート頑張りすぎて足首が痛い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 =&gt; 'Default', で、 Cache::Memcached...]]></description>
<dc:subject>perl</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2010-01-18T12:31:21+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000710.html</feedburner:origLink></item>
<item rdf:about="http://blog.yappo.jp/yappo/archives/000709.html">
<title>Mooseを使うべきでない理由とMooseを使う理由</title>
<link>http://feedproxy.google.com/~r/yappo/~3/OeLjwe5P2s4/000709.html</link>
<description>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を使わないべきとは言っていない。良く考えて使うべきだと言っているのだ。...</description>
<dc:subject>perl</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2010-01-09T01:07:23+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000709.html</feedburner:origLink></item>
<item rdf:about="http://blog.yappo.jp/yappo/archives/000708.html">
<title>Plack::Middleware::Debug のアイコンをどかす Middleware</title>
<link>http://feedproxy.google.com/~r/yappo/~3/0tRsltivIdo/000708.html</link>
<description><![CDATA[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-&gt;(@_) }; }; sub {}; };するような使い方ってMiddlewareって呼んでもいいものなかしら? &lt; miyagawa&gt; middleware でいいですよとの事。...]]></description>
<dc:subject>perl</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2010-01-05T15:26:16+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000708.html</feedburner:origLink></item>
<item rdf:about="http://blog.yappo.jp/yappo/archives/000707.html">
<title>2009年のまとめ</title>
<link>http://feedproxy.google.com/~r/yappo/~3/_-6ZLxVQMKY/000707.html</link>
<description>■1月 　井澤ライブドア社長いじりで年を開ける 　CodeRepos新年会開催 ■3月 　Dan The Hack祭り ■4月 　Hatetter作った - いまも便利に使ってる 　Shibuya.pm #11 で発表 　　run_ops hack と Xen 周り 　mikio さんを励ました 　くさなぎくんが全裸になった ■5月 　Log::Dispatch::Screen::Color つくった 　虹が綺麗だった 　Iron Man Blogging Challengeに参加した 　　もう秋田 　AcotieScript 作った 　svn2git hack した 　Hash::Merge を褒めた ■6月 　Data::Model...</description>
<dc:subject>music</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2009-12-31T23:58:04+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000707.html</feedburner:origLink></item>
<item rdf:about="http://blog.yappo.jp/yappo/archives/000706.html">
<title>Golang の interface type 風味の duck type する関数を作る Object::InterfaceType っての作った</title>
<link>http://feedproxy.google.com/~r/yappo/~3/VE65GcwZGY8/000706.html</link>
<description><![CDATA[だいぶ前に作って放置してたんですが、そこそこCPANに上げられる感じにはしてあったので年末の倉庫整理をかねて CPAN にあげました。 http://github.com/yappo/p5-Object-InterfaceType Goではクラス定義で云々するんじゃなくて、interfaceで定義されてるメソッド群をすべて実装されてたらOKといった感じなんですが、まぁいわゆるduck typingできればおｋみたいな感じですね。 Perlの世界では if ($foo-&gt;can('bar') && $foo-&gt;can('baz')) みたいなコードで duck type可能かを調べるんですが、見た目がごちゃごちゃしがちになるので、Goのinterface type的な感じのものをPerlの世界に持ってきました。 if ($obj-&gt;can('read') && $obj-&gt;can('seek') && $obj-&gt;can('close')) { なんてコードを if ((interface_type [qw/ read seek close /])-&gt;($obj)) { という感じで書き換えられます。 my $is_filehandle = interface_type [qw/ read seek close...]]></description>
<dc:subject>perl</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2009-12-31T16:21:38+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000706.html</feedburner:origLink></item>
<item rdf:about="http://blog.yappo.jp/yappo/archives/000705.html">
<title>ajax/javascriptテスト環境の JSTAPd を CPAN にあげました</title>
<link>http://feedproxy.google.com/~r/yappo/~3/ZHIRUFAUywA/000705.html</link>
<description>ちょっと前のacotiethoneの時にlestrrat++さんがドキュメントを英訳してくださったのでCPANにアップロードしました。 http://search.cpan.org/dist/JSTAPd/ それなりに頑張って日本語でもドキュメント書いたので、lestrratさんが気に留めて使う気になって英訳してくださったんだとおもいます。 おかげでCPANへリリースすることもできました。 テストも重要ですがドキュメントも重要ですね。...</description>
<dc:subject>perl</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2009-12-31T16:04:25+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000705.html</feedburner:origLink></item>
<item rdf:about="http://blog.yappo.jp/yappo/archives/000704.html">
<title>Module::Requires について hacker track last day を書きました </title>
<link>http://feedproxy.google.com/~r/yappo/~3/Q0MMWPYQc8c/000704.html</link>
<description>依存モジュールの管理を実際のコード内で行う為にあったら便利そうなモジュールを思いついたので思いつきのまま CPAN にアップロードして advent calendar に書きました。 http://perl-users.jp/articles/advent-calendar/2009/hacker/25.html たぶん、 advent calendar で紹介されたモジュールの中で一番新米なんじゃないかと思います。 あとは casual track が完走すれば JPerl Advent Calendar 2009 は全部完走となります。 今から寿司がたのしみです＾＾...</description>
<dc:subject>perl</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2009-12-25T15:26:24+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000704.html</feedburner:origLink></item>
<item rdf:about="http://blog.yappo.jp/yappo/archives/000703.html">
<title>あなたがData::Modelを使う10の理由</title>
<link>http://feedproxy.google.com/~r/yappo/~3/vpU1jb9gaLw/000703.html</link>
<description>前口上 一昨年書いた『あなたがRuby on Railsを使わない10の理由』を書いたら、おおむね好評とともに読んでもらえたみたいで(ほんとかー?)うれしい限り。実際あのあとも記事の影響ってわけじゃないと思うけどRoR使ってくれた人もたくさんいるし、ますます広まってきているみたいでこれも私設営業の人としてはとてもうれしい。 略 (例によって書きかけなので今後もいろいろ変わったりするかも) Data::ModelはCPAN Moduleである まあ上でああいったけどやはりCPAN Moduleであることそのものの価値ということにまずは言及しておく。 いまのPerlはまぎれもないCPAN Moduleベースの言語なのだ。それ自体は実のところ単なる偶然の産物なんだけど。でもさまざまに紆余曲折あってCPAN Moduleベースになったおかげで、Perlが得た恩恵はとても大きい。 Perlはその根幹はCPAN Moduleであるということは、CPAN Moduleの四半世紀の歴史がはぐくんできた膨大な蓄積をPerlも同様に備えているということだ。おかげでプログラマだったらPerlがどんな挙動をするかというのはだいたい想像がつくわけ。 Data::ModelはiPodと相性がいい この項、あとで書く いまData::Modelを使い始めると世界で三番目にヘビーなData::Modelユーザになれる あなたが何かの分野で世界第三位の位置に立つことを考えて欲しい。思った以上に道のりが険しいという事が誰でも想像がつくであろう。 しかし、そんなただの人が世界で三番目の位置に立てる分野がある。そうData::Modelのユーザとしてなら世界第三位のヘビーユーザーになれるチャンスがあるのだ。 現在Data::ModelのヘビーユーザはYappoとtokuhiromしか居ない。ここにあなたの名前が連ねるのだ。 どうだい魅力的ではないか? え、DBIx::Skinnyがいいって?ありゃ駄目だ。nekokakを始めとしてモバイルファクトリーの全社員が使ってい。あなたはモバイルファクトリーの社員数を数えられるか? それにyusukebeやnekoyaやnihenやnobuなんとかやmixiの連中まで唾をつけてやがる。 そんな手垢のついたものばっかり使ってるから君は世界三位の位置にいつまでたってもつけないんだよ。 それが、Data::Modelを使えばチャンスが巡ってくる。どうだい?簡単だろう。 それに今ならAdvent Calendar期間中で使い方のドキュメントが揃って来てるしね。 http://perl-users.jp/articles/advent-calendar/2009/data-model/ 以下蛇足 この記事を書いている私はもともとCDBIファンだったんだけど、いまのData::Modelは古き良きCDBIが持っていたcultureと、DBICが持っていたcultureの両方を備えたこれ以上はないほど魅力的なORMになっている。ある意味、CDBIよりもCDBIらしいと思う。この業界の先端を走っている人全員ではないけれど、かなり多くの人はData::Modelを使っているし、これからますます増えてくると思う。...</description>
<dc:subject>perl</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2009-12-22T15:54:01+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000703.html</feedburner:origLink></item>
<item rdf:about="http://blog.yappo.jp/yappo/archives/000702.html">
<title>JPerl Advent Calendar hacker track で Module::Setup の事書いたよ</title>
<link>http://feedproxy.google.com/~r/yappo/~3/6OSGNGapN9M/000702.html</link>
<description>ガイアックスさんのご好意で会場提供された hackathone の成果として Module::Setup 0.07 を shipit する事ができたので、当日担当だった Advent Calendar に Module::Setup の紹介と新要素紹介を行いました。 Module::Setup でらくらくモジュール作成 - JPerl Advent Calendar 2009 実に14月ぶりくらいのメジャーリリースで、様々な機能が追加されています。 おもに flavor 開発者にとって便利な物が大量投入されてます。 他にも Ark などの helper script をより便利に作れる Helper support 機能が投入されてます。 一般向けとしては XS flavor が追加されており、多分 id:gfx がよりモダンな flavor...</description>
<dc:subject>perl</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2009-12-21T12:48:33+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000702.html</feedburner:origLink></item>
<item rdf:about="http://blog.yappo.jp/yappo/archives/000701.html">
<title>goo.gl の API を叩いて goo.gl のショートURLを作る WWW::Shorten::Google ってモジュールかいた</title>
<link>http://feedproxy.google.com/~r/yappo/~3/KU7MKfbGks4/000701.html</link>
<description>http://goo.gl/ ってのが巷では始まっていますが、まだ勝手に tinyurl を作れないようなので 簡単に http://goo.gl/hoge な tinyurl を作る WWW::Shorten::Google ってモジュールを書きました。 http://github.com/yappo/p5-WWW-Shorten-Google CPAN には、各種 tinyurl を使って url を短くするための統一インタフェイスとして WWW::Shorten ってのがあるので、それの流儀にしたがって作りました。...</description>
<dc:subject>perl</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2009-12-15T19:54:59+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000701.html</feedburner:origLink></item>
<item rdf:about="http://blog.yappo.jp/yappo/archives/000700.html">
<title>今年良かったCM</title>
<link>http://feedproxy.google.com/~r/yappo/~3/eJM7Y4_JTMQ/000700.html</link>
<description>というか近年まれに見る良作。 BOSSのクリスマスのなんだけど。 と思ってweb上でCMみれる所探したけど見つからないでやんの。 企業ページにflashな視聴ページあるけど、今の環境じゃ動画みれねー。 ニコニコ動画とかに上げときゃいいのにCMなのに出し惜しみしててどうすんだって感じ。 久しぶりにBOSS飲もうかと思った気持ちが一気に萎えましたというおちでした。 まぁ、こういう昭和の時代にいっぱいあった感じのCMは今は少ないので増えるといいですね。 このCM自体は、今時のTVにあるまじき良作で、最近話題のニコマスMAD映画?だかのプロデューサーが死んじゃうやつより良いとおもいますね。はい。...</description>
<dc:subject>music</dc:subject>
<dc:creator>Yappo</dc:creator>
<dc:date>2009-12-04T02:34:53+09:00</dc:date>
<feedburner:origLink>http://blog.yappo.jp/yappo/archives/000700.html</feedburner:origLink></item>


</rdf:RDF>
