Chrome はマルチスレッドなのだけれど、色々辛い。マルチスレッドがらみのバグはよくコードレビューで指摘されるし（気づくのは大したもんだおともうが）、TSAN (Thread Sanitizer: レースコンディション動的検出ツール) ボットが見つけてくれることもある。でも正直 reason-able なコードが書ける気がしない。皆なんで平気なのか謎。まあ平気じゃないから TSAN みたいなものが必要になるわけだけれど。 スレッド同士で間接的直接的に同じ変数を触ってレースが発生する。根本的にはそういうデザインを強いられるアーキテクチャがまずい。なぜオブジェクトをスレッドに縛り付けてメッセージパッシンする作りにしなかったのか。プロセス同士はそうなってるんだから同じことをすれば良いはずなのに・・・。 何がこのまずいデザインを招いたのか。なぜ人々は頑張れなかったのか。社会的な要素が大きいとわか

C++ を書いていると、数年のブランクがあるにもかかわらず妙な安心感がある。自分は間違っていない、というと語弊があるが、自分の間違っている程度を自分はわかっている、というような。コードの質もなんとなく高い気がする。 仕事で Android アプリの Java を書いているときはそこまでの confidence を感じない。そこそこだろうとは感じている。 Python とか JS を書いていると、我ながらこのコードはダメだなと思う。しかしどう良くしていいか検討もつかない。似たような話を前に書いた気がする。 最近のモダンメインストリーム言語、すなわち Go, Swift, Rust, TS とか全然使えない。Kotlin は Better Java として使っている範囲ではそこそこだと思いつつ、Kotlin を活かしている感じはない。 自分は学生時代、 C++ の習得に莫大な時間を費やした。学

これは来年の目標や計画をたてるにあたっての braindump である。 メタな話として、長期的な見通しを考えると同時に目先の仕事のがんばりにも気を配らないとだめだな、というのが今年仕事をがんばってみた上での感想。先のことばかり考えると足元を掬われる。あと人生のフェーズ的に将来の話ばっかりしてる段階でもない。 といいつつ大局的な話をまず考える。 Android の仕事について Android プログラマ、もうだいぶ旬を過ぎた感はある。世間的には Android 固有でハードコアなことをするより iOS と両方できるようになったり React Native なり Flutter なりでクロス OS 開発をしてみたり、あるいは Web のフロントエンドもできますよ、みたいな人が重宝されるフェーズに見える。専門家はまだ必要だが、足りてる。 これは少し前に一部のサーバ側の人が「フルスタック」すなわ

最近はプログラマ向けの技術書を読んでもムカついたりがっかりしたりばかりで、読みたい技術書を探すにも良い技術書評家はいないし、もうプログラマ向け技術書というジャンルは終わってしまったのだろうか。それはなぜか。 ・・・というような不満をもっていたが、考えているうちにこれは概ね濡れ衣に思えてきた。端的にいうと、一線を退いた元おたくが「最近のアニメ（などの得意だったおたく分野）はつまらん」というのと同じ現象が自分に起きているだけな気がする。 キャリアの停滞 まずマンネリ化。自分はキャリア初期のたくさん学ぶことのある時期は終わってしまった。これは雇用という点では良いことだが、学びのある本に出会う確率を下げてはいる。多くの人が「これは必要」と思う話題ほどたくさんの本が書かれる。中身はどれも似通ってくる。新しい読者が必要なものに出会う確率はあがるが、必要なものを読み終えた読者は同じものの繰り返し、すなわ

大統領選が終わった。感想などを書いてみる。 ベイエリアに住んでいる日本人はけっこう動揺しているのではないかと思う。自分たちの多くはビザや永住権で滞在しており、市民ではない。だから移民政策の影響を受ける。Trump 次期大統領の発言を真に受けるなら最悪国外退去や口座凍結もありうる。実際にそういうことが起こる確率は低いと思うけれども、万一起こると人生大打撃なので心配したくなる気持ちはわかる。今までそういう心配は皆無だった。ビザの期限切れはあるけれど、それは deportation とは違うからね。 政策上の不安のほかに、外国人差別の感情がおもったより根強いと思い知らされた薄寒さもある。ベイエリアなんてインド人と中国人が最大勢力みたいな地域。自分が差別される様をいまいち想像できない。でも Trump に投票したのはアメリカ人の約半数。そのすべてが差別主義者ではないにせよ、一方で敗れた Hilla

Courseraで Neural Networks for Machine Learning というクラスをとっており、ようやく半分まで進んだ。CNN, RNN, LTSM という三大知りたかった単語の正体がわかってよかった。後半はなんの話をするんだろう。個人的には応用編として TensorFlow でコードを書こうとなってほしいところだけれど、普通に理論的な話が続くっぽい。 授業の内容。むずかしい、というか超絶不親切。自分のような初学者はビデオをみただけだとまず間違いなく理解できない。だから周辺資料をがんばって読む。クラスのページにアップロードされている論文以外だと、最初は Stanford の 231n および 245d からリンクされている論文のうち関係ありそうなものなどをつまみ食いしていたが、結局 www.deeplearningbook.org の草稿から関係のある章を刷って読む

遅い API にキャッシュをいれて速くしたい。サーバ側の話。 Tracing 結果をながめながら Bigtable の速度に感心する。Read が速い。Write もまあまあ速い。遅いのは Spanner. Spanner が遅いのは仕方ないから、こいつをストレージに使っているバックエンド API の結果は適当にキャッシュして速くしたい。Bigtable を HBase, Spanner を MySQL かなにかに読み替えてもらえばだいたい気分はわかるはず。 自分はサーバサイド要素技術の知識が 10 年前くらいで止まっているけれど、当時の LAMP スタックだとデータはぜんぶ MySQL などの RDB に入れ、遅い部分は memcached や Redis にキャッシュしておくのが定石だったと思う。キャッシュの validity を保つのが面倒だった。 Bigtable/HBase はだ

結局 Presidential Debates は三回とも観てしまった。一回目以降は時間の無駄だった気もするけれど、まあ四年に一回だからよしとしよう。 自分は debates というものがまったく好きではないことを自覚した。Debates は conversation ではない。相手ではなく聴衆に話しかけている。二人並べることに生産的な意味合いがない。二人並べておくと 半リアルタイムで相手を罵れるぶん盛り上がり、聴衆の気は引きやすいだろうというのはわかる。 こうした debates で poll が動くことも多いというけれど、こんな茶番で政局が決まってしまうのはちょっとやだね。 Presidential election debates のおかげで人々が選挙自体に関心を寄せる面はあるとも思う。あと本来なら特に聞きたいとも思わない対立候補の主張を強制的に聞かされるというのも、気分は悪いが視野

通勤用の自転車を盗まれた。自転車置き場には切断されたロックが残されていた。以前は盗難防止のため室内に置いていたのだけれど、引っ越したあとは隣人がみな家の外に置いているのと居間が狭くなったなどのなりゆきで屋外に置いていた。鍵を頑丈なものにアップグレードしておくべきだったが、していなかった。うかつ税。 自分は会社員になってからずっと自転車通勤をしている。運動好きではないが、だからこそ強制的に体を動かす仕組みがないと運動不足になると社会人になる直前の自分は考えた、のだった気がする。結果としてはすごくよい判断だった。我ながら偉い。 会社員になる直前の春休み、そんな話を近所にすむ高校時代の同級生に話したら、それじゃあ良い自転車を買いましょうとサイクリングが趣味の彼は言い、新宿の大きな自転車屋に連れて行ってくれた。はじめて乗ったママチャリよりも高級な自転車は軽く速く、自転車通勤は思っていたよりずっとラ

読んだ(Amazon, Play Books)。結果としては Cython と Numba と Pypy に目を配っておけば良さそうと理解した。Pandas でヘビーに使われている Cython についてある程度わかったのはよかった。思ったより頑張っていた。たとえば C のコードで GIL を外すための構文がある。Python を早くしたくなったら Cython の本を読んでもいいかもしれない。 最終章は engineering blog のエントリをまとめたようなケーススタディ。性能はさておき Python でシステムを作る際のスタックにどういう要素技術を使えるのかちょっとわかったのよかった。自分は Pypy の使いどころがわかっていなかったけれど、 microservices ぽくしてバックエンドに使うとか、CPU intensive なバッチに使うとかはアリかもしれないと思えてきた。

余暇プロジェクトでは PyCharm を使っているものの、ダウンロードしてきたプロジェクトを冷やかすのには重すぎるため、コード読みには VS Code も併用している。 VS Code の Python mode は Microsoft の人がプラグインを書いており、けっこうちゃんと動く。コード補完などの支援にはオープンソースのライブラリを使っていた。Jedi と Rope という二つのライブラリのコピーが plugin のコードに含まれている。Jedi はコード補完, Rope はリファクタリング主体のライブラリらしい。編集はともかく定義へのジャンプが普通に動くのはすごい。コード分析がオープンソースのコモディティになる日がくるとは思わなかった。 自分にとってランダムなコード読みは Emacs の最後の用途だった。でも VS Code で事足りる気がしてきた。VS Code の使い方はもう

静的型の国からくると Python のように型を書かない duck typing は落ち着かず、せめてドキュメント的に型をつけておきたいと感じる。そういえば Python はいつからか型注釈をサポートしたと何かで読んだ記憶がある。調べたところ、3.5 から type hinting という名前で実装されているらしい。適当に真似をして type hint をつけてみる。 すると PyCharm のコード補完が突然まともな候補を表示しはじめた。Type Hinting をつかったコード補完をサポートしているらしい。これはもうぜんぶ型つけちゃいますよ。Python3 のキラー機能と言ってよいのではないか。Docstring に埋め込む書式もサポートしてるというけれど、そういうのは仕事の Closure Compiler だけでおなかいっぱいです。 またひとつ JetBrains への faith

Amazon, Play Books 余暇に Python を使っている都合から読んだ。なんとなくでしか Python を使えない人向けに、もうちょっと真面目に理解すると色々良いことあるよ、というスタンスで書かれた本。自分は書捨てのぶんにはなんとなくの理解でいいと思いつつ、ライブラリなどオープンソースのコードを読むとわからないことが多く苦労していた。この本のおかげでその不安が和らいだ。 トピックの選択が見事。自分が知りたいと思いつつ面倒で放置していた話題を軒並みカバーしてくれている。具体的には Unicode, generator, metaclass. それ以外にも色々知らないことがあった。自分は Python について、今となっては特に新しいところのない退屈な言語という印象を持っていた。「新しいところがない」という部分の印象は変わらないけれど、退屈というほどで もないとわかった。それな

Hackability を損なう Bureaucratic だと思って避けてきた習慣、具体的には可視性をきちんと private にするとか、を見直す時期が来た気がしている。コードレビューで指摘されることが多いし、でかいコードだと可視性を厳しくした方が逆にコードをいじりやすい 。その箇所に依存されている心配がなくなるから。 もともとは「自分のチームしからさわらないコードなら可視性厳しくしなくてもどうせ悪いことされないよコードレビューもあるし」という言い分があった。その一方でいま自分が書いているコードへの変更を将来自分以外の誰かがレビューする可能性はけっこうある。そして「チームしかさわらないコードなら最初は private にしといて必要に応じて public にすればいいじゃん」という主張も等しくありうる。 一番の問題だったテスト可能性については、C++/GUnit では FRIEND_T

仕事の都合で久しぶりに C++ を書く必要があり Emacs を起動したら、しばらく使っていなかったせいか設定が色々壊れている。特に X Window 側からのコピーが動かなくなっており辛い。しばらく我慢していたけれど耐え切れなくなり社内資料を漁ると CLion を使っている一派を発見。ドキュメントの指示に従いいくつか設定ファイルを書くと・・・動いた。 C++ で IDE を使うのは久しぶり。とはいえ JetBrains なので操作はおおむね Android Studio と同じ。リファクタリングもまあまあ動く。コードベースがでかいせいか大量にメモリを使うしあちこち遅さが目につくけれど、それでもコピペできない Emacs よりはいい、というかコピペできても CLion の方がいい。どうも持ってるライセンスの数が足りてないらしく使えない時があるのが難点。でもちゃんと動くから、自分でライセンス

日曜夜から疲労感があり、翌日高熱頭痛でダウン。本日病欠二日目。だいぶよくなったので明日からは出勤できるだろう。 ちょっとがんばって余暇にコードを書いたりすると体調を崩す。体がボトルネックで頑張れないのはつらい。まあ体調を崩すのが概ねいつも頑張った直後なのは事実だとしても頑張ったあと常に倒れるわけではないから、「頑張ると倒れてしまう」というのは一般化しすぎだろう。ただ体調不良はシグナルとして受け取り、しばらくペースダウンの予定。 頑張ると常に倒れるわけではないとはいえ、頑張っている状態をデフォルトにできないのもまた事実だと思う。少しはマージンがないと不意のストレスやワークロードに対応できない。時間と体力が足りない。 様々な形で好きに使える時間が失われていくとき、できることは大きく分けて二つあると自分は暗に考えている。一つは「無駄な」時間をなくすこと。もうひとつは「他の」時間を諦めること。別の

GitHub が GraphQL をサポートしたというニュースに驚き、久しぶりに資料を眺めている。 以前みた時は、クライアント側は嬉しいけれどサーバ側を書くのが大変そうな印象だった。GraphQL サーバのフレームワークたちは、フレームワーク側がクエリを型単位のリクエストに分解する。フレームワークを使う側はデータを取得する "resolver" 一式を個々の型に実装する。 バックエンドが microservices や nosql になってしまっている大規模サービスなら悪くないデザインだけど、RDB から一撃で色々ひっこぬきたい人たちには嬉しくなさそうに見える。実質上 ORM の one-to-many association で lazy evaluation をするみたいになってしまい、性能上の問題もありそうだし。(なおこの問題を N+1 problem と呼ぶことを今更知った。) A

引っ越しに伴う電力会社の住所変更を忘れていたので PG&E に電話をしたら、新しい住所がみつからないという。なにかと思い管理人に確認したところ、電気代含む utility fee は家賃とセットで払うらしい(家賃に含まれていはいない)。PG&E ではない電気会社があるのか、それともアパート全体でまとめて払い、徴収を一元化しただけか。 これは電力自由化と関係があるのかとふと思う。むかしむかし旅行でサンフランシスコのホテルにとまったとき、電力自由化の煽りをうけ停電しまくりでごめんなさい、と張り紙がしてあったのを思い出す。それが Enron の仕業だったと知ったのは随分後のことだった。 前は家賃と電気代とその他の utility を別々に払っていた。それを一撃で払えるようになったのは便利ではある。一方で引っ越すたびに業者が変わるめんどくささもある。ゴミの回収が民間業者なのは、分別にうるさくないの

休暇明け以来いまいち働きがピリっとしない。立て直そうとしばらくさぼっていた Poromodoro を復活してみる。あっさり復調。Porodoro はやれば捗る。知ってる。でもいつの間にかやめてしまい、仕事が滞り、やばいと気づいて復活する、の繰り返し。なぜ続けられないのか。 思いあたる理由はいくつかある。まずしょうもない理由: Pomodoro につかうデバイスの調子が悪い。自分は Wear Tomato という時計アプリを使っているのだけれど、しばらく前から機械の調子が悪く時計自体をつけていなかった。控えの時計があったのを思い出して交換してことなきを得た。ところで Pomodoro はスマート時計のキラーアプリだと思う。嬉しい人は多くないかもしれないけれど、Pomodoro やるなら大変よい。どのスマート時計でも実装がありそうだし。 もうすこし根深い理由。めんどくさくて崩れる。自分は Po

引っ越しにともなう懸念のひとつは自転車通勤体験が悪くなることだった。まえのアパートは Stevens Creek Trail という遊歩道/自転車道から五分くらいの距離にあり、これを走ると通勤自動車ラッシュの中を自転車で並走したり高速道路の出入り口で怖い思いをすることなく会社まで走れた。眺めも良かった。 引っ越しに伴い trail ともお別れか・・・と思って調べたら、実は別の trail を走れることがわかった。前よりも入り口までの距離は遠いし眺めも大してよくない。でも高速道路の入り口は回避できる。めでたい。 Mountain View 市は環境保全や景観維持に厳しく Google などが申し出た敷地拡大などをむげなく断ったりと自分からすると感じのわるい相手だけれど、整備された trails をみると we get what we pay な面もあるな、と思うのだった。 でもまあ Stev