先日、Firefox add-onでGoogle Books用の画像zipperを作ったわけですが、同様にiPadでは見れないからってことでガンガンONLINE用の画像zipperを作ったんですよ。ビューワがFlashなだけで、画像は別途jpgで取得出来ますんでね。やっぱり、PCの前で座って読むよりiPadに入れて寝転がって読むほうが、UX的に見て優れていると思いますわ。
ということなんですが、このadd-onは流石に公開出来ませんな。あからさまに「複製は法律により禁じられています」と来られちゃね。複製が駄目ということならば「ブックマークレットでdocumentをクリアして画像だけを表示する」という手もありなんでしょうが、流石に処理内容的にボリュームが大きいので手を出しづらいところです。mobile Safariにもユーザスクリプティング環境があればなぁと。
ということで本件に関しましては、個人でこっそりと楽しませていただく事にいたします。
2010年8月5日木曜日
2010年7月22日木曜日
[Programming] Google Books の画像を ZIP でまとめる Firefox アドオン
寝転がって iPad で本や楽譜を読む日々なのであります。そんな中、Google Books で公開されている LIFE や Popular Science 等のアーカイブはまさに宝の山なのですが、Mobile Safari ではスクロールバーが表示されないので読めないという状態になっています（正確に言えば←→ボタンがあるので、これで読み進めることは可能なんですけど、これがまたエラく小さいんで押しづらいんですわ）
なんらかの手段によりダウンロードして読むしか無いというわけですが、Google Book Downloader はWindows 専用ですし、グリモンの Google Book Downloader スクリプト+ FlashGot もダウンロードの自動化は可能なものの、ZIPにまとめる作業が要ります。
幸いなことに Firefox アドオンでは nsIZipWriter が使えますので、ここはひとつ作ったれということで作ってみました。グーグル先生に怒られそうな機能ですし、Mozillaのアドオンギャラリーに登録するのは結構ダルいので、野良 XPI として Dropbox の公開フォルダに入れておきます → googleBooksZipper.xpi
なお、手許に Windows 環境が無いので動作検証はしていないのですが、OS の違いを吸収する処理（パスデリミタの切替くらいしか無いんですけどね）は行っているので、多分、Windowsでも動作するでしょう。
単機能なアドオンなので説明は不要でしょうが、一応、取説的なものを以下に書いておきます。
googleBooksZipper.xpiをインストールすると、コンテキストメニューに
と、現在開いている本を ZIP で保存するという項目が追加されます。この項目を選ぶと
と、ZIPファイルの保存先を聞いて来ますので、お好みの場所を選んで「保存」ボタンを押すと、
と、小さなウィンドウが開きます。このウィンドウでは出力する画像の横幅（ピクセル数）が設定出来ます。デフォルトとして1024が設定されていますので、お好みで変えてください。"close this dialog when completed" というチェックボックスがありますが、これにチェックを入れておくと、処理終了後にこのウィンドウを自動的に閉じるようになります。
設定後、ZIP ボタンを押すと処理が開始され、進捗が表示されます。処理の手順としては、まず各ページの画像URLをGoogleに問い合わせます。
続いて、各画像をダウンロードしテンポラリファイルに保存します。
各画像のダウンロードが終わると ZIP 処理が行われ、完了すると
と、その旨が表示されます。これで ZIP ファイルが所定の場所に出来ているはずなので、あとは CloudReaders など、ZIPファイルに対応したリーダーに放り込んで読みましょう。
なお、私は books.google.com を利用しているのですが、books.google.co.jp だと画像のダウンロードが中断してしまうことが多々あるようです。原因は不明なのですが、中断した場合はいったん close して最初からやり直すしか今のところ手がありません。一見したところアクセス制限してるぽいので、ウェイトを入れる必要があるのかもしれませんね。
なんらかの手段によりダウンロードして読むしか無いというわけですが、Google Book Downloader はWindows 専用ですし、グリモンの Google Book Downloader スクリプト+ FlashGot もダウンロードの自動化は可能なものの、ZIPにまとめる作業が要ります。
幸いなことに Firefox アドオンでは nsIZipWriter が使えますので、ここはひとつ作ったれということで作ってみました。グーグル先生に怒られそうな機能ですし、Mozillaのアドオンギャラリーに登録するのは結構ダルいので、野良 XPI として Dropbox の公開フォルダに入れておきます → googleBooksZipper.xpi
なお、手許に Windows 環境が無いので動作検証はしていないのですが、OS の違いを吸収する処理（パスデリミタの切替くらいしか無いんですけどね）は行っているので、多分、Windowsでも動作するでしょう。
単機能なアドオンなので説明は不要でしょうが、一応、取説的なものを以下に書いておきます。
googleBooksZipper.xpiをインストールすると、コンテキストメニューに
と、現在開いている本を ZIP で保存するという項目が追加されます。この項目を選ぶと
と、ZIPファイルの保存先を聞いて来ますので、お好みの場所を選んで「保存」ボタンを押すと、
と、小さなウィンドウが開きます。このウィンドウでは出力する画像の横幅（ピクセル数）が設定出来ます。デフォルトとして1024が設定されていますので、お好みで変えてください。"close this dialog when completed" というチェックボックスがありますが、これにチェックを入れておくと、処理終了後にこのウィンドウを自動的に閉じるようになります。
設定後、ZIP ボタンを押すと処理が開始され、進捗が表示されます。処理の手順としては、まず各ページの画像URLをGoogleに問い合わせます。
続いて、各画像をダウンロードしテンポラリファイルに保存します。
各画像のダウンロードが終わると ZIP 処理が行われ、完了すると
と、その旨が表示されます。これで ZIP ファイルが所定の場所に出来ているはずなので、あとは CloudReaders など、ZIPファイルに対応したリーダーに放り込んで読みましょう。
なお、私は books.google.com を利用しているのですが、books.google.co.jp だと画像のダウンロードが中断してしまうことが多々あるようです。原因は不明なのですが、中断した場合はいったん close して最初からやり直すしか今のところ手がありません。一見したところアクセス制限してるぽいので、ウェイトを入れる必要があるのかもしれませんね。
2010年4月1日木曜日
[Firefox] 用意周到か過剰コンプライアンスか
[HACKS.MOZILLA.ORG] privacy-related changes coming to CSS :visited
こりゃまた思い切ったことをしはりますな。getComputedStyle()以外にも visited なリンクをセレクタで取り出す方法は結構あるんで、虱潰しにやっていくしかありませんな。他のブラウザの挙動も併せて調べとかんといかんわけで、ちょっとうへぇな感じ。まぁ、W3Cの尻拭いは現場で何とかするという気概は見上げたものですが。
こりゃまた思い切ったことをしはりますな。getComputedStyle()以外にも visited なリンクをセレクタで取り出す方法は結構あるんで、虱潰しにやっていくしかありませんな。他のブラウザの挙動も併せて調べとかんといかんわけで、ちょっとうへぇな感じ。まぁ、W3Cの尻拭いは現場で何とかするという気概は見上げたものですが。
2010年3月7日日曜日
[Programming] Chrome Extension は福袋的にした方が良い？
ここしばらく、ちまちまとChrome拡張機能をいじっております。で、「リンクのターゲットを_blankに書き換える」というありがちな拡張機能を試しに作ってみたわけです。正味の処理は
ということで、えらくメモリ食うんだなぁとびっくりいたしました。
確かに Firefox でも OOPP を初めとするプロセス分離作業が進められているわけで、各プロセス毎に分厚い土台を準備しなきゃならなくなるというのも時代の流れなのでしょう。
この驚きはあの時の驚きに似てます。C から C++ に移行した時、バイナリの肥大化にのけぞった時の驚きです。ただの Hello World が iostream にしただけで何でこんなにでかくなるんだよｗというやつです。C は高級言語じゃなくて超高級マクロアセンブラだという説を心底納得出来たのもこの時でした。まぁ、libc からこのかた分厚い土台に支えられてきた人間がいまさらメモリ効率がどうこうなんて言えた義理じゃねぇだろ、というのも重々承知ではあるんですけどね。
で、こういった状況を鑑みまするに、今後は単機能な拡張機能を個別に数多く入れるという考え方よりも、色々な機能を詰め込んだ多機能な拡張機能を一つだけ入れるという考え方の方がメモリ効率的に良いということになります。「福袋的」というのはそういうことです。要るか要らないかは置いといて、とりあえず色々詰め込んどけという手法です。
でもやっぱりこの手法には違和感を感じざるを得ないんですわ。小人さんがわらわらと群がり手を取り合って仕事するというファンタジー的・明治合体チョコボール的世界、すなわち、コマンドをパイプでちまちまとつないでいく世界を知っている人間からしてみれば、上で述べたような福袋的アーキテクチャは「何このゴリアテｗ」「かっこ悪〜」となるんじゃないでしょうか。
var l = document.querySelectorAll("a");
for (var i = 0; i < l.length; i++) {
if (!l[i].target) {
l[i].setAttribute("target", "_blank");
}
}
だけという、実にあっさりしたもの。御存知の通りChromeでは各タブおよび拡張機能ごとにプロセスが割り当てられるわけですが、どれくらいメモリ消費してるのかなと思いアクティビティモニタを見たところ
ということで、えらくメモリ食うんだなぁとびっくりいたしました。
確かに Firefox でも OOPP を初めとするプロセス分離作業が進められているわけで、各プロセス毎に分厚い土台を準備しなきゃならなくなるというのも時代の流れなのでしょう。
この驚きはあの時の驚きに似てます。C から C++ に移行した時、バイナリの肥大化にのけぞった時の驚きです。ただの Hello World が iostream にしただけで何でこんなにでかくなるんだよｗというやつです。C は高級言語じゃなくて超高級マクロアセンブラだという説を心底納得出来たのもこの時でした。まぁ、libc からこのかた分厚い土台に支えられてきた人間がいまさらメモリ効率がどうこうなんて言えた義理じゃねぇだろ、というのも重々承知ではあるんですけどね。
で、こういった状況を鑑みまするに、今後は単機能な拡張機能を個別に数多く入れるという考え方よりも、色々な機能を詰め込んだ多機能な拡張機能を一つだけ入れるという考え方の方がメモリ効率的に良いということになります。「福袋的」というのはそういうことです。要るか要らないかは置いといて、とりあえず色々詰め込んどけという手法です。
でもやっぱりこの手法には違和感を感じざるを得ないんですわ。小人さんがわらわらと群がり手を取り合って仕事するというファンタジー的・明治合体チョコボール的世界、すなわち、コマンドをパイプでちまちまとつないでいく世界を知っている人間からしてみれば、上で述べたような福袋的アーキテクチャは「何このゴリアテｗ」「かっこ悪〜」となるんじゃないでしょうか。
2010年2月20日土曜日
[Google] Chrome Extension を作ってみて
やっぱWebKit系もやっとかんとね、ということでGoogle Chromeのdev版を入れてみたのですが、やはり気になるのは拡張機能の作りやすさ。ということで実際に作って確かめるためにこんなのを作ってみたわけです。
で、結論としては「Firefox（というかXUL）でExtensionを作っている人やGreasemonkeyでページをいじっている人にとってはストレスがたまるのでは？」という感じです。
content_scriptsの制限のきつさ
XMLHttpRequestもlocalStorageも直接には使えず、すべてbackground_pageを別途作製してsendRequestもしくはconnectしないと使えない、というのは異常に思えます。せっかくmanifest.jsonにpermissions設定があるのですからXMLHttpRequestくらいは直に使えるようにしてほしいところです。まぁcontent_scripts程度であればGreasemonkeyのChrome版でGM_系APIが実装されるまで待てということでいいんじゃないでしょうか。
コンテクストメニューへのアイテム追加などが出来ない
すくなくともドキュメントを見た範囲では出来ないようで、これはかなり痛い。UIをいじりたければWebKit APIを使えと言うことなのでしょうか。いずれにしてもXULのオーバーレイという一貫した設計思想とはかけ離れているようなので、また勉強し直しですな。
XUL慣れしているとかえってイライラする
これもGoogle側にしてみれば「おれにいわれてもなぁ」なので、仕方ないっちゃ仕方ないんですけどね。たとえば右クリックされた単語を拾うならばdocument.popupRangeParentとdocument.popupRangeOffsetを使うという定石がFirefoxでは使えるわけですが、Chromeではそんなプロパティは無いわけで、DOM Rangeで書き直しすることになりそうです。他にも「XULなら出来るのに」というのがどんどん出てくるんじゃないでしょうか。
まぁ「まだこなれていないだけだから気長にいこう」というのもアリなわけで、しばらくはちまちまと楽しませていただくことにします。
で、結論としては「Firefox（というかXUL）でExtensionを作っている人やGreasemonkeyでページをいじっている人にとってはストレスがたまるのでは？」という感じです。
content_scriptsの制限のきつさ
XMLHttpRequestもlocalStorageも直接には使えず、すべてbackground_pageを別途作製してsendRequestもしくはconnectしないと使えない、というのは異常に思えます。せっかくmanifest.jsonにpermissions設定があるのですからXMLHttpRequestくらいは直に使えるようにしてほしいところです。まぁcontent_scripts程度であればGreasemonkeyのChrome版でGM_系APIが実装されるまで待てということでいいんじゃないでしょうか。
コンテクストメニューへのアイテム追加などが出来ない
すくなくともドキュメントを見た範囲では出来ないようで、これはかなり痛い。UIをいじりたければWebKit APIを使えと言うことなのでしょうか。いずれにしてもXULのオーバーレイという一貫した設計思想とはかけ離れているようなので、また勉強し直しですな。
XUL慣れしているとかえってイライラする
これもGoogle側にしてみれば「おれにいわれてもなぁ」なので、仕方ないっちゃ仕方ないんですけどね。たとえば右クリックされた単語を拾うならばdocument.popupRangeParentとdocument.popupRangeOffsetを使うという定石がFirefoxでは使えるわけですが、Chromeではそんなプロパティは無いわけで、DOM Rangeで書き直しすることになりそうです。他にも「XULなら出来るのに」というのがどんどん出てくるんじゃないでしょうか。
まぁ「まだこなれていないだけだから気長にいこう」というのもアリなわけで、しばらくはちまちまと楽しませていただくことにします。
2010年1月21日木曜日
[Firefox] 蚊帳の外
[YouTube] Introducing YouTube HTML5 Supported Videos
Flash の地位はまだ当分揺るがないから大丈夫とはいえ、こういう敗戦って、結構、リーダー不信を初めとする開発陣の士気低下に繋がってくるんですわ。まぁ去年の夏の時点ではっきりしていたことでもあり、気持ちの切り替えはとうの昔に済んでいるとは思いますが。
it requires a browser that supports both the video tag and h.264 encoded video (currently that means Chrome, Safari, and ChromeFrame on Internet Explorer).いちはやく video タグに対応したという実績があってもコーデックが theora じゃねー。先頭を走っていたつもりが、実はコースを間違えていましたと言うパターンです。オープンソースという夢に捉われすぎましたな。
→ videoタグとH.264コーデックの両方に対応しているブラウザが必要です（今のところ Chrome と Safari と ChromeFrame 拡張入りの IE ということになります）
Flash の地位はまだ当分揺るがないから大丈夫とはいえ、こういう敗戦って、結構、リーダー不信を初めとする開発陣の士気低下に繋がってくるんですわ。まぁ去年の夏の時点ではっきりしていたことでもあり、気持ちの切り替えはとうの昔に済んでいるとは思いますが。
2010年1月9日土曜日
[Firefox] extensions.checkCompatibility.3.6
Firefox 3.6 RC1 が出たので早速アップデートしたわけですが、アドオンの互換性チェックがまたしても有効になってしまったわけで、めんどくせーとか言いながらも extensions.checkCompatibility.3.6r1 を新規で作って falseとしたわけですが無効にならない。extensions.checkCompatibility.3.6p とか extensions.checkCompatibility.3.6r とか幾つか試したんですが駄目みたいで、うへぇとなったわけですが、なんの事はない、extensions.checkCompatibility.3.6 だけでOKでした。
この記述仕様に関してはこのページくらいしかオフィシャルな情報が見当たらないわけですが、RC版については 3.6->3.6.1 扱いということですか。そんなのどこにも書いてないやん。nsExtensionManager.js見ろやとのことですが、そりゃちょっと御無体ってもんじゃないでしょうか。
あと、about:config ではコンテクストメニューから新規作成出来るんですから、削除も出来るようにしてほしいとこです。今回、無意味な extensions.checkCompatibility ほにゃららがたくさん入ってしまったし 3.6a や 3.6b のエントリも不要になるので prefs.js を直接編集して削除したんですが、これしか手が無いというのはちょっとねー。
この記述仕様に関してはこのページくらいしかオフィシャルな情報が見当たらないわけですが、RC版については 3.6->3.6.1 扱いということですか。そんなのどこにも書いてないやん。nsExtensionManager.js見ろやとのことですが、そりゃちょっと御無体ってもんじゃないでしょうか。
あと、about:config ではコンテクストメニューから新規作成出来るんですから、削除も出来るようにしてほしいとこです。今回、無意味な extensions.checkCompatibility ほにゃららがたくさん入ってしまったし 3.6a や 3.6b のエントリも不要になるので prefs.js を直接編集して削除したんですが、これしか手が無いというのはちょっとねー。
登録:
投稿 (Atom)
