我们可以提供：
自由宽松的工作环境；
足有竞争力的薪酬；

大致要求如下：
诚实、正直、敬业、有责任感，有较好的沟通能力和团队精神；
有较强的学习能力和领悟能力，能够自主学习；
基本功扎实，了解常用的数据结构和算法；
熟悉以下语言中一种以上： java，python，php，c。

符合以下条件的优先考虑：
熟练掌握 java 程序设计与开发，编程能力强；
有 python、php 等脚本语言使用经验；
理解能力强，有较强的软件设计能力；
善于协作和沟通，有责任心，对新技术能快速学习并掌握；

所有要求都不是强制的，如果你有兴趣、有责任心，请别犹豫，赶快发简历至

关于公司：
手机之家（http://www.imobile.com.cn/）自 2002 年创办，是中国最大的面向消费者的手机及移动设备网站。在 GOOGLE 以及百度等搜索引擎上，有关手机的关键词，手机之家的排名均非常靠前。根据百度数据研究中心发布的 2009 年上半年行业报告显示，“手机之家”是网民最关注的手机及相关产品资讯网站，以超过一半（55.71%）的关注份额位居第一。 公司旗下还拥有多家电子商务站点：如：烧包网，18900等等。

协议改进。之前版本的 DAL 使用 php 序列化作为数据传输协议，这是一个历史遗留的问题，因为最早的 DAL 是完全用 php 实现的。现在仔细考虑过后认为 php 序列化肯定不是好的编码格式，首先 php 序列化是文本格式的，并不高效；还有很致命的一点就是 php 对数据类型支持很差。比如：php 不支持 double 类型，如果打算用 java 语言实现一个 DAL 客户端，那么这里无疑是丢失了数据类型信息，所以 php 序列化肯定是不够用的。新的编码格式目标就是高效，并且对数据类型有良好支持。参考了 mysql 数据库协议和 igbinary 序列化格式，最终考虑采用二进制协议。如何支持数据库的多种数据类型呢？我们是这么做的，server 端返回的查询数据是一个表格，表格有表头和表内容，我们在传输表头时就传输了每列的列名和列类型，这里列类型和 JDBC 的数据类型是一致的，表内容全部采用字符串编码，这样可能会多传输一些字节，但是避免了精度问题，因为数字也是用字符串编码的，当然没有精度问题。这样的好处是 DAL 不同的客户端可以根据各自语言特点来解码。协议设计好后先用 php 实现了一个版本的解码器，由于 php 本身性能问题导致 php 版的解码器效率比较低。接下来又用 php 扩展实现了解码器，性能有大幅度提高。在大数据解码方面比 php 序列化快几十倍，比 igbinary 快一点点。

对数据库函数的处理。DAL 需要操作缓存，需要考虑数据库切分，所以不得不分析用户的查询请求。如果用户使用了数据库函数，这个分析就变的异常困难，因为你不知道（很难知道）用户调用的函数中使用了什么函数，涉及到哪些字段。目前的临时解决办法是：只要用户使用了数据库函数，用户就必须显示的指定是否缓存；如果用户这个请求需要辅助表完成，那么 DAL 会强制选择第一个辅助表而不进行任何优化选择（关于辅助表选择优化请看《DAL 最近的一些进展》）。

数据库条目缓存结构调整。以前数据库条目缓存包含了条目的属性和数据两部分信息。很显然，没必要缓存条目的属性，因为条目属性在系统启动时就可以加载，在整个系统运行期间不会改变，没必要每次写到缓存里。缓存数据库条目时所有字段都是按字符串格式存储的，这样做无疑增加了缓存条目的体积，但换来的是保证不会在 server 端丢失数据精度，同时数据格式和协议是一致的，便于操作。

大体就是这些改进，关于 DAL 的介绍可以看超前同学的博客。在这段开发过程中接触了很多开源软件，也浏览过一些源代码，个人认为 php 和 mysql 的源代码质量比较一般，如果打算读开源代码不建议选这两个。

1. 选择最优的索引表完成查询。数据分片后为了便于排序和做一些聚合操作，每套分片都建了若干个索引表，有查询请求需要索引表辅助完成的时候，以前是随机选一个可用的索引表，现在引入了一个评分的算法，给每个索引表评分，选得分高的索引表。评分的依据主要是索引的使用情况，大体来说就是有索引比没有索引好，联合索引比单个索引好。目前这个特性在手机之家测试机上运行良好，情绪稳定。
2. 对并发查询请求的优化。在生产机的数据库上经常会看到有同样的 SQL 请求在数据库中执行，DAL 能不能为这种情况做些优化呢？我们想到了这样的办法：每次执行数据库查询的时候记录一个请求执行上下文，当有同样的请求并发到达时，只有严格的第一个到达的请求会查询数据库并将查询结果保存在执行上下文中，其他请求都等待第一个请求完成，然后直接使用上下文中保存的查询结果。当然如果对某个表有更新操作，这个表的所有执行上下文都将被删除，保证数据的一致性。还有如果查询中包含时间函数也不能使用这种优化机制。
3. 编码优化。以前的 DAL 使用 php 序列化编码结构化数据。其实只要稍微想想就知道这肯定是个不好的方式，但是由于历史原因，这种编码方式一直持续到现在。php 反序列化大数据时性能相当差，并且 php 只支持少数几种数据类型，用 php 序列化编码的数据无法跨语言使用。新的编码主要要解决性能问题和数据类型跨语言的问题。这部分工作目前还在进行中，以后会给出结果。

大概就是这些，最后再附几张大学校门图，这也能看出国家正在进步嘛！

• 公司初期，没找到盈利模式，不断做一些尝试，这个很正常；而很多有一定规模的公司还是没有自己的目标和原则，WEB 2.0 来了，大家都说自己的站点是 WEB 2.0，国外公司推出个啥啥啥，国内公司纷纷效仿也做个啥啥啥。
• 技术人员急于转管理，公司技术根基不扎实。我认为任何一个公司没有一支强大的技术团队都是很难成长的，但是看国内大部分公司并没有很重视技术团队，技术管理人员对技术知晓甚少。
• 国内开源社区一直很冷淡，很多公司在大会中提出要开源自己公司开发的啥啥啥，试问，这些软件开源后有多少人会研究，有多少公司敢用，这样的开源对社区有多大意义？我还是比较佩服一些公司默默的为熟知开源软件提供 patch。

最后感谢国家，感谢老大给我这个大会名额。

• 仔细审视你的设计
  设计不好的系统不仅是不好维护，更是滋生 bug 的温床。

• 不要为不成熟的系统做过多的优化
  《UNIX 编程艺术》中的优化原则是：雕琢前先要有原型，跑之前先学会走。 显然不成熟的系统，代码变动频繁，今天做的优化明天可能因为设计问题又要改掉。比如，在开发 dal 过程中，为了少获取数据库连接，尽量取一次连接，反复使用，结果引入分布式事务后，这样的代码不得不改掉。
• 工作任务合理安排
  长期的工作目标肯定是要明确的。第二天要做什么，做到什么程度，遇到问题卡住了怎么办，这些最好提前想清楚了，这样每天工作效率高，也觉得很有成就感。工作任务一定要明确记录，比如：“完成配置文件解析”，而不是“看代码，改 bug”。
• 代码一定要严格对待
  申请的资源不用了一定要释放，该判断的逻辑一定要判断，而不是说“一般情况下，这段代码没问题，如果怎么怎么，代码可能不行”。保证在任何时候任何可能发生的事情都要在掌控之中。
• 选择第三方开发包时要慎重
  使用前一定要仔细看文档，做好测试工作，也可以上网搜一下大家对这个开发包的评价。否则，用了一段时间发现有各种各样的问题必定很郁闷。

来到新部门一个多月了，新的部门目前的工作重点是研发一套分布式数据访问系统。开发团队由三位成员组成，各自负责一部分组件的研发。

这一个多月来，代码写了不少，错误也犯了不少，时间也浪费了不少。今天做一些总结，以免日后遗忘。

• 设计要自由、大胆，最后落到实处
  做设计尤其是做新的系统设计，不要拘泥于已知的东西，要大胆的设想，否则就是原地踏步，设计出来的东西没什么创新，亮点很少，客户当然不会买账。做完设计后要想想，哪些可以做，哪些比较难做，分清主次和先后，逐步实施。不是说设计好了就要一次性做出来，任何伟大的系统都是一砖一瓦搭建起来的。

• 对系统抽象后，系统结构应该非常清晰
  系统中结构不清晰的部分往往是没有考虑周到的部分，如果短时间内考虑不好，不如暂时放下不要急于动手。或者试着做一点，新的、好的想法说不定就显露出来了。

• 动手写代码之前基本的逻辑是要清晰的
  经验不丰富或者是涉足新的领域，一般很难事先把所有的逻辑都考虑的清清楚楚，但是至少大体上是清晰的。如果对系统没有一个大概的想法，急于动手去做，结果往往是很悲惨的。

• 写代码过程要心细严格
  整个系统的开发过程中，设计和调试用的时间比较多，减少这两块时间就提高了效率。“敏捷开发”的思想就是不要像传统软件开发那样做过多详细的设计，大概想的差不多就着手开发，一边开发一边修正设计，这样设计的时间就减少了。如何减少调试时间呢？往往需要花时间调试的代码都是写的时候不仔细，犯了一些很低级的错误，但是却浪费了大量的调试时间，所以写代码的时候还是尽量细心严格。

转眼一年又要过去了，我给自己 2009 年打 70 分。在工作上我还比较认真，我觉得老板给了你一份工作，要不就认真做，要不就走人。09 年在读书学习这方面做的不好，先后也买了一些书，但是完整看完的很少，以后要杜绝浮躁，静心花些时间来读书。08 年最后一天领结婚证了，但是我觉得这一年还没有很好的尽到一个做丈夫的责任，没有多花点时间陪老婆，以后也要好好改进。自从 07 年工作以来，身体持续发福，后面不一定有很多时间来锻炼，但是一定要控制饮食。

时不待我，我不待时。