去除人人影视广告
我平时都是在 人人影视 看电影。最近人人影视除了一个客户端，可以看电影，还可以自动下载收藏的电影，感觉还是挺不错的。
但是最近这个客户端开始加入了广告。于是我就想着如何可以去除这些广告。
首先我用抓包广告抓取改软件发的请求，发现是通过 http://ctrl.zmzapi.net/app/ads 这个地址获取的广告信息。
iOS微信重磅更新，迎来了「微信小游戏」
赶着圣诞节的结束，微信迎来了新版本 v6.6.1 的更新。
- 主界面新增任务栏，下拉可以找到用过的小程序
- 小程序菜单升级，并支持小程序快捷切换
- 小程序支持新类目 - 小游戏
在完成本次更新后，将直接跳到了跳一跳的游戏界面。
阿里巴巴全链路设计
「服务设计」应该是很早就有的一个概念，主要是区别于单一的、有形的产品设计，也就是对「服务」的设计。而「服务」与「产品」有着很大的区别，尤其是对于传统的硬件产品，它不是一个具体的一个物件，而是在一系列流程中给消费者带来的体验。因此，在我看来，「服务设计」更多是一个相对概念。
到后来，大家经营的理念变了，发现有时候只做好产品还不足以赢得竞争，于是把产品以外的体验环节也进行了关注和优化。从这个层面而言，某个具象的产品设计成为了服务设计中的一个环节。
什么是「全链路设计」？我觉得这个词应该不是一个舶来品或正式词汇，更多是提出者个人或所处小圈子中交流所使用到的一个指代词。其实从 UCAN 2017 回顾！阿里资深总监杨光：聊聊消费升级下的设计变化 可以看出，这个词完全可以用「全流程设计」来替代，只是「全链路」听起来更高端和跨界一些。
这种终端的升级带动着体验升级。用户在生活中进行任务的时候会涉及到大量的数据，会和互联网产生连接。任务更加复杂。淘宝中的淘鲜达业务是一个网上超市，一小时之内可以送达蔬菜、水果等商品。这个产品的用户体验问题就不仅限于页面。如果一小时送不到，就没有解决它的时效性问题。设计师把整个链路剖开之后，在每个链路里都做了优化，包括商家接单语音的提示，包括 POS 机打印小票的重新设计。全链路的每个终端都做了优化设计之后，将原来的妥投率（一小时内投递给用户的成功率）从 49% 提升到 94%。设计师要全链路的考虑问题，考虑整个产品的生命周期，而不仅仅是考虑产品之中一个环节。体验是一个过程，设计师要跳出界面去考虑一个完整的服务。在今天，用户购买的不仅仅是一件商品，而是整个体验的过程。
其实从上面这段话不难看出，「全链路设计」这个概念本身就是基于「海鲜达」这样一个服务来提出的，而非基于具体的一个硬件或软件产品提出。正如前面所说，在这个案例里，软件的「产品设计」只是「海鲜达」这个服务设计中的一个环节。而由于这个服务又是由互联网的从业者打造的，因此没有理清楚概念，把「服务设计」当成是「产品设计」的子集了，而非原来的「产品设计」是「服务设计」的子集。所以，我的理解是这里存在概念的混淆。如果要把「UI 设计师」或「交互设计师」来和所谓的「全链路设计师」来比较，显然是不合理的。这里的「全链路设计师」更加像是设计咨询公司的角色，而非一个特定的工种。事实上，尽管国际知名设计咨询公司也不乏一些跨界的设计人才，能够参与到众多行业的服务或产品设计中，但如果真要把「全链路设计师」当成一个工种来说，那这个角色更加像是产品总监或设计总监。他需要关注的更多是项目的整体和重点，而非对每个细节都面面俱到，以及亲力亲为。
让PWA支持HEXO
先说一下说明是 PWA，
PWA(Progressive Web Apps) 是 Google 提出的用前沿的 Web 技术为网页提供 App 般使用体验的一系列方案。
PWA 本质上是 Web App，借助一些新技术也具备了 Native App 的一些特性，兼具 Web App 和 Native App 的优点。
PWA 的主要特点包括下面三点：
- 可靠 - 即使在不稳定的网络环境下，也能瞬间加载并展现
- 体验 - 快速响应，并且有平滑的动画响应用户的操作
- 粘性 - 像设备上的原生应用，具有沉浸式的用户体验，用户可以添加到桌面
阿里巴巴的日志采集分享（下）
曝光日志，是电商场景下很特殊的一类日志，具体来说：比如商品图墙列表上有多少商品给用户展示过就是一种典型的曝光日志，一般用来作为推荐算法的输入信息或者广告展示计费用途。曝光日志一般是点击日志的几十到几百倍，而一页内的曝光信息又大致雷同，所以一般都会做聚合。
只是如何聚合，由客户端采集框架聚合还是由业务自身聚合（比如曝光日志设计为一条可以直接记录一批商品），这会是需要权衡考虑的。
用户回退行为的识别，也是比较棘手的，因为跟踪用户浏览行为的目的，主要是为了分析链路转化率，用来优化业务或分析活动效果等。而页面回退行为对这些行为分析是一种干扰。在下游数据分析过程中再识别这种行为往往很难，在采集端会有更充分的信息进行识别。但具体实现也并不是总能万无一失，而且有些特殊情况下，可能还需要保留这种回退行为的数据。
H5 和 native 日志统一：H5 日志通过 JS 接口传给 Native 的方法，转换成 native 的格式统一输出
H5 越来越流行，Hybrid 的应用越来越普及，用户并不关心你的页面是 native 的还是 H5 的，但是日志的采集方案在 Web 端和 Native 端通常却是两套架构，后续采集传输流程等等很可能也不在一条链路上。如果不加处理，对于用户行为的链路分析会带来很大的麻烦。
阿里巴巴的日志采集分享（上）
要说日志采集的难度是不高，但是要说复杂程度，绝对是很繁琐的。有许多细节和流程需要考虑，不同的客户端如何采集，格式怎么统一，各种用户行为怎么跟踪，如何减少对业务代码的侵入，怎么保证性能和实时性等等。
闭环：无规范不分析，无分析不采集；采集必计算，计算必分析；
自下而上是「数据采集规范」，「数据采集」，「数据解析」，「日志数据域」，「流量分析平台」。
在数据采集前，先定义了采集规范如SPM(超级位置模块)，SCM（超级内容模块），黄金令箭（交互采集模块），采集规则统一等。
数据采集的支持平台有埋点申请，埋点配置，埋点验证，数据监控，数据管理。（这个就是埋码的流程。）数据采集技术包括 Apus/Etag（WEB 产品采集），Beacon（WEB 嗅探），UserTrack（APP 产品采集）等。
浅析APP设计：掌握市场截图设计原则
其实，应用市场图相关文章之前就有写，一直没有整合。最近在进行新版本设计，在新版本设计中，分析的竞品与优秀应用的市场图多达 40 余款，从中发现问题并得到解决方案，一同记录下来，分享给大家。
文章开始我们来说说应用市场图的名称，它即被叫作市场图、应用市场图，也有被称为应用截图、上架图等。所以当大家听到这几个名词时，就可以知道说的是什么了。
移动端应用市场无非就是安卓与 iOS 系统之间的区分。iOS 中 APP STORE 的应用规范比较一致，适配便捷，而安卓的应用市场就比较多。
详情请看本人整理的最新应用市场设计平台规范
＊需强调 Google Play 除了市场图之外，另外还有一张 Banner 图。*
应用市场存在的目的，是方便与驱使用户下载应用的行为。那么市场图存在的意义，就是帮助用户更好地了解产品属性、产品定位和产品的功能。
畅想 AR 的应用场景
随着增强现实（AR）应用和硬件在科技行业的流行，我们有必要使用Scott Jenson的价值>痛苦理论讨论一下 AR。AR 对生活的提升是否超过为了使用它带来的痛苦。也就是说，它是否足够的引人注目，可以成为日常必需品。
为了回答这个问题，我绘制几幅关于「什么会增强现实」的插图。对于每个插图，我假设可以使用语音和注视路径/眼睛跟踪识别对象。由于这些假设，我在设计插图的时候尝试在日常生活中给出最直观的展示。
总之，我的目标就是字面意义上的「增加」。就是更强人们在生活工作中接收到信息。以下是我的十个插图。
RBAC权限管理模型
站在巨人的肩膀上我们可以看得更远，而不是再造一个轮子。
我们在做任何一款产品的时候，或多或少都会涉及到用户和权限的问题。譬如，做企业类软件，不同部门、不同职位的人的权限是不同的；做论坛类产品的时候，版主和访客权限也是不一样的；再例如一款产品的收费用户和免费用户权限也是迥然不同的。
但在设计产品的用户和权限的关系的时候，很多产品经理可能按照感觉来，在并不清楚用户和权限是否存在优秀的理论模型的时候，就按照自我推理搭建了产品的用户和权限模型。而这种基于感觉和推理的模型肯定是有诸多问题的，譬如写死了关系导致权限不够灵活、考虑不周导致权限覆盖能力弱等等。
正如牛顿所言，站在巨人的肩膀上才能看的更远。我们不妨去参照已有的比较成熟的权限模型，如：RBAC（Role-Based Access Control）——基于角色的访问控制。我搜集了网上很多关于 RBAC 的资料，大多与如何用数据表实现 RBCA 相关，并不容易理解。所以，我会以产品经理的角度去解析 RBAC 模型，并分别举例如何运用这套已得到验证的成熟模型。