背景
Composer is a tool for dependency management in PHP. It allows you to declare the libraries your project depends on and it will manage (install/update) them for you.
–https://getcomposer.org
Packagist is the main Composer repository. It aggregates public PHP packages installable with Composer.
–https://packagist.org
和“用户中心”的目的一样，独立模块，少写重复的代码。但是“用户中心”适合做上层的“Provider”，服务于多个子系统，对于一些独立的项目(外包)就不太合适了，所以，现在需要将一些重复的模块独立成“Package”。
{
可能有疑问了，为啥不先写一系列“Package”，然后在“用户中心”里引用这些“Package”呢？
１、“用户中心”的粒度是某个具体应用，各功能模块里都会包括一个app_id字段；
２、当时没考虑到这些非常独立的项目；
}
技术
composer.json
按照https://packagist.org上的说明，我们需要新建一个composer.json文件，包含包的名字、描述、所需的依赖等等。
需要重点注意的是如下几个
- require
必须的软件包列表，除非这些依赖被满足，否则不会完成安装。
- require-dev (root-only)
这个列表是为开发或测试等目的，额外列出的依赖。“root 包”的 require-dev 默认是会被安装的。然而 install 或 update 支持使用 –no-dev 参数来跳过 require-dev 字段中列出的包。
- Classmap
classmap 引用的所有组合，都会在 install/update 过程中生成，并存储到 vendor/composer/autoload_classmap.php 文件中。这个 map 是经过扫描指定目录（同样支持直接精确到文件）中所有的 .php 和 .inc 文件里内置的类而得到的。
可以用 classmap 生成支持支持自定义加载的不遵循 PSR-0/4 规范的类库。要配置它指向需要的目录，以便能够准确搜索到类文件。
- PSR-0与PSR-4
虽然官方已经废弃了psr0，但是composer还是对psr0向下兼容，所以也花时间从composer的加载代码中了解了一下他们的区别，具体如下：
1.在composer中定义的NS，psr4必须以\结尾否则会抛出异常，psr0则不要求
2.psr0里面最后一个\之后的类名中，如果有下划线，则会转换成路径分隔符，如Name_Space_Test会转换成Name\Space\Test.php。在psr4中下划线不存在实际意义
3.psr0有更深的目录结构，比如定义了NS为 Foo\Bar=>vendor\foo\bar\src，
use Foo\Bar\Tool\Request调用NS。
如果以psr0方式加载，实际的目录为vendor\foo\bar\src\Foo\Bar\Tool\Request.php
如果以psr4方式加载，实际目录为vendor\foo\bar\src\Tool\Request.php
- Files
如果你想要明确的指定，在每次请求时都要载入某些文件，那么你可以使用 ‘files’ autoloading。通常作为函数库的载入方式（而非类库）。
travis-ci
Travis CI is a hosted continuous integration and deployment system.
–https://travis-ci.org/
styleci
StyleCI provides checks for both your open and closed source repos. By analyzing every push or pull request made on your repo, StyleCI ensures that your code is always written against the standards you want it to be.
–https://styleci.io
styleci提供了两种方式配置仓库里的代码检查，一种是在仓库的根目录下新建一个.styleci.yml文件，另一种是styleci对应的仓库里进行设置，详细的配置见configuration
功能
user log 的功能其实很简单，就是记录用户的一些操作，设计时主要包含user_id用户ID, title操作行为, data操作数据, ip来源IP, created_at操作时间；
考虑到方便判断操作的类型（增删改查），增加type操作类型；
方便追踪SQL，增加sql操作语句；
考虑到title, data对后期数据的挖掘不是很方便，比如修改了某一个用户，虽然说title可以填写“修改用户”，data可以填写修改前后的用户信息。但还是需要对title和data里面的数据进行进一步提取才能知道这是用户模块，某某用户。
故增加object操作模块，object_id，操作对象ID；
考虑到日志不需要实时Request.php写库，并且并发比较高，所以扔给队列处理，增加pushed_at入队时间，poped_at出队时间；
还有其它的字段需要依赖于具体的业务，比如接口需要知道是app还是web调用的，可以增加source字段。
所以一个日志表的设计大致如下：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | integer | 日志ID |
| user_id | integer | 用户ID |
| title | varchar | 操作行为 |
| type | char | 操作类型 |
| object | varchar | 操作模块 |
| object_id | integer | 操作对象ID |
| data | text | 操作数据 |
| sql | integer | 日志ID |
| ip | char | IP |
| pushed_at | timestamp | 入队时间 |
| poped_at | timestamp | 出队时间 |
| created_at | timestamp | 写库时间 |
| deleted_at | timestamp | 删除时间 |
在composer的package中对数据表的创建可以先创建可以生成migration的文件，然后再创建migration command，这个command的作用是提供一个命令行（例如：php artisan userlog:migration），用于生成migration，再执行php artisan migration即可创建数据表。
userlog中采用的是队列来记录日志，即新建一个UserLogJob，这个Job的handle中就是将当前日志写入数据表，包含入队和出队的时间。
一个userlog包就这样完成了，详见laravel-userlog。