RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

Udemyを利用してみた!!

どうも、NIR-AMAUQAです。寒い日が続いていますね。
そんな時はできるだけ家に引き籠りたい!!
そして、家で何か勉強したいということで…
今回はUdemyというサービスを利用して、スキルアップを試みるお話です。
※ 投稿時点では、まだ受講途中です。

Udemyって何?

Udemyとは多数の講座をeラーニングで提供するサービスです。
実際にサイトを見てみるといろいろな種類の講座があるのがわかると思います。

www.udemy.com

言語は英語が中心ですが、日本語の講座も結構あります。
※英語の講座でも、字幕付きの講座もあるみたいです。

パッと見た感じだと有料コンテンツが多いですが、無料コンテンツもあります。
トップページで無料と検索すると、少しですが出てきます。

なんでUdemyを受けようと思ったのか

先日、社内メールでUdemyの講座で業務もしくは技術に関連するものであれば会社負担で受けられますよという連絡がありました。
これはエンジニアにとってはかなり嬉しいですね!!
業務に直接関係ない講座でも技術関連であればOKとのことでした。

そして、eラーニングでのスキル学習に興味もあったのでやってみよう!!
という経緯です。

そもそも社内メールを見るまで、Udemyの存在を知りませんでした。(無知なのは突っ込まないでください。笑)

どんな講座を受けたのか

技術関連であればOKとのことでしたので、以下の条件で探しました。

結果、今回は全く触ったことのないSwiftの勉強をすることに!!
Xcodeにも触れたことが無かったので初心者用講座を探しました。
いろいろあった中から「【Swift4.0対応】超豪華版!未経験者が有名アプリ開発者になるiOS 11の全て 20個以上アプリをつくりプロになる」を選択。 www.udemy.com

余談ですがSwiftを選択したどうでもよい理由

  • 去年買ったMacBookが自宅で放置されている
    エンジニアとしてそれはどうなのか…デスクトップ派なもので…)
  • 流行ってるものは触ってみたい
  • 友人にiOSエンジニアが多いから気になった

理由はどうあれ、きっかけがあれば良いと思います。(笑)

講座内容を簡単に紹介

有料コンテンツなので詳しくは書きませんが少しだけ…

未経験者にフォーカスしていることもあり、Xcodeをインストールする所から丁寧に解説されていました。
プログラムの基本的な知識や構文の書き方などに関しても解説されています。
※ 用語に関しては未経験者の方は調べながらやった方が理解しやすいかと思います。

アプリ作成に使用する画像なども用意されているので、プログラムの経験者であればすぐに作成することが出来ると思います。
参考までに最初の方に作った物のサンプルを載せておきます。

  • パラパラ漫画的なのを再生
    タイマーの使い方や、ボタンを押したときの処理を学ぶ項目にて。
f:id:NIR-AMAUQA:20180213122656p:plain:w300
  • ログイン画面的なやつ
    テキストボックスの操作やキーボードの使い方を学ぶ項目にて。
    ラクスカラーっぽくしてみました。
f:id:NIR-AMAUQA:20180213120547p:plain:w300 f:id:NIR-AMAUQA:20180213120601p:plain:w300

学習の進め方

動画と並行して手を動かす

私の選択した講座はハンズオン形式でしたので、基本的には動画を見ながら手を動かして進めていきました。
一度購入した講座は何度でも見れるので、聞き逃した所なども再度見ることができます。

学習した項目を応用

学習した項目に関しては、自分のスキルにするために自分が納得するまで調べたり操作したりしました。
再度同じことをしようとしたときに、自分の思い描いた通りにできるのが理想ですね。

隙間時間を活用

少しだけ空いた暇な時間などには積極的に進めるようにすることで無駄な時間が無くなりました。
動画と並行で進めるとは言っても、先に内容を知っておいた方がやはり効率が良いので、通勤中の電車で動画を見て予習をしました。
Udemyはスマホアプリ版があるのでいつでも動画を見ることが出来るのは良かったです。
※ 動画を見ていた続きから再生されるので、PCとアプリを交互に使う際に手軽でした。

Andorid版 play.google.com iPhone

この記事を書いている時に知ったんですが、スマホでオフライン時に再生するためにあらかじめダウンロードができるようです。
これを利用すると、モバイル通信費を節約できるのでいいですね。

https://support.udemy.com/hc/ja/categories/204119668-%E3%83%A2%E3%83%90%E3%82%A4%E3%83%ABsupport.udemy.com

躓いた所

プログラムとかは問題なかったのですが、Xcodeの使い方に慣れていなくて躓いたなってところがありました。 iPhoneアプリ作ったことのある人にとっては当たり前の事だと思いますが、解決するときに参考にした記事を紹介しておきます。

  • シミュレータでのUIの配置箇所がおかしい

ideacloud.co.jp

  • シミュレータでキーボードが出てこない

qiita.com

yutaihara.com

  • UIパーツとプログラムの紐づけでエラー

ios.steppers-hi.net

やってみた感想

まとまった時間は取れないけど勉強したい方や巷で行われている勉強会のスケジュールに合わない方には良いサービスだと思います。
実際、マイペースで進められるのは結構気が楽でした。
ただし、マイペースで進められるので自分で学習するという意思が無いと三日坊主になりそうなので注意です。

利用してみて一つ難点かなと感じたのは、ノートPCのみの場合は動画を見ながら並行で進めることが難しいところかと思います。
回避策として、私はデスクトップで動画再生しながらMacBookを操作していました。

現時点では講座の途中ですが、結構学んだことが多くスキルアップに繋がっていると感じれているので満足しています。
簡単なアプリであれば今でも作れそうだなって感じなので、講座を受け終わったころに何かアプリ作れたらいいなと思っています。
今後も気になる講座、特に人工知能や業務関連でフロントエンド系の技術の講座は積極的に受けていきたいです。

ARKit + Unityのサンプルアプリで手軽にAR体験

こんにちはsts-250rrです。

今回は最近リリースされたiPhoneのOSであるiOS11から追加された「ARKit」を少し触ってみましたので紹介したいと思います。

あまり業務的ではありませんが、昨年はVR元年と言われ3D関連は少しだけホットな話題ですよね。インタラクティブな内容になっていますがお付き合いいただければ幸いです。

ARKitってなに?

ARKitはその名の通りAR(拡張現実:Augmented Reality)なアプリケーションを開発するためのフレームワークです。

何か特別なセンサー類を用意せずともARアプリの開発が可能になったためハードルは下がったのではないかと思います。

ARKitでの開発を始めるために必要なものは以下のものです。

ハードウェア
  • Mac macOS Sierra以降
  • iPhone 6s以降でiOS11が入っているもの
ソフトウェア
  • Unity version5.6.2以降
  • Unity ARKit Plugin
  • Xcode version9以降
Apple Developer のライセンス
  • 今回はAppStoreに公開するわけではないため無料のもので良いです。 無料ライセンスでもアプリを3つまでiOSバイスに転送できます。サンプルを動かす分には十分です。

Unityでサンプルアプリを動かしてみる

Unityでプロジェクトを作成

まずはUnityでプロジェクトを作成していきます。 プロジェクト作成時点で注意すべき点はありませんがプロジェクト名を「ARSample」とでもしておき、[Create Project]しましょう。 作成が終わるとUntitledという名前のシーンが作成された状態になります。 私も3DモデリングやUnity自体に詳しいわけではないですが、シーンとは3Dオブジェクトを配置していくための「舞台」であると解釈しています。 f:id:sts-250rr:20180204190645p:plain iOS用のビルド設定を行う

Fileメニューの[Build Settings]を開くと図のような画面が開きます。 [Platform]にiOSを選択して[Switch Platform]ボタンを押してビルド設定をiOSにします。 ※iOSの項目にUnityのアイコンが表示されているはずです。 f:id:sts-250rr:20180204190748p:plain

UnityにARKit Pluginをインポートする

UnityのWindowメニューから[Asset Store]を選択すると画面上にAsset Storeが表示されます。 Asset StoreはプラグインやUnityで使用できる3Dモデルや素材を画像などを購入することができます。無料のものもあるので色々探してみるのも良いと思います。 f:id:sts-250rr:20180204190910p:plain

話を戻しましょう。Asset Storeの検索フォームから「Unity ARKit Plugin」を検索し、インポートします。 ダイアログが出てくる場合がありますが、特に問題はないようなので気にせずインポートします。

ボタンをぽちぽちしているとなんのパッケージをインポートするのかといった画面が出てきますので全てのチェックボックスにチェックが入っていることを確認し[Import]しましょう。 f:id:sts-250rr:20180204191053p:plain

インポートが完了すると[Project]ウィンドウの[Asset]フォルダに[Unity ARKit Plugin]のフォルダが作成されます。
これでUnityでARKitプロジェクトを作成する準備が整いました。 f:id:sts-250rr:20180204191338p:plain

ARKitのサンプルを開く

[Unity ARKit Plugin/Example/UnityARKitScene]にサンプルのシーンがあるのでダブルクリックして開きます。
[Scene]ウィンドウに切り替えると図のようなシーンが表示されています。この画面をARで表示していくわけです。
左側のタブに表示されているものはシーンに追加されているオブジェクトの一覧です。
今回は3Dモデリングに関しての話がメインではないので割愛します。

ARKitサンプルのビルド設定

再びFileメニューの[Build Settings]を開き、上部のUnityARKitSceneのチェックボックスをチェックします。
次に[Player Settings...]ボタンを押すと[inspector]タブにiOSの用のプレイヤー設定画面が表示されます。
[Other Settings]の項目を設定していきます。設定を行う項目は以下の3点です。

  • Identification [Bundle Identifier]
    「com.unity.arkitscene」という文字列が入っていますが、ここの固有(一意)のものでないといけません。自身でドメインを持っておられるような方はドメインを入れてしまうのが手っ取り早いです。
    ここが固有のものでなかった場合、後の工程でつまづきます。(筆者談)

  • Configuration [Camera Usage Description]
    「AR BABY」の文字列が入っていることを確認します。
    ここの値は今回作成するARアプリがiPhoneのカメラにアクセスする権限を得るために必要なようです。 (よくある「〇〇がアクセスを求めています」のやつ)

  • Supported URL schemes [Target minimum OS Version]
    中身の値を「11.0」に変更。

Build Settingsのウィンドウの[Build And Run]を押下して、任意の名前(UnityARKitSceneで良いです)で保存しビルドを始めます。 処理が完了すると、Xcodeが起動し「Unity-iPhone」のプロジェクトが表示されます。 f:id:sts-250rr:20180204191629p:plain

サンプルアプリの実行

MaciPhoneを接続し、Xcodeの左上の▶️ボタンを押すとiPhone側にアプリが転送され問題なく完了するとiPhone上でアプリが起動します。カメラへのアクセス許可を求められるので、拒否しないであげてください。
カメラ画面が表示されると画面上に黄色い点が表示されたり、水色の枠が表示されます。黄色い点は特徴点、水色の枠は水平面を認識していることを示しています。水色の枠内をタップすると立方体が設置されます。
この立方体は水平面上に配置されているので、回り込んでみたりするとまるでその場所に置いてあるように見えます。
色々なところをぐるぐる見回してみたり、平面に立方体を設置してみてAR体験をしてみてください。

f:id:sts-250rr:20180206110654p:plainf:id:sts-250rr:20180206110759p:plain

まとめ

簡単なサンプルでしたがいかがでしょうか?
実際にアプリを開発しようと思うと3DモデリングiOSアプリ開発の知識が必要になるかと思いますが、比較的ハードルが低く感じられたのではないでしょうか?

筆者の感想としては、iPhoneの優秀さが感じられ非常に手軽に楽しく開発ができそうだなと思いました。

みなさんのアイデアをぜひARで実現してみませんか?


  • エンジニア中途採用サイト
    ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております!
    ご興味ありましたら是非ご確認をお願いします。
    20210916153018
    https://career-recruit.rakus.co.jp/career_engineer/

  • カジュアル面談お申込みフォーム
    どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
    以下フォームよりお申込みください。
    forms.gle

  • イベント情報
    会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください! rakus.connpass.com

Google Homeがブログの記事タイトルを読み上げるアプリを作って公開した話

id:radiocat です。Google Home MiniとAmazon Alexa Dotの二刀流プレイヤーです。

先日、このブログのタイトルを読み上げるGoogle Assistant対応アプリの申請が承認されました。

Google Assistant | RAKUS Developers Blog

お手元のGoogle HomeスマホGoogle Assistantを起動し、以下のように呼びかけてみて下さい。

OK Google, RAKUS Developers Blog につないで

スマホの場合は以下のように最新5件の記事のタイトルと投稿日、そしてこのブログへのリンクが表示されます。スピーカーの場合はタイトルと投稿日を読み上げます。

f:id:radiocat:20180204142146p:plain:w300

しばらくは新着一覧にも表示されるようです。スマホGoogle Assisntantを起動して「使い方・ヒント」を表示すると新着一覧が出てきます。

f:id:radiocat:20180204143908p:plain:w300 f:id:radiocat:20180204144224p:plain:w300

今回はこのアプリを作る手順と公開するための申請手順について簡単にまとめてみました。

アプリの開発

基本的な開発の流れは以前この記事にまとめられていますのでまずはそちらを確認してみてください。

tech-blog.rakus.co.jp

今回作ったアプリの全体の構成イメージは以下の図のようになります。

f:id:radiocat:20180204145840p:plain

ブログ情報を取得する機能はNode.js+Expressで実装しました。

Action on Google

プロジェクトを作成し、ActionsにDialogflowを設定します。それ以外の入力項目はアプリの申請時までに入力を完成すれば良いので、いったんは未入力またはダミー入力で構いません。

f:id:radiocat:20180204151319p:plain

Dialog Flow

今回のアプリはブログの情報を応答するだけで会話をしないので、Default Welecom Intentに直接 Use Webhook を設定しました。また、今のところ応答後に会話を継続させる機能もないので End conversation を設定しました。つまりアプリにつなぐとブログ情報の応答を返してすぐアプリは終了します。

f:id:radiocat:20180204152012p:plain:w500

Heroku(Node.js)

Heroku上でNode.js+Expressを使ったGoogle Assistantアプリの基本的な開発手順については以前Qiitaに公開していますので、まずはそちらを参照してみてください。

qiita.com

メインとなるブログ情報を取得して応答する機能の主要な部分について以降で解説していきます。

RSSフィードを使ってブログ情報を取得する

応答を返す前に、まずブログ情報を取得する必要があります。 当ブログが利用しているはてなブログはブログのURLに /rss を付けるとRSSフィードを取得できます。このURLを利用して記事のタイトルと投稿日を取得することにしました。RSSフィードJSON形式で取得するためにFeedParserというライブラリを使います。

github.com

詳細は上記の公式サイトにまとめられていますが、ざっくり以下のような流れでRSSフィードを取得できます。

  // RSSフィードを取得する
  http.get(BLOG_RSS_URL, function(res) {
    res.pipe(new FeedParser({}))
      .on('readable', function() {
        var stream = this, item;
        // 最新5件だけ取得
        while (item = stream.read()) {
          if (itemCount >= 5) {
            break;
          }
          // item.title のように必要な属性を取得

スマホから呼ばれた場合だけブログのリンクを付けて応答する

スマホから呼ばれたかどうかはWebhookのリクエストのJSONsurface.capabilities をチェックすることで判別できます。詳細はQiitaにまとめています。

qiita.com

また、Google AssistantにはBasic Cardというリンク付きのカードを表示するRich Responsesという仕組みが準備されています。これもQiitaにまとめています。

qiita.com

これらの仕組みを使うことでスマホの画面ではちょっとだけ見栄えを向上させることができます。

HerokuにデプロイしてDialogflowに設定

RSSフィードからブログの情報を取得してJSONでレスポンスを返す仕組みが完成したらHerokuへデプロイし、そのURLをDialogflowのFulfillmentに設定します。

f:id:radiocat:20180204183524p:plain

あとはAction on GoogleのSimulatorで問題なく動作することが確認できれば公開するアプリの準備は完了です。

アプリの申請

いよいよアプリを公開するために申請の準備を行います。基本的にはAction on Googleの画面で全ての項目を入力するだけです。必須項目を全て入力すると以下のように SUBMIT DRAFT FOR REVIEWボタンが押せる状態になります。

f:id:radiocat:20180204183939p:plain:w700

アプリの起動ワード

Sample invocationsでアプリの起動ワードを設定します。「○○につないで」や「○○と話したい」という言葉を設定します。今回は会話系アプリではないので「○○につないで」というワードのみ設定しました。

f:id:radiocat:20180204192006p:plain:w600

アプリの画像

以下の2つの画像を準備する必要があります。

  • Large banner image (1920 x 1080)
    • Google AssistantのアプリのページのTopに表示されるバナーです
  • Small square logo (192 x 192)
    • アプリのページやアプリ一覧で表示されるアプリのロゴです

f:id:radiocat:20180204184921p:plain:w300

プライバシーポリシー

今回のアプリでは特に個人情報を扱うことはないので以下のような簡単なページを準備しました。Herokuを使うのでExpress上に静的ページを準備して配置しました。

f:id:radiocat:20180204185330p:plain:w500

アプリの利用範囲

今回は特に制限していませんがSurface capabilitiesでアプリをスピーカーだけ、スマホだけの利用に制限することもできます。

f:id:radiocat:20180204190108p:plain:w600

審査

申請するとその翌日には結果が返ってきました。一度目は申請内容に不備があってリジェクトされました。指摘は2点で1点は単にプライバシーポリシーのURLが間違っていたためで、もう1点は以下のような起動ワードが不適切という指摘でした。

Sample Invocationsでは、<アプリ名、または、 Pronunciation + Trigger Phrase>を組み合わせた形で文言を作成し、 必ずその文言がアプリ起動することをご確認いただいてから、ご申請頂く必要があります。

最初に申請した時はアプリ名にはとらわれず、利用シーンや利便性を考えて下記のようなワードも登録していました。

  • ラクスブログについないで
  • 最新のラクスブログ情報を教えて

これらが "<アプリ名、または、 Pronunciation + Trigger Phrase>を組み合わせた形" ではなかったことが原因です。試していなかったのですが、これらのワードでは呼び出すことができないようです。事前にAction on GoogleのSimulatorから設定した全てのワードで呼び出せるこをとを確認してから申請するのが良さそうです。また、手軽に呼び出しできるようにするには、呼び出しやすいアプリ名/Pronunciationを考える必要がありそうです(もちろん、呼び出しやすくてもアプリの趣旨に沿わない名称では結局リジェクトされると思います)。

上記を修正後、再度申請しその翌日に無事承認されました。すごく幸福感のある返信メールが届きました。ありがとうございます。

f:id:radiocat:20180204193116p:plain:w500

なお、メールにも書かれているように複数言語でアプリを公開したい場合は全ての言語で承認を受ける必要があるようです。

おわりに

無事にアプリを公開することができました。なお、今回作ったアプリは弊社のシステムリソース等は使わずパブリックなクラウドサービスを利用して個人で作った実験的なものであり会社の公式的なサービスとして公開されたものではないことはご了承ください。

次回はこの機能をAlexaからも使えるようにしてみたいと思います。

新卒1年目が新卒0年目に贈る、5+1冊の「エンジニア虎の巻」

f:id:tech-rakus:20180202113705j:plain

はじめに

こんにちは!新卒1年目のrs_tukkiです。

エンジニアとして入社してからもうすぐ1年。最初は右も左も分からなかった私ですが、先輩や上司の方々にしごかれ指導していただきながら、なんとか機能開発に携われるようになってきました。

さて、今回は技術そのものとは少し違うお話です。

現在2月。
あと2か月もすれば新しく新卒として入社される、言わば「新卒0年目」の皆さんは、期待と同時に、どのように仕事を進めていけばいいのか、どうすれば説明会で会った先輩たちのようになれるか...という不安もお持ちだと思います。
残念ながらそういったコツは実際の業務の中で身に着けていくしかありませんが、そのヒントなら、古今東西のあらゆる書籍に転がっています。

そこで今回は、新卒1年目の私が、新卒0年目のエンジニアにオススメしたい、5冊+1冊の必読書...いえ、「虎の巻」をご紹介します!

まずは「仕事のやり方」から

エンジニア、というと皆さんの中には、ただずっとパソコンに向かってコードを書いていればいい、と思っている方もいるかと思います。
ですが、実際の仕事は何も自分一人だけで進めていくものではありません。 例えば自分たちの作ったものを資料にまとめて営業の人たちに説明したり、発生した問題に対して皆で対応策や回避策を考えたり...と、パソコンを使わない作業も意外と多いのです。

とはいえそんなときに、「自分はプログラミングしかできないから」と投げ出すわけにはいきません。むしろ、直接業務に関係するためにその時になってからでも学ぶことができるプログラミングよりも、
文書の書き方問題に直面したときの考え方
そして、そういった作業をこなしつつ本来の業務を遅らせないための取り組み方
こそが「今、このタイミングで知っておくべきこと」なのだと思います。

ここでは、そういったことを知れる本を3冊ご紹介します。

<文章嫌いではすまされない! > エンジニアのための伝わる書き方講座

<文章嫌いではすまされない! > エンジニアのための伝わる書き方講座

<文章嫌いではすまされない! > エンジニアのための伝わる書き方講座

  • 作者:開米 瑞浩
  • 発売日: 2014/06/28
  • メディア: 単行本(ソフトカバー)

大学時代に真面目なメールを沢山書き、重要なプレゼンを常にやっていた、という人はあまりいないのではないでしょうか。
ですが就職した後は、たとえエンジニアであっても説明のためにメールを送ったり資料を書いたりと、とにかくプログラム以外にも「書く」作業がかなり増えます。
そこで一番重要なのは、「必要な情報だけを、正確に、分かりやすく相手に伝えること」です。
この本では「誰に」「何のために」文章を書くのか、ということから始めて、図や表の作り方など、情報を的確にまとめて伝えるための方法が書かれています。よく、「コミュニケーションは仕事で一番大事なスキルだ」という人がいますが、その意見の是非はともかく、「誤解なく伝えられること」は必ず役に立つはずなのです。

問題解決力を鍛えるトレーニングブック

発売は2002年と結構古い本です。が、今でも十分参考になる内容だと個人的には考えています。
安易に問題と言っても様々ですが、この本ではまず「問題」の定義とは何か?ということから考え始め、いきなり解決に取り組むのではなく、いったい何が原因なのか、どうすれば解決したと言えるのか、といったことを体系立てて「基本手順」としてまとめています。
実際に起こった問題に対する解決の事例も追えるので、エンジニアとしての問題にも十分応用が利く本です。

脳のパフォーマンスを最大まで引き出す 神・時間術

脳のパフォーマンスを最大まで引き出す 神・時間術

脳のパフォーマンスを最大まで引き出す 神・時間術

  • 作者:樺沢 紫苑
  • 発売日: 2017/04/13
  • メディア: 単行本(ソフトカバー)

こちらは逆に昨年4月に発売されたばかりで、私も今まさに読んでいる途中の本です。
一般的に仕事は1日8時間。特にエンジニアだと残業が多く、9時間も10時間も働くことがあるかもしれません。毎日そんなに長い間集中して取り組めというのも無理な話ですし、実際私も集中力が途切れ途切れになって注意されてしまうことがありました。
この本では、いわゆる「生産性」を叩き出す方法として、上手く集中力を維持しながら、効率よく時間を使う方法について解説しています。
「雑念が出たら紙に書け」というのはちょっと意外でした。

評価されるエンジニアとは?

...何やら偉そうなことを 言っているように思うかもしれません。私もそう思います

プログラミングの世界には「まずは動くようになることが大事」という格言があるらしいですが、当然ただ動くようになっただけでは、ただごちゃごちゃしたものが出来上がっているだけです。
自分のコードが先輩や上司に評価されるためには、まずそのコードが読みやすいものでなければいけません。それは技術力とはまた別のところにありますが、例えるなら部屋の整理整頓をきちんとできるか、といったところでしょうか。

このように、これからエンジニアとして働く皆さんが、「デキる」エンジニアになるためには、ただ技術があるだけでなく、それをどう実際の業務で生かすか、というところまで求められているのだと思います。

コードの綺麗な書き方開発への心構えなど...基本的なプログラミングを覚えた人たちが、そういったノウハウを知ることが出来る本*1を2冊ご紹介します。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

エンジニアとして就職すると、当然ながら仕事としてのプログラミング技術が必要で、コードを書くことも多いと思います。
大学では、自分がコードを書いても、それを読むのはせいぜい自分と教授くらいだったかもしれません。しかし、仕事では一つのコードを多くの仕事仲間で編集するので、当然分かりやすさは大事になってきます。
分かりやすい変数名の書き方、分かりやすいコメントの書き方、分かりやすいロジックの組み立て方など...ベテランのプログラマでも意外とできていない「分かりやすさ」のための技術がまとまっている本です。

プログラマが知るべき97のこと

プログラマが知るべき97のこと

プログラマが知るべき97のこと

  • 発売日: 2010/12/18
  • メディア: 単行本(ソフトカバー)

既に沢山のブログで「初心者向けの必読書」として紹介されているので、もう読んだことのある人もいるのではないでしょうか。
実に73人ものプログラマによる97本のエッセイ(日本語版には更に日本人8人による10本)がまとめられています。「浮動小数点数は実数ではない」のような数学に近い話から、「関数の『サイズ』を小さくする」などの実際のプログラミングにも役立つ内容、更には「ハードワークは報われない」などといった働き方に関する話まで。
全てを実践する、というのは無理がある(というか矛盾する話もいくつかある)のですが、「デキる」人たちはこういうことを意識しているんだな、ということを覚えるだけでもいいと思います。

【おまけ】エンジニアじゃなくても読んでほしい「新卒虎の巻」

最後に、オススメの本をもう一冊だけご紹介します。
ですがこちらは、営業職向けの内容も多く含まれているため「エンジニアの虎の巻」とは言えません。
それでも今、このタイミングでなるべく多くの「新卒0年目」に読んでいただきたい、「新卒の虎の巻」です!

入社1年目の教科書

入社1年目の教科書

入社1年目の教科書

  • 作者:岩瀬 大輔
  • 発売日: 2011/05/20
  • メディア: 単行本(ソフトカバー)

オススメ、という割に、この本に書いてあること自体は「仕事は絶対やりきろう」とか「早く出すことを意識しよう」とか「仕事に対する見方を変えよう」とか、割と当たり前に思われることです。
ですが、そんな当たり前が全部で50個。入社したばかりのやる気に満ちている時であればともかく、しばらくすると数多くの「当たり前」に取り組むことを忘れてしまうかもしれません。
そんな時に、この本に乗っていたことを思い出して自分のやり方を見つめ直す。そうしてまた入社したときのやる気を復活させる。そんな読み方ができる本だと個人的に考えています。だからこそ、入社する前の今に読んでおいてほしいのです。 まあ、50個の中には「宴会芸を死ぬ気でやれ」とか「同期とは付き合うな」とか個人的にどうだろうと思うものもあるのですが...

おわりに

私が入社してから今までに読んだ本の中で、「これは絶対に役に立つ!」と感じた5+1冊をご紹介しました。
もちろん、読んでないといけない、というわけではありません。これらの本を全部読んで、書いてある内容を全部実践しようなんて無理だと思います。

ですが、「読んだこと」自体は絶対に無駄になることはないと思うのです。
面白そうだと思った本を一冊流し読みしてみて、これなら自分にもできそうだと思った一つを、機会があったらチャレンジしてみようと思うだけでもいいと思います。ていうか私もそんな感じです。

私の紹介した本が、新卒0年目の皆さんの心の片隅にでも残ってくれれば幸いです。

*1:逆に、プログラミング未経験の方には難しい内容だと思います...

インストール不要!スマホで自作アプリを動かす方法【疑似Webアプリ】

こんにちは。エンジニアのmickey-STRANGEです。
今回はめんどくさがりによるめんどくさがりのためのスマホアプリ開発についてお話したいと思います。
とはいえ、このブログの内容ではスマホアプリは作りません。
タイトル詐欺ぎりぎりですが、嘘はついていませんので、そういう認識でお楽しみいただけますと幸いです。

構成

先に書きました通り筆者は非常にめんどくさがりです。開発環境・実行環境の整備といったところに手間をかけたくありません。
今回使うのはGitHubのみです。
GitHubのみで疑似Webアプリを実現します。
ではGitHubのみで疑似Webアプリをどう作るか考えていきましょう。
Webアプリというと大雑把に考えて3つ、大事な要素があります。

  1. サーバそのもの(apachetomcatなど)
  2. プログラム実行環境(phpJavaなど)
  3. 記憶領域(postgres、Oracleなど)

これらに対応させて考えていきます。
まずサーバにはGitHub Pagesを使用します。 GitHub PagesはGitHubのサービスであり、静的ページをホスティングしてくれるもので、簡単なWebサイトを公開することが出来ます。

そして公開した静的Webサイト(HTML)にjavascriptを書いておきます。つまり実行環境はブラウザです。

最後に記憶領域ですが、アクセスした各端末に必要な情報を記憶させます。
javascriptによる永続の記憶領域として、Web StorageIndexedDBというものがあります。

これらを使用してスマホでも実行可能なプログラムを作成することが可能です。では各要素について見ていきましょう。

GitHub Pages

まずサーバの役割を担うGitHub Pagesです。
上記の通り静的ページのホスティングサービスですが、すごく簡単に言うと「GitHubにHTMLファイルをpushすればWebサイトとして公開してくれる」という認識でいいと思います。

ここからGitHub Pagesの使いかたをご説明いたします。といっても大層なものではなく、2ステップで完了です。

1.まずHTMLファイルをpushします

ここは詳しい説明は省きます。方法は問いませんので自分のリポジトリにHTMLファイルをpushしてください。
めんどくさがりの意見としてましてはGitHub Desktopを今回初めて使いましたが、何も考えなくていい感じがとてもよかったです。GitHub Desktop | Simple collaboration from your desktop

例としてHello,World!的なHTMLを作成しました。

2.pushしたリポジトリを公開する設定をします

リポジトリ画面の上部にある「Settings」リンクをクリックし…

f:id:mickey-STRANGE:20180129194437p:plain

GitHub Pagesカテゴリ内のSource設定を「master branch」に変更して隣の「Save」をクリック。

f:id:mickey-STRANGE:20180129194440p:plain

以上です!
これでGitHub Pagesの設定が完了しました。pushしたファイルにアクセスしてみましょう。

f:id:mickey-STRANGE:20180129202306p:plain

表示されているリンクをクリックすると…

https://mickeystrange.github.io/tools/

Hello,GitHubPages!が表示されればOKです。

発行されるURLはhttps://[ユーザ名].github.io/[リポジトリ名]/ファイル名なので、https://mickeystrange.github.io/tools/index.htmlにアクセスしても同じものが表示されます。
(おそらくファイル名を省略した場合にindex.htmlを自動的に表示してくれているのではないかと。)

HTMLを公開する設定が出来ましたので、あとはjavascriptを作っていくだけです。

これでGitHub Pagesの説明は終わりです。実行環境のブラウザは言わずもがなということで記憶領域の1つ目、Web Storageの説明に移ります。

Web Storage

Web Storageはブラウザの記憶領域にKey-Value Storeで値を保持できる仕組みです。
Web Storage API - Web API | MDN

使いかたはとても簡単で、準備も不要です。

これでもう値の格納と取り出しが出来ています。それぞれ1行だけです。
もう見たままですが一応ご説明いたしますと、
3行目の

localStorage.setItem('key', value);

の部分で'key'というキーで変数valueの値を格納しています。
また、 5行目の

var item = localStorage.getItem('key');

の部分で'key'というキーで格納されている値を変数itemに取り出しています。

localStorageというのはWeb Storageの種類の1つで、記憶領域が保持される期間が永続のものです。
もう1つの種類としてsessionStorageというものがありますが、こちらはブラウザを閉じるまでの間のみ有効なものになります。

このWeb Storageを使用して、ページへのアクセス数をカウントする簡単なプログラムを作成いたしました。

LocalStorage 静的リソースだけでアプリケーションを作るための記憶領域テスト

ページの再表示やブラウザの再起動などをして遊んでいただきますと、記憶領域をたしかに持っていることが確認出来ると思います。
開発者ツールなどで見ることが出来ますが、特別隠すようなものでもありませんのでコードは以下の通りです。
tools/storage_test.html at master · mickeySTRANGE/tools · GitHub

簡単な値の保持だけであればWeb Storageが十分な機能を持っていることをご説明いたしましたが、続いてもっと強力な記憶領域といたしましてIndexedDBの説明に移ります。

IndexedDB

IndexedDBはブラウザの記憶領域にオブジェクトを保持する仕組みです。
Web Storageと比べて最大容量が多い、KVSではなくJSONを保存できる、検索に強い、などの特徴がある、NoSQLデータベースです。

これからIndexedDBの使用方法についての説明をいたしますが、Web Storageの後で見るととても複雑です。
インストールや外部ライブラリは不要(ブラウザの機能なので当たり前)ですが、手順が多いです。

1.DBに接続する

IndexedDBは基本的にリクエストと、そのリクエストの結果によって実行される部分を書いていきます。
今回の例ですと、3行目の

var openRequest = indexedDB.open("sampleDatabase", version);

がDB接続のリクエストで、4-10行目の

// 接続に成功すれば各処理を実行
openRequest.onsuccess = function(event) { 
  db = event.target.result; 
  db.onerror = function(event) { 
    alert("Database error: " + event.target.errorCode); 
  };
}; 

が接続成功時に実行する処理、といった具合です。サンプルは関数の外の変数にDBのインスタンスを保存しています。
11-15行目の

// DB定義を更新
openRequest.onupgradeneeded = function(event) {
  db = event.target.result;
  db.createObjectStore('sampleObject', {keyPath: 'key'});
};

は、保存するオブジェクトの定義を行っています。
アクセスする時のオブジェクトストアの名前を第一引数に、オブジェクトの定義を第二引数に持っています。
サンプルは'sampleObject'という名前のオブジェクトストアで'key'をキーに定義しています。

このonupgradeneededというものは、DBのバージョンが上がった時に実行されるものです。
3行目のopen()の第二引数にversionがありますが、これはIndexedDBのバージョンではなく、自分が作るDBのバージョンです。
バージョン1としてこのサンプルの通りオブジェクトストアを定義し、変更が必要になった時にバージョン2として接続し、onupgradeneededの中で新しくオブジェクトストアを追加したり、オブジェクトストア定義変更を行ったりすることが出来ます。

2.オブジェクトストアにアクセスする

DBに接続出来れば次はデータへのアクセスです。データの格納と取得を見てみましょう。

setValueではDB接続のサンプルで作ったsampleObjectに1つのオブジェクトを追加しています。
keyは'sample'value'hoge'という値を持っています。keyは必須かつ重複不可の制約がありますが、他の要素は何を持っていても構いません、

getValueではsampleObjectから'sample'というkeyPath(サンプルでは'key')を持つ値を検索しています。

IndexedDBの記憶領域は全て永続なので、この構文のみでもアプリを作成することが可能です。
これらの構文を使用し、またページへのアクセス数をカウントする簡単なプログラムを作成いたしました。

Indexed Database 静的リソースだけでアプリケーションを作るための記憶領域テスト

tools/indexed_database_test.html at master · mickeySTRANGE/tools · GitHub

ページのリロード等をしていただきますとカウントが正常に出来ていることが分かります。

3.IndexedDBの注意点

簡単なサンプルをお見せいたしましたが、indexed_database_test.htmlのコードを見ていただきますと、Web Storageの時とは大きく構成が違うことが分かっていただけるかと思います。

そうです、「取得する関数」と「格納する関数」で分けて処理をきれいに書くことが出来なかったのです。

理由がありまして、リクエストを書き、その成功時失敗時に実行する処理を書くと説明いたしました。
実はこれが曲者で、リクエストが完了したかどうかをイベント外から見ることが出来ないのです。

「取得する→1増やす→格納する」という流れを切り分けることが出来ず、
取得するリクエストのonsuccessイベントで「1増やして格納する」という処理の流れになります。
更に言うと取得するリクエストさえ接続するリクエストのonsuccessイベント内で実行しています。

IndexedDBはWeb Storageよりも強力なデータベースが使用できる代わりに、処理の流れを作るところで非常にややこしくなってしまう、というデメリットがあると言えます。

まとめ

自分の書いたコードを簡単にスマホで動かす方法をご紹介いたしました。いかがでしたでしょうか。

一番手軽なのはやはりWeb Storageを使用する方法です。 多分これが一番早いと思います。

これにJQueryやBootstrapなどの部品を組み合わせることで十分なスマホアプリのようなものが作れると思います。
今回の記事とは別に業務を効率化するJSなども趣味で作っていたりしたため、ここ最近でJS面で成長したことを感じています。
自分で使えるツールをもっとpushしてJSライフを楽しんでいきたいです。

OWASP ZAPについて調べてみた

はじめに

開発エンジニアのamdaba_sk(ペンネーム未定)です。前回は「ソフトウェアテストについて簡単にまとめてみた」という記事を書きましたが、その流れで今回はセキュリティテストツール「OWASP ZAP」について少し調べてみました。

※以下は個人的にネットで調べてみた情報をまとめたものであり、実際に開発過程で運用するなどしたものではありません。また日本語サイトを中心に調べているため、機能等の情報は古い可能性があります。

セキュリティテスト

昨今は個人情報の漏えいや顧客情報流出などのニュースをよく耳にします。怖いですね…。

ラクスでも個人情報の漏えいや顧客情報流出などは深刻な問題としてとらえていまして1、その発生を未然に防ぐために開発者には年1度セキュリティ学習と修了テストが課されていたりしています。

またリリース前にはとあるWebアプリケーション検査ツールを使った脆弱性検査を実施し、検出された脆弱性を修正するようにしています。

しかしながら今のツールによる検査は、はたから見ているだけの感想ですが

  • 設定がややこしそう
  • リリース前に修正箇所全体に対して行うため、たくさんあったときに修正が大変
  • ツールの稼働サーバーがチーム間で共有なため、柔軟には使用できない

といった不便さを抱えているように感じます。

OWASP ZAP

そこで上記の不便さに対し、

  • もっと簡単な設定で自動チェックをしてくれるツールはないか
  • もっとこまめに、例えば単体テストの一環としてチェックできないか
  • もっと柔軟に、チームごとに専用の環境を用意できないか

といった要望を満たすツールとして私が目を付けたのが「OWASP ZAP」でした。

OWASPとは

OWASP ZAPではじめる2016年のウェブアプリケーションセキュリティでは

ウェブアプリケーションを作成する開発者や,ウェブアプリケーションに関わる意思決定を行う方々に対し,セキュリティに関する十分な情報を行き渡らせることを目的とし活動をしているのがOWASPです。OWASPは「The Open Web Application Security Project」の略称で,グローバルにチャプター(支部)を展開するオープンコミュニティです。

と説明されています。Webアプリケーションセキュリティの啓蒙団体といったところでしょうか。

OWASP ZAPの概要

OWASPにはWebアプリケーションセキュリティの啓蒙に関して大小さまざまなプロジェクトを展開しています。OWASP Zed Attack Proxy(OWASP ZAP⁠)はその中でも最重要として位置づけられたプロジェクトの一つであり、その成果物としてのツールです。

IPAテクニカルウォッチ「ウェブサイトにおける脆弱性検査手法の紹介」でも取り上げられて、使いやすく、検知制度が高く、効率性が非常に高い初級者向けのツールという評価を受けています。またありがたいことに無料で使えるオープンソースウェブアプリケーション脆弱性診断ツールで、Github上ソースコードが公開されています。

用途としては「開発者が開発時に簡易的なウェブアプリケーション脆弱性診断を実施する」ことを特に意識して作られており、セキュリティの専任ではない開発者でも簡単に利用できるようになっています。

なお、OWASP ZAPが検査可能な主な脆弱性は以下のとおりです。

OWASP ZAPの機能

表1はOWASP ZAPの主要な機能をまとめたものです。

表1 OWASP ZAPの主要機能(OWASP ZAPではじめる2016年のウェブアプリケーションセキュリティより引用)

項番 機能名 概要
1 スパイダー機能 指定のURLを起点とし,オートクローリング(自動で脆弱性診断対象のリンクを辿り,存在するURLを洗い出す。)を行います。
2 動的スキャン機能 クローリングして明らかになった任意のURLに対し,ツールが準備している脆弱性診断用の検査文字列を用いて自動で脆弱性診断を行います。
3 ローカルプロキシ機能 ローカルプロキシとしてOWASP ZAPを動作させ,手動で脆弱性診断を行います。やや玄人向けです。
4 ディレクトリ探査機能 指定のURL配下に不要なディレクトリが存在しないかを確認します。
5 アラート機能 脆弱性診断結果に関する簡易の報告書を作成します。
6 ZAP Script機能 OWASP ZAPの機能を拡張し,OWASP ZAPをより自分好みにカスタマイズできます。JavascriptPythonRubyなどのさまざまな言語に対応しています。情報源としては,OWASP ZAP ScriptsというGroupがあります。

OWASP ZAPはJavaで作られており、クロスプラットフォームで動作します。またwindows 環境では特にありがたいのですが、利用しやすいようにグラフィカルインターフェースを備えています。

詳しい手順はその他の記事や公式のドキュメントを参照していただきたいと思いますが、項番1(スパイダー)の実行後に項番2(動的スキャン)を実行する自動脆弱性診断を行うだけなら

  1. 検査対象URLの入力
  2. 実行ボタンクリック

という非常に簡潔な手順で実施できます。

一方でRESTfulなAPIによる操作もできるようで、curlなどでコマンドラインからリクエストを投げれば上の手順をスクリプト化できます。さらにデーモンモードで起動しておけば、JenkinsなどのCIツールと連携して最初から最後まで自動で実施することもできます(e.g.JenkinsとOWASP ZAPで自動診断 - Qiita)。

またJenkinsと連携した上の例ではOWASP ZAPのAPIスクリプトで直接呼び出していますが、 公式のZAP Jenkins pluginというものもあるようで、そちらを利用するという手もあるでしょう。

その他、手動の単体テスト実施時にローカルプロキシ機能を使用してチェックするとか、いろいろ設定をいじって使ってみるとか、使い方の幅も広そうです。

おわりに

以上簡単ながら「OWASP ZAP」について調べたことをまとめました。

設定も簡単、精度もよく、自動化も可能と、とっても便利そうです。ただあくまで簡易チェックツールということで、

  • 開発中は「OWASP ZAP」で簡易検査
  • リリース前は精密チェックができる別のツールで本検査

という風な使い分けをしたらいいんじゃないかと今の段階では思っています。

参考

  1. OWASP Zed Attack Proxy Project
  2. IPAテクニカルウォッチ「ウェブサイトにおける脆弱性検査手法の紹介」
  3. OWASP ZAPではじめる2016年のウェブアプリケーションセキュリティ
  4. JenkinsとOWASP ZAPで自動診断 - Qiita
  5. zap plugin - Jenkins - Jenkin Wiki

◆TECH PLAY
techplay.jp

◆connpass
rakus.connpass.com


  1. 本ブログで「意図しない処理が実行されるCSRFとは?概要と対策」や「要注意!新人エンジニアが発生させた2大脆弱性」といった記事があるように、個人レベルでも関心の高い話題です。

戦闘力53万風のマイクロサービス

f:id:Y-Kanoh:20180111033033j:plain

こんにちは!エンジニアのY-Kanohです。

弊社のエンジニアは、業務終了前にその日の稼働報告を社内システムに入力することになっています。 しかしながら、この入力を忘れるメンバー(主に私)が多く、チームのリーダーに指摘されてから、数日前の仕事状況を思い出して記入することが度々ありました...。(すみません。)

そこで、チームで導入されているチャットツール、「MatterMost」に稼働報告を忘れている人へ通知をするようにしてみました。

Mattermost | Open Source Collaboration for Developers

しかし、ただ作るだけではすぐ終わってしまったので、かねてから興味があったDockerを使ってマイクロサービスとして作り直しています。

今日はそのお話です。

概要

大雑把に言えば、作成したBotシステムは下図のようなイメージです。

f:id:Y-Kanoh:20180111024417p:plain

プログラムは毎朝始業直前に動かすようセットします。 稼働状況は社内のDBに登録されているので、まず社内DBを参照し、昨日の入力を忘れているメンバーを見つけ、チャットに通知します。

MatterMostには外部連携機能があり、外部システムからの投稿が可能です。*1

設計

概念図

最初は、「動けばいい」の信念のもと、上記図のBotシステムをそのまま1コンテナにしただけの設計でした。

マイクロサービスを目指すにあたり、そのコンテナ内容を機能ごとに分割し、以下のような設計で実装しています。*2

f:id:Y-Kanoh:20180111024243p:plain

作成したコンテナは以下の7つです。

  1. 管理用BFFコンテナ
  2. Bot用BFFコンテナ
  3. API Gatewayコンテナ
  4. API Gateway情報DBコンテナ
  5. 社内DBアクセス用コンテナ
  6. チーム情報DBアクセス用コンテナ
  7. チーム情報DBコンテナ

※社内DBには稼働情報、チームDBにはチームメンバー情報やチームが使用しているチャット情報が格納されています。

これらのコンテナ群は、大きくBFFAPI Gatewayバックエンドの三種類に分けることができます。

BFF

BFFとは、Backends for Frontendsの略で、つまりフロントエンドのためのバックエンドです。*3 *4

BFFは、クライアントの種類ごとに、クライアントとバックエンドの間で、データ加工や画面作成などの処理を行います。

BFFを使用することで、バックエンドから受け取ったデータを、各BFFが対象とするデバイスやユーザ向けに適した形に加工して表示させることができます。

API Gateway

機能を各コンテナに分けるうえで、一つ問題がありました。

コンテナ同士はやり取りする相手のコンテナ接続情報を知っておく必要があります。そのため、やり取りするコンテナを増やすたびに、接続先情報をそれぞれ定義する必要があるため、 コンテナ依存関係の定義が複雑になってしまいます。

そこで、今回はバックエンドのコンテナは、互いに通信せず、必ずAPI Gatewayを介してやり取りするようにしました。 これにより、以下のメリットが見込まれます。

  • APIを一元管理
  • コンテナ間の依存関係を簡略化
  • 共通処理を行う場合ここで実行可能
  • BFFからのサービス呼び出しを簡略化

バックエンドのAPIは、必ずAPI Gatewayを介して呼び出されます。Gatewayに来たリクエストは、Gatewayで適切なコンテナへルーティングされるため、Dockerコンテナで面倒なコンテナ同士の依存関係を定義する必要はなくなります。

また、今回は特に実装していませんが、バックエンドへの認証機能や、ログの収集なども、ここで一括して行うことができます。

今回、API Gatewayには、OSSとして開発が進められているKongを使用します。

Kong Open-Source API Management Gateway for Microservices

バックエンド

BFF、API Gatewayの導入により、バックエンドはその他の機能とかなり疎結合になります。

フロント側に適したデータ形式に加工する必要が少ないため、設計の制約が減ります。

そこで、バックエンドのAPIは、RESTの原則に基づいた実装にしました。

docker-compose.yml

docker-compose.ymlは以下の通りです。

前述したAPI Gatewayにより、各コンテナはkongコンテナをlinkさせるだけでバックエンドのAPIが使用できます。

version: '2'
#==============================================================================
# Volumeの定義
#==============================================================================
volumes:
  team_vol:
    driver: 'local'
  kong_vol:
    driver: 'local'

#==============================================================================
# servicesの定義
#==============================================================================
services:
  #############################################################################
  ## API Gateway
  #############################################################################
  # API GatewayのDB
  kong-database:
    image: postgres:9.4
    environment:
      - POSTGRES_USER=kong
      - POSTGRES_DB=kong
    volumes:
            - kong_vol:/var/lib/postgresql/data

  # API Gatewayの初期設定を行うコンテナ
  kong-migration:
    image: kong
    depends_on:
      - kong-database
    environment:
      - KONG_DATABASE=postgres
      - KONG_PG_HOST=kong-database
    command: kong migrations up

  # API Gatewayコンテナ
  kong:
    image: kong:latest
    depends_on:
      - kong-database
      - kong-migration
    environment:
      - KONG_DATABASE=postgres
      - KONG_PG_HOST=kong-database
      - KONG_PG_DATABASE=kong
    ports:
     - "8000:8000"
     - "8443:8443"
     - "8001:8001"
     - "8444:8444"

  #############################################################################
  ## 社内DBアクセス機能
  #############################################################################
  qcp_watcher:
    links:
      - kong
    build:
      context: "./BEService/QcpWatcher"
      dockerfile: "Dockerfile"
    ports:
      - 49513:80
    extra_hosts:
      - qcp:192.168.99.100  #社内DBのホストを指定

  #############################################################################
  ## Team情報管理機能
  #############################################################################
  # Team情報管理DB
  team_db:
    build: "./BEService/Team/DB"
    ports:
      - 54321:5432
    environment:
      POSTGRES_USER: postgres
      POSTGRES_DB: postgres
    volumes:
            - team_vol:/var/lib/postgresql/data

  # TeamDBアクセスコンテナ
  team:
    links:
      - kong
      - team_db
    build: "./BEService/Team"
    ports:
      - 49514:80


  #############################################################################
  ## Bot用コンテナ(MatterMost連携コンテナ)
  #############################################################################
  mm_bff:
    links:
      - kong
    build: "./FEService/MmBff"
    ports:
      - 49515:80

  #############################################################################
  ## 管理者用コンテナ
  #############################################################################
  admin_bff:
    links:
      - kong
    build: "./FEService/AdminBff"
    ports:
      - 49516:80

実際に作成したBot

毎朝こんな感じに通知してくれるようになりました。

f:id:Y-Kanoh:20180111025537p:plain

より通知を目立たせるために、戦闘力が53万の方にご協力いただいています

f:id:Y-Kanoh:20180108181755p:plain

この方にはbotをマイクロサービスにする前から協力いただいています。最初はアイコン画像だけでしたが、メンバーからの要望により、口調もあの方になりました。

最初は黄色いネズミのアイコンだったのですが、こちらのほうが断然反応していただけました。

f:id:Y-Kanoh:20180108181351p:plain

全員稼働報告が入力できていた場合は、ちゃんと褒めて(?)いただけます。ありがたや。

今後の拡張

Botを機能ごとに分割することで、追加機能の実装もやりやすくなりました。

また、コンテナによって機能ごとにプログラムが隔離されているため、興味がある技術を試しに使ってみることもできます。

そのため、今後は業務に役立ちそうなものを 趣味 自己学習として、拡張できればと思います。

Copyright © RAKUS Co., Ltd. All rights reserved.