Sunday, July 27th, 2008
在約爾大神的文章裡，他老兄把微軟的那票 architect (架構設計師? 104 翻的不是我啊 …) 好好地損了一下，幫他們取了個響亮的綽號：architect astronaut (架構太空人設計師)，順便也好好地損了一下同步 (synchronization) 這個概念。好吧，這裡就有點怪怪的了，微軟並不是唯一押寶在同步上的笨蛋，如果「同步」這個概念不賺錢，為什麼有這麼多攀子要燒錢?
我個人的看法是，「同步檔案」這玩意兒當然不賺錢，它只是一個大布局的基礎棋子罷了，這個布局是為了簡化資訊共享和協力工作的難度。就像下棋吧，直砍直殺未必是好，有時得要繞個彎設個套才能贏。今天的手機了不起只有 VGA 解析度，當然搞不出什麼大風大浪來，但若等到手機都是 XGA 傳輸速度都很猛時才要進場，那就只能揀別人吃剩的了。
其實「同步」這個詞並不精確，它其實就是最近很夯的「雲端運算」的一種附加功能而已。因為資訊都存在網路上，也都在網路上分享操作，當然它會是同步的。好吧，雲端運算是不是又是那票太空人弄出來唬弄普羅大眾的呢? 我個人認為他們還不至於這麼閒。就像約爾問的: 誰會需要同步檔案? 如果這只是一個包套方案中的某一點小小的附加功能，我想也不會有人拒絕使用才對。
無責任評論, 軟體工程 |
Sunday, May 4th, 2008
Joel Spolsky 最近貼了一篇新文章，文章本身是有些亮點，不過最後他對於谷歌和微軟的抱怨大家聽聽就好了，因為選項太明顯，換成你的話，你是要到貴死人不賠命的紐約市去做 bug tracking 的軟體，還是要留在矽谷幫 Google 做有趣的 demo code? 要是我的話我是不會選他的公司的哈哈 …
近幾年幾個朋友學弟有興趣到美國發展，來問我一些事情，我想這些資訊也許還蠻有用的，就來野人獻曝一番啦：
不要在你生活一團糟的時候下這個決定，如果你在台灣沒法活的很好，來美國活的更好的機會和簽樂透大概差不多。我來美國六年得到的結論很簡單：人性不分種族國界都是一樣的。如果你在台灣是受不了公司裡的政治鬥爭，那你來美國會更受不了。
要有家人的支持，已成家有小孩者務必慎重，美國養小孩非常非常非常昂貴。
沒有留美經驗的人，或甚至沒有留學經驗的人，務必先到各大 BBS 留學板去取經，假設你下個月就要出國，你要準備什麼，也看看過來學長的經驗談，再決定是否要來美工作。
英文必須有可以「fingerpointing in a professional and elegant fashion both verbally and on paper」的程度，和你 GRE 或托福的成績並沒有關係，事實上小弟兩者都沒考到目前為止混的還頗開心，我也看過舊 GRE 2300 舊托福 650 的強者英文爛到我都替他害臊。
美國的面試一般會有 phone screening (一到兩次) 及 in-person interview (一到兩次)，按慣例公司必須負責 in-person interview 的「所有」travel expense。不付的公司，沒有必要去。
不可以假設公司會幫你辦移民，即便他們幫你申請了工作簽證。
美國的 recruiter 都非常的能言善道，不過呢，若找你的是未上市公司，要份財報和財務預測來看看，不給就不要去了，這是 common practice 沒什麼好害鲝的。start-up 公司的財報和財務預測要找懂行的人幫忙看。技術好的公司未必會成功，很多時候技術往往不是主要的因素，財報只是幫助你理解公司是否有本事活過明後年，好好活著會按時發薪水的公司對你才是真的，其他都是假的。
美國一般算年薪，把年薪的數字乘以 20 大約就是你在台北或新竹花起錢來的感覺，唯一不同的是美國某些地方的房子貴到一個不行，例如矽谷、紐約、洛杉磯、波士頓這些地方，隨便一間破房子也許就要你六七十甚至百萬美金。所以你拿到的 offer 好不好夠不夠，和你所居住的地方有很大的關係。
美國的工作環境未必會比台灣好，我選美國的原因是因為在台灣做純軟體很難混，做 SI 我又沒興趣，所以才來美國闖看看。每個人有每個人自己的看法和理由，如果你的理由可以說服自己就衝吧 [...]
無責任評論, 美國生活 |
Sunday, January 27th, 2008
搞軟體的常常遇到的問題就是，程式寫好之後，客戶嫌它跑的慢，所以不爽付錢。爽，是一件很重要的事情，所以師程工多半都會被要求無論如何要調到客戶爽為止。不過說真的，效能調校是件很有趣的事情，小弟來分享一些曾遇過的趣事好了。
關於時間方面的效能調校大致上可以分成兩種：縮短執行的時間，或是縮短等待的時間。前者多半出現在後台用的程式，例如小弟以前做過的某個銀行專案，一個批次跑下來要十九個半小時，基本上這等於叫客戶不要開門做生意 經過一個多月的調教校，批次執行時間變成十九分鐘。這麼歡樂的情形也許不常見，不過我倒是從中學到不少有趣的東西：
資料庫的 table design 非常重要，我所做過大部份的專案都是以客戶現有的資料結構下去設計，但客戶的資料結構往往不符合效能最佳化的需求。在一開始設計時就應找出最常用或最關鍵的 query path，針對這個 path 下去設計才對。
Stored procedure 的設計必須把握「先細篩後粗篩」的原則，cursor 指向的 data set 越小，跑起來越快。像上面的例子中，我只是把兩個 select 的順序換一下，時間就從十九個半小時變成六小時。
注意一下 team member 的實際能力，雖然這有些傷感情或 micro-management 的嫌疑，不過卻太常見了。一個很有效的鑑別方式是和你的隊友聊天，看看他打算用什麼方法解決問題，若是沒有方法，或是方法的執行上實在不怎麼樣，那就該想想 plan B 了。
擴充性迷思：客戶通常會要求高於他們業務量所需的規格以備未來的擴充，或是要求要有種種神奇的擴充能力。如何委婉的讓他們知道有多少錢玩多大的車是很重要的事情，很多時候系統只打算用五年卻做了十年的規劃，這樣做起來累驗收也累，爽的只有 sales。
注意客戶的真實需求：很多時候程式跑的慢並不是技術上有問題，而是管理面或協調面上出紕漏。比方說奧客亂拗碰上軟腳 sales PM，或是客戶自己都搞不清楚自己要什麼，或是客戶自己山頭林立一人一把號各吹各的調。這種情形下除了等五年後摩爾定律打敗客戶需求之外，找個很會喬夠力喬的高層才是明智之舉。
很多學校都灌輸「演算法改進會優於程式本身改進」這個概念，不過呢，請務必確認您的隊友都了解這個原則是基於「程式本身已經寫的很好」的假設。我看過不少同行花好多好多的時間想要去生出一個更好更棒的演算法，卻沒有去檢查原有程式的品質。爛程式可以很有效地搞砸好的演算法！
如果 team 很大，程式慢就幾乎是必然的，因為程式往往會遷就組織架構而做許多不必要的取捨，例如過度模組化或不必要的流程。這時候通常我們會需要一點來自上層的助力和自己的勇氣才行。
縮短等待時間一般牽扯到的問題反而都不是技術面的，除非一開始設計就很爛，或是很幸運的遇到網路基礎架構很爛的客戶，不然很少會需要什麼技術面的調整。大部份的調整都是屬於心理層面的，所謂 perceptual performance 的東西。比方說，跑一個報表產生的程式，50 頁用了 5 分鐘，客人嫌太慢等很久，放了一個 dialog 上面跑個 progress bar 外加一堆文字閃來閃去顯示報表產生的步驟和進度，50 頁共用了 7 分鐘，客人反而很滿意覺得程式很讚跑的很快 訣竅很簡單：UI 有在動不會卡住，客人的爽度一般而言比較高。
此外，像拙文記憶體用量的迷思中所寫的現象，雖然與縮短等待時間沒關係，但其實也是 perceptual performance 的另一種表現形式。這種心理層面的效能要怎麼調，得靠 usability 方面做好功課，不然就得和客人拉關係哈啦來補補課學經驗囉。
技術文章, 無責任評論, 狀況排解, 軟體工程 |
Monday, September 3rd, 2007
自從 Web 發明以來，許多人都看到了它發展的潛力，特別是在 Enterprise Applicaiton 這塊大餅。對於 Enterprise App 來講，Web-based 的主要優勢在於 deployment and patch，因為 IT 不需要一台台機器安裝。而且在 PC 上安裝愈少的程式，代表這部 PC 穩定運轉的機率愈高，而 PC 本身所需的軟硬體規格要求也愈低。
但是 Web-based app 也有幾個主要的天險：頻寬、人機界面、報表列印，以及安控。近年來 AJAX 等 dynamic web page 技術流行的一個很重要的原因是它可以有效降低對於頻寬的需求，這對於網路基礎架構不佳，或是位於頻寬費用高昂地區的公司有很大的吸引力。報表列印目前我看到的成功範例多半是 Word 或 PDF 套表，這暫且不提。安控的部份經過十多年來的生聚教訓，大部份的 SI 廠商都知道要如何做了 (這個，知道和做到還是有些細微的差距，這差距有多大，通常是和投入的資源有關，這就不在本文的探討範圍之內了)。
人機界面為何說是一個天險呢？我個人認為 Web app UI 難做的地方有三個：Javascript、browser compatibility/limitation、以及 lack of UI elements。Javascript 是一個非常鬆散的東西，而且主流的 browser 都是用 intepreter 來跑它，因此在反應速度上真的是很慘。這樣的例子隨便抓都一大把，像 Siebel 那個龜到不行的 portal 就是典型的負面教材。AJAX [...]
技術文章, 無責任評論 |
Sunday, July 8th, 2007
由於老年痴呆的關係，詳細時間有點記不得了，但大約是在 VB 5.0 的時代，UI 的開發有一股新興的潮流崛起，我們稱它為「內嵌式 HTML」技術。顧名思義，就是利用 HTML 來當成 desktop application 的 UI。會促使人們這麼做的理由，我個人可以想到的是
It feels cool!
i18n 的問題，用 HTML 來做的話容易的多
可以做出非常豐富的 look-and-feel，不再受制於 Windows Control
可以有限度地將 presentation 與 business logic 分開
一般最流行的做法是在程式中內嵌 Internet Explorer (利用 IWebBrowser2 COM interface)，這個做法有額外的好處
可以利用現成的 HTTP/HTTPS 來穿過防火牆對 backend 傳輸資料
可以克服純 web client 無法做到的事 (e.g. drag-n-drop，printer control)
不過呢，眾所周知，IE 有許多缺點，比如說安全性漏洞 (有沒有上千不清楚，絕對有三位數字)、記憶體用量、javascript engine 的錯誤處理很難搞等等，但它的優點往往會讓程式開發商不得不選擇它。除此之外，IE (或我該說，Microsoft) 對於 CSS 的支援興趣缺缺 (因為它不是 XML-based)，導致許多 UI 效果都必須使用 javascript 或直接 [...]
Windows, 技術文章, 無責任評論 |
Thursday, July 5th, 2007
話說美好的 90 年代，只要學會 GW-BASIC 或 dBASE III，就算是電腦高手了，那真是令人懷念的時光啊 :p 那時候 80×25 的終端機螢幕，應用程式的 UI 只要會動就好，使用者必須自己想辦法搞懂要怎麼樣叫出什麼功能，真是程式員的天堂。是的，你若不知道按 / 就可叫出 Lotus 1-2-3 的選單，那肯定是你學藝不精，不會有人說是 Lotus 的程式寫的不好。
很可惜的是，這種好光景並沒有持續太久，事實上它也不可能持續太久，因為這樣的 UI 先天有許多缺陷
它是給專家用的，專家 = 少數買主 = 市場小，這個絕對會被股市唾棄
它有鍵盤這個天險，Baby boom 或 Echo boom 年代的人鍵盤熟練度不高
賣相不好，不夠親善 … 族繁不及備載 …
軟體業要擴張，所以軟體一定要想辦法讓普羅大眾都來買，都來使用，也因此圖形介面是必然的趨勢，滑鼠的發明以及 processor power 的進步使得這個必然終於開花結果。商業競爭下最後是微軟 Windows 幾乎主宰 PC 市場，過程我們宅男師程工不研究，對我們來講怎麼寫賣的出去的程式才是最重要的。Windows 的 look-and-feel 雖然逐漸演變 (3.1 -> 95 -> XP -> Vista)，不過了不起 (或是沒進步) 的是，你還是可以用 Windows 95 [...]
Windows, 技術文章, 無責任評論 |
Wednesday, January 10th, 2007
最近的新科報導 列出了 2007 年富比士百大「best to work for」的公司 (簡稱：「爽」公司)。IT 相關的有哪些咧？好奇的我就列一些出來看看：
1 Google (新進榜，直接拿冠軍)
6 Network Appliance (去年 27，上升 21)
11 Cisco Systems (去年 25，上升 14)
14 Qualcomm (去年 23，上升 9)
31 Adobe Systems (新進榜)
33 Intuit (去年 43，上升 10)
44 Yahoo (去年 73，上升 29)
50 Microsoft (去年 42，下降 8 )
82 CDW (去年 34，下降 48)
87 Texas Instruments (去年 83，下降 4)
100 Stanley (新進榜)
落榜名單
SAS Institute (去年 30)
Autodesk [...]
無責任評論, 美國生活 |