Redis の SortedSets 同点問題について - blog.nekokak.org
WEB+DBのRedis特集をひろせまさあきさんと共同で執筆しました。 WEB+DB PRESS Vol.73posted with amazlet at 13.03.05設樂 洋爾 白土 慧 奥野 幹也 佐藤 鉄平 後藤 秀宣 mala 中島 聡 堤 智代 森田 創 A-Listers はまちや2 大和田 純 松田 明 後藤 大輔 ひろせ まさあき 小林 篤 近藤 宇智朗 まかまか般若波羅蜜 Mr. O 技術評論社 売り上げランキング: 335 Amazon.co.jpで詳細を見る 買ってください。 このRedis特集の第五章では、Redisを使ったリアルタイムランキングについて取り上げたのですが、 記事中にある同点問題について、執筆時から状況が変わりましたのでupdateします。 記事中では、RedisのSortedSetsはスキップリストというアルゴリズムを使っている特性上、 同じス
実行時に使用したメモリを取得する幾つかの方法 - 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;
Re:Teng::Schema::DeclareにPlugin機構があったらいいのにって妄想してた
http://d.hatena.ne.jp/shiba_yu36/20110317/1300375840 TengではSchemaAPIがあるのでinflate/deflateをSchema定義時以外に 挿し込むことも可能です。 ちょっと長いですがサンプルスクリプト。 use strict; use warnings; use Test::More; { package Mock; use parent 'Teng'; package Mock::Schema; use Teng::Schema::Declare; table { name 'mock'; pk 'id'; columns qw/ id name /; }; package Mock::Name; use overload '""' => sub { $_[0]->as_inflate }, fallback => 1 ;
Cache::Memcached::Fastの高速化
一番簡単に高速化するには シリアライザをData::MesagePackにするとよいかもしれない。 #! /usr/bin/perl use strict; use warnings; use Cache::Memcached::Fast; use Data::MessagePack; use Benchmark qw/timethese/; my $normal = Cache::Memcached::Fast->new({ servers => ['127.0.0.1:11211'], serialize_methods => [ \&Storable::freeze, \&Storable::thaw ], }); my $msgpack = Cache::Memcached::Fast->new({ servers => ['127.0.0.1:11211'], serialize
Tengでのコネクション管理について
現在Tengでのコネクション管理方法を模索中です。 旧来までのSkinny方式のメリットは connect_infoがある場合はTeng側で コネクションの接続管理（再接続等）、 トランザクション管理（コネクションとトランザクションは同時に意識して管理する必要がある） がある程度可能な所でしょう。 ただ、問題もあります。 Skinny/Tengではnewする時などに外部で生成したdbhを受け取り それを使う事が可能なのですが、connect_infoが不明なため、 Skinny/Teng側ではreconnectしようがないので、若干挙動が分かりにくくなる所でしょう。 (dbhからconnect_infoを取れないのは検証済み..いや、取れるよ！って場合は教えてください！) またコネクションの再接続は切れてるから接続し直せば良いというものでもありません。 トランザクション中だったり、on m
SQL::Object
というのを作ってみた。(結構前に) https://github.com/nekokak/p5-SQL-Object コンセプトは 生のSQL（基本where句）をプログラマブルに結合出来るようにすることです。 （namespaceが微妙という説もあるけどSQL::Stringとかもにたようなもんだよね！） 使い方： use SQL::Object qw/sql/; my $sql = sql('foo.id=?',1); $sql->as_sql; # 'foo.id=?' $sql->bind; # qw/1/ $sql->and('foo.name=?','nekokak'); $sql->as_sql; # 'foo.id=? AND foo.name=?' $sql->bind; # qw/1 nekokak/ $sql->as_sql; # 'foo.id=? AND foo
Tengについて
先ほどTengという新しいORMをリリースしました。 TengはDBIx::Skinnyの後継バージョンと捉えていただいて結構です。 DBIx::Skinnyはおおよそ３年前ほどに一人でつくりはじめたORMで 現在に到るまでに様々な仕様変更を繰り返し、 結構秘伝のタレ的なコードが目立つようになってきました。 元々はDBIx::Skinnyをリファクタリングすることで済まそうと思っていたのですが、 後方互換を残したままのリファクタリングに限界を感じました。 多くの人に使っていただいている現状で後方互換を簡単に捨ててしまうのは 宜しく無いとの判断から別プロジェクトとしてリリースするに至りました。 DBIx::Skinnyは現状、バクレポートも特別なく 問題なく継続してご利用頂けると思いますので、ご安心ください。 また、なにか大きな問題点があれば、サポートしますのでpatches&testsウエ
Smart::Argsの素晴らしいところ
Sub::Argsというものを作っていながら、 Smart::Argsを紹介します。 一言でいうとSmart::Argsの良さは型チェックができるとかそんなことではなく、 argumentsをhashと同じキー名の変数でうけとれることでしょう。 サンプルコード use strict; use warnings; package Your::Class; use Smart::Args; sub foo { args my $self, my $fh, my $bucket => {optional => 1}, my $ext => {optional => 1}, ; } package main; foo(fh => $fh, bucket => $bucket, ext => $ext); # or foo({fh => $fh, bucket => $bucket, ext =>
Minimalistic Approach
最近Minimalistic Approachなアプローチがとある界隈でブームなんです。 DBIx::SkinnyをつくったのはDBIx::Classのあの重厚な感じで見通しがわるくズングリムックリなところが嫌で すっきりさっぱりなORMが欲しくてつくりました。 QudoをつくったのはTheSchwartzの拡張性の乏しさが故にプラガブルなJobQueueエンジンを作りたくて作りました。 Qudoは重厚というほどではないですが、それなりの重苦しさがあるとは思っています。 その重苦しさが故にプラガブルで拡張性はあってもその拡張性はQudoというフレームにそった拡張しかできませんでした。 その為、JonkというすっきりさっぱりなJobQueueエンジンを作りました。 Minimalistic Approachなアプローチでは、様々な小さなモジュールを部品として使い、 DIYな感じで自分の好みだ
DBIx::TransactionManager
というのを書きました。 https://github.com/nekokak/p5-DBIx-TransactionManager まぁ、DBIx::Skinnyで使っているトランザクションの仕組みを別モジュールに切り出した感じです。 use DBI; use DBIx::TransactionManager; my $dbh = DBI->connect('dbi:SQLite:'); my $tm = DBIx::TransactionManager->new($dbh); { my $txn = $tm->txn_scope; $dbh->do("insert into foo (id, var) values (1,'baz')"); { my $txn2 = $tm->txn_scope; $dbh->do("insert into foo (id, var) values (
DBIx::Skinnyの拡張モジュールをまるっとテストします
現在DBIx::Skinnyの内部をリファクタリングしたりしているのですが、 その為に関連モジュールが動かなくなったりするとかなしくなるとおもいます。 そこでexternals_testsという仕組みをMouseから拝借して 関連モジュールを最新（もしくは新規開発中）のDBIx::Skinnyで問題無くテストが通るかをチェック出来るようになりました。 現在の所 https://github.com/walf443/p5-dbix-skinny-proxy_table https://github.com/walf443/p5-dbix-skinny-pager この２モジュールを外部モジュールテスト対象としております。 基本gitで管理されているモジュールであれば readonlyでもよいのでリポジトリのパスを教えて頂ければテスト対象に追加します。 （git以外は面倒なのであまりやりたくあ
DBIx::Skinnyのなおしたいところ(案)
・DBIx::Skinny::SQLがいけてないのでなおしたい $skinnyのObjectに依存しているのがretrieveメソッドだけなので 若干のインコンパチな変更になるけどなんとかしたいかな。 あとDBIx::Skinny::Accessorを廃止したい。 正直SQL builderとしていけてない。（Data::ObjectDriverからぱくっといてなんだけど） complex_whereとか書きにくすぎる ・AnonRowクラスの廃止 Rowクラス生成を必須とするかどうか。 ・ClassメソッドでDBIx::Skinnyを操作出来るインタフェース 正直インスタンスをつくって操作したほうがよいのでSkinnyとして廃止したい。 後方互換かんがえると結構大変なことなり。 ちなむとヤルにしてもいきなりエラーになるとかはしないのでご安心を。 そしてヤルか
Jonkという名のJobTankingミドルウエア
JobQueueManagerについて で書いていたシンプルなjob管理の仕組みを作ってみました。 https://github.com/nekokak/p5-Jonk 使い方はこんな感じ。 use Jonk; my $dbh = DBI->connect(...); # enqueue job { my $jonk = Jonk->new($dbh); $jonk->enqueue('MyWorker', 'arg'); } # dequeue job { my $jonk = Jonk->new($dbh, {funcs => ['MyWorker']}); my $job = $jonk->dequeue; print $job->{func}; # MyWorker print $job->{arg}; # arg }Jonkはなにもやりません。jobをRDBMSに貯める以外は。
「バリデーションはどの位置で必要か」のやりとりで思ったこと。
個人的にはapi単位での引数のバリデーションはあった方がbetterかなとおもう。 tokuhiromが 複数人で開発している場合では、クラスをかいた人と利用者がちがう場合があるので、validation は必要だとおもうけれど。と書いてるけどこれはまさにその通りで、 さらに言うと自分の書いたコードも時間が経てば他人が書いたコードと一緒だから バリデーションの情報から引数の情報を読み取れると、 そのapiに対する理解の速度は向上するとおもう。 実行速度とのトレードオフだったりはするだろうけど、無駄な引数渡したり、本当は必要な引数を渡しきれなかったりして それで誤動作とかするくらいならバリデーションあったほうがいいんじゃないでしょうかね。 perlcodesampleさんの 動的言語の利点は、引数にどのような型でも渡せるので、静的言語のように型の指定がいらないということです。つまり、動的言語
YAPC::Asia 2010 省サーバ運用のトークについての補足
YAPCお疲れ様でした。 東工大++ 運営の人達++ そしてベストスピーカーに投票していただいた方々 本当にありがとうございます！ I got the 2nd best talk award. ということでまさか自分が選ばれるとは思ってなくて 壇上ではキョドってましたが本当に嬉しく思っております。 省サーバ運用のトークについての補足をちょっとばかししておきたいとおもいます。 別に大規模に対するDISや大規模環境の話なんて聞いても意味ないぜとかは一切言っておりおません。 スケールする環境を構築できるような知識やノウハウは必須だと思っています。 今回のトークのテクニカルな部分もとりあえず小規模環境で構築するけど 規模がおおきくなったらこういうふうにスケールできるよね なので色々工夫しようねというお話です。 ヒットしないサービスを開発する人ってまぁそんなに居ないと思うので 当然将来スケールするよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
株式会社ディー・エヌ・エーに入社しました
退職のお知らせ