map! は
各要素を順番にブロックに渡して評価し、その結果で要素を置き換えます。
https://docs.ruby-lang.org/ja/latest/class/Array.html#I_COLLECT--21
てことで、自分自身を書き換える。
array = [1,2,3,4,5] array.map!{ |a| a * 2 } # [2,4,6,8,10]になる
slice! も同じノリと思ったら、
array = [1,2,3,4,5] array.slice!(0, 2) # [1,2]になると思ったら...
指定した要素を自身から取り除き、取り除いた要素を返します。取り除く要素がなければ nil を返します。
https://docs.ruby-lang.org/ja/latest/class/Array.html#I_SLICE--21
てことで、
戻り値 = [1, 2] array = [3,4,5]
になった。めちゃくちゃ時間を溶かしました。 ドキュメントはちゃんと読まないといけませんね。
次のRecommendBookViewModelクラスは、loadRecommendBooks関数という内部でviewModelScopeを用いて非同期処理を行う関数を持っている。
import androidx.lifecycle.ViewModel import androidx.lifecycle.viewModelScope import kotlinx.coroutines.flow.MutableStateFlow import kotlinx.coroutines.flow.StateFlow import kotlinx.coroutines.launch import hoge.fuga.recommendbook.RecommendBook import hoge.fuga.recommendbook.RecommendBookRepository data class ViewState( val loading: Boolean, val recommendBooks: List<RecommendBook> ) class RecommendBookViewModel( private val recommendBookRepository: RecommendBookRepository ) : ViewModel() { private val _viewState = MutableStateFlow(ViewState(true, emptyList())) val viewState: StateFlow<ViewState> = _viewState fun loadRecommendBooks() { viewModelScope.launch { val recommendBooks = recommendBookRepository.recommendBooks() _viewState.value = ViewState(false, recommendBooks) } } }
loadRecommendBooks関数をいい感じにテストするためにはいくらかの準備が必要になる。
次のような環境とする。
implementation "org.jetbrains.kotlin:kotlin-stdlib:1.4.21" implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.2' implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.4.2' testImplementation "org.junit.jupiter:junit-jupiter-api:5.6.1" testRuntimeOnly "org.junit.jupiter:junit-jupiter-engine:5.6.1" testImplementation 'org.robolectric:robolectric:4.4' // 多分今回のテストには関係ない testImplementation 'androidx.test:runner:1.3.0' testImplementation 'androidx.test.ext:junit:1.1.2' testImplementation 'org.jetbrains.kotlinx:kotlinx-coroutines-test:1.4.2' testImplementation "io.mockk:mockk:1.10.2" testImplementation('androidx.test.ext:truth:1.3.0') { exclude group: 'com.google.auto.value', module: 'auto-value-annotations' }
Junit5ではorg.junit.rules.TestRule は無くなった。代わりにorg.junit.jupiter.api.extensionパッケージ内の各種インタフェースを実装したクラスを、ExtendWithで指定する形になった。そこでDispatchers.setMain()などを実行するTestCoroutinesExtensionを作る。
package hoge.fuga import kotlinx.coroutines.Dispatchers import kotlinx.coroutines.test.TestCoroutineDispatcher import kotlinx.coroutines.test.resetMain import kotlinx.coroutines.test.setMain import org.junit.jupiter.api.extension.* // テストの前後の実行、テストのコンストラクタへのパラメータをサポートする class TestCoroutinesExtension : AfterTestExecutionCallback, BeforeTestExecutionCallback, ParameterResolver { private val namespace = ExtensionContext.Namespace.create(javaClass) private val key: Any = TestCoroutineDispatcher::class.java private val dispatcher = TestCoroutineDispatcher() override fun afterTestExecution(context: ExtensionContext?) { Dispatchers.resetMain() } override fun beforeTestExecution(context: ExtensionContext?) { Dispatchers.setMain(dispatcher) } override fun supportsParameter(parameterContext: ParameterContext, extensionContext: ExtensionContext): Boolean { return parameterContext.parameter.type === TestCoroutineDispatcher::class.java } override fun resolveParameter(parameterContext: ParameterContext, extensionContext: ExtensionContext): Any { return extensionContext.getStore(namespace).getOrComputeIfAbsent(key, { dispatcher }, TestCoroutineDispatcher::class.java) } }
TestCoroutinesExtensionを使ってRecommendBookViewModelのテストを書く。
import com.google.common.truth.Truth.assertThat import io.mockk.coEvery import io.mockk.mockk import hoge.fuga.TestCoroutinesExtension import hoge.fuga.recommendbook.RecommendBook import kotlinx.coroutines.test.TestCoroutineDispatcher import kotlinx.coroutines.test.runBlockingTest import org.junit.jupiter.api.Nested import org.junit.jupiter.api.Test import org.junit.jupiter.api.extension.ExtendWith // エクステンションを使う @ExtendWith(TestCoroutinesExtension::class) class RecommendBookViewModelTest(val dispatcher: TestCoroutineDispatcher) { // コンストラクタでTestCoroutineDispatcherを受け取る↑ @Nested inner class loadRecommendBooks { @Test fun `success`() = dispatcher.runBlockingTest { val viewModel = RecommendBookViewModel( mockk { coEvery { recommendBooks() } returns listOf( RecommendBook("a"), RecommendBook("b"), RecommendBook("c") ) } ) viewModel.loadRecommendBooks() val viewState = viewModel.viewState.value assertThat(viewState.loading).isFalse() assertThat(viewState.recommendBooks.size).isEqualTo(3) } } }
割とシンプルにできて良さそう。
本エントリはUbie Advent Calendar 2020の22日目です。 21日目はtoCプロダクトAI受診相談ユビーのプロダクトオーナーである@shikicheeのエンジニアの僕が強みを活かして施策推進したら、異次元の角度で数字が伸びちゃった話でした。
自分は現在toBプロダクトである、医療機関向けのAI問診ユビーのソフトウェアエンジニアをしています。普段はRails/Ruby、Spring Boot/Kotlin、React/TypeScriptを使ってバックエンドからフロントエンドまでプロダクトに関連することについて全般的に開発をしています。
またこのほかに最近は全社的な技術戦略に関するロールを持っており、サービス全体のカタチをどのようにしていくかについて考えたり手を動かしたりしています。
本エントリでは、Ubieの現在のシステムの状況と、起こり始めている現象などを紹介しつつ、今後どのようなことを行っていくかについてまとめます。
Ubieは今年で創業から4年目を迎えました。現在のサービス群の基となるコードは、共同創業者の一人である久保(@quvo_ubie)が大学院時代の研究で作り始めました*1。コードベースとしてはこの研究時代の2年間を足した6年物ということになります。
現在のUbieのソフトウェアエンジニアやサービス、プロダクトの数は次の通りです。
独立して動作するサービス群の関連は次のようになっています。
この図にプロダクトの境界を引くと...
結構こんがらがっているように見えますね。実際に結構こんがらがっています。
Ubieでは創業から現在に至るまで、不確実性を下げるための検証にフォーカスしてきました。それぞれの局面毎に、リソースや時間の制約を鑑みて最善手と考えられるものを重ねているものの*2、やはりどうしても複雑化していっています。
疾患推測エンジンの実現、症状チェッカーの価値検証を経た後、出口としては 実際に患者さんが病院に受診する/しないことが重要となってきます。この時点で医療機関にとっては、症状チェッカーは患者さんの受診行動に影響を与えるかもしれませんが、業務上の課題には特に貢献しません。病院に受診した患者さんは改めて1から問診を行うからです。そこで医療機関の業務上の課題解決にフィットするプロダクトの検証が始まりました。
医療機関向けのプロダクトの形がある程度見えてきた頃、症状チェッカーのリプレースが始まりました。Androidアプリは廃止し、Webサービスとして作り直しています。アプリの場合、症状チェックをするために症状の発現 -> 症状で検索などをする -> アプリの認知 -> インストール -> チェック という風にかなりの数の手続きを踏まなければなりません。症状があるユーザにとってはかなりの負担です。Webサービスにすることで症状の発現 -> 症状で検索などをする -> ランディング -> チェック とスムーズに症状チェックができるようになりました。同時にその形態でスケールは可能なのかという点の検証が必要となります。
病院とは入院施設としてベッド数が20床以上、医師3名以上の機関を指します。それ以外は診療所となります。街に沢山あるクリニックや医院は診療所です。国内の病院はおよそ8000件で、診療所は100000件です。病院と診療所では来院患者数や医療従事者の規模が異なります。業務上の課題や関心事も大きく異なるのではないか、という仮説のもと、プロダクトを分けて検証をはじめました。
国内の医療機関への導入が徐々に進んできたところで、医療制度が近しい国においてもAI問診サービスが役に立つのか検証をはじめました。また国内においては症状チェッカーで行った問診をAI問診サービスを導入している病院に直接送ることができるようになりました。２つのプロダクトが繋がり、サービスの関連図には現れてこない複雑さも生まれ始めています*3。
ソフトウェアエンジニアの人数、サービスの個数、プロダクトの数が着々と増えていく中、開発において起こっている現象が沢山あるわけですが、代表的なものとしては次の通りです。
個別に現象に対処して行ってもいいですが、現在の人数やプロダクトの増加速度を鑑みると、もう少し中長期目線で考えたほうがよさそうだなぁということで、技術的負債の観点でそれぞれの現象を見直してみました。
ここでいう技術的負債とは、技術的負債の言葉の生みの親であるウォード・カニンガム氏の次の定義に準じます。
「もしも自分たちが書いているプログラム（WyCash）を、金融の世界に関する正しい捉え方だと自分たちが理解した姿と一致させることができなくなれば、自分たちは絶えずその不一致につまずき続けることになり、開発スピードは遅くなっていくでしょう。それはまるで借金の利子を払い続けるかのようです」
それぞれ 正しい捉え方だと自分たちが理解した姿と一致していないのではないか という観点で見直すと、
不確実性の高い部分を素早く検証するために、不一致を許容するのは重要である一方で、不確実性が下がった後もその部分を放置しておくと、やがて様々な症状が現れてくるのかなと思います。
逆にこれらを解決していけば、現象の解消や防止ができるのではないかと考えました。
正しい捉え方だと自分たちが理解した姿と一致させ続けることはとても重要だと考えつつも、とはいえリソースと時間の制約があるので、どこまでなにをするかをどう決めていくかは大事です。Ubieでは皆2言目にはROIだROIだと言っています。
図はほとんど意味を持っていませんが、つまり、複雑度を上げるような追加変更は線形に増えていきますが、開発のインベストはいつの間にか指数関数的に増加していくので、インベストが爆発するまえになんとかしたい、ということです。同時にこれを予防できればある程度の負債は許容してもよさそうです。
なぜインベストの増加を予防したいのかというと、当然速度やコストに効いてくるからですが、それ以外にも意思決定の歪みを防ぐという観点があるかと思います。
技術的負債によってインベストが増加すると、質の高いissueであっても優先度が下がったりします。重要な検証の優先度が下がるのは時にクリティカルになります。
ということで、直近で解くべき課題は
かなと定義しました。これによって人数やサービスやプロダクトが増えても速度を落とさない、むしろ加速するような状態を作っていきます。
守破離ということで、すでにややマイクロサービスぽく分割していることもあって、マイクロサービスアーキテクチャについて改めてしっかりと入門することにしました。
マイクロサービスアーキテクチャの序盤の章では、サービス分割の観点でDDDを参照しています。
DDDの考え方は、技術的負債のあるべき姿と一致させるという考え方と似ています。エリック・エヴァンスのドメイン駆動設計 では歯を食いしばって真のモデルとシステムを一致させるといった言葉が何度も出てきます。
マイクロサービスアーキテクチャの各種ノウハウを取り入れる前に、まずは現在のシステムとあるべき姿のギャップを、DDDにおけるコンテキストとその境界を描くことで可視化していきました。
コアドメインはなんだろうというところから初めて、徐々に現在のサービス群が何を提供しているかなどを考えながら付け足していきました。
実際の作業はmiroで複数人で行っています。
あんまり現実のシステムを意識せず、理想状態を考えるとスムーズに行くなぁという感想です。同時にあまりにギャップありすぎてちょっと引くみたいな時もあります。
コンテキストマップを書いていくと、実際のコンテキストとサービスが横断している場所が見えてきました。次の画像は症状チェッカーと医療機関向けプロダクトが連携する箇所ですが、複数のサービスが1つのコンテキストに対して同時に携わっていることがわかります。実際にこの部分は壊れやすく、慎重な変更が必要になってしまっています。
また、コンテキストマップを描いていく中で、1つの業務フローに対して、いくつかの独立したコンテキスト達が複数組み合わせられていることに気づきました。
それぞれのコンテキストは個別に価値を生み出せそうな単位でありますが、現状はプロダクトの特定の業務フローのなかに埋まっています。これらを価値創出の単位として切り出せそうです。
価値創出の単位を自由に組み合わせることができるようになれば、考えてもみなかった、あるいは実現が難しいと思っていたプロダクトをどんどん作り出せるのではないか、と期待できます。
コンテキストマップによって現在すでにインベストが高くなっている箇所の解消のためのアクションの洗い出しや、将来インベストが高くなると予見される箇所などの可視化ができました。不確実性が高い場所と低い場所が共存できるカタチを見つけるについてはまだまだこれからですが、価値創出の単位がそれぞれ確からしいかどうかを判断したり、新しい不確実性をどのように追加していくかについて、モジュラモノリスの考え方が役に立つのではないかと思っています。
モジュラモノリスはモノリスの中でモジュールによって境界を分離していくものです。すでにUbieは複数のサービスが分かれているので、本当のモジュラモノリスにしていくぞというのは現実的ではありません。しかし複数のコンテキストを持っていそうなサービスにおいて、モジュールによる分離をまずは行うというアプローチは非常にコスパが良いのかなと思っています*4。
ここから先はまだこれからです。ということでおそらく大小様々な課題と直面していくと思いますが、一連の活動を価値創出を掛け算可能にするシステム の第1歩目と定義し、医療の領域の課題解決を加速していきたいと考えています*5。プロダクト開発もエンジニアリングも好きという方は是非一緒にやっていきませんか！？
待ってます。
material-uiのTextFieldをtesting-library/reactでテストしようとすると、HTMLElementを取り出すところで苦労したのでメモを残す。
次のTextFieldがどこかのコンポーネントにあるとする。
<TextField name="name" label="name" aria-label="name" variant="outlined" value="title" />
実際にDOMにレンダリングすると次の構造になる。ルートの要素にaria-labelがついていることがわかる。
<div aria-label="name" class="MuiFormControl-root MuiTextField-root" > <label class="MuiFormLabel-root MuiInputLabel-root MuiInputLabel-formControl MuiInputLabel-animated MuiInputLabel-shrink MuiInputLabel-outlined MuiFormLabel-filled" data-shrink="true" > name </label> <div class="MuiInputBase-root MuiOutlinedInput-root MuiInputBase-formControl" > <input aria-invalid="false" class="MuiInputBase-input MuiOutlinedInput-input" name="name" type="text" value="title" /> <fieldset aria-hidden="true" class="PrivateNotchedOutline-root-1 MuiOutlinedInput-notchedOutline" > <legend class="PrivateNotchedOutline-legendLabelled-3 PrivateNotchedOutline-legendNotched-4" > <span> name </span> </legend> </fieldset> </div> </div>
testing-libraryのgetByLabelText関数は、ラベル名でHTMLElementを取り出すので、input要素に直接アクセスできないことがわかる。解決策として2つの方法がある。
１つ目の方法はgetByLabelText関数でルート要素を取り出したあと、querySelector関数を使ってinput要素を探すというもの。
import { render, cleanup } from "@testing-library/react/pure"; import "@testing-library/jest-dom/extend-expect"; import { TextField } from "@material-ui/core"; describe("Material UIのTextFieldのテスト", () => { it("querySelectorを使ってvalueの値をチェックする", () => { const result = render( <TextField name="name" label="name" aria-label="name" variant="outlined" value="title" /> ); // input要素を取り出す。 const input = result.getByLabelText("name").querySelector("input"); expect(input?.value).toEqual("title"); }); });
querySelector("input")の戻り値はHTMLInputElement | null なので適宜nullチェックを加える必要があるが、値を検証するだけならinput?.valueとするだけで十分。
2つめの方法は、getByDisplayValue関数を使ってvalue値からinput要素を取り出す。
describe("Material UIのTextFieldのテスト", () => { it("getByDisplayValueを使ってvalueの値をチェックする", () => { const result = render( <div> <div>title</div> <TextField name="name" label="name" aria-label="name" variant="outlined" value="title" /> </div> ); const input = result.getByDisplayValue("title"); // elementが取り出せた時点で 'title' というvalueを持っていることがわかるので // このexpectは実際は不要 expect(input.getAttribute("value")).toEqual("title"); }); });
getByDisplayValue関数はinput要素系のための関数なので便利なのだが、値を使って取り出すので同じ値のinput要素があったりするとエラーになってしまう。
個人的にはラベルを指定した上でquerySelector関数を使う方法が好きですが、しかしMaterial UIの内部構造を知った上で書く必要があるのでちょっとな〜という気はしますが仕方ない気もする。
最近AtCoderなどに参加していて、すべての組み合わせを生成しつつ計算するといった機会になんどか遭遇し、毎回頑張って実装していたのだけど、bit全探索という方法があるらしいと知り、調べて、Kotlinでどう書くか考えた結果次のようになった。
import java.util.BitSet fun bitFullSearch(n: Int): List<BitSet> = (0 until (1 shl n)).map { bit -> BitSet(n).apply { repeat(n) { i -> set(i, bit and (1 shl i) > 0) } } }
たとえば bitFullSearch(4) などと呼び出すと、それぞれ次のbitが立ったBitSetのリストが手に入る。
{} {0} {1} {0, 1} {2} {0, 2} {1, 2} {0, 1, 2} {3} {0, 3} {1, 3} {0, 1, 3} {2, 3} {0, 2, 3} {1, 2, 3} {0, 1, 2, 3}
bitSet.get(i) でそのインデックスのビットが有効かBooleanが手に入るほか、bitSet.stream()で有効なインデックスのストリームが手に入るので大体いい感じにできる。
個人のプロジェクトでMaterial-UIを使っているんですが、 コンポーネントがHiddenを含んでいると、テストがうまく動きません。
import * as React from 'react'; import {Hidden} from "@material-ui/core"; export const Hoge = (): JSX.Element => { return ( <div> <Hidden mdUp> <div>mdUp</div> </Hidden> <Hidden smDown> <div>smDown</div> </Hidden> </div> ) };
import React from "react"; import {render, cleanup} from '@testing-library/react' import {Hoge} from "../hoge"; afterEach(async () => { await cleanup(); }); describe('hoge', () => { describe('ある幅以上の時のレンダリング', () => { it('mdUpが表示される', () => { const {getByText} = render( <Hoge/> ); expect(getByText("mdUp")).toBeVisible() }); }); });
見つけられない...ていうかそもそもHidden要素がどっちもレンダリングされていない
TestingLibraryElementError: Unable to find an element with the text: mdUp. This could be because the text is broken up by multiple elements. In this case, you can provide a function for your text matcher to make your matcher more flexible.
<body>
<div>
<div />
</div>
</body>
13 | <Hoge/>
14 | );
> 15 | expect(getByText("mdUp")).toBeVisible()
| ^
16 | });
17 | });
18 | });
"@material-ui/core": "^4.10.2",
"react": "^16.13.1",
"@testing-library/dom": "^7.16.3",
"@testing-library/jest-dom": "^5.10.1",
"@testing-library/react": "^10.3.0",
"@testing-library/user-event": "^12.0.7"
Unable to test React with Material-UI Hidden element · Issue #2179 · enzymejs/enzyme · GitHub によると、jest-domとmaterial-uiの双方に課題があるようです。 -> https://github.com/enzymejs/enzyme/issues/2179#issuecomment-528973289
対応方法は2つほどあるぽいです、ここではかんたんな方を書きます。
テスト側でrenderするときにcreateMuiThemeを用いて初期の画面幅を指定するやりかたです。
import React from "react"; import {render, cleanup} from '@testing-library/react' import {createMuiTheme, MuiThemeProvider} from "@material-ui/core"; import {Hoge} from "../hoge"; afterEach(async () => { await cleanup(); }); describe('hoge', () => { describe('ある幅以上の時のレンダリング', () => { it('mdUpが表示される', () => { const theme = createMuiTheme({props: {MuiWithWidth: {initialWidth: 'sm'}}}) const {getByText} = render( <MuiThemeProvider theme={theme}> <Hoge/> </MuiThemeProvider> ); expect(getByText("mdUp")).toBeVisible() }); }); });
これで画面幅を指定して実行できます。
initialWidthをmdにするとsmDownの方の要素が表示状態になります。
ReactでTDDでやっていくぞと思って触り始めたけどやはりUI部分はなかなか大変だなと思いつつ、Androidよりは楽かもという気持ち
前回に引き続いて。
レイアウトのleft, rightが start, endになりました。なるだろうなーと思ってたので想定どおり。
before
LayoutPadding( top = 16.dp left = 8.dp, right = 8.dp, bottom = 16.dp )
after
LayoutPadding( top = 16.dp start = 8.dp, end = 8.dp, bottom = 16.dp )
Imageを描画するDrawImageがなくなりました。代わりにSimpleImageを使います。このあたりは今後も色々と変わりそうですね。
before
Container( width = 100.dp, height = 200.dp ) { DrawImage(image) }
after
Container( width = 100.dp, height = 200.dp ) { SimpleImage(image) }
ContextAmbientはandroidx.compose.Contextを返してましたが、androidx.compose.Contextになりました。
before
import androidx.compose.Context
after
import android.content.Context
TopAppBarのnavigationIconに使うAppBarIconがなくなり、代わりにIconButtonを使う形になりました。
before
TopAppBar(
title = {
Text(context.getString(R.string.app_name))
},
navigationIcon = {
AppBarIcon(
icon = ImagePainter(BitmapImage(context.getBitmap(R.drawable.ic_baseline_arrow_back_24))),
onClick = {
backStack.pop()
}
)
}
)
IconButtonを使う場合のほうが冗長ですが、children: @Composable() () -> Unitを受け取るのでより柔軟な表現が可能になってます(例えばTextを渡してもちゃんと動く)。
after
TopAppBar(
title = {
Text(context.getString(R.string.app_name))
},
navigationIcon = {
IconButton(
onClick = {
backStack.pop()
}
) {
SimpleImage(
BitmapImage(context.getBitmap(R.drawable.ic_baseline_arrow_back_24))
)
}
}
)
Column, RowともにArrangementが設定できますが、寄せる方向の設定がStart, Endという名前でした。なので次のように同じ値でもColumnかRowかで意味が異なります。
before
Column( modifier = LayoutWidth.Fill, arrangement = Arrangement.End // 下寄せ ) { Row( modifier = LayoutWidth.Fill, arrangement = Arrangement.End // 右寄せ ) { // something } }
ArrangementにVertical, Hotizontalの概念を追加し、使える値を増やしつつ制限をかけています。これにより意味を理解しやすくなりました。
after
Column( modifier = LayoutWidth.Fill, arrangement = Arrangement.Bottom // Arrangement.Endは使えない ) { Row( modifier = LayoutWidth.Fill, arrangement = Arrangement.End ) { // something } }
今までは1ヶ月に1リリースという感じでしたが、2月は2回ありました。I/Oに向けてガガガッとスパートかけてる感じなんでしょうか。楽しみですね。