跳到主要內容

發表文章

MSNP16 與MSNP15 的差異

MSNP16 與MSNP15 唯一的差異 USR 4 SSO S t=...&p=xxx {MACHINE_GUID} 其中 MACHINE_GUID 可以是任何 32bytes 的16進制亂數,這大概是為了要讓MSN 可以在不同位置重複登入所設計,就像是XMPP 中的(jid)uid@domain/resource類似

msnSDK 文件

msnSDK ( http://tcmail.program.com.tw/image/msnSDKV1.0.1.pdf )主要的功能就是把一些常用的MSN 功能做成一些API,讓外部的程式可以簡單的應用它來開發相關應用程式,目前;msnSDK支援4種程式介面, 1.SOAP 2.CGI 3.ADO (這三種API的功能相同) 4.CGI-Steam 這個介面主要是處理從msn client 到msnSDK 之間的訊息以及線上狀況的資訊傳遞,歡迎需要測試功能的人或是有應用需求的各行各業先進與我聯繫(sonet.all@gmail.com) 備註:msnSDK 本身有unix/linux/win32 版本 v1.0.2 已釋出: msnSDK v1.0.2 文件釋出 v1.0.3 已釋出: msnSDK v1.0.3 文件釋出 不分版本(最新): msnSDK 不分版本(最新)文件

如何成為一位傑出的工程師一文讀後感

這篇文章 值得一讀,但是;讀完後我們要怎麼再思考咀嚼成為自己的血肉? 我覺得 why很重要,而why not也很重要,文中提到: 成就傑出表現的原因並不在他們擁有什麼 ,而在於他們如何應用他們所擁有的特質。傑出表現之謎其實在於如何將他們的天分轉換成生產力:就好像將位能轉換成動能一樣。我們的結論是:傑出的表現是努力得來的,與天份無關。(Stars are made, not born.) 那麼這句話自相矛盾的嚴重!沒有天份,就無法將天份轉換成生產力,所以;傑出表現的原因在他需要先擁有天份,才能轉換/應用 特質,結論應該是;傑出的表現是因為有了天份,才能靠後天努力得來,那麼就與天份有關,不是嗎? 這篇文章反應的只是一些特例,也就是說他的研究對象是那些已經在這個領域有充足天份的人,以這些人為基礎來做這個研究,成員結構與一般的公司大相逕庭,所以他的結論應該是;如果你對xx領域已有天份,還需要靠後天的努力才能成為傑出的工程師,於是乎那種天生的宿命論仍然主導一個工程師的傑出不傑出,不是嗎? --- 電子發票系統建置  http://rd-program.blogspot.com/2012/03/blog-post.html  ---

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

親愛的夥伴,我最敬愛的摯友;我不知道你們多久會來看我的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-> ...