2013年12月19日 星期四

網站效能不佳?談『如何判定系統變慢原因』的簡易 SOP


        上次『大禹治水』提到,對於採用 Windows+ASP.NET+MSSQL 技術的網站服務,找出網站系統變慢、效能不佳的原因其實有一簡易 SOP 可以起手,減少無頭蒼蠅盲目亂撞的時間成本浪費,這篇就簡單介紹一下這簡易的 SOP。

        符合“簡易”的這個特徵有兩個條件:
  1. 不用額外安裝任何第三方軟件或工具,只使用作業系統內建的基本工具即可。
  2. 與系統特性無關,不需要先理解遇到麻煩的系統任何內部原理與商業邏輯。
        所以任何任何人,都可依照這個 SOP,花個半天時間迅速判斷 80% 以上的網站效能瓶頸點。

2013年12月14日 星期六

我的 log4net 設定的 Best Practice


        一個系統是否容易追蹤與維護?出了問題容不容易快速查閱、釐清問題癥結?系統日誌(System logging)絕對佔著舉足輕重的角色。.NET 寫系統日誌的方案,最出名的大致上只有兩種:log4netNLog。兩者之間沒什麼優劣比較,這種東西,精通其中之一就很夠用。

2013年12月7日 星期六

從『玩股網驚魂記』談大禹治水


        楚狂人的『玩股網』前陣子發文公告系統不穩的情形,這兩天他寫了篇『玩股網驚魂記』說明了前因後果,看完後覺得可以當作一個個案解析的案例。

        先談談文章所說最後發現玩股網無法正常運作的結論:被大量的 Crawler(網路爬蟲抓資料導致伺服器過於忙碌。開頭原本說判斷這應該不是駭客攻擊,其實就結果來看,這也算是一種攻擊手法:分散式服務阻斷式攻擊DDoS

2013年11月30日 星期六

[連載]新創公司歷險記-1:臨危受命,掌握資訊

        今年四月,正徘徊在職涯下一步的十字路口,當時剛好接到前同事電話力邀我加入一個剛成立半年的新創公司團隊,一起打造一個全新的新產品而努力。

        當時被原公司既有的營運系統基於管理上風險的考量,而搞得拳腳難伸的我,在與灰心喪志之下,很受眼前這個可以盡情嘗試各種全新技術與各種假設的創業機會所吸引,毅然訣然地揮別前公司

        由於要能盡情試驗新技術、開發流程與團隊合作的模式,我加入的條件就是我必須擔任掌握這些權力的  Team Lead(這篇)

        然而真正置身此處,才發現事情也沒有想像中那般美好。

2013年11月8日 星期五

YAHOO 2013 HACKDAY 附錄:兩分鐘的 Bubble DEMO 劇本稿


        科技幫助人溝通越來越快速、方便,但是人與人之間的溝通,還缺了一個重要的環節。我們團隊所製作的 Bubble Chat,就是為了補足這遺落的環節。

        進入我們的 APP ,首先結合超級好用的 YahooMap,精準地呈現你所在地週圍,其他人透過這個 APP 所分享的生活大小事,心情喜怒哀樂。

YAHOO 2013 HACKDAY 參賽記錄與心得


        剛好透過 INSIDE 網站宣傳得知 Yahoo 今年所舉辦『駭客松(Hackthon)』。

        我實在認為自認有熱情的開發者,一生中都應該至少來體驗一次這種 “燃燒生命、爆肝寫 Code” 的活動!所以之前總是錯過這類活動的我,這次看到比賽消息,立刻在 FB 上揪團參加。

        由於這次競賽的要求跟過去以往不同,特別強調 UI / UX 設計,並且要求團隊中一定要有至少一個 Designer 參加,所以造成這次比賽隊伍中,女性比例大幅提高,每隊通常會有一個女性參加(本隊也是),甚至有團隊是完全女性組成的四人隊伍。如果去網路上尋找過去幾屆的比賽作品,相比之下也會發現這屆 DEMO 的作品視覺上質感有大幅提升的效果。

2013年10月16日 星期三

新創公司的 Team Lead 跟你想的不一樣!


        前幾天一位前同事到家裡做客,邊玩邊聊,談到他最近在工作遇到的挫折。

        這位前同事跟我一樣都離開前公司後,帶著一些理想加入了新創公司。先前我一直鼓吹他要積極爭取新公司新團隊內 Team Lead 的角色,但自認淡薄名利、不想爭權奪利,只想好好做事的他,覺得誰當 Team Lead 都一樣,所以並沒有把我當時的建議當回事。如今,在這個依然沒有 Team Lead 的新創公司內,他遇到了團隊合作中無法跨越的磨合障礙

        這個新團隊的組成各有各的來源與背景,大家帶來的做事方式、文化、習慣與見解各不相同。而其中兩人洽巧是同氣連枝的夫妻檔,難以溝通和差異頗大的做事方式讓他配合起來苦不堪言。

        對原本堅信透過實事求是、良好的溝通就能達成共識的他,我直白的說:「我的經驗告訴我,溝通不是萬能。你們需要的,就是一個拍板定案的 Team Lead 。

        「但是公司 Manager 說:Team Lead 要等第一階段上線後,看誰的表現好,再決定由誰擔任。

        真是大錯特錯!

        已經陷入群龍無首局面這樣糟糕的團隊,管理階層還想把問題拖到上線後才處理?這樣的思維,代表管理層把 Team Lead 這個位置當作一個 promote 的獎勵手段。無功不受祿,對於才剛成立尚未有戰功的新團隊,用這樣的思維當然會找不到 Team Lead 的合適人選!這時間點該立即找到的人選,該是願意挺身而出為成敗負全責的人擔任!也只有願意替成敗負全責的人,才有拍板定案的權力!

        這時候的 Team Lead ,未必他的薪水就該拿的比其他人多,單純只是承擔更多的責任和壓力,所以不必用 promote 的眼光看待這個職位,這需要事先跟其他團隊人員溝通清楚,避免破壞團隊合諧的誤會。

        為何在這當下,我不贊成繼續採用『溝通』這個方法?

        前同事最初其實是為了一個程式開發的方法來徵詢我的建議,因為現在團隊內出現的異議就是必須在執行速度快或是易於維護支援做個取捨。80%的狀況我都是以後者為重,因為大多數的應用,事實上速度根本就沒有那麼重要。但是一次耗費過多時間的維護支援,造成的停業損失可能一次就把速度上的獲利優勢連本帶利全部吐出來。

        相信『良好溝通可以解決爭議』的前同事,為了一個我看來極端雞毛蒜皮的小事,花了好幾天做 POC 收集數據和網路資訊想要在團隊中證明自己的論點。新創公司最珍貴的資源:時間。就這樣奢侈地流失掉了

        曾經也相信過『良好溝通可以解決爭議』的我,阻止他繼續浪費時間:
        「這件事的真相本來就是同時有好有壞,你花再多時間去證明你說的優點真的存在,也沒辦法否定他說的缺點不存在。僵持不下的根本原因,在於你們兩人『內心』中對這些優點和缺點的配重不同!大家都承認這些優缺點並存,但是在你的內心,兩者的重要性比重是 3:7,對方則是看作 7:3,這才是問題的癥結。這就是所謂的『成見』,你收集再多資料也沒用。

        『成見』是來自於當事者過去經歷過的『事實』所堆積,唯一要能打破成見,也只能以毒攻毒,依賴的也是『新的親身經歷的事實』

        所以,不斷地在空中噴口水比劃是無法產生事實,只有先做出決定、執行、才能產生新的事實!而尷尬的就是:誰來做出這個決定?因為這個團隊,沒有 Team Lead

        「你知道其他人為何不願意配合你覺得明明就比較好的方式去做事情嗎?因為你改變他們的習慣,卻又不替他們負責!這跟只出一張嘴指東道西有何不同?他們用熟悉的老方法,東西可以做出來,雖然很醜又很花力氣,新技術又快又漂亮但沒經驗,但是遇到沒見過的障礙不知如何解決時,誰負責?如果你只給建議卻不負責,當然他們肯定不配合你!

        「但上頭又不指定 Team Lead,我又不是 Team Lead,事情也不是我說了算,為何要負責?這應該是要經過大家都認同的決定⋯⋯。

        不多說,到此我相信這個團隊內耗空轉的問題已經很明顯了。

        決定不論好或不好,都要有下一步才會前進。擔任 TL 的角色並不代表他所做的決定都是明智且正確的,他只是不斷地勇於承擔,快速下決定、修正、再決定、修正,並且能以同理心支持和理解團隊。這是我自己擔任 Team Lead 之後的心得:溝通雖然重要,但遠比不上承擔責任重要

        溝通不見得能讓事情前進(請參考我國立法院),但承擔責任肯定會!

        送行前,我要他好好想一個問題:

        「你說不論誰當 TL 你都無所謂。那如果這個 Team 最後決定要用的技術和做事方式和你理想不同,你願意開開心心地選擇入境隨俗融入嗎?還是會鬱鬱寡歡,不能接受?如果你是後者,代表你無法忍受事情發展跟你想要的不同,那憑什麼說『誰當 TL 都無所謂』?憑什麼把決定權交給別人?交給你所謂的『大家的共識』?

        因為知道自己是這樣的人,所以當初現在這間公司找上我的時候,擔任 Team Lead 是我加入的必要條件。

        在電梯門口,我再次鼓吹前同事到管理層面前,主動毛遂自薦去擔任 Team Lead 一職。

在強調一次:
溝通不見得能讓事情前進,但承擔責任肯定會! 

2013年10月6日 星期日

Yahoo 2013 Tech Conference 與會小記

        這次榮幸獲 Yahoo HR 的安排參加這場 2013 Tech Conference。看到活動邀請函上寫著『無限供應的自助餐點』,抱著白吃白喝看熱鬧的心情,在 9 / 12 日當天晚上,來到了南港軟體園區的雅虎辦公室。

2013年8月24日 星期六

你這是負責任或推責任?談『系統程式交接』


        我最感到幸運的,是這一路上遇到幾個願意帶我的師傅。其中一個待我相當嚴苛(當時我常常心裡有很多抗拒),然而現在回想起來,卻也從他身上學到、領悟許多。其中他讓我體悟到影響至深、最重要的一點,不是技術,而是某些做事態度,尤其是『程式交接』這件事

2013年6月28日 星期五

JD ( Job Description ) 是什麼?能吃嗎?


        JD,Job Description ,是應徵招募職缺時重要的參考資訊、也是一個公司營運方向的重要體現。讓我們來看個我手上最近拿到的範例:

1.       BU Team Lead
  a.      Product technical owner
  b.      Provide technical support to project/incident
  c.      Provide mentorship and guidance to fellow team members
  d.      Assist to manage/review release process
2.       Technical Architect
  a.      Review project/incident design by request
  b.      Code review by request
  c.      Establish the code standard
3.       Production Support
  a.      Analyze sticky incident
  b.      Support/guide the team for urgent case

        然而以上條列式的敘述,在上層和下層的解讀卻截然不同。上層開出一個職位,對這個職位所能發揮的功能是有所期望的,所寫下的描述是希望擔任這個位置的人『至少』能做到的事。而下層的人面對這樣的工作描述,則認為:沒有寫在上面以外的部分,不屬於我的權責範圍,與我無關。

        當一個公司大部分的員工,心態都屬於後者,這間公司就已經僵化,很難有機會繼續進化。因為任何的『創新』或『改變』的項目,一定都不可能被寫在現任員工所持有的那份 JD 文件之內,後者的力量大了,所有的改變和推行就很難發生,有志難伸者只好陸續求去,留下的,只有比例越佔越高的 JD 保命 ( save ass ) 的擁護者。而這間公司的發展前途越趨暗淡,是可以被預料的。

        今年四月,我剛離開一個情感寄託很深、工作三年半的公司。其中一個原因跟 JD-Driven 的管理與工作文化有關。

        來到新的工作環境,帶領一個剛成軍 1Q 的工作團隊,我相當看好其中一個團員的潛力,希望能 promote 他來接手我的權責。在徵詢他的意願的過程中,他提到:「我需要知道這個 "Assistant" Team Lead,到底該做什麼?

        「你該做的,就是我所做的所有事情。」心中並沒有明確 JD 想法的我,簡單回答。

        「那我必須知道,你做的所有事情包含哪些?」這位同仁又追問。

        突然間,這個問題讓我當下仔細思考 JD 存在的意義。

        讓我們回頭來看看整件事的因果關係:

        老闆和股東為何要成立一間『營利』商業公司的原因?肯定是為了『賺錢、贏得市場』,絕不是為了燒錢取暖。所以,CEO 的 JD 是什麼?讓公司成功獲利!

        CEO 為了達成這個目標,他心中有策略,根據心中的策略,他判斷需要什麼樣能力的幫手,於是創造了第二批的 JD(s),例如 PM ( 專案經理 )、HR ( 人力資源主管 )、RD ( 研發主管 ) …etc。而這時候的第二批 JD(s) 會以功能導向的描述為主,而最初衷的原始目標:『讓公司獲利』,這項目經常會在這階段的 JD 文件中被抹去

        而第二批 JD 所招募進來的人,會為了讓自己做事方便、加快效率,產生第三批 JD(s),這之後同樣也都只有功能性描述。但絕不能忘記,這所有 JD(s) 的源頭都來自最原始的目標:讓公司成功獲利

        然而,常常我們看著手上 JD 文件的描述,忘了這一切的因果,而 JD 反而成為與公司初衷矛盾與對抗的產物。因為,市場可能會改變,CEO 可能會誤判或是需要調整策略,原來的功能性描述自然可能就不再適用

        但是若我們抓緊原本 JD 的初衷,這些條文式的規範就不會是困擾和問題。

        因此,當下我是這樣回答同仁他的疑惑:
        我們的目標就是讓手上這個產品推上線,並且成功地在市場上成功獲利。雖然這件事跟公司所有人都有關,但是你把這個當做是你自己的責任,而你手邊剛好有幾個幫手 ( Team members ) 能從旁協助你,在這樣的前提下,你覺得你必須採取什麼樣的行動來達成這個目標,那些行動就是你該做的事情

        的確,我會決定必須要從中 promote 一個 assistant team lead,也是因為要達到上述目標而認為這是自己必須採取的行動,並不是因為任何 JD 告訴我說應該要培訓或是 promote 某人。

        看這位同仁點點頭,我想他應該是理解我所說的。事後證明,他也的確表現得非常不錯,高於我的預期。

        所以,各位讀者,你手上那份 JD 的文件是什麼?能拿來吃嗎?不如丟掉這份包袱,把公司的願景和目標當做你自己的 JD 吧! 

2013年6月15日 星期六

架構師 vs 創業者

        今年初,我以系統架構師的頭銜離開了前公司,來到了一個才 start-up 三個月左右的新創公司當 Team Lead,帶著五、六個人的開發團隊力挽狂瀾、力保三個月後能讓該公司的新創產品能順利上線。

        這段時間我算是忙到昏天暗地,每天工作時間超過十二小時,甚至還有做到清晨四點下班,然後早上十點又繼續上班。可以說沒什麼體力心力寫部落格,任其荒廢了好一段時間。

        這段時間,我不斷受到內心或是外在所謂『架構師』和『創業家』角色之間的拉扯。但想想自己當初跳脫上一間公司的角色來到這裡,諸多原因之一,就是我想認真學習如何成為一個『創業者』!

        但是,架構師和創業家在思維上是很衝突的。

2013年4月9日 星期二

一個打十個的葉問很強,但我要殺很大的瑤瑤!


        傳說中葉師傅是個以一打十的功夫英雄、深居簡出,是個頂尖的人才

        求才若渴的老闆,三顧茅廬尋訪多年、重金禮聘,花費 9999K 終於請出葉師傅到我們公司上班。老闆欣喜若狂,認為嘔心瀝血總算讓這麼一等一的高手出任敝公司職務,公司前途光明,發展不可限量。

        「這位老闆,先說好,沒有以一對十的場面我可是不幹的。」葉師傅醜話說在前頭。

2013年3月14日 星期四

『東西沒壞就不要修』?淺談軟體的技術破產



        只要在軟體開發圈子混一段時間,尤其已經有系統 run 在 production 環境上,十之八九會聽到這句廣為流傳的經驗談:「東西沒壞就不要修。

        這句話,常常被反對重構(refactoring)者掛在嘴上。

2013年2月5日 星期二

軟體開發適合 BottomUp 或 TopDown?

        在進行軟體開發的系統設計,有兩種迥然不同的思維模式,一種是由下到上的 BottomUp,也就像是蓋房子一樣,由地基規劃打底開始,逐步往上;另一種是由上至下的 TopDown,由需求主導,逐步向底層延伸。甚至,微軟曾經為了不得罪兩邊的支持者,提出了折衷的 MiddleOut 從中間往兩邊延展的模式,但落得兩邊都不討好的下場,所以這個含糊其辭的異教論我就不在此討論了。


        十年前當 XML base 的 WebService 初試啼聲,彷若帶來一道曙光,是 IT 界整合的創世救星的年代,那時候各種系統整合的名詞蜂擁而出,開始有 SOA(Service-Oriented Architecture:服務導向架構)、 BPM(Business Process Management)或是 ESB(Enterprise Service Bus:企業服務匯流)⋯⋯等令人眼花繚亂的名詞,當年我負責協助金融業導入相關技術產品與專案,就遇到究竟該 TopDown or BottomUp 僵持不下的爭論。

2013年1月9日 星期三

『微軟私有雲建置及管理規劃營』課後報告



        當單機軟體服務已經幾乎被淘汰,網路服務已經成為顯學,所有的應用幾乎都要求 web 化,網路應用服務供應商如何自己建置,或找到穩定、經濟、合用的伺服器 Hosting 環境,已經成為燃眉之急的要務。
       雲端這個詞正夯,有人認為這只是個行銷名詞,跟過去網業虛擬主機或是主機代管並無差異。為了釐清這樣的誤解,微軟替現在的『雲端運算』做了如下的定義:虛擬化可攜性

關於 SQL timeout 的錯誤判別

        今天看到網路上一篇討論 SQL Timeout 原因的探討文章。         由於那篇文章的結論和我過去經驗完全不同,所以我懷疑是不是我過去仰賴的長期判斷經驗有誤,特別寫了個 TestCase 作為比較。         首先我先引用該文章作為調查起點的 Ex...