安全で、誰にも手頃でアクセスしやすく、ユーザーを尊重したWebを作るためのHTTPヘッダーのプラクティス [UI/UX]原文 HTTP headers for the responsible developer - Twilio (English) 原文著者 Stefan Judis 原文公開日 2019-04-23 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket msh5 原著者への翻訳報告 1950日前 メールで報告済み 編集 This article was originally published on twilio.com, and translated with the permission of Twilio and the author. 当記事の原文はtwilio.comにて公開されたものであり、Twilio社および原著者の許可を得て翻訳しています
Python の可視化ライブラリである Seaborn を利用して表現豊かなグラフを生成するためのテクニックを紹介する記事です。グラフの選択基準としてデータを構成する値が分類のある値かそれとも連続値であるかに注目しており、この記事を通して実践的なテクニックを身につけることができます。 可視化は素晴らしいものです。ですが、優れた可視化の実現は悩ましく容易ではありません。 また、大勢に対して優れた可視化をプレゼンするような場合には時間と労力がかかりますよね。 私たちは棒グラフ、散布図、ヒストグラムの作り方についてはよく知っていますが、それらを美しくすることに対してはそこまでの注意を払っていません。 このことは同僚やマネージャーからの信頼に影響します。今あなたがそれを感じることはありませんが、それは起こることです。 さらに、私はコードの再利用が重要であることを知っています。新しいデータセットに触
trivago社の小規模な開発チームがコンテナオーケストレーターとしてKubernetesではなくNomadを採用することになった経緯と理由について、両プロダクトの特徴やユースケースに言及しつつ紹介されています。 [HashiCorp][Kubernetes]原文 Maybe You Don't Need Kubernetes (English) 原文著者 Matthias Endler 原文公開日 2019-03-21 翻訳依頼者 翻訳者 msh5 翻訳レビュアー doublemarket 原著者への翻訳報告 2129日前 Twitterで報告済み 2128日前 原著者承諾済み 編集 スクーターに乗った女性（イラスト画像の作成元はfreepik、NomadロゴはHashiCorp） Kubernetesはコンテナオーケストレーションの巨人です。世界中で巨大なデプロイメントを動かしています
Stuff では「全社員がサポートに送られてくるメールを読むこと」という取り決めがあります。 これにはデータ分析による統計値を眺めるよりも、リアルな消費者の声に耳を傾けむけるべきという主張が込められています。 原文 Why everyone should read support emails – Simon Schultz – Medium (English) 原文著者 Simon Schultz 原文公開日 2019-03-04 原文ライセンス CC BY 翻訳依頼者 翻訳者 msh5 翻訳レビュアー doublemarket 原著者への翻訳報告 2047日前 原文へのコメントで報告済み 編集 Stuff では、原則や組織構造についての取り決めはほとんどありませんが、例外としてとても重要にしていることが一つあります。 全社員がサポートに送られてくるメールを読むこと これまでのプロジェク
Quoraでの質問に対する回答の翻訳。長らくコンピューターの世界に身を置いている人間からの、ウィットに富んだ回答。 ソフトウェア開発におけるあらゆることは、既に発明されてしまっています。人々は、それを再発見し、あたかも初めて見つけたかのようなフリをしているだけです。あなたがかっこよくて新しいと思ったものはすべて、Smalltalk、HAKMEM(訳注 : MIT AI研究所で書かれた、アルゴリズムや理論などが書かれたメモ。Wikipedia英語版)、Ivan Sutherland(訳注 : Wikipedia日本語版)、Douglas Engelbart(訳注 : Wikipedia日本語版)、初期のIBM、あるいはBell Labsからのコピーでしかありません。 コンパイラーを信じてはいけません。ツールを信じてはいけません。ドキュメントを信じてはいけません。自分のことも信じてはいけません
あるひとりの人がシステムを作ったが故にそのシステムに精通している場合に、最も生産的な開発が行われる。しかしこれは、ひとりの人がシステムの面倒を見ることを超えてシステムが成長する時には矛盾してしまう。 ある状況下において、特定の開発者たちが他の人の10倍生産性が高くなることがあるのはなぜかについて議論してみましょう。 ヒント : 開発者の話ではなく、状況が大きなカギ。 生産性が非常に高いことにウキウキした気分になるのはいつでしょうか。新しい機能が指先からあふれ出てくる時？それは、私たちが関わるツールのことを知り尽くしている時、あるいはもっと決定的に言うと、自分がシステムを変更しつつある時に起こるのです。自分のバックパック、それも自分で詰め込み、そしてひとつひとつの小袋の中まで何年にもわたる旅行を経て調整してきたバックパックの中身を知っているように、システムを知ることです。それぞれのモジュール
.gitconfigファイルに記入するオプションをカスタマイズすれば、Gitをより上手に、便利に使うことができる。著者のGit設定の紹介と、便利な設定の解説。 私はGitが大好きで、いつでもGitを使っています。私は時々、何かについて深く調べてみたり、ドキュメントを一通り読んでみたり、設定を見直してみたりするのですが、今回はGitについてそれをやってみました。私の書いた4番目の技術スタックの改善に関する記事にようこそ！ Gitのすべて 私がコーディングを始めたのは、ただのファイルシステム上でコピーしていたあの辛い日々、そしてチェックアウトに排他的ロックが必要だったVisual SourceSafeを使っていた時でした。それでもその時、ソース管理のコンセプトは私にとって素晴らしいものに思えましたし、家でコーディングする時にはそういったものにアクセスできたらな、と思っていました。 その後カリフ
GitLabのデータベースが消失してしまった事故に関して、PostgreSQLのコミッターであり、PostgreSQLに関するコンサルティング会社2ndQuadrantのCTOでもあるSimon Riggs氏からの分析とアドバイス。 GitLabのみなさん、PostgreSQL 9.6とレプリケーション機能、バックアップの仕組みを使ってくれてありがとう。 今回、GitLabのデータベースが消えてしまったのは残念です。 https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/ 振り返りの分析に対するコメントができるように、こういった情報を公開してくれてどうもありがとう。 レプリケーションの遅延を監視していたのはいいことですし、私としてはとてもうれしいです。4GBのレプリケーション遅延は問題ないこともありますし、
ファイルがどのようなプロセスやユーザなどに使われているのかを表示する lsof コマンドの使い方を網羅的に書いた記事。基本的なものから複数条件を指定したちょっと複雑な使い方まで。 これは、知っておくべきUnixやLinuxのユーティリティーに関するシリーズの3番目の記事です。この記事では、便利な lsof ツールについてお伝えしようと思います。 netcat がネットワーク接続のスイスアーミーナイフ(訳注 : 何でもできる便利なツールの意味)なら、 lsof はUnixのデバッグのスイスアーミーナイフであると言いたいところです。 lsof はUnix哲学に忠実に従っています。ひとつのタスクだけを完璧にこなす、つまり、プロセスによって開かれているファイルの情報を一覧にするだけです。開かれているファイルとは、通常のファイル、ディレクトリー、NFSのファイル、ブロックファイル、キャラクタースペシ
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
私のメガネが年々小さくなり、そして（たぶん）かっこ良くなっているとしても、私は今でも"Nerd Nation"の一員です。したがって私は本をよく読みます。大体年間50冊ぐらい。このゲイツノートでレビューしてきた本の多くは新作が多いです。なぜなら人々は新しい作品に興味を持っていると感じるからです。しかし、実は古くてとても重要だと感じたり価値があると思っていたりする本を読み直す事も好きなのです。スタンフォード大学の心理学者、キャロル S.ドゥエックによる「やればできる!」の研究―能力を開花させるマインドセットの力(原題"Mindset: The New Psychology of Success(2006)")もその一つです。 私が最初にマインドセットに注目するようになったのは、数年前に、私の友人であるネイサン・マイアーボールドと魅力的な教育の再発明について議論していた時の事でした。それはマル
マイクロサービスのアーキテクチャでシステムを開発すると、サービス間の通信を効率的に管理する方法が必要になる。この問題を解決するためにHAProxyを使う一例を提示する。 「マイクロサービス」は、この10年でもっとも興味深いアーキテクチャーのスタイルを表す言葉として、使い散らされている最新のアーキテクチャーバズワードでしょう。 マイクロサービスとは？ Martin Fowlerの定義によれば以下のようになります。 要するにマイクロサービスというアーキテクチャーのスタイルは、それぞれが独自のプロセスで動きHTTPリソースAPIなどの軽量なメカニズムでコミュニケーションを取り合う小さなサービスの形をとったひとつのアプリケーションを開発していくというアプローチです。これらのサービスは、ビジネス上の機能を中心に作られ、完全に自動化されたデプロイの仕組みによって、別々にデプロイできます。これらのサービ
原文は2015年8月22日時点のものを利用しており、それ以降に追記、更新されている可能性があります。 本翻訳は原作者の許可を得て公開されています。 Thanks for GreyCat! このページはBashプログラマーが陥りがちなよくあるエラーについてまとめました。以下の例は全てなんらかの欠陥があります。 クオートをいつも使い、どんな理由があっても単語分割を使わなければ、多くの落とし穴からあなた自身を守ることができます！単語分割はクオート表現をしない場合にはデフォルトでオンになっている、Bourneシェルから継承された壊れたレガシーな設計ミスです。落とし穴の大半はクオートされていない展開になんらか関連し、単語分割しその結果をグロブします。 1. for i in $(ls *.mp3) BASHプログラマーたちがループを書く際にもっとも犯しがちなよくあるミスは以下のような感じです。: f
コマンドラインで素早い操作ができるのは、優れたエンジニアの資質の一つとも言える。そのためのテクニックを集めた珠玉のコマンド集。 原文のコミット bb0c38c0899339e836c37eead4a9534b06c56662 The Art of Command Line メタ情報 基本 日常的に使うもの ファイルとデータの処理 システムのデバッグ ワンライナー 目立たないが便利なもの さらなるリソース 免責事項 コマンドラインで流れるように操作ができるということは、軽く見られたり他人から理解されないスキルだとみなされることもあるでしょう。しかしそのスキルは、明らかにかすぐ分かるようかは問わず、エンジニアとしてのあなたの柔軟性や生産性を改善してくれるものです。ここでは、Linuxでコマンドラインを使う上で便利だと思ったメモやTipsの数々を挙げてみます。あるものは基礎的ですが、非常に詳しい
よく使うコマンドの組み合わせを関数として.bashrcに書いておく事で、色々な操作が簡単になる。筆者の.bashrcとそこに書かれた実用的な関数のサンプル、使用例。 (訳者注) 原文タイトルが「Ten tips for wonderful bash productivity」なので、10のテクニックというタイトルにしていますが、実際には9つしかありません。原文筆者に指摘したところ本人も自覚されていなかった模様？です。悪しからず。 私はいつも自分のbashの環境をいじったり直したりしています。同じような問題に何度も遭遇しては、その度に解決策を探さねばなりません。うんざりして座り込んでしまうまでそれは続きます。お前いつも座って仕事してるだろって？ ええ、でももう皆さんお分かりでしょう。そういう場合は、カスタム関数を作って、それを.bashrcに書き込んで、ログインする可能性のあるマシン全部に入
「プロセスは実行中のプログラムを抽象化したものである」これは私が著書 "Linux Kernel Development" の中で使った比喩だ。バイナリイメージ、仮想メモリ、各種カーネルリソース、関連付けられたセキュリティコンテキストといったものだ。スレッドは、「プロセスの中の実行単位」で、仮想プロセッサやスタック、プログラムの状態だ。言い換えれば、プロセスは実行されるバイナリであり、スレッドはOSのプロセススケジューラがスケジューリングできる最小の実行単位であると言える。 プロセスは1つ以上のスレッドを持っている。シングルスレッドのプロセスでは、1つのプロセスは1つのスレッドしか持っていない。つまり、スレッドはプロセスであると言ってしまえる。実行されるのは何か1つのことだけだ。マルチスレッドのプロセスでは、プロセスは複数のスレッドを持っている。つまり、複数の何かが実行されている。 現代の
私はシェルスクリプトの大ファンで、他人のスクリプトから面白い方法を学ぶのが大好きだ。最近、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
どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。アプリケーションのログを拡張する手助けとなるのがこの「十戒」だ。 新年の私のブログにようこそ。監視とログのモニタリングについてのParisのdevopsメーリングリストでのスレッドに返信を書いた後、長らく心に留めていたブログ記事を思い出した。 このブログ記事は、私のOpsとしての顔をもって、主に開発者向けに書いた。 どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。多くの場合、これは予言をするのと同じようなことだからだ。トラブルシューティング中にどんな情報が必要かを知るのはとても難しい。それが、Opsエンジニアの大きな助けとなるよう、あなたのアプリケーションのログを拡張する手助けとなるこの「十戒」を望んだ理由だ。 1. 自分でログを書くべ
Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか？プロセッサーがどのくらい忙しいか？違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが
ツイ鳥「ジョージ＝コクム」（森に入ったのですが怪物もおらず、ツイ鳥だけがいました。赤字貿易経営者！ @_596_ ツイ鳥は丸く青く、羽のない巨大な鳥の姿をした鳥です。ツイ鳥は多くの目でずっと遠くまで見渡すことができ、侵入者を捜して森を守っていました。ある日、誰かが尋ねました。『もし夜に怪物が来たらどうしよう？』ツイ鳥「ジョージ＝コクム」巷では「毒の鳥」と言われている方いましたがきっと別の鳥です。輸出入業経営者の貿易業者兼ライター。 ツイ鳥「ジョージ＝コクム」（森に入ったのですが怪物もおらず、ツイ鳥だけがいました。赤字貿易経営者！ @_596_ ちょっと参考になる商品の選び方でも。amazonで商品を選ぶサクラレビューよりも「タイトル先頭にブランド名かメーカー名が入っているものがおすすめ。」です。理由はそもそもタイトル先頭にブランド名、メーカー名を入れることは【必須】で破っているやつは規約違
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
