O3noBLOG

這次 JSDC 2013 分享的投影片出來了，這次的主題是比較根基的東西，也算是我寫一陣子 JavaScript 後覺得可以整理出來的一個 Pattern，沒聽現場的，應該看投影片也可以知道我說的是什麼，本來題目是 Magic this，後來改成 this 了，不過已經生好的標題圖片不用太可惜，所以還是放上來了。

以前曾經介紹過 autojump 這個很好用的快速切換目錄的指令，後來 大貓 跟我說有個叫 z 的，一樣用途，原理也差不多，不過 z 的位置比較好按些，最近在看 Vim Scripts 時，意外發現到有個 fasd，也是一樣的原理，不過他的功能比較強大，配合一些 alias 就可以做到和 z 或是 v 一樣的功能，作者對相關的領域很熟悉，對於常用 shell 的整合很好，像是 zsh 和 bash 的 指令補完 就都有支援，目前正在改用他，Mac 安裝很方便：

brew install fasd

然後在.bashrc或是.zshrc加上

eval "$(fasd --init auto)"

就可以了，其他環境有包好的就比較少了，可以看看他的 Wiki: Installing via Package Managers，其他的環境我測試過 Ubuntu 編譯安裝都很順利，基本上只是拷拷檔案而已。

Google Chrome 開發工具的文件昨天有更新，不確定這整頁是新的還是改寫，不過總之是詳細很多的 Script Debugging 的使用說明，從詳細的介面介紹，到如何用這些功能都有說明，值得推薦一看。

另外還有一篇新的則是關於把開發工具導入開發流程內的文件，所以包括一些新功能像是 snippets 的介紹，也有 in place editing ，如何儲存修改過的檔案等。

前一篇：2013 日本賞櫻 京都 醍醐寺

第二天到京都，其實是到日本的第三天（不含入境那天），中間的第二天關東關西都在下雨，雖然當初這樣決定不是因為天氣因素，而是考慮到體力和休息時間的問題，不過運氣還算蠻不錯，因為這一天京都天氣沒很差，倒是東京聽說雨大到嚇人，其實本來天氣預報是說都會陰天，不過剛到京都沒想到還出現籃天，本來都計畫好要去喝咖啡了，馬上改目標跑去 Yuren 推薦的平野神社。

上一篇：2013 日本賞櫻 京都 第一天 ， 下一篇：2013 日本櫻花 京都 Day 2

其實昨天的京都第一天，我漏掉了另一個重要景點，就是醍醐寺，台灣的日本遊記 blog 常常會看到說，如果京都只有看一個地方的櫻花，就到醍醐寺，我必須說所言不假啊，所以乾脆獨立一篇來貼醍醐寺的照片好了。

前陣子 Bingo 告知才發現，jQuery Deferred 物件的 pipe 在 1.8 被標為 Deprecated 了，以後請改用 then，兩者其實不管回傳值的話，行為還蠻接近的，現在的 pipe 還沒移除掉，不過已經是新版的 then 的 alias 了。看文件的話如果不看下面的敘述，很可能不知道 1.8 前後的差異，雖然回傳的都是 Promise 物件，不過 1.8 之前回傳的是同一個 Promise 物件，1.8 之後回傳的則是新的，和原來 pipe 行為一樣，結果修改過的 Promise 物件。

前一篇：2013 日本賞櫻， 下一篇：2013 日本賞櫻 京都 醍醐寺

這次所謂的往西，其實就是到京都，如果搭新幹線的話，來回票價要兩萬四日幣左右，其他交通手段的時間損失太大了，其實根本沒考慮，還好瑞男有提醒我 JR Pass 這東西，全日本 Pass 只要兩萬八日幣，所以我只要去個兩天就賺回本了，而且東京的 JR 交通也都還可以用，最後規劃就是到日本後的第一和第三天去京都看櫻花，隔一天是因為睡眠時間，不乾脆住在那是因為都沒房間了，幸好我當初還不確定行程時先用交通方便來找住宿地點，挑了品川來住，新幹線有停，所以可以直接品川到京都，沒去大阪是因為還要再轉車，時間消耗和變數太多，因為我要趕早上第一班和晚上最後一班，而且還只能搭每站停的車次，比較麻煩的是晚上九點就發車了，不過回到東京其實已經十一點半了，要是錯過就會很慘，而且我還要看夜櫻，兩天晚上都覺得好可怕XD。

前幾天我的網域名稱 othree.net 突然無法從 Google 的 Public DNS 8.8.8.8 查到，經過一些交叉比對後，發現 Google Public DNS 和 Linode 內部用的 DNS 查不到，其他大部分的 DNS 都查的到，一時也不知道到底是什麼問題，就和 namecheap 聯絡，結果對方客服還蠻鬼打牆的，聯繫兩次都說設定沒問題，他們連的到，有問題也是 Google 的，還好 DK 有跟我說可能和 DNSSEC 有關係，讓我比較好找問題，其實我也有跟 namecheap 的人說到 DNSSEC，但是他們好像沒聽到一樣，讓我有些訝異的是， namecheap 的人對於 Google Public DNS 查不到他們客戶的 domain 覺得好像沒什麼，沒有很積極找問題。

還好 Google Public DNS 有 mailing-list，可以上去問這種問題，結果對方說我的 DNSSEC 驗證不過，附上 DNSViz 結果給我。

其實一開始光看這張圖還不知道問題在哪，接著又去看 DNSSEC 運作的原理才了解，DNSSEC 其中對於 domain name record 要不要信任基本上是靠 chain of trust，也就是一層一層確定沒問題才保證最後的目標沒問題，所以他會先驗證 net 的 resolve 結果是可信任的，然後才往下問 othree.net 的 DNSKEY，然後用 net 那邊的 DS record 來驗證目標的 DNSKEY，而我的狀況是，去問上層的 DNS 有沒有 othree.net 的 DS record ，結果是有的：

[/root] -root- >>> dig @192.55.83.30 othree.net. DS

; <<>> DiG 9.7.0-P1 <<>> @192.55.83.30 othree.net. DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14284
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 12
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;othree.net. IN DS

;; ANSWER SECTION:
othree.net. 86400 IN DS 1 1 1 1234567890123456789012345678901234657890

其實看到這邊有點傻眼，因為用來驗證我的 DNSKEY 的 hash 竟然是 '1234567890123456789012345678901234657890' ，怎麼想都是有人亂打的，不過我也不想追究了，總之上層有 DS record，但是去問下層 DNSKEY 時確沒有：

[/root] -root- >>> dig @208.64.122.242 +multiline othree.net. DNSKEY

; <<>> DiG 9.7.0-P1 <<>> @208.64.122.242 +multiline othree.net. DNSKEY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16844
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;othree.net. IN DNSKEY

這樣當然無法通過 DNSSEC validation，本來以為把這件事跟 namecheap 講他們就知道該怎麼處理了，結果還是不行，於是我又更直接的請他們跟上層說把那筆 DS record 刪掉，到今天早上終於正常了。

去年朋友就問我要不要去日本賞櫻，我想了一段時間後答應了，於是就開始規劃、買票等等，沒想到今年東京櫻花比去年早了兩週開，完全超出原來規劃的緩衝時間，本來買的機票時間是不管櫻花早一週或晚一週開都還可以的，沒想到今年遇到是有紀錄以來第三早的，不過機票住宿都好了，所以就只能往北走或往西走，東京的櫻花我們到時都已經稀疏不少，有的還長葉子了。

這篇主要記錄東京和北邊的部分~

後一篇：2013 日本賞櫻 京都 第一天

第一天就先跑去台場看鋼彈，天氣不好，早知道第一天不要過來台場，應該先去逛逛街的，因為最後一天晚上又和朋友來一次，而且那天的天氣好很多，拍的彩虹橋也漂亮多了。