发表于 | 分类于

是不是时不时就会有这样的情况：一拍大腿，我竟然忘了这件事；要是当初做了某事就好了，现在弥补成本太高了；等等。

我并不是想说用待办事项软件记录下来，也不是想说注意重要而不紧急的事，而是想说，别让自己 100% 被具体的事务缠住了，至少要让 20% 的自己跳出来，站在更高的角度去审视自己、审视身边人、审视生活。可以是天马行空，可以是无厘头。即便从效用的角度，如果这时候在某个关键节点投入一点点精力，也好过将来用极大的成本来弥补或补齐。

给生活多一些照顾，生活少给你一些意外。

发表于 | 分类于

昨天折腾了下提交代码后的自动部署，将代码开源到 GitHub 上，也在 V2EX 等渠道介绍。在一些网友评论和我自己思考后，感觉这个事情不太妥：造轮子的味道太重。

决定产品核心竞争力和赢利能力的，在于对业务的把握和实现。除此之外，其他的都是末端。尤其，在时间精力有限的前提下，应尽可能把时间精力投入到核心业务上。任何其他的东西，应尽可能「外包」给成熟的第三方服务。如果投入太多精力去重复造轮子，这就是本末倒置。

PS：多暴露自己，多和别人交流，是件非常好的事。别人不经意间的一句话，可能就会为自己提供全新的视角，揭示被自己习惯或忽视的东西。

发表于 | 分类于

今天研究并实现一个响应 GitHub Webhooks 实现自动部署的 Web 服务。简单收拾了下代码和文档，开源至此

前提条件

这并不是一个 Hello Word 教学示例，而是我自己在用的实际项目。假设你已经知道下列技术或满足其条件：

  • 有一台自己的服务器
  • 会配置域名
  • 会配置 nginx 或者其他 Web 服务器，实现 Web 服务至 node 服务的转发
  • 了解 node、koa
  • 了解 Webhooks
  • 了解 SMTP
  • 会编辑 shell 脚本

主要功能

  • node lib/index.js 运行后，在 3030 端口提供可响应 GitHub Webhook 的服务
  • 内部通过 exec 来调用实际工作的 shell 脚本（需要自己编写）
  • 发邮件告知运行结果

主要配置

均位于 config 目录，参照 *_demo.json，添加没有 _demo 的版本

config.json

可为每个仓库、分支创建对应的配置：

1
2
3
4
5
6
7
8
9
10
{
  "webhook-test_master": { // RepositoryName_BranchName
    "secret": "GitHub_Webhook_secret",
    "cwd": "/home/jason/testapi/", // 脚本执行目录
    "command": "/bin/bash ./deploy.sh", // 真正工作的 shell 脚本
    "env": { // 一些环境变量
      "DEBUG": "s:*"
    }
  }
}

security.json

目前主要存储了 SMTP 配置信息，用于发告知邮件：

1
2
3
4
5
6
7
8
9
10
{
  "mailConfig": {
    "host": "email-smtp.us-west-2.amazonaws.com",
    "port": "465",
    "user": "user123",
    "password": "password123",
    "from": "[email protected]",
    "to": "[email protected]"
  }  
}

琐碎的

关于 GitHub Webhook，记得生成密码、选择 json 格式。

关于 shell 脚本，可以通过 2>&1 将其中不重要的 warn/error，从 stderr 转到 stdout 中。

关于邮件服务，我开始时用的是阿里云，但出现了提示发送成功、但实际不破功的情况，垃圾箱也没有。后来试了 Amazon SES，目前一切顺利；每天 200 封免费邮件额度。

使用 VSCode 编写调试，.vscode 配置本身也包含在项目中了。

如果你遇到了问题，多问问 Google 和自己；我这边是顺畅运行的。

发表于 | 分类于

本来要做微信登录，一直被微信审核给卡着，烦；就折腾了 Docker.

目前来看，我对 Docker 的使用还在 Container 级别。比如，需要使用 mongodb；本来是全局安装，测试和生产环境使用相同的 mongo、不同的 db. 有了 Docker 之后，可以运行不同的 mongodb Container，分隔的更彻底些，理论上扩展性也更好些。再加上结果 Docker Volume，可以更好地备份恢复数据。

顺带着还有个好处：临时学习某技术时，不用全局安装其运行环境，而是安装一个 Docker 镜像，在这个沙盒里随意折腾，而不用担心污染电脑主环境。试用后发现不需要，直接删除 images 即可；需要时，才考虑在电脑主环境安装。

进阶的，还没有用于 Images/Stack/Swarm 级别；不过还是跟着官方介绍跑了一遍，大致知道是怎么回事。等将来用的时候，再细细口味。

比如，明天准备搭个 webhook 的响应服务，就可以用上 Docker 来开发和部署。虽然我还是觉得有点不适应，平白多了一些步骤，不过还是硬着头皮上吧，逼自己适应 Docker 的套路。

发表于 | 分类于

一、野蛮学习阶段

学新东西时，先不要太过在意能否应用到生产中、怎么用。先把自己完全沉浸到新东西中，用新东西的视角和思维模式来理解一切。
打个比方，自己之前擅长用螺丝刀解决一切问题。现在开始学锤子，先不着急和螺丝刀比较，而是认真学习锤子的使用方式，把全世界看成钉子。

二、为我所用阶段

等到了一定程度，再跳出来，和已有的东西交融。

比如，和螺丝刀相比，锤子在哪些方面更好使；又有哪些局限，还是有螺丝刀更顺手；
比如，我目前正在使用的技术和方式，有哪些不足；和新东西相比，互相有哪些优缺点。

既不盲目崇拜新东西、把已有的拍死，也不要过早因为新东西的局限而下结论。

更关键的，是已经会的、和新学的东西之间，如何交融，如何发挥双方的特长，如何更新自己的技术树。该用锤子用锤子，该用螺丝刀则继续使用螺丝刀。

吸星大法，你怕不怕？