責任ある開発者のためのHTTPヘッダー | Yakst
安全で、誰にも手頃でアクセスしやすく、ユーザーを尊重した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社および原著者の許可を得て翻訳しています
超高速な開発ができるわけ | Yakst
あるひとりの人がシステムを作ったが故にそのシステムに精通している場合に、最も生産的な開発が行われる。しかしこれは、ひとりの人がシステムの面倒を見ることを超えてシステムが成長する時には矛盾してしまう。 ある状況下において、特定の開発者たちが他の人の10倍生産性が高くなることがあるのはなぜかについて議論してみましょう。 ヒント : 開発者の話ではなく、状況が大きなカギ。 生産性が非常に高いことにウキウキした気分になるのはいつでしょうか。新しい機能が指先からあふれ出てくる時？それは、私たちが関わるツールのことを知り尽くしている時、あるいはもっと決定的に言うと、自分がシステムを変更しつつある時に起こるのです。自分のバックパック、それも自分で詰め込み、そしてひとつひとつの小袋の中まで何年にもわたる旅行を経て調整してきたバックパックの中身を知っているように、システムを知ることです。それぞれのモジュール
CPU使用率は間違っている | Yakst
Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか？プロセッサーがどのくらい忙しいか？違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが
Windowsのドライバーの日付が全部2006年6月21日なのはなぜ？更新されていないの？ | Yakst
バージョン番号が変わるのに日付が全部同じという不思議な仕組みのWindowsのドライバー。そこには秘密が。 なぜWindowsのドライバーの日付が2006年6月21日なのか？ドライバーをアップデートしたことないの？単なるなまけ者集団？ もっと重要なことに、2006年6月21日という日付は、Storage Spacesのように2006年に存在すらしていなかったドライバーにも適用されているのです！また開発部門がタイムマシンを使ったのでしょうか？ Windowsのすべてのドライバーの日付は2006年6月21日に設定されています。バージョン番号は時とともに増えていきますが、タイムスタンプは変わらないままです。 私の同僚Zacがこう説明しています。ある特定のハードウェアのために使うドライバーを探す時、システムは色々な基準に基づいてドライバーをランク付けします。ドライバーがハードウェアIDとぴったり一
寿司=ビール問題 : MySQL 8.0でのUTF8サポート入門 (MySQL Server Blogより) | Yakst
これまでのMySQLでよく問題になった、絵文字や日本語の文字の照合やソート順序の問題に関して、来たるMySQL 8.0では大幅な改善が加えられる予定になっている。この問題の概要と今後の改善方針について、MySQL開発チームからの解説。 免責事項 この記事はManyi Lu氏によるMySQL Server Blogの投稿「Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0」(2017/1/13)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0での私たちの計画として、utf8のサポートを大幅に改善します。utf8サポート自体はMySQL 4.1の頃にさかのぼりますが、いくつかの制限が存在しています。記事タイトルにもある「寿司 = ビール」問題は、バグ#76553のことを指しています。少
RethinkDBはなぜ失敗したのか | Yakst
つまり、これらのマーケットは小さく、しかもデータベースのマーケット自体よりも小さいのです。とは言え、どれかが他よりもマシになりうるでしょうか？ マネージドホスティングは、本質的にはユーザのためにAWSでデータベースを動かすことで、そうすることでユーザたちは自分で動かす必要がなくなります。これらのサービスを使う代わりになるのは、AWSに自分でデータベースを立てることです。したがって、マネージドなデータベースホスティングサービスが課金できる額には、非常に厳しい上限があることになります。Compose.ioやmLabが、RethinkDBよりも1桁あるいは2桁多いユーザを抱えるMongoDBを提供していることを考えて、マネージドホスティングを提供することには少しの良い点もないという結論を下しました。 Database as a Serviceはマネージドホスティングの更に複雑なバージョンです。D
MySQLインデックスのお手入れの基本 | Yakst
Percona Database Performance Blogの翻訳。既に運用を始めたデータベースで、インデックスが正しく使われているか、無駄や不足がないかを確認する方法のまとめ記事。クエリをひとつひとつ確認するのではなく、統計情報を元に判断する分かりやすい方法。 このブログ記事では、MySQLインデックスに手入れする基本的なステップについて見ていこうと思います。 データベースは、インデックス次第でハイパフォーマンスにも、役立たずで遅くて大変にもなりうることはご存知でしょう。インデックスは、時々手入れをする価値がある非常に重要なものです。それでは、何をチェックすればよいのでしょうか？順不同ですが、確認すべき点を挙げてみます。 1. 使われていないインデックス sysスキーマで、使われていないインデックスをとても簡単に見つけられます。 schema_unused_indexes ビューを
読みやすいREADMEを書く | Yakst
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
6万ミリ秒でできるLinuxパフォーマンス分析 | Yakst
NetflixのシニアパフォーマンスアーキテクトであるBrendan Gregg氏による、Linuxサーバにログインして60秒でまず調べることのまとめ。 パフォーマンス問題でLinuxサーバーにログインしたとして、最初の1分で何を調べますか？ Netflixには、多数のEC2 Linuxからなるクラウドがあり、そのパフォーマンスを監視したり調査したりするための数々のパフォーマンス分析ツールがあります。その中には、クラウド全体にわたる監視を行うAtlasや、オンデマンドにインスタンスの分析を行うVectorがあります。これらのツールは多くの問題を解決する手助けをしてくれますが、各インスタンスにログインし、標準的なLinuxパフォーマンスツールを実行する必要がある場合もあります。 この記事では、すぐ使えるはずの標準的Linuxツールを使いコマンドラインにおいて、最適化されたパフォーマンス調査を
innodb_file_per_tableが有効な時にディスク容量を開放するには | Yakst
MySQL Performance Blogの翻訳。innodb_file_per_tableが有効になっている時、データを削除してもデータファイルのサイズは小さくならない。これを小さくする方法とは。 September 25, 2013 By Nilnandan Joshi innodb_file_per_tableがOFFの時には、全てのデータはibdataファイルに保存される。テーブルをドロップしたりデータを消したりしたとき、使用されていないディスク領域を解放するには、ダンプしてからリストアするしかない。 innodb_file_per_tableがONの時には、各テーブルのデータとインデックスはそれぞれの表領域ファイルに保存される。しかし、共有の表領域であるibdata1も容量が増えてしまう。これがなぜ起きて、どうやって解決するかはこちらの記事(日本語訳)を見て欲しい。 上に挙げた
LIKE句のSQLインジェクション | Yakst
GitHubのエンジニアがデータベースのスローログから見つけた、LIKE句を使ったクエリーのパフォーマンス問題につながる可能性のある文字列。問題の仕組みと、それを回避するためのスニペット。 先日、例外情報のトラッカーを見回していたら、目を引くスロークエリーログを発見しました。SELECT ... WHERE ... LIKEといったクエリーのLIKE句にたくさんのパーセントが付いているのです。この部分はユーザが入力した部分なのは明らかで、最初私はSQLインジェクションを疑いました。 [3.92 sec] SELECT ... WHERE (profiles.email LIKE '%64%68%6f%6d%65%73@%67%6d%61%69%6c.%63%6f%6d%') LIMIT 10 コードを見てみると、ここで解釈されるメタ文字(%や_や\)のチェックをまったくせずにユーザが指定し
GitHub : ノマドなエンジニア達とRubyをスケールさせる | Yakst
GitHubの技術ディレクターが語る、GitHubのインフラの特徴と、社員の6割がリモート勤務という社風、Hubotを使った協力的かつ新しい働き方。 Sam Lambertは、2013年にGitHubの最初のデータベース管理者として入社し、現在はGitHubの技術ディレクターを務めています。このインタビューで彼は、今や1000万以上のユーザと2500万以上のプロジェクトを誇るサービスが、比較的シンプルな技術的スタックの上でどのようにスケールし続けてきたのかを考察しています。また、自作のパワフルなチャットボットであるHubotを使ってコラボレーションしつつ、従業員の約6割がリモートで働いているという、GitHubの大規模なオフィスレスな仕事環境についても触れています。 SCALE: 私としては、GitHubはテクノロジーのユーザーというよりは主にテクノロジーの提供者であると思っていますが、そ
Bashのよくある間違い | Yakst
原文は2015年8月22日時点のものを利用しており、それ以降に追記、更新されている可能性があります。 本翻訳は原作者の許可を得て公開されています。 Thanks for GreyCat! このページはBashプログラマーが陥りがちなよくあるエラーについてまとめました。以下の例は全てなんらかの欠陥があります。 クオートをいつも使い、どんな理由があっても単語分割を使わなければ、多くの落とし穴からあなた自身を守ることができます！単語分割はクオート表現をしない場合にはデフォルトでオンになっている、Bourneシェルから継承された壊れたレガシーな設計ミスです。落とし穴の大半はクオートされていない展開になんらか関連し、単語分割しその結果をグロブします。 1. for i in $(ls *.mp3) BASHプログラマーたちがループを書く際にもっとも犯しがちなよくあるミスは以下のような感じです。: f
MySQLインデックスの基礎 : ひとつのテーブルに対するクエリの最適化法 | Yakst
MySQLのインデックスを効果的に使うにはどうしたらいいのかについての分かりやすい解説。そもそもインデックスの役割はとは何か、そしてどうすればその役割を果たしてくれるのかを説明する。 たとえ1つのテーブルだけに対して実行されるクエリでも、パフォーマンスが悪いというのはよくあることです。その理由は簡単で、インデックスの作り方がまずいため、実行計画がおかしくなってしまうのです。ここでは、1つのテーブルのみに対する色々なクエリを最適化するためのガイドラインを挙げてみたいと思います。 おことわり : あらゆる状況をカバーしようとはせず、一般的なガイドラインを提示するに留めるつもりです。ここで挙げたものがうまく適用できない例を簡単に見つけることができるのは間違いないでしょうが、ほとんどの場合はここに書いたことが十分なのも事実です。また、MySQL 5.6以上にあるIndex Condition Pu
プログラミング初心者に言ってはいけないこと | Yakst
経験あるプログラマが初心者に言ってしまいがちだが、初心者のモチベーションに悪影響を与えるパターンを指摘する。言った方、言われた方、あるいは聞いたなど、何らかの形で誰もが身に覚えのある内容。 経験のあるプログラマと、プログラミングを習い始めたばかりの初心者の会話の例。 プログラマ : やあ、プログラミングの勉強を始めたんだって？いいじゃないか、何を勉強してるんだい？ 初心者 : PHPとHTMLの基礎をやってるんです。MacでTextMateエディタを使ってます。 プログラマ : ひええ、PHPなんて間抜けな言語かよ。Ruby on Railsを覚えて、Herokuにデプロイ、Vimでコーディングした方がいいよ。TextMateなんて初心者向きじゃないか。それから、Node.jsもやった方がいいな。あれはすっっっごくいいぜ。ノンブロッキングIOだからな。ヒャッハー！ 初心者 : うーん、そう
MySQLで、正しいデータ型を使うことはどのくらい重要なのか？ | Yakst
テーブル設計においてカラムのデータ型を正しく決めることには、どのような利点があるのかについて。単純に扱う値と同じ型を選ぶべきであるというだけではなく、なぜそうあるべきかについて、内部的な効率の面から解説する。 パフォーマンスに関する話の中で、カラムに値を保存するのに正しいデータ型を使うことの重要性を説いているのを聞くことがよくある。例えば、数値はINTやBIGINTで表現し、IPアドレスにはINT UNSIGNEDを使い、VARCHAR(255)の代わりにVARCHAR(60)を使うといったことだ。 このアドバイスは正しい。しかし、今日はもう少し詳細の説明を試みてみようと思う。 理由 この最適化が正しいと思う3つの理由は以下の通りだ。 文字列として数値データを扱うことは、文字コードや照合処理のCPUオーバーヘッドが余計に必要になってしまう。例えば、'Montréal' = 'Montrea
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
