V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  justdoit123  ›  全部回复第 5 页 / 共 13 页
回复总数  250
1  2  3  4  5  6  7  8  9  10 ... 13  
257 天前
回复了 justdoit123 创建的主题 问与答 电商系统表结构设计——曾经购买
@felmoon 后期分析更多的时候是离线计算,暂时不用考虑。
257 天前
回复了 justdoit123 创建的主题 问与答 电商系统表结构设计——曾经购买
@aino 命中不高 是跟 产品 做对比的,个人感觉而已。也行,那就对近期活跃用户做下预热。感谢~
257 天前
回复了 justdoit123 创建的主题 问与答 电商系统表结构设计——曾经购买
@aino 是这样的,能关联查询出来。 问题是,这个关联查询 目前只能通过 user_id 找到购买的 order 记录,然后从 order 再关联 order_item 表,找到曾经购买过的商品。

这个查询在新的需求里,很高频。暂时是加 redis 缓存,但是这种 per user 的查询,缓存命中率不太高。
277 天前
回复了 livin2 创建的主题 Linux Linux DE 与普通消费市场的距离到底在哪?
@terrytw 很赞同。打磨细节很痛苦很无聊很长期,没有金钱的诱惑,真的干不下去。
我感觉这是不能一概而论的。情况不同,处理方式不同。

复杂的业务系统,有时候你本地跑起来也没用,即便是单体架构。因为你本地未必有数据。如果每次写一个业务功能,都要写对应的单元测试、mock 这个业务各种场景的数据,那开发进度会大受影响。随着业务发展,可能还要写各种数据迁移。 如果这个业务是重要的(比如,飞机航班)、商业价值高的。那这样做没问题,也应该这样做。但是如果只是前景都不明朗,就投入一两人力的探索性系统,这些都不重要。提早把过多精力,放在这些方面有点浪费了。

我理解 OP 的感觉。我也很讨厌这种无法启动的项目。我觉得我们能做的事大概就是,在接手项目时候,所需要的适应时间成本一定要计算进去。这其实是切换上下文带来的时间成本,别说是接受别人的项目。回头维护自己过去写的项目,你可能都需要有不小的上下文切换开销。时间充裕了,至少不会因为时间问题加剧这种情绪。
277 天前
回复了 yueyuea 创建的主题 问与答 兄弟们你们怎么看程序员信风水这件事
偶尔听说一些,一些风水理念,感觉是有点道理。例如:镜子不对床、不对门、不住在风口(穿堂风)、单灯不顶头。感觉有点道理的项,自己也会有所注意。没细致了解过,所以看山看水那些也就听听,一愣一愣的,太玄的就不去细究与跟从。

以前有看到代码注释放个佛祖的,我觉得这种也蛮正常的。只要不魔怔、不要本末倒置了就好。代码 BUG 少,一定是写的人努力来的结果,而佛祖在这里能起的作用,估计最实际的是让写的人心理状态自信、平稳。他要是平时不努力,没有实力,放个什么都没用。

另外,我每次回老家都要给爷爷、家里供奉的(我也说不出来名字 T_T )、天公上香。对祖先是缅怀,也祈求保佑家人平安。对上,可能就祈求得比较泛一些,都是比较大的面,很少祈求私家的事。 我不会去祈求明天让我中个 500w 彩票,或者让我能有什么贡献极大的科学发现,又或者考试能满分,面试通过,升职加薪,年终绩效满分。。。。。。这就很可悲。三分天注定,七分靠自己打拼。

OP 提到的那货非常的可恶,为了兜售自己本末倒置的理念,给别人下“诅咒”!
随意。prettier 配置好,加上 githook ,让它自动去 format 。

纯前端团队,建议单引号,毕竟不用按 Shift 。 夸语言团队,可以使用 双引号。在一些语言里,单引号表示 char ,双引号表示字符串。
287 天前
回复了 justdoit123 创建的主题 前端开发 前端有没有比离线的 Playground 环境?
@0o0O0o0O0o 真 ~ T ~ M ~ D 的好。感谢~
新手,弱弱问下。有状态应用部署在 k8s 中,为什么挑战会比较大? 指的是大规模、高可用 redis/kakfak/zk 集群吗?
309 天前
回复了 justdoit123 创建的主题 科技 如何设计一个 redis 计数缓存?
@Goooooos 原来 redis 还支持操作~ 谢谢!
309 天前
回复了 justdoit123 创建的主题 科技 如何设计一个 redis 计数缓存?
@rrfeng 我也想过这个方法。就是语义没那么明朗。
311 天前
回复了 justdoit123 创建的主题 DevOps 大家的 CI 都是怎么搭建的?
原来大家都是不依赖 CI 工具的语法写 CI Job 的~~


@FlytoSirius 关于 secret ,至少我感觉 Jenkins 里的 secret 不是很好用。才萌生了把配置放入加密代码中的想法。

@CivAx 谢谢~ 我去了解下。
说得很对,主要就是 PromQL 还不熟。 之前在生产环境上,把服务搞 OOM 过。准备自己搭一个学习环境 来玩一玩。
@Frankcox grafana 里我看了下,主要都是根据 namespaces 的维度来看资源使用情况的,刚好没有节点的。metrics 我相信是收集了,只是没有配置对应的图表。 后续去看看怎么配置。
@salmon5 w(゚Д゚)w 哇哦! 感谢,感谢~
企业大到一定程度,肯定是要追求私有化部署的。别致盯着国内看,你看看国外,Google 会把服务部署在 AWS 上吗?


你说的更多的是中小型企业,据我上一份工作的经验,这类企业大部分是接受 SaaS 的。
314 天前
回复了 Braisdom 创建的主题 推广 写一点最近看回复的感想
我自己觉得 DSL 多了,要记的东西就太多了。不同的 DSL ,等于有不同的编程语法。

但是矛盾就在于,DSL 本质上是沉淀的结果,总不能每次写个新东西都从二进制开始吧?

只能说希望同领域、同场景的 DSL 语法最好趋于相近,能有一个统一;不同领域、不同场景的 DSL 的语法,能遵循一定的规律。
321 天前
回复了 connor123 创建的主题 问与答 是否 12306 推出候补功能后,更难买票了
据说,候补多的话,会动态加开列车。有人这样买到票吗?
这样挺好的。成熟化的软件领域就得是这样。假使,每次要写个 web 项目,都要先写一个 web 框架、db 框架、甚至要写个新的操作系统。

总还会有新的领域会出现,等待有识之士去占领。
@maocat 之前 2022.1 出的时候,升级之后也是各种 bug ,我才退回到 2021.3 ,结果就一直用到现在也没什么大问题。
1  2  3  4  5  6  7  8  9  10 ... 13  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   942 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 31ms · UTC 23:00 · PVG 07:00 · LAX 15:00 · JFK 18:00
Developed with CodeLauncher
♥ Do have faith in what you're doing.