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

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

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

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

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

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

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

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

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

このアカウントは、notestockで公開設定になっていません。

あれは前頭部は「？＞＜；」ってなることはなるけど、全体としては乗客本位で作った上で整備性の問題もきちんとデザイナーが現場の声聞いて修正したデザインにしたりとか、鉄道デザイン事例としては製品もプロセスも結構いい感じの事例って思うかも＞＜

微妙にカットしたら括弧の対応と日本語おかしくなった＞＜；

この余計なことをせずに一貫して、機能を基準にしたデザインにしてれば反発は少なかったんでは？＞＜； 「必然的にそうなる」と納得いくデザインになるし＞＜

インダストリアルデザインには商品側の都合を隠蔽して、『顧客がどう使うかをベースに商品を作るデザイン』(最近のカーデザインの多くはそうだろうし、ラパンのコンセプトカーや現行モデルも特にそうかも、大賀時代までのかつてのソニーや現在のAppleも代表例)と、『機能と機構をベースに最適な形を導き出すデザイン』(ロケットや新幹線(500系はちょっとだけ例外)ってわけることが出来るかも＞＜

現行アルトは、太古の名作大衆車のように機能と機構をベースにしたデザインで出発しておいて、でもそれは貫徹せずに妙にブレちゃったからこうなったんでは感＞＜

【スズキ アルト 新型発表】初代アルトの真似ではなく「リスペクト」…デザイン | レスポンス（Response.jp） https://response.jp/article/2015/01/06/240996.html

"...むやみにキャラクターラインを入れるなど、デザインのためのデザインをするのではなく、シンプルでクリーンなデザインを実現したのだ」と述べる。

しかし、「フロントは少しだけ遊び心を入れている」と内山さん。「もちろん必要以上にデザインしてしまうと全体のバランスを崩すので、メガネをモチーフにしてヘッドライト周りをデザインすることで、ちょっとだけ目力を出して表情を作った」。"

だからどっちつかずになったのか感・・・・＞＜

LOVE CARS! — Web Automobile Club - 【スズキ新型アルトのデザインを検証する】　#LOVECARS http://lovecars.jp/article/2015/01/1888/

オレンジ的にはあのグリルって1980年代リバイバルデザインに見えたかも＞＜
そのデザインの祖先(？)の1970年代の家電にも近く見える＞＜

2002.1.24 【スズキ『ラパン』発表】東京モーターショー…見せたくないけど、知って欲しい | レスポンス（Response.jp） https://response.jp/article/2002/01/24/14473.html
"...「市販車のカタチをぼかしたかったんです」と語る。「あの時点では、なるべく本当の姿を、他のメーカーさんにも知られたくなかった。でもラパンを知って欲しかったんです」という。..."
で、「コレジャナイ・・・」になって数世代かけてコンセプトカー版に近いデザインになおした流れ？＞＜；

ちゃんと調べてないのでわかんないけど、コンセプトカー版のラパンと初代ラパンも、Be-1ほどまでいかなくても世の中のカーデザインの流れに与えた影響それなりにあるんでは感＞＜

原案どんな感じなのか気になるけど、初代セフィーロやハイパーミニをデザインした人がなんでこういうデザインにしたのかって謎かも＞＜；
過去の作品みたいななんか思いきりとか強いコンセプトが感じられないかも・・・＞＜

2015年02月08日　日本車最大の弱点はデザイン！なぜダメなのかを考えてみた « 日刊SPA! https://nikkan-spa.jp/788831

"アウディにだって負けてないもん！ 新型アルトはなぜステキなのか？..."

"...今や世界の自動車業界のデザインリーダーたるアウディで、A6やA5などを手掛けた和田智が、今度はなんと軽自動車をやる！ いったいどんなデザインになるのかと注目していましたが、こうなりました。..."

オレンジ的には「なんでこの人が関わったのに、どうしてこうなった・・・＞＜；」だけど、評価高いの？＞＜；

x っぽくかも＞＜
o っぽく見えるかも＞＜
＞＜；

まるっこくしたいのか尖らせたいんだかさっぱりわからん的な・・・＞＜

現行アルトもだけど、女性向け意識したデザインをベースに無理に男性向けにもしました感があってどっち付かずで微妙に見えるかも・・・＞＜

あと暗いと寝られないので、キャンプの時はシュラフの中でちっちゃい照明つけて寝る＞＜(おうちでは蛍光灯つけたまま寝てる＞＜)

毛布大好きなので掛け布団無い＞＜(もふもふの毛布が二重になってる＞＜)

夏で、初心者向けの設置済みの備え付けの大きいテントに泊まるって形態で、本来はキャンプ場側が(寝袋じゃなく)毛布を貸してくれるシステムだったんだけど、オレンジは「もふもふの毛布じゃないと寝られないの＞＜；」って駄々こねた結果オレンジだけおうちから毛布持ってった＞＜

小さい頃はじめてキャンプ場に行った時に普段使ってるもふもふの毛布をわざわざ持ってったの思い出した＞＜(2回目からは普通の寝袋)

これも10年の時を経て同じコード(ライブラリ)転用して作ってる＞＜
Delphiメインにしてた時の感覚が残ってる時に書いたコードなのでC# なのに命名規則が一部Delphiのコーディング規約になってる懐かしいコード＞＜；

オレンジとしては、公開するライブラリ作るみたいな意味でそうしてるんじゃなく、基本的に一人で作ってるから、次に同じような事をする時に楽したかったり、GUIだけ違うものをあとで作ったり出来るようにそういう風に作るので、構造が「他の人にとって使いやすいか？」じゃなくて「何年後のオレンジがこれを再利用できるか？＞＜；」みたいな事しか考えて無いかも＞＜
で、実際に10年以上前のコードから引っ張って来て使うとか普通にしてる＞＜

派生大好きなので、依存のツリーで言うと幹方向になるけど＞＜；(ややこしい＞＜；)

ていうか、説明難しいけど、パッケージになってないというか、そもそもツリー状に作られてるので、前に作ったあるライブラリなりアプリの「あの時書いたコードを転用して楽しよう＞＜；」って時には、当たり前だけどその部分からの依存部分というかツリーの枝方向のコードは使うけど幹方向のコードは使わないかも＞＜

内部の部品単位でも使えるようにしてあるので、使わない部分は使わないし、例えば「音楽ファイルのメタデータの取得だけがしたい！」って場合はメタデータ読む部分だけ引っ張ってきて使うかも＞＜
ていうか、だからこそDataとかInfoみたいな単語がついちゃう型名が結構発生しちゃうかも＞＜；

結構汎用的だと思うけど＞＜
一回ライブラリ作っておいて互換性も保ち続ければ次にオーディオ再生したい時にそのライブラリにファイル投げてPlayってするだけで音ならせるし、曲名とかも取得できる＞＜

実際には、バラックな実験コードな第一段階のアプリ作って、そのコードをリファクタリングしながらライブラリを構築していって、基本機能がライブラリに移っていくみたいな流れで作るかも＞＜
バラックな実験コードはぐちゃぐちゃで、ライブラリ化していく時に再利用と将来性を意識した書き方に変える感じで、そういう風に作ったライブラリを長期間あちこちで使い回したりする感じ＞＜

アプリ作るときのやり方の違いでもあるのかも？＞＜
オレンジは例えばオーディオプレイヤーアプリを作る場合は、オーディオプレイヤーを簡単に作れるライブラリを作りながらそのフロントエンドを作るみたいな方式で作るかも＞＜
オーディオプレイヤーに限らず使い捨てではないアプリ作る時はだいたいそんな感じかも＞＜

オレンジ方式は、『音楽』が『音声データ』と『曲名等のメタデータ』を持つ(『...』がそれぞれ型)だけど、
らりおさん方式だと、『メタデータも持つ音楽』が『音声データ』を持ってるみたいな構造になってるの興味深いかも＞＜
オレンジの発想だとメタデータこそフォーマットが安定しない(ある形式ではジャンル名があったり、音圧の情報が追加されてたり)って発想があるので、上位にある『音楽』型が将来仕様変更が少なくなるように、メタデータは別の型へのハンドルにするって発想かも＞＜

オレンジ方式の「フラットに持つデータは複雑にさせずツリー状ににしよう＞＜」って設計、深くなった時にすごいことになるというデメリットがあるし、命名が冗長的だと結構とんでもない事になる＞＜(よくなってる＞＜；)

デザパタブームの時に学んだ内容もう1ミリも覚えてなくてほぼ自己流になってる＞＜；

あとオレンジが書いたみたいな方式とかオレンジの傾向ってつまり「データをなるべくツリー状に扱いたい」 かつ 「それぞれは明示的に命名された型であることが望ましい(無名の型や既成の型はある程度避ける)」みたいな感じの発想になってるかも＞＜

実際のライブラリだとStreamになってる事多いかも＞＜
ファイルかオンラインかハードウェアからきたやつかとか区別無く扱いたいのと、デコーダを外部用意する構造にする必要が多い(説明難しい＞＜；)ので「適切なデコーダがStreamからデータ読む」みたいにするかも＞＜

この事例ではそう＞＜
曲名とかって再生とか技術的な面(？)では直接は関係ないけど、でもプレイヤーとしてはくっつけて扱う方が便利じゃん？＞＜

つまりらりおさんの例示で言うと

struct Sound {
channels: u8,
len: Duration,
repeat: bool,
waveform: Vec<u8>,
　metadata: Audiometadata, // ←こんな感じの構造にする場面の時にDataとかInfoみたいな単語がつく命名が出てくるかも＞＜
}

それで言うと、Sound構造体にメタデータ型へのハンドルがあるみたいな構造がオレンジ方式かも＞＜

それってつまり単一の型で表す(.net frameworkではそうなってる事が多い気がする)か、またはハンドルはハンドルでメタデータはメタデータで完全にバラバラの型を作りハンドルとメタデータの関係性の表現には型システムを使用しないって発想じゃん？＞＜

「複雑化を防ぐためにひとつの型が持つプロパティ等の数が極端に増えすぎないようにしたい」＆「ハンドルとメタデータの関係も型で表現したい」ってなるとオレンジ方式になる気がするというかそういう考え/場面でそうしてる＞＜

オレンジの事例の音楽そのものって、再生可能なオーディオデータのクラスで、生のデータ(を持つバイト列やストリームのクラス)や長さの情報やチャンネル数等は持ってるかも＞＜
でも、メタデータはメタデータであるので別って発想でそのクラスにベタに曲名プロパティとかアーティストプロパティみたいなのとかキーバリューなメタデータリスト等を直接置いたらごちゃっとしそうだから、ベタに置くのは避けたかも＞＜

Infoとかそれはメタ情報(？)であるって単語等を型名につけない文化圏、例えばオーディオプレイヤーアプリ作る時に、曲名とかの情報をどういう構成でどういう風に扱ってどう命名するのか謎＞＜
オレンジは曲クラスが曲名等情報クラスを持ってるみたいな構成にして、曲名等情報クラスの名前はInfoかなにか忘れたけどなんかそういう「これはメタ情報である」的な命名してたような記憶ある＞＜

x「『
o『
＞＜；

ていうか、Infoとかついてないのは「『そのもの』であって、『そのもの』では無くそれに関する情報のみしか持ってない物は例外的である(ので、Infoなりなんなりつけて注意喚起する)って、OOP的発想・・・？＞＜

オレンジはわりとHogeDataとかHogeInfo的な型名多用してるかも＞＜；
ハンドルを含むような物がHogeとしてあってそれとは別に同じ対象のハンドルを含まないものが必要な場合にはHogeInfoとか使うかも＞＜

このアカウントは、notestockで公開設定になっていません。

このツイートの人、ビジネス上のパートナーをオンライン飲み会に誘いそう＞＜

https://mstdn.nere9.help/@hadsn/107335315276884077
ていうかこれの2個目のツイートの"この出来事があったので"に続く部分、昭和のオフィスじゃん＞＜ この職場とプライベートで分けない感覚、オンライン化しただけでむしろ発想が昭和のオヤジ(いま60歳くらいの世代)じゃん＞＜

常時接続的な人間関係を持ちたい(/持ってる)のは親しい人であってビジネス上の人間関係では無いだろって指摘激しく同意＞＜