再現手順

case1

1. スキル登録 より
   Agnus Dei を
   難易度：マスターギター
   達成：99
   で登録
2. 1.登録後、スキル登録 より
   Agnus Deiを
   難易度：マスターベース
   達成：100
   で登録

2で登録したものが反映されない

case2

1. スキル登録 より
   0時20分のRouletteを
   難易度： ベーシックギター
   達成：100
   で登録
2. 1登録後スキル登録 より
   0時20分のRouletteを
   難易度： エクストリームギター
   達成：100
   で登録

2で登録されたものが反映される

case3

case2のデータがあることを前提とする

1. スキル閲覧画面より
   0時20分のRouletteを押下して編集画面に遷移
   難易度： エクストリームギター
   達成：10
   で編集ボタン押下しスキル閲覧画面に遷移
2. 何故か
   0時20分のRoulette
   難易度： ベーシックギター
   達成：100
   が反映される

症状の推論

更新日時ではなく同一曲タイトルの一番スキル値が高いものが表示されてしまう。

仕様にするかバグとするかは要検討？

#18 を完了させる必要あり
曲登録したタイミングでTwitterにPost

現在 table の文字サイズを，iPhone等横幅320pxの端末から見ても崩れないように小さめに設定していますが，特にPCから見た時に文字が小さすぎる，というか文字サイズは結構人によって好みがあると思うので，jQueryで文字サイズを変更できるボタンを追加しようと思っています（テーブルの横幅が広いとき偏った感じになるのも緩和できると思います）．

In The Breeze，難易度71.5とかで登録してしまい登録できなかったのエンジニアとしての怠慢感ある

外部リンクをtarget="_blank"にする。

• 自ドメインコンテンツの遷移とそうでないものを明確に分ける。
• それが一般的と認識しているユーザーも居るため、遷移先で誤ってタブを閉じるなどの誤脱落を減らす。

・問題点
スキル登録する際に以下の問題点がある

1.曲数が多く、探すのが困難
2.難易度がDr/Gt混合で洗濯が煩わしい
　→ユーザーがスキル登録するときはDr/Gtの行き来はあまりしないのでは？
3.既存登録曲を見ながらの登録が出来ない→別途バグ有
　何を登録してないか、（ユーザーが何かを見ながら登録していたとして）どこまで登録したのかが分らなくなる。
4.コメント登録が全文を見渡しにくい。

・改善案

1. 不明。曲数が多いため抜本的なUI改修をしなければいけない？
   　　致し方ない？
   2.Dr/Gtのradioボタンを設け、フロントエンド側で難易度プルダウンの中身を制御する。（show/hideでも有？）
   　→データを持つことが出来れば曲ごとのマスター譜面有無も判別できる
   　→プルダウンをjs制御するのはマスター譜面有無を対策するのであればマスト
   3.見せ方の問題なのか導線の問題なのか整理が必要。
   4.input[type=text]でなくtextareaにする

2,4が割と短い工数で実装できる気がしています。
1,3はある程度仕方が無いのでいい案浮かびませんでした。

FYIですがtextareaは style : resize:vertical を設定しておくとレイアウト崩すことなくユーザーが入力時に広げたりできるのでいい感じです

いたずら対策が必要かもしれないけどスキルの編集履歴取り続ければ成長が見れて良さそう

datatablesに食わしている重たい内容(ユーザ一覧、曲一覧)をJSONとして返すAPIを作成したい

理由1

• ユーザ一覧画面、曲一覧の表示がクライアントによっては重すぎる
• table からより JSON からのほうが速いらしい(http://blog.cybercube.co.jp/jquery%E3%81%AEdatatabels%E3%81%A7%E8%A1%A8%E7%A4%BA%E9%80%9F%E5%BA%A6%E3%82%A2%E3%83%83%E3%83%97)

理由2

• #25 で 曲名からidを検索するような機構を作りたいので

ユーザ一覧の最終更新列ですが，自分の感覚ではスキルの更新，プロフィールの更新があったときに変更されて欲しいのですが，Userモデル の updated_at カラムをそのまま使っているのでログイン時などセッション関連のカラムが更新されたときにつられて更新してしまうみたいです．

admin_user は曲の登録/編集/削除などとりあえずなんでもできるが、
曲登録作業の委託のため adminユーザを開放すると危険
そこで、曲の登録のみ行えるユーザが居るといい
editable_user 的なユーザかどうかを before_action で確認しちゃえば良い

曲登録時に空白値があったら警告する

どうせ曲リストフェッチするのにモッサリするのだから曲選択されたときに動的にラジオボタンのenabled/disabled切り替えて横に難易値表示したげるぐらい多少モッサリしてもやったほうが良さそう

あとラジオボタンの状態は保存しておいたほうが良い（うまい人がMAS以外の難易度で登録することは少ない　特にドラムはGとBの区別無いし）　さらにいうならスキル帳を編集画面に表示するついでに平均スキル値を計算してやってスキル帯に入りそうな難易度自動選択するぐらいの勢いがほしい

window resizeをかけるとテーブルのカラムが適切な長さにならず、偏りがある幅になってしまう。

col属性やtdにclass付与することによる長さの固定化が必要

Wikiからコピペするだけで良い感じにしたい

現状バリデーション等は以下のようになっている．

• 存在しない難易値は0.0で登録
• 難易値のバリデーションが存在しない
• 達成率のバリデーションは0～100
• スキル値のバリデーションは0～200（ただし0は除く)

この状態で達成率０を指定すると`スキル値がゼロの曲は登録できません，'
とバリデーションエラーが出て登録できない．
これは間違って存在しない難易度の曲を登録しないようにするための
応急処置なのだが，達成率0で登録してメモ書きのように使いたい，
という需要はあるはず．（そもそもクローン元はそういう使い方ができる）

で，長らくしょうがないことだと思っていたがおそらく以下のようにすれば，
現在登録されているデータに影響なく変更することができる．

• 存在しない難易値はマイナスの値で登録(例-999.9)
• 難易値のバリデーションはマイナス～9.99（ただし0は除く）
• 達成率のバリデーションは0～100
• SPのバリデーションは0～200 (0を含む)

• webmasterツールとの連携、各サーチエンジン登録
• description,title,その他見出しなどマークアップによるSEO対策
• sitemap.xmlの送信
• robotsの設定

など
[ギタドラ　シミュ],[GITADORA シミュ] あたりで10件以内に表示させたい。

以下のとおりです．

http://gfdmskill.blog.fc2.com/blog-entry-5.html#cm

達成率ソートが桁数を正しく認識していません
例）99.99>9.99>100.00
修正よろしくお願い致します

問題点

スキル登録する際に以下の問題点がある

1. 曲数が多く、探すのが困難
2. 難易度がDr/Gt混合で洗濯が煩わしい
   　→ユーザーがスキル登録するときはDr/Gtの行き来はあまりしないのでは？
3. 既存登録曲を見ながらの登録が出来ない→別途バグ有( #13 )
   　何を登録してないか、（ユーザーが何かを見ながら登録していたとして）どこまで登録したのかが分らなくなる。
4. コメント登録が全文を見渡しにくい。

改善案

1. 不明。曲数が多いため抜本的なUI改修をしなければいけない？
   　致し方ない？
2. Dr/Gtのradioボタンを設け、フロントエンド側で難易度プルダウンの中身を制御する。（show/hideでも有？）
   →データを持つことが出来れば曲ごとのマスター譜面有無も判別できる
   →プルダウンをjs制御するのはマスター譜面有無を対策するのであればマスト
3. 見せ方の問題なのか導線の問題なのか整理が必要。
4. input[type=text]でなくtextareaにする

2,4が割と短い工数で実装できる気がしています。
1,3はある程度仕方が無いのでいい案浮かびませんでした。

FYI

textareaは style : resize:vertical を設定しておくとレイアウト崩すことなくユーザーが入力時に広げたりできるのでいい感じです

匿名でのタレコミが簡単，という理由でFC2ブログを利用していたが，
やはりFC2ブログは書くのがめんどくさい，
見る側もいちいち新曲更新や障害がおこるたびにブログを探してアクセスいないといけないのでめんどくさいはず，
ということで，基本情報発信はTwitterと，トップページのTwitterウィジェット，ということにしようと思う．
ただこれだとやはりタレコミがしにくいので，FC2ブログは現状のまま残し，Twitterとの連携機能を使って，一日一回ツイートのまとめ記事を投稿させるようにする．

pxgradient(テキストをグラデーション表示するjQueryプラグイン)を使用するとユーザ一覧が激重です．
pxgradient が悪いというよりかは一覧の全部のユーザに適用してるのが悪いのですが…

pxgradient，簡単で良いのですがグラデーションをかけた文字がコピペできなくなる等気に入らないところもあり，webkitだとCSSで簡単にグラデーションが得られるのでそっちにしたいのですが，そうすると10%ぐらい存在するFirefoxとIEユーザを切り捨てることになりあまりよくない

結局はユーザ一覧でフェッチしてくるユーザの数を高々50件ぐらいにしておき，ソートしたいときはサーバにまた問い合わせ直す，というのが現実的かも

Tri-boost　稼働から1年ほど経つが、
（おそらくは）次期バージョンがそろそろ発表されると思うので、
移行の方法を優先度最高で考えたい。

時期バージョンを仮に tetra という名前だとする。現状

tri.gfdm-skill.net/users/
tri.gfdm-skill.net/musics/
tri.gfdm-skill.net/skills/

のようになっているのを、

gfdm-skill.net/tri/users/
gfdm-skill.net/tri/musics/
gfdm-skill.net/tri/skills/

gfdm-skill.net/tetra/
gfdm-skill.net/tetra/musics/
gfdm-skill.net/tetra/skills/

のような構成にしたい
（別にドメインを変更する必要はないかもだけど）

案

ゆくゆくはVPSあたりに移転させたいが、
とりあえず現状のPaaSをそのまま使う方向で、
以下の様な方法を考えている。

データベースを切り変える

単純には、同じモデルを使いながら、
/tetra/以下のリクエストがあった場合に、
MySQLのデータベースを切り替える方法が考えられると思う。

ただし、SqaleのようなPaaSでは、
1アカウントごとに使えるMySQLデータベースの個数は1個になっており、
この方法は使えない。
また、データベース切り替えによってパフォーマンスはどうなるのか？という疑問もある

tetra用テーブルをORM

実際のMySQLデータベース上では tetra_user や tetra_skill といったテーブルを新しく定義して、
既存の user 、 skill コントローラあるいはモデルでどうにかして参照を切り替える。
こうするべきなんだろうけど実際どうやるのかわからないし、複雑になりそう。

tetra_user や tetra_skill などといったモデルを追加して、 routes.rb で振り分ける

ソースが汚くなっていくが、これが一番簡単に思う。
たとえば user は tri/users/ に飛ばし tetra_user は tetra/users/ に飛ばしちゃえば良い。
メンテナンスは最新バージョンのだけすれば良い。

ドメイン問題

完全に最初のミスだけど tri.gfdm-skill.net から gfdm-skill.net/tri に移動したい
VPS 借りてtri.gfdm-skill.netからリダイレクトするだけのアプリ置きたい

拡大できるとはいえもうちょっとデフォルトで広くしたほうがよさそう

再現手順

case1

1. スキル登録 より
   Agnus Dei を
   難易度：マスターギター
   達成：99
   で登録
2. 1.登録後、スキル登録 より
   Agnus Deiを
   難易度：マスターベース
   達成：100
   で登録

2で登録したものが反映されない

case2

1 スキル登録 より
0時20分のRouletteを
難易度： ベーシックギター
達成：100
で登録

2.1登録後スキル登録 より
0時20分のRouletteを
難易度： エクストリームギター
達成：100
で登録

2で登録されたものが反映される

case3

case2のデータがあることを前提とする

1 スキル閲覧画面より
0時20分のRouletteを押下して編集画面に遷移
難易度： エクストリームギター
達成：10
で編集ボタン押下しスキル閲覧画面に遷移

2.何故か
0時20分のRoulette
難易度： ベーシックギター
達成：100
が反映される

症状の推論
更新日時ではなく同一曲タイトルの一番スキル値が高いものが表示されてしまう。

仕様にするかバグとするかは要検討？

問題点

• 新規登録の位置がわかりにくい
• TOPコンテンツ内に新規登録、ログインの導線があるとコンバージョンがあがるのでは？

スキル値の計算は以下の式でやっています．

https://github.com/kumamotone/gfdm-skill/blob/master/app/helpers/application_helper.rb#L88

((rate * level * 20) * 0.01).to_d.floor(2).to_f

このto_d.floor(2).to_fというのは，Float に floor がない ruby において，
強引に小数点以下2位にて切り捨て処理をしてしまう処理で，以下の記事を参考にしています．

http://qiita.com/ryoff/items/eb2e8242561a105eb940

以上の記事でも言及されていることですが，
to_d でBigDecimalに変換しても，その前にFloatの変数に何か代入した時点で，
エラーがおこらなくとも誤差で値が意図しないものになっていることがあります．

実際，rate=92.74，level=5.00のとき，以下のようにおかしくなります．

irb(main):014:0> rate = 92.74
=> 92.74
irb(main):015:0> level = 5.00
=> 5.0
irb(main):016:0> ((rate * level * 20) * 0.01).to_d.floor(2).to_f
=> 92.73

調べてみると，掛け算の結果おかしくなっているというよりか，92.74は，
Float として宣言した瞬間 92.7399999... に近い値になっているように見えます．

irb(main):001:0> require 'bigdecimal/util'
=> true
irb(main):002:0> require 'bigdecimal'
=> true
irb(main):008:0> 92.72.to_d.floor(2).to_f
=> 92.72
irb(main):010:0> 92.73.to_d.floor(2).to_f
=> 92.73
irb(main):009:0> 92.74.to_d.floor(2).to_f
=> 92.73
irb(main):011:0> 92.75.to_d.floor(2).to_f
=> 92.75

これを解消する一つの方法のひとつは
to_d する前に to_s してしまうことのようです．

irb(main):013:0> 92.74.to_s.to_d.floor(2).to_f
=> 92.74

というわけで，以下のように計算後に to_s するように変更を加えればよさそうです．

irb(main):018:0> ((rate * level * 20) * 0.01).to_d.floor(2).to_f
=> 92.73
irb(main):019:0> ((rate * level * 20) * 0.01).to_s.to_d.floor(2).to_f
=> 92.74

おわり

既に登録している曲のスキルを登録するとき、
skills/[skill_id_num]/edit/ ではなく skills/new からすると、
「既に曲が登録されています」とか出てウザすぎる
バグと言ってもいいレベル

id と 曲名の組は簡単に取得できるはず
曲名からidが引ければ 曲名/難易度/達成率 だけ書いてある csv(tsv) から自動登録できる
tsv は現存する偉大なブックマークレット(http://www.nicovideo.jp/watch/sm27220060) がそのまま使える
クライアントサイドで 25回 × 1000曲の比較ぐらいならシュっとできるのでは

• 対象スキル帯のユーザを全列挙
• それらのユーザのスキル全部をリストで集計する
• 最終的に「曲名」「難易値」「達成率の平均」「登録数」みたいなデータにする
• datatables に食わせて登録数でソート

いつも大変便利に愛用させていただいております。

実力が近いユーザのスキルから稼ぎ曲や次の目標を見つける、
という使い方ができるととても便利だなあと思っております。
そこで、指定したIDのライバルとスキル差分が表示できる、という機能を試作してみました（下図）。

こういう機能を追加してもいいよ、と思っていただけたら
Pull Requestさせていただきたいのですが、いかがでしょうか？