新しいものを表示

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

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

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

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

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

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

mstdn.nere9.help/@orange_in_sp

オレンジが今作ってるこれの対象プロセス選択部分も、対象プロセス選択部分を直接作ったんじゃなく、Windows Core Audioのセッション群を簡単に扱えるフレームワーク(簡単に音量ミキサ自作できるフレームワーク)をまず作ってそれを流用してるし、
そのフレームワークも12年前に作りかけたレベルメータのフレームワーク部分を参考に清書したもの><

[B! オブジェクト指向] オブジェクト指向は必要なのか / Is object-oriented needed? b.hatena.ne.jp/entry/s/speaker

なに言ってんだこいつ><(素直な感想)
ウェブ界隈の方々って、フレームワークを作り上げていくようなやり方はせずに、他のものに流用しづらいコードを書くようなやり方をするのが普通なの?><
フレームワーク作るなら必要だけど作らないなら不要って、それで不要っていうならつまりフレームワークを作るようなやり方はしてないってことでしょ?><

これ、その人々の性格での色々だけじゃなく、事故なんかの遺族が求める改善策も同様だよね><
「同じ目に遭う人が二度と出ないように」って願ってる遺族に「お辛かったでしょう。補償します」なんてして改善策の要求をのらりくらりとかわすと神経を逆撫でする事になる><

「謝れ」っていう人や、その人が有利になるようにしろって人には対応簡単かも><
謝ったりなんか優遇すれば済むわけだから><
「謝るんじゃなくて、問題を解決でき二度と同じ過ちを繰り返さない改善策を作るんだよ><# 」って人にはそれは通用しない><;

なんで、この応対されると「ふざけんな><# 」ってなるか簡単に言うと、共感されたいんじゃなくて問題解決したいので、問題解決に優先して共感を重視されると「解決する気あんのか!><# 」ってなる><
オレンジの母親が菓子折り出されると逆に怒ることが多々あるのもそれに近いかも><

[B! コミュニケーション] 「あ、いま傾聴の技術を使って話を聞こうとしてるな」とわかると急に話したくなくなることってない?不愉快になる理由 b.hatena.ne.jp/entry/s/togette

傾聴の技術ってなにそれ?>< と思って読んで、
「あ!>< これオレンジもこの応対されると『お前話理解してないだろ><# 』ってキレて応用問題出して『理解してないじゃないか><# 』って問い詰めるやつだ!><;」
ってなった><;

コンビニ定番の「ワッフル」 ルーツはなんと古代ギリシャで、日本独自の進化も遂げていた【連載】アタマで食べる東京フード(6) | アーバン ライフ メトロ urbanlife.tokyo/post/40766/

オレンジ的には、回頭性を重視するかしないのかがMRを選択するかの・・・あれだと思ってた><(語彙力)

orange さんがブースト

あと、二輪駆動のMRを否定してる文脈だけど、ミッドシップ四駆のMID4はそこに該当しなくね?
ってツッコミもちゃんと書いてある

orange さんがブースト

"曲げやすいクルマ"と"曲げにくいクルマ"の二元論ではなく
"コーナリングの限界性能は高いけど、そこを超えた瞬間に突然ブレークするピーキーなクルマ"と"限界は低いけど、そこを超えても突然挙動を乱さないドライバーにとってコントロールしやすいクルマ"を比較した話とワタシは解釈したんだけど……

自動車メーカーは趣味で車を作ってるんじゃなく商売で作ってるわけだからMID-4の完璧な市販車バージョンを作れなかったのはいろいろな制約でしょうがないけど、
でも、採算性や現実的な開発費等をあえて無視して技術面のみに単純化して考えたら、あのパッケージから逃げただけなんじゃないの?><
って思う><(もちろん、金に糸目をつけずに無理に作ってたら経営がさらにやばくなってただろうから無理があるけど><)

R35みたいなのを当時作りたかったけど、世界の技術水準では時期尚早だったって話で考えるとそりゃ結果のR35もFRだけど、
でも、あれってフロントミッドシップじゃね?><;

曲げたい時には曲がってくれてスピンさせたくない時にスピンしないクルマが優れてるクルマであって、「これじゃスピンしやすい!」って曲がりにくくしたら曲がりにくいクルマじゃん?><
曲げたい時には曲がりやすく、曲げたくない時には安定するを、なるべく確実に行うために電子制御があるわけじゃん?><
「スピンしないようにする制御が大変!」ってシャシを曲がらなく作ったら、電子制御しても曲がらないクルマじゃん?><

ていうか斜め読みで書いたけど、GT-Rの下りはオレンジと意見同じ?><;

古いものを表示
:realtek:

思考の /dev/null