プロダクトマネージャーについて - naoyaのはてなダイアリー
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･い
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
些末なコードレビュー - naoyaのはてなダイアリー
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
ポータブルなWebアプリケーション - naoyaのはてなダイアリー
140文字で書ききれなかったのでブログに殴り書き。 Heroku のアプリケーションを人に渡す 昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。 対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。 対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかは
「書く」のは特別な道具 - 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サイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
HBFav2 をリリースしました - naoyaのはてなダイアリー
http://hbfav.bloghackers.net/ 1年以上前に HBFav という、はてなブックマークの「お気に入り」を読むための iOS アプリを作ってリリースしましたが、今回一から実装し直してバージョン 2.0 という形で先ほどリリースしました。App Store からダウンロード可能です。 HBFav って? HBFav は、はてなブックマークで「お気に入り」に追加している、すなわちフォローしているユーザーのブックマークやコメントをタイムラインのようにして閲覧するアプリです。個人的にはてなブックマークで最も重宝しているのがお気に入り機能で、そのユースケースを中心にしたアプリが欲しくて作ったというのが元々の動機でした。 なんで作り直したの? バージョン 1.0 はあまり時間の無い中コンセプト優先で作ったということもあってお世辞にも品質が良いとは言えない代物でした。重たいし、落
AWS Summit Tokyo 2013 - naoyaのはてなダイアリー
一昨日、昨日と東京は品川で開催された AWS Summit Tokyo 2013 に行ってきた。 全般的な印象としてはエンタープライズトラックがたくさんあったし来場者もスーツを着た人も多くて、AWS を取り巻くステージは去年一年くらいで完全にエンタープライズ側に移行しきったんだなあ、というものだった。もちろんテクノロジートラックやコンシューマートラックもあって、技術的な実装やテクニックにフォーカスしたような話も方々でなされていたんだけど、多くの来場者の関心事は如何にしてクラウドをエンタープライズに導入するか、あるいはそれによってビジネスの課題を解決するかというところにあった、というのが肌感覚としてあった。 自分は AWS、というか IaaS はハードウェアを抽象化してソフトウェアでそれ全体を扱えるようにしたというところが本質的で、自動化、DevOps、あるいはプログラミングのための道具とし
WEB+DB PRESS で連載を始めます - naoyaのはてなダイアリー
WEB+DB PRESS Vol.74posted with amazlet at 13.04.16井上 誠一郎 奥野 幹也 田中 慎司 西嶋 悠貴 伊藤 直也 登尾 徳誠 天野 祐介 後藤 秀宣 ヒノケン 近藤 宇智朗 近藤 嘉雪 渡邊 恵太 堤 智代 中島 聡 A-Listers はまちや2 川添 貴生 技術評論社 売り上げランキング: 1,303 Amazon.co.jpで詳細を見る 今月 24 日発売の Vol.74 ですが、よーくみると「RubyMotion入門」と言う文字が見え隠れしますね。 ･･･失礼しました。 ひ、久しぶりに WEB+DB PRESS に記事を書いたと思ったらなぜか連載が始まっていた･･･! ドラクエばかりしててろくに外にも出ない ひょんな折り CROSS 2013 で久しぶりに編集の稲尾さんと会ったところ、いかにも暇そうだと思われたのでしょう、記事書きませ
Kindle向けに『入門Chef Solo - Infrastructure as Code』を出版しました - naoyaのはてなダイアリー
Chef のスタンドアロン版である Chef Solo の技術書を Kindle 向け電子書籍として出版しました。 入門Chef Solo - Infrastructure as Codeposted with amazlet at 13.03.17伊藤直也 (2013-03-11) 売り上げランキング: 14 Amazon.co.jpで詳細を見る がんばりました。原稿＼(^o^)／オワタ Chef Solo 本 Chef はサーバー/インフラの状態管理フレームワークです。より単純化して言うならサーバー構築の自動化ツール。コードは Ruby で書きます。ウェブアプリケーションをホストするサーバーの管理にもちろん利用できますし、チームメンバーの開発環境を同じ状態に揃える、あるいは個人の開発環境の整備を自動化する、といったことにも利用できます。 本書の内容のは、その Chef の入門書です。C
権限委譲、リーダーシップ、チーム - naoyaのはてなダイアリー
いいか、覚えておけ。おれにしてもお前にしても、それなりに成功するってことは、なにかは得意なんだ。でも大体のことは不得意極まりない。全部自分でやろうとするな。自分よりも何かで優れている人たちが、その何かでお前のためにチカラを貸したいと思うような人間になれ。 それがリーダーってもんだよ。 この記事が話題になってた。リーダーシップというのは力を貸してやろうと相手に思われることだという、いい話。 この手の話は、誰もが否応なしに社会で経験することだから、みんなそれぞれ自分の考えを述べたくなる･･･という話題でもありますね。例に漏れず、自分も少し経験から感じることを書いてみよう。 「権限」を「委譲」する? 「上司が何かを部下に任せる」という文脈でいくと、このストーリーは「権限委譲」の話にもみえる。確かにテーマとしてはそうなのだが、自分は一般で言う「権限を委譲する」という考え方そのものにちょっとした落と
開発メモ#6 : ログの取り扱い : GrowthForecast, Amazon S3, Treasure Data で心労ゼロ - naoyaのはてなダイアリー
開発メモ#6 です。前回から少し間があいてしまいました。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で書いたように、EC2 へのアプリケーションのデプロイにあたっては Elastic IP の利点を活かしてカジュアルにホストを入れ替えまくっています。ちょっとこのデプロイは慎重になりたいな、と思ったらスナップショットからインスタンスを立ち上げては切り替える、の繰り返し。 この運用をしていると、スナップショットとの差分ができやすいのは chef-solo で吸収するというのが前回、前々回のはなし。 もう一点問題があります。アクセスログやアプリケーションのログです。フロントエンドのサーバをあっちこっち切り替えているうちに、そのままではログが分断されてしまう。ホストを Terminate しようものならログは消失してしまいます。 この
Dash - naoyaのはてなダイアリー
Twitter で知人に紹介したら周囲から「これは便利」という声が結構聞こえてきたので、ブログでも紹介しておこう。Dash というドキュメントビューワー。 iOS や RubyMotion、あるいは node や ruby そのほかのマニュアルをまとめてインクリメンタルサーチして API を調べる、ということができる。メジャーな色んな言語に対応している。 本来 Dash は "Snippet Manager" ということで、コードスニペットを管理するためのアプリケーションのようだけど自分は単なるドキュメントビューワーとしてしか使っていない。RubyMotion の勉強会に行ったときに、これが便利というのを教えてもらってその後愛用しています。主に iOS の開発のときに利用していた。 http://satococoa.github.com/blog/2013/01/22/view-rdoc-
宮川さんのポッドキャストと、昔話 - naoyaのはてなダイアリー
第１回はnaoyaさん(@naoya_ito)をゲストに迎えてポッドキャスト、LTSV、RubyMotion、Perlなどについて話しました。 もう昨晩のことになってしまいましたが @miyagawaさんのポッドキャストに出演しました。初めての経験でしたが、喋っている方としてもとても楽しめました。 話の内容的には、LTSV にはじまり RubyMotion、AWS など最近ブログに良く書いていたことと、宮川さん持ち出しネタの Ruby の Topaz、Perl の Moe などなど。1時間ほど、実装系の話をしてみましたがよくよく考えると1時間いろんな技術ネタについてじっくり対話する･･･という機会はあまりないですね。またやりたい。 今何でポッドキャストなのかとかその辺の背景は実際の番組内にあるので、興味のある方はぜひご試聴ください。なお、Ruby の話をいろいろしてたら matz が聴いて
LTSV FAQ - LTSV って何? どういうところが良いの? - naoyaのはてなダイアリー
LTSV って何? Labeled Tab-Separated Values という、テキストのフォーマットの仕様です。CSV や TSV や JSON そのほかと同じ、テキストデータのフォーマット名。主にログ、特に httpd のアクセスログなどに適用すると便利です。 仕様は http://ltsv.org にまとまっています。随時更新中です。 LTSV は単なるログのフォーマットであって、それ以上でもそれ以下でもありません。 LTSV ってタブ区切りで値に名前を付けただけのもの? はい、そうです。 これが 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (
LTSV が行指向な Key-Value フォーマットで捗る話 - naoyaのはてなダイアリー
引き続き LTSV について。Text::LTSV はやってることは単にタブの split でしょうもないのだけど、せっかく作ったんだし何か利用方法はないかなと考えた。 LTSV のログは欠点があってそのままでは見づらいこと。 Text::LTSV でハッシュになるのだから、YAML とかで出力したらどうなるか試してみよう。さらに、YAML に色づけする YAML::Tiny::Color というのがあったぞ。 #!/usr/bin/env perl use strict; use warnings; use Project::Libs; use YAML::Tiny::Color qw/Dump/; use Text::LTSV; while (<>) { my $hash = Text::LTSV->parse_line($_); print Dump $hash; } こんなスクリプ
【今北産業】3分で分かるLTSV業界のまとめ【LTSV】 - naoyaのはてなダイアリー
id:stanaka がはてなで使って居るログフォーマットが LTSV だよーとブログに書く Labeled Tab Separated Values (LTSV) ノススメ - stanaka's blog Web界隈のエンジニアたち、特にログとか、#fluentd 関係者がざわつく 「ざわ・・・ざわ・・・」 @t_wada 「Unix 哲学の大事な点が形になっていると思う。素晴らしい。」 @hotchpotch 「cool」 六本木、渋谷、白金台方面から京都へ熱い視線が送られる id:naoya がただ vagrant + chef を使いたいがために LTSV に乗っかる GrowthForecast を使っていたため GF の中の人が反応する @kazeburo 「[growthforecast]」 id:naoya が勢いで Text::LTSV を作る あまり反応がないのでしょ
LTSVフォーマットなログを fluentd + GrowthForecast で料理 - naoyaのはてなダイアリー
ここ数年のデータ解析の重要性の高まりから、ログに関するソリューションが方々で活発に探求されている昨今でございます。ウェブサーバーの単純なアクセスログをそのまま保存するではなく追加情報を添加してみたり、あるいはアプリケーションから直接ログを吐いてそれらをデータウェアに投げ込んで･･･というのも当然のように行うようになりましたね。 しかしあまり自由度のない access_log の combined フォーマット。さてどうしたもんか･･･ ここで id:stanaka の登場です。 Labeled Tab Separated Valueというのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからflue
Vagrant - naoyaのはてなダイアリー
先日 Vagrant を触ってみたら便利すぎて鼻血が出ました。しばらく見ないうちに色々進んでるもんですねえ、いやはや参っちゃいました。 Vagrant は仮想マシンの VirtualBox のフロントエンドに相当する、ruby で書かれたツールです。vagrant コマンドなどを使ってコマンドラインから簡単に新しい VM を作れる。 % gem install vagrant % vagrant box add centos http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.3-x86_64-v20130101.box % vagrant init centos % vagrant upこれだけで CentOS の Linux box をローカルマシン内に立ち上げることができる。*1 *2 なにこれすごい。 % vagra
開発メモ#3 : レガシーなCGIアプリケーションのリファクタリング - naoyaのはてなダイアリー
開発メモその3です。今回は Perl のおはなし。 何年も前に作ったウェブアプリケーションのコードを開いてみたら黒歴史なコードが出てきて憂鬱な気分になる、そんな経験ありませんか。私はあります。ずっとそんな現実から目を背けて生きてきました。 さて、先日 Perl + CGI で書いて Apache::Registry で高速化している、実行環境が Apache に癒着した CGIアプリケーションを発見しました。おえ〜っ。一から作り直したい気持ちをぐっと堪えて、これを Plack 化したりとリフォームしていくとしましょう。その過程を以下記します。劇的ビフォア・アフター! ･･･とかは期待せず、地道な変更を積み重ねていくのがコツです。 方針 いきなりコードをがりがり書き換えていくというよりは、試行錯誤のしやすい環境に移行させていきながらリフォームを進めます。遠回りですが、結果的にその後の運用が楽
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
