- 博客(932)
- 资源 (47)
- 收藏
- 关注
RSS订阅原创 爬虫+Flask+Echarts搭建《深度学习》书评显示大屏
在饼图页面和柱状图页面中，我们使用Pie()和Bar()函数创建了一个饼图和一个柱状图，并设置了相应的参数。通过对书评数据进行预处理和情感分析，并将结果可视化展示出来，我们可以更好地了解读者对这本书的评价情况。上述代码中，我们首先使用re库编译了一个正则表达式模式，用于匹配所有的空格、制表符和换行符。然后，我们使用循环遍历书评列表中的每一个元素，并使用re.sub()函数将匹配到的字符替换为空字符串。由于爬取到的书评数据中可能存在一些无意义的字符，比如空格、换行符等，因此我们需要对数据进行预处理。
2023-07-19 17:45:30
261
原创 前端框架Layui的使用讲解（Layui搭建登录注册页面）
Layui是一款基于jQuery的前端UI框架，具有轻量、简单、易用等特点。Layui提供了丰富的组件和接口，包括表单、表格、弹窗、导航、日期等常用组件，以及丰富的API接口。Layui的设计理念是“模块化设计”，即将一个完整的页面拆分成多个模块，每个模块都有独立的功能和样式，便于开发和维护。本文介绍了Layui框架的基本使用方法，并通过搭建一个登录注册页面的实例来展示Layui的强大功能。希望读者能够通过本文对Layui有更深入的了解，并在实际开发中灵活运用。
2023-07-19 17:42:49
1052
原创 使用函数的正确姿势
实际上，如果它是个常量，那也就形成不了闭包了，因为常量是不可变的程序实体，而闭包体现的却是由“不确定”变为“确定”的一个过程。只要两个函数的参数列表和结果列表中的元素顺序及其类型是一致的，我们就可以说它们是一样的函数，或者说是实现了同一个函数类型的函数。原因是，所有传给函数的参数值都会被复制，函数在其内部使用的并不是参数值的原值，而是它的副本。以切片值为例，如此复制的时候，只是拷贝了它指向底层数组中某一个元素的指针，以及它的长度值和容量值，而它的底层数组并不会被拷贝。类型的签名一致，并且实现得当就可以了。
2023-05-29 10:31:25
204
原创 通道的高级玩法
函数的时候，只需要把一个元素类型匹配的双向通道传给它就行了，没必要用发送通道，因为 Go 语言在这种情况下会自动地把双向通道转换为函数所需的单向通道。另外，我们在 Go 语言中还可以声明函数类型，如果我们在函数类型中使用了单向通道，那么就相等于在约束所有实现了这个函数类型的函数。如果我们把它用在通道的类型字面量中，那么它代表的就不是“发送”或“接收”的动作了，而是表示通道的方向。的左边，那么就说明该通道只能收不能发。注意，与发送操作和接收操作对应，这里的“发”和“收”都是站在操作通道的代码的角度上说的。
2023-05-11 10:17:06
138
1
原创 通道的基本操作
今天我们讲到了通道的一些常规操作，包括初始化、发送、接收和关闭。通道类型是 Go 语言特有的，所以你一开始肯定会感到陌生，其中的一些规则和奥妙还需要你铭记于心，并细心体会。首先是在初始化通道时设定其容量的意义，这有时会让通道拥有不同的行为模式。对通道的发送操作和接收操作都有哪些基本特性，也是我们必须清楚的。这涉及了它们什么时候会互斥，什么时候会造成阻塞，什么时候会引起 panic，以及它们收发元素值的顺序是怎样的，它们是怎样保证元素值的完整性的，元素值通常会被复制几次，等等。
2023-04-21 10:33:30
148
原创 字典的操作和约束
我们这次主要讨论了与字典类型有关的，一些容易让人困惑的问题。比如，为什么字典的键类型会受到约束？又比如，我们通常应该选取什么样的类型作为字典的键类型。我以 Go 语言规范为起始，并以 Go 语言源码为依据回答了这些问题。认真看了这篇文章之后，你应该对字典中的映射过程有了一定的理解。另外，对于 Go 语言在那些合法的键类型上所做的求哈希和判等的操作，你也应该有所了解了。再次强调，永远要注意那些可能引发 panic 的操作，比如像一个值为。
2023-04-19 10:30:39
140
原创 container包中的那些容器
这个代码包中有两个公开的程序实体——List和Element，List 实现了一个双向链表（以下简称链表），而 Element 则代表了链表中元素的结构。
2023-03-22 10:20:45
145
原创 数组和切片
总结一下，我们今天一起探讨了数组和切片以及它们之间的关系。切片是基于数组的，可变长的，并且非常轻快。一个切片的容量总是固定的，而且一个切片也只会与某一个底层数组绑定在一起。此外，切片的容量总会是在切片长度和底层数组长度之间的某一个值，并且还与切片窗口最左边对应的元素在底层数组中的位置有关系。那两个分别用减法计算切片长度和容量的方法你一定要记住。另外，
2023-03-09 11:47:27
138
原创 程序实体的那些事儿 （下）
在本篇文章中，我们聚焦于类型。Go 语言中的每个变量都是有类型的，我们可以使用类型断言表达式判断变量是哪个类型的。正确使用该表达式需要一些小技巧，比如总是应该把结果赋给两个变量。另外还要保证被判断的变量是接口类型的，这可能会用到类型转换表达式。我们在使用类型转换表达式对变量的类型进行转换的时候，会受到一套规则的严格约束。我们必须关注这套规则中的一些细节，尤其是那些 Go 语言命令不会帮你检查的细节，否则就会踩进所谓的“陷阱”中。
2023-03-09 10:47:11
105
原创 程序实体的那些事儿（中）
我们先讨论了代码块，并且也谈到了它与程序实体的作用域，以及访问权限控制之间的巧妙关系。Go 语言本身对程序实体提供了相对粗粒度的访问控制。但我们自己可以利用代码块和作用域精细化控制它们。如果在具有嵌套关系的不同代码块中存在重名的变量，那么我们应该特别小心，它们之间可能会发生“屏蔽”的现象。这样你在不同代码块中引用到变量很可能是不同的。具体的鉴别方式需要参考 Go 语言查找（代表了程序实体的）标识符的过程。另外，请记住变量重声明与可重名变量之间的区别以及它们的重要特征。
2023-03-01 10:30:26
126
原创 程序实体的那些事儿（上）
如果只用一两句话回答这个问题的话，我想可以是这样的：Go 语言的类型推断可以明显提升程序的灵活性，使得代码重构变得更加容易，同时又不会给代码的维护带来额外负担（实际上，它恰恰可以避免散弹式的代码修改），更不会损失程序的运行效率。在 Go 语言中，变量的类型可以是其预定义的那些类型，也可以是程序自定义的函数、结构体或接口。可以想象，如果不这样会多写不少代码。Go 语言是静态类型的编程语言，所以我们在声明变量或常量的时候，都需要指定它们的类型，或者给予足够的信息，这样才可以让 Go 语言能够推导出它们的类型。
2022-12-14 12:22:00
219
原创 库源码文件
我们在本篇文章中详细讨论了把代码从命令源码文件中拆分出来的方法，这包括拆分到其他库源码文件，以及拆分到其他代码包。这里涉及了几条重要的 Go 语言基本编码规则，即：代码包声明规则、代码包导入规则以及程序实体的访问权限规则。在进行模块化编程时，你必须记住这些规则，否则你的代码很可能无法通过编译。
2022-12-13 17:46:49
344
原创 命令源码文件
这有很多种方式，最简单的一种方式就是对变量flag.Usage重新赋值。flag.Usage的类型是func()，即一种无参数声明且无结果声明的函数类型。flag.Usage变量在声明时就已经被赋值了，所以我们才能够在运行命令时看到正确的结果。注意，对flag.Usage的赋值必须在调用flag.Parse函数之前。现在，我们把 demo2.go 另存为 demo3.go，然后在main函数体的开始处加入如下代码。}那么当运行后，就会看到现在再深入一层，我们在调用flag包中的一些函数（比如。
2022-11-16 11:40:43
404
原创 故障管理:故障应急和故障复盘
除了例行的故障应急和故障复盘，我们还会定期对一个时期内的故障案例进行总结。比如按照一个季度、半年和全年的周期，这样可以更容易地发现一些共性问题，以便于研发团队在稳定性建设方面的规划。举个例子，2017年年底，我们整体总结了全年的故障案例，对P0~P2严重级别的故障进行分类汇总，就发现全年第三方原因的故障，以及数据类的故障占了很大比例。我们再往细节分析，发现第三方原因的故障，多数是机房IDC的电力、网络切换，单台服务器硬件故障导致的。
2022-11-15 16:15:37
1186
原创 故障管理:鼓励做事，而不是处罚错误
我们做个小总结，对于故障的态度，我们还是得要辩证地看。对于是否处罚，也要具体问题具体分析。完全不处罚，或者一刀切，一律处罚都是不可取的。作为管理者，还是要将规则和标准定义清楚，在执行时才能够做到公平公正。另外，管理者除了关注故障本身之外，还要考虑得更加全面一些，要关注到人的感受，关注事情的前因后果，只有这样，在管理执行过程中才会让员工感受到尊重和信任。最后，你在故障定责和处罚方面有什么经历和想法，欢迎留言与我讨论。
2022-11-15 15:58:10
455
原创 故障管理:故障定级和定责
今天我们讨论了故障管理中的定级和定责标准。蘑菇街在这方面的具体管理执行中，还是取得了不错的效果，所以分享出来，欢迎你留言与我讨论。
2022-11-15 15:38:44
1804
原创 故障管理:谈谈我对故障的理解
再表达两个观点。第一，出问题，管理者要先自我反省。不能一味地揪着员工的错误不放，员工更多的是整个体系中的执行者，做得不到位，一定是体系上还存在不完善的地方或漏洞。在这一点上，管 理者应该重点反思才对。第二，强调技术解决问题，而不是单纯地靠增加管理流程和检查环节来解决问题，技术手段暂时无法满足的，可以靠管理手段来辅助。比如我上面提到的就基本都是技术手段，但是要建设一 个完善的体系肯定要有一个过程，特别是对于创业公司。
2022-11-15 15:11:34
508
原创 稳定性实践:全链路跟踪系统，技术运营能力的体现
今天我们从技术运营层面的应用这个角度重新认识了全链路跟踪系统。同时，从这个案例中，我们也应该看到，技术、产品和运营相辅相成，共同促进彼此的完善和成熟。全链路跟踪系统在技术方案的广泛应用，给我们提供了大量可分析处理的线上运行数据，从这些数据中，我们又能提炼出对线上稳定运行更有价值的信息。所以，技术之外，我们也应该更多地考虑技术在价值方面的呈现。今天的内容就介绍到这里，你在这方面遇到过哪些问题，有怎样的经验，欢迎留言与我讨论。
2022-11-15 11:57:33
528
原创 稳定性实践:开关和预案
在稳定性保障中，限流降级的技术方案，是针对服务接口层面的，也就是服务限流和服务降级。这里还有另外一个维度，就是业务维度，所以今天我们就从业务降级的维度来分享， 也就是开关和预案。如何理解开关和预案 开关，这个概念更多是业务和功能层面的，主要是针对单个功能的启用和停止进行控制，或者将功能状态在不同版本之间进行切换。在业务层面，就像我们前面经常提到的大促场景案例，我们会关闭掉很多非核心功能，只保留交易链路的核心功能。比如我们认为商品评论是非核心功能，这时就会通过开关推送这种方案将这个功能关闭。
2022-11-15 11:26:37
259
原创 稳定性实践:限流降级
首先，我们先梳理清楚限流和降级的概念，明白它们会发挥怎样的作用，这样才便于我们理解后续的解决方案。限流，它的作用是根据某个应用或基础部件的某些核心指标，如QPS或并发线程数，来决定是否将后续的请求进行拦截。比如我们设定1秒QPS阈值为200，如果某一秒 的QPS为210，那超出的10个请求就会被拦截掉，直接返回约定的错误码或提示页面。降级，它的作用是通过判断某个应用或组件的服务状态是否正常，来决定是否继续提供服务。
2022-11-14 20:51:28
861
原创 稳定性实践:容量规划之压测系统建设
容量规划离不开对业务场景的分析，分析出场景后，就要对这些场景进行模拟，也就是容量的压力测试，用来真实地验证系统容量和性能是否可以满足极端业务场景下的要求。同时，在这个过程中还要对容量不断进行扩缩容调整，以及系统的性能优化。今天，我们就来看压力测试的技术实现方式:压力测试系统的建设。我们详细讲讲压力测试的几个维度。
2022-11-08 19:41:07
474
原创 稳定性实践:容量规划之业务场景分析
通过上面的分享，我们应该不难发现，容量规划工作，单纯靠技术能力是无法解决的，需要经验和数据的积累，到了阿里这个体量就必须借助人工智能和各类分析算法这样更高级的手段才能解决。同时，容量问题，也不是简简单单通过资源扩容这种成本投入就可以解决的，扩容是最后的执行手段，但是怎么合理的、科学的扩容，就需要有合理的规划。当业务体量和复杂度到达一定程度时，就要依靠技术人员对业务的深入理解。能够合理规划业务、技术和数据模型，是需要一些经验积累，以及在各类极端场景下的经历。
2022-11-08 17:28:19
441
原创 极端业务场景下，我们应该如何做好稳定性保障?
从今天开始，和你分享我对微服务和分布式架构下的稳定性保障的理解。稳定性保障需要一定的架构设计能力，又是微服务架构比较核心的部分。在陈皓老师的“左耳听风”专栏，以及杨波老师的“微服务架构核心20讲”专栏都有非常详细的介绍。所以在我 的专栏里，我会结合特定的场景，并着重从运维和技术运营的角度来分享。我们所面对的极端业务场景首先，看一下我们当前所面对的极端业务场景，我把它大致分为两类。
2022-11-07 16:58:01
332
原创 云计算时代，我们所说的弹性伸缩，弹的到底是什么?
今天我们以弹性伸缩为例，讨论了如何思考问题和分析问题。我们的讨论和分析归结到一点就是:独立思考和分析的能力很重要，意识也很重要，切忌不可人云亦云随大流，反而迷失了工 作的方向。现在业界各种技术上的Buzzword(时髦词)层出不穷，让人目不暇接，但是仔细观察和思考，你会发现它们背后常常隐藏着很多共性的特点，一定要抓住它们背后所要解决的问题和本质，这样也就不会乱花渐欲迷人眼了。
2022-11-07 15:58:04
376
原创 量体裁衣方得最优解:聊聊页面静态化架构和二级CDN建设
今天分享的页面静态化架构方案和二级CDN方案，是我在实际工作中较早跟公有云方案相结合的实践之一，并且在我们的日常和大促活动中，起到了非常好的效果。同时也可以看到，我们的业务一旦与公有云相结合，云生态的各种优势就会马上体现出来。但是无论选择哪种方案，都要结合具体的业务场景，才能作出最优的方案选择。公有云也好，云计算也好，都不能为我们提供完美的定制解决方案。正所谓具体问题具体分析，找出问题，优化解决路径，量体裁衣，才能得到最适合我们的“定制方案”。
2022-11-03 20:33:30
340
原创 以绝对优势立足:从CDN和云存储来聊聊云生态的崛起
通过CDN和云存储这个案例，我们可以清晰地看到，随着公有云的深入发展，特别是公有云巨头的飞速进步，公有云已经形成了自有的、独特的生态体系。这不仅仅体现在技术和产品层面，而且可以预见其最终还会形成商业层面的体系闭环。所以，利用云计算的优势，拥抱变化，才能够为我们的业务发展和创新带来更多的可能性。以上分享的这些内容，是我在近两年的工作中真切经历过的案例和感受，希望能在思路拓展上对你有所帮助。如果你在这方面有什么好的经验和想法，欢迎你留言与我讨论。
2022-11-03 17:32:45
393
原创 Spring Cloud:面向应用层的云架构解决方案
上期文章我们介绍了混合云，以及在实际操作中我们常见的几种混合云模式。今天我们来聊一聊Spring Cloud如何解决应用层的云架构问题。对于Spring Cloud，你大概不会陌生，它跟Spring生态中的另一个开源项目Spring Boot，基本上已经成为国内绝大多数公司向微服务架构转型时的首选开发框架。
2022-11-03 14:55:06
412
原创 为什么混合云是未来云计算的主流形态?
上面我以蘑菇街为例，分析了我们为什么会认为混合云会是未来一段时间内的主流形态，并推测了可能还会出现的其他混合模式，比如多云平台的混合、多云平台服务的混合等等。不管如何选择和使用，我们一定还是要以满足业务场景为出发点，脱离了这一点，单纯追求技术深度和复杂度是没有意义的。在公有云或混合云应用过程中，你曾遇到过什么问题，或者有什么好的建议，欢迎你留言与我讨论。
2022-11-02 17:52:33
308
原创 为什么蘑菇街会选择上云?是被动选择还是主动出击?
2018年1月22日凌晨，我们美丽联合集团旗下的蘑菇街和美丽说的业务，整体搬迁到腾讯云，完成了从托管IDC模式，到腾讯云上混合云模式的转变。云计算发展到今天，无论是在技术、服务层面，还是在商业层面都已经相对比较成熟。当前绝大多数初创公司在基础设施上的策略一定是公有云，已经极少再有自建或托管IDC的情 况，所以不会存在是否上云这样的纠结。但是对于蘑菇街这样体量的公司，搬迁上云，就必须要考虑得更全面:考虑基础设施的变化，业务的平稳过度，运维模式的转变，成本管控的调整，以及众多的细节问题。
2022-11-02 16:40:10
243
原创 做持续交付概念重要还是场景重要?看“笨办法”如何找到最佳方案
至此，我们整个持续交付体系的内容就全部介绍完了。对于整个过程的总结，你可以参考本专栏“持续交付”主题的第一篇文章《持续交付知易行难，想做成这事你要理解这几个关键 点》，我在文中对整个持续交付体系进行了比较完整的梳理。细心的你应该可以发现，到本期文章为止，我并没有提到太多DevOps相关的内容，而这个恰恰是当前业界非常火热的概念。在写作过程中，我也没有特别强调持续交付是什么，持 续集成是什么，而这些又是当前DevOps里面特别强调的部分。
2022-11-02 11:49:48
202
原创 持续交付中流水线构建完成后就大功告成了吗?别忘了质量保障
到这里，我们稍作一个总结。关于持续交付中的流水线模式，我们在前面两期文章以及本期的分享中，相对完整地介绍了从需求分解开始，到代码提交、软件构建，再到功能和非功能测试验证的整个过程。这个过程就是我们常说的持续集成。之所以我没有在一开始引入这个概念，是因为，如果我们将注意力集中到这一过程中具体的动作和问题上，会更有利于我们理解，而不是一开始就被概念性的术语和框架束缚住。
2022-11-01 20:43:30
243
原创 持续交付流水线软件构建难吗?有哪些关键问题?
上期文章我们介绍了需求分解与应用对应的管理方式，以及提交环节的开发协作模式，今天我们详细介绍一下提交阶段的构建环节，也就是我们经常提到的代码的编译打包。
2022-11-01 16:12:11
186
原创 人多力量大vs.两个披萨原则，聊聊持续交付中的流水线模式
在前面5期文章中，我们分别详细介绍了持续交付体系基础层面的建设，主要是多环境和配置管理，这些是持续交付自动化体系的基础，是跟我们实际的业务场景和特点强相关的， 所以希望你一定要重视基础的建设。本期文章是我们持续交付系列的第6篇文章，从本期开始，我们进入到交付流水线体系相关的内容介绍中。
2022-11-01 14:25:46
364
原创 线上环境建设，要扛得住真刀真枪的考验
我们简单构建一张模型图来对线上环境作个展示:我在这两期文章中介绍了这么多环境，我们可以看到，环境建设是一项异常繁琐复杂的工作，这些工作不是一蹴而就，而是根据实际的场景和问题催生出来的，所以是个逐步渐进的过程。而且，因为不同的业务类型和场景，以及业务发展的不同阶段，场景和问题可能都是不一样的，而且其建设需求也不一样，所以在实际操作中，一定要切合具体情况进行建设。再就是，环境管理是复杂的，多一个环境就多一份管理成本。所以环境并不是越多越好，反而是越精简越好。
2022-11-01 10:13:16
352
原创 开发和测试争抢环境?是时候进行多环境建设了
最后，不知道你有没有感受到，单单一个线下环境就要如此复杂和繁琐，整个持续交付体系建设是多么的有挑战性，就可想而知了。我们对线下环境稍微做个总结:集成测试环境，主要供测试使用，这个环境会最大程度与线上版本保持同步。作为对应用的功能、需求、业务流程等在正式发布上线进行验证的主要环境，集成测试环境的稳定性和可测试需要加强保障，进行全套建设。同时，作为整个线下环境的中心节点，也要为开发测试环境和项目环境提供部分依赖服务。
2022-10-31 14:37:48
408
原创 如何做好持续交付中的多环境配置管理?
今天我们针对多环境的配置管理进行了分享，这里更多的还是思路和方案上的引导。如果你对Maven和AutoConfg不熟悉的话，建议自行查询资料进行学习了解，甚至是自己动手 尝试一下。另外，对于文章中的方案，我是尽量简化了场景来分享的，虽然思路上是相通的，但是实际情况下各种细节问题会更繁琐，要具体问题具体分析。你在这个过程中遇到过什么问题?有什么好的解决方案?或者还有什么具体的疑问?欢迎你留言与我一起讨论。如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见!
2022-10-28 16:23:13
1347
原创 持续交付的第一关键点:配置管理
今天我们来看持续交付的第一个关键点:配置管理。按照持续交付的理念，这里所说的配置管理范围会更广，主要有以下几个部分。版本控制依赖配置软件配置环境配置讲持续交付，一上来就先讲配置管理，主要还是想强调:配置管理是基础，是关键。我们后面将要讲的每一个持续交付环节，都对配置管理有很强的依赖。这个基础工作做不好，也就 谈不上的持续交付的成功。勿在浮沙筑高台，我们做工具平台或系统，一定要重视基础的建设。同时，这里还有一个前提，就是一定要做到代码和配置的分离。不要让配置写死在代码里，需要依靠严格的规范和约束。
2022-10-28 15:19:09
693
原创 持续交付知易行难，想做成这事你要理解这几个关键点
我们现在经常会接触到这些名词，比如持续交付、持续集成、持续部署、持续发布、DevOps和敏捷开发等等。大多有关持续交付的分享或文章中，这些名词经常会同时出现。它们 之间到底有什么区别?我自己之前也弄不清楚，直到看到乔梁老师的这张图。这里我重点解释一下持续交付这个概念，通俗地说，持续交付代表着从业务需求开始到交付上线之后的端到端的过程。后面我们会针对这个过程的关键环节进行分享。受篇幅所限，其它名词就先不作过多解释了，你可以看图自己体会，都不难理解。后面针对某些概念我们还会提到。
2022-10-28 14:50:23
264
原创 冷静下来想想，员工离职这事真能“防得住”吗?
最后，我们来总结一下。对于离职想表达的两个观点:员工离职反应了个人发展与团队发展之间的矛盾;员工离职是个必然结果，坦然接受，做出应对，而不是谈之色变，或避而不谈。对于技术管理，这其实是个很大的话题，今天我们提炼一个重点:技术管理者，一定要重点关注人，而不仅仅是事情。这一点是做技术骨干和技术管理者之间的最大差别，也是转变思路的第一步。在技术管理上，你还有什么疑问，欢迎留言与我沟通讨论。
2022-10-27 14:46:12
283
原创 运维需要懂产品和运营吗?
最后，我们再总结一下，运维虽然不是业务系统的实现者和代码的开发者，但是我们参与到了产品技术标准的制定、业务系统运维体系的建设以及后期的技术运营中，这个时候运维已然成了整 个技术架构的设计者之一，而且是架构稳定和演进的看护者，这时我们所发挥的作用和呈现的价值已大不相同。从技术产品和技术运营的角度再来思考一下运维，现在的运维还是之前那个运维吗?欢迎你留言与我一起讨论。如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见!
2022-10-27 11:46:14
1036
1
2018全新无限流量卡充值官网PHP源码
2019-03-20
http协议-破冰-基础课程
2022-06-22
xlggg-http-notification-master.zip
2019-08-22
后台模板.7z
2019-08-22
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人