スピードとスケールのソフトウェア

ネイティブElixirアプローチによるバックグラウンド作業の実行

デズモンド・ボウ著

Elixirの錬金術師の多くはRuby / Railsのバックグラウンドを持っている。バックグラウンドジョブを作成するタスクが発生すると、Rubyユーザはキューシステム、Redis、RabbitMQなど、自分が知っている楽しいものに手を伸ばしがちです。もっと良い、慣用的な方法がある。

https://blog.appsignal.com/2019/05/14/elixir-alchemy-background-processing.html

Rustを使ってElixirを1,100万人の同時ユーザーに拡張する

マット・ノワック著

通常の」スケールのタスクでは、Elixirはかなり速い。大規模なアプリケーションでもかなり速い。しかし、スケールが単に大きいだけでなく、巨大な場合はどうすればいいのでしょうか？それは チーム ディスコードが答えようとする。

https://blog.discordapp.com/using-rust-to-scale-elixir-for-11-million-concurrent-users-c6f19fc029d3

クエリ最適化の物語

マニッシュ・ギル著

ある特に頑固な問い合わせを最適化した素晴らしい事例を紹介します。PostgreSQLの最適化ツールについて深く掘り下げた興味深いものです。

https://parallelthoughts.xyz/2019/05/a-tale-of-query-optimization/

ダウンタイムなしで数百万のRedisキーを移行する

グスタボ・カソ著

Redisは汎用性の高い素晴らしいツールで、Shopifyはこれを多用している。しかし、ある時点で既存のソリューションがスケーリングできなくなり、アップグレードが必要になりました。しかし、何百万ものエントリーを持つRedisクラスターをどのように移行すればよいのでしょうか？

http://gustavocaso.github.io/2019/04/30/migrating-millions-of-redis-keys-without-downtime/

モジュール式ルボコップ

ボジダル・バツォフ著

RuboCopは、私たちの正直さと私たちを維持するために、大量の組み込みの警官を持っています。 コード 出力はクリーンだ。その数は非常に多いので、それは恩恵でもあり苦痛でもある。RuboCopチームがどのようにそれを管理するつもりなのかについての記事はこちら。

https://metaredux.com/posts/2019/05/22/a-modular-rubocop.html

ボーナスだ！ もっと知りたい？についての記事をご覧ください。 ビットコインを暴落させた唯一の取引.

あわせて読みたい：

• クラクフのRuby会議。私たちはそこにいた！
• なぜ人々はRubyを恐れるのか？最もポピュラーな神話
• ソフトウェアプロジェクトはなぜ失敗するのか？最も一般的な理由