为什么我要写 ResquePanel
ResquePanel 是用于监控 php-resque 的一款 Web 界面工具。完全使用 PHP 开发。当然，由于 resque 的 “正版” 是 Ruby 写的，所以你也可以用来监控 Ruby 版的 resque。
也许有人会说我造轮子，因为很容易可以在 GitHub 上搜到一个叫 ResqueBoard 的项目，还有个非常漂亮的介绍网页，如图：
ResqueBoard 官方介绍页
可以看出来，作者花费了不少心思，前端做得也漂亮(我觉得这个前端堪称完美！)。所以刚开始我也用了这个，于是，发现了问题。
ResqueBoard 的缺陷
首先是该项目依赖太多，除了 Node.js 的 Cube，另外还要装一个 MongoDB，最关键的还在于如果你需要使用作者改写过的 php-resque，这让人很是担心。虽然我毫不怀疑作者的人品，但要我把正在跑的一个项目依赖的库替换掉（因为与原项目冲突），还是有不少担心的。然后就是 Cube 依赖的一个叫 websocket-server 的项目已经不见了，导致 npm install 安装依赖失败，Google 了半天，最后在该项目的 GitHub Issue List 里找到解决方案，过程参见 npm install cube Error: No dist in websocket-server package。折腾了半天，Cube 的两个进程跑起来了。最后就是替换项目里原来用的 php-resque，小心翼翼。配置了 Nginx 后终于跑起来了。
跑起来后发现，首页是能看了，其他页面都有问题，一检查，发现 web 目录下有个 .htaccess 文件，一看尿了，rewrite 规则这么多！只能用 apache 了，于是又给服务器装了 apache，Nginx 做反代，搞了半天终于基本正常了，右上角显示的三个服务正常连接。再对照官方文档，完全正确了。
但是，跑了几天后，发现数据有问题。首先是很多数据完全获取不到，基本上除了看到队列、处理了多少个 Job，其他一切显示没有数据。这一点让我很是伤心。各种找原因，反复查看官方文档、Issue 列表，还是没找到问题。
我最终决定自己写一个，简单一点的。
有人会说，明明是你自己菜，还怪人家太复杂！
我菜我认怂行不？
我并不否认 ResqueBoard 的价值，也并不怀疑作者的人品(不会故意给一个不好用的东西出来)。但是，作为一个产品经理(我觉得我更是一个产品经理)，我觉得无论是什么工具，做出来都是给人用的，既然给人用，就要考虑用户的感受。当然，对于开源软件，这一条并不适用，因为很多工具都是作者给自己用的，顺便开源出来，让用得上的人顺便用用。
其实，我不需要查看那么多指标，我只是想简简单单看看队列的情况而已，当然，如果可能，可以加一个 Retry 的功能。所以你也可以说，并不是 ResqueBoard 不好，而是不适合我。
有人会问，那你为什么不向作者咨询一下，而是自己造个轮子？
首先我本人是一个不喜欢麻烦别人的人，如果有问题，我会尽一切可能自己解决，这事跟借钱一样，我宁愿向银行向支付宝借钱也不愿意向朋友借钱，像银行借钱只不过交点利息，向朋友借钱要交的就太多了。当然，这是我自己的观点，我只是自己不想做这个事，不代表我反对这个事。就好比我不会穿丝袜，但不反对别人穿，如果是美女穿，我还喜欢呢，哈哈！
跑题了。话说回来，我觉得 ResqueBoard 是一个好看但并不好用(或者说实用)的工具，首先是安装过程太折腾，限制条件太多，虽然功能强大，但对于使用 php-resque 作为队列的用户来说，并不是一个好的选择。(既然选择了 php-resque 作为队列服务，首先可以认为用户对队列的要求并不高，否则肯定选择更加强大更加完善的方案。)
所以，我在 ResquePanel 里使用的都是 PHPer 比较熟悉的技术，最“精深”的也只不过是 swoole 实现的 WebSocket (外加一个 swoole 实现的 child process，其实没必要使用这个特性的，我只是为了尝试一下，也许会在正式版本中移除)，安装简单快捷，甚至都不用安装 HTTP Server。当然，代价就是功能没那么多，目前最核心的功能除了查看队列情况(包括 Queues/Workers/Jobs 的各种信息)外，还有一个 Retry 的功能，都是按照我们实际需要来开发的，所以比较简单实用。
ResquePanel 的未来计划
目前 ResquePanel 只是一个简单的查看 php-resque 队列运行情况的 web 界面工具，我计划将其发展成一个完整的队列工具，甚至包含一个微型的 MVC 框架，这样在某些场景下，可以完全依靠 ResquePanel 来解决问题，为开发者提供方便。
当然，以上只是美好的构想，也许由于我太懒会停更这个项目。
