スレ立てるまでもない質問はここで 154匹目
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2020/09/07(月) 18:56:51.64ID:4fn7uU/g スレ立てるまでもない質問はここで 154匹目
25デフォルトの名無しさん
2020/09/10(木) 10:58:45.12ID:ow/IAMyj >>22
環境変数にも問題はありませんでした。
環境変数にも問題はありませんでした。
26デフォルトの名無しさん
2020/09/10(木) 11:00:54.22ID:ow/IAMyj >>23
他のコードも見てみたんですが、どれも基本的に同じコードでした。
他のコードも見てみたんですが、どれも基本的に同じコードでした。
27デフォルトの名無しさん
2020/09/10(木) 11:08:01.37ID:ow/IAMyj 綴りを間違えていたようで、cledentialsではなくcredentialsでした。
直したらきちんとファイルもアップロードできました。
ありがとうございました。
直したらきちんとファイルもアップロードできました。
ありがとうございました。
28デフォルトの名無しさん
2020/09/10(木) 14:30:43.83ID:5ZaHG68g 一文字ずつ打ってたのか…
29デフォルトの名無しさん
2020/09/10(木) 14:55:38.10ID:wbCB6iSX 英検一級以上の単語なんて普通に生きてりゃまずお目にかかることなんてないしな
「Aliens: Colonial Marines」のおバカなAIはたった1文字のタイプミスが原因か、MOD開発者が報告 « doope! 国内外のゲーム情報サイト
https://doope.jp/2018/0778723.html
>“AttachPawnToTeather”が、正しくは“AttachPawnToTether”だった
テザリングのテザーだがやはりこれも一級以上
「Aliens: Colonial Marines」のおバカなAIはたった1文字のタイプミスが原因か、MOD開発者が報告 « doope! 国内外のゲーム情報サイト
https://doope.jp/2018/0778723.html
>“AttachPawnToTeather”が、正しくは“AttachPawnToTether”だった
テザリングのテザーだがやはりこれも一級以上
30デフォルトの名無しさん
2020/09/10(木) 17:35:09.94ID:ow/IAMyj え、打たないの
2020/09/10(木) 17:40:19.02ID:aa4WTOXX
32デフォルトの名無しさん
2020/09/10(木) 18:58:41.82ID:qqrZM7ve その都度正しいのをコピペするってこと?
33デフォルトの名無しさん
2020/09/11(金) 11:17:58.95ID:xxcUm1ef S3に保存した画像ファイルを表示するときimgのsrcにS3のファイルのリンクを指定しますが、
リンクからバケット名やファイル名などがわかってしまいますが、これは特に問題ありませんか?
リンクからバケット名やファイル名などがわかってしまいますが、これは特に問題ありませんか?
2020/09/11(金) 11:33:22.80ID:2ygR8GWv
何をどうするかで変わるに決まってんだろ
まったく問題ない から 大問題 の間のどれかだ
まったく問題ない から 大問題 の間のどれかだ
35デフォルトの名無しさん
2020/09/11(金) 13:02:45.19ID:xxcUm1ef まとめブログのようなサイトで、あるニュースを表した画像をサムネイルとして表示するつもりだけど
この画像自体は特にセキュリティ性のある画像ではない。この場合はリンクにファイル名とかが出てても問題ない?
この画像自体は特にセキュリティ性のある画像ではない。この場合はリンクにファイル名とかが出てても問題ない?
2020/09/11(金) 13:41:07.49ID:2ygR8GWv
答えは同じ
何をどうするかで変わるに決まってんだろ
まったく問題ない から 大問題 の間のどれかだ
何をどうするかで変わるに決まってんだろ
まったく問題ない から 大問題 の間のどれかだ
37デフォルトの名無しさん
2020/09/11(金) 14:45:38.91ID:xxcUm1ef 何をどうするかって例えば?
2020/09/11(金) 15:11:11.69ID:ClWA61Ey
パスをどうするか、他のファイル名をどうするか、他のファイルに何を置くか
なんでもかんでもぜーんぶ
そのレベルのやつがセキュリティ考える必要があるようなことをやるんじゃねーよ
基本が何もできてない
なんでもかんでもぜーんぶ
そのレベルのやつがセキュリティ考える必要があるようなことをやるんじゃねーよ
基本が何もできてない
39デフォルトの名無しさん
2020/09/11(金) 15:23:11.34ID:xxcUm1ef は、はぁ
2020/09/11(金) 15:26:01.70ID:PKeuSwqJ
41デフォルトの名無しさん
2020/09/11(金) 15:36:06.90ID:xxcUm1ef なるほどね〜了解
2020/09/11(金) 15:38:27.80ID:rpshaWn6
>>36
お前が誰から何を守りたいのかわかってないのに安全かどうかなんかわかるわけ無いだろ
お前が誰から何を守りたいのかわかってないのに安全かどうかなんかわかるわけ無いだろ
43デフォルトの名無しさん
2020/09/11(金) 22:45:07.21ID:6OP5rCh4 なるほど、いろいろ勉強し直しすわ
44デフォルトの名無しさん
2020/09/12(土) 02:17:02.70ID:SzTm78BI GUIアプリって結局Webベースで開発するのが合理的だよな
2020/09/12(土) 05:54:57.33ID:Q/cMHo3Y
Webベースで開発するのは金を取るためでオープンの敗北だよ
ローカルでオープンだと金を取れないからビジネスにならない
だからWebベースにする。WebベースだとOSSを使ってもソースをオープンにする必要なくなるから
ローカルでオープンだと金を取れないからビジネスにならない
だからWebベースにする。WebベースだとOSSを使ってもソースをオープンにする必要なくなるから
46デフォルトの名無しさん
2020/09/13(日) 05:51:38.89ID:lu6eiMc4 そういうマネタイズの部分はわからんけど
言いたかったのは
・HTMLはGUI構築する仕組みがよく出来てるし
・ブラウザなんてどのPCにも入ってるからクロス開発にもなる
・扱えるデータ・デバイスも不足ない
ってこと
(ただ現状メジャーな方法がElectronとかでこれが微妙)
言いたかったのは
・HTMLはGUI構築する仕組みがよく出来てるし
・ブラウザなんてどのPCにも入ってるからクロス開発にもなる
・扱えるデータ・デバイスも不足ない
ってこと
(ただ現状メジャーな方法がElectronとかでこれが微妙)
47デフォルトの名無しさん
2020/09/13(日) 09:00:28.13ID:e9EK7dt7 CSSとかJSとかバックエンドの言語とか全部やる気あるの?
2020/09/13(日) 09:58:18.35ID:Ln963FmW
全部できないゴミエンジニアが多すぎなんだよ
htmlとcssを使えばクオリティ高いUI/UXを作れるのにそもそもセンスなさすぎて
昔のボタン配置したUIみたいなのしか作れず画面は崩れる
そのくせhtmlとcssをバカにする
htmlとcssを使えばクオリティ高いUI/UXを作れるのにそもそもセンスなさすぎて
昔のボタン配置したUIみたいなのしか作れず画面は崩れる
そのくせhtmlとcssをバカにする
2020/09/13(日) 10:40:58.32ID:+npDkJjj
cssはゴミでしょ
webの世界でもコンポーネント指向が主流になってきてる
コンポーネント指向だとスタイルもコンポーネントに閉じ込めるからcssなんていらん
cssを無くしてelementの視覚属性を拡充すべきだった
webの世界でもコンポーネント指向が主流になってきてる
コンポーネント指向だとスタイルもコンポーネントに閉じ込めるからcssなんていらん
cssを無くしてelementの視覚属性を拡充すべきだった
2020/09/13(日) 10:53:00.71ID:F8eJvx/w
CSSとコンポーネントは併用して使うものなんだが
HTMLの本質である文書と視覚の分離を理解してるか?
HTMLの本質である文書と視覚の分離を理解してるか?
2020/09/13(日) 12:07:22.32ID:Xp7zp8nz
コンポーネントごとに見た目がバラバラだったりすると再利用もしたくないなぁ。
2020/09/13(日) 13:02:28.70ID:JiEeR27v
2020/09/13(日) 13:09:14.64ID:C1zUubdH
> セマンティクスな文章構造を装飾するにはcssがフィットするが
手のひらクルックルw
手のひらクルックルw
2020/09/13(日) 13:11:08.06ID:C1zUubdH
> 見た目を調整したいならコンポーネントのスタイルをオーバーライドするだけだ
じゃあユーザースタイルシートで変更する方法を書いてみて
じゃあユーザースタイルシートで変更する方法を書いてみて
2020/09/13(日) 13:25:18.52ID:I60CiHSB
2020/09/13(日) 13:37:54.61ID:d/ryA4WH
2020/09/13(日) 13:59:21.00ID:Xp7zp8nz
>なぜならcssは継承やコンポジションをサポートしないから
cssのそこを直接改善すれば済む話だと思うが、それ以前に
>cssだと逆にUIフレームワークが定めた見た目を部分的に変更することが難しい
アプリケーション開発者の立場でそれが難しいとは思わんのだが。
もしコンポーネント開発茶の立場で言っているのだとしたら何をやりたいのかよくわからん。
cssのそこを直接改善すれば済む話だと思うが、それ以前に
>cssだと逆にUIフレームワークが定めた見た目を部分的に変更することが難しい
アプリケーション開発者の立場でそれが難しいとは思わんのだが。
もしコンポーネント開発茶の立場で言っているのだとしたら何をやりたいのかよくわからん。
2020/09/13(日) 14:08:40.06ID:lqAY86+l
板違いなんだがここは雑談スレなのか?雑談スレならスレごと板違いなんだが
htmlの見た目を部分で変えたいとかHTML5やJavaScriptでできるんだからその手の板でやれ
htmlの見た目を部分で変えたいとかHTML5やJavaScriptでできるんだからその手の板でやれ
2020/09/13(日) 14:22:35.07ID:jqobtGhf
>>57
難しいというか面倒くさい
せっかくコンポーネントに隠したhtml構造とcss class名を調べて、それに合わせてカスタムcssを作らなきゃいけないじゃん
まるで、メタプログラミングでプライベート変数にアクセスするような気持ちの悪さを感じる
コンポーネントの構造を変えたくなった時にもカスタムcssが壊れないか注意を払わなきゃいけない
コンポーネントが直接スタイル属性をサポートしてれば、たとえば幅を変えたいならコンポーネントのwidth属性を変えるだけ
使う方は内部のhtml構造もcss classも何も知らなくていい
こっちのほうがわかりやすいしメンテナンス性も高い
難しいというか面倒くさい
せっかくコンポーネントに隠したhtml構造とcss class名を調べて、それに合わせてカスタムcssを作らなきゃいけないじゃん
まるで、メタプログラミングでプライベート変数にアクセスするような気持ちの悪さを感じる
コンポーネントの構造を変えたくなった時にもカスタムcssが壊れないか注意を払わなきゃいけない
コンポーネントが直接スタイル属性をサポートしてれば、たとえば幅を変えたいならコンポーネントのwidth属性を変えるだけ
使う方は内部のhtml構造もcss classも何も知らなくていい
こっちのほうがわかりやすいしメンテナンス性も高い
2020/09/13(日) 15:08:38.71ID:C1zUubdH
ウェブの大半はアプリケーションではない
CSSはウェブの大半で有効に使える
それが証明されましたねw
CSSはウェブの大半で有効に使える
それが証明されましたねw
2020/09/13(日) 17:22:03.28ID:Ln963FmW
2020/09/13(日) 17:31:14.83ID:24n75C+P
>>61
sass頼りとかネイティブじゃ欠陥品と認めたようなもの
部分変更のためにまたclass追加すんのか
そうやって管理対象をばかすか増やすなよ
メンテナンス性も考えろ
ただの例示に噛み付いて本質を見失うアホの典型例
コンポーネントの描画パラメータをインターフェースとして定義してクライアントに提供できることがコンポーネントの利点だと言っている
widthに限った話ではない
sass頼りとかネイティブじゃ欠陥品と認めたようなもの
部分変更のためにまたclass追加すんのか
そうやって管理対象をばかすか増やすなよ
メンテナンス性も考えろ
ただの例示に噛み付いて本質を見失うアホの典型例
コンポーネントの描画パラメータをインターフェースとして定義してクライアントに提供できることがコンポーネントの利点だと言っている
widthに限った話ではない
2020/09/13(日) 17:36:01.82ID:8aNWh6BR
> sass頼りとかネイティブじゃ欠陥品と認めたようなもの
せやな。JavaScriptフレームワークに頼るのはやめような
せやな。JavaScriptフレームワークに頼るのはやめような
2020/09/13(日) 17:43:40.14ID:Ln963FmW
2020/09/13(日) 17:45:31.52ID:24n75C+P
2020/09/13(日) 17:51:39.99ID:8aNWh6BR
>>62
ちゃんとレスポンシブデザインに対応したコンポーネント作ってるか?
ちゃんとレスポンシブデザインに対応したコンポーネント作ってるか?
2020/09/13(日) 17:54:23.85ID:24n75C+P
2020/09/13(日) 17:59:40.45ID:Ln963FmW
>>65
いやお前実際にUI作れないじゃん
全部コンポーネントの中にパラメータとかアホか?
コンポーネント間で共有するのにパラメータ化すんの?
クライアントはいい迷惑だな
しかもゴミのようなセンスだし
いやお前実際にUI作れないじゃん
全部コンポーネントの中にパラメータとかアホか?
コンポーネント間で共有するのにパラメータ化すんの?
クライアントはいい迷惑だな
しかもゴミのようなセンスだし
2020/09/13(日) 18:07:56.68ID:24n75C+P
>>68
本当にアホなんだなあ
パラメータにデフォルト値があるってことすら思い至らないんだ
まさかクライアント側で全てのパラメータを一個一個指定するとでも思ったのかね
それに違和感を感じないとかセンスを疑うワ
酷いインターフェース作りそうだなこいつ
一緒に働いてる同僚が可愛そう
本当にアホなんだなあ
パラメータにデフォルト値があるってことすら思い至らないんだ
まさかクライアント側で全てのパラメータを一個一個指定するとでも思ったのかね
それに違和感を感じないとかセンスを疑うワ
酷いインターフェース作りそうだなこいつ
一緒に働いてる同僚が可愛そう
2020/09/13(日) 18:18:44.33ID:Ln963FmW
>>69
そもそもお前みたいな時代遅れ野郎に付き合ってやってる俺に感謝しろよ
デフォルト値とかの話じゃねえんだよ
css側にUIの状態を持たせるのはフロントの処理と分けるためだ
フロントの状態が変わればcssが勝手にUIが変更されるんだよ
widthのパラメータを変えなくても勝手に変わるわけ
これは他のcssプロパティでも同じ
その設計ができないからお前は的外れなゴミクズ発想しかできないんだよ
コンポーネント内にパラメータやデフォルト値を持たせたらカオスになるだろ
わかったか
そもそもお前みたいな時代遅れ野郎に付き合ってやってる俺に感謝しろよ
デフォルト値とかの話じゃねえんだよ
css側にUIの状態を持たせるのはフロントの処理と分けるためだ
フロントの状態が変わればcssが勝手にUIが変更されるんだよ
widthのパラメータを変えなくても勝手に変わるわけ
これは他のcssプロパティでも同じ
その設計ができないからお前は的外れなゴミクズ発想しかできないんだよ
コンポーネント内にパラメータやデフォルト値を持たせたらカオスになるだろ
わかったか
2020/09/13(日) 18:26:17.77ID:24n75C+P
やっぱフロント屋ってセンスねんだな
コンポーネントの基本中の基本すらわかってない
クライアントにはそのコンポーネントの仕様を表現したインターフェースを提供せよ
クライアントがコンポーネントを利用するのにその実装に依存した記述をしなければならないならそのコンポーネントは欠陥品である
CSSってのはまさにその欠陥品そのものなんだわな
CSSをカスタムするにはhtmlの構造を詳しく調べないといけない
htmlの構造を変えるにはCSSを詳しく調べないといけない
それを怠るとデザインが簡単に崩れる
アホくさ
クライアントがコンポーネントの中身のhtml構造とcssまで把握しなきゃならないならメンテナンス性を著しく損ねてるってことだ
クライアントはコンポーネントの提供するインターフェースに従って属性を変更すればそれでいい
クライアントはコンポーネントの詳細を知る必要はない
コンポーネントはクライアントにハックされて調和を乱される心配をしなくていい
それが正常な世界のあり方だ
コンポーネントの基本中の基本すらわかってない
クライアントにはそのコンポーネントの仕様を表現したインターフェースを提供せよ
クライアントがコンポーネントを利用するのにその実装に依存した記述をしなければならないならそのコンポーネントは欠陥品である
CSSってのはまさにその欠陥品そのものなんだわな
CSSをカスタムするにはhtmlの構造を詳しく調べないといけない
htmlの構造を変えるにはCSSを詳しく調べないといけない
それを怠るとデザインが簡単に崩れる
アホくさ
クライアントがコンポーネントの中身のhtml構造とcssまで把握しなきゃならないならメンテナンス性を著しく損ねてるってことだ
クライアントはコンポーネントの提供するインターフェースに従って属性を変更すればそれでいい
クライアントはコンポーネントの詳細を知る必要はない
コンポーネントはクライアントにハックされて調和を乱される心配をしなくていい
それが正常な世界のあり方だ
2020/09/13(日) 18:27:26.44ID:8aNWh6BR
>>67
レスポンシブに対応するかは、コンポーネント側で決めることではない
レスポンシブに対応するかは、コンポーネント側で決めることではない
2020/09/13(日) 18:31:35.99ID:8aNWh6BR
>>71
根本的に考えがずれてる
CSSというのは文書構造に対して後から適用するものだ
HTMLというのは構造化された情報の集まりだ
そこにCSSを適用することで、自由にデザインを変更することができる
お前は適当に作ってるから情報の集まりであるHTMLが構造化されていない
HTMLというデータの仕様がまったくない
いきあたりばったりで生成するHTMLを作ってる
まず生成するHTMLの仕様を定義しろ
> CSSをカスタムするにはhtmlの構造を詳しく調べないといけない
HTMLの仕様が最初に定義されてるんだから、これは依存関係が逆になる
htmlの構造が詳しく定義されてる のだからCSSをカスタムするのは容易だ
根本的に考えがずれてる
CSSというのは文書構造に対して後から適用するものだ
HTMLというのは構造化された情報の集まりだ
そこにCSSを適用することで、自由にデザインを変更することができる
お前は適当に作ってるから情報の集まりであるHTMLが構造化されていない
HTMLというデータの仕様がまったくない
いきあたりばったりで生成するHTMLを作ってる
まず生成するHTMLの仕様を定義しろ
> CSSをカスタムするにはhtmlの構造を詳しく調べないといけない
HTMLの仕様が最初に定義されてるんだから、これは依存関係が逆になる
htmlの構造が詳しく定義されてる のだからCSSをカスタムするのは容易だ
2020/09/13(日) 18:31:41.98ID:Ln963FmW
フロント屋ってなんだ?フロントできないゴミエンジニアのお前はバックエンド屋なのか
当たり前だがバックエンドもインフラもやれてフロントもやれるのが当然なわけ
つまりこのゴミクソ野郎は無能だから吠えて何も解決策は出していない
そもそもUI作れないからクライアントに納品できないからな
当たり前だがバックエンドもインフラもやれてフロントもやれるのが当然なわけ
つまりこのゴミクソ野郎は無能だから吠えて何も解決策は出していない
そもそもUI作れないからクライアントに納品できないからな
2020/09/13(日) 18:33:54.66ID:24n75C+P
まあCSSが全てにおいて悪センスなわけじゃない
たとえば、Markdownの生成するHTMLのようにある程度決まりきった単純な構造を持ったドキュメントに対して、クライアントの好きなデザインを適用したい、などといった場合には少ない労力で対応できる
が、これをより複雑で実装の変化も速い構造になりがちな、アプリケーションで同じ手法でやろうとするのは馬鹿げてる
たとえば、Markdownの生成するHTMLのようにある程度決まりきった単純な構造を持ったドキュメントに対して、クライアントの好きなデザインを適用したい、などといった場合には少ない労力で対応できる
が、これをより複雑で実装の変化も速い構造になりがちな、アプリケーションで同じ手法でやろうとするのは馬鹿げてる
2020/09/13(日) 18:36:18.02ID:8aNWh6BR
コンポーネントが生成するHTMLが定義されない状態で
どうやってテストできるというのか
HTMLの構造は詳しく調べるものではない
仕様書として定義するものだ
どうやってテストできるというのか
HTMLの構造は詳しく調べるものではない
仕様書として定義するものだ
2020/09/13(日) 18:38:51.05ID:Xp7zp8nz
78デフォルトの名無しさん
2020/09/13(日) 18:43:14.83ID:lu6eiMc4 ちぐはぐにならないようにグローバルなスタイルは外部から注入する形
にすればいいんでないか?
にすればいいんでないか?
2020/09/13(日) 18:44:26.17ID:24n75C+P
>>76
はぁ┐(´д`)┌ヤレヤレ
出力されるhtmlは仕様じゃない
実装だよ
コンポーネントの仕様ってのはいいか?
そのコンポーネントのカスタムタグ名はなんですか
そのタグをおいたらどういった物が描画されるんですか
クライアントがコントロール可能なパラメータはなんですか
それらをコントロールするにはどの属性を変えればいいんですか
どの属性にどんな値を設定したらどうなりますか
そういうことを厳密に定めた文書のことを「仕様」と言うんだ
仕様にはHTMLなんてものはどこにも出てこない
なぜならHTMLは仕様ではなく実装の詳細だからだ
ま、肌感覚でテキトーな仕事ばっかしてるウェブ系キッズじゃ、正しい仕様とか言われても理解が難しいだろうけどな
はぁ┐(´д`)┌ヤレヤレ
出力されるhtmlは仕様じゃない
実装だよ
コンポーネントの仕様ってのはいいか?
そのコンポーネントのカスタムタグ名はなんですか
そのタグをおいたらどういった物が描画されるんですか
クライアントがコントロール可能なパラメータはなんですか
それらをコントロールするにはどの属性を変えればいいんですか
どの属性にどんな値を設定したらどうなりますか
そういうことを厳密に定めた文書のことを「仕様」と言うんだ
仕様にはHTMLなんてものはどこにも出てこない
なぜならHTMLは仕様ではなく実装の詳細だからだ
ま、肌感覚でテキトーな仕事ばっかしてるウェブ系キッズじゃ、正しい仕様とか言われても理解が難しいだろうけどな
2020/09/13(日) 18:50:44.01ID:8aNWh6BR
>>79
HTMLを実装とか意味不明w
コンポーネントの仕様ってのはいいか?
このコンポーネントを配置したら
どういうHTMLが生成されるかって話なんだよ
そのHTMLがどういうレンダリングがされるかっていうのは
OSやブラウザによってバラバラだろ
HTMLがどう描画されるかHTMLの仕様ではない
HTMLを実装とか意味不明w
コンポーネントの仕様ってのはいいか?
このコンポーネントを配置したら
どういうHTMLが生成されるかって話なんだよ
そのHTMLがどういうレンダリングがされるかっていうのは
OSやブラウザによってバラバラだろ
HTMLがどう描画されるかHTMLの仕様ではない
2020/09/13(日) 18:52:30.01ID:Ln963FmW
ゴミクズバックエンド脳が時代に取り残されてることにすら気づかず全世界の誰もが望まない欠陥方法をお披露目しているわけだがいつまで続くんだろうな
2020/09/13(日) 18:57:23.09ID:24n75C+P
>>77
君は話を理解してるようだな
そのとおりだ
で、あるからして
どこからでも使われるような汎用的なコンポーネントは、より充実したカスタムポイントを提供するべきだろう
しかし、特定の組織、グループ、プロジェクト、システム内で共有できればよい
そのドメインに特化したコンポーネントは、要件を満たすのに必要十分なカスタムポイントを提供すればよい
要件の変化が生じて、新しいカスタムポイントが必要になったのなら、必要になった時点で追加すればいい
クライアントはコンポーネントのインターフェースに従って利用しているはずなので
後方互換性を維持したまま内部構造を柔軟に変えたり、インターフェースを拡張することは容易だ
ようするにYAGNIの法則だな
君は話を理解してるようだな
そのとおりだ
で、あるからして
どこからでも使われるような汎用的なコンポーネントは、より充実したカスタムポイントを提供するべきだろう
しかし、特定の組織、グループ、プロジェクト、システム内で共有できればよい
そのドメインに特化したコンポーネントは、要件を満たすのに必要十分なカスタムポイントを提供すればよい
要件の変化が生じて、新しいカスタムポイントが必要になったのなら、必要になった時点で追加すればいい
クライアントはコンポーネントのインターフェースに従って利用しているはずなので
後方互換性を維持したまま内部構造を柔軟に変えたり、インターフェースを拡張することは容易だ
ようするにYAGNIの法則だな
2020/09/13(日) 19:01:40.33ID:24n75C+P
84デフォルトの名無しさん
2020/09/13(日) 19:13:59.60ID:lu6eiMc4 >複雑で実装の変化も速い構造になりがちな、アプリケーション
単純な構造をもったものの組み合わせなんじゃないの?
結局の所は
単純な構造をもったものの組み合わせなんじゃないの?
結局の所は
2020/09/13(日) 19:18:57.12ID:8aNWh6BR
2020/09/13(日) 19:21:27.96ID:8aNWh6BR
生成するHTMLを仕様として定義しない場合は、実際に問題が発生する
それは既に書いてあるとおり書いてあるとおり
htmlの構造を変えるにはCSSを詳しく調べないといけなくなる
それは既に書いてあるとおり書いてあるとおり
htmlの構造を変えるにはCSSを詳しく調べないといけなくなる
2020/09/13(日) 19:26:54.59ID:24n75C+P
>>84
業務システムでは単純に見える項目でも内部が複雑化することはある
業務システムでは単純に見える項目でも内部が複雑化することはある
2020/09/13(日) 19:28:19.81ID:8aNWh6BR
コンポーネントが生成するHTMLを仕様として定義すると
デザインを別の人が担当できるというメリットが有る
また生成するHTMLは仕様として決まってるわけだから
コンポーネントが完成する前から
デザイン担当者はデザインを作ることができる
デザインを別の人が担当できるというメリットが有る
また生成するHTMLは仕様として決まってるわけだから
コンポーネントが完成する前から
デザイン担当者はデザインを作ることができる
2020/09/13(日) 19:31:29.63ID:24n75C+P
2020/09/13(日) 19:32:24.15ID:Xp7zp8nz
>>82
だからスタイルはそれに当てはまらないだろう。
動作が同じだからといって内部で新しいエレメントが追加されたらそこだけ見た目が変わってしまう。
それを変更できるようにしてもらうなら、それを使う側からしてみれば扱うカスタマイズポイントが
1つ増えるわけで、何のことはない結局内部構造を把握するのと手間は変わらないわけだ。
コンポーネント開発者側の手間が増えるだけで何もいいことはない。
だからスタイルはそれに当てはまらないだろう。
動作が同じだからといって内部で新しいエレメントが追加されたらそこだけ見た目が変わってしまう。
それを変更できるようにしてもらうなら、それを使う側からしてみれば扱うカスタマイズポイントが
1つ増えるわけで、何のことはない結局内部構造を把握するのと手間は変わらないわけだ。
コンポーネント開発者側の手間が増えるだけで何もいいことはない。
2020/09/13(日) 19:33:22.59ID:8aNWh6BR
92デフォルトの名無しさん
2020/09/13(日) 19:33:37.71ID:qg7N5frC ヤンクミの法則。
2020/09/13(日) 19:35:00.54ID:8aNWh6BR
HTMLは仕様であり、先に定義することで
デザイナーとの分担作業が可能になる
どうせ大規模プロジェクトを経験してなくて
自分でデザインまで作ってるんだろうな
デザイナーとの分担作業が可能になる
どうせ大規模プロジェクトを経験してなくて
自分でデザインまで作ってるんだろうな
2020/09/13(日) 19:38:23.37ID:8aNWh6BR
>>90
> 動作が同じだからといって内部で新しいエレメントが追加されたらそこだけ見た目が変わってしまう。
これ、フロントエンドを理解してないやつがよくやる間違い
内部で新しいエレメントを追加・削除しないと変えられないと思ってる
実際は状態(class属性等)に応じて表示状態(displayスタイルなど)を変更すればいいだけなのだ
class属性等に応じて表示状態を変えるだけだから
JavaScriptはシンプルになるし、速度も軽くなる
コンポーネントが完成していなくても静的なHTMLとして記述しclass属性等を
変更するだけで状態に応じたデザインを作ることができる(分担作業)
> 動作が同じだからといって内部で新しいエレメントが追加されたらそこだけ見た目が変わってしまう。
これ、フロントエンドを理解してないやつがよくやる間違い
内部で新しいエレメントを追加・削除しないと変えられないと思ってる
実際は状態(class属性等)に応じて表示状態(displayスタイルなど)を変更すればいいだけなのだ
class属性等に応じて表示状態を変えるだけだから
JavaScriptはシンプルになるし、速度も軽くなる
コンポーネントが完成していなくても静的なHTMLとして記述しclass属性等を
変更するだけで状態に応じたデザインを作ることができる(分担作業)
2020/09/13(日) 19:39:29.29ID:8aNWh6BR
状態(≒見た目)が変わっても内部構造は変わらない
これがシンプルな設計において重要な点
これがシンプルな設計において重要な点
96デフォルトの名無しさん
2020/09/13(日) 19:42:49.59ID:qg7N5frC 単一の情報に対して複数の表示法を与えようとするのは、ウェブ作成者の多くがまともな大学を出ていないことと関係あるのでは?
2020/09/13(日) 19:46:07.97ID:8aNWh6BR
例えばタブインターフェースなんか、タブ1枚目、タブ2枚目、タブ3枚目があったとき
1枚目を表示するときは、1枚目だけを表示して、2枚目、3枚目は非表示にするだけでいいのだ
そのために必要なのはタブの表示ページ番号を示す属性を変更するだけ
あとは簡単なCSSですべてできる
JavaScriptはほんの3行程度、ラジオボタンを使えばJavaScriptゼロにだってできる
これをわざわざクリックされたときに1枚目を作成して
2枚目、3枚目は削除するなんてJavaScriptの処理を書いて
HTMLとCSSをJavaScriptに埋め込んで
わざわざして遅く面倒にしてるのが(アホな)コンポーネント厨
1枚目を表示するときは、1枚目だけを表示して、2枚目、3枚目は非表示にするだけでいいのだ
そのために必要なのはタブの表示ページ番号を示す属性を変更するだけ
あとは簡単なCSSですべてできる
JavaScriptはほんの3行程度、ラジオボタンを使えばJavaScriptゼロにだってできる
これをわざわざクリックされたときに1枚目を作成して
2枚目、3枚目は削除するなんてJavaScriptの処理を書いて
HTMLとCSSをJavaScriptに埋め込んで
わざわざして遅く面倒にしてるのが(アホな)コンポーネント厨
2020/09/13(日) 19:46:13.31ID:24n75C+P
HTMLを仕様として定めると、そのHTMLを前提としたCSSが無秩序に量産されるというリスクがある
そうなると、既存のCSSを変えずに、コンポーネントの構造を変えることが難しくなる
内部実装であるHTMLに、クライアントであるCSSが依存しているからだ
今日はインプットテキストだったコンポーネントが、要件変更で明日にはリストボックスになっているかもしれない
そういった変化があった場合に、コンポーネントのソースコード以外を変更する必要があるなら、そのコンポーネントはインターフェースと実装の分離ができていない証拠だ
HTMLを仕様と定めて、クライアントにCSSの実装を許すと、このような変化には耐えられなくなる
実装であるHTMLを外部に漏らしてはいけないのだ
そうなると、既存のCSSを変えずに、コンポーネントの構造を変えることが難しくなる
内部実装であるHTMLに、クライアントであるCSSが依存しているからだ
今日はインプットテキストだったコンポーネントが、要件変更で明日にはリストボックスになっているかもしれない
そういった変化があった場合に、コンポーネントのソースコード以外を変更する必要があるなら、そのコンポーネントはインターフェースと実装の分離ができていない証拠だ
HTMLを仕様と定めて、クライアントにCSSの実装を許すと、このような変化には耐えられなくなる
実装であるHTMLを外部に漏らしてはいけないのだ
2020/09/13(日) 19:47:46.26ID:8aNWh6BR
>>96
お前の願望を言うのはお前が低学歴なのでは?w
お前の願望を言うのはお前が低学歴なのでは?w
100デフォルトの名無しさん
2020/09/13(日) 19:48:19.46ID:8aNWh6BR101デフォルトの名無しさん
2020/09/13(日) 19:48:57.79ID:8aNWh6BR102デフォルトの名無しさん
2020/09/13(日) 19:49:06.63ID:Xp7zp8nz103デフォルトの名無しさん
2020/09/13(日) 19:49:59.28ID:8aNWh6BR104デフォルトの名無しさん
2020/09/13(日) 19:51:40.17ID:8aNWh6BR105デフォルトの名無しさん
2020/09/13(日) 19:52:24.50ID:24n75C+P106デフォルトの名無しさん
2020/09/13(日) 19:53:45.51ID:8aNWh6BR >>105
> 転送量やセキュリティの観点から非表示にするだけでなく要素そのものを取り除くことは珍しくもない
だからそういう理由があるときだけ複雑にしろよ
なぜやらなくていいときまで複雑にするのか→考える脳が無いから。全部同じやり方しますアポポッポポポw
> 転送量やセキュリティの観点から非表示にするだけでなく要素そのものを取り除くことは珍しくもない
だからそういう理由があるときだけ複雑にしろよ
なぜやらなくていいときまで複雑にするのか→考える脳が無いから。全部同じやり方しますアポポッポポポw
107デフォルトの名無しさん
2020/09/13(日) 19:54:11.08ID:qg7N5frC 複数のビューとか、Excelで要らんってわかったんじゃないのか。
もう20年以上前にわかってるもんを、いまさらやってどうなるというのか。
やっぱウェブ系は頭悪いな。
もう20年以上前にわかってるもんを、いまさらやってどうなるというのか。
やっぱウェブ系は頭悪いな。
108デフォルトの名無しさん
2020/09/13(日) 19:54:39.72ID:24n75C+P109デフォルトの名無しさん
2020/09/13(日) 19:57:27.38ID:24n75C+P110デフォルトの名無しさん
2020/09/13(日) 19:57:29.54ID:8aNWh6BR >>107
複数のビューが何を言ってるのか知らんけど、
コンポーネントの状態によって見た目が変わるのは普通の話
それをJavaScriptを使って状態によって構造を変化させて
CSSを適用しづらくして、うわーっとなって
全部JavaScriptにしてやるーって叫んでテストの工数を増やすか
状態が変わっても構造を変化させずに、同じ構造だから
CSSが適用しやすく、状態によっての見た目の違いはCSSでやれるから
JavaScriptコードが少なくなって、処理速度も速く
宣言的な記述でバグもテストも少なくなるかの違い
複数のビューが何を言ってるのか知らんけど、
コンポーネントの状態によって見た目が変わるのは普通の話
それをJavaScriptを使って状態によって構造を変化させて
CSSを適用しづらくして、うわーっとなって
全部JavaScriptにしてやるーって叫んでテストの工数を増やすか
状態が変わっても構造を変化させずに、同じ構造だから
CSSが適用しやすく、状態によっての見た目の違いはCSSでやれるから
JavaScriptコードが少なくなって、処理速度も速く
宣言的な記述でバグもテストも少なくなるかの違い
111デフォルトの名無しさん
2020/09/13(日) 19:58:05.27ID:qg7N5frC HTMLは文書ではない!データのコンテナなのだ!などと、グーグルの受け売りが正義とか思わないでほしいのだが。
ウェブ系の馬鹿は考える頭が付いていない。
ウェブ系の馬鹿は考える頭が付いていない。
112デフォルトの名無しさん
2020/09/13(日) 19:58:06.54ID:8aNWh6BR113デフォルトの名無しさん
2020/09/13(日) 20:02:13.75ID:24n75C+P >>106
理由が出来た時に容易に対応できるようにコンポーネントにするんだよ
理由が出来た時に容易に対応できるようにコンポーネントにするんだよ
114デフォルトの名無しさん
2020/09/13(日) 20:03:05.61ID:8aNWh6BR115デフォルトの名無しさん
2020/09/13(日) 20:08:02.62ID:24n75C+P >>112
いやいや
HTMLの構造はこうですって、仕様にしちゃったらそれはもう外部に漏れてんだよ
その仕様を前提に、どこのだれがどんなCSSを書いたかなんてわからねえぞ
いざHTMLの構造を変える時に、無駄な調査工数がかかる
HTMLは仕様ではなく実装である、とすればHTML構造はいつでも変化しうるんだ、ということが誰にでもわかる
なのでCSSを気軽に追加するバカもいなくなる
コンポーネント内部のHTML構造の変更のために、バカバカしい調査をする必要もなくなるわけだ
いやいや
HTMLの構造はこうですって、仕様にしちゃったらそれはもう外部に漏れてんだよ
その仕様を前提に、どこのだれがどんなCSSを書いたかなんてわからねえぞ
いざHTMLの構造を変える時に、無駄な調査工数がかかる
HTMLは仕様ではなく実装である、とすればHTML構造はいつでも変化しうるんだ、ということが誰にでもわかる
なのでCSSを気軽に追加するバカもいなくなる
コンポーネント内部のHTML構造の変更のために、バカバカしい調査をする必要もなくなるわけだ
116デフォルトの名無しさん
2020/09/13(日) 20:08:11.90ID:bz2S3zJv オンライン会議の参加者それぞれにexeファイル渡し、マイクから発言時間をリアルタイムで記録して会議の進行役が盛り上がり具合を見れるものを作ろうと思ってます
とりあえず触ったことのあるc#で音声認識ライブラリを使って時間を記録し、それをデータベースに送信して管理する形を考えているんですが
、言語とか使うデータベースこんなのがいいってありますか?
ズブズブの素人なので的はずれなこと言ってたらごめんなさい
とりあえず触ったことのあるc#で音声認識ライブラリを使って時間を記録し、それをデータベースに送信して管理する形を考えているんですが
、言語とか使うデータベースこんなのがいいってありますか?
ズブズブの素人なので的はずれなこと言ってたらごめんなさい
117デフォルトの名無しさん
2020/09/13(日) 20:08:45.61ID:8aNWh6BR118デフォルトの名無しさん
2020/09/13(日) 20:09:13.68ID:8aNWh6BR119デフォルトの名無しさん
2020/09/13(日) 20:09:31.03ID:24n75C+P >>114
した結果がコンポーネント
した結果がコンポーネント
120デフォルトの名無しさん
2020/09/13(日) 20:10:06.72ID:8aNWh6BR >>115
> いざHTMLの構造を変える時に、無駄な調査工数がかかる
いちいち変えるな。仕様として決めないで
いきあたりばったりで作業してるから、変えることになるんだろ
無駄な調査工数がかかるのも、いきあたりばったりで仕様を残してないからが一番の理由だな
> いざHTMLの構造を変える時に、無駄な調査工数がかかる
いちいち変えるな。仕様として決めないで
いきあたりばったりで作業してるから、変えることになるんだろ
無駄な調査工数がかかるのも、いきあたりばったりで仕様を残してないからが一番の理由だな
121デフォルトの名無しさん
2020/09/13(日) 20:10:48.20ID:24n75C+P >>117
インターフェースは軽々しく変えてはならない
HTML構造はインターフェースほど安定したものではない
ちょっとした要件の変化に応じて変えていくものだ
HTMLはインターフェースにはなりえない
インターフェースは軽々しく変えてはならない
HTML構造はインターフェースほど安定したものではない
ちょっとした要件の変化に応じて変えていくものだ
HTMLはインターフェースにはなりえない
122デフォルトの名無しさん
2020/09/13(日) 20:11:24.96ID:24n75C+P >>118
関係ないで無視したらデザインがぶっ壊れるだろ
関係ないで無視したらデザインがぶっ壊れるだろ
123デフォルトの名無しさん
2020/09/13(日) 20:11:57.70ID:8aNWh6BR >>115
> HTMLは仕様ではなく実装である、とすればHTML構造はいつでも変化しうるんだ、ということが誰にでもわかる
HTMLの構造は要求が変わったときだけ変化する
見た目が変わっただけでは変化しない
逆に言うならば、見た目を変えるだけならば、HTMLの構造は変化しない
それはすなわちコンポーネントを変更する必要がないということだ
見た目は容易に変わるが、コンポーネントの機能はさほど変化しない
お前のように見た目とコンポーネントが強く結合してしまってりゃ
見た目の変更でコンポーネントに修正まで入るんだろうなw
> HTMLは仕様ではなく実装である、とすればHTML構造はいつでも変化しうるんだ、ということが誰にでもわかる
HTMLの構造は要求が変わったときだけ変化する
見た目が変わっただけでは変化しない
逆に言うならば、見た目を変えるだけならば、HTMLの構造は変化しない
それはすなわちコンポーネントを変更する必要がないということだ
見た目は容易に変わるが、コンポーネントの機能はさほど変化しない
お前のように見た目とコンポーネントが強く結合してしまってりゃ
見た目の変更でコンポーネントに修正まで入るんだろうなw
■ このスレッドは過去ログ倉庫に格納されています
