qyb的博客

从知乎上看到相关的讨论：https://www.zhihu.com/topic/19568370，周末晚上尝试了一下

按照文档上(https://letsencrypt.readthedocs.org/en/latest/using.html)所描述，Apache服务器是可以用脚本自动完成证书申请和配置全过程的。但我最终参考的还是一个通用的方案，https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-wit...，手工完成申请和创建，然后再自己配置

非常简单，除了一开始我填写了5个域名反馈DNS超时；最后改成2个域名（dup2.org www.dup2.org）就平稳完成，得到了4个相关的文件

然后配置证书，包括参考 http://stackoverflow.com/questions/16200501/http-to-https-apache-redirec... 设置了把 HTTP 自动重定向到 HTTPS.

最后看看 google 会不会给我加权了.. 以及三个月后再重新延长证书

有人问我什么是 SRS，这里简单解释一下

首先是要理解 SPF，https://en.wikipedia.org/wiki/Sender_Policy_Framework
就是域名拥有者通过 DNS TXT 记录，声明哪些IP地址发出来的标记Sender为本域的邮件是可以被信任的
SPF很好的过滤了伪造Sender的行为，从而Sender的信誉可以被积累和建立

但是SPF对 autoforward 这种配置造成了困扰
一封邮件从Google发送到Hotmail，然后Hotmail将其转发到Sohu
转发过程中Hotmail将如何声明Sender？
如果是原始发件人的话，就违背了Google的SPF声明

所以需要重写Sender，让Sohu信任这封看起来是来自Hotmail的邮件
不过Hotmail除了重新Sender，还得支持当这封信soft-bounce之后，能正确的将弹回邮件再弹给Google
于是还得有一个防重写伪造的机制，确认这封弹回的邮件的确是从Google来的然后重写转发的

最终专业从事 email gateway/forwarding 的人提出了 SRS，https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme
希望采用 SPF 验证的服务器，上面的例子中是Sohu，能认可Hotmail的这种重写行为，http://www.openspf.org/SRS

早上简单做了一些调研

1.因为 dup2 一直用的是 Drupal，所以先从它家的BlogAPI看起：https://www.drupal.org/project/blogapi 、https://www.drupal.org/documentation/modules/blogapi（2013年更新） 。BlogAPI Module 支持"Blogger API (outdated), MetaWeblog API, and most of the Movable Type API"，基本上可以认为这些 API 对应的 Publisher 也不再推广
2. Drupal 的 Blog API 是基于 XML-RPC 的，安全问题不少。现在的潮流是 OAuth + RESTful API，历史上也有 Content API、RESTful Web Services 这样的项目；到了 D8 时代已经全面在底层支持 RESTful，慢慢的应该会有一些成熟的项目出来
3. WordPress 现在已经有了一套很全面的 API，不错！https://developer.wordpress.com/docs/api/
4. Google Blogger API 升级到了 3.0：https://developers.google.com/blogger/
5. Medium，就在 2 个月前发布了 API！！！The Medium API is now open to everyone
6. 意外的发现了 Apple News 也有了 API，好大的一盘棋：https://developer.apple.com/news-publisher/ ，而 Drupal，则支持了这个 API https://www.drupal.org/project/publish_to_apple_news
7. 国内的博客托管平台，研究了一下 CSDN，发现已经失效，顿时失去了兴趣...有时间再调研国内的各个所谓 Medium Platform 的情况吧。现在的感觉是微信公众号的素材 API 可能还稍微靠点谱

果然是术业有专攻，FastMail 的 JMAP 提出快有 2 年了吧，但这里已经有另外一家公司搞了一个类似的协议 Nylas Sync Engine https://github.com/nylas/sync-engine，Python 开发的，这个我喜欢

而且，人家也实现并开源了一个看起来很棒的 Email Client：Nylas N1 https://github.com/nylas/n1，JavaScript App，打包基于 Atom，所以目前支持的平台包括了 Windows、Linux、Mac；框架基于 React，所以我甚至在想是不是能山寨到 React Native 框架上。。。

按照我以前的分类，FastMail 主要是一家 Inbox + SMTP 服务提供商，Nylas 是一家 Email App 服务提供商。JMAP 协议的竞争优势是将在 Cyrus IMAP 3.0 里被支持（FM看起来是Cyrus的支持者），Nylas 以后怎么发展不太好说，毕竟成立时间有限.

我去年产生一个观点：Email App Provider 独立价值是有疑问的，从各个免费邮件客户端纷纷被 Google（Sparrow）、微软（Acompli）、Dropbox（Inbox）等巨头收购就能看出来。很可能 Email App Provider 只能在企业邮箱市场开发 Groupware 客户端才能生存

Nylas 的模式没有仔细看，回头再研究

--
以前的Blog
如何做好一个 Mailbox Provider.2013-06-07
Mark 一下 JMAP 和 switchboard.2014-06-18
JMAP .2015-03-04

上周，学习某公司Blog的时候跳到另一个公司的业务介绍。觉得还蛮有意思，有点当初看到 Mad Mimi 的感觉；就如同 Marc Andreessen 所介绍的 unbundle 理论 —— 从某个巨型服务上切下一块。

周六晚上因为某事无意中想到 dup2.com 这个域名已经被注下好多年了，4 字母域名如今能卖多少钱呢？？？然后猛然一惊：刚刚看到的这个业务模式其实和 dup2.com 还蛮搭配的啊~~

周末和 dup2.com 域名持有人 qyt 同志简单讨论了一下，也许 2016 年 dup2.com 就会蹦出来和大家见面了 :)

不卖关子，是企业服务方向，看得到的一个路径上2015年国内也有创业者开搞了。SaaS 产品征途漫漫，适合作为一个业余项目运作

发现阿里云的一个 SDK 已经同时集成了 Xiaomi+Huawei，也有人说友盟集成了 Xiaomi

Android 第三方 Push 推送方案使用调查

关于 Lollipop 下如何处理 boot.oat, services.odex, services.jar 的方法可参考上一篇http://dup2.org/node/1625

因为我们没有华为 framework 的源代码，只有 google 自己的 AOSP tree，不过不要紧，只要华为不是丧心病狂的对 AOSP framework 做了大幅度的修改，经过简单的 patch 也能达到我们的目的

首先拿到华为原厂ROM里面的 boot.oat 和 services.odex，在 /system/framework/arm 目录下；经过一番处理，反编译 samli 文件到 services 目录

然后在 AOSP tree 的 5.1.1 最新分支（写作本文的时候用的是 android-5.1.1_r14）编译，按上述步骤换个工作目录同样处理 WORKING_DIRECTORY/out/target/product/generic/system/framework/arm 目录下的 boot.oat 和 services.odex

视需要 patch 原厂的 samli 文件，然后打包成 classes.dex，压缩为 services.jar，覆盖机器上 /system/framework/services.jar，重启

祝你好运

先记录一下，https://github.com/liudongmiao/ForceStopGB/blob/master/aosp/readme-5.0-z... 里的方法似乎是能用的，
但目前还没有达到我原设的需求

1. 下载 smali 和 baksmali，https://bitbucket.org/JesusFreke/smali/downloads 这个里面的应该都能在 Java7 上运行。。。至少系统上为了编译 framework 是安装的 Java 7
2. 下载 oat2dex，从 https://github.com/testwhat/SmaliEx/releases 下载一个 oat2dex_java7.jar
3. 从 arm 目录里拿到 boot.oat 和 services.odex
4. 执行 java -jar oat2dex.jar boot boot.oat; 这会在 boot.oat 所在目录下生成 dex odex 两个子目录
5. 执行 java -jar oat2dex.jar services.odex dex/ ; 生成 services.dex
6. 按照教程处理 services.odex 即可：java -jar baksmali.jar -a 22 -b -s services.dex -o services; ...; java -jar smali.jar -a 22 -j 1 -o classes.dex services;
7. 最后生成 services.jar：jar -cvf services.jar classes.dex; 覆盖，应该能重启成功

有！待我仔细回忆一下过程：

2010年的时候去爬岗什卡，成功登顶。因为同帐篷的一个队友体能不太好，登顶后回到冲锋营直接就睡了，所以其它队友早就集体下撤，而我被队长分配等他恢复以后i一起走，落在了最后面。

岗什卡的问题是冰裂缝很多，尤其是冲锋营到最后大坡的那一段，必须大家穿在一条绳上蛇行前进。行进路上亲眼看到走在第一个位置的协作掉到冰裂缝里幸好紧跟他后面的搭档经验丰富且机警立刻卧倒在地，避免第一个人掉进去太深，然后大家一起把他拽出来。大本营和冲锋营之间的路途比较安全，不用结绳走，但靠大概每100米打一个小旗来确认路径。上山的时候天气很好，走到一个小旗后，看雪地另外一头的小旗，沿直线走过去

从冲锋营下撤回大本营的那段路很长，除了我们俩还有一个协作，只不过这位协作是农大的学生可能还没毕业。队长下撤的时候天气还好，所以他放心留我们三个最后。可是走着走着，天气变坏，从小雪变成大雪，几处小旗完全被淹没在雪里；协作同学有点慌，到处找路；几段路径基本上雪到了小腿深；而队友因为体能不行控制不住身体吧，若干次甚至踩下去整个大腿都陷下去；我帮着他把腿刨出来也消耗了大量的体能。

随着天色渐晚，气温下降更厉害，风雪更大，体能也接近为零，走着走着就觉得特别丧气，心想“这一趟要是走不回去可毫不奇怪呢”。也没有什么太多关于生死、亲人的念头在脑海里盘旋，也许是体能真的消耗太大，人体的自我保护机制已经启动大脑自动降频了。就是想着走，以及一个可能这次就挂在这里的念头。平时夜深人静时有时想起死亡还是挺毛骨悚然的；当时除了坚持走这个念头，情绪上没有恐惧，只有丧气

最后走出雪地，也没有什么欣喜若狂。丧气的念头没有了，继续走呗。

后来想，如果我不是留在最后，就他们俩（协作是必须要陪最后客户的），凭自己的力量应该是走不下来的。未必丧命，估计也会被冻得大病一场

其一：

小朋友突然指着她的匡威对我说：“爸，你们小时候这种鞋就叫运动鞋了吧...”

一瞬间关于运动鞋材质的多个名词从脑海里呼啸而过“EVA、气垫、Gel、...”，我回答：“是啊，我们那个时候关于运动鞋没有太好的技术，类似这样橡胶鞋底的就算运动鞋了”

想了想我又补充说：我像你这么大的时候...大概1990年吧...你想想改革开放也没多长时间，农业开始给力也不过10年，这种轻工化工就发展时间更短了，没有原料，没有生产线，工人需要培训，blahblah，总之需要积累...所以最开始的运动鞋也就和做橡胶轮胎的工艺差不多...当然现在好多了，到2010年的时候，中国的工业能力，在很多方面世界上都是处于前列的...韩国，它的汽车很厉害，造船业很厉害，不过我们正在慢慢追赶

其二：

小朋友说：每当我看到网上有人说抵制X货，我就会看着手里的养乐多心里默默呵呵——你们知不知道养乐多是日本生产的

我说：是啊，不要理会说抵制日货的人...一般来说，贸易封锁对双方的消费者都没有好处...如果你有兴趣，家里有一本《经济学通识》，放在书架上，薛兆丰写的，你可以...

小朋友：是啊，我已经看过了，里面说了抵制日货没有好处

我汗：你。。。啥时候看的

小朋友：大概一年前吧，随便翻了翻，看了一点儿

我：嗯，要是有兴趣就把它当经济学入门的小册子看看吧，还是比较通俗的...这个贸易封锁就是把对老百姓造成的压力最终体现在对政府的压力上，就看哪边政府忍耐力更强，不同发展阶段的国家，忍耐能力不一样，blahblah...比如朝鲜现在就在饥荒...对了，朝鲜是一个很奇葩的国家你知道吗？这个国家竟然公然生产毒品，外交官掩护走私毒品，哈，哈，哈...

说到这里，到学校了