Microsoft ASP.NET Blazor #02

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2020/11/22(日) 05:30:30.13ID:kDrPKY9d
ASP.NETのBlazorのスレッド part2です。

ASP.NET
https://dotnet.microsoft.com/apps/aspnet
ASP.NETは、クロスプラットフォーム対応、無料、オープンソースのフレームワーク
Free. Cross-platform. Open source.
A framework for building web apps and services with .NET and C#.

Introduction to ASP.NET Core Blazor
https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-5.0

【本命】Blazor スレ1【真打】
http://mevius.5ch.net/test/read.cgi/tech/1595255796/
2デフォルトの名無しさん
垢版 |
2020/11/22(日) 05:37:28.65ID:kDrPKY9d
Blazor
Build client web apps with C#
https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
2020/11/22(日) 12:05:05.73ID:ab9PVYBK
アンチBlazorがVS、VSCodeの対立を煽り、スレを荒らしている可能性があります
内輪もめはやめて、Blazorについて有益な意見交換の場にしましょう
2020/11/22(日) 12:12:49.29ID:vrdBpsCk
Blazor Serverでもwasmでもいいんだけど
大規模になると1プロジェクト（wasmだと3プロジェクト）では収集がつかなくなるような気がしている。
例えば業務系だと100機能くらいあったりするわけだがその分Viewを作るのはまずいよな？
mvcはareaで分けているけど、あれも結局フォルダで分けてるだけだからなあ

複数のプロジェクトを跨いで開発、デプロイをするようなサンプルはないものか。
2020/11/22(日) 12:18:49.45ID:kDrPKY9d
>>1
ローカルルールひとつだけ追加

スレ立て時にワッチョイをつけるのは厳禁
理由1: 荒れるから。人物特定と人物叩きの話題が増えるため
理由2: ワッチョイはセキュリティ、プライバシー上の問題があるため
NGにしたい場合は各自で対応するように。
2020/11/22(日) 12:22:30.45ID:dtkY0af3
フォルダ分けでいいと思うけど
あでもビルド時間を短縮したいならプロジェクト分けたほうがいいのか
2020/11/22(日) 12:31:41.65ID:kDrPKY9d
>>4
ASP.NET MVCではファイルが増えがちなのは仕方ない。
そういうもの。

Razor PagesはMVCほどファイルが複雑にならないというのを
利点にあげていた。
ただ俺にはRazer Pagesは柔軟性のない欠点のが大きく見える。
コードビハインドで昔のWeb Formsっぽいというかね
2020/11/22(日) 12:58:15.06ID:4i3C/72s
>>7
いやMVCやPagesは一例でほんとに聞きたいのはBlazorのほうね

例えばBlazorSeverはDataフォルダのXXXServiceの数分Program.csでAddSingletonしてるが
あれも100Service作ったら100回するのか？
チームで開発してたらみんなProgram.cs触りまくることになるし
なんだか現実的ではないような。

そもそもServiceもどの単位でつくればいいんだろ。
モデルの数だけ？
2020/11/22(日) 12:59:40.95ID:bLh5qcao
ファイル増えるのが嫌なら自分でビューエンジンを作ればいい　大変だけど

頑張れば razor 使ったままで
ビューファイルをデータベースからロードして中身も構成し直すとかできるかも
2020/11/22(日) 13:03:24.97ID:abaPzBFv
>>8
Blazorとかあまり関係ないAsp.netの基本じゃないかそれ？
アセンブリ単位でのサービス登録、リフレクションを使ったサービス登録、サービス登録のサブモジュール化、などいくらでも手段はある
2020/11/22(日) 13:05:55.19ID:bLh5qcao
>>8
そういう場合ばかり普通別のファイルにメソッドなり新しいクラス作るなりして
そこにサービス追加するコード書くんじゃないの
2020/11/22(日) 13:12:52.05ID:nWFJksTe
>>3
どっちかというと、
Blazor基地外が他スレで暴れてるんだけどな。
それでこのスレに注目が集まってる。
2020/11/22(日) 13:17:15.75ID:vrdBpsCk
>>10
そうなのか
知識不足ですまん
じゃあServiceはカテゴリごとに別プロジェクトで作成して
そのdllをAddSingletonしたらいいのかな
2020/11/22(日) 13:21:22.95ID:vrdBpsCk
なんとなくカテゴリごとにBlazorServerのプロジェクト作るのかなと思ってたんだが
まとめてIISなりにデプロイする方法がわからんかった。
2020/11/22(日) 13:33:44.46ID:abaPzBFv
>>13
やり方は色々ある
うちのやり方だとまずステレオタイプで分けて、ジェネリック型の登録、リフレクションで登録、個別に登録と段階分けてして登録してる
で、それをIServiceCollectionの拡張メソッドでラップしてUseXxx(オプション)の形式で公開
2020/11/22(日) 13:51:05.25ID:vrdBpsCk
>>15
なるほど
サンプルくれ
2020/11/22(日) 14:01:22.68ID:bLh5qcao
.NET Core で作られてるオープンソースのCMSがあるから
そのソース見ればいいと思う
2020/11/22(日) 14:15:18.33ID:ujQ9d+0r
ここ見る限り簡単さで売ってるフレームワークじゃないみたいだな。
他の探すわ。
2020/11/22(日) 14:28:03.57ID:vrdBpsCk
>>17
ありがとう
探してみる
2020/11/22(日) 14:42:21.15ID:abaPzBFv
>>18
Reactより単純だよ
2020/11/22(日) 17:58:24.06ID:NUTvM1Lb
純粋にBlazorの話がしたい人はこちらに移動してくださいね

【本命】Blazor スレ2【真打】
https://mevius.5ch.net/test/read.cgi/tech/1606028377/
22デフォルトの名無しさん
垢版 |
2020/11/23(月) 02:43:30.92ID:WFPhqmL6
>>21
のスレはスタンドアロンでBlazorを使う場合のみのスレ

ここはASP.NETがバックエンドに絡む場合にもOKのスレ
2020/11/23(月) 07:21:58.63ID:con/o1/6
スタンドアローンでBlazor使うのってどういうケースなんだ？
ゲーム？
あ、電卓か。
2020/11/23(月) 08:37:48.72ID:UgGRFwp8
>>22
いやいやBlazorだってASP.NETの中のピースなのでその理論はおかしい
25デフォルトの名無しさん
垢版 |
2020/11/23(月) 08:51:36.23ID:WFPhqmL6
>>23
データを全部ローカルに持ってるアプリ
サーバーレスで使えるゲームとかもそうだな

>>24
真打スレの1が頭おかしいからしょうがない
ASP.NET野郎とか言い出してASP.NETの話題を極度に嫌ってる

難癖としかいいようがない
単純にポエムっぽい気持ち悪いテンプレ1を変更されてキレてるんだろう
26デフォルトの名無しさん
垢版 |
2020/11/23(月) 08:55:59.65ID:WFPhqmL6
>>1
誤解のないようこちらにも書いておくけど
前スレと扱ってるテーマは何も変えてない。

本命、真打とかいういらないスレタイのワードを消して検索にかかりやすくした
気持ち悪いポエム系テンプレをなくした
これだけ。改善しかしてない
2020/11/24(火) 00:14:25.35ID:EBaS3Lgi
あっちの>>1はいろいろとあたまおかしい
せっかくだからあっちから出てこないでもらいたい
28デフォルトの名無しさん
垢版 |
2020/11/24(火) 20:21:06.22ID:VvBbDMQG
BlazorはASP.NETと関連性が高いしASP.NETの話題が出るのは避けられない。
こっちは前スレの実態どおりに、ふつうに使っていきましょう
2020/11/25(水) 18:39:02.03ID:zFotDvmS
asp.net mvcとblazorを混ぜこぜにすることってできるんだろうか
asp.net mvcで作ったアプリを全部blazorに変更する必要はないんだが
一機能だけ複雑怪奇なUIなのでBlazorで作りたい
2020/11/25(水) 19:11:12.24ID:89i//6R1
>>29
できるよ
31デフォルトの名無しさん
垢版 |
2020/11/25(水) 20:21:13.57ID:imttWao4
>>29
どっちのBlazor？？

複雑なUIはXamarin.Formsが最適解だとおもうわ
速いし、開発も楽
2020/11/25(水) 20:44:21.95ID:zFotDvmS
いやすでにMVCのWEBアプリで出来てるのにいきなりその機能だけザマリンになったら困る…
2020/11/25(水) 20:44:45.21ID:zFotDvmS
あ、BlazorServerかな…
楽な方でいいんだけど
2020/11/26(木) 01:20:30.80ID:OS71rNiZ
つーか、前スレからxamarin推しのアホが居着いてるけどいい加減控えろって
2020/11/26(木) 01:49:05.56ID:O9/RzT4k
ASP.NETの話題禁止のクソスレに書き込んでしまいました
VPSを借りて、Linux上にasp.net core(?)をインストールすれば、BlazorServer
が普通に使える様になるのでしょうか？
36デフォルトの名無しさん
垢版 |
2020/11/26(木) 03:24:06.62ID:+DwRTiUz
>>34
良いものを勧めて何が悪い
nativeなら別にXamarinじゃなくてもいいが、
ここはMSの技術のスレだから俺なりに配慮してMSのXamarinを書いている
Blasor Wasmが現時点でムリゲーなのは触ればわかる
37デフォルトの名無しさん
垢版 |
2020/11/26(木) 03:33:19.75ID:+DwRTiUz
>>35
用途と規模、同時接続数は？
ASP.NETの話題禁止のクソスレではレンタルサーバーとか
VPSとか勧めてた人いたけどよっぽど小規模じゃないとアウトだと思う

Blazor Serverはserver-sideで多くの仕事するから
スペックがしょぼい共用のServerは適さない。
専用にハード用意してでオンプレミスか、
その運用ができないならAzure使ったらいいと思う。
2020/11/26(木) 08:20:06.17ID:a2VDJR7j
>>36
その前にザマリンってブラウザ上で動いたっけ…

>>37
企業内でしか使わない、同時接続はせいぜい100くらいかな
この手の使い方ならBlazorSever一択な気がする
wasmはServerが選択できないようなシチュエーション、不特定多数が使うゲームとかで使う感じ

しかしBlazorServerってパフォーマンスについてはほんとに未知数。
作ってみて全然ダメなんてなったら総スカンだよ
だれかややこしい画面100機能くらい作って実験してみてくれ。
後世まで讃えられるよ。
2020/11/26(木) 12:21:32.51ID:OS71rNiZ
ザマリン野郎はただのハッタリ詐欺師よ
どこかの派遣先でちょろっと触った事がある程度の経験しか無い癖に、さも分かってるかのように騙る馬鹿
2020/11/26(木) 12:55:56.37ID:a2VDJR7j
ザマ郎め…
41デフォルトの名無しさん
垢版 |
2020/11/26(木) 13:10:39.86ID:+DwRTiUz
>>38
nativeはブラウザで動かないからこそいい。

ブラウザの悪いところの制約をうけない。
CSSとhtmlでUIつくるする必要ないから生産性高くて動作もはやい
XamarinならJSだけでなく、めんどくさいCSSとhtmlも意識しなくてよくなる
2020/11/26(木) 14:47:34.74ID:a2VDJR7j
>>41
いやブラウザ上で動かすと言うのが要件です
2020/11/28(土) 21:32:26.57ID:VVrnAQDV
エセザマ野郎が本家Xamarinスレで暴れて鬱陶しいんで、きちんとここに隔離拘束しといて！
2020/11/29(日) 12:22:21.90ID:t4883+oA
ザマ郎め…
45デフォルトの名無しさん
垢版 |
2020/12/01(火) 16:13:35.40ID:KJeyTCS5
Blazorwasmって、ローカルで動かしてみたり、認証のいらないアプリを書いたりするには良いけどさ
認証を入れて安物VPSに配置すると、Pingが高いせいかめちゃくちゃ遅くなっちゃうのな
Azureを契約したら認証を使ってもまともなスピードで動くのか気になるところなんだけど、どっかで体験できるサイトってないかな？
2020/12/01(火) 16:55:46.55ID:TBput4Ui
認証の実装次第じゃね？
2020/12/01(火) 17:08:37.83ID:mXq+MLFh
>>45
azureのfreeプランで体験すればいいんじゃないの
48デフォルトの名無しさん
垢版 |
2020/12/01(火) 17:11:08.20ID:EvEZBXUJ
>>45-46
認証どの方法でやってるの？認証というかDBがクソ遅いんでは？
ストレージと契約プランは？

自分の固定回線でサーバー立ててオンプレミスでパフォーマンス
見てみればいい。
モバイル回線からアクセスとかして実際のローディングの実感つかんだり。

VPSとかレンタルサーバーとかスペックがとにかくしょぼい
維持費下げて快適なサーバー作るにはオンプレミスでやるべき
2020/12/01(火) 17:13:55.57ID:EvEZBXUJ
オンプレミスなら占有できるし、ストレージもSSDとか使える。
安いVPSとかいまだにHDDだったりとにかくスペックがゴミだぞ
大手クラウドはましだけど維持費高い
2020/12/01(火) 18:48:51.15ID:WP+WGTcn
誰かと共有してるサーバーなんて、
誰かの処理が多かったら、自分の処理は少なくなる

特に安い所は、共有者が多いかも
2020/12/01(火) 19:18:59.55ID:mXq+MLFh
AWSのlargeインスタンスに本番デプロイしてるけど特に問題なしだな
2020/12/01(火) 19:36:41.77ID:+qF/uZ2f
>>45
webassemblyはローカルで動くんだから
VPSは関係ないでしょ

関係あるとしたら必要以上に通信してるとか
設計の問題でしょ
53デフォルトの名無しさん
垢版 |
2020/12/01(火) 21:47:54.47ID:EvEZBXUJ
>>52
関係あるに決まってるだろう
最初のローディングはサーバーからのダウンロードだし
認証やるならDBの速度にひっかかる。
スタンドアロンで完結するアプリなんてほとんどない
2020/12/02(水) 00:16:56.71ID:3xGcwmKY
もしかしてクライアントからDB直接アクセスしてんのか
55デフォルトの名無しさん
垢版 |
2020/12/02(水) 00:53:22.98ID:EgVjsFYE
認証使ってるのか書かれてないから不明だが認証は通常DBを使うし
安いVPSだとApplication Serverと同一のhostにDBもあるし、
たくさんのユーザーが同時使用するから遅い。
共有サーバーでストレージがHDDだとすごく遅くなるのは明らか
2020/12/02(水) 01:11:28.10ID:YoQmKH+u
認証のDBアクセスが重いとか、どんだけ高負荷な有名サービスだよ
2020/12/02(水) 02:35:00.10ID:ZTMuPDF1
>>56
それは思った。
そんなサイトは世界でも100も無いのではないかと思うのだが。
58デフォルトの名無しさん
垢版 |
2020/12/02(水) 06:18:58.14ID:EgVjsFYE
>>56-57
web appで一番ボトルネックになるのは
RDBってのは昔からふつうのことだぞ
だからこそRubyやJSなど低速な言語のサイトもけっこうある。
ボトルネックが言語よりもDBになることが多いからだ

あと通常、認証後にもリソースの権限チェックが行われる。
トークンベースだったとしてもそこの計算量が多くCPUにも負担がかかる。
DBが高負荷のときはCPUリソースも余裕がない可能性高い
59デフォルトの名無しさん
垢版 |
2020/12/02(水) 06:22:57.09ID:EgVjsFYE
>>56-57
どんだけ有名サービスだよってことじゃなくて、
レンタルサーバー、VPSがどんだけ詰め込んでんだよって話
限界まで詰め込みすぎなわけ
共用サーバーは膨大な数のWordPressとかが動いてる

同一サーバーの契約者数、アクセス数が多いから
自サイトのアクセス数の絶対数が少なくても性能が足りなくなる。
オンプレミスにするかまともなクラウドを使えばいい
2020/12/02(水) 08:22:53.00ID:+nSH4YQS
Blazor Serverの仕組みって一般的にはなんと呼ばれる技術なのか分かる人いますか
SignalRでSPAを実現してるやり方って他の言語やフレームワークにもある？
MS系に詳しくない人たちに説明したい。
2020/12/02(水) 10:29:09.09ID:yJY81L7A
サーバー不要の方式がSPA
62デフォルトの名無しさん
垢版 |
2020/12/02(水) 11:01:43.03ID:EgVjsFYE
>>60
エンジニア向けの説明？
MS技術に詳しくない人ならSignalRも知らないはず

類似のSPA技術はないだろう。
ほかのframeworkはなるべくステートレスにやろうとするが
Blazor Serverはステートフルでサーバーが多くの仕事をする。
しかもJSを書かない
2020/12/02(水) 12:25:38.82ID:+nSH4YQS
古くなったWebFormの移行先の技術選定で、社内のお偉方に説明する必要がある。
Serverの方は既存コードから再利用性が高そうだから使ってみようと思ったが
こんな技術が身についても潰しが効かないし、若手が嫌がりそう。

wasmも使い物にならんし
ts+Reactとかに思い切って移行するほうがいいのかもしれないと俺は思い始めた。
2020/12/02(水) 12:31:47.85ID:yJY81L7A
既存のクソコードを一掃する
チャンスでもあるわけだ。
2020/12/02(水) 12:35:05.78ID:4ZukVyfA
>>63
BlazorとWebFormsは全然違うからダイレクトに移行するメリットはないよ
WebFormsをリファクタリングしてAspNet Core Webapi+WebFormsの形に落とし込む
その後WebFormsを好きなフレームワーク乗せ変える
移行先のフレームワークとしてBlazorを選んでもいい
これが移行の王道
2020/12/02(水) 12:49:23.65ID:+nSH4YQS
>>65
なるほどなあ
しかしwebapiの設計がまじでわからん

みんな本当にget,put,post,deleteのRESTの原則に従って作ってるのだろうか。

バッチ処理とかどうしてるんだろう
2020/12/02(水) 12:53:18.42ID:yJY81L7A
>>66
大分まえから普通がRESTよ。
つい最近もオレオレREST？API作ってきたベンダーが集中砲火。
2020/12/02(水) 13:54:47.31ID:vDg6xkSY
REST, GraphQL とか

バッチ処理は、AWS Batch, Lambda とか
69デフォルトの名無しさん
垢版 |
2020/12/02(水) 14:00:38.77ID:EgVjsFYE
>>63
思い切って移行ならXamarin.Forms
速くて使いやすくて喜ばれる
スマートフォンアプリ作れるようになるしエンジニア教育の
面でもベストだわ
少し待ってMAUIでもいいとおもうが。

>>65
AspNet Core Webapi+WebForms
はいったんレガシーとミックスさせる方法だから、
無駄にコストと手間かかりすぎだと思うわ
新規で作って切り替えるほうが楽だし現実的
2020/12/02(水) 14:02:40.02ID:7ARpvJUU
Visual Studio使ったら難しいこと考えなくてもC#でREST API生成できるやん
2020/12/02(水) 14:03:35.26ID:7ARpvJUU
Xamarin野郎来たからBlazor本スレに戻るわ
72デフォルトの名無しさん
垢版 |
2020/12/02(水) 14:09:13.66ID:EgVjsFYE
>>71
新しいことを学べない人には無理だろうな
Xamarin.Formsという言葉だけで拒絶反応を示す

スタンドアロンスレに戻りなｗ
2020/12/02(水) 14:28:48.10ID:u23z8tnt
あ、知識・スキル共に皆無なことが露呈してXamarin本スレから逃げ出した人や
こいつこんな所におったんか
2020/12/02(水) 15:32:11.71ID:3xGcwmKY
>>66
今どきRESTだけなんて無いよ
クエリスタックはRESTとGlaphQLの組み合わせ
コマンドスタックはgRPC
これが今のスタンダード
2020/12/02(水) 16:08:55.57ID:yJY81L7A
>>74
gRPCが今のスタンダード？

笑
2020/12/02(水) 16:10:32.50ID:u23z8tnt
MagicOnionマジおすすめ
2020/12/02(水) 18:02:17.85ID:+nSH4YQS
昔SOAPを使っていたのもあって
なかなかREST APIに馴染めない
に加えてあのURIを文字列で記述するのが嫌
クエリパラメータも文字列なのが嫌
スペルミスしてたら動かないとかつらすぎる。
（あんまり使ったことないから間違ったこと書いてたすまん）

せっかく同じC#なんだから型安全がいい
おそらく自分にはgRpcの方が馴染みそう

しかし一番馴染むのはBlazorServerのXXXService()
あんな楽なものはない。
だからBlazorServerが魅力的なんだよおおおお
惜しい
2020/12/02(水) 19:39:41.09ID:3xGcwmKY
>>75
そだよ
コマンドスタックは現状これしかない
2020/12/02(水) 19:44:30.50ID:yJY81L7A
>>78
スタンダードの意味は？
80デフォルトの名無しさん
垢版 |
2020/12/08(火) 10:45:05.78ID:p9ADjhn4
何をやっているか知りたいので空のプロジェクトから解説しているサイトないですか？
dotnet new web
2020/12/08(火) 16:14:08.34ID:11kT5JjZ
>>80
？

dotnet new webっていうコマンドが
なにをやっているか知りたいってこと？
2020/12/08(火) 16:23:50.99ID:aYlokb/a
>>81
もんもー？

dotnet new web後の流れが知りたいってことでしょ
2020/12/08(火) 16:43:22.34ID:C+tXhbuq
本ならあった気がするがサイトは知らんな
2020/12/08(火) 16:45:34.63ID:v7gdDVm9
スレチ
2020/12/08(火) 17:11:29.09ID:E4wQPgos
文もう
2020/12/08(火) 18:21:19.48ID:11kT5JjZ
>>82
それってテンプレートから作ったものを
読めばいいんじゃね
87デフォルトの名無しさん
垢版 |
2020/12/09(水) 10:00:37.08ID:R4W4bNd2
>>80
>1-2 のテンプレートに書いてあるだろう
まずはMicrosoftのドキュメントに目を通す
2020/12/18(金) 07:21:07.35ID:5JOKzxNw
この技術に限らずMSの出してくるフレームワークに手を出しづらい理由
MS自身が使ってないからなんだよな…
ブラウザ上でうごくExcelをBlazorで作ってるんなら安心するんだが。
89デフォルトの名無しさん
垢版 |
2020/12/18(金) 09:13:03.15ID:AKVGlWuS
>>88
wasmの話だろうと仮定。
そんな無駄な移植しても意味ないし当然だろう
Excelはweb appとnative appで存在するのに
中途半端なBlazor Wasmで作る意味がない。

Excelに限らない話かもしれない
このままweb appとnative appだけが続き
wasmが普及しない未来はありうる。
2020/12/18(金) 09:16:42.38ID:mc4Y4fQo
pythonが動き出すと話は全く変わってくる
2020/12/18(金) 19:18:46.90ID:WIChbQFJ
>>89
NativeにしてもWPFやXamarinでは作ってないよね
たしかReactNativeだったかな

技術的な意味がなくても移行をあえてやってみて
Officeで使われた技術です！
って宣伝するだけでその技術への信頼度上がるとおもうんだけどなー
92デフォルトの名無しさん
垢版 |
2020/12/18(金) 20:08:20.82ID:AKVGlWuS
>>91
SPのExcelはReact Nativeなの？
Xamarinじゃなくて？

MSが使ってるかどうかよりも
MSと資本関係ののない多くの会社が使ってるかの方が信頼できるな
MSが使ってても宣伝やしがらみのためだと思われることもある
93デフォルトの名無しさん
垢版 |
2020/12/18(金) 20:12:21.48ID:AKVGlWuS
>>90
Pythonはスクリプトだから遅いし大規模にも向かない。
TSとおなじく、MSのnative appやASP.NETでは
使えない状態のままだとおもう。
主力はC#

PythonはAIとか強いからMSとしてその分野の強化かと
94デフォルトの名無しさん
垢版 |
2020/12/18(金) 20:22:53.83ID:UPU6Cu+L
愛の不時着いいよね〜ｗ

見たことないけど。
2020/12/18(金) 20:38:35.56ID:WIChbQFJ
>>92
SPがなにかわからんけど
クロスプラットフォームかということでReactNative使ってるんだと。
https://www.softantenna.com/wp/software/office-in-javascript/
2020/12/18(金) 20:45:25.39ID:4UaQE5Dn
>>92
https://appfigures.com/resources/insights/microsoft-goes-all-in-on-react-native

iOSアプリでは…
Bing Search
Microsoft OneDrive
Microsoft Outlook
Xbox
Microsoft Word
Microsoft OneNote
Microsoft Excel
Mixer - Interactive Streaming
Microsoft SharePoint
Microsoft Teams
Cortana
Microsoft Edge
Office Delve - for Office 365
Microsoft Visio Viewer
Dynamics 365 for phones
PowerApps
MS Executive Industry Summit

続く
2020/12/18(金) 20:45:59.21ID:4UaQE5Dn
>>96 続き

Androidアプリでは…
Microsoft OneDrive
Microsoft Outlook
Microsoft Word
Microsoft Excel
Microsoft PowerPoint
Xbox
Mixer - Interactive Streaming
Microsoft Teams
Xbox beta
Microsoft Edge
Microsoft Cortana - Digital assistant
Microsoft Kaizala
Microsoft SharePoint
Face Swap
Microsoft Selfie
Bing Ads
AltspaceVR - The Social VR App
PowerApps
Mixer - Interactive Streaming Beta
Xbox Game Pass (Beta)

…が、ReactNativeを使うてますねｗ
2020/12/18(金) 21:29:16.49ID:WIChbQFJ
日本の企業にありがちな
他部署が作ったオレオレフレームワークが他の部署では使われないみたいなやつ。
99デフォルトの名無しさん
垢版 |
2020/12/18(金) 22:05:46.36ID:AKVGlWuS
>>95
SP=Smartphone

MSにしてはけっこう多いな、
別の記事ではMSはXamarin使ってると書いてあった。
MSはMAUIでたらMAUIに移行するんでは。
YouTubeはXamarinらしい。

最近のシェア動向
https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours/
React NativeとFlutterが上位
2020/12/18(金) 22:11:56.09ID:+Wrhvh6s
YouTubeがxamarin？見間違いじゃねえか？
2020/12/18(金) 22:27:08.65ID:WIChbQFJ
Nativeは置いといて
ブラウザ上で動かすExcelのような複雑なUIのアプリは、jsよりWebAssemblyのほうが向いてると思うんだが。

それでも作り直すメリットがないのであれば
逆にWasmは何に使うのが正解なんだ…？
ゲームのみ？

CRUD中心の企業向けアプリなんてwasm選ぶ必要なくね？
BlazorServerの方が生産性高いし。
2020/12/18(金) 23:52:57.38ID:Lq+ZSFwA
>>93
全てのアプリが速さを追求するわけじゃない
大規模なアプリも小規模なアプリもある
Pythonの膨大なライブラリがブラウザで動くことが重要
2020/12/18(金) 23:57:26.29ID:Lq+ZSFwA
>>101
新規サービスはBlazor一択
VS、C#自体の高生産性、バックエンドとフロントエンドが同じ言語で書けるメリットは大きい
速度も比較すると今はまだ遅いけど、体感ではどんぐりの背比べ、ぜんぜん問題ない
デバッグはまだやりにくいが、テスト書けばいいだけ
2020/12/18(金) 23:59:15.50ID:Lq+ZSFwA
>>101
Excelとか既存の大規模アプリは移植のコストが割に合わない
2020/12/19(土) 00:08:47.12ID:x1EY5aRu
つまり遅くてデバッグもしにくくて使い物にならない、と。
2020/12/19(土) 00:25:06.52ID:8bUfeulY
>>105
問題ないと言ってる
107デフォルトの名無しさん
垢版 |
2020/12/19(土) 00:25:30.46ID:pyDV0l6z
>>102
AIでPython使うなら速度は大事。
PythonのライブラリはCを多用してるようだし。

スクリプトだと開発生産性も落ちる
Blazor wasmだと現状まともなデバッグできないからさらに生産性落ちる。
2020/12/19(土) 00:30:54.14ID:KJkGIAX1
>>89
ちゅうか、Blazor Wasmが駄目だからと言ってWasm自体の問題と混同しては
いけない。なぜなら、JS以外でWebページやWebアプリを作りたい需要は
とても多いはずなので、そのためにはWasmしか選択肢が無いから。
Wasmはプログラマが使う言語ではなく裏方で動くマシン語なのでWasmが
仮にどんなに使いにくくても、プログラマが使う言語にはほとんど影響しない。
109デフォルトの名無しさん
垢版 |
2020/12/19(土) 00:31:30.10ID:pyDV0l6z
>>101
＞CRUD中心の企業向けアプリなんてwasm選ぶ必要なくね？

これはそのとおりだがそもそもSEO必要ないならweb appの必要がない。
なんでもブラウザでやろうとするのは思考停止。
native appのほうが生産性も高いし、速度も速いし使いやすい。
wasmよりもMAUI, Flutter, Xamarinなどnativeのほうが流行る可能性が大きい。

Blazor WasmについてはJS interopが遅いという問題もあるし
それとデバッグが解決するまで俺は静観ですわ
2020/12/19(土) 00:40:03.17ID:pyDV0l6z
>>108
そうはいっても
Blazor 以外のWasmがほとんど使われてないからな

一方でnativeは廃れる気配はない。

Swift, Kotlinでnative appの学習する分には無駄になることはほぼない。
MAUIが流行ったとしてもGoogle/Apple純正ツール開発と
Kotlin, Swiftの知識が役に立つ
2020/12/19(土) 00:43:46.76ID:H4M2BfyN
BlazorServerはいらない子なのか？
2020/12/19(土) 00:43:58.13ID:avFHhi1d
ザマ爺、本命Blazorスレでボコられたからって今さらこっち戻ってくんなよハゲ
2020/12/19(土) 00:50:09.15ID:KJkGIAX1
>>110
FlutterやXamarine, MAUI, Qtなどと比べてWasmの優位性は、
実行形式が1つしか要らないのでビルドが速く、開発時のバックアップや
バージョン管理が楽と言うこと。
前者でAjail開発を行おうとすると、僅かに修正するたびに全てのターゲット
について再コンパイルして毎回テストしなくてはならない。
iOS/Android/Windows/Mac/Linux用に作る場合、5回、
64BIT版と32BIT版の両方が必要な場合、10回。
これだと開発に時間がかかってしょうがない。
一方、Wasmだと一回ビルドすればよいだけだしテストも1回でもなんとかなる
場合が多い。テストが省略できる理由は、ブラウザ自体がHTML5によって
プラットフォーム間の互換性を維持してくれているため。
2020/12/19(土) 00:51:22.44ID:1ZOkfUtM
>>109
配布やらバイナリの管理やらに手間がかかるから
社内向けのシステムでもデスクトップアプリの応答性能が必要なければWebアプリ使うほうが主流やぞ
2020/12/19(土) 00:54:22.75ID:KJkGIAX1
>>113
最近、実行形式のサイズが大きくなって、ターゲットプラットフォームが多くなると、
バックアップに時間と容量を必要とする様になってしまった。
差分や増分バックアップでは途中のバージョンの欠損ですべてが失われる危険がある
のでやはり単純コピーしたいが、そうなるとプラットフォーム毎に実行形式が
異なっていることは非常に大問題となる。
その点、Wasmだとあらゆるプラットフォームで実行形式が単一しか要らなくなる
のでバックアップの時間もストレージの消費も少なくなって便利。
もちろんビルド時間も大いに節約でき、生産性も上がる。
2020/12/19(土) 00:58:02.14ID:KJkGIAX1
>>115
最近驚いたのが、VS2019ではMFCの(Debug,Releaseなどの)ビルドディレクトリ
のサイズが1GB程度に膨れ上がってしまっていることだ。
こんなもの、バックアップをどうしろというのだ。
コピーするだけで大変な無駄な時間が要る。
2020/12/19(土) 00:58:22.58ID:8bUfeulY
>>107
学習は別にすればいい
AIも使うだけならそこまでではない
そして仮にAIが駄目だったとしてもそれでpythonの全ての価値を失うわけではない
AIはpythonの極一部の用途でしかない

スクリプトとC#を比べたらC#が勝つのは当たり前
しかしpythonには豊富なパッケージがある
pythonがブラウザで動くならそれは大きな価値がある

デバッグをする必要はない
やるべきことはテストコードを書くこと
テストコードを書けば自然とデバッグをする機会も減る
これはBlazorがどうのこうの以前の問題
テストツールがこれだけ充実してる時代にまだデバッグしてるんですか？
2020/12/19(土) 01:01:33.63ID:pyDV0l6z
>>113
技術的に可能だからといって全部対応する必要はない
web appでIEを切るのと同じようにnativeでMacやLinuxは切る

Linux desktopなんて無視でいい。シェアがない。
Macもシェア小さいので無視。会社でMac無しはふつう
64bitで動けば32bitも普通まずそのまま動く

法人で使うならWindows10 64bitとAndroidとiOSだけで十分
WindowsとSPどちらか片方でもいい
2020/12/19(土) 01:05:15.02ID:pyDV0l6z
>>114
deployガーっていうのはもうやめてくれ
それは管理者、開発者が無能なだけだ

クリック押すだけのインストーラーつくってもいいし
システム管理ツールでdeployしてもいい。
アプリ開始時にバージョン通知するようにしとけば、
各自のバージョンも把握して強制アップデートもできる。
そういうアイデアがないひとがdeployが、と騒ぐ。
2020/12/19(土) 01:07:02.04ID:KJkGIAX1
>>118
まあ、言ってることはわかるが、Ajail開発では、テストを小まめにすることが
重要とされる。
例えば、64BITだけでビルドとテストをしつづけて、100回目で32BITでも
やってみたら、駄目、と言う事になる可能性があるが、その場合、不具合の
原因がどの修正によってもたらされたのは分からなくなるので、原因の不具合
の切り分けが難しくなるため、なるべく毎回テストした方が良いと考えられて
いる。ただし、ビルドとテストに時間が掛かって、むしろ開発効率が
悪くなることもあるので絶対ではないが。
2020/12/19(土) 01:07:28.35ID:pyDV0l6z
>>117
まだデバッグしてるんですかって？え？？
コード書きながら動作確認するのもデバッグなわけだがｗ
2020/12/19(土) 01:09:22.42ID:H4M2BfyN
毎回Nativeをやたら推してくるやつが湧いてくる。。
2020/12/19(土) 01:16:12.58ID:tyWP7Wcq
ID:pyDV0l6z
貴方、MS関連スレでオンプレ爺さんと呼ばれてる人ですか？
124デフォルトの名無しさん
垢版 |
2020/12/19(土) 01:20:51.08ID:pyDV0l6z
Blazor Wasmやりたがってたひとって
wasmだからやりたいってわけじゃない。
ほとんどはただCSSやJSがきらいな人たち。図星だろう？

web appである必要ないのにまわりと一緒になって思考停止していて
生産性の悪いCSSゴミやJSでもがいて開発が進まない。

JSがいらない素晴らしい！と
Blazor Wasmのような成熟してないのもに手を出してしまう。

SwiftとかKotlinを学習してnativeでさくっと開発してリリースしてしまうほうが速い。
2020/12/19(土) 01:27:21.70ID:KJkGIAX1
速度は少々犠牲にしても開発し易ければ使われる、という歴史を何度も見てきた。
ターゲットが増えても、ビルド回数が一回で済むこと、バックアップのための
ストレージが少なくて住むこと、バイナリの管理が楽なこと、などのメリットが
Webアプリにはあり、なおかつ、好きな言語を使いたい需要が大きい以上、
Wasmが生き残っていく可能性は高いと見ている。
2020/12/19(土) 01:31:03.86ID:H4M2BfyN
>>125
じゃあBlazorServerで良くないか？
127デフォルトの名無しさん
垢版 |
2020/12/19(土) 06:52:39.03ID:pyDV0l6z
>>116 >>125
バイナリサイズ肥大化はC/C++の問題だろう
C/C++はDLLなどランタイムの互換性も問題になる。

しかしそれらはC#では解決しているのだから関係ない話

あとWeb appはブラウザのバージョンアップでレイアウト崩れたりする。
nativeはブラウザのバージョンに関係ないからリリース後はむしろ楽になる。
昔はIEでしか動かないweb appがたくさん開発されてて企業によっては
いまだに稼働している。
web appにはそういう負の側面もある。
2020/12/19(土) 06:54:57.16ID:pyDV0l6z
>>126
Blazor Serverは企業内で使うくらいだろう
ステートフルだからスケーラビリティがない。
2020/12/19(土) 09:15:20.46ID:H4M2BfyN
>>128
逆に企業外でwasm使うシーンってある？
ゲーム？
2020/12/19(土) 09:40:11.79ID:8bUfeulY
>>121
やれやれ
動作を確認するんじゃない前提と結果を確認するんだよ
それはテストだ
2020/12/19(土) 09:40:59.84ID:8bUfeulY
>>124
C#を使いたい人だよ
2020/12/19(土) 09:50:15.99ID:29ydT2k+
デスクトップはテストが面倒くさくないか
Seleniumは安定してるけどWinAppDriverは微妙
2020/12/19(土) 12:27:51.83ID:3Uzrrw/t
>>127
VS2019のMFCではバイナリサイズが極端に大きくなっていたが、それより十分前の
VSではそんなことはなかった。
なのでバイナリサイズが大きいのはC++そのものが原因ではない。
2020/12/19(土) 12:29:39.47ID:3Uzrrw/t
>>127
レイアウトの崩れはWidget類をcanvasにグラフィックで描画している場合は
起きない。
2020/12/19(土) 12:34:53.83ID:LKhLVIez
デスクトップアプリは未だにFormsの忌まわしい思い出を引きずっててな
2020/12/19(土) 12:44:26.38ID:3Uzrrw/t
>>135
どんな思い出？
2020/12/19(土) 12:47:54.80ID:FPzjGDbs
>>116
中間ファイルなんかバックアップとる必要ないだろ
2020/12/19(土) 12:50:43.81ID:LKhLVIez
>>136
残業、徹夜、バグ地獄
デスクトップが高生産性なんて嘘だ
2020/12/19(土) 12:58:36.30ID:aM5epQiT
>>138
そういう職場がBlazor使ったところで問題解決にならないだろw
2020/12/19(土) 13:00:34.17ID:3Uzrrw/t
>>137
ちなみに、Debug/Releaseフォルダは中間だけでなく最終バイナリも含んでいる。
また、不具合を発見した時、原因を探ったり、どのバージョンから不具合が起きていた
かを調査することは重要で、そのためには中間ファイルまで残っていたほうが
安全だし便利では有る。
ソースファイルだけ残していた場合、ライブラリやツールキット、ヘッダフィル、
コンパイラのバージョンが変化してしまっていることが多いので、元の
環境に戻すのに膨大な手間と時間が掛かるし、当時の環境にまで完全には戻し
切れないこともある。
毎回毎回、全ての関係ファイルのバージョンをメモすることも不可能に近いし、
古いヘッダフィルやライブラリなどを正確に全て保存しきることも難しい。
古いものをダウンロードしようとしても昔のURLアドレスは無効になっていて
探し出すのに苦労することも多い。
deprecateになっていてダウンロードできなくなってしまっている可能性も有る。
さまざまなライブラリを使っていれば、それら全てについて元に戻す作業が
必要となり、非常に時間が掛かる。
それを避けるためにライブラリ類をハードディスクなどに保存しようとしても、
容量が大きすぎて困ることも多い。
また、インストーラーを保存しても、インストール作業中にネットから
ダウンロードすることが前提になっているものも多く、ちゃんと古いバージョンを
保存することは難しい。
2020/12/19(土) 13:08:06.13ID:8bUfeulY
>>139
webになって淘汰されたから今は快適だよ
Formsは自然にスパゲッティになるように設計されてるとしか思えん
2020/12/19(土) 13:16:37.65ID:fca3Stwo
>>140
開発環境はDockerで作るといいよ
Dockerfileだけで十分だけどもし不安ならイメージをレジストリに保存しておけばまず間違いない
2020/12/19(土) 14:19:42.49ID:xTbqHGyz
>>142
dockerでWindowsコンテナって実用レベルになったの？
2020/12/19(土) 14:21:59.37ID:cBsPiTZc
>>124
Web開発にふむきな人用の
補助フレームワークですよ。最初から。
2020/12/19(土) 14:33:16.67ID:pyDV0l6z
>>129
ゲームは開発者が便利なUnityとかのライブラリで作る場合が多い。
Unityは生産性が高い。
一方のwasmは現時点でBlazor wasmはまともなデバッグができない。

あとはゲームといえばアプリ内課金だけど、wasmにすると
課金してもらうハードルがすごいあがってしまう。
SPのnative appだと手数料は高いが簡単に課金できる。

広告収入目当ての無料ゲームならwasmありだとおもうけど
ガチャとかで儲けようと思うとSP native appのが楽だと思うぞ
2020/12/19(土) 14:37:33.55ID:pyDV0l6z
>>130
俺の言ってるdebugはIDEのメニューのDebugに相当するものでおかしくない。
工程としてのデバッグと技術的なデバッグの違いは文脈でわかると思うんだがな
2020/12/19(土) 14:38:28.43ID:H4M2BfyN
>>145
ゲームでもなかったら何に使うんだこれってなる
BlazorWasmって最初は夢のような技術だと思っていたが、
俺のような企業向けアプリしか作らないやつにとってはBlazorServerが夢のような技術な気がしてきたぞ。
2020/12/19(土) 14:42:22.79ID:pyDV0l6z
>>134
グラフィックで描画したらSEO犠牲になるよな
SEOないならweb appでやる意味はないと俺は思う。
2020/12/19(土) 14:48:03.92ID:pyDV0l6z
>>140
それもC, C++の話でしょ
C#の人はそんな苦労はしてない
DLL地獄などバージョン管理の問題の多くは.NETで解決してる。
ソース保存だけで十分に後日デバッグできる。
2020/12/19(土) 15:17:18.87ID:H+0BgwK+
>>143
windows？
2020/12/19(土) 15:18:34.03ID:H+0BgwK+
>>145
テストしろよ
課金は内容次第
2020/12/19(土) 15:19:15.99ID:H+0BgwK+
>>146
そのDebugは必要ない
テストしろ
2020/12/19(土) 15:19:58.62ID:H+0BgwK+
>>147
夢のようだろ
C#でフロント開発できるんだから
2020/12/19(土) 15:23:14.19ID:3Uzrrw/t
>>148
SEO対策が必要な部分だけは、グラフィックでやらずに普通に p や div で
文字列を書く方法も考えられる。
2020/12/19(土) 15:24:00.22ID:JGeD5jA5
>>150
ID:3Uzrrw/tはMFCをビルドしたいんやで
2020/12/19(土) 15:42:15.72ID:piWwQ7Ox
お前らこの技術を使っていったいぜんたい何を作ろうとしてるんだ？
2020/12/19(土) 15:43:59.93ID:3Uzrrw/t
>>145
一番の問題はiOSだね。
技術的に可能でも、Appleから駄目と言われれば終わってしまう。
とにかくAppleはなんとしてもMacのXCodeを使ってないアプリはiOSでは
動かせないように目を光らしている。
セキュリティーとかいう理由は体のいい言い訳で、実際にはMacを強制的に
買わせるため。
本当は独占禁止法違反。
Macの互換機を作ったところで今度はXCodeを互換機にはインストールできない
ようにされるだろうが、それはEUでは「相互運用性のため」と言われて
独占禁止法違反に当たるが。
というわけでMacの互換機を誰か作るべし。
2020/12/19(土) 15:45:44.06ID:3Uzrrw/t
VirtualPCやVMWareみたいなもののWindowsで動くMac仮想マシンは無いのかな。
2020/12/19(土) 15:48:45.06ID:cfiN3g00
>>157
Macだけあれば良いのだから問題ない
2020/12/19(土) 15:50:12.89ID:3Uzrrw/t
>>159
個人的にはそれだけは嫌なのでiOSは無視するよ。
2020/12/19(土) 15:50:26.91ID:1ZOkfUtM
>>120
Ajail開発w
脱獄されないよう点呼も小まめにね
2020/12/19(土) 16:20:27.46ID:MvLlV0UQ
>>160
君がそうしたいならそうすればいい
雨の中で傘を刺さずに踊る人が居てもいい
それが自由というものだからね
2020/12/19(土) 16:24:52.94ID:3Uzrrw/t
>>162
iOSのアプリ開発は、企業に任せるよ。
164デフォルトの名無しさん
垢版 |
2020/12/19(土) 19:33:56.12ID:pyDV0l6z
iOS, Androidのシェアは日本ではほぼ半分
https://simchange.jp/post-164095/

iOS, Androidのどちらか先にappつくって
ヒットしたら移植するのでもいいだろう
165デフォルトの名無しさん
垢版 |
2020/12/19(土) 19:37:37.25ID:pyDV0l6z
>>158
VMwareでMac OSは動くようだよ
仮想化してるから速度は期待できないが。

>>157
Mac以外のハードでMac OSを動かす方法は既にある。
この話題はあれるから書きたくない
2020/12/19(土) 19:40:52.47ID:pyDV0l6z
最近、nativeの話してもバッシングされなくなったな
まえはXamarinの単語だしただけで基地外が騒いだけどｗ
多くの人がBlazor wasmのガッカリ感に気付いたかね？
2020/12/19(土) 19:59:06.06ID:G+RQMXDP
XamarinがNGワードに入ってるだけだと思うぞ
俺は技術的なワードはうざくてもNG入れない主義だから見えてるけど
2020/12/19(土) 23:35:45.44ID:cBsPiTZc
>>166
Blazor = Wasm + js
であることに騙され、
そのjsの占める割合が高い事に失望した。

結論

Reactでやった方が速いやんけ！（開発も速度も）
2020/12/19(土) 23:44:53.55ID:LpZi8G42
ザマ爺あっちのスレ戻れ
社内でしか通用しない老害のウンチクは向こうで垂れ流せ
2020/12/19(土) 23:52:19.46ID:tyWP7Wcq
ID:pyDV0l6z
やっぱり貴方、MS関連スレでオンプレ爺さんと呼ばれてる人じゃないですか！
なんで応答しないんですか！！
2020/12/19(土) 23:58:08.90ID:LpZi8G42
ここではスレチのxamarin推すガイジとして有名でザマ爺呼ばわりされて皆から嫌われとるんや
2020/12/19(土) 23:58:46.73ID:8bUfeulY
>>168
高くないが？
2020/12/20(日) 00:41:09.44ID:a9TnPW+R
>>166
Blazor本スレならスレ違いで叩くがここは雑談スレだから放置してる
2020/12/20(日) 01:13:21.56ID:qnjQAXRu
あっちはクラウドの話ばかりですが
2020/12/20(日) 03:32:44.06ID:Hx+xItDT
ここはガイジの隔離スレ
本スレに迷惑掛からないよう適当に相手してやってくれ
2020/12/20(日) 03:57:19.02ID:NmAfNXJq
>>165
有ってもWindowsを終了させて再起動しなくちゃいけないとかだったら
困るし、遅いのも困るし、XCodeをインストールできるかどうか、できても
ネットに繋いだ時にライセンス違反を指摘されたり、AppStoreに登録できるか
どうかも分からないし、とにかくAppleが絡むとろくなことが無いので
iOSは無視するしかない。
177デフォルトの名無しさん
垢版 |
2020/12/20(日) 07:58:59.61ID:vYm8Aryt
>>173-175
本スレってASP.NET知らない無能が立てたスタンドアロンスレのことか？
あそこも俺がネタふらないとすぐ過疎った。
Blazor使ってる人がほぼいないから話題がない。
2020/12/20(日) 08:09:16.60ID:vYm8Aryt
>>176
iOS app開発できるし
パッチもあてられるし
CPU次第でMacより速くできるし。
マルチブートするかMacOS専用PCにするかは自分次第だし。
Apple嫌いなのは同じだが違いは儲かるから俺はやる、それだけ
AndroidとiOSシェア同じなんだから捨てるのはもったいない
2020/12/20(日) 12:38:53.63ID:NmAfNXJq
>>178
iOSには800万社くらいがアプリを提供していて、その内の1%の会社で8割くらい
の売り上げを獲得し、残りの99%は、平均で年間売り上げは100万円位しか
ない。
2020/12/20(日) 12:39:56.25ID:NmAfNXJq
>>179
訂正：
800万社ではなく、75万社くらい。
2020/12/20(日) 13:24:08.95ID:XPZNArTY
ザマオンプレジジィが伸び伸びしてて草
終の棲家とするが良いｗ
182デフォルトの名無しさん
垢版 |
2020/12/20(日) 17:45:21.29ID:vYm8Aryt
>>179
アプリ内課金なのか何の数字なのか不明だが、
間接的にsp appで利益あげるパターンもある。
アプリ無料で広告もつけなくても稼ぐことができる

トップ層は大ヒットゲームだし
下はとりあえずつくってみたアプリだし
平均値はあまり意味はない。
2020/12/20(日) 20:08:45.15ID:Gd3F49It
177 名前:デフォルトの名無しさん :2020/12/20(日) 07:58:59.61 ID:vYm8Aryt
>>173-175
本スレってASP.NET知らない無能が立てたスタンドアロンスレのことか？
あそこも俺がネタふらないとすぐ過疎った。
Blazor使ってる人がほぼいないから話題がない。


爺さんさ、もしかして発達障害の診断受けたことある？

上に引用した爺さんのレスだが、実際のところは2つのblazorスレで無関係なオンプレミスとxamarinの話を永遠繰り返してただけじゃない？で、スレ違いだから止めろとスレ民からいくら言われても、決して止めなかった。…これって爺さんの中では適切な話題を振っているとの認識だからよな？

スレチだけでなく、こちらの質問に対して妙にズレた回答をしてくることも幾度となくあった。むしろ適切な回答が返ってくることの方が珍しいくらい。
要するにさ、全く会話が成立していない状態なんだよね。分かるかな？
現実社会でもそういう指摘受けたことないかい？どうだろう？
2020/12/21(月) 00:37:22.04ID:SJYr72qf
>>182
もう、スマホが出来てからかなり時間が経ってしまったので黎明期の
ように簡単なゲームやアプリでも飛ぶように売れるというような特殊期間
は過ぎてしまった。
ソフトウェアの需要も頭打ちになっており、そう簡単に儲かるものではない。
ゲームも売上高は高く見えても開発にも同等に人件費がかかっており
赤字ぎりぎりの事が多い。
2020/12/21(月) 01:12:36.38ID:KEVFN1Cr
>>183
もう構うなや
NGワードいくつか設定しとけば問題無いやろ
2020/12/21(月) 01:33:49.70ID:kC10DwQL
ここは雑談スレだから仕方ない
Blazor本スレならしょうもない雑談は徹底的に叩くけど
2020/12/21(月) 09:36:20.15ID:eMg5oWqT
>>184
儲かるマーケットで新規参入が増えるのは当たり前だしどうでもいい。
クオリティが高ければ人気がでて儲かる

ゲームの損益は上場企業なら公開されてる。
頭打ちでもない。巣ごもり需要で各社、好決算だ
2020/12/21(月) 09:40:40.18ID:eMg5oWqT
>>183
オンプレミスの話題は他の奴らが悪い
海外で脱クラウドの流れでてるのは事実だし
ある程度知識あるエンジニアなら当然のように気が付く。

事実に反発しているということは
オンプレミスで開発・運用できるスキルがないやつらってこと
否定しないと自分がスキルないのを認めることになるから奴らはしつこい
2020/12/21(月) 10:19:52.71ID:RgKh0kMO
脱クラウドの真偽はどうあれ、少なくともBlazor使ってるのなんてほぼ100%クラウドでしょう
ちょっとは周り見た方がいいよ
2020/12/21(月) 10:54:45.18ID:sgTwUHSK
>>188
極一部の企業がやり始めたってだけで全体に拡大解釈しちゃいかんよ
オンプレミス回帰と主張したいなら数字とグラフで示さなきゃ
それができないならただの戯言
2020/12/21(月) 12:29:08.06ID:vPyfCX7u
たのむからここではオンプレの話をするなよ
2020/12/21(月) 17:46:03.85ID:xeeueWnS
>>187
iOSのアプリは、メーカーが作ってればいいよ。
2020/12/21(月) 17:56:07.61ID:eMg5oWqT
>>189
Blazorだけの数字なんていみないし
そもそもBlazorのシェアがまだ1%すらない
ちょっとは現実みたほうがいいよ
2020/12/21(月) 17:58:48.02ID:eMg5oWqT
>>190
ほんとクラウド信者はしつこいな
スキルある企業、個人は
パブリッククラウドの料金体系見てすぐ除外する。
ほとんどの用途でオンプレミスよりコスト高になる。
わからないやつはその程度のレベルだししつこく反論してくるな
2020/12/21(月) 17:59:42.03ID:eMg5oWqT
>>191
心配しなくてもそのうち消える
俺にとってこの板は失うもののほうが圧倒的に多い
2020/12/21(月) 18:00:08.46ID:FwW9ovL+
雑談スレだとオンプレ爺さんも相手してもらえるんだなw
2020/12/21(月) 18:11:17.19ID:vPyfCX7u
あっちが本スレなんじゃよ爺さんも湧くからたまらんなあ
2020/12/21(月) 19:04:54.94ID:sgTwUHSK
>>194
そんなすぐに見切り付けられるんじゃクラウドは商売にならん
しかし現実の世界ではクラウドは大繁盛だ
みんなクラウドのほうが良いと判断してるわけだな
2020/12/21(月) 20:35:12.12ID:eMg5oWqT
>>198
しつこいな
どうせおまえは無能でオンプレミス対応できないんだから
気にしてもしょうがない
2020/12/21(月) 20:42:24.04ID:RgKh0kMO
俺はオンプレのサーバーに触れたことすらない無能だが、クラウドのお陰で一本稼いでる
オンプレのほうが安い可能性は否定しない(知らないから)けど、ぶっちゃけ全く興味ないわ
2020/12/21(月) 20:52:32.75ID:+ci58h/H
>>199
クラウドに対応できないんだね
わかってるよ
オンプレ仕事は減っていくだろうけど頑張ってね
2020/12/21(月) 21:08:17.13ID:vPyfCX7u
こんなところに書いてもあれだが雑談系スレッドならいいだろう。
オチは無い。

Qiitaや技術系ブログをみてると、Reactやらnode.jsやらJavaScript系の技術を使ってる俺たちは最先端だよねイケてるよねっていうのがすごく鼻につく。

その技術が苦手なこともあるはずなのに良い面ばかり書かれてて
そしてJavaやC#は馬鹿にされる。

おそらく若手はC#なんて古臭い言語やってられないですよ俺たちもTypeScriptヤりたいっすよ
って思ってるんだろうなあと。

いやいやnode.jsってン万件のCSVデータ取り込みとかに耐えれるのか？向き不向きがあるだろうと言いたいところだが
こればっかりは触ってみないと分からないんだよなあ。
そしてそんなことやってる暇がない。

BlazorServerなんて最強じゃんと思うんだが、若手はこんな潰しの効かなさそうな技術なんか学びたくないだろう。
俺が若手の頃にCOBOLなんてやってられないっすよと思ったように。

良し悪しとは別に技術には勢いというものがあって、勢いがあると沢山の知見が集約されてどんどん良くなっていく。
js系の技術やクラウドもそうなんだろうな。
2020/12/21(月) 23:50:58.97ID:ll9V3sqt
ン万件とか少な過ぎて笑える
2020/12/22(火) 09:37:44.93ID:yCNDLhUz
>>201
またでてきたか、低能のイキリが。
そんな簡単なことで自慢してくるから笑われる
オンプレミスやってるやつらで簡単な設定するだけの
クラウド使えない奴などいない
2020/12/22(火) 09:42:09.37ID:yCNDLhUz
>>202
ここ雑談スレじゃない。

Web系エンジニアのマウントには同意。
スクリプトしかできない無能なフロントエンドほどマウントとってくる。
バックエンドの知識ないからクラウドつかってるやつらなのに
クラウド使える俺たちすごい！みたいな奴らなｗ

コボラーに同意しちゃうとまた爺さんと誤解されるからやめとくか
2020/12/22(火) 09:46:21.52ID:8AraQvJr
ここは雑談スレで本スレはこっちな
【本命】Blazor スレ2【真打】
https://mevius.5ch.net/test/read.cgi/tech/1606028377/
2020/12/22(火) 09:47:06.91ID:yCNDLhUz
>>202
C#が古臭くてTSがやりたい？
そんなこといってるやつは無能すぎだろ

nodeは低速だしクソだよ
nodeのweb frameworkでまともなやつはない

JSがどんどん良くなっていくも嘘
触ってみりゃわかる
ゴミみたいなのが乱立してるだけってのがJSフロントの実態
2020/12/22(火) 10:03:50.70ID:QfeqeAq5
>>204
使えてないからオンプレのほうがいいなどと間違ったことを言い始める
使えてる人はクラウドを選ぶ
2020/12/22(火) 12:11:07.00ID:Vz3OkUO2
>>207
すまんがあなたの
クラウド貶してオンプレ推してるのに違和感を感じるので
そのnode、js貶してるのもいまいち信用できないんだよなあ
適材適所ってあるって思うんだよ。
何からなんでもクラウドはたしかにおかしい。
オンプレが必要なシーンはあるだろう。

同様に何からなんでもjsはクソ！もおかしい。
これではWeb系エンジニアのマウントと変わらない。
2020/12/22(火) 12:24:41.48ID:ejjmBy56
地頭が悪いジジイやから数十年携わってきたサーバー運用しか出来んねん
スレ民はもうちょい労ってあげてや
2020/12/22(火) 12:54:35.28ID:sMkHVlkY
>>209
>これではWeb系エンジニアのマウントと変わらない。

こういうのはオンプレ爺と同じでコンプレックス丸出しなのでやめた方がいいよ
それに今どきWeb使わないシステムやソフトウェアのほうが圧倒的少数派なので「Web系」って括りは意味がない
2020/12/22(火) 13:06:10.14ID:yCNDLhUz
>>209
信用できない？
ベンチマーク見てから言え
C#, Javaに比べて
node(JS)遅いし
Rubyは激遅い

能無しフロントのマウントと一緒にするな
俺は技術の優劣をみてクソと言っている
2020/12/22(火) 13:09:39.64ID:yCNDLhUz
>>210
外部業者に委託しないとバックエンドの開発も運用も
できないようなおまえのような無能と一緒にすんなハゲｗ

もしジジイならスキル範囲ひろくてめちゃ有能ジイイだな
おにいさんだけど
2020/12/22(火) 13:48:16.89ID:ejjmBy56
ジジイなんで毎度すぐレス返ってくるねん？
会社に相手してくれる人おらんで暇なんかな

しゃあない、おいちゃんが何でも話聞いたるわ！
これからは無理してITの話題振らんでもええさかい、ジジイの趣味話でも聞かせてや
2020/12/22(火) 13:52:25.55ID:ejjmBy56
あ、それから無理して草生やす必要ないで？
つい背伸びしてまうのはジジイの悪いトコロやな
2020/12/22(火) 14:30:43.23ID:Vz3OkUO2
>>212
文字速度、生産性全てにおいてASP.NET+C#が上回るならなぜみんな選択しないのか。
理由は必ずあるはず…！
小規模なシステムで使うには重量級すぎるとか？

それとも最初に覚えた言語が何かにもよるのだろうか。
js系言語から入ったらC#やJavaに手を出さないものなのか。
おれは機会があればjs系言語に手を出してみたい。

>>211
そう？会社もWeb系とSIer系で分けれるのかなとおもってるんだけど。
コンプレックスははっきり言ってめちゃくちゃある。
あいつらはなんであんなにキラキラとした目でjs系技術最高っスみたいなノリなんだちくしょうめ。
2020/12/22(火) 14:32:57.24ID:Vz3OkUO2
>>216
×文字速度
○速度
2020/12/22(火) 16:09:21.58ID:3BPmpE5D
>>213
零細勤めなのは知ってるけどどれくらいの規模のシステム作ったことあるの？
ロードバランサー要らないレベル？
2020/12/22(火) 16:42:02.20ID:QfeqeAq5
>>216
なぜ選択されないのかというとWEB系ウェーイの連中がスクリプト布教活動に熱心だからだよ
やつらがnode最高です、ruby最高ですとひたすら布教するので、引っかかったユーザーがどんどん増える
C#erは布教活動にはあまり熱心ではないね
自分らが有効に活用できればOKという考え方なので、ユーザーを増やすことには興味がない
もしかするとウェブ系ウェーイみたいに雑魚が流入してくるリスクを懸念してるのかも
2020/12/22(火) 20:12:23.02ID:lwpoOL3+
毎度すぐレス返してきてお前暇なんか？言うてジジイ煽ってみたら案の定何も書き込まなくなりおった
なんちゅう打たれ弱さや…チンケなプライドが足枷になってること理解しとるんか？
2020/12/22(火) 20:54:55.78ID:Vz3OkUO2
なんだこのエセ関西弁…このスレはなんでこうイロモノ揃いなのか

>>219
たしかにやつらは得た技術を発信することを良しとしてるよな。
Web系ならではのオープンな感じ。
SIerがやったら自社ノウハウを流出させたから減給とかなりそう。
それで情報が少ないから人気のない言語、フレームワークと捉えられるのは悲しいなあ。
2020/12/22(火) 21:14:00.98ID:QfeqeAq5
そもそもASP.NETの人気がないというのが嘘だろう
個人ブログ等の記者が主観で語ってるだけのいわゆる僕が考えたフレームワークランキングだと無視されがちだけど
ちゃんとした測定を元にランキングを出してるとこだとPHPの次ぐらいにASP.NETが入ってるものが多い
2020/12/22(火) 22:12:00.01ID:yCNDLhUz
>>221-222
ASP.NETはWeb Frameworkとしては1位だ
https://www.wappalyzer.com/technologies/web-frameworks/

>>220
無視されたことに気付かないバカ
224デフォルトの名無しさん
垢版 |
2020/12/22(火) 22:21:19.03ID:yCNDLhUz
>>223のURLはもっと知名度あっていい。

node.jsが人気ないのもわかるだろ
Expressもシェア落として6%になった。
Expressはフルスタックではなく貧弱なやつだからな
node系のフルスタックはゴミみたいなのしかない

web frameworkは迷わずASP.NETでいい。
C#できないちょい無能はLaravelかRails
ガチ無能はバックエンドさわってはいけない。事故の元
2020/12/22(火) 22:22:23.43ID:lwpoOL3+
ほらな、逃げた言うて煽ったらすぐ書き込みにきよる
何より笑えるのはわいが煽って以降、ジジイがレスに草生やさなくなったことやｗ

要するにな、オンプレジジイはいい歳して己が確立してない精神的未熟児なんやね
他人に抗うことしか行動原理が無い、それこそが唯一のアイデンティティ…なんとも悲しくて哀れで虚しい話やないか！？

……おいちゃんな、ほんまはジジイの力になりたいんや！真剣にそう思ってる
ジジイがクラウド本気で勉強するつもりならわいが一から手取り足取り教えたる、blazorに関してもジジイと違っておいちゃんはプロやから正しい使い方伝授したるよ？どや、ええ話やろ？
2020/12/22(火) 22:58:45.41ID:Vz3OkUO2
名探偵コナンの服部みたいな嘘くさい関西弁
2020/12/22(火) 23:57:17.69ID:lwpoOL3+
お前もおいちゃんと友だちになりたいんか…？
わいは全然構へんのやけどジジイが嫉妬してまうかもしれんからジジイの返答待ちやな

ほなまた明日
2020/12/23(水) 00:26:15.53ID:JHNEfXdY
こんなこと書いてても、昼間はBlazorWasmを自在に操って、洗練されたピザの販売サイトや天気の一覧が出てくる画面を作ってるんだろうなあ
2020/12/23(水) 01:54:16.30ID:Kc0L3Url
>>228
オンプレ爺さんは？
2020/12/23(水) 07:14:04.95ID:y+ivgknh
雑談スレらしく活気があってイイネ！
2020/12/23(水) 08:14:07.90ID:L0gYl8Ji
>>229
さあ…でもたぶんオンプレ爺さんは、己を育ててくれたBlazorに感謝しているのは間違い無いだろうから、
感謝のカウントアップをしてるんじゃね。
毎日一万回、カウントボタンをクリックし、スクショを取り、エクセルに貼り付けてる。
さすがにそこまでしないか。八千回かな。
2020/12/23(水) 08:25:24.23ID:5MtFrMbi
いい話だなァ（；＿；）
2020/12/23(水) 08:34:59.21ID:L0gYl8Ji
ついでに恥を偲んで聞くんだが、
よくWeb系の奴らが、型があるって素晴らしいですね♪的なことQiitaとかに書いてるけど
奴らが言う型って、もしかしてC#で言うところのクラスのこと？
2020/12/23(水) 08:43:14.91ID:iOQdV6uo
TypeScriptのことだよ
2020/12/23(水) 08:58:24.15ID:L0gYl8Ji
え、言語なのか…
2020/12/23(水) 10:03:58.22ID:h+qkHPqF
>>234
ts推しのひとのlevelはこの程度だｗ

>>235
言語のわけない。経験言語は？
2020/12/23(水) 12:04:39.47ID:L0gYl8Ji
>>236
し、C#の経験がありますっ
2020/12/23(水) 12:24:52.39ID:qFmqxSAt
C#やってて型が何かわからないってどゆこと？
C#ではclass, struct, enum, interface, delegate, arrayが型

型があるって素晴らしいですね♪的なのは見たことないけど
動的言語でも型がない言語は実質ないから
静的型チェックっていいですねくらいの意味じゃないのかな
239デフォルトの名無しさん
垢版 |
2020/12/23(水) 12:28:36.82ID:h+qkHPqF
これはひどい
>>236 で回答しちゃいそうになったが
C#やってて型もわからないような人が>>231のように煽ってたわけだ。
型わからないのにC#使えるわけないんだがね

これでまたはっきりしちゃったな
初心者がオンプレミスおにいさんのスキルに嫉妬して叩きまくってたということが
2020/12/23(水) 12:33:43.74ID:J8E3P1ZQ
>>239
TypeScriptは言語ですよ？
2020/12/23(水) 12:41:43.57ID:h+qkHPqF
>>240
そういう話じゃない
>>234のレスがずれまくってるということ
TSは型のある言語のひとつだが233返答として不適切ということ。

まあ質問者が煽ってたカスだったから答えはもう不要だけどね
2020/12/23(水) 12:53:44.25ID:L0gYl8Ji
>>238
いや型が何かはわかってる
js系やってる人達のいう型と同じなのかなという、煽りではなく素朴な疑問

ただjsだって文字型、数値型はあるだろうから複合型のこと言ってるのだろうか。
243デフォルトの名無しさん
垢版 |
2020/12/23(水) 13:26:24.61ID:4FZ7yNJk
文脈的にTypeScriptでも合ってるような気がする。
2020/12/23(水) 14:06:10.99ID:Kc0L3Url
文脈的にはTypeScriptはすばらしいということだね
2020/12/23(水) 14:12:41.92ID:aoAgDZ6q
>>242
変数が定義時に型を結び付けられていて、途中で別の型の値を代入すると
コンパイル段階でエラーにしてくれることを
「型があるって素晴らしい」
と言っているのだろう。例えば、C++では
int a = 5;
とした場合、aに文字列や浮動小数点値やクラスオブジェクトは代入できない。
auto a = 5;
としても、autoがintのように解釈されてaがint型の変数になるだけで
aに文字列や浮動小数点値やクラスオブジェクトは代入できない。
ところが、JSだと、
let a = 5;
とすると、aには文字列でも浮動小数点値でもオブジェクトでも何でも
代入できてしまう。
これがバグの原因になりやすいから。
2020/12/23(水) 14:17:08.23ID:O5AY10nM
typescriptは厳密すぎるとは思うけどね
もうちょっと緩くする的な議論もあると聞く
247デフォルトの名無しさん
垢版 |
2020/12/23(水) 14:45:16.52ID:4FZ7yNJk
ウェブ系で型があるって素晴らしいってことは、型が無い世界に居たって事で。

Javascriptつこてて、TypeScriptに出会った感が強い。
2020/12/23(水) 15:20:49.21ID:qFmqxSAt
>>242
それはC#における型はわかってても
言語に依存しない型という概念を理解してないってことだったりしない？

JS使ってる人たちが言う型とC#の型に違いがあるかというと違いはない
型の種類や適用されるルールに違いがあるだけで型という概念は同じ
2020/12/23(水) 18:02:10.45ID:L0gYl8Ji
>>245
>>248
ありがとう
jsにもプリミティブ型はあるけど、コンパイラによる型チェックがなかったってことかな。

逆に型チェックなしでよく頑張ってこれたな…
数値計算とかブラウザ上でやることがないから問題なかったのかな。
2020/12/23(水) 18:45:31.75ID:aoAgDZ6q
>>249
[追加]
JSの場合、オブジェクトは、
let a = {
　age : 12;
};
として作製するが、ageを書き間違えて
a.aga = 13;
などとすると、何のエラーも出ず、aga という新しいプロパティーが
追加されてしまう。その結果、
a.age と a.aga の二つのメンバが出来、
a = {
　age : 12;
　aga : 13;
}
としたような状態になってしまう。
JSに限らず多くのスクリプト言語は同様の現象がおき、ミスに対する
フェイルセイフが出来ておらず非常に危険なので、大規模開発に
向いていないと言われている。
2020/12/23(水) 18:52:45.56ID:qnDToIG0
それ型と直接関係なくね？
確かにtsだとそれを防ぐ型とか作れるけども…
2020/12/23(水) 19:09:45.60ID:aa3pY4zz
なぜ型と関係ないと思うwww
2020/12/23(水) 19:26:43.15ID:L0gYl8Ji
>>250
全部dynamic型！みたいな言語だな。
こんなの自分一人でもだめだわ。破綻するわ。
これの利点ってなんなんだろ…

あとよくサーバーとフロントで型を共有できて嬉しいですよね♪みたいなこと書いてるブログもみるんだが
それができてない場合ってこうなる？
サーバー側:sexはなんか卑猥だからgenderにしたれ！
フロント側:sexに何も挿入されない…
2020/12/23(水) 21:34:43.30ID:qFmqxSAt
>>250
それはDictionaryに新しいkey/valueペアを追加してるのと同じだからね
そういうのでバグ出しちゃうのは基本的にテスト書かない人

チーム開発で動的言語使ってまともなプログラムを作るためには
静的言語の場合よりも高い技術スキルとコミュニケーション能力が求められる
なのでソフトウェアの規模というよりチームの規模が大きくなればなるほど不利
2020/12/23(水) 21:52:55.12ID:O5AY10nM
無能爺が出しゃ張らないだけで、雑談スレでもここまで建設的なスレになるんだね
2020/12/23(水) 21:53:23.50ID:qFmqxSAt
>>253
サーバーとクライアントで違う言語を使ってても
swaggerとかでインターフェース定義してそれぞれコード生成すればいい
C#でも同じだと思うんだけど？

逆に同じ言語を使ってるからといってやり取りするデータを定義した
クラスライブラリを共有するのはアーキテクチャ的にはかなり微妙
特に外部に公開するようなサービスでは
2020/12/23(水) 22:03:15.12ID:92W7nQMG
>>254
これだけのことにテスト書くの？テストまみれにならないか？
そもそもコンパイラがチェックしてくれるようなこおを自力でテスト書くとか苦行すぎるだろ…
それって高い技術力と言っていいのだろうか。
言語、フレームワークの選定を間違えているとおもう。

>>256
Blazorのプロジェクトつくるとそうなってるよね
あれは規模が小さいシステムなら許容されるんだろうか。
2020/12/23(水) 22:27:01.33ID:92W7nQMG
>>256
連投すまん

そのswaggerはサーバー側の型に変更があったらクライアント側で気づくことができるんだろうか。
blazorのプロジェクトの構成ならコンパイラが教えてくれるよね。

外部に公開しないシステムで二回型定義するのは、ツールに頼ったとしてもめんどくさいとおもってしまうんですよ
2020/12/24(木) 00:11:53.93ID:61P3AxB9
>>258
swaggerの意味間違えてるよ。
それswaggerの役割じゃないから。
2020/12/24(木) 00:38:15.61ID:cDdTcWWQ
Unityがなんで勝ったか、を考えれば答えは見えてるだろ
2020/12/24(木) 00:59:13.90ID:z4h3nURn
>>257
>Blazorのプロジェクトつくるとそうなってるよね

なるほど、前提として想定してるアーキテクチャが全然違ったのね
>>256の話はBlazorのプロジェクトが別のバックエンドのAPIサーバーにアクセスする必要があるようなケースに
APIサーバーがで定義された型をクラスライブラリとしてBlazorのプロジェクトと共有するかどうかみたいな話ね

Blazorはモノリシックなアプリでいい場合は簡単に作れていいと思うよ
考え方的にはRailsとかと同じだけど裏のところが独自技術な分だけ優れてる
悪い点はロックインされるところ
2020/12/24(木) 01:05:39.49ID:cu9CRgEK
最近はミクロサービスもやっぱ駄目だったってんでモノリスに回帰してきてるらしいな
2020/12/24(木) 06:31:15.50ID:qBLsz+9E
Docker は、1コンテナに、1アプリのマイクロサービス

今の基幹技術だろw
流行りまくっている
264デフォルトの名無しさん
垢版 |
2020/12/24(木) 08:12:52.16ID:Lxgk3nTO
>>263
またにわかのフロントエンドのバカか
流行っているかではなく優れているかで選ばなくてはいけない
大規模やってる大手企業、上級エンジニアはDockerを嫌う
2020/12/24(木) 08:34:44.70ID:tvAmDhsP
>>261
すまん前提が書けてなかった。
うちは企業内アプリをメインに作ってて、他の外部apiには殆どアクセスしない。
バックもフロントも自チーム内で完結する。

横に座ってる奴がサーバー側の型を変更して急用ができて帰ったとする
フロントやってるやつがそのことに気づかずにリリースしてしまうなんてことが起こるようなら本末転倒だなと。

それで原因はテストコードが足りないとか、コミュニケーションが足りないとかいうのもおかしいよねと考えている。
Blazorのプロジェクト構成ならビルド時に気づくよね。

swaggerを使うことで、フロント側がすぐに型変更を検知できるような仕組みがあるんならいいんだけど、気づかないよね？困るよね？現にお困りではないでしょうか？
と聞きたかった。
266263
垢版 |
2020/12/24(木) 08:39:38.18ID:qBLsz+9E
AWS の構成図を見てみろ。
ほとんど、マイクロサービスだろ

何十もの、Lambda, SQS(Queue), SNS(通知)をつなげてるの、ばっかりだろ

クラスメソッドの動画を見ろ

会社全体で、AWS の資格を800持っていて、
全12資格を持つ・ジェダイマスターが7人もいる！
2020/12/24(木) 08:40:41.97ID:BsodnxpD
>>264
零細爺が見栄張って適当言っちゃあかんでしょ
社内でファイルサーバーでもたててSEごっこしてなさい
2020/12/24(木) 08:53:01.08ID:Lxgk3nTO
>>266
そりゃアマゾンは大手のクラウド事業者だからあたりまえだろ
自社の提供するサービスをそのまま使ってるだけ
サービスの広告にもなる

一般法人がそれを採用することが合理的かは別の話だ。
デメリットを理解せず、流行ってるからいいという
アホな価値観だからそういう思考になる
2020/12/24(木) 08:58:23.93ID:nIBEXBhK
こいつはホンマにいつも5chやっとるな
270デフォルトの名無しさん
垢版 |
2020/12/24(木) 09:04:12.11ID:Lxgk3nTO
>>266
おまえいつもKENTAの話ばっかりしてるやつだろｗ
クラスメソッドｗ
俺は初心者向けスクールなんていかない。

会社全体の資格者数なんて何の意味もないし
ベンダー資格なんてすぐに取れるんだよｗ
スクールだから宣伝のために講師に取らせてることも理解できないって
頭悪すぎだぞ
スクールの講師に優秀なエンジニアいないぞ
簡単にとれる資格でだまされてるやつｗ
KENTAとかスクールとか情弱ビジネスに釣られすぎ
271263
垢版 |
2020/12/24(木) 09:33:54.56ID:qBLsz+9E
クラスメソッドは、AWS パートナー・オブ・ザ・イヤーとか取ってる、最上位の会社

米国年収で、
Ruby on Rails 1,300万円
Node.js 900万

VMware 1,400万
AWS Solution Architect 1,500万

もう、AWS資格が、Railsを超えてる！
2020/12/24(木) 09:52:41.32ID:tvAmDhsP
ついでに聞いとこ。
クラスメソッドくんは普段なんのフレームワークで開発してるんだい？
2020/12/24(木) 10:54:27.41ID:cDdTcWWQ
>>266
その構成が複雑化しすぎて多くの場合でデメリットがメリットを上回ってしまう
よっぽど巨大で複雑なシステムでもない限りモノリスのほうがシンプルでイイネ
っていうふうにトレンドが移り変わろうとしてるところ
274デフォルトの名無しさん
垢版 |
2020/12/24(木) 11:28:27.57ID:TzdYJrci
KENTAはコテ付けるべきでは？
2020/12/24(木) 12:08:12.79ID:tvAmDhsP
>>273
これほんとにそうだと思う。

こういうのが必要なのって相当巨大なシステムだけなんじゃないのか
トレンドだからとDockerだか、Kubernetesだかに手を出して
気づかず消耗してるんじゃないだろうか。

クリーンアーキテクチャについてもそうおもうし、
なんならrest apiもそうなんじゃないだろうかと疑っている。
rpcでよかったのにrestにしちゃったケースもあると思うんだよなあ
2020/12/24(木) 12:24:48.60ID:61P3AxB9
>>265
サーバー側の型が
クライアント側に漏れでた時点で
設計がおかしい。

もしかして、
クラサバみたいな設計ですか？
2020/12/24(木) 12:37:13.88ID:tvAmDhsP
>>276
漏れ出るって…？
ASP.NET MVCは定義したモデルをビューで参照できるよね？
これは漏れ出てる…？
2020/12/24(木) 13:32:36.53ID:FJvlKwaS
>>275
Dockerは別にいいと思う
あれはどんな依存関係でも簡単にパッケージできるのと環境を汚さないで済むという強力なメリットがある
K8Sまで行くとやりすぎで本当にK8Sが必要なのか慎重に考えないといけない

クリーンアーキテクチャは悪くない
モノリスに回帰してきているとは言ってもコードを汚く書いていいわけじゃない
あくまでも悪いのはミクロサービスであってアプリケーション内部をクリーンアーキテクチャで綺麗に構造化するのは依然として良いことだ

RPCはそのとおり
APIだけじゃぜんぜん駄目だったのでgRPCなどが普及し始めた
DDDの文脈で綺麗にシステムを作ろうとするとAPIよりRPCが肝要となる
2020/12/24(木) 13:35:03.72ID:61P3AxB9
>>277
サービスレベルで設計してないって事ね。
2020/12/24(木) 13:56:01.24ID:RIrJysKy
単純なマスタメンテみたいなアプリでもなけりゃサーバーとクライアントで扱うモデルって一致しなくない？
セキュリティとかプライバシーに関わるようなデータでも平気でネットワークに流しちゃう感じ？
2020/12/24(木) 14:00:28.72ID:VTM9inIm
ドットネッターはコンテナに拒否反応示す人が多いよね
.NET Coreでせっかくモダンなスタイルのデプロイが可能になったと思ったら、
井の中の蛙なユーザーに迎合してIIS統合とかFDD強化とか変なことに力入れてどんどん退行してるし
2020/12/24(木) 15:31:58.25ID:GGlRJfww
Windowsコンテナが実用レベルになったら起こしてくれ
2020/12/24(木) 17:59:56.32ID:tvAmDhsP
>>279
そこまでやる必要がないレベルといえばそう。
世にあるMVC系のWebフレームワークはなんか漏れ出してるということなんだろうか

>>280
逆に単純なマスタは一致するんじゃないの
そりゃおっしゃるようなシーンでは一致しないだろうけど
どっちが多いかにもよるんだろうか。

サーバーと型が共有できるって利点だと思っていたけど
結構反対意見も多いな。
少なくともBlazorの雛形はそうなっているけど、これは小規模だから成り立っている？
もっといろんな意見を聞きたい。
2020/12/24(木) 18:17:21.72ID:61P3AxB9
>>283
反対意見じゃなくてAPIの設計がちがう。

swaggerでopenAPIとして公開するレベルなら、
クライアントの種別、言語は問わない。
2020/12/24(木) 18:32:45.65ID:z4h3nURn
>>265
それってコンパイルエラーになるような変更なら気がつくけど
それ以外の変更なら不具合が起こってても気が付かないてことでしょ？
結局テスト書いてないだけじゃない？

swaggerとかインターフェース定義ファイルからそれぞれのスタブを自動生成するようなやつは
定義が変わればそりゃ検知できるけど検知できて新しい定義に対応したところで
その変更によって不具合が起こってないことはテストしないとわからないよね
2020/12/24(木) 18:36:25.33ID:cDdTcWWQ
>>280
モデルにも色々ある
ドメインモデルとかビューモデルは当然、共有しない

APIやRPCのI/Oモデルは共有する
Blazorはこれを追加作業なしで完全な形で型安全に共有できるから強い
2020/12/24(木) 18:46:02.72ID:PofLudrU
さらにF#の型プロバイダをBlazorで利用すると、バックエンドが.NETでない場合でも、型安全なI/Oモデルを手に入れることができる
インターフェース定義、コード生成要らないので、とても楽ちん
2020/12/24(木) 18:53:41.80ID:tvAmDhsP
>>284
いろんなデバイスやシステムからアクセスするapiに関してはおっしゃる通りだと思うよ。
でもそんなの限られるんじゃないの？いや俺がそういうの作った事ないからそう思い込んでるだけかもしれないけど。

そうじゃないものまでapi化するのは意味なくて、型は共有した方が嬉しいですよね♪ってことだと解釈してます。

>>285
swaggerはリリース前に自動で変更検知して止めてくれるってこと？
なら安心だな。
テストに関してはおっしゃる通り。
2020/12/24(木) 19:15:50.43ID:EoOpc5fU
>>283
型共有は工数削減効果が非常に高いので積極的に利用して良いよ
2020/12/24(木) 19:26:12.20ID:yLXHVLdF
swaggerがどうのこうの言ってる人はミスリードを狙ってそうな気配がする
swaggerはメソッドを定義することはできないからblazorの型共有とはそもそもまったくの別物だよ
2020/12/24(木) 19:34:01.95ID:yLXHVLdF
blazorの型共有は単にAPIのDTOを共有するといったつまらないユースケース留まらない(もちろんDTOとしても非常に便利ではあるが)

例えば単価、税率、個数から消費税込み価格を計算するメソッドがプレゼンテーション層とドメイン層の両方で必要になった場合
blazorならC#で1回だけメソッドを実装すればいい
バックエンドとフロントが異なる言語だと同じ処理を異なる言語で2回実装しなければならない
もちろん仕様変更が発生した場合には両方ともプログラムを修正、テストをしなければならない
テスト定義もバックエンドの言語とフロントエンドの言語で2回書かなければならない
片方の仕様変更を忘れてもテストが更新されなければアラートは鳴らないので
慎重に2つの言語を調べ尽くして実装漏れがないかどうか確認しなければならない
2020/12/24(木) 20:36:59.38ID:NdJ7CDDg
画面の金額と実際の請求金額に差異が出たりしたら偉い人が顧客に土下座するレベルの重大事故だろ
さすがにそこはサーバーサイドに投げるわ
コード共有などという小手先レベルの共通化は少々バグっても笑って許される程度の機能のちょっとしたUX改善程度にとどめておくべきで、
重要なものはアーキテクチャ上差異が発生しないように作る
2020/12/24(木) 20:48:02.28ID:yJIcrLfM
>>292
この例はあくまで一例
実際のシステムでは金額計算以外にも同じような状況は沢山ある
それをいちいち全部バックエンドに問い合わせるのは実行効率も製造効率も悪い
2020/12/24(木) 20:58:24.94ID:KjzzoxRm
>>291
コピペ？

swaggerを使ってのopenAPIなら
まずはその設計思想を勉強されてみてはどうでしょうか？

googleのAPIとか参考になりますし、
無料で試せますよ。
2020/12/24(木) 21:06:28.06ID:cW3QBX++
>>292
自分の設計だとバリデーション含めて
ロジックは全部（表示フォーマットも）サービス側ですね。
ローカルにあるロジックと応答速度で遜色ないですよ。

サービス側は全部単体テスト対象なんで
安心感もあります。

リリース後にバグ出すと、
なんで単体テストを通過したのか始末書もんです。
2020/12/24(木) 21:23:01.51ID:IhbSA9yU
>>295
思想としては正しいと思う
.NETな人って表面的なコードの共有は大好きなのにデプロイメントをDRYにするという意識が希薄な人が多くて、
ビジネスロジックのDLLをWebとバッチで安易に共通化したりしてデプロイをミスってトラブル起こすケースが多いんだよね
2020/12/24(木) 21:32:29.46ID:cW3QBX++
View側に業務ロジック混ざると、
コードが読めなくなること多いですからね。
いろんな人が出入りするし。

フロントなんて持って数年、
システムの統廃合やリプレース時にも楽ですよ。
298デフォルトの名無しさん
垢版 |
2020/12/24(木) 21:48:16.63ID:BMlK5S4S
Blazor Serverでファイルのアップロード処理をしたいのですが、
アップロード時に、ローカルにファイルが存在するかチェックするにはどうすればよいでしょうか？
2020/12/24(木) 21:51:51.36ID:zHK1POmy
>>298
ローカル側の処理なんでJavaScript書かないと仕方ないんじゃないの
2020/12/24(木) 21:59:31.17ID:BMlK5S4S
>>299
ありがとうございます。
該当部分はJavaScirptで作ります。
2020/12/24(木) 22:00:26.68ID:cDdTcWWQ
>>294
swaggerはblazorの型共有とは違うベクトルの話だよ
ここで話すべき内容ではない
2020/12/24(木) 22:05:56.79ID:cDdTcWWQ
>>295
それはいままで簡単にフロントエンドとバックエンドでロジックを共有できなかったからそうするしかなかっただけ
型共有がなかったからコードを重複させるか些細なことでもバックエンドにリクエストを出すしかなかった
どちらもやりたいことにたいして実装と実行のオーバーヘッドが大きい
型共有が可能なblazorでは無駄なエンドポイント実装、APIコール実装を削減することにより生産性の向上が期待できる
また無駄なラウンドトリップを避けることによりより良いユーザー体験が期待できる
2020/12/24(木) 22:08:01.69ID:cDdTcWWQ
>>296
昨今ではデプロイメントは自動化されるので間違えることはない
2020/12/24(木) 22:09:26.12ID:cDdTcWWQ
>>297
Viewには業務ロジックは混ざらない
Viewからは業務ロジックを呼び出すだけ
今まではAPIを通じてリモート呼び出ししていたがblazorではその必要なく呼び出せる
2020/12/24(木) 22:25:28.29ID:Lxgk3nTO
>>304 >>302
「Blazorでは」と書くと正しく伝わらない。
Blazor ServerとBlazor WebAssemblyで全然違う
紛らわしい名前つけたMSが悪いんだが。
306デフォルトの名無しさん
垢版 |
2020/12/24(木) 22:50:48.81ID:cFK/Qw2G
実際どちらのことを書いてるんだろう
Serverかな
しかしwasmとserverでほんと全然ものが違うよな。
共通点はフロントをc#でかけるってだけで。

MSの名前の付け方は本当に適当だと思う。
2020/12/24(木) 22:59:35.56ID:z4h3nURn
同一言語で作ってる同一プロジェクト内で型を参照することを
”型共有”って言うのは相当違和感あるね

誰が使い始めたのかしらないけど
2020/12/24(木) 23:11:34.69ID:F9/YVp9N
では何と言うべきか？
2020/12/24(木) 23:24:38.23ID:cFK/Qw2G
Qiita や個人のブログを貼るのはアレなので
クラスメソッドの記事を…

https://dev.classmethod.jp/articles/typescript-front-server/

interfaceを共有することで 型安全な開発ができます

これのことかな。
2020/12/24(木) 23:50:47.46ID:cDdTcWWQ
Blazorはinterfaceの共有もできるがそれだけに限らない
interface、class、struct、、、何でも共有できる
それらを総称するとなんと言うか？それは型だ
だから型を共有していると言うより適切な表現はないのではないかな
2020/12/25(金) 00:08:08.33ID:vv0pxJyE
>>309
このケースはリポジトリとして定義した型をサーバーとクライアントで共有してるというのは違和感ないな
RESTのAPIで切り離されてるからかな
(APIが返す型情報を元にしてないから微妙なところがあるけど)

ASP.NET MVCで言えば同じビューモデルの定義を参照してるからって
ビューとコントローラーで”型共有”してるとは普通言わないよね？
2020/12/25(金) 00:14:35.63ID:K5aqSQYy
>>311
言い回しとして普及してるかどうかは知らんが型を共有してるのは正しい
2020/12/25(金) 00:24:51.99ID:Z26lwPgE
>>311
Blazor wasmのプロジェクト構成では
Shareプロジェクトにモデルを定義して
ClientプロジェクトのRazorページでShareプロジェクトを参照している
同じくServerプロジェクトのコントローラーでもShareプロジェクトを参照している
これはなんていうんだろう。

どちらにせよサーバーとクライアントで同じ型を使うという目的に対して手段が違うだけであって、別にまずくはないと思うんだけどどうだろう。
2020/12/25(金) 08:42:56.78ID:uurLZNKt
サーバーとフロントで型を共有？できた方が大半はうれしい。
OpanAPIが必要なシステムではそこに固執しなくてもよいということで。

じゃあこの板でもたまにやたらと推してくる奴がいる言語、rubyやpythonって静的型付け言語じゃないよね。
てことは型の共有もくそもないと。

そういう言語で中規模以上のWebシステムを作ろうとするとやはり苦労する？
推してくるやつはその事実をわかっていない？
静的型付け言語しかしらない俺にとってはなんであんな推してくるのかとても気になる。
2020/12/25(金) 09:13:17.07ID:JfQSa+1c
>>314
OpenAPIじゃメソッド(処理)を共有できないよ
フロントエンドとバックエンドで言語を揃えることにより今まで複数言語で書くかリモート実行するしかなかった問題が解決した
OpenAPIは複数言語で書く手間を軽減できるがリモート実行するしかないという問題には未だに無力
2020/12/25(金) 09:31:31.83ID:UA1/tVeu
どんな言語であれフレームワークであれ
データ型は共有しないとクライアントが受け取ったデータを適切に処理できないでしょ

blazor は同じアセンブリを共有できる分開発は楽になるでしょ

クライアントに送るデータはクライアントに必要なデータしか普通は送らないし
サーバ側の型がクライアントに漏れるとか
入門書レベルの開発しかしたことないだろ
2020/12/25(金) 09:44:37.32ID:uurLZNKt
>>315
多種多様なシステムやデバイスが使うapiは仕方がないという認識
2020/12/25(金) 10:04:08.77ID:JfQSa+1c
>>317
その多種多様なデバイスの上で.NETが動くわけで
2020/12/25(金) 10:09:58.28ID:8j4BK9K7
ぜんぶ設計者次第だという認識
2020/12/25(金) 10:16:11.17ID:81Ut/TdK
>>314
WebなんてぶっちゃけDBと画面の間のマッピングを定義してるだけの話なので、
データモデルがRDBによって常に静的に型付けされているため動的型でも破綻しにくい
むしろ変にドメイン駆動とか意識高いのに毒されて画面から独立したモノリシックなビジネスロジック層みたいなのができちゃうと、動的型では確実に破綻する
2020/12/25(金) 10:17:04.89ID:JfQSa+1c
>>316
サーバー側の型がなにを指しているのかによるな
データアクセスレイヤのクラスがプレゼンテーションに漏れるのはBADだと思う
しかしドメインレイヤのクラスをプレゼンテーションから参照するのは問題ないと考えている

昨日も例を出したけど
入力として単価、消費税率、個数があってリアルタイムに税込み価格を表示する画面があったとする
この税込み価格の計算は明らかにドメインロジックだ
プレゼンテーションレイヤから直接ドメインレイヤを参照できればそれが最もシンプルでよろしい

もしそれができない場合、プレゼンテーションレイヤにも税込み価格計算ロジックを実装するかリモート呼び出しのためのエンドポイントを実装し、APIクライアントも実装するという重い作業を強いられる

もちろん、税込み価格計算はただの一例であり、実際にはより多くのニーズがある
プレゼンテーションレイヤからドメインレイヤの型を参照できると低コストでより高度な画面を作成することができる
2020/12/25(金) 10:22:24.07ID:JfQSa+1c
>>320
それはどうかな？
意識の高いプログラマの代表格であるマーチンファウラー先生はrubyを称賛していたね
ドメインを実装するのに必ずしも静的でなければならなということはなさそうだ
重要なのはテストを書くことなのだろう
2020/12/25(金) 10:27:26.49ID:JfQSa+1c
そもそもWEBをひとくくりに画面とDBのマッピングであると決めつけるのもいかがなものか
チュートリアルみたいな簡単な仕事ならそれでもいいのかもしれないが
現実のビジネスは小さな事業でもそんなに簡単にはいかない
2020/12/25(金) 10:32:50.39ID:vv0pxJyE
>>314
自分で勉強しろって
ここで言ってる”型共有”はRubyでもPythonでもできてる

>>315
“メソッドを共有”って何なの？
処理を共有するためのAPIなんだけど・・・
それにBlazorもリモート実行してるよ
2020/12/25(金) 10:35:51.93ID:uurLZNKt
>>322
C#であればコンパイラが型チェックしてくれるようなことすらも
Rubyは自力でテストを書かなければならない？
しんどくない？しんどくてもその分の見返りがRubyにはある？

いや数画面のスキャフォールドで作られたようなCRUDシステムなら好きな方選んだらいいと思うんだけど
中規模以上になってくるとどうなのかなと思って。
2020/12/25(金) 10:38:07.26ID:uurLZNKt
>>324
あれ、RubyやPythonも型があるのか
失礼しました。
もう自分で触ってみないとわからんな…
2020/12/25(金) 10:38:47.43ID:UA1/tVeu
>>321
そんなこといったら
クライアント側でのデータ検証なんて　何もできない
2020/12/25(金) 11:01:46.48ID:bbGDaeBs
静的型チェックを重視するならC#よりF#使えばいいのに
2020/12/25(金) 11:08:03.54ID:8j4BK9K7
訳わかんない理論がまかり通るスレ
2020/12/25(金) 11:37:26.72ID:JfQSa+1c
>>324
リモート実行は外部処理系に処理を依頼しているだけなので共有ではない

ここでいうメソッドの共有とは異なる処理系が同じ実行コードをそれぞれの内部に持っているということ
2020/12/25(金) 11:45:17.08ID:JfQSa+1c
>>325
動的言語はしんどいよ
自分個人としては動的言語には懐疑的
ただ高度なスキルを持った著名人が支持しているのでコード解析の弱体化のデメリット以上に何かしらメリットがあるのだろう
そしてそういった著名人は必ずテストも推奨している
テストを書かない場合は静的言語のほうが有利なのだろう
しかしテスト書けば動的言語の弱点が補われるのでメリットのウェイトが大きくなる
2020/12/25(金) 11:49:27.10ID:JfQSa+1c
>>327
何もできないというのは間違い
しっかりしたシステムでは必ずクライアント側でもデータ検証を行っている

ただしそれはコード重複や無駄なリモート呼び出しの実装という負債を抱え込むデメリットと常にセット

フロントエンドとバックエンドで言語を揃えれば負債なしにフロントエンドでデータ検証を行うことができる

もちろんデータ検証以外の処理もおなじこと
2020/12/25(金) 12:16:12.84ID:uurLZNKt
>>331
そう。その何かしらのメリットを知りたいのだ…

>>245
>>250
はjavascriptの例だが、これがrubyでも起こるとすると
しょーもないCRUDの画面でもテスト書かないといけないのだろうか。

javascript勢がTypeScriptに流れてるってことは
それなりの規模のあぷりを動的型付け言語でやろうとするといくらテスト書いても辛いって事だと思うんだけど。
2020/12/25(金) 12:24:33.08ID:cyV6b5qO
それをここで聞いてもな…
親の仇の如く口汚く罵られるだけで、
メリットなんか提示されないと思うぞ
2020/12/25(金) 12:30:41.85ID:uurLZNKt
だよね…
技術の優劣をつける意図はないんだが、
自分が作るシステムでは正しい技術を選択したいという想い
2020/12/25(金) 12:31:52.62ID:fU2xV1RD
>>321
明日もお願いします。
2020/12/25(金) 12:32:11.57ID:uurLZNKt
Webフレームワーク比較検討スレみたいなのがほしい
js系の言語のスレはBlazorの話するとうざがられるし
2020/12/25(金) 12:37:05.82ID:JfQSa+1c
>>333
動的言語はコード編集から動作確認、テスト実行開始までがとにかく早い
なのでゼロベースの新規プロジェクト、サービス公開までの時間を最優先する場合にはデメリットよりメリットが上回る
339デフォルトの名無しさん
垢版 |
2020/12/25(金) 13:33:23.39ID:pgbI6Wzr
>>337
人気のweb frameworkのスレッドは個別にあるしそこでいい。
全部の言語まとめて扱うと荒れる。
ＪSやJavaのスレッドはある
Java Web Application Framework総合　ver2
http://mevius.5ch.net/test/read.cgi/tech/1374399677/

C#は乱立してないから素直にASP.NET使えばいい
5chみたいな狭い世界で比較検討せずに
素直に人気のあるやつをいくつか試して決めた方がいい。
2020/12/25(金) 13:37:24.42ID:pgbI6Wzr
>>337
うざがられてあたりまえ
JSやってるやつらのほとんどがC#を使えない

C#使えるならバックエンドは迷わなくていいASP.NETでいい
迷うならフロントまわりの技術
2020/12/25(金) 13:55:33.58ID:8j4BK9K7
自演ぽいな
2020/12/25(金) 14:03:41.81ID:l1B2LBGM
そろそろ学習本が欲しいところ
アレ以外で
2020/12/25(金) 14:22:22.25ID:vv0pxJyE
>>330
じゃ、Blazor Serverはリモート実行だから”メソッド共有”じゃないってことね

異なるプログラムで共通のライブラリを使うことを
”メソッド共有”って呼んでもなかなか通じないと思うよ
2020/12/25(金) 14:24:09.99ID:JfQSa+1c
>>343
ではなんと言ったらわかりやすい？
2020/12/25(金) 17:26:45.87ID:UA1/tVeu
共通するコードをライブラリ化して共有でいいんじゃないの
2020/12/25(金) 17:48:04.91ID:tkA/KKSW
バッと来て
グッと溜めて
ブワッ！
2020/12/25(金) 18:29:51.37ID:AIeBZh27
>>345
長いので1単語にまとめて
2020/12/25(金) 19:21:45.07ID:uurLZNKt
>>340
そうなんだろうか
実はC#erが食わず嫌いなだけで、実はあちらのほうがめちゃくちゃいいものなのかもしれないよ…？
2020/12/25(金) 19:30:34.79ID:UA1/tVeu
以前は asp.net は Windows Server でしか動かなかったからなぁ

今でこそようやく Linux でもまよもに動くようになって2年ぐらい？

twitter でも .net core で検索すると
一年前はほんと大して結果なかった気がするけど
最近は増えてきてるかな

まだまだこれからでしょ
350デフォルトの名無しさん
垢版 |
2020/12/25(金) 20:54:05.41ID:pgbI6Wzr
>>348
あちらのほうってなんだよ
エンジニアならもっとはっきりかけよ

JSのbackendのweb frameworkか？
ろくなのないって俺が何度も書いてる。試す価値なし。
疑うなら自分で試してベンチマークとかとれよ
RailsもNode backendも遅くてゴミ

スクリプトは遅い。開発の生産性が低い
これは開発者の常識
高速なハードとソフトを合わせないとスケールするサイトにできない
2020/12/25(金) 20:56:57.60ID:pgbI6Wzr
>>349
昔はLinuxでというかライセンス無料で使えなかったのは大きいね。
JSやってるやつらはいまだにIIS, Windowsでしか動かないと思ってる。
あとclassic ASP時代のイメージのままの人も多い
2020/12/25(金) 21:08:02.22ID:pgbI6Wzr
高速なコードで作りたかったらstaticに限る。
主要OSの主要な言語はstaticだ

Swift, Kotlin, Java

server-sideでKotlinもあり。
2020/12/25(金) 23:41:23.33ID:Z26lwPgE
サーバーとクライアントは同じ言語の方がいいんだろ？
2020/12/26(土) 00:06:30.37ID:w6CJ0JU3
>>353
できれば同じ方がいいがパフォーマンスも生産性も低いJSに合わせるのは愚策
server-sideでJS使ってるのはアホだと思う

大手ならserver-sideとclient-sideは別の人材が開発するのだから
言語を合わせるメリットはあまりない

ヤフーとかもbackendでnode.js使ってるが事故ばかり起こしてるだろ
レベルが低い
355デフォルトの名無しさん
垢版 |
2020/12/26(土) 19:37:00.30ID:5ukh9MxR
日本人の誰かBlazorのwikiを作ってくれ
フリーでオープンソースのウェブフレームワークって書くだけでも
wikiがないとBlazorが何かわからん
なぜC#を使ってウェブアプリが作れるのか？
ウェブブラウザはC#を解釈しないからJavaScriptとHTMLだろ
2020/12/26(土) 19:44:30.35ID:T66JFeJq
BlazorWasmのほう？
WebAssemblyで調べたらいいのでは
2020/12/26(土) 19:54:05.69ID:5ukh9MxR
>>356
WebAssemblyはwikiがあるが本文にBlazorがない
2020/12/26(土) 20:13:39.65ID:q2RopqqH
所詮その程度のオモチャということです
2020/12/26(土) 20:19:52.51ID:zr3CHg45
WebAssemblyはそれようの仮想マシンで動くからじゃないの

C#コードをその中間言語にコンパイルするだけ

たぶん
2020/12/27(日) 11:16:47.49ID:FLSM18Bj
>>355
そんなwiki作っても内容古くなるし意味ない
不正確で古い情報入手してどうする？
英語でMSのドキュメント読みなされ

何度も言うけどBlazorと書くべきじゃない。
Blazor Server, Blazor WebAssemblyで
アーキテクチャが全く違う。
2020/12/27(日) 11:17:34.43ID:FLSM18Bj
>>359
ちがう、いいかげんなこと書かずに
MSのドキュメントを読むべき
2020/12/27(日) 11:17:38.77ID:l7B3kP+i
>>360
似てるよ。
2020/12/27(日) 11:44:29.13ID:Y/0KLGYh
>>360
Blazorを初見で見て1分で何か知りたいだけでwikiがいい
時間をかけて英語でMSのドキュメントを読まない
2020/12/27(日) 11:56:13.46ID:l7B3kP+i
>>363
Web Assembly
https://docs.microsoft.com/ja-jp/aspnet/core/blazor/index/_static/blazor-webassembly.png?view=aspnetcore-5.0

Blazor Server
https://docs.microsoft.com/ja-jp/aspnet/core/blazor/index/_static/blazor-server.png?view=aspnetcore-5.0
2020/12/27(日) 12:57:58.03ID:5MC+7bSJ
>>361
あーそうね
Ｃ#のコードをいつも通り.NETの中間言語にしたものを配布して
ブラウザでの実行時にwasmのコードに変換して実行だっけ？

大して変わらんと思うけど
2020/12/27(日) 14:19:59.57ID:iruxp8RS
.NET6でAOTが入る予定らしいがファイルサイズの問題とかあるしwasm書くような用途なら他の言語の方がいいんじゃね
2020/12/28(月) 12:55:53.75ID:Ov8uGTUf
状態管理ってどうやるのが無難なのかな？
blazor + fluxor ？
2020/12/28(月) 20:34:30.42ID:N8gr0T4H
状態管理サービスをDI
2020/12/28(月) 20:36:55.85ID:RNhofGKy
blazorserver ならセッション？
webassemblyならいる？
2020/12/28(月) 23:32:18.60ID:w2tkTAcI
GO + wasm が来年のトレンドだと思いましゅ
371デフォルトの名無しさん
垢版 |
2020/12/29(火) 01:03:32.89ID:QFieIEDm
Kotlinはブーム来てる
Kotlinはwasmもすでに存在するようだ
2020/12/29(火) 07:55:55.72ID:iWtJxFHh
wasmとserver
wasmの方が人気だよなあ
serverはwebformの移植用以外は使い道がないんだろうか
2020/12/29(火) 09:17:54.01ID:8biyF2ED
go + wasm で使えるイケてるフロントエンドフレームワークがあったらいいんだがなぁ。
374デフォルトの名無しさん
垢版 |
2020/12/29(火) 09:43:58.26ID:QFieIEDm
Googleが採用言語を分裂させすぎだから
Goは普及しないだろ
FlutterではDart
AndroidではKotlin推してる
全部Goにしてたら結果は違ったはず
Kotlinのが流行ってるしな
Go速いらしいけど人気ないのははハードル高いんだろうか
2020/12/29(火) 12:10:38.95ID:TrPJjXJg
>>372
これホント？

なんとかC#しか使えないエンジニアを有効活用して
JSの10倍遅くても問題ないからオフラインでも使えるWebアプリを作りたいってニーズある？
JSが不要になるわけじゃないし現状はデスクトップアプリかblazor serverのほうが何倍も良いと思うけど
2020/12/29(火) 12:22:03.72ID:gscEc512
PlayStation Portable go の運命と重なる...
2020/12/29(火) 12:30:16.56ID:iAxs8NN4
>>375
どっちでもいいんじゃないの
何倍というほどの差はない
2020/12/29(火) 12:33:17.29ID:Fq3XcUlo
>>375
おっしゃるとおり！
俺のような企業向けアプリしか作らない人間からすると
wasmよりserverのほうが使えそうなんだよね
でもblazorでググるとwasmの記事ばかり引っかからない？
あっちのほうが期待されてるように感じる…
2020/12/29(火) 13:01:36.23ID:k23+wtCh
Chromeではある程度可能だが、いまのところ、広く一般には、Wasmは、ローカルファイルシステムになかなか自由にはアクセスできない。
ところが、Cordovaはlocal http serverをアプリ起動時に立ち上げて、
WebViewでHtml+JS+Wasmを起動ですることによって、
Wasm
--> JS
--> XmlHttpRequest()/fetch() で "http://localhost:5000/機能名?トークン&パラメータ" にアクセス
--> Http プロトコルの Http Request が発生し、local http serverが眠りから覚める。
--> local http server は、端末の API を好きなように呼び出し、端末の
ローカルファイルシステムを読み書きする。
--> http response で結果を JS 側に返す。
--> JS は、結果を受け取る。
の順序でWasmからローカルファイルシステムにアクセスできる様になるらしい。
Cordovaは、AndroidでWasmが使えたという報告があるし、
iOSでもVer11以降だとWasmが使えたという報告がある。
つまり、多くの人が使っているモバイルデバイスでは、WasmとCordovaの組み合わせで
モバイルのローカルファイルシステムも、あらゆる端末機能にもWasmから利用可能に
なるようだ。
2020/12/29(火) 13:02:15.95ID:EHaGj/ct
そりゃ技術的に面白いのはwasmだから話題になるのそっちだよ
2020/12/29(火) 13:07:56.98ID:k23+wtCh
>>379
[補足]
この方式だと端末内の他のアプリからでも、このアプリのlocal http serverに
アクセスできるからセキュリティー的な問題が有るという心配が有るかもしれないが、
そこは「トークン」をつけているので心配が無い。
それは、アプリ起動時に乱数の様なものから作成し、local http serverとJSの
両方に同じトークン値を渡すことで、鍵の様な働きをする。
トークンが合わなければlocal http serverは機能しないようにすることで、
セキュリティー上の問題はクリアできる。
2020/12/29(火) 13:19:00.27ID:k23+wtCh
MonacaはCordovaアプリをブラウザから作製できるようにした「クラウドIDE」で
Mac実機無しにiOSアプリを作製してAppStoreに登録できる、とされている。
2020/12/29(火) 13:21:34.09ID:k23+wtCh
>>382
ただし、クラウドの先にあるMac実機をレンタルする必要があるかもしれない。
2020/12/30(水) 19:23:50.60ID:+vZt7ZP1
>>381
それＷＥＢアプリであるメリットを感じないんだが
そのトークンはだれが作るって？
ローカルサーバーに自分でトークン作って渡すんなら、トークン偽装しほうだいだな
2020/12/31(木) 14:25:23.04ID:hpqEd6nD
>>384
この話は、Html+JS+WasmのWebアプリWを、WebViewを使って、
native アプリAのようにする場合の話。
native アプリAが起動するときに、まずトークンTを作り、
WebViewとHttpServerを同時に起動し、その両方に同じトークンTを
渡す。
nativeアプリA
--->トークンT作製
---> HttpServerを起動しトークンTを渡す。
---> WebViewを起動しトークンTを渡す。
---> WebView内でHtml+JS+Wasm (W)が動作し始める。
---> JS内からトークンTをGET PARAMETERに付けたURLによって
　　fetch, または、XHRを使ってHttpServerにアクセスする。
　　URLは、http://localserver:5000/機能名?トークンT&パラメータ
　　のようになる。
---> HttpServerは、イベントを待機した状態から目覚め、
　　GET PARAMETERにトークンTが入っていることを確認したら、
　　機能名に応じた動作を nativeAPIを使って行う。
---> 端末のローカルファイルシステムにも読み書きできる。
---> 結果を Http プロトコルの Http Response で JS に返す。
---> JS は結果を受け取る。
2020/12/31(木) 14:45:37.85ID:tdaLm2s5
ネイティブアプリならそのままローカルファイルアクセスしてUIレイヤーとしてWebView使えば十分では？

わざわざローカルでweb server起動してそれ経由でファイルアクセスさせるメリットってあるの？
2020/12/31(木) 14:52:50.53ID:bz8vpTSU
でも、既 存のア プリの流 用なら単にserverとclientを一箇所で動かすだけに見えるし、
新 規ならそもそもメ リ ットがどこにあるんだろうという感じだし。
どうしてもUIをhtmlとjsで書きたい場合とかかな。
2021/01/01(金) 02:03:52.73ID:y/yrEKhd
>>386 >>387
自分でクロスプラットフォームツールキットを作っている場合、
iOS/Android/Windows/Linux/Macなどに個別に対応させるのが大変な場合、
HTML+JS+Wasmでまず、ブラウザで動くようにしておき、ファイル入出力
部分だけを上記の様な local HttpServer 方式で行えば便利。
2021/01/01(金) 02:09:02.70ID:y/yrEKhd
>>386
それだとWasmをメインプログラムとしたクロスプラットフォームアプリは
作りにくい。
Wasmの関数の中にファイル入出力を行いたい部分が有った場合など。
2021/01/01(金) 13:36:41.38ID:xBl+DmmI
FileとかOS API使いたければ素直にnative appにするほうがいい。
わざわざwasmとか意味不明
2021/01/01(金) 23:29:42.24ID:TX7qBddY
>>390
特にクロスプラットフォームのライブラリを自作する場合、ブラウザ上のWasmで
ファイルアクセスまで出来れば対応が楽。
2021/01/01(金) 23:57:03.96ID:ifweq93H
トークン作るネイティブアプリがあって
HttpServer側のローカルアクセス部分も個別に作るのか
2021/01/02(土) 00:01:46.88ID:TBL/2gAq
？
wasmからファイルにアクセスするわけじゃないよね？
というかそもそもwasmでコーディングするわけでもないよね。
2021/01/02(土) 00:47:26.18ID:md7DJnNn
そもそもWasmでファイルアクセスできたらセキュリティ上おかしいんじゃないのか？

Wasmはソースコード見えないというのに
知らないうちにファイルアクセスするコードダウンロードして
実行されたらまずいだろう

MSの人も動画でBlazor Wasmは安全だといっていた。
Browserのsandbox内で動作するからというがその理由。

>>391
実際コード書いてないわけでしょ
wasmより絶対にネイティブのが楽
nativeでcross-platform対応もできる。FlutterやXamarin
2021/01/02(土) 10:59:11.61ID:kLdWoF3Z
>>394
C++で書いたプログラムをWasmに変換し、それをWebViewの中で実行する場合の
話だよ。
WebViewを起動するのは、C++やSwift、Javaなど。
その際にlocal http serverとWebViewを同時に起動する。
そして1つの鍵(セキュリティートークン)をlocal http serverとWebViewの
両方に渡す。
なので安全。
2021/01/02(土) 11:26:48.47ID:XwpZ0T7a
つまり、悪意のあるプログラムが自分でトークン作ってlocal http serverたたいて
それ経由でローカルファイル等の情報にアクセスできるんだろ

local http serverは正しいWebViewから呼ばれているのかどうか確認できないんだが
それのどこが安全？
2021/01/02(土) 11:42:56.76ID:kLdWoF3Z
>>396
できない。
それはキャッシュカードを拾っても、正しい暗証番号が分からなければATMから金を
引き出せないのと同じこと。
local http serverとWebViewの中のJSの両方に1つの暗証番号を渡しているので
両者だけが通信できて、他のアプリは通信できない。
2021/01/02(土) 11:47:13.97ID:kLdWoF3Z
>>397
[補足]
・URLのGET PARAMETERの中に正しい暗証番号(=トークン)が書いてある場合には
　なるべく速く処理を行ってできるだけ早くresponseを返すようにする。
・暗証番号が間違っている時には、数秒間waitしてからresponseを返し、かつ、
　waitしている間は、新たなリクエストを受け付けないようにする。
・こうすれば暗証番号を順番に試してたまたま開く鍵を見つけることが現実的な
　時間では不可能になるので悪意を持ったアプリから身を守ることができる。
2021/01/02(土) 15:33:34.85ID:XwpZ0T7a
いやだから、その暗証番号はカード使う人が外部から指定するんだろ
その暗証番号を指定している人が、そのカードの正しい所有者かどうか確認できないと思うんだが
これが安全だと思えないのは俺がおかしいのか？
2021/01/02(土) 15:35:28.24ID:kLdWoF3Z
>>399
すまんが、俺のIQは、150超だから、一般プログラマには理解できないかも知れない。
401デフォルトの名無しさん
垢版 |
2021/01/02(土) 15:46:16.27ID:5cxm5c+d
InputFile の OnChange で、選択されたファイル数が0の場合はどうすればイベント拾えるのでしょうか？

<InputFile OnChange = "method" />

@code {
private void method(InputFileChangeEventArgs e)
{
//ファイル未選択の場合はこのメソッド自体が呼び出されない。
}
}
2021/01/02(土) 16:59:19.62ID:kLdWoF3Z
>>399
WebViewという名前でも、ネット回線からダウンロードしてきた
HTML+JS+Wasmを表示・実行するわけではなく、アプリにパッケージされた
HTML+JS+Wasmを表示・実行するので、所有者の同一性は最初から保証される。
もちろんアプリのパッケージを改ざんすれば駄目だが、それは今回の
セキュリティー問題とはまた別の話。
アプリの改ざんについては、そもそも論で、それはそれで別の方法で改ざんを
防止する技術が必要となる。
2021/01/02(土) 19:13:25.57ID:XwpZ0T7a
そのアプリのパッケージにlocal http serverとサーバ側のプログラムなりスクリプトなりも含むのか？
2021/01/02(土) 19:19:19.80ID:kLdWoF3Z
>>403
アプリのパッケージには、
1. local htttp server
2. html+JS+Wasmのプログラム
3. セキュリティートークン発生器
4. ファイルAPI呼び出し器
を含む。
原則的にサーバーは全く使わないのでサーバー側プログラムは含まないが、
サーバー側プログラムを使う場合には、nativeアプリがサーバー側プログラム
と連携する場合のやり方をそのまま使えばよい。
2021/01/02(土) 22:23:44.30ID:md7DJnNn
>>404
通常のブラウザでは通用しないってことでOK？

ユーザーにファイルアクセスを求める仕組みはどうなってるの？
あとhttp serverなんて動かそうとしたらPCのセキュリティなりファイアウォールが警告だしてくるはず。

Flutterとかのnativeでやるほうが楽なのに
いちいちたくさんの言語使って無駄な工数かける意味がわからん。
しかもめんどくさいわりにサーバー使ってないとかますますわからん。
2021/01/02(土) 22:24:16.16ID:md7DJnNn
大手企業がWasm使ってない理由は労力のわりにメリットがないことだと思う。
メリットあるとしたらGoogle/Appleの手数料回避できそうなことくらいか
2021/01/03(日) 02:08:15.23ID:bUgsUhHF
>>405
>通常のブラウザでは通用しないってことでOK？
ちゃんとアプリとしてパッケージしないと駄目だね。

>ユーザーにファイルアクセスを求める仕組みはどうなってるの？
ファイル関係はnativeアプリと同じになる。
なぜならnativaアプリが使うファイルAPIを使うのだから。

>あとhttp serverなんて動かそうとしたらPCのセキュリティなりファイアウォールが警告だしてくるはず。
今回説明してきた方法は、既にCordova(やmonaca)でも実績が有るのでなんとかなる
はず。AppStoreやPlayStoreなどへの登録も可能。
また、local http serverは、Rubyやnode.jsやapache、mongooseなどでも普通に
高頻度で使用されており、特にセキュリティーソフトが問題になることはない。
なぜならWasmのローカルでのテストには必ず必要になるから。
2021/01/03(日) 02:15:37.37ID:bUgsUhHF
>>407
[補足]
今回、local http serverは、JS+Wasmでは使えない端末機能を使うためのもの
であったが、ローカルだけでWasmを起動するためにも必要。
Wasmは、fetchやXHRを使わないと起動できないが、CORSの関係で
少なくともWindowsではlocal http serverを起動していないとエラーになる。
(それがないと、URLにローカルのファイルパスをどういうschemeで指定
しても駄目。)
2021/01/03(日) 03:24:25.31ID:pzO8LSqN
その実績ってのをいくつか紹介してくれ
2021/01/03(日) 03:53:04.49ID:bUgsUhHF
>>409
Cordovaが使っている技術を解説しているサイトに書いてある。
Cordovaを使って作るのではなく、Cordovaが自分自身で使っているアルゴリズム
であり、かつ、Cordovaは、AppStoreとPlayStoreに登録できるとされている
非常に有名なソフト。
2021/01/03(日) 10:07:36.68ID:ZfI7ecBk
>>407
後半のlocal firewallの話は一般ユーザーの問題点だよ。
技術的に動くかどうかの話じゃない。

開発者はfirewallから警告でても意味がわかるけど、
一般ユーザーはとまどうってこと。
2021/01/03(日) 10:19:49.86ID:S5x84IqF
デタラメな俺理論を長々と書く奴は相手にせず放置が一番


まぁhttpdの話はローカルサーバーに同じホストからアクセスしてる分には
ファイアーウォールとか関係ないでしょ
2021/01/03(日) 12:05:13.76ID:bUgsUhHF
>>412
頭が悪い人には頭が良い人が言っていることが理解できないのでデタラメに
聞こえるし、長い文章も読めないし。
2021/01/03(日) 12:06:19.30ID:bUgsUhHF
>>411
Cordovaという有名どころでライブラリの基礎で使われているアルゴリズム
なのだから、当然、ユーザーの視点でも大丈夫になっているハズだ。
2021/01/03(日) 12:07:52.02ID:hFPMmBD/
ローカルへのhttpアクセスをデフォルトではブロックしてるファイアウォールとかもあるんだよ
2021/01/03(日) 13:07:23.70ID:ZfI7ecBk
>>412
415も書いてるけど
たしかWindowsのFirewallでも
localからのアクセスでもちゃんと警告でるよ
2021/01/03(日) 13:09:03.48ID:arRzErs6
Cordovaなんて
何年もまえからある、
弩メジャーなやつじゃん。
なので数年前に旬を過ぎて枯れてるけどね。

Visual Studioでも2013？ぐらいから
テンプレート入っとるぞ。

やっぱBlazorレベルのユーザーは
レベルが周回おくれなのか？
2021/01/03(日) 13:11:40.28ID:arRzErs6
正直いってXamarinよりCordovaのほうが
遥かにイケてるぞ。大手のスマホアプリで実績多いでしょ。
2021/01/03(日) 13:13:18.51ID:ZfI7ecBk
>>414
それなら初めからCordovaでnative appにすりゃいいじゃないの。
頭が良い人はそちらを選ぶだろう

いちいちwasmやらhttp serverを使う必要がない。
無駄に時間かかるだけ
2021/01/03(日) 13:23:38.42ID:S5x84IqF
らしい、とか、ハズ、とか
わろた
2021/01/03(日) 13:47:20.60ID:arRzErs6
Cordovaでクロスプラットフォームで
自前ブラウザーアプリが作れるから、
そのアプリ実装部分でWasmはありだぞ。

実際、CordovaとWeb系UIのライブラリーを
組み合わせて開発する。
なのでCordovaとBlazorでも可能じゃね？

自分のは数年前にCordovaとPWAとで
検討中して見送った過去がある。
2021/01/03(日) 14:04:27.77ID:bUgsUhHF
>>421
>なのでCordovaとBlazorでも可能じゃね？
理論上は、BlazorWasmもHTML5と標準Wasmの範囲内のコードになっているはず
なのだから、そのままか、わずかな配慮でで動く可能性は高い。
2021/01/03(日) 14:21:02.77ID:bUgsUhHF
この方式はC言語とposixが使えるプラットフォームならほとんど無修正で
同じサポートコードが使える可能性があるので便利なのだが、
fire wallの警告が出てしまうならば、使えないかもしれない。
Cordovaは この方式以外にも3種類くらいの方法を併用してJSと
nativeの間で通信しているとされるが、それらにはプラットフォーム間の
互換性が乏しく、iOS、Android、Windows、Linuxなどで
サポートコードの書き直しが必要となる。
2021/01/03(日) 14:34:57.09ID:arRzErs6
今自分がやるなら
flutter+WebUIライブラリーかな。
まだ下調べはしてないし作るものも多いけど。

そこにBlazorがあってもなくてもよいが。
2021/01/03(日) 15:00:54.68ID:ZfI7ecBk
>>418
実績、実績いうならwasmなんて論外だろｗ


CordovaなんてJS, CSSベースだしうんこすぎるし使わんよ。
Xamarinはシェア５位だから実績は十分だしC#使える。
MAUIになれば品質もあがるだろう。
Unityでもいいし、Flutter, Kotlinでもいい
2021/01/03(日) 15:24:48.35ID:arRzErs6
UI開発ではHTＭL&JSのライブラリーが
断トツ最強なんたが。
2021/01/05(火) 22:26:03.46ID:eSPu60fw
cordovaなんて10年近く前のプラットフォームじゃん。
ちょっと後に出たionicに頃されたんじゃなかった？
2021/01/06(水) 13:32:12.25ID:PNufzztm
>>425 >>427
Cordova単体なら言語がJSに強制されるが、WasmもCordovaで動くようになったので
言語はJSに強制されなくなった。
今後、CordovaはC++、Rust、C#(BlazorWasm)をクロスプラットフォーム
で動かすための土台としての私用用途が出て来る。
2021/01/06(水) 13:33:21.72ID:PNufzztm
>>428
Cordova方式はElectronよりサイズが小さいはず。
2021/01/06(水) 13:53:04.57ID:PNufzztm
Electronは、WebブラウザであるところのChroniumの改造場も同時配布する
必要があるので、アプリサイズが最低350MB位となるが、Cordovaだと800KB
程度で済むと報告されている：
https://stackoverflow.com/questions/26167023/reduce-cordova-apks-size
2021/01/06(水) 15:01:07.35ID:twxSQNJZ
CordovaはAdobeが投資を引き上げて後は終焉を待つ状態なので
5年前ならいざ知らず今から新規に採用するようなものじゃない

本当にクロスプラットフォームの土台となりうるなら
AdobeがPhoneGap終わらせてCordovaからも手を引いたりしないよね
2021/01/06(水) 15:31:36.33ID:Y7FOu5Ta
そもそもcordovaはionicに負けてしかも日本ではそのどっちも流行ったことないでしょ。
何年前の技術語ってんだ浦島太郎かよ。
2021/01/06(水) 15:34:10.93ID:N9dyrfHy
久しぶりに聞いたな
2021/01/06(水) 16:05:53.56ID:twxSQNJZ
>>432
Ionicは基本的にCordova使う前提のフレームワークだぞ
2021/01/06(水) 17:36:23.26ID:IwWtN5mv
オンプレ爺とCordova爺は同一人物？
2021/01/06(水) 17:55:22.98ID:ATHWudiV
スクリプト系言語は総じてクソだぞ爺さんと同一人物
2021/01/06(水) 18:22:10.23ID:IwWtN5mv
あーそっちの方かサンガツ
2021/01/06(水) 22:02:50.48ID:YZSk0OOW
>>435-437
アホだなおまえら
CordovaはJSだぞ
CordovaがJSなの知らないほど無知

むしろその人にFirewalｌ警告などの問題点を指摘した。
オンプレミス派は頭いいから基本的に高速な言語を好む
2021/01/06(水) 22:31:39.93ID:ge6MZGJO
いつものザマオンプレ爺さん定期
2021/01/06(水) 22:37:55.13ID:YZSk0OOW
>>439
爺さんではなくおにいさん定期
Xamarin評判悪いからUnityもやる
2021/01/06(水) 23:43:33.16ID:k0vOylQ2
オンプレ爺さんまだいたのか
2021/01/07(木) 01:52:20.73ID:3TLTtAUE
「まだクラウドじゃないんですか？」で金を取り、
「これからはむしろオンプレですよ」でまた金を取る。
これを永久に繰り返す錬金術ｗ

企業が「脱クラウド」「オンプレ回帰」に踏み切る理由
https://www.itmedia.co.jp/enterprise/spv/2101/05/news002.html
2021/01/07(木) 15:03:31.98ID:BLvEhbF6
>>442
やっと事実を伝える記事が増えてきたか。
パブリッククラウドは時代遅れなんて経験あるエンジニアには常識

遅いし高いしろくでもない
2021/01/07(木) 16:28:53.05ID:jfoKMLtR
>>443
自演乙
2021/01/07(木) 21:50:05.56ID:DHxcg4pM
老害回避用に下記単語のNGワード設定を推奨

オンプレ
Xamarin
Cordova
2021/01/07(木) 22:40:27.59ID:BLvEhbF6
>>444
こんなことで自演するかよｗバカｗ
クラウドがクソなんてスキルある人には常識
2021/01/07(木) 23:10:55.02ID:c5+YjLRl
しつけーなジジイ
何度も5ch覗きに来んな無能ハゲ
2021/01/08(金) 06:54:41.89ID:eHuqAzdP
クラウド爺さんは二人いたんだなあ
2021/01/08(金) 11:40:03.05ID:hbHr5ZSG
Cordva騒いでた人＝オンプレ爺だったのかよ
本気で気付いてなかった自分を殴りたい
2021/01/08(金) 12:07:35.03ID:MOpHGUBr
>>449
夏くらいまで自分を殴ってていいよ
2021/01/08(金) 12:18:27.99ID:5RCoenNw
>>449
ちがうつってんだろバカ
それぞれの技術の特徴しってたら間違えようがないんだけどな
>>438読め

File API使いたければ素直にnative使え、
http serverはfirewallが警告出す、
とまっとうなレスいれたのがおまえらがオンプレおにいさんと呼ぶ奴だ。

俺はC#やKotlin, Swiftのような言語を好む
スクリプトしかできないやつ、クラウド頼みのやつをバカにしてきてるのに
JSで時代遅れなCordovaなんて使うわけがない
node.jsもdisってきている。
2021/01/08(金) 13:55:28.48ID:9vpDWgh3
>>451
ところがWasmでcordovaを使うのは最新なんだな、これが。
というよりまだ誰もやってない。
2021/01/08(金) 13:59:08.83ID:MOpHGUBr
>>451
クラウド頼みをバカにしてるってことは…ひょっとすると君もオンプレ爺さんなのかい！？
2021/01/08(金) 14:20:11.98ID:9vpDWgh3
いまのところWASIはグラフィック出力が出来ないし、
wasmerは、CUIのWASIだけで、しかも今最も肝心なiOSやAndroidでは
それすらも動かない。
が、Cordovaを使えばWASIをモバイルも含めたあらゆるプラットフォームで
グラフィック付きで動かすことが出来るようになるに違いない。
2021/01/08(金) 16:22:21.34ID:5RCoenNw
>>452
新しければいいわけじゃない。
C#, C++のように古くても必要とされる技術がある。

wasmは新しいが必要性がない。
手数料回避以外にメリットがない
大手が採用してないだろ
まだ時期尚早

wasmはIT大手が使い始めてからでよい
それまでnativeの学習するのが賢い
2021/01/08(金) 16:49:03.26ID:F+SpYfrf
>>455
1. HTML+JS+Wasmの部分は、出力バイナリがプラットフォームが変わっても
　変わらないという特徴があるのでビルド結果をバックアップするのは楽。
　ただし、Cordova方式の場合は、*.apkなどにパッケージ化する際にプラットフォーム
　依存になってしまうが。
2. GTKやQtなどは自分でグラフィック部分も各OSに合わせて用意しているのでサイズが
　大きいし、ツールキットを作るのも大変だが、Wasmの場合、HTML5のcanvasを
　使えばその部分が不要なので、ツールキットが作り安いし、サイズが小さい。
2021/01/08(金) 19:42:08.00ID:5RCoenNw
>>456
しつこくCordova推してるけどうざがられてるだけだぞ。
BlazorはJSが嫌いでC#が好きな人が興味持ってるんだから
ここでJS系の技術を推すのはナンセンス

その特殊なスタックを推したければBlogなりYouTubeなり
GitHubでやってくれ
2021/01/08(金) 21:32:03.22ID:eX99CYJf
node.jsなんか使いたくもないわ
2021/01/08(金) 22:21:40.37ID:1X0kULwm
>>457
ザマ爺てめえも同じくらいうざがられてるから率先してスレから消えろや
目くそ鼻くその分際で粋がるんじゃねえ
2021/01/09(土) 12:38:53.91ID:hogOqFTZ
>>459
ほんとアホだな
おまえらが俺のことを書かなければ気が付くようなレスはしない。
当面Wasmでコード書くこともないしこのスレ読みたくないんだが
おまえみたいに俺の話題を書くからいつまでも続く

>>458
JS全部だろう
nativeやればいいだけ。まともな言語だらけ
C#, Kotlin, Swift
2021/01/09(土) 15:19:24.66ID:X2U+K+I4
だれか登場人物と相関図を整理してくれ
ザマリン爺さんとオンプレ兄さんが恋敵なのはわかった
2021/01/09(土) 16:45:25.64ID:jYiNSutT
考えるの面倒だからまともに読んでない
2021/01/09(土) 18:02:30.85ID:4SmuPkRr
>>461
正確にはザマオンプレ爺な
スキルセットの古さから推定年齢50代後半、最近ようやくザマリンの不人気に気付いたというアホ

もう一人はCordova爺、とはいっても意外に若いかもしれない年齢不詳
こいつはザマ爺とは異なり知識は深い、が偏りすぎてて職場にいると面倒くさいタイプ
2021/01/09(土) 21:00:29.31ID:V/x0GCIg
ここは老人たちを隔離するために作られたスレ
あきらめて仲良く雑談しなさい
2021/01/09(土) 23:20:48.56ID:hogOqFTZ
>>463 >>461
ほらな、こうやって俺の話題しか話せないような
スキルない奴がすぐ湧いてくる

C#とKotlinとSwift推してる俺のスキルセットが古いって
脳みそくさりすぎだろｗ
2021/01/09(土) 23:24:24.77ID:hogOqFTZ
それとXamarinはシェア５位で不人気でもなんでもない。
人気のあるフレームワークだ
>>463のアホはモバイルアプリ開発経験ゼロだろう

言語がゴミなFlutterよりもXamarin/MAUIは伸びしろがある。
2021/01/10(日) 02:57:31.92ID:mWh+kAw4
ザマ爺、お前のハッタリは聞き飽きたよｗ
2021/01/10(日) 03:21:58.38ID:t4oThHgn
https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours/
2021/01/10(日) 03:46:34.61ID:79osdvS+
>>468
(上位から大きく離れてシェア急落中の)5位だからなw不人気では無いなw
あっという間にflutterに追い抜かれてxamarinファンには面白くないかもしれんが
エンジニアならフェアに判断しようや
2021/01/10(日) 09:23:59.56ID:osL1god/
オンプレ爺、C#とXamarin使いの設定だったのがしれっとKotlin・Swiftまで追加してるじゃん！？

雑談スレだから今まで見逃してたけれども調子に乗って吹かしてると張り倒すぞこの野郎
2021/01/10(日) 09:38:16.74ID:TUlvVbF7
>>468
シェア５位のソース張りおつかれ

>>469
おまえみたいなバカは単純にシェアでしか判断できない。
Flutter(Dart)は言語がクソで有名だ。
複雑なコードを書こうとしたら言語が足を引っ張る

React Native, Cordova, IonicはJSでクソ。
2021/01/10(日) 09:40:57.52ID:TUlvVbF7
>>470
ここC#系のスレだからXamarinよく書いてただけだハゲ
ここのやつらスキルないしKotlinの知識ゼロだしな
実際はKotlin推し
2021/01/10(日) 10:58:09.59ID:SrWqbjf1
>>471

なるほど賢く優秀だと1年でシェア26%から14%にほぼ半減しても判断材料にしないよなw
Flutterは言語がクソ(根拠示さず)で有名(根拠示さず)だから影響ないよなw

>複雑なコードを書こうとしたら言語が足を引っ張る

足引っ張ってるのは言語なのか？実は”誰か”だったりしないか？w

>React Native, Cordova, IonicはJSでクソ。

MSのスマホアプリはクソのReact Nativeで実装してるけどなw
不思議だなw
2021/01/10(日) 11:54:35.09ID:GMn9HNNA
Native推すってことは
C#でのWEBアプリ開発はイマイチって思ってるってことなのかな
その辺はjs系言語に一日の長ありということを認めてるよね。

Blazorはjs系言語いまさら覚えられませんって人向けだと思うわ
おれのことだけど。
2021/01/10(日) 12:11:41.51ID:ZqyUOoXz
Blazorで出来る事は限られてるよ。
ちょっとした事ですぐ
js面に手を出すことになって、
そんとき浦島太郎だ！
2021/01/10(日) 16:17:36.42ID:TUlvVbF7
>>473
それはcross-platformはろくなのがないからだよ
１年で半減もあるし逆に１年で5倍もありうる状態

React NativeもXamarinもバグが多かったりで
まともに使えないのがたくさんある。
Flutterも消去法で選ばれてるだけ
Flutter使ってるやつらもDartがクソだと認めてる
言語がだめだと結局消えるのを俺はわかってるから手を出さない。
2021/01/10(日) 16:24:36.33ID:TUlvVbF7
>>473
最終行
既存アプリはXamarin買収する前に開発スタートしてたんだろ。

MAUIが実用レベルになればMSもMAUIでアプリ作るようになるはずだし
そもそもMSが自社で使ってるかどうかはどうでもいい話
ほかの会社のアプリが十分に使ってればそれでいい
2021/01/10(日) 16:37:25.68ID:TUlvVbF7
>>474
wasmには期待していたがBlazor wasmさわって
すぐJS不要にできる状況ではない、とすぐわかった。
数年後はわからんが今はだめ

web appはJS以外にもCSSとか生産性低い要素が
あるから好きではない。
nativeなら会社以外の時間にひとりで開発してマネタイズ
できるからnativeの時間を増やしているというだけ。
2021/01/10(日) 17:03:22.02ID:GMn9HNNA
>>478
BlazorServerは？
作ってるのがオフラインでも動くようなアプリなんだったらwasmやNativeなのはわかるけど。
2021/01/10(日) 17:14:24.46ID:TUlvVbF7
>>479
Blazor Serverはスケールしないから好きじゃない。
ステートフルは時代遅れだと思うわ
前にも指摘したがBlazor ServerはMSが
Azureで儲けるための技術と見ている。
俺は不特定多数向けサービス作ってるから
スケールしない技術に興味はない。
サーバーに負荷が集中しすぎるアーキテクチャ。

企業内システムで使う分にはいいんじゃないの
同時接続が予測できる範囲ならってこと
2021/01/10(日) 17:39:06.95ID:GMn9HNNA
>>480
なんとなくあなたの選択肢はTypeScript+Reactだと思うよ
js系言語がクソだと言うがTypeScriptなら大丈夫なんじゃないの
多分少し触っただけでクソだと言ってるのでは？そこまでガッツリやってないという印象。
2021/01/10(日) 23:28:55.11ID:IfLhCjnV
TypeScriptもJavaScruptと全く別の言語ってわけじゃないからなぁ

結局JavaScriptわかってないと困る場面が出てくる気がする
2021/01/10(日) 23:38:06.59ID:re1lSACU
MS オフィスアプリはreact nativeで作られてるってマジ？
2021/01/11(月) 15:07:17.31ID:aEN5u7j8
raspberry pi 4で.NET動いたー
2021/01/11(月) 22:15:13.04ID:NARwS4T4
>>481
web appの開発生産性の低さの理由はJS以外にもある。
犯人はHTML, CSS。
Web designは得意じゃないからReactみたいに
frontendのコード書くのが苦痛で仕方ない。

smartphone、windowsのnative appはそういった苦痛がないんだな
C#/Kotlin/Swift, 言語は全部、静的だしめんどくさいCSSはない。
おれには天国
2021/01/11(月) 22:16:12.48ID:NARwS4T4
SP appだけリリースしてweb appは出さないっていうサービス増えてるよな？
そういう割り切りって大事だと思う
みんなブラウザに固執しすぎですわ
2021/01/12(火) 00:22:24.81ID:frmHOofW
いやリリースしてるのがスマホアプリだけでも技術的には完全にWebベースのものがほとんどだよ
2021/01/12(火) 08:23:25.72ID:YVBPDvLm
>>485
わかる
なんでこんな複雑怪奇なものにリソースを割かないといけないんだ？って気持ちになる
Web系エンジニアってすごい忍耐力があるとおもうわ

しかしWebアプリからは逃げられない…
2021/01/12(火) 13:57:46.77ID:gN/Az5jH
Webアプリの苦痛はブラウザ毎のHTML/JS/CSSの対応バージョン考慮しないといけないとこだよね。
仕事だからやってるけどクッソめんどい。
全ブラウザが常に最新のJS/CSSフルサポートしてくれれば何の文句もないんだけど。
あと、ブラウザのオプション設定とかセキュリティソフトのせいで微妙に想定外の動作するとか勘弁してほしい。

パッケージソフトならRuntime同梱で割とどうにでもなってたのに・・・
2021/01/12(火) 15:24:59.60ID:Tnz9LnkQ
>>488
>>489
ようはwebエンジニア未満って事では...。
2021/01/12(火) 16:03:19.01ID:651NdeAm
>>488
web app嫌いなら逃げたっていいだろう
自社で解決しなけりゃモバイル知識つけて転職すりゃいい

あとAndroid, iOS appエンジニアもWebエンジニアだし

>>490
それはない
web appのbackendしかやらない人もwebエンジニアだし
2021/01/12(火) 17:46:56.35ID:Ao5nGZOO
>>490
いやなんとなくvb5とかvbaの臭いがするんだよな…
型が使えるだけで喜んでる人たちだし
2021/01/12(火) 18:24:03.86ID:DnpTcmq6
また言い合いを誘ってるだけのくそレスか
2021/01/13(水) 21:21:51.49ID:qDmikOjf
うだつの上がらない底辺の巣窟ですからｗｗｗ
2021/01/13(水) 21:57:45.94ID:jEePmYlx
>>494
型が使えて嬉しい？
2021/01/13(水) 22:15:04.99ID:cdnuNNke
パッケージソフトばっか作ってた時代はWebアプリのメリットとか楽しさ全く分からんかった。
今はソフトの設定画面とかはChromium使ってWeb風にしてる。
JQueryやVue.jsでGUI実装する楽さと柔軟さは圧倒的(Reactは使ったことないから知らん)

ただし対応ブラウザのバージョンとか設定とか気にし始めると精神擦り減るから純粋なWebアプリはきつい。
2021/01/16(土) 13:20:28.52ID:ZWdP8vPv
C#は、値型/参照型/参照渡し関連がごちゃごちゃしているな。
Cのポインタが理解できない人が多いと聞いたが、彼らには、
C#のstructとclassで値型と参照型の違いが有ったり、参照渡しの
概念はそれらとは別にあったりすることや、DeppCopyとShallowCopy
の違い、代入演算子=で何が起きるかなどを正しく理解できるのだろうか？
2021/01/16(土) 17:33:27.69ID:dh/EnmR5
>>497
できますよ
2021/01/21(木) 10:59:39.61ID:NpE+5Spi
Blazor WebAssembly App の PWA で、FormでいうKeyPreviewのように、どのコンロトール上にフォーカスがあっても、キー入力のイベントを取得できるのでしょうか。
キーボードインターフェイスのバーコードリーダの入力を、テキストボックスに入力する以外の方法で行いたいのです。

div上にフォーカスが存在する場合は取れたのですが・・・
500デフォルトの名無しさん
垢版 |
2021/01/21(木) 12:09:27.74ID:084E4D0G
あれ？C#さえ分かれば使えるのでは？
2021/01/24(日) 09:43:03.07ID:EXqklOpv
asp.net mvcのスキャフォールディングを使ってコード生成してくれる機能すごい便利と思ってたけど
Blazorにないのはなんでなんだろう

流行りじゃなくなったから？
2021/01/25(月) 23:24:35.92ID:vuFdTYWI
<inpu
2021/01/26(火) 00:14:54.94ID:qSdfocRR
>>501
基本的に1モデルに対して一枚のHTMLを作ればよい古典的なWebMVCに対して、
Blazorというか仮想DOM系フレームワークはビューの論理構造に合わせて積極的にコンポーネントを分割、ネストしていくんだよ
要件によって全然違った構造になるんでスキャフォールドなんか役に立たない
2021/01/30(土) 12:52:21.79ID:gpuCWU5d
>>503
業務系だとほとんどの場合1モデルに対して1HTML（というかスキャフォールドでできる例の一式）なんだけどな
たまにややこしいUIがある。
MVCにBlazorを組み込めるようになったら捗るのに。
2021/01/30(土) 13:22:26.04ID:VnS/Ic0u
scriptブロックにC#を使えるだけでもだいぶ楽になるはずなんだがね…
SPAとセットみたいな扱いなのが残念
2021/01/30(土) 14:04:23.64ID:NIBr3ao+
MS技術は開発環境を過剰に整備しすぎて、複数のものを柔軟に組み合わせて利用することが困難になってることが多いよね
2021/01/30(土) 14:30:26.39ID:qqS09RJU
かといってAndroidStudioみたいに、独立したツールを寄せ集められても困る。
1つツールをバージョンアップすると謎のエラーが出まくるとかあるし。

AndroidStudioはバージョンアップ恐怖症だわ
2021/01/30(土) 20:09:20.29ID:lNvH5Mw3
>>506
Angularが廃れたのと同じ失敗繰り返してるよね…
2021/01/30(土) 21:19:43.17ID:vJSVoVkS
>>506
そうか？
2021/01/30(土) 21:20:08.48ID:vJSVoVkS
>>507
わかる
2021/02/28(日) 09:30:22.76ID:hkX3n4ku
>>506
なんか困難な部分あるっけ？
2021/03/19(金) 22:58:18.25ID:2/KUxY5q
html部分もxamlで書ける未来は来ますか？
2021/03/20(土) 00:24:36.28ID:pCJbHtqc
こない
2021/03/20(土) 00:51:40.10ID:N0CH58op
xhtmlが生き残っていたらそういう未来もあったんだろうなあ
2021/03/20(土) 08:51:30.66ID:pCJbHtqc
ない
2021/03/29(月) 22:08:00.80ID:FV93VuwM
reactっていうかJSXっぽいblazorが欲しい
MVVMは微妙だ
2021/05/17(月) 01:03:56.89ID:pKrWHb4H
うわーん
子コンポーネントに追加したCSSが適用されて
くれないよおおお
2021/05/17(月) 01:12:01.56ID:DJO6l4LT
へ？
2021/05/17(月) 06:43:56.79ID:CJj7zo9G
>>517
Ctrl + F5
2021/05/17(月) 10:47:38.82ID:pKrWHb4H
>>519
ちゃんとビルドはしてるんだけど
コンポーネント用に追加したCSSの内容が
反映されない
インテリセンスは効いてるし場所がおかしい
わけではないと思うんだけど
2021/05/17(月) 10:59:05.90ID:CJj7zo9G
>>520
ブラウザで表示中にCtrl+F5の意味だったんだけど。
cssはキャッシュされるから、クリアするか、強制再読み込みさせないと反映されない。
2021/05/17(月) 11:53:15.23ID:pKrWHb4H
>>521
やってみたけどダメっす
*.razor.cssを置くだけだよね？
2021/05/17(月) 11:58:38.84ID:pKrWHb4H
原因わかった
Layout.cshtmlに*.styles.cssを置いてなかった
ありがとう
2021/05/18(火) 10:26:38.81ID:6Jx3mCkU
動的にelementを作成し、IDを割り振っているのですが、IDから検索したelementに対してclassを追加/削除を行なう事はできますか？
jQueryだと $("#id名").addClass('class名') / $("#id名").removeClass('class名') とやれば出来ると思うのですが、できるだけJavaScriptは使いたくありません。
2021/05/18(火) 12:24:53.93ID:IKQP0yKv
なんでそんな罰ゲーやってんの？
526デフォルトの名無しさん
垢版 |
2021/05/19(水) 09:45:24.37ID:vAevRKi/
Blazorise とか DevExpress を使えば　もっと快適に開発できるのに何で
2021/05/19(水) 12:39:30.36ID:BIRmA78o
そもそも Blazor で Id 振る必要ってある？
@ref で大抵解決するんじゃ？
2021/05/19(水) 15:39:11.78ID:BIRmA78o
多分エラーチェックでエラー表示したいンだろうけど
バリデーションチェックでほとんど出来るし
いざとなればボタン押下時のチェックで
@refで定義したコントロールの
Cssをc#側で書き換えてやれば良い
2021/05/20(木) 00:14:09.50ID:rMZEEvKV
>>526
やり始めたばかりで、知識が足りないからです。
2つの単語をぐぐって調べてみます。

>>527,528
@refでElementReferenceの取得は出来ているのですが、ElementReferenceに対しての操作がわからないのです。
.NET5 から SetFocus が使えるようになったという程度の知識です。
CSSを書き換える具体的なコードをご教示していただけませんか？
2021/05/20(木) 03:45:22.57ID:hYXifQvY
DevExpress　は有償だけどお試しが出来る　Blazorise 無償でも使えたはず

DevExpress　の場合

Razor

<DxTextBox @bind-InputCssClass="@CssClass"></DxTextBox>


c#

string CssClass = "";

実行チェックで

CssClass = ????


ただし、入力チェックはフォームのバリデーションチェックのみが基本

実行時のエラーはエラーダイアログかアラートで表示
2021/05/20(木) 09:55:17.44ID:rMZEEvKV
>>530
ご教示ありがとうございます。
これまでVB.Netで、デスクトップばっかやってきたので、ASPとかウェブアプリとか手探り状態でやっているので
定番の方法をネットで調べながら悪戦苦闘しています。

アドバイスもありがとうございました。
2021/05/21(金) 13:30:50.82ID:3pnf2HoY
初めてのウェブアプリで.netはきついな
2021/05/26(水) 23:28:38.59ID:o92StIuL
初歩的な質問ですいません
Blazor Serverの勉強をしています

テンプレートのDataフォルダ以下に自分で作ったjsonファイルを配置しました
ページにこのjsonファイルの内容を読み出し、表示したいと考えています
HttpRequestMessage(HttpMethod Get, "ファイルパス")を使って、その後SendAsyncを呼び出すコードを書いたのですが「Sorry, there's nothing at this address.」と表示れファイルを認識していないようです
ブラウザにファイルパスを入力するとjsonファイルは表示されるのでパスが間違っているわけではなさそうです

読み出す方法自体が間違っているのでしょうか？
初歩的な内容で申し訳ありませんがアドバイス頂けたら幸いです
2021/05/28(金) 16:15:02.73ID:xaI11mjw
参考

https://www.syncfusion.com/faq/blazor/web-api/how-do-i-read-a-json-file-in-blazor-webassembly
2021/06/07(月) 16:17:45.72ID:Z0RJUhSU
Blazor Serverサイドで、自分自身の再起動って出来ますか？
起動時の設定を画面から行った際に、自動的に再起動できればうれしいんだけど・・・
2021/06/07(月) 16:24:10.54ID:wYqzuJ+k
自分自身の再起動？？
2021/06/07(月) 16:33:08.67ID:rkNZY3be
>>535
HttpRuntime.UnloadAppDomain
はどう？
2021/06/07(月) 16:39:01.06ID:rkNZY3be
>>537
あ、ASP.NET Coreでは非対応だった
2021/06/07(月) 17:12:25.16ID:wYqzuJ+k
IHostApplicationLifetime
2021/06/07(月) 18:22:24.87ID:nUdOwg5l
勉強に題材に出来そうなアプリないかな
気軽にこういうの作ってみようって思い浮かばないんだよな
2021/06/07(月) 18:24:24.42ID:jYDIVOJV
>>540
マイクロソフトが公開してるサンプルアプリ取得すれば
2021/06/14(月) 14:00:07.30ID:qkTbMiy1
DevExpressのお試しインストールして
AWSに　適当に作ったのアップすれば？
543デフォルトの名無しさん
垢版 |
2021/07/18(日) 14:10:32.49ID:9iW5ZKc1
.Net含めWeb周りもど素人なんだけど、
Blazor WASM 勉強中で教えてもらいたいんだが、

css変数でレイアウト制御しようと思ってて、
変数の環境汚染防ぐために属性セレクタでhtmlタグの末尾に自動追記されるコンポーネント毎にuniqueな属性？を指定したいんだけど、そんなプロパティある？

やっぱJS通して取得するしかないんかなぁ
そこまでするならやらない方が良いだろうし...
544デフォルトの名無しさん
垢版 |
2021/07/21(水) 15:37:46.74ID:xVY5rD/0
>>543
hoge.razor.css じゃダメなん？
2021/07/21(水) 17:52:24.05ID:VIIGeUce
Reactでok!
本家でもやってるし
546デフォルトの名無しさん
垢版 |
2021/07/22(木) 13:23:04.73ID:l3sHUd0A
>>544
VsCodeでCLI含め勉強してるんだが、
Razorファイル側でないと、コンパイル通らなくて変数読めなかったんだよなぁ
書き方が悪かったのか..?


>>545
JSのトレンドってその時々で変わるイメージだし、
JS食わず嫌いでBlazor始めたのに、JSライブラリの沼に浸かりたくない...
2021/07/22(木) 13:51:47.93ID:25FL4ybp
>>546
webやるのにjsはマストですよ
2021/07/22(木) 17:30:50.12ID:ISgGWg0R
>>547
現時点ではそうだね
今後も覇権は変わっていくだろうけど
549デフォルトの名無しさん
垢版 |
2021/07/22(木) 19:23:58.05ID:l3sHUd0A
WASM - ブラウザ間のラッパーとして使うなら未だしも、
ライブラリに依存しちゃうとその変更を追わなきゃいけないのがなぁ

⁇?「jQueryは嫌だ…」
⁇?「Vue.jsは嫌だ…！」
⁇?「Reactは嫌だっ！」
2021/07/22(木) 19:49:02.66ID:vwDpdZeF
jsライブラリは素のjsで書くとめんどくさいからライブラリを使ってる
c#オンリーで書いたとしたら素のjsで書いた時と同じことにぶち当たる

じゃあ結局ｊｓとts学んでライブラリ使ったほうがよくねと言うこと
blazorは普通に流行らないし使う人もほぼいないでフェードアウトする
2021/07/22(木) 20:11:52.16ID:vwDpdZeF
blazor向けに超絶便利なライブラリーをMSが作って普及させればワンチャンあるかもレベル

その場合でもHTMLとｃｓｓとjsの知識は必要
2021/07/22(木) 23:36:33.58ID:2i9Z6Xhw
webならjsがマストなのに
そこにコンパイル言語ぶっ込む真意はなに？
2021/07/23(金) 02:01:12.53ID:sECHlIz3
jsが糞言語だから
2021/07/23(金) 03:45:12.09ID:YZkweKMA
Blazorが流行るかどうかとWasmが流行るかどうかは全く別の問題だ。
結局、Wasm以外選択肢が無いのでWasmは流行るだろう。
2021/07/23(金) 03:52:06.77ID:YZkweKMA
nativeアプリよりずっとセキュアなのにnativeアプリと同じ言語で書けるという
点と、ググると即座に使えるという点が今後のアプリ開発をWasm化していく
原動力になることだろう。ググる方がデスクトップのアイコンを探すより速いし。
2021/07/23(金) 03:54:48.13ID:YZkweKMA
Wasmアプリは、今までのC/C++資産を全て受け継げるのに、nativeアプリより
遥かにセキュアになること、速度はnativeアプリと余り差がないこと、
1つ作るだけでWindows/Mac/iOS/Android/Linuxなど全てのOSで使えること、
などが非常に重要な点となる。
2021/07/23(金) 04:06:31.26ID:YZkweKMA
JSだと少なくともC/C++と比べるとどうしても遅くなるので、どうしても
C/C++製のnativeアプリに比べて不利になる。その意味でWasmの
ブラウザ上アプリはJSアプリに比べて有利。
2021/07/23(金) 13:08:29.55ID:YZkweKMA
ただし、それはC/C++をWasm化した場合であってBlazorには当てはまらないが。
2021/07/23(金) 14:10:39.28ID:Nx0yKcVz
結局は、便利なライブラリ・モジュールがあるかどうか。
ある機能の関数が欲しい時に、自作できないから

それで結局、Ruby on Rails みたいに、すべて揃っているものを使う。
さらに、デザインパターンも決まっているから考える必要がない
560デフォルトの名無しさん
垢版 |
2021/07/23(金) 16:18:02.69ID:LbRveJOa
>>559
それって楽しいか？
2021/07/24(土) 11:02:57.33ID:Bn7tmXAV
楽しくてやってるのか？個人でやる分にはいいが…
おれみたいにデスクトップアプリをWebアプリ化したいが、
チームにC#の経験者が多い、Typescriptの習得に時間を割けない
というネガティブな理由でBlazorを検討するやつは多いはずだ
2021/07/24(土) 13:35:26.86ID:8X55Gw1w
>>561
それが限定的で超短期的な避難措置ならわかるが
将来を見据えてみんなtsに移行したほうが絶対良い
時間を割けない経営側の判断がおかしいと思う

能力の限界が来て移行できない人はいらない人とまでは言わないがもうアプリレベルの開発はもういいかなと
Blazorって多分後2年持たないと思うのでそんなのを移行先にしてはいけない
2021/07/24(土) 13:44:25.48ID:1w6sRCas
tsってc#見たいで
もっと柔軟でc#じゃ出来ないような事も出来て
言語としておもろいですよ
2021/07/24(土) 13:49:24.79ID:8X55Gw1w
面白いけど基本的にjsの弱点を補うためにおかしな仕様になってる
型が柔軟になってて中で何度も型判定したり意味ねえよって思う
2021/07/24(土) 13:59:20.60ID:Py2hfFQF
voidとany　nullとundefined

特に受け付けないのが
hoge: string='';
if(hoge)がfalse

C#からの移行はかなり厳しいと思うｗ
2021/07/24(土) 14:00:13.27ID:8X55Gw1w
といいつつ今はそんなにts触らないので流れが全く分からない

tsの仕様の細かいところまで全部追えてる人間はそういないと思う
思い付きレベルにしか思えない機能を入れたり仕様変更したり忙しかったけど今も同じなのかは知らない
2021/07/24(土) 15:21:34.25ID:1w6sRCas
>>564
形無し言語も多い中で
贅沢言わんことだよ
2021/07/24(土) 15:24:29.17ID:1w6sRCas
>>565
ui記述言語として書きやすい仕様だが(>_<｡)v
569デフォルトの名無しさん
垢版 |
2021/08/22(日) 09:10:39.98ID:0Cz6ueFz
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴 バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412


Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます
2021/09/18(土) 15:36:06.25ID:ZtgFEKoc
ReactというかJSをしばらくやってるんだがC#の非同期に慣れてるとしんどいね
2021/09/24(金) 18:41:54.72ID:lFl/t56p
>>570
ほとんど同じじゃね？
2021/09/25(土) 01:28:16.45ID:h7oOvGYh
だね
2021/09/25(土) 09:44:48.46ID:utiZsGgV
キャンセルできない
ライブラリのasync対応が半端
AsyncEnumerableがない
2021/11/03(水) 13:43:09.57ID:EK9S3Of/
VS2022で何か変わりますか？
2022/04/19(火) 18:34:10.96ID:cFmOLae8
なんだこの過疎り具合…
他のASP.NETスレも動いてないみたいだしC#でWebしてる人はよほど少ないのね
2022/04/19(火) 18:54:16.41ID:ADHtQbAX
APIぐらいじゃね？
2022/04/19(火) 21:04:28.79ID:bkK/k49z
次期OfficeやVSCodeがBlazorHybridで作られたら考えるわ
578デフォルトの名無しさん
垢版 |
2022/04/22(金) 10:45:57.05ID:bV4j5CrE
ASP.NETって書籍もWebフォームばっかだな
579デフォルトの名無しさん
垢版 |
2022/04/26(火) 22:01:04.82ID:n5z2s5RV
もうすぐ.NET MAUIの正式リリースがくるってことで...
なんだかんだ.NETが理想的な形に近づいてきてるところ見るとわくわくするんだけれども。

世の中Google主導で、JavaScriptが人権みたいな流れになってるもんだからMicrosoftはこれからどうするんだろうと心配になる。

C#(Microsoft)対JavaScript(Google)な未来がみえるみえる
2022/04/27(水) 06:53:03.08ID:l66LauWY
>>579
JavascriptらMSがTypescriptで覇権を握っているように思うけど…
2022/04/27(水) 11:04:53.32ID:d8y38HAK
フロントエンドはTSで開発環境はVSCで
メインストリームだよ
2022/04/27(水) 12:42:11.57ID:0yTdFTVm
でもBlazorやMAUI、WinUIは流行る気がしない。
Reactのように企業が実際使っているフレームワークのほうが信頼度高いから。
2022/04/27(水) 12:44:51.74ID:uliHTCYs
特に日本記号は新しいもの使わないからな
584デフォルトの名無しさん
垢版 |
2022/05/01(日) 10:44:21.22ID:e5c16v3a
WinUIは特にWindows App SDKがまだまだ未完成状態だから流行る流行らない以前に普及できないよ

Microsoftはきちんと動くようになってから宣伝してほしい
585デフォルトの名無しさん
垢版 |
2022/05/03(火) 03:04:06.38ID:3JSewAq3
あのさ、ちょっとわいReactの経験無いから聞きたいんやけど、
Asp.netMVCでRazer使ってSSRしながら作ったらVisualStudioだけで全て完結してまるっと統一感でるとおもうんだけど
なんでフロントはReact、サーバーサイドはAsp.netって分けて作ってるところがそこそこあるの？

Razerだけで自作コントロール的なものからなにから用意できるからAsp.netだけで作ったほうが絶対にいいとおもうんだけど
2022/05/03(火) 06:37:39.20ID:FBRVO9ax
うちは
React + Asp.net Web API
2022/05/03(火) 08:01:49.35ID:r6X26HcZ
SPA作らないんならReactいらないんでないの
2022/05/04(水) 11:07:52.23ID:E45en6lm
>>585
ASP.net MVCではSSRと言わないはず。
SSRはSPA関連で使うワード

統一感ないのはほとんどのweb appは
フロントエンドとバックエンドで担当が分かれてるからでしょ。
言語を統一する必要があまりない。
言語の統一よりも、フロント、バックそれぞれのフレームワークの良いものを
選んだほうがいいってことかと。
動的言語をバックエンドで使ったら生産性も低いし性能も落ちる。
バックエンドやAPIをC#でやるのは理にかなってる。

フロントエンドはブラウザがJS縛りなのだからTSでやるのが合理的
BlazorならフロントもC#にできるがパフォーマンスが落ちる。
あとフロントエンドのひとたちはOOP、C#の理解できない人が多い。
データベースの知識も浅い。
フロントエンドしかできない人にはasp.net MVCは学習コストが高い。
2022/05/04(水) 11:12:21.42ID:E45en6lm
>>585
587も書いてるけど
まずSPAがいいのか、MVCのような従来型がいいのか、を考える必要ある。

SPAにもデメリットある。
なんでもかんでもSPAではだめ

SPA使わないとなるとASP.NET MVCは今でも最強フレームワークだと思う
SPA使わないとしてもAPIでASP.NET MVC使うのはぜんぜんいいと思うし

SPAである必要ぜんぜんないのにSPAでやってるサイトが増えてる感じはする。
戻るボタンつかえないクソサイトね
590デフォルトの名無しさん
垢版 |
2022/05/04(水) 16:05:04.80ID:xvnabw/l
>>588
なるほどなー
うちはフロントとバック別れてないからReact使うメリットがまったく分からなかったのか
たしかに分かれてたらフロント専門にやってるような人たちも混ざれるもんなー
でもさ、
ぶっちゃけさ、どっちも同じ人が担当したほうが結局のところ無駄な伝達とか無くてはやいよな
2022/05/04(水) 23:18:33.72ID:AJMM67e4
Ruby on Rails ではデフォルトで、Turbolinks のPjax で、History 履歴を管理する

Rails 7, Elixir のPhoenix 1.6 から、脱Webpack でesbuild へ

RailsのHotwire, PhoenixのLiveView で、
websocket による、JSON ではなく、HTML 片のリアルタイム通信。
脱JavaScript

ここ数年、SPA で、React に奪われたシェアを回復すべき戦略

他には、Bootstrap よりも、Tailwind が多くなってきた
2022/05/05(木) 00:54:03.75ID:cAbH/I31
>>591
日本語で頼む

ブラウザはJS縛りなのに脱JSとは？
フロントエンドのコードをRubyで書いてJSに変換できる技術ってこと？
593591
垢版 |
2022/05/05(木) 01:43:56.90ID:2L8NgwAH
JSON API を定義して、JavaScript(JS)・Ajax でやり取りする必要がなくなる

サーバー側で、HTML 片を作って送って、
受け取ったブラウザ側で、その部分を置換する

Rails + React + Bootstrap みたいに、2つのアプリが必要なくなった。
JSを受け取って処理する、部分が無くなった

この方法で、ここ数年SPA で、Reactに奪われたシェアを回復する
594591
垢版 |
2022/05/05(木) 01:58:11.05ID:2L8NgwAH
猫でもわかるHotwire入門 Turbo編
https
://zenn.dev/shita1112/books/cat-hotwire-turbo

たぶん、Ruby on Rails 7 のHotwire, Elixir のPhoenix 1.6 のLiveView も、
似たような感じなんだろう
2022/05/05(木) 07:25:39.82ID:zkLrQNmV
Blazor serverの類似技術ってことかいな
2022/05/05(木) 12:12:39.76ID:cAbH/I31
>>594
Thanks. 594のリンク先でHotwireの概要読んだ。
実際Hotwireで、どのくらい開発時間が削減できるのかは気になるわ

気になるところは、htmlのブロックをやりとりすることのデメリットだな
JSONでデータ渡すからこそ、PC, SPの両方でサーバーサイドを共通化できるってのが
メリットだったんじゃないのかね
Hotwireで部分的な更新はできるようになったけどクロスプラットフォーム対応はしにくいと思う。

web frameworkごとに内部の動きもぜんぜんちがうとか、
相変わらずweb appはカオスだな
転職のとき大変そう
597591
垢版 |
2022/05/05(木) 23:32:46.84ID:2L8NgwAH
KENTA

未経験からのエンジニア転職の必須教養【技術知識編】
https
://www.youtube.com/watch?v=Q1c09rrhTjo

転職・学習環境は、Ruby on Rails 1強

Railsチュートリアル・Rails Guide、
パーフェクト Ruby on Rails・黒田努の本などの、多くの教科書がある。
Dean などのYouTube 動画も多い

キャリアパスも、Rails → Go だけ
2022/05/06(金) 06:05:59.50ID:g661Ln4z
なんだKENTAの人か
解散
2022/05/06(金) 06:52:21.72ID:LpVwH58w
>>597
KENTAはレベル低いから動画みないほうがいいぞ
同じことばっかり言ってる。技術的に浅いからネタがない。
自分のコード、ほとんど晒してない。
2022/05/06(金) 07:02:04.16ID:LpVwH58w
>>597
あと教科書などいらない
ふつう、新しい技術学ぶのは英語。英語の情報をみたほうがはやい

Rubyは低速だから大手ITはRails捨てたところ多いし。
KENTAみたいに技術ないむかしの人がいまだにRubyとかRails推して
英語できない初心者がまたRails始めるという日本の悪循環
スクールもそんな感じ
情弱相手のビジネス
2022/06/10(金) 20:43:37.92ID:hbzVWYIX
DBなどへの接続文字列とかって実際の案件や現場でどーしてるんですか？
２，３方法があるみたいでも、なんか定番のこれって感じの記事も少ないし
そもそもサーバー上に配置したappsetting.jsonを見られてる時点で
鯖に侵入されててそれどこじゃないってことなんでしょうか？
602デフォルトの名無しさん
垢版 |
2022/09/26(月) 22:47:25.10ID:aC/L4xEl
Blazorでこれやっとけみたいな教本とかありますか？
ねこジョーカーさんのやつとか？
603デフォルトの名無しさん
垢版 |
2022/09/26(月) 22:49:15.04ID:aC/L4xEl
作りたいものはWikiみたいなDBと連動してボディの文字を修正したりコメント欄を追加したりしたい
2022/10/06(木) 08:17:39.29ID:+AsrxDle
DevExpress のサンプルでも見とけば？
2022/11/13(日) 15:46:36.25ID:kbkoXQBG
WEB開発はMacの人が多いから、まずはASP.NET CoreがMacでも開発できるよってことを
みんなに広める必要がある
2023/02/12(日) 20:28:01.91ID:IPWWwtwu
>>578
え(笑)
2023/05/29(月) 05:56:19.80ID:bhwRlPkq
ASP.netで作ったポートフォリオを転職時に提出したいのですが
PHPではレンタルサーバーを借りてアップロードしますが
ASP.netの場合は自身でサーバーを立てる必要があるのでしょうか？
2023/05/29(月) 08:50:20.39ID:/worGbVW
コードビハインドで取得したバイナリデータをJavaScriptの関数に渡したいんだけど、常套手段はありますか？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況