ドキュメントは、大体markdownでよくない？
業務の引き継ぎ内容をmarkdownで書いて、GitLabのwikiにGitでコミットするようにしたけど、個人的になかなか良い感じだった。もうなんかドキュメント類は全部markdownでよくない？って思ってる。
会社内のドキュメントが、WordとかExcelで作成されているケースが殆どだったけど、社内nasに格納されているそれらから必要な情報を探すのが大変で、ざっくりたワードでgrepしたいけど、バイナリファイルだとそれができないのが結構なストレスだった。
いちいちファイル開いて検索しては外れを引いて、心の中で舌打ちをすることが多かった。（あと、Excelファイルがなんか知らんが壊れているときがある。）
markdownだと、テキストファイルなので、簡単にgrepできるのがいい。
あと、個人的にWordとかExcelとかフォーマットが指定されていない場合に、フォーマット作りと見た目を綺麗にすることに精を出しがちで、なかなか書くことに集中できないことが多い。（あと他の人が作成した、雑なフォーマット見ると、つい直したくなってしまう）
個人的に思うメリット・デメリット
メリット
- 直感的にかける
- 簡単に整う・揃うし、シンプルで凄く簡潔。
- Office系のツールだと、自由度が高すぎて、やらなくていい整形をしていることが多い。
- 自由度が低いことが逆に良いことだと思う。
- テキストで保持ができるので、grepができる
- これに関わらずテキストファイルの強みは全文検索が簡単にできることだと思う。
- 保守性が高い
- markdownに対応しているツールは多いので、移行するのも楽。
- ファイルが軽い
デメリット
- 改行がめんどくさい
- 半角スペース二回がめんどくさい。改行一回で勝手になってほしい。
- 方言が強い
- 学習コストがかかる。
- 慣れるまで少し時間かかる。でもOffice系のツールよりは簡単な気がする。
方言が強いのが個人的にかなりマイナスなイメージ、もう少し統一する方に流れてほしい。
システムの設計書とか、markdownで大丈夫か検証してみたいところ。
kotestの初期設定でエラー
サーバーサイドkotlinを初めてやっている。
kotlinでは、junitでもテストはできるが、kotestというテスティングフレームワークが良さそうだったので、そちらを利用することにした。
とりあえず、色んな記事を見つつ、以下の手順で導入。
すると、
Found interface kotlin.time.TimeMark, but class was expected ~~
という感じのエラーが出た。
「は？絶対成功するんちゃうんけ？」と思いつつ、
内容的に時間がどうのこうの処理は入っていないので、 たぶんなんか根本的にダメそうな匂いを感じながら、ググったところイシューを発見。
https://github.com/kotest/kotest/issues/2960
どうやら、kotlinとkotestのバージョンの組み合わせが悪い場合に発生するエラーらしい。
イシューを参考にkotestのバージョンを上げるとテスト通った。よかったよかった。
この記事にたどり着いて、見当違いの内容で解決しない人は、どうかうちの実家の犬写真をみて落ち着いてください。
ブログを始める
今から始めます。
