prefork サーバーと thundering herd 問題 - naoyaのはてなダイアリー
Catalyst を POE で動かす Engine の Catalyst::Engine::HTTP::POE という実装が CPAN にあります。"Single-threaded multi-tasking Catalyst engine " だそうです。"Single-threaded" と言いつつも実装を覗いてみると環境変数 CATALYST_POE_MAX_PROC を 1 よりも大きく設定することで prefork する実装になってます。POEシングルスレッドではアプリケーション内で発生するブロックを避けることが難しいのでそのための実装じゃないかなと思います。 ところでこの Catalyst POE エンジン、prefork の実装はどのように行っているかというと POE から prefork と名の付いたイベントが発生するとおもむろに子プロセスを生成する、というのもの。複数の
エンジニアの不安と壁 - naoyaのはてなダイアリー
このところ、KLab×はてな エンジニア応援ブログコンテストというのを開催していまして、エンジニア人生に関するちょっとした小話をブログに書いていただくと、内容によっては、シリコンバレーに行けたり、iPad が貰えるかもしれない。という企画です。「え、ブログ書くだけでシリコンバレー? 」 なかなか太っ腹な企画です。 よい機会なので、宣伝がてら、自分もちょっと、昔話をしてみたいと思います。 振り返ってみると、自分がエンジニアとして経験を積むなかで、「ここが壁だったな」と思うところがぼちぼちありました。それが何で壁に感じたのかといま改めて考えると、いずれも体系的な知識がなかったために、それを乗り越えるための指針がなかったというのが大きかったように思います。 きれいなコードを書くにはどうしたらいいんだろう? 負荷分散って、どうやるんだろう? 溜め込んだデータをうまく活用するには、どうしたらいいんだ
マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
Deploy to Heroku / Webアプリケーションのポータビリティ再び - naoyaのはてなダイアリー
Heroku の新機能で Heroku Button が出た。 見るよりも、触る方が早い。以下のボタンを押すと md2inao をあなたの Heroku アカウントにデプロイして、動かすことができる。 ボタンを押すと以下のような画面が出て、Deploy to Free を押すと直ちにデプロイが始まる。 GitHub からソースコードが Heroku にデプロイされて、Web アプリケーションが動く。 ご満悦。 このボタンを README.md に置いておけば、Webアプリケーションを自分で動かしたいなと思ったユーザーが、自分自身の環境で好きな時にそれをデプロイして使うことができる。 すなわち、Heroku Button で、URI を介した Web アプリケーションの交換が可能になった。 Heroku Button Heroku Button を有効にするための前提は割とシンプルで Git
些末なコードレビュー - naoyaのはてなダイアリー
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
RubyMotion を1年以上使い続けてみての雑感 - naoyaのはてなダイアリー
RubyMotion Advent Calendar 2013 に何か書こう、ということでエントリ。 ご存知のように iPhone アプリの HBFav は RubyMotion で作っています。Objective-C ではなく。以前は Titanium Mobile で作っていましたが、去年にバージョン2として作り直すにあたって RubyMotion に移行しました。 RubyMotion に関しては以前、以下のエントリで概要を説明しています。 RubyMotion - naoyaのはてなダイアリー それから、今年 5月に開催した RubyMotion カンファレンスのスライドなどもあります。 実践RubyMotion - Speaker Deck RubyMotion が発表されたのは 2012 年の5月 とかで、それからずっと使い続けているので1年半近くが経ったことになります。App
ポータブルなWebアプリケーション - naoyaのはてなダイアリー
140文字で書ききれなかったのでブログに殴り書き。 Heroku のアプリケーションを人に渡す 昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。 対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。 対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかは
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
YAPC::Asia 2013 / Github によりバザールモデルへ - naoyaのはてなダイアリー
ブログを書くまでが YAPC、ということなので、書きます。 初日「モダンPerlリファクタリング」 自分は20分枠で 「モダンPerlリファクタリング」という題で話しました。スライドは以下で公開してます。 https://speakerdeck.com/naoya/modanperlrihuakutaringu-number-yapcasia 今回、思いの他 CI やテストに関する発表が他に多くてそれらに比べると基礎的な内容に終始しちゃいましたが と @t_wada 御大よりお褒めに与ったので個人的には満足です。 リファクタリングはテストさえ書ければその半分以上は終わったことになる、ただしテストはテストを書くことそのものが主目的になりすぎないように。そして書いたテストはとにかく計算機を利用して頻繁に実行しましょうということが言いたかったのですが、意図通りに伝えられたんじゃないかなと思う。
Coveralls + Perl - naoyaのはてなダイアリー
Coveralls は Github に置いているソースコードのテストカバレッジを git push の度に調査して報告してくれるクラウドサービス。「カバー率100%を維持したいなら継続的インテグレーション (CI) のレポーティングにテストカバレッジも含めちゃえばいいじゃない」という貴族向けのサービスです。いえ、貴族はフィクションです。 こんな感じでモダンなデザインで色々教えてくれる。各行が何回テストされたかみたいな詳細なレポーティングもある。 Travis CI と同じく Github の README なんかに貼り付けるバッジがあります。というか Travis CI なんかのCIツールと連携して Coveralls にレポートを投げるのが前提になっているようです。 つい最近 プロトタイプ開発用のRailsプラグイン「Chanko」を2.0.0にアップデートしました - クックパッド開
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 で久しぶりに編集の稲尾さんと会ったところ、いかにも暇そうだと思われたのでしょう、記事書きませ
開発メモ#1 : Cinnamon によるデプロイ - naoyaのはてなダイアリー
このごろ作っているものが幾つかあるのだけど備忘録代わりにこの辺はこうしているということを書いて行こうかなと思います。 まずは Perl によるアプリケーションのデプロイについて。id:antipop と id:shiba_yu36 が開発した "Cinnamon" というミニマムなデプロイツールを利用しています。 Cinnamon - A minimalistic deploy tool https://github.com/kentaro/cinnamon シンプルで使いやすいデプロイツールです。 Capistrano? デプロイツールの定番といえば Capistrano で、最初は Capistrano を使っていました。けど、作っているものはほぼ Perl で書かれているのにデプロイツールだけ Capistrano で Ruby というのが、例えばモジュールの管理に Carton と
やる気と身体 - naoyaのはてなダイアリー
ひとたびフロー状態になると、それを維持するのは難しくない。私の一日の多くはこんな感じだ: (1) 仕事にとりかかる。(2) emailをチェックしたり、Webを見たり、そのほかのことをする。(3) 仕事に取りかかる前にランチを取ったほうがいいと判断する。(4) ランチから戻る。(5) emailをチェックしたり、Webを見たり、そのほかのことをする。(6) いい加減はじめたほうがいいと心を決める。(7) emailをチェックしたり、Webを見たり、そのほかのことをする。(8) 本当に始めなきゃいけないと、再び決心する。(9) くそエディタを立ち上げる。(10) ノンストップでコードを書いていると、いつのまにか午後7:30になっている。 ステップ8とステップ9の間のどこかにバグがあるようだ、私は必ずしもこの溝を飛び越えられないからだ。私にとっては、ただ始めることが唯一困難なことなのだ。静止状
Treasure Data - naoyaのはてなダイアリー
少し前にログの話を書いた http://d.hatena.ne.jp/naoya/20130219/1361262854 ときに、Treasure Data については後日にもう少し詳細に書くと言ったので書くとしよう。 近頃 Treasure Data (以下、時折 TD) という名前をちらほら聞いたことがある人は多いのではないかと思います。「ビッグデータのクラウドサービスである」とか「日本人が創業したシリコンバレーのベンチャー」、あるいは Yahoo! 創業者の Jerry Yang が投資したとか、Fluentd と何か関係があるといった文脈などなど。 けど、具体的に Treasure Data がどういうサービスで、どういう機能を持っていて、どんな場面で利用されるものなのかはまだあまり良く知られていないかもしれない･･･ようにも見える。今日はその辺から少し紹介していこうかなと思う。
宮川さんPodcast ep6、KDP での本の作り方 - naoyaのはてなダイアリー
第６回は伊藤直也さん (@naoya_ito) をゲストに迎えて、Kindle 出版、GitHub、Google Reader などについて話しました。 ほぼ週一くらいで配信されている @miyagawa さんの Podcast、第6回目のゲストで出演しました。第1回目に続き、これで自分は2回目ですね。だんだん往年のいいともみたいになっていくのだろうか。 それはともかく、内容は先日だした Kindle の 入門 Chef Solo に絡めて KDP (Kindle Direct Publishing) の話、それから Google Reader にまつわる RSS の話に関して。二人とも KDP での出版経験があるのと、RSS に関しては昔二人で本を書いたりした当時のホットな話題でお互い良く知ってるしというので、面白く話せました。 Chef 本が実際 KDP でどのくらいダウンロードされて
Google Reader終了にまつわるRSSに関しての取材 - naoyaのはてなダイアリー
岡田有花さんに取材いただいたものがさきほど記事になりました。RSSやRSSリーダーは「終わる」のかについて。Google Reader の終了発表にまつわる話ここ最近ホットなトピックですね。 この3月、RSSに関連する大きなサービスが相次いで終わりを迎えた。3月5日にTwitterのRSSフィードが終了。3月14日にはGoogleが、RSSリーダー「Google Reader」を終了すると発表した。 これらの動きを受けてネットでは、RSSについての議論が盛んになっている。「RSSは時代遅れ」「RSSリーダーは終わる」といった論調もある。 だが、ニフティのブログサービス「ココログ」や、はてなのソーシャルブックマーク「はてなブックマーク」など、RSSに関連するサービスを多く手がけてきたフリーエンジニアの伊藤直也さんは、「RSSも、RSSリーダーも終わらない」と話す。 もともと Google R
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以外はオープンソースで公開さ
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
開発メモ#6 : ログの取り扱い : GrowthForecast, Amazon S3, Treasure Data で心労ゼロ - naoyaのはてなダイアリー
開発メモ#6 です。前回から少し間があいてしまいました。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で書いたように、EC2 へのアプリケーションのデプロイにあたっては Elastic IP の利点を活かしてカジュアルにホストを入れ替えまくっています。ちょっとこのデプロイは慎重になりたいな、と思ったらスナップショットからインスタンスを立ち上げては切り替える、の繰り返し。 この運用をしていると、スナップショットとの差分ができやすいのは chef-solo で吸収するというのが前回、前々回のはなし。 もう一点問題があります。アクセスログやアプリケーションのログです。フロントエンドのサーバをあっちこっち切り替えているうちに、そのままではログが分断されてしまう。ホストを Terminate しようものならログは消失してしまいます。 この
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
