V2EX › pastor 的所有回复 › 第 2 页 / 共 10 页

V2EX = way to explore

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

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10

❮

❯

2022-09-08 18:55:42 +08:00

回复了 zmlu 创建的主题 › Apple › 多少人喜欢灵动岛的？

相比余大嘴重新定义了什么叫“彻底没电“，这个至少丝滑一些

2022-09-05 13:39:49 +08:00

回复了 RedBeanIce 创建的主题 › Java › [mysql 字段] not null 还是 null default

@iseki
默认值不一定是 0 。
结合产品需求的默认值设计，我#33 已经明确讲过了，#42 有更多补充。

2022-09-05 13:37:28 +08:00

回复了 RedBeanIce 创建的主题 › Java › [mysql 字段] not null 还是 null default

@RedBeanIce #37
"请问一下，一个非必填字段。如何判断用户输入 0 ，还是 default 0 ，，"
—— 你既然根据产品规则设置了默认是 0 ，也就是可以给用户端 0 用来展示，那不管是不是用户输入的 0 ，都是正确的作为前端展示的值。
搞清楚一点，提高产品思维，这个前提下，实现业务逻辑的重点是为了产品合理性，而不是为了去满足你区分到底是不是用户输入的强迫症需求

#39 "产品规则可控，感觉好麻烦。。。。"
—— 我们程序员骂产品"狗"的时候，很多是因为产品不懂技术瓶颈压力、随便什么需求都敢提
—— 而产品骂程序员的时候也很多是因为程序员只考虑技术、不考虑产品

前阵子雷军不好举例子他亲自下场去当销售才体会到技术人员太执着于技术了做不好产品的嘛

嫌麻烦，其实就是咱没经历过好厂好项目好规范的训练，作坊式的生产、不规范习惯了导致了懒惰，然后反倒去以为别人这么做是多余、说人家麻烦。。

规范、严谨的工程，比如知名开源，或者硅谷那些知名厂的多数项目，规范化得多，提交、合并流程各种繁琐。说起来麻烦，但确实这很规范，大家都规范，也是对自己能力的提升

2022-09-05 12:24:22 +08:00

回复了 RedBeanIce 创建的主题 › Java › [mysql 字段] not null 还是 null default

@RedBeanIce #29

对于用户是否应该必填字段，产品规则是可控的，即使不需要用户输入；
默认值也是产品规则可控的，比如字符串类型，一般默认就""，用户如果可以不输入，""也没问题。数值类型 0 值同样道理。

但是数据库 null 对于不同语言处理起来可能会遇到不同的麻烦。而对于默认值。

不喜欢 not null default 的各位，建议还是反思下自己吧

支持 not null default +1
支持 bigint 时间戳 +1

2022-09-02 19:20:51 +08:00

回复了 rrfeng 创建的主题 › Go 编程语言 › 在学习 Go 的泛型，写了个模拟 async/await 的小工具，写的过程中发现个问题

@rrfeng “真搞不懂哪里来的优越感和这么喜欢批判别人”

补充一点，不是批判 OP 你这个人，是说这个语法糖这个实现

2022-09-02 19:19:32 +08:00

回复了 rrfeng 创建的主题 › Go 编程语言 › 在学习 Go 的泛型，写了个模拟 async/await 的小工具，写的过程中发现个问题

@rrfeng
这不是优越感，只是我这个人说话比较实在并且直接，你听了可能会不舒服而已。
至于为什么这样不懂得客气，是因为有过太多因为客气委婉、别人反倒以为自己没问题，所以我不想再客气了，有问题就尖酸刻薄地指出，至少对于技术本身，是中肯切实的

批判跟优越感也没有直接关系。
批判纯粹是因为你做的这个语法糖是一种倒退，如果没有其他人参与讨论我就不会来留言了，但是看到其他人也参与了讨论并且没有意识到这种语法糖是倒退，这就可能导致有更多人被误导。

同样有一些其他人参考其他语言做一些对于 go 而言是倒退的东西，如果力所能及，我也都会献上一些建议不要这样做的刻薄说辞

但我不只是空口乱喷，讲了一些点的，OP 要是能静下心来回到技术本身，对自己是有好处的

OP 不要纠结我的说话方式，你就当我是个没礼貌的小学生无视我的不客气好了。对其他人也一样，每个人隔三差五总会遇到让自己不舒服的人，我们没法改变环境，但是能适应环境，只要不是切实伤害，自己内心强大就无所谓别人客气不客气了

已经好些人说我刻薄之类的了，我自己也知道并且欣赏自己的刻薄。刻薄并不是什么坏事情，这世界，总是需要有一些刻薄的人的

良药苦口，忠言逆耳，认真思考技术就行了，共勉

2022-09-02 16:59:11 +08:00

回复了 rrfeng 创建的主题 › Go 编程语言 › 在学习 Go 的泛型，写了个模拟 async/await 的小工具，写的过程中发现个问题

这玩意相比与 goroutine 是倒退，跟你帖子主题说自己搞的这个东西是否牛逼没关系。

2022-09-02 16:57:14 +08:00

回复了 rrfeng 创建的主题 › Go 编程语言 › 在学习 Go 的泛型，写了个模拟 async/await 的小工具，写的过程中发现个问题

@rrfeng 我只是劝你别研究这种吃力不讨好的东西了，如果你目前阶段的修为 get 不到，就忽略我说的吧。期待未来的某天或许你会恍然大悟

2022-09-01 18:37:48 +08:00

回复了 dzdh 创建的主题 › Go 编程语言 › 在 TLS 上 Go 比 Nginx 厉害这么多吗？

遇到这种现象一定要相信是自己的问题而不是 go 真的牛逼到可以吊打 c/cpp/rust

2022-09-01 18:36:37 +08:00

回复了 rrfeng 创建的主题 › Go 编程语言 › 在学习 Go 的泛型，写了个模拟 async/await 的小工具，写的过程中发现个问题

@pastor #14 "二院" -> "而言"

2022-09-01 18:35:44 +08:00

回复了 rrfeng 创建的主题 › Go 编程语言 › 在学习 Go 的泛型，写了个模拟 async/await 的小工具，写的过程中发现个问题

go 的哲学，就是让大家从语法语义中解放出来，这种 async/await 的设计，其实本质上都不算是 lib 封装了，而是更偏于语法语义的语法糖的设计。不管花多少时间玩这种东西，到头来总有一天会想明白，发现竹篮打水。越早回头是岸越划算

2022-09-01 18:31:17 +08:00

回复了 rrfeng 创建的主题 › Go 编程语言 › 在学习 Go 的泛型，写了个模拟 async/await 的小工具，写的过程中发现个问题

还有就是，如果你的业务依赖这种同时多个异步的，最麻烦的地方并不是封装这种 async/await 的绕脑的写法，而是实际场景中每个异步请求可能失败后怎么处理。

这对于不同的业务场景没有固定答案，比如爬虫或者什么，失败了也影响不大；但是对于具有事务性要求的业务，这种同时依赖多个异步远不如串行顺序处理好。对性能有很高要求的八成也应该是依赖自家的基础设施，这种如果还能设计成同时多个异步，那说明你们整体架构已经出问题了、比如微服务拆分得非常不合理，这种要治病得从架构顶层往下梳理而不是脚疼医脚。

2022-09-01 18:26:46 +08:00

回复了 rrfeng 创建的主题 › Go 编程语言 › 在学习 Go 的泛型，写了个模拟 async/await 的小工具，写的过程中发现个问题

@rrfeng
第一，如果没有先后顺序，那有序调用也是满足要求的，for 循环挨个调用就可以
第二，如果有性能要求，同时去请求 10 个才能满足性能，那 wg.Add(10) go func() { defer wg.Done() ... } 也比 async/await 可读性舒服得多，如果这种异步量大这里可以用协程池而不是直接 go

对于异步理解比较到位的人二院，async/await 并不比 Promise 之类算是改进，相比于 go 可读性就更不直观了

2022-09-01 14:07:21 +08:00

回复了 rrfeng 创建的主题 › Go 编程语言 › 在学习 Go 的泛型，写了个模拟 async/await 的小工具，写的过程中发现个问题

协程本身就比 async/await 易用、可读性强，OP 搞这种玩意可以加深下自己对协程之类的玩法，但如果真应用到业务里，那就是坑队友了。

我昨天看了这个帖子标题手滑点进来都没看内容就直接就给关闭了，今天发现竟然有人回复，就又点进来

本末倒置的玩法，不值得浪费时间，奉劝各位早点散了吧

2022-08-31 21:17:33 +08:00

回复了 wenzaiquan199 创建的主题 › 问与答 › 为安全问题，早上公司热烈讨论

@hxndg 我对 tls 的描述不准确，感谢指出！

"一般如果没有明确的需求不建议自己定安全需求。"
这个除了少数安全要求很高的项目，绝大多数场景，都是程序员自己负责了基本的安全策略，不可能每个公司都专门的安全部门去指导业务开发来实施这个，比如我上面举例子的几点，虽然没人明确列出行业规范，但类似的实现也差不多是基操了。所以说没有明确的需求是正确的，但是业务程序员自己不去管安全需求也是不太正确的

2022-08-31 21:13:18 +08:00

回复了 wenzaiquan199 创建的主题 › 问与答 › 为安全问题，早上公司热烈讨论

@Al0rid4l #91
@shyangs #95

你俩这两楼误解我意思了。我上面举数据库的例子是为了说明任何措施不能保证百分百，还包括社工之类的。
因为我看 @Al0rid4l 的观点给我的感觉就是”既然前端不能百分百还做它何用“，所以举例子说明：
不只是前端，后端、数据库同样不能保证百分百，但是后端、数据库仍然要做；
进一步来反驳 @Al0rid4l “做它何用” 的观点，不是用来论证因为数据库需要密文所以应该由前端开始密文。

但是话说回来，至少我遇到过的合理的项目，都是从前端开始密文的，前面也举过前端页面别人 F12 的例子了，麻烦 @Al0rid4l 看明白了再来评判

2022-08-31 19:56:46 +08:00

回复了 wenzaiquan199 创建的主题 › 问与答 › 为安全问题，早上公司热烈讨论

@Al0rid4l 你看举的例子了吗？

前端的加密能防什么？
TLS 防的是什么？

这两点我前面说过了，再补充一些：
数据库为啥不应该存明文密码之类的，是为了防什么？
因为怕服务被入侵被脱裤之类的，不存明文至少防别人直接拿明文密码来登录然后盗资产之类的
服务被入侵的事件比例不是很大，但是数量还是很多

负责每个业务层次该的防的安全事项能做就做上，没什么不对的。如果照这样说，不只是 web 前段，即使是原生.so .a 别人也照样能反编译，只要肯花足够时间破解你，谁也不能保证自家代码百分百安全。后端我上面密码数据库不存明文也说了，自家服务都有被入侵的可能性。
所以，安全防护根本就做不到百分百！
那既然没有百分百，是不是就都不用做了？

我提醒你一下，首先认清自己是在地球，不是三体星，建议等你飞升到三体星在用三体人的思维思考问题，不要自以为懂地上来就一顿喷。
另外，"还有典中典的诸如虽然我研究不深但我觉得他挺专业的, 虽然我不懂, 但加密了应该有用吧"，这是我谦虚的说法而已，再研究不够深入，感觉也比你那一楼的看法要更懂吧！你还真以为自己很懂就来乱批判啊？

都说谦虚使人进步，我想进步，结果这咋还我谦虚使其他人自以为是了呢！
我要检讨！我不能再这样谦虚了，否则准被你们这些真小白带歪了节奏！

2022-08-31 19:45:38 +08:00

回复了 wenzaiquan199 创建的主题 › 问与答 › 为安全问题，早上公司热烈讨论

@littleylv 兄弟，绝大多数 cookie 或者 token 失效前，你先 F12 然后刷新下页面就能这样了

2022-08-31 17:01:37 +08:00

回复了 wenzaiquan199 创建的主题 › 问与答 › 为安全问题，早上公司热烈讨论

补充问一下：OP 家的数据库里存的也是明文吗？

2022-08-31 17:00:31 +08:00

回复了 wenzaiquan199 创建的主题 › 问与答 › 为安全问题，早上公司热烈讨论

1. https 主要是解决数据链路上的中间人问题，比如各种代理软件、甚至被黑客入侵的 ISP 节点。如果没有 https 、中间人直接看到你内容，太不安全了
2. 前端加密不全是为了解决中间人问题，比如考虑下公共电脑，上一个用户登录上去了忘记退出或者关闭，下一个用户 F12 一看，哦豁，上一个人的用户名密码都拿到了。甚至，比如你自己电脑，刚好自己上厕所走开一会忘记锁屏了，其他人“一不小心”就知道了你的相关信息。这一层加密至少提高了门槛，能把绝大多数不必要的低级泄露避免掉
3. 至于前端代码不加混淆，那是他这一层的安全问题，可以建议他们也加上混淆之类的

我对安全这块研究不深，但觉得 OP 家的测试提出问题说明测试还是挺专业的，至少相比于 OP 家目前的后端团队靠谱。

在自己舒适圈习惯了的人多数都不喜欢被别人提建议，这种心态不好，建议 OP 和一些楼层放下这种心态，平和一些对待测试。尤其是，更不要去随便鄙视人家，很可能最后发现小丑竟是自己。
我曾经也像 OP 和一些层主一样，抵触外界干扰，别人说点啥就觉得别人找事、别人菜鸡，但其实是因为自己还太年轻无知，工作久了逐渐意识到自己的缺点，然后花了很长时间去有意识地让自己改正。没什么丢脸的，自己进步了去争取做到海纳百川有容乃大，壁立千仞无欲则刚，于人于己，都挺好的

说的不一定对，欢迎批评指正或补充

1 2 3 4 5 6 7 8 9 10

❮

❯