随着产品矩阵和团队规模的扩张，跨业务、APP的数据处理、分析总是不可避免。一个显而易见的问题就是异构数据源的连通。我们基于PrestoDB构建了业务线内适应腾讯生态的联邦查询引擎，连通了部门内部20+数据源实例，涵盖了90%的查询场景。同时，我们参与公司级的Presto Oteam进行协同共建，在引擎层面做了诸多改造。在实际使用Presto的过程中，也发现其SQL表达能力的过人之处。本文将从Presto使用者和开发者两种角度，给大家分享一些技术落地过程中的干货。

腾讯云医小程序中有医生和患者聊天的场景，在处理该场景的列表过程中遇到两个问题: 一是下拉加载历史消息时需要在容器顶部进行衔接导致的界面抖动问题；二是大量的会话内容导致的长列表问题。

腾讯云医业务是为医生与患者打造的云上一站式医疗服务平台，为了降低医生首次入驻平台的成本；利用好微信的私域流量；保证医患双方有更接近端原生的使用体验，我们选择以微信小程序作为医患双端的核心承载形式。

小程序相对于原生本来就存在一定的性能差距，云医小程序上线后，随着入驻医生，使用患者的稳步增加，服务场景的不断丰富，微信小程序的性能开始受到了越来愈多的挑战。

在当下阶段，云医小程序的性能表现直接影响到用户的长期留存，因此，我们对腾讯云医医患双端进行了一次全方位的性能优化，从加载、渲染等维度深挖小程序的性能可塑性，提升腾讯云医总体的使用体验。

​全栈框架 Remix 宣布开源，于是怀着好奇心去看了下官网，发现了这个口号（Say goodbye to Spinnageddon），活整的还挺好的。

1999年，我出生了，中国第一支电竞战队AG也在这一年成立。那时候，电竞被认为是不务正业，几个小伙子需要在网吧吃泡面练习，辗转多地睡网吧、打比赛。2018年，中国电竞元年到来，亚运会双冠、S8总冠军等等荣誉均被中国战队包揽。一时间，中国迎来了电竞的热潮，更是有许许多多的俱乐部、电竞学校、电竞少年投入这个领域。而如今，电竞已经入亚，可以说：业发展正当时，电竞夺冠承势起。接下来，小编将从产品的角度，带你逐步了解电竞的世界。

企点电话作为对时延要求非常高的业务场景，必须要保证服务的高性能和稳定性，随着企点电话业务的发展，暴露出了许多go服务性能上的问题，本文结合企点电话在go语言方面的性能调优经验，最终总结出一份性能调优最佳实践。

逛直播间的时候，你是否经常点击右下角的点赞按钮呢。今天的文章，将会带你用两种方式来实现 H5 直播间的点赞动效。

这是前段时间，在Intel-PWA开发者日，做的一个关于微信小程序的主题分享，主要内容是关于如何基于Chromium内核来设计一个跨平台的小程序框架，实现一个Runtime用来支持多平台的小程序和小游戏运行。

Promise 和 Async/Await 依然活跃代码中，对他们的认识和评价也经历多次反转，也有各自的拥趸，形成了一直延续至今的爱恨情仇，其背后的思考和启发，依旧值得我们深思。

腾讯问卷有两种创建问卷的模式，分别是高级编辑与文本编辑。

高级编辑提供方便的UI界面，用户通过拖拽形式即可完成问卷创建。

而文本编辑则是通过纯文本来生成问卷，适合需要大量创建题目的用户。

当前文本编辑模式的解析器基于正则表达式实现，代码逻辑十分分散且复杂，使得想添加新语法会变得非常困难。

而且并没有实现文本与问题ID的绑定，每次对文本内容修改时，会重新解析并实时生成新的问题ID。

问题ID的变化会使之前设置的DSL（根据ID来处理逻辑）全部失效，同时还会导致以往关联的答案数据因为ID的丢失，而变得无效。

作为一个产品经理，我们最离不开的一个词，就是“需求”。能传达我们对需求的理解与定义的工具就是产品需求文档。而产品需求文档也是贯穿于整个产品设计研发过程中的一个关键指导纲领。

在工作期间，我撰写了不少需求文档，同时在理解需求、表述需求、实现需求的过程中不断磨练自己的产品思维。因而撰写此篇文章，尝试通过具体经验反思总结，形成系统化、可实践复用的关于产品需求文档撰写的方法论。希望这篇文章能帮助同样是产品新人的同学们学会用产品思维撰写需求文档，并运用到其他的策划工作中。

本文将围绕是什么、为什么、怎么写产品需求文档以及用产品思维讲述如何写好需求文档，让需求文档助力产品落地上线。

最近优化了几个新人写出的动态表格文件下载接口的性能瓶颈，感觉非常有必要总结一篇文章作为文档来抛砖引玉，以促进大家学习一起写出更专业的代码。

帮助文章受众系统化了解「什么是审批流」、「如何盘点审批流」、「如何设计审批页面」，以此，在基于合规化的前提下，制定信息传达准确、流程操作高效、节点可预知、历史可回溯的审批系统。

一文带你了解 display:table-cell 的使用方法和可能遇到的坑。

跳表原理及其Golang实现~

我们在企点电话SDK中实现了一套日志追踪系统追客(Tracker)，既弥补了纯日志可读性差的问题，又同时做到了1:1直观的还原用户现场的能力，问题排查的整个过程会比亲临问题现场还更便捷高效。