https://ichou.cn/posts/ Recent content in Posts on yii.im Hugo -- gohugo.io zh-CN Sat, 08 Feb 2025 12:00:00 +0800 https://ichou.cn/posts/dsm-721-video-station-hardware-transcoding/ Sat, 08 Feb 2025 12:00:00 +0800 https://ichou.cn/posts/dsm-721-video-station-hardware-transcoding/ 本文记录在群晖 DSM 7.2.1 上，为 Video Station 启用硬件转码（硬件直通）的完整流程。我实际采用的步骤分为三步：先激活 Advanced Media Extensions，再修复 DTS/EAC3/TrueHD 支持，最后用 VA-API 开启硬解。 前置条件 系统：DSM 7.2.1，x86_64（ARM 不适用下文中的 AME 补丁）。 套件：在套件中心先安装 Video Station 和 Advanced Media Extensions（AME）。 SSH：能以管理员账号登录 DSM 并执行 sudo -i 取得 root。 硬件：CPU/核显支持 VA-API 硬件解码且已安装对应的驱动。 第一步：激活 Advanced Media Extensions AME 未自动授权时，需要运行社区补丁脚本激活后，才能正常使用 HEVC 等解码及后续的硬件转码。本步参考自 我不是矿神：黑群晖一键修复（root、AME、DTS、转码等）。 DSM 7.1 与 DSM 7.2 的 AME 版本不同，脚本不通用；7.2 对应 AME 3.1.0-3005，使用 7.2 专用脚本。 仅适用于 x86_64，不支持 ARM。 激活过程会下载官方解码包，耗时可能较长，需耐心等待。若一直无法激活，可先卸载 AME、重启系统后再重新安装并再次执行脚本。 操作步骤： https://ichou.cn/posts/some-tips-about-activerecord-enum-in-rails/ Thu, 14 Jun 2018 05:41:07 +0800 https://ichou.cn/posts/some-tips-about-activerecord-enum-in-rails/ 在 Rails 的 ActiveRecord 中，有一个 ActiveRecord::Enum 的 Module，即枚举对象。 官方说明： Declare an enum attribute where the values map to integers in the database, but can be queried by name. 给数据库中的整型字段声明一个一一对应的枚举属性值，这个值可以以字面量用于查询。 拿到具体的运用场景中去考虑，Enum 的主要用于数据库中类似于 状态(status) 的字段，这类字段用不同的 整数(Integer) 来表示不用的状态。如果不使用 Enum，那就意味着我们代码中会出现很多表示状态的数字，他们可能会出现在查询条件里，也可能会出现在判断条件里，除非你记得或者拿着数据字典去看，否则你很难理解这段代码的含义。 代码中，以数字方式去表示数据状态，导致代码可读性被破坏，这样的数字被称为『魔鬼数字』。 Enum 就是 Rails 用来消灭魔鬼数字的工具。 ActiveRecord::Enum 与 Mysql 的 Enum 有何不同 枚举的功能，是为了解决数据库相关的问题，那么当然的，数据库本身大多都含有枚举的功能。 以 Mysql 为例，mysql 的字段类型中有一个 ENUM 的类型： CREATE TABLE person( name VARCHAR(255), gender ENUM('Male', 'Female') ); 这样就设置了一个叫 gender 的 ENUM 字段，其值为： {NULL: NULL, 1: 'Male', 2: 'Female'}, 在使用 SQL 的时候，数字键值(index of the value)和定义的字面量（actual constant literal）是通用的。 https://ichou.cn/posts/a-way-to-achieve-chain-calls-in-ruby/ Sun, 07 May 2017 16:44:25 +0800 https://ichou.cn/posts/a-way-to-achieve-chain-calls-in-ruby/ 最近项目组有一个关于人脸识别相关的需求，需要用到 FacePP 的服务，而官方提供的 Ruby SDK 自 2013 年提交以来，从未更新过，Issue 和 PR 也无人处理。So, 我被安排去『重新』实现 FacePP 的 SDK。 官方 SDK 地址: https://github.com/FacePlusPlus/facepp-ruby-sdk 本以为这是个苦差事，难鹅，当我拉下官方的 SDK 源码时，却被华丽丽的惊艳到了 w(°ｏ°)w 通常来说我们写 SDK 的常规思路： 实现一个通用的请求处理，包括 url 拼装，参数处理，签名等 根据各个接口去实现一个方法（method） 而这个 SDK 的实现，直接使用了 Ruby 里的大杀器 —— 元编程， 进而毫不费力的实现了链式调用 链式调用 关于链式调用相信大家都不陌生，最常见的就是 ActiveRecord 的查询方法 Article.where('id > 10').limit(20).order('id desc').only(:order, :where) 个人认为，链式调用最大的优点就是优雅，相比起把所有参数放在一个 options(hash) 里喂给一个方法的调用方式，链式调用的可读性明显更好，参数组合也更自由。 FacePP 的 SDK 里面实现的链式调用 api = FacePP.new 'YOUR_API_KEY', 'YOUR_API_SECRET' puts api.detection.detect url: '/tmp/0.jpg' 实现原理 链式调用的实现原理其实很好理解，每当你调用一个链式对象的某个方法时，返回一个该对象所属类的新实例即可 https://ichou.cn/posts/the-security-about-wechat-web-oauth/ Mon, 28 Nov 2016 21:38:46 +0800 https://ichou.cn/posts/the-security-about-wechat-web-oauth/ 本文其实有一点标题党，因为微信网页授权本身并没有什么安全问题，有安全问题的是一些不恰当的打开姿势。主要围绕授权过程中 40029 报错和 state 参数的使用方式来展开讨论，如果你在开发中也遇到过这类似的问题，或许这篇文章可以帮到你。 认识微信网页授权 微信网页授权(官方文档)是公众号开发者在微信内嵌浏览器中获取用户基本信息的唯一方式，其最关键的就是取得用户的 openid，进而才能实现支付一类的功能，因此微信这个 OAuth 的意义已经不仅仅在于授权登录了。 一个简单的微信授权的流程大致如下： 当然，在实际使用中，我们不会让用户每次都去授权，授权之后我们会把信息写入 session/cookie 中，于是一个比较标准的流程应该是： state 该如何用 在微信授权的参数里面，有一个不太起眼的非必须字段 state ，官方的说明是『重定向后会带上state参数，开发者可以填写a-zA-Z0-9的参数值，最多128字节』，咋看一下，似乎只是一个标识字段，用来传递用户授权前的状态。 但实际上，我们可以在回调地址 redirect_uri 里传递任何参数，同样可以用来保持用户的状态，实现和 state 一样的效果，为什么还要单独设立一个 state 参数呢？ 在我刚接触微信授权的时候，应业务需求做了一个微信授权的中转服务，我将 state 用来标识用户在授权后应该去到哪一个应用，比如用户需要去我们的商城 mall，那么就传 state=mall。这个设计看似高效合理，但是不知不觉间就已经引入了一个潜在的安全问题了： 如果授权第二步中微信 301 重定向的 url 被其他人截取了，我没有办法验证这个 url 的请求者是不是我的真实用户，因为没有一个字段可以给我用来做验证。只要行动够快或够鸡贼，这个不怀好意的家伙拿着这个 url 便可以跳过微信的授权以用户的身份登录到我们的商城，而且由于 state 设计得过于简单，他甚至可以通过修改 state 去到任何一个接入过的系统。 如果你用过一些主流的微信支持组件，如 ruby 的 wechat gem 包、php 的 EasyWeChat，你会发现他们的授权方法里都不支持自定义 state，授权 callback 的时候会对 state 做比对检测。对此，ruby wechat 的维护者 Eric-Guo 给出的解释是： state的确可以这么用（自定义使用），但是设计目的实际上是为了安全性，也就是说这个state设计的目的是防止有人冒名顶替的登录。。 这也是wechat gem内置帮你填写的原因，而不是放出来让你自定义的原因。 综上，state 一种比较有效的用法是： 在授权开始前生成并写入用户的 cookie（还需要加密），授权完成时，比对 url 与 cookie 中的 state，如果不一致便可判定为非法请求。 https://ichou.cn/posts/the-right-way-to-set-nginx-for-laravel/ Mon, 07 Nov 2016 02:22:25 +0800 https://ichou.cn/posts/the-right-way-to-set-nginx-for-laravel/ Laravel 是当今最流行的 PHP 框架之一，如所有 PHP 项目一样，通常情况下它都需要运行在 LAMP 或 LNMP 环境之下。如何配置 LNMP 使之为 Laravel 工作可以说是每一个 Laravist 的必修技能。 本文将就 LNMP 环境下如何为 Laravel 的配置 Nginx 进行一次比较详细的探究，通过本文你可以更清晰的认识这份你每天都在使用的配置，理解其中的原理，知晓某些配置的好与不好。在文章的后半段，还会为你推荐一种更为安全，更加适合 Laravel 的配置方案。 广为流传的配置 root /path/to/your/laravel/public; index index.php index.html index.htm; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { try_files $uri /index.php =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php7.0-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } 这段代码引用自：How to Install Laravel with an Nginx Web Server on Ubuntu 14. https://ichou.cn/posts/wordpress-wp_default_styles-warning-under-php7.1/ Fri, 07 Oct 2016 17:10:56 +0800 https://ichou.cn/posts/wordpress-wp_default_styles-warning-under-php7.1/ 遇到问题 如果你使用最新的发布的 PHP7.1 来跑 WordPress，会惊讶的发现页面上会报出几个 Warning 的错误 Warning: Parameter 1 to wp_default_styles() expected to be a reference, value given in /Users/Home/Sites/WordPress-4.6/wp-includes/plugin.php on line 600 Warning: Parameter 1 to wp_default_scripts() expected to be a reference, value given in /Users/Home/Sites/WordPress-4.6/wp-includes/plugin.php on line 600 也许你会觉得这可能是某个主题或者插件导致，或者是某个版本的 WordPress 有问题，然而不幸的是，这是一个 WordPress 与 PHP7.1 间的兼容问题，几乎所有版本的 WordPress 都会中招。 探查原因 在 WordPress 的官网 support 里面有人提过这个 BUG，但是并没有获得有效的回应，只是提醒大家 PHP7.1 目前还不是稳定版本 😂😂 最后，我倒是在 php 的官方邮件组中找到了相关信息： 邮件地址：http://php-news.ctrl-f5.net/message/php.internals/94856 主要解答： Thanks for pointing this out. https://ichou.cn/posts/hugo-theme-vec/ Fri, 09 Sep 2016 16:52:42 +0800 https://ichou.cn/posts/hugo-theme-vec/ Vec Vec is a minimal, clean and beautiful theme for Hugo. Demo. Repo. Installation mkdir themes cd themes git clone https://github.com/yiichou/hugo-theme-vec vec See the official docs for more information. Configuration You could add params into your site’s config.toml file: [params] Keywords = "key, 关键字, キーワード" Description = "There are some words to describe your site" Avater = "//chou.oss-cn-hangzhou.aliyuncs.com/yii.im/avatar.jpg" SelfIntro = "Just a worm, seek for true, live in shadow, no more. https://ichou.cn/posts/trace-alfredworkflow/ Sat, 30 Jul 2016 19:33:03 +0800 https://ichou.cn/posts/trace-alfredworkflow/ 在 Mac 上切换代理是一件挺麻烦的事情，然而不幸的是一旦你有了这个需求往往也意味着你需要频繁进行这个操作 比如我， 公司公用的扶墙是 Shadowsocks + PAC 离开公司，就要自己开个 SS 了 公司用的是香港 CN2 线路的服务器，自己的是个 Do 的小水管，所以虽然麻烦还是要来回切换 另外，抓包用的 Cellist 设置代理的时候也有点问题，基本都需要手动去设置 在网上找了一下 Alfred 的插件，发现一个 Pac-helper。用倒是可以用，不过略微有点简陋，于是就自己抽时间造了一个，效率提升杠杠的 项目地址： https://github.com/yiichou/Trace.alfredworkflow Quickly start Download https://github.com/yiichou/Trace.alfredworkflow/raw/master/Trace%20(Proxy-helper).alfredworkflow Setting Doubule click trace in Alfred Workflows Preferences Click Open workflow folder to open Finder Open proxy.conf and modify it like sample Use Call out your alfred, and type trace Enjoy it! More feature When you change your proxy setting via Trace, OSX may ask your password to allow this operation everytime. https://ichou.cn/posts/pretty-self-hosted-ngrokd/ Sun, 10 Jul 2016 11:13:12 +0800 https://ichou.cn/posts/pretty-self-hosted-ngrokd/ 问题 随着互联网生态圈的发展，现今的 Web 项目中开始越来越多的使用第三方服务，通常这些第三方服务都是由 Client 通过 Server 的 API 主动发起请求，但是 Server 回调 Client 这种方式也是很多服务中不可避免的一种方式。这样的场景下，对于开发者就有个比较麻烦的问题： 如何在开发的过程中让处于内网的开发机收到回调？ 古老的解决方案 方案一 传统解决方案中，如果没有固定 ip 首先需要动态域名，然后需要维护一份外网到内网的端口映射表，最后如果 Client 中有取 Host 信息的操作还需要响应的 Hack（这点后面会提到）。当然，如果你连公网 ip 都没有，那么就可以直接放弃这个方案了。 方案二 一种更为有效的解决方案是：使用一台拥有公网 IP 的主机，通过隧道来实现转发。其实在很早之前，为了让处于校园网内网的服务器在外网可以访问，我经常通过 SSH Tunnel 来解决这个问题。 # 将远程主机的 10086 转发到本地的 3000 ssh -C -f -N -g -R 10086:127.0.0.1:3000 user@Tunnel_Server 这种方式虽然使用简单，但是稳定性并不理想，一段时间内没有请求 Tunnel 就会自动断开。而且使用者必须有 Tunnel_Server 的 ssh 登录权限，每开一个服务就需要占用 Tunnel_Server 一个端口。 Ngrok 正当我苦于写 SSH Tunnel 的各种连接脚本和守护脚本的时候，第一次接触到了 Ngrok。（2013年）那个时候 ngrok 还是一个很冷门的小工具，它所依赖的 Go 也一样，加上文档有限，各种尝试之后并没有把这套服务搭起来。 再后来，国内出现了金数据团队维护的 tunnel.mobi，默默的为国内的开发者提供了很长一段时间的便利。国内 ngrok 的快速普及，个人觉得很大程度上都得益与 tunnel. https://ichou.cn/posts/some-reflections-on-the-twice-changes-of-sudiyi-wechat-team/ Wed, 22 Jun 2016 00:27:27 +0800 https://ichou.cn/posts/some-reflections-on-the-twice-changes-of-sudiyi-wechat-team/ 在撰写这篇文章之前，我有点犹豫是否应当隐去公司的名字，一番思量之后还是决定不去在意这些细节。如果通篇都用某某公司来代替，难免写起来枯燥无味，况且，我要写的又不是什么坏事。 那么正文，就先从讲故事开始吧。标题中提到速递易的三代微信运营团队，其实这仅是我自己提出的说法，姑且可以认为是为了讲故事所做的必要加工。 第一代运营团队：自娱自乐 这个故事是从 15 年的 8 月份开始，某一天，我收到了 速递易社区助手 微信公众号给我发来的第一条推送。 单看标题，一股强烈的网络段子既视感已扑面而来，根本无法激起我想要点开的兴致。但这毕竟是以后要参与开发的项目，因此还是『满怀期待』的点进去了。看完之后果然有惊无喜，有惊的是因为通篇跟速递易没有半毛钱关系，但是不管三七二十几也要在文末都强行插入广告；无喜是因为文章内容本身于我这样的客户毫无共鸣，属于典型的打开不超过三秒。 第一印象总是很容易导致偏见，我们不能排出这是一次意外的可能。之后我开始有意识的关注他们推送的文章，我需要更全面的了解我参与的产品，了解我的队友，也因此有了现在这篇文章。 然而，墨菲定律再一次展现了它的魔力，你越是担心什么会发生，那它就真的会发生： 这几个月的时间里，推送文章的风格可以简单的概括为：有热点炒热点，没热点就随便发点什么，跟速递易业务基本没关联，但文章末尾一定有强行插入的广告。曾经有段时间，我干了一些挺无趣的事，每次他们发布推送之后，我就去日志里统计一下有多少人取消关注，这个值通常都在 2000 以上。 当然，他们偶尔也会发跟速递易新业务强关联的文章，比如在卖大闸蟹的期间： 除了业务推广的『政治需求』之外，这篇『1945年，上海穷人吃大闸蟹度日』，私以为是这段时期里公众号推送中最好的一篇。只有这篇文章，让我感觉到他们是用心在做，既切准了客户群体的兴趣，又关联了自身业务，还避免了营销手段过于直白（或称逼格够高）。 为什么是这样？ 这一代运营团队最大的问题在于他们和速递易线上业务的研发部门隔得太远，并且沟通几乎为零，以至于在同一家公司的同一条产品线上，他们姓名身份对我而言却是一个迷。 从他们的角度看，其实也并没有什么值得诟病的地方。大概他们接到的工作内容就是定期在公众号里推送文章，以唤起 速递易社区助手 在客户微信中的存在感。从运营方式的角度来看，这是一种更接近于个人自媒体的运营方式，在一个大主题的范畴之下，我愿意发什么就发什么，只要有人看就行。但是作为一个拥有自身产品线的官方公众号来说，这样的运营方式本来就是不合适的，更何况即便是按自媒体的标准来看他们也算做得很差了。 就其成果而言，评价为毫无建树的自娱自乐应该不为过。 第二代运营团队：与研发为伍 大概是在 12 月底的时候，我得知了微信运营将完全交给南区研发中心的消息（研发中心并不只有研发），并且不只是单纯的运营，还会根据需求逐步在微信公众号中添加新功能，把微信公众号真正的用起来。 接下来的时期，整个公众号的更新开始变得活跃，即使作为用户也能明显的感受到近期 速递易社区助手 的态度变得积极了。除却新功能的开发让人精神振奋之外，研发与运营在一起了这一变化也在团队中产生了奇妙的化学反应，仿佛之前的枷锁一下子被解开了。 在整个微信团队情绪高涨的时期里，这一代运营团队推送的文章也经历了一番『脱胎换骨』，大概变成了这个样子： 这一次，文章的内容终于和速递易的产品紧密的关联了起来。广告图不再是网上搜的，而是精心设计的；内容不再是东拼西凑的，而是业务相关的原创；排版不再是文字图片堆一起，而是有设计过的图文混排。 总体来说，文章的可读性增加了，内容的中所包含的信息质量更是有了质的飞跃。但是短板也非常明显： 过份侧重信息的有效传达，忽视了文章需要的娱乐性。文章十分有料，编排也够趣味，相信看过的人都能清晰的理解我们想要传达的信息，然而，用户每次进来都只看速递易小科普，这就够了么？ 文章偏短，大概是因为原创确实很难，排版组织恰又比较有效，看完一篇文章再也不能超过30秒 整体风格呈现出浓浓的理科生气质，这一点，就算你撒娇卖萌也还是掩盖不住内容里面清晰的条理性 第二代团队的优势与不足 第二代微信运营团队的优势在于它本身就属于研发中心的一部分，这个时期里，微信公众号的研发与运营可以紧密的结合起来开展，加之其对速递易整个产品线都十分熟悉，所以写出的文章比较有货。 然而在这段期间，公众号陆续上线了查件消息窗模式，模板消息通知，关注推送，商城接入等一系列新功能。于是这段时期推送的文章基本上就变成了为这些新功能背书或充当说明书的作用，从某种程度上来说，文章是被速递易产品关联了起来。所以这一系列的优势，也是导致上面三点不足的原因，有种聪明反被聪明累的感觉。 就其成果而言，这一代团队诠释了运营一个微信公众号的正确方式，他们实现了业务对运营的所有期待，但是在如何抓住用户兴趣点这方面略显不足。 第三代运营团队：专业与非专业的差距 前面提到第二代运营团队一直被业务的更新推着走，完全还没有机会展示出自己个性化的一面。然而随着组织体系的变动，他们似乎再也没机会了。一波新鲜血液的注入，微信的运营移交给了位于北京的新市场部，这是一个以某知名电商网站的前市场团队为班底成立的新团队。 她们一上来，就感觉画风不一样了： 初来咋到的她们，面临着和第二代团队一样问题 —— 速递易处在一个新产品密集发布的时期。但是在她们的文案里，你看不到那种局限于功能介绍的文字，而是经过消化，将需求恰当好处的揉碎在有趣或有料的文章之中。 特别是 『你不够火？那是因为你不够污』一文，其实这是一片推广我厂洗衣产品的软文，虽然尺度略大，但看过之后我都不知道为什么就举起了我的膝盖献了出来。这种驾驭软文的功力，归之于专业级无可厚非，至于到不到专家级，实不敢妄自断言，毕竟隔行如隔山。 北京团队优秀在哪里？ 在与 第二代、第三代团队的接触中，我毫不怀疑大家都是在个人能力上非常优秀的人，你没有办法排出一个谁比谁更厉害的顺序（也许是因为他们都比我厉害所以看不出来，哈哈~）。类推一下，我觉得就算是第一代团队的人，也不见得会比他们差。 这样的比对，是基于对他们智商、情商的主观认知，但就微信运营这一项来说，他们之间还是可以高下立判的。造成这种差距的缘由是经验么？看上去说得通，细思实则不然，如果让第一代的团队继续运营下去，两年三年，也会经历很多，积累很多经验，但是实在无法想象他们如何能望及现今北京团队的项背。 So，这不仅仅是一个简单的经验积累的过程，久了不一定就会懂，可能你收获的只是套路。抛开这一弱相关因素，再来剖析三者之间最大的不同，我想应该就是各自所处的环境。一个是在远离核心业务的总部，一个是在与研发混迹一室的南区，另一个是在运营资源富集竞争激烈的帝都，再结合三者文章的特点，导致其间差距的缘由已可见一斑。 结语 眼界，我认为决定着这些不同的，是运营者本身的眼界。所以我甚至愿意去推断：这种运营能力上的差异，可能并不是依靠模仿学习就可以赶上的，除非这种学习能提高学习者的专业素养和眼界。 眼界依赖于观测者自身所处的环境，以哲学上 认知 和 知识 的方式来描述，大概可以描述为：眼界是基于个人的感知数据的，取决于你对你所接触到的物理实体的 认知。通过学习获得的是 知识，只有服从于你的 认知 的那部分才会被接受，有悖于 认知 的部分对你而言是不存在的部分。 https://ichou.cn/posts/tinker-with-the-data-in-your-laravel-apps-with-php-artisan-tinker/ Sat, 18 Jun 2016 10:39:15 +0800 https://ichou.cn/posts/tinker-with-the-data-in-your-laravel-apps-with-php-artisan-tinker/ 本文翻译自：Tinker with the Data in Your Laravel Apps with Php Artisan Tinker 使用 Php Artisan Tinker 来调试你的 Laravel 今天，我们将通过介绍 Laravel 中一个不太为人所知的功能，来展示如何快捷的调试数据库中的数据。通过使用 Laravel artisan 内建的 php artisan tinker, 我们可以很方便的看到数据库中的数据并且执行各种想要的操作。 Laravel artisan 的 tinker 是一个 REPL (read-eval-print-loop). REPL 是指 交互式命令行界面，它可以让你输入一段代码去执行，并把执行结果直接打印到命令行界面里。 如何简便快捷的查阅数据库数据？ 我想最好的方式应该是输入下面这些熟悉的命令，然后立马能看到结果： // see the count of all users App\User::count(); // find a specific user and see their attributes App\User::where('username', 'samuel')->first(); // find the relationships of a user $user = App\User::with('posts')->first(); $user->posts; 使用 php artisan tinker, 其实我们可以轻易的做到这点。 Tinker 是 Laravel 自带的 REPL，基于 PsySH 构建而来。它帮助我们更轻松的和我们的应用交流，而无需再不停地使用 dd() 和 die() 。那种为了调试一段代码，通篇都是 print_r() 和 dd() 的痛苦，我想我们大部分人都能感同身受。 https://ichou.cn/posts/the-min-and-max-of-input-date-didnt-work-in-iso-safari/ Tue, 13 Oct 2015 23:49:09 +0800 https://ichou.cn/posts/the-min-and-max-of-input-date-didnt-work-in-iso-safari/ 今天接到一个需求，要在商品下单页面加上一个日期选择控件让客户可以选择发货的时间，而且可选日期需要从下单日的两天后开始。 因为是 App 内嵌的 webview，而且之前前端大姐在写页面是并没有引用任何样式库，所以直接考虑用 Html5 原生的 Input[date] 控件来完成。 // in angular $scope.minDate = new Date(Date.now() + 3600 * 48 * 1000); // with angular <input type="date" ng-model="date" min="{{minDate | date:'yyyy-MM-dd'}}" /> // A simple example <input type="date" min="2015-10-15" /> 这段代码在 Android 上用起来十分酸爽，简单干净又达到了效果 然而，事情总不能是一帆风顺的， F’u’c’k The ios! 在 IOS 上，min 属性没有生效，可以选择任意的一个日期。网上查了下资料，偶有看到之前是支持的，而且有作者甚至专门在文章中强调这一点。 http://tiffanybbrown.com/2013/10/24/date-input-in-html5-restricting-dates-and-thought-for-working-around-limitations/ 出于慎重，担心是由于项目中引用的各种 js 导致 min 失效，我又单独写了一个简单的、没有任何依赖的 html 页面来测试，最终还是证明 IOS 的 Safari 并不支持对 input[date] 的范围限定！！ 遇到这样的情况，只能用 js 来做 hack，于是我做了这样的改进（涉及 angular，可略过） https://ichou.cn/posts/rubymine-has-blink-bug-when-change-tab-under-full-screen/ Sun, 11 Oct 2015 23:47:39 +0800 https://ichou.cn/posts/rubymine-has-blink-bug-when-change-tab-under-full-screen/ Rubymine 8 已经解决这个问题 系统环境 Mac: MacBook Air & MacBook Pro Mac OS X: EI Capitan App: Rubymine 7.1.4 & PhpStorm Java: Java6 for OS X 2015-001 via Apple 问题描述： 在全屏模式下，切换 Tab 会出现竖条状闪烁，目前发现都是在界面的中部，闪烁很快，影响不大；切换窗口时，会出现全屏闪烁，界面反白，闪烁明显，偶尔甚至卡顿 其实这个问题并不只有 Rubymine 有，也并非 EI Capitan 才开始出现。根据社区的反应，Jetbrains 家的所有 IDE：Intellij, Rubymine, Pycharm, PhpStorm, WebStorm 几乎全部都已经出现过类似问题，而且最迟从 Yosemite 10.10 起，切换 Tab 的闪烁就已经存在了。 解决方案 各种查询，能找出的解决方案仅有一枚： 使用 Java7 以上的版本 安装 Oracle 的 JDK 下载地址 -> http://www.oracle.com/technetwork/java/javase/downloads/index-jsp-138363.html#javasejdk 安装好 JDK 后，可以在终端中查看目前默认的 java 版本是否是刚刚安装的版本 https://ichou.cn/posts/if-did-wechat-api-refuse-transfer-encoding-chunked-respond/ Wed, 12 Aug 2015 23:41:56 +0800 https://ichou.cn/posts/if-did-wechat-api-refuse-transfer-encoding-chunked-respond/ 入职速递易的第一个任务就是微信公众平台的重构，由于数据量巨大，现今的版本采用的又是灰常冷门 goliath 框架，导致整个系统很难维护了，自然也不敢再在此基础上做更多的功能开发，于是决定重构。 虽然之前有接触过，但是用 rails 接入 微信公众平台，我也是第一做。即使是得到了朋友、同事的很多帮助，但是有些细节依旧要自己摸索。期间也遇到一些诡异的问题。 做微信接入第一步，就是提交 url 和 token，这里本来只是用来做服务器验证的，甚至绝大部分相关的三方插件文档都直接跳过了这一步。但是 遇到的第一个问题就在这里 我搭起来的环境通不过！ 检查页面及 http header 输出，没有问题 用 php 的代码跑一下，配置成功 对比两者 http header ，找不同，可疑项比较多，无法确认 检查引用的 gem 包，然后发现在不使用 puma 的情况下，配置成功 对比有无 puma 时的 http header, 发现有 puma 时 Transfer-encoding=chunked 查阅 Transfer-encoding=chunked 相关资料，妈蛋我没开过这个啊。。。。 puma 自己开的？ 停用一部分插件后发现，开启 puma 也不再有 Transfer-encoding=chunked ，配置成功 问题分析： 微信公众服务的接口可能不接受 Transfer-encoding=chunked 的返回数据 puma 支持 chunked (分段传输），但没有默认开启，之前处于启用状态应该是由于开发环境下某个用于 Debug 的 Gem（我使用了一个在报错网页上提供一个控制台的 gem，应该就是它） https://ichou.cn/posts/some-suggestion-when-using-rails-ar-association/ Sat, 04 Apr 2015 23:31:01 +0800 https://ichou.cn/posts/some-suggestion-when-using-rails-ar-association/ 从遇到上一篇文章所描述的问题开始，在使用 Rails 的数据关联时，总会有一种弱弱的错觉：前面有坑。 没留意的时候，用起来也没感觉到什么问题，遇到问题后，变得小心翼翼了，反而是各种不明状况都遇到了。由于问题描述起来也比较繁琐，在群里面向大家咨询，并没有得到有人遇到过类似问题的响应，也没有实质的解答建议。 在 星哥 的建议下，又重新去查阅了 rails guide 里面的相关内容，才发现原来我是自己坑了自己一把： 当我仔细去看 rails guide 的时候才发现，之前我根本没有仔细去看这个部分的内容，基本就属于需要使用什么就去查阅什么的状态，对于 关联 稍微具体一点地知识点都没有掌握，也就更别说一个全面的认知了。 之所以最近会觉得遇到坑，起源一次把 migration 写错了，将外键与 modle 中声明的从属关系写反了。虽然很快发现了问题，但是由此也揭开了自己知识储备不足导致的恐慌，毕竟不了解就不能最有效的去运用。 上一篇文章中遇到的问题，呃，到现在依旧是个问题。它的存在使自己对 Association 的不信任感进一步加剧。 下午抽了些时间，（较为）完整的去看了 guide 的讲解，才发现 Rails 的 Association 其实是一个很了不起的功能。也根据自己的经历，总结出一些些以后在使用中需要注意的点： 尽量从环境语义上去考虑如何设置关联 最大限度的在关联的两端都声明关联 遵寻 Rails 的约定去创建关联，比如：has_and_belongs_many 的链表命名方式，外键的创建等等 在保证快速开发的基础上，去摸清并尝试 关联 一些更高级的运用，比如：条件 和 依赖，以简化业务逻辑 有效创建 migration 的关键字： references 以上，留查备用，以之自省 https://ichou.cn/posts/a-confused-about-inverse-of-in-rails/ Sat, 04 Apr 2015 23:25:23 +0800 https://ichou.cn/posts/a-confused-about-inverse-of-in-rails/ 接上一篇博文，最近花了比较多的时间来折腾 rails 的 Active Record Associations, 一些以前没注意过的问题这次纠集成一大波僵尸直奔我可怜的脑子来了喂。 进入正题，昨天基本明确了 关联 的是使用规则，今天开始在项目里尝试用一些附属功能去提升效率（其实就是瞎折腾），以求写出更简洁漂亮的业务逻辑。果不其然，刚想用 inverse_of 就被难住了。 问题缘由 我对 inverse_of 的困惑并不是在实际使用中产生的，即使不了解它也能在项目中愉快的玩耍，这似乎又旁证了 Rails 是一个很智能的框架。 不过它的 Guide 文档里这一部分就有些描述不清了（或说自相矛盾？）。关于 inverse_of 的功用倒是没有什么疑惑，只是被这混乱的文档弄得不知道哪些情况下需要去显示的声明 inverse_of , 哪些情况下 inverse_of 又是无效果的。 问题描述 Guide 中关于 inverse_of 的解释：http://guides.rubyonrails.org/association_basics.html#bi-directional-associations 其中有两处说明让我很费解： 其一： There are a few limitations to inverse_of support: 1. They do not work with :through associations. 2. They do not work with :polymorphic associations. 3. They do not work with :as associations. 4. For belongs_to associations, has_many inverse associations are ignored. https://ichou.cn/posts/a-problem-when-using-has-and-belongs-to-many-to-tags-in-my-blog/ Fri, 30 Jan 2015 23:22:07 +0800 https://ichou.cn/posts/a-problem-when-using-has-and-belongs-to-many-to-tags-in-my-blog/ 这个 blog 本是基于 vec.io 改写的，偷了很多懒，导致写成后博客一直存在一丢丢 BUG. Tag 关联丢失这个问题其实很久以前就发现了，也尝试解决过一次，但是检查了代码没有发现问题，然后又试了一下好像又没什么问题，就当成偶发故障忽略了。然而不久前又遇到了，还表现出时好时坏的「特性」，让人颇为烦躁啊~ Blog 数据库使用的是 MongoDB，rails 用 mongoid 来驱动。在处理 Tag 时没有使用多态，而是简单的用了 has_and_belongs_to_many 来处理，按理说是应该没有任何问题的。关键的声明代码如下： class Post include Mongoid::Document has_and_belongs_to_many :tags, autosave: true ... end class Tag include Mongoid::Document has_and_belongs_to_many :posts end 问题描述 bug 表现出来的症状时，第一次添加一个 Tag 时，没有任何问题，双向索引都正常；当我更新这篇文章时，由于这个已经添加的 Tag 没有变动，本应是没有操作的，但是实际情况是 post 索引 tags 是正确的，但是从 tag 的索引中却找不到这篇 post 了；如果再一次更新文章，这个 tag 又正常了，如此往复循环。 经过调试，从控制台对比两次的 query 发现，每次更新的时候都会先清除双方的所有关联信息，然后再根据『新』的 tags，重新构建关联。而问题就出现在这里，若是某个 tag 之前就与此 post 是关联的，虽然在上一步中已经清楚了关联，但是 AR 似乎还是会判断它是没有变更的项，于是不会在此 tag 下重新添加此 post 的外键，于是前面描述的 Bug 就产生了。 https://ichou.cn/posts/aliyun-oss-php-sdk-has-some-bugs-when-dealing-with-chinese/ Wed, 28 Jan 2015 23:20:17 +0800 https://ichou.cn/posts/aliyun-oss-php-sdk-has-some-bugs-when-dealing-with-chinese/ 关键字: upload_file_by_file, utf-8, object_name 我用这个 SDK 写了个 WordPress 的插件，由于自己用的 ACE，不需要这个 SDK，所以一直没发现这个问题 直到最近有两个人给我反馈无法上传中文名的文件，我想可能是编码问题，仔细的测试个自己的代码，没发现问题 然后我跟踪一下 SDK 里的代码，瞬间凌乱了。。。。。 见 sdk.class.php line 1290 /** * 上传文件，适合比较大的文件 */ public function upload_file_by_file($bucket, $object, $file, $options = NULL){ // ..... 省略 ...... if($this->chk_chinese($file)){ $file = iconv('utf-8','gbk',$file); } // ..... 省略 ..... } 只要判断包含中文就转 GBK，并没有检测输入字串是不是 utf8。这个倒是可以理解，因为或许在某个地方已经判断过了（我没通看源码，所以自我安慰一下），不过为什么要转成 GBK 呢？ 在另一个地方有如下代码 line 2575 /** * 检验object名称是否合法 * object命名规范: * 1\. 规则长度必须在1-1023字节之间 * 2\. 使用UTF-8编码 */ private function validate_object($object){ $pattern = '/^. https://ichou.cn/posts/how-to-use-cache-to-speed-up-your-wordpress-on-aliyun-ace/ Tue, 06 Jan 2015 23:17:41 +0800 https://ichou.cn/posts/how-to-use-cache-to-speed-up-your-wordpress-on-aliyun-ace/ 圣诞前夕，@Cnsjw 反馈了 Aliyun OSS support for wordpress v2 的两个漏洞，因为手头有些事情，拖拖拉拉终于赶在元旦前完成了修补工作 https://ichou.cn/posts/sublime-text-on-ubuntu-keeps-attempting-to-remove-it/ Sun, 09 Nov 2014 23:09:58 +0800 https://ichou.cn/posts/sublime-text-on-ubuntu-keeps-attempting-to-remove-it/ Few days ago, I reinstalled my notebook with Ubuntu 14.04 desktop version. On Mac OS X， I used TextMate2 as my editor. but it wasn’t supported by Ubuntu, Sublime Text 2 had became the substitute. However, when I opened the Sublime via terminal, keep getting this message: (sublime: 6476): GLib-CRITICAL **; Source ID 1982 was not found when attempting to remove it. I tried to find the reason， there was nothing useful information in Chinese. https://ichou.cn/posts/jian-xin-zhi-neng-you-jian-tou-di-ce-shi-ban-kai-yuan/ Fri, 07 Nov 2014 23:07:46 +0800 https://ichou.cn/posts/jian-xin-zhi-neng-you-jian-tou-di-ce-shi-ban-kai-yuan/ 『简信』是基友 Vincenting 花了四个月时间开发的一套邮件系统，做这个项目的初衷很简单，很多人吐槽mailgun、sendcloud的独立IP价格略贵，同时mailgun不能有效的去兼容特别是QQ的发送规则。 除了他，我应该是这个项目的第一个试用者，并且承担了其中 PHP 部分的支持。回想一起在 QQ 上讨论，在 Slack 上开会的那些日子，其中有很多点子、思想我始终觉得是很好的。 项目最后在选择自主运营并进入创投阶段，还是开源上陷入了纠结。根据自己的创业经历，我力劝他开源，因为我觉得专门去运营这样一个项目是没有问题，但对于现阶段的我们来说并不是一个很好的选择，现实始终很现实，挫折会帮我们认识得更清楚。 于是，最后，开源了 当前完成情况 目前已经可以供发送量小中型用户使用，基本的功能已经测试通过。 HTTP协议的邮件投递，包括队列等待式投递、立即投递，立即投递又可选阻塞式投递（请求直接返回投递结果，默认投递后返回邮件 ID，并通过回调告知投递结果） 针对收件域名的发送频率控制 发送异常的根据关键字的默认处理以及可人工针对发送日志指定处理方法 下面要完成的功能 SMTP 协议的邮件投递 开发文档，包括模块的设计以及通信的规则 使用文档 安装工具，方便快速安装 传送门： 项目主页： https://github.com/jianxinio/postman 测试版本安装文档： https://github.com/jianxinio/postman/blob/master/docs/install.md 技术关键字 ruby[padrino], golang, nodejs, tls, redis, mysql, semantic-ui 非技术的内容 这个项目由于目前由一个人开发，所以整体（性能以及安全、可靠性）很局限于个人认知水平。很希望有更多的人参与，给邮件发送一个更好的选择。 如果你了解上面的技术关键字中的一点或者几点，欢迎先了解下大概的代码，提出代码中的缺陷/提交缺陷的改进代码。目前整体的开发文档会在后面快速跟进（由于公司新项目，可能下面速度会稍慢）。 还有我蹩脚的英文，后面依旧是希望同时提供中文/英文两个版本的页面/文档，也欢迎加入。 最后之前帖子传送门： https://www.v2ex.com/t/133221#reply71 https://ichou.cn/posts/a-ie8-css-background-image-url-error-without-quotes/ Fri, 24 Oct 2014 22:51:30 +0800 https://ichou.cn/posts/a-ie8-css-background-image-url-error-without-quotes/ 今天在日志中看到一个很奇怪的报错，发现有一部分用户请求了一个错误的图片 url 2014/10/24 13:23:35 [error] 29108#0: *38 open() "/var/www/xiaom_v2/public/assets/signup-bg.png),url("bgimg.png"" failed (2: No such file or directory), client: 118.119.93.192, server: www.ixiaomei.com, request: "GET /assets/signup-bg.png),url("bgimg.png" HTTP/1.1", host: "www.ixiaomei.com", referrer: "http://www.ixiaomei.com/about/" 2014/10/24 13:26:03 [error] 29105#0: *67 open() "/var/www/xiaom_v2/public/assets/signup-bg.png),url("bgimg.png"" failed (2: No such file or directory), client: 182.141.26.27, server: www.ixiaomei.com, request: "GET /assets/signup-bg.png),url("bgimg.png" HTTP/1.1", host: "www.ixiaomei.com", referrer: "http://www.ixiaomei.com/" 居然请求了 /assets/signup-bg.png),url("bgimg.png" 这样的地址，看得我也是醉了。不过也是很明显的可以看出问题出在 css 的多背景图片引用上。 到访客统计里面一看，过不其然，这两个都是 IE6。再查看其他记录，发现 IE8 及 IE8 以下的浏览器（下文称 IE8-）都有这个问题。 因为网站上多处使用了多背景叠加，却只有这一处请求是错误的，我就意识到这又是一个 IE8- 支持上的坑，查看 css 看到这行是这样写的： https://ichou.cn/posts/ci-wang-zhan-dang-ji-de-su-yuan/ Wed, 22 Oct 2014 22:49:02 +0800 https://ichou.cn/posts/ci-wang-zhan-dang-ji-de-su-yuan/ 上周末出去骑车，狂奔 140km+，回来没看 小美搬家 的访问统计就直接睡了，第二天醒来发现网站宕机了几乎一整天，周末一天只有一个 ip ，Run-Cry （ ＴДＴ） 由于网站换成 rails 后，类似的宕机这已经是第二次了，加上本来就是一台只有 512M 内存的 ECS，一直都有内存不够的疑虑。今天有空，于是把最近的日志 down 下来试着分析了一下。 Problem 1. 日志没有设置截断 所有的日志都记录在一个文件中，从29号清空日志到现在竟然已经有 60M 了，无论是查看还是查找都极为不方便。这个问题是由于 Rails 原生的日志组件比较薄弱，之前自己也没意识到这个问题，解决方法通常有两种：一种是使用 Gem，另一种是在系统中安装其他的日志组件并使用，比如：logrotate。从 ruby-china 的讨论中来看，如果直接使用 Rails 来处理日志，多线程处理会成为比较头大的问题，所以选择 logrotate 的成本相对低很多。 Problem 2. 搜狗图片蜘蛛抓取导致大量 500 错误 打开日志发现最多的错误就是一个来自 218.30.103.38 的请求导致的 500，这个 IP 是搜狗负责抓取图片的蜘蛛，每次和另外两个蜘蛛一起访问。 搜狗的蜘蛛感觉有点小神经，可以看到其中两个都指定了请求文件的类型，一个 html，一个 jepg。html 倒没什么问题，但是对着一个网站的主页抓取却期望得到一个 jpg 的返回，这个设定真的好么？如果做了适当的处理还好，像这个网站这样的必然只能导致 500.对于这一点我真有点摸不着头脑了，先 Mark 一下，回头了解一下搜狗这么做的原因再作应对。 另外，我还发现搜狗蜘蛛的访问频率颇高，稳定的一个小时来一波，只逛首页，每一波持续的时间不定，通常会有5-15组请求，每组就是上图的三个请求，两组间间隔是两分钟。不确定这个频率是否偏高，于是我将频率和图片蜘蛛的问题一起反馈给了搜狗，希望能收到回复。 Problem 3. 请求被带上了奇怪的尾巴 本来小美的首页地址是没有带任何 Url 参数的（带了也没用~），也没有生成什么带参数的首页链接，但是有些来访的访客（应该都是蜘蛛）却带上了奇怪的尾巴。这些尾巴有： /?fid=40 有来自百度蜘蛛和海外的请求 /?auth=7df1ovPb1BZBVZ8M7b01PbwdvyREvZuy2W3iq54tnSTVLiHiQXdma0R9BPMnAs8&fid=50 大多来自江苏或阿里 /?v1_v2=fAJi5 主要来自 google 蜘蛛 这些 URL 的来源也让人费解，不过它们也没有什么实质性的影响，暂时观望 https://ichou.cn/posts/aliyun-oss-support-plugin-for-wordpress/ Wed, 03 Sep 2014 22:42:49 +0800 https://ichou.cn/posts/aliyun-oss-support-plugin-for-wordpress/ 本插件主要为 Wordpress 提供基于阿里云 OSS 的远程附件存储功能，并且最大限度的依赖 Wordpress 本身功能扩展来实现，以保证插件停用或博客搬迁时可以快速切换回原来的方式。 项目地址 Github 当前版本 Stable: 3.0.0 插件特色 支持 Aliyun OSS 的图片服务（根据参数获得不同尺寸的图片） 自定义文件在 Bucket 上的存储位置 支持 Https 站点 全格式附件支持，不仅仅是图片 支持 wordpress 4.4+ 新功能 srcset，在不同分辨率设备上加载不同大小图片 支持在 WordPress 后台编辑图片 图片服务支持预设图片样式，可用于图片打水印的需求 中英文双语支持，方便使用英文为默认语言的同学 代码遵循 PSR-4 规则编写，并使用 phar 文件作为 release 版本 插件使用 关于插件使用方式的 Wiki: Quick start 下载 latest release 安装 将插件解压上传到 /wp-content/plugins/ 或者通过 WordPress 插件中心上传安装 注意上传时 zip 包的名字,建议使用 aliyun-oss.zip 配置 启用插件 Aliyun OSS 进入设置页面 完成相关设置 启用图片服务 关于插件中图片服务的 Wiki: How to use Image Service https://ichou.cn/posts/guan-yu-san-huan-nei-wai-jia-che-lu-cheng-de-ce-suan/ Tue, 02 Sep 2014 22:45:53 +0800 https://ichou.cn/posts/guan-yu-san-huan-nei-wai-jia-che-lu-cheng-de-ce-suan/ [](http://www.ixiaomei.com/) 小美搬家是我毕业后和同学一起开始的创业项目，就目前来说称作项目已经不太合适了，可以说它就是我的职业。小美搬家旨在为当代年轻的城市青年提供高质量的便捷搬家服务，简洁、快速、优质是我们不同传统搬家公司的主要特点，目前服务范围仅覆盖成都地区（今年刚起步(￣▽￣)） 我在小美搬家的承担主要任务是服务创新和技术开发，我们这一版的官网确认动工已经是去年这个时候的事儿了，服役一年几乎没有大的改动也差不多快审美疲劳了。之前设计的在线测价系统也是十分简陋的，随着客户转化流程的不断改进，这样的测价已经不能满足工作需要了。虽然新的网站已经开始筹备，但是这个问题迫在眉睫，于是决定提前将网站的在线测价系统更新。 整个测价系统中，涉及地理位置和路程测算的部分都是由 百度地图API 来实现的，本来一开始考虑使用 Web API，最后发现 Javascript SDK 才是更适合我们的真爱。但是即使是功能繁多的 SDK ，有一些需求依然不能解决，比如：区分驾车行程在三环内外各有多少。 问题描述 由于我们的搬家服务对于三环内外车程的计费方式是不同的，所以如果测价里面不能区分三环内外那么测出来的价格也就失去了参考价值（总不能让用户测好填进来吧，操作成本太高）。 否定的方案 把地址做成预设的点，点对点选择，点点间路程数据预先测算好。 这个方案就不多说了，假定100个点（好少），C100（2）= 4950, wakaka~ 已经哭晕在厕所 让客户来选择搬出到点是否在三环内测，跨三环的平分车程 不用怎么推敲就知道不靠谱 在2的基础上，如果跨三环，让客户选定最近的三环立交 如果遇到两点都在三环外，但主要车程都在三环上的情况怎么办？ 灵感来源 在调试 百度地图SDK 的时候，发现有在一个圆范围内搜索目标的 demo，而成都的三环也近似圆形，似乎可用。但是在看过源码之后，无比失望.。o○　○o。. 百度 demo 里面的范围内搜索虽然表示的是一个圆，但其实那只是一个用来标识的覆盖物，真正的搜索是在一个正方形的坐标范围内进行的。虽然百度的 demo 没什么用，但就在这里，我看到了解决问题的关键——坐标——有了坐标就变成数学问题了。 解决思路 百度地图搜索的结果里面是带有经纬坐标的，这个坐标叫百度坐标（为了军事保密，不是准确经纬坐标）。这个坐标是一个球面坐标，计算需换算成平面坐标来进行，后面详解。 有坐标之后，以市中心为原点画圆，使圆尽量与三环重合，得圆的方程。 搜索结果中有搬到地两个点的坐标，连线，得直线方程。 将直线与圆求切点，会有两种情况： 没有切点或一个切点 这说明两地都在三环外，且不用走三环，测算的车程全为三环外车程 两个切点 两点都在圆内 前面白算了,全是三环内车程 一个点在圆内，一个点在圆外 求两点连线段在圆内部分的比例，正比与车程，得三环内外车程的估值 两点在圆外同侧 不用走三环，测算的车程全为三环外车程 两点在圆外异侧 求圆内切线段占两点连线段的比例，正比车程，得三环外和三环上的车程估值 计算公式什么的，就没必要列出来了吧 关于坐标 通常情况下，我们使用的经纬度坐标，地球是球形的，所以经纬度坐标表示的是一个球面，称为球面坐标。 https://ichou.cn/posts/wordpress-you-jian-cha-jian-fen-xi-yu-jian-xin-jianxin-for-wordpress/ Sat, 30 Aug 2014 22:43:03 +0800 https://ichou.cn/posts/wordpress-you-jian-cha-jian-fen-xi-yu-jian-xin-jianxin-for-wordpress/ 虽然 Wordpress 邮件插件已经有很多了，国外的 Configure SMTP 和 WP-Mail-SMTP，国内的 WP SMTP，甚至还有很多所谓的无插件添加 SMTP 邮件服务的教程，但是 简信 和上面这些的邮件发送方式并不一样，即所谓的编程式邮件，可以作为一种（伪）geek的选择。 wordpress 默认邮件解决方案 wordpress 默认的邮件解决方案是使用 php 的 mail() 方法，调用的是 php 环境自身的邮件组件。想起来这的确是最简单、最干净的处理方式，就像图片处理用 gd，请求用 curl 一样，但是由于垃圾邮件这个问题的存在, mail() 就成了被遗弃的一部分了。大多数 php 环境里都没有开启对 mail() 的支持，即使发出去的，也通常会被 spam 拦截掉，这也是静默安装的 wordpress 无法发出邮件的原因。 wordpress 内置其他解决方案 除了 mail() ，wordpress 内核中还内置了其他几种邮件解决方案： SMTP POP3 Sendmail Qmail SMTP 是最常用的解决方案，上面列出的几个插件都是调用的这一功能，而这些插件本身其实就是实现了 SMTP 的快速配置接口。 POP3 和 SMTP 类似，但是现在用得已经相对较少了。 Sendmail 和 Qmail 是类似的，都是一种需要在服务器上安装的邮件发送组件，其具体实现方式没有研究过，因为需要服务器组件支持，感觉上一般用户很少有人使用。 SMTP 插件和 SMTP 无插件教程 如上所说，SMTP 插件本身并没有带上 SMTP 邮件发送的核心方法，只是实现配置接口。而网上流传的 SMTP 无插件教程，就是把配置的核心部分提出来放在 WordPress 的源文件里。从原则上来讲两种方法是没有优劣之分的，但是从管理和 wordpress 本身的架构方式（钩子遍地式架构）来看，还是插件的方式更值得推荐。 https://ichou.cn/posts/ji-yu-a-li-yun-ossde-wordpressyuan-cheng-fu-jian-zhi-chi-cha-jian-a-li-yun-fu-jian-aliyun-support-xiu-ding-ban/ Thu, 28 Aug 2014 22:40:24 +0800 https://ichou.cn/posts/ji-yu-a-li-yun-ossde-wordpressyuan-cheng-fu-jian-zhi-chi-cha-jian-a-li-yun-fu-jian-aliyun-support-xiu-ding-ban/ 原插件地址：http://mawenjian.net/p/977.html 由于原插件作者没有持续更新，已经无法使用（或无法兼容最新版本环境），故对此进行一些小修正 修正日期：2014-8-27 版本号：1.1 修订项目： 插件年久失修，其内部调用的 Aliyun OSS php SDK 已升级 WordPress 3.5以后 设置->多媒体 中没有路径配置，导致配置不便 Aliyun OSS 可以绑定自己的域名，插件中不能简单的设置 修订内容： 升级 Aliyun-OSS-SDK 到 1.1.6 版本 (2014-06-25更新) 设置中可直接配置访问路径 Url，支持已绑定到 OSS 的独立域名 支持自定义 OSS 上文件的存放目录 （不影响本地存储，中途若修改请手动移动 OSS 上文件，否则可能链接不到之前的资源） 修正原插件 bug 若干 TODO: 原作者的代码在 github 上托管了一份，是不是应该联系原作者进行更新 插件下载： OSS-Support.zip 源码 https://github.com/yiichou/aliyun-oss-support Issues 无法支持 Aliyun ACE 平台 原因分析：ACE 本身的静态文件存储就是使用的 OSS（自带），静态文件可以上传到服务器，但是在执行存操作时会被移动到 OSS（自带） 中。此插件实现原理是：各个尺寸图片在服务器上生成好后，触发上传到 OSS（用户） ，再根据设定来决定是否删除服务器上的图片。在 ACE 上，生成的图片实际并不在指定的位置，故不会有文件上传到 OSS（用户）。 https://ichou.cn/posts/jia-ru-jian-xin-kai-fa-zu/ Sun, 29 Jun 2014 22:37:46 +0800 https://ichou.cn/posts/jia-ru-jian-xin-kai-fa-zu/ 『简信』 是小伙伴业余时间开发的一个编程式邮件系统，主要用于快速的构建基于邮件的 web-server 构想 http://jianxin.io https://ichou.cn/posts/hello-my-another-ichou-dot-cn/ Tue, 15 Apr 2014 22:30:25 +0800 https://ichou.cn/posts/hello-my-another-ichou-dot-cn/ 这又是一个全新的开始