これは、なにをしたくて書いたもの？ そういえば、Jakarta EE（Java EE）でCORSの設定をしたことがないなと思いまして。 実装方法はいろいろあると思うのですが、すでに用意されているものとかないのかなと思って少し見ていたら、RESTEasyにあったので 軽く試してみることにしました。 RESTEasyのCorsFilter CORS（オリジン間リソース共有）および使用するヘッダーについては、MDNを参照ということで。 オリジン間リソース共有 (CORS) - HTTP | MDN RESTEasyが提供するCorsFilterについてのドキュメントはこちらです。 Chapter 32. CORS ほぼ内容がありませんが。設定内容についてはJavadocを見てね、という感じです。 CorsFilter (RESTEasy 6.2.8.Final API) 設定をしたら、Appli

列挙型、JavaでいうならEnum型、使っていますか。使わないわけにいきませんよね。 でも、Enumを使っていたせいで辛い目にあったことありませんか。ないですか。それならきっともうすぐに辛い目にあうと思います。 Enumはすべてのプログラマに等しく辛みを与えてくれるからです。そんな辛みについて、ちょっと一緒に直視してみましょう。 エムスリーエンジニアリンググループ、Unit1（製薬企業向けプラットフォームチーム）三浦(@yuba@reax.work) [記事一覧 ]がお送りいたします、エムスリー Advent Calendar 2023の6日目です。 アプリケーションプログラミング上の辛み 1. 既存のif文が偶発的に意図しない方に倒れる 2. switch文に至っては「どちらでもない」で処理不発に アプリケーションプログラミング上の対策 1. 分岐条件をEnumに持たせる 2. swi

こんにちは。フロントエンドエンジニアの渡邉です。 普段はReactとTypeScriptを書いています。 今回は自分がコンポーネントを実装する際に意識していることについていくつか紹介できればなとおもいます。 ※ スタイリングに関して話すときはstyled-componentsを使用しています。 目次 はじめに 再利用性の高いコンポーネントを実装するために意識していること 共通のコンポーネントを作成する際は汎用性を意識する コンポーネントが知らなくてもいい情報を持たない(コンポーネント・構成編) コンポーネントが知らなくていい情報をもたない(コンポーネント・スタイル編) 無駄な描画を減らすために意識していること 状態に関係ないコンポーネントを混ぜない さいごに はじめに 今まで自分がReactを書いてきて、再利用性が低いコンポーネントを実装してしまったり、コンポーネントの設計自体が無駄な再描

Lombokのコンストラクタ生成に関する以下アノテーションの利用サンプルです。 @NoArgsConstructor(lombok.NoArgsConstructor) @AllArgsConstructor(lombok.AllArgsConstructor) @RequiredArgsConstructor(lombok.RequiredArgsConstructor) デフォルトコンストラクタを生成する @NoArgsConstructorをクラスに付与することでデフォルトコンストラクタを自動生成することができます。 ■@NoArgsConstructorを付与したクラス import lombok.NoArgsConstructor; @NoArgsConstructor public class Person1 { private long id; private String

ソフトウェアアーキテクチャには、依存関係のデザインという側面がある。その目的は多くの場合において、ソフトウェアの振る舞いに対する変更容易性を高めることではないだろうか。 ソフトウェアプロダクトは、そのライフサイクルを通して、繰り返し変更し続けられていく宿命にある。それがユーザーや顧客の要求であり、彼らの価値につながるからだ。そしてその提供には迅速さも求められる。依存関係のデザインは、これを実現するために組み込まれたソフトウェアの構造なのだ。 アーキテクトの悩みのひとつは、このような目的に基づいて自らがデザインしたソフトウェアの構造が、儚く崩れ去っていくことだ。アーキテクチャとは所詮はルールでしかない。開発チームが厳密にルールを守らない限り、望ましい構造を構築・維持することはできない。アーキテクチャは脆いのだ。それこそが技術的負債の一因でもある。 無償のJavaライブラリとして提供されている

spring-bootで作成するweb-apiのintegration test（以下IT）を記述するのにWebTestClientが使える。これは内部的にWebClientを使用する。同様にTestRestTemplateは内部的にRestTemplateを使用する。環境に応じて使い分けになる。今回はWebTestClientによるITの記述について。 ドキュメントは WebTestClient :: Spring Docsにあり、ここ読めばだいたいは困らないと思う。 ソースコード build.gradle plugins { id 'org.springframework.boot' version '2.6.7' id 'io.spring.dependency-management' version '1.0.11.RELEASE' id 'java' } group = 'com

Javaのジェネリクスの話題のひとつにnew T()したいができないので困る、というテーマがある。 先日のセッションではこの対策についても簡単に述べたが今日はそのまとめ。 まず第一に疑うべきは本当にnew T()する必然性があるか？というのが持論だが、ある種のフレームワークではその必然性がある。 O/RマッピングのフレームワークでPOJOにデータを詰めて返したい WebフレームワークでHTTPリクエストをPOJOに詰めてControllerクラスに渡したい （このあたりの議論はJavaのジェネリクスで，T.class や new T() ができず悩んだ話 （型パラメータのインスタンス化に関し、フレームワーク設計からケーススタディ） - 主に言語とシステム開発に関してによくまとまっている） ここで、これらのPOJO(Plain Old Java Object - 端的に言えばデータを格納する

MyBatisでネストしたオブジェクトマッピングするサンプルあんまり見かけないので、残しておく。 例えばこんなデータを person id name address_id 1 yamada 11 2 sato 11 address id city 11 tokyo book id title 21 hoge 22 fuga 23 piyo person_book person_id book_id 1 21 1 22 2 23 こんなオブジェクトにマッピングしたい時。。 public class Person { private Address address; private List<Book> books; // アクセサは省略 } こんな感じになる <mapper> <resultMap id="personMap" type="Person"> <id column="perso

キャスト null 除外 否定フィルタ Streamから配列へ 配列からStreamへ リストの集約 リストからマップへ変換 コレクションの変更 任意キーでグルーピング 任意キーでソート カンマ区切り プリミティブRangeからリストへ オブジェクト型の合計 BigDecimal の合計 グルーピングして集計 グルーピングしてカウント 最大値/最小値の抽出 Optional から値の取り出し 開発の現場でよく使う Java Stream イディオムです。 キャスト List<String> studentNames = people.stream() .filter(Student.class::isInstance) .map(Student.class::cast) .map(Student::getName) .collect(Collectors.toList()); null 除

これは、なにをしたくて書いたもの？ Javaで文字数を数える時に、String#lengthではサロゲートペアがうまく数えられないことは有名だと思うのですが。 Unicode - Wikipedia 結合文字というものを踏まえた数え方をちゃんと知らなかったので、今回見てみることにしました。 タイトルは、確認したバージョンがJava 11なだけです。 注）BreakIteratorではうまく数えられない絵文字があるので、その場合はJava 17へ Java 17で文字を数える - CLOVER🍀 BreakIterator 結合文字は、基底文字と組み合わせて文字を作ることができる文字のことを言います。 Unicodeにおける、異体字セレクタも該当します。 異体字セレクタ - Wikipedia 異体字セレクタは、このサイトで確認するのがよさそうですね。 異体字セレクタセレクタ 異体字セレク

これは、なにをしたくて書いたもの？ 前にWildFlyとArquillianを使ったエントリを書いたのですが。 WildFly 25＋Arquillian＋JUnit 5でインテグレーションテスト（Managed／Remote／Bootable JAR） - CLOVER🍀 Codehaus Cargoを使ったインテグレーションテストもやってみたいなと思い、試してみることにしました。 Codehaus Cargo - Home Codehaus Cargo - Maven 3 Plugin Arquillianとの直接の比較にはならないとは思いますが。目的や機能が違うので。 Codehaus Cargo Codehaus Cargoは、Java EE／Jakarta EEのアプリケーションサーバーをAPIで操作する機能を提供します。 Codehaus Cargo - Home アプリケー

コードで学ぶドメイン駆動設計入門 〜エンティティとバリューオブジェクト編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜振る舞いとサービス編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜ファクトリ編〜 - じゅんいち☆かとうの技術日誌 引き続き連投エントリ。私も来年で39歳になります。そして息子が7歳。いいおやじですが、脳は衰えないと言われています。鍛えれば鍛えたほど進化できると信じます。 ということで、リポジトリ編に入ります。 リポジトリ リポジトリは、ライフサイクルの途中から最後にフォーカスし、オブジェクトの永続化と永続化されたそのオブジェクトを検索する手段を提供するオブジェクトです。このように説明すると、DAOに近い印象を持つかもしれませんが、DAOはRDBMSやSQLなどのインフラストラクチャ層の関心事を含んでいるので、ここでは

１年半ほど前にブログで、ViewExpiredExceptionに苦しんだ記録をまとめましたが、再度、似たようなトラブルに直面してしまいました。 タイトルがその原因だったわけですが、この問題についてもまとめておこうと思います。 STATE_SAVING_METHODについて JavaEE7のWebアプリケーションでは、STATE_SAVING_METHODの設定で、クライアントごとのView情報をどこで保管するかを管理します。 デフォルトでは、serverになっており、Viewの数も15と少な目に設定されています。（下記の設定は、定義しなくてもデフォルトで反映されます） <context-param> <param-name>javax.faces.STATE_SAVING_METHOD</param-name> <param-value>sever</param-value> </con

基本がきちんとわかっておらず、不具合を発生させてしまったケースとして、恥を承知で記録しておきます。 トラブル内容 リリースしたアプリケーションが、ここ数日間、やたらと「ViewExpiredException」が多発しまくるようになってしまいました。 ソフトウェアは、JavaEE7（glassfish4.1）、JSF2.2＋Primefaces5.1です。 発生している画面は、ログイン画面や複数の入力画面で、一定ではありません。 時間帯もまばら。う～ん、これには参りました。 原因発見 サイトをいろいろと確認していると、JavaEE Server の「STATE_SAVING_METHOD」が「server」の設定の場合、そのデフォルトのview情報保持数が15であるらしいということを発見。 jsf 2 - How and when is a view scope bean destroye

2.2ではカスタムコンポーネントをすぐに作成、実装することができる。 XMLとかなにもいらない。 やっと来たかーって感じ。 カスタムコンポーネントのコード。 package jsf; import java.io.IOException; import javax.faces.component.FacesComponent; import javax.faces.component.UIComponentBase; import javax.faces.context.FacesContext; import javax.faces.context.ResponseWriter; @FacesComponent(value = "custom.aoi_blink" ,tagName = "aoi_blink" , createTag = true) public class Blink

jBatchとは？ Java EE 7から新たに加わった、バッチ処理用フレームワークの仕様です。 EE 6までは、Java EE標準仕様にバッチは入っていなかったのですが、EE 7から加わりました。 正式名称は「Batch Application for the Java Platform」で、公式？の略称が「jBatch」です。 Spring Frameworkには、以前から「Spring Batch」というものがあったのですが、これを基にjBatchの仕様が策定されたようです。 また、Spring Batch自身も、jBatch準拠になっているようです。 jBatchの実装 jBatchに限らず、Java EEは仕様のみ（ほとんどインターフェイス・アノテーション・例外・enum）なので、jBatchを使うためには、それに対応する「実装」が必要です。 僕が調べた限りでは、今のところ実装は

データベースのパフォーマンスチューニングで、SQLのチューニング(インデックスの設定含む)は一番効果が大きい。 それでいて、SQLのチューニングはポータビリティが高い。メモリの設定、ディスクの設定、パラメータの設定はデータベースごとにまったく異なる(基礎的な考え方は同じではあるけれども)。それに比べると、SQLのチューニングはどのデータベースでも同じようなもの(Oracleのヒント句を使ったチューニングなんかは独特だと思うけど) で、SQLのチューニングを行う上で、重要なのが実行計画。だいたいどのデータベースも実行計画を確認するためのExplainコマンドが用意されている。H2にもある。 まず、以下のようなテーブルを作る。担当者、商品、売り上げ。 create table staff (id int not null primary key, lname varchar, fname va

H2の組み込みモードで単体テスト 単体テストとか、結合テストとかでテストスイート起動時にデータベースを起動して、終了時にデータベースをシャットダウンする例です。 @RunWith(Suite.class) @SuiteClasses( { ProductDaoImplTest.class, ProductServiceImplTest.class }) public class AllTests { private static org.h2.tools.Server server; @BeforeClass public static void beforeClass() throws Exception { Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override public void run