Gitでブランチ(コミット)間の違いを表示するgit diffコマンドに存在するダブルドット(..)記法とトリプルドット(...)記法の違いについて、Stackoverflowの分かりやすい回答。 「git diffコマンドで比較する時のダブルドット(..)とトリプルドット(...)の違いとは？」という質問へのMark Longair氏の回答 git diffコマンドは通常(「通常」というのは、例えばマージコンフリクトを解消する際などには3ウェイマージを表示することがあるため)、コミットグラフにおける完全な2つのポイント間のツリーの状態の違いを表示します。git diffでの..と...の表記は、以下の意味になります。 言い換えると、git diff foo..barはgit diff foo barと完全に同じです。どちらも2つのブランチfooとbarの最新の変更同士の違いを表示します。

Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか？プロセッサーがどのくらい忙しいか？違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが

Percona Database Performance Blogの翻訳。既に運用を始めたデータベースで、インデックスが正しく使われているか、無駄や不足がないかを確認する方法のまとめ記事。クエリをひとつひとつ確認するのではなく、統計情報を元に判断する分かりやすい方法。 このブログ記事では、MySQLインデックスに手入れする基本的なステップについて見ていこうと思います。 データベースは、インデックス次第でハイパフォーマンスにも、役立たずで遅くて大変にもなりうることはご存知でしょう。インデックスは、時々手入れをする価値がある非常に重要なものです。それでは、何をチェックすればよいのでしょうか？順不同ですが、確認すべき点を挙げてみます。 1. 使われていないインデックス sysスキーマで、使われていないインデックスをとても簡単に見つけられます。 schema_unused_indexes ビューを

主にPostgreSQLで、アプリケーションがスケールしていくことを考慮に入れずに後で困ることになりがちな設計のポイント。今後巨大にスケールする必要が分かりきっている際には特に注意すべき点。 開発者として仕事を始める時には、参ってしまうほど覚えなくてはいけないことがあります。まず最初に言語自体、それから使っているフレームワーク特有のクセ、さらにその後(あるいはその前)にフロントエンド開発を織り交ぜ、そしてその先でデータをどこに保存するかを決めなくてはなりません。 最初の頃は、素早く身につけるべきことが多すぎて、アプリケーションのデザインにおいてデータベースは後から付け足すものになりがちです(おそらくこれはエンドユーザーエクスペリエンスに影響がないからでしょう)。その結果、データベースが動き始めてから直さなくてはならない数々の悪い習慣が存在しています。ここでは、そのうちのいくつかについて概要

いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの

Linuxカーネル開発者になりたいと思っても、まず何から手をつけたらいいか分からず、始める前から挫折する人も多いだろう。すぐ始められる最初の一歩の例が、筆者の経験を交えて4つ挙げてある。 (これは、CUSECというイベントでの、カーネルは怖くないという話の続き) カーネルプログラミングを始めるにはどうしたらいいか、アドバイスを求めたことがある。その時は、こう回答があった。 仕事のためにカーネルを理解する必要がなくても、やってみたらどうだろう？ Linuxカーネルメーリングリストに登録してみて、精一杯理解しようと頑張ってみよう。 メインのLinuxカーネルの一部にならないコードを書いているなら、時間の無駄だ。 これは私にとっては、全然、少しも役に立たなかった。そんなわけで、ここでは、あなたなりにOSやLinuxカーネルがどう働くか、楽しみながら理解していくための、いくつかの戦略について書いて

私はシェルスクリプトの大ファンで、他人のスクリプトから面白い方法を学ぶのが大好きだ。最近、SSHサーバの2要素認証を簡単にするためのauthy-sshスクリプトに出会った。このスクリプト群を見まわしていて、みんなと共有したいたくさんのクールなことを見つけた。 出力に色付けする 出力文字列を、成功した時は緑に、失敗した時は赤に、警告は黄色に色づけしたいと思うことはたくさんあるだろう。 NORMAL=$(tput sgr0) GREEN=$(tput setaf 2; tput bold) YELLOW=$(tput setaf 3) RED=$(tput setaf 1) function red() { echo -e "$RED$*$NORMAL" } function green() { echo -e "$GREEN$*$NORMAL" } function yellow() { e