EAD: Bandit Johnson

［zt］用户体验的量化 - [项目开发技术]

用户体验（User Experience）这个词应该是已经流行很久了，我刚刚参加工作的时候，我们公司的美工叫UX Engineer而非Designer，听起来好像很NB的样子，但是，我们也知道UX远非页面设计这么简单。下面是WikiPedia对于User Experience的定义：

User experience, most often abbreviated UX, but sometimes UE, is a term used to describe the overarching experience a person has as a result of their interactions with a particular product or service, its delivery, and related artifacts, according to their design.

有工程想法的人都很喜欢Metric或者Measure这个说法，那么用户体验如何衡量呢（具体到Web应用）？可以参照这篇文章看看...

应用的性能考虑 - [项目开发技术]

今天看了一篇庄伟表的博文，说的是上周博文视点在上海的OpenParty的演讲，我之前收到过相关的邮件，但是，周末要陪孩子，就没有办法去参加，有点可惜了。

个人很认同庄的观点：

架构设计需要关注需求，而需求有两大部分 ，一部分是与业务相关的需求，另一部分是与业务无关的需求。
与业务无关的需求，包括可重用性、高性能、可靠性、易用性、安全性等等。
经典的GoF的设计模式，其实只解决了（甚至只能说部分解决了）可重用性的需求。

前端时间小D他们接了一个项目，对于站点的性能要求很高，我帮着出了一些主意，不过，感觉上却是有点力不从心，因为，自己也是很久没有关注性能方面的问题了。前面公司作的项目不是web应用，性能上的调整走的是前台/后台简单缓存的路子，还没有用具体的memcache的软件。希望回头小D回来，能给点经验介绍，也让我好好学习一下。

今天上午查了查，在JavaEye上找到了一篇不错的文章，讨论架构上针对性格的应用选择，可以看看。不过，具体的提升，不做项目，还是不行阿...

PS，我不想做个远离底层开发的PM，还是需要找机会好好补课。

又见推荐Pragmatic系列的书 - [项目开发技术]

订阅徐宥的博客应该就是最近的事情，应该是查询VIM的时候找到的，之前虽然也看到过，但是没有仔细的读完。订阅了之后，把他近期的博文都读过了，深有感触。

今天在家又在9点上看到他的一篇文章，讲述编程内容的，提到了四本书，分别是：

1. 《Pragmatic Programmer》
2. 《The Art of UNIX Programming》
3. 《Elements of Programming Style》
4. 《The Productive Programmer》

其中，第一，第四是我一直欣赏的，个人也觉得是写给所有做开发的中级人员的必读书目。对于第二和第三，也是早有耳闻，不过，一直没有仔细的读过。个人感觉三可能有相应的替代品，例如最近出版的《Implement Patterns》/《Complete Code》，目前的状态不是很好，可能不会有时间，备忘一下吧。至于第二本，有中文版本，看看09年能不能读完吧。

[zt]软件负债 - [项目开发技术]

负债是个不被人喜欢的名词，同时，也是一个不愿意被别人知道的情况。在软件开发行业，更是如此。没有一个ISP愿意承认自己的产品开发过程中有软件负债，那些高管们企图通过更好的计划，更详尽的流程等等来跟踪，衡量，像个皇帝新衣里的皇帝一样的把project里面的完成度改成100%，而没有能力或者不愿意去看看背后到底有没有技术负债...

最近这方面的感慨实在是太多了，正好今天看到了这篇文章，备忘一下，以后可能用得到。

作者认为软件债务由以下5个部分构成：

• 技术债务：现在不去做、没有完成的事情，将会在未来对开发工作产生负面影响。
• 质量债务：难以验证整个系统的功能和技术质量。
• 配置管理债务：集成和版本发布管理变得更具风险、复杂，而且更易于出错。
• 设计债务：要想加入一般复杂度的功能，其成本不断增加，并超出如果从头开发要付出的成本。
• 平台经验债务：能够开发系统功能的人力资源受限。

[FW]SOA参考资料 - [项目开发技术]

前几天被人问道过SOA的东西，好久没有好好关注了，今天在INFOQ上看到了一篇文章，介绍了OPENSOURCE的SOA BOOK，备注一下，后面可能用得到。:)

Productive Programmer Vs Pragmatic Programmer - [项目开发技术]

买回来《卓有成效的程序员》/《Productive Programmer》没有几天就读完了，一是因为自己读过英文版的前面若干章和INFOQ上的迷你版本，二是自己在最近几年的开发过程中，也切实的理解和认同其中的很多观点，虽然，应用的广度和深度不如Neal，但是，背后的想法却是一样的。说实在话，最新的图形界面、IDE等等，确实把很多背后的东西屏蔽给了一代人；就像从最开始的JSP MODEL1/MODEL2走过来的我们，现在看到Spring、Hibernate，更容易理解这些框架背后想要解决的问题，以及自己曾经做过的努力与之的差距，也相对比较容易看到为什么要这么做。

具体的内容，以及每个人看完之后的体会，我想肯定会因人而异。但是，对我个人而言，这本书与另外一本缩略也是PP的Pragmatic Programmer的一样，给我很大的触动。如果说Pragmatic Programmer是为我掀开了20年前的程序员的开发方式，引导我学习Vim/Python的话，那么这本PP就更加让我坚定了这条路，同时，又往这条路上增加了很多新的工具(Ruby?/Regex/DSL...)，同时，又加深了对于背后原则的理解。

强烈建议每个做开发的程序员，好好的读读这两本PP的书，当然，如果你有机会跟拥有这些良好开发习惯的同事一起PP的话，你能够成长的更快...

我算不清楚了，我到了说了几个PP了。 ：）

使用VIM来进行JAVA开发的配置 - [项目开发技术]

http://articles.techrepublic.com.com/5100-10878_11-5054618.html
备忘一下。

谈IDE Vs Vim - [项目开发技术]

昨天，LEO说他想用IntelliJ IDEA，因为，他发现很多人都在用，而且，评价很高。那是阿，忘记在那一年，IDEA是得到过JOLT的IDE大奖，尤其是对于Refactoring的支持，可能在当今的JAVA IDE中间，仍然是没有出其右者。我在03年的时候，第一次接触它，就被它深深的折服...

但是，6年后的如今，可能，我更倾向于用VIM来进行代码的开发。俗语虽说“工欲善其事，必先利其器”，但是，很多时候，你所在的公司是没有，或者不会出钱买一个IDEA来让你玩的（如果是不注意版权保护的公司或者个人，那就不在讨论的范围里面）。与其把自己的期望值提高，还不如踏踏实实的来学习VIM和Shell script。

VIM有个Python的插件，比较容易的实现代码的重构，好像C／C＋＋也有类似的插件，JAVA还没有。后续的CE项目，我可以试验一下，用VIM来开发到底有多复杂...

今天看到有一篇讲解code refactoring的文章，谈到了利用find/sed来实现find/replace的，值得参考。

$ find . -name '*.cpp' -exec sed -i s/Foo/MyClass/ {} \;

推荐两篇不错的RIA开发经验总结 - [项目开发技术]

我自己意识到RIA这个说法，并跟一堆有干劲的年轻人一起基于JAVA作了一个产品，已经是6年前的事情了。当时犯了很多的错误，有一些是组织上的问题，但是，很多也是跟自己的经验和技术的不足密切相关。

今天又在INFOQ上看到MICHAEL CHAN的两篇介绍他作RIA的经验，确实不错，给我很多的启示。就如MICHAEL在文章中提到的，他从《大型多人在线游戏开发》书中获得了很多启示。文章中提到的经验，也不仅仅适用于RIA的开发，对于企业级应用开发的其他问题，也都有所裨益。

不大规模的写代码也有些时间了，不是什么好事情。手里的这个CE的项目，我可能只会REVIEW，但是，作完了还是要好好总结一下，跟其他人分享。

对了，那两篇文章的链接如下：

RIA原则与实践（上）（下）

编程的首要原则 - [项目开发技术]

很少在豆瓣9点看到技术类的感兴趣的文章，今天是第一次，看到了一篇讲“编程的首要原则”。原则上，讲原则的东西都是争抢眼球的。不过，积累一些争抢眼球的素材也是不错的。

本文是整理作者的一个帖子的回复，基本观点如下：

1. 获得最多认同的答案：

KISS - Keep It Simple Stupid

DRY - Don’t Repeat Yourself

2. 获得第二认同的答案：

写代码时时刻设想你就是将来要来维护这坨代码的人

3. 一些众所不一定周知的答案：

先弄清你的问题是什么！

个人非常认同这三点，其他的没有摘录过来并不能说不重要，但是，能够做到这三点已经非常不容易了。跟BOB大树在3P的那本书里提到的观点有异曲同工之妙。