世間が covid-19 の感染に震えるなか子が frozen-13 すなわち Frozen に七年遅れで罹患してなにかと Let It Go を聴きたがる。親として一緒に歌えないと色々と都合が悪い（というか歌えると色々都合が良い）ので覚えようと繰り返し聴いてみたけどまったく覚えられる気配なし。

歌ってどうやっておぼえるんだっけ？というか自分は歌を覚えたことがあるのか？すくなくとも 10 年以内、下手すると 20 年以内にはないような気がする。カラオケとか嫌いだし・・・。繰り返し聴いてる歌のサビくらいはちょこっと歌えるかもしれないが、そういう水準ではないのだよ。親の威厳をかけて Let It Go 全部歌う必要があるのだよ。

"let it go lyrics" などと検索すると歌詞のテキストが見つかるので、こいつを紙に印刷して壁に貼ろうかと一旦 Docs にコピーする。この感覚なんとなく覚えがあるな・・・とおもったアレだな。英語の shadowing. 印刷するのはやめて画面に Docs を表示し、ちょっとずつ再生しては一緒に歌ってみたり、再生しないで歌ってみたり。昔々にピアノの練習をしてた感覚にも似ている気がする。ほとんど覚えてないけど。とはいえ概ね shadowing である。

そしてあたりまえだが昔より英語力だけは高まっているので若干トリッキーに単語を繋いだり音が消えたりする部分があっても歌の音声と歌詞の相関を理解できる。英語やっててよかった気分をすごい久しぶりに味わえた。

たまに英語の勉強に洋楽を勧めてるのをみるけど、気持ちはわかるような、割と難しい気もするような。まあ今は歌詞の入手も音楽探すのもすごくラクだし、どんな歌もそのへんの音声教材よりは短いし上達した時の嬉しさは歌の方が上だし、いいのかもしれない。Let It Go を洋楽に数えていいのかはさておき。

それにしてもこの「覚える」訓練は子が生まれてからすっかり遠ざかっていた。久しぶり。ボソボソなりに声を出すせいもあり、普段使っていない脳の部位が活性化する（ポップカルチャー的な用法です）かんじがちょっと気持ち良い。15 分とかのそれなりに短い時間でも練習できるし、親としての歌の練習が英語の shadowing (の簡単なやつ) になっているお買い得感もある。これはしばらくやって良い気がしてきた。覚えないといけない歌も色々あるし。For the First Time in Forever とか Let It Go の倍くらい長いんだけど子が飽きる前に覚えられるのかこれ・・・。

Frozen 以前に英語圏の伝統的なこどものうた、たとえば itch bitch spider とか twinkle twinkle little star みたいな短いやつらもなかなか覚えられなくて長いこと居心地の悪い思いをしていたが、単に時間をとって shadowing 的に練習すればよかったのだな。こいつらは Let It Go と比べるとまったく盛り上がらないが一方ですごく短いのでそのうち練習して良い気がする。Frozen が片付いたらどこかで音源を探してきたい、かもしれない。あとは楽譜も欲しいなあ。

I found myself not to afford to write more, which was the original goal. This time I'm too busy, my mental traffic is so congested that I cannot have another task without harming things I'm responsible for.

Still, there are still some findings:

• I enjoyed writing these. It was fun to write some silly stuff. I love to waste time by these writing attempts. These aren't just affordable now.
• My writing tends to go too sentimental, and it degrades the clarity. I have to find a way to be more dry, concise and critical. Being emotional is easy, but not helping your thinking.
• I still have a lot of errors around articles and tenses. It's a shame. I think a continuous practice like this will help improving. It's disappointing that I cannot do it.

Again, it was fun. And I'm pleased that I can still enjoy writing these random stuff. I'll be back some other day.

These days I feel like that my procrastination is killing me. My chores are stacking up, my work is disorganized, but I cannot take any action and just keep wandering the internet news sites. My instinct is pushing back against the home obligation. At the same time, it feels guilty to spend time to thinking about work without fulfilling the home responsibility. I'm almost paralyzed by this conflict, and it's called procrastination.

Is it a matter of productivity and I should revisit things like GTD? Maybe. Maybe not. I'm depressed? Slightly, if any. Is this a midlife crisis? I don't know. I think I need some soul searching to convince myself.

I just finished the audio version of Susan Fowler's Whistleblower. There are a lot of stunning facts covered. One of such saddening points is that the harassing managers came from Google. So in theory, in a parallel universe, it might be Google. Instead of Uber.

Susan Fowler had the dawning thought that she was prepared to fight against Uber. Although it is true that she is prepared, there is no reason that it has to be Uber. I take it more as a probabilistic outcome. Uber is probably the most likely one, as its bad reputation suggests. However, I cannot think other companies, including my employer are perfectly innocent. There is so much evidences being publicly reported. Here is the latest one. The story has so many parallels to the ones from Uber's,  albeit it's a bit more nuanced.

To be clear, I haven't seen such a misconduct around me. All I have is a vaguely memory of a few rumors in this realms from years ago. I'm not sure whether I in the past years took it seriously. I just don't remember how I reacted. If I hear such kind of things today, however, I'll probably believe it. That's the effect of the movement Susan Fowler catalyzed: I no longer hold the level of the belief to my employer. While I still think it's a good place to work overall, I now consider it as a matter of some probability. The odds are on my side, but it can fail.

And the story tells me that it fails miserably if it does. I don't think I'm able to fight against it. The best I can do is probably just running away. To be honest, I'm not that confident that I even have that ability, to run fast enough.

Even before reading this book, I know I can never be like Susan Fowler and that's totally OK to me. After finishing the book, however, I now don't want to be one of the researchers in Physics department in UPenn, who stayed away from Susan once she became "the "problem". Still, I know I'm probably one of them if it happens. I don't know what I should do, how I can prepare. One thing clear is that it's not about running fast enough.

Whistleblower: My Journey to Silicon Valley and Fight for Justice at Uber: Susan Fowler

むかし Susan Fowler すげえなという話を書いたが、自分の認識は全然甘かったと深く反省した。件のブログはすごいクールにズバッと相手を切ったように見えたがそれは体裁であって、人生を賭けた一撃だったのだね。そりゃそうだよね。自分は「Stripe で楽しくやってる」とか書いたけど、件のブログを書いたせいで PR からめちゃ煙たがられたりして気の毒・・・だがその気の毒さは Uber が反撃のために送り込んできた私立探偵やおそらくインターネットトロルたちからの攻撃の酷さとくらべると些細な問題に見えてしまうという辛さのスケール。なお今は NYTimes の editor になり、思わぬ形で物書きになるという年来の夢を果たしたそうである。

Susan Fowler は home school だったため小中高と学校にいかず、いきなり大学から社会生活（というと語弊があるが）をスタートしている。それは前にインタビューを読んで知っていたが、その背景になる家庭の貧困についてはこの本で初めて知った。自分を white trash の trailer park コミュニティにいたと書いている。序盤の自伝パートはすごくアメリカ的。

その後アイビーリーグであるところの UPenn に編入し物理学の博士号を目指すが、メンヘル同級生の男に絡まれた上に大学に助けを求めたらトラブルをもみ消したい組織の意向によって逆に学校を追い出されドクターを取れない、のみならず、取得したはずのマスターの学位までなぜか抹消されてしまう。Upenn ひどすぎてびっくり。

この体験を通じて組織でのセクハラの扱いに絶望したことが、Uber での戦いへの備えになっている。UPenn での体験に限らずとにかく人生が壮絶すぎ、しかしその厳しさが Uber と戦う強さを育てたのも事実で、戦う定めの星の下に生まれた人なのだなという感想を持たざるをえない。本人の望みとは無関係に。

そんな Susan Fowler も告発ブログを書いて人生を ruin するのには恐れがあり Uber 脱出成功後しばらくは見ないふりをしていたが、ある日夜と霧を読んで覚悟を決めたという下りがあった。ナチの収容所からの生還譚が超絶ブラック企業の告発を促した。なんとも象徴的。自分もデスマのときに読んでいくらかの勇気を得た遠い記憶があるよ。

ところで Susan Fowler を abuse しつづけていた SRE 部門のクソ管理職チェーンはみな Google 出身者とされており、なんというか、がっかり。この会社のどこかにはきっと今でもこういうクソ管理職がいて、自分はたまたまそういうのを引き当てていないだけなのだろうと思うと薄ら寒い。自分はそうしたクソ管理職と戦う準備ができているか。できてないね。ハズレ上司を引いたら感傷とか責任感とかぜんぶ投げ捨てて逃げ出そうという思いを新たにした。

人々を勇気づけようと書かれた本を読んだ感想が「時が来たら逃げ出そう」なのは我ながら救いがたいが、自分にそうした勇敢さはないとこれ以上ないほどはっきり思い知ることができる本でありました。

本人による audiobook の narration は正直あまりうまくないが、時々感極まっている部分などが生々しかった。まあ、自分で読むべき類の本だとは思う。

"I found a secret." She said, after perfecting the taste of her potato salad / mashed potatoes. "To make the taste perfect, you can keep adding salt to the salad while tasting it and stop right before it gets too salty."

"It's like the Microsoft strategy for winning." I responded. "In their days they were said that their strategy was to keep running the business until they won, pouring money into it until competitors gave up." Twenty years ago, it sounded like a perfect strategy. Looking back, however, I cannot help but wondering - How many businesses had they won through this? Maybe their game console deserves the exemplar position. On the other hand, there are numerous counter examples. Think about their server market, which has lost to Linux, or mobile. A lesson from this quick lookback is probably something like this: The words from the winner sounds like the truth but you cannot tell.

That being said, I still have some respect for their commitment to the business continuity. My employer is famous for the business discontinuity. I used to think that it is reasonable, or at least make some sense. I'm not sure anymore. Instead I now believe Microsoft indeed won some ground with the strategy, and it must have paid off overall. It is just not a perfect strategy. There is no such thing.

Of course I didn't keep talking like this. That is not how couples talk. Here is what actually followed: "I think I read the same idea in Salt, Fat, Acid, Heat. I followed that advice for a while, but then noticed that it doesn't work on some occasions: Think about marinated chicken for example. You cannot taste the marinade, especially when you use some alcohol. You have to commit to some recipe, and all you can do is adjust it for each iteration."

In a sense the continuous-tasting secret resembles Agile Software Development, or Lean Methodology. You experiment, measure and adjust. In some cases, this works perfectly. For some others though, this doesn't make a lot of sense. There are software counterparts of the marinade - You have to commit. You can iterate only slowly. The perfection takes time and the early in-market does create the moat. Should you avoid software projects that's hard to experiment with? Now you know this a silly question - It's like asking you should avoid marinade. Fine. You can. But are you happy with it?

Of course I didn't keep talking like this. That's not how couples talk. Here was what actually followed: "But it works perfectly when it does. Give me a scoop. Wow this does taste perfect!"

The mobile app I'm helping to build at work has stunning number of threads and it's been complained by the system health related teams, who are monitoring the apps built in the organization and alert their developers as needed.

One day, an engineer from a neighboring team filed a bug that said "the app has too many threads". I was furious - Their teams is responsible for large part of it, and you just throw the shit to us and ridicule us? What a rude guy. I was furious also because their team has been contributing to the app unstability for a long time and debugging it has wasted a lot of my time. But this kind of them-vs-us mindset never solves any issue, so I just left the bug open and moved on (which doesn't solve any issues either, literary, but at least I don't make it worse.)

People casually create thread pools. In many cases that's not a problem. Each thread isn't that expensive after all. However, if a lot of teams who are developing compute-intensive features come together and put their efforts into a single app, each increment is gradually harming the performance.

How expensive are threads? Talking about thread overhead, the first thing people care about is the memory. Thread does allocate some memory, but the actual number is not clear. In addition to the linux thread, an ART thread is attached to each thread on Android.

In practice though, the thread creation latency becomes more like a problem than the thread heap consumption. The thread creation is serialized, blocking other threads. Even without that, it does a lot at the beginning of the thread lifetime, and its CPU consumption is visible in a startup trace data.

In short: Threads can be heavy in memory, but thread creation latency is more evident harm.

Why do teams create itstheir own thread pool instead of sharing it? Because it's easier. Creating a new one is one liner but passing around thread (or Java Executor) needs some plumbing, especially it crosses the team boundary. Also, it is often safe to have a new one if you need specific semantics, like serialized execution on a single thread. Java doesn't have a way to express these characteristics of an Executor.

If you think a bit more, you would realize that you can implement the serialized semantics over an existing thread pool. Guava's SequentialExecutor implements it for example. People just don't care. Another evidence that people don't care is that everyone creates the thread pool with number of thread as the device's CPU count. What a f*** - Multiply it with the number of thread pools. How does it possibly make sense. (I know it does in a few occasions, but it doesn't help me from the complaints from the other side.)

Java or Android could have had some API that returns an Executor with desired property but is backed by a system-(or process-)wide thread pool. That didn't happen. Whom to curse?

Using native (C++) code in the app makes the situation way worse: There is no obvious way to share threads (or thread pools) between C++ and Java. As a result, same people create separate thread pools in C++ in addition to ones in Java.

The number of thread is now the number of CPU cores multiplied by the number of participating teams plus the number of async-but-serialized executions multiple by the number of programming languages. This is crazy. And that's why the number of threads in our app is crazy large.

Solving this problem is technically trivial: You can build a cross language thread pool library that has thread sharing in mind. But it's more about organizational problems: You have to convince other teams to use that library. You have to demand other teams extra work and complexity. You have to convince that your design is right, eschewing the endless bikeshedding, while you have deadlines, as well as do others.

I don't have energy to go through all of these, but probably I should start building something small and start using it in our own codebase, then go to the rude neighbor, and then pitch it to the research org, etc, etc... Oh god it's depressing. Stop thinking too much and just start small. Later.

Another side of me appreciates where I am - It's much better to have at-least-partially-technical problems stacking up in front of myself, instead of having the need to looking around to find even niche problems to solve, or having a not-at-all-technical problems in front of, but not reachable from, me. For me a hired professional, problems I have are bread and bacon.

As instructed by my primary care doctor, I visited a specialist. I was supposed to have a pulmonary (lung) function test, but the doc said his office doesn't have the facility and I have to make another appointment to the hospital nearby. What a waste of time; What's the point of the specialist?

Without waiting for the test result, he prescribed a long-term control medicine for asthma. Why don't we wait? I was nervous, but kind of expected it. After all, asthma is very a vague categorization and the perception of the patient (me) matters a lot. And I went to the doctor, suggesting I consider myself an asthma sufferer.

Reading through the instruction of the medicine, the long list of the side effects scares me a lot. I hope I don't have to use this, but "long-term" means this is likely to become my lifelong medication. Sigh.

I was fed up with the series of my doctor visits. It's not close (20 min drive) and their office work is far from efficient. My primary care doctor/provider (PCP) hasn't shown up after my very first visit but only her subordinate NPs do. The specialist today was as blunt as I almost took it as an arrogance. I hate all of these.

My spouse has her PCP in a big hospital. It has its own strengths and weaknesses. One strength over my current mediocre small medical center is the streamlined services and the doctor's average quality of the service. The drawback is the long queue of appointments. Last week I asked her how long she had to wait for the possible next appointment. The closest date, it turned out, was about a month away. I'm not sure that is a good option. Even though my current situation is messy and has tedious arrangement, I can at least make an appointment in a few days.

Yet another option for me is the employer-provided medical center. I didn't like the idea of letting my life depending on the employer beyond the paycheck and I didn't have high expectations regardless. However, a friend of mine tried it and told me that he was very much satisfied. According to him, it has a couple of advantages over my current situation: First, the appointment latency is very short, which is a big plus. Also they are located on-site, meaning very close to my office. I would no longer have to pay about an hour plus $20 Uber fee for each visit. It'd be another big win. And so far I don't see any real shortcomings. Probably I should, and will, take a look - Once this asthma round is over.

I didn't like the employee-based services because I feel spoiled and I miss the opportunity to see "Real America." I don't have such an aspiration anymore though. Life is too hard to chase the reality behind the curtain. Now I'm happy to be illusioned.

A teammate came back from his business trip to a remote office in Asia. I found that I've missed him.

Let's call him T.  T is the one I talk the most at work, and he's the one who has interesting topics. My work days were quiet while he was traveling. And that's over.

T traveled to talk to the people below the tech stack. I and T have been talking about adding some corner-cutting private API across the stack for performance optimizations, but we knew too little about the lower layer to make it happen. So the goal of his trip was to figure the plan out with the team who know the needed details.

T went there because this is his project. At the same time, he went there on my behalf because it's also my project. Precisely speaking, it is still not a proper project with substantial commitment, but we want to make it real. T took action for that while I didn't.

T figured it out, but he probably wouldn't make it, that is, he probably wouldn't write any code for that. That's likely to be my part.

That's because ... T is a manager, specifically a TL-M. A tricky part is that he's not my manager. He did the legwork not because his reportees needed it but because he thought it was important for hitting bigger goals, for which I'm also responsible.

I feel bad for him - Probably I should've traveled instead of him, or at least we should've gone together. Or he should be able to work on the whole project by himself. The talk-code separation invites bureaucracy. I hate it, but I realized I just did call it.

I've been frustrated by my lack of the action, but I'm almost giving it up. Why do I have to depend on him? Why does he have to depend on me? Why cannot we pursue these technical challenges from the beginning to the end by each of ourselves?

This question can be easily answered in a way that critics do. But I would reject that. It's just a noise unless being actionable. I'll figure it out. Meanwhile, T has a bumper-sticker message in the intranet profile page. It says: Figure Things Out.

My English ability is declining - This is the feeling I have often these days. Although I've been accepting the fact that my English fluency is not getting better, having decline is different. I have struggled to articulate my engineering points to my teammates, which feels like a real threat.

More practice is needed, probably speaking, but writing is easier. So I decided to start some writing practice: I'll write some random trivial stuff once a day for ten days. I expect it to be plain diary and do not expect it to be worth a read. That aims to be pure practice.

What should I write about today, then? Here you go...

Why is my English fluency declining? There are several contributing factors.

First of all, I have spent no time on explicit English practice. I simply cannot afford it. This isn't great, but it's just a plain fact.

Secondly, I've largely withdrawn from podcast listening for a month. I still listen time to time, but my phone no longer has any podcast app installed. The intention was to spend more time on long-form audio books and my own thinking, and it paid off. However, thinking more to me means thinking in Japanese, and also listening to written English like Audiobooks isn't like listening to people speaking and somehow doesn't have the language gravity podcasts had. It might be matter of taking back podcasts again to my life, but somehow doesn't feel like that today.

Relatedly, I feel myself in a kind of introspective mode these days. I like to be introspective, but it's not a great way to be aware of languages. What's worse, my introspection is solely done in Japanese.

Probably I should spend more time on consuming spoken media, talking to people and thinking in English. I don't feel like that, but there needs to be some balance to hit. This writing project is a not-so-promising attempt to hit the balance.

By the way, have you tried Google Docs' spell checker recently? It's amazing. I wrote the text above in a single path, and pasted it to a gdoc, and edited based on the suggestion. I underscored such edits. I guess I could've spotted some of them if I re-read, but all of t hem. It's worth highlighting - It tells me my misspelling patterns.

Anyway, spell checker. It's worth a shot. (I guess GMail is now using the same checker, but I'm not sure.)

Edit: I've made several edits after the spell checker applied. There are endless mistakes and rough edges.

インドに住むフェミニストのアメリカ人が書いた子育ての本（ひどい要約）"Women's Work" の後半、著者は取材旅行のためはじめて家を空けてたびに出る。夫のために子育てカンペなどを整理しながら「なぜこんなことを」と理不尽に感じ、しかし旅先では「自分はもっと早くからこうすればよかった」とある種の達成感と開放感に浸る。そんな下りがある。

これを読み、自分の奥様にも家を空けて外出してほしいなと思う。何度か水を向けているだが、まったく進展しない。自分にとっても目先ではやや面倒が増えることなので頑張って urge しつづける意欲もなく立ち消えになるのを繰り返している。でも、たぶんそこは頑張って繰り返し背中を押すべきなのだろう。

自分が出張に感じる強い抵抗は、結局そこで生まれる借りを返せる見込みのなさに根がある、気がする。自分はただでさえ、たとえば podcast の録音や出張者とダベる外食などで帰宅を遅らせ、奥様に負担をかけている。つまり細々とした貸しが積もっている。しかしそれを返すことができない。返せない借金がある身で更にでかい借金（出張）をするのは気が重いので出張から逃げてしまうが、これは明らかにキャリアを損ねている。友達と遊びに行くとかも同じ理由で難しい。つまり自分が必要に応じて出張とかをするためには、奥様に旅行とかに行ってもらう必要があるのである。別にいいよとかいうけど、借金踏み倒すしか選択肢がない倫理的イヤさが伝わってない。

なんとなく mortgage の利息を決めるクレジットスコアを稼ぐために車のローンを組む、みたいな理不尽さを感じないではないが、そういう金融的メタファはさておきちょっと遊んで息抜きしたり人間関係を回復したり自分のことを考えるまとまった時間をとったりしてくれた方が関係性として sustainable に思える。現状には deadlock 的息苦しさがある。信頼を勝ち得てないのではという指摘も有りうるが、別に一通り子の世話をできることはわかっているのだからその点で自分にできることはあまりない。子と自分を信用して出かけてもらうよう強く促す必要があるのだろう。

ロジスティクスの問題として、家に車が一台しかないというのがある。自分は緊急時のため、あるいは平日だったら drop-off/pick-up のために車がいる。奥様が外出に車を使いたいとなると、どちらかが借りるなりタクシーなりで妥協しないといけない。借りた車で長距離でかけなくないという旅行者の思惑と、慣れない車に子供を乗せるところで苦労したくないという留守番者の思惑が食い違う。車くらい借りてくれよ・・・といいたいが、もしそれが本当に blocker なのだとしたら・・・自分が借りた車で送迎なりするのかねえ。まあいいけどロジスティクス的な不自由さはずいぶん増してしまう。が、そういう細部でフリーズしてないでガっと話を進める太っ腹さが求められているのだろう。 車をもう一台買う…のはあまり考えたくない。

もっと無責任に子供おいて遊び行くねじゃーねーとかいって出かけちゃってくれるとある意味ラクなのだが・・・というなんとも歪んだ悩み。

喘息関係で医者に行く手前、軽く予習。CDC のサイトをチラ見したあと、リンクされていた NIH のガイドにも軽く目を通す。

基本的には 1. 診断を受けて薬をちゃんと飲みなさいね 2. 環境要因を排除しましょうね。という話だった。そして NIH 的には 1 がメイン。そして投薬などのガイドラインを読む限り、いまのところ医者は間違ったことは言っていない様子で安心。自分はいまのところ short-term relief の薬しか使っていないが、long term control の薬も受け入れた方がいいのかもしれない。Inhaled corticosteroid の副作用は、割と控えめっぽいし。Oral はやばそうだが。まあしかし、あまり嬉しくはないなあ。環境要因の理解は、なんとなく自分が子供の頃から大きな進歩はないように見える。

そして自分はそれら環境要因の回避をかなり内面化しているのを思い出す。ある時期までは気にしていなかったが、奥さんと暮らしはじめてからというもの自分の神経質さを痛感している。最初のころ奥さんの家に遊びに行ったとき、あまりに possible asthma triggers に溢れていて発作が起こるのではないかと恐怖で気が気でなかった。埃をキャッチする布製品や毛糸製品ばっかりじゃん！やめてくれよ！みたいな。発作がおこることはなかったし、もうだいたい慣れたけど。

布にせよ毛糸にせよ、肌触りがいいから人々は好きなのだよね。一方でこれらは house dust の巣窟になりがちなので、自分は無意識に避けている。カーテンはツルっとした化繊のものを買っていたし、ソファもラグも持たなかった。自分の親が同じ方針だったので特に気にしなかったが、結果として家は殺風景になる。屋内に温かい景観を与えたい人とは意見が衝突しがち。

部屋に置くものに限らず、この喘息トリガーの回避を内面化した態度とそうでない人の衝突は時折おこって困惑する。最近のハイライトは去年のフランス旅行。喫煙者満載のカフェで「ゆっくり過ごす」みたいのは完全な恐怖体験なのだが、そういう感覚は理解されない。

ただ、そりゃ理解できないよなとも思う。他人の恐怖を理解するのは難しい。たとえば被痴漢行為経験者が公共交通機関に感じる恐怖とか、自分はきっと理解できないよね。これは辛抱強くコミュニケーションしていくしかないのだろう。

自分の子は喘息持ちっぽい兆候を見せており、自分は家の現状がもつ悪影響を心配している。しかしこれはまだ顕著化していない問題なので、フェアな形で懸念を伝えるのが難しい。あまり悪化しないといいなと思いつつ暮らしている。

Wunderlist がもうすぐなくなるので行き先を探さないといけない。

主要な使いみちは夫婦共有買い物リスト。条件としては iOS と Android 両対応で、できれば Web もあるとよい。結論としては Todoist でも使うか思っている。しょうじきそんなに好きではないが、ひげぽんも使っているので。（困った時はひげぽんの真似をしろ。これ人生の tips.)

眺めてはがっかりしたアプリたちを記録しておく。

• Microsoft To Do: Wunderlist の公式後釜。出来は良い。しかし自分は Microsoft ID を mess up しがちでトラブルが怖いのと、あとは背後に巨大な Office の影がみえるのに抵抗がある。Microsoft にも Office にも他意はないが、そういう巨大なものに sign up したいわけではないのだよ・・・。じっさい Microsoft To Do のウェブアプリをみると Office への導線はあるが Office から To Do への導線はない。かわりに Outlook Tasks Powered by To Do とかいうのがあって、そうかお前が黒幕か、みたいな気分になる。Outlook にも他意はないが、そういうのはいらないの。自分が大企業の犬なせいで org chart の臭いに敏感すぎるかのもしれない。
• Remember The Milk: まだあったのか！そして 2016 年に大型アップデートをし、ついにアイテムの順序を DnD で並べ替えられるようになったという。これだよこれ！・・・とおもったが、アプリがあまりにもゼロ年代というか肝心の並び替えができない。アホなの。ついでにウェブでは Google Sign-in できるがアプリではできないとか、そういえばゼロ年代世代ってこういう感じだったねーそんで mobile first みたいな標語が持て囃されたんだよねー・・・と懐古してしまった。ログインすると過去に productivity obsessしていた頃の黒歴史 TODO が発掘されたため、そっと削除。さようなら Web 2.0.
• Any.do: 割とよくできていて個人的には好きなのだが、VC money を燃やしつつブレイクできてない感にあふれており、有り体にいうと数年で潰れそうな気配。 奥様にも使ってもらうため、あまり冒険したくない。
• TickTick: アプリの起動が妙に遅いのと、なんとなく没個性なのでパス。いちおう GTask という Android アプリが元らしいので Android が主戦場のはずだが、それにしちゃシャキっとしなくね？

なお Wunderlist とは別に長期的なタスクのトラッキングには Basecamp を使っている。こいつを Todoist に統合できるとよいんだけど、複数のプロジェクトにある TODO を串刺しで一覧できる dashboard みたいのがないと Basecamp は置き換えられないな。

ツール探しは本来楽しいものであるはずだが、めんどくささしか感じない。老化か。

これとは別に自分の TODO を管理するアプリがほしいとぼんやり思っているが、今のところ何も使っていない。なぜかはうまく説明できないけど。これを機に Todoist 使うとするか・・・。

• Vega-Lite: A Grammar of Interactive Graphics

Altair は vega-lite というのをつかっているらしいが、これと Vega の違いがよくわかっていなかったので元ネタの paper を読む。

Vega-lite も Vega もフォーマットが JSON である点は一緒。Vega が低レベルの表現なのに対し、Vega-lite はもうちょっと高位の表現を持ち、その高位の表現から Vega のデータを生成する。Vega-lite をみると、Altair は要するに Vega-lite の Python 表現なのだとわかる。

Vega にしろ Vega-lite にしろ、データを JSON につっこんで JS のライブラリに描画をさせるアプローチ。これによってホスト言語 (ex. Python) 非依存にできる。そして対話性を与えられる。

理論的には良さそうだが、実際には弱点もある。まずでかいデータに弱い。せっかく Pandas がでかいデータを持てるのに、それを JSON に変換すると効率性が失われる。実際データポイントの上限が 5000 個に制限されており、適当に 1000 ずつサンプリングしたヒストグラム用のデータを 6 個つなげるとエラーになったりする。というか昨日その問題にぶつかった。サンプル数を減らせばいいんだけど、そういう制限気にするのかったるいのだよ・・・。データポイントの上限にヒットしていないのに描画中に死ぬこともある。ipynb も無駄にでかくなる。PNG を保存したい場合は Selenium 使ってねとかアホなの？（実際は右クリックで "save image" することもできるが。)更にこの裏返しとして、遅い。

対価として得られるはずの対話性: コードを書いてる身からすると図の上での対話性とか別にいらないのだよね。コードをいじって再描画すればいいので。図の上での対話性は、たとえば The Upshot や Distill などの data journalism みたいな文脈で意味があるのは理解している。D3 とかをやってた研究室発なのでそういう対話的可視化に注力しているのもわかる。でも自分には必要ないし、そのためのコストが生産性に跳ね返ってくるのが厳しい。

一方でブレイクダウンをいい感じにやってくれる高位表現というアイデアの力は、Altair をさわっているとたしかに伝わってくる。こういう気の利いた API を Python ネイティブでバリっと実装したライブラリがほしいなあ。

Python native の気の利いた API というと Seaborn があるわけだが、一旦 Altair をみたあと Seaborn をみるとしょぼい。Altair/Vega-Lite の uniformity は、冗長性はいまいちだけど納得感がある。Seaborn はそれと比べるとだいぶ ad-hoc である。というわけで自分が Seaborn を使うことはなさそう。

まあしばらくは DataFrame/Matplotlib と Altair の間を行ったり来たりします、というかまた SQL 仕事の機会がきたら考えます。

なお paper は Grammar-Based Visual Encoding の歴史を軽くおさらいしており、そこは勉強になった。The Grammar of Graphics はそのうち読みたいと思いつつ何年もたっているけれど、これが Tableau の言及になっていたとは知らなかった。

はー可視化とか一度くらい真面目に勉強してみたいもんだわ・・・。

• Friendfluence: The Surprising Ways Friends Make Us Who We Are: Carlin Flora

友達って大事だよね、変な友達もつと大変だったりするけど、でも大切だよね、という本。ベタな自分語りではなくよく取材されて書けれており、そうですねと思いながら読んだ。

自分の人間関係の雑さを反省し考え直すきっかけになればと思って読んだが、友達大事だよね、そうだよね・・・みたいな気分以上のものは特になかった。別に social skill みたいなものを学びたいわけではないが、その手の自己啓発色が強いのを読む方が何かしら provoke されるかもしれない・・・が、またこんど。