2021年なにしたっけ

くらし

二人目の子供が大きくなっていき、それにつれて一人目の子供も刺激されて成長していくさまを見ながら一緒に暮らしていた。 子供のことは生活のほとんどを占めるが、プライベートの詳細には立ち入らないのであんまり書くことがない。

しいていうなら睡眠の重要性を再確認した。 夜ふかしした次の日は何をやってもダメダメだし、子供の対応でどうせしっかりとは寝れない。 かといって早寝が続くとやりたいことが何もできないので鬱憤が溜まっていく。 今は夜ふかしと早寝を交互に繰り返している。

買い物

洗濯機

洗濯機がドラム式になった。 ドラム式がいいらしいと聞いていたり、なにかと天気に左右される生活を改善したいという考えが夫婦間で大きくなってきたのでエイヤと買ってみた。 こういうのは二人共苦手としているが、がんばってよかった。 今は夜に洗濯・乾燥する生活に落ち着いている。

ハンドディスペンサー

子育てしていると、とにかく手を洗う。コロナ禍もあってさらによく手を洗う。 こんなに手を洗うなら、もしかして自動で泡が出てきたら便利なんじゃないかと思って買ってみたらやはり便利だった。 ただ、最初に買ったのは作りがイマイチで、泡が電池部分に入り込んでしまい、最終的に半年くらいで故障した。 二個目は電池部分に泡が入り込まないように完全に分離しているタイプに変えてみた。電池が大量にいる。

Kindle Paprewhite

もともと7年くらい使っていたし、画面には傷がついていてライトが付けられないし、typeCになったし、多分早くなってるだろうと思って買い替えてみた。 あいかわらず漫画はiPadで見ているが、小説にはやはりよい。これで三体を読み切った。

iPhone13 pro MAX

10からの買い替え。ひょんなことから10万円分のAppleカードをもらったので使うタイミングを伺っていた。 これまでは裸で使っていたが、考え方を変えてケースとAppleCareをつけた。高いもんなんだから保護もコストを掛けていい。 Apple純正のケースにMagsafeでくっつくリング用のベースをつけてさらにリングを付けてる。 充電もMagsafeのやつを買ってくっつけてる。このくっつけるのが楽しいので充電が捗る。

本

いろいろ最初だけ読んでは途中でほったらかしというパターンが多かった。 読み切れたのは三体ぐらいで、しかも半年ぐらいかかった。読み切れた事自体は達成感がある。

読み終わったあとも三体のことについて、しいては宇宙、人生について考えている……。

来年はもう少し読みたい。

健康

実は5月に全身麻酔の手術入院をしていたんだけど、この出来事をまとめようまとめようと思ってずるずる年が終わってしまった。 病気というわけではなくて、耳の一部を小さく切り取っただけ。いつかブログにまとめたいが、しない気もする……。 ともかく全身麻酔の体験は興味深かった。痛みというより意識に対する麻酔という感じ。 この手術の直前に「全身麻酔の原理は解明されていない」という記事を見て大変興味深かった。

全身麻酔が効く仕組みから「意識の発生源」が見えてきた - ナゾロジー

OSS

仕事が一段落した頃、Rubyの型についてキャッチアップしようと触ってみたらドハマリした。 これは実用的に使えるツールで開発環境を大きく変えると直感した。 仕事のRailsプロジェクトにも入れて便利に使った。 PRもいくつか送っていて、8月くらいから寝る前のちょっとした時間を使ってmergeされたのもされなかったのも合わせて60個ぐらい送っていたらしい。 仕事用のコードでエラーになっている部分のうち、これはおかしいのでは？と思った部分をひたすら改善していった。なので実用性を重視した改善が多いと思う。いやまあ興味本位での手当たりしだいというPRも多いとは思う。。。 使い始めた頃に比べたらだいぶ使いやすくなったきがするけど、まだまだ発展途上なのでもっと便利にしていきたい。 作業時間の捻出が課題。

来年

睡眠を大事にがんばりすぎない感じでがんばっていきたい。

三体 / 劉慈欣

三体の感想を書くことは不可能だ。

単純に三部作で相当な分量があり、しかも一部毎にジャンルが違うと思うくらい多様な話が盛り込まれている。三体の感想を一言で述べるということは、言葉を原子に見立てるならば、原子を無限に圧縮することになるため途中で核融合が発生してしまう。そのため永遠に到達できない。

よってこれから語るのは三体の感想ではない。ただの個人の日記である。

2021-12-23。僕は三体Ⅲを読み終えた。

僕は三体を2021年5月頃に読み始めた。Ⅰだけでも歴史あり、科学あり、VRあり、サスペンスあり、人類賛歌ありと盛りだくさんだった気がする。 気がするというのは、現実での時間の経過もあるが、本編の話のスケールが大きすぎて、Ⅰは遠い過去の話のように感じるのだ。

途中間も空いたりしているが、Twitter検索によるとⅡの上を読み終えたのが10月となっている。Ⅱを読み終えたのは11月末だ。

そう考えるとⅢは1ヶ月程度と、僕にしてはかなり早く読んだことになる。僕は「年内に読み切る」と目標を立てた。

目標とは、他の余計なことをしないために自分にかける呪いだ。この呪いのおかげもあってか、それとも三体の魅力もあってか、加速的に読み進めていった。

これだけの壮大なスケールにも関わらず、三体は読みやすい。難しい表現は出てこず、かなりわかりやすさに配慮しているんじゃないかと感じた。表現は淡々としていて、それでいて壮大なシーンも僕でも難なく思い描けるように書かれている。それゆえ、壮大なシーンがダイレクトに精神に届くため、〈水滴〉のシーンや〈紙切れ〉のシーンは精神的に落ち込んだ。

僕個人は、壮大な人類の歴史にとってほんの小さなひと粒の粒子でしか無い。そう考えると生きる意味についても、どうしても考えさせられてしまう。

僕は今年いっぱいでMICINを退職し、来年1月からREADYFORへ転職する。しかし、そんなことは人類にとっても宇宙にとっても些細なことだ。僕がこの人生で何をしたのかなんて、多く見積もっても百年と残らないだろう。宇宙規模で見れば、全ての個人の営みは等しく希薄化され、一切意味がないかのように思える。

はたしてそれが真実なのだろうか？

本書ではこうも語られている。

”きょうを楽しめ”というのがいつだって正しい道だったんだからね。

私達の目では原子は目に見えないほど小さい。一つ欠けたところで大して変わらないだろう。代わりはいくらでもいる。

しかし世界はその原子でできている。

宇宙規模で見ればちっぽけな命でも、宇宙の歴史はその生命の一つ一つで紡がれている。

宇宙は大きい。でも、生命はもっと大きい。

生きる意味なんてどうでもいい。生きることが意味なのだから。

Rails MVCしか知らなかったバックエンド開発者が、最近のフロントエンド開発を学んで得た知見

これは、これまでRailsの古き良きMVCな開発体制しか知らなかったバックエンド開発者が、環境が変わってフロントエンド開発を学ばざるをえなくなった者の記録です。

歴史的に正しい事実を書いたものではなく、私個人の理解を整理するための妄想日記です。

私はこれまではWebアプリの開発ばかりやってきて、RailsでHTMLテンプレートエンジン使ってviewを作るスタイルでしか開発してきませんでした。

しかし、ネイティブフロントとWebフロント両方があるアプリケーションが開発されているところを見て、ある事を思いつきました。

「Webフロントもネイティブフロントのように開発できれば、バックエンドエンジニアはバックエンドに、フロントエンドエンジニアはフロントエンドに分業できて、開発しやすくなるのでは？」

 

この気付きが超重要でした。このイメージを持てたおかげでフロント開発の意義がスルスル入ってきました。

Railsはフルスタックフレームワークなので、RailsでHTMLを生成して返すことができますが、その開発体制だと、「バックエンドエンジニアは、得意なバックエンドを沢山書いて、不得意なフロントエンドをちょっと書く。フロントエンドエンジニアは得意なフロントエンドを沢山書いて、不得意なバックエンドをちょっと書く。」ということが起こっていたように思います。

だんだんと、「ちょっと不得意な人が書いたコード」が増えていきます。レビューで指摘しあえれば良いのですが、なかなか完璧にはいきません。

もし、RailsのV部分を引き剥がして、フロントエンドが得意なエンジニアに開発を任せることができれば、RailsはAPIだけでよくなり、ネイティブフロントもWebフロントも同じようにAPIを提供する形で開発できます。

どうやらこれを実現するのがSPA(シングルページアプリケーション)という事なのかなと思います(多分間違ってる)。

だからこそRailsでAPIモードができたり、PWAだとかいう話が出てきたのかなと想像します。

そしてSPAを作りやすいReactやVueが盛り上がったと予想します。このSPAをS3とかなんかいい感じのプラットフォーム(これがNetlifyとかなのか？)にデプロイすれば、サーバーを管理せずとも簡単なアプリなら作れるし、Lambdaとかと組み合わせれば結構なことまで出来ちゃいます(これがAWS amplify?)。いわゆるLinuxサーバーを立てたりしなくてもマッシュアップサービスとかが作れてしまうので、サーバーレスとかも叫ばれてきたのかなあ？

このSPAも細かく言うと色々やりようがあるようです。

例えばブラウザでページを開いたときにJSが起動してHTMLを構築するシンプルな方法をCSR(クライアント サイド レンダリング)と言うそうです。だいたいのことはCSRで行けるし、create-react-appが出てきて学習コストも下がってきたので、今も結構使われてるのかなと予想します。

しかしながらGoogleクローラーがJSを実行するかしないか微妙な時期があったのか、最初のJS実行時のラグを気にしてか、サーバーサイドでReactなりVueなりを実行してHTMLを生成する手法が出てきました。これがNext.js(React)とかNuxt.js(Vue)ということかなと思います。これがSSR(サーバー サイド レンダリング)と言うそうです。

Next.jsの方をちょっと触っただけですが、動的画像生成を実装した経験からも、next/imageだけでもかなり便利そうです。

これは、libvipsを使って動的に画像を生成して、ブラウザ毎に最適な形式でファイルを作り、キャッシュ用のヘッダーもいい感じにして、なんなら専用サービス(Vercel？)にデプロイすれば生成したファイルをキャッシュしてくれます。

これだけでも導入する動機になりそうです。触ってみた感じ、S3のファイルとかでもドメインさえ設定すればなんでもいけそう。

ただし、この画像生成機能はビルド時ではなく画像へのリクエストがサーバー上に来たときだけに使えるので、SSRでは使えても後述するSSGでは使えないようです。

さて、そんなSSRも、GoogleクローラーがJSを実行してくれるようになったり、CDNが一般的になったり、そもそもサーバー側の要素が増えるので、実装が複雑になってしまいがちでした。そこで新たな策として、予めビルド時(デプロイ時)にDBなりを見てもいいからHTMLを生成しておいて、これをCDNなりで静的ファイルを配信すれば、サーバーのプロセスもいらないし、なんならDBもいらないし、既にレンダリングされているから表示も早いしでいい事ずくめとなったのがSSG(スタティック サイト ジェネレーター)なのかなーと予想します。

これがNext.jsの今の売りっぽいです。CSRに似ていますが、HTMLのあらかじめ生成度合いが、CSRが0だったのがSSGで80〜100になったイメージです。もちろんAPIをクライアントサイドから叩いて動的コンテンツを追加することもできます。なんかこの辺からJamstackと言うらいしいっぽい感じがします。ブログとかほとんどSSGでいけそうです。

更にISGやISRなんてのもあるっぽいですが、まだまだキャッチアップ中です。。。 

さてさて、こんなことを最近学んでみて、また、少しNext.jsアプリケーションを作ってみて、昔ながらのRailsアプリケーションに対する考え方が変わり、ようやく時代に追いつけてないことが自覚できたレベルにはなれたかも？と思いました。

これまで作ってきたものは、サーバーサイドでほぼ同じHTMLを作って返すものなので、最近のフロント事情からしたら無駄が多いのかもと思えてきました。

また、Next.jsをcreate-next-appで作ってみると、驚くほど簡単にコンテンツが作れてしまいます。フロントはからっきしだった私が、簡単なアンケートサイトみたいなやつなら作れたので確かです。

Next.jsはルーティングも簡単に(ファイルパスを切るだけ)できるので、最早VもCもフロントでできてしまいます。

そして、どうせSSRするなら、そのnodeサーバーからprismaなりでDBを叩いて動的コンテンツを返せれば1プロセスだけでいいし、認証もFirebase AuthenticationやAuth0なんかで作れてしまいます。

そうなると「もはやRailsはいらない！」みたいな思考になる人が現れてもおかしくないなと思う気持ちも理解できます。

もちろんRailsでHTMLを生成する方法も、状況によってpros/consあるかとは思いますが、自分が見ないようにしていたものの大きさを急に知って、驚くばかりです。

っていうかもはや私としては、バックエンドエンジニアとは？自分の存在価値は？みたいな気持ちです。

これから、改めて「どうやってアプリを作るのか」を考え直してみたいと思います。

entrykitがM1 mac(Apple Silicone)で実行できないときの対処法

現状

M1 macでDockerのApple M1 Tech preview 7 *1 を動かしています。

golang:1.15 imageがたまたま手元で動いていたのでこれで試します。

entrykitはv0.4.0のバイナリを配布していますが、これを実行しようとすると以下のようにgoレベルで落ちてしまい実行できません。

$ docker run --rm -it golang:1.15 bash
root@aa08b9d02add:/go# wget https://github.com/progrium/entrykit/releases/download/v0.4.0/entrykit_0.4.0_Linux_x86_64.tgz
root@aa08b9d02add:/go# tar -xvzf entrykit_0.4.0_Linux_x86_64.tgz

root@aa08b9d02add:/go# ./entrykit
runtime: failed to create new OS thread (have 2 already; errno=22)
fatal error: newosproc

runtime stack:
runtime.throw(0x84a820, 0x9)
    /usr/local/go/src/runtime/panic.go:527 +0x90
runtime.newosproc(0xc820026000, 0xc820035fc0)
    /usr/local/go/src/runtime/os1_linux.go:150 +0x1ab
runtime.newm(0x8e5980, 0x0)
    /usr/local/go/src/runtime/proc1.go:1105 +0x130
runtime.main.func1()
    /usr/local/go/src/runtime/proc.go:48 +0x2c
runtime.systemstack(0xa2b6e0)
    /usr/local/go/src/runtime/asm_amd64.s:262 +0x79
runtime.mstart()
    /usr/local/go/src/runtime/proc1.go:674

goroutine 1 [running]:
runtime.systemstack_switch()
    /usr/local/go/src/runtime/asm_amd64.s:216 fp=0xc820020770 sp=0xc820020768
runtime.main()
    /usr/local/go/src/runtime/proc.go:49 +0x62 fp=0xc8200207c0 sp=0xc820020770
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1 fp=0xc8200207c8 sp=0xc8200207c0

あまりパソコンに詳しくないのですが、 downloadしたものはx86_64(amd64)環境のbuildと思われるので、aarch64(arm64)環境では動かないのかなと推測します。

また、entrykitは長らくreleaseされておらず、作者も興味を失っている気がする(憶測)。

界隈で一瞬流行ったので、なんとなく使われているということが多いのではないでしょうか。

考えうる解決法

解決方法はいくつか考えられます。

1. entrykitを捨てる

そもそもprehookだけの利用の場合、entrykitは必要ありません。

prehookコマンドの正体は、

$ prehook ① -- ②

となっている場合、

1. ①を外部コマンドとして実行する(複数可)。その後②でexecする。
2. --以降がなく①だけの場合は①でexecする。

ただこれだけです。

よって

Dockerfile

ENTRYPOINT[ \
  "prehook", "ruby -v", "--", \
  "prehook", "bundle install", "--" ]

は

Dockerfile

ENTRYPOINT[ "./entrypoint.rb" ]

entrypoint.rb

#! /usr/bin/env ruby

system("ruby -v")
system("bundle install")

exec *ARGV

と別ファイルに切り出せます。

もちろんrubyじゃなくshellでもいいです。

Multi stage build

これだけなら話は早いですが、entrykitを使うからには、おそらくprehook以外のentrykitコマンドと組み合わせたいという使い方が多いと思います。

そんなときの対処方法としてMulti stage buildがおすすめです。

FROM golang:1.15 AS entrykit
RUN go get -v -ldflags "-s -w" github.com/progrium/entrykit/cmd

とすると、Docker環境内でdownloadとbuildが始まり、/go/bin/cmdという実行ファイルが生成されます。これがentrykitの実体です。 cmdじゃなくentrykitという名前でbuildする方法がいまいち分からなかったので誰か教えて下さい……。-oはgo getでは使えないらしい。

ともかくこれで、M1環境でしかもgolang version 1.15でbuildしたentrykitのbinaryが手に入ります。簡単。

次にentrykitを使う場所で、entrykitの実体だけCOPYしてきます。

Dockerfile

COPY --from=entrykit /go/bin/cmd entrykit
RUN entrykit --symlink

これで各種コマンドが生成されます。symlinkはCOPYできないのでCOPY後に--symlinkするようにしましょう。 また、使うコマンドが1つだけなら、

COPY --from=entrykit /go/bin/cmd render

だけでもいいです。お好みで。

Cross buildしてbinaryをプロジェクトリポジトリに置いとく

手元でCross buildして複数環境用にbuildしておき、生成されたbinaryが使われるようにuname -mとかで切り替える。。。

面倒そうな上にMulti stage build以上のメリットはなさそうです。

結論

• entrykit本当にいるのかどうかよく考えよう。
• Multi stage build便利。

課題

Multi stage buildの場合、entrykitのファイル配置がおかしいのか、go getでversion指定する方法がよく分からない……。go歴0秒なのでご教授いただけると幸いです。

逆に言うとversion指定しなくてもいいのでメンテナンスレス！

感想

バイナリ配布型のプロダクトの場合、fat gemなどと同じく継続的なreleaseが必要でメンテナ負担が大きいのではないかなと推測します。(作ったこと無いのでなんとも言えないけど)

その点、スクリプト型言語なら再buildなどが必要ないので、 ミニマムに使えるけどメンテナンス負担が大きいバイナリ配布と、 導入は大げさだけどメンテナンス負担が小さいスクリプト配布と使い分けがありそうですね。

とはいえ今回のように都度buildすりゃいいじゃんと言われればまあそうなのかも。

*1:download link: https://desktop.docker.com/mac/m1preview/Docker-AppleSilicon-Preview7.dmg

プログラミングElixir / Dave Thomas

プログラミング Elixir(第2版)

リンクは第2版ですが、読んだのは第1版です。。。

本を買ってから4年くらい積まれていたのですが、この度第2版が出版されたとのことで、あわてて手元の第1版を読みはじめました。

結論からして、読んでないことを後悔しました。

関数型言語は難しそうなイメージで一つも書いたことがなかったのですが、Elixirなら馴染みのRubyっぽい文法で読めるし、これまでよくわかってなかったパターンマッチも、この本を読むことでなんとなく理解できたように思います。

パターンマッチはif文のような分岐でもあり、assertionでもあり、変数捕縛でもありと、私の拙い文章能力では意味不明ですが、ともかくパターンマッチによって、これまで自分が見ていた世界を、別の視点から見ることができたような気持ちになりました。

自分がこれまでに築き上げてきた考え方を変えることは簡単なことではないですが、本書の丁寧な解説と、読者がプログラミングを楽しめるようにと書かれた著者のお陰で、不思議とこれまでとは別の考え方でプログラムを見ることができた気がしました。

タプルとリストの違いには困惑しましたが、タプルは不変で追加や変更等の操作はしないもの。パターンマッチでは `{ :ok, foo } = ...` のように最初にAtomを置く使い方を頻繁にしています。

リストは、数字など同じ型の値の集まりであることが多いようです。

Rubyは大クラス主義なので、どちらもArrayでまかなわれますが、この使い分けはRubyが主要言語の私には新しい発見でした。

本文ではif文やfor文など、おなじみの構文はほとんど出てきません。Elixirでは関数とパターンマッチが融合していて、通常はif文を書くところではパターンごとにマッチする同名の関数を書くことで、if文を書かずに済み、かつ名前をつけることができています。名前をつけるほどでもない場合にif文を使うのでしょう。

for文もなくはないのですが、ほとんどはEnum系の関数でなんとかなるようです。

Elixir/Erlangのプロセスは、golangのgoroutineのようなもののようです。軽量に生成することができ、平行/並列で動作します。さらにsend/receiveでメッセージをやり取りでき、さらには複数Nodeでも扱うことができOTPという強力なバックグラウンドもあるので、Elixir/Erlangは分散システムを作るのが得意ということなのでしょう。

余談ですが、最近エディタをatomからvscodeに移行しようとしていて、 Elixir用の拡張を探していたのですが、最初に見つけたものがうまく動かず、特にフォーマッターが動いてほしかったのでドツボにはまって自分で自作してしまい、これに時間を使ってしまいました。

後から[ElixirLS](https://github.com/elixir-lsp/vscode-elixir-ls)という拡張なら、フォーマッターを含めオートコンプリートなど全てうまくいくことがわかりました。vscodeのformatter extensionの書き方/読み方がわかったので良しとします。

本書によってElixirの魅力に惹かれたので、Phoenixアプリケーションなどもいつか作ってみようと思います。

株式会社MICINで働き始めました

micin.jp

"すべての人が、 納得して生きて、 最期を迎えられる世界を。"

をvisionにかかげる、MICINで医療系のプロダクトを作っていきます。

MICINって？

私は不勉強ながら、転職ドラフトでオファーがあるまでMICINの名前を知りませんでした(マイシンと読みます)。 しかしながら、実はcuron(クロンと読みます)というオンライン診療サービスで今注目されている企業なのです。

オンライン診療とはその名の通り、病院に行くことなく、オンラインで、【予約→問診→診察→支払い→お薬の受け取り】まで一気通貫でサポートする事ができ、コロナ禍でさらに有用性を発揮し、大きく伸びているサービスなのです。

さらにMICINではオンライン診療だけでなく、データソリューション事業や治験など、医療における多方面への事業を展開しています。(宣伝)

どうしてMICINに？

医療×Techがやりたいなと思って、転職ドラフトをやってみて声をかけられたのがきっかけです。

選考を始めたときは「ちょっと話聞いてみようかな」ぐらいの気持ちでしたが、カジュアル面談や面接で自分の本気の本音をぶつけても、お互いにうまく響いたようで、最終的に「ここで働きたいな」と思えるような医療に対する情熱を感じ、JOINしました。

医療系の中でも、患者寄りの思想である事や、データを活用して医療を良くしていこうという部分が私の経験にもうまくマッチしたように思います。

どうして医療×Tech？

医療がやりたくなった話をしだすと、自分でも想いが溢れすぎて*1もはや自分の文章能力では表現不能と悟ったのではしょりますが、個人的な体験から、誰も見捨てず手を差し伸べるという医療のかっこよさに惹かれ、責任感、親として、使命感、年齢、人生観、その他様々なものが混ざり合い、自分も医療のために働きたいと思い至りました。

そして、私がこれまで磨いてきた技術力と、医療へのモチベーションを掛け合わせれば、自分の力を最大限発揮できると思いました。

どういう人がいるの？

私はしがないWeb系のプログラマーでしたが、社員の皆様の出身は様々で、コンサル、医師、博士、薬剤師、科学者、製薬、MRなどなど、ほんとにすごい経歴の方が集まっています。

そして全員が、医療を良くするにはどうすればいいか、理想面でもビジネス面でも本気で考えています。

こんなに面白い人達が集まって、これからどんな事が起こるんだろうと今からワクワクしています。

心を燃やせ

"俺は俺の責務を全うする!!"

We Are Hiring!

というわけで医療をより良くしていくためにがんばります。

私も医療やってみたいという方は、ぜひご応募ください。

hrmos.co

*1:5000字くらい書いたり消したりした

アドラー流子育てベーシックブック / キャサリン J. ボルス

アドラー流子育てベーシックブック

積読消化習慣ということで、どんどん読んでいきたいと思います。

この本は、Twitterで見かけて購入しました。知り合いがオススメしている本は積極的に読んでいきたい。

子育て本はいくつか読んだことがありますが、本書は理論派というよりは実戦派という感じで、実際にイメージしやすい短いエピソードが沢山載っていました。

セルフケアの重要性を説いている子育て本は初めて読んだので、そこが印象的でした。

子供にイライラしだしたら、セルフケアが足りてない証拠と思えば落ち着きやすいし、イライラしだしているパートナーにも今ケアが足りてないのかもという視点も持つことができました。

この本を読んで、今まで以上に子供が今どういう気持でいるのか、深く気持ちをシンクロさせて考えるようになりました。

そして、今いっぱいいっぱいになってるのかな？とか、主導権をあげれてなかったかな？とかいろいろ打てる手が広がったように思います。

しいて言うなら、広く浅く、8割の子に当てはまればいいぐらいのチップスが多く、根拠も学問ではなく著者の経験からくるところが大きいのが、読者を選びそうです。 また、アメリカ特有の文化もベースにあり、そのまま日本の文化には転用しにくいだろうというエピソードも多数あるので、その辺は気にせず読み飛ばしていました。

最高の一冊に出会った！という感じではないけど、読まないよりは読んだほうが経験が積めて手札が増える。という感じでした。