@x940727 #110 不知道是我说的有问题，还是你理解有偏差；我说除了要造轮子——那是因为相对 Java 来说，确实是缺不少成熟的企业应用的中间件；某些情况下没有合适的就要自己造轮子

要造轮子的意思，不是所有都要造轮子

@monkeyWie #19 说的好像我没用过 java sprnigboot 一样。按照我们这边的实践，go 写业务除了要造轮子之外，没有多难受。恰恰是毕业 1-2 年的同事，前后维护过 java 与 go 的项目，都说 java 用起来难受

tailscale ，对方电脑设置 subnet router

Subnet routers and traffic relay nodes
https://tailscale.com/kb/1019/subnets/

对一些人来说，只要每年年底都有公司裁员，对他们来说都是一样的，只是裁员而已
他们不会关注裁员比例、行业、方向诸如此类，也不会关心为什么裁员

就好像某个段子那样，野外遇到一只熊，要怎么做？对他们来说，只要跑得比你快，或者踹你一脚让你跑不了，就可以

与 c/c++中指针与值概念是一样的，只是用起来没有心理负担

A：指针传递，可修改其值
B：值传递，不可修改

对于 go 来说，若你想修改某个参数的值，就需要拿到其指针

如果还是想不明白，不妨没事研究下自己住的小区。从小区区域、栋、楼层、房子、房间、房间内部装修
当然，还有水电气诸如此类

架构跟语言没有关系；楼上 N 多人过于纠细节，只见树木不见森林；简单来说就是分层+模块化；一般分层是纵向划分，模块化是横向。
说白了就是要拆。解耦很重要，所以不同系统、服务、模块之间，要增加接口进行隔离；接口要定义清晰

1. 分层（纵向划分）
比如对于 C 来说，因为会涉及硬件，所以一般是。当然，也可以对于某一层或某一模块，也可以根据需要进一步划分
业务 <-> 业务接口 <-> HAL （硬件抽象层）<-> 硬件驱动

2. 模块化（横向划分）
比如 HAL ，要支持不同的硬件接口（ bus ），要支持不通的通讯协议。不同硬件接口与不同协议支持，就是横向（模块化或插件化）

tailscale

若有自建后台需求，tailscale + headscale

汇丰养老+1 ，很多前同事都去了。汇丰 很多外包职位，但也有本部职位

早会要说的其实就是，昨天做了什么、遇到什么问题（资源协调或配合）及今天安排

对于我来说（团队或项目负责人）的好处是，
1. 团队内不同同事之间的交流明显会多起来（氛围）
这里说的不是早会，是推行早会之后日常工作中同事之间的交流沟通

2. 团队成员有问题或及时跟我沟通
3. 我可以了解潜在风险，进而调整计划、协议资源或人员
4. 可以对架构、进度与设计进行监控

写个测试客户端是最好的，可以验证通讯、协议、业务，还可以做压力测试

asm

智能理发器。现在搞智能硬件的，真的是随便加个智能都可以搞
真不知道这个有什么太大的实际意义与需求

一个人的行吗？把我收购了

1) parsec
2 tailscale + rdp/vnc

可以尝试下好未来的 go-zero ，单体或微服务都支持。我们就是基于这个框架的，前后已有三四个项目都是
使用体验还算可以

orm 可以可以用其自带的，也可以替换成 gorm

不过只能说 go 或者真的戳到某些人的痛点
像我们这边的，毕业 1-2 年的原先做 c++/java 或前端的同事，拿本书 1-2 周过一下，就可以用 go 写业务代码

我是真的很想知道，楼上诸位说的业务代码，都是些什么业务代码？
不就是数据库表 model crud 、api 设计实现；业务处理逻辑；第三方系统对接？

难不成还有别的什么不成