第3回Rails2.0で作るRESTfulアプリケーション（後編） 鎌田達哉（かまだたつや) 2008-05-23
Rails Style Guideに載っていることが分かれば大体Rails書ける気がしました。もちろん実際に書けるというのと、知識として知るのは全く別のことだと思うのですが、知識としては要点がかなりおさえられている気がしました。 Rails Style Guideで言っていることが分かれば大体分かってる もちろんRails Style Guideは個々の単語（ActiveRecordとかMigrationとか）が分かっている前提で書いてあるので、その分のハードルは高いのですが、逆にここで書いてあることが理解できれば大体Railsのコードが書けるし読めるという到達点が示されている、と捉えることもできます。 昔流行った遅延学習法の話に遡るわけでもないのですが、1から積み上げで勉強していくのも退屈だし、0の段階からいきなりコードを書くのも若干ハードです。何より、知識としてどこまで学べば良いのか分
はじめに: 技術ネタは最近Qiitaに書いています このブログはもともと「技術系ブログ」としてスタートしました。 イメージとしては「技術的な問題に遭遇してググったら引っかかるようなサイト」です。 普段そういうページによく助けられているので、自分もgive＆takeの精神で情報発信していこう、と思ったのが動機です。 しかし、去年の夏にQiitaに出会って以来、シンプルな技術的なネタはQiitaに書くようにしています。 理由はQiitaというサービスの方向性がまさに「技術的な問題に遭遇してググったら引っかかるようなサイト」だったことに加え、Qiitaの中の人に出会って「Qiitaにかける情熱」を直接聞いて、僕も応援したいな～と思ったからです。 そんなわけで、このブログが更新されていなくても、ときどきQiitaにポロッとTips的なネタを書いたりするときがあります。 気になる方はQiitaで僕の
こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI（rrrspec）などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本
第40回RVM（Ruby Version Manager）による環境構築（2） 三村益隆 2010-04-27
RubyKaigi 2014、楽しかったし、学びがあって行って良かったなぁと思いました（小並感すぎる）。 淡々とメモしておくよ benchmark-ips ベンチマークの高機能版。ウォームアップとして何回か走らせてから実行したり、5秒とか100msで何回実行できるかとかを計測できるっぽい synvert フォーマッターらしい。Rubyのバージョンがあがってシンタックスを変更したほうがよかったりする場合に変更してくれる Railsバージョンもあるっぽいけど、このセッション聞いてなかったので詳しくはわからない（あとで調べる） peek-performance_bar View や SQL等でかかった時間を表示するプロファイラ rack-mini-profilerと似てる気がするけど、こっちも試してみたい stackprof Ruby 2.1で追加された rb_profile_frames を使
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
Webサイト、Webサービス、WebアプリケーションをRubyで作成するためのDSL、それがSinatraです。本書は、基本的なRubyのプログラミングを理解したプログラマが、Sinatraを使い始めるために必要な知識をコンパクトにまとめた書籍です。ルーティング、ビュー、キャッシュなどを使ったアプリケーションの書き方から、内部構造の解説や、サブクラス化を用いたModularスタイルのアプリケーションを解説。さらにはカスタムブログエンジンを例に、アプリケーション構築の全体を紹介します。なお本書はEbookのみの販売となります。 はじめに 本書の対象読者 本書の構成 基礎 さらに詳しく 実践 本書の表記規約 サンプルコードの利用について お問合せ先 1章 準備作業 Sinatraの特徴 フレームワークなのか MVCを実装するのか 誰が使用するのか 実際のプロジェクトはどのようなものか 問題点は
Rails Guidesでは「Resource Routing: the Rails Default」として namespace, resource, resources といったメソッドを利用する方法が紹介されている。これまでとりあえずこの機能を使って開発してきたが、これは果たして本当に積極的に利用した方が良い機能なのか。 あるとき 試しにTwitterのAPIのようなルーティングを定義しながら、Resource Routingを利用する場合としない場合とを比較してみることにする。ここでは (Resource Routingを利用するメリットを出すためにも)、API用のPrefixとして各パスの先頭に /api/v1 を付けることにする。このAPIはアクセストークンの発行や、tweetの取得、投稿、ユーザやフォロワー情報の取得などの機能を提供する。また、/api/v1 以下のどのパターン
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本当は、RubyWorld Conf辺りでこういう内容も交えてなんか話せればいいなあと思ってたんだけど、CFPに落ちたのでQiitaにポエムを書いてみました。 Railsはそれなりに学習コストはかかりますが、慣れてくるとデフォルトで便利なものが揃ってるしサードパーティライブラリも豊富で、未だに最も便利なWebアプリケーションフレームワークの一つだと思います。 なので、最近のスタートアップ界隈ではRailsで開発をスタートする、という話をよく耳にします。(個人の感想です) しかし、Railsは本体に新しい要素をガンガン取り入れてくるので、
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
─質問１─ Ruby製サードパーティライブラリ、要はgemで、何が人気なのかってこと、手っ取り早く知りたいんですけど。 ─回答１─ RubyGems.orgのstatsページを見てください。 ─質問２─ えっ？これだけ？この辺は万年上位で固定でしょ。もうちょっと俺の知らないバラエティに富んだものに出会いたいんだけど。俺、Rails用ないし。 ─回答２─ カテゴリー別ならThe Ruby Toolboxがあります。 The Ruby Toolbox - Terminal Coloring ─質問３─ あんた、俺の質問ちゃんと聞いてるの？カテゴリー別なんて言ってないし。それに、ここのカテゴリーってなんか俺的に信用ないんだよね。取りこぼし多いっていうか..。俺のgem出てこないっていうか..。 ─回答３─ GitHubのTrendingでここ最近の人気リポジトリが分かります。 Trending
http://individualist.link/ （←ドメインかっこいいでしょ） 〜 居酒屋にて 〜 A「やっぱり若者が稼ぐにはアプリ作るしかないと思うんですよ」 B「あー分かる」 B「スマートフォンアプリ？Webアプリでもいいの？」 C「ゲームは当たると大きくていいよね」 A「Webアプリでもいいです」 B「当ててそれで暮らしてる人見ますね。羨ましい。」 A「いいですよね」 A「そういう人の話聞いてみたいんですけどなかなか出てこないですね」 B「当てた人が人前で自慢するメリットないからねえ…」 B「どういう人がどういうサービスで当てたのかまとめたい」 A「いいですねえ。Wiki 的な」 B「Google Docs とかでやってみる？」 A「おお、やりましょう」 B「Webサービスにしてもいいかも」 〜 帰宅 & １時間後 〜 B「できた」 B「ドメイン取ろう」 B「http:
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 追記 RailsでJS辛い問題に関しての結論：http://qiita.com/kaiinui@github/items/dad6180f1910c6a4bfd5 -- 近年、(1) Web/App両対応が増えてきたこと、(2) WebでもJSを多用するようになったこと、の二つがあり、以下の点でRailsが微妙になっている。 ViewのJavascriptがRailsから独立している API層のサポートが微妙 最初に書いておきますが、特に決定的な解決策もなく、辛いから今後解消されてほしいよね、な話です。 ViewのJavascriptが
Rails + iOSという組み合わせは割と多いと思うんだけど。いちいちサーバーとクライントの繋ぎ込みを自前で書くのはつらいなーと思って調べたら、NSRailsという便利なのがあったので試してみた。 https://github.com/dingbat/nsrails Railsのモデルと対になるものをiOS側で定義しておくとiOSのオブジェクトを操作するだけサーバにデータを永続化したり、データの取得ができる。ざっくりいうとparse.comと非常に使用感が似ている。 導入 導入はcocoapods経由で。Podfileにuse 'NSRails'とかくだけ。 pod 'NSRails' iOS側でRailsアプリの場所を指定するには、AppDelegateで以下のように指定するだけ。 - (BOOL)application:(UIApplication *)application did
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く