[test()] * 5 有问题，都是同一个实例

（假设你要 ping 的地址是实例化的参数，那更容易理解 [test(ip)] *5 这样错在哪里了

搞 windows 服务器维护，或者在自己电脑上折腾些小玩意的时候很有用。做一些系统配置，可以直接用 powershell 一两条命令搞定，微软官网的文档也算全面，能很方便搜到。如果用 python 做，不一定有库支持，或者实现方式比较怪。

powershell 能调用.net 类库，能写非常复杂的功能，不过我断断续续用了一两年，也没用多深入。当面对复杂需求的时候，更倾向于将具体跟系统交互的部分写成 ps1 脚本，然后用 python 调用它。
在学习新技能方面我觉得“够用就好”，根据工作需要来。我们都是一块砖，那里需要往哪搬

机械键盘这点声音小意思，开放式工位日常充斥着各种人讨论工作的声音。
airpods pro 顶不住的话，就去搞个头戴式+主动降噪的，播着歌，能隔绝大部分噪音

大四实习的时候，我看了 surface book 跟 mbp 的发布会之后就一直在想着要换笔记本。
等到毕业公司发了老款的 macbook air ，性能一般，屏幕一般，用了大半年我发现自己对笔记本的需求就只是用来远程自己台式机，就打消了换电脑的念头。

换工作的时候把 mba 还回去，又起了买笔记本的念头，又是看了好久的评测视频，对比来对比去，想要搞个 surface go ，开会的时候用来做笔记，展示想法 blahblahblah 。。多酷啊
等入职新公司，开会要不忙着打代码，要不听老板讲话，要不摸鱼。公司发的 13 寸小米我都嫌屏幕太小，买来的华为平板沦为 bilibili 启动器，于是又打消了买轻薄本的念头。

以上是废话。之前看到一个观点，叫做要为了解决问题而使用工具，而不是为了用工具而去培养习惯。比如你像我一样日常不用笔记本开发，那笔记本性能多厉害都是浪费；比如开会不喜欢做笔记，那带个电脑过去也是累赘。
有很强烈的需求，再去升级换代就顺利成章。比如你重度依赖笔记本而它是台老爷机，影响你使用效率，或者我一天玩几个小时游戏，而最近玩新游戏卡顿得厉害，之类的。

这得看人，伴郎伴娘不是必需品。
我亲姐跟亲姐夫平时生活都比较低调，结婚的时候就正常走个流程，没有安排什么游戏唱歌跳舞之类的。我挺喜欢这样，以后结婚如果对象能接受，那就这么过。
参加过其他几场婚礼，搞了一堆游戏环节，又唱又跳的，作为客人我觉得 ok ，但是我自己不想要。。

明天才开工。今天醒来打开电脑，年前玩得起劲的游戏。。突然没兴致玩下去了

你说的这个需求，应该是 mock server 干的活。有些前端框架会直接集成 mock 服务，比如 antd pro 。
不过我也没用过哈哈哈，配置起来方不方便，你得自己试试。
要我选的话，我选择用 flask 快速撸个后端出来，定义下路由，直接返回数据，写起来也挺快的

我的印象还停留在五六年前，看了微信还是 QQ 的一篇技术文章，分享他们是如何控制安装包大小的。
那会安装包大小普遍在 100M 左右，超过 150M 就不能通过 4G 网下载了。

不过当时手机存储很多只有 16G ，现在动不动 256G ，5G 也在慢慢普及了。。压缩安装包大小还能有什么收益，还是做需求要紧（滑稽）

缩进被删了有点麻。if 折行之后下一行是两个缩进的距离，为了 if 里面一个缩进的语句区分开来

折行呗，大概长这样，也不用什么括号

```
if cond_a \
and cond_b \
and cond_c:
pass
```

这真的是围城。
不知道楼主现在是哪个阶段，我自己想的是等 30+结婚生娃了，就找个国企当做最终站，有空带带娃做点小项目，只要工资能应付贷款之类的就行。

上次听同事说他前同事也是年纪轻轻跑去电信云，干了不到一年就跑路了

搜狗。用了有十年了。一开始打动我的功能是按下 u+部首偏旁，就可以打出字。还有自定义短语之类的。

没，刚好昨天生日，回了趟家，过完生日直接跨年。

有三倍跟调休的话，还是不亏的。我们那 8 小时算一个工作日，加班 12 小时算 1.5 天 x3 倍，薅公司羊毛的好机会。
回头随便找个周末+调休，回家就是了。
挣钱嘛，不寒碜

有测试的话，就简单自测主要逻辑，然后交给 QA 测，有时候状态不好，能让他测出来一堆 bug ，修着修着，代码就走样了，有时候上线了也不安心。
没 QA 就要全部自测。自测完还出问题的功能，一般情况是漏掉某些条件分支的处理，十分钟内查日志修 bug 重新发版，快得很。

if 写得太暴力，看着简单，逻辑反而弯弯绕绕地

不如开空调或者暖气，让房间温度适宜一点。
我房间除了大冬天没有暖气确实冷，秋天或者夏天开空调，就算不盖被子也不容易着凉。

有点点强迫症，自认为是对自己代码比较负责的，之前也给项目内的同事做过 code review 。总体感受就是，shit 山是无法避免的。

追求完美是不现实的。代码开发是要解决实际问题，而需求是不断变动的。你无法预测到两三年后的功能需求，打补丁是在所难免的。
你无法保证自己每一段代码都是“完美的”，你也无法保证每个同事都对自己有高要求。即使你能保证自己的设计思路一致，别人再接手的时候，也不能再次还原你的想法。时间久了就夹杂着每代开发不同的“想法”在里面了。

反正我已经看开了。之前卡同事的代码卡得比较严。现在只要别歪得太离谱，我会先给过。
搞 code review 是累活，不少团队 leader 嘴上说着要有追求，要规范 blahblahblah ，等到评绩效的时候就对你的付出视而不见。
我会尽量保持对自己的要求，跟同样有兴趣的同事交流。至于其他人，我真的管不着了