班会第 28 期
ufologist opened this issue · 0 comments
- 技术
-
一个用Vue.js开发微信app界面(ios风格)的demo
线上地址: vue-wechat.github.io
-
Chrome 49+ 可用, 其他浏览器可以用 URLSearchParams polyfill
The URLSearchParams interface defines utility methods to work with the query string of a URL.
var paramsString = "q=URLUtils.searchParams&topic=api" var searchParams = new URLSearchParams(paramsString); //Iterate the search parameters. for (let p of searchParams) { console.log(p); } searchParams.has("topic") === true; // true searchParams.get("topic") === "api"; // true searchParams.getAll("topic"); // ["api"] searchParams.get("foo") === null; // true searchParams.append("topic", "webdev"); searchParams.toString(); // "q=URLUtils.searchParams&topic=api&topic=webdev" searchParams.set("topic", "More webdev"); searchParams.toString(); // "q=URLUtils.searchParams&topic=More+webdev" searchParams.delete("topic"); searchParams.toString(); // "q=URLUtils.searchParams"
-
只要大家是js沾边工程师，http是无法躲过的、必须掌握的技能
- 三层架构
- 二个核心：req和res
- 一个记住：无状态
- Chrome调试与http
- http基础：GET/POST/上传
- 表单
- 异步：ajax
- 使用Node.js实现服务端
- 工具postman
- 命令行cUrl
-
前端重构应该关注自己哪些能力的提升，在繁重的业务压力下怎么提升自己的能力，如何让专业能力有更好的呈现，个人影响力怎么加强，如何成为一个小团队里面的骨干？
说到前端重构的职业成长，我觉得应该重点关注三个方向
- 专业能力: 职业技能(一专) + 辅助技能(多长)
- 职业技能
- 辅助技能
- 通用能力: 通用能力带动专业能力
- 项目管理的能力
- 解决问题的能力
- 主动沟通的能力
- 团队影响力: 每个人能力的提升促进整个团队发展壮大
- 文档的输出
- 知识的分享
- 基础规范: 为了增强团队的协作和高效开发，提升代码质量，TGideas团队一起制订的代码规范。主要包括五部分内容：PC规范、移动端规范、性能优化、CP规范、
- SEO指南: 团队在SEO方面的经验沉淀，SEO小组多年经验实践总结，主要包括四部分内容：基本规范、PC与移动端差异化、产品侧SEO、SEO白皮书
- 组件: 主要包括五部分内容：移动端组件、PC功能类组件、PC效果类组件、3D效果类组件、PC样式组件
- 工具: 工作中常用的工具，包含TGideas团队开发的及收集的外部工具
- 前端推荐: 这是有一些资源，如推荐书籍介绍、PDF文档下载、前端博客链接、前端分享资源、工作参考手册
- 专业能力: 职业技能(一专) + 辅助技能(多长)
-
我理解的Webpack，就是一个更出色的前端自动化构建工具、模块化工具、资源管理工具。
为什么选择Webpack，两点原因。
- 前端需要模块化：JS模块化不仅仅为了提高代码复用性，更是为了让资源文件更合理地进行缓存
- AMD与CMD规范日渐衰弱：原因？ES6带来了很强的模块化语法糖
Why Webpack
-
模块化前端项目的发布打包问题
-
代码切分: 抽取多个页面公用模块，打包成commonjs，便于缓存
两大重要概念：切分点（split point）与代码块（Chunk）
-
版本控制: 对于静态资源的版本控制
如果将版本号作为请求参数，版本号为发布日期，有两个问题：
- 更新版本时，CDN不能及时更新
- 没有发生变更的文件也被赋上新版本
Webpack的做法是，生成hash，区分文件
-
如何做技术，每个做 ( 过 ) 技术的都有自己的经验，而总结起来无非是影响自己、影响团队、影响业界，影响世界。
- 无码无坑，写好代码，提升手速是影响自己
- 抽象、共用帮其他人省时间是影响团队
- 开源源码、把**带给业界，让昨天的优秀项目成为明天的基础设施是影响业界
- 通过程序让一个方水平的人甚至多方水土的人能更方便地做某件事，是改变世界
- 古训总是简炼地为我们总结这些罗嗦的话「修身，齐家，治国平天下」
一线程序员，团队最重要的成员。这群人做了最多的事，产出了最重要的结果。如果每个人产出的质量和速度都增长，那么客户将更乐意把口袋的钱放到公司的账户。这里的关键是质量和速度。
- 良好的入门指南
- 导师
- 榜样
- 提供工具
- 鼓励成长
- 提供机会
主管、经理，团队的中坚力量. 总监、部门负责人，团队的资源池
最好的管理不是当团队的保姆，而是当团队的资源池. 如果每个人都能很好的自我驱动，在缺什么的时候就向资源池去拿，那么世界一定是和平的
- 雇主心态
- 放权与资源
- 设定好目标和方向
- 提升团队影响力
-
业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。
一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，nosql缓存需要主从集群，静态文件需要上传cdn，这些都是能让业务程序流畅运行的强大后盾。- 通用方案(缓存): 日用户流量大，但是比较分散，偶尔会有用户高聚的情况；
- 消息队列: 秒杀、秒抢等活动业务，用户在瞬间涌入产生高并发请求
- 一级缓存: 使用站点服务器缓存去存储数据
- 静态化数据: 对于更新频繁度不高，并且数据允许短时间内的延迟，可以通过数据静态化成JSON，XML,HTML等数据文件上传CDN，在拉取数据的时候优先到CDN拉取
-
PhxSQL是一个建立在Paxos的一致性和MySQL的binlog流水基础上, 提供 Zookeeper 级别强一致和高可用的MySQL集群
PhxSQL完全兼容MySQL，建立在简单可逻辑证明的一致性模型之上，架构、部署、运维简单
主要原理简单来说
- Paxos选出主机
- 主机把本机MySQL设置成可写的MySQL主机，在MySQL写binlog流程中拦截binlog流水、发送到Paxos，形成全局的binlog流水
- 备机把本机的MySQL设置成只读的MySQL备机，MySQL备机从全局binlog中拉取流水，重放和执行，从而主备MySQL一致
- 针对常见的业务场景，PhxSQL提供两个服务端口：强一致读写端口（ReadWritePort）和只读端口（ReadonlyPort）；对数据要求强一致的业务，通过ReadWritePort来读写；只要求能读取但不要求最新数据的读请求（比如一些定时对账业务），可以通过ReadonlyPort来读取
看这张图让我想起了 EVA 动画片中的MAGI
在EVA中，由赤木直子博士开发的三台超级电脑被命名为 “三贤人超级计算机系统”（MAGI System）简称“三贤人”（MAGI）。MAGI相当于NERV的大脑，由三大系统组成：MELCHIOR-1，BALTHASAR-2，CASPER-3。
在数据库事务隔离方面，PhxSQL支持最高级别的serializable。在性能方面，PhxSQL提供明显优于MySQL半同步的写性能和几乎相同的读性能
MySQL传统主备同步方案仍然具备很多新系统难以企及的优点。MySQL主备在主机上支持完整SQL、全局事务、以repeatable read和serializable级别的事务隔离，在金融、帐号等关键业务中有巨大的价值。同时，现有复杂MySQL应用迁移到新的非兼容系统成本也很高。
但是MySQL传统主备方案也有其缺点。最明显的就是主机故障后的自动换主和新旧主数据一致性（以及衍生的换主后主备一致性、各个备机之间一致性，这里就不详加讨论了），即所谓的一致性和可用性。
为了解决这个问题，有传统流派：用Zookeeper、etcd、或者其它第三方来检测心跳、选主、和切换。改造MySQL client让其能感知新的主机。或者为了能让传统MySQL client不加修改就能感知新的主机，部署MySQL代理服务器，让其将连到自身的MySQL client请求透明转发给新的主机。为了减少主备间数据的落后，从而降低旧主机故障、某台备机被提升成新主机时，新旧主机之间、新主机和其它备机之间的差异，很多方案在主备同步机制上做了很多有益的工作
如果主备间任何时刻都完全一致，那么任何时刻换主都是强一致的。这句话的另外一个意思是，如果无法保证主备间任何时刻完全一致，那么当有持续不断的更新时，任何时刻的换主都是无法保证强一致的。
PhxSQL的设计原则是什么？
-
简单可逻辑证明的一致性模型
各个MySQL的binlog流水一致，则各个MySQL机器之间数据“一致”
对于PhxSQL来说，切换主机是一件很平常和容易的操作，就像往MySQL里插入一条数据一样平常和容易 -
最小侵入MySQL原则
-
简单的架构、部署、和运维
PhxSQL只有3+1个模块
- MySQL是必须的
- PhxBinlogSvr负责全局binlog存储和同步、选主、集群成员管理等关键功能
- PhxSQLProxy则作为传统MySQL client访问PhxSQL中MySQL服务的代理，使得PhxSQL的换主操作对于传统MySQL client透明
- 可选模块是PhxSQL client lib，它修改了MySQL client库中的连接初始化函数，允许传入一个集群的PhxSQLProxy列表，从而在一个PhxSQLProxy没有响应时、自动访问其它可用PhxSQLProxy，进一步提高可用性。开发人员可以直接链接PhxSQL client lib。
开源是整个互联网的基石，为全世界提供许多关键不可或缺的基础服务
PhxSQL的局限性
- MySQL主机在执行SQL DDL命令（例如建库和建表命令）时可能存在一致性风险。
- 在写入请求量很大的系统中，MySQL备机流水可能落后较多；如果这个时候主机死机，备机暂时无法提升成新主机，造成系统在一段时间内不可写
-
没有什么框架是银弹，可以搞定所有问题，只有最适合你当前业务的框架和语言。
片面的信仰任何一种技术都是不负责任的，目的不是比谁最牛逼，而是谈谈这些框架都好玩在什么地方
-
Ruby on Rails 是效率的极致
Rails 最大的魅力就是 Convention over configuration 约定优于配置这种敏捷开发的理念. 说白了就是提供了一套规范和默认配置, 如果你按照规范来, 你基本上就不需要配置了, 一路顺风顺水, 如果团队和业界都采用相同的规范, 那么效率必然得到提高.
举个例子来说，你要买一个包子，如果你不说你要什么馅的，那么包子店就随便给你一个包子，因为此时的重点不是包子馅，而是包子本身，一个由皮，馅构成，由蒸这种加工工艺做成的点心，这就是约定。而当你指定要什么馅的时候，就成了配置。
-
Node.js
在 Node.js 上，我最终学到的一件事情是，语言速度快这些特性并不能解决高并发这种场景，因为在那个时候，服务器的性能瓶颈不是语言，而是数据库。
-
elixir on Erlang VM
Erlang 是 1987 年爱立信发布的针对电信手机通讯的语言，天生支持高并发和高 uptime，在移动互联网的著名成功案例就是 Whatsapp，单个机器可以支持 200 万连接。
-
Go
Go 不光编译的快，运行起来也是非常快
-
Swift
他有像 Rails 一样强大的社区，有像 Ruby 一样有趣的语言，有像 Go 一样编译语言的优秀特性
-
-
- 产品
-
工作中有一个高效的逻辑思维能力无比重要。它能立刻让你找到问题的关键，让问题引刃而解。
我对逻辑思维的理解。逻辑思维的过程，是化繁为简，目的，是找到解决方法。因此，所有和“寻求解决方法”无关的信息，都是无用信息，都需要剔除。
花半秒钟就看透事物本质的人，和花一辈子都看不清事物本质的人，注定是截然不同的命运。
Be MECE: 取自“Mutually Exclusive Collectively Exhaustive”，中文意思是相互独立，完全穷尽，发音读作“Me See”
实际运用中你只用不停问自己两个问题：
- 我是不是把所有的可能因素都考虑到了，有没有遗漏的？如果有，再去找。
- 这些因素之间有没有互相重叠的部分？如果有，进行去重。
归纳和演绎
这是两条基本的认知事物和思考的逻辑法则
- 归纳，是把具备某种相同属性的事物，一一列举出来，然后寻找共通点。
- 演绎，是把互相之间形成影响的因素，按照事物因果顺序、时间先后顺序，重要程度顺序排列出来，再寻找突破口。
工作中所有的问题，你都可以把它用演绎或者归纳的形式进行拆分。我喜欢把这个过程称为“解构”。归纳演绎和前面提到的 MECE 经常会搭配使用，在归纳演绎的过程中，坚持 MECE 的原则，能把复杂的问题分解成多种单一的因素，这个过程犹如抽丝剥茧，将一团乱麻理地条条顺顺。
下面是我思考问题时会遵循的一个思维提纲，大家可以参考：
- 核心问题是什么？（只能有一个，如果有很多，找到最重要的那个）
- 这个问题的背景是什么？（来龙去脉，历史原因）
- 和现在这个问题有关的人物和因素有哪些？（记住MECE法则，用归纳法，一一并列出来）
- 哪些是导致这个问题的关键原因？
- 哪些是次要原因？
- 解决这个问题有哪些方法？（用归纳法，写出所有可能。用演绎法，找到每种方法实施的具体步骤）
- 解决这个问题，你现在欠缺哪些条件或者资源？
- 如何去弥补这些条件上的欠缺？
- 你的时间规划是怎样的，先做什么，再做什么，然后做什么？
- 最后一步，just do it.
先说结论
先讲结论，把你要阐述的观点一开始就抛出来，这能节省所有人的时间. 因此第一句话就要把自己的核心观点传递出来：我们的方案是什么，以及，它为什么是最佳的选择。
记住按照总分总的原则，首先抛出核心观点，即“我们应该做什么”。接下来需要进行解释，即“为什么这么做”。
演绎归纳和 MECE”，是你的分析思考过程；“先讲结论”，是你思考完以后的表述方法。
先讲结论的人，能够在一开始就抓住别人的注意力，接下来通过层层递进的方式论证结论的正确性，听众就不会迷失方向。
当你给领导汇报工作的时候，他们绝不可能听你长篇累牍的解释分析，他们只会听你的结论，或者解决方法。当他们有兴趣的时候，会追问细节，当他们很忙的时候，他们只需要听到最重要的东西。
培养洞察
事物的原因，原因的原因，原因的原因的原因。你需要洞察的，就是事物的本质。在平时生活中养成勤于思考的习惯。
-
致敬 G20：这 17 张 PPT 里，有关于**命运的 30 个大胆思考
**正在通过G20开启世界下一个世界开端，读懂**，就读懂了世界。
**未来产业
- 1 维的传统产业
- 2 维的互联网产业
- 3 维的智能科技产业
- 一维世界正在推倒重建，二维世界被划分完毕（BAT掌控），三维世界正在形成，高维挑战低维总有优势。所以网店可以冲散实体店，而微信的对手一定在智能领域诞生。
**当下的企业
- 三等企业做服务
- 二等企业做产品
- 一等企业做平台
- 今后企业的出路唯有升级成平台，平台化的本质就是给创造者提供创造价值的机会！
**互联网进化论
- PC互联网
- 移动互联网
- 物联网
- PC互联网解决了信息对称，移动互联网解决了效率对接，未来的物联网需要解决万物互联：数据自由共享、价值按需分配
**经济结构进化论
- 计划经济
- 市场经济
- 共享经济
- 共产经济
- 从“按计划生产、按计划消费”，到“按市场生产，按利润分配”，再到“按消费生产，按价值分配”
**产业链的流向正在逆袭
- 以前先生产再消费, 未来一定是先消费再生产
- 传统经销商这个群体将消失，而能够根据消费者想法而转化成产品的设计师将大量出现
**广告业态的进化论
- 媒介为王
- 技术为王
- 内容为王
- 产品为王
- 未来最好的广告一定产品本身，最好的产品也一定具备广告效应。
**商业角逐的核心
- 地段
- 流量
- 粉丝
- 房地产经营的就是地段，传统互联网经营的就是流量，自媒体经营的是粉丝。而未来是“影响力”和“号召力”之争，“核心粉丝”的瞬间联动是未来商业的“引力波”。
**媒体的进化论
- 传统媒体
- 新媒体
- 自媒体
- 信息流
**社会的组织结构从公司+员工，变成平台+个人. 未来每一个人都是一个独立的经济体。
当你有一个想法时，你可以先表达出来，然后在平台上进行展示（这样的平台会越来越多），然后吸引喜欢的人去下单，拿到订单后可以找工厂生产（不用担心量太少，今后的生产一定会精细化和定制化），然后再送到消费者手里。
**商业未来十年内的主题都将离不开，“跨界互联”. 以互联网+为基础，不同行业之间互相渗透、兼并、联合，从而构成了商业新的上层建筑
**未来只有三种角色，自下而上依次是
- 价值提供者
- 价值整合者
- 价值放大者
-
我认可的是运营就是经营，但这同样是个很大的词，而经营就是得用心、用脑慢慢去做的一件事。
运营太大了，运营又太细了，运营什么都会，但运营又什么都不会。运营会什么，想创意、写文案、选商品、填页面、做推广、跟进度、看数据，设计师资源不够自己上，前端资源不够自己切页面。但按让专业的人做专业的事来说，运营又什么都不会，只会提需求，提需求，提需求。
所以运营是最直接接触和把控业务的人，运营做得好，你可以甚至当CEO，运营做不好，当一颗螺丝钉，你也会最先被踢掉。阿里为什么运营牛？阿里的核心业务就是电商，电商就得靠运营，用心用脑研究出来的。
有几项特质是做好运营（前提是做好）必不可少的，足够细致、有耐性、爱思考、主观能动性强。
-
不要纠结，先去做
做事情是要先思考，但不要纠结在选择，如果实在想不清楚也不用纠结，先去做，试试看，或许就有思路了。
-
站在一定的高度上，要有格局
“你做的可是产品运营，运营的是啥？是整个APP呢，你要站在CEO的高度想问题”. 站得越高，想得越多，能考虑到的就越全面，埋头只做自己的事常常会迷失方向，不知对错。就像开车时，教练说眼睛看着最远的地方
-
不看你怎么想，要看你怎么做
-
心要大，皮要糙
-
-
