2011-03-31

常常某些Dll到不同的電腦上會無法載入

最近有個CASE 要呼叫QuickFIX所提供的.NET dll


我的程式將 quickfix_net.dll 及 quickfix_net_messages.dll 加入參考之後


然後呼叫它來處理


OK 程式Compile完了之後 在本機上測試通過 然後放到另一台主機上(OS為XP)也順利執行


但是在windows 2003上面卻行不通 exception顯示是無法載入檔案


google了一下 發現可以利用 Dependency Walker


查詢這個dll到底需要那些dll才能執行


一查之下 發現windows 2003的PC上少了MSVCP100.dll 跟 MSVCR100.dll


又google了一下 應該是C++所需的元件吧 所以少了這兩個元件的PC無法載入quickfix_net.dll


所以趕緊上 http://www.microsoft.com/downloads/en/confirmation.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84&displaylang=en


下載C++所需的套件 程式果然就正常執行了


2011-03-15

[筆記]高階IT架構師座談會(5)



Session 5 台灣資深技術人員之路，顧問講師的經驗分享

5.1 顧問需俱備的能力

    (1) 口才
    (2) 規劃
    (3) 專業
    (4) 解決問題
    (5) 行銷
    (6) 專案

5.2 如何培養成為IT顧問
    (1) 主修加強 並增加學習廣度 至少都要認識
    (2) 要有聆聽的能力
    (3) 一定要非常有興趣 才能感染其他人
    (4) 訓練自己以不同角度看待事情 培養宏觀格局
    (5) 持續學習精確的技術 不斷嘗試 累計經驗
    (6) 多參加活動 磨練膽量
    (7) 考上MVP 參加MVP的聚會 多跟高手一起討論

[筆記]高階IT架構師座談會(4)




Session 4 程式設計師的「校能調校」


4.1 透過Sharing 讓較弱的同仁跟上腳步


4.2 成為開發者的基本條件


  
技術方面 : (1) OO (2)
XML (3) 平台技術(.NET or JAVA)


  
態度方面 : (1) 高度興趣 (2) 邏輯要好


4.3 OO一定要用團隊來開發 因為要有人使用 才會去修正設計的缺失 設計技巧才會進步 所以沒有環境就開發不了好的OO程式


4.4 技術至少要知道其細節 盡量不要使用黑箱程式 ex.要玩ORM
還是得先了解ADO.NET (註. ORM
(Object-Relational Mapping )只是一個以物件導向的方式來存取資料庫欄位的架構, ADO.NET
Entity Framework，是微軟以 ADO.NET 為基礎所研發出來的類似ORM架構解決方案)


4.5 提升軟體效能的方法


   
政治->外包->硬體->架構->演算法->程式語言


4.6 進度vs品質


   
(1) 年輕時以品質為主 能力才能提升 盡量超越老闆的標準


   
(2) 開發人員維持自己的品質
QA維持專案的品質


   
(3) 專案以進度為主 產品以品質為主


4.7 慣例不一定是對的


   
開發者常常copy paste 老手或別人的作品
不了解其背後的邏輯


   
說不定那些老手們的慣用作法是錯的


4.8 慣例不一定是錯的


   
舊系統留下的code 是累計下來的經驗
若行不通的話早就掛了 所以直接翻掉重寫 會遺失當初的細節 因為不了解背後的邏輯


4.9 達成率假象


   
(1) 怕績效不好 可能會從最簡單的開始做 結果最後20%卻花最久甚至是永遠都無法完成


   
(2) 腦力開發產業本來就很難估真實的達成率


   
(3) 做code review 可避免造假


   
(4) 對可信賴的人 才能估出他的達成率


4.10 如何讓開發者進步


   
(1) 舉行競賽


   
(2) 一個team不能整天都在開發
要留時間讓某些人學習 然後分享出來


   
(3) 讀書


    (4) 專心


4.11 開發者如何挑書來讀


   
(1) 找該作者是否為官方版產品的人員


   
(2) 針對你想了解的問題 找該解決方案的書籍 了解其細節


   
(3) google可能只提供片斷 沒有細節 不能盡信


[筆記]高階IT架構師座談會(3)





Session 3 如何設計以服務為導向的企業資訊架構


3.1 DB的相關處理 : 全部都用stored procedure 切開 千萬別直接操作DB


3.2 Data Layer Service : 建議call sp 的東西做成元件
進而做成服務


3.3 SOA常見的錯誤開發方式


        (1) 開發習慣改不過來
程式間仍bind太緊


   (2) 僅僅將元件變成Service並不是SOA的精神


   (3) 常做出只滿足前端某一需求的服務 (不夠自由)


   (4) Service要跨平台時Message不要使用該語言的特性


      建議回歸基本的型別 or 按照wsdl規定


      顧問們一致推薦JSON


      ps. 若資料量太大
可使用Google Protocol Buffer 來處理


   (5) Framework的Base寫超大是浪費 很多人只是用到其中一小塊功能


      建議透過不同的Interface去控制版本 好處是當Base擴充新功能 舊版仍讀舊的Interface就不會影響到


3.4  SOA應該是以服務為導向的架構


(1) 一定要鬆
才能重複使用


(2) 單一窗口對外
然後再導向其他Service


    (3) Service是給系統使用
而不是人


    (4) 設計Service時 建議倒過來想 從最前端開始設計


    (5) 必須要有一組專門的團隊來開發Service 不然開發者很容易因為其他案子而分心 效果不佳 (開發Framework也是)


3.5 SOA的表面好處與實際問題


   3.5.1
提升投資效益


        但實際上效益無法保證


   3.5.2
提升組織敏捷性


        但實際上有時會面臨以下問題 :


(1)
Interface會設計的過於複雜


(2) 平台與技術上的限制


   3.5.3
減輕IT負擔


        因為Service要對外服務 所以必須確保高可靠性及高獲得性


        反而需要更多心力去維護


3.6 服務導向原則 :


  ps. 描述 from wiki


  http://en.wikipedia.org/wiki/Service-oriented_architecture


(1) 標準化合約


   (2) 鬆散耦合


   (3) 抽象化


          除了服務契約中所描述的內容，服務將對外部隱藏邏輯


   (4) 重複使用


      將邏輯分佈在不同的服務中，以提高服務的重用性


   (5) 自主性


      服務對所封裝的邏輯具有控制權


   (6) 無狀態性


      服務將一個活動所需保存的資訊最小化


   (7) 可被探索性


服務需要對外部提供描述資訊，這樣可以通過現有的發現機制發現並訪問這些服務


   (8) 可組合性


一組服務可以協調工作並組合起來形成一個組合服務


3.7 訂閱者模式的架構能使用SOA嗎?


    座談中 我有請教一下顧問們 如果是 訂閱者模式的架構


    該如何引進SOA? 適合用SOA來處理嗎?


    胡顧問的回答是 雙向都能當作服務 但要避免依賴性的問題


    張顧問的回答是 可以切成兩塊 一塊realtime 一塊用batch來處理


    當下我沒想懂他們在說什麼 後來思考了一下 或許可用以下模式進行


    1. Service1 接收Client端需求者 要記錄Client位置


    2. Service2 主動發送端 => 一旦有新資料 就呼叫Service1


        讓Service1決定送什麼資料給誰


  


[筆記]高階IT架構師座談會(2)




Session 2 企業的雲端運算可以從那裡做起


2.1 雲端只是個新名詞 內部使用的技術仍是差不多


2.2 Services call Services的一些原則


   (1) 要埋breakpoint


   (2) 要有自己的log (因為雲端上相互呼叫 不好debug)


   (3) 把Services做整合


   (4) 要考量到”同步”問題(very
important)


2.2 如何面對新名詞


   (1) 看到一定要先記下來
若多次碰到再去survey


   (2) 評估一下此新名詞大概會活多久
會多紅 有價值再去碰


   (3) 自己要增加快速學習吸收的能力


2.3 如何使用Open Source的東西


   (1) 當作者換版時 你要評估換或不換


2.4 Windows Azure 免費申請到六月


2.5 混合雲概念 : 一般時刻使用私有雲服務就足夠 但是當面對尖峰時刻時 再臨時租用公有雲來處理


2011-03-14

2011-03-12

[筆記]高階IT架構師座談會(1)

2011/3/11 參加了一場IT架構師的座談


主講人都是很厲害的高手 聽完他們的經驗分享 真的受用無窮


我記錄下一些對我有影響的topic 期待未來的案例能夠找到best solution


Session 1 企業軟體開發的生命周期管理


1.1 這場主要是講在台灣的軟工流程 有一般的標準流程(ex.瀑布式) 也有提到Agile => 是由user驅動,從需求端開始完成開發


1.2 案子越大通常老闆要越強勢 才有可能成功


1.3 In Taiwan, 企業文化仍倒向客戶端這邊 所以客戶需求 > 一切


1.4 所以當面對客戶或老闆不合理的需求時 要有能力說"不"


      但不是直接硬碰硬的說不 你不要做 事情仍是換你的同事做 終究是團隊裡其他成員會擔下來


1.5 說"不" 是件藝術 你要提出替代方案 或是證據 說服客戶或是老闆


1.6 當跟客戶談需求時 客戶常常會説 我不知道需求是什麼?


      此時需要你不斷的去引導 溝通


      PS. 客戶需求時常會變 所以每次談的內容都一定要記錄下來


1.7 客戶不會管你的架構設計的好不好 只會理他的需求有沒有達成


      但是架構設計的好 軟體才活得長久


1.8 Architect的工作 (1) 設計 (2) 決定技術 (3)提出solution


1.9 趨勢的張書源顧問決定技術的條件之一 就是挑選至少會活2年的技術


      他的工作做了很多POC (Proof of Concept, 證明新技術是否能用)


1.10 張顧問認為整合新舊系統or解決擴建問題 目前最佳的solution就是SOA


1.11 標準的流程是 分析->產出文件(確認需求)->實作


       但在台灣常常會反過來 顧問群裡有人覺得反過來也不錯 至少最後出來的文件才是最正確版本的文件


1.12 胡百敬顧問認為一定要先分析才能控制需求 確認專案範圍程度


       他認為沒想好就動工必定會失敗 越早寫越早死


1.13 如果有委外 一定要拿source code 不然根本無法維護


1.14 如何處理複雜的專案呢?


        (1) 固定IO(應該是指單位化的意思)


        (2) 做小規模UnitTest(應該也是指單位化)


1.15 如何讓後人可以維護你的程式呢?


        (1) 埋break point 讓人知道你上次dubug到這裡



 


2011-03-02

C# byte相加及short相加竟然是int

今天做了將short相加的動作


ex.


short s1 = 1;


short s2 = 5;


short s3 = s1 + s2;             // 編譯不過


int s4 = s1+ s2;                 // ok


short s5 = (short)(s1 + s2); // ok




byte b1 = 1;


byte b2 = 2;


byte b3 = b1 + b2;             // 編譯不過


int b4 = b1+ b2;                 // ok


byte b5 = (byte)(b1 + b2);   // ok


 


原因是C# 會將 short 或 byte的四則運算轉置為int


所以相加之後 要記得做強行轉換