Upgrade to Pro — share decks privately, control downloads, hide ads and more …

艦これタイマー for Pale Moon+

koedoyoshida
September 02, 2017
55

艦これタイマー for Pale Moon+

koedoyoshida

September 02, 2017
Tweet

Transcript

  1. 艦これタイマー for Firefoxとは • Amanoさん作のソフトウェア • 艦これタイマーとは遠征や入渠、建造の残り 時間を管理し、時間がくると通知してくれるア プリの総称。 •

    艦これタイマー for Firefoxはタイマーを自動設 定するためにFirefoxアドオンとして作成された 艦これタイマーです。 • http://miku39.jp/blog/wp/?page_id=1705#i-2 6
  2. 艦これタイマー for Firefoxの技術 • nsIObserverService で http-on-examine-response (HTTPの受信)の通知を受け取り、艦これのURL であれば nsITraceableChannel

    で通信の内容を チェック、タイマーの設定を行っています。 • 残り時間の取得のためにサーバーに一切アク セスは行わないため、サーバーの負荷に優しい 仕様です。また、オンラインゲーム利用規約を読 んだ上でサーバーにアクセスを行わない実装 • http://miku39.jp/blog/wp/?page_id=1705#_for_ Firefox 7
  3. 規約との整合性 • http://www.dmm.co.jp/rule/=/category=onlinegame_service/ • (8)不正な方法(特殊なプログラムを介しての)でのアクセスを試みる行為 • (12)その他当社が不適切と判断する行為 • (8)については、人口増加によるサーバー過負荷での猫問題もあったのでむや みやたらにサーバーにアクセスしない方がサーバーに負荷はかからないし、サー

    バーにアクセスしなければ「アクセスを試みる行為」にも該当しないし誰にも迷惑 がかからないので、通信内容を見て判断するのは問題ない”だろう”と、通常こう いう項目はサーバーのクラッキング行為や、通信手順をなぞる外部プログラムを 使った、1クリックで遠征できますとかダメージのある艦艇をまとめて入渠させま すとかのマクロや、戦闘シーンを高速にしてさくさくと経験値稼ぎできます(通常で はありえない頻度で通信をすることになりサーバー負荷も高まる)とかいんちき処 理などを想定しているものであること、(12)については、当社というのは DMM.comを指していますが、何をもって不適切と判断するのかDMM.com次第の ため気にしてもしかたがないので、その時になったら開発中止などを考えることに する。要請があれば素直に従う。 • http://miku39.jp/blog/wp/?p=1867 8
  4. 艦これタイマー for Firefox (オリジナル)のライセンスとソース • MITライセンス – http://miku39.jp/blog/wp/?page_id=1705 • ソース

    – xpiファイルなのでzipとして展開可能 • リポジトリ – https://bitbucket.org/amano_rox/kancolle-timer- for-firefox 9
  5. 艦これタイマー for Firefox+ • Forkして開発 • 本家はタイマーとしての機能は十分に実装済 み。 • サイトのコメントで要望は多くでているが、タイ

    マーの範囲を超える要望が多い。 • 作者のamanoさんは提督業で忙しい。 • 個人的にも付けたい機能がある。 – 艦これタイマー for Firefox をベースにしてAddonを作ることにした。 10
  6. 艦これタイマー for Pale Moon+ • 艦これタイマー for Firefox+ をリネーム •

    emid等を引き継ぎ • FirefoxのAddon署名も付けているので現行の FirefoxESRでの動作は可能 • addons mozillaでは公開していない • bitbucketで公開 • https://bitbucket.org/koedoyoshida/kancolle- timer-for-pale-moon 17
  7. ビルドの自動化(3) #ビルドスクリプト $ cat Makefile define SHELLSCRIPT mkdir -p ../build/chrome

    if type -a JSsyntaxcheck.sh > /dev/null 2>&1 ; then JSsyntaxcheck.sh chrome/content/*.js || exit 1; fi #Version modify cp -f install.rdf install.rdf.orig sed -i -e "s/<¥/em:version>/."`git rev-parse --short HEAD`"<¥/em:version>/g" install.rdf sed -i -e "s/<em:creator>/<em:creator>KoedoYoshida<¥/em:creator><em:creator>/g" install.rdf (中略) bash build.sh cp -f install.rdf install.rdf.bak cp -f install.rdf.orig install.rdf endef export SHELLSCRIPT all:: echo "$${SHELLSCRIPT}" > /tmp/$$$$ ; $(SHELL) /tmp/$$$$ ; rm -f /tmp/$$$$ 21
  8. JavaScriptの構文チェック(2) • JShintを使用 – Node.jsまたはRhino等で動作 – http://www.jshint.com/install/ • Rhino –

    Rhino(ライノー)とはオープンソースで開発されて いるJavaScriptの実装である。RhinoはJavaで記述 されており、Mozilla Foundationによって管理、配 布されている。 – https://developer.mozilla.org/en-US/docs/Rhino/ 23
  9. JavaScriptの構文チェック(3) • cygwin環境で下記を作成。 • ^Eは構文エラー検出のみ使用したかったため、 ワーニングレベルだと元ソースでも多数出る。 $ cat /usr/local/bin/JSsyntaxcheck.sh #!/bin/bash

    "/cygdrive/c/Program Files/Java/jre7/bin/java.exe" -Dfile.encoding=UTF-8 -jar "C:¥cygwin¥home¥user¥rhino1_7R4¥js.jar" "C:¥cygwin¥home¥user¥jshint- rhino-2.1.10.js" $@ | grep "^E" && exit 1 exit 0 24
  10. JavaScriptの構文チェック(4) • チェック行数を無制限に変更 • Node.js版と出力フォーマットも多少異なるが、1行で出力するよう修正。 • エラーはE999,ワーニングはW999といったフォーマット。 $ diff -uNr

    jshint-rhino-2.1.10.orig.js jshint-rhino-2.1.10.js (中略) - state.option.maxerr = state.option.maxerr || 50; + state.option.maxerr = state.option.maxerr || (中略) for (var i = 0, err; err = JSHINT.errors[i]; i += 1) { - print(err.reason + " (" + name + ":" + err.line + ":" + err.character + ")"); - print("> " + (err.evidence || "").replace(/^¥s*(¥S*(¥s+¥S+)*)¥s*$/, "$1")); - print(""); + print(err.code + ":" + err.reason + " (" + name + ":" + err.line + ":" + err.character + ")" + "> " + (err.evidence || "").replace(/^¥s*(¥S*(¥s+¥S+)*)¥s*$/, "$1")); } 25
  11. smarttab問題(1) • 元ソースのインデントは – 1段目:4SPACE – 2段目:tab – 3段目: tab

    4SPACE – 4段目: tab tab • いわゆるsmarttab(by JSHint) • Java ScriptのIndent規約 – http://www.oracle.com/technetwork/java/javase/ documentation/codeconventions- 136091.html#262 – Four spaces should be used as the unit of indentation. The exact construction of the indentation (spaces vs. tabs) is unspecified. Tabs must be set exactly every 8 spaces (not 4). 26
  12. smarttab問題(3) • .git/hooks/pre-commitで対応 – 特定ブランチはtabの存在を許す。 – それ以外のブランチは強制修正または警告 • git cherry-pickにpre-commitが呼ばれない

    – git format-patchとgit amを併用 – .git/hooks/pre-applypatchで.git/hooks/pre- commitを呼ぶ。 – 最終的にgit commit --amend -C HEAD 28
  13. smarttab問題(3) $ cat .git/hooks/pre-commit #!/bin/bash if git rev-parse --verify HEAD

    >/dev/null 2>&1 then against=HEAD else # Initial commit: diff against an empty tree object against=4b825dc642cb6eb9a060e54bf8d69288fbee4904 fi #master branch is ok git branch | grep -e '^* master$' && exit 0 RET=0 if git branch | grep -e '^* target-branch$' >/dev/null 2>&1 then for FILE in `git diff-index --name-status $against -- | grep -E '^[AUM].*¥.js$'| cut -c3-`; do sed -i -e 's/¥t/ /g' "$FILE" done exit $RET fi 29
  14. smarttab問題(4) cat .git/hooks/pre-applypatch #!/bin/sh #サンプルそのまま有効化 . git-sh-setup test -x "$GIT_DIR/hooks/pre-commit"

    && exec "$GIT_DIR/hooks/pre-commit" ${1+"$@"} $ git-format-patch ~ (中略) $ git am --ignore-space-change 000x.patch $ git add -A ;git commit --amend -C HEAD 30
  15. 改行コード • オリジナルの改行コードはCRLF • vimだと毎行末に^Mが表示される。 – EmacsならOK – 宗教上の理由(宗教の自由) •

    sed等に掛けるとCRが落ちる – 変更していない部分も差分と表示される – smarttab問題で置換するとこれも困る • 変換するとcherry-pick,merge,rebase等が困難 になる。 31
  16. Mercurial(hg)からgitへ(1) • git-hgで変換 – http://offbytwo.com/git-hg/ • git-hg cloneすると新規のgitリポジトリが出来る ので、それを既存のgitリポジトリに統合 –

    $ git hg clone (hgリポジトリURL) – ~/gitrepo $ git remote add hgrepodir (cloneして変換 されたhgのgitリポジトリ版のディレクトリ) – ~/gitrepo $ git fetch hgrepo • gitブランチとしてhgの変換後リポジトリが見える 33
  17. Mercurial(hg)からgitへ(2) • 統合後のgitリポジトリでgit-hg fechしたい – 変更後の修正を取り込みたい error abort: repository .git/hgcheckout

    not found! • 下記を実施 ~/gitrepo $ cp -rp hgrepodir/.git/hgremote .git/ ~/gitrepo $ cp -rp hgrepodir/.git/hgcheckout .git/ ~/gitrepo $ git-hg fetch searching for changes no changes found 34
  18. オリジナルの変更を取り込み(2) • 初期に試したこと • patch適用前にパッチの改行コードとインデント変換を実施 – git format-patchでパッチをファイルに出力 – sedでtabを変換

    – git am (変換後のパッチファイル) • commitログ、著者情報を含めて取り込める • 面倒な点 • git format-patchでは対象コミットの一つ前を指定する必 要がある?コミットの指定方法が直感的でない • コマンドを複数打つ&判断(どれが対象コミットの前のコ ミット?、どれが変換されたファイル?)が必要で面倒 • コミットログもtab変換の対象となってしまう。 • mergeが衝突する場合(該当箇所を双方で修正)の対応が 困難(rejファイル等が生成されない) 37
  19. オリジナルの変更を取り込み(3) • 別解 – 対象commitは"abc123"とする。 $ git show -w abc123

    |(tab変換) | patch -p1 $ git commit -a -C abc123 • 参考Git cherry-pick without whitespace http://stefaanlippens.net/git-cherry-pick-without- whitespace • オリジナルのコミットメッセージと著者情報を 取り込める 38
  20. gitのサブコマンド化 $ cat ~/.gitconfig [alias] cherry-pick-ignore-space-change-ignore-cr =!(git show -w $1

    |nkf --unix -w | sed -e 's/¥t/ /g' |patch -p1 -l && git commit -a -C $1) && echo • そのまま適用出来る場合はオリジナルのコミット メッセージでcommit – 出来ない場合はrejファイルが出来るので手動マー ジ後、同様にgit commit -a -C ~で適用 同様に改行コード(無変換/CRへ逆変換)等も作成 39
  21. 機能追加内容(1) • 表示をグループ毎、任意に表示変更可能に • 保有艦数、保有設備数を常時表示可能 – 最大に近づくと警告表示へ • 内部パラメータの可視化 –

    各艦船の士気(キラキラ、疲労)の数値表示 – 近代化改装(合成)での候補リスト表示 – 演習相手の編成から獲得できるEXP概算を表示 – 入渠の修理時間での降順リスト表示 • 艦艇を装備、艦種等で検索可能 – あの装備どこに行った? – 士気の(高い/低い)状態の艦船はどれ? 49