V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  wssy001  ›  全部回复第 1 页 / 共 3 页
回复总数  47
1  2  3  
@nyxsonsleep #11 前端传过来的数据先是在 gateway 层就做了一层数据过滤 传递到 service 层还有一层数据过滤
有啥好讨论的,不就是代码提交前的自测,关键的数据权限代码被打上了注释,发版时没注意取消注释给提交上去了
@leohuangsulei #5 我之前做的 OA 项目,有些无代码需求,就有形如
SELECT * FROM ARTICLES WHERE ${columnName} = #{columnValue}
这样的 SQL
不过前端传过来的数据都做了过滤
小服务 Serverless 一年需要几千?你是按照一个月 750 小时在线算的吧
如果是一个月 750 开机,建议直接买包月 Serverless 不适合一个月 750 小时开机
10 天前
回复了 lwen 创建的主题 宽带症候群 MacBook Pro 2015 装了 Ubuntu 焕发第二春
@cyio #6 考虑磁盘 IO ,你是把 macOS 当 App 的生产环境了吗?真追求极致性能,谁会用 docker……
另外、这年头还有用机械硬盘的 MacBook ?
11 天前
回复了 lwen 创建的主题 宽带症候群 MacBook Pro 2015 装了 Ubuntu 焕发第二春
@cyio #2 为啥 docker 不适合在 macOS 上使用?
Python 和 Golang 都没必要学,Python 的话,动态语言,Java 是纯静态,你 Java 写多了再写 Python 不觉得别扭?
Golang 无非是能带给你 AOT+极速编译的快感(我目前也是拿 Golang 当做第二语言,但越写越感觉 Golang 不适合负责业务。要不是 GraalVM 生态没起来,我还真没动力继续学习 Golang )
Java 作为一个 JIT GC 都很优秀的语言,第二个语言我建议考虑无 GC 语言
@ounxnpz #13 那你可千万别去字节写 golang 因为你能看到不少 golang 项目里有你讨厌的
bean 字段是确认的,那就禁用 Map
如果是动态的,那就和定规矩的吵一架,要么把动态字段需求砍掉,要么就允许用 Map
Java 从业者表示 直接用 IDEA 吧,省时省心
IDEA 内存占用大就是因为拿空间换的时间(时间往往和用户体验相关)
我问过几个拿 VSCode 开发 Java 项目的,听得最多的就是,如果想要 VSCode 达到 IDEA 那种体验,你必须得裝好多个插件,内存也少不了吃很多。甚至还有人说,同样的开发体验,IDEA 如果吃 8GB VSCode 至少会吃 7GB
是不是被针对了
我家用环境 一个月上传大概 200GB (半个月一次备份手机数据至云盘),没遇到过你说的限速
坐标:浙江电信
会不会是因为我掏钱把上传拉到 100Mbps 的缘故
35 天前
回复了 jlak 创建的主题 Go 编程语言 Go 语言真的有这么破烂不堪吗
google 的技能树全点在如何提升 AOT 编译速度上了,当初创造 golang 不就是为了加快项目编译
golang 只是 C 的网络语法糖,C 不擅长的,golang 也不擅长
浙江电信一直都可以,我家就是 IPv4 IPv6 双公网,可爽了
很多人不是为了 FTTR 才去办理的 FTTR ,而是为了宽带不得已办的 FTTR
Java 岗位远多于 Go ,web 后端开发生态也优于 Go Go 的话,C 的网络语法糖 岗位方向比 Java 更偏向操作系统层面
求职更多的是问自己,问问自己这俩语言谁能为你拿到更多的 offer ,offer 是第一位的,语言喜好才是第二位的
63 天前
回复了 javak 创建的主题 Java Java hello world 确实就要占用 30M
@voidmnwzp 试试用 go 写点复杂业务 希望写的舒服
64 天前
回复了 sagaxu 创建的主题 Java 2024 年, graalvm native image 仍较为勉强
以 Hotspot 为例,生产环境的主流 GC 要么 G1 要么 ZGC 但一般都选 G1 ,G1 适用场景更多。目前只有大对象大缓存应用才用 ZGC, ZGC 针对大对象分配比其他 GC 都合理并减少了性能损耗
按照 spring 团队的说法,native image 下峰值性能能达到 JIT 的 9?%(有点忘了 90%还是 95%),可以借助 PGO 进一步提升性能
(顺带说一下,Oracle GraalVM 免费了)
64 天前
回复了 sagaxu 创建的主题 Java 2024 年, graalvm native image 仍较为勉强
@sagaxu 在抛弃 Hotspot 这条路上 kotlin native 做的还没 graalvm native image 好
不过这俩项目目前都不咋样
真有这方面需求 还是老老实实换语言吧
64 天前
回复了 karottc 创建的主题 Java quarkus-graalvm 可以救 Java native 一命
无论是 springboot 还是 Quarkus 在改造成 Native Image 项目中 都会面临重构轮子的窘境
JVM 环境中,开发者 Google 到一个好轮子可以拿来直接用,而在 Native Image 中,开发者不得不考虑该怎么用原生的方式“曲线救国”
这是我这几年玩 GraalVM Native Image 的心得,最后得出一个结论:鉴于目前 Native Image 的生态,我觉得把项目用 go 重构的代价要比改成 Native Image 低不少(时间+精力方面)
97 天前
回复了 Knuth 创建的主题 计算机 现在笔记本 CPU 是不是普遍过剩?
说明你的笔记本平时只干没啥 CPU 负担的活
1  2  3  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5563 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 41ms · UTC 01:40 · PVG 09:40 · LAX 18:40 · JFK 21:40
Developed with CodeLauncher
♥ Do have faith in what you're doing.