プロダクトマネージャーについて - naoyaのはてなダイアリー
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･い
「リーン」について : 「何を作るか」よりも「何を作らない」か - naoyaのはてなダイアリー
2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN) という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。 書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。 仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す･･･というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─
Treasure Data - naoyaのはてなダイアリー
少し前にログの話を書いた http://d.hatena.ne.jp/naoya/20130219/1361262854 ときに、Treasure Data については後日にもう少し詳細に書くと言ったので書くとしよう。 近頃 Treasure Data (以下、時折 TD) という名前をちらほら聞いたことがある人は多いのではないかと思います。「ビッグデータのクラウドサービスである」とか「日本人が創業したシリコンバレーのベンチャー」、あるいは Yahoo! 創業者の Jerry Yang が投資したとか、Fluentd と何か関係があるといった文脈などなど。 けど、具体的に Treasure Data がどういうサービスで、どういう機能を持っていて、どんな場面で利用されるものなのかはまだあまり良く知られていないかもしれない･･･ようにも見える。今日はその辺から少し紹介していこうかなと思う。
「書く」のは特別な道具 - naoyaのはてなダイアリー
This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。 コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。 今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
AWS Summit Tokyo 2013 - naoyaのはてなダイアリー
一昨日、昨日と東京は品川で開催された AWS Summit Tokyo 2013 に行ってきた。 全般的な印象としてはエンタープライズトラックがたくさんあったし来場者もスーツを着た人も多くて、AWS を取り巻くステージは去年一年くらいで完全にエンタープライズ側に移行しきったんだなあ、というものだった。もちろんテクノロジートラックやコンシューマートラックもあって、技術的な実装やテクニックにフォーカスしたような話も方々でなされていたんだけど、多くの来場者の関心事は如何にしてクラウドをエンタープライズに導入するか、あるいはそれによってビジネスの課題を解決するかというところにあった、というのが肌感覚としてあった。 自分は AWS、というか IaaS はハードウェアを抽象化してソフトウェアでそれ全体を扱えるようにしたというところが本質的で、自動化、DevOps、あるいはプログラミングのための道具とし
昨今の自分用Webアプリケーションひな形 - naoyaのはてなダイアリー
ちょっと jQuery と簡単なサーバサイドの処理を組み合わせた処理を試しに書いてみよう･･･なんて時に、いちいち jQuery を取ってきて HTML を書いて script タグを書いてロードして sinatra 立ち上げて云々･･･というのが毎度面倒なので、ひな形になるアプリケーションを作った。 https://github.com/naoya/boilerplate ひとまず sinatra でサーバーサイドを書き、HTML は slim で、CSS は sass 。JavaScript は CoffeeScriptで書くにあたって jQuery、underscore、Backbone をロードしてある、というような構成にしてあります。 まあ、この類のことは人それぞれ自分なりにカスタマイズしてやっていると思いますが、どういうコンポーネントで構成しているかを、備忘録も兼ねてちょっと紹
iOS版Chrome リリースに見るiOSプラットフォームの制約 - naoyaのはてなダイアリー
iOS版の Chrome がリリースされましたね。 アプリとしての使い勝手どうこうというところよりも、JavaScript エンジン周りをどうしているのかに興味があったのだけど、TechCrunch の記事 (http://techcrunch.com/2012/06/28/hands-on-with-googles-chrome-for-ios-just-like-chrome-for-android-only-slower/) を見る限り v8エンジンは搭載されていないし、当然 UIWebView での JIT コンパイラも有効にはなっていないように見えました。つまり、JavaScript の実効速度に関して言えば、Mobile Safari のそれを上回ることはない。(厳密に言えば、純粋な JavaScrpit の実効速度以外のところの実装が良くてトータルとして速い、というようなこと
HBFav というはてなブックマーク iPhone アプリを作りました - naoyaのはてなダイアリー
ちょこちょこと余暇の時間を使って、HBFav という iPhone アプリを作りました。 HBFav は、はてなブックマークの「お気に入り」機能を閲覧するためのアプリです。はてなブックマークの「お気に入り」は、気に入ったユーザーがブックマークしたブックマークを一覧する機能、つまり、Twitter で言うところのタイムラインです。それを見る専用のアプリがほしかった、ということで作ったものです。 ･･･ということで、繰り返すと、HBFav はタイムライン形式でソーシャル・ブックマークを楽しむためのアプリ。はてなブックマークのお気に入り機能を活用しているぜ! という方におすすめです。 HBFav は、App Store からインストールできます。 App Store - HBFav : http://itunes.apple.com/app/id477950722 Kindle とともに HBF
Mojolicious::Lite で WebSocket を使ったチャットを作る - naoyaのはてなダイアリー
node.jsの衝撃とWebSocketが拓く未来 (1/2)：WebSocketで目指せ！ リアルタイムWeb（1） - ＠IT という記事を読みました。node.js という V8 を用いたサーバーサイド JavaScript フレームワークを使うと簡単にイベント駆動のサーバが書ける、node-websocket-server.js を使うと node.js で WebSocket サーバが実装できる。Ajax による polling や Long Polling などと WebSocket のアーキテクチャ比較といった内容でした。 WebSocket を使うと手軽にサーバプッシュ的なアプリケーションが作れて嬉しいのですが、現時点では、HTTPサーバー側で WebSocket を処理する下地の実装をどう用意するかというところがひとつ課題でしょう。node.js はその回答のひとつとして
はてなブックマークの裏側その後 - naoyaのはてなダイアリー
まるごとPerl! Vol.1 で執筆させていただいたはてなブックマークのシステムに関する記事が ThinkIT で読めるようになりました。記事全体を何回かにわけて掲載していただいています。まるごとPerlの記事なのですが、実は Perl のことはあまり触れていなくてはてなのサーバー運用概論みたいは話が主なところです。 http://www.thinkit.co.jp/free/article/0610/1/1/ http://www.thinkit.co.jp/free/article/0610/1/2/ せっかくなので現状報告も含めて少し補足をしてみようかなと思います。 現在の数字 記事の中での数字は6月のもので ユーザー：45,000人 ブックマーク数：535万件 ページビュー：5,000万/月 サーバー：17台 となってますが、現在 10 月の方はというと ユーザー: 60,000
B木 - naoyaのはてなダイアリー
昨年から続いているアルゴリズムイントロダクション輪講も、早いもので次は18章です。18章のテーマはB木(B Tree, Bツリー) です。B木はマルチウェイ平衡木(多分木による平衡木)で、データベースやファイルシステムなどでも良く使われる重要なデータ構造です。B木は一つの木の頂点にぶら下がる枝の本数の下限と上限を設けた上、常に平衡木であることを制約としたデータ構造になります。 輪講の予習がてら、B木を Python で実装してみました。ソースコードを最後に掲載します。以下は B木に関する考察です。 B木がなぜ重要なのか B木が重要なのは、B木(の変種であるB+木*1など)が二次記憶装置上で効率良く操作できるように設計されたデータ構造だからです。データベースを利用するウェブアプリケーションなど、二次記憶(ハードディスク)上の大量のデータを扱うソフトウェアを運用した経験がある方なら、いかにディ
第11回 Kansai.pm / スペルミス修正プログラムを作ろう - naoyaのはてなダイアリー
昨日は第11回 Kansai.pm でした。 今回は無理を言って自分がホストを担当させていただきましたが、面白い発表が多く開催した自分も非常に満足でした。 PFI の吉田さんによる Cell Challenge での計算機に合わせたアルゴリズムのチューニング手法の発表 (発表資料) は圧巻でした。伊奈さんの本文抽出の話 (発表資料)、はこべさんのコルーチンの話 (発表資料)、いずれも難解になりがちなところを凄く分かりやすく解説されていて、さすがだなと思いました。各々ショートトークも、いずれも良かったです。 スペルミス修正プログラムを作ろう 自分も 20 分ほど時間をいただいて、スペルミス修正プログラムの作り方について発表しました。 スペルミス修正プログラムを作ろうView more presentations from Naoya Ito. スペルミス修正プログラムについてはずばり スペル
第2回 アルゴリズムイントロダクション輪講 - naoyaのはてなダイアリー
今日は id:motemen 主催のアルゴリズムイントロダクション輪読会 第2回でした。 現在弊社では今年のインターンシップを 2回目(年に2回のうちの後半) 開催中ですが、先月まで来てくれていたインターン一期生も数名輪読会に参加し、東京オフィスからも数名参加、お客さんも増えて大変盛り上がりました。 輪講第2回の今日の発表は自分が担当で、内容は「第4章 漸化式」でした。アルゴリズム計算時間の漸近的限界を得るため、再帰アルゴリズムの計算時間の漸化式を解きます。4章では漸化式の解法として置き換え法、再帰木、分類法が紹介されています。 アルゴリズムイントロダクションの第一巻は、前半しばらく計算量の話が続きます。6章からようやくソートアルゴリズムの話に入ります。次回5章は「確率論的解析と乱択アルゴリズム」です。 数学的基礎とデータ構造 (アルゴリズムイントロダクション) 作者: T.コルメン,R.
あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー
お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは top や ps などで調べると良いでしょうか。例えば手元の coLinux で top して M キーでソートすると emacs のプロセスが最もメモリを使っているようです。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1923 naoya 18 0 23120 19m 3096 S 0.0 2.0 0:55.40 emacsメモリサイズは VIRT と RES がありますが、VIRT は Virtual の略で仮想メモリ領域のサイズ、RES が Resident の略で、実際に使用している物理メモリ領域のサイズ。19MB ほど使っているようです。この emacs のプロセスが利用するメモリ領域はざっくり 20MB 程度と
勉強、学ぶ - naoyaのはてなダイアリー
先週、サポートのアルバイトスタッフと、プログラミングの話題になった。プログラミングを勉強している、とのことだった。もちろん、自分は「それを続けると良いと思う」ということを言った。 少し前の自分だったら「プログラミングの勉強を続けると良いと思う」という言葉は、嫉妬や羨望、あるいは自己肯定からの言葉だったのではないかと思う。今もそういう部分がないとは言い切れないが、以前とは少し違っているように思う。 このスタッフがプログラムを書けるようになったとして、それが直接仕事に役に立つかどうかは本人次第だと思う。"直接的に役に立つ"という保証はない。 そういうことではない。 何かシステム的なトラブルが起こったとき、自分ではない誰かが何かの操作で困っているとき。プログラムの世界についての知識、慣れ、経験があると、第六感が働くようになる。プログラムのおかしな挙動の、その振る舞いだけを見て、原因がどのあたりに
中島さんと古川さんの対談 - naoyaのはてなダイアリー
中島聡さん の おもてなしの経営学 アップルがソニーを超えた理由 (アスキー新書) を読みました。とにかく古川さん との対談が面白い。「経営学」と題している書籍ではあるのですが、この対談の箇所だけを抜き取ると、一人のソフトウェアエンジニアがどのようにして未来を切り開いたかというエンジニア論の体をなしています。 著者の中島さんの blog ははてなブックマークでも人気エントリーの常連なので、ご存じの方も多いことかと思います。 ところで 1998 年に、マイクロソフトがブラウザ戦争 (wikipedia:ブラウザ戦争)の結果、独占禁止法で提訴されたことがありました。個人的にはネットスケープがマイクロソフトにボコボコにされて「もうやめて、ネットスケープのライフは 0 よ!」と勝敗が完全についた区切り/象徴である事件だと認識していて、当時はまだそれほど IT ビジネスに関心がなかったにも関わらず興
ソフトウェア技術者としての残り時間 - naoyaのはてなダイアリー
年始の NHK でのイチロー特集番組を見ていて一番印象に残ったのは、他の人の道具を絶対に触らないというイチローのこだわりでした。曰く、人の道具を触るとその道具の感覚が体に残ってしまい、自分の道具を利用するときの感覚の妨げになるから、ということでした。全体を通して、イチローは他のプレイヤーとの相対的な競争の中に身を置いているのではなく、絶えず自分を改良し続けるという過程の中にいるのだというのがよくわかる内容でした。良い番組だったと思います。 気づけば自分も 30 歳になりました。まだ若いとは思っていますが、さすがに 20 代の頃に比べると、病気や怪我の治りが少し遅くなったと感じることもあり、少しずつ自分の人生、「死」ということを考えるようにもなりました。時間は有限ということが少しずつ実感できるようになってきました。あるいは実感できるようになってしまった、と言った方が良いかもしれません。 ここ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
