跳到主要內容

發表文章

目前顯示的是 8月, 2008的文章

抱歉!我並不希望你們假日來公司加班

親愛的夥伴,我最敬愛的摯友;我不知道你們多久會來看我的Blog;或是根本不會來,但是我還是想說一些心裡的話,今天我到公司看到大家認真加班,每個人不求加薪在星期假日到公司來趕工作,那種熱情;我本該由衷感激,不過;抱歉!我必須說:我並不希望你們假日來公司加班,因為加班只是效率不佳與無法準確估算時程最佳寫照,雖然;我不是你們每個人的主管,不過我必須跟你們說:這類的加班是錯誤的,不管對公司對個人來說,都損耗了最大的成本,而且;個人也不相信趕工出來的東西;品質能夠得到任何的保障 不過我應該更精確的說明我的想法,我所指的是沒有按照計畫行事而因為要交付客戶產品時程趕不及所需要的加班,這一連兩個禮拜,我看到這種狀況真的是搖頭連連,如果我自己知道;我所要購買的產品不是按部就班完成,而是透過加班的手段來達成目標,那我會毫不遲疑的退貨,理由無他;因為工作沒有按照例行計畫施行來完成,在每個流程裡的工作者都無法確實估算他的工作流程所需時間;且無法提出保證,這代表了生產品質也面臨相同的問題->不夠精確且無法提出證明,那麼;我們該為這種例外管理上的趕工喝采嗎? 值得商榷...真正有效的管理計畫,應該要包含很多變異的因素,所以計畫本身就要包含變化,才能將不確定的因素降到最低,如此才能使經營成本得到精確的估算,保障企業經營的穩定成長,如果我們遇到的每個問題都是不確定的,那我們要如何保障股東與客戶的權益,替他們提供確實可行的願景? 公司假日仍在公司的比率,我應該數一數二,且每天從事工作相關的事務直到am 1:00,但是我絕對不願意把絲毫的時間浪費在這種無法保證自己工作效率的事務上,我寧願假日到公司心情輕鬆自在的讀我想讀的技術文件,我情願熬夜去探討怎麼寫程式會比較好或怎麼把程式更有效率的完成且如何兼顧避免錯誤的發生,如果興趣就是programming,如果因為興趣而工作需要不停的工作,那是個人選擇,除此之外;抱歉!我只能說,這種補償過錯式的加班,不值得稱許 如果;你們認同我的想法,應該深自思考甚至開會檢討,這兩個星期我們是為什麼加班? 沒準時的理由是什麼? 該怎麼改善這些缺點? 是誰沒準時把東西交出來? 是誰說哪天要給而沒給? 是不是要提早先把工作完成? 我有沒有事先提醒我的夥伴該完成那些工作? 在遇到問題時我有積極向上反應嗎? 該不該獎勵 把準時 把品質 當成第一要務的夥伴? 這樣才真的有把問題

msn 疑似有一個bug

因為自己在摸索msn protocol,發現msn 在做聯絡人的地方有一個bug,當第一次把某個人加入聯絡人(且對方也核准)後,雙方如果都刪除彼此(沒封鎖聯絡人,但同時刪除hotmail聯絡人);當任一方要再訂閱對方,而有拒絕過一次後,對方從此不會再收到訂閱的通知,但自己卻可以訂閱對方為聯絡人且看到對方的線上資訊,這情況跟gtalk很類似,看來;大家在實作這個程序時都留下了一些缺憾 ps.這問題並不是msn client的bug,因為msn server確實沒有傳送ADL 指令;通知對方有人請求加入聯絡人 另外; msn 裡的顯示歌曲資訊會佔用不必要頻寬,msn client勾選這個項目後,似乎每幾秒就會送出UBX 指令給所有的聯絡人,不知道當一個團體很大(數千人,而且每個人都開啟這個功能,且彼此為聯絡人)又同在相同網域下的時候,是不是有可能造成網路嚴重的負擔

msnp15 認證過程(I)

使用別人開發好的msn sdk來開發程式;真的能夠滿足你對技術的慾望嗎?以下為msn protocol v15的認證過程,msnp15大致上延續前一版的協定,但是在認證的部份改了,目前msn server 已支援msnp16,而現階段最新的msn client (msn v8.1)還在使用msnp15,要到msn v9才會開始全面支援msnp16 直接從msn protocol著手的主要理由是~這樣,才能將msn 移植到非win32的平台上,否則;微軟本身也有釋出msn sdk,它的缺點是;只能依附在有安裝msn client 的win32上,就這一點來說;msn 的政策還相當封閉,因為每次protocol升級;認證的部份幾乎都有更動,這也是從protocol著手來應用msn 最大的麻煩,不過從追蹤 撰寫msn protocol,可以學到不少東西可說是額外的收穫,msn protocol在技術上跟xmpp真的很大的落差,msn protocol顯得格外凌亂設計不良,既不結構化也談不上功能上的彈性,看起來像是非資訊背景的工程師做出來的系統,我相信當msn與yahoo在談im整合時一定相互埋怨過對方的protocol設計怎麼如此草率,這恰好凸顯了 xmpp protocol 的優勢... 207.46.110.86:1863 c2s->[client to server] s2c->[server to client] c2s->VER 1 MSNP15 CVR0 s2c->VER 1 MSNP15 c2s->CVR 2 0x0404 winnt 5.2 i386 MSNMSGR 8.1.0178 MSFT luke_shei@hotmail.com s2c->CVR 2 8.1.0178 8.1.0178 8.1.0178 http://msgruser.dlservice.microsoft.com/download/1/C/F/1CF776CC-90D6-4497-B079-402BA9DB8BE4/Install_Messenger.exe http://get.live.com/tc c2s->USR 3 SSO I luke_shei@hotmail.com s2c->GCF 0 6713 s2c->

[微程式-技術研討會] 8月研討會 - Bidirectional-streams Over Synchronous HTTP (BOSH) - 主講人:znul

Bidirectional-streams Over Synchronous HTTP (BOSH) 網址: http://www.xmpp.org/extensions/xep-0124.html 一何謂bosh? 雙向性的Http串流,利用http protocol post transport xmpp stream 二why http protocol? 一般防火牆都會允許tcp 80 prot 的對外窗口,某些少數的防火牆甚至允許任何的通訊協定通過這個port, 但是更多的proxy,filter 會確認通過的串流是否為http 三技術名詞 1pull: client use http request from server,是一種以網路為基礎的溝通方法 2 push: server response data to client,是一種以網路為基礎的溝通方法,server主動將資料傳給client 四compare other bidirectional http-base transport protocol 1http polling :週期性的詢問server是否有資料 2 ajax(Asynchronous JavaScript and XML) 3 comet :是長時間連線要求的web 應用的模式,server在有資料要傳送時透過此連線push資料至用戶端. 利用ajax with long polling or iframe or htmlfile activex 的技術去探測server是否有新的訊息 4bosh:採用多個http request / response 對,非polling,自稱可高效率低延遲的傳輸訊息及節省網路頻寬 五要求 1相容於受約束的執行環境(如行動電話或流覽器的用戶端)**. 2可以讓流覽器的用戶端建立跨網域的連接* 3相容部份緩衝的http代理回應* 4有效率的通過http回應時間限制的代理* 5完全相容http 1.0* 6相容受限的網路連線(如防火牆.代理.閘道) 7容錯性 8擴展性 9使用的頻寬遠低於輪詢機制的protocols 10回應的時間遠低於輪詢機制的protocols 11支援輪詢 1