nabokov7; rehash : 馬鹿が可視化される時代とどう向き合うか (アメリカ式)
August 15, 201316:04 カテゴリちょっとアメリカ行ってくる 馬鹿が可視化される時代とどう向き合うか (アメリカ式) 日本では、あまりに暑いのでコンビニの冷凍庫に入っちゃいましたーって写真をアップしただけでえらいことになってるそうですな。 冷凍庫写真投稿の店再開断念、店員に賠償請求へ んーそんな騒ぎになっちゃってたのか。 冷蔵庫に入って写真をアップする人達を見て最初に思ったのは、日本は暑いんだなぁ、というただの感想でした。 こっちは寒いので羨ましいくらいだよ。てかカリフォルニアってサンシャイン降り注ぐパラダイスじゃなかったのかよ (勝手な誤解)。なんで8月にもなって暖房いれなきゃならんわけ？ それはともかく、 これをきっかけに 「馬鹿が可視化される時代」とどう向き合うか、という問題提起があっていろいろ議論されてるけど、こう考えたらどうか。 「身近な馬鹿は迷惑極まりないけど、
nabokov7; rehash : 個人データをまとめて Glacier にバックアップする (ためのツールを公開しました)
October 21, 201216:02 カテゴリプログラミング公開やら広報やら 個人データをまとめて Glacier にバックアップする (ためのツールを公開しました) 海外に引っ越すにあたって、ちょっと心配だったのが手持ちのデジタルデータの保護。 今回、荷物を減らすために、持っていた本1500冊とCD500枚をすべてデジタル化して本体は処分してしまいました。(機会があればこれについても別途書く)。つまり、引っ越しの際HDDに何かあったらそれらの財産もすべてパーということ。 一応、PCのデータはネットワークストレージにもバックアップしてあるんだけど、結局PCもネットワークストレージも同じ引っ越し荷物に入るので、もし貨物まるごと紛失したり水没したりしたらバックアップの役を果たさないわけです。アメリカは荷物の扱いが雑だとも聞くし... こういうときこそクラウドにバックアップするのがいいので
nabokov7; rehash : ライブドアという会社の話をしよう - Q8. ライブドアの他サイトパクリ路線についてはどう思ってた？
February 21, 201207:35 カテゴリライブドアという会社の話をしよう ライブドアという会社の話をしよう - Q8. ライブドアの他サイトパクリ路線についてはどう思ってた？ さて、事件後の話に移ろう。 - Q8. ライブドアの他サイトパクリ路線についてはどう思ってた？ 事件前からライブドアの「芸風」のひとつとして、他サイトのデザインを丸パクリする、というのがあったのだが、その話はちょっと置いといて、事件後最初のパクリ案件の話からはじめよう。 事件の数週間後にリリースされたQ&Aサービス (ライブドアナレッジ) のデザインが、米Yahoo! の Yahoo! Answers 丸パクリだったことが波紋を呼んだ。 「ネットサービス“そっくりさん”登場のなぜ」 「ちょっと似すぎでは」――ライブドアが2月8日に公開したQ＆Aサービス「livedoor knowledge」が、一部ネッ
nabokov7; rehash : 社会人の常識！正しい退職届の書き方
April 21, 201123:55 カテゴリ組織とyou 社会人の常識！正しい退職届の書き方 転職が決まったので退職届けを出しました。 ↑これに署名捺印したものを出したのだけど、誰も書き直せとも言ってこないので、どうやら無事受理された模様。 ■ というわけで、すでに何度か退職イベントをクリアして経験値を積んだ僕による、正しい退職届の書き方講座をお送りします。人間一度は必ず転職するのですから、知っておいて損はないと思います。 1.「一身上の都合」とかの定型文から脱却しよう 理由を書くんならはっきり書く、書かないなら書かない。「一身上の都合」などと何やら含みのあるような事言われても後味悪いですし、お前が辞めてからプライベートで家業を継ごうが、東南アジアに自分探しの旅に出ようが、会社の知ったことではありません。円満退社なら「じゃ俺次行くわ！」だけで十分です。いっぽう円満退社でない場合には「一
nabokov7; rehash : ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(上)
March 08, 201222:49 カテゴリライブドアという会社の話をしよう ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(上) 事件直後の話はこのへんで切り上げて、その後の、あまりぱっとしなかったサービスの話をいくつかしていこう。 - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？ nowaってみんな知ってますかね… → ライブドア、新ブログサービス「nowa」の一般向け公開を開始 (2007年5月30日) Six Apart の VOX という新ブログサービスを参考に、ブログと SNS と twitter と tumblr と irc を全部あわせたような様々な機能を備えた次世代ブログが nowa だった。 この頃は丁度、web2.0という言葉がもてはやされ、ライトユーザ間のゆる
nabokov7; rehash : ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(下)
March 10, 201213:50 カテゴリライブドアという会社の話をしよう ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(下) さて、前回からの続き。 社運をかけて招集された nowa の開発チームは、プログラマ、ディレクター、デザイナー、マークアッパ、どれをとっても精鋭チームというべき豪華な面子が勢揃いしていた。 一方の「旧ブログ」チームは、それまで一人でブログを支えて続けていたベテランのエンジニアが辞め、あとを僕ともう一人とで継いだものの、その片方の人も別会社に移って行ってしまって、エンジニアは僕一人だけになっていた。マネタイズのプランもなくただの金食い虫だった「旧ブログ」には大した長期戦略も与えられず、広告営業案件の狩り場と化して、宣伝用のブログパーツばかり作らされていた。 基本的に旧ブログチームの役割はデ
nabokov7; rehash : ライブドアという会社の話をしよう - Q1. NHNとの統合はうまくいくと思う？
January 28, 201212:57 カテゴリライブドアという会社の話をしよう ライブドアという会社の話をしよう - Q1. NHNとの統合はうまくいくと思う？ 2011年を最後に古巣のライブドアという会社はNHN Japanに統合されて、書類上は消滅したようだ。 もっとも、もともと半年に一度は組織変更がある会社だったし、中の人的には看板が変わっただけで特に大きな出来事という実感はないのかもしれない。 でも、僕も5年あまりそこにいたし、Webに関する技術や空気感や、様々なことをそこで学んだ。だから、今でもwebについて自分が語れることはそこに軸をおいたことがらばかりだ。この会社の一番エキサイティングな5年間ではなかったかもしれないけど、その間に僕の立場で見聞きしたことや考えたことを、この機会にまとめておこうと思う。 - Q1. NHNとの統合はうまくいくと思う？ すぐに大きなシナジー
nabokov7; rehash : ライブドアという会社の話をしよう - Q2. NHNに買収されたとき、現場としてどんなことを期待した？
January 30, 201223:46 カテゴリライブドアという会社の話をしよう ライブドアという会社の話をしよう - Q2. NHNに買収されたとき、現場としてどんなことを期待した？ 前の記事の続き。 NHN関係でついでにもうひとつ。 - Q2. NHNに買収されたとき、現場としてどんなことを期待した？ 最初に親会社の森川社長がオフィスを通りがかったとき、僕は畳ユニットを椅子にしており、「会社がまともな椅子ひとつくれないのでかっとなって自腹で購入しました」と軽口叩いたら(だいたい事実) 翌月くらいには全社にアーロンチェアが配られたのはすごいと思いました。それは今でも感謝しておりますがほんとうに現場として期待していたのは椅子が新しくなること、ではなくて、えーと… 成長させるべきエリアへ存分にリソース投入できるようになること、だったな。 …ASIMOの開発者が「歩くとは前に倒れ続けること
nabokov7; rehash : ライブドアという会社の話をしよう - Q3. アメブロの芸能人ブログ戦略をどう思ってた？
February 04, 201219:21 カテゴリライブドアという会社の話をしよう ライブドアという会社の話をしよう - Q3. アメブロの芸能人ブログ戦略をどう思ってた？ - Q3. アメブロの芸能人ブログ戦略をどう思ってた？ アメブロが芸能人の囲い込みで力をつけ、他社を華麗に抜き去りつつあったのは、ライブドア事件の一年後ぐらい、2006年終盤〜2007年頃のことだ。 ちなみにライブドアブログは事件前までは会員数ではダントツの首位で、事件(2006年1月)後もそれでひどく落ち込む訳ではなかった。ただ、激しく追い上げるFC2とアメブロに対し、ただ現状維持だけを続けていたライブドアブログの状況がこの記事の下の方のグラフから良く分かると思う。 →有名人・芸能人ブログ人気でアメ−バ躍進 この頃、ライブドアブログがアメブロと同じような、芸能人ブログを中心とした集客・マネタイズモデルに進まなかっ
nabokov7; rehash : 蒟蒻畑コラ画像作者に謝罪させるような世の中じゃ、記者クラブだってクローズトなままだろう。
February 12, 201121:31 カテゴリ番組の途中ですがマジレスです 蒟蒻畑コラ画像作者に謝罪させるような世の中じゃ、記者クラブだってクローズトなままだろう。 蒟蒻畑にでかい注意書きが義務づけられ、ついにキレた生産者が「食べたら死にます」と袋にでかでかと印刷した...というネタ画像が話題になってた。 だけどこれ、結構多くの人が本気にしたらしくて、騒ぎが大きくなったあげくついに作者が謝罪をするに至ったらしい。 (↓本物はこっち) こんなの本気にする方がどうかと思うのだが、それでも「世間をお騒がせ」すると謝罪をしないといけないのが世の習わしらしい。いかにも日本らしくてくっだらねぇ。誰かが謝罪させたのか、作者が勝手に謝罪しちゃったのかは不明だけど、確かになんとなく騒ぎの責任を原作者に求めるような空気はあったようだ。リツイートの中には、騙された自分の情弱っぷりを棚に上げて「悪質なコラ
nabokov7; rehash : 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
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 : マイ・ブラックホール (2) - いかにして私はブラックホールに辿り着いたか
July 24, 200915:39 カテゴリmysqlプログラミング マイ・ブラックホール (2) - いかにして私はブラックホールに辿り着いたか ブログのアクセス解析用に使うストレージを選定するのに先だって，こんな条件下での速度比較をしてみた。 主な処理は，ブログ毎，あるいはページ毎のアクセス数のカウントアップ。つまり，ブログid & 記事id をキーとして，memcached なら set/incr, sqlなら insert 〜 on duplicate key update 〜 文の発行をする。200個のプロセスが，それぞれ平行して「あるキーのカウントアップ(書き込み) を行い，続いて別のキーの読み出しを行う」という処理を500回繰り返す。(合計10万回のカウントアップと10万回の読み出しに相当。)ストレージは，ベンチマークを行うスクリプトとは別のサーバ上にあり，必ずネットワーク
nabokov7; rehash : マイ・ブラックホール (1) - ブラックホールとほしのこえ
July 16, 200902:18 カテゴリmysqlイントラブログより マイ・ブラックホール (1) - ブラックホールとほしのこえ ブログのアクセス解析のリプレースのために，大量のアクセスログデータを mysql に投入する。 マスター - スレーブ構成のマスター側は blackhole エンジンを使うことにした。どんなSQLを投げても何も保存しない、何も結果を返さない、ひたすら処理を無視するだけの文字通りのブラックホール。 何もしないので、もちろん処理は高速だ。そんなのDBとして無意味じゃないかと思うかもしれないけど、通常のDBの前段に入れてやると、入力バッファの役割を果たしてくれるのだ。 問題は、一気に大量のデータをバッチで投入したときのマスターとスレーブの処理速度の違いだ。スレーブは普通の (つまり、ディスクにデータをちゃんと保存する) DBなので、バッチ処理中はスレーブの処理
nabokov7; rehash : 会社を横断して交流するのが盛んな業界ほど、健全性が高い
June 21, 200912:56 カテゴリ番組の途中ですがマジレスです 会社を横断して交流するのが盛んな業界ほど、健全性が高い 丁度こんな↓ポストが話題になってたので、最近思ってたことを少し: 人材流出リスク対策の為、弊社では社外勉強会への参加を自粛する様、お達しがでました。（涙） Twitter / understeer まずその一。 会社を横断して交流するのが盛んな業界は、健全性を保ちやすい。 横のつながりが無い場合、「慣習」とか「常識」が同じ会社、同じ部署内のごく少数の間でクローズドになってしまい、いつの間にか変な独自進化を遂げてしまうことがある。(?Bの関連エントリにこんなのも見つけたw) A社では上司が「この書類のここんとこ、ちょっと書き換えとけ ! こんなのどこでもやってるから !」と部下を叱咤し、一方のB社ではそんなことやったらクビがとぶのが当たり前、みたいな、いびつなロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
