2020.8.13
東京から届いた8つの段ボールを開封
疲れた
今日なんか検証作業と開封と横転しかしてない
よるはピザとパスタを食べました
おいしかった
@ci7lus/prettier-config作ろうにも俺の.prettierrcは3行しかありません
code:.prettierrc
{
"trailingComma": "es5",
"semi": false,
"singleQuote": false
}
昔はもうちょい長かったけど不要っぽいの全部消して、今publicのリポはほぼこれで運用できてるはず
てか5行かこれ（うるさい）
作るべきか？
結論
https://tweet-card.now.sh/1293928811248021505.jpg?lang=ja https://twitter.com/rokoucha/status/1293928811248021505
不要
作りません
今までジョブ管理キューとしてbull-queueだけを採用してきていているが、なかなか使いにくいところも多い 具体的に例挙げるとなると難しいけど
なんか「独特の挙動」がいくつもあるのでそれを把握し切ってからでないとprodで使うのはやめたほうがいいとかそういうレベル
一番困ってるのが、redisかnodeかどちらかが余裕のない環境で動作してると繰り返しのjobのnextが過去になったまま実行されなくなってしまうというやつ
外部からの定期アクセスの一環としてnext見て必要に応じて再登録みたいな余計な手間が居る
あとredisの余裕がないのが原因なんだろうけど、jobがnullになることがある
https://gyazo.com/b8596482b44dfe1caed628ca75db3524 https://www.npmjs.com/package/bull#feature-comparison
昔ジョブ管理が欲しいな〜と思っていろいろ比較していたが、Bull他が載せてるこの比較表を見るにBullが一番っぽかったので採用した
単純な頭をしているので
Kue, Beeは既にディスコン、Bullを代替として紹介している状態だった
Beeはなんか更新を再開している感じがある
Thanks to the folks at Mixmax, Bee-Queue is once again being regularly maintained! link けどRepeatable Jobsないのは普通に困っちゃうので採用できない
実際Backendとして使えたほうが嬉しいのはRedisよりMongoだったりする
これは無料枠の都合
いやーどうかな Redisが500MBぐらいあったほうが普通に嬉しい
Job情報というのはロギングしている限り普通に飛んでいいものなので
けどRate Limiterは欲しいな普通に…
対象APIの都合上対象関数の同時実行は10以下に抑えたいとかそういうのがある
とりあえずagendaのAPIを読みこむか…
https://gyazo.com/b069a86c7ef2f3fab86cf9e7a357e4ec
https://gyazo.com/63714faa6f7e8e3fc20a59fb2f7dbc53
KindlePWの充電が97%以上にならない