先日、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

今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照／更新クエリを実行しています デ

ども、大瀧です。 EC2からEメールを送るという案件、たくさんありますよね。そして結構な確率でトラブるんですよね(涙目)。そんな苦い経験をベストプラクティスとしてまとめてみました。一応技術的なところは網羅したつもりですが、メールセキュリティの専門ではないので、不備や間違いがあればご指摘ください。 では、メール送信トラブルの元凶である、スパムメールとその対策からご紹介していきます。 スパムメールとの闘いダイジェスト Eメールの歴史は、スパムメールとの闘いの歴史と言えます。 不特定多数に送信されるスパムメール(未承諾の広告メール)は、メール受信者に不快な思いをさせるとともに、メールサーバーのメール流量を爆発的に増加させ、長らくメールサーバー管理者を泣かせてきました。 このスパムメールをなんとか撃退しようと、現在では主に以下のような対策が行われています。 1. 送信メールサーバー側のネットワーク

スケーリング＝時速160㎞で走行しながら自動車の全ての部品を取り替えること －Mike Krieger　 Instagramの共同設立者＠ Airbnb OpenAir 2015 Airbnbのピーク時のアクセス数は、毎年夏のピーク時で見ると年率3.5倍で増加しています。 2015年夏の旅行シーズンを前に、Airbnbの基盤チームは、夏季のアクセスで予想されるデータ通信量に対処するため、データベースのスケーリングで忙殺されていました。中でも特に全体への影響が大きかったプロジェクトが、特定のテーブルを、アプリケーションの機能に従ってそれぞれのデータベースに分割することを目的としたプロジェクトでした。これは通常、アプリケーション層のフォームの変更やデータ移行、データの整合性を保証する堅牢性テストなど、最小限のダウンタイムで多大な技術的投資を必要とするものです。何週間もかかるエンジニアリング時間

CloudSQLの価格は実戦的という意味で、per Dayの価格を24hourで割った価格にしています。 メモリは2GBあれば検証としては十分なので格差は関係ありません。 IOPSはEBSならGeneral Purposeの1000GB*3で最大確保しています。 その他、ネットワーク周りなどポイントがあれば都度、補足していきます。 ベンチマークのデータ 今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。まぁ、こんなオレオレメモデータを見ても楽しくないでしょうから、１つ１つ考察していきましょう。 手法について 私がよくやる計測方法なのですが、innodb_buffer_pool_size がデータ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照／更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出し

はじめに 実際に運用していた時に非同期にしていた主な処理は下記のようなものがあります。 iOS Android の push 通知の送信処理 ログの作成 様々な外部 API の呼び出し 非同期で更新しても問題ないデータの更新 Sidekiq is なに sidekiqは非同期処理を実現する gem 他にも Ruby で非同期処理を実現できる有名な gem には resque や delayed_job 等がある。 sidekiq.org Enterprise版等もありますが、 今回はOSS版を使用している前提でのお話しです。 他の非同期処理が可能な gem との簡単な比較 FAQ · mperham/sidekiq Wiki · GitHub この内容は結構真実を語っていることを最近知った Sidekiq Redis マルチスレッド リトライ処理あり おしゃれなダッシュボード Resque

前回の記事で書いたとおりRailsの環境を更新しました。 が、本番環境おけるアセットパイプラインでハマってしまいました。 ここで復習しておきます。 そもそもアセットパイプラインとは？ 「app/assets」「lib/assets」「vendor/assets」など異なるパス上のjsやcssを同一のurl（例えばhttp://myapp:3000/assets/xxxx）で参照を可能にする仕組みです。（jsやcssの結合だったり圧縮だったり他にも色々仕事してます。） アセットパイプラインの対象となるパスは「Rails.application.assets.paths」で参照できます。 #/myappが$RAILS_ROOT $ script/rails console irb(main):001:0> puts Rails.application.assets.paths /myapp/a

こんにちは。ホリデー株式会社の内藤です。 ホリデー株式会社では Holiday（https://haveagood.holiday） という新規サービスの開発・運営を行っています。*1 以前投稿した記事でご紹介したように、Holiday では全文検索エンジンとして Elasticsearch を利用しています。 Ruby on Rails で構築されたアプリケーションから Elasticsearch を操作するには、公式 gem である elasticsearch-rails を使うのがとても便利です。 もちろん、Holiday でも活用させてもらっています。 大方の機能についてはこの gem で提供されるもので満足だったのですが、一点だけ、Holiday の運用をしている中で困ることがありました。 それが、サービス公開後のインデックスの再構築です。 elasticsearch-rails

DeNA社内でのElasticsearch勉強会にて、アプリ「ハッカドール」におけるElasitcsearch利用法について発表してきました。 スライドはこちら。 Elasticsearch for Hackadoll from mosa siru Elasitcsearchの中身や運用について濃く触れるというよりは、ちゃんとした検索エンジン作るための泥臭い話がメインになっています。 （ある意味で昨年Tokyo WebMiningにて発表した捗るリコメンドシステムの裏事情（ハッカドール）の派生スライドです。） ハッカドールは1周年を迎え、来月にはアニメ化もされます。ニュースアプリがアニメ化とか開発者としてもどうなるか予想がつきませんが、放映時には全裸待機しようと思います！ hackadoll-anime.com

モデル業界の仕事の進め方は効率が悪過ぎる————。 ピーター・フィッツパトリックはモデル事務所のSilent Models NYを設立した5年前、業界の慣習に衝撃を受けた。「モデルのスカウトや売り込みから、クライアントの間のやり取りに至るまで、あらゆる段階において無駄な作業が多い」と彼は言う。 そこで彼は無駄を省くためにアプリをローンチした。Swipecastはモデルとフォトグラファー、デザイナー、スタイリスト、小売店などをマッチングするモバイルアプリだ。 仕組みは単純だ。クライアントは画面上のルックブック（モデルのファッション写真を並べたカタログ）をスワイプし、撮影に使いたいモデルを見つけたら、直接本人にメッセージを送って仕事を依頼。報酬はアプリ経由で支払い、モデルは仕事終了と同時にそれを受け取る。 女性モデル業界は市場規模40億ドル（約4兆9570億円）といわれるが、近い将来には男性モ

今晩19:30からプロダクトマネジャー決起集会やるので、プロダクトマネジャーの方は渋谷にお越しください。— あんちぽくん (@kentaro) August 19, 2015 8月19日(水)、これに参加するために渋谷まで行ってきました。ツイート主が偶然にも同じ会社の人だったのでついて行きました。 先日のエントリ「Inspired: 顧客の心を捉える製品の創り方」を読んだにも書いたように、プロダクト・マネージャーという役割、あるいは、チームメンバーが備えるべきプロダクト・オーナーシップという素養に興味があって、この会にも参加しました。参加者は、弊社 CTO の id:antipop さんと、弊社の「プロダクトオーナーシップ勉強会」の参加者4名と、Fablic から id:ninjinkun さんの計6名でワイワイと。 たまたま同時期に同じ書籍を読んでいたという id:ninjinkun さ

こんにちは、夏の暑さに負け気味の htomine です。 半袖で過ごせるのはいいけど外に出たくなくなりそうです！ さて、今回は最近リニューアルもされたフリマアプリ「Fril」を運営する株式会社Fablicの皆様にお話を聞いてきました。 チームの文化に合わせて、Qiita Teamの使い方が徐々に変わっていくところに注目です。 株式会社Fablicさまインタビュー他部署との結びつきが弱い、情報共有のモチベーションが低い、アウトプットしても見てくれる人が少ない……など、社内でのコミュニケーションや情報伝達に問題意識を持つ企業は少なくないのでは。組織が大きくなればなるほど、その状況を変えるのは大変かもしれません。 現在70人のメンバーを抱え、フリマアプリ「Fril」（フリル）の企画・開発・運営を行うFablicでは、Qiita Teamを導入したことで、社内コミュニケーションを円滑にし、より強い

テレビや新聞、雑誌などでも紹介され、女性を中心に人気を伸ばしているフリマアプリ「FRIL(フリル)」(以下、フリル)。簡単に使える日本最大級のファッションフリマアプリということで、ダウンロード数はなんと360万を突破！今、大注目のアプリです。クックパッド編集部では、そんな「フリル」の人気の秘密に迫るべく、ユーザー暦約２年の主婦・木村友美さんに実際にどのようにアプリを活用しているのか詳しくお話を伺いました！

パスワードを忘れた方はパスワードの再設定を行ってください。 初めての方ははてなID登録 (無料) してください。 うまくログインできない方はお問い合わせをご覧いただき、Cookieの設定をご確認ください。

ホリデー事業室の内藤です。 ホリデー事業室は昨年の4月に発足した部署で、Holiday（https://haveagood.holiday）という新規サービスの開発を行っています。 Holiday とは、クックパッドが長年取り組んでいる「毎日の料理を楽しみにする」分野からは少しだけ離れ、「いつもの休日を楽しくすることで人生を豊かにする」ことを目指したサービスです。 例えばこちらのおでかけプランのように、「〇〇に行くならここも行ったほうがいいよ」や「〇〇を散策するならこのコースだよね」など、おでかけのレシピを投稿したり探すことができるようになっています。 今回は、全文検索エンジン Elasticsearch を使って、全文検索と位置情報を絡めた検索についてお話したいと思います。 本稿で説明する内容は、実際に Holiday の中でも応用を加えた形で使われています。 Holiday では、複数

スタートアップの創業時におけるエンジニアの役割とはなんでしょうか？ 昨今様々なスタートアップが立ち上がっていますが、実際にプロダクトを作り始める段階で様々な葛藤があるかと思います。 スタートアップのフェーズによってエンジニアの役割や、目的なども刻々と変わっていくでしょう。 今回はフリマアプリの「フリル」というサービスの立ち上げをベースに、 スタートアップの創業期におけるエンジニアリングについて赤裸々に語りたいと思います。 創業期におけるエンジニアの役割 創業期における技術の選定 技術的負債との付き合い方 開発チームの拡大によるエンジニアの役割の変化

パスワードを忘れた方はパスワードの再設定を行ってください。 初めての方ははてなID登録 (無料) してください。 うまくログインできない方はお問い合わせをご覧いただき、Cookieの設定をご確認ください。