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

はじめに

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

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

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

内容

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

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

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

ソースコード

Swift組のコードはこちら。

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

こだわりのポイント

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

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)
}

FizzBuzzにおいて設計的観点がここまで入りこむのは初めてでアツかった。TDDならではの見直しができて、ペアプロの力を実感できたのでとても有意義だった。

参考

転職します。百合転職します。

はじめに

おばんです、5月で転職をする田中です。

ということでこれは転職エントリーです。 前職へのお気持ちは会社のブログに書いたので、こちらのブログではもっと個人的な感情や考えについて書きます。

dev.classmethod.jp

心や感情を大切にしたい

僕は人の心の変化を描いた作品が好きで、人と人との関わりによって起こる変化が好きです。感情の揺れ動きが好き。BLでもそれ以外のものでもなんでも見るけど、そういうテーマを描く作品が多いので、特に百合が好きです。

自分がどんなものに心を揺さぶられるかというと、ごく一部だけどこんなの。

『キャロル』

  • 逃避行から現実に向き合って、どう生きていくか選択する二人
  • 「心に従って生きなければ、人生なんて無意味よ」

www.youtube.com

『名もない雨』

  • 死について考えるし、後悔なく生きたいと思う
  • まわりに居る人との関係性を考える

www.pixiv.net

リズと青い鳥

  • 音、言葉、しぐさ、足取り、目線、全てに感情や意味が乗っていて、演奏表現に乗ってくる
  • 音に当てられて泣き出す吹奏楽部員と映画を見ている僕たち
  • 将来を選ぶということは、選ばなかった人生もあるという青春

www.youtube.com

たまこラブストーリー

  • 人が関係しあう中で発生する優しさが詰まってる
  • ちなみにももせさんという方の「もちたま」と「みどたま」が尊い

www.youtube.com

www.pixiv.net

椎名林檎

  • 変化が歌や作品から見受けられるし、なにより年を重ねるごとに、表現が変わっているのがすごく好き。
  • 『本能』からの、出産・子育てを経た上での『ありきたりな女』
  • と思いきや、『カプチーノ』のような少女みある曲が飛び出てきて萌える

www.youtube.com

www.youtube.com

こんな作品に影響を受けて自分は生きているのですが、

  • さて自分の人生にはなにがあったっけ
  • 誰かに影響が与えられるっけ
  • この選択肢で良いんだっけ

という想いが強くなっていきました。

こんなに素晴らしいものが世の中には溢れているのに、俺が今表現しているものはなんだ?自分の気持ちを表せているのか?世界を作れるのか?

後悔のない方に転がす

作中の登場人物はみな選択して決断していたし、作っている人は作品を通してそういう世界を表現しています。

感情的すぎたり、作品にアテられてしまっているかもしれないけれど、今の自分のあり方は全然心が揺さぶられなかったし、作るものを通して他の人になにか影響することもできない。少なくとも自分が共感できないと価値を出せないと思いました。このままだと後悔すると思って、別の環境に身を置こうと転職を決意しました。

さいごに

次の転職先はピクシブ株式会社です。

昔からpixiv本体のアプリにはお世話になっていたし、同人誌を書いた経験からBOOTHを使い始めたのがきっかけです。クリエイターをサポートするためのサービスづくりに共感して決めました。作家さんの創作活動に少しでも貢献できれば、最高です。

こう決断して、こう動いているのは、数々の百合作品と出会えたからです。だから今回の転職は、 百合転職です。


前職のDevelopers.IOにはもう書けませんが、QiitaやTwitterなどで技術系の情報発信は続けていくつもりですので、乞うご期待!

干し芋のリストシュッ

http://amzn.asia/15FIGjH

ストーリーボードとサービスブループリント

はじめに

こんぬづは、無職の田中です。

最近知り合いのデザイナーさんにデザインについて教えてもらう機会があり、その中で「ストーリーボード」と「サービスブループリント」というものが出てきたので、知識を固めるために自分でも調べ直しました。今回はそのまとめです。

サービスブループリントについては実際にワークショップをやってもらったので、少し分量多め。

ストーリーボード

共感を測るためのツールという印象。(「印象」と書いたのは、ネットをナナメ読みしたからそんなに自信が無いのと、人によって認識が違いそうだったから)

画像や絵を使って、ユーザーの感情や行動をストーリーに落として、そのストーリーに共感できるかどうかでサービスの価値を図ることにつなげる。

ユーザーテストじゃないけど、ストーリーボードを組んで人に見てもらうのは、市場調査段階でやると良さそう。

参考

サービスブループリント

ユーザーがサービスをどこから知り、どんなプラットフォームを介して触れるのか(タッチポイント)に重きを置いている印象。

具体的なビジネスに落とし込んで考えているとも言えそう。 ある記事には「ビジネスセッション」と「テクニカルセッション」という2つのセッションでこのツールを使っていくことが書かれていた。 ビジネスセッションで、ビジネス上の理想形(青写真)を描いて、テクニカルセッションで理想を実現可能な形で落とし込む。

テクニカルセッションを経ることで、サービスを提供することができるかどうか測れるのが良さそう。

参考

ストーリーボードとサービスブループリントの違い

ストーリーボードとサービスブループリントは部分的に一致するところもあるが、サービスを提供する側の行動や提供するものまでを想定しているかどうかの違いがありそう。

ストーリーボード: 市場調査段階でやると良さそう サービスブループリント: 需要が見込めて、実現可能かを測るのに良さそう

という感じ。

感想

f:id:ktanaka117:20180523121640j:plain

違いでも書いた通り、それぞれ「使うフェーズが違う」と思った。

エンジニアは実現可能性に目を向けがちだと思った。 最近自分は技術的な面で1→10にするためのスキルを磨いている傾向にあると思っていて、0→1が弱いと感じていたのだけれど、今回触れた2つのツールには良いヒントがあった。

デザインを考える手法やツールはこれまでいくつか触れてきたことがあって、部分的に一致する様々なものがあるので混乱していた。今回人に教えてもらって、調べたことで「なるほど、こういう違いの傾向にあるのか、完全に理解した(←わかってない)」となれてよかった。

雑な理解だけど、もっと深く知るのはより必要になった時にまわそうと思う。

追記

デザイナーさんとは「本来【デザインする】って言った時は、こういったツール/フレームワークを使って深掘りするところから始めないと、どういう見た目にすればいいかも考えられない」なんて話もした。

確かにこの段階を踏まえないと、どういう目標地点に向けたデザインをすればいいかわからないと思った。これを踏まえないで【デザインする】ことって結構多いんじゃないかとも思った。

仕事を始めるとき、「うちの会社(やり方)ではお客さんとのヒアリングで最初にこれをやるんです」くらいに決め打ちをお客さんに要求してしまってもいい気がした。自前のサービスでも。

僕にはセンスが無いから

僕はセンスが無いと思ってるけど、その分足で稼ぐ性分なんだとわかってきた。

なにかとセンスが良くて一人で調べてシュッとこなしてしまうようなセンスの良い人は、物事をうまく抽象化して理解するのがうまかったり、理解に至る道筋が見える人だったりする。

一方で僕は経験から物事を考えたり、やってみて考えることが主になっている。 なにかを理解しようとしたとき、全体のふんわりとしたコンテキストから理解を得ようとする。文章もナナメ読みするし、国語や英語の問題の解き方もそうだったのだけど、多分そのほかの物事を理解するプロセスも同じ。エンジニアリングに関することもこういう考え方をするので、理解が遅いと感じることが多々ある。

センスの良い人には劣等感を覚える。

けれど「行動する」ことが、センスが無いと思っている自分の生存戦略だとわかってきた。

  • ブログを書いてみる
  • イベントに参加、登壇、運営してみる
  • 友達を増やす
  • 同人誌を書いてみる
  • 技術を学ぶためにサンプルを書いて手を動かす
  • 見たことのない映画を見る
  • オススメされた本や漫画はとりあえず読む
  • やったことのないことはとりあえずやってみる

行動してみると、それまで見えてなかったことが見えるようになるし、なによりそれをやったことのない人より圧倒的に語れることが多くなるのが良い。見えるものが増えると、全く別の物事にも共通したコンテキストが存在するのが見えるようになって、理解が早くなったりする。

本来の言葉の意味とはずれるかもしれないけど、行動しないでいるとどんどん良くないほうに転がっていく感覚に対して、「貧すれば鈍する」という言葉をよく唱えている。行動してみるとわかることが多いし、人生が加速するので動き続けるようにしている。

センスが無いと感じる僕は、足で稼ぐ。


そんなふうにここまで生きてきたけど、最近は行動や経験で得たものをそのままにはせず、一般にはどう捉えられているのかなど、本を読んで理解の軌道修正をするようになってきた。実際に体験することは間違ったことではなくて、本に書いてあることとどういう差分があって、机上だけでなく、現実としてはどうなっているのか理解するように勤めるようになった。この辺りは人にうまく伝えられるようになってくる段階な気がするので、体験したことの軌道修正は楽しい。

様々な環境に依存できることが真の安定

誰かから聞いた話が頭の中に残っているだけかもしれないけれど、依存先が多いことが真の安定であるということを信じている。

大きい会社にいることが安定ではなく、世界から自分が求められ続ける状況こそが安定。

一つの環境に依存して安定を求めるのではなく、様々な環境に依存できる生き方が真の安定。

友達が多かったり、仲良くなりやすかったり、なじみやすかったりも同じ。自分はそういう生き方に安定だけでなく、安心を得ているなと思った。

今は割とできていると思っているので、これからもこの生き方がしたい。

技術書典4で、SwiftでTDDを紹介する本を頒布した後の話 #技術書典

まずはお疲れ様でした!

おばんです、技術書典が最高に楽しかった田中です!ありがとうございました!

技術書典自体も、即売会へのサークル参加自体も初めてでしたが、自分がこれまで読んでた本の作者さんとか、ネットでしか会ったことのない人に会えたのが刺激的でした。

サークル参加で忙しくしたものの、なんとか戦利品を勝ち取ることもできたのでよかったです。

技術書典にサークル参加してきました

こんな本を出しました。

tanakalivesinsendai.hatenablog.com

売り子をして、素敵な表紙を描いてくれた@kiko_twさんには頭があがりません...! 一緒に本を作って参加できて楽しかったです!

感想が届いて嬉しかった

Twitterに続々上がってくる戦利品画像の中に、自分が買いた本もある。 感極まる。

技術書典が終わったあと、内容について質問や意見をくれる人がいてくれてとても嬉しかったです。 個人的にもTDDの話で議論できるのはとても勉強になるので楽しいです。

ぜひ読んだ方は感想とか、気になったところとかを @ktanaka117 までTwitterでメンション飛ばしてください!なんでもしますから!(なんでもするとは言っていない)

支払い状況

  • 現金: 86冊
  • Kyash: 5冊
  • かんたん後払い: 19冊

でした。 価格が1000円だったので、お札でのやりとりでラクできました。 お釣り用意に関して同僚に話したら、「それ諭吉3発で死ぬじゃん」とか言われましたが、余裕でしたw

Pixiv PAYにも対応しようとしたのですが、SMS認証周りの復帰不能バグっぽいのに当たったのでバグレポートしました。きっと近く対応してくれるはず...!

全然印刷数が足りなかった

150部刷って、当日は110部くらい持っていって完売しました。しかも 1時間ちょい

初参加で余るかもしれないと日和っていたのですが、前日から急にサークルのチェック数が伸びて、最終的には124くらいになって、全然足りませんでした。

次はもっと強気で刷っていこうと思います!

近々web販売します!

身の回りやTwitterを見ていると、「手に入れられなくて残念だった」という嬉し申し訳ない声が聞こえたので、PixivのBOOTHあたりに、手元に残っている本を少し出したり、電子版を発行しようと思います!

GW中とかを目処に出しますので、ぜひTwitterとかこのブログをチェックしていてください。 乞うご期待。

技術書典4で『Swiftで書いておぼえるTDD』という同人誌を出展します #技術書典 #く-07

はじめに

おばんです、月ノ美兎のプリクラ機の声がツボにハマった田中です。(動画の10分くらいから)

www.youtube.com

さて本題ですが、明日開催の技術書典4で『Swiftで書いておぼえるTDD』という同人誌を出展します。 このブログでは宣伝として、本の魅力と、執筆にあたって込めた想いなどを書いていきます。

dev.classmethod.jp

『Swiftで書いておぼえるTDD』

「Swift でテスト駆動開発に入門する」本です。

f:id:ktanaka117:20180421192742p:plain

みどころ

  • TDDについてわかる
  • TDDでSwiftを解説する、しかもサンプルコード付き
  • テストと型によって駆動するSwiftらしい設計
  • SwiftでTDDをするときの課題とその乗り越え方

世の中にはJavaで解説されたものが多い

TDDってJavaで解説されたものばっかじゃね...? TDD自体は言語にとらわれない開発手法ではあるのですが、実際のところ、言語によって書き方や設計思想、どういうところをテストしなければいけないかは変わってきます。 仮に初歩的な内容の解説だったとしても、早いうちから言語特有の書き方が出てくるはずで、Swiftで書いた場合どうなるか解説したものは世の中に多くありません。 新しいことを学び始めるときは、なるべくわかりやすくハードルが低くあるべきだと思ったので、Swiftを普段書いている人がTDDに入門しやすいようにしたいという想いでこの本を書きました。

TDD ってなんか難しそう...

自分もそう思っていたのですが、コードを書きながら理解していったらわかりやすかったという経験がありました。 『テスト駆動開発』というバイブルも同じような書き方になっているのですが、『Swiftで書いておぼえるTDD』もそれにならって、コードとともにTDDを解説する内容にしました。 ぜひ本を読みながら写経してみてほしいです。

仕様

目次

謝辞
はじめに

第1章 TDDとは
1.1 TDDのメリット
1.2 TDDのデメリット
1.3 レッド/グリーン/リファクタリング
1.4 チームの理解を得よう

第2章 書いておぼえる TDD
2.1 開発環境
2.2 サンプルプロジェクトのリポジトリ
2.3 演習問題
2.4 ポーカーの言葉の整理
2.5 トランプの言葉の整理
2.6 カードの文字列表記(インスタンスの生成)
2.7 カードの文字列表記(文字列表記の取得)
2.8 カードの比較
2.9 ツーカードポーカーの役を判定(ペア、フラッシュ、ハイカード)
2.10 この章のまとめ

第3章 2018 年現在の Swift での TDD 開発
3.1 ビルドが遅い問題
3.2 モック自動生成ツールが不足している問題
3.3 他のIDEにできることがXcodeにできない問題

第4章 参考文献
4.1 『テスト駆動開発』
4.2 『実践テスト駆動開発』
4.3 『Test-Driven iOS Development with Swift 4』

著者紹介

さいごに

TDDについてディスカッションしたい

今回本を書いて、自分が考えるTDDについて大きめにまとめて、整理することができたと思っています。 読んでみて「ここは良い説明だった」とか、「もっとこう説明した方がよい」というところがあれば教えて欲しいです。 「読んでみた」ブログを書いたり、疑問が生まれたりした人は、この本を書いてよかったなと思うので、ぜひTwitterでメンションください。(@ktanaka117) これをきっかけに、すでにTDDに詳しい人や、これからTDDを始めて疑問が生まれた人と意見を交わせると僕としてはすごく嬉しいです。

ディスカッションだけでなく、SwiftでTDDペアプロする活動というのを最近やり始めています。 一回やってみた感じだと、どういう設計思想でコードを書くか、どういう観点でテストを書くかという考え方を共有できるのでとても有意義でした。 僕からもお誘いする人もいると思いますが、逆にお誘いしてもらえたら嬉しいので、声をかけてください。