※問題があったのでいったん落としました。
※ログインができない問題を対処しました。
Node.jsとOAuthの勉強ということで、とにかくつぶやくだけのTwitterクライアント「速ツイ [ http://sokutwi.edo-m18.me/ ]」を作ってみました。
Twitterにつぶやきたいときとタイムラインを見たい時はタイミングが違うなーと思ったのがきっかけで作ったものです。
とにかくすぐにつぶやきたい！ というときに使えるクライアントです。
なので、タイムラインの閲覧やReply、DirectMessageなどの普通はある機能は一切ありません。なのでページを開くだけなので非常に高速。
またiPhoneの場合は「ホーム画面に追加」で追加するとWebアプリとして機能するように作ってあります。
作った感想や使ったモジュールなどは別ブログでNode.js関係の話を書いているので、そちらで書こうと思ってます。（時間があれば・・・）
ただ、本当に勉強のために作ったのと、もともと自分で使う想定で作ったので、使う場合は自己責任でお願いします・・。
前回の「スマホの開発が超絶楽に！ weinreでスマートフォンをPCでリモートデバッグ！」は大変好評なようでうれしい限りです。自分もこれを知ったときはかなり興奮したのを覚えているので、同じ気持になってもらえたら幸いです。
さて、今回はデバッグツール的なつながりでCharlesというプロキシツールの話をしたいと思います。
プロキシサーバーとは、e-Wordsでは「単にプロキシと言う場合は、WWW閲覧のためにHTTPによる接続を中継するHTTPプロキシを指す場合が多い。
」という説明がされています。
つまりどういうことかと言うと、外部と通信する際に、通信そのものを代理でやり取りしてくれるソフトウェア（サーバ）ということができると思います。
今回もまた、文章では伝わりづらいので実際にその作業をしているデモ動画を作成しました。
※注意：デモでは本来なら手を入れることができないサイトに対しても使える＝本番環境でも問題ない、ということを説明するためにYahoo! Japanのサイトでテストしています。なので、実際には修正を行おうとしているサイトと、修正すべきファイルは手元にあるはずなので適宜それらと置き換えて読み進めてください。
いかがでしたでしょうか。Charlesを使うことで非常に手軽に本番環境でのテストが行えることが分かってもらえたのではないでしょうか。
ただ注意としては、（当然ですが）実際に本番環境をいじっているわけではないのでCharlesを落としてしまえば本当の本番環境に戻ります。なので、最終的にはこうして修正・チェックしたファイルを本番へ上げる必要があります。
ただCharlesを使うことによって、「テストで大丈夫だったものを本番に上げたらおかしくなった」ということを極力減らすことができる、ということです。（なんせ、本番環境でうまく行っていたのだから、それをアップしたら当然テストしたものと同じ結果になる、という理屈）
では、動画でやっていたことをピックアップしながらなにをしていたのかの詳細をしていきたいと思います。
まず、Charlesのサイトからアプリをダウンロードします。（Windows版、Mac版ともにあります）
サイトトップ右側にある「Download a free trial Version **」からダウンロードページへ進みます。
するとページ中程にWindows 32bit版、64bit版、Mac OS X版、Linux / UNIX版のリンクがあるので、そこから該当のファイルをダウンロードし、インストールします。
インストール後、起動したらメニューバーから「Proxy > Mac OS X Proxy(とMozilla Firefox Proxy)」のチェックを入れます。（Macの場合）
Firefoxに限っては、専用のCharlesアドオンをインストールしないとダメなようです。ただ、インストールは簡単で、「Mozilla Firefox Proxy」のチェックを入れるとインストールするかどうかを聞かれるので、そのまま「はい」を選択してインストールすればOKです。
続いて、メニューバーの「Tools > Map Local」を選び、マッピングの設定を行います。
マッピングについては、まずリダイレクトしたいURLを指定し、そのURLへアクセスした場合にどのファイルを参照させるかを指定します。（つまり、参照先のURLを無理やりローカル（手元）にあるファイルにリダイレクトする＝Map Local）
ここまで設定したところで、設定したサイトを見てみると、上で設定したファイルの変更がそのまま反映することが確認できると思います。
いかがでしょうか。それほど導入がむずかしくないことが分かるかと思います。
一点注意としては、Trial版は30分経つとCharlesが自動で終了する、という点です。（ただ、もう一度普通に起動し直せば、設定した内容は保存されているので使い続けることはできます）
今回のケースはHTMLでデモをしましたが、もちろんCSSやJSを同じようにローカルファイルを参照させることもできます。（逆に、ある程度の規模の案件だとHTMLはPHPなりのプログラムで書き出している、ということも少なくないと思います。その場合は今回の手法では修正がむずかしいかもしれません）
ちなみに、画像ファイルの場合はとあるディレクトリ以下をすべてローカルのファイルを参照するようにしたい、なんていう要望があるかもしれません。その場合は、URLの指定の箇所で「http://hoge.com/img/*」のようにアスタリスクを入れることで、その下のディレクトリにアクセスがあった場合は、ローカルの指定したディレクトリにリダイレクト、という設定もできるようになっています。
このCharels、知ったときはかなり感動しました。たとえば、アカウントがなくて本番にアクセスできない環境（ファイルを納品だけしている場合など）のときに、でもなんとか原因を調べてくれ、なんていう要望をもらったときでもなんとかできてしまったりします。
もちろん通常の開発時でもとても役に立つので、一度試してみてはいかがでしょうか。
weinreとは、サイトでは次のように書かれています。weinre is Web Inspector Remote.
。
この単語の頭2文字ずつをつなげて「we in re」ということのようです。読みは「ワイナリー」とか「ワイナー」みたいな。
つまり、リモートでデバッグができる、ということです。百聞は一見にしかず、ということで、実際に使ってみたものの動画キャプチャをアップしているので、下の動画を見てみてください。きっとその機能に驚くはずです。(ちょっと画面が小さいので、720pにしてフルスクリーンで見るといいかも）
Githubで公開されているphonegap / weinre - Githubからダウンロードできます。
zipで公開されている2ファイルのうち、今回は「weinre-jar-1.5.0.zip」を使いました。Mac版はアプリになっていて使いやすいのですが、ただ設定をいじるのが大変だったので、jarファイルを直接実行するのがいいでしょう。デモもそれを想定してターミナルから実行しています。
さて、今回のデモでやっているように、weinreをターミナルから実行してみます。（社内のサーバに設置しておくときにもやりやすいかと思います）
まず、Githubから落としてきたファイルを解凍します。生成されるファイルは2つで、使う方はweinre.jarのほうです。場所はどこでもいいので、あとあと使いやすい場所に保存しておくといいでしょう。
次に、ターミナルを起動します。通常は、アプリケーション > ユーティリティのフォルダの中にアプリケーションがあります。
起動したら、上記で保存したファイルの場所まで移動してください。（操作がよくわからない人は、cd (cdの後ろに半角スペース）と入力後、保存したフォルダをFinderで表示し、そのフォルダをターミナル上にドラッグ&ドロップし、Enterキーを押すと移動できます）
続いて、java -jar weinre.jar --httpPort 8080と入力し、Enterキーを押します。エラーが特になければ、実行成功です。
起動が無事完了したら、あとはブラウザで実行すればOKです。Google Chromeを立ち上げ、http://localhost:8080/にアクセスしてください。
デモで見た画面が表示されればOKです。ページが表示されたら、ページ中程にあるbookmarklet url in a preと書かれた箇所にあるJavaScriptのソースをコピー*1します。
コピーしたら、一番上にあるリンク http://localhost:8080/client/#anonymous をクリックしてデバッグページを表示させます。
続いて、iPhoneエミュレータか、別のGoogle Chromeのウィンドウでリモートデバッグしたいページを開き、*1でコピーしたJavaScriptをロケーションバーに貼りつけて実行*2してください。
デバッグページの画面にデバッグしたいページのURLが表示されれば接続完了です。あとは、Google Chromeで普段行なっているのと同じようにデバッグすることができます。
実はファイルを落としてきてやる方法以外に、weinreのAPIがすでに用意されていて、そちらを使うことで手前で準備しなくてもリモートデバッグを体験することができます。
http://debug.phonegap.com/client/#hogeにアクセスし、*2で実行したJavaScriptの、読み込むJS部分をhttp://debug.phonegap.com/target/target-script-min.js#hogeに変更すればOK。
ちなみに、#hogeとなっている箇所（ローカルで実行しているもの、APIどちらも）はIDになっていて、それを任意の文字列に変更し、JSを読み込ませるブックマークレットの部分のIDも同じものにすることで、ひとつのサーバで複数のページのデバッグができるようになります。(※http://localhost:8080/client/#debugtest のように)
APIを利用する場合は、実機でも確認することができるのでさらにそのすごさを実感することができると思います。（ネットワークの設定などをいじれば、同じネットワーク内のものであればローカルで準備したものでも実機での検証ができますが、ちょっと話がそれるので割愛）
今回の記事を書くにあたって、「スマートフォンブラウザのWebInspectorをリモートで実現するweinreが凄い」の記事を参考にさせてもらいました。
ちょっと仕事でChromeアプリについて調べる必要があったので調べていたら、かなり簡単に作れそうだったので試しに作ってみた。
いつも、ちょっとした画像をDataURIに変換するためにブックマークからサイトを開いたり、ということをしていたのだけど、それが以外にめんどくさかったので、Chromeのホームから直に開けるのはいいなぁ、ということで作ってみたアプリ。その名も「Convert to DataURI」。
気づけば3ヶ月も更新していなかったことに気づきました。まぁ、3倍と3ヶ月で3つながり、ということで(謎
さて、そんな訳で先日開催された CSS Nite Ginza Vol.56 で、Vim についての話で登壇してきました。見出しの通り、3倍(以上)速くなることまちがいなしのエディタ「Vim」。その速さを知ってもらうために行ったライブコーディングの様子もあるのでぜひ見てみてください！
Vimとは、ざっくりと説明するとCUI時代のエディタ「vi」の機能拡張版。CUIとは、キーボードで操作することを基本としたUIのことです。マウスで操作するのはGUI。なので、コーディングなど、キーボードで作業することがメインの職種（MEやプログラマなど）にはとても親和性の高いエディタとなっています。
タグの中のテキストをさっとコピーしたい！ とか、ダブルクォーテーションの中の文字をざっと削除したい！ なんていう「思ったこと」をそのまま実行してくれるのがVimのいいところ。
と、文字でいくら力説してもなかなか伝わらないので、実際に登壇時に行ったライブコーディングの様子がムービーでアップされているので、ぜひそちらを見てみてください。そして興味を持った方はぜひ、一度Vimに手を出してみてください。多分、一度は挫折しますｗ（かくいう自分も一度挫折した口ですｗ）
ですが、それを乗り越えた先には信じられないくらいコーディングがスピードアップした自分がいることでしょう。そう、まるで宇宙船で100倍の重力に耐えた悟空のように。（ネタが古い）
今まで、CSS3 のグラデーションを利用したサンプルの作成を作成するとき、Photoshop っぽい感じでグラデーションが作れたらなーと前から思っていたので、最近 JavaScript から遠ざかっていたのもあって思い切って自分で作ってみました。
メインはグラデーションの作成ですが、Photoshop ライクなものを目指したので、Photoshop では当たり前のように出来るドロップシャドウなんかも設定できたら便利かな、と思って付け加えてあります。
ちなみに、CSS3 のグラデーションがメインなので、"CSS3 のグラデーションに対応している Firefox3.6以上か、WebKit 系のブラウザでしか動作しません"。
色々チェックはしていますが、もし不具合なんかあったら連絡もらえるとうれしいです。
連絡いただける際は、この記事へのコメントか、問い合わせからお願いします。
今回は、CSS3 のプロパティを出力するのが目的だったので、そもそも CSS3 に対応していないブラウザはすっぱり切り捨てましたｗ なので、全体的に CSS3 をめっさ使ってます。
加えて、IE6 などのブラウザを切り捨てたので、気兼ねなく色々なセレクタを使ったりしてとてもコーディングが楽でした。
CSS3 が当たり前になったらこんなに楽になるんだなー・・としみじみ思いました。早く、CSS3 をメインで使ってコーディングがしたい・・・。
CSSのボックスレイアウトって色々複雑だよなぁと思っていて、もし自分がそれを、まだ理解してない人に教えるならなんて教えるかな？ とか考えてるときがありました。
元々、なにかに例えて説明するのが好きなので、身近なものでなにか説明できないかと考えたわけです。
出した答えがこれでした↓
すべてを家に例えるわけです。
まず、widthは "家の幅"、paddingは "庭の範囲"、borderは "家の壁の厚さ"、marginは "隣の家との距離" と。
そう説明した上で、"庭の範囲"（つまりはpadding）は自分の好みが反映される（つまり背景）。そして自分の敷地は壁までの範囲（つまりwidth＋padding＋border）。そして隣の家との距離はmargin。
こう例えると、なんとなくpaddingとmarginの違いがわかりやすいのかなぁと思ったわけです。
さらに、実際のボックスの幅がwidth＋padding＋borderとなる理由も、上記の説明でなんとなくイメージできるかなと。
そんなこんなを考えていて、ついに人にそれらを教える機会があり、参考資料として上の図と、下のツールを作るに至りました。
分かる方から見ても、この説明が分かりやすいか、分かりづらいか、そういった意見を頂きたいなぁと今回の記事を書いてみました。
もっといい説明があるよ！とか、なんでもいいのでコメントもらえたら幸いです。
ちなみにツールのコンセプトは「よくボックスレイアウトについて分かっていない人でも、動的に見ることでなんとなくでも概要をつかんでくれるかなー」と。
おかしい部分なんかありましたらコメントでももらえるとうれしいです(;´д｀)
カテゴリー
最近のエントリー
©2009-2011 CSS-EBLOG All Rights Reserved
