落語にはオチがあって、それを聞いて笑うものなのですが、CDで10回20回も聞いていると、もはやそれで笑うこともないです。しかし、落語を聞くことは楽しいです。音でしか聞いていないのに、情景をイメージできて、感情移入できます。BGMよりも楽しく、他人のおしゃべりを聞くのよりも(いい意味で)低い集中力で聞けます。
私はiPodに落語を入れていつでも聞けるようにしています。歩きながら聞いていると、誰かとおしゃべりしているようで、孤独(?)を紛らわせてくれます。難点なのは、人のしゃべる声であるため、電車の中では聞きづらいことです。それでもめげずに音量を上げて聞くと完全に落語の世界に入れます。
しかし、昔は落語を聞きながら受験勉強なんかもしたもんですが、よく勉強内容が頭に入ったもんだと我ながら感心します。今は落語聞きながらは本も読めません。。。さびしーなー :'(
マイコミジャーナルに、あまり使われていないHTMLタグについての記事がありました。
確かにあまり使われていませんね。私はせっかくあるんだからと積極的に使うようにしていますが、使おうとすると逆に使い方を調べるのに苦労するぐらい使われていません。
しかし、そもそもHTMLのタグだけで意味を表現しようとすること自体が間違っている気がします。HTMLは文章の構造を定義する言語なのですから、文章内で意味を持たせたい場合は、以下のようにタグのclassで意味を指定すればいいのではないでしょうか。
<span class="field string">名前</span>: <input>...
classで指定するようにすれば、自分の好きなようにいくらでも拡張可能ですから、いちいち「入力欄の説明に使うタグは何だっけ？」と迷うこともなくなります。また、HTML自体の構造もシンプルになります。こうすればlabelとかlegendとかは使わなくてもよくなります。
HTML5では文章構造を表すsectionやヘッダ、フッタを表すheader, footerなどがどかどかっと追加される予定みたいですが、ちゃんと使われるんでしょうかね。ブロック要素div、インライン要素span、表組みtable、リスト構造ul(もしくはol)さえあれば、何でも表現できますよ。きっと。
1つ実例を挙げたいと思います。以下をご覧ください。
上記はMicrosoft Wordで「新しいスタイル」を作るときの画面です。これを見ると「種類」には段落、文字、リンク、表、リストしかありません。Microsoftは、これだけあれば文章の構造化は可能である、と判断しているということです。
またWordには「スタイル」という、上述した「構造」に対する「装飾」を定義するための機能があります。HTMLとCSSみたいなものです。とてもシンプルです(複雑なのは使い方だけです :p )。Microsoftの製品を引き合いに出すと、何か悪い例を示しているような錯覚を感じる方もいるかもしれませんが、このデザイン、操作性が世のデファクトですから、仮に正しないとしても、間違ってはいないはずです。
もちろん、グラフの描画や複雑なレイアウトを構造化するのであれば、上述の構造だけでは足りないですが、一般にはそれだけで9割程度の要求を満たせると思います。シンプルに行きましょうよ。
Microsoft Office 2007のWordには上記のようなツールバーがあります。Wordに限らず、多くのアプリケーションで文章の書式を設定するときには、このようなツールバーを使いますよね。Bloggerの投稿フォームにも同じようなツールバーがあります。こういうデザインをWYSIWYG(What You See Is What You Get)って呼んだりします。見たままの効果を文章に反映できる、とても優れたデザインです。これらのツールバーには、お決まりのように「太字」「斜体」「フォントの色」「フォントのサイズ」「左寄せ」「中央揃え」などのボタンがあります。ある意味、文章の編集にはこのツールバーデザインがデファクトとなっているため、もはや誰もこれを不便だとは思わないと思います。
しかし私はあえてこのデザインに異論を唱えてみます。そもそも文章内の文字列を太字にしたり色を変えたりするのは、その文字列が大事な内容であったり、逆に婉曲したい内容であることを読者に示したいからです。人は文字列を装飾することで意味を持たせようとしているのですね。
であれば、装飾の変更単位も「太字」や「色の変更」ではなく、最初から「強調」や「婉曲」などの「意味を主にしたデザイン」にしてみてはどうでしょう。つまり意味とそれを表す装飾の分離をするということです。HTMLとCSSみたいなものですね(HTMLは意味ではなく構造を表す言語なので、ちょっと違いますが)。
具体的にこんなデザインにしてみてはいかがでしょうか。
ツールバーのボタンには、装飾ではなく、意味を示すアイコンを並べてみました。使い方はWYSIWYGツールバーと同じです。文字列、あるいは段落を選択してクリックするだけ。「強調」ボタンを押せば、文字列に「強調する内容である」という意味を付けられます。「強調」という意味を付けられた文字列がどのように装飾されるか(太字になるのか赤字になるのかなど)は、どこか別で定義をするようにします。例えば右にあるWordの「スタイル」ウィンドウのようなUIで。(Wordのスタイル機能も「スタイル名=意味」と思えば「意味を主にしたデザイン」を実現できているんですね。あまり使われていませんが。)
このデザインの利点は、同じような文書をいくつも書く場合(設計書、マニュアル、ニュース記事、真面目系(?)のブログ等)、同じデザインを複数の文書に適用できます。一方難点は、ツールバーのボタンを押しても何が起こるか想像できないということです。分かりやすさはWYSIWYGには遠く及びません。
ここまで書いてて思いましたが、HTML+CSSなら大体実現できるんですね :) Blogの投稿もHTMLでするんですから、もっと意味を主にしたデザインでできるようにしてくださいよ。(HTMLタグ直打ちは結構厳しいです。。。)
今週は寒かったですね :s
朝起きるのも都下の会社に行くのも仕事をするのも家に帰るのも冷たい布団に入るのも嫌になります。寒いのは嫌です。一週間よく耐えたと自分をほめたくなります。
また先週から職場が変わり、異邦者としていわれのない差別を受けているという被害妄想を抱く一方、「あれ？まだ2週間しか経ってなかったっけ？もう随分前からいるような気がするよ」と、常駐組の仲間のように扱われるというギャップ。なかなか慣れないものですね。:(
そんなつらい一週間を乗り切るために、最近は甘いものに逃げています。とりわけ、夜遅くまで営業しているミスドはありがたいです(今週だけで3回行きました(L) )。
ちょっと前までミスドやマクドの、あの入ってすぐに「ご注文をどうぞ」と言われる感覚が、優柔不断で人見知りな私には合わなくて敬遠してきましたが、最近は慣れたもので(?)、堂々と買いに行けるようになりました。
平日の夜中は結構ドーナツが残っています。どれもおいしそうです。気がつくと箱いっぱい買っています。長い箱をぶら下げて家に帰り、夜食にのんびり食べようとテーブルの上に置いておきます。風呂から出てくると既に箱が空いていて2つ3つ家族に食べられています :'( コーヒーを入れ、いざ自分が食べる時、箱を開けたときの甘い香りに心踊らせ、1つを手に取り粛々と食べます。とても幸せです。この時点で夜1時ぐらいです。
しかし幸せは長くは続きません。ドーナツ2つ目が食べられないのです。おなかがいっぱいなのではなく、1つで満足してしまうのです。10個も買ったのに、1個しか食べられません。そして次の日に帰ってくる頃には、家族に全部食べられて残っていません。それを今週3回繰り返したわけです。
もともと甘いものを食べるスピードは人の何倍も遅かったのですが、最近はそれに益々磨きがかかってきました。先のドーナツ1個でも、10～30分かけて食べます。またコーヒーも必須です。この前食べた31アイスクリームも、カップ1個にえらい苦労しました(ちなみに31に入るの初めてでした :) )。
甘いものは大好きなのですが、たくさん食べられないということはつまり、ミスドのドーナツを全種類制覇するのに多くの時間とお金がかかるということです(家族に食べられるし)。なら1個だけ買えばいいじゃないか、と思うかもしれませんが、大の大人がドーナツ1個だけという買い方はできないのですよ。まー、のんびりやればいいんですよ。逆にそれだけ長い間楽しめると思えば。
決してこのことが、年齢によるものではないと信じています。:s
最近通勤にバスを使うようになって、今までにまして通勤が憂うつになりました。勘弁してほしいです :'(
バスの支払いにはSuicaを使っています。バスは定期を買わない方が得なので(20日間ぐらい使う場合)、乗るたびにSuicaでタッチしています。財布に入れたView Suicaでタッチしています。
ところがどうにも反応が悪い。2回に1回ぐらいエラーになる。私のタッチの仕方が悪いのかと思い、慎重にタッチしてみたり、長めに静止してみたりしましたが、ダメでした。。。
この件で2週間ほど苦悩しましたが、やっと昨日原因がわかりました。バスの中にあるPASMOの注意書きを何気なく眺めているとき、「他のICカードと重ねないでください」の注意書きの下の「競合するICカード」一覧の中に原因がありました。
免許証
免許証！これか！確かに去年免許更新時にICカード化したぞ。View Suica(クレジットカード)と免許証が財布の中に入っているため、タッチ時に干渉していたみたいです。試しに免許証を抜いてみたらサクッと通るようになりました。
しかしクレジットカードも免許証も、財布の中に入れておくのが普通でしょう。干渉するから一緒に入れないで下さいって、ちょっとないですよ。。。今後ICカード化するものが増えていくことを考えると、今のうちにちゃんと規格を統一するなり読み取りの精度を上げるなりしてほしいものです。ICカード化したせいで逆に不便になったことのいい例じゃないでしょうか。
ちなみに、バスではNGだったView Suica + 免許証ですが、JRの改札では問題なく通過できます。この辺に運用の歴史の差が出るんですかね。というか、Suica 2枚でNGなら分かりますが、別のカードと干渉するという時点で、明らかに設計漏れでしょうね :s
@ITにGoogleのブラウザ「Chrome」に対する開発者のスピード狂ぶりを綴った記事が出ていました。
この記事によると、Webサービスにおいては0.5秒遅いだけでユーザが離れていくそうです。その教訓から、Chromeには徹底したスピードへのこだわりを終結させており、その結果としてあの素晴らしいレスポンスが得られるようになったわけだそうです(私が使っているような低速なPCではそれほど激早というわけではないですが)。
個人的にはプロセス分離やドメイン先読みはやりすぎなような気がしますが、他のブラウザがやらない(できない)ことをしている、という点では面白いと思います。
開発者は皆、多かれ少なかれスピード狂です。私はそれほどスピード狂ではないですが、応答性を高めるためにスレッドを分けるとか、ファイルからのI/Oを極力減らすとか、データの先読みをする、という点は常に気をつけるようにしています。
一方でメモリ使用量も抑えるように色々考えています。スピードとメモリ使用量はトレードオフですからね。例えば10万パケット入っているキャプチャファイルに対して、全てのパケットの開始位置(uint)をリストにするだけで400KB必要です。タイムスタンプと発着IP/Portも一緒に保存したら3MBぐらい必要になります。
スピードのためにメモリを大量確保するのか、それともスピードを犠牲にしてメモリ使用量を抑えるのか、もしくは両方とも折り合いのつく着地点を探るのか、開発者はいつでも葛藤しています。Googleの中の人は相当苦労したと思います。それともノウハウたくさん持っているからそれほど苦労せずに見通しが立つのでしょうかね。うらやましい。。。
今までキャプチャファイルの読み込みはFileStreamからPositionプロパティを使ってせっせと読み出し、Lengthプロパティの位置まで来たら止める、という方法をとってきました。これだと50MBのキャプチャファイルを読み出すのに大体10秒ぐらいかかっていました。
Wireshark(というかcapinfo.exe)でキャプチャ情報を読み出すのも大体それぐらいかかっているので、それが普通かなと思っていました。が1ファイル開くのに10秒も待っていられない! 何とかならないものかと試行錯誤していました。
そんな中、CodeProjectにFast Binary File Reading with C#という、ストリームの読み込みの手法毎の性能比較の記事があったの でWireWhaleもチューニングしてみました。具体的には、Position、Lengthプロパティの使用を極力減らし、値は変数で保持、Positionを移動するときはSeekを使うようにしてみました。
結果、、、びっくり!!! 何と50MBのキャプチャを開くのに5秒かからなくなりました!!! プロパティ内で何してるんでしょうね!?
やっぱりこういう細かい調整が性能を大きく左右するんですね。とても参考になりました。
