nabokov7; rehash : A/Bテストで出来ること、出来ないこと
June 16, 201415:28 カテゴリサービス作りの話 A/Bテストで出来ること、出来ないこと A/Bテストに頼るべきでない判断に、次の二つがあると思う: 「正しさ」に基づく判断 長期的な判断 ■サービスの思想的に、設計的に、あるいは倫理や法律的に正しいかどうか、についてはカバーしてくれない。 例えばパスワードが簡単すぎたら警告を出す会員登録フォームと、文句言わずに受け付ける登録フォームとを比べたら、たぶん後者の方が登録率はよくなるわけですよ。あるいは、でかい広告と小さい広告を比べたら、クリック率は単純に面積に比例して大きくなる。 A/Bテストは、人間の本能的な、あるいはとても正直な反応をさらけだす仕組みだ。しかし人間の反射的な行動って、利己的だったり、後で大きな間違いにつながったりもしがち。人間が、深い考え無しに行動することで起こしがちな間違いは、そのままA/Bテストが起こしがち
nabokov7; rehash : 個人データをまとめて Glacier にバックアップする (ためのツールを公開しました)
October 21, 201216:02 カテゴリプログラミング公開やら広報やら 個人データをまとめて Glacier にバックアップする (ためのツールを公開しました) 海外に引っ越すにあたって、ちょっと心配だったのが手持ちのデジタルデータの保護。 今回、荷物を減らすために、持っていた本1500冊とCD500枚をすべてデジタル化して本体は処分してしまいました。(機会があればこれについても別途書く)。つまり、引っ越しの際HDDに何かあったらそれらの財産もすべてパーということ。 一応、PCのデータはネットワークストレージにもバックアップしてあるんだけど、結局PCもネットワークストレージも同じ引っ越し荷物に入るので、もし貨物まるごと紛失したり水没したりしたらバックアップの役を果たさないわけです。アメリカは荷物の扱いが雑だとも聞くし... こういうときこそクラウドにバックアップするのがいいので
nabokov7; rehash : 日々のインプットを絶やさないための，オンライン講義サイトのすすめ (coursera & udacity)
August 02, 201213:44 カテゴリサービス作りの話 日々のインプットを絶やさないための，オンライン講義サイトのすすめ (coursera & udacity) 意識高くオライリーの本を買い込んだりiTunesUの講義を見始めたりしたものの，途中で挫折してしまった経験はないですか。 本や動画による自習が続きにくい理由は 三日坊主になって続かない。ペース配分が自由すぎるため，だんだん間があいていって放置状態に至る。 受動的になりすぎる。ぼんやり分かったつもりで進んでていって，ある時点で急に理解がついていかない大きな壁にぶちあたり，挫折する。 といったあたりだと思う。 一番良いのは日々の活動がそのまま学習を兼ねることで，エンジニアなら，大規模サービスの運用だとかプログラミング言語だとかの習得の場としては現場に勝るものはない。でもそれではカバーできない領域もあるわけで，そんな時にお
nabokov7; rehash : ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(下)
March 10, 201213:50 カテゴリライブドアという会社の話をしよう ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(下) さて、前回からの続き。 社運をかけて招集された nowa の開発チームは、プログラマ、ディレクター、デザイナー、マークアッパ、どれをとっても精鋭チームというべき豪華な面子が勢揃いしていた。 一方の「旧ブログ」チームは、それまで一人でブログを支えて続けていたベテランのエンジニアが辞め、あとを僕ともう一人とで継いだものの、その片方の人も別会社に移って行ってしまって、エンジニアは僕一人だけになっていた。マネタイズのプランもなくただの金食い虫だった「旧ブログ」には大した長期戦略も与えられず、広告営業案件の狩り場と化して、宣伝用のブログパーツばかり作らされていた。 基本的に旧ブログチームの役割はデ
nabokov7; rehash : 蒟蒻畑コラ画像作者に謝罪させるような世の中じゃ、記者クラブだってクローズトなままだろう。
February 12, 201121:31 カテゴリ番組の途中ですがマジレスです 蒟蒻畑コラ画像作者に謝罪させるような世の中じゃ、記者クラブだってクローズトなままだろう。 蒟蒻畑にでかい注意書きが義務づけられ、ついにキレた生産者が「食べたら死にます」と袋にでかでかと印刷した...というネタ画像が話題になってた。 だけどこれ、結構多くの人が本気にしたらしくて、騒ぎが大きくなったあげくついに作者が謝罪をするに至ったらしい。 (↓本物はこっち) こんなの本気にする方がどうかと思うのだが、それでも「世間をお騒がせ」すると謝罪をしないといけないのが世の習わしらしい。いかにも日本らしくてくっだらねぇ。誰かが謝罪させたのか、作者が勝手に謝罪しちゃったのかは不明だけど、確かになんとなく騒ぎの責任を原作者に求めるような空気はあったようだ。リツイートの中には、騙された自分の情弱っぷりを棚に上げて「悪質なコラ
nabokov7; rehash : 就職時に必要だった身元保証書をまだ提出してない件
February 06, 201115:32 カテゴリ組織とyou 就職時に必要だった身元保証書をまだ提出してない件 ライブドアに移って丸5年が経過したんだけど、いまだに、就職時に提出を要求された身元保証書ってやつを提出してない。 ていうか何なのかね、あれ。 「この人のせいでもし会社が損害を被ったら私が責任を負います」という誓約を身近な人(多くの場合は両親)に、しかも住民票付きで提出させるというのが日本の企業の慣習らしい。だけどこれ、発想がおかしすぎるだろ ? まず、なんのためにお前は入社面接をしたのかと問いたい。履歴書や面接でふるいにかけてもまだリスクが0ではないのは分かるが、それは会社が負うべきリスクだ。それを会ったこともない第三者に負わせようという事なかれ主義全開の姿勢にはとことんがっかりさせられる。 僕の場合、入社の日、世はまさに「ライブドア事件」のまっただ中だった。 その中で、「
nabokov7; rehash : 誤差を○%以内におさめるには，サンプル数(標本数)がどれくらい必要か (補)
November 29, 201000:29 カテゴリ統計 誤差を○%以内におさめるには，サンプル数(標本数)がどれくらい必要か (補) このブログ、以前に書いた「誤差を○%以内におさめるには，サンプリング標本数がどれくらい必要か」という記事へのアクセス数がけっこうコンスタントにあるんですよね。自分でも時々必要になる情報なので、自分用メモも兼ねて書き留めておいたんだけど、いまみてみたらリンク先が軒並み not found になってる... というわけで、このページに簡易計算機を作っておきました。 例えば「あなたはこの番組を見ましたか? (yes/no)」というような質問を○人にして、その結果が yes○% : no○% だったときに、その誤差はどれくらいか」(あるいは誤差○％以内におさめるには最低何人に質問すべきか) を知りたいときに使います。必要とする精度からサンプル数を計算したり、回答
nabokov7; rehash : 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
nabokov7; rehash : かんたん！明日から出来る slowloris 対策
July 02, 200902:52 カテゴリネタ かんたん！明日から出来る slowloris 対策 slowloris という新手の dos 攻撃ツールが出てきたので対策を色々しらべていたのですが、意外な富豪メソッドもあることがわかりましたので一応メモ。 livedoor の各種サービスでも稼働実績のある f5 のロードバランサは、負荷分散のついでに SSL の処理までやってくれたりして、「f5 にできないことはない」「それ、f5 で出来るよ」などとも言われる魔法の箱です。そしてこれに Application Security Manager (ASM) のモジュールを追加するだけで、dosアタックをはじめ、いままでアプリケーション側で対応していたほとんどの対策を一手に引き受けてくれるのです。 slowloris の対応については記載が見当たらないのですが、ここを見ると、 Since
nabokov7; rehash : 検索流入率とRPMが相関関係にあるコンテンツと，逆相関になるコンテンツとがあるっぽい事
June 17, 200904:19 カテゴリ広告と正義と数字の話統計 検索流入率とRPMが相関関係にあるコンテンツと，逆相関になるコンテンツとがあるっぽい事 「検索エンジンからの流入率と、コンテンツマッチ広告の RPM (revenue per mille ... 1000PVあたりの収益) との間に相関関係がある」 かどうかが、ときどき話題にのぼります。 検索エンジンと広告の精度が共に十分高ければ、 そのページの内容は、検索エンジン経由でたどり着いた人がまさに探していた内容であり、 そのページに表示される広告もまた、訪問者が求めている情報に近い という状況が成り立つはずで、そういう理想的な状態では、検索流入率とRPMとが高い相関を示す (= 検索エンジン経由でやってきた訪問者は、広告をより高い確率でクリックする) はずなのです。 このことが実際の数値でも示せれば、例えば 検索エンジンか
nabokov7; rehash : 例えば1年後にユーザ数が100万人になるとしたら、半年後の時点のユーザ数は50万じゃなくて1000だよな?（副題：プラクティカル指数・対数）
April 08, 200902:07 カテゴリイントラブログより番組の途中ですがマジレスです 例えば1年後にユーザ数が100万人になるとしたら、半年後の時点のユーザ数は50万じゃなくて1000だよな?（副題：プラクティカル指数・対数） 例えばあるサービスのユーザ数が常に一定の倍率で増加し，一年で100万人に達したとすると，6ヶ月目の時点でのユーザ数は 100万x(6/12) = 50万人 ...ではなく、 100万(6/12) = 1000人 ...である。 つまり、「毎月ユーザ数が前月の約3.16倍になる、という増加率をキープすれば、半年後にはユーザ数が1000人になり、さらにその半年後には100万人に達する」ということ。 ただしこれは、最初に述べたように、ユーザ数が一定数ずつではなく、一定倍で増加するというモデルを前提にした計算結果だ。 ■ なんでこういう話をしだすかというと， no
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
