Add AOT gzip content-encoding support for main build files.2016/12/30https://github.com/vercel/next.js/commit/29c226771ce8b5b26632c8e7753e69f7407933b4AOTってなんだ？と思って引っかかった。Ahead of Timeの略で、実行前に処理をするという意味のようでした。差分を見ると、build時にassetsをgzipにするほか、main.js、common.jsをレンダリングのタイミングでAcceptヘッダを見てgzipにしています。Prevent prefetcher from making identical requests.2017/01/05https://github.com/vercel/next.js/commit/e38cacc4c25ec91764ef00bc32936f8108a93a65prefetchの際に、変更前まではロードが完了してからキャッシュの有無のフラグを立てていた。Map<string, boolean>でURLをキーにプリフェッチの状態を管理していたのを、Map<string, Promise>にすることで、二重でロードするのを防ぐようにした。bypass SSE on Service Worker2017/01/07https://github.com/vercel/next.js/commit/0551dc90a14d4beda8dc64058c4ae2837cc61ec6Service Workerでfetchする際に、リクエストがSSEを期待している場合は実行しないように。prefetchをスクラッチしている感じがして面白い。Implement "Immutable build artifacts" feature2017/01/12https://github.com/vercel/next.js/commit/b7e57f934740bd1cfb6c0a9c797b8943eb12ca49Cache-Control: immutableという新しいCache-Controlの仕様をサポート。immutableは2017年9月に正式にRFCになったらしい。tex2e.github.ioビルド時にUUIDを発行し、prefetchやrouterで画面遷移の際に取得するjsonデータなどのパスで利用します。これによってすでにキャッシュ済みのコンテンツに対してはリクエストを行わないようになります。もともとFacebookがリロードでの304の大量発生を防ぐために考案したものだそうです。bitsup.blogspot.comなるほどこんな仕様があるのだな〜と面白かった。まとめ2.0.0-betaは42まであってすごく長い

Next.js全部読む 3 (~2.0.0-beta.16)

Custom Document Support2016/12/17https://github.com/vercel/next.js/commit/8ddafaea5c1544f713bb0118b78055585b37e1e3#diff-dc3c27fcfe133615dd2b43df0b2da03e1ed23a7a03d17e86ae20f73ef20bc697R20pages/_ducument.jsにファイルを置くとそっちを使うように。babelでビルドするタイミングでファイルの存在を見ています。この変更まではデフォルトのDocumentコンポーネントしか使えず、CSSがnext/css一択だったようです。カスタムした_ducument.jsを使うことで、任意のCSSを使えるようになりました。Programmatic API2016/12/17https://github.com/vercel/next.js/commit/1708222381788060e79de8f343ae2d8670865380next.js/server/index.jsのServerクラスをexportし、それを用いて任意のNodeアプリケーションを実装できるようになりました。元々のnext startも以下のようにnodeでServerを起動しているので、このあたりの挙動に手を入れたい場合にカスタムできるようになりました。const srv = new Server({ dir })srv.start(argv.port).then(() => {  if (!process.env.NOW) {    console.log(`> Ready on http://localhost:${argv.port}`)  }}).catch((err) => {  console.error(err)  process.exit(1)})Implement the Singleton Router API2016/12/19https://github.com/vercel/next.js/commit/22776c2eeeca2696b78f38f067aa90af8472a9e1next/routerがexportされ、アプリケーション側で使えるようになりました。現在だとuseRouterが一般的ですが、このころはimportしてRouter.push()とかいう風に書きます。その他現在だと_documentとかrouterとか普通に使ってるけど最初は無かったんだよな〜と。当たり前ではあるんだけど、歴史的経緯みたいな感じがして面白い。

Next.js全部読む 2 (~2.0.0-beta.0)

2024年の年始にNext.jsのコードベースを読むことにしました。その際に得た知識をアウトプットすることを考えていましたが、初めはどのように読み進めたらよいのか迷い、なかなか整理することができませんでした。最近になって「最初のコミットから差分をすべて読んでいく」という方法が自分には馴染むと分かってきました。そういうわけで特に興味深いと感じたコミットについて、メモを取っていくことにしました。コミット差分はSourceTreeを使って追いかけています。ソースコード全体はcloneしたrepositoryをIntelliJで開いて読んでいます。気を抜くとどんどんcanaryが進んでいく最初のコミット記念すべき最初のコミットは2016年10月。Readme.mdのみのコミット。SSRのための軽量なフレームワークとして誕生したようです。Pages routerも目玉だったぽい。記念すべき最初のコミット~1.2まで省略Next.jsの基本構造を学ぶ上で興味深い内容が沢山ありましたが、全部書いていくのは大変なので割愛。初期のSSRやハイドレーションの仕組みなどがわかります。この頃はReact Hooksも無く、JavaScriptを前提としていて、結構読むのは大変。CSS関連も現在は使ってない仕組みを利用しているのであまり深入りしても得るものは少ないかも。prefetchサポート (~v2.0.0)2016/12/16のコミット。github.comprefetchを行うLinkコンポーネントと、prefetchを明示的に行う関数を追加しています。Service Workerを用いて、prefetch対象のURLをCacheStorageに事前に保存します。Next.jsはSSRを行った際に、ハイドレーションのためのJSONデータをページに埋め込んでいて、クライアントサイドでそのデータを取り出して使っています。画面遷移の際はnext/routerがページのJSONデータを取り出すAPI*1にXHRでリクエストして、取得したJSONを使って再レンダリングをしています。prefetchではLinkコンポーネントをレンダリングしたタイミングで、遷移先のJSONデータを取りに行ってCacheStorageに保存しています。XHRでリクエストするとService Workerのfetchイベントがトリガーされ、そこでキャッシュがあればそれを利用するという仕組みになっているので、next/routerがページ遷移する際に、prefetchしたキャッシュを使うといった動作になるようです。こんな感じで面白かったコミットをメモっていきます。ペース的に最新に追いつけるのかちょっと不安ですが、古すぎるものはできるだけスキップできればと思っています。*1:pagesに対して自動で生える

Next.js全部読む 1

「テクノロジーで人々を適切な医療に案内する」をミッションに、ヘルスケアプラットフォームを提供しているUbie株式会社の八木（@sys1yagi）です。ソフトウェアエンジニアとして医療機関事業のプロダクト開発や新規事業の立ち上げなどを行っています。Ubieでは「Dev Genius」という名前の社内版ChatGPTを内製しています。続きをみる

OpenAI Assistants APIを使って社内用GPTsを作った際に苦労した5つの点

DoroidKaigi 2023の公式アプリのリポジトリが公開されましたね。github.comAndroidアプリケーション開発から離れて久しいので、まずは最新のトレンドや技術について学ぶために、このプロジェクトを使って実際に手を動かしながら、気になる部分を調べてメモしていくことにしました。コントリビュートはできそうならやろうかなと考えています。build-logicってなにプロジェクトをAndroid Studioで開き、ビルドして動かしつつプロジェクト内を眺めると、何やら見慣れないモジュールが。app-iosとapp-androidというモジュールから、プロジェクト全体がKotlin Multiplatformぽいことは推測できます。また、core, featureは共通のロジックやUIとかだろうな〜とも推測できます。ではbuild-logicとは一体なんなのか？中身をチラッと眺めてもよくわかりませんでした。いっぱい書いてて大変やな〜というのが第一印象。build-logicはGradleのComposing buildsを用いた共通のビルド設定まずは根本から辿っていこう、ということで、Project rootのbuild.gradle.ktsやsettings.gradle.kts を読みました。するとsettings.gradle.kts に次のような記述がありましたhttps://github.com/DroidKaigi/conference-app-2023/blob/main/settings.gradle.kts#L2pluginManagement {    includeBuild("build-logic")    ...}includeBuildってなんだろう？と調べてみるとComposing buildsというページが見つかりました。docs.gradle.orgincludeBuildに指定したmoduleの設定を取り込めるもの、と理解しました。詳細を見るとなんだか難しそうなので、conference-app-2023での使い方に着目してみると、次のようにpluginをregisterしている記述が見つかりました。https://github.com/DroidKaigi/conference-app-2023/blob/main/build-logic/build.gradle.kts#L35register("androidApplication") {    id = "droidkaigi.primitive.androidapplication"    implementationClass = "io.github.droidkaigi.confsched2023.primitive.AndroidApplicationPlugin"}register("android") {    id = "droidkaigi.primitive.android"    implementationClass = "io.github.droidkaigi.confsched2023.primitive.AndroidPlugin"}idはpluginIdで、implementationClassはpluginの動作を記述しているクラスのFQCNです。対応するクラスの実装を見てみると、build.gradleに記述しそうなことが書いてあります。例：https://github.com/DroidKaigi/conference-app-2023/blob/main/build-logic/src/main/kotlin/io/github/droidkaigi/confsched2023/primitive/AndroidComposePlugin.ktJetpack ComposeやDagger Hiltなんかは結構色んな設定を書くので、各種モジュールに毎回宣言するのは大変ですもんね。pluginとしてまとめて、モジュール側でpluginをapplyする形にすることで、共通化をしているようです。マルチモジュールでは必須の仕組みと言えそうですね。ちょっとした気になりbuild-logicは、プロジェクト全体に、configをまとめたplugin群を定義する仕組みと分かりました。実際にfeature moduleを覗いてみると、pluginをapplyしています。https://github.com/DroidKaigi/conference-app-2023/blob/main/feature/about/build.gradle.ktsplugins {    id("droidkaigi.convention.androidfeature")}android.namespace = "io.github.droidkaigi.confsched2023.feature.about"dependencies {    implementation(projects.core.designsystem)    implementation(projects.core.ui)    implementation(projects.core.model)    testImplementation(projects.core.testing)    implementation(libs.androidxCoreKtx)    implementation(libs.composeUi)    implementation(libs.composeHiltNavigtation)    implementation(libs.composeMaterial)    implementation(libs.composeUiToolingPreview)    implementation(libs.androidxLifecycleLifecycleRuntimeKtx)    implementation(libs.androidxActivityActivityCompose)    implementation(libs.composeMaterialIcon)    androidTestImplementation(libs.composeUiTestJunit4)    debugImplementation(libs.composeUiTooling)    debugImplementation(libs.composeUiTestManifest)}droidkaigi.convention.androidfeatureにはandroidアプリに関するpluginがいくつかバンドルされています。さてそこで気になるのは、モジュールのdependenciesの記述です。droidkaigi.convention.androidfeatureにはJetpack ComposeやDagger Hilt、テスティングなどのdependenciesが含まれています。droidkaigi.convention.androidfeatureを利用するモジュールで再度dependenciesを宣言する必要は無い気がしますが、実際には宣言が書かれていました。試しに重複しているdependenciesを除去して、クリーンビルドしたら、無事ビルドが成功しました。なんとなくrepository公開に向けてわーっと作ってこの辺りの重複除去はまだ特にやってない、ということかなと解釈しました。libs.versions.tomlってなにモジュールのdependenciesを見ると、testImplementation(projects.core.testing)implementation(libs.androidxCoreKtx)といった具合にlibs.androidxCoreKtxという謎の変数を参照しています。これは一体どこから来るのか？gradle/libs.versions.tomlというファイルを見つけました。中身はなんだかpackage.json.lockだとかGemfile.lockみたいな雰囲気。conference-app-2023/gradle/libs.versions.toml at main · DroidKaigi/conference-app-2023 · GitHub[versions]androidGradlePlugin = "8.1.0"# For updating Kotlin and Compose Compiler version, see:# https://github.com/JetBrains/compose-multiplatform/blob/master/VERSIONING.md#kotlin-compatibility# https://developer.android.com/jetpack/androidx/releases/compose-kotlin?#pre-release_kotlin_compatibilitykotlin = "1.9.0"androidxCore = "1.10.1"androidDesugarJdkLibs = "2.0.3"compose = "1.5.0"compose-jb = "1.4.3"composeCompiler = "1.5.1"...これはGradleのバージョンカタログという機能のようです。developer.android.combuild-logic/settings.gradle.ktsで当該tomlファイルを読み込む記述をしていて、これによりプロジェクト全体でバージョンカタログの変数を参照できるようになっているようです。https://github.com/DroidKaigi/conference-app-2023/blob/main/build-logic/settings.gradle#L10バージョンの変数宣言はとっ散らかる感じがあったので、こういった仕組みは便利ですね。nextGradleの設定やモジュール構成とKotlin Multiplatformの関係性がまだ理解しきれていません。次回はKotlin Multiplatformの構成について学び、各モジュールの関係について調べようと思います。

DoroidKaigi conference app 2023を読んでいく 1

こんにちは、Ubie(ユビー)株式会社のUbie Discoveryという組織で、ソフトウェアエンジニアとして働いている八木(@sys1yagi)です。ChatGPTが賑わっていますね。正確にはGPT-3.5やGPT-4といった大規模言語モデルのブレークスルーが賑わっているわけですが、一般的にはChatGPTを通して大規模言語モデルに触れるというケースがほとんどだと思います。ChatGPTの業務利用のリスク続きをみる

Generative AI(ChatGPT)と対話する、社内用生産性向上ツールを開発し、業務利用リスクを解決した話

ChatGPTを作っているOpenAI社は、サードパーティ向けにOpenAI APIを提供しています。クライアントライブラリも提供していて、一般的なREST APIとして各種機能が簡単に使えます。https://platform.openai.com/docs/libraries続きをみる

openai-nodeを使ってchat/completionsのstreamをフロントエンドで試す

これはUbie Engineers & Designers Advent Calendar 2022 11日目の記事ですこんにちは、Ubie(ユビー)株式会社のUbie Discoveryという組織で、ソフトウェアエンジニアとして働いている八木(@sys1yagi)です。続きをみる

チームトポロジーを取り入れ、スケールフェーズに合った組織構造に移行した話

ユビーAI問診は、Ubieが提供する医療機関向けのプロダクトです。患者さんに対して問診を実施し、医師向けのカルテを作成します。現在は大きく分けて、タブレットとスマートフォンの２つの利用方法があります。タブレット用、スマートフォン用の画面これらはどちらもWebアプリケーションとして実装していて、フロントエンドはReact/TypeScriptで書いています。問診のプロセスは画面遷移が多いユビーAI問診は紙の問診票で書くような定型的な質問だけでなく、来院した目的に合わせて様々な質問を行います。例えば「頭が痛い」といった症状を入力した場合、発症時期や部位、痛みの程度、持続時間、経過、頻度などを掘り下げて、更にそれらの回答内容から疑われる疾患に関連する質問を重ねていきます。あるいは「足をひねった」など外傷に関する場合は、スポーツをしていたかや事故かといった状況を聴取したりします。問診の長さは入力内容によって様々ですが、短くて10数回、長いと4、50回ほど画面遷移を行います。質問の種類は10数種程度なので、質問の表示の動作確認はStorybookなどを用いれば十分行えます。しかし問診の回答結果に基づいて作成するカルテは、膨大なパターンの質問と回答の組み合わせがあるため、動作確認にはかなりの労力を必要とします。最初の数質問の分岐。今はもっと複雑にCypressによるE2Eテストを開発時の動作確認用に導入するUbieでは基本的にひとつのフィーチャーをひとりのエンジニアが担当します*1。バックエンドとフロントエンドの両方を設計・実装したあと、全体の動作確認を行うわけですが、一回の問診は数分かかるのでトライアンドエラーが発生すると非常に時間がかかります。そこでE2EテストフレームワークであるCypressを、開発時の動作確認用に導入することにしました。特定の問診フローを実行するテストを追加していくことで、開発時の動作確認を気軽に行えるようにしようという目論見です。Cypressを選んだ深い理由は特になかったのですが、導入が簡単な点拡張が容易な点（テスト中にNode.jsで任意の処理を実行できる）Cypress StudioというGUIアプリケーションで、テストの実行や管理が容易な点などが気に入っています。Cypressを導入するCypressの導入は非常にかんたんです。yarn add -D cypress # あるいは npm install cypress --save-dev次のコマンドでCypress Studioを起動できます。yarn run cypress open # あるいは npx cypress open初回の起動時にテストのための各種ファイルが生成されます。cypress├── fixtures│   └── example.json├── integration # テストをここに置く│   ├── 1-getting-started│   └── 2-advanced-examples├── plugins│   └── index.js└── support    ├── commands.js    └── index.jsCypress Studio。integration配下のテストが一覧されるデフォルトはjsなので、TypeScriptにするための設定がちょこちょこ必要になります。https://docs.cypress.io/guides/tooling/typescript-supportとりあえず動かすGoogleで'Cypress E2E'というキーワードで検索し、https://www.cypress.ioのページを開くテストをするとします。実装は次のとおりです。describe('CypressをGoogleで検索する', () => {  it('Cypress E2Eで検索するとヒットする', () => {    // Googleを開く    cy.visit('https://google.com');    // input要素にキーワードを入力する    cy.get('input')        .first()        .clear()        .type('Cypress E2E{enter}');    // Cypressのページタイトルを探して、クリック    cy.get('h3')      .contains('JavaScript End to End Testing Framework')      .click();  });});cyという特殊なオブジェクト以外は概ねJestのような書き口です。上記のコードが動作する様子開発環境でCypressを利用する基本的には最初にvisitするページをlocalhostにすれば自分の環境で立ち上げたアプリケーションにアクセスするテストが書けます。開発環境でのログインのテストの様子画面の操作をする他にアサーションも書けます。// 画面上に'診察券がある'という文言のボタンが存在することを要求するcy.get('button').contains('診察券がある').should('exist');要素の状態のアサーション以外にも、Cookieの値やURL、API Callの内容の検証などについても行えます。Introduction to Cypress | Cypress Documentationプラグインを使ってテスト実行前にDB設定を整えるlocalhostに向けてテストを書くだけでは不十分です。医療機関にはいろいろな種類や設定があり、それぞれ動作が異なります。これらの設定を行うにはデータベースをセットアップしなければなりません。CypressのテストコードはChromeやFirefoxなどの環境で動作するので、そこからデータベースを直接操作するといったことは基本的にはできません。バックエンド側に開発用のAPIを生やすことも考えられますが、そうすると複数の環境にテストのためのコードが散逸してしまうためできれば避けたいところです。Cypressではプラグインを追加できます。プラグインはNode.jsで動作します。デフォルトでtaskというプラグインがあり、ここでNode.jsで動作する任意の処理を追加できます。https://docs.cypress.io/api/commands/taskplugins/index.tsでtaskイベントに対する処理を記述することで、(module).exports = (on) => {  on('task', {    hello(message: string): string {      // Node.jsで動作する      const value = `hello ${message}!`;      console.log(value);      return value;    }  });}テストコードから呼び出せるようになります。// ブラウザではなく、コマンドラインのほうに'hello world!'とログが出るcy.task('hello', 'world'); ここでNode.js向けのデータベースクライアントを導入し、データをセットアップするtaskを追加することで、テスト実行時に必要な環境を整えられるようになります。ユビーAI問診では各テーブル毎にCRUD操作をする関数を生やして、任意のデータを用意できるようにしています。TypeOrm を使い、typeorm-model-generatorで既存のテーブルからEntityを生成したので、比較的簡単に準備用のコード群ができました*2。このスタイルの場合、データベースを直接操作し、バックエンドAPIに対して実際にAPI Callをすることになるので、CIなどでのテスト実行は困難になります。少し迷いましたが、あくまで開発時に使うということで割り切ることにしました。導入してよかった点思ったよりメンテしやすい動作確認を楽にするためとはいえ、メンテナンスが難しいと結局コストとしてどうなんだっけ？ということになりますが、Cypressのテストコードはかなりメンテナンスがしやすい印象です。Best Practices | Cypress Documentationを参考に再利用可能な関数を整頓していくと様々なバリエーションのテストを素早く増やしていけます。TypeScriptが使える点もありがたいです。experimentalですがCypress Studio上で操作を記録し、テストコードを生成する機能もあります。Cypress Studio | Cypress Documentationこの辺りは要素のセレクタなどを適切に準備する必要があるので気軽には使えないですが、テスタブルなコードを書く動機にもなって良いなと思います。大胆な変更も安心できる一連のシナリオを実行するテストを書けば、何度でも使えるので、そのシナリオ中に関連するコードを変更する際にリグレッションテストとして機能します。問診のフローはかなり複雑に関連しあっているので、これまでは変更にかなり慎重に取り組まなければなりませんでしたが、テストが増えていくにつれて大胆な変更が可能になりました。ドキュメントとしての価値もあった実はCypressを導入したあとに気づいたのですが、各種テストをきちんと構造化するとドキュメントとしての価値もでてきました。現在カバーできている範囲は全体の数％にも満たないですが、それでも新たな実装に対してCypressのテストを追加することで、他の人に引き継いだり、時間が経過した後のキャッチアップなどが容易に行えます。データのセットアップもコードで表現しているので、前提条件なども把握できるようになっており、CIでの実行を犠牲にした価値は十分あったかなと思います。心残りな点とはいえやはり、CIなどの第三者による定期的な実行は諦めきれない要素です。どうしても人間が任意のタイミングで実行するだけでは漏れが生じるからです。この間も圧倒的に壊れていました。この辺りは別途対策を考えています。各リポジトリのdevelopブランチをデプロイする環境を持っておいて、変更が入るとデプロイ後にCypress Testをキックするなど、自前で用意することになりますが実現自体は可能なのではないかと思っています。まとめE2Eテストというと結構重たいというか、大変そうなイメージがありましたが、開発時の動作確認ツールとして割り切ることで、かなり便利に使えることがわかりました。ユビーAI問診は開発が始まってから時間が経っていて、ドメインの深さやコードの複雑さが新メンバーの負担になったり、あるいは古い人が離れられないといった問題がありました。CypressのE2Eテストがすべてを解決するわけではありませんが、今後もこうした取り組みを重ねて、壊れにくく、キャッチアップしやすく、手離れしやすい環境を作っていきたいと思っています。そんなUbieでは新たなソフトウェアエンジニアを募集しています。最近はフロントエンド、バックエンドに特化したポジションが増えたりしていますので、昔見たな〜という方もぜひまた見てみてください。recruit.ubie.life*1:もちろん規模が大きい場合手分けする場合もあります*2:prismaも検討しましたが、複数のDB接続を簡単にはできなそうだったので諦めました。https://github.com/prisma/prisma/issues/2443

開発時の動作確認ツールとしてCypressのE2Eテストを導入した話

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]になった。めちゃくちゃ時間を溶かしました。ドキュメントはちゃんと読まないといけませんね。

rubyのslice!でめっちゃハマった

こんにちは、Ubie(ユビー)株式会社でソフトウェアエンジニアとして働いている八木(@sys1yagi)です。ソフトウェアエンジニア採用といえば技術面接ですよね。技術的な経験に関するインタビューや、コーディングテスト、技術課題の提出、ライブコーディングなどを行い、候補者の経験や技術力、技術の方向性やキャリア観などが自社とマッチするかを確認するというのが一般的かと思います。続きをみる

ソフトウェアエンジニア採用で技術面接をやめました

Ubie(ユビー)株式会社でソフトウェアエンジニアをしている八木(@sys1yagi)です。現在Ubieはソフトウェアエンジニアが25名おり、採用活動の進捗としてはまもなく30名を超えることが見えてきています。Ubieには大きく2種類のプロダクトがあります。病院向け(toB)の「AI問診ユビー」というプロダクトと、一般ユーザ向け(toC)の「AI受診相談ユビー」というプロダクトです。病院向けの「AI問診ユビー」は、病院、クリニック、グローバル(アジア)に分かれており、全体で4つのプロダクトを開発しています。これらのプロダクトは15個のサービスを組み合わせて動作しています。続きをみる

Pactで小さく始めるコンシューマ駆動契約テスト

Ubie(ユビー)株式会社でソフトウェアエンジニアをしている八木(@sys1yagi)です。Ubieに入社してすでに1年8ヶ月くらい経ってますが(2019年4月入社)、入社エントリを書いていなかったので書きます。【特にこんな人に読んでほしい】・Ubieに興味があるけど、技術スタック全然違うしな〜って思ってる人・キャリアとか転職とか皆どういう観点で考えてるんだろと気になる人続きをみる

事業とプロダクトで転職先を選んだら一致する技術スタックがほぼ0個だった話

viewModelScopeを使っている関数を持つViewModel次のRecommendBookViewModelクラスは、loadRecommendBooks関数という内部でviewModelScopeを用いて非同期処理を行う関数を持っている。import androidx.lifecycle.ViewModelimport androidx.lifecycle.viewModelScopeimport kotlinx.coroutines.flow.MutableStateFlowimport kotlinx.coroutines.flow.StateFlowimport kotlinx.coroutines.launchimport hoge.fuga.recommendbook.RecommendBookimport hoge.fuga.recommendbook.RecommendBookRepositorydata 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'}TestCoroutinesExtensionを用意するJunit5ではorg.junit.rules.TestRule は無くなった。代わりにorg.junit.jupiter.api.extensionパッケージ内の各種インタフェースを実装したクラスを、ExtendWithで指定する形になった。そこでDispatchers.setMain()などを実行するTestCoroutinesExtensionを作る。package hoge.fugaimport kotlinx.coroutines.Dispatchersimport kotlinx.coroutines.test.TestCoroutineDispatcherimport kotlinx.coroutines.test.resetMainimport kotlinx.coroutines.test.setMainimport 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)  }}ViewModelのテストを書くTestCoroutinesExtensionを使ってRecommendBookViewModelのテストを書く。import com.google.common.truth.Truth.assertThatimport io.mockk.coEveryimport io.mockk.mockkimport hoge.fuga.TestCoroutinesExtensionimport hoge.fuga.recommendbook.RecommendBookimport kotlinx.coroutines.test.TestCoroutineDispatcherimport kotlinx.coroutines.test.runBlockingTestimport org.junit.jupiter.api.Nestedimport org.junit.jupiter.api.Testimport 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)    }  }}割とシンプルにできて良さそう。

Junit5でJetpack ViewModelのviewModelScopeを使っている関数のテストをする

本エントリはUbie Advent Calendar 2020の22日目です。21日目はtoCプロダクトAI受診相談ユビーのプロダクトオーナーである@shikicheeのエンジニアの僕が強みを活かして施策推進したら、異次元の角度で数字が伸びちゃった話でした。自分は現在toBプロダクトである、医療機関向けのAI問診ユビーのソフトウェアエンジニアをしています。普段はRails/Ruby、Spring Boot/Kotlin、React/TypeScriptを使ってバックエンドからフロントエンドまでプロダクトに関連することについて全般的に開発をしています。またこのほかに最近は全社的な技術戦略に関するロールを持っており、サービス全体のカタチをどのようにしていくかについて考えたり手を動かしたりしています。本エントリでは、Ubieの現在のシステムの状況と、起こり始めている現象などを紹介しつつ、今後どのようなことを行っていくかについてまとめます。Ubieの今とサービス群Ubieは今年で創業から4年目を迎えました。現在のサービス群の基となるコードは、共同創業者の一人である久保(@quvo_ubie)が大学院時代の研究で作り始めました*1。コードベースとしてはこの研究時代の2年間を足した6年物ということになります。現在のUbieのソフトウェアエンジニアやサービス、プロダクトの数は次の通りです。ソフトウェアエンジニアの数： 24人サービスの数(デプロイの単位)：15個プロダクトの数：4個独立して動作するサービス群の関連は次のようになっています。サービスの関連図この図にプロダクトの境界を引くと...プロダクトの境界線結構こんがらがっているように見えますね。実際に結構こんがらがっています。現在に至る変遷Ubieでは創業から現在に至るまで、不確実性を下げるための検証にフォーカスしてきました。それぞれの局面毎に、リソースや時間の制約を鑑みて最善手と考えられるものを重ねているものの*2、やはりどうしても複雑化していっています。創業前 疾患推測エンジン最初のサービス創業前（およそ2年）ソフトウェアエンジニアの数：1人サービスの数：1個プロダクトの数：0個不確実性：症状群の入力による疾患推測が実現可能か創業1年〜 toC 症状チェッカー AndroidアプリAndroidアプリとAPI創業1年~ソフトウェアエンジニアの数：2〜3人サービスの数：2個 (Androidアプリも1個と数える)プロダクトの数：2個不確実性：症状に基づいた疾患推測にニーズがあるのか創業2年〜 toB AI問診サービス 病院向け病院向けのフロントエンドを追加創業2年~ソフトウェアエンジニアの数：3〜7人サービスの数：3個プロダクトの数：2個不確実性：症状チェッカーを病院につなげることがそもそもできるのか疾患推測エンジンの実現、症状チェッカーの価値検証を経た後、出口としては 実際に患者さんが病院に受診する/しないことが重要となってきます。この時点で医療機関にとっては、症状チェッカーは患者さんの受診行動に影響を与えるかもしれませんが、業務上の課題には特に貢献しません。病院に受診した患者さんは改めて1から問診を行うからです。そこで医療機関の業務上の課題解決にフィットするプロダクトの検証が始まりました。創業2.5年〜 toC 症状チェッカーサービス(テスト版)チームが複数生まれてサービスも分割されていった創業2.5年~ソフトウェアエンジニアの数：7〜12人サービスの数：8個 (toC, toB, 疾患推測の単位で分割開始)プロダクトの数：2個不確実性：症状に基づいた疾患推測ニーズのスケーラビリティ医療機関向けのプロダクトの形がある程度見えてきた頃、症状チェッカーのリプレースが始まりました。Androidアプリは廃止し、Webサービスとして作り直しています。アプリの場合、症状チェックをするために症状の発現 -> 症状で検索などをする -> アプリの認知 -> インストール -> チェック という風にかなりの数の手続きを踏まなければなりません。症状があるユーザにとってはかなりの負担です。Webサービスにすることで症状の発現 -> 症状で検索などをする -> ランディング -> チェック とスムーズに症状チェックができるようになりました。同時にその形態でスケールは可能なのかという点の検証が必要となります。創業3年〜 toB AI問診サービス クリニック向け病院向けにクリニック向けが乗っかる形創業3年~ソフトウェアエンジニアの数：12~18人サービスの数：12個プロダクトの数：3個不確実性：クリニックでスケールするための特有の普遍的な課題が存在するか病院とは入院施設としてベッド数が20床以上、医師3名以上の機関を指します。それ以外は診療所となります。街に沢山あるクリニックや医院は診療所です。国内の病院はおよそ8000件で、診療所は100000件です。病院と診療所では来院患者数や医療従事者の規模が異なります。業務上の課題や関心事も大きく異なるのではないか、という仮説のもと、プロダクトを分けて検証をはじめました。創業4年〜 toB AI問診サービス アジア向け、症状チェッカーと AI問診サービスの接続あっという間に15個創業4年~ソフトウェアエンジニアの数：18~24人サービスの数：15個プロダクトの数：4個不確実性：AI問診サービスが、海外の医療環境においても課題解決に貢献できるのか症状チェッカーをトリガーとした、受診をする/しないが起こるのか国内の医療機関への導入が徐々に進んできたところで、医療制度が近しい国においてもAI問診サービスが役に立つのか検証をはじめました。また国内においては症状チェッカーで行った問診をAI問診サービスを導入している病院に直接送ることができるようになりました。２つのプロダクトが繋がり、サービスの関連図には現れてこない複雑さも生まれ始めています*3。現在起こっている現象ソフトウェアエンジニアの人数、サービスの個数、プロダクトの数が着々と増えていく中、開発において起こっている現象が沢山あるわけですが、代表的なものとしては次の通りです。暗黙知の部分のキャッチアップや変更コストが増加特に文脈を知らない新メンバーは大変そうです。新メンバーはみんな荒野でも生き抜けるパワーを持っていますがとはいえ力を発揮するリードタイムはだんだん増加していっています。プロダクト間で共用している箇所が存在し、壊れやすい共通ではなく共用となっています。一言でいうと1ロジックに2プロダクトの知識が詰まっていたりします。即日壊れます。新しいアイデアの検証をするときのインベストが大きい領域があるたとえば、問診を聴取していくフローは症状チェッカーと医療機関向けプロダクトの両方の知識を有していて、さらにそれぞれが複数のパターンを持っているので、分岐が複雑になっています。特定の診療科向けに柔軟に質問を追加したり省略するといったことを気軽に試すのは難しい状態となっています。技術的負債という視線個別に現象に対処して行ってもいいですが、現在の人数やプロダクトの増加速度を鑑みると、もう少し中長期目線で考えたほうがよさそうだなぁということで、技術的負債の観点でそれぞれの現象を見直してみました。ここでいう技術的負債とは、技術的負債の言葉の生みの親であるウォード・カニンガム氏の次の定義に準じます。「もしも自分たちが書いているプログラム（WyCash）を、金融の世界に関する正しい捉え方だと自分たちが理解した姿と一致させることができなくなれば、自分たちは絶えずその不一致につまずき続けることになり、開発スピードは遅くなっていくでしょう。それはまるで借金の利子を払い続けるかのようです」t-wada.hatenablog.jpそれぞれ 正しい捉え方だと自分たちが理解した姿と一致していないのではないか という観点で見直すと、暗黙知の部分のキャッチアップや変更コストが増加システムが、正しい捉え方だと自分たちが理解した姿と一致していない形であることで、リバースエンジニアリング的なアプローチによる理解を困難にしているのではないか。本当に複雑なのか、一致していないのか見直す必要があるのではないかプロダクト間で共用している箇所が存在し、壊れやすい共用している部分が、利用者にとって独立した共通のものなのか、似ている別のものなのかが曖昧。あるべき姿にできていないか、あるべき姿をまだ見いだせていない可能性があるのではないか。新しいアイデアの検証をするときのインベストが大きい領域があるシステムが、あるべき姿の解像度が低い段階の時のままになっていることで大きく結合してしまっているのではないか。そのために不確実性の高いものを部分的に足し合わせる時に必要な変更が大きくなるのではないか。不確実性の高い部分を素早く検証するために、不一致を許容するのは重要である一方で、不確実性が下がった後もその部分を放置しておくと、やがて様々な症状が現れてくるのかなと思います。不確実性の混在を避ける逆にこれらを解決していけば、現象の解消や防止ができるのではないかと考えました。ROIで考える正しい捉え方だと自分たちが理解した姿と一致させ続けることはとても重要だと考えつつも、とはいえリソースと時間の制約があるので、どこまでなにをするかをどう決めていくかは大事です。Ubieでは皆2言目にはROIだROIだと言っています。ポジショントーク用のポンチ絵図はほとんど意味を持っていませんが、つまり、複雑度を上げるような追加変更は線形に増えていきますが、開発のインベストはいつの間にか指数関数的に増加していくので、インベストが爆発するまえになんとかしたい、ということです。同時にこれを予防できればある程度の負債は許容してもよさそうです。なぜインベストの増加を予防したいのかというと、当然速度やコストに効いてくるからですが、それ以外にも意思決定の歪みを防ぐという観点があるかと思います。issueの質が高くて低インベストの領域にフォーカスしたい技術的負債によってインベストが増加すると、質の高いissueであっても優先度が下がったりします。重要な検証の優先度が下がるのは時にクリティカルになります。issueの質が高いのに高インベストのために後回しになるということで、直近で解くべき課題は現在すでにインベストが高くなっている箇所の解消将来インベストが高くなると予見される箇所などの可視化不確実性が高い場所と低い場所が共存できるカタチを見つける（機動的な検証が可能な状態）かなと定義しました。これによって人数やサービスやプロダクトが増えても速度を落とさない、むしろ加速するような状態を作っていきます。マイクロサービスアーキテクチャとDDD（ドメイン駆動設計）に入門する守破離ということで、すでにややマイクロサービスぽく分割していることもあって、マイクロサービスアーキテクチャについて改めてしっかりと入門することにしました。マイクロサービスアーキテクチャの序盤の章では、サービス分割の観点でDDDを参照しています。DDDの考え方は、技術的負債のあるべき姿と一致させるという考え方と似ています。エリック・エヴァンスのドメイン駆動設計 では歯を食いしばって真のモデルとシステムを一致させるといった言葉が何度も出てきます。マイクロサービスアーキテクチャの各種ノウハウを取り入れる前に、まずは現在のシステムとあるべき姿のギャップを、DDDにおけるコンテキストとその境界を描くことで可視化していきました。あるべき形をコンテキストマップで可視化する境界づけられたコンテキストを考えていくコアドメインはなんだろうというところから初めて、徐々に現在のサービス群が何を提供しているかなどを考えながら付け足していきました。実際の作業はmiroで複数人で行っています。実際の図。めっちゃぼかしてます。あんまり現実のシステムを意識せず、理想状態を考えるとスムーズに行くなぁという感想です。同時にあまりにギャップありすぎてちょっと引くみたいな時もあります。コンテキスト境界と現実の乖離が分かってくるコンテキストマップを書いていくと、実際のコンテキストとサービスが横断している場所が見えてきました。次の画像は症状チェッカーと医療機関向けプロダクトが連携する箇所ですが、複数のサービスが1つのコンテキストに対して同時に携わっていることがわかります。実際にこの部分は壊れやすく、慎重な変更が必要になってしまっています。複数のプロダクトが交差する場所価値創出の単位と業務フローまた、コンテキストマップを描いていく中で、1つの業務フローに対して、いくつかの独立したコンテキスト達が複数組み合わせられていることに気づきました。一つの業務フローに対して複数のコンテキストが組み合わさっているそれぞれのコンテキストは個別に価値を生み出せそうな単位でありますが、現状はプロダクトの特定の業務フローのなかに埋まっています。これらを価値創出の単位として切り出せそうです。それぞれのコンテキストが独立して価値を生み出す価値創出の単位を自由に組み合わせることができるようになれば、考えてもみなかった、あるいは実現が難しいと思っていたプロダクトをどんどん作り出せるのではないか、と期待できます。不確実性を内包するためのモジュラモノリスの考え方を取り入れるコンテキストマップによって現在すでにインベストが高くなっている箇所の解消のためのアクションの洗い出しや、将来インベストが高くなると予見される箇所などの可視化ができました。不確実性が高い場所と低い場所が共存できるカタチを見つけるについてはまだまだこれからですが、価値創出の単位がそれぞれ確からしいかどうかを判断したり、新しい不確実性をどのように追加していくかについて、モジュラモノリスの考え方が役に立つのではないかと思っています。www.infoq.comqiita.comモジュラモノリスはモノリスの中でモジュールによって境界を分離していくものです。すでにUbieは複数のサービスが分かれているので、本当のモジュラモノリスにしていくぞというのは現実的ではありません。しかし複数のコンテキストを持っていそうなサービスにおいて、モジュールによる分離をまずは行うというアプローチは非常にコスパが良いのかなと思っています*4。価値創出を掛け算可能にするシステムを作るここから先はまだこれからです。ということでおそらく大小様々な課題と直面していくと思いますが、一連の活動を価値創出を掛け算可能にするシステム の第1歩目と定義し、医療の領域の課題解決を加速していきたいと考えています*5。プロダクト開発もエンジニアリングも好きという方は是非一緒にやっていきませんか！？note.com待ってます。*1:症状に基づいた疾患推測エンジンの研究が、現在のUbieのプロダクトの根幹となっています*2:もちろん失敗してる場合も沢山あります！*3:サービスの関連図に現れてないということはどこかのサービスが複数の関心事を取り扱っていることになりますが、まさにそうです！*4:まだ何も試してないので本当に雰囲気で良さそうって思ってるだけです*5:正直来年の今頃入社するメンバーがうらやましい！

患者さんと病院をつないでいくシステムの今とこれから

material-uiのTextFieldをtesting-library/reactでテストしようとすると、HTMLElementを取り出すところで苦労したのでメモを残す。TextFieldに付与したaria-labelはinputのラッパー要素に付く次の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つの方法がある。querySelector関数を使う１つ目の方法は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とするだけで十分。getByDisplayValue関数を使う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の内部構造を知った上で書く必要があるのでちょっとな〜という気はしますが仕方ない気もする。

 testing-library/reactでmaterial-uiのTextFieldの値をテストする

最近AtCoderなどに参加していて、すべての組み合わせを生成しつつ計算するといった機会になんどか遭遇し、毎回頑張って実装していたのだけど、bit全探索という方法があるらしいと知り、調べて、Kotlinでどう書くか考えた結果次のようになった。import java.util.BitSetfun 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()で有効なインデックスのストリームが手に入るので大体いい感じにできる。

bit全探索 in Kotlin

個人のプロジェクトでMaterial-UIを使っているんですが、コンポーネントがHiddenを含んでいると、テストがうまく動きません。hoge.tsximport * 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>  )};hoge.test.tsximport 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よりは楽かもという気持ち

 Material-UIのHidden要素をテストする

前回に引き続いて。left, rightがstart, endにレイアウトのleft, rightが start, endになりました。なるだろうなーと思ってたので想定どおり。beforeLayoutPadding(  top = 16.dp  left = 8.dp,  right = 8.dp,  bottom = 16.dp)afterLayoutPadding(  top = 16.dp  start = 8.dp,  end = 8.dp,  bottom = 16.dp)DrawImageを廃止Imageを描画するDrawImageがなくなりました。代わりにSimpleImageを使います。このあたりは今後も色々と変わりそうですね。beforeContainer(  width = 100.dp,  height = 200.dp) {  DrawImage(image)}afterContainer(  width = 100.dp,  height = 200.dp) {  SimpleImage(image)}androidx.compose.Contextを廃止ContextAmbientはandroidx.compose.Contextを返してましたが、androidx.compose.Contextになりました。beforeimport androidx.compose.Contextafterimport android.content.ContextAppBarIconを廃止TopAppBarのnavigationIconに使うAppBarIconがなくなり、代わりにIconButtonを使う形になりました。beforeTopAppBar(  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を渡してもちゃんと動く)。afterTopAppBar(  title = {    Text(context.getString(R.string.app_name))  },  navigationIcon = {    IconButton(      onClick = {        backStack.pop()      }    ) {      SimpleImage(        BitmapImage(context.getBitmap(R.drawable.ic_baseline_arrow_back_24))      )    }  })ArrangementにVertical, Hotizontalの概念を追加Column, RowともにArrangementが設定できますが、寄せる方向の設定がStart, Endという名前でした。なので次のように同じ値でもColumnかRowかで意味が異なります。beforeColumn(  modifier = LayoutWidth.Fill,  arrangement = Arrangement.End // 下寄せ) {  Row(    modifier = LayoutWidth.Fill,    arrangement = Arrangement.End // 右寄せ  ) {    // something  }}ArrangementにVertical, Hotizontalの概念を追加し、使える値を増やしつつ制限をかけています。これにより意味を理解しやすくなりました。afterColumn(  modifier = LayoutWidth.Fill,  arrangement = Arrangement.Bottom // Arrangement.Endは使えない) {  Row(    modifier = LayoutWidth.Fill,    arrangement = Arrangement.End  ) {    // something  }}おわりに今までは1ヶ月に1リリースという感じでしたが、2月は2回ありました。I/Oに向けてガガガッとスパートかけてる感じなんでしょうか。楽しみですね。

 Jetpack Compose 0.1.0-dev05から0.1.0-dev06にしたときに変更が必要だったところ

Jetpack Compose 0.1.0-dev05がリリースされましたね。0.1.0-dev05でui-foundationにAdapterListというComposableが追加されました。待望のAdapterListAdapterListの説明は次のようになっています。A vertically scrolling list that only composes and lays out the currently visible items.今まではRecyclerViewのようなComposableが存在せず、VerticalScrollerを使ってそれっぽい動作をしていましたが、VerticalScrollerはScrollViewと同じものなので実用には限界がありました。AdapterListはRecyclerViewと同じように、表示されている要素だけをレンダリングするので、大量の要素があってもサクサク動作します。AdapterListの使い方AdapterListのシグネチャは次の通りです。@Composablefun <T> AdapterList(  data: List<T>,  modifier: Modifier = Modifier.None,  itemCallback: @Composable() (T) -> Unit)実際に使うには次のようになります。import android.os.Bundleimport androidx.appcompat.app.AppCompatActivityimport androidx.ui.core.Textimport androidx.ui.core.setContentimport androidx.ui.foundation.AdapterListimport androidx.ui.layout.Containerimport androidx.ui.layout.LayoutPaddingimport androidx.ui.layout.LayoutWidthimport androidx.ui.material.MaterialThemeimport androidx.ui.material.surface.Cardimport androidx.ui.unit.dpclass MainActivity : AppCompatActivity() {  override fun onCreate(savedInstanceState: Bundle?) {    super.onCreate(savedInstanceState)    setContent {      MaterialTheme {        val data = 0.until(100).toList()        AdapterList(data = data) {          Card(modifier = LayoutPadding(top = 8.dp, bottom = 8.dp, left = 16.dp, right = 16.dp)) {            Container(modifier = LayoutWidth.Fill + LayoutPadding(16.dp)) {              Text("Hello ${it}")            }          }        }      }    }  }}AdapterListはまだ実用できない0.1.0-dev05の時点ではまだ2コミットしかないので、実用に足らないのは当然っちゃ当然かなと思います。https://android.googlesource.com/platform/frameworks/support/+log/refs/heads/androidx-compose-release/ui/ui-foundation/src/main/java/androidx/ui/foundation/AdapterList.kt具体的な問題としては 要素のクリックイベントが動作しない という点があります。例えば次のコードのButtonはうまく動作しません。class MainActivity : AppCompatActivity() {  override fun onCreate(savedInstanceState: Bundle?) {    super.onCreate(savedInstanceState)    setContent {      MaterialTheme {        val data = 0.until(100).toList()        AdapterList(data = data) { value ->          Card(modifier = LayoutPadding(top = 8.dp, bottom = 8.dp, left = 16.dp, right = 16.dp)) {            Container(modifier = LayoutWidth.Fill + LayoutPadding(16.dp)) {              Button(onClick = {                println("click! $value")              }) {                Text("button ${value}")              }            }          }        }      }    }  }}いくらか実験してみたところ、Ripple要素があるとクリックイベントが実行されないようです。Buttonは　Ripple + Clickableで構成されているので反応しなくなっているようです。Rippleを使わずClickableのみを使えば動作はするのですが、タッチフィードバックがなくなるので厳しいです。もちろんこうした問題は今後どんどん改善されていくと思いますが、今すぐに使うというのはちょっと難しそうです。おわりについにAdapterListが登場して実用段階への光が射してきましたね。さすがにプロダクション投入はまだまだ難しいですが、一部のViewをComposeに置き換えるのは十分できそうだなぁと思います。

 Jetpack Compose 0.1.0-dev05で追加されたAdapterListを眺める

Jetpack Compose 0.1.0-dev05が出ました。リリースノートはこちら https://developer.android.com/jetpack/androidx/releases/compose#0.1.0-dev05前回に引き続き、アップデートでエラーになる部分と対応方法を紹介していきます。androidx.ui.layout.Paddingが廃止androidx.ui.layout.Paddingが廃止され、androidx.ui.layout.LayoutPaddingになりました。PaddingはComposableだったのに対して、LayoutPaddingはModifierです。次のような使い方になります。beforePadding( 8.dp ) {    Text(text = "こんにちは")}afterText(    modifier = LayoutPadding( 8.dp ),    text = "こんにちは")FontFamilyのコンストラクタがprivateになったカスタムフォントを使う時はres/font にフォントファイルを置きつつ、FontFamilyを作って利用する形だったのですが、FontFamilyのコンストラクタがprivateになり、作り方が変わりました。beforeFontFamily(  // res/font/ipam.ttf にファイルを置いておく  Font(name = "ipam.ttf", weight = FontWeight.W400, style = FontStyle.Normal))afterfont(R.font.ipam, weight = FontWeight.W400, style = FontStyle.Normal)Ambient.ofが廃止Ambient.ofの代わりにambientOf関数が生えました。Providerも独立して、Providersになりました。Provideする値増えたらネスト大変だなーと思ってたところなのでちょうどいいです。beforeval IpamFontAmbient = Ambient.of<FontFamily>()@Composablefun IpamFontProvider(children : @Composable() () -> Unit) {    val fontFamily = remember {        FontFamily(            Font(name = "ipam.ttf", weight = FontWeight.W400, style = FontStyle.Normal)        )    }    IpamFontAmbient.Provider(value = fontFamily, children = children)}afterval IpamFontAmbient = ambientOf<Font>()@Composablefun IpamFontProvider(children : @Composable() () -> Unit) {    val font = remember {        font(R.font.ipam, weight = FontWeight.W400, style = FontStyle.Normal)    }    Providers(IpamFontAmbient.provides(value = font), children = children)}ambient関数が非推奨上位のComposableからProvideされる値を取り出す時はambient関数を使ってましたが、非推奨になりました。代わりにambient関数にkeyとして渡しているAmbilentインスタンスのcurrentを使います。beforeval font = ambient(IpamFontAmbient)afterval font = IpamFontAmbient.currentandroidx.ui.core.ambientDensity関数が廃止Composable内でdensityを取り出せるandroidx.ui.core.ambientDensity関数がなくなりました。beforeimport androidx.ui.core.ambientDensityval density = ambientDensity()afterimport androidx.ui.core.DensityAmbientval density = DensityAmbient.currentwithDensity関数が廃止withDensity関数は、DensityScope.() -> Unitを受け取ることで、Dp.toPx関数などの拡張関数を使えるスコープを提供するのですが、なくなりました。代わりにDensityScopeと同様の拡張関数を持つDensity interface が用意されました。DensityAmbient.currentでDensityインスタンスを取り出せるので、kotlinのwith関数を使って同じことができます。beforewithDensity(density) {    Paint().apply {        isAntiAlias = true        style = PaintingStyle.stroke        this.strokeWidth = strokeWidth.toPx().value    }}afterval density = DensityAmbient.currentwith(density) {    Paint().apply {        isAntiAlias = true        style = PaintingStyle.stroke        this.strokeWidth = strokeWidth.toPx().value    }}ImageがPainterに変更画像の表示はImageを使ってましたがPainterという抽象クラスが使われるようになりました。VectorAssetはImageになれないので、Painterで抽象化するのかなと思ったらVectorPainterはまだないみたいです。beforeAppBarIcon(  icon = imageResource(R.drawable.ic_baseline_arrow_back_24),  onClick = {    backStack?.pop()  })afterAppBarIcon(  icon = ImagePainter(imageResource(R.drawable.ic_baseline_arrow_back_24)),  onClick = {    backStack?.pop()  })Buttonの引数が変更styleが展開されたほか、textがなくなりchildrenになりました。beforeButton(    "キャンセル",    style = ButtonStyle(        backgroundColor = MaterialTheme.colors().secondary,        contentColor = MaterialTheme.colors().onSecondary,        shape = MaterialTheme.shapes().button,        elevation = 2.dp    ),    onClick = onCloseRequest)afterButton(    backgroundColor = MaterialTheme.colors().secondary,    contentColor = MaterialTheme.colors().onSecondary,    shape = MaterialTheme.shapes().button,    elevation = 2.dp,    onClick = onCloseRequest) {    Text("キャンセル")}終わりに結構大変だった...。でもだいぶ洗練されてきた印象がある。今後が楽しみです。

 Jetpack Compose 0.1.0-dev04から0.1.0-dev05にしたときに変更が必要だったところ

Jetpack ComposeにはSeekBarがないので、必要な場合は今の所自分で作ることになります。で作りました。0.1.0-dev04 での実装なので将来そのままでは動かなくなると思うのでご注意ください。Preview使う実際の動作はこんな感じになりますstreamable.com実装Draggableを使って実装します。横棒とか丸は頑張って描画してます。Draggableは値の範囲がfixedなので、横幅が動的(いわゆるmatch_parent)の場合利用が難しいです。そのためDraw関数とparentSizeを使って、widthをstateに持つみたいなことをやってます。@Composableprivate fun paint(): Paint {    return Paint().apply {        color = MaterialTheme.colors().primary        isAntiAlias = true    }}@Composablefun SeekBar(    @FloatRange(from = 0.0, to = 1.0) progress: Float,    fixedWidth: Dp? = null,    onChangeProgress: (Float) -> Unit) {    val squareSize = 32.dp    val barHeight = 8.dp    val fixedWidthPx = withDensity(ambientDensity()) { fixedWidth?.toPx()?.value }    val (width, setWidth) = state {        fixedWidthPx ?: 0f    }    if (width == 0f) {        Container(            modifier = LayoutWidth.Fill        ) {            Draw { _, parentSize ->                val newWidth = parentSize.width.value                if (newWidth != width) {                    setWidth(newWidth)                }            }        }    } else {        val squareSizePx = withDensity(ambientDensity()) { squareSize.toPx().value }        val max = width - squareSizePx        val min = 0.dp        val (minPx, maxPx) = withDensity(ambientDensity()) {            min.toPx().value to max        }        val position = animatedDragValue(maxPx * progress, minPx, maxPx)        val paint = paint()        Draggable(            dragDirection = DragDirection.Horizontal,            dragValue = position,            onDragValueChangeRequested = {                position.animatedFloat.snapTo(it)                onChangeProgress(position.value / max)            }        ) {            Container(                modifier = fixedWidth?.let { LayoutWidth(it) } ?: LayoutWidth.Fill,                alignment = Alignment.CenterLeft,                height = squareSize            ) {                Stack {                    Padding(                        top = squareSize / 2 - barHeight / 2,                        left = squareSize / 2,                        right = squareSize / 2                    ) {                        ColoredRect(                            Color.LightGray,                            height = barHeight                        )                    }                    Draw { canvas, _ ->                        canvas.drawCircle(                            Offset(position.value + squareSizePx / 2, squareSizePx / 2),                            squareSizePx / 2,                            paint                        )                    }                }            }        }    }}おわりにProgressBarなども横幅fixedなんでスクラッチしたり、わりとスクラッチが必要だけど、結構カスタムなコンポーネント作るのそんなに難しくないので、UIライブラリがどんどん出てくるかもなと思ったりします。β、RCが待ち遠しいですね。

 Jetpack Compose (0.1.0-dev04) でSeekBarをスクラッチする

Jetpack Compose 0.1.0-dev04が出ましたね、今回からリリースノートのページもできたみたいです。developer.android.comまだプレビューなんでどんどんAPIが変わっていきます。もしまともに使ってるとえらいことになるわけですが、個人的にproduction readyを待たずなんかアプリ出したろと思っているのでガンガン使っています。で、0.1.0-dev03から0.1.0-dev04にしてみると案の定えらいことになったので変更が必要だったところをまとめます。0.1.0-dev03から0.1.0-dev04にしたときの様子コンパイラの設定0.1.0-dev03では、どうもkaptとの相性が悪く、Backend Internal error: Exception during code generation みたいなエラーがでてコンパイルできなかったのですが、0.1.0-dev04では、オプションを追加することで回避できるようになったようです。android {  composeOptions {    kotlinCompilerExtensionVersion "0.1.0-dev04"  }}最初、compileOptionsに書いてエラーになって頭を抱えたんですが、composeOptionsでした。unaryPlusの廃止+state とか +ambient とか +imageResource とかの、+が要らなくなりました。単純に+を消して回ればOK。effectOfが廃止unaryPlusの廃止と同時にeffectOfも廃止になりました。代わりに @Compose を使えとのこと。beforeprivate fun paint(color: Color, strokeCap: StrokeCap, strokeWidth: Dp) = effectOf<Paint> {    val paint = +memo { Paint() }    // ...    paint}after@Composableprivate fun paint(color: Color, strokeCap: StrokeCap, strokeWidth: Dp): Paint {    val paint = remember { Paint() }    // ...    return paint}まぁカスタムでeffectOf使うケースあんまりなさそうなのでもし引っかかったらという感じです。memoがrememberにリネームbeforeval count = +memo { 0 }afterval count = remember { 0 }dp, sp, IntPxなどが移動beforeimport androidx.ui.core.Dpimport androidx.ui.core.PxSizeimport androidx.ui.core.dpimport androidx.ui.core.spafterimport androidx.ui.unit.Dpimport androidx.ui.unit.PxSizeimport androidx.ui.unit.dpimport androidx.ui.unit.spFlexRow, FlexColumnが非推奨ここが一番たいへんでした。FlexRow、FlexColumnが非推奨となり、代わりにRow、Columnを使えとのこと。次のようなレイアウトを考えると、以前はFlexRowとinflexible, flexibleを使って書いてました。before@Preview@Composablefun DefaultPreview() {  MaterialTheme {    FlexRow {      inflexible {        Padding(16.dp) {          Row {            Padding(left = 4.dp) {              Text("1")            }            Padding(left = 4.dp) {              Text("2")            }          }        }      }      flexible(1f) {        Container(          modifier = ExpandedWidth,          alignment = Alignment.TopRight        ) {          Padding(16.dp) {            Text("こんにちは")          }        }      }    }  }}FlexRowが非推奨となりinflexible, flexibleなども消滅しました。代わりにRowを使います。after@Preview@Composablefun DefaultPreview() {  MaterialTheme {    Row(modifier = LayoutWidth.Fill) {      Padding(16.dp) {        Row {          Padding(left = 4.dp) {            Text("1")          }          Padding(left = 4.dp) {            Text("2")          }        }      }      Container(        alignment = Alignment.TopRight,        modifier = LayoutFlexible(1f)      ) {        Padding(16.dp) {          Text("こんにちは")        }      }    }  }}Rowの中はデフォルトがinflexibleです。flexibleはLayoutFlexibleを使います。LayoutFlexibleはRowScopeからしかアクセスできません。ExpandHeight, ExpandWidthの廃止LayoutHeight.Fill, LayoutWidth.Fillになりました。おわりどんどん進化してますね。βが出るのが楽しみです。ScrollingListというRecyclerViewぽいやつも早くほしいっす。

 Jetpack Compose 0.1.0-dev03から0.1.0-dev04にしたときに変更が必要だったところ

Jetpack Composeでカスタムフォントを使うには、FontFamily を用いる。res/fontにフォントファイルを置き、FontFamilyにFontを渡す。// res/font/ipam.ttfがあるとすると次のようになる。FontFamily(  Font(name = "ipam.ttf", weight = FontWeight.W400, style = FontStyle.Normal))使う実際使う際は次のように+memoなんかを使って取り出しておき、TextStyleにセットする。@Preview@Composablefun CustomFontSample() {    val fontFamily = +memo {        FontFamily(            Font(name = "ipam.ttf", weight = FontWeight.W400, style = FontStyle.Normal)        )    }    Text(        text = "こんにちは",        style = TextStyle(            fontSize = 14.sp,            fontFamily = fontFamily        )    )}こうなる。ambientを用意する使う箇所で毎度取り出すのは煩雑なのでambientを用意しておくとよさそう。import androidx.compose.Ambientimport androidx.compose.Composableimport androidx.compose.memoimport androidx.compose.unaryPlusimport androidx.ui.text.font.Fontimport androidx.ui.text.font.FontFamilyimport androidx.ui.text.font.FontStyleimport androidx.ui.text.font.FontWeightval IpamFontAmbient = Ambient.of<FontFamily>()@Composablefun IpamFontProvider(children : @Composable() () -> Unit) {    val fontFamily = +memo {        FontFamily(            Font(name = "ipam.ttf", weight = FontWeight.W400, style = FontStyle.Normal)        )    }    IpamFontAmbient.Provider(value = fontFamily, children = children)}次のようにIpamFontProviderのchildで+ambient関数を使ってProvideしているFontFamilyを取り出せるようになる。@Preview@Composablefun CustomFontSample() {    IpamFontProvider {        val fontFamily = +ambient(IpamFontAmbient)        Text(            text = "こんにちは",            style = TextStyle(                fontSize = 14.sp,                fontFamily = fontFamily            )        )    }}setContent辺りの根本で囲んでおけばアプリ全体でどこでも取り出せるようになる。このあたりはFlutterのproviderに考え方が似てるんじゃないかと思う。おわりにCompose面白い。

 Jetpack Composeでカスタムフォントを使う

Ubie Advent Calendar 2019の9日目です。チームコラボレーションツールっていっぱいありますよね。UbieではSlackやメール、Notion、Google Hangouts、Jira、Figma、Github、HERP、Salesforceなどのほかに「Miro」というチームコラボレーションサービスを使っています。MiroってなにMiroはオンラインのホワイトボードプラットフォームです。もともとRealtime Boardっていうサービスでしたが、最近(といっても2019年の序盤)Miroって名前になったようです。miro.comMiroは、ほぼ無限の2次元空間にリアルタイムで同時に複数人で図を書くことができます。図を作る際にテンプレートを選べますが、最初に配置されているアイテムが異なるだけで操作は同じです。MiroのテンプレートUbieではMiroをどのように使っているか複数のユーザが同時に図を書くサービスというと結構思いつきますよね。Figma、Google図形描画、Cacooなどなど。UbieではFigmaをUI/UXに関するデザインに利用し、それ以外の図は概ねMiroを使うといった形で運用しています。それ以外の図とはたとえば次の通りです。設計を議論するときに利用する図アーキテクチャを図示するER図のようなものを書くシーケンス図のようなものを書く責務を洗い出し境界を引くetc..タスクの洗い出しと分類画面遷移のバリエーションを洗い出す業務フローの図簡易ガントチャートの作成ユーザーストーリーマッピング全社横断のKPT座席表etc...例: チームの計画をざっくり図に起こすチームのバックログの管理はJiraを用いていますが、並んでいるタスクたちを時間軸に並べたとき厚みがどうなるかとかデッドラインがここだねとか、いつまでに何が終わってないとここはズレるよねといった話をするためにMiroで図を書いたりします。レトロスペクティブの際などにこれを眺めて色々組み替えたりします。例: リリースフローを図にする病院向けのプロダクトは、バグの混入やデグレなどをできるだけ防ぐために厚めのリリースフローになっています。リリース日が決まっており前日から準備するスタイルで、リリース担当を持ち回りで行います。リリースフローのドキュメントはありますが、リリース内容によって手順が異なる場合があったり、不具合が見つかった場合のフローなど複雑なので、図にもしつつ、認識わせしたり自動化可能なポイントを洗い出したりしています。例: ユーザーストーリーマッピングを行うチーム結成当初やクォータの区切り目などで、短期中期でフォーカスするものなどについて認識合わせしたり議論するために、ユーザーストーリーマッピングを行ったりしてます。スライスをざっくり置いてますがそこまで厳密に運用はせず、目線合わせを主な目的として使っています。例: 座席表を作る座席表なんかも作ったりします。そろそろ40名を超えてきてかなり手狭になってきました...ここがいいよMiroということで、Miroは概ね何にでも使えて便利です。特に強力だなと実感するのは、リモートで集まって議論する場合です。リモートでもホワイトボードで議論してる感覚に近づけるさすがに物理ホワイトボードの体験にはかなわないんですが、リモートメンバーがいるミーティングをする場合などはMiroのほうが捗ります。エンジニアが集まってミーティングする様子(わかりづらいけどリモートメンバーもいます)。Ubieはその日にリモートするかは各自で決めるほか、フルリモートのメンバーもいたりします。ミーティングする際は大画面にGoogle Hangoutsを映して、画面共有しながら会話します。 設計議論のときなんかはリモートメンバーもMiroをいじりつつ会話しつつで概ね対面に近い成果物が得られます。また電子化された状態で残るのもいいですね。ここが気になるMiro複数人で図を書くという体験については申し分のないMiroですが、一点使っててしんどい部分があります。図の一覧画面で図のサムネイルが出ない(なんか設定する必要あるのかな?)デフォルトでソート条件が last opened になっていて他者が作った新規の図が一生見つからない後者はまぁソート条件変えればいいんですが、デフォルトはlast modifiedとかにしてほしいですね...、前者についてもまぁ空間が無制限なのでどこを切り取るか難しいってのはありつつ基本ノープレビューは厳しい感じがあります。こうするといいよみたいな方法あったらぜひ教えてください。おわりにざっくりですがMiroを紹介しました。Ubieに入社したときはすでにMiroが導入されていたので、Ubieでの業務的な前後の比較は僕はできないですが、前職含めてわりとホワイトボードと付箋最強でやっていたので初めて触ったときは結構衝撃を受けました。ぜひ一度試してみてください！Ubieってどんな会社なんと思ったかたはWe-are-Ubie-会社・事業・組織・採用のことを是非御覧ください（やや画像重いかもです...）。

 チームコラボレーションサービス「Miro」いいなぁという話

adventar.org昨年のノンアルコールビールで晩酌すると風呂上がりにさっぱりプログラミングできて助かる - visible trueに引き続き、今年も書きます。まるで酔っ払っているかのように雑です。自我を失ったノンアルコールビールたちさて個人的にノンアルコールビールではアサヒドライゼロが好きで、いつもノンアルコール飲料を選ぶ時はドライゼロを買っています。ドライゼロ｜アサヒビールある日、アサヒドライゼロを仕入れるか〜とスーパーに赴いたら新たなノンアルコールビールたちが棚にひしめき合っていました。www.asahibeer.co.jpwww.kirin.co.jpwww.suntory.co.jpwww.sapporobeer.jpおいおいおいおいおい「糖の吸収を抑える」、「脂肪を減らす！」アルコールもプリン体も失い、更に糖の吸収を抑え脂肪を減らす機能を付与されるとは。バーソロミュー・くまか。飲んでみる6缶入りはパッケージにでかでか「脂肪を減らす！」って書いてあってちょっと恥ずかしかったので1缶ずつ買いました。「これちょっと恥ずかしい」味はどれもおいしく、値段も手頃*1だし良い感じでした。この中ではカラダフリーが香りが好みで一番スキな感じでした。パッケージさえ気にならなければドライゼロと交互に飲もうと思うくらい。ノンアルコール充実してきたビール系だけでも結構増えてるけど、日本酒系なんかも出てきてノンアルコールアツいですね。www.gekkeikan.co.jp酒税かからないから安いし、アルコール入ってないので健康的、美味しい。うれしい。*1:120円/缶くらい

ノンアルコールビールめっちゃ増えてる

Ubie Advent Calendar 2019の2日目です。最近チームで新しいサービスが必要になったのでKtorでやろうか！ってことでKtorでサービスを書き始めています。データベースはGoogle Cloud Spannerを使おうということになりました。Java/KotlinのWebアプリケーションにおいて、データベースのマイグレーションライブラリというとFlywayが有名かと思いますが、残念ながらFlywayはGoogle Cloud Spannerをサポートしていません。SpannerをサポートするPull Requestは存在するのですが、2018/01/01に作られたもので、Pull Requestを出した方はその後、google-cloud-spanner-jdbcを公式のgoogle-cloud-javaライブラリに追加*1したりしていますが、Flyway側の動きはなさそうです。Pull Requestをつついたり引き継いだりしようか考えましたが、リリースタイミングをコントロールできない点と、機能的にKtorで使える範囲であれば小さそうということで、自分で作ってしまおうと考えました。spanner-kase名前はCloud SpannerのSchemaを入れておく場所ということでspanner-kase(スパナケース)にしました。https://github.com/ubie-inc/spanner-kase色々ケアレスミスをしてバージョンはいきなり1.1.3です。spanner-kaseでできることspanner-kaseでできることは次の通りです。指定したパス内のマイグレーションファイル(.sql)を収集し実行する。実行したマイグレーションファイルのバージョン情報を永続化し、バージョンに差分があればマイグレーションを実行する実行済みのマイグレーションと、収集したマイグレーションファイルのchecksumを比較して、変化を検出した場合はエラーを送出する使い心地としては概ねFlywayかなと思います。Ktorで使うことだけを想定しているので、Spring Boot等ではうまく動かないかもしれません。spanner-kaseの使い方spanner-kaseを使うには次の手順が必要ですspanner-kaseをプロジェクトに追加するマイグレーションファイルをresourcesに配置するgoogle-cloud-spannerのクライアントを初期化するSpannerKaseDatabaseClient、MigrationDataScannerを作るSpannerKaseを作ってマイグレーションを実行するspanner-kaseをプロジェクトに追加するspanner-kaseは内部でgoogle-cloud-spannerを使っていますが、推移的な依存関係を避けるためにimplementationで宣言しているので、利用時には別途google-cloud-spannerを追加する必要があります。// build.gradle.ktsimplementation("app.ubie.spanner-kase:1.1.3")implementation("com.google.cloud:google-cloud-spanner:$GOOGLE_CLOUD_SPANNER_VERSION")マイグレーションファイルをresourcesに配置するKtorプロジェクトを作ると最初からresourcesディレクトリがあると思うので、そこにマイグレーションファイルを置いていきます。パスは特に指定はないですが、ここではdb/migrationに配置しています。.├── build.gradle.kts├── src│   └── ...├── resources│   └── db│       └── migration│           ├── V1__User.sql│           ├── V2__Todo.sql│           └── V3__Permission.sql...マイグレーションファイルには命名規則があります。V[VERSION]__[NAME].sqlVERSIONの範囲はLong*2です。VERSIONが若い順に順次実行します。すでに実行済みのVERSIONは実行しません。VERSIONは年月日時分秒で書くのがおすすめです。V20191201142511__User.sqlgoogle-cloud-spannerのクライアントを初期化するspanner-kaseは内部でgoogle-cloud-spannerを使っているので、まずはSpannerクライアントを作ります。val options = SpannerOptions.newBuilder().build()val projectId = options.projectIdval spanner = options.service// spanner-kaseで使うval instanceId = InstanceId.of(projectId, YOUR_INSTANCE_ID)val databaseId = DatabaseId.of(projectId, instanceId.instance, YOUR_DATABSE_ID)val databaseAdminClient = spanner.databaseAdminClientval databaseClient = spanner.getDatabaseClient(databaseId)databaseAdminClientはSpannerのDDL(Data Definition Language)を更新する際に、databaseClientはデータのCRUDを行う際に利用します。SpannerKaseDatabaseClient、MigrationDataScannerを作る次にSpannerKaseDatabaseClientとMigrationDataScannerを作ります。SpannerKaseDatabaseClientはspanner-kaseがバージョン管理のために使うテーブルの操作をする他に、マイグレーションファイルのSQLの実行などを行います。val spannerKaseDatabaseClient = SpannerKaseDatabaseClient(    instanceId.instance,    databaseId.database,    databaseAdminClient,    databaseClient)MigrationDataScannerはマイグレーションファイルの収集を受け持ちます。MigrationDataScanner自体はinterfaceなので、任意の実装を利用できます。予めClassLoaderMigrationDataScannerを用意しています。KtorではApplicationを初期化する際に、environmentのClassLoaderを使うことで、resources内のマイグレーションファイルを利用できます。@kotlin.jvm.JvmOverloadsfun Application.module() {    // 省略    val migrationDataScanner = ClassLoaderMigrationDataScanner(        environment.classLoader, // io.ktor.application.Application.environment        "db/migration" // relative path from resources dir    )}SpannerKaseを作ってマイグレーションを実行するあとはSpannerKaseを初期化して、migratie() を実行するだけです。val configure = SpannerKase.Configure(        spannerKaseDatabaseClient,        migrationDataScanner    ) SpannerKase(configure).migrate()おわりに早急に必要になる！と思ってザーッと作ったけど、優先度いくつか入れ替えてまだspanner-kaseを使うサービスはプロダクションでは出ていないので、まだもうちょいアップデートあるかもしれません。Ktor + Spannerは割とレアな気がしますが、もし機会があれば触ってみてください。*1:FlywayでのサポートPR時に作ったものを公式に提案して取り入れられたっぽい*2:1 - 9,223,372,036,854,775,807

 Ktor用のSpannerのスキーマバージョン管理ライブラリ「spanner-kase」を作った話

YoutubeAndroid Dev Summit '19のセッション！www.youtube.comAndroid Studio 4.0 とJetpack ComposeのセットアップJetnewsというサンプルアプリを試したり、新規プロジェクトでJetpack Composeで始めたり、既存のプロジェクトにJetpack Composeど導入する方法について書いてある。developer.android.comJetpack Compose チュートリアルJetpack Composeの基本の解説。Composable functionsやレイアウト、スタイル、Themeなどの説明。developer.android.comCodelab↑のドキュメントがCodelabになった感じ。わかりやすい。codelabs.developers.google.comSample projectJetNewsというアプリのサンプル。ナビゲーションドロワー、画面遷移などJetpack Composeで全て行っている。データは埋め込みなので通信処理等はない。かなり参考になる。github.comSample project2自分で作ったもの。Navigation、ViewModelを使う。Github APIをRetrofitで実際に検索する。既存プロジェクトとの共存をイメージしているけど、JetNewsがSPAぽい世界観なので迷っていきている。github.comおわりにまだまだ進化中という感じだけどいい感じなのではという気持ち。

 Android Studio 4.0とJetpack Compose関連の見るとよいところなどのメモ

Kotlin Fest 2019楽しかったです。今回は「Kotlinコルーチンを理解しよう 2019」を話してきました。資料作りの様子、各セクションを作る時になに考えてたか、反省点などまとめます。前回と今回でロゴの形がちょっと変わってる資料コルーチンとはなにか、から実際使ってどうテストするかまでを45分でまとめるのはなかなか難しかったですが、一応網羅的にやれたか！？とは思っています。作る時はヒイヒイ言っててなにも考えてなかったけど改めてみると、これから触っていく場合に最初に読むものとして結構いいかもしれんと思うなどしました。speakerdeck.comコルーチンとはなにか、なにがうれしいのか概念については自分のなかではある程度理解できてたものの、対象コルーチンや非対称コルーチンについて曖昧だったので改めて調べた。新雑誌「n月刊ラムダノート」の『「コルーチン」とは何だったのか？』の草稿を公開します - まめめもはとても参考になりました、また、Google公式で紹介していた次のエントリも考え方の整頓にとても助かりました。Google Developers Japan: Android でコルーチン（パート I）: 背景を理解するGoogle Developers Japan: Android のコルーチン（パート II）: 使ってみるGoogle Developers Japan: Android のコルーチン（パート III）: 実際の処理特にパート3のSingleRunnerの実装はこの辺に転がっているがめちゃんこ役に立つので参考にすると良いと思います。このほか2004年の論文 Revisiting Coroutinesもまた改めて読んだ。前よりは理解できた。コルーチンの何が嬉しいかについては昨年末のGoogle Play App Dojoでの登壇(http://sys1yagi.hatenablog.com/entry/2018/12/19/104023)でまとめていたのでそこまで迷いはなかった。スライドの最初の、コンウェイによる概念の発明、simulaによる実装、様々な言語の様々な実装の話は、発表では30秒くらいでサラッと流したけど、コンウェイの論文(http://www.melconway.com/Home/pdf/compiler.pdf)を見に行ったり、simulaのコルーチンプログラムを読んだり(http://staff.um.edu.mt/jskl1/talk.html の Chess game control using Two Masters approach.のセクション)、Module-2やSchemeやLispに入門してみたり、Pythonのasync/awaitやRubyのFiberを試したりなんかしてめっちゃ時間をかけてしまった。が良かった。対象コルーチン、非対称コルーチン、各言語の実装、継続やスタックがどうとかいう議論など、歴史を感じる事ができた。これのおかげでサラッと話せたんだなと思う。Kotlinにおけるコルーチンの仕組み最初は結構細かく書いていた。suspendキーワードの話のあと、CPS(Continuation Passing Style)とステートマシン生成について話し(https://github.com/Kotlin/KEEP/blob/master/proposals/coroutines.md#implementation-details)、さらにsuspend関数がContinuationImplに、suspendラムダがSuspendLambdaに変換される様子をバイトコードを見て話したり、更にsuspendラムダの拡張関数を使ってコルーチンを実行する様子なんかも眺めたかったけど、実際使っていくにあたってはそこまで意識しないことだよなーっていうのと圧倒的に時間オーバーする事がわかって削った。// suspendラムダの拡張関数。関数型に拡張関数生やせるの面白い@InternalCoroutinesApipublic fun <T> (suspend () -> T).startCoroutineCancellable(completion: Continuation<T>) = runSafely(completion) {    createCoroutineUnintercepted(completion).intercepted().resumeCancellable(Unit)}結果的に利用者にとって一貫性のある内容になったんじゃないかって気がしたので良かった(使う時にCPSが〜とかはあんま考えないので)。KotlinコルーチンのきほんKotlinコルーチンは関係要素が多すぎて何から説明するかとても大変だった。このセクションは基本的にKotlin公式のドキュメントに沿って話すことにした(https://kotlinlang.org/docs/reference/coroutines/coroutines-guide.html)。このセクションが一番長くて時間が足らないってことで結構削ってしまった。コルーチンビルダー関数について深ぼったり(特にsuspendラムダとか起動周りとか)、コルーチンスコープのインスタンス作って動かしてみる例があればもっと理解を深められただろうと思う。コルーチンディスパッチャーについても、こう使うと切り替えられますという感じで割り切ったのでちょっと心残りである。コルーチンディスパッチャーは奥が深くてDefaultとIOの違いとか、MainとServiceLoaderに関する話なんかも面白い。実行コンテキストの合成とかもややこしいけど面白い点だ。あともうちょい、このセクションに出る要素でほぼ実用はできるって点はもっと丁寧に説明できたらな〜と思ったりした。コルーチンスコープと構造化された並行性自分のなかで構造化された並行性についてはイメージがあったのでわりとスムーズにいった。最初はRoman氏のStructured concurrencyとそこから参照されているNotes on structured concurrency, or: Go statement considered harmfulに触れたり、構造化プログラミングの非同期版やで〜みたいな話をしようと思ったけど、生まれた背景をそこまで細かく知る必要は無い気がしたので省略した。coroutineScope関数のあたりで、実はwithContext関数もスコープビルダーだよとか、ファストパスでwithContext関数呼び出しがネストしても実行コンテキストが変わらなければそのまま実行するよとか話したかったけど省略した。またSuperVisorについても省略した。viewModelScopeはSuperVisorJobを使ってたりするけど、まぁ通常はほぼ使わないと思うので省略。分岐と合流の図は自分で書いてみてマジわかりやすいと思ってたので、わかりやすいという感想を見かけてやったねってなった。コルーチンと設計ここもまたサラリと書いた形になった。掘り下げようと思えば色々できたのだけど、考え方だけ伝えればいいかってことでだいぶ削った。そういえばスコープのモチベーションとリークの関係についてもっと説明するべきだった。その上でプラットフォームでスコープ提供してて最高って話ができると良かったかなと思う。suspend関数をメインセーフティで実装したり、コルーチンをメインセーフティで起動したりはまぁこんなものかな。メインセーフティでない例をしっかり示せてなかった気がするのでそこはちょっと反省点。コルーチンのテストコルーチンのきほんのセクションと同等くらいの大きさでめっちゃ大変だった。テスト方法についてもまだまだ固まってない部分もありどうまとめたもんか迷ったりした。Githubにもぜんぜん実践的なテストコードが転がってなくて結構途方に暮れたが自分のアプリで徹底的にテスト書いて事なきを得た。間接的なコルーチンの呼び出しについて、ディスパッチャーを置き換える具体的な方法の紹介はあったほうがよかったなと思った。また、runBlockingTestやsetMainやRule周りも結構ザーッと書いてるんでもうちょい補助的な情報を示せたはずと思ったりした。準備の中でテストに関しての理解が間違ってた！みたいなことが数回発生して全練り直しを2回くらいして大変だった。TestCoroutineDispatcherとDelayHandler周りの実装は面白いので覗きたかったけどさすがに時間が足らないので諦めた。テスト周りは多分まだまだ書く度に悪戦苦闘することになりそう。おわりに今回準備にあたってコルーチンに関する論文をいくつか読んだ(ざくっとだけど)らとても面白かったのと、最近のCoroutines FlowでHoareのCSPモデルが関係する話(Kotlin Flows and Coroutines - Roman Elizarov - Medium)を読んだりして計算機科学をしっかり学んでみたいな〜大学院とかがいいのかな〜とかなんとか思ったりした。しかしまずは車の免許を取ろうと思っている。そしてキャンプに行きたい。参加者、スタッフの皆様ありがとうございました！引き続きKotlinを愛でていきましょう！

 Kotlin Fest 2019で「Kotlinコルーチンを理解しよう 2019」を話してきました

FlowのflowViaChannelを使ってRxBindingを置き換える - visible trueでKotlin Coroutines 1.2.xでFlowというコールドストリームをサポートするクラスや関数群が登場しました。ってことでflowViaChannel関数について書いたら、Kotlin Coroutines 1.3.0-M1でflowViaChannel関数がdeprecatedになりました。previewなのでそういうこともあるでしょう。ということで、FlowのflowViaChannelを使ってRxBindingを置き換える 改め、FlowのchannelFlowを使ってRxBindingを置き換える 話をします。1.3.0-M1でなにが変わったかRelease 1.3.0-M1 · Kotlin/kotlinx.coroutines · GitHubによるとFlowにおけるコンテキスト保存の不変性について見直したとあります。コンテキスト保存の不変性というのは、Flowのブロックをどのコンテキストで実行するかを利用者がコントロールできることを保証するものです。Flowのコンテキスト保存の不変性たとえば次のコードはすべて同じスレッドで実行されます。suspend fun a() {  println("start: ${Thread.currentThread().id}")  flow {    println("emit: ${Thread.currentThread().id}")    repeat(3) { emit(it) }  }    .collect {      println("collect: ${Thread.currentThread().id}")    }}出力は次のようになります。start: 11emit: 11collect: 11collect: 11collect: 11flowOn関数を使うと、upstreamの実行スレッドを変更できます。suspend fun b() {  println("start: ${Thread.currentThread().id}")  flow {    println("emit: ${Thread.currentThread().id}")    repeat(3) { emit(it) }  }    .flowOn(Dispatchers.IO) // ここより上流はDispatchers.IOで動作する    .collect {      println("collect: ${Thread.currentThread().id}")    }}出力は次のようになります。start: 11emit: 14collect: 11collect: 11collect: 11さて、次の場合はどうでしょうか*1。suspend fun c() {  println("start: ${Thread.currentThread().id}")  flow {    kotlinx.coroutines.withContext(Dispatchers.IO) {      println("emit: ${Thread.currentThread().id}")      repeat(3) { emit(it) }    }  }    .collect {      println("collect: ${Thread.currentThread().id}")    }}flow関数のブロック内で新たなコンテキストを使おうとしています。これだと利用者が例えばDispatchers.Mainで動作させたいと思ってもコントロールできませんよね。このコードを実行すると例外が投げられます。start: 11emit: 14Flow invariant is violated: flow was collected in BlockingEventLoop@71cde863, but emission happened in LimitingDispatcher@73ad1220[dispatcher = DefaultDispatcher]. Please refer to 'flow' documentation or use 'flowOn' insteadこのようにflowのブロックの実行コンテキストは、呼び出し元によってコントロールできることを保証するというのが、コンテキスト保存の不変性です。Flowのコンテキスト保存の不変性の見直しコンテキスト保存の不変性の見直しについては次のissueが詳しいです。Flow context preserving property, thread safety and context changing · Issue #1210 · Kotlin/kotlinx.coroutines · GitHub既存のコンテキスト保存の不変性では対応しきれない(あるいはコストがかかる)ユースケースがでてきたようです。そのために新たに、異なるコルーチンからFlowCollector Unitです">*2のemit関数の呼び出しを禁止するようになりました。またchannelFlow関数を導入し、コンテキスト保存の不変性を保証しつつ、簡単に異なる実行コンテキストを利用できるようになりました。その流れでflowViaChannel関数が非推奨になりました。非推奨になった明確な理由の説明がパッと見当たらなかったのですが、flowViaChannel関数のブロックがCoroutineScope.(channel: SendChannel<T>) -> Unitであるのに対して、channelFlow関数のブロックがsuspend ProducerScope<T>.() -> Unitであることから、ブロックが完了すると自動的にChannelをクローズするようにすることで、予期しない不具合を起こりづらくしてるのかな〜と思いました*3。channelFlowを使ってRxBindingを置き換えるではflowViaChannel関数を使うのをやめてchannelFlow関数を使ってRxBindingを置き換えましょうまずはbeforeのflowViaChannel関数を使うパターンです。fun TextView.textChangeAsFlow() =  flowViaChannel<String?> { channel ->    channel.offer(text.toString())    val textWatcher = addTextChangedListener {      channel.offer(it?.toString())    }    channel.invokeOnClose {      removeTextChangedListener(textWatcher)    }  }実はこれ1.3.0-M1では正しく動作しません。flowViaChannel関数の実装がchannelFlow関数を使う形に変更されたために、ブロックを抜けるとchannelがクローズされてしまうのです！怖いですね。channelFlow関数を使った実装は次です。fun TextView.textChangeAsFlow() =  channelFlow<String?> {    channel.offer(text.toString())    val textWatcher = addTextChangedListener {      channel.offer(it?.toString())    }    awaitClose {      removeTextChangedListener(textWatcher)    }  }channel.invokeOnCloseの代わりにawaitClose関数を使っています。これはProducerScopeに追加された拡張関数で、呼び出し元がcancelをするまで待ってくれます。便利ですね。おわりにKotlin Coroutines 1.3.0-M1でFlowはPreviewからExperimentalになりました。まだ変更はいろいろありそうですが進捗してる感じがあってstableが楽しみですね。*1:withContext関数をFQCNで書いているのは、FlowCollector.withContextの利用が禁止されていてコンパイルエラーになるためです。*2:flow関数のブロックがsuspend FlowCollector.() -> Unitです*3:普通にhttps://github.com/Kotlin/kotlinx.coroutines/pull/1214に書いてました..

 FlowのchannelFlowを使ってRxBindingを置き換える

使える気がするんだけど何か方法あるのかなーと思って試してみたら普通に使えばよいことがわかった。index.htmlでWebフォントを読み込む好きなフォントを書く<html lang="en">  <head>        <link href="https://fonts.googleapis.com/css?family=Gentium+Book+Basic&display=swap" rel="stylesheet">  </head></html>fontFamilyで指定するあとは普通にfontFamilyで名前を指定するだけ。@overrideWidget build(BuildContext context) {  return Scaffold(    appBar: AppBar(      title: Text(        widget.title,        style: TextStyle(            fontSize: 32,            fontFamily: "Gentium Book Basic",            fontWeight: FontWeight.bold),      ),    ),こんな感じで反映される。beforeafterまとめWebフォントをそのまま使えるのは良いですね~。

 Flutter for webでWebフォントを使う

Firestore良さそうですよね。ローカルで動作を試せるLocal Emulatorがあるので気軽に試せてさらによさそうです。JVM環境で接続する例があんまり見当たらなかったのでメモします。firestore local emulatorの準備をするとりあえずインストールして、firebase setup:emulators:firestore次のコマンドで起動できればOKです。firebase serve --only firestorefirebaseのバージョンとかでいろいろエラー出たりするのでググったりしてなんとか入れてください。firestore local emulatorをポートを指定して起動するfirebase serve --only firestore ではポートが8080でしか起動できません、そこで次のコマンドでLocal Emulatorを起動します。gcloud beta emulators firestore start --host-port=localhost:8812次のような出力が得られれば成功です。[firestore] API endpoint: http://localhost:8812[firestore] If you are using a library that supports the FIRESTORE_EMULATOR_HOST environment variable, run:[firestore][firestore]    export FIRESTORE_EMULATOR_HOST=localhost:8812[firestore][firestore] Dev App Server is now running.[firestore]application.confにlocal emulatorの設定を書くKtorからlocalhost:8812のLocal Emulatorに接続するために、application.confに設定を書きます。特にfirebaseのための書き方などはないので、適当に書きます。ktor {  firebase {    project_id = $PROJECT_ID    firestore {      emulator {        host = localhost        port = 8812      }    }  }}Ktorから設定を読み込むapplication.confの内容はApplication.environmentから読み込めます。fun Application.module() {  val firestoreEmulatorHost =    environment.config.propertyOrNull("ktor.firebase.firestore.emulator.host")?.getString()  val firestoreEmulatorPort =    environment.config.propertyOrNull("ktor.firebase.firestore.emulator.port")?.getString()?.toInt()  val projectId =    environment.config.propertyOrNull("ktor.firebase.project_id")?.getString() ?: throw IllegalStateException(      "firebase project id not found"    )}Firestoreを初期化するFirestoreでLocal Emulatorに接続する場合はFirestoreOptionsを使って直接Firestoreのインスタンスを作ります。val firestore = FirestoreOptions  .newBuilder()  .setHost("$firestoreEmulatorHost:$firestoreEmulatorPort")  .build()  .service本物につなぐ場合も考慮して次のようなobjectを作りました。import com.google.auth.oauth2.GoogleCredentialsimport com.google.cloud.firestore.Firestoreimport com.google.cloud.firestore.FirestoreOptionsimport com.google.firebase.FirebaseAppimport com.google.firebase.FirebaseOptionsimport com.google.firebase.cloud.FirestoreClientobject FirebaseInitializer {  data class FirestoreEmulator(val firestoreEmulatorHost: String, val firestoreEmulatorPort: Int) {    fun toUrl() = "$firestoreEmulatorHost:$firestoreEmulatorPort"  }  fun firestore(    projectId: String,    emulator: FirestoreEmulator?  ): Firestore {    return if (emulator != null) {      FirestoreOptions        .newBuilder()        .setHost(emulator.toUrl())        .build()        .service    } else {      val credentials = GoogleCredentials.getApplicationDefault()      val options = FirebaseOptions.Builder()        .setCredentials(credentials)        .setProjectId(projectId)        .build()      FirebaseApp.initializeApp(options)      FirestoreClient.getFirestore()    }  }}こんな感じでFirestoreを取り出せます。val firestore = FirebaseInitializer.firestore(  projectId,  if (firestoreEmulatorHost != null && firestoreEmulatorPort != null) {    FirebaseInitializer.FirestoreEmulator(firestoreEmulatorHost, firestoreEmulatorPort)  } else {    null  })やったね。おまけ: KoinでInjectionせっかくなのでKoinでFirestoreインスタンスをinjectできるようにします。とりあえずKoinをdependenciesに追加し、dependencies {  implementation "org.koin:koin-core:2.0.1"  implementation "org.koin:koin-ktor:2.0.1"}モジュールを実装します。Applicationの拡張関数にしとくと楽です。import io.ktor.application.Applicationimport org.koin.dsl.modulefun Application.applicationModule() = module {  single {    val firestoreEmulatorHost =      environment.config.propertyOrNull("ktor.firebase.firestore.emulator.host")?.getString()    val firestoreEmulatorPort =      environment.config.propertyOrNull("ktor.firebase.firestore.emulator.port")?.getString()?.toInt()    val projectId =      environment.config.propertyOrNull("ktor.firebase.project_id")?.getString() ?: throw IllegalStateException(        "firebase project id not found"      )    FirebaseInitializer.firestore(      projectId,      if (firestoreEmulatorHost != null && firestoreEmulatorPort != null) {        FirebaseInitializer.FirestoreEmulator(firestoreEmulatorHost, firestoreEmulatorPort)      } else {        null      }    )  }}あとはアプリケーションの初期化時にKoinをinstallしてモジュールを設定すれば、適当に取り出せるようになります。fun Application.module() {  install(Koin) {    modules(      applicationModule()    )  }  // ...  routing {    get("/firestore") {      val firestore: Firestore by this@routing.inject()        // do something    }  //...}まとめFirestore Local Emulator良さそう。admin的な画面って内蔵されてないんだろうか？ある気がする。わからない。

KtorでFirestore Local Emulatorにつなぐ

今年もKotlin Festが開かれますね。もうセッションの応募はされたでしょうか？トラック数が増えたので今年はさらにいろんなジャンルが聞けるのではないかとワクワクしています。Kotlin/JSとかKotlin/Native, MPPが特に気になります。kotlin.connpass.comとりあえず4つほど応募しました。応募内容は次のとおりです。他の方々の応募状況も見てみたいっす言語機能Kotlin コルーチンを 理解しよう 2019概要Kotlin コルーチンは2017年3月にexperimentalな機能としてKotlin 1.1とともに登場しました。その後2018年10月に正式版の1.0.0がリリースされるまでに、様々な変更がありました。特に2018年9月に加えられた並行性の構造化に関する変更は、それ以前のコルーチンのコードが利用できなくなるなど、とても影響が大きいものでした。ある時点より以前の情報が誤りになってしまう状況は、学習者にとって混乱のもととなります。本セッションではKotlinコルーチンの簡単な歴史をおさらいしつつ、コルーチンとはなにか、コルーチンの簡単な利用方法、コルーチンスコープと並行性の構造化がなぜ生まれたのか、アプリケーションでコルーチンを利用する時の考え方、コルーチンのテスト方法などについて解説します。本セッションがKotlin コルーチンの適切な知識へのガイドになれば幸いです。Kotlin コルーチン 「Flow」を味わい尽くす概要Kotlin コルーチンといえば「async/await」がよく注目されますが、それ以外にもいくつかの機能があります。Channelは、Kotlin1.1においてコルーチンをexperimentalでリリースした時から提供している機能のひとつです。async/awaitは単一の値をやりとりしますが、Channelはストリームを取り扱います。Channelは連続的な値を非同期に送受信する用途に便利ですが、ホットストリームである点が利用の幅を制限していました。Koltin コルーチン 1.2.0から「Flow」というコールドストリームがpreview版として追加されました。本セッションでは、ホットストリームとコールドストリームとはなにか、ホットストリームの課題、Flowの仕組み、Flowの現在の使い方、Flowの使い所などについて解説します。Android KotlinDesign of Android Application with Jetpack and Coroutines概要Google I/O 2019でKotlinがAndroidアプリケーション開発の第1言語に躍り出ました :tada: 。Android Jetpackの各種ライブラリではKotlin向けの拡張(ktx)が充実し、また非同期処理を必要とする部分ではコルーチンのサポートが相次いで行われており、Android Jetpack + Kotlin + コルーチンでアプリケーションを作る下地が整いつつあります。本セッションでは、Google I/O 2019で発表されたAndroid JetpackのLifecylce、LiveData、ViewModelのコルーチンに関する機能を説明し、これらを用いたときのアプリケーション設計をどうするべきかや、テストをどのように行うべきかなどについて解説します。Server side KotlinKtorで小さく始めるAPIサーバ概要2018年11月にJetbrain謹製のウェブアプリケーションフレームワークであるKtor 1.0がリリースされました。Ktorはサーバのコアコンポーネントに対して、実行エンジン(TomcatやJettyなど)、認証、ロギング、CORS、Routingなど必要な機能をDSLで宣言的に追加していくスタイルを採用しています。必要最小限の機能で始められるので、プロトタイピングや単一の責務を持つアプリケーションを素早く作るのに適しています。本セッションではKtorのコンセプト、提供されている機能群、基本的な使い方を説明し、簡単なTODOアプリケーションのREST APIサーバを作ります。Ktorで小さく始めるAPIサーバを体験しましょう！まとめどれか引っかかるといいなー。どしどし応募しましょう！！

 Kotlin Fest 2019のセッションに応募しました。

Android向けロギングライブラリ「Loco」をリリースしました。 - visible trueで1.0.0をリリースしたのですが速攻いくつか修正を入れて1.1.0をリリースしました。しれっと1.0.1も出してました。あとjcenterにも登録できたのでサクッと導入できるようになりました。GitHub - sys1yagi/loco: loco (Log Coroutine) is a logging library using coroutine for Android.loco-core-1.0.1修正は2点。どちらも@chibatchingさんが直してくれました。ありがとうございます！Release core-1.0.1 · sys1yagi/loco · GitHub[Bug fix] Close channel on runner stopped #2 @chibatching 🍰LocoRunner内のChannel閉じ忘れを修正[Cleanup] Add const modifier #1 @chibatching 😄定数にconst付け忘れを修正loco-core-1.1.0Release core-1.1.0 · sys1yagi/loco · GitHub[Breaking Change] Change LocoConfig interface #16破壊的変更です。LocoConfigの引数をいくつか変更しました。SenderとLocoLogのMappingをなくして、sendersを渡す時点で設定できるようにしました。LocoConfig.Extraを追加し、必須でないパラメータはExtraに置くようにしました。Loco.start(  LocoConfig(    store = InMemoryStore(),     smasher = GsonSmasher(Gson()),     senders = mapOf(      // log senders and mapping      StdOutSender() to listOf(        ClickLog::class      )    ),    scheduler = IntervalSendingScheduler(5000L),    extra = LocoConfig.Extra(      sendingBulkSize = 30    )  ))[New feature] implement default sender #12デフォルトのSenderを設定できるようにしました。Senderが1つの場合はマッピング設定は不要になります。Loco.start(  LocoConfig(    store = //... ,    smasher = //... ,    senders = mapOf(),    scheduler = //... ,    extra = LocoConfig.Extra(      defaultSender = LocatSender()    )  ))今後今後はモジュール周りの追加を中心に更新していきます。RoomによるStoreとか、KoshiによるSmasherとか、ExponentialBackoffなSendingSchedulerとか、ListをJsonArrayに予め変換するSenderなどなど。こんなモジュールもほしいな〜っていうのがあればissue作ってくれると嬉しいです。Issues · sys1yagi/loco · GitHub

 loco-core 1.1.0をリリースしました。

AndroidアプリでロギングするといえばPureeかなと思います。かなり安定しているしいい感じに動く。ただコードベースがJavaなので、たま〜に不具合でた時などに追っかけるのが結構たいへんだったり、Gsonに依存しているので、別のJsonライブラリ使ってる場合ちょっとな〜ってなったりすることがあります。かねてから何らかの形で書き直しできないかな〜と思いつつ時間が取れなかったんですが、コルーチンベースでpureeやってみっか— 八木 (@sys1yagi) 2019年5月17日ということでついに手を出してみたところ、結構スッと出来上がったのでリリースします。LocoはLog Coroutineの略です。https://github.com/sys1yagi/loco構造Locoは次のような構造を持ちます。Smasher: ログをシリアライズする // ここだけ料理つながりな命名。ただ直感的ではない気がするので追々Serializerに変わるかもStore: シリアライズしたログを一旦永続化するSender: シリアライズしたログを送信するSendingScheduler: 送信間隔などを決めるそれぞれInterfaceなので好きな実装ができます。セットアップまだjcenterに公開されてない*1のでbintrayのrepositoryをrootのbuild.gradleに追加する必要があります。allprojects {  repositories {    maven { url "https://dl.bintray.com/sys1yagi/maven" }  }}あとはdependenciesに必要なものを追加するだけです。予めAndroidで使えるSmasherとStoreを用意してあります。dependencies {  // core  implementation 'com.sys1yagi.loco:loco-core:1.0.0'    // Gsonでシリアライズする。filterを追加して加工ができる    implementation 'com.sys1yagi.loco:loco-smasher-filterable-gson:1.0.0'  // SQLiteでログを保存する  implementation 'com.sys1yagi.loco:loco-store-android-sqlite:1.0.0'}この他にも便利モジュールができたら随時追加していきます。汎用性がありそうなものはPRもらえると嬉しいです。使う詳しくはsampleを見ていただきたいですが、概ね次のような感じでセットアップします。class SampleApplication : Application() {  override fun onCreate() {    Loco.start(      LocoConfig(        store = LocoAndroidSqliteStore(), // loco-store-android-sqlite        smasher = FilterableGsonSmasher(Gson()), // loco-smasher-filterable-gson        senders = NetworkSender(),         scheduler = IntervalSendingScheduler(5000L) // 5000msおきに送信する      ) {            // SenderとLocoLogをマッピングする            logToSender[NetworkSender::class] = listOf(              ClickLog::class, // LocoLogを実装したクラスたち              ScreenLog::class           )      }    )  }}// SendingSchedulerは今の所自前で用意しとく必要がありますclass IntervalSendingScheduler(val interval: Long) : SendingScheduler {  override suspend fun schedule(    latestResults: List<Pair<Sender, SendingResult>>,    config: LocoConfig,    offer: () -> Unit  ) {    delay(interval)    offer()  }}data class ClickLog(    val value: String) : LocoLogdata class ScreenLog(    val screenName: String) : LocoLogあとはどこからでもLogを送信できます。class MainActivity : AppCompatActivity() {  override fun onCreate(savedInstanceState: Bundle?) {    super.onCreate(savedInstanceState)    Loco.send(ScreenLog(this::class.java.simpleName))    setContentView(R.layout.activity_main)    // ...  }}終わりにまだ1.0.0で機能が不足してたり不具合あるかもしれないのでいろいろ触ってみてissue作ったりPRもらえると嬉しいです。https://github.com/sys1yagi/loco*1:申請中です

 Android向けロギングライブラリ「Loco」をリリースしました。

※こちらは古いので FlowのchannelFlowを使ってRxBindingを置き換える - visible true を参照ください。Kotlin Coroutine 1.2.xでFlowというコールドストリームをサポートするクラスや関数群が登場しました。Flow - kotlinx-coroutines-core次のような感じでめっちゃRxJavaっぽい雰囲気ですが動作の仕組みはコルーチンでやってる感じです。val f = flowOf(1, 2, 3) // Flowを固定値で作る  .map {    it * 2  }  .flowOn(Dispatchers.IO) // 実行コンテキストを設定できるrunBlocking {  f.collect { // この呼出しで初めて値が送出され始める    println(it)  }}Channelはホットストリームなので取扱いが難しい的な話本題と逸れるのであんまり語らないですが、こんな話があってFlowが登場しました。Cold flows, hot channelsproduceとかChannelだとObservable的な使い方できなかったり宣言時点で動き出すので管理大変やで〜みたいな感じですね。例えばRxTextView#textChangesと置き換えてみるFlowでRxTextView#textChangesのような機能を実装すると次のようになります。fun TextView.textChangeAsFlow() =  flowViaChannel<String?> { channel ->    channel.offer(text.toString())    val textWatcher = addTextChangedListener {      channel.offer(it?.toString())    }    channel.invokeOnClose {      removeTextChangedListener(textWatcher)    }  }flowViaChannel関数を使ってChannelを使ったFlowが作れます。次のように使います。lifecycleScope.launchWhenCreated {  binding.editNickName.textChangeAsFlow()    .map { it?.isNotEmpty() ?: false }     .collect {      binding.submitButton.isEnabled = it    }}collect関数を呼び出した時に、呼び出し元のスコープでFlowが動作し始めます*1。なので、呼び出し元のスコープがキャンセルされると、自動的にcollect関数も終了します。例ではlifecycleScopeを使っているので、onStopの時にキャンセルされます。もしFragmentで使う場合はviewLifecycleOwner.lifecycleScopeで呼び出すなどの工夫が必要そうです。Flowを1 : nにしたい時はどうするといいかな？TextViewにaddTextChangedListenerするケースだと、複数回呼び出しても問題ありませんが、setOnClickListenerなどリスナーが上書きされる性質のものを使う場合は、1 : n の関係でFlowを作りたいですね。broadcastIn関数を使ってBroadcastChannelを作ると 1 : n のFlowが作れます。lifecycleScope.launchWhenCreated {  val textChange = binding.editNickName    .textChangeAsFlow()    .broadcastIn(this)    .asFlow()  // ... 省略}broadcastIn関数は引数にCoroutineScopeを必要とします。BroadcastChannelを作った時点でhot streamになるので、スコープに所属させていないとリークしてしまうからです。broadcastIn関数を呼び出したあとasFlow関数で改めてFlowに変換しています。これでbroadcastIn関数の手前部分がhotになり、それ以降はcoldになります。使い方は次のようになります。lifecycleScope.launchWhenCreated {  val textChange = editNickName    .textChangeAsFlow()    .broadcastIn(this)    .asFlow()  launch {    textChange      .map { it?.isNotEmpty() ?: false }      .collect {        sendButton.isEnabled = it      }  }  launch {    textChange      .map { 140 - (it?.length ?: 0) }      .collect { remain ->        editNickNameLimit.text = "remain: $remain"      }  }}よさそう。おわりにFlow便利そうですね。RxBindingの機能は多岐に渡るので、今回のお試しだけで全部置き換えられるかっていうとわからないですが、概ねいけるんじゃないかなーと思います。ところでFlowはまだpreviewなのでプロダクトへの投入は推奨されていません。とはいえ大体うまく動くのでまぁちょっとくらいならいいんじゃないかなと思ったりしますが、Structured Concurrencyの時のようにめちゃくちゃ変わる可能性もあるんでほどほどにしましょう。*1:https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/common/src/flow/Builders.kt#L50

 FlowのflowViaChannelを使ってRxBindingを置き換える

IntelliJからdocker上で動いてるSpring Bootアプリにデバッガつなぎたいときってありますよね。ﾄﾞﾁｬｸｿハマったのでメモします。Dockerで動かすSpring Bootアプリでデバッグ用ソケットを起動するgradleを使っている前提です。gradleでSpring Bootを起動するタスクはbootRunです。これに--debug-jvmオプションを付与すると、5005番でデバッグを受け付けてくれます。docker-composeの設定イメージは次です。version: '3'services:  app:    image: openjdk:8    container_name: TodoList    ports:      - 8080:8080      - 5005:5005 # デバッグ用ポートも開けてあげる    command: ./gradlew app:bootRun --debug-jvm # このオプションをつけるこれでdocker-compse upするとサーバ起動前に5005番で待ち受けてくれます。IntelliJのRemote Configurationで5005番に接続するEdit ConfigurationでRemote Configurationを追加する。デフォルトで5005番なのでそのままでOKあとはつなぐだけやったね。handshake failed - connection prematurally closedが出る時はlocalだとつながるのにDocker経由だとこんなエラーでてつながらない現象に苦しみました。Error running 'debug': Unable to open debugger port (localhost:5005): java.io.IOException "handshake failed - connection prematurally closed"原因はいろいろあるみたいですが、とりあえず自分の環境で起きた原因は、IntelliJの動作で使っているJVMと、Docker上で動いているJVMのバージョンが異なるからでした。docker-composeで利用するimageをopenjdk:10からopenjdk:8にしたら繋げられました。やったね。おわりに毎回5005番を待ち受けるのでsuspend=nみたいなオプション渡せるといいんだけどよくわからない。