Skip to main content

懸垂マップ サイト/アプリ のワークフロー

このメモについて
  • このメモは、図解の試行錯誤の一環で、自分用メモ

背景1. テーマ

  • 懸垂マップ サイトのメンテを、もうちょい楽にしたい
  • ツール化できるところはツール化する
  • なんか無駄なフローが入ってないか?をチェック

背景2. 図解について

  • 少し前に DFD の本を読んだので活用してみよう
  • 描画ツールは使いこなせてないので、Excel にしよう
    • 上下に線を引いたボックスは、グループ化したものを作っておけば楽に使い回せた
  • 元ファイルはアプリの _resources フォルダに置いておいた

バージョン1. データと、ありかを意識して記載

PullUpPark workflow

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

バージョン2. DFD 風(?)に書く

PullUpPark workflow

  • より DFD 風に書くと、こうなるだろうか
  • 「マイマップに登録したものが元データで、サイトとアプリは、それを加工したもの」というのが分かりやすい感じがする
    • 「実はデータベースは無くて、ただの静的サイトなんです」と説明するときに使えそう(誰に説明する機会も無いんだけど)

バージョン3. 登録までの作業を書き込み、手動のもの/ツール化済のものを色分け

PullUpPark workflow

  • やりたかったのはこれなので、「バージョン1」の粒度を元にするのが適切
  • 前半部分(フォーム等からの投稿とマイマップの編集作業)に手動の作業が集中し、後半部分はツール化できているのが分かる
  • このような図にしとくと、どこを直せば良いか分かりやすくなる気がする

その他メモ:余談

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

以下広告