yak shaving life

遠回りこそが最短の道

Pixel 6 祭りに乗るか否か

Pixel 3 を使っている。Pixel 3 は本当に素晴らしいデバイスで、未だにほとんど不満がない。いや、Google Storeで買った後すぐに値下げしやがったことについてだけはハラワタ煮えくりかえってますけどね。許すまじ。2万ですよ2万。いきなり2万値下げっておかしくない?値下げの直前に買ったんですけど?なんで先に買ったユーザになんの保証もないじゃコラ。せめてなんかクーポンくれるとかさあ、なんか…あるやん?何にも無しってのはちょっと…辛いやん?

というのはさておき、デバイス的には本当に素晴らしくて、ちょっとメモリ容量が少ないのとカメラのメモリ消費が異常なのでカメラを開くと全てのアプリがkillされてしまう*1けどまあ大して困っていない。動作の軽快さ、カメラの画質、背面指紋センサ、本体のサイズ感、質感、見た目。どこをとっても個人的には歴代ベストに近い端末だと思っている。

いるんですが、電池の消耗だけはどうしようもなく一日外にいると厳しい感じになってきたのと、電源ボタンがイカれ始めていてたまに押しっぱなし状態になってしまい勝手に再起動を繰り返す困ったちゃんなのでそろそろ買い替え時期かなと。Pixel 5aが出たときにこれは買いかなーと思っていたんだけど、割とすぐPixel 6の噂が出始めたのでどうすっかなーというところ。

Pixel 6はかつてないくらいマーケティングが激しくて盛り上がっているように見える。リーク記事とかも多すぎて故意にリークしてるとしか思えないレベル。しかしGoogle Tensorとやらがどのくらい凄いのか分からない、というか不安の方が大きい。フラッグシップ端末を大枚叩いて買ってまで人柱になりたくないなあ。あとはPixel 3 値下げの件もあり、発売してすぐ素直に手が出せないというのもある。あれは…本当にトラウマなんですよ…。

というわけで、このビッグウェーブに乗ってPixel 6買っちまうか、でも正直5aで十分な気もするんだよなーというので悩んでいる。5aはワイヤレス充電できないこと以外は良さそうだけどなあ。まあ6が発売するまでは様子見かなー。あと身近な人がiPhoneユーザばかりなのでPixel話ができないのが悲しい。日本Pixelユーザ会(JPUG)みたいなものが必要とされている…。いや、されてないか。とりあえずPixel 6、要チェックなのでAndroidユーザの皆さんは楽しくお祭りに参加しましょう。ワイワイ。

*1:rebuild.fmでもそのような話があった気がする

Spring BootでJS/CSSのバージョニングをするための最小設定

ググってもなんか古い情報とかが多くてうまく見つけられなかったのでメモ。Spring Bootのバージョンは2.5.x

基本的に、application.yml / application.propertiesspring.web.resources.chain.strategy.content.enabled プロパティを追加するだけでできる。

spring.web.resources.chain.strategy.content.enabled = true

これだけで良い。少し古いバージョンだとspring.resources.chain.strategy.content.enabled (webがない)なので注意。

バージョニングを適用するファイルパスを指定したい場合は spring.web.resources.chain.strategy.content.paths を追加すれば良い。

これだけなので本当に簡単なのだが、なぜかうまくJS/CSSにバージョンが付与されずハマったことがあった。原因は spring.web.resources.add-mappingsfalseになっていたからだった。ここだけ注意が必要。

絶対に挫折しない日本史 を読んだ

なぜ読もうと思ったか

日本史に苦手意識があるので、読みやすそうな本を読みたかったし、挫折したくないので。

どのような本か

日本の通史を、固有名詞を限りなく省いた形で書いた本。前半でざっくりした流れを説明し、後半ではテーマごとにまた一から通史を書くというのを8回繰り返している。今まで見たことのない形式。

書評というか感想

挫折せずに最後まで読めたのでよかった。結構さくっと読めました。

固有名詞をざっくり省いたということで、歴史上の人物とか建物とか律令とかそういうものの名前がほとんど出てきません。逆に現代の人物や作品の固有名詞が喩えとしてバンバン出てきます。とにかく親しみやすい内容にしようという著者の努力が伺えて好印象。ドラえもんの喩えとか分かりやすかった。

前半よりも後半のテーマが面白くて、個人的にはコメ、土地、家族あたりが興味深かった。米が主食になったのって意外と最近なんですねえ。家制度とかもどういう風に始まったのかとか全然知らなかった。男性優位社会がこうやって形成されていったんだな〜という大きな流れが理解できた気がする。

高校のとき日本史の授業はなかったし、小中で学んだ内容もさっぱり記憶がなくて日本史というものがどうしても好きになれない…というか分からなすぎて興味が持てないという感じだったのだけれども、最近は仏教について学んだり大河ドラマを見たりして少しずつ日本史の復習をしているので、この本も非常に役立った。僕みたいな日本史弱者には良い本だと思う。逆に歴史好きの人が読む本ではなさそう。

あと、著者の政治的指向がちょくちょく出ている感じがするので、そこに共感できなかったりリベラル嫌いだったりすると読むのが辛いかも知れない。まあ不快に思ったとしてもそういう部分だけ読み飛ばせばいいと思いますが。歴史の解釈にはどうしても主観が入るので難しそうだなと思いました。まる。

github.devがめちゃ便利で感動している

いや、感動は言いすぎかもしれないけど。良い。

最近ペアプロならぬペアコードレビューをやったりしていて、そういやgithub.devって使ってます?的な話をしたところ使ったことがないというのでとりあえず見せてみようと思って何気なく「.」キーを押したところ、えっ…PRの差分めっちゃ見やすくない!?なにこれ良くない?良くなくない!?と一昔前のギャルみたいな喋り方でキャピキャピ盛り上がりました。すみません嘘です。盛り上がったのは本当です。

まあ従来のGitHubのUnified Viewで十分なケースもあるけれども、Side by Sideでみたいなーと言うときもあり、でもSplit Viewはなんか見づらいんだよなーと以前から思っていた。そこでgithub.devですよ。PRの差分もこれで見れるとは知らなかった。手元のIDEで見ているかの如き良体験。流石にコードジャンプとかはあまりできない(ちょっとはできる)けど、とにかく見やすい。ファイルツリーが使えるのもいいですね。MacだとOption + ZでWord wrapするのがオススメです。

もうこれなしでは生きていけないくらい使っているんだけど、不満を挙げるとすれば「.」を押したときカレントタブじゃなくて新しいタブで開いて欲しい。github.comでしかできないことも多いので両方見たいんですよ…でも.devの方は開くまでだいぶ時間かかるんでブラウザバックとかしたくないんです。MSさんお願いします。新しいタブにしてください。おねげぇしますだ…。

最近は新しいタブ開いてURLコピペして.comを.devに書き換えるという方法を取っています。あれ、もしかして新しいタブで開くためのショートカットとかあるのかな。誰か知ってたら教えてください。

あと正式名称がよくわからないのも困る。これがCodespacesでないことは分かる。github.devと呼ぶべきなのか?それともGithub web-based editor?VS Code Web?誰か真実を教えて欲しい…。

まあとにかくコードレビューが大変捗るので、GitHubさんありがとうという感じです。使ったことない人はぜひ試してみてください。

ParallelStreamは親スレッドというか元のスレッドも並列処理に使用するし一部のスレッドで例外が発生しても正常処理のスレッドは継続する

PararellStream絡みでなんだかよくわからないことになったので公式ドキュメントなどを読んでみたけどたいした記述がない。(もっと詳しく書いてあるページがあるのか?)

docs.oracle.com

しばらくうんうん唸っていたけどもう一度ググり始めたら神記事を見つけて全てが解決した↓↓

hit-techblog.blogspot.com

要は、

ParallelStream内のスレッドでは親スレッドと同じスレッドも使用する…らしい ParallelStream内で例外が発生しても正常処理のスレッドは継続する…らしい

ということだそうで。この辺が分かっていなかったのが悩んでいた原因なのでした。なんとなく直感的じゃないんだよなあ…。まあ並列処理は直感では理解できないという印象ではあるので、こうやって色々踏んで覚えていくしかないのだろう。

しかし世の中には人の役に立つブログを書いてる人がいて素晴らしいなあ。インターネット最高。

「なぜ?」から始める現代アート を読んだ

なぜ読もうと思ったか

著者の長谷川祐子氏は金沢21世紀美術館の館長で、東京都現代美術館の元チーフキュレーター。この人の書いた現代美術の解説本を読んでみたいと思ったので。

どのような本か

世界的に有名なアーティストの作品を例に挙げながら、現代アート鑑賞のポイントをガイドしてくれる本。ところどころで美術史や関連する歴史、その他必要な知識を解説しているので前知識が少なくても読める。

書評というか感想

かなり読み応えのある本だった。

著名な現代美術のアーティスト(一部建築家含む)が25人くらい主要な作品と共に紹介されていて、それだけでもだいぶありがたい上に、作品を鑑賞するためのポイントが周辺知識とともに解説されている。時にその周辺知識について深掘りしていてそれがまた勉強になった。各章で着目するポイントを変えているところも面白い。

一方、ちょっとこの人の主観入りすぎじゃない?と思う部分も散見されて、うーんどうなんだろうと思っていたが、最近になってようやく気づいたことがある。アートに正解はないので、誰の書いた本であろうと著者の主観がガッツリ入ってくるのである。村上隆や小山登美夫の書籍ではアートを取り巻く社会の構造が解説されていて、なるほどなーと思いながら読んだものだけど、今思えばやはり、多くは主観に基づいて書かれていたんだろうなと思う。極論すれば世の中全部そうなのかもしれないけど、美術という分野ではそれが顕著なのかなーと。

そういうわけで、「世の中全てポジショントーク」だとは常々思っているわけですが、ことアートにおいてはより一層「全ては主観である」という意識を持っておく必要があるなと思った。そう考えるとこの本が特段主観的すぎるということは全くなくて、シンプルに良い本です。現代アート分かるようになりたい〜というアート初心者(つまり僕のような人)にはだいぶオススメです。

データ指向アプリケーションデザイン を読んだ

なぜ読もうと思ったか

発売当初から話題になっていたしいつか読みたいと思っとは前々から思っていたのと、Redis ClusterやGoogle Spannerについて調べていて分散DBを学びたくなったので。

どのような本か

「アプリケーションデザイン」と題されてはいるものの、基本的にはDBと分散システムの本。なので分散データベースについての記述が多い。でもRDBの話もちゃんとあります。

書評というか感想

すごい本だった…。

何がすごいってまず分量がすごい。前半は気合入れて読んだけど、後半は隙間時間で読んでいたので読了までに数ヶ月かかってしまった。内容も濃いので流し読みだと全く頭に入ってこず、何回も読み直したりしていたらだいぶ時間がかかってしまった。

そして内容もすごい。すごいすごい言いすぎて語彙力の貧しさが露呈してしまっているけど、すごいと思ったんだからすごいのである。扱っているトピックが広く、さながらDBと分散システムの教科書といった感じ。

いわゆるWeb系のエンジニアで、扱っているシステムが小〜中規模な場合、分散システムを触る機会もあまりないと思う。自分もそうだった。そういう人でも第1部「データシステムの基礎」は勉強になります。データモデルやストレージの話、あとは広く浅くいろいろな話題に触れている感じ。

第2部「分散データ」は分散システムに馴染みがない人(僕とか)だとちょっと読むのが大変かもしれない。全てを理解しようとして読むとかなり気合が必要なので、気になったところだけ深く読んであとはさらっと読んだ方が読了するにはいいかもしれない。ただし7章「トランザクション」は本当にいい話なのでここはじっくり読んだ方が良い。RDBの理解を深めることにもなるので是非。

第3部「導出データ」はMapReduceの話とイベントストリームの話が多い。僕はHadoopも触ったことがないしMapReduceとか正直なんとなくしか知らなかったけど、ここを読んで多少理解できた気がする。多少だけど。イベントストリームは今後のトレンドというか、疎結合でスケーラブルなシステムを作る上で避けては通れないのである程度詳しくなっておきたいところ。そして最後の第12章はちょっと毛色が違って、筆者が考える「データシステムの将来」について述べられている。これまた興味深い。

全体的に、実装については触れられていないのでコードは載っていない。でもかなり詳細なところまで説明があるので「抽象的すぎて分かりにくい」ということはない。また実際のプロダクトがどういう設計やアルゴリズムを採用しているか具体例を挙げてくれるのでイメージがつきやすい。

僕自身は分散システムについては本当に無知なので、学びが多すぎて頭が渋滞してしまい読むのにだいぶ時間がかかった。素晴らしい本だけど読むの疲れた。というのが正直な感想。もうちょっと集中して読む環境を整えればよかった。これは隙間時間で読む本ではない…。分散システムについて詳しい人がこの本を読んだ感想を聞いてみたい。

また、よく使っているRDBトランザクションがいかに強力で、そこにどれだけ依存しているのか認識できてよかった。逆にいうと、RDB以外のデータベースをガッツリ使ってアプリケーションを作ろうと思うと設計思想をまるっきり変えなければならない。今までFirestoreとかを雑に使ってアプリを書いたことはあるけど、プロダクションレベルのサービスを作ろうと思うとマインドセットからまるっと変えないといけない気がする。そのくらいRDBトランザクションは強力。DynamoDBとかCassandraとかを使っている例はよく聞くけど、市井のエンジニアたちは皆そこまで理解した上で設計されているんだろうか。

無知の知というか、俺って何にも知らないな〜という気持ちにさせてくれたのでありがたい。DBとか分散システムに対する興味が深まったので、今後は関連する書籍を読んだりNoSQLやNewSQLを使って遊んでいきたい。最近はDockerでなんでもサクッと構築できるので便利な世の中だ。

いやーそれにしても素晴らしい本だった。しかし書いてあることの何割くらい理解できたんだろうか。またもう一回読んで復習しないとなあ。