Rust 2018 edition 虽然实际发布时间还没到（本文开始写的时间是 18 年七月底），但是有些 2018 edition 的特性已经随着 Rust 的新版本发布放出，这些已经进入 stable 版的特性必然是应当了解并学习的。其中就有两个本文所要讨论的关键字 —— impl 和 dyn。
最先出现的 impl 是大家已经熟悉的关键字，不过这次这个关键字除了用于表示实现一个 Trait，还有新的意义，即表达一个既存类型（Existential types），我们可以理解为一个实现了一个特征的 具体对象。

官方原文介绍：impl Trait https://rust-lang-nursery.github.io/edition-guide/2018/transitioning/traits/impl-trait.html
impl Trait is the new way to specify unnamed but concrete types that implement a specific trait. There are two places you can put

lets-understand-new-keywords-those-impl-and-dyn-of-rust-2018-edition

理解 Rust 2018 edition 的两个新关键字 —— impl 和 dyn

最近开发后端 UCenter 服务，考虑到该服务核心逻辑变动相对少，稳定性要求高，单点处理能力要强，且 IO 瓶颈较少（大多缓存），有较多的校验和加解密工作，因此需要使用性能更为强劲的语言，最终考虑使用 Rust（无 GC、内存安全、性能与 C/C++ 差距不明显）以及其最近风头正劲的基于 Actor 模型的 Web 框架：Actix-web。对于框架和语言的介绍我会另起文章，先说说这个用户中心服务。
用户中心服务提供平台下属多个应用的统一授权工作，无论是第三方登录授权（如基于 OAuth 的授权或对外部以 OAuth 支持）、SSO（Single Sign-On）以及解决跨应用用户数据共享、互通等。虽然服务核心逻辑十分稳定，但对于各类子应用接入会有较多的拓展需求，例如不同应用的专用数据表的访问、多协议适配等。对于动态语言或存在虚拟机的语言而言，动态库加载相对简单，但对于 Rust 这种静态和无（或极小）运行时语言，拓展则相对困难。不过 Rust 提供了 FFI（Foreign Function Interface）支持，我们则利用这个实现我们的需求。

how-to-implement-dynamical-loading-and-plugin-manager-for-rust

Rust 实现动态库加载和基于此功能实现的插件管理

博客已长草，这一年多以来变化太大，变动太多，精力无比分散。但是过了这么久发现还是写博客文章能让人沉淀下来，静下心来好好总结之前所学。
所以接下来，争取每月一篇以上的更新，且希望各位支持。如果有什么问题希望能得到更完整的文字教程，可以联系我（Email 在 关于 里），我会根据你们的情况准备文章。
之前说要对博客进行改动也废了，不过不代表不会有，现在这个版本有点旧，而且功能也有严重的缺失，之前的评论系统由于多说的悲剧而悲剧，因此这次我打算自己实现了（本来也不复杂，还是太懒）。这次可能带来的东西有点和以前不一样，所以各位保持关注。
对这一年以来给我来信支持的朋友表示感谢！

sorry-about-that-no-update-blog-long-time

博客长草，非常抱歉，从今天起重新开始更新

通过本文了解 git server 和 SSH 授权实现原理，如何使用数据库而不是 authorized_keys 来管理用户，并实现更精细的自定义访问权限管理。本文不会实现完整的 Git 服务，但可以通过本文了解实现原理。

gitlab-like-implementation-and-git-server-or-service-implementation

从 gitolite 实现原理拓展 gitlab 及其他 git 服务的实现原理

摘自 https://serverfault.com/questions/546966/whats-removing-stuff-from-var-run-at-reboots-from-a-fedora-machine：
The software should define what directories it needs in /run (which replaced /var/run in Fedora 15) by placing a configuration file in /usr/lib/tmpfiles.d. During the boot process, systemd-tmpfiles populates /run based on that confguration.

其中解释了 /run 是挂载在临时文件的系统里的，即在系统启动后，添加在里面的数据、文件都是写入内存的，因此重启后自然不存在。
懒得去翻的，本文直接给出一个便于快速查阅的方案。

why-lost-tmpfile-after-system-reboot

为什么重启后 /run 下的文件不在了？

仓库地址 https://github.com/chongyi/inspirer2

blog-refactor

博客代码重构中

今天在 SegmentFault 看到了类似问题，查资料回答那个问题后，决定留个笔记。
我们在计算金额时，难免存在保留位数有限，计算结果需要取舍的情况。往往在电商、银行系统中，金额是以整数形式保存，单位为货币最小单位，例如分。但是在结算时额外的参数如折扣、利率、税率等存在着大量的浮点数，计算结果则需要转换为整数。
简单处理一般是四舍五入，但是这样存在很明显的问题，就是 “入” 的概率大于 “舍”，明显的，遇到 1、2、3、4 舍，遇到 5、6、7、8、9 入，粗看这种就可以发现问题。如果想要两边平衡，则 “四舍六入” 才是合理的，但是，5 怎么办？

how-to-ensure-accurate-for-digital-transformation

四舍五入不可取！结算金额，如何保证精确？

来继续填坑（上个月没发，因此这个月至少两篇）。

上一篇 laravel 学习笔记 —— 查询构造器（下） 中我们正在开始分析查询构造器的 where 方法，作为出场率最高的方法，其中相关的玩意儿足以帮助我们去理解整个组件大致的设计思路和实现细节。由于整体分析实在是太过麻烦（我其实就是懒），因此我们在上一篇的末尾提了三个问题，本文也将顺着这三个问题来进行解析，当然其余的思路类似的，就不在赘述，毕竟精力有限。
上一篇提到的问题是：

where 方法中多余的参数是干什么的
方法中的代码为什么要拆分（或者封装）的那么细 ？
Expression 这个类是干嘛的 ？

我们就从多余的参数是做什么的开始吧。

where 方法所包含的参数有 4 个（Laravel 5.1，这几篇文章都是基于这个和 5.2 两个版本讲述），分别为: $column, $operator, $value, $boolean 。
顾名思义，第一个参数必然是指的字段名称，第二个参数则是操作符，第三个是值，第四个指的是布尔逻辑。除了第一个参数，其余皆包含默认值意味着可选填。

learn-laravel-query-builder-part-2

laravel 学习笔记 —— 查询构造器（下）

Laravel 框架中有一个非常有趣的功能，就是 `HTTP 中间件`，我们在定义路由的时候，通过中间件对访问进行过滤。来自外部的请求首先经过全局中间件，若通过，则会继续穿过层层路由组所设置的中间件，在到达目的路由，当然，目的路由也可能定义了个中间件，通过后，该路由的处理对象（如控制器），得到的就是一个经过过滤的请求了。本文主要就是讲述该组件如何实现的。

realization-of-pipeline-component-for-laravel

Laravel Pipeline 组件的实现

现在，Laravel 可以有更多可能。我基于 swoole 对 Laravel 框架的底层做了些许调整，使得其在能够运行至 Swoole 提供的强大特性下的同时，又能够不改变原有的开发模式（但是思路可能应该有些许调整了哦~）。现在已经有了一个可用的雏形，项目地址：https://github.com/chongyi/swoole-laravel-framework

laravel-new-look-base-on-swoole

让 Laravel 变得更富有可能 —— 基于 swoole 的 Laravel

我希望基于 Laravel 构建一个开源的电商平台，初始目标是能够令其适用于中小型的电子商务网站需求，同时也具备快速改造成内容管理系统或其他类型平台的能力。该项目将会对组件进行细分，在初期阶段作为整体开发，后期会将里面比较独立的部分拆出成为公共组件独立开发。

plan-to-implement-an-electric-business-platform-base-on-laravel

计划基于 Laravel 实现开源的电商平台

当下所有包含数据库组件的框架，都提供了一套流畅的操作方式去生成查询语句，这一部分我们称作 查询构造器 。查询构造器的存在，使得在数据库操作这一层面彻底的和原生开发区分开来。原生开发中，查询语句都是人为地根据业务需求手工写的，没有对查询语句进行规范的封装（即使有也不是人人能够做得到且做得好），随着项目扩展，这种原生的写法会导致项目愈发难以维护，而且由于操作原始，更加容易引发很多不必要的 BUG 以及安全隐患。查询构造器针对每一类语句关键字进行封装，通过流畅的链式方法组合，形成一个树状的数据结构，最终由生成器生成目标查询语句。

我向来认为 Laravel 框架的组件永远不是最优秀的，但由于其他框架或多或少不优雅、实现差、功能残缺，才使得 Laravel 的每个组件无论是单个拿出来看还是组合起来看，都是那么的好用，这其中的典型就是 查询构造器。说实在的，大多数优秀框架提供的查询构造器功能都已经十分完善，基本上在绝大多数业务上可以替换手工书写查询语句，但是

learn-laravel-query-builder-part-1

laravel 学习笔记 —— 查询构造器（上）

所谓万丈高楼平地起，再强大的功能组件，也是建立在许多功能很基础的模块之上。而且越是强大、富有扩展性，则拆分越细，分层越明显。Laravel 的许多组件都是这样，数据库组件当然更能直观体现出来这种设计思路。关于分层，我在上文已经给出了一定的解释，不再赘述。本文是对数据库的连接层进行讲述，在此，希望各位确保对 PDO 已经有了一定的认识和理解。


learn-laravel-database-and-model-connector

laravel 学习笔记 —— 数据和模型之数据连接层

自上一篇 《laravel 学习笔记 —— 神奇的服务容器》 已经有一年了，很多人都问过关于数据库部分的文章什么时候出来。其实不是不想写，而是没法写，因为当时大部分特性都没用到，以至于我无法以笔记形式给出。经过一年时间，laravel 已被我运用在很多类型的项目里，或多或少也对数据库组件了解的比较完整了，是时候完善学习笔记序列重要的环节之一 —— 数据库 部分。

Laravel 有三宝，路由、容器和 Eloquent ORM，Eloquent ORM 实际上是 Laravel 框架数据库组件的一个部分，也是最为重要和常用的，所以我们在说 Laravel 数据库组件时，往往指的是 Eloquent ORM。当然，数据库篇的文章肯定要全面讲述，这样有助于理解，也能帮助一些在这一块遇到问题的朋友。
数据库组件是一个比较独立的组件，其仅仅

learn-laravel-database-and-model-foundation

laravel 学习笔记 —— 数据和模型起步篇

潜心工作难免疏忽，毕竟没法全心全意去维护博客。
不过心还在，近日仔细构思了一下，正在进行一系列重构。更多人在这个博客上可能更为关注 laravel 的一些内容。但是只是会用 laravel，也永远只会停留在浅薄的认识，我希望借助这个小小的地方发表我作为 PHPer 更多的愿景。PHP 也许不是最好的语言，但是却是一个值得把玩的语言，因为借助这门语言，可以很容易以此为跳板，去开启更多地新世界的大门。
近日的工作，忙碌中出现了很多失误，反思总结后，才更加坚定了走得太快迟早会扯蛋的这一认识。于是应当做出一些改变，也正如无数人反应的样式问题。
不过还是要说一下，，黑色的样式是为了便于长期在深夜工作的我眼睛着想。。。不过考虑到大家一般在白天看，我还是会调整回来的。
哦对了，这只是一篇小记，没什么干货。:joy: :joy:，干货很快就有了，别急。

please-wait-for-inspirer-s-new-look

请等待一个新面孔

一直嫌弃 MySQL 的编译安装，原因很简单，依赖复杂、容易出错，总之就是麻烦。但这些天由于需要必须编译安装，被迫阅读相关文档，发现现在的 MySQL 安装变得十分简单和容易。

make-install-mysql-5-7

MySQL5.7 的编译安装

最近由于项目开发需要，手机客户端和网页端统一使用一套接口，为保证 会话（Session） 能够正常且在各类情况下兼容，我希望能够改变 SessionID 的获取方式。默认情况下，所有网站都是通过 HTTP 请求的 Header 头部中的 Cookie 实现的，通过 Cookie 中指定的 SessionID 来关联到服务端对应数据，从而实现会话功能。但在实现这一系列功能后出现了一个小问题。。。

extension-laravel-session-in-failure-problem-caused-by-the-default-session-middleware

扩展 Laravel 默认 Session 中间件导致的 Session 写入失效问题

之前安装出现了很多问题，主要是内核版本的问题导致的（具体情况大概是找不到 Kernel Header）。这回重新走了一遍过程，发现问题解决，原来是中间搞忘了重启导致的，特此在这里记录一下。

install-vmtools-into-centos-7-on-vmware

VMware 下 CentOS 7 中安装 vmtools

之前有一篇 《PHP 7 开发版本编译安装》，不过那时候连 RC 版都不是，昨日正式版已经在 Github 上发布（参见： https://github.com/php/php-src/releases） ，于是乎迫不及待的在此分享其编译安装的过程。
其实 php 的编译安装相当简单，且每个版本差异不大，正因为如此之前版本的编译安装过程也可以参考，当然，需要注意的是，每个版本的编译参数存在部分差异，以 ./configure --help 中具体描述的编译配置参数为准。
本文中系统环境为 CentOS 7 64bit，如使用其他系统环境的，请注意在某些 依赖安装环节  的差异。

make-install-php-7

PHP 7 的编译安装

在做 web 端开发，常常和各种请求打交道。HTTP 协议中，常见的请求不外乎是 GET，POST，PUT，DELETE，HEAD。其中，GET、PUT、DELTE、HEAD 都是幂等操作，而 POST 则不是。那么什么是幂等操作？其存在的意义和网站的设计与架构有什么关系呢？