0 前端项目技术选型

  0x0 单页应用 & 多页应用 相关技术选型不同项目需求不同: 传统的多页网站不会用React单页应用用jQuery实现困难,需要自己处理技术细节,出错的可能性多两大类站点多页应用每个新页面都需要做页面的跳转,是通过浏览器发请求到服务端的 日常:前端拿到设计图做好模板,后端用jsp等模板引擎填充数据,拼html代码,形成真实的html给浏览器做显示 特点: 每个页面跳转都经过服务端新页面出现需要刷新浏览器用户需要有一定的等待时间js定位:js主要做动画,数据处理都是在后端做好的 后端处理好拼给浏览器例如:如点击某个按钮后,隐藏了一个div显示了另一个divjs设计初衷就是做这些小功能的,随着js标准升级,功能才变强大常用类库: jQuery:对原生的DOM事件做了封装,解决了浏览器兼容性问题 & 提供更好用的apimootools | YUI:DOM封装类库,使用方法和原生js差不多 - 多页应用时代更多的就是通过js操纵DOM常用工程架构工具: 无特定前端工具,后端配合grunt:一头豪猪,是一个命令启动器,本质上是一个注册任务的脚本处理器通过grunt执行一个config(比如指定编译的文件、编译好的东东输出到哪个目录下面)用起来比较麻烦,执行任务很慢,因为硬盘读写效率低导致的gulp:也是跑任务的工具,和grunt差不多好处是通过stream的方式处理文件,比grunt更快,API更简洁好用现在基本上已经被npm替代了常用模块化工具: 大部分情况下没有模块化工具:每个页面单独引一个jQuery,单独写几行代码就好seajs:支付宝的小伙开发的requirejs静态文件处理: 手动编译到html中,配置的时候不够灵活有的时候不处理,交给后端用Nginx机制去处理单页应用特征 - 前端路由:点到一个新页面,浏览器不需要刷新,只是页面内容刷新就可以了 三大类库:React、Vue、Angular 特点:各自有自己的开发范式对整个DOM做了上层的抽象 好处:隔离了DOM层,所以才能做服务端渲染服务端没有js的DOM api的运行环境(如:document.xxx),如何把js的DOM操作渲染成最终的html呢?通过类库抽象出来的方式去渲染前辈:backbone.js前端MVC的经典案例,整个类库的代码量很少是一个骨架,细节需要自己实现React:需要把它的代码编译成浏览器支持的代码才能运行,JSX语法浏览器并不认识Vue:和React的主要区别:Vue的数据是双向绑定的,下层可以修改上层数据。React遵循单向数据流,数据只能从上到下修改Angular:用ts开发里面有不少超前的东西目前的生态不够完整工程架构工具:npm 占据90%左右的使用量了 模块化工具: webpack:可以打包任何的静态资源文件(js、jsx、css、sass...)可以按照想要的样子做编译rollup.js:能够按需引入函数而不是把文件中的所有的函数都包含进来静态文件处理:使用webpack处理静态文件,直接在js里引静态资源就好,模块化工具会自动转换成线上可用静态资源路径 0x1 web app 架构简介以前:写好网页模板交给后端,后端填数据,把填好的html返回给浏览器 现在:webapp所有的前端页面跳转,都在浏览器中做 一次加载的内容变多数据通过api获取,在前端渲染出来大部分代码都是js代码,甚至不用写html了工程架构解放生产力通过自动化操作,保障开发目光能聚焦在业务上,而不是繁琐的文件复制、目录改变之类重复性的劳动 源码处理:需要让jsx能自动转成js、自动使用babel编译、图片路径自动处理 图片处理: 图片是一个资源,在js中应该能直接import到为什么要Import?业务代码开发目录时在src目录中,而最终是需要把「资源」编译到dist目录中,这一步其实是需要做资源拷贝的希望图片能做「浏览器长缓存」,需要控制图片的版本。我们不希望每次手动在图片后面加版本号,这一步也希望能交给工程架构去自动完成最终的图片url,后面会自动加一串hash值我们在业务代码中,直接把import进来的东东,作为资源路径即可,而不必关心dist目录中图片的hash值是多少,每次的真实路径是什么环境搭建每种框架的解决方案都不一样(jsx、ts等),需要有一个编译的过程,把不同语法类型编译成浏览器能识别的语言(es5) 预见问题:一开始,手头项目直接写css即可。但是以后会不会出现css太多类重名的问题?如果会,是否需要提前考虑解决方案还是到时再说? 质量保证通过代码规范,保证排错、可读性 code lint:用来规范代码的写法 排除环境差异:存在操作系统环境差异,需要通过工程架构避免类似问题 可以通过给编辑器放一个editconfig,处理不同环境下,代码规范问题包括定义:方法结束时,应该留一个空行、用4个空格还是一个tab之类的git commit预处理:强制自动做代码lint监测,有错就不让commit 关键点:定制每个项目和团队都是不一样的,需要通过定制,满足团队的上述需求。 需要对所使用的定制工具,了如指掌,甚至自己需要写一些webpack的脚本实现某些功能才行 项目架构工程架构更多的考虑让工程跑起来、更方便做开发(自动处理的东西之类的) 项目架构需要考虑: 网页如何运行业务代码如何分层以便做好功能预留业务扩展的空间技术选型: web app使用哪个框架?还是需要自己写?它的store选哪个?数据逻辑如何做?数据解决方案: mobxreduxflux需要考虑:后端结构是怎样的?API形式如何?http请求用什么方案?(自己写?还是怎样?)代码风格: 和代码检测不一样,这里主要考虑: 数据存储:哪些数据存在mobx中?(mobx是整个应用公用的数据管理)哪些数据存在当前react的view中?0x2 网络优化 & webpack打包网络优化方法:合并资源文件,减少http请求 说明: 浏览器并发http请求有数量限制,桌面8个,手机6个如果需要并发请求的资源太多,会延长整个页面的加载时间合并后,可以加快网页加载时间示例: 我们一个工程中,js文件很多打包出的实际页面中只有两个js文件,这就是代码打包的结果webpack根据所有的Import依赖树,做了文件合并,合并成一个js文件打包完成,会生成一个dist目录,就是合并后的文件的存放目录生成一个vendor.js文件:这个文件是压缩过的vendor:包含了所有引入的第三方类库的文件因为第三方库更新频率较低,适合长期存在浏览器缓存中,所以单独打一个js包生成一个业务代码打包后的js文件类库的css文件,使用cdn存就好 方法:利用浏览器的缓存机制 加载资源文件的时候设置过期时间,默认使用浏览器内部的本地文件,这样就可以不经过网络了缓存机制的问题:网站更新后,如果js静态资源的文件名没有更改,那么浏览器端不会更新静态资源,而使用缓存的资源需要有机制更新静态资源文件的文件名和url:缓存更新机制以前:直接加时间戳,问题是不能定位到哪个文件更新了哪个没更新,导致发布一个版本,所有静态资源都被更新现在:打包文件根据内容做计算得到hash如果内容有更新,hash就会更新如果没更新,就用缓存  

Lean Startup II 定义两个假设

  时机:用户探索阶段 定义用户痛点假设: 观察用户痛点大小决定了商业模式的空间观察用户痛点持续性决定了商业模式的持续性痛点本身会不断演化痛点具有时效性定义解决方案假设: 解决方案和用户痛点的「匹配度」能不能解决这个痛点解决方案和用户痛点的「吻合度」 产品和市场之间的吻合度0x0 用户痛点是什么Guy Kawasaki:思考不如意的事情,然后从这些点切入,寻找新的机会 SnapchatSituation痛点一:社交压力 传统社交媒体分享自己照片时的「点赞压力」「期望得到评论压力」 分享人:每一次分享都是一个对自己受欢迎程度的测试持续发消息却没回应 - 感觉自己是个Loser阅读者:迫于社交压力不得不给人点赞痛点二:隐私泄露问题 「非主流」照片,一旦发给朋友,就永远失去对照片的控制权Task「不适合公开照片」可以设置倒计时(如7秒),到期彻底消失 如果对方截屏,系统会发通知「xxx正试图截屏你的照片」,从而形成约束力UberSituation坐出租车的痛点: 打不到车 - 永远不知道下一辆车什么时候来驾驶员服务态度不好交易过程不方便司机的痛点: 老板的专职司机有大量碎片时间(老板:你7点送我过去,晚上9点来接我)Task地图叫车评分体系免密支付Result这里讲的Uber模式,就是滴滴的「专车」模式...的确是解决了上述痛点的 德康血糖仪Situation糖尿病是一种慢性病,痛点:测血糖 采样麻烦不能连续采样睡眠状态无法采样Task无痛植入采样传感器连续监测 + 云端数据同步葡萄酒:Dr.WineSituation葡萄酒选择太多,挑选过程艰辛,最终会变成「仅仅基于价格」的选择Task方案一(澳大利亚黄尾巴):用颜色标签极度简化葡萄酒信息方案二(Dr.Wine):用App扫酒标,获得这款酒的相关信息,包括历史和评论方案三(WSJY):买会员,它每季度配送12瓶不同的葡萄酒(帮用户做选择)分析:单品思维(12瓶酒)预售模式:先有用户,再集中用户倒逼供应链0x1 怎样定义用户痛点和解决方案假设错误做法: 天才人物的天才构想市场调查和焦点小组原因:市场调查主观性强烈:去听你想听的东西本质缺陷:消费者无法告诉你他们的「潜在需求或隐形需求」到底是什么方法体系工具一:头脑风暴初创小组带着强烈的同理心去进行头脑风暴,将自己代入用户角色,从而定义用户痛点和解决方案 目标:对用户形成一些「基本的认知」 场景对比工具使用「同理心」将自己代入用户观察使用场景,进行定性描述通过定性描述,定义有可能的痛点(脑爆的点)提出有可能的解决方案(脑爆的点)举例:Netflix做的场景对比 传统模式用户租DVD的场景图 VS Netflix新解决方案的场景图 头脑风暴两阶段阶段一:思维发散阶段 尽可能多的收集点子不要引入价值判断阶段二:聚焦阶段 引入价值判断做取舍头脑风暴基本规则第一大规则:推迟判断在积累大量点子之前,不要过早引入价值判断,价值判断留待最后 第二大规则:注重数量头脑风暴的关键作用:打开个人思维的局限性 工具二:参与式观察和访谈关键的一步 关键点: 不带预设,不过早引入价值判断深入挖掘和预期不符的维度不只关注用户自身体验,深入挖掘用户相关利益方体验案例:解决印度地区新生儿死亡率高问题假设问题:印度医院设备落后 假设方案:找到印度医院和潜在捐赠对象,把两者做对接,给医院更多恒温箱 Action:走访印度不同医院 Result:发现真正问题 - 农村小孩缺乏从家到医院的设备,医院有恒温箱但大量闲置 修正方案:做有基本保温功能、便于运输的睡袋,便于把孩子送到医院 工具三:从别人的失败中学习案例:ANM模式:聚焦消费类电子产品,美国设计,中国代工生产,美国销售 50%员工只做一件事:去亚马逊读各种电子产品的差评两个标准:分类排名中靠前的产品(有一定影响力、销量)有用户基础,但是差评很多将竞对的差评转化为认知,继而针对性迭代自己产品的设计  

Lean Startup III 用MVP验证两个假设

  重点: 验证解决方案和痛点的匹配度通过不断迭代,实现对真实用户的痛点、有效解决方案的不断逼近工具:Minimum Viable Product 最小可行产品针对天使用户的「最小功能组合」关键点:只针对天使用户对产品容忍度高能看到产品的未来愿意互动,一起改进产品最小、最基本功能组合建议把想象中的产品砍成两半,再砍两半关键点:以最快的速度通过MVP获取认知,放弃一切无助于认知的功能 速度聚焦 举例:Zappos - 美国最大的鞋类电商网站待验证:有没有人愿意通过网购买鞋 MVP: 不是 买一堆鞋子不是 建立仓库是 在鞋店里拍下照片,发到网站上是 如果有人买,他就到店里按原价把鞋买下来再寄给顾客分析: 卖一双鞋都会亏一点钱用很少的钱验证了基本假设 举例:微信1.0版待验痛点: 传统运营商短信贵群发短信不容易MVP(1.0版): 只有免费短信和短信群发功能I 设计MVP本质:资源有限的前提下,加快迭代速度、快速获取认知 第一步:用户排序不急于放大用户群,主动做减法,过滤 & 筛选用户群,找出天使用户 用户分层金字塔: 天使用户两特点: 特点一:痛点迫切,愿意尝试不成熟、不完美、有一定缺陷的产品 特点二:愿意积极提供反馈,愿意积极推广产品或解决方案 举例:啄木鸟假牙关键:引入了20位牙医,作为天使用户,单独拉微信群以方便沟通 牙医将病人情况反馈给研发,包括使用产品前后对比图、最新治疗情况等 第二步:痛点和功能排序对痛点和功能组合做筛选和排序,找出最核心、与痛点最相关、最小的功能组合 方法: 从最痛点、功能开始验证提出「可有可无」、「暂不需要」的功能点最痛点验证完之后,才向次重点迈进关键: 聚焦加速聚焦举例 - 社交软件:Yo唯一功能:想起哪个朋友要打招呼,点一下这个朋友的名字,会自动给他发一条信息:Yo 第三步:制作MVPMVP形态静态页面(如:卖鞋的Zappos)广告链接微信朋友圈里发的某个东西产品原型设计产品原型思路: 类比:通过观察其他行业或本行业类似的服务、产品,获取灵感反证:观察别人,总结失败案例跨界嫁接:不同产业、行业的不同创新元素重新组合,通过嫁接形成产品原型举例:斯坦福学生团队的移动充电桩原型场景:车库没充电桩 原型:木板下装了四个轮,上面放了块电池 II 测度MVP & 数据收集比较关注数据指标(与成型产品关注的数据指标不同): 分阶段指标 而不是 总指标实时的对比测试 而不是 事后的因果分析 对比验证:多版本试验定量 与 定性(后续对用户的访谈与观察)结合工具一:AB测试举例亚马逊:办公室里的桌子摆放,都通过AB测来决定...(有名的AB测公司) 预设一个测量指标把桌子摆成不同形状通过指标评分决定桌子摆放啄木鸟假牙:两轮AB测 内部测(19个内部员工,刻意提高销售人数比重)外部测(19个牙医)工具二:同期群分析针对总量概念的对比。 如果:只看uv总数变化曲线,会掩盖不同时期用户群的行为差异或活跃度差异 同期群分析:看到不同时期用户数的变化 - 进入、推出、流失 帮助我们把用户分成不同时期的用户群的工具 目的:对每一个用户群的行为和趋势,进行更精确的判断 工具三:净推荐值NPS - Net Promoter Score,表明了MVP是否有增长潜力 「测试用户黏性时,唯一有效的工具」 净推荐值和「增长」密切相关,高净推荐值有可能获得「病毒式增长」 初创公司三大增长引擎黏着式增长:用户新增率 > 用户流失率

Lean Startup 概述

  0x0 新思维运动三个代表Steve Blank 《四步创业法》《创业者手册》Eric Rise Steve Blank的学生《精益创业》Reid Hoffman LinkedIn创始人核心 - 承认未知从「天才人物的天才设想、完美计划和完美执行」 → 「科学试错、民主创业」 从试错中不断获取认知、不断迭代认知,最终调整创业路径 未知观不知道用户痛点是什么不知道解决方案是什么只能通过不断试错,不断迭代,去逼近用户的真实痛点,而不是「幻想」能百分之百的「捕捉到用户痛点」 实践 - Amazon Fresh(生鲜配送)选择西雅图做试点,「单点突破」一开始只选择了几个居住密度最大的高端小区服务不针对所有人,而是「天使用户」缴纳299美元年费的方式,过滤出天使用户天使用户对「购物环节」痛点极大选择「用户少 & 粘度高」的用户,做验证和测试5年时间不断测试生鲜零售模型 & 调整参数5年后才进入洛杉矶依然选几个密度最大的小区切入Lean Startup 五项基本原则用户导向原则:从「自我导向」到「用户导向」行动原则:从「计划导向」到「行动导向」「行先于知」,而不是「知引导行」试错原则:从「完美预测」到「科学试错」工具:MVP聚焦原则:从「系统思维」到「单点爆破」单点突破、主动过滤噪音客户迭代原则:从「完美主义」到「高速迭代」迭代、速度 都很关键总结“假设并不是科学的,任何假设都只是假设,只有经过验证或者说可证伪的假设才是科学的” 0x1 逻辑框架新创企业 & 大公司新创企业不是大公司的缩小版,大公司执行已知的商业模式,新创企业探索商业模式 Lean Startup是一个关于「探索商业模式」的方法论区别商业模式:大公司已经有了被验证的商业模式,新创公司没有大公司:执行已知或已确定的商业模式,更多是在运营和执行层面新创公司:探索未知的商业模式 新创企业之所以失败,是因为它们混淆了探索与执行,过早执行一个没有经过验证的商业模式。 新创企业的工具目标:更高效的探索商业模式 工具:Lean Startup Lean Startup 逻辑结构Part I:基本的商业计划只是假设的商业计划,用这个东东提出「前提和假设」再完美的商业计划:也只是「前提和假设」也经不起和客户的第一次亲密接触在和客户第一次接触时,基本上也就完成了历史使命Part II:「客户开发」阶段客户开发和产品开发同步进行,甚至客户开发前置于产品开发客户开发而非产品开发,是整个Lean Startup的核心中心是用户,而非产品,更不是自己想象中的产品产品根据用户的需求来开发Part III:「精益研发」阶段用「精益研发」来快速迭代,科学试错小结用商业计划建立前提和假设,从一开始就把客户导入到创业过程中用「高速迭代」、「科学试错」获取认知传统产品引入模型缺陷认知来的太晚:直到产品已经开发完毕,进入测试阶段,团队才真正开始提升认知的过程 创业过程中最关键的不是某个产品或服务而是在于是否具有正确的认知用户反馈是否从一开始就结合在创业过程中两个错误假设: 用户痛点高度确定解决方案高度确定新创企业生命周期 & 工作重点精益创业期阶段I:商业模式探索(发散式)发散式探索,不确定性极高可能会尝试多个方向,快速转向,不停试错阶段II:商业模式探索(聚焦式)已经确定了初步方向在两三个路径中选择商业模式关键点I、II阶段:现金流为负,关键点是「快速迭代」、在现金流耗尽之前,尽快确立商业模式 工作重点 起点:「用户探索」 任务:探索和定义两个基本假设用户痛点假设解决方案假设关键点:倾听的技巧观察、访谈、倾听用户停止推销,开始倾听在很长一段时间里,对推出自己的解决方案保持克制结果:不断探索,不断提升认知 进入:「用户验证」 任务:验证「用户痛点假设」和「解决方案假设」验证商业模式:可重复、可规模化方法:与天使用户大量互动 转轴: 定位:用户开发的「核心反馈机制」时机:「用户验证」阶段,发现没有天使用户做法:循环往复,免除危机回到精益创业的起点,调整商业模式,继续探索,积累认知,迭代商业模型关键:快速、敏捷、把握时机原因:现金流为负、现金流有限 有用户 & 商业模式成立: 进入用户扩张 & 执行阶段 Sweet Spot:II 和 III 的交界点,此处新创公司终于确立了商业模式 这个点之前和之后,需要的技能「完全不同」硅谷很少有人能「同时拥有两大阶段技能」放大执行期阶段III:商业模式确立放大阶段从1到100阶段IV:商业模式正常执行传统商学院覆盖的内容三大理论基石I 跨越鸿沟参考:豆瓣 新产品,如何从「天使用户」到被「主流人群」广泛接受

区块链基础 & 公链原理

  0x0 区块链相关概念法币:日常生活中用到的纸币 去中心化:比特币不需要中间机构做货币的发行工作 - 货币是被「发现」的,而不是「发明」的。需要注意的是,并不是所有的区块链项目都是去中心化的 挖矿:「结点A」希望给「结点B」转钱,需要「矿工」帮A把钱「搬运」过去 这种搬运的行为就是「挖矿」挖矿的平均时长:10分钟(转钱不是实时到账的)广播:矿工除了能「挖矿」,还可以「广播」 - 每挖成功一次矿,就会给所有结「广播」一次 账本:每个结点都有一个「账本」 每个结点每次收到广播,就会在自己的账本上记录一条信息唯一的作弊方式就是篡改所有结点的账本记录区块链:每个结点维护的「账本」就叫做「区块链」 区块:每笔转账记录消息,就叫「区块」 创世区块:区块链的第一个区块「创世区块」 矿工挖到矿之后,希望向区块链中,追加一个区块 矿工之所以能挖出来矿,是因为有人在转账 0x1 公链原理(共识算法)PoW原理Proof of Work - 工作量证明系统 区块参数Nonce值:可以理解为序号 Timestamp:挖区块的时间戳 Data:交易信息 Hash:根据当前区块信息计算出来的哈希值 Pre Hash:上一个区块的哈希值 说明有上表我们知道,参数中除Nonce和Hash,其他参数都是已知且固定的 矿工挖矿的时候,需要先把Nonce值置为1,把四个参数组合起来,计算Hash值。如果当前组合计算出来的Hash值不符合「要求」,则把Nonce累加后,再次计算新的Hash,直到符合要求 要求比如当前难度为4,则要求计算出来的Hash值,前4个数必须为0000,才算挖矿成功 比特币难度系数有调整机制,会随着所有结点的总算力增强而增强,所以挖矿越来越难 过程模拟https://anders.com/blockchain/blockchain.html 区块的链接两个区块的链接方式,是通过后一个区块保存前一个区块的hash值,而链接起来的 公链把上述步骤原理用代码实现而产生的产品 示意代码片段type Block struct { PreHash []byte Timestamp int64 Data []byte Hash []byte Nonce int } func main() { //创建创世区块 var genesisBlock = CreateGenesisBlock() var newBlock = GenerateNextBlock(genesisBlock) fmt.Println("挖出的新区快Data为", newBlock.Data) fmt.Println("挖出的新区快Data为", hex.EncodeToString(newBlock.Hash)) } func CreateGenesisBlock() *Block { var genesisBlock = &Block{[]byte{0}, time.

探索互联网产品的最佳实践

  根据《启示录》第二部分 - 流程 相关内容,重新梳理总结而成。省略了部分「大公司」相关内容 & 「开发」相关内容 0x0 概述产品探索 + 产品开发 = 完整产品 本章着重探讨「产品探索」部分,这部分内容是所打造产品的能否达到预期的核心。 目标产出有价值、可用、可行的解决方案(产品原型) 阶段产品探索分为两阶段: 机会评估阶段方案完善阶段将会在「0x1」「0x2」两节中详细介绍 Tips「产品探索」阶段,完成时间不固定、无法准确预期不要像规划施工一样规划产品探索时间 反面举例 当我们有一个创意,需要根据它定义新产品的时候,计划: 第一周:评估产品机会,尝试理解待解决问题,拜访潜在用户,收集基本需求 第二周:与交互设计师一起制作产品原型 第三周:利用产品原型展开用户测试 第四周:完成产品用例,与开发团队一起评审原型和文档 然而: 第三周突然发现,用户对解决方案(创意或原型)丝毫不感兴趣 没时间了,于是让开发团队做「有缺陷」的产品 最后产品彻底失败 确保「产品探索」完成后再进入「产品开发」否则,就是赌上全部开发资源,在进行「产品探索」 通过「用户研究」可以改善现有产品常用方法 问卷调查、日志分析、数据挖掘、拜访用户、可用性测试、竞品分析 注意 仅通过用户研究,很难定义新产品 0x1 机会评估阶段目标(Task)发现& 确认问题、发现和验证市场机会 淘汰馊主意避免浪费时间和金钱挑选最合适、最有利的产品机会团结团队、理解产品、整合资源方法(Action)十问法1、产品价值:产品要解决什么问题? 最难回答多数PM答非所问,只能说出:产品的功能和特色2、目标市场:为谁解决这个问题? 3、市场规模:成功的机会有多大? 可以求助于:行业分析师贸易协会公司财务结合自己的分析做出判断评估需要谨慎,避免浮夸,不是所有产品都有十亿美金市场4、量化指标:(度量指标或收益指标)怎样判断产品成功与否? 5、竞争格局:有哪些同类产品? 6、竞争优势:为什么我们最适合做这个产品? 7、市场时机:时机合适吗? 8、营销组合策略:如何把产品推向市场? 描述具体销售方案,甚至会影响产品需求9、解决方案要满足的条件:成功的必要条件是什么? 注意:不是描述解决方案,而是搞清楚产品的依赖因素和约束条件举例:如果要通过系统集成商销售产品,对方可能会对产品的扩展性、合作方式提出要求10、结论(继续或放弃):给出评估结果 特约用户法寻找10名左右用户作为「特约用户」 从特约用户身上,探索目标用户的需求强烈程度 Tips机会评估只讨论「待解决问题」,不应该涉及「具体解决方案」将来有大把时间讨论考虑方案,现在需要认真考虑「解决什么问题」 常见错误 把「问题」和「解决方案」一起考虑「解决方案」遇到问题,就整个放弃「产品机会」(洗澡水和孩子一起倒掉)开发新产品或者改善旧产品,都属于「产品机会」「产品机会」与产品的新旧无关,需要一视同仁的比较所有产品机会的「成本和收益」 新产品一样有机会市场环境充满变数竞争对手不断被淘汰新技术、新创意不断涌现财务人员辅助机会评估能帮你了解和评估产品,看公司的投入是否划算帮你了解用户,财务同事掌握着各种支付、交易数据确认商业上的可行性常见错误跳过机会评估阶段没有回答机会评估应该论证的问题大量回避评估产品机会,直扑产品设计的PM小案例产品机会评估案例 0x2 方案完善阶段目标(Task)设计& 验证& 完善MVP解决方案(探索最小可行产品解决方案) 方法(Action)此处主要讲方案的验证和完善 原型测试法目标目标一:测试产品原型的价值判断对用户来说: 你的产品是否有用是否愿意购买有多喜欢产品的设计重在观察用户是否喜欢这些功能 目标二:测试产品原型的可用性发现没能成功实现的功能点发现被忽视掉的功能点重在观察用户如何设法完成必要操作 步骤步骤一:选人特约用户竞品用户亲朋好友(针对大众产品)目标用户聚集地捞人步骤二:测试测试内容: 1、用户未接触产品时,如何解决相关问题 先不要给测试者原型,只抛问题然后看他们如何做2、观察测试者能否从原型首页看出产品要解决的是什么问题?哪些功能点最吸引他们? 3、正式进行测试任务 4、任务完成后通过聊天收集进一步信息 是否使用同类产品?是否有别的解决方案?原型是否比他们常用的产品好?净推荐值打分?5、让用户为产品的每个阶段打分 x、如果原型尚不完整 分功能点,测试主流程用户操作到没做好的功能点:问问他们「接下来希望发生什么」TipsPM要亲自参与原型测试,不能委托他人,一定要多接触用户克服自己「难以面对测试结果」的心里障碍,要明白:自己产品设计不可能完美,没有人能做到始终正确获取用户反馈是完善产品的最佳途径理想状态下需要两个人:一个人主持测试,一个人做记录测试的是原型,而不是测试者…只有原型会测试不通过,测试者不会的,不要担心告诉测试者:这只是初步创意,不是正式产品,请大胆说出真实看法测试重点:看测试者是否能「轻松完成任务」&「喜欢相关功能」步骤三:迭代提高原型的「可用性」和「价值(吸引力)」 原型修改:2~3个用户反应同一个问题就可以马上修改原型 成功表征:连续6个用户理解和欣赏产品价值,且完成了关键的测试项目

Golang与密码学

  0x0 概述这篇文档主要聊聊三种加密方式与Golang实现 哈希加密对称加密非对称加密0x1 哈希加密哈希算法我们知道,查找中,有「哈希查找」,是一种比「顺序查找」更快的查找方法。 「哈希查找」的关键点,就是实现一种「哈希算法」,使得每个任意key,经过哈希算法计算后,可以获得一个定长的散列值。 相同key经过相同哈希算法散列之后,获得相同的散列值不同key经过相同哈西算法散列之后,获得不同的散列值特点: 可以把任意长度的「明文」,散列成固定长度的「指纹」正向计算简单快速,逆向推算困难,基本不可能逆推出明文明文有一点点变化,密文就会改变优秀的散列算法需要尽量避免两个不同的明文,加密出来是相同的指纹发展:  取模操作 → 异或运算→ 位移操作 密码学里面,一般都通过「位移操作」「取模操作」「异或操作」来实现加密 - 无论对称加密非对称加密、哈希散列加密 成熟Hash算法MD5SHARIPEMDGolang相关hash代码片段MD5MD5加密结果为16字节串 data := []byte("test string") s := fmt.Sprintf("%x", md5.Sum(data))m := md5.New() m.Write(content) s := hex.EncodeToString(m.Sum(nil))SHA256sha256加密方式,通常用在公链中,散列结果为32字节 s := fmt.Sprintf("%x", sha256.Sum256(content))m := sha256.New() m.Write(content) fmt.Println(hex.EncodeToString(m.Sum(nil)))文件内容加密 f,_ := os.Open("filename") h := sha256.New() io.Copy(h,f) s := h.Sum(nil) fmt.Println(hex.EncodeToString(s))RIPEMD160ripemd160目前只在数字货币中用到了 - 以太坊 三方包:golang.org/x/crypto/ripemd160 可以使用gopm安装 gopm get -v -u golang.org/x/crypto/ripemd160 hasher := ripemd160.New() hasher.Write([]byte("test string")) fmt.Println(hex.EncodeToString(hasher.Sum(nil)))0x2 对称加密对称加密,加密完之后,是可以通过密钥解密的 - 和hash加密不一样 常见对称加密算法: DESAES补码、去码 & 分组加密补码:给15个字符做「分组加密」,无法平均分成两组,所以需要补一个码凑成16个字符,这种操作叫做「补码」

启示录 - 互联网团队构成

  产品成败的关紧因素:选择人员、界定工作职责 作者在本节中反复强调了,「不同的工作要人不同的人专职来做」 但是作为初创团队,甚至个人开发者,人力严重不足的情况下,需要「分清项目阶段」,「不同阶段让自己带上不同的思考帽」进行不掺杂无关信息的专业性思考。 通过这一章,我们可以知道,个人开发者,在整个项目流程中: 分别需要扮演什么样的角色?每种角色的职责是什么?每种角色需要分配多少精力?时间占比如何?每种角色的目标产出是什么?产品达成预期的关键点:有价值 + 可用 + 可行 关键角色及其职责角色职责补充PM 产品经理评估产品机会 机会来源:Boss拍脑袋用户反馈可用性测试产品团队和运营团队脑爆PM需要判断这些需求是否可采纳工具和方法(产出):传统方法(产出):市场需求文档(MRD)简化方法(产出):机会评估(作者提出的方案)详细定义待开发产品(探索产品的解决方案) 需定义的内容:基本的产品特征和功能产品的用户体验产品的发布标准工具和方法(产出):传统方法(产出):产品需求文档(PRD)简化方法(产出):简化文档(围绕产品原型展开工作)注意点:文档应该用来描述「功能」和「属性」文档不应该用来「讨论技术实现」【重要】一定要有一个全权负责「定义产品」的人 【重要】产品经理定义的产品没有价值、不具备可用性和可行性,开发团队多出色都无济于事 九成产品未能实现既定目标: 构思拙劣尚不成熟可用性差毫无价值PM最宝贵的经验: 打造优秀产品的流程领导产品团队的能力应对产品扩张的经验个人对自己的认知自我激励的能力(不是)行业知识或技术UED 用户体验设计师让真实用户测试产品 用户研究 职责:研究分析用户,评估产品或原型是否符合特定用户的使用习惯工作内容:拟订恰当的用户测试项目监督测试评估测试结果提出改进方案产出:没说...估计是用户画像之类的吧...交互设计 工作内容:理解「目标用户」的基础上:设计有价值、可用的:目标功能用户导航产品使用流程产出:「用线框绘制产品需求」,交给视觉设计师视觉设计 工作内容:根据线框,设计可见的用户界面:布局颜色字体传达并唤起产品蕴含的情感原型制作 迅速制作融合的PM、设计师创意的产品原型,让用户试用根据用户反馈意见,反复修正原型与PM密切合作,将功能和设计相结合,确保产品同时具有「可用性」和「价值」 PM → 价值UED → 可用性 为了保证「可行性」,还需要软件架构师参与评估设计和产品原型 项目经理产品定义完毕之后,开发团队接手,项目经理登场 制定计划跟踪进度目标:保证项目「按期发布」 有些项目经理,以为管理能力等同于使用微软「Project」软件的能力,这没有领悟项目管理的真谛。 优秀项目经理的特质: 给人工作紧迫感善于捕捉问题思路清晰用数据说话利用数据:识别项目方向确认项目进度改善产品和开发流程,必须从「测量、收集数据」开始务必坚持根据「数据和事实」制定决策果断判断力态度必须克服所有障碍解决所有问题一往无前、愈挫愈勇,直到项目成功RD 开发成功的产品:真实用户需求(PM) + 现阶段可行的技术方案(RD) 【tips】很多优秀的产品,是程序员抓住用户需求,自己创业研发出来的 OP 运维负责保障web服务正常运行运营对外宣传推广产品产品发布拓展市场销售渠道组织重点营销活动和PM沟通互补: 运营是产品获得需求的重要来源产品是运营获取市场营销信息的重要来源小团队的妥协方案案例让设计师身兼数职 一个创业公司只有三个人: 产品经理交互设计师(同时负责用户研究)视觉设计师(同时负责开发原型)获取了不错的结果:很快拿到产品原型(可供目标用户测试的) 「拿到产品原型」可以看做是一个里程碑可外包内容视觉设计用户研究和可用性测试外包成本较高重视「测试反馈」的话,成本更高建议让产品经理、交互设计师分担「用户研究」、「可用性测试」工作原型制作可以从开发团队借个帮手来做结果导向不要告诉别人「如何做」,而是告诉他们「做什么」 收集需求的时候,常听用户谈论「你们应该如何做」,而非「做什么」。思考解决方案是人类的天性PM如果思考「做什么」,会发现解决方案如此多客户不必考虑解决问题的途径他们不知道什么可行PM常常告诉UED如何设计产品,却忘了告诉他们「做什么」  

Linux定时任务

  参考资料:鸟哥的linux私房菜 Linux 排程就是透過 crontab 與 at 這兩個東西 at 和 crontabat:处理只发生一次的事件 crontab:处理周期性事件 crontab 除了可以使用指令執行外,亦可編輯 /etc/crontab 來支援CentOS常见定时任务log rotate(日志轮替)logwatch(日志分析工具)tmpwatch (移除暂存文档)...定时任务与软件安装的多少有关 单次任务指令:at 相关服务:atd 注意:atd不一定已经打开了,需要手动操作之~ > systemctl restart atd # 重新啟動 atd 這個服務 systemctl enable atd # 讓這個服務開機就自動啟動 systemctl status atd # 查看状态at使用使用 at 指令创建工作,將這個工作寫入 /var/spool/at/ 目錄內,atd 服務会執行之可以利用 /etc/at.allow 與 /etc/at.deny 這兩個文件來進行 at 的使用限制 at.allow:at指令白名单用户at.deny:at黑名单。如果木有at.allow,会根据at.deny判断权限以上两个文件都木有:只有root可使用...写的有点长...没看完 定时任务服务:cron(crond) 该服务预设为自动启动的执行任务的日志:/var/log/cron指令:crontab 使用结果:指令被记录到/var/spool/cron/用户名 中指令格式:crontab [-u username] [-l|-e|-r] -e: 编辑crontab的定时任务(当前用户的) 任务会写在/usr/bin/crontab文件中-l: 查看crontab任务-r: 移除所有crontab任务示例:crontab -e (进入编辑界面,每项任务占一行)*/5 * * * * /home/dmtsai/test.

Go 语言狂人许式伟:编程的意义就是让世界变得有趣一些

  从小孩的教育到世界观当小孩长大以后,未来十年二十年的时候整个社会是什么样子的? 只有明白了那个时候的世界是什么样的,才能想象教会小孩什么东东可以让他适应那个时候的世界——这个和做企业是一样的 不要因为别人的言论而认为世界是什么样的,应该有自己的世界观 职业生涯工作六年以后,有困惑:为什么我们做的wps不赚钱呢?做什么业务才是符合互联网时代的?商业上才能成功的?07年坚决转型产品经理,只有PM才能在商业上探讨产品成功的可能性。07思考:移动互联网的大趋势下,什么东西会变化?发现:似乎还没有移动互联网下的存储公司创建七牛七牛的使命:释放社会的创造力。 解释:你有没有在做一个新的,以前人没有试过的探索。这件事是勇敢的、值的鼓励的。你起码试了,别人连试都不敢试。云计算可以降低试错成本,让你可以一个月、一周就能判断你的尝试是不是一个靠谱的事情。 几个观点如果把人看成一个投资人的话,投资企业和思考小孩的教育有共同点:你要思考未来。写代码不习惯单步调试:人需要在把自己逼到资源相对匮乏下,才能更有效的突破(这个观点和辉哥的观点相同,想要高效学习,需要认为制造时间上的稀缺性)编程的意义在于,让你真正能够创造一个世界,或者说改变一个世界。人的意义在于自我实现,自己追求的是什么,就去实现什么。所以,要让这个世界变的更有趣一些。视频内容<iframe src="//player.bilibili.com/player.html?aid=12069987&cid=19912250&page=1" scrolling="no" border="0" frameborder="no" framespacing="0" allowfullscreen="true" height=490 width=682 </iframe  

【Git技巧】为Git创建一个孤立分支

  问题描述有时候我们需要在GIT里面创建一个空分支,该分支不继承任何提交,没有父节点,完全是一个干净的分支,例如我们需要在某个分支里存放项目文档。 使用传统的git checkout命令创建的分支是有父节点的,意味着新branch包含了历史提交,所以我们无法直接使用该命令。 可视化效果【Git技巧】为Git创建一个孤立分支 image2018-4-19_14-27-9.png" data-location="Azen 【Git技巧】为Git创建一个孤立分支 image2018-4-19_14-27-9.png" data-image-height="560" data-image-width="1310" 解决方法创建分支使用 git checkout的--orphan参数: git checkout --orphan doc该命令会创建一个名为doc的分支,并且该分支下有前一个分支下的所有文件。 查看--orphan的帮助: Create a new orphan branch, named <new_branch>, started from <start point> and switch to it. The first commit made on the new branch will have no parents and it will be the root of a new history totally disconnected from all the other branchs and commits. 这里的start point指的是你执行git checkout命令时的那个分支,当然新的分支不会指向任何以前的提交,就是它没有历史,如果你提交当前内容,那么这次提交就是这个分支的首次提交。