イーロン・マスクに反論したツイッターのエンジニアがクビになった話の流れ。

イーロンマスクとエンジニア及びその周辺の人々のツイートを和訳しました。
174

クビになったツイッターのエンジニアと、イーロン・マスクとの会話の流れを和訳しました。

ツイッター上ではツリーが綺麗に並んでいませんので、面白いツイートを取りこぼしているかもしれません。

問題の発端は、イーロン・マスクのこのツイートでした。

Elon Musk @elonmusk

Btw, I’d like to apologize for Twitter being super slow in many countries. App is doing >1000 poorly batched RPCs just to render a home timeline!

2022-11-14 03:00:58

ところで、多数の国でTwitterが非常に重いことをお詫びします。ホームタイムラインを表示するのに、アプリは酷いRPCをバッチで1000回以上実行しています。

RPCはリモートプロシージャーコールで、他のコンピューター上にある命令をネットワーク経由で実行するプロトコルです。同じコンピューター上にある命令を呼び出すよりも遅くなります。

Sam Pullara @sampullara

@elonmusk The real issue imho is they undid server side rendering and you have to download tons of code just to see a single tweet. Other countries are slow because of the round trips and initial download and not so much from the backend since everyone shares that.

2022-11-14 04:10:10

私見では、サーバーサイドレンダリングをやめたことで、1つのツイートを読むのに大量のコードをダウンロードしなければならなくなったことが本当の問題だと思います。国外にある端末との通信のやり取りや、最初のダウンロードが遅いわけで、共通のバックエンドはそれほどでもありません。

クビになったエンジニア登場

Eric Frohnhoefer @EricFrohnhoefer

I have spent ~6yrs working on Twitter for Android and can say this is wrong. twitter.com/elonmusk/statu…

2022-11-14 06:14:15

TwitterでAndroid対応に6年ほど従事していますが、これは間違っていると言えます。

イーロン・マスクからの直接の返答が来ました。

Elon Musk @elonmusk

@EricFrohnhoefer Then please correct me. What is the right number?

2022-11-14 08:34:51

それじゃあ間違いを訂正してよ。正しい数字はいくつ?

Elon Musk @elonmusk

@EricFrohnhoefer Twitter is super slow on Android. What have you done to fix that?

2022-11-14 08:36:10

AndroidではTwitterは激重です。これを直すために何かしましたか?

Eric Frohnhoefer @EricFrohnhoefer

@elonmusk We have done a bunch of work to improve performance and we found that it correlates well with increasing UAM and Ad spend. Agree, there is plenty of room for performance improvements on Android. However, I don’t think the number of requests is the primary issue.

2022-11-14 10:36:45

私たちはパフォーマンスの改善に色々と尽力しましたし、UAMや広告の増加と関係があることもわかりました。確かにAndroidにはパフォーマンス改善の余地がたくさんあります。でもリクエスト数はメインの問題ではないでしょう。

Eric Frohnhoefer @EricFrohnhoefer

@elonmusk For a cold start of the app there are ~20 requests to load home timeline. Most of the requests are non-blocking and happen in the background. This includes things like images, user settings, hashflags, etc.

2022-11-14 10:37:13

アプリの初回起動時は、ホームタイムラインのロードにリクエストが20回ほど発生します。リクエストのほとんどはノンブロッキングで、バックグラウンドで処理されます。これには画像、ユーザー設定、ハッシュフラグなどが含まれます。

ノンブロッキングとは、関数を呼び出した後に、その関数が終わるのを待たずに次の処理をすることです。通常の関数呼び出しや、RPCでは、一般的にはブロッキング処理になり、関数が終わるのを待つまで次の関数を処理しないので遅くなります。しかしプログラムは簡単になり、バグが減る利点もあります。

Eric Frohnhoefer @EricFrohnhoefer

@elonmusk I think there are three reasons the app is slow. First it’s bloated with features that get little usage. Second, we have accumulated years of tech debt as we have traded velocity and features over perf. Third, we spend a lot of time waiting for network responses.

2022-11-14 10:38:29

アプリが遅い原因は3つあると思います。1つは、あまり使われていない機能が増えすぎていること。2つ目は速度や機能を強化するために、技術的負債が何年も積み重なったこと。3つ目はネットワークの通信を待っている時間が長いことです。

Eric Frohnhoefer @EricFrohnhoefer

@elonmusk One performance focused holdback (go/ddg/7601) showed a causal increase of 40M UAM. For reference Mixed Media only showed +10M UAM. If we want to improve things we need to make tradeoffs that favor performance over new feature work.

2022-11-14 10:39:45

あるパフォーマンスの改善対策(go/ddg/4601)は400万ユーザーの増加に影響しました。参考までに、マルチメディア対策は100万ユーザーしか増えませんでした。もし改善したいのであれば、新機能の追加よりも、パフォーマンスの改善を優先する取捨選択が必要です。

Eric Frohnhoefer @EricFrohnhoefer

@elonmusk Frankly we should probably prioritize some big rewrites to combat 10+ years of tech debt and make a call on deleting features aggressively.

2022-11-14 10:46:27

率直に申し上げて、10年以上の技術的負債と戦うために、大規模なコードの手直しを優先し、機能を積極的に削減するという判断を下すべきでしょう。

1 ・・ 5 次へ