今日は、声からその人の感情がわかるソフトウェアで有名なEmpath様のセミナーへ
参加しました。
今一番、イノベータースタートアップ企業で元気がある会社です。
最初は、色々な方の声を録音し聴いて、「この人は喜んでる」とか「悲しんでる」
など、アナログ的に作り始めたそうです。
新しい物を作り上げる事は、改めて膨大な作業が必要なんだと感じました。
当社も何か始めないといけないと思った刺激を受けたセミナーでしたね。
皆さん頑張りましょう!
今日は、声からその人の感情がわかるソフトウェアで有名なEmpath様のセミナーへ
参加しました。
今一番、イノベータースタートアップ企業で元気がある会社です。
最初は、色々な方の声を録音し聴いて、「この人は喜んでる」とか「悲しんでる」
など、アナログ的に作り始めたそうです。
新しい物を作り上げる事は、改めて膨大な作業が必要なんだと感じました。
当社も何か始めないといけないと思った刺激を受けたセミナーでしたね。
皆さん頑張りましょう!
どうも、小野です。 今回はAWS Fargateを使って、下図のような構成で作っていきます。
AWS Fargateは元々あるECSからEC2の管理を除外したサービスになります。 つまり、ECSをよりマネージドにしたものです。
Fargateについて知りたい方は公式サイトを確認してください。 aws.amazon.com
説明するにあたりAWSコンソールでもよいのですが、UIが頻繁に変わったりするので、今回はCLIベースで説明していきます。
※動作確認を行うターミナルは、コマンド実行時に変数を利用している関係上、最後まで閉じないようにしてください。
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<アカウントID>:root" }, "Action": "sts:AssumeRole" } }
ROLE_ARN=$(aws iam create-role --role-name fargate-helloworld-role --assume-role-policy-document file://./assume-role-policy.json | jq -r '.Role.Arn') aws iam attach-role-policy --role-name fargate-helloworld-role --policy-arn "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
コンテナのリポジトリはDockerHubなどがありますが、今回はAWSのECRを使います。
HELLO_REPO_URI=$(aws ecr create-repository --repository-name helloworld/hello | jq -r '. repository. repositoryUri') WORLD_REPO_URI=$(aws ecr create-repository --repository-name helloworld/world | jq -r '. repository. repositoryUri') NGINX_REPO_URI=$(aws ecr create-repository --repository-name helloworld/nginx | jq -r '. repository. repositoryUri')
$(aws ecr get-login --no-include-email --region ap-northeast-1)
Webサーバにはnginxを使います。 nginxはALBからリクエストを受けて、サービスディスカバリを利用してアプリケーションにリクエストをします。
mkdir helloworld-nginx cd helloworld-nginx
default.confを作成します。
server { listen 80; server_name localhost; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; location ^~ /hello/ { # パスの先頭が「/hello/」の場合に helloアプリケーションにリクエスト proxy_pass http://hello.helloworld:8080/hello/; } location ^~ /world/ { # パスの先頭が「/world/」の場合に worldアプリケーションにリクエスト proxy_pass http://world.helloworld:8080/world/; } location / { root /usr/share/nginx/html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } }
「hello.helloworld」、「world.helloworld」はサービスディスカバリの機能によってDNS解決されます。
FROM nginx # 作成したdefault.confをnginxサーバに置きます ADD "default.conf" "/etc/nginx/conf.d/"
docker build -t helloworld-nginx . docker tag helloworld/nginx:latest ${NGINX_REPO_URI}:latest docker push ${NGINX_REPO_URI}:latest
今回作成するアプリケーションは、JavaEE + Payara Microで作ります。 アプリケーションは、Hello、Worldの2つ作ります。
@Path("hello") public class HelloResource { @GET @Produces(MediaType.TEXT_PLAIN) public String getText() { // Worldサービスのホストは環境変数から取得 String host = System.getenv("WORLD_HOST"); String url = "http://" + host + ":8080/world/webresources"; // Worldアプリケーションから文字列を受け取り、Helloと結合して返却する return "Hello " + ClientBuilder.newClient() .target(url) .path("world") .request() .get(String.class); } }
buildタグ内に追加
<build> <finalName>hello</finalName> ←追加
FROM payara/micro # curlをインストールするため一時的にrootユーザに変更 USER root RUN apk add --no-cache curl USER payara ADD "target/hello.war" "/tmp/" ENTRYPOINT ["java", "-jar", "payara-micro.jar","--deploy","/tmp/hello.war"]
mvn clean package docker build -t helloworld-hello . docker tag helloworld/hello:latest ${HELLO_REPO_URI}:latest docker push ${HELLO_REPO_URI}:latest
@Path("world") public class WorldResource { @GET @Produces(MediaType.TEXT_PLAIN) public String getText() { return "World!"; } }
<build> <finalName>world</finalName> ←追加
FROM payara/micro # curlをインストールするため一時的にrootユーザに変更 USER root RUN apk add --no-cache curl USER payara ADD "target/world.war" "/tmp/" ENTRYPOINT ["java", "-jar", "payara-micro.jar","--deploy","/tmp/world.war"]
mvn clean package docker build -t helloworld-world . docker tag helloworld/world:latest ${WORLD_REPO_URI}:latest docker push ${WORLD_REPO_URI}:latest
タスク定義の登録をCLIで実行する際に、オプション値にjsonで渡すものがあり、シンタックスベースの場合ダブルクォートのエスケープが必要になるので、JSONで設定します。
サービスのコンテナは、内部でヘルスチェックを行うようにします。
{ "family": "helloworld-hello", "networkMode": "awsvpc", "taskRoleArn": "<ROLE_ARN>", "executionRoleArn": "<ROLE_ARN>", "containerDefinitions": [ { "name": "helloworld-hello", "image": "<リポジトリURI>", "portMappings": [ { "containerPort": 8080, "hostPort": 8080, "protocol": "tcp" } ], "essential": true, "healthCheck": { "retries": 3, "command": [ "CMD-SHELL", "curl http://localhost:8080/hello/index.html || exit 1" ], "timeout": 5, "interval": 30, "startPeriod": 120 }, "environment": [ { "name": "WORLD_HOST", "value": "world.helloworld" } ] } ], "requiresCompatibilities": [ "FARGATE" ], "cpu": "512", "memory": "1024" }
{ "family": "helloworld-world", "networkMode": "awsvpc", "taskRoleArn": "<ROLE_ARN>", "executionRoleArn": "<ROLE_ARN>", "containerDefinitions": [ { "name": "helloworld-world", "image": "<リポジトリURI>", "portMappings": [ { "containerPort": 8080, "hostPort": 8080, "protocol": "tcp" } ], "essential": true, "healthCheck": { "retries": 3, "command": [ "CMD-SHELL", "curl http://localhost:8080/world/index.html || exit 1" ], "timeout": 5, "interval": 30, "startPeriod": 120 } } ], "requiresCompatibilities": [ "FARGATE" ], "cpu": "512", "memory": "1024" }
{ "family": "helloworld-nginx", "networkMode": "awsvpc", "taskRoleArn": "<ROLE_ARN>", "executionRoleArn": "<ROLE_ARN>", "containerDefinitions": [ { "name": "helloworld-nginx", "image": "<リポジトリURI>", "portMappings": [ { "containerPort": 80, "hostPort": 80, "protocol": "tcp" } ], "essential": true, "healthCheck": { "retries": 3, "command": [ "CMD-SHELL", "curl http://localhost/ || exit 1" ], "timeout": 5, "interval": 30, "startPeriod": 0 } } ], "requiresCompatibilities": [ "FARGATE" ], "cpu": "256", "memory": "512" }
では、準備が整ったので、CLIベースに順を追って構築していきます。 作業ディレクトリは、上記で作成したtask-xxxx.jsonがある場所に移動してください。
# VPC作成 VPC_ID=$(aws ec2 create-vpc --cidr-block 10.0.0.0/16 | jq -r '.Vpc.VpcId') # DNS hostname resolutionを有効 aws ec2 modify-vpc-attribute --vpc-id ${VPC_ID} --enable-dns-support aws ec2 modify-vpc-attribute --vpc-id ${VPC_ID} --enable-dns-hostnames # インターネットゲートウェイの作成 IGW_ID=$(aws ec2 create-internet-gateway | jq -r '.InternetGateway.InternetGatewayId') # VPCにインターネットゲートウェイを追加 aws ec2 attach-internet-gateway --internet-gateway-id ${IGW_ID} --vpc-id ${VPC_ID} # サブネット(パブリック:2、プライベート:2)を作成 PUBLIC_SUBNET_A_ID=$(aws ec2 create-subnet --vpc-id ${VPC_ID} --availability-zone ap-northeast-1a --cidr-block 10.0.0.0/24 | jq -r '.Subnet.SubnetId') PUBLIC_SUBNET_C_ID=$(aws ec2 create-subnet --vpc-id ${VPC_ID} --availability-zone ap-northeast-1c --cidr-block 10.0.1.0/24 | jq -r '.Subnet.SubnetId') PRIVATE_SUBNET_A_ID=$(aws ec2 create-subnet --vpc-id ${VPC_ID} --availability-zone ap-northeast-1a --cidr-block 10.0.2.0/24 | jq -r '.Subnet.SubnetId') PRIVATE_SUBNET_C_ID=$(aws ec2 create-subnet --vpc-id ${VPC_ID} --availability-zone ap-northeast-1c --cidr-block 10.0.3.0/24 | jq -r '.Subnet.SubnetId') # パブリックのルートテーブル作成 PUBLIC_ROUTE_TABLE_ID=$(aws ec2 create-route-table --vpc-id ${VPC_ID} | jq -r '.RouteTable.RouteTableId') aws ec2 create-route --route-table-id ${PUBLIC_ROUTE_TABLE_ID} --destination-cidr-block 0.0.0.0/0 --gateway-id ${IGW_ID} PUBLIC_A_ASSOCITATE_ID=$(aws ec2 associate-route-table --subnet-id ${PUBLIC_SUBNET_A_ID} --route-table-id ${PUBLIC_ROUTE_TABLE_ID} | jq -r '.AssociationId') PUBLIC_C_ASSOCITATE_ID=$(aws ec2 associate-route-table --subnet-id ${PUBLIC_SUBNET_C_ID} --route-table-id ${PUBLIC_ROUTE_TABLE_ID} | jq -r '.AssociationId') #Elastic IPを発行 ALLOCATION_ID=$(aws ec2 allocate-address --domain vpc | jq -r '.AllocationId') # NATゲートウェイを作成 NAT_GATEWAY_ID=$(aws ec2 create-nat-gateway --subnet-id ${PUBLIC_SUBNET_A_ID} --allocation-id ${ALLOCATION_ID} | jq -r '.NatGateway.NatGatewayId') # プライベートのルートテーブル作成 PRIVATE_ROUTE_TABLE_ID=$(aws ec2 create-route-table --vpc-id ${VPC_ID} | jq -r '.RouteTable.RouteTableId') aws ec2 create-route --route-table-id ${PRIVATE_ROUTE_TABLE_ID} --destination-cidr-block 0.0.0.0/0 --nat-gateway-id ${NAT_GATEWAY_ID} PRIVATE_A_ASSOCITATE_ID=$(aws ec2 associate-route-table --subnet-id ${PRIVATE_SUBNET_A_ID} --route-table-id ${PRIVATE_ROUTE_TABLE_ID} | jq -r '.AssociationId') PRIVATE_C_ASSOCITATE_ID=$(aws ec2 associate-route-table --subnet-id ${PRIVATE_SUBNET_C_ID} --route-table-id ${PRIVATE_ROUTE_TABLE_ID} | jq -r '.AssociationId')
# ロードバランサ、Nginx用のセキュリティグループ作成 WEB_SG_ID=$(aws ec2 create-security-group --group-name helloworld-web-sg --description "web security group" --vpc-id ${VPC_ID} | jq -r '.GroupId') # インバウンド設定で80を許可する aws ec2 authorize-security-group-ingress --group-id ${WEB_SG_ID} --protocol tcp --port 80 --cidr 0.0.0.0/0 # サービス用のセキュリティグループ作成 APP_SG_ID=$(aws ec2 create-security-group --group-name helloworld-app-sg --description "application security group" --vpc-id ${VPC_ID} | jq -r '.GroupId') # インバウンド設定で8080を許可する aws ec2 authorize-security-group-ingress --group-id ${APP_SG_ID} --protocol tcp --port 8080 --cidr 0.0.0.0/0
# ターゲットグループの作成 # ロードバランサがリクエストを送るターゲットを登録 TARGET_GROUP_ARN=$(aws elbv2 create-target-group --name helloworld-nginx --protocol HTTP --port 80 --vpc-id ${VPC_ID} --target-type ip | jq -r '.TargetGroups[0].TargetGroupArn') # ロードバランサ作成 LB_ARN=$(aws elbv2 create-load-balancer --name alb-helloworld --subnets ${PUBLIC_SUBNET_A_ID} ${PUBLIC_SUBNET_C_ID} --security-groups ${WEB_SG_ID} | jq -r '.LoadBalancers[0].LoadBalancerArn') # リスナー登録 aws elbv2 create-listener --load-balancer-arn ${LB_ARN} --protocol HTTP --port 80 --default-actions Type=forward,TargetGroupArn=${TARGET_GROUP_ARN}
# タスク定義作成 TASK_HELLO_REVISION=$(aws ecs register-task-definition --cli-input-json file://./task-hello.json | jq -r '.taskDefinition.revision') TASK_WORLD_REVISION=$(aws ecs register-task-definition --cli-input-json file://./task-world.json | jq -r '.taskDefinition.revision') TASK_NGINX_REVISION=$(aws ecs register-task-definition --cli-input-json file://./task-nginx.json | jq -r '.taskDefinition.revision') # クラスタ作成 CLUSTER_NAME=fargate-helloworld aws ecs create-cluster --cluster-name ${CLUSTER_NAME} # サービス検出ネームスペース作成 OPERATION_ID=$(aws servicediscovery create-private-dns-namespace --name helloworld --vpc ${VPC_ID} | jq -r '.OperationId') # 作成したネームスペースのIDを確認 NAMESPACE_ID=$(aws servicediscovery get-operation --operation-id ${OPERATION_ID} | jq -r '.Operation.Targets.NAMESPACE') ネームスペース作成に時間がかかるので、1分ほど待つ。 # Helloサービス名登録 HELLO_SERVICE_ID=$(aws servicediscovery create-service --name hello --dns-config "NamespaceId=${NAMESPACE_ID},RoutingPolicy=MULTIVALUE,DnsRecords=[{Type=A,TTL=60}]" | jq -r '.Service.Id') HELLO_REGISTRY_ARN=$(aws servicediscovery get-service --id ${HELLO_SERVICE_ID} | jq -r '.Service.Arn') # Worldサービス名登録 WORLD_SERVICE_ID=$(aws servicediscovery create-service --name world --dns-config "NamespaceId=${NAMESPACE_ID},RoutingPolicy=MULTIVALUE,DnsRecords=[{Type=A,TTL=60}]" | jq -r '.Service.Id') WORLD_REGISTRY_ARN=$(aws servicediscovery get-service --id ${WORLD_SERVICE_ID} | jq -r '.Service.Arn') # Nginxサービス名登録 NGINX_SERVICE_ID=$(aws servicediscovery create-service --name nginx --dns-config "NamespaceId=${NAMESPACE_ID},RoutingPolicy=MULTIVALUE,DnsRecords=[{Type=A,TTL=60}]" | jq -r '.Service.Id') NGINX_REGISTRY_ARN=$(aws servicediscovery get-service --id ${NGINX_SERVICE_ID} | jq -r '.Service.Arn') # Helloサービス作成 aws ecs create-service --cluster ${CLUSTER_NAME} --service-name hello-service --task-definition helloworld-hello:${TASK_HELLO_REVISION} --desired-count 1 --launch-type "FARGATE" --network-configuration "awsvpcConfiguration={subnets=["${PRIVATE_SUBNET_A_ID}","${PRIVATE_SUBNET_C_ID}"],securityGroups=["${APP_SG_ID}"],assignPublicIp=DISABLED}" --service-registries "registryArn=${HELLO_REGISTRY_ARN},containerName=helloworld-hello" # Worldサービス作成 aws ecs create-service --cluster ${CLUSTER_NAME} --service-name world-service --task-definition helloworld-world:${TASK_WORLD_REVISION} --desired-count 1 --launch-type "FARGATE" --network-configuration "awsvpcConfiguration={subnets=["${PRIVATE_SUBNET_A_ID}","${PRIVATE_SUBNET_C_ID}"],securityGroups=["${APP_SG_ID}"],assignPublicIp=DISABLED}" --service-registries "registryArn=${WORLD_REGISTRY_ARN},containerName=helloworld-world" # Nginxサービス作成 aws ecs create-service --cluster ${CLUSTER_NAME} --service-name nginx-service --task-definition helloworld-nginx:${TASK_NGINX_REVISION} --desired-count 1 --launch-type "FARGATE" --network-configuration "awsvpcConfiguration={subnets=["${PRIVATE_SUBNET_A_ID}","${PRIVATE_SUBNET_C_ID}"],securityGroups=["${WEB_SG_ID}"],assignPublicIp=DISABLED}" --service-registries "registryArn=${NGINX_REGISTRY_ARN},containerName=helloworld-nginx" --load-balancers "targetGroupArn=${TARGET_GROUP_ARN},containerName=helloworld-nginx,containerPort=80"
以下のコマンドを実行する。
open http://$(aws elbv2 describe-load-balancers --load-balancer-arns ${LB_ARN} | jq -r '.LoadBalancers[0].DNSName')/hello/webresources/hello
表示された画面に「Hello World!」が表示されるか確認してください。 環境構築後、ヘルスチェックが通すまでに時間がかかるので、時間をおいてから確認してください。
最後に構築した環境をお片づけしましょう。
# ECSサービスの起動タスク数を0に更新 aws ecs update-service --cluster fargate-helloworld --service nginx-service --desired-count 0 aws ecs update-service --cluster fargate-helloworld --service hello-service --desired-count 0 aws ecs update-service --cluster fargate-helloworld --service world-service --desired-count 0 # ECSサービスを削除 aws ecs delete-service --cluster fargate-helloworld --service nginx-service aws ecs delete-service --cluster fargate-helloworld --service hello-service aws ecs delete-service --cluster fargate-helloworld --service world-service # ECSクラスタを削除 aws ecs delete-cluster --cluster fargate-helloworld # サービスディスカバリのサービス名を削除 aws servicediscovery delete-service --id ${HELLO_SERVICE_ID} aws servicediscovery delete-service --id ${WORLD_SERVICE_ID} aws servicediscovery delete-service --id ${NGINX_SERVICE_ID} # サービスディスカバリのネームスペースを削除 aws servicediscovery delete-namespace --id ${NAMESPACE_ID} # ロードバランサを削除 aws elbv2 delete-load-balancer --load-balancer-arn ${LB_ARN} # ターゲットグループを削除 aws elbv2 delete-target-group --target-group-arn ${TARGET_GROUP_ARN} # NATゲートウェイを削除 aws ec2 delete-nat-gateway --nat-gateway-id ${NAT_GATEWAY_ID} # ルートテーブルを削除 aws ec2 delete-route --route-table-id ${PRIVATE_ROUTE_TABLE_ID} --destination-cidr-block 0.0.0.0/0 aws ec2 disassociate-route-table --association-id ${PRIVATE_A_ASSOCITATE_ID} aws ec2 disassociate-route-table --association-id ${PRIVATE_C_ASSOCITATE_ID} aws ec2 delete-route-table --route-table-id ${PRIVATE_ROUTE_TABLE_ID} aws ec2 delete-route --route-table-id ${PUBLIC_ROUTE_TABLE_ID} --destination-cidr-block 0.0.0.0/0 aws ec2 disassociate-route-table --association-id ${PUBLIC_A_ASSOCITATE_ID} aws ec2 disassociate-route-table --association-id ${PUBLIC_C_ASSOCITATE_ID} aws ec2 delete-route-table --route-table-id ${PUBLIC_ROUTE_TABLE_ID} # インターネットゲートウェイをデタッチ aws ec2 detach-internet-gateway --internet-gateway-id ${IGW_ID} --vpc-id ${VPC_ID} # Elastic IPを解放 aws ec2 release-address --allocation-id ${ALLOCATION_ID} # サブネットを削除 aws ec2 delete-subnet --subnet-id ${PUBLIC_SUBNET_A_ID} aws ec2 delete-subnet --subnet-id ${PUBLIC_SUBNET_C_ID} aws ec2 delete-subnet --subnet-id ${PRIVATE_SUBNET_A_ID} aws ec2 delete-subnet --subnet-id ${PRIVATE_SUBNET_C_ID} # セキュリティグループを削除 aws ec2 delete-security-group --group-id ${WEB_SG_ID} aws ec2 delete-security-group --group-id ${APP_SG_ID} # VPCを削除 aws ec2 delete-vpc --vpc-id ${VPC_ID}
AWS CLIのみでFargateを使った環境構築を行いました。 今回はオートスケーリングなどの設定を行いませんでしたが、負荷に応じてタスクごとにスケールが可能なので、 コンピューティングリソースを有効に使いつつ、柔軟に対応ができそうです。 サービスごとにアプリケーションの更新が可能なので、他のサービスに影響を与えずにデプロイが可能になります。
もし、マイクロサービスに手をつけたいけど、インフラ環境をどうすればいいか悩んでいる方は、試してみてください。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/create-service-discovery.html
どうも、小野です。
今回は、開発で意外と問題になってくるDBのバージョン管理についてのお話です。
みなさんは、どのように管理していますか? DBは開発工程前に予め設計するのですが、やはり変更はつきものです。 しかもDBはアプリケーションの核になっているので、構成が変わるとエラーが発生したり、随時更新していかないと環境によって構成が異なったりします。
私も周知漏れなどで、自分のところでは動くけど、他の環境では動かないなどは日常茶飯事でした。 ちゃんと管理しろって話ですが、エンジニアの人数も少なかったので、管理コストに比べたら、トライアルアンドエラーの方が良かったりします(汗 ただし、エラーログに「〜の列が見つかりません。」のような、エラーのトレースができることが前提ですね。
現状の管理方法における問題点を挙げ、改善方法についてお話します。
続きを読むアジアカップもW杯のような盛り上がりを見せて欲しいと思っている、小野です。
プロジェクトを進めていく中で、プロジェクト(タスク)管理は必要になってきます。 管理方法については、十人十色で企業によってやり方は異なります。弊社ではタスク管理方法にTrello(トレロ)を採用しています。
今回は、Trelloを使ったタスク管理方法についてご紹介したいと思います。
無料で利用できるWebサービスなので、サーバ管理も不要です。Googleアカウントを持っていれば、アカウント登録が簡単です。
Trelloを採用したのは、以下の理由が挙げられます。
今までにRedmineを使いましたが、Trelloに比べ入力項目が多く、タスクの更新を行うための手順が多いので途中で断念しました。 進捗を変更するだけでも、詳細を開いて、進捗を変更して、保存といった操作が必要です。 Trelloであれば、ドラッグ&ドロップのみで変更できます。
ボードはプロジェクト単位で作成するのが管理しやすいです。(〜アプリ開発など)
作成する際に、ボード名と公開範囲を決めます。作成するとホーム画面にボードが表示されます。
作成したボードを開いて、リストを以下の5つ用意します。このリストで進捗を管理します。
横スクロールの必要がない範囲で収めると使いやすくなると思います。 ちなみに今使っている端末はMacbookAirの13インチで、解像度は1440×900です。
やるかどうかわからないタスクや、今作業するタイミングではないタスクなどを置きます。 定期的に棚卸ししていかないと、溜まっていくので注意が必要です。
やるべきタスクを置きます。新たにカードを作成するときはここに作成します。
作業中のタスクを置きます。 担当者がTodoからDoingにカードを移して、作業を開始します。
担当者が作業を完了したら置きます。
第三者への確認が必要なタスクを置きます。 アプリケーションの動作確認やレビューなどです。
まずはタスク名と後述するラベルだけ設定しておきます。 他に必要があれば、タスクの詳細、担当するメンバー、期限などを設定します。
タスクを行う際の優先順位はカードの並び順で設定します。 以下の図のように、上が高く下が低いとイメージです。
同じプロジェクトでも、タスクによってリリースするバージョンが異なる場合があります。その場合にラベルを使います。 Trelloのフィルタリング機能によるラベルの絞り込みができるので、特定バージョンのカードのみを表示することも可能です。
ボード上に表示されるのは、ラベルの色のみなので、その色がどのバージョンなのかわかりづらいです。 そこで後述するプラグインを利用することで、ラベル名も表示できるようになります。 以下の画像は、Chrome拡張機能を追加した場合のものです。
カードを移動する際にメンバーをアサインすると、担当者にデスクトップ通知されるので気付きやすくなります。
前にも申し上げましたが、Trelloはアドオンを追加できます。ただし、無料アカウントの場合だと、1つのアドオンまでしか追加できません。 2つ以上利用したい場合は、有料アカウントになる必要があります。
ChromeでもTrello向けの拡張機能がありますので、2つほどご紹介します。
カードにラベル名称を表示します。
カードにNoを表示します。 Gitのブランチ名などにカードNoを入れてあげると、カードとソースバージョンの紐付けが行いやすくなります。
弊社で行なっているTrelloを使ったタスク管理方法は一例に過ぎません。大事なのは、自分たちにとって最適な手法を見つけることです。 ぜひ、タスク管理にTrelloを採用してみてはいかがでしょうか?
どうも、小野です。
先日、JJUG(Japan Java User Group)が主催するJJUG CCC 2018 Fallに参加してきました。 今回はその様子をお伝えしていきます。 本記事では、セッションの内容は書きません。内容について知りたい方は、 記事の最後のリンクを確認してください。
写真を全くと言っていいほど、撮っていないのでイメージしにくいとは思いますが、 予めご了承くださいm( )m
(余談ですが、イベント名にFallとありますが、時期的にWinterですね。)
開催場所は新宿ベルサールグランドカンファレンスセンターでした。 JR新宿駅西口から徒歩15分程度とちょっと遠いんですね。
他の企業主催のイベントはわかりませんが、JJUGのイベントは100%ボランティアスタッフです。 ボランティアスタッフのみなさんには本当に感謝しています。
お子さんがいる家庭で、休日のイベント参加は難しいものがあります。 なんと、本イベントでは託児所が設けられています。 安心して子連れで参加できますね。 次回、参加する機会があったら利用したいと思います。
コミュニティ主催でありながら、参加費が無料です。 しかも、ランチセッションに参加すると、お弁当も配布されます。 場所代、お弁当代だけ考えても結構な金額いくと思いますが、 そこを無料でやっていただけるのはとても助かるし、感謝しています。 ただし、全てのセッション後は懇親会があるのですが、これに参加する場合は1000円かかります。 でも、1000円以上の価値はありましたね。 料理は、LINEの恒例?の寿司が提供されていたみたいです。LINE DEVELOPER DAYでもありました。 (残念ながら、私は次の日3時起きだったので参加できませんでした。。。)
私も普段AWSを利用しており、身近に感じる内容でした。 ECSについては前々から興味があり、Java、SpringBootでどのように構築されているか興味がありました。
セッションの内容はJavaの内容よりもECSよりの話でした。
あと、今だとFargateが東京リージョンにあるので、なぜ使わないのかなと思っていたのですが、 FargateにはECSに比べコストがかかるというデメリットがため採用しなかったそうです。 確かに、コストがかかるという記事はよく見かけます。
まずはECSから使ってみようと思います。
よくQiitaでお世話になっているopengl-8080さんのセッションです。
Java9からモジュールシステムの導入により、新たな問題の解決方法を説明してくださいました。 相変わらず、図を使い込みわかりやすい資料でした。 今、業務ではJava8を利用していおり、モジュールシステムについてはモヤっとしか理解していませんが、 今後、Javaのアップデートした際には、本資料を活用したいと思います。
Java8から導入されたStream APIですが、個人的に今更感はあったので小ネタでを挟んでくるのかなと期待していましたが、 入門と書いてある通り、初心者向けの内容でした。
業務でStreamAPIを使っているので、既知の内容でしたが、1つだけ勉強になったことがあります。 それは、StreamAPIを使ったことがある人だったら、一度は躓く例外の取り扱いについてです。 登壇者である櫻庭さんの回答は「Either」を利用するといいそうです。
ちなみに私は、Stream処理内でRuntimeExceptionをスローし、Stream処理外でCatchするようにしています。
寺田さんは話の冒頭に、Microsoftに在籍していながらも、自分は「Javaの人間」とアピールしていたのがとても印象的でした。
さて、本セッションは最近注目されているkubernates(K8s)のお話です。
kubernatesはマイクロサービスの管理を楽になるなど得られるメリットは大きいのですが、 その反面、覚えることが多く安易に採用しない方がいいとのことでした。
本番運用での採用は、まだ難しいかもしれないですね。
コミュニティ主催であり、お弁当が配布されるなら参加料は有料でもいいのかなと思いました。 無料でここまでやれているのが凄いと思います。
本カンファレンスは、イベント名のとおりJavaを中心とした内容になっています。 初心者から上級者までJavaに興味がある人でしたら楽しめるイベントだと思います。 年に2回開催されているので、興味があったら参加してみてください。
セッションの資料が以下にまとめられています。 興味のある方はぜひ。
どうも、小野です。
先日、LINEが主催するエンジニア向けカンファレンス『LINE DEVELOPER DAY 2018』に参加してきました。 過去にも何度か開催されていたのですが、情報収集力が足りず、あったことすら知りませんでした。無念。。 今年の開催に関しては、Twitterでフォロー中の ちょまど(@chomado) さんのツイートを見て知りました。 Twitterは重要ですね。
今年のテーマは「NEXT LINE」です。LINEが次に目指すものは大きく分けて2つあります。
続きを読む