Server-side Kotlinプロジェクトのモノレポ化について発表しました - 株式会社ヘンリー エンジニアブログ
株式会社ヘンリーでSREなどをしている戸田（id:eller）です。先日「Hack@DELTA v24.06 モノレポは、令和のソフトウェア開発における銀の弾丸か？」にお招きいただき、弊社のモノレポ化事例について発表させていただきました。当日利用した資料とQ&AをSpeaker Deckで公開しております： speakerdeck.com 当技術ブログではこのモノレポ化について、2回に分けて解説しております。合わせて読んでいただけると理解が深まるかと思います。 dev.henry.jp dev.henry.jp 弊社ではサービスやサポートを通じて、お客様である医療機関様ならびに国家が抱える社会課題の解決に邁進したいと考えております。そのためにはモノレポをはじめとした生産性改善施策を継続的に行い、サービスの変化を加速していくことが大切です。 社会課題解決というスタートアップらしい働きに関心を
Server-Side Kotlinで書かれたCloud Runサービスのコールドスタートレイテンシを短縮する - 株式会社ヘンリー エンジニアブログ
株式会社ヘンリーでSREなどをしている戸田（id:eller）です。先日弊社のエンジニアが登壇したサーバーサイドKotlin LT大会 vol.11でSansan社の柳浦様がServer-Side KotlinアプリのCloud Run コールドスタートレイテンシを改善した話をされていました。 Server-Side Kotlin アプリのCloud Run コールドスタート レイテンシを改善した話 - Speaker Deck 本件はCloud Runを使ってServer-side Kotlinを運用している弊社でも関心が高い内容です。そこで弊社の事例も紹介させていただければと思います。 動機：コールドスタートレイテンシを改善すると何が嬉しいか Cloud Runはスケールアウト時に10秒までリクエストを滞留させます。そして10秒でインスタンスが用意できなかった場合は429エラーが発生す
JVM勉強会（開発編）を開催しました - 株式会社ヘンリー エンジニアブログ
こんにちは、SREの戸田です。本日はJVM勉強会（運用編）に続けて開催したJVM勉強会（開発編）の一部を公開します。 図1 勉強会はやっぱりGoogle Meetでオンライン開催しました システムプロパティ システムプロパティは環境変数のように、プログラムの挙動を変えるために利用することが多いです。例えばOpenJDKそのものでも Integer.valueOf() で値をどの程度キャッシュするか*1を設定するためにシステムプロパティを使っています。 他にも user.language あたりはよく知られていますし、標準で提供されるシステムプロパティも多数あります。しかし製品コードから直接参照することは基本ないと思っていて、 File.pathSeparator などの提供されたAPIを使うことが望ましいでしょう。またシステムプロパティは動的に変更することも可能ですが、システムプロパティを
JVM勉強会（運用編）を開催しました - 株式会社ヘンリー エンジニアブログ
こんにちは、SREの戸田です。本日は社内で開催したJVM勉強会（運用編）の一部を公開します。 JVM、使っていますか？弊社ではサーバサイドKotlinが活躍しているので、もちろん日常的にJVMが稼働しています。このためサービス運用の一貫で必要になる知識や関連ツールなどをSREないしプロダクトチームに共有することを目的として、この勉強会を開催しました。 図1 勉強会はGoogle Meetでオンライン開催しました パフォーマンス・チューニング サービスを開発していると、この処理をもっと高速化したい！ランニングコストを抑えてユーザ体験の向上に投資したい！というというシーンには多く遭遇しますよね。こうしたユーザが増えてサービスに負荷がかかるようになったことで生じた課題に対して迅速に打ち手が取れることは、とても重要です。 しかし焦ってはいけません。「このコードはめっちゃループしてるし遅そう！」「あ
Gradleのjvm-test-suiteプラグインがテスト周りの定型コードを排除するのに便利そう - Kengo's blog
Gradle v7.5の時点ではまだIncubating段階の機能ではあるのですが、Gradleの新しいプラグイン jvm-test-suite がいい感じなので紹介します。 docs.gradle.org 解きたい課題：サブモジュールや統合テストが出てくるととたんに面倒になるビルドスクリプト Gradleは設定をDSLで記述するので基本的には何でもありなのですが、やはり定形コード（boilerplate）は少ないほうがビルドスクリプトの見通しも良くなります。もちろんGradleは「設定より規約（Convention over Configuration）」の考えを持っているため、ある程度は空気を読んでSourceSetやTaskを自動的に生成してくれます。しかしテスト周りにおいてはこうした自動生成は十分ではなく、次に挙げるような課題がありました： サブプロジェクト全てに対して実行したタス
Server-side Kotlin合同勉強会を開催しました｜株式会社ヘンリー
ヘンリーでは継続的に社内勉強会を開催しています。今回会社の枠を飛び越えて、株式会社NewsPicksさんと合同勉強会を開催しました。 弊社からは2名のスピーカーが参加しました。ヘンリーのサーバサイドを見ている弊社の縣は、サーバサイドアーキテクチャの狙いと課題について発表しました。発表資料はこちらです： ドメインの特徴を踏まえてマイクロサービスを分割したことや、スキーマ駆動開発を志向するためにgRPCを採用したこと、実際に開発して見えてきた課題などを紹介しました。参加された方からもとても好評で、多くのエンジニアの興味を惹いたと感じられるコメントをいただきました： 質疑応答の部分も含めて、アーキテクチャー議論を楽しく拝聴させていただきました。 他社さんの事例を聞くのはめちゃくちゃ参考になります。フロントエンドでgRPCを使わないのかという質問に対してApollo-GraphQLがよく出来てるの
Gradle/Kotlinで開発する私的ベストプラクティス2022 - Kengo's blog
こちらのエントリーが素敵だなと思ったので、最近書いてるKotlinプロジェクトのベストプラクティスをまとめてみます。一部はJavaプロジェクトにおいても利用できるはずです。 zenn.dev 基本方針 参加障壁を下げる。OSSプロジェクトでもプロプライエタリ・ソフトウェアプロジェクトでも、新しい開発者が参加するコストを下げることには大きな意義がある。 環境差異を吸収する。javaにPATHが通ってさえいればOSに関係なくビルドが通るようにする。 プロジェクト固有ルールを作らない。Conventional CommitsやKeep a changelogなど、ひろく世に使われているルールを採用する。 Gradleを設定する Spotlessを使う コードのフォーマットはformatterに任せて人間は細かいことを考えない、というのが不特定多数が参加するソフトウェアプロジェクトのあるべき姿だと
Kotlin DSL を考慮した Gradle Plugin を記述するために必要だったこと - おでーぶでおでーぶ
とある Gradle Plugin を 2.0.0 に移行する際、v1 から Kotlin DSL を使っていた人の環境でちょっと問題が発生したというツイートを見たので、Kotlin DSL がどうやって DSL Marker なしに lambda で書けるようにしてるのかちょっと調べてみた。ここで記述している問題は 2.0.1 では修正されていて、また Kotlin DSL での移行ステップも README に追記しておきました。 github.com TL;DR 外に見せる境界で def を使うのは避けておいた方が無難 Kotlin DSL は拡張関数で delegate してて、見るべきメソッドが違うかもしれないから気をつけよう Kotlin と Gradle の言語仕様の違いに気をつけよう kotlin-dsl を apply して開発しないと Groovy と Kotlin DS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kotest | Kotest