■ このスレッドは過去ログ倉庫に格納されています
Microsoft ASP.NET Blazor #02
- 1 ：デフォルトの名無しさん：2020/11/22(日) 05:30:30.13 ID:kDrPKY9d.net
- 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.65 ID:kDrPKY9d.net
- Blazor
Build client web apps with C#
https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
- 3 ：デフォルトの名無しさん：2020/11/22(日) 12:05:05.73 ID:ab9PVYBK.net
- アンチBlazorがVS、VSCodeの対立を煽り、スレを荒らしている可能性があります
内輪もめはやめて、Blazorについて有益な意見交換の場にしましょう
- 4 ：デフォルトの名無しさん：2020/11/22(日) 12:12:49.29 ID:vrdBpsCk.net
- Blazor Serverでもwasmでもいいんだけど
大規模になると1プロジェクト（wasmだと3プロジェクト）では収集がつかなくなるような気がしている。
例えば業務系だと100機能くらいあったりするわけだがその分Viewを作るのはまずいよな？
mvcはareaで分けているけど、あれも結局フォルダで分けてるだけだからなあ
複数のプロジェクトを跨いで開発、デプロイをするようなサンプルはないものか。
- 5 ：デフォルトの名無しさん：2020/11/22(日) 12:18:49.45 ID:kDrPKY9d.net
- >>1
ローカルルールひとつだけ追加
スレ立て時にワッチョイをつけるのは厳禁
理由1: 荒れるから。人物特定と人物叩きの話題が増えるため
理由2: ワッチョイはセキュリティ、プライバシー上の問題があるため
NGにしたい場合は各自で対応するように。
- 6 ：デフォルトの名無しさん：2020/11/22(日) 12:22:30.45 ID:dtkY0af3.net
- フォルダ分けでいいと思うけど
あでもビルド時間を短縮したいならプロジェクト分けたほうがいいのか
- 7 ：デフォルトの名無しさん：2020/11/22(日) 12:31:41.65 ID:kDrPKY9d.net
- >>4
ASP.NET MVCではファイルが増えがちなのは仕方ない。
そういうもの。
Razor PagesはMVCほどファイルが複雑にならないというのを
利点にあげていた。
ただ俺にはRazer Pagesは柔軟性のない欠点のが大きく見える。
コードビハインドで昔のWeb Formsっぽいというかね
- 8 ：デフォルトの名無しさん：2020/11/22(日) 12:58:15.06 ID:4i3C/72s.net
- >>7
いやMVCやPagesは一例でほんとに聞きたいのはBlazorのほうね
例えばBlazorSeverはDataフォルダのXXXServiceの数分Program.csでAddSingletonしてるが
あれも100Service作ったら100回するのか？
チームで開発してたらみんなProgram.cs触りまくることになるし
なんだか現実的ではないような。
そもそもServiceもどの単位でつくればいいんだろ。
モデルの数だけ？
- 9 ：デフォルトの名無しさん：2020/11/22(日) 12:59:40.95 ID:bLh5qcao.net
- ファイル増えるのが嫌なら自分でビューエンジンを作ればいい 大変だけど
頑張れば razor 使ったままで
ビューファイルをデータベースからロードして中身も構成し直すとかできるかも
- 10 ：デフォルトの名無しさん：2020/11/22(日) 13:03:24.97 ID:abaPzBFv.net
- >>8
Blazorとかあまり関係ないAsp.netの基本じゃないかそれ？
アセンブリ単位でのサービス登録、リフレクションを使ったサービス登録、サービス登録のサブモジュール化、などいくらでも手段はある
- 11 ：デフォルトの名無しさん：2020/11/22(日) 13:05:55.19 ID:bLh5qcao.net
- >>8
そういう場合ばかり普通別のファイルにメソッドなり新しいクラス作るなりして
そこにサービス追加するコード書くんじゃないの
- 12 ：デフォルトの名無しさん：2020/11/22(日) 13:12:52.05 ID:nWFJksTe.net
- >>3
どっちかというと、
Blazor基地外が他スレで暴れてるんだけどな。
それでこのスレに注目が集まってる。
- 13 ：デフォルトの名無しさん：2020/11/22(日) 13:17:15.75 ID:vrdBpsCk.net
- >>10
そうなのか
知識不足ですまん
じゃあServiceはカテゴリごとに別プロジェクトで作成して
そのdllをAddSingletonしたらいいのかな
- 14 ：デフォルトの名無しさん：2020/11/22(日) 13:21:22.95 ID:vrdBpsCk.net
- なんとなくカテゴリごとにBlazorServerのプロジェクト作るのかなと思ってたんだが
まとめてIISなりにデプロイする方法がわからんかった。
- 15 ：デフォルトの名無しさん：2020/11/22(日) 13:33:44.46 ID:abaPzBFv.net
- >>13
やり方は色々ある
うちのやり方だとまずステレオタイプで分けて、ジェネリック型の登録、リフレクションで登録、個別に登録と段階分けてして登録してる
で、それをIServiceCollectionの拡張メソッドでラップしてUseXxx(オプション)の形式で公開
- 16 ：デフォルトの名無しさん：2020/11/22(日) 13:51:05.25 ID:vrdBpsCk.net
- >>15
なるほど
サンプルくれ
- 17 ：デフォルトの名無しさん：2020/11/22(日) 14:01:22.68 ID:bLh5qcao.net
- .NET Core で作られてるオープンソースのCMSがあるから
そのソース見ればいいと思う
- 18 ：デフォルトの名無しさん：2020/11/22(日) 14:15:18.33 ID:ujQ9d+0r.net
- ここ見る限り簡単さで売ってるフレームワークじゃないみたいだな。
他の探すわ。
- 19 ：デフォルトの名無しさん：2020/11/22(日) 14:28:03.57 ID:vrdBpsCk.net
- >>17
ありがとう
探してみる
- 20 ：デフォルトの名無しさん：2020/11/22(日) 14:42:21.15 ID:abaPzBFv.net
- >>18
Reactより単純だよ
- 21 ：デフォルトの名無しさん：2020/11/22(日) 17:58:24.06 ID:NUTvM1Lb.net
- 純粋にBlazorの話がしたい人はこちらに移動してくださいね
【本命】Blazor スレ2【真打】
https://mevius.5ch.net/test/read.cgi/tech/1606028377/
- 22 ：デフォルトの名無しさん：2020/11/23(月) 02:43:30.92 ID:WFPhqmL6.net
- >>21
のスレはスタンドアロンでBlazorを使う場合のみのスレ
ここはASP.NETがバックエンドに絡む場合にもOKのスレ
- 23 ：デフォルトの名無しさん：2020/11/23(月) 07:21:58.63 ID:con/o1/6.net
- スタンドアローンでBlazor使うのってどういうケースなんだ？
ゲーム？
あ、電卓か。
- 24 ：デフォルトの名無しさん：2020/11/23(月) 08:37:48.72 ID:UgGRFwp8.net
- >>22
いやいやBlazorだってASP.NETの中のピースなのでその理論はおかしい
- 25 ：デフォルトの名無しさん：2020/11/23(月) 08:51:36.23 ID:WFPhqmL6.net
- >>23
データを全部ローカルに持ってるアプリ
サーバーレスで使えるゲームとかもそうだな
>>24
真打スレの1が頭おかしいからしょうがない
ASP.NET野郎とか言い出してASP.NETの話題を極度に嫌ってる
難癖としかいいようがない
単純にポエムっぽい気持ち悪いテンプレ1を変更されてキレてるんだろう
- 26 ：デフォルトの名無しさん：2020/11/23(月) 08:55:59.65 ID:WFPhqmL6.net
- >>1
誤解のないようこちらにも書いておくけど
前スレと扱ってるテーマは何も変えてない。
本命、真打とかいういらないスレタイのワードを消して検索にかかりやすくした
気持ち悪いポエム系テンプレをなくした
これだけ。改善しかしてない
- 27 ：デフォルトの名無しさん：2020/11/24(火) 00:14:25.35 ID:EBaS3Lgi.net
- あっちの>>1はいろいろとあたまおかしい
せっかくだからあっちから出てこないでもらいたい
- 28 ：デフォルトの名無しさん：2020/11/24(火) 20:21:06.22 ID:VvBbDMQG.net
- BlazorはASP.NETと関連性が高いしASP.NETの話題が出るのは避けられない。
こっちは前スレの実態どおりに、ふつうに使っていきましょう
- 29 ：デフォルトの名無しさん：2020/11/25(水) 18:39:02.03 ID:zFotDvmS.net
- asp.net mvcとblazorを混ぜこぜにすることってできるんだろうか
asp.net mvcで作ったアプリを全部blazorに変更する必要はないんだが
一機能だけ複雑怪奇なUIなのでBlazorで作りたい
- 30 ：デフォルトの名無しさん：2020/11/25(水) 19:11:12.24 ID:89i//6R1.net
- >>29
できるよ
- 31 ：デフォルトの名無しさん：2020/11/25(水) 20:21:13.57 ID:imttWao4.net
- >>29
どっちのBlazor？？
複雑なUIはXamarin.Formsが最適解だとおもうわ
速いし、開発も楽
- 32 ：デフォルトの名無しさん：2020/11/25(水) 20:44:21.95 ID:zFotDvmS.net
- いやすでにMVCのWEBアプリで出来てるのにいきなりその機能だけザマリンになったら困る…
- 33 ：デフォルトの名無しさん：2020/11/25(水) 20:44:45.21 ID:zFotDvmS.net
- あ、BlazorServerかな…
楽な方でいいんだけど
- 34 ：デフォルトの名無しさん：2020/11/26(木) 01:20:30.80 ID:OS71rNiZ.net
- つーか、前スレからxamarin推しのアホが居着いてるけどいい加減控えろって
- 35 ：デフォルトの名無しさん：2020/11/26(木) 01:49:05.56 ID:O9/RzT4k.net
- ASP.NETの話題禁止のクソスレに書き込んでしまいました
VPSを借りて、Linux上にasp.net core(?)をインストールすれば、BlazorServer
が普通に使える様になるのでしょうか？
- 36 ：デフォルトの名無しさん：2020/11/26(木) 03:24:06.62 ID:+DwRTiUz.net
- >>34
良いものを勧めて何が悪い
nativeなら別にXamarinじゃなくてもいいが、
ここはMSの技術のスレだから俺なりに配慮してMSのXamarinを書いている
Blasor Wasmが現時点でムリゲーなのは触ればわかる
- 37 ：デフォルトの名無しさん：2020/11/26(木) 03:33:19.75 ID:+DwRTiUz.net
- >>35
用途と規模、同時接続数は？
ASP.NETの話題禁止のクソスレではレンタルサーバーとか
VPSとか勧めてた人いたけどよっぽど小規模じゃないとアウトだと思う
Blazor Serverはserver-sideで多くの仕事するから
スペックがしょぼい共用のServerは適さない。
専用にハード用意してでオンプレミスか、
その運用ができないならAzure使ったらいいと思う。
- 38 ：デフォルトの名無しさん：2020/11/26(木) 08:20:06.17 ID:a2VDJR7j.net
- >>36
その前にザマリンってブラウザ上で動いたっけ…
>>37
企業内でしか使わない、同時接続はせいぜい100くらいかな
この手の使い方ならBlazorSever一択な気がする
wasmはServerが選択できないようなシチュエーション、不特定多数が使うゲームとかで使う感じ
しかしBlazorServerってパフォーマンスについてはほんとに未知数。
作ってみて全然ダメなんてなったら総スカンだよ
だれかややこしい画面100機能くらい作って実験してみてくれ。
後世まで讃えられるよ。
- 39 ：デフォルトの名無しさん：2020/11/26(木) 12:21:32.51 ID:OS71rNiZ.net
- ザマリン野郎はただのハッタリ詐欺師よ
どこかの派遣先でちょろっと触った事がある程度の経験しか無い癖に、さも分かってるかのように騙る馬鹿
- 40 ：デフォルトの名無しさん：2020/11/26(木) 12:55:56.37 ID:a2VDJR7j.net
- ザマ郎め…
- 41 ：デフォルトの名無しさん：2020/11/26(木) 13:10:39.86 ID:+DwRTiUz.net
- >>38
nativeはブラウザで動かないからこそいい。
ブラウザの悪いところの制約をうけない。
CSSとhtmlでUIつくるする必要ないから生産性高くて動作もはやい
XamarinならJSだけでなく、めんどくさいCSSとhtmlも意識しなくてよくなる
- 42 ：デフォルトの名無しさん：2020/11/26(木) 14:47:34.74 ID:a2VDJR7j.net
- >>41
いやブラウザ上で動かすと言うのが要件です
- 43 ：デフォルトの名無しさん：2020/11/28(土) 21:32:26.57 ID:VVrnAQDV.net
- エセザマ野郎が本家Xamarinスレで暴れて鬱陶しいんで、きちんとここに隔離拘束しといて！
- 44 ：デフォルトの名無しさん：2020/11/29(日) 12:22:21.90 ID:t4883+oA.net
- ザマ郎め…
- 45 ：デフォルトの名無しさん：2020/12/01(火) 16:13:35.40 ID:KJeyTCS5.net
- Blazorwasmって、ローカルで動かしてみたり、認証のいらないアプリを書いたりするには良いけどさ
認証を入れて安物VPSに配置すると、Pingが高いせいかめちゃくちゃ遅くなっちゃうのな
Azureを契約したら認証を使ってもまともなスピードで動くのか気になるところなんだけど、どっかで体験できるサイトってないかな？
- 46 ：デフォルトの名無しさん：2020/12/01(火) 16:55:46.55 ID:TBput4Ui.net
- 認証の実装次第じゃね？
- 47 ：デフォルトの名無しさん：2020/12/01(火) 17:08:37.83 ID:mXq+MLFh.net
- >>45
azureのfreeプランで体験すればいいんじゃないの
- 48 ：デフォルトの名無しさん：2020/12/01(火) 17:11:08.20 ID:EvEZBXUJ.net
- >>45-46
認証どの方法でやってるの？認証というかDBがクソ遅いんでは？
ストレージと契約プランは？
自分の固定回線でサーバー立ててオンプレミスでパフォーマンス
見てみればいい。
モバイル回線からアクセスとかして実際のローディングの実感つかんだり。
VPSとかレンタルサーバーとかスペックがとにかくしょぼい
維持費下げて快適なサーバー作るにはオンプレミスでやるべき
- 49 ：デフォルトの名無しさん：2020/12/01(火) 17:13:55.57 ID:EvEZBXUJ.net
- オンプレミスなら占有できるし、ストレージもSSDとか使える。
安いVPSとかいまだにHDDだったりとにかくスペックがゴミだぞ
大手クラウドはましだけど維持費高い
- 50 ：デフォルトの名無しさん：2020/12/01(火) 18:48:51.15 ID:WP+WGTcn.net
- 誰かと共有してるサーバーなんて、
誰かの処理が多かったら、自分の処理は少なくなる
特に安い所は、共有者が多いかも
- 51 ：デフォルトの名無しさん：2020/12/01(火) 19:18:59.55 ID:mXq+MLFh.net
- AWSのlargeインスタンスに本番デプロイしてるけど特に問題なしだな
- 52 ：デフォルトの名無しさん：2020/12/01(火) 19:36:41.77 ID:+qF/uZ2f.net
- >>45
webassemblyはローカルで動くんだから
VPSは関係ないでしょ
関係あるとしたら必要以上に通信してるとか
設計の問題でしょ
- 53 ：デフォルトの名無しさん：2020/12/01(火) 21:47:54.47 ID:EvEZBXUJ.net
- >>52
関係あるに決まってるだろう
最初のローディングはサーバーからのダウンロードだし
認証やるならDBの速度にひっかかる。
スタンドアロンで完結するアプリなんてほとんどない
- 54 ：デフォルトの名無しさん：2020/12/02(水) 00:16:56.71 ID:3xGcwmKY.net
- もしかしてクライアントからDB直接アクセスしてんのか
- 55 ：デフォルトの名無しさん：2020/12/02(水) 00:53:22.98 ID:EgVjsFYE.net
- 認証使ってるのか書かれてないから不明だが認証は通常DBを使うし
安いVPSだとApplication Serverと同一のhostにDBもあるし、
たくさんのユーザーが同時使用するから遅い。
共有サーバーでストレージがHDDだとすごく遅くなるのは明らか
- 56 ：デフォルトの名無しさん：2020/12/02(水) 01:11:28.10 ID:YoQmKH+u.net
- 認証のDBアクセスが重いとか、どんだけ高負荷な有名サービスだよ
- 57 ：デフォルトの名無しさん：2020/12/02(水) 02:35:00.10 ID:ZTMuPDF1.net
- >>56
それは思った。
そんなサイトは世界でも100も無いのではないかと思うのだが。
- 58 ：デフォルトの名無しさん：2020/12/02(水) 06:18:58.14 ID:EgVjsFYE.net
- >>56-57
web appで一番ボトルネックになるのは
RDBってのは昔からふつうのことだぞ
だからこそRubyやJSなど低速な言語のサイトもけっこうある。
ボトルネックが言語よりもDBになることが多いからだ
あと通常、認証後にもリソースの権限チェックが行われる。
トークンベースだったとしてもそこの計算量が多くCPUにも負担がかかる。
DBが高負荷のときはCPUリソースも余裕がない可能性高い
- 59 ：デフォルトの名無しさん：2020/12/02(水) 06:22:57.09 ID:EgVjsFYE.net
- >>56-57
どんだけ有名サービスだよってことじゃなくて、
レンタルサーバー、VPSがどんだけ詰め込んでんだよって話
限界まで詰め込みすぎなわけ
共用サーバーは膨大な数のWordPressとかが動いてる
同一サーバーの契約者数、アクセス数が多いから
自サイトのアクセス数の絶対数が少なくても性能が足りなくなる。
オンプレミスにするかまともなクラウドを使えばいい
- 60 ：デフォルトの名無しさん：2020/12/02(水) 08:22:53.00 ID:+nSH4YQS.net
- Blazor Serverの仕組みって一般的にはなんと呼ばれる技術なのか分かる人いますか
SignalRでSPAを実現してるやり方って他の言語やフレームワークにもある？
MS系に詳しくない人たちに説明したい。
- 61 ：デフォルトの名無しさん：2020/12/02(水) 10:29:09.09 ID:yJY81L7A.net
- サーバー不要の方式がSPA
- 62 ：デフォルトの名無しさん：2020/12/02(水) 11:01:43.03 ID:EgVjsFYE.net
- >>60
エンジニア向けの説明？
MS技術に詳しくない人ならSignalRも知らないはず
類似のSPA技術はないだろう。
ほかのframeworkはなるべくステートレスにやろうとするが
Blazor Serverはステートフルでサーバーが多くの仕事をする。
しかもJSを書かない
- 63 ：デフォルトの名無しさん：2020/12/02(水) 12:25:38.82 ID:+nSH4YQS.net
- 古くなったWebFormの移行先の技術選定で、社内のお偉方に説明する必要がある。
Serverの方は既存コードから再利用性が高そうだから使ってみようと思ったが
こんな技術が身についても潰しが効かないし、若手が嫌がりそう。
wasmも使い物にならんし
ts+Reactとかに思い切って移行するほうがいいのかもしれないと俺は思い始めた。
- 64 ：デフォルトの名無しさん：2020/12/02(水) 12:31:47.85 ID:yJY81L7A.net
- 既存のクソコードを一掃する
チャンスでもあるわけだ。
- 65 ：デフォルトの名無しさん：2020/12/02(水) 12:35:05.78 ID:4ZukVyfA.net
- >>63
BlazorとWebFormsは全然違うからダイレクトに移行するメリットはないよ
WebFormsをリファクタリングしてAspNet Core Webapi+WebFormsの形に落とし込む
その後WebFormsを好きなフレームワーク乗せ変える
移行先のフレームワークとしてBlazorを選んでもいい
これが移行の王道
- 66 ：デフォルトの名無しさん：2020/12/02(水) 12:49:23.65 ID:+nSH4YQS.net
- >>65
なるほどなあ
しかしwebapiの設計がまじでわからん
みんな本当にget,put,post,deleteのRESTの原則に従って作ってるのだろうか。
バッチ処理とかどうしてるんだろう
- 67 ：デフォルトの名無しさん：2020/12/02(水) 12:53:18.42 ID:yJY81L7A.net
- >>66
大分まえから普通がRESTよ。
つい最近もオレオレREST？API作ってきたベンダーが集中砲火。
- 68 ：デフォルトの名無しさん：2020/12/02(水) 13:54:47.31 ID:vDg6xkSY.net
- REST, GraphQL とか
バッチ処理は、AWS Batch, Lambda とか
- 69 ：デフォルトの名無しさん：2020/12/02(水) 14:00:38.77 ID:EgVjsFYE.net
- >>63
思い切って移行ならXamarin.Forms
速くて使いやすくて喜ばれる
スマートフォンアプリ作れるようになるしエンジニア教育の
面でもベストだわ
少し待ってMAUIでもいいとおもうが。
>>65
AspNet Core Webapi+WebForms
はいったんレガシーとミックスさせる方法だから、
無駄にコストと手間かかりすぎだと思うわ
新規で作って切り替えるほうが楽だし現実的
- 70 ：デフォルトの名無しさん：2020/12/02(水) 14:02:40.02 ID:7ARpvJUU.net
- Visual Studio使ったら難しいこと考えなくてもC#でREST API生成できるやん
- 71 ：デフォルトの名無しさん：2020/12/02(水) 14:03:35.26 ID:7ARpvJUU.net
- Xamarin野郎来たからBlazor本スレに戻るわ
- 72 ：デフォルトの名無しさん：2020/12/02(水) 14:09:13.66 ID:EgVjsFYE.net
- >>71
新しいことを学べない人には無理だろうな
Xamarin.Formsという言葉だけで拒絶反応を示す
スタンドアロンスレに戻りなｗ
- 73 ：デフォルトの名無しさん：2020/12/02(水) 14:28:48.10 ID:u23z8tnt.net
- あ、知識・スキル共に皆無なことが露呈してXamarin本スレから逃げ出した人や
こいつこんな所におったんか
- 74 ：デフォルトの名無しさん：2020/12/02(水) 15:32:11.71 ID:3xGcwmKY.net
- >>66
今どきRESTだけなんて無いよ
クエリスタックはRESTとGlaphQLの組み合わせ
コマンドスタックはgRPC
これが今のスタンダード
- 75 ：デフォルトの名無しさん：2020/12/02(水) 16:08:55.57 ID:yJY81L7A.net
- >>74
gRPCが今のスタンダード？
笑
- 76 ：デフォルトの名無しさん：2020/12/02(水) 16:10:32.50 ID:u23z8tnt.net
- MagicOnionマジおすすめ
- 77 ：デフォルトの名無しさん：2020/12/02(水) 18:02:17.85 ID:+nSH4YQS.net
- 昔SOAPを使っていたのもあって
なかなかREST APIに馴染めない
に加えてあのURIを文字列で記述するのが嫌
クエリパラメータも文字列なのが嫌
スペルミスしてたら動かないとかつらすぎる。
（あんまり使ったことないから間違ったこと書いてたすまん）
せっかく同じC#なんだから型安全がいい
おそらく自分にはgRpcの方が馴染みそう
しかし一番馴染むのはBlazorServerのXXXService()
あんな楽なものはない。
だからBlazorServerが魅力的なんだよおおおお
惜しい
- 78 ：デフォルトの名無しさん：2020/12/02(水) 19:39:41.09 ID:3xGcwmKY.net
- >>75
そだよ
コマンドスタックは現状これしかない
- 79 ：デフォルトの名無しさん：2020/12/02(水) 19:44:30.50 ID:yJY81L7A.net
- >>78
スタンダードの意味は？
- 80 ：デフォルトの名無しさん：2020/12/08(火) 10:45:05.78 ID:p9ADjhn4.net
- 何をやっているか知りたいので空のプロジェクトから解説しているサイトないですか？
dotnet new web
- 81 ：デフォルトの名無しさん：2020/12/08(火) 16:14:08.34 ID:11kT5JjZ.net
- >>80
？
dotnet new webっていうコマンドが
なにをやっているか知りたいってこと？
- 82 ：デフォルトの名無しさん：2020/12/08(火) 16:23:50.99 ID:aYlokb/a.net
- >>81
もんもー？
dotnet new web後の流れが知りたいってことでしょ
- 83 ：デフォルトの名無しさん：2020/12/08(火) 16:43:22.34 ID:C+tXhbuq.net
- 本ならあった気がするがサイトは知らんな
- 84 ：デフォルトの名無しさん：2020/12/08(火) 16:45:34.63 ID:v7gdDVm9.net
- スレチ
- 85 ：デフォルトの名無しさん：2020/12/08(火) 17:11:29.09 ID:E4wQPgos.net
- 文もう
- 86 ：デフォルトの名無しさん：2020/12/08(火) 18:21:19.48 ID:11kT5JjZ.net
- >>82
それってテンプレートから作ったものを
読めばいいんじゃね
- 87 ：デフォルトの名無しさん：2020/12/09(水) 10:00:37.08 ID:R4W4bNd2.net
- >>80
>1-2 のテンプレートに書いてあるだろう
まずはMicrosoftのドキュメントに目を通す
- 88 ：デフォルトの名無しさん：2020/12/18(金) 07:21:07.35 ID:5JOKzxNw.net
- この技術に限らずMSの出してくるフレームワークに手を出しづらい理由
MS自身が使ってないからなんだよな…
ブラウザ上でうごくExcelをBlazorで作ってるんなら安心するんだが。
- 89 ：デフォルトの名無しさん：2020/12/18(金) 09:13:03.15 ID:AKVGlWuS.net
- >>88
wasmの話だろうと仮定。
そんな無駄な移植しても意味ないし当然だろう
Excelはweb appとnative appで存在するのに
中途半端なBlazor Wasmで作る意味がない。
Excelに限らない話かもしれない
このままweb appとnative appだけが続き
wasmが普及しない未来はありうる。
- 90 ：デフォルトの名無しさん：2020/12/18(金) 09:16:42.38 ID:mc4Y4fQo.net
- pythonが動き出すと話は全く変わってくる
- 91 ：デフォルトの名無しさん：2020/12/18(金) 19:18:46.90 ID:WIChbQFJ.net
- >>89
NativeにしてもWPFやXamarinでは作ってないよね
たしかReactNativeだったかな
技術的な意味がなくても移行をあえてやってみて
Officeで使われた技術です！
って宣伝するだけでその技術への信頼度上がるとおもうんだけどなー
- 92 ：デフォルトの名無しさん：2020/12/18(金) 20:08:20.82 ID:AKVGlWuS.net
- >>91
SPのExcelはReact Nativeなの？
Xamarinじゃなくて？
MSが使ってるかどうかよりも
MSと資本関係ののない多くの会社が使ってるかの方が信頼できるな
MSが使ってても宣伝やしがらみのためだと思われることもある
- 93 ：デフォルトの名無しさん：2020/12/18(金) 20:12:21.48 ID:AKVGlWuS.net
- >>90
Pythonはスクリプトだから遅いし大規模にも向かない。
TSとおなじく、MSのnative appやASP.NETでは
使えない状態のままだとおもう。
主力はC#
PythonはAIとか強いからMSとしてその分野の強化かと
- 94 ：デフォルトの名無しさん：2020/12/18(金) 20:22:53.83 ID:UPU6Cu+L.net
- 愛の不時着いいよね〜ｗ
見たことないけど。
- 95 ：デフォルトの名無しさん：2020/12/18(金) 20:38:35.56 ID:WIChbQFJ.net
- >>92
SPがなにかわからんけど
クロスプラットフォームかということでReactNative使ってるんだと。
https://www.softantenna.com/wp/software/office-in-javascript/
- 96 ：デフォルトの名無しさん：2020/12/18(金) 20:45:25.39 ID:4UaQE5Dn.net
- >>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
続く
- 97 ：デフォルトの名無しさん：2020/12/18(金) 20:45:59.21 ID:4UaQE5Dn.net
- >>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を使うてますねｗ
- 98 ：デフォルトの名無しさん：2020/12/18(金) 21:29:16.49 ID:WIChbQFJ.net
- 日本の企業にありがちな
他部署が作ったオレオレフレームワークが他の部署では使われないみたいなやつ。
- 99 ：デフォルトの名無しさん：2020/12/18(金) 22:05:46.36 ID:AKVGlWuS.net
- >>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が上位
- 100 ：デフォルトの名無しさん：2020/12/18(金) 22:11:56.09 ID:+Wrhvh6s.net
- YouTubeがxamarin？見間違いじゃねえか？
- 101 ：デフォルトの名無しさん：2020/12/18(金) 22:27:08.65 ID:WIChbQFJ.net
- Nativeは置いといて
ブラウザ上で動かすExcelのような複雑なUIのアプリは、jsよりWebAssemblyのほうが向いてると思うんだが。
それでも作り直すメリットがないのであれば
逆にWasmは何に使うのが正解なんだ…？
ゲームのみ？
CRUD中心の企業向けアプリなんてwasm選ぶ必要なくね？
BlazorServerの方が生産性高いし。
- 102 ：デフォルトの名無しさん：2020/12/18(金) 23:52:57.38 ID:Lq+ZSFwA.net
- >>93
全てのアプリが速さを追求するわけじゃない
大規模なアプリも小規模なアプリもある
Pythonの膨大なライブラリがブラウザで動くことが重要
- 103 ：デフォルトの名無しさん：2020/12/18(金) 23:57:26.29 ID:Lq+ZSFwA.net
- >>101
新規サービスはBlazor一択
VS、C#自体の高生産性、バックエンドとフロントエンドが同じ言語で書けるメリットは大きい
速度も比較すると今はまだ遅いけど、体感ではどんぐりの背比べ、ぜんぜん問題ない
デバッグはまだやりにくいが、テスト書けばいいだけ
- 104 ：デフォルトの名無しさん：2020/12/18(金) 23:59:15.50 ID:Lq+ZSFwA.net
- >>101
Excelとか既存の大規模アプリは移植のコストが割に合わない
- 105 ：デフォルトの名無しさん：2020/12/19(土) 00:08:47.12 ID:x1EY5aRu.net
- つまり遅くてデバッグもしにくくて使い物にならない、と。
- 106 ：デフォルトの名無しさん：2020/12/19(土) 00:25:06.52 ID:8bUfeulY.net
- >>105
問題ないと言ってる
- 107 ：デフォルトの名無しさん：2020/12/19(土) 00:25:30.46 ID:pyDV0l6z.net
- >>102
AIでPython使うなら速度は大事。
PythonのライブラリはCを多用してるようだし。
スクリプトだと開発生産性も落ちる
Blazor wasmだと現状まともなデバッグできないからさらに生産性落ちる。
- 108 ：デフォルトの名無しさん：2020/12/19(土) 00:30:54.14 ID:KJkGIAX1.net
- >>89
ちゅうか、Blazor Wasmが駄目だからと言ってWasm自体の問題と混同しては
いけない。なぜなら、JS以外でWebページやWebアプリを作りたい需要は
とても多いはずなので、そのためにはWasmしか選択肢が無いから。
Wasmはプログラマが使う言語ではなく裏方で動くマシン語なのでWasmが
仮にどんなに使いにくくても、プログラマが使う言語にはほとんど影響しない。
- 109 ：デフォルトの名無しさん：2020/12/19(土) 00:31:30.10 ID:pyDV0l6z.net
- >>101
＞CRUD中心の企業向けアプリなんてwasm選ぶ必要なくね？
これはそのとおりだがそもそもSEO必要ないならweb appの必要がない。
なんでもブラウザでやろうとするのは思考停止。
native appのほうが生産性も高いし、速度も速いし使いやすい。
wasmよりもMAUI, Flutter, Xamarinなどnativeのほうが流行る可能性が大きい。
Blazor WasmについてはJS interopが遅いという問題もあるし
それとデバッグが解決するまで俺は静観ですわ
- 110 ：デフォルトの名無しさん：2020/12/19(土) 00:40:03.17 ID:pyDV0l6z.net
- >>108
そうはいっても
Blazor 以外のWasmがほとんど使われてないからな
一方でnativeは廃れる気配はない。
Swift, Kotlinでnative appの学習する分には無駄になることはほぼない。
MAUIが流行ったとしてもGoogle/Apple純正ツール開発と
Kotlin, Swiftの知識が役に立つ
- 111 ：デフォルトの名無しさん：2020/12/19(土) 00:43:46.76 ID:H4M2BfyN.net
- BlazorServerはいらない子なのか？
- 112 ：デフォルトの名無しさん：2020/12/19(土) 00:43:58.13 ID:avFHhi1d.net
- ザマ爺、本命Blazorスレでボコられたからって今さらこっち戻ってくんなよハゲ
- 113 ：デフォルトの名無しさん：2020/12/19(土) 00:50:09.15 ID:KJkGIAX1.net
- >>110
FlutterやXamarine, MAUI, Qtなどと比べてWasmの優位性は、
実行形式が1つしか要らないのでビルドが速く、開発時のバックアップや
バージョン管理が楽と言うこと。
前者でAjail開発を行おうとすると、僅かに修正するたびに全てのターゲット
について再コンパイルして毎回テストしなくてはならない。
iOS/Android/Windows/Mac/Linux用に作る場合、5回、
64BIT版と32BIT版の両方が必要な場合、10回。
これだと開発に時間がかかってしょうがない。
一方、Wasmだと一回ビルドすればよいだけだしテストも1回でもなんとかなる
場合が多い。テストが省略できる理由は、ブラウザ自体がHTML5によって
プラットフォーム間の互換性を維持してくれているため。
- 114 ：デフォルトの名無しさん：2020/12/19(土) 00:51:22.44 ID:1ZOkfUtM.net
- >>109
配布やらバイナリの管理やらに手間がかかるから
社内向けのシステムでもデスクトップアプリの応答性能が必要なければWebアプリ使うほうが主流やぞ
- 115 ：デフォルトの名無しさん：2020/12/19(土) 00:54:22.75 ID:KJkGIAX1.net
- >>113
最近、実行形式のサイズが大きくなって、ターゲットプラットフォームが多くなると、
バックアップに時間と容量を必要とする様になってしまった。
差分や増分バックアップでは途中のバージョンの欠損ですべてが失われる危険がある
のでやはり単純コピーしたいが、そうなるとプラットフォーム毎に実行形式が
異なっていることは非常に大問題となる。
その点、Wasmだとあらゆるプラットフォームで実行形式が単一しか要らなくなる
のでバックアップの時間もストレージの消費も少なくなって便利。
もちろんビルド時間も大いに節約でき、生産性も上がる。
- 116 ：デフォルトの名無しさん：2020/12/19(土) 00:58:02.14 ID:KJkGIAX1.net
- >>115
最近驚いたのが、VS2019ではMFCの(Debug,Releaseなどの)ビルドディレクトリ
のサイズが1GB程度に膨れ上がってしまっていることだ。
こんなもの、バックアップをどうしろというのだ。
コピーするだけで大変な無駄な時間が要る。
- 117 ：デフォルトの名無しさん：2020/12/19(土) 00:58:22.58 ID:8bUfeulY.net
- >>107
学習は別にすればいい
AIも使うだけならそこまでではない
そして仮にAIが駄目だったとしてもそれでpythonの全ての価値を失うわけではない
AIはpythonの極一部の用途でしかない
スクリプトとC#を比べたらC#が勝つのは当たり前
しかしpythonには豊富なパッケージがある
pythonがブラウザで動くならそれは大きな価値がある
デバッグをする必要はない
やるべきことはテストコードを書くこと
テストコードを書けば自然とデバッグをする機会も減る
これはBlazorがどうのこうの以前の問題
テストツールがこれだけ充実してる時代にまだデバッグしてるんですか？
- 118 ：デフォルトの名無しさん：2020/12/19(土) 01:01:33.63 ID:pyDV0l6z.net
- >>113
技術的に可能だからといって全部対応する必要はない
web appでIEを切るのと同じようにnativeでMacやLinuxは切る
Linux desktopなんて無視でいい。シェアがない。
Macもシェア小さいので無視。会社でMac無しはふつう
64bitで動けば32bitも普通まずそのまま動く
法人で使うならWindows10 64bitとAndroidとiOSだけで十分
WindowsとSPどちらか片方でもいい
- 119 ：デフォルトの名無しさん：2020/12/19(土) 01:05:15.02 ID:pyDV0l6z.net
- >>114
deployガーっていうのはもうやめてくれ
それは管理者、開発者が無能なだけだ
クリック押すだけのインストーラーつくってもいいし
システム管理ツールでdeployしてもいい。
アプリ開始時にバージョン通知するようにしとけば、
各自のバージョンも把握して強制アップデートもできる。
そういうアイデアがないひとがdeployが、と騒ぐ。
- 120 ：デフォルトの名無しさん：2020/12/19(土) 01:07:02.04 ID:KJkGIAX1.net
- >>118
まあ、言ってることはわかるが、Ajail開発では、テストを小まめにすることが
重要とされる。
例えば、64BITだけでビルドとテストをしつづけて、100回目で32BITでも
やってみたら、駄目、と言う事になる可能性があるが、その場合、不具合の
原因がどの修正によってもたらされたのは分からなくなるので、原因の不具合
の切り分けが難しくなるため、なるべく毎回テストした方が良いと考えられて
いる。ただし、ビルドとテストに時間が掛かって、むしろ開発効率が
悪くなることもあるので絶対ではないが。
- 121 ：デフォルトの名無しさん：2020/12/19(土) 01:07:28.35 ID:pyDV0l6z.net
- >>117
まだデバッグしてるんですかって？え？？
コード書きながら動作確認するのもデバッグなわけだがｗ
- 122 ：デフォルトの名無しさん：2020/12/19(土) 01:09:22.42 ID:H4M2BfyN.net
- 毎回Nativeをやたら推してくるやつが湧いてくる。。
- 123 ：デフォルトの名無しさん：2020/12/19(土) 01:16:12.58 ID:tyWP7Wcq.net
- ID:pyDV0l6z
貴方、MS関連スレでオンプレ爺さんと呼ばれてる人ですか？
- 124 ：デフォルトの名無しさん：2020/12/19(土) 01:20:51.08 ID:pyDV0l6z.net
- Blazor Wasmやりたがってたひとって
wasmだからやりたいってわけじゃない。
ほとんどはただCSSやJSがきらいな人たち。図星だろう？
web appである必要ないのにまわりと一緒になって思考停止していて
生産性の悪いCSSゴミやJSでもがいて開発が進まない。
JSがいらない素晴らしい！と
Blazor Wasmのような成熟してないのもに手を出してしまう。
SwiftとかKotlinを学習してnativeでさくっと開発してリリースしてしまうほうが速い。
- 125 ：デフォルトの名無しさん：2020/12/19(土) 01:27:21.70 ID:KJkGIAX1.net
- 速度は少々犠牲にしても開発し易ければ使われる、という歴史を何度も見てきた。
ターゲットが増えても、ビルド回数が一回で済むこと、バックアップのための
ストレージが少なくて住むこと、バイナリの管理が楽なこと、などのメリットが
Webアプリにはあり、なおかつ、好きな言語を使いたい需要が大きい以上、
Wasmが生き残っていく可能性は高いと見ている。
- 126 ：デフォルトの名無しさん：2020/12/19(土) 01:31:03.86 ID:H4M2BfyN.net
- >>125
じゃあBlazorServerで良くないか？
- 127 ：デフォルトの名無しさん：2020/12/19(土) 06:52:39.03 ID:pyDV0l6z.net
- >>116 >>125
バイナリサイズ肥大化はC/C++の問題だろう
C/C++はDLLなどランタイムの互換性も問題になる。
しかしそれらはC#では解決しているのだから関係ない話
あとWeb appはブラウザのバージョンアップでレイアウト崩れたりする。
nativeはブラウザのバージョンに関係ないからリリース後はむしろ楽になる。
昔はIEでしか動かないweb appがたくさん開発されてて企業によっては
いまだに稼働している。
web appにはそういう負の側面もある。
- 128 ：デフォルトの名無しさん：2020/12/19(土) 06:54:57.16 ID:pyDV0l6z.net
- >>126
Blazor Serverは企業内で使うくらいだろう
ステートフルだからスケーラビリティがない。
- 129 ：デフォルトの名無しさん：2020/12/19(土) 09:15:20.46 ID:H4M2BfyN.net
- >>128
逆に企業外でwasm使うシーンってある？
ゲーム？
- 130 ：デフォルトの名無しさん：2020/12/19(土) 09:40:11.79 ID:8bUfeulY.net
- >>121
やれやれ
動作を確認するんじゃない前提と結果を確認するんだよ
それはテストだ
- 131 ：デフォルトの名無しさん：2020/12/19(土) 09:40:59.84 ID:8bUfeulY.net
- >>124
C#を使いたい人だよ
- 132 ：デフォルトの名無しさん：2020/12/19(土) 09:50:15.99 ID:29ydT2k+.net
- デスクトップはテストが面倒くさくないか
Seleniumは安定してるけどWinAppDriverは微妙
- 133 ：デフォルトの名無しさん：2020/12/19(土) 12:27:51.83 ID:3Uzrrw/t.net
- >>127
VS2019のMFCではバイナリサイズが極端に大きくなっていたが、それより十分前の
VSではそんなことはなかった。
なのでバイナリサイズが大きいのはC++そのものが原因ではない。
- 134 ：デフォルトの名無しさん：2020/12/19(土) 12:29:39.47 ID:3Uzrrw/t.net
- >>127
レイアウトの崩れはWidget類をcanvasにグラフィックで描画している場合は
起きない。
- 135 ：デフォルトの名無しさん：2020/12/19(土) 12:34:53.83 ID:LKhLVIez.net
- デスクトップアプリは未だにFormsの忌まわしい思い出を引きずっててな
- 136 ：デフォルトの名無しさん：2020/12/19(土) 12:44:26.38 ID:3Uzrrw/t.net
- >>135
どんな思い出？
- 137 ：デフォルトの名無しさん：2020/12/19(土) 12:47:54.80 ID:FPzjGDbs.net
- >>116
中間ファイルなんかバックアップとる必要ないだろ
- 138 ：デフォルトの名無しさん：2020/12/19(土) 12:50:43.81 ID:LKhLVIez.net
- >>136
残業、徹夜、バグ地獄
デスクトップが高生産性なんて嘘だ
- 139 ：デフォルトの名無しさん：2020/12/19(土) 12:58:36.30 ID:aM5epQiT.net
- >>138
そういう職場がBlazor使ったところで問題解決にならないだろw
- 140 ：デフォルトの名無しさん：2020/12/19(土) 13:00:34.17 ID:3Uzrrw/t.net
- >>137
ちなみに、Debug/Releaseフォルダは中間だけでなく最終バイナリも含んでいる。
また、不具合を発見した時、原因を探ったり、どのバージョンから不具合が起きていた
かを調査することは重要で、そのためには中間ファイルまで残っていたほうが
安全だし便利では有る。
ソースファイルだけ残していた場合、ライブラリやツールキット、ヘッダフィル、
コンパイラのバージョンが変化してしまっていることが多いので、元の
環境に戻すのに膨大な手間と時間が掛かるし、当時の環境にまで完全には戻し
切れないこともある。
毎回毎回、全ての関係ファイルのバージョンをメモすることも不可能に近いし、
古いヘッダフィルやライブラリなどを正確に全て保存しきることも難しい。
古いものをダウンロードしようとしても昔のURLアドレスは無効になっていて
探し出すのに苦労することも多い。
deprecateになっていてダウンロードできなくなってしまっている可能性も有る。
さまざまなライブラリを使っていれば、それら全てについて元に戻す作業が
必要となり、非常に時間が掛かる。
それを避けるためにライブラリ類をハードディスクなどに保存しようとしても、
容量が大きすぎて困ることも多い。
また、インストーラーを保存しても、インストール作業中にネットから
ダウンロードすることが前提になっているものも多く、ちゃんと古いバージョンを
保存することは難しい。
- 141 ：デフォルトの名無しさん：2020/12/19(土) 13:08:06.13 ID:8bUfeulY.net
- >>139
webになって淘汰されたから今は快適だよ
Formsは自然にスパゲッティになるように設計されてるとしか思えん
- 142 ：デフォルトの名無しさん：2020/12/19(土) 13:16:37.65 ID:fca3Stwo.net
- >>140
開発環境はDockerで作るといいよ
Dockerfileだけで十分だけどもし不安ならイメージをレジストリに保存しておけばまず間違いない
- 143 ：デフォルトの名無しさん：2020/12/19(土) 14:19:42.49 ID:xTbqHGyz.net
- >>142
dockerでWindowsコンテナって実用レベルになったの？
- 144 ：デフォルトの名無しさん：2020/12/19(土) 14:21:59.37 ID:cBsPiTZc.net
- >>124
Web開発にふむきな人用の
補助フレームワークですよ。最初から。
- 145 ：デフォルトの名無しさん：2020/12/19(土) 14:33:16.67 ID:pyDV0l6z.net
- >>129
ゲームは開発者が便利なUnityとかのライブラリで作る場合が多い。
Unityは生産性が高い。
一方のwasmは現時点でBlazor wasmはまともなデバッグができない。
あとはゲームといえばアプリ内課金だけど、wasmにすると
課金してもらうハードルがすごいあがってしまう。
SPのnative appだと手数料は高いが簡単に課金できる。
広告収入目当ての無料ゲームならwasmありだとおもうけど
ガチャとかで儲けようと思うとSP native appのが楽だと思うぞ
- 146 ：デフォルトの名無しさん：2020/12/19(土) 14:37:33.55 ID:pyDV0l6z.net
- >>130
俺の言ってるdebugはIDEのメニューのDebugに相当するものでおかしくない。
工程としてのデバッグと技術的なデバッグの違いは文脈でわかると思うんだがな
- 147 ：デフォルトの名無しさん：2020/12/19(土) 14:38:28.43 ID:H4M2BfyN.net
- >>145
ゲームでもなかったら何に使うんだこれってなる
BlazorWasmって最初は夢のような技術だと思っていたが、
俺のような企業向けアプリしか作らないやつにとってはBlazorServerが夢のような技術な気がしてきたぞ。
- 148 ：デフォルトの名無しさん：2020/12/19(土) 14:42:22.79 ID:pyDV0l6z.net
- >>134
グラフィックで描画したらSEO犠牲になるよな
SEOないならweb appでやる意味はないと俺は思う。
- 149 ：デフォルトの名無しさん：2020/12/19(土) 14:48:03.92 ID:pyDV0l6z.net
- >>140
それもC, C++の話でしょ
C#の人はそんな苦労はしてない
DLL地獄などバージョン管理の問題の多くは.NETで解決してる。
ソース保存だけで十分に後日デバッグできる。
- 150 ：デフォルトの名無しさん：2020/12/19(土) 15:17:18.87 ID:H+0BgwK+.net
- >>143
windows？
- 151 ：デフォルトの名無しさん：2020/12/19(土) 15:18:34.03 ID:H+0BgwK+.net
- >>145
テストしろよ
課金は内容次第
- 152 ：デフォルトの名無しさん：2020/12/19(土) 15:19:15.99 ID:H+0BgwK+.net
- >>146
そのDebugは必要ない
テストしろ
- 153 ：デフォルトの名無しさん：2020/12/19(土) 15:19:58.62 ID:H+0BgwK+.net
- >>147
夢のようだろ
C#でフロント開発できるんだから
- 154 ：デフォルトの名無しさん：2020/12/19(土) 15:23:14.19 ID:3Uzrrw/t.net
- >>148
SEO対策が必要な部分だけは、グラフィックでやらずに普通に p や div で
文字列を書く方法も考えられる。
- 155 ：デフォルトの名無しさん：2020/12/19(土) 15:24:00.22 ID:JGeD5jA5.net
- >>150
ID:3Uzrrw/tはMFCをビルドしたいんやで
- 156 ：デフォルトの名無しさん：2020/12/19(土) 15:42:15.72 ID:piWwQ7Ox.net
- お前らこの技術を使っていったいぜんたい何を作ろうとしてるんだ？
- 157 ：デフォルトの名無しさん：2020/12/19(土) 15:43:59.93 ID:3Uzrrw/t.net
- >>145
一番の問題はiOSだね。
技術的に可能でも、Appleから駄目と言われれば終わってしまう。
とにかくAppleはなんとしてもMacのXCodeを使ってないアプリはiOSでは
動かせないように目を光らしている。
セキュリティーとかいう理由は体のいい言い訳で、実際にはMacを強制的に
買わせるため。
本当は独占禁止法違反。
Macの互換機を作ったところで今度はXCodeを互換機にはインストールできない
ようにされるだろうが、それはEUでは「相互運用性のため」と言われて
独占禁止法違反に当たるが。
というわけでMacの互換機を誰か作るべし。
- 158 ：デフォルトの名無しさん：2020/12/19(土) 15:45:44.06 ID:3Uzrrw/t.net
- VirtualPCやVMWareみたいなもののWindowsで動くMac仮想マシンは無いのかな。
- 159 ：デフォルトの名無しさん：2020/12/19(土) 15:48:45.06 ID:cfiN3g00.net
- >>157
Macだけあれば良いのだから問題ない
- 160 ：デフォルトの名無しさん：2020/12/19(土) 15:50:12.89 ID:3Uzrrw/t.net
- >>159
個人的にはそれだけは嫌なのでiOSは無視するよ。
- 161 ：デフォルトの名無しさん：2020/12/19(土) 15:50:26.91 ID:1ZOkfUtM.net
- >>120
Ajail開発w
脱獄されないよう点呼も小まめにね
- 162 ：デフォルトの名無しさん：2020/12/19(土) 16:20:27.46 ID:MvLlV0UQ.net
- >>160
君がそうしたいならそうすればいい
雨の中で傘を刺さずに踊る人が居てもいい
それが自由というものだからね
- 163 ：デフォルトの名無しさん：2020/12/19(土) 16:24:52.94 ID:3Uzrrw/t.net
- >>162
iOSのアプリ開発は、企業に任せるよ。
- 164 ：デフォルトの名無しさん：2020/12/19(土) 19:33:56.12 ID:pyDV0l6z.net
- iOS, Androidのシェアは日本ではほぼ半分
https://simchange.jp/post-164095/
iOS, Androidのどちらか先にappつくって
ヒットしたら移植するのでもいいだろう
- 165 ：デフォルトの名無しさん：2020/12/19(土) 19:37:37.25 ID:pyDV0l6z.net
- >>158
VMwareでMac OSは動くようだよ
仮想化してるから速度は期待できないが。
>>157
Mac以外のハードでMac OSを動かす方法は既にある。
この話題はあれるから書きたくない
- 166 ：デフォルトの名無しさん：2020/12/19(土) 19:40:52.47 ID:pyDV0l6z.net
- 最近、nativeの話してもバッシングされなくなったな
まえはXamarinの単語だしただけで基地外が騒いだけどｗ
多くの人がBlazor wasmのガッカリ感に気付いたかね？
- 167 ：デフォルトの名無しさん：2020/12/19(土) 19:59:06.06 ID:G+RQMXDP.net
- XamarinがNGワードに入ってるだけだと思うぞ
俺は技術的なワードはうざくてもNG入れない主義だから見えてるけど
- 168 ：デフォルトの名無しさん：2020/12/19(土) 23:35:45.44 ID:cBsPiTZc.net
- >>166
Blazor = Wasm + js
であることに騙され、
そのjsの占める割合が高い事に失望した。
結論
Reactでやった方が速いやんけ！（開発も速度も）
- 169 ：デフォルトの名無しさん：2020/12/19(土) 23:44:53.55 ID:LpZi8G42.net
- ザマ爺あっちのスレ戻れ
社内でしか通用しない老害のウンチクは向こうで垂れ流せ
- 170 ：デフォルトの名無しさん：2020/12/19(土) 23:52:19.46 ID:tyWP7Wcq.net
- ID:pyDV0l6z
やっぱり貴方、MS関連スレでオンプレ爺さんと呼ばれてる人じゃないですか！
なんで応答しないんですか！！
- 171 ：デフォルトの名無しさん：2020/12/19(土) 23:58:08.90 ID:LpZi8G42.net
- ここではスレチのxamarin推すガイジとして有名でザマ爺呼ばわりされて皆から嫌われとるんや
- 172 ：デフォルトの名無しさん：2020/12/19(土) 23:58:46.73 ID:8bUfeulY.net
- >>168
高くないが？
- 173 ：デフォルトの名無しさん：2020/12/20(日) 00:41:09.44 ID:a9TnPW+R.net
- >>166
Blazor本スレならスレ違いで叩くがここは雑談スレだから放置してる
- 174 ：デフォルトの名無しさん：2020/12/20(日) 01:13:21.56 ID:qnjQAXRu.net
- あっちはクラウドの話ばかりですが
- 175 ：デフォルトの名無しさん：2020/12/20(日) 03:32:44.06 ID:Hx+xItDT.net
- ここはガイジの隔離スレ
本スレに迷惑掛からないよう適当に相手してやってくれ
- 176 ：デフォルトの名無しさん：2020/12/20(日) 03:57:19.02 ID:NmAfNXJq.net
- >>165
有ってもWindowsを終了させて再起動しなくちゃいけないとかだったら
困るし、遅いのも困るし、XCodeをインストールできるかどうか、できても
ネットに繋いだ時にライセンス違反を指摘されたり、AppStoreに登録できるか
どうかも分からないし、とにかくAppleが絡むとろくなことが無いので
iOSは無視するしかない。
- 177 ：デフォルトの名無しさん：2020/12/20(日) 07:58:59.61 ID:vYm8Aryt.net
- >>173-175
本スレってASP.NET知らない無能が立てたスタンドアロンスレのことか？
あそこも俺がネタふらないとすぐ過疎った。
Blazor使ってる人がほぼいないから話題がない。
- 178 ：デフォルトの名無しさん：2020/12/20(日) 08:09:16.60 ID:vYm8Aryt.net
- >>176
iOS app開発できるし
パッチもあてられるし
CPU次第でMacより速くできるし。
マルチブートするかMacOS専用PCにするかは自分次第だし。
Apple嫌いなのは同じだが違いは儲かるから俺はやる、それだけ
AndroidとiOSシェア同じなんだから捨てるのはもったいない
- 179 ：デフォルトの名無しさん：2020/12/20(日) 12:38:53.63 ID:NmAfNXJq.net
- >>178
iOSには800万社くらいがアプリを提供していて、その内の1%の会社で8割くらい
の売り上げを獲得し、残りの99%は、平均で年間売り上げは100万円位しか
ない。
- 180 ：デフォルトの名無しさん：2020/12/20(日) 12:39:56.25 ID:NmAfNXJq.net
- >>179
訂正：
800万社ではなく、75万社くらい。
- 181 ：デフォルトの名無しさん：2020/12/20(日) 13:24:08.95 ID:XPZNArTY.net
- ザマオンプレジジィが伸び伸びしてて草
終の棲家とするが良いｗ
- 182 ：デフォルトの名無しさん：2020/12/20(日) 17:45:21.29 ID:vYm8Aryt.net
- >>179
アプリ内課金なのか何の数字なのか不明だが、
間接的にsp appで利益あげるパターンもある。
アプリ無料で広告もつけなくても稼ぐことができる
トップ層は大ヒットゲームだし
下はとりあえずつくってみたアプリだし
平均値はあまり意味はない。
- 183 ：デフォルトの名無しさん：2020/12/20(日) 20:08:45.15 ID:Gd3F49It.net
- 177 名前:デフォルトの名無しさん :2020/12/20(日) 07:58:59.61 ID:vYm8Aryt
>>173-175
本スレってASP.NET知らない無能が立てたスタンドアロンスレのことか？
あそこも俺がネタふらないとすぐ過疎った。
Blazor使ってる人がほぼいないから話題がない。
爺さんさ、もしかして発達障害の診断受けたことある？
上に引用した爺さんのレスだが、実際のところは2つのblazorスレで無関係なオンプレミスとxamarinの話を永遠繰り返してただけじゃない？で、スレ違いだから止めろとスレ民からいくら言われても、決して止めなかった。…これって爺さんの中では適切な話題を振っているとの認識だからよな？
スレチだけでなく、こちらの質問に対して妙にズレた回答をしてくることも幾度となくあった。むしろ適切な回答が返ってくることの方が珍しいくらい。
要するにさ、全く会話が成立していない状態なんだよね。分かるかな？
現実社会でもそういう指摘受けたことないかい？どうだろう？
- 184 ：デフォルトの名無しさん：2020/12/21(月) 00:37:22.04 ID:SJYr72qf.net
- >>182
もう、スマホが出来てからかなり時間が経ってしまったので黎明期の
ように簡単なゲームやアプリでも飛ぶように売れるというような特殊期間
は過ぎてしまった。
ソフトウェアの需要も頭打ちになっており、そう簡単に儲かるものではない。
ゲームも売上高は高く見えても開発にも同等に人件費がかかっており
赤字ぎりぎりの事が多い。
- 185 ：デフォルトの名無しさん：2020/12/21(月) 01:12:36.38 ID:KEVFN1Cr.net
- >>183
もう構うなや
NGワードいくつか設定しとけば問題無いやろ
- 186 ：デフォルトの名無しさん：2020/12/21(月) 01:33:49.70 ID:kC10DwQL.net
- ここは雑談スレだから仕方ない
Blazor本スレならしょうもない雑談は徹底的に叩くけど
- 187 ：デフォルトの名無しさん：2020/12/21(月) 09:36:20.15 ID:eMg5oWqT.net
- >>184
儲かるマーケットで新規参入が増えるのは当たり前だしどうでもいい。
クオリティが高ければ人気がでて儲かる
ゲームの損益は上場企業なら公開されてる。
頭打ちでもない。巣ごもり需要で各社、好決算だ
- 188 ：デフォルトの名無しさん：2020/12/21(月) 09:40:40.18 ID:eMg5oWqT.net
- >>183
オンプレミスの話題は他の奴らが悪い
海外で脱クラウドの流れでてるのは事実だし
ある程度知識あるエンジニアなら当然のように気が付く。
事実に反発しているということは
オンプレミスで開発・運用できるスキルがないやつらってこと
否定しないと自分がスキルないのを認めることになるから奴らはしつこい
- 189 ：デフォルトの名無しさん：2020/12/21(月) 10:19:52.71 ID:RgKh0kMO.net
- 脱クラウドの真偽はどうあれ、少なくともBlazor使ってるのなんてほぼ100%クラウドでしょう
ちょっとは周り見た方がいいよ
- 190 ：デフォルトの名無しさん：2020/12/21(月) 10:54:45.18 ID:sgTwUHSK.net
- >>188
極一部の企業がやり始めたってだけで全体に拡大解釈しちゃいかんよ
オンプレミス回帰と主張したいなら数字とグラフで示さなきゃ
それができないならただの戯言
- 191 ：デフォルトの名無しさん：2020/12/21(月) 12:29:08.06 ID:vPyfCX7u.net
- たのむからここではオンプレの話をするなよ
- 192 ：デフォルトの名無しさん：2020/12/21(月) 17:46:03.85 ID:xeeueWnS.net
- >>187
iOSのアプリは、メーカーが作ってればいいよ。
- 193 ：デフォルトの名無しさん：2020/12/21(月) 17:56:07.61 ID:eMg5oWqT.net
- >>189
Blazorだけの数字なんていみないし
そもそもBlazorのシェアがまだ1%すらない
ちょっとは現実みたほうがいいよ
- 194 ：デフォルトの名無しさん：2020/12/21(月) 17:58:48.02 ID:eMg5oWqT.net
- >>190
ほんとクラウド信者はしつこいな
スキルある企業、個人は
パブリッククラウドの料金体系見てすぐ除外する。
ほとんどの用途でオンプレミスよりコスト高になる。
わからないやつはその程度のレベルだししつこく反論してくるな
- 195 ：デフォルトの名無しさん：2020/12/21(月) 17:59:42.03 ID:eMg5oWqT.net
- >>191
心配しなくてもそのうち消える
俺にとってこの板は失うもののほうが圧倒的に多い
- 196 ：デフォルトの名無しさん：2020/12/21(月) 18:00:08.46 ID:FwW9ovL+.net
- 雑談スレだとオンプレ爺さんも相手してもらえるんだなw
- 197 ：デフォルトの名無しさん：2020/12/21(月) 18:11:17.19 ID:vPyfCX7u.net
- あっちが本スレなんじゃよ爺さんも湧くからたまらんなあ
- 198 ：デフォルトの名無しさん：2020/12/21(月) 19:04:54.94 ID:sgTwUHSK.net
- >>194
そんなすぐに見切り付けられるんじゃクラウドは商売にならん
しかし現実の世界ではクラウドは大繁盛だ
みんなクラウドのほうが良いと判断してるわけだな
- 199 ：デフォルトの名無しさん：2020/12/21(月) 20:35:12.12 ID:eMg5oWqT.net
- >>198
しつこいな
どうせおまえは無能でオンプレミス対応できないんだから
気にしてもしょうがない
- 200 ：デフォルトの名無しさん：2020/12/21(月) 20:42:24.04 ID:RgKh0kMO.net
- 俺はオンプレのサーバーに触れたことすらない無能だが、クラウドのお陰で一本稼いでる
オンプレのほうが安い可能性は否定しない(知らないから)けど、ぶっちゃけ全く興味ないわ
- 201 ：デフォルトの名無しさん：2020/12/21(月) 20:52:32.75 ID:+ci58h/H.net
- >>199
クラウドに対応できないんだね
わかってるよ
オンプレ仕事は減っていくだろうけど頑張ってね
- 202 ：デフォルトの名無しさん：2020/12/21(月) 21:08:17.13 ID:vPyfCX7u.net
- こんなところに書いてもあれだが雑談系スレッドならいいだろう。
オチは無い。
Qiitaや技術系ブログをみてると、Reactやらnode.jsやらJavaScript系の技術を使ってる俺たちは最先端だよねイケてるよねっていうのがすごく鼻につく。
その技術が苦手なこともあるはずなのに良い面ばかり書かれてて
そしてJavaやC#は馬鹿にされる。
おそらく若手はC#なんて古臭い言語やってられないですよ俺たちもTypeScriptヤりたいっすよ
って思ってるんだろうなあと。
いやいやnode.jsってン万件のCSVデータ取り込みとかに耐えれるのか？向き不向きがあるだろうと言いたいところだが
こればっかりは触ってみないと分からないんだよなあ。
そしてそんなことやってる暇がない。
BlazorServerなんて最強じゃんと思うんだが、若手はこんな潰しの効かなさそうな技術なんか学びたくないだろう。
俺が若手の頃にCOBOLなんてやってられないっすよと思ったように。
良し悪しとは別に技術には勢いというものがあって、勢いがあると沢山の知見が集約されてどんどん良くなっていく。
js系の技術やクラウドもそうなんだろうな。
- 203 ：デフォルトの名無しさん：2020/12/21(月) 23:50:58.97 ID:ll9V3sqt.net
- ン万件とか少な過ぎて笑える
- 204 ：デフォルトの名無しさん：2020/12/22(火) 09:37:44.93 ID:yCNDLhUz.net
- >>201
またでてきたか、低能のイキリが。
そんな簡単なことで自慢してくるから笑われる
オンプレミスやってるやつらで簡単な設定するだけの
クラウド使えない奴などいない
- 205 ：デフォルトの名無しさん：2020/12/22(火) 09:42:09.37 ID:yCNDLhUz.net
- >>202
ここ雑談スレじゃない。
Web系エンジニアのマウントには同意。
スクリプトしかできない無能なフロントエンドほどマウントとってくる。
バックエンドの知識ないからクラウドつかってるやつらなのに
クラウド使える俺たちすごい！みたいな奴らなｗ
コボラーに同意しちゃうとまた爺さんと誤解されるからやめとくか
- 206 ：デフォルトの名無しさん：2020/12/22(火) 09:46:21.52 ID:8AraQvJr.net
- ここは雑談スレで本スレはこっちな
【本命】Blazor スレ2【真打】
https://mevius.5ch.net/test/read.cgi/tech/1606028377/
- 207 ：デフォルトの名無しさん：2020/12/22(火) 09:47:06.91 ID:yCNDLhUz.net
- >>202
C#が古臭くてTSがやりたい？
そんなこといってるやつは無能すぎだろ
nodeは低速だしクソだよ
nodeのweb frameworkでまともなやつはない
JSがどんどん良くなっていくも嘘
触ってみりゃわかる
ゴミみたいなのが乱立してるだけってのがJSフロントの実態
- 208 ：デフォルトの名無しさん：2020/12/22(火) 10:03:50.70 ID:QfeqeAq5.net
- >>204
使えてないからオンプレのほうがいいなどと間違ったことを言い始める
使えてる人はクラウドを選ぶ
- 209 ：デフォルトの名無しさん：2020/12/22(火) 12:11:07.00 ID:Vz3OkUO2.net
- >>207
すまんがあなたの
クラウド貶してオンプレ推してるのに違和感を感じるので
そのnode、js貶してるのもいまいち信用できないんだよなあ
適材適所ってあるって思うんだよ。
何からなんでもクラウドはたしかにおかしい。
オンプレが必要なシーンはあるだろう。
同様に何からなんでもjsはクソ！もおかしい。
これではWeb系エンジニアのマウントと変わらない。
- 210 ：デフォルトの名無しさん：2020/12/22(火) 12:24:41.48 ID:ejjmBy56.net
- 地頭が悪いジジイやから数十年携わってきたサーバー運用しか出来んねん
スレ民はもうちょい労ってあげてや
- 211 ：デフォルトの名無しさん：2020/12/22(火) 12:54:35.28 ID:sMkHVlkY.net
- >>209
>これではWeb系エンジニアのマウントと変わらない。
こういうのはオンプレ爺と同じでコンプレックス丸出しなのでやめた方がいいよ
それに今どきWeb使わないシステムやソフトウェアのほうが圧倒的少数派なので「Web系」って括りは意味がない
- 212 ：デフォルトの名無しさん：2020/12/22(火) 13:06:10.14 ID:yCNDLhUz.net
- >>209
信用できない？
ベンチマーク見てから言え
C#, Javaに比べて
node(JS)遅いし
Rubyは激遅い
能無しフロントのマウントと一緒にするな
俺は技術の優劣をみてクソと言っている
- 213 ：デフォルトの名無しさん：2020/12/22(火) 13:09:39.64 ID:yCNDLhUz.net
- >>210
外部業者に委託しないとバックエンドの開発も運用も
できないようなおまえのような無能と一緒にすんなハゲｗ
もしジジイならスキル範囲ひろくてめちゃ有能ジイイだな
おにいさんだけど
- 214 ：デフォルトの名無しさん：2020/12/22(火) 13:48:16.89 ID:ejjmBy56.net
- ジジイなんで毎度すぐレス返ってくるねん？
会社に相手してくれる人おらんで暇なんかな
しゃあない、おいちゃんが何でも話聞いたるわ！
これからは無理してITの話題振らんでもええさかい、ジジイの趣味話でも聞かせてや
- 215 ：デフォルトの名無しさん：2020/12/22(火) 13:52:25.55 ID:ejjmBy56.net
- あ、それから無理して草生やす必要ないで？
つい背伸びしてまうのはジジイの悪いトコロやな
- 216 ：デフォルトの名無しさん：2020/12/22(火) 14:30:43.23 ID:Vz3OkUO2.net
- >>212
文字速度、生産性全てにおいてASP.NET+C#が上回るならなぜみんな選択しないのか。
理由は必ずあるはず…！
小規模なシステムで使うには重量級すぎるとか？
それとも最初に覚えた言語が何かにもよるのだろうか。
js系言語から入ったらC#やJavaに手を出さないものなのか。
おれは機会があればjs系言語に手を出してみたい。
>>211
そう？会社もWeb系とSIer系で分けれるのかなとおもってるんだけど。
コンプレックスははっきり言ってめちゃくちゃある。
あいつらはなんであんなにキラキラとした目でjs系技術最高っスみたいなノリなんだちくしょうめ。
- 217 ：デフォルトの名無しさん：2020/12/22(火) 14:32:57.24 ID:Vz3OkUO2.net
- >>216
×文字速度
○速度
- 218 ：デフォルトの名無しさん：2020/12/22(火) 16:09:21.58 ID:3BPmpE5D.net
- >>213
零細勤めなのは知ってるけどどれくらいの規模のシステム作ったことあるの？
ロードバランサー要らないレベル？
- 219 ：デフォルトの名無しさん：2020/12/22(火) 16:42:02.20 ID:QfeqeAq5.net
- >>216
なぜ選択されないのかというとWEB系ウェーイの連中がスクリプト布教活動に熱心だからだよ
やつらがnode最高です、ruby最高ですとひたすら布教するので、引っかかったユーザーがどんどん増える
C#erは布教活動にはあまり熱心ではないね
自分らが有効に活用できればOKという考え方なので、ユーザーを増やすことには興味がない
もしかするとウェブ系ウェーイみたいに雑魚が流入してくるリスクを懸念してるのかも
- 220 ：デフォルトの名無しさん：2020/12/22(火) 20:12:23.02 ID:lwpoOL3+.net
- 毎度すぐレス返してきてお前暇なんか？言うてジジイ煽ってみたら案の定何も書き込まなくなりおった
なんちゅう打たれ弱さや…チンケなプライドが足枷になってること理解しとるんか？
- 221 ：デフォルトの名無しさん：2020/12/22(火) 20:54:55.78 ID:Vz3OkUO2.net
- なんだこのエセ関西弁…このスレはなんでこうイロモノ揃いなのか
>>219
たしかにやつらは得た技術を発信することを良しとしてるよな。
Web系ならではのオープンな感じ。
SIerがやったら自社ノウハウを流出させたから減給とかなりそう。
それで情報が少ないから人気のない言語、フレームワークと捉えられるのは悲しいなあ。
- 222 ：デフォルトの名無しさん：2020/12/22(火) 21:14:00.98 ID:QfeqeAq5.net
- そもそもASP.NETの人気がないというのが嘘だろう
個人ブログ等の記者が主観で語ってるだけのいわゆる僕が考えたフレームワークランキングだと無視されがちだけど
ちゃんとした測定を元にランキングを出してるとこだとPHPの次ぐらいにASP.NETが入ってるものが多い
- 223 ：デフォルトの名無しさん：2020/12/22(火) 22:12:00.01 ID:yCNDLhUz.net
- >>221-222
ASP.NETはWeb Frameworkとしては1位だ
https://www.wappalyzer.com/technologies/web-frameworks/
>>220
無視されたことに気付かないバカ
- 224 ：デフォルトの名無しさん：2020/12/22(火) 22:21:19.03 ID:yCNDLhUz.net
- >>223のURLはもっと知名度あっていい。
node.jsが人気ないのもわかるだろ
Expressもシェア落として6%になった。
Expressはフルスタックではなく貧弱なやつだからな
node系のフルスタックはゴミみたいなのしかない
web frameworkは迷わずASP.NETでいい。
C#できないちょい無能はLaravelかRails
ガチ無能はバックエンドさわってはいけない。事故の元
- 225 ：デフォルトの名無しさん：2020/12/22(火) 22:22:23.43 ID:lwpoOL3+.net
- ほらな、逃げた言うて煽ったらすぐ書き込みにきよる
何より笑えるのはわいが煽って以降、ジジイがレスに草生やさなくなったことやｗ
要するにな、オンプレジジイはいい歳して己が確立してない精神的未熟児なんやね
他人に抗うことしか行動原理が無い、それこそが唯一のアイデンティティ…なんとも悲しくて哀れで虚しい話やないか！？
……おいちゃんな、ほんまはジジイの力になりたいんや！真剣にそう思ってる
ジジイがクラウド本気で勉強するつもりならわいが一から手取り足取り教えたる、blazorに関してもジジイと違っておいちゃんはプロやから正しい使い方伝授したるよ？どや、ええ話やろ？
- 226 ：デフォルトの名無しさん：2020/12/22(火) 22:58:45.41 ID:Vz3OkUO2.net
- 名探偵コナンの服部みたいな嘘くさい関西弁
- 227 ：デフォルトの名無しさん：2020/12/22(火) 23:57:17.69 ID:lwpoOL3+.net
- お前もおいちゃんと友だちになりたいんか…？
わいは全然構へんのやけどジジイが嫉妬してまうかもしれんからジジイの返答待ちやな
ほなまた明日
- 228 ：デフォルトの名無しさん：2020/12/23(水) 00:26:15.53 ID:JHNEfXdY.net
- こんなこと書いてても、昼間はBlazorWasmを自在に操って、洗練されたピザの販売サイトや天気の一覧が出てくる画面を作ってるんだろうなあ
- 229 ：デフォルトの名無しさん：2020/12/23(水) 01:54:16.30 ID:Kc0L3Url.net
- >>228
オンプレ爺さんは？
- 230 ：デフォルトの名無しさん：2020/12/23(水) 07:14:04.95 ID:y+ivgknh.net
- 雑談スレらしく活気があってイイネ！
- 231 ：デフォルトの名無しさん：2020/12/23(水) 08:14:07.90 ID:L0gYl8Ji.net
- >>229
さあ…でもたぶんオンプレ爺さんは、己を育ててくれたBlazorに感謝しているのは間違い無いだろうから、
感謝のカウントアップをしてるんじゃね。
毎日一万回、カウントボタンをクリックし、スクショを取り、エクセルに貼り付けてる。
さすがにそこまでしないか。八千回かな。
- 232 ：デフォルトの名無しさん：2020/12/23(水) 08:25:24.23 ID:5MtFrMbi.net
- いい話だなァ（；＿；）
- 233 ：デフォルトの名無しさん：2020/12/23(水) 08:34:59.21 ID:L0gYl8Ji.net
- ついでに恥を偲んで聞くんだが、
よくWeb系の奴らが、型があるって素晴らしいですね♪的なことQiitaとかに書いてるけど
奴らが言う型って、もしかしてC#で言うところのクラスのこと？
- 234 ：デフォルトの名無しさん：2020/12/23(水) 08:43:14.91 ID:iOQdV6uo.net
- TypeScriptのことだよ
- 235 ：デフォルトの名無しさん：2020/12/23(水) 08:58:24.15 ID:L0gYl8Ji.net
- え、言語なのか…
- 236 ：デフォルトの名無しさん：2020/12/23(水) 10:03:58.22 ID:h+qkHPqF.net
- >>234
ts推しのひとのlevelはこの程度だｗ
>>235
言語のわけない。経験言語は？
- 237 ：デフォルトの名無しさん：2020/12/23(水) 12:04:39.47 ID:L0gYl8Ji.net
- >>236
し、C#の経験がありますっ
- 238 ：デフォルトの名無しさん：2020/12/23(水) 12:24:52.39 ID:qFmqxSAt.net
- C#やってて型が何かわからないってどゆこと？
C#ではclass, struct, enum, interface, delegate, arrayが型
型があるって素晴らしいですね♪的なのは見たことないけど
動的言語でも型がない言語は実質ないから
静的型チェックっていいですねくらいの意味じゃないのかな
- 239 ：デフォルトの名無しさん：2020/12/23(水) 12:28:36.82 ID:h+qkHPqF.net
- これはひどい
>>236 で回答しちゃいそうになったが
C#やってて型もわからないような人が>>231のように煽ってたわけだ。
型わからないのにC#使えるわけないんだがね
これでまたはっきりしちゃったな
初心者がオンプレミスおにいさんのスキルに嫉妬して叩きまくってたということが
- 240 ：デフォルトの名無しさん：2020/12/23(水) 12:33:43.74 ID:J8E3P1ZQ.net
- >>239
TypeScriptは言語ですよ？
- 241 ：デフォルトの名無しさん：2020/12/23(水) 12:41:43.57 ID:h+qkHPqF.net
- >>240
そういう話じゃない
>>234のレスがずれまくってるということ
TSは型のある言語のひとつだが233返答として不適切ということ。
まあ質問者が煽ってたカスだったから答えはもう不要だけどね
- 242 ：デフォルトの名無しさん：2020/12/23(水) 12:53:44.25 ID:L0gYl8Ji.net
- >>238
いや型が何かはわかってる
js系やってる人達のいう型と同じなのかなという、煽りではなく素朴な疑問
ただjsだって文字型、数値型はあるだろうから複合型のこと言ってるのだろうか。
- 243 ：デフォルトの名無しさん：2020/12/23(水) 13:26:24.61 ID:4FZ7yNJk.net
- 文脈的にTypeScriptでも合ってるような気がする。
- 244 ：デフォルトの名無しさん：2020/12/23(水) 14:06:10.99 ID:Kc0L3Url.net
- 文脈的にはTypeScriptはすばらしいということだね
- 245 ：デフォルトの名無しさん：2020/12/23(水) 14:12:41.92 ID:aoAgDZ6q.net
- >>242
変数が定義時に型を結び付けられていて、途中で別の型の値を代入すると
コンパイル段階でエラーにしてくれることを
「型があるって素晴らしい」
と言っているのだろう。例えば、C++では
int a = 5;
とした場合、aに文字列や浮動小数点値やクラスオブジェクトは代入できない。
auto a = 5;
としても、autoがintのように解釈されてaがint型の変数になるだけで
aに文字列や浮動小数点値やクラスオブジェクトは代入できない。
ところが、JSだと、
let a = 5;
とすると、aには文字列でも浮動小数点値でもオブジェクトでも何でも
代入できてしまう。
これがバグの原因になりやすいから。
- 246 ：デフォルトの名無しさん：2020/12/23(水) 14:17:08.23 ID:O5AY10nM.net
- typescriptは厳密すぎるとは思うけどね
もうちょっと緩くする的な議論もあると聞く
- 247 ：デフォルトの名無しさん：2020/12/23(水) 14:45:16.52 ID:4FZ7yNJk.net
- ウェブ系で型があるって素晴らしいってことは、型が無い世界に居たって事で。
Javascriptつこてて、TypeScriptに出会った感が強い。
- 248 ：デフォルトの名無しさん：2020/12/23(水) 15:20:49.21 ID:qFmqxSAt.net
- >>242
それはC#における型はわかってても
言語に依存しない型という概念を理解してないってことだったりしない？
JS使ってる人たちが言う型とC#の型に違いがあるかというと違いはない
型の種類や適用されるルールに違いがあるだけで型という概念は同じ
- 249 ：デフォルトの名無しさん：2020/12/23(水) 18:02:10.45 ID:L0gYl8Ji.net
- >>245
>>248
ありがとう
jsにもプリミティブ型はあるけど、コンパイラによる型チェックがなかったってことかな。
逆に型チェックなしでよく頑張ってこれたな…
数値計算とかブラウザ上でやることがないから問題なかったのかな。
- 250 ：デフォルトの名無しさん：2020/12/23(水) 18:45:31.75 ID:aoAgDZ6q.net
- >>249
[追加]
JSの場合、オブジェクトは、
let a = {
age : 12;
};
として作製するが、ageを書き間違えて
a.aga = 13;
などとすると、何のエラーも出ず、aga という新しいプロパティーが
追加されてしまう。その結果、
a.age と a.aga の二つのメンバが出来、
a = {
age : 12;
aga : 13;
}
としたような状態になってしまう。
JSに限らず多くのスクリプト言語は同様の現象がおき、ミスに対する
フェイルセイフが出来ておらず非常に危険なので、大規模開発に
向いていないと言われている。
- 251 ：デフォルトの名無しさん：2020/12/23(水) 18:52:45.56 ID:qnDToIG0.net
- それ型と直接関係なくね？
確かにtsだとそれを防ぐ型とか作れるけども…
- 252 ：デフォルトの名無しさん：2020/12/23(水) 19:09:45.60 ID:aa3pY4zz.net
- なぜ型と関係ないと思うwww
- 253 ：デフォルトの名無しさん：2020/12/23(水) 19:26:43.15 ID:L0gYl8Ji.net
- >>250
全部dynamic型！みたいな言語だな。
こんなの自分一人でもだめだわ。破綻するわ。
これの利点ってなんなんだろ…
あとよくサーバーとフロントで型を共有できて嬉しいですよね♪みたいなこと書いてるブログもみるんだが
それができてない場合ってこうなる？
サーバー側:sexはなんか卑猥だからgenderにしたれ！
フロント側:sexに何も挿入されない…
- 254 ：デフォルトの名無しさん：2020/12/23(水) 21:34:43.30 ID:qFmqxSAt.net
- >>250
それはDictionaryに新しいkey/valueペアを追加してるのと同じだからね
そういうのでバグ出しちゃうのは基本的にテスト書かない人
チーム開発で動的言語使ってまともなプログラムを作るためには
静的言語の場合よりも高い技術スキルとコミュニケーション能力が求められる
なのでソフトウェアの規模というよりチームの規模が大きくなればなるほど不利
- 255 ：デフォルトの名無しさん：2020/12/23(水) 21:52:55.12 ID:O5AY10nM.net
- 無能爺が出しゃ張らないだけで、雑談スレでもここまで建設的なスレになるんだね
- 256 ：デフォルトの名無しさん：2020/12/23(水) 21:53:23.50 ID:qFmqxSAt.net
- >>253
サーバーとクライアントで違う言語を使ってても
swaggerとかでインターフェース定義してそれぞれコード生成すればいい
C#でも同じだと思うんだけど？
逆に同じ言語を使ってるからといってやり取りするデータを定義した
クラスライブラリを共有するのはアーキテクチャ的にはかなり微妙
特に外部に公開するようなサービスでは
- 257 ：デフォルトの名無しさん：2020/12/23(水) 22:03:15.12 ID:92W7nQMG.net
- >>254
これだけのことにテスト書くの？テストまみれにならないか？
そもそもコンパイラがチェックしてくれるようなこおを自力でテスト書くとか苦行すぎるだろ…
それって高い技術力と言っていいのだろうか。
言語、フレームワークの選定を間違えているとおもう。
>>256
Blazorのプロジェクトつくるとそうなってるよね
あれは規模が小さいシステムなら許容されるんだろうか。
- 258 ：デフォルトの名無しさん：2020/12/23(水) 22:27:01.33 ID:92W7nQMG.net
- >>256
連投すまん
そのswaggerはサーバー側の型に変更があったらクライアント側で気づくことができるんだろうか。
blazorのプロジェクトの構成ならコンパイラが教えてくれるよね。
外部に公開しないシステムで二回型定義するのは、ツールに頼ったとしてもめんどくさいとおもってしまうんですよ
- 259 ：デフォルトの名無しさん：2020/12/24(木) 00:11:53.93 ID:61P3AxB9.net
- >>258
swaggerの意味間違えてるよ。
それswaggerの役割じゃないから。
- 260 ：デフォルトの名無しさん：2020/12/24(木) 00:38:15.61 ID:cDdTcWWQ.net
- Unityがなんで勝ったか、を考えれば答えは見えてるだろ
- 261 ：デフォルトの名無しさん：2020/12/24(木) 00:59:13.90 ID:z4h3nURn.net
- >>257
>Blazorのプロジェクトつくるとそうなってるよね
なるほど、前提として想定してるアーキテクチャが全然違ったのね
>>256の話はBlazorのプロジェクトが別のバックエンドのAPIサーバーにアクセスする必要があるようなケースに
APIサーバーがで定義された型をクラスライブラリとしてBlazorのプロジェクトと共有するかどうかみたいな話ね
Blazorはモノリシックなアプリでいい場合は簡単に作れていいと思うよ
考え方的にはRailsとかと同じだけど裏のところが独自技術な分だけ優れてる
悪い点はロックインされるところ
- 262 ：デフォルトの名無しさん：2020/12/24(木) 01:05:39.49 ID:cu9CRgEK.net
- 最近はミクロサービスもやっぱ駄目だったってんでモノリスに回帰してきてるらしいな
- 263 ：デフォルトの名無しさん：2020/12/24(木) 06:31:15.50 ID:qBLsz+9E.net
- Docker は、1コンテナに、1アプリのマイクロサービス
今の基幹技術だろw
流行りまくっている
- 264 ：デフォルトの名無しさん：2020/12/24(木) 08:12:52.16 ID:Lxgk3nTO.net
- >>263
またにわかのフロントエンドのバカか
流行っているかではなく優れているかで選ばなくてはいけない
大規模やってる大手企業、上級エンジニアはDockerを嫌う
- 265 ：デフォルトの名無しさん：2020/12/24(木) 08:34:44.70 ID:tvAmDhsP.net
- >>261
すまん前提が書けてなかった。
うちは企業内アプリをメインに作ってて、他の外部apiには殆どアクセスしない。
バックもフロントも自チーム内で完結する。
横に座ってる奴がサーバー側の型を変更して急用ができて帰ったとする
フロントやってるやつがそのことに気づかずにリリースしてしまうなんてことが起こるようなら本末転倒だなと。
それで原因はテストコードが足りないとか、コミュニケーションが足りないとかいうのもおかしいよねと考えている。
Blazorのプロジェクト構成ならビルド時に気づくよね。
swaggerを使うことで、フロント側がすぐに型変更を検知できるような仕組みがあるんならいいんだけど、気づかないよね？困るよね？現にお困りではないでしょうか？
と聞きたかった。
- 266 ：263：2020/12/24(木) 08:39:38.18 ID:qBLsz+9E.net
- AWS の構成図を見てみろ。
ほとんど、マイクロサービスだろ
何十もの、Lambda, SQS(Queue), SNS(通知)をつなげてるの、ばっかりだろ
クラスメソッドの動画を見ろ
会社全体で、AWS の資格を800持っていて、
全12資格を持つ・ジェダイマスターが7人もいる！
- 267 ：デフォルトの名無しさん：2020/12/24(木) 08:40:41.97 ID:BsodnxpD.net
- >>264
零細爺が見栄張って適当言っちゃあかんでしょ
社内でファイルサーバーでもたててSEごっこしてなさい
- 268 ：デフォルトの名無しさん：2020/12/24(木) 08:53:01.08 ID:Lxgk3nTO.net
- >>266
そりゃアマゾンは大手のクラウド事業者だからあたりまえだろ
自社の提供するサービスをそのまま使ってるだけ
サービスの広告にもなる
一般法人がそれを採用することが合理的かは別の話だ。
デメリットを理解せず、流行ってるからいいという
アホな価値観だからそういう思考になる
- 269 ：デフォルトの名無しさん：2020/12/24(木) 08:58:23.93 ID:nIBEXBhK.net
- こいつはホンマにいつも5chやっとるな
- 270 ：デフォルトの名無しさん：2020/12/24(木) 09:04:12.11 ID:Lxgk3nTO.net
- >>266
おまえいつもKENTAの話ばっかりしてるやつだろｗ
クラスメソッドｗ
俺は初心者向けスクールなんていかない。
会社全体の資格者数なんて何の意味もないし
ベンダー資格なんてすぐに取れるんだよｗ
スクールだから宣伝のために講師に取らせてることも理解できないって
頭悪すぎだぞ
スクールの講師に優秀なエンジニアいないぞ
簡単にとれる資格でだまされてるやつｗ
KENTAとかスクールとか情弱ビジネスに釣られすぎ
- 271 ：263：2020/12/24(木) 09:33:54.56 ID:qBLsz+9E.net
- クラスメソッドは、AWS パートナー・オブ・ザ・イヤーとか取ってる、最上位の会社
米国年収で、
Ruby on Rails 1,300万円
Node.js 900万
VMware 1,400万
AWS Solution Architect 1,500万
もう、AWS資格が、Railsを超えてる！
- 272 ：デフォルトの名無しさん：2020/12/24(木) 09:52:41.32 ID:tvAmDhsP.net
- ついでに聞いとこ。
クラスメソッドくんは普段なんのフレームワークで開発してるんだい？
- 273 ：デフォルトの名無しさん：2020/12/24(木) 10:54:27.41 ID:cDdTcWWQ.net
- >>266
その構成が複雑化しすぎて多くの場合でデメリットがメリットを上回ってしまう
よっぽど巨大で複雑なシステムでもない限りモノリスのほうがシンプルでイイネ
っていうふうにトレンドが移り変わろうとしてるところ
- 274 ：デフォルトの名無しさん：2020/12/24(木) 11:28:27.57 ID:TzdYJrci.net
- KENTAはコテ付けるべきでは？
- 275 ：デフォルトの名無しさん：2020/12/24(木) 12:08:12.79 ID:tvAmDhsP.net
- >>273
これほんとにそうだと思う。
こういうのが必要なのって相当巨大なシステムだけなんじゃないのか
トレンドだからとDockerだか、Kubernetesだかに手を出して
気づかず消耗してるんじゃないだろうか。
クリーンアーキテクチャについてもそうおもうし、
なんならrest apiもそうなんじゃないだろうかと疑っている。
rpcでよかったのにrestにしちゃったケースもあると思うんだよなあ
- 276 ：デフォルトの名無しさん：2020/12/24(木) 12:24:48.60 ID:61P3AxB9.net
- >>265
サーバー側の型が
クライアント側に漏れでた時点で
設計がおかしい。
もしかして、
クラサバみたいな設計ですか？
- 277 ：デフォルトの名無しさん：2020/12/24(木) 12:37:13.88 ID:tvAmDhsP.net
- >>276
漏れ出るって…？
ASP.NET MVCは定義したモデルをビューで参照できるよね？
これは漏れ出てる…？
- 278 ：デフォルトの名無しさん：2020/12/24(木) 13:32:36.53 ID:FJvlKwaS.net
- >>275
Dockerは別にいいと思う
あれはどんな依存関係でも簡単にパッケージできるのと環境を汚さないで済むという強力なメリットがある
K8Sまで行くとやりすぎで本当にK8Sが必要なのか慎重に考えないといけない
クリーンアーキテクチャは悪くない
モノリスに回帰してきているとは言ってもコードを汚く書いていいわけじゃない
あくまでも悪いのはミクロサービスであってアプリケーション内部をクリーンアーキテクチャで綺麗に構造化するのは依然として良いことだ
RPCはそのとおり
APIだけじゃぜんぜん駄目だったのでgRPCなどが普及し始めた
DDDの文脈で綺麗にシステムを作ろうとするとAPIよりRPCが肝要となる
- 279 ：デフォルトの名無しさん：2020/12/24(木) 13:35:03.72 ID:61P3AxB9.net
- >>277
サービスレベルで設計してないって事ね。
- 280 ：デフォルトの名無しさん：2020/12/24(木) 13:56:01.24 ID:RIrJysKy.net
- 単純なマスタメンテみたいなアプリでもなけりゃサーバーとクライアントで扱うモデルって一致しなくない？
セキュリティとかプライバシーに関わるようなデータでも平気でネットワークに流しちゃう感じ？
- 281 ：デフォルトの名無しさん：2020/12/24(木) 14:00:28.72 ID:VTM9inIm.net
- ドットネッターはコンテナに拒否反応示す人が多いよね
.NET Coreでせっかくモダンなスタイルのデプロイが可能になったと思ったら、
井の中の蛙なユーザーに迎合してIIS統合とかFDD強化とか変なことに力入れてどんどん退行してるし
- 282 ：デフォルトの名無しさん：2020/12/24(木) 15:31:58.25 ID:GGlRJfww.net
- Windowsコンテナが実用レベルになったら起こしてくれ
- 283 ：デフォルトの名無しさん：2020/12/24(木) 17:59:56.32 ID:tvAmDhsP.net
- >>279
そこまでやる必要がないレベルといえばそう。
世にあるMVC系のWebフレームワークはなんか漏れ出してるということなんだろうか
>>280
逆に単純なマスタは一致するんじゃないの
そりゃおっしゃるようなシーンでは一致しないだろうけど
どっちが多いかにもよるんだろうか。
サーバーと型が共有できるって利点だと思っていたけど
結構反対意見も多いな。
少なくともBlazorの雛形はそうなっているけど、これは小規模だから成り立っている？
もっといろんな意見を聞きたい。
- 284 ：デフォルトの名無しさん：2020/12/24(木) 18:17:21.72 ID:61P3AxB9.net
- >>283
反対意見じゃなくてAPIの設計がちがう。
swaggerでopenAPIとして公開するレベルなら、
クライアントの種別、言語は問わない。
- 285 ：デフォルトの名無しさん：2020/12/24(木) 18:32:45.65 ID:z4h3nURn.net
- >>265
それってコンパイルエラーになるような変更なら気がつくけど
それ以外の変更なら不具合が起こってても気が付かないてことでしょ？
結局テスト書いてないだけじゃない？
swaggerとかインターフェース定義ファイルからそれぞれのスタブを自動生成するようなやつは
定義が変わればそりゃ検知できるけど検知できて新しい定義に対応したところで
その変更によって不具合が起こってないことはテストしないとわからないよね
- 286 ：デフォルトの名無しさん：2020/12/24(木) 18:36:25.33 ID:cDdTcWWQ.net
- >>280
モデルにも色々ある
ドメインモデルとかビューモデルは当然、共有しない
APIやRPCのI/Oモデルは共有する
Blazorはこれを追加作業なしで完全な形で型安全に共有できるから強い
- 287 ：デフォルトの名無しさん：2020/12/24(木) 18:46:02.72 ID:PofLudrU.net
- さらにF#の型プロバイダをBlazorで利用すると、バックエンドが.NETでない場合でも、型安全なI/Oモデルを手に入れることができる
インターフェース定義、コード生成要らないので、とても楽ちん
- 288 ：デフォルトの名無しさん：2020/12/24(木) 18:53:41.80 ID:tvAmDhsP.net
- >>284
いろんなデバイスやシステムからアクセスするapiに関してはおっしゃる通りだと思うよ。
でもそんなの限られるんじゃないの？いや俺がそういうの作った事ないからそう思い込んでるだけかもしれないけど。
そうじゃないものまでapi化するのは意味なくて、型は共有した方が嬉しいですよね♪ってことだと解釈してます。
>>285
swaggerはリリース前に自動で変更検知して止めてくれるってこと？
なら安心だな。
テストに関してはおっしゃる通り。
- 289 ：デフォルトの名無しさん：2020/12/24(木) 19:15:50.43 ID:EoOpc5fU.net
- >>283
型共有は工数削減効果が非常に高いので積極的に利用して良いよ
- 290 ：デフォルトの名無しさん：2020/12/24(木) 19:26:12.20 ID:yLXHVLdF.net
- swaggerがどうのこうの言ってる人はミスリードを狙ってそうな気配がする
swaggerはメソッドを定義することはできないからblazorの型共有とはそもそもまったくの別物だよ
- 291 ：デフォルトの名無しさん：2020/12/24(木) 19:34:01.95 ID:yLXHVLdF.net
- blazorの型共有は単にAPIのDTOを共有するといったつまらないユースケース留まらない(もちろんDTOとしても非常に便利ではあるが)
例えば単価、税率、個数から消費税込み価格を計算するメソッドがプレゼンテーション層とドメイン層の両方で必要になった場合
blazorならC#で1回だけメソッドを実装すればいい
バックエンドとフロントが異なる言語だと同じ処理を異なる言語で2回実装しなければならない
もちろん仕様変更が発生した場合には両方ともプログラムを修正、テストをしなければならない
テスト定義もバックエンドの言語とフロントエンドの言語で2回書かなければならない
片方の仕様変更を忘れてもテストが更新されなければアラートは鳴らないので
慎重に2つの言語を調べ尽くして実装漏れがないかどうか確認しなければならない
- 292 ：デフォルトの名無しさん：2020/12/24(木) 20:36:59.38 ID:NdJ7CDDg.net
- 画面の金額と実際の請求金額に差異が出たりしたら偉い人が顧客に土下座するレベルの重大事故だろ
さすがにそこはサーバーサイドに投げるわ
コード共有などという小手先レベルの共通化は少々バグっても笑って許される程度の機能のちょっとしたUX改善程度にとどめておくべきで、
重要なものはアーキテクチャ上差異が発生しないように作る
- 293 ：デフォルトの名無しさん：2020/12/24(木) 20:48:02.28 ID:yJIcrLfM.net
- >>292
この例はあくまで一例
実際のシステムでは金額計算以外にも同じような状況は沢山ある
それをいちいち全部バックエンドに問い合わせるのは実行効率も製造効率も悪い
- 294 ：デフォルトの名無しさん：2020/12/24(木) 20:58:24.94 ID:KjzzoxRm.net
- >>291
コピペ？
swaggerを使ってのopenAPIなら
まずはその設計思想を勉強されてみてはどうでしょうか？
googleのAPIとか参考になりますし、
無料で試せますよ。
- 295 ：デフォルトの名無しさん：2020/12/24(木) 21:06:28.06 ID:cW3QBX++.net
- >>292
自分の設計だとバリデーション含めて
ロジックは全部（表示フォーマットも）サービス側ですね。
ローカルにあるロジックと応答速度で遜色ないですよ。
サービス側は全部単体テスト対象なんで
安心感もあります。
リリース後にバグ出すと、
なんで単体テストを通過したのか始末書もんです。
- 296 ：デフォルトの名無しさん：2020/12/24(木) 21:23:01.51 ID:IhbSA9yU.net
- >>295
思想としては正しいと思う
.NETな人って表面的なコードの共有は大好きなのにデプロイメントをDRYにするという意識が希薄な人が多くて、
ビジネスロジックのDLLをWebとバッチで安易に共通化したりしてデプロイをミスってトラブル起こすケースが多いんだよね
- 297 ：デフォルトの名無しさん：2020/12/24(木) 21:32:29.46 ID:cW3QBX++.net
- View側に業務ロジック混ざると、
コードが読めなくなること多いですからね。
いろんな人が出入りするし。
フロントなんて持って数年、
システムの統廃合やリプレース時にも楽ですよ。
- 298 ：デフォルトの名無しさん：2020/12/24(木) 21:48:16.63 ID:BMlK5S4S.net
- Blazor Serverでファイルのアップロード処理をしたいのですが、
アップロード時に、ローカルにファイルが存在するかチェックするにはどうすればよいでしょうか？
- 299 ：デフォルトの名無しさん：2020/12/24(木) 21:51:51.36 ID:zHK1POmy.net
- >>298
ローカル側の処理なんでJavaScript書かないと仕方ないんじゃないの
- 300 ：デフォルトの名無しさん：2020/12/24(木) 21:59:31.17 ID:BMlK5S4S.net
- >>299
ありがとうございます。
該当部分はJavaScirptで作ります。
- 301 ：デフォルトの名無しさん：2020/12/24(木) 22:00:26.68 ID:cDdTcWWQ.net
- >>294
swaggerはblazorの型共有とは違うベクトルの話だよ
ここで話すべき内容ではない
- 302 ：デフォルトの名無しさん：2020/12/24(木) 22:05:56.79 ID:cDdTcWWQ.net
- >>295
それはいままで簡単にフロントエンドとバックエンドでロジックを共有できなかったからそうするしかなかっただけ
型共有がなかったからコードを重複させるか些細なことでもバックエンドにリクエストを出すしかなかった
どちらもやりたいことにたいして実装と実行のオーバーヘッドが大きい
型共有が可能なblazorでは無駄なエンドポイント実装、APIコール実装を削減することにより生産性の向上が期待できる
また無駄なラウンドトリップを避けることによりより良いユーザー体験が期待できる
- 303 ：デフォルトの名無しさん：2020/12/24(木) 22:08:01.69 ID:cDdTcWWQ.net
- >>296
昨今ではデプロイメントは自動化されるので間違えることはない
- 304 ：デフォルトの名無しさん：2020/12/24(木) 22:09:26.12 ID:cDdTcWWQ.net
- >>297
Viewには業務ロジックは混ざらない
Viewからは業務ロジックを呼び出すだけ
今まではAPIを通じてリモート呼び出ししていたがblazorではその必要なく呼び出せる
- 305 ：デフォルトの名無しさん：2020/12/24(木) 22:25:28.29 ID:Lxgk3nTO.net
- >>304 >>302
「Blazorでは」と書くと正しく伝わらない。
Blazor ServerとBlazor WebAssemblyで全然違う
紛らわしい名前つけたMSが悪いんだが。
- 306 ：デフォルトの名無しさん：2020/12/24(木) 22:50:48.81 ID:cFK/Qw2G.net
- 実際どちらのことを書いてるんだろう
Serverかな
しかしwasmとserverでほんと全然ものが違うよな。
共通点はフロントをc#でかけるってだけで。
MSの名前の付け方は本当に適当だと思う。
- 307 ：デフォルトの名無しさん：2020/12/24(木) 22:59:35.56 ID:z4h3nURn.net
- 同一言語で作ってる同一プロジェクト内で型を参照することを
”型共有”って言うのは相当違和感あるね
誰が使い始めたのかしらないけど
- 308 ：デフォルトの名無しさん：2020/12/24(木) 23:11:34.69 ID:F9/YVp9N.net
- では何と言うべきか？
- 309 ：デフォルトの名無しさん：2020/12/24(木) 23:24:38.23 ID:cFK/Qw2G.net
- Qiita や個人のブログを貼るのはアレなので
クラスメソッドの記事を…
https://dev.classmethod.jp/articles/typescript-front-server/
interfaceを共有することで 型安全な開発ができます
これのことかな。
- 310 ：デフォルトの名無しさん：2020/12/24(木) 23:50:47.46 ID:cDdTcWWQ.net
- Blazorはinterfaceの共有もできるがそれだけに限らない
interface、class、struct、、、何でも共有できる
それらを総称するとなんと言うか？それは型だ
だから型を共有していると言うより適切な表現はないのではないかな
- 311 ：デフォルトの名無しさん：2020/12/25(金) 00:08:08.33 ID:vv0pxJyE.net
- >>309
このケースはリポジトリとして定義した型をサーバーとクライアントで共有してるというのは違和感ないな
RESTのAPIで切り離されてるからかな
(APIが返す型情報を元にしてないから微妙なところがあるけど)
ASP.NET MVCで言えば同じビューモデルの定義を参照してるからって
ビューとコントローラーで”型共有”してるとは普通言わないよね？
- 312 ：デフォルトの名無しさん：2020/12/25(金) 00:14:35.63 ID:K5aqSQYy.net
- >>311
言い回しとして普及してるかどうかは知らんが型を共有してるのは正しい
- 313 ：デフォルトの名無しさん：2020/12/25(金) 00:24:51.99 ID:Z26lwPgE.net
- >>311
Blazor wasmのプロジェクト構成では
Shareプロジェクトにモデルを定義して
ClientプロジェクトのRazorページでShareプロジェクトを参照している
同じくServerプロジェクトのコントローラーでもShareプロジェクトを参照している
これはなんていうんだろう。
どちらにせよサーバーとクライアントで同じ型を使うという目的に対して手段が違うだけであって、別にまずくはないと思うんだけどどうだろう。
- 314 ：デフォルトの名無しさん：2020/12/25(金) 08:42:56.78 ID:uurLZNKt.net
- サーバーとフロントで型を共有？できた方が大半はうれしい。
OpanAPIが必要なシステムではそこに固執しなくてもよいということで。
じゃあこの板でもたまにやたらと推してくる奴がいる言語、rubyやpythonって静的型付け言語じゃないよね。
てことは型の共有もくそもないと。
そういう言語で中規模以上のWebシステムを作ろうとするとやはり苦労する？
推してくるやつはその事実をわかっていない？
静的型付け言語しかしらない俺にとってはなんであんな推してくるのかとても気になる。
- 315 ：デフォルトの名無しさん：2020/12/25(金) 09:13:17.07 ID:JfQSa+1c.net
- >>314
OpenAPIじゃメソッド(処理)を共有できないよ
フロントエンドとバックエンドで言語を揃えることにより今まで複数言語で書くかリモート実行するしかなかった問題が解決した
OpenAPIは複数言語で書く手間を軽減できるがリモート実行するしかないという問題には未だに無力
- 316 ：デフォルトの名無しさん：2020/12/25(金) 09:31:31.83 ID:UA1/tVeu.net
- どんな言語であれフレームワークであれ
データ型は共有しないとクライアントが受け取ったデータを適切に処理できないでしょ
blazor は同じアセンブリを共有できる分開発は楽になるでしょ
クライアントに送るデータはクライアントに必要なデータしか普通は送らないし
サーバ側の型がクライアントに漏れるとか
入門書レベルの開発しかしたことないだろ
- 317 ：デフォルトの名無しさん：2020/12/25(金) 09:44:37.32 ID:uurLZNKt.net
- >>315
多種多様なシステムやデバイスが使うapiは仕方がないという認識
- 318 ：デフォルトの名無しさん：2020/12/25(金) 10:04:08.77 ID:JfQSa+1c.net
- >>317
その多種多様なデバイスの上で.NETが動くわけで
- 319 ：デフォルトの名無しさん：2020/12/25(金) 10:09:58.28 ID:8j4BK9K7.net
- ぜんぶ設計者次第だという認識
- 320 ：デフォルトの名無しさん：2020/12/25(金) 10:16:11.17 ID:81Ut/TdK.net
- >>314
WebなんてぶっちゃけDBと画面の間のマッピングを定義してるだけの話なので、
データモデルがRDBによって常に静的に型付けされているため動的型でも破綻しにくい
むしろ変にドメイン駆動とか意識高いのに毒されて画面から独立したモノリシックなビジネスロジック層みたいなのができちゃうと、動的型では確実に破綻する
- 321 ：デフォルトの名無しさん：2020/12/25(金) 10:17:04.89 ID:JfQSa+1c.net
- >>316
サーバー側の型がなにを指しているのかによるな
データアクセスレイヤのクラスがプレゼンテーションに漏れるのはBADだと思う
しかしドメインレイヤのクラスをプレゼンテーションから参照するのは問題ないと考えている
昨日も例を出したけど
入力として単価、消費税率、個数があってリアルタイムに税込み価格を表示する画面があったとする
この税込み価格の計算は明らかにドメインロジックだ
プレゼンテーションレイヤから直接ドメインレイヤを参照できればそれが最もシンプルでよろしい
もしそれができない場合、プレゼンテーションレイヤにも税込み価格計算ロジックを実装するかリモート呼び出しのためのエンドポイントを実装し、APIクライアントも実装するという重い作業を強いられる
もちろん、税込み価格計算はただの一例であり、実際にはより多くのニーズがある
プレゼンテーションレイヤからドメインレイヤの型を参照できると低コストでより高度な画面を作成することができる
- 322 ：デフォルトの名無しさん：2020/12/25(金) 10:22:24.07 ID:JfQSa+1c.net
- >>320
それはどうかな？
意識の高いプログラマの代表格であるマーチンファウラー先生はrubyを称賛していたね
ドメインを実装するのに必ずしも静的でなければならなということはなさそうだ
重要なのはテストを書くことなのだろう
- 323 ：デフォルトの名無しさん：2020/12/25(金) 10:27:26.49 ID:JfQSa+1c.net
- そもそもWEBをひとくくりに画面とDBのマッピングであると決めつけるのもいかがなものか
チュートリアルみたいな簡単な仕事ならそれでもいいのかもしれないが
現実のビジネスは小さな事業でもそんなに簡単にはいかない
- 324 ：デフォルトの名無しさん：2020/12/25(金) 10:32:50.39 ID:vv0pxJyE.net
- >>314
自分で勉強しろって
ここで言ってる”型共有”はRubyでもPythonでもできてる
>>315
“メソッドを共有”って何なの？
処理を共有するためのAPIなんだけど・・・
それにBlazorもリモート実行してるよ
- 325 ：デフォルトの名無しさん：2020/12/25(金) 10:35:51.93 ID:uurLZNKt.net
- >>322
C#であればコンパイラが型チェックしてくれるようなことすらも
Rubyは自力でテストを書かなければならない？
しんどくない？しんどくてもその分の見返りがRubyにはある？
いや数画面のスキャフォールドで作られたようなCRUDシステムなら好きな方選んだらいいと思うんだけど
中規模以上になってくるとどうなのかなと思って。
- 326 ：デフォルトの名無しさん：2020/12/25(金) 10:38:07.26 ID:uurLZNKt.net
- >>324
あれ、RubyやPythonも型があるのか
失礼しました。
もう自分で触ってみないとわからんな…
- 327 ：デフォルトの名無しさん：2020/12/25(金) 10:38:47.43 ID:UA1/tVeu.net
- >>321
そんなこといったら
クライアント側でのデータ検証なんて 何もできない
- 328 ：デフォルトの名無しさん：2020/12/25(金) 11:01:46.48 ID:bbGDaeBs.net
- 静的型チェックを重視するならC#よりF#使えばいいのに
- 329 ：デフォルトの名無しさん：2020/12/25(金) 11:08:03.54 ID:8j4BK9K7.net
- 訳わかんない理論がまかり通るスレ
- 330 ：デフォルトの名無しさん：2020/12/25(金) 11:37:26.72 ID:JfQSa+1c.net
- >>324
リモート実行は外部処理系に処理を依頼しているだけなので共有ではない
ここでいうメソッドの共有とは異なる処理系が同じ実行コードをそれぞれの内部に持っているということ
- 331 ：デフォルトの名無しさん：2020/12/25(金) 11:45:17.08 ID:JfQSa+1c.net
- >>325
動的言語はしんどいよ
自分個人としては動的言語には懐疑的
ただ高度なスキルを持った著名人が支持しているのでコード解析の弱体化のデメリット以上に何かしらメリットがあるのだろう
そしてそういった著名人は必ずテストも推奨している
テストを書かない場合は静的言語のほうが有利なのだろう
しかしテスト書けば動的言語の弱点が補われるのでメリットのウェイトが大きくなる
- 332 ：デフォルトの名無しさん：2020/12/25(金) 11:49:27.10 ID:JfQSa+1c.net
- >>327
何もできないというのは間違い
しっかりしたシステムでは必ずクライアント側でもデータ検証を行っている
ただしそれはコード重複や無駄なリモート呼び出しの実装という負債を抱え込むデメリットと常にセット
フロントエンドとバックエンドで言語を揃えれば負債なしにフロントエンドでデータ検証を行うことができる
もちろんデータ検証以外の処理もおなじこと
- 333 ：デフォルトの名無しさん：2020/12/25(金) 12:16:12.84 ID:uurLZNKt.net
- >>331
そう。その何かしらのメリットを知りたいのだ…
>>245
>>250
はjavascriptの例だが、これがrubyでも起こるとすると
しょーもないCRUDの画面でもテスト書かないといけないのだろうか。
javascript勢がTypeScriptに流れてるってことは
それなりの規模のあぷりを動的型付け言語でやろうとするといくらテスト書いても辛いって事だと思うんだけど。
- 334 ：デフォルトの名無しさん：2020/12/25(金) 12:24:33.08 ID:cyV6b5qO.net
- それをここで聞いてもな…
親の仇の如く口汚く罵られるだけで、
メリットなんか提示されないと思うぞ
- 335 ：デフォルトの名無しさん：2020/12/25(金) 12:30:41.85 ID:uurLZNKt.net
- だよね…
技術の優劣をつける意図はないんだが、
自分が作るシステムでは正しい技術を選択したいという想い
- 336 ：デフォルトの名無しさん：2020/12/25(金) 12:31:52.62 ID:fU2xV1RD.net
- >>321
明日もお願いします。
- 337 ：デフォルトの名無しさん：2020/12/25(金) 12:32:11.57 ID:uurLZNKt.net
- Webフレームワーク比較検討スレみたいなのがほしい
js系の言語のスレはBlazorの話するとうざがられるし
- 338 ：デフォルトの名無しさん：2020/12/25(金) 12:37:05.82 ID:JfQSa+1c.net
- >>333
動的言語はコード編集から動作確認、テスト実行開始までがとにかく早い
なのでゼロベースの新規プロジェクト、サービス公開までの時間を最優先する場合にはデメリットよりメリットが上回る
- 339 ：デフォルトの名無しさん：2020/12/25(金) 13:33:23.39 ID:pgbI6Wzr.net
- >>337
人気のweb frameworkのスレッドは個別にあるしそこでいい。
全部の言語まとめて扱うと荒れる。
ＪSやJavaのスレッドはある
Java Web Application Framework総合 ver2
http://mevius.5ch.net/test/read.cgi/tech/1374399677/
C#は乱立してないから素直にASP.NET使えばいい
5chみたいな狭い世界で比較検討せずに
素直に人気のあるやつをいくつか試して決めた方がいい。
- 340 ：デフォルトの名無しさん：2020/12/25(金) 13:37:24.42 ID:pgbI6Wzr.net
- >>337
うざがられてあたりまえ
JSやってるやつらのほとんどがC#を使えない
C#使えるならバックエンドは迷わなくていいASP.NETでいい
迷うならフロントまわりの技術
- 341 ：デフォルトの名無しさん：2020/12/25(金) 13:55:33.58 ID:8j4BK9K7.net
- 自演ぽいな
- 342 ：デフォルトの名無しさん：2020/12/25(金) 14:03:41.81 ID:l1B2LBGM.net
- そろそろ学習本が欲しいところ
アレ以外で
- 343 ：デフォルトの名無しさん：2020/12/25(金) 14:22:22.25 ID:vv0pxJyE.net
- >>330
じゃ、Blazor Serverはリモート実行だから”メソッド共有”じゃないってことね
異なるプログラムで共通のライブラリを使うことを
”メソッド共有”って呼んでもなかなか通じないと思うよ
- 344 ：デフォルトの名無しさん：2020/12/25(金) 14:24:09.99 ID:JfQSa+1c.net
- >>343
ではなんと言ったらわかりやすい？
- 345 ：デフォルトの名無しさん：2020/12/25(金) 17:26:45.87 ID:UA1/tVeu.net
- 共通するコードをライブラリ化して共有でいいんじゃないの
- 346 ：デフォルトの名無しさん：2020/12/25(金) 17:48:04.91 ID:tkA/KKSW.net
- バッと来て
グッと溜めて
ブワッ！
- 347 ：デフォルトの名無しさん：2020/12/25(金) 18:29:51.37 ID:AIeBZh27.net
- >>345
長いので1単語にまとめて
- 348 ：デフォルトの名無しさん：2020/12/25(金) 19:21:45.07 ID:uurLZNKt.net
- >>340
そうなんだろうか
実はC#erが食わず嫌いなだけで、実はあちらのほうがめちゃくちゃいいものなのかもしれないよ…？
- 349 ：デフォルトの名無しさん：2020/12/25(金) 19:30:34.79 ID:UA1/tVeu.net
- 以前は asp.net は Windows Server でしか動かなかったからなぁ
今でこそようやく Linux でもまよもに動くようになって2年ぐらい？
twitter でも .net core で検索すると
一年前はほんと大して結果なかった気がするけど
最近は増えてきてるかな
まだまだこれからでしょ
- 350 ：デフォルトの名無しさん：2020/12/25(金) 20:54:05.41 ID:pgbI6Wzr.net
- >>348
あちらのほうってなんだよ
エンジニアならもっとはっきりかけよ
JSのbackendのweb frameworkか？
ろくなのないって俺が何度も書いてる。試す価値なし。
疑うなら自分で試してベンチマークとかとれよ
RailsもNode backendも遅くてゴミ
スクリプトは遅い。開発の生産性が低い
これは開発者の常識
高速なハードとソフトを合わせないとスケールするサイトにできない
- 351 ：デフォルトの名無しさん：2020/12/25(金) 20:56:57.60 ID:pgbI6Wzr.net
- >>349
昔はLinuxでというかライセンス無料で使えなかったのは大きいね。
JSやってるやつらはいまだにIIS, Windowsでしか動かないと思ってる。
あとclassic ASP時代のイメージのままの人も多い
- 352 ：デフォルトの名無しさん：2020/12/25(金) 21:08:02.22 ID:pgbI6Wzr.net
- 高速なコードで作りたかったらstaticに限る。
主要OSの主要な言語はstaticだ
Swift, Kotlin, Java
server-sideでKotlinもあり。
- 353 ：デフォルトの名無しさん：2020/12/25(金) 23:41:23.33 ID:Z26lwPgE.net
- サーバーとクライアントは同じ言語の方がいいんだろ？
- 354 ：デフォルトの名無しさん：2020/12/26(土) 00:06:30.37 ID:w6CJ0JU3.net
- >>353
できれば同じ方がいいがパフォーマンスも生産性も低いJSに合わせるのは愚策
server-sideでJS使ってるのはアホだと思う
大手ならserver-sideとclient-sideは別の人材が開発するのだから
言語を合わせるメリットはあまりない
ヤフーとかもbackendでnode.js使ってるが事故ばかり起こしてるだろ
レベルが低い
- 355 ：デフォルトの名無しさん：2020/12/26(土) 19:37:00.30 ID:5ukh9MxR.net
- 日本人の誰かBlazorのwikiを作ってくれ
フリーでオープンソースのウェブフレームワークって書くだけでも
wikiがないとBlazorが何かわからん
なぜC#を使ってウェブアプリが作れるのか？
ウェブブラウザはC#を解釈しないからJavaScriptとHTMLだろ
- 356 ：デフォルトの名無しさん：2020/12/26(土) 19:44:30.35 ID:T66JFeJq.net
- BlazorWasmのほう？
WebAssemblyで調べたらいいのでは
- 357 ：デフォルトの名無しさん：2020/12/26(土) 19:54:05.69 ID:5ukh9MxR.net
- >>356
WebAssemblyはwikiがあるが本文にBlazorがない
- 358 ：デフォルトの名無しさん：2020/12/26(土) 20:13:39.65 ID:q2RopqqH.net
- 所詮その程度のオモチャということです
- 359 ：デフォルトの名無しさん：2020/12/26(土) 20:19:52.51 ID:zr3CHg45.net
- WebAssemblyはそれようの仮想マシンで動くからじゃないの
C#コードをその中間言語にコンパイルするだけ
たぶん
- 360 ：デフォルトの名無しさん：2020/12/27(日) 11:16:47.49 ID:FLSM18Bj.net
- >>355
そんなwiki作っても内容古くなるし意味ない
不正確で古い情報入手してどうする？
英語でMSのドキュメント読みなされ
何度も言うけどBlazorと書くべきじゃない。
Blazor Server, Blazor WebAssemblyで
アーキテクチャが全く違う。
- 361 ：デフォルトの名無しさん：2020/12/27(日) 11:17:34.43 ID:FLSM18Bj.net
- >>359
ちがう、いいかげんなこと書かずに
MSのドキュメントを読むべき
- 362 ：デフォルトの名無しさん：2020/12/27(日) 11:17:38.77 ID:l7B3kP+i.net
- >>360
似てるよ。
- 363 ：デフォルトの名無しさん：2020/12/27(日) 11:44:29.13 ID:Y/0KLGYh.net
- >>360
Blazorを初見で見て1分で何か知りたいだけでwikiがいい
時間をかけて英語でMSのドキュメントを読まない
- 364 ：デフォルトの名無しさん：2020/12/27(日) 11:56:13.46 ID:l7B3kP+i.net
- >>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
- 365 ：デフォルトの名無しさん：2020/12/27(日) 12:57:58.03 ID:5MC+7bSJ.net
- >>361
あーそうね
Ｃ#のコードをいつも通り.NETの中間言語にしたものを配布して
ブラウザでの実行時にwasmのコードに変換して実行だっけ？
大して変わらんと思うけど
- 366 ：デフォルトの名無しさん：2020/12/27(日) 14:19:59.57 ID:iruxp8RS.net
- .NET6でAOTが入る予定らしいがファイルサイズの問題とかあるしwasm書くような用途なら他の言語の方がいいんじゃね
- 367 ：デフォルトの名無しさん：2020/12/28(月) 12:55:53.75 ID:Ov8uGTUf.net
- 状態管理ってどうやるのが無難なのかな？
blazor + fluxor ？
- 368 ：デフォルトの名無しさん：2020/12/28(月) 20:34:30.42 ID:N8gr0T4H.net
- 状態管理サービスをDI
- 369 ：デフォルトの名無しさん：2020/12/28(月) 20:36:55.85 ID:RNhofGKy.net
- blazorserver ならセッション？
webassemblyならいる？
- 370 ：デフォルトの名無しさん：2020/12/28(月) 23:32:18.60 ID:w2tkTAcI.net
- GO + wasm が来年のトレンドだと思いましゅ
- 371 ：デフォルトの名無しさん：2020/12/29(火) 01:03:32.89 ID:QFieIEDm.net
- Kotlinはブーム来てる
Kotlinはwasmもすでに存在するようだ
- 372 ：デフォルトの名無しさん：2020/12/29(火) 07:55:55.72 ID:iWtJxFHh.net
- wasmとserver
wasmの方が人気だよなあ
serverはwebformの移植用以外は使い道がないんだろうか
- 373 ：デフォルトの名無しさん：2020/12/29(火) 09:17:54.01 ID:8biyF2ED.net
- go + wasm で使えるイケてるフロントエンドフレームワークがあったらいいんだがなぁ。
- 374 ：デフォルトの名無しさん：2020/12/29(火) 09:43:58.26 ID:QFieIEDm.net
- Googleが採用言語を分裂させすぎだから
Goは普及しないだろ
FlutterではDart
AndroidではKotlin推してる
全部Goにしてたら結果は違ったはず
Kotlinのが流行ってるしな
Go速いらしいけど人気ないのははハードル高いんだろうか
- 375 ：デフォルトの名無しさん：2020/12/29(火) 12:10:38.95 ID:TrPJjXJg.net
- >>372
これホント？
なんとかC#しか使えないエンジニアを有効活用して
JSの10倍遅くても問題ないからオフラインでも使えるWebアプリを作りたいってニーズある？
JSが不要になるわけじゃないし現状はデスクトップアプリかblazor serverのほうが何倍も良いと思うけど
- 376 ：デフォルトの名無しさん：2020/12/29(火) 12:22:03.72 ID:gscEc512.net
- PlayStation Portable go の運命と重なる...
- 377 ：デフォルトの名無しさん：2020/12/29(火) 12:30:16.56 ID:iAxs8NN4.net
- >>375
どっちでもいいんじゃないの
何倍というほどの差はない
- 378 ：デフォルトの名無しさん：2020/12/29(火) 12:33:17.29 ID:Fq3XcUlo.net
- >>375
おっしゃるとおり！
俺のような企業向けアプリしか作らない人間からすると
wasmよりserverのほうが使えそうなんだよね
でもblazorでググるとwasmの記事ばかり引っかからない？
あっちのほうが期待されてるように感じる…
- 379 ：デフォルトの名無しさん：2020/12/29(火) 13:01:36.23 ID:k23+wtCh.net
- 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から利用可能に
なるようだ。
- 380 ：デフォルトの名無しさん：2020/12/29(火) 13:02:15.95 ID:EHaGj/ct.net
- そりゃ技術的に面白いのはwasmだから話題になるのそっちだよ
- 381 ：デフォルトの名無しさん：2020/12/29(火) 13:07:56.98 ID:k23+wtCh.net
- >>379
[補足]
この方式だと端末内の他のアプリからでも、このアプリのlocal http serverに
アクセスできるからセキュリティー的な問題が有るという心配が有るかもしれないが、
そこは「トークン」をつけているので心配が無い。
それは、アプリ起動時に乱数の様なものから作成し、local http serverとJSの
両方に同じトークン値を渡すことで、鍵の様な働きをする。
トークンが合わなければlocal http serverは機能しないようにすることで、
セキュリティー上の問題はクリアできる。
- 382 ：デフォルトの名無しさん：2020/12/29(火) 13:19:00.27 ID:k23+wtCh.net
- MonacaはCordovaアプリをブラウザから作製できるようにした「クラウドIDE」で
Mac実機無しにiOSアプリを作製してAppStoreに登録できる、とされている。
- 383 ：デフォルトの名無しさん：2020/12/29(火) 13:21:34.09 ID:k23+wtCh.net
- >>382
ただし、クラウドの先にあるMac実機をレンタルする必要があるかもしれない。
- 384 ：デフォルトの名無しさん：2020/12/30(水) 19:23:50.60 ID:+vZt7ZP1.net
- >>381
それＷＥＢアプリであるメリットを感じないんだが
そのトークンはだれが作るって？
ローカルサーバーに自分でトークン作って渡すんなら、トークン偽装しほうだいだな
- 385 ：デフォルトの名無しさん：2020/12/31(木) 14:25:23.04 ID:hpqEd6nD.net
- >>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 は結果を受け取る。
- 386 ：デフォルトの名無しさん：2020/12/31(木) 14:45:37.85 ID:tdaLm2s5.net
- ネイティブアプリならそのままローカルファイルアクセスしてUIレイヤーとしてWebView使えば十分では？
わざわざローカルでweb server起動してそれ経由でファイルアクセスさせるメリットってあるの？
- 387 ：デフォルトの名無しさん：2020/12/31(木) 14:52:50.53 ID:bz8vpTSU.net
- でも、既 存のア プリの流 用なら単にserverとclientを一箇所で動かすだけに見えるし、
新 規ならそもそもメ リ ットがどこにあるんだろうという感じだし。
どうしてもUIをhtmlとjsで書きたい場合とかかな。
- 388 ：デフォルトの名無しさん：2021/01/01(金) 02:03:52.73 ID:y/yrEKhd.net
- >>386 >>387
自分でクロスプラットフォームツールキットを作っている場合、
iOS/Android/Windows/Linux/Macなどに個別に対応させるのが大変な場合、
HTML+JS+Wasmでまず、ブラウザで動くようにしておき、ファイル入出力
部分だけを上記の様な local HttpServer 方式で行えば便利。
- 389 ：デフォルトの名無しさん：2021/01/01(金) 02:09:02.70 ID:y/yrEKhd.net
- >>386
それだとWasmをメインプログラムとしたクロスプラットフォームアプリは
作りにくい。
Wasmの関数の中にファイル入出力を行いたい部分が有った場合など。
- 390 ：デフォルトの名無しさん：2021/01/01(金) 13:36:41.38 ID:xBl+DmmI.net
- FileとかOS API使いたければ素直にnative appにするほうがいい。
わざわざwasmとか意味不明
- 391 ：デフォルトの名無しさん：2021/01/01(金) 23:29:42.24 ID:TX7qBddY.net
- >>390
特にクロスプラットフォームのライブラリを自作する場合、ブラウザ上のWasmで
ファイルアクセスまで出来れば対応が楽。
- 392 ：デフォルトの名無しさん：2021/01/01(金) 23:57:03.96 ID:ifweq93H.net
- トークン作るネイティブアプリがあって
HttpServer側のローカルアクセス部分も個別に作るのか
- 393 ：デフォルトの名無しさん：2021/01/02(土) 00:01:46.88 ID:TBL/2gAq.net
- ？
wasmからファイルにアクセスするわけじゃないよね？
というかそもそもwasmでコーディングするわけでもないよね。
- 394 ：デフォルトの名無しさん：2021/01/02(土) 00:47:26.18 ID:md7DJnNn.net
- そもそもWasmでファイルアクセスできたらセキュリティ上おかしいんじゃないのか？
Wasmはソースコード見えないというのに
知らないうちにファイルアクセスするコードダウンロードして
実行されたらまずいだろう
MSの人も動画でBlazor Wasmは安全だといっていた。
Browserのsandbox内で動作するからというがその理由。
>>391
実際コード書いてないわけでしょ
wasmより絶対にネイティブのが楽
nativeでcross-platform対応もできる。FlutterやXamarin
- 395 ：デフォルトの名無しさん：2021/01/02(土) 10:59:11.61 ID:kLdWoF3Z.net
- >>394
C++で書いたプログラムをWasmに変換し、それをWebViewの中で実行する場合の
話だよ。
WebViewを起動するのは、C++やSwift、Javaなど。
その際にlocal http serverとWebViewを同時に起動する。
そして1つの鍵(セキュリティートークン)をlocal http serverとWebViewの
両方に渡す。
なので安全。
- 396 ：デフォルトの名無しさん：2021/01/02(土) 11:26:48.47 ID:XwpZ0T7a.net
- つまり、悪意のあるプログラムが自分でトークン作ってlocal http serverたたいて
それ経由でローカルファイル等の情報にアクセスできるんだろ
local http serverは正しいWebViewから呼ばれているのかどうか確認できないんだが
それのどこが安全？
- 397 ：デフォルトの名無しさん：2021/01/02(土) 11:42:56.76 ID:kLdWoF3Z.net
- >>396
できない。
それはキャッシュカードを拾っても、正しい暗証番号が分からなければATMから金を
引き出せないのと同じこと。
local http serverとWebViewの中のJSの両方に1つの暗証番号を渡しているので
両者だけが通信できて、他のアプリは通信できない。
- 398 ：デフォルトの名無しさん：2021/01/02(土) 11:47:13.97 ID:kLdWoF3Z.net
- >>397
[補足]
・URLのGET PARAMETERの中に正しい暗証番号(=トークン)が書いてある場合には
なるべく速く処理を行ってできるだけ早くresponseを返すようにする。
・暗証番号が間違っている時には、数秒間waitしてからresponseを返し、かつ、
waitしている間は、新たなリクエストを受け付けないようにする。
・こうすれば暗証番号を順番に試してたまたま開く鍵を見つけることが現実的な
時間では不可能になるので悪意を持ったアプリから身を守ることができる。
- 399 ：デフォルトの名無しさん：2021/01/02(土) 15:33:34.85 ID:XwpZ0T7a.net
- いやだから、その暗証番号はカード使う人が外部から指定するんだろ
その暗証番号を指定している人が、そのカードの正しい所有者かどうか確認できないと思うんだが
これが安全だと思えないのは俺がおかしいのか？
- 400 ：デフォルトの名無しさん：2021/01/02(土) 15:35:28.24 ID:kLdWoF3Z.net
- >>399
すまんが、俺のIQは、150超だから、一般プログラマには理解できないかも知れない。
- 401 ：デフォルトの名無しさん：2021/01/02(土) 15:46:16.27 ID:5cxm5c+d.net
- InputFile の OnChange で、選択されたファイル数が0の場合はどうすればイベント拾えるのでしょうか？
<InputFile OnChange = "method" />
@code {
private void method(InputFileChangeEventArgs e)
{
//ファイル未選択の場合はこのメソッド自体が呼び出されない。
}
}
- 402 ：デフォルトの名無しさん：2021/01/02(土) 16:59:19.62 ID:kLdWoF3Z.net
- >>399
WebViewという名前でも、ネット回線からダウンロードしてきた
HTML+JS+Wasmを表示・実行するわけではなく、アプリにパッケージされた
HTML+JS+Wasmを表示・実行するので、所有者の同一性は最初から保証される。
もちろんアプリのパッケージを改ざんすれば駄目だが、それは今回の
セキュリティー問題とはまた別の話。
アプリの改ざんについては、そもそも論で、それはそれで別の方法で改ざんを
防止する技術が必要となる。
- 403 ：デフォルトの名無しさん：2021/01/02(土) 19:13:25.57 ID:XwpZ0T7a.net
- そのアプリのパッケージにlocal http serverとサーバ側のプログラムなりスクリプトなりも含むのか？
- 404 ：デフォルトの名無しさん：2021/01/02(土) 19:19:19.80 ID:kLdWoF3Z.net
- >>403
アプリのパッケージには、
1. local htttp server
2. html+JS+Wasmのプログラム
3. セキュリティートークン発生器
4. ファイルAPI呼び出し器
を含む。
原則的にサーバーは全く使わないのでサーバー側プログラムは含まないが、
サーバー側プログラムを使う場合には、nativeアプリがサーバー側プログラム
と連携する場合のやり方をそのまま使えばよい。
- 405 ：デフォルトの名無しさん：2021/01/02(土) 22:23:44.30 ID:md7DJnNn.net
- >>404
通常のブラウザでは通用しないってことでOK？
ユーザーにファイルアクセスを求める仕組みはどうなってるの？
あとhttp serverなんて動かそうとしたらPCのセキュリティなりファイアウォールが警告だしてくるはず。
Flutterとかのnativeでやるほうが楽なのに
いちいちたくさんの言語使って無駄な工数かける意味がわからん。
しかもめんどくさいわりにサーバー使ってないとかますますわからん。
- 406 ：デフォルトの名無しさん：2021/01/02(土) 22:24:16.16 ID:md7DJnNn.net
- 大手企業がWasm使ってない理由は労力のわりにメリットがないことだと思う。
メリットあるとしたらGoogle/Appleの手数料回避できそうなことくらいか
- 407 ：デフォルトの名無しさん：2021/01/03(日) 02:08:15.23 ID:bUgsUhHF.net
- >>405
>通常のブラウザでは通用しないってことでOK？
ちゃんとアプリとしてパッケージしないと駄目だね。
>ユーザーにファイルアクセスを求める仕組みはどうなってるの？
ファイル関係はnativeアプリと同じになる。
なぜならnativaアプリが使うファイルAPIを使うのだから。
>あとhttp serverなんて動かそうとしたらPCのセキュリティなりファイアウォールが警告だしてくるはず。
今回説明してきた方法は、既にCordova(やmonaca)でも実績が有るのでなんとかなる
はず。AppStoreやPlayStoreなどへの登録も可能。
また、local http serverは、Rubyやnode.jsやapache、mongooseなどでも普通に
高頻度で使用されており、特にセキュリティーソフトが問題になることはない。
なぜならWasmのローカルでのテストには必ず必要になるから。
- 408 ：デフォルトの名無しさん：2021/01/03(日) 02:15:37.37 ID:bUgsUhHF.net
- >>407
[補足]
今回、local http serverは、JS+Wasmでは使えない端末機能を使うためのもの
であったが、ローカルだけでWasmを起動するためにも必要。
Wasmは、fetchやXHRを使わないと起動できないが、CORSの関係で
少なくともWindowsではlocal http serverを起動していないとエラーになる。
(それがないと、URLにローカルのファイルパスをどういうschemeで指定
しても駄目。)
- 409 ：デフォルトの名無しさん：2021/01/03(日) 03:24:25.31 ID:pzO8LSqN.net
- その実績ってのをいくつか紹介してくれ
- 410 ：デフォルトの名無しさん：2021/01/03(日) 03:53:04.49 ID:bUgsUhHF.net
- >>409
Cordovaが使っている技術を解説しているサイトに書いてある。
Cordovaを使って作るのではなく、Cordovaが自分自身で使っているアルゴリズム
であり、かつ、Cordovaは、AppStoreとPlayStoreに登録できるとされている
非常に有名なソフト。
- 411 ：デフォルトの名無しさん：2021/01/03(日) 10:07:36.68 ID:ZfI7ecBk.net
- >>407
後半のlocal firewallの話は一般ユーザーの問題点だよ。
技術的に動くかどうかの話じゃない。
開発者はfirewallから警告でても意味がわかるけど、
一般ユーザーはとまどうってこと。
- 412 ：デフォルトの名無しさん：2021/01/03(日) 10:19:49.86 ID:S5x84IqF.net
- デタラメな俺理論を長々と書く奴は相手にせず放置が一番
まぁhttpdの話はローカルサーバーに同じホストからアクセスしてる分には
ファイアーウォールとか関係ないでしょ
- 413 ：デフォルトの名無しさん：2021/01/03(日) 12:05:13.76 ID:bUgsUhHF.net
- >>412
頭が悪い人には頭が良い人が言っていることが理解できないのでデタラメに
聞こえるし、長い文章も読めないし。
- 414 ：デフォルトの名無しさん：2021/01/03(日) 12:06:19.30 ID:bUgsUhHF.net
- >>411
Cordovaという有名どころでライブラリの基礎で使われているアルゴリズム
なのだから、当然、ユーザーの視点でも大丈夫になっているハズだ。
- 415 ：デフォルトの名無しさん：2021/01/03(日) 12:07:52.02 ID:hFPMmBD/.net
- ローカルへのhttpアクセスをデフォルトではブロックしてるファイアウォールとかもあるんだよ
- 416 ：デフォルトの名無しさん：2021/01/03(日) 13:07:23.70 ID:ZfI7ecBk.net
- >>412
415も書いてるけど
たしかWindowsのFirewallでも
localからのアクセスでもちゃんと警告でるよ
- 417 ：デフォルトの名無しさん：2021/01/03(日) 13:09:03.48 ID:arRzErs6.net
- Cordovaなんて
何年もまえからある、
弩メジャーなやつじゃん。
なので数年前に旬を過ぎて枯れてるけどね。
Visual Studioでも2013？ぐらいから
テンプレート入っとるぞ。
やっぱBlazorレベルのユーザーは
レベルが周回おくれなのか？
- 418 ：デフォルトの名無しさん：2021/01/03(日) 13:11:40.28 ID:arRzErs6.net
- 正直いってXamarinよりCordovaのほうが
遥かにイケてるぞ。大手のスマホアプリで実績多いでしょ。
- 419 ：デフォルトの名無しさん：2021/01/03(日) 13:13:18.51 ID:ZfI7ecBk.net
- >>414
それなら初めからCordovaでnative appにすりゃいいじゃないの。
頭が良い人はそちらを選ぶだろう
いちいちwasmやらhttp serverを使う必要がない。
無駄に時間かかるだけ
- 420 ：デフォルトの名無しさん：2021/01/03(日) 13:23:38.42 ID:S5x84IqF.net
- らしい、とか、ハズ、とか
わろた
- 421 ：デフォルトの名無しさん：2021/01/03(日) 13:47:20.60 ID:arRzErs6.net
- Cordovaでクロスプラットフォームで
自前ブラウザーアプリが作れるから、
そのアプリ実装部分でWasmはありだぞ。
実際、CordovaとWeb系UIのライブラリーを
組み合わせて開発する。
なのでCordovaとBlazorでも可能じゃね？
自分のは数年前にCordovaとPWAとで
検討中して見送った過去がある。
- 422 ：デフォルトの名無しさん：2021/01/03(日) 14:04:27.77 ID:bUgsUhHF.net
- >>421
>なのでCordovaとBlazorでも可能じゃね？
理論上は、BlazorWasmもHTML5と標準Wasmの範囲内のコードになっているはず
なのだから、そのままか、わずかな配慮でで動く可能性は高い。
- 423 ：デフォルトの名無しさん：2021/01/03(日) 14:21:02.77 ID:bUgsUhHF.net
- この方式はC言語とposixが使えるプラットフォームならほとんど無修正で
同じサポートコードが使える可能性があるので便利なのだが、
fire wallの警告が出てしまうならば、使えないかもしれない。
Cordovaは この方式以外にも3種類くらいの方法を併用してJSと
nativeの間で通信しているとされるが、それらにはプラットフォーム間の
互換性が乏しく、iOS、Android、Windows、Linuxなどで
サポートコードの書き直しが必要となる。
- 424 ：デフォルトの名無しさん：2021/01/03(日) 14:34:57.09 ID:arRzErs6.net
- 今自分がやるなら
flutter+WebUIライブラリーかな。
まだ下調べはしてないし作るものも多いけど。
そこにBlazorがあってもなくてもよいが。
- 425 ：デフォルトの名無しさん：2021/01/03(日) 15:00:54.68 ID:ZfI7ecBk.net
- >>418
実績、実績いうならwasmなんて論外だろｗ
CordovaなんてJS, CSSベースだしうんこすぎるし使わんよ。
Xamarinはシェア５位だから実績は十分だしC#使える。
MAUIになれば品質もあがるだろう。
Unityでもいいし、Flutter, Kotlinでもいい
- 426 ：デフォルトの名無しさん：2021/01/03(日) 15:24:48.35 ID:arRzErs6.net
- UI開発ではHTＭL&JSのライブラリーが
断トツ最強なんたが。
- 427 ：デフォルトの名無しさん：2021/01/05(火) 22:26:03.46 ID:eSPu60fw.net
- cordovaなんて10年近く前のプラットフォームじゃん。
ちょっと後に出たionicに頃されたんじゃなかった？
- 428 ：デフォルトの名無しさん：2021/01/06(水) 13:32:12.25 ID:PNufzztm.net
- >>425 >>427
Cordova単体なら言語がJSに強制されるが、WasmもCordovaで動くようになったので
言語はJSに強制されなくなった。
今後、CordovaはC++、Rust、C#(BlazorWasm)をクロスプラットフォーム
で動かすための土台としての私用用途が出て来る。
- 429 ：デフォルトの名無しさん：2021/01/06(水) 13:33:21.72 ID:PNufzztm.net
- >>428
Cordova方式はElectronよりサイズが小さいはず。
- 430 ：デフォルトの名無しさん：2021/01/06(水) 13:53:04.57 ID:PNufzztm.net
- Electronは、WebブラウザであるところのChroniumの改造場も同時配布する
必要があるので、アプリサイズが最低350MB位となるが、Cordovaだと800KB
程度で済むと報告されている：
https://stackoverflow.com/questions/26167023/reduce-cordova-apks-size
- 431 ：デフォルトの名無しさん：2021/01/06(水) 15:01:07.35 ID:twxSQNJZ.net
- CordovaはAdobeが投資を引き上げて後は終焉を待つ状態なので
5年前ならいざ知らず今から新規に採用するようなものじゃない
本当にクロスプラットフォームの土台となりうるなら
AdobeがPhoneGap終わらせてCordovaからも手を引いたりしないよね
- 432 ：デフォルトの名無しさん：2021/01/06(水) 15:31:36.33 ID:Y7FOu5Ta.net
- そもそもcordovaはionicに負けてしかも日本ではそのどっちも流行ったことないでしょ。
何年前の技術語ってんだ浦島太郎かよ。
- 433 ：デフォルトの名無しさん：2021/01/06(水) 15:34:10.93 ID:N9dyrfHy.net
- 久しぶりに聞いたな
- 434 ：デフォルトの名無しさん：2021/01/06(水) 16:05:53.56 ID:twxSQNJZ.net
- >>432
Ionicは基本的にCordova使う前提のフレームワークだぞ
- 435 ：デフォルトの名無しさん：2021/01/06(水) 17:36:23.26 ID:IwWtN5mv.net
- オンプレ爺とCordova爺は同一人物？
- 436 ：デフォルトの名無しさん：2021/01/06(水) 17:55:22.98 ID:ATHWudiV.net
- スクリプト系言語は総じてクソだぞ爺さんと同一人物
- 437 ：デフォルトの名無しさん：2021/01/06(水) 18:22:10.23 ID:IwWtN5mv.net
- あーそっちの方かサンガツ
- 438 ：デフォルトの名無しさん：2021/01/06(水) 22:02:50.48 ID:YZSk0OOW.net
- >>435-437
アホだなおまえら
CordovaはJSだぞ
CordovaがJSなの知らないほど無知
むしろその人にFirewalｌ警告などの問題点を指摘した。
オンプレミス派は頭いいから基本的に高速な言語を好む
- 439 ：デフォルトの名無しさん：2021/01/06(水) 22:31:39.93 ID:ge6MZGJO.net
- いつものザマオンプレ爺さん定期
- 440 ：デフォルトの名無しさん：2021/01/06(水) 22:37:55.13 ID:YZSk0OOW.net
- >>439
爺さんではなくおにいさん定期
Xamarin評判悪いからUnityもやる
- 441 ：デフォルトの名無しさん：2021/01/06(水) 23:43:33.16 ID:k0vOylQ2.net
- オンプレ爺さんまだいたのか
- 442 ：デフォルトの名無しさん：2021/01/07(木) 01:52:20.73 ID:3TLTtAUE.net
- 「まだクラウドじゃないんですか？」で金を取り、
「これからはむしろオンプレですよ」でまた金を取る。
これを永久に繰り返す錬金術ｗ
企業が「脱クラウド」「オンプレ回帰」に踏み切る理由
https://www.itmedia.co.jp/enterprise/spv/2101/05/news002.html
- 443 ：デフォルトの名無しさん：2021/01/07(木) 15:03:31.98 ID:BLvEhbF6.net
- >>442
やっと事実を伝える記事が増えてきたか。
パブリッククラウドは時代遅れなんて経験あるエンジニアには常識
遅いし高いしろくでもない
- 444 ：デフォルトの名無しさん：2021/01/07(木) 16:28:53.05 ID:jfoKMLtR.net
- >>443
自演乙
- 445 ：デフォルトの名無しさん：2021/01/07(木) 21:50:05.56 ID:DHxcg4pM.net
- 老害回避用に下記単語のNGワード設定を推奨
オンプレ
Xamarin
Cordova
- 446 ：デフォルトの名無しさん：2021/01/07(木) 22:40:27.59 ID:BLvEhbF6.net
- >>444
こんなことで自演するかよｗバカｗ
クラウドがクソなんてスキルある人には常識
- 447 ：デフォルトの名無しさん：2021/01/07(木) 23:10:55.02 ID:c5+YjLRl.net
- しつけーなジジイ
何度も5ch覗きに来んな無能ハゲ
- 448 ：デフォルトの名無しさん：2021/01/08(金) 06:54:41.89 ID:eHuqAzdP.net
- クラウド爺さんは二人いたんだなあ
- 449 ：デフォルトの名無しさん：2021/01/08(金) 11:40:03.05 ID:hbHr5ZSG.net
- Cordva騒いでた人＝オンプレ爺だったのかよ
本気で気付いてなかった自分を殴りたい
- 450 ：デフォルトの名無しさん：2021/01/08(金) 12:07:35.03 ID:MOpHGUBr.net
- >>449
夏くらいまで自分を殴ってていいよ
- 451 ：デフォルトの名無しさん：2021/01/08(金) 12:18:27.99 ID:5RCoenNw.net
- >>449
ちがうつってんだろバカ
それぞれの技術の特徴しってたら間違えようがないんだけどな
>>438読め
File API使いたければ素直にnative使え、
http serverはfirewallが警告出す、
とまっとうなレスいれたのがおまえらがオンプレおにいさんと呼ぶ奴だ。
俺はC#やKotlin, Swiftのような言語を好む
スクリプトしかできないやつ、クラウド頼みのやつをバカにしてきてるのに
JSで時代遅れなCordovaなんて使うわけがない
node.jsもdisってきている。
- 452 ：デフォルトの名無しさん：2021/01/08(金) 13:55:28.48 ID:9vpDWgh3.net
- >>451
ところがWasmでcordovaを使うのは最新なんだな、これが。
というよりまだ誰もやってない。
- 453 ：デフォルトの名無しさん：2021/01/08(金) 13:59:08.83 ID:MOpHGUBr.net
- >>451
クラウド頼みをバカにしてるってことは…ひょっとすると君もオンプレ爺さんなのかい！？
- 454 ：デフォルトの名無しさん：2021/01/08(金) 14:20:11.98 ID:9vpDWgh3.net
- いまのところWASIはグラフィック出力が出来ないし、
wasmerは、CUIのWASIだけで、しかも今最も肝心なiOSやAndroidでは
それすらも動かない。
が、Cordovaを使えばWASIをモバイルも含めたあらゆるプラットフォームで
グラフィック付きで動かすことが出来るようになるに違いない。
- 455 ：デフォルトの名無しさん：2021/01/08(金) 16:22:21.34 ID:5RCoenNw.net
- >>452
新しければいいわけじゃない。
C#, C++のように古くても必要とされる技術がある。
wasmは新しいが必要性がない。
手数料回避以外にメリットがない
大手が採用してないだろ
まだ時期尚早
wasmはIT大手が使い始めてからでよい
それまでnativeの学習するのが賢い
- 456 ：デフォルトの名無しさん：2021/01/08(金) 16:49:03.26 ID:F+SpYfrf.net
- >>455
1. HTML+JS+Wasmの部分は、出力バイナリがプラットフォームが変わっても
変わらないという特徴があるのでビルド結果をバックアップするのは楽。
ただし、Cordova方式の場合は、*.apkなどにパッケージ化する際にプラットフォーム
依存になってしまうが。
2. GTKやQtなどは自分でグラフィック部分も各OSに合わせて用意しているのでサイズが
大きいし、ツールキットを作るのも大変だが、Wasmの場合、HTML5のcanvasを
使えばその部分が不要なので、ツールキットが作り安いし、サイズが小さい。
- 457 ：デフォルトの名無しさん：2021/01/08(金) 19:42:08.00 ID:5RCoenNw.net
- >>456
しつこくCordova推してるけどうざがられてるだけだぞ。
BlazorはJSが嫌いでC#が好きな人が興味持ってるんだから
ここでJS系の技術を推すのはナンセンス
その特殊なスタックを推したければBlogなりYouTubeなり
GitHubでやってくれ
- 458 ：デフォルトの名無しさん：2021/01/08(金) 21:32:03.22 ID:eX99CYJf.net
- node.jsなんか使いたくもないわ
- 459 ：デフォルトの名無しさん：2021/01/08(金) 22:21:40.37 ID:1X0kULwm.net
- >>457
ザマ爺てめえも同じくらいうざがられてるから率先してスレから消えろや
目くそ鼻くその分際で粋がるんじゃねえ
- 460 ：デフォルトの名無しさん：2021/01/09(土) 12:38:53.91 ID:hogOqFTZ.net
- >>459
ほんとアホだな
おまえらが俺のことを書かなければ気が付くようなレスはしない。
当面Wasmでコード書くこともないしこのスレ読みたくないんだが
おまえみたいに俺の話題を書くからいつまでも続く
>>458
JS全部だろう
nativeやればいいだけ。まともな言語だらけ
C#, Kotlin, Swift
- 461 ：デフォルトの名無しさん：2021/01/09(土) 15:19:24.66 ID:X2U+K+I4.net
- だれか登場人物と相関図を整理してくれ
ザマリン爺さんとオンプレ兄さんが恋敵なのはわかった
- 462 ：デフォルトの名無しさん：2021/01/09(土) 16:45:25.64 ID:jYiNSutT.net
- 考えるの面倒だからまともに読んでない
- 463 ：デフォルトの名無しさん：2021/01/09(土) 18:02:30.85 ID:4SmuPkRr.net
- >>461
正確にはザマオンプレ爺な
スキルセットの古さから推定年齢50代後半、最近ようやくザマリンの不人気に気付いたというアホ
もう一人はCordova爺、とはいっても意外に若いかもしれない年齢不詳
こいつはザマ爺とは異なり知識は深い、が偏りすぎてて職場にいると面倒くさいタイプ
- 464 ：デフォルトの名無しさん：2021/01/09(土) 21:00:29.31 ID:V/x0GCIg.net
- ここは老人たちを隔離するために作られたスレ
あきらめて仲良く雑談しなさい
- 465 ：デフォルトの名無しさん：2021/01/09(土) 23:20:48.56 ID:hogOqFTZ.net
- >>463 >>461
ほらな、こうやって俺の話題しか話せないような
スキルない奴がすぐ湧いてくる
C#とKotlinとSwift推してる俺のスキルセットが古いって
脳みそくさりすぎだろｗ
- 466 ：デフォルトの名無しさん：2021/01/09(土) 23:24:24.77 ID:hogOqFTZ.net
- それとXamarinはシェア５位で不人気でもなんでもない。
人気のあるフレームワークだ
>>463のアホはモバイルアプリ開発経験ゼロだろう
言語がゴミなFlutterよりもXamarin/MAUIは伸びしろがある。
- 467 ：デフォルトの名無しさん：2021/01/10(日) 02:57:31.92 ID:mWh+kAw4.net
- ザマ爺、お前のハッタリは聞き飽きたよｗ
- 468 ：デフォルトの名無しさん：2021/01/10(日) 03:21:58.38 ID:t4oThHgn.net
- https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours/
- 469 ：デフォルトの名無しさん：2021/01/10(日) 03:46:34.61 ID:79osdvS+.net
- >>468
(上位から大きく離れてシェア急落中の)5位だからなw不人気では無いなw
あっという間にflutterに追い抜かれてxamarinファンには面白くないかもしれんが
エンジニアならフェアに判断しようや
- 470 ：デフォルトの名無しさん：2021/01/10(日) 09:23:59.56 ID:osL1god/.net
- オンプレ爺、C#とXamarin使いの設定だったのがしれっとKotlin・Swiftまで追加してるじゃん！？
雑談スレだから今まで見逃してたけれども調子に乗って吹かしてると張り倒すぞこの野郎
- 471 ：デフォルトの名無しさん：2021/01/10(日) 09:38:16.74 ID:TUlvVbF7.net
- >>468
シェア５位のソース張りおつかれ
>>469
おまえみたいなバカは単純にシェアでしか判断できない。
Flutter(Dart)は言語がクソで有名だ。
複雑なコードを書こうとしたら言語が足を引っ張る
React Native, Cordova, IonicはJSでクソ。
- 472 ：デフォルトの名無しさん：2021/01/10(日) 09:40:57.52 ID:TUlvVbF7.net
- >>470
ここC#系のスレだからXamarinよく書いてただけだハゲ
ここのやつらスキルないしKotlinの知識ゼロだしな
実際はKotlin推し
- 473 ：デフォルトの名無しさん：2021/01/10(日) 10:58:09.59 ID:SrWqbjf1.net
- >>471
なるほど賢く優秀だと1年でシェア26%から14%にほぼ半減しても判断材料にしないよなw
Flutterは言語がクソ(根拠示さず)で有名(根拠示さず)だから影響ないよなw
>複雑なコードを書こうとしたら言語が足を引っ張る
足引っ張ってるのは言語なのか？実は”誰か”だったりしないか？w
>React Native, Cordova, IonicはJSでクソ。
MSのスマホアプリはクソのReact Nativeで実装してるけどなw
不思議だなw
- 474 ：デフォルトの名無しさん：2021/01/10(日) 11:54:35.09 ID:GMn9HNNA.net
- Native推すってことは
C#でのWEBアプリ開発はイマイチって思ってるってことなのかな
その辺はjs系言語に一日の長ありということを認めてるよね。
Blazorはjs系言語いまさら覚えられませんって人向けだと思うわ
おれのことだけど。
- 475 ：デフォルトの名無しさん：2021/01/10(日) 12:11:41.51 ID:ZqyUOoXz.net
- Blazorで出来る事は限られてるよ。
ちょっとした事ですぐ
js面に手を出すことになって、
そんとき浦島太郎だ！
- 476 ：デフォルトの名無しさん：2021/01/10(日) 16:17:36.42 ID:TUlvVbF7.net
- >>473
それはcross-platformはろくなのがないからだよ
１年で半減もあるし逆に１年で5倍もありうる状態
React NativeもXamarinもバグが多かったりで
まともに使えないのがたくさんある。
Flutterも消去法で選ばれてるだけ
Flutter使ってるやつらもDartがクソだと認めてる
言語がだめだと結局消えるのを俺はわかってるから手を出さない。
- 477 ：デフォルトの名無しさん：2021/01/10(日) 16:24:36.33 ID:TUlvVbF7.net
- >>473
最終行
既存アプリはXamarin買収する前に開発スタートしてたんだろ。
MAUIが実用レベルになればMSもMAUIでアプリ作るようになるはずだし
そもそもMSが自社で使ってるかどうかはどうでもいい話
ほかの会社のアプリが十分に使ってればそれでいい
- 478 ：デフォルトの名無しさん：2021/01/10(日) 16:37:25.68 ID:TUlvVbF7.net
- >>474
wasmには期待していたがBlazor wasmさわって
すぐJS不要にできる状況ではない、とすぐわかった。
数年後はわからんが今はだめ
web appはJS以外にもCSSとか生産性低い要素が
あるから好きではない。
nativeなら会社以外の時間にひとりで開発してマネタイズ
できるからnativeの時間を増やしているというだけ。
- 479 ：デフォルトの名無しさん：2021/01/10(日) 17:03:22.02 ID:GMn9HNNA.net
- >>478
BlazorServerは？
作ってるのがオフラインでも動くようなアプリなんだったらwasmやNativeなのはわかるけど。
- 480 ：デフォルトの名無しさん：2021/01/10(日) 17:14:24.46 ID:TUlvVbF7.net
- >>479
Blazor Serverはスケールしないから好きじゃない。
ステートフルは時代遅れだと思うわ
前にも指摘したがBlazor ServerはMSが
Azureで儲けるための技術と見ている。
俺は不特定多数向けサービス作ってるから
スケールしない技術に興味はない。
サーバーに負荷が集中しすぎるアーキテクチャ。
企業内システムで使う分にはいいんじゃないの
同時接続が予測できる範囲ならってこと
- 481 ：デフォルトの名無しさん：2021/01/10(日) 17:39:06.95 ID:GMn9HNNA.net
- >>480
なんとなくあなたの選択肢はTypeScript+Reactだと思うよ
js系言語がクソだと言うがTypeScriptなら大丈夫なんじゃないの
多分少し触っただけでクソだと言ってるのでは？そこまでガッツリやってないという印象。
- 482 ：デフォルトの名無しさん：2021/01/10(日) 23:28:55.11 ID:IfLhCjnV.net
- TypeScriptもJavaScruptと全く別の言語ってわけじゃないからなぁ
結局JavaScriptわかってないと困る場面が出てくる気がする
- 483 ：デフォルトの名無しさん：2021/01/10(日) 23:38:06.59 ID:re1lSACU.net
- MS オフィスアプリはreact nativeで作られてるってマジ？
- 484 ：デフォルトの名無しさん：2021/01/11(月) 15:07:17.31 ID:aEN5u7j8.net
- raspberry pi 4で.NET動いたー
- 485 ：デフォルトの名無しさん：2021/01/11(月) 22:15:13.04 ID:NARwS4T4.net
- >>481
web appの開発生産性の低さの理由はJS以外にもある。
犯人はHTML, CSS。
Web designは得意じゃないからReactみたいに
frontendのコード書くのが苦痛で仕方ない。
smartphone、windowsのnative appはそういった苦痛がないんだな
C#/Kotlin/Swift, 言語は全部、静的だしめんどくさいCSSはない。
おれには天国
- 486 ：デフォルトの名無しさん：2021/01/11(月) 22:16:12.48 ID:NARwS4T4.net
- SP appだけリリースしてweb appは出さないっていうサービス増えてるよな？
そういう割り切りって大事だと思う
みんなブラウザに固執しすぎですわ
- 487 ：デフォルトの名無しさん：2021/01/12(火) 00:22:24.81 ID:frmHOofW.net
- いやリリースしてるのがスマホアプリだけでも技術的には完全にWebベースのものがほとんどだよ
- 488 ：デフォルトの名無しさん：2021/01/12(火) 08:23:25.72 ID:YVBPDvLm.net
- >>485
わかる
なんでこんな複雑怪奇なものにリソースを割かないといけないんだ？って気持ちになる
Web系エンジニアってすごい忍耐力があるとおもうわ
しかしWebアプリからは逃げられない…
- 489 ：デフォルトの名無しさん：2021/01/12(火) 13:57:46.77 ID:gN/Az5jH.net
- Webアプリの苦痛はブラウザ毎のHTML/JS/CSSの対応バージョン考慮しないといけないとこだよね。
仕事だからやってるけどクッソめんどい。
全ブラウザが常に最新のJS/CSSフルサポートしてくれれば何の文句もないんだけど。
あと、ブラウザのオプション設定とかセキュリティソフトのせいで微妙に想定外の動作するとか勘弁してほしい。
パッケージソフトならRuntime同梱で割とどうにでもなってたのに・・・
- 490 ：デフォルトの名無しさん：2021/01/12(火) 15:24:59.60 ID:Tnz9LnkQ.net
- >>488
>>489
ようはwebエンジニア未満って事では...。
- 491 ：デフォルトの名無しさん：2021/01/12(火) 16:03:19.01 ID:651NdeAm.net
- >>488
web app嫌いなら逃げたっていいだろう
自社で解決しなけりゃモバイル知識つけて転職すりゃいい
あとAndroid, iOS appエンジニアもWebエンジニアだし
>>490
それはない
web appのbackendしかやらない人もwebエンジニアだし
- 492 ：デフォルトの名無しさん：2021/01/12(火) 17:46:56.35 ID:Ao5nGZOO.net
- >>490
いやなんとなくvb5とかvbaの臭いがするんだよな…
型が使えるだけで喜んでる人たちだし
- 493 ：デフォルトの名無しさん：2021/01/12(火) 18:24:03.86 ID:DnpTcmq6.net
- また言い合いを誘ってるだけのくそレスか
- 494 ：デフォルトの名無しさん：2021/01/13(水) 21:21:51.49 ID:qDmikOjf.net
- うだつの上がらない底辺の巣窟ですからｗｗｗ
- 495 ：デフォルトの名無しさん：2021/01/13(水) 21:57:45.94 ID:jEePmYlx.net
- >>494
型が使えて嬉しい？
- 496 ：デフォルトの名無しさん：2021/01/13(水) 22:15:04.99 ID:cdnuNNke.net
- パッケージソフトばっか作ってた時代はWebアプリのメリットとか楽しさ全く分からんかった。
今はソフトの設定画面とかはChromium使ってWeb風にしてる。
JQueryやVue.jsでGUI実装する楽さと柔軟さは圧倒的(Reactは使ったことないから知らん)
ただし対応ブラウザのバージョンとか設定とか気にし始めると精神擦り減るから純粋なWebアプリはきつい。
- 497 ：デフォルトの名無しさん：2021/01/16(土) 13:20:28.52 ID:ZWdP8vPv.net
- C#は、値型/参照型/参照渡し関連がごちゃごちゃしているな。
Cのポインタが理解できない人が多いと聞いたが、彼らには、
C#のstructとclassで値型と参照型の違いが有ったり、参照渡しの
概念はそれらとは別にあったりすることや、DeppCopyとShallowCopy
の違い、代入演算子=で何が起きるかなどを正しく理解できるのだろうか？
- 498 ：デフォルトの名無しさん：2021/01/16(土) 17:33:27.69 ID:dh/EnmR5.net
- >>497
できますよ
- 499 ：デフォルトの名無しさん：2021/01/21(木) 10:59:39.61 ID:NpE+5Spi.net
- Blazor WebAssembly App の PWA で、FormでいうKeyPreviewのように、どのコンロトール上にフォーカスがあっても、キー入力のイベントを取得できるのでしょうか。
キーボードインターフェイスのバーコードリーダの入力を、テキストボックスに入力する以外の方法で行いたいのです。
div上にフォーカスが存在する場合は取れたのですが・・・
- 500 ：デフォルトの名無しさん：2021/01/21(木) 12:09:27.74 ID:084E4D0G.net
- あれ？C#さえ分かれば使えるのでは？
- 501 ：デフォルトの名無しさん：2021/01/24(日) 09:43:03.07 ID:EXqklOpv.net
- asp.net mvcのスキャフォールディングを使ってコード生成してくれる機能すごい便利と思ってたけど
Blazorにないのはなんでなんだろう
流行りじゃなくなったから？
- 502 ：デフォルトの名無しさん：2021/01/25(月) 23:24:35.92 ID:vuFdTYWI.net
- <inpu
- 503 ：デフォルトの名無しさん：2021/01/26(火) 00:14:54.94 ID:qSdfocRR.net
- >>501
基本的に1モデルに対して一枚のHTMLを作ればよい古典的なWebMVCに対して、
Blazorというか仮想DOM系フレームワークはビューの論理構造に合わせて積極的にコンポーネントを分割、ネストしていくんだよ
要件によって全然違った構造になるんでスキャフォールドなんか役に立たない
- 504 ：デフォルトの名無しさん：2021/01/30(土) 12:52:21.79 ID:gpuCWU5d.net
- >>503
業務系だとほとんどの場合1モデルに対して1HTML（というかスキャフォールドでできる例の一式）なんだけどな
たまにややこしいUIがある。
MVCにBlazorを組み込めるようになったら捗るのに。
- 505 ：デフォルトの名無しさん：2021/01/30(土) 13:22:26.04 ID:VnS/Ic0u.net
- scriptブロックにC#を使えるだけでもだいぶ楽になるはずなんだがね…
SPAとセットみたいな扱いなのが残念
- 506 ：デフォルトの名無しさん：2021/01/30(土) 14:04:23.64 ID:NIBr3ao+.net
- MS技術は開発環境を過剰に整備しすぎて、複数のものを柔軟に組み合わせて利用することが困難になってることが多いよね
- 507 ：デフォルトの名無しさん：2021/01/30(土) 14:30:26.39 ID:qqS09RJU.net
- かといってAndroidStudioみたいに、独立したツールを寄せ集められても困る。
1つツールをバージョンアップすると謎のエラーが出まくるとかあるし。
AndroidStudioはバージョンアップ恐怖症だわ
- 508 ：デフォルトの名無しさん：2021/01/30(土) 20:09:20.29 ID:lNvH5Mw3.net
- >>506
Angularが廃れたのと同じ失敗繰り返してるよね…
- 509 ：デフォルトの名無しさん：2021/01/30(土) 21:19:43.17 ID:vJSVoVkS.net
- >>506
そうか？
- 510 ：デフォルトの名無しさん：2021/01/30(土) 21:20:08.48 ID:vJSVoVkS.net
- >>507
わかる
- 511 ：デフォルトの名無しさん：2021/02/28(日) 09:30:22.76 ID:hkX3n4ku.net
- >>506
なんか困難な部分あるっけ？
- 512 ：デフォルトの名無しさん：2021/03/19(金) 22:58:18.25 ID:2/KUxY5q.net
- html部分もxamlで書ける未来は来ますか？
- 513 ：デフォルトの名無しさん：2021/03/20(土) 00:24:36.28 ID:pCJbHtqc.net
- こない
- 514 ：デフォルトの名無しさん：2021/03/20(土) 00:51:40.10 ID:N0CH58op.net
- xhtmlが生き残っていたらそういう未来もあったんだろうなあ
- 515 ：デフォルトの名無しさん：2021/03/20(土) 08:51:30.66 ID:pCJbHtqc.net
- ない
- 516 ：デフォルトの名無しさん：2021/03/29(月) 22:08:00.80 ID:FV93VuwM.net
- reactっていうかJSXっぽいblazorが欲しい
MVVMは微妙だ
- 517 ：デフォルトの名無しさん：2021/05/17(月) 01:03:56.89 ID:pKrWHb4H.net
- うわーん
子コンポーネントに追加したCSSが適用されて
くれないよおおお
- 518 ：デフォルトの名無しさん：2021/05/17(月) 01:12:01.56 ID:DJO6l4LT.net
- へ？
- 519 ：デフォルトの名無しさん：2021/05/17(月) 06:43:56.79 ID:CJj7zo9G.net
- >>517
Ctrl + F5
- 520 ：デフォルトの名無しさん：2021/05/17(月) 10:47:38.82 ID:pKrWHb4H.net
- >>519
ちゃんとビルドはしてるんだけど
コンポーネント用に追加したCSSの内容が
反映されない
インテリセンスは効いてるし場所がおかしい
わけではないと思うんだけど
- 521 ：デフォルトの名無しさん：2021/05/17(月) 10:59:05.90 ID:CJj7zo9G.net
- >>520
ブラウザで表示中にCtrl+F5の意味だったんだけど。
cssはキャッシュされるから、クリアするか、強制再読み込みさせないと反映されない。
- 522 ：デフォルトの名無しさん：2021/05/17(月) 11:53:15.23 ID:pKrWHb4H.net
- >>521
やってみたけどダメっす
*.razor.cssを置くだけだよね？
- 523 ：デフォルトの名無しさん：2021/05/17(月) 11:58:38.84 ID:pKrWHb4H.net
- 原因わかった
Layout.cshtmlに*.styles.cssを置いてなかった
ありがとう
- 524 ：デフォルトの名無しさん：2021/05/18(火) 10:26:38.81 ID:6Jx3mCkU.net
- 動的にelementを作成し、IDを割り振っているのですが、IDから検索したelementに対してclassを追加/削除を行なう事はできますか？
jQueryだと $("#id名").addClass('class名') / $("#id名").removeClass('class名') とやれば出来ると思うのですが、できるだけJavaScriptは使いたくありません。
- 525 ：デフォルトの名無しさん：2021/05/18(火) 12:24:53.93 ID:IKQP0yKv.net
- なんでそんな罰ゲーやってんの？
- 526 ：デフォルトの名無しさん：2021/05/19(水) 09:45:24.37 ID:vAevRKi/.net
- Blazorise とか DevExpress を使えば もっと快適に開発できるのに何で
- 527 ：デフォルトの名無しさん：2021/05/19(水) 12:39:30.36 ID:BIRmA78o.net
- そもそも Blazor で Id 振る必要ってある？
@ref で大抵解決するんじゃ？
- 528 ：デフォルトの名無しさん：2021/05/19(水) 15:39:11.78 ID:BIRmA78o.net
- 多分エラーチェックでエラー表示したいンだろうけど
バリデーションチェックでほとんど出来るし
いざとなればボタン押下時のチェックで
@refで定義したコントロールの
Cssをc#側で書き換えてやれば良い
- 529 ：デフォルトの名無しさん：2021/05/20(木) 00:14:09.50 ID:rMZEEvKV.net
- >>526
やり始めたばかりで、知識が足りないからです。
2つの単語をぐぐって調べてみます。
>>527,528
@refでElementReferenceの取得は出来ているのですが、ElementReferenceに対しての操作がわからないのです。
.NET5 から SetFocus が使えるようになったという程度の知識です。
CSSを書き換える具体的なコードをご教示していただけませんか？
- 530 ：デフォルトの名無しさん：2021/05/20(木) 03:45:22.57 ID:hYXifQvY.net
- DevExpress は有償だけどお試しが出来る Blazorise 無償でも使えたはず
DevExpress の場合
Razor
<DxTextBox @bind-InputCssClass="@CssClass"></DxTextBox>
c#
string CssClass = "";
実行チェックで
CssClass = ????
ただし、入力チェックはフォームのバリデーションチェックのみが基本
実行時のエラーはエラーダイアログかアラートで表示
- 531 ：デフォルトの名無しさん：2021/05/20(木) 09:55:17.44 ID:rMZEEvKV.net
- >>530
ご教示ありがとうございます。
これまでVB.Netで、デスクトップばっかやってきたので、ASPとかウェブアプリとか手探り状態でやっているので
定番の方法をネットで調べながら悪戦苦闘しています。
アドバイスもありがとうございました。
- 532 ：デフォルトの名無しさん：2021/05/21(金) 13:30:50.82 ID:3pnf2HoY.net
- 初めてのウェブアプリで.netはきついな
- 533 ：デフォルトの名無しさん：2021/05/26(水) 23:28:38.59 ID:o92StIuL.net
- 初歩的な質問ですいません
Blazor Serverの勉強をしています
テンプレートのDataフォルダ以下に自分で作ったjsonファイルを配置しました
ページにこのjsonファイルの内容を読み出し、表示したいと考えています
HttpRequestMessage(HttpMethod Get, "ファイルパス")を使って、その後SendAsyncを呼び出すコードを書いたのですが「Sorry, there's nothing at this address.」と表示れファイルを認識していないようです
ブラウザにファイルパスを入力するとjsonファイルは表示されるのでパスが間違っているわけではなさそうです
読み出す方法自体が間違っているのでしょうか？
初歩的な内容で申し訳ありませんがアドバイス頂けたら幸いです
- 534 ：デフォルトの名無しさん：2021/05/28(金) 16:15:02.73 ID:xaI11mjw.net
- 参考
https://www.syncfusion.com/faq/blazor/web-api/how-do-i-read-a-json-file-in-blazor-webassembly
- 535 ：デフォルトの名無しさん：2021/06/07(月) 16:17:45.72 ID:Z0RJUhSU.net
- Blazor Serverサイドで、自分自身の再起動って出来ますか？
起動時の設定を画面から行った際に、自動的に再起動できればうれしいんだけど・・・
- 536 ：デフォルトの名無しさん：2021/06/07(月) 16:24:10.54 ID:wYqzuJ+k.net
- 自分自身の再起動？？
- 537 ：デフォルトの名無しさん：2021/06/07(月) 16:33:08.67 ID:rkNZY3be.net
- >>535
HttpRuntime.UnloadAppDomain
はどう？
- 538 ：デフォルトの名無しさん：2021/06/07(月) 16:39:01.06 ID:rkNZY3be.net
- >>537
あ、ASP.NET Coreでは非対応だった
- 539 ：デフォルトの名無しさん：2021/06/07(月) 17:12:25.16 ID:wYqzuJ+k.net
- IHostApplicationLifetime
- 540 ：デフォルトの名無しさん：2021/06/07(月) 18:22:24.87 ID:nUdOwg5l.net
- 勉強に題材に出来そうなアプリないかな
気軽にこういうの作ってみようって思い浮かばないんだよな
- 541 ：デフォルトの名無しさん：2021/06/07(月) 18:24:24.42 ID:jYDIVOJV.net
- >>540
マイクロソフトが公開してるサンプルアプリ取得すれば
- 542 ：デフォルトの名無しさん：2021/06/14(月) 14:00:07.30 ID:qkTbMiy1.net
- DevExpressのお試しインストールして
AWSに 適当に作ったのアップすれば？
- 543 ：デフォルトの名無しさん：2021/07/18(日) 14:10:32.49 ID:9iW5ZKc1.net
- .Net含めWeb周りもど素人なんだけど、
Blazor WASM 勉強中で教えてもらいたいんだが、
css変数でレイアウト制御しようと思ってて、
変数の環境汚染防ぐために属性セレクタでhtmlタグの末尾に自動追記されるコンポーネント毎にuniqueな属性？を指定したいんだけど、そんなプロパティある？
やっぱJS通して取得するしかないんかなぁ
そこまでするならやらない方が良いだろうし...
- 544 ：デフォルトの名無しさん：2021/07/21(水) 15:37:46.74 ID:xVY5rD/0.net
- >>543
hoge.razor.css じゃダメなん？
- 545 ：デフォルトの名無しさん：2021/07/21(水) 17:52:24.05 ID:VIIGeUce.net
- Reactでok!
本家でもやってるし
- 546 ：デフォルトの名無しさん：2021/07/22(木) 13:23:04.73 ID:l3sHUd0A.net
- >>544
VsCodeでCLI含め勉強してるんだが、
Razorファイル側でないと、コンパイル通らなくて変数読めなかったんだよなぁ
書き方が悪かったのか..?
>>545
JSのトレンドってその時々で変わるイメージだし、
JS食わず嫌いでBlazor始めたのに、JSライブラリの沼に浸かりたくない...
- 547 ：デフォルトの名無しさん：2021/07/22(木) 13:51:47.93 ID:25FL4ybp.net
- >>546
webやるのにjsはマストですよ
- 548 ：デフォルトの名無しさん：2021/07/22(木) 17:30:50.12 ID:ISgGWg0R.net
- >>547
現時点ではそうだね
今後も覇権は変わっていくだろうけど
- 549 ：デフォルトの名無しさん：2021/07/22(木) 19:23:58.05 ID:l3sHUd0A.net
- WASM - ブラウザ間のラッパーとして使うなら未だしも、
ライブラリに依存しちゃうとその変更を追わなきゃいけないのがなぁ
⁇?「jQueryは嫌だ…」
⁇?「Vue.jsは嫌だ…！」
⁇?「Reactは嫌だっ！」
- 550 ：デフォルトの名無しさん：2021/07/22(木) 19:49:02.66 ID:vwDpdZeF.net
- jsライブラリは素のjsで書くとめんどくさいからライブラリを使ってる
c#オンリーで書いたとしたら素のjsで書いた時と同じことにぶち当たる
じゃあ結局ｊｓとts学んでライブラリ使ったほうがよくねと言うこと
blazorは普通に流行らないし使う人もほぼいないでフェードアウトする
- 551 ：デフォルトの名無しさん：2021/07/22(木) 20:11:52.16 ID:vwDpdZeF.net
- blazor向けに超絶便利なライブラリーをMSが作って普及させればワンチャンあるかもレベル
その場合でもHTMLとｃｓｓとjsの知識は必要
- 552 ：デフォルトの名無しさん：2021/07/22(木) 23:36:33.58 ID:2i9Z6Xhw.net
- webならjsがマストなのに
そこにコンパイル言語ぶっ込む真意はなに？
- 553 ：デフォルトの名無しさん：2021/07/23(金) 02:01:12.53 ID:sECHlIz3.net
- jsが糞言語だから
- 554 ：デフォルトの名無しさん：2021/07/23(金) 03:45:12.09 ID:YZkweKMA.net
- Blazorが流行るかどうかとWasmが流行るかどうかは全く別の問題だ。
結局、Wasm以外選択肢が無いのでWasmは流行るだろう。
- 555 ：デフォルトの名無しさん：2021/07/23(金) 03:52:06.77 ID:YZkweKMA.net
- nativeアプリよりずっとセキュアなのにnativeアプリと同じ言語で書けるという
点と、ググると即座に使えるという点が今後のアプリ開発をWasm化していく
原動力になることだろう。ググる方がデスクトップのアイコンを探すより速いし。
- 556 ：デフォルトの名無しさん：2021/07/23(金) 03:54:48.13 ID:YZkweKMA.net
- Wasmアプリは、今までのC/C++資産を全て受け継げるのに、nativeアプリより
遥かにセキュアになること、速度はnativeアプリと余り差がないこと、
1つ作るだけでWindows/Mac/iOS/Android/Linuxなど全てのOSで使えること、
などが非常に重要な点となる。
- 557 ：デフォルトの名無しさん：2021/07/23(金) 04:06:31.26 ID:YZkweKMA.net
- JSだと少なくともC/C++と比べるとどうしても遅くなるので、どうしても
C/C++製のnativeアプリに比べて不利になる。その意味でWasmの
ブラウザ上アプリはJSアプリに比べて有利。
- 558 ：デフォルトの名無しさん：2021/07/23(金) 13:08:29.55 ID:YZkweKMA.net
- ただし、それはC/C++をWasm化した場合であってBlazorには当てはまらないが。
- 559 ：デフォルトの名無しさん：2021/07/23(金) 14:10:39.28 ID:Nx0yKcVz.net
- 結局は、便利なライブラリ・モジュールがあるかどうか。
ある機能の関数が欲しい時に、自作できないから
それで結局、Ruby on Rails みたいに、すべて揃っているものを使う。
さらに、デザインパターンも決まっているから考える必要がない
- 560 ：デフォルトの名無しさん：2021/07/23(金) 16:18:02.69 ID:LbRveJOa.net
- >>559
それって楽しいか？
- 561 ：デフォルトの名無しさん：2021/07/24(土) 11:02:57.33 ID:Bn7tmXAV.net
- 楽しくてやってるのか？個人でやる分にはいいが…
おれみたいにデスクトップアプリをWebアプリ化したいが、
チームにC#の経験者が多い、Typescriptの習得に時間を割けない
というネガティブな理由でBlazorを検討するやつは多いはずだ
- 562 ：デフォルトの名無しさん：2021/07/24(土) 13:35:26.86 ID:8X55Gw1w.net
- >>561
それが限定的で超短期的な避難措置ならわかるが
将来を見据えてみんなtsに移行したほうが絶対良い
時間を割けない経営側の判断がおかしいと思う
能力の限界が来て移行できない人はいらない人とまでは言わないがもうアプリレベルの開発はもういいかなと
Blazorって多分後2年持たないと思うのでそんなのを移行先にしてはいけない
- 563 ：デフォルトの名無しさん：2021/07/24(土) 13:44:25.48 ID:1w6sRCas.net
- tsってc#見たいで
もっと柔軟でc#じゃ出来ないような事も出来て
言語としておもろいですよ
- 564 ：デフォルトの名無しさん：2021/07/24(土) 13:49:24.79 ID:8X55Gw1w.net
- 面白いけど基本的にjsの弱点を補うためにおかしな仕様になってる
型が柔軟になってて中で何度も型判定したり意味ねえよって思う
- 565 ：デフォルトの名無しさん：2021/07/24(土) 13:59:20.60 ID:Py2hfFQF.net
- voidとany nullとundefined
特に受け付けないのが
hoge: string='';
if(hoge)がfalse
C#からの移行はかなり厳しいと思うｗ
- 566 ：デフォルトの名無しさん：2021/07/24(土) 14:00:13.27 ID:8X55Gw1w.net
- といいつつ今はそんなにts触らないので流れが全く分からない
tsの仕様の細かいところまで全部追えてる人間はそういないと思う
思い付きレベルにしか思えない機能を入れたり仕様変更したり忙しかったけど今も同じなのかは知らない
- 567 ：デフォルトの名無しさん：2021/07/24(土) 15:21:34.25 ID:1w6sRCas.net
- >>564
形無し言語も多い中で
贅沢言わんことだよ
- 568 ：デフォルトの名無しさん：2021/07/24(土) 15:24:29.17 ID:1w6sRCas.net
- >>565
ui記述言語として書きやすい仕様だが(>_<｡)v
- 569 ：デフォルトの名無しさん：2021/08/22(日) 09:10:39.98 ID:0Cz6ueFz.net
- 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 は我々に教えてくれます
- 570 ：デフォルトの名無しさん：2021/09/18(土) 15:36:06.25 ID:ZtgFEKoc.net
- ReactというかJSをしばらくやってるんだがC#の非同期に慣れてるとしんどいね
- 571 ：デフォルトの名無しさん：2021/09/24(金) 18:41:54.72 ID:lFl/t56p.net
- >>570
ほとんど同じじゃね？
- 572 ：デフォルトの名無しさん：2021/09/25(土) 01:28:16.45 ID:h7oOvGYh.net
- だね
- 573 ：デフォルトの名無しさん：2021/09/25(土) 09:44:48.46 ID:utiZsGgV.net
- キャンセルできない
ライブラリのasync対応が半端
AsyncEnumerableがない
- 574 ：デフォルトの名無しさん：2021/11/03(水) 13:43:09.57 ID:EK9S3Of/.net
- VS2022で何か変わりますか？
- 575 ：デフォルトの名無しさん：2022/04/19(火) 18:34:10.96 ID:cFmOLae8.net
- なんだこの過疎り具合…
他のASP.NETスレも動いてないみたいだしC#でWebしてる人はよほど少ないのね
- 576 ：デフォルトの名無しさん：2022/04/19(火) 18:54:16.41 ID:ADHtQbAX.net
- APIぐらいじゃね？
- 577 ：デフォルトの名無しさん：2022/04/19(火) 21:04:28.79 ID:bkK/k49z.net
- 次期OfficeやVSCodeがBlazorHybridで作られたら考えるわ
- 578 ：デフォルトの名無しさん：2022/04/22(金) 10:45:57.05 ID:bV4j5CrE.net
- ASP.NETって書籍もWebフォームばっかだな
- 579 ：デフォルトの名無しさん：2022/04/26(火) 22:01:04.82 ID:n5z2s5RV.net
- もうすぐ.NET MAUIの正式リリースがくるってことで...
なんだかんだ.NETが理想的な形に近づいてきてるところ見るとわくわくするんだけれども。
世の中Google主導で、JavaScriptが人権みたいな流れになってるもんだからMicrosoftはこれからどうするんだろうと心配になる。
C#(Microsoft)対JavaScript(Google)な未来がみえるみえる
- 580 ：デフォルトの名無しさん：2022/04/27(水) 06:53:03.08 ID:l66LauWY.net
- >>579
JavascriptらMSがTypescriptで覇権を握っているように思うけど…
- 581 ：デフォルトの名無しさん：2022/04/27(水) 11:04:53.32 ID:d8y38HAK.net
- フロントエンドはTSで開発環境はVSCで
メインストリームだよ
- 582 ：デフォルトの名無しさん：2022/04/27(水) 12:42:11.57 ID:0yTdFTVm.net
- でもBlazorやMAUI、WinUIは流行る気がしない。
Reactのように企業が実際使っているフレームワークのほうが信頼度高いから。
- 583 ：デフォルトの名無しさん：2022/04/27(水) 12:44:51.74 ID:uliHTCYs.net
- 特に日本記号は新しいもの使わないからな
- 584 ：デフォルトの名無しさん：2022/05/01(日) 10:44:21.22 ID:e5c16v3a.net
- WinUIは特にWindows App SDKがまだまだ未完成状態だから流行る流行らない以前に普及できないよ
Microsoftはきちんと動くようになってから宣伝してほしい
- 585 ：デフォルトの名無しさん：2022/05/03(火) 03:04:06.38 ID:3JSewAq3.net
- あのさ、ちょっとわいReactの経験無いから聞きたいんやけど、
Asp.netMVCでRazer使ってSSRしながら作ったらVisualStudioだけで全て完結してまるっと統一感でるとおもうんだけど
なんでフロントはReact、サーバーサイドはAsp.netって分けて作ってるところがそこそこあるの？
Razerだけで自作コントロール的なものからなにから用意できるからAsp.netだけで作ったほうが絶対にいいとおもうんだけど
- 586 ：デフォルトの名無しさん：2022/05/03(火) 06:37:39.20 ID:FBRVO9ax.net
- うちは
React + Asp.net Web API
- 587 ：デフォルトの名無しさん：2022/05/03(火) 08:01:49.35 ID:r6X26HcZ.net
- SPA作らないんならReactいらないんでないの
- 588 ：デフォルトの名無しさん：2022/05/04(水) 11:07:52.23 ID:E45en6lm.net
- >>585
ASP.net MVCではSSRと言わないはず。
SSRはSPA関連で使うワード
統一感ないのはほとんどのweb appは
フロントエンドとバックエンドで担当が分かれてるからでしょ。
言語を統一する必要があまりない。
言語の統一よりも、フロント、バックそれぞれのフレームワークの良いものを
選んだほうがいいってことかと。
動的言語をバックエンドで使ったら生産性も低いし性能も落ちる。
バックエンドやAPIをC#でやるのは理にかなってる。
フロントエンドはブラウザがJS縛りなのだからTSでやるのが合理的
BlazorならフロントもC#にできるがパフォーマンスが落ちる。
あとフロントエンドのひとたちはOOP、C#の理解できない人が多い。
データベースの知識も浅い。
フロントエンドしかできない人にはasp.net MVCは学習コストが高い。
- 589 ：デフォルトの名無しさん：2022/05/04(水) 11:12:21.42 ID:E45en6lm.net
- >>585
587も書いてるけど
まずSPAがいいのか、MVCのような従来型がいいのか、を考える必要ある。
SPAにもデメリットある。
なんでもかんでもSPAではだめ
SPA使わないとなるとASP.NET MVCは今でも最強フレームワークだと思う
SPA使わないとしてもAPIでASP.NET MVC使うのはぜんぜんいいと思うし
SPAである必要ぜんぜんないのにSPAでやってるサイトが増えてる感じはする。
戻るボタンつかえないクソサイトね
- 590 ：デフォルトの名無しさん：2022/05/04(水) 16:05:04.80 ID:xvnabw/l.net
- >>588
なるほどなー
うちはフロントとバック別れてないからReact使うメリットがまったく分からなかったのか
たしかに分かれてたらフロント専門にやってるような人たちも混ざれるもんなー
でもさ、
ぶっちゃけさ、どっちも同じ人が担当したほうが結局のところ無駄な伝達とか無くてはやいよな
- 591 ：デフォルトの名無しさん：2022/05/04(水) 23:18:33 ID:AJMM67e4.net
- 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 が多くなってきた
- 592 ：デフォルトの名無しさん：2022/05/05(木) 00:54:03.75 ID:cAbH/I31.net
- >>591
日本語で頼む
ブラウザはJS縛りなのに脱JSとは？
フロントエンドのコードをRubyで書いてJSに変換できる技術ってこと？
- 593 ：591：2022/05/05(木) 01:43:56.90 ID:2L8NgwAH.net
- JSON API を定義して、JavaScript(JS)・Ajax でやり取りする必要がなくなる
サーバー側で、HTML 片を作って送って、
受け取ったブラウザ側で、その部分を置換する
Rails + React + Bootstrap みたいに、2つのアプリが必要なくなった。
JSを受け取って処理する、部分が無くなった
この方法で、ここ数年SPA で、Reactに奪われたシェアを回復する
- 594 ：591：2022/05/05(木) 01:58:11 ID:2L8NgwAH.net
- 猫でもわかるHotwire入門 Turbo編
https
://zenn.dev/shita1112/books/cat-hotwire-turbo
たぶん、Ruby on Rails 7 のHotwire, Elixir のPhoenix 1.6 のLiveView も、
似たような感じなんだろう
- 595 ：デフォルトの名無しさん：2022/05/05(木) 07:25:39.82 ID:zkLrQNmV.net
- Blazor serverの類似技術ってことかいな
- 596 ：デフォルトの名無しさん：2022/05/05(木) 12:12:39.76 ID:cAbH/I31.net
- >>594
Thanks. 594のリンク先でHotwireの概要読んだ。
実際Hotwireで、どのくらい開発時間が削減できるのかは気になるわ
気になるところは、htmlのブロックをやりとりすることのデメリットだな
JSONでデータ渡すからこそ、PC, SPの両方でサーバーサイドを共通化できるってのが
メリットだったんじゃないのかね
Hotwireで部分的な更新はできるようになったけどクロスプラットフォーム対応はしにくいと思う。
web frameworkごとに内部の動きもぜんぜんちがうとか、
相変わらずweb appはカオスだな
転職のとき大変そう
- 597 ：591：2022/05/05(木) 23:32:46.84 ID:2L8NgwAH.net
- KENTA
未経験からのエンジニア転職の必須教養【技術知識編】
https
://www.youtube.com/watch?v=Q1c09rrhTjo
転職・学習環境は、Ruby on Rails 1強
Railsチュートリアル・Rails Guide、
パーフェクト Ruby on Rails・黒田努の本などの、多くの教科書がある。
Dean などのYouTube 動画も多い
キャリアパスも、Rails → Go だけ
- 598 ：デフォルトの名無しさん：2022/05/06(金) 06:05:59.50 ID:g661Ln4z.net
- なんだKENTAの人か
解散
- 599 ：デフォルトの名無しさん：2022/05/06(金) 06:52:21.72 ID:LpVwH58w.net
- >>597
KENTAはレベル低いから動画みないほうがいいぞ
同じことばっかり言ってる。技術的に浅いからネタがない。
自分のコード、ほとんど晒してない。
- 600 ：デフォルトの名無しさん：2022/05/06(金) 07:02:04.16 ID:LpVwH58w.net
- >>597
あと教科書などいらない
ふつう、新しい技術学ぶのは英語。英語の情報をみたほうがはやい
Rubyは低速だから大手ITはRails捨てたところ多いし。
KENTAみたいに技術ないむかしの人がいまだにRubyとかRails推して
英語できない初心者がまたRails始めるという日本の悪循環
スクールもそんな感じ
情弱相手のビジネス
- 601 ：デフォルトの名無しさん：2022/06/10(金) 20:43:37.92 ID:hbzVWYIX.net
- DBなどへの接続文字列とかって実際の案件や現場でどーしてるんですか？
２，３方法があるみたいでも、なんか定番のこれって感じの記事も少ないし
そもそもサーバー上に配置したappsetting.jsonを見られてる時点で
鯖に侵入されててそれどこじゃないってことなんでしょうか？
- 602 ：デフォルトの名無しさん：2022/09/26(月) 22:47:25.10 ID:aC/L4xEl.net
- Blazorでこれやっとけみたいな教本とかありますか？
ねこジョーカーさんのやつとか？
- 603 ：デフォルトの名無しさん：2022/09/26(月) 22:49:15.04 ID:aC/L4xEl.net
- 作りたいものはWikiみたいなDBと連動してボディの文字を修正したりコメント欄を追加したりしたい
- 604 ：デフォルトの名無しさん：2022/10/06(木) 08:17:39.29 ID:+AsrxDle.net
- DevExpress のサンプルでも見とけば？
- 605 ：デフォルトの名無しさん：2022/11/13(日) 15:46:36.25 ID:kbkoXQBG.net
- WEB開発はMacの人が多いから、まずはASP.NET CoreがMacでも開発できるよってことを
みんなに広める必要がある
- 606 ：デフォルトの名無しさん：2023/02/12(日) 20:28:01.91 ID:IPWWwtwu.net
- >>578
え(笑)
- 607 ：デフォルトの名無しさん：2023/05/29(月) 05:56:19.80 ID:bhwRlPkq.net
- ASP.netで作ったポートフォリオを転職時に提出したいのですが
PHPではレンタルサーバーを借りてアップロードしますが
ASP.netの場合は自身でサーバーを立てる必要があるのでしょうか？
- 608 ：デフォルトの名無しさん：2023/05/29(月) 08:50:20.39 ID:/worGbVW.net
- コードビハインドで取得したバイナリデータをJavaScriptの関数に渡したいんだけど、常套手段はありますか？
- 609 ：デフォルトの名無しさん：2023/09/01(金) 20:41:11.94 ID:cHYygBTa7
- 法による支配だのと嘘ハ百ほざいてる利権キチガイの岸田異次元増税憲法ガン無視地球破壊軍国主義売國奴文雄のテロ組織自民党か゛、憲法違反
極まりない自閉隊利権をさらに倍増させて私利私欲のために世界最惡の殺人組織公明党強盗殺人の首魁齊藤鉄夫ら国土破壞省と賄賂癒着してる
クソ航空関係者に、力による一方的な現状変更させて都心まで数珠つなぎで鉄道の3０倍以上もの温室効果ガスをまき散らす大量破壞兵器の
クソ航空機飛ばさせて憲法13条25条29条と公然と違反して私権侵害に威力業務妨害にと繰り返して莫大な石油を無駄に燃やしてエネ価格
暴騰させて國民の生活どころか人権まで蹂躙して、氣候変動によって土砂崩れに洪水、暴風、猛暑、干ばつ，大雪にと住民を殺しまくって
WMOか゛1９70年以降確認しているだけで20０万人以上が気候変動によって殺害され経済損失は600兆円以上だが、もはや正当防衛かつ
緊急避難としてクソ航空関係者と国土破壊省のテ□リストを皆殺しにする権利を住民が有することは法的に認められた正当な権利なのは明らか
日本人は個人的な恨みによる行動ばかりだが．民主主義とは武力によってのみ維持できるという世界の常識を理解しないと奪われる一方だぞ!
（羽田)ttps://www.call4.jp/info.php?Τypе＝items&id＝I0０00062 , ｔΤΡs：//haneda-projеct.jimdofrｅe.Com/
(成田)tＴΡs://n-souonhigaisosyoudan.amebaownd.com／
（テロ組織)tTps://i.imgur.com/hnli1ga.jpｅg
総レス数 609
197 KB
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★