方法名中的add和set
浏览Java的API文档是很有意思的事情，比如说：HttpServletResponse。在HttpServletResponse里有三个比较有意思的方法：
public void addCookie(Cookie cookie)
public void setHeader(java.lang.String name, java.lang.String value)
public void addHeader(java.lang.String name, java.lang.String value)
先看addCookie，为什么这个方法叫addCookie呢？如果换到PHP里，很多都是定义为：
setCookie($name, $value, array $options)
那么到底是addCookie好？还是setCookie好呢？从阅读者的直觉上来看，一个set方法往往意味着给某个键设置某个值，在这里，键就是$name，值就是$value。既然是键，就说明其有唯一性，但对Cookie而言，$name是不具备唯一性的，比如说不同域下可以共存同名的Cookie，所以说单就名字而言，addCookie比setCookie更合理，以后大家起名时，不要set，add想用什么就用什么，多思考一下是有好处的。
再看看addHeader和setHeader，为什么会有两个看似一样的方法呢？不过换到PHP里，很多都是定义为：
setHeader($name, $value, $replace = true)
那么到底是一个方法好，还是分成两个方法好？这里先看看如果用一个方法的话，一般如何使用：
setHeader($name, $value, true)
setHeader($name, $value, false)
其中true表示重置先前同名header，false则不是重置，而是追加（用逗号分割，详见header函数）。
再看看如果用两个方法的话，情况如何：
setHeader 对应 setHeader($name, $value, true)
addHeader 对应 setHeader($name, $value, false)
对比二者的区别，如果单纯使用一个setHeader方法，方法参数里会出现一个布尔型参数，而使用两个方法的话，则是通过set，add这样的动词来区分方法含义的。从阅读者的角度看，任何时候，布尔型参数都是让人费解的，不能准确的用直觉去判断其含义，相对而言，用明确的词汇来描述方法意图更好。
Javascript中给select添加option
最容易想到方法是通过innerHTML来添加，代码如下：
<select id="select"></select>
<button id="button">Add</button>
<script>
document.getElementById("button").onclick = function() {
document.getElementById("select").innerHTML = "<option value="bar">foo</option>";
};
</script>
innerHTML使用起来非常方便，可惜这段代码虽然在Firefox里无恙，但是在IE里却不会正常运行，解决：
document.getElementById("select").options.add(new Option("foo", "bar"));
new Option([text], [value], [defaultSelected], [selected])
如果你想选中某项，应该使用selected，至于defaultSelected，它表示的是是否缺省选中，如果你使用reset重置功能的话，则有用。
如此一来，就兼容了Firefox和IE了。为了照顾IE这个差等生，习惯用Firefox的我们不得不多考虑一下。
顺手记录options常用的几种操作：
删除所有选项：<select>.options.length = 0;
删除当前选项：<select>.options.remove(<select>.selectedIndex);
获取当前值 ：<select>.options[<select>.selectedIndex].value;
获取当前文本：<select>.options[<select>.selectedIndex].text;
修改当前节点：<select>.options[index] = new Option("Text", "Value");
PHP领域对象都应该实现ArrayAccess
PHP里，领域对象是否值得使用，存争议，有的人认为在PHP里，使用数组是最佳实战；还有的人则认为随着复杂性的提高，领域对象是救命稻草。抛开细节，先看看两种方式调用时的最初印象，举个一般的例子：
数组：<h1><?php echo $article['title']; ?></h1>
对象：<h1><?php echo $article->getTitle(); ?></h1>
数组和对象的选择，不一定非得是二选一的结果，在项目开发初期，复杂度较低，此时更注重开发效率，使用数组是更好的选择，但是随着项目的演化，复杂度越来越高，此时更注重维护效率，使用对象是更好的选择。所以我们要是能够在二者之间自由切换就最好不过了。但从上面的代码可以看到，二者的使用方式存在较大差异，一旦切换，很多调用代码都要重写，所以，我们说PHP领域对象都应该实现ArrayAccess，如此一来，你可以通过数组方式来访问对象，切换就简单多了。
CRON环境变量问题
使用CRON，基本都遇到过环境变量问题，比如说某个命令没有找到，一般来说，都是建议使用完整的路径，以避免依赖系统的PATH环境变量，但其实重新设 置一下PATH之类的环境变量是很简单的，请看：
# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
写代码要细心
看一段PHP代码，设想一下它的输出结果，可以用来做面试题：
<?php if ($a = 100 && $b = 200) { var_dump($a, $b); } ?>
逻辑的层次划分
这个问题我印象中已经说过几次了，不过鉴于其重要性，再说一次也不嫌多。
在MVC中，单就M而言，逻辑分为两种：应用逻辑和领驭逻辑，不同的逻辑应该放在不同的层次，这样结构才清晰，比如说这个例子：我的CMS有个功能，有网友回复文章的话，则给文章作者发一封电子邮件通知他一下，同时因为有回复，说明文章受欢迎，就要给文章作者加适当的积分，以资鼓励。
上面的逻辑不算太复杂，但是编码时还是应该考虑逻辑分层，如果我们不分层的话，比如说，所有的逻辑都在控制器中完成，会有什么问题呢？假如现在我新加一个逻辑，如果用户使用手机上网，回复了文章的话，则不使用电子邮件通知，而使用手机短信通知作者，同时给文章作者加积分。由于我们把所有的逻辑都在控制器中实现了，所以其中的积分逻辑被重复实现了，把它单独划分成领域逻辑就会避免这个问题了。
