这里收集一下可以长期关注的php开发框架,所谓长期关注,就是说这个框架未来肯定还是有一定市场的,不会过两天就死掉:
1.Laravel
2.Symfony2
3.Yii2
4.Zend Framework
5.Slim
其他框架,例如CodeIgniter,Cakephp等,虽然还会有人用,但是从设计理念上,全然不如laravel这类组件化了的框架。对于我个人而言,越来越喜欢slim,因为它小,它自由,你可以用它做任何事情,它不提供的功能,你只需要composer去安装对应的组件即可。
-
不知道你对Yii2有没有了解?希望能看到你对yii2的梳理#265 restful 2017-04-30 16:38
-
之前一个项目,同事使用Yii开发,就接触了一下,感觉还行,一起写过一个投票页面,对于他而言,熟练上手,而且验证之类的写起来非常容易,但是我没有深入研究,现在已经转前端了,前后端分离开发的情况下,php主要是为了实现后端数据计算实现api,还在使用的是slim,所以可能要让你失望#266 回复给#265 否子戈 2017-04-30 16:44
今天开始看一个轻量级的php开发框架:slimphp,它和我以前接触过的所有php框架都不一样,以前看过的框架动不动就开始MVC,而slimphp一上来是composer,它就像一个库一样,可以由你自由支配,没有特定的文件目录结构,你想怎样就怎样,它只给你提供接口。和express非常像:
1.路由方式
跟express很像的一个地方是,采用->get('/', function($req, $res, $args) {})
2.中间件
除了req和res的地方很像,中间件也很像,甚至也包括一个$next函数。
之所以要看slim是因为我想用它来写一个api server,前端则是在componer环境下去写,到时候会用vue作为前端框架。这样一来,一方面可以让自己学到更多东西,另一方面我是在想,我未来的开发基本上都会基于这种模式,即后台只写api接口,前端会基于最流行的框架去写。现在已经非常明确了,我肯定会选择vue作为框架,如果公司或客户层面要求用react也会用。但是我之前一直对php的框架没有打定主意,最开始想学laravel,但是因为没有赶上好时机,没有在它刚出来的时候就去学,所以也就不想去学了。看到slim后,瞬间就决定,因为我只用php来写api,所以将来只会用slim来写了。什么thinkphp之类的,滚一边去吧。slim配合composer,可以避免laravel的繁复,同时又有巨大的可定制的空间。
搞起!
-
2021.6.5 记 现在我的想法一直。#1056 yuan 2021-06-05 10:16
支持上下文context的debounce
虽然debounce已经被大家玩腻了,但是当我们在一个类里面用的时候,总是还会遇到一些麻烦,比如一个页面有三个来自同一个类的实例化对象,每个对象中对自己的一些操作需要用到debounce,是不是意味着必须将this传入到debounce,从而让每个debounce从属于这个对象?于是我对debounce函数进行了改造,使得它可以不再获得一个函数来执行,而是直接执行函数:
/** @desc ensure a given task doesn't fire so often that it bricks browser performance @param object context: this @param string|function factory: function to run, if you pass a string, it will find context[factory] @param number wait: time to wait, ms @param boolean immediate: whether to run factory right now @usage1: `Util.debounce(this, this.request, 200, true)`, run this.request immediately and never run again in 200ms. use first call in 200ms @usage2: `Util.debounce(this, 'request', 200)`, run this.request after 200ms,time clock will be reset if you call again. use last call in last 200ms @usage3: `var factory = this.alert.bind(this, 'word');Util.debounce(this, factory, 200)`, use bind to pass parameters, if you bind, this will not be change by debounce notice: 1.you can use this in factory function and do not need to use `this.request.bind(this)`, factory will bind context automaticly; 2.you must pass factory function name, anonymous function is not allow; 3.no parameters for factory function, unless you use bind and pass function name; 4.context in arrow function will not change; */ function debounce(context, factory, wait, immediate) { if(typeof factory === 'string') { factory = context[factory]; } if(typeof factory !== 'function') { return; } var queue = context._$$debounce = context._$$debounce || {}; var timer = queue[factory]; var isCallNow = immediate && !timer; var call = function(factory) { // original function if(typeof factory.prototype === 'object') { factory.call(context); return; } // bound function or arrow function factory(); }; var delay = function() { queue[factory] = null; if(!immediate) { call(factory); } }; clearTimeout(timer); queue[factory] = setTimeout(delay, wait); if(isCallNow) { call(factory); } }
使用方法很简单,主要是在类的原型链方法中去使用。
class Cat { walk() {} say() { debounce(this, this.walk, 200, true) } }
这样就可以使得其实例化对象拥有这个debounce,当实例化对象调用say方法时,会立即执行自身的walk方法,但是在接下来的200ms内,不会再执行第二次。
这个用法也简化了underscore中debounce的用法:
// underscore中 var factory = debounce(function() {}, 200, true) factory()
必须先执行一次debounce,得到它的返回值,这个函数才是反复执行时可以被防抖的函数。而采用本文的方法,则可以不再依靠这个第三方变量factory,而是直接执行debounce函数即可。
究其原理,就是在debounce中利用第一个参数context记录了要执行的factory是否是正处于queue中的函数,如果是,就不会被再次执行。这也为什么要求factory不是匿名函数的原因,因为如果是匿名函数,每一个factory都是不一样的。如果想使用匿名函数,应该考虑使用underscore的debounce,本文恰恰是为了解决在同一个实例化对象的不同方法中使用debounce的问题。情景不同,解决方法也就自然不一样了。
放弃使用atom,用回sublime
因为atom是开源免费的,而且界面超级符合我的口味,所以前几个月我一直使用它。但是它最最最大的弊端是性能问题,当一个程序在占用文件时,它会假死,当一个文件比较大时,它是直接死,而且安装插件由于国内网络问题,也基本安装不了。最最最主要的问题还是性能问题,希望atom团队能够解决这个问题,我才会再用回atom。
npm安装node-sass等下载binary加速
国内安装npm包的时候,很多都需要从GitHub下载binary文件,即使你把npm的registry设置为国内的镜像,binary的url是程序设定的。不过目前最重要的几个包,都可以通过修改环境变量来让下载从国内的镜像下载,在.npmrc加入如下内容:
registry=https://registry.npm.taobao.org/ sass_binary_site=https://npm.taobao.org/mirrors/node-sass/phantomjs_cdn url=http://cnpmjs.org/downloads electron_mirror=https://npm.taobao.org/mirrors/electron/ sqlite3_binary_host_mirror=https://foxgis.oss-cn-shanghai.aliyuncs.com/ profiler_binary_host_mirror=https://npm.taobao.org/mirrors/node-inspector/
这样,在npm install node-sass的时候,就会走国内的镜像下载binary。
windows上升级npm
公司也很醉,开发环境一直要求node v0.12.x版本,不然node-sass不支持。而windows上node和npm是一起安装的,所以npm其实是安装在了nodejs的安装目录下,有一个npm和npm.cmd。网上的npm升级都很简单:
npm install -g npm@latest
然后,就没有然后了。很多人根本升级不成功,跟我一样,于是我就谷歌搜啊,各种说法都有,最后没一个解决的。于是自己思考一下呗。
为什么用npm -g安装的包可以使用全局命令呢?因为有环境变量这个东西,路径设置好之后,执行命令会先到这个路径下去看看,有可执行的就执行。npm的包路径是C:\Users\youname\AppData\Roamingpm,所以npm -g安装的包都产生了对应的.cmd文件,在命令行就可以用全局命令。但是npm本身这个包不能这么搞,npm install的包全部在这个路径下,但是你执行npm命令的时候,其实是使用的node安装目录下的那个npm。怎么解决?把node安装目录下的那个npm删掉咯。于是愉快玩耍。
参考:http://skychang.github.io/2014/09/13/npm-%E7%82%BA%E4%BB%80%E9%BA%BC%E5%9C%A8Windows%E5%BA%95%E4%B8%8B%E6%9B%B4%E6%96%B0npm%E7%84%A1%E6%95%88/
怎样的代码风格才算好的代码风格
以前不觉得,现在才发现为什么很多程序猿都喜欢某种代码风格,原来是因为键盘的原因,举一个简单的例子,函数名使用驼峰还是使用下划线?这个问题似乎没有答案,但对于每天敲键盘的程序员而言,如果写代码的速度足够快,就会发现,使用下划线更省力,长时间使用驼峰命名,就会发现手指比较累,因为驼峰命名有一半的输入需要用一只手的两个手指,而下划线输入需要两只手的各一个手指,看上去没什么关系,但是从手指的角度看,两只手的各一个手指显然会更省力一些,如果一天24小时写代码,速度够快的话,就会发现这其中的奥秘。为此,也有一些键盘商专门为程序猿开发了专用键盘,就是为了更加合理的布局各个键,从而让程序猿更加有效率且舒适的写代码。