AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

ハンズラボ新卒研修2017 (2/2) 〜実際にやってみた編〜


写真:仮想プロジェクト最終発表会を終え、安堵の表情の2017年新卒のみなさん

こんにちは、エンジニアの三井田です。
先月投稿した「ハンズラボ新卒研修2017 (1/2) 〜カリキュラム編〜」をお読みいただいたみなさま、ありがとうございました。多くのコメントもいただき、大変励みになりました。

少し間があいてしまいましたが、今回は「ハンズラボ新卒研修2017 (2/2) 〜実際にやってみた編〜」と題しまして、4月〜6月の3ヶ月間に渡って行われた2017年度新卒研修の、より具体的な研修方針・内容や、研修を通して考えたことなどをまとめたいと思います。

4月 〜入社、社内技術研修〜

4月の研修は、IT経験者、未経験者関係なく全員一緒に社内で技術研修を行いました。
ビジネスマナーなどを学ぶ外部研修などもあったため、4月に社内で研修ができた期間は実質12日程度でした。

4月に身につけてほしいこと(前編からの再掲)

前編からの再掲になりますが、4月の社内技術研修で身につけてほしかったことは下記です。

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

 

到達度の測り方

各々が上記の目標をどれくらい達成できたかについては、下記の方法で測りました。

中間到達度の測り方

  • 配布した問題集の問題が解けているか
    単純に解いた問題の数を確認するのと同時に、エラーが出た時に何が問題なのかを把握し、正しく動作するようにプログラムを修正できているかも確認しました

最終到達度の測り方

  • 入社初日に解いてもらったプログラミングテストがJavaScriptで解けるかどうか
    入社初日に解いてもらったプログラミングテストを4月末にもう一度解いてもらうことで、4月の最終到達度を測りました

4月の研修方針と心がけたこと

単純な知識や技術の学習は、基本個人で

単なる知識や技術の学習は、集団よりも個人のペースで行った方が効率が良いと考えたので、各自でeラーニングや書籍を見ながら、分からないところを質問しに来てもらうスタイルにしました。(もちろん、つまづきやすかったり、書籍などを見ても理解しづらいと思ったトピックについては、別途講義を行いました。)

みんなで集まる時間は、インタラクティブに

反対に、みんなで集まる時間は、コードレビューなど参加者全員でコミュニケーションを取れる内容にしました。講義をするにしても、一方的にならないようにできるだけ新卒のみなさんと対話しながら進めるようにしました。

新卒のみなさんの精神的サポートをする

自分も去年の4月は入社したばかりで何かと不安な時期だったので、5人全員の考えていることを把握できるように毎日夕礼を行い、そこで各々の日報に対するフィードバックや、不安に感じていることに対してできる限りのサポートをしました。

4月に学習したこと・行ったこと

今回は技術研修に焦点を当てた話をするため、6日間の外部ビシネス研修やハンズラボの説明など、技術面以外の話についての説明は割愛させていただきます。(昨年度の話になりますが、社内で行った技術面以外の研修については、弊社チーフエンジニア田部井がこちらの記事でまとめております)

4月に社内で行った、正味12日間の技術研修の内容は以下です。

  • キックオフ
  • JavaScript基礎の学習
  • HTML5/CSS3の学習[追加]
  • セレクタ・DOM操作演習
  • Node.jsの学習
  • データベースの学習
  • 社内LT会
  • コードレビュー会
  • その他(マークダウンの書き方、UNIX研修(外部)など)

 

キックオフ

新卒研修概要説明

前編でご紹介した研修目標や、研修スケジュールなどについて研修初日に説明しました。

プログラミングテスト

その後、新卒のみなさんの技術力が未知数だったため、1時間程のプログラミングのテストを、紙にプログラムを書いてもらう形式で実施しました。回答言語は自由にしたので、新卒のみなさんが選んだ言語は、C、Java、PHP、Swiftなどさまざまでした。そしてこのテストの結果を踏まえて、事前につくったカリキュラムを再度調整しました。

環境構築(Atom、Emmet、EditorConfig、Node.js(Nodebrew経由)、ESLintなど)

今回の研修で使うプログラミング環境の構築や、入れておくと便利なプラグインなどをインストールしてもらいました。最終的にNode.jsでJavaScriptファイルを実行して、前編の最初に出てきたアスキーアートが出たら終了でしたが、全員無事に完走することができました。

JavaScript基礎の学習

eラーニング&問題集を解く

基本的な文法などは、Schooの動画などを見て各自で学習してもらいました。学習後は、事前に配布したJavaScriptの基礎的な問題が30問程書かれた問題集を解いてもらうことで、学んだ知識の定着を図りました。
もちろん、個人で学習していると疑問点や不明点がたくさん出てくるため、その場合は躊躇せずに私やほかの人に積極的に聞くように促し、適宜フォローを行いました。

社内講義

JavaScriptでプログラムを書く上で知っておいた方が良いことや、つまづきやすい部分に関しては、別途社内で講義を行いました。講義では以下のトピックなどを取り上げました。

  • レキシカル環境
  • 実行コンテキスト
  • this
  • プロトタイプ
  • ES6新機能(const・let、アロー関数など)

社内講義後には、eラーニングの時と同じくその講義に関する確認問題を配布し、理解できていない箇所がないかの確認を行いました。

HTML5/CSS3の学習[追加]

当初のカリキュラムには含まれていませんでしたが、HTML・CSSを書いたことがない、習ったけどよく分からない人が大半であったため、急きょHTML・CSSの学習を追加しました。

HTML5/CSS3の初心者向けの書籍を一通りやってもらい、基本的なhtmlタグやcssプロパティを覚えてもらいました。また、効率的なマークアップの仕方(Emmetを使った方法など)については、ライブコーディングも交えながらの講義を行うことで補足しました。そして、一通り学習が終わった後は、数種類のサンプルWebサイトを自力でマークアップする練習をしてもらいました。

セレクタ・DOM操作演習

これに関しては「習うより慣れよ」なので、書籍を見ながらひたすら演習を積んでもらいました。

Node.jsの学習

4月の後半は、Webアプリケーションの仕組みを説明してから、実際にExpressを使ってローカルサーバを立ててもらい、サーバサイドの演習を行いました。また、WebSocketについても学習し、同じように通信の仕組みなどを学んだ後、実際にSocket.IOを使ってWebSocketサーバーを実装し、動作確認を行いました。

データベースの学習(DynamoDB)

弊社は、アプリケーションのデータストアにS3やDynamoDBが使われることが非常に多いという特徴があります。そのため、RDB、SQLについて学ぶことはエンジニアとして非常に重要なことだというのは百も承知なのですが、学校でRDBについて学習した人も多かったため、今回は研修期間の都合上、AWSのフルマネージドNoSQLデータベースサービスであるAmazon DynamoDBの学習と演習をメインで行いました。

弊社におけるDynamoDBの活用事例についてご興味のある方は、下記の記事をご参照ください
東急ハンズメッセのピークにお客様の信頼を取り戻した高コスト効率の Amazon DynamoDB

社内LT会

新卒のみなさんにはこれからの長いエンジニア人生、知識や技術をただ学習するだけでなく、学んだことや経験したことを積極的に社内外にアウトプットしていってほしいと考えたので、その第一歩目として、好きなテーマのSchooの動画を1つ見てもらって、それについてのLTを社内で行ってもらいました。ITと関係ないトピックでも大歓迎だったため、新卒のみなさんそれぞれの個性が溢れる大変面白いプレゼンになっていました(もちろん、内容もきちんとまとまっていました)。

コードレビュー会

また、4月に解いたプログラミングの問題について、同期・講師とより良い解法や書き方について議論する、コードレビュー会も複数回行いました。みなさんただ批判するのではなく、お互いをリスペクトし合いながら上手にディスカッションができていたのでとても良かったです。配属後、プルリクエストを送る時などに、ここでの議論の経験が生かされれば幸いです。

その他

マークダウンの書き方に慣れていない人が多かったので、研修中の日報は、昨年度同様マークダウンで書いてもらいました。また、コマンドラインでの操作に不慣れな人もいたため、基本的なUXIXコマンドなどについて学べる外部研修を受講したりもしました。

4月最後のプログラミングテスト

結論から言うと、驚くほど成長していました。大半はJavaScriptを書いたこともなかったため、どうなることかと思いましたが、全員JavaScriptで問題にきちんと回答することができていたので、上記の研修カリキュラムは一定の効果があったのではないかと思います。特に、研修担当者に質問したり、コードレビュー会でコードをレビューしたりされたりすることで、自分のコードを客観的に見ることができるようになったと感じました。やはり自分以外の人と、どうしたら現状のコードがより良くなるかを議論することは、技術力を向上させる上で非常に大切なことだと改めて感じました。

5、6月 〜仮想プロジェクト〜

5、6月は、AWSの外部研修に参加した後、前編でお話した通り、社内で仮想プロジェクト演習を行いました。仮想プロジェクトについては前編をご参照ください。

仮想プロジェクトで身につけてほしいこと(前編からの再掲)

  • 実際に開発をする上で必要となる力
  • チームで円滑に開発を進める方法・マインド
  • スケジュール遅延による影響と対策を知る

 

到達度の測り方

中間到達度の測り方

「設計」「実装(フェーズ1)」「実装(フェーズ2)」「テスト」の各フェーズの最後に報告会を設けました。そこでプロジェクトの進捗などを把握するとともに、報告会の内容、プロジェクトの進め方についてのフィードバックを主にAWSチームから行いました。

最終到達度の測り方

新卒研修最終日に行う「仮想プロジェクト最終発表会」で、最終成果物や仮想プロジェクトの振り返りについて発表してもらうことにしました。最終発表会ではAWSチーム以外の弊社社員にも発表を聴いてもらい、仮想プロジェクト全体のフィードバックなどをより多くの人から行ってもらいました。

仮想プロジェクトお題 〜Botをつくってください〜

5月初旬の仮想プロジェクトキックオフ時に、仮想お客様であるAWSチームリーダーの鹿倉から、以下の5つの要件をお題として提示しました。

要件1〜4:AWSの情報を取得して通知するBot

  1. 特定のタグが付いているインスタンスの一覧を抽出
  2. RI(リザーブドインスタンス)の適用率を抽出
  3. 特定のセキュリティグループに入っていないインスタンスがないかチェック
  4. 特定のインスタンスの情報(OS,インスタンスタイプなど)を入力すると、日本円でオンデマンド、1年RI、3年RIの金額が出力(価格テーブルは常に最新)

クライアント側は特に制約はなく、既存のサービスと連携する形でも、自分たちでフロント側をつくっても良いという条件でしたが、新卒のみなさんは最終的にSlackに上記の通知を行うことに決定しました。

要件5:東急ハンズのGoogleカレンダーにスケジュール登録したら、自動でハンズラボのGoogleカレンダーにも登録してほしい

弊社社員は、ハンズラボと親会社の東急ハンズ2つのGoogleアカウントを所有しています。そのため、片方のGoogleカレンダーにしか予定を登録してないと、ほかの人がもう片方のアカウントのGoogleカレンダーだけを見て、予定が空いていると勘違いしてしまうことがあります。そこで、東急ハンズのGoogleカレンダーに予定を登録したら自動でハンズラボのGoogleカレンダーにも同じ予定を登録できるようにしてほしい、という要件を挙げました。

これらの要件を提示した理由

新人研修ということで多少の配慮はしましたが、基本的にAWSチーム(特にリーダーの鹿倉)がほしいものを依頼しました。去年仮想プロジェクトで私たちが仮想プロジェクトで開発した蔵書管理システムは、研修終了後社内で使われる機会が徐々に減っていき今や忘れ去られているので(笑)、今年度は、「仮想」ではあるものの、研修終了後も実際に使うことのできるシステムを依頼しました。また、技術的な観点からも、要件1〜4に関しては、配属後何度となく使うであろうAWS SDKの使い方に慣れることができる、要件5に関しては、(おそらくGoogle App Scriptを使えばできそうだったので、)4月に習ったJavaScriptの知識を活用することができると考え、これらの要件に最終決定しました。

開発に関して

プロジェクトのフェーズを、「設計」「実装(フェーズ1)」「実装(フェーズ2)」「テスト」に分けました。報告会も含めた各フェーズの日数は下記です(AWS研修2日間とAWS Summit3日間はプロジェクト期間から除外)。

  • 設計 :8日
  • 実装 :15日 (フェーズ1 :7日、フェーズ2 :8日)
  • テスト : 7日

IT未経験者に関して

今年度はIT未経験者がおり、4月の研修である程度プログラムは書けるようにはなったものの、ある問題に対して自分でアルゴリズムを考え、それをコードに落とし込む力は、5月以降も引き続き別途鍛えていく必要があると考えました。そこで今年度のIT未経験者に対しては、「時短勤務」という設定で、10:00(始業時刻)〜15:00は仮想プロジェクトへの参加、15:00〜19:00(終業時刻)は個別に上記の力を鍛える補習を行うことに決めました。そして、仮想プロジェクトキックオフで新卒のみなさんに、プロジェクト期間中は、IT未経験者の時短勤務を踏まえた上での話し合い・タスクの分担をするように伝えました。

5月の研修方針と心がけたこと

失敗から学んでもらう

前編の繰り返しになりますが、失敗する前に注意されるよりも、失敗して自ら学んだ方が印象に残りますし、学びは大きいと考えます。仮想プロジェクトではできるだけ先回りして教えることを避け、失敗してからその経験を自分たちで振り返り、そこから学んで次の行動につなげていけるように指導することにしました。

コミュニケーションの取り方を試行錯誤してもらう

コミュニケーションスキルが配属後も非常に重要なスキルになることや、みなさんほぼ初めてのチーム開発ということで、外部の人(お客様)、内部の人(チームメンバーなど)とのコミュニケーションに問題はなかったか、改善できるところはないかを、毎日の夕礼や、各フェーズの最後の報告会で特に細かく指摘することにしました。

技術面でも成長してもらう

とは言え新卒のみなさんはエンジニアなので、コミュニケーションスキルだけではなく、技術面でも成長してほしいと考えました。今年度は私がプロジェクトの開発サイクルの回し方やソースコードレベルまで見て、不十分だと思う点については、補足講義やコードレビューなどの形でサポートすることにしました。

新卒のみなさんの精神的サポート&エンジニアとしてのキャリアパスについて一緒に考える

開発期間が短く、チーム開発に不慣れなため、仮想プロジェクトは新卒のみなさんにとってかなりハードなものになることが予想されます(実体験)。特に精神的な疲れが増してくることが予想されるので、引き続き毎日の夕礼や日々のコミュニケーションで、新卒のみなさんの精神的サポートを行うことを心がけました。

また、去年の自分の反省として、仮想プロジェクト期間中は目先の開発に集中しすぎてしまい、研修後の配属のことや、自分のエンジニアとしてのキャリアパスについて研修中に考える余裕がほとんどありませんでした。今年度は、仮想プロジェクトのことから少し離れて研修後の配属や自身のキャリアパスなどについて一緒に考える時間を、研修中のどこかで設けようと考えました。

仮想プロジェクト期間中に行ったこと

仮想プロジェクト中は基本的に会のセッティングなども新卒のみなさんで主体的に行ってもらいました。仮想プロジェクト中に研修担当側が行ったことも、基本的には新卒のみなさんが行ったことに対するフィードバックだったため、行ったことを箇条書きにしづらいのですが、抜粋すると以下のことを行いました。

  • 補足講座
  • 面談
  • 夕礼での進捗報告に対するフィードバック
  • 各フェーズごとの報告会・その後の反省会でのフィードバック
  • 最終発表会での最終フィードバック

 

補足講座

4月で学んでいないが開発をする上で必要な知識については、補足講座という形で私から新卒のみなさんに講義を行いました。例えば、以下のような講義です。

git講座

開発フェーズに入った頃、gitを使ったバージョン管理の経験がない人が多くいたこともあり、それぞれが思い思いにAWSコンソール上でLambda関数のコードを書いていました。そこで、gitに関する補足講座を行い、gitの基本的な使い方や、リモートリポジトリをGithub上に作成し、ブランチの切り方、マージの仕方、コンフリクトが生じた時の対応などの演習を行いました。

非同期処理、Promise講座

AWS SDKを用いたAWSリソース情報の取得は基本非同期で行われるため、開発が進むにつれ、非同期処理の扱いに苦労している様子が見受けられました。そこで、非同期処理について改めて学ぶ補足講座を行い、その後、実際に新卒のみなさんが書いているコードのどこに問題があるのか、なぜ想定通りの動きをしないのかを一緒に考えました。また、最後に新卒のみなさんのコードを、Promiseを使って一緒に書き換えたりもしました。

面談

研修期間中、複数回面談を行いました。去年は配属先の希望を聞く面談を研修終盤に1回実施しただけでしたが、今年は去年より面談回数を増やし、より手厚く新卒のみなさんのサポートを行いました。また、私が企画した面談(私と新卒のみなさん×5回)では、業務内外での悩みを聞いたり、研修後の配属や自身のキャリアパスなどについて一緒に考えたりしました。

新卒のみなさんとの1対1での面談の実施に際しては、ヤフー様で行われている「1on1ミーティング」を大変参考にさせていただきました。
下記書籍にて非常に貴重な知見を共有していただき、誠にありがとうございます。

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

夕礼での進捗報告に対するフィードバック

4月に引き続き、夕礼は毎日行いました。そこでは、当日のプロジェクトの進捗報告をしてもらうと同時に、チームレベル、個人レベルでの懸念点や疑問点を話してもらい、それに対して研修担当の私からフィードバックをしました。また、プロジェクトの進捗報告は夕礼後にAWSチーム内で共有を行い、プロジェクトの進め方で指摘すべき点はないか、きちんとチームで開発ができているかを他のメンバーと逐一確認していました。

各フェーズごとの報告会・その後の反省会でのフィードバック

最終発表会でのフィードバック

これらに関しては事前に研修担当側が何かを用意するということはなく、新卒のみなさんが自分たちで考えて実行したことに対して、研修担当側から気になる点や、こうしたらもっと良くなる点などをフィードバックしました。各フェーズごとの報告会・反省会には、普段の夕礼と違い、AWSチームリーダーの鹿倉や、開発経験・マネジメント経験の豊富なエンジニア田部井、平井も参加して、より多くの指摘・アドバイスを新卒のみなさんに行いました。その甲斐もあり、6月末の最終発表では、社長の長谷川も絶賛するほどの素晴らしい成果物とプレゼンを披露することができていました。仮想プロジェクトの成果物などについては、新卒の誰かが後日書いてくれるかもしれません。

研修を終えて

最後に、研修を終えて感じたことを書き連ねたいと思います。

研修で学んだこと

地味でも毎日コツコツサポートを続ける重要性

今回の研修で4月、5〜6月にそれぞれ設定していた研修目標は、大方達成することができました。4月の最後のプログラミングテストを見た時は、入社時とは別人のような成長を感じましたし、仮想プロジェクトの最終発表でも、初期とは比べものにならないほど落ち着いて、伝えるべきことを簡潔に伝えることができていました。これは、もちろん一番は新卒のみなさん一人一人の努力の賜物なのですが、事前に入念に準備したカリキュラムや、毎日の夕礼や報告会で細かくフィードバックを行ったことも、その成長の一助となったのではないかと思います。地味でも毎日コツコツ、研修を受けているみなさんのサポートを続けることが、研修を成功させるためにはとても大切なことだと感じました。

来年に向けての反省点

4月の研修が、単に技術を学ぶだけにとどまってしまった

4月の社内技術研修についてですが、書籍や動画を見て学ぶことが多かったこともあり、単なる技術の学習にとどまってしまったな、と感じています。せっかく社内で研修を行っているので、実際に弊社で開発しているアプリがどのように業務に役に立っているのかを、東急ハンズの事例を紹介したりしながら学べる機会などがあれば、もっと良かったのではないかと思いました。実際に開発したシステムを使っているユーザーをイメージできた方が、仮想プロジェクトに対する士気もさらに高まったかもしれません。来年度はAWSチームだけでなく、東急ハンズのシステムを内製しているチームなどとも連携しながら、今年度よりさらに良い研修にしていきたいと思います。

研修担当、1人はつらいよ

今回チーム内のリソースの問題もあり、社内での講義や夕礼などは、ほぼ全て私が担当する形となりました。来年度は、少なくとも2人以上はいた方がより手厚い指導やサポートができるのではないかと思います。また、私は新卒2年目のエンジニアということで、新卒のみなさんと年齢や境遇が近く、質問や悩みを相談しやすいというメリットがある一方で、実務経験を踏まえたアドバイスは、経験のあるエンジニアほどできないというデメリットもあります。来年度は、実務経験が豊富なエンジニアと若手のエンジニアの両方が研修にメインで携わるという体制が、より良い形なのではないかと思いました。

おわりに

6月に無事研修を終え、新卒のみなさんは7月から各チームへと配属となりました。AWSチームに配属された人はいないので(泣)、業務中はやや遠目からみんなの様子を見ることが多いのですが、各々配属先で自分の役割をしっかりと果たしていて、頼もしい限りです。また最近は、新人のみなさんを先輩エンジニアがチームの垣根を超えて指導する機会も増えてきており、弊社の教育熱の高まりを感じています。私も新卒研修担当としての役目は終えましたが、これからはこの新卒研修で得た知見を、弊社の教育体制をより良くするために生かしていきたいと思います。

以上で、今年度の新卒研修のまとめは終わりとなります。
最後までお読みいただき、誠にありがとうございました。


iOSDC Japan 2017で東急ハンズのiOSデバイス管理手法について話しました


こんにちは。
きんちゃん。(Yusuke Kuroiwa)です。

少しだけ、自己紹介します。
東急ハンズで利用している、HandsPOSと呼ばれる自社のiPad POSレジシステムを、Swiftで1から開発してきました。
普段はiOSエンジニアですが、2015年6月頃から東急ハンズの要件にマッチした、デバイス管理も模索しました。

9月17日に、iOSDC Japan 2017東急ハンズのデバイス管理についてお話してきました。
私は、昨年もiOSDCにて、お話をさせて頂きました。
時間がない、スライドだけみたい人は一番下に貼ってます。
スライドの補足もしてるので、ぜひ読んでほしいです。

iOSDC Japanとは

iOSDC (iOS Developers Conference Japan) は、iOSとその周辺技術に関するエンジニアのためのカンファレンスです。

昨年から始まり、今年が二度目のカンファレンスです。
会場も大きくなり、参加者も増え、セッション数も増大しました!
勉強になるようなセッションが多く、懇親会含め非常に楽しかったです。
スタッフの皆様お疲れ様でした。

発表概要

東急ハンズでは、現在3500台超えのiOS端末を管理しています。
主となるのは、PDAとPOSレジです。
弊社はPDAとPOSを、それぞれiPod touch(iPhone)、iPadに自社アプリを組み込み店舗へ配布しています。
今後、POSの展開が進む中、最終的な管理台数は、4600枚ほどに登る予定です。
さて、このような大量のiOS端末はどのように管理するべきなんでしょうか。
iOSDC Japan 2017では、これらの端末を管理するための実際に得た知見、問題点&ハンズラボが実践するエンタープライズ的対処方法についてお話致しました。

iOSのデバイス管理するための課題と解決

実際に大量のデバイスを管理するとなると、下記のような要件が出てきます。

  • キッティングの問題: 開梱してちまちま設定する必要があり、作業を簡略化してして楽にしたい
  • 業務アプリ(In-House app)配布・管理
  • AppStoreにあるようなアプリを配布・管理
  • 社内ネットワークに接続するためのWi-Fiの設定情報の配布
  • デバイスの紛失時の対処をどうするか

上記のような課題は、MDM(Mobile Device Management)やその他の周辺のサービス、合計4つのサービスを利用することで解決ができます。
4つのサービスの詳細は、スライドを参照を。

MDMから端末へアプリインストール通知が届かない問題

MDMを使えば、管理が簡単になり、キッティングも簡単になり、ハッピーになりました。
ですが、サービス仕様的に回避しようがない問題がたまに現れます。

その1つが、MDMから端末へアプリインストール通知が届かない問題です。
MDMからの端末へコマンド発火はすべてプッシュ通知と同じ原理(APNS)を利用しています。
その為、プッシュ通知が届かない端末へは、デバイスの各種情報、アプリのインストール情報、アプリインストール等ができなくなります。

この中でも特にアプリインストールに関しては、自社のPOSレジ(HandsPOS.app)を配布運用している弊社には大問題です。
プッシュ通知がとどないと、アップデート出来ないのです。
アップデートに失敗すると店舗内で隣のPOSレジはある機能が乗ってるけど、また隣のPOSレジはその機能がないというような問題が発生します。

プッシュ通知が届かないのは、デバイスを再起動を行えば、一時的にプッシュ通知が届くようになりなりますが、数日経てばまた届かなくなります。
根本的な、解決に随分の時間を割いてきました、ポートを開けたり、Wi-Fiを切れないようにしたり、、、根本の解決できず諦めました。
ようわからん。

弊社は、Harakiri-Updater(切腹アップデート、自社でのアプリアップデート手法の呼称)で回避しています。
CrashlyticsのAd-Hoc配信でも同じような方法が利用されていました。

下記に貼っつけているのが、実際にHarakiri-Updaterを行ってみた動画です。

  1. アプリが起動した瞬間に、サーバへ必要なバージョン情報を取得
  2. 必要なバージョンより自分のアプリのバージョンが下回っていれば画面にアラート
  3. 従業員の了解を得たら、スライドに乗ってあるURLスキームを開きます( UIApplication.shared.openURL(plistURL) )
  4. アプリを自爆します。※
  5. URL scheme契機で、システムアラートが表示されます。これはたとえ、アプリが死んでも死ぬ前に発火しておけば表示可能です。
  6. 「インストール」ボタンを押してインストールを続行します。

※ iOS 10以下であれば、自爆は不要です。iOS 11では5番で出て来る「インストール」ボタンを押しても自爆しません。
if #available(iOS 11.0, *) 等で対応しておけば良いでしょう。

他にも

上記で紹介した問題にもエンプラのiOSアプリを運用するにはたくさんの課題と解決をしてきました。
昨年のiOSDCでは下記のような内容もお話しました。

  • iPadを有線化する
  • プッシュ通知でアプリを殺して自動アップデートする
  • iPadがスリープ状態でもお行儀とか考えず、バックグランドで音声流して大量のデータを裏でさばく
  • キッティングが問題ないかを確認するために LibMobileGestalt.dylib の利用

バッドノウハウを駆使してでも業務要件に答えなければなりません。
ですが、安定性が一番大事です。そこも考慮しつつ実装・導入は欠かせません。
HandsPOSに関しては、Crash freeは98%-99%です。

iOSの話ししながら手羽先食べます

【iOSエンジニア向け】ハンズラボようこそiOS手羽の会
2017/09/27(水) 19:30 〜 21:30、東新宿で行います。
うまい手羽先食べながら、弊社のことはもちろんですが、iOSについても話しましょう!

スライド公開

スライド公開しているのでぜひ見てください。

nsnextstep.fmにて

先日のnextstep.fmで、今回のiOSDCの中で面白かった発表と評価いただけました!
ありがとうございます!


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


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

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

環境

流れ

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

やっていきます。

トークンから公開鍵を作成(node.js)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実行する。

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

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

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

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

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

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

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

まとめ

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


HandsPOSゆるふわ開発フロー


最近は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ファイルを変更していたらスクリーンショットのせてねルールが独特でしょうか。あまり使いこなせている感がないです。

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/