ArchUnitの方がリフレクションAPIよりも利便性が高い理由

テスト ArchUnit

はじめに

私がArchUnitを理解するために公式ドキュメントを読んだ時のメモです。特にオチはないです。

ArchUnitの方がリフレクションAPIよりも利便性が高い理由

Why test your architecture? - ArchUnitの「Why use ArchUnit?」に、利便性が高い理由が載っています。
引用します。

ArchUnit provides simple predefined ways to test the typical standard cases, like package dependencies.
ArchUnitは、パッケージの依存関係など、typical standard cases(典型的な標準ケース)をテストするための簡単な定義済みの方法を提供します。

ここは「なるほどー」って感じですね。リフレクションAPIでテストを記述するより、typical standard casesについては、きっと簡潔で読みやすくなるのでしょう。

でも、続いて次の文章があります。

But it also is fully extensible, providing a convenient way to write custom rules where imported classes can be accessed similarly to using the Reflection API.
In fact, the imported structure provides a natural way to use the full power of the Reflection API for your tests.
ただし、完全に拡張可能で、インポートされたクラスにReflection APIを使用するのと同様にアクセスできるカスタムルールを記述する便利な方法を提供します。
実際、インポートされた構造は、テスト用にReflection APIのフルパワーを使用する自然な方法を提供します。

「typical standard casesをテストする方法提供しつつも、full power of the Reflection APIを使用する自然な方法も提供している…？　どういうAPIの構成になっているんだろう？？」と私は疑問に思いました。


この疑問はArchUnit User Guide - 5. Ideas and Concepts を読むと解消されました。

ArchUnit is divided into different layers, where the most important ones are the "Core" layer, the "Lang" layer and the "Library" layer. In short the Core layer deals with the basic infrastructure, i.e. how to import byte code into Java objects. The Lang layer contains the rule syntax to specify architecture rules in a succinct way. The Library layer contains more complex predefined rules, like a layered architecture with several layers.

441/5000
ArchUnitはさまざまなレイヤーに分割され、最も重要なレイヤーは「Core」レイヤー、「Lang」レイヤー、「Library」レイヤーです。 要するに、Coreレイヤーは基本的なインフラストラクチャ、つまりバイトコードをJavaオブジェクトにインポートする方法を扱います。 Langレイヤーには、簡潔な方法でアーキテクチャルールを指定するためのルール構文が含まれています。 Libraryレイヤーには、複数のレイヤーを持つレイヤードアーキテクチャのような、より複雑な定義済みルールが含まれています。

ArchUnitはレイヤ分けして構成されていると。なるほどです。

ArchUnitって何モノ？

テスト ArchUnit

はじめに

　内輪でArchUnitに対する関心が高まっているのですが、これが何ものなのかちょっとわかりにくいので、自分のためにもメモ。

何モノなのか

「アーキテクチャをテストするモノ」です*1。
ここでいうアーキテクチャは、パッケージ間やクラス間の依存関係を主に指しています。

4. What to CheckのUML*2で記載されているテスト内容が、主に想定しているターゲットです。
このようなものについて、リフレクションAPIを使ってテストするよりも短い記述でテストできます。

主に想定しているターゲット以外も、リフレクションでチェック出来るものであればテスト可能です。
ただし、主なターゲットをテストする時ほどテストコードは短くならないかもしれません。

*1:Why test your architecture? - ArchUnitに「Why test your architecture?」という見出しがあるので、察しがつきます

*2:コード例もみると混乱するので、まずはUMLのみ見ることをお勧めします

Docker ComposeでPostgreSQLとpgAdmin 4を起動したら接続時にしょうもない事でハマった

開発環境

はじめに

　Docker ComposeでPostgreSQLとpgAdmin 4を起動して、pgAdmin 4からPostgreSQLに接続したら、うまく繋げなくて「？？」ってなってました。
　１ヶ月後ぐらいに忘れていて、またやってしまいそうなのでメモ。

環境

  • docker-compose version 1.23.2
  • PostgreSQL 11.5
  • pgAdmin 4.13

どうやって起動したか？

何にハマったかの前に、どうやって起動したかを簡単に説明します。

以下の記事を参考にdocker-compose.ymlを参考を作成して起動しました。

何にハマったか

pgAdmin 4に接続情報を入れる際、接続先として127.0.0.1:5432を指定して「繋がらない…？」って困ってました。
127.0.0.1って、pgAdmin 4を起動しているコンテナを指しているから、繋がるはずがない。

繋げるためには、コンテナからみたホスト(環境によってことなるでしょうが、172.17.0.1とか)か、docker-compose.ymlで指定したサービス名(postgresqlとか)を指定する必要があります。

さいごに

気づいたときは、脱力しました…。

WebSphere Application Server traditionalをDockerで起動してみる

開発環境

はじめに

WebSphere Application Server traditionalを起動してみました。
所々苦労したのでメモ。

環境

  • Docker version 18.09.7

使う前に知っておくべきこと

そもそもWebSphere Application Server traditionalって？

IBM WebSphere Application Server Libertyではない方のWebSphere Application Serverを traditionalと呼びます*1。

WebSphere Application Server traditionalのDockerイメージの説明

以下に存在します。

ライセンス

ibmcom/websphere-traditionalの下部のリンクに説明があります。

使う際の注意点

起動にちょっと時間かかる

ibmcom/websphere-traditionalに記載のコマンドを実行しても、すぐは使えません。
起動に時間がかかります。dockerのログをみて出力が落ち着くまで待ちます。 手元で試したところ、以下のログがでたら起動しているようです。*2 

{"type":"was_message","host":"was","ibm_cellName":"DefaultCell01","ibm_nodeName":"DefaultNode01","ibm_serverName":"server1","ibm_sequence":"1569160254517_000000000011A","message":"CWPKI0037I: Expiration monitor reports the following information: \n**** Subject:  Expiration Monitor ****; \n\nHostname: was\nProfile UUID: AppSrv01-BASE-1389585a-6c06-4875-bab5-66f7452fd309\nProcess type: UnManagedProcess\n\nChecking for expired certificate and certificates in the 60 days threshold period.\n\nCWPKI0735I: All certificates were searched and no expiration issues were found.\n.","ibm_datetime":"2019-09-22T13:50:54.517+0000","ibm_messageId":"CWPKI0037I","ibm_threadId":"0000006e","module":"com.ibm.ws.crypto.config.WSNotifier","loglevel":"INFO"}
{"type":"was_message","host":"was","ibm_cellName":"DefaultCell01","ibm_nodeName":"DefaultNode01","ibm_serverName":"server1","ibm_sequence":"1569160254610_000000000011B","message":"ADMR0016I: User defaultWIMFileBasedRealm\/server:DefaultCell01_DefaultNode01_server1 modified document cells\/DefaultCell01\/security.xml.","ibm_datetime":"2019-09-22T13:50:54.610+0000","ibm_messageId":"ADMR0016I","ibm_threadId":"0000006e","module":"com.ibm.ws.management.repository.FileRepository","loglevel":"AUDIT"}
管理コンソールのURLはちゃんと ibmcom/websphere-traditionalに記載されているURLを叩く

以下のURLを叩きます。


「コンテキストパスなしでも何か出るだろー」とかおもって、https://localhost:9043/を叩いても何も出ません。

ibmcom/websphere-traditionalに記載されているポートだけ開けても、デプロイしたアプリにアクセスできない

ibmcom/websphere-traditionalには記載されていないですが、アプリには9043ではないポートを使用してアクセスします。
defaulthostにデプロイする場合、デフォルトでは9080を使用してアクセスします。

よって、実際のDockerコマンドは以下のような感じになります。

docker run --name test -h test -v $(pwd)/PASSWORD:/tmp/PASSWORD -p 9043:9043 -p 9443:9443 -p 9080:9080 -d ibmcom/websphere-traditional:9.0.5.0

WebSphere Application Server traditionalが使っているポート番号を調べたい場合は、以下が参考になります。

さいごに

普通にインストールするよりは格段に楽に起動まで出来ましたので、Dockerを使って起動するのおすすめです。

*1:IBM WebSphere Application Server (WAS) | 製品・ソリューション | エヌアイシー・パートナーズ株式会社

*2:止めたコンテナを再開したときは、また別のログがでるのですが割愛します。

Intellij IDEAとTomcatとコンソールの文字化け

開発環境

はじめに

すごくちょっとしたことなのだけど、5分以上はまったのでメモ。

環境

事象

Tomcatを起動した際に、IntelliJ IDEAのコンソールの表示が文字化けする。

解決方法

以下のファイルに「-Dfile.encoding=UTF-8」と追記する。

C:\Users\<ユーザ名>\.IntelliJIdea2019.2\config\idea64.exe.vmoptions

はまったこと

以下のファイル記載しても、設定は有効にならない。

C:\Program Files\JetBrains\IntelliJ IDEA 2019.2\bin\idea64.exe.vmoptions

おそらく、読み込まれるファイルに優先順位があるのでしょう。

2019年7月現在CentOS 6.4をEC2で新規に使おうとしたら意外と大変だった。

クラウド

はじめに

CentOS 6.4をEC2に新規インストールしたかったのですが、AWS Marketplaceに存在しませんでした。
そこで自分でAMIイメージを作ったのですが、苦労したのでメモ。

作業前に決めておくこと

HVM AMIs (GRUB)を作成するか、Paravirtual AMIs (PV-GRUB)を作成するか

両者の解説は、User Provided Kernels - Amazon Elastic Compute Cloud に記載されています。
主な違いは以下の通りです。

種類 作成したAMIを起動できるインスタンスタイプ AMI構築時のポイント
HVM AMIs (GRUB) 現行世代のインスタンスと旧世代のインスタンスタイプ(全部の旧世代で起動するかは不明)。 Partition Tableの設定が必要(parted等のコマンドで設定する)。
Paravirtual AMIs (PV-GRUB) t1等旧世代のインスタンスタイプのみ。*1 Partition Tableを設定しなくていい。
私は今回HVM AMIs (GRUB)を使うことにしました。

作業前に知っておくべきこと

ISOイメージからOSを(多分)起動できないという事実

結構調べたんですが、方法がさっぱり分からず。
私はISOイメージを使わずにセットアップしました。

どこのサイトでCentOS 6.4を配布しているのか

「何を当たり前な」と思うかと思いますが、古いディストリビューションはミラーサイトではもう配布していないことがあります。
日本のミラーでは、もう、CentOS 6.4は配布していませんでした。
私はhttp://vault.centos.org/から入手しました。

インストール方法を解説したサイト

種類 サイト
HVM AMIs (GRUB) EC2でCentOS6のEBS-Backed HVM方式 AMIをゼロから作る - Qiita
Paravirtual AMIs (PV-GRUB) EC2でCentOS6のEBS-Backed AMIをゼロから作る - SEEDS Creator's Blog *2

今回私は、EC2でCentOS6のEBS-Backed HVM方式 AMIをゼロから作る - Qiita のサイトを参考に作成しました。

インストール方法を解説したサイト(EC2でCentOS6のEBS-Backed HVM方式 AMIをゼロから作る - Qiita)に対する補足

前述のサイトを見ながら作業していく中で、気づいた点があったので、僭越なのは承知なのですがメモしていきます。

OSはCentOS 6.xでも良い

「作業用インスタンスを作成」ではAmazon Linux 64bitを使っていますが、私はCentOS 6.10にしました。
特別な根拠はないのですが、まあ、バージョンが近いOSの方で作業した方が良いかと思っての、験担ぎ的判断です。
ただし、途中で使うツールが時々インストールされていないので、適宜yum installでインストールする必要がありました。

「EBSのパーティション作成。フォーマット。マウント」のデバイスの名前(/dev/xvdf)について

当然なのですが、AWSコンソール上から/dev/sdf以外でマウントした場合は別の名前になります。
lsblk*3コマンドを使用して、自分の環境ではどういう名前になっているか確認してから作業します。

私が作業したインスタンスではlsblkは以下の結果になりました。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdb    202:16   0  30G  0 disk
└─xvdb1 202:17   0  30G  0 part

ですので、私の環境ではdev/xvdbを使用することになります。

「EBSのパーティション作成。フォーマット。マウント」のフォーマットで指定するデバイス名は末尾に1がついている方

ちゃんと記事を読めば失敗しないのですが、デバイス名は末尾に1がついている方を使用してください。
私の場合は以下の通りですね。

mkfs.ext4 /dev/xvdb1

うっかり、末尾に1がついてない方を指定してもコマンドは成功してしまうのですが、Partition Tableが変になってしまい、grubの設定ではまります。

間違った場合、parted -lで確認した際にloopというみたことないPartition Tableになります。
以下に間違った場合の例を示します。

# parted -l
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 8590MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  8590MB  8589MB  primary  ext4         boot


Model: Xen Virtual Block Device (xvd)
Disk /dev/xvdb: 32.2GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  32.2GB  32.2GB  ext4

インストール用の yum.conf を作成で前提としているrikenさんのmirrorが無い

http://vault.centos.org/のみでどうにかします。

鍵のダウンロード

cd /mnt
wget -O ../RPM-GPG-KEY-CentOS-6 http://vault.centos.org/6.4/os/x86_64/RPM-GPG-KEY-CentOS-6

repos.confの作成の内容は以下のようにします。

vi ../repos.conf

[ami-base]
name=CentOS-6 - Base
mirrorlist=file://${PWD}/../mirrorlist.centos
gpgcheck=1
gpgkey=file://${PWD}/../RPM-GPG-KEY-CentOS-6

[ami-updates]
name=CentOS-6 - Updates
mirrorlist=file://${PWD}/../mirrorlist.centos.updates
gpgcheck=1
gpgkey=file://${PWD}/../RPM-GPG-KEY-CentOS-6||<

repos.confから参照するmirrorlist.centosは以下のように作成します。

vi ../mirrorlist.centos

http://vault.centos.org/6.4/os/x86_64/

repos.confから参照するmirrorlist.centos.updatesは以下のように作成します。

vi ../mirrorlist.centos.updates

http://vault.centos.org/6.4/updates/x86_64/

あとは記事通りでＯＫ

うっかり手順を飛ばさないように気を付けて行いましょう。

さいごに

こうやって整理して書くと大半は参考記事通りなんですが、HVM AMIs (GRUB)とParavirtual AMIs (PV-GRUB)の違いをちゃんと理解しておらず、やたら時間が掛りました。
Paravirtual AMIs (PV-GRUB)の手順で途中までやって、「あれ。なんか使いたいインスタンスタイプで起動できない？？」となって、あーだこーだして時間を浪費する結果に。

*1:これが実は結構な制約で、東京リージョンの場合、GUIから選べるインスタンスがあんまり無いです。Linux AMI 仮想化タイプ - Amazon Elastic Compute Cloudに載っているものは選べてよさそうなんですが、実際に選べるのはもっと少ないという。

*2:明確にはParavirtual AMIs (PV-GRUB)と記載されていないのですが、「作成したEBSをAMI化する」のところでHVM AMIs (GRUB)作成時には選べないカーネルを選択しているので、区別がつきます。

*3:Linux で Amazon EBS ボリュームを使用できるようにする - Amazon Elastic Compute Cloud

mvn site:siteでやたらスタックトレースが出力される

Maven

はじめに

実用上問題ないのですが、mvn site:siteを実行するとスタックトレースがいっぱい出力されます。
無視して良いのか気になったので調べてみました。

環境

続きを読む