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はスキップリストというアルゴリズムを使っている特性上、 同じス
2011の振り返り - blog.nekokak.org
ちょっと落ち着いたので振り返りなどしてみようかとおもう。 1月 転職を決意し動き出す Teng作ってたみたい Jonkも触ってた 2月 退職の準備とおもいきや１０日で１サイトつくるとかやってた SQL::Objectとかつくってた ３月 転職 地震 ４月 HandlerSocketに興味を持ってたみたい CPANモジュールガイド献本もらったり tmux入門してすぐにscreen回帰した MySQueueとかネタでつくったみたいだ ５月 Yokohama.pmでHandlerSocketの発表とか ６月 Redisの検証をしてた Hokkaido.pmに参加する準備してた DBIx::Handlerを作ったりしてた ７月 Hokkaido.pmに参加。飯が美味かったなり ８月 Web+DBにJobQueueについて寄稿 ９月 Test::Function後のTest::Attribute::
blog.nekokak.org
App::MadEyeとはPerlでかかれた監視フレームワークである。 基本ドキュメントを見ても一切使い方がわからないであろう このモジュールをちょっと解説してみる。 ちなみにYAPC::Asia 2010の省サーバ運用の発表の際、 「監視とかどうしてますか？」 という質問があったが、私はこのApp::MadEyeを使っている。 使用理由としては、基本的に監視したいと思う項目が網羅されている事、 使ったことがあること、nagiosとかめんどくさそう（使ったこと無いだけです） ということ、そして最大の理由はそれがPerlで書かれていることであろう。 早速解説というか使い方 App::MadEyeを起動するスクリプトを用意する。 今回は指定のサーバにpingを打ってみる例である。 #! /usr/bin/perl use strict; use warnings; use App::MadEy
distributed job system. Clutch - blog.nekokak.org
https://github.com/nekokak/p5-Clutch 公開してみた。 あんまり触る時間なくてこのまま腐るなら出してしまおうということでだしてみました。 まぁ何をやる人なのかをざっくり書くと、 gearmanみたいな中間管理職daemonを立てずに client - workerが直接通信してjob queueを投げる感じです。 gearmandみたいなのがいないので、基本的にworkerがどこにいるのかとかはclient側が管理する必要があるけど ちょっとしたツール作るときとかそんなに管理に困るわけでもないので。 前回のHokkaido.pmでの発表でだいたいやりたい内容とか書いてるのであわせてどうぞ http://nekokak.org/presen/hokkaido06/ （発表の時からは微妙に仕様はかわってるけど。） あとパフォーマンスとか今のところ追求していない
wantarrayの使い方
wantarrayは普段からまぁつかうのですが、 void contextの時の挙動が制御できるってしらなかったのでエントリー。 #! perl use strict; use warnings; sub foo { unless (defined wantarray) { warn 'void context'; return; } if (defined wantarray) { warn 'defined wantarray'; if (wantarray) { warn 'list context'; return; } else { warn 'scalar context'; return; } } } foo(); my $foo = foo(); my @foo = foo();こんなコードがあるとすると、実行結果は void context defined wantarr
quick hackの必要性 - blog.nekokak.org
ふと思ったのでメモっておく位の感じ。 仕事ではquick hackって重要だなぁと。 業務で本当に必要と思うような仕組みがあったとして、それをすぐに導入できるかは大人の事情とかがあり なかなか難しかったりするのが普通じゃないでしょうか？ 必要な仕組みだから周りだったり上司だったりを説き伏せて正しい（？）手段で導入するのももちろん正道だとおもいますが、 それがなかなかムズカシイのも世の常かなぁと。 自分は必要だとおもっても、周りにその問題意識があるかどうかは別なので。 好き勝手やっていいよって会社であれば別なんでしょうけど、そういう会社って結構珍しいんじゃないかなぁ。 もちろん相談出来る相手がいて、色々と相談や議論をし、協力者を見つけるのもいいし、そういう相手がいるんであればやるべきだとは思います。 そうすれば自分が思っていなかったような問題点なんかが出てきて考えの幅が広がるかもしれない。
ORMについて - blog.nekokak.org
最近方々でORM不要論が巻き起こってたりするとかしないとか。 まぁ自分も結構煽ってた節があるのでここでちょっくら おそらく日本のPerl界隈のORMで一番使われているであろう(自分の適当調べ)、 DBIx::SkinnyとTengの作者の本気の意見 を、ここに吐露してみようと思う。 結論から言うと、一般的なWebアプリだったりそれに付随するアプリ、 DB周りを操作するアプリに関しては普通にORM使えばいいと思います。 以上 以下は色々思うことなどをつらつらと。 正直つかいたければDBICやDODやその他のORMも使い倒したらいいと思います。 DBICにはDBICの良さがあり、typesterさんが今も愛用するにはそれなりに訳があるし DODはL社でよく使ってるらしいし、DODの透過キャッシュがやっぱり便利だという声も聞きます。 要件を満たせばどんなORMだってつかえばいいんですよ。 もちろ
Test::Attribute::AutoLevel released - blog.nekokak.org
http://blog.nekokak.org/show?guid=6JbK6Erh4BGSM4iYghOgLw こちらでかいたTest::Functionですが @kamipoさんからパッチもらったりして微調整した後renameしてreleaseしました。 リリース名はTest::Attribute::AutoLevelです。 use Test::More; use Test::Attribute::AutoLevel; sub test_fail : AutoLevel { fail 'oops'; } test_faile(); done_testing;などとします。 attribute嫌いな人もいますが、個人的には嫌いではないです。 ついでにTengとDBIx::Skinnyもリリースしました。
Hokkaido.pm#5に参加した - blog.nekokak.org
7/16(土)に行われたHokkaido.pmにJPA様の支援により行くことができました。 ３連休ということでフライト料金が凄いことになってるので、 前日の金曜日の午前中に北海道に到着する感じで入りました。 金曜日の夜にだれか北海道で飲めるヒトーとtwitterで募集したら @lapis_twさん @techno_nekoさん @aloelightさん が来てくださって北海道名物のジンギスカンをたらふく食べることができました。 うまかったです。でも当分ジンギスカンはいりません。 ほんちゃんの発表資料は http://nekokak.org/presen/hokkaido05/ こちらになります。 スライドにも書いてますが、特定のプロダクトを話すよりも、 エンジニアとしての意識の持ち方的な話をしてみました。 いかがでしたでしょうか。 今回のHokkaido.pmでは高校生の@akiymさんが
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でし
Redisのめものもめ - blog.nekokak.org
めものもめなので適当です。 replicationと耐障害性について 例えば 192.168.1.10:6379 で起動しているredisがあるとする。これをmasterとする。 別サーバでreplicationを受けるサーバを容易 192.168.1.11:6379 で起動したとする。これをslaveとする。 redis-cliコマンドでslaveのredisに接続し。 redis> slaveof 192.168.1.10 6379と実行するとon the flyでslaveになることが出来る。 データ量によりどの程度レプリケーションにラグができるかは未検証 次にmasterが死亡したとする。ぷぎゃー。 取り急ぎアプリケーションの参照先をslaveに変更し、 redis-cliでslaveに接続 redis> slaveof no oneと実行することでreplicationをon
tmuxに入門してみた
昔からscreenをずっと使ってて、osx上でもiTermのタブ+screenという使い方をしてるんですが 最近tmuxが人気なのでtmuxを試してみました。 osxではbrew install tmuxだけではいります。 tmuxのキーバインドを覚えるのがめんどくさいので、 tmuxに同梱されているscreenキーバインド設定ファイルを~/tmux.confにコピーします。 tmuxを起動してstatusバーの部分が明らかに見難かったのでscreen風にして使ってみたりしています。 デフォルトで縦分割できるし、縦分割したwindowをさらに横分割とかもさくっとできるのでなかなかヨサゲです。 screen使いの人も一度ためしてみるといいんじゃないでしょうかね。 以下設定ファイル # Set the prefix to ^A. unbind C-b set -g prefix ^T b
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という新しいORMをリリースしました。 TengはDBIx::Skinnyの後継バージョンと捉えていただいて結構です。 DBIx::Skinnyはおおよそ３年前ほどに一人でつくりはじめたORMで 現在に到るまでに様々な仕様変更を繰り返し、 結構秘伝のタレ的なコードが目立つようになってきました。 元々はDBIx::Skinnyをリファクタリングすることで済まそうと思っていたのですが、 後方互換を残したままのリファクタリングに限界を感じました。 多くの人に使っていただいている現状で後方互換を簡単に捨ててしまうのは 宜しく無いとの判断から別プロジェクトとしてリリースするに至りました。 DBIx::Skinnyは現状、バクレポートも特別なく 問題なく継続してご利用頂けると思いますので、ご安心ください。 また、なにか大きな問題点があれば、サポートしますのでpatches&testsウエ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JPA理事 - blog.nekokak.org
株式会社ディー・エヌ・エーに入社しました