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

iOSDC Japan 2017にブースを出展してきました

iOS イベント
2017年9月19日
Miyu Watanabe

こんにちは！POSチームの渡邉です。
新卒として2017年春に入社し、7月からPOSチームでえっちらおっちら頑張ってます。
頑張ってブログも書いていきます！よろしくお願いします！

さて、iOSDC Japan 2017、盛り上がりましたね〜！

弊社はダイヤモンドスポンサー、Tシャツスポンサー、ブース出展、エンジニア2名登壇と
気合が入ったイベントになりました！

登壇した黒岩の資料・駒場の資料も合わせてご覧ください。
今回はブース出展にスポットを当てて書いていきますよー！

ブースの様子

イベントといえば、ブース出展といえば、
やっぱりノベルティグッズですよね！
ブースでなにか配っていたらとりあえずもらっちゃうのは私だけではないはず。

弊社はロゴステッカーと公式キャラクター「らぼたん」のステッカー、

そして新しく製作したラバーコースターを準備しました。

弊社黒岩が飲んでいたビールを奪って撮った使用イメージはこちら。

ラバー製だから結露してもこぼしても大丈夫なんです！

そしてブースの目玉は、
東急ハンズで実際に使われているiPadPOS「HandsPOS」の展示＆デモです！

じゃーん

HandsPOSはiPadを2台使っています。
1台はお客さん用ですが、もう1台は店員さんが操作するものなので
店舗でも滅多に見られない画面を見ることができ、
バーコードを読み込ませて店員さん体験もできるという優れもの！

明日東急ハンズでアルバイトすることになってもなんとかなります。

実際にデモをしていただいた方からは
「すごーい」「おおおー！」といった嬉しい反応をたくさんいただきました。

中には5億円のお釣りのレシートを作った方（！）や、
そのツイートをみて5億円を超えるためにブースにいらっしゃった方（！！）、
クレジット決済のサイン欄にお絵描きする方（！！！）もいて
セッションだけでなく、ブースも盛り上がりました！ありがとうございました！

（POS一式を頑張って運んだ甲斐があった・・・隣の駅だから近いけど・・・）

iOSDCの後は、iOS手羽だ！！

迷えるiOSエンジニアのみなさん！
ハンズラボでHandsPOSを一緒に作りませんか？

・エンプラの世界でゴリゴリiOSと向き合いたい！
・とにかくiOSが好きだ！
・手羽先が好きだ！
・ハンズラボのiOSエンジニアと話してみたい！

こんな方は、ぜひ「ハンズラボようこそiOS手羽の会」に来てみてください！
お酒を飲みながら、絶品の手羽先を食べながら、iOSの話をしましょう！

ご応募はこちらから↓
ハンズラボようこそiOS手羽の会

Cognitoユーザープールから発行されたアクセストークンの署名チェック

Cognito
2017年9月19日
YusukeKarakita

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

アプリケーションの認証にCognito User poolsを使用する場合、API Gatewayを使用していればCognito User pools Authorizer機能を使って、Cognito認証済みユーザーからのリクエスト以外は拒否するといった制御できるのですが、自前サーバーでアクセストークンを使ったアクセスコントロールをしたい場合、トークンの有効性や改ざんされていないかなどの検証機能を用意する必要が出てくるかと思います。

今回は、署名チェックするための公開鍵作成(Node.js)から署名チェック(Go)までの手順をまとめましたので共有させていただきます。

環境

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.12.5
BuildVersion:   16F73

$ npm --version
5.3.0

$ node --version
v8.1.0

$ go version
go version go1.8.3 darwin/amd64

$ sw_vers

ProductName: Mac OS X

ProductVersion: 10.12.5

BuildVersion: 16F73

$ npm --version

5.3.0

$ node --version

v8.1.0

$ go version

go version go1.8.3 darwin/amd64

流れ

アクセストークンから公開鍵を作成
作成した公開鍵を使って署名チェック

やっていきます。

トークンから公開鍵を作成（node.js）

JSON Web Token (JWT) Setをダウンロードする

（公式）ID トークンとアクセストークンの署名を確認する

$ curl https://cognito-idp.<リージョン名>.amazonaws.com/<CognitoユーザープールID>/.well-known/jwks.json > jwks.json

1 2	$ curl https://cognito-idp.<リージョン名>.amazonaws.com/<CognitoユーザープールID>/.well-known/jwks.json > jwks.json

<リージョン名>、<CognitoユーザープールID>を環境に合わせて入れます。
ここでダウンロードした情報をもとに公開鍵を作っていきます。

モジュールをインストール

公開鍵作成に必要なモジュールをインストールします。

$ npm install rsa-pem-from-mod-exp jsonwebtoken

1 2	$ npm install rsa-pem-from-mod-exp jsonwebtoken

公開鍵作成スクリプトを作成

$ vi createPublicKey.js

1 2	$ vi createPublicKey.js

スクリプトはこちらの記事を参考にさせていただきました。
Node.jsでAWS Cognito User Pools のアクセストークンを検証する

3行目のaccessTokenは公開鍵を作成したいユーザープールから発行されたものにします。

var jwt = require('jsonwebtoken');
var jwktjson = require('./jwks.json');
var accessToken = '＜アクセストークン＞'

var decoded = jwt.decode(accessToken, { complete: true });
if (!decoded){
  console.error('accessToken is not JSON Web Token.');
  process.exit(1);
}
var kid = decoded.header.kid;
var n; // modulus
var e; // exponent
for (var i = 0; i < jwktjson.keys.length; i++) {
  var row = jwktjson.keys[i];
  if (kid == row['kid']) {
    n = row['n'];
    e = row['e'];
    break;
  }
}

var pem = rsaPublicKeyPem(n, e);
console.log(pem)

function rsaPublicKeyPem(modulus_b64, exponent_b64) {

  function prepadSigned(hexStr) {
    var msb = hexStr[0]
    if (
      (msb >= '8' && msb <= '9') ||
      (msb >= 'a' && msb <= 'f') ||
      (msb >= 'A' && msb <= 'F')) {
      return '00' + hexStr;
    } else {
      return hexStr;
    }
  }

  function toHex(number) {
    var nstr = number.toString(16)
    if (nstr.length % 2 == 0) return nstr
    return '0' + nstr
  }

  function encodeLengthHex(n) {
    if (n <= 127) return toHex(n)
    else {
      n_hex = toHex(n)
      length_of_length_byte = 128 + n_hex.length / 2 // 0x80+numbytes
      return toHex(length_of_length_byte) + n_hex
    }
  }

  var modulus = new Buffer(modulus_b64, 'base64');
  var exponent = new Buffer(exponent_b64, 'base64');

  var modulus_hex = modulus.toString('hex')
  var exponent_hex = exponent.toString('hex')

  modulus_hex = prepadSigned(modulus_hex)
  exponent_hex = prepadSigned(exponent_hex)

  var modlen = modulus_hex.length / 2
  var explen = exponent_hex.length / 2

  var encoded_modlen = encodeLengthHex(modlen)
  var encoded_explen = encodeLengthHex(explen)
  var encoded_pubkey = '30' +
    encodeLengthHex(
      modlen +
      explen +
      encoded_modlen.length / 2 +
      encoded_explen.length / 2 + 2
    ) +
    '02' + encoded_modlen + modulus_hex +
    '02' + encoded_explen + exponent_hex;

  var seq2 =
    '30 0d ' +
    '06 09 2a 86 48 86 f7 0d 01 01 01' +
    '05 00 ' +
    '03' + encodeLengthHex(encoded_pubkey.length / 2 + 1) +
    '00' + encoded_pubkey;

  seq2 = seq2.replace(/ /g, '');

  var der_hex = '30' + encodeLengthHex(seq2.length / 2) + seq2;

  der_hex = der_hex.replace(/ /g, '');

  var der = new Buffer(der_hex, 'hex');
  var der_b64 = der.toString('base64');

  var pem = '-----BEGIN PUBLIC KEY-----\n'
    + der_b64.match(/.{1,64}/g).join('\n')
    + '\n-----END PUBLIC KEY-----\n';

  return pem
}

100

var jwt = require('jsonwebtoken');

var jwktjson = require('./jwks.json');

var accessToken = '＜アクセストークン＞'

var decoded = jwt.decode(accessToken, { complete: true });

if (!decoded){

console.error('accessToken is not JSON Web Token.');

process.exit(1);

}

var kid = decoded.header.kid;

var n; // modulus

var e; // exponent

for (var i = 0; i < jwktjson.keys.length; i++) {

var row = jwktjson.keys[i];

if (kid == row['kid']) {

n = row['n'];

e = row['e'];

break;

}

var pem = rsaPublicKeyPem(n, e);

console.log(pem)

function rsaPublicKeyPem(modulus_b64, exponent_b64) {

function prepadSigned(hexStr) {

var msb = hexStr[0]

if (

(msb >= '8' && msb <= '9') ||

(msb >= 'a' && msb <= 'f') ||

(msb >= 'A' && msb <= 'F')) {

return '00' + hexStr;

} else {

return hexStr;

}

function toHex(number) {

var nstr = number.toString(16)

if (nstr.length % 2 == 0) return nstr

return '0' + nstr

}

function encodeLengthHex(n) {

if (n <= 127) return toHex(n)

else {

n_hex = toHex(n)

length_of_length_byte = 128 + n_hex.length / 2 // 0x80+numbytes

return toHex(length_of_length_byte) + n_hex

}

var modulus = new Buffer(modulus_b64, 'base64');

var exponent = new Buffer(exponent_b64, 'base64');

var modulus_hex = modulus.toString('hex')

var exponent_hex = exponent.toString('hex')

modulus_hex = prepadSigned(modulus_hex)

exponent_hex = prepadSigned(exponent_hex)

var modlen = modulus_hex.length / 2

var explen = exponent_hex.length / 2

var encoded_modlen = encodeLengthHex(modlen)

var encoded_explen = encodeLengthHex(explen)

var encoded_pubkey = '30' +

encodeLengthHex(

modlen +

explen +

encoded_modlen.length / 2 +

encoded_explen.length / 2 + 2

) +

'02' + encoded_modlen + modulus_hex +

'02' + encoded_explen + exponent_hex;

var seq2 =

'30 0d ' +

'06 09 2a 86 48 86 f7 0d 01 01 01' +

'05 00 ' +

'03' + encodeLengthHex(encoded_pubkey.length / 2 + 1) +

'00' + encoded_pubkey;

seq2 = seq2.replace(/ /g, '');

var der_hex = '30' + encodeLengthHex(seq2.length / 2) + seq2;

der_hex = der_hex.replace(/ /g, '');

var der = new Buffer(der_hex, 'hex');

var der_b64 = der.toString('base64');

var pem = '-----BEGIN PUBLIC KEY-----\n'

+ der_b64.match(/.{1,64}/g).join('\n')

+ '\n-----END PUBLIC KEY-----\n';

return pem

}

実行して出力された公開鍵をファイルに保存します。

$ node createPublicKey.js > public.pem

1 2	$ node createPublicKey.js > public.pem

作成された公開鍵はこんな感じになっているかと思います。

$ cat public.pem
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3J2jr1WaxUA8NmTcFcGI
ZPJiCFp5iK/hJA9VCa6Qh30xrwpMVSyZs6fX46blL39KqZJqtspGd2P2A6un4+9j
ucBANKM8kGNG0KfmNSryb9m9LtDIDtrkKmFhhBdjqPUVdCWIz+BiVDpb8ZOCsKsM
rOi8TOHaMnhuAA43NaHaxEihRCZoZiHXxvPPmjAsXhSq54npkrzy+Q4XQWS49gTw
EcgkPGGhSN9JoDxLg6hr9Mo3kyBOCGBXkHXRkHKpt+4xo15if8fgYJi2ZhvS9Cla
wcggWME9/UxEFa4aVUMCDcVjVBQj4I6JgBNSzi7K3jSDpwrTsAmmRQZT/3PEbybG
lwIDAQAB
-----END PUBLIC KEY-----

$ cat public.pem

-----BEGIN PUBLIC KEY-----

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3J2jr1WaxUA8NmTcFcGI

ZPJiCFp5iK/hJA9VCa6Qh30xrwpMVSyZs6fX46blL39KqZJqtspGd2P2A6un4+9j

ucBANKM8kGNG0KfmNSryb9m9LtDIDtrkKmFhhBdjqPUVdCWIz+BiVDpb8ZOCsKsM

rOi8TOHaMnhuAA43NaHaxEihRCZoZiHXxvPPmjAsXhSq54npkrzy+Q4XQWS49gTw

EcgkPGGhSN9JoDxLg6hr9Mo3kyBOCGBXkHXRkHKpt+4xo15if8fgYJi2ZhvS9Cla

wcggWME9/UxEFa4aVUMCDcVjVBQj4I6JgBNSzi7K3jSDpwrTsAmmRQZT/3PEbybG

lwIDAQAB

-----END PUBLIC KEY-----

これがユーザープールの公開鍵として利用できます。

公開鍵を使ってトークンを検証する

今度は作成した公開鍵をもとに、サーバーに送られてきたアクセストークンが正当なものかをチェックします。

コードはこちらの記事を参考にさせていただきました。
【Go言語】GoでJWT（JSON Web Token）を使うサンプル

$ vi validationCheck.go

1 2	$ vi validationCheck.go

tokenStringに検証するトークンを入れます。

package main

import (
    "fmt"
    "crypto/rsa"
    "io/ioutil"
    jwt "github.com/dgrijalva/jwt-go"
)

const (
    tokenString = "＜検証したいトークン＞"
    pubKeyPath = "./public.pem"
)

func main() {
    token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
            if _, ok := token.Method.(*jwt.SigningMethodRSA); !ok {
                return nil, fmt.Errorf("Unexpected signing method: %v", token.Header["alg"])
            }
            return LookupPublicKey()
    })

    if err != nil || !token.Valid {
            // トークン有効期限切れ or 署名チェックが通らなかった時の処理
            fmt.Print("Invalid token")
    } else {
        claims := token.Claims.(jwt.MapClaims)
        fmt.Println("OK")
        // ユーザーネーム出力
        fmt.Println("username: ", claims["username"])
    }
}

func LookupPublicKey() (*rsa.PublicKey, error) {
    key, _ := ioutil.ReadFile(pubKeyPath)
    parsedKey, err := jwt.ParseRSAPublicKeyFromPEM(key)
    return parsedKey, err
}

package main

import (

"fmt"

"crypto/rsa"

"io/ioutil"

jwt "github.com/dgrijalva/jwt-go"

)

const (

tokenString = "＜検証したいトークン＞"

pubKeyPath = "./public.pem"

)

func main() {

token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {

if _, ok := token.Method.(*jwt.SigningMethodRSA); !ok {

return nil, fmt.Errorf("Unexpected signing method: %v", token.Header["alg"])

}

return LookupPublicKey()

})

if err != nil || !token.Valid {

// トークン有効期限切れ or 署名チェックが通らなかった時の処理

fmt.Print("Invalid token")

} else {

claims := token.Claims.(jwt.MapClaims)

fmt.Println("OK")

// ユーザーネーム出力

fmt.Println("username: ", claims["username"])

}

func LookupPublicKey() (*rsa.PublicKey, error) {

key, _ := ioutil.ReadFile(pubKeyPath)

parsedKey, err := jwt.ParseRSAPublicKeyFromPEM(key)

return parsedKey, err

}

実行する。

$ go run validationCheck.go
OK
username:  testuser01@hands-lab.com

$ go run validationCheck.go

username: testuser01@hands-lab.com

有効なトークンであれば上記のような出力になるかと思います。

トークンの無効性を確認してみる

こちらのサイトでトークンのエンコード・デコードができるので、試しに内容を書き換えた（改ざんした）トークンを検証してみます。

RSA公開鍵暗号アルゴリズムを選択します。

左側にアクセストークンをいれると、右側にデコードされたトークンの中身が表示されます。

右側のトークンの内容を書き換えると左側にエンコードされたものが表示されます。
それを先ほどの署名チェック（validationCheck.go）のtokenStringに入れて再度実行するとInvalid tokenと出力されるかと思います。

$ go run validationCheck.go
Invalid token

$ go run validationCheck.go

Invalid token

有効期限が切れたトークンでも同様に無効の結果となります。

まとめ

ちょっとつらかったですができました。これをいい感じでアプリに埋め込むといいのではないでしょうか。

HandsPOSゆるふわ開発フロー

iOS
2017年9月7日
KomabaTaiki

最近はTypeScriptが楽しい、駒場です。

東急ハンズの内製iPadPOSアプリHandsPOSのゆるふわ開発フローについて書いてみたいと思います。

issue tracker

課題管理には社内全体で Backlog を利用しています。Backlogの課題に対応したGitHubのプルリクエストが作成された場合、Open時にはPRのURLをコメントしマージされた時にはBacklogの課題をCloseするBOTが運用しています。BOTはGitHubのWebHook, API Gateway, Lambdaで出来ています。コードと絡まないようなタスクもこちらに登録しています。

git workflow

developブランチからforkしてfeatureブランチやbugfixブランチをローカルで作成してプルリクを作成しレビュー後にdevelopブランチにマージするフローで、GitHub Flowに近いです。リポジトリにはGitHubを使っています。最近はRebase mergeが好きです。

git commit-hook + lint

lintにはSwiftLintを利用し警告も出ないようにしています。lintで警告が出るコードをコミットしたくないので、gitのpre-commit hookにswiftlintを実行し警告が出ない事をチェックして警告があるようであればエラーにしてコミットを防止しています。commit hookは.gitディレクトリ配下となりコード管理しにくいため、npmの pre-commit を利用してチーム内で共有しています。また、個々人のインストールしているSwiftLintのバージョンが古く、新規ルールを追加しても必要な警告がその人の環境では出ない事も考えられるため、そこは後述のCI(CI環境のSwiftLintは最新を利用)で実行されるDangerで警告されるようにしています。

CI

developブランチへのコミット及びプルリクされているブランチへのコミット時にはCIを走らせてテスト等を実行しています。

DEBUGビルド及びUnit Test
Releaseビルド
プルリクの場合はDangerの実行

CIサービスは最初は無料だったbuddybuildを利用していたのですが、有料化に伴いビルドの早かったCircleCIを現在は利用しています。Travis, CircleCI, Bitrise, Nevercode, buddybuildを試した結果として最近のCircleCIはマシンパワーが上がってCIサービスの中ではちょっぱやです。でも1コミットに対して並列で何か処理させる事は出来ないので、タスクがいくつもあってMatrixをうまく使えれば総合時間ではTravisが速いかもしれません。

Danger

Dangerはいまのところこんなルールで動かしています。Storyboardファイルを変更していたらスクリーンショットのせてねルールが独特でしょうか。あまり使いこなせている感がないです。

# Git
warn "Big PR" if git.lines_of_code > 5000

# GitHub
warn "Please add labels to this PR" if github.pr_labels.empty?
warn "PR is classed as Work in Progress" if github.pr_labels.include? "WIP"
warn "PR is classed as Work in Progress" if github.pr_title.include? "WIP"
can_merge = github.pr_json["mergeable"]
warn("This PR cannot be merged yet.", sticky: false) unless can_merge
hasImage = github.pr_body.match /!\[.*\]\(.*\.png\)/
warn "Please provide screenshots." if git.modified_files.include?("*.storyboard") && !hasImage
fail "Please provide a summary in the Pull Request description" if github.pr_body.length < 5

# swiftlint
github.dismiss_out_of_range_messages
swiftlint.config_file = '.swiftlint.yml'
swiftlint.lint_files inline_mode: true

# Git

warn "Big PR" if git.lines_of_code > 5000

# GitHub

warn "Please add labels to this PR" if github.pr_labels.empty?

warn "PR is classed as Work in Progress" if github.pr_labels.include? "WIP"

warn "PR is classed as Work in Progress" if github.pr_title.include? "WIP"

can_merge = github.pr_json["mergeable"]

warn("This PR cannot be merged yet.", sticky: false) unless can_merge

hasImage = github.pr_body.match /!\[.*\]$.*\.png$/

warn "Please provide screenshots." if git.modified_files.include?("*.storyboard") && !hasImage

fail "Please provide a summary in the Pull Request description" if github.pr_body.length < 5

# swiftlint

github.dismiss_out_of_range_messages

swiftlint.config_file = '.swiftlint.yml'

swiftlint.lint_files inline_mode: true

Carthage自動PullRequest

アプリで利用しているライブラリはなるべくCocoaPodsではなくCarthageに寄せています。Carthageは carthage outdated で新しいバージョンがリリースされていないかチェックでき、 carthage update --no-checkout コマンドで実際にはframeworkをビルドせずにCartfile.resolveをアップデート出来ます。これらを利用して週に1回CIをスケジュール実行(CircleCIはスケジュール実行の機能がないためLambdaのスケジュール実行でCircleCIのAPIで実行)させ、新しいバージョンがあればCartfile.resolveをアップデートするPullRequestを自動作成するようにしてライブラリは定期的にアップデートしています。

GitHub Releases

新しいバージョンを作成する際はgitのタグを作ります。タグのプッシュイベントの場合はCIは通常のタスクの他にxcarchiveを作成しGitHub Releasesにアップロードするタスクを追加で実行させています。現在はタグの作成後にCHANGELOG.mdの生成のために github-changelog-generator を手動で実行していますがこれもCIのタスクに持っていきたいですね。ただ、このgemですとまだdevelopブランチにはマージされていないけれど、featureブランチに向けたPRのマージも、バージョン間にマージされたものとして載ってきてしまうため、もうちょっと良いものはないかと検討中。

deploy

HandsPOSはEnterpriseアプリなので、AppStoreへの登録はありません。代わりにMDMと呼ばれる管理サービスにipaファイルをアップロードし各端末に配信する形です。弊社では CLOMO をMDMに利用していますが、CLOMOに外部向けのAPIがないため現在は作成したipaを手動でアップロードしています。このあたりの自動化は課題の一つ。最近個人的なサイドプロジェクトでpuppeteerを使い始めたので、それで出来たらいいなと構想しています。また、プロビジョニングプロファイルを1年間更新せずに危うく有効期限切れになる事があったため、現在は定期的に再作成しているが新しいバージョンを作る度に再作成しても問題はないため、そこもspaceship等で再作成->ダウンロードした新しいプロビジョニングプロファイルでipaを作成…と出来ると新しいバージョンを作成するとそこから1年有効なipaが作成出来るので嬉しいですね！

まとめ

書いていくうちに後回しにしている改善がそこそこある事に気付かされました。まだまだ改善していこうと思います！

「iOSDC 2017」に本ブログの著者駒場と、黒岩が登壇します！

https://www.hands-lab.com/news/seminar-events/770

マイナビニュース掲載「エンタープライズの世界で挑戦! ハンズラボのiOSアプリ開発現場に迫る」
http://news.mynavi.jp/kikaku/2017/09/01/002/

ハンズラボ新卒研修2017 (1/2) 〜カリキュラム編〜

新人研修
2017年8月3日
MiidaYuki

上の画像の文字には、FIGletを使用しました公式サイト

こんにちは、エンジニアの三井田です。

新卒採用受け入れ2年目となったハンズラボは、今年も5名の新卒エンジニアが入社し、4〜6月の3ヶ月間、新人研修を行いました。

6月末に新人研修が無事に終了し、7月から新卒のみなさんが各チームへ配属となりました。7月から始まった私の開発も少し落ち着いたので、今回は2017年度のハンズラボ新卒研修について、講師の視点から備忘も兼ねてまとめようと思います。

他企業様で新卒研修に関わっているみなさまの参考に少しでもなれば幸いです。

前提

今年の弊社新卒について

最初に、今年の弊社新卒について簡潔に説明します。

今年は、IT経験者4名(情報系学部・専門学校卒)、未経験者1名(語学系学部卒)の計5名の新卒エンジニアが入社しました。

経験者のプログラミング経験に関しては、授業でCやJavaなどを学習した人が多く、ネイティブアプリ開発を学校で学んでいた人もいました。しかしながら、各々が実際どのくらいコードを書けるかは、選考時にコーディングのテストを行っていないため、入社するまで分からない状態でした。

未経験者は、IT未経験だったものの、内定後から入社まで週2〜３回のペースで弊社でアルバイトをして、プログラミングの基礎的な勉強をしてから入社した、という状況です。

2017年度新卒研修の指導体制・方針について

次に、弊社の2017年度新卒研修の指導体制について説明します。

AWSチームで担当する

2017年度の研修は、R&Dその他もろもろを行っているAWSチームが担当することになりました。また、プロジェクトの稼働率等の問題から、他のチームの人への講義などの依頼は、よほどその人にしかできないことでない限りは避ける、という制約がありました。

＊ AWSチームに関する詳しい業務内容は、同じチームで働く百木田(からきた)がこちらにまとめております

まずは、アプリケーションをしっかりと開発できるようになってほしい

「バーサタイリスト(なんでもやる人)を育てる会社」を謳っている弊社ですが、新人、特に新卒エンジニアには、まずはアプリケーションをしっかりと開発できるようになってほしいという方針があります。故に今年度の新卒研修は、当初はインフラ系の研修時間を多くとっていましたが、最終的にはアプリケーション開発中心のカリキュラムとなりました。

以上を踏まえてチーム内で議論した結果、チームリーダーの鹿倉を除いたAWSチームの中で、比較的アプリケーション開発経験のある私が、新卒研修のメイン担当となりました。

私について

今年度の新卒研修を担当した私、三井田に関してですが、実は去年の3月に学部(情報科学専攻)を卒業した2016年度新卒なので、去年は新卒研修を受ける側でした。ハンズラボに入社後、3ヶ月の新卒研修を経て配属されたチームで、ECサイト・スマホアプリのAPIや管理画面の開発などに携わった後、今年の2月からAWSチームに移籍しました。実務経験豊富な熟練エンジニアではありませんが、新卒のみなさんと年齢や境遇が近い分、同じ目線に立って研修をすることが少しはできたのではないかな、と思っています。

研修目標

研修を行うにあたって、以下の3つの研修目標を立てました。
1. 自走できるエンジニアになる
2. ユーザーの要求に応えることができるエンジニアになる
3. 共に開発する仲間を大切にできるエンジニアになる

1. 自走できるエンジニアになる

受け身ではなく、主体的に問題を解決する力

自分で本やWebサイトを使って調べる、分からないところを具体性を持って人に聞く

自分が書いたコードに責任を持つ

自分で考えてコードを書く。自分がなぜそのようなコードを書いたのか人に説明できる
脆弱性のないプログラムを書く。指示されていなくても、常にセキュリティのことは念頭に置いておく

2. ユーザーの要求に応えることができるエンジニアになる

＊ユーザーが言ったことは全て二つ返事でやらなければいけない、という意味では決してありません！！

自分が開発したものは、必ず誰かに使われる

ユーザーの要求・要望に対して、全て「難しいからできません」では、次から何も頼まれなくなります。ユーザーの要求に応えるためには、以下の2つの力を養うことが必要だと考えました。

ユーザーの要望を正確に理解する力(根気強くユーザーとコミュニケーションをとることが必要)
ユーザーの要望を実現する技術力

(+α)ユーザーの潜在的な要求・要望に応えられる力も、ゆくゆくは身につけてほしい

また、ユーザーは必ずしも技術的な専門家ではないため、ユーザーから言われた要望だけに応えるのではなく、ゆくゆくは、ユーザーが言語化できない不満・欲求も汲み取って解決できるエンジニアを目指してほしいです。

3. 共に開発する仲間を大切にできるエンジニアになる

会社では、1人で開発することはほとんどなく、チームで開発を進めていくことになります。故に、チームで開発する際には、以下の点を意識してほしいと考えました。

開発に関わる全ての人たちをリスペクトしよう

独りよがりの開発はやめよう

例：自分だけが分かるプログラム
他の人が後でそのプログラムを修正するかもしれない！

4月

〜自走するために必要な、開発の基礎力育成フェーズ〜

研修内容

4月の研修内容は以下の通りです。

経験者・未経験者問わず5人全員一緒に研修
JavaScriptのeラーニング・社内講座を通して、プログラミングの基礎的な知識を学習
終盤は、jQuery・Node.jsの座学・演習を通して、Webアプリケーション(クライアント・サーバモデル)の仕組みを、実際に手を動かしながら理解する

4月の研修で身につけてほしいこと

開発するために必要な基礎的なプログラミング技術
自分で考えてコードを書く力
分からないところが出てきたときに、それを主体的に解決する力

(補足)JavaScriptの選定理由

賛否両論あるかと思いますが、今年の新卒研修で学ぶ言語は、JavaScriptを選択しました。主な選定理由は以下です。
1. フロントエンドもサーバサイドもJavaScriptで書ける
2. Web開発をする上で避けて通れない
3. Node.jsの、社内での採用実績

1. フロントエンドもサーバサイドもJavaScriptで書ける

JavaScriptという１つの言語を学ぶことで、フロントエンドもサーバサイドも実際に手を動かしながら学ぶことができます。4月に社内で研修ができる期間は、外部研修を除くと実質12日程度しかありませんでしたが、学ぶ言語を一つに統一できたことで、プログラミングの基礎からWebアプリケーションの仕組みまで、一通り学ぶことができました。

2. Web開発をする上で避けて通れない

さらに、弊社は一部iOSネイティブアプリを開発するチームがあるものの、アプリケーションを開発しているほとんどのチームは、Webアプリを開発しています。現在、フロントエンド開発ではJavaScriptを使うことはもはや避けられないため、よく「難しい」「クセがある」と敬遠されがちなJavaScriptを、しっかりと指導できるこの研修期間中に体系的に学んでほしい、という思いもありました

3. Node.jsの、社内での採用実績

また、一時期社長の長谷川が、フロントエンドもサーバサイドもJavaScriptでやることを推進していたこともあり、社内の多くのプロジェクトのサーバサイドにNode.jsが採用されています。サーバサイドをNode.jsを使って学ぶことで、研修後の配属先で一からNode.jsを学ばなくてよくなる、というメリットもありました。

5月、6月

〜ユーザーの要求に応えられるエンジニア、チームで円滑に開発を進められるエンジニアになるための「仮想プロジェクト」演習〜

仮想プロジェクト

もはやハンズラボ恒例の仮想プロジェクト、今年もやります。去年の仮想プロジェクトの模様は以下のリンクからご覧いただけます。

今年も仮想プロジェクトという名前自体は同じですが、研修内容が違うこともあり、主に以下の点が昨年と異なります。

仮想お客様であるAWSチームからお題を出して、それを開発してもらう
開発言語は、4月に勉強したJavaScript

なぜ仮想プロジェクトをやるのか

「配属後に実際のプロジェクトで経験するであろうことを、なぜこの研修期間でやるのか」「座学や、課題を与えて解いてもらう時間をもっと増やした方が良いのではないか」と社内でも議論になりました。弊社がそれでも新卒研修期間に仮想プロジェクトを行う理由は、以下の2つです。

仮想プロジェクトは、失敗できる

実際のプロジェクトではお客様からお金をいただいて開発するため、失敗はできません。しかしながら、仮想プロジェクトは仮想なので、最悪大失敗に終わっても大丈夫(？)です。

失敗する前に注意されるよりも、失敗して自ら学んだ方が印象に残りますし、学びは大きいと考えます。仮想プロジェクトで失敗を恐れず大胆に行動し、失敗から大いに学んでほしいと思っています。

主体的な行動・意思決定ができるようになってほしい

配属後のチームでは、おそらく立場としては一番下で、しばらくは上司・先輩から与えられたタスクをこなしていくことになります。しかしながら、仮想プロジェクトではチームメンバーは全員同期であり、仮にリーダーを決めたとしても、配属後のプロジェクトよりは自分で考えて行動する機会が多くなります。

配属後に、ただの作業員ではなく主体的に業務に取り組むエンジニアになるため、仮想プロジェクトで、組織の一員として主体的に行動・意思決定をする経験を積んでほしいと考えました。

5月、6月の研修で身につけてほしいこと

5、6月の仮想プロジェクトで身につけてほしいことは、以下の3つです。
1. 実際に開発をする上で必要となる力
2. チームで円滑に開発を進める方法・マインド
3. スケジュール遅延による影響と対策を知る

1. 実際に開発をする上で必要となる力

学校の授業や4月の研修で、開発するために必要な技術・知識を学んだだけでは、すぐに実務で開発を始めるのは難しいことが多いです。
具体性を持ってお客様、チームメンバーに聞くなどの質問の仕方であったり、分からないことを調べるスピード力であったり、実際に開発をする上で必要となる力をこの仮想プロジェクトで身につけてほしいと思います。

2. チームで円滑に開発を進める方法・マインド

チームメンバーに技術面で差がある中で、作業の早い人が自分だけでやろうとしてしまうと、その人の負担がどんどん増えてしまいます。技術面に差がある中で、どのようにタスクを分担すればチームで円滑に開発を進められるのかを、仮想プロジェクトで考え、学んでほしいと考えました。

加えて、適切なコミュニケーションの取り方も仮想プロジェクトで最も学んでほしいことの一つです。一口にコミュニケーションと言っても、チーム外の人とのコミュニケーション、チーム内の人とのコミュニケーション、根回し(何かを依頼したり企画したりする時は、早め早めにアポ取りなどの行動をする)など、いろいろな種類があります。コミュニケーションスキルは、研修中だけではなく配属後も必要不可欠なスキルになるので、ぜひ、この仮想プロジェクトでたくさん失敗し、適切なコミュニケーションの取り方を学んでほしいと思います。

3. スケジュール遅延による影響と対策を知る

初めてのプロジェクト開発かつ開発期間が短いと、スケジュールはどうしても遅れてしまうことがあります。去年の仮想プロジェクトも、終盤にスケジュールの遅延がありました。プロジェクト中にスケジュールが遅延してしまった時に、その影響を正しく把握し、適切な対策を講じることができるようになってほしいと思います。

新卒研修のカリキュラムに関しては以上です。

実際の3ヶ月の研修はどうだったのか？

ここに書くと長くなり過ぎてしまうので、その模様は後日また書きます。

大変な3ヶ月間でしたが(笑)、忘れられない貴重な経験をすることができました。

近いうちに更新するので、そちらもぜひ読んでいただければ幸いです。
それでは、今回はこの辺で。最後までお読みいただきありがとうございました。

東急ハンズでAmazon Chimeを導入した時に調べたこと

AWS
2017年7月29日
YusukeKarakita

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

今年の２月にリリースされたAmazon Chimeをこの度、東急ハンズの会議に使ってみることになりました。

以下がChimeを採用したいくつかの理由です。

シンプルな操作
最大100人がビデオミーティングに参加可能
主催側から参加者をミュート可能

Chimeを本格的に利用することになり、いろいろ調べたのですがまだまだナレッジが少なく試行錯誤したので、わかったことを残しておこうと思います。

Chimeアカウントとユーザー

Chimeにはアカウントとユーザーという単位が出てきます。イメージ的にはアカウントは会社やチームなどのグループで、ユーザーは個人に紐づくものです。

ChimeユーザーはAmazon.co.jpのアカウントと紐付いていて、AWSアカウントを持っていなくても使用できますが、AWSコンソールからChimeアカウントとChimeユーザーを紐付けることでユーザー管理をすることができるようになるなど便利に利用できます。

以下がChimeアカウントの種類です。

AWS Black Belt Online Seminar 2017 Amazon Chime from Amazon Web Services Japan

少し補足するとこんな感じ。

Amazonアカウント

・　AWSアカウントで管理されていない単独のアカウント（ユーザー）。

チームアカウント

・　AWSのChimeで作成したアカウントにユーザーを招待できる。

エンタープライズアカウント

・　自社のドメインをAWSアカウントのChimeへ登録する必要あり。
・　そのドメインのメールアドレスでChimeにログインすると自動的にアカウントにユーザーが追加される。

ちょっとややこしいです。整理するために図にしてみました。

グループミーティングをホストするにはPro Editionを付与したChimeユーザーが必要です。主催者によってミーティングがホストされると、Chimeユーザーを作成していない人でもミーティングIDを教えてもらうことでミーティングに参加することができます。

ポートと通信帯域の要件

通常のビデオミーティングをする場合は以下のそれぞれのIPアドレス：ポートに対するアウトバウンド通信を許可してあげる必要があります。

IP Address

52.54.62.192/26
52.54.63.0/25
52.54.63.128/26
52.55.63.128/25

Ports

TCP/443
UDP/16384:17383
UDP/3478

ポートの要件はこちらに記載されています。
hosts-ports-and-protocols-needed-for-amazon-chime

各機能を利用する上で必要な通信帯域はこちらに記載されています。
what-are-the-bandwidth-requirements-for-amazon-chi

料金体系

各ユーザーエディションごとの料金は公式サイトに記載されているとおりです。

ユーザーはAWSコンソール上からエディションをGrantさせたりRevokeさせたりできるのですが、課金されるのはProエディションをGrantさせてた期間の日割り計算になります。
なので1ユーザーを1ヶ月のうち合計20日間ProエディションをGrantさせていた場合、

15ドル / 30日（１ヶ月） ✕ 20日（Proが当たっていた日数） = 10ドル

1 2	15ドル / 30日（１ヶ月） ✕ 20日（Proが当たっていた日数） = 10ドル

という計算になります。
なお、課金は１ユーザーごとになるため、２ユーザー以上利用した場合はユーザー数分の課金が発生します。

AD連携

AWSのAD Connectorを利用することでChimeのAD連携をすることができます。しかしながらAD連携するにはAD Connectorがバージニアリージョンにある必要があります。

まとめ

以上となります。Chimeの使用感や問題点、会議する上で工夫したこと、考慮した方がいいことなどあるのですが、そちらは別の機会に書ければと思っています。
Chime自体、登場したばっかりでまだまだ改善の余地がありますがフィードバックをしつつ、アップデートに期待したいと思います。
ありがとうございました。

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