JavaScript の質問用スレッド vol.123 [無断転載禁止]©2ch.net

2017/04/03(月) 00:31:25.68

JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-6のテンプレを読んだ上で質問してください。次スレは>>950が>>2のテンプレ案(本スレで改善案があれば考慮)を元に立ててください

■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
　　(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
　　具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
　　わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
　　※必ず「問題の事象が再現されること」を確認してください。
　　　必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) ライブラリ関連の質問は禁止です。関連スレにあるライブラリ質問スレで質問して下さい。
(10) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。
※前スレ
JavaScript の質問用スレッド vol.122
http://echo.2ch.net/test/read.cgi/tech/1472426483/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2017/05/06(土) 11:53:54.14

>>72
> JavaScriptから始めた人間としては、なんだこの糞仕様死ね、としか思えない。
>>67が使用しているコードでは RadioNodeList は使っていないように読めるので、それは別の話。

「他人のコードに倣っておけばOK」は参考にしたサイトがダメだと意味がないし、本当の意味で理解したとは言えないので個人的にはお勧めはしない。
客観的な評価としては、仕様書と回答内容を比較して正誤を判断するのが確実かね…。
少なくとも、模範となる信頼性の高いサイトが一つ二つないと初心者は間違いなく、はまる。

2017/05/06(土) 12:42:20.62

経験上、「どっちがいいですか」系の質問は「判断する目がない」もそうだが、「自分から学ぶ意志がない」がほとんどだな
自分から学ぶ意志がない質問は次のどちらかになる

- 質問文に自分の考えが皆無で回答者に判断を完全に委ねている質問
- 自分の考えがあっても、まともな基礎勉強してないことが丸分かりで、質問内容が広範、基礎から全部教えないと理解できないと思われる質問

後者は学ぶ意志はあるが、独学が苦手で熟練者に手取り足取り教えて貰う方が早いと思っているタイプ
まともな回答は豚に真珠なので、痛い目を見るまで間違い続けるのを見守るのも優しさかと思う

2017/05/06(土) 13:16:30.69

>>73
いや多分あの書き方だと、「一度捕まれたら名前は消えない」という仕様は、
RadioNodeList以外にも適用されてるぞ。
もっとも、同じ名前のフォームを使う場合がradioButton以外にはほぼないので、
自動脳内補完したのだとも思えるが。そもそも名前も変えないしね。

> 模範となる信頼性の高いサイトが一つ二つないと
まあ俺らはこれを提示すべきかもな。
つってもgoogleやYahooとか、いわゆる大手どころ
（Webサイトにも金を掛けて居るであろう所）
を見ればそんなに大外れはないとは思うが。

> 本当の意味で理解したとは言えないので個人的にはお勧めはしない
ちなみに俺は習うより慣れろ派。
初心者の時点ではどっちがいいなんて分からないよ。
そこで踏みとどまってしまってコードを書かないから上達しない。
だからどっちでもいいからとにかく書け、迷うなら適当に他人を参考にしろ、だね。
理想的には理解して書いた方がいいけど、それが出来る奴はあんな質問しないよ。
「どっちがいいですか」ではなく、「どこがどう違うんですか」になる。

>>74
初心者に要領を得た質問をしろというのはそもそも無理だ。

ただ一般論としては、同じようなAPIがあるのなら、とりあえず新しい方使っとけ、かな。
大体は古いのに問題があったから更新されてるもわけでね。
偶に「新しいことこそが正義」みたいな馬鹿も沸くけど、
それはここではある程度どうしようもない。

2017/05/06(土) 17:36:04.74

>>75
> 初心者に要領を得た質問をしろというのはそもそも無理だ。
「質問の初心者」と「JavaScriptの初心者」は等価ではないと俺は思う
そもそも、俺は要領を得た質問を求めているわけではない
(勿論、最終的にはそうなるのが理想だが)

俺が指摘しているのは「学ぶ姿勢」で受動的な学習しかしない人は伸びないのだよ
分からないなりに調べて、分からないなりに調べた結果を書いて、それで要領を得ない質問になったとしても、調べた経験は無駄にならない
回答者は質問者の知識レベルを踏まえた回答が出来るというメリットもある
それは回答を貰って「自分には難しすぎる」と匙を投げるか、出来る限り理解しようと努力するか、の違いでもある

自分から何も調べず、回答者に完璧な回答を求めて、回答を貰って満足するタイプは自分で調べる事をしないから、いつまでたっても他人に質問して問題解決を図ろうとする
そういう人は独り立ち出来ず、いつまでも「初心者」のままだ
実際、某Q&Aサイトでも名前を何度も変えては同じような質問を繰り返して、詳しい回答を貰うと「初心者なので分からないです」と返信する人がいるよ

2017/05/06(土) 17:42:11.82

>>75
> ただ一般論としては、同じようなAPIがあるのなら、とりあえず新しい方使っとけ、かな。
対象ブラウザによっては新旧APIを併用するか、旧APIを使用する事もある
PromiseとかFetchとか、IE11で実装されてないことを踏まえれば、「とりあえず、新しいAPIを使っとけ」という判断にはならない事もあるだろう

2017/05/06(土) 19:31:13.08

>>76
質問をするスキルか。確かに今の時代だとそれが必要なのかもしれないね。
初心者にも分かるように言うと、とにかく全部ダンプしろって事だな。
何をやろうとしていて、どこで引っかかっていて、何を迷っているか。
長文が～っていう奴はゴミだから無視でいい。
というかやってりゃ分かるはずだけど、
MDNでも仕様書でもここの「長文」どころじゃない。
三行越えたら長文だ～みたいな奴はプログラマに向いてない。

>>77
そういやJavaScriptはこれがあるんだった。
初心者にも分かる結論としては、
「新しめのAPIの方がいいが、新しすぎるのは駄目」ってところか。

2017/05/06(土) 22:35:31.96

いくら新しいAPIの知識はあっても
現状の実装をいかに把握するかだけ
これだけ

2017/05/06(土) 23:59:40.05

>>75
> いや多分あの書き方だと、「一度捕まれたら名前は消えない」という仕様は、
> RadioNodeList以外にも適用されてるぞ。
どうして「同じ」と解釈したのか、理解できなかったので、仕様のどの文章をどう解釈したのか、説明が欲しい。

document.forms は HTMLCollection を返すので live
https://momdo.github.io/html/dom.html#dom-document-forms
form[name] は RadioNodeList (NodeList を継承している) を返すので not live
form.elements は HTMLFormControlsCollection を返すが、HTMLCollection を継承するのでこちらも live
https://momdo.github.io/html/forms.html#the-form-element:dom-form-elements-2

Google Chrome 58.0.3029.96 で再現出来なかったので、現象を再現可能なコードも欲しい。
https://jsfiddle.net/3duzojn3/1/

2017/05/07(日) 00:55:55.42

>>80
こちらも動作を確認したがそちらと同じ。
英語の仕様書も確認したが確かにそう書いてある。
しかし動作はそうなってないね。

> 一度要素が特定の名前を使用して参照されると、
> たとえ要素の実際のIDまたはnameを変更しても、要素がツリーに残る限り、
> その名前は、この方法でその要素を参照する方法として利用され続ける。
これはつまり、ブラウザ内部に名前引き用のキャッシュを持っていて、
ヒットした場合はそれを使い、ミスなら新規登録、
ノードが取り除かれる時にエントリから消し、
DOMノードの属性変更ではエントリを確認してないと言っている。
（更新はしないので一旦登録されたら名前が残ったままになる）
高速化では定番の方法だし、実際に名前を変える必要があることは無いので、
内々で使う場合の仕様としてはこれもありだろう。
ただし外面仕様として出す場合はこれは無理だ。知識的に粗結合化出来てない。
（このAPIを使う場合に例外ケースを把握してないと使えない）

だからこの仕様を外面仕様としている場合は間違いなく糞だ。
ただし、実際の動作はそうなってない。
どっちが正しいのかは俺には分からん。

仕様として美しいのは間違いなく今のブラウザの動作だ。
だから推測するなら、
元々マクロ用だった為の奇妙な（ただし知っていると便利な）DOM周りの旧仕様を
一般的なプログラミング向けの仕様（直感的、統一的、一貫性重視）に
変更している最中といったところか。
俺が仕様について裁定する権限があるのなら、
上記引用部分を削除して終わりだね。（ブラウザの動作に合わせる）

2017/05/07(日) 05:32:07.74

そういうのはDOM Lv0といって昔のデファクトを文章にしただけのものだから
ベンダー間でこうしていきましょうねと合意が取れてるものとは違うぞ
Webは生き物だから正しいも正しくないもない
神様も居ない

2017/05/07(日) 09:10:15.71

まあしかし、仕様書と実装の同期は取っておくべきだろ。
それが>>80の意図だろ多分。

こちらで試した限りではFireFoxでも同じだった。
80が仕様について何かやっている人なら頑張れとしか。

2017/05/07(日) 09:41:57.10

>>81
伝わってないようだが、「その3行の意味が理解できないから説明してくれ」や「その仕様が糞である理由を説明してくれ」ではない。
RadioNodeList 以外にも「たとえ要素の実際のIDまたはnameを変更しても、要素がツリーに残る限り、その名前は、この方法でその要素を参照する方法として利用され続ける」が適用されると判断した「仕様の文章」を引用して「あなたの解釈」を説明してくれ。

2017/05/07(日) 09:51:22.86

>>84
いやそれは文章そのものだろ。
和文も英文も、あの書き方ならRadioNodeList以外も含むとしか取れないが。
てかお前、日本語も英文も読めない人？

2017/05/07(日) 09:57:53.45

HTML Standard や DOM Standard には「後方互換性の為に標準化した旧来の仕様」が多数存在する。
(>>82のいう DOM Level 0がそれだが、子の表記はMDNでしか見たことがないな)
XHTML2.0での失敗、IE6がいつまでも現役時代だった失敗を経て、HTML5 では既存のブラウザで動く事を重視して標準化しているからだ。
それが彼(>81)の言う「糞な仕様」だが、そうする事で旧来の古いブラウザの独自拡張で書いたコードも全てのブラウザで動くことが保証される。
「美しい仕様」よりも「動く仕様」を重視しているので、>>81とは目指すべき方向が違う。

2017/05/07(日) 10:05:18.25

>>85
そこまで否定される筋合いはないんだが、なぜそう挑発的なんだ？

> 指定したIDまたはname（歴史的な理由でイメージボタンを除く）をもつフォームでフォームコントロール（または複数存在する場合、フォームコントロールのRadioNodeList）を返す。または、いずれも存在しない場合、与えられたIDとともにimg要素を返す。
> 一度要素が特定の名前を使用して参照されると、たとえ要素の実際のIDまたはnameを変更しても、要素がツリーに残る限り、その名前は、この方法でその要素を参照する方法として利用され続ける。
> 複数のマッチするアイテムが存在する場合、それらの要素すべてを含むRadioNodeListオブジェクトが返される。

この文章は form[name] に書かれたもの。
文章内で「form.elements や document.forms にも適用される」とはない。
返り値の Interface も RadioNodeList と HTMLCollection で全く違う。
どう解釈したら「form.elements や document.forms にも適用される」となるのか日本語を読めない俺に説明してくれ。

2017/05/07(日) 10:48:18.68

>>87
> 日本語を読めない俺に説明してくれ。
それは無理。

ここで国語の授業をするのは原理的に無理なんだよ。
俺が日本語でいくら説明しても、君はそれを俺が意図した通りに読めないことを意味する。
君がいくら反論してきても、それは俺には君が意図したとおりには伝わらないことを意味する。
だから片方の言語が不自由な時点で、「文章での」議論は空転する。
だからこそ韓国人はここではものすごく嫌われているわけでね。

俺には和文も英文もそうとしか取れないし、
仮にそれが俺の間違いなら、俺がそれを君に俺の文章で説明することは不可能なんだよ。
だから原理的に無理。

2017/05/07(日) 10:57:46.04

>>88
そうか。日本語を日本語で説明できないとは謎理論だが、あなたの中ではそうなんだな。
>>87では「日本語が読めない」と書いたが、それは言葉の綾で俺は日本語を読めると思っている。
「>>88の中では RadioNodeList 以外にも適用されると解釈したんだな」ぐらいに思っておくことにする。
俺はあなたの根拠なき主張を信じないがね。

2017/05/07(日) 11:16:41.63

なぜいつもこうなるのか

2017/05/07(日) 12:08:47.12

韓国人が紛れ込んでいるからだろ。
2chにおける典型的なスレ崩壊パターンだよ。
だから彼等は嫌われる。

実を言うと80の時点で意味不明だった。
そもそも俺が噛み付かれる理由がないし、
文章自体も直接的に俺に向けた物とも思えなかった。（話が噛み合っていない）
ただ俺はこういう馬鹿も見飽きてるし、コードが上がっているので試しに見てみたら、
ああなるほど彼はこれが言いたかったのか？と思って81を書いた。
それが伝わっていないというのなら、俺にはどうしようもない。あれで精一杯だ。

ちなみに俺はゆとりに対しても同様に怒っているが、
ゆとりに関しては日本人だから俺らにも教育責任はあるとも思う。
ただ韓国人については死ねとしか思わないね。

2017/05/07(日) 12:18:54.29

ID:nVVEnA7X0 が感情的になって無駄に煽るから、こうなる
どちらかが間違っている事ご分かっていて、「日本語も英文も読めない人？」といわれたら、カチンとくるのは当然
>>80はそれでも我慢した方だと思う

2017/05/07(日) 12:23:58.61

支離滅裂すぎる
全然関係ないこのスレに人種差別持ち込むなよ

2017/05/07(日) 12:39:51.32

>>92
逆ギレ止めーや。
つか最近そういう奴も増えたけどね。
基本的価値観として、まともな日本人なら、「間違っている奴が悪い」なんだよ。

既に書いたが、和文も英文も俺にはそうとしか読めないし、
それで間違っているというのなら、俺がそれを説明する能力なんて原理的にないのさ。
だからその説明を俺に求めるのも論理的に矛盾してる。
お前らは馬鹿すぎてこのことが理解出来ないようだが。

2017/05/07(日) 13:22:06.98

>>93
そうやって正統な批判を全部人種差別にすり替えるのが韓国人の汚い手口だよ。
だから今後とも嫌韓は収まらない。

そもそもここで韓国人呼ばわりされることがおかしいだろ。
顔も見えない、性別も分からない、見えるのは書き込みだけなのに。
それでも嫌われるのはそういうことをやり続けてるからだよ。
今回の例で言えば、

仕様書「RadioNodeListを含みます」
俺「『含みます』って書いてあると思うけど」
韓国人「いやそうは書いてない。書いているという証拠を示せ」
俺(どうしろと)

俺が間違っているというのなら、お前らが代わりに説明してやればいいだけ。
それも出来ないのなら、お前らは批判の為の批判をしているだけ。
それは韓国人やヤクザの手口だよ。だから彼等は嫌われる。
そういうゴミを嫌う権利は誰にでもある。ここら辺をパヨクは間違っている。
もちろん、俺を嫌う権利はお前らにもある。
だから俺はWeb板のスレには行かない。俺が嫌いならあっちで頑張れ。
あっちはあっちで機能しているし。

こうやって複数のスレで競争しないと、
今のJavaScriptのスレの面子では状態を改善出来ないんだ。
だから俺が強硬に並立を主張したわけでね。

2017/05/07(日) 13:30:47.09

ああすまん、ミスってた。
無駄に喧嘩になっても仕方ないので一応投稿し直す。

仕様書「RadioNodeList以外も含みます」
俺「『含みます』って書いてあると思うけど」
韓国人「いやそうは書いてない。書いているという証拠を示せ」
俺(どうしろと)

とにかく、俺には含みますと書いてあるとしか見えない。
それが俺の間違いだというのなら、君らがそれを指摘してくれればいい。
俺にはこれ以上どうすることも出来ないのさ。

2017/05/07(日) 13:37:00.76

┐(´∀｀)┌

2017/05/07(日) 13:42:44.84

典型的なネット右翼やな

2017/05/07(日) 14:22:41.48

空気を読まずに蒸し返してみる

ある事の証明は存在をひとつ示せばいい
ない事の証明は全てを網羅しなければならない
この２つの証明はは等価ではなく後者の方が圧倒的に困難である
よって、ないことを証明しろ、それが出来ないならあるのだという論法は典型的な詭弁の手法として用いられる

ある事が分かっているならば当該箇所を示せばその時点で論破()できるのに、それをせずに相手に悪魔の証明を求めるのは、あるという証拠の１つすら示せないからに他ならない

2017/05/07(日) 14:55:04.57

つか、何度も言っているが、
俺が間違っているというのなら、お前らが説明してやれよ。
マジでお前らヤクザのやり方を地で行ってるぞ。

仕様書の該当部分は既に明示されているし、
そこにはそう書いてある（と俺には読める）
これ以上俺が出来ることはないんだよ。

お前らって、内容を読まずに批判する為の批判を繰り返すよね。
そして相手が悪いという事に無理矢理持っていこうとする。
これはゆとりに多いパターンだけど。

あ (ｱｳｱｳｲｰ Sa37-gZQE) · 2017/05/07(日) 15:04:07.44

イデオロギーと主張と日本語が読めないと言うのは互いに疎だろうから、ちょっとこうなると話が終わらなくなるな。

>>95
正当か正当でないかは主観だから言い換えるとして「正当かもしれない批判を全部人種差別にすり替える」を技を
>>95という批難のレスが自己言及を起こしてるから、根拠を足すか別の表現で説明して。
批判のための批判ではなくて、論理的に正しい批判が読みたいな、俺は。

2017/05/07(日) 15:38:18.75

>>101
日本語でおk

2017/05/07(日) 16:22:44.83

ヤクザ、ゆとり、韓国人、これらはすべて論理的な議論において無用なレッテル貼りでありこれまた詭弁の典型例である
発言者が馬鹿だと論旨の正否に関わらず批判を受けるという好例だわ

2017/05/07(日) 16:58:46.44

>>80は真っ当なものだし、正しいと俺は思う
根拠(URL)も十分に出てるし、補足することは何もない

対して彼の返答は「そうとしか読めない」しかなく、具体的なところは何もない
信じてもらえなくて当然だと思う

2017/05/07(日) 17:24:34.96

>>96
少なくとも彼は>>80や>>87で自分の正当性を説明出来ているけどね
君はなぜか完全スルーの構えでそこに触れてないが
仕様は変わらないのだから、仕様の解釈を説明するしかないのに、それが出来ないのは君に説明能力がないとしか思えない

あと、君の発言は段々、暴論になってきているから気を付けた方がいい
人格否定や差別的発言は明らかに君が間違ってる(君の論にてらせば、君が悪い)
いっちゃ悪いが、自分の発言が認められなくてだだをこねている子供のようだ

2017/05/07(日) 19:09:24.78

というかこの手の「ゆとりスクラム」、最近割と良く遭遇するようになったが、何がしたいんだ？

俺に説明能力がないというのなら、俺に説明を求めること自体がおかしいし、
説明能力があるゆとり君が代わって説明すればいいだけ。
俺が文章を読めてないというのなら、俺にそれを文章で説明しろというのは無理な話。
俺を信じれないというのなら、ああそうですかでしかない。そもそもそういう話ではないし。

ゆとりって基本的に他人に文句は言うけど、自分で改善しようとは全くしないよね。
今の現実世界はそれまでの大人達が少しずつ改善を重ねてきた結果だというのに。

俺は2chしかほぼ見てないから
> 実際、某Q&Aサイトでも名前を何度も変えては同じような質問を繰り返して、
> 詳しい回答を貰うと「初心者なので分からないです」と返信する人がいるよ (>>76)
には遭遇したことがないけど、(というより遭遇しても気づくほど見てない)
この手の「無理矢理○○って事にしたい」ってのは最近すごく遭遇するんだが。

2017/05/07(日) 20:11:06.03

わかったから他所でやってや
ゆとりでもそうでなくてもどうでもいいが、スレタイぐらいは読めるやろ

あ (ｱｳｱｳｲｰ Sa37-gZQE) · 2017/05/07(日) 20:31:31.21

>>102
日本語読めないんだ。

あ (ｱｳｱｳｲｰ Sa37-gZQE) · 2017/05/07(日) 20:36:30.42

>>106
破綻しとる。
自説を説明する能力がある人間でも、代わって「おまえの理論」の説明はできまい。
説明能力が無いなら説明を求めるのがおかしいって無茶苦茶じゃん。
説明能力がある奴に、説明を求めるのは無意味だろ。
だって説明能力があるならば、求めるより前に説明してるはずじゃん。
説明能力か無いからこそ、説明しろと要求されていると思えよ。
論理的にやろう。ゆとりも、非ゆとりもな。

2017/05/07(日) 21:20:48.44

> 俺に説明能力がないというのなら、俺に説明を求めること自体がおかしいし、

書いてあんだろ？

「俺に説明能力がない」だ
説明が足りないじゃない。
説明する能力がないのだ。

感情を表現する能力がないやつに
感情を表現しろと言っても無理だろ？
計算する能力がないやつに計算しろと言っても無理だろ？
説明する能力がないやつに説明しろって言っても無理だろ？

2017/05/07(日) 21:34:41.49

つまり結局こうだろ

>>109
日本語でおk

2017/05/07(日) 21:46:16.89

要するに「無能」が正しいと認めているわけだから、
「無能」に聞いても、能力がないやつには答えられないということ

あ (ｽﾌｯ Sd52-gZQE) · 2017/05/08(月) 06:06:52.81

>>112
違う違う。
無能だからこそ、説明を求められるんだ、と。
能力が無いならば、最初から説明しようとすらするはずが無いんだよ。
全くできない事をしようとする事はあり得ないんだし。
空が飛べないのに空を飛んで見せるのが、全くできない事をするって言うことだよ。

相手の言葉をうまく摘んで「無い」の定義を適当に用意してはいかん。ただの逃避だよ。
それこそ自分が揶揄してるやつ。
吐いた唾は飲もう。

2017/05/08(月) 09:35:49.25

無能なほど意味不明な説明をしたがる

2017/05/08(月) 11:29:12.00

自らの正当性を主張する人が自己完結していないわけがなので、ID:nVVEnA7X0も俺も自己完結している点では同じ
見解の相違で衝突した場合、お互いに根拠を出しながら意見を出すのが普通
相手の論理を崩すには「相手が出した根拠が間違っている証拠」をだしたり、「根拠の解釈が間違っている論理的矛盾」をだしたり、と論理的に話をする

ところが、ID:nVVEnA7X0 は「いや多分あの書き方だと(>>75)」「そうとしか取れない(>>88)」と恣意的な感想を述べるばかりで根拠も論理展開も何もなければ、相手の論理的矛盾に言及するわけでもない
根拠や意見を掲示するのは>>80だけ
説明出来ないというが、「そうとしか取れない」理由を具体化すれば説明可能なはず
具体的な何をすれば良いかは>>84で補足要求してくれているのに無反応
この状況で説明能力がないといわれるのは仕方がないし、何も反論出来ないのなら説明能力がないと認めているも同義だと思うがね

2017/05/08(月) 11:29:40.46

人間なんてみんな無能だよ
協力し合わないとなにも為せないんだよ
そのことを忘れちゃだめ

2017/05/08(月) 13:25:26.02

とりあえずスレ違いだからツイッターあたりでバトってもらっていいかな？

2017/05/08(月) 14:07:05.92

一体何と闘ってるの？w

2017/05/08(月) 21:44:07.20

そりゃレスした相手とじゃね？

2017/05/11(木) 22:25:00.55

window.fetchでshift-jisのデータをダウンロードしてresponse.text()で文字列にすると文字化けしてしまうのですがどのようにすれば文字化けしないようにできますか？

2017/05/12(金) 08:25:26.77

>>120
サーバ側で正しい文字コード(Shift_JIS)を指定する
https://www.google.co.jp/search?q=htaccess+charset

2017/05/12(金) 08:36:44.00

>>121
外部サーバーなので出来ないです(´；ω；`)

2017/05/12(金) 09:15:45.68

メッセージングの手段とかないの？
まあ例えばC#アプリとやり取りするときとか、最も汎用的な方法はローカルWebSocketだよ

2017/05/12(金) 09:40:01.01

2chも、shift-jisだから、JSで扱えない

でも、YQL(Yahoo Query Language)を通して取得したら、UTF-8になってる。
文字コードを推測して、変換しているのかね？

この板よりも、web制作管理板で質問した方がよいかも。
そっちの方が、人が多いから

2017/05/12(金) 09:46:56.13

> 2chも、shift-jisだから、JSで扱えない

そんなわけねーだろｗ
文字コードを変換すればいいだけ

2017/05/12(金) 09:48:05.24

もしくは適切にパラメータ与えれば
ブラウザが勝手にやってくれる

**124** (ﾜｯﾁｮｲ cf75-yoyE) · 2017/05/12(金) 10:15:34.52

iframe に読み込ませれば、ブラウザが自動変換するから、文字化けしないけど、
自分で、JSで、2chのHTMLを取得しようとすると、shift-jis のままじゃないの？

つまり、ブラウザを通せば、変換されるけど

2017/05/12(金) 13:33:42.65

Fetch APIにはContent-Typeを上書きする機構はないのかな

>>122
外部サーバならクロスドメインを許可してる事になるという事？
それなら、そのサーバ管理者に相談してみては？

2017/05/12(金) 13:46:56.99

http://echo.2ch.net/test/read.cgi/hp/1456242505/392
「移動を勧められたので、移動しました」と言い訳しそうだが、質問をクローズせずに並行質問する行為はマルチポストという
人が多いとノイズも多くなるので、俺はWeb制作板をお勧めしないな

2017/05/12(金) 13:55:16.77

new Headers で XMLHttpRequest#overrideMimeType 相当の機能が実装できそうだが
https://sbfl.net/blog/2017/01/29/fetch-api/#i-3

2017/05/12(金) 14:55:20.81

>>130
リクエスト時のヘッダーにコンテンツタイプを指定するってことですよね？やったんですが出来ませんでした。

2017/05/12(金) 14:56:27.27

>>28
相手は2ちゃんのサーバーです

2017/05/12(金) 15:00:29.58

fetchにはオーバーライドマイムヘッダーはないというとこですか？
文字コードを変換することは出来ませんか？
実行環境はelectronのrenderer processです
出来ればnode.js特有のモジュールを使わない方法がいいですが...

**sage** (ﾜｯﾁｮｲ b3d1-Y6YN) · 2017/05/12(金) 22:45:38.02

setTimeoutとseIntervalって使い分けってどうやるんやるんですか？
なんか参考にするコード教えてください

2017/05/12(金) 22:52:47.26

そのまんま、一定間隔で実行を繰り返したいか一回だけ呼びたいかの違い

2017/05/13(土) 02:16:56.42

>>132
2chは、文字コードを指定していないから、やっかい。
JSでは、UTF-8 と扱われて文字化けする

結局、jQueryから、YQL (Yahoo! Query Language)のサービスを使って、
2chのHTMLを取得できた。
YQLで、shift-jis からUTF-8へ、文字コードを自動変換しているのかな？

jQuery → YQL → 2ch

VBScriptについて必死に話し合うスレ
http://echo.2ch.net/test/read.cgi/tech/1416826139/924

2017/05/13(土) 03:58:22.44

>>134
一定周期動作をさせるなら、処理完了後からIntervalを取るか、処理開始時からIntervalを取るか
例外でタイマーを止めるか、一定周期で例外を出力し続けても止めないか

2017/05/13(土) 06:43:23.71

「settimeout setinterval 違い」で検索！

2017/05/13(土) 10:44:28.39

HTMLのテキストボックスへ日本語を入力中に、
強制的に確定（Enterを押した場合と同じこと）
もしくは入力をキャンセルさせる（ESCを2回押したような処理）ことは可能ですか？

2017/05/13(土) 11:20:23.82

IMEイベントを上手く利用すれば可能

2017/05/13(土) 11:42:20.94

それができるなら、利用者の性癖を盗みとる事ができそうだな

2017/05/13(土) 20:35:36.55

カンマ演算子を積極的に使っているコードを知らないか？
この際、他言語でも構わない。

三項演算子を使って宣言的（という言い方が正しいかは微妙だが）に記述すると、
var somevalue = (caseA)? valueA : (caseB)? valueB : valueC;
という形になってくるのだけど、
この際単純な式だけでは無理な時があって、カンマ演算子を使いたくなってくる。

とはいえCの世界ではほぼ完全に禁止に近くて、推奨とか積極使用とかは聞いたことがない。
おそらく何らかの問題をはらんでいるからだと思う。
元々Cは手続き的だし、限界までチューニングするので、相性も悪い。

そこで、わりと好き勝手やっているJavaScriptの世界なら誰かしら使っているかもしれんし、
ソースも見えて助かるので、どこか積極使用しているところとか知らないか？
推測だが、他の「宣言型」と言われる言語も
本当に宣言的に記述するのなら大量使用しているはず。
ソースが公開されていて、何をやっているか分かり、
相手の技量も分かる状況なら他言語でも構わないのでよろしく。
さらっと調べてはみたんだが、
そもそも使ってない言語の検索では要領を得ず、いいのが出てこない。

Scala使っているやつ居たよな？そっちではどうとか、あればよろしく。

あ (ｽﾌﾟﾌﾟ Sd9f-4rj3) · 2017/05/13(土) 20:52:18.30

>>142
google closure compilerが割と積極的に,使ってくるよ。

問題と言えば、代入だったら実際に代入される値から遠いとか、そもそも分けて書けよとか、アトミックである保証がある場合とない場合があるとか、色々ある。

2017/05/13(土) 21:35:25.83

つかClosureCompiler遣い居たのか。
それってコンパイル後のコードって読まないでしょ？
（なんで君が読んでいるのかは知らんが。
さすがにミニファイは読めないから信じるしかなくて、
通常ClosureCompilerもそれに近い扱いだと（勝手に）思っているが）

おそらく問題は「可読性」だけなんだと思っている。
だからコンパイラやトランスパイラが使うのは全く問題なくて、
逆に言えば、使うメリットがあるからコンパイラが使っているとも言える。

可読性の問題はおそらく「色々な書き方が出来ること」「読む方が不慣れなこと」に尽きる。
だから「コンマ演算子が多用されている『世界』」があれば、
彼等はなんとかしているのだとも思っている。だからそれを確認したい。
googleのコーディングルールでは、
C++もJavaScriptもカンマ演算子を明確には禁止にしていない。多分グレーゾーンだ。

> アトミックである保証がある場合とない場合があるとか
カンマ演算子でアトミックに出来るか？
というかいわゆるマルチスレッド環境で言う「アトミック」はJavaScriptにはないはずだが、
それ以前にシングルスレッドだからアトミックとか要らんわけだが。

2017/05/13(土) 21:37:14.85

カンマ演算子みたいな副作用前提のものを宣言型プログラミングで積極的に使うなんてことあるかぁ？
ただ一文になってるってだけじゃん
普通は関数化して処理部分は関数内に隠蔽するでしょ

2017/05/13(土) 21:58:34.66

いやその関数を2回呼びたくない時にどうするかだよ。

副作用無しの関数なら、先に呼んでしまって一時変数化するというのが通常の解法。
でも最初の分枝、142の例で言うとcaseAに当たった場合にこれは不要なら、
関数呼ぶだけ無駄でしょ。

関数に副作用がある場合は一時変数化も出来なくて、
if文でしこしこ書くことになる。

とはいえ関数型の場合は副作用無しにして何度でも呼んでしまえ、が正義なのかもね。

なお俺が使おうとしている状況は、、、と詳細に説明しようとしたが、
JavaScriptの場合は型無しなので、 || と && 上手く使ったら
カンマ演算子無しで書けそうな気もしてきたorz

2017/05/13(土) 22:15:31.25

？？
関数を2回呼ぶとか一時変数にしないといけないってのがよくわからん
必要ないと思うけど…まぁ本人が自己解決できそうならいいか

2017/05/13(土) 22:23:27.64

どの言語でもそうだけど、

コロンで区切れば、独立した文だから、安全

カンマでは、独立した文にならないから、
副作用・評価順序などを勘違いしやすく、バグが多くなる。
だから、カンマは使わない方がよい

短絡評価も、後ろの式が実行されるかどうか、分かりにくいので、
使わない方がよいと言われる

2017/05/13(土) 22:26:02.59

とりあえず、文と式の区別がつくようになってから出直しなさい

2017/05/13(土) 22:35:08.66

プログラマーたるもの言語仕様に依存せず、型を強く意識し型に対してプログラミングしましょう

2017/05/13(土) 22:35:17.69

>>147
あ、いや、やっぱ多分無理だ。こんな感じ。
（カンマ演算子は使ったこと無いから文法が怪しいが、多分これであってると思う）

var result = (sel==='ALL')? query_set(name, 'ALL') :
(var tgts = get_tgts(name), (tgts)? query_set(name, tgts) : obj[name]);

sel==='ALL'の時にはquery_setを呼び出す。
それ以外の時にはget_tgtsでリストを確認し、該当した場合はquery_setを呼び出す。
該当無しの場合は単にobjを名前で引く。

query_setは何度呼んでもいいが、
初めて呼ぶ場合には obj[name] に色々初期化した物を作成して登録する。
登録されている物はobj[name]で確認出来るし、
2回目以降(既にobj[name]が存在した場合）にはobj[name]が返される。
だから上記は、
sel==='ALL'の時は常にobj[name]を引き、無ければ登録してそれを返す、
それ以外の場合は、新規登録リストget_tgtsにあれば新規登録してそれを返す、
なければ既に登録されていればそれを返す、となる。
ここで get_tgtsは何度呼んでもいいから上記は

var result = (sel==='ALL')? query_set(name, 'ALL') :
(get_tgts(name))? query_set(name, get_tgts(name)) : obj[name];

とすることも可能だが、 get_tgts(name)は重くなる可能性があるので
必要な時にのみ一度引くようにしたい。
逆に obj[name]は1回引いて終わりだし、こちらも何度引いてもいいので、

var result = (sel==='ALL')? query_set(name, 'ALL') :
(obj[name])? obj[name] : (var tgts = get_tgts(name), (tgts)? query_set(name, tgts) : null);

とも出来る。

2017/05/13(土) 22:35:19.85

これだと、fが1回呼ばれるのか、2回か、どちらか分からない
1 < f() && f() < 10

こう書けば、1回しか呼ばれない
a = f();
1 < a && a < 10

Pythonでは、こう書けるから、1回しか呼ばれない
1 < f() < 10

fがオブジェクト・関数などの場合、どういう副作用があるか分からない。
何かのリソースにアクセスして、その電荷を変えてしまうかもしれない

volatile というけど、読み取っただけでも、電荷が逆転するデバイスがあるから、
2回読み取ったら、正常に動かないとか

2017/05/13(土) 22:35:56.65

諦めてif文でしこしこ書いてもいいのだが、tgtsなんて結局ここでしか使ってないし、
欲しいのはresulｔだけだから var result = の書き方で出来た方が見やすい。

ただ、関数型ならここをそのまま切り出して、

function somefunc(name){
ここはif文でしこしこ
return result;
}

で上位からは

var result = somefunc(name);

で隠蔽してよしとするのかな？
多分ここが噛み合ってないのだと思う。

あ (ｽﾌﾟﾌﾟ Sd9f-4rj3) · 2017/05/13(土) 22:38:11.42

>>144
いや、カンマ演算子全体に対して言ったんだよ。
読む側が不慣れとかじゃなくて、どれくらいのメリットあるの？
メリットがあってもデメリットを下回れば、そりゃ無駄なんだし。

2017/05/13(土) 22:50:19.81

>>154
ちょっと輻輳気味だが、

>>151内、
1. get_tgts(name)はユーザー作成リストを参照するので際限なく重くなる可能性があり、
可能であれば出来るだけ引きたくない。
2. ちなみに今はこの手の「重くなるかもしれないユーザー作成リスト」についてはキャッシュを作成し、
それを引いているから実は重くないのだが、キャッシュの管理が面倒なのも事実。
3. だから「重いけど我慢出来る範囲」ならキャッシュ無しで組むのもありか？とも思ったり。
その時に出来るだけ無駄のない動作をする為の記述が必要であり、それが今回。

つっても同様のケースは以前からあり、
カンマ演算子を三項演算子内で使用することについては、考えてはいたんだが。

実際、result を得る為だけに使う tgts とかは result = 式内に閉じこめた方が見やすいでしょ。
そして記述通りに動くのならそれが最速の記述ではあるし。
見やすくて速いんだからやらない理由はない。
ただしカンマ演算子については積極的に使っているのを見たことがないから、
多分何かしらかなり問題があって、、、だろうからそれを先に確認したくてね。

2017/05/13(土) 22:57:27.66

>>151
こんな感じでどうでしょ
var result = sell ==='ALL'
? query_set(name,'ALL')
: ((tgts,name,obj) => tgts ? query_set(name,tgts) : obj )(get_tgts(name), name, obj[name]);

2017/05/13(土) 23:06:40.11

>>148
> 短絡評価も、後ろの式が実行されるかどうか、分かりにくいので、
> 使わない方がよいと言われる
いやそれはCの世界では嘘だ。あっちは短絡評価ありきで組む。
そして俺はもちろんJavaScriptもそうしているし、
逆にwhile文とかは短絡評価無しだと組みにくいでしょ。
典型的パターンは以下。

var i = start;
while (i<arr.length && arr[i].prop!=xxx) i++;

関数型？で無理矢理組めば、

var i = arr.slice(start).findIndex(function(v){return v.prop==xxx;})+start;

なのか？しかし無駄が多いし余計に見にくいだろ。

2017/05/13(土) 23:17:11.98

>>156
それが
> 普通は関数化して処理部分は関数内に隠蔽するでしょ (>>145)
なのか？

その書き方ではカンマ演算子を使わなくて済んでいる。
引数を一時変数に使うことにより回避している。
これは事実だが、余計に見にくくないか？(多分if文使って書いた方がマシ)
また、それって一般的か？俺はあんまり見ないが。

（もっとも、俺は配信されているもの、
つまりコンパイル後のコードしか見てないから、ES3準拠？とかの可能性はあり、
コンパイル以前のコードについては知らないんだが）

2017/05/13(土) 23:23:24.73

「配列arrの中の、start番目以降の要素の中で、prop==xxxに当てはまる最初の要素のインデックス」を
求めるならこんな感じにそのまま書けばいいのよ
var i = arr.findIndex((v, idx) idx>=start && v.prop==xxx);

2017/05/13(土) 23:33:21.05

>>159
ああそれはその通りだね。
（俺はあの書き方はそもそもしないから慣れてない）
ただ俺はそれだとstart以前も走査するのが気に入らないから、
やっぱりwhileで回すけど。

2017/05/13(土) 23:36:49.07

>>157

var i = arr.slice(start).findIndex(function(v){return v.prop==xxx;})+start;

最近の書き方だとこうだろ？
var i = arr.slice(start).findIndex(v => v.prop == xxx)+start;

んで、lodash使えばこうなる。
var i = _.findIndex(arr, {prop: xxx}, start);

2017/05/13(土) 23:38:27.63

>>157 >>160

> なのか？しかし無駄が多いし余計に見にくいだろ。
> （俺はあの書き方はそもそもしないから慣れてない）

コードの話をしようぜ？

俺は見にくいというのは、コードの話じゃなくて
お前の話になってる。

お前が見にくいっていうのなら、単にお前が未熟ってだけ。
コードの話をしている時に、人の話をしてはいけない

2017/05/13(土) 23:41:00.33

>>159

こうだな

var i = arr.findIndex((v, idx) => idx >= start && v.prop == xxx);
var i = start; while (i<arr.length && arr[i].prop != xxx) i++;
var i = _.findIndex(arr, {prop: xxx}, start);

一行につなげて比較してみよう

2017/05/13(土) 23:46:38.05

カンマ演算子の使いどころは、一つのStatementしか記述を許されてない箇所にある
(while文の条件式、アロー関数の省略記法、三項演算子など)
省略記法が大好きな人ほど好む傾向があるかも知れない

2017/05/13(土) 23:48:01.73

>>158
いやまぁもちろんこんな無名関数をそのまま書いたりしないけどね
上と抽象度違っちゃってるし、いつもはちゃんと名付けするよ(面倒だから手抜きしましたごめんなさい)
「一般的か？」って言われたら、JavaScriptでは一般的ではないでしょう
だいたいみんなif文使うし、宣言型なんて見ない見ない
ただまぁこうやって引数にしちゃえばキャッシュ出来るよという参考までに
あとは自分で選べばいいさ

2017/05/13(土) 23:49:06.10

>>161
sliceした方がいいかどうかは場合によるのだけど、
一般的にはsliceせずに回す>>159だと思うぞ。

それはおいといて、そもそも findIndexに開始地点を指示出来ないのが謎なんだが。
だからlodashが必要になるわけで。
とはいえlodashは普及しないよ。
確かに短く書けるけど直感的ではないし、わざわざ学ぶほどの価値もない。

とにかくその件については俺はwhileの一択だ。
速いし分かりやすいし。
君がそう思わないのも君の自由。
ただいずれにしても、おれはカンマ演算子について聞きたいのであって、
157以降は俺の興味以外だから降りるよ。

2017/05/13(土) 23:55:22.89

>>165
> JavaScriptでは一般的ではないでしょう
ちなみにこれを他言語では一般的にやってるのか？それは何言語？
別に糾弾しようってわけではなくて、ちょっと見てみたい。

ちなみに抽象度については俺も思ったが、それ以前に、
1つのことをやる物を2つに分解して配置したくないので、
俺は「名前付き関数」にして呼ぶって事もしない。if文で書く。
ただしこれはCでは関数内関数が使えないからそういう文化なのであって、
関数内関数が使える言語なら別文化もありだとは思う。

2017/05/13(土) 23:56:04.26

>>157
もちろん、それでいいと思うよ
そこら辺考えだすとそうするしかない
折衷案としてはこんな感じでwhileの部分を関数化する感じかな

var searchPropIdx = function(arr, tgt, start){
var j=0, len=arr.length;
while (j<len && arr[j].prop!=tgt) j++;
return j;
};
var i = searchPropIdx(arr,xxx,start);

これでも何してるかは関数名が教えてくれるから宣言的といえるのではないでしょうか

2017/05/13(土) 23:56:59.84

>>166
> 分かりやすいし

だからコードの話をしている時に
自分の話をするなって

2017/05/13(土) 23:59:09.17

>>168
自分で関数作るぐらいならlodashの方がいいな。
いきなりsearchPropIdxとか書かれても
コード読まないと何をしているのかわからない。

lodashのような有名ライブラリであれば
有名なライブラリを知っているならば使い方わかるし
たとえ知らなくても、誰かが解説してくれてれる

2017/05/14(日) 00:02:48.77

>>170
lodashが使える環境ならもちろん使う
ただまぁ標準ライブラリではないから今回のケースでは考えませんでした

2017/05/14(日) 00:09:32.47

>>168
まあ、俺も必要な場合はそのように関数化してくくり出すけどね。

メリットは抽象度が上げられて依存関係を切れる（隠蔽出来る）ことだが、
ここら辺は要するにオブジェクト指向のメリットであり、
そもそもオブジェクト指向は巨大なコードを何とかする手法だから、
ここでlodashを布教している奴が理解することはないというのは、
これまでさんざん見てきたとおり。

俺はlodashが使える環境でも使わないね。whileで書く。
ただここら辺は各人が好きなようにすればいいだけの話だね。