[opentaps ERP+CRM社群議會] 本週主題20071025

時間為: 10/25 pm 14:00~18:00 自由進場

本週 Topic:

1. ERP及 CRM 的簡介與實務 (丁元)
   
2. SVN + TortoiseSVN 教學 (志均)
   
3. opentaps ERP+CRM 中文化工作方式與任務分派 (小郭)
4. wiki使用教學與當前進度說明
5. 問題與討論

新主站與wiki+SVN: http://opentaps-chinese.blogspot.com/

說明事項:

1. 原本社群主題為 L2J Java 遊戲伺服器, 經過大家討論也許較看不到"願景"
   L2J PG.Chinese(天堂II Java Server)
   決定減少研究時間,但歡迎想了解如何架設者,
   利用每週定時的聚會時間來請教與學習.
   
   
2. 新社群為 opentaps ERP+CRM 研究社群
   每週主參與者們進行相關或技術心得分享...
   採自由參與, 甚至歡迎有興趣了解的您參與學習或領取分組工作.
   
   
3. 當前 SVN source code 約 450 MB, 檔案總數約 10,000,
   下載總時間約3小時, 欲下載者請先有心理準備.
   

* ERP 專有名詞中文化組
* 開發技術研究組 (Java ERP 技術開發工程)
* ERP+CRM 使用者介面與理論研究組 ( ERP 教肓訓練顧問)

opentaps 使用 jar 檔案清單總表

version: 5760

總共 438 個

• 依名稱排列
• 依目錄排列
  

技術對談~看 Google 怎麼用 Java

原文 iThome online

這篇文章雖然有點舊了, 但卻可以從中體會Google的想法
到是可以給其他企業一些參考性的建議:

如何在不斷擴增的Java中保持"輕快",
老僧人前陣子閱讀的這二本書,
Better, Faster, Lighter Java (輕快的好 Java)
Prefactoring (軟體預先架構之美學)

或許加上以下的Google訪談中的重點,
會給您一點"約束"力, 來減低架構上的設計...

小僧人就把文中的重點給整理出來供大家思索一翻...

• 我們喜歡使用現成的PC，來建構我們的系統，而不是大型而且可靠度佳的昂貴主機。
  單一PC隨時可能發生錯誤，我們試著用軟體的方式建立容錯的機制。
• 
  
• 我們沒使用J2EE，這其中有許多原因，包括Google在J2EE之前就已經有了自己的分散式架構，甚至還是使用 Java 語言建構出來的。
• 小僧人個人見: J2EE確實學習與教育成本太高了, 大約要3-5年的經驗者人力
  
  
• 失敗不是少見的情況，而是很常見的。當你要建立一個像Google這樣規模的搜尋服務，你可以想像會有多少問題，但是我們就是要持續的讓服務運作下去，盡量讓系統可以自動修復，不要造成延遲。
  
  
• 在中介層的開發，Java是很好的選擇。
  
  
• 採用 Java 有一個很重要的理由是想要降低開發的心力和時間。另一個理由，學生在學校裡學的都是Java，而且喜歡Java，他們甚至不懂C++，所以比找C++人才容易。而且Java除錯容易多了。
• 小僧人個人見: 找一班C++的人力資源, 確實比Java來的難...
  
  
• 在Google使用C++的應該多一點，可能是 6：4 左右。不過，使用Java的人正在成長中...
  
  
• 有許多在Java社群有所貢獻的人，現在都在Google
  
  
• Google盡可能的維持小型團隊，而且讓小型團隊在同地點工作，理想的團隊規模可能是5個人，4個或5個，也許多到8個。大過這個數字，溝通就複雜多了。
• 小僧人個人見: 這是很棒的軟體開發專案的建議
  
  
• 現在有多少員工...一萬人
  
  
• Google不會把5、6個新員工放在一起，由他們自己做事，新員工都會安插在一些原有的團隊裡面。
  
  
• 我們已經完成JDK 1.6的測試，只要等JDK 1.6公佈後，我們也可以很快地轉換過去。
  
  
• 每個語言都有生命週期，有些語言持續增加新功能，導致該語言後來很難寫、很醜、難以使用，很多語言後來變成這樣，而我會盡力讓Java不變成這樣。 我相信現在的Java已經是一個相當完整的語言，雖然還是有很多好的功能可以加入，但將這些東西一股腦全部加進來絕對是錯的。

最簡單但卻是最棒的答案-Better, Faster, Lighter Java(心得一)

有時候其實最簡單的架構, 卻是最棒的答案~

信守從最簡單的答案變成最棒的答案, 總是在你堅守這原則後驚異發現...

這本書雖然以 Java 來看,
但實際上卻很適合各領域的程式語言開發案的成員們閱讀
每種語言的背後都應該以這精神來構建才會是個良方...

Better, Faster, Lighter Java

http://www.oreilly.com/catalog/bfljava/

http://www.oreilly.com.tw/product_java.php?id=a168

Java的複雜度已經超越我們的能力...
我們漸漸發現控制不了也學不完的新 Java架構...

我們的經驗與能力的極限的結果,
我們花在撰寫利用新架構的Code竟比解決真正問題的部分還多
新的枷鎖不斷增加, 卻離直接的幫助漸行漸遠...

面對不對受商業影響的 Java 我們不需要

• 超過三到五層的 Logic Layer, 應當簡化為二層簡化無法控制的複雜度
• 不需要 EJB, 大多數的結果只是 the bloat "澎風" 的虛表與走向失控
• 使用 Tomcat 不是龐大的 Web Logic or JBoss ..

J2EE 的學習成本超乎我們個人的學習極限, 且受廠商們不斷為了收益,
廠商必需持績加諸新疊床 Design pattern, 來確保企業對其產品的買單...

Hibernate, Spring 捨 J2EE 改採以走最少量簡化的 API 來達到同樣的目的,
但這卻是每位Java開發者最想要的！

不可避免的膨風

• 超大型的企業架構才叫時尚? 卻苦了近90%的Java開發者
• 用大砲打小鳥的架構?
• Design pattern 拾簡單化換威力, 就是膨風
• 超多的膨脹程式碼並不是來自對於寫code知道太多的人, 反是來自那些知道太少的人

對抗膨脹的五個基本法則

1. 保持簡單
   優秀程式員的價值在於簡化, 更易除錯, 更易進行測試, 更易進行加強與維護, 更易其它團員接手
   
   
2. 每次做好一件事
   單體化的 MVC (Model-View-Controller)是優雅與專注的表現
   也利於Refactor重構, 更利於測試.
   
   
3. 力求通透transparency
   Hibernate or JDO 是很棒的替代方案
   
   
4. 開放擴充
   善用OO設計原則中的部份 Abstraction
   善用 ORMDBS 的設計
   善用 RMI (Remote method invocation)
   
   
5. 吃什麼像什麼
   過度的相信Java廠商建議, 特定J2EE的信仰與廣告只會引領你走向毀滅與專案失控...

opentaps 版本 1.0 概觀

Version 1.0 是 2007 年預定發布的版本,
並且是一個完整企業級應用平臺能提升整體的企業工作效率.

opentaps 開發技術架構圖


Opentaps 1.0 包含著以下的子系統:

• 客戶關係管理(Customer Relationship Management, CRM);
• 企業資源規劃(Enterprise Resource Planning, ERP);
• 財務會計(Financials and Accounting),
• 庫存(Inventory), 倉儲(Warehouse), 及製造(Manufacturing);
• 採購(Purchasing); 完整的線上即時與銷售存儲點功能.
• 它同時也包含著整合外部應用的工具, 包括客製化應用的文件,
  Outlook, 及行動裝置支持通過 SOAP, XML-RPC, 與 SyncML.

opentaps 應用架構圖(當前)


opentaps 應用架構圖(較早期)


opentaps 使用者介面


opentaps 財務會計輸出的報表


opentaps 整合輸出式的電子商務網站系統