@invictus 平衡轮更别说，不是个通勤工具，就是个玩具。

@invictus 哦对了， 还有一点
在地铁站平衡车是不允许骑行的，所以只能拎着或者拖着，米家的九号可以装一个延长把还好，胖九装不了，所以三十多斤的玩意儿拎着很麻烦。
而且这玩意你别想拎着上楼。
滑板车稍好，可以推着，但是也别想拎上楼，至少天天拎着很重。

@invictus 不建议，平衡车不适用于：
1、人群流量较大并且非机动车较窄的路段；
2、路面颠簸多坑、多陡坡、多沙子石子的路段；
3、泥泞、涉水区域多的路段。
个人骑行数千公里，亲身体会，而且平衡车在事故方面不受法律保护，上路就算违法了

@CF3B5
我俩站的角度不一样。
你想表达是程序员作为主导的项目中，程序员应该有的素养。
而我所站的立场，是在项目开发过程中的程序员应该做到的，需求既定的情况下不应该贸贸然改动。
如果把你今天这一堆观点和起始事件剥离开来，单纯看你的观点，我举双手赞同，程序员应该做到进步无止境，无论是技术还是风格。
而回归到你“现在做程序员（工程师），难道不应该考虑自己负责的产品设计工作吗？”的标题，应该考虑，事实上就必须要考虑。但是这个考虑是在需求文档确定之前的，确认开始开发之前凡是不符合规则、不符合实际、存在问题的需求，都应该被改正过来。
需求既定的情况，就要做好程序员的本分。本分是什么，拿着别人的钱，按照别人的要求开发出合格的软件，这个合格是主导项目的人来制定规则的，而不是由程序员。
之前我的言辞过于激烈了，很抱歉。

@CF3B5
而且需求是需求，技术是技术，别把两者混为一谈。
项目的需求，从下发需求文档、批注、评审、签字，这么长的时间你想改什么觉得有什么问题随便提。都签完字进入开发阶段了，除非涉及到流程不正确会卡死或者存在非常非常大的问题的情况下，会采取通知项目负责人和开发负责人以及相关人员一起修改，否则谁来说都应该是不做不改，你是产品经理还是咋滴，这个项目你是负责人吗？你要改大家知道吗？产品知道了吗同意了吗？
技术是另一回事。我这边项目开发完，每个人都有自己的学习计划和技术分享安排，爱搞权限的搞搞 shiro/security/jwt/sso 之类的，爱搞数据库的搞搞 es/elk/mongo/pg，爱玩网络的搞搞 nio/netty/dubbo。程序员这方面做的不好，不愿意学习，不愿意按照你的要求做技术调研，这个你可以随意喷，开了都是你的权利。
“只要需求完成了，不出 bug，绝不会改第二次，还觉得这才叫负责”，这就是负责，需求都完成了还没 BUG，只要代码 review 没有明明白白的错误（我们这边是违反阿里 java 规约、或者存在明显不合适的实现方式的时候），你凭什么要去改别人的代码？

@xuanbg 他不能每个都参加，那么至少项目应该有开发负责人吧，开发负责人吃什么饭去了？有问题来怼一个程序员而不知道和产品沟通、不知道问责负责人，我不明白这人什么思维。
而且话说的很明白了，“产品经理的文档就是要求做成这样子的……”，这句话明显就能看出来需求早就确认了，而且已经开发完了，谁允许这个所谓的“技术负责人”越过产品经理或者项目负责人直接改需求的？

@CF3B5
我的观点就是你有毒。
你觉得有问题第一步要找产品经理，都进入开发阶段了，还直接让程序员改，有没有一点规则概念？？？？
这不是你一个人过家家的事情，前端、后端、交互、UI、测试、产品，多方共同参与的。都进入开发阶段了你有问题就应该找产品、找项目的开发负责人，而不是扯一个程序员来批判，有病吧？
我做项目，别说你技术负责人，顶头 boss 让我不按照需求去开发要我改东西我都不搭理，都进入开发阶段了，你要改可以，找齐产品、开发负责人、测试负责人，需求变更的会议记录通知到所有人，不然改出事情了归谁？早不说干啥去了？还一大堆大道理，一堆的“我们当年”，还一堆的“感觉”，看把你能的。

监控 mac 温度，可以考虑 istat menu，可以监控温度、cpu 使用率、内存、网速、硬盘之类的
发热的话，基本没办法

这个距离，最适合的应该是自行车，不用高级的就只需要普通便宜的自行车
如果有共享单车，而且数量比较多不会大清早一起来就没了的话，最好了。

@cuikai1 步行 2.5 公里需要用时 25 分钟左右，自行车骑行需要 6-8 分钟，电动车需要 5 分钟

我一点点来说
第一点，丢失的概率，消息是会丢的、会失败的、可能要回滚的，RPC 立即返回结果或者使用 netty 之类的 NIO 框架管理 channel 返回结果，在这个角度上是 RPC 优于队列的，队列最大的好处是可以积压，但是最大的坏处就是本质是异步无法直接知道结果。
第二点，负载均衡，Nginx 是用来做什么的，要负载为什么不让专业的来而要自己来靠队列来实现均衡？
第三点，nginx 完美解决你的问题，发送端和接收端只要对接 nginx 就可以了

如果让我选择服务间通讯，我毫不犹豫会选 RPC 框架，实现简单、同步结果，项目简单的话我干脆面向 socket 编程，越粗暴越简单越好，再上一层就 NIO，多节点就上 nginx。
多了队列，就要维护队列、路由、TOPIC，要多一个 MQ 的监控和运维，要多考虑异步失败处理，要多个队列 listener 线程池和一堆相关的事情。

把你的“任何”去掉就是我
事有轻重缓急，我在做项目开发或者个人重要事情，杂七杂八的事情我理都不理，做完再一起处理，重要的事情中断工作立即回复。
如果是在摸鱼、非重要事情时间，不想搭理的回绝，不想做的解释一下，要做的加到 todo-list 慢慢处理，加急的立即处理。

个人建议
连续佩戴不要超过 1 个小时！
长时间佩戴尽量使用比较透气材质的头戴耳机，音量不要过大。不推荐长期使用入耳式，如果有隔音需求，可以考虑索尼经典降噪头戴耳机。

我说一下我家和我住宿的时候方法
1、平时所有外界蚊子会进来的渠道全部阻断，窗户加纱窗，门不大开
2、出门前雷达杀虫气雾剂喷遍角落，回来的时候开窗透气十分钟然后关闭
3、基于以上措施，基本没蚊子了，然后再弄一个雷达驱蚊液放床边上或者书桌底下，以防万一

非大佬。
1、函数中传递的多是引用，数据已经从 db 中拿出来放进内存了；
2、内存中，就算大对象，拷贝也比较快，如果真的很大就已经崩了；
3、建议，db 查询对象的时候，如果能预见对象字段较多数据量较大，就提前做好准备，比如分页分批查询、只拉取有用字段；
4、大量也看多大，几百上千的无所谓，真的一次 pull 个百十万，换谁来都爆，这时候就性能优化吧；
5、有的时候，数据量很大的业务，看看能不能先 sql 处理加工一次，比全部加载到内存里面好一些

如果是 IDEA，并且用自带 GIT 工具提交的话，可以大家都导入一份同样的格式化配置文件，然后提交 commint and push 的时候勾选上自动格式化的选项
话说格式化是必须的，而且规则要一致，不然两个人改了同一个类，提交或者有冲突的时候会疯。

@tom
以你所举的例子，我分两种情况来说：
1、A 表每条记录关联 B 表中一部分记录，并且可以以 GroupBy A.id 之类的方式进行统计，最终需要的结果以 A 为主得到 B 的关联统计数据。这种情况好好捣鼓 SQL 应该可以一步到位，拉数据的时候可以对 A 先做分页和限制，一批一批计算和拉取系统压力会小一点；
2、A 表每条记录都要和整个 B 表进行关联查询，并且 B 表整个表都有用。这种情况，没有实际业务场景下就只能说暴力轮询吧，如果内存扛得住就把比较小的表全都载入到内存中，然后大表分页分段来遍历处理，扛不住就自己设计笛卡尔积计算流程吧，大概就是 A 一批 B 一批，然后计算结果保存，最后汇总。

1、数据同步到本机的时候，是否会写入到 DB 或者 ES 中？可以考虑在存储的时候添加额外字段便于统计；如果不方便在原表上统计，可以根据记录主键建立关联表进行统计；统计的结果，可以放缓存累加处理
2、缓存框架，个人觉得用不到，要用到缓存的场景在这个需求下面可能就是一次性把目标记录全都载入然后一次性处理，如果记录数过多很容易出问题，不如换成迭代的方式，分页一批一批搞；
3、如果题主所提及的缓存框架是为了存储这几十万数据，马马虎虎也行，但是非结构化数据存储、解析还是费工夫的，来回折腾的话，有点麻烦；
4、个人建议同步归同步，处理归处理，统计归统计；边同步边统计的话，一方面万一系统挂了重启了又要从头开始，另一方面代码分离各搞各的好配任务（个人习惯，仅供参考）

@javlib 用 redis 还快一点，乐观锁重试失败不如竞争 redis 锁的性能吧
其实也要看业务的复杂程度，如果本身失败的可能性不高，冲突的几率很小的话，乐观锁也够了，实现起来还简单
但是如果并发的概率比较大，业务的要求还比较高的话，redis 分布式锁更好些。