5月に作成を開始したGithubリポジトリのコードの各種連携について完成。
おおよその動きをマーメイド図で示します。
【活動履歴】原文時系列
2025/5/30
・時刻差分のアルゴリズム
・・ js
・・・入力エラー処理
・・・・hh
ss分割後の入力桁数確認を数字限定にした
・・・・キャンセル後に数秒待機してもらう処理を追加
・・・・Promissで値を返すならasync functionでなくても動作する
・・・関連理解
・・・・アロー関数形式
・・・・厳密等価演算子
・・・・ブロッキング関数
・・・・非同期関数を呼び出す関数は非同期関数
・・・pyodide
・・・・スプレッド構文
・・・・クエリが存在しない場合にcode改行なしで返答
・・py
・・・測定関数
・・・・可変長位置引数
2025/5/31
・時刻差分のアルゴリズム
・・yml
・・・CI/CDとはソフトウェア開発の工程を自動化・効率化する仕組み
・・・jqは、JSONデータを扱うための軽量で強力なコマンド
ラインツール
・・・if文の使い方
・・・・-fはパスにあるのが通常のファイルかどうかを判定
・・・・-zはzero length の略
・・・git logの活用
・・・・1コミットで複数ファイルの変更が発生した場合、それらすべてのファイル名を拾うことを避けるために、head -n 1 が必要であるとの認識であったが、単純に使ったのでは最終更新ファイルを拾えない。複数ファイル更新がないとの前提で進めていくのが無難か。しかし、失敗lsでもgitでも複数行を返す模様
・・・・Gitのdiffアルゴリズムは効率重視でツリーを比較し、変更されたファイルを「ツリー走査の結果」や「git内部の差分生成順序」に従って並べるため、出力順は一意に定まっているが、アルファベット順などの人間にわかりやすい順ではない
・・ js
・・・入力エラー処理
・・・・ダイアログをブラウザ依存なしに
・・・・キャッチエラーの関数呼び出し元の変数名を変更して関数名との混合を回避
・・・関連理解
・・・・ショートサーキット評価
・・py
・・・アンパック構文がjsでいうスプレッド構文か
・・・正規表現の\n?で改行の有無に関わらずという意味
2025/6/2
・全般
・・対象pyファイルから直接pyodideリポジトリを読み込む処理を分岐で追加した場合、既存のmain.jsが複雑化するため、追加読込pyファイルの処理のみinject-result.pyに追加し、別途output.pyをpyodideリポ内に追加で対応することにした。以後pyodideは測定と実行と入出力の基幹リポジトリの位置付けとなる
・yml
・・ファイルをまたぐ処理はyml、単純にファイルを読み込んで処理するだけならpyだけで事足りる
2025/6/3
・py
・・try内部の記述には失敗の可能性のある処理［ファイル操作，関数実行］を含めるようにし、それ以外は外にだした方が可読性があがる
・・md出力用のpyファイルはすべてzenn-contentリポジトリに以降しファイルの読み込みに対応させた
・・md反映の設定を完了
4
・github
・・MIT LISENCEの導入
・・再利用テンプレートをGithub Actionsの呼び出しymlとするとの理解
・スクラップ反映
・・リポジトリからgistへの自動反映
・・・シークレット登録
5
・yml
・・変数をダブルクォートで囲むのは、どんな文字列が入っていてもコマンドが壊れないようにする保険
・・ ls や find の落とし穴
ファイルの最終更新時刻（mtime）はGitのコミット時刻じゃなくチェックアウトした時点でのファイルのOS（Linux 仮想マシン）上の時刻になりがち。つまり、どのファイルが最後にコミットされたか」ではなく、このワークフローで最後にファイルシステム上で見つかった日時でしかない。しかも、GitHub Actionsのランナー上ではチェックアウトしたときにタイムスタンプが上書きされることもあり、本当の変更順を保証できない。
・ ・ addもcommitも中身を見ているので、commitであれば変更ないならエラーになってしまう。リポジトリ外を参照してコミットメッセージを出すなら、別途ログファイルを特定のディレクトリに置いてアクション動作の都度修正する処理が必要になる。
・・GitHub Actions では削除だけを検知しない push 条件は直接は指定できない。
・py
・・*argsは引数なしでも動作可能
・・.split(":")は入力の正しさを保証できず、空文字に対しても動作しエラーしないので便利だが、反面で直後の構文チェックを厳密に作る必要がある
・・時刻差分の入力が正しい形式かどうかだけ見るならstrptimeでも対応可能
・・終了コードが外部処理に使われるときだけ sys.exit() が必要
・・if name == "main": は 関数ではなく、Pythonスクリプトが直接実行されたときだけ実行される［条件付きの処理ブロック］
・・・returnは関数内でのみ付けられる
・・JSONは文字列をダブルクォートで囲う仕様だから、JSONを変数として渡すなら、エスケープするかダブルクォート閉じて再びシングルクォート開始する形とする
・・EOFErrorはinput()で入力待ち中にCtrl+D（Linux/macOS）やCtrl+Z（Windows）で入力が終わった場合に発生
6
★githubからgistへのコード連携完了によりスクラップ自動反映対応済み
・スクラップ本文の編集であれば直接githunと連携できそうだが、そうするとスクラップのコメントによる分割構造を活用できないため、gist連携構造が最善と判断。コメントを直接連携してgithubから編集は難しい模様。
7
arrowとpendulumはpaizaでは用意されておらず
8
・numpy, pytzは入力異なるため、時刻差分のアルゴリズムの測定対象から除外する
・tracemallocをつかう場合、ガベージコレクションが作動することを前提とする
・psutillではシステム負荷を見ることはできるが、精度は悪いので全体の大まかなメモリ使用量限度を見るのに向いている
9
◆実用性
・メモリ許容と関数群選定および実用用途についての記事を別途作成し以下と紐付け
・・アルゴリズムとは？
・・時刻差分のアルゴリズム
◆時刻差分
・比較
・・md反映
13
・サーチコンソール
22
・ga4の内部トラフィック削除については中断、アドオンを使えば簡単ではある
月ごとの活動ログを兼ねた技術メモです。時刻差分アルゴリズムを中心に、JS / Python / pyodide / GitHub Actions などを活用しながら、実用的な構成へと整理・分岐しました。
🔸2025/5/30｜JS・Python による基本処理の整備
JavaScript
-
hh:mm:ss分割後の桁数チェックを数値限定に - キャンセル時、数秒待機を入れるUX調整
-
Promise返却ではasync不要なケースありと確認 - ブラウザ依存しない入力ダイアログに変更
- 関数名と変数名の混同を避けるリファクタ
Python
- 測定関数を作成（
*args使用） - アロー関数・非同期関数の呼び出し側の非同期性確認
- 厳密等価演算子やブロッキング挙動の整理
pyodide
- スプレッド構文の動作検証
- クエリがない場合に
codeを改行なしで返す調整
🔸2025/5/31｜YML・Git操作と比較ロジック強化
YML・Git
- CI/CD の定義・自動化理解
-
jqによるJSON加工、if文の-f/-z処理確認 -
git logとhead -n 1の取り扱い、diff順序の非直感性に対応
JavaScript
- エラー時のcatch処理、関数名変更で混乱回避
- ショートサーキット評価の動作確認
Python
- アンパック構文とJSのスプレッドの類似
-
\n?正規表現による改行有無対応
🔸2025/6/2｜Pyodide基盤の整理とファイル構造の分岐
-
main.js複雑化を避け、測定処理をinject-result.py側に移動 -
output.pyを新設し、測定・入出力専用に - pyodideリポジトリをアルゴリズム処理の基幹に再定義
🔸2025/6/3｜md出力とPython設計の最適化
Python
-
try内に失敗可能性ある処理だけを集約して可読性向上 -
.md出力はZenn用にzenn-contentリポジトリへ移管 -
if __name__ == "__main__":で直接実行のみ処理 - JSONのクォート仕様と
sys.exit()の使用目的を明確化 -
EOFErrorはinput()中断時に発生する挙動と確認
🔸2025/6/4｜GitHub側の整備とスクラップ連携
- MIT LICENSEを追加
- GitHub Actionsテンプレの再利用方法を整理
- スクラップ→Gistへの自動反映対応（シークレット設定含む）
🔸2025/6/5｜YML処理・Gitの時間管理の落とし穴
-
ls/findのmtimeはコミット順ではなく、チェックアウト時刻に依存 - GitHub Actionsのpush検知では削除単独は検出不可
-
add/commitの内部挙動と整合しないとエラーになるケースあり
🔸2025/6/6〜｜GitHub→Gist連携完了と今後の方針整理
- スクラップ本文はGitHub直編集ではなく、コメント構造維持のためGist経由が最適
- 以後はGistを自動反映の母体とする運用に移行
🔸2025/6/7〜｜測定対象の精査と精度評価
-
arrow/pendulum：paiza未対応のため対象外 -
numpy/pytz：形式が異なるため除外 -
tracemalloc：GC起動前提での計測を要確認 -
psutil：おおまかなメモリ上限確認向け
🔸2025/6/9｜実用性評価と記事連携準備
- 「時刻差分のアルゴリズム」＋「アルゴリズムとは？」の比較記事へリンク
- 実メモリ制約・関数選定・用途に応じた分類を別記事でまとめ中
🔸その他
- サーチコンソール：観測継続中
- GA4の内部トラフィック削除は中断中（アドオン利用の余地あり）
✅まとめ
技術選定・入力設計・測定処理・比較出力・GitHub自動連携などを経て、「アルゴリズム実装から公開までの技術的ルート」を見える化できた一ヶ月でした。
次月は、Zenn投稿との連携をさらに強化し、可視化・検証性の高い構成へと進める予定です。