V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  zzhirong  ›  全部回复第 4 页 / 共 5 页
回复总数  91
1  2  3  4  5  
2025 年 4 月 6 日
回复了 myTrip 创建的主题 生活 拍婚纱照真累啊,我为什么要花钱买罪受
× 找人修图,修到亲妈都不认识
√ 拍些真实照片记录重要瞬间

就我而言,若干年后再看,那些真实的照片反而让我更感动,那些修过的,总感觉好陌生。
2025 年 4 月 6 日
回复了 mogutouer 创建的主题 程序员 用 AI 编程,半夜的我放声大笑 2
妈妈心疼地摸着刚从噩梦中惊醒的儿子的头,轻声说:“你看隔壁那个程序员叔叔,也不知道在干什么,大半夜的,一会儿骂骂咧咧,一会儿又像是在道歉,有时候还突然大笑起来,真奇怪。儿子,咱们以后可别当程序员!”
2025 年 4 月 3 日
回复了 FaustY 创建的主题 程序员 类 Manus 的 UI Agent 完全是个伪需求,前端已经没活路了
@mumbler 那个店关门了怎么办,领导一会要去另一栋楼开会要修改一下地址怎么办,领导最近信用卡到期了,要更换支付方式,领导夫人来了,需要多点一些,夫人喜欢吃淡点的,领导除了吃猪脚饭,还能吃什么,总不可能是随便吧,领导想给自己的父母点一些该怎么办。我的核心观点就是,想要精确表达需求,就要有足够的输入,你可以优化输入(比如,最近点过什么,我可以说,就吃上次点的),但是你不能省略输入信息,不然,你得到的结果很可能不是你想要的,各种 UI 都在优化这种输入,比如从常用地址中选择而不需要手动输入地址,你没办法做到不精确描述需求,而想得到一个精确的结果,不然就是开盲盒了(点了什么不知道,送到哪去了不知道,是用美团月付还是用信用卡支付的,不知道,餐具有几套,不知道,我最近牙疼,是不是清淡的,不知道)。
2025 年 4 月 3 日
回复了 FaustY 创建的主题 程序员 类 Manus 的 UI Agent 完全是个伪需求,前端已经没活路了
@mumbler 你要吃什么,在哪个店铺,要点多少数量,收货地址是哪,餐具要多少,有无口味要求(可能一个人吃,也可能几个人吃)这些可以做哪些优化?一个界面呈现所有选项么?
2025 年 4 月 3 日
回复了 FaustY 创建的主题 程序员 类 Manus 的 UI Agent 完全是个伪需求,前端已经没活路了
我认为,信息压缩也是有极限的,有些东西无论以何种方式呈现,最终还是要呈现,你可以改进压缩算法,但是它的极限就在那,你没办法不说出你的需求,就能得到结果,最多做一些优化(比如常用地址只要选择就可以了,而不用重复输入)。话说,真有人会感觉目前 App 订餐以及打车需要优化么(普通人一天最多也就一两次吧)?
2025 年 4 月 3 日
回复了 FaustY 创建的主题 程序员 类 Manus 的 UI Agent 完全是个伪需求,前端已经没活路了
@mumbler 你要选择你要点外卖功能,(搜索你想吃的)然后选择店铺,选择你要点的东西,选择收货地址,写备注,这不就是目前 app 在做的事情么?我想不到哪里还可以优化。
出现这个问题的原因是,更新后,旧版本的 js 文件不存在了,然后,旧的页面链接还是指向旧的 js 文件,获取的时候,返回了 404.html (或其他),你这种情况可能是由于使用文件名来做版本控制(同一 js 文件不同版本不同的文件名),我能想到的方法是,固定 js 链接地址,再由后端来决定返回什么版本的 js ,或使用 HTTP Etag 头来做版本控制。
2025 年 4 月 3 日
回复了 FaustY 创建的主题 程序员 类 Manus 的 UI Agent 完全是个伪需求,前端已经没活路了
对话框也属于 UI ,我感觉并不适合所有场景,就订餐来说,食物长什么样的,店铺评价如何,要几双筷子,有哪些优惠,如何支付,外卖送到哪了等等,这些信息用自然语言来呈现不一定最佳。还有打车,你如何精确描述你的目的地,以及到哪接你,以及你可接受的价格。
2025 年 4 月 2 日
回复了 taohua1c 创建的主题 Kubernetes 想学习 K8S,请问大佬们应该怎么入门呢?
@kamilic 这本书是好,但内容有点过时了( 2018 年出版的,第二版的话今年 5 月份发布),详细是真详细,我也是看这本书入门的,同时还看了另一本《 The Kubernetes Book 》(只有 243 页,实用为主,核心概念都都介绍了一下)。

实验环境的话,可以安装 minikube 或 k3s 组建单节点集群,但受限于国内网络环境不友好,我是买了一台外网服务器用来运行 k3s 。
2025 年 3 月 30 日
回复了 zzhirong 创建的主题 Go 编程语言 有关 gin.Context.FileFromFS 的小坑
@gvison 看了下引用的 frontend 包的源码,发现 github.com/go-dev-frame/sponge/pkg/gin/frontend.FrontEnd.setEmbedFSRouter 有个新的实现方式

staticFS, _ := fs.Sub(staticFS, "dist")
r.GET("/*file", func(c *gin.Context){
staticServer := http.FileServer( http.FS(staticFS))
staticServer.ServeHTTP(c.Writer, c.Request)
})

这种方案也是可以的,直接 wget http://localhost:8080/ 这会返回 301
2025 年 3 月 30 日
回复了 zzhirong 创建的主题 Go 编程语言 有关 gin.Context.FileFromFS 的小坑
@gvison 你的方案确实可以,但我不想引入额外的包而且我就想把主页挂在 / 下,有无办法只用 gin 实现?
2025 年 3 月 30 日
回复了 zzhirong 创建的主题 Go 编程语言 有关 gin.Context.FileFromFS 的小坑
@kingcanfish 你的方案会有两个 301 重定向,当你碰到首页不在根目录下的情况,你的最佳实践是什么,我目前的做法是

r.GET("/", func(c *gin.Context) {
c.File("dist/") // 会直接返回 dist/index.html ,没有重定向
})

把 / 映射到 index.html 应该很常见吧,有更好的方式么?
2025 年 3 月 29 日
回复了 zzhirong 创建的主题 Go 编程语言 有关 gin.Context.FileFromFS 的小坑
@lovelylain 什么意思?你的意思是 /dist/index.html 会内部转发到 / 么?但是,wget 确实收到了 301 ,然后一直有尝试重定向,然后一直收到 301 。
2025 年 3 月 29 日
回复了 zzhirong 创建的主题 Go 编程语言 有关 gin.Context.FileFromFS 的小坑
@tbxark 原因我昨天通过调试就已经知道了,就是先把问题代码贴上来,看看大家能否一眼就能看出,你提出的修改方案也还是会返回 301

// 还是会返回 301
dist, _ := fs.Sub(dist, "dist")
router.GET("/", func(c *gin.Context){
c.FileFromFS("index.html", http.FS(dist))
})
2025 年 3 月 29 日
回复了 zzhirong 创建的主题 Go 编程语言 有关 gin.Context.FileFromFS 的小坑
补充一点:帖子被贴上 “404 not found” 的标签了,应该是没有创建 ./dist/index.html 文件的缘故,但这里说的问题并不是这个低级错误。

- wget http://localhost:8080 返回的是 301 ,而且我这边返回的是 20 次 301 (超过阀值强行退出)。
如果您刚掌握了 gin 的基础知识,可以参考 https://github.com/gin-gonic/examples 和中间件示例 https://github.com/gin-gonic/contrib
两者本质上都可以抽象成,一个线程池在完成多个任务队列,那么问题来了,既然两者都差不多,然后,Go 还引入了
goroutine 抽象层,为什么 Go (可能)要高效一些。如果所有任务都是非阻塞的,那么多线程和 goroutine 在性能表现上差别可能并不明显(猜想,未验证);但在现实情况中,由于 I/O 或通信等原因,不可避免会发生阻塞。传统线程一旦阻塞,则会占用整个线程资源,而 goroutine 在阻塞时会被挂起,并在等待条件满足后重新调度,大部分时候不会需要阻塞底层线程,从而更高效地利用系统资源。也就是说,如果你很 NB ,能够做到又能尽量少阻塞线程,又能把任务完成(也就是高效利用线程池,这就是 Go 调度器做的事情),那么两者差别不会很大。
除了以上其他人所说,我认为还有一个重要原因,在 Go 中,对象的概念主要通过 struct 实现,而 struct 为值类型,为了让方法修改其内容,只能依靠指针,所以,只要还有值类型存在,而函数传参均为值传递,那么如果希望定义能够修改对象本身的方法,就必须使用指针。
2025 年 3 月 17 日
回复了 rkonfj 创建的主题 Go 编程语言 现在搞 p2p 很简单了
@cloverzrg2 PeerGuard “夜幕降临,我的守望始于此,直至死亡将我收走。我不娶妻、不育子、不占有土地;我不争荣誉,不戴王冠;我只在城墙上生、老、病、死。我是黑暗中的剑,是守护 peer 的盾,我以我的生命和荣誉守护
peers ,直到永远。”
2025 年 3 月 17 日
回复了 rkonfj 创建的主题 Go 编程语言 现在搞 p2p 很简单了
1. 看到 PG 第一反应联想到 PostgreSQL 。
2. 在阅读 README 时,我发现了一个有趣的词——“Birthday Paradox (生日悖论,在一个群体中,只需要 23 个人,就有超过 50% 的概率存在两个人的生日相同)”,用在 NAT 穿越上,指的是在双方都知道对方 NAT 地址但不知道对方 NAT 映射端口的情况下,各自随机选择一组目标端口发起通信,从而有一定概率能建立连接,这不禁让人联想到你我相识全靠缘分。最近刚好看了两个关于概率相关的数据结构:跳跃表和 HyperLogLog 。感叹数学真美和烧脑。
1  2  3  4  5  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   2162 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 24ms · UTC 15:22 · PVG 23:22 · LAX 07:22 · JFK 10:22
♥ Do have faith in what you're doing.