mitmproxyで自動的にweinreを読み込ませるスクリプト書いたのでモバイルのデバッグが捗る

今さらなネタばかりですいません。

背景

2017年4月現在では Safari, Chrome に remote debug の機能が入っているので、対応している環境ではこれを使うことでスマホのブラウザの挙動に対しても効率的にデバッグできるようになってきている1。

が、なんかどうも安定しないし、例えば Windows からは Safari のリモートデバッグ使えるのかなぁ？

ということで環境を選びにくい古の weinre なわけだけど、これの何が問題って

  1. weinre の script を serve しなければいけない
  2. デバッグしたい HTML に <script> を書いて weinre のコードを読み込ませる必要がある

ところ。

対策

実はもう何年も前に思いついてはいたんだけど、誰か作ってるでしょと思ったら見つけることができず、どうでもよくなって放置していたんだけど、上の問題は

  • weinre を serve するサーバパッケージを用意する
  • local proxy サーバで HTML を書き換えてあらゆる HTML で自動的に weinre を読み込む <script> を入れる

ことで解決する。

準備

ということで作った。

まずは以下の道具を用意。

weinre はいつの間にかそれ専用の weinre コマンドが npm 上にできてたので、

$ npm install weinre -g

mitmproxy は Python で書かれているので普段 Python を使っている人は pip でもいいし、使ってない人はバイナリパッケージがあるのでそれを使うといい。Homebrew 使ってる人は

$ brew install mitmproxy

がいちばん簡単。

スクリプト

使い方

1) weinre を localhost 以外の IP アドレスで起動する

localhost でしか listen しないと weinre を起動した PC からしか繋がらない。

$ weinre --boundHost 192.168.0.5 --httpPort 8282

みたいな感じ。

2) スクリプトを読み込みながら mitmproxy を起動

この時、1 で起動した weinre の情報を与えてやる。上の例で言うと

$ mitmproxy -s "weinre.py 192.168.0.5 8282"

になる。

weinre も mitmproxy もデフォルトでは 8080 で立ち上がろうとするので、どちらかには port を明示的に指定して譲らなければいけない。

※ mitmproxy は https も proxy できる。mitmproxy で証明書を発行して、クライアントとなる OS、ブラウザにこの証明書をインストールする。この手順は十分簡単なので、公式のドキュメントを参照のこと。

3) ブラウザの proxy 設定で mitmproxy を指定する

これは各ブラウザの設定方法を参照。

これであらゆるサイトについて weinre の機能でリモートデバッグできるようになった。便利。

weinre の使い方についてはバッサリ割愛。

  1. Android 4.4+ / iOS 6+ ↩

Kanazawa.rb meetup #8「なんでも質問してみよう」でした

久しぶりにいつもの Kanazawa.rb でした。そして圧倒的にいつも以上のいつもでした。

これぞmeetupの醍醐味

meetup #7 の懇親会で隣になった川口さんと「今回は最大規模ですねー」「気をつけないと、だいたい次回コケますよ」「そうなんすよねー、今からコケそうだけど、まぁいいんですよ」てなことを話していました。

セミナーを2回続けたあとの今回の meetup #8 は人数的には過去最低を更新し、恐らく参加していない人から見れば失敗だったように映るでしょう。

でも違います。meetup #8 は今までで最も昼間からお互いに話し、お互いに聞き、プロジェクタのコネクタを回し、ホワイトボードを使った

最もアクティブなmeetup

でした。

これは恐らく

  • 回数を重ねてもうみんな距離感や何を期待されているかが分かってきた
  • Agile x Kanazawa.rb を経験した
  • 参加者が少なかった
  • 今まででいちばん近くに座った

などによるものでしょう。特に後半は大事で、参加者が少ないということは

「15分で収まる朝礼」

にぴったり合致するのです。一目で全員が全員を分かります。初めての座り方、初めての「質問」を柱にしたタイムテーブル、そのすべてが

「あぁこれでいいんじゃないか」

と感じるものでした。もうあとは内容は書ききれるわけがありません(笑

Kanazawa.rbの作り方 - 補足 -

今回は

「なんでも質問してみよう」

をテーマにしましたが、これは要するに

  1. 会話するという意味
  2. 質問を持ってきてちょうだい

の二つの意味になります。

Kanazawa.rb を立ち上げる際に最初に合意したことの一つは「セミナーイベントにはしたくない」ということでした。これはセミナーイベントが良くないという意味ではありません。セミナーイベントは他にもあります。Kanazawa.rb はセミナーではなく meetup です。そしてセミナーを毎月続けるのはしんどすぎるという意味でもあります。例えば「Agile x Kanazawa.rb」を毎月やったら我々は仕事できません(笑

だから meetup #6 も meetup #7 もセミナーだけで終わる形にはしていないのです。フリータイムを確保して質問したり雑談したり実験したりする、LTタイムを用意して参加を促す。これは明確に最初から意図したものです。たまたまではありません。

meetup #8 ではこの仕込みを「会話」としました。そのための「質問」でした。

もう一つ、2) の「持ってくる」は事前の準備を意味します。この準備は一言で言うと 「meetupの時間を最大限活かすための準備をしてきてほしい」という意味です。

Kanazawa.rb の meetup は 13:00 〜 17:00 なので 4時間です。部屋の準備と撤収の時間と休憩を抜いたら正味3時間程度でしょう。3時間でできることは限られます。だからしっかり準備してこよう、というメッセージでした。

そして今回は「Kanazawa.rbの作り方」という発表でこうした意図と、その裏で何を考えていたかを事前に整理できた範囲で説明しました。まぁ、これができたのは今回の参加者が前回に比べて極端に少なく、半分以上は organizer だったからというのも大きいです。たぶん参加者が倍いたらしなかったでしょう。

Kanazawa.rb は毎月やってますが、organizer 同士がそれ以外のタイミングで meet する機会はほぼありません。これは「イベント」を開催するにはかなりの弱点です。本来はもっと頻繁に会ってシミュレーションを重ね、議論を重ね、周到に準備すべきです。そしてイベントのスタイルを練って、やるたびに洗練されるようにスジを通すべきです。しかしあえて今まではやっていませんでした。これは Kanazawa.rb のリズムを大事にしたかったからです。また毎回テーマもやり方も変えていたので、今まではくり返すことによって洗練させることもできませんでした。

しかし分かっていたことではありますが、このやり方ではセミナーを連続してやるのは厳しすぎるねということを今回はみんなで確認できた、そんな感じがします。

もう一つは「これもアリ」「それもアリ」をみんなに知ってほしかったからです。準備の最中はものすごく不安になったことも多々ありますし、なったよーと今回は正直に吐露しましたが、Kanazawa.rb をいろんな形で開催してきたのは

今後の meetup の選択肢を広げるため

でもありました。そしてその選択肢はまだまだあるよ、と今回紹介しました。これを伝えることが今回の自分の最大のミッションでした。

今後またこの春のようにイベント的にやるのであれば、それは利用するツールを変える、もっと言うと運用の形を変える、スタッフを変えるなどの変化は必要じゃないかな、と考えています。

そして「とりあえずしばらくはあんま無理しなくていいんじゃないの」と合意しました。その理由はあえて書きませんが、meetup #8 に参加した個々人は今回「ぐっと強くなった」感じがします。これは決して内輪感が強まったという意味ではありません。何をどう考えてどう準備してどう臨むか、これを考えて参加できるようになったという意味です。

気になった人は来てみてください :-)

まだまだ面白いよ

くり返しますが、meetup #8 はたぶん最高の meetup でした。

Kanazawa.rb に興味あると思っている人は油断しちゃダメよ。興味じゃ足りない。

いつだって成果は行動の後についてくるのだ。

次回は 5/25(土) Meetup #9 - Kanazawarb だ！

最小限rspec-capybara-mechanizeの準備

※ capybara は 2.0 で request spec ではなく feature spec で動くようにするなど API 変更が入っています。下のエントリは capybara 1.x 時代のものなので、gem のバージョンも 1.x になるように制限してあります。

PHP も end-to-end は RSpec で書こうと思っているという話は先日書きましたが、以前は capybara-mechanize を単独で動かしただけで rake で回せる環境になってなかったので、それを最小限の構成で準備してみました。

minimal rspec-capybara-mechanize env — Gist

を clone して bundle install すればだいたいすぐ使えます。中身はこんな感じ。短い。ステキ。

include Capybara

は Capybara のドキュメント見ると Capybara::DSL になってるんですけど、何も考えずに bundle install した capybara ( version 0.4.1.2 ) では Capybara::DSL なんてねーよ！と怒られてしまいました。どうなってんだ。

[追記] どうもたまたま自分の入れた環境は依存性の関係で 0.4 になってしまい、include Capybara::DSL は怒られてしまうという状況のようです。gist を update して 1.0 以上でも 0.4 でもどっちでも動くようにしておきました。

構成としては

Gemfile
Rakefile
app/
spec/requests/spec_helper.rb
spec/requests/**/*_spec.rb

みたいな感じを考えてます。これで

require File.dirname(__FILE__) + "/../spec_helper"

describe 'Index' do
  before {
    visit '/'
  }
  it {
    body.should include('Copyright')
  }
end

みたいなテストが書けます。ひゃっほう。

使い方はいつものように

bundle exec rake spec:requests

です。

気をつけなきゃいけないのは、Capybara は RackTest じゃないと response とかメタデータが取れないっぽいところ。はっきりそう書かれているのを読んだわけじゃないんですが、

Capybara の README 意訳 - おもしろWEBサービス開発日記

を読むと Selenium では session や request にアクセスできないと書かれています。Mechanize だと取得できるようです。

refresh の意味を再認識

Web サーバを自分でいじれるようになって以来、html の meta で refresh させる方法は極力取らないように習慣づいてたんだけど、あえて refresh にする方が移転の事実が伝わってよかったのね。こんな簡単なことにようやく気づきましたorz

mod_rewrite とか Redirect でストレスなく新しい URL に誘導されちゃうと人間の意識に残らないので、いつまで経っても古い URL にアクセスしてくる。そこで、mod_rewrite で refresh 用の HTML に誘導して、移転のメッセージを出し、そこから refresh で遷移する。あるいは手でリンクを辿らせる。あるいはリンクすら張らずに URL だけ提示する。こうするとかっこはよくないけど、ユーザーの意識に残る。これ大事。

mod_rewrite が裏で頑張りまくってるってのは公開サイトでは当たり前かもしれないけど、内部向けならそんなにユーザーに優しくある必要もないし、設定が少ない方が管理は楽、という話でした。

え、クッキーってスパイウェアなの？

スパイウェア——パソコン1台に平均27.8件も潜入 (HotWired Japan)

クッキー入れたら平均30件程度じゃ済まないような気がするけど、自分の知らないところでクッキーがなんか高度なことしてて、そういう高度なクッキーだけをカウントしてるんやろか。クッキーってただのデータやんね？ オレなんか勘違いしてる？

これはオレも感じていた

十代にオザキを聴かせる

ちょうどうちらの世代辺りに「マジなのはかっこ悪い」という感じがあった。個人的には渋谷系にはまったく興味ないが、なんだろう、トピックを無理矢理置き換えて話を進めると、ちょうど校内暴力がいじめになっちゃったそんな感じだ。つまり、ムキにならずにストレスを発散する方法を見つけちゃったってところか。

ところが最近の世代は意外と骨太なところがあると感じる。

世代的な共通項というべき存在がいないという印象を受けた

という言葉はまさに自分の感じていたところにドンピシャだ。

話はそれるけど、この共通項なき世代への過渡期に当たる世代が変な優しさを身にまとい、やたらと友達であることを確認し合うとか、そういう脆そうなコミュニケーションスキルを磨いていたのではないか。つまり、不安の現われの世代だったのかなぁと。コギャルとかパラパラとか、なんかそういう感じなんだよな。無機質で統率が取れているところが実に気持ち悪い。ジュリアナの人たちは自分の楽しさが前面に出ていたが、パラパラって「人」が見えないのよね。

で、今はそういう変な不安のない、すっきりと共通項のない世代ができあがってきているのではないかと。でも逆に面白いだろうなぁ、そういう世代。自分が今その年代でもそう思えたかどうかは疑問だけど、やはりギャップがあるから面白いのだし、いいからこれを聴け！というなんかバトルロイヤル的な状況って楽しそうじゃないか。

/* まぁ、シャベリ場とか見てるといつの時代も子どもは子どもなんだなと思うので、実際に「世代」がどれほど影響があるのかってのもちと微妙だけど。 */

で、オザキ好きですよ、私は。熱い歌と泣ける歌が好きです。

チョー久しぶりの CD

ここんところ金がないのと場所がないのとで何年も CD なんか買ってなかったんだけど、尾崎トリビュートと Mr. Children を買ってみた。曲の感想はとりあえず置いておくとして(こら)、mp3 にしてみた感想は「なんだ、欲張ったエンコードすりゃ十分な音出るじゃん」ということだった。時間掛けて（2パスで） rip して 、最低 128kbps の VBR でローパスフィルタ掛けずにエンコードすると十分な音になる。（VBR の下限はまだ下げられるけど。）

これは cd2wav32 + gogo.dll の話だけど、iTunes でもカスタムで悪くない音になる。デフォルトは AAC だけど、使い回しを考えて VBR の mp3 に。やぁ確かにこの CDDB は優秀だ。ID3 タグを v1 形式に変換して取り出せば Winamp で楽々再生。CCCD じゃなきゃこれで十分な感じだ。

rsync の -C オプションと .cvsignore

最近 -C オプションつきで rsync することが何度かあったのだが、そのとき気づいたことがある。今までは file list に含まれていたはずの *~ ファイルがまったくリストアップされなくなっているのだ。

なんだろうと思ったらこれが -C オプションの効果で、これは CVS ディレクトリを無視するものではなく、CVS を操作するときに邪魔になる *~ やらコンパイル済みオブジェクトやら諸々のファイルを無視してくれるらしい。しかも .cvsignore も読み取ってくれると。

こりゃー便利だ。早速 eclipse の作るファイルとか .cvsignore に登録。

広告免除申請完了

  1. 決済サイトでお買い上げ
  2. お買い上げ金額を Value-Domain の方で実際の操作に割り当て → 反映

という流れ。

というわけで 2, 3時間後には反映されているらしい。PukiWiki の skin から広告の分外さないと。

10時くらいに寝て4時過ぎに目が覚めた

どうも体調が優れない。寝るときにこそ鼻炎の薬飲んだらよかったんかいなぁ。疲れているのにうまいこと休めない感じ。季節の変化に身体がついてきてないんかな。

というわけで PHP で中身をこちょこちょいじっている説教講座を wget で取り出す shell script を書く。これで Pure HTML になるので、本番環境に上げられるようになる。（いや、xrea でも PHP 版をそのまま使えるんだけどね。）このノウハウは説教講座に限らず、どこでも通用するので大事にしておきたい。

About

例によって個人のなんちゃらです