SRE(Site Reliability Engineering)チームの@cubicdaiyaです。今年のはじめから開発しているWidebulletというシンプルなAPI Gatewayを紹介します。 WidebulletはJSON-RPCをベースにしたシンプルなAPI Gatewayです。Goで書かれています。 github.com JSON-RPCはJSONによるRPC(Remote Procedure Call)プロトコルで、リクエストやレスポンスのボディに含まれるJSONを利用してクライアント/サーバ間の通信を行います。 # リクエストボディ { "jsonrpc": "2.0", "method": "echo", "params": {"msg": "ok"}, "id": "1"} # レスポンスボディ {"jsonrpc": "2.0", "result": "ok",

DDD+CQRS+Event SourcingとAkkaでの実装ヒントを解説。

When we started working on CitusDB 1.0 four years ago, we envisioned scaling out relational databases. We loved Postgres (and the elephant) and picked it as our underlying database of choice. Our goal was to extend this database to seamlessly shard and replicate your tables, provide high availability in the face of failures, and parallelize your SQL queries across a cluster of machines. We wanted

みなさんこんにちは、@ryuzeeです。 今日はデイリースクラムについて、概要や注意点を紹介します。 なお、あくまで一般論であることに注意してください。スクラムの基本は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。 1. デイリースクラムの目的スクラムを利用するとき「フレームワークで決められているから」というだけの理解で進めてはいけません。これは全てのイベントに当てはまります。 スクラムのイベントはすべて、検査と適応が行われるように明確に設計されています。 デイリースクラムの最大の目的は、スプリントゴールの進捗を検査し、今後の作業計画を必要に応じて見直す（適応する）ことで、スプリントゴール達成の可能性を最適化することです。 毎日の検査と適応（高速なフィードバックループ）によって問題を早期に発見することでリスクを減

長年IT業界で働いていると、たびたび遭遇する風景がある。 省エネのためと称してお昼休みの間フロアーの照明を消すオフィスがある。 さっさとLEDライトにした方が効果が高い気がするのだが…それはさておき、昼休みが終わってフロアーに戻るとおや？薄暗い。「まだ誰も戻ってきてないの？」とおもってパチッと電気を点けると、5人ぐらいの協力会社さんが目の前にパッと現れてギョッ！とする。すでに午後の作業にとりかかってらっしゃる。 …なぜ、電気点けない。 ある日、所要で朝早く出社したらフロアーが薄暗い。 オフィスに一番乗りかな？と思ってフロアーの電気をパチッと点けると…既に協力会社のAさんがパンを食べながらキーボードを打っている。 …なぜ、電気点けない。 この風景を私は「協力会社さんがダークサイドに落ちてる」と呼ぶ。 なぜ協力会社さんは電気を点けないのか。なぜ暗闇で作業してても平気なのか。理由はいくつか考えら