読者です 読者をやめる 読者になる 読者になる

CloudFoundryへSpring BootアプリケーションをPush

CloudFoundryへアプリケーションをPushする方法に関して簡単に書きたいと思います。
利用する環境はPivotal Cloud Foundryになります。
自分で試したい場合は、下記のサイトでアカウント作成して、OGとSPACEを作成してください。
Pivotal Account
OGとSPACEの簡単な説明は下記に書いておきます。
ORG
個人または複数の開発者が共通で利用するものです。
例えば、組織の単位でORGを作った場合は、その組織に所属している人達は、それにアクセスでき、
リソース、アプリケーション、サービスの可用性、カスタムドメインなどが共有されます。
SPACE
すべてのアプリケーションやサービスは、ある一定のスコープに置かれます。
例えば、組織の単位でORGを作った場合は、少なくとも1つのスペースが必要です。
スペースは、ユーザーにアプリケーションの開発、展開、保守のための共有場所へのアクセスを提供します。
各スペースの役割は、特定のスペースにのみ適用されます。

ORG,SPACE以外にもいろいろあるんですが、詳しい内容は下のリンクを参照するのがいいと思います。
Orgs, Spaces, Roles, and Permissions | Pivotal Docs

Cloud Foundryは基本的にはCloudFoundry CLというコマンドラインベースで操作されます。
f:id:chronos_snow:20161123225054j:plain

簡単な説明は終わりにして、
今回は、Spring BootのRestのアプリケーションをデプロイしてみようと思います。

Javaをインストール

下記のサイトからJavaをダウンロードします。
Java SE - Downloads | Oracle Technology Network | Oracle
Mac用のものを選択してダウンロードしてインストールします。

Gradleをインストール

下記のサイトからGradleをダウンロードします。
Gradle Distributions
ダウンロードしたら下記の要領でインストールします。

mkdir project
cd project
unzip gradle-3.2-bin.zip
mv gradle-3.2-bin gradle

環境変数の設定

ZSHの設定ファイルにパスを通します。

vi .zshrc
export GRADLE_HOME=${HOME}/project/gradle
export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home
export PATH=${PATH}:${JAVA_HOME}/bin:${GRADLE_HOME}/bin

MacにHomebrewをインストール

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

CloudFoundry CLIインストール

CloudFoundryを操作する為にはCloudFoundry CLIが必要になります。
アプリケーションをデプロイしたり、アプリケーションの状態を確認するなど
このCloudFoundry CLIで全て行うことができます。

brew tap cloudfoundry/tap
brew install cf-cli
brew update && brew upgrade cf-cli

CloudFoundryへログイン

CloudFoundry CLIのインストールが完了したらログインできるか確認します。

cf login 
API エンドポイント: https://api.example
Email> <アカウントID>
Password> <パスワード>
認証中です...
OK

CloudFoundryへアプリケーションをPUSH

サンプルのRestサービスアプリケーションとして下記のものを利用します。
github.com
アプリケーションはGradleプロジェクトベースになっています。
また、CloudFoundryへPUSHする為の設定として下記のmanifest.ymlで設定を定義しています。

applications:
- name: cf_sample_service
  memory: 512M
  instances: 1
  path: build/libs/cf_sample_service-1.0.0.jar
  buildpack: https://github.com/cloudfoundry/java-buildpack.git
  stack: cflinuxfs2

CloudFoundryへアプリケーションをPUSHする場合は下記のようにすればPUSHできます。

git clone https://github.com/chronossnow/cf_sample_service
cd cf_sample_service
./gradlew build
cf target -o <ORG> -s <SPACE>
cf push

Java Virtual Machine調査方法

Java Virtual Machinenの構成

JVMとOSの領域があります。
JVMはPermanentとHeapがあります。
Permanentはクラスやメソッドなどのメタデーターがロードされる領域になります。
Heapはクラスのインスタンスが格納される領域になります。
JVM以外はOSの領域がありCヒープとSヒープがあります。
CヒープはJavaから利用されるOSライブラリーなどのネイティヴなものがロードされる領域になります。
SヒープはJavaスレッドが格納される領域になります。

f:id:chronos_snow:20161002234440p:plain

各領域に関して

JVM Permanent クラスファイル(メタデーター)がロードされる領域
JVM New Eden 新しいオブジェクトが作成された時に最初に格納される領域
JVM New Survivor From Scavenge GCが発生してTo領域にあるオブジェクトで生存しているものはこの領域に移動
JVM New Survivor To Eden領域が満杯になるとScavenge GCが発生してオブジェクトがこの領域に移動
JVM OLD Scavenge GCが32回発生しても生存しているオブジェクトはこの領域に移動(FullGCで消える)
OS Cヒープ Javaから利用されるOSライブラリーなどのネイティヴなものがロードされる領域
OS Sヒープ Javaスレッドが格納される領域

JVMパラメーターに関して

パラメーター 概要
-Xmx Javaヒープの最大サイズを設定。単位はバイ
-Xms Javaヒープの初期サイズを設定。単位はバイ
-XX:MaxPermSize Permヒープの最大サイズを設定。単位はバイ
-XX:PermSize Permヒープの初期サイズを設定。単位はバイ
-Xmn New領域の初期値および最大値を設定。単位はバイ
-Xss 1スタック領域の最大サイズを設定。単位はバイ
-XX:NewRatio New領域に対する Old領域の割合を設定(2を設定した場合は、New領域とOld領域の割合が、1:2になる)
-XX:SurvivorRatio Survivor領域のFromとToに対するEdenの割合を指定(8を設定した場合は、Eden/From/Toの割合が、8:1:1になる)

Javaプロセス番号確認

[user@localhost]$ sudo su - root
[root@localhost]# sudo -u <アプリケーションアカウント> jps -v
20167 Jps 
15149 sample.jar -Xrs -Xms2048m -Xmx2048m ← この先頭の番号がJavaのプロセスID

ガベージコレクション統計データーの表示(-gcutilオプション)

[root@localhost]# sudo -u <アプリケーションアカウント> jstat -gcutil -h20 <JavaプロセスID> 1000
S0       S1      E           O        M          CCS       YGC   YGCT      FGC    FGCT      GCT  
0.00   0.00  80.09   2.36  97.77  95.62     52    10.822    52   19.085   29.907
0.00   0.00  80.09   2.36  97.77  95.62     52    10.822    52   19.085   29.907
0.00   0.00  80.09   2.36  97.77  95.62     52    10.822    52   19.085   29.907
0.00   0.00  80.09   2.36  97.77  95.62     52    10.822    52   19.085   29.907
0.00   0.00  80.09   2.36  97.77  95.62     52    10.822    52   19.085   29.907

列の見方は下記の内容を参考にして見てください。

概要
S0 Survivor 領域 0 の使用率 (現在の容量に対するパーセンテージ)
S1 Survivor 領域 1 の使用率 (現在の容量に対するパーセンテージ)
E Eden 領域の使用率 (現在の容量に対するパーセンテージ)
O Old 領域の使用率 (現在の容量に対するパーセンテージ)
P Permanent 領域の使用率 (現在の容量に対するパーセンテージ)
YGC 若い世代の GC イベント数
YGCT 若い世代のガベージコレクション時間
FGC フル GC イベント数
FGCT フルガベージコレクション時間
GCT ガベージコレクション総時間|

ガベージコレクション統計データーの表示(-gcオプション)

[root@localhost]# sudo -u <アプリケーションアカウント> jstat -gc -h20 <JavaプロセスID> 1000
S0C            S1C             S0U   S1U   EC                EU                 OC                  OU              MC           MU           CCSC      CCSU      YGC   YGCT      FGC   FGCT      GCT  
262144.0 262144.0  0.0    0.0   1572864.0 1262368.5 1048576.0   24778.0   47488.0 46427.5 5760.0 5507.9     52   10.822  52     19.085   29.907
262144.0 262144.0  0.0    0.0   1572864.0 1262368.5 1048576.0   24778.0   47488.0 46427.5 5760.0 5507.9     52   10.822  52     19.085   29.907
262144.0 262144.0  0.0    0.0   1572864.0 1262368.5 1048576.0   24778.0   47488.0 46427.5 5760.0 5507.9     52   10.822  52     19.085   29.907
262144.0 262144.0  0.0    0.0   1572864.0 1262368.5 1048576.0   24778.0   47488.0 46427.5 5760.0 5507.9     52   10.822  52     19.085   29.907
262144.0 262144.0  0.0    0.0   1572864.0 1262368.5 1048576.0   24778.0   47488.0 46427.5 5760.0 5507.9     52   10.822  52     19.085   29.907

列の見方は下記の内容を参考にして見てください。

概要
S0C Survivor 領域 0 の現在の容量 (KB)
S1C Survivor 領域 1 の現在の容量 (KB)
S0U Survivor 領域 0 の使用率 (KB)
S1U Survivor 領域 1 の使用率 (KB)
EC Eden 領域の現在の容量 (KB)
EU Eden 領域の使用率 (KB)
OC Old 領域の現在の容量 (KB)
OU Old 領域の使用率 (KB)
PC Permanent 領域の現在の容量 (KB)
PU Permanent 領域の使用率 (KB)
YGC 若い世代の GC イベント数
YGCT 若い世代のガベージコレクション時間
FGC フル GC イベント数
FGCT フルガベージコレクション時間
GCT ガベージコレクション総時間

モリープール世代及び領域容量の表示(-gccapacityオプション)

[root@localhost]# sudo -u <アプリケーションアカウント> jstat -gccapacity -h20 <JavaプロセスID> 1000
NGCMN         NGCMX         NGC             S0C             S1C            EC                  OGCMN         OGCMX          OGC               OC                 MCMN  MCMX            MC            CCSMN  CCSMX          CCSC     YGC   FGC
2097152.0 2097152.0 2097152.0 262144.0 262144.0 1572864.0  1048576.0  1048576.0  1048576.0  1048576.0       0.0 1091584.0  47488.0  0.0        1048576.0  5760.0    52    52
2097152.0 2097152.0 2097152.0 262144.0 262144.0 1572864.0  1048576.0  1048576.0  1048576.0  1048576.0       0.0 1091584.0  47488.0  0.0        1048576.0   5760.0    52    52
2097152.0 2097152.0 2097152.0 262144.0 262144.0 1572864.0  1048576.0  1048576.0  1048576.0  1048576.0       0.0 1091584.0  47488.0  0.0        1048576.0   5760.0    52    52
2097152.0 2097152.0 2097152.0 262144.0 262144.0 1572864.0  1048576.0  1048576.0  1048576.0  1048576.0       0.0 1091584.0  47488.0  0.0        1048576.0   5760.0    52    52

列の見方は下記の内容を参考にして見てください。

概要
NGCMN New 世代の最小容量 (KB)
NGCMX New 世代の最大容量 (KB)
NGC New 世代の現在の容量 (KB)
S0C Survivor 領域 0 の現在の容量 (KB)
S1C Survivor 領域 1 の現在の容量 (KB)
EC Eden 領域の現在の容量 (KB)
OGCMN Old 世代の最小容量 (KB)
OGCMX Old 世代の最大容量 (KB)
OGC Old 世代の現在の容量 (KB)
OC Old 領域の現在の容量 (KB)
PGCMN Permanent 世代の最小容量 (KB)
PGCMX Permanent 世代の最大容量 (KB)
PGC Permanent 世代の現在の容量 (KB)
PC Permanent 領域の現在の容量 (KB)
YGC 若い世代の GC イベント数
FGC フル GC イベント数

メモリダンプ確認方法

[root@localhost]# sudo -u <アプリケーションアカウント> jmap -dump:format=b,file=heap.bin <JavaプロセスID>
[root@localhost}# jhat heap.bin ← http://<ホスト名>:7000でアクセスできる。

メモリダンプテキスト出力方法

[root@localhost]#  sudo -u <アプリケーションアカウント> jmap -histo:live <JavaプロセスID> > heap01.txt

Cヒープ内容出力方法

[root@localhost]# ps -aux | grep 'java'
root     13386  0.0  0.0 175120  1532 ?        S    Sep21   0:00 sudo -u sample nohup /usr/local/jdk/bin/java
sample    13387  0.2 74.9 5969548 3036976 ?     Sl   Sep21   5:05 /usr/local/jdk/bin/java -Xms3072m -Xmx3072m -Xmn2048m
[root@localhost]# gcore <プロセス番号>
Saved corefile core.13386
[root@localhost]# strings -a core.13386 > core.txt
[root@localhost]# sort core.txt | uniq -c | sort -nr | less > data.txt

Redis Clusterに関して

Redis Clusterを試しに組んでみたので、その簡単な構築方法。

Redisインストール

Redis Clusterの場合6ノード必要(master : 3台/slave : 3台)になります。
また、Masterを3台のみで構成することも可能です。

[user@localhost]$ sudo su - root
[root@localhost]# cd /usr/local/src
[root@localhost]# wget http://download.redis.io/releases/redis-3.2.4.tar.gz
[root@localhost]# tar -zxvf redis-3.2.4.tar.gz
[root@localhost]# mv redis-3.2.4 ../redis
[root@localhost]# cd ../redis
[root@localhost]# make

Redis設定ファイル

[root@localhost]# cd /usr/local
[root@localhost]# mkdir redis_cluster
[root@localhost]# cd redis_cluster
[root@localhost]# cp ../redis/redis.conf .
[root@localhost]# vi redis.conf
daemonize yes
bind 0.0.0.0
port 7000
cluster-enabled yes
cluster-config-file /usr/local/redis_cluster/nodes.conf
cluster-node-timeout 5000
appendonly yes

Redis Server起動

[root@localhost]# cd /usr/local/redis_cluster
[root@localhost]#  /usr/local/redis/src/redis-server ./redis.conf

Redis Clusterの構成はRedis Serverは6ノードでMasterは3ノードでClusterを組みSlaveは3ノードの構成で検証します。

ノード IP ポート 尾行
redis01 172.20.100.10 7000 Master
redis02 172.20.100.11 7001 Master
redis03 172.20.100.12 7002 Master
redis04 172.20.100.13 7003 Slave
redis05 172.20.100.14 7004 Slave
redis06 172.20.100.15 7005 Slave

6台のRedis ServerでClusterを構成

[root@localhost]# /usr/local/redis/src/redis-trib.rb create 172.20.100.10:7000 172.20.100.11:7001 172.20.100.12:7002 172.20.100.13:7003 172.20.100.14:7004 172.20.100.15:7005

Redis Cluster確認

[root@localhost]# /usr/local/redis/src/redis-cli -c -p 7000
127.0.0.1:7000> set foo bar
 -> Redirected to slot [12182] located at 172.20.100.11:7001
 OK
 172.20.100.11:7001> set hello world
 -> Redirected to slot [866] located at 172.20.100.10:7000
 OK
 172.20.100.11:7001> get foo
 "bar"
 172.20.100.11:7001> get hello
 -> Redirected to slot [866] located at 172.20.100.10:7000
 "world"
 172.20.100.10:7000>

Angular2での外部APIの呼び出し方法に関して

Angular2系でのの外部APIの呼び出し方法に関して書きたいと思います。
Angular2系では下記のHTTPクライアントがあるのでそれを利用します。
angular.io
Angular1系ではhttpとresourceの2つのクライアントがありましたが、
Angular2系はこのHTTPクライアントで行います。
これを利用するればJSONマッピングなど比較的に簡単に行うことができます。
簡単な実装方法を下記に書きます。

メッセージ格納クラス

APIからのJSONマッピングするクラスを作成します。
Angular1系の時は単純にそのままJSONを扱ってましたが(クラスぽい定義で扱うこともできる)
Angular2系からJSONマッピングするクラスに値を格納するようにします。
SONをマッピングするクラスはJSONの各要素を格納するエリアの定義及び
コンストラクターで要素の値を受けてエリアに値をセットするようにします。

export class Message {
        messageId : string;
        message : string;
        constructor(
                messageId : string,
                message : string) {
                this.messageId = messageId;
                this.message = message;
        }
}
メッセージサービスクラス作成

APIの呼び出しを行うサービスクラスを作成します。
APIの呼び出しはAngularのHttpとRXJSのObservableを利用します。
非同期通信で利用できるものが2つあります。
1つはObservableです。
もう1つはAngular1系からあるPromiseです。
Promiseは1リクエストの非同期処理を扱うもので
連続リクエストの非同期処理や遅延処理やキャンセルなどはできません。
Angular2からはPromiseではなくObservableを利用します。
Observableは連続リクエストの非同期処理や遅延処理やキャンセルなど
Promiseではできないことも可能になっています。

import { Injectable } from '@angular/core';
import { Headers, Http, Response } from '@angular/http';
import { Observable } from 'rxjs/Observable';
import { Message } from './message';
@Injectable()
export class MessageService {
        private messageUrl = '/message_service';
        constructor (private http: Http) {}
        getMessage(): Observable<Message> {
                return this.http.get(this.messageUrl)
                        .map(response => response.json() as Message)
                        .catch(this.handleError);
        }
        private handleError(error: any): Observable<any> {
                console.error('An error occurred', error);
                return Observable.throw(error.message || error);
        }
}
モジュール定義

NgModuleに設定を行います。
AngularのHttpModuleを利用するのでimportsに設定して宣言します。
また作成したMessageServiceをprovidersに設定して、アプリケーションでDIできるようにします。

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { FormsModule } from '@angular/forms';
import { HttpModule, JsonpModule } from '@angular/http';
import { AppComponent } from './app.component';
import { MessageService  } from './message.service';
@NgModule({
        imports: [
                BrowserModule,
                FormsModule,
                HttpModule
        ],
        declarations: [
                AppComponent
        ],
        providers: [
                MessageService
        ],
        bootstrap: [
                AppComponent
        ]
})
export class AppModule { }
コンポーネント設定

コンポーネントコンストラクターにMessageServiceをDIします。
ngOnInit()の中でDIしたMessageServiceを利用してAPIを呼びします。
このngOnInit()は初期値を設定する場合などに利用するもので、
コンポーネントが呼ばれたら自動的にこれが呼ばれるようになっています。
APIの結果はJSONマッピングクラスのMessageに格納されます。
HTMLで{{ message.messageId }}など定義しとけば格納されている値をHTMLで表示できます。

import { Component } from '@angular/core';
import { MessageService  } from './message.service';
import { Message } from './message';
@Component({
        selector: 'my-app',
        template: '<div>{{ message.messageId }} : {{ message.messageName }}</div>'
})
export class AppComponent {
        errorMessage : string;
        message : Message;
        error : any;
        constructor(private messageService : MessageService) { }
        ngOnInit(): void {
                this.messageService
                        .getMessage()
                        .subscribe(
                                message => this.message = message,
                                error =>  this.errorMessage = <any>error);
        }
}

Angular2のQuickStartをやってみた

Angular2のRC5がリリースされました。
そろそろ次ぐらいが安定版のリリースになる気がします。
Angular2からTypeScriptベースに変更されています。
Angular1系と比べかなり変わっているので、移行はかなり厳しそうです。
Angular2のQuickStartをやってみました。
angular.io
それとGulpやWebPackも一緒設定してみました。

基本構成

Angular2の基本的なディレクトリ構成は下記の構成です。

angular2-quickstart
 |-app
 |-gulpfile.js
 |-index.html
 |-package.json
 |-style.css
 |-tsconfig.json
 |-typings.json
 |-webpack.config.js
パッケージ管理の設定

利用するパッケージ管理する為にnode.jsのnpmを利用します。
npmでは利用するパッケージ管理用の設定ファイル(package.json)を作成します。

{
  "name": "angular2-quickstart",
  "version": "1.0.0",
  "scripts": {
    "start": "/usr/local/bin/gulp && /usr/local/bin/gulp connect ",
    "postinstall": "typings install",
    "typings": "typings"
  },
  "license": "MIT",
  "dependencies": {
    "@angular/common": "2.0.0-rc.5",
    "@angular/compiler": "2.0.0-rc.5",
    "@angular/core": "2.0.0-rc.5",
    "@angular/forms": "0.3.0",
    "@angular/http": "2.0.0-rc.5",
    "@angular/platform-browser": "2.0.0-rc.5",
    "@angular/platform-browser-dynamic": "2.0.0-rc.5",
    "@angular/router": "3.0.0-rc.1",
    "@angular/router-deprecated": "2.0.0-rc.2",
    "@angular/upgrade": "2.0.0-rc.5",
    "systemjs": "0.19.27",
    "core-js": "^2.4.0",
    "reflect-metadata": "^0.1.3",
    "rxjs": "5.0.0-beta.6",
    "zone.js": "^0.6.12",
    "angular2-in-memory-web-api": "0.0.15",
    "bootstrap": "^3.3.6"
  },
  "devDependencies": {
    "browser-sync": "^2.14.0",
    "concurrently": "^2.0.0",
    "connect-history-api-fallback": "^1.3.0",
    "gulp": "^3.9.1",
    "gulp-connect": "^5.0.0",
    "gulp-webpack": "^1.5.0",
    "lite-server": "^2.2.0",
    "proxy-middleware": "^0.15.0",
    "ts-loader": "^0.8.2",
    "typescript": "^1.8.10",
    "typings": "^1.0.4",
    "url": "^0.11.0"
  }
}
コンパイル設定

TypeScriptコードはコンパイルが必要です。
そのコンパイル時にコンパイルオプション及びコンパイル対象のTypeScriptコードの指定などの
設定をまとめた設定ファイル(tsconfig.json)を作成します。

{
	"compilerOptions": {
		"target": "es5",
		"module": "commonjs",
		"moduleResolution": "node",
		"sourceMap": true,
		"emitDecoratorMetadata": true,
		"experimentalDecorators": true,
		"removeComments": false,
		"noImplicitAny": false
	}
}
Typingsの設定

TypeScriptには型定義というものがあります。
その型が記述されているものが型定義ファイル(〜.d.ts)です。
一般的な型定義ファイルは下記のGitHubリポジトリにあります。
https://github.com/DefinitelyTyped/DefinitelyTyped
利用する型定義ファイルを管理するものがTypingsです。
Typingsは利用する型定義ファイルをまとめた設定ファイル(typings.json)を作成します。

{
	"globalDependencies": {
		"core-js": "registry:dt/core-js#0.0.0+20160602141332",
		"jasmine": "registry:dt/jasmine#2.2.0+20160621224255",
		"node": "registry:dt/node#6.0.0+20160807145350"
	}
}
WebPackの設定

WebPackとはアプリケーションに必要なJavaScriptCSSなどのリソースの依存関係を解決して
配布できる形にしてくるビルドツールです。
WebPackのビルド定義を行うビルド設定ファイル(webpack.config.js)を作成します。

module.exports = {
	entry : './app/main.ts',
	output : {
		filename : './bundle.js'
	},
	resolve : {
		root : [ './node_modules' ],
		extensions : [ '', '.webpack.js', 'web.js', '.js', '.ts' ]
	},
	module : {
		loaders : [ {
			test : /\.ts$/,
			loader : 'ts-loader'
		} ]
	}
}
Gulpの設定

Gulpとはサーバー設定やProxy設定及びリソースの圧縮などのタスクが定義できます。
Gulpのタスク定義は設定ファイル(gulpfile.js)を作成します。

var gulp = require('gulp');
var connect = require('gulp-connect');
var proxy = require('proxy-middleware');
var url = require('url');
var webpack = require('gulp-webpack');
var webpackConfig = require('./webpack.config.js');
gulp.task('ts', function() {
	return gulp.src([ './*.ts' ])
			.pipe(webpack(webpackConfig))
			.pipe(gulp.dest('./dist'));
});
gulp.task('index', function() {
	return gulp.src([ './index.html' ])
			.pipe(gulp.dest('./dist'));
});
gulp.task('css', function() {
	return gulp.src([ './styles.css' ])
			.pipe(gulp.dest('./dist'));
});
gulp.task('connect', function() {
  connect.server({
    root: ['dist'],
    port: 9000,
    livereload: true,
    middleware: function(connect, o) {
        return [ (function() {
            var options = url.parse('http://localhost:8080/service');
            options.route = '/service';
            return proxy(options);
        })() ];
    }
  });
});
gulp.task('default', [ 'ts', 'index', 'css']);
コンポーネント作成

Angular2はコンポーネント指向のJSフレームワークです。
そのコンポーネントは定義方法は下記のコードになります。

import {Component} from '@angular/core';
@Component({
	selector: 'my-app',
	template: '<h1>My First Angular 2 App</h1>'
})
export class AppComponent { }
モジュール定義作成

NgModuleは、コンポーネント、ディレクティブ、パイプ、サービスなどを一箇所にまとめて定義
してモジュールを宣言するものです。
基本的にこのモジュール宣言をアプリケーションには1つ定義する必要がありますが、
現状、宣言しなくとも書き方によってはアプリケーションは動きます。

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { FormsModule } from '@angular/forms';
import { HttpModule, JsonpModule } from '@angular/http';
import { AppComponent } from './app.component';
@NgModule({
	imports: [
		BrowserModule,
		FormsModule,
		HttpModule,
		JsonpModule
	],
	declarations: [
		AppComponent
	],
	bootstrap: [
		AppComponent
	]
})
export class AppModule { }
エントリーポイント作成

アプリケーションを起動する為のエントリーポイントを作成する必要があります。

import "core-js";
import "rxjs/Rx";
import "zone.js/dist/zone";

import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { AppModule } from './app.module';
platformBrowserDynamic().bootstrapModule(AppModule);
index.html作成

最後にindex.htmlを作成します。

<html>
<head>
<title>angular2-quickstart</title>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" href="styles.css">
</head>
<body>
	<my-app>Loading...</my-app>
</body>
<script src="./bundle.js"></script>
</html>
起動方法
cd angular2-quickstart
npm install
npm start

第9回Jenkins勉強会に参戦

第9回Jenkins勉強会に参戦してきました。
jenkins.connpass.com

超簡単Pipeline講座
  • Jenkinsのパイプラインの概説
  • Jenkins1の時はbuild PipelineでGUIベースで定義することができた
  • GUIベースの定義はからり面倒で大変
  • Pipeline PluginはGroovyでコードベースで定義できる
  • 可視化の部分は有償だったがOSS化された
  • Jenkins2のPipelineはPipeline PluginでのGroovyのコードベースで定義していく

www.slideshare.net

実録!となりのJenkins2.0」
  • Jenkins1及びプラグインインストール
  • Jenkins1 Build PipelineでのGUIでJobのワークフローを作れる
  • デプロイなどの独自スクリプトはシェルなどで記述する
  • Jenkins1からJenkins2へのアップグレードは簡単
  • Jenkins1で利用したジョブやPipelineもそのまま引き継がれる
  • 後方互換性がかなりしっかりしている
  • GroovyでJobを繋ぎを記述できる
  • デプロイなどの独自スクリプトはGroovyで書ける
  • ソースのテンプレート機能もある
  • Groovyのコードをビジアル表示してくれる
  • ジョブ設定やGroovyのソースはjenkinsfileにもできる(GitHubで管理可能になったので移行が楽)
  • Clover等などの今まで利用したPluginはJenkins2 Pipelineスクリプトに対応しているなら使える

www.slideshare.net

「Jenkins 2を使った究極のpipeline ~ 明日もう一度来てください、本物のpipelineをお見せしますよ ~」
  • Job設定がコード化されて変更が楽になった。
  • Jenkins1 build PipelineよりJenkins2 Pipelineの方がビジュアル的に見やすくなっている。
  • Multi-Branch Pluginでプルリクがわかりやすくなった
  • Multi-Branch Pluginは自動でブランチに対応したジョブを作成してくれる
  • Multi-Branch Pluginはブランチを削除すると自動でジョブが消える
  • GitHub Organization Folder Pluginはプルリクのジョブも自動作成してくれる

www.slideshare.net

Regional SCRUM GATHERING Tokyo 2016へ参戦

2日間で、アジャイルスクラム関連のセッションが開催されるイベントの
Regional SCRUM GATHERING Tokyo 2016へ参戦。
Regional SCRUM GATHERINGは、スクラムの初心者からエキスパート、ユーザー企業から開発企業など
立場の異なる様々な人々が集まる学びの場です。
スクラムマスターやプロダクトオーナーやトレーナーなど多くの人が集まってます。
今回は、CSMを取得して初めて参加しました。
2016.scrumgatheringtokyo.org
初日なんですが、まさかの大雪で、朝起きたら大変なことにwww
とりあえず駅へ...入れないし、電車が壊滅状態でたどり着けず断念www
スクラムのスケールの話とか聞きたかったのに...。
f:id:chronos_snow:20160119231200j:plain
2日目からの参加になってしまったwww
2日目のkeynoteは、Scrum AllianceのCEOやエッセンシャルスクラムの著者の方の話でした。
エッセンシャルスクラムの著者の方の講演は、
コンポーネントチームやフューチャーチームの話は聞けて良かったと思います。
f:id:chronos_snow:20160119230738j:plain
今回、聞いたセッションは、下の内容です。

Microsoftが実践したScrum導入7年間の旅、そしてDevOpsへの進化
  • Microsoftがかなりの時間を掛けてウォーターフォールからアジャイルへ移行。
  • DevOpsは、開発以外にも運用(オペレーション)も含んでいる。
  • DevOpsで、コードのデプロイが30倍スピードアップwww。
  • DevOpsで、パフォーマンスの低い環境に比べてリードタイムが200分の1に短縮www。

docs.com

Agile人材の評価とキャリアプラン

www.slideshare.net

あなたのチームの「いい人」は機能していますか?
  • 障害や運用に追われて、本タスク出来てない人とかいる。
  • まわりにくらべて自分の成果は小さい。
  • 技術力が向上していない。
  • プロダクトにコミットできない。

www.slideshare.net

あじゃいる時代のソフトウェア品質保証 〜DevSQAの提案〜
  • 山中教授似すぎwww

www.slideshare.net

Customer Expectations Management of Scrum スクラムにおける事前期待のマネジメント
  • プロダクトオーナーよりの内容。
  • サービスの品質。
  • サービスサイエンス
  • 期待のマネージメント。

www.slideshare.net