V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  Ketteiron  ›  全部回复第 18 页 / 共 27 页
回复总数  533
1 ... 10  11  12  13  14  15  16  17  18  19 ... 27  
@javalaw2010 #8 这里不能用 datetime ,跨夏令时那天会少一小时,只能是两个 timestamp ,相减是正确的。不过 timestamp 的问题是用户去了别的时区记录会不正常,比如临时去日本旅游几天,那么所有不在日本的时间都会往后推一小时,必须要一个单独的 timezone 字段。
2025 年 9 月 21 日
回复了 ethusdt 创建的主题 程序员 现在搞个 SPA (react 系)流行哪些库?
@wwk 最大的问题是性能问题,prisma 一些很简单的操作会生成多个 SQL ,例如几年前 prisma 的 update 一直都是生成 select+update+select 至少 3 个语句,某些情况下会增加到 6 个,这问题至今没有完全解决,复杂联表查询就更不用说了。
而相比之下 drizzle 基本都保证只有一次操作,drizzle 出圈除了营销很大原因是因为性能实在太好,相比原生 sql 几乎感受不到额外开销。而 prisma 很容易碰上莫名其妙的慢 SQL ,一通排查发现是 prisma 自己的问题,再找到 issue 发现存在很久没有任何进展,因此只能无奈地回退拼接 SQL ,类似 issue 我看得都麻木了。
再来就是 DX ,drizzle 的 schema 与 typescript 融合得很完美。prisma 的自定义 schema 很垃圾,间接导致 prisma 的 ts 支持并不理想,json 类型至今还是 any ,使用社区插件又引入新的问题。Model 的设计首先是无法继承,被迫多写很多重复性字段定义,其次让连表查询相当困难,嵌套多不说,最恶心的是一些简单的连表+动态查询不得不回退 SQL 拼接。
prisma 主打的就是类型安全,而实际上很难能称之为安全,相反 drizzle 的设计是真的能避开很多低级运行时隐患,缺点是比较复杂的场景要跟 typescript 打架。

drizzle 的 bug 确实不少,但是对我来说暂时都有办法解决,生产环境目前没有遇到过问题。
2025 年 9 月 21 日
回复了 wwww961h 创建的主题 问与答 digvps.com 这个站能用 ai 加 vue 仿出来么
看样子 OP 不会敲代码,我建议放弃
2025 年 9 月 21 日
回复了 sunshai 创建的主题 职场话题 从入职到离职,只用了一个月,炮灰的自我反省
@gxt92 我的错,OP 是试用期,可以拿 0.5-1 个月的赔偿。
2025 年 9 月 21 日
回复了 sunshai 创建的主题 职场话题 从入职到离职,只用了一个月,炮灰的自我反省
@gxt92 实习期没有赔偿。有些公司的实习期长达 6 个月,最后再辞掉,换下个人进来。
@javalaw2010 #6
"2025-09-19 14:44:00",有可能一条的时区是 Asia/Shanghai, 另一条的时区是 Asia/Tokoyo ,这是你的业务场景。
驱动要将一个绝对时间转成有时区的相对时间,默认操作是以 ioc 参数进行转换。
而你想的是在这里由业务层进行处理,第一条用 Asia/Shanghai ,第二条用 Asia/Tokoyo ,这样就能解析出正确的本地时间。

但请思考这样一个场景:
上海客户在下午 3 点创建订单,1 分钟后日本客户在下午 4 点 1 分创建订单,又 1 分钟后越南客户在下午 2 点 2 分创建订单。
对服务器来说,如何能形成一个正确的时间线,3 点->4 点 1 分->2 点 2 分?
在你这个场景下,已经无法区分了,因为所有时间被转换成当地时间,每个时区的订单都以自己为基准,失去了与其他区比较的中心坐标,如果要正确处理又得以一个标准(例如 UTC)统一转换,增加了复杂度。
进一步,上海客户飞到了美国,此时你要用哪个时区给他解析呢?
一旦驱动真的把解析时间的权利交给开发者,又要多出无数屎山。

在这里我们要先统一共识,时区是什么?时区解决了什么问题?
时区是绝对时间的相对偏移,与地理位置和政治有关,解决了如何将一个绝对时间在全球不同地方展示为当地时钟时间。
服务器不应当关心时钟时间,或者只应当关心以一个时区作为始终标准的时钟时间,例如 UTC0 ,任何时间都要以此标准进行统一,丢弃原本时区信息。全世界任意一个地方要获得正确的时钟时间,应该依赖客户端,而非服务端,服务端要做的仅仅是统一标准。
而原本时区信息在某些场景下是有意义的,Oracle 、PostgreSQL 等提供了 TIMESTAMP WITH TIME ZONE ,但是 MySQL 没有,只能自己存一个 zone 。

>我认为这个地方更适合交由业务层自行处理啊
因此可以回答这个问题,不同时区有不同的业务逻辑是合理的,但是自行处理时区时间是不合理的。

服务器、数据库、驱动都会有这么一个时区配置,这是为了设定自身的基准,它们可以不一样并且是合理的,但是在分布式满天飞的当下,全部使用 UTC 是最简单最没有心智负担的做法,把各种转换问题全部扔掉。或者直接使用 BIGINT 。

>时区就会非常混乱
时区的混乱是历史遗留问题,也是开发者对历史遗留问题选择了错误的解决办法。
甚至还有各种屎山手动加减时区,也是服了。
2025 年 9 月 20 日
回复了 Ketteiron 创建的主题 Solana 搁浅了,换点 gas
结贴,研究下黄钻怎么来。
2025 年 9 月 20 日
回复了 itechify 创建的主题 V2EX 关于 V 站改用户名水一贴: 15 年前的回旋镖
今天想改名,试了一圈都被占用了,只能随便改个
2025 年 9 月 20 日
回复了 braveman92 创建的主题 职场话题 感觉简历已经完全毁了
过了保质期应该也只能降薪了,程序员过了 35 就是相当的难,我的前上司能力非常出色,照样 35 被裁,降薪不少才找到下家。他跟我说,已经做好这是人生中最后一份工作的心理准备了,再被裁就回老家种茶叶。
@meteora0tkvo 没人能忍,2345/360/wps 等软件可以任意修改用户配置,下载其他软件,被称为流氓软件已经二十年,有用吗,唯一的手段只有不使用国产软件。
2025 年 9 月 20 日
回复了 alioth0909 创建的主题 程序员 vibe coding 是砒霜还是良药?中美文化对比
@alioth0909 #2 我的看法是那篇 reddit 帖子完全正确,标记 AI 与抵制 AI 是完全不同的两件事。
我极度支持 Stack OverFlow 禁止任何 AI 回复,而后面 v2 也采取了相同的做法。所有论坛/交流平台,都应该完全杜绝一切纯 AI 产物,这仅仅是在危害人类文明发展。

注意,这与我身为开发人员支持 vibe coding 是不冲突的。
何为 vibe coding ?
开发人员未经人工检查和验证生成大量代码。
这好吗,好也不好,需要从两个方面去审视,只会选择"好"或"不好"二者其一都是浅薄的。

>似乎我们对于 AI 编程这样的提效工具,有更大的热情
你可以去看看油管,各路外国高手以什么样的热情在研究 vibe coding 。
而这个论坛中,又有多少人拒绝学习 AI 知识, 拒绝定制 rules ,拒绝 MCP 。

> 很多人对“工艺感“和”可维护“有更高的要求,从而对 vibe coding 有一定的偏见
对“工艺感“和”可维护“有坚持的那些人,都在以远超普通程序员的效率使用 AI 编程,从而节省下大量时间用于“工艺感“和”可维护“,这依然是不冲突的。
2025 年 9 月 20 日
回复了 YanSeven 创建的主题 职场话题 发现自己在“学习”和“面试”中找不到平衡点了
八股就别看了,还考八股的也没必要去。
聚焦在学习本身,代码本身,如果学习得足够深入,就会真正碰上八股文里的问题,通过实践得出来的知识才能真正记住并且能说出自己的理解,而不是照本宣科说一通教科书废话。
2025 年 9 月 20 日
回复了 mryaocom 创建的主题 职场话题 焦虑,不知道接下来如何
如果是应用层的没啥难度,最基础的就是调接口,调整提示词,难一点的要设计工作流,可以用 dify 这种可视化的。
无法接受离职,就谈好了把开发周期拉长,一定要给足学习的时间。
现在阿猫阿狗都知道要做 AI ,但是怎么做,上层不管,只要求底下人凭空变出来,这样公司已经在死亡的路上了。
2025 年 9 月 20 日
回复了 alioth0909 创建的主题 程序员 vibe coding 是砒霜还是良药?中美文化对比
以偏概全,你用数篇帖子,脑补出整个欧美国家都在抵制 vibe coding ? v2 抵制 vibe coding 的帖子也不少啊,怎么说。
你要对比中美文化,不能用身边统计学+量子脑补,最起码也要深入调研一下。
2025 年 9 月 20 日
回复了 ethusdt 创建的主题 程序员 现在搞个 SPA (react 系)流行哪些库?
@june4 #22 vue 最大的一个问题就是没有需求,创造需求。vue3 进展缓慢,这些不去解决,反而炒热度玩 solidjs 吃剩的玩意。vue3 吸收 react 的优点,并且设计上没有 react 带来的心智负担,这个方向相当好,甚至不少人放弃 react 转而去写 vue tsx 。而 vapor 我个人是不认可的,它的发展必定挤占大量开发资源,我手里的一堆 vue 项目都在考虑用 react 重构。yyx 懂开源,更懂炒热度,oxc 之类的项目也是如此。
2025 年 9 月 20 日
回复了 ethusdt 创建的主题 程序员 现在搞个 SPA (react 系)流行哪些库?
@wwk #23 drizzle1.0 修复了大量 bug ,包括一堆迁移问题,正式项目可以等待 1.0 发布再转。
prisma 无论如何都不推荐用,很难想象多少公司被 prisma 推进坑里去了。
2025 年 9 月 20 日
回复了 ethusdt 创建的主题 程序员 现在搞个 SPA (react 系)流行哪些库?
@ejin #7 来回看了半天,0-6 楼说的都是 react ,为什么突然冒出个 vue ,走错片场了吧?
Vapor 这种东西应该丢到 vue4 去搞,vue3 的一堆问题都还没搞定。
而且现在有人在意性能吗,反正我自己不在意。大厂用 react 多,react 性能那么差,性能真的有关系大厂早大量迁移到 vue3 去了。

我个人比较在意 vue 的一堆 typescript 相关问题,比如 defineProps 直接丢掉 undefined ,而官方对此表示这是合理的
const props = defineProps<{
a?: boolean
}>()
props.a
// ^? (property) a: boolean

直到支持了响应式解构才勉强算解决了这个问题,但是 defineProps 与 typescript 行为不一致依然是不合理的。
const { a = undefined } = defineProps<{
a?: boolean
}>()
a
//^? const a: boolean | undefined

vue 运行时再快有屁用,vue-tsc 比 tsc 慢了 5 倍,vue-eslint-parser 无法享受 typescript-eslint 的性能改进,vue 官方明确表示不会支持类型感知,只能社区自己搞了个勉强能用的,但是太慢,后端 lint 检查 12 秒,差不多体量的 vue 检查要 80 秒,慢了 7 倍,插件越多这个差距还会接着放大。

运行时性能差距,没人关心,用户也感受不到几十到几百毫秒的差别,相比之下 vue 与 typescript 的融合体验被 react 吊打。react 不会插件天天报错,升级版本换另一个报错,不会拖慢 CI/CD 检查,不会与 typescript 有不一致的行为,不会被 typescript-eslint 维护者指着鼻子说 Vue 社区对于支持 type linting 没有兴趣
https://github.com/typescript-eslint/typescript-eslint/issues/2865#issuecomment-742647474
别瞎搞这些有的没的。
服务器和数据库统一使用 UTC ,时间戳展示交给客户端。
datetime 没有时区,因此不建议用于有时区要求的场景。
如果想用 datetime 处理,设计接口时要额外传输时区信息,然后服务端转换成 UTC 时间,请求数据时转换成 Unix 让客户端自行处理。
当然这里存在一个问题,服务端完全丢失了该条数据的时区信息,如果业务有需要,再增加一个 timezone 字段。
2025 年 9 月 19 日
回复了 TeemoYang 创建的主题 生活 老丈人撸了网贷,我该不该帮忙还?
@zhaol #178
>夫妻感情挺好的, 一起存钱买房
通篇读下来,老丈人拿走他们家 13.6w+数额未知的 1w*n ,估摸至少也有 20w 。
最近又要手术,还要再出至少 3w 。
老丈人买了房,而自己家孩子上小学了还没买房,钱全在老婆卡里连余额都不知道,感情好不好我不知道,但是买房看起来没啥希望。
1 ... 10  11  12  13  14  15  16  17  18  19 ... 27  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   1490 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 30ms · UTC 16:42 · PVG 00:42 · LAX 08:42 · JFK 11:42
♥ Do have faith in what you're doing.