代码是写给人看的，所以一份好的代码，是要让水平不一的阅读者，都能够理解代码的本意。每个人的代码风格是不可能完全相同的，例如在一个文件里，有的以两个空格做缩进，有的以四个空格做缩进，有的使用下划线，有的使用驼峰，那么它的阅读体验就会变得很差。 所以如何来对代码进行约束，使团队的代码风格尽量统一，不产生更多的理解成本，是一个需要解决的问题。众所周知，懒是社会生产力进步的源动力，所以... 在前端工程化的标准中有一项就是自动化，自动化当中就包括了代码规范自动化。实现代码规范自动化可以解放团队生产力，提升团队生产效率...所以 ESLint、TSLint、StyleLint 这些工程化插件应运而生。 而最近在笔者团队也在统一不同的项目之间的规范差异，相信大家也都遇到了大段飘红的现象，今天咱来简单探究一下背后涉及到的原理。
2022年绝对可以说是AIGC元年，从google搜索的趋势来看，在2022年AI绘画及AI生成艺术的搜索量激增。 Image AI绘画在这一年的爆发一个很重要的原因就是 Stable Diffusion 的开源，这也离不开这几年 Diffusion Model 扩散模型在这几年里的迅猛发展，结合了 OPENAI 已经发展得很成熟的文本语言模型 GPT-3，从文本到图片的生成过程变得更加容易。
在Lazada各域推荐场景中，既有优质商品优质卖家不断涌现带来的机会，也有商品质量参差带来的问题。如何才能为用户提供更好的体验，对卖家变化行为进行正向激励呢？下面本文将为大家分享我们在与商品的演变成长性和商品的购买体验相关的三个环节中探索实践的经验。
大数据平台建设有其天生的复杂性，每一年都在推陈出新，从WareHouse、DataLake到LakeHouse，各种各样的Batch、Stream、MPP、Machine Learning、Neural Network计算引擎，对应解决的场景和组合的方式非常个性化，建设过程会遇到包括技术层面、组织层面、方法论层面种种问题，包括存储计算组件选型、离线实时湖仓架构方案设计以及场景化的性能分析，随着时间推进也会出现持续的组织管理、数据和平台运营、扩容、稳定性优化等问题，出现多个平台共存，存储和计算集群技术栈多样化以及数据分散等常态化问题，面临保留原架构还是推倒重来迁移到新的平台的困扰，有没有一套Architecture FrameWork能够屏蔽底层技术和开发细节，Data Fabric、Data Mesh似乎是为了解决这个问题而生，从技术和方法论的角度探讨如何影响大数据平台的建设、数据工程和架构持续演进。 本文重点聚焦在相对比较容易混淆的Data Fabric和Data Mesh这两个概念，尝试说明这两个概念要解决的问题、架构特征以及可行的技术栈，距离成熟还有哪些不足，以及围绕两个技术领域
本文将从以下五部分切入，讲述日志系统的演进之路：携程日志的背景和现状、如何搭建一套日志系统、从 ElasticSearch 到 Clickhouse 存储演进、日志3.0重构及未来计划。
Taro-CRN是帮助携程开发者基于Taro开发CRN项目的框架，实现一套代码在小程序和APP上的跨端开发，也为后续携程的跨端开发生态打下基础。Taro-CRN由携程机票团队与火车票团队共建而成。Taro本身是业内比较成熟的跨平台解决方案，目前已经支持转换到多平台小程序、H5、RN页面，并且有很好的社区支持。 在携程内部，Taro也拥有同样广泛的使用基础。多个业务线应用Taro来实现多平台小程序的开发，也有大量的H5业务页面是由Taro-H5转换而成。然而，Taro-RN作为Taro跨端开发方案的最后一块拼图，在携程内部却很少有团队应用，其根本原因在于其难以与携程的CRN框架结合使用。CRN是适用于携程APP业务开发的React Native框架，在携程系APP上有极为广泛的应用。CRN会在构建过程中，进行一些针对携程业务的分包、混淆、引入公共包等优化策略。这一点与Taro-RN那种直接打出bundle包的方案难以融合。
架构的核心是管理复杂度，架构师的核心能力是抽象能力，什么是抽象能力？抽象能力就是一种化繁为简的能力。何为化繁为简？就是把一种复杂的事情变得简单的能力，比如通过打比喻让别人很容易听明白你说的意思就是一种抽象能力。如何锻炼抽象能力？我觉得有三种方法，第一种是用归纳法找共性，从多个问题中找到共同的问题提炼通用解决方案，去其糟粕取其精华。第二种通过演绎法找关系，从多个问题中找关系，把多个问题串成一个问题，系统化解决问题！第三种是通过归纳法找特性。化繁为简需要不断的思考，不断的看清一件事的本质，这个事的解决方案越容易。
本文主要为大家介绍下 Cloudflare 提出的一种「新的」微前端方案以及其极致的首屏优化背后的实现原理，有兴趣的同学也可以直接去看 Cloudflare 的原文： Cloudflare Workers 和微前端：为彼此而生 https://blog.cloudflare.com/zh-cn/better-micro-frontends-zh-cn/ 通过 Cloudflare Workers 增加采用微前端 https://blog.cloudflare.com/zh-cn/fragment-piercing-zh-cn/
由阿里巴巴 TC39 代表主导的Async Context 提案[1] 刚在 2023年 2 月初的 TC39 会议中成为了 TC39 Stage 1 提案。提案的目标是定义在 JavaScript 的异步任务中传递数据的方案。 我们先以一个同步调用中访问全局变量为例，来讲讲什么我们为什么需要定义异步上下文。设想一下，我们是一个 npm 库作者。在这个库中，我们提供了一个简单的 log 函数和 run 函数。开发者可以将他们的回调函数和一个 id 传给我们的 run 函数。run 会调用用户的回调函数，并且，开发者可以在这个回调函数中调用我们的 log 函数来生成自动被调用 run 函数时传入的 id 标注了的日志。如我们的库实现如下：
