Kong を使った Microservices Architecture API Gateway Pattern の実現方法 - Qiita
Kong を使った Microservices Architecture API Gateway Pattern の実現方法Dockermicroservices この記事は、Kong - API Gateway Pattern速習会＠Wantedlyの資料として作られたものです。 サービスが大きくなるとやりたくなってくること より高速な実装に置き換えたい APIを複数のサービスに分けて開発したい マイクロサービス化 何故マイクロサービスか James Lewis/Martin Fowlerの"Microservices"日本語訳 State of the Art in Microservices by Adrian Cockcroft - Qiita いろいろ理由は言われてるけど... 人が扱える大きさの限界 「明確な」境界が必要 名前空間やスコープなど、プログラミング言語でも使用してい
12 Factor App - モダンなサービス運営に必要な12のインフラ的要素 - Qiita
皆さんは、The Tweleve-Factor Appをご存知だろうか？ これはHerokuの中の人が書いた、Webアプリケーションを使いやすい形でスケーラブルにするための方法論である。簡単にいえばコンテナで動かしたいアプリケーションが守っておくとよいレシピ集であると言える。 http://12factor.net/ (日本語訳) 今回これを取り上げた背景としては、実はDockerコンテナをメインにした本番でのインフラ運用を考えた時に、アプリケーションがこの12の要素を満たしていることが重要だと最近ひしひし感じているから。 実際、自分が働いているところが運営しているサービス Wantedlyは、もともとずっとHerokuで運営していて、最近AWSに移行し、現在Dockerコンテナの上で動いている。この移行を約1ヶ月半で実現できた大きな要因として、Herokuの上に乗っていたことで知らず知ら
RailsでいろんなSNSとOAuth連携/ログインする方法 - Qiita
Deviseというgemのomniauthableを利用して、いろんなOAuth提供元サービスと連携orそのサービスを用いたログインを実現する方法。 こういうことやりたい人結構いるんじゃないかと思って、Wantedlyで実際にやってみた経験を大公開！！ Gemのインストール deviseと各providerのomniauth関連Gemをインストール gem 'devise' gem 'omniauth' gem 'omniauth-facebook' gem 'omniauth-github' gem 'omniauth-google-oauth2' gem 'omniauth-hatena' gem 'omniauth-linkedin' gem 'omniauth-mixi' gem 'omniauth-twitter' とりあえず、omniauth-'provider'でググって出て
Application Layoutを整理する3つの方法 - Qiita
サービスを運営していると、 Admin以下のページだけちょっとヘッダーを変えたい ABテストのために2種類のレイアウトを試してみたい キャンペーン用にある期間だけ別のロゴを使いたい ユーザー登録ページだけ簡易レイアウトにしたい などなどの理由で、app/views/layouts/application.html.erbと大体同じだけど、ちょっと違うというレイアウトが欲しくなります。ただ、コピペでいろんなレイアウトを作ってしまうと後の変更が困難になります。Layoutでもデフォルト値や継承を使って再利用性の高いものを作りましょう。 方法1 Default content_for あるyieldに対応するcontent_forがセットされなかった時のデフォルト値を定める方法です。 yieldは普通の文字列を返す関数で、値がセットされていなければ""が返ります。なのでempty?を使って値がセ
Rubyはじめての人がRails開発に参加するときに最初に知っておくべきこと - Qiita
※この内容はRailsで書かれたWantedlyのプロジェクトに参加することを想定していて、一部Railsのデフォルトでない機能の解説もありますが、使っているgemもメジャーなもので割と汎用的な内容になっていると思うので、是非参考にしてみてください。 URLを見ればだいたいどこを変更すればいいかわかると言うこと Ruby on RailsはMVC(Model View Controller)にもとづいて設計されていて、ディレクトリ構造的にもapp/以下に綺麗に分かれている。 MVCって何？って人は、ググってみてほしいが、割と宗教論争になりかけているので、モデルはDBの各テーブルに関連していて、ビューはHTMLの部分に近くて、コントローラーはビュー用にモデルを引っ張ってくるつなぎ役だと思ってれば大体合っている。これ以上は深く考えずにコードを読んだほうが良いと思う。 Router でもコード的
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ページを開く
