Ruby on Railsの，バージョン間での違いのまとめ。 一覧表を見て，Ruby on Railsの発展・遷移の歴史をたどる事ができる。 また，各バージョンの仕様の変化（リリースノート）についてのリンク集も掲載。 一覧表（簡易年表） 現時点での最新版と，次期バージョンの計画まで。 バージョン リリース日 特徴 初代 2004年7月 ・DHHが一般公開 ・15分でブログ作成のデモが話題に 1.x系 1.0 2005/12/14 ・初の正式リリース ・既に高い知名度だった ・機能面では0.14と差異なし ・パラダイムはDRY+CoC 1.1 2006/03/26 ・Ruby 1.8.4推奨 ・各種ライブラリ改良 1.2 2007/11/24 ・1系の安定版(1.2.6) ・Ruby 1.8.6推奨。1.8.7では動かず 2.x系 2.0 2007/12/07 ・デフォルトDBがSQLite
こんにちは、＠IT編集部の西村賢です。IT系のオンラインメディアで編集・記者をしております。タイトルに「ど素人」と書くと、ちょっと嘘になるので「素人」と書きましたが、素人がWebアプリを作ってみた体験談と感想を書いてみたいと思います。「オレもプログラミングを勉強して何か作ってみたい！」と考えている人や、「自分でサーバを借りて何かやってみようと思っていたんだよね」という人の参考になれば幸いです。 去年の夏、Webアプリケーション開発フレームワークのRuby on Railsのことを調べていて「面白そうだな」と思い、ドキュメントに従ってサンプルアプリをいくつか作ってみました。作ったり壊したりしている間に、こう思いました。 「あれ？ これなら自分が欲しかったサービスが作れちゃうんじゃないの？」 で、「Worklista」（ワークリスタ）という名前のWebサービスを作りました。3カ月ほど前から親し
Ruby on Railsは、バージョン2系から3系へと移行しつつあります。このメジャーバージョンアップは現在も進行中で、2010年8月29日に出たバージョン3.0は、その後、バージョン3.0.9までマイナーバージョンアップが進んでいますし、2011年5月22日にはRails 3.1のリリース候補版がリリースされ、正式リリースが目前に迫っています。そして、実はバージョン3.2や、4.0の話まで聞こえてきています。 7月25日に発売される『Rails3レシピブック 190の技』（高橋征義／松田明／諸橋恭介著、ソフトバンククリエイティブ）の刊行記念イベントとして東京・池袋のジュンク堂で行われたトークイベント「最新のRuby on Railsの魅力を語る～3.0、3.1、3.2、そして4.0へ～」から、Railsの最新トピックに関連する気になる発言をピックアップしてお伝えします。 このRails
JavaScriptへコンパイルして実行することを前提としたスクリプト言語「CoffeeScript」がちょっとした注目を集めています。CoffeeScript自体は2009年末に登場し、その1年後の2010年12月にバージョン1.0がリリースされていますが、注目を集めたのは、数日前（2011年4月13日）にRuby on Railsの生みの親であるDHHが、次期バージョンのRails3.1でjQueryやSCSSと合わせて、CoffeeScriptをデフォルトとして採用するとTwitter上で発言して議論が巻き起こったからです。 Yes, it's true, Rails 3.1 is going to ship with CoffeeScript and SCSS in the box for use with the new asset pipeline. It's bad ass.
日本OSS推進フォーラムは2011年4月11日、Rubyの採用事例集を公開した。富士通ソーシアルサイエンスラボラトリ、日立ソリューションズ、日本ユニシス、シーイーシーが構築した事例を掲載しており、「Rubyの採用が大手システムインテグレータ（SI）でも広がっている」（日本OSS推進フォーラム）としている。 事例集を作成したのは日本OSS推進フォーラムのアプリケーション部会 RubyアプリケーションTF（タスクフォース）。日本OSS推進フォーラムは大手コンピュータメーカーや大手システムインテグレータなどによる団体で、独立行政法人 情報処理推進機構（IPA）が事務局を務める。RubyアプリケーションTFには前述の4社のほか、富士通、NEC、テクノプロジェクトなど合わせて19社が参加している。 事例集に掲載されているのは、水族館の来館者が専用端末やニンテンドーDSで情報を閲覧できるシステムや、社
はじめに Ruby on Railsの2年半ぶりのメジャーバージョンアップである3.0の正式リリースがいよいよ間近に迫ってきました。 Rails 3は、アプリケーション・レベルではRails 2.3との互換性をなるべく保ちながらも、メジャーバージョンアップだけあってフレームワーク自体は隅々にまで徹底的なリファクタリングが施されて更なる洗練を遂げています。結果として、Rails 3では融通の効かないフルスタック構造を捨ててすっきりとしたモジュール独立性が実現されているのですが、この際に、Merbとの合併の影響もあってか、いくつかの新たな外部ライブラリに依存する形になっているのも興味深いところです。 そこで本稿では、あえてRails 3そのものではなく、このRails 3の大改造の舞台裏を支える裏方さんにスポットライトを当ててみたいと思います。 Arelによってパラダイムが大きく変わったAct
英語は苦手ですが、Rails 3 での変更を知りたかったのと和訳の練習を兼ねて訳してみました。 英語力がないのでかなり出来が悪いですが・・・ 公開するか迷いましたが、恥を晒します。 間違いなどがありましたらご連絡を頂けるとうれしいです m(_ _)m (追記) id:willnet さんも和訳をされていました。 実際にRailsを触っている方なので、内容も詳しく正確と思われます。 後編にも期待！！ Rails 3.0 リリースノート和訳 - 前編 - おもしろWEBサービス開発日記 原文: Rails 3.0: Release Notes 1 Rails 2.3.5 から Rails 3 へのアップグレード いつものように、アップグレードの時はカバー率の高いテストスイートがあなたの味方です。 Rail3 にアップグレードする前に、まず最初に Rails2.3.5 にアップグレードし、アプリ
Rails検証報告書: プログラマの思索 Railsで特徴的なのは、CookieでHTTP セッションを管理できることだろう。 ここの仕組みが非常に分かりやすい。 Railsの後から付いた機能で一番素敵だと思うのがこの機能です。 「Cookieなんて仕様上は4KBしか保存出来ないんだから寧ろ弱体化してね？」 とか認識されることが多い気がしてならない。 コレ、導入時にも度肝を抜かれて、以降常に、 「ハンパねー、マジCookieセッションハンパねー！」 と脳内のアフロの人が言ってるんですが、大した利点に感じる人は少ないのか、他の言語やWAFで全面採用している例を見たことが無い。 そもそもセッションという言葉自体が複数の処理をまとめた単位という広義の意味とWebアプリケーションで複数リクエストにまたがってサーバー側に保存されるデータという狭義の意味が混在して使われているという事情があってWeb上
日本OSS推進フォーラムという団体がRailsに関する調査結果を公開していたのでメモ。 【元ネタ】 日本OSS推進フォーラム 「RubyTF_Ruby_on_Rails検証報告書」 （PDF：975KB） おそらくIPOの外郭団体のような立場で、日本の大手SIの技術者がRailsを調査したらしい。 その報告書を読むと、Railsは企業向けにそこそこ使えるが、スケールアップやセキュリティ、技術蓄積にやや難がある、とのこと。 報告書で興味を引いたのは、セキュリティに関する所。 リダイレクト、Web アプリケーション内リンクをSSLにする対応は特に問題なく非常に簡単。 Railsで特徴的なのは、CookieでHTTP セッションを管理できることだろう。 ここの仕組みが非常に分かりやすい。 Railsでは、HTTPセッションをシリアライズ化してCookieに書き込む。 この時、サーバーにもハッシュ
追記(2009/11/29 19:26): Google App Engine 0.0.5 gem では、この記事通り動かすことができなくなっていますのでご注意ください。 google-appengine という gem のおかげで、簡単になっています。XML 書かなくて済みます。 Rails Primer for Google App Engine with JRuby ところで、この記事通りやってもうまくいかなかったので、自分のやり方を書きます。 Hello world アプリを作ってみます。まず、gem で google-appengine をインストールします。 $ sudo gem install google-appengine CRuby の gem です。いろいろと関連 gem がインストールされます。 appengine-apis という gem が入っているとこの後うま
Google App EngineのJava版が出ました。まぁJavaは比較的どうでもいいんですが、嬉しいことにこの上ではJRubyが動くようです。海外の先駆者ががんばってブログを書いてくれたので、いつものように勝手訳してみます。 http://olabini.com/blog/2009/04/jruby-on-rails-on-google-app-engine/ これは最近アナウンスされたGoogle App EngineがJavaをサポートするというニュースに関する記事の3つ目だ。今回の記事ではJRuby on RailsアプリケーションをGAE/Jで動かすのに必要な手順をさらってみて、アプリケーションの特性がどのようになると予想すべきかに付いて書きたい。 まずJRubyは最新版が必要だ。JRuby1.2リリース以降にJRubyのtrunkに加えられた変更のほとんどが必要になるので、
Rails2.3.0 RC1リリース 2/1（日本では2/2）にRails2.3.0 RC1がリリースしました。 今回も多くの更新があるのでリリースノートの一部を訳しました。 Ruby on Rails 2.3 Release Notes 元記事について 元記事はこちらです。正確な内容についてはこちらを確認してください。 更新について 細かい機能変更やバグフィックスを見たい方はコミットリストをgithub落とすか、RailsにあるCHANGELOGファイルを参照してください。 1. アーキテクチャ 1-1. Rackとの統合 Rails2.3ではこれまでつかわれていたCGIモジュールを破棄し、すべてRackをつかうようになりました。これによって多くの内部的な変更を必要としました。（もし、CGIを使っていてもproxyインターフェイス経由でCGIを利用することができるので心配しないでください
Rails 2.2RCがリリースされました。 国際化(i18n)、スレッドセーフ化など、 うれしい機能が多数追加されているようです。 リリースノートが公開されていたので簡単に日本語訳してみました。 誤り等あればご指摘ください。 ※原文はRuby on Rails 2.2 Release Notesにあります。 Ruby on Rails 2.2 リリースノート Rails 2.2では様々な新機能、改良が施されました。 この文書では主要な変更点のみを紹介し、細かなバグフィックス等の説明は行いません。 全ての変更点については、GitHubのrails mainリポジトリにあるコミットリストをご覧ください。 Rails 2.2のリリースとともに、Rails Guides hackfestの最初の成果であるRuby on Rails Guides をスタートさせました。このサイトではRailsの主
Rails pluginとして動く言語、purlを公開しました。 purl はクライアントサイドから柔軟な画像処理を行うために開発されました。 サムネイルの生成などを行うプラグインはいくつかありますが、そのどれよりも強力で汎用性、拡張性があります。 セットアップ Rails2.1以上では、 $ script/plugin install git://github.com/nanki/purl.git それ未満では、 $ git clone git://github.com/nanki/purl.git -- vendor/plugins/purl gitが無い環境なら、githubのdownloadからファイルを落として、vendor/plugins/ に配置してください。 依存ライブラリ 必須: ImageMagick, rmagick あった方がいい: cairo, rcairo その
9Arrows プロジェクトの成果物を細分化し、担当者割り振りやスケジュール・進捗状況の管理を行うWBS（Work Breakdown Structure：作業分解図）。 プロジェクトを管理する上で欠かせないこの手法を中心に、チームとしても個々としても作業を効率的に進められるようになるツールです。 WBSとは？ WBS（Work Breakdown Structure：作業分解図）とは、一言でいうと「やる事リスト」です。 プロジェクトマネジメントで計画を立てる際に用いられる手法の一つで、プロジェクト全体を細かい作業に分割した構成図で「作業分割構成」「作業分解図」などとも呼ばれています。 プロジェクト管理に特化した機能ばかり 日々変化するプロジェクト進行を、効率的に進めるためだけの機能を取り揃えました。タスクの細分化、担当割り振りなどはもちろんのこと、自分のやるべき作業のみのピックアップ
Charles Oliver Nutter Java, Ruby, and JVM guy trying to make sense of it all There still seems to be confusion about the relative simplicity or difficulty of deploying a Rails app using JRuby. Many folks still look around for the old tools and the old ways (Mongrel, generally), assuming that "all that app server stuff" is too complicated. I figured I'd post a quick walkthrough to show how easy it
WhatThreadsafeRailsMeans - スレッドセーフな Rails ってどういうこと? 目次 この文書について Q/A: スレッドセーフな Rails ってどういうこと? Q: Rails がスレッドセーフになるってどういうこと？ Q: なぜこれが重大なの? もう 複数プロセスで shared-nothing なRailsのアーキテクチャで 並列性はあるんじゃない? Q: じゃあ Ruby や Ruby EE, Rubinius みたいなグリーンスレッドの実装は, スレッド対応の恩恵は何もないの? Q. なるほど, じゃ JRuby みたいなネイティブスレッドの実装はどうなの ? Q: それってすごいの? スレッドセーフな Rails ってどういうこと? この文書について "Q/A: What Thread-safe Rails Means" の日本語訳です http://
このURLのページは表示することが出来ませんでした。 IQサーバー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
