テーブル名からカラム情報を取得 - Qiita
users というテーブルに定義されているカラム情報を取得する方法のメモ。 使うAPI: Ruby on Rails API columns() テーブル名からモデルクラスを参照し、それに.columnsメソッドを使うと取得できる。 # テーブル名から、定義されているすべてのカラム定義を取得 Module.const_get('users'.classify).columns # 特定のカラムの情報を取得(例えば `id`) Module.const_get('users'.classify).columns['id'] # 特定のカラムから定義の一部を取得 col = Module.const_get('users'.classify).columns['id'] col.type # データ型を取得 カラムの定義の取得はこんなメソッドが用意されているっぽい。 コレで全てかわからんとです
PadrinoでStrongParametersみたいなことをしたかった - くりにっき
Strong Parametersについて params で受け取った値をホワイトリスト形式で制御するRails4からの機能です。*1 詳しいことは StrongParameters | TECHSCORE(テックスコア) を参照 最近Padrino使ってて同じことができないか調べてました（activerecord 4系を使いたかったので3系のMass Assignmentはスルー） 忙しい人のためのまとめ Params Whitelistingの :params はHashでネストできる いろいろ試してみた padrino 0.12.3 + activerecord 4.1.4 で検証 サンプルコードはいろいろはしょってます 簡略化のためにPOSTされた時のparamsをjsonで表示してます アプリ名は架空のものです サンプル1 何もつけないとparamsには全部入ってくるので、そのま
クックパッドとマイクロサービス - クックパッド開発者ブログ
技術部の高井です。 最近、日本でもマイクロサービスという言葉が流行しつつあります。 今回は、なぜクックパッドがマイクロサービスを選択したのか、また実際にどのようなやり方をしているのかということを紹介します。 Conwayの法則 ここ数年の間、クックパッドはレシピの投稿・検索サービスから「食を中心とした生活のインフラ」として事業領域を拡大しつつあります。海外レシピサービスの買収による海外展開は、単なる金銭的な関係にとどまらず、人的・技術的な交流も含めて本格化しつつあります。また、「モバイルファースト」を標語とするモバイルアプリケーションへの取り組みも加速してきました。 事業領域の拡大やグローバル展開、モバイルファーストといったビジネス要求の変化に応じて、会社の組織構造も変化しています。そして、Conwayの法則 として知られているように、組織構造とソフトウェアアーキテクチャには密接な関係があ
RailsでAPIを作るときのエラー処理について | Yucchiy's Note
RailsでAPIを雑に書いていたんだけど, コントローラとかをどう書くとエラー処理しやすくなっていいかなーと考えていて, 個人的に考えがまとまったのでブログ書いた. ※9/1に追記書いた. 良いエラー処理について 個人的にAPIを書く上で(API書くに限らない気はするけど)どういうふうにエラー処理を行うと良いかなーと考えてみると コントローラ内では基本的に, ある関数の処理が失敗して, 次の処理が行えない場合はすべて例外を投げる 例外は各々のコントローラ内で例外のキャッチは行わず, すべてApplicationControllerなど, 親コントローラ内の1メソッドで完結させる かなーと思う. APIのエラー処理は, Envelopeにステータスコードとエラーメッセージを書いて, APIのフォーマットを統一するほうがクライアントが作りやすそうだし, またこのように処理することで, エラー
RailsでAPIをつくるときのエラー処理 - Qiita
例外を利用して実装すると便利な場合が多い この投稿では、HTTP経由でJSONを返すようなWeb APIをRailsを利用して実装するとき、エラーレスポンスを返す場合の処理をどう実装するとやりやすいのか、というニッチな話題に触れる。APIでエラーを返したいとき、即ち400以上のステータスコードと共にレスポンスを返したいような場合、どう実装するのが良いか。もしリクエストの処理中にエラーが検出された場合、それ以降の処理を行わずに直ちに中断してエラーレスポンスを返したいという場合が多いため、例外を利用して実装すると便利な場合が多い。 例外を利用しない方が良い場合もある 1つのリクエストに複数の問題が含まれている場合、先に見つけた問題だけを報告するようなエラーレスポンスを返すのか、それとも問題を抱えながらも進めるところまで処理を進めて報告可能な情報を全て含むようなエラーレスポンスを返すのか、という
Railsでルーティングが無いときの挙動を変える - Qiita
挙動を変えたい場合がある config/routes.rbに定義されていないパターンのパスを持つHTTPリクエストが来ると、Railsは非Production環境では例外を発生させ、Production環境では404用のレスポンスを返す。HTMLであればpublic/404.htmlを変更すれば幾つかの要求は満たせる。しかし、例えばJSONを返すAPIを提供したい場合、またレスポンスを動的に返したいような場合、任意の処理を実行可能にしたいという要求が生まれる。 全パターンに一致するルーティングを定義する 例えば GET /v1/users のように/v1以下をAPI用のパスに利用しており、/v1/foo などの定義されていないパスにリクエストが来たとき、適切な処理を実行させたいものとする。これは、matchを利用して全てのパターンに一致するようなルーティングを末尾に定義しておけば実現できる
クックパッドにおける最近のActiveRecord運用事情 - クックパッド開発者ブログ
インフラストラクチャー部の成田（@mirakui）です。 Rails の OR マッパーである ActiveRecord ですが、みなさんどのように運用していますか？ ActiveRecord を使うと、 SQL を直接扱うことなく、抽象化された表現で RDB にアクセスできるので、アプリケーションの開発効率という観点ではメリットが大きいです。 一方で、 ActiveRecord が駆使されているアプリケーションをサーバに配置してプロダクションとして運用する立場からすると、いくつかの問題に突き当たります。 まずはクックパッド本体アプリケーションにおける、最新の rake stats をご覧ください。 +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC
Railsをバージョンアップし続けるために必要なこと - Qiita
本当は、RubyWorld Conf辺りでこういう内容も交えてなんか話せればいいなあと思ってたんだけど、CFPに落ちたのでQiitaにポエムを書いてみました。 Railsはそれなりに学習コストはかかりますが、慣れてくるとデフォルトで便利なものが揃ってるしサードパーティライブラリも豊富で、未だに最も便利なWebアプリケーションフレームワークの一つだと思います。 なので、最近のスタートアップ界隈ではRailsで開発をスタートする、という話をよく耳にします。(個人の感想です) しかし、Railsは本体に新しい要素をガンガン取り入れてくるので、バージョンアップのサイクルはかなり早く、それに追従していくのはそれなりに大変です。 Railsで開発をする場合には、一旦レールに乗ったらプロダクトが死ぬまで走り続ける覚悟が必要です。(時速60km以下になったら爆発する) それを最初に理解しておかないと、あっ
Railsでモデルの一覧を取ってくる - ぴよログ
アプリケーションの中にあるModelのレコードを数を調べたかったので、それをプログラムから動的に行う方法を考えてみた。 ActiveRecord::Baseのサブクラスを取ってくればいいはずだ！ということで、ActiveRecord::Base.subclassesを使うことにした。確認にはrails consoleを使った。 % rails c ActiveRLoading development environment (Rails 4.1.0) Frame number: 0/5 [1] pry(main)> ActiveRecord::Base.subclasses => [User (call 'User.connection' to establish a connection)] [2] pry(main)> UserというModelが取れたことはわかる。でも実はこのアプリケ
Railsアプリのステージング環境を自動で構築してくれるTeatroというサービスの話。 - Sooey
Railsアプリのステージング環境を自動で構築してくれるTeatroというサービスの話。 Teatro 動作の流れは、 GitHubアカウントでサインアップする 連携させるリポジトリを選ぶ（GitHub側にフックが設定される） リポジトリにPull Requestが作成されると、自動的にステージング環境の構築が始まる（その際、PRにもコメントがされる） ステージング環境の構築が完了すると、http://ブランチ名.Organization名-リポジトリ名-トークン.ttrcloud.com/ のようなURLが割り当てられる といった感じ。 詳細な設定方法やどんなミドルウェアが使えるのかについては、Helpを参照しましょう。 現時点では以下のミドルウェアが使えるようです。 PostgreSQL MySQL Redis Elasticsearch RabbitMQ MongoDB 試しに、He
RailsでTypeScriptを使う - Kentaro Kuribayashi's blog
JavaScriptは設計が難しい。経験上、すぐグシャグシャになってしまう。よくわからなくなる。もちろん、私のスキル不足というのはあるだろうけれども、スキルが不足してるのはしかたないので、学習は続けることは前提であるにしても、技術的に解決できるなら技術に頼りたい。そうした意味で、いわゆるAltJSの中ではTypeScriptが有望だろうと思う。 RailsとTypeScript TypeScriptを使うにしても、それ単体で使うというシーンは、Webアプリケーション開発という文脈ではあまりない。たとえば、Railsで開発しているWebアプリケーションのフロントエンドを構成する言語として使うことになるだろう。その際、まず考えるべきことは、Asset Pipelineとどう折り合いをつけるかということだろう。 Asset Pipelineは、以下の機能を担っている: 拡張子(例:applica
Ruby on RailsにSQLインジェクションの脆弱性、直ちに更新を
オープンソースのWebアプリケーション開発フレームワーク「Ruby on Rails」に2件のSQLインジェクションの脆弱性が見つかり、修正のための更新版が7月2日にリリースされた。 Ruby on Railsのサイトに掲載された情報によると、脆弱性はActive Record用のPostgreSQLアダプタに存在し、ビット列型、または範囲型を使っているアプリケーションが影響を受ける。 ビット列型の脆弱性はバージョン2.0.0～3.2.18に、範囲型の脆弱性はバージョン4.0.0～4.1.2にそれぞれ存在する。悪用された場合、細工を施した値を使って任意のSQLを挿入される恐れがある。 これら脆弱性は、更新版の3.2.19、4.0.7、4.1.3で修正された。直後にリグレッション問題に対応するための4.0.8と4.1.4がリリースされている。
Railsの作者DHH、ルマン24時間耐久レース アマの部で勝利
モータースポーツとWebプログラミングの両方を知る人にとっては大きなニュースです。 タイトルの通り、Railsの作者として知られるDHHがルマン24時間耐久レース、アマチュアクラスで1位になったとのことです。（全体では17位)まさかこのサイトからスポーツニュースのサイトを参照するとは予想外ですが、結果を伝えるニュースにも「DHハンソン」の文字が。 WikipediaのDHHのプロフィールによると、ルマン24時間耐久レースへの参戦は今年で3年目で、写真と並んで彼の「趣味」であるとのこと。またSimple Talkのインタビューの記事によるとシルバーストーンやスパなどルマン以外のレースに参戦しているようです。 https://www.simple-talk.com/opinion/geek-of-the-week/david-heinemeier-hansson-geek-of-the-wee
Rails SQL Injection Examplesの紹介
6. 脆弱性のあるアプリケーション Copyright © 2010-2014 HASH Consulting Corp. 6 @books = Book.where( "publish = '#{params[:publish]}' AND price >= #{params[:price]}") 山田 祥寛 (著) Ruby on Rails 4 アプリケーションプログラミング 技術評論社 (2014/4/11) に脆弱性を加えましたw ※元本に脆弱性があるわけではありません 7. UNION SELECTにより個人情報を窃取 Copyright © 2010-2014 HASH Consulting Corp. 7 priceに以下を入れる 1) UNION SELECT id,userid,passwd,null,mail,null,false,created_at,updated
Railsに組み込むgemを作るためのTips - AnyType
params_inquirerというgemを作りました。何ができるかと言うと、文で説明するのがなかなか難しいので、下のコードを見てください。 # users_controller.rb def index if params[:status].accepted? # params[:status] == 'accepted' と同じ @users = User.accepted elsif params[:status].rejected? # params[:status] == 'rejected' と同じ @users = User.rejected else @users = User.all end end params_inquirerを使うと上のaccepted?のようなメソッドがparamsに対して呼べるようになります。すでにrubygemsで公開してるので、ちょっと試して
Railtie を使った Rails3の拡張 (翻訳版) - Engine Yard Blog JP | Engine Yard Blog JP
この記事はコミュニティ ゲスト投稿者兼 Engine Yard OB の Andre Arko 氏から英語版ブログで2010年10月3日に寄せられたものです。Arko 氏は 5 年前から Ruby and Rails を使ってウェブ アプリケーションを作成されており、Bundler コア チームのメンバーでもあります。同氏は Plex に勤務するかたわら、@indirect としてのツイートや、andre.arko.net でのブログも公開しています。 Rails 3.0 の gem プラグイン ついに Rails 3.0 がリリースされました。このバージョンには Railtie という、Rails を拡張するための素晴らしい新機能が追加されています。Railtie は Rails 3 のコア コンポーネントの基盤であり、これには Carlhuda さんが何か月もかけて丁寧にリファクタリン
パーフェクトRailsで俺が書いた所について思うこといくつか - joker1007’s diary
既に大きい書店の店頭には並んでいる所もあるようで、自分もアキバの書泉で現物を見てきました。 立ち読みして、ほほーうとやってる著者の図って感じです。 献本させていただいた方にも、既に届いていて読んだよーって言ってくれてる方がちらほら。 参考になったと言っていただけて、とても嬉しく思っています。 さて、今回はちょっと自分の担当した部分と思ってた事について少し書いてみたいと思います。 私が担当したのは、3章のアセットについてと4章のlibディレクトリ周り+Railsのロードパスについて、そして9章のモデル実践編みたいな所です。 一応それぞれありますが、主に言いたいのは9章についてですw 3章について CoffeeとSassについて、どの程度解説するか非常に悩みました。 実際、書くとなるとリファレンスマニュアルを日本語で解説する、以上の事はページ数的にできない。 かといって、昨今のRailsアプリ
書評『パーフェクトRuby on Rails』 - miyohide's blog
『パーフェクトRuby on Rails』を献本いただきました。ありがとうございます。 パーフェクト Ruby on Rails 作者: すがわらまさのり,前島真一,近藤宇智朗,橋立友宏出版社/メーカー: 技術評論社発売日: 2014/06/06メディア: 大型本この商品を含むブログを見る 早速レビューを。 本書の紹介 全体的に、現場でRailsアプリケーションを開発し、運用する上で必要な物が網羅されている本です。 例えば、他の本で「おまじない」のように書かれているAsset Pipelineの説明も何故このような書き方になっているのか、それぞれにどのような意味があるのかを書かれています（第3章）。 また、Railsのロードパスでなぜlibディレクトリがオートローディングの対象になっていないか（第4章）にもページが割かれています。 第1章と2章は環境構築とRailsの基本的なことについて書
Rails でテストをどう書くべきか備忘録
今朝聞いた今週の rebuild.fm のポッドキャストで、テストに関する話題がとても面白く勉強になりましたので備忘録メモ。全部テスト書いてたら時間が足りないし、個人的にはどの部分を重点的にテストすべきか、削っても良いのはどこかに注目して聞きました。 Rebuild: 43: Kent is More Professional (Kenn Ejima) 以下 rebuild.fm 話題から参考にしたいメモ ・テスト書くのは良いが、テスト原理主義、100％カバー、全部テストファーストにこだわるのは疑問。 ・内部構造、実装に対するテストは書かない。 ・モックは一番外側のAPI、インターフェースに対してだけ使う。（※） ・モックのためのモックとかは避ける。 ・リファクタリングのためにテストを書き換えなきゃいけないようなテストは駄目。 ・テストとコードを同時に変更すると、トラブルに気付きにくくなる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PullReview