我眼中的技术世界
近两年大语言模型跟AI编程十分的火热。自己也花了很多的时间通过VScode上包括各种ai编程助手包括copilot、通义千问、cline等。之前的应用里面主要是针对项目内的需求做一些单元测试、explain、fix的部分工作。今年cursor的编程工具也全面爆发了，各大厂商都纷纷投入这个赛道。尤其今年智能体、mcp发展起来了之后感觉越来越方便，其能力也更为强大。最近我开始全面进行ai完整来开发。也写个例子给大家参考项目背景在移动互联网时代，位置打卡和照片分享已成为日常生活的重要组成部分。无论是工作考勤、旅游记录，还是社交分享，人们都希望能够在照片中记录准确的时间和地点信息。基于这一需求，我们开发了一款功能完善的微信小程序水印相机。核心功能设计1. 智能定位与地址解析项目的核心亮点在于自动获取用户位置信息：GPS坐标获取：利用微信小程序的地理位置API，实时获取用户的经纬度坐标地址逆解析：通过坐标信息查询详细的地址描述，为用户提供可读性强的位置信息时间戳记录：精确到分钟的时间记录，确保打卡信息的准确性2. 专业级拍照体验为了提供媲美专业相机的拍照体验，我们实现了：多方向支持横屏和竖屏模式
Golang实现消息队列系统：RabbitMQ和NSQ的对比分析消息队列是现代分布式系统中不可缺少的一部分，通过消息队列可以实现不同服务之间的松耦合，提高系统的可扩展性和可靠性。Golang是一门非常适合编写高并发、分布式应用的语言，这里就来对比分析一下Golang实现的两个流行的消息队列系统：RabbitMQ和NSQ。1. RabbitMQRabbitMQ是一个基于AMQP（高级消息队列协议）协议的消息队列系统，使用Erlang语言编写。RabbitMQ可以轻松地实现异步消息传输、工作队列、发布/订阅、路由、消息确认等特性。RabbitMQ也支持多种客户端，包括Golang。使用Golang连接RabbitMQ主要是通过RabbitMQ Golang客户端，它提供了简单、易用的API来发送和接收消息。同时，RabbitMQ客户端也支持Golang的并发模型和协程，并且提供了可靠性、消息确认等一系列特性。在RabbitMQ中，消息的发送和接收过程涉及生产者、交换器、队列和消费者。以下是RabbitMQ的交互流程图：生产者 ----> 交换器 ----> 队列 ---->
不管是通过DDD方法论设计新服务还是梳理老服务，绕不开的一点就是接口设计。接口设计时很容易犯的一个错就是经常会根据接口调用方的个性化场景（比如多种界面展示）设计出很多类似且重复性的接口，且接口的实现逻辑割裂、复用性差。为了让业务服务更加聚焦领域能力，根据领域能力设计对外接口，同时又要满足多样化的接口消费场景如前端展示，架构里往往需要引入BFF这一层。在用户体验至关重要的今天，程序展示界面丰富多样。比如同一个界面可能同时存在极简版、专业版，一个界面要展示多种数据，要连接的设备也层出不穷如小程序、APP、网页、客户端等等。归纳起来有这几类：这些需求如果都在前端完成，则前端需要多次网络请求服务端数据，并且接口相关的适配逻辑不适合用前端技术来处理，效率不会高。但是如果一股脑丢到服务端来处理，则服务端模块的接口频繁修改带来稳定性下降。模块界限会变模糊，接口数量膨胀厉害。展示逻辑和领域逻辑混杂在一起，久而久之业务逻辑将变得难以维护。从DDD角度看，提倡围绕领域业务能力进行接口设计，服务端应该聚焦领域自身能提供什么样的能力来设计接口，而展示相关的处理逻辑不应该是领域业务。因此可以得出这里的主要矛盾是
前端性能指标是衡量网页加载速度、交互流畅度和视觉稳定性的重要依据，对于优化用户体验至关重要。 FP (First Paint) First Paint（首次绘制）标志着浏览器开始在屏幕上渲染任何内容，包括背景颜色改变。这是用户看到页面开始加载的第一个视觉反馈。尽管FP是一个相对宽泛的指标，但它能快速给出页面开始加载的初步指示。 FMP (First Meaningful Paint) First Meaningful Paint（首次有效绘制）是页面主要内容开始呈现给用户的时刻。这个指标更关注于用户感知，即用户开始看到页面上他们认为“有意义”的内容。FMP已经被LCP（Largest Contentful Paint）所替代，因为LCP提供了更准确的度量标准。 LCP (Largest Contentful Paint) Largest Contentful Paint（最大内容绘制）衡量的是页面上最大的可见元素（文字块或图像）变为可见所需的时间。这是用户感知页面加载完成的重要标志，直接影响到用户感受到的速度。LCP应该尽快发生，理想情况下在2.5秒内。 CLS (C
在当今设备多样化、应用复杂的世界里，构建高效且用户友好的用户体验至关重要。微服务架构的兴起为后端开发带来了诸多好处，但也为需要与多个后端服务交互的前端应用程序带来了挑战。这就是后端前端 (BFF) 模式的用武之地。>BFF 模式是一种架构模式，专门设计用于通过为每个前端应用程序创建专用后端来满足不同客户端的需求。这意味着，您不需要拥有一个试图为所有客户端提供服务的通用 API，而是拥有一个充当前端和微服务之间的适配器的 BFF 层。为什么要实现 BFF 模式？前端后端模式在 Web 开发中提供了多种优势：优化用户体验：每个 BFF 都根据其相应前端应用程序的特定需求进行量身定制，允许前端开发人员优化用户界面和数据流。例如，移动应用程序 BFF 可能优先考虑轻量级 JSON 响应和高效的数据聚合，而 Web 应用程序 BFF 可能专注于更丰富的数据结构和更复杂的交互。简化前端开发：通过抽象微服务架构的复杂性，BFF 为前端提供了单个 API 进行交互。这减少了对单个微服务的依赖，并简化了客户端的数据获取逻辑，使前端团队可以专注于构建用户界面，而无需担心后端的复杂性。提高后端敏捷性：只要
我们在需求阶段经常会遇到下列问题，针对直播抢购场景，假设我们要设计一款直播抢购的功能，比如某网红的直播间粉丝过亿，500万人在线，100万单商品瞬间被抢，下单并发高达200万QBS，如果当时出现评论区卡死，商品白屏，连库存服务也挂了，订单系统也崩溃了，这应该怎么办？分析：首先这是普通的技术难题，库存服务挂了，订单系统也跟着崩了，那肯定是服务依赖没处理好，或者说是这个全链路这个压测不到位，引发了连锁反应。问：系统缺乏防护机制的原因是什么？答：我认为系统缺乏防护机制的原因主要有三个。首先，流量失控没有限流措施，导致高并发直接压垮了系统。其次，服务之间的强依赖耦合太紧，一个服务出现问题，其他服务也会受到影响。最后，隔离措施不足，资源和逻辑没有有效隔离，单点故障迅速蔓延，导致整个系统瘫痪。问：如何设计以避免这种局面？答：我会采取三个主要策略来解决这个问题。首先，拦截，通过限流和熔断机制拦截和限制流量，比如设定阈值，超过阈值时进行限流或降级，以保护服务不被压垮。其次，缓解，通过缓存和排队等方式缓解流量高峰，提升系统吞吐能力。最后，隔离，通过隔离故障域，将问题限制在局部，防止故障蔓延到整个系统。问
在JavaScript中确实存在一些著名的"怪异"案例，这些都是由JavaScript的类型转换和比较规则导致的。以下是一些典型例子：相等性比较：[] == ![] // true [] == false // true '' == false // true null == undefined // true [1,2] == '1,2' // true针对第一个 [] == ![] 返回true是因为类型转换问题，其详细过程如下：首先，![] 会被计算：[] 是一个对象，转换为布尔值时为true!true 得到false此时表达式变成了[] == false当对象与布尔值比较时，两边都会被转换为数字：[] 会先被转换为原始值，调用toString()得到空字符串""空字符串转换为数字得到0false转换为数字也是0最终变成了0 == 0 ，所以返回true类型转换： [] + [] // ""（空字符串） [] + {} // "[object Object]" {} + [] // 0 true + true // 2数值
互联网发展迅猛之余也伴随着互联网寒冬，行业不景气这样的词，等毕业季去各个求职网站投简历，去各个人才市场找机会，才发现四处碰壁，作为应届求职者更需要打好基础，明确发展规划，跟上行业步伐。下面是本人2019年秋招前端面试经历，结合个人博客和牛油们面经中的高频问题以及行业前辈们复习资料的综合整理，包含基础篇、Vue框架篇、HTTP&浏览器、构建工具篇、安全篇、算法篇，欢迎交流斧正。希望大家在毕业季都能一帆风顺，从容斩获OFFER 怀着学习的态度完成了一份90页PDF ， 近140+commits，近100+前端面试题及推荐解答，资源合集的面试小册。因为篇幅有限，下面是小册前三篇的各五道前端高频面试题及推荐解答，这个项目已经在github上开源，欢迎大家取用：https://github.com/okaychen/FE-Interview-Brochure 浏览器解析渲染页面过程 大致过程： HTML解析构建DOM-CSS解析构建CSSOM树-根据DOM树和CSSOM树构建render树-根据render树进行布局渲染render layer-根据计
需求描述打造 特定领域知识(Domain-specific Knowledge) 问答 系统，具体需求有：通过自然语言问答的形式，和用户交互，同时支持中文和英文。 理解用户不同形式的问题，找到与之匹配的答案。可以对答案进行二次处理，比如将关联的多个知识点进行去重、汇总等。 支持上下文。有些问题可能比较复杂，或者原始知识不能覆盖，需要从历史会话中提取信息。 准确。不要出现似是而非或无意义的回答。 从大语言模型（Large Language Model, LLM）角度而言，上面的需求是在两阶段训练模式下，面向下游场景进行适配的问题。基础模型(Foundation Model)，面向特定领域不能直接应用，因为领域知识不在预训练的数据集中，比如：较新的内容。同一个知识点不断变更：修改、删除、添加。如何反馈当前最新的最全面的知识。比如对于 ChatGpt 而言，训练数据全部来自于 2021.09 之前。 未公开的、未联网的内容。 方案分析基于 LLM 搭建问答系统的解决方案有以下几种：Fine-Tuning 基于 Prompt Engineering，比如 Few-Shot方式。 与普通搜索结合
ChatGPT 很智能，但是它有不足：知识库老旧，停留在2021年。另外对于企业，很多私有知识，并不希望全部暴露给GPT。因此结合ChatGPT的自然语言对话能力，加上私有知识库的数据，可以发挥更大价值。假如我们想利用OpenAI能力打造基于私有知识库的智能机器人，可以怎么做呢？实现思路当前主流解决方案是使用建立本地向量数据库，用户输入的时候先在本地向量数据库找出相似文本，然后再发给 LLM，让 LLM 帮我们整理答案。（更多内容感兴趣的查看结尾的问答）大概步骤如下：1、将知识库文档向量化（使用OpenAI中的embeddings）后存储到向量数据库（Chroma）;2、对于用户输入，在向量数据库中查询相关文档(如余弦相似算法)并按相似程度排序;3、取最相关的前几个(如 top 5，需要考虑 token 数)作为背景知识，同用户请求一起发送给 LLM，让大模型根据背景知识整理并回答。实现Demo把 LangChain 的文档作为知识库，使用一个智能助手进行问答。先直接看看实现效果我们先问一下ChatGPT（gpt4）:再来问一下基于LangChain文档建立的问答机器人：（效果还是很明
小码哥
十年老程序员
粤ICP备2023052298号-1
