Above & Beyond

日々のアウトプット記録

PlantUMLで色々描く

今の会社ではドキュメントを書いたりするのにDocbaseを使っています。

DocbaseMarkdownでドキュメントを描くのですが、図を描いたりするのにPlantUMLやdraw.io等の記法が使えます。 様々な可視化に便利なので、これを活用して日々図を描いています。 今回は、どんなものを描いているのか、実例を紹介します。(そのものを公開はできないので、一部改変してますが)

PlantUMLとは

今回紹介するのは PlantUML です。UML以外にも多彩な図を描くことができるツールです。 作成されたシーケンス図などを目にする機会は結構多いのではないかと思います。

尚、今回紹介する使い方は、ガチのUMLとしてではなく可視化のツールとして使っているので、それはUMLとしてどうよ、、、みたいなツッコミは受け付けていません。 あくまで、可視化する時の参考、として見てもらえればと思います。

ちなみに、はてなブログではPlauntUML記法には対応していないので以下の例は試せないですが、VS CodeMarkdown Preview Enhanced 拡張を使えば確認できます。

UMLダイヤグラム

シーケンス図

処理の流れを表すのに使っています。 ソースコードの処理の流れなんかを描くことが多いですが、こんなふうにワークフローを描いたりもします。

記事作成から公開までのワークフローEditorEditorHerokuHerokuPostgreSQLPostgreSQLAuthorizerAuthorizerAWS S3AWS S3記事作成プレスリリースメディア実績お知らせ1[新規作成] ボタンクリック2記事保存3[承認申請] ボタンクリック4承認申請通知記事承認5[修正依頼] ボタンクリック6修正依頼7[承認申請] ボタンクリック8[承認] ボタンクリック(Heroku上で公開)9Heroku上で確認記事公開10[S3に公開] ボタンクリック11サイトにデプロイして公開12サイト上で確認<!--MD5=[db1e59732e2da4e98b82c66b080bfbec]

ソースはこんな感じです。

@startuml
title 記事作成から公開までのワークフロー\n

actor Editor
control Heroku
database PostgreSQL
actor Authorizer
control "AWS S3"
autonumber

group 記事作成\n* プレスリリース\n* メディア実績\n* お知らせ
  Editor -> Heroku: [新規作成] ボタンクリック
  Heroku --> PostgreSQL: 記事保存
  Editor -> Heroku: [承認申請] ボタンクリック
  Heroku --> Authorizer: 承認申請通知
end
...

group 記事承認
  Authorizer -> Heroku: [修正依頼] ボタンクリック
  Heroku --> Editor: 修正依頼
  Editor -> Heroku: [承認申請] ボタンクリック
  Authorizer -> Heroku: [承認] ボタンクリック(Heroku上で公開)
  Editor -> Heroku: Heroku上で確認
end
...

group 記事公開
  Authorizer -> Heroku: [S3に公開] ボタンクリック
  Heroku -->  "AWS S3": サイトにデプロイして公開
  Editor -> "AWS S3": サイト上で確認
end
@enduml

コンポーネント

コンポーネント間の関係を示したい時に使っています。 この例は上記のシーケンスをどういうコンポーネントで実現しているかを説明する為に描いたものです。

記事作成から公開までDeveloperGitHubHerokuS3Cloudfrontmasterにpushbuilddeploy静的ページに変換表示確認静的website公開表示確認<!--MD5=[6d52720e477742f8cf582dea084fccfe]

ソースはこんな感じです。

@startuml
title 記事作成から公開まで\n

actor Developer
component GitHub
component Heroku #ccccff
component S3 #ffccaa
component Cloudfront #ffccaa

Developer -> GitHub: masterにpush
GitHub -> Heroku: build
Heroku -> S3: deploy\n 静的ページに変換
Developer - Heroku: 表示確認
S3 -- Cloudfront: 静的website公開
Cloudfront - Developer: 表示確認
@enduml

アクティビティ図

バッチ処理をドキュメント化する時の流れを描く時に使っています。

処理アクティビティ実績値算出処理予想値算出処理年月別サマリー算出処理<!--MD5=[6dcf966a9878e3e22e2e665494350f10]

ソースはこんな感じです。

@startuml
title 処理アクティビティ\n
start
:実績値算出処理;
:予想値算出処理;
:年月別サマリー算出処理;
end
@enduml

その他の図

ガントチャート

変わり種ですが、こんなものも描けます。

プロジェクト管理ツールなりExcelなりを使ったほうが良いじゃんというのはもっともなのですが、 そういうものを使わずにドキュメントだけでぱっと表現したいときもたまにある訳で。 進捗実績%も表現できるので、簡易的なものとしては十分使えるかなと思っています。

開発環境123456789101112131415161718192021222324252627282930311234567891011123月 20224月 20221. 事前検討 - 担当A2. 基本設計書作成 - 担当A3. 詳細設計書作成 - 担当A4. 実装 - 担当A5. テスト仕様書作成 - 担当A6. 単体テスト - 担当A7. 結合テスト - 担当A10. QA/課題管理作成 - 担当B11. 基本設計書内部レビュー - 担当B12. 詳細設計書内部レビュー - 担当B13. コードレビュー - 担当B14. テスト仕様書レビュー - 担当B123456789101112131415161718192021222324252627282930311234567891011123月 20224月 2022<!--MD5=[506574adbc85a15d77c4666507345afa]

ソースはこんな感じです。

@startuml
language ja
title 開発環境
Project starts 2022-03-01
[1. 事前検討 - 担当A] starts 2022-03-01 and ends 2022-03-02
[1. 事前検討 - 担当A] is 100% completed
[2. 基本設計書作成 - 担当A] starts 2022-03-03 and ends 2022-03-09
[2. 基本設計書作成 - 担当A] is 10% completed
[3. 詳細設計書作成 - 担当A] starts 2022-03-10 and ends 2022-03-16
[3. 詳細設計書作成 - 担当A] is 0% completed
[4. 実装 - 担当A] starts 2022-03-17 and ends 2022-03-25
[4. 実装 - 担当A] is 0% completed
[5. テスト仕様書作成 - 担当A] starts 2022-03-28 and ends 2022-03-29
[5. テスト仕様書作成 - 担当A] is 0% completed
[6. 単体テスト - 担当A] starts 2022-03-30 and ends 2022-04-05
[6. 単体テスト - 担当A] is 0% completed
[7. 結合テスト - 担当A] starts 2022-04-06 and ends 2022-04-12
[7. 結合テスト - 担当A] is 0% completed
[10. QA/課題管理作成 - 担当B] starts 2022-03-03 and ends 2022-03-07
[10. QA/課題管理作成 - 担当B] is 80% completed
[11. 基本設計書内部レビュー - 担当B] starts 2022-03-10 and ends 2022-03-11
[11. 基本設計書内部レビュー - 担当B] is 0% completed
[12. 詳細設計書内部レビュー - 担当B] starts 2022-03-17 and ends 2022-03-18
[12. 詳細設計書内部レビュー - 担当B] is 0% completed
[13. コードレビュー - 担当B] starts 2022-03-28 and ends 2022-03-29
[13. コードレビュー - 担当B] is 0% completed
[14. テスト仕様書レビュー - 担当B] starts 2022-03-30 and ends 2022-03-31
[14. テスト仕様書レビュー - 担当B] is 0% completed
@enduml

ファイル内容の可視化

PlantUMLではJSONとかYAMLの構造を可視化する機能があります。 ファイルを見ているだけだと分かりづらい設定値などの構成も簡単に可視化できるので、個人的に愛用しています。

JSON

JSONAPIの戻り値とかでよく使われますね。 以下はAzure CosmosDB(MongoDB互換ドキュメントデータベース)のあるコレクション構造を可視化した例です。

_ididcreatedAtupdatedAt__v0$date$date<!--MD5=[ecd7e35e1633f6cef5c71e28905590a1]

ソースはこんな感じです。

@startjson
{
    "_id" : "",
    "id" : "",
    "createdAt" : {
        "$date" : ""
    },
    "updatedAt" : {
        "$date" : ""
    },
    "__v" : 0
}
@endjson

YAML

YAMLKubernetesの各種設定等で使われますね。 以下はredisのConfigMapのYAMLを可視化したものです。

apiVersionv1datakindConfigMapmetadatamaster.confredis.confreplica.confcreationTimestamplabelsnamenamespaceresourceVersionselfLinkuidappchartheritagerelease<!--MD5=[216fca801aac4840cb1c2e75c4b64e29]

ソースはこんな感じです。

@startyaml
apiVersion: v1
data:
  master.conf: ""
  redis.conf: ""
  replica.conf: ""
kind: ConfigMap
metadata:
  creationTimestamp: ""
  labels:
    app: ""
    chart: ""
    heritage: ""
    release: ""
  name: ""
  namespace: ""
  resourceVersion: ""
  selfLink: ""
  uid: ""
@endyaml

まとめ

こうやって見てみると、PlantUMLって色々な図が描けて便利ですよね。 テキストで記述していくものなので、変更やバージョン管理も簡単です。 なんとなくいい感じに図を描きたいなと言う時に使ってみると、今より少しだけわかり易いドキュメントが書けるかもしれません。 自分の脳内整理や可視化に使ってみるのもいいと思います!

骨伝導ヘッドセットを買いました。

取り敢えず買ったもの

題名のとおりです。初めての骨伝導ヘッドセット。買ったのはこれです。

自分か購入した時は4000円引きでセールをしていて、なおかつポイントが6%付いたのでだいぶ安く入手できました。 何でこれを買うに至ったかは後述するとして、取り敢えず開封の儀とヘッドセットの写真から。

f:id:kabukawa:20220227215530j:plain

色は赤を選択。赤が一番かっこよく見えたので。 付属品はこんな感じです。

  • 充電用ケーブル2本。USB-A側を給電できるUSBポートに刺します。本体とはマグネットでカチッとくっつくタイプ。
  • 耳栓。これは自分は使わないかな。
  • ケーブルとか本体を収納するソフトケース。もうちょっとおしゃれでも良いような。
  • Bluetoothのペアリング方法と充電方法が書かれたカード
  • 保証書
  • ユーザーガイド(日本語ページあり)
  • おまけで持ち歩き用にウエストバッグが付いてましたが、これもおしゃれではないかな。。。

必要十分だし、Bluetoothのヘッドセットを使ったことがあればそれ程迷わずに使えるかなと思います。 ユーザーガイドに日本語ページがあるのも初めて使う人にとっては嬉しいポイントかも。

つけてみた時の耳の周り。老眼鏡のツルと当たりますが、それ程気にはならないです。

f:id:kabukawa:20220305001115j:plain

耳の穴が塞がれていないことが分かると思います。 音は耳の前にある部分から骨を震わせる事で音が聞こえるという仕組み。


使ってみて

あくまで個人の感想ですが、

  • 歳のせいか高音が聞き取りづらくなったのですが、これを使うとよく聴こえます。
  • 音量によっては音漏れはあります。でも、自分の使い方だと音量はそれ程上げてないので周りには聴こえないです。
  • 低音で肌がブルブルするのを感じるらしいです。自分は特にそういうのはありませんでした。
  • 想像以上に音は良かったです。低音が物足りないとか言い出すとキリがないですが、少なくともオンライン会議の音声はよく聴こえます。
  • 本体が軽いので、装着した感じは悪くなかったです。
  • 耳を塞がないので蒸れたりすることがなく、長時間着けたままでも嫌な感じはないです。
  • 2時間ぶっ続けの会議にもこれで参加してみましたが、快適に聞くことが出来て終わったあとの疲れ方も以前より改善されました。

という事で、自分としては大満足でした。 安い買い物ではないので誰にでもオススメとまでは行かないですが、長時間のオンライン会議で耳が蒸れたりすることにストレスを感じている人は、検討してみることをオススメしてもいいかなと思います。


何故買ったのか

リモートワークで会議といえばオンライン会議になりました。 リモートワークなので家から参加するわけですが、社内の雑談ならともかく、顧客との会議音声をスピーカーで流すのは周りの家に漏れてしまうので避けたい。 ということでヘッドフォン、若しくはヘッドセットで参加することになります。

これまではこのヘッドセットを使って参加していました。

ノイズキャンセリング性能の高い、とてもいいヘッドセットです。 ただ、周りの音が聞こえないと、リモートワークだと困ることが有ったりします。 例えば家族から声をかけられても気づかないとか、宅急便が来てもチャイムの音が聞こえずに不在扱いになったり。 そんな事があって、周りの音が聞こえつつ、会議の音声も聞こえるようなヘッドフォンがほしいなと思っていました。

という事でAmazonを徘徊していたら、骨伝導ヘッドセットというのが良さそうという事になったのですが、骨伝導ヘッドセットを使ったことがないので、ちょっと心配。 安いものは3千円台からあるものの、果たしてどれがいいのやら。 そういう時はTwitterで聞いてみようということで、こんな感じで呟いたら有り難いことに使っている方からコメントを頂きました。

上記のスレッドでみなさんが推薦しているのが AfterShokz(今はブランド名が変わって単に Shokz ) のヘッドセットだったので、取り敢えずブランドはこれに。 教えていただいた皆様、改めてありがとうございました!

あとはどの機種にするかで、自分の想定している使い方だと

  • 予算は2万円以内
  • 一日中つけっぱなしを考えていたので、バッテリーが8時間持つ
  • 汗っかきなので防水性能は高いほうが良い

ということで Aeropex になりました。 セールで値引きされていたのとポイントアップが重なったので15500円くらいで買えたことになります。 なかなか良い買い物でした。

S3バケットの設定を適度にダンプするAWS CLIをシェルにした

RSSリーダーの記事を消化していて、そういえばこういうのをやらなきゃいけなかったんだったと思い出したのでシェルにした。

dev.classmethod.jp

だいたいこんな感じ。 各バケットに対してサブコマンドをバンバン発行して、それをファイルに出力する。

出力は {日付(YYYYMMDD)}/{プロファイル名}/{バケット名}/ の下に サブコマンド毎に出力。

#!/bin/bash

#   呼び出したいS3apiサブコマンドを定義
### ---------------------------------------------------------------------------
FUNCS=$(cat << EOS
get-bucket-acl
get-bucket-encryption
get-bucket-lifecycle-configuration
get-bucket-location
get-bucket-logging
get-bucket-notification-configuration
get-bucket-ownership-controls
get-bucket-policy
get-bucket-policy-status
get-bucket-replication
get-bucket-request-payment
get-bucket-tagging
get-bucket-versioning
get-bucket-website
get-public-access-block
EOS
)

#   定数定義
### ---------------------------------------------------------------------------
# s3api コマンド
S3CMD="aws s3api --profile ${1}"

# メイン処理
### ---------------------------------------------------------------------------
# 引数チェック
if [ $# != 1 ]; then
  echo "Usage: ${0} [profilename]"
  exit 0
fi

# 最初にバケット一覧を取得
BUCKETS=`${S3CMD} list-buckets --query "Buckets[].Name" --output text`

# S3apiサブコマンドを各バケットに対して実行
for BUCKET in ${BUCKETS}; do
  # 処理日付取得(YYYYMMDD)
  OUTDIR=`date +"%Y%m%d"`/${1}/${BUCKET}

  # 出力ディレクトリ作成
  if [ ! -d ${OUTDIR} ] ; then
    mkdir -p ${OUTDIR}
  fi

  printf "[%60s] を処理中 " ${BUCKET}
  for FUNC in ${FUNCS}; do
    printf "."
    # 属性が未設定の場合はエラーになるが、ここでは無視
    ${S3CMD} ${FUNC} --bucket ${BUCKET} > ${OUTDIR}/${FUNC}.json 2> /dev/null
  done
  printf "\n"
done

設定をバックアップしておいて、何かあった時に確認する感じ。 何でこういうのが必要かといえば、こーどかIaaS化されずに構築された環境がありまして、という話です。