TypeScriptでwindowにプロパティを追加するいくつかの方法

DjangoのテンプレートにReactを埋め込むとかいう、妙なことをしているときに、とある理由からwindowにReactやらを追加しておく必要ができたのですが、TypeScriptだとそのまま突っ込むと型の関係で怒られました。

調べてみるとほぼこのタイトルの記事があったのですが、他にもいくつか解決策が出たので残しておきます。

• TypeScriptでwindowにプロパティを追加する - sansaisoba's tech blog

ちなみに、怒られたのはuseStateがReact自身の同一性を見ているからでした。 https://reactjs.org/warnings/invalid-hook-call-warning.html#duplicate-react

1. windowを作り直す

最初は上記の記事にあるように、window.tsファイルを作成して実装しました。

たしかこんな感じで書いたらいけるはずです。

• window.ts

interface MyWindow extends Window {
  HogeForm: Comment
}
declare var window: MyWindow;
export default window;

• index.ts

import React from 'react';
import { render } from 'react-dom';
import HogeForm from '../containers/HogeForm';
import window from './window';

render(<HogeForm />, document.getElementById('hoge_container'));

これで、hoge_containerタグの場所の表示を置き換えて表示しました。HogeFormの型はCommentでいけます。

この場合、表示するクラスやらが増える度にwindow.tsを修正することになります。

2. as anyを使う

管理ファイルが増えるのも煩わしいなぁとぼやいていたら、同僚にanyを使ったらやり方を教えてもらいました。

import React from 'react';
import ReactDOM from 'react-dom';
(window as any).React = React;
(window as any).ReactDOM = ReactDOM;

import { HogeForm } from '../containers/HogeForm';
(window as any).HogeForm = HogeForm; 

これだとファイルも増えないので、わかりやすさは上がった気がします。 でもTypeScript使っててanyって明示するのもなぁと、同僚と唸ることに。

3. expose-loaderを使う

といったわけで、最終的にはexpose-loaderを使って解消しました。

import 'expose-loader?React!react';
import 'expose-loader?ReactDOM!react-dom';

import 'expose-loader?Containers!./containers/'; 

ライブラリを追加する必要はありますが、コード自体はだいぶスッキリしたので、対価には見合っているかなと。 ただ、直接関数をロードすると、呼び出す側が正しく認識できなかったので、いったんObjectにするようにしています（ここではContainers）。

これによって使う側がどう変わるかと言うと、django-react-templatetagsでの書き方が、

• expose-loader導入前

{% load react %}
{% react_render component="HogeForm" props=hoge_data %}

• expose-loader導入後

{% load react %}
{% react_render component="Containers.HogeForm" props=hoge_data %}

のようになります。

---

といったのを9月くらいにやっていたのですが、気付けばもう年も変わっているという、、、

今年は忘れないうちにアウトプットしていきたいところです。

【主にスクラム向け】プロダクトバックログフォーマットと運用フローについて

プロダクトバックログのテンプレートが欲しい

「プロダクトバックログなんて、そんな何個も作るものじゃないでしょ」

とか思っていたときもあったのですが、ここ数年、公私合わせて、年2、3個はプロダクトバックログ（PBL）を作り、その都度フォーマットを作っていたので、 いい加減（自分のためにも）PBLのフォーマットを決め、テンプレートを用意するようにしました。

これが「さいきょうのPBLだ！」

最強なのかはともかく、現時点で一番わかりやすく運用しやすいPBLのフォーマットは、以下のようになりました。

テンプレートにはGoogleスプレッドシートを利用しています。

なぜかというと、現状ではこれが一番全体の把握がしやすく、多くの人が特に追加費用無しでアクセス可能であり、独自カスタマイズを許容できるツールになるからです。
セルに記述するというのも、アイテムを追加する人の心理的障壁を下げていますし、途中を許容しつつ議論ができるのも利点だと思うので、 特に強いこだわりがないのであれば、現状はスプレッドシート一択で良いのではないでしょうか。

PBL項目

スプレッドシートの各項目は以下のような用途を想定しています。

項目	用途
No	通番。優先度で前後させても通番を振り直しはしない
エリア	開発範囲を示すときに使う。LeSS Hugeのエリアに相当
ステータス	プロダクトバックログアイテムの状態を表す（詳細は後述）
誰が	誰のための価値になるものを作るのかを明示する。ユーザストーリのWho
何をしたい	どういったことを実現するのか。ユーザストーリのWhat
それはなぜか（価値）	どういう価値が提供されるのか（リリース後に検証する内容）を書く。ユーザストーリのWhy
ポイント	ストーリポイントを書く
レビューチェック内容	このアイテムでどういったことを実現するのかを具体的に書く。スプリントレビューの受け入れ基準に相当（How）
備考	SKIPにした理由や、アイテム分割した際の情報などを書く

PBLに携わる人数が多ければ、起票者の項目もあると便利です

スクラムでのPBL運用フロー

ではこのPBLをスクラムのイベントに沿って運用するフローを提示してみたいと思います。

1. プロダクトバックログリファインメントを実施

1. 各自がプロダクトバックログにTODOでアイテムを追加する（事前記入だったり、時間を取ってやったりする）
2. プロダクトバックログリファインメントを実施し、アイテムの上の方から内容を確認していく
   1. TODOを追加した人から内容の説明を受け、チーム内のゴール認識を合わせる（レビューチェック内容を決める）
   2. アイテムのストーリーポイントを見積もる
   3. アイテムの状況に合わせて、ステータスを変更する
3. アイテムの粒度が大きすぎたり、不明瞭な場合は、実現可能な粒度にアイテムを分割して、再度内容を精査する

ステータスは以下のような意味合いで利用します。

ステータス	意味
TODO	アイテムを起票した状態で、まだチームへの展開が行われていない
READY	展開された内容が、現時点で着手可能
NOT READY	展開された内容が、まだ着手不可能
DOING	スプリントで実施中
DONE	アイテムが完了している
WAIT	現状議論する段階にない（議論できない）
PENDING	どうするかを保留した
SKIP	一旦実施しないこととした

2. スプリントプランニングを実施

PBL上位のアイテムでステータスがREADYとなっているものからスプリントで実施するアイテムを決め、そのアイテムのステータスをDOINGにする。

選んだアイテムはスプリントバックログ（ホワイトボードを使うのがお奨め）に移動し、タスクを詳細化・細分化する。

3. スプリントレビューを実施

スプリントで作成した成果（プロダクトインクリメント）を、PBLのレビューチェック内容と照らし合わせながらレビューする。

実現できていればステータスはDONEにし、追加で実現したいことが見つかったならPBLに新しいアイテムをTODOで追加する。

4. 繰り返し

これらを繰り返していく。

まとめ

個人的には、価値を生み出す作業にどれだけ注力できるかが、アジャイル開発の目指すところかなと思っているので、それ以外の部分については可能な限り力をかけずに済ませるようにしたいです。

ちょっとでもPBLのフォーマットに迷うくらいであれば、とりあえずこのフォーマットに書き殴ってみて、後で適当なものに切り替えてみるとかはどうでしょうか。

【MySQL 8向け】MyBatis Migrationsのコンテナ化

JVM系のマイグレーションツールの導入

新しくSpring Bootの開発環境をコンテナ上で作る上で、DBマイグレーションツールのMyBatis Migrationsをコンテナで使えるようしたので、その手順をまとめておきます。

Docker Composeの構成

作っていた開発環境のマイグレーション関連部分に絞ってディレクトリ構成を表すと、以下のようになっています。

$ tree -d
.
├── sample
│   └── migration
│       ├── drivers
│       └── sample
│           ├── environments
│           └── scripts
└── mysql
    ├── conf.d
    ├── data
    ├── log
    ├── sql
    └── tmp
        └── data

プロジェクトルートにdocker-compose.ymlを置き、それ起因でコンテナを運用するようにしています。

マイグレーション自体はdocker composeを持つリポジトリとは別で管理しているので、 アプリケーション名のディレクトリ（ここではsample）配下に、migrationディレクトリとしてgit cloneして利用するイメージです。

• docker-compose.yml

version: '3.7'
services:
  migration:
    build:
      context: ./sample/migration/
    image: sample-migration
    container_name: sample_migration
    command: /bin/bash
    tty: true
    working_dir: "/sample/migration"
    volumes:
      - ./sample/migration:/sample/migration:cached
    depends_on:
      - db

  db:
    image: mysql:8
    container_name: sample_db
    environment:
      MYSQL_ROOT_PASSWORD: "root"
      #MYSQL_DATABASE: "sample"
      MYSQL_USER: "admin"
      MYSQL_PASSWORD: "admin"
    volumes:
      - ./mysql/sql:/docker-entrypoint-initdb.d
      - ./mysql/conf.d:/etc/mysql/conf.d
      - ./mysql/data:/var/lib/mysql
      - ./mysql/tmp/data:/tmp/data
      - ./mysql/log:/var/log/mysql
    command: mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    ports:
      - "3306:3306"

このdocker-compose.ymlでは、MySQL 8のコンテナを立ち上げ、その後マイグレーション用のコンテナを立ち上げています。

MySQLのコンテナイメージ

MySQLのコンテナイメージでは、MYSQL_DATABASEを指定することで、予めDBを作成することもできるのですが、 DBは複数利用することを考え、コンテナイメージ作成時に実行されるinit.sqlで作成するようにしています。

• mysql/sql/init.sql

CREATE DATABASE sample CHARACTER SET utf8mb4;
GRANT ALL ON *.* TO 'admin'@'%' WITH GRANT OPTION;
CREATE USER 'admin'@'localhost' IDENTIFIED BY 'admin';
CREATE USER 'admin'@'127.0.0.1' IDENTIFIED BY 'admin';
FLUSH PRIVILEGES;

MyBatis Migrationsのコンテナイメージ

本題のMyBatis Migrationsのコンテナイメージは、OpenJDKのイメージをベースに作成します。

• sample/migration/Dockerfile

FROM openjdk:11-slim

RUN apt-get update && apt-get install -y \
        wget \
        unzip \
    && apt-get clean \
    && rm -rf /var/lib/apt

RUN wget https://github.com/mybatis/migrations/releases/download/mybatis-migrations-3.3.5/mybatis-migrations-3.3.5-bundle.zip \
    && unzip mybatis-migrations-3.3.5-bundle.zip -d /usr/local \
    && rm mybatis-migrations-3.3.5-bundle.zip

ENV MYBATIS_MIGRATIONS_HOME /usr/local/mybatis-migrations-3.3.5
ENV PATH $PATH:$MYBATIS_MIGRATIONS_HOME/bin

WORKDIR /sample/migration

COPY . .
CMD ["/bin/bash"]

docker-compose up -d後（コンテナイメージ起動後）、コンテナに入ってマイグレーションスクリプトのテンプレートを作成します。

mkdir sample
cd sample
migrate init

この際、コマンド実行ディレクトリにdriversディレクトリが作成されますが、複数DBのスクリプト管理をすることを考え、WORKDIR配下にdriversを移動させます。

実際に利用するMySQLのJDBCコネクタは、以下からダウンロードし、先ほどのディレクトリに配置してください。

• MySQL :: Download Connector/J

その後、プロパティの以下を生成された値から変更します。

• time_zoneをAsia/Tokyoに
• script_char_setをアンコメント
• JDBCに必要な設定を追加（driverのクラスに注意）
• send_full_scriptをアンコメントしてfalseに
  • これをしないとマイグレーションスクリプト実行でMySQLの構文エラーになる

• driver_pathをJDBCコネクタを配置したコンテナ内の絶対パスに

• sample/migration/sample/environments/development.properties

## Base time zone to ensure times are consistent across machines
time_zone=Asia/Tokyo

## The character set that scripts are encoded with
script_char_set=UTF-8

## JDBC connection properties.
driver=com.mysql.cj.jdbc.Driver
url=jdbc:mysql://db:3306/sample
username=admin
password=admin

#
# A NOTE ON STORED PROCEDURES AND DELIMITERS
#
# Stored procedures and functions commonly have nested delimiters
# that conflict with the schema migration parsing.  If you tend
# to use procs, functions, triggers or anything that could create
# this situation, then you may want to experiment with
# send_full_script=true (preferred), or if you can't use
# send_full_script, then you may have to resort to a full
# line delimiter such as "GO" or "/" or "!RUN!".
#
# Also play with the autocommit settings, as some drivers
# or databases don't support creating procs, functions or
# even tables in a transaction, and others require it.
#

# This ignores the line delimiters and
# simply sends the entire script at once.
# Use with JDBC drivers that can accept large
# blocks of delimited text at once.
send_full_script=false

# This controls how statements are delimited.
# By default statements are delimited by an
# end of line semicolon.  Some databases may
# (e.g. MS SQL Server) may require a full line
# delimiter such as GO.
# These are ignored if send_full_script is true.
delimiter=;
full_line_delimiter=false

# If set to true, each statement is isolated
# in its own transaction.  Otherwise the entire
# script is executed in one transaction.
# Few databases should need this set to true,
# but some do.
auto_commit=false

# If set to false, warnings from the database will interrupt migrations.
ignore_warnings=true

# Custom driver path to allow you to centralize your driver files
# Default requires the drivers to be in the drivers directory of your
# initialized migration directory (created with "migrate init")
driver_path=/sample/migration/drivers

# Name of the table that tracks changes to the database
changelog=CHANGELOG

# Migrations support variable substitutions in the form of ${variable}
# in the migration scripts.  All of the above properties will be ignored though,
# with the exception of changelog.
# Example: The following would be referenced in a migration file as ${ip_address}
# ip_address=192.168.0.1

これで準備完了です。

使い方

実際に利用する際は、initしたときのように起動後にコンテナ内に入ってmigrate upを実行でもいいですが、以下のように直接実行することもできます。

$ docker-compose up -d
$ docker-compose exec migration bash -c "cd sample && migrate up"

初回の起動スクリプトなどを組む場合は、こちらの使い方が便利です。

手順は以上です。よいコンテナライフを！

PythonでのAWS Lambda開発メモ（利用開始編）

Lambdaを使うことになった経緯

Lambdaの利用経験がなかった私が、Lambda利用を決めた流れは

1. 1日1回のS3のファイルチェック処理が必要になる
2. ファイルがなかったらSlack通知してくれればいい（簡単なスクリプトでOK
3. 今のところ、AWS上にサーバは立ってない
4. 調べてみたらLambdaもスケジュール実行できるらしい
5. ならインフラコストを考えるとLambdaがいいか

でした。

Lambdaで利用する言語については、JupyterやGlueと合わせてPythonに。

LambdaやPythonの学習コストは、自分が払って展開すれば大したことにはならないだろうという見込みもあり、

「ついに私もサーバレスか・・・」

と感慨深く利用を始めました。

Lambda利用のために何をやったらいいのか？

Lambdaはマネージドサービスなので、AWS Console内で作業ができるようになっています。 エディタも用意されており、そこのテンプレートコードにあるlambda_handle関数に処理を書けば、指定のトリガーで実行される仕組みです。

言えば簡単なのですが、以下を懸念していました。

• Pythonのライブラリ利用について
• コード管理
• ログ管理
• テスト実行（テストコードではなく）
• デプロイの自動化

なので、今回はこれらについて記事にしようと思います。

---

Pythonのライブラリ利用について

Lambdaを利用した際に、最初から用意されているライブラリはBoto3で、それ以外を利用したい場合は、利用するPythonのコードと一緒にzipでまとめて、アップロードする必要がありました。

• Lambda 実行環境と利用できるライブラリ - AWS Lambda
• デプロイパッケージの作成 (Python) - AWS Lambda

今回はSlack通知の処理部分にrequestsを使いたかったので、zipでまとめてアップロードしています。

コード管理

そんな事もあって、幸か不幸かLambdaのコンソール上だけでは完結しなかったため、Lambdaプロジェクト用のGitHubリポジトリを作成し、コードは当該リポジトリ配下で記述するようにしました。

ディレクトリ構成はLambdaコンソールを参考に、リポジトリルート直下に関数名のディレクトリを作成して、そこにコードを置き、リポジトリルート直下には以下のようなシェルファイルを作成して、アップロード用のzipを作る、といった具合の構成です。

rm -rf upload.zip
pip3 install requests -t ./someLambdaFunction
cd someLambdaFunction
zip -r ../upload.zip *

しくじりポイント

zipは展開後が関数名のディレクトリになるのではなく、ソースコードの配置になっていないと駄目でした。

Lambdaコンソール上では、例えばsomeLambdaFunction/lambda_function.pyのような構成になっているので、てっきりsomeLambdaFunctionディレクトリもzipに含めるのかと思っていましたが、含めてしまうとsomeLambdaFunction/someLambdaFunction/lambda_function.pyのようになり、動作しなくなります。

環境変数の利用

WebhookのURLなどは環境変数を利用することで、コードから除去することができます。

• 【アップデート】AWS Lambdaで環境変数を使えるようになりました！！！ ｜ DevelopersIO

ログ管理

ログについては標準出力に出しさえすれば、特に設定もなくCloudWatch Logsで見れました。

テスト実行（テストコードではなく）

関数のテスト実行はLambda上でテスト用のトリガーを作成して、それを実行すればできます。

処理内部で外部パラメータを利用しないのであれば、トリガーで渡すパラメータはデフォルトのままで問題ありません。

ローカルで開発・実行できるように準備もしたのですが、アクセスキーの発行を渋られて、結局Lambda上でのみ動作テストすることになってしまいました。。

デプロイの自動化

デプロイは少し曲者で、AWSのマネージドで完結させることはできなそうでした。

最初はCodeDeployでいけるかと思ったのですが、CodeDeployはデプロイされているLambdaのバージョンを切り替えることしかできないようでした。 CloudFormationを使えばいけるのかもしれませんが、ちょっとイメージしているのとは違うというか、CIと流れるように実行したかったといいますか。

lambda-uploaderを使えばできそうだったのですが、アクセスキーが・・・
AWS Lambda Pythonをlambda-uploaderでデプロイ ｜ DevelopersIO

というわけで、これはまだ手動です。

Lambdaを使ってみて

「思っていたより簡単に利用できてびっくりした」というのが素直な感想です。

サーバの用意もいらないし、実行のコスト（金額的な意味で）もほとんどかからないしで、いいとこづくめだなと。 でもその恩恵に預かれるのはLambdaを知っている人だけなんだなぁと思うと、読みかけのサーバレス本をちゃんと読んで、もっと使いこなせるようになっておこうという気になりました。

知は力なりとは言ったものですね。