SHOYAN BLOG

I am a pragmatic programmer.

ラピッドブラスターエリートデコのガチヤグラ必勝法

スプラトゥーン2のガチヤグラで勝つ方法を紹介します。私はこのやり方でS+までいきました。ガチヤグラでなかなか勝てないイカの諸君の参考になればと思います。

ラピッドブラスターエリートデコを使う

ガチヤグラで私がおすすめする武器はラピッドブラスターエリートデコです。圧倒的な射程で一方的にヤグラ上の敵を倒すことができます。また、防衛拠点にいる敵をどかすこともできます。

ガチヤグラはブラスター系の武器が強いルールです。なぜかというと、ヤグラ上の敵はブラスターの爆風で簡単に倒すことができます。これがシューターになるとなかなかヤグラ上の敵に当てるのが難しいです。

ラピッドブラスターエリートデコの立ち回り

ラピッドブラスターエリートデコは敵と確実に距離をとってラピッドブラスターエリートデコの弾だけ当たる距離で戦うことが基本的な立ち回りです。このような立ち回りをする理由は、射程が長い分近づかれると弾を当てるのが難しく、簡単に倒されてしまうからです。

初動の立ち回り

初動は自陣をしっかり塗ります。インクを塗っておかないと相手との距離がとれなくなるため、簡単に倒されてしまいます。しっかりインクを塗っておきましょう。初動は自陣にインクを塗りつつ、戦況がどのように動くかを把握します。

人数有利の場合の立ち回り

こちらのチームが人数有利でヤグラ周りに敵がいなければ率先してヤグラに乗ってよいでしょう。ヤグラ上からヤグラに向かってくる敵や防衛拠点にいる敵を攻撃します。

人数不利の場合の立ち回り

人数不利の場合は、安全なところまで下がって味方が前線に復帰してくるのを待ちます。孤立した場合はリスポーンに戻ってしまってもよいです。敵がヤグラに乗っている場合は、安全なところからヤグラ上の敵を攻撃してヤグラの進行を妨害します。

おすすめのギア

おすすめするギアはイカ速、メインインク効率アップです。イカ速は敵との距離を取るために積んでいます。メインインク効率アップは、メイン効率がよくないため積んでいます。私はイカ速1.0、メインインク効率2.0を積んでいます。デスが少なく抑えれる場合はメインインク効率を1.0にして、ペナルティや逆境強化を積んでもよいでしょう。

まとめ

ポイントは敵と距離をとって戦うこと、人数有利の時、人数不利の時の立ち回りを意識することです。あとは実践あるのみです。自然とこの立ち回りができるくらい実践を繰り返せば必ずウデマエはあがります。

スプラトゥーン2が楽しすぎる

スプラトゥーン2が楽しすぎます。社会人になってからゲームはあまりしなくなってゲームは卒業かと思っていましたが、やばいゲームと出会ってしまいました。時間を見つけてはスプラトゥーン2をやっています。ハマりすぎて妻には愛想をつかされていますが、まあそれでもいいのです。

スプラトゥーン2はオンラインサバゲーのようなゲームです。味方と敵の2チームにわかれて自分のチームのインクを多く塗ったほうが勝ちです。幼稚園児でもできるシンプルなゲームです。そんなシンプルなゲームですが、プロゲーマーも多くいて、プロチームもあります。6月11日より世界大会が開催されて、第3回スプラトゥーン甲子園で優勝したGGBoyZが日本代表として出場します。

幼稚園児からプロゲーマーまで楽しめるゲームってなかなかないのではないでしょうか。クリエイターの人には脱帽ですね。素晴らしいゲームです。

ちなみに私のウデマエはS〜Aあたりをウロウロしています。あと100時間くらいやればS+はいけるんじゃないでしょうか。武器はプラコラやラピブラエリート、デュアルスイーパーカスタムなど中長距離武器をよく使ってます。

しばらくはやり続けるでしょうから、今後もスプラトゥーン2について書いていきたいと思います。

まだ設計書書いてるんですか?

私は自社開発のシステムを開発しているエンジニアなのですが、そのような現場でも設計書(詳細設計書や機能設計書のこと)が必要だという意見を耳にします。私は自社開発のシステムの場合、設計書は必要ないと思います。設計書を書く時間があったら1行でもコードを書いてほしいです。

そもそも、なぜ設計書が必要になったかというと、分析と実装を行う人が違ったからです。いわゆる、元請けが設計書を作って、実装は下請けに丸投げするやつですね。分析と実装を同じ人が行う場合は設計書は不要です。

生産性の観点からも考察してみます。

一般的に設計書にお金を払う人はいません。例えば、ホームページを業者に依頼したとして、設計書しか出てこなかったら金返せとなりますよね?
人は動作するアプリケーションにのみお金を払います。基本的に資本主義の世界ではお金を払う人がいるものが価値のあるものです。この一般的な常識から次のような式が定義できます。

動作するアプリケーション > 設計書

以上から、動作するアプリケーションを実装することに時間を使った方が生産性が高いと言えます。

設計書は分析する人と実装する人が違う場合のみに必要です。また、仮に必要だとしても設計書自体に価値はないため、最低限の時間で作るべきものです。

時間は有限です。であれば、価値のあることに時間を使いましょう。

PMDでJavaのコードのバグをチェックする

Javaにおいてバグの要因となりそうなコードをチェックするツールとして、FindBugsがあります。しかし、FindBugsは2015年以降の開発が止まっているため、言語のアップデートに追従できていません。そこで、FindBugsの代替えとなるPMDを紹介します。PMDを使えばバグの原因となりそうなコードを検知することができるため、不具合を未然に防ぐことが可能です。

PMDとは

PMDは次の4つの問題があるコードを検知することができるツールです。

  • Possible bugs - バグの要因となるコード
  • Dead code - 使われていないコード
  • Suboptimal code - 効率の悪いコード
  • Overcomplicated expressions - 複雑な構文

PMD自体はJavaで実装されていますが、Java以外の言語にも対応しています。今回はJavaのコードを対象に使い方を紹介します。

PMDのインストール方法

Homebrewでインストールする

Macであれば、次のコマンドでインストールできます。

1
brew install pmd

バイナリをダウンロードする

バイナリをダウンロードしてインストールすることができます。次のページからダウンロードしてください。

PMDでコードをチェックする

サンプルコードの準備

PMDでコードをチェックしてみます。今回はサンプルコードを作って検証します。サンプルコードはGithubにアップロードしているのでクローンしてご利用ください。

1
2
git clone git@github.com:shoyan/pmd-samples.git
cd pad-samples

PMDの実行

Pmdを実行します。-dがソースコードのパス、-Rがルールが設定してあるファイルのパス、-lに言語を指定します。

1
2
3
4
5
6
pmd pmd -d src/main/java -R rules.xml -l java
3月 20, 2018 6:03:49 午後 net.sourceforge.pmd.cache.NoopAnalysisCache <init>
警告: This analysis could be faster, please consider using Incremental Analysis: https://pmd.github.io/pmd-6.1.0/pmd_userdocs_getting_started.html#incremental-analysis
/pmd-samples/src/main/java/UnusedCode.java:2:        Avoid unused private fields such as 'FOO'.
/pmd-samples/src/main/java/UnusedCode.java:4:        Avoid unused local variables such as 'i'.
/pmd-samples/src/main/java/UnusedCode.java:6:        Avoid unused private methods such as 'foo()'.

3つの問題が検知されています。UnusedCode.javaの2行目を見てみると、使われていないメンバ変数があります。他のエラーも同様に使われていないローカル変数とプライベートメソッドを検知しています。

ルールについて

ルールの一覧については次のリンクよりご覧ください。

0の状態からルールを構築するのは大変です。そのため、PMDのリポジトリには様々なルールのサンプルが定義されています。基本的なルールが網羅されているbasic.xmlを利用するとよいでしょう。他にも様々なルールがあるので参考にしてください。

カテゴリ

PMDのルールはカテゴリに分類されています。例えば、ベストプラクティスであれば、ベストプラクティスに沿ったルールが定義されています。カテゴリの詳細については次のリンクでご覧ください。

トラブルシューティング

PMD6.1.0はPMD7への過渡期バージョンのようで、Deprecatedの警告が山のように出ます。
設定ファイルでしか警告を消す術がないので設定ファイルを修正します。

次のようにdeprecatedをfalseにするか、プロパティ自体を削除してください。

1
<rule ref="category/java/errorprone.xml/AvoidBranchingStatementAsLastInLoop" deprecated=“false" />

参考リンク

Nginxで構築するキャッシュプロキシサーバ

Nginxを使えば簡単にプロキシサーバを構築することができます。手元で動かせるサンプルコードをGithubで公開しています。git cloneしてご利用ください。PCにDockerがインストールされていれば簡単に動作環境を構築することができます。

https://github.com/shoyan/nginx-proxy-cache

キャッシュを有効にする

Nginxのキャッシュ機能はデフォルトでは有効ではないので、設定する必要があります。

/etc/nginx/nginx.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    # キャッシュの場所を指定する
    # levels: キャッシュの階層レベル
    # keys_zone: 使用する共有メモリゾーンの名前とサイズ
    proxy_cache_path /var/cache/nginx/cache levels=1:2 keys_zone=my-key:10m;
    proxy_temp_path /var/cache/nginx/tmp;

    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

次にlocationディレクティブでキャッシュを有効にします。

/etc/nginx/conf.d/default.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
server {
    listen       80;
    server_name  localhost;

    proxy_set_header    Host    $host;
    proxy_set_header    X-Real-IP    $remote_addr;
    proxy_set_header    X-Forwarded-Host       $host;
    proxy_set_header    X-Forwarded-Server    $host;
    proxy_set_header    X-Forwarded-For    $proxy_add_x_forwarded_for;

    location / {
        # 8081のポートで起動しているサーバにプロキシする
        proxy_pass    http://app:8081/;
        # 全てのアクセスをキャッシュする
        proxy_ignore_headers Cache-Control;
        # my-keyというキー名でキャッシュを登録
        proxy_cache my-key;
        # キャッシュは1分間有効にする
        proxy_cache_valid any 1m;
        # レスポンスヘッダにキャッシュがヒットしたかどうかを付与する
        add_header X-Nginx-Cache $upstream_cache_status;
    }
}

以上の設定を行えばキャッシュが有効になります。

キャッシュの詳細な設定についてはNginxのドキュメントを参照ください。
ngx_http_proxy_module

アプリサーバはNode.jsで構築しています。1秒でHello Worldを返す単純なアプリサーバです。こちらもDockerで動作するのでNode.jsをPCにインストールする必要はありません。

プロキシサーバとアプリサーバの起動は次のコマンドで行います。

1
2
3
4
5
6
7
$ docker-compose up
Starting proxycachesample_app_1 ...
Starting proxycachesample_app_1 ... done
Starting proxycachesample_proxy_1 ...
Starting proxycachesample_proxy_1 ... done
Attaching to proxycachesample_app_1, proxycachesample_proxy_1
app_1    | Server running at http://localhost:8081/

1回目のアクセスはリクエストがアプリサーバまで行くのでレスポンスタイムは1秒程度かかります。

1
2
3
$ curl http://localhost:8080 -w "%{time_total}"
Hello World
1.009103

2回目からのアクセスはプロキシサーバがキャッシュしているため、レスポンスタイムが速くなります。

1
2
3
$ curl http://localhost:8080  -w "%{time_total}"
Hello World
0.003797

確認が終わったらサーバを停止しておきましょう。サーバの停止はCtrl+Cか次のコマンドで行えます。

1
$ docker-compose stop