こんにちは。私はSergey Kamardin（セルゲイ・カマルディン）です。Mail.Ru（ロシアの電子メールサービス会社）で開発者をしています。 この記事では、どのように私がGoを使って高負荷対応のWebSocketサーバを開発したかについて説明したいと思っています。 パフォーマンス最適化のアイデアやテクニックを通じて、WebSocketの知識はあるもののGoについてはほとんど知らないという方のお役に立てれば幸いです。 1. はじめに まずは開発に至った経緯について、どうして私たちがこのサーバを必要としたのかを説明しておきましょう。 Mail.Ruには多くのステートフルなシステムがあります。ユーザのeメール保存もその1つです。システム内、およびシステムイベントの状態変更を追跡する方法にはいくつかの種類がありますが、それらは主に状態変更に関するシステム通知、または周期的なシステムのポーリ

1. 概要 SQLiteを使うと小さなBLOB（例：サムネイル画像など）を読み書きする場合、fread()やfwrite()を使って個別のファイル上に記録されたBLOBを読み書きするよりも35％も速く (*1) 読み書きができます。 さらに、10キロバイトのBLOBを扱うようなSQLiteデータベースを考えた場合、個別のファイルにそれぞれのBLOBを格納する場合に比べてディスク領域を約20％も節約可能です。 このようなパフォーマンスの差が生じる理由は、（私たちの考えでは）SQLiteデータベースの場合、open()やclose()システムコールが呼び出されるのが1回だけなのに対して、個別のファイルに格納されているBLOBを使用する場合は、open()やclose()がBLOBの数だけ呼び出されるためだと思われます。どうやらopen()とclose()を呼び出すオーバーヘッドは、データベース

数年前、Microsoftは、社内全体のエンジニアリングシステムを活性化させるため、数年間にわたる投資を行う決定をしました。私たちは山のような数のチームを抱える大企業です。チームはそれぞれ、担当のプロダクト、独自の優先順位、プロセス、ツールを持っています。”共通の”ツールもありますが、チームによって様々に異なる点も多く、内部で開発した単発のツールも数え切れないほどあります（「チーム」とは社の部門のようなもので、数千のエンジニアの集まりです）。 この状況にはたくさんのマイナス面があります。 似たようなツールを構築しているチームがいくつもあり、巨額の冗長な投資が生まれている 「クリティカルマス（損益分岐点を超える生産量、普及率）」に向けた設備投資ができない 皆がバラバラのツールやプロセスを用いているため、従業員が異動しにくい 組織の垣根を越えてのコード共有が難しい “MS限定”ツールの過多のた

(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間

例えば、あなたが驚くほど聡明な開発チームのメンバーで、コードレビューのみに一日の時間を確保しているとします。しかし作業を開始して2時間後、眼鏡を忘れてきてしまい、午前中はぼんやりとしたカラフルな表示を見つめていただけだったということに気づいたとします。さて、あなたはどうしますか? 家まで歩いて10分もかからないし、天気も良ければ、眼鏡を取りに帰るのが一番です。でも朝家を出るとき、攻撃的なスズメバチの群れが眼鏡の置いてある部屋に巣を作って、邪魔されたくない様子だったらどうしますか？ そういう時はもちろん、コンタクトレンズを付けてきたふりをして、恥ずかしい思いをしないようにするのがよいでしょう。実際に読むことなく膨大な量のファイルを見分けることができるということを覚えておいて下さい。 参考コード 1 不安の種は隔離するべきだということに誰も異論はないでしょう。そしてもちろん、あらゆるクラスは一

本題に入る前に言っておきます。私は、このトピックは重大であるし、Chef Software（以後Chef Incと表記）の一部の人たちにとっては、ことさら重要な意味があると思っています。「Chefはオープンソースではない」という問題に向き合う時が来たのです。いつからそうなったか正確には分かりませんが、この数年間でChefはオープンソースモデルから確実にシフトしてきています。 「でも、コードはGitHubに公開されていますよ」 確かに、文字通りの意味では、コードは自由に閲覧および改変できるようになっていますが、それだけではオープンソースの理念を満たしているとは言えません。なぜなら、オープンソースとは協力してソフトウェアを構築するコミュニティだからです。 「でも、私もパッチを提供したことがありますよ」 皆さんのコントリビューションには感謝しますが、この問題は大局的に捉える必要があります。元々「