« 2009年06月 | メイン | 2009年08月 »

2009年07月 アーカイブ

2009年07月19日

RubyKaigi2009のRejectKaigiで発表してきました

Ruby会議2009のReject会議、元々は最終日のスタッフが撤収作業中に行なう予定なのですが、2日目のビアバッシュ中にも急遽開催が決定されたようです。そのReject会議(別名:酒の肴)で発表してきました。資料を公開しておきます。
以前、OSC2008Kansaiで発表した資料をマスタにしたので、2時間ちょっとで作成しました。編集中に気付いたのですが、OSCからちょうど一年なんですね。驚きました。前回は念入りにリハーサルを行ないましたが、今回はイメージトレーニングのみの一発本番。
発表の番になってプロジェクタに端末を繋いだら、原因不明のメモリ不足とか言われて本当に焦りました。10日以上起動しっぱなしのMacで資料作成中に、JSONを画面いっぱいに表示したスライドを作成中に、Keynoteの動きが緩慢になったため、これが原因の可能性があるんじゃないかと思っています。順番を変わってもらって、モニタの設定をし直して再度プロジェクタに繋いでも同じエラーで、どうしようかと思っていたのですが、「そのままで!」のような事を言われたので、編集画面のまま発表しました。
発表中は、自分で何を言っているのか、時間がどれだけかかってたのかもわからないくらい緊張していました。資料作成中から手が震えて、作業に支障が出る程。蚤よりも心臓が華奢かも...。
これまでで、一番疲れたRubyKaigiだったかもしれません。いや、後一日あるんですけどね。
2009/07/20 追記
技評さんのRuby会議2009のレポートに載りました。Reject会議のレポートはないと思っていたので驚きです。記者の方、ありがとうございます。
2009/07/20 追記2
Ustreamでも中継・録画されていたようです。スタッフの方、まわりが酒を飲んでいる中、ありがとうございます。後半はセリフを忘れ、スライドを見てセリフを思い出し喋り出しています。慣れていないのに一発本番はやめておいた方がいいという典型例かもしれません。
3分の時間中、2分ちょっとしか喋っていません。もう少しわかりやすいようにゆっくり喋るか、スライドを増やすか、準備していたデモをしたほうが良かったと今更ながら思いました。

2009年07月21日

携帯電話と個体識別番号とセキュリティ

簡単ログインの問題やドコモの新しいブラウザのリファラの問題等、最近まわりで、携帯電話向けサイトのセキュリティについて色々話されているのでのっかっておく。
個体識別番号について
個体識別番号が何か、色々説明したいけど、書き出すと長くなってしまうのでここでは詳細は言及しない。もの凄く簡単にいうと、モバイルサイト向けの住基カードの番号とでも思ってもらえば話は早いかも。
で、その個体識別番号が端末でも確認できるという話を、利用者は知っておくべきだと思う。まず、有名なのは携帯電話の端末のバッテリーを外したところに貼られているシール、そこに個体識別番号が印刷されている。この番号が悪意のある人間に知られてしまうと、普段の携帯向けサイトの利用状況にもよるけど、不正アクセス等が簡単にできてしまう可能性がある。バッテリーが外されると、携帯の一部の設定が初期化されるため、もし見られたら気付くと思っている人は間違い。実は、個体識別番号はもっと簡単に確認できる。
古くから携帯電話の情報を追っている人は多いと思うけど、携帯電話には特定の操作をすると通常とは違う動きをする。古くは、デバッグモードに変更する事ができる携帯電話があった。情報漏洩に厳しくなったのか操作自体がよりわかりにくくなったのか、それとも特殊な機材がないとだめなのかはわからないけど、最近ではデバッグモードについての情報を見つけられなくなっている。もしかすると、探せばあるのかもしれないけど、自分は知らない。
個体識別番号の話に戻すと、デバッグモードと同様に個体識別番号を見るための特定の操作というものが存在する。これはデバッグモードよりも色々な意味で簡単で、今でも充分通用する。見るための条件もあるけど、詳しく書くと悪用される危険性があるため書かない。でも、簡単に見られる可能性があるということは知っておいた方が良いと思う。さっきも書いたけど、古くから情報を追っている人にとっては既知の情報だから、そういう人達の中の悪意を持った人に、仮に端末をほんの少しの間でも渡してしまわないようにして欲しい。
これだけじゃ、危うさが伝わらないと思うので、個体識別番号を表示させた携帯電話の写真を貼っておく。慣れればあっと言う間に表示させる事ができる。
個体識別番号が画面に表示される
個体識別番号とあるキーワードを隠しています。

2009年07月22日

Greasemonkeyを作る時に気をつけていること

以前、書こうと思っていて、すっかり忘れていた事を、Ruby会議に参加して思い出したので書きます。

Greasemonkeyのscriptを作る時に、気をつけていることがあります。それは、サイト作成者に対する礼儀です。あるサイトのデザインが酷いと思ったからと言って、『xxxのサイトのデザインが酷いのでデザインを改善するグリモン書いた!』とblogに書きますか?私はこの様な事にならない様に気をつけてます。サイトのデザインが酷いと思うのはもしかすると自分だけかもしれません。ユニバーサルデザイン・アクセシビリティに気を払ってそういうデザインなのかもしれません。実際の所はわからないわけです。どういう事情なのかわからないのに、グリモンを書いて安易にネットに公開という様なことは、私は避けたいと思っています。

このため、サイトを改変する様なuserscriptはあまり実装しません。サイトの改変はしませんが、機能の追加は良くします。この二つはどこが違うのかわかりにくいとは思いますが、『おもてなしを追加できるかどうか』が基準だと言い換えればわかってもらえるんじゃないでしょうか。でも、『xxxするおもてなしを追加するGreasemonkey』はわかりづらいので『xxxする機能を追加するGreasemonkey』と書く事が多いと思います。そして、サイトの運営者と訪問者、双方の益になるかどうかも判断の基準になっています。

ここでは、Reject会議で話した『「るびま」をどこまで読んだのか記憶するuserscript』を例にお話しします。

私がRubyを勉強しはじめた当時、「るびまは全部読んだほうがいい」と勧められました。しかし、先頭から順に読もうと思っても難易度が混在していたため、初心者向けの記事や興味のある記事から読んでいたのですが、どこまで読んだかわからなくなってしまいました。読んでいないと思っていた記事の途中で既読と気付いたり、読んだつもりのものがそうでなかったり、間があいてしまった時にどの記事が読んでいる途中なのかさえわからなくなったのが、このuserscriptを作った動機です。
このuserscriptは「るびま」の各記事の既読を管理してくれます。このuserscriptは文章が記事か記事ではないかは一切判定せず、「るびま」の内部リンクを調べて、リンク先に対してのステータス管理を行なっています。記事か記事でないかは利用者に判断してもらう方針をとっています。

それでは、まず利用する側から、どのようなステータスがあればいいのか考えてみます。
まず、「既読」と「未読」です。そしてその中間の状態である「途中」。「目次」もステータスとして管理したところですが、その他にも記事ではないページがあるかもしれません。そこで、「目次」はステータスとせずに「記事ではない」というステータスにして、利用者に判断してもらえるようにします。ここまでで、ステータスは「未読」「途中」「既読」「記事ではない」の4つとなります。

これで十分でしょうか。いえ、不十分です。「未読」の分割が必要です。「未読」には読むつもりだけど読んでいない状態と、そもそも読むつもりがない状態があります。このため「読まない」というステータスも切り出します。そして、「読まない」のか読むつもりだけど「未読」なのかさえも決めていない、「保留」も追加します。
これで必要なステータスが全部で揃ったと思います。

「保留」
「未読」
「途中」
「既読」
「記事ではない」
「読まない」

では、これをサイトの運営者側の立場から見てみます。
どうですか。「読まない」というステータスが気になりませんか。できれば消したいですよね。

利用者が自分だけならステータスはこのままでも構わないかもしれませんが、公開するとなれば運営者も目にする事になります。運営者の事を考えると「読まない」ステータスを消すかと悩むところですが、利用する側から見ると「読まない」というステータスは必要です。これをどうすべきか、実際に悩みました。そこで、『今は読まないと考えているけどそのうち読むかもしれない』という意味合いを込めて、「読まない」を「読まないつもり」に変更しました。

最後に、アイコン化のための漢字をひとつ割り当て、用語を統一したものが下のステータスです。

『留』:「読むかどうか決めてない」
『未』:「読んでない」
『中』:「読んでいる途中」
『済』:「読んだ」
『除』:「記事ではない」
『削』:「読まないつもり」

若干、運営者側に譲歩してもらったようなステータスになっていますが、このuserscriptによって「るびま」を読む人が増えることを期待するとバランスはとれているのではないかと思っています。

これまで公開したuserscriptの中で、特定のサイト向けのものは『おもてなしを追加』するものがほとんどです。他にいくつかあげると次のようなものがあります。
ここまで、『おもてなしを追加』が動機のものを説明してきましたが、本題とは関係のない他の動機で作成したuserscriptを簡単に説明して終わりたいと思います。

単に『便利な機能』を実装したい場合ですが、そのままでは面白くないので時々ネタに走ります。どこでも実行できるようなuserscriptの場合は、特にネタ色が強くなります。
『やってみたい技術』や『知って欲しい技術』が動機のuserscriptがあります。userscriptの可能性を探ったり、JavaScriptでこんなこともできると知ってもらいたい等、技術的な動機です。このような場合は、どのサイトでも実行可能なuserscriptがほとんどです。そして、ほとんどの場合、ネタに走ります。
最後に上げる動機は、『ネタ』です。全サイトが対象になるような場合もありますし、確実にネタだとわかってもらえる(と私が思っている)サイト等が対象となることもあります。

2009年07月26日

「FIREFOX 3 HACKS」を読みました

JavaScript人口やGreasemonkeyの開発者数を考えると、日本発のFirefoxのaddonの数は非常に少ないのではないでしょうか。この原因は、日本語で読めるaddonの開発方法が少ないかと思います。「FIREFOX 3 HACKS」はFirefox全般について書かれていますが、この書籍の3章はaddonの開発方法が日本語で書かれた数少ない文章のひとつではないかと思います。1章から5章までで358ページあるのですが、3章にはなんと140ページ、約4割も割り当てられています。Firefoxユーザだけでなく、Firefoxのaddonを開発したいと考えている人にお勧めします。
このエントリーでは「FIREFOX 3 HACKS」を読んで、後で読み返したい部分や気になった点等を列挙します。
まず、はじめに何点か注意点。
本の内容を書き過ぎて購入者が減ってしまい、著作陣に迷惑をかけてしまうのは本意ではありません。このため、書籍が手元にないとわかりにくい書き方をあえてします。
文章が膨大になると思いますので、リンク等は特に設定せずに書いていく事にします。
ほとんどを通勤中の電車内で読んだため、疑問に思った事があっても実行環境がありませんでした。このため、動作確認等を全くしていません。誤った記述が含まれている含まれていると思います。
文中にChromeという言葉が頻繁に出てきますが、これはGoogle Chromeの事ではなく、Firefoxの用語です。Google Chromeの話は一切出てきませんので気をつけて下さい。関係ない話ですが、Googleが同じ名前を用いてしまったため、FirefoxのChromeの情報が探しにくくて仕方がないです。
この本は50余りのHACKが5章にわかれて構成されています。言及している場所を示す時に、ページ数と共にどのHACKなのかを番号とともに表示するようにします。また、ページ内の場所を示すために代替の位置を分数で併記する場合もあります。例えば、「P12 #1 1/3」の場合は、12ページのHACK #1についてページの1/3ぐらいの位置に書かれた文章について言及しています。このエントリーは初版第1刷をもとにしています。版が変わった場合、ページ数が変更になる可能性がありますのでご注意下さい。
#22~#25はこの本の最大の難所だと思います。通読を目指している人の多くはここで断念してしまうかもしれません。ブックマークや履歴等を操作するaddonを開発したい場合には必須だと思いますが、そのような操作を行なわないのであれば後回しにしてしまっても構わないと思います。#27には#22~#25に関連した内容が書かれており、理解しにくいかもしれませんが、そうゆうものだという感覚で良いのではないでしょうか。
3章は前出の通りaddonの開発について書かれています。しかし、JavaScriptよりの話が多く、addonのGUI部分を記述するためのXULについてはほとんど書かれていません。筆者陣も勧めている通り、XULについての記述が多い「Firefox 拡張機能開発チュートリアル」という電子ファイルをオンラインで読む事ができますので、合わせて読む事をお勧めします。
1章
[P12 #1 9/10]
APNG作成ツールのURLがあります。
[P15 #2 4/5]
ロケーションバーの自動補完リストに、何がどのような順で表示されるかを決定する方法について書かれたページのURLがあります。
[P19 #3 3/5]
スマートブックマークフォルダの検索条件を細かく指定する方法について書かれています。
[P20 #3 1/2]
スマートブックマークフォルダの検索条件の主なパラメータについて一覧にまとめられています。
[P25 #4 1/5]
Firefoxのブックマークツールバーはどれだけブックマークが多くても横一列に表示されます。表示領域が足りない場合は省略されて「»」にまとめられてしまいます。ここには、ユーザスタイルシートを書いて、ブックマークツールバーを多段表示する方法についての記述があります。
[P29 #5 1/6]
Firefoxのウィンドウの右上には検索バーが表示されています。この検索バーに新しい検索エンジンを登録する方法について書かれています。また、検索エンジンを提供しているサイトの一覧へのURLが書かれています。
[P31 #5 0/1]
複数の単語でページ内検索を行なったときにページ内を単語別に色を変えハイライト表示をするaddon、そして日本語を入力中でもページ内のインクリメンタルサーチが可能になるaddonが紹介されています。
[P31 #5 1/2]
前出の検索エンジンの作成方法の簡単な説明と、詳細なドキュメントのURLがあります。
[P46 #8 0/1]
「不用意に実行してしまう軽減すること」は記述ミスかと思います。
[P51 #9 0/1]
プロファイルフォルダは、所定の位置でないと認識されないと思っていたのですが、そうではないとのことです。ここにはプロファイルフォルダの位置を、相対パスや絶対パスで指定する方法が書かれています。
[P52 #10 4/5]
プロファイルフォルダ内には個人辞書情報というものがあるらしいのですが、何が保存されているんでしょうか。

2章
[P96 #18 3/5]
Greasemonkey Scriptはバージョン指定が可能とは知りませんでした。
[P96 #18 4/5]
トップレベルドメインはまとめて指定できるんですね。Google向けのScriptを書く時に役にたちそうです。
[P97 #18 1/5]
GM_getValueにはデフォルト値が指定可能だそうです。
[P97 #18 1/8]
GM_registerMenuCommandには第5引数まで指定が可能なんですね。何に使うんでしょうか。
[P99 #18 2/5]
E4Xを使うとヒアドキュメントのような事ができるのは知っていましたが、このような記述をすることで「+」で連結していく事もできるんですね。これは是非覚えておきたい記述方法です。

3章
[P105 #20 2/5]
addon作成の際に非常に便利そうなFUELについての説明です。
[P111 #20 2/5]
activeWindowのインスタンスの仕様のため、一致したWindowオブジェクトが単純には見つけられないのはハマりどころかもしれません。代替手段はあるんでしょうか。
[P111 #20 1/8]
activeTabもactiveTabと同様の仕様のようですが、こちらには回避方法が書かれています。
[P114 #20 1/8]
BookmarkオブジェクトもBookmarkFolderオブジェクトも同様の仕様のようですが、こちらも回避方法があります。
[P117 #20 1/2]
ブックマークのタグの誤った操作方法で、ブックマークのデータを破壊してしまう問題を回避する方法が書かれています。
[P126 #20 3/5]
表が誤っているようです。定数名とそれの説明内容が一致していません。
[P148 #22 1/2]
遷移元と遷移先を入れかえるために、[P147 #22 7/8]のSQLを書き変えています。ちょっと自信がないんですが、WHERE句内のvisit_typeの判定にはfrom_infoではなくto_infoを用いるべきなのではないでしょうか。
[P152 #22 1/2]
SQLが間違えている気がします。COUNT関数を使用するサブクエリは、hテーブルにJOINして、COUNTされたカラムの別称をORDER句に指定しないと取得できないのではないかと思います。それともここに書かれているように、サブクエリそのものをORDER句内に直接書いても動作するのでしょうか。書いていたら動作しそうな気がしてきました。これが動作するのなら実行速度がはやくなりそうな気がします。
[P165 #23 2/3]
getChildFolderの名称が名前と一致していないと思います。getChildFolderByNameが妥当ではないでしょうか。
[P171 #23 0/1]
作成時のイベント名はcreatedじゃなくaddedを使うんですね。
[P175 #23 1/2]
ファビコンの登録方法が書かれています。
[P177 #23 3/5]
ここでは、#20を参照するように書かれていますが、#20は20ページ以上もありどこを見れば良いのか戸惑いました。該当する情報は表20-25だと思います。
[P183 #24 9/10]
#24を読むとスマートブックマークの検索条件の詳細な指定方法を知ることができます。
[P184 #24 3/4]
ここの表のメソッドのように、配列も渡しているのにも関わらず配列の長さを渡すようなものが多いのですが何故なんでしょうか。渡した配列自身から簡単に求まると思うんですが、何か理由でもあるのでしょうか。
[P185 #24 2/3]
表24-2にはスマートブックマークで利用できる検索条件が書かれています。
[P192 #24 2/5]
サンプルコードが間違えているようです。「var queries = [query];」とありますが「var queries = [];」が正しいのではないでしょうか。
[P198 #24 1/8]
タイトルのソートについての例外的な挙動について書かれています。この挙動は変更される可能性があるのでしょうか。他と同様の動作をしないのであれば別の定数を割り当ててあれば親切だったかと思います。将来、もし他の条件と同じような動作をさせる事が可能となった場合には、どのような定数になるのでしょうか。
[P199 #24 1/8]
includeHiddenの意味合いは他のプロパティと意味合いが逆になっています。
[P202 #25 7/8]
例外的にpropertyBagは読み書き可能のような書かれ方をしていますが、表25-3では読み取り専用となっています。[P203 #25 7/8]にその理由が書かれていました。
[P206 #25 5/6]
hacChildrenへの情報の反映のタイミングは本当にクセがありますね。これは知らないと確実にハマります。
[P210 #25 0/1]
「steps.push();」となっていますが「steps.push(step);」だと思います。
[P211 #25 0/1]
コンポーネントの名前空間の制御について書かれています。これは知っておきたいですね。
[P211 #25 2/5]
モジュールの評価が一回だけというもの重要な情報かもしれません。
[P211 #25 3/4]
モジュールの公開するメソッドや変数の指定はEXPORTED_SYMBOLSを使うようです。
[P213 #26 9/10]
標準で指定されているResource URIと、Resource URIの指定方法が書かれています。
[P214 #26 3/4]
サンプルコードで唐突にioServiceオブジェクトが使用されています。また、次の行ではサービスが読み込まれているにも関わらず、変数への代入が行なわれていません。varの位置もおかしいので記述ミスだと思います。
[P217 #27 1/2]
引数の「前回の残り秒数」がどう使われるのかが全く予想できません。getDownloadStatusは「メソッド」に書かれている引数の数と「変換例」に書かれている引数の数が一致しません。この記述は多分間違いだと思います。また、getTimeLeftの「変換例」は渡した値がそのまま戻ってきています。このため「前回の残り秒数」の使い方を推測もできませんでした。
[P220 #27 1/3]
Microformatsの情報のURLが書かれています。
[P221 #27 2/5]
getMostRecentBackupの説明が重複しています。
[P226 #27 1/8]
デバッグ用のアサーションが使えるようです。動的言語なのが理由ではないかと思いますが、メソッドがひとつしかありません。
[P228 #28 0/1]
ここに書かれているコードは、ここだけでは終わりません。次ページ[P229 #28 7/8]の最後のほうに書かれているコードへと続いています。ここのページだけを読むと、Firefoxがコンポーネントを呼び出す方法が理解できません。私は何度も読み返した後にやっと気付きました。
[P228 #28 1/3]
15行目と19行目の処理は必要なのでしょうか。次ページの_xpcom_categoriesに登録しているapp-startupをfinal-ui-startupに変更しておけば、15行目、19行目の処理は不要な気がします。イベントを動的に追加/削除する例を示すためにこういう書き方をしているのか、それとも何らかの理由があるのか不明です。
[P229 #28 1/1]
欄外に、GUIDを生成するツールやサービスについての情報があります。
[P231 #28 1/2]
domwindowopenedの名称がここまでのイベント名の命名規則と違いハイフンがありません。もしかすると、イベント名はコンポーネント依存なのかもしれません。
[P233 #28 1/8]
contractID周辺でsyntax errorが発生しそうです。多分、誤植だと思います。
[P236 #29 2/5]
デジタル署名についての説明が続いていますが、非常に混乱しました。install.rdfにはupdateURLが、update.rdfにはupdateLinkが書かれており、両者は同じものではない点に注意して下さい。ここも何度も読み返してしまった場所です。
[P236 #29 3/5]
デジタル署名ツールのURLと、ツールの簡単な使い方の説明が載っています。
[P239 #29 1/2]
ハッシュを求めるツールの取得方法が書かれています。LinuxやCygwinでは標準で使えるのでしょうか。

4章
[P242 #31 5/6]
確かGoogle GearsはDOM Strageに合流するようなアナウンスがあったと思います。このためここに書かれている事は過去のAPIとなってしまう可能性がありますが、とりあえず読み進める事にします。
[P247 #31 1/8]
どちらでも良い話ですが、図31-2を見てニヤリとしてしまいました。
[P250 #32 3/5]
ApacheでDOM Storageを使うには、localhostではなくダメらしいです。理由はわかりません。
[P251 #32 1/2]
innerHTMLが使われていますが、セキュリティやエスケープに言及しないのであれば、Firefoxの書籍なのでtextContentの方が良いのではないかと思います。実は、P248でも同様な処理がありますが、あちらはタグを使用しているためinnerHTMLを使用する理由は(エスケープはしていないとはいえ)あります。しかし、こちらではtextContentを使えば脆弱性をはらんだコードにもなりませんし、エスケープについての説明を省けるのでtextContentを使用するほうが良かったのではないかと思いました。
[P252 #33 1/3]
図33-1のサンプルが格好いいです。
[P253 #33 1/4]
ここまで、meta要素がある場合は指定される文字コードはUTF-8でしたが、ここではShift_JISが指定されています。理由は不明です。
[P263 #37 1/10]
ここまでのサンプルコードは比較的小さいものばかりでした。しかし、#37は最初から最後まで同じものを説明しています。先に全体を斜め読みしてから読んだ方がわかりやすいかもしれません。
[P264 #37 1/10]
「FlickrにXMLHttpRequest」となっていますが、「FlickrからXMLHttpRequest」が正しいのではないかと思います。
[P264 #37 2/5]
「&login;」という文字実体参照が使われているのですが、初めて見ました。何が表示されるのでしょうか。
[P264 #37 3/5]
if文の条件がクラスを元にしているの事が気になります。しかも、複数のクラスを指定しています。
[P265 #37 5/6]
「すべてnullを渡しています。」となっていますが、最後の引数「fresh」はundefinedだと思います。freshの定義されている場所を逆に辿っていくと、[P264 #37 9/10]の「login: function(fresh) {」の引数になります。これは、[P264 #37 3/4]で「users.login();」という呼び出され方をしていますので、nullにはならないでしょう。
[P266 #37 0/1]
「flickr.auth._getFrob()」とありますが、[P265 #37 1/3]は「flickr.auth.getFrob()」という形で呼ばれています。最初は、APIの仕様がそうなっているのかと思いました。しかし、良く見ると[P265 #37 3/5]で「'method': 'flickr.auth.getFrob'」と文字列で定義されており、[P266 #37 1/4]あたりで文字列編集と行ない「_」をつけて「flickr.auth._getFrob」とし、引数を連結させ、callback用の処理を文字列として生成しています。
[P266 #37 3/4]
唐突に「clearTimeout」が出てきていますが、ここまで「setTimeout」は使用されていません。
[P267 #37 1/2]
comfirmの引数が4つもあります。chromeのconfirmは引数を4つとると言う事でしょうか。windowsオブジェクトは使えないはずなので、window.comfirmではないはずです。
[P268 #37 1/6]
「&buttons.auth;」という文字実体参照の様なものがまたあります。もしかしてこれは多言語対応のための仕組みなのかもしれません。
[P269 #37 1/6]
低レベルの処理を行なう関数が多いのでわかりにくくなっているような事が書かれていますが、この注意書きは#37の最初のほう欲しかったと思いました。
[P269 #37 1/2]
「&buttons.upload;」という文字実体参照の様なものがここにもあります。
[P272 #37 3/5]
ここのコードは[P266 #37 2/3]の部分の再引用のようです。
[P275 #38 1/3]
「XULRunnerアプリケーションの実行」となっていますが、実質的に各OS別の簡易的なXULRunnerアプリケーションの作成方法が書かれています。
[P279 #39 0/1]
こちらはXULRunnerアプリケーションの本格的なパッケージングの方法が書かれています。
[P290 #40 0/1]
processing.jsは知っていましたが、ContextFree.jsは知りませんでした。これは面白そうです。

5章
[P293 #41 2/5]
色の違いは何を意味するんだろうかと思っていましたが、キャッシュなんですね。知りませんでした。
[P295 #40 2/5]
console.logで書式指定子が使えるらしいです。特に、オブジェクトリンクが便利そうです。Firebugの使い方は一通り読んだはずなんですが、すっかり忘れていますね。
[P296 #40 2/5]
FirebugのコマンドラインAPIの一覧です。
[P297 #40 1/6]
同様に、FirebugのコンソールAPIの一覧です。
[P300 #42 3/5]
Firebugを更に拡張するaddonは、ここで紹介されている以外にもあるようです。サポートサイトを見て下さいとのことです。
[P301 #42 9/10]
YSlowからは、以前読んだ『JavaScript:The Good Parts』に載っていたJSLintが組み込まれているようです。JSLintはそのうち利用しようとしていたのですが、YSlowから実行できるのであれば気軽に実行できますね。
[P302 #42 1/10]
ここから数ページに渡って、JSLintが推奨している13のルールについて解説されています。全て実践するかどうかは別にして、一度は目を通しておきたい内容です。
[P305 #42 9/10]
14番目のルールもあるらしいです。
[P306 #42 1/10]
Firebug上で、addon等のChromeのデバッグを可能にするChromeBugについて説明されています。addonを開発する時にインストールしたいと思います。
[P312 #43 3/4]
mozDrawTextには文字リテラルが渡されていますが、変数textを使うべきかと思います。
[P314 #44 1/2]
Canvasの情報へのURLが載っています。
[P315 #44 0/1]
GIFに対するanimated GIFのように、PNGに対するアニメーションPNGというものがあります。それがMNGとAPNGです。ここでは、何故2つあるのかの歴史的背景が説明されています。
[P320 #44 1/10]
APNGの仕様のURLが載っています。
[P320 #45 1/4]
Microsummaryの解説です。色々な情報をサイトから抽出し、ツールバーに並べておけるようです。MacのSafari+DashboardでできるWidgetのようなものの文字版と言ったところでしょうか。歴史的にはどちらが先なのかはわかりません。
[P322 #45 3/4]
「含ページ」とありますが「含むページ」だと思います。
[P323 #45 1/3]
Microsummaryの書き方を解説したページのURLが載っています。
[P323 #45 1/2]
Microsummaryを簡単に作成するジェネレータの簡単な解説です。手軽に作成できるのは良いですね。
[P329 #46 1/3]
配列の内包表記についての解説です。内包表記は便利なので覚えたいのですが、これまでのJavaScriptの文法と感覚的に一致しないため、なかなか覚える事ができなくて困っている書き方です。多分現行のIEでは使えなさそうですが...。
[P331 #47 1/2]
letはlet宣言はともかく、let文やlet式の書き方がわかりにくいと思っています。let文はif文に似ているのでまだなんとかなりそうですが、let式は「{}」が省略されたlet文と考えれば良いのでしょうか。
[P333 #47 1/4]
Iteratorコンストラクタの第2引数にtrueを指定するとkeysが返るようですが、valuesを返すような方法はないのでしょうか。
[P333 #47 9/10]
Iteratorに対してfor inすると配列が返るようです。
[P334 #47 2/5]
独自イテレータの作成方法です。[P333 #47 1/10]に、イテレータは全ての要素が返された後でnextメソッドを呼ぶと例外が発生すると説明されていますが、独自イテレータを作る時は、この例外を投げる処理を自分で記述しなければならないようです。
[P335 #47 5/8]
ジェネレータにはnextメソッド以外にもメソッドがあるようです。それらのメソッドの使用方法について書かれたURLが載っています。
[P335 #47 9/10]
ジェネレータで使用するyieldは、Rubyのyieldと同じ名前ですが、使い方が違うためいつも混乱します。
[P336 #47 1/10]
配列の内包表記の「[]」を「()」に書き変えるだけでジェネレータになるようです。
[P336 #47 9/10]
奇妙な記述の方法が載っています。オライリーの書籍の本文で顔文字を見たのは初めてかもしれません。(^^;
[P337 #47 1/2]
JavaScriptの将来を知りたいのであれば、やはりECMAScriptのサイトを参照するのが良いようです。
最後に
一番最初に『書籍が手元にないとわかりにくい書き方をあえてします。』と断りを入れていましたが、読み返してみるとわかりにくく書き過ぎた感じがします。また、「URLが書かれています」等の記述をもしたため、冗長になってしまいました。これらの点を改めると、読みやすくなるかとは思うのですが、もう書き直す気力がないためそのままにしておきます。

2009年07月29日

ヒウィッヒヒーの神様

PostとResがTLに巣食う 絶対Favo もらえるはずなの
落ちるサーバ 淋しく一人 マウス握りしめる私
復旧二時間 しかも遅延あり 相手はWassrにもいるんだから
今夜 OFF会 期待している FollowerのFollowerに

目立つには どうしたらいいの 一番の悩み
誰かをdisればいい そんなの嘘だと 思いませんか?

Boy Tweets Girl ReTweetの予感 きっと誰かが Resくれる
Followingなう ヒウィッヒヒーの神様 この人でしょうか

ノリでust 中継なのよ 未Followingの男の人って
Mixi はてブ Blogにtako3 さりげなく チェックしなくちゃ
待っていました タイムライン 早くProtect取って見せてよ
つぶやき素敵 アイコンも素敵 思わず見とれてしまうの

リア充で実況ならば @より#タグ
「DM送らせて」と さっそくOK ちょっと信じられない

Boy Tweets Girl Tweetできる文字数 きっと140を 超えてる
Followingなう ヒウィッヒヒーの神様 文字数数えて
Boy Tweets Girl Resするアドレス 元より短いbit.ly
Followingなう ヒウィッヒヒーの神様 どうもありがとう

よく見るまとめサイトに そう言えば 書いてあった
会社の人にIDばれそう
今週も 来週も さ来週もそっと oh tweeet!

Boy Tweets Girl 土曜日 日曜日 ひと月たったら 1000tweets
Followingなう ヒウィッヒヒーの神様 廃人しています
Boy Tweets Girl いつまでも ずっとこの気持ちを忘れたくない
Removingなう ヒウィッヒヒーの神様 爆発しろ!!!
ちなみに...
本家の方は来週公開らしいです。
Google

タグ クラウド