めあとるーむ記録帳

なんか書く

MavenでCheckstyle

Java

開発環境にEclipseではなくVisual Studio Codeを用いていて、ビルドツールはコマンドラインでMavenのコマンドをたたいている。

で、Pythonを書いているとpep8なるものがありコーディング規約をチェックしてくれたり、Goだと言語仕様レベルでコーディング規約を定めてくれていることもあり、Javaでもそろそろコーディング規約のチェックツールを導入するかなーと思った。

Javaでのコーディング規約チェックツールにはCheckstyleというツールがある。これを使えばいいことまではすぐにわかったのであるがMavenを使っていることだしMavenで実行させたい。

Maven用のCheckstyle Pluginはちゃんとある。

Apache Maven Checkstyle Plugin – Introduction

しかし日本語資料はこれでもかというぐらい見つからなかった。厳密にはあったのだが、Maven2での資料でMaven3ではなかった。

なのでここに軽く示す。

Apache Maven Checkstyle Plugin – Usage

示すって言った直後にあれだけどここのページの下部にあるExampleを大体コピーで構わない。バージョンには気を付けるのと、設定関係の値（configuration下）は考えた方がいい。

configLocation値とかは書かなくても動くし（Checkstyle自体がデフォルトでSunの規約となっているのでおそらくそれで動いてくれる）

で、走らせた結果日本語が文字化けしてめちゃくちゃエラーを吐いている。つらい。5471個もエラーが出た。つらい

でも日本語使ってるからエラーというわけではなく、出力がUTF-8だからこうなってっぽい。

一応CHCPコマンドで文字コードを変えることはできるが、それでも一部文字が上手く表示されないようだった。

出力をShiftJISにするか、あるいはエラーメッセージを英語で出力するかの解決法しかないと思われる。一時ファイルに出力させてそれをエディタで見るのも一つではあるが、それもそれで面倒。

一番楽なのは出力を英語にするやつだと思う。でもどうすればいいかわからない……

Eclipseとか使いたくない人がWindowsでJavaの開発環境を作る

Windows Java 雑記

Javaの開発環境を調べていたら毎回毎回Eclipseの情報が出てくるが、なんとなくあのIDEを使いたくない場合はこういう風にしようって感じの話。

ざっとまとめるとこんな感じで開発してる

まあぶっちゃけたことを言うと一番苦労するのはVSCodeの環境を整えることでGitはGit for Windowsとか入れればいいしMavenはZIPで落として適当なところに解凍してパスを通すのが楽。

パッケージ管理システムを使うならChocolatyあたりを使うといい。この場合もPowershellになる。

ところでシェルをPowershellにしているが、実をいうとBashを使いたかった。

Bash on Windowsでも同じプロジェクトを操作することができるが、一つ問題点としてBashとWindowsの環境が切り離されているというところ。WindowsにGitを入れてもBashの方ではGitが呼べない（厳密には2017年4月のCreater Updateで呼べるようになるらしいが）ので、Bash環境の方にLinux用のGitやMavenを入れる必要がある。

が、現状（バージョン1607）ではBash on WindowsでJava実行時に問題が起きるのでそれができないという問題がある。また、Bashの方からWindowsのMySQLへのアクセスとかしようとするとソケットでエラーが出てくるためあまりよろしくない（解決できるかもしれないけど時間かかるしわからなかった）。これはこれでBash側にMySQLサーバ立てればいいところでもあるが。

VSCodeの開発環境は拡張機能でJavaの言語サポートがあるためそれを使うのが一番簡単だと思う。

Red Hatのやつが特に問題なく入ってくれると思う。Language Support for Java™ by Red Hatってやつ。

各種MavenのプラグインはPOMに直接書き込むことになる。これが面倒だなぁと思うならGradleに移行するのもいいと思う。最近ならプラグイン関係はMavenにもGradleにも対応してると思うし。

Mavenのプラグインは基本的に好みだが、おススメするところでは

あたりは入れておきたいと思う

Bash on Windows での .bash_profile の扱い

Bash on Ubuntu on Windows Windows

環境変数やらを扱う際に使うときは .bashrc と .bash_profile の二つがある。これらの違いはログイン時に読み込まれるかシェル起動時に読み込まれるかの違いがある。

参考

qiita.com

これによると .bashrc はシェル起動時、.bash_profile はログイン時とある。

通常ならこれでいいのだが、さて Bash on Windows ではどうなるのか。というのも、ログインタイミングはユーザログイン時なのか bash 起動時なのかわからない。シェル起動時というのは bash 起動時でいいのか。

で、（わかっている）結論から書くと、bash 起動時はログインとは取られていない。

そもそもデフォルトではホームディレクトリに .bash_profile はないのでひょっとするとログイン時という処理は特別な扱いをされていて読み込まれないのかもしれない。

もし環境変数を設定したい場合は .bash_profile ではなく .bashrc に書いておくのが安パイかもしれない。でも正しい処理ではないのであくまで Bash on Windows ではそうしておく程度に考えた方がよさそう。

ちなみにシェル再起動のコマンドは exec $SHELL -l で再起動する。何かあれば .bashrc に書き足した後にこのコマンドを実行すればとりあえず使えるようになるはず。

本当はちゃんといくつかのパターン（再起動とか）で検証するのが正しいんだろうけど時間がないので誰かやってくれると助かる。

Nintendo Switchを買った

ゲーム 雑記

買った。発売日に手に入った。天よありがとう。

で、触った感じ

まず本体。排熱用のスリットはやっぱちょっと熱を持つ。40度ぐらい。配置的にも携帯モードで遊んでもまあそんなに気にならない。

重さもまあそれなり。重いほどではない。劇的に軽いわけでもない。昨今のタブレットなら普通ぐらいか。

スタンドもあるが角度が固定で結構急なのでちょっとキツイかも。出来なくもない程度。ちょっと頼りないけどちゃんと支えてくれる。

本体側のボタンは電源、音量のみ。あとはコントローラにいくつか。特に押しにくいこともなくいたって普通。

コントローラはJoyConと別にProコンを購入。JoyConは小ささが目立つ感じ。慣れればそこまで気にならないがスティックのストロークがやや浅い感じ。ボタンは小さめだけどまあこれも問題はなし。トリガー関係も良好。HD振動はまだ体験してないが、普通の振動でもiPhoneのようにメリハリのついた振動の感じ。iPhoneとその他のスマホを持っている人にはわかると思う。

Proコンは結構大きめ。WiiUプロコントローラと比べてもちょっとでかいかも。WiiUのときはProコンがWiiUゲームパッドのボタン類を再利用してる感じだったのに対してこっちは完全新規設計。従来のコントローラに近い。トリガーがPS3やPS4みたいに飛び出してるけど完全なデジタルボタンなので暴発の可能性は低そう。

加えてコントローラ類は全部マット処理がされてるので指紋とかは目立たない。これはとてもプラス。

OSはFreeBSDベースらしい。権利関係の表記でFreeBSD Kernelの表記があった。PS4もFreeBSDなんだけどなんだろうねこの流行？

全体的にキビキビと動く感じ。買ったばかりのAndroid端末を彷彿とさせる動きだった。

設定周りは割とすんなり。このあたりはWiiUの反省が生きてるっぽい。

ドックから外すと携帯モード・テーブルモードに起動、つけるとテレビモード。このあたりの動きもかなりしっかりしてる。

欠点はテレビ側が切替速度に対応しきってないところか。いいテレビがほしくなってくる

その他起動周りもかなりすんなり。3DS同様基本はスリープで起動に時間はかからない。ゲームを中断するのも容易。本体のボタンのほか、ホームボタン長押しで簡易メニューが出るのでそれを使うと画面の明るさ、機内モード、そしてスリープに入るのかを選べる。スリープは本体の電源ボタンでも行ける。

発売日にアプデもあったがそちらも特に問題なし。5分もしないで更新が終わった（と思う、うろ覚え）のでかなり良さそう。

どうでもいいけど周辺機器でコントローラなどを購入するとすごい勢いでUSB Type-Cケーブルが増える。まあ当然なんだが、なんかすごい侵食率。

あとProコンはBluetoothでPCにも容易に接続できるとのこと。なんかNintendoがこんなにオープンな規格を使ってるのは珍しい気がする。時代の流れだろうか。

バーっと書いたが、ぶっちゃけるとあんまり良く見てない。まだeShopにもアクセスしてない。

ゼルダが面白すぎる。このゲームはヤバイ。多分歴史に名を残す。時オカを越えてると思う。なんというか、これはオーパーツとかそういったたぐいのゲーム。明らかにおかしい。今までのオープンワールドゲームが「ただ単純に世界が広いだけでした」と言われると否定できなくなる気がする。

このソフトの前と後で、多分ゲーム自体も変わるんじゃないかと思うぐらい。

多分とりあえずクリアしたらまたなんか書くと思う。明らかにおかしいもん。本当にもう1つの世界があるって言われるレベル。頭おかしい。

ゼルダの伝説 ブレス オブ ザ ワイルド

ゼルダの伝説 ブレス オブ ザ ワイルド

ゼルダの伝説 ブレス オブ ザ ワイルド

ゼルダの伝説 ブレス オブ ザ ワイルド

Javaのファイル読み込みでテキストを扱うときはchar型を使わない方がいい

Java

ファイル読み込みでテキストファイルを扱うときはこんなコードを書く

    String fileText;
    try{
        BufferedReader br = new BufferedReader(
            new InputStreamReader(
                new FileInputStream("FileName"), "UTF-8"
            )
        );
        StringBuilder sb = new StringBuilder();

        String line;
        while((line = br.readLine()) != null){
            sb.append(line);
        }
        br.close();
        fileText = sb.toString();
    }catch(FileNotFoundException e){
        e.printStackTrace();
    }catch(IOException e){
        e.printStackTrace();
    }

そして一部をこうも書ける

        int ch;
        while((ch = br.read()) != -1){
            sb.append((char)line);
        }
        br.close();

違いは1行ずつ読み取るか、一文字ずつ読み取るかの違い。

でもこうすると内部に改行が含まれている場合、うまく扱えないケースがある。一応Characterクラスには\nが定義されてるが、改行直後の文字の扱いがおかしくなってしまい、改行ごとにパースした後に表示されない文字が残ってしまうようだった。

詳細は調べたら追記するかもしれないが、改行をもとに分けるようなコードだったら注意する必要があるみたい。

JSONのkeyにあたるstringの覚え書き

雑記 JSON

JSON は最近のネットワークを通じたデータのやり取りでよく使われている。Web サービス以外にもゲームや設定ファイルに使われることがあるぐらい。

そんなわけでライブラリもそろってるし、お仕事でも機能の切り分けとして WebAPI 化したりする際に使った。

ただ、どうしても環境が環境でちょっとライブラリが使えず、まあそこまで複雑な仕組みにならないということで手書きで JSON を出力するコードをある時に書いた。 そのコードを用いて吐き出した JSON を、別環境で読み込ませようとしたときにエラーが起こった。

なんと別環境で使っているライブラリで読み込めないというケースが発生したのだ。

そのとき使っていたライブラリは Google GSON というライブラリ。

github.com

これは JSON を Java オブジェクトにシリアライズしたりデシリアライズしてくれるライブラリ。

不思議なことに一部はできていたが、途中からできていなかった。JSON の形がおかしいのかと疑ったが、整形はできるし JSON.org を見てもおかしな点はない。

はてさてなぜやらと思いつつ調べると、デシリアライズに失敗した部分の key が大文字から始まるという共通点があった。

{ "Hoge" : "fuga" }

みたいな感じだったのだ。これを

{ "hoge" : "fuga" }

とすると問題なく通った。

ふと調べてみると Twitter の API とかは key の文字列が小文字から始まっていた。困ったときは仕様書に帰れというわけで、そんな決まりでもあるのだろうかと思い RFC と ECMA を調べてみた。

JSON が関係する仕様書は

と思われる。上から順に

2つ目と4つ目は同じことを言ってる通り、中身もたぶん同じ。策定文書が違うだけだと思われるが一応上げておく。Ecma は JavaScript などの親分的存在。まあそれはさておき。

とりあえず JSON の key に関する情報を集める。

http://www.json.org/object.gif

まんま json.org から引用したが、このとおり。つまり string(文字列？)であれば何でもいいように書いてある。

では string の定義を見てみる。RFC4627 には以下の通り。

A string is a sequence of zero or more Unicode characters [UNICODE].

string は0文字、あるいはそれ以上の Unicode の文字の集まり。

これは Introduction での記述。別途あった Strings では以下の通り。部分抜粋。

A string begins and ends with quotation marks. All Unicode characters may be placed within the quotation marks except for the characters that must be escaped:quotation mark, reverse solidus, and the control characters (U+0000 through U+001F).

stringsの始まりと終わりはクォーテーションです。すべてのユニコードの文字が使え、エスケープを用いることでクォーテーションマークなど（具体的にはバックスラッシュや水平タブなど）の文字も使えます。

JSON.org にもっとわかりやすい図があった。つまりこういうこと

http://www.json.org/string.gif

引用しなかったが、特殊な文字の表現についてなどが書かれている。

Parsers の項を見てみたが、この辺りは JSON の形式にちゃんと対応すること、実装時によってはネストの深さや文字数によっては対応できないものがあるかもしれない、程度の注意書きだけだった。

この辺りには大文字の使用の制限に関しては存在しない。気になるところというと、同項(String)の以下のくだり

The representation of strings is similar to conventions used in the C family of programming languages

strings の表現はC言語系の形式にほぼ同じ

とはいえこれがkeyに該当する変数名のコーディング規約のたぐいだと取るのは拡大解釈が過ぎる気もする。

そしてRFC7159を見て驚愕した。13項Exampleでこんなものが書いてあった

This is a JSON object:

{
 "Image": {
      "Width":  800,
      "Height": 600,
      "Title":  "View from 15th Floor",
      "Thumbnail": {
          "Url":    "http://www.example.com/image/481989943",
          "Height": 125,
          "Width":  100
      },
      "Animated" : false,
      "IDs": [116, 943, 234, 38793]
    }
}

めっちゃ大文字使ってるやん

つまり、単にGoogleGsonが対応できてないというだけの話だった

今さら始めるFGO

雑記 ゲーム

FGOの第1部が終わって1ヶ月ほど経過した。

年末にガーッと盛り上がったこともありユーザーが増えているようだが、ぶっちゃけ先にいうと

FGOはめっちゃ不親切なゲームである。

先ほど言ったとおり、そろそろはじめて1ヶ月ほど経過するわけで、やはりドロップアウトする人が増えつつあるようだと思う。

初心者向けの紹介ツイートなどもあるが、ぶっちゃけそれより先に覚えることがあるのでそれを教えておこうかな、と思ってこの記事を書く。

0. 型月が合わないならやめておけ

まず言っておくが、このゲームは型月ゲーである

何を今更だが、このゲームはType-moonのブランドを冠している。過去、型月作品を触れて合わなかった人間はまず合わないと思ったほうがいい。

なぜなら、このゲームのよさのかなりの部分を型月の空気が占めているので、はっきり言ってそこが合わなければもはやこのゲームはただの不親切なゲームになってしまう。

では過去の型月作品を触れるかというとそこまでは言わない。もしはじめてなら、とりあえず序章、1章あたりをプレイしてシナリオを読んで欲しい（スキップはすべきではない）。

もしそこで「続きが気になる」とか「嫌いじゃないなこういうの」とか「キャラクターに感情移入してしまった」という部分があれば問題ないと思う。

おすすめは3章以降なのだが、まあそこまで行くのは長いのと、初期に実装された部分がめっちゃ不親切な部分が強いのでそこを越えるのはちょっとつらいと思う

1. クラス相性を考えろ

ではプレイするときに覚えることだがまず一つ目。覚えなくても意識するぐらいでもいい

FGOでは戦闘時、クラスによって有利不利がある。スキルなどでは攻撃力20～50％アップ程度（各種差はあり）のバフになるが、クラス相性は純粋にダメージが倍になったり半分になったりする。

レア度より先にクラス相性を考えるのが一番である。フレンドを選ぶ画面でも表示されるが、ぶっちゃけUIが分かりにくいというまたこの不親切さが（ｒｙ

以下まとめる

  • セイバーはランサーに強い
  • ランサーはアーチャーに強い
  • アーチャーはセイバーに強い
  • ライダーはキャスターに強い
  • キャスターはアサシンに強い
  • アサシンはライダーに強い
  • ルーラーはセイバー、ランサー、アーチャー、ライダー、キャスター、アサシンから受けるダメージを半分にする。アヴェンジャーに弱い
  • アヴェンジャーはルーラーに強い
  • バーサーカーは上の全てのクラスへ与ダメも被ダメも倍になる（上の全てに強く、全てに弱い）
  • シールダーは全てに等倍
  • 一部ボスなどは別枠

ほらめんどくさいでしょう

でもぶっちゃけこれを覚えるところから始まりだし、これがわかってないと多分ずっと苦労する。バサカで殴るのは楽だけど受けるダメージも増えるので扱いが難しい。アヴェンジャーあたりは楽ではあるが、うまくクリティカルスターを調整しないとHP70万ぐらいのボスを削りきれなかったりする。

なので、強いキャラとかはあんまり関係ない

もちろん星5はだいたい強いが、○○さえ入れておけば何も考えなくていいということは絶対にない。

そもそも戦闘で3人パーティに並べるわけで、1体で全部済ませるようなキャラはいない。クラスさえ相性が良ければ全員星1とかでもどうにかなったりする（シナリオ後半からはつらいが）

ついでにいうと、マスターレベルが低いうちはコストの都合入り切らないので、低レアも使うことになる。その場合、やはりクラス相性を一番に考えたほうがいい。

2. 育成はレベルから

基本このゲームはレベルを上げて物理で殴るのが一番早い。シナリオ後半からスキルとかを考える必要が出てくるが、まず前提条件としてレベルマックスである。

面倒なようだが、ある程度戦力が揃ってくると曜日クエストの種火集めが安定するようになり、ぶっちゃけ作業になる。

まあこれがこれで面倒だったりするのだが、忘れてはいけない、このゲームは結構不親切である。

ちなみにレベルを上げようとすると再臨でつまずくことになると思うが、とりあえず詰まったら他のキャラのレベルでもあげておけばいいと思う。

レベルはメニューの強化から手動でやる必要があるのでそれも忘れないように。多分、序盤ならドロップやフレポガチャの小さい種火をマメに食わせたりしておけば20ぐらいまでは行けるはず。

まあ金の種火の100分の1ぐらいの経験値しか入らないが。

3. アイテムの集め方

基本的にドロップはめっちゃ渋い。加えて一部素材はシナリオ後半にしか出てこない。

つまり、シナリオ序盤のタイミングで後半に出てくるキャラを引くと第1再臨で詰まってしまうケースもある。

そんな時に頼りになるのがイベントである。イベントは素材回収のタイミングである。

問題はFGOのイベントは割とスパンが長いことだ。大体3カ月に2回ぐらい。イベントがないタイミングも結構ある。

新年になってから復刻イベばっかでしかも1つは監獄塔とか高難易度イベをやるあたり本当に運営は不親切である。

ちなみに初期は未実装シナリオで出てくるアイテムが再臨素材に要求されていたりした。その時もイベント頼みだった

まずこの4つ。本当にそのぐらい。

戦闘であれこれ気にすることなどもあると言えばあるのだが、初心者にはいらないと思うのであえて言わなかった。多分Wikiとかに書いてると思うので自分で読むといい。

もう一度言うが、FGOは基本不親切なゲームである。それを把握したうえで楽しんでもらいたい。