私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.141 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>650
さんくす！ちょっとやってみる！
さんくす！ちょっとやってみる！
質問者が自分にとって自明で、回答者にとって自明でない、本来質問に必須のコンテキストを削ぎ落としてしまいがちなバイアスのことなんて言うんだっけ？
アンカー要素をクリックするとスムーススクロールをする場合に
スムーススクロールをするメソッドには手を加えずに、一部のアンカー要素では
スクロールさせないといったようなインターセプト的な技法はありますか。
スムーススクロールをするメソッドには手を加えずに、一部のアンカー要素では
スクロールさせないといったようなインターセプト的な技法はありますか。
>>654
イベントリスナは剥がせるよ
イベントリスナは剥がせるよ
>>655
早速どうも
剥がすというのはremove.eventListenerのことでしょうか。
そうであれば剥がすためにスムーススクロール側のスクリプトに手を加える方法しか
私では思いつきませんので、やり方をお教えいただけませんか。
早速どうも
剥がすというのはremove.eventListenerのことでしょうか。
そうであれば剥がすためにスムーススクロール側のスクリプトに手を加える方法しか
私では思いつきませんので、やり方をお教えいただけませんか。
>>656
スムーススクロールをどうやってるのか知らんが、
セレクタを変えるだけだろう？
$('A').smoothScroll() から
$('.target').smoothScroll() に変更するだけ
スムーススクロールをどうやってるのか知らんが、
セレクタを変えるだけだろう？
$('A').smoothScroll() から
$('.target').smoothScroll() に変更するだけ
capture:true
stopImmediatePropagation
stopImmediatePropagation
私の状況を助けていただけませんでしょうか。
職場にキオスク端末に今までブラウザのキオスクモードで
Flashコンテンツを表示させていたのを、
JSとHTMLで刷新することになりました。
端末は旧新混在しており大きく分けて感圧式と静電容量式があります・
Flashを使っていたときは気にすることはなかったのですが、
ボタンなどをDOMで構築するとかなり押し心地が異なります。
おそらく感度や制度、画面の厚みからくるものだと思います。
（Flashコンテンツではなぜかある程度調整が効いているようです）
そこで端末がどちらに含むのかを認識して調整をかけたいと思い奮闘したのですが
UAなどJSから簡単に取得できる情報は際がありません。
あとはmatchMediaくらいかなと思っているのですが、
このAPIの掘り下げ方が分からず行き詰まっております。
助けていただけませんでしょうか？
職場にキオスク端末に今までブラウザのキオスクモードで
Flashコンテンツを表示させていたのを、
JSとHTMLで刷新することになりました。
端末は旧新混在しており大きく分けて感圧式と静電容量式があります・
Flashを使っていたときは気にすることはなかったのですが、
ボタンなどをDOMで構築するとかなり押し心地が異なります。
おそらく感度や制度、画面の厚みからくるものだと思います。
（Flashコンテンツではなぜかある程度調整が効いているようです）
そこで端末がどちらに含むのかを認識して調整をかけたいと思い奮闘したのですが
UAなどJSから簡単に取得できる情報は際がありません。
あとはmatchMediaくらいかなと思っているのですが、
このAPIの掘り下げ方が分からず行き詰まっております。
助けていただけませんでしょうか？
すみません。徹夜続きで寝ぼけていたのもあり誤字があまりに多いです。
失礼しました。
失礼しました。
ajaxを使い動的に生成した要素の親要素を基準として.childrenで動的要素を取得すると
漏れてしまう要素があります。
動的要素ってそういうもんですか？
漏れてしまう要素があります。
動的要素ってそういうもんですか？
>>662
面白そうな仕事で裏山
質問に質問で返すようで悪いんだけど、そもそもHTMLで作る際に調整なんてあるの？
touch系のイベントを使ってなくて、clickしか設定してないとか、そういう基本的なことではなくて？
面白そうな仕事で裏山
質問に質問で返すようで悪いんだけど、そもそもHTMLで作る際に調整なんてあるの？
touch系のイベントを使ってなくて、clickしか設定してないとか、そういう基本的なことではなくて？
APIでjsonデータを取るようになってから、クラウドDB使用時のfirefoxの
アドレスバーの左端に「以下のサイトが、あなたがこのサイトにいる間、
クロスサイト cookieとサイトデータにアクセスできます。」
って表示されてるんですがこれ危ないやつですの…？
アドレスバーの左端に「以下のサイトが、あなたがこのサイトにいる間、
クロスサイト cookieとサイトデータにアクセスできます。」
って表示されてるんですがこれ危ないやつですの…？
>>660
おぉ！！！
ありがとうございます。
まさにインターセプト的な割り込みです。
capture: true って親子関係にある要素の同イベントの例ばっかりで、
今のところ使いどころないなと思っていたのですがこんな使い方があるなんて。
おぉ！！！
ありがとうございます。
まさにインターセプト的な割り込みです。
capture: true って親子関係にある要素の同イベントの例ばっかりで、
今のところ使いどころないなと思っていたのですがこんな使い方があるなんて。
Arrayにわんさかメソッドが入る案がES4時代から合ったが
少し入っただけで今は鳴りを潜めてる
近い未来で機能が増える予定はない
一方集合関係のメソッドがSetに追加されることはほぼ確実
その他に[1,2,3]==[1,2,3]の性質を持ったTuple型が入る予定なので
今後はArrayではなくそれらに期待すべき
少し入っただけで今は鳴りを潜めてる
近い未来で機能が増える予定はない
一方集合関係のメソッドがSetに追加されることはほぼ確実
その他に[1,2,3]==[1,2,3]の性質を持ったTuple型が入る予定なので
今後はArrayではなくそれらに期待すべき
7 * 12くらいの処理だし平気かな…
O記法とか知らなかったし学びになった 感謝
O記法とか知らなかったし学びになった 感謝
ちょっと手を入れればN^2にはならんと思う
チェック先の3,4,... で「最初に」ヒットしたインデックスが必要なら、チェック元1,2,...の順序は関係ない
だからチェック元はソート
あとはチェック先の要素を回して二分探索
チェック先の3,4,... で「最初に」ヒットしたインデックスが必要なら、チェック元1,2,...の順序は関係ない
だからチェック元はソート
あとはチェック先の要素を回して二分探索
配列が大きくなったらチェック元はSetに突っ込んじゃうのが楽だと思う
計算量が多くてアカンと考えるのが間違ってる
計算量が多い計算をするためにコンピュータはあるんでしょ
計算量が多い計算をするためにコンピュータはあるんでしょ
データ量が多ければ・・・
O(1) > O(log n) >> O(n) >> (超えられない壁) > O(n^2)
みたいになるんだから計算量を減らす事は考えなきゃダメでしょ
前の人らが言ってる少ない配列なら大差ないけれども
O(1) > O(log n) >> O(n) >> (超えられない壁) > O(n^2)
みたいになるんだから計算量を減らす事は考えなきゃダメでしょ
前の人らが言ってる少ない配列なら大差ないけれども
計算量はcomplexityの訳語
アルゴリズムの計算量(complexity)とは
そのアルゴリズムを実行するのにどのくらいのリソース(主に時間と空間)が必要になるかを示すもの
ビッグO記法はアルゴリズムの計算量の表現形式
アルゴリズムの計算量(complexity)とは
そのアルゴリズムを実行するのにどのくらいのリソース(主に時間と空間)が必要になるかを示すもの
ビッグO記法はアルゴリズムの計算量の表現形式
漏れらは、n^2 を見たら、
反射的に、n log n にならないか、考える
反射的に、n log n にならないか、考える
Google などのプログラミング・コンテストなどは、計算量の見積もりする
1秒間に数百万回ループできる。
Ruby などの動的言語では、1秒間に百万回ぐらいだけど
n log n の形とか、グラフ・動的計画法・メモ化とか
1秒間に数百万回ループできる。
Ruby などの動的言語では、1秒間に百万回ぐらいだけど
n log n の形とか、グラフ・動的計画法・メモ化とか
>>684
データ量がもう常識はずれに明らかに多ければね
でも原則最適化は実際困ってからしっかり分析して考えるべきものでしょ
それ自体が良いことと信じ込んで目的化したり、感覚でやるものじゃない
それよりもコーディング速度重視で愚直に仕上げて
最後に問題になったらそこを潰すほうに時間をかける方が
１つ１つのことに考え出すよりよっぽど建設的で効率的
プログラムっていうのは全体で動いているのであって、
君が拘ったコードが実際は１回も働かないということだって十分ありうるのだから
人にアドバイスするにしてもどこに力に入れるべきかはよく考えたほうがいい
データ量がもう常識はずれに明らかに多ければね
でも原則最適化は実際困ってからしっかり分析して考えるべきものでしょ
それ自体が良いことと信じ込んで目的化したり、感覚でやるものじゃない
それよりもコーディング速度重視で愚直に仕上げて
最後に問題になったらそこを潰すほうに時間をかける方が
１つ１つのことに考え出すよりよっぽど建設的で効率的
プログラムっていうのは全体で動いているのであって、
君が拘ったコードが実際は１回も働かないということだって十分ありうるのだから
人にアドバイスするにしてもどこに力に入れるべきかはよく考えたほうがいい
最適化するかどうかは状況次第だがアルゴリズムのオーダーは把握しておいたほうがいい
かといって競プロみたいのばっかりやるのは逆に害のほうが大きいけど
かといって競プロみたいのばっかりやるのは逆に害のほうが大きいけど
最適化はエンジンの仕事
俺らのしったこっちゃねえ
エンジンが状況を慎重に判断して
より高速で等価な演算に変えるべきだろ
人間は何をしたいか意思を示すことが仕事だ
俺らのしったこっちゃねえ
エンジンが状況を慎重に判断して
より高速で等価な演算に変えるべきだろ
人間は何をしたいか意思を示すことが仕事だ
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.141 + (1001) - [100%] - 2019/9/22 23:15
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.143 + (753) - [97%] - 2020/4/19 5:00
- + JavaScript の質問用スレッド vol.101 + (1001) - [97%] - 2012/7/16 14:15
- + JavaScript の質問用スレッド vol.140 + (1001) - [97%] - 2019/9/19 10:45
- + JavaScript の質問用スレッド vol.102 + (1001) - [95%] - 2012/9/11 17:30
- + JavaScript の質問用スレッド vol.123 + (966) - [95%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.122 + (116) - [95%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.122 + (1004) - [95%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.100 + (1001) - [95%] - 2012/6/13 22:46
トップメニューへ / →のくす牧場書庫について