DAL2.1.1是一个非常重要的版本，到此为止，当初的想法已经得到了相对较好的实现。刚来的朋友可以看这两篇Blogs：
beta技术沙龙结束，开始忙正事了，DAL2.0开发已近尾声，在这稍微说说情况，来了解一下DAL的相关词汇及来龙去脉。
总的来说，DAL是团队近几年在开发和运营上的经验的总结以及智慧的结晶。一年前，开发DAL是一件水到渠成的事；一年后，不断改进DAL则是为了在未来5~10年、甚至更长远的时期内，(在数据访问层)支撑着手机之家传统业务的快速增长以及新业务的持续开拓和稳步扩充。后者，决定了新版DAL的项目目标。
具体说来，当时定的目标是这样的：
一）可伸缩。
这里是指Scale Out.，即水平可伸缩。事实上，这点更应该是整个系统要考虑的目标了，而非DAL，DAL要考虑的是怎么更好地支持。举例说，我们可以一个库一个服务，甚至可以是一个表一个服务；库、表拆分后，DAL应能路由查询、合并结果，而不是让应用程序去操心这些事。
二）高可用性。
1) 我们认为出错失败是很正常的，一台机器倒下了，其它机器应继续保持系统正常运作。容错是很重要的一个要求。
2) 系统规模大了以后，很容易出现“异构“的情况，如原有模块MySQL表引擎是MyISAM的，是不支持事务的，而新上的模块又采用了InnoDB表引擎，在这种情况下，DAL应能对原有模块进行优雅降级。
3)失败恢复也是要考虑的，失败后，需要把失败前驻留在内存中的消息找回来。
4) 另外，DAL本身也在快速的迭代当中，升级是很经常的事，应能进行在线热升级(不重启原有服务)。
三）良好的性能。
对于根据Id来取记录的查询，在缓存命中的情况下，应该达到和Memcached不相上下的读取速度。在缓存不命中的情况下，则应该充分利用分库分表和并行计算的优势，最大化地提高查询的效率。对于修改型查询，挂在上面的监听器，不应该影响性能。
四）系统可监控。
资源占用情况，命中率如何，系统当前压力怎样等等，都应该是可知的。应该有报警机制，当压力到达一个阀值以后，通知相关人员进行处理。还应该有详细的错误日志，便于排查问题。
五）安全。
没有SQL注入问题；避免或尽量减少分表和索引表之间的数据不一致问题等等。
六）易于编程。
需要设计一套简单好用的API，便于应用程序的开发。API必须是自完备的，应用开发者不需要太费力就能记住的。
应用开发人员不再关心分库分表问题，不再关心缓存问题， 特别是缓存清除问题。甚至不再关心后端的数据库是MySQL，还是Oracle，或者是其它。
七）可定制、可扩展、可维护的架构设计。
像连接池组件、缓存组件、查询分析组件、消息队列组件、通讯协议等等不应该写死，应设计成可方便定制的。还应该提供足够的钩子用于扩展。只有这样，DAL的架构才是灵活的、拥抱变化的。简单说，我们定的是机制，提供的是策略；机制是软件目标和宗旨的体现，一般是不能轻易改变的，而策略则应当是能比较简单地进行切换的。
更加详细的资料可以参看这两个blog：
<<数据访问层开发实践>>
<<手机之家的数据访问层实践>>
主讲人唐福林是一个思维很活跃的人，和他交流，我相信你会有收获的。欢迎lucene爱好者、搜索爱好者前来一同探讨。
——————————————————
时间：7月26日14点30分开始
地点：奇遇花园咖啡馆http://storygarden.me/cafe/map
主题：大型网站的lucene搜索实战
演讲简介：本次活动介绍基于Lucene的站内搜索的实践，后台技术层面的一些想法与实践，包括缩短更新周期，简化重建索引流程，支持大数据量频繁更新的索引，以及在性能和可用性方面作的努力。
主讲人：唐福林
主讲人简介：从高中的 NOIP 到大学的ACM，是编程竞赛的参与者，也是算法的爱好者，以追求程序或系统的性能的极致为乐。 目前就职于手机之家，负责基于lucene的站内搜索的开发及持续改进。
DAL全称Data Access Layer，是一个由手机之家技术团队研发的中间件，原先我们做的只是一个数据库代理层程序，作用类似于MySQL Proxy，主要功能包括数据表拆分，以及缓存更新与清除的自动化、透明化等等。但现在，我们做得更多，走得也更远，可以在这篇BLOG中了解一些这方面的信息。
DAL2.0是DAL的下一代版本。DAL2.0的规划，其实从去年在三元桥时间国际7楼的小会室里就开始了，老高提出了初始想法，经过讨论以后，一拍即合，觉得应该抽出一个整块的时间来做这个事。
正式开发，从2月底3月初开始，原定计划是4月底5月初交上答卷，很遗憾，项目已经延期了。当然，非要找一些借口的话，也是有的：找人，组建团队，沟通，第二期BETA沙龙，QCON北京大会，又找人，会人。。。但其实，最主要还是因为：我没安排好任务，没管理好时间(是情商问题而非智商问题)。
虽然公司给予了我们团队很多的理解和支持，但我认为这是有问题的。因此，从5月4号(五一节后)开始，我做了一些调整：关掉Gtalk，不访问Twitter，不收Email，专心致志开始了2周的封闭式开发。成效是明显的，不少难题都是在这2周内解决的。有些朋友可能找不到我，在这说Sorry了。
接下来，我稍微说说技术的一些情况。
与DAL1.0比起来，DAL2.0的变化是非常大的：
显然，这些变化不是一言两语就能说清楚的，其中有很多细节问题，在这不再赘述。
虽然，和DAL2.0比起来，DAL1.0显得单薄了些，但其实她是一个非常重要的里程碑，有很多想法通过她已经被证明是可行的。
DAL2.0的开发还在继续，还需要不断地努力、持续地投入。在运行之前，需要大量的测试：单元测试、集成测试，旁路测试等等。
总之，我们是对DAL2.0是非常有信心的，欢迎大家继续关注我们，并提出宝贵意见。
昨天写了一个方法，然后用JUnit进行单元测试，愣是通不过去。检查了半天，发现是我误解了自己一个月以前取的一个变量名了。很郁闷，一个不友好的变量名浪费了那么多时间。
为此，我觉得有必要约定一下Java程序代码里变量的命名(其它语言同样适用，无非是大小写、下划线方面的区别)，以免再发生类似的错误。对于语法级的命名约定(规范)可以看Java命名约定(规范)，这里要说语义级的命名约定(规范)，而且只涉及复数的情况。
以下是复数变量的命名模板(含推理过程)：
一个学生的多本图书 a student’s books -> studentBooks
很多学生共有的多本图书 students’ books -> studentsBooks // 强调共同财产
每个学生的多本图书的集合 the list of each student’s books ->studentBooksList // 强调私有财产
学生图书的集合 student-book’s list ->studentBookList // 强调书的集合
套用该模板的几个示例：
primaryKeyColumnNames: List< String> [a, b]
trueUniqueKeyColumnNamesList: List< List< String>> [[c], [d]]
trueUniqueKeyColumnNameList: List< String> [c, d]
trueUniqueKeyColumnNames: List< String> [c]
uniqueKeyColumnNamesList: List< List< String>> [[a, b], [c], [d]]
uniqueKeyColumnNameList: List< String> [a, b, c, d]
uniqueKeyColumnNames: List< String> [a, b]
specColumnNameList: List< String> [a, b, c, d, f] f为scatter column name
columnNames: List< String> [a, b, c, d, f, g, e, h]
注：<后加了个空格，免得浏览器把它当作HTML标签的开始。
100天，对于一个daemon程序来说，实在是微不足道的。
不过，对于年轻的Monkey和Mycached来说，则是一个值得记念和回味的数字。
Monkey是一个Java NIO Framework，MyCache是一个Java Memory Cache Library，两者皆由手机之家开发团队研发而来。
Mycached是构建在Monkey和MyCache之上的一个类Memcached缓存系统。
在此截图留念：
QCon(Beijing)大会在今天落下了帷幕。有点疲劳，但还是坚持听完了：）
今天似乎成了广告时间：），呵呵，关于云计算的演讲给我留下的有价值的回忆并不多。
我听了微软、IBM、CeresData、VMware等的云计算方面的报告。这些产商都有自己的特有产品，每个产品也都有自己的特点。而我现在关心的问题是：在可预见的未来，这么多形态各异的云它们之间交互的标准是什么？
这期间有个细节，我觉得挺逗。当微软的演讲人问到谁在用Visual Studio的时候，在那么大的一个会议室里居然只有3个人举起了手。。。不用我多说，在坐的大多数是LAMP或Java EE开发人员。
接下来，来自台湾的高焕堂先生，作了题为：提高架构质量的10个观点的演讲。观点挺新颖，把中华文化蕴育其中。他的一句话：以序(条理、规则)容(包含)易(变化)，我觉得是道出了架构设计的真谛。高焕堂强调，架构师应该具备逆向思维的能力，自顶向下看问题，这样才能掌控全局、运筹帷幄。
要说今天有点共鸣的演讲，当数下午第三场李伟带来的大型复杂系统的架构与设计。作者高膽远瞩，与本次大会敏捷为王的基调截然不同。他举的如何从无到有建设一个生态岛的例子颇为生动有趣。
其它的就不多说了。等着看PPT吧。
–The End.
连续两天7点左右起床，今天有点困：）。倒了两次地铁，倒到五道口，走几步路就到了。还是九点整。。。不过，吃了早饭。
应该说，今天的会议是我(也是很多人)最为关注的。
SpringSource的Rod Johnson打头阵，演讲题目为：Spring的现在和未来及企业Java的挑战。和多年前一样，RJ继续唱响轻量级Java EE开发、继续推崇他的spring framework。
他认为lean solution是Java EE的未来。Tomcat将是未来主流的Java WEB Server和Application Server，因为简单(容易部署)、免费和开源，而像Websphere和Weblogic等复杂的解决方案将慢慢丢掉自己的市场，特别是在全球经济衰退的大背景下。他举例说ebay已经慢慢将重量级服务器换成Tomcat。
中间，RJ说，SpringSource已是Tomcat最大的贡献者，为此，我第一个给了掌声：）
另外，RJ提到的spring framework的平台独立性设计，我颇为赞同。框架对环境的无侵入式设计是相当关键的，这使得项目可以更容易的部署和维护。有些框架，把环境变量或常量写到底层库的各个地方，这就是一种侵入式的表现。。。这使得我们不能简单地切换环境(因为我们已经依赖那个特定的环境)，如从web切换到console。
在Q&A环节，RJ认为Java的未来将是community-driven的，而不是由IBM或SUN等某一公司决定的，不管收购成不成功，对开发人员的影响不大。
第二场，来自eBay的教训—可扩展站点的最佳实践，由Randy Shoup讲解。今天的演讲和之前网上流传的一篇文章很相似：Scalability Best Practices: Lessons from eBay。这些原则，我想地球人都知道，在此不多谈。
Yann HAMON作了上午第三场的演讲。AgileCMMI：借助轻量级敏捷实践提高软件性能。算是自圆自说吧，有点中庸的味道(既Agile又CMMI)，反正一般不会错：）。没留下太多的印象。
接下来，说说下午的主题吧，均和架构有关。
首先是支付宝程立的演讲：大规模SOA系统治理中的架构支持。本来是想更多地听听支持宝是怎么实施SOA的，但似乎变成讲怎么实施SOA了，而这个话题要想在一个小时以内讲清楚那是有难度的。不过，对于作者的尝试表示肯定和赞赏。
至于第二场(豆瓣网技术架构的发展历程)和第四场(从优酷网谈大型网站架构)的演讲还确实没有出乎我的意料。
豆瓣网也选用了SCGI通信协义，这个很正常，因为他们用的是python。他们也有缓存控制器(但不是专门的层)，缓存单条记录(增删改自动刷新缓存)，列表不缓存，打散对业务逻辑不透明。总之，豆瓣网的架构和手机之家新平台系统架构在某些地方是有点类似的，但封装没有那么彻底。
另外，刚开始，豆瓣网的搜索是用sphinx做的，但后来发现这个工具可定制性较弱，就换成了Xapian，直到现在。
优酷网的结构看起来要更简单一些。对缓存和切表也是不透明的。不过，邱丹提到的其它三个东西倒是我最近经常想的：sendfile()、mmap()以及unix domain socket。在这个平台以后的开发过程当中，肯定用得着。
再来说说下午第三场的演讲吧：有道搜索服务系统架构剖析。这位大哥的演讲，就像大学时代老教授的讲课一般：），中规中矩，文字居多，图片偏少。不过，他说的监控和日志分析等设施，是很多有点规模的网站都应该具备的吧。而我们目前还没有专门的系统。
最后则是敏捷和模式的晚场沙龙。几位嘉宾讲得都挺好。
其中李伟先生的发言，我印象颇深。他主张用生活中的例子来阐释计算机中的设计问题。他的书： 架构之美–软件架构的艺术即将上市，有兴趣的可以留意。
但是，对于嘉宾们的有些观点，我也持保留意见。特别是Just-in-time Architecture的看法，我认为是过于极端了。
不敏捷和过度敏捷，都是不可取的。我们不是要拥抱设计的变化，而是要拥抱业务的变化；我们不是不要设计，而是不要不可预见的设计。
—The End.
早上7点左右就起来了，匆忙洗脸刷牙。乘地铁13号线，倒到10号线。。。在知春路站下，打了个的，路有点堵。。。到会场刚好9点整。。。没吃早饭。
人很多，座无虚席。
Marting Fowler出场演讲：领域特定语言的发展与应用。
对这个话题，没太大的感觉。。。注意这个词，［领域特定］，而不是［通用］。所以，一句话：每一种领域特定的语言一般只适用于(熟悉了)那个领域的人。
然后亚马逊的Jeff Barr出来宣传云计算了：亚马逊Web Services。
这是我比较感兴趣的话题。XX计算，最近很火。我的观点是不管名词怎么演变、外界怎么忽悠，是商业的也好、是技术的也罢，这些计算模型的本质都是一样的，无非就是集合兵力(计算资源)来更好地做某些事情。它们都是社会分工进一步细化的表现，是市场的必然选择。
就目前来看，要到云计算大规模运用的那一天，还很遥远，特别是在中国。
现阶段，云计算面向的用户主要是中小企业，让大企业或国家部门去使用外界提供的云计算服务那是不太靠谱的，安全和竞争问题。
所以，目前那些支持云计算服务的软件(特别是开源软件)将会有更大的市场。集群、切分、复制、冗余、分布式计算等将仍然是多核时代很多开发人员需要掌握的热门词汇。
上午的最后一场是Dojo创始人的演讲。和RIA有关，他认为JavaScript在RIA领域更有前途，并期待HTML5更优异的表现。不太关注，略过。
下午第一场，仍然是Marting Fowler：Ruby实践的回顾和展望。MF对Ruby看来是相当的喜爱，不然用不着展望。MF认为，开发效率高是Ruby的优势，性能差则是劣势，但不重要，因为用ruby开发的项目，通常都不太大，而且可以采用混合编程的办法弥补这种缺陷。
接着是Henrik Kniberg的：多团队的Sprint计划。关于Sprint，可以参看他写的一本书：硝烟中的Scrum和XP。虽然，对于中国的中小企业来说，Sprint不太现实，但他提出的某些观点还是可以借鉴的。
第三场是吕建伟带来的：实效项目管理。总体看来，阿朱推广的这个过程方法很山寨：）。但是，却是一个实用的方法。
搞开发也有一些年头了，对权威这个东西渐渐不再感冒。现在我的观点是，不管是正规的方法论，还是山寨的土办法，只要能解决现实的问题，那就OK了。它们之间只是形式不一样，但目标(或者说实质)都是一样的，它们都是为了解决问题而产生的。正规或山寨也都不是真理，只是一种“最佳实践”，是真理在某些情况下的某种反应罢了，每个企业都应该有适合自己的管理办法和发展策略。
阿朱的演讲触动了我，让我想起了手机之家。为此，我买了他的书：走出软件作坊。
下午最后一场，本在多功能厅，但演讲的那哥门似乎不太精神。我就跑到第三会议室奏热闹去了。没白去，说到了widget，有点意思，也许对其他同事有用。但坐得太远，没看清楚。标记一下，有时间进一步查询：RIA技术在GeoWeb项目中的实际应用。
晚上，则是一个技术沙龙，几位远道而来的专家坐在台上和观众互动。基本上是在闲聊，只有只言片语在我脑海中还存有记忆：1）敏捷的路还很长，但已经在改变。2）混合编程is good。3）JAVA平台将更好地支持云计算。4）IBM收购SUN失败。
其它的一些感受：
一）关于演讲：
1）演讲时语调要抑扬顿挫，避免一样的语速，那样只会让听众想睡觉。
2）PPT少些文字，多些图片。在一个大的会议室里，观众看不见(也没有耐心去看)PPT上的文字，但看得见巨幅图片。
3）和观众多些互动，别一味的讲解，这样能让观众集中注意力。
4）要控制好时间，在大会中，一般会有很多讲师，每个人的时间都是严格控制的。所以一定要抓住演讲的主题，只传达最重要的东西，把延伸的东西留到会后、个人博客上、书中等等。这其实是大会巡讲和个人专讲很重要的一个区别。
5）要有充份的准备。达到PPT和演讲能够流利地衔接和过度、没有嗯啊呵嘿等语气词、逻辑清晰慎密。最简单的办法就是准备两个稿件：放映稿和演讲稿，然后反复练习。
二）关于组织活动：
1）任何活动，都应该配备咨询人员。被动。
2）任何活动，都应该做好向导工作。主动。
三）杂项：QCon这次沙龙组织的不太好。
大家基本上没怎么讨论就散场了。
专家没和听众打成一片。
听众没能和专家一起合影留念，专家觉得受冷落。
一句话：互动不够。原因：缺泛调停者，主持人没控制好节奏。
—The End.
今天已经是4月6号了。离之前拟的最后期限也是越来越近。。。
但这个QCon大会，今年一定要去参加，而且要参加好，抱着学习和审视的心态。
争取每天、每场会议都有收获。回来给弟兄们做个有价值的汇报。
多余的话不说太多，感谢鼓励、支持和理解。。。
以下是本次大会中我要关注的议题：
一、Java企业级开发的最新态势
二、云计算
三、架构设计与实践
四、敏捷开发与敏捷团队
公司欲开发一款中间件，缺一人手。招聘启示放出几天了，但始终招不到合适的人。。。
公司的架构，可以看我的博客：beta技术沙龙结束，开始忙正事了。。。
收到的简历里清一色的SSH，有自己见解和创新的很少很少。很头痛。
难道现在要找一个有服务器开发经验的、有缓存系统设计经验的同学，有这么难吗？