加藤和良 (1984年うまれ) の個人的なブログです。
6月もあまり良くなかった。マクロで「このままではいけない」と思うのが空回りして、ミクロでわるい結果をだしていると思う。
はやいもので、2009年も半年がたってしまった。いろいろふりかえりを書こうと思ったけど、まとめられなかったのであとで。
のこり半年は英語をちゃんとやろうと思う。読み書きの「書き」で固まることがないようにしたい。客観的指標だと TOEIC で C とかなんだろうか。そもそもいまのスコアを知らないのだけど。
私の基本的な主張は「JavaScript は難しくない」だ。ただ、HTML + CSS は難しいと思っていて、それと組み合わせる JavaScript をちゃんと書いたり、書いてもらおうとすると困難は多い。
JavaScript についてよくふれられるクロスブラウザの問題、こまかな差異のあるホスト間で動作するプログラムをどう書くか、という問題は「ソフトウェアの移植性」としてそれなりに歴史のある問題だと思う。JavaScript で「良い」とされる書き方は、たとえば C + UNIX みたいな環境で「良い」とされる書き方と似ていることがある。
例えば、ほとんどのブラウザにある便利な関数が、特定のブラウザにだけ無いときに
if (! Array.prototype.forEach) {
Array.prototype.forEach = function () { ... };
}
みたいなものを書くのと ruby (MRI) の missing/ にあるファイル群は同じことをしている。
また、Object Detection と呼ばれる「User-Agent ではなくクラス/メソッド/関数の有無をみろ」という原則も autoconfぼくらの約束 にある
#ifdef __FreeBSD__を書いて「移植性が高いぜ」とか いばってるのはもう恥ずかしい。未知のOSでも動くように、autoconfで調べて#ifdef HAVE_HOGE しましょう。
と同じことだと思う。
難しいと思うのは Progressive Enhancement, 段階的な機能強化だ。
これは「MMX 命令がある CPU だったらそれを使う」みたいな実行時間効率を一次元で強化するのとは違っている。HTML は文章の構造を、CSS はその見た目を、そして JavaScript はそれにふるまいを与える、という分担は独特で、しかも、その分担がそろわない場合を常に考慮する、というのはわりと酷なはなしだと思う。
「ユーザー体験という観点から見れば一次元だ」みたいなものは単なる言葉遊びで難しさを緩和しないし、3つの分担と「段階的」が理想主義すぎるといわれると確かにそんな気もする。Yahoo! の Nicole Sullivan さんの Object Oriented CSS なんかをみると、JavaScript を足さなくとも、HTML + CSS ですらずいぶん大変なことになっていると思う。
あきらめるひともいる。Cappuccino と Objective-J で 280 Slides を作り上げた 280 North の人々は「Cappuccino は Progressive Enhancement / Graceful Degradation にはできていない」という。
Cappuccino represents a significant shift in attitudes toward web application development. It was designed specifically and exclusively for writing web programs. None of Cappuccino will work in an environment without Javascript. After all, what use would a program like 280 Slides be without its interactive behavior? The program itself doesn’t have any data to display, so there is nothing to degrade to.
Objective-J なんて無理するから…。あー、いや、これはこれで現実的な判断だと思います。ただ、彼らのいう “Web Program” にまで達しているソフトウェアはそんなに無いので、万能ないいわけではない。
結論はとくにないです。
私は HTML 4 や XHTML がわりと好き (HTML 5 は微妙) で、CSS, JavaScript との分担もきれいだとは思う。難しさは一段上の成果物を作ろうとしているのだからしょうがない。ただ、その「上」さをだれがどのくらい評価するかは気にかかる。
私が well-formed, valid な HTML とか、microformats や RDFa みたいな目に見えないものに肩入れしがちなのは、それが自分以外の開発者にバトンを置いておくことだというのがあるけど、そういうことを、例えば 美人時計 を hCard に対応させて顧客の前で説明する自信は無い。あるいは、アクセシビリティで障害者が、みたいな話をするにもそんなに詳しくなく、知りもしない集団を都合良く被害者あつかいするのもどうかと思う。
高い目標とそれを実現するための教育、ってのが王道なんだろうけどね。後者が欠けたときの失敗がこわいというか。いろいろあきらめすぎなのかなあ。
JavaScript自体は難しくないのは同意。加えてHTML、CSSも単体では難しくないと思う。それぞれを組み合わせ、クロスブラウザにしようとすると途端に職人芸の世界に。ところでif (Array.prototype.forEach)は!が抜けてる
ありがとうございます、直しました。単体では難しくないというのは同意します。クロスブラウザは、JavaScript なら既存のライブラリを使えば「職人芸」ほど酷くはないかなあ。職人芸というかバッドノウハウだと思っているので JavaScriptは悪くない で主張されていたライブラリに対する姿勢にはあんまり同意できないです。
dsvn.el をつかうと Emacs のなかから Subversion が使えるようになる。
エディタで編集がおわったら M-x svn-status として、ディレクトリ名をいれる。
すると、そのディレクトリで svn status をしたようなバッファができる。
ここで main.c のある行にカーソルを移動して = を押せば、下に svn diff の結果が表示される。
diff に問題がなければいい。もし変なものが混じっていることに気づいたら、この diff の結果のバッファにカーソルを移して return すれば、その diff のファイルの該当行に飛んで、すぐ編集ができる。
この status, diff, ファイルの編集、とをパチパチ切り替えられるのはかなり便利だと思う。大きめのブランチのマージでも、status をインクリメンタルサーチして M なファイルを確認、C なファイルを編集、と進めていける。
細かい使い方は status のところで ? でヘルプが出てくるので、それを参照してください。
ここからもう応用です。
レポジトリに EUC-JP なものと UTF-8 のものが混じっているような事態のときは svn (1) の出力を lv で変換して diff が化けないようにしている。
まず、こういう svn-with-lv を $PATH の通ったところに置く。$LANG を明示的に指定しているのは Carbon Emacs というか Mac 対策なので、普通の Unix だったらいらないはず。
#! /bin/sh export LANG='ja_JP.UTF-8' svn "$@" | lv | cat
これを dsvn.el が使う svn として指定すればいい。
(setq svn-program "svn-with-lv")
関わっているものに、コミットメッセージに以下のようなパスをいれるルールのレポジトリがある。
[branches/ruby-19] lambda とか長いの書かなくてよくなった
パス部分は機械的に決まるので Emacs にいれさせている。dsvn.el にはやや hook が足りないので advice でなんとかした。
(defadvice svn-commit (around dsvn-commit-with-message activate)
(let ((url (apply 'buffer-substring svn-url-label)))
(cond ((string-match "^.+?:/+example\.org/\\(.*\\)$" url)
(let ((path (match-string 1 url)))
ad-do-it
(insert (format "[%s] " path)) ))
(t
ad-do-it) )))
これで example.org/branches/… にコミットするときは [branches/...] と入力されかけたバッファが開くようになる。
All articles are written by 加藤和良. A few are written in English.