バリデーション解体新書 2025/4/8に開催した #アーキ部 『バリデーション解体新書』の内容を編集したものです。 バリデーションとは何か? 広義には、 何らかの処理を実施するにあたって、入力データが想定する条件を満たすかを検証する行為 と言える。 この定義で、アプリケーションのどこでバリデーションをしているのかを考えると、以下のように各層にそれが見られる。 このように実装される場所が散らばるので、「バリデーション」や「入力チェック」を分類して開発ガイドラインを作ることが多い。 例えば、大規模Java開発向けのTERASOLUNA開発ガイドラインを見てみると、 ユーザーが入力した値が不正かどうかを検証することは必須である。 入力値の検証は大きく分けて、 1. 長さや形式など、文脈によらず入力値だけを見て、それが妥当かどうかを判定できる検証 2. システムの状態によって入力値が妥当かどうか

コードは Kotlin だけどよしなに読み替えてください。 前提 Excel は便利なのでこれを使ってまとめて書きたい。どかっと記述して CSV で取り込みたい。 とにかくフィールドが多い、可変かもしれない、増えるかもしれないし減るかもしれない。 やっていく jackson-dataformat-csv を使えばできる。 https://github.com/FasterXML/jackson-dataformats-text/tree/master/csv ドキュメントがかなりふわっとしていて難解だがやればできる。 import assertk.assert import assertk.assertions.isEqualTo import assertk.assertions.isNotNull import com.fasterxml.jackson.annotation.Json

はじめに JavaのORマッパーは何をお使いでしょうか？ 最近の僕は、以下の理由からSpringのJdbcTemplateクラスをよく使っています。 設定ファイル不要なので、簡単に利用開始できる！ SpringのDIコンテナが無い環境でも利用できる！ 内部でやっていることは単純であるため、ハマりにくい！ 環境 JDK 17 Spring JDBC 6.0 テスト用データベースにはH2を利用しました。しかしこの記事の内容は、一部を除いてRDBの種類に関係なく適用できるはずです。 インスタンス生成 JdbcTemplateのインスタンス生成は簡単です。コンストラクタの引数にDataSourceを渡すだけです。 DataSourceは、コネクションを取得する際の窓口となるインタフェースです。実装クラスとしてはHikariCPのHikariDataSource（コネクションプール機能付き）や、Sp

このSpring Bootを使ったクリーンアーキテクチャの例は、データの詰め替え過剰にみえる。 https://www.baeldung.com/spring-boot-clean-architecture これだけのモデルと詰め替えが必要なのだろうか? 『Get Your Hands Dirty on Clean Architecture 』にこのマッピング戦略(詰め替え戦略)が書かれている No Mapping (レイヤ間でモデルを共有し、詰め替えをしない) 2-way Mapping (各レイヤで独自のモデルを持ち、レイヤを跨ぐ呼び出しは上位レイヤが詰め替えの責務を負う) Full Mapping (各レイヤで独自のモデルを持ち、レイヤを跨ぐ呼び出しには専用のモデルを使う) またこの戦略のどれを選ぶかの基準は『Balancing Coupling in Software Design

Java デベロッパーの皆さんは IntelliJ IDEA や Eclipse を使ってる方が多いのではないでしょうか。筆者は VS Code を使っています。業務では長らく Java から離れていたのですが、ここ数年はけっこう書いています。かつては IntelliJ IDEA に課金してましたが Java 再開を機に VS Code の環境を整えました。この記事では、定番の拡張やワークスペースの使い方についてご紹介したいと思います。 結論から言うと 「Microsoft の Extension Pack for Java を入れましょう。」で終わりです。 Extension Pack for Java - Visual Studio Marketplace Extension Pack はその名の通り複数の拡張の集合体で、現状は6つの拡張がインストールされます。少しこの中身を見ていきま

こんばんは、GxP高田です。 これはグロースエクスパートナーズ Advent Calendar 2022のカレンダーの22日目の記事です。2が多めで縁起がいいですね。 サンタクロースも走り回る師走を忙しくお過ごしの皆様に、さっと読めて来年からと言わず明日から使える知識をお届けしたいと思います。 Javaアプリのコンテナベースイメージどれにする? アプリの実行環境として、Dockerに代表されるようなコンテナで実行されることがほとんどになってきました。 Javaを稼働させるためには、Java実行環境（Java Runtime Environment）が必要になるため、どうしてもコンテナイメージサイズが大きくなりがちです。どのイメージがいいのか、イメージサイズ、セキュリティ、メンテナンスが続くのか、などで大いにお悩みなのではないでしょうか。 JDK11から利用可能になったjlinkというツール

おなじみの画像 JavaやScalaといったJVM言語のDockerイメージは、JVMを同梱しなければならない都合で肥大化しがちである。特に何もしなくても、例えば一般的なamazoncorretto:21のイメージサイズは217.7 MBもある。 hub.docker.com これにさらにビルド済みのJARファイルが載ってくるので、結構大きくなってしまうのだ。 そこで、Scalaのコンテナイメージのサイズをなんとか小さくできないかと、考えた。すると、JVMを使ったまま70 MiBくらいに縮めることができた。 github.com コンテナイメージのサイズを小さくするために、何をしたかを書いていく。ちなみに題材としたアプリケーションはちょっとしたHello, Worldをするだけのもので、ライブラリはCatsに依存させた。 JVM使う編 マルチステージビルドを行う Alpineなどの軽量ラン

JJUG CCC 2023 Fall

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog LINE の Business Platform 開発担当フェローの Matsuno です。 今回は Spring Boot でアプリケーションを開発した場合のメトリクスの勘所についてご紹介しようと思います。 我々のチームでは Kotlin + Spring Boot での開発がデファクトスタンダードとなっているのですが、正直まだまだこのテクニカルスタックで開発しているエンジニアは日本では少ないのです。そこで、実際の運用の雰囲気を感じていただければと思いまして今回の記事を書くことにしました。 メトリクス取得の基本 我々のチームではメトリクスの格納先として Prometheus を利用しています。 Prometheus で格納し

概要 この記事ではBeanのライフサイクルについてまとめています。 割と内部のお話です。 以下のキーワードは知っている前提で進めます。 Bean DI(Dependency Injection) ちなみに先日pivotalが主催するSpring Professional v5.0 Examを受けたのでそのときに勉強した内容のまとめです。 Beanのライフサイクル Beanのライフサイクルは大きく3つに分かれます。 初期化フェーズ 利用フェーズ 終了フェーズ 初期化フェーズ このフェーズでは主に Bean定義読み込み・書き換え Bean生成&DI 初期化処理 を行います。 このフェーズが最も複雑です。 大まかな流れはこんな感じ では詳しく見ていきましょう。 Bean定義の読み込み まずBeanの生成に必要な情報の読み込みが行われます。 @Configurationの書かれたJava Conf

2018年6月26日2019年5月16日 mockitoについての全投稿は/tag/mockitoにあるので参照されたい Mockitoのスタブ化には二通りの書き方がある。以下のようなものだ。 import org.junit.*; import org.mockito.*; import static org.junit.Assert.*; import static org.mockito.Mockito.*; public class Sample { @Mock Login login; @Before public void before() { MockitoAnnotations.initMocks(this); } @Test public void test() { // こちらか doReturn(true).when(login).doit(anyString(),

開発部のにゃんです。主にバックエンドを弄っております。 Webアプリケーションではセキュリティ対策のためにランダムな文字列を使用する場面が多々あります。例えば CSRF対策のトークン OAuthやOpenID Connectで使用するnonce, state, code_verifier メールの到達確認用URLのトークン パスワードをhashする際に使用するsalt セッションID これらの値は単に衝突しなければOKというものではありません。十分なセキュリティ強度を確保するためには推測不可能なランダム値を使う必要があります。 以下は推測不可能なランダム値ではありません。セキュリティが求められる場面では使ってはいけません。 Math.randomなどの疑似乱数 日付やユーザ情報のハッシュ ではどのような値が適切なのでしょうか？ /dev/randomと/dev/urandom Linuxに

要約 技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。 たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端 ちょっと仕事でJava + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある

Java といえば JavaBeans 規約、すなわち getter/setter のウザさで有名ですが、古くは S2JDBC*1、近頃は JPA でも public フィールドが使えるようになったりして public なフィールドへの障壁が下がってきたのではないかと思います。とはいえまだまだ JavaBeans 規約に則っていることを前提にしたライブラリやフレームワークが数多くあります。例えば最近では JSF の EL 式から public フィールドを参照できなくて悲しい思いをしました。 そこで lombok ですよ lombok というライブラリがあります。 Project Lombok アノテーションを付与することで getter/setter や equals 、 hashCode といっためんどくさいコードをコンパイル時に自動生成してくれるというすぐれものです。この間 Java

Shaded jarとは Javaでのdependency-hellを回避するための方法の一つ。 元々のコードベースが、ライブラリAのバージョンXに依存しているとする。 このコードベースに新たなライブラリBを追加したい。 しかしながら、ライブラリBはライブラリAのバージョンYに依存しており、 ライブラリAのバージョンXとYは互換性がないという状況を考えよう。 CodeBase |- Library A, Version X |- Library B |- Library A, Version Y # Conflict!!! このままではライブラリAのバージョンX, Yのどちらを選んでも新規機能と既存機能の 両方を同時に動かすことはできない。 ここで登場するのがshaded-jarである。 Library AのバージョンYのクラスを全てLibrary Bに同梱してしまい、依存関係を排除したラ