re: Meta Generation mixlee 2007-01-21 21:27
有witrix平臺的DEMO可以看嗎？非常感興趣
re: 三種Tomcat的插件比較 mixlee 2007-01-18 09:52
Myeclipse沒那么多限制。只要TOMCAT配好就OK了
re: Ajax：擁抱JSON，讓XML走開 mixlee 2006-10-01 18:07
xml對tree結構的處理還有優勢的，其他數據結構用JSON最好
re: 動態語言是否會成為JAVA的終結者？ mixlee 2006-09-01 21:01
看不出Ruby、Python和桌面有啥關系，也搞不懂OO和并行/分布式計算有啥矛盾。垃圾啊
LGPL的license如果用在商業代碼中會不會有問題？好象用LGPL的代碼都要開放出源碼？
為啥非的弄成C/S模式？AJAX只是補充而已。C/S是倒退
re: 還是亂碼問題 mixlee 2006-07-23 11:07
我也碰到亂碼問題，在tomcat下是好的，但放到oc4j下就亂了。只是include的網頁是亂碼，不知道怎么回事。include的網頁也加了encoding的。GBK和UTF8都不行。里面用了jstl，不知是不是這個原因，jstl怎么指定encoding啊？哪位兄弟知道
@quaff
既然兩個沒影響，那做成單例有什么不可，反正各自加載各自的配置文件，互不影響。
我想問問，在一個web server，比如tomcat下，放兩個application。
在這兩個application中都包含有同一個單實例的class。那么這兩個單實例會互相有影響么？為什么在web系統中很少見人使用單實例，實際的例子就是spring取對象的方式，直接做一個單實例封裝一下就可以在系統內方便的取對象了，為什么還要用WebApplicationContextUtils.getRequiredWebApplicationContext(context)的方式來取,我看代碼spring 是把啟動時加載的配置信息放在ServletContext里，為什么不直接放在一個單實例里取值還方便，對單實例一直有疑惑，還請老兄賜教
re: 用戶評價系統的觀點 mixlee 2006-04-29 18:31
關鍵是交互性和可操作性。也就是用起來是否方便，這個最重要。
漂亮到在其次。再漂亮用起來別扭也白搭
re: 我的一次項目管理實戰 mixlee 2006-04-29 18:20
總結得很不錯，許多關鍵點都抓到了
大家一起吃飯可以代替共同出去參加一些活動。
每天的聚餐可以很好的融合團隊的感情。
個人認為不在一起聚餐就根本算不上一個團隊，我比較中國，呵呵
re: 拿什么來驅動你啊，我的項目？ mixlee 2006-04-26 22:45
一般對技術不在行的LEADER就特別喜歡文檔，因為這是他的工作成績的體現。這也是他對技術沒有把握，沒有信心，所以只能靠文檔來安慰安慰自己。
我認為文檔還是有用的，在開發的時候可能效果不是很明顯，在后繼開發中就能體現出來。
比如換了一撥開發人員，如果沒有用例，沒有功能的需求說明，那么新來的人光在需求里就得摸上大半個月，還弄不明白。而且需求階段的文檔寫清楚了，也就可以讓開發人員好干活。
所以需求階段的文檔一定得寫清楚。這個階段的文檔我認為還是得主要靠文字描述，盡量寫詳細。
至于設計方面，代碼就是最好的文檔。寫詳細設計文檔簡直就是浪費時間
re: 代碼質量與文檔質量 mixlee 2006-04-25 23:27
這個跟以前有沒做過沒啥關系。
做沒做過應該是指業務邏輯。與開發框架無關。
如果具備開發框架的思想，那么即使是進入一個新的技術領域，也會先把開發相應的框架做起來然后再做業務應用。
re: 代碼質量與文檔質量 mixlee 2006-04-23 13:20
對于軟件公司來說，
自己的開發框架才是最重要的。
有了一個好的開發框架，代碼質量就可控制，一切才能走上正軌。
就如同工廠如果沒有一套生產線，那么做出來的產品必定是不穩定的。
現在的公司，有幾家擁有自己的開發框架？有幾個項目經理手里掌握著成熟的開發框架？全部由零做起，不亂套才怪。
re: 新的展現層技術、架構與開發方式 mixlee 2006-04-19 20:26
個人認為Tapesrty的設計理念已經落后了。屬于上個世紀的設計思維
re: 你必須找到你所熱愛的事情 mixlee 2006-04-17 23:35
我熱愛的是投機交易，不過靠這玩意兒現在我養活不了我自己，所以還得郁悶的埋頭編碼
re: DAO-持久層-領域對象-貧血模型 mixlee 2006-04-11 01:30
典型的濫用接口
re: 關于團隊的一些想法 mixlee 2006-04-09 01:17
一個團隊就如同一個球隊，必須要有顯著的風格才能取勝。
風格是LEADER注入給團隊的。靠什么CMM根本沒用。
有聽說過球隊實行CMM的嗎，呵呵
我認為接口是約定遵守的行為標準，具體怎么實現可以由各使用者自行確定。
所以一般技術標準都是以接口形式公布。可以方便各廠商自行實現。所以接口主要是對外的。
abstract更大程度上是應用在自己能掌控的內部，比如自己是軟件開發商，那么在自己的系統里就可以大張旗鼓的使用abstract而不用考慮別人會怎么實現。
表達能力不好，說的不太清楚。也就是說如果有第三方實現的參與，最好用接口，如果是自己實現，接口和abstract都可以考慮
re: 回顧兩個項目看設計階段 mixlee 2006-01-20 02:56
培訓初程的代價太大，國內公司很少做這種事。
我認為初程最好只做二次開發，就是基于公司的快速開發框架做業務流程的應用開發。這樣以來框架會強制性的實現開發的規范性以及一致性還有性能的問題。
要設計師提供詳細設計文檔給初程也是不現實的事情。
詳細設計花的時間比編碼的時間還長，只一個設計師不可能完成這項任務。
到最后設計師就成撲火隊員，一方面要培訓初程,跟初程溝通也是一件花時間的事情，另一方面還得解決技術攻關，兩頭都做不好，基本上會累的半死。