Visual Studio Code - .drawio.svg や .drawio.png の衝撃

はじめに

先日、 Visual Studio Code の Extension に Draw.io Integration という、VSCode で draw.io を使用出来る拡張機能がリリースされ話題になりました。

リリースされるや否や、界隈では盛り上がりを見せまして、Qiita の記事や #InfraStudy でも導入方法や事例が紹介されたりしました。

そんな訳で、モデリングなどの設計作業をするときはこの方法で作図するのがデフォルトになってきたのですが、先日更に（個人的に）驚愕の機能を知ったのでご紹介します。

draw.io について

draw.io は無料の作図ツールで、Webブラウザやデスクトップアプリから利用できます。また、Confluence などでは拡張機能として draw.io の機能を用いて作図を行うことが出来ます。作成した図形は SVG や PNG 、JPEG などの形式でエクスポートすることができ、また、 Google Drive など様々なストレージにファイルを保存することが出来ます。

f:id:anfangd:20200708215724p:plain — draw.io default view

draw.io は以前からローカルストレージでファイル保存をすることが出来ましたが、編集作業を行うには前述の Webブラウザやデスクトップアプリが必要で、ちょっとした手間がありました。また、Webブラウザを使用して編集する特性上、（個人的に）クラウドストレージにデータ保存することがデフォルトになっており、 git の管理に含めることは全くありませんでした。

しかし、VSCode の拡張機能として draw.io が使用できるようになったことで、VSCode でコーディングやドキュメンテーションをしながら、併せて作図までも行えるようになり、同時にそれらと同じ git レポジトリ配下で管理するということも容易になりました。これは本当に便利です。

f:id:anfangd:20200708220024p:plain — VSCode + draw.io view

また、最近、モデルベース要件定義テクニックという書籍で RDRA を使ったモデリングについて学ぶ機会があり、そこで Enterprise Architect や astah* などの専用モデリングツールを知ったのですが、普段使いしているツールで代替できないか調べていたところでした。これらのツールは、モデリングした図形をリポジトリとして管理出来ることも強みの一つだと思うのですが、なんと VSCode + draw.io の組み合わせでそれが代替利用できそうです。

VSCode で draw.io を使う

使用方法はとても簡単です。 VSCode 拡張機能として Draw.io Integration インストールし、 .drawio、.dio、.drawio.svg や .drawio.png といった拡張子のファイルを新規作成・開くだけです。

Web版とは一部機能の違いがあり、記事作成時点（2020/07/08）では画像のエクスポートが出来なかったりしますが、使い勝手は十分です。

.drawio.svg と .drawio.png

さてさて、上記で記載したとおり、VSCode で draw.io が使用できる拡張子には複数種類があります。

.drawio
.dio
.drawio.svg
.drawio.png

VSCode で draw.io が使えるだけで驚いていたのですが、下2つの拡張子の動作に驚きました。なんと、 VSCode + draw.io でファイル作成・編集・保存すると、それぞれ、 SVG や PNG のファイルとして保存されるのです。

f:id:anfangd:20200708220950p:plain — using .svg & .png

これで、 VSCode の拡張機能版に画像の Export 機能がなくなった理由が分かった気がしました。

draw.io 単体で Webブラウザで作図する場合、1つのシートに複数の意味の図形を作図したり、シート分割したりしてました。しかし、 VSCode 版では 1つのファイルの1つ意味をもつ図形を作成し、そうすることでそれを画像として使用できるようになるのです。

なるほど、こういう使い方か。

確かに、1つのファイルに情報を詰め込みすぎてもっさりすることがよくあったので、この方が効率的かもしれません。

Markdown ファイルからの参照

上記で記載した「VSCode 上は draw.io で編集しながら、保存したファイルは SVG や PNG になる」ということは、その保存したファイルを画像参照として Markdown ファイルなどから指定してあげれば、そのまま画像として表示できることを意味します。

これ、凄くないですか？

draw.io で作図した図形を Export することなく、そのまま参照させることが出来るのです。

RDRA に習ってモデリングのリポジトリを作成し、Markdown で解説ドキュメントを作る
仕様書や設計メモを draw.io で作図した画像とともに Markdown で管理する

などなど、活用のアイデアは色々と浮かんできます。

f:id:anfangd:20200708220325p:plain — Markdown view with drawio.svg

Live Sharing

上記の情報だけでも驚きづくしでしたが、もう一つ素晴らしい機能の組み合わせを知りました。

Draw.io real-time collaboration using Visual Studio Code and Live Share

なんと、 VSCode + draw.io + Live Sharing の組み合わせがいけるのです。

つまり、モデリング作業を複数メンバーがリアルタイムに１つのファイル編集する形で作業できるのです。

これは凄い。

draw.io の高機能性を活かしながら、複数メンバーが同時に同じ図形もモデリングできるなんて。

基本思想として考えられる、「 VSCode + draw.io で作図する図形はミニマム情報の単位でファイル作成する」ということを考えられると、そこまで複数のメンバーが同じファイルを同時に触るということはないかもしれません。

しかし、この機能を使用することで、ペアプログラミングならぬ、ペアデザイニングや、ブレーンストーミングしながら企画していく最中に簡単な図形をガリガリ書いていくなんていう作業には向いているかもしれません。

また、KPT振り返りなど、miro が得意とするような機能の一部も代替できるかもしれません。（ miro は大好きですが、料金がネックとなりがち。）

まとめ

システムやソフトウェアの設計の際には、モデリングしながら作図することは数多くあると思います。 5年以上前は、（あくまで個人的には）Excelのオブジェクトでシーケンス図や処理フロー図を作成するなんてことが普通でしたが、いまは有料無料の作図ツールが充実してきており、特に draw.io の使い勝手の良さや拡張性の高さには驚くばかりです。

組織やプロジェクトなど利用するシーンによって使えるツールも異なると思いますが、 draw.io ( + VSCode ) の組み合わせは、コスト感でも使い勝手でも、一番良い部類に入るのではないでしょうか。

おわり。

2020-05-10

Python - AmazonLinux2 に Python3.8 と Poetry をインストールした Dockerイメージを作成する

Tech Python Docker Poetry AmazonLinux2 ローカル開発環境

概要

Python で Webアプリケーションを作りたくなった為、 Docker を使用してローカル開発環境を構築するための Dockerfile を作成した。この Dockerfile によって、以下の構成のイメージ・コンテナを作成することができた。

Item	Content
OS	amazonlinux:2
Python	3.8.2
Pip	pip3.8
Poetry	1.0.5
OpenSSH	OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
Git	2.23.3

はじめに

とある方面から Python 関連の技術的な質問を頂くことになりそうになったが、 Python についてはほとんど触ってこなかったため、最低限の実行環境を整備しておくくらいはしておこうと思い調査した。

方法

Qiita や Stack Overflow を中心とした技術系ブログを参考に、Dockerfile 及び関連操作について調査し、まとめた。

結果

作成したコードの clone

次のコマンドでコードを GitHub から clone する。

git clone https://github.com/anfangd/dockerfile-AmazonLinux2-python3.8-poetry.git

# Folder Structure
tree
.
├── Dockerfile
└── authorized_keys

なお、 Docker のインストールは事前に済んでいることを前提とする。

事前準備

起動したコンテナ内に SSH 接続をしたため、事前に以下のような手順で秘密鍵と公開鍵を作成しておく。

# Create keys
ssh-keygen -t rsa -b 4096 -C "hoge@example.com" -f ~/.ssh/id_rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.

ls ~/.ssh
id_rsa  id_rsa.pub

# Dockerfile と同階層に公開鍵を配置する。
cp ~/.ssh/id_rsa.pub <PROJECT_ROOT>/authorized_keys

Build

次のコマンドで、 Docker の新しいイメージをビルドする。

# Build
docker build -t "amazon-linux2/python" .

Start Container

次のコマンドで、新しく作成したイメージを起動する。

# Start Container
docker run --privileged --rm -d -p 10000:22 --name amazonlinux2-sshd-container amazon-linux2/python /sbin/init

SSH Access to Container

次のコマンドで、起動したコンテナに SSH アクセスする。

# SSH Access
ssh ec2-user@localhost -p 10000 -i ~/.ssh/private_key

Stop Container

作業が終わったら、次のコマンドでコンテナを停止させる。

# Stop Container
docker stop amazonlinux2-sshd-container

Example: Poetry install Django | Flask

作成したコンテナ内では、 Poetry を使用することが出来る。

例えば、 Poetry を使用して Django をインストールする方法は次の通り。

# Example: Poetry install Django
mkdir django-demo && cd $_
poetry init --no-interaction --dependency django
poetry install
poetry run django-admin.py startproject django-demo

また、 Poetry を使用して Flask をインストールする方法は次の通り。

# Example: Poetry install Flask
mkdir flask-demo && cd $_
poetry init --no-interaction --dependency flask
poetry install

Dockerfile

なお、 anfangd/dockerfile-AmazonLinux2-python3.8-poetry で取得する Dockerfile の中身は次の通り。

FROM amazonlinux:2

# 各環境変数を設定
ENV USER ec2-user
ENV HOME /home/${USER}

RUN echo "now building..."

# Install General Tools
RUN yum update -y \
        && yum install -y git wget tar make \
            gcc openssl-devel bzip2-devel libffi-devel

# Install Python 3.8 && Poetry
RUN cd /opt \
        && wget https://www.python.org/ftp/python/3.8.2/Python-3.8.2.tgz \
        && tar xzf Python-3.8.2.tgz \
        && cd Python-3.8.2 \
        && ./configure --enable-optimizations \
        && make altinstall \
        && rm -f /opt/Python-3.8.2.tgz \
        && python3.8 --version \
        && pip3.8 --version

# 手元の公開鍵をコピー
COPY authorized_keys /tmp/id_rsa.pub

# Install SSH Server && Create and setting ec2-user.
RUN yum -y install \
        sudo \
        openssh-server \
        openssh-clients \
        which && \
    yum clean all && \
    systemctl enable sshd.service && \
    echo "PasswordAuthentication no" >> /etc/ssh/sshd_config && \
    useradd ${USER} && \
    echo "ec2-user ALL=NOPASSWD: ALL" >> /etc/sudoers && \
    sudo -u ${USER} mkdir -p ${HOME}/.ssh && \
    mv /tmp/id_rsa.pub ${HOME}/.ssh/ && \
    chmod -R go-rwx ${HOME}/.ssh && \
    cat ${HOME}/.ssh/id_rsa.pub >> ${HOME}/.ssh/authorized_keys

# USER ${USER}
WORKDIR ${HOME}
RUN sudo -u ${USER} curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python3.8 \
        && echo 'alias poetry="python3.8 $HOME/.poetry/bin/poetry"' >> /home/ec2-user/.bashrc

RUN echo "finished."

考察

2020年5月10日時点では、特に問題なく期待通りの環境を構築することができた。

結論

Docker の AmazonLinux2 イメージの上に、Python3.8 と Poetry をインストールし、 Web　Application Framework を使用したアプリケーション開発を実現することが出来る。

課題

Python の仮想環境の考え方をうまく理解できていない。
Python の依存管理ツールの考え方をうまく理解できていない。

参考文献

2020-04-13

Scrum - メンバー全員が完全リモートワークの新設チームで Scrum型のシステム開発するならこれが欲しい！

Tech Scrum Agile チーム開発システム開発ツール

はじめに

システム開発プロジェクトにおいて使用するツールの全体像について整理してみたかったので書いてみました。

はじめに
もくじ
要約
Scrum について
- Scrum の全体像
- Scrum を概念モデル図で表現してみる
Scrum Event
ツールの全体構成
- ツールの種類
- ツール群
Scrum を支えるプラクティス
コミュニケーション
その他の手段
- リッチに SaaS を使用する
- 可能な範囲で OSS を使う
参考
変更履歴

要約

現時点（2020年4月12日）において、Scrum型のプロジェクトを推進するにあたって、（個人的に）理想的なツール構成は下図の通りです。

f:id:anfangd:20200412214057j:plain — Tools for Team Development 1

なお、このツール構成のコンセプトは、以下の TIS さんの「チーム開発環境構築テンプレート」から多分に影響を受けています。

Fintan-contents/collaborage: チーム開発環境構築テンプレート

上記のツール構成の実現にあたっては、特に次のようなことを意識しています。

プロジェクト単位でチーム開発環境を構築する
可能な限りOSSを使用し、IaaS上に自前で構築することで、情報資産をコントロール出来る幅をもたせる

一方で、次のようなツールは、自前でホスティングできないものの、それ以上に生産性の向上に役立つと想定しています。

SaaS 型の Knowledge Base ツール　：　esa
SaaS 型の UML 作成ツール　：　draw.io
SaaS 型のホワイトボードツール　：　miro
SaaS 型のチケット管理ツール　：　Jira Software　※miroとの連携が魅力

なお、各ツールの採用にあたり、SSOや、OAuthのような機構を実現しなければ、アカウント管理が非常に煩雑になります。今回の想定では、理想形として、プロジェクト単位で G Suite の契約をするなどすることが一番効率的であると判断しています。

Scrum について

ツール個別の話題の前に、Scrum について整理します。なお Scrum の概要については、2020年2月に IPA 情報処理推進機構から公開された『アジャイル領域へのスキル変革の指針 - アジャイル開発の進め方』で非常によくまとまっているのでオススメです。

Scrum の全体像

Scrum の基本的な開発の流れは下図のように表現されます。

f:id:anfangd:20200412142111p:plain — Scrum_overview_by_ryuzee

Scrum を概念モデル図で表現してみる

Scrum を構成する要素を概念モデル図で表現すると下図のようになります。

f:id:anfangd:20200413085311j:plain — Figure: Scrum Conceptual Model Diagram

Scrum Event

Scrum で実行されるイベントのイメージについてまとめます。

Sprint Planning

Sprint の開始時に、 Product Backlog から今回の Sprint で扱う Sprint Backlog を選出します。プロダクトオーナによって順位付けされた Backlog Item は、開発チームによって詳細化され、タスク分割されます。通常、タスクは 2〜8時間単位で見積もられ、１つのタスクは１人に割り当てられます。

f:id:anfangd:20200412222500j:plain — Figure: Sprint Planning

f:id:anfangd:20200412230743p:plain — Figure: Product Backlog, Sprint Backlog, Task

Sprint

Sprint 期間中は次のプロセスを通して作業を進めます。

チームで協働して、【要求〜設計〜テスト】を繰り返す
TDD（テスト駆動開発）で実装する。

Daily Scrum

毎日、決まった時間に決まった場所で、１５分以内で、開発チームが全員の情報を共有します。メンバーは一人ずつ、以下の３つの要素を決まった順に共有します。

昨日やったこと
今日やること
障害になっていること

f:id:anfangd:20200412222902p:plain — Jira Software board

出典：What is a Jira Software board? | Jira Software Cloud | Atlassian Support https://support.atlassian.com/jira-software-cloud/docs/what-is-a-jira-software-board/

Sprint Review

Sprint Review では次のようなことを行います。

sprint で実装した機能をデモする
product backlog について協議する

Sprint Retrospective

Sprint Resrospective では、KPT法を使用した「ふりかえり」を通して、チーム学習やチーム改善の活動を行います。

f:id:anfangd:20200412180137p:plain — KPT

ツールの全体構成

本章から、改めてツールについて見てゆきましょう。「要約」で掲載した図を以下に再掲します。

ツールの種類

上図のツールを構成するそれそれの機能要素についてまとめます。

Type	Description
Knowlede Base	効率的に情報を共有するためのプラットフォーム。Wikiなどがこれにあたる。Officeツールで作成した文書は、色々と制約や使いづらさがあるため、Webブラウザのみで利用できるようなツールを採用することで、利用しやすくなる。
UML	ビジネスやシステムを分析する際に作図するツール。
Office Tool	「文書作成（Word）」、「表計算（Excel）」、「プレゼンテーション（PowerPoint）」などのツール。
File Storage	情報資産を格納し、関係者間で共有する仕組み。（共有フォルダ、Google Drive、OneDrive）
Account Management	アカウント管理を実現するツール。OAuthなどの仕組みを実現し、中心となるサービスアカウントにて管理出来るようにすることが望ましい。
Code Analyze	コードの静的/動的な解析を自動化し、かつ、見やすく表現するツール。
Version Control System	コードや文書の版管理を実現するツール。「共有フォルダ」を使用する場合、PDFやOfficeツールで作成した文書も git のような VCS の管理ツールの対象となるが、 Google Drive などのように、自前で版管理が可能なサービスを使用することで、作業効率の向上に繋がる。
Code Review	VCS と連携し、コード差分や Issue の発行、コード管理フローを支援するツール。
Chat	コミュニケーションのハブとなるツール。リモート開発の場合は、すべてのコミュニケーションが Chat ツールを中心に実行されるようになると、情報の伝達漏れや、記録漏れの防止に繋がる。
Video Chat	オンライン会議を始め、雑多なコミュニケーションに活用する。利用者の物理デバイスが持つマイクやカメラ、ネットワーク環境に依存する部分があるため、ハードウェアの部分から意識して環境を整える必要がある。
ホワイトボード	チームが物理的に近い場所にいる場合は、実際のホワイトボードの活用が好ましいが、遠隔にいるメンバーとコミュニケーションする場合には、情報の伝達漏れや、やり取りの障害になることがあるため、オンラインで利用できるツールの利用が好ましい。
Package Repository Manager	Dockerコンテナや、Mavenのリポジトリなど、チーム内や組織内でのみ共有したいパッケージを管理するプラットフォーム。
CI	継続的インテグレーションを実現するツール。システム開発の分野では比較的、一般的なため詳細は割愛。
Ticket Management	チケット管理を実現するツール。システム開発の分野では比較的、一般的なため詳細は割愛。

ツール群

採用する想定の各ツールについて下表にまとめます。

Tool	Description	Memo
esa	Webブラウザから利用できる「情報共有サービス」	DocBase も良さそう。
PlantUML	PlantUML の記法に従ってコードを記載することで、UMLを作成できる。 esa や GitLab などと連携できる。	GitLab 連携には、サーバホスティング型の PlantUMLサーバ必要。Dockerで簡単に構築出来る。
draw.io	PlantUML はシステムに近い部分のUML作成には向くが、ビジネスに近い部分の作図には向かない。 draw.io は Web ブラウザから利用できる作図ツールであり、様々なサービスのアイコンをすぐに利用できるため、無料ながら非常に強力な作図ツールである。Jira や Confluence と連携する機能を有する（らしい。）
G Suite	言わずもがな。次のような用途で使用できる。 - アカウント管理 - ファイルストレージ - Officeツール - Video Chat	機能で使用する場合、組織共通で使用しているツールと競合するため、導入は容易ではない場合が多々ありそう。
sonarqube	コード解析ツール。セットアップと連携に一手間掛かるが、非常に有用なコード解析ツール。	だんだん、Web上でも認知度が上がってきたように思う。
GitLab	Git Hosting サービスの１つ。OSSのため自前サーバに構築できる。有料版もあるが、無料版でもかなりリッチな機能を有する。コードレビュや Merge Requestを始め、コード管理のための十分な機能を有する。	GitHub が使えるならそちらでも良い。
Rocket.Chat	Chatツール。 GitLabと同様に、OSSのため、自前のサーバに構築出来る。
miro	ホワイトボードツール。以前は Realtime Board という名前だった。非常に強力なコラボレーション機能を有しており、複数人でリアルタム編集が出来るため、本物のホワイトボードより使いやすい部分も多くある。	この領域はこれ１択かもしれない。
Jira Software	Atlasian のチケット管理ツール。アジャイル向け機能など、ビジネスユースとして十分な機能を有する。 miro との連携機能が魅力。	色々使うと結構高い。
Sonotype Nexus	Package Repository Manager	この領域にあまり詳しくないが、OSSの割に非常にリッチな機能を有しており使いやすいらしい。
Jenkins	CIツール。	余裕があれば CircleCI などでも良い。