スタートアップはいかにしてその活力を失うのか | Yakst
急成長するスタートアップがどうしてそのスピード感や勢いを失ってしまうことがあるのか、その背景にある構造とパターンを筆者の目から解き明かし、それを回避する方法を提案する。John Qian氏のブログ記事の翻訳。 [スタートアップ]原文 How a startup loses its spark (English) 原文著者 John Qian 原文公開日 2023-08-12 翻訳依頼者 翻訳者 doublemarket 原著者への翻訳報告 238日前 メールで報告済み 238日前 原著者承諾済み 編集 ちゃんとしたシードステージのスタートアップでは、エンジニアは業務経験を「夢中だ」と表現する。大きな会社では、得られるのは最良のケースでも「楽しい」程度だ。どうしてこうなってしまうのだろう。これは避けられないのだろうか。 スタートアップを夢中になれるものにするのは何なのかを調べてみよう。エンジ
インシデント指揮官トレーニングの手引き | Yakst
[SRE]原文 An Incident Command Training Handbook – Dan Slimmon (English) 原文著者 Dan Slimmon 原文公開日 2019-06-24 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1723日前 Twitterで報告済み 編集 私が Hashicorp で担った最初の仕事のひとつは、社内向けのインシデント指揮官のトレーニング資料を作ることでした。 これは私自身がインシデントへの対処にあたりながら何年ものあいだ肌身に感じてきた、あらゆる類の考えをまとめ上げる良い機会となり、最高に面白いタスクでした。 以下は私の書いたトレーニング資料、ほぼそのままです。 あなたがインシデントレスポンスのポリシーを定義するにせよ、即興でインシデントレスポンスを行うにせよ、お役に立てたら幸いです。
マイクロフロントエンド | Yakst
原文 Micro-Frontends – Paul Sweeney – Medium (English) 原文公開日 2019-05-26 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1781日前 原文へのコメントで報告済み 編集 あなたの現場には、リビルドに時間がかかって仕方がない、大規模なUIはありませんか？ 複数のチームで作業していてしょっちゅうコードがコンフリクトするなど、インテグレーションに問題が発生することはありませんか？ ひとつのアプリが、あまりにも多くの機能を抱えすぎていませんか？ そんなとき、きっとマイクロフロントエンドが役に立つでしょう。 マイクロフロントエンドは、バックエンドのエンジニアリングにおけるマイクロサービスアーキテクチャの概念を、フロントエンド開発に適用したものです。 しかしUIを複数のフロントエンドへ分割する
責任ある開発者のための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社および原著者の許可を得て翻訳しています
RethinkDBはなぜ失敗したのか | Yakst
つまり、これらのマーケットは小さく、しかもデータベースのマーケット自体よりも小さいのです。とは言え、どれかが他よりもマシになりうるでしょうか？ マネージドホスティングは、本質的にはユーザのためにAWSでデータベースを動かすことで、そうすることでユーザたちは自分で動かす必要がなくなります。これらのサービスを使う代わりになるのは、AWSに自分でデータベースを立てることです。したがって、マネージドなデータベースホスティングサービスが課金できる額には、非常に厳しい上限があることになります。Compose.ioやmLabが、RethinkDBよりも1桁あるいは2桁多いユーザを抱えるMongoDBを提供していることを考えて、マネージドホスティングを提供することには少しの良い点もないという結論を下しました。 Database as a Serviceはマネージドホスティングの更に複雑なバージョンです。D
読みやすいREADMEを書く | Yakst
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
Bashのよくある間違い | Yakst
原文は2015年8月22日時点のものを利用しており、それ以降に追記、更新されている可能性があります。 本翻訳は原作者の許可を得て公開されています。 Thanks for GreyCat! このページはBashプログラマーが陥りがちなよくあるエラーについてまとめました。以下の例は全てなんらかの欠陥があります。 クオートをいつも使い、どんな理由があっても単語分割を使わなければ、多くの落とし穴からあなた自身を守ることができます！単語分割はクオート表現をしない場合にはデフォルトでオンになっている、Bourneシェルから継承された壊れたレガシーな設計ミスです。落とし穴の大半はクオートされていない展開になんらか関連し、単語分割しその結果をグロブします。 1. for i in $(ls *.mp3) BASHプログラマーたちがループを書く際にもっとも犯しがちなよくあるミスは以下のような感じです。: f
より良いプルリクエストのための10のヒント | Yakst
GitHubなどの普及により、プルリクエストを使った開発フローは非常に一般的になった。一方でプルリクエストの品質も色々だ。オープンソースプロジェクトや業務でたくさんのプルリクエストをレビューするMark Seemann氏から、良いプルリクエストを作り、スムーズにマージしてもらうための10のヒント。 原文 10 tips for better Pull Requests by Mark Seemann 良いプルリクエストを作ることには、良いコードを書くこと以上を含んでいる。 プルリクエストモデルは、チームでソフトウェアを開発するための素晴らしい方法になりつつある。チームメンバーが分散している場合は特にそうで、オープンソースの開発だけでなく、企業においてもそれは同じことだ。2010年頃から私は、オープンソースプロジェクトにおいてだけでなく、クローズドソースのソフトウェア開発のために内部的にプル
私が他人のシェルスクリプトから学んだこと | Yakst
私はシェルスクリプトの大ファンで、他人のスクリプトから面白い方法を学ぶのが大好きだ。最近、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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
