知鸦日报2022-12-15

组件在保证合理性的同时，还需要满足复用性、易用性，以便更好地服务于日常的设计需求。所以在组件维护过程中我们不可避免的需要考虑复用性和易用性二者之间的平衡。

不同于我们常见的财务指标和运营指标，体验度量体系是动态的，它需要伴随品牌和企业商业目标的迭代、受众喜好的变迁、科技发展等因素进行不断的调整。

抽奖，是一种典型的互动玩法形式。无论是大V的粉丝抽奖，还是活动会场的参与抽奖，这种起源于彩票开奖的互动玩法，同时兼顾了高期待感和低预期的特征，让活动在成本控制之余又能有惊喜和引爆点，这样的优势让其在各种运营场景中幻化万千，大行其道。 在闲鱼各种互动场与营销活动中，抽奖自然也是一个相当高频使用的互动玩法。众所周知，越是经典的玩法，业务需求就越发别出机杼，在参与条件、开奖展示、奖品规则等各方面千变万化，闲鱼内典型的就有现金夺宝、低碳双十一抽iphone、旧衣回收抽锦鲤等，不胜枚举。

本文介绍了数据库发布系统从0到1建设过程，以及遇到的问题和解决方案。

2021 年 10 月 5 日 Google 发布 Android12 操作系统，安全性和隐私性大幅提升，本文主要介绍流利说各APP适配Android12操作系统的改动范围和实际情况。

In this blog, we share how we improved the daily edit-build-run developer experience using DevPods, our remote development environment. We will start with some of the initial challenges, the pain points we addressed with Devpod, our architecture, and some of our recent successes in terms of adoption and cost reduction. We will finally leave you with some thoughts around the future of remote development at Uber.

什么是融合通信呢？顾名思义，融合通信的核心是融合，它涵盖了多种通信技术，比如 IM、RTC、白板、直播、点播、PSTN 等，融合可以从两个方面理解，首先是业务的融合，也就是从业务方的视角来看，作为一个业务的开发者可能需要使用多种通信技术，才能实现对应的业务逻辑；其次是技术的融合，从融合通信的技术提供方的角度来看，它需要我们把多种通信技术在底层打通，通过底层的深度融合，这样才能方便业务使用者在上层可以更简单易用的去使用我们的融合通信技术，来实现他的业务逻辑。

本文主要从标签的构建，标签的生产加工，存储设计， 用户洞察，用户分群以及ID-MAPPING等几个方面阐述转转用户画像平台的建设和实践。

在文章中从两个阶段讲述了建模的一些方法，包括业务概念建模和系统建模。

新接到一个需求，需要APP内的某些功能，能够把入口添加到桌面，点击桌面到入口可以直接跳转APP对应界面（类似于下面这张示例图），于是就做了一番调研。

其实很多APP目前都已经实现了类似的功能，比如支付宝、云闪付等等，其中的每一个独立功能都可以单独添加到桌面，所以网上有很多实现的方法，笔者做的是整理和试错。

一年一度的双十一又要来了，自2008年双十一以来，在每年双十一超大规模流量的冲击上，蚂蚁金服都会不断突破现有技术的极限。2010年双11的支付峰值为2万笔/分钟，全天1280万笔支付，这个数字到2017双11时变为了25.6万笔/秒，全天14.8亿笔。在如此之大的支付TPS背后除了削峰等锦上添花的应用级优化，最解渴最实质的招数当数基于分库分表的单元化了，蚂蚁技术称之为LDC（逻辑数据中心）。本文不打算讨论具体到代码级的分析，而是尝试用最简单的描述来说明其中最大快人心的原理。

本文阐述了一种将分层设计和DDD领域设计思想应用于微服务体系架构的方案实践，也是个人的最佳实践。对于大部分互联网公司来说，我们主张将其Web服务架构分为五层：基础设施层、领域服务层、应用服务层、网关层和用户界面层（表示层）。领域服务层和应用服务层均可以采用微服务设计进行拆分，其中领域服务层将按照DDD领域设计进行领域划分，设计为一个个领域模块微服务，每个微服务高度内聚，仅关注自己的业务，领域服务间通过接口调用进行松耦合。这种设计方案可以大大简化大系统，并且在后期的维护中优势会日渐凸显，然而把大系统分而治之拆成微服务同时也对架构师和开发人员提出了更高的要求。第2部分介绍了相关背景，接着第3部分探讨了分层设计以及每一层的功能，第4部分结合微服务和DDD对领域服务层进行服务模块划分和设计。第5部分则就分层设计和DDD领域设计中常见的问题进行了整理。

实现支持分支路径的图调度框架，解决普通图调度框架可扩展性差的问题。

本文会详细介绍vivo在容器集群高可用建设中的具体实践，包括在容器集群高可用建设、容器集群自动化运维、容器平台架构升级、容器平台能力增强、容器生态打通等层面的打磨和建设。

从定义上讲，表达式是由代表量的符号和代表运算的符号组成的符合规则的组合。

目前会员权益业务已经步入成熟期，自有场用户已经趋于饱和状态，而新的突破口是利用权益和积分杠杆来撬动商城场的用户，达到金融App用户增长，能撬动多少用户就要联合金融各业务线、利用权益来进行用户的渗透，而每个业务线对权益的渗透过程，都有着各自的利益点和独到之处。因此权益系统能否支持“业务规则类需求”的灵活定制占据举足轻重的地位。如何解决规则开发的效率问题，最大化解放开发团队成为目前最大的技术挑战点。规则引擎作为特定领域工具，顺理成章的成为这个挑战点的“关键解法”。

有了明确的目标和诉求后，本文调研了常见的规则引擎系统，对Drools、Urule、Aviator、QLExpress等功能做了深入的源码研究，结合目前的业务场景开发了一款适合自身业务功能的规则引擎：ZCube，它既包含了丰富的可视化规则建模设计器，如：脚本式、向导式等，又支持高可用易扩展的架构体系。支持将多个规则打包为知识包文件，在管控平台和业务系统之间进行灰度发布推送、全量发布推送、推送轨迹管理、版本管理、历史版本回退以及知识包执行告警、健康度监控等，实现了让业务规则以知识的形式保存在知识库中，可以在规则发生变动时轻易做出修改，结合后管下发能力实现规则热插拔和热更新。同时可视化界面更易于理解，可以有效地弥补业务分析师和开发人员之间的沟通问题。

组件到底什么时候会渲染？React.memo 到底要不要用？本文将以 React 更新流程为基础，层层递进，将性能优化相关的用法原理串联起来，帮助读者搞明白为什么以及如何进行性能优化。

染色环境现阶段解决了测试环境冲突和测试环境稳定性的问题，并且相较之前多套独立环境的方案，在成本上也有比较大的节省。后续得物也会尝试用染色的能力解决生产灰度发布问题，相信也会有不错的效果。

本文探索了通过数据结构的极致优化，实现广告检索系统倒排召回无截断。

待人真诚，但不必执着，人这一辈子活在机缘里，而不是关系里。

以OKR理念为基础，结合团队实际情况，摸索出了一套适合自身的OKR制定方法。

身边感染的人一个接一个，阳的人在等着康复，剩下一批人，在等着阳。

即使有人已经康复，也还是会担心重复感染，生怕陷入阳完又阳的循环。

那么重复感染新冠的可能性到底有多高呢？症状会更严重吗？