一直都在用别人的框架,虽说知道原理,但是没有实际去尝试写一个看看,下午没事看了一下CI的源码,确实短小精悍,萌生了自己尝试一下的念头,花了几个小时谢了一个超级简单的MVC框架,实现了基本的MVC,没有路由分发,没有安全验证,没有考虑扩展性,只支持Mysql等等等等,后期哥好好规划给整牛逼了,目前是0.0.1,嘿~
核心一共4个文件
Bootstrap.php
Controller.php
Model.php
View.php
先发上来让大家瞅瞅~
爱技术,好产品,探管理,享生活
一直都在用别人的框架,虽说知道原理,但是没有实际去尝试写一个看看,下午没事看了一下CI的源码,确实短小精悍,萌生了自己尝试一下的念头,花了几个小时谢了一个超级简单的MVC框架,实现了基本的MVC,没有路由分发,没有安全验证,没有考虑扩展性,只支持Mysql等等等等,后期哥好好规划给整牛逼了,目前是0.0.1,嘿~
核心一共4个文件
Bootstrap.php
Controller.php
Model.php
View.php
先发上来让大家瞅瞅~
公司内部一直是在用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号之前就争取发布了,现在工作与上学的差距就显出来的,没有了那么多的空余时间,多了很多的各类事情,并且越来越多的精力放在工作上,在生活上也没有留下印记,这也是这一年的遗憾,从今年开始就要对此进行一个改观,绝对沿用大三时每月一主题思路,保留下以后生活中的点滴。
今年的总结沿用去年的章节格式,继续从Life,Hobby,Career三个角度进行总结。