nekokak's blog — 駄文：ABテストがモノづくりを破壊する
Archive 駄文：ABテストがモノづくりを破壊する あーなんか書こうかなーと思っても時間もなくて、ぶっちゃけあんまりモチベーションわかなくて、ずっと書いていなかったんだけど何となく思うことをつらつら書き溜めていこうかなと思う。年末だし。 なんとなしに頭にあるのを吐き出すテイなのであんまり読みやすさとか考えない。あと極論書いてる。（という予防線を貼るあたり若干ひよってる） 今回はABテストについて思うことを書いてみるかなと。 ABテストって簡単に言うと２つ以上ある選択肢のうち一番良い結果を出すことのできるものを見つける事ですね。 言葉だけ見るとなんかよさ気にみえてしまうけどモノづくりする上での弊害がかなり大きいと考えています。 一つ目 ABテストやっちゃうと正直工数が余計にかかる。結構掛かる。最近だと低コストでABテストを実現するためのツールとかもあるんだけど適用したいケースによっては設
簡易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
RENAME TABLEでカジュアルな運用 @mysql-casual#15 - blog.nekokak.org
やぁ。可愛いアイコンでお馴染みの@nekokakだよ。 mysql-casualとか言ってるけどカジュアルな記事が@oinumeさんくらいしかないよね。 ドン引きだね'`,､('∀`) '`,､ ということでガクンと敷居を下げようって感じで超絶カジュアルな話をしてみようと思うんだ。 カジュアル運用していると、「あれなんかこのテーブルまじレコード数おおすぎね？」 とかあるあるですよね。 そこでカジュアルにcountして見るわけです。 InnoDBのテーブルになのにそれもmsaterに対して。 カジュアルですね。 mysql> select count(*) from accesslog; +----------+ | count(*) | +----------+ | 11676738 | +----------+ 1 row in set (1 min 36.99 sec)1分半くらいかか
ORMについて - blog.nekokak.org
最近方々でORM不要論が巻き起こってたりするとかしないとか。 まぁ自分も結構煽ってた節があるのでここでちょっくら おそらく日本のPerl界隈のORMで一番使われているであろう(自分の適当調べ)、 DBIx::SkinnyとTengの作者の本気の意見 を、ここに吐露してみようと思う。 結論から言うと、一般的なWebアプリだったりそれに付随するアプリ、 DB周りを操作するアプリに関しては普通にORM使えばいいと思います。 以上 以下は色々思うことなどをつらつらと。 正直つかいたければDBICやDODやその他のORMも使い倒したらいいと思います。 DBICにはDBICの良さがあり、typesterさんが今も愛用するにはそれなりに訳があるし DODはL社でよく使ってるらしいし、DODの透過キャッシュがやっぱり便利だという声も聞きます。 要件を満たせばどんなORMだってつかえばいいんですよ。 もちろ
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でバージョンを指定
SELECT FOR UPDATEする上での注意点 - blog.nekokak.org
MySQLで行ロックかけてトランザクションを効かせたい場合、SELECT FOR UPDATEを使うわけですが、 以下のようなクエリを発行しちゃうと行ロックではなくテーブルロック風味に扱われるので注意。 mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> select * from user order by id DESC limit 1 for update; +----+---------+ | id | name | +----+---------+ | 4 | xaicron | +----+---------+ 1 row in set (0.00 sec)このクエリを実行中に別のセッションから同じことを実行するとロック待ち状態になり 最悪デッドロックで死亡します。 ERROR 1205 (HY000): Lock
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
OreOre::Cache
入社して一ヶ月がたちました！僕は元気です！ memcachedとかつかわずlocalにカジュアルにキャッシュしたい時は まぁなんかこんなんで全然処理速度かわるからOreOre::Cacheもありじゃないすかねぇ。 キャッシュするデータ量とかによってon memoryにもつのかとか変わってくるとは思いますが。 #! /usr/bin/perl use strict; use warnings; use Cache::FileCache; use Cache::MemoryCache; use Benchmark qw/timethese/; my $memory_cache = Cache::MemoryCache->new( +{ namespace => 'test_file:', default_expires_in => 1, } ); my $file_cache = Cache:
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ウエ
O/R Mapper についてかんがえてみた
元ネタ）http://d.hatena.ne.jp/tokuhirom/20110104/1294170319 昔良くORMを使うことのメリットは SQLを書かなくてよくなる。 つまりプログラマはSQL脳が低いからプログラマにSQLを書かせない。 プログラム中にSQLという別の概念がはいってくるとコードが読み難くなる。 バックエンドのRDBMSの差異を吸収してくれるからバックエンドを気にする必要がない。 さらに、バックエンドのRDBMSを簡単に取替え可能。 プログラマブルにSQLを組み立てしたい。 などと言われることが多いんじゃないでしょうかね。 個人的には最後の「プログラマブルにSQLを組み立てしたい」と言う要件以外は全部 間違っていると思います。 イカ全て自分の視点なだけなので違う意見もあるであろうことを承知で言い切ります。 SQLを書かなくてよくなる。つまりプログラマはSQL脳が低い
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 =>
RDBMSのsavepointについて
大体のRDBMSでsavepointという機能が実装さておるわけですが、 正直savepointを今までつかったことありませんでした。 savepointについては http://dev.mysql.com/doc/refman/5.1/ja/savepoints.html http://msdn.microsoft.com/ja-jp/library/ms378414%28SQL.90%29.aspx などを見るとよいでしょう。 簡単に言うと、トランザクションの途中でエラーになった場合、 savepointでマークした場所にまでrollbackで戻れるってかんじすね。 で、使いどころとしては 複数のプロセスが同テーブルをinsertしたりするときにユニーク制約がかかってdupで落ちる時なんかに 使ったりするのかなーと思っているのですが、 もっと有効な使い方があるんじゃないかなとおもってい
コード否定≠人格否定
よく（？）勘違いされるんですが、 「このプログラムのこの部分の書き方ないわー」 と言われた人は 自分自身が全て否定されていると受け取る人が多いような気がします。 もちろんプライドをもったプログラマーであれば、 自分の書いたコードが否定されることは気持ちのいい事ではないと思います。 あと、コードの問題点を指摘する側の人がもう少し配慮した言い方をすればいいのになと思う節がない訳ではありません。 しかし、私がいつも思っている（思うようにしている）事は、 「指摘されるうちが華」という事です。 指摘されるという事は何かしらの事情はあれ、 自分の書いたコードに興味を持って見てくれる人が居る。 もしくは一緒に仕事をして居る間柄だとすると、問題点を指摘してくれたり、 もっといい書き方あるよという自分の足りない部分を補ってくれるているのです。 なんとありがたい事ではないですか。 こんなありがたい事を無償で
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
株式会社ディー・エヌ・エーに入社しました