信念和自洽

前几天和老张聊天时候料到信念的问题。我通过信念对「自洽」做了一个定义:主观对客观物感受的信念度非常高。

“主观对客观物的感受”就是一个人对某个东西或某件事的定义,而认为这件事是绝对真理的程度就是信念。

这么看来,说人话,自洽就是一个人对客观时间里的各种事物的主观定义已经非常笃定了。

至于在“自洽”状态下,一个人还有没有成长或者进步的空间,取决于“笃定”的基础 – 这个每个人都是不一样的。就是,有的人我们觉得很倔,很硬。

定义这件事由于本身是“人造物”,永远都是一个“相对”的概念。而认为它是绝对的,而更进一步 – 认为某一绝对概念是绝对正确的。可能就非常接近愚蠢了。

好吧,我这里的“愚蠢”也是相对概念,因为只是我认为的“愚蠢”,每个人脑子里的这个“愚蠢”,都是不一样的。

物质缺乏时候,物质需要管制

物质缺乏时候,物质需要管制。那精神缺乏时候呢?是否也需要“管制”。

物质和精神的对立,能否都应用于“管制”呢?是否可以类比?

如果能,那精神该如何管制?

如果不能,那是什么区别导致的呢?

有次类比思考是由于我经常觉得,大脑和身体这两个精神和物质的“摄入器官”,其行为是极其相似的 – 都是吃喝,然后拉撒。

按照我的这种想法,精神就是需要“管制”。

当下是否是一个精神缺乏的时代呢?是否存在某种不容易察觉的“管制”呢?

教给孩子的口令

今天正式给儿子配了手机,同时,非常郑重地告诉他两条ground rule:

1. 不要相信任何人

2. 不要泄漏自己的真实身份给任何人

是“任何人”,而不是“除家人以外的人”。因为当下的网络环境实在是太不安全,或者是我过于悲观了。

(是否我在把我这种过于悲观的想法传递给孩子呢?这个是另一个需要思考的问题。)

其中的第一条“不要相信任何人”,我稍微展开了一下。

如何确认家人的身份 — 如果来电号码、微信语音、电话都不可靠的话,可以使用“口令”。

很容易理解,就是这个口令是只有家人才知道的“冷僻信息”,比如家人在家里的外号,或者是孩子小时候说的毫无意义的口头禅,或者是孩子的某个课外辅导班的老师。

但是,口令还不能过于明显,如果电话被监听或者本人在胁迫的情况下(好吧,这有点迫害妄想症了)。

这时候就需要用平时不太常用的常用语,比如:“你在哪呢?”,说成“你在哪里嘞?”

还不够,当有些情况下,你需要孩子“不听你的话”,那么就需要制定一个“反口令”,当孩子听到这个“反口令”时,需要反过来听。

比如:“在哪呢,你?,你快点来xxx地方。”

这时候,孩子的反应是,回答“好的”但是“不去”。

其他的慢慢补充吧。

貌似我们一直在解决“跨平台”的问题

为了解决不同操作系统中运行软件的问题,我们发明了Java来实现“一次编译,随处运行”。貌似很多时候我们都尝试不依赖于所谓的平台。

但最终我们发现,所谓的平台、版本本身的这种“反跨平台”的设计,是有存在的意义的。–至少对创造这些平台的人来说。

人类社会无时无刻不是在解决这些纠结,只是在不同的领域罢了。制造分歧(可能是因为审美、或者仅仅凭借运气),消除分歧(可能并不是所标榜的那么伟大),然后制造新的分歧。

Java解决了软件在桌面操作系统层面的跨平台问题,但是现在的iOS和Android又产生了有待解决的问题。

然后现在很多人在倡导React Native、Uniapp、Ionic这些框架,思路依然是“一次编译,随处运行”。

0维是存在

或者说:存在是第零维

第一次骑行

严格意义上来说,不是第一次。从小到大不知道骑了多少次了,长距离骑行也有几次。

但是昨天是第一次真正意义的骑行,而不是骑车。算是第一次严肃地对待这项运动,虽然我还是喜欢用“玩”这个字。

无论体育运动还是工作,很多时候都是一个“精进”的过程,或者不用这么大的词,就是“学习”的过程。学,然后,练习。好像没有其它了。

路上和张哥聊了许多,除了告诉我一些基本的骑行安全常识和姿势纠正外,还聊了很多关于“学习”的事情。很多事情,在操作层面是不同的,但是在精神层面都是一样。

比如“精进”,无论是游泳、自行车,甚至编程,其实都是一个“量变”,期间身体或者大脑会越来越敏感敏锐,会对自身越来越了解,进而不断地进行优化。最终,达到“质变”。日常中我们简化地说“量变到质变”,其实还需要很多思考,可不是单纯的“傻练”。

对待孩子的教育也是,甚至更难,因为孩子既不是“物”也不是你可以直接感知到的“自身”,而是一个独立的“人”。需要对他/她的身心非常敏感,进而不对地尝试和调整,人太独特了,很多时候其他教育方法毫无参考性,或者说本身就把孩子当成了“物”来对待,注定是一种失败。

豆瓣之死

毫无疑问,豆瓣是我到目前为止最钟爱的国内网站。一直用它记录我的阅读、观影记录,从2005年开始,14年。

但是这个星期,我发现豆瓣的图书API彻底不能用了,code 104 invalid_apikey。同时 developers.douban.com 也打不开了。

虽然豆瓣的API早已不能申请,大约5年前,但是好在之前有几个申请的key一直还能正常使用,觉得很幸运,也觉得豆瓣很够意思。

但是,这次呢?没有什么余地了。去查了一下,发现很多人遇到这个问题,有些是一些小站,有些是一些在校大学生在做毕业设计需要用到豆瓣的数据,还有一些人已经撸起袖子开始爬虫了。

其实说回来,豆瓣提供了这么长时间的数据接口给到别人,但是我们这些“developers”又给豆瓣了什么回馈吗?貌似很少。我们和那些伸手党没什么区别。

豆瓣之死,是因为在这个世界里,“开放” 已经从最开始的理想,变成公益,最终变成了一件负担。

从这角度来看,豆瓣确实死了。

”开源“ – 有点类似测试众包的意思

吐个槽

如果强求一致,一个伟大的灵魂也会毫无作为

愚蠢的一致成了出没在小人物心头的鬼怪,受到小政客、小哲人、小教士的顶礼膜拜。如果强求一致,一个伟大的灵魂也会毫无作为。

爱默生

微信支付的使用场景总结

关于微信支付的库和文章很多,但似乎都没有很好地说清楚各个接口的使用场景。这里结合之前的经验对微信支付文档做个补充。微信的文档在这里:https://pay.weixin.qq.com/wiki/doc/api/index.html

MICRO – 付款码支付

所谓的通过扫码设备扫描用户出示的付款码,类似POS的操作,只是POS机换成了扫码设备,银行卡磁条换成二维码。扫码设备在x宝就有的卖,100左右(可能更便宜),其实就是一个输入设备,付款码就是一段字符串。这个扫码设备只是做一个二维码到字符串的转换而已,所以可以支持微信、支付宝、银联或者你自己开发的支付码。

使用这个方案需要注意,有时候用户不是扫码后马上同步完成的,而是需要输入密码或者余额不足换卡(微信和支付宝都有可能产生这种情况),或者最终取消交易的。所以在扫码页面最好进行后台的轮询检查支付结果。

JSAPI – 公众号支付

其实更准确地说,是微信浏览器内支付(有别于H5支付是在用户移动设备上的浏览器)。在微信里,体验是最好。但是通常需要根据用户浏览器UA进行切换,如果是微信浏览器就用JSAPI,如果是在不在微信里,但是在手机浏览器里,就切到MWEB。

MWEB – H5支付

主要是用户在手机浏览器里支付,此时会打开用户手机里微信进行支付。

如果用户没有安装微信呢?

NATIVE – 扫码支付

商户端生成订单,然后生成对应的付款二维码,来让用户进行扫码支付。和MICRO是最常用的线下支付场景,和MICRO相比稍微麻烦一些,因为需要输入密码。但是好处是可以获得用户的授权,然后获取用户的openid或者unionid,而MICRO是不能拿到这个信息的。如果你需要根据openid追踪到系统内的用户时,这算是NATIVE的一个好处。

APP – APP支付

流程上其实和JSAPI很类似,都是获得预支付ID(prepayID)然后在APP内完成。在服务端接收付款通知,最好在APP里再进行一下确认。

WEAPP – 小程序支付

和JSAPI一样,只是支付参数(package)放的地方不同,一个是网页,一个是小程序内。