【本命】Blazor スレ2【真打】 (734ﾚｽ)
上下前次1-新
70(1): 2020/11/25(水)16:08 ID:s/U6WABr(1) AAS
>>68
XreaのCoreserverやSakura Internetみたいなレンタルサーバーでは使えないということですねありがとうございました
71(1): 2020/11/25(水)16:19 ID:cpMhX0+Z(2/2) AAS
>>70
PHP専用のプランで使えるかってこと？
そりゃ無理だわ
同じ会社のやってるVPSのプランにしてください
72: 2020/11/25(水)16:48 ID:4YMIWKt+(1) AAS
千円もしないvpsがゴロゴロしてるのに未だにレンタルサーバに需要があるのがわからん
コンパネ？みたいなUiに需要があるのかね
スレチだが
73: 2020/11/25(水)17:04 ID:jzvQX9aE(2/3) AAS
>>68
nginxとapacheだけで、asp.netが使えるようになるのですか？
74(1): 2020/11/25(水)17:06 ID:jzvQX9aE(3/3) AAS
>>71
vpsじゃなくても、phpだけじゃなく、rubyやC/C++のcgiが使える
一ヶ月数百円から500円くらいまでの安いレンタルサーバーは沢山有ります。
75(1): 2020/11/25(水)17:06 ID:imttWao4(3/4) AAS
こっちはASP.NETの話題禁止のクソスレだから
下のスレへどうぞ
Microsoft ASP.NET Blazor #02
2chｽﾚ:tech
76: 2020/11/25(水)17:38 ID:89i//6R1(1) AAS
>>75
じゃあBlazorの話も禁止ね
77: 2020/11/25(水)17:57 ID:PB3oYzKc(1) AAS
>>74
さくらインターネットに585円のVPSプランあるやんw
78(1): 2020/11/25(水)18:58 ID:aGDrX6e7(1) AAS
>>64
どこに書いてある？ASP禁止って
まあこっちのスレの方が伸びてるしここが本スレでいいよねもう
79(2): 2020/11/25(水)19:35 ID:yKXMVzmF(1/2) AAS
>>67
レンタルサーバーで .NET core 使える環境はまだないね
っていうか使えるのが出てこない可能性の方が高いかなぁ
アプリ登録するのにシステムんにサービスとして登録しないといけないし。
VPSで自分で自由に使えるのは大丈夫
80: 2020/11/25(水)19:38 ID:yKXMVzmF(2/2) AAS
まぁ active Server pages や
Application Service Provider の話は禁止でいいな
81(1): 2020/11/25(水)20:08 ID:imttWao4(4/4) AAS
>>78
よくない、お前本人だろ
ここでまたこのスレ使ってしまうと1のカスが
クソスレタイとテンプレねじこんでスレ立てしにくる
82: 2020/11/25(水)22:11 ID:rBSs4eKN(1) AAS
>>81
本スレを荒らさないでください
83: 2020/11/26(木)01:08 ID:eoABo+tN(1) AAS
>>79
VPSを借りて、Linux上にasp.net core(?)をインストールすれば、BlazorServer
が普通に使える様になるのでしょうか？
84(1): 2020/11/26(木)01:08 ID:lH6B10sG(1/2) AAS
>>79
VPSを借りて、Linux上にasp.net core(?)をインストールすれば、BlazorServer
が普通に使える様になるのでしょうか？
85(1): 2020/11/26(木)08:04 ID:k5hYinBT(1) AAS
>>84
きちんとデプロイしなきゃならない
Linuxを全くわかっていないなら
Wkndows Server の VPS を探すことになる。
安くはないし通信量による課金も発生するけど
Azure WebApp 使えば楽
Apache 搭載の Linux で ASP.NET Core をホストする
省3
86(2): 2020/11/26(木)12:33 ID:lH6B10sG(2/2) AAS
>>85
Sakura Internetなどの日本のVPSのLinuxにASP.NET Coreをホスト(?)した場合、
MSクラウド(Azure(?))と同じ事が出来るようになるのでしょうか？
ならない場合、後者の優位な点を教えていただければ幸いです。
87: 2020/11/26(木)13:00 ID:seB575Yt(1) AAS
>>86
Azure SignalR Service
Blazor Server アプリには Azure SignalR Service を使用することをお勧めします。
このサービスでは、多数の同時 SignalR 接続に対して Blazor Server アプリを
スケールアップできます。 さらに、SignalR サービスのグローバル リーチと
ハイパフォーマンスのデータ センターは、地理的条件による待機時間の短縮に
役立ちます。
省3
88: 2020/11/26(木)13:06 ID:HhoxF6mi(1) AAS
>>86
同じことできるよ
ただOSのセキュリティも含めて自分で管理できなければいけない
Azureだとその辺は気にしなくていい
自分が作るアプリのセキュリティだけ気にすればいい
89(1): 2020/12/01(火)03:28 ID:AyJ2ZU61(1) AAS
Blazor Advent Calendar 2020 1日目
Blazor WebAssemblyをただC#実行プラットフォームとして使って既存のReactのWebアプリを拡張した話
外部ﾘﾝｸ:qiita.com
90: 2020/12/01(火)09:01 ID:egbABUn/(1) AAS
いいね
91: [なかsage] 2020/12/01(火)10:57 ID:FTpqyNN7(1) AAS
>>89
俺も取り組んでるやつだwww
92: 2020/12/01(火)12:18 ID:NavvHgIk(1) AAS
Svelteみたいな方向に進化せんかな
93: 2020/12/02(水)22:53 ID:hJiXLNQ4(1) AAS
そういや.NET Insider にMacのVSでBlazorデバッグできるようになったよ！て書いてあったけど
WindowsのVSではまともにデバッグできるようになったんかな？
94(1): 2020/12/11(金)22:31 ID:V7fk+d5E(1) AAS
Developer Decries WinForms-to-Blazor Performance Degradation
開発者がWinFormsからBlazorへのパフォーマンスの低下を非難
外部ﾘﾝｸ[aspx]:visualstudiomagazine.com
> I have a c# WinForms app that I have been converting to Blazor Wasm.
なかなか猛者がいるようだな
自作のコンバータでもあるんかね
95(1): 2020/12/12(土)02:18 ID:4q8SABHv(1/3) AAS
>>94
「Blazorではパフォーマンスが約20分の1に低下しています（たとえば、WinFormsでは350ミリ秒、Blazorでは7000ミリ秒）」
#これを改善するために AOT 方式にした場合、今ですら巨大なダウンロードサイズがさらに増えるとBlazorの専門化
により言及されている：
「将来、・・・、アプリ、またはアプリの一部である可能性が高いものもWebAssemblyにコンパイルされます。これはAOTまたはAhead Of Timeコンパイルと呼ばれます。このモードの利点はパフォーマンスですが、トレードオフはダウンロードサイズが大きくなることです。」
96: 2020/12/12(土)02:56 ID:E+dxDDH/(1/3) AAS
AA省
97: 2020/12/12(土)03:03 ID:X07PkpTY(1) AAS
「Monoランタイムによる中間言語逐次変換実行方式（ILインタプリタ方式）の今は遅いが、いずれAoTに対応して爆速になる！そしたら勝つる！！」って言ってたのにこんなオチかよ…
98: [なかsage] 2020/12/12(土)06:07 ID:nI2cvcZT(1) AAS
Dom操作の全てにJSが逐一介在してるの
どうにかせんとダメだよ。
これは、それとは別の大問題。
99(1): 2020/12/12(土)06:22 ID:E+dxDDH/(2/3) AAS
それはWebAssemblyの仕様で、
C#固有の問題じゃないけどな。
Rustだろうが何だろうがそうだよ。
JS噛まさずにWebAssemblyからダイレクトにDOM触る方法は今のところ無いし計画もない。まあ要望はある。
100: 2020/12/12(土)08:30 ID:cpIIyxGV(1) AAS
Wasmに過度な期待を持ってはいけないのは
触れば気づくだろう？
最後はnativeにいきつくわけよ
だから今やるべきはXamarin.Formsですわ
その後MAUIが主力になってくる
101: 2020/12/12(土)09:16 ID:DkKIdPi2(1/3) AAS
WinFormsとBlazorなんて全く異なる物の速度を比較してる時点で滅茶苦茶胡散臭い記事だな
アンチBlazorが必死になって抵抗してるんだろうな
102: 2020/12/12(土)09:20 ID:72312GxT(1/2) AAS
BlazorServerにしたらいいじゃん
103(4): 2020/12/12(土)09:27 ID:DyBScL4l(1/2) AAS
実際、サーバと通信途切れてもいいアプリって
お絵描き系とメモ帳系くらい？
業務系なんかデータの整合性気にしないといけないし、
ゲームで通信切れるのもってのほかだし、
WASMのメリットがいまいち分からない
104: 2020/12/12(土)09:34 ID:72312GxT(2/2) AAS
>>103
簡単なゲームとかもそうだろうね
業務系はServerの方がいいんではないかと思う。
なんだか反則みたいな仕組みなきもするけど。
105(1): 2020/12/12(土)09:35 ID:DkKIdPi2(2/3) AAS
>>103
wasmというかSPAはサーバー計算資源を削減できるからクラウド料金が安い
あと配布ルートが多彩、CDN、S3、Dropbox、GitHub、、、
wasmの利点は開発言語の多様化、将来的にはパフォーマンスもJSより良くなる
106(1): 2020/12/12(土)09:38 ID:rjq8VE9O(1) AAS
>>103
逆だ
サーバーと通信が途切れたらダメなんてウェブアプリは出来損ない
ウェブアプリはステートレスだから途切れても何にも問題ないそれがデフォルト
107(1): 2020/12/12(土)10:06 ID:DyBScL4l(2/2) AAS
>>106
通信途切れたらというか、
何かボタン押したときに404が返ってきて困るアプリって何？
上に挙げたようにメモ帳系なんかは確かに書いてた内容がおじゃんになるのはよろしくない。
・・・が、それ以外のアプリってサーバにデータ送信できなきゃ
意味ないのが多いんじゃないの？ってのを聞きたかった。
108(1): 2020/12/12(土)10:57 ID:DkKIdPi2(3/3) AAS
>>107
何が言いたいのか不明瞭
もしかしてSPAはサーバーと全く通信しないとでも思ってる？
109: 2020/12/12(土)11:10 ID:UY03Th0g(1) AAS
みんなザマ爺NGしててエラい
110: [なかsage] 2020/12/12(土)15:12 ID:gFRHn2zG(1/2) AAS
>>99
Domにアクセスするから問題になるのでは？
Wasmだとcanvasに点で描画するのが本流かと。
canvas内でネイティブアプリが動くに等しい。
VRとかゲーム系はみんなそーでしょ。
111(1): 2020/12/12(土)15:23 ID:gFRHn2zG(2/2) AAS
>>108
SPAはViewがクライアント側で完結してるのに対して、
BlazorServerはViewがクライアントとサーバーにまたがって完結してるのが問題なんですよ。
なのでBlazorServerで接続が切れると
整合性の担保が怪しいので
致命的エラー扱いで強制終了せざるを得ないね。
112(1): 2020/12/12(土)15:58 ID:njlY7O2j(1) AAS
>>105
ほーん
その利点は気付いてなかったわ
やっぱクライアントレンダリングの方が将来性ありそうね
113(1): 2020/12/12(土)16:34 ID:4q8SABHv(2/3) AAS
>>112
安いというのは魅力だろうな。
ただ、MSとしてはAzureのクラウドを使わせなきゃ駄目だから、BlazorWasmはそれと矛盾するが。
114(1): 2020/12/12(土)16:54 ID:4q8SABHv(3/3) AAS
>>113
MSとしてはダウンロード量やクラウドとのアクセス量、クラウドに助けてもらう処理
が多ければ多いほど自社のクラウド事業にとって有利になるわけだから、
BlazorWasmは、如何にバイナリサイズを大きくし、クラウドとの連携を複雑化
してなるべくクライアントの処理だけで済まさずにサーバーの助けを混ぜないと
動作しないようにするかで経営手腕を問われる。
つまり、基礎はわざと複雑で使いにくしておきながら、その複雑さをフレームワーク
省1
115: 2020/12/12(土)17:57 ID:E+dxDDH/(3/3) AAS
そうか、そう考えると >>95 は理にかなってるね。さすがMS
116(1): 2020/12/13(日)11:02 ID:UCfR+Gyz(1) AAS
>>111
接続が切れても自動で再接族試みてくれるんだけど
それにずっと状態をクライアント側で持ってるわけじゃないから
再接続に失敗しても
1時間の作業が全部きえたー、とかにはならないし
そうなるとしてもこれまでのwebアプリと一緒でしょ
117(1): 2020/12/13(日)11:20 ID:MilXzpek(1) AAS
>>114
Wasm（というかSPA）はサーバーリソースの使用率を減らせるからクラウド使用料金はむしろ減るぞ
118: 2020/12/13(日)11:33 ID:k9p7uAHs(1/19) AAS
維持費はオンプレミスのが安い
しかも速い
119(1): 2020/12/13(日)11:39 ID:yG0Ic1Ux(1/10) AAS
オンプレは高い
電気代、人件費、場所代
120(1): 2020/12/13(日)11:40 ID:+g+t61bw(1/3) AAS
>>117
だとすると、MSのクラウド事業が縮小するね。
121(1): 2020/12/13(日)11:53 ID:k9p7uAHs(2/19) AAS
>>119
大嘘だな
海外より日本は電気代高いが割合は微々たるものだ
クラウド事業者が儲かってるのは利益率高い証拠
122: 2020/12/13(日)12:04 ID:yG0Ic1Ux(2/10) AAS
>>120
縮小しないよ
安くて便利
→みんな使う
→儲かる
1顧客からの収益が減っても客数が増えれば全体収益は上がる
これ商売の基本というか子供でもわかる理屈だろ？
123(1): 2020/12/13(日)12:07 ID:yG0Ic1Ux(3/10) AAS
>>121
クラウドがなぜ儲かるかって
大量のリソースを纏めて管理してるから台数で割ったときに安くなるからだよ
これも商売の基本
取り扱う数を増やすほど1個辺りの単価は安くなる
物を売り買いする場合もそう
人や物を管理する場合のコストもそう
124(1): 2020/12/13(日)12:09 ID:k9p7uAHs(3/19) AAS
海外では大手企業はクラウド離れの動きでてる
オンプレミスのが速くてコスパいいことに気付いた企業が多い
125(1): 2020/12/13(日)12:12 ID:k9p7uAHs(4/19) AAS
>>123
実態をわかってない
オンプレミスでは運用管理の専任の人なんて必要ない
他のサーバー管理のついでにやる程度
>>124嫁
利用料金が高すぎてクラウド脱出企業が増えてるの知らないのは情弱
126(1): 2020/12/13(日)12:13 ID:CXVbPnPb(1/4) AAS
もしかしてハイブリッドクラウドのことを言ってるなら、
あれは従来クラウド化など考えられなかったお硬いシステムにもクラウドの柔軟性を導入しましょうって話で、オンプレミスへの回帰とはむしろ真逆
127: 2020/12/13(日)12:17 ID:k9p7uAHs(5/19) AAS
脱クラウドはいわゆるパブリッククラウドからの脱却
賢い企業はオンプレミスに移行してる
利用料金が高すぎるため
128(1): 2020/12/13(日)12:18 ID:CXVbPnPb(2/4) AAS
だとしたらよほど人間の単価が安い企業なんだろうな
129(3): 2020/12/13(日)12:20 ID:yG0Ic1Ux(4/10) AAS
>>125
専任が居ないとはいえメンテナンス、トラブル対応には賃金が発生する
初期投資、修理費、電気代（鯖、空調）、人件費
後は障害による停止期間中の作業停止も地味だが大きな人件費の浪費になる
トータルで見ればクラウドのほうが安いよ
まあ専任が居ない程度の小規模ならクラウドよりVPSのほうがより良いかもね
130: 2020/12/13(日)12:26 ID:yG0Ic1Ux(5/10) AAS
>>126
大規模に機器を調達して自社クラウドを構築する企業は増えてきてるそうだね
金融系とかデータを外に出せない分野ではそういう選択肢もあるのだろう
ただクラウド専門事業者と比べて小規模にならざるをえない
そうなるとさっき言った纏めて管理する台数が減るので1台あたりのコストは依然として大きなままだ
コスト的には厳しいだろうね
131: 2020/12/13(日)12:28 ID:k9p7uAHs(6/19) AAS
>>128
だからさ、無能な企業とちがって
運用管理のエンジニアなんて雇わないんだよ
昔はサーバーのオペレーターとかいた時代あるようだけど
今はそんな時代じゃない
壊れたら原因調査して予備のパーツに交換してすぐ復旧させる。
自社内でスキルあるエンジニアいればできることだ
132: 2020/12/13(日)12:29 ID:CXVbPnPb(3/4) AAS
俺が担当してるシステムはオンプレとクラウドのハイブリッドで、
俺の業務時間の大部分はオンプレのお守りを投げているベンダーとの間の無駄なコミュニケーションに費やされている
もうすぐクラウドへの置き換えが完了するけど、そうなればベンダーは切って(俺の給料を抜きにしても)年間数千万は浮く見込みだ
133(1): 2020/12/13(日)12:30 ID:+g+t61bw(2/3) AAS
>>129
畑違いだから分からんけど、大規模なところなんてほとんど無くて、
小規模なところの方が圧倒的に多いはずだよね
134(2): 2020/12/13(日)12:31 ID:k9p7uAHs(7/19) AAS
>>129
電気、空調の工事、なんてクラウドやDCでも外部の業者呼ぶだけに決まってるだろｗ
修理費とかかけてる方がバカ
賢い企業は予備パーツストックしておいてすぐ交換しすぐ復旧させる
135(1): 2020/12/13(日)12:34 ID:k9p7uAHs(8/19) AAS
>>129
＞障害による停止期間中の作業停止
これもすでにかいた。
スキルあるエンジニアが障害箇所を特定してハード故障なら
すぐパーツ交換
データのリカバリーまでしてサービス再開させる。
あとデータ転送量の多いサイトはどうやってもクラウドのが超高額になる。
省3
136(1): 2020/12/13(日)12:35 ID:CXVbPnPb(4/4) AAS
>>134
正月休みの帰省中の夜中にぶっ壊れたらどうすんの？
そりゃ俺が24時間張り付いたらそこそこの規模のオンプレのシステムは運用できるかもしれんが、少なくとも俺は絶対にやりたくないねw
137(2): 2020/12/13(日)12:40 ID:k9p7uAHs(9/19) AAS
>>136
そんなミッションクリティカルならDC使うだろうし
DCの近所に自社のエンジニアが住んでるのが普通だぞ
なにかあったら夜中でもすぐかけつけられる体制になってる
大昔の無能オペレーターじゃあるまいし、
２４時間はりつきなんてばかなことしないｗ
監視するプログラムが走ってて異常を検知してメールとかがくる
138: 2020/12/13(日)12:42 ID:yG0Ic1Ux(6/10) AAS
>>133
小規模でもクラウドやVPSのほうが安い
大規模だともっと安い
オンプレはセキュリティ規約の都合でクラウドを借りれない場合などに使うものだ
139(1): 2020/12/13(日)12:44 ID:yG0Ic1Ux(7/10) AAS
>>134
業者呼ぶのも金かかる
パーツ交換も人件費がかかる
パーツ交換まで作業者手が止まる可能性あり
やっぱりオンプレは金がかかるな
140: 2020/12/13(日)12:46 ID:yG0Ic1Ux(8/10) AAS
>>135
その作業中止まってるじゃん
従業員数時間に比例して損失が増えていく
オンプレは高くつくね
141(1): 2020/12/13(日)12:47 ID:113EdQf0(1) AAS
>>137
答え出てるじゃん
その運用体制を整備して実行していくのにいくらかかると思う？
142: 2020/12/13(日)12:48 ID:yG0Ic1Ux(9/10) AAS
>>137
で、深夜に叩き起こされたエンジニアが嫌気が差して転職するわけだ
今まで人材育成にかけたコストが全部吹っ飛ぶね
143(1): 2020/12/13(日)12:50 ID:yG0Ic1Ux(10/10) AAS
そっかオンプレだと会社やDCの近くに担当者の家を借りないといけないのか
うわー金掛かりそうだなー
144(1): 2020/12/13(日)13:04 ID:k9p7uAHs(10/19) AAS
必死にオンプレミス否定してるやついて笑えるｗ
クラウドやDC勤務のやつらかな
145(1): 2020/12/13(日)13:06 ID:k9p7uAHs(11/19) AAS
>>139
まだ理解できないんだなこいつは。
パーツ交換くらい業者呼ばずにやるんだよ
そんなのよんでたら時間と金がかかる
スキルある企業は予備パーツさくっと交換して復旧終わり。
ダウンタイムが最小限になるのもオンプレミス
146: 2020/12/13(日)13:08 ID:rq9kuXid(1) AAS
毎回クラウドかザマリンのはなしになる
147: 2020/12/13(日)13:09 ID:k9p7uAHs(12/19) AAS
>>141
夜間対応が必要なほどミッションクリティカルなサービスは
金融のごく一部のみだしほとんどの企業は関係ない。
金融でもそもそもパブリッククラウドにしたところで解決しない。
むしろハードがブラックボックス化してトラブル解決が困難になる
148(1): 2020/12/13(日)13:13 ID:k9p7uAHs(13/19) AAS
>>143
なんもしらないんだなこのアホは
DC多いは千葉の印西市とか郊外だぞｗ
149: 2020/12/13(日)13:24 ID:8JARRe3z(1) AAS
>>116
複数画面を経由しての
トランザクションぽい処理とかはきついなーー。
150: 2020/12/13(日)13:28 ID:+g+t61bw(3/3) AAS
DC = Data Center
上下前次1-新書関写板覧索設栞歴
あと 584 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.018s