能用 32G 当然比较自由。。办公 8G+虚拟机 8G ，chrome 跟 vscode 这两个吃内存大户时不时崩溃。
只是开发用途的话，也不需要追求极限吧，压测是在正经服务器上做的，开发环境能验证就行。

负责的模块写得太细了，试着概括一下。
亮点要突出，找一下你工作中最有技术深度的内容，着重写一写，等面试官发问。

同意#5 的说法，更重要的是代码组织的水平。
我这两年最不想细看的就是前两多行的单文件脚本，全是函数，没有封装。但不是故意的，里面有太多“构思中”的功能，比起一篇文章，更像是一张草稿纸。
写代码是需要思考的，想到哪写到哪，看起来就乱糟糟的。有时候为了应付上线，不得以破坏了代码的封装，看着实在糟心，有机会我就以“新功能不好拓展”为由重构一下。
但有些团队并不关心这些，因为这些代码不需要他们维护，也不考虑人员 backup 的问题。这种时候就会被冠以“强迫症”的称号，要不要继续保持“优雅”就看个人选择了。。。

系统盘 200~250G 是比较合适的大小，再小就不要再分了。恰好我的 SSD 就 256G ，不用考虑分区的事。以前的笔记本就一块盘，还是需要分的。
我的个人偏好是在重装的时候格式化 C 盘，所以一般会把非绿色软件跟纯粹的数据分开存放。不过，这是偏理想的情况。各类软件存放数据、配置的逻辑都不太一样，会引出更多的问题。
比如，有些软件的数据存在安装目录下，有些在 Users 下，有些在文档目录下，也有些分散在 AppData 里。即使你弄清楚了这些，电脑用的时间长了，总会有些犄角旮旯的“脏东西”。
所以纯粹的数据文件分开存放只是第一步，其实并没有一劳永逸的办法。

来一个花钱的方案，用云产品的对象存储，一般都提供了命令行工具，客户端配置好 ak/sk ，拉下来还挺方便的

公司拒绝续签是要赔钱的。你看看其他同事是否都要走这个过场，当心有什么“主动放弃续签”的坑在里面

不用库的话，也就是手动根据版本把不兼容的函数提前赋值给某一对象，底下的逻辑用它处理。
可以学一下 flask 的_compat.py 的做法，把不兼容的部分扔到一起处理。

拿打机举例，坦然面对我玩得比朋友菜，但不妨碍我开心。

github sharp dark

以前 vscode 更新公告里面看到的配色，习惯之后换不了别的了

我的朋友跟我借钱都是约定好什么时候还款的。一两千借过，小几十万也借过（关系最好的朋友）
一个比较奇葩的，理发店的 tony 老师，关系熟络之后偶尔找我借四五百。。但是拖一两个月也不提还钱的事。后来换工作不在那家店理发了，他再找我我就当看不见了。
也有朋友到了期限没法还的，但因为关系很好（每天都在小群里聊天），我也知道他们不可能跑路，就干脆不催了。

你最好还是找人借一块试试手感。今年生日朋友送了我一块 hhkb ，用了一两个月，已经快吃灰了。来反驳一下“提高效率”的说法吧。

1. 键位。重度使用 tmux ，依赖 CTRL ，换了位置确实舒服多了。其他 win 键，退格键的问题，都可以靠切换开关解决，一两天就适应了。
但是，我还有别的键盘，三台电脑 /笔记本，在公司跟在家用两套模式还是挺烦的。（我 CTRL 键是真的用得非常多）

2. 轴体。我原先用的红轴，手感也是偏轻的，用下来的感觉是半斤八两，没有突出优势。

3. 60 键。打代码的时候用 VIM 模式，非常顺手。
F 功能键确实用得少，但我工作中高频使用的全局截图键，恰好就绑定在 F1 。。就很难受。（放其他位置怕冲突）
而且，工作不止要打代码，不是什么都支持 vim 模式。当你写在线文档、阅读文件，企微 /钉钉回复大段消息的时候，缺少按键的劣势就显露出来了。

最后促使我把 HHKB 放一边的原因，是我当时手上有一件“临时”的日常操作，写脚本逻辑很复杂，手动只需要十几秒。
但是我需要用到各种组合键，用 HHKB 直接歇菜了，少了几个键，操作量是原本键盘的一倍，还容易出错。气得我把它扔一边了。

工具就是工具。多一两颗“少用”的按键没有问题，少一两颗“想用”的按键就是巨大的麻烦。
我也喜欢紧凑型的键盘（自用的 75%，82 键），但是办公我建议还是买完整尺寸的键盘。某些功能区到了需要的时候，才会觉得真的好。

有些软件，比如默认地址是 C:\Program Files(x86)\xxx ，你用浏览改完成 D:\Program Files 之后，后面那截 xxxx 就没了。
平时习惯安装到别的目录，直接修改文本反而快一点

哦对了，上面那个项目是在这个项目里找到的，里面都是基于数据库暴露接口的项目，分享一下
https://github.com/dbohdan/automatic-api

好几年前也搜到过一次，太久就给忘了

让前端把 query 扔到后端直接执行，很不靠谱。相似的思路有相对成熟一点的方案，叫 GraphQL （我也没用过其实）

至于 python + mongodb 的组合，倒是搜到一个项目 https://docs.python-eve.org/en/stable/quickstart.html
看着可能符合你需要。

我们以前用过基于 python + MySQL 的 API 自动生成工具，也在部门内推行过。入门很快，但遇到定制化需求的时候就很麻烦。
后来开的坑多了，自己也攒了一些用着顺手的开发思路，代码结构也基本固定下来，有新需求就复制粘贴，改改模型定义。。这样反而更方便。

主流平台的跨平台开发也是日常看他们扯来扯去的。。有帮助，但不起决定性作用。想直接在桌面软件的路上赶超其他两家是不太行的。
正常思路应该是 某一类搭载 linux 桌面环境的 设备崛起，带动市场对此类平台的投入，进而更多的研发力量投入到其中，促进整个软件生态的发展。
emmm ，好像是安卓的路子（

不辛苦，命苦。
发了这句之后被同事截图做成表情，然后用于在群里回复组长的话。。

什么，第三季已经出了？