orange @[email protected]

それに、LRTを通した/通った だけでは解像度が低すぎる情報になってこれも無秩序開発に繋がる＞＜
路面区間でも、ビジネスやショッピングエリアであれば、サイドリザベーション式やモール化が最適になる＞＜
逆に郊外エリアであれば、道路状況にもよるけど、平均速度の面と騒音を考慮してセンターリザベーション式になる＞＜
速達性が要求される場面や都市外縁の住宅地エリアや大型ショッピングモールがあるようなエリアであれば、路面化は避けるべきだし、
都市の中心部で都市の構造上、路面では著しく平均速度が落ちるのであれば、歩行空間との一体化は犠牲にして地下化するのが最適になる＞＜(ドイツで多いパターンで北米にもある)
その場合はLRT(狭義のライトレール)とは別にストリートカー(路面電車)を整備する例が多々ある＞＜

ていうか、まず都市計画ありきでそれにあわせてLRTや公共交通を作るものであって、日本は都市計画の制約が極端に弱いので、元ツイートの考え方だけだと結局沿線の無秩序開発に繋がって、そして無秩序開発は公共交通とのミスマッチに繋がる＞＜
先に沿線にどういう建物なら建てていいのか決めなきゃいけない＞＜

完全にそれはそうなので、だからこそ気持ち悪い書き方に見える＞＜(主処理と順に実行する関数をわけて欲しい＞＜)

あと、そういう例だとC# の場合はインタフェースが使われる構造になる気がする＞＜

たとえば子クラスで必ず前処理と終了処理が実装される事を要求する場面ならば、前処理、主処理、後処理の関数として、主処理だけ親クラスに書いた上で、前、主、後って順に呼ぶ実行関数を別にする方がよくない？＞＜
スライドの書き方だと必須なんだかオプショナルなんだかよくわかんない構造に見えるし、変更にも弱そう＞＜

前後の処理をabstractな関数で定義しておく書き方になってる例も、オレンジには気持ち悪いコードに見えた＞＜
オレンジだったら、対象の関数をオーバーライドして親クラスの関数を呼ぶコードの前後に前後の処理を書くってするから＞＜
ていうか、順に実行する必要があるものであれば、真ん中部分の関数から前後を呼ぶなんて気持ち悪い書き方しないで順に呼ぶ関数を分ける＞＜

さっきの記事の筆者、著書のレビューにも書かれてたけど、static多用しまくるのが好きらしいけど、スライドの例みたいなのでも、スライドの例より複雑な状況だと引数がとんでもない量になったり、関数が余計に分割されまくりでコード量が爆発的に増えたり、引数がとんでもなくならないように引数用の複雑な構造体を作りまくったりってなるじゃん？＞＜
オレンジも開発初期の試行錯誤コードはそんな感じでぶっちゃけ恥ずかしいけど、そういうのを解消するようにリファクタリングしてオブジェクト指向な環境が提供する機能に頼って簡潔にしたコードにしてくってしてるよ＞＜

でも、本当にキレイに書いてないと恥ずかしくて大々的にコードを公開するのは恥ずかしいので、ちゃんと清書したやつしか公開してない＞＜；
(頼まれたりお節介で作ってあげた時には、コードもzipで固めて一緒に渡すことが多い＞＜)

オレンジが頼まれたりお節介で超高速で数時間とかでWindowsアプリ作れるの、それまで作ってきたアプリが多少汚く書かれてても(＞＜；)、「ちょっと違うアプリも簡単に作れるようになってるフレームワーク」の上に作るみたいなやり方で作ってきた蓄積があるから、
「そういう目的だったらあのアプリのあの部分と、あっちのアプリのあの部分を持ってきたらすぐ書けるかも＞＜」って事がそこそこ多かったのもある＞＜

ちなみに夕方書いたこれはこの場面では間違ってた＞＜；(のでその後書き換えた)
https://mstdn.nere9.help/@orange_in_space/112149301949664511
これだと別のキーでソートする時に、前のキーで反転させると続けて反転になっちゃう＞＜；
これだと一般的なlistviewの挙動と違う＞＜；

NAudio自体のプロセス別のループバック対応、開発者の人が一人頑張ってるんだけど、なんか苦戦してるっぽい＞＜

で、作ってる録音アプリもアプリ自体が目的じゃなくあくまでデバッグ用であって、選択したプロセスからの音のみをループバックするのを簡単に出来るようにするフレームワークで、将来的にはNAudioとも組み合わせて使えるようにする予定＞＜