拆分链表、图解 HTTPS、Zookeeper 原理、如何成为技术专家、架构师三板斧 John 易筋 ARTS 打卡 Week 18
题目
Given a linked list and a value x, partition it such that all nodes less than x come before nodes greater than or equal to x.
You should preserve the original relative order of the nodes in each of the two partitions.
Example:
解答
分离链表,可以初始化另个链表,一个都小于某个值,一个大于等于某个值,最后拼接起来即可。这里需要注意:最后一个节点的next需要设置为null,否则会导致死循环。或者每个节点都根据val重新创建一个避免这种问题。
重新定义链表,用于打印输出
算法实现
2. Review: 阅读并点评至少一篇英文技术文章
笔者的博客
翻译:图解HTTPS工作原理、秘钥、握手、HTTPS,SSL,TLS的区别、证书
在这里开始阅读。如果您从这部漫画中拿走的只有一件事,那就让它成为这件事。
要了解HTTPS的工作原理,您必须了解对称和非对称密钥加密的工作方式。听起来像是大话,但实际上并非如此。
当您浏览到HTTP安全站点时,您的浏览器和它所连接的服务器将进行秘密握手。我们将其分解并带入现实世界,以便您可以通过秘密握手与朋友打招呼。
容易混淆HTTPS,SSL和TLS。我们经常互换使用这些术语。让我们用一些历史来谈谈每个人。
他们在做什么?我们为什么需要它们?他们如何验证证书?在漫画的最后一章中有太多问题要回答!
参考
https://howhttps.works/episodes/
3. Tips: 学习至少一个技术技巧
笔者写的博客:
漫画:什么是ZooKeeper、Znode、最大ZXID、Paxos、ZAB协议?
4. Share: 分享一篇有观点和思考的技术文章
笔者写的博客链接
极客大学架构师训练营如何成为技术专家、软件开发技术的第一性原理、架构师的三板斧 第29课 听课总结
说明
说明讲师:首席架构师 李智慧
1. 如何成为专家?
1.1 技术等级体系
金字塔每一层都是根据2、8定律分开。假如全球有2000万开发者,在最下面的无名者是1600万。
团队影响者为400万人;
公司影响者为80万人;
全国影响者为16万人;
全球影响者为3.2万人;
关键开创者为6400人;
领域开创者为1280人;
行业开创者为256人。
国内的99.99% 技术大牛,止步在全国影响者。开创者基本上都在美国。
目前国内在大数据,机器领域还是比较有优势,有可能上升为开创者。
1.2 德雷福斯模型
新手:新入行者;
高级新手:熟悉本公司的工作内容,流程;会的内容比较有限;大多数领域里面超过半数的人,都是高级新手,有的甚至到退休都是这样。
胜任者:能够触类旁通,类似的问题或者稍微难一点的问题,也可以搞定;
精通者:有自我驱动、自我学习能力;比较擅长于提炼专家的知识为规范;
专家:本能能拆解问题,给出解决方案;
1.3 德雷福斯模型的启示
一个人不会因为工作经验就自动成为专家,只有非常少的人能成为专家。专家不一定做得更好,但一定做得更轻松。
大部分人终其一生停留在高级新手阶段,而阻碍TA继续发展的一个重要原因就是:TA不知道自己是一个高级新手。
1.4 如何在工作中成长,成为技术专家
勇于承担责任,在悬崖边思考。
在实践中保持技能,1万小时定律。
警惕银弹陷阱,关注问题场景。
1.5 最重要的是在工作中实践
工作任务要明确,具体产出是什么?结果如何衡量?用 OKR 管理工作目标。
工作任务要有适当难度,摘 跳起来够得着的苹果。
任务过程中积极接收各种反馈,针对反馈采取行动。
允许自己犯错误。
1.6 彼得定律
在一个成熟有效的组织中,当一个员工在其岗位能够出色完成工作,就会得到晋升,被提拔到更高一级职位。如果在这个职位,他能够继续出色完成工作,就会继续得到晋升,知道TA晋升到某个职位以后,无法出色完成工作为止。
结论:在一个层级组织中,每个员工都会趋向于晋升到TA 所不能胜任的职位。
推论:一个成熟的组织中,所有的职位都被不能够胜任它的人承担着。
当一个人位于TA不能胜任的职位上时,TA必须投入全部的精力才能有效完成工作,这个职位也被称作这个人的彼得高地。一个处于彼得高地的人,精疲力尽于TA手头的工作,就无法再进行更进一步的思考和学习,TA的个人能力提升和职业进步都将止步于此。
2. 软件开发技术的第一性原理
用第一性原理分析一个新技术的来龙去脉:
这个技术的核心关键点是什么?要解决的问题是什么?
过往有没有类似的技术?核心设计是否想通?
这些问题应该使用何种模式解决?
不要去学习软件如何使用,而是去猜测软件如何设计:
5分钟阅读 Hello World 级的文档和 Demo;
30分钟做个 Hello World,体验一下;
2个小时阅读关键设计文档和代码;
如果我来开发这个软件,将如何设计、关键技术点如何处理。
3. 架构师的三板斧
3.1. 设计文档
没有软件设计文档就没有软件设计:
让自己停一下,思考下软件的设计,有没有更好的方案。
给软件开发的合作者、维护者提供一些必要资料。
UML 软件建模设计
部署图:描绘系统整体蓝图;
组件图:描述系统模块关系;
类图:关键类的设计和领域模型;
用例图:功能与场景;
活动图:泳道图,逻辑与流程;
时序图:参与对象之间的调用关系;
状态图:复杂对象的状态变迁。
3.2 设计模式
低耦合、高内聚:是软件设计的核心驱动力和目标;
设计原则:开闭、依赖倒置、里式替换、单一职责、接口隔离;
设计模式:工厂、适配器、策略、观察者、组合、模板方法、装饰者;
开发框架:Spring、Mybatis、反应式。
3.3 架构模式
分布式架构:
分布式缓存、消息队列、负载均衡;
分布式关系数据库、NoSQL、搜索引擎;
分布式一致性 ZooKeeper。
微服务架构:
领域驱动设计、服务复用与中台化;
微服务框架与 RPC。
大数据架构
大数据平台架构;
数据采集与分析;
数据推荐与智能化。
性能优化
性能测试与分析:性能测试、负载测试、压力测试;
性能指标:响应时间、并发数、吞吐量;
性能优化三板斧:缓存、异步、集群。
系统高可用架构方案:
解耦
隔离
异步
备份
失效转移
幂等
事务补偿
重试
熔断
限流
降级
异地多活
版权声明: 本文为 InfoQ 作者【John(易筋)】的原创文章。
原文链接:【http://xie.infoq.cn/article/6d2c8c3265e1dad0655fc70c0】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论