ソーシャルメディアにおける他人との関係性がコンテンツ価値に影響を与える - naoyaのはてなダイアリー
ときどき、たまたま自分がそのとき考えていたことについてそれを補強するような材料が偶然たくさん集まってくる、なんてことがあります。そんな出来事があったので、ちょっとブログを書いてみようかなと。 以前に HBFav を作ったときこんなことを書きました。 Mark Zuckerberg は、いずれみんな、ニュースは友人知人経由で知ることになるだろうと言っていました。自分もそうなるだろうと思います。 4年ぐらいが経ちましたが、その思いは以前よりも増して確信めいたものになってきています。 ところで先日、Twitter の iOS アプリに「ニュース」という機能が追加されました。人によっては出てないそうなのでまだテスト中か、もしくは既に削除されているのかもしれないですが。 この機能についての自分の感想は以下のようなものでした。 もうすこし補足します*1。 Facebook や Twitter のような
プロダクトマネージャーについて - naoyaのはてなダイアリー
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･い
エンジニアにとって良い組織とは何かを知りたい? - 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
日本語で読める IT名文書 三選 - naoyaのはてなダイアリー
pplog の方に書いたけど、別にブログに書けばいいかと思い直したので投稿。Slack でチャットしてて、なんとなくこれ面白いよ URL を共有する機会があったので適当に選んだもの。 伽藍、バザール、ノウアスフィア、おなべ(3) http://www.artonx.org/diary/20120411.html#p01 artonさんがノウアスフィアの開墾についてわかりやすく書いてるもの。原文はちょっと長くて読むのが大変だけど、こっちは分かりやすいし、面白い。OSS の構造がなんかわかったきになる、すごい。 Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した http://anond.hatelabo.jp/20111018190933 (前編) http://anond.hatelabo.jp/20111018192953 (中編) http://a
Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
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 が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
Chef Solo の Environments - naoyaのはてなダイアリー
今年3月に入門Chef Soloを書いた時点では、Chef Solo は Environments の機能をサポートしてなかったため解説は省略しました。 その後、Chef はバージョン 11.6.0 (現在は 11.8.2) で Chef Solo での Environments をサポートし、入門Chef Solo で推薦している knife-solo も 10月末にリリースされた 0.4.0 から Environments をサポートしました。というわけで、現状 Chef と knife-solo が最新版であれば Environments を利用することができます。 たまたま今手をつけている仕事で Environments のことを調べたので備忘録的に記しておきます。 Environments とは Chef の Environments は、例えば development や pr
Infrastructure as Code - naoyaのはてなダイアリー
今年の3月に 入門Chef Solo - Infrastructure as Code という本を書いた。 その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。 この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う
ポータブルなWebアプリケーション - naoyaのはてなダイアリー
140文字で書ききれなかったのでブログに殴り書き。 Heroku のアプリケーションを人に渡す 昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。 対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。 対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかは
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
「書く」のは特別な道具 - 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サイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
Treasure Data - naoyaのはてなダイアリー
少し前にログの話を書いた http://d.hatena.ne.jp/naoya/20130219/1361262854 ときに、Treasure Data については後日にもう少し詳細に書くと言ったので書くとしよう。 近頃 Treasure Data (以下、時折 TD) という名前をちらほら聞いたことがある人は多いのではないかと思います。「ビッグデータのクラウドサービスである」とか「日本人が創業したシリコンバレーのベンチャー」、あるいは Yahoo! 創業者の Jerry Yang が投資したとか、Fluentd と何か関係があるといった文脈などなど。 けど、具体的に Treasure Data がどういうサービスで、どういう機能を持っていて、どんな場面で利用されるものなのかはまだあまり良く知られていないかもしれない･･･ようにも見える。今日はその辺から少し紹介していこうかなと思う。
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以外はオープンソースで公開さ
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] (
エンジニアだからなんとか - naoyaのはてなダイアリー
昔から「エンジニアは営業が苦手」とか「エンジニアはデザインが苦手」とか、あるいは「エンジニアはコミュニケーションが苦手」というような言われ方が嫌いだった。 実際、営業が苦手なエンジニアというのはいると思う。でもそれはエンジニアだから苦手なのではなくて、単にその人が営業が苦手なだけだ。同じように、デザインに関してもコミュニケーションに関してもそうだ。 おおまかにそういう傾向があるということまでは否定はしない。例えばプログラミングのカンファレンスに行くとそこでは男性率が非常に高いし、全体としては、まあなんというかリア充とはちょっと違う雰囲気を醸し出している･･･というようなところがあってそれは誰もが感じることだろう。集団を集めて一般化してみるとそういう何かしらの傾向が現れる、ということまでは否定はしない。 でもやっぱり、その「エンジニアだから○○」という型にはめたような話を自分自身にあてがって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
