Macでdnsmasqを使ってお手軽名前解決

最近興味があってBoxenを調べています。BoxenはMacで開発するための
環境をよしなに整えてくれるツールなんですが、その中で気になったのが下記のヤツ

dnsmasq w/ .dev resolver for localhost

via https://github.com/boxen/our-boxen

はて?dnsmasqで.dev resolver for localhostてどんな事してくれるんじゃろかい?

何してくれんの?

端的に言うと

  • dnsmasqでローカル向けにDNSサーバを立てる
  • .dev のドメインはローカル(127.0.0.1)で名前解決できるようにする

あぁ上に書いてある説明どおりですね。ていう事をやってくれます。

もう少し噛み砕くと、ローカルでの開発用に hoge.dev, fuga.devみたいなドメインが欲しくなった時って、/etc/hostsに一個一個定義してたりしましたが、もうこんな事しなくてもいいんですぜ旦那。「*.dev」のドメインであれば、勝手に127.0.0.1に向く用にできまっせ。という話

# /etc/hosts

127.0.0.1   hoge.dev
127.0.0.1   fuga.dev

ではboxenが自動でやってくれるような事をわざわざ手動でやってみます。アナログ最高。ヒャッハー!!!!

ちなみにboxenのpuppetのヤツはここです。

dnsmasq のインスコ

$ brew install dnsmasq

設定ファイルの用意

# 設定ファイルのコピペ
$ cp $(brew list dnsmasq | grep /dnsmasq.conf.example$) /usr/local/etc/dnsmasq.conf

# 自動起動の設定ファイルコピペ
$ sudo cp $(brew list dnsmasq | grep /homebrew.mxcl.dnsmasq.plist$) /Library/LaunchDaemons/
$ sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

dnsmasq.confの設定変更

# /usr/local/etc/dnsmasq.conf

# wildcardでの名前解決を許す?
bind-interfaces 
# launch deamonで動かすために常にforgroundで起動
keep-in-foreground  
#  /etc/resolve.confを見ない
no-resolv 

#  *.dev ドメインへのアクセスは全てlocalに。
address=/dev/127.0.0.1 
#  名前解決する時にローカルを見るためには自動的にloopbackしてくれんので、明示的に設定するとかなんとか?
listen-address=127.0.0.1 

/etc/resolver/devの設置

  • Macは特定のドメインDNSだけを切り替える事ができる
  • /etc/resolver配下にそのドメインと同じ名前でファイルを設置するればおk
  • 書式は /etc/resolve.confと一緒
# /et/resolver/devを作成
$ sudo mkdir -p /etc/resolver
$ sudo touch /etc/resolver/dev

# 中身はこの一行のみ
nameserver 127.0.0.1

DNSのキャッシュクリア

一応キャッシュのクリア

$ dscacheutil -flushcache

確認

ここまで作業は終わりあとは確認

# *.dev のドメインは全て127.0.0.1が返ってくればOK
$ ping -c 1 hoge.dev
$ ping -c 1 hoge.fuga.dev
$ ping -c 1 hoge.fuga.piyo.dev

# 他の名前解決に支障がないか一応確認
$ ping -c 1 www.google.com

余談

  • /etc/hostsを弄る必要が無くなったのは良い。
  • dev以外に対応するドメインを増やしたかったら? 例えば *.hogeみたいな。
    • /usr/loca/etc/dnsmasq.conf に "address=/hoge/127.0.0.1" の行を追加
    • /etc/resolver以下にhogeファイルを置けば良い。
  • もうちょっと修行しないとオジサンダメです。

Andorid標準ブラウザでiframeのスクロールがおかしくて久しぶりにキレちまった件

Androidのブラウザでiframe利用してコンテンツを表示した時に困った時の話。別にキレてないです。

前提

  • Android OSは 4.0.3
  • iframeで読み込むコンテンツはサブドメイン
  • iframeのコンテンツは親frameに収まらずにスクロールする。
  • iframeのコンテンツはフォーム的なもんが表示

現象

  • スマホ(Android 4.0.3)でiframeが存在するページを表示してフォームが表示されていた。
  • 画像の通り、radioボタンが並んだ縦長のフォームを表示している。


  • 初期表示では、radioボタンをポチポチチェックできる。


  • 送信ボタンを押そうと下に引っ張ると、iframeの中がスクロールする。


  • ここで問題が発生する。送信ボタンが押せないどころか、その状態でradioボタンを押すとチェックが入らない!!!

原因

  • 詳細な原因までは正直わからないが、要はこういう事らしい。

1. 初期表示の状態ではradioボタンを押せる
2. 一度スクロールすると、押せなくなる。

これは押せなくなってるんじゃなくて、初期表示の位置をタップしていると同義らしい。
実際に少しだけスクロールさせてradioボタンをクリックすると、上の方のradioボタンにチェックが入る。


対応

さてこれに対応するにはどうしたんもんかという話だが、要は「スクロールなんてしなくてもいいくらいにiframeの高さを調節すれば良い」という事だった。

その対応は、mixiさんが提示してるようにjsでiframe内の高さを取得して、iframeの高さを自動的に設定すれば良い。

ところがどっこいiframeはSameOriginPolicyによってサブドメインだろうが、port付きだろうが、httpsだろうが別ドメイン扱いなので、iframe内の情報を取得するのは無理ゲーだった。

はーマジなんなの?

f:id:tell-k:20140426132610p:plain

というわけで、単純にiframeのheight属性をスクロールが発生しないであろう高めに設定するだけにした。もうiframeなんてなかったんやと思いたくなる珠玉の一品。

余談

どういう了見でこんな事になってるかまでは、ソース的なものが見つからなかったので、もし知ってたら誰か教えてください。

他に方法を無いかなと探した結果、yet antother的にcross domainのiframeの情報を取得する方法があったけど、どれもBKな感じがいなめないので、まだ試していない。

ちなみに Androidの2.3.x系、Android4.2.x系では、この現象は発生しなかった。

ほんとにあったかもしれない怖いコード (呪いのビデオ風)

納涼!ほんとにあった怖いコード(by CodeIQ×はてな)

http://partner.hatena.ne.jp/codeiq_matsuri2013_2

まずはこちらの画像をご覧いただきたい。

f:id:tell-k:20130826184950p:plain

お分かりいただけだろうか?

f:id:tell-k:20130826185014p:plain:w700

これは、とあるプログラマが、深夜23時頃に、終電で帰るのを諦めて、とある既存ライブラリを徹夜で書き直しをすることを決意した時に見つけてしまったコードだ。

f:id:tell-k:20130826185042p:plain

彼はこのコードを見て以来、心身ともにおかしくなってしまった。一部では彼は呪われてしまったという噂もある。

f:id:tell-k:20130826185101p:plain

当時の彼を知る同僚は、その頃から彼の言動がおかしくなったと証言している。

「BoldがSetされてるはずなのにSetされてないどころかそのままreturnされてる、ていうかCamelなのかunderscoreなのかどっち?。。。何をいってるか分からねぇと思うが、俺も何をいってるかわからねぇry)」

「いやこいつを理解できない俺がおかしい!!きっとこれは名のあるファンタジスタが書いたファンタスティックコードなんだ!ははは。。ひひ。。」

彼はその日から、取り憑かれたように、社内のファンタスティックなコードを探しては社内掲示版にアップし続けていった。彼はもうこの時、目の焦点があってなかったと言う。

ほどなくして彼は「探さないでください」という置き手紙とともに行方が分からなくなった。彼は行方をくらます直前にこんな妄言を吐いていたそうだ。

「俺にはこの記事のファイル名は"いーしーきゃんびー"って読めないし、"いーきゃんびー"、
もしくは、"いーしーあんゔぃー"だろうが!俺じゃない!俺がわるいんじゃない!全てはあいつが悪いだ!みんな呪われろ!ノロワレロ!ノロ。。」

彼はいま現在も行方が分かっていない。

ご注意

  • この記事の大半はフィクションであり、登場人物、画像、リンク先には関しては一切関連がございません。予めご了承ください。
  • また掲載されているコードは本来のコードの一部分だけを、記憶を頼りに再現したものとなっております。そのため呪われたりしませんのでご安心ください。

なんだよこれ。。。

お口直しに僕のお気に入りの動画を貼付けておきますね (´・ω・`)


疾走 - YouTube

Marked で reST(reStructuredText) を リアルタイムプレビューする

reST書いてる時に、いい感じでプレビューしてくれるのないかな。って思って見つけたヤツをメモる

やってみたら割と便利だった。

rst2html.py のパスをMarkedのCustomProcessorに設定するだけでいいらしい。

f:id:tell-k:20130324185420p:plain

あと毎回Marked 起動するのめんどいので、こんな感じで、.bashrcにaliasとして設定しておいた。

alias rstpreview='open -a Marked'

これでいつでも好きなファイルをMarkedで開ける

$ rstpreview hoge.rst

Markedは保存した内容を即座にプレビュー画面に反映してくれるので嬉しい。あとは僕のreST書きたい欲を待つだけ。

FacebookのOAuthのアクセストークンについて

FacebookのOAuthのトークンについての覚え書き。

最近では、FacebookTwitter の OAuth認証を介して、ログイン機能を提供するWebサービスが大分増えてきましたよね。しかも、ID/PASSでのログインとは別に、おまけ程度にあるのではなく、Facebook or Twitter でしかログインできないなんてサービスもちらほらあります。

FacebookのOAuth認証を通して手に入るユーザーのアクセストークンは、ユーザーがパスワードを変更したタイミングとかで無効になるので、認証するたびに新しいトークンになってたら、差し替えておいた方が良いんじゃないかなという話を長ったらしくします。

Facebook のOAuth認証のフロー

割と適当に書いたシーケンス図(ぽい)もので確認しましょう。
アプリケーションの要件によって、異なると思いますが、Webアプリケーションだったら、大体こんなフローになると思います。

f:id:tell-k:20120125002219p:plain

これでユーザーはApplicationにログインできるようになります。2回目以降は、7のアクセストークンが戻ってきたタイミングで、DBに問い合わせを行い、アクセストークンが既に存在していれば、ログイン状態になるといった具合です。

アクセストークンの有効期限が切れる

  • Applicationが求めるスコープに「offline_access」を入れてあげないと、割と1時間位でアクセストークンが有効期限切れなる。
  • Applicationにログインしている状態で、有効期限切れが起きるとApplicationからFacebookのGraphAPIが利用できなくなります。ex) ウォールへの投稿ができない!!!

パスワード変更すると無効になる

  • パスワードを変更するとアクセストークンが無効になります。
  • つまりApplicationにログインしている状態で、別のブラウザでFacebook開いてパスワードを変更したら、ApplicationではGraphAPIを利用できなくて、アババババとなります。

どうするのが良いか

アクセストークンが切れたら、ユーザーに再認証してもらう意外に、正しいアクセストークンを手に入れる術はありません。なので再認証してもらうための案を考えてみましょう。

  • ログインの中に、アクセストークンの更新処理を組み込む
    • 毎回ログインする時はFacebook認証をするので、そのついでに、あたらしいアクセストークンに差し替えてしまう。
    • アクセストークンでDBを検索
    • なかったら8で取得するFacebookのプロフィールIDをキーにDB検索する
    • もしあればデータあれば、それは「1度ログインして、且つアクセストークンが変わった」データなので、ついでにアクセストークンも新しいものに変更してやる
    • まぁ普通に皆やってるんだろうけど、プロフィールIDとか付帯情報はとっておきましょうねという事。
  • Facebookの接続解除、再接続機能を実装する。
    • 単純にDB上のデータを削除して、再度いちから認証にしてもらう。

なんか、うまくまとめられないので今日はここまで

hb qp bp study 新年LT&ビアバッシュ2012 にいってきた。

今日はビアバッシュにいってきました。

hb qp bp study 新年LT&ビアバッシュ2012

普段の勉強会テイストよりも、終止新年会ムードで面白かったですねw
個人的には @inoshiro さんの顔を認識できたのと、@richardx64 さんが覚えててくれたのが嬉しかったですw

とりあえずハッシュタグ #bphbqpstudy2012 からさらった資料をまとめておきます。
漏れてたら教えて下しあ。発表はもっとあったので全然少ないはず。

普通に為になるのから、黒い感じのや、熱い思いのこもったLTまで色々堪能させていただきました。
スタッフの皆さん、発表者の皆さん ありがとうございました。そしてお疲れさまでした。m(_ _)m

@hebikuzure さん

@urasoko さん

@rywo さん

余談

そういえば妙に採用募集ネタが多かったですね。奇遇にも下記の会社でも、主にデザイナーさんを募集中らしいので、応募してみたい人は

「採用に応募したいです! @tell_k からの紹介です! http://jobs.beproud.jp #しみずかわ」

と気軽に呟くといいらしいですよ!!!!

なんか今ちゃんと見たらエンジニアの採用は募集してなかった。。。けどけど腕に覚えのある「Webデザイナー」さんは絶賛募集中です!! てへぺろ(・ω<)

JOBS | Beproud.inc