2018-07-28

iOS Test Night #8 で「あのイベントはすごいよと噂のWACATEがどうすごいのか、参加して確かめてきた」というタイトルで登壇しました #ios_test_night

はじめに

こんぬづは、台風の日のカフェは空いていて居心地が良いという知見を得た田中です。

先日開催された iOS Test Night #8 で登壇したので、その報告をします。

testnight.connpass.com

内容

WACATE 2018 Summer from Kenji Tanaka

以前からテスト関係に関心のある知り合いからWACATEの噂を聞いていて、参加したのでレポートしましたという感じです。やったこと、わかったこと、次にやること、感想などを書いています。スライドには他にまとめたレポートの情報も載っています。

内容ももちろん魅力的だったのですが、テストエンジニアの方々と接する機会を持てたのが個人的には収穫でした。日々自分がどれだけ機能や画面に寄った言葉でコミュニケーションを取っていたのかわかり、もっと要件や仕様のレイヤーで話をしたり、テスト前提で考えると開発にも活かせそうだと思いました。また、テストが無い状況にどう立ち向かうべきかという個人的な課題について、参加者の人々と話ができて、判断に自信が持てたのも良かったです。

感想

自分がテストについて考え始めたのは iOS Test Night がきっかけだったので、その中でも他の人が体験したことのないようなこと（テストエンジニアだらけの空間にまじって色々やること）をレポートできたのは、循環が生まれたりして良かったかなと思い、嬉しいです。

2018-07-21

百合好きにも、百合入門者にも、百合を知らない人にも読んで欲しい『百合が俺を人間にしてくれた――宮澤伊織インタビュー』

はじめに

おばんです、百合漫画総選挙結果発表(10~1位) – 百合ナビの結果を見て、「なるほど、そうなるよね」という納得感とともに、自分の中のランキングとは違うなというもやもやを抱えている田中です。

今日のトピックはこれです。みなさんこの記事を見ましたか？神記事なので読んでほしい。でも読むのにハードルが高く感じるという人のために関連キーワードとみどころを簡単に紹介します。もし自分にヒットしそうという感じがあればぜひ本文も読んでほしい。

百合が俺を人間にしてくれた――宮澤伊織インタビュー

みどころ

百合について言葉にしたいけど、うまく言葉にできない。声に出してしまえば壊れてしまうかもしれない、あるいは怖い人たちに刺されるかもしれない。そんな感情を抱いている人が共感できる、「そうそう、そうなんだよ！！！」「百合ってこうだよね！！！」が詰まっている素敵な文章なところ。

また、百合に関する知識と認識をアップデートしてくれる文章もとても見所があります。

Designer X Engineer Lovers（DXEL）第一回に参加してきました！ #dxel

はじめに

おばんです、「デザインの勉強をするぞ！！！」という決意をn回し、今日さらに+1回した田中です。

今回はデザイナーとエンジニアが仲良く、よりよく仕事していくための勉強会である、Designer X Engineer Lovers（DXEL）の第一回に参加したので、そのレポートをお届けします。

engineers-x-designers.connpass.com

アイスブレーク

はじまりはアイスブレークから。 2人1組で自己紹介の中に一つだけ、嘘か本当かを入れて、それを当てるというアイスブレーク。

実はBLが好きなんですよ（嘘か本当か） #dxel
— ダンボー田中、目をつぶって (@ktanaka117) 2018年7月10日

「そのUI、実は簡単じゃないんです」@akatsuki174

気持ちはすげーわかるけど、実装がめっちゃしんどい😇
「戻る」ボタンを押した時にアラートを表示する
- あえて標準UIを使わない
- 自動保存にしてそもそも保存の確認をしなくてすむようにする
ハイパーリンクつけたい
アコーディオンメニュー

「わかる」の嵐でした。また、iOSではよく見ないUIには、よく見ない理由があると紹介されていました。（ほんこれ）ということで、デザイナーの方はiOSで見ないUIがあったら、早めに相談を！逆にiOSエンジニアもそういうデザインを見つけたら、デザイナーに「こういうUIだったらやりたいことをかなえつつ、iOSの流儀にのっとれますよ」と話に行くことが大切だなと思いました。

「Atomic Designはデザイナーとエンジニアの架け橋」@testkatsuobushi

<スライドが公開され次第、掲載します>

スライド用意しようと思ったんだけど、昨日寝ちゃったからネットにある良い記事を解説していきます！
Atomic Design を分かったつもりになる | DeNA DESIGN BLOG
UIデザイナーに必要なのは、決定力のあるデザインを作る能力｜坪田朋

「約2ヶ月デザイナーとペアプログラミングを行なった話と僕が伝えたいこと」@bannzai

一方的な教育ではなく、相談しながら進めたそのなかで「UIに興味があるんだな」と思ったので、Swiftについては多く触れなかった

対話の中で良いやり方を探すのがとても良いと思いました。また、対話に発生するコストやストレスが減って、共通理解を持つことでお互いに楽しく仕事ができるようになったというのが、理想的だなと思いました。しかとムネに響いたぜ...！

「デザイナーとエンジニアを両方経験したわたしが思うこと」@nanammeon

触って楽しい（エンジニア目線)、見て楽しい(デザイナ目線)をモットーにしている
上流工程が遅れて、デザインの工数が減らされてしまう><
前職はエンジニアの方が強かった
良いデザインができても一方的に拒否されてしまったら辛い、傷つく
エンジニアとデザイナの関係が不等号ではいけない
1日の多くを閉めるお仕事の時間を辛いと思いたくない

本来「良いものを作る」という共通の目的のもとに集まっていることは変わらないので、エンジニアとデザイナのどっちが強いとかではなく、より良い解決が得られることが一番良いなと思っているので、共感度が高い発表でした！

「今日から始めるデザインレビュー」@noa_design51

ガイドラインを作ろう！
- ユーザーインターフェースを考え抜くため
- エンジニアとデザイナで共通言語を持つため
あくまでデザインの最終判断はデザインのプロであるデザイナーにある

感覚によったデザインレビューは自分でも少ししてしまっているかもしれないと反省しました。なぜそのデザインが採用されているかは、エンジニアも理解したいと思ってはいるので、教えて欲しいなって、思い、ましたまる。

「デザインに込められたエモを知りたい」@mogaming

エモってなんだ？
- 願い・想い・狙いとか
デザインに込められたエモい会（エモ会）をやることにした

クソエモ話の嵐でした。なんか、エンジニアの立場としてもエモの無い開発したくないなってめっちゃ思ってて、最近の転職もそれがテーマで、、、俺も翼になりてぇ。

「Android, iOS 両方を考慮したアプリデザイン管理」@tummy

<スライドが公開され次第、掲載します>

...🤔（便利なデザインツール便利そうだな） Zeplinの画面や機能が紹介されていました。どうにもAtomic Designがやりやすい、その方向でデザインをしていくように、ツールも向かっているのかなという印象を持ちました。

「エンジニアだけでがんばってみた」@yuri_htt

<スライドが公開され次第、掲載します>

弊社にはデザイナーがいません
エンジニア4人
競合のアプリの機能とUIを洗い出した
インスパイアしました(ゲスく言うとパク...)
いろんなユーザーの体験を考えてみた

デザイナが居ない環境での開発の話を聞いて思ったのは、やっぱりデザイナってすごいということ。例の中ではとても多い画面数が紹介されていましたが、全てに統一感を持たせて、様々なユーザーのUXを考えるのは素人にはできない...。自分は幸いにもデザイナがいる環境にいるので、なんだかもっとコミュニケーションがしたいという気持ちになりました。

懇親会

株式会社レトリバさんのスポンサーで懇親会が開催されました。ありがとうございます！

f:id:ktanaka117:20180710211732j:plain

まとめ

これまで、エンジニアがエンジニアに向けた勉強会や話に触れる機会は多かったですが、エンジニア⇆デザイナにフォーカスした会はレアで参加できてよかったです。（日頃からデザイナの人とはやりとりしているはずなのに、これまで多くなかったのは不思議）明日からもっとデザイナとのコミュニケーションの機会を持ちたいと思いました。

あと、で、デザイン勉強したい...(n回目)

こんなに数多くのデザイナとエンジニアが一堂に会するイベントは多くないので、今後も開催されていってほしいと思いました！応援しています！（いつか登壇したい）

2018-07-08

Xcodeでビルド・テストの成功/失敗時にVTuberの音を出すとキマる

こんぬづは、『星野、目をつぶって』という青春漫画が尊くて仕方ない田中です。

根暗が友達の悩みを解決して、夢に、恋に奔走する、スタート地点がだいぶ下から始まる『SKET DANCE』みたいなお話でオススメです。

さて、こんなQiitaを書きました。

qiita.com

でもVTuberの音声なんてどこで手に入るの！？

BOOTHで買いました。

そのVTuberの代表的なセリフが売られているのと、代表的なセリフってちょうどよい短さなので、なにかのリアクションの音としてとてもオススメです。

えるえるの6,000円パック最高でした。😇

2018-06-20

WACATE2018 夏～もちもちモ・デ・リングで、もぐもぐテスティング～参加レポート #WACATE

はじめに

おばんです、MacBookのマイクでのPodcast収録が限界だったため、ちょっと良いマイクを買っちゃった田中です。

先日、WACATE(Workshop for Accelerating CApable Testing Engineers)という、テストエンジニアのための合宿に参加したのでそのレポートをします。イベントは座学のセッションとワークショップを交互に行う形式でした。資料とTwitterの呟き、それからその他気づいた点などまとめていきます。

WACATE2018 夏～もちもちモ・デ・リングで、もぐもぐテスティング～開催概要 - WACATE （ソフトウェアテストワークショップ）

#wacate pic.twitter.com/AejXKIHHT4
— ダンボー田中 (@ktanaka117) 2018年6月16日

参加の目的

開発エンジニアとして、テストエンジニアが集まる空間で知識と雰囲気を感じて視野を広げるため
レガシーコードを整理し改善するためのヒントとして、モデリングやテストの方法を知るため
機能開発とバランスをもってテストしていくための方法を知るため
テストエンジニア界隈を知るため

参加する前にやったこと

はじめて学ぶソフトウェアのテスト技法

作者: リー・コープランド,宗雅彦
出版社/メーカー: 日経BP社
発売日: 2005/11/03
メディア: 単行本
購入: 24人クリック: 539回
この商品を含むブログ (51件) を見る

上の書籍を途中まで読んで、以下のことを学んだ。これはやっておいてよかった。事前学習なしだとだいぶ厳しかったかもしれない。

参加してわかったこと

UMLには複数種類ある

クラス図、ユースケース図、アクティビティ図、状態遷移図などはUMLの中の種類

ユースケース図はシステムの全体像を掴むのに有用

システム屋以外の人間でもわかりやすいという利点もある

アクティビティ図はアクターがやることの流れを掴むのに有用

シーケンス図との違いは、実装に寄っているかどうか
シーケンス図を書く場合、どういうデータをどういうプロトコルで受けわたすか、などの詳細設計が行われる
アクティビティ図はアクターがどういう行動をするかという概要を時系列順に書くもの

状態遷移図/表は仕様の抜け漏れを探すのに有用

nスイッチカバレッジ

状態遷移をテストする組み合わせの話
0スイッチカバレッジは1つの状態が少なくとも1回のパスを通る組み合わせ
1スイッチカバレッジは1つの状態が少なくとも2回のパスを通る組み合わせ
- 状態A→状態B→状態A(戻り)→状態B、みたいな

モデリングとは、ある側面から見た概念の捉え方

目的に合わせたモデル(UML)を使って、概念を記述する(文法)
UMLに複数種類あるように、モデリングの仕方は様々ある
どういう視点でモデルを構築するかが、ある程度体系立てられている
これまでは雰囲気でやっていたモデリングだったが、UML書きが体系立ててモデリングをトレーニングする方法になりそう

テストは常に何を切り捨てるかという選択

「全件をテストすることは不可能である」という前提がある
その前提に基づいてテストを考えるということは、「なにをテストするか」というより、「なにをテストしないか」ということに焦点が当てられる
2日間のワークショップの中でも基本的に時間不足の状況が作られていて、実戦に近い形でテストを考える必要があったので、とても良いワークショップ設計だった

「テストの視点からのモデリング」 by 朱峰錦司

テストの視点からのモデリング（公開用） #wacate from Kinji Akemine

twitter.com

「ユースケース図&アクティビティ図モデリングからテストまで」 by 中村仰志, 越中谷郁美

ユースケースとアクティビティとテスト from kauji0522

twitter.com

「状態遷移テスト」 by 藤原洋平, 角田俊

twitter.com

深夜の分科会

WACATEの夜は分科会という、各々が持ち寄ったテーマについて語り合う時間があります。が、その時間についてではなく、その後の自由時間に行われた深夜の分科会が個人的にとても楽しかったので、そこをピックアップして紹介します。

深夜の分科会で話したテーマはTDDでした。

twitter.com

ブロッコリー(@nihonbuson)さんによるTDDのデモ
- t_wadaさんがやるように、JavaでEclipseでFizzBuzzで。
テストファーストとTDDの違いは？
- 雑に答えるとリファクタリングの工程があるかないか
金融系のような大きなプロジェクトをTDDでやることができるか？
- できるかもしれないが...?
- 仕様がガッチガチに決められている場合にTDDはできない
  - 「もし入力がほげほげだったら出力はふがふがである」というような仕様を日本語で決められている場合には厳しい
  - それ以上の改善が行えないから
  - これは「誰が書いても同じように実装できるように」ということを主軸に置いたやり方だから(人海戦術を効果的にまわすため)
  - 「動作する汚いコードから、動作する綺麗なコードを目指す」TDDに対して、「綺麗な設計から、動作する綺麗なコードを目指す」アプローチで、ちょうど対になっているはず
- 長期プロジェクトでのウォーターフォール開発とアジャイル開発の違い
  - ウォーターフォールの場合
    - 2年かかるプロジェクトだったとして、完成時のそのプロダクトの価値判断が2年前のもの
    - 2年後に価値がどうなっているかはわからない
  - アジャイル開発の場合
    - 小さな歩幅で振り返りながら進めるので、プロダクトの価値基準を見直す機会が多い

感想とその後

テスト自体の理解が進んでよかった。また、テストは一人で学習して仕事に投入していくにはかなり高いハードルがあるが、合宿を通してテスト設計をする手順について知れたことで、ハードルを超えられた気がする。周りの参加者と会話やワークをしていくことで、これまで散り散りで理解していた知識をつなげることができたのも、大きな収穫だった。

プロジェクトの状況によって、やらなきゃいけないことが変わってくるな。
作ってみなきゃいけない図とか、変わってくる。状況次第で使い分けられるように練習していきたいな。#WACATE
— ダンボー田中 (@ktanaka117) 2018年6月16日

WACATEは「若手IT技術者が世界に羽ばたく為の加速装置」と銘打っているが、加速するかどうかはこの後にかかっていると思った。ので、帰ってきてから早速PlantUML + Atomで環境構築をして、手元の処理の流れをシーケンス図で記述していってみている。なかなか良さそう。

あと一番大きいのは、レガシーコードに向き合う勇気がもらえたことかもしれない。一段飛ばしはできないものの、一歩ずつ理解を進める手立てを得られた。

2018-05-29

身内で楽しくペアプロTDDする会をやってみた

はじめに

おばんです、学生時代以来久々にやる、バスケットボールというスポーツで膝をやってしまった田中です。

仲間内10人ちょいでペアプロTDDを楽しむ会というのをやったので、振り返ります。会の趣旨は以下の通り。

TDDをやってみよう
ペアプロをやってみよう
TDDとペアプロの文化を理解しよう
他の言語との実装の違いを楽しもう
みんなでプログラムを書いてわいわいしよう

内容

t_wadaさんの講演動画をみんなで見て、田中が情報を補足
FizzBuzz問題をペアプロTDDでやってみる

参加したグループの言語はSwift, JavaScript, TypeScript, Goなど。

特に盛り上がったのは言語ごとの書き方の違いと、テスト環境の違いなど。最終結果をいくつかのグループが前で発表する形式をとりました。

VSCodeのLive Sharing機能が便利そうだったし、Goのコンパイル速度が速すぎて自分の組みのSwift/Xcode環境が言い訳できなかったのが面白かった。

ソースコード

Swift組のコードはこちら。

ペアプロTDDを楽しむ会 in DarkでやったFizzBuzzのお題。 · GitHub

こだわりのポイント

最初はIntの入力値をもとに、FizzBuzz判定の結果をStringで返す実装をしようとしていたが、「Stringで欲しいかどうかというのはPresentation層の話ではないか」「FizzBuzzの本質に迫るならば、Stringではなく別の型で範囲を絞った方が良いのではないか」という、ペアプロならではの着眼点と相談から、enumでFizzBuzzの結果を判定したところ。

enum FizzBuzzResult: Equatable {
    case number(Int)
    case fizz
    case buzz
    case fizzBuzz
    
    static func ==(lhs: FizzBuzzResult, rhs: FizzBuzzResult) -> Bool {
        switch (lhs, rhs) {
        case (.fizz, .fizz), (.buzz, .buzz), (.fizzBuzz, .fizzBuzz):
            return true
            
        case (.number(let lhsValue), .number(let rhsValue)) where lhsValue == rhsValue:
            return true
            
        default:
            return false
        }
    }
}

func judge() -> FizzBuzzResult {
    if number % 3 == 0 && number % 5 == 0 {
        return .fizzBuzz
    }
        
    if number % 3 == 0 {
        return .fizz
    }
        
    if number % 5 == 0 {
        return .buzz
    }
        
    return .number(number)
}