プロダクトマネージャーについて - naoyaのはてなダイアリー
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･い
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
「書く」のは特別な道具 - naoyaのはてなダイアリー
This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。 コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。 今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが
Vagrant + Chef Solo + serverspec + Jenkins でサーバー構築を CI - naoyaのはてなダイアリー
Jenkins おじさんと戯れること半日、うまくいったので備忘録を残しておく。 やりたかったのは Chef で構築したサーバーを Jenkins で CI する、というもの。このときサーバーはテストが終わる度に破棄して、テスト開始時に再度真っ新な状態から立ち上げたい。(こういうサーバーを壊して作ってというテストはなんという名前で呼ばれるのだろう?) 仮想サーバーを破棄/作成をプログラマブルにやるのはもちろん Vagrant プロビジョニングは Chef Chef の環境を整えるのに knife-solo 0.3.0.pre3 テストは serverspec コードは Github に上げる (https://github.com/naoya/jenkins-vagrant-test) CI は Jenkins という構成になっている。ひとまず Jenkins や Vagrant はローカル
昨今のWebアプリケーションのひな形その2 - Grunt - naoyaのはてなダイアリー
昨日の続き。 こういうアプリケーションのテンプレートを管理するのに便利な仕組みはないですかねーと言っていたら @teppeis さんや @omo2009 さんに Grunt や Yeoman はどうかと教えてもらった。 Grunt はユースケースとしては JavaScript の連結や圧縮、SCSS/LESS なんかのメタ言語のコンパイルをするときに使うもの、つまり rake なんかと同じようなものと以前にチラ見した程度で知った気になっていたけども、ちょっと違っていた。Grunt は確かにタスクランナーではあるのだが、Node.js で実装している利点を十分に活かして、任意のファイルが更新されたのをトリガに一連のタスクを実行させたり、Grunt で Webサーバーを立ち上げて他のタスクと連携させたりといったことができるようになっている。プラグインの仕組みがあって、エコシステム的に結構活発に
Vagrant 1.1 で EC2 を vagrant up - naoyaのはてなダイアリー
Vagrant 1.1 がリリースされました。 Vagrant は仮想サーバーのフロントエンドのツール、詳しくは Vagrant - naoyaのはてなダイアリー あたりを。 で、この 1.1 が 1.0 → 1.1 という割に結構大きなアップデートで新しく VM に VirtualBox 以外のものが選択できるようになった。すなわち「VirtualBox のフロントエンド = Vagrant」から「各種仮想マシンのフロントエンド = Vagrant」という風にアップデートされた。 今回の 1.1 からVMを操作するproviderがプラグイン構造となり、VirtualBoxだけならず、公式で操作できる対象が増えました。 VirtualBox VMware Fusion Amazon EC2 + VPC Rackspace Cloud VMware Fusion以外はオープンソースで公開さ
ファーストサーバ社の障害に関して - naoyaのはてなダイアリー
あまりまとめられないので箇条書きで。 「クラウド (IaaS)」と「レンタルサーバ」の区別 技術的には「クラウド (における IaaS)」と「レンタルサーバー」は明確に異なるものなので、そこは混同されないことをおすすめしたい 今回障害が起こったファーストサーバのサービスはレンタルサーバであって、クラウドサービスではないだろう クラウド = Amazon Web Services (AWS) や Heroku がその代表例だと思ってもらえばいい *1 具体的には、日経新聞の当該記事のこと → http://www.nikkei.com/article/DGXNASFK2600L_W2A620C1000000/ 意図は不明だが「クラウド」のような目新しいものと今回の事件とを結びつけて何かしらの印象を与えようとするのは、個人的には感心しない 業者が「クラウド」と謳っていたかどうかは知らない。例え
退職のお知らせ - naoyaのはてなダイアリー
本日8月31日をもって、はてなを退職しました。 入社は2004年9月1日でしたから、今日でちょうど6年です。6年間の間に、はてなブックマークをはじめとする各種サービスの企画開発やディレクション、インフラの構築、技術チームのマネジメント等々、色々な経験を積むことができました。その一方で、なかなか自分の思うようにはサービスを成長させる、会社を伸ばすことができず自分の力量不足を感じる毎日でもありました。その足りない能力と経験を埋め合わせる日々が、成長を促してくれたとは思います。 この6年は、はてなという会社が、個人あるいは家族のような繋がりから組織に変っていく過程でした。会社というものが何なのかを全然知らなかった自分が、Webサービスの開発と運営に、組織がなぜ必要かというのを体で知ることになりました。なかなかに得難い経験でした。 遠回りもありましたが、はてなは組織になりました。新サービスは日々ユ
naoyaのはてなダイアリー - 大規模サービスを展開する企業が陥るジレンマ
このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。 一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。 はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュー
GNU screen いろいろまとめ。 - naoyaのはてなダイアリー:
先日人力検索で GNU screen の設定TIPSについて質問してみたところ、かなーり役立つ設定とかをたくさん教えてもらうことができました。みなさん感謝。 そんで、教えていただいた通りにカスタマイズした結果、こんな感じのスクリーンショットが撮れました。MacOSX のターミナルです。 おかげさまでかなり便利になって作業効率が上がったと思います。いろいろ教えてもらったお礼とまではいきませんが、やった設定とかをはまりどころとかも交えて紹介してみます。名付けてリバースNDOメソッド。ちなみに、知ってる人にはごく当然のことが当たり前のように書いてるので、あんまり役に立たないかもしれません。 hardstatus alwayslastline で最終行にウィンドウ一覧を表示 これは今回の質問とは直接関係ないのですが、やるとやらないとでかなり使い勝手が違うので。 hardstatus alwaysl
naoyaのはてなダイアリー - Perlプログラマのレベル10 - Perlプログラミング救命病棟より
プログラマ、と一言で言っても、if文の意味をようやく理解したばかりの駆け出しのプログラマもいれば、汎用的で優れたライブラリを量産できるような凄腕のハッカーもいる、つまりはピンきりです。 Perlプログラマに関してはどうでしょう。一流のPerlプログラマになるためには、見えない階段があるようです。use strict を使い始めたらその階段を一歩上ったと言えるでしょうし、正規表現を理解したときも一段あがることになると思います。リファレンス、クロージャ、オブジェクト指向、CPANモジュール、mod_perl、MVCフレームワーク。それらも階段を構成する材料の数々と言えるでしょう。 さて、Perlプログラミング救命病棟という書籍から、ちょっと長いですがそんなPerlプログラマのレベル10のリストを引用してみます。 レベル1: Perl 関係の書籍や資料を何も読んでいない。Perl がプログラミン
naoyaのはてなダイアリー - onsubmit で submit ボタンを disable にしてユーザビリティを良くする
先の Yahoo! Shopping のアプリケーションで、今度ちょっとやってみようと思ってたことを実装してみた。 http://bloghackers.net/~naoya/ys/app.cgi ボタンを押したときに、そのボタンが disable になります。この方法を使うとボタンが押されて次の処理に入ろうとしているというのが直感的に分かるのと、二重送信防止にもなるということでユーザビリティが改善できます。 仕掛けはすごく簡単で、form の onsubmit ハンドラに、その form に紐づく submit ボタンを disable になるような JavaScript を登録しておくだけ。 function disableSubmit(form) { var elements = form.elements; for (var i = 0; i < elements.length;
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
