3TB超のCacooのPostgreSQL 9.3を9.5にアップグレードした話 | 株式会社ヌーラボ(Nulab inc.)
こんにちは。Cacooチームのイニエスタこと、とおのぶです。CacooはデータベースのPostgreSQLのバージョンアップを実施しました。基本的には公式のpg_upgradeの手順に従っています。ここではドキュメントには記載の少ない具体的な作業内容の流れを紹介したいと思います。 理由 ユーザアンケートからみる Cacoo のコア・バリューで記されたとおり、全体的なパフォーマンスの向上については重要度の高い課題の一つです。PostgreSQL 9.5ではソート性能の大幅な改善が強化点の一つで、パフォーマンスの改善が見込まれます。またフェイルオーバ後、新しいマスターに追従するスタンバイとして、古いマスターサーバをオンラインに戻すことができるpg_rewindも、PostgreSQL 9.5の魅力の一つです。 バージョンアップ前の構成 構成は、マスタとスレーブのストリーミング・レプリケーション
Talks & Presentations
Below is a list of talks and presentations that I have done over the years. If you have any questions/feedback about the content or are interested in having me present at your event, please don’t hesitate to reach out! 2017Orange County Gophers Meetup · Slides Types All The Way Down QCon NY 2017 · Slides · Video Generating Unified APIs with Protobuf & GRPC 2016Slides Vendoring & Versioning with Go
MERY EC におけるセッション管理と JWT - peroli Developer's Blog
2016 - 08 - 26 MERY EC におけるセッション管理と JWT Back-End 設計 Ruby list Tweet こんにちは。 MERY のサーバーサイドエンジニアの @saidie です。 MERY では、女の子が知りたい最新の情報や欲しくなるファッションアイテムを、記事という形式を通して毎日届けています。 そして、ここ一年弱の間、ユーザが欲しいと思ったアイテムをそのまま手軽に MERY 上で買うことのできる、EC の システム開発 を進めてきました。 この記事では、MERY の EC システムを開発するにあたって、既存の MERY 会員のログインセッションと EC において必要とされる新たなセッションに関する設計の裏側と、セッション情報のやり取りに JWT ( JSON Web Token) を使う取り組みについてご紹介したいと思います。 MERY の EC セッ
魅力的なイラストを活用したアプリのUIデザイン７選
Appleは完璧を追い求めることで有名であり、それは 私たちがUpLabsで称賛しているところでもあります。 Appleはとりわけインターフェイスに関しては常に境界線を押しひろげ、 他社にとっては高いハードルを作りあげてきました。彼らはスキューモーフィズムを世の中に広めた企業であり、彼らの方針にコミュニティ全体を従わせたのです。 フラットスタイルの時代となった今もなお、彼らはなんとか自分たちに忠実であり続けようとし、崇高なピクセルパーフェクトなデザインを生み出すための製作者を奨励していました。 より現実的なモチーフのマテリアルデザインなどに比べ、半現実的なディテールのコンセプトは、明快さやエレガントさにおいて劣りますが、芸術的な美学を保つことはできます。 美しいグラデーションや、表現豊かなタイポグラフィ、想像性豊かなアニメーション、滑らかなグラフィック、そして豊富なドローイング を使うこと
読みやすいRSpecを書くためのTips - 弥生開発者ブログ
こんにちは、黒曜(@kokuyouwind)です。 最近見つけた面白いポケストップは「シーサーに似た守り神(メイドインタイランド)」です。 PokemonGOは飽きてきて、代わりに最新作のサン・ムーンが欲しくなってきました。 アローラロコンかわいいよアローラロコン。あとミミッキュ。 さて、Misocaに入社して一年弱が経ち、RSpecの書き方にも大分慣れてきたのですが、油断すると冗長で複雑なSpecを書いてしまいがちです。 既存のSpecが複雑だと新しいexampleを追加するときにも書きづらくなってしまうため、気づいたらなるべくリファクタリングするように心がけています。 今回は、最近自分が「こういう書き方だと読みやすく保守もしやすいのではないか」と思っているRSpecの書き方について紹介していきたいと思います。 Specを記述する対象と文脈に着目して分割する 最近書くSpecでは、大体
Ruby の Timeout の仕組み - tmtms のメモ
Ruby で長い時間掛かるかも知れない処理のタイムアウトを行うにはこんな感じにします。 require 'timeout' begin Timeout.timeout(3) do # 3秒でタイムアウト hoge # 何かの処理 end rescue Timeout::Error puts 'なげーよ' # タイムアウト発生時の処理 end Timeout.timeout はブロック開始時にスレッドを作成し、そのスレッドで指定された秒数だけ sleep して、sleep から復帰してもまだブロックが終わってなければ作成元のスレッドに対して Timeout::Error 例外を発生させます。 指定時間以内に処理が終わる場合: timeout(X) │ スレッド作成 ─┐ │ │ ブロック実行 sleep X │ │ スレッドkill→ 🕱 │ timeout復帰 指定時間以内に処理が終わら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
cookpad 2015 summer internship TDD
How we cook cookpad.com 2016
Linuxユーザ管理の決定版？ 〜STNSとサーバレスで夢が広がる〜【cloudpack大阪ブログ】 - Qiita