半空洞男女関係

思ったこととかプログラミングしてるときのメモとか色々かいてます。メールはidそのままgmail

なぜ何かを作るのか

なぜソフトウェアを書いているのだろう。自分はどうなりたいのだろう。と色々考えていたのだけれど、久々に腑に落ちてきた気がした。一言で言えば、ヤバいものを見たいからだと思う。作り手になっていると、一番最初に完成したものを見ることができる。気に食わなければ、調整することができる、一番自分が気持ちいいところに調整していくことができる。(全てをコントロールできたなら)この瞬間がたまらなくてやっているのだなと理解した。(しかもこれでお金がもらえるなんて!)

自分でコードを書かなくたってそうだ。自分が関わったプロジェクトで、素敵なものが誕生して触っている時間はたまらない。これは確実にいいものじゃんと心から思えるものができるととても楽しい。大学時代にもそういう経験があった。会社に入ってからもそういう経験は何度かあった。

そういうものをきちんと作りたいのに、うまく作れないとフラストレーションがたまる。変化に弱い設計だったり、自分の理解が足りなくて、うまく使いこなせなかったり。刃こぼれしたデザインナイフで作業しても気持ちよく作業はできないし、絵筆の使い方がわからなければいい絵を素早く書くことはできない。だから設計について学ぶし開発の手法を考える。

ということがしたかったはずなんだけど、最近忘れていた気がする。とにかく物事を効率的に、失敗しないように進めることばかり考えていたと思う。もっと生き生きと毎日を過ごすべきだと思う。

あんままとまってないけど、ブログなんてこんなんでいいっすわ

表面的な部分に惑わされない

自分は去年にgolangを始めたのだが、だいぶ面白かった。golangそのものは登場してからすぐ試したりはしていたが、 := といった構文や、型を後ろにつけるスタイル、classがなくstructでよしなにやっていくスタイルなどがなんだか気持ち悪いな、と感じてやめてしまったのを覚えている。あの時もう少しgolangをやっていたらよかったかも、と感じていた。今回も同じような気持ちになった気がしたのでブログが書きたくなった。

TIL: componentDidCatch

TypeScriptでReactを書いていて、エラー処理を知りたいなと思って調べていたら、 componentDidCatch というものを知った。これと getDerivedStateFromError をうまく使えばError Boundaryといって、子Componentのエラーをキャッチして、そのComponentの代わりに他のコンポーネントを出したり、エラーログを送信するような仕組みが作れる。

Error Boundary – React

TIL(2): Susprese

なるほど便利だ。と話していたら、こんなのもあるよ。と id:EBAGmasa に教えてもらった。

ReactのSuspenseで非同期処理を乗りこなす

Suspense は簡単に言ってしまえば「ロード中...」といった非同期処理中にやってあげたい処理を簡単に書ける仕組み。もう少し抽象的に書くと、データの取得と、その状態による動作を分けることができるものと思ってる。これを使うための構文が一見とても奇妙なものになっていることが気になるポイントだった。Promisethrow するのだ。 throwError のために使うものじゃん!?と思っていたから、受け入れがたかった。わかるよ。わかるけどねー。。という気持ち。(詳しくは↑の記事を読む。 wrapPromise の部分)

Algebraic Effects

なんじゃこりゃーと友達と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さんがこんなツイートをしてましたが、まさにこんな感じなんだろうなと思う。(左下からは「複雑すぎる」右の人からは「全然なってないよ」)

おまけ

実は、公式のドキュメントにはthrowなんて一言も出てないのでした。デモ用のサンドボックスには記載がある。

サスペンスを使ったデータ取得(実験的機能) – React

実際は、データフェッチのライブラリとかを使っていくことになるのかもしれませんね。それでも、こういう内側の概念を知っておくのは重要に感じた。

銀の弾丸

昨日書いたブログにも繋がるかもしれない。マニフェスト掲げたところで実行するのは現場だし社会であるという。

改善は泥臭い。MVPで表彰されたあの人も、その人も、半期でサッとやった訳ではなくてそこまで積み上げてきた誰かの成果だったり、その人の長い努力だったり、タイミングがあったりする。

今では素敵なソフトウェア開発をしているどこかのチームだって地道な改善を少しずつ進めて、うまく行った結果、あそこまで行っている。という価値観でやっている。進みはのろい。

Raft

Raft Consensus Algorithm

Redis Labs、強い一貫性を保ちつつRedisを高可用クラスタ化する「RedisRaft」発表 - Publickey

Raftは知らなかったけどこういうOSSがあるんだなー。Apache Arrowを思い出した(ちょっと違うけど)