Why·Liam·Blog

虽然我有美国研究生的学士学位，但是我感觉自己还是没有读过研究生一样。

我同学在香港读书的时候一直感叹研究生对他的改变。其实我一直不能理解其中的关系。

知道现在我有点是懂非懂的有一些感慨。

读不读研其实是个人的问题，有的人急着出来工作，有点人选择继续深造。

我身边有本科 GPA 低，但是去了跨国公司做高管，做经理的；也有放弃腾讯的 offer 毅然地去读研的。

今天看到有人因为 hexo 文件遗失 以前的文章全没有了 所以我准备在 Github 备份我的代码

1. 本地编写文章
2. push 到 Github
3. Travis CI 检测到代码变化
4. Travis CI 构建代码环境，编译代码，生产博客文件，并自动部署

顾名思义，Travis CI 是一个持续集成 (Continuous integration，简称 CI) 的工具。它可以在公共的 Github 仓库上免费使用。

首先去 travis-ci 官网，点击右上角 Sign in with GitHub 通过 github 授权登录。然后去到个人信息页面，开启需要使用 travis 的项目关：

瓦片地图十分有趣，我今天第一次了解

如今互联网地图的地图内容分为两种，一种是栅格地图瓦片，一种是矢量地图瓦片。

栅格地图瓦片是一种比较传统的模式，将矢量数据渲染成为 256×256 像素大小的图片。前端 js 地图框架，如 openlayer 和 leaflet，按一定规则编排显示，如百度地图，高德地图，天地图等。栅格瓦片地图的渲染技术已经成熟，可以实现栅格渲染，矢量渲染两种。参考笔记 mapnik 笔记一: 入门及 python 接口使用。

矢量地图瓦片是一种新颖的模式。地图数据会以 json 等格式分块地传输过去，在浏览器端利用前端框架将地图在显示出来。在这个基础上，你必须懂得 canvas。整个展示的过程对点线面的渲染有很严格的规定。总体来说，矢量瓦片的数据传输量少，服务器压力小。方便渲染成为各种各样的地图，所以这也是为什么 Mapbox 首推 Mapbox GL 的原因，腾讯地图使用矢量渲染的原因。而且现在移动端不断利用矢量瓦片的技术，考虑到导航时候，需要将地图旋转成为伪 3D 界面。

对于经过墨卡托投影为平面的世界地图，在不同的地图分辨率 (整个世界地图的像素大小) 下，通过切割的方式将世界地图划分为像素为 $256\times256$ 的地图单元，划分成的每一块地图单元称为地图瓦片。
地图瓦片具有以下特点：

不知道 SAE 的价格是怎么算的，反正最近就是这么逗不够用。连续冲了 3 次钱了，上星期又被停了。

其中我的博客每月最少要花 50 元钱，它提示我的博客的访问量已经上了 50 万，我知道这事根本不可能的事情。

Google analysts 给我的数据也就 2000 左右。

总之，他又促使我有了转了博客的决心。

磕磕碰碰把软件开发好，固然是一个令人喜悦的事情。

一方面为软件可以上架而开心，另一方面软件的幼稚感令我十分的担忧。

从产品角度谈谈，自己觉得还有一下一些问题

1. logo 过于丑陋
2. 引导页过于简单，没有良好的引导功能
3. 现在主页的资讯过于简单（应当实现缓存，给予个人信息的智能推荐功能）
4. 主页的交互过于死板，还有提升空间
5. 登入页面好 low，我正在以一个 UX 的角度重构设计
6. 没有良好的交互模式

昨天调试完 Codeship 和 EC2 的连接后开始尝试，连接 Docker

Docker 之所以有用，是因为把代码从一个机器迁移到另一个机器经常是困难的。它尝试去使得软件迁移的过程变得更加可信和自动化。Docker 容器可以移植到所有支持运行 Docker 的操作系统上。

简答一点，我直接安装 Docker Toolbox.

我们使用 Terminal 进入 Docker

登入 codeship，trivisCI，CircleCI 任意一个，这三个都是可以持续集成的管理工具

本文暂时以 Codeship 为例子进行配置

1. 登入 codeship，绑定 github 或者 bitbucket，选择一个项目
2. 修改 README，加入 Codeship Status，如
3. 在 Project Configyration 中配置 test setting 和 deployment
4. 自行配置 测试代码
5. 配置 部署配置

1. Add new deployment pipeline
2. 选择需要部署的 分支，如 master
3. 选择部署 codedeploy
4. AWS Access Key ID， 在 IAM 上建立的用户
5. AWS Secret Access Key， 在 IAM 上建立的用户
6. Region，如 us-east-1
7. AWS 上 Codedeploy 的应用的名字
8. Codedeploy 上组的名字
9. S3 的名字

1. 提交代码，代码会进过如下步骤
2. 生成测试环境
3. 在测试环境中更新代码
4. 测试
5. 测试成功后安装 AWS CLI
6. 上传代码到 s3
7. 将 s3 上的文件部署到 codedeploy
8. ec2 中执行配置脚本
9. 等待部署成功

上篇我们配置了一大串的东西基本完成的 AWS 的配置，接下来我们可以试一下开始部署。

1. 进入服务器 ssh -i **.pem ec2-user@ip地址

在代码文件中创建 appspec/yml

今天基本理清了 CodeShip 和 CodeDeploy 的用法。

在 IAM 的用户中 (USER) 创建一个用户，暂时我就把它命名为 codeship 。该用户是给 Codeship 做部署用的。

在 IAM 中创建三个策略 (Proliies)

EC2

在公司继续打杂

公司准备弄一套自动部署系统，这两天看了一堆的资料

我计划的流程如下

• 开发者提交代码到版本仓库
• 自动触发持续集成，Jenkins 调用 Rundeck 获取部署文件并部署到测试环境
• 在测试环境进行单元测试
• 单元测试完成后，生成 Docker 并部署到开发环境
• 测试人员进行产品验证
• 测试人员在验证通过后，申请发布到生产环境，并手动触发 Jenkins
• 运维人员触发 Rundeck，将 Docker 更新到生产环境