IAMポリシーで自分の所有リソース以外の操作を制限する

AWS IAM
2017年3月13日
YusukeKarakita

こんにちは。百木田です。

先日、こんなことがありましたね。
Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。

人間が関わっている以上、人的ミスはどうしても避けられないので工夫してミスを減らしましょうという教訓ですね。

今回のブログでは新しい技術は使ってないですが、そんなニュースもあったので人的なミス防止に関連する共有です。

AWSを導入している企業であればAWSの機能や技術を検証するために、
サービス提供しているアカウントから分離された検証用アカウントを利用している場合も多いかと思います。
本番環境ではユーザーに適切な権限を付与し、事故を防止していることと思いますが、検証環境では事故の影響が小さかったり、検証するために必要な権限が多い or 不明確であったりということもあり、それぞれのIAMユーザにAdministrator権限に近い権限を付与しているといったこともあるかと思います。

自分が操作しているリソースのすぐとなりに他の人が検証で使用しているリソースがある場合、そういった権限を持っていれば少しコンソール操作をしくじっただけでリソースが消え、両者、冷や汗状態です。

基本的に私はしくじる側の人間だと思っているので、そんな環境でコンソール操作するのはめちゃくちゃイヤなわけで、寝ぼけながら操作しても自分以外の管理するリソースを操作すること無いようにしたかったわけです。
（入社した月にそんなことやらかした時にはもうあれですね。）

今回はEC2インスタンスの[開始/停止/再起動/削除]操作を制限するポリシーを設定します。

設定方法

操作制限を書いたIAMポリシーを作成
自分の使用しているIAMユーザーに対して作成したIAMポリシーを付与
自分が管理しているEC2インスタンスにタグ付け
　　Ownerというタグネームに対して自分のIAMユーザー名を設定

作成したIAMポリシーは以下です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "ec2:RebootInstances",
                "ec2:StartInstances",
                "ec2:StopInstances",
                "ec2:TerminateInstances"
            ],
            "Condition": {
                "StringNotEquals": {
                    "ec2:ResourceTag/Owner": "${aws:username}"
                }
            },
            "Resource": [
                "*"
            ]
        }
    ]
}

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Deny",

"Action": [

"ec2:RebootInstances",

"ec2:StartInstances",

"ec2:StopInstances",

"ec2:TerminateInstances"

"Condition": {

"StringNotEquals": {

"ec2:ResourceTag/Owner": "${aws:username}"

}

"Resource": [

"*"

]

}

]

}

「操作するEC2インスタンスのOwnerタグと、現在使用しているIAMユーザー名が異なる場合はActionの操作を拒否」という内容です。
また、どのユーザーでも同じポリシーが使用できるようにユーザー名の部分は変数を指定しています。

試してみる

Ownerタグに自分のIAMユーザー名が設定されているインスタンスは操作できます。

そうでないリソースは操作時にエラーが出るようになりました。

CLIで試しても同様にエラーとなります。

$ aws ec2 stop-instances --instance-id=i-02xxxxxxxxxxxxxxx

An error occurred (UnauthorizedOperation) when calling the StopInstances operation: 
You are not authorized to perform this operation. Encoded authorization failure message:.....

$ aws ec2 stop-instances --instance-id=i-02xxxxxxxxxxxxxxx

An error occurred (UnauthorizedOperation) when calling the StopInstances operation:

You are not authorized to perform this operation. Encoded authorization failure message:.....

まとめ

権限を少し工夫するだけで安心して作業できるようになりました。
現在お使いのIAMユーザーにIAM操作権限が付与されていれば今からでも手軽に設定できると思いますので実施してみてください。

Serverless Frameworkでバイナリデータを処理するアーキテクチャを構築したかった

こんにちは。AWSチーム百木田です。

サーバーレス、してますか？

この度、「クライアントから画像を受け取ったらLambdaでその画像の処理をする」ということがしたく、受け取る部分を昨年11月に発表されてできるようになったAPI Gatewayでのバイナリデータサポートを利用してやってみました。
そして何かツールを使って楽にデプロイしたいと思い、今回はServerless Frameworkを利用してやってみることにしました。

環境

OS（VM）: CentOS Linux release 7.2.1511 (Core)
Node Version: 7.5.0
Serverless Version: 1.8.0

準備

Serverlessの定義ファイル作成

Serverlessのセットアップについては省略させていただきます。’serverless’コマンドが実行できる前提です。

‘serverless.yml’を作成します。

定義している内容は以下です。

LambdaからS3にデータを置くためのIAMロールを定義
POSTで受けてLambda処理を行うAPI Gatewayを定義
画像を保存するS3 Bucketを定義

注）S3バケット名の部分は変更してください。

service: saveImage

provider:
  name: aws
  runtime: python2.7

  stage: dev
  region: ap-northeast-1

  iamRoleStatements:
    - Effect: "Allow"
      Action:
        - "s3:Put*"
      Resource:
        Fn::Join:
          - ""
          - - "arn:aws:s3:::${self:custom.bucketName}/*"
  environment:
    'bucketName': '${self:custom.bucketName}'

# バケット名を変数として宣言
custom:
  bucketName: BUCKET_NAME

# APIゲートウェイの設定を定義
functions:
  save:
    handler: handler.handler
    events:
      - http:
          path: save
          method: post

# S3バケットを定義
resources:
  Resources:
    myImageBucket:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: ${self:custom.bucketName}
  Outputs:
    RdsLogs:
      Description: "Bucket for images"
      Value:
        Ref: "myImageBucket"

service: saveImage

provider:

name: aws

runtime: python2.7

stage: dev

region: ap-northeast-1

iamRoleStatements:

- Effect: "Allow"

Action:

- "s3:Put*"

Resource:

Fn::Join:

- ""

- - "arn:aws:s3:::${self:custom.bucketName}/*"

environment:

'bucketName': '${self:custom.bucketName}'

# バケット名を変数として宣言

custom:

bucketName: BUCKET_NAME

# APIゲートウェイの設定を定義

functions:

save:

handler: handler.handler

events:

- http:

path: save

method: post

# S3バケットを定義

resources:

Resources:

myImageBucket:

Type: AWS::S3::Bucket

Properties:

BucketName: ${self:custom.bucketName}

Outputs:

RdsLogs:

Description: "Bucket for images"

Value:

Ref: "myImageBucket"

タイトルで「してみた」にできなかったのには理由があり、残念なことに肝心のバイナリデータサポートの設定は現時点でServerlessでは対応していませんでした。そのためプラグインを使用するか他の方法で設定する必要があります。今回は泥臭くデプロイ後にマネジメントコンソールで設定することにします。

Lambda実行コードを作成

Lambdaでの処理は受け取った画像データをS3にアップロードするという簡単なものにしました。

# -*- coding: utf-8 -*-

import os
import logging
import datetime
import base64
import boto3

logger = logging.getLogger()
logger.setLevel(logging.INFO)

s3 = boto3.client('s3')
BUCKET_NAME = os.environ['bucketName']

def handler(event, context):
    todaydetail = datetime.datetime.today()
    FILENAME = (todaydetail.strftime("%Y%m%d-%H%M%S") + '.jpg')

    dec_save(data = event['body'], FILENAME = FILENAME)
    s3.upload_file('/tmp/' + FILENAME, BUCKET_NAME, FILENAME)
    os.remove('/tmp/' + FILENAME)

    responce = {
         "statusCode": 200,
         "body": "Upload Sccessful \n"
    }
    logger.info(responce)
    return responce

# ------------ バイナリデータをデコードして/tmpに保存する -------------
def dec_save(data, FILENAME):
    dec_data = base64.b64decode(data)
    f = open('/tmp/' + FILENAME,'w')
    f.write(dec_data)
    f.close()
    return

# -*- coding: utf-8 -*-

import os

import logging

import datetime

import base64

import boto3

logger = logging.getLogger()

logger.setLevel(logging.INFO)

s3 = boto3.client('s3')

BUCKET_NAME = os.environ['bucketName']

def handler(event, context):

todaydetail = datetime.datetime.today()

FILENAME = (todaydetail.strftime("%Y%m%d-%H%M%S") + '.jpg')

dec_save(data = event['body'], FILENAME = FILENAME)

s3.upload_file('/tmp/' + FILENAME, BUCKET_NAME, FILENAME)

os.remove('/tmp/' + FILENAME)

responce = {

"statusCode": 200,

"body": "Upload Sccessful \n"

}

logger.info(responce)

return responce

# ------------ バイナリデータをデコードして/tmpに保存する -------------

def dec_save(data, FILENAME):

dec_data = base64.b64decode(data)

f = open('/tmp/' + FILENAME,'w')

f.write(dec_data)

f.close()

return

ここではデータを’/tmp’に一度保存していますがもちろん受け取ってそのままS3にあげちゃってもOKです。

デプロイ

$ serverless deploy

1 2	$ serverless deploy

バイナリデータサポートを設定

‘serverless deploy’するとS3バケットやAPI Gateway、Lambdaといったリソースが作成されているかと思います。その後、API Gatewayのマネジメントコンソールからバイナリサポートのバイナリメディアタイプに’image/jpg’などPOSTで受ける’Content-Type’に合わせた値を設定します。

バイナリサポート設定後のAPIをデプロイするために再度’serverless deploy’をします。再度デプロイしても手動で設定したバイナリサポートの設定は消えません。

これで設定は完了です。

実際に試してみる

お手軽に試すにはローカル端末から以下のコマンドを実行します。

$ curl -X POST \
-H "Accept: image/jpg" \
-H "Content-Type: image/jpg" \
--data-binary "@image.jpg" \
"https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/save"

$ curl -X POST \

-H "Accept: image/jpg" \

-H "Content-Type: image/jpg" \

--data-binary "@image.jpg" \

"https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/save"

‘Upload Sccessful’が表示され、S3の指定バケットにファイルが保存されています。

まとめ

今回はServerless Frameworkを利用しましたが他にもSAMやApex、Lamveryなどツールが出ているので今後試していきたいと思います。Serverless Frameworkも順次アップデートされているので今後楽しみです。

ありがとうございました。

Kinesis FirehoseがS3に出力したファイルを１レコードずつ読み込む

AWS Python
2017年3月2日
鹿倉秀太

皆々様、お久しぶりのブログ更新です。

Kinesis FirehoseがS3に出力したファイルをPythonでモニャモニャしたいと思っていたところ以下のことでつまづいてしまいました。

１つのファイルに複数レコード出力されている場合、改行(区切り文字)がなく１レコードずつ読み込めない！

改行とか入っていて、１行ずつ読み込むんだろう・・・みたいな想像を勝手にしていたのでちょっとつまずいてしまいました。

AWSのデモデータをKinesisFirehoseに流すと実際のファイルはの中身は下記のようになります。

{"ticker_symbol":"TGH","sector":"FINANCIAL","change":-0.6,"price":65.43}{"ticker_symbol":"JYB","sector":"HEALTHCARE","change":-2.27,"price":42.95}{"ticker_symbol":"WAS","sector":"RETAIL","change":0.53,"price":13.04}{"ticker_symbol":"NGC","sector":"HEALTHCARE","change":0.32,"price":5.41}

1	{"ticker_symbol":"TGH","sector":"FINANCIAL","change":-0.6,"price":65.43}{"ticker_symbol":"JYB","sector":"HEALTHCARE","change":-2.27,"price":42.95}{"ticker_symbol":"WAS","sector":"RETAIL","change":0.53,"price":13.04}{"ticker_symbol":"NGC","sector":"HEALTHCARE","change":0.32,"price":5.41}

こういったJsonストリームデータをPythonで処理する時ってどうしたらいいんだろうと調べていたらjsonライブラリにJSONDecoderというのがあるのを見つけました。

下記サンプルです。

import json
import boto3

s3 = boto3.resource('s3')
bucket = s3.Bucket('backet name')
obj = bucket.Object('key name')
obj = obj.get()
json_stream = obj['Body'].read()

decoder = json.JSONDecoder()

while len(json_stream) > 0:

    record, index = decoder.raw_decode(json_stream)
    json_stream = json_stream[index:]
    print record

import json

import boto3

s3 = boto3.resource('s3')

bucket = s3.Bucket('backet name')

obj = bucket.Object('key name')

obj = obj.get()

json_stream = obj['Body'].read()

decoder = json.JSONDecoder()

while len(json_stream) > 0:

record, index = decoder.raw_decode(json_stream)

json_stream = json_stream[index:]

print record

これを実行すると下記のように出力されました〜。

{"ticker_symbol":"TGH","sector":"FINANCIAL","change":-0.6,"price":65.43}
{"ticker_symbol":"JYB","sector":"HEALTHCARE","change":-2.27,"price":42.95}
{"ticker_symbol":"WAS","sector":"RETAIL","change":0.53,"price":13.04}
{"ticker_symbol":"NGC","sector":"HEALTHCARE","change":0.32,"price":5.41}

{"ticker_symbol":"TGH","sector":"FINANCIAL","change":-0.6,"price":65.43}

{"ticker_symbol":"JYB","sector":"HEALTHCARE","change":-2.27,"price":42.95}

{"ticker_symbol":"WAS","sector":"RETAIL","change":0.53,"price":13.04}

{"ticker_symbol":"NGC","sector":"HEALTHCARE","change":0.32,"price":5.41}

そうです、この記事・・・単にストリームデータの読み込み方についての記事です！KinesisFirehoseは完全に引きです！

でもストリームデータを扱うことは個人的には今後も増えそうなので今回調べておいてよかったです！

ではでは〜。

MBSハッカソン2017　参加レポート

イベント
2017年2月15日
YusukeKarakita

はじめまして！AWSチームの百木田（からきた）です。２月からハンズラボに入社しました。
前職はインフラエンジニアとして、主にAWSを使ったインフラ環境の設計・構築・運用を行っていました。
また、それ以前は大学でやり投げを頑張っていました。やり投げる系のエンジニアです。

よろしくお願いします。これからエンジニアブログ頑張ります。

初回は技術系のお話ではなく参加レポートです。
２月１１日に大阪で開催されたMBS主催のMBSハッカソンに参加してきました。

入社して最初の大仕事。気合入れて大阪へ。

弊社、昨年に引き続き協賛させていただいておりました。

当日の発表によると参加者数は131名！エンジニアだけでなく、プランナー、デザイナーも結構いました。
弊社からは５名。協賛とは関係なく一般応募で戦います。オールエンジニアです。
このMBSハッカソン、参加者全員がHackできるというわけではなく、今回のアイデアソンで８組に選ばれて初めて来週開催されるハッカソンに出場できるというもの。
1組5-7人なので決勝まですすめる確率は30-40%というなかなかな狭き門。

今回はアイデアソンの流れや思ったことを中心に書いてみようと思います。

会場入り

会場についたらまず着席します。チーム参加・個人参加関係なくバラバラに座るように言われ、各テーブルはじめまして状態になります。

スタート！

まずはじめにゲスト紹介があり、その後API提供していただいた各社からそれぞれのサービスについてご説明いただきました。
個人的にはcoineyというサービスがすごいなあと思いました。

アイスブレイク　「うろ覚えお絵かき」

自分の知っているテクノロジーについて事例なども含めチームメンバーに絵で説明します。

好きなMBSのコンテンツを共有

このハッカソン、テーマとして「今が旬の6つのテクノロジーを使ってMBSの番組・イベントをもっと面白くするITサービスを開発しよう！」ということを掲げているので、まずはMBSのコンテンツについてチーム内で共有し理解を深めます。

まずは好きなテレビ・ラジオ番組（のコーナー）、イベント、Webコンテンツなどを各個人がリストアップ。
それをチーム内で出し合い

好きな番組
あまり他の人が出さなそうな番組

に分けてランク付け。
↑ここでチーム内で番組に関しての紹介やディスカッションをし合うことでそれぞれの番組に対する理解が深まる

ちなみに私は関東に住んでいるのでMBSを見る機会はほぼなく、情熱大陸しか知らなかったため、チームメンバーの方にそれぞれどんな内容か丁寧に説明していただきました。（ありがとうございました！）

コンテンツとテクノロジーを好きなように組み合わせてアイデアを出していく。

今回テクノロジーとしてテーマとなっていたものは以下の６つです。

人工知能（AI）
仮想現実（VR／AR）
位置情報
IoT
ロボット
フィンテック

これらとMBSのコンテンツを組み合わせてアイデアを放出します。
組み合わせの例としては

「情熱大陸」✕「フィンテック」　とか、
「ちちんぷいぷい（MBSの情報番組）」✕「人工知能」とか。

とにかく組み合わせてからどんなものができるか考える。5秒考えて思い浮かばなかったら次！
というように頭の中のなにか溜まったものをどばどばと放出していくような作業。

私、とにかくこれが楽しくて快感でした。
この段階では、どう実現するの？とか、誰得よ？とか言わない約束。だめ、絶対。

こうして１人４つほどアイデアを出し、チーム内で紹介し合います。
ここもとてもおもしろかったです。自分以外の人の、しかも別業界の人のリミッターが外れたアイデアなんて聞ける機会はそうそう無いですからね。

お披露目会

その後、自分が出した４つのアイデアの中から本命として１つ絞り込み、１枚の画用紙にまとめて参加者全員でお披露目会です。
いいね！と思ったアイデアにシールを貼っていきます。うろ覚えですが多い人で40枚以上、いわゆる「モテアイデア」というらしい。ちなみに私はシール６枚・・・。認定・非モテアイデアでした。

チームビルディング

お披露目会の後はいよいよチームビルディングです。自分のアイデアとシールの枚数を提げてナンパし合いされ合います。
自分のアイデアと近い人と組んだり、面白いアイデアを持っている人と組んだり、そうして徐々にチームが組まれていきます。
そんな中、周りでチームビルドをしている人たちを見ていると何やらみなさん困っている様子。

「深刻なエンジニア不足！」

エンジニア、引っ張りだこでした。
いくらプランナーやデザイナーがチームにいて夢を語り合ってもエンジニアがいないと実現は難しい。
「Engineer First」
ファシリテータの伴野さんが何度かおっしゃっていました。アイデアソン・ハッカソンではものを作れる人が一番偉いですよーと。
そんなエンジニア不足が嘆かれるなか、我々のチームは全員エンジニアのチームで挑むことになりました。
この時は思っていました。勝つる！

チーム内でアイデアを育て、発表

チームビルドしてからチーム内でアイデアの発散→具体化→収束を２時間半ほどかけて行い、その後チームごとに舞台で発表です。
どのチームもコントを入れたりして工夫した発表。
そうして全25チームによる発表が終わり、審査員によるハッカソン進出チームが発表されました。

・・・負けました。

敗因（自己分析）

エンジニアしかいないのでアイデアを育てる段階で、フィージビリティとか工数ありきの考えになっていた。
プランナーのようなエンジニア以外の目線で考えるメンバーがいないのでいまいち斬新性に欠けたものになった。
デザイナーがいないので発表資料が残念。

まとめ

アイデアソン・ハッカソンではEngineer FirstだがEngineer Onlyが強いということでもないということを身をもって経験しました。
バランス大事。
また、運営面の話ですがチームビルド前の発散の段階ではそれぞれの作業時間がとても短く区切られていて（長くても5分とか）、深く考える時間を与えない、パっと浮かんだアイデアを大事にする、みたいな部分はなるほど勉強になりました。
こうやって自分の脳ミソをフル回転させて発散させるという作業をすることで、凝り固まった頭が少し柔らかくなる気がしました。
あと、普段接しない人たちとリミッターを外して意見を交わすのって大事だなと思いました。
これからもアイデアソンに参加し、こういった機会を積極的に持ちたいです。

負けてとっても悔しかったので再挑戦したいと思います！

ありがとうございました。

新卒1人仮想プロジェクト完了しました

新人研修
2017年2月3日
MurakamiKazuo

はじめに

ハンズラボの新Macbook Proを手にした新卒の村上です。新卒研修のメインである1人仮想プロジェクトが12/9に完了したので忘れないうちに書いておきます。

えっ!?この時期に新卒研修？

と思うのが当然ですが、実は私が大学院を中退し10月中旬に入社して1人で仮想プロジェクトを行ったというわけです（さみしっ）。私も入社前に今年度の新卒の研修記事を参考にして入社したので特にハンズラボに入社を考えている方々の参考になれば嬉しいです。

仮想プロジェクトの概要

仮想プロジェクトといっても、今年度の新卒４人で行った仮想プロジェクトもそうかもしれませんが、作るものに関して具体的な要件があったわけではないです。
「何か世の中のためになりそうなものをつくって。利益出しても良いからw」
といった感じだったので、自分が欲しいサービスを作れるというわけです!（もちろん、みんなにも使ってもらいたい）。

うーん、何を作ろうか…　技術的に簡単すぎても研修にならないし、難しすぎても終わらないし。何より1人だし…

ちなみにスケジュール見積もりは以下のようになりました。

企画：７日
プロトタイピンング：３日
設計：２日
実装：１６日
テスト：３日
リリース：２日

何をつくったのか

企画発表スライド

企画の段階で社員の方々に発表した際の資料です↓（アニメーションは動かない）

新卒仮想プロジェクト（工具共有サービス） from Kazuo Murakami

貸し借りサービスの難しさ

スライドにもありますが当初5つの案があり、Slackで社員の方々に投票を呼びかけ、その結果を踏まえて工具共有アプリを作ることにしました。既存競合サービスを考えると、「メルカリアッテ」や「Anytimes」になると思います。それらのサービスと違う点は、アイテム領域を工具のみに絞っているところと、売買でなく貸し借りをサポートするサービスであるという点です。

特に考える必要があったのは、貸し借りサービスはメルカリアッテのような売買サービスとは違い、売って終わりではないという所です。スライド中で二つの壁という表記がありますが、

レンタル中のレンタル品の劣化
借主がレンタル品を返さない

ということを考慮する必要がありました。1つ目については工具の劣化のしずらさでカバーできると思い、２つ目については質代制度というものを考えました。
これは貸主が借主がレンタル品を返さない場合または大きく劣化した場合に備えて、あらかじめ貸主が借主からレンタル代に加えて質代としてお金を預かっておくという制度です。

とテキトーなことを言いましたが、この制度がうまくいくかどうかはわかりません。結局開発に入ってからはサービスが上手くいくかどうかを考える余裕はなく、開発に専念していたため今でもベストな解は導けてません。運用側で保障することを考えればもっと他に手はあるかもしれません。この辺の難しさが貸し借りサービスが（私の知る限り）ほとんど存在しない理由ではないかと1人考えていました。

具体的なサービスの流れは上記スライドにもありますが、プロトタイピングの時点でAdobe XDを使ってモックを作りましたのでよければ見てください（サイドナビゲートバーの項目を選択する際に面倒があります）。

どのようにつくったのか

私の技術レベルなのですが、情報系の学科出身なので基本情報技術者試験程度の知識はありました。Web開発については入社前にDjangoの参考書を一読していたという程度で自分で企画してサービスを構築するというのは初めてでした。

開発環境

Python 3.4
Django 1.8, Django Channels
Bootstrap3
sqlite

DjangoとはPython用のWebフレームワークです。RubyでいうRuby on railsのようなものです。他にもPython用フレームワークはFlaskやPyramidなどがありますが、最も多くのユーザに使われているものがDjangoです。フレームワークを語るときによくMVCモデルと耳にしますが、DjangoだとMTV（Model, Template, View）モデルがそれに対応します（厳密な定義はないですが）。Djangoはユーザ管理機能（ユーザ登録、ログインから、パスワード変更など）の多くの部分のロジックを用意してくれているのでテンプレート(html)を書くだけでそれらを実現できたりします。また、モデル定義からフォームを作成することができるので、html内でformタグやinputタグなどを使わずにフォームを作成することもできます。他のWebフレームワークをほとんど使ったことがないので比較ができませんが、とても使いやすくお気に入りです。
ちなみに社内には業務でDjangoを使っている人はおらず、もしDjangoエンジニアで弊社に興味がある方がいれば、私と共にDjango（Python）勢力を拡大していきましょう！！　現状は謎テクノロジー、ユニケージ(Bash)とPHPで書いている方が多いです。

機能一覧

ユーザ登録、ログイン（facebookログイン含む）、ログアウト、パスワード変更とリセット
アイテム（工具）のCRUD機能
アイテムへの応募
チャット
評価

特に苦労した点は、UIとチャットです。UIはBootstrapがなければとても間に合いませんでしたし、チャットはDjango Channels(Websocketを実装するためのライブラリ)のおかげでなんとか実現できました。
当初評価機能まで考えていたのですが、時間的に間に合わず断念しました。

つくったアプリの画面

ログイン画面

ホーム画面

チャット画面

今後はチャットのUIの改良　また、評価機能、検索機能を付け足して社内だけでも公開して意見をもらいたいなと思っています。

おわりに

上記ではサービス概要や開発環境について書きました。もう一度一人で仮想プロジェクトをやるとすれば、今回は実装量として一人でやるには多かったのでもう少しコンパクトですぐにみんなに使ってもらえるようなアプリを作りたいです。
研修の1ヶ月半ほどの間、ほとんど毎日先輩社員のTさんと人事担当のAさんに進捗を報告する時間とプロジェクトが遅延した場合の対処法を教えていただいたりして、プロジェクトを円滑に進められるよう助けていただきました。また、仮想プロジェクト以外にも社会人マナー、東急グループ内のハンズラボの位置付け、プロジェクト管理、ソフトウェアテストについても教えていただきました。この場を借りてお礼を言いたいと思います。ありがとうございました。現在、私は既にチームに配属され日々、PHP、bash、AWSの勉強をしながら業務にあたっています。

12 3 4 5...10...»最後 »