migration の中で model を触ったら必ず reset_column_information する - onk.ninja
migration の中で model を触ったら必ず reset_column_information する 治安の悪い Rails アプリケーションでは、migrate 中に model の不整合で怒られることがあります。 class AddAgeToUsers < ActiveRecord::Migration[5.1] def up p User.first # 1 add_column :users, :age, :integer # 2 User.create(name: "Taro", age: 16) # 3 end end 1 で User model を触ってしまっているので add_column 前の DB の状態がキャッシュされて 2 で追加した add_column は別にキャッシュをリセットしないので 3 で ActiveModel::UnknownAttrib
Rails での JSON API 実装まとめ - onk.ninja
Rails での JSON API 実装まとめ 前後リンク RESTful API のおさらい Rails での JSON API 実装まとめ スキーマファースト開発 The NEXT of REST Ruby on JSON の図のような流れになるんですが、それぞれ見ていきます。 to_json (2011-2013 頃) 2011-2013 年頃、僕らは render :json を使っていました。 render json: @user render json: @user.to_json として User#as_json や User#to_json を利用します。 この頃はまだ SPA という言葉もなく、ネイティブアプリもそこまで流行っていなかったので これで十分だったのですが、どんどん API に世の中が寄っていき、限界を迎えます。 この頃のツラみ JSON を組み立てるのが大変
Mountable Engine だらけの Rails アプリ開発 - onk.ninja
Mountable Engine だらけの Rails アプリ開発 はじめに これはドリコムアドベントカレンダーの 2 日目です。 1 日目は id:sue445 さんによる ドリコムを支える中間ポイントシステム - くりにっき です。 お前誰よ id @onk ドリコム歴 2006/12/01 中途入社 9年目に突入しました 仕事 アプリケーションエンジニア 2009/04 から Rails アプリを触るように 主にサーバサイドを担当しています 今日の話 「普通に Rails アプリを作ると Mountable Engine を少なくとも 5 個は使う時代になったよね」って話をします。 目次 Mountable Engine とは Mountable Engine の作り方 Mountable Engine のテストの書き方 Mountable Engine の設定を書きたい 管理画面付
The NEXT of REST - onk.ninja
The NEXT of REST 前後リンク RESTful API のおさらい Rails での JSON API 実装まとめ スキーマファースト開発 The NEXT of REST REST で解決していない問題 REST っていうのは本当に難しくて、 開発者のお気持ちで API が異なる 指針であって仕様じゃないのが理由 POST がワイルドカードとして使われるとか クライアントとサーバ間のまだある精神的な溝 API はサーバが作るもので、クライアントは手出ししづらいという意識 REST だとクライアントごとに最適化した API を作りづらい Web とスマホで同じ API を使うときに不要なレスポンスがある 提供されている API が不十分なときにクライアント側で JOIN するハメに のような問題を抱えています。 これかを解決するために、API Query Language (
スキーマファースト開発のススメ - onk.ninja
第 2 部 で 現在 5 派閥ぐらいありそうです。 と書いた中でなぜ OpenAPI を選んだのかというと、 JSON Hyper-Schema は Hypermedia の技術なので、1 サーバ 1 クライアント、同一チームで両方を見るという private API では出番が無い。 RAML はコミュニティ規模が OpenAPI, API Blueprint に比べて小さかった OpenAPI と API Blueprint、生 JSON Schema だと、OpenAPI が一番「RESTful API」に特化していて、かつ詳細度が高い といった辺りです。 OpenAPI は ruby だとライブラリが (当時は) 少なかったのですが、まぁ作れば何とかなるだろうと採用しました。 最近のトレンドでも Swagger 1 強になってるっぽくて、良い選択をしたなぁと思っています。 Open
RESTful API のおさらい - onk.ninja
RESTful API のおさらい 前後リンク RESTful API のおさらい Rails での JSON API 実装まとめ スキーマファースト開発 The NEXT of REST REST の歴史 REST (REpresentational State Transfer) という言葉は 2000 年に Roy Fielding の博士論文で初出しました。 (思想としてはその前からあった？ REST 入門) 日本では 2005 年ぐらいから徐々に流行りだして、 2006 年に WEB+DB Press で特集や連載が組まれる等が行われ、 (Rails 2.x が RESTful を打ち出した) 2007 年の終わりには web 開発者の間では一般化した言葉になっていたって印象。 なぜ REST が必要になったのか はるか昔はメインフレーム上で全部入りのアプリケーションを開発してい
rubocop のしつけ方 - onk.ninja
rubocop のしつけ方 TL;DR rubocop --auto-gen-config して Offense count の多い順に毎日数個ずつ設定を確認したら 僕の使っている .rubocop.yml ができました これが onkcop か…(ゴクリ / “僕の使っている .rubocop.yml” https://t.co/KVryle9SJq — そのっつ (SEO Naotoshi) (@sonots) October 26, 2015 rubocop とは コーディング規約に準拠しているかをチェックする gem です。 https://github.com/bbatsov/rubocop こんなコードに対してかけると def badName if something test end end 以下のような警告をしてくれます。 Offenses: test.rb:1:5: C:
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
