書籍『数学文章作法』基礎編・推敲編
《読者のことを考える》という原則。 それが、あなたに伝えたい、たったひとつのこと。 数式まじりの説明文が題材の中心ですが、 説明文を書く人ならどなたにも役立ちます。 正確で読みやすい文章を書きたいあなたのために。 第1章 読者 第2章 基本 第3章 順序と階層 第4章 数式と命題 第5章 例 第6章 問いと答え 第7章 目次と索引 第8章 たったひとつの伝えたいこと 《読者のことを考える》という原則。 推敲にも、この原則を生かしましょう。 数式まじりの説明文が題材の中心ですが、 説明文を書く人ならどなたにも役立ちます。 文章を書きっぱなしにしたくないあなたのために。 第1章 読者の迷い 第2章 推敲の基本 第3章 語句 第4章 文の推敲 第5章 文章全体のバランス 第6章 レビュー 第7章 推敲のコツ 第8章 推敲を終えるとき 第9章 推敲のチェックリスト
絵本を読むときのパターン・ランゲージ
目次 お気に入りの1冊 ファンタジーの翼 ゆっくり読みましょう 耳をすます 半分ひとりごと いっしょに過ごすひととき お祈りと子守唄 解題 —— パターン・ランゲージって何？ みなさんからのフィードバック ぜひ、感想をお送りください 再配布条件(GPL) 書籍案内 お気に入りの1冊 ．．． 「ねえ、ごほん、よんで」 まだよく回らぬ舌で子どもがお願いをしてきます。 これから眠る前のひととき、子どもに絵本を読んであげるのです。 本棚には子どものために買った本が何冊も。 ＊ ＊ ＊ でも、今日はどの本を読めばいいのでしょう。 幼い子どもは繰り返しが大好きです。 大人は平凡な日常、退屈な繰り返しはうんざりですが、 子どもはそうではありません。 朝が来て、夜が来る。 朝が来て、夜が来る。 その平凡な繰り返しも子どもは驚きと喜びをもって迎えます。味わいます。 絵本を読むとき、子どもは情報を求めているわ
WebHooks - Web hooks
WebHooks - Web hooks 目次 この文書について Web hooks Web hooks この文書について "Web hooks" の日本語訳です http://blogrium.com/?p=70 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... このあいだ, ウェブアプリケーションの生態系に関するあるすごいことに僕は気がついた. それからというもの, 僕は頭の良い人とあうごとにその考えをぶつけてきた. ブログにも書こう書こうと思っていたけれど, あいにく僕はきちんとしたブロガーではなかった. とある事情があって, ようやくその話を書くことにした. そのアイデアは, 僕がウェブフック(web hooks)と呼んでいるものだ. すごく簡単なサーバサイドの仕組みで, ウェブアプリケーションのユーザが自分のデータを自分の好きなようにできる. 開発者は,
Gitの基礎練習
バージョン管理ツールGitの基礎練習です。 Windows XPのコマンドプロンプトでGitの基本的なコマンドを動かしていきます。 Gitを学び始めるきっかけにどうぞ。 （筆者もまだGitを使いこなしているわけではありません。 誤りのご報告、改善提案などは大歓迎です。フィードバックからよろしくお願いします） 目次 はじめに ダウンロードとインストール ファイルをGitの管理下に置きましょう 新しいファイルを追加します 新しいディレクトリを追加します 編集からコミットまでの流れはこんな風に進みます ブランチを使ってみましょう ここまでの作業ログを見ましょう この文書に書かなかったこと 関連リンク 更新履歴 ぜひ、感想をお送りください はじめに Windows XPのコマンドプロンプトで、 バージョン管理ツールGitの基本的なコマンドを動かしてみましょう。 この文書の通りに実行すると、 基本的
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
HowGoogleEarthReallyWorks - Google Earth の <ほんとの> 仕組み
HowGoogleEarthReallyWorks - Google Earth の <ほんとの> 仕組み 目次 この文書について Google Earth の <ほんとの> 仕組み パート1 終幕: 3D の仮想地球を描画する 基本 より良いフィルタリングを持ち込む さあ本題に入ろう Google Earth の <ほんとの> 仕組み この文書について RealityPrime > How Google Earth [Really] Works の日本語訳です。 推敲添削歓迎: 誤訳、タイポ、不統一、そのほか ... 有名サイト HowStuffWorks.com の記事 "How Google Earth Works" を読んだら, この記事が "それがどれだけスゴいか" や "その使い方" を書くだけで "それが(ほんとは)どんな仕組みで動いているのか" を説明していないこと
EfficientJavaScript - Dev.Opera - 効率的な JavaScript
EfficientJavaScript - Dev.Opera - 効率的な JavaScript 目次 この文書について 効率的な JavaScript ECMAScript eval や Function のコンストラクタを使うのはやめよう eval を書き換えよう 関数を使いたいなら function を使おう with を使うのはやめよう 性能を決める関数で try-catch-finally を使うのはやめよう eval と with は隔離しよう グローバル変数を使うのはやめよう 暗黙のオブジェクト変換に気をつけよう 性能を決める関数で for-in を使うのはやめよう 文字列は累積スタイルで使おう プリミティブの操作は関数呼び出しより速い setTimeout() や setInterval() には文字列でなく関数を渡そう DOM 再描画と再フロー 再フローの回数をでき
技術系メーリングリストで質問するときのパターン・ランゲージ
目次 はじめに メーリングリスト —— サポートセンターではなく互助会です 表題 —— あいさつではなく用件を書きましょう 自己紹介 —— 自分の知識・技能・経験を簡潔に書きましょう 書き出し —— 最初に問題の要旨を書きましょう 肩書き —— 会社の名前を背負っていることを忘れないように 実行手順 —— 手順は箇条書きで書きましょう 結果の予想 —— 期待した結果を書きましょう 実際の結果 —— 実際に起きたことを書きましょう ステップ明記 —— どこからうまく行かなくなったかを書きましょう 実際の値 —— 条件を具体的に書きましょう エラーメッセージ —— 必ずコピー＆ペーストしましょう 判断理由 —— そのように考えた理由を書きましょう 文献の引用 —— 読者の手間を省くように書きましょう ソース —— 関連する部分を抽出して示しましょう スレッド —— 関連する話題なら「返信」しま
バッドノウハウからグッドラッパーへ
「有用なものを生み出すけれど複雑怪奇になっているシステム」を見つけたときには、 「バッドノウハウだ」と批判するだけではなく、 バッドノウハウを隠す「グッドラッパー」を作ることを考えよう、というお話。 目次 はじめに 有益なものを生み出さなければ「奥が深い」とも呼ばれない バッドノウハウをグッドラッパーで隠そう 本当によくないシステムとは よびかけ 補足：Perlとバッドノウハウ いろんな方からのコメント 反応リンク 関連リンク 更新履歴 ぜひ、感想をお送りください はじめに 高林哲さんは『バッドノウハウと「奥が深い症候群」』というページで、 「奥が深い症候群」や「バッドノウハウをありがたがることの危険性」について書いています。 これはもっともな指摘なので、それを受けてもう一歩進んだ話を書いてみましょう。 有益なものを生み出さなければ「奥が深い」とも呼ばれない もしも「奥が深い」システムが何
IntroTestMore - A Perl Testing Tutorial
IntroTestMore - A Perl Testing Tutorial 目次 ■なぜテストするのか ■恐れないで！ ■ベーシックテスト ■Test::Simple とその API ■開発過程にテストを盛り込む ■Test::More の API について A Perl Testing Tutorial chromatic (http://wgz.org/chromatic/) (http://wgz.org/chromatic/perl/IntroTestMore.pdf) 英語がそのまま残ってる部分は意味がわからなかっとこなので、 適当に補完してね。 ■なぜテストするのか コードが仕様どおりの動きをすることを確認する。 o 実装忘れの防止 o アクシデントに対する動き o 全てのテストにパスすれば完成 境界条件のチェック o 不正な入力をどう扱うか o イジワルな操作にどう対処す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
