懸垂マップ サイト/アプリ のワークフロー
このメモについて
- このメモは、図解の試行錯誤の一環で、自分用メモ
背景1. テーマ
- 懸垂マップ サイトのメンテを、もうちょい楽にしたい
- ツール化できるところはツール化する
- なんか無駄なフローが入ってないか?をチェック
背景2. 図解について
- 少し前に DFD の本を読んだので活用してみよう
- 📘 データフローダイアグラム
- 社会人なりたてのころに研修で触れたぐらいの記憶しかないので、活用したことがない
- 描画ツールは使いこなせてないので、Excel にしよう
- 上下に線を引いたボックスは、グループ化したものを作っておけば楽に使い回せた
- 元ファイルはアプリの _resources フォルダに置いておいた
バージョン1. データと、ありかを意識して記載

- 自分的には どこに/どの形式で/どのデータを配置、というのがスッキリした気はする
- DFD 風に書いたものの、たぶん使い方が違う
- 改めて見ると、当初の「マイマップを embed して載せただけ」のサイトと比べると、だいぶ拡張してる感じになってるな・・
バージョン2. DFD 風(?)に書く

- より DFD 風に書くと、こうなるだろうか
- 「マイマップに登録したものが元データで、サイトとアプリは、それを加工したもの」というのが分かりやすい感じがする
- 「実はデータベースは無くて、ただの静的サイトなんです」と説明するときに使えそう(誰に説明する機会も無いんだけど)
バージョン3. 登録までの作業を書き込み、手動のもの/ツール化済のものを色分け

- やりたかったのはこれなので、「バージョン1」の粒度を元にするのが適切
- 前半部分(フォーム等からの投稿とマイマップの編集作業)に手動の作業が集中し、後半部分はツール化できているのが分かる
- このような図にしとくと、どこを直せば良いか分かりやすくなる気がする
その他メモ:余談
- この図にする前の変更として、③部分の画像 upload 部分は手動作業を減らしたり効率化している
- upload だけ別ツールから手動アップにしていたが、aws cli (aws s3 sync) でのアップに変更
- NFC 正規化問題(Macでファイル名の「パ」等の表現方法が2種類ある件)の整理
- サムネイルは毎回、全ファイル消して作り直して、⑦のWeb配下に置いて全uploadしていた
- サムネイル作成は aws lambda でやるのも良さそうな気もしたが、いったんこのまま ˛- 自分しか更新しないので、都度更新のほうがタイミングが把握しやすい
- 問い合わせフォームも同様に lambda が活用できそうだが、この辺、自前で作るとスパムなどがこわいので、いったんこのまま
- これはうまく活用するとアプリからの「新しい鉄棒を見つけました」投稿機能ができそうだが、誰から来たか分からなくなりそう、という理由でも足踏み
以下広告