インフラストラクチャー部の成田です。 先日開催された RubyKaigi 2013 で、 "High Performance Rails" というタイトルの発表をしてきました。 スライドと動画 発表の様子は ustream の録画をご覧ください。 [ustream id=33559705 hwaccel=1 version=3 width=480 height=302] スライドは以下にアップロードしてあります。 High Performance Rails (long edition) // Speaker Deck なお、発表時間の都合上、当日はここから 40 枚ほどのスライドを削除してしまいました。発表に使った短いバージョンのスライドはこちらです。 発表の概要 クックパッドは 2008 年から Ruby on Rails を採用し、ずっと使い続けてきました。サービスが成長するとともに
前回ブログで紹介したRailsサーバUnicornくんを運用し始めて結構時間が経ちました。 サービスを落とさないであるとか、システムの安定性を確保するために、 ちょっとしたユーティリティを作ったり監視ソフトMonitの設定を行ったりしていました。 みなさんのお役に立つかわかりませんが、弊社でUnicornと組み合わせて運用に利用しているツールや設定をブログに掲載してみたいと思います。 もっといいやり方がありましたら、ぜひコメント欄でご紹介頂ければと思います。 ダウンしたら自動的に再起動 これはMonitで行っています。 もちろん同内容の監視ツールGodでも可能だと思いますが、以前設定した経験があって設定が楽そうだったので、Monitでやってみました。(事実楽でした) check process unicorn with pidfile "/path/to/rails/tmp/pids/un
2010.07.09 次世代Ruby on RailsサーバーUnicorn（汎用のRackアプリケーションサーバ）を使ってみた 2010.07.20追記: prefixを指定した運用も可能でした。ご指摘頂きありがとうございます。 2010.07.28追記: 関連記事「RailsサーバUnicornを飼いならす! 運用時の便利技」へのリンクを張りました。 Railsサーバはたくさんあってややこしいですね！ 最近さらにUnicornというものが頭角を表してきたようで、Twitterやgithubも使っているようなので使ってみましたので、特徴や使い方などレポートしてみたいと思います。 このブログの他にもEngine Yardのブログ記事「Everything You Need to Know About Unicorn」やgithubの記事「Unicorn!」が非常に参考になると思いますので、
Railsのsession_storeやcache_storeとして、memcachedを使うことはよくあると思います。 今回は、memcachedのRuby用クライアントgem, memcache-clientやdalliにて、Passengerやunicornのfork後の初期化をきちんと書かないと、悲惨なことになるというお話です。 ※他のgemやmemcached以外でも当てはまります。 必要な初期化処理 以下の処理を、config/environments/production.rbや、config/initializers/session_store.rbなど、どこでも良いので初期化コードに書いておく必要があります。 dalliを利用している場合 https://github.com/mdesjardins/dalli/tree/ # passengerの場合 if define
こんにちは。私は今まで、3年間、RailsやCakePHP,Ethnaなど様々な言語やフレームワークを使って開発を行ってきました。その中で、共通して使ってきたのがHTML/CSSです。私が3年間かけて培ってきたHTML/CSSの書き方ややり方、方針などをこの場を借りてまとめたいと思います。 まずはじめに 対応ブラウザを確認する スマホ対応の必要があるかを確認する HTML/CSSを使った開発のルールを決める HTML編 idやclassの命名を考える idは多用しない HTMLの共通化を考えた記述をする コラム: IE(後方互換モード)の対応が必要になった時の対処 CSS編 共通で使えるCSSは共通用のファイルを作ってまとめる CSSの適用範囲を考慮して記述する reset.cssを使うかどうかを決める CSSの!importantはできるだけ利用しない BootstrapのCSSを上書き
操作ログや簡易的なパフォーマンス測定などの目的で、特定アクションで実行されたSQLを監視したいことがあります。 filterやviewで実行された分を含まず、単純に指定ブロックの中を監視するなら、以下のような方法で簡単に実現可能です。 # application_controllerにでも定義しておく def watch_queries events = [] callback = -> name,start,finish,id,payload { events << payload[:sql] } ActiveSupport::Notifications.subscribed(callback, "sql.active_record") do yield end events end 使い方はこんな感じ def update @user = User.find(params[:id])
Rails4がリリースされてしばらく経ちましたが，一部のgemが対応に追いついていないこともあり，まだ本番系のシステムに適用するのは様子見かなというところです．社内システムや個人的に遊ぶアプリで予行練習中． というわけで，まだもうしばらくはRails3のお世話になりそうなので，Rails3の総まとめというわけではないですが，良く使うgemをまとめてみました．社内のチームMTGでの発表資料をSlideShareにアップロードしてあります． 既にRails開発に慣れた人にとってはおなじみのgemが多いと思いますが，これからRailsでの開発を始める人にとってはそれなりに有用かと思います． また，弊社では数多くのRailsアプリケーションをcapistranoでdeployしている実績がありますので，deploy関連のgem等も参考になればどうぞ． ================以下追記（20
RailsでFat ControllerになったらForm Classを作れ，という記事はあちこちで見るのですが，今一つ参考になるような実装があまり見つからなかったので記事にしてみました． Rails 3.2.13，Ruby 2.0.0系で動作確認済みです． Fat Controller問題 Railsで特に何も考えずに検索機能を作っていると，検索ロジックでcontrollerが膨らんできてしまうと思います（Fat Controller問題）． 例えば，検索フォームの内容として最初は名前だけで検索するとのことで， HogeController < ApplicationController def index @hoges = Hoge.where("name LIKE ?", "%#{params[:name]}%") end end と書いていたのが，そのうちメールアドレスや住所でも絞
2013.08.12 [Rails 4.0] 巨大なテーブルやserializeを使うときのActiveRecordオーバーヘッドを測定してみた Railsは遅い！とよく言われますが、高速化ポイントのうち最有力候補の1つがDB/モデル周りです。 N+1問題を修正するだけでも、体感できるレベルの高速化が期待できます。 しかし、RubyKaigiでCookPadの方も言っていたように、RDBMSがSQLを実行する時間だけでなく、ActiveRecordオブジェクトの処理は非常に重いです。 モデル周りの最適化と聞いて、一生懸命SQLをEXPLAINするのも大事ですが、ログに出力される「Prefecture Load (0.5ms)」のような数値にはActiveRecordオブジェクト部分のオーバーヘッドが含まれていないため、全体でどの部分が遅いのかを理解しないと徒労に終わってしまう可能性がありま
ActiveRecordにはコールバックがたくさんあります。 実行順序がよくわからなくなるので、Rails 4が出たことだし改めてまとめてみました。 ※ActiveRecord::Callbacksのヘッダコメントに全部書いてあります 使うモデル まずは、このようなクラスを作りました。 class Work < ActiveRecord::Base callbacks = %w(before after).product(%w(validation save create update destroy)).map{|a|a.join('_')} callbacks += %w(after_commit after_rollback after_initialize) callbacks.each do |callback| send(callback) { logger.debug cal
ActiveRecordには便利なprevious_changesというメソッドがあります。 割と知名度が低いので、ここで使い方をご紹介します。 （08/26追記） はてブでご指摘（？）頂きましたが、正確にはActiveRecordではなくActiveModel::Dirtyの機能です。 まずはchanges previous_changesの前に基本のchangesです。 これは、saveする前に変更されたattributeを調べる機能です。 まずはfindした直後です。changed?は当然falseになります。 User.create(name: "Taro") user = User.find(1) user.changed? # => false user.changed [] user.changes # => {} user.changed_attributes # => {
モデルからデータを取得する際に常に特定の検索条件を指定することができるdefault_scopeですが、 デメリットについてあまり注意を払わずに使ってしまって失敗しました。 サンプル事例 環境 * Rails 3.2.12, 4.0 * MySQL 5.1.65 ※ 実際に問題が起きたバージョンが3.2.12 なのでそちらが中心になっています。 データを「名前」「年齢」どちらか指定された値で並び替えるという処理があったので、 特に指定が無ければid順で取得するという条件をdefault_scope を使って追加しました。 class User < ActiveRecord::Base default_scope -> { order(:id) } end これで、モデルからデータを取得する際に必ずORDERが指定されるようになります。 User.all #=> SELECT "users"
Rails3では，ActiveRecordを使ったデータの取得方法にfind, find_by_XXX, find_all_by_XXX, all, whereでの絞り込みなど色々ありますが，それぞれ微妙に異なった挙動をします． ちょろいサンプルアプリを書く位ならあまり気にならない所なのですが，きちんとアプリを書く上では以外と大事なところ（後述）なので，ここいらでまとめておきます． Rails使っている人で hoge = Hoge.find(params[:id]) || Hoge.new とか書いて思った様に動かないぞ？とかハマった人向けです． 取り上げるのはfind, find_by_XXX, all, find_all_by_XXX, whereです．Railsのバージョンは3.2.8を使っています． 以下の説明では，以下のクラスが存在することを前提とします． class Hoge
Concurrency and Python By Shannon ,jj Behrens, February 03, 2008 Stackless Python, Erlang, and greenlets are interesting approaches to concurrency Shannon -jj Behrens works for Metaweb Technologies. He can be contacted at [email protected]. Imagine you wrote a new Web server that didn't support concurrency and couldn't do multiple things at the same time. Consequently, each new Web request would r
2011 Pythonアドベントカレンダー(Python3) - connpass の3日目を担当します。 Python 3 がリリースされてから、 Python の進化は主に Python 3 で行われ、そこから Python 2 にバックポートできるものがバックポートされています（例: GCのチューニング、辞書の内包表記など）。 しかし、 Python 2 は 2.7 で新規開発を終了しており、 2.7 にバックポートされなかった機能はもう Python 3 に移行しないと利用することができません。今日は、そんな機能のひとつである New GIL を紹介します。 なお、今日紹介する内容のほとんどは UnderstaindingGIL で紹介されている内容を僕なりに要約したものです。（ただし、翻訳ではありません） 著作権の扱いがわからなかったのと、代わりに自分で図を書き起こすのが面倒だっ
2024年下半期のフィルム写真たち ふと気がつくと2024年も残り僅か。 そしてふと振り返るとこのブログに掲載する写真がGRIIIで撮ったものばかりになっていたのだけど、決してフィルムに飽きたということではなく、フィルムはフィルムで淡々と撮り続けているし、モノクロもカラーネガもいつも通り自宅で…
Bob Ippolitoは2006年にEventletの最初のバージョンを書きましたが、割とすぐに開発をやめてしまいました。Donovan Prestonは当時働いていたLinden Labの他の人とメンテナンスを行いました。ステートマシンやコールバックを使うよりも簡単にネットワークソフトウェアを方法を探しており、2008年にEventletに興味を持つようになりました。GreenletをベースとしたEventletは、当時あった他のフレームワーク(PYthonネイティブのジェネレータ、生のgreenlet、Corotwine)よりも、使いやすさという点で進んだものでした。 その時関わっていたプロジェクトはTwistedを使っていたので、二つのライブラリを統合することから始めました。作業をしているとEventletの大量のバグを見つけて、ほとんどのコア部分を書き換えました。修正したブランチ
Katana プロジェクトの概要 Howard Dierking ASP.NET が初めてリリースされた 2002 年当時の状況は今とは異なり、まだインターネットの揺籃期で、ユーザー数は約 5.69 億人、1 日の平均利用時間は約 46 分、Web サイトの数は約 300 万でしたが、わずか 10 年後の現在、インターネットのユーザー数は 22.7 億人、1 日の平均利用時間は 4 時間、Web サイトの数は 5.55 億に達しています (bit.ly/MY7GzO、英語)。 このような増加が、Web アプリケーションの構築と実行の基盤となるフレームワーク、ツール、ランタイムに対するアプリケーション開発者のニーズを急激に変化させたことは明らかです。最新の Web アプリは、迅速に変化できるように多種多様なコンポーネントやフレームワークを利用する必要があります。その上、クラウドのように大掛か
OWIN — Open Web Interface for .NET こないだ 1.0 になった ASP.NET SignalR をインストールしたときに、Owin とか Microsoft.AspNet.SignalR.Owin がインストールされてるので気が付いた人もいると思いますが、SignalR はこの OWIN 上でホストされていたりします。 そして、事実上の OWIN リファレンス実装が Katana Project です。 Katana Project - Home ちゃんと SignalR の GitHub リポジトリを見ると、submodule として Katana が取り込まれてます。 で、OWIN って結局のところ何？使うと良いことでもあるん？という感じなので、まずは仕様書を確認しましょう。 OWIN — Open Web Server Interface for .
典型的で孤立したWebアプリケーションは、いくつかのI/OチャネルからHTTPリクエストを受け入れ、内部でそれを処理し、HTTPレスポンスを出力し、それをクライアントに送り返します。これは、アプリケーションが終了を命令されるまで繰り返し行われます。 この事は、WebアプリケーションがHTTPを直接的に話す必然性がない事を意味します: WebアプリケーションはあるHTTPリクエストの何種類かの表現を受け入れる事を意味します。
ども、大瀧です。 最近、お客さまからの問い合わせからElastic Load Balancing(ELB)の負荷分散について調べ社内資料としてまとめる機会がありました。せっかくなので、ブログ記事として公開してみます。内容は随時アップデートしますので、ツッコミ・ご指摘があればぜひお願いします！ 負荷分散の仕組み ELBは、クライアントのリクエストを受け付けEC2インスタンスにトラフィックを転送するために、2種類の負荷分散を組み合わせて動作します。 スケーラビリティと冗長性のために、ELBはロードバランサの機能を提供するノードを複数動作させるはたらきがあり、クライアントから複数のノードへアクセスを分散させるためにDNSラウンドロビン、ノードからEC2インスタンスへのトラフィック転送を分散させるためにLeast Connsという手法を用いています。 DNSラウンドロビン DNSラウンドロビンはそ
資料はslideshareに上げました。 ジェネリクスの基礎と クラス設計への応用 ジェネリクスの基礎と�クラス設計への応用 from nagise 内容はジェネリクスの基礎的なところから、話題を網羅する感じでかいつまんで紹介といったところです。 セッションの元ネタは当blogの過去記事なのでつっこんだ情報が欲しい人はGenericsカテゴリを参照してください。 セッション中に出てきた比較的ライトで比較的実用的な部分は以下の過去記事を読むと良いでしょう ジェネリックな設計 基礎編 (2012年のJJUGセッションの補足)導入部、3種類の山括弧 Javaジェネリクス再入門 3種類の山括弧、2種類のスコープ ジェネリクスの代入を理解する その１ (旧blog)パラメタライズドタイプの代入互換性 ジェネリクスの代入を理解する その２ (旧blog)ワイルドカードの代入互換性 ジェネリクスの代入互
2013/10/17に弊社オフィスにてサーバー・アプリケーションの監視サービス、New Relicについての勉強会を開催しました。 PaaSやAWS上でNew Relicを使っている方は非常に多いようですが、問題の解決方法などについて利用経験のある方で情報交換の機会にと思い企画しましたがとても素晴らしい内容になりました。 各講演の資料と動画をご紹介します。当日のツイートについても下記にまとめてあります。 New Relic Night まとめ #eytokyo - Togetter その他の感想記事 New Relic Night に参加してきた - Blogaomu New Relic入門 @yando New relic from yandod New Relicの基本的な所についての解説です。いくつかあやふやな点がありましたが、後続の講演でフォローしていただけましたので今回の
土曜にJJUG CCC 2013 Fall（http://www.java-users.jp/?page_id=695）へ行ってきました。 事前にお知らせするのを忘れていましたが、17:15〜18:05のセッションでJVMのソースコードリーディングについてお話ししましたので、発表資料を公開します。 R5-5 JVMコードリーディング入門 〜JVMのOS抽象化レイヤーについて〜 JVMのコードを読みはじめたばかりの方を対象に、JVMとOSのメモリを中心とした関係性についてお話しします。JVMはOSからどのようにメモリを確保しているのでしょうか？ そんな素朴な疑問をもとに、JVMのコードを楽しく追いかけてみましょう。※このセッションは入門者向けです。バイトコードやGCについては扱いません。 虎塚 (さくらば組) http://www.java-users.jp/?page_id=709#r5-
昨日のSeasar2のエントリについたコメントなどで、「とはいえ代わりに何つかうの？」みたいな話が出てたので、とりあえずJava EEのWebフレームワークについて簡単にまとめてみます。 Java SE 8+Java EE 7+lombokで書いていますが、基本的なところはJava SE 7+Java EE 6でも大丈夫です。 なので、今どきとは書いてますが、基本的には2009年12月のJava EE 6ということで、実はすでに4年近くたってます。 何も考えてない なんも難しいこと考えないなら、やっぱJSPが楽ですよね。 なんでも書けちゃう。 <%@page contentType="text/html" pageEncoding="UTF-8"%> <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content=
本ブログの読者の皆様方におかれましては、JavaのArrayListとLinkedListの 実装の違いにより性能に差があることは、当然のように熟知のことと存じあげます。 しかし！ 実際にいかほどの差があるのか、それを数値で説明できるという方はどれほどいらっしゃるでしょうか。 いきなり丁寧語の煽りでスタートしました @cero_t です。 そう、今日のテーマはマイクロベンチマークです。 たとえば、 文字列を + で結合すると遅い。 ArrayListの初期化時にはサイズを指定したほうが良い。 ArrayListはループ処理が得意、LinkedListは途中の追加が得意。 など、よくあるパフォーマンスのプラクティスについては既に知っているという方も多いと思うのですが 実際に何倍ぐらいの差なのか（どれぐらいのオーダーの差なのか）を数値で話すことができるという方は、 あまり多くないように思います
ここ数週間、Joel Spolsky(リンク)とRobert C Martin(リンク)(Bobおじさんと呼ばれている)の間で議論が交わされている。そもそもの発端は、Jeff Atwood (リンク)とJoel Spolskyの「38:th Stack Overflow」 (リンク) というポッドキャストで、Joelの「よくユニットテスティングをJoelテストの13番目の項目に加えるべきだと言われるんだけど、それには反対なんだ」という発言だった(Joelテストとは、「Joelテスト: よりよいコードのための12のステップ」のことだ) (リンク)。Joelはこのように説明している(リンク)。 テスト駆動開発について議論されていることですが、すべてはユニットテストすべきだという意見があります……たくさんの人が私に、Joelテストを読んだ後で、「13番目の項目としてユニットテスティングを加えるべ
2006年1月に開催されたソフトウェアテストシンポジウム in 東京（以下、「JaSST '06」と記す）では、アメリカからリック・クレイグ氏が招待され、基調講演が行われた。 クレイグ氏は、リスク分析を行い、リスクに基づいてテストの優先度を決める、という考え方を提唱した人である。 このリスクという指標は、テストケースやバグの重要性を評価する上で、たいへん分かりやすく、かつ有効である。リスクに基づいてテストを考えることは、今では当たり前になっている。実際、JaSST '06のテスティングライブやパネルディスカッションでも、リスクという言葉が盛んに使われていた。 これを見ると、クレイグ氏が提唱した手法は、日本で広く受け入れられているように思われるかもしれない。 だが、日本国内で使われているリスク分析と、クレイグ氏が提唱した本来のリスク分析には、大きな違いがあるように感じられる。 アメリカと日本
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く