私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.132 +

みんなの評価 :
レスフィルター : (試験中)
>>350
それはできればしたくないだろう
ES2015のときの話だが
だからまだましな解決策としてSymbol.unscopablesが導入されたが
それだけでは十分では無かった
だからもうimport "std:Array-Ex"みたいにやってくほうがベターかね
という雰囲気になって、しばらくそれ系の提案は勢いを潜めてるってことだ
物事はもっと複雑で、Web APIが返す配列がArrayを継承してくれる目処も経ってなかった頃だったしな
とりあえず、それ以上議論を攻めるような感じにはならなかったということ
それはできればしたくないだろう
ES2015のときの話だが
だからまだましな解決策としてSymbol.unscopablesが導入されたが
それだけでは十分では無かった
だからもうimport "std:Array-Ex"みたいにやってくほうがベターかね
という雰囲気になって、しばらくそれ系の提案は勢いを潜めてるってことだ
物事はもっと複雑で、Web APIが返す配列がArrayを継承してくれる目処も経ってなかった頃だったしな
とりあえず、それ以上議論を攻めるような感じにはならなかったということ
なら、Array拡張するモジュールを標準化すれば良いのでは?
デフォルトではArrayはそのまま、標準化された
ArrayExをimportすれば拡張される
まあいいや、
どちらにしろ
> 本当に良い機能でいっぱいなら仕様に取り込まれてそう
という意見は間違いで、良い機能でいっぱいであっても
仕様に取り込まれないことはよくある話ってことだよ
デフォルトではArrayはそのまま、標準化された
ArrayExをimportすれば拡張される
まあいいや、
どちらにしろ
> 本当に良い機能でいっぱいなら仕様に取り込まれてそう
という意見は間違いで、良い機能でいっぱいであっても
仕様に取り込まれないことはよくある話ってことだよ
? 単に良いものなら取り入れられるっていうのは
考えが甘いって話をしてるだけだよ。
良くても取り入れられないものはたくさんあるのが現実
考えが甘いって話をしてるだけだよ。
良くても取り入れられないものはたくさんあるのが現実
>>354
標準化すれば良いのでは?って……
今まで説明した話を聞いていなかったのか?
標準モジュールの話が本腰入れてできるようになったのは、
ES2015後切り離して議論していたモジュールの構文以外の部分がようやくまとまって実装されだした今だし、
valuesもONにしたりOFFにしたり様子を見てたが、ONにしていって大丈夫だろうという判断が出た今からが
配列のメソッドに手を入れていくムードになり得るということだよ、物事には流れや雰囲気っていうのがあるんだからね
でも今はもう個別のメソッドが提案されてるし、やっぱりまとめてどっさりではなく1個1個入れていく形になるかもねってこと
それはそれで、そっちのほうが良いだろうよ
とりあえずRubyか何かを真似してどっさり持ってくるよりもさ
それでね、一番言いたかったのは、「お前が提案してこいよ!!いやしてください」ってことなんだけど
伝わらなかった?
標準化すれば良いのでは?って……
今まで説明した話を聞いていなかったのか?
標準モジュールの話が本腰入れてできるようになったのは、
ES2015後切り離して議論していたモジュールの構文以外の部分がようやくまとまって実装されだした今だし、
valuesもONにしたりOFFにしたり様子を見てたが、ONにしていって大丈夫だろうという判断が出た今からが
配列のメソッドに手を入れていくムードになり得るということだよ、物事には流れや雰囲気っていうのがあるんだからね
でも今はもう個別のメソッドが提案されてるし、やっぱりまとめてどっさりではなく1個1個入れていく形になるかもねってこと
それはそれで、そっちのほうが良いだろうよ
とりあえずRubyか何かを真似してどっさり持ってくるよりもさ
それでね、一番言いたかったのは、「お前が提案してこいよ!!いやしてください」ってことなんだけど
伝わらなかった?
伝わらなかった?って俺がいつ標準化しろって言ったんだ?
標準化する方法はあるって話をしただけ
俺は良いものであっても標準化されるとは限らないって話をしてる
標準化する方法はあるって話をしただけ
俺は良いものであっても標準化されるとは限らないって話をしてる
>>358
俺は良いものであっても標準化されるとは限らないと言わずに
標準化されるように提案しようと言ってる
なぜなら「本当に良いもの」なんて個人次第だから
それを提案して皆に認められて仕様に入って実装されて初めて「本当に良いもの」と言えるんだよ
それには時期とタイミングっていうのがある
Rubyに入ってる「本当に良いもの」だから、今JSに入れても「本当に良いもの」になるというわけではない
JSが大きく関わっているWebの他の物や開発者、実装などの準備やタイミングもあるんだよ
だから、もし今その「本当に良いもの」が「本当に良いもの」になれると思うのなら提案すればいい
それぞれの言語の事情を踏まえないと他の言語を引き合いに出しても仕方がない
俺は、「本当に良いもの」はきちんと然るべきときに導入されてきてると思うよ
俺は良いものであっても標準化されるとは限らないと言わずに
標準化されるように提案しようと言ってる
なぜなら「本当に良いもの」なんて個人次第だから
それを提案して皆に認められて仕様に入って実装されて初めて「本当に良いもの」と言えるんだよ
それには時期とタイミングっていうのがある
Rubyに入ってる「本当に良いもの」だから、今JSに入れても「本当に良いもの」になるというわけではない
JSが大きく関わっているWebの他の物や開発者、実装などの準備やタイミングもあるんだよ
だから、もし今その「本当に良いもの」が「本当に良いもの」になれると思うのなら提案すればいい
それぞれの言語の事情を踏まえないと他の言語を引き合いに出しても仕方がない
俺は、「本当に良いもの」はきちんと然るべきときに導入されてきてると思うよ
若いなら色々手を出したほうがいい
でも年取ってものいうのは専門性だから
すこしずつ絞っていくようにすればいい
どれを選ぶかは仕事でなにをやるかとかそういうもので決まっていくことが多い
プログラム以外の強い分野もも1つくらいつくようにするとなおよし
でも年取ってものいうのは専門性だから
すこしずつ絞っていくようにすればいい
どれを選ぶかは仕事でなにをやるかとかそういうもので決まっていくことが多い
プログラム以外の強い分野もも1つくらいつくようにするとなおよし
素人の行き方には、根拠が無い。
C#が目標でも、C#からは行けない。そういう道がない。
Java から行かないと無理だろ
JavaScript(JS), Python にも、直接行く道がない。
素人は、行けると思うけど、漏れら、10言語以上知っていると、無理だとわかる
「たのしいRuby 第5版、2016」
これを読んで無理なら、それ以上進めない
JSなどは、オブジェクト指向・クラスじゃないだろ。
いきなりプロトタイプだから、JSの内部の実装を学んだ所で、何もならないし時間の無駄。
ビジネスロジックとは無関係
Rubyで、Sinatra を、full scratch で書く方が速い。
それがRails を作る事と同じ
「Node.js超入門、掌田津耶乃、2017」
この本を読めばわかるが、
Node.jsを、full scratch で書くと、Sinatra と同じ。
Node.js + Express + Bookshelf が、Rails と同じ
「10日でおぼえる jQuery 入門教室 第2版、山田祥寛(よしひろ)、2013」
この本が、RubyのNokogiri と同じ
最初から、JSで苦しむより、Rubyでフレームワークを学んでから、
Node.jsへ行った方が、ずっと速い
C#が目標でも、C#からは行けない。そういう道がない。
Java から行かないと無理だろ
JavaScript(JS), Python にも、直接行く道がない。
素人は、行けると思うけど、漏れら、10言語以上知っていると、無理だとわかる
「たのしいRuby 第5版、2016」
これを読んで無理なら、それ以上進めない
JSなどは、オブジェクト指向・クラスじゃないだろ。
いきなりプロトタイプだから、JSの内部の実装を学んだ所で、何もならないし時間の無駄。
ビジネスロジックとは無関係
Rubyで、Sinatra を、full scratch で書く方が速い。
それがRails を作る事と同じ
「Node.js超入門、掌田津耶乃、2017」
この本を読めばわかるが、
Node.jsを、full scratch で書くと、Sinatra と同じ。
Node.js + Express + Bookshelf が、Rails と同じ
「10日でおぼえる jQuery 入門教室 第2版、山田祥寛(よしひろ)、2013」
この本が、RubyのNokogiri と同じ
最初から、JSで苦しむより、Rubyでフレームワークを学んでから、
Node.jsへ行った方が、ずっと速い
今ではマルチパラダイムが主流だし
古典的なクラスに完全に縛られてるクラスベース言語も無くなってきてるんだから
プロトタイプベースのJSで、クラスとはオブジェクト指向に於ける抽象化プログラミングの一種だと
認識していたほうが、他の言語に言っても理解が早い
古典的なクラスに完全に縛られてるクラスベース言語も無くなってきてるんだから
プロトタイプベースのJSで、クラスとはオブジェクト指向に於ける抽象化プログラミングの一種だと
認識していたほうが、他の言語に言っても理解が早い
Rubyはオブジェクト指向を突き詰めるとの本末転倒ぷりを身をもって示してくれた、クソ原理主義言語。
rails以外に存在価値なし。
rails以外に存在価値なし。
超初心者の質問をお願いします!
iOS safariで、ブラウザ閲覧中のスリープ時に何か処理を実行したいのですが
どのようにすればいいでしょうか?
visibilitychangeとhiddenでiOS以外のブラウザでは実行できるのですが。。。
よろしくお願い致します
iOS safariで、ブラウザ閲覧中のスリープ時に何か処理を実行したいのですが
どのようにすればいいでしょうか?
visibilitychangeとhiddenでiOS以外のブラウザでは実行できるのですが。。。
よろしくお願い致します
http://developer.mozilla.org/ja/docs/Web/Reference/Events/visibilitychange
これみるとIE phone以外対応してることになってるけど?
これみるとIE phone以外対応してることになってるけど?
スリープ時はタイマーも止まる可能性大だし、処理が継続できる保証もない
PCでスリープした時を考えると当たり前だと思うだろう
スリープ時になにかするという事は避けたほうが良い
PCでスリープした時を考えると当たり前だと思うだろう
スリープ時になにかするという事は避けたほうが良い
別タブなり別アプリなり開いてる間も処理し続けるとか、最初からそういうものでなきゃ「迷惑だからやめろ」って思うんだが……
ライブラリ使うとそんなこともわからない人材ができあがるのか
ソース見てないけど
ソース見てないけど
裏でこっそりマイニングさせようとしてて
スリープとか別アプリとかされた時にサーバに通知させたい動機だったりして
スリープとか別アプリとかされた時にサーバに通知させたい動機だったりして
var a=[1,{b:true},3];
var b=a.concat();
b[2]=5;
a[1].b=false;
console.log(a);//[1,{b:false},3]
console.log(b);//[1,{b:false},5]
concatでシャローコピーしたつもりなのですが
a[2],b[2]は成功
しかし、a[1],b[1]のオブジェクトはどっちもfalseになっていて
干渉していました・・・
forで繰り返して構築する以外に
完璧なシャローコピー(?)をするにはどうしたらいいですか
var b=a.concat();
b[2]=5;
a[1].b=false;
console.log(a);//[1,{b:false},3]
console.log(b);//[1,{b:false},5]
concatでシャローコピーしたつもりなのですが
a[2],b[2]は成功
しかし、a[1],b[1]のオブジェクトはどっちもfalseになっていて
干渉していました・・・
forで繰り返して構築する以外に
完璧なシャローコピー(?)をするにはどうしたらいいですか
これはだめ?
b = JSON.parse(JSON.stringify(a))
b = JSON.parse(JSON.stringify(a))
http://qiita.com/knhr__/items/d7de463bf9013d5d3dc0
ここにもいろいろのっとる
ここにもいろいろのっとる
>>381
日付型とかが壊れる
日付型とかが壊れる
JSON.parseは循環参照に対応していないので平坦化/組み立ての作業が必要
何をやりたいのか意味不明だけど、A.prototype.hoge(); しないとarrayが作られないじゃん
それとvarいらんだろ
それとvarいらんだろ
アドブロックブロックの原理ってどうなってんのあれ?
解除したいんだけど。
解除したいんだけど。
・そのサイトを使うのをやめる
・そのサイトがアドブロックブロックやってることを宣伝拡散
・そのサイトがアドブロックブロックやってることを宣伝拡散
アドブロックブロック対策のために
検出不可能なアドブロックを作りたい
検出不可能なアドブロックを作りたい
tampermonkeyで実行してるスクリプトの変数に
コンソールからアクセス出来る?
コンソールからアクセス出来る?
>>395
今は要素を消したり隠したりを表のレイヤーでやるから感知されうるが
Houdini系APIを利用してレンダリングのレベルで調整すればバレにくくなる
ただそれでも今ではどうしても痕跡が残るが
もし拡張機能からより上位のレイヤーを調整できるようにさせてもらえれば可能かも
今は要素を消したり隠したりを表のレイヤーでやるから感知されうるが
Houdini系APIを利用してレンダリングのレベルで調整すればバレにくくなる
ただそれでも今ではどうしても痕跡が残るが
もし拡張機能からより上位のレイヤーを調整できるようにさせてもらえれば可能かも
>>397
完璧を目指すと最悪ブラウザ作ることにはなるんだろうなっては思ってる
あと要素を消したり隠したりするからバレるわけだよね。
それをやらなければいい。やり方はあって(というか昔やってた)
画像の場合は透明画像にすり替える。他の形式もそれぞれダミーにすり替える。
要素は消さない。ただ見えないだけ。
これだけで結構検出は難しくなると思うよ
あとはJavaScriptによる自動操作、HTMLを書き換えると検出されそうだから
ページが読み込んでるいずれかのJavaScriptファイルを書き換えて
匿名関数の即時実行で処理させる。またwindow.openなどの関数を
オーバーライドして処理を割り込ませる
アイデアは有るけどそれを拡張機能として作るのが面倒だなw
完璧を目指すと最悪ブラウザ作ることにはなるんだろうなっては思ってる
あと要素を消したり隠したりするからバレるわけだよね。
それをやらなければいい。やり方はあって(というか昔やってた)
画像の場合は透明画像にすり替える。他の形式もそれぞれダミーにすり替える。
要素は消さない。ただ見えないだけ。
これだけで結構検出は難しくなると思うよ
あとはJavaScriptによる自動操作、HTMLを書き換えると検出されそうだから
ページが読み込んでるいずれかのJavaScriptファイルを書き換えて
匿名関数の即時実行で処理させる。またwindow.openなどの関数を
オーバーライドして処理を割り込ませる
アイデアは有るけどそれを拡張機能として作るのが面倒だなw
あと拡張機能でHTTPプロキシみたいなことできるんだろうか?
できなければプロキシ作れば良いんだけどhttps対応がめんどいな
できなければプロキシ作れば良いんだけどhttps対応がめんどいな
逆の観点で言って、プロキシでフィルター通しても
画面に本来必要不可欠な処理と統合されたら対応不可能になるんじゃない?
画面に本来必要不可欠な処理と統合されたら対応不可能になるんじゃない?



類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.122 + (1004) - [97%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.122 + (116) - [97%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.102 + (1001) - [97%] - 2012/9/11 17:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
トップメニューへ / →のくす牧場書庫について