useful tools
新規作成 2021-5-17
あるとちょっと楽になるようなツールを作ってメモしていく。
anchocochro
「あんちょこ」× Chrome Extension の略
下準備の段階
https://github.com/ddddddO/anchocochro
目的
単語をさっと調べるため
React/TypeScript/Laravelでアプリを作りたいため
Chrome 拡張機能を利用した、単語・文章をメモするCRUDアプリ
曖昧に検索したい
データを永続化したい
その単語(文章)に対する参考リンクを複数持ちたい
その単語(文章)に対するdescriptionを複数持ちたい
構成
ローカル
ブラウザのChrome拡張とhttp通信するAPI(Laravel/SQLite)
ブラウザ
画面表示・ローカルのAPIと通信(React/TypeScript)
テーブル
words(親)
descriptions(子)
1word:多description
links(子)
1word:多link
morpheme
あとで追加
wordとdescriptionを形態素解析した結果を持とうかと
morpheme_wordsテーブル/morpheme_desriptionsテーブルを作ろうかと
Chrome 拡張機能のメモ
API
Reactでサクッとchromeの拡張機能をつくる
メモ
Laravelのキューも使いたい。作成更新の場合は、以下処理をジョブとして非同期実行する
単語(or 文章)とdescriptionを形態素解析 をする
DBへ登録する
ViteでReact + TypeScript + TailwindCSSの環境構築をする
calma
Calendar for Markdown の略
https://github.com/ddddddO/calma
Markdownのカレンダーを生成するGo製CLI
esaでカレンダーを出力したいと思い、誕生。
HTMLを出力するフラグを追加した。
gdag
generate DAG の略
https://github.com/ddddddO/gdag
タスク分割後にタスクの依存関係をdagとして生成するためのGoパッケージ。
タスクを進める際の地図になり、メンバーへ進捗共有もできる。
パッと全体を見られるのが良い。ほぼ毎日使っている。あまり使わなくなってきた。
各タスクを格納する変数に、規則性のある名前をつけると管理しやすい。
DAGを謳っているが循環のあるグラフを作れてしまうから、そのエラーハンドリングが課題。
gtree
generate tree の略
https://github.com/ddddddO/gtree
treeを出力するためのCLIとパッケージ。ディレクトリとファイルの生成もできるようになった。
CLIは実質2日間くらい?かかった。ある程度形になるまで1日/バグ・リファクタ対応で1日くらい。
実際のリファクタ・機能追加はかなり伸びた。3カ月弱くらい。もしかしたら、まだまだ修正するかもしれない。
その時どうしようもないと思えるバグ(そのコード。赤い箇所)が見つかっても、日が経ってから考えれば解決することがあるとわかった。
小さな問題(今回の場合は、個々のノードに絞って枝を構成するには?という問題)にして考えたら糸口が見つかった。
使いどころはわからないけど、packageとして提供を始めた。
awesome-goに載った。
https://github.com/avelino/awesome-go/pull/3910
tree生成機能をWebAssembly化し、Webページとしてホストした。
技術
連結リスト
ツリー状のデータを表現するために構成。
ディレクトリ構造をデータで表すために、親ノードから子らのノードへ・逆に子ノードから親ノードへと辿れるように構成。
各ノード(type node struct)は、親:子=1:nを持つ。
深さ優先探索
的な実装で、複雑になって諦めかけていた処理が楽に実装できそうになりそうだったのでそうしてみた。
こちらの赤い箇所が変更前。分岐が多くネストが深くなりつつあって手が付けられなくなりそうな様子がわかる。
stackを使う。type stack structを定義した。
stackなので、push/popメソッドも定義した。
ちゃんとした深さ優先探索のアルゴリズムを見る、いつか。
TDD
的に、最初に数個テストを書く->テストがこける->こけないように実装する、で進めた。
とても楽に進んだ。いいと思う。
なお、TableDrivenだとテストの追加がしやすいのでよりいい。
入力と出力がはっきりしているなら、TDDで進めた方がいいかもしれない。
CI
GitHubへPush, PR作成時にGitHub Actionsでgo testとcoverageを測定する。
GitHub ActionsでBadgeのリンクが生成されるので、READMEに記載すると、それっぽくなっていい。やり方はこちらを参考にした。
テスト実行漏れが無くなるのは大きいと感じた。
Codecovというサービスを利用してみた。
コードカバレッジの可視化と推移を確認できる。READMEのbadgeから飛べるのでいい。
こちらでも触れられているが、カバレッジの推移を追えることで、品質がもしかしたら低下していないか?の推測はできそう。
テストを書くモチベーションは特に上がらなかった(カバレッジ全く見てない)。
CD
TagをGitHub上かローカルからpushすると、クロスコンパイルされたバイナリが生成され、GitHub上からダウンロードできるようになる。
こちらのコードをコピペして使った。
内部品質
について「良いコードとは何か」を参考にした。
※大分更新していないため、記載が古くなってしまっている。
凝集度
「モジュール内の協調度」を示すそう。
高いと、堅牢性・信頼性・再利用性・読みやすさ、が良くなる。
tree/node/stack でファイルを分け、中身のメソッドは逐次的凝集・機能的凝集のいずれかに出来ているように思う。
たしかに再利用はかなりしやすかった。可読性も上がったと感じる。
nodeGeneratorのnewNode系メソッドは論理的凝集にあたるよう。良いとは言えない状態。
結合度
「モジュール間の相互依存性の程度」を示すそう。
低いと、可読性・保守性が上がる。
難しい。「公に宣言されていない内部データを直接書き換えます」には当てはまらないと思うので、内部結合なところは無い、のかな。いや、これどうかな?
nodeGeneratorのnewNode系メソッドは制御結合。良くはない。
tree.goはスタンプ結合にあたりそう。結合度は高いらしい。