nekokak's blog — 駄文：ABテストがモノづくりを破壊する
Archive 駄文：ABテストがモノづくりを破壊する あーなんか書こうかなーと思っても時間もなくて、ぶっちゃけあんまりモチベーションわかなくて、ずっと書いていなかったんだけど何となく思うことをつらつら書き溜めていこうかなと思う。年末だし。 なんとなしに頭にあるのを吐き出すテイなのであんまり読みやすさとか考えない。あと極論書いてる。（という予防線を貼るあたり若干ひよってる） 今回はABテストについて思うことを書いてみるかなと。 ABテストって簡単に言うと２つ以上ある選択肢のうち一番良い結果を出すことのできるものを見つける事ですね。 言葉だけ見るとなんかよさ気にみえてしまうけどモノづくりする上での弊害がかなり大きいと考えています。 一つ目 ABテストやっちゃうと正直工数が余計にかかる。結構掛かる。最近だと低コストでABテストを実現するためのツールとかもあるんだけど適用したいケースによっては設
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はスキップリストというアルゴリズムを使っている特性上、 同じス
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
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::
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だってつかえばいいんですよ。 もちろ
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
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
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
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脳が低い
コード否定≠人格否定
よく（？）勘違いされるんですが、 「このプログラムのこの部分の書き方ないわー」 と言われた人は 自分自身が全て否定されていると受け取る人が多いような気がします。 もちろんプライドをもったプログラマーであれば、 自分の書いたコードが否定されることは気持ちのいい事ではないと思います。 あと、コードの問題点を指摘する側の人がもう少し配慮した言い方をすればいいのになと思う節がない訳ではありません。 しかし、私がいつも思っている（思うようにしている）事は、 「指摘されるうちが華」という事です。 指摘されるという事は何かしらの事情はあれ、 自分の書いたコードに興味を持って見てくれる人が居る。 もしくは一緒に仕事をして居る間柄だとすると、問題点を指摘してくれたり、 もっといい書き方あるよという自分の足りない部分を補ってくれるているのです。 なんとありがたい事ではないですか。 こんなありがたい事を無償で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
