Kyoto.pm #01 に参加してきた - blog.nekokak.org
第一回のKyoto.pmに帰省を兼ねて参加してきました。 自分の発表資料は以下 http://nekokak.org/presen/kyoto01/ ORMとはといったような概論的なはなしをしながら、 最後は一緒にTengを開発しませんか？ といったかんじ。 プレゼン中でも触れていますが、今あまり(ほとんど)Tengの開発に注力できないので 新機能だったり、リファクタリングだったりが滞っています。 DBIx::SkinnyもTengも多くの人に使われるようになってきているので、 使っている人からの開発リソースの還元を受けたいなーとか 開発に関わりたいと思っているような人をうまく取り込みたいなーと考えています。 プレゼン後の懇親会で、Tengは必要最低限の機能にわざと絞ってるのに、 新機能開発ってどういうこと？ という質問を受けたのですが、Tengは自分の理想を完璧に形にできているわけではな
Clutchの仕様と構想と（その２） - blog.nekokak.org
投げっぱなしrequest まぁ、Gearmandで言うところのdispatch_backgroundである。 clientはworkerにリクエストを投げる、 workerはリクエストを受け付けた事だけをclientに通知し、client - workerの接続を終了する。 workerはその後clientからのリクエストを処理する。 こうすることでclientはworkerの処理結果は受け取れないが、即時に処理を終了させることができる。 usecaseとしては、ページングの際の先読みキャッシュを作ったりとか。 multi request 複数のworkerに対してまとめてリクエストを投げたいケースもある。 一つの方法としてはclientが対象となるworkerにまとめてリクエストを投げる方法。 各workerへの接続をそれぞれ持ち、selectかけつつぐるぐるループさせて、read
Clutchの仕様と構想と（その１） - blog.nekokak.org
Clutchを作ってる上で、やり残しの部分だったり、懸念点だったりもろもろが頭の中に残っているので 現状の仕様等をまとめつつ書きだしてみる。 長くなりそうだからその１としている。 なぜGearmanではないのか ClutchはGearmanのように中間daemon(gearmand)を基本持たない。 Gearmanの場合はclientは実際に処理を行うworkerがどこにどれだけ居るかを知る必要はなく、 gearmandの居場所さえ知ればよい。 clientがgearmandにリクエストを投げれば、あとはgearmandが対象となるworkerにrequestを回す。 自分としてはこのgearmandという存在がうっとおしく思えた。 例えばちょっとしたツールでjob queueを使いたい場合、workerプロセス以外にもgearmandを起動する必要がある。 別にそれくらい起動しとけばいい
RENAME TABLEでカジュアルな運用 @mysql-casual#15 - blog.nekokak.org
やぁ。可愛いアイコンでお馴染みの@nekokakだよ。 mysql-casualとか言ってるけどカジュアルな記事が@oinumeさんくらいしかないよね。 ドン引きだね'`,､('∀`) '`,､ ということでガクンと敷居を下げようって感じで超絶カジュアルな話をしてみようと思うんだ。 カジュアル運用していると、「あれなんかこのテーブルまじレコード数おおすぎね？」 とかあるあるですよね。 そこでカジュアルにcountして見るわけです。 InnoDBのテーブルになのにそれもmsaterに対して。 カジュアルですね。 mysql> select count(*) from accesslog; +----------+ | count(*) | +----------+ | 11676738 | +----------+ 1 row in set (1 min 36.99 sec)1分半くらいかか
DBI#cloneというメソッド - blog.nekokak.org
http://search.cpan.org/dist/DBI/DBI.pm#clone DBIにcloneメソッドがあることを@nihenさんがみつけました。 #いやーDBIのドキュメントは良く読むと便利メソッドが一杯ありますね TengとかSkinnyではconnect_infoを受け取るだけでなく、 $dbhを受け取って利用する仕組みも提供しているのですが、 そこで一番問題になっていたのはdbへの接続がブチギレた場合のreconnectの問題でした。 connect_infoがある場合は接続情報を自分で持っており、簡単に再接続できるんですが $dbhしかない場合はいままでできないとおもっていました。 DBI的にも接続時につかったpasswordを取るインタフェースがなかった。 なので$dbhを渡された場合は自動reconnectは行わずにエラーで死亡にするようになってたんですが、 D
Teng v0.14 released - blog.nekokak.org
v0.13の変更で$row->updateを経由させると、 deflateが二回実行されるバグがあったので修正しました。 v0.13を使っている人はupdateを v0.13を使おうと思っていた人は使わないようにしてください！ very thanks @kentaro
ORMについて - blog.nekokak.org
最近方々でORM不要論が巻き起こってたりするとかしないとか。 まぁ自分も結構煽ってた節があるのでここでちょっくら おそらく日本のPerl界隈のORMで一番使われているであろう(自分の適当調べ)、 DBIx::SkinnyとTengの作者の本気の意見 を、ここに吐露してみようと思う。 結論から言うと、一般的なWebアプリだったりそれに付随するアプリ、 DB周りを操作するアプリに関しては普通にORM使えばいいと思います。 以上 以下は色々思うことなどをつらつらと。 正直つかいたければDBICやDODやその他のORMも使い倒したらいいと思います。 DBICにはDBICの良さがあり、typesterさんが今も愛用するにはそれなりに訳があるし DODはL社でよく使ってるらしいし、DODの透過キャッシュがやっぱり便利だという声も聞きます。 要件を満たせばどんなORMだってつかえばいいんですよ。 もちろ
実行時に使用したメモリを取得する幾つかの方法 - blog.nekokak.org
あんまこういうの詳しくないので、詳しい人に教えてもらいたいのですが、 Perlのプログラムでどれだけメモリを消費したか確認するのに幾つか方法があると思います。 今回はwebアプリで１リクエスト毎に消費したメモリを取得したい感じ。 自分が知ってる方法は １：Plack::Middleware::Debug::Memoryでやってるようにpsを叩いてメモリを取る my $out = `ps -o rss= -p $$`; $out =~ s/^\s*|\s*$//gs;こういうやつ。 ２：Devel::Mallinfoを使う Devel::Mallinfoを使えばmallinfoが取得できるので、mallocされたサイズを取得できるので 開始と終了でmallinfoをとって差分を出せばプロセス中にどれくらいメモリを消費したかが分かる。 #! /usr/bin/perl use strict;
OrePANがcoolすぎる - blog.nekokak.org
みなさんCPANモジュールの管理どうしてますか？ rpm? deb?いやーメンドクサイですね。 メンドクサすぎて日がくれます。 それにそんな一元管理の方法したらコンポーネントが複数ある場合、 簡単にmoduleのバージョンがupでいないじゃないですか。 so badですね。 いまだとperlbrewとextlibでコンポーネント毎にcpanモジュールを管理することが 大分と楽にはなりましたが、OSの差はどう仕様も無い！ 実際にサービスに撒くmoduleに関してはサービスのosで作ったperlbrew+extlibで管理していいとおもいますが、 localの開発環境が、MacOSとかだとすると激しくメンドクサイですね！ さらにextlibとかに入れてるバージョンと全く同じバージョンのモジュールを 手元のmacに入れるとか実は結構むずかしいんですよね。 Makefile.PLでバージョンを指定
DBIx::Handler的なものをでっちあげた件 - blog.nekokak.org
最近はORMを一切使わず生なDBIでもりもりコードかいてます。 ORMを使うと隣の人に刺されるのでェ で、です。生のDBIを使うとforkする処理を書く時に面倒だったりします。 現在のところDBIx::Connectorとかつかってて基本問題ないんですが、 どうしてもこのDBIx::Connectorのインタフェースが気に入らなくてイライラしてました。 隣の人はそうでもないみたいですが で、です。ついカッとなってDBIx::Handlerというのを書きました。 実はこいつは今年の初め頃に一度軽く書いたんですが、その時はDBIx::Connectorよりも低機能だし おれおれコネクター書くのはよくないよなーとおもって自重してたんです。 でもついカッとなったのでしかたないです。 個人的なDBIx::Connectorの嫌な部分を列挙すると、 - トランザクションのかけ方がcodeblockでし
released Jonk-0.10_01
先ほどJonkをdevリリースしました。 今までのJonkと異なり大幅にクラス構成を変更し、 またapiをガッツリ変えました。 新生Jonkでは以下のように使います Jobの登録: use DBI; use Jonk my $dbh = DBI->connect('dbi:mysql:test','user','pass'); my $jonk = Jonk->new($dbh); my $job_id = $jonk->insert('worker_key', 'job_data_here');Jonの実行 use DBI; use Jonk use Your::Worker; my $dbh = DBI->connect('dbi:mysql:test','user','pass'); my $jonk = Jonk->new($dbh, {functions => [qw/wor
Tengについて
先ほどTengという新しいORMをリリースしました。 TengはDBIx::Skinnyの後継バージョンと捉えていただいて結構です。 DBIx::Skinnyはおおよそ３年前ほどに一人でつくりはじめたORMで 現在に到るまでに様々な仕様変更を繰り返し、 結構秘伝のタレ的なコードが目立つようになってきました。 元々はDBIx::Skinnyをリファクタリングすることで済まそうと思っていたのですが、 後方互換を残したままのリファクタリングに限界を感じました。 多くの人に使っていただいている現状で後方互換を簡単に捨ててしまうのは 宜しく無いとの判断から別プロジェクトとしてリリースするに至りました。 DBIx::Skinnyは現状、バクレポートも特別なく 問題なく継続してご利用頂けると思いますので、ご安心ください。 また、なにか大きな問題点があれば、サポートしますのでpatches&testsウエ
プロジェクト開発におけるテスト用DBの(使い|作り)方
昔書いたような気がしてたけど書いてなかったので。 モジュールをつくっていてDB回りのテストを書きたい場合は Test::mysqldやTest::postgresql を使うこと。 CPANなんかに上げるモジュールではなく、お仕事プロジェクトのコードを書いていて DB回りのテストを書きたいケースについてです。 私はMySQLを利用しているので、Test::mysqldをつかってもよいのですが、 起動コストがそれなりにかかるのと、ローカルの開発環境には既にMySQLは立ち上がっている前提があるので、 既に立ち上がっているMySQLをそのまま利用する方法をとっています。 そこでテスト用のユーティリティクラスを紹介してみます。 package t::Utils; use strict; use warnings; use utf8; use lib './t/'; use Test::Fixtu
DBIx::SKinnyのなおしたいところ(とりあえず今日の成果)
http://blog.nekokak.org/show?guid=8BnKXTn53xGnxZgxMSAp_g 参照のこと。 まだCPANにはupしていません。 ・DBIx::Skinny::Accessorを廃止 Class::Accessor::Liteにおきかえました ・AnonRowクラスの廃止 Rowクラスを定義していない場合は自動でRowクラスを生成しますがいままでのようなanonクラスではなく tableに対応したクラスを生成します。 ・update_by_sql/delete_by_sqlの廃止 doメソッドで十分だと思います。 update_by_sql/delete_by_sqlの廃止以外はAPIにインコンパチな変更はありません。 なお、依然ご意見ご要望おまちしておりますのでよろしくお願いします。
DBIx::Skinnyのなおしたいところ(案)
・DBIx::Skinny::SQLがいけてないのでなおしたい $skinnyのObjectに依存しているのがretrieveメソッドだけなので 若干のインコンパチな変更になるけどなんとかしたいかな。 あとDBIx::Skinny::Accessorを廃止したい。 正直SQL builderとしていけてない。（Data::ObjectDriverからぱくっといてなんだけど） complex_whereとか書きにくすぎる ・AnonRowクラスの廃止 Rowクラス生成を必須とするかどうか。 ・ClassメソッドでDBIx::Skinnyを操作出来るインタフェース 正直インスタンスをつくって操作したほうがよいのでSkinnyとして廃止したい。 後方互換かんがえると結構大変なことなり。 ちなむとヤルにしてもいきなりエラーになるとかはしないのでご安心を。 そしてヤルか
released Jonk-0.01
http://search.cpan.org/~nekokak/Jonk-0.01/ 先ほどリリースしたのでお知らせしておきます。 http://blog.nekokak.org/show?guid=tFbq8B723xGnPyxB1pTnqQ こちらで紹介したインタフェースから若干のインタフェースの変更がありますが、 基本的な方針に変更はありません。 use DBI; my $dbh = DBI->connect(...); # enqueue job { use Jonk::Client; my $jonk = Jonk::Client->new($dbh); $jonk->enqueue('MyWorker', 'arg'); } # dequeue job { use Jonk::Worker; my $jonk = Jonk::Worker->new($dbh, {funct
メモリ使用量の確認
サーバのメモリが思った以上に消費していたのでサックリ調べてたのですが 各プロセスのメモリ使用状況の調べ方としては ps aux --sort=-rss | head -40とやるとRSSのサイズでソートしてくれるのでheadとかでみてやればメモリ使用量が多い順に参照可能。 ただたんにps auxしただけだと見るのがしんどい。 topでもshift+Mで同じ感じでみれるのでそれでも良い。 （cを入力してプロセスの詳細を表示するとなおよい） あとはCoWに乗ってるかを調べたが、 http://d.hatena.ne.jp/naoya/20080212/1202830671 naoyaさんが紹介されている方法そのまんまでよいでしょう。 sudoして実行すること。 Cowはアプリの質にもよるが基本的にはライブラリが共有メモリに乗ってればいいから アプリの質をみつつsharedなパーセントを調整出
Devel::KYTProfをもっと便利に
Devel::KYTProfに３つ程パッチを送ったら取り込んでいただけたのでその機能の部分だけでもご紹介。 http://github.com/onishi/perl5-devel-kytprof １：カラースキームの指定 use Devel::KYTProf; Devel::KYTProf->color_info('magenta');とかすると、表示される文字の色を変える事ができます。 人によってターミナルの背景色がちがったりするので、環境に合わせて指定できるようになりました。 ２：Cache::Memcached::Fast使用時のキー表示 Devel::KYTProfでは自動でCache::Memcached::Fastをhookして、 勝手にプロファイルをとってくれるのですが、memcachedの肝となるキャッシュキーを表示できてなかったので 表示するようにしました。 これでど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Teng v0.13 released - blog.nekokak.org
Devel::KYTProfが熱い！