@Hanggi
1. V2EX 没法给自己点赞 2. 我也没开别的号给自己点赞 3. 这赞不是我给的
你看到 1 赞第一反应竟然是我在给自己点赞，能有这种脑回路，看来你经常干用小号给自己点赞的勾当？不去参与刷赞黑产简直屈才了你

我说的是 Go 标准库缺失非常多重要的基础功能导致标准库并不够好用，而你却一直企图用所谓的“你不理解为什么没有”之类的来蒙混过关。说难听点，我理解了又能怎样？能改变标准库事实上的确缺失很多基本功能，并不太好用的事实吗？并不能吧

还有我想把一件事问清楚，你张口闭口 Go 标准库健全、健全、健全的，那么请问你这语境中的“健全”到底是什么意思？现代汉语对健全的解释“①强健而没有缺陷。 ②（事物）完善，没有欠缺”，结合这个解释，你是到底是想说 Go 标准库没有 BUG 呢，还是想说 Go 标准库已经十分完善，没有任何缺陷不用改了呢，还是 Go 标准库功能方面已经十分完美了？

@Hanggi 做人不能太二极管，喜欢一门语言并不是要么爱死要么喷死。我喜欢 Go 并不意味着这些用得不爽的地方我也要用所谓“设计哲学”来洗脑自己让自己强行接受

Go 的标准库健全吗？或许你可以说 Go 的标准库“健”，但绝对担不上“全”的名头。我希望你能摸摸自己良心问自己一句：Go 的标准库它好用吗？注意是“简单”“方便”“功能全面”这层面的意思，至少我觉得 Go 的标准库完全担不上这个名号。而且更别提 Go 标准库那令人一言难尽、写得让人摸不着头脑的文档（这点你还真别跟我杠，去年 JetBrains 做的调查，关于 Go 标准库文档，我记得有 50%左右的人都觉得这文档写得不得要领、无法获得有帮助的信息）

go 用了挺长一段时间了，也写过不少业务代码，虽然很喜欢 Go 但也来抱怨下写业务时经常觉得烦心的地方：

1. 作为一门新生的现代语言，标准库功能之缺乏让人难以忍受。比如 Go 标准库里连个查找指定值是否在数组或切片里的功能都没有，所以理所当然的数组查找相关的所有功能（数量统计、获取 index 之类的）也都没有，都让你自己手写。当然，这东西写个 for 循环就搞定了，但每次不同项目里想要用的时候都得复制粘贴一遍的时候就不由得在心里咋舌一下。除此之外还有很多功能也同理。希望这方面能随着接下来泛型的发布有所好转

2. 写业务方面另一个感触就是，Go 的 DDD 实践没有太过统一的标准，所以参与不同项目经常看到各种风格迥异的 DDD 实践。光是我参与的几个项目就见过了从经典的分层架构到 Clean Architecture 的应用，再加上不同的人对不同架构有不同理解。。。。。

3. 现在写业务代码最烦的就是写 Entity 和 DTO 等各种对象之间的转换。大部分对象转换就是值一个个赋过去，手写起来烦得要死，找过自动代码生成的轮子也都是好几年前的不太好用，IDEA 里也没现成的插件。用基于反射的自动转换的轮子的话又有一定性能问题。相关的工具链方面还有挺多想吐槽的，记得 java 这方面工具链挺完善的？希望 go 啥时候这方面也能完善点

翻成定位呗

@logique goland 啊还能是啥


@hzzhzzdogee material theme ui 插件里的 Monokai Pro ，因为喜欢亮色主题，我把这个主题的所有颜色都取了个反色

@monetto 用过好多电脑配置再差也不至于一两秒吧。。。难道是项目或者 sdk 还没有索引好？

难道我用的是假的吗。。。。

这样 tab 选择对应的对象之后直接不就帮你导入对应的包了。。。。

https://i.imgur.com/I2LPqrp.png

@x66 你什么时候产生了远程桌面只能用电脑连的错觉。。。。 还有不建议像你这样放地图炮，windows 给普通用户输管理密码等同于 linux 下用 sudo ，你要放地图炮的话等于也在放 linux 系系统得地图炮

@BeautifulSoap 错别字订正：1.路过庆幸下自己 2.是一年发两次，每次发根据之前半年营收平分利润

路过庆幸走自己。。。我在的日本公司一年发两次奖金，每次奖金都是把公司当年利润的一定比例平分给所有员工。所以所有员工无论谁拿的奖金但是同样的金额。好处自然都能理解，但坏处就是公司营收不好的时候奖金就没了。。。。。

你们调侃了 lz ，lz 则调到了鱼，除了电池健康度魔怔人之外没人受伤的世界完成了

你是要直接访问 s3 链接还是要在 s3 链接外套一层服务再访问？

直接访问 s3 链接需要首先在 IAM 里配置对应的 user 和 user 的策略只能访问指定的 bucket ，然后获取到用户的两个 KEY ，然后用这两个 KEY 来获取。至于怎么在代码里用，直接找 aws 的 sdk 就行，用 sdk 里附带的 s3 类配合认证信息获取图像
但这么做有个问题在于你必须明文把 aws 用户的两个 key 交给客户端，而且用户多了不可能每个用户都配置一个 user

所以一般做法还是在 s3 外套个自己写的服务器，在服务器内鉴权，成功之后通过你服务器获取 s3 中的图片而非直接拿 s3 的 url

@starcraft 一加海外市场可不小，而且本来就是蓝绿厂的公司，不自己作死的话再怎么也不可能比魅族先倒。倒是一加的系统技术能力是真的值得诟病，每年出的机型数量少到和苹果差不多，结果自己的系统更新支持，bug 处理之类的拉跨得一塌糊涂

@gengchun 我作为公司里入职不到 3 年的普通小员工，当真受没有领导这头衔。不信？我之前发的在日本工作的帖子你可以看一下： https://v2ex.com/t/748274 （帖子里说有上下关系是为了不被特定出所在公司，因为奉行完全扁平化的 it 公司在日本毕竟少数。而且最近几个月天天 1 点多才到公司上班，虽然公司制度上这么做完全没问题但被特定出公司的话毕竟不太好）
我思考了一下，觉得可能是因为在日本工作大家都还算轻松，所以不太会像国内崩得这么紧员工之间小心眼吧

@gengchun 有被笑到，我平时说话遇到提交了不该提交的文件都是大概这么说的 “这 xxxx 变更、xxxx 文件是不该提交的内容，如果你平时只用命令行的话，我觉得可能是你习惯了 git add *还不确认提交内容，这不好可能需要注意下”当然，我用日语的所以实际字打出来的话会有对应敬语的修饰。

如果这种话在你眼里都是普通人都没法接受，所谓官威的话，那么你平时工作生活都遇到的都是一群心眼多么小的人啊？虽然不太想用这成语但“物以类聚人以群分”要不要思考下？

还有，不好意思我们公司奉行完全扁平化的管理模式，我们各项目组连组长都没有，所有开员工在职能上都是平等地位。甚至我们公司扁平化到普通员工的上面直接就是公司懂事们，互相之间只有新员工对老员工前辈的适当礼节根本没有职位上的所谓上级可以去要求或欺压别人。所以可能也拜此所赐我们公司氛围是真的很好，可能这也是比较少遇到你说的小心眼人的一个原因。

对了，都说了这么多楼了，你还张口闭口 gitgnore 是认真的吗，避重就轻简直死鸭子嘴硬。我就问你无论什么环境，写代码时临时加了几行调试用代码或任意的临时的代码，然后提交时忘了这茬提交前一行 git add *全给交上来了那么请问这种情况你给我配置下 gitgnore 给我看看？？这次你可以把临时代码提交上来，那么今后万一提交上什么敏感信息导致出事怎么办？当然我看你说的话也是个连最基本的这种责任感都没的老油条了，那也和你继续逼逼下去的需要了

@gengchun 我平时工作可是非常大度的，因为大部分人都是正常人，被指出来问题后至少都会接受，也不会去找各种原因来为自己狡辩。提交了不该提交的东西做错事了就是做错了，下次多注意就行，我也不会再多说什么。

而那位实习生我印象深刻就是因为他不光不反思自己 add *还不确认提交内容这件事的危险性和错误性，被指出来后死鸭子嘴硬全甩锅到.gitignore 上。和你的发言如出一辙，所以对你说话我毫不客气，也不认为需要客气，这反倒被你认为我平时工作就这样欺压实习生的态度，呵呵

至于环境什么的都没关系，只要继续 add *一把梭，无论你用什么环境怎么配置，今后依旧非常大概率会把不该提交的更改给提交上来

@gengchun 你这用来狡辩还不承认的说辞和我之前遇到的实习生如出一辙

问题在于有没有配置.gitignore 吗？问题明明在于用了命令行但却嫌麻烦偷懒，所以养成了无脑 git add * 的坏习惯还不改。
你可以配置自动忽略.DS_Store 但你没法忽略测试用的帐号密码，没法忽略临时改改但不想提交的变更？很多次 review 别人代码都遇到类似修个 bug 临时改了 log 类用于调试，然后修完 bug 后把忘了这茬把 log 类文件也给提交上来的了。这种情形只有写代码的人每次提交前人工确认一遍才能发现和预防，而 git add *一把梭的人大概率会出这种问题


话题回到 GUI ，你用过 GUI 的话应该知道几乎所有 GUI 都会以非常易读的方式展示修改的文件一览，每次提交前都会强制你手动勾选要提交的文件。这就相当于强制你确认文件变动了。当然真不想慢慢选的人还是会出错的，但出错概率至少比直接 add *要小很多