前言

之前官网的部署都是构建的时候，直接用 upload 和 shell 这两个指令去做部署，前者上传到服务器，后者执行执行shell指令，解压并覆盖。
但是这样其实并不灵活，一方面是这个项目是多人协作项目，如果每一个人，都要有部署的权限，那么就意味着运维要开多个权限。
所以后面决定将官网的构建和部署通过Jenkins来构建和自动化部署。(事实上，现在前后端三十几个项目，全部都用Jenkins来做到自动化构建和部署了)

写在前面的话

说在前头，现在是2018-09，下面的文章是我在2016-10月的时候，记录在Evernote的，那时候 phantomjs-node 这个issue，确实没有解决，后面我们团队有提交了一个pr上去，而且这个作者也成功修复了，并更新了新版本，从而修复了这个bug。
但是在那个时候，时间是比较赶的，你没办法去赌这个作者，马上去采取你的pr并更新版本，才有了下面的解决。
反正我觉得整个过程挺有意思的，有记录并分享的价值。<(￣︶￣)>

前言

前段时间，在用 gulp 打包的时候，出现了一个问题：
使用了gulp-zip组件将build目录打包成zip包，并且使用了 gulp-scp2 上传到服务器，最后用 ssh2shell 在服务器上执行zip包解压命令。但是出现了一个问题。就是在windows下，使用了gulp-zip 打的zip包，上传到服务器解压的时候，发现里面的目录会没有执行权限。

原因

用gulp打包之后，后面发现在ie8下会报错。原因是 framework.min.js 的一个错误。 后面发现是因为在进行 uglify 打包的时候，在ie8下会有问题。

解决

后面查了一下，在用 uglify 压缩js的时候，加上这个配置就可以了

1
2
3
4
5

{    
    compress: { screw_ie8: false },   
     mangle: { screw_ie8: false },   
      output: { screw_ie8: false }
}

前言

之前那么多篇幅，其实有很大一部分是要将官网的多语言的页面进行静态化预编译，以对SEO进行优化。 本篇主要是讲一讲官网的多语言的跳转规则。

现象

先说一下现象吧。
就是如果尝试请求一个没有该语言的页面。那么就会跳转到默认语言的对应页面。如果这个页面还不存在，最后才跳转到404页面

前言

通过 官网构建优化流程(2) - 旧版grunt打包构建流程 可以知道grunt打包构建的流程。
本篇主要是把之前官网的grunt构建换成扩展更好，可读性更强，速度更快的gulp构建。
目录结构如下：

前言

通过 官网构建优化流程(4) - gulp 静态页面预编译插件 gulp-staticfy 可以知道我们重新用gulp 做了一个静态页面预编译组件，并且效率提高了一大截。既然已经选择把官网的打包构建从 grunt 转为 gulp 了，那么还有一个组件还需要编写成gulp，那就是 grunt-jst-concat 组件：npm 组件传送门 grunt-jst-concat
这个组件也是我们项目的人自己写的，其目的就是项目中有用到 underscore 模板的js文件，将模板html文件编译成jst（或者js后缀）后缀的模板编译文件，然后插入到其调用js的文件内容前面。
这样子就可以在js调用underscore 模板的时候，直接执行该js，而不需要再去请求模板，而从节省了一次http请求。

前言

通过 官网构建优化流程(3) - grunt静态页面预编译插件 grunt-staticfy 可以看到通过这个 grunt-staticfy 组件可以实现 模板静态化预编译，但是会有几个问题。
后面决定采用gulp来重写这个组件：
github 传送门 gulp-staticfy
npm 组件传送门 gulp-staticfy
用gulp 的几个好处就是：

1. gulp 是基于流的方式，不需要像grunt那样进行那么多的io操作
2. npm 有一个 phantom 的插件： phantomjs-node，在安装这个npm 插件的时候，不用单独再去安装phantomjs 客户端。而是插件在安装的时候，就会去下载phantomJS。而且整个调用非常方便。可以用 promise， 也可以用 co同步（还有最新的async await语法), 而如果是之前grunt-staticfy 那种处理，就比较麻烦，还要用到 exec 去执行 phantom 的脚本， 非常不友好。

前言

通过 官网构建优化流程(2) - 旧版grunt打包构建流程 可以知道整个的grunt打包流程。其中最大的难点就是 静态页面预编译 这一块有用到了一个插件。
这个插件是我们团队那时候自己写的一个grunt插件，专门用来静态页面预编译。
github 传送门 grunt-staticfy
npm 组件传送门 grunt-staticfy
其原理就是先启用一个web server，然后将要静态化的页面，用phantomJS 跑起来，最后再把 phantomJS 跑完新的页面保存起来。

前言

这个主要是讲第一版的时候，用grunt来进行官网构建。

具体构建分析

具体的构建流程是：Gruntfile.js (我知道你们根本不会看，但是我还是要贴代码 ʅ（´◔౪◔）ʃ)

写在前面的话

说在前头，现在是2018-09， 但是接下来我写的这个一系列的文章，都是从我的Evernote 笔记里面抄过来的。我的Evernote里面，技术笔记不少，有几千篇，都是这几年的技术积累。但是真正能够直接放到网上跟大家共享的，其实也不多。
这个系列是其中之一，这个系列的笔记，就是我在做这个项目官网的一些技术思路，这个官网最早可以追溯到 2015-2016 年，也是我一手搭起来。所以接下来看的时候，不要说我很low，里面用的很多技术都是很旧的，甚至连三大框架都没有，还在用jquery库。其实在 2015-2016 的时候，我在做这个项目的时候，用的东西已经是那时候最新的，甚至有些东西网上根本找不到，只能自己造车轮(比如后续的 gulp-staticly插件)。

GoAccess

简单来说呢 GoAccess 是一个专门用来分析日志的工具，既可以在终端中展示结果，也可以生成 HTML 报表在浏览器中查看。GoAccess 最吸引人的一点就是它生成的 HTML very 炫酷。

安装

我的服务器是 CentOS7, 可以直接用yum安装： yum install goaccess

前言

项目中有个mongo要删一些过期数据，但是因为数据太多了，而且考虑到现在的mongo版本是2.6，版本太低了，删除的效率比较低，所以打算换成 mongo 3.4 版本。
刚开始升上去之后，情况挺好的，业务上也没有出现问题。 但是马上接下来的几天都会有出现如果是用户高峰期的情况，都会出现内存消耗非常大的情况，而且还会卡顿。

前言

之前项目有用到了一些第三方支付，包括 paypal, google iap, stripe, apple iap, 还有国内的 alipay。其中每个支付类型都有一些坑，本章讲的是google 内购支付，即 google iap 的一些需要注意的点，或者是一些踩过的坑， 将会持续更新。

创建商品的最低价钱

之前有一个需求，就是服务端要调用google的 iap API 来动态创建商品项， API INSERT DOC, 打算建一个 $0.5 的订单， 后面发现竟然报错了：

前言

之前在配置一个s3 bucket站点的时候，有报了一个 AccessDenied 错误：

前言

事情是这样的，我们有一个在线的站点，这个站点支持多语言。 但是后面发现当这个站点的主页也要放到手机端上显示的时候，这时候就会有一个问题：
因为这个站点的页面同时也是我们手机端APP的内嵌页，但是手机端的APP也有多语言，而且有三十几种多语言，所以就会出现手机端传过来的语言是网页端没有的，比如这时候手机端的语言是 ka， 这时候手机端显示首页的url就是： http://xx.xxx.com/ka/home.html，但是因为 xx.xxx.com 所在的s3上并没有这种语言的页面，所以就会变成 404 页面：

前言

最近打算想完善服务端的一些监控机制，并且将其图形化。也一直再找一个高性能，高可用的消息队列做内部服务之间的通讯。其实本身消息队列这种服务在我们的业务层上也用到了一些，比如很多任务队列处理，其实就是用的resque redis的队列的方式来做的： golang基于resque的作业队列 -- goworker， 然后我们的 webrtc 服务也用到了 VERNEMQ 这个服务来做 signal 服务通信： webrtc 的 signal 服务器 VerneMQ 的搭建, 当初之所以用这个服务也是因为他支持 mqtt 的协议，适合用在移动端设备上， 这次想找的消息队列服务主要是用来做我们内部服务直接的通信，所以可靠性和灵活性非常重要，考虑到我们的大部分服务都是Golang 写的，所以后面就选了 NSQ 来做服务内部之间的通信。

前因

之前在我们后台做发版操作的时候，要传升级包。这时候一个包大概要 20M，刚开始如果是传2M以下的，是没有问题，但是一旦超过了 2M，就会报这个错误：

前言

goworker是一个基于Go后台队列任务执行框架， 运行速度比基于Ruby的快10到100,000倍。 goworker 兼容 Resque，所以你可以用 Rails/PHP 和Resque推送你的作业，然后利用Go在后台执行。
我们的很多项目都是用 goworker 来进行队列任务处理，即一些基于PHP的业务处理，然后将一些分支任务，比如 发送push，发送邮件， 通用统计 等等的任务，放到worker中去处理，这样子可以让多个业务项目的一些通用任务处理全部放在一块。
goworker是基于resque的用golang语言封装的库，Resque 是使用Redis创建后台任务，存储进队列，并随后执行。它是rails下最常用的后台任务管理工具之一。
官方文档：传送门

前言

最近想用一下Superset，这个是一个开源项目，可以直接通过写sql来生成图表，有时候对一些图表需求比较多的时候，可以用的上。

Superset是由Airbnb（知名在线房屋短租公司）开源BI数据分析与可视化平台（曾用名Caravel、Panoramix），该工具主要特点是可自助分析、自定义仪表盘、分析结果可视化（导出）、用户/角色权限控制，还集成了一个SQL编辑器，可以进行SQL编辑查询等，原来是用于支持Druid的可视化分析，后面发展为支持很多种关系数据库及大数据计算框架，如：mysql, oracle, Postgres, Presto, sqlite, Redshift, Impala, SparkSQL, Greenplum, MSSQL.