概要
Goの入門としてQiitaをローカル管理するツールを作った。
リポジトリは以下。
https://github.com/ma-bo-do-fu/qsync
今回はその感想をメモしておく。対象読者はGo言語やツール開発初心者。
環境
$go version go version go1.10.3 darwin/amd64
モチベーション
- Goの練習したい
- Qiita記事をGithub管理したい
- ドキュメント管理をCIに載せたい
作ったもの
詳細は下記参照。
https://github.com/ma-bo-do-fu/qsync/blob/master/README.md
概要だけ記載する。
$qsync pull
すべての投稿を指定した場所に保存する。
$qsync push /path/to/entry
保存した投稿を更新する。
$qsync post
新規に投稿する。
入門としてよかった点
題材が練習としてちょうどよかった。 今回のツールを通して以下の処理について学ぶことができた。
問題点
画像添付できない
画像添付用のAPIがないので画像が添付できない状態。
運用としてローカルで画像保存用のディレクトリ(例：YYYY/mm/dd/images)を作ってそこで管理し、記事公開時に改めてブラウザ側で添付するなどか…
Qiitaの画像はS3で管理されているので、
$qsync attach 記事ID /path/to/image
とかでS3のURLが返ってきたらローカルで作業が完結できそう。
マークダウンの表示が異なる
VSCodeのマークダウンプレビューととQiitaの編集画面とで表示が異なる。 結局微調整のためにブラウザで編集することに…
感想
- テストを書かずに開発するのはつらい
とりあえず動くものを作ろうとテストを書かずに開発したら苦労した。次はテストの書き方を覚える予定。 - 毎回go build/go installをするのが大変
コード変更したら自動でビルドとインストールが走るようにしたい。 - プロジェクトの名前が被っていた
ツールを作るときはGoogleとGithubで検索して被っていないか調べたほうが良い。 - rangeの書き方が馴染んだ
tour of goをやっているときにrangeの書き方に戸惑ったが、ツールを書いていたら馴染んだ。 - gometalinterを早めに入れればよかった
linterは開発初期から入れるべき。後から入れると修正が大変。 - ちゃんと設計しないと後からつらくなる
README駆動開発という言葉もあるように、最初に要件定義を書くと全体の見通しが立ちやすいと思う。
何かのサービスのAPIクライアントを作るのは、その言語に初めて触れるときに良い練習になると感じた。 新しい言語を学びたいけど作るものに困っている方はAPIクライアントにチャレンジしてみるとよいかもしれない。
