Rails Active Record における rewhere の使い所 - ボクココ
ども、@kimihom です。 今回は ActiveRecord でもおそらくマイナーなメソッドであろう rewhere を使う機会があったのでメモとして残しておく。 今回の利用ケース とあるデータの取得条件でフィルタリングをして統計として表示するページを想像してみて欲しい。そこではあらゆる where 条件で絞り込みを指定している。そしてもちろん取得する件数や並びの順番なども指定している。 # 今日更新された特定の会社に所属するコンタクトを作成日時の新しい順で30件 @records = Contact.where( "updated_at between ? and ?", DateTime.now.beginning_of_day, DateTime.now.end_of_day ) @records = @records.where(company_id: company.id)
私が実施する Heroku x Rails の高速化をまとめてみた - ボクココ
Herokuの欠点は、Tokyoリージョンがないため、ネットワークによる遅延が気になる と言われている。どの程度による遅延が気になっているのかは人によると思うが、Herokuを最大限に高速化させるために私がやっていることをまとめてみた。 これを実施すれば、Herokuが遅いとはあまり思わなくなると考えている。 Asset Sync を利用する [追記（重要）] Asset Syncを利用するのは公式で止めるよう勧告が出ている。CloudFrontを利用する方法が推奨されている。以下の内容は古いのでご注意を。 ーーーーーーーーーーーー Asset Syncは、Amazon S3に画像やCSS/JavaScriptを置き、各アセットのパスの向き先をそちらにかえてくれるgemだ。これを利用しないと、HTMLとかに置いた静的コンテンツが全てHerokuにアクセスしてしまうため、Herokuサーバー
iOS8 で画像をアルバム or カメラで取得し、S3 へアップロードする - ボクココ
だいぶお決まりな処理な気がするのでまとめてみる。 iOS8 からは Photos Framework という画像を扱うフレームワークがあり、これを利用していく。 UIImagePickerController を使えば、画像選択まではそれなりにうまくいくのだが、 S3 へアップロードとなるとそのファイルパスが必要になってきて、そのファイルパスをどうやってとってくればいいのかが難しいところ。 画像は特に、自前のサーバへアップロードするんじゃなくて、S3に直接アップロードしたほうが負荷的にも優しいし、マルチパートのPOSTを実装する必要もなくなるので、基本的には採用すべきだと思う。そのURLだけを自前サーバにポストすればいいだけにしよう。 画像をリサイズして色々なサイズの画像をS3に保存したいというようなケースも多くあると思う。その時は自前サーバのAPIで、アプリから渡したS3のURLにある画
良いアプリを作るには、技術とかより知ってるかが重要 - ボクココ
良いアプリを作るにはどうしたらいいか？ たくさん作って自分の技術力を上げる！という言葉が出てくるかもしれない。それは半分正解で半分不正解だ。こういう人は何でも自分で作ってしまい、他の公開されているかもしれないコードを流用することができないパターンが多い。 もちろんそれを否定するつもりは全くなくて、そうした経験の末、自分にしか作れないUI. UXを実現することができるようになるだろう。彼らこそが真のエンジニアとして世の中のソフトをよりよくしてくれる。 自分は技術はツールでしかなく、それを使って何を皆に提供するかということに主眼を置いている立場である。別に自分の力で実装する必要は無いことに気づく。Libraries 系のアプリを使って眺めると、特にそれを感じてしまう。 実はあまり教えたくはないアプリ 以下の２つは心からオススメする分、あまり大きな声でオススメはしたくないという想いもある。なぜな
DB の state は State Machine で管理する - ボクココ
最近は毎日プログラミングの日々を過ごしている。 そんな中、とあるテーブル(ドキュメント)で状態を管理しなきゃいけない場面があった。 この問題の一つの手としてはstate をint で保存し、一つ一つの数字を何かしらの状態に紐づけるやり方だ。これを実践してみたことがある方ならわかる通り、後でこれをメンテする人がいったいその数字が何なのか、をいちいちどっかのドキュメントを見て調べなければならない。これの管理がとても面倒。何かの状態が新しくできたらそのドキュメントもちゃんと更新しないと、色々崩壊する。 State Machine State Machine はそれぞれの状態と、状態の遷移を管理する一種のデザインパターン。これにより、数値での管理をなくし、さらにある状態からある状態への遷移を限定することができる。例えば、状態として「走る」「歩く」「止まる」「寝る」があるとしよう。いきなり「走る」か
ユーザ登録・API 認証の仕組みを Rails で実現する - ボクココ
スマホアプリから会員の新規登録、ログインが両方できるようにAPIを作成中。ようやく自前でアクセストークンを作ってOAuth認証が出来たのでまとめておく。 まず何がしたいか？ スマホアプリでAPI認証ができるように、OAuthを自前で作成したい。 -> スマホアプリ側ではユーザ名とパスワードを入力すればトークンが取って来れて、そのトークンで各APIにアクセスすればユーザ固有の情報が取って来れるようになる仕組みを作る。 スマホアプリ側でユーザ作成も出来るようにしたい。 -> APIでユーザが作れるようにする。もちろんhttps前提。 環境 gemfile ruby '2.0.0' gem 'rails', '4.0.0' gem 'rails-api' gem 'active_model_serializers' gem 'mongoid', '4.0.0.alpha1' gem "moped
Rails の認証で Devise ではなく Sorcery という選択 - ボクココ
現在 AngularJS と Ruby on Rails 間の認証の仕組みを実装しようとしている。 この際問題になるのは、デフォルトのRails認証の仕組みは、HTMLベースであるため AngularJS で必要とされる JSON でのレスポンスが受け取れない、という点がある。 もちろん、Devise による認証でも Devise::Controller 系を継承することで独自のコントローラをカスタマイズすることが可能だ。だが、これは Devise 側のソースコードを理解し、適切なコードとレスポンスを Devise の慣習にそって実装する必要がある。これがなかなか大変。 そこで登場するのが Sorcery . これは簡単にいえばシンプルな認証の仕組みだけを提供してくれるものだ。 個人的に最も大きな違いといえば、Devise は devise_for :user や devise_for :
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
