原文 Engineering Career Development at Etsy - Code as Craft (English) 原文著者 Ryan Bateman 原文公開日 2019-10-02 原文ライセンス CC BY-NC-ND 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1616日前 原文へのコメントで報告済み 編集 2018年の5月の終わり頃、Etsyは社内でエンジニアリングのキャリアラダー (Career Ladder) を発表しました。 現在では、広く一般にこのラダーを公開しており、私たちがなぜこのようなものを作ったのか、なぜこの内容になったのか、そして発表以降どのように活用されてきたのかを詳細化しています。 こちらをご覧ください。 キャリアラダーの定義 キャリアラダーは、企業内におけるエンジニアの成長パスを描くのを助

ハニー、見てくれよ。俺はテクノロジーを使ってるんだから 謝ってる時間なんてなかったよ THE STOOGES, SEARCH AND DESTROY この数年というもの、私が作ったもののバグについて謝るのを意識的にやめようとしてきました。 バグについて謝ろうという誘惑は強いものがあります。昔は自分も謝っていました。私の書いたコードのせいで、同僚の1日が台無しになってしまったり、ユーザに対する影響が出てしまった時には、「おっと、ごめんよ！そんなこと考えもしなかった」と言っていたものです。 この謝罪の動機はもっともなものです。あなたはチームのためにベストなことをしたいわけです。つまり、ほんのちょっと違ったやり方をしていれば、問題は防げたはずなのです。そう考えると、バグについて謝るのは害がないように見えます。しかし、次のような文化的なアンチパターンの原因になります。 ある人またはコードの一部を、

[SRE]原文 An Incident Command Training Handbook – Dan Slimmon (English) 原文著者 Dan Slimmon 原文公開日 2019-06-24 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1723日前 Twitterで報告済み 編集 私が Hashicorp で担った最初の仕事のひとつは、社内向けのインシデント指揮官のトレーニング資料を作ることでした。 これは私自身がインシデントへの対処にあたりながら何年ものあいだ肌身に感じてきた、あらゆる類の考えをまとめ上げる良い機会となり、最高に面白いタスクでした。 以下は私の書いたトレーニング資料、ほぼそのままです。 あなたがインシデントレスポンスのポリシーを定義するにせよ、即興でインシデントレスポンスを行うにせよ、お役に立てたら幸いです。

[Python]原文 What's new in Python 3.8? - DeepSource (English) 原文著者 Sanket Saurav 原文公開日 2019-07-26 翻訳依頼者 翻訳者 hiroya 翻訳レビュアー doublemarket msh5 meiq 原著者への翻訳報告 1415日前 原文へのコメントで報告済み 1415日前 原著者承諾済み 編集 はじめに もうすぐPythonの最新バージョンのベータ版が公開される予定です。最終の安定版が利用可能になるまでは、もう少し時間がありますが(リリーススケジュールはこちら)、どのような新機能が追加されているのかを調査することには十分価値があります。Python 3.8 では、言語としての構文の追加、既存の挙動に関しての軽微な変更、そして全体的な速度の改善が追加されています。これらの変更は、以前の3.7のリリースま

原文 Micro-Frontends – Paul Sweeney – Medium (English) 原文公開日 2019-05-26 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1781日前 原文へのコメントで報告済み 編集 あなたの現場には、リビルドに時間がかかって仕方がない、大規模なUIはありませんか？ 複数のチームで作業していてしょっちゅうコードがコンフリクトするなど、インテグレーションに問題が発生することはありませんか？ ひとつのアプリが、あまりにも多くの機能を抱えすぎていませんか？ そんなとき、きっとマイクロフロントエンドが役に立つでしょう。 マイクロフロントエンドは、バックエンドのエンジニアリングにおけるマイクロサービスアーキテクチャの概念を、フロントエンド開発に適用したものです。 しかしUIを複数のフロントエンドへ分割する

NetflixのシニアパフォーマンスアーキテクトであるBrendan Gregg氏による、Linuxサーバにログインして60秒でまず調べることのまとめ。 パフォーマンス問題でLinuxサーバーにログインしたとして、最初の1分で何を調べますか？ Netflixには、多数のEC2 Linuxからなるクラウドがあり、そのパフォーマンスを監視したり調査したりするための数々のパフォーマンス分析ツールがあります。その中には、クラウド全体にわたる監視を行うAtlasや、オンデマンドにインスタンスの分析を行うVectorがあります。これらのツールは多くの問題を解決する手助けをしてくれますが、各インスタンスにログインし、標準的なLinuxパフォーマンスツールを実行する必要がある場合もあります。 この記事では、すぐ使えるはずの標準的Linuxツールを使いコマンドラインにおいて、最適化されたパフォーマンス調査を

安全で、誰にも手頃でアクセスしやすく、ユーザーを尊重した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がどのように動作するかをよりよく理解することで、アプリケーション開発者やシステム管理者が、トレードオフを踏まえた良い選択をできることでしょう。本記事ではコミュニティー版でコネクションがどのように動作するかについて述べますが、一方でスレッドプール、リソースグループ、あるいはコネクション多重化といった関

[JavaScript]原文 Responsible JavaScript: Part I – A List Apart (English) 原文著者 Jeremy Wagner 原文公開日 2019-03-28 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket taka-h 原著者への翻訳報告 1860日前 メールで報告済み 編集 数値から読み取れるように、JavaScriptはパフォーマンスを大きく左右する要素です。 この傾向が続けば、Webページのサイズの中間値は近いうちに、転送�される量だけでも少なくとも400KBに達するでしょう。 他のテキストベースのリソースと同様、JavaScriptはほぼ常に圧縮されて提供されますが、配信時にいつも正しく実践されていることといえばそれくらいかもしれません。 リソースの転送時間を減らすこと自体はパフォーマンス全体から見て重

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社のプリンシパルアーキテクトとしての私の責務の一つは、顧客のデータベースをチューニングすることです。パフォーマンスチューニングに関連する側面は多く存在し、それがこの仕事を複雑、かつ大変興味深いものに

Microsoftによる買収が発表されたGitHubは、これまでどう進化し、今度どうなっていくのか？開発者プラットフォームとしてのGitHubが目指す未来を、同社のSam Lambert氏がプログラミング言語、データセンター戦略、AIといった様々な観点から語る。 [Ruby on Rails]原文 GitHub goes off the Rails as Microsoft closes in (English) 原文著者 Thomas Claburn (The Register) 原文公開日 2018-08-16 翻訳依頼者 翻訳者 mkasasagi 翻訳レビュアー doublemarket taka-h 原著者への翻訳報告 1888日前 メールで報告済み 1878日前 原著者承諾済み 編集 プラットフォーム改造で変わる「Ruby専門店」。今後はGo、Java、Kubernetesへ。

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

[InfluxData]原文 Announcing IFQL - A New Query Language and Engine for InfluxDB | InfluxData (English) 原文著者 PAUL DIX 原文公開日 2017-11-14 翻訳依頼者 翻訳者 atfujiwara 翻訳レビュアー taka-h 原著者への翻訳報告 2383日前 メールで報告済み 編集 本日私たちは InfluxDB のクエリー言語であるIFQL 初期のアルファ版をリリースします。これはInfluxDB 1.4 と共にすぐに利用できる全く新しい言語および実行エンジンです。これは個別のスタンドアロンのバイナリーとして実装されており、InfluxDB と並行して動作します。これは InfluxDB API において、バージョン 0.9 が２年以上前にリリースされて以来の最大の進歩を示してい

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

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