redirect_toのレスポンスコードをデフォルトで302 Foundではなく301 Moved Permanentlyにする - Qiita
redirect_toのレスポンスコードをデフォルトで302 Foundではなく301 Moved PermanentlyにするRubyRails 302じゃなくて301を使う理由は、301リダイレクトと302リダイレクトの違い参照。 重要なところを抜き出すと、 301リダイレクトは、”Permanent Redirect”で「恒久的な転送」、一方、302リダイレクトは、”Temporary Redirect”で「一時的な転送」を表します。 検索エンジンのインデックスに関して： 302リダイレクト：旧URLのまま 301リダイレクト：新URLへ というようになっている。 ちなみにRailsでは、デフォルトで302が返るようになっている。 これを変えるには、
ElasticSearchとKibana - Qiita
ElasticSearchとは Elasticsearchは、割と設定とかが簡単で使いやすい全文検索エンジンで、内部でJava実装のLuceneを利用している。 http://www.elasticsearch.org/overview/elasticsearch Kibana連携の際は、単に検索というより、可視化したいデータを高速にフィルタリングして集計する用途で使われていると思ったほうが良い感じ。 ElasticSearchのインストール Kibanaとは ElasticSearch社が提供している、ログデータの可視化ツール。Apatchなどのシステムログを用いる例ばっかりWeb上で見つかるが、別に検索のクエリログやWebサイトの行動ログだってちゃんと入れて設定すれば使える。 Kibanaのインストール ElasticSearchのプラグインとしてインストール (現在はkibana3と
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
Rubyで学ぶデザインパターン - Iterator - Qiita
Wantedlyエンジニア新人研修（設計）の1回目 チェックポイント ArrayはIteratorを使っているか？ HashはIteratorを使っているか？ 自分でIteratable(Enumerable)なクラスは書けるか？ Rubyでインターフェースは存在しないがどう置き換えられているか？ 1. どういう時に使うか 集合の要素を全走査したいとき。 Rubyで言えば XXX.each でループを回せる部分。 2. メリット (+デメリット) メリット 個々の要素とその集合という概念を扱えるようになる。 デメリット 特になし。 3. このパターンを使わないとどうなるか 配列やDB的なidがあるものに関してはfor (int i = 0; i < x.size(); i++)というような決まり文句で代替が効く。 文字列をKeyにした集合だと、そのkeyの配列などがない限り個々の要素にアク
RSpecのshouldはもう古い！新しい記法expectを使おう！
というように書くようになりました。 別にshouldを使った記法がなくなったわけではありませんが、 https://github.com/rspec/rspec-expectations のREADME.mdには、もう新しいSyntaxの説明しか載っていないし、今後はexpectの方を使っていくほうがいいでしょう。 http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax には、新しいSyntaxを導入した背景が説明されています。 簡潔に書くと、shouldだとBasicObjectを継承したクラスのテストを書くときに不具合が起こるみたいですね。 移行方法 基本 基本的には、上に書いたように、 foo.should を expect(foo).to に foo.should_not を expect(foo).
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitでMerge CommitをRevertする方法 - Qiita
