簡易2WaySQL - blog.nekokak.org
2WaySQLというものがあるわけです。 2WaySQLについてはhttp://www.slideshare.net/t_wada/tokyo-rubykaigi-01-twada-presentation を参考にしてもらうとして、 超絶簡単に説明すると、実行可能なSQLを書いておいて（where句の値もデフォルト値を書いておくので実行可能となる） プログラム側で良い感じにプレスホルダーとかに置き換えて値を良い感じに置き換えます。 どんなSQLかというと SELECT * FROM USER WHERE id = /*:id*/1 OR name = /*:name*/'nekokak' OR ids IN /*:ids*/(2,3,4)こういう感じ。 普通に実行可能ですよね。 これを、 my $sql = q{SELECT * FROM USER WHERE id = /*:id*/1
Clutchの仕様と構想と（その１） - blog.nekokak.org
Clutchを作ってる上で、やり残しの部分だったり、懸念点だったりもろもろが頭の中に残っているので 現状の仕様等をまとめつつ書きだしてみる。 長くなりそうだからその１としている。 なぜGearmanではないのか ClutchはGearmanのように中間daemon(gearmand)を基本持たない。 Gearmanの場合はclientは実際に処理を行うworkerがどこにどれだけ居るかを知る必要はなく、 gearmandの居場所さえ知ればよい。 clientがgearmandにリクエストを投げれば、あとはgearmandが対象となるworkerにrequestを回す。 自分としてはこのgearmandという存在がうっとおしく思えた。 例えばちょっとしたツールでjob queueを使いたい場合、workerプロセス以外にもgearmandを起動する必要がある。 別にそれくらい起動しとけばいい
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
「バリデーションはどの位置で必要か」のやりとりで思ったこと。
個人的にはapi単位での引数のバリデーションはあった方がbetterかなとおもう。 tokuhiromが 複数人で開発している場合では、クラスをかいた人と利用者がちがう場合があるので、validation は必要だとおもうけれど。と書いてるけどこれはまさにその通りで、 さらに言うと自分の書いたコードも時間が経てば他人が書いたコードと一緒だから バリデーションの情報から引数の情報を読み取れると、 そのapiに対する理解の速度は向上するとおもう。 実行速度とのトレードオフだったりはするだろうけど、無駄な引数渡したり、本当は必要な引数を渡しきれなかったりして それで誤動作とかするくらいならバリデーションあったほうがいいんじゃないでしょうかね。 perlcodesampleさんの 動的言語の利点は、引数にどのような型でも渡せるので、静的言語のように型の指定がいらないということです。つまり、動的言語
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
