retheviper

現代のプログラミング環境は、Go や Rust などの軽量ランタイムが受け入れられる中、「JVM の方向性」に疑問を持つ声も聞かれるようになってきました。私自身もそうで、特にクラウド環境では、JVM の起動時間やメモリ使用量が問題となるケースも少なくないです。なのでサーバレス環境の場合、純粋に起動時間のためPythonやNode.jsを選ぶこともあります。しかし JVM は、現在も新技術によって性能改善の余地を持ち続けています。この記事では、Leyden や Loom を始めとした現在進行中の主要プロジェクトを概覧し、JVM の「性能」は未来にわたってどれだけ改善可能かを検討します。JIT から AOT + PGO へJIT (Just-In-Time Compiler)は、バイトコードを実行時にネイティブコードへコンパイルする技術です。最適化コードをランタイムで生成できる依存性が高い一方、warm-up期間1や"jitter2による性能不定は無視できません。これらを解決するために考案されたのがGraal で、 C2 の代替として設計された高性能 JIT コンパイラです。inlining, escape analysis, vectorization などで事前に最適化を行い、JIT の不安定性を削減します。例えばTwitterの事例 では Graal JIT を通じて CPU 利用率を8〜11%削減し、Kotlinのマイクロベンチマークでは +18%の性能向上 を報告しています。Leyden で起動の早さと安定性を両立Project Leyden は、JVM アプリケーションの起動時間と warm-up 時間を根本的に短縮することを目標にしています。従来の JIT ベースの最適化は、ランタイムの初期段階でプロファイル情報を集めながら段階的に性能を引き上げていく「適応的」最適化方式ですが、Leyden はそれを「事前確定的」（static）な最適化に置き換える方向性をとります。このために Leyden は、以下の要素をアーカイブとして事前に保存する「condensers」という概念を導入しています。この condensers は、以下の情報を含むアーカイブです。使用クラスのリストと linking 情報ヒープの初期状態（AppCDS + heap snapshot）プロファイル情報（PGO）コンパイル済みコードこれにより、アプリケーションの起動直後から JIT 後のような性能を発揮し、jitter を最小限に抑えることが期待されます。たとえば Quarkus チームは Leyden の初期実装に基づき、以下のような改善を報告しています。起動時間を 50% 以上短縮Native Image に近い応答速度を実現しつつ JVM の柔軟性は保持メモリ使用量を最大 30% 削減Leyden の関連 JEP には、JEP 483（class loading/linking の事前保存）、JEP 515（PGO support）などがあり、JDK 25 以降で順次取り込まれる予定です。ZGC, Shenandoah, そして LXRGCは JVM の性能に大きく影響する要素です。近年導入したZGC や Shenandoah GC は「pause-less GC」を目指し、ZGC は広大なヒープを持つ JVM でも少なくとも <1ms の GC ポーズを実現しています。最新の LXR GC（研究段階）は、ZGC より九分すぐれた性能を見せ、tail latency を30倍減少、throughput を6倍向上という報告も出ています。Cassandra ベンチマークでは Shenandoah が p99 レイテンシを77%減らすなど、リアルなサービスへの影響も証明されています。これらは、小型のサービスから広大な JVM グラフまで、性能の jitter を削減しながら throughput を保てるっという為に大きな意味を持ちます。Valhalla の支援するメモリー効率Project Valhalla は「value class」を JVM に実装することで、ヒープのオブジェクト依存を解消し、キャッシュローカリティを向上させます。通常のオブジェクトはヒープ内の分散やヘッダーを持ち、GC やキャッシュミスに負担をかけますが、value class はプリミティブな構造体のように inlined されるため、メモリーバンドを向上させます。特に Kotlin の data class は Valhalla から大きな影響を受け、変数配列やベクタ計算のような性能パスでは 数倍の向上 も期待できます。Loom でスケーラブルな I/O 並行性の実現Project Loom は仮想スレッドによって、従来のブロッキングな I/O コードをそのまま保ちながら、大量の同時接続を処理できるようにする試みです。ここで重要なのが、既存の並行処理との関係です。従来の Java（および Spring MVC）は、リクエストごとに OS スレッドを1本消費するアーキテクチャでした。しかしこれは、同時接続数が多くなるとすぐにスレッド枯渇やコンテキストスイッチによる性能低下を招きます。この問題を解決するために導入されたのが Spring WebFlux です。WebFlux は Reactor に基づくノンブロッキング非同期モデルで、少数のスレッドで大量のリクエストを捌くことを可能にしました。ただしその代償として、開発者は Mono や Flux を理解し、非同期パイプラインの構築を強いられ、デバッグも難しくなるという課題がありました。幸 Kotlin では suspend 関数を使うことで非同期処理を簡潔に書けますが、Java では依然として複雑なコードが必要でしたね。ここで登場する Loom の仮想スレッドは、WebFlux 並のスケーラビリティを持ちながらも、従来通りの「同期的なコード」で記述できるという点で画期的です。コード自体も、既存のスレッドベースのコードとほぼ同じままです。Java 21 で仮想スレッドが正式に導入され、Spring MVC の VirtualThreadTaskExecutor などがその代表例です。従来の Servlet ベースの構成に最小限の変更で仮想スレッドを導入可能であり、WebFlux よりも低レイテンシかつ高スループットを実現できます。Netty や Tomcat など、一部のアプリケーションサーバも Loom 対応を進めており、今後は仮想スレッドが標準的な選択肢となっていくのではと思います。まとめ以下に、この記事で紹介した JVM の主要な改善点をまとめます。Graal や Leyden により JIT 不安定性や warm-up 時間を削減ZGC, Shenandoah, LXR GC により低レイテンシなヒープでの GC を実現Valhalla によるメモリ実行効率向上Loom による I/O スケーラビリティの高効化最後にJVM は長い歴史を持つ一方で、近年はその限界も語られがちでした。でも、ここで紹介した Leyden や Loom のようなプロジェクトは、Java の価値を単なる互換性だけでなく「今のニーズに応える性能基盤」として再構築しようとしています。特に Kotlin や Scala など、Java 以外の言語でもこのような JVM の改善を活用できるので、これからの進化にも期待が持てますね。まだまだアプリケーション開発のパラダイムや性能基盤は変わり続けていくもので、これからの先はまたどうなるかわかりませんが、このような技術革新が続くといいですね。では、また！JITが最適化を行うために必要な初期段階のこと ↩︎実行時間のばらつきのこと ↩︎

JVM はまだ進化する

KotlinはJavaとの互換性があるので、Javaで構築した既存のシステムの一部を書き換えたり、言語だけを変えて新しいシステムを構築したりするケースが多いかなと思います。しかし、同じJVM上で動作するKotlinとJavaでも、フレームワークやライブラリの違いにより改善できる箇所もあります。Javaの歴史が長いこともあり、Javaのフレームワークやライブラリは非常に多くの機能を提供していますが、Kotlinではより簡潔で直感的なコードを書くことができる場合があります。また、その中ではKotlinの特性を活かした設計が可能だったり、性能の向上が期待できたりします。今回はそのような改善の一例として、Ktorでのリクエストバリデーションの実装方法について紹介します。既存実務ではKtor、ExposedといったKotlin用のフレームワークを採用しています。ただ一部ではJavaのライブラリに依存していて、直列化ではJackson、リクエストのバリデーションではjakarta.validationを使用していました。JavaやKotlinでよく使われるSpring Bootの場合、これらのライブラリを使うのがとても簡単ですね。例えば、リクエストのバリデーションは@Validや@Validatedアノテーションで自動的に行うことができます。しかし、Ktorではそうでもいきません。なので、Ktorのリクエストバリデーションは、手動で行う必要がありました。例えば、以下のようにしていました。// リクエストのバリデーションを行うobject AnnotationValidator { private val validator: Validator = Validation.buildDefaultValidatorFactory().validator fun getViolationMessages(model: Any?): List<String> { model ?: return emptyList() val violations = validator.validate(model) return violations.map { "${it.propertyPath} ${it.message}" } }}// バリデーションを行うインターフェースinterface Validatable( fun validate(): List<String>)// リクエストボディdata class CreateLogRequest( @field:NotNull @field:NotBlank @field:Size(max = 36) @field:Pattern(regexp = "^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-5][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$") @JsonProperty("user_id") val userId: String?, @field:NotNull @field:NotBlank @field:Size(max = 2048) @JsonProperty("referral") val referral: String?, @field:NotNull @field:NotBlank @field:Size(max = 2048) @JsonProperty("user_agent") val userAgent: String?) : Validatable { override fun validate(): List<String> { return AnnotationValidator.getViolationMessages(this) }}// コントローラーclass LogController : KoinComponent { private val logUseCase: sLogUseCase by inject() fun createLog(request: CreateLogRequest): CreateLogResponse { val validationErrors = request.validate() if (validationErrors.isNotEmpty()) { throw BadRequestException("Validation failed: ${validationErrors.joinToString(", ")}") } return logUseCase.createLog(request) }}ここで自分が問題と思ったのは、以下のようなものがあります。リクエストのバリデーションを手動で行う必要があるため、コードが冗長になりやすい。各コントローラーやリクエストに対して同じようなバリデーションコードを書く必要があるため、コードの重複が発生しやすい。バリデーションと直列化でアノテーションに依存しているため、リフレクションによるパフォーマンスの低下や、アノテーションの変更が必要な場合にコードの修正が必要になる。プロパティの型をアノテーションで指定するため、型安全なコードが書きにくい。なので、これらの問題を解決するために、Ktorのリクエストバリデーションを改善する方法を考えました。改善自分で考えた改善策は以下のようなものです。Ktor公式のRequest Validationを使用して、アノテーションに依存しないバリデーションを実装する。バリデーションのロジックを共通化できるようにする。JacksonからKotlinx Serializationに移行して、アノテーションをさらに減らしつつとパフォーマンスを向上させる。それぞれ分けると以下のような内容になります。KtorのRequest Validationを使用するまずはValidatableControllerというインターフェースを作成して、それぞれのコントローラーで実装します。このインターフェースは、KtorのRequest Validationを使用してリクエストのバリデーションを行うためのもので、Ktorのプラグインに登録するためのメソッドを持っています。interface ValidatableController { fun configureValidation(validationConfig: RequestValidationConfig)}そして、data classを修正します。jakarta.validationのアノテーションは削除し、Validatableというインターフェースも削除します。data class CreateLogRequest( @JsonProperty("user_id") val userId: String?, @JsonProperty("referral") val referral: String?, @JsonProperty("user_agent") val userAgent: String?)次に、コントローラーを修正します。ValidatableControllerを継承させ、バリデーションのロジックをconfigureValidationメソッドに移動し、KtorのRequest Validationを使用してリクエストのバリデーションを行います。class LogController : KoinComponent, ValidatableController { private val logUseCase: LogUseCase by inject() override fun configureValidation(validationConfig: RequestValidationConfig) { validationConfig.validate<CreateLogRequest> { request -> when { request.userId == null -> ValidationResult.Invalid("User ID must not be null") request.userId.isBlank() -> ValidationResult.Invalid("User ID must not be blank") request.userId.length > 36 -> ValidationResult.Invalid("User ID must not exceed 36 characters") !request.userId.matches(Regex("^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-5][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$")) -> ValidationResult.Invalid("User ID must be a valid UUID format") request.referral == null -> ValidationResult.Invalid("Referral must not be null") request.referral.isBlank() -> ValidationResult.Invalid("Referral must not be blank") request.referral.length > 2048 -> ValidationResult.Invalid("Referral must not exceed 2048 characters") request.userAgent == null -> ValidationResult.Invalid("User Agent must not be null") request.userAgent.isBlank() -> ValidationResult.Invalid("User Agent must not be blank") request.userAgent.length > 2048 -> ValidationResult.Invalid("User Agent must not exceed 2048 characters") else -> ValidationResult.Valid } } } fun createLog(request: CreateLogRequest): CreateLogResponse { return logUseCase.createLog(request) }}このようにすることで、KtorのRequest Validationを使用してリクエストのバリデーションを行うことができます。これにより、アノテーションに依存せず、コードの冗長性を減らすことができます。モジュールの設定次は、ValidationControllerをKtorのモジュールとして設定します。インターフェースとしてValidatableControllerを定義した理由は、DIで使用しているKoinを使用して、すべてのコントローラーを取得し、KtorのRequest Validationに登録するためです。まずKoinではinterfaceに対して実装クラスをバインディングするいくつかの方法があります。代表的には、以下のような方法があるでしょう。val koinModule = module { single<ValidatableController> { AccessLogController() }}この方法では、ValidatableControllerインターフェースを実装したクラスを単一のインスタンスとして登録します。しかし、これでは複数のValidatableControllerを登録することができません。この場合、get()を使用して、1つのValidatableControllerのみを取得することはできます。しかしここでやりたいことは、複数のValidatableControllerを取得して、リクエストのバリデーションを共通化することなのでこの方法は適していません。またの方法が、bindを使用する方法です。val koinModule = module { single { LogController() } bind ValidatableController::class single { AnotherController() } bind ValidatableController::class}先ほどのコードとは違って、bindを使用することで、Koinはそのインターフェースを実装したすべてのクラスを取得できるようになります。なので、以下のようなコードで全てのコントローラーを取得することができます。fun Application.configureRequestValidation() { val validatableControllers: List<ValidatableController> = getKoin().getAll() install(RequestValidation) { validatableControllers.forEach { controller -> controller.configureValidation(this) } }}こうすることでリクエストのバリデーションを共通化することができます。これからは新しいコントローラーを追加する際も、ValidatableControllerインターフェースを実装するだけで、KtorのRequest Validationに自動的に登録されるようになります。Kotlinx Serializationの使用最後に、Kotlinx Serializationを使用して直列化を行います。これにより、アノテーションの使用を減らし、パフォーマンスを向上させることができます。Kotlinx Serializationは、KSP（Kotlin Symbol Processing）を使用して、コンパイル時に直列化のコードを生成します。これにより、リフレクションを使用せずに直列化を行うことができ、パフォーマンスの向上が期待できまし、リクエストのバリデーションでも型安全なコードを書くことができるため、コードの可読性も向上します。まず、Kotlinx Serializationを使用するために、既存のJacksonからKotlinx Serializationに移行します。以下のように、ContentNegotiationプラグインを使用してシリアライザを設定します。プロパティの命名規則をスネークケースに変更するために、JsonNamingStrategy.SnakeCaseを使用することができます。fun Application.configureContentNegotiation() { install(ContentNegotiation) { json( Json { namingStrategy = JsonNamingStrategy.SnakeCase } ) }}次に、リクエストボディのデータクラスに@Serializableアノテーションを追加します。Kotlinx Serializationでは@Serializableだけでスネークケースへの変換も可能となり、プロパティ名にアノテーションが不要になります。また、プロパティはそのまま型を指定するだけです。型を指定することでNullチェックも自動になります。@Serializabledata class CreateLogRequest( val userId: UUID, val referral: String, val userAgent: String)次に、コントローラのバリデーションを修正します。userIdの型がStringからUUIDに変更されたので、正規表現のチェックは不要になりました。かなりスッキリしましたね。class LogController : KoinComponent, ValidatableController { private val logUseCase: LogUseCase by inject() override fun configureValidation(validationConfig: RequestValidationConfig) { validationConfig.validate<CreateLogRequest> { request -> when { request.referral.isBlank() -> ValidationResult.Invalid("Referral must not be blank") request.referral.length > 2048 -> ValidationResult.Invalid("Referral must not exceed 2048 characters") request.userAgent.isBlank() -> ValidationResult.Invalid("User Agent must not be blank") request.userAgent.length > 2048 -> ValidationResult.Invalid("User Agent must not exceed 2048 characters") else -> ValidationResult.Valid } } }}評価結論的に以下のような改善ができたと思います。バリデーションと直列化のコードが簡潔になり、可読性が向上したバリデーションと直列化でアノテーションを使用しなくなり、リフレクションによるパフォーマンスの低下を回避できたバリデーションに対してビジネスロジック以外のチェックを減らすことができたまた、サイドエフェクトとして以下のような点もあります。Regexが不要になっているか、共通化してインスタンスの使い回しができるmax, minなどのチェックが不要になっているlimit, offsetなど頻繁に使うパラメータのチェックを共通化できるただ、以下のような懸念もあります。LocalDateTimeやLocalDateなどのKotlinx Serializationでサポートされていない型を使用する場合、独自のシリアライザを実装する必要がある// LocalDateTimeのシリアライザの例object LocalDateTimeSerializer : KSerializer<LocalDateTime> { override val descriptor: SerialDescriptor = PrimitiveSerialDescriptor("java.time.LocalDateTime", PrimitiveKind.STRING) override fun serialize(encoder: Encoder, value: LocalDateTime) { encoder.encodeString(value.format(DateTimeFormatter.ISO_LOCAL_DATE_TIME)) } override fun deserialize(decoder: Decoder): LocalDateTime { return LocalDateTime.parse(decoder.decodeString(), DateTimeFormatter.ISO_LOCAL_DATE_TIME) }}fun Application.configureSerialization() { install(ContentNegotiation) { json( Json { // LocalDateTimeのシリアライザを登録 serializersModule = SerializersModule { contextual(LocalDateTimeSerializer) } } ) }}@Serializabledata class ExampleRequest( // LocalDateTimeのフィールドでは、独自のシリアライザを使用する @Contextual val timestamp: LocalDateTime)Enumのようにコンパイル時に値が決まっている型を使用する場合も、独自のシリアライザを実装する必要があるKotlinx SerializationはまだJacksonほどの機能がないため、特定の機能が必要な場合はKotlinx Serializationでは実装できないことがあるKtor Request Validationはリクエストボディのみのバリデーションをサポートしているため、クエリパラメータやヘッダのバリデーションは別途実装する必要があるなので、今回の対応は意図としては成功したと思いますが、まだまだ改善の余地はあるかなと思います。また、環境や要件によっては、このような改善が適さない場合もあるかもしれません。改善内容のまとめ以下の表に、改善前後の違いを簡潔にまとめました。項目改善前改善後バリデーションの方法jakarta.validation + 手動呼び出しKtor公式のRequestValidationプラグインアノテーションの使用@NotNull, @Pattern, @JsonPropertyなど多数@Serializableのみ、基本的に不要UUIDバリデーション正規表現でチェックUUID型指定で型安全に直列化ライブラリJackson（リフレクションを使う）kotlinx.serialization（KSP利用で高速）バリデーションの共通化各コントローラーで個別に記述ValidatableControllerで共通定義可能Koinとの連携取得や登録が煩雑もしくはしないbind + getAll() で一括取得最後に今回はKtorのRequest処理を改善する方法について紹介しました。Kotlinの特性を活かし、KtorのRequest Validationを使用することで、リクエストのバリデーションを簡潔に行うことができました。また、Kotlinx Serializationを使用することで、直列化のパフォーマンスも向上させることができました。このように、KotlinとKtorを使用することで、Javaのフレームワークやライブラリでは実現できないような改善が可能になることがあります。特に、Kotlinの特性を活かした設計や、パフォーマンスの向上が期待できる点は大きなメリットです。今後もKotlinやKtorを使った開発において、より良い設計やパフォーマンスの向上を目指していきたいと思います。もし、他にもKtorやKotlinに関する改善点やアイデアがあれば、また共有していきたいと思います。では、また！

KtorのRequest処理を改善する

この度は、ホームサーバを作りました。まだ作ったばかりなので、色々と改善や課題があるかと思いますが、一通りの構成を整えたので、その構成について簡単に説明します。なぜ自作サーバを作るのか最近は無料で使えるクラウドのサービスも多く、FirebaseやVercelなどのサービスを使えば、簡単にWebアプリケーションを公開することができます。なので既存のサービスを利用するだけで良いのでは？ということは自分でも考えたことはありますが、そこであえて自作サーバを作ることになった理由について簡単に説明します。性能多くのクラウドで提供するVMやサーバレスのサービスは、CPUやメモリ、ストレージなどに制限があることが多いです。また、AWSやGCPといったサービスの場合、使われているCPUのアーキテクチャがBroadwellのような、かなり旧時代のものが使われていることが多いですね。それに比べ、今回自作サーバの構築に使ったマシンはM2 ProのMac miniなので、IPCで比べるとより高い性能を期待できます。メモリも同じく、32GBのメモリを搭載しているので、メモリの制約もないですね。費用無料のサービスだと基本的に費用はかからなくても、セキュリティのためのWAFのような追加の機能を追加したり、データベースを使ったりすると、結局はお金がかかることが多いです。そして使用量が多くなるとあまり費用が安いわけでもないですね。当分は趣味や個人的に使うための機能のためだけに使いたいので、少しでも支出を減らしたいと思いました。自作サーバだと電気代がかかることはありますが、Mac miniの場合は消費電力が少ないので、それほど気にならなく、使っていない時はスリープにしておけば電気代も抑えられると思います。機能サーバレスやVMの場合、場合によっては対応するランタイムが決まっていたり、DBの選択肢が限られていたりすることがあります。例えば、今もOracle Cloudの無料のインスタンスを利用中ですが、無料の場合PostgreSQLを利用できないのでVMの中にDBを起動する形となっています。このように既存のプラットフォームを使うと自分が使いたい機能よりも、サービスの提供する機能に合わせる必要があることがありますね。今回は特にそういった制約を受けずに、自分が使いたい技術を使って自由にサービスを構築したいと思いました。その他他にも色々な理由を書きましたが、最も大きな理由は2台のMacを使っているところで、余っているリソースを活用したいと思ったところですね。移動がある時はMacBook Proを使っていて、常に使っているのはMac miniなのでサーバとして運用して、外からもアクセスできるようにしたいと思いました。インフラ構成インフラの場合、まず全体を図で表すと以下のようになります。ONU自宅では、NURO光を利用しているので、そもそもネットの接続のためにはONUが必要ですね。ONUはOptical Network Unitの略で、光回線を利用してインターネットに接続するための装置です。基本的なルータとしての機能も揃っているものです。私の場合ONUとは別にWi-Fiルータを使っているので、ONUの設定としてはフォートフォワードだけを設定しておきました。TCPの80番ポートと443番ポートをフォートフォワードしておけば、外部からONUの後ろにアクセスが可能になります。ルータ次はルータです。先に説明した通り、ONUにはルータとしての機能も揃っているのであえて使う必要はないものですが、ルータが提供している無料のDDNSの機能を使うために、ルータを使っています。ONUだけではIPが固定されていないので、ルータのDDNSを使い、さらにそれを購入したドメインに紐付けることで、常に同じドメインでアクセスできるようになります。固定のドメインがあるので、SSL証明書も取得しやすくなりますね。ここでも80番ポートと443番ポートをフォートフォワードしておきます。サーバサーバは、上述したMac miniを使っています。中ではDockerコンテナとしてビルドしたNginxとKtorのアプリケーションが動いています。Nginxはリバースプロキシとして動いており、Ktorのアプリケーションにリクエストを転送しています。Ktorアプリケーションでは静的ファイルの配信ができるので、Compose Web(WASM)で作成したWebアプリケーションを配信しています。DockerでNginxとKtorは同じネットワークとして構成しているので、NginxからKtorにアクセスする際は、コンテナ名でアクセスできます。Nginxが80番ポートと443番ポートからのリクエストを受けて、Ktorのアプリケーションに転送しています。そしてCertbotを使ってSSL証明書を取得しているので、HTTPSでアクセスできるようになっています。80番のリクエストは301リダイレクトで443番にリダイレクトです。これらの構成は、以下のようにDocker Composeで定義しています。services: nginx: build: context: . dockerfile: Dockerfile_nginx container_name: nginx ports: - "80:80" - "443:443" volumes: - certs:/etc/letsencrypt - certs-data:/var/www/certbot networks: - home_network certbot: image: certbot/certbot container_name: certbot volumes: - certs:/etc/letsencrypt - certs-data:/var/www/certbot networks: - home_network app: build: context: . dockerfile: Dockerfile image: app:latest container_name: app ports: - "8888:8888" networks: - home_network depends_on: - nginxnetworks: home_network: driver: bridgevolumes: certs: certs-data:また、不正アクセスを防ぐためにNginxは以下のようなDockerfileでビルドしています。# ベースイメージとして最新の Nginx を使用FROM nginx:latest# 必要なパッケージをインストール（git, wget, dnsutils）RUN apt-get update && apt-get install -y \ git \ dnsutils \ wget \ && rm -rf /var/lib/apt/lists/*# Nginx Ultimate Bad Bot Blocker のリポジトリをクローンRUN git clone https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker.git /opt/nginx-ultimate-bad-bot-blocker# 必要なディレクトリを作成し、bot 設定ファイルをコピーRUN mkdir -p /etc/nginx/bots.d /usr/local/sbin \ && cp /opt/nginx-ultimate-bad-bot-blocker/bots.d/* /etc/nginx/bots.d/ \ && cp /opt/nginx-ultimate-bad-bot-blocker/conf.d/globalblacklist.conf /etc/nginx/conf.d/# install-ngxblocker スクリプトのダウンロードと実行RUN wget https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/install-ngxblocker -O /usr/local/sbin/install-ngxblocker \ && chmod +x /usr/local/sbin/install-ngxblocker \ && /usr/local/sbin/install-ngxblocker -x# setup-ngxblocker スクリプトのダウンロードと実行RUN wget https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/setup-ngxblocker -O /usr/local/sbin/setup-ngxblocker \ && chmod +x /usr/local/sbin/setup-ngxblocker \ && /usr/local/sbin/setup-ngxblocker -x# Nginx のカスタム設定ファイルを追加（nginx.conf や default.conf を追加する）COPY ./nginx/nginx.conf /etc/nginx/nginx.confCOPY ./nginx/default.conf /etc/nginx/conf.d/default.conf# 証明書のためのボリューム（Let's Encrypt を使用する場合）VOLUME ["/etc/letsencrypt", "/var/www/certbot"]# Nginx 設定をテストして起動CMD ["nginx", "-g", "daemon off;"]課題概ねインフラの構成には問題がないですが、アプリケーションの部分にはいくつか課題を感じました。主にFrontendで使っているCompose Web(Wasm)のことです。Routing未対応Wasmで作成したアプリケーションの特徴なのかもしれませんが、基本的にSPAのような静的コンテンツを生成するのもあり、まだAlphaのため色々と未対応の部分があります。特にRoutingが未対応なので、ページ遷移が課題ですね。まだ公式はないのですが、直近でCompose Wasmに対応するRoutingのライブラリがリリースされたり、他にもいくつかあるので今回はそれを使ってみようと思います。Safari 未対応Wasmの場合、ブラウザによっては動作しないことがあります。Compose Webの場合、Safariでは動作しないことがわかっているので、Safariでの動作を考える必要があります。理由はGCにまだ未対応だからとのことですね。Macを使う場合でもSafariを使っているユーザは少ないと思いますが、iOSの場合はSafariを使うユーザが多いので、これはなかなか大きな課題ですね。ただ、SafariでももうすぐWasmGCに対応するとのことなので、それまで待つしかないですね。CJK未対応いわゆる日本語や中国語、韓国語などの文字が未対応です。Compose Webの場合、まだCJKの文字が未対応のようで、日本語を入力すると文字化けしてしまいます。これはおそらくフォントないしはレンダリングの問題のようで、こちらのやりとりを見ると最新のComposeのバージョンで一部を解消したようですが、Koltinのバージョンによっては使えなかったりするのでまだ色々と調整が必要そうです。最後に今回は主にインフラの構成の話になりましたが、Composeを使ってKotlinだけで完結するようなアプリケーションを作るのも目的の一つだったので、もしできれば今後はComposeを使ったアプリケーションの開発についても書いていけたらと思います。Compose Webの場合はJSの時代から少し触っていたものの、最近はWasmの方に力を入れてきたのもあって、まだまだ未対応の部分が多いですが、これからの発展が楽しみですね。個人的には、commonパッケージを通じてサーバとクライアントのコードを共有できるのが一番の魅力だと思っているので、色々とアーキテクチャなどを考えながら開発していきたいと思います。それでは、また！

ホームサーバを作ってみた

今年のKotlinConfが開催されました。数日かけてのイベントなので、全てのセッションを見ることはできませんが、まずはキーノートの方で重要な情報をまとめてみました。全体のスケージュールはこちらから確認できて、YouTubeでのライブ配信も行われているので、興味がある方はぜひチェックしてみてください。まずはKotlinConf'24の公式アプリの紹介がありました。公式アプリでは今回行われるカンファレンスとセッションを確認できるもので、GitHubにてソースコードを公開しています。Kotlin Multiplatformで作成されていて、iOS、Android、Webで動作するものなので、いいサンプルとして使えるかもしれません。Kotlinの今まずはKotlinの現状から。常にKotlinを使っているエンジニアの数が、200万以上になっているとのことです。また、Kotlinを導入している企業もどんどん増えているとのことです。代表的な企業は以下の画像通りだそうです。Kotlin 2.0 and K2 CompilerKotlin 2.0からはK2コンパイラーの導入により、全般的にコンパイルの速度が向上したという話が主なテーマです。ただ一部プロジェクトでは、遅くなるケースもあるとのことでした。また、IntellijでもK2コンパイラーモードがあり、コードハイライトが1.8倍速くなるとのことです。K2モードは、Intellij 2024.1以上から以下の設定画面で設定できます。2024.2からは性能の改善を含め、Beta版として提供される予定です。2.0へのマイグレーションは1000万行のコード、18000人のエンジニア、80000のプロジェクトでテストされていて、1.9からのマイグレーションはスムーズに行えるとのことです。Metaの場合Metaの場合、Kotlin firstでの開発を積極的に進めているとのことでした。IDEからコードの最適化までの全てにおいてKotlinを採用して、既存のJavaで作成されたFacebook, Instagram, Facebook Messenger, WhatsAppなどのアプリにおいて、Kotlinに自動変換できるツールを作成して移行を自動化しているとのことです。そしてMetaはKotlin 1.8の時点から一部のプロジェクトにおいてすでにK2コンパイラーを採用していて、今は95%のプロジェクトがK2コンパイラーを使っているとのことです。その効果としてはAndroidプロジェクトにおいては最大20%のビルド時間の短縮ができたらしいです。Googleの場合K2コンパイラーにはGoogle側も協力していて、Androidのツーリングに関してLintやParcelize、KSPなどにもコントリビュートしているそうです。また、Jetpack Composeのコンパイラーの改善もあり、従来はKotlinとバージョンと相違があったのですが、2.0からは同じバージョンで指定できるようになったとのことです。またAndroid StudioでもKotlin 2.0のサポートを予定しているとのことでした。代表的な機能は以下の画像の通りです。Jetpack Composeにおいても新しい機能を追加される予定だそうです。主に以下の画像で挙げている機能が、7月から提供される予定だそうです。コンパイラーそのものの改善もあり、安定性やパフォーマンスが向上しているとのことです。他にも、Google内部ではサーバサイドKotlinの採用も進んでいたり、KMPによる開発も進んでいるとのことでした。あとはJetpack ComposeのライブラリもMultiplatformに対応していて、ViewModelやRoomなどのライブラリもKotlin Multiplatformで使えるようになったとのことです。Kotlin MultiplatformK2コンパイラーの導入により、Kotlinのコードを直接Swiftのコードに変換することができるようになったとのことです。これにより、iOSアプリの開発においてもKotlin Multiplatformを使って開発することができるようになりました。そしてFleetで、iOSアプリも開発できるという紹介もありました。FleetだとCompose MultiplatformによるiOSとAndroidのアプリ開発が同時に可能で、リファクタからデバッグまで一貫して開発できるとのことです。AppCodeのサポートが2023年に終了となっていたので、これは嬉しいニュースですね。また、新しいビルドツールであるAmperも紹介されました。まだ発表されてから間もないのですが、すでにJetBrainsのIDEでサポートされていて、YAMLファイルだけでビルド設定を行うことができるので、新しいプロジェクトで使ってみるのもいいかもしれません。Compose Multiplatformにおいても、以下の新しい機能が追加されたらしいです。どれも期待していた機能だったので、嬉しいですね。個人的にはデスクトップアプリでファイルの選択ダイアログを実装した時に、対応する機能がなくJavaのAWTを使わざるを得なかったので、このようなAPIもあるといいなと思っています。Upcoming次に、Kotlin 2.1のベータ版から導入予定の機能について紹介や、新しいライブラリ、AIモデルの発表がありました。以下の画像の通りです。Guardwhenの分岐で、変数の重複を防ぐための機能です。既存のコードなら、以下のようなコードでstatusが重複する場合があっても、どうしようもなかったですね。fun render(status: Status): String = when { status == Status.Loading -> "Loading" status is Status.OK && status.data.isEmpty() -> "No data" status is Status.OK -> status.data.joinToString() status is Status.Error && status.isCritical -> "Critical problem" else -> "Unknown problem" }なぜなら、以下のようにコードを変えた場合にandでコンパイルエラーが発生してしまうからです。fun render(status: Status): String = when (status) { Status.Loading -> "Loading" is Status.OK && status.data.isEmpty() -> "No data" // Error: expecting '->' is Status.OK -> status.data.joinToString() is Status.Error && status.isCritical -> "Critical problem" // Error: expecting '->' else -> "Unknown problem" }これを改善するため、以下のようにGuarded Conditionを導入する予定だそうです。$-escaping problemKotlinで$は、文字列の中で変数を埋め込むために使われています。ということは、$を文字列として使いたい場合にエスケープの問題が発生するとのことでもあります。特にMulti-line Stringがそうですね。例えば、以下の例があります。val jsonSchema: String = """ "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://example.com/product.schema.json", "$dynamicAnchor": "meta", "title": "Product", "type": "object"}"""ここでschemaやidなどは変数ではなく、文字列として使いたい場合がありますが、Multi-line Stringの場合にはエスケープができません。なので、以下のようなコードになるケースもありました。val jsonSchema: String = """ "${'$'}schema": "https://json-schema.org/draft/2020-12/schema", "${'$'}id": "https://example.com/product.schema.json", "${'$'}dynamicAnchor": "meta", "title": "Product", "type": "object"}"""これを解決するために、文字列リテラルで$を2回入れることでinterpolationできるようにする、という機能が導入される予定だそうです。Non-local break/continue今までは、コンパイラーがLambdaが実行される場所を特定できないため、breakやcontinueが使えなかったです。なので、以下のようなコードはエラーになってしまいます。for (i in 0..n) { val date = state[i]?.let { when (it) { -1 -> break // Error: 'break' is not allowed here 0 -> continue // Error: 'continue' is not allowed here else -> process(it) } }}これもまた、Kotlin 2.1からはletのようなinline関数を正しく解析できるようになるため、breakやcontinueが使えるようになるとのことです。Contexts去年発表されたContextについても発表がありました。これはすでにプレビューとして導入されていて、Kotlin 2.2からはベータ版として提供される予定だそうです。これでDIと似たようなことをしたり、セッションやトランザクションなど色々な関数で使い回す必要があるものは、関数の引数に渡すことなく、Contextを使って共有することができるようになります。Core LibrariesKotlinのコアライブラリも改善される予定だそうです。すでに発表されているkotlinx.ioのようなものだけでなく、kotlinx.rpcのような新しいライブラリの発表もありました。これらのコアライブラリは、Multiplatformでの開発をサポートするために提供されるもので、どのプラットフォームでも使えるものです。AWS SDK for KotlinKotlin用のAWS SDKも提供される予定という発表もありました。今まではJavaのSDKを使うことが多かったのですが、CoroutineやNull SafetyのようなKotlinの特徴を活かせつつ、Multiplatformで使えるSDKが提供されるとのことです。Kotlin Language ModelFleetではすでに利用可能で、Intellijでは2024.2から利用可能となるKotlinの言語モデルが開発中のことです。既存のいくつかのモデルと比べ、Kotlinに特化されたからか、比較的パラメータの数が少ないことに比べ、ベンチマークでは高い精度を示しているとのことです。ただ、比較で使っているLlamaの場合はすでにバージョン3がリリースされているので、最新のモデルと比べる場合どの程度の精度があるのかは気になるところです。最後にKotlinConf'24のキーノートでの発表内容を以上でまとめてみました。他にも多くのセッションがあ理、Kotlin 2.0もChangelogを見ると、多くの変更があるので、また色々とチェックしていきたいところですね。Composeの発展も良かったのですが、Flutterのような他のフレームワークもあるのでこれからどれだけのシェアを取れるかが楽しみです。言語としても他の言語の発展も早いので、Kotlinも引けを取らないように頑張ってほしいですね。では、また！

KotlinConf'24を要約してみた

この度は、動的画像リサイズのAPIを作りましたのでその紹介です。ここでおいう動的画像リサイズAPIとは、元の画像のURLとリサイズしたいサイズを指定すると、そのサイズにリサイズした画像を返すAPIです。目的そもそも動的画像リサイズAPIを作る理由はなにか。それから説明しないとですね。今までは画像の配信において、エンドユーザが画像をアップロードする場合、あらかじめサムネイルの画像も作成してアップロードするようにしていました。ただ、その方法だと全ての画面比と解像度に対応したサムネイルを作れないという問題があります。そのため代案として、フロントエンドから画面に最適化したサイズを指定して、APIからリサイズした画像を取得するようにしたいというのが目的です。設計・技術選定APIはマイクロサービスとして、なるべくシンプルに作ることにしました。Getのエンドポイントを一つ持っていて、そこにクエリパラメータで元の画像のURLとリサイズしたいサイズを指定すると、リサイズした画像を返すというものです。フロントエンドではそのままimgタグに使えるようにしたいので、返すのは画像のデータそのまま（ヘッダーにはContent-typeを指定）にします。また、リサイズだけでなく、画像の形式を変換することもできるようにします。また、APIはCloud Run上で動かすことにしました。既存のAPIもそうなので使い方を合わせるためでもあり、ローカルでの開発でもdocekr composeを使って楽に開発できるためです。他にもコンテンツの配信にはCloud Storageを使っているので、それとの連携もしやすいためです。そして最終的に処理された画像は、Cloud CDNに保存され、2回目以降の呼び出しではキャッシュを返すようにします。会社ではすでにウェブフレームワークとしてKtorを採用しているので、それと揃えるためにこちらもKtorを採用。Ktorの以前ににNode.jsとRustによる実装を試みたことがありますが、前者は性能の問題から、後者はメンテが難しくなる問題から（社内にRustができる人が少ないので）採用しない方になっています。当時作成していたRustバージョンに近いサンプルコードはGitHubにて公開していますので、こちらから確認できます。画像の変換とリサイズのためにはScrimageを採用することにしました。他の候補としてはJavaのImageIOなども検討しました。ただ、リサイズ対象の画像のフォーマットと、返すデータのフォーマットとしてWebPを処理する必要があったのですがそれに対応していないものが多かったです。他に考えたものとしては、GraphicsMagickのように画像の変換やリサイズを行うツールを使う方法もあります。こちらの場合はJavaから取得したデータを一度ファイルに書き出して、それをコマンドラインで実行するという方法になりますので、その分のI/Oコストがかかるため今回はScrimageを使うことにしました。リサイズ処理では、実際のAPIを書いていきます。Ktorは使い慣れているのもあり、今回はKtorでのAPI構築というよりはScrimageを使った画像のリサイズ処理が重要なので、その部分に焦点を当てていきます。API全体で処理のフローは大まかに以下の通りです。クエリパラメータからurlとリサイズ後の大きさを取得画像の取得画像のリサイズ画像の形式変換ここでScrimageを使った画像の処理は3〜4の部分ですが、実際のリサイズを行う前に取得した画像の形式をまず判定したり、画像のサイズを確認する必要もあります。理由としては処理の効率化のためですね。今回はPNG, JPEG, WEBP, GIFの4つの形式に対して、リサイズ後にWEBPに変換するという処理を行うことにしています。ここで元の画像がWEBPだった場合、あえてWEBPに変換する必要はないです。また、リサイズが必要ない場合もあります。そのため、まずは画像の形式を判定して、リサイズが必要な場合のみリサイズ処理を行うようにします。画像の形式判定URLもしくはローカルストレージ（今回はCloud RunにCloud Storageをマウントする形で使っている）から画像を取得する際、その画像の形式を判定する必要があります。Scrimageでは画像の形式を判定するためのFormatDetectorというクラスを提供しています。使い方は簡単で、以下のように読み込んだ画像のデータをByteの配列で渡すだけです。API上では想定してないフォーマットが来た場合はエラーを返すようにしていて、ここで返すFormatはPNG, GIF, JPEG, WEBPでありScrimageのものをそのまま使っています。fun detectImageFormat(data: ByteArray): Format { return FormatDetector.detect(data).orElseThrow { IllegalArgumentException("Unsupported format") }}PNG, JPEGの処理まず一番簡単なPNG, JPEGの場合です。これらの形式の場合、ScrimageのImmutableImageとして扱うことになります。ここで画像のデータをImmutableImageに変換するにはImageReaderのインタフェースを実装したクラスを使います。公式サイトではImmutableImage.loader()で形式に関係なく画像を読み込むことができると書いてありますが、実際にAPIをビルドする際はAWT関連のエラーが出るので、形式に応じて読み込むクラスを変える必要があります。fun asImmutableImage(rawData: ByteArray): ImmutableImage { return ImageIOReader().read(rawData)}ImmutableImageに変換したら、リサイズ処理を行います。Scrimageではリサイズのためのメソッドが用意されているので、それを使ってリサイズを行います。ここで注意すべきは、resize()やresizeTo()のようなメソッドがあるのですが、前者の場合はパーセントでのリサイズ、後者の場合は指定したサイズにリサイズするという違いがあります。これらの場合、元の画像のアスペクト比が保持されないため、scaleTo()やscaleToWidth()などのメソッドを使う必要があります。今回はwidthのみを指定してアスペクト比を保持したままリサイズするため、scaleToWidth()を使います。fun resizeImmutableImage(image: ImmutableImage, width: Int): ImmutableImage { return image.scaleToWidth(width)}最後に、リサイズした結果をByteArrayとして返すためのメソッドを用意します。どの形式に変換するかによってImageWriterを実装するクラスを選ぶ必要があります。今回はWEBPにしたいので、WebpWriterを使います。fun encodeImage(image: ImmutableImage): ByteArray { return image.bytes(WebpWriter.DEFAULT)}最後にRouterでは、Content-Typeを指定してByteArrayを返すようにします。call.respondBytes( bytes = resizedImage, contentType = ContentType("image", "webp"))WEBPの場合WEBPの場合は、上記データ読み込む時点でWebpImageReaderを使う必要があります。その後のリサイズ処理はPNG, JPEGの場合と同じです。ただ、形式がWEBPの場合にはscrimage-webpが提供しているWebpImageReaderを使う必要があります。なので、形式に応じて読み込むクラスを変える必要があります。先ほどのasImmutableImageの引数に形式を追加して、形式に応じて読み込むクラスを変えるようにします。fun asImmutableImage(rawData: ByteArray, format: Format): ImmutableImage { return when (format) { Format.WEBP -> WebpImageReader().read(rawData) Format.GIF, Format.PNG, Format.JPEG -> ImageIOReader().read(rawData) }}他の処理はPNG, JPEGの場合と同じです。GIFの場合GIFの場合は、AnimatedGifというクラスを使ってリサイズを行います。ImmutableImageと同じようにリサイズメソッドが用意されているので、それを使ってリサイズを行います。処理で使われるクラスが違うので、GIFの場合は別途メソッドを用意します。fun asAnimatedGif(rawData: ByteArray): AnimatedGif { return AnimatedGifReader.read(ImageSource.of(rawData))}また、AnimatedGifの場合はframesというプロパティで各フレームのデータを保持していて、これらはImmutableImageとして扱うことができます。そのため、リサイズ処理は各フレームに対して行い、それをAnimatedGifに戻すという処理を行います。若干複雑ですが、以下のように書くことができます。suspend fun resizeAnimatedGif(gif: AnimatedGif, width: Int): AnimatedGif { val resizedData = ByteArrayOutputStream().use { StreamingGifWriter().prepareStream(it, BufferedImage.TYPE_INT_ARGB).use { stream -> gif.frames.mapIndexed { index, image -> stream.writeFrame(image.scaleToWidth(width), gif.getDelay(index)) } it.toByteArray() } return AnimatedGifReader.read(ImageSource.of(resizedData))}最後に、リサイズした結果をByteArrayとして返すためのメソッドを用意します。基本的にはImmutableImageと同じですが、GIFをWEBPに変換する場合はGif2WebpWriterを使います。これでWEBPに変換後も、GIFのアニメーションが保持されたままリサイズすることができます。fun encodeGif(gif: AnimatedGif): ByteArray { return gif.bytes(Gif2WebpWriter.DEFAULT)}処理を共通化するここまででPNG, JPEG, WEBP, GIFの4つの形式に対してリサイズ処理を行うことができました。ただ、それぞれの形式に対して処理を書いていると、処理が重複してしまうため、共通化する必要があります。特にImmutableImageとAnimatedGifの処理は似ているため、それらを共通化することにします。共通Interfaceを作るScrimageではImmutableImageとAnimatedGifは別のクラスであるだけでなく、共通のInterfaceを持っていないため、まずはそれを作成する必要があります。ここでは、ImageというInterfaceを作成し、それを実装するクラスを作成します。それぞれのクラスはWrapperとして作成し、それぞれのクラスのプロパティをInterfaceのプロパティとして持つようにします。sealed interface Image { val width: Int}class AnimatedGifWrapper( val animatedGif: AnimatedGif) : Image { override val width: Int get() = animatedGif.frames.first().width}class ImmutableImageWrapper( val immutableImage: ImmutableImage) : Image { override val width: Int get() = immutableImage.width}画像取得の共通化あとは外部に公開するAPIとして、asImageというメソッドを作成し、それぞれの形式に応じてWrapperを返すようにします。ここで、形式の判定は先ほど作成したdetectImageFormatを使います。fun asImage(rawData: ByteArray): Image { return when (val format = detectImageFormat(rawData)) { Format.GIF -> asAnimatedGifWrapper(rawData) Format.WEBP, Format.PNG, Format.JPEG -> asImmutableImageWrapper(rawData, format) }}private fun asAnimatedGifWrapper(rawData: ByteArray): AnimatedGifWrapper { val gif = AnimatedGifReader.read(ImageSource.of(rawData)) return AnimatedGifWrapper(gif)}private fun asImmutableImageWrapper(rawData: ByteArray, format: Format): ImmutableImageWrapper { val image = when (format) { Format.WEBP -> WebpImageReader().read(rawData) Format.GIF, Format.PNG, Format.JPEG -> ImageIOReader().read(rawData) } return ImmutableImageWrapper(image)}リサイズ処理の共通化同じく、リサイズ処理も共通化します。ここでは、resizeImageというメソッドを作成し、それぞれの形式に応じてリサイズ処理を行うようにします。ここで、リサイズ処理は先ほど作成したresizeImmutableImageとresizeAnimatedGifを使います。AnimatedGifのリサイズ処理はまた別途writeAnimatedGifというメソッドを作成して分けています。ここでImageはsealed interfaceとして作成しているため、分岐処理はwhen式を使って網羅することができます。suspend fun resizeImage(image: Image, width: Int): Image { return when (image) { is AnimatedGifWrapper -> resizeAnimatedGif(image, width) is ImmutableImageWrapper -> resizeImmutableImage(image, width) }}private suspend fun resizeAnimatedGif(gifWrapper: AnimatedGifWrapper, width: Int): AnimatedGifWrapper { val gif = gifWrapper.animatedGif val resizedData = writeAnimatedGif { stream -> gif.frames.mapIndexed { index, image -> stream.writeFrame(image.scaleToWidth(width), gif.getDelay(index)) } } val resizedGif = AnimatedGifReader.read(ImageSource.of(resizedData)) return AnimatedGifWrapper(resizedGif, resizedData)}private suspend fun writeAnimatedGif(writeFunction: (StreamingGifWriter.GifStream) -> Unit): ByteArray { return withContext(Dispatchers.IO) { StreamingGifWriter().use { streamingGifWriter.prepareStream(it, BufferedImage.TYPE_INT_ARGB).use { stream -> writeFunction(stream) } it.toByteArray() } }}private fun resizeImmutableImage(imageWrapper: ImmutableImageWrapper, width: Int): ImmutableImageWrapper { val resizedImage = imageWrapper.immutableImage.scaleToWidth(width) return ImmutableImageWrapper(resizedImage, imageWrapper.format)}画像のエンコード処理の共通化最後に、画像のエンコード処理も共通化します。ここでは、encodeImageというメソッドを作成し、それぞれの形式に応じてエンコード処理を行うようにします。suspend fun encodeImage(image: Image): ByteArray { return when (image) { is AnimatedGifWrapper -> image.animatedGif.bytes(Gif2WebpWriter.DEFAULT) is ImmutableImageWrapper -> image.immutableImage.bytes(WebpWriter.DEFAULT) }}これで共通化も終わり、呼び出す側はasImage, resizeImage, encodeImageの3つのメソッドを使うだけでリサイズ処理を行うことができます。サイズのチェックもImageの方でプロパティ化しているため、それを使ってリサイズが必要かどうかの判定も行うことができます。あとはImageWriterなど、毎回インスタンスを生成する必要のないクラスは、シングルトンとして作成しておくとよいでしょう。最後にだいぶ長くなってしまいましたが、ここまでで動的画像リサイズAPIの作成方法を紹介しました。Scrimageを使うことで、PNG, JPEG, WEBP, GIFの4つの形式に対してリサイズ処理を行うことができ、共通化することで処理の重複を防ぐことができました。あとは、Cloud Run上で動かすためのDockerfileを作成し、Cloud Storageとの連携を行うことで、画像の配信を行うことができます。また、Cloud CDNを使うことで、2回目以降の呼び出しではキャッシュを返すようにすることで、負荷を軽減することができます。なかなか面白いプロジェクトでした。では、また！

動的画像リサイズAPIを作る

CI/CDは一度インフラとアプリケーションを構築すれば、あまり変わることはありません。極端な話、期待通り動いてくれれば問題はないといえることです。しかし、場合によってはCI/CDのフローを見直すことも必要になります。アプリケーションの機能追加やインフラの変更などにはいつ変化があるかわからないし、緊急対応が必要な場合は迅速なデプロイが必要とされる場合もあるからです。そのため、CI/CDの高速化が非常に重要な課題となるケースもあります。実は去年転職をしましたが、転職先の会社ではCI/CDの高速化が課題となっていました。前職では2週間に一回というリリースのサイクルがあったのですが、今回は一日でも数回のリリースがあるため何よりもそのため、CI/CDの高速化を行うために、いくつかの方法を試してみました。今回はその中で、最も効果があった方法を紹介します。インフラ構成基本的には、以下のような構成になっています。GitHubにソースコードおよびCI/CDの構成ファイルを配置Cloud Buildを利用してDockerコンテナをビルドCloud Runにデプロイこの構成はFrontend, Backendともに同じで、データベースマイグレーションも同じ環境となっています。マイグレーションの時にはCloud RunでFlywayを実行してAlloyDBにマイグレーションを行っているようになっています。キャッシュで高速化CI/CDの高速化にはいくつかの方法がありますが、今回はキャッシュを利用することで高速化を行いました。高速化のために考えられるのはいくつかの方法がありますが、まずは簡単な方法としてキャッシュを利用することにしました。今回利用したキャッシュは二つで、一つはGradleのキャッシュ、もう一つはDockerイメージのキャッシュです。GradleのキャッシュまずGradleにはBuild CacheとConfiguration Cacheというものがあり、これらを有効にした場合、次回のビルドからはそれぞれ前回のビルドの成果物とビルド時の設定をキャッシュとして使うことになるのでビルドの時間をかなり短縮することができます。これらのキャッシュを有効にするには、gradle.propertiesファイルに以下のように設定を行います。// build cacheorg.gradle.caching=true// configuration cacheorg.gradle.configuration-cache=trueDockerイメージのキャッシュGradleのキャッシュを有効にしても、CI/CDの環境で実際ビルドが走る時に利用できるキャッシュが存在しなければなりません。そのために利用したのがDockerのキャッシュです。Cloud Buildのフローが実行されるたびに前回のビルドの成果物をどこかにプッシュしておき、ビルドが走る時にそれを利用するとGradleのキャッシュを利用することができるようになります。これを実現するためにはまず最初にCloud buildの構成ファイルは以前は以下のようになっていました。(一部抜粋)steps: - name: gcr.io/cloud-builders/docker args: - build - '-t' - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA' - api - '-f' - api/Dockerfile id: Build - name: gcr.io/cloud-builders/docker args: - push - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA' id: Push - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk:slim' args: - run - services - update - $_SERVICE_NAME - '--platform=managed' - '--image=$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:COMMIT_SHA' - >- --labels=managed-by=gcp-cloud-build-deploy-cloud-run,commit-sha=$COMMIT_SHA,gcb-build-id=$BUILD_ID,gcb-trigger-id=$_TRIGGER_ID,$_LABELS - '--region=$_DEPLOY_REGION' - '--quiet' id: Deploy entrypoint: gcloudimages: - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:COMMIT_SHA'上記のファイルでは、最初にコミットのハッシュでDockerイメージをビルドし、それをプッシュしています。その後、Cloud Runにデプロイするために、そのイメージを利用しています。この時、イメージのタグにはコミットのハッシュを利用しています。ここでキャッシュを挟むようにすると、以下のようになります。steps: - name: gcr.io/cloud-builders/docker args: - '-c' - >- docker pull $_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:latest || exit 0 id: Pull entrypoint: bash - name: gcr.io/cloud-builders/docker args: - build - '--cache-from' - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:latest' - '-t' - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA' - '-t' - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:latest' - api - '-f' - api/Dockerfile id: Build - name: gcr.io/cloud-builders/docker args: - push - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA' id: Push (Cache) - name: gcr.io/cloud-builders/docker args: - push - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:latest' id: Push (Latest) - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk:slim' args: - run - services - update - $_SERVICE_NAME - '--platform=managed' - '--image=$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:latest' - >- --labels=managed-by=gcp-cloud-build-deploy-cloud-run,commit-sha=$COMMIT_SHA,gcb-build-id=$BUILD_ID,gcb-trigger-id=$_TRIGGER_ID,$_LABELS - '--region=$_DEPLOY_REGION' - '--quiet' id: Deploy entrypoint: gcloudimages: - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:latest'上記のファイルでは、まず最初に前回のビルドの成果物をプルしています。これにより、前回のビルドの成果物を利用することができます。その後、ビルドでは--cache-fromオプションを利用して、前回のビルドの成果物をキャッシュとして利用しています。また、イメージのタグにはlatestとコミットのハッシュを利用しています。そして最後にContainer Registryにlatestとコミット8種の両方をプッシュします。こうすると、Container Registryでは一つのイメージに対して二つのタグが付与され、次回のビルドでもlatestを利用できるようになります。Dockerfileの修正Dockerイメージをビルドする際にDockerfileを使っていましたが、キャッシュをより効率的に利用するためにDockerfileを修正しました。修正前のDockerfileは以下のようになっていました。(一部抜粋)FROM eclipse-temurin:17RUN mkdir /apiWORKDIR /apiRUN ./gradlew build -x test -x compileTestKotlin上記のDockerfileでは、まずGradleのビルドを行っていて、成果物はGradleの設定によりjarファイルとしてビルドされます。そしてCloud RunではリポジトリないのEntrypointを実行するように設定しているため、jarファイルを実行するようになっています。一般的にはjarファイルだけを残すとコンテナのサイズを小さくすることができますが、今回はキャッシュを利用するためにjarファイル以外の成果物も残す必要があるので、ここは修正していません。ただ、Gradleのビルドが走る時に、毎回依存関係の解決を行うのは非常に時間がかかるので、依存関係の解決を行う部分だけをキャッシュするようにしました。結果は以下のようになります。FROM eclipse-temurin:17WORKDIR /api# dependency cacheCOPY build.gradle.kts settings.gradle.kts gradlew gradle.properties /api/COPY gradle /api/gradleCOPY docker /api/dockerCOPY detekt /api/detektRUN ./gradlew build -x test -x compileTestKotlin -x detekt || return 0# build appCOPY src /api/srcCOPY resources /api/resourcesRUN ./gradlew build -x test -x compileTestKotlinデプロイではほとんどの場合、ソースコードの変更が行われます。なので、あまり変わることのないGradle関係のファイルだけを先にコピーして、ソースコードのない状態でビルドを行います。これにより、実際のアプリはビルドされずに依存関係の解決だけが行われます。それからソースコードをコピーしてビルドを行います。なぜこのような構造にしたかというと、Dockerイメージのビルド時にはキャッシュが存在していても、コピーしたファイルに変更があった場合にキャッシュが無効になるためです。依存関係の更新があった場合は仕方なくキャッシュは効かなくなりますが、ソースコードの変更がない場合は依存関係の解決まではキャッシュが有効になるため、ビルドの時間を短縮することができます。ここでは主にBackendの設定を紹介しましたが、Frontendの設定もDockerfileを同じように修正することでキャッシュを利用できるようにしています。backendと多少は設定が違いますが、基本的にはyarnもGradleと仕組みとしては同じく先に依存関係の解決を行うようにするだけです。FROM node:18.17.1-slim AS baseWORKDIR /app# dependency cacheCOPY package.json yarn.lock ./RUN yarn --frozen-lockfileCOPY ./tsconfig.json ./COPY ./packages/app/package.json ./packages/app/package.jsonRUN cd ./packages/app && yarn || return 0# build appFROM base AS builderWORKDIR /appCOPY ./packages/app/ ./packages/app/COPY --from=base /app/packages/app ./packages/appRUN yarn build:app:productionデータベースマイグレーションの場合、Cloud Buildで直接DBに接続してマイグレーションを行うのが難しかったのと、Backendと同様の設定をすることでDBアクセスは簡単にできたので基本的にはBackendと同じくDockerイメージを作成し、Cloud Run上でEntrypointのスクリプトを利用しFlywayを実行するようにしていました。ただ、ここでBackendと同じDockerfileを使って同じくアプリをビルドしたあと、実際のアプリをCloud Runで実行するようになっていましたが、ここは必要なかったので（Cloud Runでは指定したポートからコンテナが応答するようにすればいいだけなので）アプリのビルドは行わなく、依存関係の解決だけを行うようにしました。ポートからの応答に関してはnginxを起動して応答するようにしています。最後に今回はCI/CDの高速化について紹介しました。キャッシュを利用することで、ビルドの時間が大幅に短縮できて、既存だと14分ほどかかっていたのが今は6分ほどになっているので、一日中でも数回のリリースが行われる現状はかなり大きい成果だと言えます。ただ、データベースのマイグレーションではCloud Runを使わないようにするなど依然として改善の余地はありますね。では、また！

Cloud BuildのCI/CDを高速化してみた

Java 21は何が変わったか

しばらくKotlinで書いてみたシリーズを書いていなかったので、今回はその四です。ListをListでソートデータ構造として、ListをListでソートしたい場合がありますね。例えばとあるテーブルに対して、別のテーブルのIDを持たせている場合などです。このテーブルのIDを配列にして、並び順を表現しているとしたら、この配列を元にソートしたいことになります。もちろんクエリでソートすることもできますが、クエリでソートすると、ソートした結果をキャッシュできないというデメリットがあります。そこで、ListをListでソートする方法を考えてみました。まずは以下のようなデータがあるとします。イメージとしては、複数の画像を持つImageBoxというデータがあり、そのImageBoxのimageOrderにはImageのIDが配列として入っているとします。data class ImageBox( val id: Int, val title: String, val imageOrder: List<Int> // imageのIDの配列)data class Image( val id: Int, val url: String)ここでDBとしてはImageBoxテーブルとImageテーブルがあり、ImageBoxテーブルのimageOrderにはImageテーブルのIDが配列として入っているとします。そしてアプリではImageBoxのimageOrderの順番にImageを表示したいとします。val imageBox = ImageBox( id = 1, title = "title", imageOrder = listOf(3, 1, 2, 5, 4))val images = listOf( Image(id = 1, url = "url1"), Image(id = 2, url = "url2"), Image(id = 3, url = "url3"), Image(id = 4, url = "url4"), Image(id = 5, url = "url5"))この場合、以下のようにソートすることができます。// imageBoxのimageOrderのをIndexをkeyとするMapに変換val indexMap = imageBox.imageOrder.mapIndexed { index, value -> value to index }.toMap()// imagesをimageOrderを元にソートval sortedImages = images.sortedBy { indexMap[it.id] }原理は簡単で、imageOrderの配列をIndexとvalueのMapに変換して、その値を元にソートしているだけです。この方法であれば、クエリでソートすることなく、imageOrderの順番にソートすることができます。また、こういったソートは以下のように拡張関数として定義すると、他の場所でも使い回すことができます。anotherには並び順を表現する配列を渡して、keySelectorにはソートしたい配列の要素から並び順の基準となる値を取り出す関数を渡します。fun <T, U> List<T>.sortedBy(another: List<U>, keySelector: (T) -> U): List<T> { val indexMap = another.mapIndexed { index, value -> value to index }.toMap() return this.sortedBy { indexMap[keySelector(it)] }}この場合、以下のように使えます。val sortedImages = images.sortedBy(imageBox.imageOrder) { it.id }keySelectorでitすら省略したい場合は、以下のような方法もあります。fun <T, U> List<T>.sortedBy(another: List<U>, keySelector: T.() -> U): List<T> { val indexMap = another.mapIndexed { index, value -> value to index }.toMap() return this.sortedBy { indexMap[keySelector(it)] }}この場合、以下のように使えます。val sortedImages = images.sortedBy(imageBox.imageOrder) { id }ListのページングページングはよくDBのクエリで行いますが、クエリでなくコードのみで処理したい場合もありますね。例えば、外部APIに対してリクエストを送る場合などです。この場合、ページングをどう実装するかが課題になります。この場合は以下のように拡張関数を定義することで、Listのページングを実装することができます。fun <T> List<T>.paginated(offset: Int, limit: Int): List<T> { // ページングが必要ない場合はそのまま返す if (offest == 0 && limit < size) { return this } // ページングが必要な場合はoffsetとlimitを元にsubListを取得する val fromIndex = (offset - 1) * limit return if (size <= fromIndex) { // ページングの範囲外の場合は空のリストを返す emptyList() } else { // ページングの範囲内の場合はsubListを返す val toIndex = size.coerceAtMost(fromIndex + limit) subList(fromIndex, toIndex) }}細かいものとしてはcoerceAtMost()を使って、sizeより大きい値を渡された場合はsizeを返すようにしています。これはもちろんIndexOutOfBoundsExceptionを防ぐためです。Exposed厳密にいってExposedはORMなのですが、Kotlinの書き方によってさらに便利になる部分もあるので今回はこちらも紹介したいと思います。InsertとUpdateの共通化ExposedでInsertやUpdateを書くのはかなり直感的なのですが、多くの場合にInsertとUpdateで同じ処理を書くことになります。そこで、InsertとUpdateの共通化を考えてみました。例えば以下のようなコードがあるとします。fun insert(image: Image): Image { ImageTable.insert { this[id] = image.id this[url] = image.url this[title] = image.title this[description] = image.description } return image}fun update(image: Image): Image { ImageTable.update({ ImageTable.id eq image.id }) { this[url] = image.url this[title] = image.title this[description] = image.description } return image}この場合、InsertとUpdateではID以外だとurlやtitleのような値をセットするという面では同じ処理を書いているだけですね。テーブルが増えれば増えるほど、このようなコードも増えていきます。幸いExposedではUpdate時のUpdateBuilderをInsert時のInsertStatementが継承している形の実装となっているので、以下のように共通化することができます。private fun UpdateBuilder<Int>.setParametersFrom(image: Image) { this[url] = image.url this[title] = image.title this[description] = image.description}このような関数を定義すると、InsertとUpdateの処理は以下のように書くことができます。fun insert(image: Image): Image { ImageTable.insert { this[id] = image.id it.setParametersFrom(image) } return image}fun update(image: Image): Image { ImageTable.update({ ImageTable.id eq image.id }) { it.setParametersFrom(image) } return image}これはbatchInsertの場合でも同じです。BatchInsertStatementもまたInsertStatementを継承しているので、以下のように共通化することができます。これでだいぶすっきりしたコードが書けるようになります。fun batchInsert(images: List<Image>): List<Image> { ImageTable.batchInsert(images) { this[id] = it.id this.setParametersFrom(it) } return images}BatchUpsertの実装ExposedにbatchInsertはありますが、batchUpsertはありません。ただ、クエリの書き方とアプリ側の実装によってbatchUpsertを実現することはできます。もちろんExposedPowerUtilsのようなライブラリもあるので、それを導入するのも良いでしょう。ただ、あのライブラリを使う場合は少し問題がありました。まずこのライブラリの実装では特定のカラムを指定して、それを基準にデータがすでに存在する場合はUpdate、存在しない場合はInsertという処理を行っています。最終的に作られるコードは、Insertをまず実行して、指定したカラムが重複している場合はON CONFLICTでUpdateを実行するというものです。ここでテーブルのIDはアプリ側で生成するUUIDであり、ON CONFLICTの基準となるカラムがFKの場合にはIDまでUPDATEされるという問題がありました。なので、先ほどのライブラリの実装を元に、PKを除いてUpdateするように実装を変更しました。それが以下です。（あと一部使ってない引数は省略してます）fun <T : Table, E> T.batchUpsert( data: Collection<E>, vararg keys: Column<*> = (primaryKey ?: throw IllegalArgumentException("primary key is missing")).columns, body: T.(BatchInsertStatement, E) -> Unit): BatchInsertOrUpdate { return BatchInsertOrUpdate(table = this, keys = keys).apply { data.forEach { addBatch() body(this, it) } execute(TransactionManager.current()) }}class BatchInsertOrUpdate( table: Table, private vararg val keys: Column<*>,) : BatchInsertStatement(table, false, false) { override fun prepareSQL(transaction: Transaction): String { val transactionManager = TransactionManager.current() val primaryKey = table.primaryKey?.columns?.toSet() // ここでprimaryKeyを取得 val updateSetter = ((table.columns - keys.toSet()) .let { columns -> primaryKey?.let { columns - primaryKey } ?: columns }) // ここでprimaryKeyを除外 .joinToString { "${transactionManager.identity(it)} = EXCLUDED.${transactionManager.identity(it)}" } val onConflict = "ON CONFLICT (${keys.joinToString { transactionManager.identity(it) }}) DO UPDATE SET $updateSetter" return "${super.prepareSQL(transaction)} $onConflict" }}トランザクションを分けるこの度はリードレプリカを導入することになり、GET系のAPIにはとりあえずリードレプリカを使うことになりました。ただ、リードレプリカは更新系のクエリを受け付けないので、更新系のクエリはプライマリに送る必要があります。そして、APIの実装としては例外を投げる前に明示的にロールバックを行うため別途の関数を定義していて、これと同じような使い方としてリードレプリカに接続するものを作りたいと思いました。まず、既存で使っていた関数は以下のようなものです。fun <T> transactionWrapper(statement: Transaction.() -> T): T { return transaction { try { statement() } catch (ex: Exception) { TransactionManager.current().rollback() throw ex } }}Exposedではtransactionの引数にDatabaseを渡すことで、簡単にどのDBに接続するかを指定することができます。なので、これを使ってリードレプリカに接続する関数を以下のように定義することができます。fun <T> readReplicaTransactionWrapper(statement: Transaction.() -> T): T { val readReplicaDatabase: Database = getKoinModule(named("readReplicaDatabase"))) return transaction(readReplicaDatabase) { statement() }}ここでのDatabaseをKoinを使用してinjectしているので、追加で以下のような設定を加えてます。// デフォルトのDBはプライマリに固定val defaultDatabase: Database = getKoinModule(named("primaryDatabase"))TransactionManager.defaultDatabase = defaultDatabase// Top level functionでKoinのinjectを使うための設定fun <T> getKoinModule(qualifier: Qualifier? = null): T { return object : KoinComponent { val value: T by inject(qualifier) }.value}これでtransactionを使うたびに関数名だけを変えるだけで、プライマリとリードレプリカに接続することができます。最後にいかがでしたでしょうか。今回もKotlinの小技的なものを紹介してみました。最近はあまり複雑なロジックを書いてない上、プライベートでの開発もあまりしてないので、なかなかブログのネタが思いつかないですね。たまにこちらのブログの記事を参考にしていただいている方がいるようなので、もう少し頻繁に更新できるように頑張ります。しばらくブログを更新してませんでしたが、今回はCompose Multiplatformも1.5.0になり、Java 21のリリースもまもなくなので、近いうちにまたそれらについての記事も更新していきたいと思います。では、また！

Kotlinで書いてみた〜その四〜

今年もKotlinConfが開催されました。毎年興味を持って参加やキーノートを視聴しているわけでもありませんが、最近はK2 CompilerにやKMMなどJetbrainsのプロダクトがかなり盛んな感じなので視聴することにしました。そこで思ったより興味深い発表が多かったので、今回はその内容について簡単にまとめてみようかなと思います。では、セッション別にどんな話があったのかを紹介していきます。K2 CompilerまずはKotlin 2.0で採用予定のK2 Compilerの話です。2021年から発表されていて、コンパイラの性能向上のみでなくプラグイン対応などの機能も提供する予定となっていますね。今現在開発が進んでいて、Kotlin 1.8がリリースされた今もかなり多い部分が完成されている状態です。ここではKotlin 1.8と、2.0になった場合のコンパイラのパフォーマンスの違いをまずグラフとして提示していました。当たり前ながら、2.0でかなり速度が上がったように見えます。同じ環境で20秒かかるものが、10秒に短縮されたということですね。Andoridの公式言語としてKotlinが採用され、JavaからKotlinに移行した開発者の間でやはりビルドが遅くなったという話を聞いた覚えがあるのでこれはかなり嬉しい結果となっていますね。またコンパイラのパフォーマンスが上がるとintellijでのコンパイルも早くなるわけなのでより快適な開発環境になると思います。また、今年の後半にはKotlin 1.9のリリースが予定されていて、その次に1.10のようなバージョンは予定にないとのことでした。つまり、1.9の後はすぐに2.0となるとのことですね。そして2.0は1.9の後方互換性を保つので、1.9でコンパイルができるのであれば2.0でもコンパイルができるとのことです。もちろん言語のバージョンアップを急ぐ企業さんはそこまではないと思いますし、コンパイラ自体が変わることでどんな問題が起こるかわからないので、実際の採用まではかなり時間がかるでしょう。ただ個人的にはサイドプロジェクトで色々試してみたいので、来年からはK2 Compilerに触れられるということが楽しみです。要望の多い機能YoutrackというサイトからJetbrainsのプロダクトに関して議論できるのですが、ここで要望の多い機能に対して今後どのような形で対応していくかを説明するセッションです。ここは一つ一つ、どのような要望があるかを見ていきます。Static ExtensionsKT-11968に上がっているもので、JavaクラスにもCompanion objectのように、staticなメソッドやプロパティを追加できるようにしてほしいということです。例えば、今までは以下のようにJavaのクラスにCompanion objectを定義してインスタンスの生成なしで使うことはできませんでした。File.open("data.txt")fun File.Companion.open(name: String)これを、staticというキーワードを使って以下のように書けるようになるとのことです。fun File.static.open(name: String)個人的にはMySQLとJVMの日付のMAX_VALUEの閾値が違ってバグが起きたことがあって、LocalDateに別途プロパティを追加したかったのにJavaのクラスにはstaticなプロパティの追加ができなくて諦めた経験があるのでこれはとても嬉しい変化です。Collection LiteralsKT-43871に上がっているもので、その名の通りコレクションのリテラルを作成できるようにしてほしいということです。例えば、今までは言語レベルでコレクションのリテラルに対応していなかったので、以下のような書き方が多かったかなと思います。cmdArgs = listOf("-language-version", "2.0")それが、以下のようにコレクションのリテラルを書けるようになるとのことです。val skip: PersistentSet<Int> = [0, 1]val skip2 = PersistentSet [0, 1]個人的にはconstキーワードの適用範囲をもっと広げてほしいと思っているところですが、これもまた悪くない変化ですね。特にアノテーションなどで使われる配列は実際リテラルになるケースが多いと思いますので、そこでまた色々と活用できる余地ができるかもしれません。Name-Based DestructingKT-19627に上がっているもので、分解宣言時に変数名とフィールド名が一致するようにしてほしいということです。例えば以下のように分解宣言をしたとしましょう。data class Person( val firstName: String, val lastName: String)val (firstName, lastName) = Person("John", "Doe")上記のコードの場合、firstNameはJohn, lastNameはDoeとなります。data classの実際のフィールド名とも一致しているので、なんの問題もありません。ただ、もし間違って以下のようにしたらどうでしょう。val (lastName, firstName) = Person("John", "Doe")この場合、意図とは違ってfirstNameはDoe, lastNameはJohnとなってしまいます。このようなミスを回避するためにinline classなどを導入してフィールドごとに型を定義したり、分解宣言そのものを使わないようにするなどの対応をしていることも少なくはないかと思いますが、今後はこのようなミスを回避するために、分解宣言時に変数名とフィールド名が一致するかどうかコンパイラが判断して値の代入を行うことになるとのことです。個人的にはかなりすごいと思いますが、心配も多いですね。単純に変数名とフィールドが一致する時のみ動作してくれるのかどうかわからないので、実際の動作を見ておきたいものです。Context ReciversKT-10468に上がっているもので、関数にコンテキストが必要な場合はパラメータとしてではなく、別途のキーワードを使ってコンテキストを渡すことができるようにしてほしいということです。例えば、以下のような関数があるとします。fun processRequest(context: ServiceContext, request: ServiceRequest) { val data = request.loadData(context)}上記の関数ではコンテキストを引数としてもらい、さらにそのコンテキストを違う関数の方に渡しています。当然、呼ばれる関数の方も引数にコンテキストが必要になります。以下のようにですね。fun ServiceRequest.loadData(context: ServiceContext): Data { /** ... */ }この場合、関数の中で呼ばれる他の関数が多くなればなるほど、その関数にもコンテキストを渡す必要が出てきます。そこで、以下のように別途のキーワードを使って、引数の追加なしでコンテキストを渡すことができるようになるということです。context(ServiceContext)fun processRequest(request: ServiceRequest) { val data = request.loadData()}context(ServiceContext)fun ServiceRequest.loadData(): Data { /** ... */ }このcontextのキーワードに渡せるコンテキストの基準が何か、そしてどのように関数の中でコンテキストを呼び出せるかどうかはまだわかりませんが、より綺麗な感覚になっているかなと思います。Explicit FieldsKT-14663に上がっているもので、privateなプロパティに対してpublicなプロパティを定義しなくても良いようにしてほしいということです。例えば、privateのプロパティに対して、外部から参照する場合は以下のように書くケースがあるかなと思います。privateなプロパティを維持しつつ、外部で参照のみできる別のプロパティがその値を提供するということですね。private val _applicationState = MutableStateFlow(State())val applicationState: StateFlow<State> get() = _applicationStateこれを、以下のように書けるようになるらしいです。val applicationState: StateFlow<State> field = MutableStateFlow(State())行数をかなり減らせられ、似たようなプロパティを定義する必要もなくなるのでかなり便利そうな感覚です。特にComposeのようにプロパティで状態を管理する場合はこのようなパターンが多いかなと思いますので、有効活用できるかなと思いました。Kotlin Notebooksこのセッションで新しくKotlin Notebooksというものの発表がありました。今はJupyter NotebookでもKotlinは使えるのですが、似たような機能をKotlin専用として開発したような感覚ですね。Jupyterそのものも有名で、動画の中ですでに多くの機能を紹介しているので説明よりはそのキャプチャを載せておきます。以下のような活用例が紹介されています。その他、自動完成やオンラインでのコードシェア対応、テーブルのソートとカラムの順番変更などができるという点が紹介で明らかになっています。Google@KotlinConfこちらのセッションはGoogleの人が出て発表をしていましたが、主に指標の話で、Androidのアプリの中でKotlinやComposeを採用しているものがどれほど多いかの話などが多かったですね。また、GoogleでもKotlinを積極活用していて、Google WorkspaceでもKotlin Multiplatformを利用してビジネスロジックを書いているという話がありました。他に注目したいところは、Androidの開発においてGradleのデフォルト設定がKotlin DSLになったというところです。Kotlinで開発をしているならもちろんGroovyよりはKotlinの方が便利だと思っていたので、このような変化はありがたいですね。ただ、GoogleでもKotlinを利用しているとはいえ、FlutterやGoという競合もあるので、今後どのような方向性を取っていくのかが気になりました。もちろんKotlinのカンファレンスなのでそのような話には触れなかったのですが、今後のGoogleの方針やCompose Multiplatformのシェアについてはもっと注目したいと思いました。CrossplatformこのセッションではComposeのiOS対応の発表と、Mutiplatformの現在の紹介などがありました。ComposeのiOSはAlpha、MultiplatformはBetaの段階で多くのライブラリが対応しているなどの話が続きましたね。Kotlinが初めからJVM以外の領域でも活用できることを目標として開発されたのは確かですが、登場から10年以上も経ってやっとそのロードマップが現実になっているなという感覚でした。個人的にはXcodeやSwiftUIよりはintellijとComposeの方が合っていると感じていたので、iOSの開発ができるようになったのは大変嬉しく思っています。特に、AppCodeの開発が今年て終了するとのことだったのでMacやiOSの開発のためには致し方なくSwiftUIを勉強する必要があるかなと思っていたところなのでタイミング的にも最適ですね。直近でちょうどKotlinのみでウェブとモバイル、デスクトップのアプリを開発するというサイドプロジェクトをやっているので、早速試してみようかなと思っています。最後に純粋にK2 Compilerの現在が知りたくて試聴した動画で、思わぬ発表が続いて嬉しい気持ちになりました。個人的には一つの言語で必要なことができるようにしたいと思っていたので、Kotlinという言語を選択したのは正解だったという気持ちになりました。やはりまだサーバサイドでもシェアはそこまで高くないかなと思いますが、これからもいろいろな分野でKotlinを使える環境が整っていくと言語として伸びるポテンシャルは十分など思いますので、また今後に期待ですね。取り急ぎ、KotlinConfのキーノートの動画を紹介しましたが、他にもいろいろな動画が公式のチャンネルにて配信中なので、興味がある方はぜひ見てみてください。では、また！

KotlinConf'23を要約してみた

最近はサイドプロジェクトとしてシンプルなWebアプリケーションを作っていて、サーバサイドのフレームワークではKtorを採用しています。今まではずっとSpringを触ってきたので、たまにはこうやって違うフレームワークで何か作ってみるのも楽しいですね。さて、そこで今回の記事のテーマとなるのが、KtorでPath Parameterを受け取りInline Classとして扱う方法についてです。高度な技術を要するものではないのですが、より型安全で便利に使えるコードが書ける方法ではないかと思い試したことの紹介となります。Inline ClassとはKotlin 1.6からInline Classという機能が追加されました。Inline Classは、型のラッパーとして使うことができる機能です。例えば、以下のようなコードがあるとします。プレイヤーがいて、そのプレイヤーごとの成績を表現したものです。// プレイヤーdata class Player(val id: Int, val playerRecordId: Int)// プレイヤーの成績data class PlayerRecord(val id: Int, val score: Int)そして以下のようなメソッドがあるとします。// プレイヤーの成績を記録するfun createPlayerRecord(val playerId: Int, val score: Int) { // ...}このメソッドを呼び出すときに、プレイヤーのIDとスコアを渡す必要があります。しかし、このコードでは、プレイヤーのIDとスコアの両方ともがInt型になっているため、プレイヤーのIDをスコアとして渡してしまうというようなミスが起こりうるのです。そこで、以下のように、プレイヤーのIDとスコアをラップした型を定義して、それを使うようにすると、より安全にコードを書くことができます。// プレイヤーのID@JvmInlinevalue class PlayerId(val value: Int)// スコア@JvmInlinevalue class Score(val value: Int)二つのInline Classを定義することで、先ほどの関数は以下のように修正できます。こうなると、パラメータを間違えて指定したらコンパイラーがエラーを吐いてくれるので、より安全にコードを書くことができますね。// プレイヤーの成績を記録するfun createPlayerRecord(val playerId: PlayerId, val score: Score) { // ...}ここだけみると、Inline ClassがJavaのラッパークラスや普通のdata classと何が違うんだ？という疑問が湧いてくるかもしれません。また、typealiasのような既存の機能もありますね。ただ、Inline Classはコンパイル時にprimitive型の扱いでありながら、実行時にはラッパークラスのように振る舞うという特徴があります。そのため、Inline Classだと型安全を担保できつつパフォーマンスへの影響も少ないというメリットがあります。KtorでPath Parameterを扱うKtorでは、Path Parameterを受け取るためには、以下のように書く必要があります。routing { get("/{id}") { val id = call.parameters["id"]?.toInt() }}Path Parameterを取得するために、ApplicationCallからParametersで{id}に指定された値をまずStringで読み込むようになります。そして、さらにtoInt()でIntに変換しています。これでPath ParameterをIntで受け取り、処理の中で使うことができるようになります。Path Parameterを受け取る処理を改善するcall.parametersを利用したサンプルは一瞬見てシンプルなコードなのであまり改善の余地はないかなと思うかもしれませんが、実はこのコードにはいくつか問題があります。例えば、Int変換時のエラーを考慮する必要がありますね。toInt()でIntに変換するときに、nullや"abc"といった文字列が渡された場合には、NumberFormatExceptionが発生してしまいます。また、toInt()でIntに変換するときに、Int.MAX_VALUEを超える値が渡された場合には、NumberFormatExceptionが発生してしまいます。このように、Path Parameterを受け取るときには、必ずnullチェックやNumberFormatExceptionのチェックを行う必要があります。また、ApplicationCallはget()やpost()のような関数の中でしか呼び出せないです。ということは、エンドポイントごとに同じような処理（エラーハンドリングなど）を書く必要があるということです。ルータ内で何回も同じような処理があるのは望ましくないので、このコードを共通化したいですね。なので、以下のようにApplicationCallに拡張関数を定義して、Path Parameterを取得する処理を共通化すると良いはずです。fun ApplicationCall.getIdFromPathParameter(name: String): Int { val parameter = parameters[name] ?: throw IllegalArgumentException("id is required") val id = parameter.toIntOrNull() ?: throw IllegalArgumentException("id must be integer") return idInt}このようにすると、以下のようにエラーハンドリングを共通化できます。try-catchで例外を処理していますが、ここは必要に応じてStatus Pagesによるエラーハンドリングを追加すると良いでしょう。routing { get("/{id}") { try { val id = call.getIdFromPathParameter("id") } catch (e: IllegalArgumentException) { call.respond(HttpStatusCode.BadRequest, e.message) } }}Path ParameterをInline Classでラップするさて、Path ParameterからInt型で取得する処理を共通化できたので、次はPath ParameterをInline Classでラップすることで、より安全にコードを書くことを考えてみましょう。まず、もっとも簡単な方法は以下のように拡張関数が返す値をInline Classにすることです。先ほどの関数だと、以下のようになります。routing { get("/{playerId}") { val id = PlayerId(call.getIdFromPathParameter("playerId")) }}ただ、Inline Classもとりあえずコード上ではクラスの扱いなので、ジェネリックを使うこともできます。なので、先ほどの関数をジェネリックを使ったものにする方法も考えられます。イメージ的には、以下のようになります。routing { get("/{playerId}") { val id = call.getIdFromPathParameter<PlayerId>("playerId") }}このようにすると、getIdFromPathParameter()の戻り値をPlayerIdに変換する処理をgetIdFromPathParameter()の中で行うことができます。また、ジェネリックであるため、使える型を特定のInterfaceに制限し、IDに関するInline Classがそれを実装するという形にしたらより安全なコードになるでしょう。なので、まずは以下のようにID系の共通のInterfaceを定義します。// ID系の共通のInterfaceinterface Id(val value: Int)// プレイヤーのID@JvmInlinevalue class PlayerId(val value: Int) : Id// 監督のID@JvmInlinevalue class DirectorId(val value: Int) : Idそして、以下のようにgetIdFromPathParameter()をジェネリックにして、Idを実装したクラスのみを受け取れるようにします。// IDを取得する拡張関数inline fun <reified T: Id> ApplicationCall.getIdFromPathParameter(name: String): T { val parameter = parameters[name] ?: throw IllegalArgumentException("id is required") val id = id.toIntOrNull() ?: throw IllegalArgumentException("id must be integer") return T::class.java.getDeclaredConstructor(Int::class.java).apply { isAccessible = true }.newInstance(id)}修正は簡単で、指定されたIdタイプのインスタンスを作成して、Path Parameterから取得したInt値をラップして返すだけですね。これでIdを実装するInline Classのみ対応するという制限もかけながら、型の安全性も確保できるようになります。ただ一つ、Path Parameterとしての変数名をInline Classの方にcompanion objectとして持たせて共通化できるといいのですが、残念ながらそれは難しいようです。interfaceのcompanion objectはoverrideできなく、Inline Classはabstract classを実装することができないからです。なので、他の方法でPath Parameter名の指定ができるようにすれば拡張関数の引数を減らしよりシンプルなものになるという改善の余地がまだありそうです。最後に久々にKtorを触り、ブログの記事にしてみましたが、どうだったでしょうか。ずっとRest APIの実装ばかりしていたので、プライベートで何か新しいチャレンジをしてみないと、なかなか発見がない状態となっているのではないかという気がしています。ブログを始めてかれこれ5年目になり、まだ勉強不足だと感じるところが多いと感じつつもなかなかそれを言語化することは簡単ではないとも感じています。ブログの更新の頻度が減ることになっても、次からはより良い記事になるように頑張りたいと思います。では、また！

Path ParameterをInline classで受け取る

Spring Boot 2 (Spring Framework 5) から Spring Boot 3 (Spring Framework 6) にアップデートしてみました。Java 17仕事でJavaを使っていたごろは、Java 17をずっと待っていました。以前こちらのブログの記事として整理したこともありましたがテキストブロックやSwitchを式で使えるなど便利な機能がたくさん追加されたためです。しかし、Kotlinを使っている今は機能や言語仕の観点からJavaのバージョンを機にする必要はありません。なので、既存のアプリケーションがJava 11で動いているのであれば、Java 17に上げるモチベーションはあまりないように見えるかもしれません。それでもあえてバージョンを上げようとした理由は、まずサポート期間が今年の9月で終わるからということになります。正確にはJava 11のPremier Supportが2023年9月で終わり、それに準するExtended Supportは2026年9月までということになります。ただ、「準する」という表現が曖昧で、11は今の時点ではもうだいぶ古く、17もリリースから1年以上の期間の間に十分検証されていると判断しました。サポート期間の話だけだと、まだ終了まで半年以上の時間が残っているのですが、このタイミングで行うのは会社で「リファクタ期間」というものを設けているためです。この期間中は主に技術負債の解消や依存関係のバージョンアップなどを重点的に行うので、新しい機能の開発とバージョンアップが重なり問題が起こるような事項は避けたいと思いました。そのほかでも、新しいJavaのバージョンを採用することでパフォーマンスの向上を図ることができる点があります。例えば、Java 11よりGCの性能が改善されていたり、状況によってZGCの導入を考慮できるオプションができたりです。Javaのバージョンが上がるということは、JVMの改善を含むということになるので、Kotlinでも十分その恩義を受けられることになるでしょう。なので、Java 17を採用することで決め、以降時の経験に関して共有したいと思います。Record社内ではORMとしてjOOQを採用していて、これから自動生成されたテーブル定義のコードをKotlinのコード(Repository)で呼び出す構造となっています。ただ、場合によってはこの自動生成のコードによりJava 17でのコンパイルが失敗することがあります。今回の場合は、以下のようなエラーメッセージと共にコンパイルが失敗するのを確認できました。エラー: Recordの参照はあいまいです public <O extends Record> SomeTable(Table<O> child, ForeignKey<O, SomeRecord> key) { ^ org.jooqのインタフェース org.jooq.Recordとjava.langのクラス java.lang.Recordの両方が一致しますこれはjOOQにRecordというクラスが存在していて、自動生成のコードでそれを利用しているためです。Java 14以降Lombokの@Valueと似た機能を持つRecord Classが登場していて、recordキーワードを使って定義したクラスは全てjava.lang.Recordを実装する形になっています。というわけで、「jOOQのRecordを意味するのか、JavaのRecordを意味するのかコンパイラが判断できない」とエラーが発生してしまうのです。これは、既存の自動生成コードのインポートを修正するだけで回避できます。既存のコードだと、自動生成のコードでは以下のようにjOOQのクラスをインポートしています。import org.jooq.*;これを、明確にjOOQのRecordを指定するように修正します。import org.jooq.Record;import org.jooq.*;以上で問題なくコンパイルが通るようになりました。もし自作のライブラリなどでRecordというクラスを定義している場合はここと同じエラーになる可能性があるので、なるべくクラスの名前を変えた方が良いかもです。Docker Image現在開発中のサービスはJibを使ってコンテナ化しています。ここでベースとなるイメージの指定が必要なのですが、既存で使っていたイメージはOpenJDKの11-jreでした。これが17からはJREのみのイメージはなく、17-jdkのみとなったので、バージョンをあげる際は注意する必要があります。ただ、OpenJDK以外のイメージ意外を使っている場合は状況が違うかもしれませんので確認が必要です。例えば、TemurinやZuluは17-jreを提供していて、Libericaの場合は17とバージョンだけになっているなど使っているJDKの種類によってタグ名が違うので、JDKのバージョンアップの際には使っているイメージのタグはチェックしておく方が良いでしょう。依存関係自分の担当しているアプリで発生していた問題ではないのですが(マイクロサービスとして、Kotlinのサービスは複数あります)、一部でJavaのバージョンを11から17に上げた際にJasperreportsを使った帳票の出力で報告された問題がありました。このライブラリはPDFの出力のために利用しているのですが、レイアウトに問題はなかったものの、表の中の表示文字数が少し減ったという問題がありました。幸い、これは大きい問題ではなかったのでまずは対応なしとなりそうですが場合によっては致命的かもしれません。おそらくこのような問題が発生したら、依存しているライブラリのバージョンをJava 17に対応したものにあげれば解消できるのではないかと思いますが、まだ17に対応していないライブラリがある可能性もあるので、事前に依存関係の方をチェックしておいた方が胃良いでしょう。Spring Boot 3Java 17は今年に11のサポートが終了するということで必須としていましたが、Spring Boot 3(Spring Framework 6)の場合は去年の12月にリリースされたばかりなので今回はあえて移行を試す必要はありませんでした。ただ、Spring Boot 3からちょうどJava 17が最低バージョンになり、以前からサーバレスのGAE上で起動しているプロジェクトもあったので、起動時間を減らすためにSpring Nativeを試してみたいと思っていたためでもあります。Spring NativeはSpring Boot 3から正式にサポートされることになったので。また、Spring Boot 3で依存関係が変わったり、プロパティの記述方法が変わったりするケースがあるとしても、自分が扱っているアプリケーションはマイクロサービスなので比較的に影響が少ないと予測できたからです。おそらくモノリシックで、Springの様々な機能に依存している場合は移行が難しい場合もあるかなと思います。なので、もし移行を考えている場合はなるべくリリースノートなどを確認しておいた方が良いでしょう。Spring Boot 2系から3系の移行は、基本的に公式のマイグレーションガイドを参照すると良いのですが、マイグレーションガイドだけではわからないことや、Spring Frameworkの依存関係の変化により他のライブラリに影響が出ることがあります。なので自分の場合はどのように対応したかを少し紹介したいと思います。@ConstructorBinding@ConstructorBindingは、@ConfigurationPropertiesを付けたクラスにアプリケーションプロパティファイルから読み込んだ値をコンストラクタインジェクションするためのアノテーションです。現在のプロジェクトではAWSのS3のバケット名やメールのテンプレート、他のAPIを呼び出すためのエンドポイントなどをapplication.yamlに記載して読み込むようにしています。ここで、Spring Boot 3だと@ConstructorBindingなしでもプロパティを読み込むようになって、そもそもこのアノテーション自体がDeprecatedになっています。なので、最初はコンパイルエラーとなりますが、@ConstructorBindingを削除するだけで問題なく動作するようになりました。最も簡単な対応でした。Tracingの変更現在のアプリケーションでは、他のマイクロサービスのAPIを呼び出す際にBraveを使ってヘッダにTrace Contextを載せています。この場合、同じTrace IDが連携されるのでログの確認がやりやすくなりますね。今まではSpring Cloud Sleuthを通じてBraveをDIしていましたが、これがSpring Boot 3になくなり(Spring Bootに統合）、Micrometerの新しいAPIを利用することになったらしいです。つまり、既存のSpring Cloud SleuthによるDIは使えなくなり、依存関係も変化があるということです。まずは、DIを担当していたBraveAutoConfigurationがSpring Boot Actuatorに移りました。なので、もうSpring Cloud Sleuthはいらなくなります。ただ、Spring Boot ActuatorだけだとBraveAutoConfigurationによるDIはできません。なので以下のようにブリッジの依存関係を追加する必要があります。(バージョンはSpring Bootのものが使われる)implementation("io.micrometer:micrometer-tracing-bridge-brave")依存関係が変わるので、application.yamlの設定も変更が必要になります。既存では、以下のように記載していました。spring: sleuth: enabled: true propagation: type: - w3cMicrometerに移行したので、このように変更します。実際は、以下の設定はデフォルトなので記載しなくても問題はありませんが、メンテナンス時に現在の設定がわかりやすいように記載しています。management: tracing: enabled: true propagation: type: w3cただ、最もつまづいた部分はユニットテストでした。テストを実行してみると、なぜか以下のようなエラーメッセージが出ていました。Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'brave.Tracing' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}Spring Cloud Sleuthを使っていた頃はユニットテスト時もDIができていたのですが、なぜかBraveAutoConfigurationによるDIが聞かない状態です。ローカルで起動した場合は同じエラーにならないので、おそらくテスト時にだけAutoConfigurationが呼ばれてないように思われます。@TestConfigurationなどを使って、直接Bean登録をする方法もあるかと思いますが、調査してみるとMicrometerにはテスト用のライブラリが用意されているので、それを使うことにしました。このライブラリがリリースされたのは2022年の12月なので、なかなか情報を見つけるのが難しいです。とにかく、以下のようにライブラリを追加することでDIの問題は解消できます。testImplementation("io.micrometer:micrometer-tracing-test")今回はライブラリの追加だけで解消できたのですが、新しいライブラリの情報はこちらで調べないとなかなかわからないというのが問題でしたね。他のライブラリの場合も同じ問題があるかもしれないので、もしAutoConfigurationによりDIされるはずのBeanが見つからないとのエラーが出る場合は、テスト用のライブラリが追加されてないか確認するのが良いかもしれません。追加で、Datadogの場合もMicrometerの設定の記載方法が全体的に変わったためか、一部プロパティの記載方法が変わっています。以前の場合は以下のように記載していました。management: metrics: export: datadog: enabled: true apiKey: ${API_KEY} step: 1mこれが以下のように変わります。management: datadog: metrics: export: enabled: true api-key: ${API_KEY} step: 1m他にもMicrometerの機能を使っている場合、既存のSpring Boot 2と比べプロパティの設定方法が変わってないか確認した方がいいでしょう。Jakarta EESpring Framework 6はOracleのJava EEからEclipseのJakarta EEに移行しているので、コンパイルが通らない場合があります。主にHttpServletRequestなどsevlet系や@Validなどvalidation系パッケージがよく使われているかと思います。これらはimport時のパッケージ名を変更することで対応できます。例えば、以下のようなパッケージを使っている場合だとします。javax.servletjavax.validationこれらは以下のように変更します。jakarta.servletjakarta.validationパッケージ名が変わっただけで、中身は変わっていないので、簡単な対応となります。springdocspringdoc-openapiを使ってAPIドキュメントを生成している場合、既存のバージョンだとSpring Boot 3と互換性がないようです。CIでは/v3/api-docsから取得したJSONを解析してS3にドキュメントをアップロードするようになっていますが、Spring Boot 3だと404エラーとなっていました。幸い、これも依存関係を変更することで対応ができます。以前は以下のように依存関係を追加していました。implementation("org.springdoc:springdoc-openapi-ui:1.6.14")implementation("org.springdoc:springdoc-openapi-kotlin:1.6.14")これを、springdoc-openapiのv2に変更するだけで良いです。Kotlinのサポートも含まれるので、以下のみで問題なく動きます。implementation("org.springdoc:springdoc-openapi-starter-webmvc-ui:2.0.2")これで404エラーは発生することなく、S3へのドキュメントのアップロードもできます。LiquibaseSpring Frameworkとの直接的な関係がある訳ではないのですが、Spring Bootのバージョンを上げたことにより影響を受けたのでこちらのケースも紹介します。DBのマイグレーションのためにGradleのプラグインとしてLiquibaseを使っている場合、バージョンによっては以下のようなエラーが出る場合があります。SLF4J: No SLF4J providers were found.SLF4J: Defaulting to no-operation (NOP) logger implementationSLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x or earlier.SLF4J: Ignoring binding found at [jar:file:/root/.gradle/caches/modules-2/files-2.1/ch.qos.logback/logback-classic/1.2.11/4741689214e9d1e8408b206506cbe76d1c6a7d60/logback-classic-1.2.11.jar!/org/slf4j/impl/StaticLoggerBinder.class]SLF4J: See https://www.slf4j.org/codes.html#ignoredBindings for an explanation.Exception in thread "main" java.lang.ClassCastException: class org.slf4j.helpers.NOPLogger cannot be cast to class ch.qos.logback.classic.Logger (org.slf4j.helpers.NOPLogger and ch.qos.logback.classic.Logger are in unnamed module of loader 'app') at liquibase.integration.commandline.Main.setupLogging(Main.java:233) at liquibase.integration.commandline.Main.run(Main.java:145) at liquibase.integration.commandline.Main.main(Main.java:129)これはおそらく、Spring Boot 3からSLF4Jのバージョンが2系になったためですね。Liquibaseのプラグインでは今までLogbackを使ってマイグレーションの状況を出力していたのですが、このLogbackのバージョンが1.2だったのでSLF4Jの2系と互換性がなかったのです。Logbackの1.3から互換性があるらしいので、それ以前のバージョンを使っている場合はこちらも合わせてバージョンを上げておく必要があるでしょう。最後に何とかJavaとSpring Bootのバージョンアップには成功していますが、前述した通り、これはあくまで自分が開発しているアプリケーションがマイクロサービスで、依存関係が比較的少なかったからできたことなのではないかと思います。モノリシックなアプリケーションだったり、より複雑な依存関係を持っているアプリケーションならここに記載したこと以外の部分でも問題が発生する可能性は高いでしょう。ただ、Springの場合はいずれSpring Boot 2のサポートが切れ、3系に移行するしかない状況が来るかもしれませんが、その時は十分マイグレーションの実例も出てくるのではないかと思います。Javaの場合は11から17に上げる場合なら大きく問題はないかと思いますが、8から移行する場合はJava 9で導入されたModuleで問題が起こる可能性もあるかと思いますので、慎重に行うべきかなと思います。嬉しいことに、まだNative化までは試してないのですが、JVM上でもアプリケーションの起動時間が減少していることを確認できました。ローカルで起動した場合、Java 11 & Spring Boot 2だと31秒がかかり、Java 17 & Spring Boot 3だと23秒がかかっていたので、断定はできないものの全体的な性能の向上もある程度は期待できるのではないかという気がします。正確なデータはまだ取れていないので、今後の課題として残しておきますが、ありがたいことですね。では、また！

Spring Boot 3を導入してみた

自分がJavaからKotlinに転向してからもう2年ほどが経ちます。しかし、いまだにKotlinでできることは無限にあって、新しい発見は終わることがないと感じています。Kotlinという言語自体のバージョンアップが早く、色々と機能が追加されて続けているのでまだしばらくこの発見も続きそうですね。そんな中で思うことなのですが、Intellijを使っていると自動的にJavaのコードを変換してくれたり、Javaの書き方をそのまま流用しても問題になることは少ないものの、やはりKotlinならではのコードを書きたいという欲求も湧いてきます。つまり、「Kotlinらしき書き方」をしたいと思ってしまうのです。Korlinらしき書き方って？「Kotlinらしき書き方」とは一体どういうものなのでしょうか。まずはその定義が必要ですね。いろいろな捉え方があるかと思いますが、私は基本的に「Kotlinの仕様や機能を最大限に活かすこと」なのではと思っています。つまり、スタンダードライブラリのAPI、Scope Function, Extensionなどを積極的にコードに取り入れることです。そうすることでコードを書く時間は短くなり、より効率が上がるだろうと私は思っています。ただ、そういう概念を言葉で述べるだけでは曖昧なところがあるので、コードを持って例を挙げた方がいいでしょう。例えば、以下のような関数を実装する必要があるとします。fun numbers(): List<String> { // TODO}この関数を通じて行いたい処理は、「0〜10の数字をStringに変換してListとして返す」ことだとしましょう。その場合、実装の一例として以下のようなコードを提示できるかなと思います。fun numbers(): List<String> { val list = mutableListOf<String>() var i = 0 while (i < 10) { i++ list.add(i.toString()) } return list.toList()}ここでkotlin.collections.map()を使ったら、同じコードを以下のように変換することができます。fun numbers(): List<String> = (0..10).map { it.toString() }map()のような関数が初めて登場した際は、あまり直感的にその処理の意味を把握できないということから「可読性に欠ける」という評価もあったようです。上記の二つのコードを比べると、場合によってはwhileループでの処理がわかりやすいと感じる方もいらっしゃるかなと思います。今はmap()が多くのプログラミング言語で採用している関数であり、期待できる関数の実行結果も常識化していますが、古典的なコードに慣れている人からしたら「ループで何かを行う」というコードの方がわかりやすいかもです。「可読性」としてしかし、果たしてより高度な処理を行う場合も「長いコードの方が可読性は良い場合もある」と断定できるのでしょうか。ここでまた、違う例を挙げてみましょう。例えば、Listの数字を全て掛け算した結果を返す関数を実装する必要があるとします。例えば以下のようなコードを書くことができるでしょう。fun multiply(numbers: List<Int>): Int { if (numbers.isEmpty()) { throw IllegalAccessException("List is empty") } var acc = numbers[0] if (numbers.size == 1) return acc for ((index, value) in numbers.withIndex()) { if (index != 0) { acc *= value } } return acc}上記のコードでは当初の目的は果たしていますが、「可読性」という観点からするとどうでしょうか。関数のシグニチャーだけでなく、関数で行なっている処理全体に目を通さないと、何が起こっているかわからないのではないでしょうか？この関数で行なっている処理を一つ一つ読んでみると、「リストが空の場合はエラーを返す」、「リストの要素が一つの場合はそれを返す」、「リストが空でなく、要素が一つでもない場合は後続の処理を行う」、「最初の要素をとり、リストの要素をループしながら最初の要素以外を全て掛け算する」という情報が込められています。ここでExtensionとkotlin.collectionsの関数を使って同じ処理を行う関数を実装してみると、コードは大きく変わります。以下がそのサンプルコードです。fun List<Int>.multiply(): Int = reduce { acc, e -> acc * e }map()の場合と同じく、reduce()という関数が何をするかがわからない場合もあるかと思います。しかし、その関数が「要素を一つに減らす」ことであり、その中で行なっている「減らし方は掛け算」ということを理解すれば良いだけなので、こちらの方がその意図を把握しやすいのではないでしょうか。先ほどの関数は、処理全体をいくつかの単位で分けて理解する必要があったということから考えると、可読性の面ではこちらの方がより優秀だと言えるのではないかと私は思っています。また、Listに拡張関数として定義することで、まるで元からついていたメソッドのように使えるのも良い点でしょう（IDEから自動補完に出てくるはずなので）。「工数」としてコードを書くのは工数がかかる行為です。なので、同じ機能をする関数を書くとしても、毎回全ての処理を書くより共通化できる部分は分離し、再利用するのが常識のようなものです。そのため多くのライブラリやフレームワークが存在していますね。プログラミング言語の使用や機能をよく理解し、それらを活用するということも本質的にはライブラリやフレームワークを使うことと変わらないものです。先のように、「Listの要素を一つにまとめる」処理を毎回自前で書くとしたら、かなりの時間が必要となるでしょう。ここで他の例をまた挙げます。例えば以下のようなデータがあるとします。data class Data(val id: Int, val version: Int)val list = listOf( Data(1, 1), Data(1, 2), Data(2, 1), Data(2, 2), Data(2, 3))DBの中に履歴を残したい場合はversionや枝番など名称の列を持たせ、同じIDのデータをいくつか挿入する場合があるかと思います。そしてその場合、最新のデータのみを処理したいケースもありますね。上記の例だと、Data(1, 2)とData(2, 3)のみを取得したいということです。最初からクエリで最新のデータのみを取得できるといいのですが、外部APIのレスポンスの場合はそのようにフィルタされたデータでない場合もあります。なのでこちらでversionがmaxのデータをフィルタする処理を書くとします。例えば以下のようなコードを考えられます。fun maxVersions(list: List<Data>) { val result = mutableListOf<Data>() for ((index, value) in list.withIndex()) { if (index == 0) { result.add(value) } else { val last = result[result.size - 1] if (value.id == last.id) { if (value.version > last.version) { result.remove(last) result.add(value) } } else { result.add(value) } } } return result.toList()}可読性の問題は一旦置いといて、このようなコードを書くときの工数はどうでしょうか。慣れてしまえば簡単なのかもしれませんが、初めてこの処理を書く人の立場からしたらかなりの工数がかかり、関数が期待通りに動作するかの検証を含めるとさらに工数が必要となりそうだと思います。慣れている場合でも、常にこのようなコードを的確に書けるかどうかが疑問です。それに対して、スタンダードライブラリを使った例を考えてみます。以下のように、メソッドチェーンによって簡単に同じことができます。val maxVersions = list.groupBy { it.id }.map { it.value.maxBy { it.version } }ここで使われているgroupBy()、map()、maxBy()はそれぞれ「ValueがListのMapを作る」、「要素を違う形にマッピングする」、「Listの要素のうちmaxの値を探す」という関数なので、ここだけでなく色々な場面で活用できる関数となっています。このように便利な関数を使いこなし、さらに組み合わせることでより複雑な処理でも簡単に書くことができるという点をみると、スタンダードライブラリの機能を理解するのは工数の面でもかなり効率を上げられることになるのではないかと思います。注意点ここまではKotlinの仕様や機能を活かすと可読性と工数という二つの観点から、メリットがあるという話をしてきました。しかし、どんなことでもメリットがあればデメリットもあるものですね。当たり前ながら、どんな機能でも単純に「それができる」という理由で乱用するとむしろ逆効果が出るケースがあります。例えば以下のような例を考えられます。二つのデータクラスがあって、DataからRequestにマッピングする必要があるとしましょう。data class Data( val id: Int?, val version: Int?)data class Request( val id: Int, val version: Int)Dataのフィールドはnullableとなっていますが、Requestの場合はそうではないです。このようにビジネスロジック上はnullになることはなくても、実装上の都合によってnullableにするケースもありますね。その場合、どうやってマッピングしたらいいでしょうか。例えば以下のような例があるとします。data class Request( val id: Int, val version: Int) { companion object { fun from(data: Data): Request { return Request( id = requireNotNull(data.id) { "${Data::id.name} should not be null." }, version = requireNotNull(data.version) { "${Data::version.name} should not be null." } ) } }}ここではcompanion objectを利用してRequestのインスタンスを生成しながら、データのマッピングを行うようにしています。そこで、requireNotNull()を利用したバリデーションを行い、nullだった場合はエラーメッセージを出力するようにしていますね。ここまでは良い実装だとして、問題はエラーメッセージの方です。どのパラメータがnullだったかわかるようにしていますが、そこでDataのフィールドをRefelctionで取得し、そのフィールド名をStringに埋め込むようにしています。エラーが発生した時には意図的に動作するとしても、果たして性能の劣るRefelctionを使うまでのことだったでしょうか。このように、言語が提供する機能を活用する場合は適切な場面を判断する必要があります。ここで紹介したmap()やreduce()、groupBy()なども便利で簡単な実装ができるようにしてくれる優秀な関数ですが、これらの関数の実装をみるとそれぞれが一つのループを必ず行い新しいCollectionを生成するという処理を行なっているということを理解すれば、メソッドチェーンで複数の関数を利用する場合は性能に影響を及ぼす可能性もあるということがわかるでしょう。他にも可読性の面でもわかりにくくなったり、別の関数として分離した方が良いコードが一つの関数内でいくつも繰り広げられることになる可能性もあるかと思います。なので、「曖昧な理解」や「慣性」としてこれらの機能を利用するという行為にはリスクがあるということを理解し、どのような実装をするかは常に悩むべきではないかと思います。最後にすでに何回か、「Kotlinで書いてみた」というタイトルで、Kotlinならこういう書き方ができるというポストを載せていて、今回の記事もまたそれらと大きく離れた題ではないです。また、ある意味ここで挙げたことはプログラマなら基本的に熟知しておくべき常識のようなもので、今更な感があるのかもしれません。それでもあえて記事として書いている理由は、基本こそ大事だという自分の考えゆえでもあります。経験を積んでいくと発展する部分もありますが、逆に変な習慣がついてしまいなかなか直せないところも出てくるものですので。自分はそうでないかという警戒を兼ねて、一度は基本に戻り今の自分と照らし合わせてみるのもまた一つの勉強になるのではないかと思います。ちょうど年末ということもありますが。少し遅れてしまいましたが、2022年のポストはこれにて終わりとなります。来年は自分も、ここに訪れるみなさんにも成長のある一年になることをお祈りします。では、また！

Kotlinはどう書いたらいいか

ほとんどの言語で、特定の条件に合致した場合にのみ実行する処理を書くには、ifのように分岐処理のための構文を使うのが当たり前のように考えられています。言語によっては構文ではなく式として扱われたり、switchや三項演算子のような他の選択肢も存在しますが、基本的に「条件とそれに従う処理」を書く機能として本質は変わらないものですね。分岐処理に限った話ではありませんが、便利な道具というのは時に危険性を伴うこともあります。ifを使う場合、最初の実装ではわかりやすく簡単に目的を達成できますが、維持保守の観点からするとあまり良くない選択になるケースもありますね。たとえば条件が増えたり変わるなどコードに変更が必要となった場合は修正がすべてのケースを網羅しているかどうかがわからなくなったり、ユニットテストが困難になったりするなどが考えられます。なので少なくともifの処理をよりシンプルにしたり、もしくはデザインパターンなどで分岐の構文を使わず同じ処理ができるように改善する必要が出てくることもあるかなと思います。そうすることで、コードリーディングはより難しくなるとしても、維持保守の観点からはより良いコードになる可能性もあるでしょう。もちろん、完全にifをなくするというのは不可能に近い話で、そこまでする必要もありません。道具自体に罪はなく、あくまで使い方が問題になるだけですので。ここではあくまで、ifを使ったコードをどういう風にリファクタできるか、それだけに集中したいと思います。（初心者向けな感じで）if文の例まずは、以下の関数をご覧ください。コードと価格を渡したら、内部ではコードに合わせて元の価格から割引の値を返すというものです。極めて単純化してはいますが、ECサイトのプロモーションなどでこのような処理が存在することもあるかなと思います。fun getDiscountAmount(code: String, amount: Int): Int { return if (code == "Facebook") { (amount * 0.1).roundToInt() } else if (code == "Twitter") { (amount * 0.15).roundToInt() } else if (code == "Instagram") { if (amount < 1000) { amount } else { 1000 } } else { 0 }}すでにどのように処理をリファクタすれば良いか、一目でわかる方もいらっしゃるかなと思いますが、ここでは色々な観点でどうコードを変えられるかを述べたいので、一つ一つ項目を挙げて説明したいと思います。関数のリファクタまずは関数内の処理をどう変えられるかを考えてみます。コードをより単純化して可読性を向上したり、処理の漏れをなくしたり、共通化できたり処理の単位が曖昧な場合は分離するなどいろいろな方法が考えられるはずです。標準ライブラリ上記の関数ではifの中にさらにifが入っている構造となっているのがわかります。このようなネストは深くなれば深くなるほど良いコードとは言えませんね。なのでまずはここから直していきましょう。ifのネストを一つ減らす方法として、標準ライブラリを用いた方法を考えられます。標準ライブラリでなくでも関数として分離するという選択もありますが、標準ライブラリに処理を委任することでこの関数の負担がまず減るかなと思います。KotlinにはcoerceAtLeast()という関数があり、パラメータとして渡された値をミニマムとして返すという働きをします。なので、amountが1000以下の場合はamount自身を、それ以外は1000を返すという処理はこの関数を使うことで単純化できます。以下のようにですね。fun getDiscountAmount(code: String, amount: Int): Int { return if (code == "Facebook") { (amount * 0.1).roundToInt() } else if (code == "Twitter") { (amount * 0.15).roundToInt() } else if (code == "Instagram") { amount.coerceAtLeast(1000) // 閾値を超えない値となる } else { 0 }}単純に標準ライブラリを使用しただけですが、ネストが一つなくなりより単純なコードになりました。また、ここでの修正により閾値の修正が必要になった場合でも、1箇所だけを修正すると良いというメリットもありますね。他にも標準ライブラリで処理ができそうな場所は積極的に利用したり、似たような処理が繰り返されるところがあったら切り出して自前のライブラリとして分離しておくことも良い選択になるでしょう。whenもう一つのリファクタとしては、ifをwhen(他の言語のswitch)に入れ替えるという方法を考えられます。whenは結果的に同じ機能をするので、常にifの代替として良いというわけではありません。しかし、ifの条件が一律であれば、whenを選ぶのは良い選択になる場合があります。先ほどのifで分岐する条件は、あくまでcodeという文字列がどのような値となっているか比較することだけですね。他には特に条件がないので、whenを用いた方がブランチを文字列だけで収めるのでより単純化つ明瞭なコードになります。たとえば以下のようにです。fun getDiscountAmount(code: String, amount: Int): Int { return when (code) { // codeの値を比較するだけの分岐 "Facebook" -> (amount * 0.1).roundToInt() "Twitter" -> (amount * 0.15).roundToInt() "Instagram" -> amount.coerceAtLeast(1000) else -> 0 }}ifをwhenに変えただけで、全体的に短くなってより読みやすいコードになっているかと思います。このように、ifの条件文がどのようなものかをみて、whenに変えるのも場合によっては良い選択の一つになり得るかなと思います。拡張関数Kotlinのような言語には、拡張関数で既存のクラスにメソッドを追加する機能がありますね。同じような処理が2箇所以上繰り返されているなら関数として分離を考慮すべきで、その関数を拡張関数として定義することも場合によっては考えられます。ここではcodeがFacebookかTwitterかによる分岐がありますが、やりたいことはamountに特定のパーセンテージをかけて返すことですね。なので、パーセンテージを求める関数を定義しておいた方が良いでしょう。パーセンテージを求めるのはここでしか使わないとしたらprivateな関数として定義しても良いのですが、より汎用的な使い方ができるようにしたいなら、以下のような拡張関数を定義するのもありでしょう。// パーセントを求める拡張関数infix fun Int.percentOf(amount: Int): Int = (amount * this / 100)fun getDiscountAmount(code: String, amount: Int): Int { return when (code) { "Facebook" -> 10 percentOf amount // 10パーセントの値を返す "Twitter" -> 15 percentOf amount // 15パーセントの値を返す "Instagram" -> amount.coerceAtLeast(1000) else -> 0 }}先のほどのコードと比べ、拡張関数を定義することで処理の共通化ができたことと共に、「パーセントを計算する」という意図がコードでより明確に表れているようになっているのではないかと思います。Mapifやwhenを使わない場合でも分岐ができる場合はあります。たとえばMapを活用する方法ですね。codeによって違う値を掛け算したいので、codeをKeyに、掛けたい値をValueとするMapを定義しておくことです。たとえば以下のようなものです。// コードと割引率val discountPercentages = mapOf( "Facebook" to 10, "Twitter" to 15)fun getDiscountAmount(code: String, amount: Int): Int { // 割引率が定義してあったら掛け算 discountPercentages[code]?.let { return it percentOf amount } // Mapにないcodeの場合 return when (code) { "Instagram" -> amount.coerceAtLeast(1000) else -> 0 }}ただ、この方法では全ての分岐を網羅することはできなくなりますね。codeの値ががMapのKeyに含まれてない場合の処理が必要となるからです。ここでクロージャを用いるとcodeの値がInstagramの場合の処理もMapに含めることができます。たとえば以下のようにですね。// Valueを(Int) -> Intに変えるval discountRules = mapOf( "Facebook" to { amount: Int -> 10 percentOf amount }, "Twitter" to { amount: Int -> 15 percentOf amount }, "Instagram" to { amount: Int -> amount.coerceAtLeast(1000) })fun getDiscountAmount(code: String, amount: Int): Int { return discountRules[code]?.let { it(amount) } ?: 0}Mapを利用する方法が条件分岐より良い方法だとは言い切れないのですが、コード別の割引率を他の関数でも参照する必要があるなど、複数の関数やクラスを跨いで共通の値を保持しておきたい場合は考えられる方法の一つになるかなと思います。この場合は、Map一つを修正するだけで全体の処理で整合性が保証されるコードになるという効果がありますね。OOP的な考え方今までは単純に関数内部の処理をどう変えていくかについて述べましたが、より高度な方法ももちろんあります。OOPの考え方として捉えると、先ほどの関数は「割引額を求める」責任がありますが、その中で「割引」の定義そのものと、その計算式まで持っていることになります。なので、責任を分離していく必要がありますね。この修正に処理は一見より複雑なものになっていくと感じる場合もあるかと思いますが、これはOOPに原則であるSOLIDを考慮したものでもあります。長期的な観点からすると、このような方法をとった方がより維持保守には向いていることになるでしょう。interface抽出まずは「割引ポリシー」をinsterfaceとして分離します。この割引ポリシーを実装するクラスで実際のポリシーに従う割引額を計算するイメージです。interface DiscountPolicy { fun calculate(amount: Int): Int companion object { val NONE: DiscountPolicy = object : DiscountPolicy { override fun calculate(amount: Int): Int = 0 } }}あとはこのinterfaceを実装するクラスを、コード別に定義しておきます。class FacebookDiscountPolicy : DiscountPolicy { override fun calculate(amount: Int): Int = 10 percentOf amount}class TwitterDiscountPolicy : DiscountPolicy { override fun calculate(amount: Int): Int = 15 percentOf amount}class InstagramDiscountPolicy : DiscountPolicy { override fun calculate(amount: Int): Int = amount.coerceAtLeast(1000)}こうやって割引ポリシーを定義しておくと、getDiscountAmount()は以下のように変えられるでしょう。fun getDiscountAmount(code: String, amount: Int): Int { val discountPolicy = when (code) { "Facebook" -> FacebookDiscountPolicy() "Twitter" -> TwitterDiscountPolicy() "Instagram" -> InstagramDiscountPolicy() else -> DiscountPolicy.NONE } return discountPolicy.calculate(amount)}Factory先ほどのinterface抽出で割引ポリシー自体は分離できたものの、getDiscountAmount()ではまだ「割引ポリシーを生成する」という責任を持っています。これもまた別の役割として分離ができるでしょう。ここは以下のように割引ポリシーを生成するFactoryを定義しておくと良いでしょう。object DiscountPolicyFactory { fun getDiscountPolicy(code: String): DiscountPolicy { return when (code) { "Facebook" -> FacebookDiscountPolicy() "Twitter" -> TwitterDiscountPolicy() "Instagram" -> InstagramDiscountPolicy() else -> DiscountPolicy.NONE } }}最終的に、getDiscountAmount()は以下のように修正できます。interfaceの抽出やFactoryの作成でコードの量は増えましたが、この関数の責任はより軽くなり、割引ポリシーの追加や修正が必要な場合でも柔軟な対応ができるようになりました。fun getDiscountAmount(code: String, amount: Int): Int { val discountPolicy = DiscountFactory.getDiscountPolicy(code) return discountPolicy.calculate(amount)}Enum割引ポリシーを生成するためにFactoryを使う代わりに、Enumを使うこともできます。先ほどのDiscountPolicyを継承して、クラスではなく列挙定数として扱う方法です。たとえば以下のようなものが定義できます。enum class DiscountPolicies(private val code: String) : DiscountPolicy { FACEBOOK("Facebook") { override fun calculate(amount: Int): Int = 10 percentOf amount }, TWITTER("Twitter") { override fun calculate(amount: Int): Int = 15 percentOf amount }, INSTAGRAM("Instagram") { override fun calculate(amount: Int): Int = amount.coerceAtLeast(1000) }; companion object { fun fromCode(code: String): DiscountPolicy { return values().find { it.code == code } ?: DiscountPolicy.NONE } }}上記のEnumを利用する場合、getDiscountAmount()は以下のようになるでしょう。fun getDiscountAmount(code: String, amount: Int): Int { val discountPolicy = DiscountPolicies.fromCode(code) return discountPolicy.calculate(amount)}Enumの場合、fromCode()でcodeによる分岐そのものが必要なくなり、割引ポリシを追加したい場合でも列挙定数を追加することで拡張も容易にできるのでFactoryよりも良い方法ではないかと思います。最後に最初に断っておいたように、全てのifをなくすのは不可能に近い話で、そうする必要もありません。しかしそのifが行っている処理の本質、責任、可読性のような要素は注意深く観察する必要があり、最初はifでとりあえず動くコードを作ったあとは他の方法で改善できるかどうか振り返ってみる必要はあるかなと思います。こういう自分も常に綺麗なコードを書いているわけではないのですが、たまにはこうやって初心者の気持ちで自分の書いたコードを振り返ってみるという姿勢は常に必要なのではという気持ちにもなります。良いコードを書くのは常に難しいものですね。でも、難しいことを最初にやっておいた方が後に後悔しないことにもつながるだろうと思います。では、また！

ifでの分岐を考える

Kotlinだけでファイルサーバを作ってみた

バックエンドの開発をしていると、テストの自動化では対応できない場合もありますね。理想的なシナリオとしては、ユニットテストから全てのシナリオを想定したインテグレーションテストまでを全部作成でき、開発・企画に属するものがそれらを理解しきっていることだろうとは思いますが、現実ではなかなか難しいものです。特に、サービスが成長していきながら技術的負債を解消しようとしたり、新しい機能を足したり、昔は対応できなかった改修が必要となったり、運用上のイレギュラー対応が必要となったりなどで最初の仕様は変わり続けていき、改修を行うエンジニアや運用する側でも今の状態がどうで、どう変わるべきかを判断するのは難しくなりがちなのだから、と自分は理解しています。なので、少なくとも今のアプリがちゃんと想定通りに動くかどうかを人の手で検証する必要が出てくるケースも十分にあり得るものです。そしてそうなった場合はどうやってテストを行うかを考える必要もありますね。テストの方法も色々あり、小さい機能単位でユニットテストを行い、最終的にはインテグレーションテストやシナリオテストまで上がっていくと良いはずですが、その全部を自動化するのが難しいケースもあるかと思います。例えばテストするためのデータのパターンを色々と用意する必要があったり、エンジニアが完全に仕様を把握してなかったりなどの場合もありますね。なので、人の手によるテスト（モンキーテスト的な）が必要となる場面も存在すると思います。今回はその「人の手によるテスト」を手伝うために、テストツールを作った話です。自分の扱っているシステムはマイクロサービスの一つであり、業務仕様が複雑でさまざまなパターンで機能をテストする必要がありました。なのでエンジニアとしては実装を進めながら、同時に業務仕様に詳しい人にさまざまなパターンのデータを使ってテストができるツールを作ることになったわけです。目標と設計、技術選定実は以前から、リポジトリにはすでにテストツールが存在していました。しかし調べたところ、作られて2年以上放置されていて、Ruby on railsという自分が全く触れたことも（興味を持ったことも）ないフレームワークで作られているという問題がありました。これだと、自分がRubyを勉強して既存のツールを改修するという手もあったかもしれませんが、以下の理由から一から作り直そうと思いました。KotlinエンジニアがRubyアプリをメンテするのは良くないドキュメント化が進んでなく、使い方が不便そう決めてからは、テストを行いたい側（企画）からの要請を受け、ツールに要求される仕様としての機能をまとめることに。テストが行えるツールという確実な目標があったので、仕様は極めて単純です。要求事項としてツールに揃うべき機能は以下のようなものでした。テストデータのファイルを読み込ませるバックエンドのアプリのAPIを呼び出すAPIの実行結果をファイルに書き込むテストツールとしては上記に挙げている要求事項を満たしているならテストツールとしては合格というわけです。しかし、実際のテストを行いたい側がまずエンジニアではなく、今後もエンジニアではない人がツールを触る可能性があります。そこまでを考慮して、以下の追加的な目標を立てました。環境構築をしなくても使えるようにする手順書がなくても使えるくらい簡単なものに仕上げるここまで決めたら、次に要求されている機能の細部を掘り下げていきます。設計書を書くほどでもないですが、土台となる設計のようなものです。データの読み込みと書き込みツールを使える人はSQLが使える=テーブル（表）が読めるテーブルの形でデータの入出力ができた方がわかりやすいテストデータはCSVで読み込むAPI実行結果もCSVに書き込むAPIコールができるHTTPクライアントでGET・POSTするAPIコールにはトークンが必要トークンはセキュリティ問題でソースコードに埋め込むのはNGしかし毎回入力するのはめんどくさいアプリを実行して最初はトークンを入力し、次回からはそのトークンを使い回すようにする本番以外の環境が対象複数の環境があるのでどれかを選択できるようにするこれも毎回入力はめんどくさい最初に一回だけ選択できるようにしたいそして自分の立てた目標を、上記の要求事項を達成できるかどうかを考えながら振り返ってみます。環境構築をしなくても使えるなら、実行可能な一つのバイナリとして提供した方が良いでしょう。また、使い方が簡単な方だと、やはりGUIを含めた方が良いですね。特にGUIを採用したら要求事項に対してもかなり良い感じで機能を完成できると思いました。例えばファイルの読み込みや書き込みにはパスの指定が必要で、トークンと環境の選択も入力が必要な項目で、CLIだとやはり不便です。エンジニアではない人が触るとしたら尚更ですね。Windowsユーザなら、コマンドラインも考慮しなければならないかもしれません。その反面、GUIだとファイルパスならダイアログ、トークンの入力もテキストポックス、環境の選択ならプールダウンメニューで対応できます。なので、「バイナリの実行で起動できるGUIのアプリを作る」という結論を出しています。Compose for Desktopテストツールの仕様と技術的な要件が決まったら次は技術選定になりますがね。まずどの言語を使うかについてですが、自分以外でも同じチーム、つまりKotlinエンジニアがこれからもメンテを行うことになる可能性が高いのでKotlinにしました。Kotlinを使うことで、機能の実現で必要なライブラリの選定も楽になりますね。すでにテスト対象のバックエンドアプリで使っているHTTPクライアントがあるので、一部のコードはそのまま移植しても良いはずです。また、同じライブラリを使うことでメンテもより簡単になるでしょう。あとはGUIですが、今回はCompose for Desktopを使うことにしました。KotlinはJavaと互換性があるので、当然SwingやJavaFXなどJavaのGUIツールキットをそのまま使うという選択肢もあります。他にもTornadoFXという選択肢があったりもしますが、今回あえてComposeを選んだのはいくつかの理由があります。まずは個人的にモバイルに興味があって以前から興味を持っていたので、今回本格的にこれでアプリを作ってみたいという願望もありましたが、今後もKotlinエンジニアの手でメンテが行われるとすると、やはりモバイルの経験があるか、少なくとも興味を持つ方が多いだろうという点です。Composeはまだ正式リリースされて1年ほどしか経ってない新しいものですが、最近流行っているいわゆる「宣言型」のフレームワークなので、少なくともAndroidアプリの開発ではメインストリームになる可能性が高いだろうという判断からでした。また、Composeはモバイルのみでなく、そもそもマルチプラットフォーム向けに開発されたものなので、Windows/Mac/Linuxの環境を問わず実行可能なバイナリをビルドできるという点でも魅力的だったです。これならテスターがどんなOSを使っていても同じ感覚でツールを使えて、ただ、やはり今まであまり接したことのない技術なので勉強はもちろん試行錯誤などもあったので、テストツールを作りながらこれは覚えておいた方が良いなと思ったところをいくつか挙げてみようと思います。状態管理SwiftUIのポストの時も触れた状態管理ですが、Composeでも同じくGUIを扱うことになるので、状態管理が大事となります。今回はアプリとしての画面がひとつしかないので、複数の画面にまたがって状態を管理する必要はないかなと思いましたが、それでもやはり処理を行うためにはアプリ全体で共有する状態として管理が必要なものがいくつかありました。ただ、上記ポストでも述べた通り、SwiftUIとComposeとは状態管理の方式が少し違います。SwiftUIでは状態がどこで使われるかによって明確に使われるアノテーションやクラスなどが変わっていたなら、Composeでは大体remember()とMutableState<T>の組み合わせで事足りることになります。画面の構成要素の最小単位をComposeではWidgetでも使い方が同じだということは、SwiftUIと比べると定義するのは簡単ですが、使い方には少し注意が必要だなという感覚でした。まず、Composeでの状態は、以下のような三つの方法で定義することができます。// Delegateで定義するvar isOn: Boolean by remember { mutableStateOf(false) }// 直接値を書き換えできるisOn = false// 分解宣言で定義するval (isOff: Boolean, setIsOff: (Boolean) -> Unit) = remember { mutableStateOf(true) }// 参照と更新が分離されるif (isOff) { setIsOff(!isOff) // toggle}// MubtableState<T>として扱うval isNotOff: MutableState<Boolean> = remember { mutableStateOf(false) }// ラッパーになっているので、値を更新するためにはvalueにアクセスする必要があるisNotOff.value = !isNotOff.valueここでDelegateでvarとして定義した場合は最も使いやすくなりますが、Intellij上ではコンパイルエラーになりがちです。なぜかというと、Delegateを使うためにはandroidx.compose.runtime.setValueとandroidx.compose.runtime.getValueをimportする必要がありますが、これが自動で行われないからです。最初このエラーの理由がわからなかったり、忙しい場合にいちいちimport文を書いていくが面倒だったりでかなり使わなくなるケースも多いかなという気がします。ただこれは、まだIntellijでのCompose対応が完璧ではないのが原因なので、これはいずれ解消されると期待できるでしょう。分解宣言で値の参照と更新を別々で使うのは、どこで使うか悩ましいケースもあるかなと思いますが、Composeの一部Widgetに状態を渡す場合に使われる場面があります。代表的なものがTextFieldで、これはコードを見るとすぐにその目的がわかります。実際のコードで、以下のように使われます。val (text: String, updateText: (String) -> Unit) = remember { mutableStateOf("") }TextField( onValueChange = setValue, // TextFieldに文字を入力するとその値でtextを更新する value = text // textの値をTextFieldに表示する)最後にMutableState<T>として定義するケースですが、直接的な値の更新ができないので最も使い方としては不便なのですが、実際は最も多く使われるのではないかと思います。なぜかというと、アプリ全体で状態を共有するなど複数のWidgetをまたがって使う場合は、以下のようにclassの中にフィールドとしてMutableState<T>を定義することになるからです。// アプリ全体で共有するためにクラスに状態を定義するclass AppState( val isOn: MutableState<Boolean>)これはもちろん別途getter/setterをclassに定義しておくと、中のvalueにアクセスしなくても直接プロパティにアクセスする感覚で使えます。イメージ的には以下のようなものですね。これだと状態として管理したい項目が増えれば増えるほどコードの量が増えてしまう面倒さがあるというのが短所かなと思います。class AppState( private val _isOn: MutableState<Boolean>) { var isOn: Boolean get() = _isOn.value set(value) { _isOn.value = value }}このように、Composeでの状態には定義する方法が色々あり、それぞれの特徴があるわけなのでどの場面で使うかによって適切な定義の方法を考えるのが何よりも大事だという印象です。Swing/AWTCompose for Desktopの特徴の一つは、SwingやAWTに対する互換性があるという点です。最初はMacのトレイ、メニューバー、通知にも対応していたので基本的な機能は全て揃っているのではないかと思いましたが、実はそうでもなく、一部の機能はSwingやAWTの機能を借りて実装することになるケースもありました。実際、私の作ったテストツールでも一部SwingとAWTの機能を使っているところがあります。例えばファイル選択機能がそうです。CSVを読み込むためにファイル選択のダイアログを表示したかったのですが、ComposeのWigdetではまだ対応できてないので、やむを得なくAWTのFileDialogを使う必要がありました。以下がその実装の例です。 // 選択したファイル名を状態として保持するvar fileName by remember { mutableStateOf("") }// AWTのファイル選択ダイアログを使うFileDialog(ComposeWindow()).apply { // 選択できるのはCSVのみにしたい setFilenameFilter { _, name -> name.endsWith(".csv", ignoreCase = true) } isVisible = true // ファイルが選択された場合は状態を更新する if (!file.isNullOrBlank()) { fileName = file } }しかし、これでも十分ではない場合もありました。フォルダのみを選択できるようにしたい場合にFileDialogはあまり良い選択ではなかったのです。名前からそうですが、あくまでファイルの選択を想定したものであるため、フォルダのみを選択できるようにはできなかったのです。なので、フォルダのみを選択できるようにするためには、Swingの力も借りる必要があります。その場合は、以下のように実装ができます。// 選択したフォルダのパスを状態として保持するvar selectedPath by remember { mutableStateOf("") }// Swingのファイル選択ダイアログをディレクトリのみ選択できるように設定して定義するval fileChooser = JFileChooser().apply { dialogTitle = "Choose Directory" fileSelectionMode = JFileChooser.DIRECTORIES_ONLY }// ダイアログを表示するif (fileChooser.showOpenDialog(ComposeWindow()) == JFileChooser.APPROVE_OPTION) { // ダイアログで選択したパスが状態として保持しているパスと違う場合、選択したディレクトリの絶対パスを状態として更新する val path = fileChooser.selectedFile.absolutePath if (selectedPath != path) { selectedPath = path }}今回はこの二つユースケースのみSwingやAWTが登場していませんでしたが、どんなアプリを実装するかによって他のAPIも色々と使う必要性が出てくるかも知れないという良い一例になっている気がします。まだComposeはリリースされて1年ほどしか経っていないので、今後のバージョンアップでより多彩なWidgetが追加されることに期待ですね。ビルドComposeを選んだ理由の一つのバイナリのビルドができるという点ですが、これはかなり満足度が高かったです。gradleを使って、コマンドひとつで実行可能なバイナリが生成されます。Macでビルドして見ると、他のアプリと同じくパッケージが生成されます。中を見ると、実行に必要なJREと依存関係のJarが含まれていて、ネイティブではなくJVM上で起動される構造になっていました。バイナリをビルドするときのオプションには色々なものがあり、OSの種類(Windows, Mac, Linux)によって違うアイコンを使ったり、基本的には含まれないモジュールを含むように指定したりすることができました。以下が実際のビルド時のオプションのサンプルです。compose.desktop { application { mainClass = "com.testtool.MainKt" // 実行時のメインクラスを指定 nativeDistributions { packageName = "Test Tool" packageVersion = "1.0.0" modules("java.sql", "java.naming") // デフォルトでは含まれないパッケージを追加 macOS { iconFile.set(project.file("misc/appicon/icon-mac.icns")) } windows { iconFile.set(project.file("misc/appicon/icon-win.ico")) } } }}ただ、ビルド時は注意が必要です。ビルドするとき、Composeでは内部的にjpackageを使うので、まずJava 15以上が必要となります。また、CPUのアーキテクチャによって違うJDKをインストールするようになっているため、ビルドするマシンと違うのアーキテクチャのCPUを使っているマシンをターゲットにすることはできません。つまり、自分の使用のMacだとApple Silicon用のバイナリが生成され、IntelチップのMacだとx64用のバイナリが生成されるということです。実際ComposeでApp Storeにアプリを提出した人もいるらしいのですが、Rosettaで起動できるということでIntelチップのMacを使ってビルドしているとのことでした。Universal Binaryを作りたい場合は、JDKそのものがまずUniversal Binaryとして提供されることを待つしかなさそうです。最後に今回はデスクトップアプリの中でもかなり制限された機能と単純なロジックしかないシンプルなものを作ったので、もしこれからまたComposeを使ってさまざまな機能を持つように実装するとしたら(マルチウィンドウやダークモード対応、ナビゲーションなど)また色々と発見があるかも知れない気がしています。個人的にはかなりためになる経験で、思ったより実装もそこまで難しくなかったので、ツールの機能を拡張するか新しいツールを作ってみるチャンスがあるとしたら再度Composeを使ってみたいなと思いました。まだリリースされてからそう長くもなく、足りない機能や情報も多かったり競合のフレームワークが色々とあるので未来はどうなるかわからないものですが、自分のようにKotlinをメインとしているエンジニアで、GUIに興味がある方なら一度はComposeを使って見ることをお勧めしたいですね。では、また！

Kotlinでデスクトップアプリを作ってみた

アプリを書いていると、DBに保存した形とは違う形でデータを読み込んだり出力するケースが多いです。代表的に、多くのバックエンドアプリで採用しているREST APIがそうですね。APIの入力値と戻り値は、DBに保存されている形とは一致しないケースが多く、必要(リクエストを送信してきた側の都合)に合わせて適切にパラメータを受け取り、レスポンスを返すようになっています。そして時と場合によっては、人間が楽に読める形としてデータをまとめる必要もあります。そういった場合はExcelファイルやCSV、PDFといったいろいろなものを想定できますね。今回のポストも場合も人が読める形のファイルとして、特にCSVを扱う場合にKotlin側の実装をどうやっていくかに関するものです。KotlinでCSVを扱うKotlinのCSV読み込み/書き込みのライブラリとしてkotlin-csvがあり、JVMだけでなくKoltin/JSの場合でもこのライブラリを使って簡単にCSVを扱えます。更にkotlin-grassというライブラリもあり、kotlin-csvとの組み合わせででCSVのデータを簡単にdata classのListとしてまとめることもできますね。読み込みの際に指定できるデータのフォーマットやカスタムマッピングオプションなどの機能も豊富にあり、かなり使いやすく良いライブラリとなっています。しかし、実はkotlin-csvを使うときに問題が一つあります。先に述べた通りCSVにデータの出力そのものは可能なものとなっているのですが、読み込みの時にdata classへのマッピングには別のライブラリが必要であったように、data classのリストを書き込むには追加の処理が必要となります。これは、kotlin-csvの書き込み用のメソッドが以下のようになっているからです。fun writeAll(rows: List<List<Any?>>, targetFile: File, append: Boolean = false) { open(targetFile, append) { writeRows(rows) }}ここでrowsが書き込みで使うデータとなりますが、型がList<List<Any?>>になっているので、列のデータを一つの行としてListに定義し、それをさらにListに格納することでCSVのデータ全体を定義する必要があります。これはつまり、data classのリストを書き込むためには、フィールド一つ一つを列として定義し、それらをListとしてまとめる必要があるということです。また、CSVには一般的にヘッダが含まれますが、List<List<Any?>>の形だと最初の行にヘッダのみを定義した行は必要となることでもありますね。一見複雑に見えますが、reflectionを利用すると、data classのフィールド名とその値を得ることができますので、それを利用してdata classのListをこのメソッドに適した形に変えられます。これをヘッダを作る方法と、data classの値を行に変更する二つの段階で分けて説明していきます。data classからヘッダを作るまずはヘッダを作ります。ヘッダを作るには、data classからフィールドを取得し、そのフィールドの名前のみを取得するといいでしょう。idというフィールドがあるとしたら、ヘッダもそのままidになるということです。フィールド名とは別の名前をつけたい場合はアノテーションを活用する方法を考えられますが、まずはフィールド名をそのまま使う方法から述べたいと思います。Kotlinのdata classから、フィールドを取得する方法が3つがあります。まずは、KClass.membersがあります。ただ、これだとメソッドを含め、全てのメンバーを持ってくることになります。以下のようにですね。data class Data(val id: Int, val name: String)val members = Data::class.membersprintln(members)// [val Line_2.Data.id: kotlin.Int, val Line_2.Data.name: kotlin.String, fun Line_2.Data.component1(): kotlin.Int, fun Line_2.Data.component2(): kotlin.String, fun Line_2.Data.copy(kotlin.Int, kotlin.String): Line_2.Data, fun Line_2.Data.equals(kotlin.Any?): kotlin.Boolean, fun Line_2.Data.hashCode(): kotlin.Int, fun Line_2.Data.toString(): kotlin.String]フィールド名が現れているのでこれも使える方法の一つではありますが、やはりdata classだと基本的にequals(), hashCode(), copy(), toString(), componentN()のようなメソッドができてしまうので、これらをフィルタする必要があります。例えば、以下のようにですね。val memberProperties = Data::class.members.filterNot { it.name.contains("component") || it.name == "copy" || it.name == "equals" || it.name == "hashCode" || it.name == "toString" }println(memberProperties)// [val Line_2.Data.id: kotlin.Int, val Line_2.Data.name: kotlin.String]しかし、フィルタをしなくてももっと簡単にフィールドのみを抽出できる方法もあります。memberPropertiesを使うことです。val memberProperties = Data::class.memberPropertiesprintln(memberProperties)// [val Line_2.Data.id: kotlin.Int, val Line_2.Data.name: kotlin.String]ただ、この方法にも問題はあります。取得したフィールドの順番が、data classに定義した通りにならなく、アルファベット順になるということです。以下の例を見ると、nameとageの順で定義したフィールドが、ageとnameの順になっているのがわかります。data class Person(val name: String, val age: Int)val memberProperties = Person::class.memberPropertiesprintln(memberProperties) // name, age順にならない// [val Line_11.Person.age: kotlin.Int, val Line_11.Person.name: kotlin.String]ここでどうしてもフィールドを定義した順に取得したい場合、data classのコンストラクタを使う方法があります。まずはコンストラクタを使った方法ですが、これはdata classに、自動的にコンストラクタがフィールドを定義した順番通りのパラメータを持つように生成されるということを利用した方法です。以下のようになります。val parameters = Person::class.primaryConstructor!!.parameters.mapNotNull { it.name }println(parameters) // [name, age]多少強引な方法ではありますが、これでフィールドとして使うフィールド名は取得できました。では、次にアノテーションを使う場合を見ていきましょう。アノテーションを使う場合フィールド名をそのままヘッダとして利用したくない場合は、アノテーションを活用できます。フィールドとしてStringを持つアノテーションを定義して、ヘッダを読み取るときにそのフィールドにつけたアノテーションを取得するという方法です。例えば、以下のようなアノテーションを定義したとしましょう。@Target(AnnotationTarget.PROPERTY)annotation class CsvHeaderName(val value: String)アノテーションは、以下のようにdata classで使います。data class Person( @CsvHeaderName("名前") val name: String, @CsvHeaderName("年齢") val age: Int)そしてこのdata classのアノテーションを取得していきます。memberPropertiesでフィールドを取得した場合、そのフィールドからアノテーションの一覧(アノテーションは複数存在できるので)を取得し、そこから先に定義したCsvHeaderNameのみをフィルタします。あとはアノテーションがあるかどうかをみて、どちらの値を使うかを決めればいいですね。以下のコードが、そのサンプルです。val datas = listOf(Person("John", 20))val headers = datas.first()!!::class.memberProperties.map { property -> val name = property.annotations.filterIsInstance<CsvHeaderName>().firstOrNull() // アノテーションはないケースもある name?.value ?: property.name // アノテーションがnullの場合は、フィールド名を使う }println(headers) // [年齢, 名前]primaryConstructorのパラメータで取得した場合でも、やり方は大きく変わりません。この場合は、コンストラクタのパラメータを基準にループしながら一致するフィールドを探すという処理が追加されるだけです。例えば以下のようにです。val fieldNames = seeds.first()::class.primaryConstructor!!.parameters.mapNotNull { it.name }val headers = fieldNames.mapNotNull { name -> // パラメータと一致するフィールドを対象に処理を行う datas.first()::class.memberProperties.find { it.name == name }?.let { property -> val headerName = property.annotations.filterIsInstance<CsvHeaderName>().firstOrNull() headerName?.value ?: property.name }}これで、ヘッダのデータはできました。次は、このヘッダに合わせて下に出力する行としてdata classをListに変換するのみですね。data classをListに変えるヘッダの処理で既にやっていたように、data classをListに変換する場合でも処理は大きく変わりません。違う点は、フィールドから実際のデータを取得するだけですね。ここでは、コンストラクタからパラメータを取得した場合を想定してコードを書きましょう。Kotlinのreflectionでフィールドの値を取得する場合はJavaと変わらなくて、取得したフィールドにdata classのインスタンスを渡すだけとなります。ただ、フィールドがnullの場合は考慮する必要があります。nullになってしまうと、その列自体がスキップされ、最終的に出力されたCSVのデータで列がずれる場合があるからです。なので、空白のStringを指定するなどで、行ごとの長さ(Listのサイズ)を合わせる必要があります。以下のようにですね。datas.map { d -> fieldNames.mapNotNull { name -> d::class.memberProperties.find { it.name == name }?.let { field -> field.call(d) ?: "" // フィールドの値を取得し、nullのばいは空白にする } } }ただ、ここで時間や日付を扱う場合、フォーマッタを利用したいケースがあるかと思います。例えば、アプリの中ではLocalTimeとして扱っているが、CSVとしてはHH:mmのような形で出力したい場合や、LocalDateをyy/MM/ddにしたい場合などですね。ここでフォーマット自体は、DateTimeFormatterを使うだけですが、問題は取得したフィールドがどの型であるかの判定です。Kotlinのreflectionで取得したフィールドは、KProperty1という型になっています。ここでどうやって元の型を取得するかが問題ですね。このクラスはKCallableというインタフェースを実装していて、ここにはreturnTypeというプロパティがあります。これでKTypeというインタフェースが取得できるようになるので、これを持って判定をおこ泣くことになります。しかし、名前から分かるように、KTypeはKotlinの型に関するインタフェースとなっています。比較したいLocalDateやLocalTimeなどのクラスはJavaのものなので、直接的な比較ができないですね。幸い、JavaのクラスでもKotlinで参照できるKtypeとして変換することはできます。以下のようにです。val localDateKType: KType = LocalDate::class.createType()なので、あとは分岐によって適切なフォーマッタを使うだけですね。以下のようにです。datas.map { d -> fieldNames.mapNotNull { name -> d::class.memberProperties.find { it.name == name }?.let { field -> field.call(d)?.let { when (field.returnType) { // タイプによる分岐 LocalDate::class.createType() -> dateFormatter.format(it as LocalDate) LocalTime::class.createType() -> timeFormatter.format(it as LocalTime) LocalDateTime::class.createType() -> dateTimeFormatter.format(it as LocalDateTime) else -> it } } ?: "" } } }ただ、ここでもう一つ注意しなければならないのは、nullableなフィールドのKTypeは別のものになるということです。つまり、上記のコードでは、以下のようなdata classのフィールドは分岐処理でフォーマッタが働かなくなるということです。// どのフィールドもフォーマットされないdata class DateTimes( val date: LocalDate?, val time: LocalTime?, val dateTime: LocalDateTime?)この場合は、KTypeを作るときにnullableであることを指定することで簡単に解決できます。あとは分岐で、両方チェックするようにするだけです。以下のようにですね。datas.map { d -> fieldNames.mapNotNull { name -> d::class.memberProperties.find { it.name == name }?.let { field -> field.call(d)?.let { when (field.returnType) { // nullableでもnullableではない場合でも分岐でフォーマットする LocalDate::class.createType(), LocalDate::class.createType(nullable = true) -> dateFormatter.format(it as LocalDate) LocalTime::class.createType(), LocalTime::class.createType(nullable = true) -> timeFormatter.format(it as LocalTime) LocalDateTime::class.createType(), LocalDateTime::class.createType(nullable = true) -> dateTimeFormatter.format(it as LocalDateTime) else -> it } } ?: "" } } }あとは、ヘッダと、data classから取得した値のリストを結合してkotlin-csvのwriteAll()に渡すだけですね。一つ、値は上記のコードで既にList<List<Any>>の形となっていますが、ヘッダはList<String>なので、ヘッダは更にListに入れる必要があります。// ヘッダval header = // 省略// 実際のデータval rows = datas.map { /** 省略 */ }csvWriter().writeAll( rows = listOf(headers) + rows, targetFile = targetFile )これでヘッダが先に行に書き込まれ、次の行からはdata classのフィールドに格納した実際の値が出力されることになりました。最後にこの度軽く「KotlinなんだからKotlin制のライブラリを使おう」と、軽い気持ちで採用したライブラリが想定していたものと違ったので困っていましたが、幸いJavaを使っていた時にApache POIを使って似たような機能をするライブラリを作ってみた経験があったのでその知識を活かせたと言えます。当時はまだ駆け出しのエンジニア(今もそうと思っていますが)だったので大変苦労した思い出でもありますが、今はその経験があってこそ対処できたようなものなので大変ありがたい経験だったなと思いました。上記のコードに対してはちょっとしたライブラリを作ってみたので、またどこかで活用してみたいものですね。色々と改善して、のちにMaven Repositoryのようなところでも公開できるようになったらなと思います。では、また！

data classのListをCSVにする

SwiftUIを触ってみた〜その2〜

今までの自分のキャリアを振り返ってみると、仕事としての経験はバックエンドばかりで、画面側の実装にはあまり関わったことがありません。しかし、スタンドアロンのアプリを作るためには、ウェブ・モバイル・デスクトップを問わず画面が必要となるので、いつかは画面側の実装もできるようになる必要があるかなと常に思っているところです。画面を作るといっても、どんな分野のエンジニアとしてキャリアパスを考えているか、どのような企業で働きたいか、慣れている言語は何であるかなど色々と考慮すべき要素は多いのですが、自分の場合はKotlinに慣れているのもあり、ウェブ・モバイル・デスクトップアプリに全部対応できるという点からJectpack Composeを、また普段からMacとiPhone、iPadといったApple社の製品をよく使っている上、KotlinからのSwift入門が比較的簡単ということでSwiftUIを勉強したいと思っています。さて、言語とフレームワークを決めてからは実践ですね。公式のチュートリアルが充実していたので、まずはこちらの方をすすめながら感じたSwiftやSwiftUIで印象的だった部分についてまとめてみたいと思います。もちろん、自分は仕事としてモバイルアプリの実装に関わったことがないのでコンテンツとしては粗末なものとなるかなと思いますが、もし自分のようにKotlinのバックグラウンドからSwiftに触れてみようと思っている方や、バックエンドのみのキャリアからGUIに初めて触れる方、もしくはKotlinとSwiftのどちらかに興味を持っている方には参考になる内容となればと思います。Swiftまずは言語そのものから。KotlinとSwiftはよく似ているという話を聞くことがありますが、正確に「どこが」というのはやはり触れてみる前はわからないものです。似ているという表現は共通点があるという意味なので、何に基準を置くかによって挙げられる共通点は色々と変わってくるものだからです。例えば、言語デザインの観点でOOP志向的で、関数型的な要素があり、GCが存在する、ということでも共通点は発見できます。もしくは、言語の使用としてキーワードや書き方の印象が似ているという意味にもなれますね。細かくは、セミコロンを使わなくて良いという点も挙げられますね。なので、まずは上記のチュートリアルを進行しながら、肌で感じた感覚から、Kotlinに比べたSwiftはどのようなものだったかを述べていきたいと思います。Kotlinに似ているものでは、まずKotlinに似ているなと感じたところから述べていきます。似ているとしても、あくまで「肌の感触」なものなので、厳密には違う仕様になっているものも多いのですが、ここでの基準は「Kotlinでできたことをどれほど近い感覚で再現できるか」となっていますので（といっても個人的な感想ですが）、参考までに。Computed propertiesまず、プロパティの話からです。Kotlinではdata classを定義するとき、プロパティを以下のような二つの方法で定義することができます。data class Student( val age: Int) { val isAdult: Boolean get() = age >= 18}ここでageはインスタンスを作成するときに固定される単純な値となりますが、isAdultはgetterとして定義した処理(ageが18以上かどうかという)の結果を返すように定義する形ですね。このような処理を伴うプロパティは、Swiftでも同じくComputed Propertiesを通じて定義することができました。同じような処理を行う場合、以下のように定義できます。struct Student { var age: Int var isAdult: Bool { get { return age >= 18 } }}まだ一つしたあげてないのですが、これだけでもなんとなく「KotlinとSwiftが似ている」の意味が少しは見えてきた気がしますね。処理を伴うプロパティを扱える、という仕様がそうですが、型の定義もそうで、キーワードは少し違うけど大体似たような感覚でコードが読めるというところがそうです。ただ、やはり違う部分もありますね。data classに対して、SwiftはGoやRustのようにstructを使えるというところがそうかなと思います。もちろんSwiftにもClassはあるので、目的によってどれかを選ぶようになるらしいです。という面では、またなんとなくKotlinでdata classとclassを分けて使うという点と似ているような気もしますね。Extension次は、拡張です。Kotlinではオブジェクトについて、そのオブジェクトの外にメソッドやプロパティを定義することができますね。これらを拡張関数や拡張プロパティと呼び、以下のように定義することができます。val Student.isUnderAge: Boolean get() = age < 18以前このブログでも述べたことのあるEffective Kotlinで提示されている活用方法ですが、ユースケースやドメインによって違う処理が必要となった場合は、class内に全てのメソッドやプロパティをを定義するよりはこのような拡張を使って、パッケージごとに定義することでアクセス制限を設ける方法があります。同じようなことがSwiftでもできますが、書き方はやはり少し違いました。上記のようなプロパティをSwiftで同じ方法で実装する場合、以下のようになります。extension Student { var isUnderAge: Bool { get { return age < 18 } }}上記のようにSwiftにはExtensionが別途キーワードとして存在していて、新しくclassやstructを定義するかのような感覚で関数やプロパティを付け加えることができます。個人的な感想としてはRustのメソッドと似ている形で、一つのextensionの中にまとめられるところがむしろKotlinより整頓された感覚なので良さげですね。Kotlinの場合、一つのオブジェクトに対しての拡張が複数あると少し汚くも見えるので…String InterpolationJavaの場合でもそうで、多くの言語では文字列と、違う変数として格納してある値を一つの文字列にまとめる場合はformat()を使うか、文字列に変換して結合するケースが多いかなと思います。Kotlinでもそのような使い方はもちろんできますが、String templateがあるので、簡単に文字列の中で違う値を埋め込むことができます。例えば以下のようなものですね。val world = "World"println("Hello, $world")SwiftでもString Interpolationがあるので、同じことができます。少し書き方が変わっているのですが、機能的にはほぼ一緒です。let world = "World"print("Hello, \(world)!")ArgumentsKotlinでは、関数のパラメータにデフォルト値を設定することで、簡単にオーバーロードを実現でき、そのパラメータが渡されてない場合の処理にも対応できます。// timesに指定した数値分、stringを標準出力するfun printHello(string: String, times: Int = 1) { repeat(times) { println("Hello, $string") }}printHello("world") // timesに値を指定しなくても関数を呼び出せるまた、どのパラメータに値を指定したいかを明確にするときや、関数に定義されたパラメータの順番に関係なく値を指定したい場合など色々な場面でNamed Argumentsを使うことができますね。例えばjoinToString()にはseparator、limit、truncatedなど6つのパラメータがあるのですが、デフォルト値が指定されていて、Named Argumentsにより以下のような使い方が可能です。listOf("A", "B", "C", "D").joinToString(prefix = "[", postfix = "]")Named ArgumentはKotlinにおいてはオプションで、基本的にはJava同様、関数に定義されてあるパラメータの順番に合わせて値を渡すだけでも問題ありません。しかし、Swiftではこれが逆になっていて、sturctのインスタンスを作る場合や関数を呼び出す場合は基本的にパラメータは基本的にNamed Argumentsのような形で渡す必要があります。これをArgument Labelと読んでいるそうです。func printHello(string: String) { print("Hello \(string)!")}printHello(string: "world") // Function Argument Labelでstringを指定ただ、これもKotlinと同様、デフォルト値を指定することができ、その場合はパラメータを省略することができます。func printHello(string: String, times: Int = 1) { var count = 1 repeat { // Kotlinのdo-whileループ的なもの print("Hello \(string)!") count += 1 } while (count <= times)}printHello(string: "world") // timesを省略している他にも、アンダースコアを使うことでArgument Labelを省略できるようにもなります。func printHello(_ string: String, times: Int = 1) { var count = 1 repeat { print("Hello \(string)!") count += 1 } while (count <= times)}printHello("world") // stringを省略関数を定義する側からしたらあまり似ていないような気もするのですが、呼び出す側としてはかなり似たような形でコードが書けるのが特徴的かなと思います。RangeKotlinではrangeTo()を使って、簡単に数値の範囲を定義することができます。この関数はoperatorとして定義されているので、..で簡単に使えます。こうやって定義したRangeでは、最小値と最大値の取得や、Listに変換するなど色々なことができます。// Rangeの定義val min = 10val max = 20val range = min..max// 最小値と最大値の取得println(range.start) // 10println(range.endInclusive) // 20// RangeをListにするval intList = range.toList() // [10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]SwiftでもRange Operatorを使って範囲を定義することができます。こちらも形は似ていて、...となります。ドットの数がKotlinより一つ多いという点を除くと全く同じ感覚で、最小値と最大値もまた名前が違うだけでプロパティとして取得できるという点もまた一緒です。// Rangeの定義let min = 10let max = 20let range = min...max// 最小値と最大値の取得print(range.lowerBound) // 10print(range.upperBound) // 20// RangeをArrayにするlet array = Array(range) // [10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]ただ、上記のコードを見ると気付きにくいところですが、Range実装については両言語での扱いが少し違うところがあります。KotlinではrangeTo()の戻り値が、元の値の型に合わせてInteRangeやLongRangeのようなものとなっていて、最小値と最大値をプロパティで取得する場合もrangeToに渡された二つの値の型と一緒です。しかし、SwiftのRangeはRange<Bound>という型で、当然Rangeから取得できる最小値や最大値もBoundの型となっています。IntやLongとはまた別の型になるので、場合によっては注意して使う必要があるかもしれません。Swiftだけのもの今まではKotlinユーザの観点から、Kotlinとどれだけ同じ感覚でコードを書けるか、ということを述べていましたが、ここからは少し間隔が違うなと思ったところを少しまとめてみようと思います。メソッド・プロパティコールでの省略Kotlinでは、apply()のように自分自身を指しているのが明確な場合、thisを省略することができます。以下のようにですね。data class Student( val name: String, var age: Int = 0)val studentA = Student(name = "A").apply { age = 18 } // Student(name=A, age=18)このように、thisを使う場合か、明確に対象importしているなど特定のケースを除くとKotlinでは基本的にClass.method()のような形でどのクラスのメンバを呼び出しているかを表記するのが原則ですね。しかし、Swiftの場合は少し状況が違います。もっとゆるい感じで、コンパイラを基準に対象が明確であれば、.method()のような形で省略できるような感覚です。以下はSwiftUIのチュートリアルで提示しているコードの一部を抜粋したものですが、filterがFilterCategoryというenumであるため、.allという形で三項演算子の中で使われていることを確認できます。struct LandmarkList: View { @State private var filter = FilterCategory.all enum FilterCategory: String, CaseIterable, Identifiable { case all = "ALL" case lakes = "Lakes" case rivers = "Rivers" case mountains = "Mountains" var id: FilterCategory { self } } var title: String { let title = filter == .all ? "Landmarks" : filter.rawValue return showFavoritesOnly ? "Favorite \(title)" : title }}ProtocolSwiftではProtocolというものがあり、JavaやKotlinのinterfaceと大体同じ感覚で使えます。ここまでだとあまり差はないように思いますが、実際にはstructやclass、enumなどを定義するときには、必要に応じでprotocolを採用(adopt)する必要があるというところが体験できる違いかなと思います。例えば、Kotlinで一つのdata classを定義するとしたら、以下のようなメンバが自動て追加されます。equals()hashCode()toString()componentN()copy()しかし、Swiftのstruct, class, enumなどにはこのようなメンバは基本的に追加されません。なので、必要なメンバがあればそれに関するprotocolを採用し、実装する必要があります。例えばハッシュ値が使いたい場合はHashable、Jsonなどに変換するためにはCodable、Listでループしたい場合はIdentifiable、enumの全ケースを網羅してループしたい場合はCaseIterable、同一化を比較したい場合はEquatableを採用するなどです。もちろんJavaやKotlinでも必要に応じてintefaceやannotationを使う必要はありますが、SwiftだとKotlinで気軽に使える機能がstructやclassなどを定義した時点では揃ってない可能性があるので、ここは気をつけるべきところですね。someSwiftでは少し変わった感覚のキーワードがあるます。そのキーワードの説明するために、まずは以下のようなprotocolとstructの定義があるとしましょう。protocol Something { func define()}struct GoodThing: Something { func define() { print("It's good thing!") }}上記のようなコードがある場合、変数の型宣言や関数の戻り値で少し独特なキーワードを使うことができます。someというものです。実際使う時は、以下のようなコードとなります。var good: some Something = GoodThing()func returnSomething() -> some Something { return GoodThing()}これだけではsomeというキーワードが一体どんなものかわからないですね。ここでKotlinの概念を持ってくるとどうでしょうか。実は、Kotlinでもこれによく似た機能があります。<T extends Something>です。KotlinやJavaの経験がある型ならこれで十分に何を意味しているかがしっくり来るかなと思います。つまり、someはとあるprotocolを満足する何かしらのインスタンスを示すものです。Swiftではそれを満足するオブジェクトであってもprotocolを直接変数の型や関数の戻り値として定義して直接使うことはできない場合があります。その場合にsomeを使うことで問題を回避できます。JavaやKotlinでinterfaceを使って、その具体的な実装は問わなく使うのと一緒だと言えます。このキーワードのおかげで、SwiftUIではViewを満足して入れば画面を構成するどんなコンポーネントとして扱えるようになります。ただ、interfaceを扱うのとは概念的に同じだとしても、コードを書く側の感覚としては全く違うのでここは注意しなければならないと思います。Compiler Control StatementsSwiftにはCompiler Control Statementsという仕様があり、コンパイル時の処理を指定できます。例えば、SwiftUIのチュートリアルでは一つのアプリを実装して、OSによって違う機能を実現するためにこれを利用しているケースがあります。以下がその例です。// watchOSで起動する場合は、通知を使う#if os(watchOS)WKNotificationScene(controller: NotificationController.self, category: "LandmarkNear")#endif// macOSで起動する場合は、設定を使う#if os(macOS)Settings { LandmarkSettings()}#endifKotlinの場合もAndroidでアプリを実装する場合はこのような設定が必要になる場面もあるかもしれませんが、バックエンドの経験上ではコードによりコンパイラをコントロールするというケースはあまりなかったので、かなり新鮮な感覚でした。最後にいかがでしたか。SwiftUIの話をするつもりが、Swiftのことだけでかなりの量になってしまったので、SwiftUIについては次のポストで述べようかなと思っています。しかし、Swiftだけでもかなり興味深いところが多かったので、やはりチュートリアルを触ってみて色々な経験ができたので良い選択をしたかなと思います。また、やはりKotlinとSwiftがなんとなく似ている部分があるのは感覚的には確かなので、やはりどちらかの経験があると残りの片方への入門もしやすくなるのかなという感覚はあります。これは外国語の教育（自分の専攻です）でいうスキーマ、いわゆるバックグラウンドの知識ある故のことだろうなと思うと、少しうれしくもなりますね。やはりKotlinやってよかったなと思います。では、また！

SwiftUIを触ってみた〜その1〜

この度はProfessional Cloud Developerの資格を取得しました。去年は特に資格を取得してないので、久々の資格取得となります。今までは主にAWSを使っていたので関連した資格を取得するのが良いかなと思っていましたが、GCPのサービスがもっと知りたいというのもあり、AWSの資格と比べどう違うかも気になったための受験となります。前回もそうであったように、無事資格の取得ができましたので、今回のポストではどのように試験の準備をしたかなどについて簡単に述べたいと思います。試験はどんな感じか以前、AWSの資格に関する記事を書いたことがありますが、プロバイダが違ってもCloudというプラットフォームが提供するサービスの根本は変わらないので、試験もまたそのような感覚です。基本的にIaaSやPaaSのようなサービスの概念や、バックエンドサービスのクラウドでのデプロイと構成の経験があれば試験の準備はそう難しくないかなと感じました。受験は遠隔監視とオンサイト監視の二つを選べ、前者は自宅での受験、後者はテストセンターでの受験となります。自分の場合はオンサイト監視が平日しか選べなかったため遠隔監視を選んでいます。AWSの試験の時もそうでしたが、遠隔監視の場合は受験できる部屋の準備をきちんとする必要があります。準備に必要なものはKRYTERIONのサイトに明示されているので、事前にチェックした方が良いです。個人的にはこの要件に合わせて部屋を片付けるのもかなり大変なものだったので、オンサイト監視の方が楽だろうと思いました。遠隔監視での試験はKRYTERIONが提供する専用のブラウザを使って進行します。ブラウザが起動すると他のアプリは最小化され、外部モニタを繋いでいる場合はそのモニタの画面が黒くなります。私の場合はApple Silicon Macを使っているので互換性の方が気になりましたが、問題なく実行できました。システムチェックのサイトも提供しているので、自分のPCで受験できるかはこちらでも確認したほうが良いでしょう。また、生体認証情報の登録が必要となりますが、こちらは単純に写真を撮るだけです。当日は試験が始まる前に登録した生体認証を確認し、監視官の指示の元に部屋の様子を見せたり身分証明書を提示するなどの簡単な手続きがあります。他の資格の場合はその場や当日で結果がわかるケースも多かったかなと思いますが、GCPの資格は認定のメールが届くまで1週間ほどの時間がかかっています。満点や得点がわからないという特徴を踏まえて考えてみると、受験当時のさまざまな状況を考慮して総合的に判断するのではないかと思っています。受験専用のブラウザを使うことになっているので、おそらくキー入力やカメラの映像なども全部録画されていたのではないかと思います。どうやって準備したかまずはUdemyから模擬試験を検索してみました。中には英語になっているものと日本語版がありますが、どれもレビューに書いてある通りで、実際のテストと比べ簡単な問題が多いです。自分の場合は5回分を提供する英語の方を4周してどれも8割以上の正解を記録しましたが、本番ではより難しい（模擬試験では問われてないものやより複雑な）問題が多かったため、これだけでは不十分と思いました。模擬試験は公式の方もあり、こちらは比較的に実際のテストに近い問題が多いので（こく一部ですが、ほぼそのままの問題もあります）こちらの方を問題で問われる各サービスのドキュメントを調べながら勉強した方が良いかなと思います。模擬試験の他にはKubernetesの問題が多いという情報があり、実際に使ったことがなかったのでそちらを中心に色々調べたことが多かったです。そのほかはテストやデプロイの概念（Blue-Greenやカナリアなど）を一度チェックしているくらいです。何を問われるかHipLocalのケーススタディを参考にして準備をした方が良いです。HipLocalに関する問題自体は全体の割合として高くないものの、このケーススタディを用いた問題の場合は、模擬試験で問われる問題以外でもいろいろなパターンがありますので試験の前にケーススタディに合わせてどうやってマイグレーションを行ったらいいかをGCPのサービスと照らし合わせながら確認した方が良いかと思います。一つ、HipLocalのケーススタティを全て覚えておく必要はありません。個人的にはここがかなり気になっていたところなのですが、実際のテストではブラウザの右側にケーススタディが提示されていたのでそれを参考して問題を解くことができました。ブラウザに表示された内容ではHipLocal以外のケーススタディが提示される可能性もあるように書いてありましたが、おそらく他のテストでも似たようなパターンの問題があるためそのような記述があるのかなという感覚です。問われる問題の範囲や詳細に対しては他のブログでも見つけることができ、自分としては詳細までは覚えてないので詳しくは述べませんが、やはりKubernetesに関する問題が多い感覚で、次にはストレージやサーバレスに関する問題が多かったかなと思います。そのほか、印象に残ったものはAnthosやistioが言及された問題があったことです。どちらも名前しか聞いてないくらいだったので、その問題に対しては正解となっているかどうかすらわかりませんでした。受かったあとはGoogle Cloud Certification Perks Webstoreから特典をもらえるコードがメールで送られてきました。もらえる特典の種類は随時変わるらしく、他のブログではBluetooth Speakerなどをもらえると書いてありましたが、私の場合は以下から選ぶようになっていました。私はジッパーフードの方を選びたかったのですが、今回はサイズを2XLしか選べなかったので、今回はジッパーのない方を選んでいます。欲しいものが特になかったら、寄付できるオプションもありますのでそちらを選んでも良いかもですね。資格の認証はAccredibleというサイトから確認できます。こちらのサイトではAWSやOracleの資格をCredlyで確認できたように、認定の証明をサイトにリンクできたり、Linkedinなどに共有できる機能があります。認定書はPDFとしてダウンロードもできました。一つ、AWSの場合は資格の有効期限が3年となっていましたが、GCPの場合は2年となっていました。クラウドだとやはりサービスの仕様が変わることも多く、新しいサービスが導入される場合も多いので有効期限を設けていること自体は当たり前とは思いますが、勉強すべき量と受験料($200)を考えると少し短い感覚です。最後に受験後に模擬試験とあまりにも違う問題が多かったため今回こそ落ちたのではないかという不安があり、のちに合格したというメールを受けてもやはり実感があまりありませんでした。ただ、それはあくまで自分が模擬試験で問われるもののみを覚えていただけなのが原因な気もします。実際の問題は問題と選択肢を注意深く読むことで正解が見えてくるものもあったり、GCPのドキュメントを確認していたらわかるようなことも多いので、まずは公式の認定資格ガイドに提示されてある内容を中心に各サービスのドキュメントを一読することをお勧めします。模擬試験はあくまで模擬試験なので、良い点数が取れたからと油断したら落ちる可能性も十分にあり得るのではないかと思います。問題の難易度に関しては、やはりどうしても自分が以前取得したAWSの資格と比較してしまいますが、そちらはアソシエイトレベルのものだったため、こちらの資格の方が難しい感覚ではありました。個人的には合格してからも本当にプロフェッショナルを名乗るにはより勉強が必要なのではないかという気がするくらいでした。ただ、普段からGCPのサービスを色々と利用してオンプレからのマイグレーション経験がある方ならそこまで難しくないのかもしれませんので、油断だけしないなら、十分受かる資格なのではないかなと思っています。では、また！

Google Cloud認定Professional Cloud Developerについて

BackendでCoroutineを使う

Kotlinのこれからを語る

最近友人がYoutubeのチャンネルを始めました。主に海外のYoutubeのチャンネルにアップされてあるドラマのメイキングやインタビュー動画などに字幕をつけて配信するというチャンネルですが、そこで毎回字幕を作るのはかなりめんどくさい作業なので、ちょっとしたコマンドaliasとして作成して提供することにしました。元の動画には原語の字幕がついていて、編集用ツールでそれを読み込むことができるらしいので動画だけでなく字幕もダウンロードするコマンドを作成しています。これなら翻訳した字幕ファイルを編集ツールで読み込んで使えるので、かなり作業量が減りました。ただ、チャンネルの登録者数が増えながら、中には色々な国からの人もいたようで、友人から「自動翻訳を使って多国語の字幕を追加できる手段が欲しい」という依頼が来ました。簡単なツールを作れば良さそうだったので、早速ツールを作って公開することになったので、今回はそのツールを作った話をしたいと思います。設計まずは友人の要望と、技術スタック、アプリの基本設計を行いました。といっても、複雑なことはあまりしたくなかったので、（友人の）やりたいことをベースに、自分がやってみたいことを混ぜたくらいのレベル感です。字幕youtube-dlやyt-dlpを使ってYouTubeの動画をダウンロードする際、元の動画に字幕がついてある場合はオプションを追加することで字幕も落とせます。Youtubeで字幕をダウンロードすると、多くの場合ファイル形式がWebVTTになるので、とりあえず.vtt形式のファイルに対応する必要があると思いました。他のフォーマットまで対応するには時間がかかりそうだったので、まずはこれのみにします。幸い、実際の字幕ファイルを落としてみたところ、フォーマットはシンプルで(SubRipとほぼ一緒)、翻訳は字幕が表示される時間の次の行の文字列と、その行のインデックスとともに取ればなんとか入れ替えができそうな気がしました。実際のファイルは以下のようなフォーマットで作成されています。WEBVTT00:01.000 --> 00:04.000液体窒素を絶対に飲まないでください。00:05.000 --> 00:09.000- それはあなたの胃に穴をあけます。- あなたは死ぬ可能性があります。言語翻訳API翻訳についてはGoogle翻訳もありますが、友人の要請によってPapagoを使うことにしました。幸いAPIを無料で利用できて、PythonのサンプルコードやAPIの詳細も提供されていたのであまり利用は難しくはい感じでした。事前にPostmanでAPIを実行してみてからこちらを採用することにしました。技術まずPythonで作ることにしました。この規模の小さいアプリは、Kotlinがメインの私でもPythonで書きたいと思っています。JVMだと起動が遅くなるのもあり、テキストを扱うだけでCPUの処理がクリティカルな作業でもないためパフォーマンスを考慮する必要もあまりありません。そして既にPythonでファイルを読み込んだり、ファイルを編集するなど色々とCLI用のツールを作っていたので「ファイルを読み込んで、編集して、保存する」という最重要の機能がすぐに実装できそうと思いました。ただ、自分が使うものならCLI上でも十分使えますが、友人が使うものなのGUIを実装することにしました。Pythonは.pyファイルで渡すと、Pythonとスクリプトのdependencyのインストールが必要となるなどエンジニアではない人が触るには不便なところがあるので、成果物はPyInstalerなどで実行できるバイナリにします。GUIに関してはPySimpleGUIを使ったことがありますが、今回は違うフレームワークを使ってみたいと思いました。PythonのGUIフレームワークといえばtkinterやKivy、wxPython、Libavgなど様々なものがあるのですが、中でもQtがPythonだけでなく色々と使われているので、PythonのコードだけでなくC++のコードでも参考できる例が多いのではないかと思いPyQtの方を選びました。プロダクションレベルのものを作るならまた色々と基準を持って検討してみたかもしれませんが、このような趣味レベルのコードを書く場合はなるべく手軽に書ける、サンプルの多いものを選ぶのがちょうど良いかもですね。効率というのも大事なので。コードファイル読み込みまずはファイルを読み込むところから始めます。.vttファイルはヘッダーに字幕の情報（言語コードなど）が書かれていて、その次からは字幕が表示される時間と字幕の文字列が繰り返されます。素直に全行を読み込んでも良いかもですが、翻訳のAPIを呼び出すときに一日で利用できる文字数の制限というのがあったので、極力リクエストにのせるデータは減らしたかったです。なので、後で入れ替えするためのもとのファイルのデータと、翻訳のためAPIのリクエストパラメータにのせる二つのデータにわけで読み込むようにしました。いかがそのコードです。# get original contents from vtt filedef get_content(self, file_path: str): exported_contents: dict[int, str] = {} global source with open(file_path, 'r') as file: original_contents: list[str] = file.readlines() for index, line in enumerate(original_contents): content = line.strip() if source == '' and 'Language:' in content: source = content.split(':')[1].strip() if '-->' not in content and content != '': exported_contents[index] = content return original_contents, exported_contentsAPIのパラメータには元の言語(source)と、翻訳したい言語(target)が必要となるので、Global変数として字幕のヘッダにある言語情報をsourceに格納、翻訳したい行はインデックスと文字列をdictionaryとして格納します。そして最終的に元のデータと、翻訳対象のデータを返します。翻訳APIの呼び出し抽出したデータのうち、翻訳対象のデータを渡してAPIを呼び出す部分です。APIには「1秒当たり10件のリクエストを許容」するという制約があり、翻訳した文字列を一行づつ送って翻訳してもらいながら、リクエストごとに120msを待つようにしました。基本的にはRequestsを使ってPOSTしているだけですが、もしエラーが返ってきたときはalertを表示してアプリを即終了するようにしています。# send translate request to papago and get translated messagedef send_request(self, contents: dict[int, str]): translated_contents: dict[int, str] = {} headers = { 'X-Naver-Client-Id': client_id, 'X-Naver-Client-Secret': client_secret, 'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8' } for index, content in contents.items(): payload = { 'text': content, 'source': source, 'target': target } response = requests.post(api_url, headers=headers, data=payload) if response.status_code == 200: body = response.json() translated_text: str = body['message']['result']['translatedText'] translated_contents[index] = translated_text # wait for API's limitation(only 10 request per second allowed) sleep(0.12) else: msgBox = QMessageBox().critical( self, 'Error', response.json()['errorMessage'], buttons=QMessageBox.StandardButton.Abort ) if msgBox == QMessageBox.StandardButton.Abort: sys.exit(255) return translated_contentsファイルの保存ロジックとしてはここが最後です。元のファイルのある場所に翻訳された字幕ファイルを保存するために、元のファイルのパス、翻訳したものに入れ替えるための元のデータ、そしてAPIで翻訳した結果のデータを渡します。基本的に翻訳したデータにはインデックスがkeyとして入っているので、そのキーを持って元のデータを入れ替えていきます。ここでヘッダには元の言語のコードが入っているので、翻訳した言語のコードに入れ替えます。そしてファイル名にも同じく言語のコードが入っているので、これもまた変えておきます。全てのデータが入れ替えられ、ファイル名を決めたら保存して終了です。# write translated contents to filedef write_result(self, file_path: str, original_contents: list[str], translated_contents: dict[int, str]): contents = original_contents.copy() for index, content in translated_contents.items(): if 'Language:' in content: contents[index] = content.replace(source, target) + line_separator else: contents[index] = content + line_separator root = os.path.dirname(file_path) file_name = os.path.basename(file_path).replace(source, target) target_file_path = os.path.join(root, file_name) with open(target_file_path, 'w') as file: file.writelines(contents)ファイルドロップダウンせっかくGUIを使っているので、QListWidgetにファイルをDrag & Dropすると勝手にファイル名が画面に表示され、翻訳対象にもなるようにしたかったです。ここはあまり自分がQtに詳しくないので、ネットで検索したものを流用しました。基本的にはファイルをDrag & Dropすると、拡張子が.vttの場合にリストに追加されます。ここでファイルのフルパスを得ることができるのですが、画面上はファイル名だけを見えるようにして、フルパスは別のグローバル変数に格納するようにしています。# drop down file listclass FileListView(QListWidget): def __init__(self, parent=None): super(FileListView, self).__init__(parent) self.setAcceptDrops(True) def dragEnterEvent(self, event): if event.mimeData().hasUrls: event.accept() else: event.ignore() def dragMoveEvent(self, event): if event.mimeData().hasUrls: event.accept() else: event.ignore() def dropEvent(self, event): if event.mimeData().hasUrls: event.accept() for url in event.mimeData().urls(): file_path = url.toLocalFile() if file_path.endswith('.vtt') and str(file_path) not in original_files: # add file path to list original_files.append(str(file_path)) # add file name to file list view self.addItem(file_path.split('/')[-1]) else: event.ignore()ファイル削除リストにファイルを追加したら削除したい場合もあるかと思ったので、リストからファイルを選択してボタンを押すとリストから消えるようにしたかったです。これは以下のようなコードで実現しています。ボタンをクリックすると、リストで選択したものが消え、翻訳対象（フルパス）からも消えるようにしています。# create remove buttondef create_remove_button(self): button = QPushButton() button.setText('Remove file') button.clicked.connect(self.remove_file) return button# remove file from file listdef remove_file(self): global original_files for selected_item in self.list_view.selectedIndexes(): index = selected_item.row() self.list_view.takeItem(index) original_files.pop(index)言語選択元の字幕ファイルの言語はヘッダから抽出できるのですが、どの言語に翻訳したいかは自分で選べるようにしました。ここは翻訳APIの使用を参考にして、翻訳可能な言語のコードをdictionaryとしています。あえてdictionaryとしている理由は、QComboBoxのアイテムは画面に見えるものなので実際の言語名にしたかったからです。アイテムがdictionaryのキーとなっているので、選択したアイテムに対応するvalueが翻訳したい言語となるようにしています。# languagessupported_language_code: dict[str, str] = { 'Korean': 'ko', 'English': 'en', 'Japanese': 'ja', 'Chinese(China)': 'zh-CN', 'Chinese(Taiwan)': 'zh-TW', 'Vietnamese': 'vi', 'Indonesian': 'id', 'Thailand': 'th', 'German': 'de', 'Russian': 'ru', 'Spanish': 'es', 'French': 'fr'}# create drop down menudef create_target_language_selector(self): label = QLabel() label.setText('Select target language') selector = QComboBox() selector.addItems(supported_language_code.keys()) selector.textActivated.connect(self.set_target_language) return label, selector# set translate target language when dropdown menu selecteddef set_target_language(self, selectd: str): global supported_language_code global target target = supported_language_code[selectd]翻訳ボタン最後に翻訳ボタンを追加して、実際の翻訳はボタンを押下した時に行われるようにしました。ボタンを押すと、翻訳対象のファイルのパスをループしながらデータの読み込み、元の言語と翻訳したい言語が違うと翻訳APIの呼び出し、結果の保存という作業を行うようになっています。念の為処理が行われる間はこのボタンを非活性化するという処理も追加しています。# create translate buttondef create_translate_button(self): self.translate_button = QPushButton() self.translate_button.setText('Translate') self.translate_button.clicked.connect(self.translate_files) self.translate_button.setDisabled(False)# read vtt file and do translatedef translate_files(self): self.translate_button.setDisabled(True) for file_path in original_files: original_contents, exported_contents = self.get_content(file_path) if source == target: continue translated_contents = self.send_request(exported_contents) self.write_result(file_path, original_contents, translated_contents) self.translate_button.setDisabled(False)実際作ったツールで重要な部分は以上で、全体のソースコードはこちらから確認できます。改善したいこうやってとりわけ欲しい機能は実現できたのですが、まだ自分がPyQtに慣れてないのもあり、ロジック上でも少し改善したいところは残っていますので、いくつかを挙げてみました。テキストをまとめて翻訳する翻訳APIの仕様上、リクエストは1秒で10回となっているため、sleepを入れて一つのリクエスト毎に120msを待つようになっています。I/Oが発生することを考慮するともっと間隔を短くしてよかったかもしれませんが、そもそもの問題は、読み込んだファイルのデータから一行づつ翻訳のリクエストを送っているところです。短い動画でも字幕は数百行となるケースがあるので、こうなった場合は全体の翻訳が終わるまで処理にかなり時間がかかってしまいますね。なので、最初はリクエストパラメータに翻訳したいデータを全て送る（dictionaryのvalueを一つのstrにjoinして）方法も考えてみましたが、APIの仕様として明示されてないだけで、リクエストパラメータのサイズには制限があるようでした。だとすると、翻訳したいデータをいくつかのchunkに分けて送るという方法があると思いますが、こうなった場合は最後にファイルを保存するときに入れ替えるデータの行をどうやって判断するか、それをうまく処理するための方法が悩ましくなります。この処理のためファイルを翻訳するまでの時間がかなり長くなるので、いつかは解消したいものですが、翻訳した結果をうまくまとめて保存できる方法が思いつくまでは少し時間がかかりそうです。プログレスバーを追加する今の作りだと、シングルスレッドであるため、一つのファイルに対して処理が行われている間は画面が固まってしまうという問題があります。そもそも処理が遅いので、かなり長い時間を固まっていますが、これはUXの観点ではあまり良くないですね。また、処理がどこまで終わっているかもわからないので、プログレスバーを追加して、一つのファイルおよび全体のリストでどれぐらいの処理が行われているかを視覚化したいと思っています。ただ、プログレスバーを追加する場合、スレッドをわけ、さらに何を基準にプログレスバーを動いていくかというロジックを考えなければならないので、そこもまた時間がかかりそうですね。ボタンの非活性化翻訳対象のファイルが追加される前と処理の途中ではボタンを非活性化したいのですが、これもまだうまく実装されていません。処理中に画面が固まってしまうからか、処理の前後でボタンを非活性化するという処理も思い通りにならなかったのでこちらも直したいと思っています。最後に今回はGUIを中心に色々と新しいチャレンジができたので、かなり面白い作業となっています。そしてやはり元がサーバサイドだからか、UI/UXの観点では考慮しきれなかった問題が出てきたり、画面を実装するためにも色々と試行錯誤があったのでこれは良い勉強になっています。PythonとPyQtが優秀だったのでできたものなのですが、これをまたJetpack Composeなどで書き換えてみるとどうなるかなという好奇心もありますね。やはり、普段やってみてないことに挑戦してみるのは自分がエンジニアとして成長するための良い糧となるような気がします。では、また！

PyQtで字幕翻訳ツールを作ってみた

JavaとPython、そして少しのJavaScriptの経験してなかった私が、転職先でGoとKotlinを触って1年が経ちました。最近のプログラミング言語は大体収斂進化している傾向があるので、一つの言語ができれば大体他の言語もできる、もしくは読めるようになると言います。しかし、言語が違うということは、その設計思想が違うということなので、同じ結果を期待して書いたつもりのコードが全く思い通りにならないケースもあります。理由は大きく二つ、「あの言語ではこうだったから、この言語でもそうだろう」という慣性と「これはこの言語の特別な仕様だろう」という思い込みなのではないかと思います。（実際私がそうでしたが）というわけで、今回はJava/Kotlinをバックグラウンドとして持つエンジニアがGoを触るときの落とし穴的な部分を一部紹介したいと思います。あくまで個人的な経験によるものなのですが、これからGoでコードを書くことになる方には少しでも参考になればと思います。timeGoでは時間を扱うためのスタンダードライブラリとしてtimeが存在していて、以下のように使えます。// 現在時間を取得now := time.Now()// 時間を指定して取得(2022-04-01 12:30:00 +0000 UTC)someDay := time.Date(2022, 4, 1, 12, 30, 0, 0, time.UTC)Java/Kotlinだとこれに対応するAPIとしてjava.timeがありますね。Goと比べて違う点は、「時間」のみでなく、もっと細かい単位でクラスを分けているというところと言えますでしょう。// 年度Year year = Year.now();// 年月YearMonth yearMonth = YearMonth.now();// 年月日LocalDate date = LocalDate.now();// 時間LocalDateTime time = LocalDateTime.now();ただ、違う点はここだけではありません。当然ながら、言語が違うとライブラリの実装も変わってくるものなので、処理の結果も違うケースがありますね。代表的には、「月」単位の時間を扱う時、実装によってはGoでは意図通りの範囲にならないケースがあります。例えば以下のようなコードがあるとします。func getOneMonthBefore(t *time.Time) time.Time { // 月に -1 を指定して返す return t.AddDate(0, -1, 0)}一件なんの問題もなさそうなコードですが、一部のケースで以下のような問題が発生します。date := time.Date(2022, 3, 31, 0, 0, 0, 0, time.UTC)oneMonthBefore := getOneMonthBefore(&date) // 2022-03-03上記のコードの結果が「2月28日」でなく、「3月3日」になるのは、処理が以下のように行われるからです。2022-03-31から1ヶ月前の2022-02-31になる2022-02-31という日付は存在しないので、2月の末日から日付の補正を行う2月の末日である28日から、31日の差分ほど日付をプラスするというわけで「基準となる月より先月の日付が少ない場合」にこのような結果を得られるわけです。ただ、月末から1ヶ月前というものは、意図としては2022-02-28を期待するはずですね。人間の思う処理と、実際のコードが算出する結果が違うというのは十分にあり得る状況ですが、AddDateのドキュメントでは上記のような処理になるという話は特に言及されてないので誤解する可能性もあるのかなと思います。また、Java/Kotlinで使っているLocalDateの場合は期待通り2022-02-28になるので、Java/Kotlinの経験のあるエンジニアが無意識的にこのような問題を起こすコードを書く可能性もあるかなと思います。ちなみに、LocalDateを使ったコードがGoと違う結果になるのは、minusMonth()では最後に以下のメソッドを呼び出すからです。private static LocalDate resolvePreviousValid(int year, int month, int day) { switch (month) { case 2: day = Math.min(day, IsoChronology.INSTANCE.isLeapYear(year) ? 29 : 28); break; case 4: case 6: case 9: case 11: day = Math.min(day, 30); break; } return new LocalDate(year, month, day);}なので、Goでも3月31日から1ヶ月前の日付が2月28日になるという処理を期待したい場合は、以下の二つの方法を考慮した方がいいかなと思います。LocalDateと同じく、閏年と月別の末尾を考慮した処理を足すAddDate()で得られた月が基準となるtimeと同じ月である場合、先月の末日を返す前者の場合は月を計算した後、上記のresolvePreviousValid()と同じ処理を足すことで実現でき、後者の場合は、以下のように末日を取得することが可能なので参考にしてください。date := date.AddDate(2022, 3, 0, 0, 0, 0, 0, time.UTC) // 3月0日を指定すると2月28日になるmapGoで変数を宣言する方式は以下の二つがありますね。// 型だけを宣言var intSlice []int// 初期化と共に宣言stringSlice := make([]string, 10)問題は、宣言の仕方によって要素を足す場合に問題が起こり得るということです。先にsliceの例を見ましょう。varで宣言した場合でもmake()で初期化した場合でもappendを使った要素の追加には問題がありません。var intSlice []int// sliceに値を追加するintSlice = append(intSlice, 1) // [1]ただ、mapの場合はvarで宣言すると問題が起こる可能性があります。以下のコードは、nil pointerとなります。var stringMap map[string]stringstringMap["A"] = "a" // panic: assignment to entry in nil mapこれはvarで宣言した変数は基本的にnilになるからですね。nilのmapに要素を追加しようとしたのでエラーが発生するのは当たり前ですが、Goland(Intellij)上では警告も表示されず、コンパイルも無事通るので実際にコードを実行するまでこのコードが動くかどうかはわかりません。むしろ、sliceを先に扱っていたなら、nilでもappendできるので「Goではこれでいいのかな」と思い込みやすいかなと思います。JavaやKotlinでもインスタンスを生成していないMapに対して要素を足すことはできないのですが、ここはJavaやKotlinの週間というよりは「Goの特殊性」と考えてしまうケースだと思いますので、要注意なところなのではないかと思います。switchGoのswitchはJavaとよく似ています。ただ、形が似ているだけで、決定的な違いがあります。まずはJavaのswitchから見ていきましょう。以下のようなコードがあるとします。int i = 1;switch (i) { case 0: System.out.println("zero"); case 1: System.out.println("one"); case 2: System.out.println("two"); default: System.out.println("else");}Javaのswitchは、breakを明示的に書かない限り、条件が一致するcaseに分岐されたとしても、その下のcaseでも流れてしますね。なので、上記のコードを実行した結果は以下のようになります。onetwoelseKotlinではwhen式になり、breakなしでも条件と一致するコードブロックを実行することで処理は終了します。例えば以下のようなコードを書くとしましょう。val i = 1when (i) { 0 -> println("zero") 1 -> println("one") 2 -> println("two") else -> println("else")}実行した結果はJavaと違うのがわかります。省略されているだけで、一つの枝ごとに処理がbreakするからです。oneここでGoのswitchの場合はどうなるかを見ていきましょう。形上はJavaと似ていますが、結果もそうでしょうか？i := 1switch i {case 0: fmt.Println("zero")case 1: fmt.Println("one")case 2: fmt.Println("two")default: fmt.Println("else")}上記のコードを実行した結果は、Kotlinと同じです。つまり、「one」と出力されるということです。これはGoのswitchもまた、Kotlinと同じく枝ごとにbreakするからです。なので、Javaの場合と同じ結果が欲しい場合は、fallthroughを追加し、次の枝に進むということを明示的に書く必要があります。以下のようにです。i := 1switch i {case 0: fmt.Println("zero") fallthroughcase 1: fmt.Println("one") fallthroughcase 2: fmt.Println("two") fallthroughdefault: fmt.Println("else")}Javaの経験がある場合、スタイルが似ているのでつい挙動も同じだろうと思ってfallthroughを省略してしまうというケースもあり得るかなと思います。ここは言語が違うだけ使用も違うということなので、要注意ですね。ifGoではif文の条件がおかしいと思われる場合、コンパイルが通りません。例えば以下の例を見てください。type Role intconst ( SystemAdmin = 1 Operator = 2 Developer = 3)type User struct { Name string Role Role}// SystemAdminかDeveloperではない場合はエラーを返すfunc checkRunnableUser(u User) error { if u.Role != SystemAdmin || u.Role != Developer { return errors.New("user is not runnable") } return nil}func Test_checkRunnableUser(t *testing.T) { u := User{Name: "John", Role: Operator} err := checkRunnableUser(u) if err != nil { t.Errorf("unexpected error: %s", err) }}上記のコードをコンパイルしようとする場合、Goland(Intellij)では条件に警告が表示され、コンパイルするとsuspect or: u.Role != SystemAdmin || u.Role != Developerというエラーメッセージが表示されるのを確認できます。エラーメッセージでもわかるように、これはif文の条件が間違っているからですね。「UserのRoleがSystemAdminかDeveloperの場合のみ許容する」という要件を満たすためには、orではなくandを使う必要があります。なので、if文の条件を以下のように修正すると意図通りに動くし、IDE上の警告やコンパイル時のエラーも発生しなくなります。// SystemAdminかDeveloperではない場合はエラーを返すfunc checkRunnableUser(u User) error { if u.Role != SystemAdmin && u.Role != Developer { return errors.New("user is not runnable") } return nil}Javaの場合だと、Intellijでは条件が怪しいという警告は表示されるものの、Kotlinと同じくコンパイル時のエラーは発生しません。なので実行はできるようになりますが、警告の出ている箇所を確認していないと実際に実行してみるまでロジックが間違えていることには気づかなくなりますね。enum Role { SYSTEM_ADMIN, OPERATOR, DEVELOPER}record User(String name, Role role) {}static void checkRunnableUser(User user) { if (user.role() != Role.SYSTEM_ADMIN || user.role() != Role.DEVELOPER) { throw new IllegalArgumentException("user is not runnable"); }}public static void main(String[] args) { checkRunnableUser(new User("John", Role.SYSTEM_ADMIN));}しかし、問題は同じ処理をKotlinで書いてみると、Intellijで警告が出ることもなく、コンパイルも通るということです。Javaのケースと同じくランタイムでエラーが発生するコードになりますが、警告すら表示されないのでコードを注意深く確認しないと意図通りに動作している理由が何かを見逃しやすくなっているのではないかと思います。enum class Role(val value: Int) { SystemAdmin(1), Operator(2), Developer(3)}data class User(val name: String, val role: Role)fun checkRunnableUser(user: User) { if (user.role != Role.SystemAdmin || user.role != Role.Developer) { throw IllegalAccessException("user is not runnable") }}fun main() { checkRunnableUser(User(name = "John", role = Role.Operator))}コンパイルタイムでエラーを事前に検知できるという点は確かにGoのコンパイラの方が優秀かなと思います。ただ、KotlinやJavaに慣れている場合、条件がおかしいということに気づくより、「constを使っているせいか」「switchを使うべきか」など、問題の本質に気づかないようになる可能性もあるのではないかと思います。これは、そもそも正しく条件を書くことが何よりも大事であることでありながら、他の言語で形成された習慣で違う言語のコードを書くと問題を起こし得るということを実例として適切ではないかと思いますね。Range loopGoのループにはfor文しかないですが、indexを利用する伝統的な形以外でもRangeでのループがあります。以下のような形で使えます。var pow = []int{1, 2, 4, 8, 16, 32, 64, 128}for i, v := range pow { fmt.Printf("2**%d = %d\n", i, v)}同じ結果を出すコードをKotlinで書くとしたら、以下のようになるかと思います。一目でわかりますね。// kotlinval pow = listOf(1, 2, 4, 8, 16, 32, 64, 128)for ((i, v) in pow.withIndex()) { println("2**$i = $v")}ただ、Goにはポインタがあり、Range loopでポインタを使おうとすると問題が発生するケースがあります。例えば以下の例をみましょう.var pow = []int{1, 2, 4, 8, 16, 32, 64, 128}// 新しいスライスにpowの参照を格納var ppow []*intfor _, v := range pow { ppow = append(ppow, &v)}// ppowの値を出力for i, v := range ppow { fmt.Printf("2**%d = %d\n", i, *v)}想定通りだと、ppowにはそれぞれ1, 2, 4, 8, 16, 32, 64, 128の参照が格納されるべきでしょう。しかし、このコードを実行してみると、実際には128と全て同じ値となっています。Range loopないで参照している値が全部同じアドレスを参照することになるからです。なので、ポインタを使うスライスを用いてループの処理をする場合は、以下のようにvを再代入するか、indexによる参照で問題を回避する必要があります。var pow = []int{1, 2, 4, 8, 16, 32, 64, 128}// 新しいスライスにpowの参照を格納var ppow []*intfor _, v := range pow { v := v // ここでvの値をコピー ppow = append(ppow, &v)}// ppowの値を出力for i, v := range ppow { fmt.Printf("2**%d = %d\n", i, *v)}うっかりRange loopを使ってしまうと、ポインタを使うスライスを用いてループの処理をする場合に問題が発生する可能性があるので、気をつけたいですね。最後に幾つかの例を挙げましたが、まだ自分もGoでアプリを書いた歴も短く、言語に対しての理解も深くないのでこれからも色々と問題に遭遇する可能性はあるのかなと思います。その度はまたこうやってブログに載せていきたいと思います。ブログのネタができるという面では嬉しいですが、失敗からのポストは結局自分が辛くなることなので、うれしくはないですね…とにかくここであげた問題は全て自分が経験したものですが、大事なのは、違う言語に挑戦するときは自分の持つバックグラウンドの知識を活かしながらも、それを偏見にしたいこと、そして先走らないことかなと思いました。Goに限らず、新しいものに触れるときは常に注意しないと、という感じですね。では、また！

JVM言語経験者がGoを触る時のハマりどころ

Rustの勉強を始めたい、と思ったのはおよそ2年前のことです。当時はJavaとPythonを主に触っていたので、パフォーマンスがクリティカルな部分では対応しきれない部分があると思い、ネイティブにコンパイルされる言語に触れてみる必要があると思いました。そしてできれば、GCのなくポインタを扱う言語でアプリを書いてみたら、本業と言えるJavaの理解もより深くなるのではないかと思った次第です。そこで候補として考えたのがGoとRustです。ただ、Goは世間の評価はともかく、自分の立場からすると少し追求している目標とずれているところがあるなと思いました。特に転職してからGoとKotlinという言語を並行で触っていると、良くも悪くも自分がやりたいことがなんなのかわかってきた気分にもなったのです。そこで、そろそろ次の候補として考えていたRustに触れてみたいと思った次第です。これもまた、世間の評価は置いといて、実際自分に合うかどうかを確認してみたくなりました。最近は色々な言語が扱えるPolyglot Programmerの時代だという概念もあり、多くのプログラミング言語が互いの良いところを吸収しながらどれも似たようなものになったという評価もありますが、私の場合は、あくまで自分に合うのは何かを探るという感覚としてRustという新しい言語を接してみたいと思っています。なので、今回はまずこちらのThe Rust Programming Languageを読みながら、興味深かった部分について、自分が今まで経験してみた他のプログラミング言語と比べながら感想を述べたいと思います。ドキュメントが長く、自分の理解もまだ浅いのでまずは一部だけを紹介しましょう。LoopRustでは伝統のforとwhile以外にも、ループの条件を指定しない(無限ループ)loopというのがありました。特定の条件でループを終了したい場合のみ、breakすることで終了できます。例えば以下のような形です。loop { // do something}他の言語だと、普通はwhile(true)のような形が多いかと思います。例えばPythonは以下のようになりますね。while true: # do somethingKotlinやJavaでも事情は変わりません。以下のようになりますね。while(true) { // do something}Kotlinの場合だと、拡張関数があるのでloopというものを定義したらどうかと思いましたが、そうするとコンパイラ上でループだと認識されないので、breakを書くとコンパイルエラーとなります。なので以下のように拡張関数と作ることはできませんでした。fun test() { loop { break // コンパイルエラー }}fun loop(doSomething: () -> Unit) { while(true) { doSomething() }}Goの場合は、forに条件式を書かないことでシンプルな無限ループを書くことができます。for { // do something}個人的にwhile(true)や条件式を指定しないforは、慣習でしかなく、直感的な理解を招くものではないと思いますので、loopというキーワードを設けた方がコードの可読性という面ではよりわかり安いものなのではないかと思いました。細かい部分ではありますが、一回仕様としてとして決まるとなかなか変更できないものなので、どんなキーワードを使うかを決めるということも言語の設計においては大事だという気がします。ArrayRustでは配列のindexを基準に一部を抽出するとき、以下のような書き方をします。参照(&)を利用して定義する必要があって、標準出力する形も少し独特ですね。また、indexを指定して切り出したものは「所有権のない別のデータ型」として定義されています。ここで切り抜いた配列の一部を、Rustではsliceと呼んでいるらしいです。let arr = [0, 1, 2, 3, 4];let slice = &arr[1..3];println!("{:?}", slice); // [1, 2]Pythonでもかなり似たような感じでコードが書けます。以下は上記と同じ挙動をするコードの例です。ただ、ここで切り抜いたsliceのデータ型は同じくlistになるというのがRustとの違いですね。list = [0, 1, 2, 3, 4]slice = list[1:3]print(slice) # [1, 2]Kotlinの場合は、Listの関数にRangeオブジェクトを渡すことで同じことができます。少し問題になるのは、Kotlin特有のRangeの書き方がどのような範囲を示すのか覚えてないとその範囲が分かりづらいということです。幸い、ここはIntellij Idea 2021.3のアップデートでヒントを表示してくれるようになったので、これ以前のバージョンを使っている場合はアップデートした方が良いですね。val list = listOf(0, 1, 2, 3, 4)val subList = list.slice((1..2))println(subList) // [1, 2]val subListUntil = list.slice((1 until 3))println(subListUntil) // [1, 2]Javaの場合は、インデックスの範囲をList.subList()に渡すことで同じことができます。List<Integer> list = List.of(0, 1, 2, 3, 4);List<Integer> subList = list.subList(1, 3);System.out.println(subList); // [1, 2]Goの場合は、Pythonと全く同じ方法で定義ができますね。また、配列からインデックスの範囲を指定して切り取ったviewをsliceと呼ぶのはRustと一緒です。ただ、Goのsliceはarrayと違って、可変長ですね。arr := []int{0, 1, 2, 3, 4}slice := arr[1:3]fmt.Println(slice) // [1 2]ImmutabilityRustでの変数の宣言は基本的にlet一つで、不変になります。もちろん可変できる変数を定義するのは不可能ではなくて、以下のようにmutキーワードを使うことで値を再代入することはできます。例えば以下のようにです。fn main() { let mut x = 5; println!("The value of x is: {}", x); // The value of x is: 5 x = 6; println!("The value of x is: {}", x); // The value of x is: 6}他のプログラミング言語だと、変数の宣言時にその変数の可変性をあらかじめキーワードで表現するようになっているケースが多いかと思います。もしくは、基本的に変数は可変で、不変にしたい場合にだけ特別なキーワードを使うとかですね。しかし、Rustでは変数は基本的にimmutableであるというのが特徴的です。GCのない言語として、メモリの安全性を確保するための工夫がここで現れていると言っていいでしょうか。もちろん、Pythonのように変数の宣言と再代入の区別が付かないケースもありますね。x = 5print("The value of x is: {}".format(x)) # The value of x is: 5x = 6print("The value of x is: {}".format(x)) # The value of x is: 6Kotlinの場合は不変だとval、可変だとvarで宣言するようになっていますね。val x = 5x = 5 // コンパイルエラーvar y = 6y = 7 // OKJavaの場合は、Rustと逆です。finalをつけない場合、基本的に再代入ができる構造ですね。int x = 5x = 6 // OKfinal int y = 6y = 7 // コンパイルエラーGoの場合は、変数をimmutableにできる方法はないようですね。なので、再代入は自由ですが、逆にJavaのfinalのようなキーワードが欲しい気分にもなります。x := 5x = 6fmt.Println(x) // 6Shadowingこれは全く予想できなかった部分ですが、Rustのドキュメントには変数にシャドーイングを使えると紹介されています。mutキーワードをつけると再代入は可能なので、それで良いのではという気もしますが、変数を不変にしながら、違うデータ型として定義し直す場合などに使えるという説明でした。Rustではシャドーイングを使って以下のようなコードを作成できます。fn main() { let x = 5; let x = x + 1; // 6 let x = x * 2; // 12 println!("The value of x is: {}", x); // The value of x is: 12}Pythonの場合も似たようなことができます。同じ挙動をするコードを以下のように書くと、問題なく動きます。変数の宣言と再代入が厳密に区別されない故のことかと思いますが、形的にはRustと全く一緒と言えますね。x = 5x = x + 1x = x * 2print("The value of x is: {}".format(x)) # The value of x is: 12Kotlinの場合、シャドーイングは一部の場合のみ可能です。関数の引数と、その関数で宣言している変数名が一致する場合ですね。fun shadow(value: Int) { val value = value + 1 // Name shadowed: value println(value) // valの方が出力される}Javaでは、シャドーイングができないです。ただ、以下のような形は可能です。class Clazz { private int value = 0; public void setValue(int value) { this.value = value; }}Goの場合、少し複雑になります。以下の例をみると、xの宣言と代入を2回していますが、スコープが分かれてあるから可能なことです。Kotlinのケースと似ているとも言えますね。x := 0fmt.Println("Before the decision block, x:", x) // Before the decision block, x: 0if true { x := 1 x++}fmt.Println("After the decision block, x:", x) // After the decision block, x: 0上記のコードは、以下のようにif文でのxに対して再代入することで挙動が変わります。x := 0fmt.Println("Before the decision block, x:", x) // Before the decision block, x: 0if true { x = 1 x++}fmt.Println("After the decision block, x:", x) // After the decision block, x: 2このように他の言語だとなるべく使わないように誘導しているシャドーイングですが、Rustでは一つの機能として紹介しているのが面白いところでした。これもまた、後述する「所有権」というものと強く関係しているような気がします。Ownership他の言語と比べたときに、Rustならではの特徴と言えるものは所有権ではないでしょうか。今まで私はGCのない言語を触ってみたことがないので、これはかなり興味深い概念でした。例えばKotlinの場合はNativeでコンパイルする場合、参照カウントを使うと言われています。JavaやPython, Goの場合はGCが働いて参照されていないオブジェクトが占めているメモリを解放することになりますね。しかし、Rustでは定数、不動小数点数、論理値、文字というスカラー型を除いた全ての参照型に関しては「一度使われたらメモリは解放される」「スコープを外れたら解放される」という原則を持っているようです。参照型とスカラー型という区分はJavaのプリミティブ型と参照型の関係を思い出させるところがありますね。より積極的かつ攻撃的なメモリ解放が行われるという違いはありますが。基本的には一回使った変数に対しては2回使えなかったり、値の変更ができないかと思った方が良い、ということかなと思いますが、他にも色々と興味深いものがありました。Move所有権と関係する概念で、ムーブがあります。変数とデータが実際どうやって相互作用するかによるものらしいです。早速下のコードを見ていきましょう。なんの問題もなさそうなものです。let s1 = "hello";let s2 = s1;println!("s1 = {}, s2 = {}", s1, s2); // s1 = hello, s2 = helloただ、上記のString literalをStringに変えたら問題が起こります。以下のコードを見ましょう。let s1 = String::from("hello");let s2 = s1;println!("{}, world!", s1);上記のコードは、コンパイルしようとすると以下のようなエラーが発生します。error[E0382]: use of moved value: `s1` --> src/main.rs:4:27 |3 | let s2 = s1; | -- value moved here4 | println!("{}, world!", s1); | ^^ value used here after move | = note: move occurs because `s1` has type `std::string::String`,which does not implement the `Copy` traitつまり、s1のデータがs2に移動したのでもう使えないということです。なので、二つの変数に同じデータを保証したい場合は、明示的に値をコピーする必要があります。例えば以下のようにです。let s1 = String::from("hello");let s2 = s1.clone();println!("s1 = {}, s2 = {}", s1, s2); // s1 = hello, s2 = helloなぜこうなっているかというと、Rustでは変数がスコープの外に移動するときにメモリの解放が起こりますが、ここで複数の変数が同じポインタを使っている場合は二重解放が起こる危険があるからと説明されています。また、String literalと違ってStringはimmutableではないので、s1の再代入でs2のデータまで変わってしまうという問題を防ぐための意図もあるような気がします。実際このような代入が問題となる言語のケースもありますね。例えばPythonの方を見ましょう。二つの変数が同じポインタを使っているので、再代入で両方とも値が変更されたのを確認できます。s1 = "hello"s2 = s1print("s1 = {}, s2 = {}".format(s1, s1)) # s1 = hello, s2 = hellos1 = "world"print("s1 = {}, s2 = {}".format(s1, s1)) # s1 = world, s2 = worldJavaではStringをimmutableとして扱っているため、s1の値を再代入してもs2に影響はありません。KotlinもJVMの場合は、基本的にJVMのバイトコードを生成するためか同じ挙動をします。以下をご覧ください。var s1 = "hello"val s2 = s1println("s1 = $s1, s2 = $s2") // s1 = hello, s2 = hellos1 = "world"println("s1 = $s1, s2 = $s2") // s1 = world, s2 = helloJavaの場合も前述した通りです。var s1 = "hello";var s2 = s1;System.out.println(String.format("s1 = %s, s2 = %s", s1, s2)); // s1 = hello, s2 = hellos1 = "world";System.out.println(String.format("s1 = %s, s2 = %s", s1, s2)); // s1 = world, s2 = helloGoでも変数はimmutableとして定義できませんが、この再代入により値が変わる可能性があるものに対しては安全性を担保されています。s1 := "hello"s2 := s1fmt.Println(fmt.Sprintf("s1 = %s, s2 = %s", s1, s2)) // s1 = hello, s2 = hellos1 = "world"fmt.Println(fmt.Sprintf("s1 = %s, s2 = %s", s1, s2)) // s1 = world, s2 = helloRustで明示的にコピーをしない場合はデータそのものが移動してしまうというのは確かにコーディング時には気を使わないといけないものですが、幸いコンパイルタイムで確認できる問題であり、他の言語を扱うときには思わぬ挙動をする可能性がある習慣を矯正してくれる可能性もあるかなと思うと、良い仕様ではなイカという気もしますね。ClosureRustではclosureを関数内の関数として定義することももちろん可能ですが、|val| val + xの形式で書きます。他の言語でlambdaと呼ばわれているものですね。多少は独特な書き方な気もしますが、型の省略が可能なのが他の言語と比べ便利なものな気がします。もちろん型の明示的な表記もできるので、以下のような使い方ができます。fn main() { // i32の引数を必要とする場合 let closure_annotated = |i: i32| -> i32 { i + 1 }; let closure_inferred = |i | i + 1 ; let i = 1; println!("closure_annotated: {}", closure_annotated(i)); // closure_annotated: 2 println!("closure_inferred: {}", closure_inferred(i)); // closure_inferred: 2 // 引数がない場合 let one = || 1; println!("closure returning one: {}", one()); // closure returning one: 1}Pythonの場合は以下のように書くことができますね。もちろん、関数の中に関数を定義することもできますが、lambdaを使った方がが便利なのかなと思います。ただ、3.5から型ヒントを使えるようになっていて、コンパイルタイムで確実にエラーをチェックしたい場合は明示的に型を書いたほうが良さげな気はします。closure = lambda x : x + 1print(closure(1)) // 2Kotlinでも簡単に定義はできるものですが、少なくとも引数の型は書く必要があります。もしくは、変数に型を指定することが必要ですね。val closure = { x: Int -> x + 1 }println(closure(1)) // 2Javaではメソッド内にメソッドを定義することができなく、1.8から追加されたFunctional Interfaceを使う必要があります。また10からはvarで型推論を使えるようになりましたが、Functional Interfaceをvarとして宣言するのはできないという制約があります。他の言語と比べると最も制約が多いですね。Function<Integer, Integer> closure = i -> i + 1;System.out.println(closure.apply(1)); // 2Goの場合は関数内に関数を定義するのは不可能ではないものの、他の言語のlambdaのような書き方はできず、匿名関数として定義ができます。また型を明示する必要があるので、名前を除いて完全な関数を定義して変数に代入しているようなものになりますね。closure := func(x int) int { return x + 1}fmt.Println(closure(1)) // 2また、closureにおいてRustの特徴はもう一つあります。closureを引数とする関数を定義するときの書き方です。closureに対してgenericを使って、whereというキーワードで関数の中にclosureを書いていくような形です。他の言語だとclosureが引数でも書き方は大きく変わらないのですが、Rustでは全く違う形になっているのが興味深いですね。例えば以下のようなコードになります。// Fというclosureを引数とする関数fn apply_to_3<F>(f: F) -> i32 where // Fはi32を受け取ってi32を返すclosure F: Fn(i32) -> i32 { f(3)}fn main() { let double = |x| 2 * x; println!("3 doubled: {}", apply_to_3(double)); // 3 doubled: 6}最後にまだドキュメントの半分の読んでなく、実際に何かしらのアプリを作ってみたわけでもないので今回のポストだけでは十分ではないというのは十分承知のつもりですが、久々に違う言語を学びながら、色々と興味深いところが多かったのでひとまず感想を書いてみました。噂ではRustのコンパイラは優秀で、そのコンパイラの指示通りにアプリを組むだけでのかなり勉強になる瞬間が多いというのと、言語自体の設計が良いという話だったので、これからも勉強しながら気づいたことや感じたこと、学んだことについてブログにまとめていきたいと思います。今回のポストだけでの企画として終わらせたくないので、今年はこれで頑張っていきたいですね。では、また！

Kotlinプログラマが見たRust

今回は久々に本を読んだのでそれに関する感想を少し書こうと思います。転職前は主にJavaを扱っていたため、Effective Javaを読み自分の書いたコードを振り返って見たことがありました。転職後はKotlinという違う言語を触るようになったものの、やはりJVMで動く言語であり、現在使っているフレームワークもSpringから変わってないので基本的には同じ観点でコードを作成すると良いのかなと思っていました。しかし、Kotlinに触れてから1年が経った今、やはり言語が違うとコードを作成するときの週間も一度は見直す必要があるのではないかと思っています。そこで、ちょうどEffective Kotlinという本を発見したので早速読んでみました。そして今回のポストではその内容について色々と書こうと思います。ちなみに、この本自体は出版されて少し経つので、ネット上でもたまにその内容やPDFの資料などを発見することあができました。例えば、この本で「可読性」のチャプタに関しての話は[こちらのブログ]の方によく整理されてあるので、参考にしてください。全体的な印象個人的にEffective Javaは上級者向けの本で、ある程度Javaでアプリを書いたこと経験のある人でないと理解が難しいところが多かったかなと思います。例えば、「try-finallyをtry-with-resourceに代替した方がいい」とか、「Streamで副作用のない関数を書く方法」などが紹介されていますが、これらはやはりある程度Javaという言語の設計と仕様に対する基盤知識を必要とするものですね。それに比べ、Effective Kotlinには初心者向けの内容も結構あります。例えば、そもそものオブジェクト志向が何かのような内容がありました。ただそれだけではどう思ってもEffective Javaを意識したような題名が意味をなくすと判断したからか（前書きでもEffective Javaを言及しています）他には「ベストプラクティス」として書かれているものも多いです。そして当たり前ながら、Kotlinにおいても有効なことはEffective Javaと重なっているような部分もあります。例えば、オブジェクトのインスタンスを作るときはfactory methodを書いた方が良いとかがそうですね。ただ、Kotlinのバージョンアップの速さに追いついてないと感じるところがあったり（これは出版物の限界でもありますが）、上級者向けの内容は多少十分ではない感覚でしたので、どちらかというとジュニア向けの感覚ではあります。興味深いジュニア向けといいつつ、自分もまだジュニア（の気持ち）であるため、興味深いと思ったところもありました。ここでその一部を紹介したいと思います。Single responsibility principleいわゆるSOLIDに触れるパートです。Kotlinでは拡張関数を用いることで、単一責任の原則を守れるという主張をしていました。まず以下のようなケースがあるとしましょう。class Student { // ... fun isPassing(): Boolean = calculatePointsFromPassedCourses() > 15 fun qualifiesForScholarship(): Boolean = calculatePointsFromPassedCourses() > 30 private fun calculatePointsFromPassedCourses(): Int { //... }}ここでisPassing()はaccreditationsというモジュールで、qualifiesForScholarship()はscholarshipというモジュールで使われるとします。そしたら、Studentというクラスがこれらの関数を持つのは単一責任としてどうか、ということですね。なので、モジュール別にこれらの関数を拡張関数として定義することが良いとのことでした。// scholarship modulefun Student.qualifiesForScholarship(): Boolean { /*...*/}// accreditations modulefun Student.calculatePointsFromPassedCourses(): Boolean { /*...*/}もしくはcalculatePointsFromPassedCourses()を外に出す方法を考えられるでしょう。しかし、この場合はこれらの二つのメソッド専用のprivateメソッドとしてつかえません。なので、どのモジュールでも使える共通関数を作っておくdepartment別にhelper関数を作っておくとかの方法も考えられます。確かに、よく考えると拡張関数の良いところは「interfaceの実装ややスーパークラスの継承なし」でも簡単に処理を追加できるということなので、このような使い方をするのがユースケース別に処理を分けられて良さげな気がします。特に拡張関数を使うと、関数を配置するパッケージと可視性の制御が効くというところが個人的には新しい発見でした。Consider defining a DSL for complex object creationオブジェクトの作成時の複雑な処理はDSLを使いましょう、というパートです。Kotlinですでに提供している例としたら、HTMLがありますね。以下のような形で定義することになります。body { div { a("https://kotlinlang.org") { target = ATarget.blank +"google" } } +"Some content"}確かにKtorのようなフレームワークでもよく使われている物なので、ある程度需要はあるのかなという気がしました。Kotlinだと高階関数を作るのが難しくはないので、十分挑戦できるところでもありますね。ただ、DSL特有の書き方を確立し、その書き方をエンジニアに共有することや最初の設計と維持管理が難しそうな気がするので、アプリの縮小が求められる今のご時世に果たして合うかとうかは少し疑問ののころところでした。個人的に何かのライブラリやフレームワークを作るとしたら、挑戦してみたいなと思いました。まあそうだよねって思ったところなんとなくそうではないかと思っていたところを（もしくはどこかで聞いて理論的な部分は忘れたけど、無意識的のうちに習慣化されていた部分を）文として親切に整理してくれているようなパートもありました。なのでもう一度自分の考えを再確認できたといえるところでしょうか。Do not repeat common algorithms「スタンダードライブラリで解決できる一般的なアルゴリズムを自前のコードで書くな」というパートです。理由は以下の通りです。呼び出しの方がコードを書くより時間が短くかかるわかりやすい名前になっているコードがわかりやすくなる最適化が効く私自身もなるべくスタンダートライブラリを活用した方が良いと思っていたので、ここはすぐに納得できました。自分で書いた処理が果たして最適化されたものかどうかもわからないし、業務使用以外のロジックを触るのは避けたいという理由でした。この本では、以下のようなコードを上げています。自前のロジックを書いた場合です。val percent = when { number > 100 -> 100 number < 0 -> 0 else -> number}上記のコードは、coerceIn()を使うことでシンプルにできます。以下がその例です。val percent = number.coerceIn(0, 100)Kotlinには特にスタンダードラリブラリに良い関数が多いので、自前のロジックを書くよりは一度どんなAPIがあるのかを確認した方が良いケースが個人的には多かった気がします。そしてそれが納得できる理由が書いてあってよかったと思います。Implementing your own utilsスタンダードライブラリで解消できる問題以外で、プロジェクトに必要な共通の処理はユーティリティ関数として作っておきましょうってパートです。ユーティリティはクラスでなく、拡張関数として作ったら以下のようなメリットがあるらしいです。関数は状態を持たないので副作用がないトップレベル関数と比べると型が決まっているので使い勝手がいい引数よりはクラスについた形が直観的オブジェクトに関数をまとめるより必要な機能を探しやすい特定のクラスに従属されるので親クラスのものか、子クラスのものか悩まない確かにJavaを使っていた時は、私もいわゆるSingleton Patternでユーティリティクラスを作ったり、DIして使えるクラスを定義しておいて、staticメソッドを書いていました。Kotlinだと、ユーティリティクラスなしでも特定のクラスに関数を追加することができるのでより使い勝手がよくなります。例えば、同じことをするとしても、拡張関数で書く場合とユーティリティクラスを作る場合のコードは以下のような違いがあります。// 拡張関数を使う場合val isEmptyByExtension = "Text".isEmpty()// ユーティリティクラスを使う場合val isEmptyByUtilClass = TextUtils.isEmpty("Text")ユーティリティクラスを使う場合はまず、「どのユーティリティクラスの関数を使うか」を考えなければならないです。それに比べ、拡張関数はIDEでも自動補完ですぐ欲しい関数を見つけることができるので、より直観的なものになっていますね。他にも具体的なクラスにのみ追加ができたりするので、より安全な使い方ができるというのも良いところですね。色々と拡張関数は使い道が多いなという、再発見ができたと言えるところでしょうか。Builder patternKotlinではnamed argumentsが使えて、Builderパターンがいらないというパートです。KotlinでもBuilderパターンを使うことが技術的に不可能ではないが、named parameterを使った方が良い理由としては以下が挙げられています。より短いより綺麗使い方がシンプルスレッドセーフ私自身も、Javaで使っていたのでKotlinでもBuilderパターンが必要かなと思ったことがありますが、いらないという結論を出しています。上記で挙げた理由ももちろん妥当ですが、Builderパターンだとインスタンスを生成するときに必須パラメータが揃っているかどうかを判断するのが難しくなるという理由からでした。例えば本に出てくるBuilderパターンの例があるとしましょう。class Pizza private constructor( val size: String, val cheese: Int, val olives: Int, val bacon: Int) { class Builder(private val size: String) { private var cheese: Int = 0 private var olives: Int = 0 private var bacon: Int = 0 fun setCheese(value: Int): Builder = apply { cheese = value } fun setOlives(value: Int): Builder = apply { olives = value } fun setBacon(value: Int): Builder = apply { bacon = value } fun build() = Pizza(size, cheese, olives, bacon) }}このBuilderは以下のような使い方ができると思います。val villagePizza = Pizza.Builder("L") .setCheese(1) .setOlives(2) .setBacon(3) .build()しかし以下の場合でもビルドはできますね。val villagePizza = Pizza.Builder("L").build()もしcheese、olives、baconが0を許容しない作りになっていると、これを修正するのは大変なことになるでしょう。もしくは、パラメータが複雑な作りのオブジェクトだったらデフォルト値を設定するか、強制null check(!!)などを入れるか…より複雑になるだけですね。しかし、named parameterを使うと簡単に解決できる問題です。デフォルト値を指定しないvalだったら、それが必須項目であるということもわかりやすいですね。val myFavorite = Pizza( size = "L", cheese = 5, olives = 5, bacon = 5 )Consider factory functions instead of constructorsJavaでも最近は色々とfactory functionを導入していて、簡単にimmutableなオブジェクトを作りやすくなりました。Kotlinでもコンストラクタの作成や、named parameterによるインスタンスの生成が色々と便利ではあるものの、それでもfactory functionが良いケースがあるというパートです。理由は以下の通りです。関数には名前があるので、どうやってオブジェクトが生成されるかわかるArrayList(3)よりはArrayList.withSize(3)がわかりやすい戻り値としてサブタイプのオブジェクトを指定できる具体的な実装を時と場合によって違う形にすることができる呼び出されるたび新しいオブジェクトを作るわけではないConnections.createOrNull()のようにnullを返すこともできるまだ存在しないオブジェクトを提供できるプロキシなしで動くようなオブジェクトを作るなどで応用できるオブジェクトの外に作ることで可視性を制御できるinlineにできるので、reifiedにもできるインスタンスを作るのが複雑なオブジェクトの手間を省くスーパークラスやプライマリコンストラクタを呼び出さずにインスタンスを生成できるこちらも読みながらなるほどと納得しました。特に私の場合でも、Service層のDTOとController層のResponseなどのオブジェクト間のマッピングではfactory functionを導入してコードを再使用性を高められたと思っていたので、良い判断だったなと今は思っています。他に、factory functionを作る方法としても以下のようなものが提示されてありました。一般的にはcompanion object内に定義しておくことが多いかと思いますが、他の方法も必要であれば考慮したいものですね。companion objectJavaのstaticメソッドのようなパターン。最もわかりやすいですね。以下のような形です。class MyLinkedList<T>( val head: T, val tail: MyLinkedList<T>?) { companion object { fun <T> of(vararg elements: T): MyLinkedList<T>? { /*...*/ } }}// Usageval list = MyLinkedList.of(1, 2)factory functionは大体以下の規則を持って命名されるという説明もありました。from一つのパラメータを渡し、タイプを変える時（自分自身のインスタンスを返す）val date: Date = Date.from(instant)of複数のパタメータを渡し、それを束ねたタイプに変換するときval faceCards: Set<Rank> = EnumSet.of(JACK, QUEEN, KING)valueOfofの冗長な形val prime: BigInteger = BigInteger.valueOf(Integer.MAX_VALUE)instance / getInstanceSingletonのインスタンス取得（パラメータが同じだと常に同じインスタンスが帰ってくる）val luke: StackWalker = StackWalker.getInstance(options)createInstance / newInstanceinstance / getInstanceは似ているが、常に新しいインスタンスを返すval newArray = Array.newInstance(classObject, arrayLen)getTypeinstance / getInstanceと似ているが、違うタイプのインスタンスを返すときval fs: FileStore = Files.getFileStore(path)newTypecreateInstance / newInstanceに似ているが、違うタイプのインスタンスを返す時val br: BufferedReader = Files.newBufferedReader(path)extensionクラスにからのcompanion objectを定義しておいて、外部から拡張関数でfactory functionを付ける形です。元のクラスをいじらなくても良くなるし、パッケージと可視性の制御など拡張関数の持つ特徴を活用できますね。interface Tool { companion object { /*...*/ }}fun Tool.Companion.createBigTool( /*...*/ ): BigTool { //...}top-levelスタンダードライブラリに含まれている、listOf()、setOf()、mapOf()のようなものです。よく使うタイプに関しては使い勝手がいいので便利なものの、IDEの自動補完などに現れたら混乱するケースもあるので命名は慎重にする必要がある、とのことでした。fake constructorPascal Caseを使って、関数をコンストラクタに見せかけるものです。Kotlinのスタンダードライブラリとしては、以下のようなものがあります。List(4) { "User$it" } // [User0, User1, User2, User3]これは実際は以下のような関数ですね。public inline fun <T> List( size: Int, init: (index: Int) -> T): List<T> = MutableList(size, init)public inline fun <T> MutableList( size: Int, init: (index: Int) -> T): MutableList<T> { val list = ArrayList<T>(size) repeat(size) { index -> list.add(init(index)) } return list}これはinterfaceに対してコンストラクタを作る必要があったり、reifiedタイプの引数が必要な時に考慮できるものらしいです。他にもfake constructorを作る方法があります。class Tree<T> { companion object { operator fun <T> invoke(size: Int, generator: (Int) -> T): Tree<T> { // ... } }}// UsageTree(10) { "$it" }ただ、この場合constructor referenceではコードが複雑になる問題があるらしいですね。// Constructorval f: () -> Tree = ::Tree// Fake Constructorval d: () -> Tree = ::Tree// Invoke in companion objectval g: () -> Tree = Tree.Companion::invokeなのでfake constructorを使うとしたら、関数として定義したほうがよさそうです。factory class別途Factoryというクラスを置いてインスタンスを返すようにする方法ですね。Javaではinterfaceでそのようなことをするケースがありますが（List.of()みたいな）、Kotlinでも良いのか？という疑問が湧きました。結論から言いますと、「factoryクラスは状態を持つことが可能」なため、場合によっては考慮しても良いとのことです。これは思ったより活用できそうな可能性がありますね。data class Student( val id: Int, val name: String, val surname: String)class StudentsFactory { var nextId = 0 fun next(name: String, surname: String) = Student(nextId++, name, surname)}val factory = StudentsFactory()val s1 = factory.next("Marcin", "Moskala")println(s1) // Student(id=0, name=Marcin, Surname=Moskala)val s2 = factory.next("Igor", "Wojda")println(s2) // Student(id=1, name=Igor, Surname=Wojda)最後にざっくりなまとめとなりますが、以上が私のこの本で得られた知識への感想となります。新しい発見もあり、自分の習慣が間違ってなかったということを人の説明で補ってもらったような気にもなり、かなり興味深かったです。ただやはり、Kotlinがまだ新しい言語であり、いろいろなパラダイムを吸収しているためか、Effective Javaのようなレベルの高い作法に対する議論は少し足りてないような気がしていて、そこは多少残念に思います。まあ、こう思うようになったということ自体が、少しは自分が成長した証拠でもあるかなという生意気な想像もしてみるのですが。では、また！

Effective Kotlinを読む

すでに気づいている方もいらっしゃるかと思いますが、2年ぶりにブログのテーマを変えました。正確にはテーマだけでなく、静的ページ生成ツールをJekyllからHugoに変えました。こういうのが気軽にできるので、最初からブログをGithub Pagesで公開したことは本当によかったなと今は思っています。サイトの生成ツールを変えたことで各ポストのURLにも変化があり、もしお気に入りなどに設定しておいた方には申し訳ないことをしましたが、それを踏まえても改善できたところが多いと思いますので、ご了承ください。さて、今回はそんなブログの刷新に関する話となりますが、大きくわけて「ブログがどう変わったか」と「これからブログでやっていきたいこと」について述べさせていただきたいと思います。UXの改善UXの観点で改善されたことは、ブログ刷新での第一順位の目標でもありました。他にも色々とあるかと思いますが、まずは以下のようなものがあります。画面遷移の改善以前のブログはメインから個別のポストに遷移するときにアニメーションが含まれていました。（ポスト一覧を表示するところでも同じものが使われていました）画面遷移時にアニメーションを入れるというのはもうトレンドとしては古いものでもあり、何より画面遷移が遅いような感覚があるので改善したかったです。なので、今回は反応が早くしてみました。検索機能タグとカテゴリ、そしてアーカイブがあれば十分かなと思いましたが、キーワードでポストを探したい時もありますね。以前は検索機能を付けようとしてもうまくいかなかったので、ちゃんと検索のできるテーマを採用しました。デザイン個人的にはダークモードが好きで、全体的に黒いテーマを選ぼうかなと思いましたが、幸いボタンを押すだけでダークモードへの転換ができるテーマがあったので、こちらを選びました。もっと良いのは、このダークモードはシステムの設定と連動されるということです。なので、ダークモードが好みではない場合は白い画面を見ることができます。一つ残念なのは、コードブロックのスタイルはまたブログとは別ということですが…これはのちに何か方法があったら対応したいと思います。他には、モバイル画面でもちゃんと画像が見えたり、メニューやレイアウトなども色々とモダンなデザインになったのが嬉しいところです。ポスト表示以前はポストの一覧から、ポストの画像をクリックするとそのポストの詳細画面に遷移するのではなく、画像が拡大されるという問題があ理ましたがそれを改善できました。そしてポストごとに読みにかかる大まかな時間を表示できるようになったので、記事を読まれる方にもどれを読むか参考するに良い情報を提供できているかと思います。内部的な変化さて、今までは主にUXの観点からの話でしたが、実は上記で挙げた項目は単純にJekyllのテーマを変えるだけでも対応ができるものでした。それをあえてHUGOに変えてまでブログの刷新を追求した理由を今から話したいと思います。管理がしやすいJekyllの場合、一つのテーマがRubyで書かれた一つのアプリを扱うようなものだったので、Gemfileの依存関係のアップデートが必要だったり、ローカルでサーバを起動するまで時間がかかったり、テーマを変えるたびに色々と設定や構成をいじる必要がありました。HUGOの場合、そのような問題はほとんどありませんでした。テーマはGithubのリポジトリをサブモジュールとしてインポートすることができて、あとはコンテンツと基本的な設定をいじるだけです。なので、実際に時間がかかったのは添付画像などリソースのパスが変わったための対応などを除くと、1時間ほどだったような気がします。また、以前は画像が一つのフォルダに集約されていたため、ポストの添付する画像を管理するのががかなり面倒臭い作業でしたが、今はポストごとに別フォルダを使用していて、そのフォルダに画像を入れるだけなので管理がより簡単になりました。なので、今後は画像の添付も以前よりは積極的にやっていこうと思います。HUGOはGoで書かれてあるため、ローカルでサーバを起動するのが早いのも良いところです。カスタマイズが楽以前は自動でRSSフィードを作ってくれる機能があるものの、全体のポストが対象となっていませんでした。テーマやJekyllの設定をいじれば解消できる問題だったとは思いますが、前述した通り、テーマが一つのアプリのようなものなので、カスタマイズが簡単ではありません。それに比べ、HUGOはより単純なものとなっていてテーマや設定のカスタマイズも簡単にできます。今もメニューは元々テーマの設定を変えるだけでカスタマイズできるものもありますが、一部は自分の方で修正したものもあります。どれも時間があまりかからなく、すぐにできるのが魅力的でした。shortcodeでHTMLとJavaScriptの添付をテンプレート化できるのも個人的にはHUGOの魅力ではないかと思います。使い勝手がいいので、色々と活用できそうなところが多いですね。これからはブログの生成ツールを変えて物理的に良くなったところの話ができたので、次はそのブログで何をしていきたいかを述べたいと思います。最初は意欲も溢れていて、さまざまな技術に触れてそこで自分が学んだことや感じたこと、そして試行錯誤など多彩な記事を書いていたと思います。今振り返ってみると「当時の自分はこんなにもわかってないものが多かったのか」と、恥ずかしくなる瞬間もありますが、少なくとも今よりはもっと力を入れていた気がします。個人的に、このブログの更新は少なくとも月に2回を目指しているのですが、気持ちだけが先走ってあまり読む価値のないポストもいくつか書いてきたのではないかと反省しています。なので、今年はいくつかの技術を実際使ってみるという目標をたて、それらに関する記事を書いていきたいと思います。今のところは以下のようなものを考えています。Jetpack Compose新年の目標としても挙げていたものですが、実は去年から少しづつ触っている状態で、今年は実際にAndroidとデスクトップアプリケーションを作ってみたいと思っています。ちょうど去年はCompose Multiplatformも正式リリースしているので、時期的にちょうどいいかと思います。SwiftUIの方も、XCode Cloudの発表やリンクでのアプリ公開が可能になったり、Swift Playgroundsでアプリのビルドが可能になったことにより興味を持っている状態ではありますが、まずは自分が仕事でKotlinを使っていて、Composeの方をある程度使いこなせるようになってから挑戦してみた方がいいかなと思っているところです。せっかくMacを使っているので、一度はSwiftでアプリを作ってみないとですね。Svelte会社の方ではNuxt.jsを使っているので、こちらでも良いかと思いましたが、結局自分が画面を触ることになるのはプライベートでしかチャンスがない気がしたので、興味本意で選んだのがSvelteです。まだ技術としては成熟したものではない気はしますが、そろそろSveltekitのようなものも登場していて、何よりも学習にかかる時間や効率を考えたときに、自分が画面を作るとしたら最も生産性が高くなりそうな技術だなと思いました。まぁ、これは実際触ってみないとわからないものですが…他に理由としては、Stackoverflow Surveyで最も愛されたウェブフレームワークに選定されたから、というのもあります。多くのエンジニアが好きという技術は、まずその理由が知りたくなりますので。（同じ理由で、Rustも触ってみたいと思っています）Quarkus会社で使っているSpring bootのビルドとテスト、デプロイにかかる時間を短くしたいのですが、その対策としてQuarkusへの移行を考慮しています。稼働中のサービスのフレームワークを変えるということはかなりのリスキーなことではありますが、成功した場合は生産性も上がり起動速度やメモリのようなメリットがかなりでかい気がしているので、いつになるかはわかりませんが、ぜひ挑戦してみたいタスクとして設定しています。移行に成功しても失敗しても、色々と勉強になりそうではありますね。最後にブログの外見は変わり、十分成功的な移行になったと思いますので、次はその中身を充実にしていくのが課題ですね。今まで通り、一人前のエンジニアになりたいという気持ちを忘れず、少しづつでも前に進むような（そして読まれる方にも役立つような）ポストを書けたらなと思います。では、また！

今年のブログの話

DBを設計する時と、最終的にアプリで活用するデータの形は大きく変わるケースがあります。特に後から機能を付け加えるとそうなりますね。もちろん正規化などを通じてより効率的にデータを保存する方法を考える必要のあるDBと、データをいかに加工して使うかを工夫するアプリの違いによるものもありますが、アプリの改修が続くと同じデータでも活用する箇所や表現の仕方が変わってくるからでもあるかなと思います。そういうわけで、今回はそのようなケースで一つ活用できる方法をご紹介したいと思います。アルゴリズムというわけでもありませんし、より効率的な方法はあるかなと思いますが、応用すれば結構色々な場所で使えそうな方法ではないかと思います。シナリオ例えば以下のようなシナリオがあるとします。社員はA、Bという二つの部署に配属される社員が部署に配属される日付はそれぞれこの場合、データの作りには色々な観点があるかと思いますが、まず部署の配属日を基準にデータを作るとしたら、部署の種類、配属日とその日付に配属となった社員のリストを持つような形になるかと思います。Kotlinのコードとして表現するとしたら以下のような形ですね。enum class DepartmentType { A, B }data class Department( val departmentType: DepartmentType, val date: LocalDate, val employers: List<Employer>) { data class Employer( val id: Int )}ここで社員の3人がいて、それぞれ部署Aと部署Bに配属された日付が違うケースがあるとしましょう。データとしては、以下のようなものです。社員番号部署A配属部署B配属11月1日1月1日21月1日2月1日32月1日2月1日上記のデータを持って、先ほどの部署のデータを実際のリストとして作るとしたら以下のようになるかなと思います。val departments = listOf( Department( departmentType = DepartmentType.A, date = LocalDate.of(2022, 1, 1), employers = listOf( Department.Employer(id = 1), Department.Employer(id = 2) ), ), Department( departmentType = DepartmentType.A, date = LocalDate.of(2022, 2, 1), employers = listOf( Department.Employer(id = 3) ), ), Department( departmentType = DepartmentType.B, date = LocalDate.of(2022, 1, 1), employers = listOf( Department.Employer(id = 1) ), ), Department( departmentType = DepartmentType.B, date = LocalDate.of(2022, 2, 1), employers = listOf( Department.Employer(id = 2), Department.Employer(id = 3), ) ))ただ、これを社員を基準に、それぞれの部署に配属された日付をデータとして加工するにはどうしたら良いでしょうか。社員番号と部署に配属となった日付の二つを持つような形です。例えば、コードで表現すると以下のようなものです。data class JoinedDates( val employerId: Int, val departmentA: LocalDate, val departmentB: LocalDate)つまり、やりたいことは先ほどのdepartmentsを、最終的に以下のようなデータにしたいということですね。[ JoinedDates(employerId=EmployerId(value=1), departmentA=2022-01-01, departmentB=2022-01-01), JoinedDates(employerId=EmployerId(value=2), departmentA=2022-01-01, departmentB=2022-02-01), JoinedDates(employerId=EmployerId(value=3), departmentA=2022-02-01, departmentB=2022-02-01)]データの整列の基準がひっくり返されるので、どうしたら良いかと悩ましくなる場面です。今回は、これを解決した自分の方法を紹介したいと思います。ロジックDepartmentを基準に考えるとEmployerのデータが複数になりますが、これを逆転させて、Employerを基準に複数のDepartmentを持つという形に加工したいというのが今回の要件です。だとすると、考えられるロジックは以下がポイントかなと思います。EmployerのID単位でまとめるEmployerごとにDepartmentをType別に分けた配列を持たせるまずはネスとしているEmployerのリストに入り、そのIDを抽出する必要がありますね。このIDは重複させたくないので、MapのKeyにしておくと良さげです。あとは、そのMapにEmployerのIDがKeyとして存在するかどうかで以下の処理をすると良いでしょう。Keyが存在しない場合は、新しくDepartmentのタイプとその日付をinsertKeyが存在する場合は、そのvalueを取り出してDepartmentのタイプと日付を追加なので、一回DepartmentのListをMapに変換して、さらにJoinedDatesのListに変換することとなります。ちょうど上記の分岐については、compute()を活用するとできるので、中間データとしてのMapがどんな形になるかを考えると良いかなと思います。私の場合はMapの方がデータを取りやすいので、最終的には以下のような処理となりました。fun List<Department>.toJoinedDates(): List<JoinedDates> { // 中間データ val tempMap = mutableMapOf<Int, Map<DepartmentType, LocalDate>>() this.forEach { department -> // Departmentのタイプとその日付のPair val departmentJoined = department.departmentType to department.date department.employers.forEach { employer -> // EmployerのIDがKeyとして存在したら足して、なかったらMapを追加 tempMap.compute(employer.id) { _, value -> value?.let { value + departmentJoined } ?: mapOf(departmentJoined) } } } // 中間データをJoinedDatesのListに変えて返却 return tempMap.map { (id, department) -> JoinedDates( employerId = id, departmentA = department.getValue(DepartmentType.A), departmentB = department.getValue(DepartmentType.B) ) }}共通ロジック化ジェネリックを使ったclassとして上記のロジックを一部分離すれば、似たようなケースで色々使い回せるのではないかと思いましたので、以下のようなコードも書いてみました。class Aggregator<T, K, V, R> { private val tempMap = mutableMapOf<T, Map<K, V>>() // データの追加 fun add(key: T, value: Pair<K, V>) { tempMap.compute(key) { _, existingValue -> existingValue?.let { existingValue + value } ?: mapOf(value) } } // 指定したListとして取得 fun getList(transfer: (T, Map<K, V>) -> R): List<R> { return tempMap.map { transfer(it.key, it.value) } }}これの場合は以下のような使い方ができます。val aggregator = Aggregator<Int, DepartmentType, LocalDate, JoinedDates>()// データの追加departments.forEach { a -> a.employers.forEach { b -> aggregator.add( key = b.id, value = a.departmentType to a.date ) }}// Listの結果を取得val joinedDates = aggregator.getList { id, joinedDate -> JoinedDates( employerId = id, departmentA = joinedDate.getValue(DepartmentType.A), departmentB = joinedDate.getValue(DepartmentType.B) )}汎用性はあるものの、呼び出し元のコードが増えたり、指定している型の意味や意図がよくわからないので適切なKDocやコメントがないと少しわかりにくいところがデメリットかもしれませんね。ただ大事なのは中間データの型とcompute()による分岐処理なので、そこだけをうまく取り出して他でも応用できるかなと思います。最後にサーバサイドKoltinだと、多くの場合にデータをListとして扱うのが普通かなと思いますが、場合によってはMapを使うのもロジックを書いていく中では良い選択になるかと思います。特に、今回紹介したcompute()以外でも、getOrPut()、getOrDefault()などの機能が便利なので色々と活用できる場面が多いかなと思います。この処理は前回のポストでも似たようなものを紹介したことがありますので、興味のある方はそちらも参考にしてください。プログラミング言語が提供するスタンダードライブラリは色々と見逃しやすいところがあるかなと思いますが、よくドキュメントや自動補完で一覧に登場する関数に注目すると、こういう風に必要なものがいきなり現れることもあるかと思います。まだ私もKotlinを触って1年ほどしか経ってないひよこなものなので、これからもどんどん新しい発見があると嬉しいなと思いますね。では、また！

Kotlinでデータの逆転グルーピング

このブログを書き始めてから、今年で4年目となります。振り返ってみるとブログを書き始めた頃はSEとして主にSIerの基盤チームの仕事をしていたので、インフラやライブラリを含めさまざまな技術に触れることが多かったのですが、去年に転職をして本格的に業務系エンジニアとしてバックエンドを担当することになり触れる技術や興味などにも変化があったかなと思います。なので、今回は振り返りを兼ねて今年のロードマップに関して少し述べたいと思います。過去分のポストを振り返ってみると最初は主にJava、Spring、Linux、Jenkinsなどに関するものが多かったのですが、最近はやはりKotlinで使えるさまざまなフレームワークなどに興味が移っている感覚です。基本的にJavaでもKotlinでもJVM言語であることは同じなのでできることや分野は大差なく、転職してからも使っているフレームワークはSpringなのですが、Kotlinの開発元であるJetBrains社がいろいろなフレームワークを開発しているのもあり自然にそれらに興味を持つようになっていますね。Sophomore jinxを克服するSophomore jinxは日本語で「2年目のジンクス」といわれている言葉です。大学2年目になると新入生だった頃と比べ、成績が下がり熱意が消えるというということを指す言葉らしいです。これの意味を拡張して、1年目に新人王などに選ばれた選手がその次の年からは成績が悪化したり、人気の映画の続編が面白くなかったりする場合など最初より何か劣化した場合を指すことになっているとか。自分の場合はエンジニアになってから4年目になるのですが、確かに2年目からは1年目の時と比べ熱意はなくなっている気がします。だからと言って新しい技術に興味がなくなったり、プログラミング自体が飽きたという訳ではありませんが、前はやりたいことがあったらずっとモニタと睨めっこしながら徹夜でコードを書いたりしていたのに、今はとてもそういう気にならないというのが違うところですね。年を取ったためかとも思いますが、これについては自己分析とやりたいこと、そしてできることを冷静に整理して少しづつでも何か成果物を出せるようにしないと思っています。去年もそうでしたが、このようなポストを書くのはそのためでもあります。計画しているもの全てを成せるとは思いませんが、多くの目標の一部でも達成した方が最初から少ない数の目標を立てるよりは良いのかなという気がしています。なので、まずは「やるかどうかわからないけどアンテナは張っておく」という感覚でいろいろな技術に目を通しておこうかなと思っています。Frontend私はJavaScriptとTypeScriptの基礎を研修やUdemyの講座で学んだくらいのレベルで、フロントエンドの仕事をあまりやることがなかったです。しかし、昨今のウェブアプリの開発においてのトレンドをみるとやはりフロントエンドの技術を一つは学んでおいた方が良さげな気もしますし、バックエンドの役割を吸収しているような気配すらするなという気がしますね。何より、エンドユーザにとって画面のないアプリは想像できないので、今まで自分が使うためのAPIやライブラリ、コマンドラインアプリだけでなく本格的にGUIを活用した何かを作ってみるべき時が来たかなと思っています。何よりフロントエンドの場合、数年前はいろいろなライブラリとフレームワークが存在してどれを使った方がいいか全くわからない状況でしたが、最近は3強だといわれていた中でもAngularを抜いたReactとVueのみが生き残り、さらにそれらを基盤にしたフレームワークが登場するなど、そろそろ技術の成熟期と言ってもいい時代になったのではないかと思いますので、React基盤のNext.jsか、Vue基盤のNuxt.jsのどちらかを選べばよい時期なのではと思います。私自身も今年はそのうちのどちらかに触れてみたいなと思っています。せっかくなのでNestJSのようなJavaScript用のサーバサイドフレームワークにも触れてみるのは良いかもしれませんが、サーバサイドというバックグラウンドがある自分にとってはまずはフロントエンドのみでちょうどよいチャレンジかなと思ったりもします。後述しますが、バックエンドではまた別に触ってみたいものもありますのでなおさらですね。Quarkus個人的にはSpringを長く使っていたので、新しいフレームワークを使ってみたいという願望があります。一つのフレームワークに慣れると、それを使い続けるのも選択肢としては悪くないと思いますが、新しい技術にはメリットもデメリットもあるものなので、少なくとも触れてみる必要はあるかなと思います。なので去年はQuarkusとKtorの二つを触ってみました。個人的にはJetBrainsのプロダクトに信用を持っていて、Kotlin向けという点でもKtorは悪くなかったと思ったのですが、機能が不十分であるところや、アーキテクチャで悩ましいところがあるという面で躊躇しています。一方でQuarkusはネイティブにコンパイルでき、Springのライブラリを一部そのまま使えたり、そもそもSpringとあまり変わらない感覚でコードをサクサク書けそうなイメージなので本格的に使用してみたいと思っています。最大の問題はやはり、ネイティブの場合ビルドにかなり時間がかかるということですが、これはCIとの連携をうまくやっていくしかないかもしれませんね。FastAPIいきなりPythonになりますが、FastAPIにも触れてみたいと思っています。以前から違う分野に転職をするとしてもバックエンドはやり続く可能性が高いと思い、いろいろな言語とフレームワークを触ってみたいと思っていました。その候補としてはExpress、Rocket、Vaporなどがあって、これらを全部触ってみた後、最も自分の好みに合ったものをプライベートで使い続けようと思っていたのです。そんな中、Pythonは普段もたまに簡単な自動化のスクリプトを作るなどの目的で使っているので、Djangoを触ってみようかと思っていたところ、最近はFastAPIで爆速の開発ができるという話を聞いて興味を持つようになりました。今もKotlinとSpringで開発はできますが、シンプルなプロジェクトならこういった軽いオプションが一つあっても悪くなさそうな気がします。インタープリタ言語なので起動も早く、Techempowerのベンチマークでも意外と悪くないパフォーマンスを見せてくれているのも魅力的ですが、SwaggerとReDocによるドキュメンテーションが自動で行われるというところがかなり良さげです。なんでもサクッと作れそうな感じがしますね。また、直接使わないとしてもコードが綺麗で勉強になる噂を聞いているので、少なくとも一度はコードを読んでみたくなります。SwiftUI and Jetpack Compose個人的に本当にやりたかった分野は、GUIを持つアプリを作り上げることです。エンジニアという職業を持つ前から作ったのもJavaFXによるデスクトップアプリでしたので。最近はJavaScriptだけでもElectronやReact Nativeなどを使ってなんでもできるという時代にはなっていますが、せっかくJavaとKotlinができるようになったので、ネイティブアプリを作ってみた方が良さそうな気がします。以前Flutterが発表されてまもない時期に、一度React Nativeと一緒にチュートリアルだけ触れてみたことがあるのですが、当時にもFlutterのいわゆる「宣言型GUI」というものに魅力を感じていたのでこれからモバイルをやるとしたらFlutterかなと悩んでいました。最近はモバイルだけでなく、デスクトップアプリやウェブアプリまで作れるようになったのでなおさらでしたね。しかし、SwiftUIとJetpack Composeというものが登場してからは完全にこちらに傾きました。どうしても同時にマルチプラットフォームアプリが開発できるという面ではFlutterが有利だとは思いますが、それと似たような感覚でネイティブのUIが作れられるようになったのでもう悩む必要がないかなという気がします。特に、SwiftUIだとMac用のデスクトップアプリを作ることもできますが、Jetpack Composeならデスクトップアプリだけでなくウェブアプリも作ることができて、さらにKotlin Multiplatform Mobileを使うとビジネスロジックの共有ができるようになるのでこちらの方が自分の場合にはより合うのではないかという気がしています。自分に合うというのは、私がめんどくさがり屋なので一つの言語で全てを解決したいという願望を持っているというだけの話ですが…とにかく一度使ってみて、よかったらフロントエンドでもJetpack Composeを使ってみるのはありかなと思っています。Kotlin/JSという選択肢もありますが、こちらはまた次の機会で。ただこれらのデメリットは、やはりどれもまだ完成されてない技術ということですね。分野を問わず新しい技術のジレンマでもありますが、新技術がどれだけ良くてもそれだけでは完全ではない（もしくはかなり不便）という場面が出てくる可能性があるので、当面は少し様子を見ながらシンプルなアプリを作ってみることから初めてみようと思います。Flutterという良い先例があるので、良さげな機能はすぐに吸収してくれるという期待もあります。Oracle Cloud他のクラウドと比べかなり後発したためか、無料プランでもメモリ1GBのVMインスタンスを二つも提供するという破格の政策で知られたOracle Clouですが、2021年からはさらに選べるVMインスタンスにARM（Ampere A1というオプションを追加しています。Ampereが既存のAMDやIntel製CPUを使うインスタンスと比べて目立つのはやはり性能です。ARMだと互換性の問題がありx86と比べ利用率が下がると思ったためか、無料プランでも4つのOCPU、24GBのメモリという良い性能のインスタンスを提供しています。無料のインスタンスを2つまで作ることができるので、2つのOCPUと12GBのメモリという構成を2つのインスタンスに分けて指定することもできます。個人的には既存の無料で使えるインスタンスが1つのOCPU、1GBのメモリというオプションだったので、Javaアプリのビルドなどヘビーな作業には向いてないのが惜しいところでした。なのでMattermostのサーバとして使うなど軽い感じでしか使い道がなかったのですが、Ampereの導入でCI用サーバなどに使える道もできたかなと思います。Oracle Cloudのホームページで紹介していること以外でも、他のベンチマークを参照するとCPU性能は期待しても良さそうな気がします。無料でOracle DBも提供されているのでそちらを使うか、それともVMインスタンスを一つDB用に使うか、GCPやAWSの無料サービスと組み合わせて使うとかでも色々できそうな気がします。ただ、やはり互換性が気になっていたのですが、個人的にはApple Silicon搭載Macを使ってみながら「意外と悪くない」という結論に至っています。プログラミング言語などはすでにARM対応済みのものが多く、サーバで使うとしたらFFmpeg、ImageMagick、GraphicsMagickなどを使うケースもあるかなと思いますが、どれもARMバージョンをインストールもしくはビルドできるので特に問題はなさそうです。他に問題なら、今の所VMインスタンスを作ろうとしてもハードウェアが十分ではないのか、2つのOCPU以上のスペックでは作れないというのが問題ですね。時間が解決してくれる問題かもしれませんが、いつになったらインスタンスを自由に作れるかわからないというのは確かに問題と言えるでしょう。最後に意欲がないといいつつ、これだけやってみたいものが多いというのはまだ自分がエンジニアとして気持ちが死んでいるわけではないからよかったなと思わせます。本当は意欲がないというより「面倒臭いだけ」と訂正するべきかもですね…というわけで、色々とやりたいことだけを並べてみましたが、今年はそろそろ何か実際使えるアプリを作り出すのを第一の目標にしたいと思っています。何か作ってみるだけでも間違いなく良い経験、良い経歴になるはずなので。では、また！

個人的な2022年のロードマップ

M1 Macが発売されてもう1年以上が経ちます。最初は流石にRosettaがあるとはいえ、ネイティブアプリが少なく問題が起こったり性能が低下するケースも少なくなかったので、すぐにApple Silicon Macを購入しようとは思わなかったのです。それが今はネイティブアプリも増え、OSのアップデートもあったので十分移行しても良いタイミングになっている気がしました。そして今年、M1 ProとM1 Maxを搭載した新しいMacが発表され、既存のintelチップ搭載モデルと比べメリットが多いと思ったので購入を決めることになりました。新しいMacについてはチップの性能という面でも、改善されたハードウェア（ディスプレイやスピーカ、キーボードなど）という面でもかなり良いものになっている印象はありますが、ここではあえてそれらについては述べません。多くのベンマークやレビューなどで明らかになっていることが多いと思いますので、ここではintel機からの移行経験に関して述べさせてください。移行方法まず、Apple Silicon Macに移行を決めてから、以下のような基準を立てました。既存のMacからマイグレーションするなるべくネイティブアプリを使うマイグレーションをすると決めた理由は、現在利用中のアプリの設定を最初から見直したくないものが多かったからです。アーキテクチャが違うのでマイグレーションを行わない方と比べ何か問題になる可能性もあるかと思いましたが、実際使用中の今までは特に問題はなかったので、最初から全てをやり直すということがめんどくさい場合はマイグレーションをしても良さそうです。また、移行には「移行アシスタント」を使いました。この場合、選べる移行の方法は以下の通りです。TimeMachineMacから移行Wi-Fiを使うThunderboltケーブルで接続TimeMachineを使うと最新の状態が反映されないので、使っているMacから移行することにしました。また、データのコピーにかかる時間が最も短いというのでThunderboltで二つのMacを直結して移行を行なっています。移行には時間は思ったよりそう掛からなく、終わった直後の状態は既存のものと変わらなかったです。移行後はApple Siliconネイティブアプリを使いたいので、アプリの情報を一つ一つ確認してUniversalではないものからバイナリを切り替えていくことにしました。バイナリの確認まずマイグレーションが終わった時点で、インストールされているアプリがApple Siliconネイティブであるかどうかを見分ける方法は以下があります。Finderから「情報を見る」アクティビティモニタの「種類」をみる「このMacについて」→「システムレポート」→「ソフトウェア」→「アプリケーション」から探すIs Apple Silicon ready?から探してみる他にもintell版のアプリの場合は最初実行時にRosettaをインストールするか確認するダイアログが出るのでそれで確認するという方法もあります。主にターミナルで使うプログラミング言語などがそうですね。ただ、一度でもRosettaをインストールしたらintell版のバイナリでもダイアログなしで実行されてしまうので、全体の移行が終わるまではRosettaをインストールしない方が良いかと思います。アプリケーションの切り替え以下はUniversal Binary(IntelとApple Siliconの両方に対応)を提供しているので、Intel機から移行した場合でも特に何もしなくて良いです。ChromeEdgeFirefoxEdgeView2Movist ProAmphetamineBandizipObsidianMagnetMacs Fan ControliStat MenusユニコーンMicrosoft Remote DesktopMicrosoft WordMicrosoft PowerPointMicrosoft ExcelMicrosoft OneNoteMicrosoft Outlook一つ、Macs Fan Controlの場合、私はメニューバーにCPUの温度を表示するために使っているのですが、温度を表示する項目を選択する際にintell機だと「CPU PECI」を選べる方が一般的かなと思いますが、Apple Siliconだとそのような項目がありません。しばらく全体的な温度をみたところ、「CPU Performance Core」が最も温度が高いように見えたので、温度を確認したい場合はそれを選んでおいた方がいいかなと思います。バイナリを切り替える必要があるケース以下はApple Silicon用のバイナリを別途提供しているので、ホームページからダウンロードして既存のアプリを上書きするだけで対応できました。Notion DesktopDocker DesktopPostmanZoomWebexdraw.ioただ、DockerはデスクトップアプリそのものはApple Siliconネイティブを使うとしても、イメージがamd64のみ対応するというケースも多いので、ここは色々と検証が必要かなと思います。私の環境ではまだMySQL（5.7）がApple Siliconに対応してなかったのですが、特に問題なく動いています。HomebrewRosettaを使って既存のintell版バイナリを使うこともできるらしいのですが、Apple Siliconに対応したバージョンはインストールされるパスが違うし（既存は/usr/local、Apple Silicon版は/opt/homebrew）、Apple Silicon版だとインストールされるパッケージは基本的にApple Siliconネイティブになるか、intell版でも新しくビルドしてくれるらしいので、使っていたintell版を消して新しくインストールし直すことにしました。アンインストールとインストールは、別に何も意識する必要はありませんでした。公式ホームページに出ている通り、以下のコマンドを実行するだけで良いです。自動でintell版を消してくれて、新しくインストールする場合はApple Silicon版になります。# アンインストール/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"# インストール/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"ただ、homebrewでインストールしたパッケージ関しては自分の場合はとりあえず全部削除しておいて、後で必要になったらそれだけインストールしようという方針でしたが、以下のコマンドで使っていたパッケージのリストがバックアップできるらしいです。/usr/local/homebrew/bin/brew bundle dump開発環境開発環境の構築に関しては色々なケースがあるので、こちらで別途説明します。JetBrains IDEJetBrains社の製品（+ Android Studio）ならToolboxで簡単に管理ができるのですが、このアプリ自体もApple Silicon対応のバイナリに変える必要があります。ToolboxをApple Siliconネイティブに切り替えた後は、メニューからIDEをアンインストール後に再インストールするだけです。もしToolboxを使ってない場合は、使っているIDEのバイナリをダウンロードし直す必要があります。ちなみに、ToolboxからインストールされるIDEは~/Applications/JetBrains Toolboxの配下にLauncherが置かれ、それをシステムレポートなどで確認するとintel版のバイナリになっています。ただ、実行時はちゃんとApple Siliconネイティブになっているので（アクティビティモニタから確認可能）安心してください。Visual Studio CodeVisual Studio Codeの場合は、Universal/Intel/Apple Silicon用のバイナリを全部提供していました。多分あえてIntelバージョンをインストールしてなかったら、自然にUniversalにアップデートされていたのではないかと思います。あえてUniversalを使う必要はなく、サイズが小さいのでApple Siliconバージョンをダウンロードしたほうがいいかなと思います。また、最近はモブプロなどでVisual Studio Live Shareを使うケースが多いかなと思いますが、こちらはまだApple Siliconに対応していません。こちらはGitHubのissueで今後対応する予定だというので、当面は待つしかないですね。JavaJavaの場合、intellだとどのベンダのものを選んでも大差ないですが、Apple Siliconだと少し話が変わってきます。なぜかというと、ベンダ別にApple Siliconに対応しているJDKのバージョンが違うからです。Rosettaを使っていない場合、「bad CPU type in executable」というエラーが発生するので、インストールされているバージョンが各ベンダ別のApple Silicon対応済みのLTSバージョンのJDKの一覧は以下の通りです。JDK対応バージョンAmazon Corretto17Azul Zulu1.8, 11, 17Bellsoft Liberica1.8, 11, 17Eclipse Temurin17Microsoft17Oracle Java SE17SapMachine11, 17上記のJDKのうち、一部はintellijでもダウンロードできるものとなっていて、intellij上ではApple Silicon対応バージョンをaarch64と表示していますのでインストール時は必ず確認しましょう。他にもRed HatやIBM Semeruなどがありますが、こちらの場合はApple Silicon用のJDKを提供していません。最近はどのJDKを選んでも特に問題はないかと思いますので、17を選ぶならOracleのでも良いし、他も好みで選んでも良さそうな気がします。私の場合はずっとAdpotOpenJDKを使っていたので、今回もTemurinを選びました。ただ、Temurinだと11がApple Siliconに対応してないので、そこはZuluを選んでいます。インストールにはhomebrewを使いました。Apple Siliconとは直接的な関係はないですが、以下のコマンドで使うJDKのバージョンを簡単に切り替えできるのでさまざまなベンダのJDKを使ってみるのもありかもですね。export JAVA_HOME=`/usr/libexec/java_home -v 11`$ java -versionopenjdk version "11.0.13" 2021-10-19 LTSOpenJDK Runtime Environment Zulu11.52+13-CA (build 11.0.13+8-LTS)OpenJDK 64-Bit Server VM Zulu11.52+13-CA (build 11.0.13+8-LTS, mixed mode)$ export JAVA_HOME=`/usr/libexec/java_home -v 17`$ java -versionopenjdk version "17.0.1" 2021-10-19OpenJDK Runtime Environment Temurin-17.0.1+12 (build 17.0.1+12)OpenJDK 64-Bit Server VM Temurin-17.0.1+12 (build 17.0.1+12, mixed mode)GraalVMの場合は、まだApple Siliconに対応していません。ただ2020年からGithubのissueがオープンの状態であって、Linux+aarch64に対応したバイナリは提供している状態なので、いずれはリリースされるかと思います。KotlinKotlinは1.5.30からApple Siliconサポートが発表されていますが、これはKotlin/Nativeに関するものなのでKotlin/JVMの場合だとJavaの方だけ気をつけたらいいと思います。こちらもhomebrewでインストールし、特に問題はありませんでした。GradleGradleの場合はv6.8.3を使うプロジェクトがあったので、Javaの設定が終わった後にビルドしてみると以下のようなエラーが出ました。（依存関係やプロジェクトの設定によってエラーの種類は変わる可能性があるかと思います）Java 17で実行した場合Java 17(Temurin)で実行した場合、Gradleそのものが実行時にエラーを吐きます。おそらくrefelction関係でdeprecatedになっていたAPIを使っているのが問題になったのではないかと思います。> java.lang.IllegalAccessError: class org.gradle.internal.compiler.java.ClassNameCollector (in unnamed module @0x8f1317) cannot access class com.sun.tools.javac.code.Symbol$TypeSymbol (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.code to unnamed module @0x8f1317Java 11で実行した場合Java 11で実行するとコンパイルまでは行われるようですが、テスト（junit）の実行で以下のような問題が起こりました。*** java.lang.instrument ASSERTION FAILED ***: "result" with message agent load/premain call failed at src/java.instrument/share/native/libinstrument/JPLISAgent.c line: 422FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failedProcess 'Gradle Test Executor 1679' finished with non-zero exit value 134調べてみると、Gradleはv6.9からApple Siliconに対応したようだったので、ラッパーを最新にバージョンアップ。gradle/wrapper/gradle-wrapper.propertiesのバージョン指定を変えるだけでも対応できますが、以下のコマンドを使っています。./gradlew wrapper --gradle-version=7.3.1 --distribution-type=binいきなりv6.8.3からv7.3.1にアップデートしたのですが、テストまで正常終了しています。このプロジェクトはKotlin + Spring bootの構成なので、もし同じような構成のプロジェクトがあるとしたらJava/Kotlin/Gradleのバージョンアップをおこなってからアプリのビルドを試してみましょう。Ruby / Python / GoRubyとPythonに関してはmacOS上ですでにインストール済みの状態ですが、バージョンやプロジェクトの設定などによっては問題が起こる可能性もあるのでhomebrewでインストールしました。このブログで使っているjekyllはrubyをインストールし直したので同じくインストールし直す必要がありました。こちらもhomebrewでインストールができ、既存のプロジェクトにおいてはなんの問題もなく実行することができました。Pythonの場合、既存のプロジェクトのパッケージを再インストールする必要がありました。でもrequirements.txtがあれば特に問題にはならないくらいです。Goの場合も1.16からApple Siliconに対応しているので、特にバージョンの指定が必要なケースでなければ、homebrewで最新をインストールしても良いかなと思います。ただ、既存のプロジェクトのGOROOTやGOPATHの問題があるので、ホームページから別途ダウンロードして設定する必要のあるケースもあるかと思います。Rosettaを使うしかないケース多くのアプリがApple Siliconに対応してきましたが、バージョンアップそのものが終わったり、Rosettaを通じて問題なく動く（からApple Silicon対応は後回しにするという政策の）アプリに関してはネイティブのバイナリが存在しない場合もあるので、仕方なくRosettaを使うしかないかなと思います。ソースコードをダウンロードして、ローカルでビルドするという方法もあるかと思いますが、使われているSwiftのバージョンが低い場合はXCodeですぐにビルドできない場合もあったりしました。いつかはRosettaのサボートも終わりそうなので、長期的な観点ではこのようなアプリは他のものに代替した方が良いかもしれません。MattermostMattermostはSlackと似たようなコミュニケーションツールで、サーバにインストールすることで無料利用ができるしマークダウンのサポートが優秀だったりするのでプライペートでよく使っています。ただ残念なことに、こちらはまだApple Silicon用の正式リリース版がないようです。正式リリースの予定はあるようなのでバージョンアップまでintell版を使うという選択肢もありますが、GitHubのリポジトリを見るとUniversalとApple Silicon用のバイナリのベータ版も存在しているので、どうしてもRosettaを使いたくない場合はこちらを選んでみても良いかもしれません。KeyboardCleanToolKeyboardCleanToolは、アプリを実行している間に全てのキー入力を無視するという単純なツールです。キーボードが汚れて拭きたいときによく使っていますね。残念ながらこちらもまだApple Siliconに対応していません。同じ会社で開発しているBetterTouchToolはUniversalバイナリで提供されていますが、その対応ができたのも11月のことなので他の製品が全部Apple Siliconに対応するにはかなり時間がかかるかもしれません。このようなアプリは特にネイティブにならなくても困らないものなので、Apple Siliconネイティブ対応はかなり優先順位が低い感がありますね。OneDriveMicrosoft社の製品にしてはかなり珍しいケースですが、対応が遅れていますね。ただ、今月PreviewとしてUniversalバージョンが利用できるようになったらしいので、もうすぐApple Siliconネイティブ版が出るかもしれません。その際にはApp Storeで自動的にアップデートされるはずなので、待つだけですね。FlutterDartはv2.14からNative対応しているのですが、Flutterはまだ未対応らしく、公式を見てもRossettaを推奨しています。なのでRosettaを入れて実行した方が早いですね。他に、flutter doctorを実行していくつか問題が出るケースがあるかと思います。そういう場合は以下の手順で対応できました。cmdline-tools component is missingと出る場合Android StudioからAppearance & Behavior -> System Settings -> Android SDK -> SDK Tools -> Android SDK Command-Line Toolsにチェックを入れるCocoaPods installed but not workingと出る場合brew install cocoapodsでインストール最後に移行が終わって本格的にApple Silicon Macを使ったのはまだ一週間経たないくらいの短い期間ですが、思ったより移行がスムーズで、ネイティブ対応済みのアプリも多かったので、M1が発表された直後の私のように互換性に疑問を持った方がいるとしたら（十分な事前調査を前提として）新しいMacに移行するのもありかも知れないと思います。最初はAppleが公式的に全てのMacをApple Siliconに移行するまで2年という計画を立てたという話をしていましたが、ユーザとしてはより時間がかかるのではないかと思っていました。しかし、実際に触ってみると、今でも十分移行ができる状態になっていると思います。では、また！

Apple Silicon Macに移行する

帳票などで、たまに和暦を処理する必要な時がありますね。例えば元号を表記するとか、和暦の年度を表記するなどの場合があるかと思います。Kotlin(JVM)の場合、西暦だとJavaのAPIのDateやLocalDateなどのAPIを使うと簡単ですが、和暦が必要となるのはごく一部のケースなので方法がなかなか分かりづらいかと思います。なので、今回はKotlinで和暦を扱う方法について少しまとめてみました。JapanseEra / JapaneseDateJavaでは、1.8から和暦で日付を扱えるJapaneseDate及び元号を扱えるJapaneseEraというAPIを提供しています。なのでJapaneseDateのインスタンスを作り、そこからJapaneseEraを取得することで簡単に元号の情報を取得できるようになります。実際の使い方は以下の通りです。// 現在日付のJapaneseDateを取得val japaneseDate = JapaneseDate.now()// JapaneseEraの取得val japaneseEra = japaneseDate.eraJapaneseDateの場合、LocalDateと同じくChronoLocalDateを継承しているのでインスタンスを作成する方法はそう変わりません。なので、以下のようなこともできます。// LocalDateをJapaneseDateに変換val japaneseDateFromLocalDate = JapaneseDate.from(LocalDate.now())// 特定の日付を指定してJapaneseDateval japaneseDateFromSpecificDate = JapaneseDate.of(2000, 12, 31)元号を日本語で表記する和暦を扱う場合にやりたいことは大きく二つかと思います。一つは、元号を文字列として扱うこと、そしてもう一つは、和暦での年度を数字として扱うことです。まずは、元号を文字列として取得できる方法について説明します。まず上記で紹介した通り、JapaneseDateのインスタンスを取得した上で、さらにそのオブジェクトが保持しているJapaneseEraを取得する必要があります。その後、JapaneseEra.getDisplayName()という関数にTextStyleとLocaleを指定して文字列を取得することができます。前者は文字の出力型を指定する列挙型定数で、後者は言語の指定と思ってください。TextStyleの場合、以下のような値があります。他の言語だと指定したものによって出力がかなり変わってくるかもしれませんが、日本語の場合はFULLとNARROWだけで十分ではないかと思います。定数出力例FULL昭和FULL_STANDALONE昭和NARROWSNARROW_STANDALONESSHORT昭和SHORT_STANDALONE昭和Localeの場合、Locale.JAPANやLocale.JAPANESEのどちらを指定しても結果は同じです。ただ、実装としては以下のようになるのでなるべくLocale.JAPANを使った方が良さそうです。Locale作られるBaseLocaleの設定JAPANlanguage = ja, region = JPJAPANESElanguage = ja以下はこれらの定数を渡して元号を文字列として取得する例です。val today = JapaneseDate.now()val era = today.era// 元号を漢字で取得val eraName = era.getDisplayName(TextStyle.FULL, Locale.JAPAN) // 令和元号だけでなく、年度までも合わせて表記したい場合もあるかと思います。その場合に使えるものはDateTimeFormatterです。これもJapaneseDateが実質LocalDateと同じくChronoLocalDateを継承しているから可能なことですね。// 日付を日本語で表記するval formatter = DateTimeFormatter.ofPattern("Gy年", Locale.JAPAN)val todayString = formatter.format(JapaneseDate.now()) // 令和3年もしJava 1.8以前のバージョンを使うなどでLocalDateやJapaneseDateが使えなく、java.util.Dateの方を使うしかない場合は、以下のような方法で年号と年度の取得が可能です。val format = SimpleDateFormat("Gy年", Locale("Ja", "JP", "JP"))val year = format.format(Date()) // 令和3年java.util.Dateを使う場合は、Localeに第3引数のvariantまで指定する必要があるので、既存の列挙型として定義されたものは使えません。また、Locale.ENGLISHなどに設定すると、JapaenseDateを使っている場合でも取得した結果はAD2021年12月5日になります。合字で表記する年号については、Unicodeで合字を取得して使いたい場合もあるかと思います。その場合は、以下のようにUnicodeのMapなどを定義しておいて取得するのが良いかと思います。拡張関数などを定義するのも良いでしょう。val eraUnicodeMap = mapOf( JapaneseEra.MEIJI to "\u337e", // ㍾ JapaneseEra.TAISHO to "\u337d", // ㍽ JapaneseEra.SHOWA to "\u337c", // ㍼ JapaneseEra.HEISEI to "\u337b", // ㍻ JapaneseEra.REIWA to "\u32ff" // ㋿)val era = JapaneseDate.now().era// 元号を合字で取得するval eraUnicode = eraUnicodeMap[era] // ㋿上記のサンプルではJapaneseEraが列挙型なのでそのままキーとしていますが、JapaneseEraは数値としての情報も持っているのでそちらを使う方法もあるでしょう。それぞれの値に対する数値は以下の通りです。JapaneseEra数値MEIJI-1TAISHO0SHOWA1HEISEI2REIWA32021年から2022年の3月の場合は令和3年なので、JapaneseEra.REIWA.valueの値が年度だと勘違いされやすいかなと思います。実際の年度の情報はJapaneseDateの方にあるので注意しましょう。年度を数字で表示するJapaneseEraは元号を得るために使う列挙型定数のクラスなので、これ自体はJapaneseDateの日付情報を持っていません。なので参照できる情報は、あくまでも元となるJapaneseDateが属した元号の情報のみです。なので数値としての年度は、列挙型のChronoFieldをJapaneseDate.get()に渡して取得する必要があります。val today = JapaneseDate.of(2010, 12, 31) // 平成22年// 年度をIntとして取得するval year = today.get(ChronoField.YEAR) // 2010val yearOfHeisei = today.get(ChronoField.YEAR_OF_ERA) // 22これはJapaneseDateがLocalDateと違って、直接yearをgetterで取得できないからです。実際オブジェクトの中を覗いてみると、LocalDateは年月日をintとshortのフィールドとして保持していることに対して、JapaneseDateはLocalDateとint型のyearOfEraを持っていて、get(ChronoField.YEAR_OF_ERA)を通じてはじめてyearOfEraを取得できることになります。getterを用意していないのはおそらくLocalDateとyearOfEraという二つの概念があるからなのではないかと思います。もちろん、Kotlinなのでこれは簡単に拡張関数を書くことでgetterを作ることはできますね。また、日付のオブジェクトとしてLocalDateを使っている場合は場合はChronoField.YEAR_OF_ERAを渡しても西暦の年度が返ってくるので、和暦を使うためにJapaneseDateを使っているかどうかをまず確認しましょう。年度を2桁の文字で表示する厳密に言って和暦とは関係のないことですが、年度を取得して使う場合、一貫して先端に「0」のついた2桁の文字列として扱いたい場合もあるかと思います。JapaneseDateを通じて年度を取得した場合はInt型になるので、1〜9の間は1桁の数字となるわけですが、これを01〜09に表示したい場合は以下の方法が使えます。DecimalFormatを利用する一つは、JavaのAPIであるDecimalFormatを使うことです。小数点の範囲などをわかりやすく指定できるので個人的には好むやり方です。val today = JapaneseDate.now() // 令和3年// 数字を表示するためのフォーマットを指定val decimalFormat = DecimalFormat("00")val year = decimalFormat.format(today) // 03String.formatを利用するもう一つの方法は、Kotlinのスタンダードライブラリの機能であるString.format()を使うことです。性能注視なら、こちらの方法が良いかなと思います。val today = JapaneseDate.now() // 令和3年// 数字を表示するためのフォーマットを指定val year = "%02d".format(today) // 03番外：kotlinx-datetimeKotlinには元々日付や時間を扱うAPIがなかったのですが、2020年からkotlinx-datetimeを提供しています。なのでKotlin/JSやKotlin/Nativeなど、JVM上で動かない場合でも日付を扱える公式のAPIができたわけですが、いくつかの懸念があるのでこれを導入するには検討が必要かと思います。Pre-releaseの段階kotlinx-datetimeはまだpre-releaseの段階で、2021年10月にv0.3.1がリリースされています。なので色々とバグがあったり、思い通りにならない可能性があります。また、開発途中のものなので仕方ありませんが、現時点で提供している機能もjava.timeのAPIに比べて少なく、簡単に年号の計算などができるわけではありません。今は必要最低限の機能だけを提供していると思って良いでしょう。マルチプラットフォーム向けKotlinのスタンダードライブラリ、及びkotlinxとして提供されるライブラリはマルチプラットホームを考慮した実装となっているため、プラットホームが違っても同じ使い方ができるというメリットがありますが、かえってデメリットになる場合もあります。実際、kotlinx-datetimeのJVMの実装は内部的にjata.timeのAPIに依存しているため、JVMだけを使う場合はあえて導入する必要がないともいえます。また、プラットフォームごとに実装が違うということはどこかで予期せぬ例外が発生したり、期待した結果にならないケースも発生しえる、ということにもなるかと思います。java.timeの懸念JapaneseEraでは明治以前（慶応など）の元号は使えませんが、おそらくその理由は和暦でグレゴリウス暦が使われたのは明治からだったという歴史的な背景があるのではないかと思います。また、JapaneseDateでも明治6年(西暦1873年1月1日)以前の日付を指定すると以下のように例外が発生します。Exception in thread "main" java.time.DateTimeException: JapaneseDate before Meiji 6 is not supported at java.base/java.time.chrono.JapaneseDate.<init>(JapaneseDate.java:333) at java.base/java.time.chrono.JapaneseDate.of(JapaneseDate.java:257)なので、単純に帳票を作るなどのケースでなく、歴史的な研究のための日付計算ではここで紹介した方法は使えないケースもあるかと思います。また、JDKのバージョンなどの問題があるためか、JapaneseEra.REIWAの取得ができなく、エラーとなるケースがあるので注意する必要があります。この場合でもvalueの値の取得は問題ないので、少し可読性は低下しながら分岐などの判定に定数をそのまま使うのは避けたほうが良さそうです。（正確な理由はわかりませんが…）最後にいかがでしたか。少し興味本位で調べ始めたもののまとめではありますが、本業の方で実際に必要な処理でもあり、これをどうやって拡張関数として落とせるかということも考えられる良い機会となったかなと思っています。また、JavaのAPIに関してはJavaバージョン別の改元(新元号)対応まとめという良い記事があったので、興味のある方はご一読ください。では、また！

Kotlinで和暦を使う

Kotlinの隠されたコスト、その最後の記事となります。今までの記事もかなり興味深かったですが、今回はさらにKotlinならではの機能に触れているので、Kotlinそのものに対する理解も含めてみる必要があり、さらに深い内容となっているかと思います。今回のアジェンダは、「委譲プロパティ」と「rangeを使ったループ」になります。この記事はExploring Kotlin’s hidden costs - Part 3の内容を要約したものです。委譲プロパティ委譲プロパティとは、getterとsetterが委譲(delegate)というオブジェクトによって実装されたプロパティを指します。これによって再利用可能なカスタムプロパティを作ることができます。class Example { var p: String by Delegate()}委譲オブジェクトはプロパティの設定と読み込みのためgetValue()とsetValue()を実装する必要があります。そしてこれらの関数はプロパティのメタデータ（プロパティ名）とオブジェクトのインスタンスを引数として必要とします。クラスが委譲プロパティとして定義されると、コンパイラは下記のようなコードを生成します。public final class Example { @NotNull private final Delegate p$delegate = new Delegate(); // $FF: 生成されたフィールド static final KProperty[] $$delegatedProperties = new KProperty[]{(KProperty)Reflection.mutableProperty1(new MutablePropertyReference1Impl(Reflection.getOrCreateKotlinClass(Example.class), "p", "getP()Ljava/lang/String;"))}; @NotNull public final String getP() { return this.p$delegate.getValue(this, $$delegatedProperties[0]); } public final void setP(@NotNull String var1) { Intrinsics.checkParameterIsNotNull(var1, "<set-?>"); this.p$delegate.setValue(this, $$delegatedProperties[0], var1); }}一部staticプロパティのメタデータがクラスに追加されます。そして毎回値の設定と読み込みが発生するたびにコンストラクタによる初期化が起こります。委譲インスタンス上記サンプルでは新しい委譲のインスタンスがプロパティの実装のため生成されています。委譲がstatefulの場合にこのようになります。たとえはローカルで計算されたプロパティを使うなどの場合です。class StringDelegate { private var cache: String? = null operator fun getValue(thisRef: Any?, property: KProperty<*>): String { var result = cache if (result == null) { result = someOperation() cache = result } return result }}またコンストラクタに追加のパラメータが渡されると、新しい委譲のインスタンスが必要となります。class Example { private val nameView by BindViewDelegate<TextView>(R.id.name)}statelessであり、すでに渡されたオブジェクトのインスタンスとプロパティ名を保ちたいだけなら委譲クラスにobjectをつけてsingletonにする方法があります。たとえば下記のようなものです。object FragmentDelegate { operator fun getValue(thisRef: Activity, property: KProperty<*>): Fragment? { return thisRef.fragmentManager.findFragmentByTag(property.name) }}また既存のオブジェクトを拡張して委譲することもできます。つまり、getValue()やsetValue()を拡張関数として定義することもできるということです。KotlinではすでにMapとMutableMapに拡張関数として委譲するパターンを使っています。（プロパティ名をキーで使っています）もし一つのクラス内でローカルの委譲インスタンスに複数のプロパティを保持して再利用したいなら、そのクラスのコンストラクタでインスタンスを初期化しましょう。Kotlin 1.1以降、関数内のローカル変数を委譲プロパティにすることもできます。この場合、委譲は後で初期化できます。クラスに定義された委譲プロパティごとにオーバーヘッドとメタデータの追加が発生するのでなるべくプロパティを再利用できるようにした方が良いでしょう。また、定義したい項目が多い場合に、果たして委譲プロパティが良い選択肢であるかを考慮すべきです。ジェネリック委譲委譲関数はジェネリックでも定義できます。なので委譲クラスをさまざまな型のプロパティとして定義することもできます。private var maxDelay: Long by SharedPreferencesDelegate<Long>()ただ、上記のようにprimitiveをジェネリック委譲を使う場合、boxingとunboxingが値の指定と読み込みで発生することに注意する必要があります。これはプロパティがnon-nullの場合でも起こることです。なのでnon-nullなprimitive型の委譲プロパティを定義する場合はジェネリックで定義を避けたほうが良いです。スタンダード委譲（lazy()）KotlinではDelegates.notNull()、Delegates.observable()やlazy()のような委譲のための標準機能が存在しています。lazy()は読み込み専用の委譲プロパティのための関数です。初めて読み込みが発生する際、プロパティを初期化するた目にlambdaを指定できます。private val dateFormat: DateFormat by lazy { SimpleDateFormat("dd-MM-yyyy", Locale.getDefault())}これはその値が実際に読み込まれるまで高いコストの初期化を遅延させるという、パフォーマンスと可読性の側面で優れた方法です。ただ、lazy()はinline関数ではなく、引数として渡されたlambdaは別のFunctionクラスとしてコンパイルされ、戻り値の委譲オブジェクトもまたinline化されないことには注意する必要があります。そしてlazy()関数で見逃しやすいのはmodeという引数で戻り値の委譲タイプを決められるということです。public fun <T> lazy(initializer: () -> T): Lazy<T> = SynchronizedLazyImpl(initializer)public fun <T> lazy(mode: LazyThreadSafetyMode, initializer: () -> T): Lazy<T> = when (mode) { LazyThreadSafetyMode.SYNCHRONIZED -> SynchronizedLazyImpl(initializer) LazyThreadSafetyMode.PUBLICATION -> SafePublicationLazyImpl(initializer) LazyThreadSafetyMode.NONE -> UnsafeLazyImpl(initializer) }modeを指定していない場合、デフォルトとしてはLazyThreadSafetyMode.SYNCHRONIZEDが使われますが、これは複数のスレッドで初期化ブロックが安全に実行されることを保証するためにコストの高いdouble-checked lockを行います。シングルスレッドしかプロパティに対するアクセスがないというのがわかっているなら、無駄なロックは下げた方がいいでしょう。こういう場合はLazyThreadSafetyMode.NONEを使えます。val dateFormat: DateFormat by lazy(LazyThreadSafetyMode.NONE) { SimpleDateFormat("dd-MM-yyyy", Locale.getDefault())}RangesRangesで限定された範囲の値のセットを定義できます。この値はComparableなものならなんでも指定できますね。そして、この表現式を使うとClosedRangeというインタフェースの実装ができることになります。包含テストrangeを使って範囲内に特定の値が含まれているかどうかをinや!inを使って検知することができます。if (i in 1..10) { println(i)}rangeはnon-nullなprimitive型（Int, Long, Byte, Short, Float, Double, Char）に対する最適化が行われるので、コンパイルされた結果は以下のようになります。if(1 <= i && i <= 10) { System.out.println(i);}なので、オーバーヘッドや追加オブジェクトの割り当てなどは起こらないです。しかし、primitiveではない場合はどうでしょう。if (name in "Alfred".."Alicia") { println(name)}Kotlin 1.1.50以前はコンパイル時にClosedRangeオブジェクトが常に生成されました。しかし、1.1.50からは以下のようになります。if(name.compareTo("Alfred") >= 0) { if(name.compareTo("Alicia") <= 0) { System.out.println(name); }}rangeはまた、whenの条件式でも使えます。if-elseより可読性が良くなりますね。val message = when (statusCode) { in 200..299 -> "OK" in 300..399 -> "Find it somewhere else" else -> "Oops"}ただ、rangeを使う場合、特定の値が含まれているかどうかをチェックするとき、指定された範囲とそれを使うコードの間に間があるとコストがかかることになります。たとえば以下のようなコードがあるとします。private val myRange get() = 1..10fun rangeTest(i: Int) { if (i in myRange) { println(i) }}この場合はコンパイルするとIntRangeオブジェクトが追加されます。private final IntRange getMyRange() { return new IntRange(1, 10);}public final void rangeTest(int i) { if(this.getMyRange().contains(i)) { System.out.println(i); }}これはプロパティのgetterをinlineとして定義しても同じです。なのでなるべくrangeが使われるテストの方に直接書くことでオブジェクトが追加されない要因した方が良いです。また、primitiveではないオブジェクトを使う場合は定数として定義し、ClosedRangeのインスタンスを再利用する方法があります。forループFloatとDoubleを除いたprimitive型の範囲をループで使うのも良い選択です。for (i in 1..10) { println(i)}コンパイルされた結果にはオーバーヘッドが発生しません。int i = 1;for(byte var2 = 11; i < var2; ++i) { System.out.println(i);}逆順にループしたい場合はdownTo()を使えます。for (i in 10 downTo 1) { println(i)}これにもまた、オーバーヘッドは発生しません。int i = 10;byte var1 = 1;while(true) { System.out.println(i); if(i == var1) { return; } --i;}untilを使って特定の値未満にループするのも良いですね。for (i in 0 until size) { println(i)}以前は少しコストがかかることになりましたが、Kotlin 1.1.4以降は以下のようなコードが生成されます。int i = 0;for(int var2 = size; i < var2; ++i) { System.out.println(i);}ただ、そのほかは最適化があまり効いてないケースもあります。reversed()を使う例があるとしましょう。for (i in (1..10).reversed()) { println(i)}コンパイルされたコードがあまり綺麗とは言えません。IntProgression var10000 = RangesKt.reversed((IntProgression)(new IntRange(1, 10)));int i = var10000.getFirst();int var3 = var10000.getLast();int var4 = var10000.getStep();if(var4 > 0) { if(i > var3) { return; }} else if(i < var3) { return;}while(true) { System.out.println(i); if(i == var3) { return; } i += var4;}IntRangeオブジェクトが範囲を再定義するため生成され、さらにIntProgressionオブジェクトが逆順に要素を整列するために生成されます。progressionを作るのに二つ以上の関数が使われていると、二つ以上のオブジェクトを作るようなオーバーヘッドが発生することになります。上記のルールはstep()を使う場合も同じで、step 1を指定しても状況は変わりません。for (i in 1..10 step 2) { println(i)}さらに、生成されたコードで最後の値を読み込む時、IntProgressionオブジェクトの最後の要素とstep()で指定した範囲を考慮して追加の処理が行われます。上記のサンプルだと最後の要素は9です。なので、forを利用したループをするときはなるべく..、downTo()、until()を利用してオーバーヘッドを避けた方が良いでしょう。forEachループforループの代わりに、rangeに対してinline拡張関数のforEach()を使う場合も結果はあまり変わりません。(1..10).forEach { println(it)}しかし、forEach()はIterableに対してのみ最適化されてないです。これはつまり、iteratorを生成する必要があるということを意味します。なので、コンパイルされると以下のようになります。Iterable $receiver$iv = (Iterable)(new IntRange(1, 10));Iterator var1 = $receiver$iv.iterator();while(var1.hasNext()) { int element$iv = ((IntIterator)var1).nextInt(); System.out.println(element$iv);}これは今までのサンプルよりもコストのかかるものです。IntRangeオブジェクトを生成するだけでなく、IntIteratorオブジェクトも生成しているからです。primitiveではない場合はさらにコストがかかるでしょう。なので、rangeを使ったループが必要な場合はforEach()よりforループを使ってオーバーヘッドを減らした方が良いです。collectionインデックスループKotlinのスタンダードライブラリはindicesという拡張プロパティで配列とCollectionのインテックスを提供します。val list = listOf("A", "B", "C")for (i in list.indices) { println(list[i])}indicesのコンパイルされた結果は良い最適化を見せてくれます。List list = CollectionsKt.listOf(new String[]{"A", "B", "C"});int i = 0;for(int var2 = ((Collection)list).size(); i < var2; ++i) { Object var3 = list.get(i); System.out.println(var3);}IntRangeオブジェクトが作られてないです。では、自前で実装してみるとどうなるのでしょう。inline val SparseArray<*>.indices: IntRange get() = 0 until size()fun printValues(map: SparseArray<String>) { for (i in map.indices) { println(map.valueAt(i)) }}拡張プロパティとして定義してコンパイルすると、あまり効率的ではないコードになっていることがわかります。IntRangeオブジェクトが作られてます。public static final void printValues(@NotNull SparseArray map) { Intrinsics.checkParameterIsNotNull(map, "map"); IntRange var10000 = RangesKt.until(0, map.size()); int i = var10000.getFirst(); int var2 = var10000.getLast(); if(i <= var2) { while(true) { Object $receiver$iv = map.valueAt(i); System.out.println($receiver$iv); if(i == var2) { break; } ++i; } }}この場合は代わりにuntil()とforループを使った方が良いでしょう。fun printValues(map: SparseArray<String>) { for (i in 0 until map.size()) { println(map.valueAt(i)) }}最後にいかがでしたか。個人的にはあまり委譲プロパティを使ったことがなく、そもそもの理解を兼ねてかなり勉強になりました。また、rangeに関しても、Javaでの習慣でテストクラスのフィールドとして定義していろいろな関数で使い回していましたが、まさかそれがよりコストのかかることだとは思ってなかったので少しショックでした。また、改めてKotlinで提供している機能とAPIに対して正しく理解する必要があると思いました。そしてオッカムの剃刀でも話しているように、なるべくシンプルなロジックとコードを追求する必要があるとも思いましたね。intellijのメニューのうち、Tools > Kotlin > Show Kotlin Bytecode でいつでもJavaのコードにdecomplieされたコードを確認できるので、最新だとどのように変換されるのかを確認してみながらコードを最適化を行なった方が良いかもしれません。今月はいつもの、自分の経験や仮説を紹介するようなポストでなく、ほぼ翻訳のみになってしまいましたが、私自身としてはかなり貴重な知識を得られたと思っています。またの機会で何か良いものがあったら、是非とも紹介させていただきたいですね。では、また！

Kotlinの隠されたコストーその３

今回はまたKotlinの隠されたコストに対するポストです。今となってはあまり気にすることはないかもしれませんし（検証は必要そうですが、バージョンアップごとにコンパイラが生成するコードを追うのは大変そうですね…）、極限のチューニングをするよりもマシンスペックを上げた方がよい時代になったとはいうものの、この記事で紹介していることをコーディングの習慣として身につけておくと良いかなと思います。前回は高階関数とLambda、そしてcompanion objectに関する記事を紹介しました。今回はローカル関数、Null安定性、Varargsに隠されたKotlinのコストについて述べます。この記事はExploring Kotlin’s hidden costs - Part 2の内容を要約したものです。ローカル関数関数内に定義した関数を「ローカル関数」と言います。これらローカル関数は、アウター関数（ローカル関数が定義された関数）の範囲にアクセスできます。例えば以下だと、sumSquareでsomeMathのパラメータにアクセスしているのがわかります。fun someMath(a: Int): Int { fun sumSquare(b: Int) = (a + b) * (a + b) return sumSquare(1) + sumSquare(2)}ローカル関数は基本的にLambdaと似ていますが、他に制限があります。ローカル関数そのものと、ローカル関数を含む関数もまたinlineとして定義できません。なので関数の呼び出しにかかるコストを避ける方法がありません。コンパイルされたローカル関数はFunctionオブジェクトに変わります。なので前回の記事で述べた「インライン化してないLambda」と同じ問題を持っています。上記のコードをJavaのコードで表すと以下のような形になります。public static final int someMath(final int a) { Function1 sumSquare$ = new Function1(1) { // $FF: 生成されたメソッド // $FF: ブリッジメソッド public Object invoke(Object var1) { return Integer.valueOf(this.invoke(((Number)var1).intValue())); } public final int invoke(int b) { return (a + b) * (a + b); } }; return sumSquare$.invoke(1) + sumSquare$.invoke(2);}ただ、Lambdaと比べ一つ性能が劣化されない点があります。関数のインスタンスが呼び出し元からわかるので、ジェネリックなインタフェースを使わず、匿名クラスになりメソッドが直接呼び出されます。これは外の関数からローカル関数を呼び出す際に、castingやboxingが発生しないということを意味します。実際のBytecodeを見ると以下の通りです。ALOAD 1ICONST_1INVOKEVIRTUAL be/myapplication/MyClassKt$someMath$1.invoke (I)IALOAD 1ICONST_2INVOKEVIRTUAL be/myapplication/MyClassKt$someMath$1.invoke (I)IIADDIRETURNここでメソッドが2回呼び出されていますが、メソッドの引数も戻り値もint型になっていて、boxingとunboxingがないのを確認できます。ただ、依然としてメソッドが呼び出されるたびにFunctionオブジェクトのインスタンスを生成していますが、ローカル関数をvalue caputeなしのものに代替することでこの問題は回避できます。fun someMath(a: Int): Int { fun sumSquare(a: Int, b: Int) = (a + b) * (a + b) return sumSquare(a, 1) + sumSquare(a, 2)}上記のようにすることで、Functionオブジェクトのインスタンスは再利用できるようなものになります。こうすることで既存のprivate関数に比べ、ローカル関数のデメリットは追加のクラス（メソッドを含む）を生成するということだけになります。ローカル関数はprivate関数の代替として、アウター関数の変数にアクセスできるというメリットがあります。ただこれによってFunctionオブジェクトを生成するというコストがかかりますので、non-capturingにする工夫が必要です。Null安全性Kotlinの最も良い機能の一つは明視的にnullになり得る型とそうでない型を区別できるということです。これによってコンパイラがランタイムで予期せぬNullPointerExceptionを投げるのを防止できます。Non-nullパラメータのランタイムでのチェック例えば以下のような関数があるとします。fun sayHello(who: String) { println("Hello $who")}これはJavaのコードで以下のようになります。public static final void sayHello(@NotNull String who) { Intrinsics.checkParameterIsNotNull(who, "who"); String var1 = "Hello " + who; System.out.println(var1);}@NotNullアノテーションが追加され、Java側にnullが渡されてはいけないということを知らせています。しかし、アノテーションは呼び出し側にnull safetyを強制するものではありません。なのでstaticメソッドを呼び出してパラメータをもう一度確認しています。この関数はIllegalArgumentExceptionを投げて呼び出し元の修正を簡単にします。publicな関数には常にnon-nullなパラメータに対してIntrinsics.checkParameterIsNotNull()でのチェックがが追加されますが、privateな関数に対しては追加されません。なぜなら、Kotlinクラスはnull safeであることをコンパイラが保証するからです。このNullチェックによるパフォーマンスへの影響は無視しても良いほどでテストにも有用ですが、ビルド時にもっと時間がかかる原因になります。これに対してはコンパイラのオプションに-Xno-param-assertionsを追加するか、ProGuardのルールに以下の設定を追加することでランタイムNullチェックをなくすことができます。-assumenosideeffects class kotlin.jvm.internal.Intrinsics { static void checkParameterIsNotNull(java.lang.Object, java.lang.String);}ただ上記のルールを追加する場合、AndroidのProGuardのOptimization設定が有効になっているかのチェックがまず必要です。この設定はデフォルトでは無効になっています。Nullable primitive型まず先に覚えておくべきことは、nullableで宣言したprimitive型は常にJavaのintやfloatなどの代わりにInteger、Floatといったboxed reference型が使われるので追加のコストが発生するということです。autoboxingとnull-safetyを無視するのでJavaではIntegerでもintでもコードはあまり変わらないJavaに対して、Kotlinだとnullableに対して安全なコードを書くように強制しているので、non-nullの方を使った方が良いというのが明確にわかります。fun add(a: Int, b: Int): Int { return a + b}fun add(a: Int?, b: Int?): Int { return (a ?: 0) + (b ?: 0)}なので、なるべくコードの可読性と性能を考慮してnon-nullの方を選んだ方が良いです。配列Kotlinには、以下の3通りの配列があります。IntArray、FloatArrayのようなもの：primitive型の配列。int[]、float[]のような型にコンパイルされる。Array<T>：non-nullオブジェクトの型が指定された配列。primitiveに対してboxingが起こりえる。Array<T?>：nullableオブジェクトの型が指定された配列。明確にboxingが起こる。もしnon-nullなprimitive型の配列が必要な場合は、なるべくArray<Int>の代わりにIntArrayを使いましょう。VarargsKotlinではJavaとは書き方が少し違いますが、可変長引数を定義することができます。fun printDouble(vararg values: Int) { values.forEach { println(it * 2) }}Javaと同じく、varargはコンパイルされると指定した型の配列になります。そして上記の関数は以下のように、３つの方法で呼び出すことができます。複数のパラメータを渡すprintDouble(1, 2, 3)Kotlinのコンパイラはこれを新しい配列の生成と初期化に変えます。これはJavaと一緒です。printDouble(new int[]{1, 2, 3});これはつまり新しい配列を作るためのオーバヘッドがあるということです。ただJavaと変わらないやり方です。配列を渡すJavaでは配列をそのまま渡すことができますが、Kotlinだとそれができず、spread operatorを使う必要があります。val values = intArrayOf(1, 2, 3)printDouble(*values)Javaでは配列の参照がas-isとして関数に渡され、新しい配列の割り当ては起こりません。しかし、Kotlinのspread operatorは以下のようなことをします。int[] values = new int[]{1, 2, 3};printDouble(Arrays.copyOf(values, values.length));配列のコピーが関数に渡されるので、より安全なコードといえます。呼び出し側には影響なしで、配列を修正できますので。しかしメモリを追加的に消費してしまいます。配列と他の引数を混ぜて渡すspread operatorの良い点は、配列と他の引数を混ぜて渡すこともできるということです。val values = intArrayOf(1, 2, 3)printDouble(0, *values, 42)この場合はどうコンパイルされるか気になりませんか？結果はかなり面白いです。int[] values = new int[]{1, 2, 3};IntSpreadBuilder var10000 = new IntSpreadBuilder(3);var10000.add(0);var10000.addSpread(values);var10000.add(42);printDouble(var10000.toArray());配列を新しく生成するだけでなく、一時的なビルダオブジェクトを使って配列の最終的なサイズを計算しています。なので配列を渡す時よりもコストは追加されます。なので、呼び出される回数の多くパフォーマンスが重要なコードに対してはなるべく可変長引数より実際の配列をパラメータとして使った方が良いです。最後にいかがでしたか。個人的にprivate関数をよく使うので、よりスコープを制限できるという面でローカル関数を積極的に使いたいと思っていましたが、ここでも隠されたコストがあるというというのは興味深かったです。primitive型についてはJavaがそうだったので、なんとなくboxingが起こるんじゃないかなと思っていたものの、nullableに対してのみそうだというのも面白かったですね。逆に、primitiveのままになるnon-null型に対してはどうやってチェックが走るのだろうという新しい疑問もありました。（例えばintだとデフォルト値の0が常に割り当てられるので）あと、配列の場合はJavaでもIntStream、DoubleStreamなどがあったのでなんとなくすぐ理解ができましたが、まさかvarargsで渡したパラメータに対して色々とコストが追加されるとは思わなかったです。そもそもあまり配列を使わないので、可変長引数を使う場面もなかったのですが…よく使わないものほど重要なことを忘れやすそうなので、これは覚えておかないとですね。色々と勉強になりました。では、また！

Kotlinの隠されたコストーその２

Kotlinは便利ですが、何が便利かというと代表的に挙げられるものがたくさんのシンタクスシュガーではないかと思います。同じJVM言語のJavaと比べ、多くの場合でコード量が劇的に減るのが嬉しいという評価も多いものですね。しかし、この便利さの裏には隠されたコスト（性能面での）があるという話があります。今回はそれについて説明している良い記事を見つけたので、共有したいと思います。ただ、翻訳よりは要約に近いものなので、そこはご了承ください。ちなみにここで紹介している記事（Exploring Kotlin’s hidden costs - Part 1）は、2017年に作成された（Kotlinがまだ1.1だったころ）ので、1.5にまでバージョンアップを成している今からすると、コンパイラの改善などで少し状況が違うケースもあるかと思いますが、述べている内容のレベルが高いので一度は目を通してみても良いかなと思います。また、記事で紹介しているKotlinのBytecodeに対しても、直接最近のKotlinが生成しているコードと比較してみるのも面白いかもですね。また、今回紹介している記事はPart 1ですが、そのほかにもPart 2やPart 3の記事がありますので、今後も順次紹介させていただきたいと思います。では、まずLambda表現式とcompanion object編を、どうぞ。高階関数とLambda表現式例えば以下のような関数を定義しておいたとしましょう。渡されたパラメータをDBのトランザクションの中で実行し、実行結果の行数を返すものです。fun transaction(db: Database, body: (Database) -> Int): Int { db.beginTransaction() try { val result = body(db) db.setTransactionSuccessful() return result } finally { db.endTransaction() }}上記の関数は、Lambdaを渡して以下のように使えますね。val deletedRows = transaction(db) { it.delete(“Customers”, null, null)}KotlinはJava 1.6のJVMから使えますが、Java 1.6のJVMではLambdaに対応していないのです。なので、Kotlinはその互換性を維持するためにLambda（匿名関数も）をFunctionというオブジェクトを生成することで対応しています。Functionオブジェクトでは、実際コンパイルされたLambda（body）がJavaのコードとしてはどうなっているかをみていきましょう。（ここでは、Intellij/Android StudioのShow Kotlin BytecodeのDecompile機能を使っています）class MyClass$myMethod$1 implements Function1 { // $FF: 生成されたメソッド // $FF: ブリッジメソッド public Object invoke(Object var1) { return Integer.valueOf(this.invoke((Database)var1)); } public final int invoke(@NotNull Database it) { Intrinsics.checkParameterIsNotNull(it, "it"); return it.delete("Customers", null, null); }}これを見るとわかりますが、Lambda（匿名関数）を使う場合、コンパイルされた結果としては基本的に3、4個のメソッドが追加で生成されるということになります。ここで追加されたFunctionオブジェクトのインスタンスは、必要な時にだけ生成されます。正確には、以下のような動作をします。value captureがある場合、毎回パラメータが渡されるたびFunctionのインスタンスが生成され、GCの対象になるvalue captureがない場合、FunctionはSingletonとしてインスタンスが生成され再利用できる先ほどのコードでは、value captureがないため、Lambdaの呼び出し元は以下のようなコードとしてコンパイルされます。this.transaction(db, (Function1)MyClass$myMethod$1.INSTANCE);しかし、value captureのある高階関数を繰り返し呼び出す場合はGCによる性能の低下を考えれます。BoxingオーバーヘッドLambdaに対応しているJava 1.8以降のバージョンでは、Functionインタフェースを複数提供していることでなるべくboxing/unboxingを避けようとしています。しかし、Kotlinでコンパイルされた場合はgenericを利用しています。/** 引数を一つ受け取る関数 */public interface Function1<in P1, out R> : Function<R> { /** 引数を受け取り関数を実行する */ public operator fun invoke(p1: P1): R}これらをみてわかるのは、高階関数でパラメータとして渡された関数を呼び出す時に、その関数にprimitiveタイプの値が存在する場合（パラメータ、もしくは戻り値）boxing/unboxingが起こるということです。先ほどのコンパイルされたLambdaにおいて、戻り値がIntegerとしてboxingされたのを確認できましたね。primitiveタイプを使用するLambdaをパラメータとしてとる高階関数は、参照回数が少なければあまり意識しなくてもよいコストになりますが、そうでない場合は性能に影響があると推定できます。Inline関数幸い、Kotlinではinlineと言うキーワドを提供しています。これを使うと高階関数をインライン化できますね。インライン化されると呼び出し元のコードにFunctionの中身を直接含ませてコンパイルします。なので、インライン化された場合は以下のような面で性能の向上を考えられます。Functionオブジェクトのインスタンスが生成されないprimitiveタイプを使う関数に対してboxing/unboxingが起こらないメソッドカウントが増えない（Androidの場合、アプリが参照できるメソッドの数字に制限がある）関数の呼び出しが増えない（CPU依存が高く、呼び出される頻度の高いコードのパフォーマンスの改善を期待できる）インライン化された場合のコードを確認してみましょう。transaction関数が消え、db.deleteを直接呼び出しているのがわかります。また、戻り値のresultもWrapperクラスからprimitiveタイプになっているのがわかります。db.beginTransaction();try { int result$iv = db.delete("Customers", null, null); db.setTransactionSuccessful();} finally { db.endTransaction();}ただ、inlineキーワードを使うときは以下のことを考慮しなければならないです。インライン関数は自分自身を直接呼び出したり、他のインライン関数から呼び出せないクラスに定義されたpublicなインライン関数はそのクラスのpublic関数とフィールドのみアクセスできるコンパイルされたコードが大きくなる（繰り返し参照される場合はより大きくなる）なるべく高階関数をインライン化し、必要であれば長いコードブロックをインラインではない関数に写した方がいいです。また、性能が大事なところでは呼び出された関数をインライン化することも考えられます。Companion objectKotlinではクラスがstaticなフィールドやメソッドを定義できません。その代わりにcompanion objectを使うことになっていますね。クラスのprivateフィールドをcompanion objectからアクセスする以下のような例があるとしましょう。class MyClass private constructor() { private var hello = 0 companion object { fun newInstance() = MyClass() }}上記のコードがコンパイスされると、companion objectはSingletonクラスになります。なので、クラスのprivateフィールドに外部クラスからアクセスできるようにする必要があり、コンパイラがgetter、setterを追加で生成することになるということです。生成されたメソッドはcompanion objectから参照されることになります。以下を見てください。ALOAD 1INVOKESTATIC be/myapplication/MyClass.access$getHello$p (Lbe/myapplication/MyClass;)IISTORE 2Javaだとこれを避けるためにアクセス制限をpackage単位にすることができましたが、Kotlinではそのようなキーワードがないですね。publicやinternalを使う場合もgetterとsetterは基本的に生成されます。また、これらのメソッドはinstanceメソッドであり、staticメソッドよりもコストが高いですね。なので、最適化のためフィールドのアクセス制限を変えるということは避けた方が良いです。もしcompanion objectからクラスのフィールドに頻繁なアクセスが発生するとしたら、この隠れているメソッドの呼び出しを避けるためにフィールドの値をキャッシュするという方法も考慮できます。Companion objectの定数にアクセスするKotlinでは、クラス内のstaticな定数はcompanion objectの中に定義するのが一般的です。class MyClass { companion object { private val TAG = "TAG" } fun helloWorld() { println(TAG) }}一見シンプルで良さげなコードですが、Kotlin 1.2.40以前の場合だとかなり裏のコードは汚くなっています。Kotlin 1.2.40以前の場合companion objectに定義されたprivateな定数にアクセスする場合、上記のようなこと（getterを利用する）が起こります。GETSTATIC be/myapplication/MyClass.Companion : Lbe/myapplication/MyClass$Companion;INVOKESTATIC be/myapplication/MyClass$Companion.access$getTAG$p (Lbe/myapplication/MyClass$Companion;)Ljava/lang/String;ASTORE 1問題はこれだけではありません。生成されたメソッドは実際の値を返すわけでなく、instanceメソッドとして生成されたgetterを呼び出すことになります。ALOAD 0INVOKESPECIAL be/myapplication/MyClass$Companion.getTAG ()Ljava/lang/String;ARETURN定数がpublicになっている場合はダイレクトにアクセスできるようになりますが、依然としてgetterメソッドを通して値にアクセスことになります。そして定数の値を格納するために、Kotlinコンパイラはcompanion objectではなく、それを持つクラスの方にprivate static finalフィールドを生成します。さらにcompanion objectからこのフィールドにアクセスするため、またのメソッドを生成することとなります。INVOKESTATIC be/myapplication/MyClass.access$getTAG$cp()Ljava/lang/String;ARETURNこういう長い道のりで、やっと値を読み込むことになります。GETSTATIC be/myapplication/MyClass.TAG : Ljava/lang/String;ARETURNまとめると、Kotlin 1.2.40以前のバージョンを使っている場合は以下のようになります。companion objectから静的メソッドを呼び出すcompanion objectからinstanceメソッドを呼び出すクラスのstaticメソッドを呼び出すstaticフィールドから値を読み込むこれをJavaのコードで表現すると以下の通りです。public final class MyClass { private static final String TAG = "TAG"; public static final Companion companion = new Companion(); // 生成されるメソッド public static final String access$getTAG$cp() { return TAG; } public static final class Companion { private final String getTAG() { return MyClass.access$getTAG$cp(); } // 生成されるメソッド public static final String access$getTAG$p(Companion c) { return c.getTAG(); } } public final void helloWorld() { System.out.println(Companion.access$getTAG$p(companion)); }}よりコストの低いBytecodeを生成することも可能ですが、それは簡単ではないです。まずconstキーワードを使ってコンパイルタイム定数を定義することでメソッドの呼び出しをなくすことができます。しかし、KotlinではprimitiveかStringに対してのみ可能な方法です。class MyClass { companion object { private const val TAG = "TAG" } fun helloWorld() { println(TAG) }}または@JvmFieldを使ってJavaのアプローチを取る方法を考えられます。こうすることでgetterやsetterが生成されず、フィールドに直接アクセスができるようになります。ただ、@Jvm系のアノテーションはJavaとの互換性のためのものであるのでこれが果たして良い方法かどうかを考えた方が良いでしょう。そしてpublicなフィールドのみ可能な方法です。Androidの開発の場合だと、Parcelableオブジェクトを自前で実装する場合のみ有効な方法に思われます。例えば以下のようにですね。class MyClass() : Parcelable { companion object { @JvmField val CREATOR = creator { MyClass(it) } } private constructor(parcel: Parcel) : this() override fun writeToParcel(dest: Parcel, flags: Int) {} override fun describeContents() = 0}最後の方法として、ProGuardやR8のようなツールを使ってBytecodeの最適化を狙うという方法があるでしょう。Kotlin 1.2.40以降の場合Kotlinn 1.2.40からは、companion objectに定義された値はメインクラスの方に格納されるということには変わりがありませんが、メソッドの生成と呼び出しなしで直接アクセスができるようになりました。これをJavaのコードとして表現すると以下の通りです。public final class MyClass { private static final String TAG = "TAG"; public static final Companion companion = new Companion(); public static final class Companion { } public final void helloWorld() { System.out.println(TAG); }}また、上記のようにcompanion objectにメソッドが一つもない場合は、ProGuardやR8によるツールと使うとクラス自体が消えることで最適化されます。ただ、companion objectに定義さえたメソッドの場合はコストが少しかかります。フィールドがメインクラスの方に格納されてあるため、companion objectに定義されたprivateフィールドにアクセスするためには依然として生成されたメソッドを経由することになります。最後に今回は人の書いた記事を読んだだけですが、かなり勉強になる内容でした。特に私個人としては、intellijを使っていると何を基準にinlineキーワードを使った方がいいという警告が出るのか悩ましい場面がありましたが、それが少し理解できました。companion objectに関する話も、今は問題が解決されたものの、何も考えず「定数だからcompanion objectだな」と思っていた自分を反省することになりましたね。そしてこの後の記事でも面白い内容が色々と出てくるので、またの機会でぜひ紹介したいと思います。では、また！

Kotlinの隠されたコストーその１

今はどんなプログラミング言語を選んでもできることはあまり違わなく、まさに好みで選んでもいいと思えるくらいの時代となっていると思います。特に、Kotlin/JSのようなトランスパイラーやFlutterのようなフレームワークも続々と登場している時代なので、こういう傾向はこれからもどんどん加速していくのではないかと思います。しかしそのような変化がある一方で、今現在はプログラマに一人が扱えるプログラミング言語の数に対する要求も増えいている状況ではないかと思います。実際の業務ではさまざまな理由で使われる言語が決まっていて、自分が今まで触ったことのないものでも使えるようになる必要があり、一人のエンジニアが固定されたポジションでなく、さまざまな分野にかけて実装を行うケースもありますしね。いわゆるPolyglotの時代とも言えます。なので、少なくともいろいろな言語の特徴を把握しておくということが大事になっているのではないかと思います。そして、そのような必要によるものでなくても、自分が普段接してない言語のコンセプトに触れてみることで、メインとなる言語への理解が深まることもあるのではないのかなと思ったりもします。これはどんな言語でもできることはあまり変わらないということともある意味通じているのですが、他の言語のコンセプトを受け入れた新しいAPIや機能を導入したり、そのようなライブラリが登場する場合もあるので。さて、前置きが長くなりましたが、ということで、これからはたまにとある操作をするときにいろいろな言語ではどうやってできるのか、そしてそうした場合の特徴などを簡単に比べてみたいと思います。今回は、配列のソートになります。JavaScriptJavaScriptではArray.prototype.sort()で配列のソートができます。なので、以下のようなコードを使えます。シンプルですね。> const a = [22, 1, 44, 300, 5000]> a.sort()[ 1, 22, 300, 44, 5000 ]また、元の配列の値は変更せず、新しくソートされた配列を作りたい場合は以下の方法を使えます。> const a = [22, 1, 44, 300, 5000]> const b = [...a].sort() // aをコピーしてソート> console.log(b)[ 1, 22, 300, 44, 5000 ]ただ、ここで気づいた方もいらっしゃると思いますが、ソートされた値が期待通りにはなっていません。本当なら、1, 22, 44, 300, 5000になるのが普通でしょう。ここで昇順に値をソートしたい場合は、ソートの方法を自前で作成する必要があります。例えば以下のような方法がありますね。> const a = [22, 1, 44, 300, 5000]> a.sort((a, b) => a - b)[ 1, 22, 44, 300, 5000 ]このsort()では、引数として渡すcompareFunction（引数が二つ、戻り値はnumber）の戻り値の結果によって、以下のことが起こります。0より小さいと、aのインデックスをbの先に置く0だと、aとbは変更しない0より大きいと、bのインデックスをaの先に置くこれはJavaをやっていた方だと、Comparatorと同じだなとすぐわかる内容ですね。アロー関数の形もJavaのLambdaに似ているので、あまり違和感なく適応できるかと思います。かなりシンプルなのですが、number型の配列に対しては自前のcompareFunctionが必要となるということは大事なので、気を付ける必要はあるでしょう。配列のインデックスを反転したい場合は、Array.prototype.reverse()を使うだけで良いです。この場合はnumberの配列でも自前のcompareFunctionが必要ないので、便利ですね。> const a = [22, 1, 44, 300, 5000]> a.reverse()[ 5000, 300, 44, 1, 22 ]Javaでは、次にJavaの方も見ていきましょう。先に述べた通り、Comparatorを使うと簡単にソートの方法を実装できるので、基本的には同じです。ただ、Javaの場合だとそもそもList.sort()、Collections.sort()、Arrays.sort()、[Stream.sorted()]など方法が色々あり、ソートしたいCollectionやArrayなどがImmutableであるかどうか、ComparatorやComparableを自前で実装するか、それともスタンダードライブラリに用意されてあるものを使うかなどのさまざまな選択肢も考慮する必要があるということですね。色々な選択肢がある中で、もっとも簡単なのは、Collections.sort()やArrays.sort()を使う方法かなと思います。これを使う場合、primitive型やStringのListは短いコードでソートができるという（そして標準機能という）メリットがありますね。jshell> var a = new ArrayList<>() {{ add(22); add (1); add(44); add(300); add(5000); }};a ==> [22, 1, 44, 300, 5000]jshell> Collections.sort(a);jshell> System.out.println(a);[1, 22, 44, 300, 5000]次に、List.sort()が簡単です。Comparatorを引数として渡す必要がありますが、昇順・降順でソートしたい場合は既に用意されてあるメソッドを呼び出すだけですね。jshell> var a = new ArrayList<>() {{ add(22); add (1); add(44); add(300); add(5000); }};a ==> [22, 1, 44, 300, 5000]jshell> a.sort(Comparator.naturalOrder());jshell> System.out.println(a);[1, 22, 44, 300, 5000]ちなみにComparatorで使える既定のソート方法は以下があります。昇順: naturalOrder()降順: reverseOrder()逆順: reversed()また、Comparatorは、Collections.sort()の引数としても使えます。なので、降順にソートしたい場合は以下のようなコードを使えます。jshell> var a = new ArrayList<>() {{ add(22); add (1); add(44); add(300); add(5000); }};a ==> [22, 1, 44, 300, 5000]jshell> Collections.sort(a, Comparator.reverseOrder());jshell> System.out.println(a);[5000, 300, 44, 22, 1]他に、元のListの値を変更せず、新しくソートされた結果を取得したい場合は、元のListをコピーする方法もありますが、もう一つの方法としてStreamを使う方法を考えられます。jshell> var a = List.of(22, 1, 44, 300, 5000);a ==> [22, 1, 44, 300, 5000]jshell> var b = a.stream().sorted().collect(Collectors.toList());b ==> [1, 22, 44, 300, 5000]Streamでソートする場合でも、Comparatorを使えます。jshell> var a = List.of(22, 1, 44, 300, 5000);a ==> [22, 1, 44, 300, 5000]jshell> var b = a.stream().sorted(Comparator.reverseOrder()).collect(Collectors.toList());b ==> [5000, 300, 44, 22, 1]また、DTOのListをソートしたい場合は、DTOがComparableを継承するという方法も考えられますが、多くの場合はソート時の条件が明確にわかるComparatorを実装したいいかなと思います。汎用性や柔軟性を考えても、Comparableの場合、条件が変わるとクラスを修正する必要があるので、Comparatorを使った方が無難かなと思います。Arrayの場合、Arrays.sort()を利用してソートできる（もちろんComparatorも使えます）上に、ListやStreamに変換することもできるので上記の方法をそのまま使えます。なので選択肢はもっと多いわけですが、便利な（好みに合う）方法を選ぶといいかなと思います。個人的にはArrays.sort()にComparatorを渡した方が可読性という面で良さそうな気がします。KotlinSytax Sugarをたくさん提供しているKotlinらしく、選べるソートのオプションがたくさんあります。なので、少しまとめてみました。Orderの種類ソート結果fun備考Natural呼び出し元Array/MutableList.sort()昇順Array/MutableList.sortDescending()降順Array/MutableList.reverse()逆順ArrayArray.sortedArray()昇順Array.sortedArrayDescending()降順Array.reveredArray()逆順ListArray/List.sorted()昇順Array/List.sortedDescending()降順List/MutableList.asRevered()逆順Custom呼び出し元Array/MutableList.sortBy()昇順、selector((T) -> R)必要Array/MutableList.sortByDescending()降順、selector((T) -> R)必要ListArray/Iterable.sortedBy()昇順、selector((T) -> R)必要Array/Iterable.sortedByDescending()降順、selector((T) -> R)必要ArrayArray.sortedArrayWith()Comparator必要ListArray/Iterable.sortedWith()Comparator必要かなり多い選択肢があるように見えますが、こうやって表としてまとめてみるとまぁまぁわかりそうな気はします。自前の比較処理を書く必要があるか、ソートした結果が元の配列かどうか、そしてArrayになるかListになるかなどいくつかの基準で分けられるということが分かれば大体どれを使った方がいいか悩む必要はないかなと思います。なので、まずやりたいことを明確にした上で、どのAPIを使うかを選んで書くだけです。以下はListから、ソートされた新しいListを作成する例です。それぞれ昇順と降順の場合となっています。>>> val a = listOf(22, 1, 44, 300, 5000)>>> val b = a.sorted()>>> println(b)[1, 22, 44, 300, 5000]>>> val c = a.sortedDescending()>>> println(c)[5000, 300, 44, 22, 1]また、data classの配列をソートしたい場合はsortByやsortedByを使えます。ここで引数に必要なのは(T) -> R型のselectorですが、単純にどれを基準にソートするかを指定すれば良いだけですので実装は簡単です。以下の例を見てください。>>> data class Data(val number: Int)>>> val a = listOf(Data(22), Data(1), Data(44), Data(300), Data(5000))>>> val b = a.sortedBy { it.number }>>> println(b)[Data(number=1), Data(number=22), Data(number=44), Data(number=300), Data(number=5000)]>>> val c = a.sortedByDescending { it.number }>>> println(c)[Data(number=5000), Data(number=300), Data(number=44), Data(number=22), Data(number=1)]他にも、より複雑な比較の条件を指定したい場合はJavaの場合と同じく、Comparatorを実装すると良いでしょう。やはりJavaと似ているようで、より単純化した（そしてそのせいで選択肢は増えた）感覚ですね。SwiftSwiftでは、シンプルに元のCollectionをソートするかソートされた新しいCollectionを作るかの選択肢しかないようです。あまり変わったことはないですが、元のCollectionをソートする場合は以下のようになります。 1> var a = [22, 1, 44, 300, 5000]a: [Int] = 5 values { [0] = 22 [1] = 1 [2] = 44 [3] = 300 [4] = 5000} 2> a.sort() 3> print(a)[1, 22, 44, 300, 5000]そして新しいCollectionを作成したい場合は以下のようになります。 1> let a = [22, 1, 44, 300, 5000]a: [Int] = 5 values { [0] = 22 [1] = 1 [2] = 44 [3] = 300 [4] = 5000} 2> let b = a.sorted()b: [Int] = 5 values { [0] = 1 [1] = 22 [2] = 44 [3] = 300 [4] = 5000} 3> print(b)[1, 22, 44, 300, 5000]ただ、Swiftのソートが独特なのはどうやってソートするか、その方法を指定する時です。sort()でもsorted()でも引数としてareInIncreasingOrderという関数を渡すことができるようになっていますが、JavaScriptやJava、Kotlinで使われていたcompareFunctionやComparatorの戻り値が数字であったことに対して、areInIncreasingOrderはpredicate型として戻り値がBoolになっています。なので以下のような形でソートの方法を指定可能です。let students: Set = ["Kofi", "Abena", "Peter", "Kweku", "Akosua"]let descendingStudents = students.sorted(by: >)print(descendingStudents) // "["Peter", "Kweku", "Kofi", "Akosua", "Abena"]"他に、classのフィールドを基準にソートしたい場合は以下の方法を使えます。struct Data { var number = 0 }let datas = [Data(number: 1), Data(number: 3), Data(number: 4), Data(number: 2)]let descending = datas.sorted { $0.number > $1.number }dump(descending)/** descending: [Data] = 4 values { [0] = { number = 4 } [1] = { number = 3 } [2] = { number = 2 } [3] = { number = 1 } }*/GoGoにはジェネリックがないからか、sortというパッケージに、sliceの種類によってソート用のfuncが色々と用意されています。例えば以下のようなものがあります。func Float64s(x []float64)func Ints(x []int)func Strings(x []string)なので、structのsliceではい場合はこれらの中でどれかを選んでソートすることになりますね。例えば以下のようになります。a := []int{22, 1, 44, 300, 5000}sort.Ints(a)fmt.Println(a) // [1 22 44 300 5000]structの場合は、以下のような方法が使えます。ソートの基準がまたboolになっています。people := []struct { Name string Age int}{ {"Gopher", 7}, {"Alice", 55}, {"Vera", 24}, {"Bob", 75},}sort.Slice(people, func(i, j int) bool { return people[i].Name < people[j].Name })fmt.Println(people) // [{Alice 55} {Bob 75} {Gopher 7} {Vera 24}]面白いのは、Goのソートにはsort.SliceStable()というものが別に存在しているということです。これは安定ソートを行うもので、その定義に関してはWikiでは以下のように述べています。同等なデータのソート前の順序が、ソート後も保存されるものをいう。つまり、ソート途中の各状態において、常に順位の位置関係を保っていることをいう。つまり、安定ソートの場合、ソートの基準となる値が同等の要素間の元の位置関係（インデックス）が保証されるということですね。その結果が実際どうなるのかを見てみましょう。people := []struct { Name string Age int}{ {"Alice", 25}, {"Elizabeth", 75}, {"Alice", 75}, {"Bob", 75}, {"Alice", 75}, {"Bob", 25}, {"Colin", 25}, {"Elizabeth", 25},}sort.SliceStable(people, func(i, j int) bool { return people[i].Age < people[j].Age })fmt.Println(people) // [{Alice 25} {Bob 25} {Colin 25} {Elizabeth 25} {Alice 75} {Alice 75} {Bob 75} {Elizabeth 75}]コードの実行結果でわかるように、Alice 25、Bob 25、Colin 25、Elizabeth 25とAlice 75, Bob 75, Elizabeth 75の元の順が維持されたままソートされたのがわかります。ここでもしsort.Slice()を使うと以下のようになります。sort.Slice(people, func(i, j int) bool { return people[i].Name < people[j].Name })fmt.Println(people) // [{Alice 25} {Alice 75} {Alice 75} {Bob 75} {Bob 25} {Colin 25} {Elizabeth 75} {Elizabeth 25}]安定ソートはそうでないソートに比べ性能が劣る可能性が高いので（元のインデックスをまで考慮しているので）、一つの値を基準にソートしても問題ない場合はsort.Slice()でも十分な気がしますが、そうでない場合は安定ソートを考慮する必要がありそうですね。PythonPythonではlist.sort()か、sorted()を使えます。他の言語でも大体同じだったので命名だけでも推測が可能かと思いますが、前者は元のlistをソートするもので、後者は新しいlistを作り出すものです。まずlist.sort()は、以下のように使えます。他の言語とあまり変わらないですね。>>> a = [22, 1, 44, 300, 5000]>>> a.sort()>>> print(a)[1, 22, 44, 300, 5000]それに対して、sorted()は以下のように使えます。>>> a = [22, 1, 44, 300, 5000]>>> b = sorted(a)>>> print(b)[1, 22, 44, 300, 5000]また、これらの関数ではkeyやreverseのようなパラメータを指定することで、どれを基準にソートするか、逆順にソートするかなどを指定できます。Pythonらしいシンプルさですね。class Data: def __init__(self, number): self.number = number def __repr__(self): return repr((self.number))datas = [Data(1), Data(3), Data(2), Data(4)]datas.sort(key=lambda data: data.number) # [1, 2, 3, 4]sorted(datas, key=lambda data: data.number, reverse=True) # [4, 3, 2, 1]番外：Stable sortGoのソート方法の中で少し安定ソートの話が出ましたが、ここで比較した他の言語だとGoのように安定ソートとそうでないソートのどれを使うかという選択肢がなかったので、それぞれの言語での安定ソートはどうやって扱われているのかを表にしてみました。以下をご覧ください。言語stablenon-stable備考Go⭕️⭕️funcによって選べられるJava⭕️⭕️Streamはnon-stableJavaScript⭕️⭕️ブラウザのバージョンによるPython⭕️❌Kotlin⭕️❌SequenceでもStableSwift❌⭕️stableを保証できないと表現多くの言語が安定ソートに対応していますが、少しづつ仕様が違う場合がありました。例えばJavaの場合、Streamによるソートは安定ソートではないため、安定ソートの結果を保証したい場合は既にソートされたCollectionを使うことをおすすめしています。Kotlinの場合はStreamに似たSequenceを使う場合でも、statefulなためか、安定ソートに対応していました。また、JavaScriptの場合はブラウザのバージョンによって違いますが、最新のブラウザを使っている場合は大抵安定ソートに対応していました。ただ、JavaScirptを使った案件の場合はIEも対象ブラウザとして考慮される場合があるのですが、IEだと安定ソートに対応していないので確認が必要かなと思います。Swiftの場合はまだソート時のデフォルト値をstableにするかどうかを検討している中で、APIとしてもGoのようにstableとそうでないものを分離するかどうかを検討しているらしいです。またどのアルゴリズムを使うかについて議論しているらしく、しばらくは安定ソートを期待できないかと思います。KotlinとPythonはどの場合でも安定ソートとなるので、悩み事が一つ減るのが嬉しいですね。最後に今回は色々な言語のソートについて調べてみましたが、いかがでしたか。一度ソートしたデータはその後の要素に対するアクセスが早くなるので、チューニングの観点からは必要なものかと思います。そしてこうやって色々な言語のソートのAPIを調べてみると、その言語の設計思想や発展の過程のようなものが少し見えるようで面白く、勉強にもなりますね。個人的にはあまり意識してなかった安定ソートがかなり勉強になりました。これからもこうやって色々な言語の使用やAPI、同じことをする場合の各言語による違いなどを比べてみたいと思います。時間と体力が十分であればの話ではありますが…！では、また！

色々な言語でやってみた（ソート編）

Quarkusを触ってみた

Java 17は何が変わったか

JavaからKotlinに移行したものの立場から言うと、Kotlinはスタンダードライブラリだけでも色々な関数を提供しているので、Javaに比べてかなり生産性が上がるといえますが、逆にいまいち関数の有効な使い方がわからなかったり、どうやって処理を書いたら「Kotlinらしい」かわからない場合もあるかと思います。なのでもう3回目のポストになりますが、今回もKotlinで色々とコードを書いてみて、そのうち良さそうなものをいくつか共有します。Listの要素をスワップListの要素の順番を変える方法はソートなどを含め色々とありますが、二つの要素をスワップ（インデックスを交換）したい場合もあるかと思います。こういう時に活用できる拡張関数を考えてみました。インデックスがわかる場合スワップしたい要素のインデックスがわかる場合は、そのインデックスを交換すればいいだけですね。ここでインデックスの交換は、二つの変数の値をスワップすることと変わらないです。変数の値を交換するのは伝統的には以下のような方法がありますね。var a = 10var b = 20var c = aa = bb = cもう少しKotlinらしい方法では、alsoを用いたものがあります。その方法だと、必要な処理は以下のようにもっとシンプルになります。var a = 10var b = 20a = b.also { b = a }これと同じく、Listの要素をスワップする処理を拡張関数で書くとしたらと以下のようになります。fun <T> List<T>.swapByIndex(indexFrom: Int, indexTo: Int): List<T> = toMutableList().apply { this[indexFrom] = this[indexTo].also { this[indexTo] = this[indexFrom] } }.toList()インデックスがわからない場合スワップしたい要素のインデックスがわからない場合もありますが、これも結局インデックスを持って値をスワップすることになるので、まずインデックスを抽出する処理だけを足せば良いかなと思います。インデックスを取得する方法は、要素を渡して取得するindexOfとPredicateを渡して取得するindexOfFirstがあるので、これらを活用することにします。あとはこれらの方法で取得したインデックスを、先に実装しておいた拡張関数に渡すだけで良いです。例えば以下のような実装ができます。// indexOf(element)を使うケースfun <T> List<T>.swapByElement(from: T, to: T): List<T> = swapByIndex(indexOf(from), indexOf(to))// indexOfFirst(predicate)を使うケースfun <T> List<T>.swapByCondition(from: (T) -> Boolean, to: (T) -> Boolean): List<T> = swapByIndex(indexOfFirst { from(it) }, indexOfFirst { to(it) })時間を数字にjava.timeパッケージのLocalDateやLocalDateTimeのようなオブジェクトは、コード上で時間を扱うには便利ですが、ファイルに書き込むなどでフォーマットを変更する必要がある時もあります。つまり、yyyy-MM-ddではなくyyyyMMddhhmmssのような形にしたい場合があるということです。こういうときは、簡単にInt型に変更できる拡張関数を書いておくと便利でしょう。例えば以下のようなものを考えられます。fun LocalDate.toInt(): Int = "$year$monthValue$dayOfMonth".toInt()val date = LocalDate.of(2021, 12, 31) // 2021-12-31println(date.toInt()) // 20211231ただ、こうする場合、以下のように月や日付が一桁のものになってしまうケースもあります。val date = LocalDate.of(2021, 9, 1) // 2021-09-01println(date.toInt()) // 202191この問題を解決するには、まず月や日付を二桁の文字列に変える必要がありますね。例えば以下のようなことができます。fun LocalDate.toInt(): Int = "$year${monthValue.toString().padStart(2, '0')}${dayOfMonth.toString().padStart(2, '0')}".toInt()val date = LocalDate.of(2021, 9, 1) // 2021-09-01println(date.toInt()) // 20210901しかし、これでも完璧とはいえません。LocalDateのみでなくLocalDateやLocalDateTime, YearMonthなど、java.timeパッケージに属する他のオブジェクトも使いたい場合には、全てのオブジェクトに対して同じような拡張関数を書く必要があるからです。幸い、LocalDate、LocalDateTime、YearMonthは共通的にTemporalというインタフェースを継承しているので、Temporalに拡張関数を追加することで問題は解決できます。そしてこれらの実装クラスで扱っている時間の範囲はオブジェクトごとに違うので、実装も変える必要がありますね。これらのオブジェクトはどれも時間を数字として表現しているので、まずtoStringで文字列に変換した後、数字だけを抽出することです。StringはCharSequenceを継承しているので、filterで数字だけを抽出すると良いでしょう。そうすると、以下のような方法が使えます。fun Temporal.toDigit(): Long = toString().filter { it.isDigit() }.toLong()val yearMonth = YearMonth.of(2021, 8) // 2021-08println(yearMonth.toDigit()) // 202108val dateTime = LocalDateTime.of(2021, 10, 2, 10, 10, 10) // 2021-10-02T10:10:10println(dateTime.toDigit()) // 20211002101010Stringのフォーマットで数字に変換する場合はtoIntやtoLongでループが一回発生するだけですが、CharSequenceとして扱う場合はループが2回発生するという違いがあるので性能的には前者が良いはずですが、時間を扱うくらいではそこまでループは長くないので気にするほどではないかと思います。要素の一部を合算Listの値を一つに集約したい（合算値を出したい）場合があります。sumを使っても良いですが、これはそもそも要素が数字ではないと難しいですね。例えば要素が以下のようなクラスとなっているケースはどうしたら良いでしょうか。data class Data( val name: String, val amount: Int, val price: Int)合算したい値が一つの場合合算したい値が一つだけの場合は、sumOfで合算したい値だけを指定すれば良いです。以下は、Dataクラスのamountだけを合算したい場合に使える方法です。val list = listOf(Data("data1", 10, 100), Data("data2", 20, 200))val totalAmount = list.sumOf { it.amount }合算したい値が複数の場合ここでamountのみでなく、priceも合算したい場合はどうすれば良いでしょう。同じくsumOfをpriceにも使うことで実装はできますが、同じListに対してループが2回も発生するのあまり効率的ではありません。こういうときは、素直にそれぞれの合算値を変数として宣言しておいてforEachループの中で値を足していく方が効率が良いでしょう。例えば以下のようにです。var totalAmount = 0var totalPrice = 0list.forEach { totalAmount += it.amount totalPrice += it.price}もう一つの方法は、foldを使う方法です。foldはreduceと似たようなもので、初期値(initial)を指定できるという違いがありますが、reduceToのようにこの初期値の型はListの要素とは違うものに指定できます。そして関数を実行した結果はinitialと同じ型になるので、これを応用するとDataのリストを二つの値(Pair)にreduceすることもできます。例えば上記の処理はfoldを使うと以下のようにワンライナで実装ができます。val (totalAmount, totalPrice) = list.fold(0 to 0) { acc, value -> (acc.first + value.amount) to (acc.second + value.price)}foldを使う場合、合算したい値が三つある場合はTripleを使うこともできますし、さらに値が多い場合は専用のクラスを作ることで対応もできるかと思います。ただ、こうする場合、合算した値をvalとして宣言できるというメリットはありますが、ループごとにインスタンスが作成されるので合算したい項目が増えれば増えるほど性能的にはあまり良くない可能性が高いので場合によって適切なものを選ぶ必要がありそうですね。最後にいかがだったでしょうか。私はずっとJavaでコードを書いていたので、完全にKotlinに転向した今でもついJavaらしいコードを書いてしまうのではないか、と思う時があります。元を辿ると、「Javaらしいコード」や「Kotlinらしいコード」がそもそも何であるかを考えなければならないとは思いますが、それでも、確かに言語が違うとその言語に合わせて自分のコーディングスタイルも変化する必要はあるのではないかと思います。そうすることで、より良いコードが書けるようになりそうな気がしていますので。というわけで、これからもKotlinならではの、Kotlinに特化したコードを書くための工夫はこれからも続きます。特に今月はJava 17もリリースされたので、新しいAPIの一覧を眺めてKotlinではどう活用できるか考えてみたいですね。では、また！

Kotlinで書いてみた〜その三〜

前回、WebFluxではFunctional Endpointを使うべきかというポストを書いたことがありますが、今回はController/ServiceとRouter/Handlerのパターン間の比較ではなく、Functional Endpointを使う場合に、どんな形で実装をしていくべきかについて少し考えたことを述べようと思います。実際の業務でWebFluxを使っているわけではないので、さまざまなパターンがあるかなとは思いますが、このFunctional Endpointを使う場合に考慮すべきものが、Router Function(以下Router)とHandler Function(以下Handler)をどう分けるかについての問題かと思います。RouterとHandlerは概念的には別のものではありますが、実装としては一つのクラスにまとめでもアプリは問題なく動くので、フレームワークの仕様や思想というよりかは、アプリのアーキテクチャに関する内容に近いますね。なので、今回はRouterとHandlerを分けた場合と分けない場合について、いくつかの観点から考えてみたいと思います。RouterとHandlerは分離するべきかSpring MVCの場合、ControllerとServiceを明確に分けるのが常識のようになっています。アーキテクチャとしてもそうですが、フレームワークの思想（デザインの観点）としてもそうですね。こういう前例があるので、同じくSpring Frameworkに属するWebFluxの場合でも、Functional Endpointという新しい概念を導入するとしても、RouterとHandlerを分ける必要があると思いがちかなと思います。一見、Controller ≒ Router, Service ≒ Handlerという対応関係が成立するようにも見えて、ネットで検索できるサンプルコードも多くがそのような構造で書かれています。しかし、実際のアプリをFunctional Endpointを持って書くとしたら、いくつか考えなければならないことがあると思います。例えば、そもそもRouterとHandlerはそれぞれControllerとServiceに一対一の対応関係であるという前提は確かであるか？もしそうでなければ、あえてMVCのパターンに合わせる必要があるのか？実装においてはどう影響するのか？などがあるかと思います。なので、今回はこれらの観点からFunctional Endpointについて述べていきます。対応関係についてSpringの公式ドキュメントでは、WebFluxのFunctional Endpointの紹介において以下のようなサンプルコードを提示しています。val repository: PersonRepository = ...val handler = PersonHandler(repository)val route = coRouter { accept(APPLICATION_JSON).nest { GET("/person/{id}", handler::getPerson) GET("/person", handler::listPeople) } POST("/person", handler::createPerson)}class PersonHandler(private val repository: PersonRepository) { // ... suspend fun listPeople(request: ServerRequest): ServerResponse { // ... } suspend fun createPerson(request: ServerRequest): ServerResponse { // ... } suspend fun getPerson(request: ServerRequest): ServerResponse { // ... }}公式のサンプルとしてHandlerが別のクラスになっているのを見ると、やはりController ≒ Router, Service ≒ Handlerという対応関係が成立するようにも見えます。@RestControllerや@Serviceと違って、@Routerや@Handlerというアノテーションは存在しないことに注目する必要があります。これはつまり、Springというフレームワークの思想としてはRouterとHandlerを必ず分ける必要はない、ということを意味しているのではないでしょうか。なので、少なくともアプリケーションのアーキテクチャという観点からしてController ≒ Router, Service ≒ Handlerという対応関係が成立する、という結論を出すのは難しいのではないかと思います。では、実際RouterとHandlerをあえてアノテーションを使ってDIをするとしたら、どうなるのでしょうか。サンプルとしては、以下のような形が一般的かなと思います。@Configurationclass PersonRouter(private val handler: PersonHandler) { @Bean fun route(): RouterFunction<ServerResponse> = coRouter { accept(APPLICATION_JSON).nest { GET("/person/{id}", handler::getPerson) GET("/person", handler::listPeople) } POST("/person", handler::createPerson) }}@Componentclass PersonHandler(private val repository: PersonRepository) { // ... suspend fun listPeople(request: ServerRequest): ServerResponse { // ... } suspend fun createPerson(request: ServerRequest): ServerResponse { // ... } suspend fun getPerson(request: ServerRequest): ServerResponse { // ... }}クラスそのものを@Componentとして登録する必要があるContollerに対して、RouterFunctionはFunctional Interfaceなのでそれを実装したメソッドを@Beanとして登録する必要があります。そしてSpringで@Beanをアプリケーションに登録するのは一般的に@Congifurationが担当するので自然にRouterのアノテーションもそうなります。Handlerは普通に@Componentとして登録することになりますね。こうなった場合、クラスやその実装を見てRouterとHandlerを分離しているのはわかりますが、アノテーションだけだと違和感を感じられますね。実装は簡単なのでそれぞれに対応するアノテーションを作るのが難しいわけでもないようですが、なぜこのような構造になっているのでしょうか。公式のドキュメントでは、以下のような説明があります。The big difference with annotated controllers is that the application is in charge of request handling from start to finish versus declaring intent through annotations and being called back.つまり、「アノテーションをつけたContoller」と「Functional Endpoint」の違いは、前者が「アノテーションでコールバックと意図を表す」に対して、後者は「リクエストのハンドリングを開始から終了まで担当する」ということです。プログラミングモデルとしてこのような観点の差があるので、アノテーションがないのは当たり前なのかもしれません。そして結果的に、Controller ≒ Router, Service ≒ Handlerという対応関係は、少なくともプログラミングモデルという観点では当てはならないと考えられます。責任の分散という側面でアノテーションの実装を見ると、@Controllerと@Serviceを分けているのがフレームワークのアーキテクチャや思想によるものであることがより明確になります。それぞれのアノテーションの実装は、以下の通りです。@Target(value=TYPE)@Retention(value=RUNTIME)@Documented@Componentpublic @interface Controller@Target(value=TYPE)@Retention(value=RUNTIME)@Documented@Componentpublic @interface Service両方とも実装が同じであるので、極端的にいうとControllerに@Serviceをつけても機能的には同一ということになります。そして@Serviceでは、以下のようなコメントでこのアノテーションが存在する理由をあくまで「デザインパターンに基盤を置いている」ことを明示しています。Indicates that an annotated class is a “Service”, originally defined by Domain-Driven Design (Evans, 2003) as “an operation offered as an interface that stands alone in the model, with no encapsulated state.”May also indicate that a class is a “Business Service Facade” (in the Core J2EE patterns sense), or something similar. This annotation is a general-purpose stereotype and individual teams may narrow their semantics and use as appropriate.なので、アプリケーションデザインの観点からするとControllerはリクエストを受信、レスポンスを返す、エンドポイントをServiceにつなぐという義務だけを持ち、Serviceはビジネスロジックを処理する義務を持つと考えられます。同じ観点から考えると、アノテーションはないものの、RouterとHandlerもまた同じ義務を持つように書くこともできるでしょう。ただ、問題は「リクエストのハンドリングを開始から終了まで担当する」という定義です。先程のサンプルコードをよく見ると、HandlerのメソッドはどれもServerRequestを引数として、戻り値はServerResponseになっています。これはつまり、RouterとHandlerをあえて別のクラスとして分割するとしても、リクエストとレスポンスまでをHandlerで処理することを意味します。ここで「Controller/Serviceの場合と同じく、Handlerの引数と戻り値だけを変えて良いのでは？」と考えられます。しかし、それこそフレームワークの思想に反することです。ServerRequestとServerResponseのJavaDocでは、以下の通り「ServerRequestとServerResponseはHandlerFunctionでハンドリングする」ことを明示しています。/** * Represents a server-side HTTP request, as handled by a {@code HandlerFunction}. * * <p>Access to headers and body is offered by {@link Headers} and * {@link #body(BodyExtractor)}, respectively. * * @author Arjen Poutsma * @author Sebastien Deleuze * @since 5.0 */public interface ServerRequest {/** * Represents a typed server-side HTTP response, as returned * by a {@linkplain HandlerFunction handler function} or * {@linkplain HandlerFilterFunction filter function}. * * @author Arjen Poutsma * @author Juergen Hoeller * @author Sebastien Deleuze * @since 5.0 */public interface ServerResponse {以上のことでわかるように、WebFluxではServerRequestとServerResponseはHandlerFunctionで扱うようにデザインされています。なので、既存のServiceのように、Handlerがビジネスロジック「のみ」を扱うというのはそれが実装として可能かどうか以前の問題になるのです。ただ、「責任の分散」という観点からして、責任によってクラスを分けるという発想は間違っているわけではないですね。なのでビジネスロジックを担当するクラスをHandlerと分離して運用するケースは考えられますが、必ずしもクラスを分ける基準がRouterとHandlerである必要はないのではないかと思われます。テストの観点でJavaでJUnitなどを用いてユニットテストを作る場合、テスト自体はユースケース単位で作成しますが、それらのテストはクラス単位でまとめるというケースが多いかなと思います。なので同じ観点でユニットテストを書く場合、RouterとHandlerが分けられているとしたら当然ユニットテストもその単位で分けられるでしょう。ただ、こうする場合の問題は、テスト自体があまり意味を持たなくなる可能性があるということです。まずRouterは単純にエンドポイントとHandlerをつなぐ役割しか持たなくなるので、そのテストも「想定通りのHadlerFunctionを呼び出しているのか」に限るものになります。そしてHandlerの場合、ServerRequestを受信してServerResponseを発するので、テストが非常に難しくなるという問題があります。なぜServerRequestを受信してServerResponseを発するのが問題になるかというと、ServerRequestのインスタンスを生成するのが難しく、ServerResponseの場合でもレスポンスボディーを抽出するのが難しいからです。なので、WebTestClientで行うことになるかと思いますが、WebTestClientを使う場合はエンドポイントとHTTPメソッドなどを利用して実際のAPIを呼び出すことになるので、結果的にHandlerのテストをするつもりがRouterのテストまでふくむしかないということになります。こうするとクラス単位でテストケースをまとめることが難しいだけでなく、Routerのみのテストも実質的には意味をなくすということになります。ではどうすればいいか今まで論じた3つの観点からすると、RouterとHandlerは別のクラスにする理由もあまりなく、むしろ別クラスに色々と問題が生じるように見えます。しかし、これが必ずしもエンドポイントに対するルーティングとビジネスロジックを分離する必要はない、ということではないかと思います。先に述べた通り、クラスを分ける基準をRouterとHandlerにしないだけで良いかなと思います。例えば、以下のようなコードがあるとします。@Configurationclass PersonRouter(private val repository: PersonRepository) { @Bean fun route(): RouterFunction<ServerResponse> = coRouter { GET("/person/{id}") { ServerResponse.ok() .contentType(MediaType.APPLICATION_JSON) .body( repository.findById(it.pathVariable("id").toLong()) .map { record -> PersonDto(record.id, record.name) } ).awaitSingle() } }}Handlerで、Bodyを作る箇所以外はビジネスロジックと言えるものがあまりありません。なので、ここではBodyだけを分離して別のクラス（Service）に一任しても良さそうです。例えば以下のようにです。@Configurationclass PersonRouter(private val service: PersonService) { @Bean fun route(): RouterFunction<ServerResponse> = coRouter { GET("/person/{id}") { ServerResponse.ok() .contentType(MediaType.APPLICATION_JSON) .body(service.getPersonById(it.pathVariable("id").toLong())) .awaitSingle() } }}@Serviceclass PersonService(private val repository: PersonRepository) { suspend fun getPersonById(id: Long): Mono<PersonDto> = repository.findById(id) .map { PersonDto(it.id, it.name) }}こうすると、Routerから直接Repositoryにアクセスこともなくなり、今まで挙げていたさまざまな問題も解消できるようになりますね。最後にここで提示した方法でビジネスロジックを分けるのは可能だとして、その方法をとった場合に残る疑問はあります。これは果たしてFunctionalなのか？Functional EndpointはLambda-basedと説明されてあるが、Lambdaが使われないので設計意図とは違う形になってないか？そもそもSpring MVCとは違うコンセプトのフレームワークなので既存とは違うアプローチが必要なのでは？などなど。これらの問題を判断するのはなかなか難しいですが、個人的には新しい技術だからといって常に新しい方法論を適用するということは難しく、既存の良い体系があるのならそれに従うのもそう間違っていることとは思いません。Springの公式ドキュメントでは「すでに問題なく動いているSpring MVCアプリケーションにあえてWebFluxを導入する必要はない(If you have a Spring MVC application that works fine, there is no need to change)」と述べていますが、これと同じく、既存の検証されてあるアーキテクチャがあるのならばそれをそのまま適用するもの悪くないのではと思います。まぁ、そもそもWebFluxを導入するところでMVCパターンを使うとしたらこういうことを気にする理由すら無くなるのですが…むしろこのようなプログラミングモデルが増えていくと今後は新しいアーキテクチャが生まれそうな気もしますね。今回のポストを書きながらはそういういうものを感じました。では、また！

WebFluxのFunctional Enpointに対する小考察

前回、Ktorを紹介しながら、KtorにはまだRole-based Authorizationに対応してないので、自前でそのような機能を実装する必要がある、と述べました。Ktorはまだ歴史が短く、SpringやDjango、Railsのように幅広く使われているフレームワークでもないので、おそらく他に比べ実のアプリケーションを作るにあたっては必要な機能が十分でない可能性がありますね。なので、こうやって必要な機能がない場合は直接その機能を実装するしかないです。幸い、Ktorでは機能をPluginといい、モジュール単位で追加できるため、必要な機能を実装するのもそのPluginを作ることでできるようになります。ただ、モジュールを利用するということは、機能単位の管理がやりやすくなるものの、そのモジュールはどうやって機能するか、また、どういうお作法が必要となるかを知る必要がありますね。今回はネット上に公開されてある記事を参考にしながら、KtorのRole-based AuthorizationをPluginとして実装してみました。そこで、今回のポストではこういう自作のPluginがどうやってKtorの機能として動作するか、どうやって実装するのかについて述べたいと思います。Role-based Authorizationとはまずは、そもそもRole-based Authorizationとは何か、からですね。これは、ウェブアプリケーションでよく言われている「認可」の方式のうち、ユーザのRole（役割）に基づいて、APIの実行を制御するものです。例えばECサイトの場合、商品に対して問い合わせをするのは認証されたユーザなら誰でもできるべきですが、「お知らせを書く」や「商品の在庫数を変更する」などの機能はその権限を持つユーザ（Admin）に限定すべきですね。なので、ここで「一般ユーザ」と「管理者」などのRoleを設け、APIに対してのリクエストが発生した際にそのRoleをまず確認し、その権限のあるユーザのみがAPIを実行できるようにする、というのがRole-based Authorizationの基本的な概念です。これを実現するために既存のアプリに導入する必要のあるものは、大きく分けてRoleの概念と、それを元にリクエストをフィルタリングする機構の二つです。前者の場合はどんなロールがあり、どういう形でユーザに紐付けるかを考えればいいだけなので、テーブルやカラムを追加して既存のユーザの情報と紐づけるだけですみます。しかし、後者はまずフレームワークでどうやってリクエストをフィルタするか、まずその構造から理解する必要がありますね。なんので、まずはKtorでリクエストを扱う方法に対して紹介したいと思います。PipelineとFeatureKtorの特徴のうち、最も重要と言えるものは、Pipelineの概念です。このPipelineに対して、公式では以下のように説明しています。The pipeline is a structure containing a sequence of functions (blocks/lambdas) that are called one after another, distributed in phases topologically ordered, with the ability to mutate the sequence and to call the remaining functions in the pipeline and then return to current block.この説明だけでは理解が難しいものですが、要するに、Ktorにおいての処理の単位のことを指していると言ってもよいものです。PipelineではAPIのコールからレスポンスまで一連の流れとしての処理を定義することができます。なのでPipelineとして実現されている代表的な機能はRouter、リクエストに対してのハンドリングを定義する機能（SpringのControllerに対応するもの）となります。また、Pipelineは拡張できるものなので、その形式に合わせて新しいPipelineを実装することでモジュール(公式の表現ではPlugin)を実現するのもできます。これらのモジュールを実装し、アプリケーションにインストールすることで、そのモジュールの機能を利用できるようになるのがKtorの特徴です。例えば、kotlin公式のJSON Mapperであるkotlinx.serializationをアプリケーションに追加するためには以下のようなコードを書きます。fun Application.main() { install(ContentNegotiation) { json() }}ここで呼び出しているinstall関数の実装を見ると、以下のようになっています。feature(モジュール)と、そのモジュールの設定となるconfigureが引数になっているのがわかります。public fun <P : Pipeline<*, ApplicationCall>, B : Any, F : Any> P.install( feature: ApplicationFeature<P, B, F>, configure: B.() -> Unit = {}): F先ほどのkotlinx.serializationをインストールするために使っていたコードでは、featureとしてContentNegotiationを渡し、その設定としてjsonを使うという設定をしているのだなという推測ができますね。実際、ContentNegotiationの実装は、以下のような形となっています。一部のコードは省略していますが、クラスの中にはConfigurationというクラスと、ApplicationFeatureを継承したcompanion objectを中に持っているのがわかります。public class ContentNegotiation internal constructor( public val registrations: List<ConverterRegistration>, private val acceptContributors: List<AcceptHeaderContributor>, private val checkAcceptHeaderCompliance: Boolean = false) { // ... /** * Configuration type for [ContentNegotiation] feature */ public class Configuration { // ... } /** * Implementation of an [ApplicationFeature] for the [ContentNegotiation] */ public companion object Feature : ApplicationFeature<ApplicationCallPipeline, Configuration, ContentNegotiation> { // ... }上記の実装でわかるように、Pipelineとして機能するためにはモジュールの設定のためのConfigurationというクラスと、モジュールとして機能するためのApplicationFeatureを継承したcompanion objectが必要であることがわかります。なので、この構造を持ったクラスを定義できれば、自作のモジュールをアプリケーションに実装できるということがわかりますね。Pluginの実装では、実際にPipelineとして、リクエストに対する認可を判定する機能を作るとしましょう。まずはロールを定義します。enumが良さそうですね。ここではシンプルに管理者と一般ユーザの2種を作ってみます。enum class Role(val value: String) { ADMIN("ADMIN"), USER("USER")}これらのロールは、テーブルなどで管理する必要もありますが、ログイン中のユーザ情報から取得する必要もありますね。認可のためには、ログイン中のユーザにとあるロールが与えられているかどうかの確認が必要となるからです。なので、io.ktor.auth.Principalを継承したユーザの情報もクラスとして作り、ログインに成功した時はこのクラスにユーザのロールを格納することにします（方法は認可とは関係ないのでここでは割愛させてください）。以下はユーザの情報を格納するための簡単な例です。data class UserPrincipal( val username: String, val roles: Set<Role> = emptySet()) : Principal次に、ロールでアクセスを制限する関数を作ります。Routerのエンドポイントに、どのロールの場合にアクセスできるかを指定するようなイメージです。例えば以下のような形で使えたらいいかと思います。fun Application.main() { routing { // 管理者のみアクセスできる withRole(Role.ADMIN) { get("/admin") { call.respond("This is admin page") } } // 一般ユーザがアクセスできる withRole(Role.USER) { get("/user") { call.respond("This is user page") } } }}Routerの使い方でわかるように、Pipelineでのコードブロック（関数）はネストが可能なのでこのように一つのレイヤーを挟むのも可能です。ここで追加したwithRoleという関数でロールを確認し、APIにアクセスできるかどうかを判定するようにしたら良いでしょう。AuthorizedRotueSelectorの実装まずはRouteSelectorを実装します。これは、routingの中にこれから作る認可の関数がネストできるようにするためのものです。もっともシンプルな実装は以下のようになります。class AuthorizedRouteSelector() : RouteSelector() { override fun evaluate(context: RoutingResolveContext, segmentIndex: Int) = RouteSelectorEvaluation.Constant}child routeの実装先に実装したAuthorizedRouteSelectorを利用して、実際にchild routeとして機能する関数を作ります。このchild routeはRouterの下にネストすることになるので、Routeの拡張関数を作ることにします。引数としては判定のためのロールと、その下にネストするエンドポイントの関数を設定できるようにすれば良いでしょう。実装は以下のようにします。fun Route.withRole(val role: Role, build: Route.() -> Unit): Route { val authorizedRoute = createChild(AuthorizedRouteSelector()) application.feature(RoleBaseAuthorizer).interceptPipeline(this, role) build() return authorizedRoute}ここで実装しているものは、まずAuthorizedRouteSelectorでchild routeを作り、その後Pipelineをインターセプトして、ユーザが指定したロールに該当するかどうかを判定します。問題なければbuildを実行させますが、これがネストしているchild routeになります。最後に、エンドポイントをネストできるように先ほど作成したchild routeのインスタンスを返します。Pipelineをインターセプトする時に呼び出しているRoleBaseAuthorizerは、別途クラスとして作ることにします。これをFeatureとして作ることになります。認可処理のモジュールの実装では、本格的に認可の処理を担当するモジュール（Feature）を実装することにします。先に述べた通り、ConfigurationとFeatureを内部に持ったクラスを作ります。ここでConfigurationは、ログイン中のユーザからどうやってロールの情報を取得するかの設定ができるクラスにします。こうすることで、以下のようなことが可能になるでしょう。fun Application.main() { // RoleBaseAuthorizerをFeatureとしてインストール install(RoleBaseAuthorizer) { // ログイン中のユーザの情報からロールを取得する方法をConfigurationとして指定 getRoles { (it as UserPrincipal).roles } }}Configurationでは、ログイン中のユーザ情報となるUserPrincipalからrolesを取得する、という関数を渡します。これを持って、RoleBaseAuthorizerではwithRole関数で指定したロールとユーザのロールを比較するようにします。認可のモジュールの設定方法のイメージができたので、次にRoleBaseAuthorizerを実装します。例えば以下のようになります。class RoleBaseAuthorizer(config: Configuration) { class Configuration { var userRoles: (Principal) -> Set<Role> = { emptySet() } // ログイン中のユーザの情報からロールの取得方法をセット fun getRoles(roles: (Principal) -> Set<Role>) { userRoles = roles } } private val getRoles = config.userRoles fun interceptPipeline( pipeline: ApplicationCallPipeline, role: Role ) { // Pipelineの位置付け pipeline.insertPhaseAfter(ApplicationCallPipeline.Features, Authentication.ChallengePhase) pipeline.insertPhaseAfter(Authentication.ChallengePhase, AuthorizationPhase) // インターセプト時の処理 pipeline.intercept(AuthorizationPhase) { // ログイン中のユーザの情報を取得 val principal = call.authentication.principal<UserPrincipal>() ?: throw AuthorizationException("Missing principal") // ユーザ情報からロールを取得 val roles = getRoles(principal) if (roles.none { role }) { // ログイン中のユーザのロールに、アクセス可能なロールが含まれてない場合の処理 } } } companion object Feature : ApplicationFeature<ApplicationCallPipeline, Configuration, RoleBaseAuthorizer> { override val key = AttributeKey<RoleBaseAuthorizer>("RoleBaseAuthorizer") val AuthorizationPhase = PipelinePhase("Authorization") override fun install( pipeline: ApplicationCallPipeline, configure: Configuration.() -> Unit ): RoleBasedAuthorization { val configuration = Configuration().apply(configure) return RoleBaseAuthorizer(configuration) } }}先に説明した通り、Configurationではユーザのロール情報を取得する関数を設定し、保存します。そしてinterceptPipelineでは、その関数を持ってPipelineをインターセプトし、ロールの検証を行うようにします。また、interceptPipelineでは、引数として渡されたPipelineの位置付けを設定する必要があります。上記のコードでは、「認証の後」に位置付けしています。その後のロジックは、色々な方法があると思いますので、ここでは割愛させていただきます。他に、Featureの場合は、RoleBaseAuthorizerが独立したモジュールとして使える設定を行います。単純に名前をつけてインスタンスを返すような、お作法的なものですね。ここまでの実装が終わったら、一通り認可に関するモジュールの作成は終わります。ただ、interceptPipelineの処理としてユーザのロールが、APIにアクセスできない場合の処理として考えられることは二つほどあります。レスポンスを返して終了まず考えられる方法は、適当なレスポンスを返し、そこで処理を終了させることです。この場合、以下のように実装ができます。if (roles.none { role }) { // レスポンスを返す call.respond( status = HttpStatusCode.Forbidden, message = "permission not granted: $role" ) // Pipelineの終了 finish()}ここで注意すべきことは、レスポンスを返すだけでPipelineは終わらないということです。レスポンスを返し処理を止めたい場合は必ずfinish()を呼び出して、Pipelineを終了させましょう。Exceptionを投げるもう一つの方法は、例外を投げる方法ですね。例えば以下のようにします。// 認可されてない場合の例外class AuthorizationException(override val message: String) : Exception(message)if (roles.none { role }) { throw AuthorizationException("permission not granted: $role")}例外を投げる場合は、当然Pipelineの処理が止まることになりますが、アプリケーションのログでも例外になるのであまり良くないですね。幸い、KtorにもSpringのExceptionHandlerのような機能があるので、それを活用したら適切な例外のハンドリングが可能になります。例えば以下のようなことができますね。// 認可されてない場合のレスポンスdata class AuthFailedResponse(val reason: String)// 例外のハンドリングinstall(StatusPages) { exception<Throwable> { cause -> when (cause) { // 認可の場合の処理 is AuthorizationException -> { call.respond( status = HttpStatusCode.Forbidden, message = AuthFailedResponse( reason = cause.message ) ) } } }}これでアプリケーションのログも綺麗になりますし、他の例外処理に対してもwhenの分岐を増やすだけで対応ができるようになります。最後に最初に思っていたことよりも膨大な内容を扱うことになったので、いつもより説明が大雑把な気もしますが、これでPipelineとそれを応用した自作モジュールの実装についての説明は一通りできたかなと思います。なので、これを応用すれば、他のモジュールを追加するのもそう難しくなさそうな気がしますね。深堀すると色々また出そうな気がしますが、それについては機会があればまた今度のポストのネタにしましょう。（正直あまり詳しくありませんので…）個人的には、このようにRole-based Authorizationの機能を作りながら知った。一連の処理をPipelineという単位で扱うという概念ががかなり新鮮で、良いと思いました。処理に対してのインターセプトはSpringでもできるのですが、処理の流れ自体を一つの単位として扱えるならより色々なことができそうな気もしますね。まだKtorに触れたばかりなので、詳しいことはもっと時間をかけてゆっくり調べる必要がありそうですが。確かなのは、Ktorはかなり魅力的なフレームワークであるということです。最初はSpringなど、既存の有名なフレームワークと比べ色々と機能が足りない認証だったのですが、こうやって簡単にモジュールを作れるとしたら意外と問題ないかもしれない、という気がします。もちろんそれでも、プロダクションレベルのものを作るにはまだ色々と検証が必要そうな認証はありますが。では、また！

KtorでRole-based Authorizationを実装する

DBのテーブルとして、1:Nのリレーションは珍しいものではありません。例えば、ECサイトで会員登録をし、複数の配送先を設定できるようにするとしたら、この会員情報のテーブルに配送先のカラムを追加するよりは、配送先のテーブルを分離して別に管理した方がデータの持ち方としては合理的で安全なはずです。そして分離した配送先のテーブルは、会員情報のテーブルとN:1の関係になるのが一般的でしょう。ただ、データの持ち方が優先的なDBと、そのデータを処理して形にするアプリケーションでは事情が違いますね。例えば上記の通り、一つの会員情報のレコードに対して複数の配送先のレコードが存在し得る場合、SQLでデータを表現すると、以下のような形になるはずです。|-----------|-------------|-----------------|| member.id | member.name | mailing.address ||-----------|-------------|-----------------|| 1 | John | Tokyo || 1 | John | New York || 1 | John | Beijing || 2 | Simpson | Osaka || 2 | Simpson | Nagoya ||-----------|-------------|-----------------|しかしアプリケーションではこのような形でデータを扱うことはあまりないですね。一つのレコードに対して複数のレコードが含まれるということは、Kotlinだと以下のように表現するのが一般的かと思います。data class Member( val id: Int, val name: String, val mailingAdress: List<String>)そして普通は、このようなオブジェクトをJSONの形にしてREST APIのレスポンスとして使う場合が多いですね。なので、先程のレコードをJSONにした場合は以下のようになるはずです。{ "members": [ { "id": 1, "name": "John", "mailingAddress": [ "Tokyo", "New York", "Beijing" ] }, { "id": 2, "name": "Simpson", "mailingAddress": [ "Osaka", "Nagoya" ] } ]}ここで問題は、オブジェクトをJSONに変えることはそう難しくないのですが（Jackson, Gson, Kotlin Serializationのようなライブラリがすでにありますし）では、このような場合、DBから取得したレコードをどうやってオブジェクトにマッピングしたら良いのでしょう。JPAのようなORMを使う場合、クラスにテーブル間の関係を表すフィールドとアノテーションを適切に使うことでレコードへのマッピングは自動に行われますが、jOOQやQuerydsl, Exposed, KtormのようなORMで、DSLを使ってSQLを書く場合はデータのマッピングを手動で行う必要があります。そして取得したデータは行の配列という形になるので、どうマッピングしたら（効率が）いいかは少し悩ましいところです。なので、今回はExposedのDSLを使って取得したOne to Manyのレコードを、コード上でどうやってオブジェクトにマッピングするかについて考えたことを述べたいとお思います。テーブルごとにSelectするもっとも簡単な方法は、そもそもレコードの取得時に個別のテーブルに対してSelectしてからマッピングすることですね。個別のテーブルに対してクエリを発行するので、書き方としては明瞭になるというメリットもあります。例えば、以下のようなことができます。transaction { // まずはMemberテーブルをSelectし、オブジェクトにマッピングする val member = Member.select { Member.id eq id } .first() .let { MemberDto( id = row[Member.id].value, name = row[Member.name], role = listOf(row[Mailing.role]) ) } // MailingテーブルをSelectし、リストにする val mailingAddress = Mailing .select { Mailing.memberId eq member.id } .map { it[Mailing.address] } // オブジェクトのコピーを作り配送先のデータをマッピング member.copy(mailingAddress = mailingAddress)}もっとも簡単で、コードとしてもわかりやすい方法ではありますが、トランザクションの観点からするとあまりよくない方法ですね。Exposedでは、transactionブロックに包むことでトランザクションの単位を制御できるものの、一回で済ませるクエリの発行が複数になるという問題があります。ここではMemberテーブルを照会するたびにMailingテーブルも照会することになるので1回のクエリが追加されているだけですが、もしMemberテーブルに1:Nの関係となっているテーブルが増えれば増えるほどクエリの発行数も増えることになるでしょう。そして今回は一つのレコードに対してのコードとなっていますが、照会対象のMemberテーブルのレコードが増えれば増えるほど発行されるクエリの数も多くなります。また、オブジェクトのインスタンスを作っておいて、わざわあコピーするというのもあまり効率が良いとは言えません。これもまたクエリの数が増える問題と同じく、照会対象のレコードが増えれば増えるほど生成されるオブジェクトのインスタンスも増えることになるという訳ですね。なので、全く性能や効率を考えてないコードと言えます。joinしてマッピングする関係のあるデータを複数のテーブルを跨いで取得するには、やはりjoinが効率的でしょう。これならまず発行されるクエリの数は個別のテーブルに対してSelectする時に比べ、劇的に減ります。アルゴリズムでよく使われる表現のBig O記法で表現すると、前者はO(N^2)であり、これはO(1)と表現できるはずです。ならばデータを取得する際に、クエリとしてはjoinを使うのが理想的なのはわかりますが、問題はそうやって取得したデータをどう加工するかです。先に述べましたが、取得したデータのうち重複するものがあるからですね。そしてこれが重複しているかどうかはクエリを実行した結果を取得して、確認するまではわかりません。ここで考えられる方法は三つほどありますので、一つづつ紹介していきます。reduceまずはクエリの結果として取得した行を、それぞれオブジェクトにマッピングした後、reduceでまとめる方法です。例えば以下のようになります。transaction { Member.leftJoin(Mailing) .select { (Member.id eq id) and (Mailing.memberId eq Member.id) } .map { // とりあえずオブジェクトにマッピングする MemberDto( id = it[Member.id].value, name = it[Member.name], mailingAddress = listOf(it[Mailing.address]) ) }.reduce { acc, memberDto -> // オブジェクトを一つに集約させる（mailingAddressは累計） acc.copy( mailingAddress = acc.mailingAddress + memberDto.mailingAddress ) }}このやり方で考えられる問題は、まず行数分のオブジェクトのインスタンスが作られるということです。このクエリとして取得しようとしているMemberのレコードは一つのみですが、そのレコードに紐づくMailingのレコードが多ければ多いほど件数は増え、当然生成されるオブジェクトの数も多くなります。また、マッピングだけでなく、reduceでもオブジェクトをコピーしているので、やはり行数分のオブジェクトが生成されていると考えられます。オブジェクトのインスタンス数は行数x2になる訳ですね。そしてもう一つの問題は、Memberのレコードを複数取得する場合、全部一つのオブジェクトにまとまってしまうという問題がありますね。なので、このやり方だと一つのレコードを取得する場合のみしか適応できなくなります。groupBy取得したレコードを、一度Mapに変換するとどうでしょうか。KotlinのCollectionにはgroupByというメソッドがあり、keyとvalueのマッピング方法を指定すると、一つのkeyにList形式のvalueになります。Mapなので、keyでMemberのオブジェクトをマッピングしておいて、valueとしてはMailingのレコードをまとめておくと良いでしょう。keyは同じものだと上書きされるので、取得したいMemberのレコードが複数の場合でも問題ないはずです。コードでは、以下のようになります。transaction { Member.leftJoin(Mailing) .select { (Member.id eq id) and (Mailing.memberId eq Member.id) } // keyはMemberオブジェクトのマッピング、valueではMailingのレコードを集約 .groupBy({ MemberDto( id = it[Member.id].value, name = it[Member.name], ) }, { it[Mailing.address] }) // keyのオブジェクトにMailingのレコードを設定 .map { (key, value) -> key.copy(mailingAddress = value) }}この方法だと、今まで照会した他の方法で考えられる問題をだいぶ解消できそうな気がしますね。ただ、気になるのは、groupByの引数がLambdaであることです。引数として関数を渡すということは、ループしながらその関数を実行することになるという意味なので、reduceの時と同じ量のインスタンスが作られる可能性がありそうですね。なので、groupByの実装を見ていきたいと思います。中のコードは、以下の通りです。public inline fun <T, K, V> Iterable<T>.groupBy(keySelector: (T) -> K, valueTransform: (T) -> V): Map<K, List<V>> { return groupByTo(LinkedHashMap<K, MutableList<V>>(), keySelector, valueTransform)}groupByの実装では、groupByToという関数に自分の引数と、作られるMapのインスタンスを渡しているだけですね。では、さらにgroupByToの中身を見ていきましょう。public inline fun <T, K, V, M : MutableMap<in K, MutableList<V>>> Iterable<T>.groupByTo(destination: M, keySelector: (T) -> K, valueTransform: (T) -> V): M { for (element in this) { val key = keySelector(element) val list = destination.getOrPut(key) { ArrayList<V>() } list.add(valueTransform(element)) } return destination}ここで確かになっていることは、やはり最初のCollectionの要素数分、keySelectorとvalueTransformを実行しているということです。Mapに変えることになるので、reduceの時とは違ってMemberレコードがいくつあっても一つに集約されるような事態は起こらないと考えられますが、依然としてオブジェクトのインスタンスが複数できてしまうという問題はあります。なので、また他の方法を探してみましょう。Map最後に考えられるのは、Selectした行をMapにまとめるのではなく、外部にMapを宣言し、それを利用することです。Mapには、computeという関数があり、引数として渡したkeyに対してどんな処理をするか（どんなvalueを作って入れるか）を指定できます。例えば、指定したkeyに対してvalueが存在しない場合は要素として追加し、存在する場合はそのvalueを変えるなどの処理ができるようになります。なので、これをうまく使うとインスタンスの生成問題を解決できる気がしますね。トランザクションとは関係のないMapをまず宣言し、Selectしたデータに対してcomputeを実行することにします。computeでは指定したkey（Memberのidなど）がMapの中にない場合にMemberのインスタンスを作成するようにして、すでにある場合はそのオブジェクトにMailingのデータを追加するようにすれば良いでしょう。そしてループが終わったらMapのvalueのみを取得すると良いですね。以上のことを、コードで表すと以下のようになります。// オブジェクトをまとめるためのMap（keyはMember.id）val helperMap = mutableMapOf<Int, MemberDto>()transaction { Member.leftJoin(Mailing) .select { (Member.id eq id) and (Mailing.memberId eq Mailing.id) } .forEach { helperMap.compute(it[Member.id].value) { key, value -> // valueがnullではない場合、コピーしてmailingAddressを累計 value?.copy( mailingAddress = value.mailingAddress + it[Mailing.address] // valueがnullの場合はインスタンスを作る ) ?: MemberDto( id = key, name = it[Member.name], mailingAddress = listOf(it[Mailing.address]) ) } }.let { // valueをListに変換 helperMap.map { it.value } }}いかがでしょうか。これで重複するデータなく、インスタンスの作成も最低限に抑えることができたかと思います。もちろん、mailingAddressを追加するたびにコピーが発生するという問題はありますが、ここは専用のsetterなどを作っておくことで回避できると思います。一つ注意しなくてはならないのは、ここで使っているMapをフィールドとして宣言したりするとデータの整合性やアプリケーションのメモリ使用量に響くということです。なので必ずメソッドの中でのみMapのインスタンスが作成されるようにする必要があります。最後にDSLを使ってクエリを直接作成する場合、JPAのようなORMの問題とされているN+1(必ず連関しているテーブルもjoinしてくる)のような問題を回避できますが、直接オブジェクトへのマッピングも書かなくてはならないという短所がありますね。個人的にクエリを書くのは楽しくないですが、クエリをコードとして管理でき、必要なクエリだけを書けるというところでDSLの方が良い点もあると思います。テーブルの構造や処理によってはORMが勝手にクエリもマッピングもしてくれるのが楽ではありますが。ただ、ORMでどうやってデータを取得するかの問題だけでなく、ここで扱った「重複するデータをどう違う形のデータに加工するか」の問題は、必ずしもDBからレコードを取得する場合のみのことに限らないので（例えば他のAPIを読んだ結果としてもそんなデータはあり得ますね）、色々方法を考えておく必要はありそうです。今の時点ではMapを利用した方法がもっとも良さそうな気がしますが、他にもっと効率的な方法があるかもしれませんしね。では、また！

ExposedでOneToManyをどうマッピングするか

サーバサイド言語としてのKotlinは普及しつつありますが、Kotlinを使う場合でもウェブフレームワークとして使われるのはやはりSpringが多いかと思います。理由としては会社ごとの事情というものもあるはずですが、一般的な理由としてはJavaエンジニアにとってKotlinは馴染みやすい物であっても、フレームワークの場合はそうでなく、Springほど検証されたフレームワークはないからということからでしょう。いまだにStrutsを使っていて、Springに移行しようとするところもありますしね。KotlinはJavaと完璧（に近い）互換性があるので、Javaで書かれてあるアプリをそのままKotlinに移行しても大した問題はありません。Javaより生産性が高い上にSpringだけでなくJackson、Apache POI、JUnit、Jacocoなどの数多くのライブラリをそのまま使えるのは確かにメリットであって、企業側としてKotlinの導入を検討する理由は確かにそこにあると思います。Javaエンジニアはその数が多いので、エンジニアを募集し安くなるというところもメリットの一つと言えるでしょう。ただ、Kotlinを使う場合に長期的にはKotlinで書かれたライブラリやフレームワークを導入することを検討した方が良いかもしれません。コンパイルした結果として生成されるByte codeがJavaと全く一緒だとしても、そもそものソースコードが違う言語なので、使う側のコード（クライアントコード）としては不便なところがあったり、Kotlinに最適化されてない場合もある可能性があるからです。また、KotlinはJVMだけでなく、ネイティブにコンパイルすることもできるので、ネイティブなアプリを作りたい場合はJavaに依存しないAPIを選ぶ必要があるでしょう。ということで、今回はJetBrains制のウェブフレームワーク、Ktorと、Ktorと一緒に使えるORMのExposedを少し触ってみて、Springと比べながら紹介したいと思います。KtorKtorは、JetBrainsで開発しているマイクロサービス向けの軽量ウェブフレームワークです。公式ホームページの紹介にも色々書いてありますが、特にSpringと比べて以下の特徴があるかと思います。軽量Springも軽量とは言われているものの、起動が遅いので、実装する側としてはあまり軽量だという感覚はないです。Springで書かれたアプリケーションの起動が遅いのは、起動時にさまざまなアノテーションを読み込み、DIや設定などを完璧に終わらせているというフレームワークそのもののアーキテクチャに起因しているのではないかと思います。なのでDIされるオブジェクトをLate initにするなどで起動速度を短縮させるテクニックなどが知られていますね。しかし、Ktorは起動がかなり早いです。同一規模のアプリをSpringとKtorの両方で作成してベンチマークした訳ではないので正確な数値に関しては割愛しますが、体験だと数倍は早いですね。例えば、In memoryタイプのH2と基本的なCRUDを実装したSpring WebFluxアプリケーションの場合、自分のPCで起動に2.7秒ほどかかりました。2021-07-18 15:08:25.150 INFO 29047 --- [main] c.r.s.SpringWebfluxSampleApplicationKt : Started SpringWebfluxSampleApplicationKt in 2.754 seconds (JVM running for 3.088)同じ構成でKtorのアプリを実装した場合、起動には1秒もかからなかったです。2021-07-18 15:09:29.683 [main] INFO ktor.application - Application started in 0.747 seconds.これはおそらく基本的にDIをしなく、アノテーションをあまり使わない（Reflectionを使わない）構造やKtorそのものはREST APIを作成するための必要最低限の機能だけを揃っているのが理由かと思われます。アプリの起動が早いというのは、テストにかかる時間を短縮させられるという面でもメリットといえますが、サーバレスなアプリにも適しているということにもなるでしょう。私もAWSのLambdaやAzureのFunctionsなどを触った経験がありますが、この場合にJavaやKotlinの使用を考慮したことはありません。サーバレスの場合、アプリが常に稼働中ではないので、リクエストが発生したたびにアプリを起動しなければならないです。なので起動の遅いSpringはそもそもの考慮対象にならなかったですね。Ktorを使う場合は起動速度が大幅に短縮できるので、JVMの起動速度が許されるというならば、サーバレスアーキテクチャで導入を検討できるレベルになっていると思います。拡張可能Ktorが軽量であることとも繋がる話ですが、必要な機能があればプラグイン（モジュール）を追加したり、自分で実装する必要はあります。コードとしては、以下のようになります。fun main() { embeddedServer(Netty, port = 8080, host = "127.0.0.1") { install(CORS) install(Compression) install(Sessions) { cookie<MyCookie>("MY_COOKIE") } install(ContentNegotiation) { // kotlinx.serialization json() } }.start(wait = true)}なので、Ktorの導入直後はモジュールの管理や開発のスピード感という側面ではマイナスになる部分もあるかなと思います。特にまだSpring Securityでは基本的に提供しているRole-Based Authorizationなどの機能が公式プラグインとして提供されてないので自前の処理を書くしかないという部分もあります。個人的には、モジュール化そのものは慣れたらメリットになる可能性の方が高いと思いますが、導入初期としてはSpringに比べ不利なところなのではないかと思います。特にKtorはDIに対応していなく、JetBrains公式のモジュールもないので、DIをするためにはInjekt, Kodein, Koinなどをディペンデンシーとして追加する必要があります。ただ、アーキテクチャによってはDIが必要なく、objectで代替することもできると思いますので、どんなアーキテクチャにするかはよく考えて決める必要があるかなと思います。Coroutine対応Spring WebFluxもそうでしたが、最近は多くのウェブフレームワークに非同期・ノンブロッキング対応が行われていますね。PaaSが普及され簡単にインフラの構築ができ、ハードウェアが安くなった今でもソフトウェアで性能を改善できる箇所があるならそれは十分価値があると思っています。だとすると、非同期・ノンブロッキング対応のフレームワークを導入するということも良い選択ではないかと思います。Ktorではルーティングの実装として、Routeのroute、もしくはget, post, put, deleteなどのfunctionを呼び出すことになります。これはSpring WebFluxのRouter/Hanlder Functionとよく似ていますね。コードで表すと、以下のようなものです。routing { get("/hello") { call.respondText("Hello") }}そしてこのHttpメソッドごとの関数のbodyを実装することになりますが、これが基本的にsuspendとなっています。これはつまり、実装する側で特に意識しなくてもコードは非同期になるということですね。Spring WebFluxの場合も、Coroutineを使うと簡単に実装ができましたが、suspendすら意識しなくて良いというところはKtorならではのメリットなのではという気がします。テストktor-server-test-hostやkotlin-test、JUnitなどを使ってテストが可能です。Springでもユニットテストは色々な書き方があるかと思いますが、よりKotlinらしき書き方になっているだけで、基本的にテストの仕方が大きく変わったりはしません。例えば、Getをのレスポンスをテストするためには以下のようなコードを書くことができます。@Testfun getMember() { withTestApplication(Application::module) { handleRequest(HttpMethod.Get, "api/v1/web/members/$id").apply { assertEquals( actual = response.status(), expected = HttpStatusCode.OK ) assertEquals( actual = response.content, expected = Json.encodeToString( MemberResponse( id = id, userId = userId, name = name ) ), ) } }}ExposedKtorで使える、Kotlinで書かれたORMは代表的にExposedがあります。JavaのjOOQがそうであったように、SQL DSLを使うことでクエリをコードで書くような感覚で（実施はDSLを解釈してSQLは自動生成されますが）使えるというところが良いです。例えば、Userというテーブルからレコードを取得する場合のコードは、以下のようになります。val userInUsa: List<User> = transaction { UserTable.select { UserTable.deleted eq false }.map { User( id = it[UserTable.id], name = it[UserTable.name], country = it[UserTable.country] ) }.filter { it.country = Country.USA }}また、ExposedでははDAOパターンも使えるので、DAOパターンでクエリを書くとしたら以下のようなことができます。JPAやR2DBCと似たような感覚で使えそうですね。(デメリットもおそらく同じかと思いますが)val userInGermany: List<User> = transaction { User.find { (UserTable.country eq Country.GERMANY) and (UserTable.deleted eq false)}}また、Exposedの特徴は、テーブルをコードとして定義することでDBに反映させることができるということです。今までLiquibaseやFlywayでDBの形状管理をやっていたことが多かったのですが、個人的に実際のDBとアプリケーションのテーブル定義に乖離があるケースを考えるとこうやってコードの中に定義した方が、データのオーナーという観点からもかなり良いのではないかと思います。特に、頻繁なテーブル定義の修正があったり、マイクロサービスが多いケースではかなり開発が便利になるのではないかと思います。Exposedのテーブル定義は、以下のようにできます。object Member : IntIdTable() { val userId: Column<String> = varchar(name = "user_id", length = 16) val name: Column<String> = varchar(name = "name", length = 16) val password: Column<String> = varchar(name = "password", length = 255) val deleted: Column<Boolean> = bool("deleted") val createdBy: Column<String> = varchar("created_by", 16) val createdDate: Column<LocalDateTime> = datetime("created_date") val lastModifiedBy: Column<String> = varchar("last_modified_by", 16) val lastModifiedDate: Column<LocalDateTime> = datetime("last_modified_date")}そして実際発行されるSQLは以下のようになります。CREATE TABLE IF NOT EXISTS "MEMBER" (ID INT AUTO_INCREMENT PRIMARY KEY, DELETED BOOLEAN NOT NULL, CREATED_BY VARCHAR(16) NOT NULL, CREATED_DATE DATETIME(9) NOT NULL, LAST_MODIFIED_BY VARCHAR(16) NOT NULL, LAST_MODIFIED_DATE DATETIME(9) NOT NULL, USER_ID VARCHAR(16) NOT NULL, "NAME" VARCHAR(16) NOT NULL, PASSWORD VARCHAR(255) NOT NULL)ここで、JPAやR2DBCの場合、Auditableクラスを定義して、エンティティがそれを継承することでカラムを共有したり、Spring Securityに連携することができましたが、Exposedでも似たようなことができました。abstract class Audit : IntIdTable() { val deleted: Column<Boolean> = bool("deleted") val createdBy: Column<String> = varchar("created_by", 16) val createdDate: Column<LocalDateTime> = datetime("created_date") val lastModifiedBy: Column<String> = varchar("last_modified_by", 16) val lastModifiedDate: Column<LocalDateTime> = datetime("last_modified_date")}object Member : Audit() { // Auditのカラムも含めてテーブルが作成される val userId: Column<String> = varchar(name = "user_id", length = 16) val name: Column<String> = varchar(name = "name", length = 16) val password: Column<String> = varchar(name = "password", length = 255)}MyBatisなどに慣れている場合は少し適応に時間が必要かもしれませんが、基本的にはテーブルの定義を除くとほぼSQLの発行をKotlinのコードで書くことになるという感覚なので、便利になるかと思います。最後に以上で、簡単なCRUDアプリをKtor + Exposedで実装してみた後の感想と紹介を少し書いてみました。まとめると、かなりサクサクコードを書けて性能も良いので、マイクロサービスに特化している構成ではないかと思いました。また、冒頭に述べた通り、ピュアなKotlin制のフレームワークであることも良いですね。Ktorの紹介でもKotlin Multiplatformに基づいていてどのプラットフォームにもアプリをデプロイできると強調していますので、色々なところで活用ができるかと思います。まだSpringと他のJavaライブラリに比べ足りないモジュールや機能もありますが、Exposed以外でもKtormのようなORMがあるなどKotlin制のライブラリの開発も進めていて、IntellijでもKtorのサポートは強力なので今後も発展を期待できそうであります。個人的にまだ仕事で使うことには無理があっても、自作アプリなどを作りたい時は導入をぜひ検討したいと思いました。Kotlinでできることがだんだん増えてきていて、嬉しいですね。では、また！

Ktorを触ってみた

前回に続いて、今回も簡単にKotlinで色々書いてみましたのでその紹介となります。Kotlinではスタンダードライブラリや言語仕様として提供している機能がかなり多いので、これらを使いこなすだけでも生産性やコードのクォリティが大幅に上がるのではないかと思います。なので、今回もJava的な書き方を、Kotlinではどんな方法で効率よく実現できるかを中心に紹介したいと思います。もちろんKotlinでは基本的にJavaの書き方でも全く問題なく動くコードを書けますが、Kotlinならではのコードに変えた方がより簡単で短いコードを書ける場合が多く、色々と手間を省けることができるので（そして大抵の場合、スタンダードライブラリの実装の方が自分の書いたコードよりクォリティ高いような…）こういう工夫はする価値が十分にあるのではないかと思います。なので、今回は自分が調べたKotlinの小技を少し紹介したいと思います。Sequentialなデータを作成するよくユニットテストなどでテスト用データを作成して使う場合がありますね。こういう時に必要となるデータの種類は色々とあるかと思いますが、複数のレコードを番号をつけて順番に揃えた感じのものを作りたい場合もあると思います。例えばData01、Data02、Data03…といったデータを作りたい場合ですね。この場合は、ループでデータを作り、Listにまとめるというのが一般的ではないかと思います。例えば以下のような例があるとしましょう。// テスト用データを作成するfun createTestDatas(): List<String> { // テスト用データのリスト val testDatas = mutableListOf<String>() // 10件のデータを追加 for (i in 0 until 10) { testDatas.add("テスト$i") } // read-onlyに変換して返却 return testDatas.toList()}ただ、どちらかというとこれはJavaのやり方に近いので、まずはこれをベースに、Kotlinらしきコードではどうやって同じことができるかを考えてみたいと思います。repeatまず考えられる方法は、ループの単純化ですね。サイズが10のリストを作りたいということは、ループが10回であることなので、それに相応しい関数を使います。例えばrepeatがありますね。repeatを使うと、スコープ内のパラメータとしてインデックスが渡されるので、簡単にfun createTestDatas(): List<String> { val testDatas = mutableListOf<String>() // 10回繰り返す repeat(10) { testDatas.add("テスト$i") } return testDatas.toList()}次に考えたいのは、MutableListをImmutableに変えることです。テストで使うデータとしては問題ない場合はありますが、変更する必要のないデータをそのままMutableにしておくのはあまり良い選択ではありませんね。なので、データの作成を最初からListにできる方法を取りたいものです。ここでは二つの道があって、最初からサイズを指定したListを宣言するか、ループの範囲、つまりRangeを指定する方法があります。Listまずはサイズを指定したListを作る方法からみていきましょう。インスタンスの作成時に、サイズと要素に対してのイニシャライザを引数として渡すことで簡単に指定したサイズ分の要素を作ることができます。例えば、上で紹介したコードはListを使うことで以下のように変えることができます。fun createTestDatasByList(): List<String> = List(10) { "テスト$it" }この方法は、実は先に紹介した方法と根本的に違うものではありません。実装としては、以下のようになっているので、Syntax sugarとして使えるということがわかります。@SinceKotlin("1.1")@kotlin.internal.InlineOnlypublic inline fun <T> List(size: Int, init: (index: Int) -> T): List<T> = MutableList(size, init)@SinceKotlin("1.1")@kotlin.internal.InlineOnlypublic inline fun <T> MutableList(size: Int, init: (index: Int) -> T): MutableList<T> { val list = ArrayList<T>(size) repeat(size) { index -> list.add(init(index)) } return list}他にもListを使う場合は、itnitとしてどんな関数を渡すかによって、stepの設定などができるのも便利ですね。例えば以下のようなことができます。List(5) { "Test${ it * 2 }" }// [Test0, Test2, Test4, Test6, Test8]List(5) { (it * 2).let { index -> "$index は偶数" } }// [0 は偶数, 2 は偶数, 4 は偶数, 6 は偶数, 8 は偶数]ただ、結果的に作られるListのインスタンスはMutableListなので、生成したデータをread-onlyにしたい場合はまたこれをtoList()などで変換する必要があるという問題があります。Rangeでは、もう一つの方法をまた試してみましょう。Kotlinでは数字の範囲を指定することだけで簡単にRangeオブジェクトを作成することができます。Rangeを使う場合、上記のコードは以下のように変えられます。// Rangeを使ってテストデータを作るfun createTestDatasByRange(): List<String> = (0..10).map { "テスト%it" }Listの時とは違って、RangeにはIntRangeやLongRange、CharRangeなどがあり、引数の数字や文字を調整することで簡単にアレンジができるということも良いです。また、一般的に性能はListよりRangeの方が良いようです。以下のようなコードでベンチマークした際、大抵Rangeの方がListの倍ぐらい早いのを確認できました。import kotlin.system.measureTimeMillisdata class Person(val name: String, val Num: Int)fun main() { benchmark { list() } benchmark { range() }}fun benchmark(function: () -> Unit) = println(measureTimeMillis { function() })fun list() = List(200000) { Person("person$it", it) }fun range(): List<Person> = (0..200000).map { Person("person$it", it) }一つ気にしなくてはならないのは、Rangeの場合は基本的に値が1づつ増加することになっているので、forやListのようなstepの条件が使えません。なので場合によってどちらを使うかは考える必要があります。CheckValidationなどで、パラメータの値を確認しなければならない場合があります。KotlinではNullableオブジェクトとそうでないオブジェクトが分けられているので、Javaと違って引数にnullが渡される場合はコンパイルエラーとなりますが、ビジネスロジックによってはそれ以外のことをチェックする必要もあり、自前のチェックをコードで書くしかないです。まず、お馴染みのJavaのやり方を踏襲してみると、以下のようなコードを書くことができるでしょう。関数の引数と、その戻り値のチェックが含まれている例です。fun doSomething(parameter: String): String { if (parameter.isBlank()) { throw IllegalArgumentException("文字列が空です") } val result = someRepository.find(parameter) if (result == null) { throw IllegalStateException("結果がnullです") } return result}ここで少し違う言語の例をみていきたいと思います。Kotlinとよく似ていると言われているSwiftの場合、ここでGuard Statementを使うのが一般的のようです。チェックのための表現が存在することで、ビジネスロジックとチェックが分離されるのが良いですね。Swiftをあまり触ったことがないので良い例にはなっていないかもしれませんが、イメージ的には以下のようなコードになります。func doSomething(parameter: String) throws -> String { guard !parameter.isEmpty else { throw ValidationError.invalidArgument } guard let result = someRepository.find(parameter) else { throw ValidationError.notFound } return result}同じく、Kotlinでもチェックのための表現とビジネスロジックが分離できれば、コードの意味がより明確になるはずです。Kotlinではどうやってそれを実現できるのでしょうか。例えば以下のようなことを考えられます。fun doSomething(parameter: String?): String { val checkedParameter = requireNotNull(parameter) { "文字列がnullです" } val result = someRepository.find(checkedParameter) return checkNotNull(result) { "結果がnullです" }}requireNotNullは、渡された引数がnullである場合はIllegalArgumentExceptionを投げ、そうでない場合は引数をnon-nullタイプとして返します、明確にnullチェックをしていることが解るだけでなく、以降チェックがいらないので便利です。また、lazy messageとしてIllegalArgumentExceptionが発生した時のメッセージを指定できるのも良いですね。checkNotNullの場合も機能的にはrequireNotNullと変わらないですが、nullの場合に投げる例外がIllegalStateExceptionとなります。なので、用途に合わせてこの二つを分けて使えますね。他に使えるものとしてはrequireがあります。こちらは条件式を渡すことで、nullチェック以外のこともできます。なので、以下のコードのように、Int型のデータに対して範囲をチェックするということもできるようになります。fun doSomething(parameter: Int) { require(parameter > 100) { "$parameterは大きすぎます" } // ...}他にも、Elvis operatorを使う方法もありますね。この場合は、nullの場合にただ例外を投げるだけでなく、代替となる処理を書くことができますので色々と活用できる余地があります。例えば以下のようなことができますね。fun doSomething(parameter: String?): String { val checkedParameter = parameter ?: "default" val result = someRepository.find(checkedParameter) return result ?: throw CustomException("結果がnullです")}Listの分割とある条件と一致するデータをListから抽出したい場合は、filterのようなoperationを使うことでできます。しかし、条件が二つだとどうすればいいでしょうか。正確には、一つのリストに対して、指定した条件に一致する要素とそうでない要素の二つのリストに分離したい場合です。こういう場合はとりあえず下記のように2回ループさせる方法があると思いますが、これはあまり効率がよくないです。val origin = listOf(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)// 奇数を抽出val odd = origin.filter { it % 2 != 0 }// 偶数を抽出val even = origin.filter { it % 2 == 0 }ループを減らすためには、あらかじめ宣言したリストに対してループの中で分岐処理を行うという方法があるでしょう。例えば以下のようにです。val origin = listOf(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)// 奇数と偶数のリストを宣言しておくval odd = mutableListOf<Int>()val even = mutableListOf<Int>()// ループ処理origin.forEach { if (it % 2 != 0) { odd.add(it) // 奇数のリストに追加 } else { even.add(it) // 偶数のリストに追加 }}幸い、この状況にぴったりな方法をKotlinのスタンダードライブラリが提供しています。partitionというoperationです。このopreationを使うと、元のリストの要素を条件に一致するものとそうでないもので分割してくれます。また、partition戻り値はPair<List<T>, List<T>>なので、destructuring-declarationと組み合わせることでかなり短いコードになります。実際のコードは以下のようになるりますが、かなりスマートですね。val origin = listOf(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)val (odd, even) = origin.partition { it % 2 != 0 } // 条件に一致するものと一致しないものでリストを分離最後にKotlinは便利ではありますが、言語自体が提供する便利さ（機能）が多いゆえに、APIの使い方を正しく活用できるかどうかでコードのクォリティが左右される部分が他の言語と比べ多いような気がしています。さらにバージョンアップも早く、次々と機能が追加されるのでキャッチアップも大事ですね。でも確かに一つづつKotlinでできることを工夫するうちに、色々とできることが増えていく気もしていますね。研究すればするほど力になる言語を使うということは嬉しいことです。ということで、これからもKotlinで書いてみたシリーズは続きます。では、また！

Kotlinで書いてみた〜その二〜

Sequenceは常にいいか

WebFluxではFunctional Enpointを使うべきか

Kotlin(JVM)は、コンパイルした結果がJVMのバイトコードになります。Javaで書かれたライブラリをそのままKotlinで利用できるのはそのためですね。これはKotliのライブラリに対しても同じなので、スタンダードライブラリを覗くとJavaの機能に依存しているところも少なくないです。ただ、KotlinがコンパイルしたらJVMのバイトコードになるということは、単純にKotlinが「書き方が違うJava」であるという意味ではないです。これはKotlinがJavaと言語スペックが違うという点もありますが、JVMだけでなく、JavaScriptやネイティブコードにコンパイルされることも想定してデザインされているので、スタンダードライブラリスタンダードライブラリはプラットフォームに合わせて違う実装になっています。そしてJVMだとしてもJavaのAPIをそのまま利用しているわけではありません。Kotlinのこういう構造は、内部のソースコードを見るとはっきりします。スタンダードライブラリの一部メソッドやクラスにはexpectとactualというキーワードが使われていますが、これらはJavaのinheritanceと似ているようなものです。Javaではinterfaceで定義したメソッドを、それを継承したクラスでoverrideで実装して使うことになりますね。同じく、Kotlinではexpectとして定義された機能をプラットフォームに合わせてactualで実装しているわけです。また、KotlinのスタンダードライブラリはJavaと一見同じようなものに見えるとしても、実際は違うケースもあります。actualによって実装されたコードがKotlinに合わせて、書かれているからですね。なので、Kotlinのスタンダードライブラリに対しては「Javaと同じだろう」という認識をするのは危険な可能性もあります。今回はそういうことで、文字列のwhitespaceに関しての機能を、スタンダードライブラリのソースコードを中心に見ていきたいと思います。whitespaceの判定とある文字列が意味のある(有効な)データであるかどうかを判定する方法の一つは、その文字列がただの空白であるかどうかを判定することです。つまり、そもそもなんのデータもなかったり、whitespaceだけでないかというチェックをするということですね。こういう場合の判定はKotlinのスタンダードライブラリで簡単に行うことができます。KotlinではStringのメソッドとして基本的に以下の二つを提供しています。isEmpty()isBlank()Java 11以降でもこれらと同名のメソッドが存在しているので、一見そのままの感覚で良さそうにも見えます。しかし、Kotlinではこれらのメソッドがまずkotlin.text.Stringsから呼ばれるものとされています。JavaのAPIをそのまま使っているわけではないので、処理も違う可能性があるという推測ができますね。ここで前者の場合、文字列が単純になんのデータも持ってないかどうかに対する判定をおこないます。実際のソースコードを見ると、文字列の長さだけをチェックしているのを確認できます。ちなみにJavaではStringはCharSequenceを継承していますが、Kotlinとしてもライブラリは違えどそういう継承関係は一緒です。なので、KotlinではStringのメンバーでありながらもCharSequenceの関数として書かれています。public inline fun CharSequence.isEmpty(): Boolean = length == 0後者の場合は、文字列にwhitespaceまで含めているのかを判定します。以下のコードを見ると、何をやっているかが明確でしょう。public actual fun CharSequence.isBlank(): Boolean = length == 0 || indices.all { this[it].isWhitespace() }isBlank()で呼び出しているisWhitespace()は、以下のような実装となっています。public actual fun Char.isWhitespace(): Boolean = Character.isWhitespace(this) || Character.isSpaceChar(this)KotlinのChar.isWhitespace()は最終的にCharacter.isWhitespace()とCharacter.isSpaceChar()を使って判定することになります。前者の場合はUnicodeのwhitespaceに当てはまるか、後者の場合はUnicodeのspace(改行コードなど)に当てはまるかを判定するJavaのAPIです。ここでわかるように、特集なケースでなければなるべくisEmpty()を使った方が文字列をチェックする時に良いでしょう。whitespaceの削除文字列が単純に意味のあるデータを持っているかどうかを判定するには、前述通りisEmpty()を使うと良いですが、文字列にwhitespaceだけでなく、意味のあるデータも混在する場合もありますね。こういう時は前後のwhitespaceを取り除きたくなります。Javaでは、文字列の前後のwhitespaceを消去する方法としてtrim()とstrip()がありました。前者は昔ながらのもので、全角のwhitespaceを検知できなく、性能の問題もあるのでJava 11以降は後者を使うことが推奨されています。ただ、Kotlinの場合は少し都合が違います。Kotlinでは基本的にtrim()だけを使うことになります。まずはtrim()の実装をみていきましょう。public inline fun String.trim(): String = (this as CharSequence).trim().toString()まずStringとしては、CharSequenceにアップキャストしてそのtrim()を呼び出すことにしています。そのあとは単純にtoString()で返すだけですね。続いて、Stringで呼ばれているCharSequence側のtrim()をみていきましょう。public fun CharSequence.trim(): CharSequence = trim(Char::isWhitespace)ここでは、オーバロードした他のtrim()にisWhitespace()をメソッドレファレンスとして渡しているのがわかります。Booleanが戻り値なので、引数はPredicateであると推測できますね。続けて、こちらで呼び出しているtrim(predicate)の方を確認します。こちらのコードは以下の通りです。public inline fun CharSequence.trim(predicate: (Char) -> Boolean): CharSequence { var startIndex = 0 var endIndex = length - 1 var startFound = false while (startIndex <= endIndex) { val index = if (!startFound) startIndex else endIndex val match = predicate(this[index]) if (!startFound) { if (!match) startFound = true else startIndex += 1 } else { if (!match) break else endIndex -= 1 } } return subSequence(startIndex, endIndex + 1)}ここまできてやっと実際の処理がでました。CharSequenceをループしながら左(start)から右の方にwhitespaceを探し、初めてwhitespaceでない文字を見つけたら右(end)から左の方にループしながら繰り返すという処理ですね。意外と単純ですが、効率的な処理です。そしてその処理での判断基準がisWhitespace()になっているわけですが、先に確認している通りこちらは最終的にJavaのAPIを呼ぶことになっているので、trim()でも十分Unicodeに定義されてあるwhitespaceやspaceまでを削除してくれると推論できます。なので、Javaとは違ってあえてstrip()を使う必要はなさそうです。また、trim()は文字列の前後のwhitespaceを削除しますが、場合によっては前方のみ、後方のみで分けて使いたい場合もあるかもしれません。その時は、以下のようなことができます。val string = " string "// 左のみtrimprintln(string.trimStart()) // "string "// 右のみtrimprintln(string.trimEnd()) // " string"これらのメソッドは引数としてPredicateを渡すこともできるので、他の条件を自前で書く必要がある場合にはそちらを使えますね。他にも、whitespaceではない、前後の特定の文字(prefix、suffix)を削除してたい場合は以下のメソッドが提供されています。val string = "--hello--"// prefixのみ削除println(string.removePrefix("--")) // "hello--"// suffixのみ削除println(string.removeSuffix("--")) // "--hello"// 前後を削除println(string.removeSurrounding("--")) // "hello"改行を削除改行が文字列の前後に入っていればtrim()で十分ですが、文字列の中に改行が含まれていて、それを変えたい場合もありますね。例えばJSONをログに一行で出力したいだったり、以下のようなMulitiline Stringを一行にまとめたい場合です。val string = """ Hello World"""Intellijだと自動的にtrimIndent()をつけてくれますが、これはあくまでインデントに関与するものであって、中の改行まではtrimしてくれないです。こういう場合は、KotlinでもJavaでも対応するメソッドは特にないので、自分で処理を書くしかないですね。例えば、以下のようなコードが使えるでしょう。fun String.stripLine() = replace(System.lineSeparator(), " ")ただ、Javaでも13からText Blockが導入されているので、今後はJavaのAPIの方で上記のようなメソッドが追加されることを期待できるかもしれません。最後に最初にexpectとactualの話をしましたが、これらのキーワードはKotlin Multiplatformでもっとも重要な概念です。Kotlinで書いたコードをさまざまなプラットフォームで共有できるようにすることを目的としているので、こういう構造になっているのは自然ですね。なので、Kotlin/JVMだけでなく、他のことを試したい方にはとりあえず理解しておく必要があるキーワードだと思います。ちょっと独特なだけで、実体は単純なので、理解は簡単でしょう。また、KotlinのStringに関しては、JetBrains公式YouTubeチャンネルの動画で簡単に説明しているので、Kotlinで開発をしている方なら一度は参考にした方が良いかもしれません。他に、strip()をあえて使う必要はないと言いましたが、実際Kotlinの最新バージョンである1.5.0でもstrip()はdeprecatedになっていて、以下のようなコメントがついているので、次のバージョンで正式対応するまでは使わない方が良いですね。‘strip(): String!’ is deprecated. This member is not fully supported by Kotlin compiler, so it may be absent or have different signature in next major versionこういうケースでもわかるように、KotlinがJavaと100%互換性があると言い切れない側面もあるのではと思います。なので、JavaからKotlinに移行した場合(実際のコードであれ、開発者自身のスキルであれ)には、一度注意深くスタンダードライブラリの説明を読む必要があるかもしれません。では、また！

KotlinのString実装を覗く〜whitespace編〜

Kotlin(Java)では、java.timeパッケージのクラスで日付や時間を処理することができます。例えばLocalDateTimeやLocalDateなどがありますね。サーバサイドではこれらのクラスを使ってDBに日付や時間を入力したり、認証用のトークンの有効期間を設定したりの処理ができるようになります。他にもPeriodやDurationがあって、「期間」を扱うこともできますね。ただ、「年月」という単位を扱いたい場合はどうしたらいいでしょうか。例えば、口座の入出金明細などを照会する時に、「2月から4月まで」という風に期間を設定するケースなどがあるとしたら、いらない「日」や「時間」まで含めるのはあまり効率的でなく、場合によってはバグの原因になるかもしれません。こういった場合は確かな「年月」としてデータを扱うか、数字として表現するかなどどちらかの方法を考える必要があるでしょう。ということで、今回はこの年月を扱う方法について少し述べたいと思います。年月を年と月に年月を扱うということは、つまり、いつでも「年」と「月」という二つのデータとして分離できるようにしたいということにもなりますね。ここでは二つの方法で、「年月」を「年」と「月」の二つに分けて扱う方法について説明します。YearMonthとしてLocalDateやLocalDateTimeでは、基本的にISO-8601形式で日付を扱うことができます。もちろん、DateTimeFormatterを使って他の形式を指定することもできますが、扱うデータの形が違うだけで、本質的には「年月日」が基本となりますね。ISO-8601の「年月日」形式で日付を扱っているということは、つまり、SpringでREST APIを作っている場合、リクエストの値がISO-8601の形式を守っていればLocalDateTimeやLocalDate形式に自動変換されるということでもあります。例えば以下のようなリクエストのJSONがあるとしましょう。{ "id": "1", "date": "2021-04-01"}Spring側では以下のようなコードで、リクエストのdateをLocalDateに変換することができます。// リクエストボディdata class DateRequest(val id: Int, val date: LocalDate)// コントローラ@PostMapping("/date")fun date(@RequestBody request: DateRequest) { // ...}そして全く同じやり方で、LocalDateをYearMonthに変えることで年月に対応することができます。例えば以下のようなリクエストがあるとします。{ "id": "1", "yearMonth": "2021-04"}ここでyearMonthをYearMonthに変えるだけです。以下のようになります。// リクエストボディdata class YearMonthRequest(val id: Int, val yearMonth: YearMonth)// コントローラ@PostMapping("/year-month")fun yearMonth(@RequestBody request: YearMonthRequest) { // ...}YearMonthを使うことのメリットは、LocalDateTimeやLocalDateと同じくjava.timeパッケージに属するオブジェクトなので、それらと互換性があり、相互変換が自由ということでもあります。例えば以下のように使えます。>>> val yearMonth = YearMonth.now() // 現在の年月を取得>>> println(yearMonth)2021-04>>> val localDate = yearMonth.atDay(1) // 年月に日を指定してLocalDateにする>>> println(localDate)2021-04-01また、YearMonthは時間に関する便利なメソッドを多く提供しているので、単純に数値としての年月を扱うだけでなく、色々な要件に合わせて日付関連の処理が必要な場合に便利かもしれません。例えば以下のような機能が提供されます。>>> val yearMonth = YearMonth.of(2021, 5)>>> println(yearMonth)2021-05>>> println(yearMonth.getYear()) // 年を取得2021>>> println(yearMonth.getMonth()) // 月(Enum)を取得MAY>>> println(yearMonth.getMonthValue()) // 月(数字)を取得5>>> println(yearMonth.isLeapYear()) // うるう年であるかどうかfalse>>> println(yearMonth.atEndOfMonth()) // 月の最後の日(LocalDate)2021-05-31数字としてYearMonthで受け取って処理した方がもっとも綺麗な方法に見えますが、状況によっては素直にInt型で受け取った方が良い(もしくはそうするしかない)ケースもあるはずです。例えば以下のようなリクエストが送らられて来るようなケースですね。{ "id": "1", "yearMonth": 202104}そもそもyearとmonthのように別の項目になっていたとしたらもっとやりやすいのですが、このように年月が一つのInt型のデータとして送られてくる場合は自分で年と月を抽出する処理を作るしかないですね。例えば以下のようなextension functionを書くことができるでしょう。// 年を抽出するfun Int.extractYear(): Int = this / 100// 月を抽出するfun Int.extractMonth(): Int = this % 100実際のコードを動かしてみると、ちゃんと意図通り動くのを確認できます。>>> fun Int.extractYear(): Int = this / 100>>> 202104.extractYear()res4: kotlin.Int = 2021>>> fun Int.extractMonth(): Int = this % 100>>> 202104.extractMonth()res6: kotlin.Int = 4しかし、パラメータとして渡されたものはただのInt型なので、期待した通りの値ではない可能性もあるという問題があります。常にYYYYMMという形でデータが送られてくるかどうかをチェックする必要がありますね。そういう場合に、上記のコードだとリクエストのyearMonthが正しい年月の形式になっているかどうかがわかりません。なので、正規式を用いたバリデーションチェックを挟むことにしたらより安全になるでしょう。例えば、以下のようなコードを使えます。fun Int.toYearMonth(): Pair<Int, Int> = if (Regex("^(19|20)\\d{2}(0[1-9]|1[012])").matches(this.toString())) this / 100 to this % 100 else throw IllegalArgumentException("cannot convert")上記の関数は、以下のような使い方ができます。簡単に使えるのでいい感じですね。>>> val (year, month) = 202104.toYearMonth()>>> println(year)2021>>> println(month)4元の値を二つのIntに分けるために戻り値としてPairを使いましたが、場合によってはYearMonthの方が良いかもしれません。そういう場合は、以下のようなコードが使えます。fun Int.toYearMonth(): YearMonth = if (Regex("^(19|20)\\d{2}(0[1-9]|1[012])").matches(this.toString())) YearMonth(this / 100, this % 100) else throw IllegalArgumentException("cannot convert")年と月を年月にさて、今回は逆に「年」と「月」を繋げて「年月」にする場合の処理を考えてみましょう。二つのIntを合わせて、一つのInt(YYYYMM)にする形です。ここでまず考えられる方法は二つです。YearMonthを使った方法と、文字列に変換してから処理するという方法です。YearMonthでまずYearMonthを利用する場合は、年と月をそのまま引数として渡した後、Intに変換すれば良いですね。ただ、YearMonthは基本的にISO-8601形式なので、2021年4月だと2021-04となるのでIntへ変換ができません。なので、まずStringに変えてから、-を消してIntに変換することにします。以上の処理は、以下のようなコードになります。fun toYearMonth(year: Int, month: Int): Int = YearMonth.of(year, month).toString().replace("-", "").toInt()文字列で文字列で処理する場合は、単純にString templatesを使うことでも可能ですが、注意したいのは、月は112という範囲を持つので、単純にtemplateで年と月を繋げると20214のような形になり得る可能性もあるということですね。なので、padStart()を利用して、月が19の場合は先頭に0をつけるようにします。そのあとはIntに変換するだけですね。これは以下のようなコードになリます。fun toYearMonth(year: Int, month: Int): Int = "${year}${month.toString().padStart(2, '0')}".toInt()これらの方法は、引数が二つなので、infixとして定義することもできます(好みの問題かと思いますが)。>>> infix fun Int.toYearMonthWith(month: Int): Int = "${this}${month.toString().padStart(2, '0')}".toInt()>>> 2021 toYearMonthWith 5res10: kotlin.Int = 202105最後にいかがだったでしょうか。あまり難しいコードではなかったので、あえて記事にまでする必要があったのか、という気もしましたが、個人的にはYearMonthというクラスの存在を初めて知ったのもあり、Kotlinならではのコード(extension function)を書いてみたく試したことを共有したいと思った次第です。もしKotlinやJavaで年月を扱う必要がある方には、少しでも役に立てるといいですね。では、また！

年月を扱ってみる

サーバサイドの機能を作っていると、ファイルダウンロード機能が必要な時があります。ただ、ストレージに保存されてあるファイルをそのまま返すということだけでなく、場合によってはファイルを生成してそのまま返したり、複数のファイルをまとめて転送する必要もありますね。リクエストごとに一つのファイルをダウンロードさせるとしたら、実装はそう難しくないものですが、複数のファイルをダウンロードさせるという場合は少し複雑になりますね。ファイルを一つにまとめて送るとしたら、ZIPに圧縮した方が良いでしょう。幸い、Javaでは基本的にZipOutputStreamというAPIを提供しているので、エントリに圧縮対象のファイルを追加したあとZIPファイルを出力だけで良いです。ただ、単純にファイルが複数だるだけでなく、ディレクトリが多重にネストされてあったりする場合は、ディレクトリ構造を維持しつつそのまま圧縮するとかの追加的な処理が必要となります。そして場合によっては含めたくないファイルがあるケースもあったりしますね。そしてなるべくファイルの数に関係なく(ファイルが一つであれ、ディレクトリであれ)一つの機能で済ませたいものです。なので、今回はそのようなユースケースに合わせた簡単なメソッドを作る方法を、JavaのコードからKotlinへ移行していく過程を簡単に紹介したいと思います。今回紹介しますコードは、はBaeldungのJavaでZipを圧縮する方法に関する記事に紹介されてあるものをベースにしています。JavaまずJavaのコードを見ていきましょう。上記の記事には、以下のようなコードが紹介されています。public class ZipDirectory { public static void main(String[] args) throws IOException { String sourceFile = "zipTest"; FileOutputStream fos = new FileOutputStream("dirCompressed.zip"); ZipOutputStream zipOut = new ZipOutputStream(fos); File fileToZip = new File(sourceFile); zipFile(fileToZip, fileToZip.getName(), zipOut); zipOut.close(); fos.close(); } private static void zipFile(File fileToZip, String fileName, ZipOutputStream zipOut) throws IOException { if (fileToZip.isHidden()) { return; } if (fileToZip.isDirectory()) { if (fileName.endsWith("/")) { zipOut.putNextEntry(new ZipEntry(fileName)); zipOut.closeEntry(); } else { zipOut.putNextEntry(new ZipEntry(fileName + "/")); zipOut.closeEntry(); } File[] children = fileToZip.listFiles(); for (File childFile : children) { zipFile(childFile, fileName + "/" + childFile.getName(), zipOut); } return; } FileInputStream fis = new FileInputStream(fileToZip); ZipEntry zipEntry = new ZipEntry(fileName); zipOut.putNextEntry(zipEntry); byte[] bytes = new byte[1024]; int length; while ((length = fis.read(bytes)) >= 0) { zipOut.write(bytes, 0, length); } fis.close(); }}zipFileメソッドをみると、引数のfileToZipにZIPで圧縮したいファイルやディレクトリのパスを指定して、fileNameにはファイルもしくはディレクトリ名、zipOutには圧縮後のZIPのファイル名を指定するようになっています。そして実装としては、指定したファイルやディレクトリにhidden属性がある場合は圧縮しなく、圧縮元のファイルがディレクトリである場合は中のファイルを全部ZIPに含ませるという処理が含まれてありますね。対象のファイルとディレクトリを全部エントリに追加した後は、圧縮元を読み込んでZipOutputStreamに書き込むという処理となっています。これをKotlinのコードに変えてみましょう。Kotlinのコードに変えてみるJavaのコードをKotlinのコードに変えるのはそう難しくありません。Intellijの場合、すでにJavaのコードを貼り付けると自動でKotlinのコードの変換してくれる機能を搭載していますので。ただ、それだけでは十分ではないですね。簡単に変換ができるとしても、それが本当にKotlinらしいコードになっているとはいえない場合があります。そして、処理自体もより単純に、もしくは読みやすいコードにする方法もあるはずですね。上記のJavaコードをまずKotlinに変えて、色々改善したいところを含めて変えていきます。Kotlinらしいコードに変えるIntellij 2021.1を基準に、Javaのコードをそのまま貼り付けると以下のようなコードに自動変換されます。@Throws(IOException::class)private fun zipFile(fileToZip: File, fileName: String, zipOut: ZipOutputStream) { if (fileToZip.isHidden) { return } if (fileToZip.isDirectory) { if (fileName.endsWith("/")) { zipOut.putNextEntry(ZipEntry(fileName)) zipOut.closeEntry() } else { zipOut.putNextEntry(ZipEntry("$fileName/")) zipOut.closeEntry() } val children = fileToZip.listFiles() for (childFile in children) { zipFile(childFile, fileName + "/" + childFile.name, zipOut) } return } val fis = FileInputStream(fileToZip) val zipEntry = ZipEntry(fileName) zipOut.putNextEntry(zipEntry) val bytes = ByteArray(1024) var length: Int while (fis.read(bytes).also { length = it } >= 0) { zipOut.write(bytes, 0, length) } fis.close()}ここでもっとKotlinらしいコードに変えたい部分は、InputStreamやOutputStreamの使い方です。Javaでもtry-with-resourceがあって、Kotlinにはuse()があるのでそちらを使った方がcloseよりも良い気がします。また、ifはwhenに変えたり、forをforEach()に変えたりなどでよりやりたいことを明確にすることができるようにも見えます。個人的にはスコープをあえて分けたほうが責任が明確になり、処理を追うときに混乱しないのでなるべくスコープ関数やCollection専用のオペレーションを積極的に使用して処理の単位を分けられるところはきちんと分けたいと思います。Javaのやり方をとっても処理としては全く問題がありませんが、せっかくなのでKotlinならではのコードを描きたいものです。あえてIOExceptionを投げるという表示をしておくというのも、ランタイム時の例外の処理を強制してないKotlinには相応しくないのではないかという気もするので、アノテーションは削除することとします。IOからNIOに変えるNIOに関しては以前のポストで何回か言及したことがありますが、サーバのように頻繁かつ同時実行数が多いケースは積極的に採用した方が良いと思います。また、Java 1.8以降から追加されたメソッドでかなり便利に使える機能が多いので、IOをNIOに変えるだけでコードの量をかなり減らせる可能性もあります。特にディレクトリを指定した場合、そのディレクトリの子要素を循環するにはNIOのFilesが提供する機能が強力なので、今回はそれを積極活用することにします。シグニチャーを変える上記のメソッドでは、三つの引数を取っていますが、実際に必要なのは圧縮元のパスと、圧縮先のパスのみですね。ZipOutputStreamを呼び出し元で渡す理由は特になく、むしろこのメソッドを利用する度に定義する必要があるので不便ですね。そして、メソッドの中で単純にエントリを追加していて、呼び出し元とオブジェクトに対する処理の職務を分担するという構造もあまりよくないかと思います。なので、ZipOutputStreamの生成と使用はメソッドの中で完結するように変えることにします。こうすることで、メソッドの外側(呼び出し元)での使い方はもっと簡単になりますし、圧縮元のデータを読み込む際に使うInputStreamは中で閉じているのに引数のOutputStreamは外で閉じるという複雑な状況は避けられます。再帰を無くす圧縮元のパスがディレクトリである場合は、さらにネストされたディレクトリやファイルもまとめて圧縮するために再帰を使うようになっています。再帰はアルゴリズムとしては重要ではあるものの、処理が全部終わるまでメモリに全データと処理を詰めておくので処理の効率という面ではあまりよくない場合もありますね。やりたいのは単純にhidden属性を持つファイルやディレクトリを除外すること、そしてそれ以外のファイルやディレクトリは全部ZipOutputStreamのエントリに入れたいという単純な事です。幸い、NIOを使うことでディレクトリの子要素を全部取得することができますし、取得した子要素はStream<Path>として取得できるので、filter()やforEach()のようなメソッドが使えます。これで十分、再帰を使わずに目的を達成できそうですね。完成したコード以上のことを反映し、修正したコードは以下の通りになります。object ZipService { fun archive(source: Path, target: Path): Unit = ZipOutputStream(Files.newOutputStream(target)).use { zos -> Files.walk(source) .filter { Files.isHidden(it).not() } .forEach { if (Files.isDirectory(it)) { zos.putNextEntry(ZipEntry("$it/")) zos.closeEntry() } else { zos.putNextEntry(ZipEntry(it.toString())) Files.copy(it, zos) } } }}簡単に説明しますと、objectとして宣言したSingletonクラスにおくことでどこでも活用できるユーティリティクラスにして、メソッドのシグニチャはより単純なものにしました。引数のsourceには圧縮元のファイルやディレクトリを、targetには圧縮先のZIPファイルを指定する事になっています。ZipOutputStreamはメソッドの中で生成して、use()を使って自動にクローズされるようにしています。まず優先的にFiles.walk()を使って子要素を全部取得するようにしています。取得した子要素はfilter()でhiddenでない場合を選別しているので、分岐は無くなりますね。また、子要素がディレクトリである場合ディレクトリ名であることを表すために/をつけてZipEntryを追加とクローズします。子要素がファイルの場合はZipEntryの追加とコンテンツのコピーを行います。これでより短く、単純なコードの出来上がりです。最後にKotlinらしいコードと述べましたが、上記のコードはあくまでKotlin/JVMでのみ有効ですね。なのでもしKotlin/NativeやKotlin/JSなどで使うには、別の方法を探す必要があるはずです。また、Files.walk()はJava 1.8から追加されたメソッドなので、1.7の場合はFiles.walkFileTree()を、その以前なら仕方なくNIOではない別の方法を使う必要があると思います。なので、Kotlin/JVM(Java 1.8以上)ではこれが最善なのかもしれませんが、また色々と研究の余地はありそうですね。こうやってJavaのAPIをKotlinの作法で切り替えていくのも、それなりに価値のあることではないかと思います。では、また！

KotlinでZIP圧縮してみる

こないだはGoに関するポストを作成しましたが、やはり本業はKotlinなので、Kotlinに関しても何かわかったことや閃いたことなどあれば、順次に書いていこうと思っています。今回はKotlinでAPIを作りながら、業務での要件をどんなコードで満たしたかを簡単に説明させていただきたいと思います。サーバサイドエンジニアをやっていると、要求される機能を以下に実現している方法がどんなものあれ(GraphQL、REST API、マイクロサービスみたいな技術やアーキテクチャの観点の以前の話として)、業務としてはある程度パターン化しているように感じることがあります。こういう場合には、コードよりもロジックが大事であるかのように見える場合もありますね。でも逆に、むしろ似たようなロジックが多いので、より良いコードを書くために工夫できる余地もまた多いのではないか、とも思います。正直自分はアルゴリズムに強いわけでもないので、効率的なコードを書くとしたら限界はあるだろうなという気はしています。とりあえず動くコードを書いて、それをリファクタリングしながら少しづつ整える感じのことしかできないのかもしれません。しかし、そんな自分にも良いコードを書くためにできることが全くないわけでもないと思います。例えば、Javaでコードを書くときは、参照の問題などからなるべくfinalをつけてオブジェクトをimmutableにするようにと教わりましたが、実際はベンチマークで比較した結果でもわかるように、性能の改善にも繋がっています。また、JavaでもKotlinでも色々と便利なAPIを提供していて、バージョンアップの度にまた新しいAPIが追加されるので、それらの用途と使い方をよく理解した上で、積極的に使用するだけでも読みやすく、性能も良いコードを書くことができます。ということで、今回はKotlinのAPIを使って書いていたコードを一部紹介したいと思います。リストのグループ化DBに商品情報テーブルがあって、さらに商品属性テーブル、生産地や販売店テーブルなどがある場合に、業務によっては「販売店ごとにどんな商品が販売されているかを確認したい」とか、「特定の商品属性に当てはまる商品だけみたい」とかのケースがあるはずですね。そういった場合、APIとしてはテーブルから取得したデータを、特定のカラムを基準にまとめたもの返す必要があります。これをコードに書くとしたらListで取得したデータを、中の一つの属性をキーにMapにまとめて返すということになりますね。Javaだと、以下のような形になるかと思います。// DBのデータの例List<User> list = List.of( new User("John", 20, "USA", "Programmer"), new User("James", 30, "Canada", "Sales"), new User("Jack", 35, "UK", "Programmer"));// UserのJobを基準にまとめるMap<String, List<Pair>> map = list.stream() .collect(Collectors.groupingBy(User::getJob, Collectors.mapping(user -> new Pair(user.getAge(), user.getName()), Collectors.toList())));// {James=[Pair(first=30, second=Sales)], John=[Pair(first=20, second=Programmer), Pair(first=35, second=Writer)]}@Data@AllArgsConstructorstatic class User { private String name; private int age; private String address; private String job;}@Data@AllArgsConstructorstatic class Pair { private Object first; private Object second;}KotlinでもJavaのAPIをそのまま使うことができるので、上記のStreamとCollectorを使って同じことはできます。ただ、せっかく違う言語と使っているわけなので、できればKotlinが提供するAPIを活用して同じことをしたいものです。KotlinはCollectionで提供する機能だけでもStreamとCollectorを組み合わせたものと似たような処理ができる場合が多いので、JavaのAPIに対応した機能があるかどうかを探すだけで事足りるケースが多いです。ということは、上記の処理でキモになっているCollectors.groupingBy()とCollectors.mapping()と似たようなものがあればいいというわけですが、groupBy()でそれらの処理をまとめることができます。なので、上記のコードをKotlinで変えると、以下のようになります。色々とスッキリしますね。// DBデータの例val list = listOf( User("John", 20, "USA", "Programmer"), User("James", 30, "Canada", "Sales"), User("Jack", 35, "UK", "Programmer") )// Jobを基準にMap<String, List<Pair<Int, String>>>にまとめるval map = list.groupBy({ it.job }, { it.age to it.name })// {Programmer=[(20, John), (35, Jack)], Sales=[(30, James)]}data class User( val name: String, val age: Int, val address: String, val job: String)Mapのvalueだけを変える上記の処理に加えて、もっと条件がつく場合もあるかと思います。例えば、金額計算とかの例があるとします。従業員が案件ごとに賃金をもらうということになっていて、案件はコードで管理されている場合、賃金を払う側としては同じ案件に対しては合算した金額のみが知りたいとかのケースもあるでしょう。こういう場合には、従業員ごとにデータをまとめた上で、さらにその人が担当した案件のリスト野中で重複するものがあれば、金額だけを合算するようにする必要がありますね。こういう場合は、グルーピングの段階からそういう処理を入れるのがもっとも効率的ではあるとは思いますが、スレッドの問題もあるので(生成中のMapの中を巡回するという)、実際のコードに書くとするとかなり複雑になる可能性もあります。なのでここではまず、ListをMapにまとめた結果を持ってさらに処理を加えるという形を取ります。KotlinのMapには、map()以外にもmapKeys()やmapValues()のような関数があって、必要な部分だけをマッピングできます。今回はvalueだけを変えたいので、mapValues()を使った方が無駄がなく、コードを読む側としても意図が明確になって良いと思います。mapValues()を使ってさらにマッピングを行うコードは、以下のようになります。data class User(val name: String, val id: Int, val amount: Int)// DBデータの例val list = listOf( User("A", 1, 1000), User("A", 1, 2000), User("A", 2, 4000), User("B", 3, 5000))// nameでまとめた後、重複するidを一つにまとめる(amountを合算)val map = list.groupBy({ it.name }, { it.id to it.amount }) .mapValues { // idでグルーピング it.value.groupBy { pair -> pair.first } // keyはそのまま、valueだけを合算する .map { map -> map.key to map.value.sumBy { pair -> pair.second } } }// {A=[(1, 3000), (2, 4000)], B=[(3, 5000)]}ListをMapにまとめるもう一つの方法は、groupingBy()があります。この関数を使うと、CollectionがGroupingというオブジェクトに変わって、aggregate()・reduce()・fold()・eachCount()のような関数を使うことで後続の処理ができます。上記のコードをGroupingを使ったものに変えるとしたら、以下のようになります。// Groupingのaggregateを利用してMapに変えた後から、valueの処理を行うval map = list.groupingBy { it.name } .aggregate { _, accumulator: MutableList<Pair<Int, Int>>?, element, first -> // 新しいキーなら、MutableListを作る if (first) mutableListOf(element.id to element.amount) // そうではない場合は、存在するListに要素を追加する else accumulator?.apply { add(element.id to element.amount) } }.mapValues { it.value?.groupBy { pair -> pair.first } ?.map { pair -> pair.key to pair.value.sumBy { pair -> pair.second } } }一見、groupingBy()の方が複雑にも見えますが、accumulatorを使ってマッピングした値を積み重ねることができるので、場合によっては考慮する価値があるかもですね。Mapを使ったキャッシュDBの参照が頻繁であり、なお参照されるデータそのものは更新される頻度が高くない場合は、アプリケーション内にキャッシュして置くのが良いケースもたまにありますね。こういう場合には、パラメータをキーとして持つMapを宣言しておいて、そのキーがない場合だけDBにアクセスする(そしてMapに追加する)という形にすれば良いでしょう。Javaでは1.8からcomputeIfAbsent()というメソッドを提供しているので、簡単に実装ができます。例えば以下のようになります。// DBデータの例List<String> list = List.of("A", "B", "C");// キャッシュのMapMap<String, Boolean> map = new ConcurrentHashMap<>();// パラメータString element = "A";// キャッシュにパラメータがない場合はDBデータを参照して、追加した後に返すBoolean exists = map.computeIfAbsent(element, key -> list.contains(element));// Method Referenceを使った例exists = map.computeIfAbsent(element, list::contains);Javaで提供する機能なので、もちろんKotlinでも全く同じ形で実装できます。ただ、Kotlinの仕様上computeのコードがLambdaかMethod Referenceかによって書き方が違うので、そこだけ注意する必要があります。これはKotlin自体の仕様によるものですが、Javaの書き方に慣れていると最初はなかなかわかりにくいところかもしれません。// DBデータの例val list = listOf("A", "B", "C")// キャッシュのMapval map = ConcurrentHashMap<String, Boolean>()// パラメータval element = "A"// Lambdaの場合var exists = map.computeIfAbsent(element) { list.contains(element) } // false// Method Referenceの場合exists = map.computeIfAbsent(element, list::contains)ちなみに、似たような機能をするメソッドとしてputIfAbsent()がありますが、computIfAbsent()の場合Mapにキーがなかった場合にだけ後続の処理が行われるに対して、putIfAbsent()はキーがあるかないかに関係なく処理が走ってしまうという違いがあるらしいです。なのでキャッシュとして使う場合は、computeIfAbsent()を使った方が良いでしょう。最後に自分が書いたコードをいくつか紹介しましたが、いかがだったでしょうか。まだKotlinに移行したばかりなので色々とわからないことが多く、本当はもっとスマートな方法があるのかもしれませんが、自分的には、こうやって実際の業務の要件に合わせて違う言語とコードを比べながら、APIのソースをみたりで自分なりにどうやって書くかを考えてみるのは意味のあることで、楽しいとも思います。というわけで、これからもKotlinでの書き方に対する研究はこれからも続きます。そろそろGoでも簡単なAPIでも作ってみたりで勉強をしないとやばそうな気もしていますが…まぁ、なんとかなるでしょう。では、また！

Kotlinで書いてみた〜その一〜

このブログのポストとしてはいきなりですが、転職してからは仕事の都合上Goも少し触ることとなりました。以前からGoかRustに触れてみたいなとは思っていたのものの、いざ全く触れてみたことのない言語で書かれてあるアプリを修正するようなことになると少し怖くもなります。なので、少しでもGoのことを知っておくべきではありますね。というわけで、今回はGoに少し触れてみて感じたことを、Javaプログラマーの観点から述べてみたいと思います。Goの特徴は、色々とあると思いますが、正直GCがあって、VMがない言語だという特徴は、実際はあまり肌で感じる違いではないです。VMがないから、ある言語よりは早いだろうなというとしか言えませんね。実際その言語を持ってコードを書くという仕事をしている身からしては、そのような特徴よりも、コードを書く場面で気にしなければならないことの方に注目したいものです。まずは自分が今まで触れてきた言語とはどう違うかですね。例えば、ループや条件などを書くときはどうなのか、今までの習慣通りコードを書いても問題ないだろうか、注意すべきところは何かなど。今回はそのような観点から本当の少しだけGoに触れてみた感想を書いていきたいと思います。考え方を変える必要があるかもGoに少し触れてみて考えたことは、もっとも基本的な部分でもJavaを書くときとはかなり違うアプローチが必要ではないかということでした。私の場合はJava意外にPython、JavaScript、TypeScript、Kotlinに触れてみたことがあるのですが、JavaScriptやTypeScriptはJavaの書き方とそう変わらない感覚で書くことができて、Kotlinも基本はJavaを簡略化した感覚でコードが書けます。Pythonがかなり違うのですが、どちらかというと書きたいコードを文法の制約なしで書けるという感覚に近いので、文法の差が気にならないものでした。しかし、Goの場合は少しわけが違います。Javaと比べ、書き方が少し違うだけでなく、機能レベルで違いがあるからです。機能レベルで違うということは、単純にJavaのコードを少し変更したくらいのコードを書くことはあまりよくないということになると思います。なので、そもそもの考え方を変える必要があるのではないかと思いました。そういう観点から感じたGoの印象は、以下の通りです。似ているようで、似ていないまず目立つのは、文法です。もちろん、大枠はいわゆるCファミリープログラミング言語とそう変わらないですが、Javaと比較すると文法の構造以外の部分でかなり変わった部分があります。例えば、Walrus Operatorとも呼ばれるPythonの代入式に似たような表現があったり、if文の条件式を括弧なしで書けたり、importを文字列で書いたり、クラスやpublic・privateのようなキーワードが無かったりの違いがあるので、コードを書くときの感覚が違うだけでなく、パッケージ構造やアプリケーションのアーキテクチャ設計のレベルで今まで自分が経験していたJavaやKotlinとは違うアプローチが必要ではないかと思えるくらいです。色々と違う点を述べましたが、単純にコードを持って比較してみましょう。例えば、以下のようなコードがあるとしましょう。数字に関する計算を担当するクラスがあって、中には渡された引数が奇数か偶数かを判別して、結果を標準出力する形です。package simple.math;public Class Calculator { public void judge(int number) { boolean result = number %2 == 0; if (result) { System.out.println(number + "は偶数です"); } else { System.out.println(number + "は奇数です"); } }}これをGoのコードに変えてみます。例えば以下のようになると思います。package simple.mathimport "fmt"func Judge(number int) { condition := number % 2 == 0 if condition { fmt.Println(number, "は偶数です") } else { fmt.Println(number,"は奇数です") }}一見あまり変わらないように見えるかもしれませんが、細かいところが違うので注意しなければならないところがあります。いくらIDEの性能がよくなったとはいえ、その言語の仕様と全く違うようなコードを書いてしまっては、正しいコードを提示してくれませんので。例えばインポートは複数になると、以下のようになりますね。import ( "fmt" "math")Pythonの場合も一行でimportをまとめたり、fromとasでAliasを指定するようなことができたりもします。しかし、Goで根本的に違うのは、GoそのものがMavenやGradleのようなパッケージ管理もできるので、インポートにgithubのパッケージを描くこともできるということです。例えば以下のようなコードで、GoのウェブフレームワークであるGinをインポートすることができます。import "github.com/gin-gonic/gin"また、変数を:=を使って宣言する場合は、関数内でのみ可能であるので、パッケージレベルで宣言する場合は普通にvarを使う必要があるという仕様も理解する必要があったりします。そしてそれに対して、関数の引数としてはvar宣言がいらなく、型を宣言する必要があります。どんな場合でも(初期化とともにvarを使うことは最近のJavaでも可能になりましたが)変数の型を書く必要のあるJavaとは大きく違うところですね。こういう細かい違いがあるので、Goの作法に対する理解なしでJavaの感覚のままコードを書くのは大変なことになるかもしれません。大文字には機能がある会社ごとにルールは違うかと思いますが、今までの自分が経験では、言語がJavaであれJavaScriptであれ以下のようなルールで書く場合が多かったです。クラス、インタフェース名はPascalCaseフィールド、メソッド、変数、引数はcamelCaseたまにPythonでコードを書く場合はsnake_caseだったり、URLはkebab-caseだったりもしたのですが、プライベートでも多くの場合このルールに従ってコードを書いています。そしてこれはあくまで人間が定めたルールなので、守らなくてもしかし、GoではPascalCaseかcamelCaseかによって意味が変わる部分があります。正確には頭が大文字か小文字かによる違いですね。publicとprivateの代わりになってくるのが、この仕様です。簡単に説明すると、他のパッケージからも参照できるのは大文字から始まるフィールドや関数であり、そうでない場合は小文字から始まるものということです。例えば以下をみてください。A Tour of Goで提示しているコードです。ここではmathパッケージをインポートして、あらかじめ定義されてあるπを標準出力している例です。package mainimport ( "fmt" "math")func main() { fmt.Println(math.pi)}上記のコードは、なんの問題もないかのように見えますが、実行すると以下のようなエラーメッセージが出力されます。./prog.go:9:14: cannot refer to unexported name math.piこれはつまり、外部から参照できないということですね。なので、正しいコードに変えるとmain関数を以下のように直す必要があります。func main() { fmt.Println(math.Pi)}先端が大文字であり、外部から参照できるように定義された名前のことをExported Namesというらしいです。Goにはクラスがないので、パッケージをインポートして、そのパッケージ内に存在する.goファイルの中にExport Namesで定義された項目のみを参照することになります。なのでクラスを作って、そのクラスのインスタンスを生成し、小文字から始まるフィールドやメソッドを呼ぶというJavaの作法とは感覚が大きく違いますね。ポインターの存在プログラマーだと誰もが知っていることだと思いますが、ポインターがあるかどうかの問題は、コードを各感覚にかなりの影響を与えるようなものです。JavaやKotlinなど、ポインターがない言語ではクラスやメソッド間にただ、GoにはGCがあるので、CやC++のようなメモリー問題はないかとも思いますが、とにかく直接使ってみないとわからないところですね。もちろん、Javaでもpublic staticで宣言したり、SpringだとAutowiredアノテーションをつけることでどこでもアクセスできるオブジェクトを作ることは可能です。Kotlinだとcompanion objectという、クラスに似たようなものをまず定義する必要がありますが、呼び出し元としてはJavaとあまり変わらないコードになりますね。しかし、こう言ったstaticなものは、JavaやKotlinだと定数として使われるのが一般的です。AutowiredでもSingletoneと使い方はあまり変わらず、固定値を格納するか、常に同じ動作(冪等に違い)をすることを期待するのが一般的ですね。それに比べ、ポインターはやはりその値を直接書き換えたりすることを期待する場合もあるので、やはり違うものです。まだ私はポインターを本格的に扱う言語に触れてみたことがなく、Goでもポインターを活用するようなコードは書いたことがあまりないので、ここで言えるのは上記で述べた内容だけですが、私と同じくポインターのない言語の経験しかない方にはやはり慣れるまで時間がかかるのではないかと思います。試行錯誤もかなりありそうですね。例外処理が独特Goで書かれてあるコードをみて、何が一番目立つかというと、例外処理の部分ではないかと思います。私が経験したことのある言語(Java、Python、JavaScript、TypeScript、Kotlin)では、例外処理のためにtry-catchブロックという仕様がありました。言語ごとに少しづつ違うところはありましたが、基本的に例外が発生しうる場所をそのブロックで囲んでから処理する、という発想自体は変わりがありません。例えば以下のようなコードで例外を処理することが一般的でしょう。public static void main(String[] args) { int result = 0; try { result = divide(1, 0); } catch (Exception e) { if (e instanceof ArithmeticException) { System.out.println("0で分けません"); return; } } System.out.println(result);}private static int divide(int numerator, int denominator) { return numerator / denominator;}しかし、Goではそのような機能はありません。代わりに、どんな関数でも戻り値として期待する値と発生したエラーを定義し、呼び出し元では関数の実行結果としてエラーが発生したを確認して、エラーが発生していたら(エラーがnilではない場合)にそのエラーの対応をする、ということが一般的な作法のようです。言葉で説明すると難しいので、実際のコードをみていきましょう。上記のコードをGoの作法に合わせて書き直すと、以下のようになります。func main() { result, err := divide(1, 0) if err != nil { fmt.Println(err) return } fmt.Println(result)}func divide(numerator int32, denominator int32) (int32, error) { if (denominator != 0) { return numerator / denominator, nil } else { return 0, errors.New("0で分けません") }}このように、関数ではエラーが発生した場合にそれをそのまま返し(上記のコードでは、あえてエラーを作っていますが)、呼び出し元ではエラーがあったかどうかを確認して分岐します。こうすることで「エラーが発生した場所が明確になる」メリットがあるらしいです。確かに、try-catchブロックが囲んでいるコードが多ければ多いほど、例外が発生し得るコードがどれなのかわからなくなる場合もありますね。例外を処理するための機能が、例外を起こさないコードと混り、わけがわからなくなります。そういう観点からすると、Goのアプローチはエラーとロジックを分離できるというメリットがあると言えるでしょう。ただ、Goの作法では関数を呼び出す度に後続でエラーチェックが入るので、毎回同じ様なコードを書く場合があるのは少し違和感があります。例えば以下のようなコードを見かけるのですが、皆さんはどう思われるのでしょうか。もっとスマートな方法があって、自分が知らないだけなのかもしれませんが…// いくつかの関数を呼び出して処理をする関数func doSomething() (string, error) { // 関数1を呼び出す result1, err1 := someFunction1() // 関数1でエラーが発生した場合はエラーを返却する if err1 != nil { return "", err } // 関数1でエラーが発生していない場合は関数2を呼び出す result2, err2 := someFunction2(result1) // 関数2でエラーが発生した場合はエラーを返却する if err2 != nil { return "", err } // 関数2でエラーが発生していない場合は関数2を呼び出す result3, err3 := someFunction3(result2) // 関数3でエラーが発生した場合はエラーを返却する if err3 != nil { return "", err } // 関数3でエラーが発生していない場合は関数2を呼び出す result4, err4 := someFunction4(result3) // 関数4でエラーが発生した場合はエラーを返却する if err4 != nil { return "", err } // ...続く}コンパイラーが厳しいコンパイルエラーが発生した場合はIDEで知らせてくれるので気にすることはあまりないかと思いがちですが、意外と気になるのはコンパイラーの厳しさです。個人的にはjShellの様なインタラクティブツールを使ってよくコードの検証をするのですが、GoにはそれがないのでVimで書いたコードをターミナルで動かしてみたり、The Go Playgroundを使ってみています。そしてこういう方法ではIDEの様なサポートをあまり期待できませんので、コンバイルエラーになることが多かったです。ただ、コンパイルエラーといっても色々な原因がありますが、Goは特に他の言語と比べてもかなり厳しいのではないかと思います。例えば以下の様なコードがあるとします。package mainimport ( "fmt")func main() {}ターミナルやThe Go Playgroundでこれを実行すると、以下の様なエラーメッセージが出ます。./prog.go:4:2: imported and not used: "fmt"インポートしたパッケージが使われていないというエラーですね。さらに、以下の様なコードを実行したとします。package mainimport ( "fmt")func main() { var result string fmt.Println("this is test program")}上記のコードを実行した結果は、以下の通りです。./prog.go:8:9: result declared but not used今回はresultという変数が使われてないというエラーです。この様に、Goでは使われてないインポートや変数などがあればエラーとなるので、他の言語と比べ厳しい方と言えますね。なので、プラグインなしのVimを使って修正するなどの場合には十分に気をつける必要がありますね。IDEでも少しはめんどくさいかもしれません。(リンティングと同時に使われてないパッケージや変数を削除してくれるとかの設定をすれば良いかもですが)最後に他にも細かい違いはまだまだ山ほどありますが、今の時点で言えるものはこのくらいです。ここで述べた、Javaプログラマーの観点からみたGoの特徴というものは、実は「慣れれば問題ない」だけなのかもしれません。しかし、「慣れる」ということは、「すでに慣れている」ものがあったらまたなかなか難しいものにもなりますね。例えば、人間の言語でいうと、同じ系列のドイツ語の話者が英語を学ぶのは簡単と言われていますが、それは二つの言語がよく似ているからですね。逆に英語が母国語である人には中国語・日本語のような言語がもっとも難しい言語らしいのですが、これは語彙、文字、文章構造の全てが違うのが原因だそうです。プログラミング言語も本質は人間の言語を模倣しているものなので、新しい言語を学ぶ際には、それが自分の母国語と言える言語と似ていれば似ているほど学びやすく、そうでない場合は難しく感じるものではないかと思います。そういう観点からすると、JavaからGoへの移行は、簡単そうで難しそうな側面があるかなという気がします。もちろん、世の中には元Javaプログラマーでも、Goの方が簡単だった！という方もたくさんいらっしゃるかと思います。ただ自分がついていけないだけなのかも…ですが。

JavaプログラマーがみたGo

この度は、転職することとなり、仕事で使われる言語もJavaからKotlinに変わることになりました。個人的にKotlinで簡単なSpring WebFluxプロジェクトを作ってみたことはあり、もともとJavaプログラマがKotlinへ移行するのは難しいことではないと言われてはいるものの、やはり仕事で使われる言語が変わるというのはかなりのチャレンジではあると思います。なので、今まではJavaに関してのポストを主に載せていたのですが、これからはKotlinに関してのポストを増やしていきたいと思います。まず、よく知られているように、KotlinはJavaと完璧な互換性を持つものです。それはJVM言語であり、コンパイルしたらJavaと同じくバイトコードになるからですね。ただ、だからと言って「Javaの感覚で」コードを書くということは、Kotlinという「違う言語」に移行する意味を無くす行為な気がします。なぜなら、Kotlinは触れば触るほどJavaとは根本的に違う考え方で設計されている言語だということが伝わってくるからです。最初はJavaの冗長さ(Verbose)を減らすことが第一の目標ではないかという印象を受けましたが、本格的に勉強を始めるとそれだけではないような気がしているのです。今回のポストは、CourseraのKotlin for Java Developersの講義の内容に基づいて作成されました。冗長さを減らすということJavaは今でも良い言語であり、多くの言語が発表されエンタープライズレベルで使われるようになった今でも、幅広い分野で使われていますね。Javaが依然としてよく使われる言語であることは、TIOBE indexやJetBrainsのThe State of Developer Ecosystem、StackoverflowのDeveloper Surveyからも読み取れることです。ただ、Javaが依然として人気の言語だとしても、それは圧倒的にJavaが他の言語に比べ優秀だとか、使いやすい言語であるという意味ではないでしょう。どの言語でもそうであると思いますが、Javaでよく指摘されている問題の一つは、「冗長すぎる」というところです。数多くのライブラリがあり、MavenやGradleのような優秀なビルドツールを使えながらも、やはり言語の仕様は変わってないですからね。Java 9からはこの問題を解消するため、他の言語から影響を受けたような機能を多く導入していますが(例えば、instanceofのパターンマッチングやrecordなど)、言語そのものの設計思想が変わるというよりは「違う言語の特徴をJavaに合わせた仕様で導入する」ことに近いので、根本的な変化とは言えないものです。なので今まで書かれている冗長なコードは残るもので、またこれからも使われることになるはずです。コードが短くなる冗長さを減らすということは、簡単にいうと「より短いコードで、同じ結果を得る」と定義できるでしょう。そういう観点からすると、KotlinはJavaの冗長さを減らすために工夫した痕跡が言語の仕様から感じ取れるようなものです。例えば以下のようなコードがあるとしましょう。public void updateWeather(int degrees) { String description; Color color; if (degrees < 10) { description = "cold"; color = BLUE; } else if (degrees < 25) { description = "mild"; color = ORANGE; } else { description = "hot"; color = RED; }}これをKotlinで書き換えると、以下のようになります。fun updateWeather(degrees: Int) { val (description, color) = if (degrees < 10) { Pair("cold", BLUE) } else if (degrees < 25) { Pair("mild", ORANGE) } else { Pair("hot", RED) }}まず二つの変数を、戻り値がPairのオブジェクトの表現式でより短くできることがわかります。そしてこのコードは、when句を使ってより短い形で変えることもできます。その結果が以下です。fun updateWeather(degrees: Int) { val (description, color) = when { degrees < 10 -> Pair("cold", BLUE) degrees < 25 -> Pair("mild", ORANGE) else -> Pair("hot", RED) }}さらにPairは、toを使うことでもっと簡単に表現することもできます。そうすると、以下のようなコードになります。fun updateWeather(degrees: Int) { val (description, color) = when { degrees < 10 -> "cold" to BLUE degrees < 25 -> "mild" to ORANGE else -> "hot" to RED }}最初のJavaのコードと比べ、かなり簡単かつ明瞭なコードになっているのがわかります。他の言語を使っていた人だとしても、一瞬ですぐに何をしているのかがわかって、より短く効率なコードになっているのがわかりますね。こういうところこそ、KotlinがJavaの冗長さ−無駄を減らすことに力を入れている部分ではないかと思います。コードを簡単に書ける自分は最初、Kotlinの文法を簡単にみながらswitchがここではwhenに変わって、caseを書く必要がないんだな、くらいの印象しか受けてなかったです。しかし、よくよく見ると、他にもJavaと違うところが良く見えます。ここで読み取れるものは、例えばさっきのコードだと以下がありますね。when句が表現式として使えるwhen句の条件の対象は条件式の中のみで良い表現式の中で複数の値を戻り値として定義し、それをtoで二つのオブジェクトをPairにまとめることができる他にも、Javaのswitchに比べKotlinのwhen句は以下のよう活用ができるというところもあります。オブジェクトの比較がより簡単ですね。例えば以下のようなコードで、簡単に二つのオブジェクトに対しても比較が可能になります。fun mix(c1: Color, c2: Color) = when (setOf(c1, c2)) { setOf(RED, YELLOW) -> ORANGE setOf(YELLOW, BLUE) -> GREEN setOf(BLUE, VIOLET) -> INDIGO else -> throw Exception("Dirty Color") }これをあえてJavaのコードで書くとしたら、おそらく以下のようになるでしょう。個人的に、たくさんのelse ifはあまり読みやすいコードではなく、書く立場としても綺麗ではないと思います。private Color mix(Color c1, Color c2) { if (c1 == Color.RED && c2 == Color.YELLOW) { return Color.ORANGE; } else if (c1 == Color.YELLOW && c2 == Color.BLUE) { return Color.GREEN; } else if (c1 == Color.BLUE && c2 == Color.VIOLET) { return Color.INDIGO; } else { throw new RuntimeException("Dirty Color"); }}ここでわかるのは、KotlinではJavaと同じことをするとしても、短いだけでなく、より簡単にコードをかけるということですね。もちろん、別のメソッドを作ったり、Comparableなオブジェクトを作ったり、Comparatorクラスを実装することでJavaでも似たようなことはできるかもしれません。しかし、そこまでしたいかというと微妙ですね。もちろん、Java 12からはKotlinのwhenに近い感覚でコードを書くこともできるようになっています。表現式としても使えて、複数の条件を指定することができ、Lambdaの感覚で書けるということも良いですね。var result = switch (month) { case JANUARY, JUNE, JULY -> 3; case FEBRUARY, SEPTEMBER, OCTOBER, NOVEMBER, DECEMBER -> 1; case MARCH, MAY, APRIL, AUGUST -> { int monthLength = month.toString().length(); yield monthLength * 4; } default -> 0;};このような変化を見ると、この「冗長さを減らす」という面では、Javaもまたバージョンアップとともに新機能を次々と導入してきているので、Kotlinの魅力が半減しているように見えるかもしれません。しかし、Kotlinではもっと重要なポイントがまた一つあります。言語自体の拡張性です。拡張ができるということ言語自体の拡張性と言いましたが、簡単にいうと、以前にも紹介したことのある拡張関数、つまりextensionのことです。Kotlinの仕様としてもこれは大きい部分として紹介されているものですね。これをよく使うと、ただ「継承しなくてもそのクラスにメソッドを追加できる」だけでなく、infixと組み合わせることでまるで予約後であるように使うことができます。実際、Kotlin for Java Developersのコーディング問題では、infixで書かれた以下の拡張関数を持って結果の確認を行っていると言われています。infix fun <T> T.eq(other: T) { if (this == other) println("OK") else println("Error: $this != $other")}このinfixを使うと、以下のようなコードが書けるようになります。"ABC" eq "ABC"このような特徴があるということは、使う側からしても便利ですが、これから言語そのもののバージョンアップにしたがってより便利な機能が追加され安いことにもなっていると思います。例えば先ほどのPairオブジェクトを作るtoが、このようにinfix関数として作られているものです。これからもこういった便利な機能が追加され、追加しやすくなるのは確かに開発のコストの削減をという面でも良いことですね。もう十分便利であること冗長さを減らし、拡張性がある言語だという特徴は、おそらくKotlinを作っているJetBrainsにとっても十分有効な特徴であるかと思います。Kotlinのスタンダードライブラリを見ると、すでに便利な関数が多く存在しています。例えば、簡単なループでは以下のようなことができます。val list = listOf("A", "B", "C")// 一般的なfor文for (element in list) { println(element)}// インデックスを含むfor文for ((index, element) in list.withIndex()) { println("$index: $element")}// インデックスのみのfor文for (index in list.indices) { println(index)}以前もJavaのfor文の性能についてのポストで簡単に述べたことがありますが、そこではJavaならインデックスが必要な場合は伝統的なfor文を使い、そうではない場合は一般的に拡張for文を使った方がいいという結論をJMHでのベンチマークで出していました。しかし、こうやってすでに言語から便利な方法を提供していると、性能を気にすることなく便利な方法を取れるという面でも魅力的です。そして、forEachでもインデックスが必要であるなら、forEachIndexedを使えるという良い点もあります。例えば、以下のような書き方ができます。// 一般的なforEach文list.forEach(::println)// インデックスを含むforEach文list.forEachIndexed { index, element -> println("$index: $element") }インデックスを簡単に取得できるということは、ループ対象のオブジェクトが持つ全インデックスを取得したい場合に、あえて0のような、マジックナンバーにありえる数値を指定する必要がないというところでも良いですね。Javaだと毎回、static finalなフィールドとして宣言したり、別の定数として管理したりするケースが多いので…他にも、正規表現なしでも文字に関して簡単にチェックできる関数が事前に提供されているとか(Char.isLetter()やChar.isDigit()など)、MapにはPairで要素を入れることができるとか、iterableなオブジェクトからStream APIのような操作がすぐできるなど、確かにJavaに比べ「悩む必要がない」のが魅力的と思います。まぁ、人によってはこれはデメリットと認識する可能性もあるのでは、といは思いますが…最後に色々とKotlinの特徴・メリットについて述べましたが、こういう自分もまだ実際に業務でKotlinを使っているわけではないので、まだまだ表面的な知識のみに止まっていると思います。しかし、ここで紹介したことだけでも、Kotlinの魅力は感じ取れるのではないかと思います。言語自体も魅力的なのですが、他にもKotlinを扱うことで得られるメリットは多いです。例えば、JetBrainsが開発しているので、Intellijとの相性が良いこと。JVM言語でありJavaとの互換性があるので、Javaの発展をそのまま吸収できるということ。NativeやJavaScriptへのコンパイルもできるということ。他の言語も十分魅力的なポイントはありますが、Javaプログラマーであるなら、一度Kotlinに触れてみる価値はあると信じています。皆さんもまだKotlinに触れたことがないのであれば、この度ぜひ軽い気持ちで挑戦してみてください。では、また！

JavaプログラマーがみたKotlin〜その二〜

今更な文字列操作の話

個人的な2021年のロードマップ

今更なI/Oの話

仕事ではJava 11を扱うことが多いのですが、正直、自分の書いたコードを振り返ってみると、Java 9から新しく追加されたメソッドはあまり使ってないのが現実です。しかし、これら新しいメソッドたちは冗長さを隠してくれるシンタックスシュガーとして存在するだけでなく、性能や機能面でより優れているものもあるので、いますぐ使わないとしても目は通しておきたいものが多いなと思っています。2021年は次のLTSバージョンとなる17の登場が予告されている時点なので、今更な感はありますが、そろそろ私もSEになってから2年になるので、今回は今年、自分が書いたコードへの反省を含め、Java 9〜11まで新しく追加されたメソッドたちの中から、良さそうな(よく使えそうな)ものを選別してみました。そして今回のポストは、そう選別したメソッドの簡単な紹介となります。多くの場合、これらのメソッドを使える環境だとしたらJava 11を導入しているはずなのであまり意味はないのかもしれませんが、それぞれのメソッド名の右に、該当メソッドがどのバージョンから導入されたかを記入していますので参考にしてください。StreamStreamこそJava 8のキモではないかと思います。そしてJava 9では、そのStreamの問題を色々と改善したり、より簡単に使えるようなメソッドを用意しています。なので、既存のforループにしか慣れてない人でも、簡単に入門できるようになったのではないかと思います。Iterate (9)iterate()というメソッド名だけではすぐに意味がわからない場合もあると思いますが、このメソッドは伝統的なFor文と同じような構文でStreamでの処理を書くことができるようになります。つまり、「初期化・ループの継続条件・カウンタ変数の更新」を書くことで、Streaｍの要素数を決めることができるという意味です。例えば、以下のような書き方ができます。// 0~9までを出力Stream.iterate(0, i -> i < 10, i -> i + 1).forEach(System.out::println);これはつまり、以下のコードと同じ意味を持ちます。for (int i = 0; i < 10; i++) { System.out.println(i);}ただ、iterate()で指定できる初期化の値が数字という制限はないので(Tです)、以下のようなこともできます。// Aで三角形を出力Stream.iterate("A", s -> s.length() < 10, s -> s + "A").forEach(System.out::println);また、ループの継続条件を指定しないこともできます。// Aで三角形を出力Stream.iterate("A", s -> s + "A").forEach(System.out::println);継続条件を指定しないと、無限ループになってしまうのでは？と思われそうですね。確かにそうですが、同じくJava 9でStreamの要素数の上限を指定できる新しいメソッドが追加されています。次に紹介するものがそれです。takeWhile (9)以前、Streamの問題として「途中でやめられない」と書きましたが、Java 9から導入されたtakeWhile()メソッドを使うと、途中で処理を終了するようなことができるようになりました。既存にあったlimit()の場合は、「指定された回数分」という限界がありましたが、こちらはPredicate型の条件を指定できるというところが違います。// AAAAAAAAAまで出力するStream.iterate("A", s -> s + "A") .takeWhile(s -> s.length() < 10) .forEach(System.out::println);なので、iterate()の継続条件を書いてない場合にはtakeWhile()を使ってどの条件で処理が終わるかを明示した方が良いですね。dropWhile (9)dropWhile()は、その名からも推測できますが、takeWhile()と真逆の機能をするメソッドです。このメソッドはStreamから与えられた条件と一致する要素を除いて、残りの要素を返却します。// AAAAAから出力するStream.iterate("A", s -> s.length() < 10, s -> s + "A") .dropWhile(s -> !s.contains("AAAAA")) .forEach(System.out::println);ofNullable (9)Java 1.8のStreamでは、Null要素を追加するためにはまずその要素がNullかどうかをチェックして、Nullの場合にStream.empty()を呼ぶような形にする必要がありました。いつものJavaのNullチェックですね。例えば以下のようなものです。// 要素のNullチェックを含むStreamのCollectkeyList.stream() .flatMap(k -> { Object value = map.get(k); return value != null ? Stream.of(value) : Stream.empty(); }) .collect(Collectors.toList());これを、Java 9ではより簡単なコードで書くことができます。OptionalのofNullable()とあまり変わらない感覚ですね。keyList.stream() .flatMap(k -> Stream.ofNullable(map.get(k))) .collect(Collectors.toList());CollectorsStreamの要素を集約するためのCollectorを提供するCollectors APIですが、こちらの変化は主にシンタックスシュガーなものが多い印象です。主にStreamでしかできなかったことや、既存のCollectorsのみだとかなり長くなるコードを簡潔に書くことができるようになっています。filtering (9)Streamのfilter()と同じ処理を、Collectorでもできるようになりました。どちらを使うかは好みの問題な気がしますが、Collectorそのものを共通化するなどの処理ができそうな気はしますね。// 0~9までのリストList<Integer> numbers = Stream.iterate(0, i -> i < 10, i -> i + 1).collect(Collectors.toList());// Stream.filter()numbers.stream() .filter(e -> e > 5) .collect(Collectors.toList()); // 6, 7, 8, 9// Collectors.filtering()numbers.stream() .collect(Collectors.filtering(e -> e > 5, Collectors.toList())); // 6, 7, 8, 9flatMapping (9)これもまた名前から推測できると思いますが、CollectorsでCollectionに変えるとき、要素のflatMappingをできるようにしてくれるようなものです。具体的には、以下のサンプルコードを参照してください。例えば、以下のようなクラスがあるとします。public class Selling { String clientName; List<Product> products;}public class Product { String name; int value;}そして、このSellingのリストを、「clientNameをKeyに、productsをValueにしたMapにしたい」場合はどうしたら良いでしょうか。例えば以下のような方法を考えられます。Map<String, List<List<Product>>> result = operations.stream() .collect(Collectors.groupingBy(Selling::getClientName, Collectors.mapping(Selling::getProducts, Collectors.toList())));しかし、問題は、List<Product>をさらにListの中に入れてしまうことになります。これは本来の目的ともズレていて、無駄な処理が発生し、Valueを持ち出すときも不便なはずです。これをMap<String, List<Product>>の形に変えるとしたら、以下のような方法が使えます。自作のCollectorを作るのですね。Map<String, List<Product>> result = operations.stream() .collect(Collectors.groupingBy(Selling::getClientName, Collectors.mapping(Selling::getProducts, Collector.of(ArrayList::new, List::addAll, (x, y) -> { x.addAll(y); return x; }))));ただ、毎回このような自作Collectorを作るというのはあまり効率的ではない方法ではないかと思います。それに、自作のCollectorを普段から使ってない場合はコードだけみても少しわかりづらくもありますね。なので、ここは新しく追加されたflatMapping()で変えてみると以下のようになります。より簡潔ですね。Map<String, List<Product>> result = operations.stream() .collect(Collectors.groupingBy(Selling::getClientName, Collectors.flatMapping(selling -> selling.getProducts().stream(), Collectors.toList())));toUnmodifiable (10)Java 10ではCollectorsに以下の三つのメソッドが追加されています。toUnmodifiableList()toUnmodifiableSet()toUnmodifiableMap()これらのメソッドを使うと、既存のCollectionsを呼ぶ必要なく、簡単に(もっと短いコードで)UnmodifiableなCollectionを作ることができます。// Collections.unmodifiableListList<Integer> collectionsUnmodifiable = Collections.unmodifiableList(Stream.iterate(0, i -> i < 10, i -> i + 1).collect(Collectors.toList()));// Collectors.toUnmodifiableListList<Integer> collectionsUnmodifiable = Stream.iterate(0, i -> i < 10, i -> i + 1).collect(Collectors.toUnmodifiableList());引数は、既存のtoList()・toSet()・toMap()と同じなので(toMap()だけ、KeyとValueのマッピングを指定する必要がありますね)、既存のメソッドと同じ感覚で使うことができます。CollectionsCollections APIの新しいメソッドは、かなり現代的な書き方を可能にします。Kotlinのような言語がJavaの冗長さを回避するための工夫をしているのであれば、Java側に新しく追加されたメソッドはそれをさらにJavaに似合うような形で受け入れたような印象です。(というか、それしか方法はなかったかもしれませんが…)Factory Method (9)Java 9では、ファクトリーメソッドでCollectionの作成ができるようになりました。使い方としては、既存のArrays.asList()と似ているような感覚です。// Listの作成List<String> list = List.of("A", "B", "C");// Setの作成Set<Integer> set = Set.of(1, 2, 3);Mapの場合は、KeyとValueを順番に並ぶことでインスタンスを作成できますが、エントリーを定義することもできます。// KeyとValueのセットで定義するMap<String, String> map = Map.of("foo", "a", "bar", "b", "baz", "c");// エントリーを定義するMap<String, String> map = Map.ofEntries( Map.entry("foo", "a"), Map.entry("bar", "b"), Map.entry("baz", "c"));これらのファクトリーメソッドで作成したCollectionの特徴は、最初からUnmodifiableなオブジェクトになるということです。なので、例えばアプリケーションの起動時にフィールドに定数をCollectionとして定義する、という場合に使えます。つまり、以下のような既存のコードを代替できるようなものです。// もっとも基本的な方式Set<String> set = new HashSet<>();set.add("foo");set.add("bar");set.add("baz");set = Collections.unmodifiableSet(set);// Double-brace initialization Set<String> set = Collections.unmodifiableSet(new HashSet<String>() { { add("foo"); add("bar"); add("baz"); }});また、このファクトリーメソッドで作ったCollectionは以下のような特徴を持ちますので、必要に応じて使うのが大事ですね。Immutable(Unmodifiable)になるNull要素を指定できない要素がSerializableだとCollectionもSerializableになるcopyOf (10)List, Set, MapにcopyOf()というメソッドが追加されています。引数にそれぞれのCollectionを渡すと、Unmodifiableなコピーすることができます。// コピー元のリストList<String> original = ...// コピーするList<String> copy = List.copyOf(original);OptionalOptionalは積極的に使われていますか？私の場合は、Streamが返すもの以外で、自分でOptionalを使う場合はあまりないです。色々制約が多いので、複雑なNullチェックが必要な場合ではないと使いづらい気もしますね。ただ、9と10で追加されたメソッドでかなり便利に使えるものとなったので、たまには良いのかもしれません。or (9)Optionalの中身がNullの場合に実行されるメソッドです。既存のorElse()やorElseGet()と何が違うかというと、こちらはOptionalの中身ではなく、またのOptionalを返すということです。引数としてはSupplierをとります。String string = null;Optional<String> optional = Optional.ofNullable(string);System.out.println(optional.or(() -> Optional.of("default")).get()); // "default"orElseThrow (10)Optionalの中身がNullの場合は例外を投げる分岐です。NullのOptionalはもともとNoSuchElementExceptionを投げますが、ビジネスロジックなどによりカスタマイズした例外を投げたい場合などはこちらを使えますね。引数としてはSupplierをとります。String string = null;Optional<String> optional = Optional.ofNullable(string);String throwing = optional.orElseThrow(RuntimeException::new); // RuntimeExceptionifPresentOrElse (9)Optionalの中身がNullかどうかによって二つのアクションを指定して、分岐処理ができるようなメソッドです。第一引数としてはConsumerを指定することで中身がNullではない場合の処理を、第二引数としてはRunnableとして中身がNullだった場合の処理を書きます。Optional<String> hasValue = Optional.of("proper value");hasValue.ifPresentOrElse(v -> System.out.println("the value is " + v), () -> System.out.println("there is no value")); // the value is proper valueOptional<String> hasNoValue = Optional.empty;hasNoValue.ifPresentOrElse(v -> System.out.println("the value is " + v), () -> System.out.println("there is no value")); // there is no valuestream (9)Optionalを要素が一つか、Null(Stream.empty())のSteamに変えるメソッドです。もともとStreamから要素を取得するときもOptionalになっていたので、このようなメソッドが追加されたのも当たり前といえば当たり前ですね。要素が多くて一つなのにStreamに変える意味があるかというと、他のStreamと結合ができたりもするので色々と活用できる余地はありそうです。Optional<String> optional = Optional.of("value");Stream<String> stream = optional.stream();StringString APIの場合は、主にJava 11でかなりの変化がありました。Webアプリケーションのみならず、最近のアプリケーションは文字列を扱う場合が多いので、このような変化はありがたいですね。repeat (11)指定した数値分、文字列を繰り返します。同じ文字列の単純な繰り返しだとすると、StringBuilderやStrinbBufferなしでも簡単に使えるこちらのメソッドの方が良いですね。String a10 = "A".repeat(10); // "AAAAAAAAAA"strip (11)文字列の前後の空白を除外するために、今まではtrim()を使うケースが多かったのではと思いますが、Java 11からはstrip()が追加され、trim()を代替できます。この二つが何が違うかというと、まずそれぞれのメソッドで定義している「空白」が違います。trim()はUnicodeを考慮してなかったため、半角スペースのみの対応となっていましたが、strip()はUnicodeで指定されたWhitespace全部を対象とするので、全角スペースや改行にも対応できます。どの文字がWhitespaceとして扱われるかは、Character.isWhitespace()のメソッドが基準となるので、そちらのJavaDocを参照してください。String stripped = "\n hello world \u2005".strip(); // "hello world"また、strip()では前後の空白が全部削除されるのですが、文字列の前後を基準にして片方だけ削除したい場合は、前からだけを削除するstripLeading()や後ろからだけを削除するstripTrailing()も使えます。String stripLeading = "\n hello world \u2005".stripLeading(); // "hello world  "String stripTrailing = "\n hello world \u2005".stripTrailing(); // "\n hello world"今までの説明だけでも十分strip()を使う理由はあると思いますが、実はもう一つがあります。性能です。性能という面ではstrip()の方がtrim()より5倍も早いと言われているので、なるべくtrim()よりはstrip()を使うべきですね。isBlank (11)すでにisEmpty()というメソッドがありますが、このメソッドとisBlank()の違いは、trim()とstrip()の関係と似ています。同じく、isEmpty()と比べるとisBlank()の方がUnicodeに対応しているのでより多くのケースのWhitespaceに対応できて、性能でも優れています。boolean isEmpty = "\n \u2005".isEmpty(); // falseboolean isBlank = "\n \u2005".isBlank(); // truelines (11)文字列に改行コード(\n・\r・\r\n)を基準に分けたStream<String>を返却します。String multipleLine = "first\nsecond\nthird";long lines = multipleLine.lines().filter(String::isBlank).count(); // 3Prediacte not (11)LambdaやMethod Referenceで定義したPredicateの結果がFalseかどうかを判断するためのメソッドです。単純にtrueの否定になるだけなのですが、このメソッドの引数はPredicateなので、LambdaやMethod Referenceを使ってより単純に表現できるのがメリットといえますね。// 否定の条件式を使う場合list.stream() .filter(m -> !m.isPrepared()) .collect(Collectors.toList());// Predicate.not()を使う場合list.stream() .filter(Predicate.not(Man::isPrepared)) .collect(Collectors.toList());最後に2021年に次のLTSであるJava 17がリリースされると、今のJava 11を使う現場の場合は多くがJava 17に移行するのではないかと思います。12から16まで、さまざまなAPIや機能、JVMの改善などが含まれていて、すでに多くのブログなどで紹介されていますが、また既存のAPIにはどのような変化があるかまでは完全に把握していない状態です。なので、Java 17のリリースに合わせて、もう一度12〜17までの新しいメソッドの整理と紹介を行おうと思います。これだけでもかなり勉強になりますし、業務で使えそうなテクニックも増えていく感覚ですね。また、今年のポスティングはこれで終了となります。色々と大変な一年だったのですが、なんとか年末を迎えることができましたね。その間、このブログにも多くの方々がいらしてくださいました。まだジュニアレベルでしかない駆け出しエンジニアのブログなのであまり情報取集には役立たないかもしれませんが、少しでも私の書いたポストを読んでくださりありがとうございます。来年からは、より面白く、より良い情報を収取してブログに載せたいですね。では、また！

9からの新メソッドめぐり

Spring WebFlux、少し触ってみてからの話

今更なループの話

一般的に、アプリケーションには要求される業務的な要件やセキュリティの観点から考慮すべきことがあるので、なんらかの機能を作るときはそれが「動くか」だけでなく、任意のロジックが必要となる場合がありますね。なのでその機能が動くにはとある場合で、動くときはとある条件に合わせて処理をする、といった制限が要求されることがあります。今回のポストも、またそのような業務上の要件から生まれた話です。現在、私が関わっている案件では、EC2で起動するSpring Boot基盤のアプリを作っています。このアプリでは、ファイルのデータとアップロード先のパスを指定すると、S3にアップロードするという単純な機能があり、それは自分の担当となっています。単純にアップロードパスとデータがあれば、動く機能を作るのは単純です。SpringにはSpring Cloudというフレームワークがあるので、すでにResourceLoaderというクラスを持ってファイルアップロードを実現できます。Spring Cloudを使わない場合でも、AWS SDKを使うと簡単に実装ができます。事実、こちらの昨日もアップロード先のパスとファイルだけあれば良いものとなっているので、実装というまででもないですね。ただ、この機能が呼び出されたとき、渡されたアップロード先のパスが「正しいもの」であるかを確認する必要がありました。つまり、業務上ファイルをS3に格納する際に決まったパスのルールがあって、この機能からはパラメータとして渡されたパスが規定のパターンと一致するかどうかを一度チェックする必要がありました。渡されたパスが「正しいもの」かどうかをチェックするための機能は、何で作ったら良いでしょうか。そしてどう作った方が良いでしょうか。色々な方法があるかと思いますが、まずここでは自分がどう実装したかを紹介していきたいと思います。文字列のパターンは正規表現でまず、ファイルのアップロード先(保存先)パスは文字列であり、特定のパターンである必要があります。文字列が特定のパターンで構成されているかどうかの判定は、正規表現を使いますね。なので、「正しいもの」としてのパスのパターンは、正規表現としてあらかじめ宣言しておいて、渡されたパラメータがそれと一致するかをチェックすることとします。ただ、Javaでは正規表現を使って文字列のパターンを判定する方法がいくつかありますので、それらのうちにどれを選ぶべきかを考える必要があります。例えば、以下の方法がありますね。Pattern.matches()を使うPatternからMatcherを取得し使うPatternからPredicateを取得し使うString.matches()を使うそして、これらの方法は、以下のコード通りに使うことができます。// 正規表現の例String patternRegex = "^[0-9]*$";// 正規表現で判定したい文字列String value = "123456789";// Pattern.matches()を使う場合boolean patternMatches = Pattern.matches(patternRegex, value);// Matcherを使う場合Pattern pattern = Pattern.compile(patternRegex);Matcher matcher = pattern.matcher(value);boolean matcherFind = matcher.find(); // 部分一致boolean matcherMatches = matcher.matches(); // 完全一致// Predicateを使う場合Pattern pattern = Pattern.compile(patternRegex);boolean matcherFind = matcher.asPredicate().test(value); // 部分一致boolean matcherMatches = matcher.asMatchPredicate().test(value); // 完全一致// String.matches()を使う場合boolean stringMatches = value.matches(patternRegex);ここでMatcherやPredicateを使う場合、部分一致を選べられるので、部分一致の場合はこれらを使うしかなさそうです。しかし、完全一致が必要な場合は何を基準に、どれを選ぶべきでしょうか。どれも同じような結果を出すのであれば、より効率的な方法を選びたくなります。そして、この場合、考えられるのは性能です。つまり、どれを使った時にもっとも早く判定の結果を得られるかということです。どれも同じなら性能で前述の通り、文字列が与えられた正規表現のパターンと一致するかどうかを判断する様々な方法があるので、中でももっとも早いのはどれか、測定したいと思います。いわゆるストップウォッチ方式(処理終了時点の時間から、処理開始時点の時間を引く)が簡単ですが、より正確な比較がしたかったためOpenjdkから提供するJMHを使ってベンチマークを作りました。Java特有の起動が遅い問題で測定に影響が出るのを防ぐためか、何回かのウォーミングアップも含めて測定をしてくれるので、良いですね。実際にベンチマークを行うため使ったコードは、以下の通りです。public class RegexTest { private static final String PATTERN_REGEX = "^[0-9]*$"; private static final DecimalFormat DECIMAL_FORMAT = new DecimalFormat("0000000"); private static final Pattern PATTERN = Pattern.compile(PATTERN_REGEX); private static final Predicate PREDICATE = PATTERN.asPredicate(); private static final Predicate MATCH_PREDICATE = PATTERN.asMatchPredicate(); private static final List<String> VALUES = IntStream.rangeClosed(0, 9999999).mapToObj(DECIMAL_FORMAT::format).collect(Collectors.toList()); @Benchmark public void patternMatches(Blackhole bh) { for (String value : VALUES) { bh.consume(Pattern.matches(PATTERN_REGEX, value)); } } @Benchmark public void matcherFind(Blackhole bh) { for (String value : VALUES) { bh.consume(PATTERN.matcher(value).find()); } } @Benchmark public void matcherMatches(Blackhole bh) { for (String value : VALUES) { bh.consume(PATTERN.matcher(value).matches()); } } @Benchmark public void predicate(Blackhole bh) { for (String value : VALUES) { bh.consume(PREDICATE.test(value)); } } @Benchmark public void matchPredicate(Blackhole bh) { for (String value : VALUES) { bh.consume(MATCH_PREDICATE.test(value)); } } @Benchmark public void stringMatches(Blackhole bh) { for (String value : VALUES) { bh.consume(value.matches(PATTERN_REGEX)); } }}そして、測定の結果は以下の通りです。実際の出力はメソッド名の順番が違いますが、コードでの並び順に合わせて変えています。Benchmark Mode Cnt Score Error UnitsRegexTest.patternMatches thrpt 25 0.591 ± 0.013 ops/sRegexTest.matcherFind thrpt 25 1.525 ± 0.022 ops/sRegexTest.matcherMatches thrpt 25 1.481 ± 0.030 ops/sRegexTest.predicate thrpt 25 2.050 ± 0.182 ops/sRegexTest.matchPredicate thrpt 25 1.733 ± 0.236 ops/sRegexTest.stringMatches thrpt 25 0.609 ± 0.005 ops/sこの結果からして、性能面では確かにMatcherかPredicateを使った方が良いと言えるでしょう。ただ、ベンチマークの結果としてはPredicateが誤差を含めても性能がもっとも良いこととなっていますが、Pattern.asPredicate()はJava 1.8、Pattern.asMatchPredicate()はJava 11から導入されたので、JDKのバージョンに合わせて適切な方を選ぶ必要があります。ただ、結果だけでなく理由も知りたくなります。性能がよかったMatcherとPredicateの場合、テストではあらかじめインスタンスを作成しておいたという共通点があります。なので、性能の低いPattern.matches()とString.matches()の場合、メソッドが呼び出されるたびにインスタンスを作成しているため遅くなっているのではないか、という推測もできますね。実際はどうか、コードをみていきましょう。まずPattern.matches()ですが、実際のコードは以下の通りです。// Pattern.matchespublic static boolean matches(String regex, CharSequence input) { Pattern p = Pattern.compile(regex); Matcher m = p.matcher(input); return m.matches();}これをみると、PatternとMatcherのインスタンスがメソッドを呼び出すたびに生成されるということがわかります(実際、Pattern.compile()とPattern.matcher()のコードを追ってみるとインスタンスを作成するのがわかります)。なのでこちらが遅くなるのは当然のことですね。それでは、String.matches()の場合はどうか、同じくコードから確認しましょう。実際のコードは以下の通りです。// String.matchespublic boolean matches(String regex) { return Pattern.matches(regex, this);}これもまた、単にPattern.matches()を呼び出しているだけなので、遅いわけですね。ただ一つ違う点は、比較対象となる自分自身のインスタンスが必要なため、Patternとは違ってstaticメソッドではないというところといえますが、これは性能に影響する部分ではないので、ベンチマークでも誤差範囲の中の結果となったと思います。実際のValidatorを作るでは、性能でMatcherとPredicateが有利であるということがわかったので、あとはこれを利用して、渡されたパスが許容できるものかどうかを判定するValidatorを作ります。今の案件ではJava 11を使うので、Predicateを選びました。パスのパターンは複数あるので、配列やリストとしてパターンを指定して起きます。また、Predicateで判定するので、あらかじめ指定したパターンでインスタンスを作成しておいて、判定が必要なときはパターンの配列やリストをループさせて、一致するものがあるかどうかを返すと良いでしょう。この要件から、実際のコードは以下のようになりました(パスの正規表現は、実際の業務とは違うものとなっていますが)。@NoArgsConstructor(access = AccessLevel.PRIVATE)public class StorageValidator { /** * 許容されたパスのパターン */ private static final List<Predicate<String>> PATH_PATTERN_MATCHERS = List.of( createMatcher( "\\/contents\\/images\\/\\d{0,4}\\/(19[0-9]{2}|20[0-9]{2})(0[0-9]|1[0-2])\\/thumbnail\\.(?:bmp|jpg|jpeg|gif|png|BMP|JPG|JPEG|GIF|PNG)$"), createMatcher( "\\/contents\\/images\\/\\d{0,4}\\/(19[0-9]{2}|20[0-9]{2})(0[0-9]|1[0-2])\\/thumbnail_backup\\.(?:bmp|jpg|jpeg|gif|png|BMP|JPG|JPEG|GIF|PNG)$")); /** * * 与えられた文字列が、SPLで利用できる有効なファイルアップロードパスであるかどうかを判定する. * * @param path 判定対象の文字列(ファイルパス) * @return 判定結果 */ public static boolean isValidUploadPath(String path) { return PATH_PATTERN_MATCHERS.stream().anyMatch(predicate -> predicate.test(path)); } /** * * 与えられた正規表現から、{@link Predicate}型のパターンマッチャーオブジェクトを返す. * * @param pattern 正規表現 * @return 生成されたパターンマッチャーオブジェクト */ private static Predicate<String> createMatcher(String pattern) { return Pattern.compile(pattern).asMatchPredicate(); }}以上で、渡されたパスが想定のパターンと一致するものかどうか判定することができるようになりました。簡単ですね。番外：Kotlinで書いてみたら？今回のポストの内容とはあまり関係のないものですが、ちょっとした興味本位から、Javaで作成したValidatorをKotlinのコードに変えてみました。幸い、intellijには、Javaで書かれたコードをKotlinに変えてくれる便利な機能がありますので簡単にできます。そもそもKotlinを作ったのがJetbrain社なので、Kotlinを普及するための機能であるとは思いますが、おかげでJavaプログラマがKotlinに入門するのも簡単になりますね。static finalなフィールドをKotlinではcompanion objectとして扱うことになるらしく、コード自体はそう変わらない感覚です。ただ、Kotlinではstream()を呼び出さなくてもCollectionから直接呼び出すことのできるメソッド(any)があったり、List.of()もlistOf()で代替できるのですが、自動変換ではそこまでしてくれなかったので、そういうところ自分で変えるしかないです。それで完成したコードは、以下の通りです。class StorageValidator { companion object { private val PATH_PATTERN_UPLOAD = listOf( // 画像の保存先パスのパターン(正規) Pattern.compile( "\\/contents\\/images\\/\\d{0,4}\\/(19[0-9]{2}|20[0-9]{2})(0[0-9]|1[0-2])\\/thumbnail\\.(?:bmp|jpg|jpeg|gif|png|BMP|JPG|JPEG|GIF|PNG)$" ) .asMatchPredicate(), Pattern.compile( "\\/contents\\/images\\/\\d{0,4}\\/(19[0-9]{2}|20[0-9]{2})(0[0-9]|1[0-2])\\/thumbnail_backup\\.(?:bmp|jpg|jpeg|gif|png|BMP|JPG|JPEG|GIF|PNG)$" ) .asMatchPredicate() ) } fun isValidUploadPath(path: String): Boolean { return PATH_PATTERN_UPLOAD.any { predicate -> predicate.test(path) } }}最後に本当は、正規表現を使って文字列がパターンと一致するかどうかを判定する、という機能を作るのはそう難しいことではないですね。どちらかというと、正規表現そのものの書き方が難しいのでは、と思います。ただ、最近はRegExr、RegEx Testing、regular expressions 101など、その場で入力した正規表現をテストしながら作成できるオンラインのツールなども多いので、じっくり時間をかけるといくらでも必要なパターンに合わせたものを作ることができると思います。個人的な感想としては、書いたコードは短く簡単でしたが、久々に色々と考えられる(効率の面で)チャンスとなったのでなかなか面白い作業になったと思っています。これからもこのような要件があるとしたら、また違う方法で挑戦してみたくなりますね。では、また！

パターンと一致する文字列かを判定する

KotlinがJavaと区別される特徴といえば色々あるとは思いますが、そのうちの一つとしてあげられるものがScope Functionではないかと思います。以前のポストでも簡単に触れたことがありますが、これらのビルトイン関数たちは確かに上手く使うと、Javaより簡潔なコードを書くばかりでなく、より作成者の意図が伝わりやすい、強力な武器になり得るのではないかと思います。しかしながら、やはり他の言語と比べて新しい概念のものであるので、どの場面で使った方が良いか、どう使ったらいいかという、いわゆるBest Practiceがどんなものであるか悩ましくもなりますね。おそらくこう思っているのは自分だけでなく、ネットから検索してみるとScope Functionに関しての多くの記事を見つけることができますが、大抵が個別の関数の使い方の紹介に過ぎないような気がしています。なので、具体的にこれらの関数はなんのためのものであり、それぞれどう使い分けるか、またどの場面で使うべきかというのが気になっていたところです。調べてみたところ、公式のドキュメントやいくつかのブログの記事などに情報があったので、これらをまとめて整理してみました。そもそもScope Functionって？最初にScope Functionを言及しましたが、これは一体なんでしょう。まずはなぜこれらの関数にこんな名前がつけられたのかを知る必要がありそうです。公式の説明だと、以下のように述べています。The Kotlin standard library contains several functions whose sole purpose is to execute a block of code within the context of an object. When you call such a function on an object with a lambda expression provided, it forms a temporary scope. In this scope, you can access the object without its name. Such functions are called scope functions.要するに、特定のオブジェクトに範囲(Scope)を限定し、Lambdaで書かれた関数を実行させたい場合に使えるもののようです。もちろん、これは全く新しい形の関数ではありません。形(コードの書き方)としては、オブジェクトの関数を呼び出しているだけのように見えるだけですね。しかし、コードをみてみると、コードブロックで警戒を作ることでより特定のオブジェクトに限った処理であることが視覚的に、明確になります。例えば、以下のようなコードはどれもやっていることは同じですが、コードも読む側からすると処理を適用させる範囲は後者の方が明確になりますね。// Scope Functionなしのコードvar john = Person("John", 20, Gender.Male)john.doWarmingUp()john.startToRun()// Scope Functionのletを使った場合var john = Person("John", 20, Gender.Male).let { it.doWarmingUp() it.startToRun() it}どう違う？上述した通り、コードの範囲を限定することで、処理の範囲が明確になるのが分かりました。しかし、これでScope Functionを使う準備は整ったかというと、そうでもないです。実はそれ以外でも考えなければならないところがあるのです。なぜなら、Scope Functionにはwith、let、apply、run、alsoの5つの関数が存在するからです。複数の関数が存在していることは、時と場合によって違う関数を選ぶ必要があるということでしょう。では、これらの関数は他と何が違うのでしょう。まず、考えられるのは仕様です。Scope Functionは、内部的には渡したLambdaを実行してその結果を返すこととなっています。だとすると、仕様としてはLambdaで扱うオブジェクトと戻り値の差だけとなります。Scope Functionには処理の対象となるオブジェクト(レシーバーと言います)と、Lambdaをまずパラメータとして渡すようになります。ここで渡したレシーバーへのアクセスをどう書くかと、処理後の戻り値がどうなるかがこの5つのScope Functionでそれぞれ違います。これをテーブルとして表すと、以下のようになります。関数名レシーバーのアクセス戻り値withthis最後の結果letit最後の結果applythisTrunthis最後の結果alsoitTまた、withを除いた他の4つの関数たちは、Extension Functionでもあるという特徴があります。 Extension Functionは何か？というと、簡単に、既定のクラスに関数を追加することです。Javaだとクラスの継承やラッパークラスの作成、オーバーライドなどで実現できる機能ですが、Kotlinでは簡単に定義できます。「Scope FunctionなのにExtension Functionでもあると？」と思うかもしれませんが、理由は簡単です。クラスの作成時に関数として定義してなくても、もともとそのクラスにあったかのように呼べる関数だから、ということです。どのオブジェクトでも、宣言しなくてもwithを除いたScope Functionをあらかじめ宣言しておいたかのように使うことができます。参考：itとthisitは、パラメータが一つのみのLambdaで使われるものです。例えばJavaだと、パラメータが一つだとしても、Method Referenceを使わない限り以下のように書く必要があります。List<String> names = List.of("john", "jack");// Predicateの引数は一つだけだが、Optional<String> filtered = names.stream().filter(name -> "john".equals(name)).findFirst();Kotlinでは、同じ状況だとパタメータを省略して単純にitとして表現することができます。val names: List<String> = listOf("john", "jack")// itでの省略val filtered = names.first { it == "o" }結局、thisと同じではないか？と思いがちですが、itはLambdaのぱらめーたにスコープが限定されて、thisのスコープはローカルでもグローバルでもなれるという点が違います。なぜなら、thisはレシーバーそのものを指していて、パラメータがない場合はLambdaのスコープの外を指すことになるからです。つまり、パラメータのないLambdaではitを使えないですが、thisは使えるということになります。いつ使う?では、Scope Functionに5つの関数があり、それぞれどう違うかがわかったので、次はそれぞれをどう使い分けるか知りたいですね。さまざまな意見があったので、(自分の)納得の行くもので整理してみました。withwithはExtension Functionではないので、オブジェクトをパラメータとして受け取る一般的な関数として使えます。このような特徴があるので、複数のオブジェクトで同じような処理を行う必要があるときに使えます。例えばforループの中で、わざとメソッドを分離したくない(命名がめんどくさいとか…)の場合に使えるでしょう。また、やはりScope Functionなので、処理の範囲を明確に区分するためにも使えそうですね。for (name in names) { println(name) with(name) { var rev = this.reversed() reversedName.add(rev) }}letオブジェクトをトリガーにして、そのオブジェクトを持って何かの処理を行いたい場合に使うものです。letの意味通り、そのオブジェクトを持って何かをするというイメージですね。また、戻り値も最後の結果となるので、それを持ってまた何かができそうです。また、Safe Callな使い方ができるため、Nullではない場合のみの動作として指定することも可能です。なのでNullになり得るオブジェクトでは、letを使った方が良いでしょう。var name: String? = nullname?.let { println("name is not null") }applyLambdaでレシーバーの関数を使わず、レシーバーそのものを返却する場合に使います。つまり、レシーバーのプロパティに新しい値を入れる場合のことです。代表的にはオブジェクトの初期化がありますね。もちろん初期化だけなら、コンストラクタを呼ぶだけで十分ではないかと思われますが、同じオブジェクトの値を入れ替える(例えばConfigurationクラスなど)場合に役立つらしいです。例えば以下のような場合を考えられます。if (devMode) { SomeConfig().apply { name = "devMode" }}run他の4つの関数で事足りるので、なるべくこれは使わないように、という話が多いです。確かに、runはノーマルな関数としても使えるので(run {})、withとの違いがいまいちわからない感覚ではありますね。あえて使う場合は、オブジェクトの値をオーバーライドする時だそうです。でも、これもletでできるので、あえて使う必要はなさそうです。多くのケースで、これは推奨されてませんでした。ただ、一部ではオブジェクトの初期化として使うと便利と言ってました。確かにthisを使うので、少しながらitを使うletよりコードが短くなり得るというメリットはありますね。// runを使う場合var result1 = server.run { port = 8080 get("/members:$port")}// letを使う場合var result2 = server.let { it.port = 8081 get("/members:${it.port}")}alsoオブジェクトがトリガーとなり、そのオブジェクトとは関係のない別の処理を行います。なので、元のオブジェクトがNullであっても、そのオブジェクトが呼ばれた時点でなんらかの処理を行うことができます。これを応用すると、条件分岐(三項演算子)のように使うことも可能です。例えば、こんな感じですね。var name: String? = nullname?.let { println("name is not null") } ?: also { println("name is null") }まとめKotlin Standard Library (let, run also, apply, with)では、5つのScope Functionのどれを使うか判断する基準を、フローチャートとして提示しています。以下は、そのフローチャートを簡単に翻訳したものです。どれを使うか悩ましい時は、こういう基準でコードを書いても良さそうですね。応用Scope Functionが戻り値としてレシーバーそのものを返すというのは、すなわちBuilderパターンとして使えるという意味でもあります。なので、適切な組み合わせで、Scope Functionによるメソッドチェーンもできます。これをよく活用すると、かなり関数型的な感覚でコードを書くことができるでしょう。以下は、その例の一つです。// letの連鎖var three: Int = " abc ".let { it.trim() }.let { it.length }// alsoの連鎖var jack: Person = Person("Jack", 30, Gender.MALE).also { println(it.name) }.also { it.doWarmingUp() }最後に実は、このようなKotlinの機能は、そう新しいものでもありません。なぜなら、同じJVM言語であり、同じく機能するwith()のような関数を提供しているGroovyがあるからです。自分の中ではSpockかGradleのイメージしかないのですが…ただ、このようにKotlinが提供する機能は「新しくはないけど、快適」という感覚を確かに伝えてくれているような気がします。なのでJavaプログラマーがKotlinに転向していく数も増えているのでしょう。最近は特にPythonやJavaScriptのような言語が人気を得ているところですが(KotlinはTIOBEの順位からだと見えもしないし…)、もっと性能と安定性、そして快適な開発のバランスを持ちたいと思う人にはぜひおすすめしたい言語です。なのでもっと、Kotlinの魅力をより多くの人(自分を含め)にわかった欲しいところです。今回のポストで少しはそれが伝わると幸いですね。では、また!

Scope Functionはどう使うか

KotlinがAndroidの公式言語になってからもだいぶ長い時間が経ちましたが、まだまだWebアプリケーションの業界ではサーバサイド言語としてはJavaを使う企業も多く(自分の場合がそうです)、モバイル業界でもJavaを使うところが多いようです。Javaも9以降はアジャイル開発でバージョンアップにスピードを出していて、いわゆるモダンな言語の特徴を吸収していってますが、そもそもの言語のデザインが古いし、互換性のために昔ながらの名残を捨てられてないところもあるので根本から違う哲学でデザインされた言語とはかなり違うはずです。また、JVMを利用しないKotlin Nativeも発表されているので、今後Javaよりも活躍できる場面が多いかも知れないなーという気がしたりもします。(GraalVMは使われることあるのかな…)取りまとめ、まだ正式の研修とかを受けたわけでなく、あくまでSpring WebFluxを使って簡単なアプリを作ってみるついでに使ってみただけなので、よくわかってない部分も多いかと思いますが、今まで触れてみた感想をJavaプログラマーの観点から簡単に紹介したいと思います。これがよかったまずは使ってみてよかったところから。結論からとなりますが、良いと思ったところはおおよそイメージ通り(期待してた通り)という感覚です。やはりモダンな感じKotlinで書いたコードを見ると、モダンな言語だとやはりこんなものかなという感覚ではあります。モダンな言語が何か、という定義から必要になるのではという気もしますが、例えばSwift、Kotlin、Goみたいなものですね。あまり他の言語に詳しいわけではないのですが、これらの言語はなんとなくPythonに似ているような気がします。例えばvar、funのように基本文法で略語をよく使っていたり、型の指定はコロンの後につけたり、セミコロンがなかったり、inやRange、isがあるなどの共通点があったりしますので。他には、言語の使用ではないけど、一般的にはGetter/Setterを使わずフィールドに直接アクセスするところですかね。(おかげでLombokを使う必要がないのも便利ではあります)ただ、そんなモダンな感覚でありながらも、やはりKotlinはJavaよりな感覚ではあります。厳格なJavaをよりゆるくしただけの感覚といえばいいでしょうか。例えばPythonだとelifなのですが、Kotlinではelse ifだったりしますので。JVM言語という理由だけでなく、基本文法からしてもJavaプログラマーならすぐに適応できる言語でもあります。例えばforループにラベルをつけることができたりします。あえてJavaとの比較をするとしたら、やはり冗長さを省けただけでなく、Javaという言語のデザインを根本的に変えようとしている気もしていました。例えばNullや、Mutableを扱う方式がそうです。Kotlinでは基本的に変数はNullになれなくて、Nullになれるオブジェクトは最初からそうであると宣言する必要があり、Nullになれるオブジェクトを扱う時もSafe Callを強制することでNullに対してはコンパイラレベルではできるだけサポートしている感覚です(おそらくこれはモダンな言語だと全部がそうですが)。そしてCollectionなどを宣言する時も、あえてMutableという宣言をしない限りは基本的にImmutableなオブジェクトが生成されます。これだけでもJavaでもっともよく見つかるNPEをよく避けられる気がしてしまいます。いちいち宣言して、コールもクエスチョンマークをつける必要があるのは面倒臭いことな気もしますが、コンパイルエラーの方がランタイムエラーよりはずっとマシだというのは我々みんなが知っていることではないでしょうか。あとは、個人的にPythonで使ってみてよかったなと思った機能がKotlinにもあってよかったです。例えばMultiple Return(複数の戻り値)だったり、Named argument(名前付き引数)があります。前者は特に、Pair/Tripleという型で明確な戻り値を提示できるのが素晴らしいと思います。こういうところはモダンながらも、Javaの持つ安定性もしくは丈夫さを捨ててなかったなという印象を与えてくれました。ただ、これらのメリットは最近のJavaもかなり近づいている状態ではあります。(まだ少し遅い感はありますが)クラス=ファイルではないJavaの場合は、一つのファイルには一つのクラスというのが常識のようになっています。もちろんInner Classを書く場合もありますが、それだと名前とおりクラスの中に含まれたものになるので、インスタンスを生成するときに複雑だったりしますね。でもKotlinだと、純粋なクラスを一つのファイルに複数書くことができます。なので、似たようなクラスを一つのファイルの中に集めておくことができますね。例えばDTO、DAO、Entityなど似たようなクラスが複数損際するパターンでは、一つのファイルの中にそれらを集めておいた方がパッケージの中が複雑にならないような気がします。実際、Kotlinを試しながら好みの領域の話かもしれませんが。どちらかを選択できる自由があるというのが、必ずしも良いこととは言い切れませんが、ファイル内にクラスを複数書くかどうかはキメの問題であって実装時のコーディングスタイルに影響を与えるものではないので(今時importを直接書く人もいないだろうし…)、良い点として挙げられるのではないか、と思います。拡張関数で自由に関数を追加できるJavaのデメリットとしてよく挙げられているのが、冗長すぎる(verbose)ということです。いわゆるBoilerplateなコードを毎回書かなくてはならないというのは、生産性の面からもよくないです。Javaにこういう面があるので、さまざまなデザインパターンが発達したり、IDEでコードを自動生成してくれたり、Lombokのようにコードの量を減らしてくれるライブラリが人気だったりしますね。自分が開発に参加したフレームワークの開発の案件も、結局は冗長化するコードを減らしたいという目的によるものでした。とにかく、Kotlinはこういう問題に対する反発ないしは反省から言語がデザインされているようにも見えます。最近のモダンな言語の特徴をコピーしただけでなく、Javaを改善させたいという強い意志が言語のデザインから感じ取れているような感覚でした。スタンダードライブラリがとにかく便利拡張関数が便利な理由ともつながるようなことですが、Kotlinのスタンダードライブラリに存在する関数たちもまた同じ観点から便利といえます。例えば、すでに有名なのがいわゆるScope Functionsのlet、with、apply、run、alsoのような関数です。これらはJavaだと別途ユーティリティクラスを作るか、プライペートなメソッドを定義するか、特定のクラスを継承してからオーバライドで関数を新しく定義するなどの方法で対応はできるものの、やはり手間がかかるのでやりたくはないものです。これをKotlinでは、より関数型的な方法で解決してくれます。例えばletの例を見ていきましょう。以下のようなdata classがあるとします。data class Member(val region: String, val name: String)このdata classのインスタンスを一つ作成します。そうすると以下のようになるでしょう。var john = Member("Tokyo", "John")あとで、同じくMemberのインスタンスとしてjakeという変数を追加するとします。jakeは常にjohnと同じregionである必要があります。var jake = Member("Tokyo", "Jake")これをJavaの考え方で、コードを整理するとしたら以下のようになります。regionを同じインスタンスを使うようにすることですね。var tokyo = "Tokyo"var john = Member(tokyo, "John")var jake = Member(tokyo, "Jake")これをletを使う場合のコードとして書くと、以下のようになります。var jake = john.let { Member(it.region, "jake")}共通のregionを別途変数として宣言したくても、jakeのregionはjohnに指定したregionと同じ値となります。そしてある意味、こちらの方が「johnとjakeは同じregionを共有する」という意図がコードの中によく表れているのではないか、という気もします。今は簡単なフィールドを共有しているだけですが、変数の数が増えたり処理すべき項目が多くなった場合はいちいち定数を宣言するよりも、このような書き方の方がより優雅になるのではないか、と思います。そういう意味では、かなり洗練された方法を提供していますね。同じことをJavaでまねるとしたら…あまりやりたくなくなりそうです。これはいまいちKotlinがJavaのさまざまな問題や不便さに注目し、それらの多くを解消してくれたのは事実ですが、果たして全てJavaより発展しているか、というとそうでもないような気もします。ただし、ここであげているKotlinの問題点ないしデメリットは、メリットと同様、個人的な見解なので参考までに。varと型モダンな言語から接した人なら、変数の宣言がvarだけで集結するのはメリットと言いたくなるかもしれません。実際Kotlinだけでなく、JavaScriptやC#など現代に使われる大体の言語はvarに対応していて、あのJavaすらも10からvarによる変数の表記を導入しています。また、Pythonのようにそもそもvarの宣言すらいらない言語があったりもしますね。varをつけることで変数であることが明確だという考え方から来てるのか、Javaとは違って関数もFirst Class Objectとして扱う言語としては関数と同様に表記したいからそうしてるのか、よくわかってないのですが、どっちかというと流行りのもののようです。こういう傾向だけを見ると、「変数は変数であることが分かればいい」というだけの話になっているようにも思えます。しかし、私はこのvarが果たして良いものであるかという疑問を持っています。Javaに慣れすぎていて、新しいのを受け入れられてない、もしくはvarの良さをわかってないだけかもしれませんが、とにかく「型指定で変数であることも、型もわかるからこっちの方が良くないか」と思ってしまいます。こう思うまたの理由は、モダンなプログラミング言語の中でもTypeScriptのように、あえて型指定ができるように既存の言語を変えようとする動きもあるからです。Pythonの場合も3.6から型を宣言できるようになっています。これ自体が、「変数は変数であることが分かればいい」から「変数の型もわかった方がいい」に変わっているように見えます。ただ、問題は最初から型指定で変数を指定する方法がなく、varしかない言語に型指定(型注釈)が付く場合です。varのメリットである短くかけるというところが、型指定をすることで台無しになります。例えば、Kotlinでのvarだけの宣言だと以下のようになりますね。var a = "this is string"そしてvarに型を指定すると以下のようになります。var b: String = "this is string"Javaの伝統的な書き方だと以下です。こちらの方が、むしろコードは短くなるし、変数であることも明確ではないでしょうか。String a = "this is string";また、厳密にいうと変数ではないところではvarをつけないのは当たり前なのかもしれませんが、Javaだと変数でも戻り値でも引数でも型をつけてしまうのに対して、Kotlinではこれらにvarをつけるか型をつけるか方が省略できるかという場面がそれぞれ区別されてしまうので、これだけはJavaよりも厳格じゃないか？という気になったりもします。例えば以下のような例です。関数の引数の場合は、型の指定が必要です。fun getMember(request: ServerRequest): Mono<ServerResponse> = ok() .contentType(MediaType.APPLICATION_JSON) .body(repository.findById(request.pathVariable(id).toLong()).map { MemberDto(it.username, it.name) }) .switchIfEmpty(notFound().build())そして関数の戻り値は、型推論により省略可能です。fun getMember(request: ServerRequest) = ok() .contentType(MediaType.APPLICATION_JSON) .body(repository.findById(request.pathVariable(id).toLong()).map { MemberDto(it.username, it.name) }) .switchIfEmpty(notFound().build())しかし、これはあくまで関数をSingle Expressionで書いた時の話です。明示的にreturnを書く場合は戻り値を省略するとコンパイルエラーになります。例えば以下のような場合がそうです。// これはコンパイルエラー(戻り値はUnitとなってしまう)fun getMember(request: ServerRequest) { return ok() .contentType(MediaType.APPLICATION_JSON) .body(repository.findById(request.pathVariable(id).toLong()).map { MemberDto(it.username, it.name) }) .switchIfEmpty(notFound().build())}また、data classの場合はフィールドにvalかvarをつける必要があります。しかし、一般的なクラスを宣言する場合は要りません。// data classではvalかvarが必要data class MemberDto(val username: String, val name: String)// classなら必要ないclass MemberEntity(username: String, name: String)通常はコンパイルエラーになるので、慣れるまではKotlinのルールに従ってコードを見直すしかないのですが、Javaからの入門だとかなり混乱する部分です。(自分だけかもしれませんが…)依存関係プロジェクトにKotlinを使う場合はスタンダードライブラリを追加して使う必要があります。ただ、ここでkotlin-stdlibだけを追加すると、Java 1.7以降に追加された一部の機能(AutoCloseableなど)を使えなくなります。なので、Java 1.7以降の機能を使いたい場合はkotlin-stdlib-jdk7かkotlin-stdlib-jdk8を依存関係に追加する必要があります。個人的にはOracleとGoogleの訴訟沙汰のようなことがあって、わざと著作権を避けるための独自のパッケージを作ったりしらからではないかなと思いましたが、実際はJava 9から導入されたModuleシステムに対応するための理由だそうです。なのでkotlin-stdlib-jre7がkotlin-stdlib-jdk7に、kotlin-stdlib-jre8がkotlin-stdlib-jdk8に代替されたらしいですね。とにかく、これらのスタンダードライブラリを使うには、MavenやGradleのような依存関係を管理するパッケージマネージャを使って一回だけ登録しておけばよく、そこまでめんどくさくはないことなのかもしれませんが、例えばkotlin-stdlib-jre8があったりするので、初めはどれを選べば良いか、どれが必要であるかを把握するのにも時間を使ってしまうことになるのでデメリットになるのではないかと思います。例えばkotlin-stdlib-jdk7がなくても、AutoCloseable以外のJDK 1.7の機能は使えたりするのですが、今から作るプロジェクトや既存のプロジェクトにAutoCloseableが使われるかどうかで依存関係をまた追加するかどうかを調べるのもかなり面倒くさそうです。そしてJDK7やJDK8対応のスタンダードライブラリが別途存在するということは、今後JavaがバージョンアップしたらまたJDK 17などの新しいスタンダードライブラリが追加される可能性があるということでもあるでしょう。7(1.7)と17はよく勘違いしそうだし…あと、JDK以外の依存関係のパッケージが色々あるので(kotlin-reflectなど)、プロジェクトの構成によってはKotlinの導入にはかなり慎重になる必要がありそうです。ある意味、KotlinがPost Javaとしてのポテンシャルは十分でありながらも、Androidアプリの作成以外にではあまり導入されてないのはこのような理由もあるのではないかという気もしています。最後に簡単にPros・Consに分けて自分が感じたKotlinに対して書いてみました。実はまだ本格的な案件で触れてみたわけでもないので、Type aliasesやinline classのような良さそうな機能に触れてもないです。でもやはり、使えば使うほど魅力的な言語であるなと感じているところです。なので個人的な意見としては、すでにJavaを使っているところなら本格的にKotlinへの移行を考慮しても良いのでは、と思っています。Javaプログラマーなら慣れやすく、より生産性も高いながら、Javaとの100%の互換性も担保されているので…言語の完成度やJVM対応でありながらNative、JavaScriptとの連動も可能なのを見るとまさにPost Javaとして相応しい言語なのではないかと思うくらいです。(他のJVM言語には悪いですが…)そういう意味で皆さん、今からでもKotlinやりませんか！

JavaプログラマーがみたKotlin

入社してから自分で立てた目標は、年に1つ以上の資格を取ることです。それは自分が元文系出身であって、転職でエンジニアになったので他の人と比べエンジニアとしてのベースとなる知識が足りないからです。なので「何から勉強したら良いかわからない」場合も多く、資格の勉強をしていると少なくとも問われることに対しての勉強はできるので、資格の勉強を頼りにして自分のスキルアップを狙っています。そんな中、今回はAWS認定の資格を受験しました。AWS認定資格の種類は以下の画像の通りですが、この中で自分が受験したのはデベロッパー - アソシエイトです。仕事でAWSの基本的なサービス(EC2とS3など)に触れたことがあり、AzureでもFunctionsとQueueによる簡単なサーバレスアプリを作ってみたり、Bastionなどのサービスを使ってみた経験があったので悩まずデベロッパーを選択。なんとか受かりましたが、少し使ってみただけで気安く挑戦するような資格ではなかったと実感しました…出典：AWS公式サイト - AWS認定ともかく、前回のJava資格の時でもそうであったように、今回も自分の観点からテストはどうだったかについて簡単に述べていきたいと思います。試験はどんな感じか問題で問われる知識の内容や範囲(AWSのサービスの種類)の側面でなく、テストそのものはどうかというと、学生時代の歴史の科目のような感覚のテストでした。もちろん、テストとは受験者の持っている知識の確認が基本なのであって、AWSのサービスの仕様や特徴などを問われるだろうと推測するのは自然なことだと思います。しかし、実際のテストで問われるのは「このようなアプリを開発するためにはどんなサービスを使って、どのような構成にするべきか？」といった物よりも、「このような要件で、入力すべきCLIのコマンドは何か？」、「この状況下のこのサービスで、〇〇を設定するために使うオプションは何か？」のような、暗記の問題が多い感覚です。例えば、特定のサービスにとある設定をするために使うファイルの「ファイル名」を選ぶような問題があったりします。AWSには本当に多様なサービスがあって、それぞれの役割や領域が重なる部分もあるので、サービスの仕様を正確に把握していない場合は設計も開発も難しくなるので、自然に試験もこのような形になるのかも、とは思っています。特に資格のレベルが上がり、アプリケーションの設計という面で考えると、開発の効率やコストの問題も考えなくてはならないので、各サービスの仕様の詳細までを知っておく必要があるでしょう。ただ、このようなクラウドサービスの発達により、インフラもコードで書いて構築する時代となっているし、資格も「デベロッパー」なのに、より開発者よりな形の試験にするのはできなかったのかな？と思ったりもしました。例えばLambdaについての問題だとすると、頻繁なアクセスがある場合と処理量の多い場合はそれぞれどの言語で書いた方がいいか、を聞いたりしたらよかったのではないかなと思いました。どうやって準備したか自分の場合はアソシエイトの3つの資格の概要をまとめた本を購入しましたが、あくまでAWSのサービスを紹介するものでしかなかったので、Udemyで5回分の模擬試験の講座を購入しました。ただ、こちらもデベロッパーをターゲットとしてるよりは、プロフェッショナルレベルの資格の内容も含めているような印象でした。どちらかというとUdemyの模擬試験の方が難しかったと思います。他にもUdemyの模擬試験も複数ありますので、どれを選ぶかによってまた実際のテストで受ける印象は変わってくるのではないかと思います。個人的には他の資格もある程度問われる知識に関しては共有する部分が多いと思うので、難易度の高い模擬試験の講座を購入し、繰り返して解いてみることがもっとも効率的ではないかと思います。そうすると他の資格を受験するときに役立つ可能性もあるでしょう。他にもAWSのオンライン動画講座を受講したり(無料ですが、英語版しかないです)、公式のドキュメントを参照したりしていました。AWSの公式のトレーニングコースで動画やPDFの資料を提供していますので、目を通しておくのをオススメします。また、プラクティショナから取得されている方にはあまり当てはまらないことなのかもしれませんが、AWSのサービスは略称で呼ばわれることが多く、名称だけではどんなサービスなのか推測が難しいので、少なくとも模擬試験で言及されるサービスに対しては自分の辞書を作っておくのをオススメします。EBSとEFSはストレージなのに、ECSはコンテナサービスだったりするので…(他にも、SQSとSNSはメッセージングなのにSTSはセキュリティ関連の物だったりします)とにかく「覚える」ことがまず大事な資格だと思います。何を問われるかそれでは、次は試験の内容です。AWS公式サイトのデベロッパーの紹介ページを見ると、推奨される知識と経験としていくつか挙げられている項目がありますが、これはあくまで大まかな概念の話であって、実際のテストで具体的に何を問われるかは提示されていません。サンプル問題があるのでそちらを参照することはできますがね。自分の場合は模擬試験を通じて勉強はしたものの、模擬試験のうちどれがデベロッパーに当てはまるかは分かりませんでしたので、AWの公式の模擬試験を購入するのもありかなと思いました。とにかく、実際のテストでよく問われれる(デベロッパーとして重要視される)と感じたのは以下のような物です。サーバレスアーキテクチャもっとも多かった問題のパターンは、サーバレスアーキテクチャでの開発に関するものです。つまり、AWS LambdaとAmazon DynamoDB、もしくはAmazon Kinesisの組み合わせでアプリを構築する場合を提示して、そこで注意すべきことや、障害が起きた場合の対処、各種設定方などを問われます。単純にサーバレスがどんな物であるか、を理解しているだけでは十分ではないと思います。なので以上の三つに関しては、詳細まで勉強する必要があります。Lambdaでの依存関係の設定はどうするか、スケーリングを考慮したシャードの設定方法、RCUとWCUのスペックなどを覚えておくといいでしょう。また、サーバレス開発をする場合だとしても、エンドポイントやセキュリティ周りのことは一般的なアプリケーション開発(サーバあり)と変わらないので、一般的な開発のパターンで考えるべきところの問題もありました。例えば、Amazon API Gatewayの設定やS3、CLIコマンドの使い方などがあります。セキュリティセキュリティに関する問題もあります。主にIAMでのポリシー、ロール、グループの設定や、KMSを使った暗号化キーのマネージメント、などがあります。Lambdaについての問題があるので、もちろんLambdaオーソライザーに関しての問題もありました。ログ・監視アプリケーションに障害が起きた場合での追跡方法や、監視したい要件でどのような設定をすべきかを問われます。例えばX-Rayデーモンの設定方法や、CloudWatchとCloudTrailの違いが何かなどをとう問題があります。Code兄弟CI/CD関連で問われる問題です。CodePipeline、CodeDeploy、CodeBuild、CodeStarに関して問われますが、それぞれの役割をちゃんと理解していれば難しくはないです。ただ、機能的にElastic Beanstalkや、CloudFormationと重なる部分があり、デプロイでどれを使うかを選ぶような問題もあったような気がします。これらの違いはちゃんと覚えておく必要があります。自分の場合は、以下のイメージを見てだいぶ理解ができたと思います。出典：AWS公式サイトトレーニングコース Exam Readiness: AWS Certified Developer - Associate (Digital)以上の内容は、AWS公式の動画でよく説明してくれているので、一回は受講することをオススメします。参考にすると良い情報他に、ちょっと覚えておくと良さげなものは以下の通りです。名前だけは知っておきたいサービステストで深くは問われないですが、名前だけ(そして何をするものか、大まかなイメージだけ)知っておくといいものとしては、OpsWorks、Step Functions、Systems Managerのパラメータストアがあります。ただ、こちらまで覚えるのは流石に余裕がないと思います。他も覚えるべきものは山ほどあるので…AWS Elastic Load BalancerELBについての問題も出ますが、最初はいまいちALB、NLB、CLBのことがわからず苦労をしていたので、以下のことを覚えておくと良いと思います。ELBはクラウドプラクティショナでも問われるものなので、私みたいにAWSの資格が初めてだったり、ELBのことが全くわからない場合に覚えておくといいでしょう。特徴ALBNLBCLB対応ProtocolHTTP, HTTPSTCP, TLSTCP, SSL/TLS, HTTP, HTTPSプラットフォームVPCVPCEC2-Classic, VPCHealth-Check対応対応対応CloudWatchマトリックス対応対応対応ロギング対応対応対応Zonal Fail-Over対応対応対応Connection Draining対応対応対応同じインスタンスの複数ポートに負荷分散対応対応-WebSockets対応対応-ターゲット(IPアドレス)対応対応-ターゲット(Lambda)対応--ロードバランサー削除保護対応対応-パスベースルーティング対応--ホストベースルーティング対応--Native HTTP/2対応--Idle Connection Timeout設定対応対応-Zond間の負荷分散対応対応対応SSLオフロード対応対応対応SNI(Server Name Indication)対応--Sticky Session対応-対応バックエンドサーバ暗号化対応対応対応固定IP-対応-Elastic IPアドレス-対応-送信元IPアドレスを保持-対応-リソースベースIAMアクセス許可対応対応対応タグベースのIAM権限対応対応-スロースタート対応--ユーザ認証対応--リダイレクト対応--固定応答対応--受かったあとは試験に受かったら、しばらくしていくつかの特典をもらえるよ、というお知らせのメールが届きます。詳細はAWS認定のサイトからも確認できる内容ですが、簡単に紹介しますと以下の特典が提供されます。AWS認定ロゴのついたグッズを購入できるAWS認定資格の模擬試験を一つ購入できるクーポンをもらえるLinkedInのAWSコミュニティに入れる次の試験が半額になるクーポンをもらえるイベントがあったら通知をもらえるAcclaimに登録できるデジタルバッジをもらえる正直デジタルバッジと模擬試験のクーポンがもらえる以外、使うところがあるかどうかは少々疑問になるライナップではあります。ただ、自腹の場合は確かに次の試験が半額になるのはメリットになるでしょう。自分の場合は会社負担のなっているので、半額でも特にうれしくはないのですが…最後にそれで、受験する価値はあったのか？というと、それはあったと思います。暗記に弱く、あまり好きではないので苦労したのは事実ですが、おかげでAWSというサービスをより深く理解することができたと思っています。違うベンダーのクラウドだとしても、やはり大まかなサービスのコンセプトはやはりAWSと変わらないものなので、AzureやGCPなどを使う場合でも十分役立つのではないかと思います。実際、AWSを使うことで得られた知識でオラクルクラウドのVMを有効活用しているところです。また、クラウドごとに無料Tierで提供されるサービスはそれぞれ違うのですが、AWSの場合はLambdaとDynamoDBが無料で使えます。なので、この資格を勉強しならが得られた知識で何らかのサーバレスアプリケーションを作ることも可能になったような感覚です。オラクルクラウドとGCPでは無料で使えるVMを提供しているので、この組み合わせだと無料プランだけで立派なサービスを立ち上げることも不可能ではないような気がしますね。おそらく、こういうのも資格に挑戦してなかったら得られなかった知識だっただろうと思っています。一つ悩ましいのは、AWSの資格は3年という有効期限があるということです。クラウドは常に変化するサービスであり、続々と新しいサービスが登場するものなので仕方ないものですが、資格を持ってどこに活用するか(例えば、就職や転職に使うなど)はよく考える必要がありそうな気がします。あとは、、他の資格とも共有する部分が多いと思うので、連続して違う資格を早めに取っておいたほうが良さげな感じですね。なので自分もいつかまた、ソリューションアーキテクトなどに挑戦したいと思っています。ま、しばらくは疲れたので全然挑戦する気にならないのですが…

AWS認定デベロッパー - アソシエイトについて

MDNの説明によると、HTTPメソッドは主に「リソースに対する」ものだと定義しています。なので書くメソッドの説明としても、GETならリソースの表現、POSTならリソースの作成、PUTならリソースの置き換え、DELETEならリソースの削除のような表現をしていますね。これを元に、CRUDの基本を説明するような資料も多く、学習者は自然にAPIのデザインはリソースの作成、参照、置き換え、削除を基準に考えることになります。あとはリクエストに対する処理が冪等であるかどうか、というのが重要ですね。理論 != 現実しかし、理論的にはそうだと認識していても、実際の業務をアプリケーションとして表現していくと、悩ましい場合があります。今回がそうです。「リソースを単純に返すだけに見えるけど、実際は内部的にリソースの作成や修正が伴う処理の場合はどうするか」という疑問がありました。なぜなら、このような要件があったからです。クライアントにとあるファイルのダウンロードを提供するAPIがある。サーバからのファイルの取得には以下の二つのケースがある。ファイルがすでに作成されていて、サーバはそのファイルをクライアントに返すだけ。リクエストに応じて、サーバがDBのレコードをファイルに書き込み(作成し)クライアントに返す。クライアントがファイルをダウンロードすると、サーバはDBを更新する。サーバはDBに「ファイル出力済み」というフラグと、「更新ユーザ」としてログインユーザの情報を登録する。「ファイルがすでに作成されていて、サーバはそのファイルをクライアントに返すだけ」だと、GETでことは済みます。クライアントの観点からしてもそうであって、サーバもすでにあるリソースを返すだけですね。これは一般的にGETに期待する、「リソースの表現」に合致していて、何の問題もないです。しかし、「リクエストに応じて、サーバがDBのレコードをファイルに書き込みクライアントに返す」の場合はどうでしょうか？ファイルを新しく作成するのは、「リソースの作成」に当てはまるのでしょうか？それとも、レコードとしてすでに存在しているので、ただ違う形に加工するだけであって「リソースの表現」に当てはまるのでしょうか。または、ファイルの要請だけでなく、クライアントが提供した情報を持ってDBの更新を行うので、「リソースの作成」に当てはまるのでしょうか。誰の観点から見るべきか以上の問題は、自分の観点、つまり、バックエンドエンジニア及びアプリケーションとしての問題でもあります。ならば、クライアント(ユーザ)からしてみるとどうでしょうか。以下のことを考えられます。クライアントはファイルがすでに作成されているか、作成してくれるかに興味がない。リクエストは「ファイルをくれ」であり、「ファイルを作ってくれ」ではない。クライアントのリクエストに合わせてファイルを作成するかしないかはサーバ(アプリケーション)の都合である。クライアントはファイルを要請するだけであり、中の処理についてはわからない。つまり、クライアント側からすると、ファイルをダウンロードするという行為に関しては、あくまで「リソースの表現」を要請することに過ぎなくなります。サーバサイドとはまた都合が違いますね。こういう場合は、どちらの都合に合わせるかは明白ではないでしょうか。優先すべきは、クライアントですね。なぜなら、アプリケーションはそもそもクライアントの要件のために存在するものであるからです。なので、サーバサイドの都合でリクエストをPOSTにする理由はなくなりますね。Specではただ、クライアント側の観点枯らして、こういう場合はGETが正しい、と決めつけるにはまた違う根拠がいるのではないでしょうか。例えばHTTPの標準とかです。ちょうど、HTTPのスペックに関する文には、以下のような章があります。4.2.1. Safe MethodsRequest methods are considered “safe” if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.4.2.1 安全なメソッドクライアントがサーバの状態を変えない、変わることを期待しない読み込み専用のリクエストは、「安全」とされる。安全なメソッドを正しく使うことによりサーバにとって害や損となるような事情を発生させなくなる。これを見ると、クライアントのリクエストによりサーバに何かリソースの変化をもたらすようなことになる場合は、GETではなさそうが気がします。しかし、重要なのはこの次の内容です。This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access log files at the completion of every response, regardless of the method, and that is considered safe even though the log storage might become full and crash the server.安全なメソッドが、完璧な読み込み専用でなかったり、副作用を伴うなどで害を招くような実装を防止するわけではない。大事なのは、その動作はクライアントの要請ではなく、責任もまたクライアントにないということである。例えば、多くのサーバはどんなメソッドに対してもアクセスログを記録するが、ログによってサーバのストレージが足りなくなりサーバに障害が生じることもあり得るが、こういう場合でもリクエストは安全とする。つまり、大事なのは実装上の都合はあくまでサーバサイドの責任であって、クライアントからの行為であるということですね。安全なリクエストのためには、クライアントのリクエストがどのようなものであるかを考えるべき、という結論になります。HTTPメソッドはそういう行為の本質を表すものであり、サーバの都合の表現ではない、ということですね。なのであくまでクライアントからして、「リソースの表現」に対する要請であれば、サーバはGETとして応じるベキになるかと思います。最後に実際のウェブサイトを観察してみても、純粋な「リソースの表現」としてのGETはあまりないような気もしています。例えば訪問するだけで「訪問者カウンター」が更新されるサイトがあったりしますね。こういう場合でもクライアントはリソースの作成やリソースを要請してなく、サーバ側で勝手に更新を行っていますが、依然としてGETとされまていて、違和感もないです。むしろこのようなリソースの変更全てをPOSTとして扱うようになるとしたら、GETを使う場面自体がなくなるかもしれません。ただし、注意しなくてはならないのが、リソースの作成や更新を伴うリクエストを全てGETにするという発想も危険であることです。リソースの扱い方という原則に戻って考えたら、「POSTで作成させた後、GETで取得させる」というやり型もあるのかもしれません。こういう場合は2回のトランザクションが発生するので性能面では劣るかもしれませんが、場合によってはより安全な設計になる可能性もありますね。なので「全てのケースに置いて」ではなく、アプリケーション全体の設計や今後の方向性を考慮した設計として適切なHTTPメソッドを選んだ方が良い、というのが結論になるかと思います(原論的な話ですが)。重要なのは、「こういう場合は絶対GETだ」、「こういう場合は絶対POST」だと言わないことですね。

GETとPOSTの間

Springが初めて発表されたのが2002年なので、およそ20年に近い時間が経ちました。今はJavaと言えば当たり前のようにSpringを使っていて、Spring MVCやMaven、propertiesのような煩雑な環境構築と初期設定の問題も、Spring Bootが登場したおかげでだいぶマシになりましたね。特に自分の場合がそうですが、Spring Boot、Gradle、yamlを使ってXMLは一つもないアプリをよく書いていて、なんでも楽と思います。こうも発展を成し遂げているSpringですが、実は数年前から、そもそものSpring MVCの問題を改善したいという声があり、Spring 5.0からはMVCとは全く違う、新しいフレームワークが登場していました。それが今回紹介します、Spring WebFluxです。Spring WebFluxはMVCと何が違うか最初から作り直したフレームワークなので、根本的な部分から違うところが多いので、理論的なだと以下のキーワードをあげられますでしょう。非同期、ノンブロッキング、反応型私の(コードモンキーの)レベルからしたら、実際のコードのレベルで体感するMVCとの違いは以下です。MonoとFluxController/Serviceの代わりにFunctionTomcatよりNettyJPA/JDBCよりR2DBC新しい抽象化クラスでは、これらの違いについて、一つ一つみていきたいと思います。理論的な話非同期、ノンブロッキング、反応型Spring WebFluxはProject Reactorに基づいて作られていて、その根幹となる考え方はReactive Streamだそうです。Reactive Streamは標準APIであり、Java 9からjava.util.concurrent.Flowとして導入されています。Reactive Streamはデザインパターン的にはObserverと似ています。簡単にいうと、何かのイベントが発生した時に「通知してくれ」と頼んで、データをもらうということです。この「通知してくれ」と頼む行為のことをSubscription(購読)といい、データを発行するPublisherと購読するSubscriberの間でSubscriptionのやり取りで行われます。こういうイベント基盤のプログラムを作ることが、いわゆる「反応型」だそうです。そしてReactive StreamではこのSubscriptionのやり取りが、非同期・ノンブロッキングで行われるらしいです。ということは、コードが実行された時点か終わるまでまつ必要がなく、その間に他のことができるということです。なので同じ数の同じタスクを実行するときは同期・ブロッキングと比べあまり性能面での違いはないのですが1、スレッド数がボトルネックとなる場合だと、非同期・ノンブロキングの方が早くなります。理論的な話は、深くまで踏み入るとキリが無くなるので、実際のコードではどんな違いがあるのか？をみていきましょう。コードのレベルでの話MonoとFluxSpring WebFluxだと、コントローラのメソッドに戻り値(レスポンス)としてMonoとFluxを使うということです。Spirng MVCなら、文字列でJSPファイルを指定したり、REST APIならJSONとして返すオブジェクトを指定していましたね。もちろんMonoとFluxもJSONオブジェクトとして出力されるのですが、作り方が少し独特です。Spring WebFluxの根幹となる考え方がReactive Streamであると先に述べましたね。そしてReactive StreamをWebFlux側で実装したものが、MonoとFluxになります。Monoは0か1か、Fluxは0かNかの違いだそうですが、必ずしもCollection=Fluxにする必要はなくて、Monoとして扱うこともできます。Reactive Streamは、名前からしてJava 1.8のStream APIとなんらかの関係があるようにも見えます。実際、データの作成と消費の時点が違うのですが2、似たような名のメソッドや、Lambdaで完成していくところは似ています。すでにRxJavaやJOOLなどに慣れているなら、書き方的にはまあり問題なく適応できそうですが、そうでない方には適応が難しいかもしれません。例えば、GETで、リクエストを受けたら1秒後にレスポンスを返す簡単なメソッドを実装するとしましょう。Spring MVCによるREST APIだと、以下のようになるでしょう。@GetMapping@ResponseStatus(HttpStatus.OK)public String getTest() { try { Thread.sleep(1000); return "task completed by mvc"; } catch (InterruptedException e) { return "task failed by mvc"; }}WebFluxでは、以下のようにMonoを作成して返します。@GetMapping@ResponseStatus(HttpStatus.OK)public Mono<String> getTest() { return Mono.delay(Duration.ofMillis(1000)).then(Mono.just("task completed by Mono"));}最近はなんでも宣言的な言語やフレームワークなどが増えているので(例えばFlutterやSwiftUIがそんな感じですね)、こういう書き方は珍しくもないですが、伝統的な命令型プログラミングに慣れている方には少し辛い書き方になるかもしれません。私自身も、StreamやLambdaは好きなものの、ネストしていく命令型とメソッドチェインで長くなる宣言型のどちらがいいか確信がないです…Controller/Serviceの代わりにFunctionWebFluxのコード上でのもう一つの特徴は、ControllerとServiceの代替となるクラスを作ることができるということです。もちろん従来通りControllerとServiceクラスを利用することもできますが、どうせなら新しいものが使ってみたくなりますね。SpringでController/Serviceを作るということは、つまりアノテーションによる「メタプログラミング」に依存して開発するというです。確かにアノテーションは便利であって、Springではアノテーションでなんでもできるような感じもしますね。しかし、アノテーションによる開発では以下のような問題があります。コンパイラで検証できないコードの行為を規定しない継承、拡張のルールに標準がない理解できない、誤解しやすいコードをを生み出す可能性があるテストが極めて難しいカスタマイズが難しいなぜかというと、アノテーションを使うということは結局Reflectionに依存するということになるからです。Reflectionを使っているとランタイムでバイトコードが生成されてしまうので、コンパイルタイムにできることがあまりないですね。Reflectionは確かに強力な道具ですが、他にも問題はあります。例えばパフォーマンスは低下し、デバッグも難しいです。こういう問題があるのでJavaのコードをネイティブにコンパイルしてくれるというGraalVMではReflectionに対応していないのかもしれないですね。とにかく、このような問題を解決するためにWebFluxで新しく導入されたのは、Functionです。はい、言葉通り、関数です。既存のControllerに対応するRouterとServiceに対応するHandlerを作り、関数型モデルとして(Functinalに)コードを書くことができます。もちろんFunctionalに書くとしても、アノテーションは使えます(むしろアノテーションなしではだめです…)。例えば以下のような書き方になります。@Configurationpublic class Router { @Bean public RouterFunction<ServerResponse> route(final Handler handler) { return nest( path("/api/v1/web/members"), RouterFunctions.route(GET("/"), handler::listMember) .andRoute(POST("/"), handler::createMember) ); }}@Componentpublic class Handler { private final MemberRepository repository; @Autowired public Handler(final MemberRepository repository) { this.repository = repository; } public Mono<ServerResponse> listMember(final ServerRequest request) { return ok() .contentType(MediaType.APPLICATION_JSON) .body(Flux.fromIterable(repository.findAll()), Member.class); } public Mono<ServerResponse> createMember(final ServerRequest request) { return ok() .contentType(MediaType.APPLICATION_JSON) .body(request.bodyToMono(Member.class) .flatMap(member -> Mono.fromCallable(() -> repository.save(member)) .then(Mono.just(member))), Member.class); }}関数型になってわかりやすくなったような、難しくなったような…TomcatよりNettySpring WebFluxのデフォルトのアプリケーションサーバはNettyです。簡単に推論できる理由ですが、Nettyの方が最初からノンブロッキングという考え方に基づいて作られているからでしょう。Tomcatはもちろん同期、ブロッキングなので、Nettyと比較すると以下のような違いがあるらしいです。Tomcat：リクエストとスレッドは1:1Netty：リクエストとスレッドはN:1もちろん、Spring MVCみたいにNettyの代わりにTomcatを使うこともできます。例えばGradleでは以下のような書きます。dependencies { implementation('org.springframework.boot:spring-boot-starter-webflux:2.3.3.RELEASE') { exclude group: 'org.springframework.boot', module: 'spring-boot-starter-reactor-netty' } implementation('org.springframework.boot:spring-boot-starter-tomcat:2.3.3.RELEASE')}JPA/JDBCよりR2DBCこれもアプリケーションサーバと同じような話です。JPA/JDBCなど、従来のORMはブロッキングなのでノンブロッキングに対応するR2DBCに変えましょう、ということです。NIOがそうであったように、ブロッキングでもR2DBCを使うと場合によってはパフォーマンスの向上を図ることもできるらしいです。新しい抽象化クラスWebFluxでは、Spring MVCで使っていた抽象化クラスも変わっています。これも同じく、関数型としての書き方とノンブロッキングに対応するためですね。種別Spring MVCSpring WebFluxリクエストHttpServletRequestServerHttpRequestレスポンスHttpServletResponseServerHttpResponse他のAPIをコールRestTemplateWebClientWebClientの場合は、RestTemplateがdeprecatedに変更されるので、Spring MVCを使う場合でも導入を考える必要はあります。実際Spring MVCで使う場合でもResttemplateに比べてパフォーマンスが向上される場合もあると言われています。どこに使えばいい？さて、さっくりWebFluxの特徴をみてみましたが、どうでしょうか。書き方もかなり違っていて、Servlet基盤のMVCとは全く違うReactorに基盤しているので、Spring WebFluxの導入はかなり悩ましいことです。実際Spring MVCと同時に使うこともできず(無理矢理Dependencyを追加しても、MVCが優先され、WebFluxの機能は動作しなかったりもします)、Spring Securityなど他のフレームワークもSpring WebFluxのために作りなおったものに変えなくては行けないので、既存のシステムやSpring MVCに基づいて整備したライブラリなどがたくさんある場合はその影響範囲が測定できません。そして性能面でも、ノンブロッキングが強いのは、「指定されたスレッド数を超えるリクエストがある場合」という条件下の話です。ノンブロッキングに変えたからって、単一スレッドでの性能が上がるわけでもないということですね。3ただし、以下のような場合はWebFluxの導入を考えられます。完全新規サービスをはなから作る複数のサービスがあり、サービス同士での呼び出しが多い場合(マイクロサービス)BFF4の場合最後に簡単に整理しようとしていた内容が、いつの間にかかなり長くなりましたが…おかげで色々と勉強はできたと思います。WebFluxが登場してからもすでに数年が経っていて、RestTemplateがdeprecatedになる予定であるように、究極的には全体をWebFlux基盤に移行する必要が生じる日がいつか来るかもしれません。なんでも最近は非同期、関数型、反応型というキーワードがすごく流行っていますし。静的タイプの言語が最初に生まれて、動的タイプの言語も生まれ、TypeScriptのように静的な世界にまた戻るような現象が起きているのを見ると、また関数型から命令型に移行する日もいつか来る可能性があるのかな、と思ったりもします。ただ、こういうパラダイムはどれが絶対というわけではないので、優秀なプログラマならどれも適時適切に使いこなせるようにならないと、という気もします。エンジニアとしての勉強の道は本当に終わりがないですね。実際は、スレッド数によるボトルネックのない状態だと、関数型の方が少し遅いらしいです。実際は関数型のAPIの実装の方が複雑だからですね。ただ、この違いはコードの読みやすさや実装のしやすさなどを考慮した時は、十分トレードオフとして考慮できるくらいの差のようです。 ↩︎Streamは同期なので、データを生産と消費が一緒に行われます。しかし、Reactive Streamではデータの生産がすぐ消費までつながるとは言い切れません。非同期だからです。 ↩︎むしろ、単一スレッドでの処理は、WebFluxの方がMVCに比べ少し遅いという話もあります。forループに比べStreamが遅い理由と似ているような気がしますが… ↩︎Back-end For Front-endの略。マイクロサービスの一種で、複数のエンドポイントをまとめて固有のオブジェクトを生み出すバックエンド。フロントエンドは一つのエンドポイントを呼び出すだけでことが済みます。 ↩︎

Spring WebFluxって何？

今更な話ですが、主にバックエンドの仕事をしてきたエンジニアとしては(特に、Springが全てを占拠してしまったJavaがメインな立場からは)、昨今のフロントエンドの世界を見ていると、一瞬よそ見しただけでもすぐに時代遅れな人間になってしまうような気になります。それだけさまざまなライブラリ、フレームワーク、設計思想、プラットフォームが現れ消えていくので、これからどれを学んでおくべきかわからなくなります。例えばアプリの設計思想だと、SPA1がトレンドになっているものの、WASMの登場でPWA2も登場し始めています。JavaScriptのフレームワークでは、「Virtual DOMを使用するので早い」という、Angular・React・Vue.jsが今の通称「3強」となっていますが、「DOMを直接更新するから早い」というSvelteもあります。Node.jsは失敗したというDenoが登場しているし、今のTypeScriptの位置を目指したが失敗したと思われたDartは、FlutterやFuchsiaで再起できているようにも見えますね。このように、フロントエンド系は新しい概念と技術の氾濫で混乱な状況ですが、面白くも、トレンドと逆行するような形のWebアプリ、いや、Webサイトの構築に関する概念もそれなりの割合を示しているように見えます。本日のポストのテーマである、「静的ウェブページ」です。静的ウェブページ(Static Web Page)とは「静的」であるということは、「動的」と区分される特徴があるということでしょう。ここでいう動的か静的かというのは、入力によって何かの処理が行われるか、もしくは常にサーバに保存されたデータをそのまま返すかががもっとも重要な基準となっているようです。例えばWikipediaでは以下のように定義しています。A static web page (sometimes called a flat page or a stationary page) is a web page that is delivered to the user’s web browser exactly as stored, in contrast to dynamic web pages which are generated by a web application.言い方を変えると、サイトが「アプリケーション」として作られたものならば動的、もしくはただの固定されたデータを表示するための「ページ」であるなら静的といえますね。なぜ今更？サーバに保存されたデータをそのまま返すという概念は、 Webアプリケーションが登場する前から存在していました。当時のウェブサイトはhtmlとcss、イメージなどのリソースをFTPなどでサーバにアップロードしてホスティングを行っていたのですが、これは今の静的ウェブページにとっても同じ方式です。つまり、概念だけを見ると静的ウェブページは昔に流行っていた「ホームページ」や「ブログ」などに近いものです。時代に逆行するような、静的ウェブページが今更注目されるのは、なぜか。当たり前ながら、当時とは違って、JavaScriptの発展によりサーバに依存しなくても簡単な処理はブラウザでできるようにもなり、適切なAPIがあればバックエンドを実装する必要がなくなるのもあり、AWS LambdaやAzure Functionsのようなサービスによりサーバレスができる環境ができるなど、バックエンドよりはフロントエンドの目的によって選択できる方法が多くなったという点があるでしょう。そして、もっとも根本的な、サイトの目的がありますね。ブログ、ポートフォリオ、イベント案内などそもそも「大した処理が必要ない」サイトに関しては、静的にしたほうがリソース使用、費用、パフォーマンス、セキュリティという面で動的ウェブページより有利です。例えば今このブログみたいにですね。最近はMarkdownなどで文書を書くと、それを元に静的ウェブページを作成してくれるツールもたくさんあり、そのようなツールで生成したデータを載せるだけでホスティングする方法も多いです。自分でソースを管理できて、簡単にホスティングできるのである意味ではもっとも静的ウェブページを作り安い時代となったとも言えますね。静的ウェブページを作られるツール多くの場合、静的ウェブサイトの生成ツールの使用は難しくありません。ベースになっている言語の実行環境を構築して、テンプレートをダウンロードして適用するか、作っていくかなのですが、ツールを実行するための環境の構築はツールのホームページの手順通りでよく、テンプレートも人の作っておいたものを持ってきて少し修正するくらいです。簡単な修正なら、HTML、CSS、JSON、YAMLくらいのファイルをいじるだけなので(プロパティファイルで色々なオプションを選択できる例もあります)、難しくありません。あとはMarkdownなどで記事を書いていくだけですね。ただ、自分の経験からだと、既製のテンプレートを大きく変えるか、最初から作り直す場合は自分が触ることのできる言語をベースにしておいた方が良いということですね。例えばこのブログはJekyllで作られていて、テンプレートも一部修正していますが、そもそも私はRubyに慣れてないので根本的な部分を修正してはいないところです。Jekyll以外には、Nodejs基盤のツールが多いようです。例えばMetalsmithや、Hexoのような物があって、React基盤のGatsby、Vue.js基盤のVuePressもあります。JavaScriptとそのフレームワークの使用に慣れているなら、こちらがいいかもしれませんね。他には、Go言語基盤のHugoもありますので、Goに慣れている方ならこちらを選択することもありですね。静的ウェブページを載せられるプラットフォームツールを使って、静的サイトを作ったら、次はホスティングが必要となりますね。静的ウェブページのホスティングの場合、このブログでも使用しているGitHub Pagesやnetlifyのようなサービスがあり、データをGitなどでアップロードすると自動でビルドとデプロイが完了される便利さがあります。他にはクラウドを利用する方法があります。AWSやAzure、Google Cloud Platformのようなクラウドサービスには、S3やBlobのようにウェブからアクセスできるストレージサービスが必ずありますが、このストレージにツールで作成した静的サイトをアップロードしてホスティングする方法もあります。特にGoogleのサービスの場合、Google Firebaseというアプリ開発に特化したプラットフォームもあるのでAPIとの連携が必要な場合は考慮できる候補ではないかと思います。最後にここでは単にツールとプラットフォームを紹介(というより、言及)しただけですが、静的ウェブページでできることや活用できるものは、他にも多いようです。同じ静的ウェブページだとしても、どのような技術の組み合わせでどのような物が作り上げられるかがかなり変わってくるのですが、実際にどんな物ができるかはJAMstackのExamplesタブから色々発見できますので、参考にしてみてください。個人的にはGatsbyに興味があって、Reactの勉強のついでに、いつかポートフォリオのためのサイトをそれで作り上げてみようかなと思っています。Oracleクラウドだと無料のVMやDBも提供されるので、簡単なAPIを作成しておくのも可能になるかもしれませんね。いや、いい時代になったものです。皆さんもぜひ、静的ウェブページで自分だけのサイトを築き上げてみてください。Single Page Applicationの略で、従来のWebアプリケーションが複数の画面で構成されていたことに対して、画面を一つにして開発の効率やパフォーマンスの向上を図ったWebアプリケーションのこと。画面がサーバサイドと分離されているため、バックエンドとして選択できるものの幅が広いという特徴もあります。 ↩︎Progressive Web Applicationの略で、Webアプリでありながらもネイティブアプリならではのメリット(パフォーマンスが高い、インストールすることでオフラインでも利用可能)を採用したアプリケーションのことを指します。 ↩︎

静的ウェブページに興味を持つ

前回、JWTとともにSpring Securityでの実現方法についてポストを書きましたが、JWTを使ってAccess Tokenのみを発行した場合は、考えられる脆弱性があるらしいです。なので今回は、Access Tokenのみを使う認証の特徴と問題点及びそれを補完するための技術を紹介したいと思います。そもそもJWTを使った認証認可は、JWTがISO標準ではあるものの、正解と言った実装方式がないらしいです。なので以下で紹介するAccess Tokenのみの発行に伴う問題と、それを補完するための戦略は概念だけを紹介して行きます。Access TokenAccess Tokenのみを使う場合は、最初の認証以降、サーバでは秘密キーを利用してリクエストに載せられたTokenを確認するため、データベースやストレージなどのI/Oが必要なくなるため高速で処理ができます。ただ、Tokenはリクエストを送るクライアント側が持っているため、強制的にセッションを終了させることができません。なので、ログアウトの処理をするためにはクライアント側からToken情報を削除するしかないですね。Access Tokenを使った認証方式はこういう特徴を持っているため、クライアント側がTokenを持っているため、これをもし第三者に乗っ取られた時はサーバサイドからそれを判断できる術がありません。こういう問題を防ぐため、Tokenを発行する際はあらかじめ期限を設定することで、一定の時間がすぎるとTokenの有効期間が満了するようにして、再利用できなくしています。Tokenの期限設定のジレンマTokenの期限をあらかじめ設定する場合、有効期限をどう設定するかの問題があります。短くした場合は、Tokenを乗っ取られた場合でもすぐにTokenを使えなくなるため安全性を担保できますが、逆にユーザは頻繁にログインし直さないと行けなくなります。逆に長くした場合は、ユーザはログインし直さなくてもサービスを長期間利用できるものの、乗っ取られたTokenも長く使えるようになりますね。Refresh TokenRefresh Tokenは、満了したAccess Tokenの有効期限を更新するための別のTokenです。サーバは認証時にクライアント側にAccess TokenとRefresh Tokenをともに発行します。ここでAccess Tokenの期限は30分くらいの短い期間に設定して、Refresh Tokenは1ヶ月ほどの長い期間に設定します。クライアント側でログイン後に30分がすぎて、Access Tokenの期限が満了した場合にRefresh Tokenでサーバに新しいAccess Tokenの発行を依頼します。サーバはクライアントのリクエストに乗ってあるRefresh Tokenを検証し、問題なければAccess Tokenを再発行します。これでAccess Tokenを乗っ取られたも、すぐに満了し、ユーザはRefresh Tokenを持って有効期限の自動更新ができるので毎回ログインする必要がなくなります。また、サーバサイドでRefresh Tokenを検証するデータを持っているので、もし問題がある場合はRefresh Tokenを満了させることもできます。ただ、Refresh Tokenを使った場合でも完璧では言えません。サーバが検証するためにRefresh Tokenに対応するデータを別のデータベースやストレージに保存する必要があるので、追加的なI/Oが発生し得るという問題はあります。また、Refresh Tokenを用いたAccess Tokenの更新のためにはサーバとクライアント側の両方に機能を追加する必要がありますね。あと、Access Tokenと同様にクライアント側がRefresh Tokenを保存する必要があるのでこれをどう保存するかを考える必要があります。Sliding SessionSliding Sessionは、セッションを継続して利用しているユーザがいる場合、自動でAccess Tokenを更新してくれる仕組みのことです。リクエストごとに新しいAccess Tokenを発行する方法がありますが、特定のリクエストに限って処理する方法もあります。例えば、ユーザが長い時間を送ると予想されるページ(問い合わせの作成)や、次に何かのアクションが予想されるページ(ショッピングカートにアイテムを追加する)の場合があるでしょう。他には、Access TokenのIAT(トークン発行時間)を確認して新しいAccess Tokenの発行を要請する場合もあるらしいですね。ただ、Sliding SessionでAccess Tokenを更新する場合、そもそもの有効期限が長く設定されていると無限に近くセッションが延長され、ユーザが全くログインしなおさなくてもサービスを利用できることになるので注意が必要です。逆に、ユーザがあまり長い時間の作業を行わない場合はSliding Sessionそのものの必要性がなくなる可能性もあります。Refresh Token + Sliding Session最後は、Refresh TokenとSliding Sessionを同時に使った方法です。普通のSliding Sessionを適用した方法との違いは、Access TokenではなくRefresh Tokenを更新するということです。Refresh Tokenを更新することにより、Access Tokenを頻繁に更新する必要がなくなります。またRefresh Tokenが更新されるためアクセス回数の少ないユーザでも比較的ログインを頻繁にする必要がなくなりますね。Refresh TokenとSliding Sessionのメリットを適切に融合させた戦略と言えます。ただ、この方式でも問題が全くないとは言えません。サーバからRefresh Tokenの有効期限を満了させない限り、ユーザはリソースにアクセスできるので、もしPCやスマホなどの機器が乗っ取られた場合は対応できません。なのでアカウントのパスワードを周期的にリセットさせるか、特定のリソースにアクセスする場合は再び認証させるなどの方法が必要となります。最後に認証はWebアプリケーションにとってもっとも重要で、当たり前な機能となっていますが、セキュリティのため強化して行くとユーザの使用性に悪影響が出てしまうという問題を持っているものです。なので色々な方法論があり、さまざまなWebアプリケーションではそれぞれ違う方法を使って脆弱性に対応していますが、どれもメリット・デメリットがあるので正解と言える物はないのかもしれません。また、JWTのPayloadは暗号化されないため(ただのbase64文字列)、JWTを乗っ取られた時にその中身を見れるという問題もあるらしいです。これを補完するためにPASETOという物も提案されているらしいですが、これがまたJWTほど亜補給される稼働かはわからない状態ですね。あと、そもそもの認証方式の問題ですが、量子コンピュータが一般に補給されたら、従来の方式による暗号の解析はすぐにできるようになるとも言われているので、暗号化という考え方そのものが変わる可能性もあるかもしれません。そうなると既存のアプリも全体を作り直さなくてはならないことになるでしょう。セキュリティは難しいものです。暗号化とともに、ユーザが便利に使える設計、戦略を適切に選定するためには色々と工夫が必要と感じます。

JWTの補完：Refresh TokenとSliding Session

よく訪問しているサイトに、とある質問がありました。質問の内容とは、List二つを、重複する要素なしで一つにまとめる方法ということでした。SQLなら簡単に解決できそうな問題でもありますが、クエリーを修正できない状態だったり、複数のAPIを呼び出してその戻り値を扱う場合は直接コードを書いて併合するしかないですね。今まであまり経験したことのない状況でしたが、個人的にも興味が沸いたのでいろいろ試しながらコードを書いてみました。問題のコード質問の作成者がやりたいことは、List<Map<String, Object>>が二つあり、Listの中のMapの要素を確認し、重複する物があれば一つのListとしてまとめたいということです。ここで重複の条件は、MapのKeyとValueでした。今はコードは存在するものの、重複チェックのためのロジックが複雑になりすぎて、負荷も高く性能面でも問題があるらしいです。まず彼の後悔しているコードは、以下のようなものでした。List<Object> list1 = ...List<Object> list2 = ...for (Object object : list1) { Map<String, String> map = (HashMap<String, String>) object; String a1 = map.get("a"); for (Object object2 : list2) { Map<String, String> map2 = (HashMap<String, String>) object2; String a2 = map2.get("a"); if (a1.equals(a2)) { Set<String> keys = map2.keySet(); for (String key : keys) { String v = map2.get(key); map.put(key, v); } } }}コードをみると、3重ループになっていて、KeyとValueが一致する項目がないかを一つ一つチェックしています。そして実際のコードなのかよくわかりませんが、このコードだとキーがリテラルになっているので全体のキーを循環できるようなループがまた追加されるべきではないかと思います。そうするとまたループが追加されたりして、より複雑なコードになりそうですね。これをListの個数分回すとしたら、それは負荷が多いだろうなと思います。なのでこれをなるべく短く、より単純なコードにしてみたいと思います。Best Practiceではないのかもしれませんが、ひとまず自分の考えてコードを紹介します。Streamを使ってみるListの要素を一つづつ処理したい場合は、まずStreamを使う方法がないかをまず考えてみました。ネットで調べてみるとやはりStreamを使って複数のListをマージする方法がいくつかあります。それらを使って検証してみました。結合と重複の除外Stream.concat()を使うと、二つのStreamをつなげることができます。また、Streamではdistinct()で重複を除外することができます。これらの組み合わせを使うと、二つのListを重複する要素なしで結合することができます。まず簡単な例題を使うと以下のようなコードになります。// 結合したいListList<String> list1 = List.of("a", "b", "d", "e");List<String> list2 = List.of("b", "c", "d", "f");// 結合と重複の除外("a", "b", "c", "d", "e", "f")List<String> concat = Stream.concat(list1.stream(), list2.stream()).distinct().collect(Collectors.toList());Stream.concat()の引数は二つしか指定できないので、3つ以上のListを繋ぐ場合はループを使うのを考慮すると良いです。また、distinct()の場合、equals()がちゃんと定義されてあるという前提ならどんなオブジェクトでも重複検査ができます。なのでLombokの@Dataのようなアノテーションのついたクラスでも重複を除外して一つのListに納めることができます。限界質問の作成者は、Listの中のMapの要素に対して重複チェックを行いたいと行っていますが、この方法ではそのようにはなりません。なぜなら、Mapそのものをequals()で比較してしまい、中の要素一つ一つに対してはチェックしない構造となっているからです。なのでこのようなコードだと、二つのListを繋いだような物ができてしまうだけです。Forループを使ってみる今回は質問者のコードを直して、より効率的に変えてみます。あえてForループを使っているのは、条件に一致した場合に一回だけput()を実行するためです。StreamやforEach()は全ての要素に対して処理を行うためのものなので、除きました。Mapにはput()以外でもputAll()があるので、要素を巡回しながら一つづつ一つでもループは消すことができます。そしてputAll()を実行したら、次の要素までチェックする必要はなくなるのでcontinueを実行して次のループは飛ばすようにして、無駄な処理を無くします。そうするとまず以下のようにコードを帰ることができますね。for (Object object : list1) { Map<String, String> map = (HashMap<String, String>) object; String a1 = map.get("a"); for (Object object2 : list2) { Map<String, String> map2 = (HashMap<String, String>) object2; String a2 = map2.get("a"); if (a1.equals(a2)) { // ループを一回無くす map.putAll(map2); continue; } }}ここで、MapのKeyを指定しているところも直します。リテラルで指定しなく、Entryを巡回しながら比較することにするのでループは一つ増えます。そして、EntryはSetで取得できるので、Collectionのメソッドであるcontains()を使って比較することができます。なので比較したいMapのうち、どちらかのEntryを巡回しながら要素が違う方のMapに入っているのかを確認するだけで良いですね。これを反映して直したコードが以下です。for (Object object : list1) { Map<String, String> map = (HashMap<String, String>) object; for (Object object2 : list2) { Map<String, String> map2 = (HashMap<String, String>) object2; // Entryで比較する for (Map.Entry<String, DataClass> entry : map2.entrySet()) { if (map1.entrySet().contains(entry)) { map1.putAll(map02); continue; } } }}あとは最初からあらかじめListの型変換をして、ループ毎に型変換をしないようにすることですね。あまりこれで性能の改善は期待できないのかもしれませんが…// あらかじめ型変換をしておくList<Map<String, String>> convertedList1 = (List<Map<String, String>>) list1;List<Map<String, String>> convertedList2 = (List<Map<String, String>>) list2;for (Map<String, String> map : convertedList1) { for (Map<String, String> map2 : convertedList2) { for (Map.Entry<String, DataClass> entry : map2.entrySet()) { if (map1.entrySet().contains(entry)) { map1.putAll(map02); continue; } } }}あとは場合によってMapのKeyをソートするなどの処理が必要になるかもですが、一旦これで要件は満たしたような気がします。条件が違う場合質問者のコードからは、推論するしかないことですが、もしListのインデックスを基準に比較するという条件があるとしたら、コードはより減らすことができます。list1とlist2の同じインデックスに、同じ要素を持つMapがあるかを確認するということです。もしこの条件があるとしたら、ループは2重に納めることができます。以下はその場合のコードです。for (Map<String, String> map : list1) { for (Map.Entry<String, String> entry : map.entrySet()) { // List2と同じインデックスを比較する Map<String, String> map2 = list2.get(list1.indexOf(map)); if (map2.entrySet().contains(entry)) { map.putAll(map2); continue; } }}ただ、この方法を使うためには二つのListが同じサイズを持っているという前提が必要となるのでそこには気をつけなくではならなくなります。最後にたまにこうやって、自分ではまだ遭遇していない場合に対して考えられるチャンスとなるので、コミュニティに注目するのは良い経験となると思います。調べている間に普段は使ってみたことのないメソッドやAPIを調べてみたり、自分が書いていたコードを振り返ってみる良い機会にもなりますね。他にもKeyは構わなく、重複するValueがある場合のみチェックするとか、要素のフィールドが重複している場合をチェックするかなどさまざまなバリエーションを考えられると思います。どれも面白い主題なのですが、今回の主題とは少し乖離があるため、機会があればいつかそのようなケースに対してのコードもブログに載せたいと思います。では、また！

二つのListを結合する

個人的に、クエリーやDBのプラグインなど、DBそのものによるデータの整形はあまりよくないと思っていて、なんからの「処理」が入る場合にSQL文はなるべく最低限のCRUDに制限し、必要な作業は全てアプリにて処理するような実装をしたほうが設計として望ましい形だと思っています。なぜかというと、システム全体の性能、アプリのDBに対しての独立性、処理の容易さという観点からそちらの方が優れていると思っているからです。まず性能ですが、DBサーバとAPサーバが物理的に同じ性能のマシンを使っているとしたら、実際は最適化されたクエリーでパフォーマンスをあげることは十分できますね。しかし、処理すべきデータやリクエストが増えると必ずしもそうとは言えません。Webアプリケーションでユーザ数が増えるとスケールアウト1やスケールアップ2を考慮することになりますが、スケールアウトする場合の場合にDBへの依存が強いアプリは問題を起こす可能性があります。APサーバは複数を利用してもアプリの動作には変わりがありませんが、DBサーバの場合は台数が増えるとデータの整合性という新しい問題が出てきますね。どのDBにも同じデータが保存されていることを保証したいなら、DBサーバをスケールアウトするよりはAPサーバをスケールアウトした方が良いと思います。なのでこの場合はアプリにデータの「処理」を任せた方が望ましいですね。次にアプリのDBに対しての独立性ですが、最近は費用の高いOralceから無料のPostgreSQLやMySQLに移行するシステムも増えてきていますね。しかし、ここでDBのクエリーやプラグインに依存した部分が多ければ多いほど移行は難しくなる可能性があります。微妙に違うカラムのデータ型から、互換性のないクエリーや機能などを全面的に検討する必要がありますね。なのでSQL文はなるべく単純にした方が、移植生が上がります。最後に、処理の容易さなのですが、現在DBの主流であるRDBSの場合は、徹底的にデータをいかに効率的に保存するかが最も重要な課題となっているものです。正規化を終えたテーブル構造は、データを加工するには適合していません。なのでアプリでは必要に応じてエンティティを作って使いますが、そのエンティティに合わせてSQLを書く際はまた複雑なJoinやWhereなどを描かなければならなくなりますね。エンティティの中に他のエンティティがま他入っていたりする場合はJoinをするか、しないかのケースまで考えてクエリーを描かなければなりません。このような理由からして、自分はなるべく複雑なクエリーを排除し、なるべくアプリ中心的に開発できる方法はないかと思っていました。初めはJDBCに触れ、そのあとはMyBatisを使うようになっていましたが、MyBatisを使ってもケース別にクエリーを書く必要があるのはまた同じでした。(プラスで、xmlが必要となることもありますね)最近はテレワークにより通勤時間がなくなり、仕事が終わった後は勉強をかねて自作アプリを実装していますが、ここでより簡単に、またよりアプリに優しいDBのAPIがないかと思っていましたが、そこで発見したのがJPAでした。JPAとはJPAはJava Persistence APIの略で、Javaが提供する標準APIです。ただ、標準APIだとしても、Interfaceとして定義しているだけなので、これを実装したものが必要となります。JPAを実装したものとして有名なのがHibernateで、これをさらに使いやすく整理したモジュールとしてSpring Data JPAが存在しています。だいぶ序論が長くなりましたが、結論的に今回言いたいことが何かというと、Spring Data JPAを使うと他のライブラリやフレームワークを使うよりも楽に開発ができるということです。おそらくSQL中心的な開発に関しては自分と同じようなことを考えていた人が他にもいたらしく、JPAは単純なクエリーを自動で作ってくれたり、自動でテーブルのJoinをしてくれるなど全くSQLに触れなくてもDBを扱うことを可能にしてくれています。同じくORMとしてよく使われているMyBatisに比べても、JPAを使った方がより効率的なのではないかな、と個人的には考えています。その理由からか、海外では他のORMよりもJPAを使っている割合の方が圧倒的に高いようでした。なのでもし今もMyBatisを使っている方がいらっしゃるなら、ぜひJPAを一度は使ってみて欲しいところです。では、実際にJPA(Spring Data JPA)の特徴と使用法を、一つづつ紹介しましょう。JPAの特徴まずはJPAの特徴です。正確には特徴というよりは、JPAを使う場合のメリットに近いのではないかと思います。自動グラフ探索まず、このようなクラスがあるとします。class Team { private long id; private String name;}そしてチームには所属された選手がいます。class Player { private long id; private String name; private Team team;}既存のSQLでこの選手オブジェクトをDBから照会する場合は、以下の手順が必要となります。TeamテーブルをSelectするTeamオブジェクトにSelectしたデータを埋め込むPlayerテーブルをSelectするPlayerオブジェクトにSelectしたデータを埋め込むPlayerオブジェクトにTeamオブジェクトをセットするこの手順は、テーブルのJoinが多くなればなるほど増えます。また、SQLもさらに長くなりますね。例えばTeamクラスにRegionというクラスがフィールドとして入り、RegionにはさらにCountryというクラスが入るとしたら？それぞれのテーブルを照会してJoinするようなクエリーを作る必要があって、またオブジェクトも全部マッピングする必要がありますね。もしこの手順に何らかの抜け漏れなどがあったら、コードは思い通りに作動しないはずです。JPAでは、このような参照関係を自動で解決してくれます。例えば、何もしなくても以下のようなことが可能です。// RepositoryからPlayerオブジェクトを取得するPlayer player = repository.findById(1);// Playerが所属したTeamを取得するTeam team = player.getTeam();性能の最適化自動的にグラフ探索をしてくれるところをみると、まさかPlayerテーブルを照会するたびにTeamテーブルも照会しているような無駄なことをしているわけではないか、と思われそうですが、実際はLazy Loadingにより、TeamはgetTeam()を実行した時点でまたのSelect文を発行して照会していることになります。なので、Playerだけの情報が必要な場合はその情報しか照会しないことになります。では、場合によっては数回もトランザクションが発生するのではないか、という疑問もあり得ると思いますが、これをJPAではキャッシュとバッチ、フェッチタイプの指定で解決しているようです。これらは以下のように作動します。キャッシュ：同じエンティティに対して(同一トランザクションならば)2回目以降のSelectはキャッシュから照会するバッチ：バッチメソッドを提供し、一回のコミットで複数のクエリを転送する機能を実装しているフェッチタイプ：アノテーションによりLazy Loadingをするか、最初からJoinして照会するかを選択可能自動クエリ生成先にRepositoryからオブジェクトを取得する例を照会しましたが、これが可能になるのはJPAが自動的に生成してくれるクエリーがあるからです。JPAが提供するアノテーションやインタフェースを使うとこで、自動生成されるクエリーを利用することができます。つまり、エンティティとして利用するクラスとJPAをアノテーションとインタフェースに紐づけておくといちいちクエリーを作成してオブジェクトにマッピングする必要がなくなるということです。もちろん自作クエリーを使うこともできるので、自動生成されるクエリーを使いたい場合も問題ないです。このクエリーの生成は、エンティティのCRUDだけに限ることではありません。エンティティに変更が生じた場合(フィールドを追加する必要がある場合)は、DDLも自動的に作成してくれます。ここで自動生成されるDDLをDrop-Createにするか、AlterにするかはアプリケーションプロパティのHibernate設定でできます。JPAの使用法では、実際のJPAをコードとしてはどう使えるかをみていきましょう。EntityJPAでは、エンティティとそのフィールド(テーブルのカラムや参照関係)をアノテーションによって簡単に定義することができます。例えば以下のようになります。// Entityとして指定する@Entityclass Car { // 自動的に増加するPK @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private long id; // UniqueかつNonNull設定 @Column(nullable = false, unique = true) private String name; // Companyとは多対一の関係 @ManyToOne @JoinColumn(name = "company_id") private Company company; // Insuranceとは一対多の関係で、Lazy Loadingをする @OneToMany(fetch = FetchType.LAZY) @JoinColumn(name = "insurances_id") private List<Insurance> insurances;}こうやってEntityにはGetter・Setterをつけておくことで、Selectした時点でこのクラスに紐づくCompanyはInsuranceのようなテーブルの情報も参照できるようになります。RepositoryJPAでは、いくつかのRepositoryというインタフェースを提供しています。よく使われているものは、JpaRepositoryやCrudRepository、PagingAndSortingRepositoryなどがあって、それぞれ基本的に提供しているメソッドが異なります。例えばCrudRepositoryは普通にCRUDのためのメソッド(Selectに該当するfind()、Upsertに該当するsave()、Deleteに該当するdelete()など)を基本的に提供していて、PagingAndSortingRepositoryの場合はページング(ページネーション)に対応したメソッドを提供しているなど、基本的によく使われるメソッドが揃っています。例えば以下のようなものです。// レコードを数えるlong count = repository.count();// 全レコードを取得Iterable<Car> cars = repository.findAll();// レコードを一件取得するOptional<Car> car1 = repository.findById(1);// レコードを一件削除するrepository.delete(car2);// レコードを保存する(Upsert)Car saved = repository.save(car3);最初エンティティを定義して、それぞれのエンティティに合わせてJPAが提供するRepositoryを作成すると(extend)、そのRepositoryを使ってクエリを発行することができるようになります。また、基本的に提供しているメソッドが十分でない場合は、命名規則に従ってRepositoryに直接クエリーメソッドを書くと自動的にクエリーを作成してくれたり、@Queryアノテーションで必要なクエリーを直接書くこともできます。public interface CarRepository extends CrudRepository<Car, Long> { // nameで照会するカスタムクエリーメソッド boolean existsByName(String name); // アノテーションにクエリーを指定する場合 @Query("select c from Car c where c.name = ?1") Optional<Car> findByName(String name);}他に2018年には、Spring Data JDBCというものも発表されています。Spring Data JPAとJDBCのAPIの間にはJPA + Hibernateという階層を経由することに比べ、Spring Data JDBCは直接JDBCのAPIを呼び出すことで性能面での利点があるらしいですね。他にも実装をより単純化することでJPAの持つ問題を解消しているらしいですね。例えばキャッシュやLazy Loadingをなくしたとか(JPAのメリットとして紹介しましたが…)ただ、Spring Data JDBCは2018年にリリースされたばかりのものなので、クエリーメソッドだけでクエリーを自動生成してくれるなどの機能には対応してなかったり、テーブルやカラムの命名規則がJPAと違うなど、JPAからマイグレートするにはまだいろいろと考慮しなければならない点が多いように思われます。こういうところは、まるでNode.jsとDenoの関係みたいですね。Spring Data JDBCは自分でもあまり詳しくなく、サンプルコードをみてテストしてみただけなのですが、すでにSpring Data JPAの経験がある人ならすぐにでも適応できそうな構成となっていました。パッケージは変わってもアノテーションやインタフェースそのものの使い方が大きく変わっている訳でもないので、感覚的には大差ありません。@Entityのようなアノテーションを使う必要がなくなったというところが目立つくらいでした。なので、個人的なプロジェクトでは一度試してみるのも良いかもしれません。(エンタープライズレベルでは、まだ検証すべきところがあると思うので)また、Spring 5からReactiveなプログラミングのできるWebfluxが紹介されたことと共に、同じくNon-blockingに対応するSpring R2DBCというものも注目されているようです。既存のSpringプロジェクトにWebfluxを今すぐ導入する必要はないらしいのでSpring R2DBCも今すぐ導入する必要はないのかもしれませんが、Non-blockingによって性能を改善できる場合3は確実に存在するので、場合によっては導入を考慮する価値があるのかもしれませんね。最後に自分の場合、Springでアプリケーションを作りながらなるべくXMLを排除しJavaのコードだけで全てを管理したかったため、クエリーを自動生成してくれるというところで惹かれていましたが、実際に使ってみると使い方も簡単で(癖はあると思いますが)、テーブルが途中で変わっても簡単に直せるというところがかなり魅力的なものですね。占有率としては標準ということもあり、JPAが他のORMと比べよく使われているようですが、自分みたいにMyBatisしか扱ったことのない方には一度触れてみて損はないかと思います。JPAの他にも紹介したようにSpring Dataだけでもいろいろなライブラリが存在していてそれぞれの思想が違うので、やっと一つを少しわかったくらいではまだまだ先が遠いような気もしていますね。でもこうやって、一つのライブラリが作られた経緯や思想を調べるだけでも得られる知識は多く、どれも無駄にはならないと思われるくらい新鮮なものなので、意味のあることとなっていると思います。またこうやって情報を集めつつ、それが誰かにとっては貴重な情報になるといいですね。今後もいろいろ調べてブログに載せて行きます。では、また！サーバの台数を増やすこと。 ↩︎サーバのマシンパワーをあげること。 ↩︎スレッドプールが小さすぎたり、一つのリクエストに対して処理時間が長すぎてボトルネックになるケースなど ↩︎

MyBatisよりJPAが使いたい

常に勉強し続けなければならないのがこの業界の定めとは思いますが、変化は日々加速されていて、何に従って何を頼れば良いかわからない時もありますね。新しい言語が続々登場してくるなかでも、昔は性能の問題で注目されてなかった言語がいきなり人気を得たり、当たり前と思っていたパラダイムがひっくり返されたりもします。今はJavaScriptの時代と行っても過言ではない状況に来ていると思いますが、今後はどうなるのでしょうか。いくつか、個人的に興味をもったIT業界の動向についてまとめてみました。Apple Silicon macこないだ、Appleの開発者向けイベントである「WWDC2020」が開催されました。毎年必ずライブで見ているわけではないのですが(深夜に始まるので…)、最近はテレワークをしていて通勤時間がなくなっているのもあり、最初から最後までライブで見ることができました。iOSやiPadOS、macOSの変化ももちろん興味深かったのですが、やはり今回のイベントで最も印象的なものがなんだったかというと、macのメインプロセッサがApple製のものに変わるということでしたね。自分はPowerPC時代のmacは経験したことがありませんが、PPCからIntelへの転換は成功的だったので、今回もそうなると思います。個人的にiPadも使っているのですが、あまりIntelのCPUに比べ性能が劣るという印象は受けたこともありませんでした。もちろん、Bootcampを使えなくなることもあり、他にもx86を基盤に作られたサードパーティアプリケーションが使えなくなる可能性もあるので、新しいプロセッサのmacが今年発売したところですぐに使っているmacを買い換えるつもりはありません(高いし…)。でも、以前からLLVMやCatalystのように、違うプラットフォーム(プロセッサ)でも問題なくアプリが起動できるような環境を構築するために何年も投資しているのを見ると、意外と転換は早く、問題なくできるのではと思います。特に自分はWebアプリを書くだけなので、あまりlow levelの技術に触れることもなく、使っている言語のコンパイラが新しいプロセッサに対応してくれれば良いだけですね。実際WWDCの紹介でも、xcodeで作成したプロジェクトは再度ビルドするだけで良いと言ってました。ただ気になるのは、自分のIntel製CPUを搭載しているmacに対してのOSのサポートがいつまで続くか、くらいですかね。最近はWindowsの発展もすごいのですが、自分の環境だとあまりWindowsにこだわる必要はないので問題なく転換できそうな気もします。そしてプロセッサのみではなく、SoCなのですでにiPadやiPhoneに適用されているさまざまなセンサーやニューラルエンジンなどを使えるのも大きいメリットと思います。ただ、こういう感想はあくまで開発者としての自分の立場から考えた個人レベルの問題で、エンタプライズレベルだといくらRosetta2やUniversal Binary2が優秀だとしてもどこかで互換性や性能の問題は起こり得ると思うので要注意とは思います。Officeのデモンストレーションは、今よりもパフォーマンスが優れているように見えたのでよかったのですが、事務職の人があえてmacを使う理由はそもそもないので…他、すでに$500でA12Zを搭載したmacを借りることができるようなので、意外とすぐに新プロセッサmacの性能や互換性問題は明らかになるかもしれませんね。まずはそこに注目かな、と思っています。性能のみならず、作業時の温度や電力消費量もどれだけ改善されたか、知りたいところですね。来週あたりでベンチマークを見れるのではないかと思っています。DenoJavaScriptはあまり触ってないので、Node.jsにも詳しくないわけですが、やはり昨今のWebアプリだとNode.jsなしでは話にならない時代になっていますね。自分の場合はTypeScriptの方でJavaScriptよりも良い印象を受けたので、NodeでもネイティブなTypeScriptサポートができるといいなと思っていました。それが、Nodeの開発者によってDenoという新しいランタイムが登場したらしいです。基本的にNodeでの反省点(async/awaitのような？)から作っているもののようで、その他にも特徴としてはTypeScriptのコンパイラを内蔵していて、いちいちコンパイルしなくても(JavaScirptにトランスパイルしなくても)使えるというところが自分にとっては最大のメリットのように思われます。ただDenoの問題だと、やはり既存のNode.js用モジュールを使えない、というところと、TypeScriptのコンパイルが遅いというところがあげられています。Rustを使って自体のTypeScriptコンパイラを作るという計画があるらしいですが、いつになったら完成できるかわからないのでしばらくDenoを使ったプロジェクトはあまり発券できないかもですね。Blazor5月には「Microsoft Build 2020」にて、Blazor WebAssemblyのリリース発表がありました。これで.NETとC#による、ブラウザから実行可能なWebアプリケーションを作成できるらしいです。Node.jsを使ったWebアプリケーションのメリットとして、よく「一つの言語でサーバサイドとクライアントサイドの両方を開発できる」ことがあげられていますが、このようにJavaScriptを使わなくてもそれが可能になるようなフレームワーク＆ランタイムが登場することもあるのですね。JavaScirptも良い言語ですが、そもそもの限界が明確なので、C#のようなコンパイル言語をブラウザ上で使えるのは逆のパターン(JavaScriptをサーバサイドで使う)に比べ良いところが多いのではないかと思います。また、BlazorファミリーとしてPWAの実装ができるBlazor PWA、ElectronとWebViewでのデスクトップアプリが実装できるBlazor Hybrid、HTML要素なしでネイティブアプリが実装できるBlazor Nativeも続々登場する予定だというので、これに刺激を受け他のコンパイル言語でもブラウザで実行できるようになるのではないかと思います。WSLやGitHubもありますが、いろいろな意味で最近のMicrosoftの変化と投資はすごいものですね…Flutter for webiOSとAndroidの二つのプラットフォームのアプリを同時に開発でき、同じく機能するReact Nativeに比べ性能でもネイティブアプリに劣らないことがメリットというFlutterですが、最近Flutterを利用したWebアプリケーションも続々登場しているようです。そもそもFlutterを書くための言語であるDartが、次世代JavaScirptを目標に開発されたものなのでおかしいことではないのですが、こうやって一つの言語でモバイルとWebアプリケーションの両方を開発できるということはBlazorの場合と同じく魅力的です。ただ、Googleが開発しているというところから、DartではなくKotlinでよかったのでは？という気持ちはありますね。また、自社のサービスをすぐ見捨てる傾向のあるGoogleなのでいつまでFlutterが生き残ることができるか、ということも疑問として残っています。MicrosoftのXamarinがいまいちになっているので、モバイルだけはFlutterを採用して開発するようなこともあるのではないかと思いますが、Webアプリケーションを開発するとしたらC#を利用できるBlazorの方がより魅力的ではないかと思います。RustポストC、C++として注目されているRustですが、最近はこの言語の人気が恐ろしいほどですね。まだエンタプライズレベルでは、既存に構築しているシステムや熟練されたエンジニアがいないなどの理由でRustが使われているケースはあまりないようですが、CやC++と同等のパフォーマンスを見せながらも安定的という面が最大のメリットと言われているらしいです。個人的にはWebアプリケーションレベルであまりシステムと直接関わるようなことをする場合はないのですが、PWAの登場などWebアプリケーションでもデスクトップ並みの性能を求められることがあったり、Javaでは直接扱うことのできないバイナリファイルの扱いなどで限界を感じていたりしているので、Rustのような言語が扱えたらより良いアプリケーションを作れるようになるのでは、と思っています。特に、コミュニケーションツールとして有名なDiscordがもともと使っていたGolangをあえてRustに交替したとの記事もあったので、同じくCとC++の代替言語として開発されたGolangさえも圧倒するメリットとは一体何かという疑問が湧いてきて、ますます気になっているところです。最近人気のKotlinの場合も、おそらくJavaと完全互換できるという特徴がなかったら成功できなかったと思いますが、互換性もない言語に転換するほどRustが持っているメリットとは一体なんなのか、知りたいですね。最後にいろいろな技術と変化があり、幸せのような、プレッシャーを感じるような複雑な気持ちではありますが、どれも肯定的な変化をもたらしてくれている、と思っています。特に、各言語の変化に関してはJavaのモットーであるWrite once, run everywhereがどの言語でもより発展した形として実現されているところをみているようですね。結局どの言語も似たようなものになりつつあるような感覚もするのですが、逆にいうともうどの言語を使うかはあまり関係ない時代になりつつある気もします。なので、いったんはそのような変化についていけられるよう、自分のスキルを磨くことですね。どの言語を使うかがあまり重要ではなくなるということは、つまりその言語で何ができるかがより重要ということになると思うので、今の自分にできる言語を使ってさまざまな経験をしてみるのが優先すべきことではないかという気がします。あまり実装ができない最近ですが、個人的なプロジェクトでも進めながら経験してみたくなりました。では、また！

最近注目しているものたち

前回はREST APIでのログインの方式と、JWTを使った認証認可について説明しました。でも、アプリケーション全体のセキュリティという観点からするとログインができたということだけで全てが終わったわけではないです。例えばエラーハンドリングがありますね。Spring SerucityのConfigurationクラス(WebSecurityConfigurerAdapterの継承クラス)を作成しておいて、ロールによってアクセスできるURLをの制限をかけておくことだけで認可されてないリクエストに対してエラーを出してくれますが、カスタムクラスで独自のエラーハンドリングをしたい場合もあリますね。なので、今回はログインの以外に、REST APIでの認証認可周りで必要となるSpring Securityの設定を紹介したいと思います。ここで紹介するのは以下のようになります。ログインしてない使用者が、特定のURLにアクセスする場合のハンドリングログインしているが、特定のURLにアクセスする場合のハンドリングログインに失敗した場合のハンドリングログアウトした場合のハンドリングでは、一つづつどうやってカスタムクラスを作るのかをみていきましょう。AuthenticationEntryPointログインしていない使用者が、特定のURLにアクセスする場合のハンドリングのためには、AuthenticationEntryPointの実装が必要となります。ここではレスポンスとしてUNAUTHORIZEDを表示する例を紹介します。public class JWTAuthenticationEntryPoint implements AuthenticationEntryPoint { @Override public void commence(HttpServletRequest request, HttpServletResponse respose, AuthenticationException exception) throws IOException, ServletException { // レスポンスの設定(401 UNAUTHORIZED) response.sendError(HttpStatus.UNAUTHORIZED.value(), HttpStatus.UNAUTHORIZED.getReasonPhrase()); }}AccessDeniedHandlerログインしているが、特定のURLにアクセスする場合のハンドリングのためには、AccessDeniedHandlerの実装が必要となります。ここではレスポンスとしてFORBIDDENを表示する例を紹介します。public class JWTAccessDeniedHandler implements AccessDeniedHandler { @Override public void handle(HttpServletRequest request, HttpServletResponse response, AccessDeniedException exception) throws IOException, ServletException { // レスポンスの設定(403 FORBIDDEN) response.sendError(HttpStatus.FORBIDDEN.value(), HttpStatus.FORBIDDEN.getReasonPhrase()); }}AuthenticationFailureHandlerログインに失敗した場合のハンドリングのためには、AuthenticationFailureHandlerの実装が必要となります。ここではレスポンスとしてFORBIDDENを表示する例を紹介します。public class JWTAuthenticationFailureHandler implements AuthenticationFailureHandler { @Override public void onAuthenticationFailure(HttpServletRequest request, HttpServletResponse response, AuthenticationException exception) throws IOException, ServletException { // レスポンスの設定(403 FORBIDDEN) response.sendError(HttpStatus.FORBIDDEN.value(), HttpStatus.FORBIDDEN.getReasonPhrase()); }}LogoutSuccessHandlerログアウトした場合のハンドリングのためには、LogoutSuccessHandlerの実装が必要となります。JWTを使ったログインだけでなく、REST APIのログインはSessionではなくトークンのような情報をクライアントが持つので、サーバサイドで処理することはありません。ログアウトの場合はクライアント側で認証に必要な情報を削除するようにして、サーバサイドとしては単純にレスポンスとしてOKを表示します。public class JWTLogoutSuccessHandler implements LogoutSuccessHandler { @Override public void onLogoutSuccess(final HttpServletRequest request, final HttpServletResponse response, final Authentication authentication) throws IOException, ServletException { // レスポンスの設定(200 OK) response.setStatus(HttpStatus.OK.value()); }}Configurationクラスの設定最後に、Configurationクラスに今まで作成したカスタムHandlerクラスをそれぞれの目的に合わせて登録します。メソッドを覚えるだけで、登録の内容自体は難しくないです。ここでは以前のポストで作成したクラスを基盤に修正しています。@Configuration@RequiredArgsConstructorpublic class SecurityConfig extends WebSecurityConfigurerAdapter { @Bean @Override public AuthenticationManager authenticationManagerBean() throws Exception { return super.authenticationManagerBean(); } @Override protected void configure(final HttpSecurity httpSecurity) throws Exception { httpSecurity .httpBasic().disable() .csrf().disable() .formLogin().disable() .and() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests() .anyRequest().hasRole("USER") .and() // 例外ハンドリングの設定 .exceptionHandling() // ログインしなかった場合のハンドラーの設定 .accessDeniedHandler(new JWTAccessDeniedHandler()) // 権限がない場合のハンドラーの設定 .authenticationEntryPoint(new JWTAuthenticationEntryPoint()) .and() // ログアウトの設定 .logout() // ログアウトに使うURLを設定する .logoutUrl("/logout") // LogoutSuccessHandlerを指定する .logoutSuccessHandler(new JWTLogoutSuccessHandler()) .and() .addFilterBefore(new JWTAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class) .addFilterAt(getJsonUsernamePasswordAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class); } private JsonUsernamePasswordAuthenticationFilter getJsonUsernamePasswordAuthenticationFilter() { final JsonUsernamePasswordAuthenticationFilter jsonFilter = new JsonUsernamePasswordAuthenticationFilter(); try { jsonFilter.setFilterProcessesUrl("/api/v1/web/login"); jsonFilter.setAuthenticationManager(this.authenticationManagerBean()); jsonFilter.setAuthenticationSuccessHandler(new JWTAuthenticationSuccessHandler()); // 認証に失敗した場合のハンドラーの設定 jsonFilter.setAuthenticationFailureHandler(new JWTAuthenticationFailureHandler()); } catch (Exception e) { throw new RuntimeException(e); } return jsonFilter; }}ここではFilterやHandlerなどのクラスのインスタンスを新しく作成していますが、@ComponentでBeanとして登録しておいても構いません。どっちかとするとBean登録した方が良いかなという気はしますが、ここではコードが長くなるので省略しておきました。また、一般的にDIはフィールドよりもコンストラクタにつけた方が良いといいますが、フィールドをfinalとして宣言している場合ならLombokの@RequiredArgsConstructorを使っても自動でDIされますので今回はそのような書き方にしてみました。最後にハンドリングの場合は、メソッドが一つしかないインタフェースを実装して、Configurationクラスに登録するだけなので難しくないですね。それぞれのHandlerインタフェースは、引数としてリクエストはレスポンス、認証情報をとっているので、場合によってはカスタム例外ビューモデルを作成して返したり、エラー処理用のControllerを作ってリダイレクトさせるなど様々な処理ができます。セキュリティという面から考えると、定型化されたSpring Securityのエラーが出されるということはサーバサイドがSpringで作成されていることを知らせるようなものなので、アプリの脆弱性の問題に繋がる場合もあると思われますね。なのでWebアプリケーションを作る場合は、外部に漏出される情報に関しては徹底的に管理しておいた方が良いのではないかと思います。では、また！

REST APIでのSpring Securityの例外ハンドリングを実装する

JWTによるREST APIのログインを実現する

新しい案件が始まって、AngularとSpring bootによるSPA(Single Page Application)を作ることとなりましたが、まだ要件定義の段階で実装まではしばらく時間が残っています。いわゆる上流工程にはあまり経験がないので日々奮闘中ではありますが、仕事が終わった後の時間には少しづつ、練習をかねて自作アプリケーションを作っています。Spring BootでREST APIを作ることにはある程度慣れてはいるものの、まだ認証/認可に対してあまり知識がないので、自作アプリではわざとSpring Securityを入れることにしました。しかし、Spring Securityの記事をいくつか読んでロールによってアクセスできるURLに制限をかけたりしているのだなと理解した後に、いざ自作アプリケーションに導入してみようとしたら、問題ができました。いつも通りREST APIで実装していたのですが、自分が参考にしていたSpring Securityのコードはほぼ昔ながらのSpring MVCパターンのためのものだったのです。なので、今回のポストはSpring MVCパターンとREST APIのログインするため必要となるのが何かについて簡単に書いてみようと思います。(実際のログインの方法は今後のポストを予定しています)``コントローラの実装まずMVCパターンとREST APIのコントローラをどのように実装するかからみていきましょう。MVCパターンの場合今も多くの研修で行われているSpringの研修は、普通のMVCパターンとJSPによるものが多いのではないか、と思います。例えば@Controllerアノテーションをつけたコントローラクラスに、@RequestMappingアノテーションをつけたメソッドを書いて、そのメソッドではModelもしくはModelAndViewなどのクラスを使ってデータやビュー(主にJSPファイルのパス)を書いていくような形ですね。実際はJSPを使う=MVCパターンというわけでもないですが、多くのSpring MVCパターンのプロジェクトがJSPを使っているのでまずはこのようなレガシーなものをMVCパターンと呼ばせていただきます。ただ文章で表現するよりは、コードを持って書いた方がわかりやすいと思います。例えば以下のようなものです。/homeというURLに接続すると、サーバの時間を返す簡単な例題ですね。ModelAndViewを使うとしても、Modelにデータとビューを共につめてるだけでやっていることとしてはあまり変わらないと思います。@Controllerpublic class HomeController { // homeというJSPファイルとサーバの時間を表示する @RequestMapping(value = "/home", method = RequestMethod.GET) public String home(Model model) { Date date = new Date(); model.addAttribute("serverTime", date); return "home"; }}REST APIの場合自分の場合も、やはり最初はSpring MVCパターンとJSPから学んだのでこのような書き方に慣れていましたが、入社後にはSpring BootとREST APIというものに出会い、コードの書き方が少し変わりました。最近のトレンドだとやはりJSPよりもAngular/React/VueなどのJavaScriptフレームワークを使って作成する場合が多いので、JSONの形としてデータだけを返したらよくなります。JSONとしてデータをレスポンスボディに載せるには、普通にDTOクラスをビューモデルとして作ります。@Datapublic class HomeViewModel implements Serializble { // サーバの時間を表示する public Date serverTime;}あとは、@RestControllerアノテーションをつけたコントローラクラスを作り、作成したDTOクラスを返すメソッドを作成するだけです。少しアノテーションの種類や使い方も少し変わりましたが、内容としてはビューを担当しているJSPファイルの指定が消えただけで返しているデータは同じです。@RestController@RequestMapping("/api/v1")public class HomeApiController { // カスタムビューモデルにデータをつめて渡す @GetMapping("/home") public HomeViewModel getHome() { HomeViewModel model = new HomeViewModel(); model.setServerTime(new Date()); return model; }}そしてフロントエンドのJavaScriptフレームワークでは、レスポンスのボディから取得して画面に表示するようになりますね。このようにREST APIだと、サーバサイドではあくまでデータモデルとビジネスロジックだけを考えれば良いようになっていて、よりそれぞれの役割の分担がよくなっていますね。ログインをするにはでは、とりあえず簡単にSpring MVCパターンとREST APIの比較をしてみたので本題に戻りましょう。先にSpring Securityの話をしましたが、実際はSpring Securityを導入しなくても同じ話になると思います。REST APIはアーキテクチャの一つにすぎないので、フレームワークを導入できるかどうかの問題はすでに別の話になってしまいます。また、ログインというのはSpring Security以前の問題です。なので今回はSpring Securityの話はさておき、二つのアーキテクチャでどのようにログインをするかについて話したいと思います。MVCパターンMVCパターンでは、Sessionでログインを実現する場合が多い(と思い)ます。例えばログインを担当するメソッドを作成して、引数としてHttpServletRequestを指定すると、そこからセッションを取得することができますね。あとは、またの引数としてFormのデータ(IDとパスワード)を受けて、これは自分が最初に学んだ方式でもあります。まずユーザの観点から話してみましょう。普通のWebアプリケーションでは、画面のほうでログインのためにIDとパスワードを入力するようになります。JSPではそのデータをformとして受け取り、POSTとしてコントローラに送りますね。そうしたらコントローラではIDとパスワードをServiceクラスに送って検証してもらい、問題なかったらログインした情報をSessionに載せます。こういうったシナリオで、コントローラにログインのためのメソッドを作るとおそらく以下のコードのような形のなるはずです。(実際はユーザのIDだけ載せる場合はないので参考までに)// URLは/login、メソッドはPOST@RequestMapping(value = "/login", method = RequestMethod.POST)public String login(User user, HttpServletRequest request) { // Serviceからユーザを取得する User loginedUser = service.getUser(user.getId(), user.getPassword()); // リクエストからセッションを取得する HttpSession session = request.getSession(); // SessionにユーザIDを載せる session.setAttribute("userId", loginedUser.getId()); return "/";}これでログインができたら、あとは他のメソッドでSessionの検証をして、ログインされているかどうかを判断することになります。ログアウトする場合は、Sessionを破棄すればいいです。例えば以下のようになりましょう。// URLは/logout、メソッドはGet@RequestMapping(value = "/logout", method = RequestMethod.GET)public String logout(HttpServletRequest request) { // リクエストからセッションを取得する HttpSession session = request.getSession(); // Sessionを破棄する session.invalidate(); return "/";}Spring Securityを使った場合はかなりコードが変わってきますが、Sessionを使う場合にこう言った基本的なフローは変わりませんね。これでMVCパターンでの認証/認可は実現できます。ここで問題がしかし、Sessionを使った方法はREST APIだと使えなくなります。なぜかというと、REST APIの最大の特徴の一つはStateless、つまり状態を持たないというのであるからです。ここでいう状態というのはサーバに取ってのクライアントのステータスのことです。今まで通りだとクライアントはサーバに接続した瞬間からサーバに自分の状態を管理させる必要がありました。こういう状態を管理するためのものがSessionであり、先に説明した通りだとREST APIには適用すべきではないですね。(無理やり適用させるとしたら不可能でもないですが…)そしてStatelessである故に、REST APIではクライアントのリクエスト毎にクライアントから必要な全ての情報をサーバに送るようにしています。ここから推論できるのはSessionでログインの情報を載せておくのではなく、クライアントからリクエスト毎に自分はログインしているということを証明するデータを何かの形で送る必要があるということになります。ではどうしたら？クライアントがリクエスト毎に、本質的なデータのみでなく、認証のためのデータを送るための手段は、すでにHTTPの中にありました。つまり、Headerです。クライアントのリクエストには操作のためのデータがBodyとして入っていて、そこに認証のための情報をHeaderとして載せればいいですね。クライアントがHeaderに認証のための情報を載せるには、まずサーバサイドから認証をしてもらわねばなりません。この認証の詳細については今後のポストで話すことにして、まずはHeaderに載せるデータが完成されたと仮定し、これをサーバのレスポンスでどう返すかについて述べます。Spring BootでレスポンスのHeaderにデータを載せるためには二つの方法があります。先に述べたSpring MVCのリクエスト同様、レスポンスを扱うためのクラスであるHttpServletResponseを使う方法と、ResponseEntityでレスポンスデータをラッピングすることです。どれも使える方法ですが、HttpServletResponseでHeaderを追加するまずはHttpServletResponseです。シンプルに、「レスポンスにデータを載せたい」という時に使える方法ですね。MVCパターンでのログインと同じく、ログインするメソッドの引数に指定すると、レスポンスのHeaderにデータを載せることができます。@PostMapping("/login")public User login(User user, HttpServletResponse response) { // Serviceからユーザを取得する User loginedUser = service.getUser(user.getId(), user.getPassword()); // レスポンスのHeaderにユーザのIDを載せる response.addHeader("userId", loginedUser.getId()); // Bodyを返す(Headerは自動で含まれる) return loginedMember;}ResponseEntityでHeaderを追加するもう一つの方法であるResponseEntityの場合は、引数はユーザ情報(IDとパスワード)のみで良くなります。名前からもわかると思いますが、ResponseEntityはBodyとHeaderを含め、HTTP Status(200 OKなど)を含めレスポンスに必要な情報は全て扱えるクラスです。使い方は簡単で、ログインメソッドの戻り値となるBodyをResponseEntityで包み、Headerなどの情報も一緒に詰めて返します。@PostMapping("/login")public ResponseEntity<Member> login(User user) { User loginedUser = service.getUser(user.getId(), user.getPassword()); // レスポンスとしてHeaderとBodyを一緒にセットして返す return ResponseEntity.ok().header("userId", loginedUser.getId()).body(loginedUser);}そのあとは？レスポンスのHeaderに載せた情報は、フロントエンド側でリクエスト毎にHeaderに載せて送ることになります。しかし、リクエスト毎に送るためにはどこかにこの情報を保存する必要がありますね。Cookieを使う方法もありますが、セキュリティ情のリスクがあるため多くの場合ではブラウザのローカルストレージに保存するようになっているようです。これはフロントエンドの領域なので、ここでは深掘りしません。また、ログアウトの場合はどうなるか、という問題もありますが、これは様々な方法で実現しているようです。例えばフロントエンドからできる方法としては、Headerに載せる認証情報を削除したり、間違った情報を送るようにするような方法があります。そしてサーバサイドでは、一定時間がすぎると認証情報を使えなくするなどの対策があります。最後に本当は、REST APIでのログインに関してはまだ考えなければならないことは他にもあります。例えば、HTTP Headerに認証のため必要となる情報を載せるということは理解できても、実際はどのようなデータを載せればいいか、そのデータはどう作るか、リクエスト毎にHeaderで認証情報を扱うということはセキュリティやリソースの面で大丈夫かなど。でも、とにかくこれでREST APIでログインするための仕組みの一つはわかりました。次回は、このHeaderとSpring Securityを使ってのログインを実装する方法を述べながら、以上の問題についても扱いたいなと思っています。では、また！

REST APIでのログインのためには

このたびは、新しい案件でAngularとSpring BootによるWebアプリケーションの開発を担当することになりました。Spring Bootは今までずっとやってきているのであまり問題はないと思いますが、問題はAngularです。Angularはバージョン2からTypeScriptを使うことになっているらしく、JavaScriptとjQueryを少し触ったくらいの経験しかないのでそもそもTypeScriptがどんなものかすら知らなかったです。ただわかっているのは、JavaやC#みたいに静的言語みたくコードを書いたら、それをいい感じにコンパイルしてJavaScriptに変えてくれる、ということだけでした。なのでまずTypeScriptの勉強を始めましたが、言語そのものの特徴に含め、TypeScriptで何かを作る時に必要となる知識は意外と大きいことに気付きました。今回のポストでは正直な感想と、どんなものが必要なのかをJavaしか知らない初心者である自分の観点から述べていきたいと思います。驚くほどJavaに似ている元々C/C++、C#、JavaといったいわゆるC-family言語と似ているとの話は聞いていましたが、実際TypeScriptを触ってみると本当にそうでした。最初、なんの情報もなかった時(型を指定できて、コンパイルしたらJavaScriptに変わるという話だけ聞いている時)、ただ普通の変数の宣言に型指定ができるようになっているだけかと思っていたのですが、それだけでなく意外とオブジェクト指向に合わせて発展、もしくは回帰している印象を受けました。型指定はいい感じ型の指定は、元々動的言語であるJavaScriptを昔ながらの静的言語化するものですね。でも、書き方自体は昔のままでなく、KotlinやSwiftのようなモダンな言語に似ています。型をまず書くのではなく、変数として宣言したあとに型をつける1のですね。例えば以下のようになります。Javaでの型指定int a = 1000;TypeScriptの型指定var a: number = 1000;また、こういう型指定を、TypeScriptでは「型注釈」とも呼ぶらしいです。TypeScriptはコンパイルされたらランタイムで型が決まるJavaScriptになるので、コンパイラーのために注釈をつけてあげる、という意味に近いようです。型以外の類似点TypeScriptには型指定だけでなく、C#やJavaプログラマーならすでに慣れているAccess修飾子、Interface、Class、Generics、Decorator(Annotation)なども用意されています。これらの一部は最近JavaScriptでも対応している機能ではありますが、実際のアプリを開発する業務ではブラウザの制約から最新のJavaScriptを使えない場合もあり不便ですね。しかし、TypeScriptを使うとコンパイラのオプションを指定することでどのバージョンのJavaScriptとしてソースコードを出力するか選択できるので、ブラウザをあまり気にせず同じコードを書けます。これは本当にありがたいですね。他に、依存関係をnpmといったパッケージマネージャで管理できるというのも良いところ。これはJavaScriptでもできる(というか、そちらが先ですが)ことですが、Importと組み合わせたらほぼC-familyと似たような感覚で運用できるという面が良いですね。JavaScriptのモジュールというのも、またES6から対応しているのでそれ以前のバージョンを使う場合だとかなり面倒くなるかも知れない、と思いました。知識不足なだけかもしれませんが…気になったところTypeScriptの良いところは、やはり昔ながらの言語に慣れている人にはかなり快適にコードをかけるような環境を提供していて、コンパイルタイムでエラーを探せるという、その何ふさわしいものとなっている点だと思います。ただ、少し気になったところもあったのでそれについても書きます。結局はJavaScriptTypeScriptはJavaScriptのSuper setなので、JavaScriptの機能をそのまま利用できるというのが特徴だとも言われています。最初はそれをメリットとして捉えていましたが、勉強をしながらやはりデメリットもあるんだなと感じました。JavaScriptをそのままかけるということは、結局言い方を変えると、ソースコードの中にJavaScript(Vanilla)とTypeScriptが混在していても問題なくなるということですね。こうなった場合にTypeScriptがSuper setという特徴を諦めないかぎりコードが動かなくなることはないと思いますが、人の観点からするとかなり混乱するコードが生まれる可能性もあるのではないかと思いますね。JavaScriptでも書けるということの意味そもそもJavaScriptの歴史の方が長く、ユーザも絶対的にJavaScriptの方が多いです。そして、私みたいにC-family言語ではなくJavaScriptからプログラミングに入門した人もいるので、そのような人にとってTypeScriptはあえて使うメリットのない、ただの不便なものにしか思われない可能性もあると思います。また、JavaScriptの方に慣れている人がTypeScriptに移ったとしても、結局はJavaScriptと変わらない書き方になる可能性もなくはないはずですね。TypeScriptがSuper setとして企画された理由は、既存のJavaScriptプログラマーを吸収するための政策だったと思いますが、プログラミング言語は自由が多いほど混乱しやすいと思うので、これはやはりメリットでもデメリットでもあると思いました。prototypeクラス基盤のオブジェクト指向言語から入門しているからか、自分にはJavaScriptのprototypeという概念があまりわかってないです。ともかくJavaScriptにはこのprototypeというのがあって、オブジェクトを変数として使うこともできるという特徴を持っていますね2。Javaプログラマーとしてはオブジェクトはクラス、クラスはファイル一つ、という風に考えることが一般的なので、こういう自由度に触れるとどうしたらいいか混乱しそうな感覚です。そしてもちろん、これはTypeScriptよりもJavaScriptの特徴ではありますが、TypeScriptがSuper setである以上避けられない問題なのですね。ModuleモジュールがJavaScriptに導入されて、TypeScriptでももちろんそのまま使えます。個別のファイルにクラスを一つづつ作成して、インポートして使っているとまるでJavaと大差ないようにも思われますね。でもこのモジュールというものも実際はややこしいところがあるようで、書き方をどうするか考えなくてはならない場合もあるようです。例えばPythonのようにasを入れることでインポートしたモジュールに別名をつけることができるけど、そうしたら問題が怒るケースもあるとか、CORS設定で塞がる場合もあるとかというのが最初はかなり複雑だなと感じました。まだ深堀りしてないので実際は使ってみないとわからないと思いますが、そもそも使ってみないとわからないという部分はやはり気になりますね。// 二つの書き方ができるが、一緒ではないimport express from "express";import * as express from "express";コンパイルTypeScriptをインストールすると、ターミナルからtscというコマンドを使えるようになります。そしてTypeScriptで作成したファイルは.tsというファイルに書いて、tscコマンドで.jsに変わりますね。tsconfig.jsonファイルを定義することでどうコンパイルするか様々なオプションを指定することもできます。例えばJavaScriptにコンパイルする時、どんなバージョンでコンパイルするか、どのファイルをコンパイルするか、.jsファイルはどこに吐き出すかなど。ただ、コンパイルにかなり時間がかかるのもあり、コンパイルされたファイルは結局JavaScriptになります3。そしてこれは、TypeScriptで作成しても「ランタイムでは弱タイプになる」ということを意味しますね。ちゃんとタイプを明示して(anyを使わず)コードを作成しただけでは不十分なケースが十分あり得るので、ランタイムでも型による問題が起こらないようにする必要性があるかも知れないという印象を受けました。最近はnpmの代替ランタイムとしてTypeScriptをそのまま使えるDenoのようなものも登場していますが、やはり内部的にはtscを使っているらしく、このコンパイル速度が遅いのが最大の問題として挙げられていました。Rustで新しいコンパイラを作成しているとのことですが、それがいつ完成されるかもわからないですね。そしてtscのみでなく、webpackを使う場合はts-loaderを使ったりするとかなり初期設定が複雑な印象を受けました。他にBabelなどを使う場合もあるらしいですが、コンパイルをするためという理由でこのようなベンドラやコンパイラをまた勉強しなくてはならないというのは少し不便な部分ですね。JavaScriptと紐付けられている言語としての運命みたいなものかもしれませんが…すっきりしたところJavaScriptライブラリを使える「TypeScriptではJavaScriptのライブラリも使える」という話も聞きましたが、実際それがどうやって可能になったのかが疑問でした。例えばTypeScriptにも型推論があってある程度、型を宣言しなくても良い場合はあるものの、基本的には型注釈で明示的に型を指定してあげないとうまくコンパイルできない部分もありますね。しかし、すでに存在しているJavaScriptのライブラリ全てがTypeScriptを考慮して作られているとは考えられないので、これをTypeScriptではどのような形で対応しているかが一番の疑問でした。答えは意外と簡単で、.d.tsという形で「型定義ファイル」を作成すると良い、ということでした。すでにTypeScriptに対応しているライブラリの場合もこの型定義ファイルによってTypeScriptが型を参照できるようにしていて、自作することも可能。そしてメジャーなものの場合、node_modulesにインストールできる形で型定義ファイルを提供している場合もありました。すでに作成されている型定義ファイルのインストールも簡単で、例えばnodeのTypeScript型定義が必要な場合はnpm install --save-dev @types/nodeのようにコマンド一つでインストールができて、GitHubのリポジトリを参照するとどんなライブラリの型定義ファイルが提供されているか確認することもできました。最後にまだ色々気になるところはありますが、多くはTypeScriptそのものというよりもJavaScriptの特性から起因しているものが多いため、現時点でフロントエンドエンジニアがどの言語を選択すべきかというと、やはりTypeScriptの方が良いのではないかと思いました。もちろん、これは自分のスタートがJavaであることもあるとは思いますが、やはりコンパイルタイムで多くの問題を事前にキャッチできるというメリットは捨てがたいものだと思っています。現在はJavaScriptとの互換性のために色々初期設定など煩雑だったりコンパイルに時間がかかるなどの問題もいくつかありますが、これらもAngularみたいに最初からTypeScriptを前提に作られるフレームワークやライブラリが増えたり、ブラウザからTypeScriptに対応したり(これは可能性が低いかな…)したら自然に解決される問題ではないかとも思いますね。最初は単純にAngularを使うために勉強したものの、意外としっかりしていて、これからの未来もかなり明るい感じだったのでエンジニアの皆さんにもぜひお勧めしたいと思っているところです。ああ、Pythonも型指定できるようになるといいな…4もちろん、最近はC#もJavaもvarで変数を宣言することもできますが、習慣もあり、元々静的言語では型から書いた方が良いのではないかと個人的には思っています。 ↩︎しかも、ES6で登場したClassは結局プロトタイプ基盤のfunctionの書き方をちょっと変えただけなのですね。 ↩︎Javaのようにバイトコードに変わったり、Cのように機械語に変わるようなものとは少し違うのでTypeScriptのコンパイルはトランスパイルとも呼ぶらしいです。 ↩︎知識不足でした！Pythonも3.6から型の宣言ができるようになっています。 ↩︎

JavaプログラマーがみたTypeScript

この度は、ブログのテーマを新しく変えてみました。新しいテーマはNexTです。一年がたってもあまりJekyllに慣れてないので思ったより苦労していますが(特に消えたページなどが気になります…)、それでも前のテーマと比べてかなりすっきりした感じが良いと思います。検索機能もついていたのでとりあえずアクティベートしてみましたが、ローカルでは機能してなかったのでGithub Pagesにあげてからテストですね。なるべく使いたい。(追記：残念ながら何かのバグのようで使えませんでした…)このブログを作ってからも1年が立ちます。最初のポストが1年前だったのですね。あの頃は入社したばかりの新人だったのでいろいろとわからない物だらけでした。なので書いていたポストの内容もいまいちな物が多かったと思います。最近はJavaを使っていろいろと開発はしているものの、あまり経歴が長いわけでもないので当時書いたポストをみているとなぜこのような恥ずかしいものを書いたんだろう、とも思います。それでもブログの更新を続けているのは、このブログが自分の勉強の記録であって、過去の自分が書いたコードや文面を振り返ってみることで新しい発見ができていたからです。時々過去のポストを振り返ってみることで同じことをしてもより良い方法、より安全な方法を探すことができました。修正したいものもかなり多いのですが、のちにそれを補えるようなポストを書いた方が自分のエンジニアとしての軌跡をちゃんと追える手段となるのではないかと思います。誰かに見せるにはかなり恥ずかしいブログですが、それでも訪問してくださる方々も増えました。おそらく私みたいに、何らかの問題と遭遇していたり他の誰かはどんな解決策を見つけたんだろうという好奇心から検索してみたりしている方々ではないかと思います。自分のコードや知識も正解とは言い切れないものなので、このブログを参考にしてくださいとおすすめはできませんが、エンジニアの仲間の一人として、こういう答えを探し出していたのでだなと受け止められれば幸いです。では、また何か勉強ができたら、ポストにてお伺いしましょう。これからもよろしくお願いします。

ブログ刷新

アノテーションは普通のJavaでも使えるもので、様々なライブラリやフレームワークでは積極活用していますね。中でも、最もアノテーションを有効活用しているのはSpringではないかと思います。DIをするためでも、クラスの位置付けにも、なんでもアノテーションをつけることで簡単に定義できるようにしているからです。なのでSpringでWebアプリケーションを実装するときはどんなアノテーションがあるのかを調べてみるのが重要と思います。なぜこのような話をするかというと、実は前回のポストでServiceを切り替える方法について説明しましたが、他に方法がないか探していたところ、Springならアノテーションでも条件によってBeanやConfigurationを登録する方法があるということをわかったからです。また、その条件によって様々なアノテーションが存在していたため、それらの勉強をかねて、今回は様々な条件と場合を想定して作られたSpringのアノテーションについて紹介したいと思います。これらのアノテーションはSpringのauto-configurationに属するものらしいです。Spring Bootではすでに多くの設定が自動化されていますが、これをカスタムして使えるようにアノテーションを提供しているということですね。※これらを全部試してみたわけではないですが、とりあえずはご紹介まで。条件でDIする以前のポストで紹介したコートから始めます。以下のようなことをすれば、application.ymlに記載した値によりどのリポジトリをDIするか決定できるという話をしました。@Configurationpublic class SomeServiceConfig { // YAMLに設定した値を読み込む @Value("${settings.TestMode:false}") private boolean testMode; // YAMLの設定からどのImplクラスを使うかを決定してBean登録 @Bean public SomeService someService(SomeRepository repository, SomeTestRepository testRepository) { return this.testMode ? new SomeTestSerivce(testRepository) : new SomeServiceImple(repository); }}同じようなことを、これから紹介するSpringのアノテーションで実装するとしたら、以下のように変わります。@Configurationpublic class SomeServiceConfig { // 本番用のサービスクラス @Bean @ConditionalOnProperty(value = "settings.Testmode", havingValue = "false") public SomeService someService(SomeRepository repository) { return new SomeServiceImple(repository); } // テスト用のサービスクラス @Bean @ConditionalOnProperty(value = "settings.Testmode", havingValue = "true") public SomeService someTestService(SomeTestRepository testRepository) { return new SomeTestService(); }}以上のコードからわかるように、@ConditionalOnPropertyというアノテーションを使うと、とある条件によりメソッドの内容が実行されるようにすることができるようになります。わざわざ分岐を書いたり、カスタムな@Valueアノテーションを用意するよりかなりすっきりしたコードになりますね。また、このアノテーションはBeanアノテーションとだけ組み合わせができるわけでもないです。他のSpringのクラスアノテーション(Configuration、Component、Service、Repository、Controller)にも使えるので、より自由度が高いですね。他にもSpring Bootのorg.springframework.boot.autoconfigure.conditionパッケージにはには@Conditional...といったアノテーションがいくつか用意されていて、これらを簡単に紹介したいと思います。定義済みのConditionalアノテーションConditionalOnPropertyapplication.ymlなど、プロパティを書いたファイルやシステムプロパティに、指定したアノテーションがある場合実行されるアノテーションです。Spring Bootアプリケーションで最も一般的に使われるものらしいですね。括弧の中にはプロパティ名と値、そしてそのプロパティが存在しない場合も実行するかどうかを指定できます。以下のコードは、use.testmodeというプロパティが存在していて、かつtrueの場合に実行されるConfigurationクラスの例です。matchIfMissingをtrueに指定すると、use.testmodeというプロパティが存在しなくても実行されるようになります。もちろん指定しなかった場合のデフォルト値はfalseとなります。@Configuration@ConditionalOnProperty(value = "use.testmode", havingValue = "true", matchIfMissing = true)public class TestConfig { // テストモードで使うConfiguration}ConditionalOnExpressionプロパティの記述方法による実行というアノテーションです。括弧で条件を指定できます。ここでいう条件(表現式)は、Valueアノテーションなどでも使われるSpELを使います。application.ymlなどに記載したプロパティが、括弧の中の条件と一致する場合に実行されますね。以下のコードはuse.testmodeとuse.submodeのどちらもtrueの場合に実行される例です。@Configuration@ConditionalOnExpression("${use.testmode:true} and ${use.submode:true}")public class TestSubConfig { // テストモード及びサブモードの両方がtrueの場合に使うConfiguration}ConditionalOnBean指定したBeanが存在する場合に実行というアノテーションです。括弧の中にBeanとして登録されているかどうか判定したいクラスを指定するだけで使えます。ConditionalOnPropertyでとあるBeanが登録されたら、それに合わせて必要なサブモジュール的なものも登録したい、といった場合に使えるのかなと思います。以下のコードは、TestRepositoryというクラスがBeanとして登録されている場合に実行される例です。@Configuration@ConditionalOnBean(TestRepository.class)public class TestBeanConfig { // テスト用のBeanが登録された場合に使うConfiguration}ConditionalOnMissingBeanConditionalOnBeanとは逆のものです。こちらは、指定したクラスがBeanとして登録されてない場合に実行というものとなります。以下のコードは、RepositoryがBeanとして登録されてない場合は自動的にTestRepositoryをBeanとして登録する例です。@Configurationpublic class AlternativeConfigutration { @Bean @ConditionalOnMissingBean public Repository testRepository() { return new TestRepository(); }}ConditionalOnResourceリソースファイルが存在する場合に実行するというアノテーションです。例えばLogBackを使う場合、xmlファイルが必要となりますが、そのxmlファイルが存在する場合はConfigurationも実行するという構成にしたい場合に使えますね。以下のコードは、そのような場合の例です。@Configuration@ConditionalOnResource(resources = "/logback.xml")public class LogbackConfig { // リソースフォルダにlogback.xmlが存在する場合に使うConfiguration}ConditionalOnClass指定したクラスが存在する場合に実行するというアノテーションです。ConditionalOnBeanと似ていますが、こちらはBeanではなくても良いという違いがありますね。例えば依存関係でとあるライブラリがあるかどうかで使えると思います。以下のコードはcom.custom.library.moduleパッケージのSomeClassというクラスが存在する場合に実行される例です。@Configuration@ConditionalOnClass(name = "com.custom.library.module.SomeClass")public class CustomLibraryConfig { // カスタムライブラリのSomeClassがある場合使うConfiguration}ConditionalOnMissingClassConditionalOnClassの逆の場合のアノテーションです。こちらはConditionalOnMissingBeanと似ていますね。同じく、指定するクラスはBeanでなくても良いです。以下のコードは、上のConditionalOnClassの逆の場合の例です。@Configuration@ConditionalOnMissingClass(name = "com.custom.library.module.SomeClass")public class NoCustomLibraryConfig { // カスタムライブラリのSomeClassがない場合使うConfiguration}ConditionalOnJavaアプリケーションがJavaのどのバージョンで実行されているかのによるアノテーションです。JavaのバージョンによってAPIの仕様が変わる場合があるので、複数の環境でアプリケーションを実行する必要がある場合は使うことを考えられますね。以下のコードは、Javaのバージョンが1.8の場合の例です。@Configuration@ConditionalOnJava(JavaVersion.EIGHT)public class JavaEightConfig { // Javaのバージョンが1.8の場合に使うConfiguration}カスタムConditionConditionインタフェースを実装することで、カスタムConditionを作ることもできます。例えば以下のコードのように、アプリケーションが実行されるOSがLinuxの場合のConditionを自作することができます。使い方は簡単で、戻り値がbooleanであるmatchesを実装するだけです。class OnUnixCondition implements Condition { // OSがLinuxかどうかを判定するConditionとなる @Override public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) { return SystemUtils.IS_OS_LINUX; }}実装したConditionは、Conditionalアノテーションに指定して使います。@Configurationpublic class OsConfig { // LinuxではBeanが登録される @Bean @Conditional(OnUnixCondition.class) public UnixBean unixBean() { return new UnixBean(); }}AnyNestConditionクラスを継承すると、より複雑な条件の指定ができます。上で実装したOnUnixCondition以外でも、Windowsで実行されているかどうかを判定するOnWindwosConditionクラスを実装したとしましょう。そういった場合は、以下のように実装することができます。public class OnWindowsOrUnixCondition extends AnyNestedCondition { OnWindowsOrUnixCondition() { super(ConfigurationPhase.REGISTER_BEAN); } @Conditional(OnWindowsCondition.class) public static class OnWindows { // Windowsの場合 } @Conditional(OnUnixCondition.class) public static class OnUnix { // Linuxの場合 }}実装したConditionは、また同じ方法でConditionalアノテーションに指定します。@Configurationpublic class OsConfig { // WindowsかLinuxのどちらだとBeanが登録される @Bean @Conditional(OnWindowsOrUnixCondition.class) public WindowsOrUnixBean windowsOrUnixBean() { return new WindowsOrUnixBean(); }}最後にこちらで紹介したアノテーション以外でも、org.springframework.boot.autoconfigure.conditionのパッケージの下には様々なクラスが存在しています。例えばWebアプリケーションかどうか、クラウドプラットフォームかどうかのアノテーションが用意されていて、のちにまた様々な条件が追加される可能性もありますね。これらConditionalアノテーション群は、Spring BootのAuto Configurationでも使われているものらしいです。あので以前私が紹介したように自分でプロパティを直接読み込み、if文を書くよりは安定的な方法であると思います。また、様々な条件に対応するアノテーションがそれぞれ存在していて、カスタムCondtionを作ることで共通化できる部分もあると思うので、いろいろ便利ですね。Javaそのものもそうですが、Springの世界もまだいろいろと奥深いと感じました。これからも勉強ですね。

条件で動作するアノテーションを使う

個人的には、関数型プログラミングにあまり詳しくはないですが、Java 1.8のStream APIは好んで使っています。他にもLambdaやOptionalといったAPIも好きですが、自分がJavaの資格を取った理由も、このStream APIについてもっと勉強したかったからと言っても過言ではないです。そんな私ですが、Streamについて勉強している中、疑問が出来ました。Streamは確かにいいAPIですが、伝統的なJavaのAPIとはかなり違うものです。これをJavaに導入したことで得られるメリットがあるから導入されたはず、というのは難しくない推論ですが、逆の場合はどうでしょうか？Streamを使った場合のデメリットは？そして自分が使っているStreamの書き方は正しいのか？などなど。今回のポストでは、そのような疑問について独自に調査したことを述べていきたいと思います。正解というより、こういう見解があるということとしてご理解ください。Streamは万能か？まず最初の質問です。Streamは万能か？つまり、既存のコードをすべてStreamに書き換えても問題はないか？そしてなるべくこれから書くコードはStreamに変えるべきなのか？という質問ですね。確かに新しいAPIが出て、既存のコードと同じ役割ができるとしたら、それにはなんらかの理由があります。Javaの場合は、NIOがそうでした。一般的なI/OではOSのカーネルの機能を利用できなかったため、それを改善するために登場しましたね。しかし、NIOもまた、全ての場面で既存のI/Oより優れているとは言えない面がありました。そしたらStreamの場合も、その可能性はあると思いました。結論からいうと、「全てのコードをStreamに書き換える必要はない」です。その理由を、一つ一つ項目別に説明します。性能は劣る場合もJava 1.5では、伝統的なFor文意外にも、いわゆる拡張For文というものが登場しました。そして1.8では、Streamと共にforEach()というメソッドもできましたね。しかし、forEach()もStreamも性能は拡張For文より劣ります。また、とあるベンチマークでは、Streamを使った場合の処理はParallelを使っても拡張For文より性能は劣るという結果が出たらしいです。理由は簡単です。Streamを使うと、より複雑な処理が中に入るからです。特に配列をStreamに変換する時はラッピングが入るので、そこでもう処理が加えられるということを考えられますね。特に、オブジェクトを扱う場合の性能の差はそんなに大きくないものの、プリミティブ型を扱う場合は性能の差がより大きいらしいです。なので無理やり配列をStreamに変えて処理をする必要はありません。StreamやforEach()は、それを持って安定したコードを書けられる場合に限定して使う必要があります。そしてStreamを使う場合もプリミティブ型を扱う場合はIntStreamやToIntStreamといった、それぞれの型に合わせたクラスを使った方がより良い性能を出すので、そこもちゃんと考慮すべきですね。JVMが長い間伝統的なFor文に最適化されてきて、1.8になってやっと登場したStreamはそれほど最適化されてないので性能が劣るという話もありましたが、これは1.8がリリースされた当時の記事に書いてあったものなので14までバージョンアップがなされた今はどうかという疑問はあります。それでも伝統的なFor文の方がまだ性能では優秀ではないだろうかと思いますが。途中でやめられないStreamの処理は一般的なforループとは違って、continueやbreak、returnなどで一部の処理をスキップしたり途中で処理を止めることができません。基本的にStreamは全要素に対して処理をすることを前提にして設計されたからです。なのでそれぞれの目的に合わせて、Streamのメソッドを適切に使い分ける必要があります。例えばFor文での処理は以下のような変えられます。条件に合致する要素だけを処理したい場合(if)filter()Collectionにしたい場合(add)collect()要素を取り出したい場合(return)findAny() / findFirst()ループ変数を使用できない拡張For文ではなく、伝統的なFor文ではループ変数を使って、現在のループが何回目かを数えることができます。しかし、Streamではループ変数を使うことができません。例えば、以下のようにStreamの外部に変数を置いてもコンパイルエラーとなります。int型のループ変数を使いたい場合はIntStreamを、ループ変数で処理をスキップしたい場合はskip()を使いましょう。もちろん、こういう場合は普通に既存のFor文を使った方が正解に違いです。そもそもの関数型実は、Streamの中でも外部変数をループ変数として使う方法がなくはないです。AtomicIntegerでループ変数を使う方法がありますが、そこまでしてStreamを使う理由もなければ、関数型プログラミングの目的に合いません。関数型プログラミングのコンセプトの中では不変性(Immutability)というものがあります。以前Immutabilityについて述べたことがありますが、ここで重要なのはデータが変わることはない、ということです。データが変わらないならどうやって処理が行われるかというと、元のデータはそのままで、処理ではそのデータのコピーを作って作業することになります。Streaｍを持って処理をする場合に、その結果が新しいインスタンスになるのもそれが理由です。Listをループさせる場合は、元の要素を編集できます。しかし、Streamで処理する場合は変更された要素で構成された新しいListを返すようになりますね。中間操作で元の要素を編集するとしても、Streamは終端操作が終わるとクローズされ再利用できなくなります。これで元のデータは変えずに済みますね。なのでStreamを使う場面というのは、まず元のデータをどうするかによります。もちろん、Streamを使わない場合でも、関数型的なコードの作成がより場合も多いです。(ということで、まずは関数型プログラミングを勉強ですね…)Streamをより活用する次に、Streamを使う場合に、どうしたら正しく、より効率的に活用できるかに関する質問です。Streamは最初から再使用できないようになっていますが、場合によっては同じデータに対してそれぞれ違う処理を行う必要があるのでそれがどうやって実現できるか、という疑問がありました。例えば、普通のFor文だとループの中で分岐を置くことで二つのCollectionに要素を分配するような処理ができるのですが、Streamだと同じオブジェクトに対しての処理はできませんね。こういう場合は同じデータに対してどうやったらStream処理を2回以上できるか気になります。もう一つは、自分だけなのかもしれませんが、Stream以外でも、メソッドチェーニングを使えるAPIは非効率的な処理が入ってもすごく場合があって、それをどうしたら効率的な書き方にできるかという疑問がありました。例えばCollectionや配列をStreamに変換してからforEach()を使うこともできますが、CollectionだとstreamなしでもforEach()は使えますね。こういう場合は直感的にCollectionのforEach()の方が良さそうだとは思いますが、それ以外の場合はどうなのかよくわかりません。なので、この二つの疑問についても調査してみました。再使用Streaｍは何度も繰り返して中間操作が可能ですが、一度でも終端操作が行われるとクローズされ、再利用ができなくなります。なぜなら、Streamの目的はデータの処理であって、データの格納ではないからです。しかし、たまには同じデータに対してStreamを利用し、それぞれ違う処理を行たい場合もありますね。そういう時はどうしたらいいでしょう。Javaでデータを格納するためのものは配列やCollectionがありますので、必要なデータを予め定義して、場合によってそれをStreamに転換して使う方法があります。配列の場合はArrays.stream()やStream.of()があり、Collectionだとstream()がありますね。例えば以下のような方法です。// Listで必要なデータを集めておくList<String> names = Stream.of("Eric", "Elena", "Java") .filter(name -> name.contains("a")) .collect(Collectors.toList());// 1番目のStreamOptional<String> firstElement = names.stream().findFirst();// 2番目のStreamOptional<String> anyElement = names.stream().findAny();予め必要なデータはListとしてCollectし、必要な場合はそれをまたStreamに変換して使う例でした。データがそもそもCollectionや配列の場合は、必要に応じてstream()を呼び出すことでそれぞれ違う処理ができます。また、peek()を挟むことで違うCollectionにデータを追加することもできます。厳密にいうと再使用というよりはどうStreamを作るかに関する話となりますが、これで一つのデータから複数の処理結果を出すことは可能、ということになります。短く書く先に述べましたが、StreamはメソッドチェーニングのできるAPIなので、非効率的なコードを書きやすい傾向がありました。なのでケース別により効率的な書き方を集めてみました。自分はEclipseを主に使っているのですが、Intellijだと、こうした方がいいよとオススメしてくれる部分らしいです。Collectionのメソッドを使う// CollectionのForEachcollection.stream().forEach() → collection.forEach()// Collectionを配列にcollection.stream().toArray() → collection.toArray()Streamを作る// 配列からStreamにArrays.asList().stream() → Arrays.stream() / Stream.of()// 空のStreamを作成Collections.emptyList().stream() → Stream.empty()// 範囲指定で配列を作成IntStream.range(expr1, expr2).mapToObj(x -> array[x]) → Arrays.stream(array, expr1, expr2)// 範囲指定でStreamを作成Collection.nCopies(count, ...) → Stream.generate().limit(count)要素の判定// 条件に一致する要素が存在するかの判定(1)stream.filter().findFirst().isPresent() → stream.anyMatch()// 条件に一致する要素が存在するかの判定(2)stream.map().anyMatch(Boolean::booleanValue) → stream.anyMatch()// 要素が一つでも条件と一致しないかの判定!stream.anyMatch() → stream.noneMatch()// 全要素が条件と一致するかの判定!stream.anyMatch(x -> !(...)) → stream.allMatch()// ソートして最も先にある値を探すstream.sorted(comparator).findFirst() → Stream.min(comparator)要素を集める// 要素の数を数えるstream.collect(counting()) → stream.count()// 最も大きい要素を探すstream.collect(maxBy()) → stream.max()// 要素を違うオブジェクトにマッピングするstream.collect(mapping()) → stream.map().collect()// 要素を一つにまとめるstream.collect(reducing()) → stream.reduce()// 要素を数字の合計にするstream.collect(summingInt()) → stream.mapToInt().sum()要素の処理// 要素の状態だけを変えるstream.map(x -> {...; return x;}) → stream.peek(x -> ...)最後に関数型プログラミングに興味がないとしても、Streamそのものはかなり魅力的なAPIですので、皆さんにもぜひ使ってみて欲しいです。Java 1.8がリリースされた当時には性能も劣り読みにくいという批判も多かったのですが、もう時間は経ち、Javaのバージョンはすでに14となっているくらいです。もうそろそろStreamを使ってモダンな書き方を試してみても良いでしょう。そしてStreamを通じて、関数型プログラミングを味わえるのも一つのメリットではないかと思います。もちろん、Streamが完璧な関数型プログラミングの例だとは言い切れませんが、少なくとも、オブジェクト指向だけでなく新しいプログラミングのトレンドはどういうものかを経験できるということだけでも十分価値があるのではないでしょうか。もう関数型プログラミングの概念が登場してからも数年が経っています。プログラミングの世界は常に変化と発達が伴うものなので、少なくとも最近のトレンドが何であるかくらいは把握しておきたいものです。では、またあいましょう！

Streamを正しく使う

この度はJava SE 8 Goldを受験しました。Silverを取ったのが去年の9月末だったので、およそ半年ぶりの受験ですね。以前、Silverの方を受験した時はポストでその感想を書いていたので、今回も同じくGold受験後の感想を書こうと思います。GenericsGenericsに関する問題は、型が明確ではない場合をとう問題が多かったです。例えばとあるクラスを継承しているクラスのみを引数として受けたい場合はどうするか、とかの問題ですね。<? super X>と<? extends X>の違いがよくわからないと難しくなる、そのような問題です。また、Genericsに関しての問題はComparator<T>とComparable<T>も登場していて、これからどう違うか、またどこで必要となるものかを理解していないと難しい問題になっていました。個人的にはあまり使ってないAPIだったので最初は苦戦した問題でした。理解できればなるほど、となりますが、これからもそんなに使うことあるかどうか…でも確かに知っておけば便利そうな気はしますので覚えておきたいAPIです。LambdaJava 1.8の重要機能であるLambdaはやはり問題数が多いです。Lambdaはただ単にメソッドの書き方が楽になったということだけではなく、それを活用できる関数型インタフェースやStreamなど、他の重要なAPIと関係がある重要なAPIですので、やはりこれがわからないと本当の意味でJava 1.8を理解していないと言えるでしょう。Lambdaに関する問題は、関数型インターフェースの条件(SAM)やjava.util.functionパッケージで提供しているインターフェースの種類を理解していないと解けないものが多い感じでした。また、Method Referenceに関する問題も出題されています。Lambdaをしっかり理解していれば書き方が違うだけというのがわかりますが、そうでないとコードすら読めないかもしれません。StreamStreamは問題の割合が多いです。Java 1.8で追加された重要なAPIの一つでもあり、今までのJavaのAPIとは性格がちょっと違うものでもあるのでなんとなく感だけで使っていた自分には大変勉強となりました。今まではせいぜいstream()やcollect()くらいしか使ってなかったのですが、今回の試験でこれから色々Streamを活用できる箇所が増えていくような気がします。個人的には既存のコードが問題なく作動していていればわざわざStreamに変える必要があるくらいではないものの、関数型プログラミングの特徴を少しでも味わえる素敵なAPIと思います。例えば問題では中間操作と終端操作の違いやそれぞれのメソッドの活用方法などに関する質問が出ていて、それらしきメソッド名を並べては「次の中、〇〇APIのメソッドとして正しいものを選びなさい」のような意味のない問題に比べ、APIそのものの特徴と使い方を理解できないと解けない問題となっている感じがして好きでした。特に、peek()やsorted()、Collectors.groupingBy()のような良いメソッドが出てきて嬉しかったです。I/O基本的にはJava 1.7から追加されたNIOに関する問題が多かったです。これもまたStreamと結び付けるためか、lines()やlist()、walk()などのメソッドに関して問う問題が多かったですね。また、同じく1.7から登場したtry-with-resourceに関する問題も出たのでよかったと思います。自分の場合はファイルI/Oで主にNIOのFilesクラスを使うことが多いので馴染んでいるのもあって、close()をわざわざ呼び出さなくても安全なAPIを提示してくれるってことはこれからの習慣にもいい影響を与えるだろうと思います。個人的には仕事でもAutoCloseableを継承したクラスを作ったこともあったので嬉しかったです。Thread並行性に関する問題も割合的には多い感じでした。AtomicIntegerやExecutorServiceのような重要なAPIを学ぶ良い機会となりましたが、せっかくRunnableやCallableまで扱っているので、CompletableFutureまで扱ってくれていたらよかったのでは、と思いました。CyclicBarrierが出ていましたが、最近はあまり使われてないらしいですしね。スレッドはそこまで難しくなく、ForkJoinPoolとCyclicBarrier、RunnableとCallableのシグニチャをちゃんと覚えておいたら解ける問題が多かった気がします。TemporalLocalDateTimeなどのAPIに関する問題が少し出ていましたが、割合は低め。Silverでも扱っていたAPIなので、こちらではフォーマッターや例外になるパターンに関する問題が多かったような気がします。ZoneIdなども出てきましたが、そこまで重要ではないような印象でした。Localeこちらもまた割合は低め。ただ、プロパティーをどう読み込むかはLocaleだけでなく環境変数などを扱う時も必要な知識となるため、覚えておくかちはあると思います。APIのシグニチャを問う問題の場合はインターネットでも十分情報を得ることができるのでわざわざ覚える必要はあるのかな？といったところですが…他にJDBCに関する問題も少々ありましたが、やはり今はあまり使われてないので問題の数は少なかったです。自分の場合はJavaでのDB処理にはMybatisやJPAを使っているのでわざわざJDBCを使うことはないのですが、基本的にJavaではこういう風にDBにアクセスして処理をしているんだな、ということだけ分かれば十分なのではと思っているので、問題の割合としては適切だったかなと。また、SilverまではJavaのAPIをちゃんと覚えているかを問う問題が多いような気がしますが、Goldからはクラス設計に関する問題もいくつか出ていて、カプセル化やシングルトンクラスをどう実装するべきかに関する問題や、Files.walk()による再帰処理などに関する問題もあったのですが、Goldを受験する人がそのような知識がないとは思えないのですね。一つ、せっかく同じような使い方(メソッドチェイン)をしていて、Streamで要素を取得する時も使えるOptionalについては言及されてないことは残念に思います。他と同じくJava 1.8で導入されたものなのになぜ…？って感じですね。最後に去年はJava SE 11の資格も登場したので、最初からそちらにした方がよかったかなとも思いましたが、Oracleの公式ホームページの試験の紹介だとJava 9から導入されたモジュールシステム以外はあまり試験の内容が変わってないようです。8も11もLTSバージョンなので、次のLTSである17がリリースされたら、おそらく資格も更新される可能性があります。個人的には12から14まで導入された新機能の方が便利だと思うので、私のように勉強の目的で受験していて、元々8の資格を持っている方ならあまり11へのアップグレードはメリットがないかもしれません。もちろん、これから初めて資格を取得する人にとっては11の方が良いでしょう。自分はそんなことも知らずにとりあえず8を受験してしまったのですが…とりまとめ、資格取得は嬉しいことですが、何よりも勉強のため始めたJavaの資格が、思っていたより仕事で役立つ知識を提供していたので満足しました。問題自体はパターンをよく覚えだけで解けるものも多いのですが、JavaのAPIに対する理解を深めたい方なら、受験してみて損することはないと思います。受検料は高いですが…

Oracle JavaSE 8 Goldについて

Springでは、application.propertiesやapplication.ymlファイルに別途設定したい項目を定義することによってデータをアプリケーションの外に出すことができます。こうしてデータとアプリケーションを分離するのは、ハードコードすることによって変更が発生した場合にアプリケーションそのものを修正する不便からの開放されることができます。しかし、こうやって別途の外部ファイルに様々な設定値を書くということは、セキュリティ問題と繋がることになる場合もあるでしょう。例えばDBなどのクレデンシャル情報や、企業の業務と関連したコードなどが平文で記載されているとしたら、ハッキングでなくても、セキュリティ問題となる可能性は十分です。こういう場合に、記載したい各種設定値などを暗号化できるといいでしょう。それを可能にするAPIがすでに存在していて、今回紹介したいものはJasyptというものです。Jasyptを使うと、平文を暗号化したり、暗号文を複合して平文に戻すことができます。Spring Boot Starterも提供しているのですでに作成済みのSpring Bootアプリケーションに暗号化機能を追加するのも簡単。では、Jasyptを使ってどうやって暗号化と複合の機能をSpring Bootアプリケーションに導入できるかを今回のポストで説明しましょう。Jasyptによる暗号化のフローJasyptを使ってのSpring Bootアプリケーションの外部ファイルに記載した設定値の暗号化と複合は、以下のようになります。EncryptorクラスをBean登録Encryptorクラスで平文を暗号化YAMLに暗号文を記載アプリケーションを起動時、YAMLの暗号文を複合して使用Jasyptで提供しているEncryptorは、デフォルトとして提供されるクラスもありますが、カスタマイズもできるので今回はその方法を紹介していきます。依存関係を追加Spring bootを基準に、依存関係は以下のように追加します。Mavenの場合<dependency> <groupId>com.github.ulisesbocchio</groupId> <artifactId>jasypt-spring-boot-starter</artifactId> <version>3.0.2</version></dependency>Gradleの場合dependencies { implementation 'com.github.ulisesbocchio:jasypt-spring-boot-starter:3.0.2'}Jasypt本体だけを普通のJavaアプリケーションで使うこともできますが、今回はSpring Bootアプリケーションを基準にしているので、設定が簡単な方を紹介しています。カスタムEncryptorを作るまずはSpringのBeanとしてEncrytorを登録します。Encryptorには様々なオプションが指定できますが、実際重要なのはパスワードとアルゴリズムです。パスワードとアルゴリズムが一致しない場合は複合ができないからです。ここではYAMLファイルにカスタム設定としてEncryptor用のパスワードを記載し、それを持ってEncryptorをBean登録する場合のコードを紹介します。@Configurationpublic class StringEncryptorConfig { // YAMLから読み込むパスワード @Value("${settings.jasypt.password}") private String password; // encryptorBeanという名前でEncryptorをBean登録する @Bean(name = "encryptorBean") public StringEncryptor stringEncryptor() { PooledPBEStringEncryptor encryptor = new PooledPBEStringEncryptor(); SimpleStringPBEConfig config = new SimpleStringPBEConfig(); config.setPassword("password"); config.setAlgorithm("PBEWithMD5AndDES"); // 以下は必須項目ではない config.setKeyObtentionIterations("1000"); config.setPoolSize("1"); config.setProviderName("SunJCE"); config.setSaltGeneratorClassName("org.jasypt.salt.RandomSaltGenerator"); config.setStringOutputType("base64"); encryptor.setConfig(config); return encryptor; }}これでEncryptorのBean登録の設定は完了です。次は外部設定ファイルの設定ですね。外部ファイルの設定外部設定ファイルでは、Beanとして登録したEncryptorの名前を指定し、暗号化したプロパティを記載します。Encryptorの名前が一致しなかったり、記載されてない場合はアプリケーションの起動時のエラーとなるので注意しましょう。application.propertiesの場合jasypt.encryptor.bean=encryptorBeanproperties.password=ENC(askygdq8PHapYFnlX6WsTwZZOxWInq+i)application.ymlの場合jasypt: encryptor: bean: encryptorBeanproperties: password: ENC(askygdq8PHapYFnlX6WsTwZZOxWInq+i)ここでお気づきの方もいらっしゃるだろうと思いますが、暗号化した項目は必ずENC()で囲まなければなりません。そうしなかった場合は、JasyptのEncryptorは設定値をそのまま文字列として読み込みますので複合されません。暗号化のアルゴリズムJasyptのパッケージを辿ると、基本的にいくつかのEncryptorが定義されていることがわかります。文字列だけでなく、数字タイプやバイナリーも暗号化できるので必要に応じてはSpringではなく、普通のJavaアプリケーションでもインポートして使うことができます。今回は文字列の暗号化だけを紹介しますが、この文字列のEncryptorには以下のようなものが予め定義されています。// デフォルトとして使われるEncryptorpublic BasicTextEncryptor() { super(); this.encryptor = new StandardPBEStringEncryptor(); this.encryptor.setAlgorithm("PBEWithMD5AndDES");}// より強いアルゴリズムを使うEncryptorpublic StrongTextEncryptor() { super(); this.encryptor = new StandardPBEStringEncryptor(); this.encryptor.setAlgorithm("PBEWithMD5AndTripleDES");}// AES256を使う最も強力なEncryptorpublic AES256TextEncryptor() { super(); this.encryptor = new StandardPBEStringEncryptor(); this.encryptor.setAlgorithm("PBEWithHMACSHA512AndAES_256"); this.encryptor.setIvGenerator(new RandomIvGenerator());}ここに記載されているアルゴリズムは、そのままBeanとして定義するカスタムEncryptorにも使えます。ただし、アルゴリズムが複雑なものであるとそれだけ暗号化した結果は複合が難しくなるので安全ですが、アプリケーション起動が遅くなる可能性もあるので場合によって適切なものを選びましょう。また、AES256を使う場合はIvGeneratorも指定する必要があるということに注意しましょう。コード内で暗号化がしたい場合は、Bean登録したEncryptorを呼ぶか、新しいEncryptorのインスタンスを作成してencrypt()メソッドを呼び出すとできます。当然のことですが、同じパスワードを指定しないと正しく暗号化と複合ができないということに注意しましょう。コマンドラインツールJasyptをダウンロードすると、コマンドラインツールで暗号化や複合ができるようになります。リンクからditributableバーションをダウンロードして解凍すると、binフォルダの中にbatファイルとshファイルが入っています。格ファイルの機能は以下となります。encrypt.sh(bat): パスワードベースで平文を暗号化するdecrypt.sh(bat): パスワードベースで暗号文を複合するdigest.sh(bat): 複合できないHashコードを生成するlistAlgorithm.sh(bat): 暗号化に使えるアルゴリズムの種類を羅列するencryptとdecryptでは、パスワードと暗号化・複合したい文をコマンドライン引数として入力するとその結果が標準出力で画面に表示されます。また、オプションとしては使いたいアルゴリズムを指定することもできます。使い方は以下のコマンドになります。bin % ./encrypt.sh password=password input=this_is_inputこのコマンドでの出力結果は以下です。----ENVIRONMENT-----------------Runtime: AdoptOpenJDK OpenJDK 64-Bit Server VM 11.0.6+10----ARGUMENTS-------------------input: this_is_inputpassword: password----OUTPUT----------------------2lgKlL4gECBBtjch4WZITWDBHWhIxvVzまた、listAlgoritymを実行すると、以下のように現在のシステムで使えるアルゴリズムのリストが出力されます。PBE ALGORITHMS: [PBEWITHHMACSHA1ANDAES_128, PBEWITHHMACSHA1ANDAES_256, PBEWITHHMACSHA224ANDAES_128, PBEWITHHMACSHA224ANDAES_256, PBEWITHHMACSHA256ANDAES_128, PBEWITHHMACSHA256ANDAES_256, PBEWITHHMACSHA384ANDAES_128, PBEWITHHMACSHA384ANDAES_256, PBEWITHHMACSHA512ANDAES_128, PBEWITHHMACSHA512ANDAES_256, PBEWITHMD5ANDDES, PBEWITHMD5ANDTRIPLEDES, PBEWITHSHA1ANDDESEDE, PBEWITHSHA1ANDRC2_128, PBEWITHSHA1ANDRC2_40, PBEWITHSHA1ANDRC4_128, PBEWITHSHA1ANDRC4_40]このリストの中のアルゴリズムはEncryptorをBean登録する時指定できるもののリストでもあるので、必要に応じて適切なものを選びましょう。強力なアルゴリズムを使うとアプリケーションの起動が遅くなる可能性もあります。(Spring BootアプリケーションのYAMLファイルは起動時に読み込まれますので)最後にアプリケーションの作りで、セキュリティの重要性はいうまでもなく高いものですね。先にも述べましたが、Springの設定ファイルでは特に、DBや外部システム連携のための接続情報などの敏感な情報が書かれることが少なくないため、外部設定ファイルがそのまま流出されたら困ることも起こり得ると思います。普段からそのようなことが怒らないように気を付けることももちろん大事ですが、こうやって暗号化によって情報を守るという手段もまた良い方法になるのでは、と思います。特に、JasyptのEncryptorは外部設定ファイルだけでなく、コードの中でも使えるので、活用できる範囲が広いですね。敏感な情報を扱っている場合は、アプリケーションの中でも積極的に活用していきたいものです。性能も安定性も大事ですが、何より情報が漏れないように、ですね。

Jasyptでプロパティを暗号化する

Springではビジネスロジックを書く場合、一般的にServiceというクラスを作成することになります。Serviceは重要な処理が入るため開発やテストでは重要なクラスですが、開発をしていると、状況によっては実装しても動かせない場合もあります。例えばまだ環境が整っていない、他のクラスに依存する設計となっているがそのクラスがまだ存在していないなどの場合ですね。こういう時は実際の処理が行われず、常に同じ結果を返すクラスを書いておく場合もあります。こういう場合に、予め複数のServiceクラスを書いておいて、外部の設定ファイル(application.yml)に開発モード、テストモードなど状況に合わせてどちらのServiceクラスを使うかを選択できたら便利でしょう。実際、ServiceクラスはInterfaceと実装クラス(Implという名の)を分けて書く場合が多いので、複数のImplクラスを作って置いて、場合によって違うものがBeanとして登録されるようにすることも不可能ではありません。なので今回は、YAMLの設定を読み、場合によってどのServieImplをBeanとして登録するかを決める方法を紹介します。Serviceの元の構成一般的なServiceクラスの構成は以下のようになります。Interfaceを作成して、それを具現化するサービスを作ることですね。そして中にはDBなどアプリの外部との連携を担当するクラスをDIして使ったりします。public interface SomeService { public void doSomething();}@Servicepublic class SomeServiceImpl implements SomeService { private SomeRepository repository; @Autowired public SomeServiceImpl(SomeRepository repository) { this.repository = repository; } @Override public void doSomething() { // ... }}ここで、テスト時に使いたいImplクラスを以下のように作成したとします。@Servicepublic class SomeTestServiceImpl implements SomeService { private SomeTestRepository testRepository; @Autowired public SomeServiceImpl(SomeTestRepository testRepository) { this.testRepository = testRepository; } @Override public void doSomething() { // ... }}こういう場合は、アプリケーションを起動するとSpringではInterfaceの実装クラスはどれ？と聞いてくることになります。一つのInterfaceに対して二つの実装クラスが存在していて、両方Beanとして登録しようとしているからです。アノテーションを削除Serviceクラスには一般的に@Serviceをつけることになります。このアノテーションをつけると、Springではこのクラスを自動的にBeanとして登録することになります。なので一つのInterfaceに対して複数の@Serviceのついたクラスを作成すると、どれを使いたいかSpringとしてはわからなくなります。なので、ここでは@Serviceアノテーションは使わないことにします。YAMLの作成YAMLの作成は簡単です。今回はbooleanを使って、trueになっていればテストモード(SomeTestServiceImplを使用)、falseになっていれば通常モード(SomeServiceImplを使用)で動くようにします。例えば以下のようなものです。settings: TestMode: trueapplication.ymlに直接このカスタムプロパティを書いても良いのですが、自作の設定なので、適当な名前をつけて別途のファイルにしても良いです。別途ファイルにした場合は、application.ymlでそのファイルを含むようにすることを忘れないようにしましょう。spring: profile: include: settings # ファイル名がapplication-settings.ymlの場合Configuration設定アノテーションを外したら、ServiceImplはBeanとして登録できなくなります。しかし、使いたいServiceImplクラスを選ぶということは、状況によって使いたいクラスをBeanとして登録したい、ということです。なのでどこかでクラスを選び、Beanとして登録するようにする必要がありますね。また、YAMLに書いた設定を読み込む必要もあります。これらをまとめて@Configurationのついたクラスとして実装しましょう。@Configurationpublic class SomeServiceConfig { // YAMLに設定した値を読み込む @Value("${settings.TestMode:false}") private boolean testMode; // YAMLの設定からどのImplクラスを使うかを決定してBean登録 @Bean public SomeService someService(SomeRepository repository, SomeTestRepository testRepository) { return this.testMode ? new SomeTestSerivce(testRepository) : new SomeServiceImple(repository); }}Springでは@Valueや@ConfigurationPropertiesを使うことでYAMLに指定した値を読み込むことができます。@ConfigurationPropertiesだとクラス全体のフィールドに対してYAMLの値をマッチすることができますが、ここでは一つの値を読み込みたいだけなので、個別フィールドに対して使える@Valueを使います。YAMLファイルがない場合は例外となるため、デフォルト値としてfalseを指定しておきました。Bean登録は普通に@Beanアノテーションをつけ、新しいインスタンスを作成して返すだけです。今回の例ではSerivceImplで依存しているRepositoryクラスをコンストラクターにAutowiredを使って注入しているため、そのインスタンスも必要となりますね。メソッドの引数にRepositoryを書いておけば、それがBeanとして登録されているクラスだと自動的に引数として入ってきます。なのであとはこれがテストモードであるか、通常モードであるかによってそれぞれのコンストラクターに合わせた引数を渡し、インスタンスをリターンすればBean登録も完了となります。簡単ですね！アノテーションを使う場合Beanを状況により切り替えたいといった場合に、@Profileアノテーションを使う方法もあります。こちらもやり方は難しくありません。まずYAMLファイルを以下のように定義したとします。spring: profile: active: devYAMLの定義ができたら、あとはどのプロファイルを使うかをアノテーションで指定します。以下のコードのようにです。@Configurationpublic class SomeServiceConfig { // devやdebugの場合はこちらをBean登録する @Bean @Profile({"dev", "debug"}) public SomeService someService(SomeTestRepository testRepository) { return new SomeTestSerivce(testRepository); } // prodの場合はこちらをBean登録する @Bean @Profile("prod") public SomeService someService(SomeRepository repository) { return new SomeServiceImple(repository); }}@Profileアノテーションでは指定できるプロファイルを配列で指定できるため、YAMLの記載によってどんなBeanを登録するかを簡単に指定できます。どちらの方法をとっても良いので状況によって適切な方法を選びましょう。最後に最近はDjangoやExpressなど、他の言語のウェブフレームワークにも触れてみたいと思っていますが、日々新しい発見と勉強が続いているので、なかなかSpringから離れることができません。こうやってできること、知らなかったことを発見するたびに、他にも良いフレームワークがありながらSpringがエンタープライズ市場で長い間生き残ることができたのはこのようにできることが多いからなのではないか、という気もします。Springだけでもしばらくブログに載せる記事のネタは尽きないかもですね！

ServiceのImplクラスをYAMLで選択する

ウェブアプリケーションを開発していると、一つのRest APIだけで全ての機能を自己完結させる必要はない時もあります。例えば組み込みたい機能がすでに実装されているサーバー(API)が存在している場合もありますね。そういう場合は、素直にそのAPIをコールするだけで簡単に目的を達成できます。実際、仕事で他のRest APIサーバーとの通信が必要となって調べてみましたが、Springではすでにそのような場合に対応できるようなクラスを用意していました。今回のポストの主人公であるRestTemplateです。RestTemplateを使うと、簡単にget・post・deleteと言ったHttpメソッドのAPIをコールできます。また、リクエストやレスポンスをカスタムして状況に合わせて使うこともできます。例えばカスタムヘッダーを作ったり、サイズの大きいファイルを転送するリクエストを作ることも可能ですね。なので今回はRestTemplateを利用し、ファイルをアップロードするとそのファイルになんらかの処理をして返してくれるAPIがすでに存在している場合で、そのAPIをコールする部品を作る方法を紹介します。サーバー側の例すでにファイルを処理するサーバーが存在している場合のことですので、まずはコールしたいAPIで利用するリクエストとレスポンスの形を把握する必要がありますね。ファイルをアップロードされたら、ヘッダーからファイル情報を読み込むようになっていて、ファイルデータが書かれているボディを読み込むようなメソッドがあるとしましょう。ヘッダーの情報に問題がなかったらローカルストレージにファイルを書き込み、処理を行います。そして処理の終わったファイルはレスポンスとして返すサーバーです。@PostMapping("/upload")public ResponseEntity<StreamingResponseBody> fileupload(HttpServletRequest request) { // リクエストヘッダーからファイルサイズを取得 long fileLength = request.getContentLengthLong(); // ファイルサイズが0だとIOException if (fileLength == 0) { throw new IOException("data size is 0"); } // ファイルを臨時ファイルとして保存 String fileName = request.getHeader("Content-File-Name"); Path tempFile = Files.createTempFile("process_target_", fileName); try (InputStream is = request.getInputStream()) { Files.copy(is, tempFile); } catch (IOException e) { e.printStackTrace(); } // ...ファイルを持ってなんらかの処理を行う // レスポンス用のヘッダーを作る HttpHeaders headers = new Headers(); // 処理が終わったファイルを書き込むボディを作る StreamingResponseBody body = new StreamingResponseBody() { @Override public void writeTo(OutputStream outputStream) throws IOException { byte[] bytes = Files.readAllBytes(path); outputStream.write(bytes); } }; // ヘッダーとボディ、HttpStatusをセットしてレスポンスを返す return new ResponseEntity<StreamingResponseBody>(body, headers, HttpStatus.OK);}サーバーがこういう形になっている場合、APIをコールする側としてはRequestのヘッダーにはファイル情報を書き、ボディにはファイルのデータを書いて転送する必要がありますね。そして処理結果のResponseにもまたファイルデータが入ってあるので、それを受け止める処理が必要となります。そのためにリクエストもレスポンスもカスタムのものを作って、RestTemplateに載せることにしましょう。RestTemplateを使う今回はRestTemplateのexecute()というメソッドを使いますが、このメソッドの引数は以下のようになります。APIのURL(StringもしくはURI)Httpメソッド(ENUM)リクエスト(RequestCallbackの実装クラス)レスポンス(ResponseExtractorの実装クラス)get()・post()・delete()などのメソッドの時と違ってリクエストとレスポンスの方を両方指定する理由は、上に述べた通りリクエストとレスポンスの両方でファイルの転送が必要からです。また、execute()でも引数にURI変数を指定することもできますが、現在はURIが固定なので使いません。では、リクエストとレスポンスのインタフェースをどう実装するかをみていきましょう。リクエストリクエストで使うRequestCallbackの実装クラスを作成します。このインタフェースにはコンストラクターの引数としてファイルを渡すとヘッダーとボディを作るようにしてみましょう。RequestCallbackをimplementsすると、doWithRequest()というメソッドをオーバーライドするようになります。このメソッドの引数であるClientHttpRequestにヘッダーとボディを設定することでリクエスト時のファイルアップロードができます。以下のコードを参照してください。public class FileTransferRequestCallback implements RequestCallback { // アップロードしたいファイル private Path path; // ヘッダーにファイル情報を載せるためのコンストラクター public PdfConvertRequestCallback(File file) { this.path = file.toPath(); } @Override public void doWithRequest(ClientHttpRequest request) throws IOException { // ファイルからヘッダーを作る request.getHeaders().set("Content-Length", Files.size(path)); request.getHeaders().set("Content-File-Name", path.getFileName().toString()); // ボディにファイルを書き込む try (InputStream is = Files.newInputStream(file); OutputStream os = request.getBody()) { is.transferTo(os); } }}ヘッダーにはサーバーで要求するファイルサイズとファイル名を載せました。そしてアップロードするファイルをInputStreamとして取得して、OutputStreamであるボディに書き込みます。これでリクエストでのファイルアップロード設定は終わりです。次はレスポンスですね。レスポンスレスポンスでは、ResponseExctractorをimplementsします。この場合はextractData()というメソッドをオーバーライドするようになります。このメソッドの引数であるClientHttpResponseからはリクエストの時と同じくHttpステータスコード、ヘッダー、ボディを取得できます。このレスポンスの結果からResponseEntityのインスタンスを作成し、レスポンスの結果を載せて返すとRestTemplateからは通信の結果としてResponseEntityを返すようになります。ResponseEntityを返すためにはそのボディの型を指定する必要があります。InputStreamの型を指定して、レスポンスのボディがファイルであることを指定しましょう。また、ClientHttpResponseのボディをResponseEntityにそのまま載せると、InputSteamがCloseされるのでボディはコピーしておきます。私は一回byte[]に変えて、さらにByteArrayInputStreamを生成することにしました。public class FileTransferResponseExtractor implements ResponseExtractor<ResponseEntity<InputStream>> { @Override public ResponseEntity<InputStream> extractData(ClientHttpResponse response) throws IOException { // レスポンスのボディをコピー byte[] bytes = response.getBody().readAllBytes(); // ステータスコード、ヘッダー、ボディのデータを載せてResponseEntityを返却 return ResponseEntity.status(response.getStatusCode()).headers(response.getHeaders()).body(new ByteArrayInputStream(bytes)); }}これでレスポンスのファイルを取得できるようになりました。次は、RestTemplateでAPIをコールするだけです。Rest APIのコール先に述べましたが、RestTemplateのメソッドを実行するのは簡単です。まずはURLと、アップロードしたいファイルのインスタンスを作っておきましょう。そして、先ほど作成したRequestCallbackとResponseExtractorのインスタンスも作成します(ResponseExtractorは、状態を持たないのでBeanとして登録しても良いです)。execute()の引数に、URL・Httpメソッドのタイプ・RequestCallback・ResponseExtractorを指定して実行すると、その結果をResponseEntityとして取得できて、そこからさらにステータスコード、ヘッダー、ボディを取得できます。これでアップロードしたファイルを処理してもらい、処理結果のファイルも即取得可能になりますね。// RestTemplateに渡す引数を準備String url = "http://api/v1/file/upload";File uploadFile = new File("path/to/upload_file.txt");FileTransferRequestCallback requestCallback = new FileTransferRequestCallback(uploadFile);FileTransferResponseExtractor responseExtractor = new FileTransferResponseExtractor();// RestTemplateでAPIコールし、その結果を取得ResponseEntity<InputStream> responseEntity = new RestTemplate().execute(url, HttpMethod.POST, requestCallback, responseExtractor);// ResponseEntityからHttpステータスを取得if (responseEntity.getStatusCode() != HttpStatus.OK) { throw new IOException();}// ResponseEntityからヘッダーを取得HttpHeaders headers = responseEntity.getHeaders();// ResponseEntityからボディを取得try (InputStream is = responseEntity.getBody()) { File downloadedFile = new File("path/to/downloaded_file.txt"); Files.copy(is, downloadedFile);}意外と簡単！これで他のRest APIとのファイルのやりとりができるようになりました。最後にクラスやメソッドを機能別に分けるだけでなく、Rest APIもまた機能によっては分離されることもありますね。今回の場合がまさにそのような例でした。もちろんネットを経由するのでこのようなやり方は一つのRest API内に機能をまとめて置くよりは安定性が劣るかもしれませんが、再使用性が確保できるという面では良い方法ではないかと思います。同じサーバー内だと通信失敗の確率も下がるだろうし、色々と活用できる余地はありそうですね。最近はなかなかブログに載せられるようなコンテンツがなかったので(勉強は続けているつもりですが…)、次は何を書けばいいかなと悩んでいましたが、ちょうど面白い部品を作ることができてよかったです。Springの世界も本当に広くて奥深いものですね。では、また！

Rest APIからRest APIにファイルを送る

Javaは長い間業界で生産性、性能、安定性で評判がよく、最近はバージョンアップも様々な機能が追加されています。仕事では主に11バージョンを使っていますが、次のLTSバージョンである17がリリーズされたらそちらを使うことになるのではないかと思います。なので今も新しいバージョンが発表されると一応更新履歴には目を通していますが、言語仕様そのものが変わる場合は新しいAPIの追加と比べ少ない気がしなくもないです。Javaが人気を得た理由の一つの生産性という部分では、今じゃPythonやJavaScriptなどに比べて劣る部分もあり、「コードが読みやすい」というメリットも、いつの間にか「冗長すぎる」という評価と変わってしまいましたね。自分はJavaが好きで、まだ言語そのものの仕様まで見切ってはいないですが、それでも使いながらこれは不便だな、これは他の言語と同じくなって欲しいなと思う時もあります。今回のポストでは仕事でJavaを扱いながら感じた不便なところ、また他の言語と比べて改善したいところについて述べたいと思います。こうして他の言語と比べ、Javaがどんなものであるかを把握していくのもまた一つの勉強になるのでは、と思いますので。Optional表記の改善以前のポスト](../java-optional)で紹介したOptionalですが、これはJavaだけでなく他の言語でも多く採用しているAPIの一つですね。むしろ、JavaのOptionalが他の言語から影響され導入されたものらしいです。今は私自身もよく使っていて、すごい便利だと思っていますが、それでも他の言語と比べたらやはり不便と思うところがあります。他の言語と比べてコードが冗長であることがJavaの特徴と先に述べましたが、実際のコードではどうかをまず比較してみましょう。複雑にネストしているオブジェクトのとあるフィールドを読み、Nullだった場合はデフォルト値を返却する例を持って説明します。JavaJavaのコードでは、最初のオブジェクトをOptionalでラップし、ネストされているフィールドやメソッドに対してmap()をチェーニングしていくことで次から次へとラップの対象を変えていきます。そして最後に、ターゲットのオブジェクトがNullだった場合はorElse()などのメソッドでデフォルト値を設定しますね。// 元のオブジェクトSomeClass object;// 複雑にネストされているOptional.ofNullable(object).map(obj::getProp1).map(prop1::getProp2).map(prop2::getProp3).orElse("default");C#言語そのものがJavaと似ているC#ですが、より若いからか、Javaと比べ進んでいる部分がよく見当たるC#です。こちらでもKotlinとコードの書き方は同じです。違うのは、オブジェクトそのものがNullになる可能性を事前に宣言しないということだけですね。object?.prop1?.prop2?.prop3? ?? "default";JavaScriptJavaScriptのOptionalもまた、C#とあまり変わらないです。object?.prop1?.prop2?.prop3? ?? "default"SwiftSwiftでもそう変わりません。object?.prop1?.prop2?.prop3 ?? "default"KotlinKotlinもデフォルト値指定のためのElvis opertor特有の表現を覗くと、一緒ですね。object?.prop1?.prop2?.prop3 ?: "default"他の言語の例と比べて見ると、JavaのOptionalは確かに冗長な印象ですね。なので今後Optionalを言語の基本仕様として導入し、ラップをするのではなく?として表現できるようにしたらどうかという気もします。?を導入したところでコードの読みやすさを損ねるわけでもないですので。Multiple Return StatementsJavaの仕様ではメソッドの戻り値となれるオブジェクトは常に一つのみですが、Pythonのような言語では戻り値を複数指定することができます。もちろん、Javaの戻り値が一つという制約を乗り越えるためによくBeanやCollectionに複数のオブジェクトやデータを入れて返すことはできるのでこれはシンタックスシュガー的なものになるだけですが、それでも便利な方法があったら使いたくもなります。Javaメソッドの処理結果として複数のデータを受け取りたい場合、Javaだと先に述べたようにBeanやCollectionを使うことになりますね。以下は戻り値が複数の数字である例です。// 複数の戻り値を持つメソッドpublic List<Integer> multipleReturn() { return Arrays.asList(1, 2);}// 戻り値の取得List<Integer> data = multipleReturn();C#C#でもJavaと似たようなやり方で複数のデータを取得することができますね。実際はref/outパラメータを使ったり、structやclassを使う方法もあるらしいですが、Javaと比べより便利ではないかと思うのはTupleを使う場合です。C#のバージョンによって書き方が違っていて、昔の書き方ではJavaでCollectionを使うのとあまり変わらないものの、新しい書き方ではかなり便利なものとなっています。以下はその二つの例のコードです。// 複数の戻り値を持つメソッド(7以前)public Tuple<int, int> oldMultipleReturn(){ return Tuple.Create(1, 2);}// オブジェクトとして取得var result = oldMultipleReturn();// 複数の戻り値を持つメソッド(7以後)public (int, int) newMultipleReturn(){ return (1, 2);}// 変数として取得(int one, int two) = newMultipleReturn();PythonPythonの例では、7以後のC#と似たような感覚でコードを書けます。オブジェクト(tuple)として戻り値を全部取得するか、個別の変数として取得するか両方一つのfunctionでできるのがより便利な気もしますね。# 複数の戻り値を持つfunctiondef multiple_return(): return 1, 2# 個別の戻り値を取得a, b = multiple_return()print(a) # 1# 戻り値をtupleとして全取得d = multiple_return()print(d) # (1, 2)JavaScriptES6から導入された書き方ではPythonと似たようなコードで複数の戻り値を取得できます。// 複数の戻り値を持つfunctionfuntion multipleReturn() { return { first: 1, second: 2 }}// 個別の戻り値を取得var (first, second) = multipleReturn()SwiftSwiftはやはりOptionalと同じく、JavaScriptとあまり変わりません。// 複数の戻り値を持つfunctionfunc multipleReturn() -> (Int, Int) { return (1, 2)}// 個別の戻り値を取得let (first, second) = multipleReturn()KotlinKotlinではPairかTripleなどがあり、使い方は簡単です。// 複数の戻り値を持つfunctionfun multipleReturn(): Pair<Int, Int> { return 1 to 2}// 個別の戻り値を取得val (first, second) = multipleReturn()Javaでのコードの書き方の方がメソッドの役割をわかりやすいというメリットはありますが、戻り値のオブジェクトやデータをそのまま変数として使えるという面ではPythonのやり方がより便利ですね。このように複数の戻り値を持つメソッドを定義できるのは現代プログラミング言語ならどれもが持っている機能のようです。Javaにもいつかは導入されるのでしょうか？引数の種類をor指定たまに、一つのメソッドで引数の型を複数指定できたら便利ではないだろうかと思うことがあります。Javaではこれをオーバーロードで実現していますね。Javapublic void doSomething(String value) { // Stringの場合の処理}public void doSomething(int value) { // intの場合の処理}もちろん、引数の型をObjectとして宣言し、内部ではinstansofを使って判定することもできます。しかし、前者ならやりたいことに比べコードの量が増えすぎる問題がありますし、後者なら意図した型以外のObjectが渡された場合の挙動がおかしくなる可能性もあります。TypeScriptTypeScriptでは、これを簡単に引数のタイプを複数指定できるようにすることで解決しています。function checkString(v: string | number) { if (typeof v === "string") { return true } return false}これまで引数の種類だけ違う場合はオーバーロードして、共通処理だけprivateメソッドで書いていましたが、これならよりコードを簡単に把握できそうですね。ぜひ導入して欲しい機能の一つです。Ternary Operator with Throw結果が二択しかない場合は、なるべくifより三項演算子を使った方がコードも短くなり便利と思います。しかし、Javaの三項演算子では例外を投げることができません。条件式に当てはまらない場合はどうしても以下のようなコードを書くしかないです。// xが0だとnumberも0で、0ではなかった場合は例外とするint number = x -> { if (x == 0) { return x; } else { throw new RuntimeException(); }}無理やり三項演算子で例外を投げようとしたら、以下のような方法はありますね。// Genericな戻り値を持っていて、例外を投げるだけのメソッドpublic <T> T throwSomeException() { throw new RuntimeException();}// elseでメソッドを呼ぶint number = x == 0 ? x : throwSomeException();個人的にif文は二択しかない結果のために使うのはスペースの無駄遣いと思いますし、無理やりメソッドを作ってまで三項演算子を使う必要はないので、三項演算子でelseの場合には単純に例外を投げられるといいな、と思っていました。そして調べてみると、他の言語ではそれができるようです。C#C#では、二つのやり方があります。まず7以前だと、elseの場合に例外を投げるFuncを実行させることで実現できます。そして7以後では普通に三項演算子でthrowできるようです。まさに私が望んでいた形ですね。// 7以前int number = x == 0 ? x : new Func<int>(() => { throw new Exception(); })();// 7以後int number = x == 0 ? x : throw new Exception();KotlinKotlinでは三項演算子がなく、if-elseを使うことになるということだけで、簡単な形になっています。val i = if (x == 0) x else throw Exception("error")JavaScriptJavaScriptでは、7以前のC#と似た形で例外を投げることができます。var number = (x == 0) ? x : (function() { throw "error" }());わざわざ関数を実行してまで三項演算子で例外を投げたくはないですが、こういうやり方があるということがわかっただけでもかなり興味深いですね。JavaにもC#の7以後のような書き方ができるといいな、と思います。アクセス修飾子の拡張Javaでのアクセス修飾子は、public・private・protectedをよく使っています。しかし、自作ライブラリーを作る場合はpublicとprivateの中間的なものもあって欲しいな、と思う時もあります。例えばJarにまとめた時、Jar以外ではアクセスできないようなアクセス制限をかけられるようなものですね。Java 9からモジュールが導入されましたが、自分が経験した問題もあるのでなるべくモジュールを使いたくはないなと思っているので…同じプロジェクトの中ならパッケージが違ってもアクセスできるような修飾子があったらいいな、と思います。また、protectedならサブパッケージでも参照できるなど。同じモジュール内でのみのアクセス修飾子はC#とSwift、KotlinでInternalとして提供しているので、Javaにも導入されるといいですね。最後に最近のJavaの更新履歴をみると、続々と便利な機能が導入され続けています。特に14では、recordでLombokの@Dataと同じ機能を持つクラス宣言ができるようになるらしいです。次のLTS版は17なので、まだ十分色々と改善される余地はありますね。1.8でも便利な機能は多いですが、これからもどんどん他の言語の良い点を吸収して変転できるといいなと思います。また、こうやって他の言語ではどうしているかを調べてみるのも良い勉強となりました。特にTypeScriptは最近注目している言語なので、機会があれば経験してみて、Javaとの比較もしてみたいものですね。では、また！

Javaはこう進化して欲しい

前回までご紹介したJenkinsでのジョブ生成は、どちらかというと、古いやり方によるものでした。実際、2016年にJenkinsが2.0にアップデートされながら、スクリプトでジョブを作成できるPipelineというものが導入されていました。Pipelineではgroovyを使って、実行したいコマンドやタスクなどをステージという単位で書きます。書いたスクリプトは上から順次実行され、各ステージごとに実行結果を画面上に表示してくれます。今までのJenkinsジョブと比べ使い方がかなり違うので、今回はそのPipelineジョブを作成する方法をサンプルを持って紹介したいと思います。Pipeline使うと何が嬉しい？まずは普通のジョブと比べ、どんなメリットがあるかを知りたいですね。既存のFreestyleジョブでなく、PipelineでJenkinsのジョブを作成すると以下のようなメリットがあります。スクリプトなので管理がしやすいファイルとしても管理ができるので、Gitなどでバージョンコントロールができます。作成が簡単Snippetを提供するので簡単にスクリプトを作成できます。ジョブの成功・失敗履歴を簡単に確認できるステージ単位でジョブを実行するので、どのステージが成功・失敗したか簡単に確認できます。Pipelineジョブ内のステージに関する実行履歴はGUIから表示され、簡単に確認できる実行ログを提供しています。以下のような画面です。Pipeline作成チュートリアルPipelineジョブの作成では、まずPipelineジョブを作成する手順を簡単に説明していきましょう。ジョブ作成画面からジョブ名を入力して、Pipelineを選択します。PipelineスクリプトPipelineでジョブを作成すると、ジョブで実行する項目を指定する画面もFreestyleジョブとは違うものになります。ビルドトリガーなどの設定は同じですが、画面を下にスクロールしてみるとPipelineというタブがあることを確認できます。ここに直接スクリプトを書くか、Gitなどで管理しているスクリプトファイルを指定するかで何を実行するか選べられます。しかし、いきなりスクリプトを書くのも難しいことです。まず画面の右にあるtry sample Pipeline…をクリックしてみましょう。まずはHello worldを選んでみます。Pipelineのスクリプトはgroovyを使っていますが、groovyの文法をまず勉強する必要はありません。サンプルのコードは他にもあるので、それらを参考してどんな書き方をするかを確認しましょう。また、Pipelineスクリプトに慣れてない人のためにJenkinsではSnippet作成機能を提供しています。実行したいタスクをドロップダウンメニューから選び、必要なパラメータなどを入力すると自動的にスクリプトを生成してくれる便利な機能です。Pipelineのスクリプト入力欄の下にあるPipeline Syntaxをクリックすると以下のような画面が表示されます。最初からスクリプトを手で書いても良いですが、どう書いたらわからない場合はこちらの機能を使いましょう。Pipelineの実行結果完成したPipelineジョブを実行するとステージ別に成功と失敗の結果が表示されます。先ほど作成したHello Worldサンプルの場合の実行結果画面です。ここでは各ステージをクリックすると、ステージ別に書いたタスクに対して結果を確認できます。Logsをクリックしてみましょう。Log画面ではステージで実行したコマンドやタスクの結果がそれぞれ出力され、実行時間と共に詳細を確認することもできます。Pipelineスクリプトの構造では、簡単にPipelineスクリプトがどんな構造となっているかもみていきましょう。Pipelineスクリプトはまず以下のようなコードで定義します。pipeline { // この中に実行するエージェントやステージを書く}実行エージェントの設定pipelineブロックを書いたら、次はpipelineを実行する環境を設定します。単純にJenkinsが起動しているインスタンスの中での実行ならagent anyと書くだけですが、最近はジョブを実行するためだけのDockerコンテナを使うことも多いようです。その場合は実行環境としてDockerコンテナを指定する必要がありますね。以下のようなコードでコンテナを指定します。pipeline { agent { docker { image '実行したいイメージ' args 'イメージを実行する時に渡すコマンドライン変数' // 省略可能 } }}ステージを作る環境まで設定できたら、次は実行したいタスクを書きます。ここで大事なのはステージという概念です。Jenkinsの公式サイトではステージブロックを「Pipeline全体で実行するタスクの明確なサブセット」として定義しています。つまり、ステージ一つが一つのタスクの段階という意味でしょう。ステージの中では一つのタスク単位であるステップを定義し、ステップの中で実行するコマンドを書きます。pipeline { agent { // Docker環境 } stages { stage('ステージ名1') { steps { // 実行したいコマンド } } stage('ステージ名2') { // ... } // ... }}Pipelineそのものに対する説明は以上となります。では、次に実際のPipelineジョブを書いたらどんな形になるのかを紹介します。Pipelineスクリプト例題以下のジョブをPipelineで作ると仮定して、簡単な例題を作ってみました。実行環境はopenjdkコンテナ(rootユーザー)Gitでソースコードをチェックアウト(ディレクトリはspringboot)gradlewタスクを実行してwarファイルを作る出来上がったwarファイルをAzure Blobにアップロードこれを実際のコードで表現すると以下のようになります。pipeline { agent { docker { image 'openjdk' // openjdk公式イメージを使用 args '-u root' // ユーザーをrootに指定 } } stages { stage('Checkout') { // Gitチェックアウトステージ steps { checkout([$class: 'GitSCM', branches: [[name: '*/ブランチ']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'RelativeTargetDirectory', relativeTargetDir: '保存するディレクトリ']], submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'GitクレデンシャルID', url: 'https://Gitレポジトリ']]]) } } stage('Build') { // ビルドステージ steps { dir(path: 'springbootapi') { // 作業ディレクトリを指定 sh './gradlew bootWar' } } } stage('Upload') { // ビルドしたwarファイルをAzure Blobにアップロードするステージ steps { dir('springbootapi/web/build/libs'){ azureUpload storageCredentialId: 'ストレージクレデンシャルID', storageType: 'blob', containerName: 'コンテナ名', filesPath: '**/*.war' } } } stage('Finalize') { // 作業が終わるとワークスペースを削除するステージ steps { cleanWs() } } }}まだPipelineのコードに慣れてないと難しいと思われるかもしれませんが、Pipeline Syntaxを活用するとすぐかけるものなので皆さんもぜひ挑戦してみてください。最後に最初Jenkinsに接した時もこんなに便利なツールがあるとは！と思いましたが、Pipelineの導入でさらに便利かつ明確にタスクがわかるようになっていて驚きました。最近はAzure Pipelinesを少し触る機会があったのですが、そちらのジョブ作成もこのJenkinsのPipelineを意識した感じです。これからのCI/CDツールは多分言語や文法は違っても、どれもこのような形になるのではないかと思うくらい良い変化です。皆さんもぜひJenkinsのPipelineに触れて、快適なビルド・デプロイを楽しんてみてください。では、また！

Jenkins Pipelineを使う

私がそうでしたが、今でも初めてJavaでのI/Oを学ぶとしたら、やはりFileオブジェクトを生成してInputStreamで読み込んだり、OutputStreamで書き込むのが一般的なのではないかと思います。ここで少し発展すると、WriterやReaderなどのクラスを使ったり、StreamをBufferで包んだり、SerializableでオブジェクトのI/Oを行ったりするレベルまで行くのでしょう。昔のAPIだとしても、動作や性能に大した問題がなければあえて新しいAPIにコードを全部変える必要はないと思います。むしろ無理やり新しいAPIに書き換えたコードが問題を起こす可能性もあるし、常に優秀とは言えませんので。例えばJava 1.8で追加されたforEach()は便利で、Lambdaが好きな私は多くの場面で使っていますが、実際は今までのJVMは伝統的なforループに最適化されているのでforEach()は性能で劣るらしいです。今後、forEach()の性能がより良くなる可能性もなくはないでしょうが、最近のJavaのバージョンアップ履歴をみると関数型APIの性能改善にどれだけ時間がかかるかは少し謎です。新しいAPIを使うということにはこのような問題もあり、慎重ではければならないのですが、それでもAPIが新しくなるのには何らかの理由があるためなので、新しくコードを書いたり簡単なコードに変えたりするなどの理由があれば、積極的に新しいAPIを導入してみるということもそう悪くないと思います。今回紹介したいAPIもまたそのようなものです。ファイルI/Oを扱う新しい方式、NIOです。(と言っても、Java 1.7から導入されたので今はあまり新しくもないですが…)NIOって何？NIOは、Javaの新しいI/Oのことです。Newの略かと思いがちなのですが、実際はNon-blockingの略らしいですね。JavaはCやC++と比べ遅いですが、その理由の一つがI/Oだったらしいです。なのでそれを改善するために出たのがこのNIOですと。BlockingかNon-blockingかによる違い、Stream基盤かChannel基盤かという違いなど様々な違いがありますが、一般的には頻繁なI/Oが要求される場合ではNIOを選択した方がより良い性能を期待できると言います。他には以下のようなメリットがあります。スレッドのブロックが発生しないコードがより簡潔コピー、移動、読み込みのオプション指定が簡単基本的にBufferを使うので、Buffered~でのラッピングが要らなくなるあまりJVMの構造に詳しくないので、私がここで浅い知識を持って説明するようなことはしません。ただ、自分の観点からしてコードがより簡潔になるということは確かなメリットです。なので皆さんにもぜひ使ってみていただきたいと思います。それでは、実際のコードでNIOをどう使うかについて説明して行きます。File → PathNIOではFileオブジェクトよりPathオブジェクトを使います。PathはFileオブジェクトに比べ、ファイルパスをディレクトリとファイル名で分離して指定できるのが最大のメリットです。例えばファイルパスが複数のフォルダでネストされているとしましょう。// 複数のディレクトリとファイルがそれぞれ文字列として存在(path/to/file.txt)String rootDirectory = "path";String toDirectory = "to";String fileName = "file.txt";この複数の文字列からインスタンスを作成するとしたら、Fileのコンストラクターは引数が一つの文字列なので以下のようになります。ディレクトリの文字列にスラッシュが含まれてないので、文字列を結合しながらスラッシュも一緒にいれる必要があります。// Fileオブジェクトの生成File file = new File(rootDirectory + "/" + toDirectory + "/" fileName);しかし、Pathの場合は指定できる文字列が複数でも構いません。ディレクトリとファイル名の文字列を順番通り指定するだけで良いです。// Pathオブジェクトの生成Path path = Paths.get(rootDirectory, directory, fileName);このように、インスタンスの作成がより便利なのがPathです。また、どうしてもFileオブジェクトが必要な場合があるとしても、FileのメソッドからPathに変換できる機能があるので便利ですね。もちろん、その逆もできます。// PathからFile生成Path path = file.toPath();// FileからPath生成File file = path.toFile();他にもtoURI()メソッドでURIオブジェクトを生成できるなど、PathにはFileと同じ機能をするようなメソッドが多いので、どちらか便利な方を使いましょう。Files昔ながらのI/Oでファイルのコピーや削除などの操作を行うためにはInputStream、OutputStream、Writer、Readerなどのクラスを活用してきました。NIOでは主にこれらの作業をFilesクラスを持って行います。また、FilesクラスにはWriterとReader、InputStreamとOutputStreamを生成する機能もあるので使い勝手が良いクラスです。ファイルのコピーFilesクラスでのファイルコピーは簡単です。以下のコードを見てください。基本的にコピー元とコピー先のファイルをPathオブジェクトとして指定するだけです。// PathをPathにコピーFiles.copy(source, target);FilesクラスでのコピーにはENUMでコピー時のオプションを指定することもできます。// オプションを指定(ファイル属性もコピー)StandardCopyOption option = StandardCopyOption.COPY_ATTRIBUTES;Files.copy(source, target, option);また、実際存在するファイルではなく、InputStreamをコピー元として指定することもできます。この場合、データをファイルに書き込むということもできますね。// InputStreamをPathにコピーFiles.copy(sourceStream, target);ファイルの削除Filesクラスでのファイル削除はコピーと同じく、Pathオブジェクトを引数として渡します。// 削除Files.delete(path);戻り値がbooleanのメソッドも用意されています。ファイルが存在する場合は削除して、その結果をbooleanとして返します。// 存在する場合削除Files.deleteIfExists(path);ファイルの移動ファイルの移動は、コピーと削除の組み合わせみたいなものですね。また、ファイル名を変える場合にも使えます。基本がコピーだからか、コピーの時と同じオプションを使えます。// 移動もしくはリネームFiles.move(path);// オプションを指定(上書きする)StandardCopyOption option = StandardCopyOption.REPLACE_EXISTING;Files.move(path, option);ファイルの書き込みInputStreamをcopy()で使えるのですが、ファイル書き込みの場合のメソッドもあります。// Pathにデータを書き込むFiles.write(path, content);write()メソッドの引数として渡せるのはbyte[]、List<String>などがあります。また、コピーの場合のようにオプションが指定できます。こちらのオプションではファイルが存在する場合上書きするか、追記するかを選べるので場合によってはcopy()と分けて使えます。// オプション指定(追記)StandardOpenOption option = StandardOpenOption.APPEND;Files.write(path, content, option);ファイルの読み込み書き込みが文字列かbyte[]で分けられているように、読み込みも同じ形でファイルを取得できるメソッドがあります。文字列取得の場合、シンタックスシュガーとして結果物がStreamかListかくらいの違いがあります。// 文字列として全行を読み込むStream<String> lines = Files.lines(path);List<String> liness = Files.readAllLines(path);// byte[]として読み込むbyte[] bytes = Files.readAllBytes(path);Fileがそうであるように、Pathもまたファイルではなくディレクトリになれるので、Filesのメソッドもそれに対応しています。list()メソッドではディレクトリないのエントリをPathとして取得してStreamを生成します。// ディレクトリ内のエントリを要素として持つStream取得Stream<Path> files = Files.list(path);I/Oとの組み合わせで使う先に述べたように、Filesのメソッドの一部は昔ながらのI/Oと組み合わせて使えるものもあります。その一部を紹介します。// 読み込みの場合InputStream is = Files.newInputStream(path);BufferedReader br = Files.newBufferedReader(path);// 書き込みの場合OutputStream os = Files.newOutputStream(path);BufferedWriter bw = Files.newBufferedWriter(path);もちろんOpenOptionの指定もできます。// ファイルがない場合は作成するStandardOpenOption option = StandardOpenOption.CREATE;InputStream is = Files.newInputStream(path, option);最後にどうでしたか。同じ機能をするだけならあまり使いたくなるメリットはないように見えるかもしれませんが、実際使ってみると、ENUMによるオプション指定でやりたいことが明確となって、コードの量も減らすことができる便利なクラスを提供するのがNIOだと思います。特にFileはそのまま使うとしても、Filesのメソッドは便利かつ強力なので、皆さんにぜひお勧めしたいものです。他にもFilesクラスには双方通信ができるというChannelクラスを提供するメソッドや、ファイルの属性、シンボリックリンクを取得したり指定したPathがディレクトリかを確認したり、二つのPathが同じファイルかをチェックするなど便利なメソッドが多いので、ぜひ使ってみてください。では、また！

IOからNIOへ

Nullチェックの地獄から脱出したい

一般的なJavaプロジェクトなら、外部設定ファイル(YAML)を記載してその値を読み込む場合なら私の以前のポストのようにできます。しかし、今回はSpringプロジェクトとして同じようなことをするようになりました。SpringはYAMLを読み込む時に固有の仕様や使い方がありますね。そしてそうやって読み込んだYAMLの値はBeanに設定することができて、アプリケーションの中ではどこでも@Autowiredを使って呼び出せるというメリットがあります。しかし、そんな便利なDIですが、使い方の難点もあります。例えば、普通にnewして使うインスタンスのなかで@Autowiredは使えない問題があるということです。今回もかなりハマっていたことなのですが、Builderでオブジェクトを作成するようにして、使用者が指定してない値はYAMLから取得したBeanを使いたかったです。でもBuilderだと新しいインスタンスを作ってしまうので、Beanを読み込めなくなっていたのでかなりはまりました。結果的には違う方法をとると、@AutowiredなしでもBeanを取得することができるということがわかったので、今回のポストではそれに至るまでの過程をコードを持って述べていきたいと思います。YAMLの作成から、newしたインスタンス内でBeanを取得して使う方法を紹介します。YAMLからBeanを作るSpringではapplication.ymlに以下のように記載して、特定のYAMLを読み込むという指定ができます。spring: profiles: active: buildingdefaultここでactiveに記載したものを使って、カスタムYAMLファイルを準備します。ファイル名のプレフィックスとしてはapplication-が入ります。なので今回のファイル名はapplication-buildingdefault.ymlになりますね。ファイルを作成して、以下のように項目と値を記載します。settings: material: "cement"作成したYAMLファイルはsrc/main/resourceにおきます。そしてこれからはSpringでYAMLを読み込むためのクラスを作成します。SpringでYAMLを読み込み、Beanを作成する方法は二つがあります。一つ目はまず、フィールドにアノテーションをつけてYAMLの項目と紐づくことです。@Getter@Componentpublic class DefaultSettings { @Value("${settings.material}") private String material;}フィールドに@Valueをつけて、アノテーションの引数としてYAMLの項目名を入力します。こうすることでYAMLから読み込まれた値はString形でBeanに取り込まれます。フィールドは必ずStringである必要はなく、intやdoubleなどのプリミティブ型はもちろん、ENUMにも対応しています。Localeならja_JPなどとYAMLに記載しておくと、ちゃんと取り込まれます。YAMLの値をBeanにするもう一つの方法は、フィールドではなくクラスにアノテーションをつけることです。以下のように@ConfigurationPropertiesの引数にprefixを指定すると、指定した項目の配下にあるもの全てがフィールドのマッピング対象となります。@Data@Configuration@ConfigurationProperties(prefix = "settings")public class DefaultSettings { private String material;}YAMLから複数の設定を読み込みたい時YAMLから設定値を読み込む際に、設定を複数を記載して状況に合わせて使いたい場合もあります。もちろんYAMLでは配列での記載ができますし、Springで読み込む時もこれをListにすることができます。なのでどうやって複数の設定をBeanにするかを説明します。YAMLでは以下のように記載します。settings: - preset-name: "default" material: "cement" - preset-name: "cabin" material: "wood"ここでpreset-nameは、実際Javaで設定を使う時にそれぞれの設定セットを区別するためのキー的なものです。なくても値を読み込むには問題がないですが、こうやって名前をつけておくとのちにどれがどれかを分かりやすくなりますね。YAMLの記載が終わったら、それぞれの設定セットに合わせてBeanクラスを作成しておきます。@Datapublic class Material { private String presetName; private String material;}最後に、YAMLを読み込むクラスを作成します。このクラスにBeanのListをフィールドとして記載すると、Springアプリケーションの起動と同時にこれらの設定が読み込まれることを確認できます。@Data@Configuration@ConfigurationProperties(prefix = "settings")public class MultiSettings { private List<Material> presets;}のちにこのクラスからListを取得して、presetNameで各設定値を探すだけで簡単に使えるようになります。BuilderからBeanを使う(失敗の例)今までの設定で、普通のSpringアプリケーション内ではBeanをDIして使うことができるようになります。しかし、今回はDIなしてBeanを取得する方法を説明するためのポストになっていますので、その過程を説明します。まず自分がやりたかったことは、先に述べましたが、Builderの中でYAMLの値を読み込んでいるBeanを使うことでした。ここでYAMLに記載した値はデフォルト値として使われて、必要に応じて一部の項目だけbuild()時に上書きしたいです。まず試して、ダメだったコードは以下のようなものです。public class Building { public static BuildingBuilder() { return new BuildingBuilder(); } public static class BuildingBuilder { // DIができない @Autowired private DefaultSettings settings; private String material; public BuildingBuilder() { this.material = this.settings.getMaterial(); } ... }}Builderを使うと、まずBuilderのインスタンスを新しく生成するしかないです。そしてnewしたインスタンスの中では@Autowiredで記載していても、DIがまともにできません。実際上のようなコードを書くと、BeanのフィールドがNullになっていることを確認できます。なのでDIのことは忘れて、newしたインスタンスの中でBeanを取得できる方法をとります。ApplicationContextProviderを作るApplicationContextは、SpringでBeanの生成やオブジェクト間の関係設定など様々な機能を担当するインタフェースです。ここで重要なのは、ApplicationContextがSpringアプリケーションを起動する時予め登録されたBeanを生成して管理するということです。つまり、このインタフェースにアクセスできればBeanを取得できるということになります。ただ、ApplicationContextそのものはあくまでインタフェースであるため、インスタンスを取得するためにはその役割をするクラスを作成する必要があります。以下のコードでインスタンスを取れるようになります。@Componentpublic class ApplicationContextProvider implements ApplicationContextAware { private static ApplicationContext context = null; public static ApplicationContext getApplicationContext() { return this.context; } public void setApplicationContext(ApplicationContext context) throws BeansException { this.context = context; }}構造は簡単で、フィールドにApplicationContextがあって、それに対するGetterとSetterがあるだけです。これで動くのも不思議ですが、Springアプリケーションが動作すると自動的にApplicationContextのインスタンスがSetterを通じてフィールドにセットされます。ただ、このクラスのインスタンをnewしては使えなくなるのでフィールドとGetterはstaticにしておきます。BuilderからBeanを使う(成功の例)それでは、ApplicationContextのインスタンスを取得できるようになりましたので、Builderを修正します。public class Building { public static BuildingBuilder() { return new BuildingBuilder(); } public static class BuildingBuilder { private DefaultSettings settings; public BuildingBuilder() { this.settings = ApplicationContextProvider.getApplicationContext().getBean(DefaultSettings.class); } ... }}さっき作成したApplicationContextProviderクラスからApplicationContextを取得して、さらにgetBean()を呼び出します。このgetBean()に引数として取得したいBeanのクラスを渡すと、そのBeanのインスタンスを取得することができます。もちろんコンストラクターではなく、フィールドそのものに書くこともできます。そうする場合は以下のようになりますね。public class Building { public static BuildingBuilder() { return new BuildingBuilder(); } public static class BuildingBuilder { private DefaultSettings settings = ApplicationContextProvider.getApplicationContext().getBean(DefaultSettings.class); public BuildingBuilder() { } ... }}修正したコードを動かしてみると、BeanのフィールドがNullではなくちゃんとYAMLから読み込んだ値が入っていることを確認できます。最後にSpringを使いながら、恥ずかしくも実際アプリケーションの内部ではどんなことが起きているかを知らなかったので今回は失敗したのではないかと思います。ただ単に動くことを確認するだけでなく、こうして自分の使っている言語やフレームワークの特性をちゃんと理解していないとこのようにハマることはなかったでしょう。なので新しい知識を得た同時に、自分に対する反省もすることになりました。これからはちゃんと自分が使っているものはどう、なぜ動くのかをちゃんと理解してから使わないとですね。

newしたインスタンスの中でBeanを使いたい

Springの代表的な特徴といえば、それは色々ありますが、一つをあげるとしたらやはり@AutowiredによるDI1ではないかと思います。初めてSpringに接したときはオブジェクトがnewなしでも動くと言うことが何ともいえない不思議なことに見えました。これがデザインパターンの一つであるということを知ってからはますますすごいなぁと思いましたね。やはり良いコードを書くためには、様々な方面での工夫が必要なものですね。とにかく、こうも重要で便利なDIですが、最近Spring Bootを触りながら気になったことがありました。今までは当たり前のように、@Autowiredはフィールドに宣言していましたが、今回の案件ではコンストラクターにつけている場合がありました。なぜ一部はフィールドにつけ、一部はコンストラクターにつけるんだろう？と思いましたね。結果的には全てのアノテーションをコンストラクターにつけることになりましたが、それが特にフィールドにつける場合との違いを理解させたわけではないので、少し調べてみました。結論からいうと、大概の場合に@Autowiredはフィールドよりはコンストラクターにつけた方がいいらしいです。そしてこれを(フィールドやコンストラクターに@Autowiredをつけることを)、それぞれ「フィールドインジェクション」と「コンストラクターインジェクション」と呼ぶらしいです。では、これらをコードを持って説明していきましょう。Field Injectionまずインジェクションのために以下のようなコンフィギュレーションクラス2を定義したとしましょう。@Configurationpublic class Mapper extends ModelMapper { @Bean public Mapper mapper { return new ModelMapper(); }}ここではModelMapperを使ってみます。ModelMapperに関しては、以前のポストにも書きましたが、互いにマッチングするGetter/SetterのあるBean同士のマッピングを自動で行ってくれる便利なライブラリーです。こうしてSpringでBeanを登録し、Autowiredアノテーションをフィールドにつけるサービスクラスの例が以下です。これをフィールドインジェクションと呼びます。@Servicepublic class ItemServiceImpl implements ItemService { @Autowired private Mapper mapper;}自分が最初にSpring Frameworkについて学んだ時はこのようなフィールドインジェクトションが一般的でした。しかし、フィールドインジェクションでは致命的な問題があリます。ここでフィールドがNullだった場合もプログラムは動作するということです。クラスの動作に必要な要件が整ってないのにもかかわらず、プログラムが動作してしまうのはバグを呼ぶこととなりますね。なのでフィールドインジェクションはよくないです。Setter Injection実は、インジェクションはSetterを通じても可能らしいです。あまり一般的な方式ではありませんが、これをセッターインジェクションと呼び、コードで表現すると以下のようになります。@Servicepublic class ItemServiceImpl implements ItemService { private Mapper mapper; @Autowired public void setMapper(Mapper mapper) { this.mapper = mapper; }}Setterによるインジェクションの問題は、フィールドインジェクションと同じです。Setterで必要なオブジェクトが注入されたかどうかと関係なくプログラムは動く可能性がありますね。この問題を解決できるのが、次に紹介するコンストラクターインジェクションです。Constructor Injectionコンストラクターによるインジェクションはコンストラクターインジェクションと呼び、コードは以下のようになります。@Servicepublic class ItemServiceImpl implements ItemService { private Mapper mapper; @Autowired public ItemServiceImpl(Mapper mapper) { this.mapper = mapper; }}コンストラクターによるインジェクションの良い点は、先に述べたような問題が発生する可能性をブロックできるということです。これはSpringというよりJavaの言語仕様の話ですが、コンストラクターで引数の要件が満たされてないクラスはインスタンスを生成できませんね。そしてNullを注入しない限り、NullPointerExceptionは発生しなくなります。また、コンストラクターインジェクションだと、循環参照3の問題を事前に防ぐことができるというメリットがあります。フィールドインジェクションやセッターインジェクションでは実際のコードが呼ばれるまでは問題を発見することができませんが、コンストラクターインジェクションで循環参照が発生する場合はSpringアプリケーションを起動する時に警告が出力されます。また、フィールドインジェクションの場合はそのクラスの単体テストができないという問題もあります。Autowiredアノテーションがついているフィールドに対してオブジェクトを注入できる方法がないですので。Setterを使うと一旦注入はできるようになりますが、あえてSetterを使う理由はないですね。コンストラクターインジェクションが良いもう一つの理由は、フィールドをfinal宣言できるということです。フィールドにfinalをつけることでクラス内でオブジェクトが変更されることを防止できるので、より安全になります。最後に今までは自分も当たり前のことのようにフィールドインジェクションを使っていましたが、フィールドインジェクションの問題を知ってからはなるべくコンストラクターインジェクションとしてコードを書くようにしています。あえてそうしなくても、IntelliJでは常にコンストラクターインジェクションを使うことと警告まで出すみたいで、Springの公式のドキュメントでもそういう言及がありました。これは今までの認識を変えざるを得ません。SpringだけでなくJavaコーディングの話をすると、コンストラクターは基本的に書かなくても暗黙的に引数なしのものが生成されるのがJavaの仕様ですね。Singletonクラスや引数の初期化なしで動くと問題になるクラスではこれを防ぐためにわざとコンストラクターを書くこととなっています。なので常にコンストラクターは明示的に書いておく習慣も大事ですね。こういうことも含めて考えると、コンストラクターを記述することの重要性がわかるような気もします。やはり良いコードを書くには、様々な方面での工夫は必要なものですね！Dependency Injection(依存性の注入)。ネット上に詳しい説明が多いので深くは入りませんが、簡単に概念を説明するとオブジェクトを外部から生成してコードに入れることでオブジェクトの依存性をコードから独立させることを意味します。注入されたオブジェクトはコードに依存してないので、どこで呼ばれても同じものとして機能することができます。 ↩︎Configurationアノテーションをつけると自動的にSpring内で設定クラスとして認識されます。ここでオブジェクトをBeanとして定義すると、DIができるようになります。以前はxmlファイルに記入しておく場合もありました。 ↩︎循環参照とは、複数のオブジェクトが互いを参照していることを意味します。例えばAクラスのインスタンスを生成する時にBを参照することとなっていて、BクラスもAクラスを参照することとなっていると、どちらかのインスタンスを作成する時に互いの参照を繰り返す無限ループに落ちてしまいます。この無限ループの果てはStackOverflowですね。 ↩︎

SpringのDIはコンストラクターでしましょう

実家で使っているルーターは、Asus社のRT-AC58Uです。そして個人的に使っているものは同じくASUS社のRT-AC68U。この二つは単にマシンスペックだけでなく、ファームウェアレベルで提供している機能も少し違います。例えばAiMeshといった機能はRT-AC58Uでは対応していません。そしてこないだファームウェアをアップデートすると、管理ページにWANからアクセスするにはhttpsしかできないという制約ができました。RT-AC68Uの場合はLet’s encryptでSSL証明書1を作成して更新まで自動で行われる機能を持っているので特に問題はないですが、残念ながらRT-AC58Uはそうではないです。なのでいつもブラウザからRT-AC58Uの管理ページに接続すると証明書がおかしいと怒られます。これから修正される可能性もなくはないと思いますが、最近は802.11axに対応した新型が続々と登場しているので、もう古くなってしまったRT-AC58Uのファームウェアバージョンアップがいつまで続くかわからない状態です。そして毎回証明書がおかしいと怒られるのをみると少し不安になりますね。実家と家のルーターの場合、ソフトウェアそのものはそう変わらないだろうと思って調べてみたらやはりそうでしたので、手動でもSSL証明書を入れられる方法がありそうな気がしました。もっと調べてみるとOSはLinuxであって、結論から言うと58Uにも証明書を入れることは成功しました。今回はそのSSL証明書をRT-AC58Uに適用させるまでの方法を記載します。システム構成現在のシステム構成図を絵で表現するとこちら。ここでやりたいことは、DDNS2を登録したルーターにSSL証明書を入れ、httpsで接続した管理ページで怒られないようにすることです。これを試した理由のもう一つはのちにこのルーターの下にホームサーバーとして機能するLinuxのマシンもおきたいからでもあります。ホームサーバーにはのちに簡単なWebアプリケーションを置いて運用する予定で、今回試したことが成功したら同じ仕組みでそちらにもSSL証明書を適用できると思います。それでは、自分がどうやってSSL証明書を作成してルーターにアップロードし、適用したかを述べていきます。ルーターの設定(1)ルーターではまず、DDNS設定が必要です。ASUS社のルーターの場合、Chromeなどのブラウザーからhttp://router.asus.comを入力するとローカルのルーターの管理ページにアクセスできます。そして「詳細設定」メニューから「WAN]を選び、さらにDDNSのタブに入って好みのアドレスとして登録します。ASUS社のルーターはasuscomm.comという無料のサーバーを提供しているのでそちらを使いましょう。DDNSの登録ができたら、「管理」メニュー配下の「システム」タブで「WANからの接続を許可」を「はい」にしておきます。私は家から接続するために事前に実家のルーターで予めDDNSの設定をしておきました。DDNSでの管理ページ接続設定が終わったら、次はルーターへのSSH接続を設定します。こちらも同じく「管理」ページから設定することができます。SSHを接続設定が終わったらテストをして、なるべく公開鍵でアクセスできるようにして、ポート番号も変えておきましょう。SSHのポートを変えた場合は、ターミナルでは以下のコマンドでアクセスできます。# SSHのポートが2022の場合$ ssh -p 2022 retheviper@javaman.asuscomm.comSSH時のIDとアドレスは管理ページのIDとDDNSで登録したものとなります。ここまでできたらSSL証明書を作成するためのルーター側の準備はまず終わります。macでの設定(1)ルーターのOSはLinuxとなっていますが、やはり重要なコマンドがいくつか足りていないです。代表的にパッケージ管理用のyumやapt、dnfのどちらも搭載されていなく、CPUの性能も怪しいので重要な作業はまずmacで行うことにしました。また、SSL証明書自体はRT-AC68Uで対応しているLet’s encryptを使います。こちらは有効期間が90日にすぎないですが、発給も更新も無料となっているのでこういう簡単な作業で使うには最適です。まず、ターミナルでLet’s encryptをインストールします。brew install letsencryptインストールが終わったら、certbotコマンドで証明書を作成できます。ただ、証明書を作成する前にDDNSを登録して置く必要があります。私はすでにルーターで提供している機能でドメインを登録してあるので、それをそのまま使います。sudo certbot certonly --manualコマンドを入力すると以下のような画面が出力されます。ただ、自分は何回か同じコマンドを実行しているので初めての実行で出力される画面は少し違う可能性はあります。Saving debug log to /var/log/letsencrypt/letsencrypt.logPlugins selected: Authenticator manual, Installer NonePlease enter in your domain name(s) (comma and/or space separated) (Enter 'c'to cancel): [ドメイン]ルーターで使っているDDNSのドメインを入力してエンターを押下すると次の画面へ。Obtaining a new certificatePerforming the following challenges:http-01 challenge for [ドメイン]- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -NOTE: The IP of this machine will be publicly logged as having requested thiscertificate. If you're running certbot in manual mode on a machine that is notyour server, please ensure you're okay with that.Are you OK with your IP being logged?- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -(Y)es/(N)o: YIPが記録されることに同意しますかという質問が表示されます。同意するしかないのでYを入力。すると以下の画面が現れます。- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Create a file containing just this data:[コード]And make it available on your web server at this URL:[httpアドレス]- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Press Enter to Continueこの画面で一旦作業を止め、画面に表示されるコードとURLはコピーしておきましょう。あとでここに戻ってきます。PCでの設定先ほど出力された画面は、「このURLにリクエストを送るので、このコードがレスポンスとして取得できるようにしてください」という意味です。なので一時的にサーバーを立てて、レスポンスできるようにしておく必要があります。ただ単にサーバー上でアクセスできるファイルを作る方法もありますが、別の方法を試すことにしました。準備するものはルーターに繋がっているPC上でレスポンスの提供ができるサーバーを立てること。ルーターの性能が十分であればルーターでやっても良いのですが、自分のRT-AC58UはPythonをダウンロードして圧縮ファイルを解凍するだけでもしばらく死んでいました。ここではPCにNode.jsを使って簡単サーバーを作ってみます。他にPythonやRubyなどを使っても構いません。これはあくまで自分が最速でサーバーを立てられる方法がNode.jsだっただけです。実家のPCはWindowsなので、公式ホームページからNode.jsをダウンロードしてインストールします。また、expressを使ってサーバーを構築することにします。インストールが終わったらコマンドラインからnpmを使えるようになリます。以下のコードでexpressのスタータープロジェクトを作ることができます。> mkdir node> cd node> npm install expressこのあとはVSCodeなどのテキストエディタを使って、以下のコードを作成します。ファイル名はapp.jsにして、先ほどexpressをインストールしたフォルダに保存します。先ほどコピーしておいたURLとコードはは忘れずに入力しておきましょう。var express = require('express') , http = require('http') , app = express() , server = http.createServer(app);app.get('/[コピーしておいたhttpアドレス]', function (req, res) { res.send('コピーしておいたコード'); });server.listen(80, function() { console.log('Express server listening on port ' + server.address().port);});ファイルを保存したらコマンドラインから実行して、サーバーを起動します。以下のコマンドで実行できます。> node app.jsサーバーが起動したら、ローカルからアクセスできるか確認します。ブラウザーでURLを入力してみて、ちゃんとコードが表示されるかを確認できたらPCでの設定は終わりです。macでの設定(2)PCでサーバーを起動している状態でmacに戻ります。エンターを押下するとサーバーとの通信が始まって、結果として以下の画面が出力されます。Waiting for verification...Cleaning up challengesIMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/javaman.asuscomm.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/javaman.asuscomm.com/privkey.pem Your cert will expire on 2020-02-14. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-leSSL認証書の作成が無事完了しました。この画面からは認証書が保存された位置と、満了日を確認できます。また、cerbot renewを入力すると更新ができるということを教えてくれます。SSL証明書を作成したので、あとはルーターにコピーして適用するだけです。まず画面に表示されたパスに入って、以下のファイルをコピーしておきましょう。cert.pemkey.pemコピーができたら、ルーターに接続します。ルーターでの設定(2)SSHでルーターに接続して以下のパスに移動します。cd /tmp/etcディレクトリー内のファイルをみると、先ほどコピーしておいたファイルと同じものが置かれてあるのを確認できます。viでファイルをあけ、先ほどコピーしておいたもので上書きします。cert.pemとkey.pemの上書きが終わったら、次にルーター内でのプロセス目録を確認します。すでに管理ページがhttpdsのサービスとして実行されているため、新しい証明書を適用するためには一回サービスを終了して再実行する必要があります。ps以上のコマンドを入力すると、現在実行中のプロセスの目録が出力されます。そのうち、httpds -s -i br0 -p 8443があればそれを終了させます。8443は管理ページで指定したデフォルトのポート番号です。プロセスの左に出力されるのがプロセスのID(PID)なので覚えておきましょう。その後は以下のコマンドを入力します。# PIDが562の場合$ kill 562# プロセスの再実行$ /usr/sbin/httpds -s -i br0 -p 8443 &&を入力しないと他のコマンドを入力できなくなるので注意しましょう。入力が終わり、もう一度psを入力してちゃんとプロセスが起動していたらこちらでの設定は終わり。exitを押してsshから抜け出した後は、ブラウザからルーターの管理ページに接続して証明書で怒られるかを確認します。今までの過程で特に問題なかったら、問題ないはずです。ただ一つ、注意しなければならないことはルーターの再起動です。自分は週に一回は再起動するようにしていますが、こういう場合はせっかく入れたSSL証明書の値が初期化されるみたいです。なので再起動はなるべくしないか、再起動後には証明書を入れ直す必要があります。最後に以上のことで特に問題がなかったら、WANからルーターの管理ページにアクセスしても証明書がおかしいと怒られるようなことはなくなります。これで安心して外からの管理ができますね！ただ、これで全てが完璧になったわけではないです。残りのタスクは以下です。証明書の更新はどうするかルーターの再起動にどう対応するかLet’s encryptで作成してもらった証明書は有効期間が90日なので、のちに更新する必要があります。更新自体はcertbotのコマンドを打つだけで簡単に終わりますが、更新後の処理(ルーターにアップロードする、アプリケーションを再起動する)が必要となりますね。こちらはcrontabでスケジューリングすると何んとかなりそうですが、残念ながらルーターにはコマンドとして入ってなかったです。ルーターが再起動した時もどう対応できるかは検証対象ですね。最初はscpでファイルを上書き、httpsdプロセスも再起動するようなシェルスクリプトを作ることで対応できるかと思ったら、権限問題があったりするのでより簡単にできる方法はないか考えています。ま、結果的にLinuxでサーバー構築ができたらWANからルーターの管理ページに接続するようなことはなくなる可能性もなくはないですが。とにかく何かわかったらまたポストとして書くことにしましょう。それでは、皆さんもぜひ、SSL証明書で安全かつ快適なWeb生活を！SSL証明書とは、このサーバーは信頼できるかを証明してくれる電子文書のことです。SSL証明書を適用することによりhttpsでの通信は第三者の攻撃より守られます。 ↩︎Dynamic Domain Name Systemの略で、家庭用のルーターはIPアドレスが動的に変わることが多いですが、これを文字列のホスト名とつなげてくれる便利なサービスです。ルーターのIPアドレスがどうかわろうが、DDNSの設定ができていたらいつでも同じURLからルーターにアクセスできます。 ↩︎

ルーターにSSL証明書を入れる

アプリケーションを作る場合、考慮しなければならないことの一つは「設定ファイルを作る」ことです。設定値のデータがアプリケーションの内部にあると、ディコンパイルしない限りそれを変えられる方法がなくからですね。なので一般的にはアプリケーションの柔軟性のためにも動的に変える必要のある設定値はアプリケーションの外に別途のファイルとして置く場合が多いです。ゲームでいえばセーブファイルみたいなものですね。外部のファイルを読み込むことに関してはすでに様々な方法があるとは思いますが、今回は自分で使っている方法を共有します。簡単に、外部設定ファイルはYAMLで記載してプログラムの起動時に読み込んでシングルトンクラスのフィールドとして持す方法です。I/Oを一回だけにできて、どこからも参照できるというメリットがあります。設定ファイルのフォーマットとしてYAMLを選定したのは、書きやすく読みやすいというメリットもあって、自分が主に扱っているSpringで使っているためでもあります。JSONでも問題はないですが、項目が増えるほどJSONは読みづらくなるので…とにかく、準備するものはYAMLを読み込むためのライブラリーです。ここではSnakeYamlを使います。ファイルを読み込んでオブジェクト化するだけなので他のライブラリーを使っても構いません。では、まず以下のようなYAMLファイルがあるとしましょう。Development: id: "develop" version: 8 use_local_storage: trueDebugging: id: "debug" version: 11 use_local_storage: falseDevelopmentとDebuggingという二つのケースでそれぞれ違う値を使いたい、というシナリオで簡単に書いてみました。これを利用するコードは以下です。// 共用の設定情報クラスpublic final class Settings { // シングルトンクラスなので自分のインスタンスを持っている private static final Settings UNIQUE_INSTANCE = new Settings(); // 設定ファイルから読み込んだ値を一次的に入れておくためのフィールド private static final Map<String, Map<String, Object>> SETTINGS_FROM_FILE = new HashMap<>(); // 設定ファイル名 private static final String SETTINGS_FILENAME = "application-settings.yml"; // Developmentの設定情報が入るMap @Getter(lazy = true) private final Map<String, Object> developmentSettings = setDevelopmentSettings(); // Debuggingの設定が入るMap @Getter(lazy = true) private final Map<String, Object> debuggingSettings = setDebuggingSettings(); // イニシャライザーブロックで最初からファイルを読み込む処理 static { // ファイルを指定して読み込む ClassLoader classloader = UNIQUE_INSTANCE.getClassLoader(); URL resource = classloader.getResource(SETTINGS_FILENAME); try (InputStreamReader reader = new InputStramReader(resource.openStream())) { // 読み込んだYAMLファイルをパースしてMapに値を取り込む Yaml yaml = new Yaml(); Map<String, Map<String, Object>> importedMap = autoCast(yaml.load(reader)); // 読み込んだ値をフィールドのMapに移す for (Map.Entry<String, Map<String, Object>> entry : importedMap.entrySet()) { SETTINGS_FROM_FILE.put(entry.getKey(), entry.getValue()); } } catch (IOException e) { // 例外処理 } } // コンストラクターは外部からアクセスできない private Settings() { } // Lazy Getterで要請が入った時点でインスタンスを作るためのメソッド private Map<String, Object> setDevelopmentSettings() { return Collections.unmodifiableMap(SETTINGS_FROM_FILE.get("Development")); } // Lazy Getterで要請が入った時点でインスタンスを作るためのメソッド private Map<String, Object> setDebuggingSettings() { return Collections.unmodifiableMap(SETTINGS_FROM_FILE.get("Debugging")); } // 外部からインスタンスを取得するためのGetter public static Settings getInstance() { return UNIQUE_INSTANCE; } // オブジェクトのキャストをより簡単にするためのメソッド @SuppressWarnings("unchecked") private static <T> T autoCast(final Object object) { return (T)object; }}ここではLazy Getterを使ってDevelopmentとDebuggingの設定のフィールドが、get要請が入った時点でインスタンスが作られるようにしています。こうしている理由は、イニシャライザーブロックでファイルを読み込んだ後から個別フィールドに値を入れたい + フィールドはprivate finalにしたい + Settingsクラスはシングルトンとしてプログラムの起動時にインスタンスが生成されるようにしたいからです。Lazy Getterを設定しておくとprivate finalを維持しつつ、フィールドの初期化は後に担保できて、一度インスタンスが生成されるとキャッシュとして残りますので便利です。もしこうでなく、コンストラクターやフィールドで初期化しようとするとその時点がファイルを読み込む前となってしまうので注意しましょう。最後に今回紹介したコードを使うと、設定クラスはシングルトンクラスとしてアプリケーションの起動時にインスタンスが生成され、その時ファイルを読み込んでMapとしてメモリー上に載せ、どこからでも固定された値をGetterで取得できます。もしYAMLの設定がより深くネストしたり、項目が増えたり、ファイル名が変わったりする場合はMapとフィールドを調整するだけで簡単に変更ができますね。単純に動くだけでなく、維持補修が簡単で無駄のないコードを書くことこそが重要なので、何か頻繁に変わるデータを扱うためにはこう言った仕組みを(自分が紹介したものと同じではなくても)考える必要があるのでは、と思います。これからもどんなものが良いコードなのかを常に意識しないと、ですね。

外部設定ファイルを扱うクラスを作る

今回のポストでは、スキルといっても大したものはないですが、自分がコードを書きながらこれは便利だな(もしくは単に格好いいな)と思ったコーディングスキル的なものをいくつか集めました。StreamでListの変換以下のような二つのクラスがあるとしましょう。コードの量を減らすためLombokを使っていると仮定します。@Getterpublic class Item { private String value;}@Setterpublic class Product { private String value;}業務的にこの二つのクラスのフィールドであるvalueが同一なものと仮定します。そうすると、Itemクラスからvalueを取得してProductクラスに取り込むことが必要な状況もあるでしょう。このような場合、オブジェクトがそれぞれ一つだけだとあまり問題にならないですね。public Product setProductValueFromItemValue(Item item) { Product product = new Product(); product.setValue(item.getValue()); return product;}複数の項目をマッピングする必要があるなら、ModelMapperのようなライブラリを使う方法もあります。同じような名前のGetter/Setterがあると自動でマッピングしてくれるので便利ですね。public Product setProductValueFromItemValue(Item item) { ModelMapper mapper = new ModelMapper(); Product product = mapper.map(item, Product.class); return product;}しかし、これらがListやMapに入っているとどうするのでしょうか。普通にFor文のなかで同じくマッピングをさせる方法がありますね。public List<Product> itemListToProductList(List<Item> itemList) { List<Product> productList = new ArrayList<>(); for (Item item : itemList) { productList.add(mapper.map(item, Product.class)); } return productList;}これをStreamとLambdaを利用して、より簡単なコードにすることができます。public List<Product> itemListToProductList(List<Item> itemList) { List<Product> productList = itemList.stream().map(item -> mapper.map(item, Product.class)).collect(Collectors.toList()); return productList;}やっていることはFor文とあまり変わりません。元のリストから要素を一つづつ取り出し、マッピングして新しいオブジェクトを作る。そしてそれを取り集めて新しいListを生成していますね。ただ、map()の引数はLambdaなのでただのマッピングだけでなく、より複雑な処理を入れることもできます。同じことをするとしてもより簡単で短いコードが完成されます。CollectionでImmutableImmutable、すなわち不変クラスについては前回のポストでも扱いました。今回はCollectionを使って、そのクラスのListやMapもImmutableにする方法について述べます。下のコードは、Listの例です。public List<Item> returnAsUnmodifiableList(List<Item> list) { return Collentions.unmodifiableList(list);}同じ方法で、Collentions.unmodifiableMap()でラッピングするとMapもImmutableにできます。こう変換されたListやMapは変更が不可能になるため設定系などのデータを持っている場合に有効活用できます。ただ、Nullが入るとNullPointerExceptionが発生するため注意しましょう。包みたいListがNullになる可能性がある場合はCollection.emptyList()を代わりに入れることができます。逆に、ImmutableになったListやMapを変更したい場合は新しいオブジェクトに複製します。public List<Item> returnAsModifiableList(List<Item> list) { return new ArrayList<>(list);}ただ、こうしてオブジェクトを複製してデータを変更する場合、元のImmutableなListにも反映されるので注意する必要があります。カスタムクラスをIterableにするとあるクラスの中に、子要素のクラスがListとして入っているとします。例えば、以下のようなイメージです。public class Container { private List<Baggage> baggages = new ArrayList<>();}場合によっては、このクラスの中の子要素を全部取り出してFor文を書きたい場合もあるはずです。そういう場合は普通、こんな形で使うのではないかと思います。public void printBaggageNames(Container container) { List<Baggage> baggages = container.getBaggages(); for (Baggage baggage : baggages) { System.out.println(baggage.getName()); }}でも、このクラス自体を拡張For文のなかで使えるとしたら、より便利になりますね。つまり、以下のように使えるとしたいということです。public void printBaggageNames(Container container) { for (Baggage baggage : container) { System.out.println(baggage.getName()); }}もしこれができたら、Getterは要らなくなって、よりシンプルなコードがかけますね。また、Listそのものを取得させるわけではないので、Immutableにする必要もなくなります。これはIterableを使うことで具現化できます。public class Container implements Iterable<Baggage> { private final List<Baggage> baggages = new ArrayList<>(); @Override public Iterator<Baggage> iterator() { return baggages.iterator(); }}こうすることで簡単に、親クラスから子要素を拡張For文の中で使えるようになります。簡単ですね！最後にそこまで高級スキル的なものはなかったのですが、覚えておくとどこかで必ず役に立ちそうなスキルをいくつか集めてみました。これらは実際の仕事でも使っているものであって、とりあえず「動けばいい」レベルを超えて行きたい時に有効活用できるようなものではないかと思いました。こういう細かいところでのスキルの差が、プログラマーとしての実力に繋がるものではないでしょうか。そう思って、今後からも何かわかったらまたポストとして作成したいと思います。では、また！

Javaの色々なコーディングスキル

現代のプログラミングは、半分インターネットでなされていると言っても過言ではないでしょう。言語やMWの公式ガイドラインだけではなく、ウェブ上の数多くのコミュニティで情報を得られる時代ですからね。そしてMavenやGradleのように、依存関係の管理自体がネットに繋がっていることを前提としているものもあります。私もそういうトレンドから離れてはなく、自分が書いているコードで問題が発生するととりあえず検索で調べてみる方です。時間はかかっても、大概はそうすることで解決できますね。しかし、そんな便利ながらもネットで知識を求める行動にはリスクもあります。果たしてその情報が正しいかという問題ですね。まずコーディングに関する情報だと、私の基準では2年以上立っているものなら信じがたいものとなります。当時はそれが正解だったとしても、今はそうではない可能性がありますので。例えば同じライブラリーを使っているとしても、バージョンアップによりパッケージの構成が変わったり、メソッドのシグニチャーが変わったりしますが、ネットにある全ての情報がそのような変更まで全部反映しているとは思えません。実際動いたというコードが書かれているとしても、そのコードはあくまで普通のテキストであって、現在コンパイルして動かすことのできるものでもないですしね。今回の主題であるGradleのdependenciesをどう書くべきかというのも、そういう意味でのものです。私自身も今まで依存関係を書くときは、公式で提案しているコードやブログなどを参照してコピペしていました。しかし、そうしていると同じライブラリーでもcomplieだったりimplementationだったりruntimeだったりしていて、かなり混乱するものでした。結局どんな書き方をとるとしてもその結果は同じように見えるのに、こうして区分している理由は何かと思いました。そして結局、その疑問の答えは自分がとある問題に直面することで得られました。なので今回はただ単に理論の話ばかりではなく、問題が起こり得る場所とその解決法についてのものでもあります。compile? implementation?ネットでGradleで依存関係を書く方法を調べると、同じライブラリーでもその書き方がcompileだったりimplementationだったりしますね。現時点でそのうちどれを使ってもまず動きはするので、一見何の問題も内容に感じされます。しかし、問題はcompileです。このキーワードは多分、依存関係を表現する最も古い記述法です。実際の検索結果が一番多いような気もしますね。意味的にも、このライブラリーをコンパイル時に使うのような感覚なのでわかりやすいと思います。ただ、Gradleの4.7バージョンのJava Library PluginのDependency managementタブを参照すると、compileはDeprecated1と書いてあります。このポストを書く時点での安定化バージョンは5.6で、今後6.0が予定されているのでこちらはなるべく使わない方が良さそうです。公式の文書を参照すると、compileはimplementationとapiの二つに分けられたらしいです。つまり、これからはcompileの代わりにそのどちらかを選ぶのが望ましいということですね。implementationとapi既存のcompileだと、必ず「依存関係の伝播」が発生していたらしいです。つまり、Aというライブラリーを使って新しくBというライブラリーを作成したとしましょう。そしてまた、Bに依存するCを作成します。こういった場合、CではBを依存することだけでAにも触れられるようになります。このような状況は、場合によってはまあり望ましくないことになる可能性もありますね。Aをラッピングして、仕様を絞る目的としてBを作成したとしてもCからAを直接扱うことができますから。これはJavaのカプセル化の観点からしてもあまり望ましくないです。implementationでは、この依存関係の伝播に制約をかけています。つまり、BからAに依存するとき、compileではなくimplementationで記述するとCからAを直接参照できなくなるということです。この理由から、最近は多くの場合にcompileの代わりにimpelementationを使うことを推奨しているらしいですね。それに対してapiでは従来通り依存関係の伝播が発生します。BがAに依存しているとき、完全なラッピングではなく、CからAも参照させたいならこちらを使うべきですね。実際、業務でライブラリーをいくつか作っていましたが、一部では大元のライブラリーを参照させる必要があるものもありました。この場合にimplementationを使うとCからのAに対する直接的な参照がGradleとしては認識できなくなったらしく、コンパイルでのエラーが発生することもありました。なのでdependenciesの記述では、自分が作成しているものの性質を正しく理解し記述方法を決めるということも大事ですね。これらの関係を簡単な図として表現すると、このようになります。最後にこれでシンプルに、Gradleのdependenciesはどう書くべきかについて述べてみました。実際はimplementationとapi意外にもランタイムのみ参照のruntimeOnlyやテスト用のtestImplementationなど、様々な記述方法があるので、状況と場合によっては柔軟な対応が必要かと思います。ただ、大抵の場合は依存関係を整理し、implementationとapiの使い分けを確かにすることが最も重要なことなのではないでしょうか。また、先に述べたように、ネットから得られた情報がAPIの更新事項を確かに反映しているかのチェックも重要ですね。古い情報だと今のコードでは問題を起こす可能性がありますので。そういう意味では、このポストも時間がたてばいつか正しくない情報となる可能性はあります。いや、このポストだけでなく、もしかしたらこのブログ全体で私が書いている情報の全てがそうなのかもしれません。コードを書きながら、ネットの情報を参照するときは常にそれが書かれた日付を確認し、公式のドキュメントと見比べる必要があるのではないかと思います。勉強も最新化の方針で！Deprecatedは、「オススメしない」という意味です。プログラミングの世界では、何らかの問題があったり必要が無くなったりするなどの理由でこれからなくなる可能性の高い関数を指す言葉となっています。実際、EclipseではJavaの関数に@Deprecatedをつけると関数名に打ち消し線が現れることを確認できます。 ↩︎

Gradleのdependenciesはどう書くべきか

JavaのEnumは興味深いものです。読みやすく、同時に複数の値を持たせるということが魅力的です。なので複数のクラスで共通のコード値を扱う必要があったり、DBに連携する場合に使うと便利ですね。私も現在の仕事では積極的に活用しています。また、完全なクラスとして機能しているので単に定数のため使うだけでなく、処理を記述することも可能なので活用できる範囲はかなり広いのでは、と思います。なので今回はJavaのEnumの活用法やメリットについて、自分の経験と調べたことをまとめ紹介したいと思います。読みやすいコードが読みやすいということは、つまり維持補修に有利ということですね。個人的にはプログラミングの段階は「とにかく動く物を作る」→「共通(重複)処理をメソッドやクラスで分離する」→「他人がみてもわかりやすいコードにする」順に進むべきだと思います。そして全ての段階が最初の設計からできていればなおさらですね。テーブルにとあるコード値が項目として存在するとしましょう。DBの種類によってはその項目をbooleanにすることもできますが、char(1)になる場合もあります。そしてこういった場合はそのコード値は二つの状態だけでなく、3つ以上の状態を持つ場合もありますね。サンプルとしてJava内での状態をStringとして持ち、DBにはchar(1)として記録するとしましょう。そういう場合は以下のようなコードが必要となるはずです。// Stringで記述されている状態をDBのコード値に変換するメソッドの例public String toCodeValue(String status) { if (status.equals("TRUE")) { return "0"; } else { return "1"; }}このメソッドを使うコードは、以下のようになります。// itemオブジェクトにステータスを指定するpublic void setStatusTrue(Item item) { item.setStatus("TRUE");}ハードコーディングされたstatusを定数かすることは可能です。定数は普通のクラス内でも持たせますね。しかし、そういう場合は定数がどのクラスで定義されているかをまず知る必要があります。とこで定数が定義されているかわからない場合は修正も難しくなるし、重複して同じ定数をそれぞれ違うクラスに作成することになる可能性もありますね。そして、このコードでは処理の結果を見る前まで状態がどうなっているか確認できなくなる可能性があるという欠点があります。もしどこかで指定されたstatusがTRUEでもFALSEでもない第三の文字列だったら？そういう場合はifの分岐を増やすしかないでしょう。これをEnumを使うコードに変えてみましょう。コードは以下のようになります。public enum StatusEnum { TRUE("0"), FALSE("1"); private Integer codeValue; StringEnum(Integer codeValue) { this.codeValue = codeValue; } public Integer getCodeValue() { return codeValue; }}定数名にそれぞれのコード値を設定し、フィールド・コンストラクタ・Getterを用意するだけです。構造からわかるように、このようなEnumクラスはLombokのアノテーションでも簡単に作ることができます。@Getter@AllArgsConstructorpublic enum StatusEnum { TRUE("0"), FALSE("1"); private Integer codeValue;}作成したEnumを実際活用する場合のコードは、以下のようになります。// itemオブジェクトにステータスを指定するItem item = new Item();item.setStatus(StatusEnum.TRUE.getCodeValue()); // "0"となるEnumを作成することで、入れたい値が明確になります。また、Enumは独立したクラスなのでパッケージを分けて保存することで管理がより簡単になります。あとでコード値が増える場合にもそちらのEnumを修正するだけで住みますね。また、Enum自体をフィールドとして宣言することも可能です。その場合は以下のようになりますね。// フィールドにEnumがある例@Datapublic Item { private StatusEnum status;}フィールドがEnumの場合は、値の指定がより簡単になります。Item item = new Item();item.setStatus(StatusEnum.TRUE); // TRUEとして保存// コード値を抽出したいときのコードString itemCodeValue = item.getStatus().getCodeValue();複数の値を持つことが可能そこまで読み易くはならないのでは？と思われる可能性もありますね。確かに、一つの定数につき値が一つだけの場合はそうかもしれません。しかし、Enumの良いところは、定数に複数の値を持たせることも可能ということです。例えば二つ以上のDBを使っていて、同じ項目を片方のテーブルはchar(1)、またの方はbooleanで管理しているとしましょう。Enumでは両方を一つの定数として管理することができます。それがどういうことか、以下のコードで確認してみましょう。@Getter@AllArgsConstructorpublic enum MultiValueEnum { Y("0", true), N("1", false); private Integer charValue; private boolean booleanValue;}コードを見ると簡単に理解できると思いますが、どちらのGetterを使うかによって同じ定数でも違うデータ型のコード値を返却します。これを実際のコードで使うとしたら、以下のようになります。// DBの項目がchar(1)Item item = new Item();item.setStatus(MultiValueEnum.Y.getCharValue()); // "0"// DBの項目がbooleanitem.setStatus(MultiValueEnum.Y.getBooleanValue()); // true複数の値を指定可能ということは、配列やListでも可能ということではないか？と思う方もいるかもしれません。結論からいうとYesです。自分も最初からわかっていたわけではありませんが、調べてみるとStreamを使うと値としてListを持たせ、さらにそのListの中の値との比較もできるようです。この場合のコードは以下のようになります。@Getter@AllArgsConstructorpublic enum ListValueEnum { Y(Arrays.asList("Good","Excellent")), N(Arrays.asList("Bad", "Unavailable")), NULL(null); private List<String> codeValueList; // Listの中に値があるかチェック public boolean hasCodeValue(String codeValue){ return codeValueList.stream().anyMatch(code -> code.equals(codeValue)); } // Listの中の値と一致する場合、その定数を返す("Good"ならListValueEnum.Yを返却) public ListValueEnum findByValue(String codeValue) { return Arrays.stream(ListValueEnum.getCodeValueList()) .filter(listValueEnum -> listValueEnum.hasCodeValue(codeValue)) .findAny().orElse(NULL); // 当てはまる値がない場合はNullを返す・ }}まだStreamは一部でしか使ってみたことがないのでこういう活用方法は考えてみたことがないですが、どこかで使えそうなコードです。また、フィールドとして使うEnumに特に値がない場合は以下のようなアノテーションを使うことも可能です。@Datapublic class Item { // StringEnum.YESのまま使う場合 @Enumerated(EnumType.STRING) private StringEnum codeValue1;}Classらしき活用Enumはクラスなので、もちろん処理を持たせる方法もあります。処理を持たせるというのは難しく感じるかもしれませんが、処理をメソッドと思えば良いだけの話です。メソッドのフィールド化する方法についてはLambdaに関する以前のポストを参照してください。@AllArgsConstructorpublic enum CalculateEnum { // Lambdaでフィールドを指定 TYPE_1(num -> num), TYPE_2(num -> num + 10); private Function<Integer> calculate; // 値を入れると処理結果が帰ってくる pulbic Integer calculate(Integer number) { return calculate.apply(number); }}このような形のEnumを使う場合のコードは以下のようになります。// 処理結果を取得Integer type_1 = CalculateEnum.TYPE_1.calculate(10); // 10Integer type_2 = CalculateEnum.TYPE_2.calculate(10); // 20最後に共通の部品として使われるものが重複されていると管理もその値の理解も難しくなり、余計なコードが増えるますね。これをEnumで克服できるということを伝えたかったのですが、いかがでしょうか。ただ、定数を必ずEnumにする必要があるかは、よく考えてみる問題だと思います。場合によってはテーブルとして管理した方が良いのかもしれません。そしてある特定のクラス内でしか使われていないなら、あえてEnumを作る必要もないでしょう。それでもこのようにAPIの活用方法を理解し、覚えておくと、どこかで使っていい場合が現れるのではないかと思います。最初はLambdaをただの「読みづらいコード」としか認識していなかった私も、Functionの存在を知ってからは積極的に使っています。知識のみでなく、その知識を適材適所で活かしていけるようになることが真のプログラマーと思います。まずその判断は難しいかもしれませんが、知識を先に持つことで見えてくるものもあるのではないでしょうか。なので、これからも新しく得られた知識があれば、このブログで紹介していきたいと思います。

Enumを使いましょう

もともと自分が学んでいたのはMavenを利用したSpring MVCのプロジェクトを作る方法でしたが、最近はGradleで管理されるSpring Bootプロジェクトを触っています。最初はGradleを単純にMavenと似たような依存関係用のツールだとしか思ってなかったですが、直接タスクを作ったりJarをビルドしたり色々挑戦してみてからそう単純なものではないということに気付きました。その中でも最も良いと思ったのは、それぞれ違う機能を持つ個別のプロジェクトをマルチプロジェクトという概念で管理できることでした。OOPの観点からしてクラスやパッケージだけを分けるのではなく、プロジェクト単位の分け方によってより維持保守に長けているアプリケーションを作られるのではないか、と思います。なのでここではまず簡単にGradleのマルチプロジェクトが何であり、その作り方について簡単に説明したいと思います。Gradle Multi ProjectGraldeのマルチプロジェクトは、その名の通り複数のプロジェクトで構成されているプロジェクトのことを意味します。具体的には全ての起点となるルートプロジェクトがあり、その配下に複数のGradleプロジェクトが入っている形になります。ルートプロジェクトの配下で管理されるプロジェクトたちはサブプロジェクトといいます。こういうマルチプロジェクトの作り方は今回紹介する方法とはまた違うものもあるらしく、プロジェクトのフォルダ構成にも違いがあるようです。ただ、マルチプロジェクトは複数プロジェクトの管理を簡単にさせるということにその目的があると思いますので、一つのリポジトリ単位で管理できるようにルートプロジェクトの中にサブプロジェクトが入っている形を採用します。これは実際自分が仕事で書いているSpring Bootプロジェクトの構成でもあります。また、ここで紹介しているのはEclipseを基準にした説明となります。(他のIDEはまだ詳しくないので…)Root Project全てのサブプロジェクトを含む大元となるルートプロジェクトを作ります。一般的なGradleプロジェクトをまず作成します。ただbuild.gradleはこれからサブプロジェクトに使う予定なので、コピーしておきましょう。あとはいらなくなったファイルとフォルダを削除します。ここで残すファイルとフォルダは以下だけです。gradle(フォルダ)build.gradlegradlewgradlew.bat以上のファイルとフォルダを残したら、次はbuild.gradleファイルを修正します。ルートプロジェクトはサブプロジェクトの管理だけをしていて、必要なタスクやプラグイン、依存関係の設定はサブプロジェクトで記述します。なのでなるべくシンプルにしましょう。subprojects { repositories { mavenCentral() }}ここでやっていることは、サブプロジェクトのリポジトリ指定だけですが、同じやり方でサブプロジェクトのbuild.gradleに共通記述しなければならないことはなんでも入れていいです。例えばプラグインとかがあるでしょう。次に、settings.gradleファイルを作成します。このファイルはルートプロジェクトとサブプロジェクトを紐付け、プロジェクト名を決める役割をします。include 'core'include 'web'rootProject.name = 'TestProject'rootProject.children.each { it.name = rootProject.name + '-' + it.name }includeと書いたものはサブプロジェクトで、rootProject.nameはその名の通りルートプロジェクト名を意味します。他にも命名できる方法はありますが、あくまでルートプロジェクト名がこのプロジェクト全体を意味するもので、サブプロジェクトはそのうちの一つの機能単位という感覚て命名しています。rootProject.children.each { it.name = rootProject.name + '-' + it.name }では、ルートプロジェクト名にダッシュをつけ、その下にサブプロジェクト名を付けています。これは以下の方法でも表現できます。rootProject.children.each { p -> p.name = "${rootProject.name}-${p.name}"}この命名法によりそれぞれのサブプロジェクトはTestProject-coreやTestProject-webのように命名されます。こう構成したプロジェクトをEclipseのパッケージエクスプローラからみると、以下のように見えるようになります。TestProjectTestProject-coreTestProject-webあとでもしサブプロジェクトを追加する必要があるとしたら、ルートプロジェクトのincludeを記述することで自動的にTestProject-...という風にサブプロジェクト名が付けられることとなります。Sub Projectルートプロジェクトの準備が終わったら次は、子要素のサブプロジェクトを作ります。サブプロジェクトは普通のGradleプロジェクトでも良く、ルートプロジェクトの配下に置くだけで使えるようになりますが、ここでは空のフォルダを作成して作る方法を紹介します。まずルートプロジェクトの配下にサブプロジェクトとして使うフォルダを作ります。フォルダ名をサブプロジェクト名として使う予定なので、適したフォルダ名を選びます。ここでフォルダ名はルートプロジェクトのsettings.gradleで記述したincludeと一致しなければならないです。例えば上のルートプロジェクトではcoreとwebをすでに書いているので、それに合わせてcoreとwebのフォルダを作成します。フォルダを作成したら、その中にルートプロジェクトを作成した時コピーしておいたbuild.gradleを置いて編集します。今回はEclipseを基準にJavaプロジェクトを生成するので以下のようなプラグインが必要です。plugins { id 'eclipse'}ファイルを保存してルートプロジェクトからgradlew tasksを実行すると、ide節にeclipseがあります。こちらのタスクを実行します。コマンドラインだとgradlew eclipseを入力することで実行できます。もちろんEclipse上でも実行できますが、更新に時間がかかる場合があるのでコマンドラインの方をお勧めします。このタスクを実行することで、作成したフォルダの中にEclipseプロジェクトとして機能するための準備ができます。あとは普通のJavaプロジェクトのようにソースフォルダ(src/main/java)を生成し、パッケージを作成してサブプロジェクトの中を埋めていきます。もしマルチプロジェクトがEclipse上で正しく認識されない場合は、プロジェクトを右クリックしてリフレッシュしたり、GradleメニューからGradleプロジェクトのリフレッシュを実行してください。Sub Project Dependencyこの方法で作成したマルチプロジェクトでは、サブプロジェクト同士で依存することもできます。例えばwebプロジェクトの起動にcoreプロジェクトで作成したクラスを読み込む必要があるときは、webのbuild.graldeで以下のように記述するとcoreのクラスをインポートできるようになります。dependencies { implementation project(':TestProject-core')}ただこの場合、webの起動時に一度coreプロジェクトをコンパイルすることになるのでテスト時にcore側の修正事項は即反映されないので注意しましょう。最後にまだEclipse上でGradleのマルチプロジェクトの生成を簡単にできる方法がなく、このような多少不便な方法でしかプロジェクトの作成ができないというところが不便ですね。のちに追加されるかもしれませんが…でもまずはマルチプロジェクトを構成する方法とその構造がどんなものかが理解できれば、これから活用できる道が増えていくのはでないかと思います。特にプロジェクトの規模が大きくなればなるほど、こういう管理の仕方だ必要になるのではないでしょうか。それでは皆さんもぜひ、Gradleのマルチプロジェクトを試してみてください！

Gradleでマルチプロジェクトを作る

今回、Oracle認定JavaSE 8 Silverを受験しました。仕事でしばらくJavaを使うことになって、自分の実力がどのレベルなのかを確かめたかったので受けてみましたが、運よくも合格。Java Silverで検索すると合格した人たちはどう勉強したか、難易度はどうなのかについてのブログが多いのでここでは書きません。それでもあえてポストとして資格試験のことを書く理由は、どうしても資格とは実際の業務で必要となる知識とは乖離があるものだからです。資格をまず取得して業務に入る人もいれば、私のように業務でのお作法を経験してから受験する人もいるだろうと思います。なので、私と全く同じ状況ではないとしてもテストで困る問題は多分ある程度その領域が重なるのでは、と思います。その結果として他の多くの方が書いているものとあまり変わらないことを述べているのではないか、とも思いますが…もしこれからJavaSE Silverを受験しようとしている方がこのポストを見つけた場合に、少しでも役に立てるような情報になれるといいなと思い、自分の経験として意外とハマったところについて述べます。全体的な印象業務では使わない知識が要求される場合が少なくないです。ただそれが全部無駄な知識とは言えない印象でした。一旦覚えておくと業務でも活かせるのでは、と思う問題もありました。大きく分けてAPIに対する単なる知識を聞く問題と、コードを読んで理解する能力を要求するような問題があります。意外と難しいなと思ったのは、IDEに依存できない問題でした。代表的にimportの書き方、コンパイルエラーの見つけだしなどがあります。実際の業務でIDEを使わず、単なるテキストエディタでJavaを書くことはないと思いますが、試験としてはそのような問題の頻度が決して低くないので、問題で提示されるコードはちゃんと読む必要があります。それでは、以下ではテストの個別項目について感じたことを述べていきます。データ型データ型で最も多く使われるのは、int/double/Stringの三つだと思います。テストでもbyte型やfloat型の範囲などを聞く問題はなかったですが、一部の問題でこれらが出てくる場合があります。例えばswitch文の条件文で使えないデータ型は何かを選ぶ問題など。Bronzeならもっとデータ型について詳しく聞く問題が出てくるのでBronzeの次にSilverを受けるならともかく、私みたいにSilverから挑戦する人なら少し困るかもしれません。他にもデータ型と関連する問題の種類は、型変換(暗黙的な型変換とそうではない場合を選ぶ)があります。こちらもbyte, short, long, floatの特徴を確かに覚えないと、意外と正解がわからなくなる問題でした。String / StringbuilderStringやStringBuilderのメソッドに関する問題が多かったです。ただ普段はあまり意識してなかった部分ですが、StringはImmutableなオブジェクトになるためreplaceやsubstringなどのメソッドを使うと新しいインスタンスが返却されるということをちゃんと覚えておく必要があります。例えば以下のような問題があります。// 出力される文字列を当てる問題String s = "this is string";s.substring(0, 1);System.out.println(s);元のString自体は変わってないので最初に宣言した通り出力されるのが当たり前ですが、注意深くコードを読まないとsubstringで切り取った文字が出力されるように勘違いしやすいです。(自分だけかもしれませんが…)配列配列をあえて使う場合があまりなく、ほとんどListを使っていたのでこちらの問題でも苦戦しました。配列の宣言の仕方から、配列の中の要素を処理する方法などの問題がよく出てきましたが、配列の宣言には様々な方法があるので少し選択肢が怪しく思われます。もちろんListは基本が可変・スレッドセーフではないので場合によっては業務でも配列を導入する必要はあるかもしれません。覚えておいて損ではないと思いますので、配列については確実に覚えておきたいと思いました。アクセス修飾子 / 継承defaultとprotectedの違いを問う問題があります。普段からパッケージ構成や継承を考慮した実装をしていたならともかく、大抵の場合はpublicとprivateのみを使っていて他を忘れやすい場合もあると思うので、ちゃんと覚えておきたいものでした。また、継承の問題でアクセス修飾子が重要なキーワードとなる問題もありました。例えばスーパークラスからオーバーライドーしているメソッドをより狭い範囲にするようなコードを提示して、そのコードを実行したらどうなるかを聞く問題など。正常実行されると思ってその結果を答えとして選んでも、「コンパイルエラー」が正解だったりします。継承に関してはかなり問題の量が多いような印象を受けました。Interfaceとabstractの違い、継承の仕方、インスタンスと参照の違い、キャストなどバリエーションも多く、どれも実務では使われているので慣れてはいるものの、問題自体もそのためか知識だけよりは少し複雑な方法でミスを招こうとしている印象でした。コードを注意深く読む必要があります。ラベルラベルについてはこの度初めて接したので全然知らなかったですね。しかし二重ループで使うとかなりパフォーマンスの改善を図れると思いますので、これはテストだけではなく覚えておくと良いこつと思います。ただ、ループ以外で使うことはそんなにないかも…とも思います。問題としてはラベルがついたループ文ないでif文を書き、結果がどうなるかを聞く問題が少しありました。例えば以下のようなものです。// 出力がどうなるかを問う問題int num = 0;x:for (int i = 0; i < 10; i++) { if (i % 5 == 0) { continue x; } System.out.println(num); num++;}ラベル自体よりは条件文とcontinue / breakの違いをちゃんと理解しているかを聞くような問題とも言えると思いますが、とにかくラベルとはなんぞや？となると、一旦答えることができなくなります。もちろん知識としてラベルをつけることができるのはどこか、という問題もありました。例外Javaの例外の特徴や、try-catch文での挙動に関する問題が出てきます。業務ではカスタム例外を作ることもあるのでExceptionとRuntimeExceptionの違いについて理解しているならそこまで問題となることはないと思いますが、提示されるコードで見逃す可能性があるのは「throws宣言があるかどうか」、「catchでスーパークラスの例外を宣言しておいてその次にサブクラスをまた書いてコンパイルエラーになる場合であるか」のような部分です。上位の例外をcatchすると、下位の例外は書く必要がないので注意しましょう。IDEを使える環境だったらあまり気にする必要ない部分なので、意外と見逃せやすい部分ではないかと思います。LambdaJavaSE SilverではJava8ならではのAPIについて聞く場合が少なくないです。Lambdaもそうですね。ただ、大抵のLambda関連の問題は正しい書き方やFunctionの種類に関する知識を問う問題です。慣れてなくても、覚えておくと大丈夫でした。書き方については括弧とreturnの省略が正しく書いてあるのかについての問題で、例外同様IDEだとすぐコンパイルエラーになるため見逃しやすい部分でした。LocalDate / LocalTime / LocalDateTime今まで自分が使っていた日付関連のAPIはjava.util.Dateとjava.sql.Dateしかなかったので、苦戦した問題でした。こちらもStringと同じくImmutableなので、似たような問題が出てきます。例えば以下のような問題です。// 出力がどうなるかを問う問題LocalDate date = LocalDate.now();date.plusDays(5);System.out.println(date);Stringと同じく、Local〜類のAPIは値を操作するメソッドが新しいインスタンスを返却することを覚えておくと良いだけです。ただ、時間や日付の出力フォーマットに関する問題が出るのでこちらは覚えておく必要がありました。APIを見るとjava.sql.Dataにも変換ができるのですが、変換に関する問題は出てませんでした。その他問題集だけだと複数の選択肢を選ぶ問題なのに一つしか選んでなかったりしていて、本場でこうなると困るな…と思っていましたが、実際のテストでは単一選択肢だとラジオボタン、複数だとチェックボックスで選ぶようになっているので心配ありませんでした。チェックスボックスなのに一つだけ選んでいたりすると次の問題に移る前に警告も出ました。一部ループでの処理などを直接計算する必要がある場合もありますが、多くは時間がかからなく即答できるものです。時間が足りないということはほぼないと思いますので、問われているAPIに関してその特徴をよく覚えると簡単に合格できる資格なのでは、と思います。ただ逆に、私みたいに業務に慣れていて基本を忘れていたり知らなかったりするとハマるところも少なくないと思います。先に述べたように時間が足りなくなることはあまりないので、コードが提示される問題は注意深く読みましょう。そしてコードが提示される問題の答えは実質的に「処理の結果が出力される」、「コンパイルエラーになる」、「実行時に例外がスローされる」の三つだけなので、まずどれに当て嵌まるかを考えてみると良いと思います。それでは、これから受験する皆さんも合格できますように！

Oracle JavaSE 8 Silverについて

最近仕事で作っているのは、固有ライブラリーです。ただ思っていたことと違ったのは、まず完全自作ではなく既存のライブラリーを改良するような物であるという点。そして二つ目はSpring Bootで作られているということです。Spring bootは今回初めて触れましたが、以前Spring MVCでWebサイトを作ってみた経験はありました。ただSpringはWebアプリケーションを作るためのフレームワークなので、これを持ってライブラリーを作ったり、Webページのないアプリケーションを作るということは想像もしたことがなかったです。それが仕事で両方の使い道に触れることがあって、まだ世の中自分の知らないものばかりだなと思いました。プログラミングとは言語やフレームワークを使えるかどうかの問題だけでなく、どう活用してどんな物を作るかの問題も含めて考えなければならない物ですね。そして画面はなくてもMainクラスを作ることでJarから独立実行ができて、インポートしてはライブラリーとして使える独特？なしようとなりました。そしてもちろんそうするためには少し準備は必要となりました。表題では短くなりましたが、今回の主題であり仕事での要件は実際はこういう物でした。Gradleのtaskで実行するSpring bootアプリケーションにして、起動時にはコマンドライン引数を渡すこうして書いてみると複雑のようですが、実際はそこまで難しい概念ではないと思います。まずGradleはMavenのようなライブラリー管理ツールとして知られていて、gradlewに様々なオプションをつけることでJarのビルド、テストなどの行為ができますね。ここでしたいのは、そんなGradleでできるタスク(オプション)を追加することです。そして追加されたタスクを実行すると、Spring Bootプロジェクトとして作成されているライブラリーのMainクラスを起動させることです。ただ、皆さんにもわかるように、Sping BootプロジェクトでMainクラスが用意されていると、普通にjava -jar project.jarという風にコマンドラインから起動させることができます。なのになぜあえてGraleのタスクに入れようとしたかというと、以下のような理由があります。マルチプロジェクト構造となっている現在の設計で、ライブラリー全体のプロジェクトは複数のサブプロジェクトを含むマルチプロジェクトとなっています。これでちゃんと伝わるか分かりませんが、とにかく表で表現すると以下のようになっています。rootproject┣ target┣ generator┗ runtime簡単に説明しますと、現在のライブラリーはgeneratorというサブプロジェクトを利用して(runtimeはその時generatorから参照します)targetプロジェクトのコードを操作します。ここで最終的にgeneratorとruntimeはJarとして提供され、使用者はこのライブラリーでの処理を適用したいプロジェクトをtargetの位置に置いて使うことになります。こうなった場合に、コマンドラインからruntimeに依存しているgeneratorのJarを起動してtargetのソースファイルを操作するように指定するのはかなり面倒臭い作業となりますね。これを自動化したかったです。起動時に渡したい引数が多いGradleのタスクとして実行したかったもう一つの理由は、ライブラリーが処理を行うために必要な引数の種類が7つくらいがあって、これを全部覚えるのは難しいからです。それにタイポにより処理に失敗する可能性も上がりますね。ここで思ったのが.batファイルを用意していて、使用者がそれを修正したらいいだけの話ではないかと一瞬思いましたが、やはりあまり良い方法ではなかったです。Gradle自体も今はそうなっていますが、別途のファイルを用意するということは、OSごとにそのファイルを作成する必要があるということですね。使用者がどんな環境で実行するかわからないのでとりあえず.batと.shの両方を準備する必要がありますね。それに、このライブラリーがWindowsやLinuxでしか使用されないだろうと言い切れないので、そういう場合はより変数は多くなります。そうなるといちいちOSや環境に合わせて、コマンドライン引数を渡すための方法を作らなければならないですね。わざわざそんなことをするよりは、Gradleのタスクとして用意し(もちろん引数はファイルに記載して読み込まれるように)、環境のことはGradleにお任せした方がコードの管理や便宜性という面からして良さげな気がしました。統一感もあって、使用者にも良い印象になりそうですしね。[target] build.gradleまずはタスクを実行したいtargetプロジェクトの方から始めましょう。Gradleプロジェクトは基本的にbuild.gradleというファイルを持ち、このファイルを修正することで依存関係やプラグインなど様々な設定ができますね。同じく、カスタムタスクを追加したい場合もこちらに追加したいタスクの内容を記載します。apply from: 'default.gradle' // このファイルを読み込むという意味task taskname(type: GradleBuild) { // タスク名とタイプの設定 group = 'application' // gradlew tasks コマンドから、applicationタブにこのタスクが追加される description = 'run program' // このタスクの説明 dir = '../generator' // タスクの実行基準位置 tasks = ['bootRun'] // 実行する内容 startParameter.projectProperties = [args: '${defaultArgs}'] // コマンドライン引数としてdefaultArgsを読み込む}ここでdefault.gradleを読み込んでいる理由は、そのファイルにデフォルト値を記載しておき、タスクを実行する時に読み込んだ値をコマンドライン引数として使うためです。最後の行でdefaultArgsと書いてありますが、これがデフォルト値を変数にしたものです。こうやってファイルを分離することで実際の使用者がこのタスクを実行するときは、default.gradleを修正して引数として渡される値だけを調節することになります。[target] default.gradle次に、build.gradleでタスクを実行する時に読み込まれるファイルの設定は以下のようになります。ここでは読み込まれる対象としての設定と、変数の形で宣言したコマンドライン引数を記載するだけです。ext { // 読み込まれる対象と表記 defaultArgs = '-arg1 value -arg2 value' // arg1とarg2の二つの引数がある場合}こちらは簡単ですね。引数名が書いてあるので順番は関係なく、あとはそれぞれの値を変えるだけでよくなります。[generator] build.gradleそれでは続いて、タスクで実行される側の設定です。 targetのタスクでgeneratorをbootRunすると指定していたので、それに合わせてbootRun時の挙動を設定します。例えば引数をどんな形で受け取るか、メインクラスはどれかという設定ですね。bootRun { // bootRun時の挙動 if (project.hasProperty('args')) { args project.args.split('\\s+') // コマンドライン引数がある場合、空白を基準に分割する }}jar { // Jarとしての設定 manifest { attributes 'Main-Class': 'com.package.Main' // メインクラスのクラスパス(パッケージとクラス名)の指定 }}コマンドライン引数を分割する理由は、皆さんも予想しているとは思いますが、Javaのメインメソッドは普通文字列の配列として引数を受け入れるからです。こうやって分割しておくと実際の処理で引数のパースが簡単になりますね。ここまでこればGradleの設定は終わりです。あとはJavaでのメインクラスの設定です。[generator] Main.javageneratorのJarを実行した時に呼ばれるメインクラスを作ります。ここでは一般的なJavaのメインメソッドと、Spring bootとしてのメインクラスの作法、JCommanderでコマンドライン引数をパースするための作法、Lombokが混在していますのでそれぞれに対する知識のない方には少し難しいコードになっているかもしれません。ただ、実行されている時の動作としては単純なものになっているので、Springのアノテーションにある程度慣れている方ならすぐに理解できると思います。まずコードは以下のようになります。@SpringBootApplication // Spring bootとしてのメインクラスにつける@EnableAutoConfiguration(exclude = { DataSourceAutoConfiguration.class }) // H2関連エラーが出たので付けましたpublic class Main implements CommandLineRunner { @Autowired private CoreProcessClass coreProcessClass; // @Componentとなっている実際の処理クラス @Override public void run(final String... args) throws Exception { // CommandLineRunnerを継承するして実行時の動作をオーバーライドする final CommandLineOptions options = CommandLineOptions.parse(args); // パースと同時にBeanを生成 coreProcessClass.startProcess(options.getArg1, options.getArg2); // 本処理開始 } public static void main(final String[] args) { SpringApplication.run(Main.class, args); // メインメソッドとしては引数を渡すだけ } @Data public static class CommandLineOptions { // コマンドライン引数をパースするクラス // JCommanderを使用した引数の設定 @Parameter(names = "-arg1", description = "File", required = true, converter = ArgumentsToFileConverter.class) // 引数は文字列なので、コンバータクラスを使う private File arg1; @Parameter(names = "-arg2", description = "String", required = true) // 普通の文字列の場合 private String arg2; private CommandLineOptions() {} public static CommandLineOptions parse(final String... args) { // 実際のパースを行うメソッド try { final CommandLineOptions options = new CommandLineOptions(); JCommander.newBuilder() .addObject(options) .acceptUnknownOptions(true) .build() .parse(args); return options; } catch (ParameterException e) { e.getJCommander().usage(); throw e; } } } public class ArgumentsToFileConverter implements IStringConverter<File> { // JCommanderで引数をオブジェクトに変えるためのクラス @Override public File convert(final String argument) { return new File(argument); } }}JCommanderを使うことでコマンドラインのパースは簡単にできます。ここでいうパースは単純に文字列だけを意味することではなく、必須項目としての指定(ない場合は例外となる)やオブジェクト変換などの様々なことができるという意味です。例えば引数として渡した文字列があるものはファイルパスだとしたら、それを読み込んでFileオブジェクト化したり複数の引数をListとして取得することもできます。そしてパースしたオブジェクトを、本処理で使われるオブジェクトに渡すだけで終わり。意外と簡単に終わりますね。最後に実は、今まで説明した内容は自分で考えて作り出したものではないです。最初はGradleタスクを作るために導入したライブラリーの問題があってなかなか仕事が進まなく、すでに出来上がっていたものを参考にしたものにすぎません。でもここであえて紹介するのは、皆さんに共有する価値があると思ったからです。特にサーバーで動くアプリケーションを作る場合はやはりコマンドラインで起動させる場合が多いですし、環境によっては引数で違う値を渡す必要があるかもしれません。そのような時に、このようにファイルから引数を渡して実行するタスクを作成して環境ごとに設定を変えたり違うファイルを読むようにするとかなり便利そうですね。なので皆さんにもぜひ紹介したいと思いました。そして個人的には、今は自分も先輩方の成したものから学ぶばかりですが、いつかはこんな考え方もあるんだと後輩に伝えられたらいいなと思わせる、大事な経験でした。これから先はまだまだ遠いですね！

Gradleからコマンドライン引数を渡す

最近のJavaはバージョンアップが早いですね。自分が初めて学んだものは1.8でしたが、すぐ9がでて今は13もリリースを目前としています。バージョンアップはバグ修正や性能の向上など良い面が多いためなるべく自分が使っているプログラムは常に最新のバージョンを維持したいですが、言語のバージョンが上がる度、何が変わったかを確認しすでに存在するコードを見直すのは簡単な問題ではいですね。Javaはかなり歴史が長いので、現在のトレンドと比べてみると不便(パラダイムが変わったからという理由が多いと思いますが)な面が多いです。そして1.8が維持された期間が長かったのですが、そのため流行には遅れていますね。10になって型推論が導入されるなどトレンドを追いかけているような面もありますが、Kotlinのように同じくJVMを使う言語と比べてみるとまだ先が遠い印象はあります。もちろん変化は肯定的なものであって、元の特徴を維持しながらもトレンドに合う書き方ができるようになったというのは、その言語を使えるユーザーのプールが広くなったとも評価できるでしょう。でも、全ての要素において「古いものと新しいもの共存」ができるわけではなさそうです。そういう場合はどちらを使うかを選択する必要がありますね。今回のポストで話たいModuleがその代表的なものです。昔からの問題を改善するために導入されたものですが、結局は既存のコードに影響を与えてしまい、対応が必要となる部分です。最初は自分が書くコードでは考慮する必要がないものだろうと思っていたのですが、どうもそうはいかなかったです。なのでここでは、JavaのModuleが何であり、どんな問題を経験したかを述べたいと思います。Project JigsawModuleはProject Jigsawという名で、1.7から導入を検討していたものらしいです。Moduleという名からわかるように、アプリケーションを起動する時読み込むライブラリー(Java内臓の)を選択することができるシステムです。1.8まではコマンドラインで起動するアプリケーションを作るとしても、基本的なシステムライブラリーであるSwingなどが含まれていたのですが、それを調整できるようになりました。要らないシステムライブラリーを除去するとアプリケーションのサイズも小さくなりますし、メモリーを節約できるというメリットもありますね。また、Javaの特徴でもあった「完璧にロードされるまでには時間がかかる」という問題も、このModuleの設定である程度解消できるようになりました。そのほかにも、パッケージの「Publicすぎる問題」も、Moduleで解消できるようです。JavaのクラスはProtected宣言で同じパッケージでアクセスできるようにできますが、パッケージが細かく分けられた場合は同じライブラリーの中でもアクセスできませんでした。そういう場合はPublicで宣言するしかなかったですね。Publicで宣言されたクラスはライブラリーの中だけではなく、どこでもアクセスできるようになるため問題が生じる可能性もあります。ライブラリーを作りながらクライアントに使って欲しいクラスと使って欲しくないクラスを分けることが難しいことだったということです。これをModule設定により外部へ公開するクラスと、ライブラリー内部に向けて公開されるクラスで分けられるようになりました。Moduleの実例では、Public問題をModuleでどう解消できたかを、コードを持って説明します。まだ自分もModuleを積極的に使っているわけではないので基本となる部分だけですが、重要なポイントは以下の三要素だそうです。NameExportsRequiresまずNameは、Moduleそのものの名称を意味します。パッケージ名と同じ命名規則で書きます。次にExportsは、このModuleから外へ公開するパッケージのことを意味します。ModuleではPublicであっても、Exportsと明示されていないパッケージは外部からアクセスすることができません。そして最後にRequiresは他のModuleに対する依存関係を表します。これらを実際のコードで書くと、以下のようになります。デフォルト・パッケージにmodule-info.javaとして記述されます。(Java9以後のシステムライブラリーから確認できます)// module-info.javaの書き方module com.module.mylibrary { exports com.module.mylibrary.api; requires com.module.exlibrary;}Exportsの場合、公開対象を指定することができます。つまり、アクセスできるMobuleを指定することができるということです。// exlibrary限定のPublic設定module com.module.mylibrary { exports com.module.mylibrary.api to com.module.exlibrary;}Moduleはもちろん外部ライブラリーに対しても使うことができます。module-info.javaを作成する方法もありますが、Java9以前に作られたライブラリーの場合にはそれがない可能性が高いですね。このようにModuleかされていないライブラリーを含ませる必要がある場合はAutomatic ModuleかUnnamed Moduleの二つの方法からライブラリーを分けて使うことになります。両方自動的にModuleとして扱われるという面では同じで、全てのパッケージにアクセスできるという面では同じですが、前者はmodulepathに属するものとして名前がある(Jarファイル名となります)ことに対して、後者はclasspathに属するもので名称がないためRequiresで指定することができません。Moduleでハマったところ自分がModuleであった問題は、同じパッケージをもつ二つのライブラリーの競合によるものでした。問題が生じたのは、既存のプロジェクトにGradleのタスクを追加しようとしていたので原因でした。Gradleのタスクを作成する方法はbuild.gradleに直接taskを作成することでもできますが、最初自分が参考にしていた方法(Gradleの公式文書に従いました)ではjava-gradle-pluginというプラグインを含ませる方法でした。こうすると自動的にJavaのライブラリーが追加されて、Javaでプラグインを書けられるようになりますが、ここに含まれているライブラリーがJavaのシステムライブラリーと競合を起こしました。元のプロジェクト(Java11を使っています)ではjavax.xmlをインポートしていて、これがJava9からはDeprecatedになり、最終的にJava11から除去されたらしいです。それがEclipse上ではUnnnamed Moduleとして読み込まれていたらしく、ちょうどjava-gradle-pluginのパッケージにも同一名のパッケージが含まれていたので競合が起こったのです。そもそも除去されている扱いなので競合が生じるのがおかしいですが…エラ〜メッセージではThe package javax.xml.transform is accessible from more than one module: <unnamed>, javax.xmlと出力されていました。似たような事例を参考にすると、二つの解決法が提示されていましたがどちらも自分のプロジェクトでは使えませんでした。module-info.javaを作成するとマルチプロジェクトとなっていてサブプロジェクト間のパッケージ依存関係まで考慮するには複雑な手続きが必要でしたし、Eclipseのモジュール依存関係設定からシステムライブラリーのjavax.xmlを除去すると、他にインポートしているjava.sqlがjavax.xmlに依存しているのでこちらも使えなくなるという問題がありました。そしてリンクの文を読んでみると、最新のJava13までこの問題(自分のケースと完璧に一致しているとは言えませんが)は解決されてないというので、どうしようもない状態でした。java-gradle-pluginはGradleで管理されているライブラリーなのでこちらからうかつに手を出すこともできませんでした。結局どうしたらいいか現時点では、外部ライブラリーを維持したまま競合だけを避ける方法はなさそうです。自分のModuleに対する理解がまだ足りてないことも原因かとは思いますが、結局はこのような事態が発生するとなるべく競合の原因となるライブラリーを除外するしか他の道はなさそうですね。便利さのために導入された新しい機能が、思わぬところで問題を起こしてしまうのはそう珍しいことでもないですが…3日ほど悩んだ私の選択は結局、そのライブラリーを使わないということしかなかったです。もちろん、Moduleの問題なのでバージョンに対するこだわりがなければJavaを1.８に下げるという方法もあります。ただ1.8はいずれサポートが終わるはずで、これからもJavaのバージョンはどんどん上がっていくはずなのでいつかは直面することになるかもしれない問題ですね。どうかJava14ではこのような問題が起こらないことを祈ります。

Moduleの問題に会った話

Pythonのような本格的なオブジェクト指向言語ではあまり見かけられないことですが、Javaではいわゆる参照型の以外にもプリミティブ型というものがありますね。どうもJavaが初めて世に出た時代はまだオブジェクト指向という概念が生まれたばかりだったのでそうなったのではないかと思います。このプリミティブ型が存在するという点から、Javaは完全なオブジェクト指向言語ではないという話もあるようです。プリミティブ型に対する定義は言語ごとに少し違うようですが、私が知っているのはJavaだけなのでJavaの基準からいうと、プリミティブ型はオブジェクトではないデータ型を指す言葉です。そしてそれは、メモリー上に載せたデータをどう持つかの観点がオブジェクトとは違うということです。オブジェクトはメモリー上のデータが位置する「アドレス」を指すことに対して、プリミティブ型はそれぞれ独立したメモリー領域にデータを載せます。これを証明するのが、条件文での演算子の違いです。プリミティブ型で、二つの変数が同一なデータを持っているかを比較する演算子は==ですね。しかし、同じ方法でオブジェクト、よく挙げられている例としてStringだと、同じ方法を使えません。equals()を使わないとStringでの正確な値の比較はできなくなりますね。なぜならオブジェクトが持っている値そのものはメモリーのアドレスなので、「同じ値を入れた」つもりでもそれぞれのオブジェクトが指しているメモリーのアドレスは違う可能性があるからです。このように、メモリー問題はプログラミングに対してはかなり重要なものです。いくらメモリーの絶対値が増えても、メモリーに載せられたデータをどう参照するか、どう扱うかを間違えたら思い通りにプログラムは動かない可能性があるからです。そしてまた重要なのは、メモリー上に載せたデータを参照する方法だけではなく、どう管理するかということです。正確なデータを入れたつもりが、途中で変わったりすると、参照の仕方が正しくてもプログラムが正常動作しない可能性がありますからね。そういう意味で、今回はImmutableなクラスについて述べたいと思います。Immutable ObjectとはImmutavle Objectとは、簡単にいうと「一度インスタンスが生成されたら、そのインスタンスが持つデータが変わらない」オブジェクトのことです。逆に、インスタンスの生成以後もデータが変わる可能性のあるオブジェクトはMutableと言います。代表的なMutableクラスとしてはBeanを挙げられますね。Setterを通じて自由にデータを変えることができます。そしてImmutableなクラスとして代表的なのは、Stringと言います。Stringは値を代入しても、元のデータはGarbage Collectorの対象になるまでメモリーに残り、そのStringオブジェクトが指すメモリーのアドレスだけ変わるからです。先に述べたように、プログラムの中でオブジェクトが持っているデータが途中で変わると、安定的な動作を保証できなくなります。そしてマルチスレッド環境では、二つのオブジェクトが同じメモリーアドレスを参照していると、スレッドそのものが止まってしまう可能性もあります。もしそのような場合が生じるとどこで問題が起きたか調べることも難しいですね。このような問題を回避するため、Immutableなクラスを作成するときは「インスタンスの生成以後はデータが変わらない」ことと、「クラスの持つデータが同じメモリーアドレスを参照しないように」します。それでは、Immutableなクラスを作成する方法にはどんなものがあるか、見ていきましょう。setterは使わない最近はかなりLombokを使う場合が多く、ある程度定型的なコードを生成してくれるので、Lombokのアノテーションを使って生成されるコードを持って説明したいと思います。Lombok自体の紹介は、以前のポストを参照してください。Lombokでは、アノテーションをつけることで簡単にBeanを生成できます。クラスの上に@Dataをつけることで、簡単にSetterとGetterができますね。これを使った場合、直接メソッドを手で書くより安定的でコードの量も減るため積極的に使えます。しかし、Setterが生成されるということはImmutableなオブジェクトにならないことを意味します。次は実際、@Dataをつけることで生成されるコードの例です。// @Dataの場合public class Car { // フィールドだけを定義 private String name; private String color; // 以下のメソッドたちが自動生成 public void setName(String name) { this.name = name; } public String getName() { return this.name; } public void setColor(String color) { this.color = color; } public String getColor() { return this.color; }}こうなった場合、フィールドがfinalで守られていないといつでもSetterにより値が変わる可能性があります。そして一部Setterメソッドが使われていない場合は全フィールドに値が設定されてないままnullになってしまう可能性もありますね。これはImmutableの定義にふさわしくないコードとなっています。幸い、Lombokで提供するアノテーションの中にはImmutableなクラスを生成するためのアノテーションもあります。@Valueというものです。これを使うと、@Dataと同じ機能をしながら(インスタンスの生成とフィールドの値を指定する方法は変わりますが)もImmutableなクラスを生成することができます。こちらのアノテーションを使ったコードは、以下のようになります。// @Valueの場合public class Car { // フィールドだけを定義 private String name; private String color; // 以下のメソッドたちが自動生成 public Car(String name, String color) { this.name = name; this.color = color; } public String getName() { return this.name; } public String getColor() { return this.color; }}最初、インスタンスを生成するときはコンストラクターで全フィールドを引数として指定します。フィールドが多いとどれがどれかわからなくなりますが、フィールドの値指定が漏れる可能性は無くなります。そしてSetterがないため一度生成されたインスタンスに対してはフィールドを変更できなくなります。そしてこの@Valueアノテーションの良いところは、Builderパターンと両立できるというところです。@Builderをつけることで、インスタンスの生成時にそれぞれのフィールドがどんなものであるかを明確に確認できますね。ただ、Builderパターンでは全フィールドに値を指定する義務はないので注意が必要です。この問題は、手でbuild()メソッドを書くことで回避できます。ある意味、オーバーライドに近いことだと言えますね。コードで表現すると、以下のようになります。@Value@Builderpublic class Car { private String name; private String color; // 以下のコードだけを作成 public static CarBuilder { // nullのフィールドがあったらNPEを発生させる public Car build() { if (this.name == null) { throw new NullPointException(); } if (this.color == null) { throw new NullPointException(); } return new Car(this.name, this.color); } }}この場合はやはりコードが複雑になり、フィールドが増えるとまたそれに対応しなければならなくなりますね。フィールドがまたListだったりすると、ループでnull検査をする必要もあるはずです。このように@Valueだけを使う場合に比べ、コードが複雑になっているので、便宜生と安全性でどちらを選ぶかを考える必要がありますね。final宣言Beanを使うしかない場合もありますね。例えばフィールドがnullになっても良い場合もあるはずです。それともそのBeanを持って処理をするメソッドでnullを検査するなど、何かの措置をしといたら良い場合もあるはずでしょう。そしてBeanを使う場合、フィールドをprivateに宣言して外部からの直接的なアクセスを防ぐということは常識となっています。publicで宣言されたフィールドだと、どこでもアクセスできるようになり知らないうちに値が変更される可能性がありますからね。それを防ぐために、Beanのフィールドに直接的なアクセスを許容しなく、Setterメソッドで値を指定してGetterメソッドで値を参照することは暗黙のルールとなっています。Setterメソッドによってフィールドに直接アクセスせずに値を指定することで最低限の安全は確保したと言いたいところですが、実はそうでもありません。なぜなら、依然としてフィールドの値は何度でも変わる可能性があるからです。一度Setterで値を入れて、その後にまたどこかでSetterを読んでいたら、Beanの持つフィールドの値は上書きされます。これを防ぐためには、フィールドにfinalを使うべきです。final宣言されたフィールドは、初期化以後にその値が代入されないため、安定性が上がります。final宣言されたフィールドに値を代入しようとするとコンパイルエラーとなるため、エラーを見つけやすいというところも良いですね。また、全フィールドがfinalで宣言されている場合、@Dataアノテーションは実質的に@Valueアノテーションと同じコードを生成します。もちろん、場合によってはfinalではないフィールドを持たせることもできます。そういう場合のコードは以下のようになります。場合によってはこれも必要かもですね！// @Dataの場合public class Car { // colorだけがfinal private String name; private final String color; // 以下のメソッドたちが自動生成 public Car(String color) { this.color = color; } public void setName(String name) { this.name = name; } public String getName() { return this.name; } public String getColor() { return this.color; }}ただ、finalとなっているのはあくまでもこのクラスのフィールドのみということに気をつけなければならないです。Carオブジェクトを生成時に使われたデータが、以後も固定されて更新ができなくなります。浅いコピーと深いコピーSetterメソッドのもう一つの問題は、オブジェクトをコピーした場合に、コピー先のオブジェクトの値を変えるためにSetterを使うとそれがコピー元に影響するということです。簡単に以下のようなコードを作成したとしましょう。// @DataのCarクラスCar car1 = new Car();car1.setName("My car");car1.setColor("red");// 友達が私と同じ車を買ったCar car2 = car1;car2.setName("Your car");// 出力してみるSystem.out.println(car1);System.out.println(car2);このコマンドをコンパイルして実行してみると、どちらのCarもnameがYour carになっていることを確認できます。なぜこうなったのでしょう？先はStringがImmutableと言っていましたけどね。これは、car1の値だけをcar2にコピーするという意図から書かれたコードが、実はcar1とcar2は「同じメモリーアドレスを参照する」というコードになってしまったからです。同じアドレスから値を参照するため、そのアドレスの値が変わると両方に影響するわけです。このようにオブジェクトは参照が変わるだけなので、代入だけではそれぞれが独立していると言えなくなります。プリミティブ型が値そのものを保存するので代入でも安全なのとはまた違うところですね。このようにオブジェクトの「参照」だけが変わる状況を「浅いコピー」と言います。今までの展開から推測できるように、オブジェクトの参照を分離する必要があるでしょう。参照が独立していると、片方の値が変わっても他には影響ないはずですからね。参照がオブジェクトごとに違うというのは、同じ値を持ってメモリーに新しいオブジェクトを生成するということと同じ意味です。そしてこれを「深いコピー」と呼びます。深いコピーには様々な方法があります。まずはフィールドのオブジェクトを新しく生成することです。例えば、以下のような方法がありますね。// インスタンスを生成して値を入れてみるCar car2 = new Car();car2.setName(new String(car1.getName()));car2.setName(new String(car1.getColor()));// 値を変えてみるcar2.setName(new String("Your car"));同じく出力してみると、今回はちゃんとcar2の値だけが変わったことを確認できます。しかし、全てのフィールドに対してこうするのはあまり便利ではないですね。とこかでメソッド化することはできないのでしょうか？簡単なのは、インタフェースを利用することです。Cloneableを継承することで簡単にオブジェクトをクローンできるようになります。ただ少し、メソッドを作成する必要はありますがね。@Datapublic class Car implements Cloneable { private String name; private String color; // cloneメソッドを作る  public Car clone() throws CloneNotSupportedException { return (Car) super.clone(); }}こうすると、以下のような方法で深いコピーができるようになります。try { car2 = car1.clone(); car2.setName("Your car");} catch (CloneNotSupportedException e) { e.printStackTrace();}ただ、この方法を使うときに注意すべきことがあります。クラスにclone()を定義したからって、全てのフィールドに対して深いコピーを保証するわけではないということです。例えばCarクラス内にさらにEngineのような、Beanクラスがフィールドとして定義されていると、そのフィールドは浅いコピーになる可能性があるということです。これを回避するためには、EngineクラスにもCloneableを継承させる必要があります。以下のようにです。@Datapublic class Car implements Cloneable { private String name; private String color; // 追加したフィールド private Engine engine; // フィールドも深いコピーをさせる public Car clone() throws CloneNotSupportedException { Car car = (Car) super.clone(); car.engine = this.engine.clone(); return car; }}@Datapublic class Engine implements Cloneable { private String name; private String cylinders; // cloneメソッドを作る  public Engine clone() throws CloneNotSupportedException { return (Engine) super.clone(); }}ListやMapの場合はどうクローンしたら良いでしょうか？同じくオブジェクトをクローンする観点からすると、両方とも方式は似ています。ループによるクローンですね。例えば以下のような方法でクローンができます。// ListのコピーList<Car> carList1 = new ArrayList<>();List<Car> carList2 = new ArrayList<>();for (Car car : catList1) { carList2.add(car.clone());}// MapのコピーMap<String, Car> carMap1 = new HashMap<>();Map<String, Car> carMap2 = new HashMap<>();for (Entry<String, Car> entry : carMap1.entrySet()) { carMap2.put(entry.getKey(), entry.getValue().clone());}これでImmutableなクラスを作り、コピーもできるようになりますね。Immutableなクラスで注意することReflectionに関するポストでも紹介したように、Reflectionを使うとフィールドに直接アクセスができ、privateで宣言されていてもアクセスを可能にすることもできます。つまりいくらImmutableなクラスを作ったとしても、Reflectionを使うとフィールドの値を変えることはできるということですね。そしてImmutableなクラスを作るということは、結局メモリーの使用量が上がるということでもあります。常に新しくオブジェクトを生成し、それぞれがメモリーを占有することになりますからね。もちろん現代のマシンのメモリーは多少のオブジェクトが作られても耐えられるメモリーを持っていますし、GCも活発に動いてくれるので一般的には心配するようなことではないですがね。Singletonクラスの変数には注意Immutableとも関係があることですが、以前紹介したSingletonクラスを作成する場合にも、そのクラスが持つフィールドには注意しなければならないです。このクラスはインスタンスが生成されるとアプリケーションが終了するまで一つのインスタンスが使われるため、フィールドの値が変更される可能性があったら致命的です。処理ごとに結果が変わる可能性があるからです。なのでSingletonクラスにはなるべくフィールドを持たせないようにするか、final宣言をしておくなど、フィールドの値が変わる可能性を最初から封鎖しておく必要があります。最後に個人的に、プログラミングの始まりが「どう実現するか」だとすると、プログラミングの完成は「どう安定させるか」であると思います。もちろん、性能を改善させたり、維持補修を簡単にさせたりするテクニックも大事ですが、安定的に動作するプログラムを作るということがもっとも難しいものですからね。要件が増えれば増えるほど、コードは複雑になり、例外が発生する可能性も高くなります。Immutableなクラスを作るということは、そのような例外を回避するための一歩であるゆえ、信頼できるプログラムを作り出せるという面で大事な知識なのではないかと思います。これからもこのような知識に触れ、身につけていきたいですね！

インスタンスをImmutableにするための工夫

昔からPCを使うといつも問題となるのはメモリーだった覚えがあります。私が初めてPCに触れたのは父が仕事て使っていたもので、当時はOSとしてDOSを採用していてゲームでもしたいときはいつもメモリーの設定を変える必要がありました。そのときはそれが不便だとも思わず、ただゲームができればいいと思っていました。しかし時間が経ち、大学でのプレゼンテーションを準備しながら感じたのは、やはりメモリーが十分でないとマルチタスクがきついということでした。今はPCのパーツの中でもっともアップグレードした時に性能向上を感じられるのはSSDと言いますが、それはあくまでCPUとメモリーを安定的に確保できる時代になったおかげと思います。まずメモリーが足りないととにかく遅いとしか思えない時代もありましたからね。そしてプログラムを作る立場となってからは、メモリー問題はより現実的な問題となりました。例えばとあるシステムを構築し、複数の使用者がそのシステムを利用するとしたら、限定された資源であるメモリーが足りなくなる可能性はハードウェアが飛躍的な発展を成している現在でも存在しています。オブジェクトを作るたび、残りのメモリーは減り続けるので。ならば最適化という面で、メモリーを節約するには、無駄なオブジェクトの生成は抑えるべきでしょう。そのためにできる方法がないかと思っていたら、すでに存在していました。今回のポストの主題となる、Singletonパターンです。SingletonパターンとはSingletonパターンは、アプリケーション内でインスタンスが一度だけ生成され、そのアプリケーションが終了するまで使われるクラスを作るためのデザインパターンです。Beanの場合はそれぞれ違うデータを持つインスタンスをたくさん生成して使いますが、こちらはインスタンスが一つしかないため動的なフィールドを持たせないですね。なのでどこからでもアクセスできるような不変のデータを持ったり、特定の処理を繰り返す必要がある時このSingletonパターンでのクラスを作る場合があります。このようなクラスがあって何が良いかというと、先に述べたメモリー問題です。例えばグローバル変数の場合、どんなクラスからもアクセスできるのであまりSingletonと変わらないようにも見えます。しかしグローバル変数の場合は、それが使われるが使われないが常にメモリーのなかにあって、無駄になってしまう可能性もあります。しかしSingletonの場合は、必要であれば生成し、必要でなければ生成しないこともできます。なのでメモリーを節約できますね。仕事では主に、ユーティリティークラスとしてSingletonクラスを作ることが多かったです。データの処理を繰り返して行う必要がある時、毎回インスタンスを生成することはメモリー問題もあって、コードが無駄に冗長になる傾向がありました。これをデータはそれぞれ違うインスタンスのBeanに持たせ、Singletonクラスに処理を任せることでコードの量も減らし、メモリーも節約することができました。古典的SingletonパターンそれではSingletonクラスをどうやって作るのかを紹介します。デザインパターンでは様々なパターンがあって、その中の一つであるSingletonもまた様々な方法で具現できます。まずは古典的な方式を紹介します。ここで目的はインスタンスを一つだけにすることなので、外部からすでに生成されているインスタンスにアクセスはできても、そのインスタンスを勝手に作れないようにします。そうするにはコンストラクターにアクセスの制限が必要ですね。まずコードで紹介しましょう。// クラスはpublicにして外部からアクセスできるようにするpublic class SingletonClass { // コンストラクターはprivateにして、外部からはアクセスできないようにする private SingletonClass() {}}しかしこれだけでは十分ではありません。どこかでインスタンスを生成する必要がありますね。また、先に述べたようにインスタンスの生成の時点は外部で制御できるようにしなければなりません。なのでprivateのコンストラクターにアクセスできるメソッドを用意する必要があります。public class SingletonClass { // インスタンスを保存するための静的フィールド private static SingletonClass uniqueInstance; private SingletonClass() {} // インスタンスの返却(インスタンスが生成されたない場合は生成してから返却する) public static SingletonClass getInstance() { if (uniqueInstance == null) { uniqueInstance = new SingletoneClass(); } return uniqueInstance; } public void doSomething() { // ... 普通のメソッド }}まずstaticで、自分のインスタンスを保存できるフィールドを宣言します。外部からSingletonクラスのインスタンスを取得するためにはこれを使うようになります。宣言だけで、この段階でインスタンスを生成しないのはグローバル変数と区別するためです。次に、インスタンスが生成されてない場合でもアクセスできるstaticメソッドを作成します。ここからこのSingletonクラスのインスタンスを取得するようになります。メソッドの中はでは戻り値としてインスタンスのフィールドをセットし、もしインスタンスが生成されてない場合にだけnewをするようにします。これで外部からは以下のように使えるようになります。// インスタンスの取得SingletonClass singletonInstance = SingletonClass.getInstance();// インスタンスのメソッドを使用singletonInstance.doSomething();これでどこからでも同一なインスタンスでつかけるSingletonクラスができました。古典的Singletonパターンの問題マルチスレッドを考える必要がない場合なら気にすることはないですが、現代のプログラミングはそうでもないですね。特に何かのシステムを作り、サービスとして提供する場合は複数の使用者によって同じクラスが要請される場合があります。そしてクラスの中が複雑でインスタンスの生成に時間がかかったり、ほぼ同時のタイミングでインスタンスが要請されると古典的なSingletonパターンでは複数のインスタンスが生成されることを塞げられない場合があります。この場合は元の設計通り動かなくなり予想できない例外が発生する可能性がありますね。もちろんこれらを解決するためにいくつかの方法が提示されてはいますが、それらの解決策にもデメリットはあります。まずどんな方法があり、それぞれのデメリットには何があるか見ていきましょう。マルチスレッド問題を開所するために他にも方法はありそうですが、スレッドセーフなSingletonクラスを生成する方法は以下のようなものがあります。インスタンスの生成をシンクロさせるDouble-Checked Lockingを使うJVMのクラスローダーにお任せまずインスタンスの生成をシンクロさせる方法は簡単です。インスタンスを取得するためのgetInstance()メソッドにsynchronizedを追加することです。コードで見るとあまり変わらないので、古典的Singletonパターンのクラスがあればもっとも簡単に適用できる方法ですね。public class SingletonClass { private static SingletonClass uniqueInstance; private SingletonClass() {} // インスタンスを提供するメソッドをシンクロさせる public static synchronized SingletonClass getInstance() { if (uniqueInstance == null) { uniqueInstance = new SingletoneClass(); } return uniqueInstance; }}ただ、synchronizedの問題は性能です。100倍以上も処理の速度が遅くなる場合もあるらしいので、マルチスレッドを性能のために使う場合があれば、あまり望ましくないですね。次の方法は、二重チェックです。インスタンスがnullであればシンクロさせます。この方法だと毎回シンクロさせる必要がないので(2回目からはインスタンスがnullでないため)最初の一回以外は性能が低下しません。public class SingletonClass { // volatile宣言で安定性を確保 private volatile static SingletonClass uniqueInstance; private SingletonClass() {} // インスタンスの二回確認 public static SingletonClass getInstance() { if (uniqueInstance == null) { synchronized (SingletonClass.class){ if (uniqueInstance == null) { uniqueInstance = new SingletoneClass(); } } } return uniqueInstance; }}volatile宣言を使う理由は、変数がCPUのキャッシュメモリーに入ることを防止するためだそうです。プログラムのデータは最初ハードディスクから読み込まれシステムメモリーに載せられますが、そのあとCPUでの処理が行われる時にはさらにCPUのキャッシュメモリーに載せられることがあります。最近は複数のCPUを搭載しているシステムも少なくないので、それぞれ違うCPUのキャッシュメモリーにインスタンスが入ってしまうとインスタンスが生成されているかどうかわからなくなりますね。volatile宣言でシステムメモリーにフィールドを乗せることで、インスタンスの生成がより安定的に行われます。でも依然として、同期化による性能低下を一回は経験しなければならないという問題があります。最後は、JVMが起動する時にインスタンスを生成させる方法です。この方法では外部からは確実にインスタンスの制御ができなく、常にインスタンスが生成されるためマルチスレッド問題を回避できますね。public class SingletonClass { // フィールドにインスタンスの生成を宣言 private static SingletonClass uniqueInstance = new SingletonClass(); private SingletonClass() {} // インスタンスのチェックも要らなくなる public static SingletonClass getInstance() { return uniqueInstance; }}クラスが読み込まれる時点でJVMからインスタンスを生成してしまうので、どんなスレッドからも静的フィールドにはアクセスできなくなります。ただ、これならグローバル変数で宣言することとあまり変わらないので、使われなくてもメモリー上にはインスタンスが生成されたままであるという問題は残ります。もちろん、グローバル変数宣言とは違ってインスタンスは唯一であることが違うところです。グローバル変数だとstaticでフィールドを宣言しても、違うクラスでまたを宣言できますので。そもそもグローバル変数には何が入っているかわからなくなる場合が少なくないので、乱発しないほうがいいですね。メソッドとフィールドを全部staticに宣言して良いのでは？もちろんその方法もありです。しかし、初期化の過程が極めて簡単な場合にだけ有効(フィールドが何もないなど)な方法と言えます。クラス自体が単純な構造をしていて、メソッドは単純に外部から入れられたデータを処理して返すだけならできる方法ですね。実際使えない方法ではないですが、後の機能拡張などを考えると良い方法ではなくなりますね。最後にSingletonパターンは幅広く使われていて、確かに魅力的なクラスの設計の方法ではあります。しかしマルチスレッド問題を回避するため工夫しなければならない問題があり、唯一なインスタンスなためフィールドの処理にも気をつけなければならない面があります。とあるスレッドでインスタンスが使われていて、フィールドにデータを入れたのをまた違うスレッドでアクセスしようとすると問題が起こり得る可能性がありますので。他にもOOPの原則である、「一つのクラスは一つだけの責任を持つ」ということからしても、Singletonクラスは問題を持っています。何かの処理を担当していながらも、自分自身でインスタンスを管理するという二つの責任を持っていますからね。そしてコンストラクターがprivateであるため、サブクラスを作られなくなるという問題があります。サブクラスを生成するためにコンストラクターをpublicやprotectedに変えるとSingletonではなくなるジレンマもできますね。それでもSingletonパターンで作られたクラスは、確かな魅力を持っています。ちゃんとインスタンスの管理さえできていれば、どこでも呼びたして使うことができますからね。常にメモリーに載せる必要があるクラスができたら、検討したくなるパターンです。

デザインパターン、Singleton

前回のポストで、BuilderパターンとともにLombokを紹介しました。Beanだけでなく、Immutableなクラス1やBuilderを作れるなど便利な機能が集まっていて、さらにアノテーションで様々なオプションが指定できたり(フィールドのアクセスレベルを指定できるなど)、必要なメソッドは追記しても良いなど使い道が多いですね。ただ、今回はそのLombokを使いながらバグらしき現象を発見したのでポストします。バグの発生したところどこでバグが発生したかを述べる前に、まずどんなLombokのアノテーションを使っていて、それらがそれぞれどんな機能をしているかを紹介したいと思います。なぜなら今回の場合は二つ以上のLombokアノテーションを組み合わせて使っていて、ほかにも自分と同じような組み合わせでLombokを使って同じバグを経験される方がいるかも知れないからです。Lombokの@Builderには、(toBuilder=true)のオプションをつけられます。これを使うと、基本的に新しいインスタンスの生成はstaticメソッドを呼ぶ事でできるようになって、すでに存在しているインスタンスから一部の値を変えて違うインスタンスに再生成する事ができます。コードで表現すると以下のようになります。// @Builderだけを使って新しいインスタンスを生成House house2 = House.builder().type("wooden").build();// toBuilderオプションで既存のインスタンスから値を変えて再生成House house3 = house2.tobuilder().type("block").build();そしてBuilderを使いながらも、元のクラスのフィールドの中でBuilderにデフォルト値として渡したいものもあります。つまり、Nullにしたくない場合ですね。自分の場合は、Listでした。インスタンスが生成される場合にはとにかくListを初期化して、Builderを使ってListそのものを代入したり、addList()のようなメソッドを作って個別の要素を追加できるようにしたかったです。これを実現するためには、元のクラスでListを初期化して、その状態でBuilderに渡す必要はありました。Lombokのアノテーションではフィールドに@Builder.Defaultをつけることでできるようになります。そしてBuilderのアノテーションでは生成されない、addList()的なメソッドだけを実装することですね。コードで表現すると以下のようになります。@Builder(toBuilder=true)public class Wallet { // Builderでインスタンスが生成されるときはNullにしたくない @Builder.Default List<String> cards = new ArrayList<>(); // カスタムメソッドをBuilderに追加するための宣言 public class WalletBuilder { // 元のBuilderではListそのものを代入する方法しかないので、個別要素を追加できるメソッドを書く public WalletBuilder addCard(String card) { this.cards.add(card); return this; } }}こうした実装で期待していた動きは以下のようなものでした。// インスタンスを生成しながらListにAddするWallet myWallet = Wallet.builder().addCard("Apple Card").build();// 既存のインスタンスにAddするWallet newWallet = myWallet.toBuilder().addCard("American Express Card").build();しかし、実際テストをしてみるとこの二つのアノテーションによりバグが発生したのです。それでどんなバグが？既存のインスタンス(Listの操作を一切していない)ではaddが思い通りになったのですが、インスタンスを生成すると同時にaddした場合はNPE2が発生していました。場所を調べてみるとthis.cards.add(card);のところで例外が発生していたので、生成されてないオブジェクトに要素を追加しようとしていたとのことですね。つまり、Listがちゃんと初期化されてないという事です。少し調べてみると、Githubでのイシューがありました。2017年に書かれたもので今となってはずいぶん古い感じもしましたが、読んでみると今の自分が経験している現象と似ていましたね。しかも、Lombokの1.18.2バージョンで解消されたという話もありましたが、今の自分が使っているバージョンは1.18.8でした。解消されているはずがちゃんと想定通りならなかったのか、バージョンアップにより再発したのかわかりませんが、ともかく同じ現象が起きていましたね。解決策それではどう解決したらいいか？他にも方法があるのかもしれませんが、自分の場合はtoBuilder=trueと@Builder.Defaultの両方を使わない事で解決できました。Builderにちゃんとフィールドが渡らない時点で後者は意味がなくなりました。そしてtoBuilderの場合も、二つのメソッドが追加されるだけなのでそれを手書きで確実に値を渡せるようにしました。上で提示したWalletクラスをこのやり方で直すと、以下のようなコードになります。// toBuilderオプションを使わない@Builderpublic class Wallet { // @Builder.Defaultを使わない List<String> cards = new ArrayList<>(); // toBuilderメソッドも手書きする public WalletBuilder toBuilder() { return new WalletBuilder().cards(this.cards); }}これで元の想定通り、インスタンスを生成する時もちゃんと初期化されたListが渡るようになりました。めでたしめでたし。教訓？ライブラリーを使ってコードの量を減らし、自動化することは生産性の向上という面では大事な事ではありますが、人間の書いたコードはどこでバグが発生するかわからないので(想定していない使い方をする場合もありますし)、たまには手間がかかっても確実なコードを書くのが安全な場合もありますね。特にこの場合、アノテーションを諦めずコードを直そうとしていたらいつまでたってもバグは回避できなかったのかもしれません。そういう意味で、よい勉強になったと思える事件ではなかったのだろうかと思います。もしこのポストを読まれる方の中、私と同じような実装を考えている方がいたら、こんなこともあるんだなと参考できるようなことになっていると嬉しいです。それではまた会いましょう！一度インスタンスを生成すると、途中で値を変える事が出来ないクラス。Stringの場合がそうです。値を代入すると、メモリーに載せてある値を捨てて新しく生成します。 ↩︎Null Pointer Exception、ヌルポとも呼ぶ例外です。参照しようとしているオブジェクトがメモリー上にありませんよーとのことで、Javaで最も遭遇しやすい例外ですね。 ↩︎

Lombokのバグにあった話

今回も、いつもと同じく仕事で得られた知識です。とあるIterableなクラスを作り、Forループをさせる必要がありました。これはそんなに難しいことではなかったです。まずフィールドにリストを持たせる。またIterableをインプリメントし、戻り値がIteratorであるメソッドを作るだけでしたね。しかし問題は、そのクラスのループの途中で、「使用者が指定したルールによりループを終了させる機能のあるクラスを作ること」でした。つまり、ループを終了させるには引数でループ中の要素を受け入れる引数を持つメソッドが内臓されていて、そのメソッドはインスタンスごとの基準となるデータを持っているということですね。メソッドをフィールドとして使う？メソッドとして機能しながらフィールドみたいにデータを持つ？それをさらに使用者が指定できるようにする？難しい注文だったので一瞬迷いましたが、「functionを使うといい」というアドバイスを受け、調べてみました。なるほど、これを使ったらフィールドとして宣言しながらもメソッドの機能を期待でき流みたいです。早速適用してみて、それがどう機能するかをまず紹介したいと思います。まずはIterableなクラスを用意します。ループの対象となるのはこちらです。// Lineというクラスをリストとして持ち、Iterate可能なクラスpublic class Factory implements Iterable<Line> { private List<Line> lines = new ArrayList<>(); public Iterator<Line> iterator() { return this.lines.iterator(); }}次はこのFactoryクラスを持ってループをさせる例です。ループの途中でRuleクラスのisEnd(Line)での判定が入ります。Lineインスタンスの中で何か条件に当たるものがあったら、戻り値がTrueとなってループから抜ける構造です。// IterableクラスFactory factory = new Factory();// forループでFactoryの中のLineオブジェクトを処理for (Line line : factory) { // Ruleクラスのループ終了判定メソッドを使う if (Rule.isEnd(line)) { break; } // ... 何らかの処理}ここで判定を行うRuleクラスの場合は、以下のようになっています。public class Rule { // 判定のルールをフィールドとして持っている private Predicate<Line> endRule = line -> line.isBroken(); // 引数のLineがPredicateの条件に当たるかを判定するメソッド public boolean isEnd(Line line) { return endRule.test(line); } public class RuleBuilder { // 中身は普通のBuilder private Predicate<Line> endRule; public RuleBuilder endRule(Predicate<Line> endRule) { this.endRule = endRule; return this; } }}まずPredicateが何であり、Lambdaだけであれができる？と思われそうなコードです。しかしちゃんと動いてくれています。それはなぜか？今までよくしらなかったですが、Java8から追加されたjava.util.functionによるマジックでした。フィールドはデータを持つためのものである、とは思っていましたが、そのデータというのがメソッドそのものにも慣れるとは知らなかったですね。それでは、そのjava.util.functionが一体どんなものかを、それに含まれている様々なインタフェースたちを持って紹介したいと思います。Functional Interfacejava.util.functionに含まれている様々なインタフェースたちを、関数型インタフェースと呼ぶらしいです。Java8で追加されたLambdaを「実装すべき抽象メソッドが一つしかないインタフェースを具現化したもの」と言いますが、ここでいう「実装すべき抽象メソッドが一つしかないインタフェース」のことが関数型インタフェースです。言葉として表現すると難しいですが、要は一つです。中身をLambdaで満たせて完成するインタフェース。様々なタイプのものがあって、ぞれぞれの特徴は少しづつ違いますが、どんなことがして欲しいかによって選択するものが違うだけで、実際はそんな難しくもないです。むしろ難しいと言えばLambdaの方かな…とにかくこれらの関数型インタフェースを、一つづつ紹介しましょう。FunctionFunctionは、そのなの通り典型的な関数です。引数と戻り値を指定して宣言します。実行はapply(適用)となります。コードで見ると以下のようになります。// Integerが引数で、Stringが戻り値となる例Function<Integer, String> function = number -> String.valueof(number);// Functionの実行String result = function.apply(12);BiFunctionFunction以外にも「Bi」が付くいくつかの関数型インタフェースがあります。何が違うかというと、そのなのとおり引数が二つ。他は元のものとほぼ一緒です。// 二つのStringが引数で、Integerが戻り値となる例BiFunction<String, String, Integer> biFunction = (string1, string2) -> Integer.parseInt(string1) + Integer.parseInt(string2);// BiFunctionの実行int result = biFunction.apply("1", "2");Predicate先に紹介したものですね。Predicateは「述語」の意味を持っています。その名の通り、「引数がTrueかFalseかを述べる」ようなものです。引数は一つです、戻り値がBooleanです。実行はtestです。// 引数がStringの例Predicate<String> predicate = string -> string.isEmpty();// Predicateの実行boolean result = predicate.test("空じゃない！");BiPredicate引数が二つのPredicateです。// 引数がStringの例BiPredicate<String, Integer> biPredicate = (string, number) -> string.equals(Integer.toString(number));// BiPredicateの実行boolean result = biPredicate.test("1", 1);ConsumerConsumeは消費するという意味がありますね。引数を受けて戻り値はない(voidとなる)ものです。実行するときはaccept(受納)となります。// 引数がStringの例Consumer<String> consumer = string -> System.out.println(string);// Consumerの実行consumer.accept("吸収！");BiConsumer引数が二つのConsumerです。// 引数がStringとIntegerの例BiConsumer<String, Integer> biConsumer = (string, number) -> System.out.println(string + "：" + number);// BiConsumerの実行biConsumer.accept("今年儲かる確率は", 0);UnaryOperatorUnaryは「単項」の意味。Operateは作用するという意味を持っていますね。引数と戻り値が同じもので、引数に何かの操作をしてから返すという印象です。UnaryOperator<String> uOperator = string -> string + "完成されます";// UnaryOperatorの実行String result = uOperator.apply("この文字を入れると");BinaryOperator引数が二つのOperatorです。BinaryOperator<String> biOperator = (string1, string2) -> string1 + string2 + "ではないです";// BinaryOperatorの実行String result = biOperator.apply("私は", "大丈夫");SupplierSupplyは「補給」の意味。Consumerとは真逆のもので、引数がなく戻り値だけがあるものです。実行はgetとなります。引数がないためこちらはBiSupplierのようなインタフェースがないです。Supplier<String> supplier = () -> "例えば引数なしで文字列が帰ってくる！";// Supplierの実行String result = supplier.get();最後にJava8が出てから数年、もうJavaも12までバージョンアップしています。でもまだJava8が使われている場面は多く、なるべくJava8の機能を最大限に活かしたコードを書きたいものですね。LambdaもStreamも難しいですが、Functionみたいにどこかで使うことになってまた今まではできなかったことをできるようになりたいです。今回も色々と勉強になりました。Javaの世界はまだまだ広くて奥深いものですね！

関数型インタフェースを使う

今回の仕事で学んだことは、自分のコードを他人がライブラリーとして使うときはどのように実装していくかの方法です。とある機能をするスクリプトを書くこと、エンドユーザーが使うUIやそコンテンツを処理するロジックなどだけに関わったことのない自分にとってはとても新しい経験になりました。今までだと自分が担当した機能を具現し、それを最適化していいだけでした。でも、ライブラリーは基本的にコードを扱える人が使うものなので設計が全く違いますね。そして、難しかった部分の一つは、柔軟性を持たせることでした。例えばデータを受け取り、処理していく中で、今までは自分が実装したBeanにデータがマッピングされていることを第一の前提条件としていました。それが今の仕事では、「どんなBeanが入ってくるかわからないから、それに対応する」ようにする必要がありました。まずクラスやインスタンスを引数として受け取る方法を知る必要がありますね。最初はObjectそのものを使おうと思いましたが、調べてみるとGenericというものがあったので、そちらを使うことにしました。次にそのGenericを使って、引数として受け取ったBeanです。自分が設計したBeanだけを使うなら、Beanが持つフィールドのデータ型も知っていいて、Getter/Setterからデータのやりとりができますね。しかし自分が作ったものではないと、フィールドのデータ型もGetter/Setterメソッドもどう呼ぶかもわからなくなります。ここでどう対応したらいいだろうか…と悩み、探し出した答えがReflectionでした。今回のポストはその二つを使い、どう「自分が作っていないBeanを処理」したかについて述べ地と思います。GenericGenericとは、「データのタイプを一般化」するということです。総称型とも呼ぶらしいです。クラスの中で使うタイプを、クラスの外部から設定するとき用いられると言いますね。今までは主に複数のデータ型やオブジェクトを処理したい場合はObjectを使ってきました。Javaでは一部のPrimitive(参照型)を覗くと、ほとんどのデータががオブジェクトとして扱われているので、もっとも上位のタイプであるObjectに変えられらからです。しかし、Objectを引数として使うと、メソッドの中のフィールドが何があるかわからなくなります。また、Getter/Setterによる値の指定・取得などの操作もできませんね。なのでオブジェクトそのものを受け取るだけでなく、インスタンスの中を直接覗く必要があります。ここでGenericを使うと、Objectと同じ機能(どんなインスタンスやクラスでも受け取れる)をしながらも、最初に具体的なタイプが決まるのでキャストがいらなくなります。これなら性能的にもよく、より安全な挙動を期待できますね。あとは実際どんな構造をしているかわからないObjectに対し、Reflectionを活用して、クラスやインスタンスの中を覗いたらメソッドもフィールドも取得できるというメリットもあります。まずインスタンスを引数として受け取る方法から見てみましょう。引数としてT1を指定します。これでGenericタイプの引数を受け入れられます。つまり、インスタンス自体が引数となるということです。ただ、引数がTの場合はメソッドの戻り値の前でも<T>を宣言する必要があります。コードで表現すると以下のようになります。// Beanのインスタンスを受け取るメソッドpublic <T> boolean isBean (T parameter) { // ... 何かの処理}// 使用例BeanObject beanObject = new BeanObject();if (isBean(beanObject)) { // ... 何かの処理}Listの中にもGenericを使うことができます。たとえば以下のように書くと、どんなタイプも受け入れられるようになりますね。List<T> list = new ArrayList<>();インスタンスではなく、クラスそのものをGenericで受け入れるには以下のように書きます。// Beanのクラスを受け取るメソッドpublic boolean isBean (Class<?> parameter) { // ... 何かの処理}// 継承もできる(限定)public boolean isStringBean (Class<? extends String> parameter) { // ... 何かの処理}// 使用例if (isBean(BeanObject.class)) { // ... 何かの処理}こうやってGenericの引数を渡してもらう準備は完了です。次は、そうやって受け取った引数を扱うReflectionについて調べてみましょう。Reflectionクラスの具体的なタイプをわからなくても、メソッド・コンストラクター・フィールドなどににアクセスできるようにしてくれるAPIをReflectionと言います。取得したメソッド・コンストラクター・フィールドはいずれもそのまま使ったり、値(戻り値)を取得したり、つけられているアノテーションを取得するなど、普通のクラスでできることは全部できます。では、このReflectionを実際どう使うかを以下のコードで紹介します。まずはインスタンスからクラスを取得する方法と、さらに取得したクラスからコンストラクターを取得するコードです。public <T> boolean isBean (T object) { // インスタンスからクラスを取得 Class<?> objectClass = object.getClass(); // クラスからさらにインスタンスを生成する Object instance = objectClass.newInstance(); // クラスのパッケージ名を取得 String package = objectClass.getPackage(); // パッケージを含むクラス名を取得 Stirng classNamePackageInvolved = objectClass.getName(); // クラス名だけを取得 String className = objectClass.getSimpleName(); // 配列でpublicコンストラクターたちをを取得 Constructor[] constructors = objectClass.getConstructors(); // 特定のpublicコンストラクターを取得 Constructor constructor = objectClass.getConstructor(parameter1, parameter2, ...); // 取得したコンストラクターからインスタンスを生成 Object instance2 = constructor.newInstance();}クラス自体を扱うことができるので、その中身がわかれば新しいインスタンスを生成して使うこともできますね。それでは次に、フィールドを取得する方法を紹介します。Fieldの取得public boolean isBean (T object) { Class<?> objectClass = object.getClass(); // 配列でpublicフィールドたちを取得 Field[] fields = objectClass.getFields(); // 特定のpublicフィールドを取得 Field field = objectClass.getField("フィールド名"); // 配列で全フィールドたちを取得(public以外も) Field[] declaredFields = objectClass.getDeclardFields(); // 特定のフィールドを取得(public以外も) Field declaredFiled = objectClass.getDeclaredField("フィールド名"); // Fieldでできること // フィールドに値を設定 field.set(object, parameter); // フィールドの値を取得 String fieldValue = field.get(object); // フィールドのアノテーションを取得 Annotation[] annotations = field.getAnnotations();}ここで注意すべき部分は、フィールドを取得するときはクラスからであって、実際値を代入したり取得するときはその対象としてインスタンスを使うということです。クラスが設計図であり、インスタンスがその設計図で生成されたものだということが明確になる瞬間ですね。Reflectionを使うことのメリットはここにもあるのかもしれません。次には、メソッドをみていきます。Methodの取得メソッドもフィールドの場合とそう変わりません。クラスからメソッドを取得し、そのメソッドからさらに色々できるようになります。またコードを以下に用意しました。public boolean isBean (T objectClass) { Class<?> objectClass = object.getClass(); // 配列でpublicメソッドたちを取得 Method[] methods = objectClass.getMethods(); // 特定のpublicメソッドを取得  Method method = objectClass.getMethod("メソッド名", parameter1, parameter2, ...); // 配列でメソッドたちを取得(public以外も) Method[] declaredMethods = objectClass.getDeclaredMethods(); // 特定のメソッドを取得(public以外も) Method declaredMethod = objectClass.getDeclaredMethod("メソッド名", parameter1, parameter2, ...); // Methodでできること // メソッド名の取得 String methodName = method.getName(); // メソッドの実行 Object methodInvoked = method.invoke(); // 引数のアノテーションを取得 Annotation[] parameterAnnotations = method.getParameterAnnotations(); // 引数を取得 Parameter[] parameters = method.getParameters();}アノテーションの場合はクラスでもフィールドでも取得できますが、メソッドの場合はそれに加えて引数のアノテーションも取得できるということが特徴です。また、引数そのものを取得することもできますね。もちろんParameterクラスでも引数名を取得するなど色々な操作ができます。結論結局、道が見えてくると、解決の方法も見えてくるものです。メソッドをやコンストラクターに触れる必要もなく、引数で受け取ったインスタンスからフィールドを取得して、その値をObjectに代入する。そしてinstanceofを活用して分岐させ、キャストすることでデータを扱う、というシンプルな構造で自分のタスクは完成されました。簡単なコードで表現すると以下のような形ですね。// クラスをわからないBeanを引数とするメソッドpublic <T> processSomething(T bean) { // 複数のタイプのオブジェクトがある String stringObject; Integer intObject; // クラスとフィールドの取得 Class<?> beanClass = bean.getClass(); Field[] beanFields = beanClass.getDeclardFields(); // ループで個別フィールドを取得し、一致するタイプのオブジェクトにフィールドの値を入れる for (Field field : beanFields) { // privateフィールドの場合はアクセスできない場合があるためアクセス可能にする if (field.canAccess(bean)) { field.setAccessible(true); } // フィールドの値を取得し、型を判断 Object value = field.get(bean); if (value instanceof String) { stringObject = (String)value; } else if (value instanceof Integer) { intObject = (int)value(); } }}どうですか。方法がわかれば簡単にできるものなのでは。さらに応用して、インスタンスの一部の値だけを修正して返すなどの挙動もできそうです。色々活用できそうな面が多いですね。最後にこのようにだいたいフィールドとメソッドがわかれば、これでどんなインスタンスやクラスが入ってきても、対応できそうな気がします。実際どうかはコンパイルして実行してみない限りわからないものですが…でも一つ、賢くなったような気はします。皆さんもぜひ、Reflectionを通じてクラスとインスタンスに対する理解を深めてみてください。それでは、また！Typeのこと。ただ、E(Element)やK(Key)、N(Number)、V(Value)も使えるらしいです。 ↩︎

ReflectionとGenericを活用する

今回は、Jenkinsで生成したJobを実行する方法について述べたいと思います。基本的にJenkinsの管理コンソールでJobを実行することは可能ですが、いちいちログインしてJobを起動することは便利ではないです。なので「とある条件でJobを自動的に実行したい」と思うようになりますね。例えば簡単に考えられるものとしてまず「定期的実行」があるでしょう。特定の時間、もしくは頻度などを指定して自動的に実行してくれるバッチ的な処理にはこのような設定が必要ですね。また、とある条件が満たされた時にだけ実行したい場合もあります。たとえばGitのリポジトリにコミットが発生したときは、その時だけビルドしたいですね。JenkinsのJobではこのような、条件によるJobの自動実行を設定することが可能です。これをBuild Triggerと呼びます。基本設定でも必要なパターンの最低限は揃えていますし、プラグインの組み合わせによってはより多彩な設定でJobを実行するように設定できます。今回のポストでは、そのビルドトリガーにどんなものがあるか、またどのように使えるかということを述べたいと思います。Build Triggerの種類JenkinsでJobを生成すると、GeneralとSource Code Managementのタブの後にBuild Triggerというタブがあることを確認できます。プラグインの構成が違うと増えたり減ったりもするので一度確認してみてください。私はJenkinsをインストールするときオススメのプラグイン構成を選んでいるので、以下の構成になっています。Trigger builds remotelyBuild after other projects are builtBuild periodicallyGitHub hook trigger for GITScm pollingPoll SCMでは、これらの機能がそれぞれどんな意味を持ち、どう活用できるかを一つづつ見てみましょう。Trigger builds remotelyこれは、「遠隔」という表現通り、Jenkinsの管理コンソールに接続しなくてもJobを外部から実行できるようにするという意味です。このメニューを選ぶと、URLでJobをコールできるようになります。Authentication Tokenに認証として使うトークン名を入力すると、以下のようなURLでJobをコールできます。(JenkinsのURLが192.168.0.2:8080、Job名がTriggerTest、トークン名がbuildTokenであると仮定)http://192.168.0.2:8080/job/TriggerTest/build?token=buildTokenhttp://192.168.0.2:8080/job/TriggerTest/buildWithParameters?token=buildToken１番の設定は、パラメーターなしでただJobを実行するときに用います。２番目の場合は、パラメーターを渡したいときに使えますね。ここで受け取るパラメーターは、GeneralタブでThis project is parameterizedをチェックし、パラメーターを追加すると設定できます。パラメーターで受け取った値はJobの中のシェルスクリプトなどで外部変数として使うことができます。LinuxのCurlなど、外部からのコールが必要である時使うと便利な機能です。Build after other projects are builtJenkinsではJobを複数生成することができます。そしてJobを複数生成することはそれぞれ違う機能をするJobをそれぞれの目的に合わせて分けるという意味でしょう。ただ場合によってはそれらのJobを連携する必要もあるかもしれません。同じプログラムの中でもメソッドやクラスは分けてもそれらを繋いで使うことになりますので。こちらのオプションをチェックすると、どんなJobの後にビルドするかを入力できます。複数のJobを登録することもできますね。Projects to watchに先にビルドしたいJob名を入力し、下の三つのオプションを選びます。JenkinsのJobの実行結果にはstable(成功)unstable(一部成功)fail(失敗)の三段階があって、ここで選ぶのは前段階のJobがその三つのうちどのような結果になったかという判定の条件です。Trigger only if build is stableTrigger even if the build is unstableTrigger even if the build fails１番目は、前段階のJobが成功的にビルドできた場合。成果物が必要だったりするとこちらのオプションですね。２番目はビルドが不安定でも実行する。また３番目は失敗しても実行する。各自目的と用途が違うので、必要に合わせて適合したものを選びましょう。Build periodically時間による定期実行が欲しい場合はこちらのオプションを使います。Scheduleの欄に、Jenkins固有のルールに合わせて周期を書くと自動的に条件に合わせてJobのビルドが繰り返されます。かなり複雑ではありますが、一旦紹介します。基本フォーマット時間単位は空白を基準に分ける記入順は分(minute)、時間(hour)、日付(day of month)、月(month)、週(week)分(minute): 0から59までの数字時間(hour): 0から23までの数字日付(day of month): 1から31までの数字月(month): 1から12までの数字週(week): 0から7前での数字(0と７は日、1は月、2は火、3は水、4は木、5は金、6は土)*は入力できる全範囲の値を許容するという意味(分の位置に入力すると0~59までの全数字)M-Nのように-を入れると範囲の指定が可能(2-4は2から4までの値)M-N/Xまたは*/Xは合間の意味(時間の位置に*/2と入力すると、２時間置きという意味になる)A,B,Cのように複数の値を列挙できるそのほかに、周期的に実行されるJobが複数ある場合はHを使うことがオススメです。例えばJobが10種類あって、それぞれを0 0 * * *にすると、全てのJobが毎日0時に実行されることになりますね。もしサーバーのスペックがあまりよくなかったり、Jobの数がそれ以上になると負荷は無視できないレベルになるはずです。そこでH H * * *に指定すると、Jenkinsで自動判断を行い、サーバーへの負荷があまり発生しない時間帯にJobが実行されるようになります。もちろんHでも範囲の指定ができますのでH H(0-1) * * *のように指定すると、毎日0時から1時までの間、負荷の低い時間帯にビルドが行われます。このフォーマットに従って書かれたいくつかの例を見てみましょう。15分置きでビルド実行: H/15 * * * *毎時間の30分までに、10分置きでビルド実行(1時から1時半まで、2時から2時半までなど): H(0-29)/10 * * * *平日の9時から16時の間、２時間置きにビルド実行: H 9-16/2 * * 1-51月から11月の間、1日と15日だけビルド実行: H H 1,15 1-11 *フォーマットになれるまでは少し時間がかかりそうですが、かなり複雑なルールまで対応できるので魅力的なプションですね。GitHub hook trigger for GITScm pollingこのオプションはGitHubとの連動で、リポジトリにPushが発生するとビルドが行われるということです。Jenkins内ではこのオプションを選ぶだけであまり複雑な設定はないですが、GitHubのリポジトリでPushが発生したということをJenkins側に知らせるための設定が必要となります。GitHubのリポジトリに入ると、上段にSettingsというタブがあります。それをクリックし、さらにWebhooksというメニューに入ります。そうすると以下のような画面が現れます。ここでAdd Webhooksボタンを押すと、また以下のような画面になります。ここでも複雑な設定はいらなく、Payload URLにJenkinsのURL/github-webhookと書くだけです。例えばJenkinsのURLが192.168.0.2:8080だとすると、http://192.168.0.2:8080/github-webhook/と書きます。これでリポジトリにPushが発生したら、Jobは自動ビルドされます。WebサーバーでのGit管理もこれで簡単にできますね。Poll SCM'SCMとは、Source Control Management(ソース管理構成)のことです。1GitやSVNなどのツールによる意味します。Poll SCMを選択すると、Build periodically同様Scheduleの入力欄が現れます。ここに同じく周期を入力します。ただ何が違うかというと、設定した時間になっても必ずしもビルドが行われるのではないということです。設定した時間になるとソースの確認をして、そこで変更があった場合のみビルドが行われるらしいですね。GitやSVNの連動で使える設定みたいです。最後に様々なビルドトリガーの指定ができるゆえ、活用できる方法が多いという面もまたJenkinsの魅力ではないかと思います。Jenkins自体のアップデート対応も、周期的にyum updateするようなJobを構成するとできそうな気がしますね。そのほか、Git連動とsystemctlでのサービス管理機能を組み合わせてTomcatやNode.jsの管理もローカルでできますので便利です。それではまた、便利な使い方を見つけたらJenkinsのポストを載せましょう！ソフトウェアエンジニアリングの観点からは、Software Configuration Management(ソフトウェア構成管理)の略でもあります。簡単にいうとソースコードだけでなく、開発環境やビルド構造などの全般的な環境情報を定義・管理することを構成管理というらしいです。 ↩︎

JenkinsのJobを実行する

以前、自分より開発者として日本就職が早かった大学の後輩がいて、どんな言語やフレームワークを勉強した方がいいかを聞いたことがあります。周りではC#をやるといい、ReactやNode.jsのような流行りのライブラリーを学んだ方がいいという人もいましたが、現場で使われている人の意見が聞きたかったからです。そして彼は、言語やフレームワークはメインとしている言語をマスターしたらいつでも変えられるもので、実質的に必要となるスキルはデザインパターンと言っていました。それから本を買い、いくつかのデザインパターンを見たことはありますが、そのパターンたちをどう使ったらいいか一人で考えるのは難しいことでした。一人でコードを書く時は、自分が理解できるコードを書けばいいだけなのでそこまで考える余裕が無くなりますね。また、エンドユーザーだけを意識したコードになりがちだったのであまりパターンを含むコードの書き方をする必要もなかったです。それが今はJavaでのフレームワーク開発に関わることとなり、自分の買いたコードを違う人が使えるように書けとの指示を受けましたが、いつも通りDTOを元とするWrapperクラスを生成して行けばいいのかなと思っていたら、実装してみてからはこれはダメだなと感じました。なぜなら数十から数百に至る変数の設定値があって、引数として渡すのも単純な数字や文字などではなかったからです。自分の作ったコードが使う側として接した場合は、これはダメと思うはず。どう改善したらいいかと悩んでいたら、指示を出した方からBuilderパターンを使うといいだろうというアドバイうをもらいました。これなら引数は最低限にして、直観的に使えるらしいです。なので実際使ってみました。そして伝統的なDTOと比べてみると、確かになと思いましたね。何が違ってなぜ違うのかを、DTOとBuilderパターンの比べでこれから述べたいと思います。Telescoping Constructor Patternテレスコープとは望遠鏡のこと。どこが望遠鏡的かというと、だんだん伸びていくコンストラクターの形が望遠鏡の伸縮みたいでこんな名前になったようです。最近はJava Beanの中でもよく使われるパターンなのですね。オブジェクトを生成する時に引数の数によって値を入れる変数の数を調節できます。Method Overloading1で複数のコンストラクターを用意するだけです。例えばカフェでコーヒーを注文する過程を、Javaのクラスで具現化するとしましょう。カップのサイズ、ホットかアイスか、シロップは入れるか、クリームは入れるか…様々なオプションがありますね。これをTelescoping Constructor Patternで書くと、以下のようになります。public class CoffeeOrder{ private final String size; private final boolean hot; private final boolean addCream; private final boolean addSugar; private final boolean takeout; public CoffeeOrder(Stirng size, boolean hot){ this(size, hot, false, false, false); } public CoffeeOrder(Stirng size, boolean hot, boolean addCream){ this(size, hot, addCream, false, false); } public CoffeeOrder(Stirng size, boolean hot, boolean addCream, boolean addSugar){ this(size, hot, addCream, addSugar, false); } public CoffeeOrder(Stirng size, boolean hot, boolean addCream, boolean addSugar, boolean takeout){ this.size = size; this.hot = hot; this.addCream = addCream; this.addSugar = addSugar; this.takeout = takeout; }}これでオーダを定義するクラスが一つ、できました。実際使ってみましょう。public class Cafe{ public static void main(String[] args){ // オーダーごとのオブジェクトを生成する CoffeeOrder order_1 = new CoffeeOrder("tall", false); CoffeeOrder order_2 = new CoffeeOrder("grande", false, true); CoffeeOrder order_3 = new CoffeeOrder("venti", true, true, false); CoffeeOrder order_4 = new CoffeeOrder("tall", false, false, true, false); }}このパターンのよくない点は、オブジェクトを生成する時、引数の意味を分かりにくいという点です。実際クラスの中身をみないと、連続しているfalseやtrueの意味が分かりませんね。そして例えば、サイズとシロップだけを引数として入れたい場合は、それに合わせてまたコンストラクターを作成しなければならないです。変数が増えれば増えるほど、それに合わせコンストラクターを用意する必要があるという問題もあります。あとでオーダーのオプションが増えたり減ったりするとそれに対応するのが難しいですね。Java Bean, DTO(VO)JavaでOOP2の概念を学ぶ時、初めて接したのがこのJava Beanです。これも一つのパターンと言えますね。みなさんがよく知っているよう、GetterとSetterで値を渡すパターンです。同じくオーダーのクラスを作ってみましょう。public class CoffeeOrder{ private final String size; private final boolean hot; private final boolean addCream; private final boolean addSugar; private final boolean takeout; public CoffeeOrder(){} public setSize(String size){ this.size = size; } public getSize(){ return this.size; } public setHot(boolean hot){ this.hot = hot; } public getHot(){ return this.hot; } public setAddCream(boolean addCream){ this.addCream = addCream; } public getAddCream(){ return this.addCream; } public setAddSugar(boolean addSugar){ this.addSugar = addSugar; } public getAddSugar(){ return this.addSugar; } public setTakeout(boolean takeout){ this.takeout = takeout; } public getTakeout(){ return this.takeout; }}コンストラクターとして引数を受け取るパターンも含める場合はありますが、Java Beanとしての特徴はこのGetterとSetterにあるので、ここでは省略。では同じく、これでオーダーを生成してみましょう。public class Cafe{ public static void main(String[] args){ // オーダーの内容はSetterで設定する CoffeeOrder order_1 = new CoffeeOrder(); order_1.setSize("tall"); order_1.setHot(false); CoffeeOrder order_4 = new CoffeeOrder(); order_2.setSize("grande"); order_2.setHot(false); order_2.setAddCream(false); }}さっきよりは個別項目ごとに値を設定することができ、それぞれのSetterをみてどんなオーダーを出しているのかがより明確になりますね。また変数が増えてもそれに合わせてGetterとSetterを用意するだけで良いです。ただ、一つの注文を完成する時、オプションの数が増えると無題に長いコードになってしまうという問題がありますね。今は5つのフィールドを使っているだけですが、もし20、30のオプションがあったら？それをいちいち書くのはかなり時間もかかることですね。私が失敗したのはこの部分でした。なのでBuilderを使い、この問題を解決してみます。Builder Patternpublic class CoffeeOrder{ private final String size; private final boolean hot; private final boolean addCream; private final boolean addSugar; private final boolean takeout; public CoffeeOrder(Stirng size, boolean hot, boolean addCream, boolean addSugar, boolean takeout){ this.size = size; this.hot = hot; this.addCream = addCream; this.addSugar = addSugar; this.takeout = takeout; } public static Builder builder() { return new Builder(); } public static class Builder{ private final String size; private final boolean hot; private final boolean addCream; private final boolean addSugar; private final boolean takeout; public Builder(){} public CoffeeOrder size(String size){ this.size = size; return this; } public CoffeeOrder hot(boolean hot){ this.hot = hot; return this; } public CoffeeOrder addCream(boolean addCream){ this.addCream = addCream; return this; } public CoffeeOrder addSugar(boolean addSugar){ this.addSugar = addSugar; return this; } public CoffeeOrder takeout(boolean takeout){ this.takeout = takeout; return this; } public CoffeeOrder build() { return new CoffeeOrder(size, hot, addCream, addSugar, takeOut); } }}Inner Classも入り、何か複雑になったように見えますが、実際使ってみるとそうでもないです。このようなBuilderクラスを使うとどうなるのか、また確認してみましょう。public class Cafe{ public static void main(String[] args){ // オーダーを生成してBuilderを使う CoffeeOrder order_1 = new CoffeeOrder(); order_1.Builder().size("tall").hot(false).build(); CoffeeOrder order_2 = new CoffeeOrder().Builder() .size("grande") .hot(false) .addCream(true) .takeout(true) .build(); }}Setterと似たような使い方で、一回だけで複雑なオプションを全部処理できます。また、生成と同時にもオーダーを完成できます。Builderが戻り値として自分自身を使っていて、連続してメソッドを呼び出すことができるからです。これならいくら変数が増えても対応できますね！Lombokを使う以上のパターンはLombokを使うとアノテーションだけで設定できるらしいです。例えばコンストラクターは@NoArgsConstructorや@RequiredArgsConstructor、@AllArgsConstructorでできます。Java Beanなら@DataをつけることでGetterとSetterができるらしいですね。また、Builderの場合は@Builderでできると言います。以下はLombokを使った場合の例です。import lombok.Builder;@Builderpublic class CoffeeOrder{ private final String size; private final boolean hot; private final boolean addCream; private final boolean addSugar; private final boolean takeout;}ちなみに@Builder(toBuilder = true)にすると、インスタンスの新規生成ではCoffeOrder.builder()から直接Builderにアクセスできるようになります。また、既存のインスタンスの値を受け継ぐ場合はorder_1.toBuilder()を使えるようになります。実際は以下のコードになるようなものとなります。import lombok.Builder;@Builder(toBuilder = true)public class CoffeeOrder{ private final String size; private final boolean hot; private final boolean addCream; private final boolean addSugar; private final boolean takeout; // ... 基本的なBuilder public CoffeeOrderBuilder toBuilder() { return new CoffeeOrderBuilder().size(this.size).hot(this.hot).addCream(this.addCream) .addSugar(this.addSugar).takeout(this.takeout); }}そしてBuilderを使うとき、親クラスのフィールドをそのまま継承したい場合はフィールドに@Builder.Defaultをつけることでそのまま受け継がれます。他にもフィールドにつけてアクセスレベルを指定できるなど便利な機能が多いので、ぜひ使いたいものですね。最後にデザインパターンの種類に何があって、どんな構造をしているかを把握することも大事ですが、何より大事なことは適材適所に使えることではないかと思いました。最初から自分がBuilderパターンを知っていたとしても、それを使ったらいいと言われなかったら果たして使おうとしていただろうかと思うと、そうでもないような気がしますね。なのでこれからはデザインパターン自体の研究とともに、それをどの場合に使えるかという面から考察していきたいと思います。それでは、また会いましょう！引数の数や種類を変えることで、同名のメソッドを複数作成する記法。 ↩︎Object Oriented Programing.オブジェクト指向プログラミングとも言いますね。コードをひたすら上から下まで流れる処理として扱うのではなく(手続き型プログラミング)、隔離されたオブジェクト間のデータ交換として成立するプログラミングのパラダイムです。 ↩︎