V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  Ketteiron  ›  全部回复第 4 页 / 共 30 页
回复总数  600
1  2  3  4  5  6  7  8  9  10 ... 30  
go 不适合,但 rust 写得不好更不适合。
rust 难就难在写法太多,要压榨出最佳性能可不是靠 AI 胡扯就行的。

go 如此简单你都看不懂 AI 写的代码有哪些陷阱,更不用说 rust ,我怕你来回改最后性能连 go 都不如。
1 月 26 日
回复了 Ketteiron 创建的主题 程序员 发现一个自动优化 js/ts 桶文件的工具
@superhot #4 打包工具可以正确处理 namespace import ,例如 zod 推荐统一使用 import * as z form 'zod'
barrel 的缺点不是 tree shaking ,只要没有副作用,打包器是能正常 tree shaking ,但是开发阶段的首次启动变慢了,热更新变慢,各种 CI 检查都会变慢。因为必须加载完全部代码全能分析出用到了哪些代码,但是如果全路径定位到文件本身,就不需要对 n 个模块的复杂关系进行非常耗时的分析,因为桶文件经常会引用桶文件,几乎要把全部项目几千个文件都分析完才能梳理出单个文件的依赖图关系,哪怕它的直接依赖只有几个文件,如果只分析引用的实际依赖,整体计算量会指数级下降。
1 月 26 日
回复了 Ketteiron 创建的主题 程序员 发现一个自动优化 js/ts 桶文件的工具
@superhot #3 IDE 会自动更新路径,除了 PR 难看点也没什么影响。
我曾经抱有相同的想法,模块内的改动不会影响到外部,这被称为封装性好。
但反过来说,它隐藏了一定的信息量
import {a} from '@/a'
import {a} from '@/a/b/c'
第二种写法是很长,但一眼就能看出这是第几层嵌套的模块,它可以培养开发者把文件当成模块的习惯,而不需要人为构造一个模块

还有一个是统一写法的问题,如果 eslint 不进行限制,同样一个导入有 n 种写法
import {a} from '@/a'
import {a} from '@/a/b'
import {a} from '@/a/b/c'
如果统一禁止掉桶文件,只有一种写法。
我能接受团队内的任何固有习惯,但我希望只能用一种习惯,不要给我第二种选择。
1 月 26 日
回复了 Ketteiron 创建的主题 程序员 发现一个自动优化 js/ts 桶文件的工具
@craftsmanship #1 因为早期编辑器没有自动导入,为了省几个字符开发人员就想了个"巧妙"的方法少写点,现在的话没必要了,而且实际上并不会少写多少。

社区里可能有一万个惯例实际上是反模式,从来如此不一定是对的。
例如有些风格指导库会让只有一个导出时使用默认导出而非具名导出,例如 Airbnb ,在 ts 下这是错的,应该尽量避免默认导出,除非不得不用 (配置文件、i18n)。
1 月 26 日
回复了 YanSeven 创建的主题 程序员 有没有用过 Neon 数据库的大佬,说说体验吗
两个缺点:
1. neon 开源部分几乎停止维护
2. 供应商锁定
除此之外没有缺点,想用就用呗,只要记得免费不等于没有代价就行
@wangym20804 #9 高并发、数据堆积、分布式事务是微服务带来的副作用,单体项目如果达不到承载上限不会有这些问题。就拿消息堆积来说,为什么消息会堆积,因为微服务调用链路过长,等待内网延迟过久,加上各种分布式组件带来的开销,一个简单请求从几十毫秒变成几百毫秒甚至几千毫秒,处理速率慢了十倍百倍当然会导致数据堆积如山。
这跟业务简不简单完全是两码事,复杂的巨石单体应用多得是,难不成 aws 、stackoverflow 的业务很简单吗?
有些项目天生适合微服务,有些项目天生适合单体,但以我的观点,世界上 99%项目根本不需要微服务,而且多数人根本处理不好微服务带来的额外复杂度。

令人讽刺的是,最终 aws 把自己的`微服务->单体`博客给删掉了,毕竟微服务用户越多,他们的产品越好卖
https://web.archive.org/web/20230504060528/https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90
@Seulgi #5 虽然要做的事情很简单,但实现起来相当困难。最大的问题在于各种软件没有通用的、标准化的操作途径,这个项目的很多代码都是土法手搓各种不可复用的模拟调用方法。
再往后,新时代的面向用户的软件应该要主动暴露相关入口便于 AI 介入,并且版本号说明要提供结构化的相关列表,目前各种解决方案的随机崩溃率太高,只能是一个过渡方案。
1 月 24 日
回复了 laodao 创建的主题 Node.js ai 时代, node.js 成为核心语言
@ragnaroks #26 对于计算密集型场景,nodejs 可以把这部分任务交给 napi-rs
就我个人体验来说,性能是一个复杂项目中最不重要的指标
1 月 24 日
回复了 laodao 创建的主题 Node.js ai 时代, node.js 成为核心语言
@iorilu 没有必要再学一门"后端语言"。
除非公司项目硬要扣一点性能,monorepo+ts+全栈是 AI 时代性价比最高的做法。
目前公司的所有后端项目都用 ts 重写了,我们对性能要求很高,但至今为止还没碰上 nodejs 带不动的场景,就算 nodejs 性能差一点也可以换 bun 。
1 月 23 日
回复了 xiaotan5 创建的主题 问与答 咋没人讨论外服明日方舟的 paypal 支付 bug
@duuu #9 外国的信用卡基于"信用"本身,付款人可以取消支付,因此免密信用支付才能推行下去,被意外盗刷了用户是可以不认的。
而且这也不是盗刷,用户授权给游戏公司,游戏公司生成一笔交易订单推送给支付渠道,支付渠道验证后批准这笔交易,在支付渠道看来,这是一笔正常的交易。
不管国内还是国外,都是一模一样的流程,如果这事发生在中国,就是绑定支付宝/微信的用户授权给游戏开通免密支付,结果发现自己的支付宝/微信余额被莫名扣减。

> 商家一定无法控制扣谁的钱
这是错的,商家能控制扣谁的钱是免密支付的基石。
用户授权给商家,那么就相当于把自己钱包的部分管理权授予给商家,商家拿到你的令牌可以请求平台进行交易,平台只会验证密钥、令牌、余额等信息,对支付平台来说,它不会也不能去验证这笔钱是不是你发起的。而在这个案例中,是商家发错信息了,平台依照请求忠实地促成这笔交易,第一过错是发错东西的商家,第二过错是把令牌授予商家的用户,支付平台在这里没有任何过错。
一般来说,碰上这种事支付平台会狠狠地罚商家一大笔钱,因为它的信誉受损,信誉或者信用是支付平台能长久运营的基石。
1 月 22 日
回复了 litchinn 创建的主题 程序员 国内外一个有趣的技术倾向区别
拿 xxl-job 和 airflow 比较很奇怪,它们是完全不同的东西。
xxl-job 踩在了过于简单与过于复杂中间,且对 javaer 友好,让一些屎山项目能够顺利迭代下去。
xxl-job 之类的工具是基于微服务且明确违反微服务设计哲学的实用性妥协方案,它实际反映出很多公司是为了使用微服务而使用微服务,而不是需要使用微服务而使用微服务,如果是后者居多,那么并不需要这么一个"分布式调度中心"。
对于更复杂的分布式调度,不应该采用高入侵性方案,而是应该搭建一个调度平台 https://github.com/temporalio/temporal
@hellojukay 轮着来难道不是指一家人轮流去娘家/婆家吗,我不理解你这"一个人"是什么个意思。
我姐和姐夫就是这样的,我没觉得有什么问题。
失业金没影响,进小程序会告诉你能领多少个月
确定入职下家公司后要申请停止领取,不然公司交不了医社保
你的反感是对的,但正确方式不是抵制它,而是控制生成的代码的质量。
vibe coding 主要有两个作用远胜于传统编码:1. 快速出 demo 、快速使用从未接触过的库; 2. 强大的静态检查。
除此之外,vibe coding 并没有解决编程的实际复杂度,它只能作为开发人员的一个工具,而是否能用好工具,与工具本身无关。
1 月 18 日
回复了 piaochen0 创建的主题 生活 拒绝医生开具的中成药也没那么难
@liminany1 因为 99%中药对 99%病人没有作用,爱吃就多吃点。
1 月 16 日
回复了 cmdOptionKana 创建的主题 股票 一个炒股难题,不知道该如何解决
愚蠢的人类,妄想从随机数里找到规律
我说个暴论,凡是用得上 EventEmitter 的项目,99%是屎山
1 月 7 日
回复了 triptipstop 创建的主题 职场话题 小弟不才 一天通过了 影刀 RPA 高级
对业务很了解和自己开店没有关联。
我确实对跨境电商很了解,但从没有自己开店的想法,正是因为太了解了。
1 月 6 日
回复了 FlashEcho 创建的主题 程序员 如何优雅地使用 zod
以 drizzle 的数据库 schema 为第一优先级,在此之上派生下一级的用于接口校验、表单验证的 schema 。
现代化的 typescript 工程,要严格遵守 DRY ,不允许在任何地方出现多次重复定义,分离数据库层与业务层实际上与复用逻辑并不冲突,没有写两遍的必要。
无论何时,应该只有一个唯一来源,应用于整个项目,包括前端以及所有中间件服务,并强制保证运行时类型与 ts 类型完全等同。

基于这个理论,不应该直接使用 createInsertSchema 和 createUpdateSchema ,因为它们也是在重复定义并不明确的类型,应该封装一个方法统一给所有下一级 schema 使用。

它可能长这样 const createSchema = (table,labels)=> createInsertSchema(table).pick(labels)
具体代码不贴了,有一些类型体操,需要保证输入限制以及 pick 生效

举个例子,我定义好一张表
export const userTable = pgTable('user', {
...baseTable,
username: varchar({ length: 32 }).notNull().unique(),
password: varchar({ length: 64 }).notNull(),
})
然后这么使用
export const userLoginSchema = createSchema(userTable, {
username: (s) => s.min(4),
password: (s) => s.min(6),
})
因为返回的是一个 zod 对象,可以按照业务逻辑进行 extend 不在数据库中的其他参数,或者根据业务进行覆盖

第一参数接收一个数据库表,以此限制第二参数输入的键名,value 是一个函数,参数是经过 drizzle-zod 生成后的 schema
drizzle-zod 会为 varchar({ length: 32 }) 这样的定义自动生成 z.string().max(32),但是它不会限制最小长度,因此派生的 schema 需要在原来基础上进行补充,或者也可以直接传入一个 zod 对象覆盖。

不应该对业务层暴露一大堆的 optional ,而是严格限定你只能传递什么东西过来,它要么必须有值要么禁止传递,从数据库层一层一层往下传递到所有涉及到的地方,一直到达前端表单,这才是 schema("契约")的正确用法之一。

还有个地方需要注意,这个 schema 不能直接在 monorepo 中被前端/中间件引入,因为包含完整的数据库模式以及用不到的大量运行时函数,直接 import 大概会打包出两百多 k ,需要使用 json-to-zod + zod-to-json(zod4 最新版已内置) 等变通方法,监听 schema 文件自动生成一个新文件并 export 给其他项目。当然因为无法序列化函数,所以 refine 等功能都用不了。

此外我对 createSchema 进行了大量改造,包括强制传递元数据,并在路由/表单通过包装 safeParseAsync 函数解析出适合人类阅读的提示信息:'用户名长度最低为 4 位'、'密码长度最低 6 位'、'缺少 xxx 字段'、'xxx 格式错误',其中'用户名'和'密码'就是我要求传递的提示文本,它同样只能定义一次,还可以进行 i18n 改造,所有其它信息可以通过遍历 code 、origin 、input 等进行填充,社区里大量使用的 zod i18n 库是一个不理想的变通方法,但图省事也可以去用。
1  2  3  4  5  6  7  8  9  10 ... 30  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   906 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 34ms · UTC 21:04 · PVG 05:04 · LAX 14:04 · JFK 17:04
♥ Do have faith in what you're doing.