Twitter での6年間 #1

2012年1月、Twitter の iOS チームに7人目のエンジニアとして入った。

たまたま最初の週が Hackweek だったので、通常の仕事は一旦停止。なんでもやりたいことをやっていいらしい。入ったばかりで何もわからない状態だったので、ぼくのメンターのテックリードがやっていた Twitter for Mac の多言語化を手伝うことにした。水曜にパッチをマージしてもらって、ぼくの担当部分は完了。その後は次週から始まる通常営業に備えてコードを読み始めた。

次の週からは通常のサイクルが始まった。毎朝スタンドアップミーティングがあり、各自の仕事の進み具合を他のメンバーと共有する。前職までは同僚がほぼ日本人ばかりだったので英語で仕事をしたことがなく、聞き取りがうまくできなかったのを覚えている。

この日からさっそく Twitter for iOS のユーザーとして気になっていた問題を直し始めた。ユーザーの目に触れる場所や影響が大きそうなパフォーマンス問題などに自分なりにプライオリティーをつけて、毎日3つ以上のパッチを作って順次直していった。これは個人的な考え方だが、US のテック企業で生き残る確率を上げるためには、初動の段階でできる限り早くスキルを周囲に見える形で発揮して「こいつはできるやつだ」と認めてもらうことが大事だと考えている。そのためには期待値を上回るスピードで成果を出さないといけない。いったん信頼を勝ち得たら仕事上の自由度が高くなるし、おもしろそうなプロジェクトに声をかけてもらえることも多くなる。

しばらくすると、ウェブ側で RTL (アラビア語、ヘブライ語などの右から左に書く言語) 対応が始まったので、iOS 側でもそれに合わせて勝手に対応をやり始めた。この頃の iOS ではシステム言語をアラビア語に変えても、ボタンやナビゲーションなどの UI 要素の左右は反転しない仕様だったので、その挙動に合わせてテキスト表示と入力だけを対応することにした。具体的には、アラビア語のツイートに URL や英数字のハッシュタグが混ざってると、URL やハッシュタグの文字の表示順序がおかしくなる問題があったので、Unicode の方向制御文字を必要な場所に挿入することできちんと表示されるようにした。2週間くらい時間をかけて全部のケースに対応できたと判断したので、パッチを作って同僚にレビューをお願いした。ぼくのほかに詳しい人がチーム内にいなかったのでレビューは難航したが、1週間後にマージしてもらえた。リリースの結果、アラビア語圏、とくにペルシャ湾岸の産油国では iOS ユーザーが Android に比べて圧倒的に多いこともあり評判がよかったらしい。ウェブ側の対応と合わせてアクティブユーザー数がはっきり伸びる結果につながった。そして、しばらくするとアラビア語圏の国がアクティブユーザー数でトップランクの一角を占めるようになった。

5月に入ると、次の Hackweek がはじまった。今回は twitter-text という Twitter が GitHub 上で公開しているオープンソースライブラリを iOS に移植することにした。twitter-text は、ユーザーが入力したツイートテキストから URL、@ユーザー名、ハッシュタグなどを抽出するライブラリで、Twitter クライアントの投稿画面に表示する残り文字数を計算するために必要なものだ。その頃は iOS で使える公式実装がなかったので、Twitter for iOS を含め各クライアントが独自実装を持っていて動作もまちまちだった。月曜からはじめて水曜にはテストも含めて実装が終わっていた。マネージャーと相談した結果、社内のオープンソース担当の人にレビューをお願いして無事オープンソースでリリースできることになった。その後、Twitter for iOS にも組み込んで、ウェブ UI とまったく同じ挙動にすることができた。

この頃には英語の会話にもだいぶ慣れてきたと感じるようになった。会話はたぶんパターンマッチなんだと思う。普段ずっと英語で会話してると、同僚が話したフレーズと声がまるごと頭の中に記録される。自分が同じ内容を話すときには、その同僚が話したフレーズと声が頭の中で再生されるからそれを真似るだけでいい。もちろん、英語の音素は日本語の音素よりも種類が多いので、違う音素を発声するための訓練は別に必要だけど。

6月に新オフィスへの引っ越しがあった。その頃、社内で iOS アプリの起動の遅さが問題になっていた。当時一番 CPU が遅いデバイスだった iPhone 3GS 上では、起動から UI を操作できるようになるまで10秒から15秒くらい時間がかかっていた。そこで、以前からマネージャーとの 1 on 1 でこの問題の解決策について話していたぼくに解決が委ねられることになった。当時の Twitter for iOS はアプリがバックグラウンド状態に移行するときに、ホームタイムライン、通知タブ、DM のデータを毎回すべてファイルに書き出していた。次回起動するときには、そのファイルを読んですべてのデータをロードしてから UI を表示する。当然起動時にすべてのデータを一度にまとめてロードするのだから時間がかかる。この問題を解決するためには、クライアント側にデータベースを用意してそこにデータを保存しておけばいい。起動時には最初の画面を表示するのに必要なデータだけを読み出してとりあえず最初の画面を表示するようにすれば、ユーザーがアプリを使いだせるまでの時間は短くなる。SQLite を導入し、データベースのスキーマを定義し、ツイートやユーザーなどのモデルオブジェクトをそれに合わせて書き直した。実際に動かしてみるとかなり起動は速くなったものの、まだまだ最適化の余地はあった。iOS の UI レイアウトを計算するときにボトルネックになるのは、たいていテキストのレイアウト計算だ。そこでツイートのテキストのレイアウト結果もデータベースに保存することにした。その他にもいろいろ最適化をした結果、最終的に iPhone 3GS の最悪のケースでも6秒以内に起動するようになった。iPhone 4 などのより速いデバイスの場合には最悪のケースでも1.5秒しかかからなくなった。チーム内でプレゼンすると、みんな成果を好意的に受け入れてくれたようだった。

(Twitter での6年間 2 に続く)

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

125

Satoshi Nakagawa

#エンジニア 系記事まとめ

noteに投稿されたエンジニア系の記事のまとめ。コーディングTIPSよりは、考察や意見などを中心に。
6つのマガジンに含まれています
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。