>>350
それは自分でやれよ

あと、これこのまま使っても、きっともっと詳しい人に
そんなの糞！って叩かれるにキマってるからな

もうプレモル４本目突入しちゃってるからな
やってほしかったら５本目買ってこい

>>348
まさにそこが空文字なら後ろにするって部分だよ

あと、一応応用は効くよ
もし内容が日付で、""を最後にしたいのなら
そのreturnの行を
return (Date.parse(a) || 0) < (Date.parse(b) || 0)
にしたらいいよ

>>350
はい
http://ideone.com/uGgC71

>>349
まあまあだね。じゃあ勝手にレビュー。

ソート関数が汎用的になっていない。
ソート関数を実装する人がよくやりがちだけど、
引数で処理を変えるんじゃなくて関数そのものを変えた方がいい
そのほうが処理がスッキリして明確になる。

つまりrows.sort内の処理を二つにわけ、
$('button#numb').on('click',function(){ sortTable(0, numberSort); });
$('button#name').on('click',function(){ sortTable(1, stringSort); });

こうすうることで、tableと関係ない汎用的なsort関数にすることが出来る。

この0と1からわかると思うけど、var obj = {略} の所、numberでソートの時は
nameいらないわけで無駄な値を取ってきてるね。
0と1だとマジックナンバーだから定数にした方がいいかもしれないけど。

それとrowsを使っている所、mapを使った方がいい。
配列 から 同数の配列を生成したいならばmapと言えば簡単だろう？

>>346のコードで

優勝、準優勝、準準優勝
みたいに順位付けして

あと日付の24 60 3600 みたいなやり方のやつも教えてください

>>353
まあ色々やってみたかった、一つづつ処理を負いたかったってのはわかるよ。
結果として無駄なことやってるだけだけどｗ

他に人に最初に補足、これは実験的な機能を使ってるので
Chromeでオプション変えないと動きません。

まずtextsがsortされるし、関数実行中に画面描画はされないので、
deliverChangeRecordsは不要。
それ以前に関数実行中に画面描画はされないので、そもそもobserveを使う意味が無い。

recs.lengthを見ればわかるが、値の合計は15。
つまり8個しかないのに、tdへの代入が15回発生している。
だからobserveを使わずにsortし終わってから代入したほうがいいね。

あと細かいところで1/0は単純にInfinityでよい。

>>340

> return (!a || !b) ? a < b : a > b

これが見にくいのは三項演算子だからではなく
優先順位がわかりにくいからだよ。

四則演算程度の優先順位ならだれでも知って当然だが、
?と<がでてきたら、えっ？えっ？ってなっちゃう。
もしかしたらこうかも知れないしさ。

(!a || !b) ? a < b : a　　　> b

カッコでくくるだけでシンプルになる
return (!a || !b) ? (a < b) : (a > b)

もしてもう一つ、式を変更しよう。否定というのは何かとわかりにくい。
(!a || !b) この形が出てきたら有名な、ドモルガンの法則がでてくる人は珍しいのかな？

法則に従って直せば、! (a && b) となる。頭の!は三項演算子の残り二つを入れ替えれば消える。

(a && b) ? (a > b) : (a < b)

まあこれはこれで正しく動くのかよくわからんがｗ

あと列に埋め込めるやつが理想です
1列目にはこの比較関数
２列目にはこの比較関数

みたいに

>>359
そんなはずはないはずなんだが？
何か勘違いしてね？

他の言語でも同じだが、省略できる括弧は絶対に書かないのが
coolだと信じてるヘボPGの多いこと多いこと。

>>364
> cyokodogさんていうex-table-filterっていうのを作ってる凄い人に要望出しました

APIとかみたけど、ごめん、正直イケてない。

作者に言うべきことだけど、もう少し機能を細かく分けた方がいい。
機能を詰め込み過ぎでぶくぶく太ってる。

フィルタ機能とかたいていのものはjQueryで用意されてる
機能をそのまま使ったほうがいいんだ。

セレクタで出来ないような複雑なものでも、これなんか、
$(・・・).filter(フィルタ関数)なんかで行けるだろうし。
あとは表示非表示するだけ。

ようはjQueryを使いこなせ！

>>367
> 他の言語でも同じだが、省略できる括弧は絶対に書かないのが
> coolだと信じてるヘボPGの多いこと多いこと。
その通り。

確かに省略できる所を省略しても、
正しく動く。正確に判断してくれる。

だがそれは ”コンピュータが” だ。

ソースコードは人間のために読みやすいように書こう。
人間が読みにくいと思ったら、
コンピュータが読めてもそれは
人間が読むコードじゃないんだよ。

えらいのは人間様です。人間様に優しくしましょうｗ

>>369
それは技術をわかってないだけ。

ファイルサイズの話だと思うが、
確かに文字は少ない方がいいんだが
実のところほとんど意味は無い。

なぜなら普通はgzip圧縮して配信するから
その時長い単語や空白はよく圧縮できる。

1バイトでもというが、本当に
数バイトとしか変わらなかったりするよ。
画像ファイルサイズを考えてみ？

>>371
今はね、回線も太くなったしサーバも強固になったから楽なんだけど
昔から書いてる人はそうもいかなかったんだよ

ユーザから見たらたかが数バイトでも
サーバから見ると×アクセス数だから
その名残で、短く書く癖が付いちゃってる人もいるんだぜ、って話

ちくしょう、考えちまったからレスしとくかｗ

> (a && b) ? (a > b) : (a < b)

そもそもソート関数で、比較条件が逆になるってことが
おかしいことなんだよ。
ソートは常に同じ条件を使うことで正しく並ぶはず。

ただ例外はある。多分空文字だろう？
空文字では適切に並ばなかったため、「じゃあ逆にしたら並ぶんじゃね？」という
安直な発想で、条件を逆にしてしまったのだろうが、
そうではなく、空文字を例外として扱うコードを書いた方がいい。

いいというのは人間にとって読みやすいという意味。
このように書くことで、空文字はちゃんとこのように扱っていると
コード上に明確に書く事ができる。

>>372
それは最後までちゃんと計算してない。
バイト数だけで考えていて、
パーセンテージを出してないだろう。

たかだか数バイト。それが積もり積もって1GB。
大きいと思ったとしても1キロバイト中の1バイトであったら、
1000GBもの通信をしているわけ。
普段1000GBのデータ容量を使ってる所が
1GBが問題になるようなことはないよ

そんなことより人間の人件費を考えなさいと。
読みにくいコードは読むのに時間がかかる。
10秒余計にかかったら、それが積もり積もって（略

>>374
そんな難しい話じゃないんだ

伝送量があと数百MBで料金あがっちゃう！削れ！、みたいなアットホームな話
最近では問題になることないからイメージできんと思うが

ちなみに人件費については、コード読むのに余計にかかった時間分
余計に給料払ってくれる会社が沢山あれば、SE業界はブラック
とか言われることも減るんだろうなあ…

>>356

失礼だけど>>346のソースをパクらせてもらって、どんな感じか書いてみたよ
jQueryは使ってないけど

http://ideone.com/rD0vJC

>>378
うーん、
Chrome,Firefoxの安定版で完璧に動くのはあと１年
モバイルも含めるとあと２年くらいかな
ES6の一部だから正式勧告は2014年末予定だね

まあobserveは結構特殊なものだけど、
同じく>>376で使ってるi18nAPIはもっと進みも早いし、
もっと使えるも、知ってて損のないものだよ

http://d.hatena.ne.jp/teramako/20130521/p1
http://note.chiebukuro.yahoo.co.jp/detail/n181230

クレクレ厨に餌をあたえないでください

>>381
まあこれくらいならやってほしいけど
>>379
http://ideone.com/U2HT6B
とりあえずこれでオシマイ
observeに凝るの疲れた

>>380
うん、ざっくりは追っかけてるつもりでいます
仕事では古臭いことをやるケースが多いのでなかなか実践的には出来てませんが

せやな…

>>382
なんか無駄に複雑になってるなｗ
面倒なのでもうレビューしないけど1つだけ。

mapもさすがにそれだけあると
目ざわりだからこうするといいよ。

var map = function(array, func) { return [].map.call(array, func); };

まあ、実際にはunderscoreとか使えっちゅー話でもあるが。

>>385
修正した

あと読みやすいようにアロー関数にしてみた
http://ideone.com/DRbOd4

querySelectorAllってさ、イベントバインドするのに
ループ使わないといけないの？

jQueryみたいに

$('a').on('click', function() {}); （全てのa要素にclickハンドラをつける）

って簡単に書きたいんだけど？

NodeList.prototype.map を作ったんだね。

mapとして取り出すか、メソッドはやすかは
方針次第だからどっちでもいいけど、
俺は将来NodeListにmapが追加されたら・・・とか
思っちゃうからあまり好きではないね。

>>388
あくまでお遊びだから
あと暫くはES6の
array = Array.from(arrayLike)
を使ってねってなるんだと思ってる

ってことで
>>387
これでいいんじゃね
Node.prototype.on = function (evt, func) {
this.addEventListener(evt, func)
}

NodeList.prototype.on = function (evt, func) {
[].forEach.call(this, function (elm) {elm.on(evt, func)})
}

>>386
アローって誰得なの…

returnとfunctionを書かずに済むからmapなんかとの相性抜群
やはり短いほうが読みやすい

>>391
短いほうが読みやすいってのはわかるんだけどな、
その前にまず、自分のコードを読みやすくしてからにしろと。
そんな小手先の書き方の前にまずやることがあるだろと。

http://jsfiddle.net/NwA63/1/

愚痴るけどさぁ、ぶっちゃけ初期バーションで
これぐらいのコード書いて欲しいんだよね。仕事なら。

上で出てるようなコードとか書かれてもさ
レビューに時間がかかるだけで全部書き直しだもの。

このコードもソート時の値の取得に、時間がかかりそうだから
メモ化するとか改善する点はあるわけ。

そのレベルでレビューしたいんだけど、
現実は上で出てるようなコードを
時間かけて読みといて、ダメな点を教えなきゃいけない。

はぁ、ここまで育ってくれるのにどれくらいかかるのか。

>>392
講釈はありがたく受け取りますけど
数字ソート失敗してますがな…

足りんかった
Firefoxで数字ソート失敗してます
講釈は重々承知致しましたが…

五月雨で申し訳ございません
元の質問で、というか必要条件であるところの
空文字列だった場合のソートも失敗しているようでございます

お言葉は仰るとおりですので心に刻みたい所存であります

ソートのルールはlocaleCompareでしょ？
この規則は>>382丸パクリで変えてないよ。

これだけ読みやすければ、修正するのも簡単でしょ？
そのやり方でまたセンスが見えてくるんだが・・・。

コード修正するつもり無いし、
他の人のレスまとうと思ったけど
面倒になったので、アイデアだけ。

コード上でソートルールを書くのは
せっかくコードがテーブルに依存しなくなったのにもったいない。
（試してないけど、列数が増えてもコードに修正はいらないはず）

ソートのルールというのは、本質的には値の型の問題なので
colgroup要素とdata-*属性を使うかな。data-typeとか。

ワロタ
>>392先輩は会社でも同じようなことしてんだろうなｗ

>>398
そもそもなんでsortに比較関数渡せるのかっつーと
本質はそういうことだろうねえ