[Memo] Dream bigger, because you deserve it indeed

Image Credit

前言

這一篇文章,我已經構思許久,打從辭職後我就開始記錄我的心境轉折還有遇到的所有事情。四個月過去了(這篇文章是寫於 2013/8/21,而我辭職的時間是 2013/4/19,剛好滿四個月),我也依照著我自己心中的想法走到這一步,也才有這篇文章的出現,就讓我和大家分享這四個月我學到的東西吧。

很多人不了解,為什麼我會從人人稱羨的 T 公司離開,其中工作經歷還只有短短的十個月。有兩個原因,第一個原因是我在幾個月前就安排了一個為期七天的長假,和我當兵的好朋友書玄一起去菲律賓體驗 Couchsurfing 的文化,而 4/19 的半夜就是我們出發的那一天。第二個原因是,因為上層的改組決定,讓原本一起工作的團隊被迫中止,打散所有人到各個部門去。雖然我的 Manager R 真的很賞視我,但是因為工作的性質和我未來規劃(及個人專長)有所落差,所以最後就因為這兩個原因離開了 T 公司。也許真的很可惜,但是人生就是這樣充滿轉折吧?而我的人生,也是因為這一次勇敢的辭職,有了改變。

原來,我喜歡旅行

在 Manila 的那七天,我和 Kobe 認識了很多到很好的菲律賓朋友,我們一起 Couchsurfing,一起和整個 Manila 的 CS 社群租下整台 Jeepney 去玩傳說中的 Pagsanjan Fall,一起誤打誤撞跑到了高山 Mt. Ping-as(下圖),一起去體驗當地的夜店,一起在整個只有我們兩個台灣人的體育館內打羽毛球,一起去 Taal Volcano 看那奇妙的火山地形,一起去看那永生難忘的 Manila Bay 的日落。

好多好多的旅行衝擊,讓我找到失去興趣的自我(寫程式原本是我的興趣,但是在變成工作之後就漸漸消逝了)。原來,「旅行」是一件我很喜歡做的事情,而它可以衍生成為我的一個興趣,讓我在下班(寫程式)之餘調劑身心,成為我生活的另一個重心。

從菲律賓回來之後,旅行這件事又衍生出一個名為 TwoBackSurfers 的團隊,就是我、書玄還有翔 Sir 三個人的小小團隊,我們開始到處去旅行,還花了七天以 Couchsurfing 的方式去環島,除此之外也開始做我們自己的衣服、自己的吊牌、自己的網站、自己的影片甚至是經營自己的 Facebook Page。很多人曾問過我「為什麼你要做這麼多吃力不討好的事情」,但我總是笑笑的沒有回答,因為我也不知道為什麼,但是我打從心底卻認為這是一件我由衷想做而且必需去做的事情。

「原來,我喜歡旅行,如此而已。」

創業?真的不是這麼簡單

而工作方面,我才知道,原來所謂的「辭職創業」,不是簡簡單單一兩個人當口號用喊的,而是要真的下去做過一些明確的市場調查,而且真的要有短期斷糧的決心才可以,我當時就是抱著一種嘗試的心態在做這件事情,才了解到原來現實世界和你想的根本就不一樣。你每天最擔心的問題就是「今天有沒有錢吃飯」,然後還要承受少數親朋好友給你的無形壓力,而這些真的都是壓死人的稻草。

我這個時候才知道身邊的那些創業朋友是以多大的壓力在生活(應該無法想像),也了解到自己在做這個決定時沒有思考清楚的問題。

雖然最後我們放棄了,但是未來,也許是幾年、幾十年後,當我有足夠的人脈、有足夠的錢不怕短時間內斷糧並且還有一個可行計畫的話,我還是會再試一次,再從轟轟烈烈的戰場中學到更多的事物吧。(我很建議大家去看猴子靈藥在書中討論「辭職創業」的這件事情,特別是打算要「辭職創業」的人,我就是看了然後不信邪,硬是要自己走一次證明他的論點讓自己痛過才學到教訓)

轉機?

之後,我剛好有機會和台灣的天才級駭客 C 一起遠端共事,雖然工作是以接案類型為主,但是因為裡面有許多跨國的案子,所以多了很多機會要自己和外國人透過信件溝通,這時,我才了解到在大公司的我,已經開始習慣說一做一的部隊化管理,所以很多時候不懂得變通,其中有幾次還造成 C 的困擾,但還是很感謝他願意花時間教我,讓我不止在技術上,甚至是溝通、時程規劃之外的事情上有所成長。

「雖然,我離他們的世界還很遠,但是至少我有這個機會在他們的背後跟著,一起朝著下一個未知的世界前進,也早已讓我心存感激了。」

可惜的是,C 也認為我這樣子以 part-time 的方式工作很難養活自己,因此他建議我該是時候考慮一下去尋找下一份穩定的工作,先讓自己免於斷糧危機才能夠有更多的空間與時間來做自己想做的事情。我想了想也覺得合理,所以我認為該是開始思考尋找下一份工作這件事情了。

面試

就在七月環島完後,我覺得差不多是時候開始投履歷了,因為唯有穩定的工作才能維持我到處旅行的計畫,也才能生存下去。所以七月中開始我就在求職網站上面尋找所有有關「前端工程師」的工作機會,而依面試順序最後統整出六間公司的一些資訊,希望能幫助到有需要的朋友(如果看不懂就直接跳過吧,這邊都是技術的東西)

1. Richi – Web Developer

 

通常大家都知道有這間公司的存在,但是卻不知道他們在做什麼,他們目前最知名的服務就是線上的紅利點數交換平台,不過他們最近開始要發展新型態的業務,但為了達到這個目標所以會需要異業合作,而前端工程師會需要花 40% 的心力維護平台,然後花 60% 的心力來因應不同的業務需求來客製化網站或是平台,並且是以小型編制的方式來和不同的人員合作。

就技術面來說,因為面試我的技術主管是從 Y! 公司來的,所以在前端的領域著墨很深,很多問題我覺得都問到了「點」上,因此如果是以學習成長空間為考量,因為這邊的人都是之前待過 T、Y!  … 等許多大公司,所以他們也有很多東西可以讓你挖,整體來說是可以學到很多的。而我也覺得他們接下來要發展的新型態業務是非常具有潛力的,就長遠來看是一件相當值得投資看看的公司。

結果:得到 Offer 。

2. iNDIEVOX – Software Engineer

 

有在玩音樂的人都知道 iNDIEVOX 專攻的是音樂電子商務的領域,辦公環境也相當特別,會讓你有一種身處在咖啡廳的錯覺,到處都是音樂相關的唱片、海報還有相關產品。福利就是和一般的公司一樣依勞基法規定,除此之外就是很多時候會拿到很多和廠商合作的公關票,所以對於喜歡音樂的人來說這真的是一個很好的環境。而面試雖然和主管討論了很多有關於前端的問題,但是因為他們的職位比較需要的是專注在後端的人,所以最後我的資料就被 bypass 到友站「streetvoice」,這一部份我之後會再詳談。

結果:因為和他們要的人不太一樣,所以被轉介到友站 Streetvoice。

3. Vpon – Frontend Engineer

 

因為以前在 T 公司的時候就看我們的神手 iOS 工程師 I 分享過 Vpon 他們廣告平台的一些資料,所以對於他們公司有一定初步的了解了,才想去應徵,同時想看看這間公司到底是怎麼樣的一個公司。我不得不直說,可能是因為他們對於我的學經歷有一定的認同,所以這是唯一一間沒問我任何技術問題的公司。

這間公司專注在行動廣告投遞,每天處理的訊息量只能用驚人來形容,而他們要尋找的是一位可以帶顉前端團隊的 Leader,並打造下一代的行動廣告投遞平台。說實在的我對於這個機會相當感到興趣,因為平時很少有機會可以接觸到大量資料。除此之外,這個職位也相當具有挑戰性,可以自己設計一個全新的平台及供開發者使用者 3rd libraries。

雖然如此,但公司認為我到職的可能性比較低,除非我確定會到職才會和我談更多細節並發佈正式的錄取通知。但對我來說,交通真的是一個很大的問題,文湖線和我住的地方相差甚遠。而我幾年前也曾經體驗過那人擠人的忠孝復興轉車惡夢,所以就決定放棄這個機會了。

結果:有拿到口頭 Offer ,但是因為交通的關係所以我最後放棄了。

4. FlipTop – Frontend Engineer

 

這是一間專注在分析大量社交資料的美商公司,而我有一位曾經一起合作過的 W 學長在裡面工作,所以當我在 PTT 得知他們要徵前端工程師的資訊時其實我還蠻開心的,一來是因為美商福利很好(可以參考他們的官方網站)、二來是我對於分析社交資料這件事情相當感興趣。但和公司聯絡上之後其實讓我有點失望,雖然他們開出來的職位是前端工程師,實際上面試的過程卻都是專注在後端及演算法的部份。

可能是因為 FlipTop 的系統是用 Scala 打造出來的,所以前端和後端的部份結合的有點密切,因此就算是前端工程師也要了解如何使用 Scala Lift。我覺得這是可以理解的,畢竟這是由整間公司所選擇的解決方案,只是以現階段的我來說,(Scala)能力就會和他們預期的人有所落差,雖然我用簡單的方式實作出來一個 workable 的平台,但是似乎和他們想要的不太一樣,被要求在 Performance 上面要有所成長。之後我就覺得,公司的「前端工程師」和我想像中的「前端工程師」有點落差,所以我就和他們說明我的決定後中止了接下來的測驗。

結果:提前結束前測就沒有後續了。

5. Streetvoice – Frontend Engineer

 

還記得前面我說到,我的資料被 iNDIEVOX bypass 給 Streetvoice 嗎 ?這是因為, Streetvoice 和 iNDIEVOX 的投資者都是中子集團,所以他們的辦公室是在同一個地方,不同區塊罷了。在業務上面,Streetvoice 和 iNDIEVOX 的不同點在於,他們主要發展的是獨立音樂的社交平台,因此整個網站的開發有很大的一部份是專注在這個平台上面。

而和他們的技術長聊天後發現,他們的團隊給予開發者很大的自由,在這邊大家可以玩新的技術並實作在新的產品上也可以一起腦力激盪來實作一些有趣的小 Project,相對於一成不變的工作環境來說,是有比較大的彈性的。

我想可能是因為我在 iNDIEVOX 已經被他們的技術長面試技術一輪的關係,所以 Streetvoice 的技術長也完全沒有問我任何技術的問題,可能覺得再多問一次很花時間,所以我們都把時間拿來討論公司未來的發展等等。

結果:聊完天的當下就直接得到口頭 Offer,並在數天後收到他們寄來的 Offer letter。

6. Mozilla – Frontend Enginner

 

對於前端工程師來說,Mozilla 這間公司是沒有人不知道的。大家都知道 Mozilla 基金會對於推動網頁標準這件事情不遺餘力,而其下產品 Firefox 更是改變 Web 的重要推手之一。其實我覺得真的是蠻幸運的,一來是因為剛好 Mozilla 為了要開發  Firefox OS 所以正在到處尋找人才,二來是因為我的 Resume 並沒有因為只有十個月短短的資歷而被刷掉,所以才有機會進行接下來的前測。

首先我真的要說,我覺得 Mozilla 的前測真的很有水準,因為題目是要求我要在一個星期內用 Native API (不能用 jQuery 等第三方 libraries )實作出一個 Autocomplete 的 plugin。剛好我很久以前就想做 Autocomplete 很久了,這次就順水推舟來實做一個自己的 plugin 吧。

在實作的過程中我才發現到,原來我們是多麼的依賴那些 libraries,光是 toggleClass / addClass / removeClass 這幾個極度常用的 function 都要自己先實作出來才有辦法繼續做下去,除此之外,還要自己去實作 ajax / getJSON 等 function 來溝通存取資料,這真的是要親自下手才知道原來這些 libraries 是多麼的偉大,處理掉這麼多繁雜的事情才能讓我們這些開發者以如此便利的方式操作元件,並專注在自己的 business logic 之上。最後,我也順利的通過所有面試。

結果:在最終面試結束後的隔天中午接到電話錄取通知。

最後

這四個月來,有許多不為人知的心酸,有苦、有累、有歡笑、也有淚水,但很開心的是我身邊還有這麼多人支持著我,如果沒有大家,就不會有今天的這篇文章,也不會有今天的我了。

知道為什麼我把文章的標題下為「Dream bigger, because you deserve it indeed」嗎?因為我總是覺得,不論當下的事情是好是壞,對未來的自己一定都是一個轉機。而年輕的我們,千萬不要忘記作夢的能力,也不要把自己的夢做小了,通常,如果那件事真的是你朝思暮想的夢,很有可能,你已經具有一定的能力去實現他,只是你自己不知道而已,放手勇敢去做吧。

不要害怕去嘗試,怕的應該是沒去嘗試的自己,如果當時辭職後沒有經前同事 L 學長提醒,我也不敢主動去嘗試那些人們眼中遙不可及的公司,也就沒有這麼多有趣的面試故事可以分享了,真的很感謝他。

即使未來人生的路上到處充滿著未知與挑戰,但至少我發現,我已經一步步朝著我高中時既定的目標在前進了,無愧於心,這樣也就夠了吧?

最後,我只想說一聲,

「謝謝你們。」

-moz-eragonj: true;

[Notes] Something you must know when fighting with IE7

Image Credit

全世界 Browsers 的使用率 (July 2012 ~ July 2013)

最近剛好有一些實戰機會可以和 IE7 來奮鬥,身為 FED 卻一直 skip 掉 IE7 好像不太好,有種沒有實戰過的感覺 xD … 現在想要把一些小細節記下來,希望能幫到想要和 IE7 奮戰的隊友們 xDD

δ 前情提要,如果是要解 IE6 的話 … 我只能請你自求多福。不過至少你能先叫做這個決定的豬腦去看一下微軟官方做的網站 IE6 Countdown,如果他發現自己做錯事的話,說不定問題就迎刃而解了呢 hahah。

奮戰流程:

  1. 如果你的作業系統不是 Windows 的話 (就算是 Windows 也是可以),那真的要先感謝一下佛心微軟放出來的 modern.IE ,因為你可以在上面找到各個作業系統上,各個虛擬化平台上內建好各個 IE 版本的虛擬硬碟。你就不用只為了測 IE 再來個什麼雙系統、三系統了,掛個 VirtualBox 就可以省下很多空間還有時間。( 因為我是用 128GB 的 SSD,所以空間有限,我個人的作法是把虛擬硬碟全部丟去行動硬碟上面,跑的很順也省下很多空間,可以參考一下)
  2. 在 fight with IE7 之前,先把戰力放在 Modern browsers。我特別去網路上找有關 browser 市佔率的各種資料,而資料整體上都是呈現出如本文一開始那張長條圖一樣的分佈。所以切記,時間就是金錢,特別是如果整個團隊就只有你這位 FED 的話,真的要先把事情都搞定後,再來打 Boss 呀。
  3. 終於要打 Boss 怪了,FED 們都知道(只有你家的 Boss 不知道) IE7 最強的攻擊技就是「完全沒有 Developer Tool」,這招真的強到讓人完全沒有還擊能力,因為通常 IE7 最大的問題就是 Layout 的不一致,尤其是對 IE7 完全沒有經驗的人來說特別如此,所以總是會很頻繁的手動調整 Layout。不過我找了一陣子後發現其實微軟有開發自己的 Developer Tool 給 IE7,只是並沒有內建在 IE7 裡面,而是需要自己手動下載來安裝,所以切記一定要先把你的 IE7 裝上 Developer Tool 呀。
  4. Let’s fight !!
  5. 特別開一個 IE7 fix,然後透過 Conditional Comments 來引入相關的 CSS / JS 檔案,這樣可以讓你原本的程式碼抽離於這些 hack 之外(我真的認為這些都是 dirty hack),所以不要 pollute 太多東西進去原本的 CSS / JS,這會造成維護上的困難也沒必要。
  6. 如果你使用到一些 CSS3 的東西像是 border-radius 或是 box-shadow 之類的屬性,記得搭配 CSS3Pie 來服用,通常可以解掉 90% 以上的 CSS3 問題,雖然好用但是要記得一些小事,就是有一些屬性只支援 shorthand version,請自行查閱一下 document 別寫得太開心到最後 Pie 看不懂就囧了。
  7. 通常 IE7 Layout 最大的問題是發生在 hasLayout 這個屬性上,根據 Sitepoint 這篇文章的解釋, 可以了解到這個是 IE 賦與元素的一個內部屬性,它的用處是「讓該元素本身及其孫元素(descendant)具有處理定位 (Positioning)及大小(sizing)的能力,而不是依賴於它的祖元素們(ancestors)」。而該文有列出幾個元素像是 img … 等。那為什麼會和這個屬性有關係?因為除了 IE 預設清單內的元素們具有這個屬性外,其他的元素是沒有這個屬性的,文章內有提到幾個常見的現象,像是「元素部分內容存在但是部分卻消失」或是「畫面只出現一半」。而要從 CSS 讓元素強制具有這個屬性有許多做法,最常見的做法就是設定一個 zoom: 1; 就可以了,這就是為什麼我們很常看到很多 3rd party libraries 在 CSS 中會加入這個東西的原因。不過這背後還有很多細節及一些奇特情況,可以參考微軟的這篇
  8. 如果你有使用 font-awesome 的話,請記得加入 font-awesome-ie7.min.css 的 hack,你會發現他都是在利用 zoom: 1; 來解 hasLayout,還有加入 innerHTML workaround 來解 IE7 不支援 pseudo element selector 的問題 xDDD
  9. 如果你有使用 bootstrap 的話(我是用 2.3),我發現如果用組合式 grid 來達成滿版的話(我這邊碰到的情況是 span6 + span6 或是 span4 + span8),整個 Layout 就會炸掉,所以要特別手動調整 width ,這邊要特別留意一下。
  10. 利用 zoom: 1;*display: inline; 來解原本被我們套用 display: inline-block; 的元素們(在 Modern browsers 我們用太習慣了,所以這個問題很多)。
  11. 如果你有用 <ul><li> 的話,不要用 list-style-image 來客製化他的樣式,因為如果有 position 上的需求,並沒有 CSS 可以直接控制這個值,可能會調到死,取而代之的你可以改用 background-imagebackground-position 搭配 padding 來手動 position,效果佳。
  12. … 未完待續

以上是和 IE7 奮鬥過的一些心路歷程,希望能幫到一些人,未來如果還有什麼有趣的狀況也會更新在這個清單內,Rock 😛

[Node.js] Difference between module.exports and exports

Image Credit

This simplified Chinese blog tells the details about the difference between module.exports and exports.

The most surprising part of the difference is that you can not use them together at the same time. (I know no one would use it in this way, because you have to make sure the coding style is the same anywhere.)

After testing, if you use these two ways to export modules, defined methods or properties in exports will be discarded directly and only export the ones defined in module.exports.

So I think the best practice here is to use module.exports instead of exports to define your stuffs.

Read More on : Here