Closed miramiku closed 6 years ago
コーディング規約合わせてなくてお手数おかけしました。 コードは私もMITでいいかなと思います。 使ってるライブラリやフォントの分は別途明記して列挙してさえいれば。
また何か思いついたら追加させて頂くかもしれませんが、そのときはよろしくお願いします
https://twitter.com/miramiku/status/973531889825808386
ツイッター告知をもってアプデ終了ですー!おつかれさまでした、そしてありがとうございました!
コーディング規約も何もないですからね…脳内にしか…ほんとすみません。 ライブラリやフォントなどすべてのライセンスはクレジットの一番下に列挙しています。 readme.md にも使用しているライブラリなどを列挙してますが更新してなったりして… 時を見て記載しますー!MITライセンスどうもです!
単一表示・複数表示のボタンの件ですが、迷うところではあったんですが「現在の状態」をあらわすようにしているので、単一・複数表示のラベルをこちらのほうで反転させていただきます><; 所持状況の「編集ロック」がその分かりやすい例だと思いますが、ロック中は「ロック」で編集可能だと「可能」となる具合です!
こちらこそありがとうございました。
ボタン表示の表示もお手数おかけします。 私もその認識で作ってたのですが、どこか漏れてたらすみませんm( )m
changelogも問題ないです! あと私のクレジットでしたら表記無くても大丈夫ですよー
changelog の確認ありがとうございます!
クレジットは(本来の)責任表示の意味もあるので…残します! ほんとは Credit のほうにも記載したいのですがどう記載しようか思案中。風化しないうちに残しますよ!ぜったい(`・ω・´)
ただ…changelog の遅延読み込み時にデータファイルのパーサが対応してないからどうしようか地味に考えてます…また来月その部分を対応させると思います…。
誠にすみません… ボタンの表示について、うちが勘違いしていただけでした! Revertしました><;
Issue 一番上に列挙されてる上から4つ目に関して、うちのコード読解力不足によるもので不具合を生んでいました。 変数名重複の問題ではありませんでした。変数の宣言が使用より後に存在したためでした。 変数の定義と使用コードの順序を入れ替えることで対応しました。正常に動作することも確認済みです。
了解です!お手数おかけしました。
今後のふんわりとした構想はこんな感じです。どれも重いです。 4月はかなり忙しそうなので1個もやらない可能性も高いですが・・・
構想は沢山ありますね!
apk 解析は挑戦しましたが失敗しました><; 分かっている事は以下のとおりです。
こんな感じですね…裏口から Wardrobe 用データを採取しようとして時間だけ無駄にしました;;この時間をお役に立てれば幸いです!(暗号の複合、および Lua の逆コンパイルを…!)
画像は2種類ありますよね(アニメーションは除く)。いわゆる「アイコン」と「実際のパーツ」と。 「実際のパーツ」のほうはノイズの少ないデータを取り出すのは困難が予測されますね…それこそ、apk から… カラー解析は 1px x 1px に画像縮小すると平均的な色が疑似的に抜き出せるというアイデアをどこかで入手したので、それでいくつか色決めてたりしてますね…。アイコンの抽出方法の解説は謎なことにとあるサイト(私の管轄外。誰もが閲覧可能なこの場所では書けません)に詳しく書いてあります。 ヘアスタイルとかドレスとか味気のないカテゴリアイコンですが…実はあそこ、実際のアイコンに変更したいんですよねぇ…ですが、アイコンを抽出する手数が多すぎて手が付けられていません!それどこかデータベースがまだ中途半端です!(入手不可能・困難なアイテムもあるのですべて入手するまでという意味ではありません) ちなみに Laurus のメジャーバージョンはデータベースの充実度で上げようと思っています。現在スモールスタートで最低限のデータのみ…それにコメントアウトされた WARDROBE のインデックス定義を見られたと思いますが…それらを組み込めたら v2 へと…そしてアイコン画像いれて v3 が今の所構想している最終形態です。
ローラスくんポケットが出来たら、ローラスお役御免になりそうですね…(現在6割のアクセスがモバイルから)。まったく別物になっても構いませんよ!
ES2017以下の件は勉強不足なのでコメントできず…。Webpack は一度使おうとしてやっぱりやめました…
アイテムごとのステージ毎順位表は私も考えましたがそれをいうと…一度計算すればいいのでパソコンでバッチ処理すればいいとうちも思いました。そうすると、既存ステージもすべて固定テーブルで良かったりするんですよね…いや、ちゃんとアクセサリ装着数による減衰率を考慮しなきゃ!ってことで考えを撤廃しましたが!
私の構想はメモ書き程度に Issues に入ってますね #21, #29, #30, #31 ですね…
ちなみに意図的なんですが 900px 固定で作っている話ですが Advisor のステージデータ項目は左 600px に収めてあり、右側 300px を意図的に余らわせています。その右側はオプション指定領域用に確保されています…今オプションが1つもないので不自然な空白領域と化しています… 現在 980px に広まったので、600 + 300ではなく、600 + 380 にわけるのではなく左側ももう少し広げてもいいかもしれませんね。
私なりの回答と私のほうの妄想は以上です><;これからも魔改造よろしくおねがいしますー!! あ、あと私 JavaScript も GitHub も素人なので…結構分からないことがいっぱいです。厚かましいながら、いろいろご教授いただけたら幸いです><;プログラミングも独学素人です;;本業(?)は理論屋なので現場を知らないダメなヤツです…
apk解析挑戦されてたんですね! 通信先のAPIの調査くらいしかしたことないので、 画像が暗号化されてたら厳しそうです・・・ 付け焼き刃でやっても無駄足になりそうなので、優先度さげておきます。 ありがとうございます。
スマホ版は、私もアプリと見比べて使う想定なので自分で使うことはあまりなさそうです。 ただ、モバイルアクセスが多いと聞いたのと、 ギルドメンバーにも、難しくて使い方わからなかった、という人がおり、 私もアイテムのグラフなどが使いこなせていないので ニーズはあるのかな、と思いました。
理想を言えばレスポンシブデザインにしてPC向けの互換性を持ったまま 本家にマージするのが一番なのですが、 大改造でコンフリクト間違いなしの上に、 Laurus.jsが4200行超もあり、ちょっとした機能追加ならともかく 大きく手を入れるのは私の力量だと辛いので断念しました。 (Advisorに修正入れようとして、Wardrobeの方書き換えたりしてました)
ES2017でClass化して分割、というのはそれをメンテしやすくしたいという意図なのですが、 ES2015↑使う →IEや旧ブラウザで動かなくなるのでbabelが必須 →パッケージ管理やビルド処理の変更も必要 →みくさんへの影響大きすぎて無理 でこちらも断念。
ちょっと本業で触る必要がでてきそうなので その前に慣らしがてら…とは思ってますが 何分大改造なので尻込みしてます。
実はLaurusを知る前に、ニキスクリプト用共有GoogleSpreadSheetを APIで読み込むのをReactで作ったのですが、基本機能ができた! というところでLaurusを発見して、その完成度の高さに放り投げた経緯もありまして(ノω・)テヘ
あと、今回のような本体に取り込む前提ならともかく 完全にフロント分けて別の暖簾でやるのに、 一番大変と思われるデータ部分を借りてやるのは クレジット表記すればライセンス上は問題ないとはいえ ちょっとスッキリしないのもあります。
ちなみに私も本業はサーバサイド側+BitBucketなのでJSもGitHubもあまり詳しくは無いです。 こちらこそ勉強させていただきましたm( )m
パフォーマンスチューニング系や計算式の厳密化は、 もちろんやるに越したことは無いのですが、 現状でも十分な速度は出てるのと思いますし、 順位変わらないなら、Laurus使うユーザはフル装備前提だと思うので 私個人としては優先度としてはそこまで高くないかな、と。
転送量の方はユーザのパケット数とか、サーバの維持コスト (github.ioなら関係ないと思いますが)に関わってきますし、 データのjson切り出しも更新のしやすさやメンテナンス性、オペミス削減なども 期待できるので、個人的には先にこっちかな、と思います。 https://github.com/miramiku/Laurus/issues/29 あたりは作ってプルリク出すかもしれません。
Changelogのjsonとindex.html内の履歴に関してはよくわかりませんでしたので、 Improved版ではindex.html直接書き換えてましたm( )m
とりあえず今の方針はこんな感じです。
アイテムのグラフはC~SSSを可視化したものにすぎません…別表現としてとらえて頂ければ! カード形式ならば2段になってるのであまり問題ないですが(C~Sの色でもわかるので)、Wardrobe の表形式の時にすべてが横になるので、グラフにすると分かりやすいかなって思います。各ステージの評価項目も2段になってるのでその形に似てるグラフほど高スコアということで…
同じスロットで同じスコアでも、特定の属性が一番高くなる組み合わせにするのがベストだと思うんですが…その計算すると条件により組み合わせ爆発が起きそうなのでどこにも書き留めず却下…。
Laurus で一番大変なのデータなんですよね…データ整備してくれる人が複数人いたらいいんですが…(ダブルチェックで)そのような方はいまだ現れません…。
サーバーの転送量は github.io なのでどうでもいいですが…モバイルからだと結構ダウンロード大変ですからねー。速度的にもパケット的にも…削減できるならしたい所…。#29ですね><;
Changelog はべた書きですー。Improved版の通り><;色分け用クラスはいろいろ用意してありますが。当然これも、転送量の関係ですね…古い Changelog なんて必要ありませんから、必要ならば読み込んでくださいのスタンスです。約1か月単位で月が替わって最初の Changelog 記述時に json 形式の過去ログ化する形ですね…(適当)。あと json で記述されている Changelog のパーサを作っただけです。
見ての通り…Laurus は1ページ構成なので毎回全読み込み…必要のないものは遅延読み込み、即応読み込みで対応して読み込み速度向上をそこそこ目指してますー><;(画像など)
私は Android ですが…新しい iOS はページを切り替えるようにアプリを切り替えられて、見比べるように Laurus と ミラクルニキ利用できるんですよね。驚きました…。そのように使い慣れてる iPhone ユーザの方にはスマホ版 Laurus も便利だと思いました。モバイルフレンドリーではありませんが、今のままでも使えますが…
方針についてありがとうございます。私は今のところデータに専念しフロントエンドの方はプルリクを期待しちゃいます><;
ご報告だけ
昼間、Laurus を利用していたら何か違和感を感じたんですがその原因が <div class="rcm-item dummy"></div>
の削除でした。わざわざ削除したところ申し訳ありませんが…復活させました。
また、複数表示の際 dummy
は隙間があいてしまいますが…それも対応済みで複数表示の際は隙間にならないようにコードを一部追記しました (。・ω・)ゞ
あ、単一表示のときのスペーサーだと思って消しちゃって、 その後の互換性もたせたときに戻し忘れてました!
プルリク時に気づくべきでした お手数おかけします(T_T
アイテムグラフの件了解ですー。 タグに対応してるのには気づいてたんですが、尖り具合を見てスキル載せやすさとかを考えるためだったんですね。奥が深い。
データ更新は・・・やっぱりいちばん大変ですよね。 手順次第では取得/整形の部分的な自動化とかはできるかもしれませんが、 手動オペレーションは超苦手なのでお力になれずすみません・・・
changelogのjsonは過去分だったんですね! 聞いた限りだと移植が面倒そうなので、全部jsonに入れて先頭n件取得とかのほうが 構造もシンプルで良いかと思ったのですが、 更新ツールか何か作ってるからそこはあまり苦になってないとかでしょうか?
iphoneのUIは知りませんでした・・・ Androidでもタスクフリッカーというアプリが似たような動きを実現してたようですが、 今は消えちゃってますね。
フロントエンドは、ちょうど本業でも触る機会でてきそうなので、 実験がてらちょっと試してみます!
今は5つの成分ごとに計算していませんが…1アイテムずつ(所詮…最大30アイテム)を再計算して上部にまとめたいですよねー。成分と合計スコアのクロス集計。
超保守のエビデンスベースで行っているのでデータ追加は遅めです。Credit の Resources にある後悔フォルダをみていただけたらお分かりの通り…1枚のアイテムにつき3枚ずつエビデンスとして取得しています。なお、簡略化のため OCR ライブラリを用いて C# でプログラムを作ってみましたが、フォントの関係かライブラリの精度の問題か、使い物になるレベルではありませんでした。
changelog の json は過去分ですねー。2/28 にシナリオ14章解放なのでそれ以前のものはもう json にしまわなきゃいけませんね…(まだ手を付けれてない)。全部、json にいれないのはやっぱり通信量の関係ですね…。サーバプログラムで排出量を調整出来たらやるかもしれませんが…不可能なのでマニュアルです。あと、n件ではなく1か月分なので(しかも今月の場合なんて2/28分も含むと言う例外もあるので)。
json の形式はシンプルなので特に苦にはなりませんよー。ul
/ li
タグと span
のクラスに記載されているものをオブジェクトに置き換えるだけですから…資料整理みたいなもものです。
あまり利用されていませんが…Cheatsheet はアイテム所持の登録状況に関係なく最大6件ずつ表示してますよ。Laurus を使えない他人におすそ分け用です。それをスクショにとってデカイ1枚の画像としておすそ分けして頂ければ!…ただ、その部分を svg か Canvas にしてスクショではなく画像出力できたらいいなとおもうのですが(別に他の方法でもその div 内だけ画像出力できる機能があれば…)
ちなみに 6
というマジックナンバーは最小の完全数 (perfect number) だからですね!
うちも Web 屋になる可能性があるのでもうちょっと技術力アップ出来たらいいですー…。 そのまえに面接の口頭試験でパスするのかが不安ですが…。
NGアイテムのエビデンス、びっくりしました。 あれ自分でアイテム用意して、体力消費して、実際に確認とってるんですね… データの品質担保のためとはいえ恐れ入ります…
changelogに関しては、月単位である切り替える必然性がそれほどないのであれば、 全json化しておいたほうが運用が楽になるかなと。 changelogをクリックしたタイミングで読み込むようにしておけば、 普段遣いする分には転送量も問題ないです。 データのメンテ周りはとても大変みたいですし、こういった箇所で 少しでも楽できるようになれば、と思っただけなので、あまりお気になさらず。
CheetSheetも今ひとつ使い道把握しきれてなかったのですが、 キャプチャ画像送る想定だったんですね。スッキリしました。
div内部だけの画像キャプチャは・・・ ユーザ側のブラウザで表示されてるものを、となるとちょっと思いつかないです。 ブラウザ側のプラグインとかでないと。 裏でヘッドレスブラウザでキャプチャしたものをDLとかならできそうですが、 そこまで周りくどいのはさすがに。
みクオリティで Laurus がんばってます><; 不確かな情報や色違いなど関連がありそうなのは追調査!調査報告は画像付きで。
changelog べた書きがいいですねー><;自由度が高い…編集がしやすい…定型はいいですけど不定形になると大変です><;べた書きが唯一対応できる!それを changelog のパーサに組み込むほうが楽かなーと。チェンジログ切り替え時にすべて読み込むのもいいかもしれませんね><;心揺らぎました なにより驚いたのが、あれ意外とみられてることに驚いてます…結構使ってる人がいるんだなーと><;
Cheatsheet は Laurus がパソコンを想定して作られてるので…パソコン使えない人におすそ分け用です><;でもそんなの関係なく、スマホから使ってる(使える)現状らしいので無用の長物と化してますが!
Laurus v1.12.0 としてマージおよび私のほうでの作業を完了しました。 マージ内容は Changelog に記載されているので内容に齟齬がないか確認お願いします。
コードについて jshint さんから怒られた内容を修正させていただきました。 挙動の変更はありません。
あと、コードの権利関係についてのお話もつけておかなければなりません… いまだに私もライセンスについて不勉強で放置中なのですが…一部、版権ものを含んでいるのでそれらを含んで MIT などと宣言できず… どこかでみた、アイコンフォントのライセンスのように区分してライセンスを明示するのがいいかもしれませんね…。フォントは SIL Open Font License でコードは MIT っていうのをどこかで見ました…それと似たようなことをやろうアレンティーさんがフォークしてからマージされるまでの間に考えてました。