こういう風になってるからスケスポさえ見つかれば何とかなっちゃう＞＜ https://mstdn.nere9.help/@orange_in_space/99267355649054733
orange
さんがブースト
orange
さんがブースト
数学が得意な方のひとだ
『プログラマの数学 第2版』《サイン本無料プレゼント》 https://snap.textfile.org/20171229214054/
そうなっちゃうって言いたかった＞＜； あと工夫を放棄すると極端に悪い意味での富豪的かもって＞＜
orange
さんがブースト
枯れたライブラリで不足している分を自前のラッパーや補助ライブラリで補っていった結果、枯れたライブラリ側の仕事をだいぶ奪っているとかあった
おささんの判断のように、この部分の挙動がそのままソフトウェアの重要な挙動になる＝柔軟に実行される必要がある って考えるとよほど柔軟なライブラリじゃなければ使えない場面では？＞＜って思うんだけど・・・＞＜
orange
さんがブースト
もっとも、横蹴りにした選択がよかったのかは知らぬが…
orange
さんがブースト
枯れた定番ライブラリを使うの、運用したり開発に参加したりのハードル下げるのに一役買ってる気はするし、そこの担当範囲でのバグは少ないだろうと思ってはいるが
ていうか、マストドンが使ってるような使い方って想定外の用途なのかも？感も＞＜
orange
さんがブースト
送信先毎にまとめることができれば、無駄な再試行を減らせるし、順番守れるし、まとめて送信への道も開けると思うけれど、ジョブをマージするのは面倒な気もするし、でなければ自前のキューでも持つ感じに…うーん…
(オレンジも(rubyの文化さっぱりわからないのもあって)「なんでこんなのに既成の物使う必要あるの？＞＜」感があって謎だった＞＜(こういう所こそ書いてて楽しい部分じゃんって意味でも＞＜))
orange
さんがブースト
高機能なキューって、もっと柔軟なイメージがあったし、自分がふぁぼるっくで作ったキューは、優先度が自由に設定できて、割り込みとかかけ放題、取り出し側プロセスで処理する優先度の範囲指定とか何でもありな状態にしていた。一般にあるキューの製品って、先入れ先出しばかりで、処理順は守れるけど溜まったときの処理が大変そうだなぁと思って採用できなかった。
orange
さんがブースト
Sidekiqのタスク処理優先順位を変えるのはキューを増やす必要があるんですけど、キューを増やすとSidekiq起動時のパラメータを変更する必要があって各インスタンスで設定変更が発生するのでよほどのことがないと増やせない情勢でbetter Sidekiq が求められています。😴
orange
さんがブースト
sidekiqの仕様が分かっていないけど、先入れ先出し(FIFO)か、後入れ先出し(LIFO)かによって、他のインスタンスへの配送にも影響があるとかなら、相手に届く実績がある宛先と再試行とでプロセスが分かれても良いとは思うけどね。
orange
さんがブースト
sidekiqが溜まっていることの弊害がいまいち分かっていない。どうせいつかは完全に失敗になるか、ちゃんと届くか、のどちらかになると思っているのだけど。失敗になるまでの時間が長すぎるなら、早く失敗に移行するように設定を変えればいいだけな気もするし。
本とか専門雑誌で、本文が和暦で資料写真のキャプションが西暦とかすごく意味不明だけどわりとある＞＜；
高度はメートル法だと現実の固定翼機の特に着陸時の降下率に対して細かすぎて大変だし、速度も、うまく言えないけどメートル法だと刻みがうまくあわない＞＜；（ヘリはどうなのか知らない＞＜）
航空関連の趣味にディープになる前は、フィートとか海里とかノットってなんで使うの？＞＜；って思ってたけど今はフィートとノットじゃないと空飛べない＞＜；と思うし気象の風速もメートル法じゃなにがなんだかわからない・・・＞＜
- ＠orange_in_space
2017年 4月に登録
