近半年的工作心得，摘录如下：
( 2月 20 日-- 2月 26 日)
工作心得
一．Ajax通过POST提交给$_POST数组变量问题：
和js人员一块调试ajax提交一些数据的时候，在ajax调用的时候，js人员通过Post方式传给我一个'allowComment',它为True\false，刚开始误以为是一个TRUE 或 FALSE是PHP里面的一个布尔值（实际是一个字符串），于是写下如下代码片段：
if(true == $_POST['allowComment'])
{
$this->_par['allow_comment'] = 0;//0为允许评论
}else
{
$this->_par['allow_comment'] = 1;
}
导致出现无论post过来的数据是true还是false，只走if不走else，当时很奇怪，我通过print_r()来打印看到明明是false，但是还是不走else这条路，最后听建鑫说它是个字符串，我于是改用var_dump()函数来看：var_dump($_POST)发现它其实就是个string类型的字符串：string(4) "ture"，不是布尔型的一个变量。而修改为：(引号引起来即可)
if(‘true’ == $_POST['allowComment'])
{
$this->_par['allow_comment'] = 0;//0为允许评论
}else
{
$this->_par['allow_comment'] = 1;
}
结论：尽管PHP是弱类型语言，但我们调试时候最好用var_dump(),而不是print_r();
二.DIV模板取高度自动适应的问题：
在做这次记录套页面的时候，提供的页面是一整张页面，这就需要php工程师去去掉里面的一些没有用的DIV标签和多余的html代码，但是在把最后剩下的一些HTML代码套好页面后，在放到pengyou里面测试时候，发现页面被遮挡，最后发现是由于刘嵩Js想取到一个DIV的高度没有得到正确的值，而这正是由于HTML设计人员把一整张页面让PHP开发人员去从里面提取出需要的东西，但是往往会出现某些DIV没有带到Smarty页面里渲染，才导致js在通过ID或者NAME去取高度时候出错，也就是PHP工程师套页面的时候并不知道UI提供的页面中哪些DIV是JS人员必须要的，而UI人员就把整个页面给PHP工程师自己去剔掉多余的DIV和HTML,而刚好把JS需要的DIV给干掉了造成的.
结论：切页面得按照产品结构来，而不是仅仅UE，涉及到JS的得事先和PHP工程师和JS人员沟通。
三．接口变动问题：
一些底层接口的变动往往造成输入（入数据库）和输出（如：页面）出现一些明显的逻辑错误，于是我们首先会想可能是不是程序逻辑出现了问题，进一步去查程序代码的逻辑是否严密，会发现数据库里面出现一些和现实逻辑不同的情况，而很容易把陈脚搞乱，特别是有其它系统的介入，更让人很难发现其中错误。
结论：尽量少动接口返回的数据结构，保持结口稳定，而一旦改变，及时通知接口使用和开发方。
( 3月 6 日-- 3月 12 日)
工作心得
对重构的一点体会：
1.改进软件的结构：
在开发记录的时候有时由于一个新的需求导致为了更快的满足用户，不故到程序的整体结构，而这种解决方法不能以一个系统的角度来解决问题，如果任其发展会使代码的质量越来越难以维护，而重构能改善这个问题。
2.增加可读性：
以前的记录的数据层是由外包人员写的，让我觉得有点难懂，而有人说，修改别人的代码不如自己写，但事实上往往自己写的代码比上一个人还难以让别的人读懂，但是如果这个人有一天离职或者没有上班那就有些耗费时间去读懂对方的代码，而我们的重构可以通过一些命名规范和类的规范和层次结构的规范来尽量防止这类事情的发生，仅管我也参考了他们的代码。
3.及早地发现错误：
进行重构我们必须对项目的每一行代码的逻辑都了解，明确它的功能和上下程序调用关系，这样的理解我觉得有助于少犯错误和及时发现自己的错误。
4.提高了开发速度：
知道用户80%的需求的情况下，这种情况下重构，可能从一定程度上能提高开发速度。
( 3月 13 日-- 3月 19 日)
遇到一问题
在对记录的项目中进行重构的时候发现需要通过Ajax多提交一个POST变量到PHP那边去，发现不能随意加，而和js开发人员沟通了一下，结果是必须得修改一下js代码，把多提交的一个加进去才行,但是我个人觉得js的Ajax Post应该做得像表单提交数据那样，只要多加一个<input type=text id=”XXX” name=”XXX” value=”add_value”>数据加入<form></form>就可以对它POST提交到另一个PHP文件，而不是仅仅对一个单独的应用而写一个Ajax Post提交数据 ,不知能否改进成这样？
工作心得
1.
做项目最好先了解需求，然后明确需求，再思考用例，然后画数据流，最后才是数据库的设计，当然最后的数据库设计也是最重要的！
2.
对于一些定义分级和对应级别的少量数据最好放到PHP数组里面，而尽量不要放到数据库里，而对一些不是经常改动而却又是经常频繁查询用到的数据在量不是很在的情况下如放到数据库里面会显得成本太高,放到一个文本里变为一个配置文件来用效率可能会反而更高。
3.
对大并发和高访问的数据库设计解决方法现目前还是分表，如还不行，再Hash打散分库,但不能无限分，一个库尽量256表，动用4个库来也就分了1000个表左右，建鑫的经验告诉这样可能性能和稳定性相对高一些，而不能随意乱分。不知按时间或者天数来分表这种情况会有什么样的问题，期待通过人缘项目来尝试一下。
2009-03-20 ----2009-03-26:
遇到一问题
工作心得
对于上次邮件里面讨论到的PHP BOM问题，我来说来句就当心得吧，其实这个BOM问题一直在我们进行开发的时候经常出现，前些日子在企业邮箱里面第一次遇到这个问题，当时好像是企业的图标LOGO没有办法显示出来，因为<img src="img.php">,是img.php去读一个图片的内容然后给img显示，经过长仔细排查出现在输出图片资源前就有输出，那时候用的是notepad+editplus,最后用Zend studio来看这个文件头出现一个锘�字，证明了该问题。
第二次遇到BOM问题，是陈鑫鑫在纸条项目里面输出XML数据到IE浏览器中展现出现XML错误。
第三次也就是我们的记录APP调用外部接口返回用户的昵称出现乱码，经琳琳查也由BOM造成！
为何经常出现这种类似的问题，我看大家都在按照自己的方式来建立和开发PHP，特别是用Notepad来新建文件，系统默认在是ANSI格式，但我们的PHP编码是UTF-8的，于是又通过Notepad的另存为修改为UTF-8格式的，这样也就产生了一个BOM,最后，再用现在统一的开发工具Zend for eclipse去编辑这个带BOM的PHP文件，但BOM依然存在文件当中，它一般是表现不出任何问题，但一旦在页面前不能有输出的情况：如上面我遇到的三种情况它也就显现出来了。
BOM如此讨厌，该如何避免：
建议：
1. 切实统一开发工具：统一用Zend for eclipse 来新建PHP文件，和修改PHP文件编码！
2. 在项目完成后对目录里面所有的PHP 文件进行遍历驱出有可能出现的BOM。如：用sed批量替换掉bom：（syscore目录和所有下级目录的PHP文件替换） find ./syscore -type f -name "*.php" -exec sed -i '1s/^\xef\xbb\xbf//' {} \;
(3月27日---4月2日)
遇到一问题：
在调试记录的js时发现超过了页数却没有出现翻页导航的页，开始首先以为是数据没有输出程序的问题， 最后查明是由于朋友下面的frame把下面给档住了,Js人员修正了这个问题，这个问题还经常出现,希望js人员也多注意一下！
工作心得：
本周收到老姜发的一点对PHP框架的看法，我也斗胆也说说我自己对这个问题的看法，有些可能说得不太准确或者有些错误，还望包含：
首先，我个人是不反对ＰＨＰ采用一些轻量级的框架，但极力反对对ＰＨＰ用一些重型的框架的，为什么呢？因为它的执行方式决定了它的这个特点：php每一个脚本先全部载入所有资源，执行完毕后全部放弃，所以使用太重的框架，会极耗内存和计算资源，形成调用栈太深占用系统资源，个人觉得轻量框架和简单的分层还是一定要采用的。
其次，你会说像Java这样的语言它能采用一些的框架，而且还涌现出了一些红红火火的框架了呢：）
个人觉得那是因为java的执行方式和PHP不一样，对于内存管理也不一样，有很多都是一次装入内存，直到jvm重启才被释放的, 事务性，安全性等等很多基础性的服务，都需要预先装入，何况java是基于工业级应用产生的，php只是个人网站开发才出现的，能一样吗？不能。所以，不能我们也不要一边倒，看人家采用什么什么了，自己也想把PHP往边上套。
再次，C++和Java强悍的框架不少，但惨不忍睹的框架也更多，为什么呢？用一个越是尖端的东西越不容易用好，对于重型的编程语言对软件工程功底的要求是相当高的，不是谁说想做个框架就做个框架，更何况各个项目的千差万别，实际的情况也不尽一样，更不能以一个框架来以逸待劳，放大了框架的作用，它并不是万能的。
最后，我仅对ＰＨＰ的框架也就领悟到：轻量框架和简单的分层还是ＰＨＰ在大多数项目开发中还是一定要采用的，但切忌过重，把握好度，适可而止。
（4-10----4-16）
1.我们人缘项目需要对用户分数排序（降序）用户姓名（升序）排序，我们用了array_multisort函数来干这件事情：
[code]$data = array(‘待排数据’);
foreach ($data as $key => $row)
{
$score[$key] = $row['score'];
$name[$key] = $row['name'];
} [/code]
array_multisort($score, SORT_DESC, $name, SORT_ASC, $data);
然而在实际排序中发生了和预期的不相符，最后经过排查发现：
Space框架对展现层和数据输出为utf8编码，而中间没有展现和过渡层则是GBK编码，而我们的人缘项目需要在Modle层的PHP文件是GBK编码时候对输出姓名进行排序，而我们在Modle层调用姓名接口返回是utf8编码返回，而我们的Modle层文件是gbk的编码，这就导致一个问题，我们在用array_multisort对姓名排序时候发现排除来的中文顺序不对，而自己做实验出来的结果是正确的时因为我们的代码都是GBK的，发现是由于文件编码和接口输出编码不一致导致的，为了解决该问题，我们先将接口返回的UTF8的编码进行转GBK码，而后通过array_multisort排完顺序后再转回来，这样一个过程多少感觉有些怪异!
2.space编码中有UTF8和GBK在各个层次中不同有什么特别的好处吗？这样做对与问题1来说比较奇怪！
（4-24---4-30）
心得体会：
我就谈谈今天上午讲记录整体架构过程中个人的一些体会吧，我开始觉得要讲清楚记录这个APP的整体架构似乎很简单，但是在短时间准备过程中发现真要讲解清楚我们的记录的各个情况真不知道从如何下手，发现要讲清楚记录这个项目让听众能从不明白到了解还真需要一些技巧和经验的积累，还好在计算机软件领域早以有UML建模等相关的知识来描述相关的事情，已经形成一门专门的知识体系，站在前人的肩膀上可能更能少走弯路，但我也是第一次讲解，经验缺乏，但凡万事开头难，还好在建鑫的指点帮助下，以及以前我也参加了前段时间的项目评审会的耳濡目染，感悟评审团在评审的时候其实对于如何编写程序如何具体实现某个功能并不是很太在意，而是在意的那几张图（用例图，流程图，数据流图）和设计的可行性罢了，而其实这写图已经帮我们从不同的角度和视野来看这个软件体系给予有层次性和逻辑性的展现出来了，最后，再加上数据库的整体设计（索引大致情况）和程序分层目录结构的部署等，如果讲得很有条理和逻辑清楚那这个系统基本上已经可以付诸编码实施开发了，但是我的这次讲解刚好相反，是设计好了，然后我再去讲解，离真去从无到有还很有差距，但这也是对自己的一次很好的锻炼，还是有所提高和得到一些收获，同时也非常感谢建鑫给我这次讲解整体架构的机会，谢谢。
向东( 5月 1 日-- 5月 7 日)的周报
遇到一问题：
今天调试博客绑定发送feed需要对其标题和内容作关键字过滤，发现Pengyou的过滤程序对我提供的高敏感的词返回值有误同时也没有给过滤掉，进过查看对应的Pengyou 的svn过滤的代码几经多个人改动那个过滤函数进而改动引出新Bug，同时发现space的过滤函数和app的过滤函数写得何其相似，功能几乎相近：都是对高敏感返回0，直接传地址返回空字串；低敏感返回2，把里面的敏感词替换为***；然后传地址返回整个内容；在没有任何敏感的情况return 1，返回正常的字符串，这样的过滤代码在APP的公共代码lib库里面也有一份，代码大致一样，我在想这两个几乎一样的需求和流程能否封装为一个公共的关键字过滤的服，抽离出来对不同的应用相似的逻辑进而选一个服务，把关键词基础库和各个业务的特殊字库都做在服务里面，低耦合，高内聚的形式来提供整个关键字过滤服务，这样做理论上可能会更让人容易理解和便于调用和bug的排查，同时维护成本也相对小一些，个人建议，仅供参考。
( 05月08 日 -- 05月 14日)
心得体会：
对于本周上线后测试出的一个Bug的界定很难，很多在测试机上测试正常，但是上线后就往往发生很多意想不到的问题，测试往往发生很多测试环境没有发生的问题进而提出Bug，而一个项目是由若干个子项目构成的，子项目相互调用接口进而完成一个服务，而数据就在这个接口之间流动，而接口的规范和到底是哪个接口出现的问题界定往往在外网真实环境在缺乏权限的情况下测试人员测试出来的Bug最难以界定是哪一个环节出了问题，而各个小组也很难上线上去调试查询，觉得这里面可能要是需要提供一些日志来记录各个接口的数据传输状况类似于PHPUNIT的日志系统，单独出来一台机器和外网并行任意包含外网某个代码片段（接口），进而做成一个线上日志系统，可供线下进行分析，或者线上提供一个功能强大的日志函数，在线下很难查到问题的情况下进行把数据接口的数据输入并能以很低的权限让查找Bug的人员观察，进而做出准确定位和界定Bug，做出及时的判断，进而分发Bug给相关人等去查证，而由于这个系统是按照一定的结构构成而分给的相关人可以很轻易看到他的接口出现什么问题，进而跟踪问题所在，毕竟模拟真实生产环境如果缺少一个很好的架构体系来支撑整个业务流程而不是仅仅有经验的技术人员来估计问题所在而后分发提案让相关人员在去合围Bug，但这里面缺乏Bug的定位（由于在线上：很可能线下正常，线上的环境出现异常等情况，查找较为困难）的高效方法这样的沟通估计效率可能不是太高，但不得不佩服经验对于Bug的定位确实起到了相当大的作用。
如要转载：请标明出处，谢谢！ 向东 （2009-5-7）
关于json里怎么传bool类型，csdn有一篇文章：
ajax中使用json传递数据时，其它数据类型都不是问题，但是如果服务器端生成的JSON中有bool类型的数据时，到客户端解析时出现了小小的问题，总结如下：
服务器返回的JSON为：
{"TypeID":[1037],"Title":"河北软件职业技术学院","Intro":"","IsLink":"false","LinkUrl":"http://www.hbsi.edu.cn","IsPic":"true","Picture":"/newsimages/hbsi.jpg","Content":"<p><br></p>"}
其中属性：IsLink和IsPic都是bool类型，在客户端使用方法：
document.getElementById("checkbox1").checked = news.IsLink;会选中复选框，但是IsLInk为false，本不应该选中，为什么呢？
查其原因，javascript 有三种基本数据类型（字符串string、数值number、布尔boolean ），两种引用数据类型（对象Object、数组Array）和两种特殊数据类型（Null 、Undefined ）。其它类型向bool类型转换时的有如下原则：
数据类型 转换为bool后的值 null FALSE undefined FALSE Object TRUE function TRUE 0 FALSE 1 TRUE 0、1之外的数字 TRUE 字符串 TRUE ""(空字符串) FALSE
此时，IsLink在JSON中为字符串“false”，所以转换后得到bool类型true。
处理办法：
document.getElementById("checkbox1").checked = news.IsLink==“true";
( 2月 20 日-- 2月 26 日)
工作心得
一．Ajax通过POST提交给$_POST数组变量问题：
和js人员一块调试ajax提交一些数据的时候，在ajax调用的时候，js人员通过Post方式传给我一个'allowComment',它为True\false，刚开始误以为是一个TRUE 或 FALSE是PHP里面的一个布尔值（实际是一个字符串），于是写下如下代码片段：
if(true == $_POST['allowComment'])
{
$this->_par['allow_comment'] = 0;//0为允许评论
}else
{
$this->_par['allow_comment'] = 1;
}
导致出现无论post过来的数据是true还是false，只走if不走else，当时很奇怪，我通过print_r()来打印看到明明是false，但是还是不走else这条路，最后听建鑫说它是个字符串，我于是改用var_dump()函数来看：var_dump($_POST)发现它其实就是个string类型的字符串：string(4) "ture"，不是布尔型的一个变量。而修改为：(引号引起来即可)
if(‘true’ == $_POST['allowComment'])
{
$this->_par['allow_comment'] = 0;//0为允许评论
}else
{
$this->_par['allow_comment'] = 1;
}
结论：尽管PHP是弱类型语言，但我们调试时候最好用var_dump(),而不是print_r();
二.DIV模板取高度自动适应的问题：
在做这次记录套页面的时候，提供的页面是一整张页面，这就需要php工程师去去掉里面的一些没有用的DIV标签和多余的html代码，但是在把最后剩下的一些HTML代码套好页面后，在放到pengyou里面测试时候，发现页面被遮挡，最后发现是由于刘嵩Js想取到一个DIV的高度没有得到正确的值，而这正是由于HTML设计人员把一整张页面让PHP开发人员去从里面提取出需要的东西，但是往往会出现某些DIV没有带到Smarty页面里渲染，才导致js在通过ID或者NAME去取高度时候出错，也就是PHP工程师套页面的时候并不知道UI提供的页面中哪些DIV是JS人员必须要的，而UI人员就把整个页面给PHP工程师自己去剔掉多余的DIV和HTML,而刚好把JS需要的DIV给干掉了造成的.
结论：切页面得按照产品结构来，而不是仅仅UE，涉及到JS的得事先和PHP工程师和JS人员沟通。
三．接口变动问题：
一些底层接口的变动往往造成输入（入数据库）和输出（如：页面）出现一些明显的逻辑错误，于是我们首先会想可能是不是程序逻辑出现了问题，进一步去查程序代码的逻辑是否严密，会发现数据库里面出现一些和现实逻辑不同的情况，而很容易把陈脚搞乱，特别是有其它系统的介入，更让人很难发现其中错误。
结论：尽量少动接口返回的数据结构，保持结口稳定，而一旦改变，及时通知接口使用和开发方。
( 3月 6 日-- 3月 12 日)
工作心得
对重构的一点体会：
1.改进软件的结构：
在开发记录的时候有时由于一个新的需求导致为了更快的满足用户，不故到程序的整体结构，而这种解决方法不能以一个系统的角度来解决问题，如果任其发展会使代码的质量越来越难以维护，而重构能改善这个问题。
2.增加可读性：
以前的记录的数据层是由外包人员写的，让我觉得有点难懂，而有人说，修改别人的代码不如自己写，但事实上往往自己写的代码比上一个人还难以让别的人读懂，但是如果这个人有一天离职或者没有上班那就有些耗费时间去读懂对方的代码，而我们的重构可以通过一些命名规范和类的规范和层次结构的规范来尽量防止这类事情的发生，仅管我也参考了他们的代码。
3.及早地发现错误：
进行重构我们必须对项目的每一行代码的逻辑都了解，明确它的功能和上下程序调用关系，这样的理解我觉得有助于少犯错误和及时发现自己的错误。
4.提高了开发速度：
知道用户80%的需求的情况下，这种情况下重构，可能从一定程度上能提高开发速度。
( 3月 13 日-- 3月 19 日)
遇到一问题
在对记录的项目中进行重构的时候发现需要通过Ajax多提交一个POST变量到PHP那边去，发现不能随意加，而和js开发人员沟通了一下，结果是必须得修改一下js代码，把多提交的一个加进去才行,但是我个人觉得js的Ajax Post应该做得像表单提交数据那样，只要多加一个<input type=text id=”XXX” name=”XXX” value=”add_value”>数据加入<form></form>就可以对它POST提交到另一个PHP文件，而不是仅仅对一个单独的应用而写一个Ajax Post提交数据 ,不知能否改进成这样？
工作心得
1.
做项目最好先了解需求，然后明确需求，再思考用例，然后画数据流，最后才是数据库的设计，当然最后的数据库设计也是最重要的！
2.
对于一些定义分级和对应级别的少量数据最好放到PHP数组里面，而尽量不要放到数据库里，而对一些不是经常改动而却又是经常频繁查询用到的数据在量不是很在的情况下如放到数据库里面会显得成本太高,放到一个文本里变为一个配置文件来用效率可能会反而更高。
3.
对大并发和高访问的数据库设计解决方法现目前还是分表，如还不行，再Hash打散分库,但不能无限分，一个库尽量256表，动用4个库来也就分了1000个表左右，建鑫的经验告诉这样可能性能和稳定性相对高一些，而不能随意乱分。不知按时间或者天数来分表这种情况会有什么样的问题，期待通过人缘项目来尝试一下。
2009-03-20 ----2009-03-26:
遇到一问题
工作心得
对于上次邮件里面讨论到的PHP BOM问题，我来说来句就当心得吧，其实这个BOM问题一直在我们进行开发的时候经常出现，前些日子在企业邮箱里面第一次遇到这个问题，当时好像是企业的图标LOGO没有办法显示出来，因为<img src="img.php">,是img.php去读一个图片的内容然后给img显示，经过长仔细排查出现在输出图片资源前就有输出，那时候用的是notepad+editplus,最后用Zend studio来看这个文件头出现一个锘�字，证明了该问题。
第二次遇到BOM问题，是陈鑫鑫在纸条项目里面输出XML数据到IE浏览器中展现出现XML错误。
第三次也就是我们的记录APP调用外部接口返回用户的昵称出现乱码，经琳琳查也由BOM造成！
为何经常出现这种类似的问题，我看大家都在按照自己的方式来建立和开发PHP，特别是用Notepad来新建文件，系统默认在是ANSI格式，但我们的PHP编码是UTF-8的，于是又通过Notepad的另存为修改为UTF-8格式的，这样也就产生了一个BOM,最后，再用现在统一的开发工具Zend for eclipse去编辑这个带BOM的PHP文件，但BOM依然存在文件当中，它一般是表现不出任何问题，但一旦在页面前不能有输出的情况：如上面我遇到的三种情况它也就显现出来了。
BOM如此讨厌，该如何避免：
建议：
1. 切实统一开发工具：统一用Zend for eclipse 来新建PHP文件，和修改PHP文件编码！
2. 在项目完成后对目录里面所有的PHP 文件进行遍历驱出有可能出现的BOM。如：用sed批量替换掉bom：（syscore目录和所有下级目录的PHP文件替换） find ./syscore -type f -name "*.php" -exec sed -i '1s/^\xef\xbb\xbf//' {} \;
(3月27日---4月2日)
遇到一问题：
在调试记录的js时发现超过了页数却没有出现翻页导航的页，开始首先以为是数据没有输出程序的问题， 最后查明是由于朋友下面的frame把下面给档住了,Js人员修正了这个问题，这个问题还经常出现,希望js人员也多注意一下！
工作心得：
本周收到老姜发的一点对PHP框架的看法，我也斗胆也说说我自己对这个问题的看法，有些可能说得不太准确或者有些错误，还望包含：
首先，我个人是不反对ＰＨＰ采用一些轻量级的框架，但极力反对对ＰＨＰ用一些重型的框架的，为什么呢？因为它的执行方式决定了它的这个特点：php每一个脚本先全部载入所有资源，执行完毕后全部放弃，所以使用太重的框架，会极耗内存和计算资源，形成调用栈太深占用系统资源，个人觉得轻量框架和简单的分层还是一定要采用的。
其次，你会说像Java这样的语言它能采用一些的框架，而且还涌现出了一些红红火火的框架了呢：）
个人觉得那是因为java的执行方式和PHP不一样，对于内存管理也不一样，有很多都是一次装入内存，直到jvm重启才被释放的, 事务性，安全性等等很多基础性的服务，都需要预先装入，何况java是基于工业级应用产生的，php只是个人网站开发才出现的，能一样吗？不能。所以，不能我们也不要一边倒，看人家采用什么什么了，自己也想把PHP往边上套。
再次，C++和Java强悍的框架不少，但惨不忍睹的框架也更多，为什么呢？用一个越是尖端的东西越不容易用好，对于重型的编程语言对软件工程功底的要求是相当高的，不是谁说想做个框架就做个框架，更何况各个项目的千差万别，实际的情况也不尽一样，更不能以一个框架来以逸待劳，放大了框架的作用，它并不是万能的。
最后，我仅对ＰＨＰ的框架也就领悟到：轻量框架和简单的分层还是ＰＨＰ在大多数项目开发中还是一定要采用的，但切忌过重，把握好度，适可而止。
（4-10----4-16）
1.我们人缘项目需要对用户分数排序（降序）用户姓名（升序）排序，我们用了array_multisort函数来干这件事情：
[code]$data = array(‘待排数据’);
foreach ($data as $key => $row)
{
$score[$key] = $row['score'];
$name[$key] = $row['name'];
} [/code]
array_multisort($score, SORT_DESC, $name, SORT_ASC, $data);
然而在实际排序中发生了和预期的不相符，最后经过排查发现：
Space框架对展现层和数据输出为utf8编码，而中间没有展现和过渡层则是GBK编码，而我们的人缘项目需要在Modle层的PHP文件是GBK编码时候对输出姓名进行排序，而我们在Modle层调用姓名接口返回是utf8编码返回，而我们的Modle层文件是gbk的编码，这就导致一个问题，我们在用array_multisort对姓名排序时候发现排除来的中文顺序不对，而自己做实验出来的结果是正确的时因为我们的代码都是GBK的，发现是由于文件编码和接口输出编码不一致导致的，为了解决该问题，我们先将接口返回的UTF8的编码进行转GBK码，而后通过array_multisort排完顺序后再转回来，这样一个过程多少感觉有些怪异!
2.space编码中有UTF8和GBK在各个层次中不同有什么特别的好处吗？这样做对与问题1来说比较奇怪！
（4-24---4-30）
心得体会：
我就谈谈今天上午讲记录整体架构过程中个人的一些体会吧，我开始觉得要讲清楚记录这个APP的整体架构似乎很简单，但是在短时间准备过程中发现真要讲解清楚我们的记录的各个情况真不知道从如何下手，发现要讲清楚记录这个项目让听众能从不明白到了解还真需要一些技巧和经验的积累，还好在计算机软件领域早以有UML建模等相关的知识来描述相关的事情，已经形成一门专门的知识体系，站在前人的肩膀上可能更能少走弯路，但我也是第一次讲解，经验缺乏，但凡万事开头难，还好在建鑫的指点帮助下，以及以前我也参加了前段时间的项目评审会的耳濡目染，感悟评审团在评审的时候其实对于如何编写程序如何具体实现某个功能并不是很太在意，而是在意的那几张图（用例图，流程图，数据流图）和设计的可行性罢了，而其实这写图已经帮我们从不同的角度和视野来看这个软件体系给予有层次性和逻辑性的展现出来了，最后，再加上数据库的整体设计（索引大致情况）和程序分层目录结构的部署等，如果讲得很有条理和逻辑清楚那这个系统基本上已经可以付诸编码实施开发了，但是我的这次讲解刚好相反，是设计好了，然后我再去讲解，离真去从无到有还很有差距，但这也是对自己的一次很好的锻炼，还是有所提高和得到一些收获，同时也非常感谢建鑫给我这次讲解整体架构的机会，谢谢。
向东( 5月 1 日-- 5月 7 日)的周报
遇到一问题：
今天调试博客绑定发送feed需要对其标题和内容作关键字过滤，发现Pengyou的过滤程序对我提供的高敏感的词返回值有误同时也没有给过滤掉，进过查看对应的Pengyou 的svn过滤的代码几经多个人改动那个过滤函数进而改动引出新Bug，同时发现space的过滤函数和app的过滤函数写得何其相似，功能几乎相近：都是对高敏感返回0，直接传地址返回空字串；低敏感返回2，把里面的敏感词替换为***；然后传地址返回整个内容；在没有任何敏感的情况return 1，返回正常的字符串，这样的过滤代码在APP的公共代码lib库里面也有一份，代码大致一样，我在想这两个几乎一样的需求和流程能否封装为一个公共的关键字过滤的服，抽离出来对不同的应用相似的逻辑进而选一个服务，把关键词基础库和各个业务的特殊字库都做在服务里面，低耦合，高内聚的形式来提供整个关键字过滤服务，这样做理论上可能会更让人容易理解和便于调用和bug的排查，同时维护成本也相对小一些，个人建议，仅供参考。
( 05月08 日 -- 05月 14日)
心得体会：
对于本周上线后测试出的一个Bug的界定很难，很多在测试机上测试正常，但是上线后就往往发生很多意想不到的问题，测试往往发生很多测试环境没有发生的问题进而提出Bug，而一个项目是由若干个子项目构成的，子项目相互调用接口进而完成一个服务，而数据就在这个接口之间流动，而接口的规范和到底是哪个接口出现的问题界定往往在外网真实环境在缺乏权限的情况下测试人员测试出来的Bug最难以界定是哪一个环节出了问题，而各个小组也很难上线上去调试查询，觉得这里面可能要是需要提供一些日志来记录各个接口的数据传输状况类似于PHPUNIT的日志系统，单独出来一台机器和外网并行任意包含外网某个代码片段（接口），进而做成一个线上日志系统，可供线下进行分析，或者线上提供一个功能强大的日志函数，在线下很难查到问题的情况下进行把数据接口的数据输入并能以很低的权限让查找Bug的人员观察，进而做出准确定位和界定Bug，做出及时的判断，进而分发Bug给相关人等去查证，而由于这个系统是按照一定的结构构成而分给的相关人可以很轻易看到他的接口出现什么问题，进而跟踪问题所在，毕竟模拟真实生产环境如果缺少一个很好的架构体系来支撑整个业务流程而不是仅仅有经验的技术人员来估计问题所在而后分发提案让相关人员在去合围Bug，但这里面缺乏Bug的定位（由于在线上：很可能线下正常，线上的环境出现异常等情况，查找较为困难）的高效方法这样的沟通估计效率可能不是太高，但不得不佩服经验对于Bug的定位确实起到了相当大的作用。
如要转载：请标明出处，谢谢！ 向东 （2009-5-7）
关于json里怎么传bool类型，csdn有一篇文章：
ajax中使用json传递数据时，其它数据类型都不是问题，但是如果服务器端生成的JSON中有bool类型的数据时，到客户端解析时出现了小小的问题，总结如下：
服务器返回的JSON为：
{"TypeID":[1037],"Title":"河北软件职业技术学院","Intro":"","IsLink":"false","LinkUrl":"http://www.hbsi.edu.cn","IsPic":"true","Picture":"/newsimages/hbsi.jpg","Content":"<p><br></p>"}
其中属性：IsLink和IsPic都是bool类型，在客户端使用方法：
document.getElementById("checkbox1").checked = news.IsLink;会选中复选框，但是IsLInk为false，本不应该选中，为什么呢？
查其原因，javascript 有三种基本数据类型（字符串string、数值number、布尔boolean ），两种引用数据类型（对象Object、数组Array）和两种特殊数据类型（Null 、Undefined ）。其它类型向bool类型转换时的有如下原则：
数据类型 转换为bool后的值 null FALSE undefined FALSE Object TRUE function TRUE 0 FALSE 1 TRUE 0、1之外的数字 TRUE 字符串 TRUE ""(空字符串) FALSE
此时，IsLink在JSON中为字符串“false”，所以转换后得到bool类型true。
处理办法：
document.getElementById("checkbox1").checked = news.IsLink==“true";
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：https://jackxiang.com/post/1699/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
最后编辑： jackxiang 编辑于2014-9-17 16:22
[404判断]CURL处理返回page not found 404页面的
arsort排序规则评论列表
