「間違いをなくすテクニック」の編集履歴（バックアップ）一覧はこちら
「間違いをなくすテクニック」(2011/05/06 (金) 11:32:14) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
原稿中の間違いをなくすために。
*URLなどは必ずコピペ
URLは手打ちせず、いったんブラウザ上でアクセスした上で、アドレス欄から直接コピペしよう。意外とURLのtypoは多い。
*サンプルの検証は欠かさない
本当は当たり前の話であるのだが、特に簡単なサンプルだったりすると、原稿に手を入れて、サンプルにもこれを反映させた後、検証が行われていないということがよくあるようだ（特に著者校正など最終段階になってくると、作業もバタバタしてくるので要注意）。
しかし、サンプルはひと文字でも修正したら、検証が必須。
かつての失敗談。
web.xml（JSP）にコメントを追加した後、検証せずにそのままでいたら、サンプル全体が動かなくなり、慌てたことが。原因は文字コードの間違いでweb.xmlが認識されなくなり、アプリそのものが起動しなくなったことにあった。コメントだから動作に関係ないよ、と気軽に無検証で修正したことによる失敗だった。
*できるだけ多くの人の目を通す
できれば監修＆編集以外に、最低ひとりは査読者をお願いするのが好ましい。まったくの別視点で見てもらうことで思ってもいなかった間違いが発見できることもあるし、そもそも原稿のブラッシュアップにもつながる。
査読者は必ずしもその技術に詳しい人間である必要はないし、ましてや編集経験がある必要もない。むしろできるだけ想定読者に近い（たとえば入門書であれば、まったくの初学者）ことが望ましい。
*自分で読み返すときには時間をおいて
書いた記憶が残っているうちに読み返しても、なかなか間違いや原稿の問題点は出てきにくい。締切が迫っているとなかなか難しいのだが、推敲は執筆から少しでも時間を置いてから行うのが望ましい。
原稿中の間違いをなくすために。
*URLなどは必ずコピペ
URLは手打ちせず、いったんブラウザ上でアクセスした上で、アドレス欄から直接コピペしよう。意外とURLのtypoは多い。
*サンプルの検証は欠かさない
本当は当たり前の話であるのだが、特に簡単なサンプルだったりすると、原稿に手を入れて、サンプルにもこれを反映させた後、検証が行われていないということがよくあるようだ（特に著者校正など最終段階になってくると、作業もバタバタしてくるので要注意）。
しかし、サンプルはひと文字でも修正したら、検証が必須。
かつての失敗談。
web.xml（JSP）にコメントを追加した後、検証せずにそのままでいたら、サンプル全体が動かなくなり、慌てたことが。原因は文字コードの間違いでweb.xmlが認識されなくなり、アプリそのものが起動しなくなったことにあった。コメントだから動作に関係ないよ、と気軽に無検証で修正したことによる失敗だった。
*キーワードはできるだけ辞書を確認
技術に詳しい人が記事を書いても、意外と初歩的なキーワード解説に誤りが発生することが多い。たとえば、Webアプリケーション、サーバ／クライアント、フレームワーク、クラウド、.NET Frameworkなどなど…過不足なく説明するのはなかなか難しい。
これら初歩的なキーワードこそ、自分で記事を書いた後、改めて辞書などで意味を再確認するべきだ。説明が一部の側面に偏っていたり、そもそも事実誤認であったりということはよくある。
*できるだけ多くの人の目を通す
できれば監修＆編集以外に、最低ひとりは査読者をお願いするのが好ましい。まったくの別視点で見てもらうことで思ってもいなかった間違いが発見できることもあるし、そもそも原稿のブラッシュアップにもつながる。
査読者は必ずしもその技術に詳しい人間である必要はないし、ましてや編集経験がある必要もない。むしろできるだけ想定読者に近い（たとえば入門書であれば、まったくの初学者）ことが望ましい。
*自分で読み返すときには時間をおいて
書いた記憶が残っているうちに読み返しても、なかなか間違いや原稿の問題点は出てきにくい。締切が迫っているとなかなか難しいのだが、推敲は執筆から少しでも時間を置いてから行うのが望ましい。
