校园招聘：
http://www.youalab.com/?page_id=2

当然社会招聘也是需要的：
http://hr.baidu.com/www/job/jobDetail.action?jobId=592

     web开发里，页面之间互相连接都是通过url，每个页面里都设置了其他页面的url，通过url的点击，整个网站有机联系在了一起。在web下也许这种方式是自然而然的，但是如果这种方式被用在桌面程序上，你会不会觉得很新奇？

facebook开源了一个框架three20（IPhone平台），此框架支持一种调用协议：每个view都向app注册一个url，其他的view则可以直接调用此url来到达那个view，并且框架一定程度上还维持了url的调用栈，这样很容易在每个view上支持”返回“按钮。 开始了解这种方式，我就已经为之倾倒。传统模式

    近期重新设计了PHP框架，并在编写代码的同时做了一些局部的测试，但根据我最初的设想，这次全新框架下必须要提倡一下unit test了。之前的开发模式中，unit test这个环节基本上是空白，大量的测试任务都交给了测试人员，这样导致了开发者对程序质量要求的下降，甚至有些提测的程序一运行就报php fatal（语法错误）。

在框架开发的同时，实现了一些函数库，同时用phpunit做了一些unit test。当然函数库级别的还是比较容易测试的，基本上设计好接口，很容易就能写测试用例并且执行测试了。
对整个PHP框架

    重构这个事情似乎已经被所有开发人员所认可，但是真正能够有多少团队切实的进行了重构并获得好处呢？没有一致的设计、快速开发并推进产品的发布、团队成员不断的扩大、规范和约束的失效，种种原因都会加速设计和代码的杂乱无章和质量低下，这在一个快速发展的团队问题显得尤其突出。当然这个问题确实是绝大部分团队的一个必经过程，但是发展到后来，有几个系统又是可以重构的呢？

也许没有规范一致的设计是重构的最大障碍，对系统全局进行抽象设计和编码约束，是让代码和谐一致的关键。越来越多一流的开发

n行： $exp = new Exception('xxxx');


m行： throw $exp;


结果得到的错误报告里说：

n行代码出现错误，追踪错误时这样的结果很不方便，自己设计时尽量避免此方式..


从phpcassa中发现这个问题，特此记录。

    IO问题永远是数据库系统最大的问题，而导致这个问题最主要的原因就是数据量太大、读写太频繁....

通常情况下，读都是远大于写频率，而在大数据量的情况下，大数据量导致磁盘寻址时间的增加，频繁的读就会导致居高不下的iowait，除了做cache之外，最好的办法就是减少数据量。


用压缩的办法来减少数据量是个不错的办法，它能极大减小数据量，并且压缩解压成本较低，而且cpu横向扩展远比IO能力横向扩展容易的多。据了解，目前业内有不少正在使用这种压缩方法（例如对各种文档、blog等），但主要

     历时2周的上线终于算是完成了，虽然算不上是完美，但也总算基本顺利。过程中出了几次问题，但总算万幸没有出现大漏子，及时根据问题调整方法，逐步解决了问题。

如果要算上上线前的一些上线准备工作，总时间接近3周了，除了整个系统第一版的上线外，都没有那么费心过。虽然在以前工作也有过通宵上线的经历，但是系统规模却小得太多了，一个晚上就全搞定。

上线这档子事，说简单的话就是个体力活，拿着新代码发布出去就可以。说复杂的话那就是需要耐心、细心、全局观、细节掌控能力、系统熟

接文章：PHP里使用引用变量时容易犯的错 中的示例

   foreach($arr as &$element) {
       //modify $element
   }
   当循环操作完后，你再次调用了某个复制或者函数来保存$arr数组，例如：
   set_var("arr", $arr);
  
   这时候你认为被设置的$arr就是你想要的那个

   一个场景：
   foreach($arr as &$element) {
       //modify $element
   }
   这种用法是最近常见的，但是这里隐藏一个严重的问题。由于$element变量的作用域是在整个函数（假如这个循环是在某个函数里），如果$element这个变量被foreach这个循环之后的代码再次使用并对其作修改操作时，问题就发生了。因为在循环里$element是个引用变量，如果再对$element赋值那么相当于修改了原有$element所指的内容，例如：
 

针对select * from table where col1 > number order by col2 desc。

其实按照常规的方法可以这样设计：key(col1, col2)

但是这种办法在mysql里不算是理想的，where条件里限定索引前部分是一个范围的情况下后面的order by还是会有filesort。如果where条件里限定索引前部分是一个常量，那么order by就会有效利用索引。例如：select * from table where col1 = number order by col2 desc，explain的结果就不错。

为了让它能够利用上索引并且消除filesort，可以这样设计
索引：key(col2,col1)

莫名奇妙的server gone away发生了，你怎么定位错误？我看在mysql下很多时候就靠猜了，
innodb数据文件和表结构不匹配？
配置错误导致内存空间不够？
....

在我发现的好几次奇怪的mysqld挂掉后再重启的情景里面，mysql都没有记录出错信息，怎么办？只有靠猜了，这完全就只能靠经验办事了.....


这个错误日志确实有点弱。

      继上次 binlog切换时会阻塞更新 ，最近还发现它不光阻塞更新，如果设置了replication那么它对从库的查询也有影响。

      在binlog切换时，会有一个Rotate_log_event产生，而slave同步到此event后也会让Relay-log切换。由于mysql写这种日志都是写入系统缓存后就不管了，导致切换文件时需要对旧文件进行fdatasync，这时候瞬间io压力会过大，耗时较长。这种情况

  
    真是太久没来写博客了，偶尔心里似乎有些感觉像欠了什么似的，但是没啥可写也感觉不想写，因为我已经定位此博客为技术路线，不愿其他的事情掺进来。言归正传，说说最近干的一些事吧。

    从我使用mysql以来，我见过的都是用myisam作为存储引擎的首选，并且mysql doc也对myisam表扬有嘉，所以在大部分时候我都使用myisam。而在最近的一些测试中，myisam却没有想像中那么优秀。

    确实myisam更新速度非常快，因为结构精简

   这两个类型，如果只存储hello这个字符串的话，存储空间都没有区别的都是6bytes。
   但是真没有区别么？其实是有的，mysql在处理数据的时候需要分配内存，而内存的分配都是fixed-size的，所以它只能按照最大的可能来分配，这样varchar(10)和varchar(100)就差别大了。而blob/text字段在处理时内存分配则有所不同，mysql会按照已经发现的最大长度来分配内存。如果查询时有filesort，处理是类似的。

   所以字段长度只要是满足了需求，那么设置的尽可能小是没错的。