Kubernetes入門記事のKPT
K
- 3記事書けた!
- それなりの分量書けた!
- そこそこ再利用して書く工数削減できた!
- 目次から記事を書くメソッドを実践できた!
- 記事の内容を実際に業務中に応用することができた!記事を見返すことが役に立つ状態になった!
- サムネ画像を絵文字で作れることに気づいた!
P
- 記事をあやまって塩漬けにしてしまうと、記憶を復帰させるのに時間がかかるし、検証もままならない
- 3記事どれも1度以上塩漬けにしていて、体感2倍くらい時間がかかった
T
P
- 誰も記事を見ない
- 記事を公開してから10日くらい経っても訪問者が0人なのはびびった。ほかの記事でもここまでひどくない。技術系記事を普通の記事に混ぜると本当に読まれないらしい。
T
- Qiitaに投稿してみるかーという気にちょっとなった
- でもあんまりー結構マサカリな人多いんだろうなあ
- 何も開発せず、Google Kubernetes Engineにアプリケーションをデプロイする
- 何も開発せず、ローカルKubernetes環境にアプリケーションをデプロイする
- みたいなタイトルでQiita投稿してみるか
- プロフィール欄を
- ビビリなのでやさしくしてください><
- とかにすれば、せめては、、
- でも色々考えたけど、Qiitaにふさわしいかとか、間違ったこと書いてないかとかに気を使う時点で記事作成作業には邪魔になってしまうので、mediumに閉じこもるほうが幸せかもしれないと思った。
P
- コマンドリストが見返しにくい
- 本当はごく少ないリストのはずだけど、説明過多すぎてあたかもたくさんのプロセスを踏んでいるように見える
T
- 記事の目次を書いた後、説明から書かずにコマンドから書く。
- 説明も本文よりは、コマンドにコメントを付加することを優先する
P
- 人によってはこのコマンドが必要、みたいな分岐が発生してコマンドが見づらい
- 特にインストール系コマンド
T
- 事前準備としてインストールコマンドはまとめてしまう
P
- 手数がきつい
- ブログ記事仕上げる時間がとにかくかかる。そしてその仕上げる時間はそこまで自分の学びに直結していない。
- 解説っぽい文章を書くのと、コマンドのコピペに時間がかかっている?
T
- コマンドのコピペに関しては、すでに述べたようになるべく最初からコマンドリストの作成を心がける
- 解説っぽい文章のコストは、説明だけならまだしも、結構細かい言葉尻(〜ます。〜だ。的な)がおかしかったりするのを直すのにも結構時間を消費しているので、なるべく解説文章は少なく仕上げる。最初に解説ポイントを設計する。みたいな工夫が必要そうだなと感じた。
P
- 文脈が効きすぎて見返しにくい
- 文脈が効きすぎて、というのは、例えば記事を開いて、適当な場所までスクロールして、記事を読もうとすると、その場所だけ見ても意味不明な状態になっちゃう現象。前後を見直さないとわけがわからない。
T
- 記事全体のストーリーがあることで理解の助けになっている面もあると思うので、一概に悪いとは言えないかもしれない
- 本当はコマンドやソースコードの意味は文脈全く無くても理解できるもののはず
- もうちょっとそのコマンド、ソースコードの1行1行分割しても成立するような説明にする必要があるかもしれない
今浮かんだこうしたほうが良さそう的な姿は、記事上部にコマンドとコードのリストがあり、それぞれにちょっとした説明のコメントが付加されてて、その下部にそれぞれの概念に対して突っ込んだ説明があるというもの。突っ込んだ説明は辞書方式になっていて、それぞれ切り離して説明している感じになる。・・・いやしかし、必要に応じて文脈的な説明も必要だと思う。と書いていて思った。
記事を書く場合において、いちばん労力がかかるのがわかりやすい詳細な説明を書くこと。上記で浮かんだ書き方なら記事下部の突っ込んだ説明が無くても、最低限記事として成立させられるし、自分の学びの濃度も濃い状態を保てそうなので、記事を書いた後の満足感をより上げられるのではないか。読む人にとっては少し・・・不親切になるかもしれないが。