Wings Knowledge β-- (執筆お役立ちメモ)

Wings Knowledge β-- (執筆お役立ちメモ)内検索 / 「文章の書き方について」で検索した結果

• 文章の書き方について
  文章の書き方について。 対象読者を明確に 対象読者によってどこまで解説すべきか、どんなキャプチャを見せるべきかは変化する。 話題の大小関係を明確に 最初からいきなり細かな話をしてしまい、全体像が見えない記事は意外と多い。 まずは、テーマの外枠を鳥瞰できる説明を先頭で明示し、これから説明する個々のトピックの位置づけを明確にすること。 その上で、個々のトピック説明を展開していけば、読者は途中で置いていかれても、先頭に戻れば記事の全体像を再確認できる。また、最初に全体が見えているので、個々のトピックも安心して読み進められる。 ＃これはTIPSのような短い記事でも基本は同様。これからなにを説明するのかをまずは先頭で示すべし。 なお、「外枠を鳥瞰できる説明」は、可能であれば図示できるのが望ましいが、文章でも可。ただし、「鳥瞰」なのであ...
• メニュー
  目次 企画について 原稿のレイアウトについて 文章の書き方について サンプルについて 画面キャプチャや挿絵について 間違いをなくすテクニック 著者校正のポイント 著者の心得 著作権について 中の人たちに向けて 総合： - 本日： - 昨日： -
• 原稿のレイアウトについて
  原稿の構成／つくりについての留意点。 主テーマはなんであるか 主テーマがなんであるかを意識しよう。そして、主テーマに記事の分量の7割以上を割いているかをチェックしてほしい。 主テーマの前提となる解説や、余談、補足説明に記事の半分以上を費やしているのであれば、記事のテーマ設定がおかしいか、そもそも構成に問題がある。 ついでの説明は避ける たとえばデータベースアクセスの説明で、ついでに処理後のリダイレクトについて説明するようなパターン。 確かに、本として説明はしてあるかもしれないが、あとからリダイレクトについて調べる時にどこに書いてあるのかが分かりにくい（索引で引けば良いといえばそうなのだが）。 また、一連の技術の中で、リダイレクトがどういう位置づけにあるのかが分かりにくくなる。 説明してあれば良いというわけではない。 ...
• サンプルについて
  サンプルの取捨選択や説明の仕方について。 サンプルの選択の仕方 サンプル作成の基準は以下。 最大限、シンプルであるか 対象となる命令の使いどころを理解させるのに十分であるか サンプルは凝ったものである必要はない。しかし、ただ構文をただなぞっただけでは意味がない。 構文を理解させるのは最低限、その上で、その機能がどのような局面で利用されるべきものかが実感できるようなサンプルが好ましい。 もっとも、それでサンプルが複雑なものになってしまうのは、それはそれで好ましくない。1.のルールを維持するためにも、ある程度は文章で「使いどころ」を補うことを検討する必要があるだろう。 基本的にはすべての説明に何らかのサンプルがあるべき 記事の中で説明しているキーワードや概念、機能について、ただ説明だけで終わり、というのは原則不可...
• 企画について
  企画立案＆構成案に関する話題をまとめる。 企画趣旨 企画立ち上げにあたって、最低限検討すべきこと。 企画立案の理由（市場状況／成熟度、問題点、新規性） 読者層（初心者or上級者向け。読者に要求する前提知識。使用するアプリケーションやフレームワーク。その他、より具体的に想定する読者層、どういった立場の人間に読ませる書籍／記事なのか） 想定する発表媒体（雑誌、サイト名など） 類書比較（競合する記事／書籍とそれらとの比較。ない場合にはその旨を） 構成案＆企画案 構成案＆企画案に最低限含めるべき内容。 書籍／記事の目的＆読者層 目次案（書籍であれば章／節レベルのタイトル＋概要、雑誌であれば節／項レベルの構成） 仕様（必要とされるおおよそのページ数や体裁） ...
• 画面キャプチャや挿絵について
  画面キャプチャや挿絵を作成する場合の留意点。 ひとつの記事は同じ環境でキャプチャ ひとつの記事（書籍＆シリーズ）では、キャプチャ環境の統一は必須。使用しているOSはもちろん、ブラウザやアプリケーションのバージョンも途中で変更しない。 ＃長い連載の場合は例外もあり。 また、対象読者層にもよるが、基本は、ブラウザやアプリケーションは特別なプラグインなどを適用していない初期状態であること。 キャプチャ／挿絵と本文には関連を持たせる とりあえず本文の中にキャプチャや挿絵を挟んで満足してしまう、ということは意外と多い。しかし、キャプチャや挿絵は、あくまで本文の理解を助けるための仕掛けだ。キャプチャ、挿絵に基づいて、本文を膨らめなければ意味がない。 本文からなんの言及もされていないキャプチャ、挿絵はNG。 キャプチャはできるだけ必要箇...
• 著者の心得
  著者としての心構えや、仕事の進め方などについて。 まずは一通り書き上げよう ひとつひとつきちんと片付けていきたい、その気持ちは分かる。 でも、文章は全体を通してのバランスが重要。 おそらくその章（節）を完成させたと思っても、次の章（節）では再び前の章を書き足したい、修正したいというのはよくあること。結局、部分的に完成させていくことは、多くの場合は不可能なのである。 ＃それは、リファレンス本やTIPS本などのものでさえ、前後のバランスを見るという意味では同じ。 一箇所で立ち止まるべきではない。まずは一通り書き上げてみよう。 書いている間はどんなに苦痛でも、とりあえず全部書き上げてみると、多くの場合はとりあえずはなんとなく形になっているはずだし、全部を書き上げたところで問題も見えてくるはず。 仮脱稿は本脱稿だと思うべし ...
• トップページ
  このドキュメントについて このドキュメントでは、著者が自分自身の執筆や監修の経験に基づいて、プログラミング系の入門記事を執筆する際に留意すべきと思われる点をまとめています。 もっとも、あくまで著者とその仲間たちとの間のメモ書き程度の内容なので、内容は（暗黙的に）特定分野の記事を想定しています。つまり、偏った記述があるかもしれません。 また、気づいたものから列挙しているだけなので、体系的にまとまっているわけでもありませんし、文章としてきちんと推敲されているわけでもありません。従って、本稿に対して「これだって、ルールに沿っていないではないか」などの指摘はご容赦ください。 時として、前後矛盾する規則もありますが、本稿ではいずれが正しいという議論をするつもりはありません。おそらく状況によってはいずれも正しいものであると思われるからです。その時どきでどういう対応を取るかは...
• 著者校正のポイント
  著者校正時の注意点を。 どうでもいいけど、著者こうせいは「構成」ではなく「校正」です 校正の基本 著者として校正の知識は最低限。 きちんとした書籍で勉強しておくことがより好ましいが、最低限、以下のような記号くらいは覚えておきたい。 印刷校正記号一覧 校正のチェック項目 ★★★別途表で提示★★★ （雑誌記事の場合）基本フォーマット P.●○ ～行目 間違った箇所 → 正しい記述 修正箇所ができるだけはっきり分かるように心がけたい。 全体として気になった箇所は別出しする これは出版社によって方針が異なるかもしれない。 たとえば、すべてのコードでバックスラッシュを円マークに修正したいようなケース。 このような場合は、すべての箇所に赤字を入れることは好ましく...
• 間違いをなくすテクニック
  原稿中の間違いをなくすために。 URLなどは必ずコピペ URLは手打ちせず、いったんブラウザ上でアクセスした上で、アドレス欄から直接コピペしよう。意外とURLのtypoは多い。 サンプルの検証は欠かさない 本当は当たり前の話であるのだが、特に簡単なサンプルだったりすると、原稿に手を入れて、サンプルにもこれを反映させた後、検証が行われていないということがよくあるようだ（特に著者校正など最終段階になってくると、作業もバタバタしてくるので要注意）。 しかし、サンプルはひと文字でも修正したら、検証が必須。 かつての失敗談。 web.xml（JSP）にコメントを追加した後、検証せずにそのままでいたら、サンプル全体が動かなくなり、慌てたことが。原因は文字コードの間違いでweb.xmlが認識されなくなり、アプリそのものが起動しなくなったことにあっ...
• @wiki全体から「文章の書き方について」で調べる

更新順にページ一覧表示 | 作成順にページ一覧表示 | ページ名順にページ一覧表示 | wiki内検索