元スレ+ JavaScript の質問用スレッド vol.114 +
JavaScript覧 / PC版 /みんなの評価 :
401 = :
あるブログのコードを引用してここで質問したら
そのブログは転載とみなされて訴えられちゃうケース
402 = :
そんなケースあってたまるか
403 = :
>>395
誰がどういう理由で訴えるのかを書かないのはなぜですか?
404 = :
>>403
http://toro.2ch.net/test/read.cgi/hp/9246666279/
405 = :
>>404
意味がわかりませんね
2chに書き込むことがボランティアと認められて西村博之から訴えられるといいたいのですか?
自分の言葉で主張してください
406 = :
これ以上主張することってあるんですか
407 = :
>>404はRaceqeen incが西村博之を訴えるという話でしょ
利用者に同影響するというのか?
408 = :
>>406
誰がどういう理由で訴えるのかを書かないのはなぜですか?
409 = :
文字列が書かれたdivがあり、そのdivの中のどこかがクリックされた時
何列目の何行目をクリックされたか知るには
どうすればいいと思いますか?
410 = :
>>409
等幅フォントを指定し、マウス座標から該当文字位置を算出する
411 = :
div内の文字列の1文字づつをspanで囲む
412 = :
>>411
それだけだと行数を計測できないのでは?
413 = :
>>411ではないが、div要素内の先頭文字から座標を取得して行き、y座標から何行目かを計測、何文字目かは行数が変わった時からカウント
毎回、計算させるのは無駄だから始めの描画が終ったときに計算しておいてspan要素でマークアップしておく、というところだろうが、描画後にウインドウの大きさを変える事も踏まえるとonresizeも監視する必要がある
座標で計算する部分は>>410と同じだな
414 = :
「先頭文字から座標を取得して行き」というけど
spanで区切らないと一列目以降の座標は取得できないのでは?
415 = :
>>414
確かに…
spanで括らないなら等幅フォントを使うしかないな
416 = :
3行以内の質問は回答があっても大抵無反応だな
熱意ある回答者がいなくなるのもわかる気がする
417 = :
>>409
CaretPosition インタフェース(CSSOM)を使うか
上手くいくかどうか判らんし CaretPosition が未サポートかもしれないが
mousedown イベントの時点で contentEditable にしてから
click の時点で caret 位置を取得してごにょごにょ
419 = :
>>416
全然減ってないが?
むしろ変な回答してそれを指摘すると発狂する馬鹿回答者がいなくなったと思う
熱意ある回答者ってそういうやつのことか?
420 = :
「今押されたキーのキーコード」 ではなく
「すでに押されてるキーのキーコード」 を
知る方法を知りたい。
421 = :
「すでに押されてる」って?
今押されたのを覚えとけばイイとかって話じゃなく?
424 = :
回答ありがとうございます
CaretPositionインタフェイスっていうのあるのですね
たしかにこのあたりの操作のしにくさは異常だと思っていました
ただまだ普及していないようなので
span区切りで座標データ化してポジショニングしようと思います
ありがとうございました
425 = :
>>409 自分が過去にやった方法だと
まずdivを複製する、そのときにそのdivに間接的にかかってるスタイルを属性で直接指定する
次にouterHTMLをforeignObjectでくるんだSVGを作る
この時に最終文字の次スペースにマーカーに当たる要素置いて相対位置("左下")を取得しておく
そしてDataURLなんかでCanvasに貼り付ける
ここまでが基本の1操作
この基本の1操作を、div内の文字数を0からlengthまで変えながら試す↓
クリックされた相対位置がマーカー位置より前("左下"より左上)に初めてなった時の文字列の最終文字がクリックされた文字
もしくは極稀に起こるマーカーのみの改行に対処したり、0→lengthでないアルゴリズムにしたいときは、
クリックされた相対位置がマーカー位置より前("左下"より左上、または"左上"より上)になる最短の文字列の最終文字がクリックされた文字
画像が入ってたりするときは、ちょっとややこしい
一応SVGの画像もオリジンが継承されるようになってきたけど、
ブラウザやバージョンによってはオリジンエラーになることがある
そういう場合は画像をrectでもなんでもいいけど置き換える
いっそChromeが対応してるRTCでのスクリーンキャプチャで画像解析してもいいかもしれない
特色のマーカーを配置しておけばImageDataの解析は難しくないはず
426 = :
なんか犯罪のにおいを感じるのは俺だけ?
427 = :
お前だけ
428 = :
SVGもキャンバスも使ったことないのでちょっと分からないですが
色んなやり方があるんですね
いつか使ってみたいと思います
ありがとうございました
429 = :
try/catchについて質問です
これまでは聞き齧った知識で漠然と
「tryブロック内の処理は遅くなる」
と思っていたのですが、実際は
「条件分岐として使うにはエラーキャッチ時の速度に難がある」
程度だという認識で正しいのでしょうか
430 = :
計測もしないで、速度を気にするやつは馬鹿である。
0.001秒のために、何時間も頑張る奴は仕事の優先順位がつけられない。
という認識でいいよw
431 = :
>>429
速度とかごちゃごちゃいってないで、
勉強しろ。
432 = :
他のやり方では出来ない時にしか使わなければ問題ないんじゃないの
433 = :
速度に難があると言ってる時点でなぁー
技術ってのは適切な場所に使うもので
速度のこと何って考えるのは最後の最後。
try/catchはtry/catchを使うべき所に使うもの。
速度に難とかを考える事自体が間違っている。
まあ多分、どういう所に使うかが
わかってないんだろうねー。勉強しろ。
434 = :
A級以上のプログラマは速度のことも常に気にしているもの
速度を気にするなとかいうのはB級のたわごと
435 = :
だから、速度のことを気にするのは、最後って言ってるだろ
頭悪いのか? 目が悪いのか? 顔が悪いのか? 全部か。
436 = :
処理ごとのコストは知らないより知っていた方がいいに決まってるのに
速度否定厨は知ること自体を否定するからな。
「些細なチューンのために何時間もかけるのは愚か」などと
勝手に前提を付け加えてそれを否定するのは馬鹿に共通する特徴。
自分で作った藁人形を突き刺してるにすぎないのだ。
437 = :
>>436
計測しましたか?
普段数回しか実行しないのに、何万回、何十万回やって
やっと違いが分かる程度じゃ意味無いですよ。
ちゃんと計測してからいいましょうね。
438 = :
俺は質問者じゃねーから。
それに質問に計測は必須ではない。
答えたくなければスルーすればいい。
書かれてもいない条件を勝手に付加して否定するお前が馬鹿ということだけが真。
439 = :
>>438
質問者じゃないのになんでレスしたんですか?
私は、レスした人(つまりあなた)に、レスしただけで
別に質問者にレスしたんじゃありませんよ
計測しないで速度云々言い出す奴は初心者。
そのことに何も違いはありませんが。
440 = :
まーた「質問者じゃないとレスしてはいけない」
という謎の前提を付け加えて否定してる
質問には実行される頻度などについての条件は何も書かれていないのに
「数回しか実行しない」などという前提を付け加えるのと同様の愚を犯している。
問題の切り分け能力が低いんだよ
言葉の使い方だけで技術者としてのレベルの低さが分かる
441 = :
>>440
へ? だから俺もお前にレスしてるんだけど?
誰にレスしようが自由だろ。
try-catchは例外なんだから
実行される回数は少ないに決まってるだろ
それともお前が「多いって決めつける」のか?
お前実践経験ないんじゃね?
答えられる奴が実行回数答えろよ。
答えない限り、少ないという一般的な前提を当てはめるだけのこと。
あと、これは質問者にレスしてるんで、
お前はレスしなくていいよw
442 = :
速度についてはアルゴリズムがO(n^2)になってないかを気にしていればいい
例えば、n個入力がある時に1個追加する度に全データを線形にサーチしちゃったり
しないように気を付ける
それがA級プログラマ
それ以外のどうでもいい高速化は考えるだけ無駄
直感的に分かりやすいように書けばいい
そんで最後にプロファイラで計測して遅くなってるところだけ直す
443 = :
>>432-433に同意。
try-catchは使わなければ対応出来ない状況で使うべきで速度を考えるのはtry-catchを使わなければならないにも関わらず、十分なパフォーマンスを得られない場合。
実際、try-catchを使わなければならない状況はそれ程多くないはず。
それでも重くなるなら結果をキャッシュしておくとか、アルゴリズムを見直した方がいい。
444 = :
聞かれた質問に対してのみ答えればよろしい
その他のチューン云々の分かりきったグダ話はいらない
質問者の立場の時、この種のわかりきった説教ほどウザいものはない
そんなこと聞いてねえっつーの
445 = :
あまりにも理解が表層的だからつっこまれてるの分からないの?
だからバカだのチョンだの言われるんだよw
446 = :
やっぱりネトウヨかw
相手の言葉に勝手に条件を付加して
自分の作りあげた藁人形を攻撃する論法がネトウヨくせーと思ってたわ
447 = :
バカは思考回路がショートしてるから人にレッテル貼って安心するんだよね
便利な言葉だよねネトウヨってwww
448 = :
技術者に問われるのはいかに現実と向き合うかなので
現実逃避に酔いしれるネトウヨは致命的。
ネトウヨ的思考習慣は技術者としての精度を著しく下げてしまう
A級以上になりたければネトウヨを卒業することだな
449 = :
思考が停止した奴に限って速度速度言うんだよ、計測しやすいからね
本来速度を改善することで得られるものは何なのかを明確にしなければただのオナニーなのに
だから技術者に求められるのは現実と向き合うなんて頭の悪いことを堂々と言えちゃうんだよね
450 = :
バカは自分がバカであることを自覚できないからバカなんだよね
類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.118 + (1002) - [97%] - 2014/8/29 22:30
- + JavaScript の質問用スレッド vol.116 + (1002) - [97%] - 2014/7/1 0:45
- + JavaScript の質問用スレッド vol.115 + (1001) - [97%] - 2014/5/29 16:16
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.119 + (1002) - [97%] - 2014/10/3 15:30
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.110 + (1001) - [97%] - 2013/10/13 14:01
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.117 + (1009) - [97%] - 2014/8/5 3:30
- + JavaScript の質問用スレッド vol.104 + (1001) - [97%] - 2013/1/28 4:00
- + JavaScript の質問用スレッド vol.124 + (1001) - [97%] - 2015/7/16 1:30
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.120 + (1002) - [95%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.122 + (1004) - [95%] - 2015/2/14 4:45
トップメニューへ / →のくす牧場書庫について