HTMLの&nbspが半角スペースだと思ってたんですが、実は違ったんだね…。
半角スペースはUnicodeでU+0020、対して&nbspはU+00A0となり、
別々の文字コードとなる。当然見た目は同じなんだけどね。。。

どういう状況でこれに困るかというと、スクレイピングしたデータをパースしたい場合。
Rubyで例えば、以下のようにsplitしたとき区切り文字がnbspだとうまくいかない。

irb(main):001:0> s ="2503 Hoge Fuga"
=> "2503 Hoge Fuga"
irb(main):002:0> s.split(" ")
=> ["2503 Hoge Fuga"]

じゃあどうするか？

irb(main):003:0> s.split(/\u{00A0}/)
=> ["2503", "Hoge", "Fuga"]

Unicodeを直接指定すればできる、と。
空白のはずなのにsplitできなくて小一時間悩んだ。

とある動画を作ってまして、Windows付属のツールでDVD焼いたんですがDVDの画質にがっかり…。
顔がぐちゃっとしちゃうのには参った。。。

まぁこの場合、大きな理由としては以下の3点。

・何度もトランスコードしてしまうこと
　iMovieでH.264で出力した後に、MPEG2に変換している。
　（さらに言うと、Windows付属ツールが一度WMVに変換している気がする…）
・そもそもWindows付属のツールのビットレートが低い
・DVDであること
　解像度720x480のNTSC映像

ということで、まず試したのはDVD Flickを使ってトランスコード&イメージを作成。
結果としてはまずまず。DVD Flickの設定でビットレートをおもいっきり上げれば悪くはない。

次にBlurayにしようと思い、multiAVCHDを使いBlurayの形式にトランスコード&データ作成。
ffmpegのpresetを1pass normalぐらいにしてやって、だいぶ良い感じになった。

iMovieが出力するする圧縮フォーマットがH.264、BDならトランスコード無しで
行けるだろうと思ったけど、いろいろと見てると不安な要素が多すぎて、
とりあえず推奨設定で置いておくことにした。まぁ綺麗だし、ね。

どうでもいいけど、見れば見るほど、BDプレーヤーの開発って面倒そうだだな、と思いました。
対応解像度がいくつかあったり、いろんなディスクフォーマットに対応したり。。。

先月からアパートにCATV回線がついてくるようになって、
12Mbpsの速度であれば家賃に含んだ形で使えるようになった。

このCATVの回線は実行速度が4Mbps台で、TTLが結構大きい。
一方でHuluの推奨は3〜5Mbps以上。すごい曖昧な表現だけど、
動画データのレートが1Mbpsぐらいでそれに幅をもたせた形かな…。

実際に試してみると、以下のようになった。

・Sonyのテレビ → ブチブチと途切れる
・Chrome Cast → 特に問題なく再生できる

以下推測にはなるけど、Sonyのテレビは元々バッファリングを
あまりしていないんじゃないかな。
対して、Chrome CastはSpec見る限り、512MByteのDDR3 SDRAMを積んでる。
これだけあれば、十分バッファリングできるだろう。

ということで、Hulu見ようとしてもテレビだとうまく再生できない場合、
Chrome Cast使うのも一つの選択肢としてありじゃないかなと思います。

19時頃になるとすごく眠くなる…。
ロサンゼルスの時間だと午前3時になるのだけど、
これは時差ボケなんだろうか（笑）

アプリケーションに組み込むためのJavaScriptのエンジンについて調べていた。
3年前ぐらいにV8を使ったことがあるけど、組み込み側の関数登録などの
手順がややこしかった印象。
ライセンスの問題も含めて考えると、以下のライブラリが良さそう。

• Duktape
  • http://duktape.org/

まずは触ってみよう。

個人的に気になるのは、各国の物価差を考えた時に、日本が来やすいのかどうか？
成田に到着して、都内に来るだけでも結構費用かかるよね…とか、今まで思ってた。

最近になって知ったのが、JAPAN RAIL PASSという切符。
実は海外からの方向けのチケットがあったんですね…。

JAPAN RAIL PASS | ジャパンレールパス
http://www.japanrailpass.net/index.html

7日間であれば約3万円で新幹線（ただし、のぞみなど一部例外あり）や特急列車に乗れる。
成田からであれば成田エクスプレスが定額で乗れるようになると。
実際、成田エクスプレスに新宿から乗ると、結構海外の人が多かった。
（対照的にスカイライナーはあまりいなかったように思えるが…）

若干高い気もするけど、まぁ正規の価格で買うのよりかはだいぶ安い。

SIGGRAPH 2015に参加するため、Los Angelsに来ています。
2日目にして、茶色ばかりの食事にそろそろ飽きてきて、
和食を食べたいなぁと思うようになってきた…。
どこ探しても、バーガー、サンドイッチ、バーガー…ステーキ、てな感じなんだよね。
Los Angels Convention Center周辺がたぶん居住地じゃないから、
というのもあるだろうけど、食べ物選択肢が少ない…。

夏といえばやっぱり花火、ということで行ってきました。
こちらの火大会は、連発して打ち上げるというより、
一つ一つの花火が大きめで、ある程度間隔を開けて打ち上げるという感じ。
一発あたりの迫力が大きいので、見応えはあります。
ぼーっと眺めながら、散ってくのをみるとやっぱり良いなと思いました。

AVRを使ったボードの設計をしていて、クロックの供給方法がいくつかあり、どういう違いがあるのかまとめてみた。
ATMEL 8-BIT MICROCONTROLLER WITH 4/8/16/32KBYTES IN-SYSTEM PROGRAMMABLE FLASH DATASHEETを元にしています。

使用するクロックのデバイスごとに、以下のように設定を行う。
デバイスに対応する設定値は、データシートのTable 9-1を参照。

• Low Power Crystal Oscillator
  • 外部の水晶発振子を接続。消費電力が少ない代わりに、外部のデバイスにクロックを供給したり、ノイズが多い環境では使えない
• Full Swing Crystal Oscillator
  • 外部の水晶発振子を接続。消費電力が多分、上記の問題が解消される
• Low Frequency Crystal Oscillator
  • 時計のクロック（32.768kHz）を使用する場合
• Internal 128kHz RC Oscillator
  • 内部のRC発振回路を使用する場合。電圧、温度などにより変化する（この場合、キャリブレーションできないため、3V、25度で128KHzとなる）
• Calibrated Internal RC Oscillator
  • 内部のRC発振回路を使用する場合。電圧、温度などにより変化する。キャリブレーションすることで、適切なクロックを得ることができる
• External Clock
  • 外部の水晶発振器を接続する。この場合は、外部端子はXTAL1のみを使用する

ちなみに、水晶発振器、水晶発振子は違いがややこしい。
前者は発振回路を含んだパッケージになっているもの。製品によっては温度補償などもあるみたい。
後者はコンデンサなどを含む回路を接続する必要がある（マイコンの中に入っているものもある）。
AVRの場合は、Figure 9-2.にあるようにコンデンサを付ける必要がある。

上の表に戻って、上から3種類に関しては、さらにCKSEL[9]、SUT[0]、SUT[1]のそれぞれのビットで動作が変わる。
設定値で変わるのは、以下の2点。要はクロックが供給開始するタイミングからのdelay時間を規定している。

• Start-up times from Power-down and Power-save
  • Power-down, Power-saveからの起動時間。（ここがあまり自身がなくて、おそらく、この時間までにクロックを安定させて欲しい、ってことだと思う）
• Additional Delay from Reset
  • 外部のリセットからシステム内部のリセット(Internal Reset)の遅延時間。Figure 11-2.のT_TOUTに相当する

まとめは以上のとおり。

結局、どれが良いのか？という話になるけど、コストとかも考えると Low Power Crystal Oscillatorが 良いんだろうな。

昨日はオープンセールで人がいっぱい並んでたみたい。

たこ焼き・お好み焼き・焼きそば 鶴橋粉舗てこや
http://tekoya.com/

銀のあんの前にできたので、ホットランドの系列かなと思ったら全く関係ないみたい。
店舗情報を見ると、元々大阪の方のお店で今回はじめて東京に進出してきたみたいだね。
本場の味かどうかわからないけど、結構気になるな。

立地の店で見ると駅前なのは良いところだけど、日野ってのはどうなんだろう。
競争相手は比較少ないので、無難にやっていけそうな感じはする。

特に問題なく、交換用のディスクで復活。交換中に故障とかなくてよかった。

ちょっと気になるのは、どういう条件で故障したと判定しているのだろう？
SMARTなのか、定期的にかけているscrubbingでエラーが発見された場合なのか？
今回故障したディスクをつないでみれば何かわかるかも。

梅雨で土日があまり晴れにならなかったですが、
久しぶりにしっかりと晴れたのでサイクリングに行ってきました。

新しい自転車なので調子を見ながら、1時間半ぐらい走ってきました。
以前のESCAPE R3に比べて、だいぶ漕ぎやすいかなという感じ。

ちょうど、写真のデータはDropboxに移行した直後でよかった…。

今朝、アラートのメールが来ていて、RAIDの片方のディスクが壊れました。
とりあえず、急いで変えのディスクは注文した。
まぁ、最悪交換するまでにもう一方が逝っても、まぁまぁ諦めはつくな…。

あるとき「このSSDはM.2で接続されてるんだよ」と言われ「何それ？」と。
調べてみるとPCI Express M.2なんていう規格がいつの間にかあったんだね。
要約するとこんな感じ：

• 接続するカードの形状と端子の配列のみを規定した規格
  • 端子にはPCIe/USB3.0/I2C/DPなどが割り当てられる。端子の配列はソケットの種類（Key ID）によって決まる
    • また、端子の配列はソケットの種類によって全く異なる。端子配列だけ見ると信号線に電源ラインが当たる場合もある
  • ソケットの種類はデバイスの用途（SSDだとかWifiだとか）によって決まる
• Wikipediaの説明を見ると「多くのレーン数を備えて高速化…何かすごい規格！？」と読めるけど、あくまでも規定しているのは「カードの形状と端子の配列」
  • （PCI Expressに比べて）小さなスペースで挿抜可能な高速バスのデバイスをつなげる、というのが利点になるのかな
• Key-IDが2つの場合、任意の組み合わせが使えるように見えるが、そうではなく規格で使用できる組み合わせが決まっている

最初、Wikipediaの説明を見て「いまいち納得出来ない…」と思って、PCI-SIGの仕様書を読んでみて上記の通り納得ができた。

AVRでSDとISPを共用する場合、どのように端子を接続すれば良いのか？
仕様書とかネットとか見て調べてみた。
（間違っていたらご指摘お願いいたします）

ISPの仕様書は以下を参照。

• http://www.atmel.com/images/doc0943.pdf

CPUはATMEGA328/168/88をターゲットに。

要点としては以下のとおりとなる。

• コネクタの端子は以下のとおり
  • 
• 実際の通信はSPIに従う
• ResetがLowの時にSPIでデータを送る
• ISPと他のデバイスと端子共用することができる
  • 外部からの駆動で影響を受けないように直列に抵抗を入れる

こんな感じの回路で良いのかな。

週末に実家に帰ってました。
その際に行ってきた、蒲郡のあじさいの里。
あさじさいはいろいろな色になるので、面白いなと。

先週末に引越し完了しました。
通勤時間が徒歩10分から電車含めて1時間15分ぐらいに変わります。
とは言っても、座って行けることと、何年もここにいるわけでもないので、
今のうちだけかなぁという感じはしています。

今週末に引っ越すため、荷造りなどを進めています。
今まで住んでいたのが会社から徒歩で行ける場所、
今度引っ越す場所は電車で1時間ぐらいの場所、結構遠い。。。
1年後ぐらいに引っ越すことを見越してのことなので、
まぁちょっとの間は辛抱かな。

前回の記事（Yoctoのパッケージのconfigureオプション - yasuharu's Diary http://yasuharu.net/diary/2797）の続き

Yoctoでiconv関連エラーが多いなぁと思ったら、すでにインストールしていたiconv（ソースコードからビルドしていたもの）が影響していて、
ビルドエラーが出ていたみたい。

work/x86_64-linux/pkgconfig-native/0.28-r0/pkg-config-0.28/glib/glib/gconvert.c:66:2: error: #error GNU libiconv not in use but included iconv.h is from libiconv

ひとまず、/usr/local/{lib, include}に入っていたファイルを移動させれば、この辺りの問題は解決された。

Yoctoを最近いじっています。
手始めに最小構成でビルドしようとするも、pkg-configがエラーでこけてしまう…。

work/x86_64-linux/pkgconfig-native/0.28-r0/pkg-config-0.28/glib/glib/gconvert.c:66:2: error: #error GNU libiconv not in use but included iconv.h is from libiconv

なぜpkg-configなのにglicでエラー？ と疑問だけど、glibcとpkg-configが相互に依存をしているようで
pkg-config側で自分で必要なglibcを用意しているみたい。
今回のエラーは、ちょうど内部で使用するglibcのビルドに失敗している。
調べてみると、glicがiconvを使っていて…という話しらしい。

• glibのmake時に「error GNU libiconv not in use but included iconv.h is from libiconv」エラーが出たので対処
  • http://d.hatena.ne.jp/rx7/20090619/p1

with-libiconv=gnuを追加すればOKとのこと。
これが何を意味するかはよくわかっていない。

次に疑問になるのは、このconfigureオプションをどこで設定するか？

• linux - How to give options for "configure" using yocto recipes? - Stack Overflow
  • http://stackoverflow.com/questions/25995070/how-to-give-options-for-configure-using-yocto-recipes

EXTRA_OECONFで設定すればよいとのこと。
pkg-configであれば、以下に記述があるので書き換えればとりあえずは動く。

poky/meta/recipes-devtools/pkgconfig/pkgconfig.inc

ただ、実際にはbbapendでパッチをあてるべきらしい。

• bbappend でレシピにパッチを当てる
  • http://www.sinby.com/backyard-report/004-Yocto/use-bbappend.html

こっちについても試してみよう。

ちょうど今日Zenfone2が発表されていて、何となく良さそうだなーとは思うものの、
何かやたらと電池食いそうだなこれ、という感じがそこはかとなく。。。
ということで、在庫限りにならないうちにZenfone5を買うことにしました。

Zenfone2の売りの一つに急速充電ができること、とあるけど、
代償として電池の劣化が早いと思うんだよね…。
珍しくAtom使ってるし、カタログにTDP載ってないし、何となく怪しいところが多い。