首页 注册 登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  RedisMasterNode  ›  全部回复第 9 页 / 共 30 页
回复总数  598
1 ... 5  6  7  8  9  10  11  12  13  14 ... 30  
❮ ❯
2023-09-23 18:15:59 +08:00
回复了 RedisMasterNode 创建的主题 › 职场话题 › 今天周六公司年会，发了个 1.6g 的足金小饰品
@littleYY 没事哥们 我们今天也算是加班
2023-09-23 14:11:54 +08:00
回复了 RedisMasterNode 创建的主题 › 职场话题 › 今天周六公司年会，发了个 1.6g 的足金小饰品
@so2back 跟 v 友们分享一下喜气
2023-09-23 12:53:10 +08:00
回复了 RedisMasterNode 创建的主题 › 职场话题 › 今天周六公司年会，发了个 1.6g 的足金小饰品
@54xavier 卧槽哥们快逃
2023-09-23 11:55:16 +08:00
回复了 RedisMasterNode 创建的主题 › 职场话题 › 今天周六公司年会，发了个 1.6g 的足金小饰品
@claylin 别的组不知道，我 975
2023-09-23 11:21:40 +08:00
回复了 RedisMasterNode 创建的主题 › 职场话题 › 今天周六公司年会，发了个 1.6g 的足金小饰品
@xianyv
@zapper 贱贱发出来恶心 v 友一手 哈哈 (^Д^) 家里人貌似很喜欢这个小饰品，我自己倒是不太感兴趣，但是确实还是值钱的。

如果是我本人的话，可能换成个主板硬盘路由器啥的也挺好
2023-09-22 16:54:27 +08:00
回复了 jiejianshiwa 创建的主题 › Android › Oneplus5, 一代神機, 6 年釘子戶
当年一加 1 从 14 年用到了 18 年还在服役，真的是神机。。。
2023-09-21 18:17:13 +08:00
回复了 sss15 创建的主题 › 程序员 › 说个微信小程序备案客服离谱的功能，我打包票一定是实习生写的
@sss15 时间如果+8 的话哪天去美国了是不是又会骂他没有-8 hhhhhhhh
2023-09-21 11:08:12 +08:00
回复了 RedisMasterNode 创建的主题 › 程序员 › 有没有能把本机（容器）的所有外部调用都转化成监控指标的小工具推荐
@wsszh 有趣的 repo ，关注一下，感谢
2023-09-20 11:56:43 +08:00
回复了 v2nika 创建的主题 › 程序员 › 为什么这么多后端开发上下游不分?
@yongzhenchen682 数据可以是提交数据，也可以是查询数据，你怎么去定义呢？

服务 A 向服务 B 查询了一堆数据，数据是从 B 流向 A ，所以你觉得 B 是上游，A 是下游；

服务 A 向服务 B 写入了一堆数据，数据从 A 流向 B ，所以说 A 是上游，B 是下游。

根本就没办法解释和通用地定义“流向”和“依赖”，文字游戏是没啥意思的
2023-09-20 10:47:30 +08:00
回复了 v2nika 创建的主题 › 程序员 › 为什么这么多后端开发上下游不分?
@v2nika 听起来没什么问题？一直都是这么用的。不需要强加自己的理解于别人之上，面试只需要表达清楚意思就可以了。

上下游的定义一直都有（至少）两类，

第一类: 按 action 的方向定义
上游: 指收到了哪里的请求 / 要响应给谁。
- 上游服务调用了我，我要响应给上游服务。
下游: 发请求给谁 / 从谁那接收它的响应。
- 我正在调用我的下游。

第二类：依赖关系
上游: 发请求给谁 / 从谁那接收它的响应。
- 我正在调用服务的上游
下游: 指收到了哪里的请求 / 要响应给谁。
- 下游服务调用了我。

面试里面结合语义这些东西并不值得纠结，而且既然不是个所有人都同意的东西，hh ，我也觉得会有人发帖：

```
为什么这么多后端开发上下游不分?
面试了不少于 100 个后端工程师, 初级到高级都有. 有相当一部分 (>70%) 的人, 都会说我做的服务调用上游服务如何如何.
为什么会这样? 只要认真思考一下, downstream 和 upstream 的概念不至于记不住吧?
```
2023-09-19 18:53:14 +08:00
回复了 RedisMasterNode 创建的主题 › 程序员 › 有没有能把本机（容器）的所有外部调用都转化成监控指标的小工具推荐
@ye4tar 比较接近，但是想要个解决方案，至少能把数据报给 prometheus （或者别的也行），它应该是个 Linux 系统能跑的进程才对，类似 Node Exporter ，但是 export 出去的内容是“外部请求的黄金指标”
2023-09-19 18:37:44 +08:00
回复了 BeautifulSoap 创建的主题 › Go 编程语言 › 踩到 Go 的 json 解析坑了，如何才能严格解析 json？
https://go.dev/play/p/8_2sAiXdrQ7

9L 的小 demo ，试了一下感觉应该挺好用的

type User struct {
Name string `json:"name" validate:"required"`
Age int64 `json:"age" validate:"required"`
}

testCase: {"name": "john", "age": 10}
result: <nil>

testCase: {"name": "john", "age": 10, "is_v2ex": false}
result: main.User.ReadObject: found unknown field: is_v2ex, error found in #10 byte of ...| "is_v2ex": false}|..., bigger context ...|{"name": "john", "age": 10, "is_v2ex": false}|...

testCase: {"name": "john"}
result: Key: 'User.Age' Error:Field validation for 'Age' failed on the 'required' tag
2023-09-19 18:19:39 +08:00
回复了 BeautifulSoap 创建的主题 › Go 编程语言 › 踩到 Go 的 json 解析坑了，如何才能严格解析 json？
我出两个小建议，但是可能都需要对全局代码进行查找和替换。不过改动量还算可控的。

1. 如果只是针对 json 格式和 struct 定义不完全匹配，可以用 jsoniter 库，通过这个配置玩一下：jsoniter.Config{DisallowUnknownFields: true}
2. 如果需要在 struct 上自定义 tag ，例如：required ，那可以提供一套自定义的 json 方法，里面先使用 github.com/go-playground/validator/v10 进行检查（支持的 tag 应该足够用了），再执行原生的 json 方法，方法签名保持不变

对于方案 2 ，全局的代码应该可以通过修改 import ，把所有的 json 包都替换成自行实现的 json 包，提供 marshal / unmarshal 方法就可以了
2023-09-13 18:35:34 +08:00
回复了 simyong 创建的主题 › NAS › 3000 元以内家庭自组 NAS 求推荐
便宜的价位大伙儿都推黑群为主，我也介绍一手我的，之前 NAS 小白（现在也时）的时期，想：
1. 要新净，不要太脏的二手（当然这个一般意味着没性价比）；
2. 要小，不要占空间，我选了 2 盘位的，4+4T 硬盘比较能满足需求，所以不求多，求迷你；
3. 容易用，所以不用装系统或者折腾。

最后选了 500 元的兮克 NAS ，跟蜗牛比起来应该配置会相对低一些，不过外皮是新的，感觉很满意。目前跑了大约半年，因为自己的事儿（装东西）重启过 2-3 次，没有因为机器的原因重启，楼主如果需求类似的话也可以康康，不过开销上比 3000 低很多，肯定也比一些 3000 的机器有更多缺点短板。
2023-09-07 12:31:12 +08:00
回复了 RedisMasterNode 创建的主题 › Go 编程语言 › Go 语言如果没有 ctx 传递，如何让 Trace ID 连贯传递呢？
@kingofzihua 很高兴在这里看到有人提及 skywalking go ，我也是其中的一位 contributor ，我觉得混合编译及代码生成是个很有创意的 idea ，因为项目比较新，短期内也没办法直接推广到公司用，未来看看其他使用方的反馈
2023-09-06 19:24:30 +08:00
回复了 blueboyggh 创建的主题 › Python › Python 如何提取两个字符串中的相同部分？
补充一句刚刚测试了一下大约 2000 字符的对比，其实很快很快，主要看楼主希望达到什么程度，例如最差最差接受 1 秒执行完，那是非常轻松的，如果是真的有 1ms 内处理的需求再考虑其他方案就是了
2023-09-06 19:21:08 +08:00
回复了 blueboyggh 创建的主题 › Python › Python 如何提取两个字符串中的相同部分？
>>> find_common_substrings(str1, str2, 4)
['haha']
2023-09-06 19:20:44 +08:00
回复了 blueboyggh 创建的主题 › Python › Python 如何提取两个字符串中的相同部分？
可以很暴力解决，如果数据量不太大

https://pastebin.com/raw/q3wf0h23

测试例子：
>>> str1 = "abcdefgandhahaok"
>>> str2 = "acsdefokokhhaha00"
>>> find_common_substrings(str1, str2, 3)
['def', 'hah', 'haha', 'aha']
2023-09-05 12:12:41 +08:00
回复了 RedisMasterNode 创建的主题 › Go 编程语言 › Go 语言如果没有 ctx 传递，如何让 Trace ID 连贯传递呢？
@paceewang1 我们之前在业务团队的时候倾向于用 ctx 传递，因为第三方库的方法签名不可控不可改，但是基本都保留了 ctx 。如果用 log 传递，或者说把 log 变量放在结构体内传递，它是对 ctx 的隐式使用，而且是 hardcode 的使用，无法分离出来给第三方方法用（或者说成本不如方法 1 ）

而这个帖子，其实不是想讨论如何改成传递 ctx ，而是说不发生任何业务修改的情况下如何拦截采集这种信息。因为想改动的人不是业务团队，也就是不是写这个代码的人，而是平台提供方，如何在极低成本（例如，只修改 cmd/main.go 方法里面的一两行）的目标下完成改造，（尽可能）让所有调用、日志都携带 trace 信息。

另外我们之前选用方法 1 做业务层面的改造时，log.Info(string) 改成了 log.Info(context.Context, string)，这个没啥好办法，都是全局的字符串替换修改调用方的，修改成了 context.TODO() 传入，然后等未来慢慢补全，实际落地下来感觉效果还可以的，而且有利于整体习惯养成。用 log 传递那是不是又不用设计 ctx 在方法签名里了？实际上这在 go 里是个不好的实践，相当于用 log 传递的方式，节约了 log.Info 调用的改造成本，但是继续保留了不传 ctx 的坏习惯，个人认为不可取。
1 ... 5  6  7  8  9  10  11  12  13  14 ... 30  
❮ ❯
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1879 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 34ms · UTC 16:21 · PVG 00:21 · LAX 08:21 · JFK 11:21
Developed with CodeLauncher
♥ Do have faith in what you're doing.