MySQL 5.5 的 InnoDB Memcached Plugin

之前曾經提過 HandlerSocket – A NoSQL Plugin for MySQL，可以透過類似 NoSQL 的方式存取 InnoDB，效能會比普通 SQL 更好。後來 Oracle 在 MySQL 5.5 推出的時候，直接使用 Memcached Protocol，理論上應該是更方便（因為 Memcached Adapter 到處都有…）。

於是最近仔細的研究了一下，發現要使用 MySQL 5.5 的 InnoDB Memcached Plugin，要注意以下的地方：

  1. 如果要使用自行指定的 Table，需要參考 Internals of the InnoDB memcached Plugin，在 innodb_memcache.containers 設定 key 與 column 的對應表。
  2. 預設是使用 containers Table 裡面 name 為 default 的 Table。
  3. 如果要指定 Table，要在 GET 或 SET 指令前，下 GET @@name 或 SET @@name 將之後的 Request 都切換到 name 這個 Table。
  4. 如果需要 Replication，記得要設定 innodb_api_enable_binlog 這個值。

大概重點就這些了，如果還有玩到別的再來補充。

Firefox 27 將移除 Flash Plugin，改用 Javascript Flash VM “Shumway” 代替

從 Geek.com: Firefox 27 will kill the Flash plug-in on January 21 看到這個消息，就試著去裝了 Shumway 的 Extension 。

要跑起來花了一點功夫…

  • 要把 Flash Block 關掉
  • 要把 Flash Plugin 改為「啟用時詢問」
  • 在 about:config 內要把 shumway.ignoreCTP 設成 true。原本沒有這個設定，要自己加上。

跑起來結果如下：

會看到下方出現 Shumway 的字樣，表示這個 SWF 檔案是用 Shumway 解析的。

另外測試了幾個影音網站，全部都不能動。YouTube 是直接強制用 Flash Plugin:

Vimeo 是黑色畫面：

ニコニコ動画也不會動：

距離 1/21 剩下三個多月了耶，這樣真的不會大爆炸嗎 😮

美國印象：聖地牙哥 (1)

上一篇居然是兩個月前寫的…

這次去美國，主要去了兩個地方：聖地牙哥與拉斯維加斯。

聖地牙哥是加州的度假勝地，位於加州最南端，與墨西哥接壤，可以直接開車過邊境到墨西哥，不過我們這次沒有去。
氣候少雨，溫暖乾燥，平常要注意保溼。從洛杉磯開車約三小時左右即可抵達聖地牙哥。

我們第一站到 La Jolla（念成拉厚鴨），這裡的海灘上滿滿的都是海豹啊。

照片上看起來海豹好像不會動，其實他們只是在曬太陽而已。

當地政府規定不能餵食或者碰觸海豹，所以這些海豹根本就不怕旁邊的觀光客，非常悠閒的在沙灘上曬一整天的太陽。

美國人也很喜歡在海邊待上半天。

下一個景點是 Bolboa Park，裡面有非常多的博物館與展覽室，但是我們到的時候剛好是感恩節假期所以休館 Orz

聖地牙哥與橫濱市是姊妹市，所以可以看到不少日本人捐的東西。據說聖地牙哥最多的亞洲裔是日本人。

第二天我們到了聖地牙哥的海洋公園。海洋公園佔地非常大，認真玩的話可以玩兩天沒問題。我們只玩了一天，所以還有一些表演與設施沒玩到。
這裡觀光客可以跟他們互動的海洋動物，像是海豚！

海豚的表演區跟觀光客的距離超近。

不管大人或者小孩，聖地牙哥的海洋公園都能給出不同的樂趣。現在在寫這篇文章的時候，又想去海洋公園玩了…

尼莫～

北極熊

白鯨

本日最可愛

(To Be Continued…)

用 ETag 追蹤使用者

真可以說是道高一尺魔高一丈⋯⋯

警告：以下文長，如果只想知道 ETag 怎麼進行追蹤的，請直接從最後一段讀起。

為了瞭解使用者的行為，投放使用者喜歡的內容或是可能有興趣的廣告，網站會使用各式各樣的方法來紀錄使用者的瀏覽行為。例如 Amazon 會紀錄使用者看過哪些或購買了哪些商品，然後把使用者有可能有興趣的商品顯示出來，希望使用者能繼續在 Amazon 購買。對於廣告聯播網來說，如果能投放使用者喜歡的內容，進而提高點擊率，便能獲得更好的成效，增加收入。但是廣告聯播網並不像 Amazon 這類電子商務網站，強制使用者必須登入才能使用，而且廣告聯播網大多橫跨多個網站（例如很多站都會掛 AdSense），因此一般來說會採用 Third Party Cookies ((可參考 fcamel 的文章: Cookie 雜記)) 紀錄 User 的瀏覽紀錄。

這造成了一個問題：到底是誰可以擁有我們「看過的網站的列表」這個資料？相信沒有人願意讓大家知道自己在看某些害羞的網站吧。但如果這些網站有加入廣告聯播網，廣告聯播網便可以知道你瀏覽過這些網站，於是在其他一般的站台，便有可能出現令人害羞的廣告內容。這造成了隱私洩漏問題。

於是人們採用了各式各樣的反制方法：有的裝了 AdBlock 眼不見為淨，但免費的服務大多數依賴廣告為生，如果大家都排斥廣告，連 Google 都活不下去；有的人提出了一個 DNT (Do Not Track)的宣告，希望網站能夠遵守。不過這實在太理想化了，不知道要何年何月全世界的網站才會支援。

另外，瀏覽器廠商也推出了他們的解決方案，其中一個是「隱私模式」，也就是不紀錄任何的 Cookie，每次重開瀏覽器都需要重新登錄網站。但這對普羅大眾來說實在太麻煩了，因此又有另一個方案：禁止 Third Party Cookie。也就是說，只允許使用者主動連上的網站（例如使用者喜愛的社交網站，部落格，或是影音網站）設定 Cookie，而使用者沒有主動連過去的網站（例如廣告聯播網）則禁止設定 Cookie。這樣就避免廣告聯播網利用 Third Party Cookies 來紀錄使用者瀏覽紀錄了。iOS 上的 Safari 預設是禁止 Third Party Cookies 的 ((結果 Google 發現 Safari 有 Bug 可以繞開這個限制，也利用了這個 Bug，於是就被告了。)) ，而原本 Firefox 打算也改為預設禁止，不過現在延遲了這個計畫。

看起來，未來使用 Cookie 來追蹤的方法會越來越受到限制，於是有許多替代方案出現，像是利用 Flash，或是 HTML5 的 LocalStorage 等等，但都有一些缺點。今天看到有人提出用 ETag 來追蹤，想了一下發現沒什麼破綻，使用者更難防止追蹤了。

ETag 是用來避免使用者下載已經存在瀏覽器快取裡面的資料，進而加速使用者瀏覽網站速度的功能。大部分的網站並不會常常大改版，於是會有一些 CSS、Javascript、圖片是不常更動的，如果這些資料下載一次後就存在使用者電腦中，下次使用者拜訪網站時，就不需要重新向網站抓取，可以節省頻寬與時間。當瀏覽器第一次下載資料時，網站可以指定檔案的 ETag 值，瀏覽器會記住。下次訪問網站時，瀏覽器會先詢問網站同一個檔案的 ETag 值是否相同，如果一樣就不重新抓取。


ETag 示意圖，取自 http://lucb1e.com/rp/cookielesscookies/

因為瀏覽器會將記住的 ETag 值送回網站，因此網站只要在頁面中插入 1px * 1px 的 GIF，然後針對每個沒有傳 ETag 來的瀏覽器給定一個獨一無二的 ETag 值（並紀錄在資料庫中），下次使用者回訪時，便可以分辨出這個使用者曾經來過這個網站。對於廣告聯播網來說，只需要在每個站台加入這個機制，又可以爽爽紀錄使用者曾經瀏覽過的網站了⋯⋯

Reference: http://lucb1e.com/rp/cookielesscookies/

美國印象：洛杉磯

去年年底到美國玩了一趟。

雖然是第一次到美國，還好全程有同學 Kano 與她男朋友的幫忙，很順利地完成了這次的旅行，還第一次挑戰了在國外自己租車開車。
只是一下飛機時差還沒調過來就上駕駛座還挺恐怖的。

IMG_9594
（我們租的其中一輛車）

這次去美國，在洛杉磯只待了差不多兩天，最有印象的是高速公路的車陣。
雙向十線道，甚至12線道滿滿都是車。而且洛杉磯人開車也很猛，不比台灣人差。一不小心喇叭聲可是會從後面狠狠追上來的。

IMG_9506
（杜比戲院，原本叫做柯達戲院，就是奧斯卡獎頒獎的地方）

洛杉磯雖然是美國第二大城，但是跟台北不同，居民大多住在市郊的獨棟房屋，開車通勤上下班。另外洛杉磯附近的高速公路大部份都是免費的，使用的人非常多。這幾年因為財政困難，所以高速公路的維護品質不是很理想，開在上面會覺得台北的高速公路贏了。

IMG_9503
（好萊塢街頭）

到了美國，第一個印象是 Good Morning (Afternoon)。這句話的出現頻率大概跟在日本的「すみません」一樣高。美國人超愛這句話。
另外就是柯達戲院外面的 Cosplayer 與推銷自製 Rap 音樂的大叔，充分表現美國人美國夢的浪漫。

IMG_9484

不過想跟他們照相，是要給小費的。看心情給，一般來說大概是 $5 ~ $10 左右。
（同步發表於 http://jnlin.pixnet.net/blog/post/32436725）

Google Reader 將在 2013/7/1 關閉

根據 Google Blog 的公告：A second spring of cleaning，Google Reader 將在 2013/7/1 關閉，官方表示原因是使用人數日漸下降。Google 並沒有給出替代方案。

Feedly 馬上就公告請大家試試看他們的服務，並且放出正在寫 Google Reader 相容 API 的消息。不過現在Feedly 網站 已經屬於癱瘓狀態了。