corepackデフォルトにしようぜ！ってPRを出したらcorepackが消されるの、なんのお笑い？(改めて議論されたということだとは思いますが)

corepack死亡マ？？

他に「OrG」なんて書いてるサービス見たことないんだけど、Slackの内部資料には「OrG」で統一しろって指示が書かれてるの？

Slack Enterprise Gridで出てくるOrganizationの略称としての「OrG」、なんでこんな変なcasingなんだろうと思って英語版確認したら英語版では「Org」で統一されてて首360°ねじれた

衝動買いをキメた 明後日には届く

慣れればあとで一気に切り替えるのも意外とできたりする

より具体的には、初回実装時点で「将来的にこれはやりたいかも〜」が見えているところまでは設計しておき、そのときに見えなかったぶんはあとで頑張る

念の為帰宅してリモート作業の陣

こんなこともあろうかと、無限に未来が考えられてしまうのでがっとやるしかない

昼休みまで耐久して無理そうなら早退の所存！

若干風邪気味な気もするしそんなことない気もする シュレディンガーの体調不良

Tailwindが良くないのは所詮CSSの糖衣構文であって得られるCSSを意識しないと使い物にならないから思考コストを下げることもなくなんの抽象化も導入しないことにあると思うんです

ガヴのデザインビルドドライバーすぎん？とは思ってたが差し込み部分すら同じ大きさか

ねむすぎ

renovateに@dependabot mergeを送りつけてしまって恥ずかしい

MastodonもわりかしやらかしてるAPIいくつかあるしな

HTTP Methodに変なものいれるとさすがに色々な道具がぶっ壊れるもんでな
あとほとんど情報のないCustom Methodに対して既存のHTTP Methodを対応付けることで冪等性とかの付加的な意味を与えられるのは大きい
キャッシュの制御などが可能になる

実際このAPIのGuideもURLの作り方とかは独特なセンスが光っている

同じエンジニアが書いたわけではないので中身をみて判断するのが妥当かと

Custom Methodは作っていいってGoogleも言ってる(なぜか503でスタイルが死んでるが)
https://cloud.google.com/apis/design/custom_methods

Block Objectがあって
Create /accounts/:id/block
と捉えるなら対になるのは
Delete /accounts/:id/block
だが、
Block/Unblockというカスタムメソッドがあると捉えれば
Block /accounts/:id
Unblock /accounts/:id
を作るという設計が自然に見える

このアカウントは、notestockで公開設定になっていません。

"型安全性は"

"TS処理系" があるわけではないので実行時にはなんの保証もないという観点ではCレベル