急成長するスタートアップがどうしてそのスピード感や勢いを失ってしまうことがあるのか、その背景にある構造とパターンを筆者の目から解き明かし、それを回避する方法を提案する。John Qian氏のブログ記事の翻訳。 [スタートアップ]原文 How a startup loses its spark (English) 原文著者 John Qian 原文公開日 2023-08-12 翻訳依頼者 翻訳者 doublemarket 原著者への翻訳報告 382日前 メールで報告済み 382日前 原著者承諾済み 編集 ちゃんとしたシードステージのスタートアップでは、エンジニアは業務経験を「夢中だ」と表現する。大きな会社では、得られるのは最良のケースでも「楽しい」程度だ。どうしてこうなってしまうのだろう。これは避けられないのだろうか。 スタートアップを夢中になれるものにするのは何なのかを調べてみよう。エンジ

[Python]原文 What's new in Python 3.8? - DeepSource (English) 原文著者 Sanket Saurav 原文公開日 2019-07-26 翻訳依頼者 翻訳者 hiroya 翻訳レビュアー doublemarket msh5 meiq 原著者への翻訳報告 1893日前 原文へのコメントで報告済み 1893日前 原著者承諾済み 編集 はじめに もうすぐPythonの最新バージョンのベータ版が公開される予定です。最終の安定版が利用可能になるまでは、もう少し時間がありますが(リリーススケジュールはこちら)、どのような新機能が追加されているのかを調査することには十分価値があります。Python 3.8 では、言語としての構文の追加、既存の挙動に関しての軽微な変更、そして全体的な速度の改善が追加されています。これらの変更は、以前の3.7のリリースま

原文 Micro-Frontends – Paul Sweeney – Medium (English) 原文公開日 2019-05-26 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1911日前 原文へのコメントで報告済み 編集 あなたの現場には、リビルドに時間がかかって仕方がない、大規模なUIはありませんか？ 複数のチームで作業していてしょっちゅうコードがコンフリクトするなど、インテグレーションに問題が発生することはありませんか？ ひとつのアプリが、あまりにも多くの機能を抱えすぎていませんか？ そんなとき、きっとマイクロフロントエンドが役に立つでしょう。 マイクロフロントエンドは、バックエンドのエンジニアリングにおけるマイクロサービスアーキテクチャの概念を、フロントエンド開発に適用したものです。 しかしUIを複数のフロントエンドへ分割する

安全で、誰にも手頃でアクセスしやすく、ユーザーを尊重した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社および原著者の許可を得て翻訳しています

原文 Give me back my monolith - Craig Kerstiens (English) 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1644日前 Twitterで報告済み 1644日前 原著者承諾済み 編集 どうやら、マイクロサービスの話題の盛り上がりはピークを過ぎ始めているように感じます。「モノリスを150個のサービスへ移行した話」みたいなブログ記事を、週に何度も見かけるようなことはなくなりました。最近よく聞くのは、むしろ「モノリスが嫌なわけなんじゃなくて、性能をいい感じに保ちたいだけなんだ」といった話です。実際に、マイクロサービスをモノリスに戻す移行事例も見たことがあります。 大きな一つのアプリケーションをいくつもの小さなサービス群へ持っていくためには、たくさんの新しいことに取り組まなければなりませんし、かつてはシ

Quoraでの質問に対する回答の翻訳。長らくコンピューターの世界に身を置いている人間からの、ウィットに富んだ回答。 ソフトウェア開発におけるあらゆることは、既に発明されてしまっています。人々は、それを再発見し、あたかも初めて見つけたかのようなフリをしているだけです。あなたがかっこよくて新しいと思ったものはすべて、Smalltalk、HAKMEM(訳注 : MIT AI研究所で書かれた、アルゴリズムや理論などが書かれたメモ。Wikipedia英語版)、Ivan Sutherland(訳注 : Wikipedia日本語版)、Douglas Engelbart(訳注 : Wikipedia日本語版)、初期のIBM、あるいはBell Labsからのコピーでしかありません。 コンパイラーを信じてはいけません。ツールを信じてはいけません。ドキュメントを信じてはいけません。自分のことも信じてはいけません

MySQLがメモリー不足で停止してしまった(OOM Killerに停止させられた)時に確認すべき項目を紹介する。特に、MySQLのバグでメモリリークが起きている可能性がある場合に手がかりを得る方法について。 [MySQL]原文 What To Do When MySQL Runs Out of Memory: Troubleshooting Guide - Percona Database Performance Blog (English) 原文著者 Alexander Rubin 原文公開日 2018-06-28 翻訳依頼者 翻訳者 doublemarket 翻訳レビュアー kakuka4430 原著者への翻訳報告 2299日前 原文へのコメントで報告済み 編集 クラッシュした時のトラブルシューティングが楽しいタスクであったためしはありませんが、クラッシュの原因をMySQLが教えてくれ

自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの