東京から行きやすい温泉地といえば、箱根、湯河原、熱海。もう少し足を延ばして伊香保、草津、鬼怒川。いずれも素晴らしい温泉が湧いていて、私も大好きです。ほんとに。 かわって、山梨。富士河口湖の温泉はなんたって富士山が見えるし、石和もものすごくアクセスの良い温泉地です。あとは「ほったらかし温泉」があまりにも有名だったりして。ただまあ、なんとなく、「温泉に行きたいから山梨行くぞ！」ってモチベーションの人は、そんなに多くない気がするんです。群馬とか栃木とかと比べて。私の肌感覚ですが。 しかしもう、私は全力で山梨の温泉を推したいです。新宿からあずさ乗って、甲府でレンタカー借りちゃってください。甲府にとどまって温泉銭湯めぐりするだけでも十分最高です。すごい良いんです。お湯が！まじで！ ▼サマリ：本記事で紹介しているところ ・甲府から90分以内のハチャメチャな秘湯 └奈良田温泉 白根館、（十谷上湯温泉 源
私は昔から ADHD で昔から発想力や問題解決力はあるのだが、自分自身が何かのスキルを上達することが非常に苦手だ。コンサルとか、エバンジェリストみたいな「人にやってもらう仕事」は得意だが、プログラマとか、ヴォーカリストとか、自分が本当になりたかった職業には何回もチャレンジして何回も失敗してきた。 遠くから見ていると私は何かが出来てるように見えるかもしれないが、冗談抜きで人の３倍ぐらい時間をかけないと成果が出ない。しかも、中途半端にしか完成しない。だから、土日も常に何か努力していないと不安になる。 多分私と同じようなADHDの人は、自分的に努力しても何も達成出来ない辛さを感じているかもしれない。過去にも色々試してみたのだが、４７年生きてやっと自分でも実施できる対策が見つかったので、同じ様なことで苦しんでいる人のヒントになればと思い久々にこのブログを書いてみた。 「自分で何かを作れる人」が長年
(Twitter での6年間 7 からの続き) これ以後は、新アーキテクチャプロジェクトが長期間続くので、大きな変化はなかったと思う。 なので、この話はいったんここで筆をおくことにしたい。 ぼくは、今年3月に Twitter を辞めることにした。もともと新しい物事を学ぶことが好きなので、あまり同じ環境に長くいるのには向いてなかったのだと思う。それでも6年間やってこれたのは、すばらしいマネージャーや同僚にめぐまれたことが大きいし、ぼくが Twitter というサービスをすごく好きだったからだと思う。 Twitter という会社では、優秀なエンジニアやデザイナがユーザーのためになるように日々プロダクトを開発し続けている。これからもユーザーとして便利に使っていこうと思う。
(Twitter での6年間 6 からの続き) Apple のイベントからしばらくすると、テックリードから提案があった。ぼくがデモ用に作ったライブラリの設計もコードもきれいで見通しがいいので、そのライブラリをアプリ本体に組み込んで、既存のコードを置き換えてはどうかということだった。ぼくはその提案には反対だった。既存のコードによほど大きな設計ミスがない限り、同じ要求を与えれば同じコードができあがる。ぼくの知る限り、既存のコードに大きな設計ミスはなかった。ぼくは、まずゴールとなる新アーキテクチャーを設計し、既存のコードを徐々に置き換えていくことでゴールに近づけていくインクリメンタルアプローチを提案した。既存のプロモートツイート関連のロジックを新しいコードベースに意味もなく移植したりすることで問題を起こしたくなかったのだ。マネージャーや他のエンジニアたちも同意見で、新アーキテクチャプロジェクトを
(Twitter での6年間 5 からの続き) 2014年3月、グリーンカード、つまり永住権の申請プロセスをはじめることにした。そのときぼくは H-1B ビザで働いていたのだが、このビザには6年の最終期限がある。2010年10月からなので期限まで残り2年半しかなかった。一度期限が切れてしまうと、基本的には国外に出ていかなければいけなくなる。H-1B で働いていてこれからも US で働きたいと考える以上、グリーンカードを取得する必要があるわけだ。 6月の WWDC で、iOS 7 にシェアエクステンション機能が搭載されるとの発表があった。社内でそれを実装するために優秀なエンジニア2人のチームが結成された。この機能はアプリから独立した拡張として別プロセスで動作するので、iOS に標準搭載されている Twitter 連携機能を直接使う必要があった。そこでその問題について詳しいぼくが認証部分をチー
(Twitter での6年間 4 からの続き) 2013年の春ごろだっただろうか。上のほうの人が、A/B テストをプロダクト開発に活用することを推奨し始めた。A/B テストでプロダクトの方向性を決めていくというのだ。これにつられ、この頃の社内では A/B テスト万能論のような空気さえただよっていた。普通に考えて、A/B テストを数週間走らせてデータをとっても、それが長期的な成功につながるか判断できるはずがない。短期的に数字が上がるからといってユーザーの嫌がることを続けていれば、いつかユーザーの忍耐の限界に達してしまうかも知れない。そのユーザーの堪忍袋の状態をどうやって計測できるというのか、など疑問は尽きなかった。 そのころ Growth という大きな部署ができて、従来国際化を担当していた i18n エンジニアリングチームもその下に組み込まれることになった。Growth チームの強い権限のも
(Twitter での6年間 4 からの続き) そうこうしてるうちにコードネーム H という野心的なプロジェクトがスタートすることになった。最初は Hackweek の1プロジェクトとしてはじまったらしく、複数のタイムラインをスワイプで切り替えられるようにすることで、これまでのタブ UI による固定数のタイムラインではなく、たくさんのタイムラインをユーザーの好みに応じて追加することができるというアイデアだったらしい。このプロジェクトに iOS フレームワークチームのエンジニア全員が投入されることになった。当時 IPO の時期が近づいていたこともありクオリティよりも開発スピードを優先しないといけなかったので、まずレビューを一切なくして各自がコードをレポジトリに直接コミットすることになった。さらに、各機能のチームからの機能追加はメンテナンスブランチに対してのみ許され、しかも最小限に行うようにと
(Twitter での6年間 3 からの続き) 2013年に入り、iOS 6 の普及率も十分に高くなったころ、同僚のエンジニアから1つの提案がなされた。ツイートビューを作り直そうというのだ。その時点での Twitter for iOS は、iOS の黎明期に Apple が推奨していたように、できるだけビュー階層を減らして描画するようになっていた。たとえば、ツイートビューには一切サブビューがなく、ツイートテキスト、プロフィール画像、ユーザー名、タイムスタンプなどのパーツは直接ツイートビューに自前で描画する設計になっていた。当初はそのほうがパフォーマンス的に速かったからだ。それから数年間の Apple によるハードウェア、ソフトウェア両面での改善の結果、ベンチマークを取ってみるとどうやらその設計はもう古いらしいことがわかった。たとえば画像を表示するときに、自分でビューに CPU で描画するの
Microservicesの世界においてService meshは大きなキーワードになった．KubeCon 2017やKubeCon 2018 EUにおいても多くのセッションをService mesh（もしくはその代表格であるIstio）が占めており注目の高さも伺える．もちろんMicroservicesを進めるMercariにおいても導入を検討しており今後重要なコンポーネントの1つになると考えている．本記事ではそもそもなぜService meshという考え方が登場したのか，なぜ重要なのか? その実装としてのIstioとは何で何ができるのか? について簡単にまとめてみる． 参考文献 Service meshを一番理想的な形でサービスに使い始めその考え方を広めたのはLyftだ（と思う）．LyftはIstioのコアのコンポーネントであるEnvoyを開発しそれを用いてService meshを構築
(Twitter での6年間 2 からの続き) 秋になると、上のほうが「Twitter は mobile centric company になる」という方針を打ち出した。つまり、それまではずっとウェブ中心の会社だったのを、これからはモバイル中心にシフトしていくという決意表明だ。その方針に従い、新機能を作るときにはまず iOS か Android に実装することが必須になった。もちろんプロジェクトに十分なエンジニアがいれば、ウェブも同時に実装してもいい。だが、これまでのようにウェブを先に作ってリリースしてから、あとで iOS と Android の実装を進めてリリースするということはしないことになった。その後のウェブトラフィックのかげり具合とモバイルユーザー数の伸びを考えると、いい時期のいい判断だったと思う。 そのころ、1人の男性エンジニアが育児休暇で10週間の休みに入っていた。少ししてから
(Twitter での6年間 1 からの続き) SQLite の導入とモデルレイヤーの刷新がうまくいったあと、ぼくは次のプロジェクトを探していた。何をやれば最終的に一番ユーザーのためになるか。そのときに選んだのは、JSON パーザーの置き換えだった。当時の Twitter for iOS は、YAJL という C で書かれた JSON パーザーをプッシュ形式のインタフェースで使っていた。プッシュパーザーはドキュメントパーザーに比べてピークのメモリ使用量は多少低くなるものの、パフォーマンスが悪くなる傾向がある。プッシュパーザーを使う側のコードは見通しが悪くなりバグが入りやすく、チームにとって頭痛の種だった。それを iOS 標準の NSJSONSerialization に置き換えることにした。Twitter for iOS のコードベースに存在するほぼすべてのモデルクラスの JSON データ
2012年1月、Twitter の iOS チームに7人目のエンジニアとして入った。 たまたま最初の週が Hackweek だったので、通常の仕事は一旦停止。なんでもやりたいことをやっていいらしい。入ったばかりで何もわからない状態だったので、ぼくのメンターのテックリードがやっていた Twitter for Mac の多言語化を手伝うことにした。水曜にパッチをマージしてもらって、ぼくの担当部分は完了。その後は次週から始まる通常営業に備えてコードを読み始めた。 次の週からは通常のサイクルが始まった。毎朝スタンドアップミーティングがあり、各自の仕事の進み具合を他のメンバーと共有する。前職までは同僚がほぼ日本人ばかりだったので英語で仕事をしたことがなく、聞き取りがうまくできなかったのを覚えている。 この日からさっそく Twitter for iOS のユーザーとして気になっていた問題を直し始めた。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
