然而随着我发现这个项目不仅有学习的价值，还可以真正投入到实际项目的使用当中，于是后面又对PermissionX进行了多个版本的迭代，目前已经成为了一个非常稳定和方便的权限请求库。...当时我的想法是，PermissionX只定义显示对话框，关闭对话框等必要的接口，至于实现方面不做任何限制，你可以用Dialog，也可以用DialogFragment，甚至可以用PopupWindow，或者是完全自定义的控件都行...可以看到，使用了自定义对话框的方式之后，我们可以自由地控制界面上的元素和内容，用户体验也得到了明显的改善。 不过，即使这样，还是有朋友在评论区里留言，嫌这个对话框太丑了（1人嫌丑，42人点赞）。 ?...因为在界面上其实并不需要将deniedList中的权限全部显示出来，而是只显示要申请的权限组名即可，这样可以让界面更精简。...另外我们还可以通过串接一个explainReasonBeforeRequest()方法，让权限提醒对话框在开始请求权限之前显示，这样就能实现先解释申请原因，再执行请求权限的功能。
分享一个 linux 技能飞书话题群的一个问题。 ---- 问： 在linux系统里，普通用户目录是在 /home 下，root用户目录在 /root，因此全部用户共享目录的。...那如果我们要装一个东西的话，是不是只用装一遍？（比如说ohmyzsh之类的） 我之前在自己服务器上，每次都需要安装两遍，一次只有当前那个用户生效，这是为什么呢？...---- 答： 不一定，当我们说我们在 linux 装了一个东西，指的是：「我们装了一个命令，可全局执行」。此时是将该命令放在了全局执行目录（或者将该命令目录放在了 $PATH）。...哦对，PATH 该路径列表可自定义，而每一个用户都可以有独立的 PATH 环境变量。...所以，要看一个命令是所有用户共享还是仅对当前用户有效，具体要看该命令是怎么装的，可以看看 which command 进一步排查。
QPS拉升会导致写入评论以及评论数等缓存一致性行为受到影响 这里引申出两种方案: 读扩散和写扩散 问题 读扩散 读扩散实现: 订阅者去拉取 feeds 时，订阅者主动去查询关注列表，逐一请求出所有关注人的发件箱中未阅读过的...日活跃为3级，收件箱长度保留1000条(节约存储成本) 冷热分离+预拉取-收件箱过大问题 如果用户关注的列表过多，会导致这个用户的收件箱列表成为一个大 key， 这类用户的性能上会有影响 为了避免用户的收件箱在...redis 中无限增长， 可以对活跃用户做一个限制， 默认最多刷新1000条 如果用户持续拉取内人， 超过1000条， 可以退化为拉模式， 去关注者的发件箱拉取(每次拉取100条来更新用户的收件箱)...在写扩散的过程中， 只添加新的 feed 到列表， 删除超过限制的 feed(写入新的 100条， 删除最老的 100条) 软删除+懒删除-写扩散下删除问题 写扩散模式下，用户发布消息可以慢慢扩散出去，...先从关注列表中读取到自己的粉丝列表，以及判断自己是否是大V。 将自己的Feed消息写入个人页Timeline（发件箱）。 如果是大V，此时拉取活跃用户；如果是普通用户，则拉取自己的所有粉丝用户。
部署无误之后，每次页面加载都会动态去拉取一次最新的评论，并呈现给用户。...优点：每次打开页面用户都能看到最新评论； 缺点：每次打开页面都会动态拉取评论，降低了纯静态效果，拉取的评论分页有点误差（影响不大）。...分析了这个过程，我们可以发现一个特征关键字，那就是分页地址后面的 comment-page-xx ！这是个好东西，因为我可以在云加速和本地的缓存中排除这个关键词的缓存即可！...于是就有 2 种情况：第一种，文章评论数量还不够生成分页，那这时候只要拉取 comment-page-1 就可以了；第二种，评论已经存在分页，那么只要拉取这个 comment-page-【页码】即可，所以...那么，js 如何判断评论是否有分页了呢？很简单，先分析下网页代码： 可以发现分页是有分页对应的 class 的，那么 js 只要判断这个 class 是否存在就好啦！
我们将总结代码评审作为学习和团队纽带工具的益处。 准备一个拉取请求用来评审 针对拉取请求作者的经验教训。有一些经验法则一致指出，准备一个拉取请求有助于使评审更顺利。 评审代码——人性化！...尽可能使拉取请求原子化在 Shopify，他们建议保持拉取请求很小——这有助于评审者深入研究，并将它作为他们工作日中的一件原子性工作完成。在实践中，这意味着将你的拉取请求限制在单个关注点上。...你可以在 Kickstarter Engineering、Gusto Engineering 和 Palantir 的博客中找到几乎相同的建议。 提供一个有用的拉取请求描述"给你的评审者一张地图"。...确实，你应该挑选最熟悉你所修改的代码部分的同事。但即使是几句话来描述拉取请求的为什么 why/ 是什么 what/ 在哪里 where，也可以极大地帮助你的评审者导航到你的拉取请求。...批准要有倾向性；弄清楚是否有些事可以稍后再修复——作为一名评审者，你不一定要做一个有权阻塞任何拉取请求的守门员。
点赞和踩：用户可以给评论点赞或踩，以表达自己的喜好。 评论拉取：评论需要按照时间或热度排序，并且支持分页显示。...（可用地址存储在 Zookeeper 中），拿到 TCP 地址后再发起请求连接到集群的某一台服务器上。...当查询词语是否为敏感文字时，用相同的哈希函数进行映射，如果映射的位置有一个不为 1，说明该文字一定不存在于集合元素中。反之，如果 3 个点都为 1，则判定元素存在于集合中。...用户限制 除了从评论信息上加以限制，我们也可以从用户侧来限制： 用户认证：要求用户登录后才能发布评论，降低匿名评论的风险。...我们可以在评论表（comment）里面新增一个表示情感正负倾向的字段 emotion，当主播打开喜好开关后，只拉取 emotion 为 TRUE 的评论信息，将“嫌贵的用户”或者 “评价为负面” 的评论设置为不可见
举个例子：比如你在某个视频或某篇文章下发表了评论，有 100 个人给你的评论点了赞，那么你希望消息页面呈现的是一个一个用户给你点赞的提醒，还是像以下聚合之后的提醒： ?...：单用户 single；全体用户 all，vip 用户，具体类型各位小伙伴可以根据自己的需求选择 state BOOLEAN 是否已被拉取过，如果已经拉取过，就无需再次拉取 recipient_id LONG...用户需要查看系统通知时，从 t_user_system_notice 表中查询就行了。 注意： 因为一次拉取的数据量可能很大，所以两次拉取的时间间隔可以设置的长一些。...拉取 t_manager_system_notice 表中的通知时，需要判断 state，如果已经拉取过，就不需要重复拉取， 否则会造成重复消费。...所以在选取用户 ID 时，我们可以将用户上次 登录的时间与推送时间做一个比较，如果用户一年未登陆或几个月未登录，我们就不选取其 ID，进而避免 无谓的推送。
在六个小时内，从一个IP地址镜像拉取的请求次数超过固定阈值（匿名用户100次，认证用户200次）后，Docker Hub就会限制其拉取带宽。虽然用户仍然可以拉取到Docker镜像，但是速度要慢得多。...33.png 您还可以在Artifactory中维护自己安全的、私有的Docker镜像中心，以进一步减少对Docker Hub的依赖。...55.png 3、Docker Hub拉取请求 该图显示了在6小时滚动时间内发出的Docker Hub拉取请求的数量。每个栏显示从该小时标记开始的前六个小时内发出的拉取请求的总数。...66.png 该统计信息将帮助您查看您的企业是否接近或超过了Docker Hub限制策略，以及拉取高峰在什么时间。...4、十大用户和IP 这些统计数据按用户和IP地址揭示了Docker仓库的主要用户是谁。如果您发现超出了拉取请求，则此信息可以帮助您确定主要的负责方。
全局配置 全局的一些配置我放在了config.js中，拉取我项目的小伙伴只需要更改里面的配置，就可以一键生成你自己的静态博客了。...github请求限制 client_id: '', client_secret: '', } repo字段中的信息决定了请求会去哪个仓库下拉取issues生成博客，user下的字段定义了首页显示的用户名...信息，如果你在github申请了OAuth app就会拿到俩个东西，带上的话就可以更频繁的请求api，否则github会限制同一个ip下请求调用的次数。...ora是一个命令行提示加载中的插件，可以让我们在异步生成这些内容的时候得到更友好的提示，withOra就是封装了一层，在传入函数的调用前后去启动、暂停ora的提示。...builder逻辑，拉取github blogs生成pages，可以方便调试。
前面两篇讲即时通讯核心技术的文章 《微信为什么不丢消息？》 《http如何像tcp一样实时的收消息？》 反馈还可以，故继续即时通讯这一个系列吧，今天聊聊即时通讯中的“状态”。...不采用轮询拉取，而采用按需拉取，延时拉取的方式，在真正进入一个群时才实时拉取群友的在线状态，是既能满足用户需求（用户感觉是状态是实时、一致的，但其实是进入群才拉取的），又能降低服务器压力。...（2）如果集中推送，“消息风暴扩散系数”过大，容易引发系统抖动；而拉取的方式，可以摊平这个抖动，用户登录时均匀的发起请求 （3）如果集中推送，往往不在意用户是否“在线”，往往会造成大量离线垃圾消息；而拉取的方式...，保证只有在线的用户才会收到请求 （4）… 有不同的建议，欢迎评论讨论。...，可以采用轮询拉取的方式同步 （2）群友的状态，由于消息风暴扩散系数过大，可以采用按需拉取，延时拉取的方式同步 （3）系统消息/开屏广告等对实时性要求不高的业务，可以采用拉取的方式获取消息 （4）“消息风暴扩散系数
而使用 REST 协议进行资源拉取，我们总是会面临一些实际的问题，而 GraphQL 可以在一定程度上解决。...说的没错，所以我们在阐述这些问题的时候，也会附上我们当前基于 REST 的解决方案。 Overfetching： 假如我们定义了一个 /comments 的 API，输出评论列表。...但是也许某一天，我们需要一个评论的精简列表的 API，当前返回内容中，除了 content 以外的其他字段都变成多余了，那么后端开发需要重新定一个 MinimalCommentSerializer 来满足新的需求...在 REST 基础中，我们增加了 fields 参数，并在 DRF Serializer 里做了特殊处理（你可以点击查看源码），实现的具体效果： # 查询 comment，并限制结果返回字段 /api/...在 REST 中，为了这个需求我们可能会额外为 /users 增加一个参数 with_comments # 查询 users，并限制结果返回字段 /api/users?
在发布前一周，他正在审查和合并许多拉取请求。当进行到编写发行说明的时候，他惊讶地发现，项目中的一些拉取请求被删除了！...Jesse Squires推特截图 接着，Jesse Squires发现，事情远没有那么简单，因为他发现相关贡献者的所有痕迹仿佛凭空消失了一样，他们对问题的评论、打开的所有问题和拉取请求等与用户有关的每项活动都不见了...举个例子，Jesse Squires可以在GitHub自动生成的发行说明中看到这行信息： 但是点进去时，唯一能显示的只有这项贡献的合并提交记录，而该用户的账户和拉取请求结果都是404。...这一做法会导致： 1.来自被暂停账户的每个拉取请求都被删除 2.被暂停账户打开的每个问题都被删除 3.被暂停账户的每条评论或讨论都被删除 这也意味着，被暂停账户贡献的所有重要数据全都没了，唯一完好无损的只有原始的项目提交历史...他在博客里更新道，GitHub开发者关系高级总监Martin Woodward联系到了他，告诉他GitHub已经恢复了相关俄罗斯开发者丢失的拉取请求、问题、评论等，用户资料也得到了恢复。
GitHub 官方表示： “开发者（对于移动端版本）的热情太高了！仅在过去几周内，测试版测试人员就对近10万个请求进行了评论、审查和合并。”...通知会显示在一个类似收件箱的界面上，你可以左滑处理，或保存或标记。 ?...随时回应评论、及时处理 issues 你还可以用表情符号对评论做出回复；如果有人依赖于你的问题反馈，你也可以及时处理，方便保持项目的运行。 ?...审查代码、合并拉取请求 该应用程序还允许你查看代码，合并拉取请求，但目前还不支持编辑应用程序中的任何代码。 ?...2018 年 6 月，微软以 75 亿美元的价格收购了 GitHub，尽管该公司没有足够的收入作为盈利报告的一个细列项目。但是，GitHub 仍然是一个庞大的平台——全球有 4000 多万开发者用户！
Alloy 提供了几个示例和 视频 来证实他们的说法，即他们的工具可以使拉取请求中需要审查的代码减少 30%。 工作原理 显然，它的有用性取决于它试图总结的内容。...访问拉取请求会调出一个概述页面，提供 Harding 所谓的“拉取请求当前状态的高级详细信息……以及它与之前提交的拉取请求的比较”。...一个图表显示了拉取请求已打开的天数——甚至允许你将它与存储库中的其他文件进行比较——或者与所有存储库的拉取请求进行比较，甚至“与你所在行业的其他公司进行比较”。...（另一个图表对拉取请求中的测试覆盖率进行了相同的比较。）...在视频演示中，Harding 指出他们的工具还提供了一个视图，仅显示“自上次审查以来的未审查提交” “对于我们团队的工作方式来说，这可能是节省时间最多的单一功能……因为如果你的团队对拉取请求进行了多轮审查
ECS S3 存储支持 下面介绍其中几个新的功能点： 系统级机器人帐号 机器人帐号是不同系统之间认证时使用，在一些使用场景中（如CI/CD），用户可能需要用一个机器人帐号访问多个 Harbor 项目。...在代理项目新建好之后，用户只要有权限访问这个代理项目，就可以通过这个代理拉取 Docker Hub 的容器镜像。 ?...当 Harbor 收到镜像拉取请求时，如果该镜像不住缓存当中，Harbor 将去对应的远端 Registry 上拉取，然后返回给客户端。...Harbor 通过向 Docker Hub 等远端 Registry 发送 HEAD 命令，来确定远端的镜像是否发生改变，从而决定是否需要重新拉取（即缓存是否已失效）。...这样不会触发 Docker Hub 的流量限制，有这方面需求的用户可以考虑使用。
用户可以在观看内容（视频为主）的同时查看其他人对这个视频的评论，而不需要找到对应的评论区查看。现在视频网站基本都已经实现了弹幕，深受年轻用户的追捧和喜爱。...但是受屏幕大小限制，可能另一种弹幕方式更常见常见，例如过重直播软件中，弹幕通常出现在弹幕的左下角的固定区域，从下往上出现。...日迹播放场景中，视频评论也是以弹幕的方式在视频的左下角出现，其形式更像是将评论逐一展示出来。下面详细分析下日迹场景弹幕的实现方式。...二、弹幕分析 日迹弹幕总体可以划分成三个部分：评论数据、展现形式、滚动方式。 评论数据模块，包括拉取逻辑，这个部分跟业务比较相关。...评论的数据，来自用户对日迹的评论，目前来看，评论数据是纯文本，比较简单。拉取逻辑也相对比较简单，就不详细说明。 日迹弹幕的展现形式比较简单，只是展示纯文本，没有比较复杂的展现形式的动画。
其次，广告系统对延时要求非常高，如果每次直接拉取每个好友的实际评论情况，也不切实际。因此，最终选择了用户互动信息实时写入到每个好友身上。...这其实是一个很复杂的问题，主要有这么3个因素要考虑： 前期投放哪些用户，他们最可能参与广告互动？他们最可能带动好友？ 那些确定要投放的用户，他们是否满足拉取条件？是否被用户体验屏蔽掉？...7.朋友圈后台架构支持 在原先朋友圈后台中，每条Feeds的评论点赞信息都是存储在一个objectid上，它存储于kv存储系统中，每次拉取与更新都是对这些数据全存全取。...当有读取时候，则需要将用户每个好友的评论点赞信息都读取出来（可以想想为什么不用上面社交计算中提到的写扩散方式）。...但是这样会引进两个工程问题： 每次读取数据量十分大 后端调用kv扩散出的链接数是随着kv集群规模扩大而扩大的 最终我们通过引入版本号的机制，在手机客户端中存储每次拉取的版本号，并将版本号这种轻量级数据写扩散到所有好友身上
对于用户来说并不友好推模式 另一部分工程师认为在创作者发布文章时就应该将新文章写入到粉丝的关注 Timeline，用户每次阅读只需要到自己的关注 Timeline 拉取就可以了 使用推模型方案创作者每次发布新文章系统就需要写入...推模型的好处在于拉取操作简单高效，但是缺点一样非常突出。 首先，在每篇文章要写入 M 条数据，在如此恐怖的放大倍率下关注 Timeline 的总体数据量将达到一个惊人数字。...通过在应用程序中缓存常用数据或频繁访问的key，可以减少对后端缓存的请求量，提高系统的响应速度和性能。...可以通过设置请求频率限制、缓存数据的过期时间等方式来限制逃逸流量，保护后端系统的稳定性。...这里我们采用多级缓存, 为了效率考虑, 我们采用本地缓存，即应用服务器在内存中缓存特别热门的博客内容，应用构建博客刷新页的时候，会优先检查博客ID对应的博客内容是否在本地缓存中。
重要接口需要对重放攻击进行防御服务端请求伪造程序中如有对外发送请求的功能，必须严格限制发送的目标和内容的类型；对于只需要请求公网的功能点，必须限制其向内网发送请求。...命令注入避免程序直接调用操作系统命令，在执行前必须检查命令中的是否有非法的特殊字符。...这类漏洞经常出现在用户评论的页面，攻击者精心构造XSS代码，保存到数据库中，当其他用户再次访问这个页面时，就会触发并执行恶意的XSS代码，从而窃取用户的敏感信息 DOM型xss 基于dom的漏洞，它的攻击代码并不需要服务器解析响应...重要信息不通过cookie，在请求中以参数形式加入一个随机产生的token，并在服务器验证该token，不正确则拒绝该请。在http头中添加自定义属性并验证。...设置一个域名白名单，判断域名合法性。适用场景：拉取文件或接口资源时没有对导致进行判断导致请求外部传入的恶意地址校验外部传入的域名是否恶意。判断ip是否指向内网。物理隔离下载代理。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
云直播
