respect RIP

火还是很火, 小程序生态也慢慢热起来, 不过真不想用微信, 所以我也属于不怎么喜欢用手机的

至于原生 app, 现在法规一直在弥补, 却一直跟在违法行为屁股后面, 所以还是不敢随便使用不知名的, 毕竟跟电脑不一样, 杀软也不完善, 敏感信息又太多

大众普世价值观现在已经是: 花钱能当爷, 当孙子能赚钱...

想法挺好的, 也挺符合对服务器不造成损害, 而且积分制度能保证活性

然而... 除非裁判亲自下场比赛, 否则都是白扯...

阻碍产品落地很少是技术水平问题, 一般是创意不足或者条件不允许

以前知道一个 Github status, gitee 有没有, 看看它 SLA 能几个 9...

先 trace 一下哪儿慢啊... 几十万行你放的超大 text 么, 我导出几百万也就几秒的事

另: 页面查询导出策略一般都很少用同步模型吧, 几乎都是返回一个 task id 然后等 ready 以后把文件地址给出来下载... 502 感觉是你查询太久了, 不然已经产生流量不太会 502, 顶多 60 秒把 nginx 默认超时给弄起来

谢谢提醒, 已提前一年卸载...

@iorilu 不想折腾就无脑 Django, 我们喜欢折腾的才不断折腾 web.py bottle flask falcon sanic starlette Fastapi

每一代一统江湖的答案其实已经存在了, 没必要总是换, 为了性能早就换语言了. Django 也是玩出一整套生态了, 轮子什么的非常全, 至于像 Java / php / JS 那样一统江湖什么的, 我反而更喜欢百家争鸣的环境

虽然 python 和 golang 在语法糖语法盐上争论很多, 但 python 自带轮子在刚学编程时候看到真的挺长见识的.

就像喜欢 linux 不喜欢 mac/win32, 喜欢 vscode 不喜欢 Pycharm, 主要是因为喜欢折腾不喜欢太平淡

但凡 linux 上能无损耗玩 Windows 游戏, 我早就不用它了... 实在没什么必须要装 Windows 的理由

大多数事物的发展规律都是先起量, 再求精. 先加法后减法的好处太多了

一统江湖的东西说没有确实没有, 谁都有自己生态; 说有还真有, 每一段时间都有一个版本答案级别的东西

Awesome python 那几个系列做的事情就是把每一届答案收集起来, 虽然还有更多好的没收录进去, 全靠自己总结, 例如 selectolax 这个从稳定性 /CSS 规范性 /超高性能等方面早就超越 lxml 了, lxml 依赖一个很老的 libxml 也总是乱输出 stderr 很烦, 但却一直小众

好思路啊... 物理切换确实更现实

当年用的方案是 linux 在我移动硬盘上, 我移动硬盘引导顺序优先级高, 平时用 Windows 引导 linux(可比 grub 麻烦多了), 不干活的时候拔了硬盘...

所以是不是可以搞个引导分区放 U 盘上, 系统依然在硬盘上通过拔插来解决引导

chrome 不方便 Chromium 方便吧, 绿色的 zip 解压缩就能用. 说的太抽象只能给你回答地更抽象了

1. 下载一个比较新的 Chromium zip 包解压缩, 使服务器可以有浏览器
2. CDP 协议的 python 库随便一个, 拿到 TargetID 就是新弹出窗口的那个 tab id 以后直接连接上它, 然后通过域名去拿 Cookie 就行了, 'Page.getCookies' 这个看起来不是特别稳定(随时弃用), 要么截流量, 要么 Network.getCookies

好好的在册的鲁菜发源地之一, 非跑去吃烧烤, 我在那待了二十年, 吃的全是新疆烧烤和哈尔滨烧烤... 图便宜去哪不是去, 非去网红打卡地

那就不开源

只在乎源码的话, 某不能提的软件在 Github 上 git 记录全删了只留了 release 编译成品

一个标题, 空内容, 仿佛回到二十年前的贴吧...

@ChenJHua 我之前把东西跑 hadoop 上也天天优化内存, 你这优化个 6MB 就很伪需求了... Serverless 一般最小规格都 128MB 了, pymongo 导入就这么大, 用精确导入具体对象的方式呢? 然后手动 gc.collect 什么的. 真抠啊

@ChenJHua 就是不直接使用 pymongo 对象, 改远程调用或者跨进程... 那个对象本来就一大堆内置方法, 内存省不了多少的, 做个 HTTP 的接口封装一下也行. 一般情况下脚本都不允许直连数据库, 你们可能要求不严格.

其实我说的就是走远程过程调用相关的事情, 有点跑题了.

你一百个脚本走一百个进程, 实际上 python 解释器运行时候 builtins 也占用 20 多 MB 了, 节省那 6MB 实际意义不大, 缓存的包你跨进程没法共享, 你说的序列化什么的实际上又新建了一遍对象. 这些脚本可以考虑从多进程转到多线程里面, 就可以共享连接池了.

现在看到一大堆脚本就头疼, 刚换的工作掉进脚本地狱里了, 所有东西都面向过程毫无抽象逻辑, 怀念有 azkaban 管理的上一份工作

麻烦, 自己倒腾个 ipc 算了, 就几行原生代码, 我是照抄官网的 asyncio 和 struct 自己搭个 Unix domain socket 就完事了, 你这情况都用不着这么复杂, 我那是抗上万并发用的