真正有用的就这么三个：
沟通用 Slack 或者 Teams 选一个，微信一类的根本就不是为了交流沟通工作用的，设计方向就有问题。
开会 Zoom 或者有钱上 WebEx，效果吊打其它。有的甚至开个会都能串台你敢信？
项目 Teambition 或者 Trello 都可以，但你也可以试试 Jira，这东西唯一的缺点就是贵。

对于大部分开发来说，其实最好的是每周规定一两天必须在公司办公，用来保证和同事之间的沟通效率。其他时间可以自行选择在家或者去公司。
在家的话也要保证一定的时间内，比如上午十点到下午三四点完全在线。如果同事有事可以立刻找到人语音视频会议。剩下的你自己愿意晚上写代码就晚上写，愿意早上写代码就早上写。
不然虽然八小时工作制，但还要花两三个小时在路上。多出来的那些时间干点啥不好。

@fancy111 对，卫生间一定要监控上，不然很多人带薪拉屎。

所以说为啥不用 zoom，专业的事还是用专业的软件做吧。

onenote 最大的问题不是 license，而是微软对他的定位。
放弃了 Desktop 版本，强推 UWP。但是 UWP 的又没法打开本地笔记文件，微软的 OneDrive 很多时候非常卡，而且又不是所有人都喜欢把自己的笔记放在云服务上。
然后那个笔记文件用多了就变得巨大，同步起来简直是灾难。
但是从使用角度，没什么比 onenote 更好用的东西了。

目前一直用的就是 VNote 写 markdown，然后 markdown 弄到 Git 库里。自建 Gitlab 或者直接 Github 都行。VNote 可以很大程度上解决 markdown 插入图片等各种不适，纯粹的 markdown 也可以直接用各种东西直接生成 blog 页面。
缺点就是你只能在 PC 上写。

用这个玩意前提是团队有一定的合作概念，需要一些培训才行。
Teams 对标的是 Slack，不是微信也不是 Jira 什么的。没用过这类软件的人基本都会把话题直接当回复用。但只要培训了基本的用法，这类软件远比 IM 好用得多。
至于使用上，微软有直接在应用宝推广过 App 吗？而且微软的服务器确实是慢，不过比 Slack 好一些就是了。

@mrcn 不是
因为 C++不像 Java 或者 JavaScript 一类的直接使用源码（字节码也算直接使用源码了）它用的是针对平台特化的二进制。所以没办法像其它语言一样直接拉同样一份库就能用。你得针对不同平台甚至不同 STL 编译出一份来。也没有像 Maven 或者 NPM 一样的东西，不然同一份代码你得编译几十上百份二进制存进去。
我了解到的，主流的都是在你公司内部部署一个包管理系统，因为特定某个产品支持的平台一般都是有限的，所以你可以只放有限的几份上去。
你说的这个并不是主流做法，版本控制系统设计来是针对纯文本的，它的 diff 并没办法很好的处理二进制。你也不应该把二进制提交到代码库里。
正常做法是，你开发了一个版本的代码，CI 编译成针对某个或者某几个平台的二进制并生成版本号，然后 CI 把这些二进制传送到二进制管理系统里。
使用这些东西的项目，会在编译期由 Build Automation 系统去二进制管理系统里面查询对应版本号（你可以把架构直接写到版本号或者 product id 里）的二进制，并下载回来解决依赖。
至于你说的代码版本和二进制版本的对应关系，CI 系统会有记录。而且很多时候你也会把这个代码版本记录到二进制的包里，或者直接打到文件属性上。
不要把二进制放到代码库里还有个原因，就是你只放二进制的话没有编译环境记录的。CI 系统会记录每次编译使用的环境变量，编译参数，而且还有 log 可以查。而且你会把 pdb 一类的东西也放到二进制管理系统里。你在代码库里提交一个二进制，甚至都不一定能和代码对应的上。到时候出了问题查起来就是灾难了。

C++的依赖管理有几种。
vcpkg，conan。或者包进 nuget 里。我们自己用的一个魔改过的 Gradle。
其实改个 Gradle 插件是最简单的，或者 Conan 也可以。直接用 Artifactory 存编译好的二进制。你在编译的时候需要的依赖都会拉取对应版本到本地，解压链接进去。如果本地有的话那就直接用缓存。
自己控制好版本和 Arch 依赖关系就可以了，改个现有的系统的话，这些基本都有办法解决。
其他的不推荐，特别是你这种做法。到时候部署版本出了问题，你都没办法追踪依赖版本。而且根据环境不一样，有的时候你编译的二进制也不一定一样。这时候你再去追踪调试就更没谱了。
依赖最好是固定好的，对于 C++来说，不要去直接依赖代码。除非你是 boost 那样直接复制进去就能用的，不然全部都依赖二进制。然后这些二进制如果是开源的最好你要么直接依赖官方发布的二进制，要么全部自己编译。而且记录好编译环境参数等信息。有些项目在编译的时候会读入环境变量，这种你更没法控制发布版本了。
所有你依赖的库，全部都依赖其二进制。然后编译过程中通过依赖管理系统去下载这些二进制，让依赖管理系统去解决版本号，Arch，冲突等等问题。不要自己手动去解决。
你现在这种做法不出问题就罢了，真的你哪个依赖库有问题导致发布版本出错，查都没得查。

一个佛都只渡 VIP 的地方，还有什么好说的。

@opengps 然而发现这么多年也没用到 int 上限？
其实你要做分布式的话，UUID 就比 int 好啊。如果只是单一数据库，那直接 int64 就完了。

@barble 我手里也没这种音箱。不过按理说这广播应该没什么用，除非是多机联动用的。就是你家比较大，几台音响互相之间可以广播不同屋子录下的内容。不然它这个功率泄露不了太远的，除非你用一个特别牛逼的天线去接。
但是要真是多机联动用这方案也是脑洞清奇，说明完全没把你隐私当回事。。。

早就不敢用百毒的东西了。。特别是 AI 音响这种。
不过这就过分了吧，把采集的环境音广播出去？这是人干的事？

不会，因为知道怎么远程办公的领导太少了。自己导致大家效率极端下降，完了再来一句咱们不适合远程办公。
这都什么年代了，需要 VPN 远程桌面回去写代码你敢信？就这样还怎么远程办公。

安全只能靠人的意识和策略，只靠技术是没用的。VPN 和 FRP 本质上没什么区别，你只要能访问到内网，那该炸就一样会炸。
作为公司而言，首先要确定对于自己来说什么东西是核心资产。绝大多数公司并非造火箭的，代码本身不值钱。是产品数据库重要，还是自身的销售渠道重要，还是真的代码最重要自己要想清楚。安全防护保的是核心资产，其他的价值没那么大。
比如你做互联网产品，那么生产环境是要彻底隔离开的。哪怕是在公司也不应该让开发人员可以直接访问到。这种情况开发人员在家办公还是在公司区别不大，只要做好代码库隔离，不要一次性把所有产品代码暴露给某个开发人员就可以了。

@kangsgo confluence 功能上没有可以与之相比的，而且教育折扣是半价。
两年前给公司选的时候试用过几乎所有的同类产品，功能上没一个能打的。
唯一的缺点就是性能一般，数据量大了以后需要堆硬件。贵不是缺点

@chenqh 如果你觉得以后会支持前端跑在不同时区，比如从国外访问，那你数据库就存 UTC。
查询的时候让前台给你传 UTC 时间。或者只存个 offset。
一般这些 ORM 都可以给你做了，配置一下就好了。
如果你这个产品从头到尾都不会有人在不同时区使用，那就直接本地时间也没问题。

大写字符是 65~90，小写是 97~112
二进制是 0100 0001~0101 1010 和 0110 0001~0111 1010
比如
01010001A，变成
01100001a

你可以直接翻转第六位，就是异或个 0010 0000

这个 0010 0000 在 ASCII 里面代表空格，所以你直接异或一个空格就可以。当然你得首先判断它是字符。

ASCII 当初就是这么设计的，大小写基本都是对称的位置。
另外虽然 ASCII 用来编码字符，但是对应数字那部分都是 0011 开头的。你把这部分 mask 掉剩下的就是字符所表示的实际数值。

兼容的 UTF8 也是一样的。不过正常来说，你要做一个完美的大小写转换，需要先判断 culture 才行。不过简单的可以就这么直接做了。

如果是兼容 ASCII 编码的字符串直接位运算就可以。