光有利古戦場終了

今回は予選51m、累計201mでした。

編成

肉集め

キャラ メイン クリュ ミスト、アーセ、デュアル→ミストは34押したいから置いてるだけ 最終ソーン 水着ノイシュ 恒常ジャンヌ

サブ シルヴァ 最終エッセル

武器 メイン ヴァッサー 魔獄 方陣終末 4凸チェンバ シュヴァ剣 4凸x5 コスモス剣 4凸 ゼノ剣 天司 3凸→黄竜麒麟HL連戦やる暇ない

石 メイン シュヴァ 4凸 スター 5凸 バハ 5凸 サン 5凸 アグニス 4凸

フレ石 ルシ 5凸

ジャンヌ2→ノイシュ3→ソーン1→デュアル→アーセ ソーン1なくても9割ぐらい落ちてたかも 団サポある時間はジャンヌ2とソーン1抜いて3ポチ

90hell

キャラ メイン レスラー クリア、ミスト、ツープラ 恒常ジャンヌ フェリ リミヴィーラ

サブ 適当

武器 メイン プリキュア拳 あとは肉集めと同じ

石 肉集めと同じ

ルシ→ヴィーラ13→ミスト→ツープラ シュヴァ→フェリ3→クリア

普段セレマグやる時と同じ感じ

95hell

キャラ

メイン グロ ミスト、グラビ、コロミ 恒常ジャンヌ シャルロッテ ルシオ

サブ 猫 みりあ

武器 メイン ゼノ剣 無垢剣 あとは肉集めと同じ

石 肉集めと同じ

適当にバフデバフして殴る

100hell, 150hell

キャラ メイン ベルセ ミスト、レイジ4、アロレ あとは95hellと同じ

武器 95hellと同じ

石 肉集めと同じ

だいたいフルオート 今回初めてフルオート使ったんだけど、楽でいいね。

bmの話

O鯖で活動しているてくさんです。某ポポリン好きな人と同じGに所属しています。

アドベントカレンダー向けに記事を書くことになりました。 adventar.org

お題はタイトルの通り、bmについてです。このお題にした理由は、他の人がやらないようなことをしていると思ってるから、です。何か便利ツール(MD行ったカレンダーとか)を作って公開!というのも考えたんですが、そういうのは他の方がやりそうかなあと思いまして。

基本的にGvでbmを使う想定の話になっています。狩りでbm使うのはABを動かす時ぐらいで、他の職では使いません。

では、bmの配置の例を貼ってみます。 f:id:txdrum_reflect:20191220225425j:plain

4以外は右寄りの配置になっています。たぶん一般的にはもっと左寄りの配置なんじゃないかと思いますが、何故そうしているかというと「マウスを左手で操作する」からなんです。

昔drumsを習ってた時に左手で色々やろうとしていた時期があり、その時にマウスを左手で操作するようになったのがきっかけなんですが、今もそうしているのは以下のようなメリットがあるからですね。

  • 右利きなので非利き手の左手の方が余計な力が入らないからちょっと楽
  • 2PC同時操作の為に両手でマウスを使える

「マウスを左手で操作する」のでキーボードは主に右手で操作します。viのホームポジションであるHJKLに指を置いてそこを起点にして指を動かします。

  • 1
    • Bにサイトを配置するぐらいで、それ以外はあまり使いません。
    • ケミ魂は製薬時のみ
    • アサ魂は昔TEで使った名残かも?
  • 2
    • SSではHJKLに魂を配置していますが、戦闘する職の場合は着替えを配置します。
    • SSには載っていませんが、消耗品はASDFGに配置してます。
      • 右から順にHP剤、SP剤、状態異常回復、という感じにしてます
  • 3
    • YUIOTによく使うスキルを配置してます
      • Oはハイド
    • 使用頻度低めのバフとかQWE辺りに配置
  • 4
    • 12345はリンカー限定の配置で、ノピをキーに合ったレベルで配置してます。
      • 普段はLv5を使うんですが、V2 3mapみたいなレベル変えて飛ぶ必要があるところで使います。

という感じです。あまり参考にならないと思いますが、こんなヤツもいるんだよというお話でした。

風花雪月

先週末ぐらいに始めた。

主人公とジェイガン風の人の会話の後、最初の戦闘へ。今までのシリーズの序盤と同じような、斧持った山賊達を相手にするやつ。普通に釣って倒せば良い感じ。のんびりやってるとジェイガン風の人が動き出すんで、さくさく進めないとイカン。

最初の戦闘の後、会話が色々あって学園を散策するパートになった。3Dのマップを歩き回って人と話したりして、メインクエストのようなものをクリアするとその日は終わり。サブクエスト的なもので、食事とか釣りとか植物栽培とかもある。

その後も学園生活がメインで進んで行き、週頭に教壇に立って教える系の選択を色々した後、金曜までは自動で進み、週末に散策するのか戦闘するのかを選び、月末にイベント戦闘がある、といった感じ。

f:id:txdrum_reflect:20190806124228j:plain

まだあまりやれてなくて2〜3ヶ月進めた辺り。今までのシリーズにない要素があり過ぎるし、学園生活がメインというのもあって、自分が勝ったこれは本当にFEなのか?と困惑している。

Google Cloud Next '19 in Tokyo 2019/08/01 メモ5

17:20〜 渋滞ゼロを目指して!〜GCP で実現するリアルタイム交通データ分析〜

  • アメリカでは人口より車が増えてる

  • 渋滞

    • 1人40h/year損している(国交省)
    • 危険が起こる

      • 死因の7位になる
    • 解消の為には?

      • 道路を作る
        • コストがかかったり使える土地が有限という問題が
      • データを利用して既存の道路を有効活用した方が良い
      • 物が通る道というよりデータが流れる道というふうに考える
  • データは存在する

    • 交通局、公開データ
    • バラバラ→サイロになっている
  • データに基づいた安全なコミュニティの形成

  • Google Cloudを使う理由

    • 最先端の研究がplatformになっている
  • Googleにおけるデータアナリティクスの設計原則

    • インフラを気にせず分析に集中
    • 包括的なソリューションを提供
    • end to endのMLライフサイクル
    • セキュリティを念頭に置いた設計、構築、運用
  • 事例

    • コロラド州交通局
    • Smart Analytics for Intelligent Transportation System

    • 主要なデータ

      • 地理空間
        • 速度
          • 台数、速度
          • レーダーからの情報
          • コミュニティからの情報
        • 気象
          • 観測装置からの情報
          • 3rd partyからの天気情報
        • インシデント
          • 事故、工事
      • ビデオストリーミング
    • BQにデータを格納し、一元的にアクセス可能にする

    • 地理空間データを扱うツール

      • geomesa
      • GeoServer
        • OSS
        • GKEを使用
        • inputにgeomesaを使用
    • 状況認識と可視化

      • kepler.gl
    • ビデオストリーミング

      • Video Intelligence API

Google Cloud Next '19 in Tokyo 2019/08/01 メモ4

14:00からのオープンステージセッションについて

14:00~ 「 graml (仮) 」について

  • Grasys 諏訪さん f:id:txdrum_reflect:20190804212137j:plain

  • サーバーメトリクス予測システム

14:40~ Cloud Run の勘所

  • リクルートホールディングス arakawa-san
  • Ubie 坂田さん

  • Cloud Run

    • 2018年に別名のサービスとして発表され、2019年に正式発表された。
    • コンテナをマネージドで管理し、自分のGKEにデプロイ。
    • リビジョンでバージョン管理
    • knative API互換
    • コマンド1行でデプロイ
  • 各サービスの使い分け

    • GCF
      • イベントドリブンの機能を作るのに良い
      • マネージするものが少ない場合はこれ
    • Run
      • コンテナ化されたアプリを動かすのに良い
      • コンテナを自分で管理する必要がある
    • GKE
      • 複雑なシステム
      • GPUやTPUを使うML向き
  • 最新のアップデート情報

    • VPC内のCLoud SQLに接続できるようになった
    • Per-service identity
    • asia-northeast1に対応
    • アップデートはリリースノートでチェックできる
      • 英語のドキュメントを見よう
  • どのように使っているか?

    • 元々functionsで動かしていたもの
      • 簡単なクローラとか
    • pubsubから(?)も使えるが・・・
      • あまり使っていない
    • ちょっとした社内ツールできちんと管理したくないもの
      • 画像変換
      • url短縮
    • wordpressが動く!?
    • Firebaseと一緒に使うと良い感じにキャッシュしてくれる
    • MLなどの処理時間が長いものを動かしたい場合は?
      • POCとかならいいかもしれないけど、本番で動かすのは良くない。
  • 機能追加できるとしたらどんな機能が欲しい?

    • IPアドレスを固定化したい
      • レガシーなサービスでIP制限があるものと通信したい場合など
      • gRPCの受ける方
    • LBで紐付けたい

おまけ

  • 会場に展示されてたTPU f:id:txdrum_reflect:20190804223515j:plain
  • パークタワー(メイン会場?)とプリンスホテル(サブ会場?)の移動用にバスが用意されてた f:id:txdrum_reflect:20190804223429j:plain

Google Cloud Next '19 in Tokyo メモ3 13:20~

少人数で実現する GKE と Firebase を使ったモバイルアプリ開発手法

  • Ginco 森下さん

  • Ginco

    • wallet
    • solutions
    • mining
  • ブロックチェーンの話色々

    • xFintech
  • Ginco ウォレットアプリ

    • バックエンドエンジニア2人
    • iOSエンジニア2人

    • ブロックチェーンノードはGKEを使用

      • 可用性
      • バージョンアップやR&Dのしやすさ
    • ブロックエクスプローラはFirebaseを使用

    • GKE

      • ロギングやモニタリングが楽
      • GUI
      • istio使える
    • デプロイはgithubとCircle CI

    • 開発初期はGAEとCloud Datastoreだった

    • Firebase

      • スキーマレス
        • サーバーエンジニアなしになった
      • local emulator
        • ruleが本番と違うことがある
      • 正規化
        • クエリ数とトレードオフ
        • 非正規化した方がパフォーマンス良い
        • ユーザーデータだけ正規化するのが良いのでは
      • privateな情報を扱うのに向いてる
      • not null制約がない
        • 検索用に初期値を入れる
      • マイグレーション
        • スクリプトを書く
        • prefixをつける
          • クライアント側にロジックを書いて対応する
  • Enterprise wallet

    • pubsub
    • GKE
    • spanner
    • KMS
      • 全てマネージドサービスを使用

Google Cloud Next '19 in Tokyo 2019/08/01 12:00〜

12:00~ ハイブリッド マルチクラウド環境下における Kubernetes デザインの勘所 - データ管理の視点から

お弁当

Google玉子焼き

f:id:txdrum_reflect:20190804211610j:plain
Google 玉子焼き

メモ

  • ハイブリッドマルチクラウド環境でのk8sクラスタのデータ管理について
  • 環境差異をなくす
  • 破棄、移行可能にする

  • 必要性、目指すべき姿

    • 統合されたオペレーション、アクセス方法を提供する
    • 破棄、移行可能な状態へ
  • ユースケース

    • デプロイする環境
    • グローバル展開→リージョンにサービスがない場合
    • デプロイ先を検討する前に作っておいて後で変えられるようにする
    • DR(Disaster Recovery)先
  • 複数環境を検討すると挙がる課題

    • オペレーションの違い
    • ネットワーク/クラスタ間接続→前日にセッションがあった
    • ストレージ
  • 統一的なインターフェース

    • システム特有のAPIやインターフェースを定義し、データアクセスを抽象化
    • 管理レイヤーを置く
  • ワークロード

    • ステートフル
    • ステートレス

    • データが溜まっていくとクラスタを簡単に破棄できない

      • managedデータサービス
      • ユーザー管理データサービス
      • ブロックファイルストレージ
      • クラスタ依存だと破棄できない
  • コンテナにおけるステート

    • アプリから生成されるデータ
    • コンテナ自体の状態
  • k8sにおけるステート

    • ステートフル
      • PVC/PV
      • Podのライフサイクルと異なるデータ
      • マネージドサービス
    • マニフェスト化できないもの
      • secretなど
    • ステートレス

    • ステートの管理

      • マネージドサービス
        • RDBMS
        • NoSQL
        • ストレージ
          • ベンダーによって違う
      • ユーザー管理

        • 別環境
      • 抽象レイヤーを配置し、入れ替え可能にする。

  • ストレージ

  • CSI(Container Storage Interface)

    • コンテナストレージの共通仕様
    • ポータビリティの低下を防ぐ
    • APIが共通化されているとバックエンドの切り替えが可能
    • CSI対応でも実装状況は異なる
  • ステートはどこで発生する?

    • etcd
      • クラスタのステート
        • マネージド
          • 3rd partyツールでバックアップ
            • Heptio Velero
        • 非マネージド
          • etcdのバックアップ
          • volumeスナップショット
        • リストア手順を確立しないといけない
      • クラスタのコンフィグレーション
        • GitOps
        • secretの管理はVaultを使うと良い?
        • sealed secret
  • k8sクラスタ管理レイヤー

    • NetApp k8s service
  • データ、ストレージの抽象化レイヤー
    • TRIDENT