跟随,学习,进步

Understanding How Envoy Sidecar Intercept and Route Traffic in Istio Service Mesh

2018-12-27 10:01:22 Jimmy Song

This article uses Istio’s official bookinfo example to explain how Envoy performs routing forwarding after the traffic entering the Pod and forwarded to Envoy sidecar by iptables, detailing the inbound and outbound processing. For a detailed analysis of traffic interception, see Understanding Envoy Sidecar Proxy Injection and Traffic Interception in Istio Service Mesh . NOTE: This blog is mostly translated with Google Translate, you can forward to read the original


理解 Istio Service Mesh 中 Envoy Sidecar 代理的路由转发

2018-12-26 18:32:27 Jimmy Song

本文以 Istio 官方的 bookinfo 示例来讲解在进入 Pod 的流量被 iptables 转交给 Envoy sidecar 后,Envoy 是如何做路由转发的,详述了 Inbound 和 Outbound 处理过程。关于流量拦截的详细分析请参考理


HTML5 Audio的兼容性问题和优化

2018-12-26 06:53:00 甄玉磊

作者:刘新金 引入 本人在双十一期间,做的一个移动端互动项目中,遇到一个在 App 、微信、h5页面环境切换选择音频播放的功能,在测试的时候出了不少兼容性问题,这里有很多值得探索的知识,今天我们就来看一下这个 HTML5-Audio。 Audio 标签用于定义声音,比如音乐或其他音频流,HTML5 的 Audio 标签在很大程度上取代了 Flash 来播放音乐。 一、默认样式 Audio 标签在浏览器中的默认样式如下图所示,需要注意的一个地方:需要配置 controls 属性(是否显示默认控制条,是 Audio 标签的控制属性),否则不展示样式效果。 二、Audio 支持的音频文件格式 1、OGG: OGG 是一种新的音频压缩格式,类似于 MP3 等的音乐格式。OGG 是完全免费、开放和没有专利限制的。OGG 文件格式可以不断地进行大小和音质的改良,而不影响旧有的编码器或播放器。 2、MP3: MP3 是一种音频压缩技术,其全称是 MovingPictureExpertsGroupAudioLayerIII(动态影像专家压缩标准音频层面3),简称为 MP3 。它被设计用来大幅度地降低音频数据量。将音乐以 1:10 甚至 1:12 压缩成容量较小的文件,而对于大多数用户来说重放的音质与最初的不压缩音频相比没有明显的下降。 3、WAV: WAV 是微软公司开发的一种声音文件格式,它用于保存 Windows 平台的音频信息资源,被 Windows 平台及其应用程序所广泛支持,标准格式化的 WAV 文件和 CD 格式一样,因此在声音文件质量和 CD 相差无几。 三、兼容性问题 我们来从下面几个角度看兼容性问题: 1、音频格式的兼容性 […]

tags: 前端开发,web前端


一个表情引发的思考

2018-12-26 06:43:15 甄玉磊

作者:石文帅 简介:字符集的由来是什么?各种字符编码又有什么关系?乱码是如何出现的?带着这些问题,我们一起倾听字符的故事。 前几天测试给提了个 bug ,“在长度限定的文本区域,输入表情时会展示乱码”。不由的产生了一些想法:这些表情是什么东西?为什么会出现乱码? JS 是使用哪种编码方式?便查阅了相关文献,最终找到了答案,今天就详细说一说编码的故事。 一、比特、字符、字节 在聊编码之前,有几个基础的概念需要先明确一下: 比特位:比特位即 Bit ,是计算机最小的存储单位。以 0 或 1 来表示比特位的值。也是网络信息传输的基本单位。 字节:8 个比特位表示一个字节。 字符:字符是可使用多种不同字符方案或代码页来表示的抽象实体。 我们知道,在计算机内部,所有的信息最终都表示为一个二进制的序列。每一个二进制位(bit)有 0 和 1 两种状态,因此八个二进制位就可以组合出 256 种状态,这被称为一个字节( byte )。也就是说,一个字节一共可以用来表示 256 种不同的状态或者符号。如果我们制作一张对应表格,对于每一个 8 位二进制序列,都对应唯一的一个符号。每一个状态对应一个符号,就是 256 个符号,从 0000000 到 11111111 。 二、东方的故事 上个世纪 60 年代,美国制定了一套字符编码,对英语字符与二进制位之间的关系,做了统一规定。这被称为 ASCII 码,一直沿用至今。 后来我们天朝也会用电脑了,但是汉字没办法表示,所以勤劳智慧的中国人民融合了 ASCII 中的数字、标点、字母,还把数字符号、罗马希腊字母与 7000 多个简体汉字整合进去,产生了 GB2312 , GB2312 是对 ASCII 的中文拓展。后来又发现中华文化实在是博大精深,汉字太多,原来的编码不太够用,因此再做拓展,此拓展方案叫做 […]

tags: 前端开发


那2018年就这样了

2018-12-25 15:23:48 Yisaer

引言等风来不如追风去,追逐的过程就是人生的意义。正文距离上一次写博客已经是10月下旬了,本来想着至少保持着每个月至少一更的频率。结果这次硬是拖到了年底才开始动笔写这篇博客,好在从来没有人对我的博客催更,于是这次就打算水一篇自己的2018年的年度总结。姑且写,也姑且看。今年十月份的时候,收到了公司的一周年纪念品,感觉挺开心的。收到的时候我自己也挺诧异的,不知不觉的就在酷家乐工作了已经一年多。回顾这一年,我觉得两个字就是幸运,四个字就是比较幸运。我是一个不大喜欢闲着的人,所以在决定好校招offer以后,我过了十月份的国庆长假就直接去实习报道上班了。所以我对于我入职的第一天的日子10月9号记得一直比较深刻。那个时候上海的研发团队算上我才总共5个人,我参与了一个几何算法图形库的基础组件库的开发和维护。虽然我以前从来没怎么接触过计算机图形学并且一些高中的计算几何知识都忘得差不多了。不过好在大二的时候参与过一年ACM,脑子没算完全荒废掉。凭借着一点小聪明对于Mentor派发下来的任务都能比较顺利的完成。那段时间有一个我比较深刻的事情是我第一次提交merge request。那个时候研发组人少嘛,所以我的merge request就所有人都review了一遍,然后就指出了很多低级错误。让我最为深刻的就是我的那次merge request里居然忘记把调试时的控制台打印语句给删掉了。当时我看到Code Comment里面被人指出代码里不要加入控制条打印语句时简直都要羞愧到爆了。现在我经常给实习生做code review的时候,虽然我也经常会提很多意见,但说实话现在的实习生写的代码比我当实习生时写的代码好多了,也没有很傻的低级错误。诶,都是后话…年初的时候,Mentor找到我希望交给我一个计算几何的课题让我单独尝试。这个课题非常小众,而且我当时也没任何计算几何的基础。不过当时凭借着一股迷之自信,我就没怎么多想的接了下来。这个问题算是平面计算几何里面一个比较经典的问题,即Nest Algrithm。当时给我的需求是提供一个服务端执行的算法包。当我搞清楚这个问题以后我就意识到这似乎是一个单纯靠我自己无法解决的问题。好在天无绝人之路,万能的Github上面居然有这一个问题场景的算法Demo,而且效果居然惊人的好。但是最可惜的一点在于这个算法的Demo居然是Javascript写的,而我需要完成的则是一个服务端可跑的算法库。我看了看这个Demo仓库里的issue,不少都提到了希望作者提供一个服务端可以跑的算法库。或者是有人自己搞了一个计划准备做一个服务端版本的算法库,可惜到最后都不了了之了。于是我的难题瞬间就降低了一大部分,即只需要读懂他的算法然后用服务端语言改造即可。于是自从十二月份开始,我就一开始针对这件事情做封闭式开发。由于作者的算法相较传统的算法使用的是临界多边形结合遗传算法去计算排列顺序的可行性,而对于这两块我又都是零基础,所以只能边啃论文边调试代码。说到这个调试代码也是一脸泪,由于这个算法Demo全程运行在浏览器端并且用javascript完成,所以我只能通过一次又一次的打印控制台里的各项参数来明白整个算法逻辑。就这样一边啃一边调一边写,差不多到二月底的时候我的第一版服务端排版算法引擎就已经出来了。这当中经历了许许多多、日日夜夜的调试以及各类问题。比如如何在遗传算法中通过多线程并行计算来加快效率,和如何处理浮点数在进行几何计算时的精度误差等等。这些都是在一步步踩坑中,然后对很多地方再推倒重来的解决方案。最终这个服务端引擎输入了当时原作者使用的测试用例Demo,最终得出了如下的结果。后来我将这些工作成果整理过后开源了出来,同时作为我的本科毕业设计,顺利毕业了。后来七月份还是八月份的时候,李青老师电话找到希望我给这篇论文写一个短篇杂志期刊,为我争取了一个优秀毕业论文。虽然没啥用吧,但是作为我大学期间为数不多的奖项,也算是一个善始善终吧。当然后面在七月份的转正述职上,当我再次提到这个项目时,我将它评价为2018年上半年我个人最满意的作品,没有之一。在完成了上面的工作中,我就从三月份开始转去了国际站业务组开始后端业务开发之旅了。这个时候我的Mentor也换人了,实习期间的Mentor由我现在的主管@橙子担当,而技术上的指导则有杭州的@磊哥跟我远程联系。磊哥的代码写的非常棒,而且在技术上教了我非常多的工具、方法和思想。让我有一种过去Java后端白学了一样。感觉自己和他写的完全是两种语言。整个三月到五月基本上都是磊哥带着我写后端的代码,我也是慢慢从CRUD开始,然后一点点写复杂的业务逻辑。最终变成了几个服务的Owner。当我完全可以独立的负责这几个后端服务的时候,磊哥的历史任务也就完成了从我们组去了监控组开发了。四月份的时候,我抽空回了一趟母校,然后在开源社区做了一次分享。比起那时候我大三的时候办开源社区分享活动,今年的开源社区热闹了许多。来了不认识的学弟学妹都过来听,非常开心。五月份的时候,我开始梳理我们整个项目组的持续集成与持续交付。由于作为一个新的前台业务组,我们当时的情况是每个服务Repo自己控制部署节奏。每个服务自己在gitlab-ci上写好了各个环境的部署脚本以后,Owner负责部署到内网环境,然后在某个特定的时间点由主管将所有服务部署到生产环境。当时我正好接触到了Istio体系中的Service Graph。那个时候我们的业务调用关系还比较简单,可以看做是一个简单的拓扑图结构。当时我看到这个图的第一想法是这个服务间调用的拓扑图不也正代表了部署的部署顺序吗?如果有一个总控制台去每个服务的部署节奏,让每个服务部署时必须要所有先制服务部署完才能部署那该多好。于是凭借这个想法,我通过Gitlab-CI的API,单独完成了我们组的级联部署系统的第一版雏形。整个六月份,我都在忙于挤毕业论文和处理毕业的各种手续,终于在7月初的时候正式毕业了。同时,我们组也开始紧锣密鼓的筹备校招和实习的事项了。当时来上大做校招的宣讲会之前,由于之前在大摩实习的时候碰到了不少大一大二甚至高中生的实习生。让我意识到其实实习这件事没必要从大三才开始找,所以我特地也去了大一和大二的年级群里做了实习的宣传。最终竟然成功招到了一名大二的学妹来我们这里做前端实习生。另外一方面,因为我一直坚持每个学期都来开源社区做一次分享,我觉得促进我们组来开源社区做技术宣讲的同时吸引更多的学弟学妹们来我们这里实习是一件两全其美的事情。在七月份九月份的时候我分别带了我们后端和前端的负责人都带到开源社区做了一次分享。在工作上,从六月份开始我开始接触我们的组基础设施平台,Kubernetes与Istio。由于我们的组的所有服务都运行在Kubernetes,而我一开始对这个又毫无概念。所以光是了解Kubernetes我就看了不少的资料和文档,边看官网Demo边尝试性的在内网进行一些简单的操作,才一点一点看明白了K8S的整体架构和如何使用。在我们的文档系统里面,有两个目录专门用来记录我们在Kubernetes与istio上的最佳实践和踩坑经历。现在看下来这些文档我自己一个人这半年来总共块贡献了有三四十篇文档了。从刚开始被K8S一上来大量的概念而感到力不从心,到后面内网或者生产环境出现BUG时自己都跟在大佬后面看他们是怎么解决问题的。到后来出现问题时自己也能慢慢的独立解决。整个六七月份我的工作重心一直铺在国际站的基础设施建设上。慢慢的对K8S和Istio的使用越来越得心应手,我也顺其自然的被大家放心去管理建设整个项目的基础设施与负责生产环境的稳定性。 在那段时间我个人总结了一些管理和运维经验在博客上。从七月份开始,我成为一个正式员工时,也成为了一个带实习生的mentor。对于带实习生这件事情,我是比较乐意的。因为我个人是一个乐于分享的人,有一个实习生能天天主动或被动的接受我的叨叨我还挺开心的。和实习生合作了三个月不到,从七月份成为mentor到九月份送走实习生回学校。当中的过程总体来说比较开心,但是作为Mentor,我事后回想过后给自己打分大概就是一个及格分。从我开始带实习生起,我给我们俩定位就在于我和实习生一起去完成我工作中的指标。所以为了保证工作能够顺利完成,我会将这些工作拆分成一些比较简单机械的任务交给实习生,然后将一些比较有难度或者比较有风险的事情交给我自己做。另外一方面,为了让工作能更快完成,某些比较困难的事情让实习生做可能需要花一天,我自己做的话可能就十几分钟就搞定了。于是我最终也是选择让我自己做。最终可能因为干的事情大多数都是没有挑战性,所以实习生在干完两个月暑假结束后就选择离开了。前段时间我和我主管One on One的时候,我谈论到了这件事情反思到对自己当时的决策比较后悔。我的主管告诉我其实交给实习生干一些有难度的活或者有些事我做的比较快,实习生做比较慢,但让他去做一样没有问题。只要我们能将任务的风险控制在一个可控的范围内,完全可以不追求效率和成本让团队内的其他人去做一些有难度和深度的事情。这样对于整个团队的成长是最有利的。九月份的时候,我邀请了我们前端的负责人@影魔来到了上大开源社区来做技术分享。影魔大佬的技术分享说实话我个人认为是我2018年听到的最好的一场分享。在他的分享当中,他特意谈到了他从阿里干了9年以后出来加入我们团队有很大一部分原因就是想要去体验和整个团队共存亡的感觉。这个话给我的感触很深,让我意识到即使是为了我自己,也要开始考虑从如何更快的提升自己转变为如何更快的提升整个团队的战斗力。我觉得这句话是我目前为止从九月份以后加班越来越厉害的罪魁祸首。我会开始主动思考我们的后端服务架构是否合理,我们的部署节奏是否能够灵活支撑频繁的服务更新迭代。当我们业务的服务越来越多,临时用的小工具越来越碎,同时每个Sprint的Story Point越来越多,以及加入了很多新的同事以后。我开始意识到我们业务组从以前的通过某个临时的工具去解决问题的情况需要转变为一个完整的内部管理体系去统一协调。10月份和11月份的时候分别参与了今年的QCon和KubeCon。QCon这个会议以前还在大学里的时候就已经听说过了,但是一直是以学生的视角走马观花的一样看了几场分享的资料。但是看完听完就完了,并没有留下啥感触。今年参加的这两场分享,第一次以一个已经工作的人视角去参加,这两场会议我都是直接直奔了Kubernetes与Service Mesh相关的主题会议。QCon参加了第一天,我之前也写了自己在QCon上的参会感受。如果说在QCon上的ServiceMesh产品主角是蚂蚁的SOFA,那么毫无疑问在KubeCon上的ServiceMesh的当家主角则是G家的Istio。可以看得出来,今年整个Kubernetes话题上,大家都对新出来的ServiceMesh概念非常关注,尤其是Google主打的Istio。但同样也有阿里和华为在KubeCon上推荐自家的ServiceMesh产品,这些更多针对的可能是国内用户。值得一提的是,这一年的KubeCon上也有不少公司分享了自己在Istio使用上的探索和经验,以惠普为首。这让我感受到了单兵作战和小组作战的效率差距。不过让我感到遗憾的是,大部分公司仅仅是用了Istio,但并没有说按照Istio提供的工作来真正在生产环境上实现一些互联网的常见需求,这一点我有了一种我上我也行的感(错)觉,不过未来的目标之一确实是希望自己也能作为主讲人参加这种会议吧。这个十月份同样还参与了ServiceMesher组织,并成功给ServiceMesh投稿Coohom在生产环境中使用Istio的经验和实践。有意思的是,通过这篇文章,我有幸被一些HR和出版社编辑认识,前者经常说要我找过去聊聊,后者则是鼓励我把这些经验时间总结成一本书来出版。 关于出书这个事情我一直在考虑,一方面非常开心有出版社找我写这方面内容,而且serviceMesh这块作为一个比较初期且前景比较明朗的领域的确是越早越好。另外一方面,工作上比较忙,而且说实话我对自己在这一块的深耕也并不自信,觉得自己学到的也只不过是些皮毛,只是起步应用的比较早而已。但是纠结归纠结,明年应该会开始构思在这方面的内容与方向吧,希望自己能做到。最后是一些工作上的感悟,以前总是觉得一个牛逼的程序员/工程师应该要有自己的拿手绝活,这样才能提高自己的核心竞争力。来到国际站项目组将近10个月以来,从项目刚开始定下到现在已经在北美打出SAAS的市场,经历了一轮又一轮商业模式与目标客户的探索,数据运营与服务治理的搭建,以及敏捷流程与团队成长的建设。我感受到的是,在互联网模式,尤其是作为最前台的业务组,一定要不能将自己局限在某个领域里面,而是需要了解业务和团队从发芽到开花方方面面的思维和工具,不停的消除瓶颈与优化效率。以前的自己有一种程序员的定性思维,总是觉得各种工具或者服务要自己写和自己实现那才是最牛逼的,但其实这些工具明明在开源软件里就有成熟的工具和解决方案却不愿意去用。技术是要为产品服务的,而产品的最终目的就是利益,所以为了产品成功,工程师就应该首先要抛开技本位的思想,从ROI的角度考虑每一个决策,多用不同的思维和视角去看待产品和业务。(可以理解为互联网版的给钱什么都做)以前在知乎上看到一个关于职场成长的金句,原文我记不大清了,原意是在职场发展中,在技术上成为一个高手固然厉害,但是更厉害的则是可以带出一个都是高手的团队。现在一想,在职场上跟对leader很重要,好的leader会为了团队成长而培养每一个人,最终形成一个有战斗力的团队,那么在业务上的成功也是迟早的。很开心这一年能在国际站团队学到这些。下一次上班又是新的一年,新的工作内容。


社交传播新范式小群效应设计-实例分析“淘宝合伙人&京东好玩节Ⅰ”

2018-12-25 09:52:44 zhang xiaoxi

前言 随着人口增长放缓、营销成本增加及资本回归理性,互联网开始进入下半场。社交营销进入窄众时代,分享给微信好友和小圈子、小群,已然成为目前用户下意识的动作,用户开始意识到从特定的专属小群中获得特定的帮助,我们把这种现象称做社交营销新范式——小群/小圈子效应。 今年2月我们在京东好玩节Ⅰ中首次尝试了小群效应传播裂变玩法,在电商流量低迷的年货期间,我们迎来了年前流量小高峰(超5亿人次参与)。随后,淘宝双十一合伙人互动也再次印证这种新范式的高效裂变效率。这两个不同平台的大型社交营销玩法都准确地获取了95后年轻爱玩用户乐于关注新奇特、偏好群聚行为的特性;并且利用5人组建战队协同完成游戏任务,战队排名赢大奖的最终利益引导用户多对多地高效传播扩散。 新范式是针对特定群体,将人与人运用有效的方式进行连接,实现多对多的快速扩散与传播,以获得有效的传播效果及价值。这也是社交营销玩法的第六种传播模式。(摘自《解构社交电商营销生态——社交玩法策划与设计精髓》欧阳蓓) 案例回顾 好玩节互动规则:首页好玩创想国度根据用户偏好划分共有7大分场景,用户进入国度后可以单人参与互动,积累好玩值兑换京豆;或者与场景内其他同好用户组成5人战队累加好玩值,取得排名前几可以获得噱头实物大奖。 合伙人互动规则:用户个人通过做日常任务/签到等行为获得能量,能量可以兑换红包;与好友组成战队后,可以分享给其他用户为战队拉点赞,每天晚上两队PK时集赞最多的一个队可以得到并瓜分能量,再进入下一场次的PK,最终能量排名前几的战队可得清空购物车大奖。 1.新范式下的五大设计环节 就此,笔者从这两个经典案例入手,归纳出小群效应模式下5个核心关键设计环节,希望在往后的项目中可以有迹可循,更多思考在前,理性科学地完成项目: 设计开始的第一个环节是设定角色,即明确目标用户群体间的一个关系,是竞争还是协作,这有助于我们确定互动的主题基调。 第二个环节是任务设计,设计我们的主体内容是什么,在有组织的任务梯度下满足普通用户和精尖用户的行为动力,促使更广的用户群体能够活跃起来。 第三个环节是通过激励体系梳理整个活动的脉络,串联组织起主任务以及支线链路,完成闭环。 第四个环节是以奖赏投入的角度再去评估互动中的设计点,明确互动中酬赏和投入设计点是否成正比,是否可以在短期和长期中心力的作用下形成有增有减的良性闭环。 在设计最后,尝试利用一些可舆论的话题传播点带来群聚效应的传播增量,使其效应价值最大化。 后文也将在此思路下,从多个互动设计维度详细跟大家聊一聊两者案例中值得学习的设计亮点以及探索归纳小群效应的设计思路共性。(后文中这两个案例将简称为“好玩节”、“合伙人”。) 2.多维度设计分析 2.1用户群体定位&高效扩散 首先,在年轻爱玩特征的95后用户定位下,两者互动考虑了不同的目标群体划分维度:好玩节是以兴趣标签划分不同用户,意在使相同爱好用户凑堆,形成了社群中常用到的“同好群体”,他们之间再为争夺排行榜而游戏PK。奖品也是根据该群体爱好精心设计,比如吃不胖国人的排行大奖是争夺一年的零食大礼包,符合用户兴趣标签。而合伙人是以用户游戏能力为维度,匹配相似游戏能力的战队PK竞争,促进了游戏的参与性。 在两者互动传播机制上,用户可以邀请强关系好友组建战队,并为完成游戏目标(拉赞或获得游戏机会等)分享到更多弱关系微信群、朋友圈中,这就体现出了群体作战模式下多对多地弱关系分享裂变的优势,可触达并激活到更多年轻爱玩用户群体,完成高效扩散。因此也既定了两者互动中95后群聚群体“强关系协同,弱关系竞争”的互动关系。 2.2群体关系下的功能亮点 在此设定下,以下功能亮点更助力将“强关系协同、弱关系竞争”最大化体现:好玩节的设计亮点在于团队内聊天互动的多样形式,增添了社交的趣味性,比如给队友送鲜花、丢拖鞋,一起答题了解队友找到话题等;合伙人值得学习的点在于战队间可以改队名交流玩策略,也正因为互动中清晰地竖立了敌和友角色,使得两种用户关系各有话题感,增强了群体社交互动的效果。 2.3任务进阶设计 任务设计是建立在用户群体角色和业务目的两者上,进行具体用户行为内容填充。合伙人有一个明显的优势是,着手从双维度出发(任务难度和完成时间维度),设计了三个任务的阶梯,使得任务由易到难覆盖了更广的用户范围。这使得不同游戏能力的用户,我们常说的普通用户和精尖用户,都提升了行为动机和参与感。 2.4建立虚拟货币 为引导用户在互动中完成多任务,虚拟货币设计有助于串联分散环节,形成互动内闭环生态。典型的电商营销活动中,货币是奖励手段的中间媒介,通常用作用户完成任务的阶段性奖励,其目的是激励用户积攒到一定程度后用来兑换实物奖品、优惠券等终极利益奖励。常用的货币体系,包括了赚取、消耗和兑换三个环节,如下图所示完成闭环,最终输出到兑换环节。这两者案例中,好玩节的货币是好玩值,合伙人是能量;同样也是引导用户完成任务赚取货币,以最终累计的货币去兑换奖励。 2.5激励体系设计 基于虚拟货币的建立,很多游戏设计惯用体系化的激励手段来增加用户的回访次数和使用黏性。激励体系(如下图所示),首先是由用户自主产生兴趣作为外围力,再由基础、蓄力、中心力、获得、释放等环节共同完成内循环。这里举例合伙人,也是通过获取基础的货币蓄力能量,再进入下一PK释放前期的能量,最终PK结果会使得能量再次获得或消耗。这里第一个学习点是它的体系中存在两处释放前期蓄力的环节,使得货币有增有减以刺激用户不断参与,产生博弈心理。再者,用户在激励体系中最终的原动力是短期中心力和长期中心力,起到了一个我们人体心脏的作用。所以其重点值得学习的是,合伙人设计了短期中心力能量兑换红包,和长期中心力清空购物车,那么在双重中心力的作用下,更大范围地满足了普通用户和精尖用户的利益心,同时也避免了单一长期目标因期间历经太长,使用户记忆点不足失去黏性的问题。 2.6设计亮点&心理模型运用 成功的案例都巧妙的运用到了一些用户心理模型,它们将帮助设计师在评估互动时,对设计策略有客观专业地分析,明确地了解互动对用户的吸引点在什么地方。下面就将具体说下合伙人案例运用到的几种用户心理。 2.6.1 第一个是利用用户害怕失去既得利益,以及从众参与的心理,使得互动回访和持续参与性强。合伙人在互动设计上利用有得有失的利益浮动,使用户总是感到不甘心的,此处正是利用了“游戏八角分析法”中的黑帽理论激发用户斗志。另一个点是设定短期目标,使用户能短期内回访;若目标期限历经太长,会使得用户记忆点不足,失去对互动的热情。 2.6.2 再者是利用了目标接近心理,使用户PK目标明确且感到易触及。合伙人在设计中自动匹配战队PK,减少用户的选择成本,缩短了进入游戏的路径;且根据以往表现,从人数、社交关系能力等几个维度考察,智能匹配实力相当的两个战队PK,使得参与者感知目标易挑战且动力足。从中我们清晰了解到,对战设计中需要给用户明确的目标竞争对手,若范围太广容易导致目标不明确反而失去动力的问题;更易触及的目标诱惑使得用户更有动机完成任务,挑战太大反而容易产生挫败感。 2.6.3 第三是通过用户博弈心理、集体荣誉感、从众参与心理使得互动活跃度高、用户黏性强。从笔者的小样本调研反馈来看,熟人组成的战队因存在社交成本,参与质量更高,且更易使得用户考虑自己的社交关系而产生集体荣誉感。 2.6.4 最后一点是调动了用户的创造娱乐性生产大量UGC内容,为互动带来了额外的无穷互动乐趣。合伙人通过修改战队昵称的方式自我创作内容,比如“平局就好”、“求平局心好累”,表达游戏娱乐态度或者叫嚣对手,互动话题感很足,网友又转战微博晒图形成舆论话题。后期可以再思考,如何利用我国网民娱乐性强的特点,发挥精尖用户的娱乐性产生增量价值。 2.7用户酬赏与投入设计 在介绍这部分之前,先简单提一下反复被设计师用到的经典行为转化模型,酬赏与投入设计也正是运用了这个原理:促进用户发生行为的策略是,增加动机,减少成本并制造转化因素。这也就是说在互动设计中,当用户的酬赏和投入成正比时,用户才有持续行动的动力。 2.7.1 酬赏设计使用户产生行为动机,并可给予多变的正向反馈。合伙人主要包括三个方面:自我酬赏,使用户获得愉悦感和荣誉感;猎物酬赏,对个人和集体利益的满足;社交酬赏,在团队互动及贡献过程中被价值认同和喜爱的渴望。 2.7.2 投入设计中,使用户付出与其能力匹配的投入可以增强用户参与性。对用户已耗费精力产生的赞数,用户不愿意轻易放弃使前期努力白费,这里投入适当成本进入下一场次,可使自己的利益变大,渐进的目标使用户更愿意投入;用户自动进入下一关消耗货币会使用户因离开而损失成本,激发用户继续参与其中;为用户匹配实力相当的战队,使用户认为能力成本不高,愿意再尝试。 3.最后的话 以上是笔者在两个经典案例中对新范式小群效应的一些思考和归纳,希望可以给大家带来一些新的设计思路~好玩节是我们在小群效应模式下的第一个尝试,后续也将继续探索该模式下的其他新互动玩法,欢迎大家一起交流探讨~

tags: 交互设计


详解 Kubernetes Pod 的实现原理

2018-12-25 08:00:00 Draveness

Pod、Service、Volume 和 Namespace 是 Kubernetes 集群中四大基本对象,它们能够表示系统中部署的应用、工作负载、网络和磁盘资源,共同定义了集群的状态。Kubernetes 中很多其他的资源其实只对这些基本的对象进行了组合。


实战契约测试

2018-12-24 19:17:21 李强

消费者驱动契约测试对于API或微服务开发非常重要,它解耦了API提供者和消费者间的开发与测试过程

tags: 软件工程,测试


循环引用导致的undefined问题

2018-12-21 11:14:26 一只好奇的茂

问题描述 两个JS文件存在循环import时,将导致undefined问题 原因分析 如下两个js,假定先加载a.js: 结果是 这里有一个有趣...


ReactNative-页面性能优化

2018-12-21 11:08:28 一只好奇的茂

生产环境下日志输出禁用: 接入babel-plugin-transform-remove-consolenpm install babel-pl...


ReactNative - FlexGrow和FlexShrink布局

2018-12-21 10:49:06 一只好奇的茂

FlexGrow flexGrow属性定义项目的放大比例。 默认为0,即如果存在剩余空间,也不放大。它和Android中的weight很像。 如...


ReactNative - 原理浅析

2018-12-21 10:35:52 一只好奇的茂

线程模型 RN应用中存在3个线程: UI线程:即Android中的主线程,负责绘制UI以及监听用户操作。 Native线程:负责执行C++代码,...


关于看板,您需要了解的10件事情

2018-12-20 17:36:26 过佳昱

看板是一个组织与管理专业服务工作的方法。它应用精益的概念(诸如约束在制品)来改善结果。看板系统是约束在制品、当有空余产能时提供开始新工作的信号的方法,也被称之为“拉动系统”

tags: 敏捷,看板方法


微保 [车险] 项目设计小结

2018-12-20 07:44:06 tattyshang

一、项目背景 公司一直希望在互联网金融领域有更广的拓展。在旗下的微保已经拿到了保险代销牌照的背景下,通过互联网技术和大数据挖掘,可以与保险公司开展更深度的合作,给用户提供优选的保险产品。车险在我国财产保险保费中比重最大,但目前中国的车险 ...

tags: 项目总结,保险


麦肯锡:判断你的组织是否敏捷的五大标志

2018-12-17 23:00:24 魏 振龙

本文由麦肯锡敏捷部落(McKinsey Agile Tribe)共同撰写,该部门由50多位全球顾问组成,他们汇集了数字,运营,营销和组织学科的专业知识,整合了深厚的经验和思想领导力,从麦肯锡的全球经验中汲取最佳经验,希望可以为企业转变为敏捷组织提供帮助。

tags: 软件工程


Istio中的服务和流量的抽象模型

2018-12-17 21:37:35 Jimmy Song

本文介绍了 Istio 和 Kubernetes 中的一些服务和流量的抽象模型。虽然 Istio 一开始确定的抽象模型与对接的底层平台无关,但目前来看基本绑定 Kubernetes,本文仅


慢慢的,公司内敏捷的热度就退了…..

2018-12-17 16:21:51 魏 振龙

教你三招,让敏捷不再是一阵风

tags: DevOps,敏捷


Kubecon&CloudNativeCon Seattle 2018

2018-12-16 15:47:05 Jimmy Song

北美的KubeCon&CloudNative是每年最值得参加的云原生盛会,这次在西雅图举行,为期四天,从12月10号到13号,参考大


计算机视觉入门 之初识 opencv.js

2018-12-14 06:26:55 开元

本文作为计算机视觉入门系列第一篇分享,主要介绍当下比较热门的计算机图形处理库 OpenCV。本文将从 OpenCV.js 的编译方法、基础概念、常用 Api 使用样例以及辅助实现验证码识别的简单实战四个方面入手,帮助大家快速了解并上手 OpenCV.js。 随着近些年移动设备上面部识别,AI 美颜等功能的火热,作为目前最热门的计算机图形处理库 —— openCV 开始大放异彩。 OpenCV ,全称 Open Source Computer Vision ,是一个基于 BSD 许可(意味着它可以被用于商业应用)的开源跨平台计算机视觉库,由 C 函数和 C++ 类构成,并且提供了多个语言的接口[1]。OpenCV提供了大量图像处理的功能,从图像显示,到像素操作,到目标检测等,大大简化了图形处理以及深度学习应用的开发过程。OpenCV.js 是 JavaScript 开发者与 OpenCV 计算机图形处理库之间的桥梁,起先仅仅是部分 JavaScript 开发者自行开发的 OpenCV 应用接口,其原理是借助一款 LLVM-to-Javascript 的编译器 —— Emscripten 将库底层 C++ 代码编译为可在浏览器运行的 asm.js 或者 WebAssembly ,后来该项目日趋完善,并于 2017 年并入整个 OpenCV 项目。 小贴士 WebAssembly 是一种新的编码方式,可以在现代的网络浏览器中运行. 它是一种低级的类汇编语言,具有紧凑的二进制格式,可以接近原生的性能运行,并为诸如 C/C++ 等语言提供一个编译目标,以便它们可以在 […]

tags: 前端开发


从 Kubernetes 中的对象谈起

2018-12-09 08:00:00 Draveness

上一篇文章中,我们其实介绍了 Kubernetes 的对象其实就是系统中持久化的实体,Kubernetes 用这些实体来表示集群中的状态,它们描述了集群中运行的容器化应用以及这些对象占用的资源和行为。