- + JavaScript の質問用スレッド vol.118 + [転載禁止]©2ch.net
88 ：デフォルトの名無しさん[sage]：2015/05/18(月) 05:47:17.18 ID:ezOKhhiH - はい、>>86には目を合わせません
|
- 今までみた絶望的なソースコード [転載禁止]©2ch.net
116 ：デフォルトの名無しさん[sage]：2015/05/18(月) 06:12:37.96 ID:ezOKhhiH - >>114
> 飛ぶ鳥跡を濁さず
濁してるのは、飛ぶ鳥の方じゃないですからｗ
|
- 【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ49【php,py,pl,rb】 [転載禁止]©2ch.net
518 ：デフォルトの名無しさん[sage]：2015/05/18(月) 07:42:20.28 ID:ezOKhhiH - >>505
> js抜きのhtml5って何を指すの？
JavaScript以外の部分という意味なら、
HTMLの要素の定義
* 従来の要素の追加・削除・再定義等
* 新たな要素の追加 (audio要素、video要素、SVG等)
* マイクロデータ・マイクロフォーマット等
* コンテンツモデルへの変更（従来のインライン要素、ブロック要素に代わるもの）
* HTML解釈の厳格化（不正なHTMLの解釈の仕方の定義など）
CSS3
* 新たなプロパティ・セレクタ等
* ウェブフォント
* レスポンシブ（メディアクエリー）
こんな所かな？
|
- 【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ49【php,py,pl,rb】 [転載禁止]©2ch.net
520 ：デフォルトの名無しさん[sage]：2015/05/18(月) 07:56:48.47 ID:ezOKhhiH - >>517
> 仮想DOMって本当に速いの？
速いというか、遅くないっていうのが正確な意味だと思う。
仮想DOMを使う場合の前提としてDOMに変更があるたびに
すべてのDOMを書き換えるっていうのがアイデアがある。
通常のDOM APIやjQueryだと必要な場所だけ
書き換えるのに対して、全てを書き換える。
全てを書き換えると遅くなると思うだろう？
そこで出てくるのが仮想DOMという技術で、内部的には全てを
書き換えるが差分のみをDOMに反映させる。
遅いDOMへの操作は結局どちらも同じだけ必要なので
最終的な速度はそんなに変わらない。
DOMの全書き換えは遅いように見えるが、メモリ内で処理する
「速い仮想DOM」を使用することで、差分だけのDOM操作に
絞り込むことができるから遅くはならない。
という言葉の括弧だけがひとり歩きしてる。
|
- Git 12©2ch.net
464 ：デフォルトの名無しさん[sage]：2015/05/18(月) 08:12:32.67 ID:ezOKhhiH - >>462
「あまりやらないほうがいいと思う」のは前提として
「コンフリクトを起こす可能性がある」からだよね？
まず一つ。コンフリクトは起きても問題ない。直せばいいだけ
もう一つ。コミットが小さく分かれていれば、コンフリクトが起きる可能性は少なくなる。
この2点がある。
どうもコンフリクトを怖いもの。起きたら世界の破滅みたいに思っている人がいるみたいだけど
ぜんぜん違う。起きるのは当たり前のことだし、他人が作ったものならまだしも
自分が作っているものなら、どうすればいいかなんてすぐにわかる。
そしてコンフリクトが起きるのはなぜかという話。それはコードが単一責任原則を
満たしていないから簡単にいえば、修正すべきコードがあちこちに分散しており
ようするにコードが汚いから。
コンフリクトは起きたら直せばいいだけだが、
面倒くさいから、起きないほうが楽というのは確か
各コミット（そこでいう1, 2, 3, 4）がそれぞれ小さい修正になっており、
それぞれがちゃんと意味がある単位で分かれていれば、そうそうコンフリクトは起きない。
|
- Git 12©2ch.net
465 ：デフォルトの名無しさん[sage]：2015/05/18(月) 08:28:44.00 ID:ezOKhhiH - >>462の1のコミットを3のコミットに含めるか？
という質問の答は、含めるべきことであれば含める。
そうしないと逆にコンフリクトが多くなるから。
何故かと言うと、1と3をまとめたい＝意味がある単位で考えてまとめるべきこと。
単一責任の原則を満たしており、意味がある単位で小さいコミットというものは、
多くの場合同じ箇所の修正になる。「1と3は同じ箇所の修正」っていうことを覚えておいてね。
そして例えば新しくコードを書いている途中で、既存のバグが見つかったとする。
新しいコードはバグを直さなければ正しく動かない。
だから先にバグを修正するために、5というコミットが必要になったとする。
（どうでもいいが1〜4数値は新しい方を大きくしてくれｗ）
そうすると5のコミットの続きからに、1〜4をrebaseしなければならない。
その時に3でコンフリクトが発生すると3を直したあと1でもコンフリクトが起きるだろう。
なぜなら、同じ箇所を修正しているから。
さらにむずかしいのは、最終的には1が終わった形にしないといけないわけだけど
3のコンフリクトをどう解決するか？って問題がある。
3の時点で1が終わった形にするわけには行かないんだよ。
3で発生したコンフリクトを直したあとに、1の修正を行うわけだから。
どう直せばいいかわからないものが多数発生する。
これがコンフリクト怖い病になる原因だねｗ
だからコンフリクトが起きる頻度を少なくするためにも、
1. 各コミットは小さい修正にしておく
2. 意味的にまとめるべきコミットはまとめておく
これを徹底することで、最終的にコンフリクトが起きにくくなる。
|
- Git 12©2ch.net
466 ：デフォルトの名無しさん[sage]：2015/05/18(月) 09:10:31.18 ID:ezOKhhiH - 時間がかかる暗号化キーの生成待ちで暇だから書き込みｗ
コンフリクトっていうのは同じ場所の修正がかぶると
発生するっていうのを意識しておいた方がいい。
あたりまえだと思うけど、じゃあどうすればいいかまで考えているだろうか？
他人とのコンフリクトは、単純に同じ箇所を修正したときだが、
自分自身とのコンフリクト、rebaseでよく起きるね。（下手だと）
こっちもコンフリクトが起きる原因は同じ箇所の修正だからなんだ。
もし同じ箇所の修正がなければ、rebaseしてコミットの順番を
入れ替えたりしてもコンフリクトは発生しない。
じゃあ同じ箇所の修正はいつ発生するか？ それはこういうの
* Aという修正をコミットした
* Bという修正をした
* Aという修正にバグが見つかったので修正した
* Aに機能が足りなかったから追加した
* Aの変数名でタイポしていた
こういうのを放置したまま、作業し続けていざmasterにマージする段階で
コンフリクトが起きてrebaseしなきゃならないってなった場合に
多くのコンフリクトが発生して、大変なことになる。
こういうのは随時rebaseしておくことが重要。
バグとかタイポとかさっさとまとめておく。
* Aとい修正をコミットした
* Bという修正をコミットした
こういうふうコミットを意味がある単位で小さくまとめておけば、
コンフリクトの回数は減るし、直すのも単純になる。
|