Railsでは、タイムゾーンを簡単に扱う仕組みが用意されています。 まず、Rails (今回は3.0系) でアプリを作ると、config/application.rb に config.time_zone = 'Central Time (US & Canada)' のような記述があると思います。日本用のシステムを作るなら、これを"Tokyo"に変えてコメントアウト解除すればOKです。 config.time_zone = 'Tokyo' これで、入出力は日本時間で、DBにはUTC時刻が入ります。 アクセスに応じて動的に変更するには、before_filterなどで以下のように設定できます。 class HogeController < ApplicationController before_filter do Time.zone = 'UTC' end end タイムゾーンをプルダウン
前略、ヤマモトです。 みなさんはウェブサービスを立ち上げる際、タイムゾーンは意識されているでしょうか。 日本国内のみのサービスであれば、時間帯は1つなので特に意識する必要はないと思いますが、 これが全世界で利用して欲しいサービスであれば話が変わります。 日本時間で「午後1時から午後2時まで限定公開」というプレミアコンテンツを予告し、全世界に公開したとしても、日本時間であると注釈しない限り、ユーザーはその地域の時間だと捉えるでしょう。 「見てみたらまだ始まってなかった」ならまだいいでしょうが、日本は、全世界でも先の時間を行ってますから、ほとんどの地域の人からしたら「見てみたら終わってた」状態ですね。 話は逸れますが、アメリカのような複数のタイムゾーンがある国では、ウェブサービスの時間の処理はどう行っているんでしょうか。 いや、ウェブサービスに限らず、例えばテレビ番組は、ニューヨークでは午後7
Heroku にデプロイしたアプリが、config/application.rb で config.time_zone = 'Tokyo' としても、日付時刻が 9時間ずれて表示されてしまいました。アプリのコードで Time.now.in_time_zone あるいは Time.zone.now などとするか、サーバの環境変数 TZ を Asia/Tokyo にすることで対応できました。 $ heroku run console ... irb(main):001:0> Time.now.strftime("%Y-%m-%d %H:%M") => "2013-01-27 02:55" irb(main):002:0> Time.now.in_time_zone.strftime("%Y-%m-%d %H:%M") => "2013-01-27 11:57" irb(main):005:0>
2011年08月25日16:55 カテゴリrailsactiverecord Rails3のActiveRecodeで複数のwhere条件をORで書く Rails3になってからArelが導入されてnamed_scopeが便利だなぁ〜と思いつつも、where条件をORで接続するにはどうすんだ?って ことで調べてみた。 ■今回の要件 1.Employeeテーブルから名前(漢字)で検索できる。 2.Employeeテーブルから名前(カナ)で検索できる。 3.カナでも漢字でも検索できる。 4.検索対象フィールド(姓、名、セイ、メイ)を動的に指定できる。 例えばEmployeesテーブルが以下のよう場合 class CreateEmployees < ActiveRecord::Migration def self.up create_table :employees do |t| t.string
Rails3ではSQLを扱うためにArelというヤツを使っています。 Rails2は使ったことがないですが、ActiveRecordのインターフェイスとして2と3では似ているようです。 そのためArelを使ってどのようなことができるのか、情報が少ないうえに新旧の情報が入り混じっているためになかなか調べるのが大変でした。 「ちょっと複雑なSQLを作ろうとすると直接SQLを書かなくてはいけなくなる」という内容の記事もよく見かけました。 デフォルトでは難しそうだと感じた私はプラグインを探してみて、 meta_search、その進化版のRansack、またSqueelも試してみました。 プラグインを使うと「簡単!」と思えるところと、逆に「難しい!」と感じるところとありました。 「SQLを直接かくか、、」と何度も思いましたが、ぐっとこらえてなんとかスマートに複雑な検索を実現できないかを試行錯誤
レンタルサーバなら「さくらのレンタルサーバ」! 月額換算でわずか131円、缶ジュース1本分のお値段で使える格安プランから、ビジネスにも使える多機能&大容量プランまで、 用途と予算に合わせてプランを選べます。 さらにマルチドメイン対応でメールアドレスも無制限。無料ウイルススキャンや無料電話サポートもあるので安心して ご利用いただける共用レンタルサーバサービスです。
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる(かもしれない)。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く