127.0.0.1:6379> lpush test a
(integer) 1
127.0.0.1:6379> lpush test b
(integer) 2
127.0.0.1:6379> lpush test c
(integer) 3
127.0.0.1:6379> lrange test 0 -1
1) "c"
2) "b"
3) "a"
127.0.0.1:6379> lrem test 0 b
(integer) 1
127.0.0.1:6379> lrange test 0 -1
1) "c"
2) "a"
127.0.0.1:6379>
虽然我不喜欢用 Electron 开发的应用
...
...
...
但是让我自己开发,我还是选 Electron
是的,纯后端只能做框架、库等「底层」用户看不到的东西
想要做点用户能直接用的东西,必须得有广义上的「前端」
可以上招聘网站搜搜前端的一般用什么技术,照着学习即可
Session 一般指的是,通过在 Cookies 里保存的一个 SessionID 实现鉴别用户的处理方式
好处是对 Web 前端,也就是浏览器基本上是透明的,前端开发不用管
Token 一般指的是,登录成功后,通过 JWT 等方式把少量信息编码成一串字符串返回给客户端,客户端在请求时一般将其附带在 HTTP Header 上,供服务端鉴别用户的处理方式
好处是任何客户端都能方便处理,并且 JWT 方式客户端本身也能获取字段信息
> 使用 token,由于 token 存储的是少量信息,是不是每次都还需要在拦截器中验证并去数据库加载用户信息
> 如果一个前端页面包含多个请求,每个请求都需要鉴权数据库压力不是很大么
> 解决是不是可以用 redis 集群做信息缓存,但是这样和传统 session 操作方式不是类似么
是这样的,如果 Token 中保存的信息少到只有 Token ID,那和传统 Session 的唯一差别就在于是不是依赖 Cookies 了
> 所以说 token 和传统 session 优势是什么,token 概念上是无状态,但是不可能真的把用户所有信息都存上呀
没有必要严格按照概念、范式,要面对实际问题
我实践下来的感受是有状态的 Token 比严格的无状态 Token 更好用,主要还是用在服务器端作废 Token,用户权限变更需要及时生效之类的处理上。
此外,Token 附带的信息并不限定「用户信息」
比如,要实现客户端发生变化( IP 、UserAgent 等)后,强制退出的功能,可以在 Token 发行时将客户端相关信息 MD5 后加入 Token,后续收到 Token 之后拿 Token 中附带的客户端信息 MD5 值和本次请求实际的客户端信息 MD5 值进行比对,有变化就拒绝,从而加强一定安全性,且操作完全不经过数据库、Redis 等其他组件。
再比如,要实现服务器端升级后,要求所有用户重新登录(重新发行 Token ),那么同理,发行时把服务器端的版本号写入 Token,收到 Token 时进行比对,这同样不需要额外查询数据库、Redis 。
也可以实现按照业务的请求转发。
比如 VIP 用户可以在 Token 中写入 VIP 标记,那 API 网关就可以将此请求转发到不同的服务器 /集群上处理,也能避免 API 网关去直接去数据库查询业务数据。
其他的那种比较直观的,比如展示在页面上的用户昵称如果写入 Token,那前端可能就可以不用额外请求用户信息接口。但这些都不太重要
人家用 Linux 桌面同时也能用好,说明人家比较能折腾,也能折腾好呗
我就是反过来,不喜欢折腾,本机 Windows/macOS + 虚拟机里装 Ubuntu Server
开发环境都在虚拟机里,可以随便造,大不了一个快照回滚,也方便做测试,可以分叉出各种不同的系统环境
代码在本机,共享到虚拟机里,也不怕丢
Linux 好的在 Linux 里用,Windows/macOS 好的在本机里用就行了
要说方便,肯定是 Windows 最方便,macOS 虽说和 Linux 接近,但终究也不是 Linux,我一样还是要虚拟机 Ubuntu 的
至于有人说 Linux 桌面比 Windows 还方便,看看就好,要有自己的判断人家为什么这么说
比如说人家那是什么场景?人家平时都在干啥?
相反,你如果都自己亲自用下来觉得 Linux 桌面没 Windows 方便了,那就是 Linux 桌面不适合你,和菜不菜没什么关系。
就好像还有说 Vim/Emacs 方便的,说 VS Code 好的,人家也没说谎。
但我就喜欢 Sublime,我也不见得就因为一个编辑器就比别人差,对吧
这些东西说到底还是算作工具器材
一个人牛不牛,关键在于他创造了什么财富价值,而不是他手里拿的是大厂出品的锤子还是自己组装的锤子
肯定要有一开始的测试环境构建和最后的环境清理的
自动化测试启动前,必要的数据导入数据库
跑完测试,把相关的测试数据全部清理掉
有条件的应该是新开一个完全独立的自动化测试环境,跑完删了就行,不和开发环境混在一起
没条件的可以给自动化测试时创建的记录加上前缀(比如,新建用户的时候,用户名起成「 autotest_user 」,最后统一根据前缀删除
也有取深层 json 字段,但结构可能不正确的时候
try:
data = j['a']['b']['c']
except KeyError as e:
data = None
if data is None:
pass
还在用 Express... 做久了一大堆现成的代码,开发起来很快,也懒得换
不用感觉的尴尬,说白了就是在乎不在乎的问题,包括某个人在不在乎或者某个行业在不在乎
我待过的互联网公司,人家不在乎,还不信「阀值」是错的
我待过的有工控背景的公司,人家就是在乎,并且认为,「阈值」能写错约等于产品不靠谱
学究不学究另说,但不同场景 /环境下,要求肯定是不一样的
网友聊天,网络用词也好,甚至火星文都没问题,也可以说在乎这些的人是学究杠精
如果是高考,和客户签合同,该抠字眼的必须得抠字眼,不然后果就是得自己承担。
(经典案例:「还欠款」,是「归还」还是「还有」;欠条 /借条)
所以放松一点吧
有时候其实就是过度设计,一堆没意义的继承导致代码难读,不是你的问题
根据我的经验,好的代码思路清晰,继承多少关系其实不大,你 get 到作者的的点很快就能推测出整体结构。而不好的代码谁来都皱眉头。
开车能学习的也就只有开车本身了吧,换手动挡的练吧
学其他的东西总归很危险,而且学习效果也不好,不值得
我也支持用虚拟机,配置好之后打个快照,导出回滚都很方便
唯一不方便的就是体积偏大点
我觉得如果公司一路追责下来是你一个开发来背所有锅,你其实也没有必要留在公司了。
感觉公司大老板属于甩手掌柜,出了问题就找部门老大问责,部门老大没办法只能找个人祭天了。但凡老板对研发有所参与的话,基本不太可能让某一个人承担全部责任,而是类似部门今年取消年终奖之类的。
想学习还是看书吧,真的,虽然这个方式非常「古典」但的确就是最好的学习方式。
毕竟出书会有出版社审稿,而且年代越久再版数量越多的书,或者被当作过教材的书,可以认为在一定时期内经受住考验的。
其次是专门的教学视频,长篇大论的博客文章。一般写的人都对自己的作品比较负责,但没有第三方审核可能存在问题作者自己未必知道。
相反,短视频,包括微博这种短内容的东西,谁都能发,也基本没有任何审核,想到什么就拍什么说什么,娱乐一下就行了。
再比如,我公开发一个帖子,说「 1 + 1 也可以等于 3 」
如果版主觉得我沙雕,他会选择不理会
如果版主觉得我在散布谣言,他可以选择直接封号
如果版主觉得我说的可能不是数学问题,他可能会置顶让大家一起来讨论
同样的事情全看平台、管事的怎么认为,而且平台也不需要什么解释
你觉得冤枉蹦跶几天几个星期费时费力费钱,他鼠标点点解封就算皇恩浩荡了
至于实际有没有执法环节还不一定呢
所以,为什么要把自己重要的数据 /资料交给这么一个平台保管呢?
@
morizawatt 说白了,他做了什么,算不算不正当,得有人定性
2020 年初的谣言辟谣最后发现是真相的事情过去还没满 1 年,有些东西被微信这种平台拿在手里只会更糟糕
我想说我反对小程序
小程序初衷的确很好,也的确很符合程序员的思路
直到最近,有个朋友跟我说他微信被封号了
我很快从「他干了什么的」思维定式里走出来了
重点不在于他干了什么,或者是不是无辜的
重点在于,微信想封你就封你
你可以去申诉,花好几天慢慢和客服扯皮
但是期间,你所有的小程序都用不了,
如果有用第三方微信登录的也就跟着用不了
换手机号吧,各种应用服务绑定的都要绑定手机号
如果以后微信的小程序平台成为类似水电煤的地位会怎么样?
想象一下,一个想封你就封你的水龙头、电表、液化气管道是啥感受?