そろそろ風有利古戦場

前回光有利まではA団にいましたが、2代目団長が騎空師的にも人間的にも小物だったので脱退。今の団はB〜C団ぽいですが、団の雰囲気は前の団よりゆるくて良い感じ。コミュるのを強制しない方が団結強くなると思ってます。(団に限らずですけど

風有利の準備は、

犬向け

メカ ミスト ルリア ミュオン or サビル ミリン

銃 琴3 拳 オナラ ヴィント 青龍邪 天司 バハ

ティアマグ バハ アグ マキュラ アーカルム

hell向け

ウォ ヘイズ チェイサー 何か シエテ(未最終 ジャンヌ ニオ(未最終 → 昏睡耐性ありそうだからランスロットにする?

エタラブ 琴3 銃3 ゼノ拳 天司 バハ

ティアマグ バハ バイブ2 アーカルム

こんなところでしょうか。

新犬次第ではAT中にゼノ拳レスラーとかクリュとか使うことになるんでしょうか?

めんどくさいマルチはあまりやりたくない人なので、テトラ、オメガ、終末武器辺りは着手してません。銃5凸は次回やるかどうか。

今回も20箱は行きたいですね。

デブサミ2019 2日目(02/15)メモ 17:25〜 エンジニア人生と定年退職、人生100年時代のエンジニアの生き方

  • 主題が大きい

    • ふわふわし過ぎ?
  • パラダイム(規範)

  • パラダイムシフト

    • なんちゃら革命
    • 一生に一度?
    • 気付かない、知らない、ことがある
  • 自己紹介(よしおかさん)

  • 人生100年時代

  • 1970〜

    • 1971 intel 4004
      • マイクロプロセッサ
      • よしおかさん中1
    • 1975 BASIC
      • エポックメイキングな事件
    • 1977 Apple II, TRS-80, PET

      • パソコン
      • よしおかさん大1
      • RSA public key
        • ネット時代に生きる技術
      • Cryptography
    • 当時の情報ソース

  • 1980〜

  • 1990〜

    • 1990 よしおかさんの娘誕生
    • 1991 web site
    • 1993 NCSA Mosaic
      • GUIブラウザ
    • 1994 ネスケ
      • よしおかさんOracleに転職
    • 1995 Win95
      • よしおかさん米Oracle
    • 1998 ネスケ/モジラ OSS
    • 1999 YLUG カーネル読書会

    • 終身雇用からのコペルニクス的転換

      • 希望退職というのがあった(DEC?)
    • OSS
      • ただにしたらどう商売するの?という疑問
        • うまく行くわけないと思っていた
        • が、ワクワクしていた。
    • インターネット
  • 2000〜

    • 2000 ITバブル
    • 2002 よしおかさん未踏
      • 1年仕事しつつ研究
    • 2004 FB, mixi, web2.0
    • 2007 iPhone
      • よしおかさんは過小評価していた
    • 2008 勉強会ブーム
    • 2009 bitcoin
      • よしおかさんはピンとこなかった
  • 2010〜

    • 2011 震災
    • 2012 deep learning
    • 2013 1000 speakers conference

    • 就職、引退の感覚が変わる。

      • 会場の受講者はほぼ会社員
      • よしおかさんの話は会社員についての話
    • 仕事感
      • x 好き、楽しい、できる、やりたい
      • y 時代の流れ
        • パラメータ調整
    • 物から情報へ
      • コンピュータとソフトウェア
        • 機械が情報を処理できるようになった
      • 世界はソフトウェアでできている
      • 物作り→情報作り
        • 製造業は圧倒的競争力があった
        • 情報処理はまだ50年ぐらい
      • 前例がなく変化が当たり前
  • パラダイム

    • 当たり前過ぎて見えないこと(古いパラダイム)
      • 定年退職
    • 新しいパラダイム
      • 働き続ける為に辞めた
      • 働く為に学ぶ→学生になった
        • 楽しい
        • 自分をバージョンアップする
  • ムーアの法則(古いパラダイム)

    • 3年で4倍ぐらいのペースだった
    • 性能向上に無頓着だった
      • この法則を前提にしていた
        • メモリを潤沢に使うプログラムでOKだった
    • 最近は年3%ぐらいしか向上してない
      • どうすんの?
        • 簡単な性能向上はない?
        • コア数が増えていった
          • many core対応のプログラムを作らないといけなくなった
  • よしおかさんが学生になったきっかけ

    • 201806 東大オープンハウス
    • 201808入試
    • 201809 退職&入学

    • 何故学生?

    • 論文を読む読む読む→纏める→問題を見つける

    • 学び直さないと色々陳腐化する

      • 学び方を学ばないと
  • Be a hacker

  • Make the world better

デブサミ2019 2日目(02/15)メモ 13:05〜 3周年に突入するAbemaTVの挑戦と苦悩

  • スライド https://speakerdeck.com/miyukki/the-challenge-and-anguish-of-abematv-celebrating-the-third-anniversary

  • みゆっきさん

    • コンテンツ配信チーム
    • 趣味でも配信
  • 新デバイス

  • 赤い人はテックリード
    • レビューしたり他メンバーからの質問を受け付けたり
  • GCPを使っている
    • L7LB
    • GKE
    • 帯域に対するコスト
    • 開発当初は東京リージョンがなかったので台湾リージョンを使っていた
      • ネットワークの速度や安定性に難あり
      • レガシーネットワークは移行のコストが高い
  • Java→Node→go

    • goのパッケージ管理はgodep→dep
    • go本体のリリースサイクルが早い(半年)

    • マイクロサービス

      • 80個ぐらい
      • コンテナ化
      • 機能毎のリリース

      • 共通ロジックをどう管理するか?

      • 負担の大きいサービスを分解する

  • GKE

  • mongo DB

    • Cloud Manager
    • シャーディング、レプリカセット
    • CPU16コア、メモリ60GBを60台
    • クラスタ

      • ユーザー
      • コメント
      • 配信
    • 管理

      • mongos
      • コネプー
    • スキーマ設計は慎重に
    • イケてるgoライブラリがない
  • cache

    • in memory
      • アプリ側
        • 番組表とか
    • redis
      • 今はmanaged serviceがあるけど、開発当初はなかった。
      • セッション管理
      • ロック
      • ネットワーク負荷対策
      • クラスタドメインによって分ける(mongoDBと同じ分け方)
  • terraform

    • GCPの構成管理
  • packer

  • ネットワーク

    • クラサバ通信
      • 開発当初はgRPCが使えなかった
        • バックにhttp2.0を流せなかった
          • 今はできる
    • プロトコルバッファ

    • CDN

      • akamai media delivery
      • API Cloud CDN(?)
        • チェックつけるだけで使える
    • 広告

      • リニア型
        • SSAI(server side)
        • 規格はVAST
      • VOD型
        • CSAI(client side)
        • シーク制御が難しい為
        • google IMA(?)
        • VAST
  • CI/CD

    • codeship
      • バックエンド
        • テスト
        • イメージ作成
    • deploykun
      • 社内製ツール
      • ChatOps
        • PR→codeship→GKE
  • モニタリング

    • bugsnag
    • Google Cloud Monitoring
    • 異常検知
      • slack
      • エンジニアにコール
      • 担当外の人にコールが行ったり
    • pagerduty
      • インシデント管理
      • 画像が貼れない
  • ログ

    • アプリ
      • 1
        • fluentd
      • 2
        • Cloud PubSub
          • カスタムカラム追加が難しい
        • BigQuery
          • キャパが心配
        • Streaming Inserter
          • 運用管理
      • 3
        • 新ログシステム
          • Cloud Dataflow
          • Cloud Storage
          • BigQuery
          • apache avro
            • スキーマ込み
            • BigQueryがavroファイル取り込みをサポートしている
  • メトリクス

    • staticdriver
      • redis, mongoDB
    • prometheus
      • アプリ
      • grafana
  • 今後

    • 挑戦と苦悩

      • 規模拡大
        • キャパ、マネジメント
      • 安定化
      • 老朽化
        • ミドルのEOL
        • 古いアーキ
    • 目指すアーキ

      • 配信レイヤーの全二重化
        • ユーザーの直前まで二重になっているべき
      • チャンネル別リソース
      • オートスケール
        • 過去の実績に基づいてスケール

デブサミ2019 2日目(02/15)メモ 12:10〜 モンスターストライクにおける負荷対策 ~エンジニアリングチームの挑戦~

デブサミ2019 2日目(02/15)メモ 11:05〜 CI/CDを使い倒して数段上のソフトウェア開発をしよう!

  • スライド https://speakerdeck.com/kimh/cdwoshi-idao-siteshu-duan-shang-falsesohutoueakai-fa-wosiyou

  • CI/CD戦国時代

  • 何故関心が高まっている?
    • 「ビシっと」答えられるという人はいなかった(受講者の中に)
  • CODEZINEの連載がキッカケ

    • 「CI/CD」でぐぐるとトップに出てくる
  • Circle CI Japan

    • 日本語サポート
      • 問い合わせがあまり来ない?
  • Hop-on!

    • 金さん個人運営
  • テスト

    • コンピュータにやらせよう
    • テストを自動実行するのがCI
    • テストの信頼性がない
      • し忘れ
      • テストが壊れている
        • 壊れを検知
        • 直さないとマージできない
          • 修正を強制する
      • 環境依存
    • 変更を検知
  • 使われない自動化は壊れていく(サイボウズ)

  • 環境依存

    • False Negative
    • コンテナを使う
    • LXCのコンテナでテストしていたのでCircleCIが有名になった
  • テストの新陳代謝を高める

  • Why Not

    • テストがない
    • テスト文化の布教に苦労している人はそこそこいる(受講者)

    • テストがなくてもCIを始める方法

      • 好みのツールを見つける
      • 様々なタスクを自動化する
      • 可視化

        • ステータスバッジ(yarnとかで使われてる)
        • ダッシュボード
        • メールやチャットで通知
      • CIをやってる感が出てくる

      • マージブロック

        • VCSの機能
        • CI通らないとマージできないようにする
      • テストを追加する
        • 頑張り過ぎない
  • CI/CDツールのメンテナンス

    • jenkinsおじさん問題
      • CI/CDツールのプロがプロジェクトに1人だけ
      • その人が抜けるとCI/CDが機能しなくなる
    • クラウド型がおすすめ
      • 導入しやすく、運用コストが低い。
  • CD

    • Dはデリバリー?デプロイメント?
      • デリバリーは人の医師が介在する
      • デプロイメントは全自動
        • デリバリーの進化系がデプロイメント
    • 広義のデリバリーの定義も存在する
      • ビジネスの価値を継続的に〜
    • デプロイは配置するだけ
    • リリースは配置してトラフィックを受ける状態にすること
  • リリース後の問題

    • フィードバックループ
      • 細かい単位でリリースする
      • フィードバックを早めに得る
      • CI無しでは回らない
        • No CI, No Feedback Loop
  • Why Not CD?

    • 技術的問題
      • 向いてないアーキ
    • 組織的問題

      • 誰か教えて!
      • エンジニアリング組織論の本を読むと良い?
    • 新システムにはまずCI/CDを導入しよう

      • 最初からクライマックス(家永さん)
  • CircleCI内の事例

    • AWS上にビルドマシン200台
      • 1人が半日張り付いて入れ替えが終わる
    • 新旧コードが混在
    • docker, kubenetes導入
    • マイクロサービス化
      • 1年かかった
  • Beyond CD

    • 完全に理解した?
    • 迅速なロールバック
      • git revert→CD→再リリース完了
    • 本番でのテスト
      • 環境差異
      • (本番以外では)テスト可能範囲が狭い
        • ビジネス要求、外部サービスとの結合、など
      • リリースしてみないとわからない
        • DevOpsとか
    • 高度なリリース手法
      • カナリー
        • 一部に適用する
      • BG deploy
    • 心理的安全性
    • CI/CD makes programming FUN!
  • 未来

    • 自動化することで進化してきた
      • 今何を手動でしているか?
        • 設定、モニタリング、デプロイ環境構築
    • first commitからクライマックスになる?
  • ユーザーコミュニティ

デブサミ2019 2日目(02/15)メモ 10:00〜 ドラゴンクエストXを支える失敗事例

  • 個人スポンサー席満席?
  • 立ち見あり
  • 開始前にコンドーさん(翔泳社)の挨拶

    • 2日続けて参加してる人がそこそこ多い
  • スクエニ青山さん

    • DQ10プロデューサー
    • 後で資料は配る
      • これ書いてる時点ではまだ公開されていない(週明けかな?)
    • テクニカルディレクター時代(1つ前の仕事)の話がメイン?
    • キングボンビーを初めてプログラムした(PCエンジン)
      • 生みの親ではない(サクマさん)
  • オンラインサービスはリリース後が本番

    • 運用、運営
  • 良い設計

    • 要件を満たしているのが前提
    • 経験からくる
  • DQ10は6年半やってる

  • 痛い目見ないとわからない部分もある
  • 組織によって解は違う

  • MMORPG

    • MOとの対比→MOはホスト(ロビー?)あり
  • 詳細は本見てね

https://www.amazon.co.jp/%E3%83%89%E3%83%A9%E3%82%B4%E3%83%B3%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88X%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93-%E2%94%80%E2%94%80-%E5%A4%A7%E8%A6%8F%E6%A8%A1%E3%82%AA%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%B3RPG%E3%81%AE%E8%88%9E%E5%8F%B0%E8%A3%8F-WEB-PRESS%E3%83%97%E3%83%A9%E3%82%B9%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA/dp/4297101742/ref=sr_1_1?ie=UTF8&qid=1550311595&sr=8-1&keywords=%E3%83%89%E3%83%A9%E3%82%B4%E3%83%B3%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88+%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93

  • 運営、運用が重要

    • 運営→攻め→イベントとか→柔軟性
    • 運用→守り→不具合対応とか→継続性
  • 失敗事例

    • その1 スキル(?)を使った時の効果音が鳴り続けたり、ノイズがある「場合がある」。

      • クライアント側の話
      • エフェクト

        • データドリブン
        • C++
        • 何も直してません!
        • ミスした時に音を止める処理が無効化されてた
          • 別のスキルで、逆に音が鳴って欲しいのに止まっちゃう不具合があって、それを直す時に他のスキルでもミスした時に音が止まるようにしてしまった。
            • 別のスキルの方を個別の処理にした
      • 教訓

        • 影響範囲をBTSのチケットに明記し、再検証し、影響範囲は極力狭くすべし。
    • redmineを使っている

    • その2 パーティーのオートマッチングが行われない「場合がある」

      • 邪神の迷宮(?) 8人パーティーで進めるダンジョン
      • エリアが複数あり、エリアによってマッチングに参加できる条件が異なる。
        • 条件は月2回(?)自動で更新(変更)される
      • プログラマ、デザイナー、プランナーがいて、条件はプランナーが決めている。(って言ってたと思う。うろ覚え)
      • 条件判定はクライアントで一次チェックが行われてからサーバーで最終チェックしている
        • 一次チェックがOKで最終チェックがNGだった
        • サーバー側にハードコードされた条件判定処理があった
          • 以前のアップデートで条件のデータフォーマット変更があった
            • リリースタイミングが微妙だったので、一旦暫定対処としてハードコードした。
              • 該当ダンジョンのデータが新フォーマットで、システムがまだ旧フォーマット対応だった?
      • 教訓
        • 暫定対応は本対応するまでチケットを残そう
    • その3 釣りで釣った魚(魚じゃないのもある)のサイズ誤判定

      • 釣れるものは123種類
      • 釣りの処理はC++Luaで実装されている
        • C++部分ではmmの情報をintで持っていて、Lua部分ではmとmmの情報をdoubleで持っている。
      • 1023mm以上だとビッグサイズ、1022mm以下だとノーマルサイズ。
        • Lua部分で1000で割ってmをmmにする処理の誤差で1023mmのものが1022mmと誤判定されてた
          • 割る前に補正処理が入っていたけど割るところでNG
          • ぱっと見であってそうだったからスルーしてしまった
          • 急に起きた
            • データ作るところで1023mmになるはずのものが1022mmになってしまった
              • ダブルマスタ(再計算を避ける為にマスタデータを複数持っていた)のズレ
              • 別の不具合も影響して起きた
      • 魚(?)を交換してしまった人をログ等から探して個別に対応した(スクリプトでデータ修正)
      • 教訓
        • 表面化していないバグがあるものと思え
    • 考察

      • 影響範囲を明確に
      • ちゃんとチケットを登録してクローズまで持っていく
      • どうやったら防げたか?
        • チケットを登録していないものが大部分
          • 影響ないだろうと軽視しがち
    • チケット200000ぐらい(不具合以外のタスクも含めて)
  • QA

    • 開発体制はどれくらいの人数でやっている?
      • 具体的な数字の公表はNG
        • 人事から止められている(コスト等がバレてしまう?)
        • スタッフロールには数百名の名前が
    • 影響範囲を特定する方法は?
      • 個別に見る
      • 個々の経験値に依存(あまり良くない)
    • チケットに登録されない理由は?
      • (担当者が)登録するまでもないと思ってしまう
      • 勘違い
        • 大部分はできているがたまーに漏れてしまう感じ
    • タスクが多い中、モチベはどう保つ?
      • 飽きて辞める人もいる
      • チーム内の異動はある
  • 雑感

    • ゲーム固有の話は少なめで一般的な話が主だったかなぁという印象

20180813

お仕事

  • この時期は朝の電車が空いてて良い
  • SQL Alchemyでorder by descは「order_by(Table.column.desc()」
  • Vueでクエリパラメータ取りたい時は「this.$route.query」

カメラ

  • 単焦点レンズ用の偏光フィルタを購入
  • 動画撮影用にGoProがちょっとほしかったりする

グラブル

  • スタレ後半はトール
  • サプはグラシ
  • ラブライブコラボのコラボ品はだいたい取れて、残りはガチャチケとブレード4凸ぐらい。
  • 溜まってたアーカルムチケ消化中