スレ立てるまでもない質問はここで 154匹目

**デフォルトの名無しさん** · 2020/09/07(月) 18:56:51.64

**デフォルトの名無しさん** · 2020/09/13(日) 19:13:59.60

>複雑で実装の変化も速い構造になりがちな、アプリケーション
単純な構造をもったものの組み合わせなんじゃないの？
結局の所は

**デフォルトの名無しさん** · 2020/09/13(日) 19:18:57.12

>>83
> それは実装
理由は？単におまえて主張してる過ぎない。

どういうHTMLを作るかは仕様できめること
好き勝手にHTMLを生成してはいけない
なぜならテストできないからだ

**デフォルトの名無しさん** · 2020/09/13(日) 19:21:27.96

生成するHTMLを仕様として定義しない場合は、実際に問題が発生する

それは既に書いてあるとおり書いてあるとおり
htmlの構造を変えるにはCSSを詳しく調べないといけなくなる

**デフォルトの名無しさん** · 2020/09/13(日) 19:26:54.59

>>84
業務システムでは単純に見える項目でも内部が複雑化することはある

**デフォルトの名無しさん** · 2020/09/13(日) 19:28:19.81

コンポーネントが生成するHTMLを仕様として定義すると
デザインを別の人が担当できるというメリットが有る

また生成するHTMLは仕様として決まってるわけだから
コンポーネントが完成する前から
デザイン担当者はデザインを作ることができる

**デフォルトの名無しさん** · 2020/09/13(日) 19:31:29.63

>>85
HTMLは実装

仕様とは>>79のような物を言う
このような仕様を満たすために出力されるHTMLは実装にほかならない
仕様が先にありその仕様を満たすHTMLを実装するんだ

**デフォルトの名無しさん** · 2020/09/13(日) 19:32:24.15

>>82
だからスタイルはそれに当てはまらないだろう。
動作が同じだからといって内部で新しいエレメントが追加されたらそこだけ見た目が変わってしまう。
それを変更できるようにしてもらうなら、それを使う側からしてみれば扱うカスタマイズポイントが
1つ増えるわけで、何のことはない結局内部構造を把握するのと手間は変わらないわけだ。
コンポーネント開発者側の手間が増えるだけで何もいいことはない。

**デフォルトの名無しさん** · 2020/09/13(日) 19:33:22.59

>>89
> HTMLは実装
はい、また理由を言えない（笑）

**デフォルトの名無しさん** · 2020/09/13(日) 19:33:37.71

ヤンクミの法則。

**デフォルトの名無しさん** · 2020/09/13(日) 19:35:00.54

HTMLは仕様であり、先に定義することで
デザイナーとの分担作業が可能になる

どうせ大規模プロジェクトを経験してなくて
自分でデザインまで作ってるんだろうな

**デフォルトの名無しさん** · 2020/09/13(日) 19:38:23.37

>>90
> 動作が同じだからといって内部で新しいエレメントが追加されたらそこだけ見た目が変わってしまう。

これ、フロントエンドを理解してないやつがよくやる間違い
内部で新しいエレメントを追加・削除しないと変えられないと思ってる
実際は状態（class属性等）に応じて表示状態（displayスタイルなど）を変更すればいいだけなのだ

class属性等に応じて表示状態を変えるだけだから
JavaScriptはシンプルになるし、速度も軽くなる
コンポーネントが完成していなくても静的なHTMLとして記述しclass属性等を
変更するだけで状態に応じたデザインを作ることができる（分担作業）

**デフォルトの名無しさん** · 2020/09/13(日) 19:39:29.29

状態（≒見た目）が変わっても内部構造は変わらない
これがシンプルな設計において重要な点

**デフォルトの名無しさん** · 2020/09/13(日) 19:42:49.59

単一の情報に対して複数の表示法を与えようとするのは、ウェブ作成者の多くがまともな大学を出ていないことと関係あるのでは？

**デフォルトの名無しさん** · 2020/09/13(日) 19:46:07.97

例えばタブインターフェースなんか、タブ1枚目、タブ2枚目、タブ3枚目があったとき
1枚目を表示するときは、1枚目だけを表示して、2枚目、3枚目は非表示にするだけでいいのだ

そのために必要なのはタブの表示ページ番号を示す属性を変更するだけ
あとは簡単なCSSですべてできる
JavaScriptはほんの3行程度、ラジオボタンを使えばJavaScriptゼロにだってできる

これをわざわざクリックされたときに1枚目を作成して
2枚目、3枚目は削除するなんてJavaScriptの処理を書いて
HTMLとCSSをJavaScriptに埋め込んで
わざわざして遅く面倒にしてるのが（アホな）コンポーネント厨

**デフォルトの名無しさん** · 2020/09/13(日) 19:46:13.31

HTMLを仕様として定めると、そのHTMLを前提としたCSSが無秩序に量産されるというリスクがある
そうなると、既存のCSSを変えずに、コンポーネントの構造を変えることが難しくなる
内部実装であるHTMLに、クライアントであるCSSが依存しているからだ

今日はインプットテキストだったコンポーネントが、要件変更で明日にはリストボックスになっているかもしれない
そういった変化があった場合に、コンポーネントのソースコード以外を変更する必要があるなら、そのコンポーネントはインターフェースと実装の分離ができていない証拠だ

HTMLを仕様と定めて、クライアントにCSSの実装を許すと、このような変化には耐えられなくなる
実装であるHTMLを外部に漏らしてはいけないのだ

**デフォルトの名無しさん** · 2020/09/13(日) 19:47:46.26

>>96
お前の願望を言うのはお前が低学歴なのでは？ｗ

**デフォルトの名無しさん** · 2020/09/13(日) 19:48:19.46

>>98
> HTMLを仕様として定めると、そのHTMLを前提としたCSSが無秩序に量産されるというリスクがある
ないよ

どこから出てきたんだか（笑）

**デフォルトの名無しさん** · 2020/09/13(日) 19:48:57.79

>>98
> そうなると、既存のCSSを変えずに、コンポーネントの構造を変えることが難しくなる

コンポーネントの構造を変えようとするな
複雑になるだろ

**デフォルトの名無しさん** · 2020/09/13(日) 19:49:06.63

>>94
お前htmlの構造を変えるって言ってたじゃん。>>71>>86

**デフォルトの名無しさん** · 2020/09/13(日) 19:49:59.28

>>98
> 今日はインプットテキストだったコンポーネントが、要件変更で明日にはリストボックスになっているかもしれない

だからそれ仕様変更ですよね（笑）

**デフォルトの名無しさん** · 2020/09/13(日) 19:51:40.17

>>71は俺じゃねーよ

>>86にちゃんと書いてあんだろ

> 生成するHTMLを仕様として定義しない場合は、
> htmlの構造を変えるにはCSSを詳しく調べないといけなくなる
だからHTMLをしようとして定義し、HTMLの構造を変えるときは
仕様変更になると

**デフォルトの名無しさん** · 2020/09/13(日) 19:52:24.50

>>97
単純なお遊びのアプリケーションしか作ったことがないとこういう発想になりがち
転送量やセキュリティの観点から非表示にするだけでなく要素そのものを取り除くことは珍しくもない

**デフォルトの名無しさん** · 2020/09/13(日) 19:53:45.51

>>105
> 転送量やセキュリティの観点から非表示にするだけでなく要素そのものを取り除くことは珍しくもない
だからそういう理由があるときだけ複雑にしろよ

なぜやらなくていいときまで複雑にするのか→考える脳が無いから。全部同じやり方しますアポポッポポポｗ

**デフォルトの名無しさん** · 2020/09/13(日) 19:54:11.08

複数のビューとか、Excelで要らんってわかったんじゃないのか。
もう20年以上前にわかってるもんを、いまさらやってどうなるというのか。
やっぱウェブ系は頭悪いな。

**デフォルトの名無しさん** · 2020/09/13(日) 19:54:39.72

>>101
遊びで作るようなちゃちいアプリケーションならそういうことを考えなくていいんだろうな
簡単そうな要件の仕事してそうで羨ましいよ

**デフォルトの名無しさん** · 2020/09/13(日) 19:57:27.38

>>103
重要なポイントはその仕様変更の影響がコンポーネントの外部に漏れるかどうかだ
コンポーネントの内部実装としてスタイルを閉じ込めておけばコンポーネント以外は修正しなくていい

**デフォルトの名無しさん** · 2020/09/13(日) 19:57:29.54

>>107
複数のビューが何を言ってるのか知らんけど、
コンポーネントの状態によって見た目が変わるのは普通の話

それをJavaScriptを使って状態によって構造を変化させて
CSSを適用しづらくして、うわーっとなって
全部JavaScriptにしてやるーって叫んでテストの工数を増やすか

状態が変わっても構造を変化させずに、同じ構造だから
CSSが適用しやすく、状態によっての見た目の違いはCSSでやれるから
JavaScriptコードが少なくなって、処理速度も速く
宣言的な記述でバグもテストも少なくなるかの違い

**デフォルトの名無しさん** · 2020/09/13(日) 19:58:05.27

HTMLは文書ではない！データのコンテナなのだ！などと、グーグルの受け売りが正義とか思わないでほしいのだが。
ウェブ系の馬鹿は考える頭が付いていない。

**デフォルトの名無しさん** · 2020/09/13(日) 19:58:06.54

>>109
HTMLの構造を変化させなければ、なにも外部にもれない
お前のやり方が根本的に間違ってるんだよ

**デフォルトの名無しさん** · 2020/09/13(日) 20:02:13.75

>>106
理由が出来た時に容易に対応できるようにコンポーネントにするんだよ

**デフォルトの名無しさん** · 2020/09/13(日) 20:03:05.61

>>113
YAGNI（それは必要にならない）
KISS（シンプルにしておけボケ）

**デフォルトの名無しさん** · 2020/09/13(日) 20:08:02.62

>>112
いやいや
HTMLの構造はこうですって、仕様にしちゃったらそれはもう外部に漏れてんだよ
その仕様を前提に、どこのだれがどんなCSSを書いたかなんてわからねえぞ
いざHTMLの構造を変える時に、無駄な調査工数がかかる
HTMLは仕様ではなく実装である、とすればHTML構造はいつでも変化しうるんだ、ということが誰にでもわかる
なのでCSSを気軽に追加するバカもいなくなる
コンポーネント内部のHTML構造の変更のために、バカバカしい調査をする必要もなくなるわけだ

**デフォルトの名無しさん** · 2020/09/13(日) 20:08:11.90

オンライン会議の参加者それぞれにexeファイル渡し、マイクから発言時間をリアルタイムで記録して会議の進行役が盛り上がり具合を見れるものを作ろうと思ってます

とりあえず触ったことのあるc#で音声認識ライブラリを使って時間を記録し、それをデータベースに送信して管理する形を考えているんですが
、言語とか使うデータベースこんなのがいいってありますか？

ズブズブの素人なので的はずれなこと言ってたらごめんなさい

**デフォルトの名無しさん** · 2020/09/13(日) 20:08:45.61

>>115
> HTMLの構造はこうですって、仕様にしちゃったらそれはもう外部に漏れてんだよ
それは仕様なんだからインターフェースだ
デザイナと共同作業をする場合に必要なことだ

**デフォルトの名無しさん** · 2020/09/13(日) 20:09:13.68

>>115
> その仕様を前提に、どこのだれがどんなCSSを書いたかなんてわからねえぞ

デザイナーの仕事だ、お前には関係ない話だ

**デフォルトの名無しさん** · 2020/09/13(日) 20:09:31.03

>>114
した結果がコンポーネント

**デフォルトの名無しさん** · 2020/09/13(日) 20:10:06.72

>>115
> いざHTMLの構造を変える時に、無駄な調査工数がかかる

いちいち変えるな。仕様として決めないで
いきあたりばったりで作業してるから、変えることになるんだろ
無駄な調査工数がかかるのも、いきあたりばったりで仕様を残してないからが一番の理由だな

**デフォルトの名無しさん** · 2020/09/13(日) 20:10:48.20

>>117
インターフェースは軽々しく変えてはならない
HTML構造はインターフェースほど安定したものではない
ちょっとした要件の変化に応じて変えていくものだ
HTMLはインターフェースにはなりえない

**デフォルトの名無しさん** · 2020/09/13(日) 20:11:24.96

>>118
関係ないで無視したらデザインがぶっ壊れるだろ

**デフォルトの名無しさん** · 2020/09/13(日) 20:11:57.70

>>115
> HTMLは仕様ではなく実装である、とすればHTML構造はいつでも変化しうるんだ、ということが誰にでもわかる

HTMLの構造は要求が変わったときだけ変化する
見た目が変わっただけでは変化しない

逆に言うならば、見た目を変えるだけならば、HTMLの構造は変化しない
それはすなわちコンポーネントを変更する必要がないということだ

見た目は容易に変わるが、コンポーネントの機能はさほど変化しない

お前のように見た目とコンポーネントが強く結合してしまってりゃ
見た目の変更でコンポーネントに修正まで入るんだろうなｗ

**デフォルトの名無しさん** · 2020/09/13(日) 20:12:48.01

>>122
> 関係ないで無視したらデザインがぶっ壊れるだろ

HTMLの構造を勝手に変えるからだ
仕様なんだからちゃんと連携とってかえろ

お前のように見た目とコンポーネントが強く結合してしまってりゃ
見た目の変更でコンポーネントに修正まではいってそれどころじゃないんだろうがなｗ

**デフォルトの名無しさん** · 2020/09/13(日) 20:12:49.66

>>120
だから何度目だ
変えなくてもいいようなド単純なオモチャアプリケーションならHTMLは固定、で許されるのかもしれねーが
そんなオモチャは学生の課題ぐらいでしか通用しないよ
今はエンタープライズの話をしてるんだが

**デフォルトの名無しさん** · 2020/09/13(日) 20:13:54.80

> 変えなくてもいいようなド単純なオモチャアプリケーションならHTMLは固定、で許されるのかもしれねーが

どんなものでも要件が変わらないならばHTMLは固定でよくなる
状態によって、HTMLの構造が変わることはない

**デフォルトの名無しさん** · 2020/09/13(日) 20:14:19.93

>>123
だから何度目だ
エンタープライズでは機能が変わっていくんだよ
オモチャアプリケーションを前提に話すのいい加減やめたら？

**デフォルトの名無しさん** · 2020/09/13(日) 20:14:59.29

ガワ変えられない設計はあかんやろ

**デフォルトの名無しさん** · 2020/09/13(日) 20:15:04.33

エンタープライズっていうのなら、コンポーネントの開発者と
デザイナーは担当者が別だ。
別々の人が並行して作業できなければ役に立たない

**デフォルトの名無しさん** · 2020/09/13(日) 20:15:45.05

>>127
> エンタープライズでは機能が変わっていくんだよ

機能が変わるってことは要件が変わるってことだ
お前はまったく別の話をしている

状態によってHTMLの構造は変わらないという話をしてる

**デフォルトの名無しさん** · 2020/09/13(日) 20:18:12.95

>>116
一定時間ごとに画面のキャプチャを収集して画像の差分を追いかけて
サボってるやつ検出するやつ作ろうぜ

**デフォルトの名無しさん** · 2020/09/13(日) 20:18:49.06

いや、やっぱやめて絶対に作らないで

**デフォルトの名無しさん** · 2020/09/13(日) 20:19:06.00

>>124
話を理解してくれ

連携を取れというがその連携が大変だと言ってるんだよ
HTMLを仕様として周知してしまったから
他の開発者やデザイナがそのHTMLを前提にCSSを開発することが合法になってしまった
各CSSの開発者に新しい仕様を説明してすべての箇所を間違いなく修正させる必要がある
それは大変な作業だ

一方でコンポーネントが可変部分をインターフェースとして提供していれば、内部HTMLの変化をわざわざ再周知する必要がなくなる
クライアントはもとのインターフェースに従って利用しているわけだからコンポーネント側が後方互換を維持すればいいだけ
連携なんぞ必要ない

**デフォルトの名無しさん** · 2020/09/13(日) 20:20:33.74

> 連携を取れというがその連携が大変だと言ってるんだよ
> HTMLを仕様として周知してしまったから
> 他の開発者やデザイナがそのHTMLを前提にCSSを開発することが合法になってしまった
> 各CSSの開発者に新しい仕様を説明してすべての箇所を間違いなく修正させる必要がある
> それは大変な作業だ

ああ、他の開発者との連携して開発すること全く考えてないｗ
大変だから、一人でやる。小さなプロジェクトしか経験してない証拠だな
他の開発者との連携して開発するのはやることとして大前提なんだよ

**デフォルトの名無しさん** · 2020/09/13(日) 20:21:55.75

>>130
は？要件が変わるって話をずっとしてんだが

**デフォルトの名無しさん** · 2020/09/13(日) 20:22:53.84

>>135
要件が変わったなら、それを仕様にまとめろ
かってに作業すんな

**デフォルトの名無しさん** · 2020/09/13(日) 20:28:05.21

>>134
オモチャ屋さんにはわからないかもしれんが
連携しなくてうまく行くようにできるなら、それが最も安全で効率的なのでそうする、ってのがシステム屋の常識なんだよ

で、システム屋はそれをどうやって実現するかっていうと
安定したインターフェーのみをクライアントに公開して、変化しやすい内部実装は隠して触らせない、って方法で実現してんの

お前はみたいに変化しやすいHTMLをクライアントのインターフェースとして提供してしまうと、しなくてもいい連絡が増えて、みんなが苦労することになる

**デフォルトの名無しさん** · 2020/09/13(日) 20:31:19.42

>>137
今はHTML構造とデザインの話をしてる

HTML構造は仕様であり、デザインは別のものが担当する
大前提を理解しろ

HTMLはデザインの変更程度では変化しない
複雑なものを作るから、頻繁に変えなくちゃいけなくなるんだよ

複雑なものは単機能を持つ基本的なコンポーネントの集まりとして作れ
どんなにアプリが変わっても、単機能のシンプルな基本ライブラリが変わらないのと同じことだ

お前が今苦労してるのは、複雑なものを作るからだ

**デフォルトの名無しさん** · 2020/09/13(日) 20:33:57.58

>>136
だからさぁ

仕様はまとまってるし変更があれば修正するよ
でもな仕様変わってもインターフェースまで変わるとは限らねえんだよ
コンポーネントにスタイルを閉じ込めとけばインターフェースは安定すんの
だからクライアントの変更なしにコンポーネントを更新できんの

お前はみたいにHTMLを仕様ですなどと言い張ると
ちょっとした要件変更のためにインターフェースとしたHTMLが変化して
それを大多数の開発者に周知しなきゃならなくなる

**デフォルトの名無しさん** · 2020/09/13(日) 20:35:35.43

> コンポーネントにスタイルを閉じ込めとけばインターフェースは安定すんの

ほらまた、コンポーネントとスタイルを結合させて
メンテナンス性を下げてるｗ

そこはデザイナーが担当するの
HTML構造をインターフェースとして定めてるから安定してんの

**デフォルトの名無しさん** · 2020/09/13(日) 20:36:53.97

> ちょっとした要件変更のためにインターフェースとしたHTMLが変化して
> それを大多数の開発者に周知しなきゃならなくなる

まさか口伝でもしてんのか？ｗ

**デフォルトの名無しさん** · 2020/09/13(日) 20:40:17.52

>>138
変化は必然なんだよ
最初はインプットテキストだったものがシステムの成長に伴ってリストボックスやオートフィルに
さらに育って検索用のリッチな小窓を出すようになる
変化がないのはチュートリアルみたいなしょぼいシステムだけ

**デフォルトの名無しさん** · 2020/09/13(日) 20:41:36.47

>>140
メンテナンス性を上げるためにコンポーネントを作ってる
HTMLに伴って変化しうるCSSを分離して遠ざければメンテナンスは難しくなる

**デフォルトの名無しさん** · 2020/09/13(日) 20:42:51.29

>>141
なわけねーだろ
ドキュメントを更新して通知すんだよ

**デフォルトの名無しさん** · 2020/09/13(日) 20:45:13.10

構造とデザインだとXML+XSLもアリかとも思うけどほとんど見ないな
それとも知らないだけで使われてる？

**デフォルトの名無しさん** · 2020/09/13(日) 20:45:47.84

>>144
じゃあ周知はそれで終りましたねｗ

**デフォルトの名無しさん** · 2020/09/13(日) 20:46:29.91

>>145
> 構造とデザインだとXML+XSLもアリかとも思うけどほとんど見ないな
XSLはセンスが悪かった
今はHTMLとCSS

**デフォルトの名無しさん** · 2020/09/13(日) 20:47:55.64

>>142
だから仕様が変更になってデザインを変更する必要が出たら
デザインを変更するだけだろ、何いってんだお前ｗ

**デフォルトの名無しさん** · 2020/09/13(日) 20:51:56.11

HTML6はXAMLにしようよ

**デフォルトの名無しさん** · 2020/09/13(日) 21:00:27.50

機械的に吐き出した実行結果のレポートにはXML最強(特にXPath連携)なんだけど、イマイチ使いにくいからな

**デフォルトの名無しさん** · 2020/09/13(日) 21:52:12.09

>>149
xhtmlは論理的で論理的で良いと思ったんだがなぜか人気がなかったな。

**デフォルトの名無しさん** · 2020/09/13(日) 21:53:51.19

90年代の発想でコンポーネント連呼するやつおるんやな

相手にしすぎるのもどうかと思うで

**デフォルトの名無しさん** · 2020/09/13(日) 23:45:50.26

Ruby on Rails の動画でも見れば？

Bootstrap, React を使って、コンポーネントを再利用する

**デフォルトの名無しさん** · 2020/09/14(月) 07:01:28.67

>>151
俺は最初からXHTMLは駄目だ（意味がない）と気付いてたけどね

XHTMLは人間用のフォーマットであり非構造化されたデータだ
具体的に言うと（半）構造化されたデータの周りに広告やその他の情報が
あちこちに散りばめられてる。そういったものを機械的にパースするなんて無駄で困難な作業でしかない
データとして再利用可能にしたければ、そもそもXMLとして構造化されたデータとして提供すべきだ

データが再利用可能であれば人類にとって嬉しいかもしれないが
XHTMLはデータを再利用を考えずに人間が読むために作られる
場合によっては再利用されたくないかもしれない。運営側の都合でHTML構造が変わるかもしれない
だからXHTMLは安定した形式にはなりえない

自動生成の都合上XHTMLに"なってしまう"場合はあっても
人間のための形式をあえて構造化されたXHTMLにするべき理由がないんだよ

XML（論理的で構造化されたデータ）→人間のための加工（非構造化を含む処理）→XHTML なのだから
加工する前のXMLを使ったほうが便利
XSLが失敗したのも人間のための加工処理が構造化されてない加工処理
つまり「特定の部分だけ例外的な処理を行う」の集まりだから
もちろんXSLTをXMLで記述するというのも悪いデザインだった
本質的に処理であるものを定義で書こうとすると冗長で柔軟性がなくなり破綻する

**デフォルトの名無しさん** · 2020/09/14(月) 07:14:29.77

>>150
> 機械的に吐き出した実行結果のレポートにはXML最強(特にXPath連携)なんだけど、イマイチ使いにくいからな

最強じゃないよ。
タグに属性なんてものがあるから、ストリーミングデータとして扱いづらい。
実行結果というのは1行1行レポートされるものが結構ある

XMLは下の階層のデータが全部揃わないと上の階層のデータが確定しない
あるタグの終りは、それを内包するデータが全て揃ってからになる
1行（もしくは1データ）ずつ処理することが困難
すべての実行結果がそろってやっとレポートを見ることができる

これはXMLだけではなくJSONでも同じだが
JSONの場合それを解決するためのJSONLという形式ができた

Excelファイルのように保存してあとから見るような使い方であればいいが
リアルタイムで実行結果をレポートするようなものには使いにくい

**デフォルトの名無しさん** · 2020/09/14(月) 07:42:49.11

>>155
つ XMLフラグメント

実行中にレポート出すなら、SAXで切り出していけば問題ない、というかXMLでログ出すときって全部蓄積するなんて無謀だからそれ以外には無いよな

**デフォルトの名無しさん** · 2020/09/14(月) 07:47:58.20

それはxhtmlならデータとしても再利用できるという夢物語の話な。
単純に、従来のhtmlより論理的でパースが楽でnamespaceで拡張できるhtmlとして期待してた。

**デフォルトの名無しさん** · 2020/09/14(月) 13:15:25.51

swiftのパフォーマンスを改善する、みたいな記事で、変数をstaticにするとパフォーマンスが改善した、と書かれていました。
https://qiita.com/Kazuma_Nagano/items/c5e22ea095d247a3de52

私はstatic変数を使ったことがないため、何故なのかよくわかりません。

static変数について調べてみると、「メモリ位置を固定化する」と書かれているので、感覚的には何となく速くなるのかな？とは分からなくもないのです。

しかし、私はメモリの扱いについても素人なため、何故メモリの位置が固定化されるとパフォーマンスが良くなるのかがいまいち理屈で理解できません。

どうしてstaticを使うとパフォーマンスが良くなるのでしょうか？

**デフォルトの名無しさん** · 2020/09/14(月) 13:19:09.60

>>158
もし、毎回ループごとに上書きされるような変数を定義する場合は全部static変数にしてしまった方が良いのでしょうか？
staticにするデメリットはあるのでしょうか？

**デフォルトの名無しさん** · 2020/09/14(月) 13:21:03.97

staticが速いんじゃありません。
時間がかかるものを何度も実行するから遅いんです。

**デフォルトの名無しさん** · 2020/09/14(月) 13:23:29.84

>>159
全く意味はありません。

**デフォルトの名無しさん** · 2020/09/14(月) 13:27:03.20

static変数にした結果遅くなることもあります。

**デフォルトの名無しさん** · 2020/09/14(月) 13:28:50.68

>>160
ありがとうございます。メモリを固定化しない場合、空きメモリを探したりするという処理に時間がかかる感じでしょうか？

>>162
どんな場合に遅くなることが考えられますか？

**デフォルトの名無しさん** · 2020/09/14(月) 13:42:59.81

> 空きメモリを探したりするという処理に時間がかかる感じでしょうか？
そうだね。0.000000001秒ぐらいかかると思うよ

**デフォルトの名無しさん** · 2020/09/14(月) 13:44:25.41

> どんな場合に遅くなることが考えられますか？
そのメモリに対して他アプリやOSの処理が発生する時

**デフォルトの名無しさん** · 2020/09/14(月) 13:49:58.29

本物の初心者は○○を使えば速くなるとかいうガセにつられて
○○を使ってこの方が速いって噂を聞いたんですよ！という
間抜けなことだ

**デフォルトの名無しさん** · 2020/09/14(月) 15:40:08.92

>>164-165
ありがとうございます！

**デフォルトの名無しさん** · 2020/09/14(月) 16:20:38.01

>>166
今回は「変数をstaticにするとパフォーマンスが改善した」というガセ自体が存在してないけどね

**デフォルトの名無しさん** · 2020/09/14(月) 16:44:28.40

staticおじさん呼ばれていますよ

**デフォルトの名無しさん** · 2020/09/14(月) 17:29:35.40

プログラミング知識で0からSwiftを勉強するとして、簡単なトランプゲームのアプリを作るまでにおおよそ何時間ぐらい学習が必要でしょうか。
ワークスAPの筆記通るレベルの頭は一応あります

**デフォルトの名無しさん** · 2020/09/14(月) 18:10:16.50

作りながら学習した方が良い
頑張れば今日中にでも作れる
あと筆記の成績なんて関係無いよ。プログラミングはカンニング前提でやるものだし

**デフォルトの名無しさん** · 2020/09/14(月) 18:29:26.16

>>170
トランプゲームを作りたいのか？
作業的な勉強が一番挫折しやすい

**デフォルトの名無しさん** · 2020/09/14(月) 18:41:16.20

C#、WPFで質問です
MVVMで構築されたシステムですが、Modelから直接Viewのコントロールを触ることは不可能でしょうか？

**デフォルトの名無しさん** · 2020/09/14(月) 19:03:57.65

>>173
間違いかも知れないが、MVVMはView側からViewModelを参照するのがキモだと認識している
そもそもVのことはMとVMは知らないはず

**デフォルトの名無しさん** · 2020/09/14(月) 19:05:57.15

>>174
ありがとうございます。やはり無理な話でしたか・・・

**デフォルトの名無しさん** · 2020/09/14(月) 19:08:24.08

プログラミング未経験ですが自分で使うお小遣い帳を作ろうと思っています
C#とデータベースの勉強を勧められてそれでやってみようと思うのですが
とりあえずWindowsで動くものができたらAndroidでも動くものが作りたいです
その場合同じくC#で作れるのでしょうか？

**デフォルトの名無しさん** · 2020/09/14(月) 19:21:44.92

>>175
だから、Viewに対してxxさせる方法があったはず
と調べたらトリガーという機能があった
これだったかな？もう四年ほどやってないと怪しくなる

**デフォルトの名無しさん** · 2020/09/14(月) 19:25:44.53

>>175
ViewがViewModelを参照して任意の動作を「自分から」やるのが、多分正解
これならMVMはVと疎結合になるからそう思う

**蟻人間** ◆T6xkBnTXz7B0 · 2020/09/14(月) 19:34:16.26

>>176
WindowsとC#でAndroidアプリ作成なら、XamarinとSQLiteでイケると思う。

**デフォルトの名無しさん** · 2020/09/14(月) 19:37:14.79

>>176
C#で作れます

**デフォルトの名無しさん** · 2020/09/14(月) 20:35:29.14

>>179
>>180
どうもありがとうございます
具体的なフレームワークやデータベースの名前も挙げていただき調べやすくなりました、助かります

**デフォルトの名無しさん** · 2020/09/14(月) 22:43:08.69

>>172
遅レスすみません。
例えば、本当に単純にはなるんですけどハイアンドロー（次のカードが今出ている数字よら上から下か予想してトランプをめくるゲーム）や、少し難し目でいけばBluetoothを使って近くにいる人でブラックジャックができるようなものを作りたいと考えております。

**デフォルトの名無しさん** · 2020/09/14(月) 22:44:00.48

>>171
ありがとうございます。
とりあえずつべこべ言わず、見様見真似で始めればいいって事ですね。