ぷーたんの日記

たまに書く。

サバゲーとは〜

会社のチーム定例LT用に書いてみる。

  • 概要
  • 道具について
  • ゲームの種類について

サバゲとは、BB弾の銃で戦う紳士なゲームである

  • BB弾を撃ち合いながら決められた目標の達成を目指す
  • 目標の種類は結構たくさんある(後述)
  • 当たったかどうかは自己申告(故に紳士たれ)
    • 当たってもゲームを続けちゃう行為は ゾンビ と呼ばれ、絶対やってはいけないとされる。Tウィルスに負けない強い心が必要。

ひとに優しく、自分に厳しく。



道具

絶対に必要な3つ(銃、弾、ゴーグル)を軽く紹介します。

トイガン

電動のエアガンやガスガン、アサルトライフルやハンドガンなど多種多様。 電動ガンだと自動連射のフルオート、単発のセミオートというモードがあったりします。
ただ、法律で弾の威力の上限値が決められているので、ほとんどの銃は威力が変わらないです。故にロマンで選ぶべし。 写真は私が買った、M4CRWです。
M4 CRW - 電動ガン ハイサイクルカスタム | 東京マルイ エアソフトガン情報サイト

BB弾

普通のプラスチックもありますが、基本的に外のフィールドでは生分解性のバイオ弾しか使えません。 大きさは6mmで、重さで0.2gと0.25gと種類があります。
【参考】【初心者参考特集】サバゲで使うBB弾の選び方のアドバイス(基本編) | さばなび
No33 PERFECT HIT ベアリングバイオ 0.2gBB (1600発入)(イメージ)

防具(ゴーグル)

実は迷彩服などは必須ではなく、気持ちを高めるために身につけます。 必須なのはゴーグルです。BB弾でも目に当たれば失明するので、これだけは絶対に注意してつけなければなりません。
【参考】ゴーグルはサバゲにおいての重要アイテム!! 【FIRST ON WEB!】 防護ゴーグル マスク&ゴーグル フルフェイスタイプ メッシュ フェイスガード 緑色(イメージ)

でも、お高いんでしょー?
心配ございません!なんとトイガンとゴーグルは大体どこのフィールドでもレンタルできますし、 弾も買えたり、レンタルにセットで付いてきたりするので、 なんとサバゲ手ぶらでもできちゃうんです!



様々な目標(ゲームの種類)

目的も色々あるんですが、加えて
 (目的)×(フルオート/セミオートを限定)×(復活の有無)= ゲーム
という具合にかけあわせで様々な状況やプレーヤーレベルを想定したゲームが組める感じです。 大体1ゲームが10〜15分で、陣地交代を交代して表裏2ゲーム1セットでやってると思います。 以下一例を紹介

1. フラッグ戦
 一番シンプルなゲーム。2チーム以上に別れ、お互いの陣地にあるフラッグを獲ったら勝ち(大体がブザーを鳴らす)

2. 運搬戦、大将戦
 決められた物を持った(運んだ)人であったり、チームに一人決められた大将(プレジデント)など、フラッグゲットできる人を制限したフラッグ戦です。
重要な人を死なせないようにしながら攻める必要があり、なかなか難しいです。

3. 殲滅戦
 互に全滅するまで殺り合うゲームです。復活ありと組み合わせる場合は、復活した数をカウントして少ない方が勝ちになります。

4. 籠城戦
 フルオート有り復活なしの防衛側と、セミオート限定復活ありの攻撃側に分かれて戦います。

5. スパイ戦
 基本は殲滅戦のルールですが、開始数分後に敵チームとして動き始めるスパイを含めるゲームです。
【参考】(愛知サバゲーFPV視点)Bが赴くサバゲー-スパイ戦- day01{ハッスル - YouTube(2:50からゲーム開始、7:15からスパイ活動開始)


他にもたくさんあります!!
【参考】サバイバルゲームを楽しむためのルール&ゲーム種類!! | サバイバルゲームNO9公式ブログ



FAQ

  • Q.痛くないの?
  • A.近距離でフルオートだと痛いです。
    なので怖いうちは仲間の後方支援をしたり、自陣の防衛から入って、慣れてきてから前線に突撃してみたりすると良いかもです。

  • Q.どこでできるの?
  • A.専用のフィールドに行くとできます。千葉の印西に多いです。都内にもありますが、郊外に比べると高くて狭いです。
    サバイバルゲームフィールド一覧 関東編

  • Q.高くないの?
  • A.スノボほどは高くないですw
    場所にもよりますが、千葉だと大体朝から晩まで遊び尽くして参加費3〜4,000円、レンタルが1〜3,000円くらいだと思います。

  • Q.どういう人に向いてる?
  • A.飽くまで個人的な印象ですが、こんな人は楽しめると思います!
    • 缶けり、隠れんぼが好きだった
    • 身体と頭を同時に動かすのが好きだ
    • 好きなアニメのキャラが愛銃を持っている
    • 好きな映画の中に銃撃戦がある
    • 少年の心を持っている
    • アーミー格好良い



最後に

コアな人しかいないイメージを持っている人もいるかもしれませんが、 実際私のようなライトなショボゲーマーもいれば、キュートなお姉さんもちらほらいたりして、 ゆるくてもなんとかなるようにフィールド側のスタッフが色々なゲームを回してくれます。

なので気軽に1回ためしてみてはいかがでしょうか?


frontrend 行ってきた。

こちら。初めて行くけどfinalとのこと。
こういうの聞きに行くと勉強不足が身に染みるんですが、モチベーションが上がるので老体に鞭打って参加して来ました。
jsセッションとcssセッションとあってjsだけ見てきたのでそれらをまとめます。
たまに話を飛ばすのはバグではありません、私の仕様です。




基調講演 by 斉藤 祐也


スライド

どんな人が書いても、一人で書いたようになるべき

js, css, html のスタイルガイドやツールガイドラインを公開している企業など。

実際に見えるもの、動くものに対しての意見は言いやすい

だからプロトタイプで見せよう。

  • tools

変化に寛容に

  • Progressive Enhancement
    • エスカレーターって、壊れて動かなくなっても階段として機能する(これな)
  • Cut The Mustard
    • jsで特定のobjectの有無で判定するあれ
  • コンポーネント単体でぷろぐれっしぶ

優秀なエンジニアの共通点

  • 哲学を持っている
  • 概念を形にできる
  • ディテールにこだわる
  • でも前提条件が変わればそれも捨てられる

どこが正しいかじゃなく、流れを感じて変化を読み取るのが大事。
好奇心は猫を殺すかもしれないが,フロントエンドエンジニアは救うかもしれない。

Be Expart

  • できないと言わない、オプションを提示する
  • 割れ窓の中で仕事しない
  • 「十分」がいつなのか知る
  • 知識を増やすための時間を定常的に設ける
  • コミュ力

専門性を発揮できる人は自分以外の領域についてもよく知っている

未来に先回りして点と点を繋げて見ることはできない、君たちにできるのは過去を振り返って繋げることだけなんだ。だからこそバラバラの点であっても将来それが何らかのかたちで必ず繋がっていくと信じなくてはならない。 -- Steve Jobs

eny keywords

  • isomorphic javascript
  • Webは絶えず変化し続ける

感想

よくわからなかったのも多いから徐々に調べて勉強しよ





Reactive Programming in JavaScript by 佐藤 歩


スライド

what is

イベントや値の関係性に注目したパラダイム
RPはデータフローの関係性を宣言する

  • Actor Model
    • 非同期な並列処理をいいカンジに説明するモデル
  • Functional Reactive (FRP)
  • The Reactive Manifesto
    • Reactiveなアプリケーションの特性をまとめたやつ
  • Reactive Streams
    • 非同期ストリーム処理を標準化しようというもの

Reactive in Frontend JavaScript

FRP

  • Reactive Extensions(RxJS)
    • FRPなライブラリシリーズ(js以外もあるよ)
    • 全ての値や入力を非同期データストリームとして見なす
    • 絶望するほどの数のインターフェイスがある
      • 要点を絞ればなんとか使える
        • transforming.map 流れてきた値を変換する
        • filtering.filter 流れてきた値でOKなものだけ通す
        • comvinaing.merge 2つの流れをマージ
        • transforming.flatmap 変換して流す
        • catch エラーをつかんだら新しい値を返す
  • 他にもあるよ
    • Beacon.js
    • Kefir.js
    • Meteor
    • Elm

おすすめ文書

感想

シーケンス図的な形でロジックを組み立てるものっぽい。
ブラウザの動きを当てはめやすい -> 形にしやすい -> 読みやすくメンテしやすいコードが書ける、といった具合?

あとライブコーディング的動画が良かった!





Introduction to React by 外村 和仁


スライド

react.js

fbが作ったライブラリ(フレームワークじゃない)

特徴

ステートレス

  • jQuery
    • 状態がDOMにしか無い。拡張性がないしメンテしにくい。
  • Backbone.JS
    • Viewをコンポーネントに分けて、データやロジックをModelに持つので少しましになる。
    • が、相互作用関係を全部手で書く必要があって管理しきれなくなる。
  • angular
    • コンポーネント(ディアクティブ)ごとに状態を保つと辛くなる。
    • アプリケーションが複雑になると辛くなる。
  • react だと
    • ステートレスコンポーネントコンポーネントがデータを極力持たない
    • これで、テスト、メンテ、再利用がしやすくなる
    • 一番親だけに状態を持たせる、親からの情報をもとに子が処理をする

virtual dom

途中の処理は仮想DOMで、最後に必要な部分(差分)だけをレンダリングするようにして速度を速くする

server side rendering

  • jsを解釈できないマシンから読めない(SEO的な)
  • 初期表示だけサーバーでやって、更新をjsにわたす
    処理を重複させないように、初期表示もjsを使ってサーバーでやる

flux

  • 設計手法(考え方)の一つ
  • 末端のDOMのイベントがルートのステートを変更するという話をしたが、そこで使うのがFlux。

flow

  • すごい高機能なlint
  • babelのほうがいいかも

まとめ

  • scalableだよ
  • でも小規模速攻型じゃないよ(めんどくさい、大規模向け)
  • これみて勉強したらいいよ

感想

statelessの考え方は良さそうだった。RPじゃなくても使えそう。
flexについては別途調べる。





Introduction to ServiceWorker by 泉水 翔吾


スライド
モバイル化してきてるから、通信量抑えたり、オフラインでもいけないとね

オフラインファースト

オフライン前提のwebapp

    • ネットワークより高速(キャッシュだから)
    • ネットワーク、サーバー側を圧迫しない
    • オフラインやネットに繋がりにくいところ(地下鉄とか)でも使える
  • ×
    • リアルタイム性は弱い

実現する技術

  • navigator.online
    • オンラインの判定、イベント
  • filesystem
    • 大きなファイル保存、非同期型、chromeだけ
  • webstrage
    • key-value、少量データ保存の同期型API(〜5MB)
  • indexedDB
    • key-value、少量データ保存の非同期型API(〜5MB)
  • Application Cache
    • マニフェストファイルでキャッシュを定義する
    • 動的ページは苦手、いろいろ制約がある
  • service worker
    • やっと主役

service worker

高機能なローカルプロキシ

  • httpリクエストの検知と改竄
    • httpリクエストを勝手に返せる
  • fetch API
    • xhrより低レベルのリソース取得API
    • サーバーからデータを取ってきたりする
  • Cache API
  • Background Sync
    • オンラインの時だけイベント発生する
  • Web Push API
  • httpsが必須
  • chromeとff、androidなら使えるよ

感想

リアルタイム性が求められないところではどんどん取り入れていったほうがよさそう。 対応ブラウザが狭いから業務では使えないかな。。。





JavaScriptテストの疑問、お答えします。 by 吾郷 協


スライド

  • テストは必須、どこを、どこまで、自動化するかを考える

Q: どこまでやればいいの?UI以外?
A: 不安ベースでやる。不安なところは書く。UIのテストはいけない訳ではなくコストが高いだけ。

Q: どこからはじめれば?
A: E2Eテストの自動化からが入りやすい。Unitテストはコードの品質に依存して難易度があがるため。

目的を持ってテストを書くべし

オススメの目的

  • 自分の不安
    • 安心できるところまで、自己満にならないように。
  • 他人の不安
    • 信頼感が大事
  • 手動の自動化
    • テスト準備の自動化でもいい、効果も説明しやすい。
  • 勉強、趣味、見栄
  • 複数環境
  • リグレッションテスト
    • バグが出た時だけテストを書く
  • ドキュメントの代わり
    • 主なAPIだけ、細かく書き過ぎない。他のテストとは分離する。
  • 知識の共有として
  • 設計として(TDD的)

目的にあったテストをしよう(目的を明確化させる)
手法はどうあれ、目的を達せられれば勝ち。

テストを書く文化

  • 技術より文化がない方が導入が大変
  • 最初は不安の可視化から

事始め

  • assertから
  • よく止まるところはあぶない -> 切り出してテスト

無理しない

  • 少しずつやる
  • 無理だったら引き返してもOK(基盤は残す)
  • 費用対効果もちゃんと見る

ツール

  • mocha or jasmin 合わなければ QUnit
  • powerAssert
  • E2EはProtractorが強い、testiumにも期待
  • ランナーはtestem、大きければkarma
  • Isomorphicなコードはテストしやすい

テスト振り返り

  • そのテストは本当に役にたったか?

コードカバレッジ

  • ただカバレッジを出すのはニセの安心感でごまかすモチベーションになりうる
  • 未テスト部分の把握にはいい

感想

現実的な視点でのテスト導入についてが語られてて良かった。 どういった不安を解消するためにやるのか、ちゃんと考えたい。




体力的に限界を迎えたのでここで帰宅しました。。。

話題のReactについても聞けたし、他のも大変興味深かったです。
勉強せねばー