人在江湖

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

@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://www.blogjava.net/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
建了外键反应并保证了业务逻辑，也没实现业务逻辑。应用层的业务逻辑该怎么写还是怎么写啊。外键保证了业务逻辑没有数据不一致的漏洞。现实地说，业务逻辑往往容易忽略并发情况，而并发情况容易造成数据不一致。

不错!