@7y

不算前辈... 后端日常用的不多, 已经转 fastapi 了, 喜欢原版或者折腾的可以继续 starlette, 我是怕麻烦那部分... 目前看起能一统江湖的协程 ORM 有了几个, 但是真正统一的还不太行, 各家都在努力造生态

用 starlette 的话, 他们 encode 出的兼容性都比较不错, 当年搭配他们家的 databases; fastapi 作者整了个 sqlmodel 但我看的时候 asyncio 部分文档都没写完...

其他的话, awesome-asgi 或者 Awesome fastapi 之类的里面会有一些, 反正我用过的都只算可用

以前的想不起来了, 最近会用到的是图片转 html 让我直接看文件夹里多张图, 低代码爬虫追剧 B 站追更, 某上网软件节点检测切换, 批量删除视频, 批量操作 chrome...

@ltruntu
这不都是西游记里的东西么?

别好像, 直接去医院, 大夫说我是干眼症还开了点结膜炎的眼药水, 实际上楼上们说的症状我貌似都没有, 就是偶尔有异物感

最后安排了一个月 4 次的睑脂腺按摩, 那酸爽, 第一次弄的时候说这么多... 然后莫名有一种失明后重见天日的感觉, 之后路效果没那么明显了

1. 名字要有意义
2. 名字要有创意
3. 名字要容易记

根据系统用途, 联想到各路天神的技能或者古典神话算了

日志监控系统谛听
爬虫系统千里眼
报警提醒系统顺风耳
财务系统叫财神爷
稳定不宕机的叫六道轮回
不稳定容易宕机的叫八卦炉(天天炸炉)
考勤系统五指山
信息管理系统生死簿
客户关系管理系统扫把星
进销存系统五脏庙
内网 IM 系统小雷音寺
外网 IM 系统大雷音寺

随便想想一大堆

没有太火, 上次看这名字还是在 Benchmark 上, https://web-frameworks-benchmark.netlify.app/result 性能略微优势但又没那么明显. 比速度不如同步的 falcon, 易用性和生态现在也被 fastapi 统治了

现在异步框架做来做去看起来都挺像 starlette 的, 后来一些框架更是直接拿它托底了... 如果真要搞异步以及学习, 看看这个还是挺不错的选择, 比较这个 encode 出品了不少好东西了, 生态都快砸出圈子来了

VPN 是正经出路, 早架早享受, 隧道用久了感觉太扯淡了

别人当年也劝过我别拿兴趣当饭碗... 工作年限越久转职越纠结, 因为公司可能更倾向于为你的 "工作经验" 买单, 而不是你的未来可能性

如果实在纠结, 再面几家以前没把握的试试?

go 的市场有点虚, 看似是大趋势, 但还是很吃生态, 社区生态虽然也火热, 但很多大厂还是更相信自家闭源生态, 站出来开源的不占多数, 如果运气好进了一家氛围不错的确实能成功转型, 运气不好就难说了可能前期非常吃力, 因为指望工作中掌握一门技术的要么运气极好要么满盘皆输

至于内卷这个事, 是那些刚入行没其他竞争力只能靠偏门竞争的人折腾的, 你又不跟他们在一条起跑线上怕什么

早年间用的 processon, 然后现在白瓢的 draw.io 存在 Google Drive 上

之前拜托同事也折腾私有 pipy 到 maven 上, 后来嫌麻烦, 直接走内网 git: 的方式安装了...

是 linux 的话 alias 先凑合用用? 很早以前我好像也有这问题, 各种清理 cache 然后 -vvvv 也没啥办法. 刚才搜 pip search private priority 也没发现什么好的建议

@keith1126 感谢课代表

昨天给我看的一愣一愣的... 另一个新闻还没晃过神来以为这边又出幺蛾子了

高中的生活已经这么精彩了, 后生可畏

做梦的时候有一个阶段叫做 "眼动期"...

@ifplusor

只是说适合走事件触发, 但是也可以当 rpc 解耦玩同步, 门槛低上限高, 就看架构师水平了

我这边 faas 就是当微服务用, aws 上 boto3 直接同步调用也没啥问题, 用自带的 rest gateway 也很容易配置各种鉴权限流, 就是要花点钱而且 30 秒超时有时候不太习惯.

关键是释放了不少计算资源, 各种适用场景就不赘述了, 这功能解耦粒度比微服务还细, 管它是什么语言实现的反正调用一个函数名字传入内容我就要指定结果

对于低频高计算(平时的定时任务)类型的任务, 比 spot 实例管理起来简单, 真有那种耗时长的再考虑竞价实例. 给我印象最深的就是解决现在公司缺运维导致的机器资源要么长久空闲要么恶意抢占, 钱都花刀把上了

简单地说, 你那边的计算密集任务依然可以留一个调度中心, 有任务在 Serverless 上跑等结果好了返回就行了, 一个 CPU 几百协程还是挺有意思的.

一句话: 没有银弹, all-in 有风险

登录了下还活着, 不知道是小概率时间还是有什么共性

如果问题真的很大, Reddit 或者邮件组之类的是不是该吵起来了

faas 减少运维成本带来的优势明摆着在那了, 至于说绑定什么的, 对象存储和数据库该迁还是得迁, 不可能在一家吊死

去年跟 aws 顾问聊到现在越来越多企业开始布局各类云基础设施, 有的尝试 all-in serverless 也没毛病, 大厂玩家们, 更是多家云混合一起用, 不会只用一家的

至于现状... 去年技术分享了 serverless 同事们不怎么愿意迁, 然后临时调去帮着运维砍成本, 提出来的把花钱的架构拆到 Serverless / spot 竞价实例 / K8S (这几个也是顾问赞同的) 一项都没通过, 只能说习惯是个挺可怕的东西, 不过因为运维走了不愿意担风险也能 "李姐"

最佳实践什么的, 国内相关文章都不多, 之前调研是硬啃的官方文档, 比较麻烦的大概就是服务治理相关经验, 但是哪的服务不用治理的, 现在公司里机器跑的已经乱成一锅粥各种抢资源...

至于成本真的是之前没想到的低, 迁了俩日常定时爬虫任务, 连免费额度都没用光... 之前 faas 貌似都用在 s3 触发的图片裁剪和视频截图上面了

就个人而言, 还是挺希望去一家 all-in Serverless 或者别的云原生相关涨涨经验的, 就竞价实例号称节省 90% 成本这东西, 我就愿意写一大堆无状态 slave 过足瘾的

稍微理解一下包的结构吧...

flask run 是当包启动的, app 里导入 util 时通过相对路径(因为是同一个包)
python app.py 是把 app 当 module 启动的, 当前路径会算在 sys.path 里面所以会导入成功

@SoulClinic 他们也是想让你及时刹车吧, 有些灰色的东西不宜在公开场合讨论, 顶多一些小圈子群里交流讨论

除了法务问题, 也可能会影响灰产饭碗吧. 参考当年搜狗那个直接把公众号临时链接转永久链接的漏洞, 有个好心人直接开源丢到 Github 了, 估计被相关人员看到, "仅用了不到半年"就把漏洞补上了, 然后不少灰产成本直接起飞了

简单的说, 反爬本身就是人家表态的合理合法的行为, 无视君子协议本身就不太好, 公开讨论不管什么结果(给对方带来损失, 或者对方及时止损), 总有一方不开心的

现在找工作都尽量避开逆向和灰色的了, 又不是无路可走没必要冒一些没必要的风险

言尽于此且行且珍惜吧