Twitter での6年間 #8｜Satoshi Nakagawa
(Twitter での6年間 7 からの続き) これ以後は、新アーキテクチャプロジェクトが長期間続くので、大きな変化はなかったと思う。 なので、この話はいったんここで筆をおくことにしたい。 ぼくは、今年3月に Twitter を辞めることにした。もともと新しい物事を学ぶことが好きなので、あまり同じ環境に長くいるのには向いてなかったのだと思う。それでも6年間やってこれたのは、すばらしいマネージャーや同僚にめぐまれたことが大きいし、ぼくが Twitter というサービスをすごく好きだったからだと思う。 Twitter という会社では、優秀なエンジニアやデザイナがユーザーのためになるように日々プロダクトを開発し続けている。これからもユーザーとして便利に使っていこうと思う。
Twitter での6年間 #7｜Satoshi Nakagawa｜note
(Twitter での6年間 6 からの続き) Apple のイベントからしばらくすると、テックリードから提案があった。ぼくがデモ用に作ったライブラリの設計もコードもきれいで見通しがいいので、そのライブラリをアプリ本体に組み込んで、既存のコードを置き換えてはどうかということだった。ぼくはその提案には反対だった。既存のコードによほど大きな設計ミスがない限り、同じ要求を与えれば同じコードができあがる。ぼくの知る限り、既存のコードに大きな設計ミスはなかった。ぼくは、まずゴールとなる新アーキテクチャーを設計し、既存のコードを徐々に置き換えていくことでゴールに近づけていくインクリメンタルアプローチを提案した。既存のプロモートツイート関連のロジックを新しいコードベースに意味もなく移植したりすることで問題を起こしたくなかったのだ。マネージャーや他のエンジニアたちも同意見で、新アーキテクチャプロジェクトを
Twitter での6年間 #6｜Satoshi Nakagawa｜note
(Twitter での6年間 5 からの続き) 2014年3月、グリーンカード、つまり永住権の申請プロセスをはじめることにした。そのときぼくは H-1B ビザで働いていたのだが、このビザには6年の最終期限がある。2010年10月からなので期限まで残り2年半しかなかった。一度期限が切れてしまうと、基本的には国外に出ていかなければいけなくなる。H-1B で働いていてこれからも US で働きたいと考える以上、グリーンカードを取得する必要があるわけだ。 6月の WWDC で、iOS 7 にシェアエクステンション機能が搭載されるとの発表があった。社内でそれを実装するために優秀なエンジニア2人のチームが結成された。この機能はアプリから独立した拡張として別プロセスで動作するので、iOS に標準搭載されている Twitter 連携機能を直接使う必要があった。そこでその問題について詳しいぼくが認証部分をチー
Twitter での6年間 #5｜Satoshi Nakagawa｜note
(Twitter での6年間 4 からの続き) 2013年の春ごろだっただろうか。上のほうの人が、A/B テストをプロダクト開発に活用することを推奨し始めた。A/B テストでプロダクトの方向性を決めていくというのだ。これにつられ、この頃の社内では A/B テスト万能論のような空気さえただよっていた。普通に考えて、A/B テストを数週間走らせてデータをとっても、それが長期的な成功につながるか判断できるはずがない。短期的に数字が上がるからといってユーザーの嫌がることを続けていれば、いつかユーザーの忍耐の限界に達してしまうかも知れない。そのユーザーの堪忍袋の状態をどうやって計測できるというのか、など疑問は尽きなかった。 そのころ Growth という大きな部署ができて、従来国際化を担当していた i18n エンジニアリングチームもその下に組み込まれることになった。Growth チームの強い権限のも
Twitter での6年間 #5｜Satoshi Nakagawa｜note
(Twitter での6年間 4 からの続き) そうこうしてるうちにコードネーム H という野心的なプロジェクトがスタートすることになった。最初は Hackweek の1プロジェクトとしてはじまったらしく、複数のタイムラインをスワイプで切り替えられるようにすることで、これまでのタブ UI による固定数のタイムラインではなく、たくさんのタイムラインをユーザーの好みに応じて追加することができるというアイデアだったらしい。このプロジェクトに iOS フレームワークチームのエンジニア全員が投入されることになった。当時 IPO の時期が近づいていたこともありクオリティよりも開発スピードを優先しないといけなかったので、まずレビューを一切なくして各自がコードをレポジトリに直接コミットすることになった。さらに、各機能のチームからの機能追加はメンテナンスブランチに対してのみ許され、しかも最小限に行うようにと
Twitter での6年間 #4｜Satoshi Nakagawa
(Twitter での6年間 3 からの続き) 2013年に入り、iOS 6 の普及率も十分に高くなったころ、同僚のエンジニアから1つの提案がなされた。ツイートビューを作り直そうというのだ。その時点での Twitter for iOS は、iOS の黎明期に Apple が推奨していたように、できるだけビュー階層を減らして描画するようになっていた。たとえば、ツイートビューには一切サブビューがなく、ツイートテキスト、プロフィール画像、ユーザー名、タイムスタンプなどのパーツは直接ツイートビューに自前で描画する設計になっていた。当初はそのほうがパフォーマンス的に速かったからだ。それから数年間の Apple によるハードウェア、ソフトウェア両面での改善の結果、ベンチマークを取ってみるとどうやらその設計はもう古いらしいことがわかった。たとえば画像を表示するときに、自分でビューに CPU で描画するの
Twitter での6年間 #3｜Satoshi Nakagawa
(Twitter での6年間 2 からの続き) 秋になると、上のほうが「Twitter は mobile centric company になる」という方針を打ち出した。つまり、それまではずっとウェブ中心の会社だったのを、これからはモバイル中心にシフトしていくという決意表明だ。その方針に従い、新機能を作るときにはまず iOS か Android に実装することが必須になった。もちろんプロジェクトに十分なエンジニアがいれば、ウェブも同時に実装してもいい。だが、これまでのようにウェブを先に作ってリリースしてから、あとで iOS と Android の実装を進めてリリースするということはしないことになった。その後のウェブトラフィックのかげり具合とモバイルユーザー数の伸びを考えると、いい時期のいい判断だったと思う。 そのころ、1人の男性エンジニアが育児休暇で10週間の休みに入っていた。少ししてから
Twitter での6年間 #2｜Satoshi Nakagawa
(Twitter での6年間 1 からの続き) SQLite の導入とモデルレイヤーの刷新がうまくいったあと、ぼくは次のプロジェクトを探していた。何をやれば最終的に一番ユーザーのためになるか。そのときに選んだのは、JSON パーザーの置き換えだった。当時の Twitter for iOS は、YAJL という C で書かれた JSON パーザーをプッシュ形式のインタフェースで使っていた。プッシュパーザーはドキュメントパーザーに比べてピークのメモリ使用量は多少低くなるものの、パフォーマンスが悪くなる傾向がある。プッシュパーザーを使う側のコードは見通しが悪くなりバグが入りやすく、チームにとって頭痛の種だった。それを iOS 標準の NSJSONSerialization に置き換えることにした。Twitter for iOS のコードベースに存在するほぼすべてのモデルクラスの JSON データ
Twitter での6年間 #1｜Satoshi Nakagawa
2012年1月、Twitter の iOS チームに7人目のエンジニアとして入った。 たまたま最初の週が Hackweek だったので、通常の仕事は一旦停止。なんでもやりたいことをやっていいらしい。入ったばかりで何もわからない状態だったので、ぼくのメンターのテックリードがやっていた Twitter for Mac の多言語化を手伝うことにした。水曜にパッチをマージしてもらって、ぼくの担当部分は完了。その後は次週から始まる通常営業に備えてコードを読み始めた。 次の週からは通常のサイクルが始まった。毎朝スタンドアップミーティングがあり、各自の仕事の進み具合を他のメンバーと共有する。前職までは同僚がほぼ日本人ばかりだったので英語で仕事をしたことがなく、聞き取りがうまくできなかったのを覚えている。 この日からさっそく Twitter for iOS のユーザーとして気になっていた問題を直し始めた。
Presto at Twitter
The document discusses the evolution and deployment of Presto at Twitter, highlighting its selection over other technologies due to its high maturity, customer feedback, and community support. It outlines the integration challenges, monitoring, log collection, and authorization issues faced during the transition from alpha to production, along with the adjustments made to improve stability. Future
Netty 4 at Twitter: Reduced GC Overhead
At Twitter, Netty (@netty_project) is used in core places requiring networking functionality. For example: Finagle is our protocol agnostic RPC system whose transport layer is built on top of Netty, and it is used to implement most services internally like Search TFE (Twitter Front End) is our proprietary spoon-feeding reverse proxy which serves most of public-facing HTTP and SPDY traffic using Ne
Introducing practical and robust anomaly detection in a time series
Introducing practical and robust anomaly detection in a time series Both last year and this year, we saw a spike in the number of photos uploaded to Twitter on Christmas Eve, Christmas and New Year’s Eve (in other words, an anomaly occurred in the corresponding time series). Today, we’re announcing AnomalyDetection, our open-source R package that automatically detects anomalies like these in big d
はじめの言語の賞味期限 - Kato Kazuyoshi
ライブドアブログの PSGI 化の話 は良いはなしだと思う。一方で、私はあんまり Perl が好きじゃないので、10年にわたって生き続けた Perl アプリケーションが、次の10年にむけてアップをはじめているのは、ちょっとしたホラーでもある。 Twitter と Ruby と JVM ライブドアブログが、将来に向けて mod_perl から PSGI + Starlet にかえたように、将来に向けてプログラミング言語をかえる人達も存在する。最近の事例で有名なのは、Twitter の Ruby から JVM 言語群への移行だろう。 OSCON Java 2011 の Twitter: From Ruby on Rails to the JVM では、JVM への移行に至った理由として Ability to handle server workloads A real concurrency
Zipkin, from Twitter
Architecture These are the components that make up a fully fledged tracing system. Instrumented libraries Tracing information is collected on each host using the instrumented libraries and sent to Zipkin. When the host makes a request to another service, it passes a few tracing identifers along with the request so we can later tie the data together. We have instrumented the libraries below to trac
Raffi Krikorian, Twitter Timelines at Scale
The reality of most large scale data deployments includes storage decoupled from computation, pipelines operating directly on files and metadata services with no locking mechanisms or transaction tracking. For this reason attempts at achieving transactional behavior, snapshot isolation, safe schema evolution or performant support for CRUD operations has always been marred with tradeoffs. This talk
『QCon SF参加レポート（前編）〜Twitter/Facebook/Google〜』
QCon SF参加レポート（前編）〜Twitter/Facebook/Google〜 | サイバーエージェント 公式エンジニアブログ
Twitterのスケーリング，新たなピークへ
多くの人々にとってTwitterは，必要不可欠なコミュニケーション手段になった。人も企業も毎日，ますます広く，深くTwitterを利用する現在，そのスケーラビリティはまさに我々すべてにとっての関心事である。今月初めにTwitterは，143,199ツィート/秒という新たなピークロードを経験した上で，中断することなくそれを処理した。現状の定常値である5,700ツィート/秒に比較すると，これは非常に大きな値だ。プラットフォーム技術担当VPのRaffi Krikorian氏は新記録をブログで報告すると同時に，この新たなトラフィックレベルにスケールするために同社が実施した技術的変更について振り返りを行った。 ３年前の2010年，ワールドカップ関連のアクティビティによる 2,000ツィート/秒というピークが引き起こした，Twitterの安定性に関する大きな問題が，同社にシステムの再構築の必要性を認識
New Tweets per second record, and how!
Recently, something remarkable happened on Twitter: On Saturday, August 3 in Japan, people watched an airing of Castle in the Sky, and at one moment they took to Twitter so much that we hit a one-second peak of 143,199 Tweets per second. (August 2 at 7:21:50 PDT; August 3 at 11:21:50 JST) To give you some context of how that compares to typical numbers, we normally take in more than 500 million Tw
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
このページを見るには、ログインまたは登録してください
QCon New York | Schedule | June 15-19, 2020