webdav 你坏事做尽(

@alittlecat 跨平台跨客户端的密码管理. 尤其是手机端 native 的密码框支持使用密码管理软件之后易用性暴涨.

api 的 uri 能拆就拆, accesslog 的收集分析现成工具多, 好统计好分析
用这种单 endpoint 的 rpc 风格就得自己把监控收集分析都定制一套.
好处大概是比较容易配置新的行为模板, 方便在客户端那边生成按钮.

结果上来说功率密度还不如米家 65w 的, 胜在插脚可折叠.

但是楼上提到了, 国内版本阉割宽电压, 没法带着当国际旅行的充电头用.

简单四则 alfred, 复杂 ipython

会有点不舍的
不至于不放心

要是在的团队差到交接个项目都不放心早可以走了

至少 2xx 和 4xx 要区分开. 5xx 是服务器出错, 一个业务应用不应该自己使用这个码, 让框架来生成.

业务状态码是业务状态码, HTTP 状态码是 HTTP 状态码. 不能混为一谈. 两者不冲突.

HTTP 状态码是用来方便你的网络中间件, 运维工具, 以及客户端的网络请求模块进行统计和分类处理.
业务状态码是提供给客户端应用进行业务逻辑处理.

运行在用户机上的代码就不能指望 100%不被逆向, 所以对来自用户机的数据永远都要防范...

pyenv+1
windows 上以前还会用 conda, 现在都在 WSL 里装 linux 版了.

之前在 linux 里用 miniconda 主要 intel 自家优化过的 python 分发只在 intel 的 conda channel 上分发. 但是那个分发版本更新太慢了, 慢慢就不用了...

应该是字体. 看看如果每次都一样的话可以自己存个映射.

人有审美需求
有时候比较苦比较忙比较累, 没有足够的余力去满足审美追求. 但是回头有空的时候再看看, 不满足审美的东西看着就让自己生气

jwt 是一套信息传递机制. 并不是一套认证方案. 和 cookie 也不冲突你可以把 jwt 存在 cookie 里用.
不用 cookie 做认证的原因很简单. 后端是 api 的时候用 header 而不是 cookie 对 xsrf 防御更好. 如果用 cookie 还得协调前后端做一套 xsrf-token 来进行防御. 而 header 只需要在 ugc 内容的过滤和呈现上防止 xss 出现就好.

上面说滥用 jwt 的我觉得很奇怪
jwt 只是一种可验证的信息签发传输方案. 你要在里面存储什么信息, 服务端如何利用完全是开发者自己的选择.
就算所谓要替代 cookie+session, jwt 可以替代的是 cookie 部分而不是整个 cookie+session. 纯 cookie 也是可以做无状态无 session 的身份验证方案的.

lz 的问题里就是服务端无状态导致无法踢人. 那就得重新做有状态认证方案了. jwt 可以+session 或者 anythin else 可用的服务端状态.

不会. 因为没有生活微信号, 只有工作微信号

不要自己主动谈这个. 面试方主动提起了再说.

一般面试方如果主动提起, 说明这公司就算不是知名 996 企业也确实有需要实施 996 的时期. 这就是提前打预防针和做双向选择的时候了.

github 关联失败+1