2005-11-14

There are my some opinions about the case

關於這個「接案」的過程到結束,有一些自己的做法想要講清楚,算是 show my rules 系列之一吧。

首先我想說的是 --我喜歡賺錢,也很愛錢。

從網際網路興起那時的公司e化風到現在,怎麼專寫網站的我沒接過幾個case,反而都在企業內部工作,沒有去賺那大筆大筆的鈔票呢?因為我知道跟業主溝通很麻煩,而我討厭麻煩事,如果今天我是個sale 那麼這是我的本業,我會樂於進行這樣的動作,可惜我不是,所以總在外部成本最小的狀況下才接case,比方說有默契的art 找我幫忙coding,或者是熟識我習性並信任我朋友負責網站建置業務之類的狀況下我才接,當然,這樣的報酬就會較少,我也會自動的降低價格,反應彼此省下的「溝通成本」,$$我很愛,只是沒愛到願意承擔麻煩。

這個由學長主動發包案子,我以為符合以上所言,加上彼此私下情誼不錯,又都是技術背景出身,因此告知他不是一般接case 的考量後,就開始進行作業,沒簽合約、沒收訂金。

教訓一:business 就是business

學長在業主的角色扮演的很好,而我的演技就差了,說實在的並沒有意識到我在進行商業活動,記得第二次去學長那請他挑選網站設計樣態與色調的時候,學長說我present 的不好時,我回應本人不是業務的當下,就應該了解對方的暗示了,原來對他而言這就是business,也難怪後來詢問學長建置意見時,他常不予回應,落差早在當時就種下,只是我沒有意會到而已。

曾老說過「要學會公私分明」,還記得一年級的時候接所上網站,那時候的我就是用態度去處理,但讓我感受到自己不夠合群,對我來說寫code是種工作,領了助學金更該當工作處理,可惜狀況反應不良只好調整,把公領域便成私領域,不要有過多的堅持。

研一的情況是以感受去體會到的,而這次接案我有明白表示,這個case 是當作私領域在處理,因為彼此的情誼與信任才為之的感受,沒有被感受到嗎?這麼明白的表示,不會被當作價格談判中的手段吧?

教訓二:不要以自己認知到的background 去做過多的揣測

直到今天拒絕案子繼續的對話過程中,我才了解對方對於網站建置這回事並不了解,網站承包這件事情跟網路系統配置是不同的,網站成立的目的與想要傳遞、呈現的目標是業主給的,對於企業目標並不會有人比業主清楚,今天若業主並無建置計畫,那麼sale 當然要畫大餅提升業主意願,但若事業主要建置,那麼便是業主把所期待的效果告知承包人員,由承包人員實現,這跟網路系統配置是不同的,同為資管人也都有同質性高的業界經驗,我真沒想到會有這樣的落差。

教訓三:消弭落差的溝通很重要

這將近一個月的打樣過程中,不斷的提出一些問題,不過每次對方的回信總是冒出新問題或無法理解的反應,我總認為還不到系統分析與程式介入的階段,於是沒有繼續追問下去,今天才了解到對方並沒有想要回答問題,只想提出問題要我回答,真想用對補習班學員灌輸的觀念回答,程式沒有做不到的只有不支援的,你要我用mail function 去做客戶聯絡公司的動作,當然沒問題,但你的server 是否有mail service 必須讓我了解,你不回答我,我該怎麼設計?你的首頁menu有九個產品分類,你要我「單向鏈結」,用這麼一個專業用詞,解釋起來卻不是這行業的通用意義,讓我怎麼去理解你的要求,當我提出相關問題時,又只要我將網站結構讓你清楚,我不知道這樣的溝通與互動該怎麼繼續進行這案子,總是要我跑到貴公司去會有幫助嗎?事前的溝通準備與文件化才能確保作品呈現不會具有落差呀。

或許是我之前不夠堅持,對於討論的不足沒有持續追蹤。


總之,事情已經算是結束,以後我會更加注意。

8 則留言:

Peggy Shih 提到...

我以為你的貓要去就業了,什麼FIND A JOB...@_@

匿名 提到...

我的第一個反應是好笑.

然後才是自我檢討, 最近似乎對於"識人"這件事情信心過度了.

這個 case 雖然是從實際的需求產生的, 但從一開始就我就沒有打算做出"完美"的東西, 就長程的計畫來看, 如果一切順利, 這個 site 大概生命週期只會有一年左右。從你過去的"產品"來看, 是有程式寫作的能力, 但可能也因為最初 demo 的網站讓我過分高估這個能力。如果你還有印象, 第一次我所說的"自由發揮", "隨便"所表達的意思, 用白話來說, 只要做的出來, 可以幫我省下一些時間, 就是做多爛我都會接受.但是實際的結果, 卻是搞了快一個月連一個頁面會長什麼樣子都還搞不清楚,更不用說網頁會如何呈現了。

網站建置? 對我來說是快十年前在搞的東西, 第一個商業作品是台灣Philips的人事招募系統, 架設在SGI的機器上, 用的 Engine 是Netscape Server,用的語言是"Server Side JavaScript",一手完成。沒聽過? 正常, 因為這是最早期的 Web Scripting 語言, 雖然後來的發展並不怎樣, 而且還需要每次變更都必須重新編譯,但仍比這之前用C語言寫WebBBS(CGI程式)來的容易。我的確沒有領導或參與小型網站建置專案的經驗,也沒有用PHP完成任何一個專案的案例。因為在Delieium(現在叫Agenda, 你可以看看他的背景, 在去想你能怎麼去批評), 接案的最小單位是"百萬",用的語言是ASP、Java或是Broadvision (JSP,不同於Java),因為需要COM+、EJB這些東西來處理比較複雜的商業邏輯。這不是貶低PHP的能耐,而是如果以PHP做Web層, AP層需要的Programmiing技能大概相類於在SSJS/ASP方案上寫NSAPI/ISAPI程式,這比操作COM和EJB需要更多的程式技能。而這種人太少了。

在這個案子成立之後,我期望第一個會看到的是草樣不管是電腦文件或是手稿,至少能說明這個網頁看起來會是什麼樣子,有那些功能(功能區塊), 可以如何操作它,但是在經過將近一個月之後,還停在所謂的"打樣", 連個鬼影子都沒看到。什麼時候要進SA? 在接案的時候就要開始考量了,沒做過PM不怪你,作為Programmer而言,什麼樣的功能要用什麼方法花多少時間完成,能做不能做,總該有點底吧? 而且前端Logical Design跟畫面設計本來就會有相當的關係,那個先那個後雖然都可以,但是我卻看不到你跟你的artist有任何的交流。為了節省時間外包,反而把自己拖下水。再者,在首頁上丟一個1.8MB的動畫GIF? 動畫GIF不是壞事,壞的是一來花的不像話,顏色有optimize過嗎? 大小有optimize過嗎? 二來是這麼大的東西即便是以T1的頻寬也至少要花上十秒進行傳輸,其他的部件呢? 怎麼看都不像是有經驗的人做出來的東西。HCI的基本原則都無法掌握,更不用去討論其他UI設計或是"對網站建置的了解"了。

溝通的確很重要, 也許有些信漏了, 但對我的結論不重要. 因為"不到SA&D的階段"這種答案已經足夠彰顯"失格"了。網站建置最被重視的外觀與感覺,換言之,連畫面的設計、元件、圖形擺放的位置、操作的流程全都是需要在專案初期就進行分析的。當然, 對於初學者來說, 這比較困難, 但programmer跨不過這一坎, 也只能停留在拼揍程式碼的階段。無法把這些元素整合起來, 包括美工設計和Client Side Script等, 當然無法把整個網站建置當成一個整體的Application來看待。第一次問你"AJAX"而沒有反應的時候, 評價就大幅降低了. 如果你還是不知道, 去google一下, 第一這表示你根本沒能跟上網站建置技術的進步速度, 二來是如果有AJAX的經驗或是對於其概念有所了解, 應該會對於把網站各個元素整合在一個Application的概念下有所體會。

"程式沒有做不到的只有不支援的"這種話我想你還沒有資格說。在第一次確認需求的時候, 我就已經表明這會放在一台Unix Like的機器上, sendmail 是不會缺乏的, 不過就算你是忘了也不會影響結論. php 的 mail function 雖然在 unix 上面是以呼叫sendmail為主, 但可以稍作修改變成以跟 Windows 平台上一樣, 以 smtp 提供, 就算因為某些因素不能修改, 也可以用 mail class 代替, 修改, 甚至整個重寫大概都花不了幾分鐘。這與主機是否提供 mail service 完全不相關. 而這竟然會是一個考量的重點? 或是你根本不知道它能夠這樣運作? 再者, web application 的程式碼本身能夠正常運作, 平台支援有問題也不是這個 case 的責任範圍. 正因為能問出這種問題,我才認為有干涉設計的需要。

而且, 如果連這種程度的問題都必須提出討論, 那表示我初期評估人員接案能力的時候就出錯了.

單向鏈結就更好笑了,第一, 我沒有把這個詞當作一個真正的專業用語, 而是用來描述種解法(原文: "你知道單向鏈結的寫法嗎?", 背景: 資料表設計的討論), hyper link 是一種單向鏈結沒錯, 但是這個詞是出現在討論 schema 的時候. 如果一個 programmer 沒有反應出這指的是 "singly linked lists", 若不是沒有經過任何資料結構的訓練, 就是初學者或是門外漢. 為什麼? 因為前者不會知道這種東西, 而後者則是不曾真的用RDBMS處理樹狀結構. 第二,我沒有用更精確的專有名詞, 這種模型稱為"Adjacency List Model"(鄰接模型或鄰接表列模型),是最簡單最直覺的模型, 當然問題也不少, 其他的模型比較複雜但比較有效率. 不用這個詞的原因是因為這個詞大概在90年代中之後才比較有人用,即使有經過關連式資料庫的訓練, 也不見得聽過這個詞, 更不用說中文翻譯了. 但是任何有資料結構或是演算法基礎的人, 都可以簡單的在RDBMS中實做這種模型. 這是第二個給予負評的地方,因為即使解釋過了你仍然根本不知道那是什麼。

我要你直接過來的原因很簡單, 如果需求不確定, 那就直接進行確認, 如同"打樣"的結果不論到什麼程度, 時間到了就凍結起來, 不論好壞, 需求、設計變更亦然. 跟你對談的同時我在另一方線上對談, 處理另外一個案子(別人的, 金額大約2.5M), 所以隨便找個一個文件給你參考。而且我也沒那麼多時間打字, 如果人來, 還可以教, 但是沒有這個意願, 那就是直接fail掉比較快.

最後, 我自己花了兩個週末的時間把所有東西都做完了, 實際進 coding/debug 的部份不到 20 個小時, 專案的總時間也不超過五個工作天, 包含前後端和所有現有 Content. 原來規格上的東西, 基本上都不缺, 自由縮放(最終版本會改成固定寬度以求最美觀的效果), 繁簡轉換(現成的, 也不過是花幾分鐘套一下程式碼, 不過我讓它改吃session), post-to-mail (最終版本是用 mail class)... etc. 雖然 php 不是我的專長語言, artwork 更不是我的專長. 最花時間的反而是讓 FireFox 和 IE 顯示儘可能近似的畫面(懶得做區分). 不過目前兩套都看過的人, 結論都是一面倒的, 評論的人包括製作 Sony 網站的專業美工(還借了一點東西用). 而因為同時進行畫面設計和Logical Design, 所以進Coding之後速度可以很快, 前端程式大概用了六百行, 其中大概一半用來處理畫面, 功能性程式碼大概才三百行左右, Logical Design清楚的話, 在進coding之前就已經決定了, 該精簡, 該共用的東西不需要在拆解. 所以寫作時間相對就短... 不論是一個人做, 或是一個團隊做. 由於邏輯設計採用單向鏈結的databse schema, 演算效能的問題就在實作層級解決, 三百行裡面大概有1/3在處理這個問題, 主要是資料庫查詢快取的設計. 利用php陣列以名稱索引的特性, 快取實作可以非常精簡. 也不需要實作排序或是二元搜尋法. 上一次我使用快取這個伎倆已經是好幾年前的事情了, udnstars 網站 launch 之前的投票系統, 只能用一台效能不怎麼樣的 PC 卻要求能應付 launch 當日電視轉播產生的效能需求, 包括快取的幾個方法合併起來加上適當的系統調教, 在受壓的狀況下結果就比原來好上數十倍。這個案子的設計是用快取來改善因單向鏈結而來的演算效能問題, 大幅降低DB I/O的需求. 系統上主要也只以 mfs 改善 session 帶來的 disk I/O 負載(並沒有用更高級的序列化+shm, 那可以節省更多記憶體). mail() 改成 mail class 來配合 chroot() 環境以提高安全性。 你認為很麻煩的 crossfade 特效, 並沒有被包含在 php 程式碼當中, 而是拆成獨立的檔案, 這使得整段 JavaScript 程式可以在 Client 端被 cache 住而不用重複傳輸, 這也是一種 optimize (降低輸出量, 節省頻寬)的手法, 這只是"把Web看成一個Application"概念下的結果, 而不是從一堆拼湊出來的程式碼裡產生一個一個網頁的概念.如果你對當代的網站建置有所了解, 應該是很清楚的概念, 不過我認為你的程度還未夠班.

為了提高彈性和安全性(獨立做chroot())而將 mysql 改用較慢 TCP 連線, 但即使如此, 目前的程式碼在1-500 concurrent connection之間, 每頁時間/連線數關係幾乎保持線性(OpenBSD堅實的IP Stack相當有幫助), 在 100 concurrent connections (全部連續傳輸) 仍低於 0.7 秒, 這種壓力在正常的狀況下大概需要數千個 concurrent session 才能產生. 而這個成績是在一台兼任mail server的 P3 667+256MB RAM (w/PHP4)跑出來的. 這已經遠超過我的效能需求. 會產生瓶頸的, 大概只有出口頻寬了. 如果你沒做過效能分析或是進階的壓力測試, 應該也沒辦法搞懂這些數字代表的意義, 去請教你能請教的人, 如果不想懂也沒關係, 因為就我所看到的, 你的程度也只到這樣而已.

沒錯, 我就是願意花這麼多錢去換回我的週末時光, 至少可以節省一些時間, 這個案子在我看來, 即便是初學者的那種拼拼湊湊的做法, 也不過就是就是兩天的 coding 和搬資料的苦工, 沒有技術上的難度, 要的東西也說明過可以自由發揮, 但是接案的人卻連到場確認都沒有意願. 更簡單的來說, 就是程度太差.

不想寫程式, 其中一個原因是我基本上知道我自己的天分到哪裡, 幾萬行的 BBS 程式可以玩, 但是數十萬行的核心程式我只能摸摸弄弄搞點小東西, 像是改寫 system call 之類的, 我沒有 goto 那種專精, 也沒有 torvalds 那種天才, 更沒有 stallman 那種淵博, 現在寫 web 程度也不會比三五年前好多少, 變不出什麼花樣. 十年前就在 oracle 上面玩樹狀結構, 現在還是一樣只是換成mysql. 但是比較起來, 還是比那些連對方背景都沒搞清楚就任意評價的人要好得多("程式設計心理學"裡面恰好提到過關於猜測程式人員背景的例子, 在能力足夠的狀況下猜測對方的背景會有很高的準確率) . 當然, 憑我這點程度, 已經足夠讓我"摸黑"(指黑箱測試, 我稽核過上百個網頁程式大部分是ASP和PHP, JSP和CFM是少數, 黑箱是不看程式原始碼的狀況進行, 通常用在第一次測試)找出大部分的問題, 猜出寫法, 給出改善方式. 這也是我第一次到你 demo 的作品之後, 特別強調需要做輸入驗證的原因, 因為在我看來, 那種問題幾乎是透明的. 而像是透過系統調校或改變程式寫法來改善效能, 或是正確評估軟體對運算資源的需求程度, 只有同時在程式和系統都有一定程度以上的人才可能辦得到.

這次會自己寫, 可能是因為那天跟那些"專業人士"喝了太多的酒, 回來才迷迷糊糊的搞起這個, 但是如果你想要驗證, 我可以讓你看程式碼, 甚至要直接"較量"都沒問題, 不過即使你不服氣, 也改變不了現況, 因為我們根本不在同一層次上. 釋放程式碼就暫時免了, 這東西整理一下, 會賣給另外一家做網路行銷廣告的公司, 當然賣的是方法, 這套東西是當作範例, 畢竟我很少寫php程式(以往只有ASP程式在), 寫了就要物盡其用. 對他們來說, Hosting 平台如果可以改善效能, 就可以減少許多的硬體和維護開支... 這也是為何我轉向SI的原因之一. 能 coding 的人比比皆是, 但是能做出有品質, 能充分發揮系統能力的 code 的人卻少之又少. 小型專案可以隨便, 反正低負載看不出什麼差異, Hosting 平台(和其他一些大型專案)卻需要斤斤計較. 差一點就差很多了, 這是數量級的差異. 但是只會拼湊程式碼的人不可能懂得這些.

為何不叫我學弟幫忙寫? 除了他忙之外, 交了女朋友, 買了新車, 幫他安排了新工作, 我必須他衝刺的時間。更重要的是,他在我這邊工作的時候已經通過我給的考驗,證明他有足夠的能力成為我另一個計畫的"戰友"。這個 case 雖然我自己花了幾天工夫做完了,下一個還是會外包,節省我自己的時間,也順便當作合作對象的考試題目。也因為如此, 實際上我沒有仔細去看報價, 不用花個幾十萬能夠找到一個能用或是能夠訓練的人, 算是便宜了.

可惜,這次是完全失敗的例子。

匿名 提到...

聽說這裡有人討論Web的技術,個人最喜歡討論技術了,剛好無論是J2EE、LAMP(那個P就是PHP啦),還是MS$的ASP到ASP.NET甚至是CGI個人都在Project上用過
不過個人有幾個問題
1.AJAX
 個人實在想不出,一個小公司首頁用這種非同步的網頁技術做什麼,這種東東通常用在mail上,最有名的當然是早期MS$ Exchange上的Web mail和Google的gmail啦,當然啦,有大量資料要在背後存取是可以用的,不過老兄你這樣算不算"老人玩小車"啊.
  不過如果每家公司都願意出”百萬”來做網頁,我們還是要鼓勵的,這個我喜歡.
2.沒用過PHP
沒用過PHP就太可惜了,很多人都以為"商業邏輯"一定要用AP Server或DCOM,這實在是中了SUN和MS$毒太深,你如果知道低層其實就是RPC/DCOM/CORBA這種技術,就知道用語言來分類,顯然是不合適的。
3.SMTP
 現在很多人都知其然而不知其所以然,即然你知道是SMTP,怎麼需要"稍作修改"呢?不要告訴我你的修改是指改IP喔!個人對這種似懂非懂的人,深深不以為然.
"php 的 mail function 雖然在 unix 上面是以呼叫sendmail為主, 但可以稍作修改變成以跟 Windows 平台上一樣" 大錯特錯
4. "1.8MB"在T1要少花上十秒傳輸
這就對了,很多人不會算、或不想算、或跟本不太清楚怎麼算,就要用這種的方法,”至少”,這個方法還不錯,老實說,我很少遇到會算的,不是不懂PHY層,就是不懂AP層,不然就是不懂TCP,不管如何,用"至少"是不會錯的。
5.單向鏈結、黑箱測試....
太多對 也太多錯的地方了,如果全對或全錯就算了,可怕的是有些對有些錯,卻當成對來處理。就像這句話一樣"黑箱是不看程式原始碼的狀況進行, 通常用在第一次測試",要說它對也不是,不對也不是,是不看程式碼啦,但重點不是看不看,而且第一次也很怪,第一次依現有的軟體工程方法,大多第一次是指units或classes的test,第一次有人說黑箱是第一次的...
這種文章,我想起一件事

某天,某軍官送假單到營長面前,
營長看看了,"叫"某軍官打開窗戶,
~*假單直接飛出窗外.

這個某軍官是我同梯的啦.
  

匿名 提到...

1.這不是討論技術, 這是謾罵. 我已經過了拿BBS或Blog來呻吟的年代, 除非閒著無聊. 事主雖然可能有其他的專長, 但很明顯的, 不是這一塊.

2.請參考前後文, 筆伐者不論程度如何, 至少連抓語病都得先參考前後文, 抓不到重點, 僅惹人訕笑, 那麼我可能會覺得連謾罵都嫌無聊. AJAX 並不在這個計畫的考量之內, 而是在這個專案執行之前, 拿來測試對方程度用的一個題目. 當然, 結果是一無所知. 再者如果真的了解 AJAX 的意義所在, 應該要會先提出豐富的前端展現. 大量資料的存取是常見的一種應用, 這點沒錯, 但DOM給出的是什麼? 就連"教科書"都都已經開宗明義寫出"Ajax turns static web pages into interactive applications." 如果資料量是最重要的, 那麼 gOffice 的出現豈非沒有意義? 這只是抓語病而已. 在AJAX這個詞被發明出來之前, 已經有許多人/專案這麼做了, 所以實際上並不是什麼很新鮮的事情, 只是這些先行者基本上都有"將Web的前後端視為整體"的概念.

案子的大小也不是重點, 如果使用了某個含有這種概念的套件, 或是接案者本身就有這種概念, 而手邊經過時間累積出一些一般化的程式碼可以重複使用, 算不是算是用上 AJAX 這種"高級技術"? 這只是一個測試對方程度的題目, 我也沒有預期要使用這樣的概念進行設計, 如果沒有現成的可以兜, 重寫一些 web scripting 和發展一個 JavaScript前端, 前者可能要簡單很多. 我也表示過, 怎麼做, 用什麼樣的技術, 做的好壞沒什麼關係, 只要能省下我一些時間就行了... 除非作品會爛到必須全部重寫.

百萬? 這種走傳統 scripting 路線只需要兩天時間完成的專案, 大概有個五萬、十萬就很了不起了. "兩天"還是一個"沒用過php的人"寫完所需要 code 花掉的時間.

2.我的確沒用 PHP 完成任何一個專案, 因為我碰到過有用 PHP 的專案, 都至少混用兩種以上的語言(例如, 遠端安全掃描-目前由acer租用, TWNIC所使用的二、三層DNS檢測系統), 而且基本上都不會是我操刀. 在我還在搞 coding 的時候 php 的成熟度, 說實話, 並沒有那麼的好. 時至今日, 實作 "Project" (for SSJS, or "Application" for ASP) 仍然稍嫌複雜, 雖然 PHP 的確提供了"更好"的方法(shm & semaphore operation), 但是有能力去使用這些功能的人, 如果沒有對 unix 有一定程度的了解或是沒人帶, 大概也是用不起的.

沒用 PHP 完成任何一個專案雖然可惜, 這個專案的完成算是某種"里程碑", 但是對我來說, 沒有特別值得高興的地方, 只是在程序式語言的經驗當中再加一筆而已.

3.用語言來對"商業邏輯"做區別本來就不適合, 因為商業邏輯跟所使用的語言關係並不大. 原文是: "需要COM+、EJB這些東西來處理比較複雜的商業邏輯。這不是貶低PHP的能耐,而是如果以PHP做Web層, AP層需要的Programmiing技能大概相類於在SSJS/ASP方案上寫NSAPI/ISAPI程式,這比操作COM和EJB需要更多的程式技能。而這種人太少了。" 有些商業邏輯問題可以用 SP 在資料庫處理, 有些可以分解成以頁面為基礎分段進行(需要小心控制), 有些可以透過跨站程序完成, 迴避需要非同步或持續執行的方法很多種, 但可惜的不是所有的問題都可以這樣解決. 但是當有這個需要時候, Java 或是 ASP 都有相對簡單的方案. 用PHP直接寫RPC程式? 別鬧了, 不是不行, 這種人太少了, 相較於稍微訓練一下就可以用 VB 寫 COM+ 元件的人的數量來說, 真的太少了. 如果你真的是哪種可以用 PHP 寫 RPC daemon 的人, 我會保持敬意. 但, 如果你是故意斷章取義, 那就另當別論論.

4.RTFM & RTFS! (a)你這是自取其辱嗎? PHP Document::Mail Functions::SMTP string Used under Windows only: DNS name or IP address of the SMTP server PHP should use for mail sent with the mail() function. (b)改用 PEAR::Mail 或是其他的 Mailer 都可以, 而且花不了幾分鐘, 這樣就可以改用 (c)雖然PHP文件上面已經警告過mail()在Windows和Unix平台上實作方式不同, 但是如果你仔細看 win95nt.h (core\main) 和 sendmail.c (core\win32) 就會發現如果需要把這個 function 換掉並不困難.(相對於Zend Engine而言) (d)就算要直接跟外部 smtp 交談也不是什麼難事, 基本也不過四道指令, 有足夠 unix 經驗的人基本上應該都會.

修改 IP ? 別鬧了吧? 還是你對這這個東西的了解只到這種程度? 還是對 PHP 的了解只有這種程度? 如果是這樣, 怎麼當打手? 這讓我覺得連罵人都沒意思.

5.1.8MB要傳多久很難說, "不懂PHY層,就是不懂AP層,不然就是不懂TCP" 這句話得還你, 如果真的有這個程度, 或只是有意賣弄專業用語, 不如拿 HDLC 出來嚇人. 任何讀過磚頭書(TCP/IP Illustrated)第一本或是上過比較正式的網路管理課程的人應該都能夠計算傳輸量的理論上限. 算到多精確要看給的條件和要求, 但是用到現實生活裡, 1700 跑 T1 只跑 173 同一條線用 2600 去跑卻可以跑過 190 (普通的HTP/FTP測試). 殘念, 雖然認證課程我只上過 CCNA (Cisco), 但是光憑這兩句話還是嚇不倒人的.

再者, 把 PHY、AP和TCP放在一起就已經有點牽強了, 為什麼? 因為TCP/IP基本上不管 PHY 的東西, AP層如果無法提供充足的資料, 速度一定慢是沒錯, 進到 TCP 層之後, 就跟 AP 沒有關係了. 而單純的用 HTTP 傳送一個檔案, Apache 會塞不滿 Buffer 嗎? 在大負載的狀況下的確會有其他的因素變得強烈而改變這個條件, 把這幾樣東西混到一起去質疑對方, 只是顯示自己的觀念不清而已. 就算你在 LAN 裡面開 Jumbo , 會對一條 T1 的出口頻寬利用率產生多少影響? 別鬧了好嗎? 刮風下雨可能影響還大一點. 計算理論值是任何網管課程裡面最基本的考題, 值得拿出來炫耀嗎? 如果要更實際一點, 拿 smartbit 出來打不就知道了, 如果不用那麼準OSS工具一大堆. 如果你下一步要拿 LFN Problem 之類的問題出來考人, 就大可不必了. 對於 TCP 控制的基本原則有了解的人都不會被嚇到.

話說回來, 那段文字裡面能值得挑語病的地方是"要少花上十秒傳輸", 因為如果硬要挑話, 可以試算在理想狀況下, 即使加上IP和HDLC overhead, 1.8MB算起來大概略低於 10 秒. 不過那是理想狀況. 我不是故意要挖坑給你跳, 而是而是剛好這點指可以指出這種似懂非懂的矇混, 是非常令人討厭的.

6.也許你確實是打手, 但是這種程度要去在這一塊專業領域筆戰, 大概只有輸的份.

a)黑箱測試的原始文句是: "(指黑箱測試, 我稽核過上百個網頁程式大部分是ASP和PHP, JSP和CFM是少數, 黑箱是不看程式原始碼的狀況進行, 通常用在第一次測試)" 換句話說, 這是很明顯的是指"稽核", 我相信你應該沒有稽核這類程式的經驗, 也不知道如何進行. 在稽核之前, 我們會先由外部進行, 如同一般的網路安全稽核一樣, 不會直接翻程式碼. 如果這個階段可以找出嚴重的錯誤, 那麼表示軟體的品質可能有相當程度的問題. 不了解沒關係, 拿軟體工程的概念出來也沒關係. 糟糕的是, 一開始看起來像是有點程度, 遇到重點的時候卻用扭曲文意的方式避重就輕, 很抱歉, 這種手法是三流的人在用的.

b)單項鏈結, 我相信你大概也完全不懂, 不懂, 去找資料, 如果是當打手硬要用拿個"太多對 也太多錯的地方了,如果全對或全錯就算了,可怕的是有些對有些錯,卻當成對來處理。"來矇混過去, 很抱歉, 我可以說, "聽說這裡有人討論Web的技術,個人最喜歡討論技術了" 討論出來卻是滿紙皆錯! 如果你真的了解這種簡單的技術問題, 那麼直接挑戰演算效能或壓力測試的問題不是更能顯示你的"專業". 但是很抱歉, 關於演算效能和壓力測試的確需要有點經驗的人才有可能提出. 而你卻在這些面向上完全沒有著墨.

c)提 AJAX 卻錯過 AJAX 的精神所在 (找本書叫做:Pragmatic Ajax : A Web 2.0 Primer, 那句話是出自這裡), 用COM+或EJB不是什麼大不了的事情, 也說過, 這是實務層次上的問題(人難找), 用到COM就配ASP, 用到EJB就用JAVA, PHP放在 windows 一樣可以叫用 COM+, 但是你吐到 RPC/DCOM/COBRA 去是怎麼樣? 難道你用 PHP 寫RPC daemon? 如果這是真的, 說實話, 我的確會保持敬意. mail function 的問題, 直接看 http://tw2.php.net/manual/en/ref.mail.php 吧, 自取其辱, 懶得再說. 但是真正有語病的 1.8MB 完全沒看出來, 反而拿 PHY, AP, TCP 之類的詞出來矇混, 而且還有觀念混淆的問題(去念RFC1180), 即使是 flaming 也太混了吧. 黑箱測試, 先曲解他人的意思, 再將自己能用的論點硬套, 若非真的不懂, 就是太逞強了. 這是三流得手法啊!

d)所以, 再加上結語, 完全看不出這像是"討論Web的技術". 比拼專業知識, 還是幫別人爭一口氣? 或是像是那些九流人士回去發黑函? 這是謾罵, 以這種程度的回應來說, 還不足以當成是技術討論. 當然, 這兩篇如果被人斷章取義去博取同情, 我也不會感到驚訝. (這也是很常見的現象)

簡單的來說, 我最後轉向研究 Programmer 的心態, 就是因為看太多這種半吊子. 而且這種心態遲早會害人, 會寫兩個程式就覺得自己很了不起, 結果就是 SQL Injection, Command Injection... (不懂, 用 google, 會特別關注也是因為第一次 demo 就看到這種問題), 然後就會有盜領, 入侵...etc . 如果不是抱著這種剛愎心態, 我還是願意教, 但是好歹我不會碰一鼻子灰之後, 回頭再酸溜溜的拐著彎偷偷罵人.

順便一提的是, 如果抱持這種心態的人, 我是少碰為妙, 所以我從好友名單裡面移除了, 如果你的還在, 也請移除.



給打手: 如果這真的那麼無足輕重, 你又何必在意呢? 看來講的和做的, 還是有一大段差距啊...



OK, 好吧, 我只是想罵人而已, 如果要當成"討論", 請拿出比較有水準的東西, 不服氣的話, 要公開比試或是拿給第三方審查也行. 畢竟已經把 web scripting 的技能隱藏起來有好幾年了, 就像這位"好同學"也不知道我以前是寫web的一樣, 丟臉的機會不是沒有, 不過以這種程度來說, 丟臉的機會應該不大... 哈哈.

四非書房 提到...

小開很有時間喔~

花了這麼多時間寫,記得要署名才能名留青史。

匿名 提到...

我是找資料時闖到這篇文裡來,冒昧對這件事發表一下個人看法。

就個人經驗,一般網站外包案的作業流程大抵如下:
1.發案人開出網站建置需求
2.接案人根據前項作出SA,並經發案人確認無誤。
3.根據SA設計網站樣板layout供發案人確認(修改以不超過三次為準)。
4.程式人員完成後端相關處理。
5.驗收交貨。

從站長的主文,跟另幾項無名氏的回應(感覺應是站長的學長吧,沒留名字我亂猜,猜錯的話謹此致歉)內容看來,既看不出兩人誰扮演PM的角色,發案的人也沒提供清楚的需求規格表給承包人(還是程式高手...高手都是這樣高來高去的嗎?)。也就是說,一開始兩人就失去基本的共識,接下來結果便是就自己立場各自解讀訊息,後續工作沒有問題才有鬼。

不過我覺得發案的人比較理虧,因為到最後還說自己只花了短短時間才完成,表示你很清楚你要的是甚麼,可以用哪些工具或筆甚麼作,這些訊息為何一開始都沒揭露給或接案人?搞到最後還自己下來作,那這樣你一開始自己弄不是更好?總之這都令人覺得想像不能... @ @

匿名 提到...

老頭, 實際的情況是, 有一個現成可運作的網站, 內容也都已經完成, 所以不需要製作太多內容. 但是ASP平台, 但是因為授權的問題我們不能直接公開使用.所有的程式碼和內容都已經交付. 而且還將實際的系統上線提供發展者參考.

要求也是做出類同的功能. (show出資料庫中html內容, 搜尋和後端上稿)

所以不存在 RFP 的問題. (實物參考)

沒有自己做的原因也很簡單, 因為沒那麼多時間, php 也不是我最熟悉的語言. 但是既然推了, 我就必須負責, 能在很短的時間完成, 是因為實際的案件規模只有這樣.

我是被批評不懂網站建置的人, 所以也高不到哪裡去. 見笑了.

匿名 提到...

哇~這裡有人在討論ajax和php,這幾篇倒是沒看到,他們的功力實在都很強,可以討論這麼長篇大論。J2EE、LAMP這還是第一次聽到。老師和老師的學長真不愧都是高材生。