如果让我选择一个词来总结我的2024,那一定是负重前行。这一年经历了太多,有几个节点真的很累,我顶住了,为自己喝彩!!!...如果撇去工作上的心酸血泪,那这一年过得是相当滋味,哈哈我列一下博客文章从个人github page首发,改到了腾讯云开发社区首发文章获得了2024年作者热度排名第 160 名拿到了腾讯云开发社区的好多礼品认识到了社区好多大佬有了一辆属于自己的机车...,工作、技术以外的生活也变得多彩了起来还是希望能够保持这种向前冲刺的好奇心,不过,2024的血泪史还是不要再出现了,真的很怕二、负重前行1)粗心大意首先24年第一灾,我给到了粗心大意,为什么呢?...,忘记删除原来调用了;导致调用了两次,那次代码的review,我的心在颤抖2)通宵达旦没错通宵了,一个存量数据的更新处理任务,预计凌晨2点完成的由于关键节点的失误,需要回退数据,修复代码逻辑问题,重新执行甲方是爸爸...,都够我吃一壶的了隔三差五的安排值班,得5分钟内响应生产问题还有计划任务,原定10个工作日的任务,要求在4天完成牛耐力好,马跑得快,牛马又快又好领导定的么,我没办法啊哥卷又卷不过,躺又躺不平三、展望20252024
监控没做好,DevOps等于裸奔:Prometheus+ELK的“稳态运营秘籍”——Echo_Wish原创兄弟姐妹们,我混运维圈十几年,见过太多“年轻人刚上班、监控全靠吼”的场面:服务挂了靠群里喊、CPU...DevOps≠工具链堆砌;真正的核心是“持续反馈+快速响应”。监控做不好,就像眼睛被蒙上布,再优秀的团队也得乱撞墙。...:Prometheus是把“指标可量化”做到了极致。...三、为什么Prometheus不够?因为没日志你等于只有一只眼睛Prometheus告诉你:“服务挂了,延迟爆了。”但是为什么挂?具体挂在哪?哪行代码吐血了?...然后找到问题代码:展开代码语言:JavaScriptAI代码解释setInterval(()=>{fetch('/api/user/info');},200);看到这玩意我当时真的想把前端拉出来聊聊人生
前言:近日我司进行云服务商更换,恰逢由我负责新上线的三方调用 api 维护管理,在将服务由阿里云部署到腾讯云过程中,我们压测发现在腾讯云调用京东接口时 TP999 抖动十分剧烈,尽管业务层有重试操作但是超时依然较多...,很多线程卡在调用三方 api 等待响应结果步骤上,并且有响应结果的调用消耗在 http 的时间也特别长,这就很容易理解了,是由于三方 api 抖动加之服务创建 http 连接过多先是导致应用响应缓慢,...再优化,这次我想到了请求分级,由于不同业务方对接口的响应时效要求不同,我们进行了连接池隔离,针对不同的业务方调用可以在调用时设置请求分级,我们大致分类下创建了三种分级 ‘FAST’,'STANDARD'...上述为两个问题,分别来看,请求可以确定是超时的我怀疑是不是由于使用了 http 连接池,池中的链接是不是超时了,从 httpclient 的日志中我分析了一下并没有这个问题,因为三方响应的 header...skyWaling 中展示的 HTTP 耗时很短的原因是因为只要开始有响应就算请求结束了,然后为什么会有只返回 header 的情况呢?
作为一个老运维,我常说一句话:“你不去看数据,数据也会来看你。”今天我们就聊聊:怎么用运维数据,把 API 管理从“救火式响应”变成“数据驱动调优”?一、API 管理为什么越来越难?...所以我们得从“数据”这个源头下手,不是光看接口是不是挂了,而是要看它怎么挂的、为什么挂的、什么时候开始挂的、挂之前有啥征兆。二、如何用运维数据驱动 API 优化?1....从指标出发:别只盯着“成功率”说实话,很多团队的 API 监控长这样:成功率 ✅平均响应时间 ✅QPS ✅看起来没啥毛病,但实战里根本不够。...它能让你精确知道每个 API 的慢点在哪个调用链环节:Redis 连接排队?下游接口超时?业务逻辑写死循环?...五、我个人的一点感悟做了这么多年运维,我发现一个事实——数据不会说谎,但你得会听懂它说的“话”。我们以前靠直觉、靠经验、靠“感觉这接口好像慢了”。但现在数据都在那儿等着你去问它:“到底出啥问题了?”
先来捋一捋思路,关于各个岗位合作打造(移动端)产品的一点想法: 为什么只有程序员是不够的 如何做一个好的非程序员 声明: 本人是程序员,截止到目前,我用的设计都是自己设计的,我用的产品策略都是自己的思考...最近想明白了一件事情:为什么身边好多人我明确地知道他们代码写的比我好,但是做不出好东西?...这个项目如果是现在做的话,从 0 到打包 ipa,两天以内,最多 800 行代码就可以搞定。...当然你可以把上面那张图也做出来给程序员预览,防止出错,但是你要明白这个东西是 iOS 系统提供的,UIAlertController 是现成可调用的 API,你要做的是只是提供调用这个 API 需要的参数...类似的例子太多太多了…… ---- 或许这篇文章的标题还可以改成: 在这个行当,不做设计师也得懂设计 在这个行当,不做产品经理也得懂产品 不想吐槽,只想分享一点自己的看法,我觉得真正的专业,不仅是把自己份内的事做好这么简单
本文权当记录成长过程中的点滴,请大家轻拍。 在很多高手们看来,这个故事简直不可理喻……没错,里头有太多坏习惯、太多低级错误,在硅谷巨头看来完全不可想象。...错,他们完全不知道……当然,我不打算把锅甩给他们,毕竟这里的甲方和乙方都是一屁股烂账、谁也别说谁。总之,让咱们客观回顾事件原委。 从项目说起 受保密协议所限,这里我没法透露太多。...去年 10 月左右,我曾经写信给对方的支持团队,询问他们能不能帮助迁移,回复中说他们“会调查一下”。然后就没有然后了。 所以说,我们得重新上传这些视频素材。...所以在使用这个脚本之后,所有不存在于我们数据库第一页里的视频都会被从 Vimeo 中删除。 这里还有另一个问题:我测试了代码,并使用了以上示例中的这个错误循环。...于是我又想到了一个办法: 另一个解决方案 能不能直接把视频从 Google Drive 上传到 Vimeo?我检查了一下上传页面,并发现确实可以这么操作。
好了,不扯淡了,上次概述了下水印情缘:http://www.cnblogs.com/dunitian/p/6232074.html 一张图概括: 额,这次先看下效果,然后普及一些开发过程中的知识点,然后介绍一下微软的...FaceAPI ==》原来的功能依旧在,非人脸识别,请在消息框中选择否 不要求人脸识别的就选否,每个月Api次数是有限的 先生成缩略图:(后期可以添加缩略比例的调节) 异步的方式开始干活了 好了之后会通知你...一起看看吧,有利于理解官方sdk: 首先定义了一个人脸识别的专用异常类:(别问我为啥不直接用Exception,不知道百度下~) 下面进行场景还原,为什么这样封装,很多人不写方法,直接贴代码,看的容易晕...) 下面就是核心代码:(我这边分了网页URL和本地图片路径,SDK好像统一用流的方式) 为什么我分两种情况,看这两张图就能理解: 根据要求进行封装: 看代码: 下面就是响应了 太多,我就不贴了,看对应代码...:(微软的提示是英文的,我得简单封装下) 调用就不用说了吧:await FaceHelper.GetFaceModelList(path) or FaceHelper.GetFaceModelList
其中最让我印象深刻的肯定是DeepSeek。为什么呢?因为它年初就惊艳了,免费开源,性能还那么强。...项目复盘:我从零开始,用的PythonFlask做后端,集成DeepSeek的API生成文本,前端是小程序框架。起初我不会API调用,就让Copilot帮我写代码框架,花了2天调试。...中间卡在模型响应慢上,我优化了prompt,限制输出长度,从原来的10秒响应降到3秒。测试时,用了10个模拟场景,准确率从70%提高到90%。实际用下来,我自己每天用它提醒工作,帮我养成习惯。...;第二个是后台日志,显示API调用和响应时间;第三个是代码片段,展示Copilot帮我生成的prompt工程部分。效果挺真实的,用了3个月,没出大bug,帮我节省了不少手动记事时间。...它让我从重复劳动解放出来,去想更有创意的点子。但也得警惕,AI输出有时不准,得人工审。未来,我想多学多模态AI,结合视频和代码,开发更多实用工具。2025年是我的AI启蒙年,希望2026能更进一步。
至于 GraphQL,又延伸的太多了,居然需要调用 API 的客户端去考虑和设计,这绝不是个好主意。 好吧,这个问题见仁见智,我们不展开讨论。...在我看来,所有的 API 都应该可以在不看注释和说明的情况下被调用方理解,从调用端点,到参数,和 JSON 的键。 这儿,我参考了国外的一些规则。规则也很简单: 用名词,别用动词。...我们前边提到了一定使用 HTTPs,也是因为这个。如果不想面向监狱编程,一定要确保这些敏感数据通过正确的方式,给到正确的调用方。 看了一眼数据,就被追了刑责,这是我身边的真事。 4....保持响应的一致 一致性是好的 API 的优秀品质。开发中,我们应该在各种方面做到一致,包括命名、URI、请求、响应等。而在这里面,响应的一致性是我对团人的一个硬性要求。 API 是要让别人去调用的。...开发的时候多想一下:作为开发人员,我们每天都在寻找使代码更好、更漂亮、更高效的模式,那么为什么不在 API 中也做同样的事呢?
国际惯例,开篇说两句 这或许是ChatGPT系列的最后一篇文章了,ChatGPT面世以来,从自己使用到把注册教程推广再到后来的微信接入以及飞书机器人接入,期间收到了很多网友的喜欢和支持。...为什么这么说呢,我觉得是时候普及一下这两个概念了,这有利于文末更好更合理的去使用 小妖GPT。 ChatGPT和GPT的介绍 这个时候,我们不如看看小妖GPT怎么说的: 什么是ChatGPT?...从官方公布的信息来看,目前对于ChatGPT并没有公开训练数据以及对应的API,所以,目前除了openAI 官方以及授权集成的一些第三方应用平台,如 必应,you.com等,其他人所调用的都是官方的GPT3...微信&飞书接入 网页版小妖GPT 通过上面大致的流程图可以明显的看出来,使用微信或者飞书接入的方式需要多一个中转服务器的开销,请求信息从用户端经过两个服务器的中转之后才会达到官方服务器中,服务器处理结束之后原路进行响应...,得留一手!
单参数入参兼容性强 还记得前面的小节中,我提到了 SpringCloud,在 SpringCloud Feign 中,接口的入参通常会被 @RequestBody 修饰,强制做单参数的限制。...为什么我好端端的 Dubbo 接口需要兼容 Feign 接口?可能会有人发出这样的疑问,莫急,这样做的初衷当然不是为了单纯做接口兼容,而是想充分利用 HTTP 丰富的技术栈以及一些自动化工具。...API 版本单独演进 引用一段公司内部的真实对话: A:我下载了你们的代码库怎么编译不通过啊,依赖中 xxx-api-1.1.3 版本的 jar 包找不到了,那可都是 RELEASE 版本啊。...而从微服务的使用角度来看,调用者关心的是 api 的结构,而对其实现压根不在乎。所以对于 api 定义未发生变化,其 app 发生变化的那些升级,其实可以做到对调用者无感知。...问题又和上一条一样了,api 一旦发生变化,调用者也得被迫升级,牵一发而动全身。 解决方案:以 module 为版本演进的粒度。api 和 app 单独演进,减少调用者的不必要升级次数。
你可以将多个调用封装到一个 API 中,让它们在服务器端完成,而不是从客户端发出多个请求。此方法也可以解决过取和欠取问题,因为你可以在将数据发回客户端之前对其进行操作。...2 减少 API 版本 在下一段中,Kyle 继续讨论了 API 版本相关的问题。他绝对是对的,API 的版本太多会使跟踪变得非常困难。...我很确定他了解部分响应。我猜他想说的是,部分响应需要有人实现。实际上,这与你在 GraphQL 中从一个资源里选择子字段非常类似。在 GraphQL 中,这是个开箱即用的特性。...当我们讨论 GraphQL 中的类型安全时,其实我们的意思是,我们相信 GraphQL 服务器的行为会与自省查询响应保持一致。为什么我们不能同样信任接口定义规范呢?我想我们可以。...对于 BFF 多么强大,以及与重量级的 GraphQL 客户端相比,我们从“stale while revalidate 模式”中获得了多少好处,我想我已经解释得够多了。
在上一篇文章《摩拜单车非官方大数据分析》中提到了我在春节期间对摩拜单车的数据分析,在后面的系列文章中我将进一步的阐述我的爬虫是如何高效的爬到这些数据的。...为什么爬摩拜的数据 摩拜是最早进入成都的共享单车,每天我从地铁站下来的时候,在APP中能看到很多单车,但走到那里的时候,才发现车并不在那里。...带着这些问题,我开始了研究如何获取这些数据。 从哪里获得数据 如果你能够看到数据,那么我们总有办法自动化的获取到这些数据。...我观察到即便在APP中,单车返回的数据也有跳动。有某一天凌晨到第二天早上,我隔段时间刷新一下我家附近的车,看看是否真的如此。 图片我找不到了,但是观察后得出的结论是,APP中返回的位置确实有问题。...而且这个跳动和手机、手机号、甚至移动运营商没有关系,说明这个跳动是摩拜接口的问题,也可以从另一方面解释为什么有时候看到车但其实那里没有车。
文章目录 JavaWeb 基础知识 -- 网络编程 1.为什么要网络编程?...,就能够让互联网上的很多主机进行配合工作,那么此时我们写的程序能做的事情就太多太多了…所以网络编程就是一个非常常见的需求场景。..., 在标准库中就有了一组类,这组类就能够让我们进行网络编程,但是我们要知道,这组类本质上仍然是调用的操作系统提供的scoket API 那么我们这里有一个问题?...要想跨语言调用,核心原理在于了解对应的语言的ABI(二进制编程接口)二进制指令规则等 3.网络编程中的基本概念 (1)发送端和接收端 在一次网络数据传输时: 发送端:数据的发送方进程,称为发送端。...为了理解这里的每个过程,咱们还是把一家餐馆比作是一个服务器 然后呢,我现在来到这家餐馆吃饭,首先我要点菜吧,我说来一个回锅肉盖饭,这就是发送请求,然后餐馆把菜给端上来相当于把响应给返回了,而从点餐到上菜之间的这段时间相当于餐馆要去做这个饭
崩溃的ReAct 与「隐式推理」的诅咒 要理解交错思维链为什么是「神技」,我们得先看看它的前任——早期的ReAct(Reasoning+Acting)范式是如何遇到瓶颈的。...这看起来很符合直觉,但在实际的工程实现(如OpenAI的Function Calling(函数调用))中,这个过程往往被简化成了「模型直接输出工具调用指令」。 问题就出在这里。...为什么它能带来40%的性能暴涨? MiniMax M2的发布数据中,有一组数据有力说明了这一机制的效果。...然而,在BrowseComp(网页浏览任务)上,提升幅度达到了惊人的40%(从31.4飙升至44.0);在Tau²这种复杂推理任务上,提升了36%。 为什么会有这种巨大的差异?...正如火如荼地进行中的AWS re:Invent 2025大会上,MiniMax也得到了亚马逊的认可。
但即便如此,这次经历不仅证实了我的低预期没问题,而且还大大拉低了我的预期。React 让人抓狂,不知道为什么没有人谈论它。 架构、组件、状态 首先,让我们从 React 为你选定的架构开始。...这个问题通过使用 React 钩子将状态“侧载(sideloading)”到组件中得到了解决。对此,我还没有听到有人抱怨过,但你们是认真的吗?你们是在说任何组件都可以使用任何部分的应用状态吗?...好吧,如果你必须从那里进行 API 调用,我会同意那是副作用。但是那个 API 调用,它也会设置状态。所以,一个完全无害的“副作用”钩子实际上管理了组件的状态。为什么没有人谈论这有多疯狂?...没有 API 通信开销,前端非常轻量级,UI 代码可以是强类型的(如果后端是强类型的),你可以在整个技术栈上进行重构,什么都加载得更快,你可以更好地进行缓存,因为有些组件是高度静态的,对所有用户来说都一样...没有前端状态 = 简洁性大获全胜,如果你能负担得起的话。 不可避免地,当你确实需要在服务器端渲染的“应用”中添加一些脚本逻辑时,明智的做法也许是只在最必要的地方添加,越少越好。
就像英语翻译,你得懂两边的语言、文化、甚至性格,才能做好这个"翻译官"。翻译官的三重修炼第一重:懂业务——别让需求在翻译中走样老李曾经接手过一个TOB系统的改造项目。...错误翻译正确翻译业务影响物理隔离的多租户架构逻辑隔离+品牌标识的单体架构开发周期从6个月降到2个月完全独立的数据库实例共享数据库+租户ID过滤运维成本降低70%微服务拆分边界混乱按业务能力聚合服务接口调用链从...陷阱二:同步调用链过长,缺乏熔断降级老李见过太多这样的设计:一个订单创建流程,同步调用6个服务,任何一个超时都会导致整体失败。这不是架构设计,这是在给系统埋雷。...老李的改进方案:核心原则:只有强一致性要求的操作才同步调用,其他全部异步化。陷阱三:API设计缺乏版本管理和向后兼容老李在一个TOB项目中痛苦地学到了这一课。...SQL+合理的API聚合响应时间从2s降到200ms接口兼容性强制客户端升级API版本化+灰度发布零投诉的平滑升级核心思想:RESTAPI的设计不是技术问题,是业务建模问题。
加上一次公司内部易永健老师的分享,涉及到了相同的话题,耳濡目染,这些曾经我发觉的痛点也逐渐有了解决之道。...单参数入参兼容性强 还记得前面的小节中,我提到了 SpringCloud,在 SpringCloud Feign 中,接口的入参通常会被 @RequestBody 修饰,强制做单参数的限制。...API 版本单独演进 引用一段公司内部的真实对话: A:我下载了你们的代码库怎么编译不通过啊,依赖中 xxx-api-1.1.3 版本的 jar 包找不到了,那可都是 RELEASE 版本啊。...而从微服务的使用角度来看,调用者关心的是 api 的结构,而对其实现压根不在乎。所以对于 api 定义未发生变化,其 app 发生变化的那些升级,其实可以做到对调用者无感知。...问题又和上一条一样了,api 一旦发生变化,调用者也得被迫升级,牵一发而动全身。 解决方案:以 module 为版本演进的粒度。api 和 app 单独演进,减少调用者的不必要升级次数。 难以测试。
上周还在用GPT-4,这周老板说要省成本换成Claude,你打开代码一看,API调用方式完全不一样,错误处理逻辑也得推倒重来。改到第三天,你开始怀疑人生:我到底是在做产品,还是在给各家AI公司打工?...直到我遇到了VercelAISDK6。那些年,我们踩过的坑说实话,早期做AI开发的时候,我特别喜欢直接用官方SDK。...我第一次体验到这种丝滑的时候,内心是震撼的。这才是2026年该有的开发体验。动手试试,别光看理论说得再多,不如自己写一遍。我们从最简单的开始。...我第一次写出这个效果的时候,还特意录了个屏发给朋友炫耀。他回了一句:“就这?”我说:“就这,五分钟搞定的。”这只是开胃菜到这里,你已经学会了让AI“说话”。但实际开发中,我们要的可不只是聊天。...统一API、流式传输、工具调用,这些能力本来就存在,只是以前你得自己拼凑。现在有人帮你把积木搭好了,你只需要专注于做产品。如果你是刚入门的开发者,这套工具能让你快速上手,不用被各种技术细节绊住脚。
说实话,我当时看到这个消息的第一反应是:什么玩意儿? 要知道,就在前不久,Anthropic刚刚拿到了110亿美元的天价融资,确实牛得一塌糊涂。...Claude也一直被公认为是目前最强的AI编程模型之一,我自己也用了很长时间。但是这波操作,真的让我有点接受不了。 从技术崇拜到价值观冲突 我得承认,Claude在编程辅助方面确实很强。...但问题是,它经常莫名其妙就封号,很多开发者都是被迫转向API调用的方式来使用。 现在好了,直接来个地域歧视:只要你的公司中国股权占比超过50%,就不让用。这已经不是技术问题了,这是价值观问题。...虽然我理解商业公司有选择用户的权利,但用"敌对国家"这种充满意识形态色彩的词汇来形容我们,确实伤害到了我的爱国情怀。技术无国界,但技术公司有立场,这我算是看明白了。...换句话说,这个世界上优秀的AI编程助手不止Claude一家,我们的选择其实比想象中要多得多。 是时候拥抱国产AI了 这件事让我意识到,过度依赖某一家海外AI服务,本身就存在风险。