中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
x-runtime は消すべきなのか - Qiita
Rails などの WAF の中にはサーバでの処理時間を x-runtime ヘッダとしてクライアントに返すものがありますが、セキュリティ上の観点から x-runtime ヘッダを消すことを奨励していることも多いです。それはなぜでしょうか。 Nginxでレスポンスヘッダの一部を隠蔽する方法 - Qiita Nginxセキュリティ設定 - Qiita Timing Attack なぜ x-runtime を消すのか。逆にいえば x-runtime を残すとどういうセキュリティ上のリスクがあるのか。 参照した記事に説明がないので推測でしかありませんが、 x-runtime を使って Timing Attack が可能になることを根拠にしているように思います。 Timing Attack とはサイドチャネル攻撃の一種で、 x-runtime の値をヒントにしてサーバ内のセキュアな情報を盗むことが
RSpecを並列実行するgemを作っている話 - Qiita
これは Ruby アドベントカレンダー 24 日目の記事です。 Railsを長く開発していると機能を追加していくにつれてテストコードも肥大化し、初めのうちは一瞬で終わっていたrspecも気がつけば数十分かかるようになっていたということも多いと思います。テストをCIで回していると、結果が得られるまで作業が止まることになるので、テスト時間の肥大化は結構大きなインパクトを持ってきます。 テストの中にボトルネックがある場合それを解消することである程度の高速化ができますが、純粋にテストの数が多いということになると、全てのテストを実行するのを諦めないのであれば、テストを並列に実行するのが高速化のアプローチとなります。 テストを並列実行するgem テストを並列に実行するgemはすでに世の中にいくつもあります。 rrrspec Cookpad社が作っているrrrspecはRSpecを複数サーバで分散実行し
複数プロセス間での排他制御 - Qiita
require 'timeout' class AccessDenied < StandardError; end def lock(&block) # 10秒以内に終わらない場合はAccessDenied例外が発生 Timeout::timeout(10) do open(File.join(Dir.tmpdir, 'my-application.lock'), 'w') do |f| begin f.flock(File::LOCK_EX) block.call ensure f.flock(File::LOCK_UN) end end end rescue Exception => ex raise AccessDenied.new('timeout') end Register as a new user and use Qiita more conveniently You ge
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
zshでログイン・ログアウト時に実行されるファイル - Qiita
今まではバカの一つ覚えのように何でもかんでも$HOME/.zshrcに書いていたけど、サーバ管理をよくするようになってきて、複数アカウントの共通設定とかをしたくなったので調べた。 順番 以下の$ZDOTDIRは指定されていない場合$HOMEになる。 ログイン時 /etc/zshenv $ZDOTDIR/.zshenv /etc/zprofile $ZDOTDIR/.zprofile $ZDOTDIR/.zshrc /etc/zlogin $ZDOTDIR/.zlogin ログアウト時 $ZDOTDIR/.zlogout /etc/zlogout 言うまでもなく、個人的な設定は$ZDOTDIRに、汎用的な設定は/etcに書く。 各種説明 zshenv 必ず実行される。/etc/zshenvは上書き不可で$PATHや$MANPATHの設定がされる。 $ZDOTDIR/.zshenvにはいかなる
検索・置換を便利にするvim-abolish - Qiita
これは Vim Advent Calendar 2014 11日目 の記事です。 日頃Railsを書いている。その際vim-abolishが便利なんだけど、日本語記事で紹介されている場面をあまり見ないので紹介したい。 インストール インストールはいつものとおりVundleやNeoBundleで。 3つ機能 ところでvim-abolishは大きく分けてAbbreviation、Substitution、Coercionの3つに分類されるが、Abbreviationは使っていないので、SubstitutionとCoercionだけを取り上げる。 Substitution Vimで :substitute と言えば置換処理に使うコマンドだが、Substitutionはこの置換処理に加えて検索を便利にしてくれる機能だ。 賢い検索 個人的にvim-abolishいれてから普通の検索はあまり使わなくな
PaperTrailはどうやってActiveRecordのバージョン管理をしているか - Qiita
この記事はRails Advent Calendar 2014の21日目の記事です。 Qiitaでは投稿の履歴管理にpaper_trailというgemを使っています。本稿ではPaperTrailがどんな感じでイベント情報をDBに保存しているかを紹介しつつ、PaperTrailが作り出すversionオブジェクトの渡り歩き方を簡単に解説したいと思います。 PaperTrailを使ってみよう 前提 PaperTrailで管理している Item modelがあり、そのインスタンスを2回編集してから削除したとします。 コードで表現するならこんな感じです。 class Item < ActiveRecord::Base has_paper_trail end item = Item.create(body: 'foo') item.update_attributes(body: 'bar') ite
アプリエンジニア向け：「サーバがなんか重い」時にすること - Qiita
アプリケーションエンジニアの人には「なんか重い」という状況に遭遇したらインフラの人にタスクを投げる、という人もいるかも知れません。けど、その重さのどこに原因があるのか。CPUか、ネットワークか、IOかくらいの診断はできた方がアプリ開発においても有益です。 「せっかくつくったシステムがなんか重い」 そんな時にアプリケーションエンジニアとしてできることを書きます。 本職のインフラの人にはぬるい内容だと思います。何を隠そう僕自身がアプリ寄りの人間なので、突っ込んだ話はできないのです。あしからずご了承ください。 なんかサーバが重いなー まずはロードアベレージを調べる サーバが重いと思ったら、まず真っ先にすべきことは対象ホストにSSH接続してロードアベレージを調べることでしょう。ロードアベレージとは 実行されずに待たされているプロセスの数 のことで、多すぎるとやばいと認識しておきましょう。ロードアベ
結局jQuery.Deferredの何が嬉しいのか分からない、という人向けの小話 - Qiita
結局jQuery.Deferredの何が嬉しいのか分からない、という人向けの小話 一年ほど前に JavaScript - jQuery.Deferredを使って楽しい非同期生活を送る方法 - Qiita [キータ] という記事を書きました。 で、一年経って、ふと、「もっと分かりやすくjQuery.Deferredの便利さを説明できるんじゃないか」と思い立ってざざざっと書いてみました。 小話と言うにはちょっと長いけど。 -- jQuery.Deferredを使うと嬉しいのは、jQuery.Deferredの仕様を満たす部品同士を簡単に組み合わせることが可能だからです。中には処理を書き下すことができるとかコールバックのネストを防げるのがいいとか言う人もいますが、個人的にこっちのほうがよっぽど重要だと感じます。 例えるならレゴブロックです。レゴブロックはあの凸と凹を持ってるブロックを自由に組み合
Qiitaの画像アップロード機能も簡単に実装できる。そう、S3ならね。 - Qiita
QiitaとKobitoで画像アップロードができるようになりました。 その後ろ側をちょっぴり公開します。 件名からも分かるように、背後ではAWSのS3を画像ストレージに採用しています。 画像アップロード機能をリリースしました - The Official Qiita Blog Kobito v1.6.1リリース: ドラッグ&ドロップやスクリーンショット撮影で簡単に画像を添付できるようになりました! - The Official Qiita Blog 用語統一 サーバ はQiitaのサーバのことを指すことにします。（つまり、S3ではない、ということ） また クライアント は各ユーザのブラウザのことを指します。 要件 画像アップロード機能を実装するにあたっていくつかの要求がありました。 成りすましを防げる アップロードされたファイルを管理できる 自分達のサーバに負荷をかけたくない 変な画像のア
Capistrano3のデプロイフレームワークの使い方 - Qiita
Capistranoはバージョン3から汎用的なデプロイフレームワークになりました。タスクのフックを利用することで簡単に自分のアプリケーション環境に特化したデプロイプロセスを記述することができます。 本稿では、この汎用化されたデプロイ機能の使い方に焦点を絞って解説したいと思います。より基本的なCapistrano3の解説は 入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineers' Blog がよくまとまっているので、そちらを参考にしてください。この参考記事では "5. Capistranoデフォルトタスクの消去" でCapistranoの新規導入時のコストを下げる目的で、このフレームワーク機能を消去しています。本稿はこのフレームワーク機能の使い方を解説するものです。 deployとframeworkの2つの抽象度が用意されている Capi
vimgrepとQuickfix知らないVimmerはちょっとこっち来い - Qiita
「vim入門」系記事で解説されないためか、意外と使い方が知られていないvimgrep。 ファイルを開いては検索、開いては検索ってしてる？ grepするためにvimから出てる？ grep結果を見て改めてvimで開き直してる？ それ、vimgrep使えば256倍早くなる（かも）よ。 簡単なまとめ vimgrepは… ファイルをまたいで検索できる grepやgit-grepよりは遅いので巨大プロジェクトでは検索対象を絞ったほうがいい ワイルドカード使うと簡単に絞り込める 繰り返し同じ対象から検索する場合はargument listを使うと捗る gitリポジトリではgit-ls-filesと組み合わせる 該当箇所に素早く移動＆編集できる quickfix-windowと組み合わせると更に捗る この記事読むと分かること :vimgrepコマンドの使い方 :cwindowコマンドの使い方 :argsコ
Rubocopをsyntasticを使ってVimから自動実行する - Qiita
NeoBundle 'scrooloose/syntastic' let g:syntastic_mode_map = { 'mode': 'passive', \ 'active_filetypes': ['ruby'] } let g:syntastic_ruby_checkers = ['rubocop'] syntastic_mode_map は 'active' もしくは 'passive' を指定します。 'active' だとバッファを保存するたびにsyntasticが走り、 'passive' の場合は :SyntasticCheck 実行時に走ります。 'active_filetypes' は保存の度にsyntasticを走らせるファイルタイプを指定します。 ２つをあわせると、基本的にsyntasticは走らせないけど、rubyのときだけは自動的に走らせる、という設定にな
gem installでGitHubリポジトリにある最新版をインストールする - Qiita
って書いて bundle update spring を実行してね。 参考: https://github.com/jonleighton/spring/issues/143#issuecomment-17984728 みたいなことがある。だいたいの場合はこれでいいんだけど、ここで引用しているspringの場合、これで直るのは bundle exec spring だけで、 bundle exec 無しだと実行できない。（僕の勘違いかも知れないので、正しいやり方を知っている人は是非コメントで教えてください。） 我慢して古いバージョンをRubygemsから引っ張ってきてインストールしてもいいんだけど、やっぱりbundlerでインストールしてあるのと同じバージョンにしたい。 で、gemコマンドにはgitリポジトリを指定して直接インストールする機能が無いので、こういう場面ではspecific_i
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
