とある APK の中身, 具体的には AndroidManifest.xml を覗きたいのだが、バイナリ XML をさっと読む良い方法がない。Apktool でもいいのだけれど、得体の知れない jar を業務用ワークステーションで実行するのもねえ・・・
という話をしたら、Android Studio で APK を開けば読めますよと教わる。どれどれ・・・と試す。おお、ほんとだ。これは便利だなー。挙動から判断するに APK Analyzer なるツールがもとになっているっぽい雰囲気。
Computer Vision: Algorithms and Applications. Ch. 3.
半分くらいしかわからんかったな・・・。
特に最後に Markov Random Field の話がでてくるのだが、全然わからん。そして例のごとくわからせるように書いていない。そして人々はまだこれ使っているのだろうか。なんとなく segmentation が代表的な応用っぽいがそれ NN にやられてしまったよね。同時期に出たもう一冊の CV の教科書は learning based の algorithm を中心に扱っているが、そっちの目次にも MRF とか一言もでてこない。MRF の CV への応用を切り開いた第一人者による教科書も一つもレビューがついてない。なんとなく枝葉の予感。読み進めて困るまでほっとこう。
あと wavelets もいまいちわからんかったが、pyramid decomposition の仲間である、という理解が得られたのは良かった。Wavelets, 自分が学生の頃は割りとはやってた印象だったけれども、今はどうなのだろうなあ。
まあわからないのはわからないマークをつけた上で先に進みます。
しかしこの本は不親切かつ概要すぎて通読する気が失われたなあ。もう一冊の教科書なり OpenCV の本なり読む方が得るものがある気がする。興味のあるトピックだけつまみ読みして終わりにしたい。高かったのに sigh だわ。
via Open sourcing oomd, a new approach to handling OOMs – Facebook Code
きみたちは Android か...
LInux-PSI というのは何かとおもったが、これも Facebook にいる Linux ハカーの人がつくったものなのだね。
というものがあるので試してみたが・・・いまいちだった。
基本的には Systrace の UI を C# で書き直しました、みたいなアプリ。Linux では Mono/GTK# で動く。GPU まわりなど Systrace では取れないデータが若干とれるのが売り。しかし UI が厳しい・・・。ゲームとか GPU べったりなアプリを作ってる人ならこの UI に適応するのもアリかもしれないけれど、自分はそのシグナルを Systrace から読めるようなんとか upstream してくれや・・・とおもいつつ退散。
ただ Systrace と比べると UI が軽い気がする。Systrace, そろそろスケーラビリティの上限に達している気がしているのでなんとかしてほしいなあ。そこが extensible かつ素敵な感じになったら Qualcomm もこんな無駄再発明をせず plug-in してくれるかもしれないじゃん。
Snapdragon Profiler, どうやってデータ収集を実装されているのだろうなあ。特にカウンタ系, /proc なり /dev なりのファイルなどを polling しているだろうか。それとも ftrace に必要なデータは入っていて、それを Systrace が解釈できないだけなのかあ。
Systrace ファイルでかすぎてもうダメぽ・・・と社内でつぶやいたところ、最新の Android Studio ならでかいトレースがとれると教わる。おお！と思ったら既存のダンプを開く方法はなさそうなので feature request しとくか、とおもってバグトラッカーをみたら "public に file してね" と書いてあったので public に file してみた.
更に、目先の逃げ道として適当に systrace の要らない行を削るのでもよいというので自分の見なそうな項目を削ったところ、ようやくブラウザが落ちなくなった. まったく...
カメラの画像など Surface を介しプロセスをまたいで流れていくメモリ (buffer) は Gralloc というアロケータで確保される。Gralloc は HAL である。
ところで Android は O ではじまった Project Treble によって多くの HAL が独立したプロセスに追い出された。Binderization という。昔の Windows の COM-fication および Mozilla でおきた反動の De-com-ificaton を思い出すがまあそれはいい。
これが意味するところは Gralloc も binderized で別プロセスに追い出されたということである。マジで？とおもったけど Systrace を睨むとそれっぽいプロセスがいるのだよな実際。無駄にかっこいいなおい・・・。Image の確保開放、微妙に遅いと思っていたがこのせいという面は否めない。
Treble, 資料を眺めると色々思わぬことが書いてある。たとえば above HAL の binder とは別の "binder context" を使って congestion を回避しているという。そしてそのためにカーネルもちょっとかわっている。Systrace で "HwBinder" というトレースがところどころにあるのはなんだろうとおもっていたけれど、それが別コンテクストで動く HAL 用の binder なのだろう。
更に HAL の Binder は binder といいつつ IDL は AIDL variant の HIDL というフォーマットで、AIDL と違い C++ もサポートしている、というか C++ がメインらしい。君たちは IDL コンパイラ二種類サポートしてくのか。それより AIDL 直してくれや・・・。
ところで Gralloc の話にもどると、このひと HAL とはいえ結局中では何をしているのだろう。というと、多くの場合は ION に落ちるらしい。例:
ION は Android がドライバ実装のため Linux に入れた shared memory の仕組み。アプリのレイヤで使う ashmen とは違い、たとえば物理メモリ上で連続した領域を確保したい、みたいなことができるという。LWN にいくつか解説がある。
ION があるならもう Gralloc は HAL じゃなくて AOSP 側で持ち、そのレイヤから直に ION に行けばいいのでは・・・という気もするけれど、Gralloc は最初の頃からあるのに対し ION は GB あたりで入ったらしいので歴史的経緯なのかもしれない。あと上でリンクした Exynos のコードをみると実装固有のフラグを Gralloc のレイヤから ION の下のデバイス固有コードに渡すようなことをしているので、Gralloc のレイヤにフックがあるのに意味はある・・・ような気もするが、基本的には Gralloc の usecase を伝えているだけなのでそれが ION に入ってればよくね？とも思う。どうせ Android 用なわけだから。あとだしの感想ですが。
ION は複数種類のヒープをサポートしている(ion.h). Linux のカーネルが普通に管理している (物理的には page にわかれている) メモリからアロケートする SYSTEM ヒープ、カーネルの起動時に reserve しておく CARVEOUT ヒープ (物理メモリは自動的に continuous になる)、そして DMA ヒープがある。
CARVEOUT はお前は昔のゲーム機か、というかんじでゲンナリするけどまあそういうの必要なこともあるでしょう。 (共存している co-processor を動かす別の OS と連携するとか。) 感心したのは DMA ヒープで、こいつは Continuous Memory Allocator 略して CMA からメモリを確保する。
CMA は名前の通り continuous な物理メモリを確保できるのだが、CARVEOUT のような雑なことはせずカーネルがもっているメモリから必要に応じてアロケートできる。正しい。しかし誰得なのだろうなと思ったら、パッチを書いていたのは Samsung の人だった。エライ。Samsung, 伊達に Android 界の頂点に立ってないなと見直した。
そしてこういうヘンなやつらもちゃんと仮想メモリにマップしないといけない Linux の VMM は大変だね。
ところで Gralloc がメモリを ION から確保するということは、そいつらは userland から普通に map できるということである。つまり GPU に渡すメモリを CPU から触れるのでは? SGI unified memory architecture なのでは? とおもったら O から NDK に AHarewareBuffer という API がたされており、これがまさにそういうクラスっぽい。（そして古いバージョンでもplatform の中のコードを無理やり触っている人たちがいたらしい) べんり! まあ CPU 遅いのでできることそんなになさそうだけど。
なお ION は雑すぎて脆弱だよと主張する ION Hazard という論文がある。Android PoV から ION を理解するのにはこの中の説明が一番わかりやすくてよかった。
ふと調べる。なんとなく Amazon に買収されたと勘違いしていたが、それは噂でおわったらしい。そして shutdown の結果 1,700 人が失業したと書いてある (2012)。おそろしや・・・。
そんなら Fire Tablet はどこの SoC を使っているのだろうか。というと公式資料があった。MediaTek だそうな。Fire Tablet 安くていいなと思っていたけど、さすがに解像度がもうちょっとほしいね。
Via www.oreilly.com. 君はなにをいっているんだ... もう書籍のカタログにすらたどり着けないのだが。一方 www.oreilly.co.jp は昔とかわらず .shtml とか言ってる。どっちがいいというもんでもないけどギャップあるね。
人々が技術書に求めていたものは Manning になってしまったので higher-end/luxurious な商売であるところの conferencing や subscription に pivot した、というロジックは完全に理解できるが、自分とは遠いところに行ってしまった感。
O'Reilly Japan はサイトがショボいのはもうちょっとなんとかした方が良いんじゃないかと思うけど、一方で技術書展みたいなコミュニティに寄っているのは割といい話な気がする。
プログラマ向けの商売は儲からない、という話にも思える。
あとで読むかもリンク from Technical Papers - SIGGRAPH 2018
SIGGRAPH のサイトに論文はないのでタイトルで適当に検索してさがす。
SIGGRAPH 2018 Papers が論文へのリンクをまとめている。
via Richard Szeliski and Session - SIGGRAPH 2018
今読んでる CVAA の著者氏、 Facebook にいるのだね。なにやってなだろうな・・・と Google Scholar をみると patent が多いね。あと 360 Video の手ぶれ補正か。この話 @Scale でやってたけど、この人だったのだなあ。
Ask HN: Favorite note-taking software? | Hacker News という定期スレがあったのに釣られて自分のスナップショットを書いておく。あまり参考になる人はいないだろうけれど・・・。
Accepting Google Docs に書いたとおり、自分は仕事のメモはすべて Google Docs に集約した。ただ以前は一つの Docs にすべてを書いていく ChangeLog スタイルだったのを、ChangeLog 的な時系列 doc とプロジェクト単位の記録用 doc に分割した。ここで言うプロジェクトは適当なまとまりのタスク、くらいの意味。細かいファイルが増えまくるのも困るのでバグ修正などは Bug Scrapbook という doc に Section を作って書き連ね、でかくなってきたら別文書に extract する、といった運用をしている。
前に Google Docs は sync がちゃんと動くのが良いと書いたけれども、もう一つの利点として GSuite のサーチが割と使えるのも良さだと気づいた。困ったらとりあえず GSuite でサーチする。すると GMail なり Groups なり Docs なりで書いたものが見つかる。GSuite 色々言いたいことはあるが search がちゃんとしてるのは面目を保ってる感じがする。
仕事外の記録は Dropbox Paper と Blog を併用している。Dropbox Paper がトータルで Google Docs より良いかは微妙だが、まあ Google 製品ばかりでも面白くないと使っている。たとえば Podcast 用の reading note は Paper. やはり Sync が重要で、会社の昼休みにつけた記録を寝る前に引き継げたりするのがよい。
残りは Blog.
Blog を記録に使うのはイマイチなところもあるが良いところも少しはある。イマイチなところはオフラインに弱いことと遅いこと。ただ Android アプリは offline に対応しているので、自分にとって一番重要な offline usecase はカバーされている。PC もがんばってほしい。そして遅い。これもオフラインの弱さと根は同じ気がする。記録をつけることでなく、文章をウェブに publish するためのツールなのだよな。(といいつつ前に一瞬ためした self-host の Ghost は offline で動くし速いしなか素晴らしかった。でも self-host はしたくないし hosting も高いので諦めた。)
Blog の良いところは、やはり文章を書くには良い体裁だと思うのだよね。雑な箇条書きよりも考えが整理されるし。万一人に読まれると思うと自暴自棄はことは書かない、そして書かないから考えなくなる。自分の潜在的な破滅志向を抑制できてよい。家族持ちが破滅志向よくない。
あと他のメモツールにない大きな利点として blog はスクロールで時系列に記事を skim できる。時系列でスクロールは読み直す手段としてすばらしい。なぜ Evernote とかにないのか謎。
公開する記録としない記録は混在させている。公開するのがデフォルトで、公開しない記録には専用のカテゴリを割りふって弾いている。これはリアルタイムで書いてるブログだと危なっかしくて足枷になるだろうけれど、自分のように年に一回エクスポートして公開する方式だとうっかりの危険は小さい。出す前にざっと眺めるから。
まあブログが特段 note taking に適したメディアだと言うつもりはない。自分は blog というものに多くの時間を費やしてきたせいで思考形態がブログ的になっている、つまり自分がブログというツールの側に適応しているのだと思う。
でもそういうのってあるでしょ。Evernote ユーザは Evernote 的に、Org-mode ユーザは Org-mode 的に、Simplenote ユーザは Simplenote 的に考えているよね。きっと。そういう力があるからこそ、冒頭のスレにいるような人々や自分は謎のこだわりを持ってしまうわけじゃん。
これまで UI の性能をみてきた同僚が「特定の操作の速度が新機種の電話で遅い」というバグをファイルした。よそであった議論をうけてのバグ登録。たしかにその操作はちょっと遅い。しかしその遅さ、たしか別のバグで議論されている HAL の下の遅さが原因だった気がする。どうやって直す気なのか・・・とおもったら、まさに HAL の担当者にそのバグをたらい回して「とりあえず HAL の遅さについて議論してちょ」とコメントしていた。なるほど。
別に責任転嫁をしているわけでなく、その遅さを直すためなら議論を推し進めたり背中を押したりのプチ TL/PM もするという話。自分はこういう他人を巻き込んでなんかやるのが苦手なので、彼はエライな、と思う。
結局、たとえば 「UI を速くする」といった粒度のある仕事をしようとおもったら自分では直せない問題にも踏み込まざるを得ない。特に壁の多い世界では。なのでプチマネージメント業が必要になる。世間ではリーダーシップと呼ばれているものなわけだが・・・。別の言い方をすると、何かを own するには時にその場を取り仕切らないといけない。アプリを速くしたいなら、ときに遅いコードの持ち主をつついて速くしてもらなわないといけない。
そういうの、すごい昔はできた気がするけど言語バリアを跨いで以来すっかりできなくなったしやる気も失っていた。でもまあ、やらないといけないのだろうね。どうやってこの苦手で面倒なものに手を付けていくかを考えないと。なんかこの話くりかえし書いてる気がするな・・・。
家計簿や予算を真面目につけ始めて思うこと: 自分たちは特に慎ましい暮らしはしてない。それなりに贅沢してる。
共働きでもないのに子供を daycare にいれている。それなりの頻繁でガジェットを買っている(自分が)。子供部屋のため 1BR でなく 2BR のアパートに住んでいる。そのアパートは勤務先から近い。毎年海外旅行(日本)をしている上に、来年は親戚の住むスイスに行きたいね、とか言ってる。引っ越してきたときに買ったクルマは新車である。自分は細々したインターネットサービス群に金を払っている、など。
こうした意思決定は(ガジェットとスイス旅行を別にすると)自分の中では正当化されているが、正当化したところで安くなるわけではない。そしてこうした出費によって生活費を base salary 内に収めるという目標が遠のいている。
自分たちはあまり外食をせず、クルマを二台持つこともせず、ケーブルテレビも契約せず、衣類宝飾品もさして買わず、家も買わず、Whole Foods にも通わず、庶民的な倹約チップスに出て来るような無駄遣いの類は割とクリアしているが、一方で上に挙げたような、ほんとにカネがない家ならまずやらないような出費をしている。(Expense-conscious な家庭が毎年海外旅行をするだろうか?)
一方で職住近接も daycare も 2BR も帰省も自分たちの QoL 向上には大きく寄与しているので、節約のためにやめてしまえばいいとも思えない。羽振りの良さの恩恵として有難く浴しておきたい。
この平和な日々が景気の力だという事実は俄には受け入れ難いけれども、それはひとつには付き合いのある人々の多くがおなじくらい(あるいはより一層)羽振りが良いせいで、無意識のうちに QoL standard が釣り上げられてしまっているのだろうね。身の回りの人の羽振りが良いのは悪いことではないし避けても仕方ないから、こまめに家計簿という現実を睨むことで認知の歪みを正していこう。
あとは外国人としてのプレミアはある。たとえば日本旅行はもっぱら親に孫の顔を見せるためであり特段面白味はないが、中米のリゾートでバケーションするよりよほどカネがかかる。友人や血縁者のサポートが得られないがゆえに daycare のありがたみが増す、US 市場のメインストリームと価値基準がずれている、というように。
まあ家計簿のおかげで不景気突入に際してすべきことがはっきりしてきたのはよかった。それがどのくらい uncomfortable かはやってみないとわからないが、まだわからなくていいです。
去年はドメイン切れで怒られた wkb.ug ですが、今年はサーバが落ちてて怒られた。ごめん・・・。
しかし原因がさっぱりわからん。こいつは hasb.ug というウェブアプリのインスタンスで、hasb.ug のドメイン自体はとうに失効したのだが wkb.ug には使われていた。Hasb.ug は完全な素人ウェブアプリなためまったくモニタリングもなければデバッグのためのログもほとんどなく、問題がおきるとお手上げ。そのうち壊れるだろうから App Engine なり Heroku なりのメンテ不要な semi-serverless 環境に移さなければなあと思ったまま面倒で放置していた。そしたら本当に壊れてしまった・・・。
なので重い腰を上げ App Engine に移動。まあ URL をパターンマッチしてリダイレクトするだけのほぼ hello world アプリなのでコード自体は 10 行くらいなのだけれど、色々な設定がかったりー・・・とおもっていたが実はまったくかったるいことはなく、一時間半くらいで移行完了。しかもオマケで HTTPS に対応までしてしまった。
App Engine (Standard), 昔はカスタムドメインの扱いがほぼ不可能だったのが、いつの間にか普通に使えるようになっていた。そして Python 版はサードパーティライブラリを使うのが超絶面倒だったのが Go はなんかふつうに go get して使える。というか標準の App Engine 自体の SDK ライブラリすら go get を要求される。カスタムドメインとライブラリ、２つの欠点がなくなった App Engine Standard (for Go), しかもタダで HTTPS がついてくるとは最強の趣味ウェブアプリ環境じゃね？とおもったら HN でも同じことを書いている人がいた。
Google Cloud は総体としてみると AWS にはだいぶ及んでない感じだけれど、時々こういう気の利いたものが混じっていてよい。
Python 3 is now available on App Engine standard environment | Hacker News のスレを見ていて気づいたこととして、このリリースからは Python も PIP でふつうに Flask とかをインストールして開発できるようになるのか。よくね？Datastore とかどうするんだろうな。まあローカル変なニセ環境を使うよりはネットワーク越しに本物の Datastore をさわればいいのかもしんない。認証とかどうすればいいのかわからんが、まあ必要になったら調べますよ・・・、
Computer Vision: Algorithms and Applications を読み始めた。二章、基本的な数式や画像処理上のコンセプトをまとめている。
Amazon のレビューにもあるとおり、あまりよく書けてない。この章も分かる人には通じるがわからない人には通じない系の話が多かった。ただ color space とか gamma correction とかは何度勉強してもすぐ忘れて混乱するので、手元にこの手の資料があって基本的な式や説明を参照できるようになったのはよいかもしれない。
まえがきにリファレンス目的に書かれたとある。内容もさほどリニアでなく、しかも長く、しかも書き方がまったく親切でもないし詳しくもないので、全部はよまず興味のある章だけつまみ読みかなあ。
CPU, OS や言語処理系のような超代表的なCSジャンルはきちんとした教科書があるけれど、周辺的なジャンルにすすむほど決定版の安心して読める教科書が乏しくなる辛さ。
2011 年出版でそんなにあたらしくもないはずだが、大学の CV の授業は参考文献としてほぼいつもこの本をリストしている。まあ最先端の成果は NN にやられてしまっているにせよドメインの基礎知識的なのは共通しているのでしょう。
去年 Goodfellow の悪魔の書を読んだときはなんだかんだで一日毎朝 1-1.5 時間くらい読めていたが、今は 30 分くらいしか読めない。厳しい。
子供が乳だけ飲んで歩き回りもせず寝てばかりいる最初の半年くらいは平和だったなと思う。子供がちゃんと成長しているのはよろこばしいし、世話や相手をしている時間も去年のような謎の生命体を相手にしているストレスは減ってむしろ delightful だけれども、時間のなさは悪化している。同時に諦めも進んで大きなフラストレーションを感じることもなくなったため、精神衛生は大丈夫でよかった(?)。
子育ての費用を厳密に追跡するのは、当事者としてはあんまし意味ないなと家計の予算を決めていて思う。具体的にはあるカテゴリ X について「子供の X」を独立に記録しても、必ずしもありがたくない。
衣類みたいのは別にしてもいい気はする。でもたとえば家庭の雑貨や外出は今や大半が子供のために資金を費やしているわけで、親とわけても意味ないね。食費も、今は離乳食を作っているから厳密にやれば子供の食費をつけられるけど、つけてどうするという感じがする。
なんとなく子育ての financial overhead がどのくらいなのか知っておくと良い気がしていたが、子供の影響で増えた出費の内訳が細かく見えたところで特段 actionable でない。家族の総体として manage するものでした。今更そんなこといってすみませんという気分。
Podcast を一ヶ月おやすみしている間にやりたいことがあったが、結局ほぼ何もできないまま一ヶ月がおわった。これは子供の就寝起床時間に adversary な変化があったせいでもあるけれど、どちらかというと自分の生活にはもともと時間がないという話なのだと思う。たとえば budgeting にしても vacationing にしてもやらねばと思いつつ podcast の編集や paper reading を優先して放置していたものなわけで、そういう生活のツケを払うと自分のために使える時間はあまりない。
逆にいうと自分の extra-curricular に時間を使うためには家庭や仕事を犠牲にするしかない。自分は仕事の側はこれ以上犠牲にできないと思っているので、結果として家庭が犠牲になる、が、一方でいま家庭を犠牲にしていいのかあまり自明でない、というかよくない。なので順当にいくと extra-curricular が犠牲になる。ただ extra-curricular は自分の将来への架け橋でもあるので (Podcast がその立場を deserve するのかはさておき) なくしてよいというものでもない。これが永遠に解決しない frustration なのはわかっているのでいいとして、そもそも Podcast よくできてんな、という気になる。
これは締切の力だよなと思う。締切があると、長期的な視座とかはさておき優先度を上げたくなる。家族にもわりかし理解される（気がする）。理解を得やすいと感じるのは、たぶん我々現代人が締切という概念にすごく飼い慣らされているから、というのと、締切前の忙しさは一過性のものに感じるからだろう。逆にいうと毎週つづく締切が永遠にあるのは締切の ephemeral な性質を損ねてよくない。
締切に振り回されるのは一般的には良くないことに思えるが、自分の振る舞いを変えるために人為的な締切をセットするのはアリな気がする。
締切だったらなんでもよい、とも思えない。たとえば「期日までにある本を読み切る」という締切は相対的に理解を得にくい気がする。誰かからの期待, commitment がある方がよい。たとえば Podcast には聞いている人や co-host がいる。過去にうまく行った他の例だと、Coursera の宿題締切。別に公的な性格はないが、外部から与えられているのがよい。あと失敗すると落第してしまう、というペナルティの存在も意味があるかもしれない。読書の締切、間に合わなくてもなにも起きないからね。
読書の締切についても家族と約束すればそれなりに機能するのかもしれない。締切をすぎたら家のことに優先度を戻すと決めれば、締切までに読みきらないと続きを読めないペナルティが生まれるから・・・でもどうかな。
個人的には人工的に決めた締切に追われて暮らすのはあまりに silly に思えてやる気が出ない。Podcast の締切みたいにある種の期待を伴うほうが腑には落ちやすい。Podcast 休止中になんかやる、という締切は機能しなかった。自分のやりたいことに意味のある締切を作るのはライフハック的スキルと言えよう。
書籍の Acknowledgement section で家族に感謝する著者は多い。昔はなぜ感謝しているのかまったく理解できなかった。でもきっと執筆中に家族への duty を多かれ少なかれさぼったのを見逃してくれてありがとう、ということなのだろう。書籍も締め切りの力が使えるプロジェクトだな。
Audible の力によりようやくゆこっぷ(おくさん)に本を読んでもらうことに成功したので自分も復習のうえ家計の立て直しを始める。
YNAB を使う。一部にファンの多い opinionated な家計簿ソフトウェア。自分も上の本を読んで興味をもった。彼らの pitch は色々だが、素朴な家計簿予算システムとは大きく２つの違いがある。
自分たちの主要な関心は後者、不定期大型出費の扱い。自分たちはしばしば旅行やガジェットなどの大型出費をするわけだけれど、こいつらの扱いが不透明なせいで日常の budgeting が意義を失っていた。日銭をケチったところであるとき雑に散財しちゃうんでしょ・・・という。加えて子供用品のような中規模高頻度不定期な出費が重なったせいでいよいよ budgeting が崩壊し、精神衛生を損ねていた。これらをシステムとして扱えるのはよい。YNAB によって出費の優先度に関する夫婦間の意見の不一致がなくなるわけではないけれど、カンと雰囲気だけで決める今までよりは生産的な議論ができることでしょう。
これは要するに欲しいものがあったら金を貯める、というだけの話ではあるものの、その前提でツール全体がデザインされているので今まで使っていた Mint.com とはだいぶ趣が違う。
Mint はクレジットカードの不正出費を見張る役には立っていたけれどbudgeting tool としていまいち actionable でないのがよくなかった。具体的には preset のカテゴリーから逸脱するのがすごく大変なのと、月をまたいだ大型出費を扱う仕組みがないこと。
YNAB には、なんとなく TODO アプリを使いつつ腑に落ちない気持ちでいたあと GTD の本を読んだあとのような説得力がある。一方で personal finance のような pervasive な話題をライフハックみたいなノリで扱っていいのか不安もある。まずはちゃんと personal finance を勉強したほうがよくね？みたいな。たとえば YNAB は借金生活から脱出したい自転車操業生活者が主要な対象ユーザなため、retirement fund の話とかはでてこない。それはいいのか。
まあ、しばらくためします。
このあと半年から一年くらいで挫折した。代替は未定。
夏休みは友達の家族と Monterey にでも行きたいなと思っていたのだけれどすっかり計画に出遅れ、かつ自分たちの子連れ旅行スキルが低すぎなことにも気づき、今年は見送り。かわりに近所の Santa Cruz Mountains の村 Boulder Creek そばにあった AirBnB の別荘に泊まってみる。うちから車で一時間くらい。おためしなので短く二泊三日。
山の中、森の中なので昼間でも涼しくてよい。遊歩道とかはあまりないけれど車どおりが少ないので driveway を散歩しても特に問題ない。そして一歳半児の脚はどのみち大して歩けない。やることがなくてヒマといえばヒマだが、森の中を走る鉄道に乗る観光や川辺で水遊びをするなど、多少はなにかあるし、どのみち子供の相手をしていれば一日は短い。一週間くらいならヒマさに殺されずダラダラ過ごせそう。
外食はせず食材持参で自炊。別荘なのでテラスでごはんを食べたりできる。蚊に刺されるが・・・。街のスーパーは普通に充実しており特に高くもないので食材をもっていく必要なかった感じもする。レストランは少ない。自炊という判断は正しかった。
など。家から近いわりに非日常感を味わえて良かった。しかし友達の家族と行くにはさすがにヒマすぎて心苦しい。やはりちゃんと計画して Monterey なり Santa Cruz なり海のそばにとまりたい。ただし自分の家族だけで行くには良い。そして AirBnB で田舎の別荘に止まる子連れ夏休みは色々と都合がよいね。ヨセミテの麓あたりも色々泊まれそうなのだけれど、どうかな・・・。
Santa Cruz Mountains の山奥に村があるのはなぞ。もともとは 19 世紀の終わりから 20 世紀初頭に林業で栄えた鉄道の街らしい。鉄道も林業も廃れた今はある種のリゾート(?)として生き延びている。自分の感覚だと廃村になりそうな設定だけれど California は人口が増えてるのでこういうところにはみ出してくる人も一定数いるのだろうか。
距離的には Bay Area からすごく近いのに住んでいるのは白人ばかりで中国人もインド人もヒスパニックも全然いない。「アメリカの田舎」っぽい。そして家の値段が近隣の 1/2 - 1/3 と相対的に激安。利便性の対価よ・・・。