進・日進月歩

ブログお引っ越し

harajune — Tue, 13 Sep 2011 08:59:51 +0000

wordpressのwysiwygがあまりすきではなかったのでmarkdownで書くために微妙にURLかえましたw

特に書くことも無いのだけど、最近書いたコードとかやってる実験や興味のあることをちょこちょこまとめて書いてみたいと思います。

新アドレス: http://blog.gijutsuya.jp/hrjn/

XSS対策手法のひとつの提案

harajune — Fri, 19 Nov 2010 06:38:01 +0000

ドラフト。ドラフトじゃなくなることはあるんだろうか。コメント求む。

XSS対策手法のひとつの提案

概要

XSS (cross site scripting)というのは、特にwebプログラミングの文脈でよくつかわれる、セキュリティホールの一種である。webプログラミングが一般的になった現在でもこのセキュリティホールは頻繁に発生しており、必ずしも素人だけがしてしまう失敗とも限らない。近年で有名な例としてtwitterでの事件がある。

>本投稿では、XSSの事例と背景について説明するとともに、その対策として「コンテキストを減らす」「コンテキストごとのエスケープ」「安全なプログラミングの手法」を示しひとつのXSS対策の指針を示す。

また最後に、もともこもない対策方法として「base64で対策したらこうなった」という話をする。

本投稿は、「安全な」対策方法としてはまだ開発段階にあり、鵜呑みにするのは危険であることをご了承いただきたい。自己責任。

XSSとは
XSSの原理と背景：コンテキストとエスケープの関係
XSS対策が困難な理由と、その対策
コンテキストの削減
コンテキストごとのエスケープ
安全なプログラミング指針
すべてをhtmlエスケープしてしまうfail safeの欠点
もともこもない対策： base64
まとめ

XSSとは

XSSとはCross Site Scriptingの略であり、掲示板などのユーザ投稿型のwebサービスに対して「悪意のあるスクリプト」を投稿し、開発者の意図しない動作をさせるセキュリティーホールの一種である。

Smartyテンプレートとphpでの具体的な例を挙げる。以下の様なtest.phpとtest.tplがあったとする。ここでは、簡単のため必要なrequireや定数・変数の定義などは省いている。

PLAIN TEXT

CODE:

// test.php
$smarty = new Smarty();
$smarty->assign("value1", $_GET["form1"]);
$smarty->display("test.tpl");
?>

PLAIN TEXT

CODE:

{* test.tpl *}
{$value1}
"." method="get">
"text" name="form1">"submit" />

この例では、例えばform1に次の値を渡すとjavascriptが実行される。

PLAIN TEXT

CODE:

本来であれば、適切に文字列が処理されform1の文字列は、文字としてブラウザに表示されなければならない。しかし、適切な文字列処理が行われていないためブラウザ上では下記の様なHTMLとして解釈され、開発者の意図してないjavascriptが実行されてしまう。

PLAIN TEXT

CODE:

"." method="get">
"text" name="form1" />"submit" />

このように、適切な文字列処理が行われないまま出力された値をブラウザが解釈することで、開発者の意図しない動作を発生させる脆弱性のことをXSSと呼ぶ。上記はその一例である。

なお、本投稿では筆者の主たる開発環境のなかで一番一般的であると考えられるPHPとsmartyテンプレートで考えるが、全ての言語・テンプレートで共通のことがいえる。

XSSの原理と背景：コンテキストとエスケープの関係

XSSを防ぐ一番一般的な方法はエスケープという文字列処理である。例えば先ほどの例では、以下の様なエスケープが行われる。

前：

↓

後：<script>alert("XSS!");</script>

ここでは、HTMLのメタ文字である「<」や「>」を「<」「>」に変換している。ここでいうメタ文字とはあるプログラムの文字列中で特殊な意味を持つ文字のことである。<や>はHTMLではタグを示す特殊な文字であり、これらはHTMLのメタ文字である。これらを文字列として解釈させるための変換をエスケープと呼ぶ。

また、ここでコンテキストという概念を導入する。コンテキストとは、プログラム中の注目している領域の文字が何であるかを示すものである。例えばHTMLでは、以下の様なコンテキストが存在する。

PLAIN TEXT

CODE:

ここは「HTMLの文字列」のコンテキスト

他にも、様々なコンテキストが存在する。

XSSの原因は、コンテキストに対して適切なエスケープがされていないことにある。先ほどの例では、「HTMLの文字列」のコンテキストでHTMLのメタ文字をエスケープ出来ていなかったためXSSが発生している。HTMLのメタ文字である「<>」をエスケープしHTMLの文字列のコンテキストに合わせなくてはいけない。

つまり、ひとつのコンテキストの中にメタ文字を含めるとXSSが起き、メタ文字をエスケープして文字列の中をひとつのコンテキストにすることでXSSが防げる。

XSS対策が困難な理由と、その対策

XSS対策を困難にしている理由として、筆者は「コンテキストの多さ」と「コンテキストごとのエスケープが提案されていない」ことに注目する。

コンテキストは先ほどの単純なHTMLの例でも多数存在することがわかる。筆者が思いつく限りでも以下の様なものがある。

HTMLの文字列
HTMLの属性値
HTMLタグ中のURL
Javascript
Javascriptの文字列
CSS
Javascriptのdocument.writeでの書き出し時
Javascript中でのURL

このコンテキストごとにメタ文字が存在し、それぞれに対して適切なエスケープ処理を行う必要がある。

しかし、PHPやsmartyでは十分なエスケープ関数が提供されていない。むしろ、「HTMLの文字列」に対するエスケープ関数しか無いといえる。そのため、エスケープ関数を通しているにもかかわらずXSSが起こる。

例えば以下の例がある。引用。

PLAIN TEXT

CODE:

// HTML

上記の様な例では、$fugaに代入されている文字列の末尾にバッククオートを挿入することで、XSSを行うことができる。Smartyにはjavascriptの文字列のコンテキストでのエスケープ処理が存在するが、この例では適切なエスケープ関数を選択しないことでXSSが起きることを示した。

このように、コンテキストが多数存在するため初心者にはそれが判断しにくくなっている。また必ずしも適切なエスケープ関数が用意されているとも限らないため適当なエスケープ関数を選んだり、適当に組み合わせたりする開発者もいるようである。

このような状況がXSSの対応を難しくしていると考えられる。

そこで、筆者は「コンテキストの削減」と「コンテキストごとのエスケープ」を提案する。

コンテキストの削減

XSSを議論するとき、エスケープばかりに目がいき勝ちであるが、今までの議論で述べた通りコンテキストの多さが混乱を招いているという一面がある。そこで、この混乱を回避するために、以下のコンテキストに絞り込むことを検討する。今回は特にPHP、smartyテンプレートでHTMLを出力することを考える。

HTMLの文字列 (ここ)
javascriptの文字列 (var hoge="ここ";)
HTML中のURL ()

javascript中のURL ($.get("http://hogehoge.com/ここ"))

（ここでこれに絞り込む根拠を書きたい。一言でいうと、これ以外は大体プログラミングの努力でどうにか出来る。）

ここで以下の様な場合に注意したい。

PLAIN TEXT

CODE:

この例は、HTMLとして出力される予定の部分にsmartyで値を埋め込む場合である。これは文字列中にのみ注目した場合「HTML」のコンテキストと「HTMLの文字列」のコンテキストが混在してしまっている。つまりこれは単純な「javascript中の文字列」のコンテキストではなく、新たなコンテキストである。

この例では、dom操作で同等の処理ができるためコンテキストを増やすこと無く対処できる。

この例の様に一見して同じコンテキストに見えるものでも、実際は異なる（二種類以上のコンテキストを混ぜている）場合があるため注意が必要である。そしてここが非常に難しいため文字列連結などには注意が必要である。

また、「javascriptでのdocument.writeでの出力」や「innerHTML」などのコンテキストの必要を主張する読者もいるかもしれないが、多くの場合DOM操作での代替が可能でありdocument.writeが必要な場面は限られる。従って、これらは使うべきではないし、使う場合は知識豊富なプログラマが行うべきである。

コンテキストごとのエスケープ

上記で定めたコンテキストごとのエスケープ処理について議論する。筆者は上記のコンテキストごとにひとつのエスケープ関数を用意している。先に議論した通り、コンテキストごとに必要なエスケープ関数はひとつである。この例の様にhtml,jsなどの複数のエスケープ関数をカスケードして処理することも不可能ではないが、次の理由から筆者はおすすめしない。

もしjsの関数にバグがあった場合、jsを利用している全箇所に影響が出る。js関数が複数のコンテキストで使用されていた場合、かならずしも複数のコンテキストで正しく処理できることを保証することはできないため、全箇所で動作確認をし直す必要がある。したがって、エスケープ関数はひとつのコンテキストごとにひとつ用意すべきである。

それぞれの具体的な実装について議論したい。

（したいといいつつ、自分の関数さらしていいいものか判断しづらいので、今度書く）

安全なプログラミングの指針

ここでは、XSSに対して安全でシステムを壊しにくいプログラミング手法について議論する。

筆者がおすすめする方法は以下である。

データはできるだけ生の状態で変数に格納する
出力時に必ず適切なコンテキストのエスケープをひとつする
どうしても必要な時をのぞき、dom操作以外のjavascriptからの出力をしない

データを生の状態で変数に格納する理由は、先の説で述べたのと同様に、コンテキストごとの適切なエスケープが困難になるからである。これについては次節で例をあげて説明する。

出力時には、必ず適切なコンテキストのエスケープをひとつだけ行う。複数のエスケープを行うと問題が起こる可能生を前説で説明した。エスケープを忘れることは論外であるが、これについてはコミット時やデプロイ時にフックでチェックする方法が多く存在する。またsmartyを改変しエスケープ関数がついていないとエラーを出し知らせることも行われている。

dom操作以外のjavascriptからの出力をしないことについても前説で議論した。多くの場合、javascriptからの出力はdom操作に代替可能であり、textnodeを作りテキストで出力することでXSSを防げる。

すべてをhtmlエスケープしてしまうfail safeの欠点

これはここで提案されている方法である。以下に引用する。

ちなみに自分は、文字列テンプレート+innerHTMLというのを好んで使うので、自社サービスに付いてはサーバー側であらかじめエスケープされているJSONを使うのを好む。これはJavaScriptで余計な文字列処理をしなくていいというメリットがある。

簡単にいうと、javascriptに値を渡した段階でhtmlエスケープされている状態にしておき、javascriptで全くエスケープ処理をしなくても大丈夫な様にする処置である。つまり何も考えずにdocument.writeを実行しても安全である。

この方式の欠点は、document.writeをする場合以外ではhtmlエスケープを元に戻す必要がある点である。例えば、ajaxに値を渡す場合やjavascript上で文字列処理をする場合などである（後者はあまりないかもしれないが）。php上でのエスケープ処理を把握し、逆エスケープ処理をjavascript上で構築する必要があり保守性の低下やバグの温床になりやすい。もちろん、サイト構築時のポリシーや設計次第では有効であるが、汎用的な解決策であるとはいい難い。また、すでに構築済みのサイトである場合ほかのエスケープ処理とバッティングしやすく、導入が困難である場合が多い。また、この方法で設計したサイトを後に変更することも同等に困難であり、設計の柔軟性が損なわれる。

先に議論した通り、多くの出力操作はdom操作に代替可能であり、差し迫った必要がない限りはそもそもエスケープする必要がない。

この手法は初期開発時の設計次第では大変有効ではあるが、dom操作の有用性や既存のシステムへの導入の困難性、システム変更の困難性から、あまりおすすめできないと筆者は考える。

もともこもない対策： base64

これまで、コンテキストとエスケープの関係を議論してきた。XSS対策の困難さはコンテキストにあったエスケープ手法を選択できないところにあることを示した。

ここで、筆者が最近諸事情でとった手法がbase64でエンコードしてしまう手法である。実はbase64で値を埋め込みjavascriptやphpのそれぞれでデコードすれば多くの場合は安全になるのである。もう一度XSSの起きやすいコンテキストについて考えてみよう。

PLAIN TEXT

CODE:

var hoge = "{$hoge|base64_encode}";

多くの場合がこれの類型であり、ダブルクオーテーションで囲まれている範囲内に特定のメタ文字を挿入することでXSSを起こすようになっている。一方でbase64の文字種を見てみよう。

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789/+=

htmlやjavascriptで危険な文字種が一切現れない。これを受け取った側でdecodeすれば、XSSの危険性を減らしながら生データを扱うことができることがわかる。URLセーフでない文字列も存在するが、これには代替があるためURLセーフにすることも可能である。

つまり、コンテキストがわからないならbase64エンコードしてしまえば、少なくとも値の受け渡しで失敗することは激減する。javascriptの出力側でdocument.writeや値の連結について注意すればXSSの問題はほぼ起きないと筆者は考える。

base64は、その変換ルールからデータのサイズは必ず4/3倍になることが知られており、データサイズの管理も簡単である。また、変換ルールは単純であるため効率よく変換もできる。

base64を使えば100%安全ということはあり得ないが、細かな詳細な議論ができない環境では有効である。

まとめ

本投稿では、XSSの対策や包括的理解をすすめることを目指し、その対策に対する考え方や施策のひとつを提案しました。

まず、XSS一般についてふれ、その原因や背景について述べました。コンテキストという概念を示し、それとエスケープ処理の対応について述べました。そして、コンテキストを絞り込みそれぞれに対してひとつずつエスケープ方法を用意するというシンプルな考え方を提案し、それがXSSに対応できることを説明しました。

個人的には「なんで今さらXSSなの？」といわれそうだなとも思ったんですが、直近でこのことで大変もめた経緯があり、また、結局包括的な説明などがあまりない状況をどうにかした方がいいだろうなと思いブログ記事にしました。

長文過ぎるので、「単純なハウツー」を求めている人には役立たないかもしれないですが、みなさまの勉強の役にすこしでも立てればなと思います。

本当は怖い3×5!=5×3

harajune — Tue, 16 Nov 2010 07:01:11 +0000

ネタもと404 blog not found 3x5!=5x3

ここ最近よく話題になっていたので、なんとなく見ていたのだけど、ネットのほとんどの人は「交換してもマルでいいじゃないか」「これで誤答扱いはひどい」と思っているようです。
個人的には、これらの指摘こそひどいなぁと思って、久しぶりにブログ書いてみました。

主な論点は、4つ。

「文章題」は、問題文の理解を問うている
書式のなってない報告書・レポートは正当化されない
書式に理由なんかない
じゃぁ3x5は5x3でいいのかなぁ？

「文章題」は、問題文の理解を問うている。

じぶんも実はこれにひっかかりました。というか、もっとひどかったかもしれません。
なにしろ私は、式すら書かず答えしか書かなかったのですから

「皿が5皿ある。1つのお皿に3つずつりんごが載っている。全部でいくつか。」

答え：15こ

小学生でもこのくらいの暗算は出来る人はいると思います。しかし、当たり前ですが減点対象です。当時小学生だった私は納得いきません。「答えは合っているのになんで減点されなくちゃいけないわけ？」あぁかわいく無い俺。

「3x5でも5x3でもいいじゃないか！」と言ってる皆さんは、もちろん「式なんか書かなくたっていいじゃないか！」というのにご賛同いただけると信じております。

冗談はともかく。

そのとき先生に言われたのはこんな感じのことだったと思います。

はらだくんが暗算得意なのは先生もよくわかっているよ。けど、この問題は「問題文がきちんと理解できているか」も点数になるの。だから、問題がきちんとわかっていることを書いてくださいね。

まぁこんなので納得する私ではないので（自分のことながら恥ずかしい・・・）、この後「かける数かけられる数の順番が違う」だとか「15この『こ』が抜けてるので減点」とか、ことあるごとにひっかかり、その度ごとに先生につっかかり偉い迷惑かけました・・・・いや、まじですみません・・・・

けど、今から思ってみれば、「問題の意図をつかみ」「相手に正確に伝える」ことの重要性から納得できるなと思います。

書式のなってない報告書・レポートは正当化されない

今時は、大学のレポートなんかろくに返却されないし、返却されても見ない人がほとんどかもしれません。まぁ私は取りにすら行きません。（死
そんなある日、某教授から「最近の若者の国語教育がひどい」という話を聞かされました。

だいたいこんな感じの内容でした。

言葉というのは時代とともに変わるので、言葉遣いがおかしいのはまだ我慢できなくも無い。しかし、論理展開や書式があまりにも稚拙でそれが我慢ならない。

国語教育は情操教育という理念の元に、感想文ばかりかかせる。そのせいかわからないが、感想文のような文章ばかり提出される。

えぇっと死にたくなりました私・・・・・・

もちろん良識ある社会人の皆様なら、報告書や論文の書式の重要さは十分に理解されてることでしょう。けど、参考までにいくつかURLを列挙しましょう。

あまり思い出せなかった・・・・けど、この2つをみれば「内容の重要性」と同じくらい「書式」が重要であることがわかるでしょう。
むしろ、「書式が整ってないと重要であることが伝わらない」ことすらあり得ます。

書式というのは「読む側」になるとその重要性がわかります。不真面目ながら院生をしている私もたくさんの論文に目を通すので必然的に似通ったフォーマットに慣れてきます。
そうすると、なんとなく効率的に読む方法が見えてきます。
しかし逆に書式に従ってない論文というのはものすごく読みにくいことがわかります。

プログラマの人にわかりやすい例を考えてみました。JavaとかPHPのドキュメントは優れてると思いませんか？なんででしょう。
それは、各メソッドが全ページにわたって同じ書式で書かれているからな気がしませんか？

書式に理由なんかない

あるのかもしれませんが、生まれてから27年納得のいく理由を聞いたことがありません。
もちろん内容に合わせて、項目が設定され、項目ごとにそれなりに合理的なスペースが割かれているのですが、詳細なレベルでは学会やドキュメントなどによってまちまちであると思います。

じゃぁ3x5は5x3でいいのかなぁ？

もちろん数式としては等価なわけですね。けど、あの文章題の答えとしてはどうでしょうか？
当時小学生だった私は、先生に「私は、リンゴと皿の関係を理解し、正しく式に直し、そこから答えを導きだせました」ということを示さないといけなかったわけです。

それにはまず、「3x5」という共通の書式で式を立てる必要があるわけです。この書式が守れてないと「この人は数字を適当に拾ってきてかけただけなんじゃないか？」と解釈されても文句は言えないと思いませんか？

まとめ

文章題というのは、まず「問題の理解」を問うていることをお話ししました。
そして、それを伝えるためには「書式」が重要であること、そして「書式」に理由をもとめることは難しいことをお話ししました。

正直な感想を言えば「3x5とかそんなのどっちでもいいよなぁ」とも思うわけです。しかし、昨今の諸先輩方の「若者の文章が崩壊しすぎててヤバい」というのを聞いたり、たくさんの書類／文章を見ているうちに、この「3x5」に潜む本質的な問題というのに恐怖を覚えずに入られませんでした。

終わりに

この文章は感想文です。

あと、教育指導要領とかもよく知りません。ただ、「どっちで書いても同じ」というのは「適当な書式でレポート書いてもいい」というのと同じな気がしますし、それは一般社会では受け入れられないということを言いたかっただけです。

rubyが激しくメモリを消費する件

harajune — Tue, 28 Sep 2010 08:08:50 +0000

rubyが激しくメモリを消費する件についてです。

だいたい以下のような感じのコードを動かしていたのですが、あっというまにbad_allocを吐いて落ちる。

PLAIN TEXT

CODE:

while 1
doc = Nologiri::HTML(text)
# 何かの処理
end

topを見ていたらメモリを消費する消費する・・・・・

しょうがないのでこういうコードを付け足しました。

PLAIN TEXT

CODE:

while 1
counter += 1
doc = Nologiri::HTML(text)
# 何かの処理
doc=nil
GC.start if counter % 10 == 0
end

これで大分マシになりました。
けどこれでも少しずつメモリを浸食してる。
ううーむ。

構造化テキストと文法と言語

harajune — Thu, 23 Sep 2010 07:16:54 +0000

最近twitterでXSSによる攻撃があって大騒ぎだったというのがよく話題になっているようです。

自分も実は某社でwikiのような記法を使って記事が書けるwebサイトを作っているのですが、よく考えないで正規表現でごりごり実装したのでXSSを連発して苦い経験をしました。

そこで今日は、文法とか言語についてだらだらと書きます。
（ちなみに計算機系の学部では、授業で形式言語とか正規文法とかならうと思いますが、それです。）

wiki記法は文脈自由文法だと思ってパースした方がわかりやすいかも？

結局記法パーサをど根性で正規表現を駆使して書いたんですが、よく文法構造を考えてみればもっと簡単にパースが出来ただろうことに最近ふと気づきました。

細かい話は端折りますが、大抵のwiki記法というのは文脈自由文法というもので表現できそうです。
文脈自由文法で生成される言語というのは、正規表現では記述できない文があるので、どうしても無理矢理な実装になってしまうようです。（チョムスキー階層）

文脈自由文法と正規表現をメールアドレスを例にわかりやすく書いてる記事があったのでとりあえずそれをご紹介。

正規表現よりも文脈自由文法を

なるほど。確かに入れ子構造とかがあると正規文法よりは文脈自由文法であると考えた方がみやすそうです。（ただしメールアドレスは正規表現だけでかけるようです。）

wiki記法には、例えばテーブル要素などの、入れ子構造を持ったものがあるので正規表現だけでごりごりやっていくのはなかなかに難しそうです。

twitterの文法は何だろな

で、twitterなんですが、基本的に入れ子構造がない文法なのであれはどうやら正規文法である気がします。
なので基本的には正規表現ですっきり記述可能なはずです。（※一行の正規表現でかけるという意味ではありません）

一般的な構造テキストの解析の仕方

構造化テキストの間違ったエスケープ手法についてや(Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法についてでも軽く触れられてますが、もうちょっとはっきりまとめるとこういう風につくるのが一般的である様に思います。コンパイラのつくりに似てる気がする。（ある意味これもコンパイルなわけですが）

字句解析（トークナイズ） : 文字列をトークンに分割
構文解析（パーサ） : トークンに文法を元に構造を持たせる
出力生成

ちょっとコードを書くのが面倒なので(Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法についてから拝借します。

PLAIN TEXT
CODE:




my $html = '';


for my $token (split m{(http://[0-9A-Za-z_\.\%\?\#\@/]+|\@[0-9A-Za-z]+)}, $tweet) {


    if ($token =~ m{^http://}) {


        $html .= '<a href="' . encode_entities($token) . '">'


            . encode_entities($token) . '</a>';


    } elsif ($token =~ m{^\@(.*)$}) {


        my $user = $1;


        $html .= '<a href="http://twitter.com/' . encode_entities($user) . '">'


            . encode_entities($token) . '</a>';


    } else {


        $html .= encode_entities($token);


    }


}

このコードで説明をすると、for my $tokenの行が字句解析にあたり、そのあとのif, elsif, elseの部分が構造解析と出力生成になっています。

ところで、さっきtwitterの記法は正規文法らしいとかきました。
その意味するところは、凄くおおざっぱに言えば、左から順番に解析していけばいいということです。
つまり、処理したトークンをあとで後方参照する必要がありません。

実際先ほどのコードを見てみると、分割したトークンを順番に処理していけばいい形になっているのがわかるかと思います。

結論

最近自分で実装したwikiパーサで結構後悔してたのもあるんですが、余程ややこしい記法でも、大概の場合、文法を意識して字句解析・構文解析をすればすっきり解析できる様に思います。

もし独自の記法をつくりパーサなどを実装することなどがありましたら、ぜひこういったことを思い出してつくってみてください。

※追記：
なんか「エスケープが間違ってた」的な話が多い気がするのだけど、個人的には字句解析とか構文解析の失敗であって、別にエスケープは失敗していない様に思う。
わかりやすく言えば、エスケープ関数にエラーはないわけで（多分

面白くなるために必要だと思うこと

harajune — Tue, 14 Sep 2010 11:08:51 +0000

先日twitterをやめたんですが、割りと大きな理由としては、皮肉っぽい発言が多い私がtwitterを使うと敵ばっかり増えて粘着されて（自業自得）気分も悪くなるからだったりします。

けど一方でtwitter見ててもあまり面白く無いなぁと思ったのもあります。
その上、色々考えた結果、あんまり俺も面白いこと書けなくなってるなぁと凄く自省しました。
（もとが面白かったかは知らないけど・・・・多分いまよりは大分ましだった気がする）

書かなくなった

で、それはなんでかなぁと考えたんですが、原因のひとつには「書かなくなった」ことである気がしました。

以前は一日中プログラム書いたり、文章書いたりメール書いたり一日中してたんですよね。
半分は受託開発関連だったので、必ずしも好き好んで書いていたわけではない（HTMLとCSSは未だに嫌い）ですが、今と比べればそらもう一日中怒濤の様に何か書いてました。

なんで書くと面白くなれるのか

プログラミングでも文章でも色々書いたりして、そのために色々調べたりすると色々と小ネタがたまるんですよね。
javascriptのブラウザ間の差異を吸収するためのbad know-howとか、railsの中見てみたら"Spellだらけ"でよくわからなかったとか。
ビジネスプランを書いていれば、送金事業の規制緩和に関する法律改正とかにくわしくなったりとか。
こういうのをブログのネタにしたり、飲み会で話したりとかすると結構これがウケるわけです。

なんでそれがウケるのかというのをちょっと考えてみました。
たぶんそれはこういう理由からだと思います。

ひとつの目的に沿って色々なことが調べられているから
根拠がしっかりしているから（単に私が思っただけではない！）
もしくは、少なくとも個人の体験に沿った事実であるから
大なり小なり系統的に調べた/経験した立場から、聞いてるひとにとって新しい情報を与えることができるから

つまり、何か目的を持って「書こう！」と思い、様々なことについて体験したり調べたりしたことは、単なる思いつきの感想文よりは面白い何かを含んでいるということなんだと思います。

久しぶりに書いてみると、これが意外に難しい

色々言ったみたものの、この文章は基本的に感想文なんですが（ぉぉ

じゃぁちょっと、まとめて特定のことについて書いてみようかなと思って筆を執ってみたんですが、実にこれが結構難しい。
最近だと、某会社に長く関わってるので開発上の注意点みたいの（デプロイどうしようとかタスク共有どうしようとか）は色々と事細かに語れますが、それ以外のことは中々難しいなと感じました。
そういえば、シュウカツの面接でこれプレゼンしたら大分感心されたので、きっとそれなりに面白かったんでしょう。

結局どういうことなのかと言えば、目の前に起こっている問題に対して自分なりに仮説を立てて本を買ったり対策を講じていたり、プレゼン資料を作ったりしていたのです。
そういう「書く」努力をしていたことに対しては、割りと容易に面白いことがかけるのかもしれないなという風に思いました。（トートロジーですが　苦笑）

面白いひとになるためには普段から書く癖を付けよう

結局おもしろい人間になるためには普段から物事を書く習慣をつけ、調べたりまとめたりすることが必要なのかなということを9月3日くらいに思いました。

書くというのは何も文章ではなくても良くて、プレゼンだったりプログラムだったりスピーチだったり、そういう特定の目的にそってまとめあげる形のものが良い様に思います。

すくなくとも、私が「これは面白いな」と感じるものはニュースサイトやはてブのURLをコピーして140文字程度の感想をつけたものではないようです。
その人の興味や関心に基づいて、少なくとも2つ以上の情報源を元に、一定上の時間をかけてある、感想以上の知見を得られるものです。

何となくそう言うことを思いました。

参考リンク

文章力向上のための10の基本的心構え

Dangerous Ideas: Getting Started is Overrated

最近始めたこと

修士論文を真面目に視野に入れ始めたというのもあるのですが、プライベートなpukiwikiを作って、そこに色々なネタを書き貯める様にし始めました。

基本的に「日誌」を毎日簡単に書き、特定の関心事には個別のページを作り#relatedでまとめて行く様にしています。

まだ効果が出てるのかは謎ですが、きっとtwitterにバラバラ書いていることよりは面白いことをたくさん書いている気がします。

shでスクリプトの実行ディレクトリを取得する

harajune — Tue, 31 Aug 2010 02:58:34 +0000

bashでスクリプトのあるディレクトリの場所を取得する方法です。

rubyで言うところの

File.dirname(File.expand_path(__FILE__))

を、bashでやりたかったのですが、今まで適当に誤摩化してました。こたえはこちらにありました。

Bashシェルスクリプトで自分の絶対パスを取得

echo $(cd $(dirname $0);pwd)

shの理屈はよくわかってないのですが、どうやらこういうことのようです。

かっこ()内はサブシェルになるらしく、cdしても外側には影響がない
$は括弧内の出力を文字列として展開する

なるほどなるほど。

追記：

と、思ったんですが、$()が単にバッククオートと同じ動作をするということっぽいです。単純に左右の対応がとれるので、バッククオートを入れ子にするようなややこしい事をするよりは簡単みたい？

X window を ssh 経由で止める

harajune — Thu, 26 Aug 2010 11:48:58 +0000

修論に向けて大学にPCを持ち込んで実験環境を整えたのですが、自宅からsshでこれにアクセスして続きをしたりしています。

で、なんとなくメモリを見てみたら、相当X関係がメモリの無駄遣いをしている（様に見える

実際はcacheなので気にすることもないかなぁと思ったのですが、いらないので終了させてみました。

sudo /etc/init.d/gdm stop

これでOK。

ちなみに、モノは試しでcacheをクリアするには。

echo 3 > /proc/sys/vm/drop_caches

でいけるらしい。

ruby 1.9.3 で readline6 を使ってコンパイルできない

harajune — Sat, 21 Aug 2010 12:55:06 +0000

なぜか以下の様になって出来ない。

ext/readline % ruby extconf.rb

checking for tgetnum() in -lncurses... yes

checking for readline/readline.h... no

checking for editline/readline.h... no

checking for tgetnum() in -lncurses... yes

checking for readline/readline.h... no

checking for editline/readline.h... no

extconf.rbを開いてみたらオプションを発見したので試してみたらこれでいけた。

ext/readline % ruby extconf.rb --enable-readline-v6

これで解決。

Vim7.3 が Mac でコンパイルできなかったのでpatchを書いた

harajune — Wed, 18 Aug 2010 03:43:24 +0000

たぶん、--enable-multibyte をつけるとiconvが呼ばれる（？）らしく、そのときにコンパイルがこけます。

ので、簡単なパッチを書きました。

もし困ってる人がいたらご利用ください

# よくよく使ってみたらSEGVしまくるので、あまりオススメできないかもしれないです