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

HANDS LAB

HANDS LAB ENGINEERS BLOG

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

Go言語 初心者向けハンズオンに行って来た

Pocket

はじめに

こんにちはハンズラボの清水です。
株式会社メディアドゥさんのGo言語 初心者向けハンズオンに参加させていただきました。

清水の最近の経験言語

  • Python: 大学からの付き合い(軽く機械学習の真似事ができるくらい)
  • javascript : Node, jQuery 研修でやりました
  • PHP : 業務で使ってます

Go言語の知識

  • 関数を使ったら戻り値とerror値が返ってくる
  • if err != nil をとりあえず沢山書くらしい
  • メルカリさんが使っている

会場に到着


サイバー感すごい!

手塚治虫作品が沢山!

勉強会開始

資料


事前にスライドが公開されているので手元のPCでも見ながら確認できるのでとてもよかったです。

練習問題がある

私も勉強会には月2~3回ほど参加していますが練習問題がある勉強会は初めてでした。
ハンズオン形式の勉強会は多くありますが、練習問題があることによって、自分で考えて実装するのでより意欲が湧いて来ます。(スライドの後半に課題があります)
資料:Go言語でシンプルなWebAPIサーバーを実装する
練習問題は全部6問あり、資料を参考に解いていきました。時間制限もあったので全部解くぐらいの意気込みで挑戦したら、思いの他1問目で手こずってしまい3問目までしか解くことができました。(相当ググりまくっていました)
そして、想像通り if err != nil を結構描きました。

一部を紹介

これは1問目のコードの一部ですが、strconv.Atoiを使用して文字列を数値に変換するのですが数値だけでなくerror値も帰ってくるのでGoではこのようにエラーハンドリングを行うようです。

勉強会を終えてGo言語に私が思った感想は

  • ところどころC言語的なものを感じる(変数宣言、ポインタとか)
  • go get便利
  • 色々と覚えることが多いが学ぶのが楽しそう
  • 並列処理やってみたい(goroutine, channel)

最後に

今回の株式会社メディアドゥさんの勉強会はとても楽しく、練習問題で自分がどこまで実装できるのかといった挑戦もあるので次の学習のきっかけになる勉強会でした。
機会があるのであれば次回も参加したいと思っています。

ハンズラボはエンジニアを募集中です。 https://www.wantedly.com/companies/hands-lab

Pocket

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