2008/4/22

v0.22 釋出

目前都是做小地方的調整及修改:

* 增加 rss:首頁 (新建主題樹)、分類頁及單一主題樹頁 (回應)。
* 增加網站縮圖:雖然很多人都說頁面很簡潔,但看久了終究「平」了點,所以加上了縮圖 (目前採用 MozShot 提供的服務),而 snap 仍保留,作為縮圖不出來時的輔助。

Keep Walking, Keep Working...

2008/4/16

v0.21 釋出

感謝親友/網友/同事的協助測試,給我們不少鼓勵、批評建議

根據大家的測試,我們做了如下的修正:

* 討論的「To: 標的物 # 暱稱」帶錯資料:已修正。
* 狀態切換不夠明顯:加粗處理。
* 「建立主題樹」按鈕不明顯:加深顏色、前方加上小 icon,以做區隔。
* 首頁加上三標:做內容導引之用。
* 若有錯誤訊息出現,區塊顏色會變化,加強提醒。
* 新建立完成主題樹,會出現「轉寄給親朋好友」的提示 (註*)。

v0.21 上線~

----

註*

之所以會加上提示的原因,主要是目前的使用者會把這邊當作「知識+ 」來使用,發表了一個主題,然後會希望網友來協助回答 (ex: 尋找懷舊美國影集)。

不過,令人尷尬的是,挖趣 wowTree 目前只是新興的小站,並沒有 Yahoo!奇摩 那麼恐怖的人潮,所以這樣的主題樹,基本上是非常難獲得網友的回應。

建議的作法,是將這一個主題樹轉寄給你的親朋好友,或志趣相投的網友/團體,運用人際的互動,一同灌溉主題樹。

2008/4/12

上線!

今天是黃道吉日,挖趣 wowTree 在 4 月 12 日 上午 10:30 上線了。

上線的前兩天 (4/10),我從上午 9:00 等到下午 3:45,中華電信的人員才來家裡安裝光纖。原本插 ADSL 的電話孔,竟然不被光纖接受,紅燈一直亮著,安裝人員說光纖會挑線路,書桌旁的線路品質可能不佳。

最後,光纖安裝家裡電話線的源頭...客廳,紅燈是熄了,但挖趣的主機該不會要放在客廳吧?晚上,在書房牆壁找到另一個電話孔,而且可以通過光纖的檢測,這才讓我安心。

上線的前一天 (4/11),工程師 Jon 要來我家裝服務的主機,我等了 2 個小時,才接到工程師來電說...他迷路了,導航裝置把他帶得團團轉。被打敗的我,騎車去帶工程師來我家。由於工程師之前就已經把主機的作業系統灌好,不到 30 分鐘就搞定了!

當天晚上,我才意識到隔天 (4/12) 就要上線了,哇哩咧~ 我還沒做完最後的測試、明天要上線也要先塞資料,讓首頁門面好看一些,公告要寫些什麼、要做什麼推廣動作...

要搞定的事情還真的不少...我到 4/12 凌晨 3:00 才上床睡覺。

4/12 上午 10:30,工程師把 wowTree 的首頁打開,嗯!上線了~ 開機大吉。

launch

2008/4/9

瘋狂測試 ing

就快上線了,不過光纖還沒來裝,機器還躺在工程師家(要等光纖裝好),唯一還能做的,就是測試、測試、再測試。

有人笑稱:「服務只要掛上 beta,user 對 error 的容許度就會提高...」我深深不以為然。beta 或許可以說是測試版,但推出的前提,是你對目前的這一版,已經善盡了測試之責,而不是推出 beta 要網友容許錯誤、協助測試。

雖然,bug 是抓不完的,測得有點頭暈目眩。但是,努力的測試抓蟲,也是對工程師拚命寫出程式的最佳回報。

再測~ 再測~ 測到我看不到 bug 為止... (希望不是眼睛變瞎)

2008/4/2

上線前的準備工作

今天又來到工程師 Jon 的家,主要還有一些測試到的問題要修正。

修完之後,跟 Jon 討論剩下的待辦工作。原本要找人來做一些互動操作,但 Jon 建議直接用 jQuery 搞定,我半信半疑,只怕誤了更多的時間。不到 2 個小時,他和我搞定了所有的(其實也沒多少)互動操作,Jon 笑著說,因為我們的需求就只是單純的「toggle (開/閤)」,加上 jQuery 這個強大的工具,自然輕鬆搞定。

至於服務的主機,由於我們服務的目標對象主要是台灣的使用者,所以 Jon 不建議承租外國的主機,雖然便宜很多,但速度就是慢了一些,使用者的耐心是有限的。於是,Jon 建議架一台主機擺在家裡,再拉一條光纖試看看。

就這樣,我隔天去中華電信營業處申請光纖,Jon 週末回高雄順便買主機,我們決定 wowTree 在 4/12 (六) 上線!

launch day

2008/4/1

二人開發的合作模式

隨著經驗的累積,我愈來愈熟悉「二人開發」的合作模式:

* 我坐在工程師的旁邊,先講解這個頁面及相關後續頁面的概要
* 接著開始討論哪些功能要改規格、延後做,或砍掉
* 然後工程師開始寫程式套頁面
* 有時工程師會邊寫邊反問我這樣做對不對,或是改成那邊行不行?
* 除非影響很大,通常我會在第一時間做出決定
* 工程師寫好了程式,他會先測看看能不能動
* 如果能動,就會要我先簡單測看看,是否有做到我想要的 spec
* 如果有明顯的問題,馬上回報給工程師,工程師馬上修正
* 如果沒有,就由我事後找時間詳細檢測
* 如果遇到頁面要調整,我會先記下來,事後找時間修改 CSS 或製作新頁面
* 我回到家,用 Tortoise SVN 將檔案抓回
* 如果測到程式有問題,記錄下來
* 如果測到文案訊息有問題,直接修改內容文案
* 如果測到頁面有異常,直接修改 CSS 或相關圖檔
* 再用 Tortoise SVN 將檔案回傳 & 同步 (sync)
* 回報工程師有關程式有 bug 的部分

列出來有點鎖碎,但這樣的合作模式減少了多餘的動作及時間的浪費。
我經歷過,才知道它的美。