人在江湖

@神奇的小松鼠
對，望京。

@heavensay
謝謝。把斜體改成別的顏色了。本來還想通過換行整理一下格式，但是blogjava編輯功能里的換行不好使，faint.

@堅強的小萢萢 @YX @matrix
已發送視頻至優酷：http://v.youku.com/v_show/id_XNDQ1Nzk0NDYw.html

@YX
謝謝，這篇俺以前看過...我已經改了我用的軟件的參數了，不然更大。我用的是HyperCam，我晚上看看怎么壓縮視頻。謝謝。

@YX
這樣啊，能用斷點續傳的軟件嗎？

@YX
高清無碼版，呵呵。可能是我用的軟件不夠好吧，在公司錄的，只用免費錄屏軟件。有什么好的免費錄屏軟件推薦么？

@堅強的小萢萢
不能訪問是什么現象？你用google帳號登錄了么？我第一次用google drive.

@lirui
115網盤不用手機注冊的話，不允許下載，太孫子了。我本來不想暴露手機號給115，但是為了你，我用手機注冊了，感動了吧？哈哈，你可以再試一次，現在應該可以了。

@ccz
鏈接已更新，之前115網盤允許共享視頻文件，后來禁止了，所以很多朋友下載不了，現在打包成rar文件，可以下載了
http://115.com/file/dpawyyb4#pentaho-demo.rar

@lee
優酷有字幕，呵呵，我知道TED的官方網站也有，那不是還得下載么，我懶。謝謝提醒，等我看全優酷的會去TED直接看的。

@邵
我看到你的微博了，你關注的人中有好幾個是我的同事，呵呵。我是一個比較純粹的Java developer， 數據挖掘方向肯定遠不如你的造詣，所以不敢亂說。pentaho也沒有深入的學，真的沒有什么可建議你的，如果你遇到具體的java問題，倒是可以一起討論，呵呵，不是不肯回答你問題，確實這不是我擅長的方向。你很勤奮，很厲害，交個朋友吧，我的msn： wanchuyang911@hotmail.com

@allenny
純猜想，很可能說的不對，請指教。

哈哈，我自己都忘了。

哈哈，多謝，Frank，你怎么想起來看我blog了? 我這輩子最想的是，擺脫生存壓力。

@jacklondon
哈哈，首先還是感謝你在我的博客里發表技術看法，喜歡看到有見地的想法。
我們沒有在討論同一個問題，你說“設計時”，只有IDE才涉及到“設計時”的問題，我博客里舉的例子是說程序員"手敲XML"還是"手敲java"寫應用程序的界面。我覺得從易用性角度說，兩者沒區別，但封裝到“手敲XML”的成本要高出很多很多，所以根本不可取。
至于國際化的問題....
我舉的例子是功能性的，不是i18n的，所以這個例子是
<wallet><money>100</money></wallet> 這個美國人能看懂，對中國人就得用<錢包><錢>100</錢></錢包>

用戶修改xml來做國際化，修改的是content，不是標簽本身。把resource property放xml里我覺得沒有問題，那么樣子會是
<key name="abc.txt"> wallet </key>
<key name="abc.txt"> 錢包 </key>
我沒說非得把key翻譯成 鑰匙。 因為i18n用途的xml結構比輔助功能的xml簡單得多，對于復雜的xml結構（功能性質的），<B>標簽本身是有含義的，所以標簽本身有i18n的必要</B>。你跟我說的不是一回事。盡管我覺得用properties文件夠用了，不知道為什么一定要用xml. 對比java, 一涉及到xml就要多考慮I/O和解析。對比properties文件，一涉及到xml就要格外考慮解析。

Jacklondon， 你舉的兩個例子跟我的想法沒有沖突。
第一個例子：
你說XML可以在GUI里使用，是基于特定的IDE的支持，<B>不是你自己設計出一個基于xml的引擎</B>。NetBeans這么做是因為它是IDE。我絕不相信哪個應用產品先基于Swing封裝出來一套xml引擎，然后讓developer寫xml, 而不用寫java, 那使用這套引擎的人就根本不必是java developer了。 所謂"GUI Design出笑話"是IDE的問題，不是swing的問題。design time form文件應該是生成出來的吧？不是自己手敲xml就生成class, 讓JDK解析的吧？我認為有強烈需求要求程序員用xml寫GUI背后的原因是程序員本身不是swing developer.基于swing封裝成客戶化的更方便的component（更方便的意思就是更不靈活），一定比封裝成xml引擎更簡單.
第二個例子，國際化不是functional層面的，“熱心的用戶”是幫程序員做事情的，不是真正產品的consumer. 我不喜歡的是，強迫使用產品的用戶edit xml.

@test
可以下載啊，我剛試過。每本書的標題本身是個link,比如第一本 1. thinking in java。書名本身是個link可以點。點擊之后帶到skydrive上。左上角有個“下載”，或者點擊“添加說明”上面那個圖標也行。你再check一下？

當然可以轉載，呵呵。

@隨波逐流
哈哈，我用BlogJava保存筆記和網頁

請教，有句沒看懂
WorkItemDAO workItemDAO=(WorkItemDAO)Container.getBean("workItemDAO");
這個為什么不是注射進來的呢？

覺得你“接下來的做法”和“現在的做法”沒啥區別啊，呵呵，就是沒有封裝private方法，而是單弄了類。

張小慶的故事挺好的，不希望故事結局太灰暗。樓主牛人，給程序員們些念想吧，呵呵。

你說的是JDK的JPDA遠程debug方式，如果你的開發環境在本地，可以用jetty. http://m.tkk7.com/vcycyv/archive/2011/02/13/344214.html
這里有介紹

很奇怪，這篇blog點擊率高的離譜，你們是怎么看到這個blog的？我之前的blog每天最多一千出頭的點擊率，這篇24小時內到四千多了，真的困惑。

@@joe
像checkstyle這樣的工具是用來定義代碼標準的。但這肯定遠遠不夠。比較死的規矩，checkstyle可以定義。 但跟design相關的東西，就不可能有標準了。偏偏design是最最影響產品質量的因素。
1. 最最基本的標準是coding convention.我一直在建議團隊follow這個 http://geosoft.no/development/javastyle.html ，我覺得比Sun的好。
2. 再上一層就是checkstyle之類的工具。其實eclipse自帶的工具就已經很好了。
3. 再上一層就是domain的設計了。設計合理很重要，團隊里每個人都理解認同設計同樣重要。
我之前在團隊里推廣Eric Evans的Domain Driven Design那本書，這是近兩年對自己影響最大的一本書。大伙兒在design的時候能有一些共同認可的基礎，不至于討論得天馬行空。另外注意，趕工是影響質量的最大因素。

頂好文！
垂直劃分產品也比較符合有技術熱情的員工的愿望。
技術選型除了看技術的先進性之外，應用廣泛程度也需要考量。先驅很偉大，但trouble shooting都要自己研究。更成熟（老）的技術有很多資源可以利用和借鑒，背后成熟的社區也挺重要的。
強大的測試工具框架為開發人員提供了測試的規范性和便利性 -- 這正是俺想要提高的地方
期待更多好文！

@Jonathank
呵呵，Martin大叔也沒把transaction script一棒子打死吧

@@joe
對索引加外鍵還是對外鍵加索引？

@simaliu
建了外鍵反應并保證了業務邏輯，也沒實現業務邏輯。應用層的業務邏輯該怎么寫還是怎么寫啊。外鍵保證了業務邏輯沒有數據不一致的漏洞。現實地說，業務邏輯往往容易忽略并發情況，而并發情況容易造成數據不一致。

不錯!