Notices by orange (orange_in_space@mstdn.nere9.help), page 32

作業デザインとしての優先順位の決定って難しいものだし、それが非常時(「忘れ物した！」も含む)であればなおさらだし、だからこそ航空宇宙分野では失敗する訓練をたくさんして異常時に正常な判断をする能力を養うし、世の中の経営失敗事例を見ても経営者になるような人でも不祥事や危機に陥ると判断力の無さが露呈するし＞＜つまり、各環境に応じた訓練や汎用的な意思決定環境構築の訓練をしなければわりと困難って事かも＞＜

使用事例が広がってった時期を考えると、たぶん2chとかでの「無限ループって怖くね？」みたいな使われ方してたのが、そういうネット界隈で育った人が社会に出ていくなかで、少しずつ「(使っても問題ない？)」的空気読みされながらフォーマルな場にも使われるようになっていったみたいな感じなのかも？＞＜

ciniiで検索してみたけど、無限ループって言葉をを数学や計算機関連以外で(論文/記事のタイトルに)用いる事例、2010年代から出てくるっぽい＞＜

とんこつ醤油鍋の素でうどん入りの鍋にして、すり下ろしにんにくたくさんいれたら、二郎うどん鍋(？)になるのかも？＞＜　みたいな発想をした＞＜

なのでオレンジがそうだったのもあるし、ベーマガ世代の人は小学生でもゲーム作って投稿してたりもしたわけで、「プログラミングを学ぶのに先に数学が必要」って意見には納得できないかも＞＜「数学よりも先にプログラミングを学んでしまうと、数学に対して偏見を持ってしまい数学教育の邪魔になる」であれば、オレンジがその通りだったので納得かも＞＜；

例えば自動車関連の解析ソフトウェアとかシミュレーター作ったりして遊んでたけど、それらを作るなら本当は微分と積分を理解してないとダメらしい？＞＜でも実際には自動車工学の教科書を読んでそれをもとに実装するのにはどの部分がどう微分でどう積分なのかという事は理解しなくても出来た＞＜だって教科書に公式が書いてあって、オレンジが知らない数学用語には頼らずに公式の説明が書いてあるんだもの＞＜

微分と積分とかベクトルとかちゃんと学んでないので一部意味不明だけど、それらが必要とされるようなプログラミングはしてたので逆に何がなんだかわからないし、(さっきの話と矛盾するけど＞＜；)むしろ「あなたがやってるこれこれこういう事を数学ではこう言うんです」って教えて欲しさあるし、実際問題としては別に困ってないという意味では教えられなくてもいいやになってる＞＜

オレンジの場合は特に数学ちゃんと学ぶ前にプログラミングし始めた結果、プログラミングの時には実用的に使えるのに学校の数学はそうじゃないっぽいし、プログラミングで使われる用語に馴染みがあるけど学校の数学の用語は同じようなものを違う言い方されるとかで、オレンジ的には「なんで非実用的なものにあわせなきゃいけないのか？＞＜；」みたいな点でも数学嫌いになった＞＜

ハードウェアの場合は、ノブの位置に対応して「その位置にあるとどういう状況である」かが書いてある事が多いかも？＞＜電源スイッチならばON　OFF　(　[])みたいな＞＜

いま大学生くらいの世代だともうGUIの標準部品には慣れ親しんでいないwebベースデザインの世代だろうし、世の中のUXデザインがゴミになった後の世代 かつ フラットデザインが溢れかえる世界でIT機器を使い始めただろうし、可愛そうなことに認知工学寄りの正しいUXデザインを学ぶのは座学で真面目に教科書読んで学ばないといけないようなそういう世界で生きてる人々かも＞＜

前にツイッターで仲良くなった人が主に自分で使う用にPythonでアプリを作りはじめたときにオレンジが色々アドバイスしてて、その人が出来上がったものを公開して実物初めて見たら、一般的にはハンバーガーメニューに近いような振る舞いの『文字もアイコンもなにも書いてないボタン』がポンと置いてあって「oh....><;」ってなった事があったけど、1990年代後半辺りではある程度は常識だったUXデザイン知識がある世代であれば頭を抱えてなんてこったいって笑い話だけど、UXデザインの退化が指摘されてる現在に生きる方々には、なにも書いてないボタンが笑い話になるような話と理解されずに「え？ ダメなの？」って人がそれなりに居るのかも？＞＜；　って思ってきてるかも＞＜

ある程度はそれはそうだけど、そもそもそういうものはほぼ必須なインフラにしてはいけないし、必須なものにしてしまったら誰でも使えるようにしなければならなくなるし、電話機なのに電話機として使うのに説明書が必要なほどに複雑な製品を売り付けようという発想も間違ってるし、実際の事例として実際にこの事例に於ては「スマホ」は「ガラケー」にすら劣ると認めなければ。世の中の機械のUXはまともになら無い＞＜

C# でソースコードがファイル1個でcsc.exeでコンパイルするのを想定したキーボード⌨を音楽鍵盤????の代わりに出来るアプリつくったらおもしろそうって思った＞＜csc.exeを使えて音が鳴らせる環境であればアプリインストールしなくても使える鍵盤演奏アプリ＞＜；

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

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

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

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

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

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

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