ソーシャルメディアにおける他人との関係性がコンテンツ価値に影響を与える - naoyaのはてなダイアリー
ときどき、たまたま自分がそのとき考えていたことについてそれを補強するような材料が偶然たくさん集まってくる、なんてことがあります。そんな出来事があったので、ちょっとブログを書いてみようかなと。 以前に HBFav を作ったときこんなことを書きました。 Mark Zuckerberg は、いずれみんな、ニュースは友人知人経由で知ることになるだろうと言っていました。自分もそうなるだろうと思います。 4年ぐらいが経ちましたが、その思いは以前よりも増して確信めいたものになってきています。 ところで先日、Twitter の iOS アプリに「ニュース」という機能が追加されました。人によっては出てないそうなのでまだテスト中か、もしくは既に削除されているのかもしれないですが。 この機能についての自分の感想は以下のようなものでした。 もうすこし補足します*1。 Facebook や Twitter のような
プロダクトマネージャーについて - naoyaのはてなダイアリー
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･い
「リーン」について : 「何を作るか」よりも「何を作らない」か - naoyaのはてなダイアリー
2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN) という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。 書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。 仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す･･･というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─
エンジニアにとって良い組織とは何かを知りたい? - naoyaのはてなダイアリー
「エンジニアにとって良い組織体制ってどんなものですか? お話を伺いたいのですが･･･」と依頼をいただくことがあるが、都合上全部を受けてはいられない。ので、そういう疑問を持たれた方は以下の本を読むと良いかと思います。 How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメントposted with amazlet at 14.10.18エリック・シュミット ジョナサン・ローゼンバーグ アラン・イーグル 日本経済新聞出版社 売り上げランキング: 19 Amazon.co.jpで詳細を見る 小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則posted with amazlet at 14.10.18ジェイソン・フリード デイヴィッド・ハイネマイヤー・ハンソン 早川書房 売り上げランキング: 7,579 Amazon.co.jpで詳細を見る Tea
Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
Docker (土曜日に podcast します) - naoyaのはてなダイアリー
Docker をいじって遊んでいる。 http://www.docker.io/ Docker は PaaS ベンダの DotCloud がその PaaS のバックエンドとして使っている (?) ミドルウェアを公開したもの。適当な条件の VM をポコポコ生み出してはテストや実際の運用に使うことができたりするもの。例えば「Ruby と Bundler が入っている VM」みたいなのを設定で作っておくと、後日何か Ruby でアプリケーションを動かしたいと思ったときにそのイメージをベースに VM を作ってデプロイしてやればすぐにアプリケーションが動き出す。そもそも PaaS がやっているのはそういう事で、それを汎用化したのが Docker。Travis CI のような、各言語ごとの実行環境が整った VM みたいなものに任意のコードを渡してビルドさせる、みたいなプラットフォームを作るのにも使える
Docker の Remote API + serverspec で CI - naoyaのはてなダイアリー
昨日 http://d.hatena.ne.jp/naoya/20130620/1371729625 で書いたように Docker を使えば、欲しい VM を "任意の状態" で簡単にかつ" "瞬時に" コピーして作り出すことができる。 「任意の状態」というのは、例えば「OS は CentOS で、Ruby と Chef が入っている」みたいな VM のこと 「瞬時に」というのは本当に瞬時。VM の起動時間を待ったり、Ruby や Chef を入れる時間を待つ必要はない serverspec でテストをする場合、真っ新な VM を用意してそれにプロビジョニングを行って、その後に破棄するみたいなことを良くする。このとき「真っ新なVM」を立ち上げるのに、Vagrant などが使えるが、Vagrant だとテストの度に VM を一から作り直す･･･つまり vagrant up しなければいけない
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以外はオープンソースで公開さ
ポータブルなWebアプリケーション - naoyaのはてなダイアリー
140文字で書ききれなかったのでブログに殴り書き。 Heroku のアプリケーションを人に渡す 昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。 対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。 対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかは
昨今の自分用Webアプリケーションひな形 - naoyaのはてなダイアリー
ちょっと jQuery と簡単なサーバサイドの処理を組み合わせた処理を試しに書いてみよう･･･なんて時に、いちいち jQuery を取ってきて HTML を書いて script タグを書いてロードして sinatra 立ち上げて云々･･･というのが毎度面倒なので、ひな形になるアプリケーションを作った。 https://github.com/naoya/boilerplate ひとまず sinatra でサーバーサイドを書き、HTML は slim で、CSS は sass 。JavaScript は CoffeeScriptで書くにあたって jQuery、underscore、Backbone をロードしてある、というような構成にしてあります。 まあ、この類のことは人それぞれ自分なりにカスタマイズしてやっていると思いますが、どういうコンポーネントで構成しているかを、備忘録も兼ねてちょっと紹
git-gutter.el - naoyaのはてなダイアリー
寝れないので変な時間にブログを書いたりする。 時折思い立ったように Emacs Lisp を見直して色々導入を試みたりするも、結局割り当てたキーバインドを忘れてたりして定着しない、というものは多い。そんな中でもここ1, 2ヶ月くらいで定着したのが git-gutter.el。 このように緑のプラス記号なんかが出て git で管理しているファイルを編集した場合の差分がどこかが一目でわかる。 多くの elisp がそうなんだけど、導入する前までは便利そうだけどそこまで必要かな? と思いつつ入れてみたらもう手放せなくなった、そういう類です。ぼーっとしながらコード書いてる時でも、あそことあそことあそこを編集したんだなってのが git diff とかしなくても分かる。 これを入れるとちょっと動きがモッサリするみたいな話もあるけど、作者の id:syohex さんが鋭意改善中 (http://d.ha
やる気と身体 - naoyaのはてなダイアリー
ひとたびフロー状態になると、それを維持するのは難しくない。私の一日の多くはこんな感じだ: (1) 仕事にとりかかる。(2) emailをチェックしたり、Webを見たり、そのほかのことをする。(3) 仕事に取りかかる前にランチを取ったほうがいいと判断する。(4) ランチから戻る。(5) emailをチェックしたり、Webを見たり、そのほかのことをする。(6) いい加減はじめたほうがいいと心を決める。(7) emailをチェックしたり、Webを見たり、そのほかのことをする。(8) 本当に始めなきゃいけないと、再び決心する。(9) くそエディタを立ち上げる。(10) ノンストップでコードを書いていると、いつのまにか午後7:30になっている。 ステップ8とステップ9の間のどこかにバグがあるようだ、私は必ずしもこの溝を飛び越えられないからだ。私にとっては、ただ始めることが唯一困難なことなのだ。静止状
Dash - naoyaのはてなダイアリー
Twitter で知人に紹介したら周囲から「これは便利」という声が結構聞こえてきたので、ブログでも紹介しておこう。Dash というドキュメントビューワー。 iOS や RubyMotion、あるいは node や ruby そのほかのマニュアルをまとめてインクリメンタルサーチして API を調べる、ということができる。メジャーな色んな言語に対応している。 本来 Dash は "Snippet Manager" ということで、コードスニペットを管理するためのアプリケーションのようだけど自分は単なるドキュメントビューワーとしてしか使っていない。RubyMotion の勉強会に行ったときに、これが便利というのを教えてもらってその後愛用しています。主に iOS の開発のときに利用していた。 http://satococoa.github.com/blog/2013/01/22/view-rdoc-
【今北産業】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 を作る あまり反応がないのでしょ
権限委譲、リーダーシップ、チーム - naoyaのはてなダイアリー
いいか、覚えておけ。おれにしてもお前にしても、それなりに成功するってことは、なにかは得意なんだ。でも大体のことは不得意極まりない。全部自分でやろうとするな。自分よりも何かで優れている人たちが、その何かでお前のためにチカラを貸したいと思うような人間になれ。 それがリーダーってもんだよ。 この記事が話題になってた。リーダーシップというのは力を貸してやろうと相手に思われることだという、いい話。 この手の話は、誰もが否応なしに社会で経験することだから、みんなそれぞれ自分の考えを述べたくなる･･･という話題でもありますね。例に漏れず、自分も少し経験から感じることを書いてみよう。 「権限」を「委譲」する? 「上司が何かを部下に任せる」という文脈でいくと、このストーリーは「権限委譲」の話にもみえる。確かにテーマとしてはそうなのだが、自分は一般で言う「権限を委譲する」という考え方そのものにちょっとした落と
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
開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー
開発メモ#1 : Cinnamon によるデプロイ - naoyaのはてなダイアリー に引き続き、その2です。 最近は個人で作るような小規模なものでも AWS を利用してホストしています。たとえ個人で作ったものとはいえ、利用するユーザーがいる以上はおいそれと落とすこともできない。かといって運用にあまり手間をかけたくない。その辺り、AWS で解決できる点が多い。 AWS の良いところはインフラが動的なので「後からどうとでもなる」ところ。 インスタンスの性能が足りないのであればスケールアップするでもいいし、冗長性が欲しくなったらそのタイミングで ELB (ロードバランサ) を用意すれば良い。その時、仮想化されていないハードウェアを使っていると移行のためにサーバーを再セットアップしたりアプリケーションをデプロイし直したりと手間がかかるところ、AWS ではその辺りの手間がほとんどかからない･･･と
開発メモ#3 : レガシーなCGIアプリケーションのリファクタリング - naoyaのはてなダイアリー
開発メモその3です。今回は Perl のおはなし。 何年も前に作ったウェブアプリケーションのコードを開いてみたら黒歴史なコードが出てきて憂鬱な気分になる、そんな経験ありませんか。私はあります。ずっとそんな現実から目を背けて生きてきました。 さて、先日 Perl + CGI で書いて Apache::Registry で高速化している、実行環境が Apache に癒着した CGIアプリケーションを発見しました。おえ〜っ。一から作り直したい気持ちをぐっと堪えて、これを Plack 化したりとリフォームしていくとしましょう。その過程を以下記します。劇的ビフォア・アフター! ･･･とかは期待せず、地道な変更を積み重ねていくのがコツです。 方針 いきなりコードをがりがり書き換えていくというよりは、試行錯誤のしやすい環境に移行させていきながらリフォームを進めます。遠回りですが、結果的にその後の運用が楽
Webはインターネットになった - naoyaのはてなダイアリー
先週金曜日にエンジニアサポートCROSS2013に行ってきた。目当ては @Jxck_ さんホストによる次世代Webセッション。セッション自体は前後半に分かれていて 前半はプロトコル編。SPDY (wikipedia) や HTTP/2.0 の動向やその課題点など 後半はアーキテクチャ編。プロトコルが変わった上で、その上で動くソフトウェアのアーキテクチャが云々 という内容でした。前半がより技術寄り、後半はテーマ的にもより広範の話題を扱うという感じでどちらも面白かった。 CROSS 2013レポート(2) - mad-pの日記 こちらに細かいログがあります。 話の前提になる SPDY や HTTP/2.0 周りの昨今については 【HTTP 2.0の最新動向】 第1回：HTTP/2.0の策定、ついに始まる - INTERNET Watch Watch 【HTTP 2.0の最新動向】 第2回：HT
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
