ここ数年で使っているやつが２つ増えたのでふと紹介してみる。
OneTab は開いているタブを全部閉じた上で開いていたタブのリンクへの一覧を一つのタブに表示してくれる。閉じると必要な URL がわからなくなる漠然とした不安からタブは開きっぱなしにしがちだけれど、リンクを一覧に残してくれるので安心して閉じられる。そして必要なものはタブの一覧からよりページにまとまったリストからの方が探しやすかったりする。
TabCopy はページのタイトルを URL をリンクした状態でクリップボードにいれてくれる。ので Blog とかを書くときに便利。リンクは Markdown 形式でもコピーできる。
自分は最近は仕事の journal を Google Docs につけているので、必要な資料へのリンクとかはこれでコピーしたのを貼り付けている。Docs にせよ Bug にせよ社内の URL は human unreadable なのが多いで URL だけ貼っても厳しいのだよね。
以上二点でした。
そういえば社内には内部ツール用の Chrome Extension というのが大量にあるのだが、それよりサイト側を良くしてくれ、と思う。内製ツールは大概 understaffed で不出来。やはり多少カスタマイズに難があっても商用やオープンソースのツールを使うべきと確信を強める昨今。
Pixel Launcher の画面を left swipe すると Google アプリになるのだけれど、ニュース記事とかが表示されており大変 distracting. 自分は情報を overeat したくないのだよ。これを消す設定はないものかと探したら、どうも最近なくなったらしい。まじで？それは困るのでは・・・。
仕方ないので Google アプリを disable... すると Pixel Launcher の検索バーが機能不全になってしまった。辛い・・・。やむなく Pixel Launcher もあきらめ Evie に鞍替え。Pixel Launcher 使ってあげたいのだがどうにもならない。悲しい。どうやら Assistant も Google アプリに同梱されていたらしく、電話を squeeze しても何も起きなくなってしまった...
じゃあどうやって Google 検索するかというと Chrome を使う。Chrome もいらん feed を表示するようになったけれど、そっちはすくなくとも消せるのでちょっとマシといえる。
追記
Pixel Launcher は設定で Google App の表示を disable できた! これでよし。
A pluggable, (mostly) language-agnostic ecosystem for building tools that work with code.
コードの indexer とかを作るためのフレームワークらしい。へえ。Web UI がついてくるというけれど、どのくらいの出来なのかな。
via Kythe
Pixel2 XL を買った。景気付けに。
OnePlus の倍の値段。シラフで買うものではないと思う。Pixel に限らず、この価格帯の Android 端末というアイデアに自分はまだ convince されていない。
一方でたとえば $150 の Moto G を触るとさすがにこれは辛いと感じる。なので高級スマホを使い慣れてから mid range に戻ると辛く感じるのかもしれない。いまいち想像できないが、ヘビーユーザになるとそうした依存が可能になるのだろうか。
まあそういった実用的な適応よりも iPhone のような個人の identity に踏み込む存在になる方が高級スマホのあるべき姿な気がする。なんにせよせっかく買ったので価格なりの価値で convince されたいとは思っている。
電話機の感想。でかい。が、実は自分はでかいほうがキーボードの入力は楽だと気づいた。そして速い。速いのはよい。画面、噂通り斜めから見ると青い。が、あっという間に人間の側が適応した。高級OLEDの違いがわかるスノッブでありたかった気もする。写真。まあまあ。自分はデジカメユーザなので、カメラへの期待値はやや高めかもしれない。Fabric のケースは結構良い。
via Coda is a next-generation spreadsheet designed to make Excel a thing of the past - The Verge
検索会社内にはろくなプロジェクト管理ツールがなく、多数派が sheets と bug tracker となぞのスクリプトみたいなやつでやりくりしている、というのは untold truth すぎて辛い事案なのだけれども、そこから起業してすごい Sheets をつくることにした人々の成果がこの Coda というやつらしい。
個人的には Sheets を拡張して頑張るよりは Pivotal なり Asana なりをおとなしく使おうぜ、と思う。だから「こいつら呪われてるな・・・」が個人的な第一印象。
一方で Dropbox Paper のチェックボックス箇条書きを使ってみると、これはこれでいいと思うこともある。文章、画像、そしてリストを混ぜられる良さはある。なので Docs や Sheet の先に未来があるという主張を完全には無碍にできない。
とりあえず invitation list には申し込んでみた。
Editor がすごい速くなった！これは良いのではないか。またしばらくスマホで書いてあげようか、という気になる。ウェブ版はとにかく遅いし、Electron も遅いからね。
会社で朝食に卵を食べた。ここ半年くらいはシリアルを食べていたのだけれど、オフィスが朝食つきの食堂そばに引っ越したおかげで卵にアクセスできるようになった。
むかしむかし初めて出張でやってきたときも、同じ食堂で卵を食べたと思い出す。そのときは卵以外のおかずも全部とり、パンだって何枚も食べ、満腹で苦しい朝を毎日繰り返していた。異国の地に立つ奇妙な興奮があった。東京オフィスも朝食はでたのだけれど。というかそっちの方が美味しかったんだけど。
その卵が今は日常のつづきになっている。たまにはタンパク質もとるかみたいな。ふとしたとき随分遠くに来たと感慨がある。そんな日はいつもよりがんばって働く気になる。
英語がむずかしくなった・・・。
これまでフランス人とウクライナ人と老人、みたいな構成だったオフィスメイトがアメリカ人の若者になったため。賢い若者はしゃべるのはやくてよくない。いやいいんだけど。インド人や中国人のアクセントに文句を言う人は滑舌の悪いアメリカンな若者と話してから出直しなさい。
そしてどのみち自分は他人の滑舌およびアクセントをとやかく言える立場ではないのであった。
職場の奇妙な VCS に Mercurial がインテグレートされたというので試している。が、わからん・・・
Evolve という extension がコードレビューツールとインテグレートされているのでこれを使えというのだけれど、なかなか難しいなあ。レビューに応じて複数のコミットを手直ししたりするのを助けてくれる拡張。
冷静に考えると Git も同程度に複雑なはずで、よく覚えたものだと思う。まあ Git は cool factor が後押ししてくれた。しかし Mercurial なんて仕事でしか使わないのでいまいち盛り上がらない。Mercurial はもともとシンプルさが売りだったのだけれど、Git の複雑かつ強力な機能と戦うべく色々拡張を重ねた結果複雑になってしまっている感がある。
しかも自分が覚えなければいけないのは plain Mercudrial ではなく社内バージョン管理ツール向けの魔改造 Mercurial. 複雑さもひとしお。しかしこれを使うと複数の連続した変更をレビューに出すことができるというので、がんばって覚える甲斐もあるでしょう。
ちょっと前に monolithic な Java のコードベースを小さいモジュールに分解する仕事をしていた。激しく相互依存しているコードベースを相互依存のないコードに治していく。Painful な仕事だった。
相互依存がクソである点に異論はない。一方でどのくらいクソかはそれほど自明でもない。たとえばよくある「テストができない」という主張。Mock ライブラリが発達した今や割となんとかなる。
小さい manageable な単位 (ライブラリとか) に分解できないという批判。それもまったくそうなのだが、一方でコードが manageable な範囲におさまっている限り存在しない問題でもある。そしてどのくらいのコード量を manageable を感じるかには個人やインフラの出来で差がある。
依存関係を管理するのはプログラマの仕事の大きな部分を占めている。それをサボるのはまったくひどい話だが、一方でサボると捗る可能性も秘めている。現代における monolithic なコードベースの代表たる Rails アプリ。ORM で join するとガンガン依存関係が発生しちゃうけど、それでいいというのが Rails の立場だった。Rails プログラマは依存管理を省ける身軽さを知っている。（あたしの理解雑すぎ？)
Monolith の住人にとって、その身軽さを捨て依存関係の重荷を背負うのは必ずしも納得のいく判断ではない。自分は色々な都合で monolith-to-modules の仕事をやっていたけれど、一部のチームメイトには苦い顔をされていた。いままで相互依存を気にせずガンガン仕事を進められたのに、ライブラリに分割されたせいで依存関係管理のための様々なオーバーヘッドを払わなければいけない。
彼らの感じていたのと同じ frustration を, Rails アプリを microservices にした人々は感じなかったろうか。とくにその開発者が Rails 大好きっ子だったとしたら、コードを Go だの Java だので置き換えようとか言われてもイヤだよね。たぶん。会社やめちゃったりしない?
モジュール化のオーバーヘッドは優れた抽象で払い下げることができることもある。でも優れた抽象とかしなくてよくね？根本にそういう考えがあると、それ以上ふたりは歩み寄れない。
Microservices とか小さなライブラリとか、自分はどちらかというと好きな側にいる。それが "正しいエンジニアリング" だとも思う。でも monolith 勢の言い分も少しはわからなくもないと思うようになったこの頃。
Android 入門してすぐの頃、自分は Android の Service についてまったくよくわかっていなかった。色々誤解していた。その誤解をといたプロセスを思い出しつつ書いてみる。
まず、最初は Service はアプリ (Activity) とは別のプロセスだと思っていた. これは完全に間違いではない (別プロセスにもできる) が、大抵の場合 Activity と Service は同じプロセスで動く。VM がわかれたりもしない。自分がなそんな誤解をしていたのは, Android Chrome が renderer のためにこのプロセス分離 Service を使っているのを見ていたからだと思う。
プロセスモデルの誤解がとけたあとの思い込みは、Service の API 定義には AIDL (かインテント) を使わなければいけない、というもの。同一の VM 内にいるのだから参照を取れば呼べるのだけれど、参照の取得はすごく難しくしてあると信じていた。が、これも誤解で、普通に サービスオブジェクトのインスタンスを持ってきて Java のオブジェクトとしてメソッドコールできる。Local Service とか呼ばれている。プロセスをわけないなら AIDL を使うよりは Java として使ったほうが全然ラク。特に状態の変更を push するみたいな非同期な奴は AIDL だと大変。
プロセスはわかれていないし AIDL も必要ない。でもそれならなぜわざわざ Service なんて仕組みを使うのか。というと、Activity のライフサイクルとは別にプロセスの寿命を指示する仕組みが欲しかったからだよな。たぶん。これはすごい narrow な見方ではあるけれど、多くの実用をカバーしている見方だとも思う。
もちろん他のプロセスから Intents を受け取りたいという要求を満たすための機能でもあるというかそれがメインだし、Intent-based のコミュニケーションはプロセス内でも便利ではある。それはそれ。
自分は Android platform の API をおおむねダメだと思っているが、notification はそんななかよくできているなと思う。
Notification API のよさそのいちは、Android platform のインフラを最大限に活かしているところ。PendingIntent を渡しておくだけでアクションを定義できるのも, RemoteViews で見た目を定義できるのも、Binder や Parceleable といった基盤があってのことだ。普通に View とか Activity とかで UI をつくったりしているだけだと platform の制約ばかりを感じるけれど, notificationn API を使うと platform に助けてもらっている感じがする。
Notification API のよさその 2 は、標準の外観が定義されており、それが毎バージョンよくなっていくこと。Notification の概観は RemoteViews でも定義できるけれど現実にその必要に迫られることは少なく、普通は notification の API 越しにもうしこし高位の情報を指定すると platform が見た目を決めてくれる。おかげで notification drawer には複数のアプリがデータを突っ込んでいるにもかかわらず、割と一貫した UX を提供できている。 毎バージョンその UI がちょっとずつ良くなってるのもえらい. Oreo から入った home screen の notification dot とかも、アプリは特に何もしなくても勝手に表示されるし。まああれが良いアイデアどうかについてはまだ判断できないけれども、platform が空気を読んで色々やってくれるのは良い。
Notification の UI と platform の関係は, Home screen widget のそれと対象的だ。Widget, Android のカスタマイザビリティの象徴みたいに見られていた時期もあるけれど, notification と比べるとそんなに流行ってない。理由は色々あるとおもうけれども、ひとつは Widget アプリと Home アプリ / launcher に UI を任せすぎたせいだと個人的には思う。特に launcher が platform の一部ではないせいで, Widget の UI は OS の進化にあわせて育っていくことができなかった。Home アプリが notification のように platform の一部なら, もっとバンバン API を生やして便利に出来たかもしれないし, UX のいまいちなところも試行錯誤して直せたかもしれない。
たとえば Widget は screen real estate を使いすぎる欠点を克服できてない。Widget のホストが iPhone の dashboard みたいにスクロール可能になっていたらもうちょっと出番があった気がする。まあこの特定のアイデアの是非はともかく、Home アプリが platform の一部になっていないせいで Widget に対して API を提供するのが難しく, fine tuning が進まなかったのは事実だと思う。なんでも customizable にすればいいってもんでもないな、と思うのだった。 Launcher が part of platform だった未来が本当に良いものかといわれるとまったく自信ないけど。
Under the Radar など iOS 系の podcast を聞いていると, アプリ開発者として platform の進化についていく態度について学ぶところがある。Android は fragmentation とかもあっていまいち platform の力を頑張って引き出そうという気が起きにくいけれども, notification をみると少しは platform に bet する人の気持もわかるね。
割れ窓理論にもとづいてプロジェクトやコードベースの hygiene を高く保とうとするのは一般的には良いこととされている。あるとき hygiene が優れないことで知られるプロジェクトで働いている友人に自分は嫌味を言った。あなたのとこのプロジェクトは割れ窓も何もないね。もう窓が全壊して床が硝子の破片でいっぱい。直しようがないじゃん。
友人は屈託なく答えた。そうですね。だから硝子片に怖気づかずズカズカ踏み込んでいって getting things done するんですよ。安全靴履いてくかんじですかね。
たしかに、そういうのってあるよな。
基本的に窓全壊なプロジェクトでは働かない方が良い。うっかり紛れ込んでしまったら逃げ出したほうが良い。ダメなコードやプロセスの裏にはダメな人々がいるものだから。けれど稀に、窓は全壊ながら high stake なプロジェクトというのがある。コードベースの hygiene さ以外はすごくいまくいっているプロジェクト。大きな成果を挙げたいなら安全靴を履いてそんなプロジェクトを戦い抜くのも意味のある選択肢になりうる。そういう前向きな理由以外にも窓全壊の危険地帯でしばらく生き延びる必要に迫られることはある。
自分はそんな安全靴精神を持ち合わせていない。コードベースの中の割れ窓地帯で仕事をすると、ひどいコードへの怒りや苛立ちで精神衛生を損ねてしまう。それ自体が悪いことだとは思わない。ひどいコードへの怒りは、ときにそれを正すための原動力にもなるから。安全靴で仕事をするのに慣れてしまったら、コードの良し悪しとかどうでもうよくなっちゃいそうじゃん。その結末は自分の価値観と合っていない。
High stake な割れ窓プロジェクトは立て直すことがある。関係者がプロジェクトの成功に強い関心を持っているので、できるプログラマや TPM が送り込まれてきたりする。そんな援軍が疲弊したチームを鼓舞し、床の硝子を吹き飛ばし、窓を張り替える。そうなると、割れ窓 High stake プロジェクトはぴかぴかのプロジェクトに生まれ変わる。安全靴は昔話になる。
そんなことは滅多におきない。だから窓全壊のプロジェクトからは逃げた方がいい。ただ直感が何かを告げたなら、そして信じるに値する直感を持っているなら、安全靴を履いて硝子片の海に踏み出せばいい。
それに逃げだせない事情があるときも、安全靴は我が身を守ってくれる。かもね。
今のチームでの自分の働きなどを振り返ってみる。
よかったこと:
- 性能改善という、自分にとって正しいと思える仕事を主にすることができた。ブラウザの internals に詳しいおかげで常人にはできたないレベルのチューニングをできたのはよかった。ニッチすぎて機会は多くなかったけれど。
- Android について一定程度理解が進んだ。特に性能調査の仕方は割と詳しくなった。
- ぐっとこらえてリファクタリングに時間をかけなかった。
- BigQuery に少し親しめた。
- サーバ側を少しだけ触れた。
- チームメイトのパーソナリティを以前のチームより深く知ることができた。（自分が何かしたからではなく、チームの小ささと各人の性格によるもの。）
よくなかったこと:
- Android 愛が芽生えず、結果として理解も期待したほどには深まらなかった。
- 普通のアプリ、結局は締め切りに間に合わせる見積もりおよび計画性と規模の大きさで破綻させない整理整頓の力というあまりに伝統的なエンジニアリング能力、しかもチームとしての力の大きい部分が重要であることがわかり、個人の開発者としてはいまいち熱意をわかせなかった。
- そんな偉そうなことを言いつつ、性能改善の仕事は、成果はぱっとしなかった。あとは性能を継続的にトラックする側にもっと力を注ぐべきだった。基盤が揃ってる状態に spoil されていたせいか、がんばって基盤を作るのはやり損ねた。
- UI の仕事をできなかった。高速化はしたけれど、UX のひとからモックをもらって書き起こすみたいのはやらなかった。まあ正直そんな興味ないんだけど訓練として一回くらいやるべきだった気がする。
- コードの品質を追求しなかった。既存コードの品質に引きずられる中、それを変える努力をしなかった。これはリファクタリングをしない、の裏返しでもあるので仕方ないけれど。
- チームの中で存在感を高める努力をしなかった。なんどかやろうとしたけれど、派生するめんどくさい議論を想像してくじけてしまった。コードの品質を追求したいなら、自分のコードをちゃんとするだけでなくあるべき姿について意見を言ったりしないといけない。そういうときは存在感が必要。ソフトウェア開発、なんだかんだでチームプレイだからね。
- それに関連して、一人プロジェクトは mixed だった。自分が正しいと思うことに注力できたのはよかったが、もうちょっとチームの方針と align していることをやる方がチームとの一体感があってよい気がする。自分の仕事は方針と矛盾はしていなかった（だから仕事を続けられた）が、ぴったり合っていたとも言えない。やる気を出して働くには自分と価値観のあうチームで働くか、自分の価値観をチームにあわせるかが必要。どちらもなかった。まあ価値観はけっこう調整したつもりだけれど、自分もそれなりに stubborn なので。
- 上の２つの結果として、いまいちチームへの所属意識、一体感みたいのが高まらなかった。サービスの方向性みたいのにも無関心になってしまった。会社員が熱心に働きたいならそういうのはあったほうがいい気がする。
- サーバ側, serving だけでなく ingestion とか analytics のコードもどさくさで触りたかったけれど、ほとんど機会をつくれなかった。そういえば一回だけ Flume さわったけどほんと一瞬だったな・・・。
- 育休復帰後の ramp up は完全に失敗した。どうにかする余地があったのかはわからないが。
つぎはもうちょっとうまく振る舞い、熱意をもって仕事ができるようにしたいもんです。
また別のチームに移ることにした。
もともと三年くらいたったら移りたいと思っており、データの仕事ができないかと考えていた。まだ三年はたっていないけれど、育休復帰に失敗していまいちなプロジェクトをやることになってしまい疲弊していたため早めに移動先を探していた。
結果として自分がやりたい類のデータの仕事ができるチームには移れなかった。いくつか興味深そうなものに応募したものの、すべて断られた。面接することもなくレジュメだけで断られ、しかもそのポジションは今も埋まっていない様子なので必要な基準をまったく満たせなかったのだろう。これはちょっとショックだった。レジュメで断らてしまうとちょっと業務外で勉強しておくくらいじゃどうにもならない。
データ感が薄めのポジションや巨大チームの下っ端など、未経験でもなんとかなりそうなサーバサイドの求人もあった。もともとはデータの仕事ができないならせめてそういうサーバサイドの仕事で社内インフラの経験を積もうと考えていたけれど、いざ実際の求人を見るとやる気がおきない。修行なので仕方ないとはいえ、社内インフラ経験のためだけにあと数年たいして興味もない仕事をする様を想像すると、ちゃんと働ける気がしなかった。
オープンソース信者の自分は社内のプロプリエタリなスタックは遅かれ早かれ滅びると信じている。次のステップのため自分が信じていないテクノロジを学ぶ仕事をする。しかも経験者の古株社員がいっぱいいる世界で下っ端からスタート。盛り上がれない。
もうちょっと好きになれそうな仕事がないかと眺めていたら、Android アプリの求人がひとつ目についた。自分はアプリ仕事からは足を洗いたいと思っていたけれど、その求人はなんとなく自分の好みにあっているように感じた。周辺情報を調べた後話を聞いてみると実際悪くはなさそうだった。アプリ仕事をやるはこの一年書いてきた見通しと全く矛盾するけれど、一方で gut feeling というかある種のときめきがある。そして何か面白いことがあるかもしれないという感触は、自分がここ数年失っていたものだと気づいた。
データの仕事がみつからない失望が生んだ幻想かもしれないし、目先の誘惑で将来の roadmap から外れるのはどうかとも思う。一方でわざわざ他所の国まできて働いているのは何らかの excitement が欲しいから。机上の計画に滅私奉公なんてやってられん。と結論してその Android アプリのチームにいくことにした。
結果として自分はもうこの会社でデータの仕事はおろかサーバサイドの仕事すらやることはほぼなくなったと思う。その先の将来も同じ傾向だろう。まあまあ絶望している。分散コンピューティングや機械学習みたいなかっこいい仕事がしたい人生だった。ただしこれは今回絶たれた道ではなく、これまで仕事をつづけてきたなかで少しずつ無意識に捨ててしまった道だとも思う。東京にいたときも、前回の異動でも、サーバサイドに舵を切ることは出来た。でも社内スタックを信じられないからと近づかなかった。結果として自分のレジュメにはサーバサイドやデータの仕事ができない人の匂いが染み付いてしまった。数年後に今回と同じような職探しをしても同じように断られるだろう。経験者がゴロゴロいるなかで未経験なおっさんを選ぶ理由がない。
仕事の外でなんとかする道筋も見えない。いまや業務外に使える時間予算は限られているし、その時間はしばらく新しい仕事に関係する勉強に使うつもりでいる。今のところその中にサーバサイド技術を使う機会は見いだせていない。
だから順当にいけば自分はサーバサイドのできない、データのわからない、クライアント専業プログラマになるだろう。悲しい。いつか目先のやることが落ち着いて、また仕事と関係ないテクノロジをさわる余裕が戻ってくるだろうか。いまのところ期待できない。こうしてキャリアの扉は閉ざされていく。
ある可能性を捨て選んだもうひとつの道で、その犠牲にみあった成果がだせるだろうか。まあがんばります。
この記事は 2017 年には publish しない予定。