責任ある開発者のための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社および原著者の許可を得て翻訳しています
MySQLのInnoDBプライマリーキーのチューニング | Yakst
[MySQL]原文 Tuning InnoDB Primary Keys - Percona Database Performance Blog (English) 原文著者 Yves Trudeau 原文公開日 2018-07-26 翻訳依頼者 翻訳者 kakuka4430 翻訳レビュアー doublemarket 原著者への翻訳報告 2055日前 原文へのコメントで報告済み 編集 良いInnoDBプライマリキーを選ぶことは、パフォーマンスチューニングの方向性にとても重要です。この記事では、あなたのワークロードに応じた最適なプライマリキーを選ぶための方法を紹介したいと思います。 Percona社のプリンシパルアーキテクトとしての私の責務の一つは、顧客のデータベースをチューニングすることです。パフォーマンスチューニングに関連する側面は多く存在し、それがこの仕事を複雑、かつ大変興味深いものに
なぜAtomはVimを置き換えられないのか | Yakst
EmacsやSublime Text、Atomといったエディターにはなくてviにだけある考え方、それがAtomなどの最新のエディターがviを置き換えられない理由になるだろうという指摘。 1976年はテキストエディターにとっては良い年でした。MITでは、Richard StallmanとGuy SteeleがEmacsの最初のバージョンを書きました。バークレーではBill Joyがviを書きました(viと呼ばれるにはまだ数年を要しましたが)。 2つのエディターはひとつの同じ大きな考え方を元に作られてるんだと還元主義者(reductionist)は言いそうですが、仕方ありません、ここでは還元主義者になりましょう。2014年に目につくもの(訳注 : この記事は2014年に書かれたもの)、つまりSublime TextやAtomといったモダンなエディターを見てみると、Emacsの大きな考え方は完全
読みやすいREADMEを書く | Yakst
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
私がデータベースを愛する理由 | Yakst
モダンなデータベースに使われる各種技術や運用に必要な知識について、Squareのデータベースエンジニアである筆者の見解。データベースの内部構造や仕組みについての興味をかき立てる。 昨年、私はSquareで色々なデータベースの面倒を見る中で、こんなことをしてきた。 データベースのパフォーマンス問題の調査と解決 新しいアプリケーションの、データモデルのデザインやシャーディング戦略の立案 データベース新製品の評価と運用化 最初は必要に迫られてやっていた私は、それから徐々に、データベースの虜になっていった。データベースを学ぶことは、コンピュータサイエンスのあらゆるトピックを横断的に扱うことであり、その理論や実装は、洗練され、かつチャレンジングでもある。 しかし、こういった感覚は他のみんなにも一般的なわけではないということも分かってきた。私の同僚や友人の多くにとっては、データベースは魔法のブラックボ
Bashのよくある間違い | Yakst
原文は2015年8月22日時点のものを利用しており、それ以降に追記、更新されている可能性があります。 本翻訳は原作者の許可を得て公開されています。 Thanks for GreyCat! このページはBashプログラマーが陥りがちなよくあるエラーについてまとめました。以下の例は全てなんらかの欠陥があります。 クオートをいつも使い、どんな理由があっても単語分割を使わなければ、多くの落とし穴からあなた自身を守ることができます！単語分割はクオート表現をしない場合にはデフォルトでオンになっている、Bourneシェルから継承された壊れたレガシーな設計ミスです。落とし穴の大半はクオートされていない展開になんらか関連し、単語分割しその結果をグロブします。 1. for i in $(ls *.mp3) BASHプログラマーたちがループを書く際にもっとも犯しがちなよくあるミスは以下のような感じです。: f
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
