Database 選擇的 cheatsheet，太棒了！

關於 SQL timeout 的錯誤判別

        今天看到網路上一篇討論 SQL Timeout 原因的探討文章。

        由於那篇文章的結論和我過去經驗完全不同，所以我懷疑是不是我過去仰賴的長期判斷經驗有誤，特別寫了個 TestCase 作為比較。

        首先我先引用該文章作為調查起點的 Exception 內容：

        

阿里雙十一的高頻交易分享

 

        即將發生的網路電商的大事件，莫過於越來越接近的大陸雙十一。屢創高峰的雙十一購物節，究竟阿里巴巴是怎麼在技術上克服這種巨量湧入的交易量呢？

        前陣子到中國東北剛好因為業務合作需要而結識了一位在杭州擔任阿里巴巴架構師的高手。晚餐大家在酒醉耳酣之際，我們聊起這件事，做經驗交流。 

我看 Java 的過去與未來

        很多人總是拿 Java vs .NET，但這太容易引戰了，所以這邊我不要用兩相比較的方式，單純從『非技術』的『商業觀點』談論我對 Java 的看法。

        我本身以微軟相關技術為主，但偶而也會寫寫 Java，因為程式語言就是工具，合適的時候就拿來用一用，更何況從 C# 轉 Java 遠比 Java 轉 C# 簡單得多，因為 C# 的語言特性較複雜。

        我自己會寫 Java 的幾個機會是：寫 Android App、寫 GAE app、寫公司產品 Java 版本的 SDK，不算是用在很核心的地方。

聲明：以下看法單純從本人過去工作經驗的觀點做分享，難免偏頗絕非全貌，請自行斟酌真實性。

[HACKING]宏碁江蕙門票銷售網分析

        緣起：原本我受朋友之託，要協助搶購將會追加的十場的演唱會門票，所以稍稍研究了一下該網站，想說能不能利用自己的專長之便偷點雞，確保自己開賣當日可以穩穩當當地不出差錯把票入手（朋友原本說每張多加 NT$1,000 跟我轉購呢，看在四個孩子的份上...）。

        原本這篇文章是打算在搶票成功後第一時間公開，打算用諾曼地搶灘的勝利之姿洋洋灑灑解說，結果過了數日後整件事被我拋到雲霄（我不懂台語，不聽台語歌，所以江蕙對我而言無意義）。

        開賣當天週日我就帶著全家到金山上泡天籟溫泉，當中午我躺在室外湯享受山海之色之際，手機 LINE 的訊息不斷傳來：「搶到票沒？」

        我心裡暗幹一聲，然後下午的泡湯過程，我心中的陰霾與失落慢慢滋生...。

「鍾馗抓鬼系列」log4net 檔案清空之謎

        身為多年 log4net 忠實用戶，最近接獲客戶報案，說 Rolling File Appender 會在跨日一過午夜就將 log 檔案內容清除，只留下 0 byte 的空殼。對方採用我曾在 blog 推薦的多年調製而成的家傳祕方的組態設定（log4net.config），竟然會遇到如此前所未聞的離奇事件！？

        上網 google 搜尋是否有他人遇到類似狀況，卻毫無線索。太陽底下無鮮事，全天下沒有別人遇到的事情，通常也不該發生在我周遭，畢竟我樂透從沒中過（不過我也都不買，這樣要中獎對老天爺來說應該是有難度），但是客戶現場截圖又不得不讓我閉嘴，不敢過度質疑：

百人 Pitch Demo Show 與會後記

        『十二小時百人 PITCH X STARTUP馬拉松』，是個鼓勵創業人腳踏實地驗證自己想法的創新活動。因緣際會，某日晚上受帶衰胖胖之邀，跟其中一個參賽團隊『鋼鐵人實作聯盟』的成員聚會交流，順便交換彼此對這個 Business Model 的想法與回饋。

        而透過該團隊主要的 Coordinator - Sandy 的介紹，我才知道有這麼一個活動，而該週六就恰巧是馬拉松活動最後的決賽場！

        決賽場的地點是在台灣微軟，那地點我很熟，依照慣例，知道現場一定會有免費的糕點和無限暢飲的冷飲機，應該可以省去一頓午餐費用（創業維艱、什麼都要省啊），於是打定主意前往！

軟體成功的 3 / 7 法則

        今年三月底，為了挽救公司的新產品，我臨危受命飛往馬來西雅。也是第一次我才一下飛機，透過越洋國際電話，就決定放生一位團隊同事。

        下令放生之前，我寫了封信，跟團隊談談我心中認為『成功的系統』的關鍵要素：

失控的加速

        這一年多來，帶著團隊參與一間新創公司的產品開發，近一年的努力成果終於推向市場營運後，才幾個月不到，結束了。

        如今還在收拾一些殘局的過程，看著這潮起潮落，我有些領悟。

        當然結束營運背後有諸多複雜的原因混雜，有些也不是我這種技術層級的黑手工頭可以知道的。但是針對 IT 開發這塊，我有個代價挺高的領悟：

        產品的系統特性，應交給市場幫你決定，而不是交給系統架構師來決定。

[連載]新創公司歷險記-2：搬開技術絆腳石、加速執行

        繼上次才寫到開頭的歷險記，第一週我先跟團隊達成『工作完成』定義的共識，避免錯誤的資訊混淆對實際狀況的掌握與判斷。

        但是，即使掌握正確的專案進度，避免浮報無知的樂觀，卻沒辦法讓實際的開發速度加快。採用了每週一輪的 spring，前兩週都無法達成目標，以當時的 deadline 來看，團隊的開發效率若沒有改善， 肯定無法對上有所交代。

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

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

        符合“簡易”的這個特徵有兩個條件：

1. 不用額外安裝任何第三方軟件或工具，只使用作業系統內建的基本工具即可。
2. 與系統特性無關，不需要先理解遇到麻煩的系統任何內部原理與商業邏輯。

        所以任何任何人，都可依照這個 SOP，花個半天時間迅速判斷 80% 以上的網站效能瓶頸點。