你的收入，为什么还没有指数增长？
两个乞丐在比划说，我要是当上了皇帝，我要饭时候的那个碗，必须是纯金的。
- 打造自己能力的”单品爆款”,要专注,专业需要时间的积累.
- 做有价值的事,让自己增值.
- 经常复盘,我们要在有限的时间里，多做些战略上的努力，而不是战术层面的付出。
原文
Saas产品如何运营
在大数据时代，每家公司都要有大数据部门吗？
大数据都知道是一个方向,问题是谁能站在浪潮之巅?
原文
邮件营销平台实践
没接触过这个领域,长了点见识.
邮件营销平台实践
直播技术
代码居多
原文
深度学习主题
下周专题深入研究
原文
Git配置管理
git的配置管理和SVN有较多不同.SVN默认有三条配置流,trunk,branch,tag. git的master并不是svn的trunk,趋同于svn的tag,是对外可发布版本的最终标示,是一个完整的可部署的生产版本.
以下是一个不错的git配置管理模型:
- feature（多个、玫红）。主要是自己玩了，差不多的时候要合并回develop去。从不与master交互。
- develop（1个、黄色）。主要是和feature以及release交互。
- release（同一时间1个、绿色）。总是基于develop，最后又合并回develop。当然对应的tag跑到master这边去了。生命周期很短，只是为了发布
- hotfix（同一时间1个、红色）。总是基于master，并最后合并到master和develop。生命周期较短，用了修复bug或小粒度修改发布。
- master（1个蓝色）。没有什么东西，仅是一些关联的tag，因从不在master上开发。
在这个模型中，master和develop都具有象征意义。master分支上的代码总是稳定的（stable build），随时可以发布出去。develop上的代码总是从feature上合并过来的，可以进行Nightly Builds，但不直接在develop上进行开发。当develop上的feature足够多以至于可以进行新版本的发布时，可以创建release分 支。
release分支基于develop，进行很简单的修改后就被合并到master，并打上tag，表示可以发布了。紧接着release将被合 并到develop；此时develop可能往前跑了一段，出现合并冲突，需要手工解决冲突后再次合并。这步完成后就删除release分支。
当从已发布版本中发现bug要修复时，就应用到hotfix分支了。hotfix基于master分支，完成bug修复或紧急修改后，要merge回master，打上一个新的tag，并merge回develop，删除hotfix分支
主分支:master,develop, master分支为稳定版本,develop为整合分支可在之上进行日编译和持续集成.
辅助分支:feature(功能开发),hotfix(热补丁),release(发布整合),生命周期较短
feature 分支使用规范：
- 可以从develop分支发起feature分支
- 代码必须合并回develop分支
- feature分支的命名可以使用除master，develop，release-，hotfix-之外的任何名称
release分支使用规范
- 可以从develop分支派生
- 必须合并回develop分支和master分支
- 分支命名惯例：release-*
release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、 编译时间等等）。
当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建 release分支了。
成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。
hotfix分支
使用规范：
- 可以从master分支派生
- 必须合并回master分支和develop分支
- 分支命名惯例：hotfix-*
和release分支一样hotfix分支都会产生新的版本号.
人员权限
开发人员:feature,hotfix
技术经理:feature,develop,hotfix,release
运维:release,master
测试人员:develop,release,master