在电子商务平台上，商品结构起着至关重要的作用。它不仅承载着预订和服务流程中的商品信息，还在商户运营效率、平台可扩展性以及终端用户体验等多个维度产生显著影响。通过高度结构化的商品信息，平台能够运用数据分析和算法，更精准地推荐合适商品给目标用户群，更加高效地为买卖家用户创造价值，从而提升交易效率和客户满意度。 本文介绍了门票活动商品结构的演进和过程中的技术挑战。
在全球化战略的背景下，Trip.com作为一个面向国际市场的全球OTA平台，正努力推进国际化战略部署。Trip.com火车票正在积极投入资源和技术力量来拓展海外业务，通过将应用、数据部署新加坡、法兰克福等中心，从而给全球用户带来更好的购票体验和减少数据合规带来的风险。
如何科学地推断某个产品策略对观测指标产生的效应非常重要，这能够帮助产品和运营更精准地得到该策略的价值，从而进行后续方向的迭代及调整。 在因果推断框架下，效果评估的黄金准则一定是“AB实验”，因为实验的分流被认为是完全随机且均匀的，在此基础上对比实验组与对照组的指标差异就可以体现某个干预带来的增量值。但是很多场景下，我们较难进行严格的AB实验，例如对于酒店的定价；现金奖励的发放等等，不适宜向不同人群展现不同的内容。对于这些问题，我们会采取因果推断的方法来进行策略的效果评估。 本文主要介绍BSTS模型原理以及CausalImpact对模型的代码实现，旨在面对一些具有特定周期性特点的数据时，更精准科学地进行因果效应值的估计。下文将首先对模型原理进行简要阐释；随后利用模拟数据展示代码逻辑，最后在具体的业务场景中进行实践。
在日常的研发工作中，编写前端界面结构占据了一部分工作量。很多UI组件都存在共性，如何减少编写UI界面的开发时间，以及提取公用的前端组件，从而达到提升研发效能的目的，是我们的重要课题。 在《前端智能化探索，骨架屏低代码自动生成方案实践》中，我们曾经探索过一种自动生成骨架屏代码的方案，在此基础上，我们设计了一套代码生成器的定制流程，到达可以定制任意目的代码的效果。本文将围绕视觉稿生成任意代码，探讨代码生成器的原理与细节，最后是落地的效果展示。
随着移动互联网和智能设备的普及，前端开发人员需要采用多端同构技术来适配不同的终端（小程序、App和Web）。这些终端之间存在着明显的差异，包括浏览器引擎、操作系统、交互方式以及代码语言等方面。 这些差异给前端开发人员带来了不少挑战。一方面，不同终端采用不同的浏览器引擎和操作系统，导致页面渲染和交互行为的表现各不相同。另一方面，不同终端所使用的代码语言和开发工具也存在差异，需要开发人员具备不同的技术背景和知识，才能编写多份代码来适配不同的终端。这样做不仅增加了研发人员的开发工作量和代码维护的难度，还可能导致用户在不同设备上遇到不一致的用户体验，影响产品的质量和用户满意度。 为了解决这些问题，多端同构技术应运而生。通过多端同构技术，旅游前端和公共团队合作多端探索与实践，根据不同终端的特性进行灵活的适配和定制。这样可以减少开发成本和维护难度，提高开发效率和代码的可复用性。同时，多端同构技术还能提供一致的用户体验，无论用户使用哪种设备访问应用程序，都能获得相似的界面和功能。
随着多终端的发展，前后端的数据交互的复杂性和多样性都在急剧增加。不同的终端，其屏幕尺寸和页面 UI 设计不一，对接口的数据需求也不尽相同。构建一套接口满足所有场景的传统方式，面对新的复杂性日益捉襟见肘。 在这个背景下，BFF 作为一种模式被提出。其全称是 Backend for frontend，即为前端服务的后端。它的特点是考虑了不同端的数据访问需求，并给予各端针对性的优化。 在这篇文章中，我们将介绍一种基于 RPC 和 TypeScript 的 BFF 设计与实践。我们称之为 RPC-BFF，它利用前后端都采用同一语言（TypeScript）的优势，实现了其它 BFF 技术方案所不具备的多项功能，可以显著提升前后端数据交互的性能、效率以及类型安全。
随着携程机票BU业务规模的不断提高，业务系统日趋复杂，各种问题和挑战也随之而来。对于研发测试团队，面临着各种效能困境，包括业务复杂度高、数据构造工作量大、回归测试全量回归、沟通成本高、测试用例数量多且难以复用、测试数据维护量大以及自动化用例管理等问题。每个都会影响测试团队的效率和质量，给软件研发过程带来挑战。 总结下来主要是两个核心困难点：成本与复杂度。 成本方面，我们通常需要在成本和质量之间做出取舍，需要在快速迭代的同时保证质量，又需要在限定的投入下保证质量。 复杂度方面，当业务规则积累一段时间后，业务流程、规则、场景和数据处理的复杂度在叠加后呈二次或者指数等形式增加，给测试质量工作带来很大的挑战。
携程作为在线旅游公司，对外提供机票、酒店、火车票、度假等丰富的旅游产品，其系统稳定性关乎用户是否具有顺滑的出行体验。然而，流量激增、代码发布、运维变更等都会给系统稳定性带来挑战。 我们在2020年对生产故障的“发现-定位-解决效率”提出了“1-5-10”的目标（即一分钟发现故障，五分钟定位故障，十分钟解决故障），这无疑对监控告警提出了很高的要求。订单量是生产故障异常检测场景中最核心最显性的指标，订单量在自身形态上具有周期性、规律上升和下降、业务高峰和低谷等特点，影响因素包括节假日、促销等。倘若数以万计的业务线通过人工配置规则的方式来覆盖到所有业务场景，并且做到高准确率和召回率，是非常不现实的。因此，迫切需要一套配置费力度低、普适性强、准确率高、时效性强的智能异常检测算法体系来及时发现异常。 指标异常检测是智能运维领域的重要落地场景，携程AIOPS团队致力于提升告警质量，寻找告警效率、准确率和真实故障召回率三者之间的平衡点。我们将统计学方法和机器学习方法结合，根据指标的历史数据，将训练的多个模型组成一套异常检测系统，在覆盖真实故障的基础上，减少告警数量，产生更有价值的告警。
本文主要介绍离在线数据仓库建设在携程旅游团队的落地与实践，将从业务痛点、业务目标、项目架构、项目建设等维度展开。
眨眼之间，距离 React 18.2.0 发布已过了一年多的时间，越来越多的开发者从当初的观望心态，逐步已经将 React18 的新特性投入开发/生产中了，当然，笔者所在的团队也不例外。 今天这篇文章就和大家简单聊聊 React 18 中的 Streaming 。
