anfangd's blog

as a software engineer

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 の機能を用いて作図を行うことが出来ます。 作成した図形は SVGPNGJPEG などの形式でエクスポートすることができ、また、 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 Architectastah* などの専用モデリングツールを知ったのですが、普段使いしているツールで代替できないか調べていたところでした。 これらのツールは、モデリングした図形をリポジトリとして管理出来ることも強みの一つだと思うのですが、なんと 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 でファイル作成・編集・保存すると、それぞれ、 SVGPNG のファイルとして保存されるのです。

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

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

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

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

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

Markdown ファイルからの参照

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

これ、凄くないですか?

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

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

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 の組み合わせがいけるのです。

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

これは凄い。

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

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

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

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

まとめ

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

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

おわり。

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

概要

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 の依存管理ツールの考え方をうまく理解できていない。

参考文献

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

はじめに

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

もくじ

要約

現時点(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時間単位で見積もられ、1つのタスクは1人に割り当てられます。

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

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

Sprint

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

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

Daily Scrum

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

  1. 昨日やったこと
  2. 今日やること
  3. 障害になっていること

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

ツールの全体構成

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

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

ツールの種類

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

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 サービスの1つ。OSSのため自前サーバに構築できる。有料版もあるが、無料版でもかなりリッチな機能を有する。
コードレビュや Merge Requestを始め、コード管理のための十分な機能を有する。
GitHub が使えるなら そちらでも良い。
Rocket.Chat Chatツール。
GitLabと同様に、OSSのため、自前のサーバに構築出来る。
miro ホワイトボードツール。以前は Realtime Board という名前だった。
非常に強力なコラボレーション機能を有しており、複数人でリアルタム編集が出来るため、本物のホワイトボードより使いやすい部分も多くある。
この領域はこれ1択かもしれない。
Jira Software Atlasian のチケット管理ツール。アジャイル向け機能など、ビジネスユースとして十分な機能を有する。
miro との連携機能が魅力。
色々使うと結構高い。
Sonotype Nexus Package Repository Manager この領域にあまり詳しくないが、OSSの割に非常にリッチな機能を有しており使いやすいらしい。
Jenkins CIツール。 余裕があれば CircleCI などでも良い。

Scrum を支える プラクティス

以下の書籍で 『Scrum を支える プラクティス』として紹介されているものについて、採用予定のツールで作図したものを記載します。

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

インセプションデッキ

f:id:anfangd:20200412182142p:plain
Inception Deck ※miro で作成

スクラムで使う「インセプションデッキ」のmarkdown形式版テンプレート - Qiita https://qiita.com/bremen/items/ed491246ed83630bc84d

リーンキャンバス

f:id:anfangd:20200412175005p:plain
Lean Canvas ※miro で作成

ユーザストーリー

f:id:anfangd:20200412181000p:plain
User Story ※miro で作成

ユーザーストーリーマッピング

f:id:anfangd:20200412175246p:plain
User Story Mapping ※miro で作成

miro は Atlasian の Jira と連携することができ、 miro の User Story を Jira の ticket へ変換することが出来るらしい。

f:id:anfangd:20200412183821g:plain
miro jira

ラニングポーカー

プランニングポーカーは Webアプリケーションとして個人制作されたようなサイトはありましたが、これといったツールは見つかりませんでした。

スパイク

スパイクは「事前調査」という位置付けのため、これに関連するツールは記載しません。ただし、敢えて挙げるとすると、調査結果を共有する Knowledge Base 的なツールが活用できると思います。

タスクボード

Daily Scrum で掲載したものと同じですが、 Jira Software board を使用することによって実現できます。

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

バーンダウンチャート

f:id:anfangd:20200412184016p:plain
バーンダウンチャート

引用:スプリントの進捗状況を監視する - アトラシアン製品ドキュメント https://ja.confluence.atlassian.com/jirasoftwareserver/monitoring-the-progress-of-a-sprint-938845440.html

パーキングロット

パーキングロットについては、スプリントレビュ時のネタの退避場所という位置付けであり、スプリントレビュの実施方法に依存してツールが変わってくるかと思います。 miro や esa などを活用することで、効果的なパーキングロットを作成できるのではないかと思います。

KPT

f:id:anfangd:20200412180137p:plain
KPT ※miro で作成

技術的負債の返済

技術的負債の返済に取り組むためには色々なアプローチがあると思いますが、例えば次のようなツールを活用することによって、コードの見える化やコードレビュの効率化を実現することが可能です。

  • GitLab
  • SonarQube

継続的インテグレーション

継続的インテーグレーションの実行にあたっては、色々なツールが想定できますが、例えば次のようなツールを活用することによって実現できます。

  • Jenkins

コミュニケーション

『完全リモート』という前提に立つと、『チャットツール』と『ビデオ会議ツール』は欠かせません。両者は色々候補がありますが、例えば以下のようなツールがあります。

  • チャットツール
    • Rocket.Chat
  • ビデオ会議ツール

先日までは、ビデオ会議ツールとして「Zoom」が一番の候補でしたが、セキュリティ問題が顕在化したため、敢えて候補には入れません。

その他の手段

リッチに SaaS を使用する

自前でサーバ構築してツールを導入するのが面倒な場合、お金を掛けることが出来るならば以下のような構成が楽だと思います。

f:id:anfangd:20200412162350j:plain
Tools for Team Development 2

可能な範囲で OSS を使う

一方、可能な限り OSS かつ、制御可能な内部サーバで実現したい場合は、以下のようなツール構成が良いかと思います。なお、Knowlede Base や UML の部分で OSS や クライアントツールの候補もありますが、作業効率などの面でそのままにしてあります。

f:id:anfangd:20200412214151j:plain
Tools for Team Development 3

参考

今回の記事を作成するにあたり、以下の資料を参考にしました。

Scrum

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

チーム開発

情報システム

ツール

変更履歴

  • 2020年4月13日 午前0時34分 新規作成
  • 2020年4月13日 午前8時48分 Scrum の概念モデル図を更新 ※Relase の概念を追加