エキサイト株式会社メディア事業部エンジニアの佐々木です。弊社アドベントカレンダー5日目を担当させていただきます。メディア事業部では、SpringBootを用いて日々ソフトウェア開発を行っていますが、サービスが大きくなったり人が増えたりするとアーキテクチャが障害にならないまでも部分的に守られていないことが起こります。Javaの世界ではArchUnitというアーキテクチャをテストしてくれるものがあり、弊社での利用を紹介いたします。 www.archunit.org 前提 openjdk 21.0.1 2023-10-17 LTS OpenJDK Runtime Environment Corretto-21.0.1.12.1 (build 21.0.1+12-LTS) OpenJDK 64-Bit Server VM Corretto-21.0.1.12.1 (build 21.0.1+12-
エキサイト株式会社メディア事業部エンジニアの佐々木です。 メディア事業部では、最近JVMを利用した開発が増えてきており、プロジェクトやリポジトリごとにバージョンが変わったりが起きています。これをなるべく自動で切り替える方法をご紹介します。 前提 設定ファイルの作成 切替の確認 マシンインストールされていないJVMバージョンが指定されている場合 まとめ 最後に 前提 メディア事業部では、SDKMANを使用して、Javaをインストールしております。Windows/Mac/Linuxで統一したコマンドを使用できるので管理が楽です。 設定ファイルの作成 設定ファイルを作成します。 $ sdk env init コマンドを実行すると、下記ファイルが出来上がります。 # Enable auto-env through the sdkman_auto_env config # Add key=value
目的 Thymeleafでは、標準でいくつかのユーティリティ関数が用意されています。 ${#dates.format()} とか、${#strings.isEmpty()} とかとか。 このユーティリティ機能のことを、式ユーティリティオブジェクト とか言うらしいです。 (初めて知った・・・( ゚ ρ ゚ )ボー 便利ではあるんですが、意外と痒いところに手が届かなかったりするんですよね。 というわけなので、今回はそのユーティリティ機能を独自に作成してみましょう!ってお話です。 標準機能 例としていくつか紹介しておきますが、今回はよく使いそうなやつを抜粋しました。 ほかにもいろいろな処理があるので、詳しくは調べてみてください。 #strings ${#strings.isEmpty(string)}文字列がブランクorNullであるかを判定する${#strings.contains(stri
こんにちは、日本のテトリスプレイヤーの上位 1% に入る飯島です(デジタルイノベーションラボ所属)。 日付を扱う時によく使用される java.time.LocalDateTime ですが、意外と時差のことを気にせず使っている方も多いのではないのでしょうか。今回は LocalDateTime と時差周りの話、その他 java.time に含まれるクラスの話をしていきます。 LocalDateTime について LocalDateTime は時差情報を持っていません。 つまり、2020-11-24T12:00:00 を表す LocalDateTime があったとして、それがいったいどの地域に置ける時刻なのかは不明だということです。 日本における 11/24 12:00 はイギリスでは 11/24 3:00 なのに、LocalDateTime ではそれを表すことができません。 日本のシステムと海
5-10分枠のLTで登壇することはそれなりに重ねてきましたが、カンファレンスに登壇したことがなかったので思い切って登壇してきました。その登壇した自分語りですので、他の方の発表については特にこの記事では言及しません。 JJUG CCCとは 日本Javaユーザーグループ(JJUG)は、Java技術の向上・発展、開発者の支援を目的とした任意団体です。その団体が年に2回、春と秋に行うカンファレンスです。 ここ最近はコロナ禍だったので、オンラインでのカンファレンスが多かったのですが、今回はハイブリッドでの開催でした。現地参加・ビデオ参加・リモート参加を選べて、私はリモート参加していました。 発表内容 JJUGにセッション内容を提出したものを記載します。 タイトル: 例示!Spring Bootで作られたREST APIのテストコード 内容: 品質を高める。リグレッションの防止。リファクタリングを安全
はじめに こんにちは。ZOZO DevRelブロックの@wirohaです。3/23にJavaのオンラインイベント「ZOZO Tech Meetup〜Java活用事例紹介〜」を開催しました。ZOZOの開発において「Java」にフォーカスした技術選定や設計手法、設計時の考え方などを紹介するイベントです。 登壇内容まとめ 弊社から次の4名が登壇しました。 ZOZOTOWNの商品の閲覧を支えるJava(技術本部 ECプラットフォーム部 / 藤本 拓也) ZOZOTOWNのカート決済システムのリプレイス〜歩みとこれから〜(技術本部 カート決済部 / 高橋 和太郎) Spring Boot+Redis Cache 〜検索APIにキャッシュを導入、実装時の工夫や効果〜(技術本部 検索基盤部 / 佐藤 由弥) ZOZOTOWNの裏側に迫る!Javaで作られたBFFの開発事例を紹介(ZOZOTOWN開発本部
update-java-alternatives に Oracle java も追加する @[Ubuntu](http://www.ubuntu.com/) 16.04 LTS 最新の update-java-alternatives は javac 等を更新してくれないバグがあります。 一時的なものだと思われますが、ご注意ください。 [穀風: 最新版の update-java-alternatives は javac を更新してくれない](https://kokufu.blogspot.jp/2016/08/update-java-alternatives-javac.html) `update-java-alternatives` には `--install` のようなコマンドがないため、簡単に対象を追加することは出来ません一般的にはパッケージから入れた時に自動的に追加される。 ただ、
https://github.com/javaparser/javaparser javaparser は Java をパースして AST にしてくれるライブラリである。 この手のライブラリは数多あるのだが、ほとんどのものが Java 1.5 ぐらいでメンテナンスが止まっている。 実際このライブラリもメンテナンスが止まっていたのだが、Java 1.8 対応版とし開発が再開されたものだ。 このライブラリはパーサーライブラリであるから、文字列をパースして AST を構築してくれるというものになっている。 実際どのような AST が構築されるのかが気になるところなので、構築された AST をダンプできるツールを groovy で書いた。 #!/usr/bin/env groovy @Grab('com.github.javaparser:javaparser-core:2.1.0') impor
2024-06-30:6月の読書会の開催はキャンセルになりました。 2024-05-28:8月以降の開催日および場所を公開しました。 2024-05-27:読書会(基礎からのサーブレット/JSP 第5版)第4回議事録を掲載しました。 2024-04-30:読書会(基礎からのサーブレット/JSP 第5版)第3回議事録を掲載しました。 2024-04-18:7月以降の開催日および場所を公開しました。 日時:8月24日(土) 10:00~17:00 場所:川崎教育文化会館 第3会議室 募集要綱:定員24名 地図:https://www.city.kawasaki.jp/kawasaki/page/0000030630.html 最寄駅:川崎 電話: 住所: 費用:会場費として一人300円ご用意ください 書名:基礎からのサーブレット/JSP 第5版 著者:松浦 健一郎, 司ゆき 訳者: 出版社:S
そもそも、そのメソッドの作成者が近くにいない場合、こういった確認すら行えません。結局、あるメソッドを使うために、そのメソッドの実装を時間をかけて分析することになるため、複数人で開発していることが、逆に開発効率を悪化させてしまいます。つまり、簡単に言うと、 「仕様の明確でないメソッドを作るのは迷惑行為です!」 ドキュメンテーションコメントによって API 仕様が明確にされていれば、こういった無駄なやりとりがなくなるため、開発効率もコード品質も上がります。下記のグラフは、開発メンバの人数と、生産性の関係を表しています。 仕様の不明確な API が溢れているプロジェクトに新しい実装メンバを投入しても、開発効率はうまく上がっていきません。すべての API の仕様が明確になっていれば、不具合が見つかった場合でも、各メソッドが何を実現すべきかが分かるので、別の人が実装を引き継いで修正していくことが可能
Javaで作られたプログラムでは、環境変数JAVA_HOMEを要求するものがあります。Linuxの場合、標準で搭載されるGCCのGCJはバージョンが古い、互換性の問題で実質はSunのJDKをダウンロードしてインストールするのがほとんどでしたので、JAVA_HOMEはほぼ固定(/usr/java/latest等)でした。 しかし最近は、openjdkがLinuxに搭載されるようになり、CentOSも5.3からopenjdkが搭載されるようになって、SunのJDKとopenjdkのパスが違い、設定がちょっと面倒になりました。 そこで、javacコマンドのある場所からJAVA_HOMEを算出しようと思い立ちましたが、CentOSでは/usr/bin/javacがシンボリックリンクで/etc/alternatives/javacとなり、また/etc/alternatives/javacもシンボリッ
Linux / OS X $ git clone https://github.com/jenv/jenv.git ~/.jenv Mac OS X via Homebrew $ brew install jenv Bash $ echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.bash_profile $ echo 'eval "$(jenv init -)"' >> ~/.bash_profile Zsh $ echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.zshrc $ echo 'eval "$(jenv init -)"' >> ~/.zshrc Enable the export plugin $ eval "$(jenv init -)" $ jenv enable-plugin
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く