JSTDD Intro followup for kanazawa.js v1.7

Apr 09, 2012

Q.『テスト駆動JavaScript』は必読？

kanazawa.js はデザイナの参加も多いので、個人的には『テスト駆動JavaScript』はオススメしません。いい本だと思いますがガチエンジニア向きです。

JavaScript そのものの話が完全にガチ
Java アプリを KUROIGAMEN から起動できて当たり前

など、ハードルは高いと言わざるを得ません。

同時に、この本で使う jsTestDriver もオススメしません。準備もやや面倒だし、サーバとかクライアントとか意識しなくちゃいけない。

js-test-driver - Remote javascript console - Google Project Hosting

もちろん jsTestDriver 自体はよいツールです。

コマンドラインから自分の好きなタイミングでテストを実行可能
しかもキャプチャしたすべてのブラウザで同時にテスト可能
複数のブラウザのテスト結果がすべて自分の手元に返ってくる

ここら辺はフロントエンドエンジニアにはとてもオススメなのですが、こういう環境に慣れていない人の JSTDD の入り口としては厳しい気がします。

あと個人的には jsTestDriver は生で使わずに npm にある jstestdriver-wrapper で使う方が楽でいいと思います。（結局 KUROIGAMEN だけど）

問題はあとから jsTestDriver の恩恵に与れるかどうかだと思うのですが、できます。jsTestDriver には各種 adapter があるので

[QUnitAdapter - js-test-driver - Run QUnit tests using JS Test Driver
- Remote javascript console - Google Project Hosting]4
ibolmo/jasmine-jstd-adapter

例えばすでに QUnit や Jasmine で書いたテストがあったとしても、複数のブラウザを効率的に検証したいときだけ jsTestDriver を使う、といった活用も考えられます。

もちろん jsTestDriver に慣れたから昔のテスト書き直すわーっていうのもアリだと思います。最初の選択、導入をしっかりやるのも大事ですけど、どうせ変化するのであればさっさと始められる方が個人的にはよい気がします。少なくとも最先端を突っ走らなければ失敗の可能性は減らせます。¹

Q. 他のフレームワークは？

2011年後半辺りは

の名前をよく聞いた気がします。Vows は思いっきり node.js って書いてあるのでブラウザの話と合うのか疑問なのですが、mocha はブラウザもサポートしてますね。

あと、テスト込みのフレームワークもあるので、その場合は付属のものを使った方がよいと思います。

なんかが代表でしょうか。

これまで jQuery くらいしか使っていないのなら QUnit や軽めのものでもよいでしょうし、大きめのフレームワークを導入してより本格的なアプリを組む場合は採用するツールの作法に従うことになると思います。

すいません、超無難な感じで。

jsTestDriver, QUnit, Jasmine すべて最先端ではありません。すでに実績があります。 ↩

高橋メソッドに真面目に水をさす

Apr 09, 2005

Tool

高橋メソッドの紹介が流行っているようなんだけど、どうにも腑に落ちないので疑問を呈することにした。それは、「文字がでかすぎて逆に分かりにくくないか？」という一点。これは自分がスライドに求める機能が2つあるからなのだけれど、とりあえず最初から順を追って読んでみてほしい。

技術者を名乗るならプレゼンも設計として捉えよう。プレゼンの設計で気にしなければいけないのは

内容
時間と分量
分かりやすい提示
分かりやすい喋り

なわけだけど¹、高橋メソッドは「スライド作り」における技法だと思っている（というかライブで見たことない）ので、「分かりやすい提示」だけに集中して考えればよい。

では「分かりやすい提示」とは何か。これは

資料としてのスライド
インターフェイスとしてのスライド

の両方を考える必要があるだろう。

資料としては表やグラフなどがこれに当たる感じがするが、これをもう少し広げると要するに「一覧性」と言い直すことができる。例えば

高橋メソッドの特徴

(1)巨大な文字
(2)簡潔な言葉

というスライドはただの箇条書きだけど一覧性があり、高橋メソッドを説明する際の資料として十分使いものになる。

インターフェイスというのはちょっと苦しい言葉なんだけど、例えば資料性を高めるために30行の箇条書きを1枚のスライドに収めてもとても読めない。これは印刷した際には資料として使えるが、プレゼンの現場では伝えたい情報と聞き手のインターフェイスとして失敗している。では「ぱっと見て分かる」ということなのかというと、そうとも言いきれなくて、アニメーションなんかもインターフェイスに入る。アニメーションは結果だけ見ても意味がなく、その動作中注視している必要があるので「ぱっと見」を定義にすると外れてしまうのである。もちろん効果的なアニメーション以外は失敗だし、基本的には失敗事例の方が多いと思う。例えば1つのスライドに10個もアニメーションが入っているようなものは失敗と見て間違いないだろう。例え結果として適切な情報量になっていてもやりすぎである。同じように全部のスライドで同じアニメーションを使うのもダメ。飽きる。飽きさせたらプレゼンは負けだ。

高橋メソッドは上の2つのうちインターフェイスの方に、つまり、詰め込みすぎて分かりにくいスライドへのアンチテーゼとしての手法に重きが置かれている²。しかし「高橋メソッドについて」を見ていると、「資料としては分かりにくい」と感じないだろうか。言い方は悪いがインパクト勝負になってしまっている部分があり、肝心の要点がどこにも整理されていないという悲しい状態になってしまっている。

そこで

頭と尻にちゃんとまとめを入れろ

と言いたい。例えば利点についての説明では、個々の利点を説明する前に、このようなまとめのスライドを入れるべき。

高橋メソッドの利点

(1)見やすい
(2)表現が簡潔になる
(3)発表しやすい
(4)聞くのに集中しやすい

これを見せたあとに、順番に個々の項目について補足していくという流れにした方がぐっと分かりやすくなる。

しかし高橋メソッドの特徴である「無駄にでかい文字を利用する³」というポイントだけに執着すると、たったこれだけの情報量でも1枚のスライドに収めるのは難しくなる。

同じように全体の流れについても適宜まとめのスライドを入れていくべきなのだが、全体を見て思うのは高橋メソッドは「まとめの提示に向いていない」ということである。なんというか、例えば「ls -la と叩いても4つしかファイルが表示されないくらいに terminal が狭い」みたいな扱いにくさを感じるのだ。分かりやすさのためにはある程度一覧性が必要だと思う。

修正高橋メソッドの登場に期待したい。

余談だけど、プレゼンの装置の設計も大事。今回の話の流れで言えば「会場とスクリーンとプロジェクタの関係」である。大きな会場ではハンディなプロジェクタで力不足になるのは当たり前だし、逆に小さな会場ではプロジェクタの画角が問題になる。要するにワイドコンバータがほしいってことなんだけど、例えば画角が足りないときはプロジェクタを会場後方に配置して VGA のケーブルを長くする（当然ケーブルを長くするのは短いときより気を使う）などの臨機応変さが大事になる。この辺はプレゼンの技法ではなく会場部隊のノウハウである。裏方が好きな人はこの辺を勉強しておくとよいだろう。（ほんとは音響系も大事だけどそっち方面は興味ないので何も書くことはないです。悪しからず。）

……。プレゼンなんて長いことしてないな。ま、必要ないからいいんだけど。

抜けがあったらツッコミよろしく ↩
ということは逆にそういう、詰め込みすぎてて全然分かんねープレゼンをしている人がたくさんいるってことなんだろうな。そういう間違いを犯すのはたぶん「スライドを印刷して確認してるから」だと思う。 ↩
これは自分の曲解もかもしれないけど ↩

MP3のID3タグにトロイの木馬がひそめる＆ファイルタイプを偽装できる @OS X

Apr 09, 2004

問題が2つある。

MP3 の ID3タグにカーボンアプリが保存できちゃう
ファイルのアイコンに拡張子や実際に関連付けられているアプリケーションとは関係のないものを表示できる

これ、MP3 の ID3 タグの部分が Windows でも通用するテクニックなら、アイコンについてはすでに可能なので Windows でも激しく危険な気がする。いや OS X での危険性を軽視するわけではないが、応用が進めばかなりのデスクトップがやばいことになりかねないっつーことで。

でも ID3 タグ上のアプリケーションを実際に起動しちゃうのは Finder だと思うので、Explorer で同じような脆弱性がなければいいのか？とりあえず Finder の穴がふさがれば、各種マルチメディアデータを扱うアプリの脆弱性だけの問題ということに絞れるような。ダブルクリックが危険ていうのは Mac としては本当に命取りだと思うので、恐らく Apple は真面目に対策取るだろう。

と楽観することにする。（使ってないし :-）

[[PrimoPDF|http://www.primopdf.com/]]

Apr 09, 2004

今度は PrimoPDF. 前回はただのにっき経由だったが、今回はえとせとら経由。まったくこの人たちのアンテナの感度はどうなっているのか。

利用している Ghostscript は 8。この段階で CutePDF よりいい。実際圧縮率も若干よい。同じサンプルを出力すると、

Distiller 10.5KB
CutePDF 47.7KB
PrimoPDF 33.8KB

いい選択肢かもしんない。セットアップも CutePDF と違ってインストーラ1つだけだし。ただちょっと実際に PDF を保存するときのダイアログにはビビるけどね。

あ、出力時に画像の圧縮率を変更できる。（screen 向けと print 向け。）これも CutePDF よりいい。決まりかな。

SourceForge.jp の容量制限から文系向け共同作業プラットフォームを思う

Apr 09, 2003

ま、単に脱線しただけなのですが。

http://sourceforge.jp/forum/forum.php?forum_id=2150

/.-j 経由。

プロジェクトホームページ 200MB まで
個人のホームディレクトリ 100MB まで
リリースファイル 100MB/ファイルまで

てな具合だそうです。もともと夏には制限が入る予定だったらしいけど、予想以上に sf.jp での活動が活発だってことですかね。それはそれでかなり喜ばしいことです。欲を言えば sf.net ほど重くならない程度でいてほしいのですが(^^;

よく調べてないけど、http://savannah.gnu.org/ こういう選択肢もある。ライセンスは GPL 以外はだめなのかな？どっかの大学とか、ring 系でこういうのホスティングしてくれないですかね。それこそ共同研究とその成果の publishing と feedback を円滑に進められるんじゃないかな。

さらに進んで人文・社会科学方面の共同作業を支援する Wiki ホスティングなんてものはどうでしょう。編集には認証が必要な Wiki を用意して、閲覧時には動的に PDF を生成してダウンロードできます、みたいな。既存の技術だけでできるし、あとはパッケージングの問題ですよね。文系人には CVS がどうこうってよりずっといい。

でもプログラマ方面と違ってフリーソフトやオープンソースにこだわりのなさげな人文・社会科学方面。無駄な出費を抑え、オープンな共通プラットフォームを利用することの意義をどれだけ理解できるものか…(-_-; 無駄にでかい Office のファイルをやりとりして「メールが大きすぎてねぇ」なんて、「プジョーは壊れるんだよねぇ」くらいに自慢げに喋ってるようじゃいけません。「オープンソース」が単なる流行語に聞こえている人だって多そうだもんな。

WebLog ブームの次は Wiki ホスティングだ！とかゆーてみたり。（すでにどっかにありそうだけど。）

About

例によって個人のなんちゃらです