乐天知命,随遇而安~
专栏文章
最新评论
  • 分享一下 Laravel、PHPer 面试可能会遇到的问题(已更新部分答案) at 2017-12-13 09:48:10

    个人观点,

    ucfirst lcfirst ucwords strtoupper strtolower
    
    asort rsort
    ...

    这类纯语法函数类的考题实在是没啥意义,我们找的是工程师,不是手册。
    楼主的内容更多是笔记而不是实战,平时积累需要,更多需要的是理解。

    从面试考官的角度来看,我部分的面试方法:

    1. 让面试的人描述清楚一个实际的场景用最简洁的方式如何组合调用哪些方法/函数可以解决场景中的问题?这个可以考察面试者对语言本身的熟练度。
    2. 同样的场景如果使用开发框架如laravel或者ci/Yii/swoole之类的可以如何更高效的解决?如何将此类问题组件化配置化?这个可以考察面试者对框架的部分功能的熟练程度。
    3. 同样的场景如果需要提高整体QPS性能可以从前后端分别做哪些优化?这部分可以一定程度上综合考察面试者对前后端语言、算法、通讯协议层面的能力。
  • 关于 MySQL enum 类型的一些测试 at 2017-12-06 07:42:16

    @leo 我的观点是可维护问题,enum本质上和tinyint没啥区别,字面量更好解读数据而已,解读数据的述求通过comment注释说明也可以解决,但维护层面就像你文章头上测试的

    1. 在原 enum 值列表中间新增值需要全表扫描并更新,成本较高。
    2. 删除一个没有用过的 enum 值仍需全表扫描,成本较高,但还在可接受范围内。
    3. 删除值列表中间的值需全表扫描,成本较高

    可读性既然可以通过注释曲线救国,
    而且维护导致的性能成本的升高会有一个非线性的增长(修改enum值列表非追加时)虽然是少数场景
    个人的观点是不如tinyint+注释简单粗暴点。

  • 关于 MySQL enum 类型的一些测试 at 2017-11-29 15:01:18

    @leo 这个你自己测试的索引维护的问题是故意漏掉不提么?嘿嘿~~

  • 关于 MySQL enum 类型的一些测试 at 2017-11-29 14:31:24

    @leo
    个人认为
    从数据可读性、索引维护难度、数据库迁移(移植)问题、索引效率、人员培训多个方面综合比较而言enum枚举字段的优势和使用tinyint相比并不占优。

    另外楼主的cas client拖更已然成梗了~~:)

  • 关于 MySQL enum 类型的一些测试 at 2017-11-29 14:04:01

    migration的enum类型有一种workaround方法解决:
    在你的Migration的类文件中初始化时将此类型注册为string

        public function __construct()
        {
            DB::getDoctrineSchemaManager()->getDatabasePlatform()->registerDoctrineTypeMapping('enum', 'string');
        }

    的方式解决。
    虽然个人觉得还是用tinyint的类型替代会更好,数字的取值含义,我一般建议在column的comment注释中分别说明:

    order_status ->comment='单据状态#0:draft/1:submit/2:approved';

    其中数字后面的是这个值的代码中的字面标识量,取值的含义比如draft草稿,submit提交,approved审核通过的多语言翻译可以在i18n中定义,
    而相关的使用可以在Model/Repository中定义

    const INDEX_ORDER_STATUS_DRAFT = 0;
    const INDEX_ORDER_STATUS_SUBMIT = 1;
    const INDEX_ORDER_STATUS_APPROVED = 2;
    
    const LABEL_ORDER_STATUS_DRAFT = 'draft';
    const LABEL_ORDER_STATUS_SUBMIT = 'submit';
    const LABEL_ORDER_STATUS_APPROVED = 'approved';
    
    // 用于根据index数字查找字面标识>显示输出翻译
    protected static $indexLabelMapOrderStatus = [
        self::INDEX_ORDER_STATUS_DRAFT=>self::LABEL_ORDER_STATUS_DRAFT,
        self::INDEX_ORDER_STATUS_SUBMIT=>self::LABEL_ORDER_STATUS_SUBMIT,
        self::INDEX_ORDER_STATUS_APPROVED=>self::LABEL_ORDER_STATUS_APPROVED,
    ];

    上面的这段代码中【字段名】-【字段字面标识】-【枚举取值】的相关const定义和字典定义其实都可以通过数据库结构定义信息自动代码生成

  • 感觉 ThinkPHP5.1 越来越像 Laravel 啦 at 2017-09-19 09:40:08

    php虽好,走着走着就出门右拐了~~~

    https://github.com/borislemke/nodejs_vs_php

    还怼啥怼,何必呢?何苦呢?

    在不知不觉中,偶是来歪楼的:)

  • Web 金字塔式开发框架分层模型概述 at 2017-09-07 14:06:26

    web服务采用金字塔式分层其实是业务和交互层面而言最容易理解(舒服)方便的一种方式
    如果业务多了以后其实还是有很多细节可以重构的:

    1. 各个业务内部服务分层管理消息化对接
    2. 对外统一提供带QOS控制的RPC接口(即大前端的视图层/接口层)
    3. 接口设计层面尽可能采用请求、响应消息模式、队列化、异步化的方式
    4. 业务流程中各个分支业务接口调用分等级,非必要支线事务可以采用异常捕获事后回推补偿来解决问题。
    5. 各业务服务的调用严格限制超时即异常终止并记录。
  • Laravel 文档阅读:国际化 at 2017-09-07 13:52:49

    多语言对于国内的业务项目最难的是基本上视图层都是公司里的初中级开发人员编写的页面数量最多,而对应的英语水平层次不齐,规范执行的彻底性也比较难保证,项目一赶进度就变成了先中文写页面有需求了再做国际化。
    让英文字面做key,这最后搞出来的key是惨不忍睹,还是规范langkey比较重要。

  • Caddy 中文文档 翻译中~~(自带 HTTPS / HTTP2 ,安装只要 10 秒的神器) at 2017-09-04 22:50:02

    还支持hugo,尼玛这是来秀的节奏啊~~

  • 给阿里云 VPC 中的 Ubuntu ECS 配置自定义 DNS 服务器 at 2017-08-27 12:45:29

    吃瓜群众坐等laravel CAS Client

  • pm2 进程管理器的使用 at 2017-07-26 10:38:24

    这字符是吃多了么?全角英文?

  • 手把手教你如何构建一个优秀的开源项目 at 2017-07-13 11:42:56

    有个开放的心态很重要,另外一点就是你没法满足所有人,也没有义务如此,手工赞一个。

  • tastphp,为现代化的 phper 准备的 PHP 框架 at 2017-07-11 20:22:12

    代码的TestCase实在是少之又少啊~~

    • Twig
    • JWT
    • DBAL

    这几部分相较于laravel而言,我想楼主框架的用意,更偏向于业务标准化

    laravel的blade更灵活和轻量化,twig还是偏重于功能性和安全性

    JWT替代session基本上是后续接口化无状态话开发的一个起点。

    DBAL 我没看到src中这部分的代码,但从实践上来说数据库抽象层的概念更偏向于DataMapper也就是Doctrine的EntityManager的概念,相对于Laravel的Eloquent的ActiveRecord模式而言少了点灵活性,不过约定做好了也是一把利器。

    其实用框架不太计较性能的话,个人更偏向于对laravel做深度定制,JWT不是问题,DBAL这层改用EntityManager也不是不可能,Twig整合到laravel例子和组件也不少。

    laravel之所以成功就是像 Rasmus Lerdorf 在最近的phpcon上说的那句话:

    PHP is really good at running really bad code really well

    laravel的灵活简单虽然和工业化标准化有点相悖,但于个体化开发用户而言获得的是撸码的愉悦和快捷解决问题,同时也允许团队用户根据各自的规范去做定制。

    个人认为与其在各个框架组件中挑挑拣拣再撸一个更标准更普适的轮子出来,不如做一些约定原则指导下的Best practices供大家参考更好。

  • API 文档神器 Swagger 介绍及在 PHP 项目中使用 at 2017-07-04 17:33:27

    @leo 这两者又不冲突,cas客户端还是要滴啊,
    oauth的场景和cas还是有差别的啊。
    改个修复已知bug支持laravel的cas客户端还是很有用的哦,嘻嘻~~

  • API 文档神器 Swagger 介绍及在 PHP 项目中使用 at 2017-07-04 17:27:13

    @leo 虽然Swagger 是神器,但我是来歪楼的,:boom:
    说好的laravel的cas客户端呢~~~ :pig:

  • 把 LaraDock 的 v2 版本修改了一下,换成国内镜像 at 2017-06-22 23:04:23

    。。。这我还真没遇到过。。。。,你用官方的版本试试呢?

  • 把 LaraDock 的 v2 版本修改了一下,换成国内镜像 at 2017-06-19 16:38:20

    @ralph docker toolbox在virtualbox的这部分,我自己本地是mac,也没有win10home版环境测试你的问题,或许你可以在laradock官方的issue列表里查找一下你的问题的答案或者发起issue等待一下别人的回复。

  • 把 LaraDock 的 v2 版本修改了一下,换成国内镜像 at 2017-06-19 16:21:59

    @ralph 据我所了解到的,win10非专业版 应该是没有支持 hypervisor 轻量级的虚拟技术
    你只能用 docker toolbox(virtualbox)的版本

    file

  • 把 LaraDock 的 v2 版本修改了一下,换成国内镜像 at 2017-06-17 17:42:45

    @ralph 能说具体点么,比如贴出你的docker-compose.yml的配置和你运行命令的错误提示贴图。

  • 新轮子求一波关注:七牛云存储引擎 Flysystem 插件 & Provider for Laravel at 2017-06-03 10:35:11

    file
    @overtrue 以前往s3上传文件要通过:

    $disk->getAdapter()->getClient()->getObjectUrl($bucket, $filekey);

    来获取s3的静态文件访问地址,
    不知道qiniu的这个服务接口如何获取?