『iOSアプリ設計パターン入門』を書き続けた約半年を振り返るエモブログ

おばんです、すごく遅れて話題のアニメを見ている田中です。メイドインアビスしんどいアニメですね...、楽しかったです、二期はよ。

さて、今回はPEAKSから出版された『iOSアプリ設計パターン入門』が、企画から半年以上続けてようやっと購入者の方々に届き始めるに至ったので、その期間で溜め込んだエモをぶち飛ばしていくぜ!!!🚀💥 (電子版は出ているなうです、製本版はもうしばしお待ちください🙏)

本を書いている期間は忙しくてあまり経過を書けなかったので、特に記憶に残った出来事を振り返ろうと思いました。 幸せも苦しみも全部詰め込みます。


peaks.cc

『iOSアプリ設計パターン入門』は技術書クラウドファンディングのPEAKSから出版された、iOSアプリの設計パターン本です。 現場で活躍するiOSエンジニア複数人で書き上げた生きた技術書です。

まずはじめに応援してくれたみなさま、ありがとうございます!そしてお待たせしてすみません! この本はありがたいことに、正式版リリースまでに1377人もの方に予約いただきました。 読者、企画、編集、執筆、様々な担当の方々によってこの数字を達成できたことを、とても喜んでいます。

技術書の始まりでやたら感謝しまくる海外の執筆者いるじゃないですか、今完全にあれです。今すべてに感謝しています。 あわよくば、「この本を書くにあたり、支えてくれたシンディへー」みたいな恋人に宛てたアレとか書けたらよかったんですが、あいにくーーー🤤

これは余談ですが、1377冊の購入って、技術書のくくりだとすごい数のようです。 小説だと「何万部突破!」とか目にしますが、一般的な書店に並ぶような技術書は、購入者の母数が多い入門者向けの本でも2〜3000部が初版でそれっきりということも少なくないということを風の噂に聞きました。 しかもクラウドファンディングでの達成。PEAKSの積み上げてきた圧倒的信頼を感じます。

このあとに一般販売もあるはずなので、お楽しみに!

すべてはここから始まった

PEAKSのながのさんとのTwitterでのやりとり。 完全にノリです。

f:id:ktanaka117:20181202164628p:plain

なんなら巻き込みも発生。

f:id:ktanaka117:20181202164644p:plain

ここから設計に心当たりのある、確実な執筆陣に声をかけていってプロジェクトはスタートしました。

キックオフミーティング

おかげさまで開始から半日ほどでクラウドファンディングは達成しました。爆速です。

ミーティングは執筆者それぞれで書きたい章構成を持ち寄って、つき合わせました。

  • 設計には多くの派生や誤解が存在しているので、全体をとりまとめる難しさがある
    • 初出に立ち返って情報を整理することで、オリジナルのアーキテクチャパターンのキモが、iOSではどう取り扱われるべきかをまとめる必要があった
  • 設計を学ぶ上で、コンセプトを追うだけでは正しい理解が難しく、コードを書くことでアーキテクチャパターンに対する認識が合う
  • いついかなる時でも通用する、絶対最強のアーキテクチャパターンは存在しないということを伝えていきたい

などの話し合いを元にして、思っていたよりもサクっと大枠は決まりました。 この時点で執筆陣全員がこの共通認識や課題感を持っていたのは、非常にプロジェクトを進めやすく、心強かったです。

合县

  • 進捗どうですか?(圧
  • 改めて認識を合わせる
  • 一気にかき上げようゼ

などなどの目的から執筆合宿に行きました。 気分は文豪です。その時の様子は、以前のブログにまとめました。

tanakalivesinsendai.hatenablog.com

合宿では調べた内容を話し合ってつき合わせたり、理解に間違いがないか確認していきました。改めて当初の目標や課題に間違いがないことも確認できました。 執筆に対する意識やモチベーションも上り調子でした。

無

合宿で持ち上がったモチベーションでしたが、その後は安心からか無の期間が発生しました。 おおまかに書けていた部分は多かったですが、無になると筆も遅くなって出てくるものがなくなり、そこには無限の苦しみがありました。

書きたいものはあるんだけど、良い言葉に乗らない。 普段書き慣れたブログでは、起きないことでした。 ブログを書き始めた頃を思い出していました。

「助けて」を言う

あれよあれよと時間は過ぎて、もう本当にどうにかしなければいけなくなって、プロジェクト内で相談。 筆が進まない部分を整理して、鈴木さん、杉上さん、加藤さんを中心にヘルプを出しました。 担当章の中では一番慣れの少ないMVVMで多くの助言をいただいたり、スケジュールの調整などで助けていただきました。 ありがとうの言葉では足りないものですが、本当にありがとうございました。🙇‍♂️

そしてストレスで胃がマッハ。 燃えたプロジェクトとか、元カノとの別れ話とか、過去これまでに味わった様々な辛い状況がなぜかフラッシュバックして、脳死しながらもなんとか手を動かしました。

立て直し

気持ち面で死んで「なんで書くんだっけ」を見失っていたので、この本を書きたかった原体験を整理しました。 そのときEmo issueに貼っていたのがこちら。

f:id:ktanaka117:20181202181653p:plain

限られた業務時間の中できれいに整えられたコードが書けず、目標とする正しい形がわからないまま書き進めるプログラミングは、非常に苦しいものでした。 なんとか汚いものを組み上げれてやり過ごしたとしても、後の自分自身の首をしめました。 自分以外が担当することになっても、苦し紛れのコードは git blame という悲しみの連鎖をうみます。

いざ「設計」というものに出会い、その目的がなんとなく理解できても、概念的な解説が多くて理解できず苦しむ日々が続きました。

画像の「当時の自分」「昔の自分を助ける」というのは、このような状況を指します。 自分と同じように苦しんでいる人の助けになれてこそ、過去の自分を救うことに繋がるというのが、この本を書くモチベーションでした。

モチベーションを思い出して、なんとか筆を持ち続けました。 「イケる!」「無理...」の躁鬱を繰り返しながらも、イケる気持ちのときに足りていない情報を整理して、構成を立て直しました。 論文を読み返したり改めて説明が必要な部分を洗い直すと、良い筋道が見つかり、内容が濃く自分で納得できるものが書けました。

反省

立て直しはできたものの、プロジェクトは遅延してしまい、先行購入者のみなさまには大変ご迷惑をおかけしました。深く悔やんでいます。 遅延の報告ではPEAKSにかけてしまった迷惑も、申し訳ありませんでした。

もし次に本を書くとしたら、以下のことについて基準を設けて臨みます。

みんなで「おつかれさま」を言えた

自分はなんらかのプロジェクトをやると、その後連絡が途切れたり、迷惑をかけすぎて関係修復するのも申し訳なくなるようなことも過去には多く経験してきました。 正直プロジェクトを始める前から不安だったけれど、それを加味しても世に出すべきテーマの本だと思ったので、「おつかれさま」をみんなで言えたときは本当に泣きました。 (loveeさんのお疲れ様はタイミング合わなくて見つからなかったけど、仲良くやっていますw)

f:id:ktanaka117:20181202190326p:plain

f:id:ktanaka117:20181202190344p:plain

f:id:ktanaka117:20181202190533p:plain

f:id:ktanaka117:20181202190356p:plain

f:id:ktanaka117:20181202190546p:plain

さいごに

紆余曲折はありましたが、最高の本を仕上げられてとーにーかーく、嬉しいです。 これから読者のみなさまの元に届いて、参考に、そして楽しんでもらえる本になれば完全なるプロジェクト成功です、お楽しみに!!!

おまけ

f:id:ktanaka117:20181202191320p:plain

心理的安全を担保するために、友達同士で設計について語る会を開いた

はじめに

おばんです、最近腰が痛くて爆発🚀💥している田中です。

今日は心理的安全を担保した設計の勉強会をやりました。 コンセプトはこんな感じ。

「設計」というと「怖い」という語がうしろにきがちなテーマなので、見知った人を集めて小規模に、心理的安全性を高めつつやろうと思います。 解釈が合ってる、間違ってるとかは気にせず、気軽にYATTEIKI。

設計の話ってマサカリが飛び交いがちで、いろんな人のいろんな解釈があって怖いということには共感していたので、「じゃあひとまず友達同士でやったら、心理的安全を担保しつつ、認識のすり合わせとかできるのでは?」と思ったのでやりました。

参加者の一人であるハゼさん(@haze_it_ac)もまとめを書いてくれました。

hazediary.hateblo.jp

やったこと、話したこと

自己紹介

  • 初めてリアルで顔を合わせる人同士もいたので、名前とidを言ってもらった
  • 普段やっていること、得意とすることによって「設計」という言葉に持っているイメージは異なると思ったので、技術領域とかを言ってもらった
  • 主な参加者の技術領域のキーワードは次のような感じ
    • iOS, Webフロント, バックエンド, Jenkins, AWS, Unity
    • Swift, Go, Python, Java, C#, PHP

設計とは

  • いろんな種類の設計がある
  • 設計にもいろいろあるので、どの設計の話か絞って、その設計に必要なものは何かから話がしたい
  • たとえば
    • アプリケーション設計
      • GUIに関する知識
      • プラットフォームに関する知識
    • インフラ設計
      • ネットワークに関する知識
      • セキュリティに関する知識
    • 「どこを専門にするかの話はあるけど、それぞれ関連しないわけでもないので、知識はあったほうが良いよね」という話も出た
  • 参加者がアプリケーションエンジニアが多かったので、ひとまずアプリケーション設計という単位に絞って話を進めることになった
  • この前提をふまえて、みんなはアプリケーション設計について何に困っているの?をざっくばらんに話していくことになった

フレームワークに依存したコードが辛い問題

MVホニャララがわからん問題

  • 「GUIアーキテクチャ」と「システムアーキテクチャ」という分類がある
  • GUIアーキテクチャ
    • MVC, MVP, MVVM, Flux, Reduxなお
    • UIに重きを置いてパターンの分類
      • Model: 画面に関係ないものすべて
      • View: 画面の表示
      • Controller/Presenter/ViewModel: ModelとViewの間でどうやり取りするか、どうデータを同期させるかなど
  • システムアーキテクチャ
    • ヘキサゴナル, オニオン, クリーンなど
    • UIよりも大きな範囲であり、Modelの部分にどういうパターンをあてはめるべきかまで語られている
    • layerという概念もあり、描画に関わる部分・アプリケーション固有の部分・外部のシステムとつながる部分・データそのもの まで語っている
  • なぜパターンで混乱するのか?
    • 人によって解釈が違うから
    • 例えばMVPの中でも色々な形があり、それが広まるごとに人々は誤解していく
    • 原点と、開発メンバー間で簡単にでも、コードに落とし込んで認識を合わせるのが大事
      • データの同期方法、
      • データの置き場所など
  • GUIアーキテクチャのパターンはいろいろあるけど、データの同期方法と、どこにどういうデータを置くかの違いを把握していくとわかりやすい
  • 具体的な書き方がわからん!問題
  • GUIアーキテクチャとシステムアーキテクチャの違い
    • サーバーサイドとクライアントサイドで関心が違う

アーキテクチャの管理をどうやっていくか問題

  • 依存関係の把握とか
  • コードレビューでカバーする
    • 組織がスケールしない場合はこれで回る
    • 「強いレビュワーがやめたらどうなる?」
      • 「知らんのか」
      • 「組織が死ぬ」
      • 正確には強いレビュワーが辞めてしまう状況が出来てしまったら、組織が死んでいるという話
  • ドキュメントでカバーする
    • ドキュメントの解釈違いも発生する...
    • そもそもドキュメントが古いとか、足りないとか...
  • レビューのタイミング
    • 実装する前のレビュー
    • 実装した後のレビュー
    • 実装する前のレビューの認識が合っていなければ、実装した後のレビューも合わないよね
    • 実装した後にレビューすると、設計がダメだった時の手戻りコスト高いよね
    • Design Doc
    • コードの近くにREADMEを置いて設計の話をまとめておく
      • 各パーツの大本となる部分のディレクトリに置いておく
      • 少なくともその時点での設計の意思決定の経緯をまとめておける

とまあ、こんな話をとりとめもなくざくざく話していったりしました。

開催して感じたこと

  • 思ったことを言いやすかった
  • iOSアプリ設計本は書いたけど、準備なしで口頭で喋るときにまだうまく言葉が作れていない部分があることがわかってよかった
  • バックエンドのエンジニアにとってGUIアーキテクチャはなじみがない
  • リモート参加の人向けの配信は、小規模であれば機材を強化して準備すれば出来そう(リモート参加の人がいた)
  • 設計の経緯や判断をどうやってまとめていくかという方法論が知れてよかった
  • GUIアーキテクチャの勘所みたいなのは、どこかで整理して発表してもよさそう
  • 事前にもう少し「設計で困っていることはなんですか?」的な話をまとめておいてもよかったかも

「百合ダンボールのiOSブロガー」の個人名刺を作っていただきました!

おばんです、「週末なにしてますか?」という質問に「本書いてます」(response time 0.018s)と答えるのが板についた田中です。

本を書くのが日常になっているかたわら、知人の経営する株式会社UZUMAKIに依頼して、個人名刺を作っていただきました! 今日はこの名刺を作った動機とか、制作過程、秘話、UZUMAKIの宣伝などをします!

個人名刺を作った動機

自分は会社での活動以外にも、イベント・コミュニティ運営など個人での活動も多くしています。 前職からずっと会社の名刺しか持っていなかったのですが、会社の人間ではない自分をアピールするために、 個人名刺が欲しいと前々から思っていました。 会社の名刺でも良いのですが、「今の自分は別に会社の人間として居るわけではないし、所属は関係ないな」と思う機会がたびたびありました。

あとは単純にオシャレな個人名刺が欲しかった!

作るに至った経緯

UZUMAKIの工藤(@ToraDady)さんとたまたま飲んでいたときのことです。

田中「個人名刺ずっと欲しいんですよね」

工藤さん「ダンボーさんiOS界隈で顔が広いし、作った名刺は配るとうちの宣伝にもなるから仕事として受けましょうか?」

田中「おっ、YATTEIKI💪」

個人名刺の制作が決定しました。 イベントにうろうろ出まくってると良いこともあるものです。 工藤さんとは以前から面識もあり、信頼度も高かったので即決でした。

名刺作りの進め方

作ることが決まったので、さっそくリモートで依頼して作っていってもらうことに。 飲んだ席以降、直接顔を合わせてアレコレすることもなくて、とてもやりやすく良い体験でした。

自己紹介

基本的に打ち合わせはGoogleハングアウトを使って、デザイナーの日野(@pinopo_)さんと工藤さんと3人で進めました。 たまたま通信環境の悪い場所にいてぷつぷつ切れる工藤さんを心配しながら、初対面の日野さんとも打ち解けていきました。

最初は自己紹介が必要でしたが、名刺がまさにそれなので、自己紹介から着想を得るという流れで打ち合わせをしました。 ちょうど転職したてで、会社で使った自己紹介プレゼンで話をしました。

f:id:ktanaka117:20181106233155p:plain f:id:ktanaka117:20181106233216p:plain

ほとんど百合作品について話した記憶しかありません。

情報整理

その後で載せる情報の整理をしていきました。 さすがに自己紹介してすぐに「このテーマで!」とはならないので、Twitterやブログのリンクなど基本情報をもとに、 「百合」とか「ダンボールのアイコン」とか「ブロガー」「iOSエンジニア」なんかのキーワードを載せる方向で、各自宿題に。 日野さんにはそれらの基本レイアウト、色やアイコンのいくつかのパターンを出していただいて、何度か打ち合わせを繰り返して完成の運びとなりました。

悩ましかったポイント

自分の内面を表すむずかしさ

iOSの人とか、ブロガーとか、イベント運営の人とか、外から見てわかるステータスはすぐに出てきたのですが、 普段の仕事の延長として以外の、個人を示すものを表現するのがなかなか難しかったです。(それだけ仕事ばっか(趣味と混じってる)ということでもありますが。)

趣味を列挙したりもしましたが、最終的にはデザイナーの日野さんの提案もあり、一番心の底から好きな百合に一極集中させたデザインにしていただきました。 「百合ダンボールのiOSブロガー」的な覚え方してもらえそうな感じになりました!

f:id:ktanaka117:20181106233847j:plain

百合の抽象化のむずかしさ

けれども百合に対しては、人一倍敏感であった。

当初は百合に対して変な玄人感を出したい欲が出ました。 たとえば二つ並んだブランコの距離感とか、そこに二人がいるイメージとか、直接的ではなく間接的なイメージで伝えようとしていました。 その場にいたメンバーに言葉を重ねてようやく理解してもらえはしたものの、抽象的なものは表現しづらく、伝わりづらさがありました。

最終的には百合の花というわかりやすいアイコンに絞って、自分の持つ百合のイメージを洗練させていく方法にして正解を導き出しました。 ここにはとてもワガママを聞いてもらって、パターンを作ってもらったりなど...。柔軟に対応してもらえて最高でした...。

f:id:ktanaka117:20181106233334p:plain f:id:ktanaka117:20181106233351p:plain

神対応と言わざるを得ない...🙏

感想

そんなこんなで念願の個人名刺を手に入れました。 ちゃんとお金もお支払いしまして、一件落着( ˘ω˘ ) お仕事方面以外の自分の素性を整理する良い機会にもなったし、デザインに対してお金を払う機会その2を得て、制作プロセスも体験することができて、一石三鳥でした! 工藤さん、日野さん、UZUMAKIさん、ありがとうございました!!!

実はまだこの名刺、ちゃんと配れる機会が持てていないので、僕にあった人はぜひ声をかけてください。 次に出没するイベントはCI/CD Night Day2です。

UZUMAKIはこんな会社です

今回依頼したUZUMAKIさんは、本来Web系のお仕事を受けている会社です。 名刺を依頼したことからデザインはもちろん、エンジニアやディレクターの方々もいらっしゃいます。 企業としてはもちろん、チームとしての働き方に重きを置いていて、プロダクト作りに対して最適な動き方を模索しながら仕事を進めていきます。

uzumaki-inc.jp

最近だと代表取締役の工藤さんがリモートワークに関する記事を書いていました。

note.mu

この記事をきっかけに、方向性が合いそうだという方がいらっしゃれば連絡を取ってみてください。 仕事の進め方は、確実でした。以前からの付き合いもありましたが、今回の件でより一層信頼できる方々だと思いました。 (僕ともまた機会がありましたら、よろしくお願いします💪)

「ソフトウェアテスト気になる!でも全然わからん!」から「ちょっとわかる!楽しい!!!」になった2年弱を振り返る

おばんです、最近LoLばっかやってる田中です。リサンドラmidにハマってます。

今回はなんとなく、テストとの付き合いについて振り返りたくなったので振り返ります。 自分とテストの付き合いはだいたい2年弱が経とうとしています。 「全然わからん!」→「テスト楽しい!!!」までの2年弱の道のりです。

こんなことを書いていきます。

  • 前はどうだったか
  • 今どうなってるか
  • 今に到るまでなにをやってきたか
  • 特に印象的だったポイント
  • これから

前はこうだったよ

ここでする話は、もうズブズブの素人思考満載のはずかしトピックですが、同じように悩んだり考えてる人は多くいるのではと思います。 「わかるー」ってところがあったら「わかるー」って言ってくれるとエモです。

テスト全然わからん!

  • だいたい2年くらい前の頃の話です。
  • その頃は「とにかく実装するんだ!!!」という気持ちばかりでした。
  • 「まあ大丈夫!軽くデバッグした!動く!僕の書いたコードは最高!」という謎の自信もありました。
  • (自動)テストは大事だよとかよく言われてますが、無くても意外とどうにかなっていた。

厳しいデグレ、デバッグ、手動テスト

  • でもそれは、ただ自動テストが無くても意外となんとかなる規模の開発をやっていたに過ぎませんでした。
  • ちょっと大きな開発だと、たまに厳しいデグレが起きたりしました。
  • デバッグや手動テストがしんどいこともありました。
  • でも期限は決まっているので、なんとかメジャーケースは非効率な手動テストをこなすことでクリアしていました。
  • 開発終盤の、コードを書く時間 <<<<< 手動テストの時間には苦痛を感じていました。

ぼんやりした設計に対する考え

  • 大きな規模の開発では、テストよりもアーキテクチャパターンに対する興味が先行しました。
  • CleanArchitecture -> MVP -> etc...という感じで学び進めて、なんとなくの理解を得ていました。
  • しかしテストに対する理解は少なく、その効能は半減。
  • 「秩序が生まれてコードが読みやすくなる」程度の、少しぼんやりした理解でした。

プラットフォームを問わず幅広く活用できるスキルへの憧れ

  • これまでの項目より少し話が逸れますが、ずっとプラットフォームを問わず幅広く活用できるスキルへの憧れが強くありました。
  • アーキテクチャパターンについて学び、まとめ、発表していくことで、その力がつく実感がありました。楽しかった。
  • アーキテクチャパターンについて学んでいくことで、地続きの話として「テスト」があることに気づいて、次の幅広スキルはコレ!と思うように。

今こうなってるよ

苦しい恥ずかしい状況から、テストについて学ぶことで次のようなパワーアップを果たしました。

設計に対する指針が出来た

  • 設計の主な目的はメンテナンスしやすさだと思ってます。
  • 可読性と、変更のしやすさと、そんな感じです。
  • アーキテクチャパターンを学んでいるだけだと「可読性が上がる」のみで、変更のしやすさ=壊していないかどうかに対しては弱くて、片手落ちです。
  • 壊していないかどうかはテストによって担保していく領域で、設計のスキルとは相互補助の関係にあります。
  • どっちもやることで、「「「力」」」がつきました。

開発が早くなった?

  • コンパイラで推し進める書き換えと、テストで推し進める書き換えの使い分けができるようになりました。
  • インターフェースの修正はコンパイラによって検査されて、実装の修正はテストによって検査されます。
  • 今自分が行なっている作業がどっちなのか理解することで、どういう検査をしなければいけないかはっきりさせることができました。
  • インターフェースの修正をしただけなら、ビルドするだけで正確さが確認できます。
  • テストのある箇所に対して実装の修正をしただけなら、テストを走らせることで(だいたいの)正確さが確認できます。
  • この使い分けはTDDを学ぶことで違いに気づけました。仮実装・明確な実装・三角測量、コンパイラ・テストの使い分けという感じです。
  • 気持ちよく、テンポよく開発を進められるようになって楽しくなりました。
  • ただし取り組む開発の規模や課題も難しくなったため、単純な比較が難しくなりました...。なので、「たぶん」早くなったという認識です。

本が書けた

  • 技術書典4に参加するために、ちょうどハマっていたテストやTDDについてまとめて書く機会を得ました。
  • 『Swiftで書いておぼえるTDD』という本を書きました。SwiftでTDDを解説していく本です。
  • これは同人誌として出しましたが、商業誌化もしました。今ちょうどKindle版がセールやってます。気になればポチ!
  • 「商業誌デビュー」という実績を解除しつつ、同人誌版をBOOTHというサービスで出したことをきっかけに転職もしました。
  • とんとん拍子すぎて、「テストを学ぶことで、こんなに成功しました!」という、雑誌の最後の怪しい広告みたいになってる。ウケる。

今に至るまでこんなことしてきたよ

いろんな良いことにつながりましたが、ここに至るまで色々なことがこの2年弱でありました。 どれも楽しいことでした。

イベントへの参加

  • そもそもテストを「学ばなければいけないきっかけ」を登壇駆動で作りました。iOS Test Night #2での登壇です。
  • 最初は教科書写したみたいなすごく恥ずかしい発表内容でした。
  • 「やろうやろう」と思ってやり始められない時は強制的に締め切りを作るライフハックです。登壇駆動学習。
  • これをきっかけに学び始めた、ユニットテストの書き方、Test Double、サービス開発におけるバランスはエンジニアとしての成長に凄まじく影響を与えました。

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

  • 「単体テストの書き方」みたいな話はネットでざっくり読んでやっていましたが、ソフトウェアテスト一般に関する話や項目の洗い出しについてなどはわかっていませんでした。
  • そういうのは体系的に本を読むのがよくて、この本はわかりやすくてよかったです。
  • 前職の本棚に置いてあるのを読みつつ、@tarappoさんに転職祝いとしてプレゼントしてもらいました。今でもたまに読んでいます。

@t_wadaさんのハンズオンや講演への参加

  • 国内のテスト駆動推進者である@t_wadaさんの講演や、TDDBCへは以前から何度か参加していました。
  • 実体験を重ねつつ、プロダクトで実践するための経験値が得られました。
  • 実は5年くらい前、学生時代にはすでにTDDBCに参加していましたが、その頃はプログラミングもしょぼしょぼだし、テストのありがたさもわかっていませんでした。
  • 実務経験がないと理解できない、規模がそれなりの開発でないとありがたみを体感できないというのはあると思いました。

『テスト駆動開発』との出会い

  • イベントに参加したりあれこれしているうちに、バイブルが発刊されました。
  • あまりに面白くて、なんども読み返して、触発されて本を書いてしまうほどのものでした。
  • この本はJavaで書かれていますが、自分はJavaScriptとSwiftで書きました。
  • 言語によって歩幅の差があったり、環境の違いがあることに気付いて、Swiftプログラマにとっての敷居を下げるために、Swiftで解説した本を書きました。
  • TDDは言語によっての向く場面、向かない場面の差があったりするということが良い気付きでした。
  • この話を一般化して、向く場面、向かない場面というのはいろんな物事にあって、設計においても、プロダクト開発においても、ツールの使い分けの判断ができることは「強さ」に繋がるということに気付けたのも、エンジニアライフ的にはかなりのインパクトでした。

WACATEへの参加

  • WACATEという、テストエンジニアのためのイベントにも参加しました。
  • これまではコードを書くプログラマの視点の大きなものでした。
  • 一方でQAやテストエンジニアといった、テスト自体に重きを置いて開発に携わる人々がいて、そんな人々と接点を得られたのがWACATEでした。
  • カリキュラムももちろん良いもので、「テストとは!」も勉強になりましたが、それよりも普段接しない人と話をする機会が得られたことの方が大きかったです。
  • 目線が全然違くて、同じものに向き合っているのは確かだけれど、言葉のチャンネルや意識のチャンネルが違うことが面白かった。
  • たぶんプログラムを書く人との間には専門領域の違いがあって、隔たりもあるのだけれど、向いてる方向は同じ感覚だったので、気持ちが良かった。
  • もし開発で関わる機会があれば、言葉や考えを相互に理解すると圧倒的「「「力」」」を得られそうだと思いました。

本の執筆

  • 本を書く熱意が生まれたのは、『テスト駆動開発』を読んだからでした。
  • すごく良いことが書かれていたというのが大きな理由で、それが自分が得意とするiOS/Swiftという領域ではあまり知見が無さそうだったので、ちょうどタイミングがマッチしました。
  • ちょうど技術書典が盛り上がってたので、波に乗れて良かった。
  • 本を書くのはとてつもない重労働です。。。
  • 文字を書くということではこれまでブログを数多く書いていましたが、ターゲットや正確性などのスコープが全然違うので、少しスキルが違かった。
  • ここで本書きを経験することで、『iOSアプリ設計パターン入門』の執筆にもつながりました。
  • こちらは1300人を超える人が買ってくれて、すごい、すごい気持ちです。
  • 技術書でこの売れ行きはすごいらしい。

ターニングポイント

多分ここ2年弱を形作って、次に繋げているのは以下のきっかけ。 人間動くとそこに道ができる。 いただけている機会には感謝しかない。。。

これから

最近転職して、サービス開発をしていますが、まだまだ悩みや苦しみはつきません。 これまでは「動かないマトに当てること」の練習をしてきました。 サービス開発は生き物で、機能開発・リファクタリング・テストのバランスはとても難しいです。 これからは「動くマトに当てること」を練習していく必要があります。 まだまだ試せていない自動化やUIテストの実施なんかがあったりします、絶対楽しいのでやっていきたい。

正直手が足りてないことも一因なので、僕と一緒に働いてみたいとか、興味あるという嬉しいことを思ってくれる人がいれば、お声がけください!!!

さいごに

そう、テストは楽しいんです。 だって特定のプラットフォームに限定した考えじゃないし、うまくすれば実際の生活にも役立てられる幅広いスキルだからです。 しんどい開発はラクにして、気持ちの良い開発を、もっと長く気持ちよくさせるためのスキルです。 この記事でテストを好きになる人が増えたらいいなって思うます。

#iosdc 終わったあと、最高のイベント過ぎて、エモくなって少し泣いた振り返り

はじめに

おばんです、とうとうiOSDCが終わってしまいました、明日は勤労の田中です。

このエントリーはiOSDC 2018を振り返ったエモ散らかしです。嬉しかったこととか、来年に向けた抱負などを書いていきます。

本を評価してもらえた

エモから生まれたエモ太郎。

最近尊敬してやまない、ベストトーク2位を取った @orga_chem さんのスライドの中でも引用してもらっていて、またしてもエモ。

speakerdeck.com

@akio0911 さんの手ほどきでウテナとピングドラムの理解が進んだ

ちなみにこのツイートにぶら下がったメンションにすごく話が続いています。 いろんなメタファーとか、話のつなぎを聞いたので見直したくなった。 映画版を見たらまた語りたい。

デザインを依頼してスライドのクオリティを上げられた

tanakalivesinsendai.hatenablog.com

楽しい仕事になったようでよかった!あとお仕事ゲットにもつながったようなので、こちらとしても嬉しい。

昨年のトークが引用された

嬉しいけど、こじれそうな暗黙的な文脈もあるので、やりすぎると老害になりそうだとも思った。少し静かに生きようと思った、うそだけど。

書いたブログが引用された

こないだなかなかに苦労して実装して、まとめた機能について、スライドの中で取り上げてもらえたのめっちゃ嬉しかった!これまで引用してもらえたのはあまりなかったので嬉しい!

inside.pixiv.blog

speakerdeck.com

「iOSアプリ設計パターン雑談」ができた

アンカンファレンスの使い方を心得た感じあった。

togetter.com

会社で作ったノベルティとTシャツのウケがよかった

転職早々、ピクシブのスポンサー作業担当に任命されたので、社の人と連携して頑張って作った。そうしたらすごくウケがよかったのでホッとしている...。

こんなトラブルもあったけど、堪忍やで!!!

その他良かったことざっくり

  • 面白いトークができた
  • 面白いトークを聞けた
  • 試してみたいと思えるワクワクする技術に出会えた
  • 多くの人と話した
  • プロダクトを良くしたい、もっと使ってもらいたいと思えた
  • プロダクトの問題点や、より良くするアイデアを得られた
  • 日本で出来ない経験をした人と話せた
  • Q「転職おめでとうございます!楽しいですか?」って聞いてもらえた
    • A「圧倒的楽しい」って言えた

来年に向けて

ベストトーク3位以内に入る

昨年はベストトークの枠が広かったのでなんとか入り込めたのですが、今年は狭まったのもあり入れず...。 個人的に手応えはなかなかにあったのだけれど、ベストトーカーの顔ぶれを見ると、技術的にも取り組む課題的にも全然足りないなと思った。

前夜祭を少しは盛り上げることができたと思ったので、自分がやるべきことはできたと思うし、順位が大切なわけではないけど、もっと評価されて価値のあるトークにしたい。後から何度も見直される価値のある資料を残したい。YATTEIKI💪

さいごに

「人を巻き込み活性化する、iOSDCコミュニティの一員です。」というアナウンスがエモすぎた。完全に同意。

iOSDCはやさしい世界すぎる。リアクションがちゃんとあって、良い感想を伝えてくれる。

こんな振り返りを帰り道でしていたら、空は晴れてたけど少し雨が降った。

iOSDC 2018 Interactive Round Table テスト相談会に参加してきました #iosdc

はじめに

おばんです、クックパッドのブースに展示されていたゲームが面白過ぎてランキング入りを果たした田中です。明日はもっと上のランクインを狙う。

iOSDC 2018の1日目の午後には Interactive Round Table という、あるテーマに集まって議論するコーナーがありました。 「テスト」というテーマで興味があったので参加しました。

togetter

togetter.com

Round1

UIテストの話

  • UIテストを書いている人は何人いますか?
    • 7人中3äşş
  • UIテストはないけど、単体テストを書いている人は何人いますか?
    • 7人中4äşş
  • すでに全員自動テストを取り入れていてすごい、iOS界隈でもテストの機運高まってそう
  • id振るのがめんどい問題
  • fuzzing test
    • id以外のユニークなものをみつけてテストする手法
  • E2Eテストの正しさをどう確認するか
    • functional E2E test
  • テスト戦略
    • なぜテストを入れたい?
    • どこからテストを入れる?
    • ↑に応じてなにをやっていくべきかが変わる

どこにUIテストを入れている?

誰がUIテストを書いている?

Round2

Mamorioの @hatakenokakashi さんからの質問

  • CoreLocationやCoreBluetoothなどのフレームワークは境界地あたりだと電波状況や位置情報に応じて状態がフラつくことがある
  • 手動デバッグを行なっているが、とてもコストが高いので、どうやってテストをするのが良いか?
  • どうやってテストで解決すればよいか?
  • これはテストというより設計で解決すべき問題かも
  • 位置情報や電波状況のメンタルモデルをモデル化すれば、入力に応じた状態変化をテストできるので、自動化できる

自動テストをどうやってメンバーに書いてもらうか

コードをクリーンに保てていないと、離職リスクにつながる

こういうことは結構ありそうだと思った。プロダクトに対する愛でカバーできる面があったりもするけど、度が過ぎたりあまりに長い期間だと心が疲弊するので、マネージャーに当たる人にはこういう面もサポートしてほしいかもと個人的に思いました。

さいごに

テスト相談会はRound3までありましたが、僕はRound2までの参加だったので、ここまでをまとめました。

テストに向かっている人たちで、どうすべきか、うちではこうやってるよ、みたいな話をワイワイするのはとても楽しかったです。

カンファレンスのスライドに使うロゴデザインをデザイナーに頼んだ話 #iosdc

はじめに

こんぬづは、カンファレンスに参加すると地方の友人と会って最近の近況を聞いたり、情報交換が出来て楽しい田中です。

昨日iOSDC 2018の登壇を終えて、今はゆっくりカンファレンスを楽しんでいるところですが、休憩時間を活用してカンファレンスのスライドに使うロゴデザインをデザイナーに頼んでみた話を書いてみようと思います。

登壇した話はこちら。

tanakalivesinsendai.hatenablog.com

作ってもらったロゴがこちら。

f:id:ktanaka117:20180831170801p:plain

これに使っている右下のロゴを、友人の優秀なデザイナー、 @noa_design51 に作ってもらいました。

なぜ頼んだか

今回はiOSDC参加も3年目で、好きなアニメ作品であるシュタインズ・ゲートをもじったタイトルにしていたため、気合の入ったスライドが欲しいと思いました。

そういえばシュタゲのサブタイトルのロゴかっこよかったなーという着想はあったのですが、自分ではデザインができないため、友人を頼ってそれっぽいのを作ってもらうことに。

f:id:ktanaka117:20180831170836p:plain
クソコラは無料

f:id:ktanaka117:20180831170846p:plain

感想

こんな良いことがありました。

  • お金を払ってロゴを作ってもらったのでスライド作りに気合が入った
  • 鳳凰院凶真になれた
  • 前夜祭を盛り上げることができた

これまでデザインを人に頼んだりしたことはなかったですが、デザイナーさんの腕が入ると何倍も見違えるので、お金は払うべきところには払うべきという良い体験ができました。 のあ氏ありがとう!!!