nabokov7; rehash : 「競合を見るな、顧客を見ろ」というおしえ。(あるいは「ジャパゾン」の志の低さについて)
December 23, 201316:29 カテゴリ 「競合を見るな、顧客を見ろ」というおしえ。(あるいは「ジャパゾン」の志の低さについて) > 「Amazonに対抗して「ジャパゾン」って本気ですか？」 企画自体の批評については、このリンク先の記事などで言い尽くされてるけど、まず第一に「ジャパゾン」って名称に致命的な問題がある気がした。 「ジャパゾン」のソースが朝日新聞しかないので、そう名付けたのが朝日なのかコンソーシアムなのかはよく分からないけど、発想というか志の点でジェフベゾス氏との違いが決定的。 ■ 今までいくつかの会社でCEOや社長の話を聞く機会があったけど、ジェフベゾス氏がひとつ飛び抜けていると思う点は、身内に話すときでも、競争相手の名前を挙げて「うちはこの点が優れてる」みたいな比較をしたり、競争相手を茶化すジョークを飛ばしたりということを一切しなかったこと。 たった一年在籍し
nabokov7; rehash : ヨーロッパ人、アメリカの企業の有給が二週間しかないと知って驚く。
October 23, 201111:35 カテゴリ組織とyou国民性の違いを県民性の違いみたいに話したい ヨーロッパ人、アメリカの企業の有給が二週間しかないと知って驚く。 先週あたり、google 社員による google+ dis (と、アマゾンdis) の長い文章がネット全体で話題になってた。全文日本語訳する人も現れたので見た人も多いと思う。 その原文を転載していた hackernews の転載記事のコメント欄で、誰かが「米アマゾンからオファーもらったけど、現職で有給四週間なのに二週間しかくれないっていうから断ったわwww」っていうレスを投下したことから話が膨らんで、各国の有給休暇の日数や労働時間の話でもりあがっていた。 興味深かったので、そのスレッドの部分だけ抜粋して紹介。 標準で四週間も有給がついてくるヨーロッパとオーストラリアでの経験のおかげで、完全に怠けグセがついちゃった。こ
nabokov7; rehash : 社会人の常識！正しい退職届の書き方
April 21, 201123:55 カテゴリ組織とyou 社会人の常識！正しい退職届の書き方 転職が決まったので退職届けを出しました。 ↑これに署名捺印したものを出したのだけど、誰も書き直せとも言ってこないので、どうやら無事受理された模様。 ■ というわけで、すでに何度か退職イベントをクリアして経験値を積んだ僕による、正しい退職届の書き方講座をお送りします。人間一度は必ず転職するのですから、知っておいて損はないと思います。 1.「一身上の都合」とかの定型文から脱却しよう 理由を書くんならはっきり書く、書かないなら書かない。「一身上の都合」などと何やら含みのあるような事言われても後味悪いですし、お前が辞めてからプライベートで家業を継ごうが、東南アジアに自分探しの旅に出ようが、会社の知ったことではありません。円満退社なら「じゃ俺次行くわ！」だけで十分です。いっぽう円満退社でない場合には「一
nabokov7; rehash : 就職時に必要だった身元保証書をまだ提出してない件
February 06, 201115:32 カテゴリ組織とyou 就職時に必要だった身元保証書をまだ提出してない件 ライブドアに移って丸5年が経過したんだけど、いまだに、就職時に提出を要求された身元保証書ってやつを提出してない。 ていうか何なのかね、あれ。 「この人のせいでもし会社が損害を被ったら私が責任を負います」という誓約を身近な人(多くの場合は両親)に、しかも住民票付きで提出させるというのが日本の企業の慣習らしい。だけどこれ、発想がおかしすぎるだろ ? まず、なんのためにお前は入社面接をしたのかと問いたい。履歴書や面接でふるいにかけてもまだリスクが0ではないのは分かるが、それは会社が負うべきリスクだ。それを会ったこともない第三者に負わせようという事なかれ主義全開の姿勢にはとことんがっかりさせられる。 僕の場合、入社の日、世はまさに「ライブドア事件」のまっただ中だった。 その中で、「
nabokov7; rehash : 2012春の新卒採用あらため，2011春の未経験者一括採用のためのテンプレート
December 08, 201010:23 カテゴリ組織とyou番組の途中ですがマジレスです 2012春の新卒採用あらため，2011春の未経験者一括採用のためのテンプレート ------------------------------------○○社に興味をもっていただき、ありがとうございます。 ■当社は、今年度より「新卒」採用を行いません。 古き良き昭和の時代、終身雇用と新卒採用はセットで日本の会社の仕組みを支える重要な基盤でした。同時に、社会人生活の重要な基盤であり、人生の目的でもありました。 しかしこれらは、現代の生き方や社会のしくみにはそぐわなくなっています。 1. 元来、会社での在籍年数と、年齢と、業務におけるレポートラインと、技術の高さと、給料の額と、人間的に尊敬されているかどうかは、それぞれ全く別の話であるべきです。しかし、新卒採用と終身雇用のセットが長らく「在籍年数=
nabokov7; rehash : 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
nabokov7; rehash : コーダーとかマークアップエンジニア、そしてデザイナの領域について
November 08, 200903:01 カテゴリサービス作りの話 コーダーとかマークアップエンジニア、そしてデザイナの領域について HTMLコーダーとかマークアップエンジニアのキャリアパスについて 言いたいのは、HTMLとCSSしかできない人の価値はこの先低くなっていくよねって事です（人材的な意味で）。 デザイナとコーダー(マークアップエンジニア) の仕事についてこの間同僚の人達と話す機会があったんですが、僕的に驚いたのは最近のwebデザイナってコーディングも出来るのが普通らしいってことでした。え、そうだったんだ ? 僕は約4年前にこの会社に転職してきました。前も似たような仕事はしてたんですが、そこではマークアップエンジニア的な職種はなく、デザイナがツールで画像を切り出したり、(table タグが何重にもなった) html を書き出して、それにプログラマが動きを与える、という進め方が
nabokov7; rehash : key-value store に特化したWAFとか、key-value store のみでランキングを効率よく管理する方法とか
November 15, 200912:12 カテゴリプログラミングネタ key-value store に特化したWAFとか、key-value store のみでランキングを効率よく管理する方法とか 同僚が新しい WAF(Webアプリケーションフレームワーク) を作っていて、その中で使うデータクラスの O/Rマッパーを何にするかで迷っているようだったので、こう叫んでおいた (心の中で)。 O/Rマッパーなど、SQLもまともに扱えない軟弱者があみだした不格好な補助輪にすぎない ! Webアプリケーションが重い理由の8割はO/Rマッパーのせいだ ! 漢なら SQL 直書きが当たり前 ! そうでなければ時代の流れに沿って key-value store 専用に設計すべき ! まあそんなこと言っても、現実には作業効率とか考えたら使うけどね、O/Rマッパー。 そんなことより、key-value
nabokov7; rehash : PubSubHubbub で最速に更新を通知しつつ，舌をかまないためのテスト
August 14, 200921:21 カテゴリイントラブログより PubSubHubbub で最速に更新を通知しつつ，舌をかまないためのテスト (先週 subscriber 対応したLDRに続いて) livedoor ブログも PubSubHubbub に publisher 対応しました。 PubSubHubbub は分散型の更新ping のようなものです。Publisher は Hub に更新を通知し，Subscriber は Hub から更新通知を受け取ります。Publisher は Hub にだけ更新を通知すれば済みます。複数の Subscriber へ通知する処理は Hub が肩代わりしてくれるし，Subscriber は自分が選んだ更新通知だけを受け取れるのでスパムの被害を抑えられるといった利点があります。 現在，http://pubsubhubbub.appspot.co
nabokov7; rehash : 広告以外の道は
March 26, 200910:01 カテゴリイントラブログより広告と正義と数字の話 広告以外の道は ライブドアブログの新管理画面には、あまり広告を入れるスペースがない。 後ろの列に座ってるディレクターのところに営業の人がやってきて、その新管理画面に広告を入れる入れないで押し問答をしていた。 ディレクター「いや、そこは広告が入るところじゃないんです」 営業「入れたっていいじゃないか」 ディレクター「なんでこの位置に広告を出すことにそんなに固執するんですか」 営業「なんでこの位置に広告を出さないことにそんなに固執するんですか」 周囲の誰も口を挟まなかったが、それは、その模様を社内IRCで実況中継するのに忙しかったからだ。 話が噛み合ない理由は、たぶんこういうことだ。そのディレクターにとっては、管理画面はユーザの持ち物で、一方、その営業の人にとっては、管理画面は広告主の持ち物だからだ。 だか
nabokov7; rehash : マイ・ブラックホール (2) - いかにして私はブラックホールに辿り着いたか
July 24, 200915:39 カテゴリmysqlプログラミング マイ・ブラックホール (2) - いかにして私はブラックホールに辿り着いたか ブログのアクセス解析用に使うストレージを選定するのに先だって，こんな条件下での速度比較をしてみた。 主な処理は，ブログ毎，あるいはページ毎のアクセス数のカウントアップ。つまり，ブログid & 記事id をキーとして，memcached なら set/incr, sqlなら insert 〜 on duplicate key update 〜 文の発行をする。200個のプロセスが，それぞれ平行して「あるキーのカウントアップ(書き込み) を行い，続いて別のキーの読み出しを行う」という処理を500回繰り返す。(合計10万回のカウントアップと10万回の読み出しに相当。)ストレージは，ベンチマークを行うスクリプトとは別のサーバ上にあり，必ずネットワーク
nabokov7; rehash : さまざまなPV
May 30, 200916:07 カテゴリサービス作りの話 さまざまなPV ここのところ、アメブロのPVや google ad planner の件で「ページビューって意外に大雑把な指標なんですよ」「ツールによって数字はまちまちです。でもそれは全部正しいんですよね」「PVの定義、ぶっちゃけ無い！」「ですよねー」...といった話が知られるようになってきたようだ。 PVなんて定義次第でなんとでもなるとか、アメブロの「PV」ってずるいよね、みたいな話はアクセスログの集計を業務でやったことがある人なら前からよく分かっていたはずのことではあるけど、こういった騒ぎでもなければ普通の人は「そんな細かいこと」をいちいち気にはしてくれないものだ。 せっかくなので、「そんな細かいこと」でどれくらいの違いが出て来るのか、実例を示してみたいと思う。 このブログだとアクセス数が少なすぎるので、ライブドアブログ開発
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ページを開く
