21/01/27 13:36:55.01 4ZLvOcYXM.net
>>850
MVUなら必要ないよ
861:デフォルトの名無しさん
21/01/27 13:52:55.21 +quYuruPM.net
うーん
プロパティにref使えないけど
SetPropertyどうやって使ってんの？
862:デフォルトの名無しさん
21/01/27 13:53:49.65 nqDSrDWAM.net
.NET MAUIか
863:デフォルトの名無しさん
21/01/27 13:54:43.18 nqDSrDWAM.net
>>853
え?
864:デフォルトの名無しさん
21/01/27 14:09:18.65 s+2IuEm00.net
xaml登場時からやってる
ベテランの自分でさえ
xaml流mvvmは
コード量が激増して面倒臭すぎる。
ReactのJSXみたいに
xaml中にコードが直接かけるように出来んものか？
865:デフォルトの名無しさん
21/01/27 19:59:46.88 1NyuRNVoM.net
<x:Code>で囲めばゴリゴリC#書けるよ
面倒だから素直にコードビハインドに書いた方が早いけど
どうせg.csにコピーされるだけだし
まあ何につけmvvmが失敗の原因だったよね
866:デフォルトの名無しさん
21/01/27 21:48:06.42 Q5PELBL+0.net
失敗というか、WPFに挫折した人の原因ではあるのかもしれない。
867:デフォルトの名無しさん
21/01/27 22:50:02.01 I3USHUPf0.net
VisualStateManagerはBlend前提の設計かもしれんが、ちょっと解りにくいわな
868:デフォルトの名無しさん
21/01/27 22:51:44.29 VJox6Jtr0.net
MVVMってテストしやすいのはいいけど、設計難易度上がるし面倒なところあるから初めて関わる人や新人いるチームだと大変すぎてな。一人や少数精鋭チームでやれればいいけど。
869:デフォルトの名無しさん
21/01/27 23:11:30.32 lP1lXV780.net
ビューとモデルの完全分離を目指した結果
肥大化するコードと失われる可読性って本末転倒じゃん
870:デフォルトの名無しさん
21/01/28 07:46:28.72 W1L2iiMj0.net
>>856
xamlてコード分離が目的なのに中にコード書いたら意味無いような気がするが
871:デフォルトの名無しさん
21/01/28 10:15:55.24 jO4DLeJx0.net
>>862
コードを分離する
メリットとデメリットは？
872:デフォルトの名無しさん
21/01/28 10:19:43.92 pXmI1nylM.net
>>863
メリット、ユニットテストがやりやすい
デメリット、めんどくせー
873:デフォルトの名無しさん
21/01/28 10:26:33.10 jO4DLeJx0.net
>>864
ユニットテストは
やりやすいレベルにはならんよ。
874:デフォルトの名無しさん
21/01/28 10:27:16.51 p4i84vEc0.net
なるよ
875:デフォルトの名無しさん
21/01/28 10:28:56.03 jO4DLeJx0.net
ならん！
876:デフォルトの名無しさん
21/01/28 10:40:26.08 FPs7AaOb0.net
>>865
UIベッタリだと出来ないだろう
877:デフォルトの名無しさん
21/01/28 10:59:29.17 dNWrUHbO0.net
>>861
Railsですね判
878:ります
879:デフォルトの名無しさん
21/01/28 11:27:11.16 tUs9KAdY0.net
コード増えるのは辛いよな
なんとかならんのかこれ
880:デフォルトの名無しさん
21/01/28 12:09:59.78 AZvjaiaSa.net
model view を結合するのはいいけど、、
model もうひとつつくって、プログラムされたタイミングで
同期させたい
isDirtyな
double bufferともいう
881:デフォルトの名無しさん
21/01/28 12:22:12.52 s7DYC79h0.net
INotifyPropertyChanged実装しないModelクラスを、ViewModelでラップするのがしんどい。
882:デフォルトの名無しさん
21/01/28 12:25:43.67 AZvjaiaSa.net
mv結合100%だから不自由なんで、
設計でいうmodelとは別に
実装用のmodel作るべき
設計modelは切り離して
change by user
change by initialize
change by signal
も判別しなきゃだな
883:デフォルトの名無しさん
21/01/28 12:47:51.29 jO4DLeJx0.net
>>870
mvvmを捨てる事から初めてみましょう！
884:デフォルトの名無しさん
21/01/28 20:10:35.14 v7b31HK80.net
>>861
俺の言いたいことをすべてお前が大便してくれた
885:デフォルトの名無しさん
21/01/28 20:52:41.82 A1rlojlb0.net
>>868
FormsアプリをUIAutomation使って自動テストする地獄を味わったことのない人には
有難みがわからないのだろうな
886:デフォルトの名無しさん
21/01/28 21:24:14.10 eBfsAdOM0.net
そもそも>>865はユニットテストがなにか知らんような気がする
マニュアルに従ってテキトーにポチポチクリックして落ちなきゃテスト終わりーとか言ってそうw
887:デフォルトの名無しさん
21/01/28 23:14:26.37 jO4DLeJx0.net
>>877
今時ICサーバー必須と言われてますわ。
888:デフォルトの名無しさん
21/01/29 05:32:11.60 smfBIAno0.net
ICサーバーってなんだ？
まさかと思うけどCIサーバーのことじゃないよな？w
889:デフォルトの名無しさん
21/01/29 12:45:43.37 geJ3sMpq0.net
笑
890:デフォルトの名無しさん
21/01/29 19:43:57.28 7PT6zv600.net
>>877
俺は>>865じゃないけど、
マジ、おせーて
assertとか使う奴？
それともGUI上で出来るようなのがあんの？
891:デフォルトの名無しさん
21/01/30 10:03:36.71 mgrsH3mq0.net
>>862
ビジネスロジックコードの分離が目的なのだから、デザインコードは一緒になっている方が良いかも
892:デフォルトの名無しさん
21/01/30 12:20:17.91 g5e1Zwf90.net
Javaでオブジェクト指向が流行った時期の間違いみたいに
大規模開発専用のクソ仕様を銀の弾丸として全部に使おうとして失敗してる感じに思える
893:デフォルトの名無しさん
21/01/30 13:07:37.17 RzqUn7xl0.net
アニメをデフォルトで使う分にはxamlってそれほど複雑でもないんだけどね
formsと同じことやるなら
894:デフォルトの名無しさん
21/01/30 14:21:59.06 7JTFVOFL0.net
UI作る人と分業できるって言うけどどんだけ凝った画面にすんだろ。
結局はコード書く人が画面まわりもやってね?
最近違うの?
895:デフォルトの名無しさん
21/01/30 15:34:49.92 B8WCMkPK0.net
専業のUIデザイナー雇ってるとこなんて余程の大手だけだろうな
896:デフォルトの名無しさん
21/01/30 15:56:17.98 pMmYD7u10.net
xaml書く専業デザイナーって聞いたことないけどいるの？
897:デフォルトの名無しさん
21/01/30 17:17:04.26 7JTFVOFL0.net
UIとコード別けられるのが最大のメリットという位だしな。
居ないとおかしいがな。
898:デフォルトの名無しさん
21/01/30 17:34:35.97 8FYOnD7D0.net
誰が言った言葉かは知らんが、少なくともUIデザインを別担当者にできるのが
最大のメリットだということじゃないと思うぞ。
899:デフォルトの名無しさん
21/01/30 18:58:30.27 7JTFVOFL0.net
何がメリットなのかWPF素人にはサッパリだよ。
900:デフォルトの名無しさん
21/01/30 19:40:15.77 8FYOnD7D0.net
俺個人としてはxamlでレイアウトしやすいところとmvvmでテストしやすいところかな。
901:デフォルトの名無しさん
21/01/30 19:46:33.44 WbnyfnwJ0.net
デザイナーがHTML/CSSで作ってプログラマーが同じ見た目になるようにXAML
902:書く
903:デフォルトの名無しさん
21/01/30 19:52:36.52 KxRn6hKfM.net
デザインとプログラミングの分業においては遥かに先を行っているはずのWebでは、
最近は逆にJavaScriptにインラインでHTMLを書いているのでした
904:デフォルトの名無しさん
21/01/30 20:01:29.27 7JTFVOFL0.net
>>892
初めからデザイナにXAMLで書いてもらったら?
905:デフォルトの名無しさん
21/01/30 21:55:15.69 WbnyfnwJ0.net
>>894
XAML書いてくれるデザイナーなんているの？
906:デフォルトの名無しさん
21/01/31 00:20:30.44 c/zdJjVH0.net
作業としてUIとコードを分けられることがメリットじゃなくて
そこが疎結合になるからいいんでないの
907:デフォルトの名無しさん
21/01/31 01:07:23.46 SnnX9R4F0.net
疎結合になること自体はメリットではない
疎結合になることで何がメリットになるか書かないと
結局、分担作業やデバッグが楽という話に落ち着くと思うが
908:デフォルトの名無しさん
21/01/31 01:25:53.85 c/zdJjVH0.net
疎結合のメリットがわからない人はここにいるのかい？
909:デフォルトの名無しさん
21/01/31 01:40:01.70 SnnX9R4F0.net
疎結合になること自体はメリットではないことがわからない人がここにいるのかい？
910:デフォルトの名無しさん
21/01/31 01:46:06.04 WbkXnsTD0.net
個人とか小規模開発ならあんまメリット大きくないよな
911:デフォルトの名無しさん
21/01/31 07:07:48.07 Odha2eMQ0.net
どんだけでかいシステム作るんだろうな。
VC6.0やVB6.0でいいだろと言いたい。あれは良くできてた。
912:デフォルトの名無しさん
21/01/31 07:27:03.47 +eg72yeD0.net
>>898
疎結合のメリットを教えてください
913:デフォルトの名無しさん
21/01/31 07:51:13.66 r9k2b4HI0.net
疎結合って
キチンとインターフェース決める設計手法と
ほぼ逆の事をやってるね。
VS等の参照ジャンプが利かなくなって
かつリファクタリング機能の対象外となるし、
コンパイル自分に結合保証も担保できなくなるから、
大規模化リファクタリング後の
潜在バグの原因になっとるんだが。
914:デフォルトの名無しさん
21/01/31 07:53:58.88 r9k2b4HI0.net
>>897
疎結合だとデバックが楽というの
どんなケースを想定されてるのでしょうか？
915:デフォルトの名無しさん
21/01/31 08:06:25.92 +eg72yeD0.net
疎結合だとデバッグが楽・・・
ビューとモデルが明確に分離されてることで
「画面に表示される値がおかしい！」というときにまずはモデルをチェックすればいい
だいたいこれで誤りが見つかる
ビューはモデルを素直に反映するようになっていればビジネスロジックの影響をほとんど受けない
つまり、デバッグ（点検）対象から外せるケースが多くなる
916:デフォルトの名無しさん
21/01/31 08:36:11.85 r9k2b4HI0.net
>>905
Viewとmodelの分離は
疎結合は関係ないんじゃ...
「ビューはモデルを素直に反映するように」
これも...
917:デフォルトの名無しさん
21/01/31 09:12:12.67 I7rtGHH8M.net
ViewとModelの分離で結合が疎にならないの？
>>906の思ってる「疎結合」の定義を聞かせてほしい
「ビューはモデルを素直に反映するようになっていれば」という前提の整理について
>「ビューはモデルを素直に反映するように」
ここだけ抜き出して「これも..」と指摘してるのはいったい何が言いたいの？
なんか逆張りで根拠もなくケチつけてるだけに見えるんだけど
918:デフォルトの名無しさん
21/01/31 09:17:07.25 Odha2eMQ0.net
昔の方が作りやすかった気がする。
919:デフォルトの名無しさん
21/01/31 09:19:16.44 xVSriNge0.net
>>904
自動テストの話じゃないの
920:デフォルトの名無しさん
21/01/31 09:21:31.64 r9k2b4HI0.net
>>907
「密結合してViewとmodelを分離」
「密結合してViewとmodelを素直に反映」
しても結果は同じでは？
921:デフォルトの名無しさん
21/01/31 09:28:45.68 I7rtGHH8M.net
？？？
ごめん>>910の国語力か俺の国語力かどっちかに問題があって
あなたの主張したいことがわからない
で、あなたの思ってる「疎結合」の定義について説明をお願いしたいんだけど
922:デフォルトの名無しさん
21/01/31 09:29:51.76 r9k2b4HI0.net
>>908
昔というか、
WinFormsと同じようにWPFでも書けるよ。
実際サンプルコードはコードビハインドで
イベントハンドラーで書いてあるもの多い。
923:デフォルトの名無しさん
21/01/31 09:34:58.64 xVSriNge0.net
>>912
mvvmのサンプルじゃ無きゃ
イベントにベタ書きのサンプルだらけ
924:デフォルトの名無しさん
21/01/31 09:43:32.25 r9k2b4HI0.net
>>911
良い説明をググッてみたけど
見つからないので簡単に書くと、
コンパイル時に参照が切れた状態になる実装を
疎結合。WPF流MVVMでバインディングで繋ぐと疎結合になる。
対してC#で普通に書くと密結合。
925:デフォルトの名無しさん
21/01/31 09:48:53.55 r9k2b4HI0.net
ちなみにMVVMで
XAML(View)とmodel間の接続を、
例の難解なバインディング構文を使わずに
コードで書く(密結合)事もできる。
926:デフォルトの名無しさん
21/01/31 09:49:01.23 Odha2eMQ0.net
>>912
それで売りの高解像度にも対応してるなら
それでいいやね。
>>913
MVVMもそのうち消えるだろう。
927:デフォルトの名無しさん
21/01/31 09:50:58.51 xVSriNge0.net
>>915
バインドが難解だと?
928:デフォルトの名無しさん
21/01/31 09:53:51.31 r9k2b4HI0.net
>>917
初心者には難解じゃない？
コード補完も効きにくいし。
最初の多きな(大きすぎる)ハードルでしょ。
設定間違えると動きも変わるし。
929:デフォルトの名無しさん
21/01/31 09:59:52.50 qyMGxVkO0.net
ビューとモデルの分離って、ロジックに影響なく簡単に見た目を変えられることにあると思うのだが
930:デフォルトの名無しさん
21/01/31 10:01:10.65 r9k2b4HI0.net
>>916
>>MVVMもそのうち消えるだろう。
MVPの派生だし消えるほど酷くはないけど。
自分はReactとかでViewModelとかいう概念は
便利に使わせてもらってる。
View(React,ts)+ViewModel(ts)+Model(C#)
931:デフォルトの名無しさん
21/01/31 10:01:25.28 xVSriNge0.net
>>918
コード量は増えるけどバインド有ってのXAMLでしょう。
932:デフォルトの名無しさん
21/01/31 10:05:34.29 Odha2eMQ0.net
>>920
よくわからんがなかなかの上級者ですな。
元MASM使いなんだが今の方が覚えること多いわ。
933:デフォルトの名無しさん
21/01/31 10:10:11.38 +eg72yeD0.net
>>914
あーなるほどね
俺とは疎結合・密結合の定義が全然違うわ
あなたは静的型付け・動的型付けみたいなものとして考えてるのね
疎結合は実行時解決だから統合開発環境で流れを追うのが難しくなると
まあそれも分からなくはないがな
俺の言ってる疎結合・密結合というのはそういった技術的に明確なものではなく概念的なものなんだ
インターフェースが明確に決められていて必要十分な最小限のやり取りがされるように設計されてれば疎結合
そういった取り決めがなくあちらこちらで繋がってるのが密結合
934:デフォルトの名無しさん
21/01/31 10:12:54.41 xVSriNge0.net
>>922
NASMって何時の時代だよw
935:デフォルトの名無しさん
21/01/31 10:16:14.30 Odha2eMQ0.net
>>924
かれこれ40年はやってる。
936:初心者
21/01/31 10:17:36.86 Mg++KL660.net
treeの子要素にアクセスするのめんどくて嫌になる
もっと簡単にして
937:デフォルトの名無しさん
21/01/31 10:31:27.08 6A85emn00.net
>>918
UWPともう直ぐ出るWinUI3では、バインドでインテリセンス効くし型チェックもやってくれる
938:デフォルトの名無しさん
21/01/31 10:34:11.79 r9k2b4HI0.net
>>923
説明書いててそうかと思った！
「静的型付け・動的型付け」この型付けは開発完了時に
100%分かってないとダメだろうから型固定なんだよね。
「静的型リンク・動的型リンク」が正しい（昔はそう言ってた）と思ってるけど認識間違い？
>>923
>>インターフェースが明確に決められていて
ＡさんとＢさんが同一箇所の実装作業をしていて、
お互いが作成したクラスを呼びだす時、
その取り決めをインターフェースクラスとして作成して
これを別モジュールに切り出してお互い齟齬が出ないようにして開発する方式を
オブジェクト指向的な開発の基本と思ってるだけど、
この別モジュールのインターフェースクラスの役割を
疎結合に置き換えたプロジェクトが多いね。
テストしてても実行しないとバグわかんないし、
仕様書が必要になるから生産性下がんない？仕様書もらうより、
インターフェースクラスを寄越せと言いたくなるけど認識が低い？
939:デフォルトの名無しさん
21/01/31 10:37:40.94 r9k2b4HI0.net
>>927
WPFのバインディングはちょっと難しい構文を書くと、
合ってるのに警告出たりしてウザかったりするけど完璧なものになった？
940:デフォルトの名無しさん
21/01/31 10:42:02.91 xVSriNge0.net
>>925
コンピュータが未だ真空管だった時代ですね
941:デフォルトの名無しさん
21/01/31 10:43:31.30 6A85emn00.net
>>929
逆に厳密な方チェックになっているからintとdoubleの違いでもエラーとなるから
コンバーターかますかViewModelをイジる必要がある
あとコンバーターは型チェック無いからハマる時があるのが問題だったり
942:デフォルトの名無しさん
21/01/31 10:55:16.05 r9k2b4HI0.net
>>921
大昔からやってる（WinFXとか言ってた時代からやってる！！）と気づく人いたと思うけど、
WPFの開発者が目指したのは、開発時にBlandエディタが使える実装なんだよ。
Blandは別製品で今はVSに統合されたけど、使えてる人はいるのかな？
Blandを使わない時点で、WPF流MVVMの実装パターンはやりすぎだし過大だ。
そのくせ、コードビハインドは捨てきれてないし、
中途半端で今時流では欠点を指摘される事が多くなってる。
943:デフォルトの名無しさん
21/01/31 11:57:18.56 7s2vE3J90.net
DreamWeaver が対応しないと
デザイナーは手を出さないでしょうな
944:デフォルトの名無しさん
21/01/31 12:23:09.41 CDkVre3V0.net
>>932
Blendね
945:デフォルトの名無しさん
21/01/31 12:57:38.82 jQyDM6Cn0.net
mvvmは疎結合というか、vmからvやUIフレームワークへの依存がないというのが一番の肝だろう。
だからUI抜きの結合テストが容易にできる。
946:デフォルトの名無しさん
21/01/31 13:16:59.40 xVSriNge0.net
UI抜きの結合テストってなんじゃい
947:デフォルトの名無しさん
21/01/31 13:43:45.07 FiwuPv0S0.net
WinUIはUWPの系譜だから事前バインディング x:Bind なんでしょ
イベントも対応しててちょっとしたボタンクリック程度ならコマンドパターン適用しなくていいし楽だったわ
あとMVVMじゃなくてMVUとかいうを使えとか
948:デフォルトの名無しさん
21/01/31 17:56:29.56 Odha2eMQ0.net
URLﾘﾝｸ(forest.watch.impress.co.jp)
ほう。
949:デフォルトの名無しさん
21/01/31 19:32:45.91 6A85emn00.net
WinUI3は４ヶ月毎のマイルストーンって言っていたから
予定だと来月に出るが、何もアナウンス無いから延びるんだろうな
950:デフォルトの名無しさん
21/01/31 23:15:46.66 Kkreym0u0.net
個人的にはwinform よりmvvmwpfの方が設計を考えるのが楽だとは思う
コード量がアホみたいに増えてるとは思うけど
951:デフォルトの名無しさん
21/01/31 23:24:50.28 WbkXnsTD0.net
WPFでUI書いて処理はイベントにベタ書きが一番楽だわ
WinFormsよりUI要素のレイアウトしやすいし
952:デフォルトの名無しさん
21/02/01 01:16:36.92 rq/3X0hM0.net
gridはレイアウト決めるときにすごく便利ですね
これだけでもメリットは大きい
953:デフォルトの名無しさん
21/02/01 06:13:34.77 nwGyyZLi0.net
>>939
先々週に次の予定発表されたやん..
3月にサポートされるバージョンの0.5
で5月のbuildイベントで0.8
で、急遽、2月中にpreview 4
954:デフォルトの名無しさん
21/02/01 08:30:05.02 FUNk1KeQd.net
>>932
それ一回も使ったことないわ
955:デフォルトの名無しさん
21/02/01 10:26:51.12 7mzzL5vxd.net
>>942
それくらいならWinFormsのTableLayoutPanelと変わらなくない？
956:デフォルトの名無しさん
21/02/01 14:20:35.38 Jz+8bDTmr.net
>>944
Blendつかえばmvvmの意味するものがわかるよ。
使うの多少ハードルあるけど、
なんでWPF流mvvmがこーなってるのか解る。
957:デフォルトの名無しさん
21/02/01 22:36:11.32 P+/hMLSZ0.net
>>943
URLﾘﾝｸ(youtu.be)
ソレのソースらしきもの見つけたが
ここではreunion0.5にincludes WinUI 3.って書いてあるのにな
それがpreview4ですか・・・
958:デフォルトの名無しさん
21/02/02 00:05:04.75 zsk2qsaN0.net
>>947
preview 4はその最新のロードマップが発表された後に、プレビューリリースの間隔が長すぎという批判が出て急遽リリースされることになった
URLﾘﾝｸ(twitter.com)
2月 preview 4
3月 reuinoin 0.5
5月 reuinion 0.8
じゃないかな?
(deleted an unsolicited ad)
959:デフォルトの名無しさん
21/02/02 00:22:15.18 RoIAA49z0.net
WPFの本のKindle版を買ってまだあんまり読んでないのに
もう別のUI出るのかよ・・・
ちきしょー、紙版買っときゃよかったぜ
それなら中古で売れるのによ・・・
WPFにはクソな思い出しかない
960:デフォルトの名無しさん
21/02/02 00:36:40.96 iARfrUqjM.net
WinUI以前にとっくの昔からWPFはレガシーなのに何を今更
961:デフォルトの名無しさん
21/02/02 03:37:50.94 rKbxrD500.net
WinFormsとかWPFのいい所は、配布先のPCでだいたいランタイムの新規インストール不要で動くとこなんだけど、
WinUIだと当面ランタイムも同梱しないといかんよね？
962:デフォルトの名無しさん
21/02/02 05:02:04.51 +YBVnJ9D0.net
こんな中途半端なものでレガシーとかWPF終わってるな
963:デフォルトの名無しさん
21/02/02 05:54:26.45 NxFZfFhx0.net
デスクトップのUIは迷走状態ですなあ
964:デフォルトの名無しさん
21/02/02 09:10:36.54 CKxQr0yQa.net
今ならElectronが覇権取りそう？
965:デフォルトの名無しさん
21/02/02 09:23:44.16 eretDOma0.net
flutterかも
966:デフォルトの名無しさん
21/02/02 20:42:27.60 9gegCBvb0.net
windowのvisibilityにデータバインドして
イベントハンドラでhiddenになったらthis.close()してやろうとしているのですが
クソコードですか？
967:デフォルトの名無しさん
21/02/02 23:17:21.74 ys8JMHCh0.net
WPFも短命だなこりゃ。。
968:デフォルトの名無しさん
21/02/03 00:00:53.68 U79XHMjd0.net
充分生きたろ。大往生だよ。
969:デフォルトの名無しさん
21/02/03 00:43:16.96 5b6XJ+8sM.net
WPFのリリースは2006年、もう15才だ
一般的なソフトウェアのサイクルとしては決して短くはない
結局日の目を見ることはなかったが、ここまでよく頑張ったよ
もう楽にさせてやろう
970:デフォルトの名無しさん
21/02/03 00:55:28.54 tBRxw4yW0.net
WPFに関連する検索キーワード
wpf 普及しない
wpf 将来性
wpf 流行らない
WPF C#
wpf 将来性 2020
wpf サポート終了
971:デフォルトの名無しさん
21/02/03 01:45:34.69 FZBBkmjF0.net
十分日の目は見たやろ
972:デフォルトの名無しさん
21/02/03 02:46:56.03 suCK4Q8d0.net
他のキーワード
wpf 普及しない
wpf 将来性
WPF C#
wpf 将来性 2020
wpf 流行らない
WPF(Windows Form)
wpf サポート終了
WPF 入門
他の人はこちらも検索
What is WPF used for?
Is WPF Dead 2019?
What is a WPF project?
What is replacing WPF?
Why is WPF dead?
Why is WPF so slow?
973:デフォルトの名無しさん
21/02/03 07:52:02.77 9W7Ice0KM.net
デスクトップで悩むならWebに逃げるわな
デスクトップでしかできない要件があるなら別だが
974:デフォルトの名無しさん
21/02/03 08:19:18.66 /SpfYE47M.net
Web SerialとかWeb Usbあるから殆どのことは出来るのかな
975:デフォルトの名無しさん
21/02/03 19:52:08.00 jQBwY413M.net
3年前のwebアプリって今動くの？
976:デフォルトの名無しさん
21/02/03 20:11:06.40 kMe6ilrT0.net
動かないことはないと思うがjQueryとか古い技術使ってそうね
今のreactやvue.jsなんかも数年立ったら古いって言われてると思う
Webは技術がコロコロ変わりすぎてやる気になれない
977:デフォルトの名無しさん
21/02/03 20:54:16.51 NmjXw9sF0.net
組み込みはずっと相変わらずc/c++だからそれはそれでモチベ維持難しいぞ
978:デフォルトの名無しさん
21/02/03 23:29:27.89 J0iktNk60.net
なんだ。勉強しようと思ったら終わりかよ。
業務アプリって明快でサクサク動くのが第一条件だからなぁ。
979:デフォルトの名無しさん
21/02/03 23:42:55.06 ioJArBze0.net
軽さを求めるならWinForms一択
980:デフォルトの名無しさん
21/02/03 23:57:50.08 J0iktNk60.net
そう。
ボタンに影つけるとかアニメーション、回転なんて実際、どうでもいいんだよね。
981:デフォルトの名無しさん
21/02/04 00:42:38.32 hcs7ROzx0.net
軽さならUWPだな
ライブラリの使わない部分切り捨てるしAOTだしライブラリ自体がCOMオブジェクトだし
982:デフォルトの名無しさん
21/02/04 02:31:54.22 e59RYOYD0.net
リユニオンでUWPもレガシー化するから、生き残るのはWinUIと、昔から裾野が広いWinForms
983:デフォルトの名無しさん
21/02/04 07:46:05.95 36EJyZsE0.net
>>971
C++時代にCOMとかActiveXとかに手を出して、COMアレルギーになったわ
984:デフォルトの名無しさん
21/02/04 08:24:26.72 ZtMmgGts0.net
生き残るかどうかといったら大体生き残るだろ。
はっきり死亡宣告されたのはC++/CLIとかGDI+くらい。事実上死亡はC++/CXとか。
985:デフォルトの名無しさん
21/02/04 08:27:11.93 nQ02ZkdOM.net
vb6がまだ死んでないんだぜ
986:デフォルトの名無しさん
21/02/04 09:29:31.02 lfkJlpDH0.net
開発環境維持するのが手間になるんだよな
987:デフォルトの名無しさん
21/02/04 10:31:10.36 3GUGjOuU0.net
>>970
同感
社外に出すなら知らんけど、うちは社内の業務アプリ開発やってるから見栄えよりもパフォーマンス重視なんだよね
みんなWinFormsでやってて、社内でWPFやってるの俺しかいねぇ
リアルタイムでグラフが動いたりすると「おおーっ」と言われるが、作った俺本人は別に要らんかったなと思ってる
988:デフォルトの名無しさん
21/02/04 10:32:41.38 89VtoA6h0.net
もしかして俺また何かやっちゃいました？
989:デフォルトの名無しさん
21/02/04 11:03:30.76 ZzRKCYY/0.net
>>973
もったいないな
COMは良いぞ
990:デフォルトの名無しさん
21/02/04 12:00:02.99 aKVEM25d0.net
COMもうサポートされないやん
このままだとExcelもいずれ死んじゃう
991:デフォルトの名無しさん
21/02/04 12:01:05.22 3bXGR69vM.net
windowsはcomだらけでしょう
992:デフォルトの名無しさん
21/02/04 13:29:37.28 llP+HC4ja.net
COMはレジストリ使うから面倒くさい
993:デフォルトの名無しさん
21/02/04 17:45:56.09 3GUGjOuU0.net
ホント、COMぁったもんだ
994:デフォルトの名無しさん
21/02/04 20:23:26.38 ZtMmgGts0.net
>>977
暗にWPF使うアプリケーションは見栄え重視と言いたいようだけどそんなん少数派だよなぁ。
というか本当にそれ目的でWPFやってんの？
995:デフォルトの名無しさん
21/02/04 21:39:09.24 ih5/H8FP0.net
高DPI時代にWinFormsは無理
996:デフォルトの名無しさん
21/02/04 23:43:38.22 OAJDFKMl5
バカ不平多し★へつらい生きてるからリストラ対象
URLﾘﾝｸ(www.youtube.com)
勝ちは偶然、負けは必然★負けて消えた人に足りなかったものは？
URLﾘﾝｸ(www.youtube.com)
リーダー達の給料が高いのは単純労働者じゃないから
URLﾘﾝｸ(www.youtube.com)
できません、自信がありません、無理です★ボンクラにしたのは誰？
URLﾘﾝｸ(www.youtube.com)
9割の人は、ただの作業員★自学自習こそ仕事の基本
URLﾘﾝｸ(www.youtube.com)
サラリーマン、10年経てばボンクラ説
URLﾘﾝｸ(www.youtube.com)
997:デフォルトの名無しさん
21/02/04 23:48:33.11 rPrK7o6X0.net
>>970
ま、両方できるならそれに越したことは
ないがな。
998:デフォルトの名無しさん
21/02/05 05:42:40.73 OpH7IlXC0.net
MSはReactivePropertyとかPrismみたいなの取り込む気はあるのかな
MSでWPFの冗長さが問題になってなさそうなのが不思議
999:デフォルトの名無しさん
21/02/05 07:17:55.50 8dD588qGM.net
MSはWPFほとんど使ってないんじゃ…
1000:デフォルトの名無しさん
21/02/05 08:17:47.81 93xMJ7WGM.net
>>989
visual studio
1001:デフォルトの名無しさん
21/02/05 08:24:41.67 8dD588qGM.net
それだけだ！
1002:デフォルトの名無しさん
21/02/05 08:26:54.02 93xMJ7WGM.net
そうかも
1003:デフォルトの名無しさん
21/02/05 08:44:17.48 8dD588qGM.net
MSの縦割り組織の悪い面だとおもう
オフィスはReactNative
VSCodeはなんだっけな、これもjs系言語で作ってたとおもう
Windowsの衰退はWPFの衰退
1004:デフォルトの名無しさん
21/02/05 09:27:46.93 I+zADhcc0.net
>>993
いや、単一の技術に全集中する方がヤバい
まあ余力がある企業だからできる技だけど多方面に分散するのは生き残る知恵だよ
1005:デフォルトの名無しさん
21/02/05 09:45:22.14 8dD588qGM.net
>>994
そういうことではなくて
自分の会社が作った技術を他の事業部がほとんど使わないんだよ
色々技術つけるのはいいよ？でもその技術作った会社がほぼ使ってないってどーいうことなの？
ってなる
なんかその辺の企業にありがちなオレオレフレームワークと一緒じゃん
1006:デフォルトの名無しさん
21/02/05 09:55:20.95 93xMJ7WGM.net
visual studioなんか自社が人柱となってベータ版を積極的に使って改善していたと言うのは過去の話か
1007:デフォルトの名無しさん
21/02/05 10:19:13.81 qkdTZe/m0.net
ドッグフード食うって話より、例えばOfficeでもWPF使えよって話なのでは
1008:デフォルトの名無しさん
21/02/05 10:20:52.50 I+zADhcc0.net
>>995
自分の事業部で使ってるんでしょ？
事業部制ってそう言うもんだよ
別会社みたいなもんだし、下手すると現場では競合したりもする
日本でも昔はそういう企業も多かったけど無駄だからやめようとトップダウンにして現場の士気は下がって業績もついでに下がってるw
1009:デフォルトの名無しさん
21/02/05 10:50:00.78 Jm9ro3zS0.net
WPFというとかぎられてしまうけど、
XAMLという括りで見ると
社内開発ツールとしてのシェアないの？
windows8以降のOS周りは
全部XAMLじゃないの？
1010:デフォルトの名無しさん
21/02/05 12:22:25.06 8dD588qGM.net
>>998
事業部制はほんとつらい
乱立するオレオレフレームワークに振り回されている…
MSと他企業の違う点は、MSは作った開発フレームワークを公開してるとこだな
>>999
それは確かに。
1011:デフォルトの名無しさん
21/02/05 12:49:32.44 QFQT7eD40.net
MSはVisual Studioの方向性も考えたほうがいいな
以前はVSとWeb開発の親和性を高めるためにASP.NETを生み出したりしてた
こんなやり方は今後は通用しない
今後はMSが歩み寄ってVS使えばReactやvue.jsの開発が楽になります！みたいな方向になっていって欲しい
さすがに巨人MSでもWeb技術を自社で囲い込むのは無理だ
1012:デフォルトの名無しさん
21/02/05 12:55:09.45 AV0Gp17OM.net
>>1000
MSは作る立場の会社なので使うだけの会社とはちょっと違う
使うだけの会社なら標準化すべきだよ
1013:デフォルトの名無しさん
21/02/05 18:00:33.45 Kj/KBKr1r.net
>>1001
VScodeが担う役割じゃないの？
それらじゃ充分デファクトになっとるし。
1014:デフォルトの名無しさん
21/02/05 18:40:59.80 QFQT7eD40.net
MSはVSCodeに注力しすぎだろ
このままじゃ有料のVisual Studioが死んでしまう
MSは製品販売で収益上げるのをやめるのかな
無料のVSCodeでいいソフト作ってくださいねー Azuleで動かしてくださいねー という戦略だろうか
1015:デフォルトの名無しさん
21/02/05 18:56:04.02 Kj/KBKr1r.net
VSは随分前から
フェードアウトしてるようにみえてるけど。
1016:デフォルトの名無しさん
21/02/05 18:58:04.45 xu/l+szrM.net
VSCodeは開発者のWindows離れ問題への対策の一環でしょ
Web開発でWindowsは使い物にならなかったのが、VSCodeやWSLによってここ数年で急速に改善された
Windowsへの繋ぎ留めが目的とはいえWeb技術に疎いドザ達だけに任せてたらエコシステムとして成長しないから、VSCodeはマルチプラットフォームにする必要があった
1017:デフォルトの名無しさん
21/02/05 19:35:53.38 7lMcNRUl0.net
有料のVS無くなってもいいから日本語ドキュメント整備に力入れて欲しいわ
1018:デフォルトの名無しさん
21/02/05 19:48:47.85 jklBcEmFM.net
確かに
あのdocsの日本語?読んでいると
頭が痛くなるな
1019:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 424日 7時間 12分 34秒
1020:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています