Githubのリポジトリを読み取り専用にする

はじめに

Githubリポジトリを読み取り専用にする」でググっても知りたいことが出てこなかったのでメモ。

どんなキーワードでググると良かったのか?

GitHub リポジトリ アーカイブ」でググるべきでした。
このキーワードでググると以下のページがヒットして、読み取り専用にする方法が分かります。


help.github.com

プロジェクトでArchUnitを利用する際のガイドが公開された

はじめに

好きなコンテンツなのですが、階層がやや深く見つけづらいため自分用にメモ。

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

はじめに

私が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に対する関心が高まっているのですが、これが何ものなのかちょっとわかりにくいので、自分のためにもメモ。

何モノなのか

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

4. What to CheckUML*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に接続したら、うまく繋げなくて「??」ってなってました。
 1ヶ月後ぐらいに忘れていて、またやってしまいそうなのでメモ。

環境

  • 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:止めたコンテナを再開したときは、また別のログがでるのですが割愛します。