想起一个叫 Rolan 的... 虽然后来被 Claunch 替代了

动手能力可以的

@Wind2Illidan 呃, 不习惯用二手, 过几天直接买也才 200 左右. TTC 不习惯还是矮轴不习惯啊

之前扫过一眼, 那边机会确实挺多最近上海的猎头也推荐去那边, 后来因为有那种 "某些文化向社会输送了太多人才" 的顾虑, 就直接排除了那边. 主要还是怕自己格格不入

大项目参考一下 git flow?

十人以下的考虑 Github flow?

尽量避免不同的人开发同一个文件 /模块, 是不是底层抽象的不彻底

查 ip 还是别用免费的这玩意了...

之前请求次数稍微多了点(三秒一次, 一共几十次), 直接封我公司 ip 了, 而且有时候不稳定. 刚才我这里电脑打开第一次失败, 刷新才成功. 不过准确度来说貌似还挺准

刚毕业时候单休, 10 8 6, 干了 4 年 2019 体检多项指标过了警戒线, 直接裸辞, 用一年时间修养锻炼身体(顺便照顾身体不好的父母), 所有指标基本恢复到巅峰期, 并且那一年把四年工作里学到的东西整理总结顺便开源, 准备找个二线沿海城市定居, 结果疫情来了...

不得不又跑到北京过劳肥了两年, 开始的一年加班确实多, 但是做的事情我都挺喜欢也就忍了, 后面的大半年实在没业务可做了(PM 走光了...), 身体也又出现一大些新的警告信号, 所以想换个环境了, 倒是也没遇到过内卷或者 35 危机, 顺其自然地换个城市 WLB 一下

说个另类的方式, 以前公司 Google Sheet 里面搞的, 也大概百万行左右, 开了多个文件(按日期 /类型 /部门进行分组), 用了很久一点问题没有

1. 有额外需求, 直接用它自带的 App Script 轻松连接其他表格或者直接连到数据库上去, 各种复杂逻辑都可以搞定, 只要会点 JS

2. 比较严格的权限管理, 帐号本来就用的 Google 单点登录的

3. 谁修改了敏感位置的数据, 有邮件提醒甚至有修改记录, 遇到数据异常可以选中评论

4. 各种图表 / 透视表 / 导出到 BI 都是现成的免得开发

5. 数据增删改查除了人工操作, 也可以走 SDK, 或者走表单, 都挺简单

虽然是题外话, 不过当时用的时候真的省了很多开发人力(开发的人不多, 可以说很低代码了, 不用整前后端直接就所见即所得)

我老家那边直接 IT 荒漠, 最后只能选临近的江苏, 最近江苏疫情管的太严了, 直接过不去

从 boss 直聘上看, 南京 苏州 无锡 常州其实岗位也不算太少, 但是稳定不累的在 boss 上没看到... 总体来说国企和外企相对会遵守劳动法, 可以参考一下, 最好两年时间把自己磨练一下, 而不是 CRUD 体力活虚度过去, 等你把手头技能玩明白了, 会有猎头开阔你眼界的

骨折期间自己试过一次

1. 用那个雕刻的推的, 推完了锋速手动刮胡刀刮. 前者剃完其实几乎看不出头发来了, 不过能摸出来, 没出血; 后者, 把痦子给蹭破了, 不过剃完以后摸不出头发的感觉

2. 剃光头再长出来, 我头发没变多

买了仨 ikbc 了, 打算新入个 s200 红轴, 不知道有坑么, 200 出头费电慢还是挺好奇的, 最关键就是矮轴到底能打不能打

以前夸克, 后来 via, 后来 x 浏览器至今

反正在我这里功能越少越纯粹(没有资讯推送), 就越省电, 反正我又不一直开浏览器

试过了多种方式, 最后我决定离开某个浮躁的城市.

@Richard14 不丢人, 这问题谁都遇到过, 当初让我懵逼了一星期

关键遇到这种问题完全不知道该怎么搜, 用尽了我的 lowb 英语词汇量才搜到的. 属于那种反直觉的常识, 只能靠经验完全没思路

1. htop 里 K 9 干不掉, 多数情况是权限不够, 在命令行手敲命令看看是不是报了权限不足, 必要时候 sudo

2. 还有一种情况是进程有守护, 所以要看一下进程 ID 有没有变化

3. SIGKILL 程序是不能捕获的, 常识性问题

先别着急看代码, 不然学了也知其然不知其所以然


按顺序推荐把以下基本功打牢一点(因为不知道你是什么语言, 所以不推荐书籍了)

1. 面向对象程序设计. 了解一下面向对象的大致原理, 不求一次看懂, 以后还会再回来看一遍的

2. 软件设计原则, SOLID 那些

3. 常见的设计模式及使用场景, 其实也是围绕上面的原则的各种实践场景

4. 实战相关的代码可以入手了, 因为不知道什么语言, 所以可以先看一些偏官方的代码, 不一定要看多知名的, 很多时候官方的代码也有不少经典代码(也不排除有些老代码挺难懂)

5. 软件架构方面的知识积累, 最常见的场景就是根据业务需求统筹代码架构与各种选型, 将一些主流积木拼凑成一套能打仗的武器. 比如最近看领域驱动设计时候确实收获很大, 而且感觉要看很久

6. 回头再走一遍查漏补缺. 很多书真的读每一遍收获都完全不同, 越读越发现自己差得很远

以上几条不是标准答案, 只是这些年学习时候走了太多弯路得到的教训

既然明白了, 我啰嗦一个题外话: HTTP 被设计为适合较短的无状态请求, 没必要做成这种特别长的方式(虽然我以前也很喜欢, 不过后来都改成最长 block 60 秒或者异步任务). 至于那个心跳说的应该是 HTTP 1.1 客户端上 Keep-Alive 的方式, 举个例子就是 requests 库用 with Session 上下文保留连接避免多次握手的开销

chrome 浏览器一个 host 只创建一个连接(以前看到是 6 个)

用 curl 测吧, 快成年经问题了...

粗略看单核效率的话, Python 和 golang 的协程并发性能差距其实并不大, 多核差距开多核也能拉近. 就拿现在比较主流的 Fastapi 一两万 QPS 的性能来说, 日常根本到不了这种量级的压力, 等到了这个压力的时候, 自然也有新的认识, 估计也不会再问出这种问题

总而言之, 选最擅长的, 其次再考虑业界主流(主要容易招人). 先顺应团队生态, 再考虑顺应市场生态, 前者决定生存, 后者决定发展

内存外存分开记呗

重要的热数据大脑内存里放着
低频的冷数据只记录索引 / 关键词, 然后存储在 workflowy 或者知识管理工具里