「本は死なない」を読んだ

本は死なない Amazonキンドル開発者が語る「読書の未来」

AmazonでKindleプロジェクトの立ち上げに関わった人が書いた本。電子書籍関連の裏話的な本なのかなと思って読んだがそうではなかった。電子書籍というよりも本、そして読書の過去と現在と未来について、著者の見識に基づいた興味深い未来予測が綴られている。

著者が変わった人で、ソフトウェア開発者としてのキャリアも長いらしく、章末のコラムに自身のウェブサイトへのリンクがあって、電子書籍リーダーでリンクを訪問するとソーシャルな機能を盛り込んだ自前の連動サイトでいろいろできる、とか面白いギミックもあった（残念ながら今はそのサイトはエラーが出てちゃんと動作していないようだ）。

著者は大の本好きらしく、紙の本や図書館などへの強い愛着を隠さず語っている。その一方で、電子書籍の時代を切り開いたKindleプロジェクトを推し進めた張本人として、愛する紙の書籍の文化をその手で追いやるやり切れなさを感じつつも、電子書籍がもたらす未来への明るい展望を確信してもいる。肯定的でバランス感のある人だと感じた。

紙の本で買って読んでみたが、電子書籍でも（できればKindleで）もう一回読んでみたいと思った。

TOEIC

リスニングは去年より難しく感じた。半分くらい聞き取れなかった。去年よりスコア落ちてる気がする。

リーディングは去年よりよくできた気がする。去年は最後の二問か三問は時間切れで適当にマークしたけど、今年はギリギリ時間内に最後まで読んで解答できた。

次回は三ヶ月後か半年後に受ける予定。

HTML Imports のスクリプト実行順序がよくわからない（解決済み）

コメントをもらって改めて該当箇所の解説を読み直したら自分の解釈間違いがわかって解決した。

HTML5 Weekly でこの記事をみつけた。 Introduction to HTML Imports — WebComponents.org

Execution order の説明の、この箇所がわからなかった。

Script inside an html import behave just like a script tag with a defer attribute. In the example code below, index.html will execute script1.js and script2.js inside component.html before executing script3.js.

defer 属性と同じように振る舞うのなら、 html import の中の script タグはメインドキュメントの script タグよりも後に実行されるはずでは？

---

defer の振る舞いは理解できる。

https://dl.dropboxusercontent.com/u/4289117/htmlimports/02.html
実行に時間のかかる script タグがあると、ブラウザのレンダリングはそこで一旦止まるので、最初に出現した script 要素のあとにある DIV 要素はしばらく表示されない。 JavaScript コンソールには、 a -> b の順に出力される。 Google Chrome より Firefox のほうが、表示のされ方が期待したものに近い。

https://dl.dropboxusercontent.com/u/4289117/htmlimports/03.html
defer 属性つきの script の実行は遅延されるため、最初に出現した defer 属性つきの script タグの直後にある DIV 要素は即座にレンダリングされる。 JavaScript コンソールには、 b -> a の順に出力される。

https://dl.dropboxusercontent.com/u/4289117/htmlimports/01.html
defer と同じ振る舞いになるんだとしたら、 JavaScript コンソールには b -> a の順に出力されるだろう、と期待したが、実際には a -> b の順に出力された。

Google Chrome バージョン 39.0.2171.95 (64-bit)

Researching a new form of HTTP caching optimization を読んだ

Researching a new form of HTTP caching optimization - Phusion Blog を読んだ。議論を呼んでいた Turbocaching についてちょっと詳しい説明があった。

Vary ヘッダを使うとキャッシュを返していいかどうかをリクエストの内容によって切り替えられるが、 Cookie ヘッダは Google Analytics とかのユーザートラッキング情報で頻繁に変更されるので、 Cookie ヘッダ全体を Vary の対象に含めてしまうとキャッシュを返してよいケースでもキャッシュが使えなくなる。

というリサーチを経て、アプリケーション側で任意の名前の Cookie をセットし、 Passenger の起動時オプションで同じ Cookie 名を指定することで、 Passenger が Cookie ヘッダをパースして指定された名前の Cookie の値だけをチェックし、キャッシュを使えるか判断する、というのが Passenger 5 のパフォーマンス改善の目玉である Turbocaching の仕組みらしい。

Vary を工夫するというアプローチはアプリケーションの実装次第で Passenger 以外のウェブサーバでも利用できそうな気がする。試してないけどこんなコードでどうにかならないだろうか。

class SessionsController < ApplicationController
  def create
    cookie[:user_id] = current_user.id
  end
end

class UsersController < ApplicationController
  def show
    @user = current_user
    response.headers['Vary'] = ['Accept-Encoding', 'X-MyApp-UserId']
  end
end

$.ajax({
  url: '/users/me',
  type: 'GET',
  headers: {
    'X-MyApp-UserId': $.cookie('user_id')
  },
  dataType: 'json'
})

アプリケーションのフロントエンドを Single Page Application ぽく実装して Ajax と PushState を使えばキャッシュの利用機会を増やせる、というのは、実際そういう作りのアプリケーションを仕事でいくつか開発運用してきた身としては、言うほど簡単じゃないよ、と思った。

三菱東京UFJ-VISAの会員専用WebサービスはICクレジットカード（単体型）とスーパーICカード（キャッシュカード一体型）で登録・閲覧経路が違う

Moneytreeを使い始めたので三菱東京UFJ-VISAのICクレジットカードをアカウントに追加しようとして、まず会員専用Webサイトに登録しようとしたら、自分のカードでは登録できなかった。

三菱東京UFJ-VISAのサポートに電話で問い合わせたところ、キャッシュカード一体型のスーパーICカードの場合は三菱東京UFJダイレクト内のメニューから確認するようにと案内された。

同じタイミングで、三菱東京UFJ銀行の口座をMoneytreeのアカウントに追加しようとしたところ、何度繰り返しても「直接ログインして「再接続」をタップしてください」という表示で止まってしまっていた。

Moneytreeのサポートにメールで問い合わせたところ、やはり三菱東京UFJダイレクトから「オンラインショッピング認証サービスの登録」を行うようにと案内された。

三菱東京UFJダイレクトのオンラインショッピングサービスに登録してクレジットカードの利用状況明細をWebで閲覧できるようになると、Moneytreeのほうでも三菱東京UFJ銀行の口座残高が反映され、さらにクレジットカードの引き落とし金額も同時に反映された。

改めてICクレジットカードの説明をみてみたら、一体型の場合はダイレクト経由でWeb明細を確認する旨が記載されていた。

会員専用Webサービス新規登録：三菱東京ＵＦＪ-ＶＩＳＡ | 三菱東京ＵＦＪ銀行