Diary

@ssig33

31/Dec/2016 (Sat)

年末なので Github で Star が多い Go のコード読んでる。 Go はわりと見様見真似で適当に書いてるのでたまにこういうことすると楽しい。

00:00

29/Dec/2016 (Thu)

今年買って微妙だったもの 10 選

Qtuo 金メッキコネクタ搭載1080P HDMI オス to VGAメスビデオ変換アダプタケーブル PC DVD HDTV用

出力先ディスプレイによって映ったり映らなかったり。そういうレビュー多いのでこれはそういうものっぽい。この手の商品はだいたい博打。

MOGU 補充用パウダービーズ 500g 822093

補充自体は成功して非常によかったのだけど、かなり注意深くやった結果やはりビーズの一部がゆかにぶちまけられる結果となった。覚悟はしてたし、想像してたよりずっと楽に掃除はできたけど。

掃除機で吸ってもどうにもならんので粘着テープのコロコロするやつがあるといいです。

ロゴス 着火剤 防水ファイヤーライター

木炭の着火剤。着火剤としての性能がまず文化たきつけと比較して大きく劣る。そしてそれ以上に致命的な欠点が、これ非常にぼろぼろと崩れやすく、室内で扱おうものならその辺がみんな着火剤の屑にまみれることになる。

文化たきつけを買った方がよいです。

オーム電機 カメラ一脚 3段階伸縮 540-1710mm OCM-001 OCM-001

耐久性に問題がありすぐ壊れた。

久順銘茶 謝さんの香る烏龍茶 凍頂四季春茶 80g

正直これそんなにおいしくない。凍頂四季春茶であって凍頂烏龍茶でないことを見逃していた点が失敗だったと言える

首・肩への負担軽減 【もちふわ エアチップピロー】 低反発チップまくら 枕 ホワイト Sサイズ 約35×50cm

枕に関しては合う合わないあるのでインターネットで買うべきではないなと思った。これの前に使ってたやつが本当にあわなくて辛かったので焦って買って失敗した。その後ニトリでやすいけどあうの見つけてよくなった。

【Spigen】 iPhone6s Plus ケース / iPhone6 Plus ケース, リキッド・クリスタル [ ソフト TPU クリア] アイフォン6s プラス / 6 プラス 用 カバー (クリスタル SGP11642)

大きな iPhone 6s Plus にこういうケースをつけるともう始末に負えない。結局すぐ外した。

Anker® タブレット用スタンド 角度調整可能 iPad・iPad mini・Nexus 7等に最適

スタンドとしては非常によろしく満足しているのだけど、意外と重くでかいので鞄に入れると、、、という感じ。これと iPad とキーボードを持とうものならたいていの PC ぐらいの重さになってしまう。

拠点ごとに複数買っておいておくみたいな使い方だといいと思う。

デイヴ・アスプリー - シリコンバレー式 自分を変える最強の食事

これは非常に危険な内容。人間が飢えているときの緊急事態モードを日常的に使おうという内容。どのような機械であれ最大出力を常時使ってやっていけるようには出来てないし、人間も例外ではないと思う。死ぬ気で頑張れば死ぬのでこういうことはしないほうがいいと思った。

20:41

28/Dec/2016 (Wed)

定期的に wget して CloudFlare あたためるみたいの規約的にはアリなのかな

00:50

27/Dec/2016 (Tue)

インフラエンジニアのいない会社で働いて 1 年半 が経った。 iOS で動く POS レジアプリとその管理インターフェイスの Web アプリケーションを作ってます。 iOS 側のことはほとんど分からなくて、データ同期用 API と Web アプリをずっと作っている。

ところで、 「NoOps」の時代がこない理由という記事が前にあったのですが、この点ぼくが働いている会社は NoOps です。アプリケーションは Heroku に乗っていて、 RDBMS が Amazon RDS で一部分析系に Google BigQuery を使っていること以外は全て Heroku 系の何かで動いています。

CI は Travis と circleCI を使っていて、 circleCI については来年初頭にも利用をやめて Travis に一本化する予定、というかんじ。

本当に自分達でなにもサーバーを管理していません。

これでやっていけているのかというと、まあやっていけています。 Heroku 使ってるからダメ〜みたいな感じの失注があったのかどうか知りませんが、まあそういう店舗はそもそもデータの置き場がベンダー側にしかない POS レジサービスを選択しないだろうと思う。

開発体制とか社内環境とかはさておき業務ドメインとしては割とおかたい感じのことをやっていますが、 NoOps でまわってます。

というわけで Heroku/NoOps で辛かったことと辛くないこと

  • Redis To Go という Heroku Add-on が極めて不安定だった
    • これ由来の障害が多発したので、 Heroku Redis に移行したら解決したみたいのがあった
  • Heroku Scheduler がたまに動かない
  • サービス名わすれたけどサポートチツールみたいなやつが 5 文字以上の TLD にメール送れない
    • shit@fuck.tokyo みたいなアドレスで死ぬ、この問題どうなったか忘れた

意外と辛くなかったこと

  • Heroku はアメリカ/ヨーロッパにしかサーバーがないので往復で時間無駄になる
    • これが嫌で Heroku 捨てる人達多いみたいだけど、これが嫌になるくらいチューニングされてんのか?
      • とはいえうちではチューニングが最近進んだのでそのうちこれが嫌になるかもしれない

自分達でサーバーメンテしてる故の強みみたいな話をする人達がよくいるけど、具体的にそれがなんなのか話してくれる人は意外と少ない。ロックインされてるデメリットはあるんだけど、まあ Heroku 捨てるってなったらそれはそれで半年もあればできるでしょう。

18:21

gulp はクソというのがもっとこう初心者にもリーチするようになってほしい

12:29

24/Dec/2016 (Sat)

バーベキュー

img

バーベキューとは何かということをアメリカ南部の田舎者に聞けば、おそらく肉を木で長時間スモークすることと答えると思います。今日はそういうことについて書きます。

バーベキューというのは日本では屋外でする焼肉みたいな意味の言葉ですが、上記のとおりアメリカでは肉を長時間スモークする料理であり、南部の郷土料理といえるでしょう。

img

この料理は一般にブラジル人の肉をローストする技法と、西アフリカ系の黒人の窯焼き料理の技法が組み合わさって完成されたといわれています。ただ、南部といっても奴隷と裕福な農場主だけがいたのではなくて、貧しい白人労働者もたくさんいたのですし、彼らがイギリスから持ち込んだサンデーローストの文化、技法の貢献も無視してはならないと思います。

実際、人種隔離時代の南部においても綿花収穫後などに盛大に行われるバーベキューの場においては人種の垣根が払われたそうです。バーベキューのみが南部において唯一人種を越える文化だったわけです。

img

ロースターの中には水皿を入れることが出来ますから、バーベキューという料理は要素技術としては以下のみっつに分解することができると思います

  1. シーズニング、ソースなどによるマリネ
  2. 低温調理
  3. 燻製
  4. 蒸し焼き
    • 酒蒸し、ワイン蒸し、ビール蒸しになる場合もあり

最近は銅蟲の影響で日本でも低温調理が再びブームになっていますから、皆さんの家に Anova やそのたぐいはあると思います。これで低温調理された肉に燻製の風味をつけることが出来ればバーベキューですから、さらにスモークガンを用意することで家が狭い皆さんもバーベキューを再現できるかもしれません。

img

幸いにして僕の家は(相対的には)広く庭があるので(一方で築 51 年に達しています)そのあたりの知識はあんまりない。

というわけで燻製などの話。

木には様々な物質が含まれており、これらは燃焼の際に様々な変化を起こしながら空気中にばらまかれます。これら化合物の香りを我々は通常煙の香りと認識します。また、肉からでた油が炭などに着いた際にもまた化学変化が起こり、この風味が肉に再び付着します。これらの作用によりバーベキューにおいては単なる真空低温調理よりも風味の深まった肉を得ることが出来るわけです。

img

そろそろ書くの飽きてきたわ。むろん温度管理などは Anova などよりはるかに難しいのでいろいろやっていく必要がありますが、毎週末やってればまあ 3 カ月ぐらいでものになると思います。その程度の技術だということです。

img

魚もこういう技法で処理していくことが出来ます。温度管理は肉より難しいです。

img

豚の肩ロースのバーベキューを一日冷蔵庫で保管したあと薄切りにしたものです。ロースハムなどのように使っていくことができます。燻製にしてるので一週間ぐらいかけて食べて大丈夫だと思う。サンドイッチにするとよいです。

img

具体的な技法は Youtube で BBQ とかで検索するとか、 Kindle で Texas BBQ Recipe とかで検索してでてきた本読むとかしてくれたらいいです。俺は解説したくない。

というわけで毎週末バーベキューをやると生活が改善するという話でした、終わり。

13:05

23/Dec/2016 (Fri)

うー

00:29

Docker イメージの最適化問題

前提 1. 実行環境は頻繁に捨てられる

  • オートスケールでの増減
  • CodeBuild 使う場合とか
  • サーバーの故障、不具合
    • ぼくが使ってるゴミクラウドみたいなやつではすっげー頻繁におきてる

前提 2. 面倒なことはしたくない

そりゃまあね。

すると?

綺麗に作られた Docker イメージはベースとアプリケーション固有部分が分離していて転送が最適化されるみたいな話はあるんですが、それはそうとして頻繁にベースごと吹き飛ばされるという環境で生活している人は多いのではないかと思う。

このような情勢のもとではいろいろ頑張って最適化したところでダメなときはダメだしみたいな話になってくる。

というわけでなのでこのへんあんまり神経質にやる必要はないと思う。普通に書けばまあ普通にある程度キャッシュされますよ以上のことを考えなくていいんじゃないかな。そういうところ神経質に気にしたい人は Docker 使わないほうがいいと思う。ただまあこのへんコストの判断基準をどこに置くかなので最終的には殺し合いになります、

golang:latest でビルドしたバイナリを alpine-glibc に突っ込むぐらいのビルドパイプラインだと複雑さはかなり低いと思うのでそれはありかなと思うけど、

という話です。ちなみに @ChimpoKnights さんは AWS Lambda と AWS CodeBuild で動いています。

00:28

22/Dec/2016 (Thu)

git のブランチ名 bash に出すやつ適当に設定したら補完の表示壊れてだるい

01:03

体調終わってる

01:00

21/Dec/2016 (Wed)

direnv 的な感じであるディレクトリ入ったらコマンド自動実行みたいな存在がほしい

03:05

nvm の遅延ロード的なことがしたくて、 direnv とか使ったらいいんですかねえ

03:03

もうちょっとどうでもいい感じで書いていくべき

03:02

zsh 捨てた

Windows 環境でデフォルトシェル変えられない問題があり、なんだか Insider Preview で追加される機能見るとデフォルトシェルの問題については期待しないほうがよさそうという状況があった。ここで自分の zshrc 見てみると別に zsh じゃなくてよさそうなもんしか書かれてない。ということでこの際なので bash に移行した。

bash-completion 入れてプロンプトに git のブランチ名出すようにしたらとりあえずやっていけてよかったと思う。 9 年以上継ぎ足された zshrc から必要なものピックアップできたりしたのもよかった。

zsh じゃないとダメ、みたいな人( predict-on の人とか)実際そんなにいなくて bash にしたらしたでやっていけると思うので、シェルの設定整理ついでに bash に引っ越すのもいいんじゃないでしょうか。

とはいうもののディストリビューションの都合だかでこんなことするのはクソだ。

03:00

16/Dec/2016 (Fri)

ローグワン見てきた。

誰が予想してたよりもサクサクキャラは死んでいく感じでそこは非常によい。

が、精神が弱い中間管理職のオーソン・クレニックが失態を散々ターキン提督やダース・ベイダーに詰められまくり、最後は見捨てられ死んでいくというかなり厳しい内容となっていた。技術分からんのに大技術プロジェクトのマネジメントを最低限未満の管理人員(デス・トルーパーは 100 人もいないように見える)で押し付けられるというのもなんとなく IT デスマーチと同じ哀愁がある。

ただ最後の最後でクレニックが諦めたような、幸せなような表情をしていたのがかなり印象的で、こういうところにギャレス・エドワーズではなくトニー・ギルロイの手が入ってんだろうなというのを感じた次第です。

とかなんとか。なんにせよギルロイが直してくれてよかったなと思います。ギルロイいなかったら爆発爆発ダースベイダーみたいな感じの、ゴジラ 2014 ぐらいの適当な映画になっていたものと思われる。

15:40

15/Dec/2016 (Thu)

Docker Remote API でローカルディスクマウント しようとすると、当然そのリモートのディスクマウントしようとするので、いろいろと困ってたんですが。

ローカルとリモートのあれこれを同期しとくとか、リモートに NFS かなんか建ててローカルではそっちみるとか、逆にローカルに NFS 建てるとかなんとかしていけばある程度解決するということに気づいた。

だいたいやりたいこととしてはこんな感じです。

  • ファイルはローカルに置きたい
  • テキストエディタもローカルで実行したい
  • しかし巨大な開発環境をローカルに置きたくない

ということでいろいろやっていってよくなった。とりあえず rsync で同期させるようにしました。

18:08

14/Dec/2016 (Wed)

ssig33com の RSS にこれ混ぜた

18:51

書いてた内容消えるとテンション下がるな

18:21

変な自前キャッシュ機構使っててクソなので Varnish にしたいところ

18:13

12/Dec/2016 (Mon)

papertrail 高いし普通に自分のサーバーに集約サーバー建てたらそれで十分という感じになった

16:06

09/Dec/2016 (Fri)

CloudAtCost いい加減やめたほうがいいかな。

19:41

DeNA の話

img

ようするにまだ黒字にはなってなかったわけでして。

  • インターネットはゴミだらけ
  • ゴミ記事生産するワーカーは低賃金長時間労働
  • DeNA も別に儲かってないからうれしくない

という状況だったし、これの 4 は事実に即した話なわけです。 MERY 持ってる DeNA がこの状況なんだからその他有象無象の金まわりなんて知れたもの。

そういう話は別として、こういうゴミサイトが一掃された検索結果がどうなるかというと、ゴミどころかなんにも情報がない日本のインターネットという状況が明らかになってくるんではないかと思う。

みんなもう、インターネットでいろいろものを書くことに飽きてて、新しい世代は別に情報を公開することに積極的ではない(グループチャットその他で情報需要が満されているからパブリックになにかする必要はないし、またパブリックの情報をあまり求めもしない)。

12:53

06/Dec/2016 (Tue)

builderscon の資料

PDF

img

img

img

img

img

img

img

img

img

img

img

img

img

img

img

img

img

img

img

img

img

img

img

18:34

AWS CodeBuild をちょっと触ってみた

フルマネージドのビルドサービス という触れ込みで、実際まあその通りなんだけど、これはあくまでもビルドツールであって CI ツールではない。出来ることはビルドだけ。

なので Amazon Travis 的なサービスではない。 AWS CodePipeline や Lambda や API Gateway などと組合せることで一気通貫の CI 環境を構築することはもちろん可能だが、大抵の場合において Travis に金を払ったほうがいいと思う。 Jenkins おじさんならぬ AWS CodePipeline が発生してしまう。

ビルドタスクが大量にあり Travis なり Jenkins なりのレーンが頻繁に逼迫してる会社ならばこれらサービスを使ってやっていくコストをペイできることでしょう。

一方で個人が Github の Private リポジトリの master を継続ビルドする、ぐらいならまあ一瞬で構築できるし安いのでそういう用途ならアリです。

ということまではまあ Amazon 側が想定してる使い方だと思うんですが、これすごく便利です。

これ何に使えるかというと、時間課金の Docker コンテナ実行環境として使えます。

  • 何らかのイベントに応じて短時間大火力の CPU を使いたい
  • cron で Docker コンテナを起動してなにかの処理をしたい

みたいなことは比較的頻繁にあると思います。僕は結構いろいろあります。これを実現するためには、これまで AWS では、事前に十分な量のインスタンスを用意しておくとか、正直とても人間の使うものとは思えない EC2 Container Service の使いかたを習熟するとかいったことが求められてきました。

しかし、ポート公開の必要のないコンテナであれば、 CodeBuild の Build specification で

phases:
  build:
    commands:
      - docker run SOME_IMAGE

とかなんとか指定しとくだけで、 CodeBuild の高性能な実行環境で実行できます。あとはこの Build Project を lambda かなにかから必要に応じて叩いてやればよいだけです。

lambda とあわせて利用することで非常に安価なバッチ実行環境が手に入ります。さっそくいろんなバッチをこれに乗せて遊んでいる。

00:27

05/Dec/2016 (Mon)

Gitlab の管理がだるくなったので Github に金払って Private リポジトリ全部そっちに寄せた

  • そもそも Gitlab が載ってるだけのサーバーに月 1000 円払ってたが Github は 7 ドル
  • セキュリティ的に GMO と俺のコラボレーションが Github を上回ってるとはとても思えない
  • Gitlab 遅い

とかなんとか。やってみるとすっかり快適になってよかった。

20:12

04/Dec/2016 (Sun)

ダイアナ・エクストラバガンザの動画見まくってた

15:15

03/Dec/2016 (Sat)

builderscon

スピーカーはただでトークを聞いてメシを食えるというので適当に応募したところ採択された。 docker swarm mode の話をした。スライドはこちら。初級者向けみたいなタグをつけていたが、 HA 構成やってる人とか docker やってる人とかじゃないとわからない話になってしまったというのがあり、反省があります。まあ、なんのことかわからなかった人はとにかく Heroku か GAE 使ったらいいかと思います。

イベント全体の話。

会場の都合で飲み物は水かレッドブルしか飲めないということになっていた。これはかなり辛い。予算抑えるためとかなんとかいろいろあったと思うし、快適な会場だったのだけど、とにかく良くなかった。人間性に関わってくる。

質疑応答の時間がきちんと確保されてないのはあまり良くなかった。ただこの点については個人的には反省があり、タイムテーブル見た時点でそうだと分かってたのだから 15 分ではなく 10 分でトークを作るべきだったと言える。

あとはよかったです。

各種トークの話題

思い出した順に書いてるので順不同です

  • 工場の人をリモートで管理していると中国で泥酔することになるという話は今日の優勝だったと思う
  • Arduino で昔のパソコンを作る話は壮絶だった
  • キーボード自作は単機能キーボード云々っていうか普通の USB HID から始めるのがよさそうと思った
  • CSS設計を破綻させない的な話は今ちょうど自分の会社でそういう話になっているところで、チームメンバーとの意思疎通と思想の交換というのは非常に難易度の高いことだという実感が僕にもあります
  • emscripten 作ってる人たちが emscripten の用途あんまり思いついてないし事例も知らないみたいのは結構驚いた
  • MVVMパターン、Fluxアーキテクチャの話はデータの更新経路が限定されてれば巨大なグローバル変数でアプリ作って問題ない、という話収斂してくるかと思う

懇親会

様々なことがあったかと思います。以上です。

23:27

Docker Swarm Mode の話(タイトル変えた)

おもしろい話をしようと思ったのですが、 15 分しかないので素早くやっていきます

結論

  • 今すぐ Docker ベースで HA 環境を作らないといけない
    • use Kubernetes
  • ベンチャー企業でインフラのコストを低減させたい
    • AWS や GCP が配ってるクーポンは無視して Heroku 使うべき
  • デプロイが趣味の人
    • この場で Docker Swarm Mode を使いはじめるべき
  • それ以外の人
    • Docker Swarm Mode にのんびり注目してみるといいです、全てが変わる可能性を持っている


Kubernetes と比較した時に

Docker Swarm mode が優れている点


Kubernetes の基本的な構成

img 引用元: kubernetesによるDockerコンテナ管理入門 - さくらのナレッジ


Docker Swarm Mode の基本的な構成

img 図作成: ssig33


優れていない点については後で話す

いろいろある


Apache Mesos + Chronos + Marathon の基本的な構成とか図を作りたくない

Docker Swarm Mode は名前に Apache という文字列が含まれていないというメリットがあります


Docker Swarm Mode とはなにか?

コマンド例を見ると一発でどういうものか分かります


クラスタのマスターノードの構築

$ docker swarm init
Swarm initialized: current node (ID) is now a manager.

To add a worker to this swarm, 
run the following command:

docker swarm join \
--token #{TOKEN} \
#{IP アドレス}:2377

クラスタにノードを追加

$ docker swarm join --token #{TOKEN} #{IP アドレス}

めっちゃ簡単!!


サービスを開始

Docker Swarm Mode ではアプリケーションの実行単位をサービスと呼びます

$ docker service create \
  --publish 80 \ 
  --name #{SERVICE_NAME} \
  #{IMAGE_NAME}

サービスのアップデート

$ docker servce update \
--image #{IMAGE_NAME}:#{TAG} \
#{SERVICE_NAME}

スケーリング

$ docker service scale #{SERVICE_NAME}=5

サービス作成時にこのサービスは全ノードに展開みたいな指定も可能

$ docker service create --mode global #{IMAGE_NAME}

典型的なありかたとしては、

  • Web アプリを global でデプロイ
  • 各種タスクランナーを必要数だけデプロイ

みたいな


ノードのラベリングとデプロイ先制約

# ラベル作成
$ docker node update --label-add #{KEY}=#{VALUE}

# サービスに制約を追加
$ docker service update --constraints-add \
  node.#{KEY}==#{VALUE} #{SERVICE_NAME}

# 否定とかももちろん可能
$ docker service update --constraints-add \
  node.#{KEY}!=#{VALUE} #{SERVICE_NAME}

これにより、複数リージョンのサーバー群を単一のクラスタとして 扱いながらサービスを適切に配置みたいなことが簡単に実現できる


サービスディスカバリ/負荷分散とかどうなってるの?

サービスがポートを公開すると、クラスタ内全部のノードにおいて、 そのポートが公開されます

複数のノードに分散されてデプロイされている場合でも 適切に負荷分散されます

Application Load Balancer やオートスケールと非常に相性がよい

ただし現状この挙動に致命的な問題が、、、(後述します)


結果何が出来るか

オレオレ Heroku/GAE が数分で構築できる、すごい!!!


そんなに何でも都合よく行くか


現状の問題点

  • サービスディスカバリ/負荷分散が全く正しく動いていない
  • たまにノードが行方不明になる
  • 単発実行のタスクのデプロイが困難
    • 当然ジョブスケジューラーもない
  • MySQL 置き場が難しい
    • 例として MySQL を挙げましたが、 ファイルの永続化が困難だという話
  • 複数のサービスをひとまとめにして管理する機能がない
  • ログ管理がない
  • いろいろ undocumented

対策

  • サービスディスカバリが壊れてる件については 前段にロードバランサを置けば対応可能
  • ノード消滅は死活監視入れてなんとかしましょう
  • ファイルの永続化困難な点は、今のところどうにもならない
    • ボリュームがマウントできないわけではないので、特定ノード 固定とかいう置き方でいいなら大丈夫
    • パフォーマンスあんまり必要ではないものなら glusterfs なども選択肢に入る
  • ドキュメントに無い困り事については Github の issue を眺めればだいたい解決する
    • 貢献チャンスかもしれない(僕はやりたくない)
  • ログは docker service log というのが実装中
    • 僕は今は logspout + papertrail で運用中

現状どれくらい使い物になるか?

  • 僕の個人サイトとデーモンは全部 Docker Swarm Mode にのっている
  • 企業内のテスト用インフラぐらいなら、、、

面倒だったので説明を省いたこと

  • メモリや CPU の予約機能はあります
  • ネットワークを作成してやっていくことはできます
  • グレースフルリスタートその他かしこくアップデートができます
  • 認証つき Docker Registry を適切に扱えます
  • ログドライバを指定可能です
    • これ logspout に比べて全然便利じゃないと思う
  • *****という問題があるのでそこが心配の方は使わないほうがいい
    • 会場の皆さんにだけ話します

まとめ

  • Docker Swarm Mode は Heroku もどきを一瞬で作れるすごいやつ
    • とにかく簡単ですごい
  • 大抵の人がほしいものはこれだったのでは?
    • 顧客
  • Kubernets の Pod とかいらんやろ
  • 安定性は酷く、まだ全然 Production Ready とは言えない

自己紹介

  • Name: @ssig33, 小池陸
  • 普段は Heroku にインフラ全部任せる会社で働いている
    • インフラエンジニアではないし インフラエンジニアだったこともないです
16:25

02/Dec/2016 (Fri)

Titanfall 2 の賞金稼ぎについて

メニューの表示上でデフォルトルールみたいな位置になってるので一番人口が多いですが、かなり独特のルールとなってます。

一見チームデスマッチ風ですが、全然違います。

  1. AI を狩ることで賞金を得る
  2. その賞金合計が一定値を先に越えたほうのチームが勝利
  3. 賞金を持ってる状態でプレイヤーに狩られると賞金の半分を奪われる
  4. AI はウェーブで来るが、そのウェーブが終了するごとに銀行が開かれ、賞金を入金できる

というシステムになっています。ですからプレイヤーを狩りまくる超絶 FPS の達人みたいな人よりも、 AI を狩りまくり対人を極力避けて確実に賞金を入金していく人のほうが勝利に貢献します。

ですから、

  • 撃ち合いが下手な FPS 初心者であれば立ち回りを慎重にしながら AI を確実に狩る
  • 撃ち合いが上手い場合は賞金を狩りつつ、銀行に入金に来た敵プレイヤーを狩ることで一攫千金を狙う

というようにするとよいかと思います。まあいろいろあるけど。単にプレイヤー狩りしてるだけだとあなたは置物未満の存在になるので注意してください。

19:07

Next