职尺路杂想
磕磕碰碰把软件开发好，固然是一个令人喜悦的事情。
一方面为软件可以上架而开心，另一方面软件的幼稚感令我十分的担忧。
从产品角度谈谈，自己觉得还有一下一些问题
Docker 初步试玩
昨天调试完Codeship和EC2的连接后开始尝试，连接Docker
Docker之所以有用，是因为把代码从一个机器迁移到另一个机器经常是困难的。它尝试去使得软件迁移的过程变得更加可信和自动化。Docker 容器可以移植到所有支持运行 Docker 的操作系统上。
简答一点，我直接安装 Docker Toolbox.
我们使用Terminal进入Docker
codeship 自动部署 - 持续部署
登入codeship，trivisCI，CircleCI任意一个，这三个都是可以持续集成的管理工具
本文暂时以Codeship为例子进行配置
登入
codeship，绑定github或者bitbucket，选择一个项目修改
README，加入Codeship Status，如在
Project Configyration中配置test setting和deployment自行配置 测试代码
配置 部署配置
Add new deployment pipeline
选择需要部署的
分支，如master选择部署
codedeployAWS Access Key ID， 在IAM上建立的用户
AWS Secret Access Key， 在IAM上建立的用户
Region，如
us-east-1AWS上Codedeploy的应用的名字Codedeploy上组的名字S3的名字
codeship 自动部署 - Codedeploy
上篇我们配置了一大串的东西基本完成的AWS的配置，接下来我们可以试一下开始部署。
- 进入服务器
ssh -i **.pem ec2-user@ip地址
在代码文件中创建appspec/yml
codeship 自动部署 - AWS 配置
今天基本理清了CodeShip和CodeDeploy的用法。
在IAM的用户中(USER)创建一个用户，暂时我就把它命名为codeship 。该用户是给Codeship做部署用的。
在IAM中创建三个策略(Proliies)
持续整合＆持续交付
在公司继续打杂
公司准备弄一套自动部署系统，这两天看了一堆的资料
持续部署：业界没有统一明确地定义，简单理解为将集成结果部署到不同的环境供用户使用，并且立即反馈部署结果的实践，其中不同的环境包括：开发环境、测试环境、预发布环境、生产环境
持续部署两个核心要素：持续、自动化，自动化是持续的基础
人既然知道努力就可以进步，为什么还是会不努力？
因为缺乏立竿见影的时效性。
让我们看看人都喜欢做什么：
旅行，很多人喜欢旅行，到了地方，疯狂的拍照留念，吃好吃的，一个地方最重要的景点，可能一天就收在自己的相机里了，这是时效性。
赌博，你把筹码放上去，下一秒就知道输赢，就算去参加世界扑克大赛，从六千多个人里决出胜负也只要七天而已。这种及时反馈的游戏让人乐不思蜀，不用坐在那里拼命工作才能拿到月终那点薪水，坐在这里，搂着美女，谈笑风生，钱就流进来了（当然也可能流出去）。
如果你想追随梦想，就要心无他念
本文源自知乎上的一个问答贴《25岁，开始害怕自己到30岁还碌碌无为，却不知道如何前进？》，题主的补充：
现在的工作不温不火，重复工作，跟公司领导谈了谈，领导说，如果你内心安于这份工作，这辈子也就这样了，需要你自己去学。 我想学，可是我明白自己不想干这一行，但是又不知道自己该从事什么行业，不知道学什么，有前进的动力，却没有前进的方向？ 很多回答的人都觉得我就是在空想，其实我已经在尝试了，我已经买了书，报了个班，我现在在尝试发现自己感兴趣的行业，以前大一大二的时候自学过不少自己感兴趣的东西。
我们的大脑就像一个装满大黄蜂的救生球，其中有数百种不同的力量，让我们前往不同的方向。