安全で、誰にも手頃でアクセスしやすく、ユーザーを尊重したWebを作るためのHTTPヘッダーのプラクティス [UI/UX]原文 HTTP headers for the responsible developer - Twilio (English) 原文著者 Stefan Judis 原文公開日 2019-04-23 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket msh5 原著者への翻訳報告 1821日前 メールで報告済み 編集 This article was originally published on twilio.com, and translated with the permission of Twilio and the author. 当記事の原文はtwilio.comにて公開されたものであり、Twilio社および原著者の許可を得て翻訳しています

Python の可視化ライブラリである Seaborn を利用して表現豊かなグラフを生成するためのテクニックを紹介する記事です。グラフの選択基準としてデータを構成する値が分類のある値かそれとも連続値であるかに注目しており、この記事を通して実践的なテクニックを身につけることができます。 可視化は素晴らしいものです。ですが、優れた可視化の実現は悩ましく容易ではありません。 また、大勢に対して優れた可視化をプレゼンするような場合には時間と労力がかかりますよね。 私たちは棒グラフ、散布図、ヒストグラムの作り方についてはよく知っていますが、それらを美しくすることに対してはそこまでの注意を払っていません。 このことは同僚やマネージャーからの信頼に影響します。今あなたがそれを感じることはありませんが、それは起こることです。 さらに、私はコードの再利用が重要であることを知っています。新しいデータセットに触

MySQLのコネクションハンドリングの内部構造、スケール限界、そして最大コネクション数のチューニングなどについてご紹介します 免責事項 この記事はGeir Hoydalsvik氏によるMySQL Server Blogの投稿「MySQL Connection Handling and Scaling」(2019/3/19)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 この投稿では、MySQLのコネクション、ユーザースレッドおよびスケーリングについて取り扱います。MySQLがどのように動作するかをよりよく理解することで、アプリケーション開発者やシステム管理者が、トレードオフを踏まえた良い選択をできることでしょう。本記事ではコミュニティー版でコネクションがどのように動作するかについて述べますが、一方でスレッドプール、リソースグループ、あるいはコネクション多重化といった関

MySQLの準同期・ロスレス準同期レプリケーションの仕組みを解説し、同機能についてのよくある誤解やメリットについて説明します。 最近、メールで「MySQL Lossless Semi-Synchronous Replication」について質問されることがありました。この質問への答えは多くの人にとって有益であると考えたため、回答をこのブログ記事に書きたいと思います。回答を読めば、トランザクションのコミット、準同期レプリケーション、MySQLのクラッシュリカバリ、ストレージエンジン（InnoDB）クラッシュリカバリの内部挙動について理解できるでしょう。同時に、私がこれまで見聞きしてきたいくつかの誤解についても糾したいと思います。まずはそれら誤解の一つから始めましょう。 こうした誤解の一つは以下のようなものです（これは正解ではありません）：準同期レプリケーションが有効になっているスレーブは常に

MySQL 8 は MySQL 5.7 より常に高速とは限らない(MySQL 8 is not always faster than MySQL 5.7) に続いて、 今回は、データがメモリに収まっており、CPUバウンドな、read only のとてもシンプルなワークロードのテストをすると決めました。このワークロードにIO処理はありません、メモリとCPUの処理だけです。 テスト環境 環境のスペック Release | Ubuntu 18.04 LTS (bionic) Kernel | 4.15.0-20-generic Processors | physical = 2, cores = 28, virtual = 56, hyperthreading = yes Models | 56xIntel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz< Memory T

trivago社の小規模な開発チームがコンテナオーケストレーターとしてKubernetesではなくNomadを採用することになった経緯と理由について、両プロダクトの特徴やユースケースに言及しつつ紹介されています。 [HashiCorp][Kubernetes]原文 Maybe You Don't Need Kubernetes (English) 原文著者 Matthias Endler 原文公開日 2019-03-21 翻訳依頼者 翻訳者 msh5 翻訳レビュアー doublemarket 原著者への翻訳報告 1904日前 Twitterで報告済み 1903日前 原著者承諾済み 編集 スクーターに乗った女性（イラスト画像の作成元はfreepik、NomadロゴはHashiCorp） Kubernetesはコンテナオーケストレーションの巨人です。世界中で巨大なデプロイメントを動かしています

[MySQL]原文 Tuning InnoDB Primary Keys - Percona Database Performance Blog (English) 原文著者 Yves Trudeau 原文公開日 2018-07-26 翻訳依頼者 翻訳者 kakuka4430 翻訳レビュアー doublemarket 原著者への翻訳報告 2055日前 原文へのコメントで報告済み 編集 良いInnoDBプライマリキーを選ぶことは、パフォーマンスチューニングの方向性にとても重要です。この記事では、あなたのワークロードに応じた最適なプライマリキーを選ぶための方法を紹介したいと思います。 Percona社のプリンシパルアーキテクトとしての私の責務の一つは、顧客のデータベースをチューニングすることです。パフォーマンスチューニングに関連する側面は多く存在し、それがこの仕事を複雑、かつ大変興味深いものに

MySQLがメモリー不足で停止してしまった(OOM Killerに停止させられた)時に確認すべき項目を紹介する。特に、MySQLのバグでメモリリークが起きている可能性がある場合に手がかりを得る方法について。 [MySQL]原文 What To Do When MySQL Runs Out of Memory: Troubleshooting Guide - Percona Database Performance Blog (English) 原文著者 Alexander Rubin 原文公開日 2018-06-28 翻訳依頼者 翻訳者 doublemarket 翻訳レビュアー kakuka4430 原著者への翻訳報告 1948日前 原文へのコメントで報告済み 編集 クラッシュした時のトラブルシューティングが楽しいタスクであったためしはありませんが、クラッシュの原因をMySQLが教えてくれ

PostgreSQLのvacuumの問題が発生した場合に起こるテーブル肥大化について、発生要因を３つ挙げて説明している。 [PostgreSQL]原文 Three reasons why VACUUM won't remove dead rows from a table - Cybertec (English) 原文著者 Laurenz Albe 原文公開日 2018-03-14 翻訳依頼者 翻訳者 nao3nao3 翻訳レビュアー doublemarket 原著者への翻訳報告未報告 何故VACUUMを実行するのか？ PostgreSQLのテーブルで、行がUPDATEやDELETEが実行されるいかなる時も、dead rowsは置き去りにされています。 VACUUMはそれらを削除し、その領域が再利用できるようにしています。 もしテーブルがVACUUMされない場合には、そのテーブルは肥大化し

コードレビューの際に落とし穴にはまらずに、どのようにうまくコミュニケーションをとるか、に関する記事の後半部分です。著者がコードレビューで失敗した実例を元にお互いの衝突を避けるテクニックについて紹介します。 [プログラミング]原文 How to Do Code Reviews Like a Human (Part Two) - Silly Bits (English) 原文著者 Michael Lynch 原文公開日 2017-11-09 翻訳依頼者 翻訳者 taka-h 翻訳レビュアー doublemarket 原著者への翻訳報告 2370日前 メールで報告済み 2368日前 原著者承諾済み 編集 この記事はコードレビューの際に落とし穴にはまらずに、どのようにうまくコミュニケーションをとるか、に関する記事の後半部分です。今回はひどい衝突を避け成功裏にレビューを終わらせるテクニックに焦点をあ

シリーズ第三回目で、「グループレプリケーション」「プロキシ」「分散ストレージ」について紹介している。グループレプリケーションはGaleraとの違いについて、プロキシには幾つかの選択肢があること、分散ストレージではオープンソースのAuroraのようなデーターベースが可能になることなどが述べられている。 この記事は、2017年現在で使用できるMySQLの高可用性ソリューションに焦点を当てたシリーズの第3回目です。 最初の記事では10年以上前から存在していた技術である「長老」を見ました。（訳注：長老編日本語訳）第2回目の記事では「大人」 、つまりより最近の成熟した技術について話しました。（訳注：大人編日本語訳）この記事では、新興のMySQL高可用性ソリューションを紹介します。私がブログで選択した「赤ちゃん」の高可用性ソリューションは、 Group Replication（グループレプリケーション

MySQLでもついにヒストグラム統計を利用した実行計画作成がサポートされるようになりました。作成/削除の方法やどのようなときにインデックスと比べて有利か、などについてご案内します。 免責事項 この記事はErik Frøseth氏によるHistogram statistics in MySQL(2017/10/2)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0.3では、ヒストグラム統計を作成しオプティマイザがより多くの統計情報を利用できるようにすることができます。このブログ投稿では、どのようにヒストグラム統計を作成し、どのような時に役立つかについて説明しようと思います。 ヒストグラムとは何か クエリーオプティマイザはデータベースの中で、SQLクエリーを可能な限り最も効率の良い実行計画に変換する役割を担っています。 時にはクエリーオプティマイザは最も効

あるひとりの人がシステムを作ったが故にそのシステムに精通している場合に、最も生産的な開発が行われる。しかしこれは、ひとりの人がシステムの面倒を見ることを超えてシステムが成長する時には矛盾してしまう。 ある状況下において、特定の開発者たちが他の人の10倍生産性が高くなることがあるのはなぜかについて議論してみましょう。 ヒント : 開発者の話ではなく、状況が大きなカギ。 生産性が非常に高いことにウキウキした気分になるのはいつでしょうか。新しい機能が指先からあふれ出てくる時？それは、私たちが関わるツールのことを知り尽くしている時、あるいはもっと決定的に言うと、自分がシステムを変更しつつある時に起こるのです。自分のバックパック、それも自分で詰め込み、そしてひとつひとつの小袋の中まで何年にもわたる旅行を経て調整してきたバックパックの中身を知っているように、システムを知ることです。それぞれのモジュール