メドピア開発者ブログ

集合知により医療を再発明しようと邁進しているヘルステックカンパニーのエンジニアブログです。読者に有用な情報発信ができるよう心がけたいので応援のほどよろしくお願いします。

Swift Concurrencyのキャンセルと向き合う

メドピアでモバイルアプリを開発している小林(@imk2o)です。 惑星直列に興奮しています。

Xcode13.2より、iOS13以降を対象にしたアプリであればSwift Concurrencyを利用できるようになりました。従来RxSwiftやCombineなどのReactive Streamを利用しているプロジェクトのSwift Concurrencyへの移行を進める際、考慮しなければならないことのひとつが「キャンセル」の扱いです。

以下に記載するコードとその挙動は、Swift5.6(Xcode13.4)とSwift5.7(Xcode14 beta)で確認しました。

Taskのキャンセルの仕組み

非同期処理を実行する Task オブジェクトは cancel() メソッドを持っており、これを明示的に呼び出すことでキャンセルができます。 Task がキャンセルされると通常 CancellationError が投げられますが、catchブロック内では Task.isCancelled の値をチェックする方法が推奨されています。キャンセルされた場合は直ちに return するほうがよいでしょう。

let task = Task {
  do {
    let result = try await someRequest()
  } catch {
    guard !Task.isCancelled else { return }
    // TODO: Handle error
  }
}

...

task.cancel()

Combineの AnyCancellable は破棄のタイミングで自動的にキャンセルされていましたが、 Taskcancel() を呼ばない限り、キャンセルされません。 Combineにおいては購読するストリームを Set<AnyCancellable> などで持っておき、ViewController(以降、VC)やViewModel(以降、VM)の破棄とともにキャンセルされるものと考えていましたが、Swift Concurrencyにおいては、

  1. VC/VMの破棄とともにキャンセルされる仕組みを導入する
  2. キャンセルを諦め、割り切る

のどちらで実装するかを考える必要があります。

Taskのキャンセル考慮は意外と険しい

VC/VMクラスのdeinitで cancel() すればよいかと思いきや、実はいくつかのハマりどころがあるのです。こんなViewModelクラスを考えます。

@MainActor
final class EchoViewModel {

    init(echoService: EchoService) {
        self.echoService = echoService
    }
    
    deinit { task?.cancel() }

    // Output
    @Published private(set) var echoBack = ""

    private let echoService: EchoService
    private var task: Task<Void, Never>?

    // 一定時間経過後にstringをエコーバックする
    func echo(_ string: String) {
        task = Task { [unowned self] in
            do {
                echoBack = try await echoService.echo(string)
            } catch {
                guard !Task.isCancelled else { return }
                dump(error)
            }
        }
    }
}

この echo("Hello!") を呼び出すと、一定時間後 echoBack プロパティが "Hello!" に変化するコードです。このときエコーバックされる前に画面を閉じてしまうと、VC/VMは直ちに破棄され、Task はキャンセルされるか...というとそうはなりません。

Task ブロック内は [unowned self] でVMの参照を持たないようにしているのですが、

echoBack = try await echoService.echo(string)

と書くことで、SwiftコンパイラがVMの参照カウントを増やす実行プログラムを生成してしまうのです。 従ってVCは破棄されてもVMは破棄されず、エコーバックされた後に破棄されるため、結果的にキャンセルが発生しません。

このコンパイラ仕様を回避するため、echo() メソッドを以下のように変えてみます。

    // EchoViewModel.swift
    func echo(_ string: String) {
        task = Task { [unowned self] in
            do {
                let echoBack = try await echoService.echo(string)
                self.echoBack = echoBack
            } catch {
                guard !Task.isCancelled else { return }
                dump(error)
            }
        }
    }

一度ローカル変数で受けることでコンパイラが生成する実行プログラムが変わり、この場合は画面を閉じるとVC/VMが破棄され、キャンセルが発動します。

実質的に同じ意味のコードを書いているのに挙動が変わるのは困りものですが、実はもっと危険なケースがあります。それは、 非同期処理がキャンセルに対応していない場合 です。

EchoServiceecho() メソッドがもし以下のような実装だとしたら、例えキャンセルしたとしても無視され、一定時間後にエコーバックしてしまいます。

final class EchoService {
    private let delay: TimeInterval = 3

    func echo(_ string: String) async throws -> String {
        // FIXME: withTaskCancellationHandlerでキャンセル対応する
        return try await withCheckedThrowingContinuation { continuation in
            DispatchQueue.global().asyncAfter(deadline: .now() + delay) {
                continuation.resume(returning: string)
            }
        }
    }
}

このようにキャンセルが考慮されていない非同期メソッドを呼び出してしまうと、先ほどのVMのような実装にしたことで、クラッシュを発生させる要因を生み出してしまいます。 (self.echoBack = echoBack のところでクラッシュします)

この問題の対処法として、ここまでVMの echo() の中で Task を作り、同期/非同期の境界点としていましたが、VMの echo() を非同期メソッドにし、VC側で Task を作る形に変更してみます。

    // EchoViewModel.swift
    func echo(_ string: String) async {
        do {
            let echoBack = try await echoService.echo(string)
            self.echoBack = echoBack
        } catch {
            guard !Task.isCancelled else { return }
            dump(error)
        }
    }
final class EchoViewController: UIViewController {
    ...
    
    deinit { task?.cancel() }
    
    func sendEcho() {
        task = Task { [unowned self] in
            await viewModel.echo("Hello!")
        }
    }

この場合の画面を閉じたときの挙動は、VCは直ちに破棄されるので Task はキャンセルされます。VMはコンパイラによって参照カウントが増えており、少なくともVMの echo() メソッドのスコープにいる間はオブジェクトが生きているため self.echoBack = echoBack のところでもクラッシュしないので、致命的な問題は回避できそうです。

非同期処理がキャンセルに対応していない場合

非同期処理がキャンセルに対応している場合

まとめ

Swift Concurrencyにおいてはキャンセルは明示的に行う必要があること、またいくつかの留意点があることを紹介させていただきました。 ただ、「こんなに厄介ならキャンセルしない」と割り切るのもアリかなと思っています。

非同期処理の多くがUnaryなRest APIの呼び出しである場合、このリクエストをキャンセル可能にしたところで、通信や端末リソースの削減になるかというと微々たるもの...とも言えます。 Swift Concurrencyの設計思想からも、キャンセルはオプション的扱いで、必要であれば使ったらいいよという位置付けなんだろうなと思いました。

Combineと比較されがちですが、どちらにも長所・短所があると思うので適宜使い分けていくのが良いでしょう!


是非読者になってください


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

テックサポート制度の用途をまとめてみました!

グループ戦略室でエンジニアのマネジメントをしている平川 a.k.a @arihh です。
リモートワークで酒量が0になりましたが体重は減らない日々です。

弊社にはテックサポート制度というものがあります。 テックサポート制度とは、1人あたり年間12万円までスキルアップ・生産性向上に関わるサポートを行う制度です。

制度導入から3年以上が経過し、申請された制度の数は1,000を超える数となりました。
今回は実際にどういうことに使われたのかをまとめてみました。

導入時のブログあるのでそちらもご覧いただけたらと思います。 tech.medpeer.co.jp

どんなものに使われていたの?

カテゴリーに分けた分類はこのようになりました!

金額での割合で分類を出していますが、件数でみると技術書が8割程度で圧巻でした。 技術書以外ではキーボード購入・ソフトウェアのライセンスと続いています。

メドピアで人気の技術書は?

技術書の本は紙の本でも電子書籍でもOKとなっています。
制度を使って買われた技術書ランキングは以下となりました!

毎週輪読会を行っているので、輪読会の対象となった技術書についてはランキングが上位になりました。

技術書以外で使われていたものは?

技術書以外で使われたものランキングTOP5は以下となりました!

  1. Happy Hacking Keyboard
  2. Dash
  3. IntelliJ IDEA All Product Pack
  4. RubyMine
  5. REALFORCE

技術書以外ではキーボードやIDEの用途が多かった中、Dashの人気が目立ちました。

他にもこんな使われ方も!

エンジニアのスキルアップ・生産性向上のために、いろいろな使われ方をしています。
いくつか気になった使われ方をピックアップしてみました!

AWSの学習のほか、RaspberryPiでクラスタを組むような使い方をしている人がいます。

さいごに

詳しいことが気になった方はカジュアル面談でお話できればと思っています! メドピアでは引き続きテックサポートのような制度でエンジニアへの投資を続けていきます!


是非読者になってください


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

Private GitHub Pagesで社内ドキュメントを公開しよう!

集合知プラットフォーム事業部の榎本です。筋トレのお供のプロテインが切れそうなので、次に購入するプロテインのメーカーとフレーバーに悩んでます。

GitHub Pages でアクセス制限

今まで GitHub Pages というと静的サイトをインターネットへ全世界公開するしかできなかったのですが、2021年に Private GitHub Pages の機能がリリースされ、限定されたユーザーのみに制限してページを公開することが可能になりました

GitHub Pages を使って社内のドキュメントやナレッジを特定のユーザーだけに公開したり、企業内だけで共有したりすることができます。…(中略)… 今回の変更で、PrivateとInternalリポジトリでは、Private Pagesを使うことで、そのリポジトリを見れる人だけがそこから生成されるPagesのサイトを見られるという設定を行えるようになりました。

GitHub Pagesのアクセス管理 - GitHubブログ

今日は Private な GitHub Pages により社内ドキュメントをカジュアルに公開できるようになって捗りました、という話を紹介したいと思います。

Private GitHub Pages設定方法

Private GitHub Pages の設定方法は簡単です。下記のGitHub公式ドキュメント通りに進めれば OK です。

Changing the visibility of your GitHub Pages site - GitHub Docs

設定手順のサマリとしては下記の通りです。

  • リポジトリTOPへ
  • Settings (リポジトリ設定画面)へ
  • 左メニューから Pages を選択
  • GitHub Pages visibility で "Private" を選択

公開されるページのURL

下記のようなURLが GitHub 側で自動で生成され、 Private GitHub Pages としてアクセス可能になります。

https://xxx.pages.github.io/

一度発行されたURLは(設定を変えない限りは)基本的に変わらないようですので、安心して使えます。また、閲覧権限のない Private GitHub Pages にアクセスした場合は、 Unauthorized access error メッセージが表示されます。

(わかりやすい Custom Domain をページに割り当ててもよいかと思います。私のチームでは開発者向けの社内ドキュメントだしそのままでいいか、ということでGitHubから自動で割り当てられたURLをそのまま使用しました)

GitHub Pages の運用について

GitHub Pages の運用方法にはいくつか流派があります。

  • GitHub Pages 用のブランチ(gh-pagesブランチ)を用意してページを公開
  • main/master ブランチに docs ディレクトリを用意してページ公開

私のチームの場合、わざわざ公開用のブランチを用意して運用するのも手間がかかりそうだったので、後者の docs ディレクトリに html を放り込んで公開するかたちにしています。

Private GitHub Pages 設定例

Advanced な使用例として、peaceiris/actions-gh-pages みたいなものを使って、静的ページの生成および公開を自動化するのも良いでしょう。

使用例

実際の使用例を紹介したいと思います。私のチームでは下記のドキュメントを開発者向けドキュメントとして公開しています。

OpenAPI を redoc でhtml化した API ドキュメントを公開

redocで生成したAPIドキュメント

APIの仕様などについて話すときや、Pull Request からAPI仕様について言及するときなどに、GitHub Pages の URL で該当部分の仕様を参照できて便利でした。

Vue.js のコンポーネントをまとめた Storybook を公開

Vue.js コンポーネント Storybook

新しいページ追加のときに、既存のコンポーネントをStorybookのページから簡単に参照できて便利でした。

注意点

  • 無料プランでは Private GitHub Pages の機能は利用はできません
    • 個人利用であればGitHub Pro, Organization利用であればGitHub Team以上の契約が必要
  • Private GitHub Pages 閲覧のためには、GitHub アカウントで認証を通している関係上、GitHubユーザー登録およびOrganizationへの登録が必要
    • ドキュメントを全社員が閲覧できる形で公開するのは、GitHub の金銭コスト増、アカウント管理コスト増につながりなかなか辛いかも
    • コストを抑えたいなら開発者ドキュメントのみ Private GitHub Pages に公開すると良さそう
  • Private リポジトリであっても GitHub Pages の設定を Public にすると全世界公開されるので気をつけましょう

まとめ

Private GitHub Pages 登場前は静的サイトを社内だけに公開しようにも、自前で S3 を用意したり認証の仕組みを用意したりと、なかなか骨が折れることが多かったように思います。しかし Private GitHub Pages が登場したことで、社内向けのinternalな静的ページ・ドキュメントであればカジュアルに公開可能になりました。

みなさんも社内ドキュメントを Private GitHub Pages で公開して、ナイスな開発体験を手に入れてみてはいかがでしょうか。


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

Feature Toggleを用いたRailsアプリの継続的なリリースと要注意事項

はじめに

皆様こんにちは、サーバーサイドエンジニアの草分です。

突然ですが、開発者の皆様、実装したソースコードはこまめにリリースしていますか? 「大きい機能なので開発に時間がかかる」「障害が起きないよう念入りにテストする必要がある」などの理由で、Featureブランチのままコミットグラフが伸びに伸びたりしていませんか?

大きな機能を作ること自体は悪いことではありませんが、大きすぎるFeatureブランチは、本流ブランチとの挙動の乖離やコードの衝突が発生しやすく、レビューやマージに多大な苦労を伴います。

この記事では、この問題の解決策の1つとなる「Feature Toggle」を、Ruby on Railsにおける実装方法と共にご紹介します。 Feature Toggle自体は開発手法の一種であるため、言語/フレームワークを問わず広く活用されています。

Feature Toggleとは

  • 「機能が動作する/動作しない を切り替える」機構です。
  • ソースコードは存在しますが、トグルを「ON」にするまで機能が動作しないよう制御します。

Feature Toggle 動作イメージ

効果

Featureブランチの早期マージが可能となる

通常、作りかけの機能を本流ブランチにマージしてしまうと、ユーザーに未完成の機能を提供することになるため、問題になってしまいます。

そこでFeature Toggleを用いて、開発中の機能はトグル「OFF」の場合動作しないように実装します。そうすることで、開発中の機能をユーザー環境に影響を出さずにマージできるようになります。

本番環境でのテストが可能となる

本番環境では、開発環境では見つからなかった問題が多々発生します。 例えば、既存データに予期せぬレコードが入っていたり、アプリではない別のレイヤーでトラブルが起きたり...

Feature Toggleで社内向けのテストユーザーのみ機能を利用できるよう制御すれば、実際のユーザー環境にリリースする前に、テストユーザーで機能の動作確認ができるようになります。

Railsでの実装例

この記事では、Feature Toggle実装の助けとなってくれる「Flipper」 gemをご紹介します。 このgemはフラグ管理と分岐制御の仕組みを提供しています。

github.com

Feature Toggleは独自に実装することもできますが、このgemを使えばフラグの動的切り替えやフラグの管理画面などを比較的簡単に導入することができます。

続きを読む

SwiftUI / UIKit (Storyboard) ハイブリッド対応、Needle + RIBs インスパイアな iOS アプリケーションデザイン

こんにちは、モバイルアプリを開発しています高橋です。交互に仕事場に猫二匹がやってきて監視されながら仕事しています。

先日リリースしたとある iOS アプリは、

  • 機能は機能ごとに分割して実装したい
  • 依存解決のコードは自動生成したい
  • ライトウェイトな設計としたい

というコンセプトの元、コンパイルセーフな DI フレームワークの uber/needle を使い、uber/RIBs のようなアプリケーションアーキテクチャでデザインすることで、各コンポーネントをコンパクトに分割することができました。

Needle や RIBs が前提知識となります。そのため本記事ではざっと Needle と RIBs を解説したのちに、具体的なコードを交えて SwiftUI + UIKit (Storyboard) ハイブリッド対応でかつ Needle + RIBs インスパイアなアプリケーションアーキテクチャの一端を解説してみます。

動作環境

  • Xcode 13.2
  • Swift 5.5
  • macOS 12 Monterey (macOS 11 BigSur でも確認済み)

Needle

まず、簡単に Needle を説明します。

Needle は各モジュールをコンポーネントとしてツリーで表現し DI することができるものです。

コードジェネレーターの cli ツール→①と、ジェネレートされたコードを引き回すライブラリ→②がセットになっており、①をビルド時に実行するようにして使います。

Swift Package Manager でも Carthage でも CocoaPods でも使うことができます。ここではサクッと①を Homebrew 、②を Xcode の Swift Package Manager で入れてみます。

①Needle コードジェネレータ

% brew install needle

次に、Build Phase で Compile Sources の前に以下を設定します。

mkdir "$TEMP_DIR"
touch "$TEMP_DIR/needle-lastrun"
SOURCEKIT_LOGGING=0 needle generate $SRCROOT/アプリフォルダ名/Needle.swift アプリフォルダ名

※Carthage で入れた場合はチェックアウトディレクトリの中にあるので、それ (Carthage/Checkouts/needle/Generator/bin/needle) を実行します。

ビルドしてみると、registerProviderFactories() という空のメソッドが生えている Needle.swift ファイルができます。このメソッドは後ほど使用します。

Needle.swift ファイルを .xcodeproj に入れたら、下準備完了です。

コラム: SOURCEKIT_LOGGING=0

SourceKit ロギングをサイレントモードにしています。 通常 Xcode はログを表示しますが、Xcode で作業している際のノイズを減らすために入れています。

②Needle ライブラリ

ライブラリの方もプロジェクトに入れます。Xcode → File → Add Packages... より Needle のレポジトリ(https://github.com/uber/needle.git)を指定して入れます。

Needle を Swift Package Manager で入れる
Needle を Swift Package Manager で入れる

Needle の使い方の簡単な説明をするとこのようになります。

  • コンポーネントをツリー構造にします。ルートだけ BootstrapComponent のサブクラスにします。
  • 親コンポーネントで定義したコンポーネントを Dependency にするので、上位コンポーネント(ルートとか)で諸々注入します。
  • 子コンポーネントでは親で注入されたものを protocol Dependency で定義することで利用することができます。
  • 子コンポーネントは Component<***Dependency> のサブクラスにします。

Needle を使ったサンプル

雰囲気を掴むために、雑ですがコードを示します。

RootComponent.swift

import NeedleFoundation

final class RootComponent: BootstrapComponent {
    var point: Int {
        return 100
    }
    var featureABuilder: FeatureABuilder { FeatureAComponent(parent: self) }
}

FeatureAComponent.swift

import NeedleFoundation

protocol FeatureADependency: Dependency {
    var point: Int { get }
}
protocol FeatureABuilder {
    func showPoint()
}
class FeatureAComponent: Component<FeatureADependency> {
}
extension FeatureAComponent: FeatureABuilder {
    func showPoint() {
        print(dependency.point)
    }
}

これで子の FeatureAComponent の中で、親の RootComponent で定義した point にアクセスすることができています。Component<***Dependency> の中で dependency というプロパティが生えているので、これ経由でアクセスすることができます。

  • 注:***Builder という protocol を登場させています。 Component の protocol として定義しています。(後述)

AppDelegate あたりで先ほど触れた registerProviderFactories() を呼び出すことで Needle との接続を行います。

AppDelegate.swift

import UIKit
@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    private(set) var rootComponent: RootComponent!
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        registerProviderFactories() // Needle.swift で定義されている
        rootComponent = RootComponent()
        return true
    }
    // MARK: UISceneSession Lifecycle
    func application(_ application: UIApplication, configurationForConnecting connectingSceneSession: UISceneSession, options: UIScene.ConnectionOptions) -> UISceneConfiguration {
        return UISceneConfiguration(name: "Default Configuration", sessionRole: connectingSceneSession.role)
    }
    func application(_ application: UIApplication, didDiscardSceneSessions sceneSessions: Set<UISceneSession>) {}
}

RootComponent を経由して featureAComponent を取り出し、そのメソッドを呼び出して挙動を確認します。

SceneDelegate.swift

import UIKit
class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?
    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let _ = (scene as? UIWindowScene) else { return }
        let rootComponent = (UIApplication.shared.delegate as! AppDelegate).rootComponent
        let featureABuilder = rootComponent!.featureABuilder
        featureABuilder.showMoney()
    }
}

実行結果:

100

雰囲気だけで申し訳ありませんが、 Needle は以上のような感じで (point が Component になった時とか、孫 Component を持った時なども同様に) 自動で DI することができます。

RIBs

今回のプロジェクトはあくまでインスパイアされているだけなので実際は使用していませんが、軽くどういうものが触れておくと、こちらは VIPER や MVC のようなアプリケーションアーキテクチャであり、フレームワークでもあります。

実際に使用する際は、uber/RIBs に則ってプロジェクトにインストールします。Xcode テンプレートも利用することができ、スクリプトを実行して Xcode にインストールすることで新規コンポーネントを作成するときに自動で必要なファイルが生成されるようになっているため、効率的に開発が進められるとのことです。

RIB

RIBs は Router-Interactor-Builder(RIB) が中心となったデザインになっており、RIB 単位でコンポーネントとして分割します。画面であればこれに View を付け足します。

  • Router: RIB 間のやりとりを担当し、画面系の RIB であれば画面遷移なども担当します
  • Interactor: ビジネスロジックを担当します
  • Builder: Router / Interactor / View を作ります
  • View: データを表示したり、ユーザーインタラクションを担当します

出典: https://github.com/uber/RIBs/wiki/iOS-Tutorial-1

ルール

大枠のルールとしてはこのような感じです。

  • 別 RIB にアクセスする場合は、Router から別 RIB の Builder を参照する
  • 直接 View から Router にアクセスせず、Interactor で Router のメソッドへアクセスしてもらう

今回のアプリケーションアーキテクチャ(Needle + RIBs インスパイア)

ようやく本題です。

前述した Needle を使用し、RIBs の設計とルールを取り入れたアプリケーションアーキテクチャデザインになっており、Needle + RIBs インスパイアとこの記事では命名しております。(現場では特に名前をつけていません)

Needle + RIBs inspired App Architecture Example
Needle + RIBs inspired App Architecture Example

ベース部分の実装イメージ

あくまでイメージですが、RootComponent.swift や SceneDelegate.swift は以下のようになっています。

RootComponent.swift

import NeedleFoundation

final class RootComponent: BootstrapComponent {
    // DI
    var apiClient: APIClient { APIClient() }
    var errorLogger: ErrorLogger { ErrorLogger() }
    
    // 子コンポーネント
    var featureABuilder: FeatureABuilder { FeatureAComponent(parent: self) }
    var featureBBuilder: FeatureBBuilder { FeatureBComponent(parent: self) }
}

SceneDelegate.swift

import UIKit
class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?
    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let windowScene = (scene as? UIWindowScene) else { return }
        guard let appDelegate = UIApplication.shared.delegate as? AppDelegate else { return }
        guard let rootComponent = appDelegate.rootComponent else { return }
        let featureABuilder = rootComponent.featureABuilder
        let window = UIWindow(windowScene: windowScene)
        self.window = window
        window.rootViewController = featureABuilder.viewController
        window.makeKeyAndVisible()
    }
}

AppDelegate.swift

import UIKit
@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    private(set) var rootComponent: RootComponent!
    func application(_: UIApplication, didFinishLaunchingWithOptions _: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        registerProviderFactories()
        rootComponent = RootComponent()
        return true
    }
    // MARK: UISceneSession Lifecycle
    func application(_: UIApplication, configurationForConnecting connectingSceneSession: UISceneSession, options _: UIScene.ConnectionOptions) -> UISceneConfiguration {
        UISceneConfiguration(name: "Default Configuration", sessionRole: connectingSceneSession.role)
    }
    func application(_: UIApplication,
                     didDiscardSceneSessions _: Set<UISceneSession>) {}
}

(Needle の紹介をしていたときに、 Builder という protocol を急に登場させていましたが)RIBs で言うところの Builder として Component は振る舞ってもらう、という発想に基づいて Builder と命名し、これを使って初期の画面を作成しています。

このとき、Builder はよく build() と命名されているメソッドではなく、エンドポイントの内容を示す意味で viewController を持つようにしています。

コンポーネント部分の実装イメージ

実際のコンポーネントは Builder、Interactor、Router (、View) で構成するので、コンポーネントごとにそれらの protocol と実装を作成し、ファイル分割します。(今回は雑ですが、コンポーネントごとにファイル分割して以下に掲載してしまいます)

FeatureA コンポーネントの View (SwiftUI) から FeatureB コンポーネントの View (UIKit) を画面遷移するサンプルを作ってみました。

ちなみに Interactor は今回は Router へのただの橋渡し役になっています。(API 通信やデータベースアクセスなどデータ処理・ドメインロジックが入るときはここで対応する)

FeatureAComponent.swift

import NeedleFoundation
import UIKit
import SwiftUI

// MARK: -
// MARK: Builder

protocol FeatureADependency: Dependency {
    // 説明用にここで注入。ただしこのサンプルであれば、FeatureAComponent の中で生成してもよい
    var featureBBuilder: FeatureBBuilder { get }
}
protocol FeatureABuilder {
    var viewController: UIViewController { get }
}
final class FeatureAComponent: Component<FeatureADependency> {}
extension FeatureAComponent: FeatureABuilder {
    var viewController: UIViewController {
        let navigationController = UINavigationController()
        let router = FeatureARouter(viewController: navigationController,
                                    featureBBuilder: dependency.featureBBuilder)
        let interactor = FeatureAInteractor(router: router)
        let viewController = FeatureAViewController(interactor: interactor)
        navigationController.viewControllers = [viewController]
        return navigationController
    }
}

// MARK: -
// MARK: Router

protocol FeatureARouting {
    func showFeatureB()
}
final class FeatureARouter: FeatureARouting {
    private weak var viewController: UIViewController?
    private let featureBBuilder: FeatureBBuilder
    init(viewController: UIViewController, featureBBuilder: FeatureBBuilder) {
        self.viewController = viewController
        self.featureBBuilder = featureBBuilder
    }

    func showFeatureB() {
        guard let viewController = viewController else { return }
        viewController.present(featureBBuilder.viewController, animated: true)
    }
}

// MARK: -
// MARK: Interactor

protocol FeatureAInteracting {
    func showFeatureB()
}
final class FeatureAInteractor: FeatureAInteracting {
    private let router: FeatureARouting
    init(router: FeatureARouting) {
        self.router = router
    }
    func showFeatureB() {
        router.showFeatureB()
    }
}

// MARK: -
// MARK: View

final class FeatureAViewController: UIHostingController<FeatureAView> {
    private let interactor: FeatureAInteracting
    init(interactor: FeatureAInteracting) {
        let view = FeatureAView(interactor: interactor)
        self.interactor = interactor
        super.init(rootView: view)
    }
    @MainActor @objc required dynamic init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}
struct FeatureAView: View {
    let interactor: FeatureAInteracting?
    var body: some View {
        Button {
            guard let interactor = self.interactor else { return }
            interactor.showFeatureB()
        } label: {
            Text("B 画面開けるかな 🤔")
        }.padding()
    }
}

FeatureB では View を Storyboard で作成しています。Storyboard の説明は割愛します。

FeatureBComponent.swift

import NeedleFoundation
import UIKit

// MARK: -
// MARK: Builder

protocol FeatureBDependency: Dependency {
}
protocol FeatureBBuilder {
    var viewController: UIViewController { get }
}
final class FeatureBComponent: Component<FeatureBDependency> {
}
extension FeatureBComponent: FeatureBBuilder {
    var viewController: UIViewController {
        let router = FeatureBRouter()
        let interactor = FeatureBInteractor(router: router)
        let storyboard = UIStoryboard(name: "FeatureB", bundle: nil)
        guard let viewController = storyboard.instantiateInitialViewController() as? FeatureBViewController else { return UIViewController() }
        viewController.interactor = interactor
        router.viewController = viewController
        return viewController
    }
}

// MARK: -
// MARK: Router

protocol FeatureBRouting {
    func dismiss()
}
final class FeatureBRouter: FeatureBRouting {
    weak var viewController: UIViewController?
    init() {
    }
    func dismiss() {
        viewController?.dismiss(animated: true)
    }
}

// MARK: -
// MARK: Interactor

protocol FeatureBInteracting {
    func dismiss()
}
final class FeatureBInteractor: FeatureBInteracting {
    private let router: FeatureBRouting
    init(router: FeatureBRouting) {
        self.router = router
    }
    func dismiss() {
        router.dismiss()
    }
}

// MARK: -
// MARK: View

final class FeatureBViewController: UIViewController {
    var interactor: FeatureBInteracting?
    @IBAction func dismissButtonWasTapped(_ sender: UIButton) {
        interactor?.dismiss()
    }
}

Demo

Needle で SwiftUI の画面から UIKit (storyboard) の画面に遷移するデモの動画キャプチャ

SwiftUI 画面 → UIKit 画面への画面遷移ができました!

Demo ソースコード一式:

github.com

ちなみに

  • データモデル (Entity) などはこれらと別に struct を定義し Needle の管理下とは関係なくあちこちで利用します。

まとめ

  • ライトウェイトなアーキテクチャである
  • コンパイルセーフでバシバシ DI できる
  • SwiftUI も UIKit でも柔軟に対応できる

よかったらお試しください!


是非読者になってください


メドピアでは一緒に働く仲間を募集しています。 iOS / Android のモバイルエンジニアも募集しています。カジュアル面談からでも OK です! ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

Vue.js 公式ドキュメントのモブ翻訳をやりました!

こんにちは!
週一のサウナは欠かさない、フロントエンドエンジニアの土屋です。

先日、Vue.js の公式ドキュメントがリニューアルされました。
Vue.js 日本ユーザーグループ主導で翻訳プロジェクトが立ち上がっているのはご存知でしょうか?

メドピアでは、普段お世話になっている Vue.js に貢献したいという思いから、数回に渡って、Vue.js 公式ドキュメントのモブ翻訳を行ないました。

モブ翻訳の方法

  • Google Meet でファシリテーターの画面を共有しながら、Vue.js 公式ドキュメントの翻訳を行う
    • OSS へのコントリビュートに慣れていない方は、ファシリテーターが共有した画面を見ながら一緒に作業する。
    • 不明点がある場合、適宜ボイスやテキストチャットで相談しながら行う。
  • OSS へのコントリビュートに慣れてる方は、自分のペースでもくもくと作業する。

モブ翻訳の流れ

ここからは実際のモブ翻訳の流れとともに、その様子を紹介します。

まず、リポジトリの READMEVue.js 公式サイト日本語翻訳ガイドを確認します。
翻訳の方法や注意点が記載されているので、必ず目を通しましょう。

その後、翻訳するページを決めます。
Vue.js ビギナーの参加者が多かったので、Tutorial を翻訳することにしました。 翻訳を通して、Vue.js の知識を獲得するのが狙いです。

GitHub Issues で翻訳タスクが管理されているので、翻訳するページが決まったら、Issue に翻訳する旨をコメントします。
Tutorial を翻訳するので、Tutorial 翻訳まとめという Issue にコメントしました。

f:id:doyahiro:20220330165158p:plain
弊社のメンバーがこぞってコメントする様子

その後、リポジトリをフォークしてローカル開発環境を構築します。
ローカルで立ち上げることに成功したら翻訳開始です!

f:id:doyahiro:20220330165401p:plain
モブ翻訳中の様子。Google Meet で画面を共有しながらワイワイ。テキストチャットも盛んです。モブ翻訳だと、ここはこう訳した方が良いなど、色々な人の意見を聞けるのがありがたいですね。

訳し方に迷ったら Wiki をチェックしましょう。よくあるNGが記載されています。
また、Vue2 の公式ドキュメントではどのように訳されているか確認するのも有用でした。

訳し方に自信が持てない箇所は DeepL を使いました。

f:id:doyahiro:20220330165552p:plain
DeepL は強力ですが、意訳になりすぎたり、文中、文末の : (コロン) が削除されることがあるので注意が必要です。頼りきりにならないようにしましょう。

翻訳が完了したら、フォークした自分のリポジトリにプッシュします。
その後、フォーク元のリポジトリに Pull Request を出します。

f:id:doyahiro:20220330165703p:plain

PRを出すと、メンテナーの方がレビューしてくれます。
修正箇所がある場合は修正して再度コミットします。

f:id:doyahiro:20220330165735p:plain

問題がなければメンテナーの方がマージしてくれます。

f:id:doyahiro:20220330165813p:plain
晴れてマージされました。やったね!

これで一つの翻訳タスクが完了です。

f:id:doyahiro:20220330165902p:plain
初めてのOSSへのコントリビュートに喜びを隠しきれない様子

この流れで数回モブ翻訳を行い、弊社の社員で Tutorial を全て翻訳することができました!

まとめ

OSSにコントリビュートするのが初めての参加者が多かったので、リポジトリをフォークしてPRを出すといった、一般的なOSSへのコントリビュートの流れを体験できたのは良い経験になったと思います。

OSSにコントリビュートしてみたいけど、本体のコードに手を入れるのはハードルが高いと感じている方は、まずドキュメントの翻訳からトライしてみるのはいかがでしょうか。

普段使っているOSSには、今後も積極的にコントリビュートしていきたいですね。


是非読者になってください


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

Google ドキュメントを会議メモとして使う

こんにちは。サーバーサイドエンジニアのティーチです。最近の趣味は生後半年の娘にウケる動作の探求です。直近だと背筋が手応えありました。髪の毛がふわふわするのが面白かったようです。

本記事について

f:id:taichisato:20220304134701p:plain

■書く

  • Google ドキュメントを会議メモとして使うときの設定
  • Google ドキュメントを会議メモとして使う提案をする方法例

■書かない

会議メモを作る意義に触れると本記事の趣旨(Google ドキュメントの具体的な設定の仕方、使用の提案の仕方)以外の部分が長くなるので以下は割愛します。

  • 会議においてアジェンダ、議事録を作る意義
  • Google ドキュメントって何?

対象

  • 会議でアジェンダ、議事録を使いたいなと思ってる方
  • よその会議の仕方知りたいなという方

Google ドキュメントの強み

私のプロジェクトではオンライン会議をするためのツールとしてGoogle Meetを用いています。
そして、会議を入れる時はGoogle カレンダーに予定を入れるようになっています。

Google カレンダーには会議メモという機能があり、予定からGoogle ドキュメントを作成することが容易です。
作成後は予定にGoogle ドキュメントへのリンクが作られるので会議参加者への共有も容易です。

作成前 作成後
f:id:taichisato:20220304132153p:plain f:id:taichisato:20220304132217p:plain

f:id:taichisato:20220304132235p:plain

※2022/3/3時点 生成場所がマイドライブ固定のようなので共有ドライブに移動させるか、「共有」から編集権限を付与する必要があります。

作成、紐付けが容易な上
機能的には画像の挿入、見出し、同時編集機能ができるので良きです。

具体的な使い方

ファイル > ページ設定 から「ページ分けなし」に設定します。(この機能を紹介するためにこの記事書きました!) f:id:taichisato:20220304132252p:plain

ページ設定分けなしにすることで、なんと!例のあの空白をなくすことができます!ステキ! f:id:taichisato:20220304132303p:plain

f:id:taichisato:20220304132317p:plain

そして、1. 左上の灰色の部分をクリックしてテキストの幅を幅広にします。

あとは会議の内容に応じて構成を作る

f:id:taichisato:20220304132329p:plain

見出しは「見出し3」推しです。(MacならCommand + option + 3)

Google ドキュメントを会議メモとして使う提案をする方法例

私はすでに登録してある会議に対して上記のような会議メモを作って例えば以下のように共有しています。

前提

私はスギサポdeliというプロジェクトに携わっており、メンバーは本サービスを「deli」と呼称しています。

最近具だくさん食べるスープのBセットが出ました。私もまだ食べてないのですが、AセットはかなりおいしかったのでBセットもぜひ!(宣伝)

deliでは GitHubのプロジェクトボード を画面共有して会議していました。

Slackで投稿した文(ポイントがわかりやすいように修正しています)

Taichi Sato(teach)

deliの週次定例は内容充実してて良いのですが、
事前準備やissue外のトピックについての話し合いがやりづらいので、  .. (1)
マイブームの会議メモを作りました。.. (2)

[会議メモのURL]

deli projectとの2画面を画面共有するのはやりにくい部分あるかもしれませんが、
とりあえずやってみたいです! ..(3)

ポイント

(1) 会議メモがあると良い理由を一行で書く。

長いと読みづらいため。提案する相手によって詳細度は変えても良いと思います。

(2) 提案する人が会議メモのたたき台を作る。

理想的には、会議を招集する人が会議メモ、アジェンダ、構成全部つくるのが一番早いと思います。
しかし、登録された会議に対して
「アジェンダ作ってもらっていいですか?」
よりも
「会議メモとアジェンダ作りました!XXとYYはわからないので追記お願いしたいです!」
といった一緒に会議スタイルを作り上げていく方が現実的には効率よいのではないかなと私は思います。

(3) とりあえず一回!

「習うより慣れよ」
実際に会議メモを使って会議してみて、よかったら継続、合わなかったらやめれば良い。 そのくらいライトに提案した方が、提案された側も「とりあえずなら..」ってなる気がします。

deliでは今後も継続してGoogle ドキュメントを使用して会議をすることになりました。

まとめ

ページ分けなし設定ステキなのでぜひ広めて欲しい..!
Google ドキュメントの使用の提案方法が参考になれば幸いです!


是非読者になってください


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html