nekokak's blog — 駄文：ABテストがモノづくりを破壊する
Archive 駄文：ABテストがモノづくりを破壊する あーなんか書こうかなーと思っても時間もなくて、ぶっちゃけあんまりモチベーションわかなくて、ずっと書いていなかったんだけど何となく思うことをつらつら書き溜めていこうかなと思う。年末だし。 なんとなしに頭にあるのを吐き出すテイなのであんまり読みやすさとか考えない。あと極論書いてる。（という予防線を貼るあたり若干ひよってる） 今回はABテストについて思うことを書いてみるかなと。 ABテストって簡単に言うと２つ以上ある選択肢のうち一番良い結果を出すことのできるものを見つける事ですね。 言葉だけ見るとなんかよさ気にみえてしまうけどモノづくりする上での弊害がかなり大きいと考えています。 一つ目 ABテストやっちゃうと正直工数が余計にかかる。結構掛かる。最近だと低コストでABテストを実現するためのツールとかもあるんだけど適用したいケースによっては設
DBD::mysqlでlimitにbindを使うとエラーがでることがある
再現コード的には use DBI; my $dbh = DBI->connect('dbi:mysql:test','root',''); my $sth = $dbh->prepare('select * from user limit ?'); # limit と ?の間に二個以上のスペース $sth->execute(1); # errorです。 DBD::mysqlの実装でSQLをパースしているところがバグっており、 bindの値がint扱いにならずにエラーになります。 ココ https://github.com/CaptTofu/DBD-mysql/blob/master/dbdimp.c#L594 回避するにはスペースを一個にする。 もしくはbind_paramで型指定してあげましょうのこと。
Fukuoka.PMで発表してきました！ - blog.nekokak.org
と言う事で Fukuoka.PM #1 は JPA 講師派遣制度として発表してきました。 他の方のまとめ記事はこちら http://yokoninaritai.hatenablog.jp/entry/2012/04/03/012440 http://spring-mt.tumblr.com/post/20696127846/fukuoka-pm 前日入したとたん屋台に連れて行ってもらったり、深夜にラーメンに付き合っていただいたりと 堪能することが出来ました。 福岡名物のラーソーメンも食べれたし満足ですた！ はやしさん++ 自分は最近ぽちぽち作ってるClutchの発表をしてみました。 資料を https://github.com/yoshiki/markdown2impress で作ってエフェクトを多めにかけたら 酔う酔うと言われて(´・ω・｀)ｼｮﾎﾞｰﾝ 自分はいままでHokkaid
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
Kyoto.pm Tech Talks #01 に 一般参加してきます！ - blog.nekokak.org
Kyoto.pmが立ち上がったと聞き、 更に発表予定の中にQudoが入ってたり、 生まれも育ちも京都な私が#01に参加しないなんてありえない！ ということで、急遽参加することとしました！ 当日は捗る達人のYappoさんがJPA の 地域PM向け 講師派遣支援プログラムで参加されたり、 関東近辺からの参加者もあるようなので、お時間ある人は来ると良いと思います。 参加枠が既に埋まってるみたいなんですが、発表者枠はまだ開いているようなので http://www.atnd.org/events/25441 発表者枠でねじ込み参加すればいいんじゃないかな。 ということでKyoto.PMな方々どうぞよろしくお願いします。
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を起動する必要がある。 別にそれくらい起動しとけばいい
CloudForecastでqudoのworker状態を見る
Qudo::Parallel::Managerをつかえばscoreboradをみれるので、CloudForecastでグラフ化してみた。 package CloudForecast::Data::Qudo; use CloudForecast::Data -base; use IO::Socket::INET; =head1 NAME CloudForecast::Data::Qudo =head1 SYNOPSIS host_config) resources: - qudo[:port] eg) - qudo # 監視ポート9000 - qudo:9005 # ほかのportで起動 =cut rrds map { [$_,'GAUGE'] } qw/busy idle/; graphs 'status' => 'Qudo worker status';
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でバージョンを指定
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 ;
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