MSFSでMarketplaceがグレーアウトした
2021/04/07時点のバージョンの話
先日のバージョンアップ辺りから起動直後にXBOXの画面が見えてそれからMarketplaceがグレーアウトして使えない...それはそれで困る...
まぁF15飛ばしたいとか困るので対応を探していくと・・・
OSに英語のlanguage packが必要なのでOSの設定でインストールする
XBOXコンソールコンパニオンっていうソフトウェアを入れる
XBOXコンソールコンパニオンでStoreと同じアカウントでログインする
というステップが増えてた
ここをみると何やら見慣れない奴が居たのでこっちを参考にしてみた
この対応方法を色々頑張ってたんだけどダメだった
マーケットプレース等のグレーアウト問題 - Microsoft Flight Simulator 日本語 Wiki*
ここも見たんだけど、今回はダメだった
（IPv6を通さないルーティングもやってみた）
XBOX対応を進めてるのか〜っていうので理解は出来るけどだったら必要なソフトウェアのインストールもセットでやってくれ！
認知範囲
人にはそれぞれ認知してる範囲があって
その範囲外のことは知る事が出来ない
でもその範囲外からの影響を受けることが多々あって
それの反応は
無視する
拒絶する
受け入れる
の3つ、それぞれメリット・デメリットはあるけど
ただ、人が他人の能力を見る時は自分の認知範囲に他人の認知範囲を重ねるので、案外低く見がちになる。
特に自己評価の高い人は認知範囲が広いと思い込んでる場合があるので面倒なことになる
極まれに認知範囲のめっちゃ広い人とか、そもそも認知範囲が存在しないような動きの人がいる。
この二つの人を識別するのは難しい
認知範囲を広げる方法は唯一、範囲外からの影響を受け入れて興味を持つことだなぁ〜って思った
要はバランスなんですよ・・・っていう意味
あるときに「そのバランスをどう取るのかが難しいんだよ！」って聞こえてきて、そうなんだ・・・なんでだろ・・・って思っててしばらくしてお風呂で理解した
バランスを取るには
周囲の力関係の理解が必要で
周囲の力関係の中で良い塩梅に設定することを
要はバランスなんですよ〜の一言で片付けてた
まずは周囲の力関係の理解を先にしないと意味がなかった
ということで、周りのライトサイドとダークサイドの力関係を理解しつつ
フォースのバランスをとることが大事って事で
シスにならないように頑張る
ってことですね
（↑これを書きたかっただけ
設計とか...
気になったって話でそれ以上のオチは無い
色んな人と話をしていると、プログラミングは出来る。 しかしテーブル設計が出来ないとか、設計技法はあまり知らないって人が一定数居ることに気がついた (居ること自体は個人的にはどうでも良いんだけど...知らない事があるなら勉強すれば良いのでは？って思ってるだけなので)
プログラムには必ず裏にデータモデルがあって、どっちが重要って事もないし プログラムを楽に作るには必ずデータモデルの設計があって データモデルの設計の一つにテーブル設計があって それらを手順化して組み合わせたのが設計技法だったりするわけで...
プログラムが出来るのに設計が出来ないってどういうことだろう・・・というか出来るってなに？って思ったｗ
最近の設計・実装のながれ
随分前とだいぶ変わったのでメモ代わりに
# 原則
- 処理で2次元を超えるのデータは可能な限り設計段階で避ける
- 処理で2次元を超えるのデータは可能な限り実装段階でも避ける
- 次元数は可能な限りあげないように設計段階で避ける
- どう頑張っても2次元を超えるなら漏れないルールを作る
# メモ
1次元のデータを扱う実装は簡単に作れてあんまりミスが起きない
2次元までは人が頑張れば作れる
3次元以上は能力的に圧倒的な差が生まれる
なので、1次元〜2次元のデータを扱うようにすると・・・一部がだいぶ多次元にならざるを得ないので、そこをルールでがんばって押さえ込む
「なに」と「どう」
何を作るのか
どう仕組みを作るのか
何で作るのか
どういう手順で作るのか
何で運用するのか
どう運用するのか
っていうのがバラバラに存在してて、個別に議論されてて
でも、議論してる人達がみんなそれぞれ別の「なに」と「どう」を抱えてるのがうっすら透けて見えてて、それを認識できてなさそうな人達がいろんな形で絡んだりしてて
世の中はなかなか難しいな
って思ったお昼のひと時
手法とか技術力とかの差異をぼんやり考えてたら...
前提として
ある人が可能なことと、他の人が可能なことは一致しない
ただし、色々と学習や経験をしていくと可能になったりする
何を考えたか
作るべきソフトウェアは実際には形状の決まってない 何か である
それを各自の持つフィルターを通してみることで形状が見える
フィルターの形と大きさと透明度は各自に差がある
この各自の差が能力的な差に繋がる
あるエンジニアJは
ABCっていうフィルターを使えるエンジニアは
ABCっていうフィルターでソフトウェアを理解しようとする
その結果、ABCっていうフィルターを通した形ソフトウェアが完成する
あるエンジニアIはABCとCDEっていうフィルターを直感的に適切に使い分けている
ただし、通常はABCっていうフィルターが好きなのでABCを使おうってみんなに言う
ABCしか使えないエンジニアJは、エンジニアIの言うことに従えば同じ事が出来ると思い込んで、CDEのフィルターを学習せずにやってみる
結果的に上手くいったり、上手くいかなかったりする
これはABCっていうフィルターの問題ではなく、フィルターは複数を使い分けるべき事があるって事を指してる
エンジニアの初期の頃はフィルターの大きさは小さく透明度も低い
それが経験を通して大きく、透明度が上がる
結果的に作るべきソフトウェアがよく見えるようになる
これが容易に超えられない経験の差として見えるようになる
単なる経験年数を積み重ねたところでフィルターの大きさとか透明度は上がらないので、フィルターを大きくして透明度を上げる努力が必要になる
そもそもの作るべきソフトウェアは形状の決まってなく観測したフィルターによって見える形が変わるのなら、単独のフィルターの優劣はそこまで影響はなくて
いくつのフィルターを使えるのか、それぞれの大きさと透明度はどのくらいなのかが実はエンジニアとチームの優秀さの決定ポイントなのでは？って思った
