Sonyのアクションカム“HDR-AS15”を購入した

これで俺も映像作家だ！（マテ

小さい

もう4日も前の話になるんだけれども、Sonyのアクションカム“HDR-AS15”を購入した。動機は幾つもある、というかいくつかある動機が重なって購入するに至ったわけだけれども、買って一番驚いたのは、その大きさ。いや、小ささ。十円玉数枚程度。手で握っても隠すことはできない大きさではあるけど、握っててもそれがカメラであると認識しにくいような気がするサイズ。これ、分解して配置しなおしたら（以下自重

動機

• 自転車乗るので、車載カメラ欲しかった。
• 映像に興味があった。
• というか映像編集楽しい。
• 俺もYoutuberになりたい。
• 動画はもっと流行るべき。
• 動画ブログはもっと流行るべき。
• iPhoneで動画を撮ると、画質はいいがマルチタスクできないし、自画撮り難しい。
• アクションカムって耐衝撃性高いんでしょ？ 多少無茶できるんでしょ？ そういう面白い画、撮れるんでしょ？
• ハンディカム、でかいし、撮る時気負いそうで、映像初心者にはハードル高い。

GoProとの比較

今比較するならGoProHERO3 BlackEditionになると思う。
実際に比較してみると、機能の面ではほとんど全てにおいてGoProの方が勝ってて、大多数の人はそっちに流れるんだろうな、と思うんだけど、一方で、AS15にもメリットはあって、それが「画質」。詳細は次項に譲るが、たぶんカメラ内で行われている画質補正のお陰で、撮ったものをいちいち調整せずとも綺麗なものとして公開できるという手軽さ（完全に日本人向けな感じだけど）が気に入った。
GoProより劣っているとはいえ、必要十分な機能を持っているので、そもそも比較する必要もない感じだったし、価格的にはこっちのほうが安かったし、GoProHERO3Blackは品薄で手に入らないし。
後述するが、電子式とはいえこのカメラの手ぶれ補正は非常に優秀で、それだけでもアクションカムとしての価値は大きい気がする（のに俺は一切気にしてなかった）。

画質

画質チェック代わりに、早速自転車に載せて走ってみた。

日暮れ前から30分程度撮ってみて、各環境光の状態でのチェックや、手ぶれ補正の有無の差などを確認してみた。
基本的に色味は青に寄っており、元々強い青を持つ部分は青潰れしてしまうが、それ以外の部分については、比較的記憶色に近い（非常に鮮やか）感じがしてよい。
夜間でも、暗部が黒く沈み込まずに、しっかりと形状が分る。その状態でありながら明るいところも完全に飛んでしまうわけではなく、「ざっくりと記録する」という意味では、非常に適している気がする。さすがSonyのExmorRセンサーだ。
手振れ補正についてはそれほど気にかけていなかったのだが、使ってみるとその優秀さが驚愕する。シーン１では手ぶれ補正無しなので、画面下部のバッグはフレームに対して固定位置に映っており、風景については映っているものがなんなのかわからないくらいに揺れることも多々あるが、手ぶれ補正をONにしたシーン２では風景の揺れがわずかになり、一方で下部のバッグの揺れが激しくなっているのがわかる。手ぶれ補正をONにすると画角が120度に制限されてしまうが、あとの編集のことを考えれば、手ぶれ補正により静止している画のほうが使いやすいだろうし、車載など揺れの起きる場面では遠慮なくONにしたほうがいい気がした。

不満点

不満点がないわけではない。１つは本体に三脚穴が開いていないこと。これは同梱の防水ケースに入れることでなんとかなるが、今度は音を拾わなくなる。車載カメラにおいて音はさほど重要ではないのでそれでも問題ないが、普通に撮影する際に困ることになる。Claspのような、三脚穴にクリップが付いたようなもので挟むなどの対策が必要だ。お金に余裕があるなら、公式のLCDユニットを購入するのもいいと思う。本体には（あくまでアクションカムなので）液晶がついていないが、この液晶付きの製品につけることで、ハンディカムのように用いることもできる。ちなみに俺は全部買った。
録音も問題だ。本体のマイクは非常にクリアで文句はないのだが、同梱の防水ケースは防水性を高めるために密封される関係で音をほとんど拾わなくなる。本体には外部音声を録音するためのミニジャックが付いているが、ケースに入れるとそこが塞がれてしまい用いることができない。防水ケースやLCDユニットと一緒に用いても外部マイクを使えるような仕様にして欲しかったな、とは思う（たとえば、Bluetooth変換ミニジャックを刺す空間が空いてるとか）。
色味が青により過ぎているのも気になる。アクションカムなのでーと言い訳すれば済む話だし、それが与える好印象もあるので、一概に直せとは言えない（というか直して欲しいならGoPro買え）が、すこし勿体無いな、という気はする。

買ったもの

AS15自体は非常にシンプルな構成なので、これでいろいろやりたいと思えば、周辺機器を買い揃える必要がある。俺は昔から「周辺機器大好き」な人だったので、今回も例に漏れずいろいろ買ってしまった。

製品	価格（定価）
HDR-AS15	26,000(29,800)
グリップスタイルLCDユニット AKA-LU1	8,750(10,500)
ハンドルバーマウント VCT-HM1	2,600(3,150)
Transcend microSDHCカード 32GB Class10 TS32GUSDHC10E	2,480
ソニー NP-BX1 互換 バッテリー ２個セット	1,000
Clasp for smartphone	945
NPBX1用充電器 カメラバッテリーチャージャー	840
PLANEX 55メディア対応USB2.0 メモリーカードリーダー/ライター PL-CR55S3U2-W	691
送料	500

ちなみに、AS15自体はヨドバシ川崎店で23,000円弱で売ってたので、欲しい人はAmazonよりヨドバシとか探したほうがいいと思うよ。

お願い

そもそもの動機が「映像編集したい」というところに起因するので、経験を積むという意味でも、例えば俺が参加する勉強会などの様子、会話をまとめあげ、雰囲気を伝えられるような映像を作っていきたいと考えている。ただ、勉強会などの雰囲気を伝えられる映像を作るには、俺一人が録画しているのでは不十分で、様々な角度から録画された映像を（恣意的な何かも含まれつつ）編集した方が楽しいものができると思う。なので、もし良かったら、俺が参加している勉強会、イベントではその様子をみんなにも録画して貰いたい。ガラケーのカメラでもいい。数千円のチープなやつでもいい。MacBookのinSightで自分の顔を撮るのでもいい。四六時中録画するのではなく、なんかキーになる部分だけ録画するのでもいい。なんかそういう機会があったら、みんなも録画して、そのデータを送ってほしいなぁと思うのである。
どうせ良い物が作れるようになるに時間がかかるんだ。ざっくり行こう。

ZXingを使ってiPhoneでQRコードを読む

iOSでQRコードを読み込む（ZXing 2.0）に書かれている方法を使って、iOSでQRコードを読むためのアプリを試作してみた。
基本的には、参考エントリの通りでいいのだが、Xcode4.5ではいくつか問題がでたので、そのへんについて補足する。

"recursive path"というチェックボックスがない

「zxing-2.0/cpp/core/src」と「zxing-2.0/iphone/ZXingWidget/Classes」を追加するという部分で、その英文を見ると「... "zxing/iphone/ZXingWidget/Classes" directory. Make sure you click the checkbox "recursive path" !」とか「... cpp/core/src/ where the 'zxing' directory is. Do not check the "recursive path" option for this path.」とか書かれているのだが、どうやらXcode4.5では「non-recursive」と「recursive」というプルダウンになっているので、設定する際は、下記のようにする。

• /..../iphone/ZXingWidget/Class recursive
• /..../cpp/core/src non-recursive

Apple Mach-O Linker (Id) Error

このままBuildすると、iostream errorが出るのは参考エントリにも書かれている通りで、ちゃんと拡張子を.mmに変更する必要はあるのだが、これをすると今度は"Apple Mach-O Linker (Id) Error"というエラーが大量に出てくる。
これに関しては、zxing in xcode 4.5 and ios 6 - Stack Overflowにエントリが投げられていたので、このとおりに設定を変更することで対応する。具体的には、「作成したプロジェクト >> TARGETS >> Build Settings >> Apple LLVM compiler 4.1 - Language」の「C++ Standard Library」を「Compiler Default」にするだけ。

ひとまず動いた

取得した文字列データをTextViewに表示するだけなので、URLとかが入っててもそのページにジャンプは出来ないが、ひとまずQRコードが読めたのでよしとする。
実際に動かした時のソースコードはこちら

• https://github.com/kkotaro0111/zxtest

2012年総括

誰得エントリ

先に総括

こうやって見ると、去年までよりかは充実した1年を送っている気がする。今まではなんとなくやってきたエンジニア的な部分もこの一年で一気に増強したし、デザイナ部分もこの調子でより強くしていきたい。

1月

会社が引越しする。新築のビルで、最上階にはカフェが！ 意味もなくカフェにいきダラダラする日が続く。

2月

人生初のiPadアプリを作る。受注案件のため詳細は差し控えるが、徹夜もしながらちゃんと動くものができた。ただ、今ならもう少し効率の良い物、プログラムとしてちゃんとしたものが作れる気がする。少しだけ。

3月

「ペアプロ合コン」というものが開催される。ネタとして参加してみるも、合コンとは名ばかりの健全な会で、思いっきりエンジョイする。このためだけにRubyとRailsを学ぶが、間に合わず本会では散々な目に。ペアの子が優しかったのが救い。

参考

• id:kkotaro0111:20120329 ペアプロ合コンいってきた

4月

初のP4D参加。この回ではペアハッカソン形式だったので、ペアの[twitter:@ppworks]さんと一緒に、短い時間ながら1つウェブアプリを制作した。その名も「勤怠戦隊キンタイン」。毎日の勤怠状況をボタンひとつで記録していくというもの。デザイン担当だったこともあり、制作後、あまりメンテナンスに参加していなかったので、せっかくRubyの知識がついてきているのだから、来年はキンタインのメンテナンスにも手を出してみたい。

参考

• http://atnd.org/events/26983 第2回デザイナー x エンジニアハッカソン
• http://kintain.herokuapp.com/ 勤怠戦隊キンタイン

5月

はてさて

6月

JavaScriptにハマる。今までもJSは組んでたけれども、いまいち全容というか、具体的なところがわからぬまま、「あぁこういう組み方もできるのかー」程度で触ってきていたのだが、初めてまともにJSの本を読んで、その辺をある程度は理解し、チューニングは無理でも、大体まっとうな書き方はできるかなー程度には組めるようになった気がする。一方でActionScriptがおざなりになる。

7月

「第2回ペアプロ合コン」に参加する。相変わらずの健全さ。ジャンルがJavaScriptだったので、ここぞとばかりに本領を発揮するも、JSってHTMLの味付けのようなものなので、HTMLのベースが出来上がるまで組むことがなく、前半は普通にデザインとHTMLマークアップのみで終わるのが残念だった。

参考

• id:kkotaro0111:20120718 第2回ペアプロ合コンいってきた

8月

某Kaya◯を受けるも落ちる。エンジニアなのか、デザイナーなのか、どっちつかずな特性は、分業のできている会社ではあまり引っかからないのかもしれない。というか、二次面接あたりで「エンジニアとしてなら雇う」的な事言われた。

9月

YAPC::ASIA 2012に参加する。よく行く勉強会の主催者である[twitter:@uzulla]さんが“LT-THON”という1コーナーの運営を担当していたので、そのお手伝いに。あと、サイトを作らせてもらった。

参考

• http://ltthon-yapc2012.hachiojipm.org/ YAPC::ASIA 2012 LT-THON
• id:kkotaro0111:20120928:1348844087 YAPC::ASIA 2012行ってきた。
• id:kkotaro0111:20120929:1348915727 YAPC::ASIA 2012行ってきた2日目

10月

はてさて

11月

Goomerというウェブアプリの制作にアサインされる。デザイン、マークアップ担当。勉強会や飲み会などで、話者の内容に面白いところとか、ためになることろがあったら、その人に対してgoom!することで、goom!された人にポイントが入る、というアプリ。最終的に一番高い評価を受けた人に「ベストトーカー賞」なんかを与えたりすればいいんじゃね？的な。個人的には多機能すぎて、勉強会当日に使い方を説明するには説明する側もされる側もハードルが高くなってしまうんじゃないかと思っている。

参考

• http://g.cfe.jp/ Goomer

12月

約2年（派遣3ヶ月、正社1年9ヶ月）で、現在の会社を退職する。来年からはエングラフィアという会社に足を突っ込みながら生活費を稼ぐためにフリーランスとしても活動するので、皆様お仕事下さい。

参考

• http://engraphia.com/ 株式会社エングラフィア

たった1行のJSコードでひたすらアイドル水着画像をあつめる

改行抜けば１行になるよ？

たった◯行のコードでひたすらアイドル水着画像をあつめる

なんかそういうタイトルのエントリが（超局所的に）バズっているようなので調べてみた。

• 【PHP】たった10行のコードでひたすらアイドル水着画像をあつめる - utgym’s diary
• 【Ruby】たった3行のコードでひたすらアイドル水着画像をあつめる（Rubyだよ） - maeharinの日記
• 【Goutte】たった数行のコードでひたすらアイドル水着画像をあつめるのをGoutteで書いてみた - iakioの日記
• 【Python】たった 4 行のコードでひたすらアイドル水着画像をあつめる(Python だよ) - Memo
• 【Haskell】たった6行のコードでひたすらアイドル水着画像をあつめる(Haskell)
• 【Perl】ゆーすけべー日記
• 【PHP】外部ライブラリ不要で、たった一つのツイートに納まる長さのコードでひたすらアイドル水着画像を集める - uzullaがブログ

ただ、どれも「指定したURLのページ内の特定画像を抽出して一つにまとめる」ということしかしてなくて、それって別にサーバーサイドスクリプトでやる意味あるのかなぁなんて思ったのですよ（モジュール化とかしらない）。だって、欲しい画像があるページのURLを取得するためにそのページをブラウザで開くんでしょ？ だったらその場で抽出したいじゃん。そこでJavaScriptです。

最近のウェブサービスはどこもjQuery使ってて楽だね。

jQueryがないといちいちgetDocumentsByClassName()とかでゴニョゴニョしなきゃいけないけど、jQueryが標準で読み込まれているのでサックリ終わらせられるのいいね。
そんなわけで、JS版ひたすら水着はこちら。（82文字）

$(  $(".MTMItemThumb").get().reverse()  ).each(
  function(){
    $("body").prepend($(this));
  }
);

最初にreverse()をしてるのは、ページの先頭に画像を集めるため、要素の追加を$("body").prepend()で行なっている関係で、表示順序が他の人のと逆になってしまうのですよ。それへの対策です。
ただ、このコードだと、画像一覧の下部に既存ページのデータが残ってしまうので、それもすっきりしたければ、下記のコードでいけます。（90文字）

var i = $(".MTMItemThumb");
var b = $("body");
b.empty();
i.each(function(){
  b.append($(this));
});

今度はページをすっきりさせた上で、要素を追加できるので、prepend()じゃなくてappend()使ってます。だからreverse()してない。
ただ個人的にはクリックした先のページも見られるようにしたいよね。いや、クロールすると文字数おおくなるから、せめてanchorタグは引っ張っておきたい。
そこでこれ。（99文字）

var i = $(".MTMItemThumb").parent();
var b = $("body");
b.empty();
i.each(function(){
  b.append($(this));
});

最初の画像のDOM取得時に、parent()を呼んで、その親要素（aタグ）を拾ってきている。

【追記】アドバイスもらった

jQueryのappendToを使えば、なんと改行を抜かなくても1行で表せるじゃないか！ すごい！ 上記で踏んできた段階の中でも一番短くて、もう上の項目不要なんじゃないかと。（56文字）

$(".MTMItemThumb").parent().appendTo($("body").empty());

JavaScriptの最大の利点

やっぱUserScriptを書く最大の利点と言ったら、ブックマークレットでしょう。そこでこれをブックマークレットにした。適当にブックマークを作成し、そのURL欄を下記に置き換えればよろしかろう。

javascript:(function(){$(".MTMItemThumb").parent().appendTo($("body").empty());})();

やっぱPureJSで書かなきゃね。

ライブラリが許されるのは小学生までだよねー。
んなわけねーだろ

var d = document;
var b = d.getElementsByTagName("body")[0];
var d1 = d.createElement("div");
d1.innerHTML = b.innerHTML;
b.innerHTML = "";
b.appendChild(d1);
var i = d.getElementsByClassName("MTMItemThumb");
for(var j = 0; j < i.length; j++){
  b.appendChild(i[j].parentNode.cloneNode(true));
}
b.removeChild(d1);

なんかもう少し簡略化できそうだけどなー。特にbodyの中身を、後で一括削除するために新しくdivを作ってそこに入れなおしてるあたり。これをやらずにbodyタグの中身を空にすると、その時点でgetElementsByClassName()の中身が空配列になっちゃう（live nodeList objectのため）なので、どこかしらに残しておく必要があるんですよ。うーむ。
やっぱこれはこの企画の意味を考えると長すぎるなー。

今後の予定

気が向いたら、

• $.ajax()使って、次頁以降も取得する

<<0 と | 0 、どっちが速いか

TwitterのTLみてたら、[twitter:@ginpei_jp]さんが、JSに関する興味深いエントリを書いていたのを見つけた。

少数値を整数値に直すのに、ビット演算を用いることはJS界では有名なことで、個人的には不思議な挙動ではあるけども俺も多用している。
ただ、俺はOR( | )ではなくSHIFT ( << )を使っており、この2つに速度的な差があるのか、というのが気になった。

というわけで、せっかくなので調べてみた。

jsdo.itという兵器

自前でコード起こして、サイトにアップしてーとかやってるのが手間だったので、jsdo.itのちからを借りることにした。
自分の環境でテストした感想は、該当ページのREADMEにまとめたが、あまりに実行環境によって結果差が大きい。
Windows7ではことごとくOR演算が早く、MacOSX Lionでは逆にOR演算が少し遅い。
しかし、1千万回forループしてこの時間ということは、純粋にビット演算の時間だけみたらカウントのしようがないくらい微々たるものなので、[twitter:@ginpei_jp]さんの言うとおり、大差ない、という結論でいいんじゃないだろうか。

データ

Windows7 32bits ( Core 2 Duo E8600 3.3GHz )

IE9

ビット演算	所要時間(msec)	最速を1とした時の比
Left Shift ( << 0 )	106.157	1.006
Right Shift ( >> 0 )	106.864	1.012
OR ( ¦ 0 )	105.513	1.000

Firefox

ビット演算	所要時間(msec)	最速を1とした時の比
Left Shift ( << 0 )	24.165	1.001
Right Shift ( >> 0 )	24.154	1.001
OR ( ¦ 0 )	24.127	1.000

Chrome

ビット演算	所要時間(msec)	最速を1とした時の比
Left Shift ( << 0 )	29.677	1.017
Right Shift ( >> 0 )	29.589	1.014
OR ( ¦ 0 )	29.172	1.000

Opera

ビット演算	所要時間(msec)	最速を1とした時の比
Left Shift ( << 0 )	221.647	1.024
Right Shift ( >> 0 )	222.954	1.030
OR ( ¦ 0 )	216.333	1.000

MacOSX Lion ( Quad-Core Intel Xeon 2.8 GHz )

Safari

ビット演算	所要時間(msec)	最速を1とした時の比
Left Shift ( << 0 )	?	?
Right Shift ( >> 0 )	?	?
OR ( ¦ 0 )	?	?

Firefox

ビット演算	所要時間(msec)	最速を1とした時の比
Left Shift ( << 0 )	34.555	1.000
Right Shift ( >> 0 )	40.397	1.169
OR ( ¦ 0 )	34.554	1.000

Chrome

ビット演算	所要時間(msec)	最速を1とした時の比
Left Shift ( << 0 )	30.28	1.000
Right Shift ( >> 0 )	30.252	1.000
OR ( ¦ 0 )	33.632	1.111

Opera

ビット演算	所要時間(msec)	最速を1とした時の比
Left Shift ( << 0 )	?	?
Right Shift ( >> 0 )	?	?
OR ( ¦ 0 )	?	?

lokkaをherokuでrunする話

lokkaというCMSがある。
rubyで書かれており、herokuで動く。それ以外の特徴はよく知らない。
なんとなく1日1エントリのTwitterの延長的なブログが欲しくなったところに、そういえばherokuでアプリ走らせるの成功したことないなーと思って、lokkaを採用してみた。

インストールからrunまで

基本的なインストール手順は、“Getting Started - Lokka”の“heroku”項目を参考にすればいいのでシンプルだが、実はこれだけだと動かない。“heroku run rake db:setup”をしたところで“rake aborted!”と言われてしまうのだ。
そこで“rubyでCMS構築したい ~lokka~ | Chie a la Mode”の「で、その後、ソースをよくよく見たら、」項目を参考にデータベースの設定をする必要があるのだが、ぶっちゃけこれでも動かない。というもの、あなたがいまcreateしたheroku appには、postgresqlが入っていないからだ。そこでこのaddonsを入れる必要がある。
それも含めて実行すると、下記のようなコマンドを打つことになる。
※途中の“HEROKU_POSTGRESQL_***の***部分は人によって変わるようなので、適宜置き換え

$ gem install heroku bundler #herokuコマンドとbundlerコマンドを入れる
$ git clone git://github.com/komagata/lokka.git #gitからlokkaを落としてくる
$ cd lokka
$ heroku create <your app name(アプリページのサブドメインになる。)> #herokuにアプリを作る
$ git push heroku master #herokuにlokkaをアップロードする
$ heroku addons:add heroku-postgresql:dev #追加：アドオン契約する（Free)
$ heroku addons | grep POSTGRES #追加：契約したpostgresqlのデータベース名（？）を確認する
#> heroku-postgresql:dev  HEROKU_POSTGRESQL_***
$ heroku pg:promote HEROKU_POSTGRESQL_*** #追加：よくわかんないけど、DBはじめる？
$ heroku run rake db:setup #lokka起動
$ heroku apps:open #ページを開く

あとは、自分のアプリページを開いて、ログイン、id/passを変更して完了である。

の出し方知ってる？

世の中には2種類の人間がいる。Macユーザーとそれ以外だ！

Macの特殊文字

OS X が他のOSと違うところに一つに、キーボードから直接入力できる文字種の多さがある。実際にその文字を表示させるには文字コード云々の話とかもあるんだろうけど、それはとりあえずおいといて、たとえばWindowsなら「きごう」と入力して変換していかなければ入力できない文字も、ショートカットキーで入力が可能なのだ。その有名な例が“”である。

の入力方法

Macを使っている人は、どこか文字入力が可能な場所をクリックしてカーソルを表示し、“option + shift + k”と押してみよう。が入力されるはずだ。

他には？ 他には？

例えば、最近話題の（？）ウムラウトは英字入力モードで“option + u → a”と押せば、“ä”と入力されるだろう。“option + u”でウムラウト¨の指示を出し、直後に合わせる文字“a”を押している。“option + u → o”なら“ö”だ。*1
それ以外にもたくさん、というかほとんどのキーで“option”との合わせ技を持っている。Macの日本語キーボードでそれを調べたのが下記の画像だ。

各キー、上下二段になっており、上が“option + shift”と合わせることで表示される文字、下が“option”と合わせることで表示される文字である。また、赤い文字はウムラウトなので、キーを入力後、“aouAOU”のどれかを押す必要がある（例では“a”を押してる）。青い文字は、ことえり使用中はショートカットがバッティングしてしまい、入力できない文字だ。どうしても入力したい場合は、“言語とテキスト”環境設定から“U.S.”などをONにし、そのモードにした上で入力する必要がある。

なんか意味あるの？

日本では（風習的に）あまり気にする必要はないのだが、海外ではとても重要な文字がこの中に含まれている。たとえば俺がさっきから使ってる「“ ” ( option + @) (option + shift + @)」だ。プログラマには馴染みの深い、いわゆる「ダブルクォート」だが、プログラミングで一般に使われる「" ( Shift + 2 )」は実は英文において使われる文字ではない*2。引用等の意味でダブルクォートを使うときは「“ ”」を使うのが当たり前なのだ*3。そのため、文章中に使われる「"」は一般に「マヌケ引用符（dumb quote）」と呼ばれている。カッコつけて英文を使うことのあるデザイナーや、英語論文を書く学生は要注意だ！カッコつけたつもりが「マヌケ」を晒してることになってしまう。もちろん、シングルクォートも「' ( Shift + 7 )」ではなく、「‘ ’ ( option + [) (option + shift + [)」である。ちなみに「“ ”」はペアであり、この向きが左右、もしくは上下逆になることはあってはいけないようだ。とはいえ、フォントの形状によってその表現方法も変わってくるので、見た目だけ考えるならあまり重要ではないかもしれない（ただ、どのフォント使っても “ ” という組み合わせにならないならそれは入力された文字がそもそも間違ってると捉えられるだろう）。

他にも、“10:00 a.m.–6:00 p.m.”などの“– (en dash / option + -)“。日本では“〜”が使われるのが一般的だが、海外では“–”が使われる。また、en dashは「ハイフン」でも「マイナス」でもない。表示環境によって大差なくなってくるかもしれないが、その違いを比べてみよう。

• - ハイフン（マイナス）
• – en dash
• ― em dash

おわかりだろうか。en dashはハイフンより少し短く、em dashはハイフンより長い。日本では「〜」でいいかもしれないが、英語圏が表示対象であるなら気をつけたほうがいい点でもある*4。

もう一個紹介させてもらおう。それは“…”である。中黒を３つ繋げる「・・・」でも、中黒の変換候補にある「…」でもない。“...”でもない。“… (option + ;)”である。意味は、普通の三点リーダーと同じで、語尾の省略や、発声の弱い様を表すんだと思うんだけど、日本語では一般的に上下中央に置かれる「・・・」も、欧文ではベースライン揃えなのが当たり前。また、同じベースライン揃えでも、ピリオド3つ並べたわけじゃないので、別のものとして扱うらしい。ちなみにこの“…”、名前を「エリプシス」というらしい。ちょっと比べてみよう。

• ・・・（中黒3つ）
• ... （ピリオド3つ）
• … （日本語変換の「三点リーダー」）
• … （エリプシス）

どうみても「三点リーダー」と「エリプシス」との違いがわからないのだが、それはどうも、文字コードが云々とかいう大人の事情らしいので、ウェブで使う分にはあまり気にしなくてもいいのかもしれない。

他にも、日本語文字と似てるけど、英文においては本来こっちを使うべき的な文字がところどころにあるんじゃないだろうか。個人的にはMacの特殊キーを表す⌘（コマンド）や⌥（シフト）とかのほうが欲しいなぁ。

どこで知ったそんなこと

「なんか意味あるの？」項でウンチクたれた話は、今年の2月に行われたCSS Niteで聴講した内容だ。日本では当たり前のように使われている表現をそのまま英文でも使うと、とんでもないことになるよ、鼻で笑われるよ、という話をしてくれた方がいたのだ。具体的にどう笑われるかというと、これを見て日本人がネタにするようなものらしい。それ以降、俺はできるだけ気をつけている。

*1:日本語がONになっていると、“o”を入力した時点で日本語が入ってしまい、失敗する

*2:聞いた話だが

*3:あくまで聞いた話だが

*4:ただし、ウェブにおいては、結局のところPCではunicode化しないと文字化けする可能性があるので、普通にハイフンを用いるのが一般的な気もする