はてなブログで Processing.js を実行する方法
Processing.js はブラウザ上で Processing のプログラムを実行できるようにする JavaScript ライブラリです。 このライブラリを利用すれば，はてなブログの記事内に直接 Processing のコードを記述して実行することができます。
はてなブログにスケッチを埋め込んで実行する方法ですが，Markdown モードの場合は公式サイトのチュートリアルにある内容そのままで大丈夫でした。 記事の編集画面で以下のように記述すれば問題なく実行できます。
<script type="text/javascript" src="processing.min.js"></script> <script type="text/processing" data-processing-target="processing-canvas"> /* ここにコードを書く */ </script> <canvas id="processing-canvas"></canvas>
スケッチを公開するなら OpenProcessing などのサイトを利用した方がよい気もしますが， こんなこともできるよということで手順について簡単に説明してみたいと思います。 ここで紹介する方法は，はてなブログに限らず，他のブログサービスを利用する場合や自分で Web ページを作成する場合にも適用できるはずです。
手順の説明
はてなブログで Processing.js を実行したい場合も，一般的な Web ページで実行する場合とまったく変わりません。 以下のような手順で比較的簡単に Processing.js を実行することができます。
- processing.min.js を読み込む。
- 描画先の canvas 要素を用意する。
- Processing のコードを記述する。
processing.min.js を読み込む
まずは Processing.js の本体を用意します。 公式サイトのダウンロードページから processing.min.js の最新版を入手してください。 実際のファイル名は processing-1.0.0.min.js のようにバージョン番号が入ったものになります。
本体の JavaScript ファイルが用意できたら，それを読み込む記述を追加します。 記事の編集画面で script 要素を追加し，src 属性にダウンロードした processing.min.js の URI を指定してください。
<script type="text/javascript" src="processing.min.js"></script>
はてなブログにはファイルをアップロードする機能はありませんので，processing.min.js は自分でホスティングする必要があります。
描画先の canvas 要素を用意する
スケッチの描画先となる canvas 要素を用意します。 この後で追加する script 要素から参照できるように id 属性を指定しておいてください。 例では単純な id をつけていますが，ブログでは 1 ページに複数の記事が表示されることもありますので，絶対に重複しないような工夫をした方がよいと思います。
<canvas id="processing-canvas"></canvas>
後で説明しますが，id をつけずに済ませる方法もあります。 スケッチをたくさん公開する予定ならば，そちらの方が楽かもしれません。
Processing のコードを記述する
Processing のコードを書くための script 要素を追加します。
type 属性を text/processing または application/processing とし，data-processing-target 属性に描画先の canvas 要素の id を指定します。
<script type="text/processing" data-processing-target="processing-canvas"> /* ここにコードを書く */ </script>
script 要素の type 属性に未知の値が指定されている場合，多くのブラウザは script 要素を無視します。 そのことを利用して script 要素に Processing のコードを直接書けるようにしています。 processing.min.js の中身を覗いてみると，type 属性の値をもとに Processing のコードかどうかを判定して実行していることがわかります。
なお，コードを書く script 要素を canvas 要素の直前に置けば data-processing-target を指定しなくても大丈夫です。 しかし，Markdown モードでは canvas 要素が自動的に p 要素に入れられてしまうため，そのままではうまくいきません。 以下のように script 要素と canvas 要素を div 要素に入れてやることでこの問題を回避できます。
<div> <script type="text/processing"> /* ここにコードを書く */ </script> <canvas></canvas> </div>
Processing の記事をたくさん投稿するなど，描画先の canvas 要素に一意な id をつけるのが面倒だという場合は，こちらの方法が楽かもしれません。
スケッチファイルを参照する場合
script 要素を使って直接記事にコードを埋め込む以外に，外部のスケッチファイルを参照することもできます。 公式サイトのチュートリアルでは，むしろこちらのほうが推奨されていました。
外部の *.pde ファイル（拡張子は *.pjs を使用する場合もあるようです）を読み込ませたい場合は，canvas 要素の data-processing-sources 属性でファイルを指定します。 この場合は canvas 要素に id 属性をつけなくても構いません。
<canvas data-processing-sources="sample.pde"></canvas>
この方法は環境によっては Same-Origin Policy 違反で実行することができないこともあるようです。 たとえば，Chrome ではローカル環境では実行することができませんでしたし， はてなブログから gist に置いたコードを読み込ませようとしてもエラーとなりました。
ソースコード
おまけとして冒頭のデモで使用したソースコードを掲載します。 ボールが色を変えながら回転するだけの単純なサンプルです。
参考資料
Processing で補色残像のデモを作ってみた
任意のカラー画像で補色残像を体験できるプログラムを Processing で作ってみました。
プログラムを実行すると "stimulus.jpg" という画像ファイルを読み込んで変換します。 まず補色画像と注視点が表示され，30 秒後にグレースケール画像に切り替わります。 グレースケール画像が表示されている状態でウィンドウをクリックすると，再び補色画像を呈示するステップに戻ります。
実行中に S キー押下で補色画像とグレースケール画像を保存します。 出力されるファイルの名前はそれぞれ "comp_image.jpg" と "gray_image.jpg" です。 上書きの確認などは一切ありませんので，もし使用される場合にはご注意ください。 万が一，大事なファイルが消えたとしても責任はとれません。
ソースコード
有名な Big Spanish Castle のチュートリアルにある内容をそのまま実装しただけです。
技術的なお話
補色画像は，単純に階調を反転させるのではなく，輝度を調整した上で反転させています。
Photoshop を用いた本家の解説では，ブレンドモードを「輝度」にして 50% グレーでの塗りつぶしを実行しているのですが，このブレンドモードを実装するのに少々手こずりました。 はじめは，カラーモデルを HSB に設定し，各ピクセルの Brightness を 50% グレーと同じ値に書き換えるように実装したのですが，出力された画像は Photoshop で作成した画像よりも全体的にかなり明るくなっていました。
どうやら，Photoshop のブレンドモードで使用される「輝度」は HSB カラーモデルの Brightness ではないようです。 ブレンドモードの同じグループに「色相」や「彩度」があるので，てっきりそうだと思い込んでしまっていたのが敗因でした。 今になって思えば，Brightness は「明度」と訳されることが多いと思いますし，英語版での表記は Luminosity となっていましたので，もっと早くに気づくべきだったのですが……。
いろいろ調べた結果，Adobe PDF Reference Archive に Blend Modes Addendum（PDF） という資料を見つけました。 この資料によると，Photoshop では輝度の計算に YUV を使用しており，ブレンドモードを「輝度」にした場合には，source と destination の輝度の差だけ RGB 各成分を単純に増減し，最後に RGB 各成分の値が範囲に収まるように 3 つまとめてスケーリングしているようです。
この資料の計算式をそのまま記述したところ，めでたく Photoshop で作成した画像と同じ結果が得られました（当たり前ですが）。
統計記号を一瞬でイタリック体にする方法
Word の検索・置換機能をつかって統計記号をイタリック体に書式設定するやり方を紹介します。 APA の Publication Manual によれば，統計量をあらわす記号は欧文書体のイタリック体にすることになっています。 本文中の SD や p といった記号をいちいち選択して書式設定するのは面倒ですが，ここで紹介する方法なら最後にまとめて設定できるので楽です。
書式の置換
Word の［すべて置換］を使って統計記号の文字書式を「標準」から「斜体」に一括変換します。 Word の検索・置換機能では，文字列を検索・置換するだけではなく，文字列の書式を検索・置換することもできるのです。
基本的な手順
［ホーム］タブの［編集］グループから［置換］を選択します。
［検索する文字列］にイタリック体にしたい統計記号を入力します。
［置換後の文字列］をクリックして入力フォーカスをあわせてから［オプション］⇒［置換］⇒［書式］⇒［フォント］を選びます。
［スタイル］で［斜体］を選んで［OK］ボタンをクリックします。
［置換後の文字列］の下に「フォント：斜体」と表示されているのを確認して［すべて置換］を実行します。［置換後の文字列］は空欄のままで構いません。
こうすると［検索する文字列］に指定した統計記号と一致する箇所がすべてイタリック体になります。
まとめて指定
検索・置換の対象として複数の統計記号をまとめて指定することもできます。 ここでは例として，平均値 M，標準偏差 SD，相関係数 r，t 値，F 値，p 値をまとめてイタリック体にする場合を考えてみます。
まず，［検索と置換］ダイアログボックスを表示させたら，［オプション］⇒［検索オプション］⇒［ワイルドカードを使用する］にチェックを入れます。 こうすると［検索する文字列］の下に「ワイルドカード」と表示され，検索と置換で特殊文字による正規表現もどきが使えるようになります。
次に，［検索する文字列］にイタリック体にしたい統計記号を並べ，それらを半角の大括弧で括ってやります。
[MSDrtFp]
これで「大括弧で括られた文字のいずれか 1 文字に一致する場合」と指定したことになります。 SD は 2 文字ですが，今回の場合は S と D が 1 文字ずつでそれぞれヒットするので問題ありません。
統計記号だけを変換する
基本的には上記のやり方でよいのですが，じつはこのままでは誤変換の問題が生じてしまいます。 統計記号としてアルファベットを指定すると，引用文献リストの著者名や論文名などにもヒットしてしまうことがあるためです。
区切り位置を指定する
そこで，英単語の一部にヒットしないように，正規表現もどきを使って単語の先頭と末尾の位置を指定します。 たとえば，平均値の M という 1 文字だけでひとまとまり（＝単語）としたい場合，［検索する文字列］を以下のようにします。
<M>
< > の中には先ほどの大括弧を使ったやり方で統計記号をまとめて指定することもできます。
ただし，残念ながら今回は 1 文字で意味をなす統計記号しかまとめることができません。
<[SD]> という検索パターンは「"S" または "D" という単語を探す」という意味になるからです。
SD や ns. などの 2 文字以上の統計記号は個別に置換してください。
著者イニシャルへの対策
区切り位置を指定しただけでは誤変換を完全に防ぐことはできません。 平均値 M のような大文字 1 文字の統計記号は，引用文献リストにある著者ファーストネームのイニシャルにヒットしてしまうことがあります。 この問題への対処法はおそらく 2 つ考えられます。
あとで元に戻す
ひとつめの方法は，とりあえず全部置換しておいて，誤って設定されてしまった箇所だけ書式を元に戻すやり方です。
統計記号にはヒットせず，著者のイニシャルだけにヒットするパターンは簡単です。 イニシャルの場合はアルファベットの後にピリオドが続くことを利用して，［検索する文字列］を以下のように指定します。
<M>.
これで［置換後の文字列］を書式なしに設定して再度［すべて置換］を実行すれば，イニシャル部分の書式だけを元に戻せます。
書式なしの設定は［スタイル］を［斜体］から［標準］に戻すだけです。 ［置換後の文字列］の下に出てる表示が「太字（なし），斜体（なし）」に変わります。 ［書式］ボタンのすぐ近くに［書式の削除］というボタンがありますが，これは罠ですので注意してください。 ［書式の削除］を選んでそのまま置換を実行すると，書式だけでなく文字列まで削除されてしまいます。
ヒットしないようにする
ふたつめの方法は，著者のイニシャルにはヒットしないように検索するパターンを修正するやり方です。
アルファベットの後にピリオドが続く場合を除外するため，［検索する文字列］を以下のように修正します。
[! と ] で文字をくくると「その文字以外の 1 文字」という意味になります。
<M>[!.]
これでピリオドが続く場合を除外できますが，副作用として統計記号の直後にある括弧やスペースなどもイタリック体になってしまうのが難点です。 スペースはイタリック体にしても変わらないので問題ありませんが，記号類はフォントファミリーによっては表示がおかしくなります。 これを元に戻すためには，以下のようなパターンを使って記号類に書式なしの置換を実行する必要があります。
[ (=<>]
結果をまとめて報告する場合
どの条件の組み合わせでも有意差がみられなかった場合など，「Fs < 1.00」のように結果をまとめて報告することがあります。 F の部分だけをイタリック体にする必要があるのですが，残念ながら Word には検索でヒットした場合にその一部分にだけ書式を設定する方法が用意されていません。
そこで，著者のイニシャルへの対策でやったように，一度置換しておいて元に戻す方法でいきます。
まず，［検索する文字列］を以下のようにして s の部分も含めてイタリック体にしてしまいます。
<Fs>
次に，［検索する文字列］を以下のようにして s の部分だけ書式を元に戻します。
s> @[=<>]
書式を元に戻すときに使っているパターンは「s で終わる単語で，その後にスペースが 1 つ以上あり，さらに等号または不等号が続く」という意味です。 引用文献リストの英文にヒットしないように「等号または不等号が続く」という条件を入れているのがポイントです。
参考資料
Access のフィールド名に全角記号を使ってはいけない
Access の演習でレポートウィザードを使ってレポートを出力させたところ，多くの受講生から「レポートが作成できませんでした」というエラーが発生したとの報告がありました。 出力されたレポートを確認してみると，ヘッダーやフッターの領域が異常に広く，コントロールのサイズも異常に大きくなっており，レイアウトが大幅に崩れていました。
原因を調べてみたところ，このエラーはフィールド名に記号が含まれていることで起こっているらしいことがわかりました。 Microsoft のサポート技術情報によると，Access ではオブジェクト名やフィールド名に記号を使用することができるらしいのですが，場合によってはそれが予期せぬエラーの原因となってしまうことがあるようです。
Microsoft Access では、データベースのオブジェクト名やフィールド名に番号記号 (#)、ピリオド (.)、または二重引用符 (") などの特殊文字を使用することは制限されていません。ただし、特殊文字を使用すると、予期しないエラーが発生することがあります。
Access は内部でデータを処理する際に一部の記号を特殊な意味を持つ制御文字として使っているらしく，オブジェクト名やフィールド名にそれらの記号が含まれていると制御文字として解釈されてしまい，予期せぬ事態が起こるのではないかと考えられます。
この問題の厄介なところは，全角記号でもエラーが発生することがあるという点です。 今回調べていく中で，中黒や括弧が原因で同様のエラーに遭遇しているケースが多数見つかりました。 初心者はフィールド名に記号が使えないなんて思いもよらないでしょうし，少しコンピュータの扱いに慣れている人でも，半角記号は危なそうだとわかっても，逆に全角記号ならば大丈夫だと思ってしまうのではないでしょうか。
Access で作業する際には，全角・半角を問わず，オブジェクト名やフィールド名に記号は一切使わないほうがよさそうです。
参考資料
Word に Lorem ipsum ... を吐かせる方法
Word の操作説明などをしているときに，適当なダミーテキストを出力する方法です。 いまさら感のあるネタですが，先日授業でちょっと紹介したので，この機会にややマニアックな話も含めてまとめてみたいと思います。
ダミーテキストの出力
基本的なやり方
何も書かれていない行に =rand() と入力して Enter キーを押すだけです。
これでダミーテキストが出力されます。
=rand()
出力される内容はバージョンによって違います。 Word 2007 / 2010 では以下のとおりです。
テキスト量の調整
以下のように引数を指定することで，出力するテキストの量を調整することができます。 第一引数で段落の数を，第二引数で各段落に含まれる文の数を指定します。 段落数だけを指定して，文の数を省略することもできます。 規定値はどちらも 3 のようです。
=rand(段落数[, 文の数])
大きめの値を指定しても，出力されるのは同じ文の繰り返しです。 試しに数えてみたところ，Word 2010 では用意されている文の数は 9 種類でした。
ややマニアックな話
前後や途中に空白文字（タブやスペース）があっても大丈夫ですが，'=' と "rand" の間は詰めて書かなくてはなりません。 一般的なプログラミング言語とは異なり，半角スペースだけではなく全角スペースも無視されます。
また，改行のみが入力されている行に =rand() と打ち込んだ後，Enter キーを押さずに次の行にカーソルを移動してテキストを入力してもダミーテキストが出力されます。
どうやら，タブやスペースを除いて "=rand"，'('，')'，'\n' というシーケンスのみからなる行が出現した際に，その部分をダミーテキストと置き換える処理をしているようです。
ダミーテキストのバリエーション
旧バージョンのダミーテキスト
あまり知られていませんが，Word 2003 以前のダミーテキストを出力することもできます。
=rand.old()
もちろん引数で段落数と文数を指定することも可能です。
古典ラテン語風ダミーテキスト
さらに知られていませんが，ローカライズされていない古典ラテン語風のダミーテキストを出力する機能まであります。 以下のように入力すると，Office のヘルプなどでもよく目にする "Lorem ipsum ... " という文章が出力されます。
=lorem()
やっぱり引数で段落数と行数を指定することも可能です。
PowerPoint でもダミーテキスト
PowerPoint でも =rand() や =lorem() でダミーテキストを出力することができます。
PowerPoint の場合は，=rand() で出力される文章は "The quick brown fox ... " という有名なパングラムの繰り返しです（このパングラムは英語版 Word で =rand() を実行したときにも使用されています）。
The quick brown fox jumps over the lazy dog.
PowerPoint でも引数で出力するテキストの量を指定できますが，=lorem() の場合は少し挙動がおかしいようです。
PowerPoint 2010 では，段落数の最大は 3 で，段落に含まれる文の数は第何段落かによって固定でした。
第一引数の制限はともかく，第二引数が無視されてしまうのは，仕様なのかバグなのかわかりません。
注意点
この機能はオプションの［文章校正］→［オートコレクト］→［入力中に自動修正する］が有効になっていないと使えません。
参考資料
R で日本語入りグラフを WYSIWYG する方法
問題
R でグラフに日本語を使う場合，デバイスごとにフォントデータベースがあるせいで問題が生じることがあります。
たとえば，同じ系統の書体であってもデバイスによって family に指定する値が違ったり，画面にプロットしたものを PDF に保存すると日本語が文字化けしたりします。
文字化けを防ぐためには画面にプロットする段階で family = "Japan1" などと指定する必要があるのですが，画面上ではデフォルトフォントによる描画となってしまいます。
ここでは，画面と PDF でのフォントの指定を統一し，文字化けを防ぎつつ表示もできるだけ一致させる設定を紹介します。 デバイスを意識しながら作業するのは認知的に負荷がかかりますし，フォントの指定を統一できれば出力先を切り替えるのも簡単になります。 また，インタラクティブに作成したグラフをそのまま PDF として保存するためには，画面上の表示と PDF での表示ができるだけ一致していた方が望ましいと考えられます。
方法
各デバイスのフォントデータベースに明朝体とゴシック体のエントリを追加してやります。 エントリは key = value の形式になっており，key が family に指定するフォントファミリーで，value がそのフォントファミリーが指定されたときの描画に使うフォントです。 key に同じものを使用し，value にはデバイスごとに適した日本語フォントを指定します。
設定
.Rprofile でフォントを設定している箇所に以下のような記述を追加します。
setHook(packageEvent("grDevices", "onLoad"), function(...) { ... ## 画面への描画で使用する日本語フォント grDevices::windowsFonts( mincho = grDevices::windowsFont("MS Mincho"), gothic = grDevices::windowsFont("MS Gothic") ); ## PDF への描画で使用する日本語フォント grDevices::pdfFonts( mincho = grDevices::pdfFonts()$Japan1, gothic = grDevices::pdfFonts()$Japan1GothicBBB ); });
画面と PDF それぞれのフォントデータベースに明朝体とゴシック体のエントリを追加しています。 PDF については既存のエントリを単純にコピーしていますが，CIDFont() 関数を使って自分で CID フォントを定義することもできます。
結果
これで family = "mincho" としてプロットすれば，出力先デバイスが画面のときには「MS 明朝」という物理フォントで描画され，PDF のときには「明朝体」という論理フォントの情報が使用されます。
PDF には物理フォントは埋め込まれず，ファイルを開いた際に適当な明朝体の物理フォントで代替して表示されます。
family を指定しなかった場合は，デフォルトのフォントで描画されます。 つまり，画面では Rdevga で指定したフォントが使われ，PDF では .Rprofile で設定したフォントが使われます。
> plot(1:5, type="n") > text(2, 3, "日本語") > text(3, 3, "日本語", family="mincho") > text(4, 3, "日本語", family="gothic") > dev.copy2pdf(file="plot.pdf")
もちろん，par(family = "mincho") でフォントを指定してから描画したり，pdf(file = "plot.pdf") でデバイスを開いて直接描画したりしても大丈夫です。
考察
この方法の欠点としては，コードの汎用性が低下することが挙げられます。 デバイスを切り替えるのが容易になるという意味で描画コードの再利用性は上がると思いますが，他人と共有しづらくなるという意味で描画コードの汎用性は低下します。
R のグラフで日本語を使う
基本的な設定
先人の知恵と努力のおかげで，R でも日本語を用いたグラフが作成できるようになっています。 画面にプロットする場合でも，PDF に出力する場合でも，Rdevga や .Rprofile で適切なフォントを指定しておけば，問題なく日本語を使用することができます。
Rdevga
## 画面のデフォルトフォント TT MS Gothic : plain TT MS Gothic : bold TT MS Gothic : italic TT MS Gothic : bold&italic
.Rprofile
## PDF のデフォルトフォント setHook(packageEvent("grDevices", "onLoad"), function(...) { grDevices::pdf.options(family="Japan1GothicBBB"); ## ゴシック体 });
これだけで，とくに何も意識しなくてもデフォルトフォントを使って正しく描画されます。 なお，Mac OS X や Linux では Rdevga がないので .Rprofile に画面へのプロットで使用するフォントの設定を加える必要があります。
フォントを指定する
デフォルトフォント以外を使いたい場合は，デバイスごとのフォントデータベースを意識する必要があるので少し面倒です。
画面に出力する場合
たとえば，明朝体で描画したい場合，出力先デバイスが画面ならば以下のようにします。
> names(windowsFonts()) ## フォントデータベースの内容を確認 > windowsFonts(mincho=windowsFont("MS Mincho")) ## 「MS 明朝」を登録 > par(family="mincho") > plot(...)
標準では画面用のフォントデータベースには serif，sans，mono という名前の英語フォントしか登録されていません。 まず使用したい日本語フォントを適当な名前で登録し，その後で family でフォントを指定します。
PDF に出力する場合
PDF の場合は，あらかじめ Japan1 などの名前で日本語フォントが登録されています。 明朝体で描画したい場合には，以下のようにします。
> names(pdfFonts()) ## 確認 > pdf(file="plot.pdf", family="Japan1") ## 明朝体 > plot(...)
標準で使用できる日本語フォントとしては，以下のようなものがあります（環境依存です）。
| family | 書体 | フォントファミリー |
|---|---|---|
| Japan1 | 明朝体 | KozMinPro-Regular-Acro |
| Japan1HeiMin | 明朝体 | HeiseiMin-W3-Acro |
| Japan1Ryumin | 明朝体 | Ryumin-Light |
| Japan1GothicBBB | ゴシック体 | GothicBBB-Medium |
画面にプロットしたものを PDF に保存する場合のトラブル
画面にプロットしたものを PDF に保存する場合には注意が必要です。 フォントを指定して画面にプロットしたものを PDF に保存すると，エラーが出て文字が出力されなかったり，警告が出て文字化けしてしまったりすることがあります。
こうしたトラブルを防ぐためには，画面にプロットする段階で family = "Japan1" などと指定する必要があります。
しかし，この場合もやはり警告が出て，画面上ではデフォルトフォントによる描画となってしまいます。
トラブルの原因はデバイスごとのフォントデータベースの内容が異なっているからです。 画面のプロットで使用した family が PDF のフォントデータベースに見つからなかったり，同じ family でもデータベースによって関連づけられているフォントが異なっていたりするために生じます。
