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

HANDS LAB

HANDS LAB ENGINEERS BLOG

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

SPA初心者が管理画面をAngularで作った話

Pocket

新入社員(?)の原と申します。

6月末で仮想プロジェクトが終わり、現在はサービス開発チームでPostfor のフロントエンドでAngularを書いたり、serverlessと戦ったりしています。

仮想プロジェクトではPostforの管理画面をAngularで作りました。

仮想プロジェクトについて

仮想プロジェクトとは、新卒の社員がお題を渡されて、要件定義・設計・実装・リリースまで新卒だけで行うというものです。

私たちのチームのお題はPostforの管理画面で、ユーザー様のご利用状況を確認できたり、ビジネス側の運用が楽になるようなアプリケーションを作りました。

 

 

↑実際の画面

技術構成はフロントをAngular、バックエンドをAWSのServerless Architectureで実装しました。

このブログでは私が担当したフロントエンドについてお話します。

フレームワーク選定

バックエンドがサーバレスという性質上、SPAにすることは必然でした。

しかし私自身1からSPAを作ったことがなく、期間が約1ヶ月と短かったため、どのフレームワーク(ライブラリ)を使うか悩みました。

Vue.jsが比較的習得が簡単だという話を聞き、Vue.jsも触ってみたのですが、結局サービス本体と同じAngularに決定しました。

選定理由としてはPostfor本体でも使っているという他に、公式のチュートリアルが充実していたということがありました。これを一通りやるだけで、

  • コンポーネントの分け方
  • サービスのDI
  • ページ遷移の方法
  • バックエンドAPIとのhttp通信
    を学ぶことができ、簡単なSPAを作ることができました。

 

またAngularに決定してから実感したことですが、routerなど必要不可欠な機能が全て入っていたり、ビルドも簡単にできることもありがたかったです。

Angular Materialを使うと、簡単にマテリアルデザインのUIが出来上がることも非常に嬉しいことでした。Angularチームが公式に作っていて安心感もあり、ドキュメントも豊富でわかりやすいです。モーダルやローディングのスピナーなども簡単に実装できました。

RxJSと状態管理

RxJSを使わない??

AngularはRxJSに依存していて、そのことが学習コストになると言われています。

自分は非同期処理について、PromiseはギリわかるけどRxなにそれという状態でした。

当初は非同期処理はhttp通信の部分くらいだと思っていたので、http通信にはAngularの標準のhttpClientではなくaxiosを使うことでRxJSではなくPromiseでうまいことしようと考えました。

またcognitoやS3にアクセスするためにAmplifyを使ったのですが、これもPromiseを返すので、非同期処理はほとんどPromiseで済むと考えました。

状態管理

しかし状態管理の問題に突き当たり、RxJSの必要性が出てきました。

具体例でいうとログインしているユーザーの属性によって、各コンポーネントの表示内容を切り替える実装のため、ユーザーのデータをどこからでも参照できるようにする必要がありました。

当時はfluxのアーキテクチャを知らなかったため、こちらの記事を参考にさせて頂き、service層にBehaviorSubjectを置いて、データが必要なコンポーネントでsubscribeできるようにしました。

結局RxJSを使う必要が出てきましたが、今回作った管理画面レベルのシンプルなアプリケーションは、Rxのオペレーターを複数覚える必要はなく、promise.then()がobservable.subscribe()に変わったという程度の理解で作ることができました。

仮想プロジェクトを終えて

試行錯誤しながら1からSPAを作れた経験はとても成長できたなと感じています。特に状態管理の問題に突き当たった経験のおかげで、fluxのアーキテクチャの必要性も実感することができました。

配属後はPostfor本体の開発をしています。Postforでは状態管理にngrxを使っていて、状態管理を一元化できる恩恵を感じながら開発をしています。(Redux DevToolsめちゃ便利)

最後に。
フロントエンドエンジニア募集してます!
https://www.wantedly.com/projects/233008

Pocket

AWS Single Sign-On環境の構築を検討してみる

Pocket

こんにちは。クラウドチームの北野です。

現在、AWSアカウントの管理やらAWSインフラのお世話をしたりしています。

ハンズラボではシステムインフラにAmazon Web Service(AWS)を積極的に採用していて、
サーバはほぼ全てAWS上で稼働しています。

何百台というサーバが常時稼働しているので、当然一つのAWSアカウントに収まるわけも無く、何十個ものAWSアカウントが存在しています。

ここまでAWSアカウントが増えてくると、AWSアカウントの管理自体が煩雑になってきます。

AWSヘビーユーザーだと似たような悩みを抱えることが多いと思いますが、
そんな時に参照するのが、AWS公式が公開しているAWS Answersです。

AWSにおけるアプリケーションの設計、構築のベストプラクティスが公開されています。

AWS Answersでは、マルチアカウント戦略のベストプラクティスであるAWS Landing Zoneが公開されています。

今回はマルチアカウント戦略のベストプラクティスの一部分である、AWSログインを一元化するAWS SSO環境の構築を検討してみます。

構成

構成図はこんな感じです。
AWS SSOがバージニア(us-east-1)にしか対応していなので、全てバージニアリージョンで構築しています。

AWS SSOではユーザー管理にActiveDirectoryを使用します。

AWSのDirectoryServiceで連携する必要があるため、マネージドサービスであるMicrosoftADを利用するか、既存のADサーバに対してAD Connectorを利用して連携します。
今回はAD Connector + SimpleADで構築しました。

認証はユーザーID/パスワードで行いますが、多要素認証も無いとセキュリティ的に不安です。
AWS SSOでは自前でRemote Authentication Dial In User Service(RADIUS)サーバを用意することで、多要素認証に対応できます。
今回はEC2インスタンスを建てFreeRADIUSを使って、RADIUSサーバを構築して多要素認証を実現しました。

今後の課題

多要素認証のためにRADIUSサーバを自前で構築してみましたが、本番導入するには運用が辛そうです。

EC2単体で立ててしまうとRADIUSサーバが単一障害点になってしまうため、冗長構成にしなければいけません。
そのために、ADサーバとのユーザ同期、多要素認証用のユーザ情報の分離…と考えだすと大変なので外部サービスを利用したいです。

先人の知恵をお借りすると、DuoやOneLoginといった外部サービスを利用して多要素認証を実現しているようなので、このあたりの利用を検討しています。

AWSには是非AWS SSOの東京リージョン対応とマネージドサービスでの多要素認証に対応していただけたらなーとお祈りしています🙏

Pocket

メンティとして1ヶ月経過してみて

Pocket

こんにちは!新卒の川永です。

7月から他社様向け小売系基幹システムの開発チームに配属され、分からないことだらけの中日々奮闘しております。
今は主にPythonでAPIを作ったりしています!
その中で、メンティとして感じたことを書いていきたいと思います。個人的な感想ですので温かい目で見て頂けると幸いです。

メンターとの面識

私は、メンターの面識はあった方が良いと思いました。
メンターと面識があることによって、分からないことの多いチームに加わった直後でも質問がとてもしやすかったです。
また、メンターを介して他のメンバーとコミュニケーションが取りやすく結果として早くチームに馴染むことができたように思えます。

メンターと関係を築く

仕事以外の話をする時間が大切だと感じました。
チーム等で一緒に食事に行って趣味や好きなもの嫌いなものの話をすることによってよりフランクな関係になり小さな相談事やプライベートな話をしやすくなりました。
ですが、話しやすい雰囲気がある事が前提かなと思います。
(そこが難しいところだとは思いますが)
あくまで気軽に話ができるのが大切です!

メンター以外のメンバー

個人的にはこれがもっとも重要だと感じました。
メンバーが協力的であるとチームとしてメンティの疑問を解決でき、メンター以外の様々な意見を聞くことができます。
そうすることで、私はチームとして働くという意識が強くなりました。
また、メンターはメンティとメンバーの架け橋的役割も担うのがよいのかなと思いました。

メンティとして心掛けたこと

・質問する時は自分が今何に困っていてどうしたいのかを明確にしてから聞くこと。
・メンター以外の人にも質問し見識を広めるようにすること。
・分からない時は素直に言うこと、聞くことが仕事という意識を持つこと。

以上いかがでしたでしょうか?
私なりの考え方なので色々ご意見等あるかもしれませんが、参考になればと思います。

Pocket

見よう見まねで機械学習をやってみた(ポケモン編)

Pocket

こんにちは!新卒の清水です。
最近、勉強または趣味でやっていたPyQの機械学習・初級をやり終えたので自分でもやってみました。

題材

以前Kaggleのチュートリアルはやったことはありますが、用意されているデータの説明がやはり英語だったのでそれなりにハードルがありました。
なので今回はネットを放浪中にポケモンのcsvデータがあったので、これを使用して行きたいと思います。

何をする?

個人的にみずタイプのポケモンが好みなのでステータスからみずタイプかどうか判定しようと思います。

環境

OS: macOS High Sierra 10.13.5
Python: 3.6.5
scikit-learn : 0.19.1
jupyter notebook

とりあえずデータをみてみる

pandasを使用してcsvデータを読み込みます。

ポケモンが909体(メガ進化も含む)なのでどうやら第七世代(サン・ムーン)までのデータのようです。

データの選別

ポケモンの各ステータス(HP, こうげき, ぼうぎょ, とくこう, とくぼう, すばやさ)を説明変数X、タイプを目的変数yとして学習させていこうと思います。
みずタイプであるのか、そうでないのかで判断したいのでみずタイプのポケモンには1をそうでないものには0を付与します。

関数を用意

applyメソッドを使用すると指定した列データ全てに関数を実行してくれます。
データをみてみましょう。

みずタイプが含まれている行を出してみました。みずタイプには1が振られています。

学習させる

もちろんscikit-learnを使用して学習させます。
今回は目的変数が2値なのでロジスティック回帰で行います。

トレーニングデータとテストデータの割合は7:3で分割します。

C = 1000としていますがこのCはハイパーパラメータと呼び、Cの値が大きすぎるほど過学習しやすくなり、小さすぎると学習にならない問題があります。
今回はCの値を0.01, 0.1, 1, 10, 100, 1000とパラメータを変えて影響があるか確認し、特に影響がなかったので1000のまま放置してます。

およそ87%の割合で判定することができました。
ほぼ自分一人の力で機械学習をしたのは初めてなのでまぁまぁいいのではないかと思います。

考察

判定に失敗した例としてオーダイルをみずタイプではないと判定しました。
そんなにポケモンを知らなくても、見れば多くの人はみずタイプだろうと判断するでしょう。

しかし、オーダイルの進化前のアリゲイツはみずタイプと判定しました

改善案としてはステータスの族ごとに学習をさせることで改善することはできると思います。
ですが、より高い精度を求めるならポケモンの画像データを使用するのがいいと思いました(全体的に青っぽいとか)。

最後に

ポケモンの知識がないと難しいところがあるのでやはりデータのリサーチは必要だということを感じました。
全体的な機械学習の流れは覚えられてきたのでこれから色々と試していきたいと思います。

Pocket

楽しく情報共有できるSlack活用術

Pocket

はじめまして。2018年4月新入社員(?)の原(@hxrxchang)と申します。

(”?” としてあるのには深い事情があります。。。詳しく知りたい方はオフィスに遊びにきてください。)

今回は、弊ラボ内で行われているSlack活用術について書きたいと思います。

Slack楽しく使っていますか??

Slackをただの連絡ツールとして使ってないでしょうか??

緊急連絡や進捗確認、議事録の共有くらいにしか使わない

なんてこともあるかもしれませんが、それだとちょっと息苦しいですよね。

就業中も終わった後もお休みの日までも、楽しくてついついSlackを開いちゃうような活用術をご紹介します。

分報を導入しよう!!

日報ならぬ分報です。

日報は1日に1回その日に行った作業や、次回の予定などを書くものですよね。

分報は1分に1回、その分で何をしたか、次の分に何をするか書くもの。。。

ではありませんのでご安心ください。

好きな時に好きなことを呟いていい、言うならば社内Twitterです!!

弊ラボでは、#times_◯◯(苗字のローマ字) という名前で各々チャンネルを作り、自由に呟いています。

呟く内容は

  • 読んだ記事の共有
  • 業務で嵌った点
  • ランチで食べたいもの
  • 休日の出来事

などなど、本当に自由です。

↑ラーメン二郎桜台店に感動した次の日に、node v10の console.table() に感動している私です。

分報導入のメリット

分報導入にはメリットがたくさんあります。というかメリットしかない??

私が感じたメリットを何点かご紹介します。

1. 技術のアンテナが広がる

弊ラボでは様々な技術が使われております。

例を挙げると開発言語では、

JavaScript、Python、PHP、Go、Shell Script、Swiftなど

またAWSの各種サービスを使用しているので、エンジニアの関心も多岐に渡ります。

そのため共有される情報も様々で、毎日知らないジャンルの情報に触れることができます。

私はJSしか触ったことがなかったのですが、入社してから

AWS LambdaでAlexaスキルを開発したり、機械学習のためにPythonをはじめてみたり、

Dockerで環境を構築してみたり、日々今まで知らなかった技術に触れることができています。

2. 気軽に質問できる

分報では情報を発信する他、質問することもできます。

gitの研修があったのですがその際に、

pull と fetch + merge どっちを使うべきなのかふと疑問に思い、以下のように呟いてみました。

研修にはメンターの先輩がついているのですが、こうして分報で呟くことで、会社全体の先輩方からアドバイスを受けることができます。

疑問があるけど誰に聞けばいいか分からない、いろんな人の意見を聞きたい時に気軽に呟くことができます。

ちなみに弊ラボでは、fetch + merge派が多数でした。

3. 自分から発信することで理解が深まる

私が記事や嵌った点を共有する時には、いいと思った点など何か一言添えるようにしています。

一言でもコメントを加えるには、記事の内容をしっかり読む必要があります。そうした心がけが少しでも理解に繋がるのではないかと思います。

自分が共有した内容にリアクションが多くついたり、コメントが来たりすると嬉しくなり、

もっと共有したい!!

ってなることでインプットの量が増える、という好循環になると楽しいです。

まとめ

以上、分報を使ってSlackで楽しく情報共有しよう! という記事でした。

デメリットを強いて挙げるなら、

Slackが気になって見すぎてしまうということでしょうか。

そうなったら ⌘ + q で閉じてあげましょう。そして落ち着いたらまた開いてあげましょう。

そんなデメリットを凌駕するくらい分報はいいものです。

ぜひ導入してみてはいかがでしょうか!?

 

 

 

 

Pocket