Jhipster Development和訳 

# はじめに(注意点）
全体的にかなり意訳です。
自分の理解用に作っています。他の方の参考に少しでもなれば。

# Profiles
原文:https://www.jhipster.tech/profiles/

JHipsterは２つのSpringProfileを使用します。

- `dev` ・・・開発環境用
- `prod` ・・・本番環境用

これらのprofileには２つの異なる構成がある:

- Maven/Gradle profileはビルドのタイミングで使用する。 例えば`./mvnw -Pprod package`または`./gradlew bootWar -Pprod`は本番環境用にパッケージングする
- Spring Profileは実行に利用されます。いくつかのSpring Beanはprofileによって動作が異なります。

Spring ProfileはMaven/Gradleにより設定される。それによりMaven/GradleとSpring間でもそれが一貫性を持って設定されます。`prod` profileは、Maven/GradleとSpringとで同時に利用できます。
注意: Spring ProfileはJHipSter application propertiesで利用されるので[common application properties documentation.
](https://www.jhipster.tech/common-application-properties/)にも目を通してください。

## By default, JHipster will use the dev profile
Maven/Gradleを使用せずにApplicationクラスを実行した場合
Mavenを使っており、MavenWrapperを実行（`./mvnw`）または`mvn`を使用した場合
Gradleを使っており、GradleWrapperを実行（`./gradlew`）または`gradle`を使用した場合

Angular2を使用しており、`dev`profileでwebpackのコンパイルした内容に置き換えたい場合は以下のように`webpack`パラメータを追加してください
`./mvnw -Pdev,webpack` or `./gradlew -Pdev -Pwebpack`

## In production, JHipster has to run with the prod profile
## Spring profiles switches
# Common application properties
https://www.jhipster.tech/common-application-properties/

# Common ports
https://www.jhipster.tech/common-ports/

# Separating the front-end and the API server
https://www.jhipster.tech/separating-front-end-and-api/
## Introduction
## Generating only a front-end or a back-end application
## Directory layout
JhipsterはMavenの標準ディレクトリ構造を採用しています。
バックエンドの作業をするときは[こちら](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html)Mavenの標準レイアウトを参考に。
フロントエンドで作業する場合は、２つのディレクトリがあることを理解する必要があります

- `src/main/webapp` は開発中のフロントエンドアプリケーションを配置する場所
- `target/www`はビルドされパッケージングされたアプリケーションが配置される場所

もし、フロントエンドとバックエンドが別々のチームで作業する場合２つの解決策があります。

- ディレクトリが分かれているので両方のチームが同じプロジェクトで作業可能。役割をはっきりさせるために、両チームは別々のbranchで作業できる。
- フロントエンドを別のgitプロジェクトし、バックエンドプロジェクトにgitサブモジュールとしてインポートする。クライアント側のビルドスクリプトを移動する必要あるが、シンプルにリファクタリングができる。

## HTTP requests routing and caching
フロントエンドとバックエンドを分離させた場合HTTPリクエストをどうハンドリングするかが課題となります。

- 全てのAPIは`/api`プレフィックスを付けてリクエストされる。これはangularを使う場合だと、`webpack.common.js`の設定で`SERVER_API_URL`で既に定義することにより自動で付与される。例えば、`http://api.jhipster.tech:8081/`のようにバックエンドAPIサーバーのURLとすることができます。(apiをドメイン部に付与するつもりであれば、まずはCORSのドキュメントを読んでから検討してください。)
- `/`をコールした場合はブラウザにキャッシュする必要のない静的コンテンツが提供される
- `/app`(クライアントサイドアプリケーション）と/content(cssや画像などの静的コンテンツ) をコールした場合、本番環境ではキャッシュすべきこれらのコンテンツはハッシュ化され、提供される


## Using BrowserSync
Jhipsterでは`dev`モードの場合フロントエンドアプリケーションのhot-reloadのためにBrowserSyncを使う。
BrowserSyncはプロキシ機能([ドキュメント](https://www.browsersync.io/docs/options#option-proxy))があり、
バックエンドへの`/api`へのリクエストをルーティングしてくれる（デフォルトの設定は`http://127.0.0.1:8080`)

これは`dev`モードだけの機能だが、フロントエンドから別のAPIサーバーにリクエストを送る際に非常に有用です。

## Using CORS
CORS([https://wikipedia.org/wiki/Cross-origin_resource_sharing]) はproxyなしで
フロントエンドから別のバックエンドサーバにアクセスを許可するものです。
これはとても簡単ではあるが、本番環境では安全性が低くなる可能性があります。

JHipsterはCORSがすぐに使えるようにする設定がある

- CORSはapplication.ymlに`jhipster.cors`の名で定義される([参考](https://www.jhipster.tech/common-application-properties/))
- これはデフォルトではモノリシックとゲートウェイアプリケーションの場合、`dev`モード時に有効になり、ゲートウェイを通してアクセスするマイクロサービスでは無効になる
- セキュリティ上の理由からこれは`prod`モードでは無効になる

## Using NGinx
フロントエンドとバックエンドのコードを分けるための別の案としてプロキシサーバーを使います。
これは本番環境ではとてもよく使う手法で、一部のチームはこのテクニックを開発でも使用しています。
この設定方法は特定のユースケースに応じて変わるため、Jhipsterのgeneratorでは自動生成できません。
以下にdocker-composeファイルでの設定方法を示します。`src/main/docker/nginx.yml`として作成してください

```yaml:nginx.yml
version: '2'
services:
  nginx:
    image: nginx:1.13-alpine
    volumes:
    - ./../../../target/www:/usr/share/nginx/html
    - ./nginx/site.conf:/etc/nginx/conf.d/default.conf
    ports:
    - "8000:80"
```

このDockerイメージは`target/www`からJHipsterがデフォルトの設定で生成するフロントエンドアプリケーションの静的コンテンツを読み込みます。
また、Nginxの設定ファイル`./nginx/site.conf`も読み込みます。
以下にサンプルを示します。

```
server {
    listen 80;
    index index.html;
    server_name localhost;
    error_log  /var/log/nginx/error.log;

    location / {
        root /usr/share/nginx/html;
    }
    location /api {
        proxy_pass http://api.jhipster.tech:8081/api;
    }
    location /management {
        proxy_pass http://api.jhipster.tech:8081/management;
    }
    location /v2 {
       proxy_pass http://api.jhipster.tech:8081/v2;
    }
    location /swagger-ui {
        proxy_pass http://api.jhipster.tech:8081/swagger-ui;
    }
    location /swagger-resources {
        proxy_pass http://api.jhipster.tech:8081/swagger-resources;
    }
}
```

上記設定の意味は

- Nginxをポート80で動作
- 静的assetのフォルダを`/usr/share/nginx/html`に指定
- `/api`を`http://api.jhipster.tech:8081/api`へリクエストするプロキシサーバー設定

この設定は必要に応じて変える必要はあるものの、多くのアプリケーションのスタート時はこれで十分でしょう。


# Managing server errors
https://www.jhipster.tech/managing-server-errors/

# Using Angular
https://www.jhipster.tech/using-angular/

## Tooling
AngularはJavascriptの代わりにTypeScriptを使用しています。
その結果として、効率的に作業するためには特定のツールが必要です。
我々のAngular2アプリケーション開発フローを以下に示します。好みによって`npm`を`yarn`に読み替えてください。

1. アプリケーションの新規作成時におけるファイルの自動生成のタイミングの最後に`npm install`タスクが実行される
2. `npm install`が完了したら`package.json`の`postInstall`が実行される。このタスクの中で`webpack:build`がトリガーされる
3. この段階でコンパイルされたすべてのファイルが`www`フォルダ内の`target`または`build`フォルダに生成されており、ここをビルドツール(MavenまたはGradle)が参照しています
4. `./mvnw`または`./gradlew`でアプリケーションサーバを起動することによりlocalhost:8080で上記ステップでコンパイルされたクライアントサイドのコンテンツを配信できるようになる
5. 別のターミナルを開き、`npm start`または`yarn start`を実行することにより、BrowserSyncのWebpack dev-serverが起動する これにより自動的にTypeScriptコードをコンパイルし、ブラウザをリロードしてくれる

もし`npm start`または`yarn start`実行をせずにクライアントサイドのコードを変更してしまった場合、コンパイルはされず、変更も反映されません
その場合は手動で`npm run webpack:build`を実行するか、`npm start`または`yarn start`を実行して何か変更を行ってください。

またmavenやgradleに`webpack`プロファイルを設定することで`webpack:dev`タスクを実行することもできます
例）`./mvnw -Pdev,webpack` or `./gradlew -Pdev -Pwebpack`
これはgradleやmavenの`clean`タスクを実行した後に特に役立ちます。

他の実行可能なnpm/yarnコマンドも`package.json`の中の`scripts`セクションに記載されています。

- ブラウザ上でコードを動作させるために、我々は[Angular Augury](https://augury.angular.io/)をお薦めします。これによりルーティングやコードのデバックが簡単になります。

## Project Structure

JHipsterのクライアントコードは`src/main/webapp`配下にあります。
構成は[John Papa Angular 2 style guide](https://github.com/johnpapa/angular-styleguide/blob/master/a2/README.md)に従っています
もし我々のアプリケーション構成、ファイル名、TypeScriptルールに質問等があれば、まずはガイドを読んでみてください。

このガイドはAngularチームに支持され、全てのAngularプロジェクトが使うべきベストプラクティスです
AngularのルーティングではURLを一貫性を保つためにダッシュケースの命名規則を使用します。
entityを生成する際、ルーティングURLとREST APIエンドポイントURLはこの規則にしたがって生成され、
entity名は必要に応じて自動的に複数形にされます

以下がプロジェクトのメインの構成です。

```
webapp
├── app                               - Your application
│   ├── account                       - User account management UI
│   ├── admin                         - Administration UI
│   ├── blocks                        - Common building blocks like configuration and interceptors
│   ├── entities                      - Generated entities (more information below)
│   ├── home                          - Home page
│   ├── layouts                       - Common page layouts like navigation bar and error pages
│   ├── shared                        - Common services like authentication and internationalization
│   ├── app.main.ts                   - Main application class
│   ├── app.module.ts                 - Application modules configuration
│   ├── app.route.ts                  - Main application router
├── content                           - Static content
│   ├── css                           - CSS stylesheets
│   ├── images                        - Images
├── i18n                              - Translation files
├── scss                              - Sass style sheet files will be here if you choose the option
├── swagger-ui                        - Swagger UI front-end
├── 404.html                          - 404 page
├── favicon.ico                       - Fav icon
├── index.html                        - Index page
├── robots.txt                        - Configuration for bots and Web crawlers
```

[entity sub-generator](https://www.jhipster.tech/creating-an-entity/)を使用し、新しいFoo entityを生成した場合の
結果(`src/main/webapp`配下)が以下です。

```
webapp
├── app
│   ├── entities
│       ├── foo                                    - CRUD front-end for the Foo entity
│           ├── foo.component.html                 - HTML view for the list page
│           ├── foo.component.ts                   - Controller for the list page
│           ├── foo.model.ts                       - Model representing the Foo entity
│           ├── foo.module.ts                      - Angular module for the Foo entity
│           ├── foo.route.ts                       - Angular Router configuration
│           ├── foo.service.ts                     - Service which access the Foo REST resource
│           ├── foo-delete-dialog.component.html   - HTML view for deleting a Foo
│           ├── foo-delete-dialog.component.ts     - Controller for deleting a Foo
│           ├── foo-detail.component.html          - HTML view for displaying a Foo
│           ├── foo-detail.component.ts            - Controller or displaying a Foo
│           ├── foo-dialog.component.html          - HTML view for editing a Foo
│           ├── foo-dialog.component.ts            - Controller for editing a Foo
│           ├── foo-popup.service.ts               - Service for handling the create/update dialog pop-up
│           ├── index.ts                           - Barrel for exporting everything
├── i18n                                           - Translation files
│   ├── en                                         - English translations
│   │   ├── foo.json                               - English translation of Foo name, fields, ...
│   ├── fr                                         - French translations
│   │   ├── foo.json                               - French translation of Foo name, fields, ...
```

## Authorizations

JHipsterはAngular routerを用いてクライアントアプリケーションの各コンポーネントを構成しています。
各stateについて、必要な権限がstateのデータにリストされ、リストが空の場合は誰でもアクセス可能であることを意味します。
権限はサーバーサイドの`AuthoritiesConstants.java`でも定義され、クライアントとサーバーサイドのロジックは同じでなければなりません
以下の例では、'session' stateが `ROLE_USER`権限をもつユーザーのみアクセス可能となるように設計されたコードです

```
export const sessionsRoute: Route = {
    path: 'sessions',
    component: SessionsComponent,
    data: {
        authorities: ['ROLE_USER'],
        pageTitle: 'global.menu.account.sessions'
    },
    canActivate: [UserRouteAccessService]
};
```

これらの権限がルーターに定義されると、２つの引数のタイプに基づき、`jhiHasAnyAuthority`ディレクティブを使用することができます。

- string単体の場合、引数の権限を持ったユーザーにのみHTMLコンポーネントが表示される
- string配列の場合、配列に定義された権限の内、一つでももっているユーザーにのみHTMLコンポーネントが表示される

例えば、以下のテキストは`ROLE_ADMIN`を持ったユーザーにのみ表示されます

```
<h1 *jhiHasAnyAuthority="'ROLE_ADMIN'">Hello, admin user</h1>
```

また、以下の例では`ROLE_ADMIN`または`ROKE_USER`権限を持ったユーザーにのみ表示されます。

```
<h1 *jhiHasAnyAuthority="['ROLE_ADMIN', 'ROLE_USER']">Hello, dear user</h1>
```

注意：これらのディレクティブはクライアントサイドでHTMLの表示、非表示を切り替えるだけです。
サーバーサイドでもコードをセキュアに保つ必要があります。

## The ng-jhipster library

ng-jhipsterはOSSで誰でも利用可能です (https://github.com/jhipster/ng-jhipster)
ng-jhipsterには下記のようなAngular2用の共通componentやutilが含まれています。

- Validation directives
- Internationalization components
- Commonly-used pipes like capitalization, ordering and word truncation
- Base64, date and pagination handling services
- A notification system (see below)


### Notification System
Jhipsterではサーバーサイドからクライアントサイドへイベントを送信し、生成されたアプリケーション全体で使用できる国際化対応された独自の通知システムを使用します。(`JhiAlertComponsent`と`JhiAlertErrorComponent`)
デフォルトではHTTP responseでエラーを検知した際にエラーメッセージを表示するのに使用されている
通知やアラートを表示するためには、`AlertService`をcontroller, directive, serviceにInjectした後に以下のように`success`, `info`, `warning`, または`error`を指定してください。タイムアウトのデフォルト値は5秒で、これは設定可能です。

```
this.alerts.push(
    this.alertService.addAlert(
        {
            type: 'danger',
            msg: 'you should not have pressed this button!',
            timeout: 5000,
            toast: false,
            scoped: true
        },
        this.alerts
    )
);
```

### Using Angular CLI

**注意：AngularCLIとJHipsterへ並行して使うことができ、それぞれが独自の設定ファイルを持っています。JHipsterはデフォルトでアプリケーションをデプロイする際やCI-CDサブジェネレーターを使用する際に自分の設定ファイルを使用しています。**

Angular CLIは開発用のツールでありscaffoldやangularアプリケーションのメンテナンスを行います。
JHipsterはAngularCLIの設定ファイルを生成します。そのため、AngularCLIのワークフローはJhipster内で動作します。
この統合は、アプリケーションのルートフォルダにangular.jsonファイルを生成し、その依存関係をpackage.jsonファイルに追加することによって行われます。

### Usage

```
ng help
```

### Building
JHipsterには独自のスクリプトが含まれているため、フロントエンドのビルドに`ng build`は使用しないでください。
詳細は下記ページを参照
[Using JHipster in development](https://www.jhipster.tech/development/)
[Using JHipster in production](https://www.jhipster.tech/production/)

### Generating Components, Directives, Pipes and Services
`ng generate (またはng g)` でAngularコンポーネントを生成することができます。

```
ng generate component my-new-component
ng g component my-new-component # using the alias

# Components support relative path generation
# Go to src/app/feature/ and run
ng g component new-cmp
# your component will be generated in src/app/feature/new-cmp
# but if you were to run
ng g component ../newer-cmp
# your component will be generated in src/app/newer-cmp
```


|Scaffold          |Usage              |
|:-----------------|------------------:|
|Component	   |ng g component my-new-component   |
|Directive	   |ng g directive my-new-directive  |
|Pipe		   |ng g pipe my-new-pipe  |
|Service           |ng g service my-new-service  |
|Class		   |ng g class my-new-class  |
|Guard		   |ng g guard my-new-guard  |
|Interface	   |ng g interface my-new-interface  |
|Enum		   |ng g enum my-new-enum  |
|Module		   |ng g module my-module  |


### Test
JHipsterアプリケーションの一貫性を保つため、テストの実行はnpmコマンドを介してのみ実行可能です。

```
npm test
```
### i18n
JHipsterは`ng2-translate`を翻訳目的に使用しています。Angular CLI の国際化はデフォルトのAngular i18nサポートに基づいており、JHipsterとは互換性がありません。

### Running the Server
Angular CLIを使用してアプリケーションを開発したい場合は、専用のコマンドを使用してサーバーを直接実行できます

```
ng serve
```

上記コマンドを実行することによって、Angularアプリケーションをコンパイルし、`http://localhost:4200`でアクセス可能になります。
しかし、あなたのバックエンドはデフォルトではそこから利用できません。 
ローカルバックエンドサーバーを使うにはそこからさらに

```
ng serve --proxy-conf proxy.conf.json
```
これでAPIにアクセス可能になるでしょう

### Conclusion
Angular CLIについてもっと知りたい場合は [https://cli.angular.io/](https://cli.angular.io/)を参照してください

# Using React (with Redux)
https://www.jhipster.tech/using-react/

# Customizing Bootstrap 4
https://www.jhipster.tech/customizing-bootstrap-4/

**※開発者向けTips: 変更の即時フィードバックを得るために`npm start`または`yarn start`の実行を忘れないようにしてください**
JHipsterアプリケーションの見た目をカスタマイズする
最も簡単な方法は、`src/main/webapp/content/css/global.css`のCSSスタイルを上書きすることです。
(sassオプションを選択した場合は、`src/main/webapp/content/scss/global.scss`)

あなたがあなた自身のscssファイルでBootstrapをPartialで使いたいならば、
scssファイルの始めに以下のようにインポートしてください。
例）border-radius mixinを使う場合

```
@import "node_modules/bootstrap/scss/variables";
@import "node_modules/bootstrap/scss/mixins/border-radius";
```

必ずメインのSassファイルではなくPartialのみをインポートするようにしてください、
さもなくば、重複したCSSを生成し、結果的に問題を引き起こすかもしれません。
color,border-radius等のdefaultのBootstrap設定を変更する場合やPartialファイルのpropertyの値を追加したい場合は
`src/main/webapp/content/scss/_bootstrap-variable.scss`を編集します。
Bootstrapに定義されている全ての値([_variables.scss](https://github.com/twbs/bootstrap/blob/v4-dev/scss/_variables.scss))はこのファイルで上書きすることができます。

# Using TLS and HTTP/2 in development
https://www.jhipster.tech/tls/