V2EX › justdoit123 的所有回复 › 第 9 页 / 共 18 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

1 2 3 4 5 6 7 8 9 10 ... 18

❮

❯

2024 年 7 月 2 日

回复了 justdoit123 创建的主题 › Coding › rpc 服务中，“业务错误”的返回应该如何设计？

话说，才发现 coding 节点算是 CodingNet 的营销节点。。。

2024 年 7 月 2 日

回复了 justdoit123 创建的主题 › Coding › rpc 服务中，“业务错误”的返回应该如何设计？

@timethinker 感谢～

2024 年 5 月 30 日

回复了 nickyadance23 创建的主题 › 职场话题 › 6 年，开始对工作感到无奈

我有时候会想去做工业软件开发。因为会预设的认为（可能事实并非如此）工业软件的需求是清晰的。就像建设一座桥梁一样。一个具体的桥梁，其宽度、长度、承受力需求是确定的。然后会进行设计，确定什么样的结构、什么样的材料等。然后进行施工建设。

不知道现实中的工业软件开发是不是我设想的这样。

同样用现实中的桥梁做比喻，互联网的短平快，就像是先横一根木头过河，一根不够就两根，木头不稳就两把用人扶着，怎么实现快怎么来，先“能过河”再说。总算有人能通过这根“桥”过了河，但是上面却说这个桥不用了。

不知道这样的比喻恰不恰当。

以前在学校会觉得技术最重要，代码最重要。工作到现在，我却感觉需求更重要，清晰的方向、牛逼的产品经理比程序员重要多了。经常看着写下的代码死掉，会让我泄气。

2024 年 5 月 28 日

回复了 yangxin0 创建的主题 › 互联网 › 腾讯真是吃饱了没事儿干了吗？

这。。。。。点进去看了下，TX 这个怎么都算是在干正事。

2024 年 5 月 24 日

回复了 lesismal 创建的主题 › 程序员 › HTTPS 用明文传输密码的问题，看到很多次了，个人观点不赞成，单开个帖

密码（或者 hash 过后的密码）终究要出现在内存里，云服务提供商是不是能从内存里直接读出密码。

安全没有绝对，做到什么程度，看被保护的对象是什么，需不需要做到那么高的层级。

服务端发一个公钥，然后在客户端把重要数据再自己加密一次也不算很费事。不过不加也就那样。

> 密码是用户自己的隐私，不想让服务提供商知道我的隐私。

我感觉这种想法很美好，现实是你这种“隐私”会像乐色一样被对待。不想泄露隐私，绝对的安全就是把自己关在一个盒子里。当你使用服务的那一刻，很多“隐私”都已经不复存在。真那么觉得密码是一种隐私，那用户名（ email 等）也应该是隐私。以后要用这些东西，就每个服务都用一个随机 ID 、随机密码。这样就不会泄露“隐私”了。但是真的好累。

2024 年 5 月 10 日

回复了 justdoit123 创建的主题 › React › react-hooks 场景下，如何在异步回调里访问当前的状态值？

暂时采用 ref 的方式解决。把一些 handler 放入 ref ，类似这样：

```tsx
const handlersRef = useRef<{
submitLog?: typeof submitLog;
startClock?: typeof startClock;
}>({});
```

2024 年 5 月 10 日

回复了 justdoit123 创建的主题 › React › react-hooks 场景下，如何在异步回调里访问当前的状态值？

@Puteulanus 谢谢～捂脸

2024 年 5 月 10 日

回复了 justdoit123 创建的主题 › React › react-hooks 场景下，如何在异步回调里访问当前的状态值？

@lisongeee 哇哦，还有这种用法。前面没有细看，明白了。

2024 年 5 月 10 日

回复了 justdoit123 创建的主题 › React › react-hooks 场景下，如何在异步回调里访问当前的状态值？

@weixind 这个 use-query 看着不错。

关于状态还是 set 多不展开讨论。我会问这个问题，是因为我在实现一个连续 timer 的需求。

1. timer 一开始是停止的，有个按钮让用户点开始；再点一次就停止。
2. 一个 timer 时间到了，需要提交数据，然后自动开始下一个 timer ，直到用户点停止为止。

那么如何在一个 timer 数据提交后，自动触发下一个？直接调用 startTimer 肯定是不行的，因为里面包含的 state 都是“旧”的。

我目前能想到的是通过 pubsub 来绕过这个问题，或者就像 1, 2 楼说的用 ref 。

2024 年 5 月 10 日

回复了 justdoit123 创建的主题 › React › react-hooks 场景下，如何在异步回调里访问当前的状态值？

@Leviathann 这种情况真的只能加上 ref 了吗？捂脸

2024 年 5 月 10 日

回复了 justdoit123 创建的主题 › React › react-hooks 场景下，如何在异步回调里访问当前的状态值？

@lisongeee setSubmitting 可以传入一个函数来修改当前值这个我知道。需求是要在 callback 里就能读到状态的当前值。

2024 年 4 月 10 日

回复了 imsoso 创建的主题 › 问与答 › 30+男装的归宿不是优衣库，而是海澜之家？

优衣库之前经常买，一开始感觉风格还可以。但是，后来发现质量都好一般，匹不起价格。

2024 年 3 月 29 日

回复了 justdoit123 创建的主题 › 问与答 › 电商系统表结构设计——曾经购买

@javalaw2010 嗯，是的。目前就用这个方案。

2024 年 3 月 29 日

回复了 justdoit123 创建的主题 › 问与答 › 电商系统表结构设计——曾经购买

@me1onsoda 所说的那种冗余方案，只需要冗余 user_id -> {product_id, order_id} ，不需要冗余整个 order 表。说到底，这种表更像是归档记录。

2024 年 3 月 29 日

回复了 justdoit123 创建的主题 › 问与答 › 电商系统表结构设计——曾经购买

@javalaw2010 那还得把 order 的状态也冗余到 order_item 里，要考虑到有些 order 是没支付就被关闭的。

2024 年 3 月 29 日

回复了 justdoit123 创建的主题 › 问与答 › 电商系统表结构设计——曾经购买

@felmoon 后期分析更多的时候是离线计算，暂时不用考虑。

2024 年 3 月 29 日

回复了 justdoit123 创建的主题 › 问与答 › 电商系统表结构设计——曾经购买

@aino 命中不高是跟产品做对比的，个人感觉而已。也行，那就对近期活跃用户做下预热。感谢~

2024 年 3 月 29 日

回复了 justdoit123 创建的主题 › 问与答 › 电商系统表结构设计——曾经购买

@aino 是这样的，能关联查询出来。问题是，这个关联查询目前只能通过 user_id 找到购买的 order 记录，然后从 order 再关联 order_item 表，找到曾经购买过的商品。

这个查询在新的需求里，很高频。暂时是加 redis 缓存，但是这种 per user 的查询，缓存命中率不太高。

2024 年 3 月 9 日

回复了 livin2 创建的主题 › Linux › Linux DE 与普通消费市场的距离到底在哪？

@terrytw 很赞同。打磨细节很痛苦很无聊很长期，没有金钱的诱惑，真的干不下去。

2024 年 3 月 9 日

回复了 RedisMasterNode 创建的主题 › 程序员 › 有人像我一样讨厌本地无法运行起来的项目的吗？

我感觉这是不能一概而论的。情况不同，处理方式不同。

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

我理解 OP 的感觉。我也很讨厌这种无法启动的项目。我觉得我们能做的事大概就是，在接手项目时候，所需要的适应时间成本一定要计算进去。这其实是切换上下文带来的时间成本，别说是接受别人的项目。回头维护自己过去写的项目，你可能都需要有不小的上下文切换开销。时间充裕了，至少不会因为时间问题加剧这种情绪。

1 2 3 4 5 6 7 8 9 10 ... 18

❮

❯