2010-02-08 [長年日記]
_ 改めて作り手としてFirefox周りの道具を整理してみる
今回の記事は自分のためでもあるけどこれから始める人向けの意味もある。もちろん漏れもあるし、単純に自分が知らないものもあるので、これどうよ?ってのがあったら教えてくれると嬉しいデス。
※ 以下のリストには Fx 3.6 じゃないと動かないものがあるかと思えば 3.6 では動かないものもあるので、もう少し静観した方がいいかも。
機械的に正しさをチェック
エラーコンソール
JavaScript と CSS のエラーをチェックできる。Firefox 標準添付。これがあるだけでもずいぶん違う。メニューの [ ツール ] → [ エラーコンソール ] で表示できる。
「エラー」と「警告」のタブだけ見ていればたいていの問題には対応できる。開きっぱなしにしていると IE 用の記述を含むサイトで警告だらけになって「お互いに大変だね」と思える。
Firebug
制作途中では HTML の「調査」に使うことが多いが、これも「コンソール」でエラーの様子を確認できるし、表示するエラーの種類を選択できる。(例えば CSS は無視して JavaScript のエラーだけを表示することができる。)
その他、リアルタイムにいろいろなものを確認できる。もちろん JavaScript の開発時には手放せない。
Web Developer
Firebug が現れるまでは Web 開発者必携と言われたものだが、今はあまりそこまで言われない。しかし Firebug にはできないことも多く、入っていないと困る。今も開発が続いているのはとても有り難い。
具体的には
- キャッシュを off に
- JavaScript を off に
- 任意のレベルの CSS や画像を off に
- form の情報を表示する
- 非推奨要素のハイライト
- table, ブロックレベル要素をハイライト
- 問題のある画像を探す
- 特定のウィンドウサイズへ変更
といったことに利用できる。
Html Validator for Firefox and Mozilla
tidy という HTML の文法チェックと修正を行えるツールを内蔵しているもの*1で、公開していない HTML のチェックを offline で行える。
Firefox extension の形で提供される HTML validator は
- onlinde でないと使えない
- 結局 online の validator サービスを利用しているから
- 公開されている URL を持ってないと使えない
- validator がアクセスしてこれないから
という制約のあるものがほとんどなので、これはとても重宝する。個人的にはいつもコマンドラインで tidy を利用しているが、同じことがブラウザから利用できて問題の箇所も確認しやすい。動的に生成された HTML に対してのチェックは明らかに tidy オリジナルよりこちらの方が楽。euc-jp のページでも shift_jis, utf-8 のページでも問題なく動作する。
※ このツールは Firefox 標準の View Source を上書きしてしまう。これをインストールしていると従来の形のソースを表示するウィンドウは使えない。
チェックツールの利用に際して
原則的には完璧を目指す。つまりエラーも警告もない状態。これは
- エラーや警告が大量にあると本当に直すべき致命的な問題の特定が難しくなるから
- せっかくチェックを自動化して目視の負担を減らしている意味がない
- 単純にエラーがないと気持ちいいし、ゼロになると達成感があるから
ただし、IE 対応などのためにどうしても正しくない記述にせざるを得ない場合もある。それは仕方ない。
以前はよく Another HTML-lint で 100点を目指すことに意味なんかないよという指摘が散見されたが、それは
- Another HTML-lint の宗教的なチェックを有効にしている
- ブラウザがお粗末
といったことが主な理由であって、本来エラーはあってはならない。というかエラーを含んだままでは「変更」のときに泣く。エラーのある状態でたまたま再現された見た目を頼りにしていると、ある日突然同じ見た目を再現できなくなる。未だにこのレベルの Web 制作/開発会社が後を絶たない。*2
目視支援
Popup ALT Attributes :: Add-ons for Firefox
alt 属性をバージョン 8 までの IE のようにツールチップ表示させる。
この挙動は本来 Web 的には正しいものではなく、IE 9 からは他のブラウザと同じように、alt に書かれたものは「画像が表示できないときにだけ表示される」ように変更される予定。
Top - FireMobileSimulator.org
ケータイの画面で概ねどのように見えるか確認する。基本的には画面のだいたいの大きさと絵文字の確認ができる程度と考えておくべき。特に古めのケータイは HTML の解釈の仕方やレンダリングにクセの強いものがあって、それはさすがに再現できない。
Firefox だけで特別なシミュレータがなくてもある程度作業できる、と割り切って使うと幸せになれる。(特に Mac には他にフリーのシミュレータはない。)
Dafizilla ViewSourceWith :: Add-ons for Firefox
HTML ソースを Firefox 標準のウィンドウではなく指定のエディタで開くことができる。
個人的には textarea 内の長文の編集に利用している。Thunderbird にも利用できるのでメールを書く際にも重宝する。
※ 以前は It'a All Text ! ( Firefox ) と External Editor ( Thunderbird ) を利用していたが、いずれも Fx 3, Tb 3 の移行のタイミングで芳しくない挙動をしまくったので常用から外れてしまった。
View Source Chart :: Add-ons for Firefox
HTML のソース上の文法ハイライトではなく構造の図示を行ってくれる。作っている最中のサイトではなく初めて見るサイトの HTML の構造を確認するのにたぶん便利。Web Developer でもある程度同じことができるけどこっちの方が見やすい。
個人的には使ってないけど、デザイン、HTMLコーディングの初学者に向いている印象。
HeadingsMap :: Add-ons for Firefox
HTML の見出しの構造だけをサイドバーに抜き出す。構造の確認と長文の閲覧に便利。
※ 以前は DocumentMap を使っていたが、更新が止まったっぽいので乗り換えた。
その他
ColorZilla :: Add-ons for Firefox
ブラウザウィンドウ内の各所の色を確認できる。そのまま色見の調整もできるので、すでに出来上がってるサイトを参考にしやすい。
YSlow :: Add-ons for Firefox
CSS はページの先頭で、JavaScript はページの末尾で読み込むようにすると速くなる、など表示速度を項目別にチェックしてくれる。Firebug の [ 接続 ] タブの方が詳細に確認できるが、YSlow はどのようにすれば速くなるのかを手ほどきしてくれる。
※ Google Pagespeed も入れてあるし試してみたけど、なぜか YSlow を使っている。なんでかは忘れちゃった。Pagespeed は名前がよくないよね。ノウハウの検索が不可能に近い。
作業支援
Pearl Crescent Page Saver
長いページのスクリーンショットをそのまま撮れる。Windows 用ならもっと高機能なものがあるけど、これで十分な気がする。
QuickNote :: Add-ons for Firefox
以前と違ってデスクトップ付箋アプリはほとんど使わなくなったが、それでもさっと開いて何かを書き留めておけるのは便利。無限に増やせるわけではないのもメモの散乱を防いでくれる適度な制約として活きる。
Dafizilla Table2Clipboard :: Add-ons for Firefox
IE + Office で可能な table の構造ごとコピーを可能にする add-on
Greasemonkey :: Add-ons for Firefox
迷ったけど。Greasemonkey というか実際には bookmarklet でもいいんだけど、ちょこっとしたツールを作って活用すると細かい省力化がはかれるのでやはり入れておくことにした。
自分で作って使っているのは以下のような感じ。ただし再利用できる形で公開はしてない。しようしようと思いつつ放置になっていたり、あまりに環境依存で公開できなかったりしている。
- basename( script_name ) 相当をページ最下部に表示
- ウィンドウを小さくしてケータイ向けの作業をしていたりするとアドレスバーが全然見えなくなってたりする。そんなときこれがあると便利。
- title と location.href を各種フォーマットで吐き出してくれるもの(対応フォーマットは PukiWiki, Hiki, Markdown, FSWiki, Hatena, TracWiki, Plain HTML)
- svn の DAV URL と Trac の Browser の URL を toggle させるもの
- Trac で確認していって、toggle させてすぐ checkout、みたいに使う。
開発向け
Live HTTP Headers :: Add-ons for Firefox
目視だけなら実は Web Developer, Firebug でも HTTP header の確認は可能なのだが、LiveHTTPHeaders は
- リアルタイムのモニタリングに適している
- 任意のフィルタを適用できる
- ログをファイルに保存できる
といったメリットがある。個人的にはよく Mechanize の処理を記述する際にそのひな形、比較対象として使っている。
Firecookie :: Add-ons for Firefox
Firebug 上で cookie を自由に操作できる。
Selenium web application testing system
Web アプリケーションの「操作」を自動テストするフレームワーク。Firefox では SeleniumIDE を使えば簡単に「操作」の記録、テストをくり返せる。テストの保存もできるので共有も可能。
XPather :: Add-ons for Firefox
要素の XPath を確認できるし、任意の XPath でどのような要素を抽出できるか確認できる。Firebug だけでも $x() である程度可能だけど、なんか XPather の方が好きで使っている。
Home - mozrepl - GitHub
Firefox に telnet で接続してコマンドラインで操作可能にする。Firebug でもかなりのことができるが、これは Firefox 全体を操作できるし、検索など独自の機能もある。
2010-01-26 [長年日記]
_ Mechanizeで無茶をする
自分にとって Mechanize による自動化はたいがい無理を通す行為である。分かりやすく言えば API なんかない、あるいはあっても足りないみたいな状態で、それでもどうにか自動化したいから Mechanize を使う。
Mechanize が持っている標準的な機能だけで済んでいる場合はまだかなりマシで、実際のところ無理というか「無茶」なレベルに突入してしまうことが、なぜかそれなりにあったりする。具体的には HTML が壊れているのでパースに失敗して、あるはずの要素がなくなっていたりする場合などである。
今回はそんな無茶の一部をご紹介。
パーサを Hpricot に変える
ずばり基本でしょう。
Mechanize は 0.9 以降デフォルトパーサを Hpricot から Nokogiri に切り替えているが、そもそも Nokogiri は HTML 用にできていない。XML 用の道具に、 Hpricot によく似たインターフェイスを付けたものである。HTML は自由度の高い書式で、XML 用のノコギリでは歯こぼれを起こすことがよくある。
そこでこの設定(0.9.0 〜 0.9.2)。
require 'hpricot' WWW::Mechanize.html_parser = Hpricot
cf.
- Mechanize の parser を Hpricot にする
- hpricot's hpricot at master - GitHub
- hpricot | gemcutter | awesome gem hosting
0.9.3 (以降?)はサブクラスの利用に注意
html_parser がインスタンスのアクセッサとして定義されたのでインスタンスごとに parser をセットできるようになったのはいいんだけど、Mechanizeクラスオブジェクトのインスタンス変数を self.class で参照して自身に書き戻しているので、
サブクラスに反映されない
状態になっている。(少なくとも Ruby 1.8.7 では parser が nil になって動かなかった。)定義部分は以下のような感じ。
class Mechanize
...
@html_parser = Nokogiri::HTML
class << self; attr_accessor :html_parser, :log end
def initialize
...
@html_parser = self.class.html_parser
end
...
end
動かすとこんな感じ。
$ cat sub_mechanize.rb class SubMechanize < WWW::Mechanize end $ irb irb(main):001:0> require 'mechanize' => true irb(main):002:0> a = WWW::Mechanize.new => (snip)irb(main):003:0> a.html_parser => Nokogiri::HTML irb(main):004:0> require './sub_mechanize' => true irb(main):005:0> b = SubMechanize.new => (snip) irb(main):006:0> b.html_parser => nil
恐らく Mechanize のインスタンスについては html_parser のセット方法に互換性をとりつつインスタンスごとに設定できるようにしたかったためにこうなったんだろうけど、いつもデバッグしやすいように独自のサブクラスを噛ましていた*1ので、まったく parse できない現象にハマってしまった。仕方ないのでサブクラスの中で独自に定義することにした。
class SubMechanize < WWW::Mechanize
def initialize
super
@html_parser = Hpricot
end
end
こんなんでいいのかな。
cf. RubyのMechanizeの0.9.3が6月8日に出てたっぽい - きたももんががきたん。
Field を作る
これはまだ初級。
Form#add_field!( name, value )
無駄に JavaScript に分離したフォームの場合、必要な field が HTML 上に存在しないことがよくある。その値を無理矢理 form 上に反映するために使う。
FileUpload を作る
これに気づいたときにはけっこう嬉しかった。add_field! では Field は作れても FileUpload は作れないから。
どうやるかというと、Form オブジェクトに対して instance_eval を使う。
Form#enctype = 'multipart/form-data'
Form#instance_eval {
@file_uploads << WWW::Mechanize::Form::FileUpload.new( name[, filename] )
}
もともと file_upload が存在しない form として解釈した場合は enctype が違うことがある(というか指定してないかも)ので手で変更してあげると吉。
Form を作る
instance_eval() を思い出してしまえば簡単。もう form そのものを解釈できませんでしたという凶悪な HTML 向け。
Page#instance_eval {
@forms << WWW::Mechanize::Form.new( node[, mech, page] )
}
node には Hpricot::Elem オブジェクトを入れてあげれば ok.
このとき、Hpricot::Elem になれば元の文字列はなんでもよいので、
Form.new( Hpricot( String#scan( /<form.*?>.*?<\/form>/m ).to_s ).at( 'form' ) )
みたいなこともできる。HTML が壊れているので正規表現でいったん form だけ引っこ抜いて、それを Hpricot オブジェクトに戻してやって Form を作る。途中の整形も思いのまま。
Page を作る
Page を作るのはちょっと手が掛かる。以前作ったものを gist に置いてあるので参考になれば嬉しい。
*1 http://gist.github.com/76140
2010-01-24 [長年日記]
_ freebsd-update で 6.4-RELEASE に
自宅サーバの FreeBSD は基本的にはお気楽実験用なんだけど、DNS cache サーバを兼ねているので事故るとまずい。そういう意味も含めて古めのものを追っかけてるんだけど、今まで使っていた 6.3 が 2010年1月いっぱいでサポートされなくなるので 6.4 に上げた。
freebsd-update
手順はこんな感じ。
freebsd-update -r RELEASE upgrade freebsd-update -r RELEASE install shutdown -r now freebsd-update install
library が上がって ports 上げろって言われたので以下の作業を追加。
portupgrade -af freebsd-update install
念のためもう一度再起動しといた。ports の full rebuild は途中で設定を何個か聞かれながらで丸半日以上掛かったかな?
そうしたら ircd-hybrid, nadoka, tiarra の起動周りがイマイチ、nadoka がうまくいったりいかなかったりしてる。もしかして nadoka が ircd より先に起きたりしてるのかもしれない。どうにか手動で順番もきっちり意識して再起動して意図した動きに。やっぱ ircd も God 管理にしなきゃダメだなぁ。
Trac が 0.11 で動かなくなった
Trac, pysvn 周りはいつもちょっとハマるので面倒で放置していたんだけど、portupgrade -af で一緒に上がってしまって案の定動かなくなった。
どうも PYTHON_EGG_CACHE が設定できていなくて cache を作るディレクトリが見つからないみたいなんだけど、
Apache + FastCGI
で動く設定が出てこない。なんか FastCgiConfig --initial-env じゃなくて PythonOption で渡すみたいなんだけど、edgewall の方にキチっと書かれてないなぁ。Python 読める人が自力で解釈してブログに書いてあるのはありがたいんだけど、0.11 が出てずいぶん経つのに情報が整理されてないのは Python 製のツールっぽくない印象。
とりあえず自宅で Trac は重要じゃないから今度考えよう。
2010-01-22 [長年日記]
_ イントラgem server運用開始
2009.10.29
09:14:00 >wtnabe< gemcutter サーバをイントラに立てられると便利だろうな
2009.12.03
21:14:52 >wtnabe< イントラに gemcutter サーバがあると便利だよね
酒を飲んだとかでなく、平気で同じことをくり返し言うようになってきている。まいりましたな。
それはともかく、gem server が簡単すぎてビビる件 を書いてから知らん間にずいぶん時間が経ってしまったが、やっと活用し始めた。
2010.01.22
11:37:34 >wtnabe< イントラに gem push したいしたいと思ってたけど、とり あえず Rakefile に scp する task 足した。permission を考えたくないから DAV 経由にした方がいいかなぁ。
どうしたかというと、cutagem で作った Rakefile に直接こんな task を書き足してお茶を濁した。我ながらひどい。
desc "push gem to intra gem server"
task :push_gem do
name = "#{NAME}-#{VERS}.gem"
sh %{scp name HOST:/PATH/TO/GEM_SERVER/gems}
end
こんなん。サーバ側では
/etc/cron.hourly/generate_gem_index
#! /bin/sh GEM_ROOT=/PATH/TO/GEM_SERVER gem generate_index -d $GEM_ROOT chown -R Webサーバにしたんだっけ $GEM_ROOT
こんな感じで回してる。
scp で投げるのやめて DAV で投げられるようにすれば権限とか owner とか面倒なこと考える必要なくなるような気もするけど、あんま考えてない。どうせしばらく自分しか push しないだろうし。
あとはイントラで他に動いてるホストの
/etc/gemrc
に、ひっそり
:sources: - http://HOST/PATH
で、gem を探すサーバを書き足してやる。
ちなみにイントラのgemはライブラリではなくshlauncherで固めたツール群の配信を想定している。
_ masa [Live HTTP Headerの3.6対応が放置されているのが困ったところですね]