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

こんばんは、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

図1：データベースとJavaプログラミング言語のミスマッチ このギャップを埋め、Javaアプリケーションとデータベースのシームレスな接続を実現するために、私たちはさまざまなデザインパターンとアーキテクチャアプローチに依存している。これらのパターンはトランスレータとして機能し、インピーダンスのミスマッチの影響を軽減し、2つの世界を調和して動作させるのに役立つ。 これらのデザインパターンは、車輪の再発明ではない。これらは、アプリケーションとデータベースのパラダイム間のインピーダンスのミスマッチを緩和するのに有効であることが証明されている、確立されたソリューションである。Driverパターン、Mapperパターン、Active Recordパターン、Repositoryパターンなどがある。 Java Persistenceにおけるデータパターンのナビゲート このセクションでは、アプリケーション開

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のライフサイクルは大きく3つに分かれます。 1. 初期化フェーズ 2. 利用フェーズ 3. 終了フェーズ 初期化フェーズ このフェーズでは主に Bean定義読み込み・書き換え Bean生成&DI 初期化処理 を行います。 このフェーズが最も複雑です。 大まかな流れはこんな感じ では詳しく見ていきましょう。 Bean定義の読み込み まずBeanの生成に必要な情報の読み込みが行われます。 @Configurationの書かれたJava Config @

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に同梱してしまい、依存関係を排除したラ

はじめに SPEEDA PDT歴3ヶ月の相川です 今回はJavaを2年くらい書いていた私が、3ヶ月間で感じたKotlinの特徴を列挙していこうと思います はじめに Kotlinの特徴 型推論について データクラスについて nullable 検査例外の話 returnを明示的に書かなくても良い 拡張関数と拡張プロパティ 拡張関数 拡張プロパティ リスト操作の評価について coroutineの話 まとめ Kotlinの特徴 型推論 データクラス nullable 検査例外の話 returnを明示的に書かなくても良い 拡張関数 リスト操作の評価について kotlin corutine 型推論について Kotlinでは変数を定義する際に、varもしくはvalを使います その際に、型推論が採用されているおかげで、Javaのように型を宣言しなくても良くなります ただ、Java10から型推論は使えるよう

（この記事は 地平線に行く とのマルチポストです） Java でファイルを読み込む処理は、バージョンが上がるごとにどんどん簡単に書けるようになっていきました。 今回は、どれだけ簡単になっていったかを Java のバージョンごとにまとめて説明します。 なお、ここでは以下の処理を行うコードをもとにしています。 そこそこ大きいテキストファイルを一行ずつ読み込む 文字コードは UTF-8 Java 1.1, Java 1.2, Java 1.3 public static void main(String[] args) throws IOException { File file = new File(args[0]); BufferedReader reader = null; try { reader = new BufferedReader( new InputStreamReader(

Community and Standards Quarkus provides a cohesive, fun to use, full-stack framework by leveraging a growing list of over fifty best-of-breed libraries that you love and use. All wired on a standard backbone. Kube-Native The combination of Quarkus and Kubernetes provides an ideal environment for creating scalable, fast, and lightweight applications. Quarkus significantly increases developer produ

okazuki.hatenablog.com 基本的に上の記事の通りでいいんですが、複数の属性を同じプロパティにつけた場合に、一気にバリデーションが実行されてエラーメッセージがうざいことになってしまいます。例えば以下のようなBeanがあったとして。 package okazuki.validationEdu; import org.hibernate.validator.constraints.Length; import org.hibernate.validator.constraints.NotEmpty; public class Person { @NotEmpty(message = "なまえ入れてね") @Length(min = 1, max = 10, message = "1～10の間") private String name; public String getNa

Spring Bootでは(Spring Boot以外にもBean Validation使ってるやつ全部ですが)、Serializableクラスに対して 「org.hibernate.validator.constraints」や「javax.validation.constraints」を使って、 @NotEmptyや@Sizeといったようにアノテーションを使うだけでバリデーションを行うことができます。 入力値を見て、アノテーションの制約に違反していれば勝手にエラーを検知してくれるのですが、 (処理を途中で止めたりエラー内容を画面に表示させるのは手動でやらなければいけません。) 1つのフィールドに対して複数のアノテーションを付与した場合はすべてのエラーチェックが走り、 エラーメッセージも複数出力される可能性があります。 例えば、以下のようなコードがあった場合、 @NotEmpty @Si