在之前的玩转服务器系列文章里，我们介绍了如何构建小型的高可用环境、PHP、Python、Java web、docker环境部署，以及Node.js SSR应用，本篇文章主要介绍新手也能快速上手的WordPress博客搭建和静态网站部署的教程
灵感来源随着AIGC的爆火，ChatGPT，GPT-4的发布，我作为一个算法工作者，深感AI发展的迅猛。最近，OpenAI的插件和联网功能陆续向用户公开，我也在第一时间试用了这些最新的功能。在OpenAI的插件市场上，我被一个可以帮助分析食谱，并生成购物清单的功能所吸引。我开始思考，如果我能够基于京东商城和AIGC的能力，帮助用户分解需求，在商城搜索相关商品，并直接返回他们想要的商品，甚至将所需商
本文通过介绍体验度量模型升级研究过程、研究方法及研究结果等内容，结合实际C端产品应用，观测新模型运行周期的表现，验证了其在高速发展的业务形态和日益变化的用户需求上的适用性和有效性。
使用Redis还是Zookeeper来实现分布式锁，最终还是要基于业务来决定，可以参考以下两种情况：（1）如果业务并发量很大，Redis分布式锁高效的读写性能更能支持高并发（2）如果业务要求锁的强一致性，那么使用Zookeeper可能是更好的选择
这篇文章主要介绍了代码中if else代码块泛滥时的治理措施，在实际应用时可根据具体场景选择合理的方案
一、为什么要做一款这样的小插件数据，一直在思考如何让数据更安全的流转和服务于客户，围绕这样的想法，我们做过许多方面的扩展。我们落地了服务端的数据切片支持场景化的设计，实现了基于JDBC协议对SQL的拦截与切片，实现了在应用层的全链路数据库审计方案和实现，实现了WEB端明暗水印和文档水印等等，但这些都是在应用服务端的改造；那么围绕以上服务端的思想产生了在端上做一些事情，分析了集团内部服务，多以WEB
大家好，接着上次和大家一起学习了《MySQL DDL执行方式-Online DDL介绍》，那么今天接着和大家一起学习另一种MySQL DDL执行方式之pt-soc。
Flutter开发中三棵树的重要性不言而喻，了解其原理有助于我们开发出性能更优的App，此文主要从源码角度介绍Element树的管理类BuildOwner。
我们可以通过MediaQuery.of(context)方法获取到一些设备和系统的相关信息，比如状态栏的高度、当前是否是黑暗模式等等，使用起来相当方便，但是也要注意可能引起的页面rebuild问题。本文会介绍一个典型的例子，并深入源码来探讨引起rebuild的原因，最后介绍避免rebuild的几个办法。
一、技术栈选择1.代码库管理方式-Monorepo： 将多个项目存放在同一个代码库中▪选择理由1：多个应用（可以按业务线产品粒度划分）在同一个repo管理，便于统一管理代码规范、共享工作流▪选择理由2：解决跨项目/应用之间物理层面的代码复用，不用通过发布/安装npm包解决共享问题2.依赖管理-PNPM： 消除依赖提升、规范拓扑结构▪选择理由1：通过软/硬链接方式，最大程度节省磁盘空间▪选择理由2：
本文将带领大家从日常的三层架构出发，精炼推导出我们自己的应用架构，并且将这个应用架构实现为Maven Archetype，最后使用我们Archetype创建一个简单的CMS项目作为本文的落地案例。
本文将从请求获取与包装处理、请求传递给Container、Container处理请求流程，这3部分来讲述一次http穿梭之旅。
一、哪些因素会成为系统的瓶颈？1、CPU，如果存在大量的计算，他们会长时间不间断的占用CPU资源，导致其他资源无法争夺到CPU而响应缓慢，从而带来系统性能问题，例如频繁的FullGC，以及多线程造成的上下文频繁的切换，都会导致CPU繁忙，一般情况下CPU使用率<75%比较合适。2、内存，Java内存一般是通过jvm内存进行分配的，主要是用jvm中堆内存来存储Java创建的对象。内存的读写速度
前端构建的提速是一项比较复杂且细节的工程, 目前产品上在持续跟踪构建慢的应用, 努力优化编译速度, 但前端本身拥有一个比较自由的技术环境, 没有统一的构建工具与流程, 另外语言本身的执行效率、单线程的构建也不好让编译机发挥其最大能力, 所以目前全局的通用优化手段还是会比较局限, 还是依赖项目自身的优化. 希望大家一起努力共建美好的明天.
APP发布到市场后，难免会遇到严重的BUG阻碍用户使用，因此有在不发布新版本APP的情况下使用热更新技术立即修复BUG需求。原生APP（例如：Android & IOS）的热更新需求已经比较成熟，但Flutter技术栈目前还缺少类似的技术方案，因此Flutter研发团队，也需要类似的热更新技术。
在Elasticsearch这样的分布式系统中执行类似SQL的join连接是代价是比较大的，然而，Elasticsearch却给我们提供了基于水平扩展的两种连接形式
随着项目的发展，前端SPA应用的规模不断加大、业务代码耦合、编译慢，导致日常的维护难度日益增加。同时前端技术的发展迅猛，导致功能扩展吃力，重构成本高，稳定性低。因此前端微服务应运而生。
Iframe是一个历史悠久的HTML元素，根据MDN WEB DOCS官方介绍，Iframe定义为HTML内联框架元素，表示嵌套的Browsing Context，它能够将另一个HTML页面嵌入到当前页面中。Iframe可以廉价实现跨应用级的页面共享，并且具有使用简单、高兼容性、内容隔离等优点，因此以Iframe为核心形成了前端平台架构领域第1代技术。
在引入ClickHouse过程中经历各种困难，耗费大量精力去探索并一一解决，在这里记录一下希望能够给没有接触过ClickHouse的同学提供一些方向上的指引避免多走弯路，如果文中有错误也希望多包含给出指点，欢迎大家一起讨论ClickHouse相关的话题。本文偏长但全是干货，请预留40\~60分钟进行阅读。
比如老王我，用npm init新建一个包，改把改把，然后来个npm publish，so easy ！Too young too naive, baby !请容我讲述一些发布过程中踩过的坑。
京东云开启中国云市场的首次公开比价活动，承诺“买贵就赔”！搜索“京东云官网”，进入活动页面，了解京东云全系核心产品优惠大放送！
Velocity是一个基于Java的Web页面模版引擎。十多年前，Velocity将Java代码从Web页面中分离出来，使得开发者能够并行网页开发和Java开发。随着十年前后端分离的浪潮涌动，回首再面对这些基于Velocity的旧系统，无论是后端还是前端人员维护，都会存在诸多问题：
key是widget、element和semanticsNode的唯一标识，同一个parent下的所有element的key不能重复，但是在特定条件下可以在不同parent下使用相同的key，比如page1和page2都可以使用ValueKey
当前微服务架构下，各个服务间依赖高，调用关系复杂，业务场景很少可以通过一个系统来实现，常见的业务场景实现基本涉及多个上下游系统，要保证整体链路的稳定性，需要尽量减少系统之间的耦合性，避免因为单点失效引起整个链路的故障。
京喜达技术部在社区团购场景下采用JDQ+Flink+Elasticsearch架构来打造实时数据报表。随着业务的发展Elasticsearch开始暴露出一些弊端，不适合大批量的数据查询，高频次分页导出导致宕机、存储成本较高。
Deferred Components，官方实现的Flutter代码动态下发的方案。本文主要介绍官方方案的实现细节，探索在国内环境下使用Deferred Components，并且实现了最小验证demo。读罢本文，你就可以实现Dart文件级别代码的动态下发。
对于AI的到来，我们战略上不要高估它，AI本身有它的局限性，保持乐观，前端没那么容易死；战术重视和关注它的发展，尝试在我们的工作生活中应用，技术变革的浪潮不会随个人的意志变化。
有次全链路压测中，有位同事负责的服务做Serverless扩容（负载达到50%之后自动扩容并上线接入流量）中，发现新扩容的机器被击穿，理论分析之后我们重新进行现象回放，模拟问题重现
本文主要介绍在业务复杂化背景下，京东零售购物车团队努力践行工匠精神，通过全异步化改造提升系统性能、提升用户体验。通过本文，读者可以了解购物车中台进行全异步化改造的总体方案，以及方案落地过程中遇到的问题及解决方法，读者可重点关注文中提到的多分页并行后，分页精细控制及底层RPC异常信息问题。
所谓一图胜千言，大家平日在工作中编写文档时，往往都需要画各种图来表达中心思想，在此为大家推荐一个专注于“画图”本身的工具 PlantUML，通过写代码的方式完成满足各种需求场景的画图工作，将人的精力集中到思想的表达与传递，避免无谓的图形页面样式修改调整，进而提升工作效率。
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号
