Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
Reveal - naoyaのはてなダイアリー
Reveal (http://revealapp.com/) なる iOS 向けのランタイムインスペクタなるものを知人のツイート経由で見つけた。ランタイムインスペクタとは何か ･･･ "Reveal brings the power of tools like Firebug and Web Inspector to iOS developers." ということでiOS アプリ用の Firebug みたいなのだと思えば良い。 動画を観てると確かにすごい。3D で動かしながら View の階層を手繰ってアプリのビューがどういう構造になっているかを見ていくことができる。更に動的にパラメータを変更して大きさや動きを変える、なんて Firebug の css の編集みたいなこともできるようだ。ベータ版は無料のようだ。 これは捗る。 RubyMotion で動かす ドキュメントを見てみたところ Re
LTSVフォーマットなログを fluentd + GrowthForecast で料理 - naoyaのはてなダイアリー
ここ数年のデータ解析の重要性の高まりから、ログに関するソリューションが方々で活発に探求されている昨今でございます。ウェブサーバーの単純なアクセスログをそのまま保存するではなく追加情報を添加してみたり、あるいはアプリケーションから直接ログを吐いてそれらをデータウェアに投げ込んで･･･というのも当然のように行うようになりましたね。 しかしあまり自由度のない access_log の combined フォーマット。さてどうしたもんか･･･ ここで id:stanaka の登場です。 Labeled Tab Separated Valueというのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからflue
開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー
開発メモ#1 : Cinnamon によるデプロイ - naoyaのはてなダイアリー に引き続き、その2です。 最近は個人で作るような小規模なものでも AWS を利用してホストしています。たとえ個人で作ったものとはいえ、利用するユーザーがいる以上はおいそれと落とすこともできない。かといって運用にあまり手間をかけたくない。その辺り、AWS で解決できる点が多い。 AWS の良いところはインフラが動的なので「後からどうとでもなる」ところ。 インスタンスの性能が足りないのであればスケールアップするでもいいし、冗長性が欲しくなったらそのタイミングで ELB (ロードバランサ) を用意すれば良い。その時、仮想化されていないハードウェアを使っていると移行のためにサーバーを再セットアップしたりアプリケーションをデプロイし直したりと手間がかかるところ、AWS ではその辺りの手間がほとんどかからない･･･と
あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー
お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは top や ps などで調べると良いでしょうか。例えば手元の coLinux で top して M キーでソートすると emacs のプロセスが最もメモリを使っているようです。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1923 naoya 18 0 23120 19m 3096 S 0.0 2.0 0:55.40 emacsメモリサイズは VIRT と RES がありますが、VIRT は Virtual の略で仮想メモリ領域のサイズ、RES が Resident の略で、実際に使用している物理メモリ領域のサイズ。19MB ほど使っているようです。この emacs のプロセスが利用するメモリ領域はざっくり 20MB 程度と
マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
naoyaのはてなダイアリー - コネクションプーリングの話
かなりながーいエントリになる予定なので,結論だけ最初に書くとこんな感じ. この話題については自分も あとで書く と言って書いてなかったので書いてみますよ。2006年の下期にもなってコネクションプーリングかよというツッコミもありそうですが、あとで書くといったら書くの。あとで読むといったら読む。 普通「コネクションプーリング」と言ったら、主に二つの役割があると思います。話を簡単にするためにウェブアプリケーションに限定して言及します。 ウェブアプリケーションから DB への接続を開けっ放しにして、接続に必要とされるオーバーヘッドをカットして双方の負荷を下げる。 ウェブアプリケーションと DB への接続を「使いまわす」ことで、同時接続本数を節約する。 というもの。 mod_perl で DB と接続維持するとコネクション数増えて云々という話は主に前者のみについての話になります。Apache::DB
naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う
あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
