にょきにょきのお勉強

ブログ画像一覧を見る

このブログをフォローする

1 | 2 | 3 | 4 | 5 | 最初次のページへ >>

大量のリダイレクト設定の確認をする

mod_rewrite でたくさんの旧URLから新URLへのリダイレクト設定をしたときに、検証した方法をメモ。

もっと自動化したほうが目視確認が軽減されていいのだろうけど、そこまで手をつけなかったので結構人力部分が残っているのが難ですが。

まず、ブラウザのアドオンなどで UserAgent を変更することができたりしますが、チェックするべき URL が多すぎてブラウザにURLを500回くらい入れるのはつらいのでコマンド&スクリプトでチェックしたいです。

というわけで、まずはコマンドでリダイレクトの状況を把握する方法。

$ HEAD -S -H 'User-Agent: Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_0 like Mac OS X; ja-jp) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8A293 Safari/6531.22.7' http://the.url.you.want.to.check/

たとえばこれは UserAgent　を iPhone4 のものに偽装してテストする場合。

HEAD コマンドはPerl の LWP モジュールに付属のコマンドだと思うのですが、HTTP リクエストした結果のヘッダ情報だけを取得することができて便利です。

-S をつけてレスポンスステータスを全部表示するようにし、-H でリクエストする時のヘッダ情報を上書きします。

次にテストしたいURLとりダイレクト後のURLの一覧対応表を作り、それを読み込んで上のコマンドを順次たたくようにして、それらの結果を整形しつつ出力するようにします。

たとえばこんな感じに。

********* uri should will be http://URI.which.should.become.so/
HEAD http://URI.which.redirect.src/ --> 302 Found
HEAD http://URI.which.should.become.so/ --> 200 OK
Connection: close
....

期待するリダイレクト先、アクセスしたURL、リダイレクト後のURLをそれぞれ目視で確認。

スクリプト実行時に UserAgent は引数指定できるようにしておいて、出力結果を > などでファイルへ保存したりして、想定どおりかどうかをチェックする、という感じでやりました。

ブラウザに毎回 URL を入力するよりは断然、労力軽減できますが量が増えると目視確認がやはりつらい。。

さらにがんばるなら出力結果もプログラム的にチェックしたいところ。

novstripe ってなに？

jQuery のプラグインで flexigrid というのがありまして。

テーブルデータの表示に使わしていただこうとしてるのだが。

オプションの novstripe ってなんだろうか？と思ったら　no vertical stripe の略だった。。。

用途は、カラム間の境界線をレンダリングしないかどうか。

true/false 指定の場合、false って指定すると表示されないような印象を受けるけど、表示する場合は false、表示したくないときは true だった。

英語のマニュアルでいまいち理解できない愚痴

Perl な ORマッパで一番シェアのあるのが DBIx::Class だという記述をたくさん見かける割に、DBIx::Class::Schema::Loader の使い方的な記述が少ないのはなぜだ。

DBIx::Class::Schema ベースでだとモジュール作るの面倒になるから自動で作る DBIx::Class::Schema::Loader を使うよねー、とか。

そんな記述があるのに、使い方がみんな一旦モジュールファイルを作る方法になっているのはなんでなんだろう。ダイナミックに作れるのがミソだと理解してるのは何か勘違いしてる？

ダイナミックにというか、手動と自動のハイブリット型ができるような雰囲気なのだが、わかりたいところがわからない。

うーんまだまだ調べ方が甘いのかも。

謝れないひと

人から図星さされたり、

労力や時間を費やしたものだったり、
いろいろ検討した結果だったり、

目下と思っている相手からだったり。

そんなシチュエーションで注意されたり指摘されたりしたら

そらー謝りづらい、非を認められない、、という気持にもなろうけど、

すこしでも自分の失敗に気が付いているなら、それは反応しないと。

注意した人に対してが嫌だったらそれはいいから、

せめて迷惑かけた人に向かっては何か言わないと。

なぜか注意した側の人が余計なことした、みたいな雰囲気はやだやだー。

Google 謹製ドキュメント

うーん、うーん、うーん。

どうして Google さまのドキュメントはわかりにくいのだろう。。

Youtube が Google とくっつく前にあった Youtube API のドキュメントにはそんな印象がないのだけど、ちょっと調べたいことがあって、今日 Youtube Data API のドキュメントを調べてみたら、、、わかりにくいというか、読みにくい。

クライアントIDの取得の仕方がわからない。

http://img.youtube.com/vi/xxxxxxx/x.jpg に直接アクセスしていいのかわからない。

後者のはたぶん API 叩いて得られる情報と同じものだと思われて、それなら使っていいのだろうとおもうのだけど、、、、、API 叩いて確認しようと思ってもクライアントIDの取得方法がわからないんだ。

デベロッパーkeyは書いてあるとおりで取得できるんだけどなぁ。。