🙆

web上で公開されているハンズオンにおける私的注意点

2021/05/31に公開

退プロから次の現場までに若干の空白ができたので、ウェブ上のハンズオンをいくつか叩いた。
その際に考えたことを、ちょっとだけアウトプットしておこうかと思う。

守破離を意識する

個人的には、ハンズオンをそのまま叩くのを良しとしない天の邪鬼なので、本当に初めて触る言語やフレームワークでない場合は多少の応用をかけて触るようにしている。

逆に初めての場合は、まずは書いてあることをなぞりつつ、行間でわざと中途半端な状態を作りエラーまたは想定外の動作を吐かせたり（例えば３つのファイルを作成するべきところで１つ作るたびに実行するとか）、とにかく思いつく範囲でわざと失敗（と考える行動）をする。

個人的（<s>強調</s>） には

個人的によくやるもので言うと、以下のものが簡単かつ効果があると思っている。

ハンズオンで使用している環境を代替してみる
- mavenを使用しているハンズオンをgradleで触ってみる
- mySQLを使用しているハンズオンをpostgreSQLで
- 環境をコンテナやVM内に作成して実行してみる
アプリケーション名称や変数名を独自のものに変更する
- 同じことを実行する処理を別名で作る

地味になめてはいけないのが名称変更で、コピペに頼ったハンズオンでは結びつきがいまいちな部分を僅かな変更で把握できるので結構有用だと考える（くどいけど個人の見解）。

これは著者さんに対して喧嘩を売る意味ではなく、著者さんも人間であり間違いを起こすという事を忘れてはいけないということ。全面的に信用してしまうと、変な落とし穴にハマることが少なくないというのが個人的な見解。

個人的にはハンズオンで間違っている事は大きく以下の２つに分かれると思っていて

著者の思い込みあるいは単純なtypoからくるミス、もしくは記述漏れ
書いた時点ではなんの問題もなかったが、脱稿後に何らかの理由で記述通りのことができなくなるケース（例えば依存ライブラリのの競合、バージョンアップによる構成変化等）

前者はコード中であれば殆どの場合エラーになるので実行時に気づくのでこっそり直して使う。後者については、書いたあとも筆者さんが精力的にそれを確認することの方が少ないので、記述どおりに動かない場合の実戦勘を養えたと思ってポジティブに。

（以下は余談）

後者はいわゆる現場の環境構築手順とかでもよく起こる（個人の体感）。どう先輩に聞くべきかをちゃんと考えないと「なんで手順通りにできないの」と逆上される理不尽な目にあうことも（近年なら環境を仮想化して配るべきだと思う）。

近年で著者が引いた中でかなりインパクトが有ったのは、そこそこ有名なチュートリアル中の、よりにもよって「テストでエラーを確認する」部分で本当に（著者からすると想定外である別の）エラーを吐くという初見殺しだった。流石にわかってないと死ぬ。

間違いの指摘とかがあるとついでで伝えやすいけど、そうじゃない場合はいいね（favとかLGTMでも）をつけるだけでもいいし、とにかくそれが役に立ったことを些細な形でもいいので筆者さんに伝える。これはまぁただのお礼だけど、あるいはそこから最新化確認しておこうとかで記述の見直しにつながるかもしれない。

Qiitaとかでは最終更新から１年以上で最上部に警告が出るけど、自己ブログの記事とかは古くなっているものがずっと残りがちなので、「その時点でも使えたよ（or微修正が必要だよ）」みたいなFBを返しておくと世界が幸せになる。と思う。

こういうアウトプットでも誰かの役に立つといいな。
アウトプットしないのは知的な便秘。