绝杀——Swoole、PHP与MySQL：连接池
我是早就看过这篇基于swoole扩展实现真正的PHP数据库连接池了。看完了，觉得真的很厉害。毕竟，现在来说可能是还没有真正在PHP使用数据库连接池的大应用。今天终于准备实验实验。
在开始之前，还是说一下测试环境吧：OS CentOS 6.4 x86；php 5.3.17；MySQL 5.5.28；Swoole 1.6.8。
使用WinForm实现无边框窗口
虽说新项目还没有提上议程，甚至第一次策划会议也一直没有召开，但是准备工作多多少少是有一点点了。项目难度最大的，就是开发桌面应用程序。这几乎是一个大家都没有多少了解的问题，所以下手比较困难。2013年初我们从TFDi Design处采购了smartCARS，同年7月Hans使用Visual Basic .Net开发了iTracker 2.0，这大概是我们选用.Net的原因吧。
2013年底（真正的年底），我开始使用Visual Studio 2013了。与Hans，不一样的是，我使用的是C#。我长期使用各种类C的程序语言，所以C#很快就能上手了。期间写过一些测试性的东西，写过一个即时通讯（上一篇日志提到过，服务端使用PHP with Swoole Extension）。VS的控件样式实话实说是很难看的；较新的VS，提供一些Flat的属性，磕磕巴巴地出来一些效果。如下图：
当然，我要寻求更好的解决方案。我找到了一篇文章Designing GitHub for Windows。自己向来非常认同GitHub的理念，便也想使用WPF尝试尝试。尝试的过程很艰辛，毕竟接触微软家的VS才一个月，Blend更是从来没有上过手。折腾了一个晚上，最后觉得太困难，还是暂时放弃了。我将目光转向WinForm。WinForm开发难度小得多，我刚开始使用VS便能顺利写出诸如“计算器”之类的小玩意儿；此时我甚至已有使用WinForm实现无边框窗口的想法。尝试了一下，确实可以。接下来我讲一讲我的做法。
神器Swoole
Swoole是一个PHP的C扩展，可用来开发PHP的高性能高并发TCP/UDPServer。Swoole的网络IO部分基于多线程的epoll/kqueue事件循环，是全异步非阻塞的。
业务逻辑部分既可以像node.js一样全异步回调执行，也可以多进程同步阻塞方式来运行。这样既保证了Server能够应对高并发和大量TCP连接。又保证业务代码仍然可以简单的编写。
相信这一段引自Swoole官网的文字解答了大家的第一个问题：Swoole是什么。那么现在我要说说，我是怎么找到它的。前一段时间，有写一个简单的IM（Instant Message）的想法。因为初接触C#的缘故，客户端肯定是用.Net写了，服务端呢？考虑到服务端肯定是跑在Linux上的，C#马上被否决（不能编译成二进制可执行文件，麻烦）。有考虑过C，但是C的特性还是少了点，写起来可能比较耗时。C++呢？确实有找到一个C++的Socket库，但是…毕竟Linus是说过某些话的，而且自己也没碰过C++，上手很有难度。忽然想到了PHP。PHP是C写的，也有Socket相关的特性，但是查了一些资料之后，还是觉得有些麻烦。然而此时Swoole出现了。简单看了一下简介之后，决定就是它了。当时心情比较激动，PHP写业务逻辑，底层实现还不用管，没有比这更爽的事情了。
基于php框架的多国语言思路
不难知道，想使网站多国语言化，最简单的方法便是直接调用在线翻译。傻子都知道这种做法是做了等于没做，体验一定是非常不佳的。直接机翻，不可行。
在网上查了一下，最正统的解决方法是使用gettext扩展，然而我没有接触过，这里就不提它了。本文中的方案，我们从一个请求开始。
请求执行到调度器之前，使用一段代码判断cookie中有无语言项并判断其合法性（是否有这个语言）。若cookie中无而已登录账户，则将本账户指定的语言写入cookie。若仍无，跳转至语言选择页面。有的情况下，将语种写入常量LANG。程序继续执行到控制器，View层模版均需为不同的语言编写不同文件，如某路径为"Tpl/cn/index_index.tpl"。动态输出的内容也需要处理。为了避免空间复杂度太大，我们为每个控制器（必要时为某些方法）单独编写语言文件。形如：
<?php
return array(
'key'=>'value'
);
算法？方法？
“你要分清楚算法和方法的区别。”算法？方法？当时的我想，这我当然能分清楚了，有什么难的。然而我现在不再像当时那样简单地想了。
两个月以来一直在恶补C，那个我认为过了时的玩意儿。过了时的东西，嗯，我现在仍这样想。学了几节语法结构后，我还觉得php语法不愧是C衍生来的，确实很像。依据经验，我的想法是：我迫切地需要知道更多的函数。掌握了各种函数，各种开发何在话下！然而令人失望的是，C的库函数是那样的少，几乎是没有一个真正实用的库函数嘛！为此我曾对Hans说：“C确实很适合搞算法竞赛。”言外之意是，什么都得你自己亲自动手去完成。
到这时，我有点认识到算法与方法的区别了。之前搞的Web开发复杂之处，讲究的是性能与便捷平衡的，实现简单的业务逻辑的书写。然而现在则是来编写程序执行人类计算起来费劲的实际问题了。初学简单算法时，我曾用1行php完成了字符串反向的问题（NOIP普及组第一题）。事实上这确实很简单，用C或Pascal也就十几二十行代码的事。我还曾用5行php解决了判断回文字符的问题。然而老师说了这样一番话：“库函数好是好，但是我们真正要做的，应该是去知道它本质到底是怎样实现的。”我似乎有些明白了。群里曾讨论过“发明轮子”的问题。没错，实际应用里重复发明轮子是愚蠢的，然而当我们要深入理解程序，学习基础时，这就明显变得尤为重要了——至少你要依葫芦画瓢地造个轮子出来。