Drag组件是即将发布的京东开源NutUI 3.0的一个拖拽组件，让我们一起来看看是如何实现的吧。

TURF分析，也称累计不重复到达率和频次分析，是一种研究如何组合资源以达到最大市场覆盖的方法。

随着公司业务的快速发展，埋点数据在业务分析中越来越重要，历史上达达快送的埋点数据一直存在问题，所以需要去对现行埋点框架进行重构。

埋点框架现状为：由业务方触发埋点，开启异步线程，经过数据组装处理后入库同时进行上报，上报结束后捞取数据库中剩余所有埋点的一半再次上报，不对埋点数量进行检查，也不管被捞取的埋点是不是正在上报的埋点，如此循环，且埋点文件分散在多个模块中，相互调用。

9.16号Apple发布了iOS 16.1的第一个Beta版本，截止9.18日京东APP 的单日用户已达4w+。新版本发布后，我们崩溃监控系统监控到了在16.1版本出现了大量导航栏相关的崩溃，崩溃量排到第一，这里介绍下此崩溃问题的解决过程。

在数字化时代的今天，我们都认同数据会创造价值。为了最大化数据的价值，我们不停的建立着数据迁移的管道，从同构到异构，从关系型到非关系型，从云下到云上，从数仓到数据湖，试图在各种场景挖掘数据的价值。而在这纵横交错的数据网络中，逻辑复制扮演着极其重要的角色。

让我们将视角从复杂的网络拉回其中的一个端点，从PostgreSQL出发，对其逻辑复制的原理进行解密。

随着线上即时消费需求增长，线下门店与线上渠道销售采用一盘货模式，本文将为您带来保证库存一致、准确的一体化解决方案。

用户触达：可以简单理解为通过某种方式将消息传递给用户的行为；触达的特定消息从功能上可分展示、引导落地两层。用户触达作为一种产品运营方式，已经融入我们日常生产活动的方方面面。在移动互联网的世界里，我们的产品离不开触达，用户活动也离不开触达。

B端产品相对垂直，服务特定人群的特定需求，功能上会有与众不同之处。单纯按照惯性思维套壳只能让产品“能用”，其中缺少的是一步分析的过程，将功能翻译成易于理解的视觉语言。这次通过一个实际项目中遇到的页面，着重介绍“翻译”的部分，讲解下如何将晦涩难懂的操作流程用视觉语言表达出来。

本文主要讲述在业务复杂化背景下，如何通过技术手段优化系统性能，提升用户体验。重点介绍了方案落地过程中遇到的一些问题和解决方案。

在实际开发中，经常会遇到各种不同的配置文件。通常，程序运行的各种配置从外部读取，以增强应用配置的灵活性。java 生态中的 springboot 提供了这种设计的典范。springboot 的应用程序，默认通过 application.yml 加载配置。默认的 application.yml 文件打进 jar 包，如果想改变程序的行为，可以在jar 包的同级目录下创建 application.yml 文件或者通过参数指定配置文件位置。那么在 rust 生态里有没有办法把默认配置文件打包到二进制文件呢。

我们可以通过rust-embed 第三方库来实现这一效果。

可视化大屏设计中，如何根据需求制定设计方案？

Apache Flink作为Google Dataflow Model的工业级实现，经过多年的发展，如今已经成为流式计算开源领域的事实标准。它具有高吞吐、低时延、原生流批一体、高一致性、高可用性、高伸缩性的特征，同时提供丰富的层级化API、时间窗口、状态化计算等语义，方便用户快速入门实时开发，构建实时计算体系。

古语有云，工欲善其事，必先利其器。要想让大规模、大流量的Flink作业高效运行，就必然要进行调优，并且理解其背后的原理。本文是笔者根据过往经验以及调优实践，结合京东实时计算平台（JRC）背景产出的面向专业人员的Flink流作业调优指南。主要包含以下四个方面：

• TaskManager内存模型调优
• 网络栈调优
• RocksDB与状态调优
• 其他调优项

本文基于Flink 1.12版本。阅读之前，建议读者对Flink基础组件、编程模型和运行时有较深入的了解。

随着到家业务与小时购业务的快速发展，系统迭代日新月异，测试效率面临巨大挑战。通过我们调研和分析，发现人工准备测试数据的工时占整个软件测试周期的30%及以上，且准备测试数据的过程极其枯燥繁琐。如何快速响应各业务方提出的不同场景测试数据支持，是我们面临的一项极大挑战。本文将会带你详细了解京东到家数据构造平台的诞生及应用。

设计师如何快速理解可视化大屏业务？

本文主要基于京东物流的分拣业务平台在生产环境遇到的一些安全类问题，进行定位并采取合适的解决方案进行安全治理，引出对行业内不同业务领域、不同类型系统的安全治理方案的探究，最后笔者也基于自己在金融领域的经验进行了关于API网关治理方案的分享。

京东到家话费券系统对外提供的服务调用频率存在不均衡的情况，比如活动页服务调用量是万级QPS，而其它普通服务的调用量为百级QPS。在业务高峰时，系统会遇到瞬时请求并发量激增的情况，此时系统的线程数量也会急剧增加，造成系统负载增加，性能下降。为此，我们不得不按照业务高峰期的场景进行机器扩容以保证业务高峰时期的服务稳定，但这会导致机器资源利用率整体上不高，该如何解决这个问题呢？