分类: 互联网

关于互联网行业的唧唧歪歪。

  • 试用 PayPal

    试用 PayPal

    因缘际会,PayPal 里有一些美金,提现手续费很贵,所以尝试使用 PayPal 购物,看看效果。

    直接付款

    1. 【成功】付费 GitHub。我现在是 Evan You 的 sponsor,$5/m,付费顺畅,自动扣费,没问题。
    2. 【失败】充值 Vultr。我的 PayPal 绑了朋友的账号,那个账号用 Yandex 邮箱注册的,长时间不用被回收了,现在没法解绑……所以失败了,不知道该说是谁的问题。
    3. 【失败】YouTube 买碟。国内视频网站竟然没有《千与千寻》,刚好 YouTube 推送,我就想买一个好了。结果付费失败,错误信息告诉我购买区域与 PayPal 所在区域不符,不知道是什么原因。
    4. 【失败】支付给他人。两个中国账户之间不能互转。
    5. 【中止】steam。国区账号没有 PayPal 入口。美区可以买,但是好贵,而且跟国区优惠方式不同,所以没继续。
    6. 【成功】抖内,付费给非中国账户,很顺利。
    7. 【成功】Vultr 的服务器是 Ubuntu 16.04,我用 do-upgrade-release 升级了几次到 18.04,后来就没升过大版本,早就想升级。于是尝试换到 digital ocean。换的过程倒是挺顺利,但是 do 亚洲只有新加坡和班加罗尔,速度都不理想,最后选了美国 SFO,速度明显变差了。凑合一个月,不行下个月找 Vultr 客服解绑然后回归 Vultr。
    8. 【成功】域名续费。域名在 namecheap 上,续费很顺利。但是域名本身似乎没带来过任何收益,有点不想续了……
    9. 【失败】购买 zimaboard。付款的时候失败了,显示为:因为国际法规云云。

    土澳账号

    想办法搞了个土澳账号,尝试了以下方式:

    1. 中国转土澳,必须走商家收款,收手续费,大约 4%
    2. 钱要 21 天才到账,避免退款,艹
    3. 土澳转出,可以走“亲朋好友”,实时到账,无手续费
    4. 【成功】等了若干天,终于到账,尝试购买 zimaboard,成功。

    其它尝试进行中,随时补充。

  • Jetpack 的流量统计好像被墙了

    Jetpack 的流量统计好像被墙了

    从5月23日开始,从 WP 后台的 Jetpack 统计看起来,我的博客访问量大跌。

    一开始我以为是 CDN 的问题,拉着同事研究了半天,没有找到证据。然后检查了 DNS 解析统计,似乎也正常。最后想起来看 GA。从 GA 的数据来看,似乎访问量并没有什么变化。那么只好猜测是 Jetpack 的统计出问题,很多访问没有统计到。

    不过我觉得多半是误伤,毕竟 Jetpack 作为 WordPress 的产品,很容易被“误伤”,而且在国内也没多少人用,不必像 GA 这样还要留点余地。可惜以后我没法很容易的看到统计数据了。

  • 解决 load-scripts.php jQuery is not defined 的问题

    解决 load-scripts.php jQuery is not defined 的问题

    不知道从哪天起,我的博客后台就坏了。没错,就是这个后台。写文章变成非常困难的一件事。各种功能都不好使,页面布局也混乱不堪。于是我打开开发者工具,看到一大堆报错,基本上都是 load-scripts.php jQuery is not defined。看起来是某些 jQuery 插件启动的时候 jQuery 还没完成加载。

    这就有点蛋疼了。我应该没有手动调整过这些脚本的加载,但是也说不定,我好像有把本地的 jQuery 换成 CDN 上的版本,但也不是很确定。不过我有好几台电脑,有些电脑上保留着可用的 JS 的缓存,我就勉强用着,反正也不常写文章。我试着 Google 这个问题,但可能关键词组合没选好,没能找到答案。WordPress 历史太悠久,跟 jQuery 相关的问题不胜枚举,搜索结果里噪音太多。

    结果前两天终于所有缓存都失效了,然后我就没法写文章了,于是必须解决这个问题了。没想到这次我很快找到了解答:

    Try adding define('CONCATENATE_SCRIPTS', false); to your wp-config.php file just below the define('DB_HOST' line.

    https://wordpress.org/support/topic/failed-to-load-jquery-at-load-scripts-php/

    使用后台的时候,WordPress 会试图把所有 JS 合并到一起,以便节省 HTTP 请求。这个设计思路没问题,但看起来他们的实现比较简单粗暴,只是简单的合并,并没有很好的检查依赖顺序,以至于可能导致后台功能失败。

  • 哈哈哈,Strikingly 开始接入外包了

    哈哈哈,Strikingly 开始接入外包了

    上线了/Strikingly认证开发者资格申请表


    上线了/Strikingly 是一款简单易用的网站和小程序营销类SaaS工具。我们是第一支被硅谷最知名孵化器Y Combinator录取的中国团队,获得了来自顶级投资机构1750万美金投资。目前用户遍布全球200多个国家和地区。我们有百万级用户和各种定制开发的项目。成为我们认证的开发者,你可以接我们开拓出来的项目单子。我们看重的是长远的合作,一起赚钱并累积到各种门户行业的专业知识背景。我们的客户包括:Microsoft、阿里巴巴、Uber、招商银行、渣打银行和众多中小企业等等。

    http://apply.sxl.cn/

    随着 HTML5 一声炮响,网页进入“更富的体验”阶段,基于 HTML 的建站工具也涌现出来,比较知名的有 Strkingly、WIX 等。——早年更多,不过很长时间这条赛道一直比较冷清,所以慢慢都死了。

    我之前做过两个建站工具,这种东西和大部分 2B 产品一样,开始的时候很容易,20% 的时间可以完成 80% 的功能,然后就很开心,觉得胜利在望。然后就找用户来试用,结果用户就会提出一些 20% 的需求,然后你去实现,发现再用一倍的时间也做不出来……

    这里有一个悖论:绝大部分会使用这种工具的人,对网页开发一窍不通,于是任何堵点都会成为劝退点;而那些懂点网页开发的人,几乎遇不到需要用这种工具的情况,即使遇到了,也会觉得手写比较方便且好维护,于是也不太会用这种产品。

    与 2C 的产品不同的是,后者用户会觉得有 80% 的需求被满足,赚了,继续用这个产品(当然也是因为大部分 2C 产品是免费的);而 2B 的用户因为 20% 的工作无法开展,而必须放弃这个产品。

    所以解决方案就是雇人。有人在,什么需求都能做。但是结果就是公司一直扩张,原本几个人全远程,结果也不得不租办公室才能管理这么大的开发团队了。

    然后需求还是做不完,又不想丢失客户,干脆,接入外包商吧!于是就出现开头一幕。


    其实写这篇就是为了说:所有建站工具,在现有的技术基础和框架下,都无法满足普适的需求。当然,我们可以做一些辅助自己的工作,或者满足本厂的需求。

  • 开发 WordPress 的 nginx 配置

    开发 WordPress 的 nginx 配置

    以前比较习惯放在 /etc/nginx/ 里,用 service nginx start 启动(对应 MacOS + brew 就是 /usr/local/etc/nginx/brew services start nginx)。来到我厂后,开始频繁接触 Nginx 和 OpenResty,现在觉得单独放在目录下面比较方便管理,所以改了一个出来。

    配合 Makefile,方便日后使用:

    1. 启动服务 make run
    2. 关闭服务 make stop
    3. 重新加载 make reload
    4. 使用 php-fpm
    5. 代理上传资源(/wp-contents/uploads/)到真实服务器
    6. log 在本地
    nginx = nginx
    
    .PHONY: run
    run:
        mkdir -p logs
        $(nginx) -p $$PWD -c nginx.conf
    
    .PHONY: reload
    reload: logs/nginx.pid all
        $(nginx) -p $$PWD -c conf/nginx.conf -t
        kill -HUP `cat $<`
    
    .PHONY: reload
    stop: logs/nginx.pid
        $(nginx) -p $$PWD -c conf/nginx.conf -t
        kill -QUIT `cat $<`
    
    error_log logs/error.log error;
    pid logs/nginx.pid;
    
    events {
        accept_mutex off;
    }
    
    http {
    
        server {
            listen 9010;
            listen [::]:9010;
    
            include /usr/local/etc/nginx/mime.types;
    
            root /Users/meathill/Sites/wp-dev;
    
            index index.php index.html index.htm index.nginx-debian.html;
    
            server_name wp-dev.com;
    
            location / {
                try_files $uri $uri/ /index.php?$args;
            }
    
            location /wp-content/uploads/ {
                proxy_pass https://blog.meathill.com/wp-content/uploads/;
                proxy_set_header Host blog.meathill.com;
                proxy_ssl_name "blog.meathill.com";
                proxy_ssl_server_name on;
            }
    
            location ~ \.php$ {
                include /usr/local/etc/nginx/fastcgi.conf;
    
                fastcgi_pass 127.0.0.1:9999;
            }
        }
    }
    
    

    代码放在 Github wp-dev-env

  • WordPress + MySQL 8

    如果遇到验证数据库链接失败的问题,可以这样:

    ALTER USER 'username'@'localhost' identified with mysql_native_password by 'password';
    
  • WP Super Cache 的 max-age 有问题

    WP Super Cache 的 max-age 有问题

    我厂做的是高性能网关,CDN 也是其中一大功能,所以就要吃自己的狗粮。之前多次尝试在七牛上配置全站 CDN,均以失败告终,这次因为是自家的产品,可以找同事咨询,所以打算再试一次。

    配置过程暂且不提,基本上很顺利。结果在缓存上遇到一些麻烦,源站(也就是我的博客)控制为:max-age=3,所以基本上完全失效。

    由于这个东西很多地方都可以控制,所以只好逐一排查。首先打开 WP Super Cache 的配置——它负责缓存,所以从它找起——无果;然后 Google “wordpress cache-control”,无结果;然后 Google “max-age=3”,发现这个地址:Cache-Control max-age=3, must-revalidate,原来缓存 max-age=3 竟然是插件的问题,而且一直保留至今。

    按图索骥,打开 /wp-content/plugins/wp-super-cache/wp-cache-phase1.php,没有找到,原来这段已经被挪到 wp-cache-phase2.php,而且亦然没改……修改为 86400,缓存就可以 HIT 了。

    至于这个地方是不是 Bug?我觉得是。这么短的时间不科学,如果真的这样,不如放出来给用户选择。

  • 告别 Bluehost

    告别 Bluehost

    Long long ago,201 为了让大家吃自己的狗粮,要求在职员工每个月都要写博客回帖子发评论。对我这种爱现的人来说,写就写嘛,于是积累了不少文章。离职的时候,还想继续写,不过担心放 201 平台上不安全,于是决定自己搭服务器。

    那是2011年,当时我根本不懂服务器,市面上也没有云服务。我四处对比了一下,决定买 Bluehost 的域名+空间。Bluehost 跟联通是一路货色:“老用户与狗不得参加”。所以头一年各种优惠,吸引了我这种啥也不懂的小白,后面就再没优惠了。而我因为懒一直续到明年……

    不过 Bluehost 也有好的地方,他们家的服务器专为建站调教,装 WordPress 各种方便,自动化脚本分分钟建起一个实例。其它常见网站程序也是如此。而且不限空间和流量,可以各种尝试各种摸索。于是我一股脑搭了一堆东西,虽然最后都没派上什么用场……

    总之,从此,我开始接触学习使用服务器,以及服务器端软件。靠着无敌厚脸皮,我不断从身边各种运维那里一点一点的汲取服务器知识。如今,大体上一个服务器从空白系统到配置完成搭建网站我已经能轻松搞定了。

    于是 Bluehost 空间就越来越不够用了:

    1. 首先它是空间,权限很低,很多东西无法安装
    2. 其次速度越来越慢,平均一个页面将近10秒的打开时间,实在难以接受
    3. 其次国内外的云服务越来越好,价格越来越低,Bluehost 一个月将近 15 刀的租金性价比低得令人发指……

    所以我开始慢慢把服务迁出去,只是因为各种原因,比如这个空间2018年才到期,于是平日投入最大的博客一直没动,甚至宁愿写一个 Node.js 爬虫同步文章到 CDN,都不想迁……不过爬虫写的并不顺利,最后甚至可能就是它把博客搞挂了,如今桌面上非 Chrome 访问博客,都会无限卡在“维护”状态,无法恢复,甚至直接改代码注释掉状态判断都不行。

    哎,所以没办法,迁出来罢!

    回头把域名也转出来,明年空间到期后就彻底告别 Bluehost 了。

  • 迁移到 Vultr

    迁移到 Vultr

    前几年 DigitalOcean 刚出的时候,因为很便宜($5/月),还送 $10 启动资金,于是就入了一台,搭了个梯子,搭了个 Ghost 博客准备写长篇。然而时过境迁,长篇还是就那几篇……

    前几天看到 Vultr 推出了更便宜的套餐,$2.5/月,配置和 DO 一致。而且 DO 上梯子的速度越来越慢,几乎只够搜索,所以干脆换一下吧。便买了一台,将梯子和博客都迁了过来。新机器在东京机房,速度比美西的还是快多了。同样价格,配置也比 DO 高上一截,1G 内存安装 SQLite 终于不用搭虚拟内存了。

    有需要购买的同学不妨用我的链接:http://www.vultr.com/?ref=7124198