orange @[email protected]

ATSやったり大量にアメリカのトラック動画見まくる前は多段MTなトラックに憧れがあったけど、実際どんな感じかだんだん知っていったら「AT(AMT)でおk＞＜」になった＞＜

casemod文化が一時的に壊滅して光り物が嫌われてた時期、ちょうど高速電脳が潰れちゃったの覚えてるけど、2008年だったっぽい＞＜

2008年2月2日号 高速電脳が事実上の倒産、負債額は約2億円 https://akiba-pc.watch.impress.co.jp/hotline/20080202/etc_kosoku.html

一時期のcase mod文化がほとんど死んだ謎の期間がなんだったのかマジで謎＞＜；(オレンジはもとから光り物系好き＞＜)

「この記事書いた人 絶対iPhone使ってそう＞＜」って思ってツイッター見に行ったらやっぱiPhone使ってた＞＜

オレンジは「とにかくイカの耳を用意する！＞＜」って発想で長期間使えるものを作ろうとするかも＞＜
(イカの耳参考記事 https://www.shutoko.jp/ss/shutokonews/archive/trivia/201803.html )

分割出来る場所を作る(モジュール化)と、将来モジュールを接続して拡張する余地をとにかく用意しておく事でオレンジ流のシンプルを保って「何十年でも使い続ける事が出来るか？＞＜」に応えてるかも＞＜
で、最初からなるべくそう書こうとしても記事も指摘する早すぎる最適化の問題も起きるので、ある程度実験コード的に書いてから同記事が否定してるリファクタリングによって将来性のあるコードに書き換えていくみたいな流れで書いてるかも＞＜

シンプルなコードかつ将来を考えずデザインしてなおかつ必要に応じて機能を足していったらどんどんスパゲティ化するかも＞＜
「柔軟性を犠牲にシンプルにする」のであればあらゆる想定済みではない機能の追加を避ける事が必要になってしまう＞＜
そうするとあらかじめすべての機能が揃った状態で設計する事になる(シンプルでは無くなる)か、小さいソフトウェアの組み合わせ(UNIX流シンプル)にするということになるかも＞＜
UNIX流シンプルの発想で「それぞれがシンプルで単機能な小さなサービスの組み合わせによって実現する手法」がつまり(この記事でもdisられてる)マイクロサービスかも＞＜
矛盾してる記事かも＞＜
https://www.mindtheproduct.com/overengineering-can-kill-your-product/

余計な「念のため」でプロジェクトが死に至る「オーバーエンジニアリング」の問題とは？ - GIGAZINE https://gigazine.net/news/20211126-overengineering/

Overengineering can kill your product - Mind the Product https://www.mindtheproduct.com/overengineering-can-kill-your-product/

8割くらい同意出来ないかも＞＜(この通りにしたら数年しか使えないものが出来上がるかも＞＜)

youtubeのジャンルボタン？の「ライブ」の所押したら出てきたyoutuber/VTuberのゲーム配信の内訳数えたら、19個がポケモンで8個がそれ以外のゲームだった・・・＞＜

VTuber、みんなポケモン配信やってる・・・＞＜

当時取材した記者さんのこの記事の、

飛騨川バス転落事故の話 ブン屋のたわ言
http://home.r07.itscom.net/miyazaki/bunya/tawagoto.html#hida

"【 遺体安置所で見た忘れられない光景 】"
の部分の話、無神論者なオレンジ的にこう・・・あれかも＞＜(？＞＜；)

ていうか、バイパス化がそもそも遺族を中心にうったえられ続けて長年実現しなかったのがやっと的なあれかも＞＜

ちなみに西武001系はものすごく嫌い＞＜(安全性を優先させなかったから＞＜)

50000系、前頭部が冒険しなかったら名車だった可能性＞＜(ある意味全否定＞＜；)