什麼都破，什麼都爛，什麼都不奇怪

這是 6/30 我在 Ruby Tuesday 所分享的主題： Sinatra 。

昨天朋友 EvenWu (Dell 特價泡沫網作者）丟 Gtalk 過來，叫我幫忙找歌，要幫網站上主題曲。不過我一時沒意識到他要找什麼歌，最後他自己搞定了。是一首聽起來很正常，但是丟上泡沫網馬上會變得非常靠背的歌。

Anyway，因為真的非常靠背 XDDD。我拿去丟推特，他拿去丟 PTT 八卦版。

原本是很嗨的一件事，但五分鐘以後馬上就發現一個大問題了….

開始有鄉民抱怨超卡，不然就是沒聲音，不然就是只有特定瀏覽器才能聽到聲音。

（我們忽略了 PTT 八卦版瞬間 DDoS 的威力）

原因出在

1. 背景音樂 mp3（3mb）和負責播放的 flash 放在同一台機器（sharehost）上
2. 背景圖片（兩張 200K ）的圖 也放在同一台機器（sharehost）上
3. 音樂抓不完很卡。後來甚至是靜態檔案抓不完，也卡 document ready ….。
4. ff/win, chrome/win 這兩個瀏覽器，如果 flash 用 css 或是寬高隱藏起來，就不會 autoplay …

於是五分鐘後當機立斷，我跑去拿 s3 當 CDN 把 1,2,3 對主機的壓力散掉，不然大概鄉民的不滿就會害 EvenWu 在八卦版拿到生平第一個劣退（噓文太多）…
他也在當下的十幾分鐘內，開始用力的想辦法修 4 的 bug..

生平第一次做搞笑網站這麼累/緊張 …. XD 竟然要搞到上 CDN …

這是剛入手時當時寫的雜記 …模擬市民初體驗，很不幸的就直接嘗到現實人生的滋味（遠目）

※ 內含不少髒話與成人內容，不喜請跳過。

=================================

- 第一次玩時，我的角色跟我一樣是個阿宅。
角色設定完全一模一樣。
但馬上發現缺點：幹你老師阿宅把妹超慢。
加上為了賺錢上班，根本無法常出去認識人（否則會被fire）。

-> 馬上重玩

- 第二次玩，我角色設定就選擇當一個超帥、魅力又超高的警察
去圖書館逛，人見人愛。馬上就把到妹。
但是我又發現：幹，上班還是很花時間….

玩到想結婚生小孩需要還是很困難

-> 又重玩

- 第三次玩，角色設定同上。
差別在於這次我修改了金錢。

在把到妹結婚前老子不去找工作!!

這次就很順利，頭一天就去圖書館專心認識人。
打算結婚以後再去上班比較省事。

在圖書館把到正妹，然後當天下午就變成女朋友
晚上就推倒了…隔天就結婚了 XDDD

OK。開始規劃我想要的人生了，於是就跑去報名了警察 …
不得不說，養了一個老婆在家裡。跟女朋友完全不一樣…

女朋友時你還有興趣跟他玩很多不同選項。
變成老婆整天你就想點跟他嘿咻，不然就是傳宗接代…
你不想跟他嘿咻，他也會想跟你嘿咻（切到另一人的選單時會看到他願望）

— 這裡玩了兩遍。因為結婚以後我還是在圖書館隨便搭訕別人
不小心搭到一個男的。我講笑話給它聽，他竟然覺得我在跟他調情 XDDDDDD

讓我頓時就意識到這傢伙是好男人。於是興起了邪惡的念頭….
帶回家玩看看 （不知道可不可以玩 3P….)

趁我老婆在臥室玩電腦的時候，跟這傢伙在客廳接吻 XDDDDDD

可是天不從人願，沒多久老婆就關電腦了…一出門就撞破姦情。結果他跟這男的互甩巴掌 lol

因為男女打架太可怕了，嚇到我。我馬上把這傢伙趕出門。
然後跟老婆道歉，不管選什麼夫妻間的選項
他都扣分。因為他覺得我很可怕…..XDDDDDDD

（大概是雙性戀他沒辦法接受 XD）

還好玩這招之前有存檔。只好 rollback 回剛結婚的時候

結婚以後不馬上有小孩是不太可能的。

（本來以為結婚以後再開始人生比較簡單…）

因為三不五時就嘿咻，很快馬上就有了小孩，靠邀!!!
雖然那時候已經去上班有工作了…
不過想說應該沒差吧

後來小孩出生以後才發現，碼的又上班又養嬰兒真的超累
我跟我老婆都睡眠不足。所以兩個人內心的願望都浮現「辭職」….

最後只好叫我老婆辭職專心在家裡帶小孩，我繼續上班。
養嬰兒就是三不五時就想買玩具放他房間，內心願望也老是想跟嬰兒玩

養小孩時我老婆真的超累。真的很無聊時，我一下班就纏著我嘿咻 !@#$%^
其實去上班以後回家帶小孩，根本都不能出去玩。
我的男角內心願望一堆都是出去玩。

老婆內心願望就是有空時老公幫他按摩，跟他嘿咻

後來小孩比較大時，靠腰一不小心我老婆又有了…
這次雙胞胎!! （其實也是幫我老婆加特殊能力時，好奇幫他選看看…）
生了兩個女孩。（第一胎是男孩）

靠杯。完全嚐到什麼是手忙腳亂。只有兩個人帶三個小孩..
忙到快瘋掉。

（我現在終於知道為啥大家只要生一個了 >_<)

只好換大一點的房子（用金錢修改器），找保母 。
結果竟然還是不夠。我跟我老婆 24hr 都在顧小孩，幹幹幹….

玩到這裡想存檔，可是就當機了。

======

雖然只有這麼短短一段，不過已經讓我開始瞭解，原來前人在閒聊之間抱怨的都是事實沒有誇大 XD。人生快轉的震撼教育啊…..

最後歸納出的（人生）結論是：

1. 阿宅很宅，又一天到晚上班，把不到妹很正常
2. 魅力要很高把妹才快
3. 當田橋才有很多時間可以把妹
4. 先結婚再過人生不一定好…
5. 結婚完三不五時就想嘿咻，回家唯一想作的事也是嘿咻
6. 常常嘿咻後遺症就是會有小孩
7. 養一個小孩雖然還養的起，只是有人要辭職顧
8. 沒事亂生小孩不當無業田橋是養不起的…

前陣子模擬市民 3 剛出來，就跑去買了一套。這一代強調的是可全鎮互動 …

然後一玩下去就不得了了，失陷。沒日沒夜望著電腦，好像中邪了一樣不斷按著「確定」、科科笑 …。也實驗了不少糟糕玩法（以後會寫在其他篇）。之後也推薦幾個友人玩這套，果然也全數失陷 XD

昨天友人突然問我說，玩那麼久，有沒有玩過自己。我說沒有，這遊戲太可怕了，簡直像人生快轉器（命運好好玩）一樣。我怕玩下去一下就知道結局，頓時覺得人生無趣就連人生這本體 game 也不想玩了 Q_Q。不過他還是一直盧我玩一下….

最後我創了一個角色，叫「鄭叉滴」，設了五個特徵下去玩。

選了這些：

工作狂 - 一天到晚愛工作
天才 - 邏輯超強
電腦天才 - 超愛用電腦
拉他鬼 - 東西亂丟
書呆子 - 看書很快

才剛開始玩一個小時我就快受不了了。

在家不是一直在看書（還拿書去上廁所）
就是一直開電腦

開電腦只會固定做幾件事：

- 無限期工作
- 玩電腦遊戲
- 隨機上網找人聊天

靠 這角色根本是一個死阿宅

我在玩這遊戲時還一直要打斷這死阿宅不要做這些事(放回給電腦控制就會這樣）。自己在旁邊看他做這些事覺得好無聊，就算快轉都還是跳針的無限做這一些事 =_=。

難怪我每次回台中老家，爸媽老是問我，你要不要做一些其他事、你要不要出去跟我們游泳、你可不可以不要一天到晚不是看書就是打電腦？完全能體會我爸媽的無奈了 XDDDDDDDD

這個月的 Ruby Tuesday 又來啦！

活動時間：2009/6/30（週二）晚上七點到九點。
活動地點：台北市 典藏咖啡館(民權店)

報名請前往活動網頁，這次的講題是：

xdite: Sinatra: a DSL for quickly creating web-applications in Ruby.
gugod: Cucumber+webrat: Rails integration test

Sinatra 是一套非常有趣的小型 web framework，以其獨到的優雅 DSL 語法聞名，非常適合 tiny web application 開發。而 Cucumber 是一套將測試工作轉化成透過 parsing story-based 純文字來執行，好處是有一份讓非程式設計師閱讀的良好規格文件，同時也可以透過這種方式讓測試程式能自然地 reuse。webrat 則是一套 Acceptance Testing 工具，用以改善及補強 Rails 內建的 integration testing API，另一個好處是它還可以搭配 Selenium 或 Watir 實際打開瀏覽器來做 JavaScript 測試。

gugod 有豐富的使用及開發經驗，期待這次的分享

凌晨在寫 Yahoo OAuth。先是試了 FireEagle 那邊的認證，沒什麼問題。

值得注意的是，因為 Yahoo Oauth Implement 了 OAuth 1.a，所以 OAuth Ruby Gem 版本需 upgrade 到 0.35 版，以及 fireeagle 的 gem 需要用 mojondna fork 出來的版本。

不過在申請 Yahoo OAuth 那邊卡了大關 :/

1. 首先是申請頁面怎麼那麼難找啊 …
2. 另外就是一直卡 Domain Verification Failed 。換了幾個 domain 都一樣。看起來也許是 Yahoo 的問題？

跑到 YDN Forum 上面看，一狗票人中獎，似乎到現在都沒有修好啊？ :/

今天晚上跟 itsZero 討論幹壞事的細節。聊起之前我用 jruby + sinatra + GAE 寫的 MrIE6 ，一連才發現示範站 404 了。

呃。可是自從上線以來，我都沒有動過 DNS 設定啊，怎麼會莫名其妙 404 … 後來才發現是 Google 又改架構了。以前直接可以在 GAE 直接設 CNAME。

研究了一下，發現現在的流程改成這樣：

1. 必須要先去註冊 Google Apps, claim 我是 MrIe6.com 的 owner。
2. 然後要到 Domain Settings 去打開這兩項

Enable prelease features

Next Generation

3. 回到 Server Dashboard 可以 Add more services

加入你的 Google Apps ( 輸入 app id )

4. 然後設定 URL

再到域名商設定 CNAME 指到 ghs.google.com ….

真不是普通的囉嗦啊啊啊啊啊….

先記下來，以後這篇應該自己還會用到。

最近放假，窩在看一些大型 Conference 的 Slides 和 Videos，翻到 Qcon 2008 的這場 Talk：YELLOWPAGES.COM: Behind the Curtain，覺得蠻有意思的，看完 talk 以候趁著印象新鮮把重點摘要下來。

一般人對於 Rails 既定的印象都是只能拿來 prototyping，或者是 startup 開站時搶快，將來網站長大了之後，再用其他語言進行改寫的選擇（ 即使許多名列前茅的 Facebook Application 都是使用 Rails 撰寫，每天擁有上千萬的 Pageviews。開發者對於 Scale 這件事還是內心存疑。）。更不用說使用 Rails 來改寫大型 production site….。

然而，YellowPages.com 卻這麼做了。

YellowPages.com 是 AT&T 旗下的一個事業（ local yellowpage )

＊ Alexa 的排名在全球 600 名左右
＊ Daily Pageview 是每日 300 萬左右
＊ More than 48 million requests / day
＊ More than 1500 requests/ second
＊ 每日大概有 200 萬次的 Search
＊ 每個月有 2500 萬的 unique vistor
＊ 舊版純然使用 Java 開發 ( 架構圖 ）
＊ 新版 ( Ruby on Rais ) Since 2007/07/04

在新版本上線運行一年之後，YellowPages.com 的首席架構師 John Straw 道出了當初改版的背後故事以及技術細節。

為什麼要改寫？

＊ 原先的網站是由一群顧問在 2004-2005 年用 Java 寫的。寫完就跑了…
＊ Fundamental design problems
＊ Code 大概有 125K 行，但是一堆 copy-and-modify 混雜 :/
＊ Absolutly No Test ( Code) !
＊ 想加新功能非常非常非常的困難 ….

於是就開始策劃改寫了 …

改寫的目標

＊ 換掉 Java Application Server
＊ 重新設計介面
＊ 改寫的時候順便加功能

新站的架構需求

＊ Absolute control of urls - Maximize SEO crawl-ability
＊ No sessions: HTTP is stateless
＊ Be agile: write less code
＊ Develop easy-to-leverage core business services

當中經過的 Survey 過程 ( Ruby / Python )

2007/1 - 2007/3 花了三個月嘗試各種架構 ( Ruby / Python ) ，最後花了四個月用 Rails 撰寫了新版…

＊第一版 -> Web Tier : Rails ( fat controller ) , Service Tier -> Python
＊第二版 -> Web Tier : Rails ( thin controller) , Service Tier -> Python
＊第三版 -> Web Tier : Django , Service Tier -> Python
＊最終版 -> Web Tier : Rails , Service Tier -> Rails

最後選擇 Rails 的原因

1. 他們 team 最好的 python developer 剛烙跑 Q_Q…
2. Platform maturity ( important )
3. Better automated testing integration ( also )
4. A clearer path to moving parts of it to C if necessary for performance ( also )
5. The development team simply felt more comfortable with it.

機器配置的考量

不過還有一些事，因為是前所未有的改版。他們對以下這些問題也有疑問…

1. 需要多少台機器
- 原先 Java 版 的架構是 21 台。Rails 版總共用了 23 台（ Web Tier 17 台、Service Tier : 6 台）。DB ( Oracle ) 2 台。
- 所有的機器都是裝 CentOS 5, 只有 DB 是裝 Solaris ( John called Solaris “a mistake they wouldn’t repeat,” not because of any particular problems with it but because of a lack of system administrators in their organization who had experience with it. XDDDDDDDDDD).
2. 一台機器要跑幾隻 mongrel
- Web tier: 16 隻 , Service tier: 30 隻
3. 要準備多少記憶體給 memcached 用
- 4G
最後架構 ：

Performance optimization

主要的 performance goal :

＊Sub-second home page load time
＊4-second average search time
＊Never dies

1. 考慮過 HAProxy and Swiftiply 但是最後選了 F5。（因為他們手上有 F5 而且熟悉操作…)
2. 自己寫了 Mongrel Handler 把 request 挑出來從 Web Tier 直送到 Servie Tier 而不經過 Rails …
3. 自己寫了 C library 去 parse search cluster 的結果轉成 hash
4. 在 Web Tier 方面，選了 Erbuis 去 render view
5. 遵照 Yahoo performance guidelines 去 tune 前端 ( 比如說 minified javascript, 把 css / js 包成一支 , 將 image 移到 Akamai 上等等… ) , 將 Prototype 換成 jQuery.
6. Apache was slow serving the 42-byte single-pixel GIFs that they use as analytics tags，他們去挖掘了原因之後換成了 Nginx。( John 還氣憤給出了結論 : Apache is unsuitable for any production enviorment, in general XDDDDDDD)

經過這樣的 Tuning 以後，已經比以前 Java 版快上不少了，他們對這樣的改版結果很滿意。至於上線後前六個月，他們反而卡 DB 問題比較居多…

對於 Slow request 的解決之道

1. Slow requests in the web tier caused mongrel queueing
所以自己幹了 qrp ( query reverse proxy ). Establish a backup pool where requests get parked until a mongrel is available （跟在 Nginx 上設 maxconn 為 1 ，其餘的 queue 住的作法類似）
2. Experimented with different malloc implementations
3. Started using a custom MRI build — ypc_ruby ( MRI 是指 Matz 版 Ruby 也就是一般 Ruby , 他們自己的 ypc_ruby 版本是對原版 Ruby 打上自己需要的 patch )
4. Started using a slightly-customized Mongrel

Ruby not Rails

1. 之後會嘗試把 Service Tier porting 到 Merb 去
2. Supporting development of Waves ( 他們 hire 了 Waves 的開發者 )

改版完畢感想

滿意啊！！

觀眾提問

演講結束之後觀眾提了蠻多問題，也相當精采.. XD （太多了挑一些我覺得有興趣的整理出來…）

Q: 為什麼要用 Oracle ?
A: 因為 AT&T 有買 License..想不到什麼理由不用 XD

Q: 你們會 memory leaking 嗎？你們的 mongrel 的 uptime 多久…
A: 不會！我們沒有這種情形！不過每次我們 deploy 新版本的 code, 會重開一次，大概每隔兩週到一個月會這麼做…

Q: Team 人數 和 開發期?
A: Core Team 大概是四個人（其中只有一個在學校寫過 Rails)。當然還有部分是拆給其他人寫…。至於開發期的問題，在 AT&T 其他部門也有 project 改寫計畫，最後花了 24 個月。我們也以為要這麼久，但用 Rails 改寫 YelloPages 最後花了四個月.

Q: 你們用 ActiveRecord 嗎?
A: Yes

Q: 那表示你們的 db 需要 migrate 囉
A: Yes。重要的 model 有 migrate …

Q: 你們的 Search ranking system ，有想轉 Lucene 嗎?
A: 我們從來沒用過 Lucene，但有想過用 Lucene，我們現在在用的是 FAST。不過不換成 Lucene 是因為我們如果想擁有自己掌控的 search engine，必須先去 hire 一個會寫 Lucene 的人，然後拜託他幫忙加上 Customer Ranking System 上去。但我們自己的 search cluster 已經夠快了 ..可以達到 3600 qps …。但最終目標當然是想要擁有自己能掌控的 search engine。

—-
相關閱讀

YELLOWPAGES.COM: Behind the Curtain（這場 Talk 的投影片）
The Rebuilding and Scaling of YellowPages.com( 這場 Talk 的英文版重點摘要）
My Favorite Quotes from the Yellowpages.com Ruby on Rails Talk ( 外國鄉民對這場 Talk 的感想）
Surviving the Big Rewrite: Moving YELLOWPAGES.COM to Rails ( RailsConf 2008 同一講者，類似主題，但內容面向不同）
At&T Interactive: The Many Facets Of Ruby ( 這一份投影片有 YellowPages 當初轉換過程，一些詳細的架構和數據，值得一讀）

這是幾個小時前 Google 剛在 Googe I/O 上發佈的新產品 — Google Waves.
附上截圖一張以及從 Google Waves Goodbye to E-Mail, Welcomes Real-Time Communication 轉來的幾段重點。

Google Wave is an attempt to replace not one but all of these methods, rolling threaded conversations, real-time chat, nested comments, media sharing, link sharing and wiki-style collaboration into a familiar interface that looks and behaves like an e-mail inbox, complete with folders for keeping things organized and a search box for digging up older threads.

# 多媒體版即時 Twitter-like

—-

Images can be dragged and dropped into the app in the browser if Gears is installed. All of the uploading happens in the background, thanks to the web-workers component of HTML 5. Wave also has an API, so people can put waves on their web pages. The whole interface of the wave gets embedded in the page, but it can be styled to match the blog or external site. Replies, questions and edits all appear in real time.

# 可以外嵌到任何 Site

—-

The methods of communicating we’ve grown used to in the last decade, primarily e-mail and instant messaging, are being usurped by more intuitive and time-sensitive alternatives on the social web. Thanks to Twitter, FriendFeed and Facebook, the emphasis now is on real-time communication: Updates are expected instantly, and we leave many of our conversations open for comments. There’s an initial flurry of activity, a constant stream of back-and-forth chatter between participants. Conversations morph and evolve quickly, then, hours or days later, eventually sputter out and fade.

This is the model Wave is clearly embracing. But Google didn’t initially set out to build a better Twitter or a better FriendFeed.

# 打了 Twitter / Friendfeed / Facebook 一巴掌 XDDD

—–

這樣看起來，有了 Wave 這神器，把 Jaiku 這個 project 砍掉是很正常的。至於 Google 想收購 Twitter 這件事，看起來在 Google Waves 推出來之後應該可以反證是個謠言…?

這服務太凶殘了 ..

這篇文章是要來推薦一本書 / 一個 Wiki - Designing Social Interfaces

所謂的 Web 2.0 / Social Network 發展到現在，feature 大概九成九都定型了，不是我抄你就是你抄我……最後就有人整理出來所謂的 Social Pattern 還弄成 wiki 。一整個就是 Feature 大全 XDDDDDD

所以其實我還蠻推這本書 / Wiki 的，網路從業人員應該都可以翻翻。工程師也可以拿給你家….呃….腦袋可能轉得比較慢的…..網站企畫看。也許在溝通 Feature 和設計 Flow 上可以加速一下….也可以避免想山寨什麼功能結果山寨到最後比山寨還不如的下場….

內容有什麼 標籤雲、Share This、Give Gift 一堆這類的鬼東西…