uber/mockoloのclassモック生成のバグを修正した

uber/mockoloとは

• Uberが開発するSwift用のモック自動生成ツールで、ここ1〜2年で採用が増えていそうな雰囲気
• 2019年のSwiftモック事情 - いけだや技術ノート でも紹介しました
  • logmi.jp

というものです。

mockoloはv1.1.3からprotocolだけでなくclassのモック生成もできるようになったのだけど、これを実際に使おうとしてみると生成されたコードがコンパイルエラーになった。

具体的には、次のようなデフォルト値ありのpropertyを持つclassで問題が発生していた。

// Foo.swift

/// @mockable
class Foo {
    var foo: Int = 0
}


// Mocks.swift

class FooMock: Foo {

    private(set) var fooSetCallCount = 0
    override var foo: Int = 0 { didSet { fooSetCallCount += 1 } }
}

• stored propertyをoverrideして新たなデフォルト値を代入することはできない
• stored propertyを新たなデフォルト値でoverrideしようとして、そこにproperty observer (willSet/didSet)を付けようとすると Variable with getter/setter cannot have an initial value というおかしなコンパイルエラーになる
  • property observerはgetter/setterではない

propertyのモックにデフォルト値を代入するのは元々protocolモック用の実装だったので、classモックではデフォルト値を代入しないようにして解決した。

github.com

これによって生成コードはこうなる:

class FooMock: Foo {

    private(set) var fooSetCallCount = 0
    override var foo: Int { didSet { fooSetCallCount += 1 } }
}

ということで、こちらの修正が含まれたv1.3.2がリリースされていたので、どうぞお使いください。mockoloのclassモックはあまり枯れていないようなので枯らしていきましょう。

App Storeの定期購読・無料トライアルの基準タイムゾーンはUTC

App Store Connectのドキュメント（ヘルプページ）にはこうあります:

自動更新登録は、1 か月間の日数ごとではなく、最初の購入の暦日と同じ日に更新します。たとえば、カスタマーが 1 か月の無料トライアルを 1 月 7 日に開始する場合、トライアルが終了するのは 2 月 7 日です。翌月に同じ日が存在しない日に 1 か月のトライアルを開始した場合、トライアルが終了するのは翌月の末日ですが、利用可能になると元の日付に戻ります。たとえば、カスタマーが 1 月 30 日に登録すると、次の更新日は、2 月 28 日 (閏年の場合は 2 月 29 日) で、その次は 3 月 30 日になります。

これだけだと「そうですね」となるのですが、仕事で見かけた事例によると、どうも日時はUTCのタイムゾーンを基準としているようです。日本時間などユーザーのローカルタイムゾーン基準でないことで、次のようなややこしいことが発生し得ます。

1. 日本時間の3月1日 午前9時（UTC 3月1日 午前0時）に無料トライアルを開始
   • 無料トライアルの終了日（課金開始日）は4月1日
2. 日本時間の3月1日 午前8時（UTC 2月28日 午後11時）に無料トライアルを開始
   • 無料トライアルの終了日（課金開始日）は3月28日で、4月1日ではない！

日本時間では同じ3月1日に無料トライアルを開始しても、たった1時間の違いで無料トライアルの期間が3日間も短くなってしまいます。

ということで、開発者としてユーザーからの問い合わせへの返答にも、ユーザーとして無料トライアルを最大限活用するのにも使える豆知識でした。

URLのパスの分割方法による結果の違い

let url = URL(string: "https://example.com/foo/bar")!
url.path // "/foo/bar"
url.path.split(separator: "/") // ["foo", "bar"]
url.path.split(separator: "/", omittingEmptySubsequences: false) // ["", "foo", "bar"]
url.pathComponents // ["/", "foo", "bar"]

ドキュメントはこちら:

• path:
  • URL: https://developer.apple.com/documentation/foundation/url/1779812-path
    • 情報量が少ないので NSURL の方も見られたい
  • NSURL: https://developer.apple.com/documentation/foundation/nsurl/1408809-path
• pathComponents:
  • URL: https://developer.apple.com/documentation/foundation/url/1780324-pathcomponents
    • 情報量が少ないので NSURL の方も見られたい
  • NSURL: https://developer.apple.com/documentation/foundation/nsurl/1407365-pathcomponents
• split: https://developer.apple.com/documentation/swift/string/2894564-split

2021年2月末でRxJava 2.xがEnd-of-Life (EoL)を迎えた

github.com

⚠️ This is the last planned update for the 2.x version line. After February 28, 2021, 2.x becomes End-of-Life (EoL); no further patches, bugfixes, enhancements, documentation or support will be provided by the project.

これまでAndroidアプリ開発での非同期処理の定番として使われていたRxJavaですが、その2系バージョンがEoLを迎えていました。Android JetpackでもKotlin Coroutinesを使ったAPIが増えてきているなど、最近はCoroutinesを使うことが増えてきているので、ひとまず最新の3.xに移行しつつ、Coroutinesに置き換えていきたいところですね。

Reactコンポーネントの定義にFCではなくVFCを使う

• [RFC] React 18 and types-only breaking changes · Issue #46691 · DefinitelyTyped/DefinitelyTyped
  • [@types/react] add VoidFunctionComponent type which does not accept "children" by awmottaz · Pull Request #46643 · DefinitelyTyped/DefinitelyTyped
• https://react-typescript-cheatsheet.netlify.app/docs/basic/getting-started/function_components/

簡単に言うと

• React.FCのpropsの型定義には暗黙的にchildrenが含まれてしまう
  • childrenが必要ないコンポーネントでもchildrenが渡せてしまう
  • パッと見ではそのコンポーネントにchildrenを渡すのかどうかが分からない
• 今後@types/reactの18以降ではReact.FCにchildrenは含まれなくなる予定（破壊的変更）
  • これを先取りして@types/reactの16.9.48からReact.VFC/React.VoidFunctionComponentが追加されており、こちらではchildrenが含まれない

ということで

• @types/react 18の時代を先取りし、基本的には全てをReact.VFCで定義して、childrenが必要なコンポーネントではpropsに明示的にchildrenを定義しましょう
• React.FCからchildrenが消えた暁にはReact.VFCは非推奨になるはずで、その時はVFCをFCに一括置換すれば問題ないはず

ということを会社のチーム内で話した。

React用のカルーセルコンポーネント

ざっと目に着いたものをリストアップしてみる。スターの多さでいうとreact-slickが最強のようだけど、issueの数も200件超と多いのは気になる。そこまでデファクトスタンダードと呼べるものはないのだろうか？

---

github.com

• jQuery用のカルーセルプラグインのslickのReact版を標榜
• issueが200件超（2020年11月10日現在）
• SSRについては特に言及されていない

---

github.com

• 「Server side rendering compatible」とREADMEで言及されている

---

github.com

• SSRについては特に言及されていない

---

github.com

• SSRはサポートしていない（のでNext.jsならdynamicでラップするようにとのこと）

  • we recommend Next.js as @brainhubeu/react-carousel currently doesn't work on the server side so it must be rendered on the client side (maybe we'll provide server-side working in the future).

Amazon RDS/Amazon AuroraのデフォルトタイムゾーンはUTC

備忘録です。

• MySQL on Amazon RDS - Amazon Relational Database Service

By default, the time zone for an RDS MySQL DB instance is Universal Time Coordinated (UTC). You can set the time zone for your DB instance to the local time zone for your application instead.

• Regions and Availability Zones - Amazon Aurora

By default, the time zone for an Amazon Aurora DB cluster is Universal Time Coordinated (UTC). You can set the time zone for instances in your DB cluster to the local time zone for your application instead.

昔はタイムゾーンは正攻法では変更できなかったようだが、2015年12月に変更できるようになっていた。

dev.classmethod.jp

aws.amazon.com