Forwarded from ┗|∵|┓Hz ❁ HoneyWorks
Аррӏе
IDN Homograph Example
#China #tech #life
为什么支付宝健康码一定是用户扫定点,而不是定点扫用户?🤔
从信息量看都是一样的, place.onEntried(user) 和 user.onEntry(place) 都是一个 user 一个 place
不过如果是 place 主动,则用户就不需要联网了,甚至连设备都不用,打印纸都可以
从网点配置看,好像两者都一样;不过如果是 place 主动,用户就有可能被场所“伪造”活动记录,所以为保万无一失,操作必须用户手动确认,这时用户扫更适用(反正需求都是一样了)。
顺便说一句,下午我去超市排队,扫码的时候仅仅因为支付宝的版本不是最新,健康码应用就不能继续运行了(只能看见那个介绍页面),害得我不得不升级重排,也不知道是支付宝为了保证代码「最新」要求的还是应用自己要求的。
连个缓和的更新期都不给,这种处理还真是十分“安全”。 👎
#Low #Ali
为什么支付宝健康码一定是用户扫定点,而不是定点扫用户?🤔
从信息量看都是一样的, place.onEntried(user) 和 user.onEntry(place) 都是一个 user 一个 place
不过如果是 place 主动,则用户就不需要联网了,甚至连设备都不用,打印纸都可以
从网点配置看,好像两者都一样;不过如果是 place 主动,用户就有可能被场所“伪造”活动记录,所以为保万无一失,操作必须用户手动确认,这时用户扫更适用(反正需求都是一样了)。
顺便说一句,下午我去超市排队,扫码的时候仅仅因为支付宝的版本不是最新,健康码应用就不能继续运行了(只能看见那个介绍页面),害得我不得不升级重排,也不知道是支付宝为了保证代码「最新」要求的还是应用自己要求的。
连个缓和的更新期都不给,这种处理还真是十分“安全”。 👎
#Low #Ali
Forwarded from Deleted Account
其实 GitHub 不应该因为社交功能上的 annoying 就 flag 用户,而且这个 flag 还能让这个用户直接消失掉。
这不是细节问题,更不是社区管理问题,这太弱智了。
这不是细节问题,更不是社区管理问题,这太弱智了。
Forwarded from Deleted Account
肯定是尽可能用 foreach
如果是
注:命名 Iterator 请依照项目代码风格,非最佳实践。
如果是
while (input.hasNextLine()) iter.next() 它肯定没意见注:命名 Iterator 请依照项目代码风格,非最佳实践。
Forwarded from Deleted Account
public relation 就是伪科学
用欺骗强奸人们的感情,真心都没有还提什么“关系”
用欺骗强奸人们的感情,真心都没有还提什么“关系”
#dev 下去散步时关于 声名、简单、高深 莫名文艺抒情了一下
关于 ParserKt 在实现绝句介词/后缀(也即“记法”) 和名字的混合解析,大概考虑好了。就是给名字专门实现解析器,然后把记法解析器写成 Either<String> 的形式,Right 的时候停止 concat name parts,记法解析器只返回 Stated 流里之前存下的结果。这种方法可以实现 one-pass。
我就是觉得程序猿要学会并适应“带着枷锁编程”,不能太松散豪放了。
考虑了一下 ParserKt v3 不参 v2 源码的重写,我觉得已经比较成熟了,不会有大问题。
后天 v2 cleanup,然后准备 v3 和 faster-parserkt
我不可能和 kotlin 的 IntArray, FloatArray 弄 CharFeed 的,那样的“优化”简直不可接受……
关于 ParserKt 在实现绝句介词/后缀(也即“记法”) 和名字的混合解析,大概考虑好了。就是给名字专门实现解析器,然后把记法解析器写成 Either<String> 的形式,Right 的时候停止 concat name parts,记法解析器只返回 Stated 流里之前存下的结果。这种方法可以实现 one-pass。
我就是觉得程序猿要学会并适应“带着枷锁编程”,不能太松散豪放了。
考虑了一下 ParserKt v3 不参 v2 源码的重写,我觉得已经比较成熟了,不会有大问题。
后天 v2 cleanup,然后准备 v3 和 faster-parserkt
我不可能和 kotlin 的 IntArray, FloatArray 弄 CharFeed 的,那样的“优化”简直不可接受……