私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.117 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>最近、出ている質問には全て答えられないとやってけない
んなこたない
必要なのは知識ではなく問題を解決していく力
んなこたない
必要なのは知識ではなく問題を解決していく力
だが使えるヤツかやってけるヤツかどうかと
それ以前に採用されるヤツかどうかは別問題
それ以前に採用されるヤツかどうかは別問題
非同期処理が終わらない間は次の非同期処理を始められないようにするには
どうしたらいいですか?
どうしたらいいですか?
最初の非同期処理の結果が出るのをwhileでずっと待たせておけばいんじゃね
>>158
requestAnimationFrame(かsetTimeout)で処理が終わるかどうかを定期的にポーリングする
その際には状態遷移(いわゆるステートマシンの作成)をする必要はある
世の中非同期処理にはpromiseとか言ってるが、一定間隔のポーリングが一番簡単
ゲームはみんなそうやっているが、デメリットもあるので必ず適合するわけではない
requestAnimationFrame(かsetTimeout)で処理が終わるかどうかを定期的にポーリングする
その際には状態遷移(いわゆるステートマシンの作成)をする必要はある
世の中非同期処理にはpromiseとか言ってるが、一定間隔のポーリングが一番簡単
ゲームはみんなそうやっているが、デメリットもあるので必ず適合するわけではない
>>149
String 型の汎用関数内なら変数名「string」は自然だが、「セッターメソッド→変数名string」は自然ではない
セッターメソッドは必ずしも汎用関数ではないからだ
例えば、String.prototype.trim はString型に対しての汎用関数だから変数名stringは自然だろう
同じ理屈で Boolean型の汎用関数なら変数名「boolean」は自然といえるが、true, false 以外に値のないBoolean型で汎用関数は想像し難い
それが Boolean.protype に存在するに足る関数で宣言された変数ならば、変数名「boolean」は相応しいだろう
String 型の汎用関数内なら変数名「string」は自然だが、「セッターメソッド→変数名string」は自然ではない
セッターメソッドは必ずしも汎用関数ではないからだ
例えば、String.prototype.trim はString型に対しての汎用関数だから変数名stringは自然だろう
同じ理屈で Boolean型の汎用関数なら変数名「boolean」は自然といえるが、true, false 以外に値のないBoolean型で汎用関数は想像し難い
それが Boolean.protype に存在するに足る関数で宣言された変数ならば、変数名「boolean」は相応しいだろう
>>165
> 世の中非同期処理にはpromiseとか言ってるが、一定間隔のポーリングが一番簡単
> ゲームはみんなそうやっているが、デメリットもあるので必ず適合するわけではない
ポーリングは効率が悪い。チェックする間隔を短くすれば負荷が高まるし、
間隔を長くすれば、遅延が起きる。
そこで効率よくしようという発想で改善されたのが非同期処理。
promiseはその非同期処理を簡単に書けるようにしたもの。
ポーリングがダメというのを出発点として、それに代わるいい方法をってことで
できたものなんだから、今更ポーリングにするのは時代を逆行してるよ。
ゲームではそうやっているというが、ゲームだけが例外。
ゲームは画面更新間隔(フレーム)というものが存在し、この1フレームは1秒間に
30回だったり60回だったりするんだが、1フレーム内でユーザーの入力を検出する。
つまり、画面の更新間隔と入力検出が同期取られてるわけ。これにより1フレームで
入力できるのは1回だけというふうに公平なゲームとして安定した動作がさせられる。
でもこれはゲーム特有の話で、普通のアプリには参考にならない。
> 世の中非同期処理にはpromiseとか言ってるが、一定間隔のポーリングが一番簡単
> ゲームはみんなそうやっているが、デメリットもあるので必ず適合するわけではない
ポーリングは効率が悪い。チェックする間隔を短くすれば負荷が高まるし、
間隔を長くすれば、遅延が起きる。
そこで効率よくしようという発想で改善されたのが非同期処理。
promiseはその非同期処理を簡単に書けるようにしたもの。
ポーリングがダメというのを出発点として、それに代わるいい方法をってことで
できたものなんだから、今更ポーリングにするのは時代を逆行してるよ。
ゲームではそうやっているというが、ゲームだけが例外。
ゲームは画面更新間隔(フレーム)というものが存在し、この1フレームは1秒間に
30回だったり60回だったりするんだが、1フレーム内でユーザーの入力を検出する。
つまり、画面の更新間隔と入力検出が同期取られてるわけ。これにより1フレームで
入力できるのは1回だけというふうに公平なゲームとして安定した動作がさせられる。
でもこれはゲーム特有の話で、普通のアプリには参考にならない。
>>167
別にポーリングが万能とは思わないけど、どんなUIであろうと画面を1/60以上の頻度で更新する事は無理だ
(最近は240Hzのゲーミングモニターとかはあるが…)
だから、1/60秒単位でポーリングするからといってパフォーマンス的に問題がある事はない
通常の非同期処理と混ぜる事も出来るし、一つの方法論として考えてもらうだけでいいよ
別にポーリングが万能とは思わないけど、どんなUIであろうと画面を1/60以上の頻度で更新する事は無理だ
(最近は240Hzのゲーミングモニターとかはあるが…)
だから、1/60秒単位でポーリングするからといってパフォーマンス的に問題がある事はない
通常の非同期処理と混ぜる事も出来るし、一つの方法論として考えてもらうだけでいいよ
このスレには、ろくにわかっていないクセに、
外人の本やライブラリを、神の如くあがめる香具師がいる
知識なんてネット上に無限にある
あるけど皆、東大に合格できないだろ?
大事なのは知識の多さではなく、本人の吸収率や上達である。
だから、個別教育が重要。
初心者は、日本人の簡単な本で勉強したらよい
難しい外人の本を読んでも、時間のムダで、吸収率が悪い
実際に漏れは、その本を読んで上達した。
やり方さえ覚えれば、知識はネットで調べればよい
知識なんて枝葉末節だし、すぐ変化するもの
それにプログラムはデバッグしながら、間違えながら作るもの
些細な知識よりも、大まかな手順を覚えること
試行錯誤しながら進むのが、人生
外人の本やライブラリを、神の如くあがめる香具師がいる
知識なんてネット上に無限にある
あるけど皆、東大に合格できないだろ?
大事なのは知識の多さではなく、本人の吸収率や上達である。
だから、個別教育が重要。
初心者は、日本人の簡単な本で勉強したらよい
難しい外人の本を読んでも、時間のムダで、吸収率が悪い
実際に漏れは、その本を読んで上達した。
やり方さえ覚えれば、知識はネットで調べればよい
知識なんて枝葉末節だし、すぐ変化するもの
それにプログラムはデバッグしながら、間違えながら作るもの
些細な知識よりも、大まかな手順を覚えること
試行錯誤しながら進むのが、人生
外人の本は、書きなぐりみたいな雑な本が多い
文章が長いくせに、何を言っているかわからない。
図が無い。レイアウトが悪い。
カラーじゃなく、白黒だけの本
日本人の本の方が、レイアウトや構成、視認性がよく、
短時間で理解できる
またその本に何を書かないか、というのも重要。
特に重箱の隅をつつくような知識は、
載せても覚えられないし、吸収率も悪く、時間のムダ
実際に必要になった時に、調べたらすむ
資格の学校のTACみたいなのが、理にかなっている
必要最小限の知識と勉強時間で、
200時間の勉強で、ギリギリ60点で合格
文章が長いくせに、何を言っているかわからない。
図が無い。レイアウトが悪い。
カラーじゃなく、白黒だけの本
日本人の本の方が、レイアウトや構成、視認性がよく、
短時間で理解できる
またその本に何を書かないか、というのも重要。
特に重箱の隅をつつくような知識は、
載せても覚えられないし、吸収率も悪く、時間のムダ
実際に必要になった時に、調べたらすむ
資格の学校のTACみたいなのが、理にかなっている
必要最小限の知識と勉強時間で、
200時間の勉強で、ギリギリ60点で合格
そうか?
ジャップ本はマニュアルをそのまま転載したような本が多い印象
ジャップ本はマニュアルをそのまま転載したような本が多い印象
国籍関わらず、人によるわ
特定の人を持ち上げようとするのに国籍持ち出してくるのはちょっと無理がある
// 個人的にはオライリー本は好かんが
特定の人を持ち上げようとするのに国籍持ち出してくるのはちょっと無理がある
// 個人的にはオライリー本は好かんが
いくつかのボタンがあり、それを押すと処理が走ります
その処理の中にはそこそこ重いものものあります
重い処理の途中にボタンをクリックされ、更に他の処理が走り出すと
整合性がおかしくなる可能性があります
このような場合、どうやるのがセオリーでしょうか?
ボタンを押した時にキューを積んで、それを順次する処理するなどでしょうか?
その処理の中にはそこそこ重いものものあります
重い処理の途中にボタンをクリックされ、更に他の処理が走り出すと
整合性がおかしくなる可能性があります
このような場合、どうやるのがセオリーでしょうか?
ボタンを押した時にキューを積んで、それを順次する処理するなどでしょうか?
複数の行で構成された巨大なデータをajaxでサーバに送信する場合、
ブラウザが途中で落とされる可能性もあると思います
するとデータが不整合を起こすはずです
サーバ側で、データを全て受信してから書き込む、みたいな処理にしないといけないのでしょうか?
ブラウザが途中で落とされる可能性もあると思います
するとデータが不整合を起こすはずです
サーバ側で、データを全て受信してから書き込む、みたいな処理にしないといけないのでしょうか?
GoogleのDart言語がECMAの標準規格になる
http://jp.techcrunch.com/2014/07/09/20140708googles-dart-language-is-now-an-official-ecma-standard/
JavaScriptはどうなるんです?
http://jp.techcrunch.com/2014/07/09/20140708googles-dart-language-is-now-an-official-ecma-standard/
JavaScriptはどうなるんです?
>>178
明らかにサーバサイドの問題だから該当言語のスレに行くべし
明らかにサーバサイドの問題だから該当言語のスレに行くべし
ajaxはサーバサイドじゃねーから。
サーバにアクセスする部分はサーバクライアント両方の要素があるのは当然のことだ
サーバにアクセスする部分はサーバクライアント両方の要素があるのは当然のことだ
>>177
処理の間ボタンをdisabledやreturn falseにしておけば?
処理の間ボタンをdisabledやreturn falseにしておけば?
>>185
フィイル出力はサーバサイドの処理
フィイル出力はサーバサイドの処理
そもそも、TCP/IPはエラー補正機能が付いているけど、どういう原理でデータ損失が起きる事を想定してるの?
サーバ側からすればAjaxだろうが、form送信だろうが変わらないけど、Ajax特有の問題がどうやって発生するの?
サーバ側からすればAjaxだろうが、form送信だろうが変わらないけど、Ajax特有の問題がどうやって発生するの?
>>178
その辺はWebサーバがうまいことやってくれんかね
その辺はWebサーバがうまいことやってくれんかね
複数のオブジェクトのデータを送る時、
何も考えずにループで送り、サーバ側も順次それをサーバに書き込んでいくと
クライアントサイドのロジックにデータの保全性が依存してしまう
それを避けるためにどうしてるかという問題
TCP/IPの話なんぞしてない
ど素人は寝とけ
何も考えずにループで送り、サーバ側も順次それをサーバに書き込んでいくと
クライアントサイドのロジックにデータの保全性が依存してしまう
それを避けるためにどうしてるかという問題
TCP/IPの話なんぞしてない
ど素人は寝とけ
どこから、「複数のオブジェクトのデータを送る」って話になったんだ?
一つの巨大なデータの話だろ。
一つの巨大なデータの話だろ。
ブラウザが途中で落とされた時とかいう話をしてるけどさ、
これってネットワークが途中で切れたりした時にも当てはまるんだよ。
だからAjaxの話とか関係なく、いままではどうしていたの?って話。
一般的なシステムの場合、データが全て届いてから処理が開始される。
もしストリーミングで受信するタイプの場合、
つまり、データが全て届かなくても処理するタイプの場合ね。
そういうものは、トランザクション処理でも仕込んでおいて、
データが完了しなければ、処理をなかったことにすればいい。
これってネットワークが途中で切れたりした時にも当てはまるんだよ。
だからAjaxの話とか関係なく、いままではどうしていたの?って話。
一般的なシステムの場合、データが全て届いてから処理が開始される。
もしストリーミングで受信するタイプの場合、
つまり、データが全て届かなくても処理するタイプの場合ね。
そういうものは、トランザクション処理でも仕込んでおいて、
データが完了しなければ、処理をなかったことにすればいい。
分かり切った一般論を抜かし出す奴なんなんだよ
具体的にどうしてるのかって話
書いたことないなら黙っとけ
具体的にどうしてるのかって話
書いたことないなら黙っとけ
>>193
お前のレスになんか意味があるのか?
分かりきった話なのに、其の質問をしているんだから、
そいつには、わかってないんだろう?
その答えが、分かりきったものになるのは当たり前の話だ。
なぜ分かりきった一般論を書いてはダメなのだ?
お前のレスになんか意味があるのか?
分かりきった話なのに、其の質問をしているんだから、
そいつには、わかってないんだろう?
その答えが、分かりきったものになるのは当たり前の話だ。
なぜ分かりきった一般論を書いてはダメなのだ?
>>196
あるから、黙る必要はないなw
あるから、黙る必要はないなw
複数行のデータとかループして送るとか言ってるから、
行単位でPOSTするつもりなんだろwwwwwwww
行単位でPOSTするつもりなんだろwwwwwwww
> 177 名前:Name_Not_Found[sage] 投稿日:2014/07/09(水) 09:48:20.58 ID:???
> 複数の行で構成された巨大なデータをajaxでサーバに送信する場合、
元々の質問者はループなんて言ってないな。
ループって言い出したのはこいつか
> 189 名前:Name_Not_Found[sage] 投稿日:2014/07/09(水) 21:56:15.09 ID:???
> 複数のオブジェクトのデータを送る時、
> 何も考えずにループで送り、サーバ側も順次それをサーバに書き込んでいくと
まったく、なんで複数のオブジェクトとかいう話を
しだいているんだろうこいつ。馬鹿じゃんw
> 複数の行で構成された巨大なデータをajaxでサーバに送信する場合、
元々の質問者はループなんて言ってないな。
ループって言い出したのはこいつか
> 189 名前:Name_Not_Found[sage] 投稿日:2014/07/09(水) 21:56:15.09 ID:???
> 複数のオブジェクトのデータを送る時、
> 何も考えずにループで送り、サーバ側も順次それをサーバに書き込んでいくと
まったく、なんで複数のオブジェクトとかいう話を
しだいているんだろうこいつ。馬鹿じゃんw
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.110 + (1001) - [97%] - 2013/10/13 14:01
- + JavaScript の質問用スレッド vol.119 + (1002) - [97%] - 2014/10/3 15:30
- + 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.114 + (1001) - [97%] - 2014/5/3 10:45
- + JavaScript の質問用スレッド vol.127 + (160) - [97%] - 2021/7/16 9:30
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.127 + (1001) - [97%] - 2016/2/4 0:15
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.107 + (1001) - [97%] - 2013/9/7 10:16
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.126 + (952) - [95%] - 2015/11/18 13:15
- + JavaScript の質問用スレッド vol.126 + (348) - [95%] - 2023/1/12 17:00
トップメニューへ / →のくす牧場書庫について