orange @[email protected]

ポピュラー音楽考古学（？）おもしろい＞＜＞＜

https://www.youtube.com/watch?v=uuxyNym5zpk
これが(1938)

https://www.youtube.com/watch?v=EW62xr7cDb0
こうなって(1958)（新発見！＞＜）

https://www.youtube.com/watch?v=Q2dq6pU4J80
さらにそのアレンジを元にカバーされて(1972)

https://www.youtube.com/watch?v=dZp9ugHctCY
インスト版＆改題されて(1975)、なるほどザワールド(放送開始は1981年)・・・・＞＜

これしらなかった！！！！＞＜；

https://www.youtube.com/watch?v=EW62xr7cDb0

https://open.spotify.com/track/21grPMeC2Qo7Qm4GnhG4fK?si=yNcmH3J7TSawAmtCpkL2XQ
これ1958年の録音らしいけど、
Zing! Went the Strings of My Heartの The Trammps版（1972）って編曲の下敷き？元ネタ？があったのか＞＜；

混乱＞＜

（/////

大は小をカーネル＞＜

！＞＜

例えとして適切かも微妙だけど、
自分が過去に作った(作ってしまった)仕様に対する互換レイヤを作るのは、将来性をうまく考慮できなかった事に対する十字架を背負うようなものかも＞＜
それを気軽に投げ捨てるのはまた気軽に同じ過ちを繰り返すと宣言するようなものかも＞＜

そうでもしないとスキルが向上しないで、使い捨てのその場かぎりしか通用しないものしか書けないままになっちゃうかもって面も大きい＞＜

オレンジ的にはその古い間違った仕様を一度書いてしまったのであれば、その事を反省し続けながらサポートしなければならないし、新しく書かれるものでは使用せず代わりに何を使用すればいいのかの案内を十分に長期に渡って行わなければならないし、そうしないとまた気軽に『将来非互換な仕様変更をしなければならなくなるような酷い仕様』を作ってしまうって考えてる＞＜(企業のウェブサイトのトップページに不祥事のお詫びへのリンクが長期にわたりあるのと同じような事かも＞＜)

なのでオレンジが自分でしか使わないライブラリとかでも(最終的には使わない事も多い)互換機能持ってたりする＞＜

オレンジが言いたいこととしては、外向きのAPIがどうのとかに限った話じゃなく、あらゆるプログラミングの要素は、互換性とその維持の為の将来性を考えながらプログラミングするべきだし、克服不可能あるいは困難な非互換が生じてしまったら土下座するつもりで望むべき！＞＜ みたいな心構えがみたいな・・・・＞＜

元のゲームの仕様変更で、土台MODが用意するAPIの仕様がある程度変わっちゃうのはしょうがないけど、そんな範囲越えて全然互換性考えてない変更されてたりでムカついてる＞＜

オレンジが今頼まれて(？)やってるAPI変更でめんどくさすぎるの、ぼかさず書くと、ゲームのサーバーサイドのMODで数年前のバージョンの非公式MOD API向けに書かれたあと放置されてるオープンソースなMOD　を、最新の非公式MOD APIで動くようにってしてる＞＜

出来るっぽさ？＞＜

オレンジがプログラミングでなんか書く時に互換性が失われるのであれば必ず古い仕様のものを扱う為のコードも残すってしてるから、そうじゃないの見ると「・・・・・＞＜」って感じになる＞＜(いま頼まれて(？)いじってるものも古いAPI向けに作られてるものを最新のバージョンに対応させてるんだけど、APIの仕様変更が酷すぎてめんどくさすぎるし、なんで互換APIを用意せずに仕様変更するのか＞＜＃ )

DBまともにあつかった事無くてさっぱりわかんないけど、古いの残したまま新しく別に構築して、新しい方になかったら古い方から読む、その上でマイグレーション処理は余裕分でのんびりやる(何週間後には終わってたらいいな的な)みたいに書くとかは無理なの？＞＜