iOSDC 2018で「設計時空のリファクタリング〜複数アーキテクチャを抱えたアプリのリファクタリング事例〜」というタイトルで登壇します。 #iosdc

はじめに

こんぬづは、アニメ『シュタインズゲート・ゼロ』では、劇場版のアンサー的な作りとなった8話で涙腺崩壊した田中です。

さて、一昨年、昨年に引き続き今年もiOSエンジニアのための国内カンファレンスである、iOSDC登壇させていただくことになったので、トークの宣伝をします。 これが世界の選択か...。

iOSDCってなに?って方は↓をご覧ください。

dev.classmethod.jp

トーク概要

これよりオペレーションスクルドの概要を説明する。

長く続くアプリ開発において、複数のアーキテクチャが積層のように負債となってしまうことは、割と多くの現場で起きているのではないでしょうか。
より良い開発をしていくためには負債の返済という、痛みを伴う対応を迫られるときがいつかきます。
このトークでは自分が直近で直面した負債の返済について話をします。
どう返済していったのか、チームとどうやって足並みをそろえたのか、様々な反省をお伝えします。

設計時空のリファクタリング〜複数アーキテクチャを抱えたアプリのリファクタリング事例〜 by ダンボー田中 | プロポーザル | iOSDC Japan 2018 - fortee.jp

最近関わりのあるプロジェクトでのリファクタリングの話をします。 このプロジェクト以前でも、時間の経過とともに部分的にアーキテクチャが書き換えられたものであったり、入り乱れたものをいくつか目にしてきました。 古い地層のコードは、負債となることがままあります。これを改善するためにどんなことを実践しているか喋ります。

またアーキテクチャに限らず、負債となるコードにはさまざまなパターンが存在します。 それぞれにどう対応したのか、ありがちなパターンに絞って紹介しようと思います。 staticおじさんを許すな。

このトークがみなさんのより良き開発ライフにつながればと思います。エル・プサイ・コングルゥ

AppCodeにissueを投げてみた

はじめに

おばんです、とうとうAmazonリズと青い鳥の公式設定資料集を買ってしまった田中です。

先日セールをやっていたので、AppCodeを本格的に使い始めています。 AppCodeはIntelliJなどで有名なJetBrains社製のIDEです。

www.jetbrains.com

いい加減Xcodeに対する不満を唱え続けるくらいなら、新しい選択肢を模索しようと使い始めました。 今のところXcodeと違うデザインに目を慣らしたり、使い慣れたキーマップを設定すれば、機能は豊富で非常にパワフルだと感じています。

そんな中一個だけ、XCTestでContextを記述するためのXCTContextを利用したときにfatalErrorで落ちるという問題にぶち当たってしまったので、issue trackerにissueを立ててみました。

AppCode上でXCTContextを使うとfatalErrorになる問題

現象が自分の環境のみで起きていることかもしれなかったので、AppCodeを以前から使っている @orga_chem さんに相談したところ、issue tracker上で"XCTContext"で検索をかけても類似するものが見つからないという結論に達して、issueを立てることにしました。

↓が投げたissue。

https://youtrack.jetbrains.com/issue/OC-17586

まだ解決には至っていませんが、とりあえず「"Affected vertions" (影響のあるバージョン)をつけ間違えてるぞ」ってJetBrainsの人に修正されたので、見てはもらえていそう👀

続報に乞うご期待。

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

はじめに

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

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

testnight.connpass.com

内容

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

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

感想

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

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

はじめに

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

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

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

みどころ

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

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

おすすめ読者

  • 「百合ってどういうもの?」という人
  • 百合が好きな人
  • 百合に入門中の人
  • VTuber(特ににじさんじ方面が好きな人)

関連キーワード

  • 百合
  • 裏世界ピクニック
  • 「百合について語るな、百合をやれ」
  • 百合に対する認識を振り返る「9つのアップデート」
    • 界隈にありがちな共通認識
    • 歴史的経緯
    • あるある
    • タブー
  • 強い百合
  • ジャガーマンシリーズ
  • ここすき
  • BanG Dream!バンドリ!
  • リズと青い鳥
  • Vtuber
  • お泊り配信
  • 百合とギャングスタラップは同じ
  • エモい風景は、それだけで百合
  • かつてそこには2人がいたんだ

Designer X Engineer Lovers(DXEL)第一回に参加してきました! #dxel

はじめに

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

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

engineers-x-designers.connpass.com

アイスブレーク

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

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

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

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

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

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

「約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回目)

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

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

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

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


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

qiita.com

でもVTuberの音声なんてどこで手に入るの!?

BOOTHで買いました。

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

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

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

はじめに

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

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

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

参加の目的

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

参加する前にやったこと

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

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

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

参加してわかったこと

UMLには複数種類ある

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

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

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

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

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

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

nスイッチカバレッジ

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

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

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

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

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

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

twitter.com

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

twitter.com

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

twitter.com

深夜の分科会

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

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

twitter.com

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

感想とその後

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

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

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