第3回Rails2.0で作るRESTfulアプリケーション(後編) 鎌田達哉(かまだたつや) 2008-05-23
第3回Rails2.0で作るRESTfulアプリケーション(後編) 鎌田達哉(かまだたつや) 2008-05-23
Ruby on Railsによるエンタープライズアプリケーション開発のための書籍です。本書ではRuby on Railsが省みることのなかった価値観のひとつであるデータ中心のアプローチに取り組み、これをRailsへと統合する方法を示しています。Railsが得意とするWebアプリケーションに、エンタープライズ分野で培われてきた安定したデータ基盤の構築ノウハウを取り込んでいます。また、そこから一歩進んで、Webサービスによる分散システムの構築や統合というテーマも扱っています。 エンタープライズ開発のエッセンスが詰め込まれた本書は、開発現場のアーキテクトおよびプログラマ必携の一冊です。 監訳者まえがき はじめに 1章 全体像 1.1 エンタープライズとは何か? 1.2 ゆっくりと成長する 1.3 すべての部品を理解する 1.3.1 永続化層 1.3.2 アプリケーション層 1.3.3 キャッシュ
はじめに Yahoo!やYahoo!JapanがOpenIDサービスの提供を始めたり、MixiがOpenID対応を表明したりと、最近OpenIDについてのニュースを耳にするようになりました。 ところが、OpenIDという言葉は知っていても、実際に使ったことのある方はまだほとんどいないのではないでしょうか。 OpenIDによる認証を提供するサービスが増え、インターネット上でアカウントを持つ人の多くがOpenIDを利用できるようになっています。 さらにOpenIDを扱うPerlやRubyなどのライブラリも充実してきています。 このように、OpenIDを使うための環境は整ってきていると言えます。 そこで、本連載では実際にOpenIDを使ってみながら、その仕組みについて解説していきます。 同時に、仕様では見えてこないOpenIDを使う上でのコツも、説明していければと思います。 OpenIDとは O
Rails Style Guideに載っていることが分かれば大体Rails書ける気がしました。もちろん実際に書けるというのと、知識として知るのは全く別のことだと思うのですが、知識としては要点がかなりおさえられている気がしました。 Rails Style Guideで言っていることが分かれば大体分かってる もちろんRails Style Guideは個々の単語(ActiveRecordとかMigrationとか)が分かっている前提で書いてあるので、その分のハードルは高いのですが、逆にここで書いてあることが理解できれば大体Railsのコードが書けるし読めるという到達点が示されている、と捉えることもできます。 昔流行った遅延学習法の話に遡るわけでもないのですが、1から積み上げで勉強していくのも退屈だし、0の段階からいきなりコードを書くのも若干ハードです。何より、知識としてどこまで学べば良いのか分
『パーフェクト Ruby on Rails』(すがわらまさのり, 前島真一, 近藤宇智朗, 橋立友宏)を読みました。「Rails 開発に慣れてきたかな」くらいの人にちょうどいい内容だったと思います。それくらいレベルの人が少し上を目指したり、より Rails らしい設計や開発の仕方を学んだりするのにいい書籍だと思いました。Ruby 2 や Rails 4 向けの説明になっているので、新しめの情報を得たいような場合にもお薦めです。逆に、最新の Ruby や Rails でバリバリ開発しているような人には既知のことばかりで物足りないんじゃないかなという印象です。 全体的に興味はあったのですが、購入の決め手となったのは第9章「より実践的なモデルの使い方」です。どう設計するか、どうリファクタリングするかの1つの指針として読んでみたいと思いました。実際に読んだ感想としては、学びも多く、読んでよかったと
Railsアプリケーションをデプロイしようとするとさまざまな問題が生じるため、Railsアプリケーションの開発は好きだけれどもデプロイは嫌いという技術者は少なくありません。本書はアプリケーションのデプロイ時に技術者が直面するさまざまな問題の解決策を体系的にまとめたRailsデプロイガイドです。本書ではまずRailsアプリケーションのデプロイを家探しにたとえて解説します。そして、一連のデプロイ処理の中で、Railsアプリケーションのホスティング方式の選択、デプロイの自動化、サーバ管理、クラスタリング手法といった高度なトピックについて詳しく解説します。 サンプルPDF ・監訳者まえがき、賞賛の声、まえがき ・6章 ・8章 監訳者まえがき 賞賛の声 まえがき 1章 実運用環境に適したアプリケーション 1.1 背景 1.2 ソースコード管理 1.2.1 RailsとSubversion 1.2.2
Railsの仕組みを体系的に学べる大型コンテンツ Rails Guides に基づいた1,600ページ超えの大型リファレンスです。 プロダクト開発に役立つ実践的な知識が満載 Railsチュートリアルを完走し、プロダクト開発中の人に最適です。 全文検索やバージョン毎の検索にも対応 Proプランでは、さらに効率的な活用をサポートします。 このアイコンが付いているガイドは現在作業中 (WIP: Work In Progress) です。作業中のガイドはそれなりに有用ではありますが、不完全な情報やエラーが含まれている可能性があります。 はじめに Rails をはじめよう Railsのインストール方法と最初のRailsアプリケーションの作成に必要なすべてを解説します。 モデル Active Record の基礎 Active Recordの基礎となるモデル、データベースへの永続的な保存、Active
第40回RVM(Ruby Version Manager)による環境構築(2) 三村益隆 2010-04-27
プロジェクト管理ツールの必要性 みなさんのプロジェクトは上手に運営できていますか? プロジェクトメンバーのタスクの進捗管理はできていますか? 問題・課題管理はスムーズに行えていますか? ExcelやWord、紙資料を用いた管理で、作業が煩雑になっていませんか? 進捗報告ミーティング用の会議資料作成やチームメンバとの情報共有のために、大きく時間を取られていませんか? ファイルサーバには必要かどうか判断できない無駄な資料があふれかえっていませんか? ソースコードはきちんと管理されていますか? リリース用のソースコードに、どんな機能が盛り込まれ、どんな不具合が解決したのか、ちゃんと把握できてますか? プロジェクトが混沌としてくると、ドキュメントやソースコードの構成管理がぼろぼろになり、プロジェクトメンバの作業の進捗具合をリーダが見通せなくなります。その結果、上記のような問いかけに対して「できてい
先日、Rails で開発しているときに意図しない InvalidAuthenticityToken エラーが発生して、すごくハマってしまいました。そのときに Rails のCSRF対策の仕組みについて調べてみましたので、ブログに残しておきます。 Rails のCSRF対策 Rails が生成した ApplicationController には以下の記述があります。 class ApplicationController < ActionController::Base # Prevent CSRF attacks by raising an exception. # For APIs, you may want to use :null_session instead. protect_from_forgery with: :exception end protect_from_forg
RailsでAPIを雑に書いていたんだけど, コントローラとかをどう書くとエラー処理しやすくなっていいかなーと考えていて, 個人的に考えがまとまったのでブログ書いた. ※9/1に追記書いた. 良いエラー処理について 個人的にAPIを書く上で(API書くに限らない気はするけど)どういうふうにエラー処理を行うと良いかなーと考えてみると コントローラ内では基本的に, ある関数の処理が失敗して, 次の処理が行えない場合はすべて例外を投げる 例外は各々のコントローラ内で例外のキャッチは行わず, すべてApplicationControllerなど, 親コントローラ内の1メソッドで完結させる かなーと思う. APIのエラー処理は, Envelopeにステータスコードとエラーメッセージを書いて, APIのフォーマットを統一するほうがクライアントが作りやすそうだし, またこのように処理することで, エラー
例外を利用して実装すると便利な場合が多い この投稿では、HTTP経由でJSONを返すようなWeb APIをRailsを利用して実装するとき、エラーレスポンスを返す場合の処理をどう実装するとやりやすいのか、というニッチな話題に触れる。APIでエラーを返したいとき、即ち400以上のステータスコードと共にレスポンスを返したいような場合、どう実装するのが良いか。もしリクエストの処理中にエラーが検出された場合、それ以降の処理を行わずに直ちに中断してエラーレスポンスを返したいという場合が多いため、例外を利用して実装すると便利な場合が多い。 例外を利用しない方が良い場合もある 1つのリクエストに複数の問題が含まれている場合、先に見つけた問題だけを報告するようなエラーレスポンスを返すのか、それとも問題を抱えながらも進めるところまで処理を進めて報告可能な情報を全て含むようなエラーレスポンスを返すのか、という
インフラストラクチャー部の成田(@mirakui)です。 Rails の OR マッパーである ActiveRecord ですが、みなさんどのように運用していますか? ActiveRecord を使うと、 SQL を直接扱うことなく、抽象化された表現で RDB にアクセスできるので、アプリケーションの開発効率という観点ではメリットが大きいです。 一方で、 ActiveRecord が駆使されているアプリケーションをサーバに配置してプロダクションとして運用する立場からすると、いくつかの問題に突き当たります。 まずはクックパッド本体アプリケーションにおける、最新の rake stats をご覧ください。 +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC
Ruby on Railsというフレームワークを使うとrails new Hogeとかでアプリケーションのひな形ができちゃって、rails serverでサーバーが立ち上げられたりするわけですが、これは一体どうなってるんだというのを追っていけたらなと思います。誰にでもわかるように書きたいです。今回こそはくじけずに書ききりたい。 railsとbin/railsの違い railsはシステムにインストールされたrailsコマンドを呼ぶ(/Users/ユーザー名/.rbenv/shims/railsみたいな)。 bin/railsはそのプロジェクト下のbin/railsのコマンドを呼ぶ。 bin/rails Railsプロジェクトを作ると、binというディレクトリの中にrailsというファイルがある。これをエディタで開いてみる。 $ vim bin/rails 中身はこんな感じ。 #!/usr/b
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く