やってみる

アウトプットすべく己を導くためのブログ。その試行錯誤すらたれ流す。

GitHubアップローダのインタフェース多様化計画

自動化促進やミス予防のために。

前回

インタフェース

  1. GUI
  2. CUI(入力確認)
  3. CUI(コマンド)
  4. 定期実行

インタフェースと対応する機能

A. GUI

  • ReadMe表示確認
  • Issue作成

MarkdownのHTML変換とその表示確認がキモ。ローカルWebサーバを立ててAJAXを使ったGUIアプリが良いか。

B. CUI(入力確認)

issue登録はGUIまたはCUI(コマンド)にまかせる。CUI(入力確認)では表示確認できない上に複数行入力できないため対応が難しい。または無駄が多い入出力を強いられる。

C. CUI(コマンド)

  • ユーザ登録
  • OTP算出
  • リポジトリ作成&add,commit,push
  • リポジトリ編集
  • リポジトリ削除
  • Issue作成
    • issue番号を返す
      • DBに登録して参照できるようにする
  • コントリビューション取得
  • コントリビューションSVG書き出し

確認とその操作を排除する。リポジトリ作成とadd,commit,pushはコマンドを別々にするか迷った。しかし同一コマンドとする。いちいちコマンドを使い分けるのが面倒だから。リポジトリ編集と削除は操作ミスをなくすために別コマンドにする。

D. 定期実行

予約投稿したい。

  • いつ以降に
  • 何をする

PC起動時または定時に、現在日時が指定した日時以降になった場合、指定したアクションを行う。

  • リポジトリ作成&add,commit,push
  • Issue作成
  • コントリビューション取得
  • コントリビューションSVG書き出し

懸念

もしGitHubアップローダ以外で変更したら、ローカルDBとサーバとで整合性がとれなくなる。

たとえばGitHubサイトから更新したときなど。その場合、サーバから取得してローカルを更新せねばならない。しかし、どのアカウントの、どのリポジトリの、何の情報を更新すればいいかわからない。毎回APIを叩きまくるとサーバ負荷も上限も超える。できるだけアップローダだけで更新するのが良い。しかし、アップローダでできる操作は限られている。すべての操作を実装することは目的を超えてしまうし現実的でない。

どこまでを対象範囲とするか考えながらやっていくしかない。

所感

まずはコマンドの抜き出しから。