TP-Link社のWifiスマートLEDランプ KL110/KL130 を使って、同一ネットワーク内にあるmacbookからランプをコマンドライン制御します。

このランプの良いところは、電灯のON/OFFだけでなく色温度や輝度を調節できる点です。
例えば

• 暖色系の色で輝度を落として落ち着いた雰囲気で集中作業する
• 手元でモノを探すときに輝度を上げる
• 物理本を読むときに色温度を変える（Kindleの背景の白とセピアくらい紙の色味が変わる）

といったことが手元でできるのが良いです。

特に色温度を変えるとだいぶ色味が変わります。
↓実際にランプの色温度最低値と最高値で見比べた写真：2500K<--->9000K

こういった色味、明るさ、薄暗さをそのときの気分でコマンドラインで調整できるようにします。

試してみた環境

macbook : macOS Mojave
Node.js : v12.12.0

準備として、最初にスマホアプリでKL110/KL130のWifi設定を済ませておきます。
そして、同一ネットワーク内にmacbookを用意して
macbook ---- Wifiルータ ---- KL110/KL130
という構成にしておきます。
ちなみにKL110/KL130は2.4GHz Wifiにしか対応していないようです。（5GHz未対応）

tplink-lightbulb をインストール

tplink-lightbulbをnpmでグローバルインストールしておきます。
すると tplight コマンドが使えるようになります。

$ npm i -g tplink-lightbulb
$ tplight
Usage: tplight <COMMAND>

コマンド:
  tplight scan                              Scan for lightbulbs
  tplight on <ip>                           Turn on lightbulb
  tplight off <ip>                          Turn off lightbulb
  tplight temp <ip> <color>                 Set the color-temperature of the
                                            lightbulb (for those that support
                                            it)
  tplight hex <ip> <color>                  Set color of lightbulb using hex
                                            color (for those that support it)
  tplight hsb <ip> <hue> <saturation>       Set color of lightbulb using HSB
  <brightness>                              color (for those that support it)
  tplight cloud <ip>                        Get cloud info
  tplight raw <ip> <json>                   Send a raw JSON command
  tplight details <ip>                      Get details about the device

オプション:
  -h, --help  ヘルプを表示                                                [真偽]
  --version   バージョンを表示                                            [真偽]

例:
  tplight scan -h     Get more detailed help with `scan` command
  tplight on -h       Get more detailed help with `on` command
  tplight off -h      Get more detailed help with `off` command
  tplight temp -h     Get more detailed help with `temp` command
  tplight hex -h      Get more detailed help with `hex` command
  tplight hsb -h      Get more detailed help with `hsb` command
  tplight cloud -h    Get more detailed help with `cloud` command
  tplight raw -h      Get more detailed help with `raw` command
  tplight details -h  Get more detailed help with `details` command

You need a command.

シェルスクリプトを書く

tplightコマンドを使ったシェルスクリプトを用意します。
スクリプト内のライトのIPアドレスは環境に合わせて書き換えてください。
~/bin/light などパスを通しているディレクトリにスクリプトを置きます。

#!/bin/bash
LIGHT_IP=192.168.1.14

ON_OFF=1
COLOR_TEMP=2500
BRIGHTNESS=100

if [ "${1}" = "on" ]; then
  ON_OFF=1
elif [ "${1}" = "off" ]; then
  ON_OFF=0
elif [ "${1}" = "hot" ]; then
  ON_OFF=1
  COLOR_TEMP=2500
elif [ "${1}" = "cold" ]; then
  ON_OFF=1
  COLOR_TEMP=9000
fi

if [ -n "${2}" ]; then
  BRIGHTNESS=${2}
fi

tplight raw ${LIGHT_IP} \
"{
  \"smartlife.iot.smartbulb.lightingservice\": {
    \"transition_light_state\": {
      \"on_off\": ${ON_OFF},
      \"color_temp\": ${COLOR_TEMP},
      \"brightness\": ${BRIGHTNESS},
      \"hue\": 0,
      \"saturation\": 0
    }
  }
}" > /dev/null

実行する

ライトを点ける

$ light on

ライトを消す

$ light off

暖色系のライトを点ける

$ light hot

寒色系のライトを点ける

$ light cold

暖色系のライトで輝度を20にする（max 100）

$ light hot 20

カスタマイズする

$ tplight details [IP address] コマンドで現在のライトの状態・設定値をみることができます。
設定値のlight_state あたりを眺めて $ tplight raw [json] でjsonを投げてやれば輝度や色温度を変えることができます。
on_offは1でon、0でoff、brightnessは輝度、color_tempは色温度、hue, saturationはカラー対応(KL130)の場合に色味の設定ができます。

$ tplight details 192.168.1.14
{
  "sw_ver": "1.8.11 Build 191113 Rel.105336",
  "hw_ver": "1.0",
  "model": "KL130(JP)",
  "description": "Smart Wi-Fi LED Bulb with Color Changing",
  "alias": "アプリで設定した名前がここに設定される",
  "mic_type": "IOT.SMARTBULB",
  "dev_state": "normal",
  "mic_mac": "xxxxxxxxxxxx",
  "deviceId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "oemId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "hwId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "is_factory": false,
  "disco_ver": "1.0",
  "ctrl_protocols": {
    "name": "Linkie",
    "version": "1.0"
  },
  "light_state": {
    "on_off": 1,
    "mode": "normal",
    "hue": 0,
    "saturation": 0,
    "color_temp": 2500,
    "brightness": 100
  },
  "is_dimmable": 1,
  "is_color": 1,
  "is_variable_color_temp": 1,
  "preferred_state": [
    {
      "index": 0,
      "hue": 0,
      "saturation": 0,
      "color_temp": 2700,
      "brightness": 50
    },
    {
      "index": 1,
      "hue": 0,
      "saturation": 75,
      "color_temp": 0,
      "brightness": 100
    },
    {
      "index": 2,
      "hue": 120,
      "saturation": 75,
      "color_temp": 0,
      "brightness": 100
    },
    {
      "index": 3,
      "hue": 240,
      "saturation": 75,
      "color_temp": 0,
      "brightness": 100
    }
  ],
  "rssi": -69,
  "active_mode": "none",
  "heapsize": 284368,
  "tid": "tty.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "err_code": 0,
  "lamp_beam_angle": 150,
  "min_voltage": 110,
  "max_voltage": 120,
  "wattage": 10,
  "incandescent_equivalent": 60,
  "max_lumens": 800,
  "color_rendering_index": 80
}

リンク

KL110 : https://www.tp-link.com/jp/home-networking/smart-bulb/kl110/
KL130(マルチカラー対応) : https://www.tp-link.com/jp/home-networking/smart-bulb/kl130/

tplink-lightbulb : https://www.npmjs.com/package/tplink-lightbulb

本記事は、NTTコミュニケーションズ Advent Calendar 2019 8日目の記事です。
昨日は、 @y-i さんの 社内ISUCONで優勝した時にやったこと でした。

これは何

• スポーツ解説アプリ SpoLive における分析基盤構築についてのノウハウ共有
• サーバーレスで、要件に応じて柔軟に分析できる基盤を構築した話

SpoLive について

SpoLive は、「スポーツファンとアスリートの距離を、デジタルの力で縮める」ことをビジョンに掲げた新サービスです。例えば試合中に、「なんで今のプレーが許されてるんだっけ？」「この選手どんな人だっけ？」といった気になることをすぐに解決できるのはもちろんのこと、より手軽に、より深く豊かな選手の情報に触れることができるようなアプリを目指して日々アップデートを重ねています。

本記事では、SpoLiveにおける分析基盤を構築したノウハウを述べます。構築の前提条件として下記がありました。

• データをビジネスサイドのメンバー(SQL を書いて分析できるメンバーがいる)が柔軟に分析できる基盤を用意したい
• 開発・運用コストはできるだけ抑えたい

分析基盤

SpoLive は、Firebase と expo で開発をしています。
基盤構築の方針として下記の方針が考えられますが、後述の理由で2 を採用しました。

• 1. Firebase Analytics + BigQuery
• 2. Google Analytics + BigQuery
• 3. 別の分析ツール(Amplitude・Mix Panel 等)

理由: Firebase を利用していたら、 Firebase Analytics を利用することが主流だと思いますが、 expo において対応できるライブラリは（自分の知る限り）なく、別の分析ツールではなくまずは世の中の知見も多くシンプルな構成から入ろうと考えたためです。

Bigqueryは、データ分析にあたってはよく用いられているサービスで、SQLで複数データを統合して集計することも容易ですし、例えば、Googleデータポータルを利用して可視化すること などができ、柔軟に分析ができます。

技術要素

前述の方針に基づき、分析基盤を構築するにあたり、下記の要素に分割できます。

アプリ =(1)=> Google Analytics =(2)=|
　　　　　　　　　　　　　 　　　　　　　|
　　　　　　　　　　　　Firebase  =(3)==> BigQyery

上記のうち、(2)(3)のGoogle Analytics/FirebaseからBigqueryへ転送するタスクは、Node.jsで実装し、CloudFunctions の 定期ジョブ としてデプロイします。

理由として、BigQuery のNode.js SDKが世の中に知見が溜まっていそうな点、expo(ReactNative)と技術要素をjsで揃えることによる、メンバーのメンテしやすさの点がありました。また、後述する通り、CloudFunctionsの定期ジョブは、コードだけでスケジューリング可能で、コンソールで手動で設定・・といった必要がなく、変更管理のしやすさを感じています。

(1)アプリ から Google Analytics

ライブラリ expo-analytics を利用して、アプリから GoogleNAalytics へアプリの利用状況に関するデータを収集します。

// analitics.js

import { Analytics as GoogleAnalytics, ScreenHit, Event } from "expo-analytics";

class Analytics {
  constructor(code = null) {
    this.ga = null;
    this.code = code;
  }

  init = () => {
      this.ga = new GoogleAnalytics(this.code);
  };

  EventHit = (category = null, action = null, label = null, value = 0) => {
    if (category && action) {
      const params = [category, action];
      if (label) {
        params[2] = label;

        if (value >= 0) {
          params[3] = value;
        }
      }
      this.ga.event(new Event(...params));
    }
  };
}

export default new Analytics(gaId);

// someview.js

import Analytics from "app/src/libs/analytics";

 Analytics.EventHit(
      "categoryName",
      "actionName",
      "labelName",
    );

転送タスクのデプロイ・自動起動

前述のとおり、(2)(3)のGoogle Analytics/FirebaseからBigqueryへ転送するタスクは、Node.jsで実装し、CloudFunctions の 定期ジョブ としてデプロイします。

# ディレクトリ構成
functions/src/index.ts
           |    
           |--- modules/
                 |    
                 |--- transferBigquery.ts

Node.js

import * as functions from "firebase-functions";
import { transferBigquery } from "./modules/transferBigquery";


// bigqueryへの定期エクスポート
module.exports.transferBigquery = functions
  .region("asia-northeast1")
  .runWith({
    timeoutSeconds: 9 * 60, // max: 9min
    memory: "1GB"
  })
  .pubsub.schedule("0 4 * * *")
  .timeZone("Asia/Tokyo")
  .onRun(transferBigquery);

(2)Google Analytics から BigQuery

GAからのデータ取得には、GoogleAPIs の Node.js向け SDKを利用します。
(3)とあわせて、一つのFunctionsとして実装します。

API利用時の認証情報は、Functionsの環境変数として保存しますが、ローカルでの開発時も functionsディレクトリで、 firebase functions:config:get > .runtimeconfig.json としておくと、ローカルでも環境変数をjsonファイルの値から利用できます。

Functionsのメイン処理は下記のイメージです

Node.js

// transferBigquery.ts

import firebase from "./firebase-admin";
import moment from "moment";

import { Analytics } from "../libs/googleAnalytics";
import { BigQuery } from "@google-cloud/bigquery";
import { Storage } from "@google-cloud/storage";

// main関数で、class初期化・メソッド実行
export const transferBigquery = async () => {
  const projectId = process.env.GCLOUD_PROJECT;
  if (!projectId) {
    console.error("projectId is invalid", projectId);
    return;
  }

  // firestoreの環境変数としてGAの認証情報を保存
  const { client_email, private_key, view_id } = functions.config().googleanalytics
  const ga = new Analytics(client_email, private_key, view_id);
  const tb = new TransferBigquery(projectId) // 後述

  // GAのデータは過去1日分を入れ替え
  const start: Moment = moment().add(-1, "days")
  const end: Moment = moment().add(-1, "days")
  await tb._delete_eventdata_from_bigquery(start,end)
  await tb._export_eventdata_to_storage(start, end) // ここが本節で説明したい部分
  await tb._save_eventdata_to_bigquery()

  //firebaseの試合情報は、全件更新
  await tb._export_gamedata_to_storage(); // 後述
  await tb._save_gamedata_to_bigquery();  // 後述
};


export class TransferBigquery {

  private projectId: string
  private suffix: string

  constructor(projectId: string) {
    this.projectId = projectId
  }

  async _export_eventdata_to_storage(start: Moment, end: Moment) {
    const eventData = await this.analytics._eventToJson(start, end) // GAからイベントデータを取得
    return await this._exportJSON(eventData.join("\n"), `events.json`); //CloudStorageへ保存(後述)
  }
  // ...省略...

}

GAのイベントデータを取得する処理は下記のとおり

Node.js

// libs/googleAnalytics.ts

import { google } from "googleapis";
import { Moment } from "moment";

export const Analytics = class {

  private jwtClient: any;
  private analytics: any;
  private viewId: string;

  constructor(clientEmail: string, privateKey: string, viewId: string) {
    this.jwtClient = new google.auth.JWT(
      clientEmail,
      undefined,
      privateKey,
      ["https://www.googleapis.com/auth/analytics.readonly"],
      undefined,
    );
    this.analytics = google.analytics("v3");
    this.viewId = viewId;
  }

  // event以外の情報を取得したい場合は、別のパラメータを指定する
  // - Dimensions & Metrics Explorer: https://ga-dev-tools.appspot.com/dimensions-metrics-explorer/
  _event_param(date: Moment) {
    const params: any = {
      "start-date": date.format("YYYY-MM-DD"),
      "end-date": date.format("YYYY-MM-DD"),
      metrics: "ga:uniqueEvents",
      dimensions:
        "ga:eventCategory,ga:eventAction,ga:eventLabel",
      sort: "ga:eventCategory"
    };
    return params
  }

  // 指定期間のデータを取得しJSONを生成
  async _eventToJson(start: Moment, end: Moment) {
    const eventJson = []
    while (start.diff(end) <= 0) {
      const eventData = await this._fetch_report_data(this._event_param(start));
      if (eventData == undefined) {
        start.add(1, "days");
        continue
      }
      console.log(`add gaEvent: ${start.format("YYYY-MM-DD")}`)
      for (const e of eventData) {
        eventJson.push(JSON.stringify({
          date: start.format("YYYY-MM-DD"),
          eventCategory: e[0],
          eventAction: e[1],
          eventLabel: e[2],
          uniqueEvents: e[3],
        }))
      }
      start.add(1, "days");
    }
    return eventJson
  }

  // GAからデータ取得
  async _fetch_report_data(params: any): Promise<any[]> {
    params.auth = this.jwtClient;
    params.ids = `ga:${this.viewId}`;
    return new Promise((resolve, reject) => {
      this.jwtClient.authorize((err: any, tokens: any) => {
        if (err) {
          reject(err);
        }
        this.analytics.data.ga.get(params, (err: Error, resp: any) => {
          if (err) {
            reject(err);
          }
          resolve(resp.data.rows);
        })
      });
    });
  }
};

(3)Firebase から BigQuery

Bigqurey の Node.js向け SDK google-cloud/bigquery を利用します。
Bigqureyへのデータインポートには、CloudStorageにあるファイルから一括インポートする方法と、 一度に 1 レコードずつ BigQuery にデータをストリーミング処理でインポートする方法がありますが、公式ドキュメントにもありますがコスト的には ストリーミング処理は必要がなければ避けるべきです。

上記の理由から、データを改行区切り JSON にしてCloudStorageへ出力し、Bigqueryへインポートさせます。

Node.js

// transferBigquery.ts

  // // 前述のメイン処理抜粋
  // // firebaseの試合情報は、全件更新
  // await tb._export_gamedata_to_storage();
  // await tb._save_gamedata_to_bigquery(); 

export class TransferBigquery {

  private projectId: string
  private analytics: any
  private location: string

  constructor(projectId: string, analytics: any) {
    this.projectId = projectId
    this.analytics = analytics
    this.location = 'US' //Bigquery>datasetのlocationを変更した場合はここも変更する
  }

  async _export_gamedata_to_storage(){
    const gameData = await firebase
     .firestore()
     .collection(`games`)
     .get()
     .then(querySnapshot => {
       const returnData: string[] = [];
       querySnapshot.forEach(doc => {
         const {
           team_homeName = null,
           team_awayName = null
         } = doc.data();

         // BigQueryがサポートしている改行区切りJSONを出力するために、ここで整形
         returnData.push(
           JSON.stringify({
             gameId: doc.id,
             team_homeName,
             team_awayName
           })
         );
       });
       return returnData;
    });
    return await this._exportJSON(gameData.join("\n"), "games.json");
  };

  // Cloud Storageへの保存
  async _exportJSON(jsonText: string, filename: string) {
    const storage = new Storage();
    const bucket = storage.bucket(`${this.projectId}.some_storage.com`);
    bucket.file(`somedir/${filename}`).save(jsonText, err => {
      if (!err) {
        bucket.file(`somedir/${filename}`).setMetadata(
          {
            metadata: {
              contentType: "application/json"
            }
          },
          (err: any, apiResponse: any) => {
            if (err) {
              console.log("err", err);
            } else {
              console.log(`finish saving ${JSON.stringify(apiResponse)}`);
            }
          }
        );
      } else {
        console.log("fail saving", err);
      }
    });
  };

  // Clound Storage からBigqueryへインポート
  async _save_gamedata_to_bigquery() {
    const schema: any = {
      fields: [
        { name: "gameId", type: "STRING", mode: "NULLABLE" },
        { name: "team_homeName", type: "STRING", mode: "NULLABLE" },
        { name: "team_awayName", type: "STRING", mode: "NULLABLE" }
      ]
    };
    return await this._saveBigquery({
      bqSchema: schema,
      tabeleName: "games",
      filename: `games.json`,
      isAppendMode: false,
    });
  };

  _loadStorageFile(filename: string) {
    const storage = new Storage();
    const bucket = storage.bucket(`${this.projectId}.some_storage.com`);
    return bucket.file(`somedir/${filename}`);
  };

  async  _saveBigquery(params: BigqueryParam) {
    const { bqSchema, tabeleName, filename, isAppendMode } = params
    const datasetId = "some_dataset";
    if (!this.projectId) {
      console.error("projectId is invalid", this.projectId);
      return;
    }
    const bigquery = new BigQuery({ projectId: this.projectId });
    const table = bigquery.dataset(datasetId).table(tabeleName);

    // https://cloud.google.com/bigquery/docs/reference/auditlogs/rest/Shared.Types/WriteDisposition
    const importMode: string = isAppendMode ? "WRITE_APPEND" : "WRITE_TRUNCATE";
    const metadata: any = {
      sourceFormat: "NEWLINE_DELIMITED_JSON",
      schema: bqSchema,
      // Set the write disposition to overwrite existing table data.
      writeDisposition: importMode,
    };

    table.load(this._loadStorageFile(filename), metadata, (err, apiResponse) => {
      if (err) {
        console.log("err", err);
      } else {
        console.log(`finish saving: ${JSON.stringify(apiResponse)}`);
      }
      return;
    });
  };

}

最後に

本記事では、Firebase / Cloud Functins / BigQuery などのクラウド基盤上に、サーバーレスでユーザー分析基盤を構築するノウハウについて述べました。

スポーツ解説アプリSpoLiveでは、これからも利用者の方により楽しくスポーツを楽しんでいただけるアプリを目指して日々改善中です。今現在、ラグビーやサッカーの試合がお楽しみいただける他、今後も対応スポーツを拡大していく予定です。ぜひご利用ください。

明日は、 @tetrapod117 さんの記事です。

「パスワード強度チェックするようなライブラリって何かあるのかな？」
と興味本位で調べてみたらzxcvbnというものが見つかったので、ご紹介。

zxcvbnとは

Dropbox社製のパスワード強度チェッカーです。
Node.js以外にも色々な言語に対応したライブラリが作られています。

dropbox/zxcvbn: Low-Budget Password Strength Estimation

準備

$ npm i zxcvbn

基本的な使い方

とりあえずhogehogeという文字列に対してパスワード強度をチェックしてみましょう。

const zxcvbn = require('zxcvbn');

const result = zxcvbn('hogehoge');
console.log(result);

基本的な使い方はとても簡単ですね。
第2引数に入力を渡して更に細かい設定をすることも可能なようですが、今回は遊んでみたかっただけなので割愛させてください。

出力内容を見てみましょう。

{
  password: 'hogehoge',
  guesses: 20003,
  guesses_log10: 4.301095134950942,
  sequence: [
    {
      pattern: 'repeat',
      i: 0,
      j: 7,
      token: 'hogehoge',
      base_token: 'hoge',
      base_guesses: 10001,
      base_matches: [Array],
      repeat_count: 2,
      guesses: 20002,
      guesses_log10: 4.301073422940843
    }
  ],
  calc_time: 3, # zxcvbnが計算するのにかかった時間(ミリ秒) あんまり気にしなくていい
  crack_times_seconds: { # パスワードが特定されるまでにかかる時間(秒)
    # 4種類の攻撃パターンごとの想定時間
    # 基本的には`offline_fast_hashing_1e10_per_second`の値だけ見ておけばいいかも
    online_throttling_100_per_hour: 720108,
    online_no_throttling_10_per_second: 2000.3,
    offline_slow_hashing_1e4_per_second: 2.0003,
    offline_fast_hashing_1e10_per_second: 0.0000020003
  },
  crack_times_display: { # パスワードが特定されるまでにかかる時間(わかりやすい形式)
    online_throttling_100_per_hour: '8 days',
    online_no_throttling_10_per_second: '33 minutes',
    offline_slow_hashing_1e4_per_second: '2 seconds',
    offline_fast_hashing_1e10_per_second: 'less than a second'
  },
  score: 1, # 0 ~ 4でパスワード強度を評価する
  feedback: {
    warning: 'Repeats like "abcabcabc" are only slightly harder to guess than "abc"',
    suggestions: [
      'Add another word or two. Uncommon words are better.',
      'Avoid repeated words and characters'
    ]
  }
}

crack_times_secondsの4種類のパターンについては、公式ドキュメントには次のように記述してありました。

• online_throttling_100_per_hour

online attack on a service that ratelimits password auth attempts.

• online_no_throttling_10_per_second

online attack on a service that doesn't ratelimit,
or where an attacker has outsmarted ratelimiting.

• offline_slow_hashing_1e4_per_second

offline attack. assumes multiple attackers,
proper user-unique salting, and a slow hash function
w/ moderate work factor, such as bcrypt, scrypt, PBKDF2.

• offline_fast_hashing_1e10_per_second

offline attack with user-unique salting but a fast hash
function like SHA-1, SHA-256 or MD5. A wide range of
reasonable numbers anywhere from one billion - one trillion
guesses per second, depending on number of cores and machines.
ballparking at 10B/sec.

うーん、セキュリティって難しい！

参考

• zxcvbn - npm

Actions使ってなにかするworkflowをつくるんじゃなくてAction自体をつくる話。

なにか簡単にGitHubActionsをつくってみたいと思い、GitHub公式のactions/labelerを参考にPRにラベルじゃなくてマイルストーンをつけるActionをつくろうと考えた。
Marketplaceで検索した結果、labelの方はちょいちょいあったがmilestoneの方はそんなにはまだなかった。マイルストーンの作成や更新がしたいのではなくてPRに既存のマイルストーンを結びつけたいってなると1,2件ぐらいしか無さそう。それらもこちらのやりたいこととは違った。
最終的につくったのはiyu/actions-milestone。

GitHub公式のテンプレートからリポジトリを作成する

GitHubのテンプレート機能は実は使ったことがなかったが、用意してくれているのだから使わない理由はない。javascript版(actions/javascript-action)とtypescript版(actions/typescript-action)が用意されている。あとはテンプレートと呼べるのか謎のミニマムなコンテナ版(actions/container-action)もあった。今回は無難にtypescriptを選択する。

[Use this template]って書いてある緑色のボタンからリポジトリを作成する。

こんな画面が出てくるがあとはいつものリポジトリ作成と同じ手順。

作成し終わるとforkしたリポジトリみたいにリポジトリ名の下にテンプレートに使ったリポジトリが表示されていた。ただコミットとかは引き継がれずすべてコピペしてInitial commitだけしたような感じの状態だった。別の世界線というより別世界だからテンプレートの今後のコミットをcherry-pickするのは難しいかもしれない。そんな心配する必要もないが。

テンプレートでできたリポジトリからconfig情報を書き換える

すぐにプログラミングに取り掛かりたいところだけどまずはconfigだけを書き換える。完全に好みの問題だがプログラムの修正も全部同じコミットにすると次回テンプレートから作成したときに何が必要になるのかわかりにくいなと思ったので。
やることは、

• README.mdの書き換え
  • Actionの開発方法とかが書いてあるので全部消して書き換えでいい
• package.json, package-lock.jsonの書き換え
  • リポジトリ名だったり説明文だったりurlだったり書き換える
  • package-lock.jsonの方はpackage.json書き換えた後にnpm installでもしとけば自動で書き換わるので手動で書き換える必要はない
• action.ymlの書き換え
  • action名だったり説明文だったり
  • この段階である程度input,output決まってるなら書き換えてもいいような、まだなような？

こちら書き換えたときのコミットなので参考に
https://github.com/iyu/actions-milestone/commit/4101ca509ee0fc10f84542abd65e416a3feca566

プログラムを書く

ここからやっとプログラミング

ESLintの設定

汚いコードをあとから修正するのは面倒なので最初に入れる。
tslintは2019年内に開発終了するらしいのでtypescriptのlintにはESLintを使う。

$ npm install --save-dev eslint

初期セットアップ (対話型のCLIでなんか色々聞かれるけど詳細は割愛)

ものすごくただの好みの問題だが自分はeslint-config-airbnb-baseを長らく使っている。

$ npm install --save-dev eslint-config-airbnb-base

このテンプレートではtestにjestを使っているみたいなのでjestのプラグインも入れる。

$ npm install --save-dev eslint-plugin-jest

最終的な.eslintrc.ymlはこんな感じ。好みで変えていく。

env:
  es6: true
  node: true
  jest/globals: true
extends:
  - airbnb-base
globals:
  Atomics: readonly
  SharedArrayBuffer: readonly
parser: '@typescript-eslint/parser'
parserOptions:
  ecmaVersion: 2018
  sourceType: module
plugins:
  - '@typescript-eslint'
  - jest
rules:
  no-console: off
  no-unused-vars: off
  '@typescript-eslint/no-unused-vars': error
settings:
  import/resolver:
    node:
      extensions:
        - .ts

実行時にtypescriptの拡張子を教えてあげる必要がある。早く省略できるようにして欲しい。

$ eslint --ext .ts,.js .

今回作るもの

大まかに区分するとこんな感じ。

1. inputデータを取得
2. PRの情報を取得
3. configファイルの中身を取得
4. ブランチ名からマイルストーンを割り出す
5. PRにマイルストーンをつける

inputデータを取得する

action.ymlに欲しいinputデータを記述しておく。

name: 'Pull Request Milestone'
description: 'Add milestone to PRs'
author: 'iyu'
inputs:
  repo-token:
    description: 'The GITHUB_TOKEN secret'
  configuration-path:
    description: 'The path for the milestone configurations'
    default: '.github/milestone.yml'
outputs:
  milestone:
    description: 'The Added Milestone'
runs:
  using: 'node12'
  main: 'lib/main.js'

上記の場合だとrepo-tokenとconfiguration-path
これをAction利用者が入力してくれるはずなのでそれをtypescript側で取得する。
こういう基本的なものはすべて公式のライブラリが取得方法を用意してくれているので簡単に取得できる。

import * as core from '@actions/core';

const token = core.getInput('repo-token', { required: true });
const configPath = core.getInput('configuration-path', { required: true });

requiredつけておけば値が存在しなかった時のエラー処理もいい感じにやってくれるのでエラー文考えなくても良い。便利。
（action.ymlでdefault付いてるくせにrequiredにしているのはただの嘘つき）

PRの情報を取得する

どのイベントから発火されたのかも公式のライブラリで簡単に取得できる。

import * as github from '@actions/github';

const pullRequest = github.context.payload.pull_request;
if (!pullRequest) {
  console.log('Could not get pull_request from context, exiting');
  return;
}

ブランチ名を利用してマイルストーンをつけるActionなのでPR以外のイベントの場合は上記のようになんかメッセージ表示して終了させる。

後々にPRのBaseブランチやHeadブランチの名前や現在のマイルストーンを利用したいのだが、このライブラリのtypesがしっかり全部書いてないので必要なパラメータは自分で拡張する必要がある。かなしい。

import * as github from '@actions/github';
import { WebhookPayload } from '@actions/github/lib/interfaces';

interface PullRequestWebhookPayload extends WebhookPayload {
  pull_request?: {
    [key: string]: any;
    number: number;
    html_url?: string;
    body?: string;

    milestone?: string;
    base: {
      ref: string;
    },
    head: {
      ref: string;
    },
  },
}
const pullRequest = (github.context.payload as PullRequestWebhookPayload).pull_request;

configファイルの中身を取得

inputで指定されたconfigファイルパスを取得する。action利用者がcheckoutをしているとも限らないのでファイルはAPI経由で取得する。このへんはactions/labelerを参考にしている。

import * as github from '@actions/github';

(async () => {
  // さっきのやつ
  // const token = core.getInput('repo-token', { required: true });
  // const configPath = core.getInput('configuration-path', { required: true });

  const client = new github.GitHub(token);

  const response = await client.repos.getContents({
    owner: github.context.repo.owner,
    repo: github.context.repo.repo,
    path: configPath,
    ref: github.context.sha,
  });
  const text = Buffer.from((response.data as { content: string }).content, 'base64').toString();
})();

（APIクライアントはPromise対応しているのでasync関数で囲ってる）
これでAPI経由でファイル取得可能だ。レスポンスの中のファイル内容についてはbase64文字列なのでtext変換している。

configファイルはこんな形式のyamlファイルを想定している。

base-branch:
  - "(master)"
  - "releases\\/(v\\d+)"

head-branch:
  - "feature\\/(v\\d+)\\/.+"

yamlファイルの文字列持っててもtypescriptで扱いにくいので今回はこんな感じのパーサーを用意して変換した。

import * as yaml from 'js-yaml';

interface ConfigObject {
  baseBranchList: RegExp[];
  headBranchList: RegExp[];
}

const parse = (text: string) => {
  const config: {
    'base-branch'?: string[],
    'head-branch'?: string[],
  } = yaml.safeLoad(text) || {};

  const result: ConfigObject = {
    baseBranchList: [],
    headBranchList: [],
  };
  result.baseBranchList = (config['base-branch'] || []).map((item) => new RegExp(item));
  result.headBranchList = (config['head-branch'] || []).map((item) => new RegExp(item));

  return result;
};

ブランチ名からマイルストーンを割り出す

このへんはもうこのAction固有の処理なのでそんなに詳しく書きません。baseブランチ、headブランチはWebhookのpayloadの中に入っているのでそれを使う。

const pullRequest = (github.context.payload as PullRequestWebhookPayload).pull_request;
const {
  milestone,
  number: prNumber,
  base: { ref: baseBranch },
  head: { ref: headBranch },
} = pullRequest;

先程のconfigで取ってきた正規表現とmatchするものを見つけてくる。milestoneは1つしかつけることはないので1件ヒットしたら即返却で良い。

export const match = (
  baseBranch: string,
  headBranch: string,
  configObject: ConfigObject,
): string|undefined => {
  let hit: string|undefined;
  configObject.baseBranchList.some((regexp) => {
    const m = baseBranch.match(regexp);
    if (m && m[1]) {
      ([, hit] = m);
    }
    return !!hit;
  });
  if (hit) {
    return hit;
  }

  configObject.headBranchList.some((regexp) => {
    const m = headBranch.match(regexp);
    if (m && m[1]) {
      ([, hit] = m);
    }
    return !!hit;
  });
  return hit;
};

PRにマイルストーンをつける

実はちょっとハマった。30分ぐらい悩んだ。
actions/labelerを参考にしていたので、最後にaddLabelのmilestone版のgithubのAPIを叩けば終わると思っていたがSDKにそんな関数は見当たらない。最初はpayloadが不完全だったこともあってSDKが対応していないだけだろうと思っていたのだがAPIリファレンスにもaddMilestoneだったりsetMilestoneなるものは見当たらなかった。悩んだ。
結論、milestoneはissueUpdate（PRもissueの一種なので同一API）やissueCreate時につけてやるものらしい。labelだけaddLabelなんてAPIがあるから騙された。issueのtitleを変える感覚でmilestoneも変更するみたい。

さらにいうとlabelと違ってmilestoneはmilestone用のID(下記コードのnumberの部分)を使ってissueを更新する。先程の項目で割り出したのはmilestoneのタイトルなのでそれと一致するmilestoneのIDを既存のmilestone一覧から探してこなくてはならない。

const addMilestone = 'v1.0';
const milestones = await client.issues.listMilestonesForRepo({
  owner: github.context.repo.owner,
  repo: github.context.repo.repo,
});
const { number: milestoneNumber } = milestones.data.find(({ title }) => title === addMilestone) || {};

既存のmilestoneが見つからなかった場合はmilestoneCreateとかで作成しても良かったわけだが、今回はメッセージ出すだけにした。やるならオプションで作成も一緒にするかみたいなフラグを追加しようかな。

if (milestoneNumber) {
  await client.issues.update({
    owner: github.context.repo.owner,
    repo: github.context.repo.repo,
    issue_number: prNumber,
    milestone: milestoneNumber,
  });
  core.setOutput('milestone', addMilestone);
} else {
  console.log(`Milestone not found, Please create it first "${addMilestone}".`);
}

今回は紐付けたmilestoneをoutputとして出力するactionなのでcore.setOutput('milestone', addMilestone);という一文も忘れずに。

Marketplaceに公開する

公式のドキュメントに画像つきで丁寧に書いてあるのでそこまで説明いらないとは思う。
https://help.github.com/ja/actions/automating-your-workflow-with-github-actions/publishing-actions-in-github-marketplace

公開する成果物にはnode_modulesも含めビルド済みのjsファイルがないといけないので、masterブランチではgitignoreにnode_modulesが入っていてそれとは別にnode_modulesを除外しないreleaseブランチを作ろう、とテンプレートでは書かれている。
https://github.com/actions/typescript-action#publish-to-a-distribution-branch

他の手段としては@zeit/nccを使ってそもそもnode_modulesも含めすべて1ファイルにしてしまうという方法もある。
https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-a-javascript-action

今回は前者の方法でやろうと思うが毎回そんな作業をするのも面倒なのでnpm preversionにビルド作業とnode_modules,ビルド成果物の追加を仕込んでおくことにした。package.jsonのscriptsの部分を書き換える

"scripts": {
 "preversion": "npm ci && npm run build && npm ci --production && git add node_modules lib -f"
}

該当する作業コミットはこれ。
https://github.com/iyu/actions-milestone/commit/a95202bc14122a66a01dc5aad55a6ebfed5279bd

これは何なのかというと、npm versionというpackage.jsonのversion部分をアップデートしつつgit-tagをつけてくれるコマンドの前にhookされるスクリプト。npmにライブラリを公開している人ならおなじみだと思う。
詳しくはここ https://docs.npmjs.com/cli/version

$ npm version major

> actions-milestone@1.0.0 preversion iyu/actions-milestone
> npm ci && npm run build && npm ci --production && git add node_modules lib -f

npm WARN prepare removing existing node_modules/ before installation
added 651 packages in 7.098s

> actions-milestone@0.0.0 build git/iyu/actions-milestone
> tsc

npm WARN prepare removing existing node_modules/ before installation
added 50 packages in 2.174s
v1.0.0

やってることはシンプルで、

1. npm ci node_modulesを消してからinstall (clean installの略だった気がする）
2. npm run build scriptsのbuildを実行 （typescriptのビルドが書かれてる)
3. npm ci --production ビルドのときしか必要でないpackageを消すために実行してる
4. git add node_modules lib -f .gitignoreにかかれているnode_modulesとビルド成果物をforce add

このあとに本来のnpm versionが動く。 （package.jsonのversionの更新とgit-commit, git-tag）

githubにpushしたらリリース物として[Draft a new release]のボタンを押してPublish this Action to the GitHub Marketplaceにチェックする。

カテゴリとかiconとか必要なものを埋めていく。iconは別になくてもいいっぽい。

これで無事完成！検索すればちゃんとMarketplaceに出てくるようになった！

さいごに

今回は一発目だったので簡単なActionにしたがもっとちゃんと実用性のあるActionを作っていきたい。ただ仕事で使うやつとなるとたぶんMarketplaceには上げないと思うので今回はまぁ楽しめた。
近々、チーム開発でGitHubActionsを使うにあたって苦労した点を記事にして書きたいと思う。

こちらの記事は、Sam Quinn 氏により2019年 4月に公開された『 Bulletproof node.js project architecture 』の和訳です。
本記事は原著者から許可を得た上で記事を公開しています。

GitHub repositoryでの実装例: 2019/04/21 アップデート

始めに

Express.jsは、node.js のREST APIを作成するための優れたフレームワークですが、node.jsプロジェクトの設計方法についての手がかりを与えてくれるものではありません。

ばからしく聞こえるかもしれませんが、この問題は確かに存在するのです。

node.jsプロジェクト構造の正しい設計により、コードの重複を回避でき、安定性を向上させます。また、正しく設計されていれば、サービスをスケールさせるときに役に立つかもしれません。

この記事は、貧弱な構造のnode.jsプロジェクト、望ましくないパターン、そしてコードリファクタリングと構造の改善に無数の時間を費やし対応してきた、長年の経験に基づく広範囲な探求です。

本記事に合わせnode.jsプロジェクトのアーキテクチャを見直すために助けが必要な場合は、santiago@softwareontheroad.comにご連絡ください。

目次

• フォルダ構造
• 3層アーキテクチャ
• サービスレイヤー
• Pub/Subレイヤー
• Dependency Injection (DI) --※日本語で「依存の注入」
• ユニットテスト
• Cron ジョブと定期的なタスク
• 構成情報及びシークレット
• ローダー 例（GitHub repojitory）

フォルダ構造

以下はこれから話を進めていくnode.jsプロジェクトの構造です。

構築するすべてのnode.js REST APIサービスで、これをを使用します。では、それぞれのコンポーネントが何をするのか詳しく見ていきましょう。

  │   app.js          # App entry point
  └───api             # Express route controllers for all the endpoints of the app
  └───config          # Environment variables and configuration related stuff
  └───jobs            # Jobs definitions for agenda.js
  └───loaders         # Split the startup process into modules
  └───models          # Database models
  └───services        # All the business logic is here
  └───subscribers     # Event handlers for async task
  └───types           # Type declaration files (d.ts) for Typescript

単なるJavascript ファイルの並び替えをする方法ではありません..

3層アーキテクチャ

下記のアイデアは、「関心の分離」の原則に基づき、ビジネスロジックをnode.js APIルーティングから分離させるものです。

これはあなたがいつか、CLIツールでビジネスロジックを使用したい、定期的なタスク処理では十分でない、と思うようになったときのためです。

そしてnode.jsサーバーからそれ自体へのAPI呼び出しは、良いアイディアではありません...

コントローラーにビジネスロジックを入れてはダメです!!

express.jsコントローラーを使用してアプリケーションのビジネスロジックを保存したくなるかもしれませんが、これはすぐにスパゲッティコードになります。ユニットテストを書く必要があるときには、リクエストまたはレスポンスexpress.jsオブジェクトの複雑なモックを扱うことになります。

いつ応答を送信するべきかを区別するのは複雑です。 バックグランドで処理が続行され、その後 応答がクライアントに送信されたとしましょう。

以下は望ましくない例です。

route.post('/', async (req, res, next) => {

    // This should be a middleware or should be handled by a library like Joi.
    const userDTO = req.body;
    const isUserValid = validators.user(userDTO)
    if(!isUserValid) {
      return res.status(400).end();
    }

    // Lot of business logic here...
    const userRecord = await UserModel.create(userDTO);
    delete userRecord.password;
    delete userRecord.salt;
    const companyRecord = await CompanyModel.create(userRecord);
    const companyDashboard = await CompanyDashboard.create(userRecord, companyRecord);

    ...whatever...


    // And here is the 'optimization' that mess up everything.
    // The response is sent to client...
    res.json({ user: userRecord, company: companyRecord });

    // But code execution continues :(
    const salaryRecord = await SalaryModel.create(userRecord, companyRecord);
    eventTracker.track('user_signup',userRecord,companyRecord,salaryRecord);
    intercom.createUser(userRecord);
    gaAnalytics.event('user_signup',userRecord);
    await EmailService.startSignupSequence(userRecord)
  });

ビジネスロジックをサービスレイヤーで扱っている

このレイヤーは、ビジネスロジックが存在すべき場所です。

それは、node.jsに適用されるSOLID原則に従って、明確な目的（情報）を持つクラスのコレクションです。

このレイヤーには「SQLクエリ」のいかなるフォームも存在するべきではありません。データアクセス層を使用してください。

• express.jsルーターからソースコードを遠ざける
• リクエストまたはレスポンスオブジェクトをサービスレイヤーに渡さない
• ステータスコードやヘッダーなど、HTTPトランスポートレイヤーに関連するものをサービスレイヤーから返さない

例

route.post('/', 
    validators.userSignup, // this middleware take care of validation
    async (req, res, next) => {
      // The actual responsability of the route layer.
      const userDTO = req.body;

      // Call to service layer.
      // Abstraction on how to access the data layer and the business logic.
      const { user, company } = await UserService.Signup(userDTO);

      // Return a response to client.
      return res.json({ user, company });
    });

サービスが裏でどのように機能するかを以下に示します。

  import UserModel from '../models/user';
  import CompanyModel from '../models/company';

  export default class UserService {

    async Signup(user) {
      const userRecord = await UserModel.create(user);
      const companyRecord = await CompanyModel.create(userRecord); // needs userRecord to have the database id 
      const salaryRecord = await SalaryModel.create(userRecord, companyRecord); // depends on user and company to be created

      ...whatever

      await EmailService.startSignupSequence(userRecord)

      ...do more stuff

      return { user: userRecord, company: companyRecord };
    }
  }

Pub/Sub レイヤーも利用する

pub / subパターンは,、ここで提案されている従来の3層アーキテクチャを超えていますが、非常に便利です。

すぐにユーザーを作成できるシンプルなnode.js APIエンドポイントは、分析サービスであったり、あるいは電子メールシーケンスの開始などのサードパーティサービスを呼び出そうとするかもしれません。

遅かれ早かれ、そのシンプルな「作成」の操作はいくつかのことを実行し、1,000行にも及ぶコードがすべて1つの関数中で実行されることになるでしょう。

それは単一責任の原則に反しています。

したがって最初から責任を分離しておくほうが良く、それによってコードの保守性を維持できます。

  import UserModel from '../models/user';
  import CompanyModel from '../models/company';
  import SalaryModel from '../models/salary';

  export default class UserService() {

    async Signup(user) {
      const userRecord = await UserModel.create(user);
      const companyRecord = await CompanyModel.create(user);
      const salaryRecord = await SalaryModel.create(user, salary);

      eventTracker.track(
        'user_signup',
        userRecord,
        companyRecord,
        salaryRecord
      );

      intercom.createUser(
        userRecord
      );

      gaAnalytics.event(
        'user_signup',
        userRecord
      );

      await EmailService.startSignupSequence(userRecord)

      ...more stuff

      return { user: userRecord, company: companyRecord };
    }

  }

依存サービスへの呼び出し命令は、最良の方法ではありません。

ここでより良いアプローチは、イベントを発行することです。（例.「ユーザーはこのメールでサインアップしました」）

これで完了です。リスナーの仕事は、リスナーの責任としています。

  import UserModel from '../models/user';
  import CompanyModel from '../models/company';
  import SalaryModel from '../models/salary';

  export default class UserService() {

    async Signup(user) {
      const userRecord = await this.userModel.create(user);
      const companyRecord = await this.companyModel.create(user);
      this.eventEmitter.emit('user_signup', { user: userRecord, company: companyRecord })
      return userRecord
    }

  }

イベントハンドラー/リスナーを複数のファイルに分割できています。

 eventEmitter.on('user_signup', ({ user, company }) => {

    eventTracker.track(
      'user_signup',
      user,
      company,
    );

    intercom.createUser(
      user
    );

    gaAnalytics.event(
      'user_signup',
      user
    );
  })

 eventEmitter.on('user_signup', async ({ user, company }) => {
    const salaryRecord = await SalaryModel.create(user, company);
  })

 eventEmitter.on('user_signup', async ({ user, company }) => {
    await EmailService.startSignupSequence(user)
  })

awaitステートメントをtry-catchブロックにラップする、もしくは単に失敗処理として” unhandledPromise “プロセスとして処理することもできます。

依存性の注入 （D.I.）

依存性の注入（D.I.）、または制御の反転（IoC）は、クラスまたは関数の依存関係をコンストラクターに「注入」または渡すことで、コードの編成に役立つ一般的なパターンです。

このようにすることで、例えばサービスの単体テストを作成するときや、サービスが別のコンテキストで使用されるとき、「互換性のある依存関係」を注入する柔軟性が得られます。

D.I. なしのコード

  import UserModel from '../models/user';
  import CompanyModel from '../models/company';
  import SalaryModel from '../models/salary';  
  class UserService {
    constructor(){}
    Sigup(){
      // Caling UserMode, CompanyModel, etc
      ...
    }
  }

手動でD.I. を実装したコード

 export default class UserService {
    constructor(userModel, companyModel, salaryModel){
      this.userModel = userModel;
      this.companyModel = companyModel;
      this.salaryModel = salaryModel;
    }
    getMyUser(userId){
      // models available throug 'this'
      const user = this.userModel.findById(userId);
      return user;
    }
  }

これでカスタマイズされた依存関係を注入できます。

  import UserService from '../services/user';
  import UserModel from '../models/user';
  import CompanyModel from '../models/company';
  const salaryModelMock = {
    calculateNetSalary(){
      return 42;
    }
  }
  const userServiceInstance = new UserService(userModel, companyModel, salaryModelMock);
  const user = await userServiceInstance.getMyUser('12346');

サービスが持つことのできる依存関係の量は無限で、新しく追加する際にいちいちインスタンス化をリファクタリングするのは、退屈でエラーが発生しやすいタスクです。

そういうわけでDI フレームワークが作成されました。

これにより、クラスで依存関係を宣言し、そのクラスのインスタンスが必要な場合には、 'Service Locator'を呼び出すだけでよくなります。

“ typedi “を用いてnode.jsにDIをもたらすnpmライブラリの例を見てみましょう。

“ typedi “の使用方法の詳細については公式ドキュメントをご覧ください。

注意: typescript での例

 import { Service } from 'typedi';
  @Service()
  export default class UserService {
    constructor(
      private userModel,
      private companyModel, 
      private salaryModel
    ){}

    getMyUser(userId){
      const user = this.userModel.findById(userId);
      return user;
    }
  }

ここでtypediはUserServiceが必要とする依存関係を解決します。

services/user.js

  import { Container } from 'typedi';
  import UserService from '../services/user';
  const userServiceInstance = Container.get(UserService);
  const user = await userServiceInstance.getMyUser('12346');

サービスロケーター呼び出しの乱用はアンチパターンです

Node.jsのExpress.jsでDIを使用する
express.jsでDIを使用する
これがnode.jsプロジェクトアーキテクチャのパズルの最後のピースです。

ルーティングレイヤー

 route.post('/', 
    async (req, res, next) => {
      const userDTO = req.body;

      const userServiceInstance = Container.get(UserService) // Service locator

      const { user, company } = userServiceInstance.Signup(userDTO);

      return res.json({ user, company });
    });

Awesome! 素晴らしいプロジェクトになりました！

とても整理されていて、「今すぐ何かをコーディングしたい！」という気持ちになりますね。

サンプルのレポジトリにアクセスする

単体テストの例

DI とこれらの設計パターンを使用することにより、単体テストは非常にシンプルになります。

リクエスト / レスポンス オブジェクトのモックや “ require … “ などの呼び出しを行う必要はありません。

例：サインアップユーザーメソッドの単体テスト

tests/unit/services/user.js

 import UserService from '../../../src/services/user';

  describe('User service unit tests', () => {
    describe('Signup', () => {
      test('Should create user record and emit user_signup event', async () => {
        const eventEmitterService = {
          emit: jest.fn(),
        };

        const userModel = {
          create: (user) => {
            return {
              ...user,
              _id: 'mock-user-id'
            }
          },
        };

        const companyModel = {
          create: (user) => {
            return {
              owner: user._id,
              companyTaxId: '12345',
            }
          },
        };

        const userInput= {
          fullname: 'User Unit Test',
          email: 'test@example.com',
        };

        const userService = new UserService(userModel, companyModel, eventEmitterService);
        const userRecord = await userService.SignUp(teamId.toHexString(), userInput);

        expect(userRecord).toBeDefined();
        expect(userRecord._id).toBeDefined();
        expect(eventEmitterService.emit).toBeCalled();
      });
    })
  })

Cronジョブと定期的なタスク

ここまででビジネスロジックがサービスレイヤーにカプセル化されたので、Cronジョブから使用するのが簡単になりました。

node.js のsetTimeoutや、その他の原始的なコード実行を遅らせる方法に頼るのではなく、ジョブやデータベース内での処理を永続化するフレームワークを使用するべきです。

こうすることで、失敗したジョブの制御や、成功した人のフィードバックを得ることができます。
node.js.
別の記事で、これらのグッドプラクティスについて既に書いていますので、こちらのガイドを確認してください。

構成情報及びシークレット

node.jsにおいて研鑽された概念である「Twelve-Factor App」に従えば、 APIキーとデータベース文字列の対応情報を保存するもっとも良い方法は、dotenvを使用することです。

決してコミットしてはいけない .envファイルを配置すると（ただし、リポジトリにデフォルト値で存在する必要があります）、 npm パッケージのdotenvは
.envファイルをロードし、変数を node.js のprocess.envオブジェクトに挿入します。

これでも十分かもしれませんが、もうワンステップ加えたいと思います。

npmパッケージの dotenv が 参照するディレクトリ（今回の例では /config）配下に" index.js "ファイルを配置し、.envファイルを読み込むことで 、変数を格納するオブジェクトを使用できます。これで構造とコードの自動補完を保持できます。

config/index.js

 const dotenv = require('dotenv');
  // config() will read your .env file, parse the contents, assign it to process.env.
  dotenv.config();

  export default {
    port: process.env.PORT,
    databaseURL: process.env.DATABASE_URI,
    paypal: {
      publicKey: process.env.PAYPAL_PUBLIC_KEY,
      secretKey: process.env.PAYPAL_SECRET_KEY,
    },
    paypal: {
      publicKey: process.env.PAYPAL_PUBLIC_KEY,
      secretKey: process.env.PAYPAL_SECRET_KEY,
    },
    mailchimp: {
      apiKey: process.env.MAILCHIMP_API_KEY,
      sender: process.env.MAILCHIMP_SENDER,
    }
  }

こうすることでprocess.env.MY_RANDOM_VARによってコード記述の氾濫を回避でき、自動補完によって環境変数の命名方法を知る必要がなくなります。

サンプルのレポジトリにアクセスする

ローダー

このパターンはW3Techマイクロフレームワークから取得しましたが、そのパッケージには依存していません。

このアイデアでは、node.jsサービスの起動プロセスをテスト可能なモジュールに分割することが可能です。

古典的なexpress.jsアプリの立ち上げ手順を見てみましょう

  const mongoose = require('mongoose');
  const express = require('express');
  const bodyParser = require('body-parser');
  const session = require('express-session');
  const cors = require('cors');
  const errorhandler = require('errorhandler');
  const app = express();

  app.get('/status', (req, res) => { res.status(200).end(); });
  app.head('/status', (req, res) => { res.status(200).end(); });
  app.use(cors());
  app.use(require('morgan')('dev'));
  app.use(bodyParser.urlencoded({ extended: false }));
  app.use(bodyParser.json(setupForStripeWebhooks));
  app.use(require('method-override')());
  app.use(express.static(__dirname + '/public'));
  app.use(session({ secret: process.env.SECRET, cookie: { maxAge: 60000 }, resave: false, saveUninitialized: false }));
  mongoose.connect(process.env.DATABASE_URL, { useNewUrlParser: true });

  require('./config/passport');
  require('./models/user');
  require('./models/company');
  app.use(require('./routes'));
  app.use((req, res, next) => {
    var err = new Error('Not Found');
    err.status = 404;
    next(err);
  });
  app.use((err, req, res) => {
    res.status(err.status || 500);
    res.json({'errors': {
      message: err.message,
      error: {}
    }});
  });


  ... more stuff 

  ... maybe start up Redis

  ... maybe add more middlewares

  async function startServer() {    
    app.listen(process.env.PORT, err => {
      if (err) {
        console.log(err);
        return;
      }
      console.log(`Your server is ready !`);
    });
  }

  // Run the async function to start our server
  startServer();

ご覧のとおり、アプリケーションのこの部分は非常に煩雑化しています。

これに関して効果的な対処法は以下です。

  const loaders = require('./loaders');
  const express = require('express');

  async function startServer() {

    const app = express();

    await loaders.init({ expressApp: app });

    app.listen(process.env.PORT, err => {
      if (err) {
        console.log(err);
        return;
      }
      console.log(`Your server is ready !`);
    });
  }

  startServer();

ここでローダーは、簡潔な目的を持つ単なる小さなファイルです

loaders/index.js

  import expressLoader from './express';
  import mongooseLoader from './mongoose';

  export default async ({ expressApp }) => {
    const mongoConnection = await mongooseLoader();
    console.log('MongoDB Intialized');
    await expressLoader({ app: expressApp });
    console.log('Express Intialized');

    // ... more loaders can be here

    // ... Initialize agenda
    // ... or Redis, or whatever you want
  }

express ローダー

loaders/express.js

  import * as express from 'express';
  import * as bodyParser from 'body-parser';
  import * as cors from 'cors';

  export default async ({ app }: { app: express.Application }) => {

    app.get('/status', (req, res) => { res.status(200).end(); });
    app.head('/status', (req, res) => { res.status(200).end(); });
    app.enable('trust proxy');

    app.use(cors());
    app.use(require('morgan')('dev'));
    app.use(bodyParser.urlencoded({ extended: false }));

    // ...More middlewares

    // Return the express app
    return app;
  })

mongo ローダー

loaders/mongoose.js

  import * as mongoose from 'mongoose'
  export default async (): Promise<any> => {
    const connection = await mongoose.connect(process.env.DATABASE_URL, { useNewUrlParser: true });
    return connection.connection.db;
  }

ローダーの完全な例はこちらをご覧ください

最後に..

ここまでで、私達は実績のあるnode.jsプロジェクトストラクチャについて深く理解できました。要約すると下記のような内容でしたね。

• 3層アーキテクチャを使用する
• ビジネスロジックをexpress.jsコントローラーに入れない
• PubSubパターンを使用してバックグラウンドタスクのイベントを発行する
• 負担を減らすためDI を実装する
• パスワード、シークレット、APIキーなどを漏らさないために構成マネージャーを使用する
• node.jsサーバー構成を、個別にロードできる小さな- モジュールに分割する

リポジトリの例はこちらからご覧ください。

ちょっと待って！まだ続きがあります。

この記事を楽しんでいただけたら、他の有益な情報も見逃すことがないように、私のメーリングリストを購読することをお勧めします。

何かを売りつけるようなことはしません。約束します！

今後の投稿もお見逃しなく！きっと気に入ってくれると思います :)

この記事のような、すごい記事がたくさんあるので、是非私のブログに来てください。

翻訳協力

Original Author: Sam Quinn
Thank you for letting us share your knowledge!

この記事は以下の方々のご協力により公開する事が出来ました。
改めて感謝致します。
選定担当: @aoharu
翻訳担当: @upaldus
監査担当: @aoharu
公開担当: @posaune0423

私たちと一緒に記事を作りませんか？

私たちは、海外の良質な記事を複数の優秀なエンジニアの方の協力を経て、日本語に翻訳し記事を公開しています。
活動に共感していただける方、良質な記事を多くの方に広めることに興味のある方は、ぜひご連絡ください。
Mailでタイトルを「参加希望」としたうえでメッセージをいただく、もしくはTwitterでメッセージをいただければ、選考のちお手伝いして頂ける部分についてご紹介させていただく事が可能です。
※ 頂いたメッセージには必ずご返信させて頂きます。

ご意見・ご感想をお待ちしております

今回の記事は、いかがだったでしょうか？
・こうしたら良かった、もっとこうして欲しい、こうした方が良いのではないか
・こういったところが良かった
などなど、率直なご意見を募集しております。
いただいたお声は、今後の記事の質向上に役立たせていただきますので、お気軽にコメント欄にてご投稿ください。Twitterでもご意見を受け付けております。
みなさまのメッセージをお待ちしております。

概要

• scoped sass (ファイル内限定で適用されるスタイル) を使いたいでござる
• でもnpm run ejectはしたくないでござる
• cra-sass を導入するとかんたんにできるでござる

参考文献

• How to use Sass and CSS Modules with create-react-app
• leighs-hammer/cra-sass

実行環境

• create-react-app で作った react project
  • 既存プロジェクトなのでversionわからん　すまん
• TypeScript

サンプルコード (変更前)

node-sass を入れてふつーにscssを使うとこうなる。

Sample.tsx

Sample.tsx

import * as React from "react";
import "./Sample.scss";

export const Sample: React.FC = () => {
  return (
    <div className="outer">
      OUTER
      <div className="inner">INNER</div>
      <ul>
        {["red", "blue", "green"].map((each, index) => (
          <li className={each} key={index}>
            {each.toUpperCase()}
          </li>
        ))}
      </ul>
    </div>
  );
};

export default Sample;

Sample.scss

Sample.scss

.outer {
  &,
  * {
    display: flex;
    flex-direction: column;
    padding: 8px;
    border-left: 1px solid gray;
  }

  font-size: 1.2rem;
  .inner {
    font-weight: bold;
  }
  ul {
    li {
      &.red {
        color: red;
      }
      &.green {
        color: green;
      }
      &.blue {
        color: blue;
      }
    }
  }
}

ビルド結果(html)

<div class="outer">
  OUTER
  <div class="inner">INNER</div>
  <ul>
    <li class="red">RED</li>
    <li class="blue">BLUE</li>
    <li class="green">GREEN</li>
  </ul>
</div>

実行結果

この実装の問題点

Sample.scss に記述したスタイルのscopeはグローバルである。
すなわち、Sample.tsx と同時にロードされるコンポーネントに、
同じclassName(例えば.outer)が割りあたっていると、互いに影響を受け合いバグの原因となる

解決策

閉じたscopeを扱うことのできるsass loaderを導入する

導入手順

cra-sass を導入

npm install --save-dev cra-sass

cra-sass を実行

$(npm bin)/cra-sass

するとなんかいっぱいインストールしてプロジェクトが魔改造される

package.json

@ devDependencies
+    "cra-sass": "0.0.5",

@ dependencies
+    "node-sass-chokidar": "^1.4.0",
+    "npm-add-script": "^1.1.0",
+    "npm-run-all": "^4.1.5",

@ scripts
-    "start": "react-scripts start",
-    "build": "react-scripts --max-old-space-size=2048 build",
+    "start": "npm-run-all -p watch-css start-js",
+    "build": "npm run build-css && react-scripts build",
     "test": "react-scripts test",
-    "eject": "react-scripts eject"
+    "eject": "react-scripts eject",
+    "build-css": "node-sass-chokidar src/ -o src/",
+    "watch-css": "npm run build-css && node-sass-chokidar src/ -o src/ --watch --recursive",
+    "start-js": "react-scripts start"

--max-old-space-size=2048 とか無くなってぶっ壊れてんじゃん！
ってことで無駄にぶっこわされたとこは直しておく

package.json

-    "build": "react-scripts --max-old-space-size=2048 build",
+    "build": "npm run build-css && react-scripts --max-old-space-size=2048 build",

サンプルコード(リファクタ後)

Sample.scss

Sample.module.scss に改名する

Sample.tsx

• scssのimport
• classNameの割当てのしかた

だけを変更

Sample.tsx

import * as React from "react";
import styles from "./Sample.module.scss";

export const Sample: React.FC = () => {
  return (
    <div className={styles.outer}>
      OUTER
      <div className={styles.inner}>INNER</div>
      <ul>
        {["red", "blue", "green"].map((each, index) => (
          <li className={styles[each]} key={index}>
            {each.toUpperCase()}
          </li>
        ))}
      </ul>
    </div>
  );
};

export default Sample;

ビルド結果

<div class="Sample_outer__144wv">
  OUTER
  <div class="Sample_inner__EiBfI">INNER</div>
  <ul>
    <li class="Sample_red__1ktYQ">RED</li>
    <li class="Sample_blue__32ZOZ">BLUE</li>
    <li class="Sample_green__2OrZU">GREEN</li>
  </ul>
</div>

css部分の抜粋

.Sample_outer__144wv {
  font-size: 1.2rem; }
  .Sample_outer__144wv,
  .Sample_outer__144wv * {
    display: flex;
    flex-direction: column;
    padding: 8px;
    border-left: 1px solid gray; }
  .Sample_outer__144wv .Sample_inner__EiBfI {
    font-weight: bold; }
  .Sample_outer__144wv ul li.Sample_red__1ktYQ {
    color: red; }
  .Sample_outer__144wv ul li.Sample_green__2OrZU {
    color: green; }
  .Sample_outer__144wv ul li.Sample_blue__32ZOZ {
    color: blue; }

その他やったこと

scriptsが壊されてないかチェックしよう

start, build, test が、 cra-sass によって破壊されている恐れがある
特にdefaultから変更している場合注意しよう

.cssが.scssと同階層に出力されるようになってうっおとしい

• node-sass-chokidar のしわざくさい
• でもoutputしなくするオプションとかなさげ
• めんどいから、別階層に吐かせて、ignoreすることにした

package.json

-    "build-css": "node-sass-chokidar src/ -o src/",
+    "build-css": "node-sass-chokidar src/ -o built-css/",
-    "watch-css": "npm run build-css && node-sass-chokidar src/ -o src/ --watch --recursive",
+    "watch-css": "npm run build-css && node-sass-chokidar src/ -o built-css/ --watch --recursive",

.gitignore

+/built-css

node-sass をすでに使っていた場合、不要になる

npm r node-sass

おしまい

これで快適な React x Scoped SASS 生活が始まる

この記事はFirebaseアドベントカレンダーの5日目の記事です。

どうも！ハムカツおじさんという名前でtwitterやってます(@hmktsu)?
自分でだったり弊社でだったりなどFirebaseを使ってサービスを作っています。

ちなみに先日Firebase Meetup #15 Cloud Functions Dayにて下記のスライドを発表させていただいたので、興味ある人はご覧になってください！
Firebaseオンリー + React Nativeでアプリを作ると果たして簡単になるのか？

はじめに

色んなツールを作るのにFirebaseを使うととても便利だなぁという感想を持っています。
料金に関しては体感としてですが常時サーバを立ち上げてるのとは違いお安くなります。
それでももっと安く済ませたいとかそういったことはあるのでしょうか。

本番環境でそれなりにお金がかかるのはしょうがないんだけども、テスト環境ではなるべくお金かけたくないしなぁ〜ということもあるのではないでしょうか。

ということでここらへんを気をつければなるべく料金を抑えれるんじゃないかなということを今回は紹介させていただきます。

対象とするFirebaseのサービス

• Firestore
• Functions
• Hosting

ざっくり気をつけたポイント

Firestore

• リージョンをどうするか
• ドキュメントの読み出し/書き込み/削除
• ページングの方法
• セキュリティールールについて

Functions

• メモリ(CPU)の割り当て
• 料金プラン

Hosting

• どういったファイルを置いているのか

こういう風に工夫するとよいかも

Firestore

• USじゃないといけない理由がないならば他のリージョンを使う
  • USはマルチリージョンなのでちょっと他よりもお高め(地域別料金)
• このデータが入っているか？という確認をしたいときに、コレクションからwhereするのではなく、複数のドキュメントを配列に格納したドキュメントを用意して、その中に入ってるかどうか比較する
• 読み出しをする際にオフセットを使わないでカーソルを使う
  • オフセットを使うとそれ以前のデータも読み取り回数に入ってしまう(大きな結果セットを管理する)
• ルールの評価はリクエストごとに1回のみ課金されるので、複数ドキュメントを呼び出すときはえいやと思い切って呼び出してみる(Cloud Firestore セキュリティ ルール)

Functions

• メモリ量でGB秒やCPU秒の料金が変わるので、さっと終わる処理ならばメモリを小さくする(コンピューティング時間)
• Blazeプランを使うと料金プランページに表示されているSparkプラン以上に無料で使える範囲が広くなる

Hosting

• Storageと比べると転送量や保存量が割高なので、Storageに画像とかをちゃんとおく

まとめ

正直なところFirebaseはAWSなどで組むのと違ってあまりお金はかかりません。
それにスケーラブルなので落ちないという利点もあります。

ただその代わりこの記事みたいに落ちないからこそ、使い方などを間違えてしまうと異常な料金になってしまうこともあります。
地味によくある話としてはStorageを使わずにHostingのみでWebサイトを作り、バズってしまったがために中々な請求金額がきてしまうとか。

ちなみに最終手段ですが、1日の使用料を実は制限することができます。
また1ヶ月の予算を設定して使用料に応じてアラートを出すこともできます。
1日あたりの費用制限を設定する
1か月の予算を設定する

これらを使うこともある意味ありなんじゃないかなと思います。

はじめに

この記事はアドベントカレンダーがマズくなったときのために書き溜めておいたものです。
これが公開されているということは、そういうことなのでしょう。

Brainfuckの開発を行うにあたって、ホットリロード機能が欲しいと思ったことはないですか？
むしろ、思い通りに動くほうが珍しい難解言語なので必須機能とも言えるでしょう。
そこで、自分でホットリロードができるBrainfuck環境を構築することにしました。

Brainfuck

Brainfuckとは

コンパイラがなるべく小さくなるように設計された簡潔な言語です¹。
以下に簡単なプログラムの例を示します。

src/hello.bf

>+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.[-]>++++++++[<++
++>-]<.>+++++++++++[<+++++>-]<.>++++++++[<+++>-]<.+++.------.--------.[-]>
++++++++[<++++>-]<+.[-]++++++++++.

出力

Hello World!

src/abc.bf

++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++.+.+.>++++++++++.

出力

ABC

導入

今回はBrainfuckのコンパイル環境としてjsbrainfuck²を使います。

$ yarn add jsbrainfuck

jsbrainfuck.interpret()の引数にBrainfuckの文字列を渡すと、コードを実行することができます。
適当に実行用のスクリプトを作成しました。

run.js

const { readFileSync } = require("fs");
const { interpret } = require("jsbrainfuck");
// 引数から対象ファイル名を取得して各ファイルを実行する
process.argv.slice(2).forEach((name) => {
  const source = readFileSync(name, "utf-8");
  console.log(`Executing ${name} =>`);
  const { print } = interpret(source); // Brainfuckコードを実行
  print(); // 実行結果を表示
});

以下のように複数のファイルを実行することもできます。

$ node run.js src/hello.bf src/abc.bf
Executing src/hello.bf =>
Hello World!
Executing src/abc.bf =>
ABC

jsbrainfuck.compile()の引数にBrainfuckの文字列を渡すとJSコードに変換された文字列が返ってきます。
適当にコンパイル用のスクリプトを作成しました。

compile.js

const { readFileSync, writeFileSync } = require("fs");
const { compile } = require("jsbrainfuck");

const name = process.argv[2]; // 入力ファイル名を引数から取得
const source = readFileSync(name, "utf-8");
const { code } = compile(source); // BrainfuckからJSコード生成
const out = process.argv[3]; // 出力ファイル名を引数から取得
writeFileSync(out, code);

$ node compile.js src/hello.bf hello.js
$ node hello.js
Hello World!

ホットリロード

ホットリロードとは

ファイルを変更したとき自動でコンパイルや実行を行うことを言います。
変更するたびに手動でコンパイルして実行する手間を省けます。

導入

Nodemon³というソース監視ツールを導入します。

$ yarn add nodemon

package.jsonに以下のような設定を追加して、./srcの中の.bfファイルを監視して、変更があったらnode ./run.js ./src/*.bfを実行するようにします。

package.json

{
  "nodemonConfig": {
    "watch": [
      "./src"
    ],
    "ext": "bf",
    "exec": "node ./run.js ./src/*.bf"
  }
}

Nodemonを起動すると監視が始まって、変更があるとリロードされていることがわかります。

$ yarn run nodemon
[nodemon] 2.0.1
[nodemon] to restart at any time, enter `rs`
[nodemon] watching dir(s): src/**/*
[nodemon] watching extensions: bf
[nodemon] starting `node ./run.js ./src/*.bf`
Executing ./src/abc.bf =>
ABC
Executing ./src/hello.bf =>
Hello World!
[nodemon] clean exit - waiting for changes before restart
[nodemon] restarting due to changes...
[nodemon] starting `node ./run.js ./src/*.bf`
Executing ./src/abc.bf =>
DEF
Executing ./src/hello.bf =>
Hello World!
[nodemon] clean exit - waiting for changes before restart

最後に

仕上げにpackage.jsonに以下のようなスクリプトを追加すると、yarn startでホットリロードができるBrainfuck環境が動くようになります。

package.json

{
  "scripts": {
    "start": "nodemon",
    "build": "node compile.js"
  }
}

これでBrainfuckのコーディングを快適に嗜むことができます。

---

1. Brainfuck - Wikipedia ↩

2. jsbrainfuck ↩

3. Nodemon ↩

Node.js を触ってみたいと思ったので、備忘録も兼ねて以下に記します。
よりよい方法やバグ等ございましたら、アドバイスいただけると光栄です。

今回は「メッセージ送信編」ということで、クライアントからサーバーへのメッセージの送信の処理を作成します。

※前回 node.jsを触るために簡単なチャットシステムを作る（サーバー接続編） という表題で、サーバー接続の処理を作成していますので、まだな方はこちらを参照ください。

クライアントからサーバーへメッセージを送信する

メッセージ入力フォームを作成

/public/index.html に、以下のメッセージ入力フォームを追加します。

index.html

<form action="">
    <input type="text" id="input_message" autocomplete="off" />
    <button type="submit">Send</button>
</form>

index.html 全体としては、以下のようになります。

index.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>mychat</title>
</head>
<body>
    <h1>node.js を触ってみた</h1>
    <form action="">
        <input type="text" id="input_message" autocomplete="off" />
        <button type="submit">Send</button>
    </form>
    <script src="/socket.io/socket.io.js"></script>
    <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
    <script src="client.js"></script>
</body>
</html>

クライアント側の処理

/public/client.js の末尾に、下記のようなSendボタンを押したときの処理を追加します。

client.js

// 「Send」ボタンを押したときの処理
$('form').submit(() => {
    const $inp = $('#input_message');
    const text = $inp.val();

    console.log('#input_message :', text);

    if (text) {
        // サーバーに、イベント名 'new message' で入力テキストを送信
        socket.emit('new message', text);
        // テキストボックスを空に
        $inp.val('');
    }
    // フォーム送信はしない
    return false;
});

/public/client.js 全体としては、以下のようになります。

client.js

'use strict';

// クライアントからサーバーへの接続要求
const socket = io.connect();

// 接続時の処理
socket.on('connect', () => {
    console.log('connect');
});

// 「Send」ボタンを押したときの処理
$('form').submit(() => {
    const $inp = $('#input_message');
    const text = $inp.val();

    console.log('#input_message :', text);

    if (text) {
        // サーバーに、イベント名 'new message' で入力テキストを送信
        socket.emit('new message', text);
        // テキストボックスを空に
        $inp.val('');
    }
    // フォーム送信はしない
    return false;
});

サーバー側の処理

server.js の「接続時の処理」の中に、下記処理を追加します。

server.js

// 新しいメッセージ受信時の処理
socket.on('new message', (strMessage) => {
    console.log('new message', strMessage);
});

server.js 全体としては、以下のようになります。

server.js

'use strict';

// モジュール
const http     = require('http');
const express  = require('express');
const socketIO = require('socket.io');
const moment   = require('moment');

// オブジェクト
const app    = express();
const server = http.Server(app);
const io     = socketIO(server);

// 定数
const PORT = process.env.PORT || 3000;

// グローバル変数
let iCountUser = 0; // ユーザー数

// 接続時の処理
io.on('connection', (socket) => {
    console.log('connection');

    // 切断時の処理
    socket.on('disconnect', () => {
        console.log('disconnect');
    });

    // 新しいメッセージ受信時の処理
    socket.on('new message', (strMessage) => {
        console.log('new message', strMessage);
    });
});

// 公開フォルダの指定
app.use(express.static(__dirname + '/public'));

// サーバーの起動
server.listen(PORT, () => {
    console.log('server starts on port: %d', PORT);
});

動作を確認する

サーバーを立ち上げた状態で、
http://localhost:3000 にアクセスします。

「aaa」と「あああ」というメッセージをフォームに入力し、「Send」ボタンを押します。
Google Chrome のデベロッパーツールの Console に、connectに続いて、
#input_message : aaa
#input_message : あああ
と表示されます。

下記のようにサーバー側で connection に続いて、
new message aaa
new message あああ
と表示されれば完了です。

node server.js
server starts on port: 3000
connection
new message aaa
new message あああ

サーバーからクライアントへメッセージを拡散する

サーバー側の処理

server.js の「接続時の処理」の中に、下記処理を追加します。

server.js

// 送信元含む全員に送信
io.emit('spread message', strMessage);

server.js 全体としては、以下のようになります。

server.js

'use strict';

// モジュール
const http     = require('http');
const express  = require('express');
const socketIO = require('socket.io');
const moment   = require('moment');

// オブジェクト
const app    = express();
const server = http.Server(app);
const io     = socketIO(server);

// 定数
const PORT = process.env.PORT || 3000;

// グローバル変数
let iCountUser = 0; // ユーザー数

// 接続時の処理
io.on('connection', (socket) => {
    console.log('connection');

    // 切断時の処理
    socket.on('disconnect', () => {
        console.log('disconnect');
    });

    // 新しいメッセージ受信時の処理
    socket.on('new message', (strMessage) => {
        console.log('new message', strMessage);

        // 送信元含む全員に送信
        io.emit('spread message', strMessage);
    });
});

// 公開フォルダの指定
app.use(express.static(__dirname + '/public'));

// サーバーの起動
server.listen(PORT, () => {
    console.log('server starts on port: %d', PORT);
});

クライアント側の処理

/public/client.js の末尾に、下記のようなSendボタンを押したときの処理を追加します。

client.js

// サーバーからのメッセージ拡散に対する処理
socket.on('spread message', (strMessage) => {
    console.log('spread message :', strMessage);

    // 拡散されたメッセージをメッセージリストに追加
    const li_element = $('<li>').text(strMessage);
    $('#message_list').prepend(li_element);
});

/public/client.js 全体としては、以下のようになります。

client.js

'use strict';

// クライアントからサーバーへの接続要求
const socket = io.connect();

// 接続時の処理
socket.on('connect', () => {
    console.log('connect');
});

// 「Send」ボタンを押したときの処理
$('form').submit(() => {
    const $inp = $('#input_message');
    const text = $inp.val();

    console.log('#input_message :', text);

    if (text) {
        // サーバーに、イベント名 'new message' で入力テキストを送信
        socket.emit('new message', text);
        // テキストボックスを空に
        $inp.val('');
    }
    // フォーム送信はしない
    return false;
});

// サーバーからのメッセージ拡散に対する処理
socket.on('spread message', (strMessage) => {
    console.log('spread message :', strMessage);

    // 拡散されたメッセージをメッセージリストに追加
    $('#message_list').prepend($('<li>').text(strMessage));
});

メッセージをビュー側に表示

/public/index.html のメッセージ入力フォームの下に、以下のメッセージリストを追加します。

index.html

<ul id="message_list"></ul>

index.html 全体としては、以下のようになります。

index.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>mychat</title>
</head>
<body>
    <h1>node.js を触ってみた</h1>
    <form action="">
        <input type="text" id="input_message" autocomplete="off" />
        <button type="submit">Send</button>
    </form>
    <ul id="message_list"></ul>
    <script src="/socket.io/socket.io.js"></script>
    <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
    <script src="client.js"></script>
</body>
</html>

動作を確認する

メッセージの表示

サーバーを立ち上げた状態で、
http://localhost:3000 にアクセスします。

「aaa」と「あああ」というメッセージをフォームに入力し、「Send」ボタンを押します。

送信したメッセージが、リスト表示されます。

別ブラウザでもメッセージを表示

ブラウザを別に立ち上げ、
http://localhost:3000 にアクセスします。

「bbb」と「いいい」というメッセージをフォームに入力し、「Send」ボタンを押します。

送信したメッセージが、両方のブラウザに、即座に、リスト表示されれば完了です。

最後に

今回作成する機能としては以上となります。

ここで作成した機能をベースに、
以下のような機能や他にも自分で思いついた機能などを追加してみるのも良い学習になると思います。

• メッセージに時刻を表示
• メッセージに発信者名を表示
• ユーザーの入室、退室を表示

ソースコードは以下に載せていますので、よろしければ参照ください。
https://github.com/genki-sano/express-socketio-chat

関連記事

• node.jsを触るために簡単なチャットシステムを作る：環境構築編
• node.jsを触るために簡単なチャットシステムを作る：サーバー接続編
• node.jsを触るために簡単なチャットシステムを作る：メッセージ送信編

CIのActivateとかでライセンスを自動でActivateさせたい！

CIでUnityを扱う時はJenkinsとかであれば問題ないのですが、CircleCIやGitHub Actionsを使用するときにDockerでのライセンス認証では.ulfファイルというのが必要になってきます。

現在.ulfファイルをコマンドラインから生成することはできません。生成するにはブラウザ経由の一択です。
それを今回Puppeteerというnode.jsのツールを使って自動化してみました。

※今回の認証フローはPersonalEdition固定になります。

Puppetterとは、Webブラウザでの操作をソースコードから行えるものになります。
詳しくはこちら
Puppeteer

今回のリポジトリはこちら
MizoTake/unity-license-activate

実装

npm経由でPuppeteerを入れて以下のjsで実装しました。

今回はライセンスの認証が必要になるので https://license.unity3d.com/manual のページで操作を行います。
手元にあるalfファイルから最終的にulfファイルをダウンロードする操作になります。

叩くコマンドは以下になります
node activate.js $email $password $alf_file_path

以下が今回のScriptの全容ですが細かく分けてどうなっているのか下で記述します。

activate.js

const puppeteer = require('puppeteer')
const fs = require('fs')

;(async () => {
  const browser = await puppeteer.launch()
  const page = await browser.newPage()

  const downloadPath = process.cwd()
  const client = await page.target().createCDPSession()
  await client.send('Page.setDownloadBehavior', {
    behavior: 'allow',
    downloadPath: downloadPath
  })

  await page.goto('https://license.unity3d.com/manual')

  await page.waitForNavigation({
    timeout: 60000,
    waitUntil: 'domcontentloaded'
  })

  const email = `${process.argv[2]}`
  await page.type('input[type=email]', email)

  const password = `${process.argv[3]}`
  await page.type('input[type=password]', password)
  await page.click('input[name="commit"]')

  await page.waitForNavigation({
    timeout: 60000,
    waitUntil: 'domcontentloaded'
  })

  const input = await page.$('input[name="licenseFile"]')

  const alfPath = `${process.argv[4]}`
  await input.uploadFile(alfPath)

  await page.click('input[name="commit"]')

  await page.waitForNavigation({
    timeout: 60000,
    waitUntil: 'domcontentloaded'
  })

  const selectedTypePersonal = 'input[id="type_personal"][value="personal"]'
  await page.evaluate(
    s => document.querySelector(s).click(),
    selectedTypePersonal
  )

  const selectedPersonalCapacity =
    'input[id="option3"][name="personal_capacity"]'
  await page.evaluate(
    s => document.querySelector(s).click(),
    selectedPersonalCapacity
  )

  await page.click('input[class="btn mb10"]')

  await page.waitForNavigation()

  await page.click('input[name="commit"]')

  let _ = await (async () => {
    let ulf
    do {
      for (const file of fs.readdirSync(downloadPath)) {
        ulf |= file.endsWith('.ulf')
      }
      await sleep(1000)
    } while (!ulf)
  })()

  function sleep(milliSeconds) {
    return new Promise((resolve, reject) => {
      setTimeout(resolve, milliSeconds)
    })
  }

  await browser.close()
})()

画面ごとの処理

  // ライセンス認証を行うページに行く
  await page.goto('https://license.unity3d.com/manual')

  await page.waitForNavigation({
    timeout: 60000,
    waitUntil: 'domcontentloaded'
  })

  // ライセンス認証を行うページに飛ばしたがリダイレクトでUnityのログインページに飛んでいる

  //コマンド引数からメールアドレスとパスワードをとってくる
  const email = `${process.argv[2]}`
  await page.type('input[type=email]', email)

  const password = `${process.argv[3]}`
  await page.type('input[type=password]', password)

  // Sign inのボタンを押す
  await page.click('input[name="commit"]')

↓

  const input = await page.$('input[name="licenseFile"]')

  // コマンドライン引数で指定したpathからfileを添付
  const alfPath = `${process.argv[4]}`
  await input.uploadFile(alfPath)

  // Nextボタンを押す
  await page.click('input[name="commit"]')

これでファイル添付ができてることがわかります。ファイル添付までできるのすげぇ…Puppeteer…

↓

  // Personal Editionの選択
  const selectedTypePersonal = 'input[id="type_personal"][value="personal"]'
  await page.evaluate(
    s => document.querySelector(s).click(),
    selectedTypePersonal
  )

  // Personal Edition選択後に出てくるのOptionを選択
  const selectedPersonalCapacity =
    'input[id="option3"][name="personal_capacity"]'
  await page.evaluate(
    s => document.querySelector(s).click(),
    selectedPersonalCapacity
  )
　　
　// Nextボタンを押す
  await page.click('input[class="btn mb10"]')

この画面の実行後はこうなっています。

↓

  // Download license fileボタンを押す
  await page.click('input[name="commit"]')

  // ダウンロードが始まるので手元に.ulfファイルができるまで待つ
  let _ = await (async () => {
    let ulf
    do {
      for (const file of fs.readdirSync(downloadPath)) {
        ulf |= file.endsWith('.ulf')
      }
      await sleep(1000)
    } while (!ulf)
  })()

  function sleep(milliSeconds) {
    return new Promise((resolve, reject) => {
      setTimeout(resolve, milliSeconds)
    })
  }

以上のような流れになっています。

さいごに

Puppeteer便利！！！！

  await page.screenshot( {
    path: "./example.png"
  });

でScreenShotを撮りつつ実装してました。

ブラウザでしか行えない操作もこれがあればできるので色々と捗るんじゃないかなと思っています。