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はスキップリストというアルゴリズムを使っている特性上、 同じス
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でバージョンを指定
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ウエ
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
O/R Mapper についてかんがえてみた
元ネタ）http://d.hatena.ne.jp/tokuhirom/20110104/1294170319 昔良くORMを使うことのメリットは SQLを書かなくてよくなる。 つまりプログラマはSQL脳が低いからプログラマにSQLを書かせない。 プログラム中にSQLという別の概念がはいってくるとコードが読み難くなる。 バックエンドのRDBMSの差異を吸収してくれるからバックエンドを気にする必要がない。 さらに、バックエンドのRDBMSを簡単に取替え可能。 プログラマブルにSQLを組み立てしたい。 などと言われることが多いんじゃないでしょうかね。 個人的には最後の「プログラマブルにSQLを組み立てしたい」と言う要件以外は全部 間違っていると思います。 イカ全て自分の視点なだけなので違う意見もあるであろうことを承知で言い切ります。 SQLを書かなくてよくなる。つまりプログラマはSQL脳が低い
Sub::Argsで存在しないキーにアクセスしたらエラーに
前回Smart::Argsを紹介したときに、 http://blog.nekokak.org/show?guid=YOPjaCIM4BGd0gUxMSAp_g use strictしててもhashのキーを間違った場合、普通に処理できてしまい 間違いに気づかないわけです。 use fieldsつかえば回避できるんですが、 いまどきuse fieldsを使ってるのはbradだけという噂もあるので、 Smart::Args使っとけって感じです。と、書いたわけですが、Sub::Argsの0.05をつかえば package Your::Class; use Sub::Args; sub foo { my $class = shift; my $args = args( +{ fh => 1, bucket => 0, ext => 0, } ); $args->{exf}; # oops } p
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 =>
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
