naoyaのはてなダイアリー - コネクションプーリングの話
かなりながーいエントリになる予定なので,結論だけ最初に書くとこんな感じ. この話題については自分も あとで書く と言って書いてなかったので書いてみますよ。2006年の下期にもなってコネクションプーリングかよというツッコミもありそうですが、あとで書くといったら書くの。あとで読むといったら読む。 普通「コネクションプーリング」と言ったら、主に二つの役割があると思います。話を簡単にするためにウェブアプリケーションに限定して言及します。 ウェブアプリケーションから DB への接続を開けっ放しにして、接続に必要とされるオーバーヘッドをカットして双方の負荷を下げる。 ウェブアプリケーションと DB への接続を「使いまわす」ことで、同時接続本数を節約する。 というもの。 mod_perl で DB と接続維持するとコネクション数増えて云々という話は主に前者のみについての話になります。Apache::DB
naoyaのはてなダイアリー
ときどき、たまたま自分がそのとき考えていたことについてそれを補強するような材料が偶然たくさん集まってくる、なんてことがあります。そんな出来事があったので、ちょっとブログを書いてみようかなと。 以前に HBFav を作ったときこんなことを書きました。 Mark Zuckerberg は、いずれみんな、ニュースは友人知人経由で知ることになるだろうと言っていました。自分もそうなるだろうと思います。 4年ぐらいが経ちましたが、その思いは以前よりも増して確信めいたものになってきています。 ところで先日、Twitter の iOS アプリに「ニュース」という機能が追加されました。人によっては出てないそうなのでまだテスト中か、もしくは既に削除されているのかもしれないですが。 この機能についての自分の感想は以下のようなものでした。 もうすこし補足します*1。 Facebook や Twitter のような
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
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
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 と連携するこ
Github を使って雑誌原稿を書く - naoyaのはてなダイアリー
今日はこのあと Github の Tokyo Drinkup January 2014 に行くのだが、先方から、もしかしたら 10分ほど Github について話してもらうかも、と打診された。話すか話さないかわからないが、もし話すとしたらと仮定し内容の整理も兼ねて以下「Github を使って雑誌原稿を書く」ということについて書いてみようと思う。 「Github を使って雑誌原稿を書く」もしくは「Github を使った雑誌編集者とのコラボレーション」について、である。 Web+DB PRESS の連載 ご存知の方もいるかもしれないが、このところ技術評論社の Web+DB PRESS で連載をしている。連載を始めて、もう一年近く経った。以前にも Perl に関する連載をしていて、そのときも数年ぐらい続けたので、間があきつつも、なんだかんだでそれぐらいの付き合いになる。 最近は特にテーマは決めず
ポータブルな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サイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー
一昨日 Testing Casual Talks #1 に参加した。名前の通り、ソフトウェアテストに関するカジュアルなカンファレンス。とても面白かった。すこし思ったところを書いていこう。 テストのエンジニアリング トップバッターの @ikasam_a さんの発表では Software Engineer in Test at DeNA ということで、氏が勤務先でテストエンジニアリング部門を立ち上げていくにあたってのいきさつや背景といったところが述べられていた。 テストは開発者の生産性を向上するためにある、生産性向上のためにテストを書くテストエンジニア、近年複雑化するテストの実行環境を構築するのもテストエンジニアの役目、"Testing Activities SHOULD be in Developments" ─ テスト活動は (従来型のQAのように開発の外ではなく) 開発の中で行われるべき
ProMotion - naoyaのはてなダイアリー
最近 RubyMotion ユーザーの間で ProMotion という名前を良く聞くようになった。http://rubymotion-wrappers.com/ の説明を観ると A full featured RubyMotion framework that makes iPhone development less like Objective-C and more like Ruby, designed to get up and running fast. となっていて、RubyMotion 向けのフレームワーク、ということらしい。 ドキュメントにあるサンプルコードは以下のようになっていて、 class AppDelegate < PM::Delegate def on_load(app, options) open RootScreen.new(nav_bar: true) en
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
Backbone.jsガイドブック - naoyaのはてなダイアリー
Backbone.jsガイドブックposted with amazlet at 13.05.07高橋 侑久 ラトルズ 売り上げランキング: 2,459 Amazon.co.jpで詳細を見る Backbone.js ガイドブックを一通り読みました。言及するか少し迷ったけど、まだあまり話題になっていないようなので書いておこうと思います。 Backbone.js あるいはこれによく似たようなフレームワークは今後、Webアプリケーション開発でよく使う道具になっていくと思う。というか、すでになっているでしょう。 Backbone.js は「クライアントサイドMVCフレームワーク」と呼ぶと良くわからない。クライアントサイドMVCフレームワークが注目される以前から、ある程度以上の規模の JavaScript アプリケーションになるとちゃんとしてるものは構造化が行われていた。イベントを集約するオブジェクト
Vagrant + Chef Solo + serverspec + Jenkins でサーバー構築を CI - naoyaのはてなダイアリー
Jenkins おじさんと戯れること半日、うまくいったので備忘録を残しておく。 やりたかったのは Chef で構築したサーバーを Jenkins で CI する、というもの。このときサーバーはテストが終わる度に破棄して、テスト開始時に再度真っ新な状態から立ち上げたい。(こういうサーバーを壊して作ってというテストはなんという名前で呼ばれるのだろう?) 仮想サーバーを破棄/作成をプログラマブルにやるのはもちろん Vagrant プロビジョニングは Chef Chef の環境を整えるのに knife-solo 0.3.0.pre3 テストは serverspec コードは Github に上げる (https://github.com/naoya/jenkins-vagrant-test) CI は Jenkins という構成になっている。ひとまず Jenkins や Vagrant はローカル
昨今のWebアプリケーションのひな形その2 - Grunt - naoyaのはてなダイアリー
昨日の続き。 こういうアプリケーションのテンプレートを管理するのに便利な仕組みはないですかねーと言っていたら @teppeis さんや @omo2009 さんに Grunt や Yeoman はどうかと教えてもらった。 Grunt はユースケースとしては JavaScript の連結や圧縮、SCSS/LESS なんかのメタ言語のコンパイルをするときに使うもの、つまり rake なんかと同じようなものと以前にチラ見した程度で知った気になっていたけども、ちょっと違っていた。Grunt は確かにタスクランナーではあるのだが、Node.js で実装している利点を十分に活かして、任意のファイルが更新されたのをトリガに一連のタスクを実行させたり、Grunt で Webサーバーを立ち上げて他のタスクと連携させたりといったことができるようになっている。プラグインの仕組みがあって、エコシステム的に結構活発に
やる気と身体 - 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 がどういうサービスで、どういう機能を持っていて、どんな場面で利用されるものなのかはまだあまり良く知られていないかもしれない･･･ようにも見える。今日はその辺から少し紹介していこうかなと思う。
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
Zopfli - naoyaのはてなダイアリー
Googleが今日（米国時間2/28）、オープンソースの新しい圧縮アルゴリズムZopfliをローンチした。今の標準圧縮技術であるzlibライブラリに比べて5〜8%圧縮率が高いといわれ、また解凍アルゴリズムは今のWebブラウザが現用しているもので間に合うため、Webサーバがこれを採用すれば、データの伝送速度が上がり、Webをやや速くすることができるだろう。 Google が出力が deflate 互換の圧縮アルゴリズムをオープンソースにしたというので、ちょっとタイムラインで話題になっていた。圧縮アルゴリズム周りにはまってた頃から結構時間が経ってしまって色々忘れてしまったけど、少しニュースを捕捉してみようと思う。 Zopfli は deflate 互換なので、deflate アルゴリズムを解釈できる実装なら伸張できる。当然ブラウザが持ってる deflate 実装で伸張できるので、エンドユーザー
開発メモ#6 : ログの取り扱い : GrowthForecast, Amazon S3, Treasure Data で心労ゼロ - naoyaのはてなダイアリー
開発メモ#6 です。前回から少し間があいてしまいました。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で書いたように、EC2 へのアプリケーションのデプロイにあたっては Elastic IP の利点を活かしてカジュアルにホストを入れ替えまくっています。ちょっとこのデプロイは慎重になりたいな、と思ったらスナップショットからインスタンスを立ち上げては切り替える、の繰り返し。 この運用をしていると、スナップショットとの差分ができやすいのは chef-solo で吸収するというのが前回、前々回のはなし。 もう一点問題があります。アクセスログやアプリケーションのログです。フロントエンドのサーバをあっちこっち切り替えているうちに、そのままではログが分断されてしまう。ホストを Terminate しようものならログは消失してしまいます。 この
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
