Bug Bashを1時間やって他チームに細かいIssueを洗い出して貰いました
株式会社サイバーエージェント AdTechStudio オペレーションテクノロジー事業部 iXamDrive(イグザムドライブ) でサーバーサイド・フロントエンドの開発をしている @HonMarkHunt です。
先日、 @konifar さんの記事 『B1グランプリ(Bug Bash)』を2時間やって細かいIssueを洗い出しました
を拝見し素晴らしいこころみだと思ったのでiXamDriveでも挑戦して見ました!
* iXam Driveとは?
インフィード広告の運用自動化ツール
TL;DR
- チーム内で触ってバグを見つけるのでは無く他チームのエンジニアにプロダクトを触ってもらいバグや分かりづらい点(UI指摘)を見つけてもらった。
- 1時間でバグ・UI改善点が27個見つかった
Bug Bash!!
このような流れで行いました!
- 事前説明
- バグ報告
- 採点
- 景品授与
それぞれ解説していきます!
事前説明
まず、当日のレギュレーションを発表しました。大きく分けるとレギュレーションは以下の3つです!
フロント(画面)
、サーバーサイドのコード(GitHubリポジトリ)
、フロントエンドのコード(GitHubリポジトリ)
から自由にbag(と思わしきもの)
、UI/UX的な指摘
、その他なんでもの
を見つけて欲しい。フロント(画面)
はStaging環境を使う。- 本番環境だと実データに影響を及ぼす危険操作ができてしまうため
フロント(画面)
は全機能を自由に触わるのではなく、こちらで指定した機能のみ触ってもらう。- 一部昨日はStaging環境でも実データに影響を及ぼす危険操作ができてしまうため
どの機能を触って貰うかミーティングで 危険操作だらけだった ことが判明したのも収穫でした。
バグ報告
- バグと思わしきものを見つけた方は前に出てプロジェクターに繋いでバグ内容を発表してもらいました。
- 想定の10倍くらいバグだらけだったのでバグ報告の行列もできてしまいました。
採点
- 報告されたバグはその都度iXamDriveのメンバーで採点しました。
- 4人のジャッジがそれぞれ1~5点までの札を持っていて、ジャッジの合計点数でもらえる景品が変わるという評価基準にしました。
- 0点の場合は「仕様」という札をあげる。
(札は前日にiXamDriveメンバーで割り箸と段ボールで手作り)
景品授与
- 報告のたびに採点してその都度点数に応じた景品を持って行って貰いました!
- 景品用に大量の駄菓子と
机にあったいらない本技術書を用意しました! - ちなみに フォームにHTMLタグをそのまま入力できる という痛恨の初歩的バグ を発見していただいた方が満点20点を叩き出しシークレット商品の iXamDriveの飲み会1回無料参加券 を獲得しました。
景品交換の様子
終了後
- Bugは随時記録。
- 27個ものバグが出ました!!!
振り返り
Bug Bashをやってみて良かったこと改善点などを書いていきます。
良かったこと
- @konifar さんの記事を拝見してから、チームのKPT meetingでBugBash 1週間後の開催が決まりました。開催までの期間が短く、2度のmeetingを経て、他チームの方々への周知用チラシ作成、採点用札作成、景品準備など... ドタバタしながら進めていくのが文化祭みたいで楽しかったです。心なしかチーム力も向上した気がします!!
- 参加していただいた方々にも楽しんでいただけた。参加者にはアンケートをお願いしたのですが結果がとてもよかったです!!「他チームでも開催したい。」という声があったのは嬉しかったです!
- issueがいっぱいできた。 ユーザーテストや単体テストと違い、自身のプロダクトを他チームのエンジニアに触ってもらう機会は中々ないと思います。エンジニアは景品欲しさに能動的攻撃を仕掛けてくるので普段は気づかないバグを発見することができました。
改善点
- できたissueいつ消化する?問題。 issueはたくさんできたものの開発スケジュールにそんなに空きがあるはずもなく... とりあえず取り組めそうなものはバックログに追加しておいたので、一瞬手が空いた時にサッと着手できるといいかもしれないです。BugBashででたバグは当月中に解消するなどのルールを事前に決めておいてもよかったかもしれないです。
- Bugの捜索対象を
フロント(画面)
、サーバーサイドのコード(GitHubリポジトリ)
、フロントエンドのコード(GitHubリポジトリ)
と3つ選出しましたが、ほとんどがフロント(画面)
の指摘でした。アンケートでも「コードの指摘はそもそも仕様がわからないからハードルが高かった」
とありました。機能を絞ったりしてコードも見やすいように手配すれば良かったです。
Tips
- 発言しやすい空気を作るように心がけました。どんな報告が来てもとりあえず大声を出しました。
- 得点のフダ余ってるんで使いたい人がいたら言ってください。
- お祭り感を出すためにわざわざチラシを作って他チームに配りました。
Shinjuku.LT 第18回 レポ
ShinjukuLT
目次
- DI with Reader Monad
- Search Suiteのシステム構成
- 引っ越しを支えるかもしれない技術
- ツリー構造のデータをRDBで扱う
- 第一回 デザインクイズ
- Bug Bashを1時間やって他チームに細かいIssueを洗い出して貰いました
- カイゼンジャーニー読んだよ
DI with Reader Monad
登壇者
TL;DR
- 関数単位の細かなDIができる
- 評価されるまで、DIを遅延させることができる
DI
- 外部から依存を注入できるようにするデザインパターン
メリット
-
- テストしやすい
種類
- 動的DI
- 静的DI
SwiftでDI
- Swinject
- DIKit
Reader Monad
- コードがたくさんです!
感想
- 心の片隅に覚えておこう。
Search Suiteのシステム構成
* 全面コンプラ
引っ越しを支えるかもしれない技術
登壇者
TL;DL
- 引っ越しで支えるかもしれないいろんな情報
引っ越しにかかるコスト
発送買取によるメリデメ
メリット * 重いものを運ばなくていい
デメリット * 引っ越しで住所が変わるとだるい
家電や粗大ゴミの破棄
- 家電は捨てれない -> 高い
- 粗大ゴミは低コストで捨てれるが、予約が必要
- 地元の引っ越し屋さんの有料回収した
- ネットのリサイクルショップは反応が遅くて微妙
- ミニクラ 等で預かってもらっても良かった
物件探し
- レインズ見れない(見たい)
感想
- レインズ見たい
ツリー構造のデータをRDBで扱う
登壇者
ツリー構造のデータで考慮すること
- 全体参照
- 一部参照
- 挿入
- 更新
- 削除
ツリー構造をRDBでどう表現するか
- 隣接リスト
問題点
- 階層が深くなると一度に引くのが大変になる
- 分けてクエリを発行してもクエリの発行回数が増える
- 挿入・更新は容易だが、削除は(末端以外だと)大変
- 隣接リストを用いたツリー構造は
ナイーブツリー
と呼ばれるアンチパターン
解決策
代わりのツリーモデルを使用する
- ただしやや複雑になるので注意
1 . 経路列挙
経路列挙
- 参考 : http://blog.amedama.jp/entry/2016/05/06/035437
- 子供のリストへの参照は簡単
- 削除・更新は容易だが参照整合性を維持することができない
閉包テーブル
- メモが追いつかなかった
まとめ
- ツリー構造の隣接リストはアンチパターンになることがある
- 経路列挙は参照整合性が維持できない
- 万能っぽいが、構造の難しさとデータが増える
感想
- 全然知らなかった
第一回 デザインクイズ
登壇者
デザインクイズ
- 作者: 田中クミコ,ハラヒロシ,ハヤシアキコ,ヤマダジュンヤ
- 出版社/メーカー: 翔泳社
- 発売日: 2013/08/20
- メディア: 大型本
- この商品を含むブログを見る
こちらの本から抜粋してAとBのどちらのデザインが直感的に優れているのかのクイズ大会
大事なこと
- 誰のためのデザインなのか
- 何のためのデザインなのか
感想
- 楽しかった!
Bug Bashを1時間やって他チームに細かいIssueを洗い出して貰いました
登壇者
- 僕です
資料
カイゼンジャーニー読んだよ
登壇者
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
- 作者: 市谷聡啓,新井剛
- 出版社/メーカー: 翔泳社
- 発売日: 2018/02/15
- メディア: Kindle版
- この商品を含むブログを見る
- 小説 + 解説という面白い構成
- リアルな状況に即したベストプラクティスに即している
感想
- 「あなたは何をしている人なんですか?」
Shinjuku.LT 第17回 レポ
ShinjukuLT
目次
- Shinjuku.fitness
- SQL Format1
- ブランチとCLRを組み合わせて、論理の繋がりを見える化してみる
- Lensとは?
- NGINX Blogから考えるマイクロサービスのProxy設定
- 危機的状況から脱出した話
Shinjuku.fitness
https://t.co/05KWn2ZQbl#17 最初の発表は@HonMarkHunt @futesi_nebusoku の「https://t.co/3FP9zpHbxT」です!#shinjukult pic.twitter.com/HQ1gIvhwzD
— disc99 (@disc99_) 2018年2月18日
登壇者
TL;DR
- 正しい肉体改造方法
資料
感想
- 1時間40分も喋ってしまった。LTとは?
SQL Format1
登壇者
TL;DR
- SQLフォーマッター作ってみた
様々なSQL文のフォーマット
- フォーマットが人それぞれ
select a , b , c from hoge
select a, b, c from hoge
select a,b, c from hoge
- 公式フォーマットは存在しない
- サイモンホリウェルのフォーマットなど
合意をとる
- 意外と色々めんどくさい...
自動でフォーマットしてくれたら楽!!
- 作ってみた
1. ファイルパスを引数に指定された`.go`ファイルを書き換える 2. `sql`という変数に格納されている文字列を修正する
- 手順
1. astで抽象構文木を抽出 2. 変数取得 3. パーサーで解析、フォーマット 4. 抽象構文木に入れる
デモ
- ターミナルで見せてくれた
感想
- ファイル保存時にフォーマット直接書き換えて欲しいナ
ブランチとCLRを組み合わせて、論理の繋がりを見える化してみる
登壇者
TL;DR
- CLRの順番に質問してブランチで図に起こすと発言の意図をぶれずに伝えることができる
宣伝
- 電車のお悩みを解決するオンラインハッカソンに挑戦して豪華賞品をゲットしよう!
前置き
ブランチ
https://www.slideshare.net/NoriyukiMizuno/vol1-66046068/30
- 原因と結果をはっきりさせる
- AだからB
- AでBだからC
CLR
- 論理性を検証する4つの視点
- 4つの視点を正しい順番で質問する
1. 明瞭性の懸念 2. 存在の懸念 3. 因果関係の懸念 4. 十分性の懸念
- 詳しくはブログにて
資料
hiiiiiiihikaru.hatenadiary.com
感想
- 身につけたら一生モノのスキルになりそう
Lens
登壇者
TL;DR
- Lensとは何か?
宣伝
Lensとは?
- なんかすごいGetter/Setter
普通のGetter/Setterとなにが違うの?
- ネストしたオブジェクトのある一部の値だけ操作したい
関連Link
資料
感想
- composeの実装、全然わからなかった
NGINX Blogから考えるマイクロサービスのProxy設定
登壇者
TL;DR
- マイクロサービス化 => プロキシのやること増えた => アプリ/ミドルウェアで解決するの辛い =>
よくある構成
リバースプロキシ
- セキュリティ
- SSL
- ロードバランシング
- キャッシュ
- etc...
マイクロサービスのプロキシはどうあるべき?
従来のアプローチ
- ミドルウェアやFWで解決
- 覚えたり運用するの大変...
3 Models in the NGINX
1. Proxy Model 2. Router Mesh Model 3. Fabric Model
Proxy Model
- 従来のリバースプロキシの設定 + マイクロサービス特有の機能
Router Mesh Model
- 1台目のNIGNXで従来のリバースプロキシのような動き
- 2台目のNGINX(ルーターメッシュハブ)
- エンドポイントの統合
- 内部キャッシュ
- サーキットブレイカー
- etc...
Fabric Model
- マイクロサービスコンテナごとにプロキシを配置
- 全ての通信IOがプロキシ経由
で、具体的にどうすればいいの?
SidecarとService Mesh
Sidecar
- 各サービスとセットでデプロイ
- 全ての通信がプロキシを経由
Service Mesh
- ≠Fabric Model
新しめのツールがたくさんあるぞ!
資料
感想
- Proxy ModelからService Meshへ移行するぞ!!
危機的状況から脱出した話
登壇者
TL;DR
- 全面コンプラ
Shinjuku.LT 第16回 レポ
ShinjukuLT
目次
- キャラクターマーケテティングを考えてみる
- Physical Computing2 現実(リアル)を支配ハックする
- Elastic Cloudを1年ばかし使ってみたレビュー的な
- 入社までにやっておきたい事, 入社してすぐにしたい事
- ~歴史から学ぶ~ スニーカー基礎講座Ⅰ
キャラクターマーケテティングを考えてみる
登壇者
TL;DR
動機
キャラクターを作るということ
- 差別化や認知度UP
- たくさんのメリット
- 定着させていくためには...
- 一定の予算と時間が必要
- PR
- 作り込み
- が必要
成功例
- 新幹線開通にあわせて登場
- 熊本外の人に向けてSNSなどで拡散
- ターゲットと時期が明確
人気キャラを作るため
- 世界観
- 背景
- 差別化
- 使いやすい
実際に作ったキャラクター紹介
- コンプラのためお見せできない
- とても可愛かった
所感
デザインできるのっていいナー
Physical Computing2 現実(リアル)を支配ハックする
登壇者
TL;DR
- ブラーバを作る
方向転換する
- モータードライバ
- 前進と後進ができるようになった
壁に近づいたら後進する
所感
自分で掃除した方が早そう
Elastic Cloudを1年ばかし使ってみたレビュー的な
登壇者
宣伝
TL;DR
経緯
- 障害対応、顧客サポートでELBログを可視化したい
- ElastiSearchとKibanaよさそう
- ElastiSearchは管理が大変...
- Amazon ESとElastic Cloudとの比較
状況
- 要求: 管理に時間がかからないこと
- ほぼAWSの構成
比較
Amazon ESのメリット
Elastic Cloudのメリット
- ESと同社が作成しているので対応がきめ細やか
- X-Pack標準搭載
- クラスタのバージョンアップが容易 違いはそんなになかったがバージョンアップやESの使い勝手からElastic Cloudを採用
結果
- 安定している
- version up対応もスムーズ
- 不満な点は特になし
所感
- うちはlogentriesです
入社までにやっておきたい事, 入社してすぐにしたい事
TL;DR
- 入社初日から活躍するためにやっておきたいこと
準備しておきたいこと
- ビジョン・行動指針の把握
- 技術面のキャッチアップ
- 公開されている記事や動画には目を通す
- 使用しているライブラリ使ってみる
- ビジネス視点でサービスさわってみる
- 中の人とご飯に行く
- 事前に親睦を深めておく
- お引越し
- オフィス側に引っ越せるなら是非
- ビットコイン買っておく
- みんなやってるから
最初は...
- 最初の一ヶ月は「なんでも聞いていい魔法の時間」
入ったあとやりたいこと
- ひたすらストーキング
- Slackの過去ログ
- ドキュメント, PR
- 闇雲でなく脳内にインデックスをつくっていく感覚
- 内容じゃなくて背景を知る
HowWhy- なぜこうなっているのかを意識する
- ビジネスドメインの理解
まとめ
- ストーキングしよう
- Whyを理解しよう
- ドメインを理解しよう
~歴史から学ぶ~ スニーカー基礎講座Ⅰ
登壇者
僕です
スライド
【読書メモ】Scala関数型デザイン&プログラミング 1章 関数型プログラムの基礎
Scala関数型デザイン&プログラミング ―Scalazコントリビューターによる関数型徹底ガイド (impress top gear)
- 作者: Paul Chiusano,Rúnar Bjarnason,株式会社クイープ
- 出版社/メーカー: インプレス
- 発売日: 2015/03/20
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (7件) を見る
概要
Scalaで関数型プログラミングを学ぶ本。 関数型と聞くと「ウ"ッ」っとなるプログラマーだが、会社で輪読会のお誘いがあったのと、対象読者が「Javaばっかしやってた人」だったのでなんかできそうだなと思い読んでみことにした。継続的にkotlinをやっているのでScalaで関数型を学べるならこれ幸い。という気持ちもあった。
今回は、1章:関数型プログラムの基礎 のまとめ。
隔週で輪読会をやっているので(可能であれば)毎回ブログにまとめていく
TL;DR
式eがあり、すべてのプログラムpにおいて、pの意味に影響を与えることなく、p内のすべてのeをeの評価結果と置き換えることができるとしたら、eは参照透過です。関数fがあり、式f(x)が参照透過なすべてのxに対して参照透過であるとしたら、fは純粋関数です。
1. 副作用とは
- 関数型プログラミング -> 純粋関数だけを使ってプログラムを構築すること
- 純粋関数 -> 副作用のない関数のこと
- 副作用 -> 単に結果を返すこと意外に何かする関数
副作用の例
- 変数を変更する
- データ構造を直接変更する
- オブジェクトのフィールドを設定する
- 例外をスローする、またはエラーで停止する
- コンソールに出力する、またはユーザー入力を読み取る
- ファイルを読み取る、またはファイルに書き込む
- 画面上ここに脚注を書きます))描画する
副作用を持つコードの例
2. 副作用の排除
- buyCoffeeの際にトランザクションを発生させたくない
- テスタビリティー
- 再利用性
- Chargeを返すように修正
- n杯のCoffeeの購入に対応した
buyCoffees
を作成 - ワンライナーでまとめられるよ!
3. 参照透過性
- どのようなプログラムにおいても、プログラムの意味を書き換えることなく式をその結果に置き換えることができる
intToString(5)
の結果を呼び出し元において"5"
と置き換えても正しく動作する。てきなこれは参照透過なのだろうか?
chargeはUnit
- buyCoffeeの戻りは
new Coffee()
と同等 - つまり、buyCoffeeの呼び出し元を全て
new Coffee()
と置き換えても、正しく動作(影響を与えない)しなければならない - この条件が満たされないので上記buyCoffeeには参照透過性がない。といえる
- buyCoffeeの戻りは
置換モデル
- 参照透過性では、関数が実行する全てのことが戻り値によって表される <= 普遍条件!
- 関数を全て結果に置き換えても同じように計算が進められる。
- 等価による置換
- プログラムの等式推論がなりたつ(意味不明)
純粋性
- 参照透過性が担保されるとめっちゃモジュール性高い
- 合成可能
4. まとめ
- 関数型プログラミングとは副作用のない純粋関数だけを用いてプログラミングすること
- メリット
- モジュール性向上
- 推論の容易可
builderscon 2017 でLTしてきたぞ!の感想とか
はじめに
2017/08/03~05で開催されたbuilderscon 2017で、LTをさせて頂いたのでそちらの感想と来年にやる方への向けて何か残せればと思い記事を書きました。
決してコアスタッフの方々に圧力をかけられたからではありません。
登壇までの流れ
7/20
申し込み(締め切りは7/30迄)8/3
採用発表8/4
登壇
登壇した感想
- 当日はメインホール400人会場😥で5分LTをやらせていただきました
- ステージ下に順番に並んで前の人が終わったらすぐ次の人はい次!という感じで完全5分切り替え制でした。割とカンファレンスのLTってそういう形式が多いですね。
- 自分は5番目くらいでしたが、前の人達が全員信じられないほど大爆笑をかっさらっていたので、首を掻っ切って命を断とうかと思いましたが、なんとか発表できました
- 発表中は緊張しすぎてなぜか会場を見ず、空条承太郎を彷彿とさせるポーズでスクリーンを見ながら発表し、マイクが遠くなって声が小さくなってしまいました。後で言われて首を掻っ切って命を断とうかと思いました。
ちょっと困ったこと
- 実際申し込みから登壇してみて少し困ったことを書いておきます。
LTの採用・不採用がいつなのかわからなかった。
- 上記の通り採用連絡が運営のツイッターから行われたのが前日でした。
- 私みたいな無能エンジニアはスライド作るだけでも数日かかってしまうので、そもそもいつ採択が発表されるのかがわからない状況は少しキツかったです。
- 前日発表するにしても、「LTの採択は前日に発表します。」と一言アナウンスがあるととても助かるなと思いました。
LTのプロポーザルが運営向けか一般向けかわからなかった
- LTの申し込み時に専用のページからLTの概要を記入するのですが、これが一般公開されるものなのか、運営が審査のために読むものなのかわからず少し書きづらかったです。
- 書いた後に分かったのは、
LT終了後に一般公開されるもの
ということでした。ですが、登壇前にカンファレンスアプリから普通に見えたような気がします。 - こちらは「そもそもプロポーザルってそういうものだから」とかそもそも私の勘違いなどでしたら喉を掻っ切りますので教えてください。
やってよかったこと
勇気がついた
- あの大人数の前で登壇するのは私のような底辺エンジニアには中々ない機会でしたのでなんか色々すごいよかったです。
自分のダメなことがわかった
- 本番は練習以上のものはでない。とよく言いますが、まさにそんな感じでした。
- スライドの作り, 声の出し方などダメなところがよくわかりました。
最後に
- 私は以前HTML5 Conferenceのスタッフをやらせていただいたことがありますが、buildersconは3日間開催、スポンサー用のアメニティー、カンファレンスアプリなど考えて、準備と当日運営が死ぬほど大変だったんじゃないかと思いまいした。
- このような貴重な機会をいただきスタッフの皆さん本当にありがとうございました!!&お疲れ様でした!!
- また来年も楽しみにしています。
発表資料はこちら
www.slideshare.net
Twitterもフォロー待ってるぜ!
調子乗ってたらflywayのstateが「ignored」になったときの対象法
内容
こんな感じになっちゃったときの対処法
+---------+---------------------------------------------------+---------------------+---------+ | Version | Description | Installed on | State | +---------+---------------------------------------------------+---------------------+---------+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 1.150 | update tsv schemas | 2017-06-22 02:33:13 | Success | | 1.151 | drop column user setting | 2017-06-22 06:16:45 | Success | | 1.152 | add category monitor column | 2017-07-03 02:59:44 | Success | | 1.153 | create manager history | | Ignored | <= コレ | 1.154 | create level set | 2017-07-06 02:31:04 | Success | +---------+---------------------------------------------------+---------------------+---------+
原因
- flywayの
shema version
は新しいものから実行されていくので、↑の例でいくと1.154
を先に追加してmigrateした後に1.153
を追加すると発生する - 普通に開発してればまず起こらなそうだが、以下のように調子にのると発生する。
ぼく 「佐藤さん(仮)の作業にmigrationありますよね!」 佐藤さん(仮) 「はい」 ぼく 「ぼくもあるんで番号かぶってconflictしないようにしましょう!」 佐藤さん(仮) 「はい」 ぼく 「ぼくの方が先にmergeするんで、ぼくが153使うんで佐藤さん(仮)は154にしてください!」 佐藤さん(仮) 「はい」
- これで佐藤さん(仮)が先にmergeすると↑の状態になる
対応
- stateが
ignored
になると、flyway migrate
しようがflyway repair
しようが実行されなくなる、辛い。 flyway migrate
時のオプションにoutOfOrder=true
を指定すると実行される
https://flywaydb.org/documentation/commandline/migrate
結果
- こんなんなる
+---------+---------------------------------------------------+---------------------+---------+ | Version | Description | Installed on | State | +---------+---------------------------------------------------+---------------------+---------+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 1.150 | update tsv schemas | 2017-06-22 02:33:13 | Success | | 1.151 | drop column user setting | 2017-06-22 06:16:45 | Success | | 1.152 | add category monitor column | 2017-07-03 02:59:44 | Success | | 1.153 | create manager history | | OutOrdr | | 1.154 | create level set | 2017-07-06 02:31:04 | OutOrdr | +---------+---------------------------------------------------+---------------------+---------+
- stateが
OutOrdr
になっている - 完全に意味不明である
OutOrdr
- java docによると
This migration succeeded.
とのことらしい。 - ただし「順不同で実行されたから、全部再実行する時は違う結果になるかも><」とのことである
教訓
- 調子のってmigration番号の先読みはしない
- conflictさせて修正したほうが安全
- 佐藤さん(仮)は想像より作業が早い