azu
azu
コミットメッセージについて特に何も決めてなかったけど、 [conventional-changelog/CONVENTIONS.md at master · ajoslin/conventional-changelog](https://github.com/ajoslin/conventional-changelog/blob/master/CONVENTIONS.md) のルールに大体したがって書いている。 `write()`という独自の記号を増やしてるけど… [ajoslin/conventional-changelog](https://github.com/ajoslin/conventional-changelog/) ベースのCHANGELOGを自動生成するために使ってるようなものなので、CHANGELOGに入れたほうがいいようなコミットは`chore`ではなくて`fix`を使ったほうがいいとかそれぐらいのイメージでやってる。 `feat`, `write`, `fix`, `docs` がたしかCHANGELOGにでるコミットの対象
> https://github.com/azu/promises-book/blob/master/CONTRIBUTE.md にコミットメッセージを追加した
[Asciidoctor](http://asciidoctor.org/) に依存した書き方を使っていい事を追記した
https://github.com/azu/textlint-plugin-asciidoc-loose と textlintを使って簡単にはチェックしてる
unhadnled reject イマイチ知られてない気がするので、最終的には章として出すイメージにしたほうがいい気がするなー Nodeの問題はデバッグの問題じゃなくてexit codeが変わるというのが結構実害。(将来直すらしいけど、いつ治るんだろ?)
[Node.jsでUnhandled RejectionsのときにExit Statusが0となる問題を回避する | Web Scratch](https://efcl.info/2020/03/20/node-unhandled-rejections-exit-status/) 一応書いたけど、もう少しUnhandled Rejectionとはというアプローチで書きたい
> [[JS]JavaScriptにおけるPromise/A+仕様を、チュートリアル形式で詳しく解説します - YoheiM .NET](http://www.yoheim.net/blog.php?q=20140310) > なぜこのような非同期の要件が仕様にあるのか? 結局は[2.3. コラム: Promiseは常に非同期?](http://azu.github.io/promises-book/#promise-is-always-async)で言ってることと同じで、同期的な実装だと場合によっては呼び出し順が変わってしまうという問題あるので、常に非同期とすることでこの整合性を解決するという感じっぽい。 逆説的には非同期の処理ができないPromiseならば、同期的に解決されても問題ないという解釈になるのかなー。 もうちょっと仕様レベルの解釈が欲しい
SyncPromiseって名前は何か使うと幸せにならない感じというのは置いておいて、 このSyncPromiseはthenableじゃないけど、`Promise.resolve(syncPromise)` したらどうなるんだろ? - [x] `Promise.resolve(syncPromise)` の挙動 ダメそう
> [モナドの本当の力を引き出す・・・モナドによる同期/非同期プログラミングの抽象化 - scalaとか・・・](http://d.hatena.ne.jp/xuwei/20150329/1427599055) 何かダックタイピングに見えてきた
> [Promises: The Sync Problem (part 1) | getiblog](http://blog.getify.com/promises-part-1/)