公司内部一直是在用ThinkPHP,最近偶然间接触CI,感觉不错,公司内部使用ThinkPHP用了他们官方示例的RBAC,最近花时间根据CI的一些特性以及ThinkPHP RBAC的基本理念,用CI实现了一套,说是RBAC,其实不只是权限控制,导航菜单的定制以及RBAC的后台页面化管理都已经初步完工了,下面就来看看最初版本。

整个RBAC基本上就是RBAC0的模型，甚至比他更简单，用到的CI钩子-扩展框架的核心。

先看一下RBAC的配置文件,这基本上就是这个的辅助功能了。关于rbac_manage_menu_hidden，rbac_manage_node_hidden这是在使用think的rbac时感觉别扭的地方，RBAC的管理也是根据自身的这套架构来控制的，但是根本没人去再对其进行操作，每次显示在后台特别别扭，所以这里增加两个参数，可以使不想显示在后台的管理节点以及菜单显示。

在./ccch_scan 执行过程中出现如下错误：

上次弄好了GSM Sniffer以后好久都没有在用，最近在用的时候经常性的报

<000c> l1ctl.c:291 BURST IND: <at> (1428545 = 1077/01/35) (-105 dBm, SNR 3, SACCH)
<000c> l1ctl.c:114 FBSB RESP: result=255

这个错误，着实郁闷，网上也找不到相应的资料，为了方便使用也得先来个临时解决方案啊，写了一个Shell脚本，执行抓包程序后将日志输出，然后检测日志的最后一条是不是包含FBSB，如果包含则删掉日志文件，重启抓包。

因为一个项目的采集需要，所以做一个比较，一开始是使用file_get_contents来抓去，后来为了方便改用了Snoopy库，没事看了一下Snoopy，是风转fsocket实现的，file_get_contents其实也是，后来为了效率问题改用了curl来抓去，但是还会经常性的拖垮服务器。

后来想，如果改用system调用linux的curl命令来执行会不会稳定性高呢？

说来惭愧，接触PHP这么久了，就从来没有写过扩展，这也与实际生产环境有关，至今为止就没有用到要写扩展的示例，但是，不用咱们也不能不会是吧，这就来稍微实践一下，随便在一台LAMP的服务器上进行尝试一下，这次是个入门，至少知道如何操作，例子是个无参的函数，过几天写一个自定义简易的加密函数，再深入研究一下~

这里环境是PHP5.3.3的环境，因为要用到ext_skel，服务器上没有留源文件，在官网下载了PHP5.3.28的源文件，来小介绍一下整个过程。

第一步，进入/home/dev/php-5.3.28/ext，创建文件toryzen.skel 写入：

前几天忽然想到以前看到的一个新闻，关于GSM Sniffing，顺道在网上百度了一下，发现寡人也能办的了，立马入手设备，配置环境，OK，别的不扯了，小介绍一下，主角是OsmocomBB，国外一个开源项目，是GSM协议栈(Protocols stack)的开源实现，全称是Open source mobile communication Baseband.目的是要实现手机端从物理层(layer1)到layer3的三层实现。

设备清单：

1. 摩托罗拉 C118
2. CP2102
3. C118数据线
4. PC

最近手底下的一个项目已经完成了4次迭代开发，基本上到了一个里程碑，但是，在项目落地推广的时候遇到些问题，因为此项目的特殊性，想法是领导提出来的，但是实际使用者又是基层员工，如何让更多的人实际的去用这个项目是个大难题，在翻阅一些资料的时候，偶然发现以前某公司分享的一个会议，迭代会议演示评审系统 （Party Achievement Show），在我们的敏捷开发规范中进行了首次尝试。

这个会议的出现更多的拉近了开发团队与需求方的距离，并且可以团队成员的紧迫感和成就感也都有极大上升

先来说一下前提，我们这个项目是一个内部使用的项目，名为“个人终端”，加上我这已经是第三版了，可惜前两版的内容一点都没有用上，着实有点可惜，这次的阶段性成果不仅在现有PC端有了大的改观，我们还走向了多平台的道路，Android端也横空出世。

最近准备改造以前的一个项目，这个项目是我从半道接手的，消息发送机制是客户端监听自己的10001端口，然后服务端想发送消息的时候，像客户端的10001端口发送socket信息（基于TCP的），从而实现通讯，这样的机制弊端太多了，公司内部有很严格的ACL策略，为此还专门把服务器设置成与所有机器啊的10001端口胡同，这次仅是准备改造，前期研究了一下技术。

也因为这个项目想要放到外网，所以先前的机制根本行不通，所以新机制的一个方案是，基于UDP的通讯，由客户端主动请求服务端，并且定期发送心跳包，为nat下的设备打开通路，服务器监听客户端发来的请求并入库，记录下nat设备上打的洞的IP和端口，在需要发送消息的时候直接回执就行了

可惜实际测试不容乐观，UDP过NAT设备后的丢包率太严重了，如果不仅过NAT设备，则几乎不会丢包。

偶然间翻看自己的一台VPS上的Cron脚本，发现一个每分钟定时跑的脚本，想了半天不知道是做什么的，后来打开发现，原来是N久之前弄的一个监控，当时有5台VPS，4台搭建了Nginx,做负载均衡，1台入口，3台负载，还有1台DB，因为单机经常502,所以做了负载均衡，为了看效果如何，准备监控一下内存和phpcgi,所以就有了这个。

前言

这已经是我第四年写总结了，今年是有点晚了，开始写这个总结的时候已经1月多了，以前的总结都是在1号之前就开始构思，并且争取在1号之前就争取发布了，现在工作与上学的差距就显出来的，没有了那么多的空余时间，多了很多的各类事情，并且越来越多的精力放在工作上，在生活上也没有留下印记，这也是这一年的遗憾，从今年开始就要对此进行一个改观，绝对沿用大三时每月一主题思路，保留下以后生活中的点滴。

2013大总结：

今年的总结沿用去年的章节格式，继续从Life,Hobby,Career三个角度进行总结。

在接触项目管理的这段时间，工期的预估一直以来就是一个特大难题，但是这也是一个必须去解决的问题，为此我们想过N多种的方案，也参考研究了很多的网上的案例，为此，我尝试建立了两种的流程模型。

第一种针对的小型的项目，一眼就能看到项目的结尾，如一个开发某个小型产品，这种模式也是我实际的在项目中使用过，但坏处就是，在项目前期需要投入大量的精力去深入的研究与分析，所以这个也只适合用于小型的产品开发。