本稿は続き物です
アウトプット時のマークダウン記法について、よりステップアップにフォーカスした内容です。
バッジの獲得ではなく、アウトプットを目的にする場合
アウトプットするのが目的ならスケジュールに縛られる必要はなく、書きたいことや忘れてもいいことをいつでも忘れられるように細かい事を気にせず書き殴っておくのがいいと思います。
正直、記事を下書きにして寝かせる事ほど勿体無い事はないので、下書きで置いておくぐらいなら未完成でも公開しておくべき、という意見です。
なので、私に取ってはある意味「敗北宣言」として本稿を残しました。
ステップアップ・マークダウンからMermaidへ
記事は書ける時に書く。特に勉強会の記事は後から振り返ってまとめるのが苦痛でしかないです。
勉強会（ハンズオンを含む）に参加し、その場で学んだ内容をまとめ、また普段から良質なナレッジにするためにマークダウンに慣れておくと良いです。
さらにステップアップするなら、Mermaid記法も書けるようにしておくと良いです。
もっとしっかりしたUMLも書けるようになるとベスト！
このレベルまでいくならVSCodeかなぁ、QiitaのWebエディタだけでは完結が難しそうです。
対応されたらやっていきたいところ。
チートシートを用意しておこう
私が好んで多用するのは、
これ。:::noteで書けます。Zennにも似たような書き方があります
と注釈1です。
使えるものはなんでも使うべきですが、一般のマークダウン以外のオリジナル拡張マークダウン記法を積極的に使うのはプラットフォームを移行したい時に不便なので正直おすすめはしませんが、使いこなせると便利なので手放せなくなるんですよね。
先ほどのMermaidなりUMLなりはVSCode上でスクリーンショットもソースコードも残せるのでやりようはあります。QiitaもCLIを使うなら悪くはないですね。
QiitaCLIを使ってQiitaの記事をGitHubにバックアップすることもできます。
なお、チートシートというほど網羅できてはいないですが、どのように書くかの例を置いておきます。
【コラム】QiitaCLIでQiitaの記事をバックアップする
長くなったので別記事にしました。
記事URL（QiitaCLIを使ってQiitaのWebエディタで書いた記事も丸ごとGitHubでバックアップ・管理したい）
ポイントだけ抜粋しますと、以下コマンドを実行できるCIを用意してデイリーバッチにすればいいです。
npx qiita pull
git add -A
git commit -m "qiitaバックアップ"
git push
これをGitHub Actionsに定期実行させればOK。
注釈
-
【注釈】注釈は書きまくると分かりにくいので、注釈したい文字（注釈コメント）のような書き方をする方法を採用しがちです。あくまでQiitaオリジナルの書き方なので、Zennに移行したい場合がちょっと大変。 ↩