新しくシンセを少し安く手に入れたので練習してる。digitoneよりは機能が絞られていて使いやすい。 コード進行とかさっぱりわからないので記事を読んで勉強しているけど、何か本を読んだ方が手取り早いのかもしれない。ちょっと違うんだよなあというところがある。曲作るのは日記っぽいところがあって、言語化しにくいテンションを表現できておもしろいと思う。
外出先から帰ってきてシンセ弄ってたらすごい眠くて、作業する予定だったけどずいぶん寝てしまっていた。気付いたら夜になっていて、何か食べなきゃなと思って外に出るけど9:00前で何もやっておらず、ナスそうめん作ろうとナスだけ買って帰るけど、暑くてやってられないのでまずはフジロック聞きながら風呂入る。
風呂入ったらいい感じになってしまって、OP-1引き出して遊んだり考え事をしていたらもうこんな時間。 まあこんなもんですかね。。。1人だと晩ごはんサボりがちになる。
明日は部屋の片付けしたり、洗濯機の周り掃除したりだな。
ブログっぽくなってきていいぞいいぞ。
なぜソフトウェアを書いているのだろう。自分はどうなりたいのだろう。と色々考えていたのだけれど、久々に腑に落ちてきた気がした。一言で言えば、ヤバいものを見たいからだと思う。作り手になっていると、一番最初に完成したものを見ることができる。気に食わなければ、調整することができる、一番自分が気持ちいいところに調整していくことができる。（全てをコントロールできたなら）この瞬間がたまらなくてやっているのだなと理解した。（しかもこれでお金がもらえるなんて！）
自分でコードを書かなくたってそうだ。自分が関わったプロジェクトで、素敵なものが誕生して触っている時間はたまらない。これは確実にいいものじゃんと心から思えるものができるととても楽しい。大学時代にもそういう経験があった。会社に入ってからもそういう経験は何度かあった。
そういうものをきちんと作りたいのに、うまく作れないとフラストレーションがたまる。変化に弱い設計だったり、自分の理解が足りなくて、うまく使いこなせなかったり。刃こぼれしたデザインナイフで作業しても気持ちよく作業はできないし、絵筆の使い方がわからなければいい絵を素早く書くことはできない。だから設計について学ぶし開発の手法を考える。
ということがしたかったはずなんだけど、最近忘れていた気がする。とにかく物事を効率的に、失敗しないように進めることばかり考えていたと思う。もっと生き生きと毎日を過ごすべきだと思う。
あんままとまってないけど、ブログなんてこんなんでいいっすわ
自分は去年にgolangを始めたのだが、だいぶ面白かった。golangそのものは登場してからすぐ試したりはしていたが、 := といった構文や、型を後ろにつけるスタイル、classがなくstructでよしなにやっていくスタイルなどがなんだか気持ち悪いな、と感じてやめてしまったのを覚えている。あの時もう少しgolangをやっていたらよかったかも、と感じていた。今回も同じような気持ちになった気がしたのでブログが書きたくなった。
TypeScriptでReactを書いていて、エラー処理を知りたいなと思って調べていたら、 componentDidCatch というものを知った。これと getDerivedStateFromError をうまく使えばError Boundaryといって、子Componentのエラーをキャッチして、そのComponentの代わりに他のコンポーネントを出したり、エラーログを送信するような仕組みが作れる。
なるほど便利だ。と話していたら、こんなのもあるよ。と id:EBAGmasa に教えてもらった。
Suspense は簡単に言ってしまえば「ロード中...」といった非同期処理中にやってあげたい処理を簡単に書ける仕組み。もう少し抽象的に書くと、データの取得と、その状態による動作を分けることができるものと思ってる。これを使うための構文が一見とても奇妙なものになっていることが気になるポイントだった。Promise を throw するのだ。 throw は Error のために使うものじゃん！？と思っていたから、受け入れがたかった。わかるよ。わかるけどねー。。という気持ち。（詳しくは↑の記事を読む。 wrapPromise の部分）
なんじゃこりゃーと友達とdiscordでわいわいしていたら、 id:progfay がoverreacted.ioのこの記事を教えてくれた。
我々向けの Algebraic Effects 入門 — Overreacted
ReactチームのDanさんの記事で、Suspressの背景を詳しく説明してくれている。Suspressは、Algebraic Effectsというものからインスピレーションを受けたものだった。この記事の中には、何度も繰り返し「見た目に惑わされるな」という文章がたくさん出てくる。
構文自体は大事ではありません、ひとまず概念の表現として必要なものを考えてみただけです。
もう一度いいますが、具体的な構文や特殊なキーワードはあくまでもこの記事専用のものです。そこが問題ではなく、重要なのは仕組みの方です。
（そう、Promise が throw されるんです！心で理解してください）
すいません。すいません。と思いながら読み進めると、背景がよく理解できて面白い。Algebraic Effectsそのものはよくわかっていないが、本当にやりたいのはこういうところなのだと感じた。
Algebraic Effects は JavaScript のようなちっとも純粋ではない言語にとっても、非常に強力な形で「何」と「どうやって」を分離する道具になりうるということです。
謙虚に前置きをしながら、何をしたいのかを説明してくれる。
これは Algebraic Effects それ自体ではありません。この仕掛けはそこからインスピレーションを得たものですが、別物です。それでも同じ目的を達成します。つまりコールスタックの下の方にいるコードが、コールスタックの上にいる何か（ここでは React）に後を譲る際、間にいる関数はそのことを知らず、また async やジェネレータに「感染」しないようにするということです。
この段落はさらにここからが面白い。
もちろん、JavaScript で実行を後から再開することなど本当はできないのですが、React から見ると、Promise が解決した時に再レンダリングをするというのはほぼ同じようなものです。プログラミングモデルが冪等性を前提にしているからこそできる芸当です！
自分が冪等性ということを意識したのはReactを始めてからだと思うけど、その冪等性を守ってきたことで、こういったアイディアを取り入れることができるようになったというのはグッとくる話。（詳しい人には当たり前かもしれないのだが。。。）きっとコンピュータサイエンスの研究者の間では、昔から研究されてきたことなのだと思うけど、それがようやくみんなが使えるレベルまで落ちてきつつある、というのは部分が面白い。overreacted.ioの記事を読んでいてさらに興味深いのは、Algebraic Effectsそのものを実装しようとするというよりは、そのアイディアを拝借するという点。
ちょうどDanさんがこんなツイートをしてましたが、まさにこんな感じなんだろうなと思う。（左下からは「複雑すぎる」右の人からは「全然なってないよ」）
my fp alignment chart pic.twitter.com/gz6fBRNbIi
— Dan Abramov (@dan_abramov) 2020年7月25日
実は、公式のドキュメントにはthrowなんて一言も出てないのでした。デモ用のサンドボックスには記載がある。
実際は、データフェッチのライブラリとかを使っていくことになるのかもしれませんね。それでも、こういう内側の概念を知っておくのは重要に感じた。
