無標題文檔

upyun-cli.py,又拍云的命令行工具

截图

其实这是个填坑的项目,两年了我终于把当时留下的坑给填上了,但愿这迟来的不会太迟。

事情是两年前 又拍云 做了个活动,大概是为又拍云开发第三方应用就可以获得不定的流量。由于我的博客一直用的是又拍云的资源服务,自然这个活动对于我而言是很有诱惑力的。

又拍云 其实已经是非常老的老朋友了,往前可以追溯到又拍在线图片服务时期。凭借多年的图片处理以及运维经验,我个人从 12 年使用到现在没有出现过任何的问题,对于又拍云的服务自然是非常的信赖。

对于老用户也是相当的信任,那个活动我其实并没有开始针对又拍云的 SDK 开发任何的小项目,只是报了个名,他们就将不菲的流量资源(T 级别,多到个人博客根本用不完)已经给到我了。

其实我是个极其懒惰的人,自然这件事情就因为各种琐事给忘在脑后了。直到近期我翻阅 github 项目的时,发现 Star 的项目中,为数不多的项目还在持续的更新,这里就有又拍云的 Python SDK

有些触动,不仅仅是因为 又拍云 那种默默实打实做实事的态度,同时也是为了我自己的懒惰感到非常的惭愧。

言归正传,我自己也荒废了 Python 语言多年,刚好可以拿这个 SDK 练练手,所以就有了这个小项目。

有些惭愧没使用 Python 做过实际项目多年,发现 Python 这门语言的发展还是很快的,非常适合短平快的些项目的开发。

现在的 Python 已经过了阵痛期,如果你还在问是选择 Python2 还是 Python3 这些月经性的问题,这里我建议如果没有历史包袱那么就直接使用 Python3 开始吧。

回到 upyun-cli.py ,除了使用 Upyun SDK,还使用了些目前很流行的模块,例如 clickcoloramapyaml 等。

当然这个小脚本还没有大到需要分模块的地步,因此我将所有的代码都集中在一个文件,也同时是为了方便部署使用。

最后废话不多说,还是抛砖引玉直接看代码吧。

作为 Python 新手,我很期待有经验的同学能够给我些更多的建议 :^)

网易云音乐接口的简单分析

由于公司网络的关系,在线听音乐经常会被断断续续,于是考虑批量将音乐(高清)下载到本地。同时,由于熊孩子的缘故,在自己的音乐榜单上「小苹果」等歌曲一直在前排,显得很没有「格调」,于是就萌生了折腾云音乐接口的想法。

网易云音乐的接口相对而言还是比较简单,尤其是大部分前端与服务器端通信的逻辑都已经在 core.js 里面,虽然加了压缩但是没有混淆因此还是很好去处理和理解。

访问云音乐接口每次都需要带个名为 csrf_token 的 GET 参数,这个参数很好找就在 Cookie 里面,而且还是持久化的。

剩下的两个参数大部分都是 POST 过去,分别名为 params 和 encSecKey,里面的字符串经过 encodeURIComponent 处理过。

云音乐请求的加密方式

加密和解密的方法还是在 core.js 这个文件里面能够找到,AES CBC 加密,客户端自己生成 Pair 。两个加密解密的方法都暴露在全局作用域下,分别名为 window.asrsea 以及 window.ecnonasr

部分的接口,例如 feedback/weblog 是没有做任何重复请求处理的,换句话说可以刷。上面说到 csrf_token 其实是持久化的,也没有来源判断等,因此拿到 Cookie 以后就可以自己构造请求。

不过话说回来网易的平台设置做得的确财大气粗,乃至多点并发去做请求都能撑得下来(估计是我的小水管还不够人家的零头)。

顺便提一句,再深入研究下其实可以发现非会员也可以下载收费资源,这里不铺开讲了。

总结下一些看起来是「大道理」的心得:

  1. csrf_token 这些参数应该和时间和请求次数挂钩,更不应该加入到 Cookie 里;
  2. 客户端和服务器端的加密一直是安全方面讨论的主要课题,我的倾向是轻客户端重服务器端,不要把所有的逻辑都写在客户端中;
  3. 前端脚本代码的打包方面尽可能的不要污染全局空间,尤其是框架方面的代码;
  4. 服务器端应该对用户异常行为作出判断,例如业务方面用户频繁下载以及标记打星是否合理;
  5. PS,网易云音乐考虑下 WebSocket
  6. 查找和 Hook 网络接口这块可以从请求方法入手,通常现在端架方面请求都会放在一个方法中处理;
  7. 有点废话,抓取的时候使用 HTTP Keep-Alive 头能够明显的加快请求速度;
  8. 可以考虑多个 IP (代理)去抓取数据,以免实际地址被服务器 Block;
  9. 实际情况中需要考虑的外部因素有很多,例如尽可能的在预算范围内购买足量的存储空间…;
  10. Charles 很好用,这钱花得值…

最后,顺便刷个榜开个玩笑捣蛋下。

云音乐刷榜

-- EOF --

NFC,Apple Pay 的幕后英雄

昨日,果粉们期待的 Apple Pay 终于在中国大陆上线,对于 iPhone6 以及以上的用户而言,又多了一种移动支付方式。我们开玩笑的说,以后这手机的支付方式的数量恐怕会比我们的存款还要多 :^)

Apple Pay 通过 NFC 近场通信协议支付。NFC 已经不是新鲜事物,往上可以追溯到 Nokia 时代。

Nokia 6131

NFC 协议的制定在 2004 年,两年后也就是 2006 年才出现了第一款搭载 NFC 的设备是 Nokia 6131。那时候,NFC 只是用来点对点近距离通讯,和支付似乎毫无关系。

直到那以后的很多年,Nokia 作为行业的老大,NFC 大部分都是 Nokia 「自己」在玩(这里有来自 Windows Phone 的 Blog 的 Nokia NFC 设备的详细历史)。NFC 和早先众多的硬件(例如 GPS)类似,高昂的价格以及小众的使用场景让其束之高阁。

钱江后浪推前浪,前浪死在沙滩上。Nokia 以后发生了什么大家都很清楚了,而 NFC 作为 Nokia 的「遗产」却被 Android 继承了下来。真正大范围铺开让公众了解 NFC ,是在 Android 平台的崛起。

Nesus S

在 2010 年 Google 发布的 Samsung Nexus S 首次将 NFC 加入到机子的硬件配置中。

Nexus S 这款机子有曲面屏幕、Android 2.3、NFC、可更换电池等特性,外形直到今天看来都不会过时。现在看来,三星正是通过 Nexus S 让其在 Android 奠定其领头地位,这是后话了。

Google Wallet

NFC 逐渐和支付关联起来,大概是 Google Wallet 的发布。现在看来,Google 每一步棋都下得十分的稳妥。有 Google 开道加上硬件的摩尔定律,NFC 芯片才逐渐得在 Androd 平台铺开。次年(2012年),Google 发布了 Google Wallet ,而这时候做硬件方面的准备已经有了。

那年,Android 产品总监 Hugo Barra (现在去小米当差了)在当年的 Google IO 2012 中提到,现在每周搭载 NFC 的 Android 设备出货量达到了一百万台

所以从另个角度上说,Android 平台的发展使得 NFC 老树新开。

然而,Google 不在中国大陆市场拓展以及国内的 Android 的市场混乱,再加上 支付宝 和 微信 这「两座大山」,NFC 用于支付的场景几乎无法普及。

一方面厂商卖力气吆喝「我发布的手机搭载了 NFC!」,而另一方面由于使用场景的缺失,用户对购买手机对于有无搭载此芯片也处于无所谓的态度。如此循环,厂商自然逐渐不会讲 NFC 作为卖点,而根据「传统」以及「人有我有」的思想,NFC 已然成了 Android 中高端机型的标配。

iPhone6 with NFC Chip

我们回到 iOS 平台,众所周知 Apple 在硬件方面是相对比较「保守」的。千呼万唤始出来,直到 iPhone 6 才搭载了 NFC 芯片,苹果用于 NFC 芯片的场景就直白了很多 - 支付。

Apple Pay 其实在国外已经发布了一段时间,NFC 用于支付的使用场景也逐渐的增长。

现在,每款 iPhone6 以及以后的苹果设备、Android 的中高端机型上都会搭载 NFC 芯片。 NFC 从当时的阳春白雪到现在飞入寻常百姓家,一直在后台默默得无闻着。

那么,有着惊人的品牌溢价和号召能力的苹果这次能否如指纹识别一样,逆推 NFC 使之成为主流的使用场景呢?

我们还是拭目以待吧。


-- split --


顺便光聊聊 Apple Pay 这个玩意。

如果单纯聊 Apple Pay 那么绕不过的两个坎的分别就是 支付宝 和 微信。 Apple Pay 本质上还是刷卡消费,所以更准确的说法应该是 银联 和 支付宝 以及 微信 ,而不是 Apple Pay。

我们从体量上看, 2015 年的 iPhone 出货量已经显示了增速放缓甚至下行。从总量上看,iPhone 6 以及以上搭载了 NFC 硬件设备的数量级大概在千万级别。

这几千万用户哪怕全部绑定了银行卡,对于支付宝和微信过亿庞大的活跃用户量,比例上也仅仅是个零头。蚂蚁撼树,实在是很难有太多的变数,即便这是苹果的产品。

然后从支付方式上看,Apple Pay 使用的 NFC 通讯方式是比目前扫码支付要便捷。但是要想到和指纹识别不同,NFC 作为非常成熟的技术,在技术上已经完全不是壁垒。

Apple Pay 能做到的支付体验,相信微信支付、支付宝也一样能够做到。同时苹果迈出了第一步,甚至国内的众 Android 厂商就会跟进。能够遇见的将来,「小米支付」、「华为支付」甚至「锤子支付」等众多付方式就会出现。

所以,至少在中国大陆对比支付宝和微信支付等平台,Apple Pay 只是个可以替代的产品。Apple Pay 会像 Apple Music 甚至早先的 iTunes Ping 一样,成为明日黄花。

--

最后,来个段子:

经过三个小时,我们的产品经理 狗蛋 终于绑定好了 Apple Pay,拿着刚发的年终奖准备中午去麦当劳「大干一番」。

然而,现实有点让 狗蛋 出乎意料。当他兴冲冲的点完准备付钱的时候,收银员告知他不支持他口中所说的「Apple Pay」方式支付。

「这怎么会呢?」,狗蛋表示疑惑喃喃自问:「你们店还有星巴克等在新闻里说是已经支持了的,怎么会用不了呢…」

「先生,您可以再考虑下使用其他方式付款,我们店是支持 支付宝 和 微信 付款的。」

很明显,几个回合的询问下来,营业员愿意招待他的时间越来越短,同时后面排队的顾客对 狗蛋 也来也不耐烦。

最终,招架不住现实情况的 狗蛋 只能选择使用微信付款。

-- eof --

博客增加了 SSL 证书

互联网的风潮一阵一阵,先是个人网站又是博客然后微博,现在又变成了微信朋友圈。

这个博客从零七年至今差不多也有一段时间,回看自己也写了不少的无用文字。博客的流量虽然不多,但通过它结识的朋友不少,很开心很多都是志同道合的狐朋狗友。所以写博客,这也是自己难得坚持下来的几件事情之一。

年纪渐长,对于安全这个东西却是越来越在心。每年博客在年初的时候都应该整整,考虑到 https 访问已经是风潮(淘宝都全站 https 了)甚至以后使用 Chrome 浏览 http 未加密的内容都会给普通用户个警告,于是我也赶紧给博客加上了 SSL 证书。

HTTP 证书

目前使用的证书是 StartSSL 的免费证书在注册和使用上并没有多大的问题。如果您和我一样也是使用 Nginx 的话,这里有个文档估计你会感兴趣,基本上几个小时就能搞定。

相对站点主要麻烦的还是图片等相关的资源通过 https 访问比较麻烦,因为我是将资源都统一另外放到了个二级域名下。好在我使用的「又拍云」存储可以通过 https 访问(但是我没搞定绑定域名如何去处理,有知道的同学请告之),统一替换看数据库的 url 以后就可以直接通过 https 显示图片了。

免费的其实是最贵的,考虑如果 StartSSL 不靠谱的话,欢迎您能够提供更加有用的讯息。 UPDATE: 听从了 @依云 的建议使用 Let's Encrypt 证书服务详细的文档可以参考这里

还有细心的同志也发现了,15 年下半年的时候我把博客站点从 Digital Ocean 迁移到了 Vultr 。这里并不是 Digital Ocean 不够好,而是同样的价格 Vultr 的速度更快而已(SSD、东京机房)。

这几年博客写的不多,甚至一年也就出那么几篇文章,除了自己的确变懒(同时也变胖了)以外,还有可能就是想得比说的更多。

不管怎么样,如果您能看到这篇文章,说明您还在关注我,在这里表示甚是感激。

最后,提前拜个早年 :^)

-- eof --

成为更好的自己

第一次看见 闭月 大概是在零九年的时候。

看她的气质,当时看到她以为是设计师。然而,她自己说她是前端的时候,我有一些惊讶。那时候前端这个职位还是刚刚起步,在国内提供这个职位的公司不多。作为女生来应聘这个职位并且能够通过面试,自然就更是难得。

再后来的合作,就是当时淘宝 UED 组织的前端兴趣小组「懒懒交流会」了。她当时作为组织委员和主持人帮助我们这些不善言辞的技术人员一次次的完成了分享,十分的辛苦。她的临场表现以及应变能力也是得到了大家的赏识和肯定。

印象中很深的一次是在 D2 交流会上,我演讲时因误操作加上我当时的上台经验不足,造成场面有点尴尬。她作为主持人帮我打了圆场,使得我的讲解能够顺利继续进行,至今对此还是表示感谢。

再后来我从原团队离职,她还组织大家每人给我写了张明信片,十分的有心。

偶尔老同事聚餐,聊到她的时候得知她换岗去当了产品经理,我还是有些诧异的。在阿里的内部转岗是需要很大的勇气以及承受很大的压力的。

然后就是看她的朋友圈,她和其他的姑娘晒自拍和美食不同,她总是会晒些自己阶段性的东西,例如今天她做了什么。甚至,她为了能够在生完孩子以后穿上比基尼而做了个健身计划,这当时被我们这些老同事奉为谈资。

就是那么个喜欢折腾的姑娘,竟然在八月份的时候离职去创业了,还是一个人。这多多少少让我们感到有些意外。在阿里近六年,她放弃了具有竞争力的薪资以及丰厚的阿里股票,这比转岗更需要勇气以及所承担的压力。

从阿里离职创业的人不少,而像闭月她那样「裸辞」去创业的人不多。但同时,看她冒着那么大的风险以及顶着那么大的压力,我们十分好奇她的创业项目是什么。

她首先印了一批记事本,免费送给同样想坚持六十天完成计划的用户。

将近一千多本有质量有设计的记事本定制下来费用对于创业而言不多,但是平均算下来也不少。要知道,例如 Moleskine 这样品质的记事本市场价都是满百以上,而想要达到和它一样品质的笔记本去除品牌的溢价,小几十也肯定是需要的。

闭月姑娘创业的第一张牌打得就让人很惊奇。

抛开情怀,我粗略考虑了下这称之为 iBetterMe 的项目

那一千本记事本送给用户,其实都知道是培养种子用户。这一千本记事本的种子用户,目标和共性都很明确,就是他们都想有个六十天的目标计划改变下自身。

有用户必定就会有产品,目前闭月的「产品」只是本薄薄的记事本。按照我个人的理解,我倾向于将她的应用和 EverNote 这类产品作为类比。

作为记事和效率类的应用从目前的技术上讲,便利性、体验以及成本上说移动设备还是无法和传统的纸质记事本相媲美。这也是 EverNote 后面和 Moleskine 合作推出实体的纸质记事本的原因 -- 想抹平这块体验上带来的鸿沟,以及覆盖部分非智能设备用户(然而 EverNote 并没有成功,这是后话)。

iBetterMe 采用的覆盖用户的路线却是独具构思。先发行纸质的记事本,这在一方面可以从功能单一的角度上以实体效率工具出发,让用户「看得见、摸得着」;同时,在另一面也可以避免直接推出一款同质应用和目前已经红海的移动市场竞争。

要知道,目前移动这块目前的竞争已经到达了饱和的阶段,目前市场缺的不是技术是想法。

有任何有价值的想法在没有完全形成生态之前贸然推出,要么就犹如块石子扔到了大海中连涟漪都不会有,要么就是直接被更强的竞争对手 copy 连还手的机会都没有。所以,在此之前使用这样的策略起步,不为是个非常稳妥的办法。

以上只是我个人对于 iBetterMe 的猜测,考虑到闭月的爱人是 iOS 程序员,所以推出移动端是迟早的事情(笑),到时候再来评论也不迟。

目前,这个项目状态从官网的简陋上看得出还只是起步阶段,毕竟目前只有闭月和她的爱人两个人在维持。好的团队当人需要磨合,而目前再没有比夫妻档更有默契的了(继续笑)。

从一六年一月份开始,闭月团队除了继续培养种子用户,还开始了对外的招聘计划。从零开始组建一个团队不容易,我想如果你对这个团队和项目有任何的想法和建议的话,他们会很乐意听的。

总之,退一步讲 iBetterMe 这个项目不管成不成,它是闭月初次创业的一次难得的经历。这份经历于以后这个项目是否能够继续,都会将会是难得的财富。

- eof -

我的照片

嗨!我叫「明城」,八零后、技术男、伪苹果粉、微软无脑黑、宁波佬,现居杭州。

除了我的博客,同时也欢迎您访问我的 GitHubTwitterInstagram 主页。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 其实无所谓叫什么名字,因为我曾经为这个名字伤透了脑筋。最后想到的这个名字都没啥特别的,说到 底是因为我实在给它不了个非常酷的名字。

如果您想联系我,可以发我邮件 echo bWluZ2NoZW5nQG91dGxvb2suY29tCg== | base64 -d

文章

项目

微信公众号