c++11 以后不要记得容器有 push_back 这个函数

一律用 emplace_back，这个函数会自动转发左右值引用

emplace_back 还有一个重载是用入参构造元素，所以可以

threads.emplace_back([&](){WHATEVER})

HDR=包围式曝光+算法融合，如果先用过相机上的包围式曝光就懂了

@tommy990607 本来就是这样的，每个目标用一个函数来实现，这是所谓的“面向过程”，关注实现目标需要经过哪些过程（函数），然后实现这个路径上需要的东西

C 不是一个 OO 语言，所以不存在“Array 对象”、“Stream 对象”。“流”是一个典型的 OO 概念，在传统 C 里是没有这种抽象的。

C 的思维： 数据都在内存里了，都能随机访问了，还套都一层函数干啥，吃饱了撑着？

@speculatorA 拿份工资跟帮其它成员考虑一步冲突吗？ 是不是拿份工资=有啥写啥，拿份股权=缺啥写啥，拿个公司=谁给钱做啥就做啥？


为什么“拿份工资”就不能缺啥写啥？

这就是 ptsd 。。

绝望感是错觉。

/t/581133 #255
/t/495443 #70
/t/570928 #13
/t/581133 #65
/t/490763 #4

讲流程没用，流程得有基础设施
我给你讲一下我们 30 人的团队都有哪些基础设施

- CI，不提，大家有手都会用

- 产品基础平台，包含前端和后端的一部分组件，由设计师直接管从出图到验收的全部分，从按钮文字到列表对话框动画等一系列 UI 都由它定义好，各产品的交互定义一律以基础平台为准，所以绝大部分页面不需要高交互原型，有没实现的特殊交互产品先跟设计沟通定成通用方案，做好后再引用，只有极少数 UI 是产品特有，则设计额外给设计稿。这个项目有一个几个人（含设计师）的小团队维护

- API 生成器；我们主要用 golang，有一个把 golang 特有形式 API parse 并输出对应前端使用的 (ts) 接口函数的编译器，CI 上会有 check 来保证 server golang 代码和 ts 始终能一一对应。这个 parser 项目由公司各个产品组的核心资深研发共同维护。

- jira 记任务，confluence 记 sprint 文档和任务汇总，并且与 gitlab 三方相互集成，在 gitlab 上的 mr 会自动创建任务的 weblink，保证每期迭代每个任务每个 mr 都是能相互关联复查的。各个内部系统的相互集成和二次开发，又有一个小团队专门开发维护

- 原型是放在 gitlab pages 上的，所有人都能随时检查，如果看不到则这个需求不会进入研发阶段，并且由于一直在线所以任何人随时都可以提出争议，无争议了才会通过评审

- 应急的时候我们的产品经理前后端代码能自己写，数据库能自己远程上去调试，哦不如说他还是核心研发角色之一










*其它的流程基本跟你描述的流程一样

通常是因为 makefile 的依赖没写好导致并行编译了互有依赖的过程

比如本来 A 依赖 B 编译时自动生成的配置，B 没编译时用占位数据来代替，这样就并行就会编译出不正常的 A

为什么你能确认这个局面是平台在操纵
而不是人性本来就如此？

@ajaxfunction 最好别跨领域挑战别人的饭碗

一个网站日流量 100 与这个网站后台包含 100w 人的信息之间没有任何因果关系
你的网站哪怕只是有一个可遍历账号公开信息的接口，那也可能存在着整站所有注册用户全部实名信息泄露的风险。因为可遍历信息意味着有撞库的可能，可撞库则可登录，可登录则有鉴权，有鉴权则很可能可跨业务查询自己的实名信息

不搞安全，你自认自己有这样的直觉和意识吗


说句不好听的，搞安全的，路过这种 pv100 的小破站哪怕直接能扒得底裤都不剩也没有挖出大厂一个犄角旮旯的业务微不足道的 xss 有成就感。因为可能这个 xss 能让这个大厂给他发实物奖励让他发在朋友圈炫耀，但小破站往往只会出来一个不懂装懂反手无威胁+报警的骚操作运维让他吃不了兜着走

lz，漏洞公开时间和流程是平台规定的。如果平台提早公开，是平台的问题，如果提交者未经平台披露自己先行公开，那他确实不受保护，可以予以追责

@tocherrygo 平台是提交人的保护者，事实上是平台在担保漏洞修复-公布流程的合法性和保密性

设想一下如果漏洞研究者直接提给厂商，厂商一边修复一边先送了奖励然后反手把研究者送公安那去破坏计算机信息系统罪+起诉敲诈勒索，他有什么自保措施么？完全没有

提交给平台，平台审核测试合法性、保证通知-修复-公开流程的完善性、担保厂商的修复奖励真实有效，这样研究者才有可靠合法的施展空间

平台直接公开了漏洞，那是平台有问题，你为什么会想到解决研究者？

我们目前的实践（ gitlab EE ）：
- protected: master 、R-*
- 开发分支随便开，命名要求由 ci 维护者制定，但不做特殊要求。这条的意思是，我可以写前端 check 只在 fe/*分支上跑，那么自然所有的前端 feature 都需要带 fe/前缀
- 设置自动发布环境的 CI，T-* 分支会自动执行发布脚本发布到测试环境，意味着你想要做前后端集成测试，必须把 fe/*分支和 be/*分支都 merge 到一个 T-* 上，由于 T-*分支不设保护，所以任何人都能进行 merge 操作，方便前后端联调
- 规定 R-*和 master 分支只允许从 T-*分支合并，由于分支受保护，因此仅有 maintainer 可以合并，他们可以拒绝不合规的 MR;同时这些 MR 信息必须使用模板，填写相关看板任务并通过 check list
- master 会集中所有主线修改，所有 feature 和修复优先进入 master 。当某个迭代周期结束后，产生该迭代的 release 分支 R-*，并且打上版本 tag 。 R-*分支只接受与该期迭代相关的修改 MR，如 bug 修复，该迭代结束日暂时没做完 delay 掉的 feature 等
- T-*分支的发布使用测试私钥签名，R-*分支使用生产私钥签名（与产品 license 相关）


其实只要用得熟练小团队也可以很完善很自动。一开始这个组三四个人的时候只有 master 、T-*、开发分支，现在全组大概 30 个人，也基本还是沿用以前的流程

为什么往一个库里怼不好？ 又不是往一个分支怼