PHP的json数据编译和解译，字符编码无关。
这里只就PHP5.2.0+以上版本而言，因为JSON扩展是自PHP5.2.0才开始引入的。早期版本没有默认引入。
json现在应用比较广泛，主要是由于ajax技术的原因。json可以很方便的传输具有属性的数据格式，方便前端进行解析处理，更好的将数据流量传输降低并且也能使前后端尽可能的分离。
貌似自06年开始我在做的项目如果客户不强烈要求的情况下，我都会使用UTF-8进行编码开发，UTF-8开发会有很多好处，比如前、后端数据传输很方便无须额外的编码开销，另外储存的字符也比较直观，虽然有数据容量的浪费，但在目前储存如白菜价的环境下，容量问题应该不大。
在使用UTF-8编码的时候，json_encode/json_decode可以很方便的处理（虽然编译后的数据中的中文看起来很怪异，但因为也不需要直接使用数据所以也无所谓），因为PHP自带的json扩展库只支持UTF-8编码。
但有的时候客户强烈选择使用GBK/GB2312进行编码的情况下，自带的json就应付不了了。所有涉及到中文的经过编译后会变成null。 更多 »
百度和Google到底区别在哪里？
自打刚回到家里就感冒，这两天终于好了一些，现在已经不难受了，呆在家里整天看电视、看电影，要么就是研究一些无聊的东西。
最近一个实验站流量不错，自打服务器稳定后、域名更换为.com后，流量在慢慢的上升，甚至已经超过了另外的运行接近4年的小论坛。觉得很有意思，因为是实验目的比较大的，所以这几天也在琢磨原因。
有几个小发现：
１。服务器稳定性对于搜索引擎有影响，但未必是绝对的，当然前提是服务器不能长久（比如１个星期，呵呵）无法访问。这个影响最少应该不在收录，可能对于排名有点干扰。但只要网站内容独特，那么稳定后也一般可以恢复正常；
２。实验证明，.com效果要好于.cn。这个之前已经在很多运营交流站内被讨论过。无论Google还是百度，似乎都更偏好于.com（当然，我是指同等条件下的）。
３。百度更倾向实用性，Google更倾向技术性。这个无关谁强大或者谁更人性化。
看流量统计发现一个有趣的现象。
我的博客来自Google的占到接近95%的流量，百度仅仅为不到3%，甚至可能还不如Bing高。而我的另外一个站（生活内容为主）来自百度的接近 70%，Google约为20%。也许真的印证了一些做SEO的人的话：使用Google的多为做技术的，使用百度的多为非技术的……
只是一个无聊想想而已，我自己觉得，如果想做网站运营，那么就要脚踏实地的做好基础性的东西，比如结构、性能等等，慢慢的去积累内容，终究会有好看的流量的……
题外话，草根现在做网站运营真的越来越难了，难道ZF故意的……
巴西逆转美国3：2获得09年联合会杯冠军！
上半场，巴西明显赛前准备不足，有些轻敌，战术部署不坚决。反观美国准备工作做得很好，全队意识很明确。结果一上来就把巴西踢蒙了。这样的对比导致美国2：0领先上半场。
下半场，邓加一定是在更衣室做了详尽的部署。开场一上来明显感觉进攻意图很明确，虽然美国发挥的也不错，但仍旧被巴西超级逆转连进3球最终赢得比赛，值得一提的是，卡卡的一次射门，球已经完全过球门线了，但被裁判给吹了，很可惜！
巴西获得卫冕！美国也值得钦佩和尊敬！！ 更多 »
史上最郁闷、最点背的前锋
2009年中超第9轮，天津泰达主场迎战上海申花。
天津整场比赛技术统计，除了犯规和黄牌外，其他各项统计均高于申花。
但是运气差到整场16次射门仅仅得到一个进球，我汗，上赛季的金靴竟然浪费了5、6次机会~~~
压着申花打得泰达竟然被人先入一球，幸亏小将何杨头球扳平，否则又要延续对阵鲁能那场得势不得分的尴尬境地了。
比赛结束，申花仍旧没破除客场虫的记录，而泰达也仍旧没有破除对阵申花不胜的尴尬。
路易斯的估计是目前最点背的一个前锋了吧？！把球队的运气都给带背了，希望还是好好休息两场调整调整一下心态吧，这样下去对本人对球队对球迷都没什么好处哦。
左二你也该变变思路啦！！！别总盯着一个人看啊，张烁虽然不入其他前锋神勇，不过他灵光一现的时候还是可以造成很多威胁并给队友创造机会的，在大路目前状态低迷的情况下，不妨换换思路吧！
铁杵磨成针的经历
去年在北京的时候因要出去玩，有一个包包拿着不方便于是在超市买了个小的密码锁，然后锁住包包进行寄存。用途倒也挺大的，小锁头挺精致的。
用过之后，其实不知道如何重设密码也不清楚机理更没研究。一次攥在手里把玩的时候不小心把密码给重置了，汗！！然后也不知道密码怎么打开，一次闲置放在一边。偶然今天弟弟拿出来说锁头挺好的，可惜打不开了。我觉得也挺郁闷的，试了几次没弄开，极其恼火。 更多 »
对付骗子的一招巨爽的办法
memcache是个好东西
标题是个废话，不好就不会有那么多人用了。
一直在考虑利用PHP+mysql自己架构一个简单的类似memcache的简单应用，原理比较简单，基本可实现缓存的键值分配、过期的设置、数据的存储等等。功能上无非就是写入和读取。简单点说其实也就是利用一个查询的集去写入缓存。每次查询到公共部分的时候直接获取结果。这样虽然也是要经过数据库查询，但对于某些多次进行的相同查询的时候效果也是比较明显的。当然不会有类似memcache的分布式架构，仅仅是一个小型的应用，适用于不方便安装memcache的时候。属于项目级的一个数据层的小型缓存机制。可惜无法理解底层的内存操作技术，否则直接写入到内存可能效果会非常好，因为基于的功能仅仅为读、写没有memcache那么复杂的应用，应该效果会好一些^_^
尝试写了一下感觉还不错，呵呵，对于小型的项目应用自信还可以应付。最近状态不错。继续加油～～忙完手里的项目赶快忙自己的……
孤单中的寂寞
产品战略规划和产品规划
使命:公司为什么存在，你需要给出一个持久的事实。
愿景:公司希望发展成什么样子，用以指导公司战略和发展。
战略:如何发展，击败竞争对手的谋略是什么。
如何走出软件作坊成为开发正规军
目前好多软件团队都存在着这样一种普遍现象：
1.大部分人所在的公司，开发人员仅3-5人，多的在10人。别看就这几条枪，还从售前支持，软件开发，测试、打包发布、文档编写、实施安装、培训、技术支持都做。这还不算什么，而且几乎是一个人负责一个产品或一个项目，一个人从头跟到尾，而且负责多个客户的维护工作。这还不算什么，而且随时老板会找来八竿子打不着的新活，要的还挺紧，突然要开发，打乱了所有的计划，最后都懒的按计划行事，每天撞钟，老板有事就吩咐，没事就上网，还不让听歌，当然更不让打游戏。甚至还不让看技术书籍，呵斥不干工作。只能上网装作在工作。
2.老板和员工互相斗智斗勇，在年终奖、报销、出差、平时福利上啊，都明争暗斗。老板卡的紧，员工就在项目和产品上下药，还不知道是谁占了谁便宜，谁给谁打了工。
3.员工一边在刻苦钻研各种开发工具，阅读源代码，学习做DEMO例子，阅读UML、设计模式、单元测试、敏捷编程等等，一边却懒的修改现在公司的产品，有问题就打补丁，客户不嚷嚷就懒的修改，代码不优化，界面不友好，架构没架构，代码不封装。
其实大家都是想把产品开发好，把开发过程管理的井井有条，但是都心有余而力不足。阅读了N多软件工程的书籍，从重型方法到轻型方法都阅读了，但都无法把现在的开发状态一点点扭转好。 更多 »
分类“经营管理”的第一篇日志
近来虽然非常非常忙，不过接触了很多关于经营管理方面的资料，越来越觉得这百分百是一门极其高深的“技术”。看过若干篇资料和视频讲座，发现作为技术出身的自己总会陷入一个双输两难的境地，总会从技术的角度关门造车，虽然经历的项目（而且是100%的独立项目）比较多，且做过一阵与客户接触比较多的工作，相对来说可以从客户的角度想问题，不过根深蒂固的思想总会在不经意之间冒出来，看了一些经营管理方面的资料发现，其实很多东西可以联系到一起。做技术不是不好，不过作为代码开发型的技术，始终要做到管理型上，这样才会有持久的工作生命。而且其实偶尔发现做管理的确是一个很有意思的科目，声明一下，这可不是权力上的自大心理，怎么说呢，对于我来说，这种感觉好像是当初刚开始学习写程序的时候那种兴奋的感觉——也许，写代码真的有些累了，该换一换了。
经过这两年的积累，明年也许是一个转型的一年，希望先预热一下，积累理论的经验，抛弃旧有的观念和不良的习惯，扬帆开始我的而立之年……
既然是新手，那么就从转载开始吧……
