首页 文章 精选 留言 我的

精选列表

搜索[自动发现],共10000篇文章
优秀的个人博客,低调大师

Angular 发布新调试指南,帮助开者发现代码中的错误

Angular 团队公布了新的调试指南,旨在让开发者更容易找到代码中的错误。 编码时最好的事情就是第一次尝试就能成功。其次则是当第一次不成功时,能够知道如何调试错误。正如我们在路线图上分享的那样,我们团队的首要任务之一是改善 Angular 调试体验。 该团队宣布推出几个新方法,以改善调试并帮助开发人员更快地解决问题。其中包括,最常见的 Angular 错误信息现在已有标准化的错误代码、附加细节和格式。用户可以采用以下格式识别这些代码: 目前,该团队已经在 Angular 11.1.0 中引入了这些更改,旨在帮助使 Angular 框架的错误可识别、可搜索,并能够通过相似性进行分组。 同时,这些错误消息还提供了一个指向angular.io/errors的链接。官方表示,他们优先考虑了最常见的错误,并为它们编写了 angular.io 指南。Angular 文档中的一个新章节内容就包含了针对十个最常见的错误的指南,其中包括有 missing tokens、invalid elements 和 missing reference targets。 此外,该指南中还提供了一个与Fireship.io合作创建的嵌入式文档教学视频,旨在提供可视化的调试常见错误的方法。完整教学视频地址。 Angular 方面表示,这个工作流程,从框架错误格式到指南、再到视频,都是旨在改善调试体验,以帮助新的开发者学习 Angular。希望用户能喜欢这些新资源,并向官方反馈他们希望看到再增加哪些错误指南。

优秀的个人博客,低调大师

花5分钟看这篇之前,你才发现你不懂RESTful

原创公众号:bigsai 转载请联系bigsai 文章收藏在回车课堂 前言 在学习RESTful 风格接口之前,即使你不知道它是什么,但你肯定会好奇它能解决什么问题?有什么应用场景?听完下面描述我想你就会明白: 在互联网并没有完全流行的初期,移动端也没有那么盛行,页面请求和并发量也不高,那时候人们对接口的要求没那么高,一些动态页面(jsp)就能满足绝大多数的使用需求。 但是随着互联网和移动设备的发展,人们对Web应用的使用需求也增加,传统的动态页面由于低效率而渐渐被HTML+JavaScript(Ajax)的前后端分离所取代,并且安卓、IOS、小程序等形式客户端层出不穷,客户端的种类出现多元化,而客户端和服务端就需要接口进行通信,但接口的规范性就又成了一个问题: 所以一套结构清晰、符合标准、易于理解、扩展方便让大部分人都能够理解接受的接口风格就显得越来越重要,而RESTful风格的接口(RESTful API)刚好有以上特点,就逐渐被实践应用而变得流行起来。 现在,RESTful是目前最流行的接口设计规范,在很多公司有着广泛的应用,其中Github 的API设计就是很标准的RESTful API,你可以参考学习。 在开发实践中我们很多人可能还是使用传统API进行请求交互,很多人其实并不特别了解RESTful API,对RESTful API的认知可能会停留在: 面向资源类型的 是一种风格 (误区)接口传递参数使用斜杠(/)分割而不用问号(?)传参。 而其实一个很大的误区不要认为没有查询字符串就是RESTful API,也不要认为用了查询字符串就不是RESTful API,更不要认为用了JSON传输的API就是RESTful API。 本篇将带你了解RESTful并用SpringBoot实战RESTful API. 一、REST介绍 REST涉及一些概念性的东西可能比较多,在实战RESTful API之前,要对REST相关的知识有个系统的认知。 REST的诞生 REST(英文:Representational State Transfer,简称REST,直译过来表现层状态转换)是一种软件架构风格、设计风格,而不是标准,只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁,更有层次,更易于实现缓存等机制。 它首次出现在 2000 年 Roy Thomas Fielding 的博士论文中,这篇论文定义并详细介绍了表述性状态转移(Representational State Transfer,REST)的架构风格,并且描述了 如何使用 REST 来指导现代 Web 架构的设计和开发。用他自己的原话说: 我写这篇文章的目的是:在符合架构原理前提下,理解和评估基于网络的应用软件的架构设计,得到一个功能强、性能好、适宜通信的架构。 需要注意的是REST并没有一个明确的标准,而更像是一种设计的风格,满足这种设计风格的程序或接口我们称之为RESTful(从单词字面来看就是一个形容词)。所以RESTful API 就是满足REST架构风格的接口。 Fielding博士答辩 Fielding博士当时提出的是REST架构在很久的时间内并没有被关注太多,而近些年REST在国内才变得越来越流行。下面开始详细学习REST架构特征。 REST架构特征 既然知道REST和RESTful的联系和区别,现在就要开始好好了解RESTful的一些约束条件和规则,RESTful是一种风格而不是标准,而这个风格大致有以下几个主要特征: 以资源为基础:资源可以是一个图片、音乐、一个XML格式、HTML格式或者JSON格式等网络上的一个实体,除了一些二进制的资源外普通的文本资源更多以JSON为载体、面向用户的一组数据(通常从数据库中查询而得到)。统一接口: 对资源的操作包括获取、创建、修改和删除,这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。换言而知,使用RESTful风格的接口但从接口上你可能只能定位其资源,但是无法知晓它具体进行了什么操作,需要具体了解其发生了什么操作动作要从其HTTP请求方法类型上进行判断。具体的HTTP方法和方法含义如下: GET(SELECT):从服务器取出资源(一项或多项)。 POST(CREATE):在服务器新建一个资源。 PUT(UPDATE):在服务器更新资源(客户端提供完整资源数据)。 PATCH(UPDATE):在服务器更新资源(客户端提供需要修改的资源数据)。 DELETE(DELETE):从服务器删除资源。 当然也有很多在具体使用的时候使用PUT表示更新。从请求的流程来看,RESTful API和传统API大致架构如下: URI指向资源:URI = Universal Resource Identifier 统一资源标志符,用来标识抽象或物理资源的一个紧凑字符串。URI包括URL和URN,在这里更多时候可能代指URL(统一资源定位符)。RESTful是面向资源的,每种资源可能由一个或多个URI对应,但一个URI只指向一种资源。 无状态:服务器不能保存客户端的信息, 每一次从客户端发送的请求中,要包含所有必须的状态信息,会话信息由客户端保存, 服务器端根据这些状态信息来处理请求。当客户端可以切换到一个新状态的时候发送请求信息, 当一个或者多个请求被发送之后, 客户端就处于一个状态变迁过程中。每一个应用的状态描述可以被客户端用来初始化下一次的状态变迁。 REST架构限制条件 Fielding在论文中提出REST架构的6个限制条件,也可称为RESTful 6大原则, 标准的REST约束应满足以下6个原则: 客户端-服务端(Client-Server): 这个更专注客户端和服务端的分离,服务端独立可更好服务于前端、安卓、IOS等客户端设备。 无状态(Stateless):服务端不保存客户端状态,客户端保存状态信息每次请求携带状态信息。 可缓存性(Cacheability):服务端需回复是否可以缓存以让客户端甄别是否缓存提高效率。 统一接口(Uniform Interface):通过一定原则设计接口降低耦合,简化系统架构,这是RESTful设计的基本出发点。当然这个内容除了上述特点提到部分具体内容比较多详细了解可以参考这篇REST论文内容。 分层系统(Layered System):客户端无法直接知道连接的到终端还是中间设备,分层允许你灵活的部署服务端项目。 按需代码(Code-On-Demand,可选):按需代码允许我们灵活的发送一些看似特殊的代码给客户端例如JavaScript代码。 REST架构的一些风格和限制条件就先介绍到这里,后面就对RESTful风格API具体介绍。 二、RESTful API设计规范 既然了解了RESTful的一些规则和特性,那么具体该怎么去设计一个RESTful API呢?要从URL路径、HTTP请求动词、状态码和返回结果等方面详细考虑。至于其他的方面例如错误处理、过滤信息等规范这里就不详细介绍了。 URL设计规范 URL为统一资源定位器 ,接口属于服务端资源,首先要通过URL这个定位到资源才能去访问,而通常一个完整的URL组成由以下几个部分构成: URI=scheme"://"host":"port"/"path["?"query]["#"fragment] scheme: 指底层用的协议,如http、https、ftphost: 服务器的IP地址或者域名port: 端口,http默认为80端口path: 访问资源的路径,就是各种web 框架中定义的route路由query: 查询字符串,为发送给服务器的参数,在这里更多发送数据分页、排序等参数。fragment: 锚点,定位到页面的资源 我们在设计API时URL的path是需要认真考虑的,而RESTful对path的设计做了一些规范,通常一个RESTful API的path组成如下: /{version}/{resources}/{resource_id} version:API版本号,有些版本号放置在头信息中也可以,通过控制版本号有利于应用迭代。resources:资源,RESTful API推荐用小写英文单词的复数形式。resource_id:资源的id,访问或操作该资源。 当然,有时候可能资源级别较大,其下还可细分很多子资源也可以灵活设计URL的path,例如: /{version}/{resources}/{resource_id}/{subresources}/{subresource_id} 此外,有时可能增删改查无法满足业务要求,可以在URL末尾加上action,例如 /{version}/{resources}/{resource_id}/action 其中action就是对资源的操作。 从大体样式了解URL路径组成之后,对于RESTful API的URL具体设计的规范如下: 不用大写字母,所有单词使用英文且小写。 连字符用中杠"-"而不用下杠"_" 正确使用"/"表示层级关系,URL的层级不要过深,并且越靠前的层级应该相对越稳定 结尾不要包含正斜杠分隔符"/" URL中不出现动词,用请求方式表示动作 资源表示用复数不要用单数 不要使用文件扩展名 HTTP动词 在RESTful API中,不同的HTTP请求方法有各自的含义,这里就展示GET,POST,PUT,DELETE几种请求API的设计与含义分析。针对不同操作,具体的含义如下: GET /collection:从服务器查询资源的列表(数组)GET /collection/resource:从服务器查询单个资源POST /collection:在服务器创建新的资源PUT /collection/resource:更新服务器资源DELETE/collection/resource:从服务器删除资源 在非RESTful风格的API中,我们通常使用GET请求和POST请求完成增删改查以及其他操作,查询和删除一般使用GET方式请求,更新和插入一般使用POST请求。从请求方式上无法知道API具体是干嘛的,所有在URL上都会有操作的动词来表示API进行的动作,例如:query,add,update,delete等等。 而RESTful风格的API则要求在URL上都以名词的方式出现,从几种请求方式上就可以看出想要进行的操作,这点与非RESTful风格的API形成鲜明对比。 在谈及GET,POST,PUT,DELETE的时候,就必须提一下接口的安全性和幂等性,其中安全性是指方法不会修改资源状态,即读的为安全的,写的操作为非安全的。而幂等性的意思是操作一次和操作多次的最终效果相同,客户端重复调用也只返回同一个结果。 上述四个HTTP请求方法的安全性和幂等性如下: HTTP Method 安全性 幂等性 解释 GET 安全 幂等 读操作安全,查询一次多次结果一致 POST 非安全 非幂等 写操作非安全,每多插入一次都会出现新结果 PUT 非安全 幂等 写操作非安全,一次和多次更新结果一致 DELETE 非安全 幂等 写操作非安全,一次和多次删除结果一致 状态码和返回数据 服务端处理完成后客户端也可能不知道具体成功了还是失败了,服务器响应时,包含状态码和返回数据两个部分。 状态码 我们首先要正确使用各类状态码来表示该请求的处理执行结果。状态码主要分为五大类: 1xx:相关信息2xx:操作成功3xx:重定向4xx:客户端错误5xx:服务器错误 每一大类有若干小类,状态码的种类比较多,而主要常用状态码罗列在下面: 200OK - [GET]:服务器成功返回用户请求的数据,该操作是幂等的(Idempotent)。201CREATED - [POST/PUT/PATCH]:用户新建或修改数据成功。202Accepted - [*]:表示一个请求已经进入后台排队(异步任务)204NO CONTENT - [DELETE]:用户删除数据成功。400INVALID REQUEST - [POST/PUT/PATCH]:用户发出的请求有错误,服务器没有进行新建或修改数据的操作,该操作是幂等的。401Unauthorized - [*]:表示用户没有权限(令牌、用户名、密码错误)。403Forbidden - [*]表示用户得到授权(与401错误相对),但是访问是被禁止的。404NOT FOUND - [*]:用户发出的请求针对的是不存在的记录,服务器没有进行操作,该操作是幂等的。406Not Acceptable - [GET]:用户请求的格式不可得(比如用户请求JSON格式,但是只有XML格式)。410Gone -[GET]:用户请求的资源被永久删除,且不会再得到的。422Unprocesable entity - [POST/PUT/PATCH]当创建一个对象时,发生一个验证错误。500INTERNAL SERVER ERROR - [*]:服务器发生错误,用户将无法判断发出的请求是否成功。 返回结果 针对不同操作,服务器向用户返回数据,而各个团队或公司封装的返回实体类也不同,但都返回JSON格式数据给客户端。 第三关 一个RESTful API案例 上面讲了RESTful理论知识,下面动手实现一个小案例吧! 预备 在本案例的实战中,我们访问的RESTful接口都是对数据库真实的操作,新建数据库,创建一个数据库和表(根据自己喜好)。 选择Maven依赖的时候,只需要勾选其中Spring的Web模块、MySQL驱动以及MyBatis框架。 本案例的POJO创建Dog.java实体对象,其具体构造为: packagecom.restfuldemo.pojo;publicclassDog{privateintid;//唯一id标识privateStringname;//名称privateintage;//年龄//省略getset} 上面创建好了项目,我们就开始构建RESTful风格的API。在具体构建RESTful API的时候,需要对各种请求有更细致的认知,当然,本案例在实现各种请求的时候为了演示的便捷并没有完全遵循RESTful API规范,例如版本号等信息这里就不添加了,案例更侧重于使用SpringBoot实现这个接口。 本案例实现对dog资源的增删改查,如下是非RESTful 和RESTful接口对比: API name 非 RESTful RESTful 获取dog /dogs/query/{dogid} GET:/dogs/{dogid} 插入dog /dogs/add POST:/dogs 更新dog /dogs/update/{dogid} PUT:/dogs/{dogid} 删除dog /dods/delete/{dogid} DELETE:/dogs/{dogid} 另外在使用postman进行发送请求的时候,有三种常用的文件类型传递到后端: form-data:就是form表单中的multipart/form-data,会将表单数据处理为一条信息,用特定标签符将一条条信息分割开,而这个文件类型通常用来上传二进制文件。 x-www-form-urlencoded:就是application/x-www-form-urlencoded,是form表单默认的encType,form表单会将表单内的数据转换为键值对,这种格式不能上传文件。 raw:可以上传任意格式的文本,可以上传Text,JSON,XML等,但目前大部分还是上传JSON格式数据。当后端需要接收JSON格式数据处理的时候,可以采用这种格式来测试。 因为GET请求查询参数在URL上,其他类型请求使用x-www-form-urlencoded方式向后端传值。 GET POST PUT DELETE请求 GET请求用来获取资源:GET请求会向数据库发索取数据的请求,从而来获取资源,该请求就像数据库的select操作一样,只是用来查询数据,不会影响资源的内容。无论进行多少次操作,结果都是一样的。 并且GET请求会把请求的参数附加在URL后面,但是不同的浏览器对其有不同的大小长度限制。 在本案例中,我们设计两个GET请求的API。GET /dogs:用来返回dog资源的列表。GET /dogs/{dogid}:用来查询此id的单个dog资源。 POST请求用来新增一个资源: POST请求向服务器发送数据,但是该请求会改变数据的内容(新添),就像数据库的insert操作一样,会创建新的内容。且POST请求的请求参数都是请求体中,其大小是没有限制的。 在本案例中,我们设计以下POST请求的API。POST /dogs:服务端新增一个dog资源。 PUT请求用来更新资源,PUT请求是向服务器端发送数据的, 与POST请求不同的是,PUT请求侧重于数据的修改,就像数据库中update一样,而POST请求侧重于数据的增加。 在本案例中,我们设计以下POST请求的API。PUT /dogs/{dogid}:用来更新此id的单个dog资源。 DELETE 请求用来删除资源,DELETE请求用途和它字面意思一致,用来删除资源。和数据库中delete相对应。 在本案例中,我们设计以下DELETE请求的API。DELETE /dogs/{dogid}:用来删除此id的单个dog资源。 对应的Mapper文件为: packagecom.restfuldemo.mapper;importcom.restfuldemo.pojo.Dog;importorg.apache.ibatis.annotations.*;importjava.util.List;@MapperpublicinterfaceDogMapper{@Select("select*fromdog")List<Dog>getAllDog();@Select("select*fromdogwhereid=#{id}")DoggetDogById(@Param("id")intid);@Insert("insertintodog(name,age)values(#{name},#{age})")booleanaddDog(Dogdog);@Update("updatedogsetname=#{name},age=#{age}whereid=#{id}")booleanupdateDog(Dogdog);@Delete("deletefromdogwhereid=#{id}")booleandeleteDogById(intid);} 对应controller文件为: packagecom.restfuldemo.controller;importcom.restfuldemo.mapper.DogMapper;importcom.restfuldemo.pojo.Dog;importorg.springframework.beans.factory.annotation.Autowired;importorg.springframework.web.bind.annotation.*;importjava.util.Arrays;importjava.util.List;@RestControllerpublicclassTestController{@Autowired(required=false)DogMapperdogMapper;@GetMapping("dogs")publicList<Dog>getDogs(){returndogMapper.getAllDog();}@GetMapping("dogs/{id}")publicDoggetDogById(@PathVariable("id")intid){Dogdog=dogMapper.getDogById(id);returndog;}@PostMapping("dogs")publicbooleanaddDog(Dogdog){returndogMapper.addDog(dog);}@PutMapping("dogs/{id}")publicbooleanupdateDog(@PathVariable("id")intid,@RequestParam("name")Stringname,@RequestParam("age")intage){Dogdog=dogMapper.getDogById(id);dog.setName(name);dog.setAge(age);returndogMapper.updateDog(dog);}@DeleteMapping("dogs/{id}")publicbooleandeleteDog(@PathVariable("id")intid){returndogMapper.deleteDogById(id);}} 经过笔者测试一切都是ok的,如果要项目源文件请联系笔者发你哈! 总结 RESTful风格的API 固然很好很规范,但大多数互联网公司并没有按照或者完全按照其规则来设计,因为REST是一种风格,而不是一种约束或规则,过于理想的RESTful API 会付出太多的成本。 比如RESTful API也有一些缺点 比如操作方式繁琐,RESTful API通常根据GET、POST、PUT、DELETE 来区分操作资源的动作,而HTTP Method 本身不可直接见,是隐藏的,而如果将动作放到URL的path上反而清晰可见,更利于团队的理解和交流。 并且有些浏览器对GET,POST之外的请求支持不太友好,还需要特殊额外的处理。 过分强调资源,而实际业务API可能有各种需求比较复杂,单单使用资源的增删改查可能并不能有效满足使用需求,强行使用RESTful风格API只会增加开发难度和成本。 所以,当你或你们的技术团队在设计API的时候,如果使用场景和REST风格很匹配,那么你们可以采用RESTful 风格API。但是如果业务需求和RESTful风格API不太匹配或者很麻烦,那也可以不用RESTful风格API或者可以借鉴一下,毕竟无论那种风格的API都是为了方便团队开发、协商以及管理,不能墨守成规。 到这里RESTful API的介绍和实战就结束啦,本篇首先从RESTful的一些特点进行介绍,再到SpringBoot实战RESTful API,最后也说了一些RESTful API并不完美的地方,相信睿智的你对RESTful 一定有了很深刻的理解。在以后项目的API设计上定能有所优化。 不同的人对RESTful API可能有着不同的理解,但存在即合理,RESTful API有着其鲜明的优势和特点,目前也是一种API设计的主要选型之一,所以掌握和理解RESTful API还是相当重要的! 推荐阅读 「经历分享」这些图灵奖主原来就藏在身边 16张图带你彻底搞懂基数排序 「干货总结」程序员必知必会的十大排序算法 图解|双轴快排分析 「五大常用算法」一文图解分治算法和思想 原创不易,bigsai请你帮两件事帮忙一下: 点赞在看, 您的肯定是我在平台创作的源源动力。 微信搜索「bigsai」,关注我的公众号,不仅免费送你电子书,我还会第一时间在公众号分享知识技术。加我还可拉你进力扣打卡群一起打卡LeetCode。 记得关注、咱们下次再见! 本文分享自微信公众号 - bigsai(bigsai)。如有侵权,请联系 support@oschina.cn 删除。本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

优秀的个人博客,低调大师

Python爬取201865条《隐秘的角落》弹幕,发现看剧不如爬山?

云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 最近又火了一部国产剧:《隐秘的角落》。 如果你没看过,那可能会对朋友圈里大家说的“一起去爬山”、“小白船”、“还有机会吗”感到莫名其妙。 暑期推荐旅游(来源微博) 小五在这个端午假期也赶紧刷完了本剧,必须要写篇文章了。 由于《隐秘的角落》是在爱奇艺独播,所以数据从爱奇艺下手最直接。 如果没爬过爱奇艺,可以考虑使用豆瓣、微博、知乎(电视剧数据分析 · 万能三件套)的数据。 爬虫 剧很精彩,但追剧界有句俗话说得好:“弹幕往往比剧更精彩”,为了让精彩延续下去,我终究没能忍住对弹幕下手。[1]爱奇艺的弹幕数据是以 .z 形式的压缩文件存在的,先获取 tvid 列表,再根据 tvid 获取弹幕的压缩文件,最后对其进行解压及存储,大概就是这样一个过程。这里参考了“数据兔小白[2]的代码,我又修改后实现分集爬取所有弹幕。 注:避免引起不必要的麻烦,本爬虫仅指出关键步骤,不再公开提供。 共爬取得到201865 条《隐秘的角落》弹幕数据。 弹幕发射器 按照用户id分组并对弹幕id计数,可以得到每位用户的累计发送弹幕数。 累计发送弹幕数的用户 danmu_counts = df.groupby('uid')['contentsId'].count().sort_values(ascending = False).reset_index()danmu_counts.columns = ['用户id','累计发送弹幕数']danmu_counts.head() 累计发送弹幕数用户top5 第一名竟然发送了2561条弹幕,这只是一部12集的网剧啊。 难道他/她是水军?每条都发的差不多?df_top1 = df[df['uid'] == 1810351987].sort_values(by="likeCount",ascending = False).reset_index()df_top1.head(10) 然而并不是,每一条弹幕都是这位观众的有感而发,可能他/她只是在发弹幕的同时顺便看看剧吧。 这位“弹幕发射器”朋友,在每一集的弹幕量又是如何呢? 分集&平均弹幕量 是不是通过上图可以侧面说明个别剧集的戏剧冲突更大,更能引发观众吐槽呢?“弹幕发射器”同志,11、12集请加大输出! 这些弹幕大家都认同 抛开“弹幕发射器”同志,我们继续探究一下分集的弹幕。 看看每一集当中,哪些弹幕大家都很认同(赞)? df_like = df[df.groupby(['tv_name'])['likeCount'].rank(method="first", ascending=False)==1].reset_index()[['tv_name','contents','likeCount']]df_like.columns = ['剧集','弹幕','赞']df_like 每一集中点赞最多的弹幕 每一集的最佳弹幕都是当集剧情的浓缩,这些就是观众们票选出来的梗(吐槽)啊!应该不算剧透吧,不算吧,不算吧实在不行我请你去爬山也可 朝阳东升 除了剧本、音乐等,“老戏骨”和“小演员”们的演技也获得了网友的一致好评。 这部剧虽然短短12集,但故事线不仅仅在一两个人身上。每个人都有自己背后的故事,又因为种种巧合串联在一起,引发观众的持续性讨论。 我们统计一下演员们在弹幕中的出现次数,看看剧中的哪些角色大家提及最多。 a = {'张东升':'东升|秦昊|张老师', '朱朝阳':'朝阳', '严良':'严良', '普普':'普普', '朱永平':'朱永平', '周春红':'春红|大娘子', '王瑶':'王瑶', '徐静':'徐静|黄米依', '陈冠声':'王景春|老陈|陈冠声', '叶军':'叶军|皮卡皮卡', '马主任':'主任|老马', '朱晶晶':'晶晶','叶驰敏':'叶驰敏'} a = {'张东升':'东升|秦昊|张老师', '朱朝阳':'朝阳', '严良':'严良', '普普':'普普', '朱永平':'朱永平', '周春红':'春红|大娘子', '王瑶':'王瑶', '徐静':'徐静|黄米依', '陈冠声':'王景春|老陈|陈冠声', '叶军':'叶军|皮卡皮卡', '马主任':'主任|老马', '朱晶晶':'晶晶','叶驰敏':'叶驰敏'}for key, value in a.items(): df[key] = df['contents'].str.contains(value) staff_count = pd.Series({key: df.loc[df[key], 'contentsId'].count() for key in a.keys()}).sort_values() 先计算出现次数,再利用pyecharts制作极坐标图。 弹幕中提到的主要演员 比较让我疑惑的三个小孩当中的朱朝阳提及量这么低,按理说应该与其其他两位大体相当啊。又去源数据看了一遍,提及朱朝阳(朝阳)的弹幕确实很少,因为大部分在弹幕中观众一般就叫他“学霸”、“儿子”之类的了。 词云 总所周知,一篇数分文章不能少了词云。每篇的词云都尽量跟上篇文章不同,这次我采用的是stylecloud,它算是wordcloud词云包的升级版,看起来美观多了。import stylecloudfrom IPython.display import Image stylecloud.gen_stylecloud(text=' '.join(text1), collocations=False, font_path=r'‪C:\Windows\Fonts\msyh.ttc', icon_name='fas fa-play-circle',size=400, output_name='隐秘的角落-词云.png') Image(filename='隐秘的角落-词云.png') 20万条弹幕词云 除了主角的名字以外,在这部以“孩子”为主题的剧中,对孩子的思想、行为的探讨占据重要部分,另外,剧中从年长的戏骨到年幼的孩子,每一个人都贡献了高光的演技,对他们演技的称赞也成为高频词汇。而最出圈的“爬山”梗,更是被频频提及。 一起爬山吗? 从《无证之罪》到《隐秘的角落》,都在证明悬疑犯罪题材在当下并非没有市场,要收获高人气高口碑,如何传播与营销终归只是手段,越来越多的团队沉下心来打磨精品剧集,观众才会愿意为剧买单,让“爬山”这样的梗一步步“出圈”。 本文相关数据和可视化源码下载:https://alltodata.cowtransfer.com/s/5b483c08987243 【云栖号在线课堂】每天都有产品技术专家分享!课程地址:https://yqh.aliyun.com/live 立即加入社群,与专家面对面,及时了解课程最新动态!【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK 原文发布时间:2020-06-29本文作者:朱小五本文来自:“AI科技大本营”,了解相关信息可以关注“AI科技大本营”

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册