乐天知命,随遇而安~
最近发表的评论
  • SpaceVim - Like spacemacs, but for VIM at 1周前
  • SpaceVim - Like spacemacs, but for VIM at 1周前

    @SpaceVim 目前最大难处是xshell客户端该如何设置才能让spacevim正常显示。
    xterm256?

  • 2018 年 Laravel 和 Lumen 的运行效率对比 at 4个月前

    lumen,解决realpath问题,我可以把他整成phar包作为lib在老项目比如ci,tp中使用,而laravel则必须全站重构,这是我能想到的lumen的唯二优点了,无状态+快速也算是其一。

  • 一步步教你如何使用 laradock 搭建项目环境 at 4个月前
  • 一步步教你如何使用 laradock 搭建项目环境 at 4个月前

    @jdxia 额,我记得是dev的域名吧。

  • 一步步教你如何使用 laradock 搭建项目环境 at 4个月前

    @jdxia 已合并,非常感谢,一点小建议,一般而言,用test做样例域名会让大多数人比较好理解。

  • 阿熊的 Caddy+Hugo+Acme.sh 配置填坑笔记 at 4个月前

    虽然和php貌似没有一毛钱关系,不过还是转过来了,主要是踩的坑太多,Mark一下。
    :joy:

  • 一步步教你如何使用 laradock 搭建项目环境 at 4个月前

    change_source的默认值我fork的版本已改为true的,所以没有PR
    另外官方v4版目前而言,
    修改源的只有alphine的系统的源,而实际上还有:ubuntu的源,composer的源,nodejs,yarn的源都没有添加对应的处理,我只是借这个参量完善一下对应的处理,但其实理想的方式应该是repo_source='cn'这样的方式,然后不同区域标识可以用不同的源集合。
    也许以后的laradock的版本会完善这部分的工作,目前而言,对国内环境,我改的版本够用,如果有不同区域的需求,自行修改对应上面提到的alphine,ubuntu,composer,nodejs,yarn对应区域的源即可。

  • 一步步教你如何使用 laradock 搭建项目环境 at 4个月前
    RUN if xxx
     RUN sed -i
    ;fi

    关键是Dockfile里RUN是单条Dockfile环境的指令语法,RUN 指令中的内容不可能嵌套 RUN指令,只能是单条的bash语句。

  • 一步步教你如何使用 laradock 搭建项目环境 at 4个月前

    @Aaron 你也可以和官方的repo比较一下我改了哪些内容,定制修改的比较符合我自己的习惯,就没发PR了。
    好像默认的change_source的环境变量没有效果,所以改默认值为true了,不适合发PR,毕竟老外使用国内镜像的还不多。

  • 一步步教你如何使用 laradock 搭建项目环境 at 4个月前

    @Aaron
    是的,根据目前最新的v4的版本重新改的版本
    composer换国内镜像
    node,yarn换国内镜像(淘宝)
    ubuntu换国内镜像
    修复官方的一个change_source的Dockfile中的语法问题。

  • 一步步教你如何使用 laradock 搭建项目环境 at 4个月前

    按国内网络环境fork修改的版本现已更新到最新v4版本

    https://github.com/nickfan/laradock

    可重新star哈 :joy:

  • 分享一下 Laravel、PHPer 面试可能会遇到的问题(已更新部分答案) at 5个月前

    个人观点,

    ucfirst lcfirst ucwords strtoupper strtolower
    
    asort rsort
    ...

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

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

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

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

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

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

  • 关于 MySQL enum 类型的一些测试 at 5个月前

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

  • 关于 MySQL enum 类型的一些测试 at 5个月前

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

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

  • 关于 MySQL enum 类型的一些测试 at 5个月前

    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 8个月前

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

    https://github.com/borislemke/nodejs_vs_php

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

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

  • Web 金字塔式开发框架分层模型概述 at 8个月前

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

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

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