インシデント指揮官トレーニングの手引き | Yakst
[SRE]原文 An Incident Command Training Handbook – Dan Slimmon (English) 原文著者 Dan Slimmon 原文公開日 2019-06-24 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1723日前 Twitterで報告済み 編集 私が Hashicorp で担った最初の仕事のひとつは、社内向けのインシデント指揮官のトレーニング資料を作ることでした。 これは私自身がインシデントへの対処にあたりながら何年ものあいだ肌身に感じてきた、あらゆる類の考えをまとめ上げる良い機会となり、最高に面白いタスクでした。 以下は私の書いたトレーニング資料、ほぼそのままです。 あなたがインシデントレスポンスのポリシーを定義するにせよ、即興でインシデントレスポンスを行うにせよ、お役に立てたら幸いです。
多分あなたにKubernetesは必要ない | Yakst
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はコンテナオーケストレーションの巨人です。世界中で巨大なデプロイメントを動かしています
サポートに来るメールを全社員が読むべき理由 | Yakst
Stuff では「全社員がサポートに送られてくるメールを読むこと」という取り決めがあります。 これにはデータ分析による統計値を眺めるよりも、リアルな消費者の声に耳を傾けむけるべきという主張が込められています。 原文 Why everyone should read support emails – Simon Schultz – Medium (English) 原文著者 Simon Schultz 原文公開日 2019-03-04 原文ライセンス CC BY 翻訳依頼者 翻訳者 msh5 翻訳レビュアー doublemarket 原著者への翻訳報告 1691日前 原文へのコメントで報告済み 編集 Stuff では、原則や組織構造についての取り決めはほとんどありませんが、例外としてとても重要にしていることが一つあります。 全社員がサポートに送られてくるメールを読むこと これまでのプロジェク
GitHubのRails離れと、迫りくるMicrosoft | Yakst
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へ。
人間らしくコードレビューするには(パート2) | Yakst
コードレビューの際に落とし穴にはまらずに、どのようにうまくコミュニケーションをとるか、に関する記事の後半部分です。著者がコードレビューで失敗した実例を元にお互いの衝突を避けるテクニックについて紹介します。 [プログラミング]原文 How to Do Code Reviews Like a Human (Part Two) - Silly Bits (English) 原文著者 Michael Lynch 原文公開日 2017-11-09 翻訳依頼者 翻訳者 taka-h 翻訳レビュアー doublemarket 原著者への翻訳報告 2151日前 メールで報告済み 2149日前 原著者承諾済み 編集 この記事はコードレビューの際に落とし穴にはまらずに、どのようにうまくコミュニケーションをとるか、に関する記事の後半部分です。今回はひどい衝突を避け成功裏にレビューを終わらせるテクニックに焦点をあ
人間らしくコードレビューするには(パート1) | Yakst
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
こんなコーディングは退屈だ！ | Yakst
Enkiのco-founderで最高技術責任者（CTO）であるBruno Marnetteが、エンジニアが仕事に飽きて転職してしまわないよう、社内文化をどのように構築しているのかを紹介します。 開発者として、私は2年以上同じ仕事を続けた事がありません。 転職することは私にとって良いキャリアとなりました。私達の業界では転職を繰り返す事はごく一般的なことです。ところが、以前私が働いていた会社は、私の離職に難色をしめしました。中には、私を必死で引きとめようとする人もいました。しかし、私は仕事に飽きてしまっていたため、残ることはできませんでした。 （免責事項：私は多くのプログラマーよりも楽しいプログラミングの仕事をしていたと思います。仕事を変えることが常に最善の選択とは限りません。） 現在私はEnkiのco-founderで最高技術責任者（CTO）です。会社ではエンジニア文化の構築も行っています。
プログラマにとっての悪夢とは？ | Yakst
本番だけでバグが発生し、ローカルでは再現できないか発現しない。 バグの発生確率が低いが、無視できるほどではない。 バグの原因が、高負荷時にのみ起こる競合状態に影響される。 バグの原因がわからない。 バグの原因になるコードを書いたのは自分ではないが、修正する責任がある立場にいる。コードを書いた人間は退職して会社にいない。 バグの原因となる問題が、99.9%の信頼性を持つどこかのライブラリーで、それだけに最後に確認するところだった。 多数の人間がデバッグしようと何年も頑張ったが、誰も成功しなかった。 何年にもわたって実行した後にのみ起こる論理的エラー。 デバッグには自分の何も知らない分野での経験が必要。 バグの修正のスケジュールに余裕がない。 自分の首がかかっているのでバグを無視できない。 Stack Overflowがダウンしている！ Stack Overflowに行って自分が答えが欲しいと
マイクロサービス時代のHAProxy | Yakst
マイクロサービスのアーキテクチャでシステムを開発すると、サービス間の通信を効率的に管理する方法が必要になる。この問題を解決するためにHAProxyを使う一例を提示する。 「マイクロサービス」は、この10年でもっとも興味深いアーキテクチャーのスタイルを表す言葉として、使い散らされている最新のアーキテクチャーバズワードでしょう。 マイクロサービスとは？ Martin Fowlerの定義によれば以下のようになります。 要するにマイクロサービスというアーキテクチャーのスタイルは、それぞれが独自のプロセスで動きHTTPリソースAPIなどの軽量なメカニズムでコミュニケーションを取り合う小さなサービスの形をとったひとつのアプリケーションを開発していくというアプローチです。これらのサービスは、ビジネス上の機能を中心に作られ、完全に自動化されたデプロイの仕組みによって、別々にデプロイできます。これらのサービ
GitHub : ノマドなエンジニア達とRubyをスケールさせる | Yakst
GitHubの技術ディレクターが語る、GitHubのインフラの特徴と、社員の6割がリモート勤務という社風、Hubotを使った協力的かつ新しい働き方。 Sam Lambertは、2013年にGitHubの最初のデータベース管理者として入社し、現在はGitHubの技術ディレクターを務めています。このインタビューで彼は、今や1000万以上のユーザと2500万以上のプロジェクトを誇るサービスが、比較的シンプルな技術的スタックの上でどのようにスケールし続けてきたのかを考察しています。また、自作のパワフルなチャットボットであるHubotを使ってコラボレーションしつつ、従業員の約6割がリモートで働いているという、GitHubの大規模なオフィスレスな仕事環境についても触れています。 SCALE: 私としては、GitHubはテクノロジーのユーザーというよりは主にテクノロジーの提供者であると思っていますが、そ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
