微信发布的时间点

这真是一件有趣的事,尤其是在一个互联网时代发布的互联网产品:几个小时前我真的无法想象搞清楚微信公众平台的上线时间会是一件很难的事情。

我这里指的考证,是说至少得有公开的官方的日志吧,或者至少有个关于我们的材料,然而没有。百度百科维基百科上关于这个上线时间,一个字都没有提到。

我另外看了几个方向:

  1. Google 的页面搜索提到微信公众平台页面于 2012 年 11 月 15 日被索引。
  2. 微信公众平台页面的版权信息写着「Copyright © 2012-2016 Tencent. All Rights Reserved.」。
  3. 微信派(wx-pai)是微信团队的公众号,该公众号于 2014 年 3 月 20 日发布文章「微信的开放之路」的通过一张长图片说官方微信提到该功能于 2012 年 8 月上线,同年 11 月 9 日开放消息接口,11 月 21 日开放认证。
Google 页面搜索给出的微信公众平台上线信息
Google 页面搜索给出的微信公众平台上线信息
微信公众号「微信派」给出的公众平台发布时间表
微信公众号「微信派」给出的公众平台发布时间表

所以我想这个发布的日子大概是 2012 年 11 月份吧,但是除了他们自己公众号提到的时间点,这样一个重要的公众事件却无法找到一个正式的公众记录。在互联网时代居然不能通过公众记录把一个具体的事件定位到一个具体的日子,或者至少是一两天之内,实在是引人发笑。这简直和当年搞不清楚中共是哪天诞生的一样。如今,将近 100 年过去了,好多事情还是那样呢。

不过微信内部大概可以看到代码的提交日志之类的东西,我们拿不到这方面的材料。但面对这样的对于时间记录之不敏感,我还是太震惊了。

我不知道以后历史学家会怎么写这件事,怎么引用这方面的资料,如果微信公众平台还能活个 5 年、10 年,发挥它的一点文化影响力的话。或者我们这个信息技术革命的时代,在信息技术领域不需要历史,也不需要历史学家了。

博客本应在其中发挥出它的作用的。

上限

最近,我可能开始写一系列以知识为话题的东西,这些东西大而空泛,说起来也听没劲的。不过反正我的博客也没有读者,或者说是几乎没有,所以就这样吧,看能写一点是一点。这些内容可能从我写程序方面写写,可能从设计领域的东西写写,因为只有这么两个方面我自认为还不算特别特别的差,可以作为个不完全对照的分析吧。这些东西很多是不满的吐槽,也没怎么经过整理,也许以后有机会会整理成一个系列吧。

我很喜欢有上限的事情,尤其喜欢有上限的学习。

什么叫有上限的学习呢?这就是说,学到够用就好。像我们在实践当中的学习就属于是有上限的学习。譬如我造一点小程序,我比较喜欢使用已有的库,这样的话,我能很容易就理清自己要完成的东西的脉络。这也就意味着,我只要完成这一部分的东西就足够了,完成这一部分就能基本实现自己最初的想法。

要想能够「有上限地学习」大概首要条件是能够有需求。这样的需求,比如前面说的写程序就是一个,还有就是做实验,做实验的话我能搞清楚自己要做什么,能得到什么样的结果。这么个需求首先要让我自己相信我能够实现,第二呢,我也能比较容易根据现有知识理清自己的路径将会是怎么样的,剩下的就是自己学习,然后根据自己学习的东西实践出来就行了。

当然,做到这些还有一个条件,就是有足够好的技术资料。比如说吧,看一些东西,我比较希望能够有相对完善的中文或英文的 PDF 资料,最好还要是 LaTeX 编译成的,这是最顶上的层次;其次,如果网上的网页索引足够方便的话,也是可以的,比如 Python 的资料我都是直接利用网上的文档。文档内容的话,首先应该有个综合性的介绍(introduction),也就是讲讲这个东西是解决什么问题的,和前后的段落有什么样的关联,让我相信这个东西有用、而且能够搞清楚我需要关注的点在哪里,紧接着教程(tutorial)可以是解决一个大问题的一步,并说明白是哪一步,然后在读完教程之后,又有参考(reference)可以读,也就是说是可以快速翻阅的材料,这里电子材料就比较方便,因为这些内容是可搜索的,而一个关键字在一本书里面也出现不了几次。如果上面的那些条件不能得到满足,我就会在寻找参考材料上面兜圈子——要么是自己看着不爽看不下去了,要么就是自己不断找能够满足自己要求的材料,即使在计算机上这种情况我自己也是经常发生。1

另外一个条件就是足够便捷的纠错(debug)方法,即除错方法。像 Python 的交互终端(REPL, interactive shell)命令提示也是个好办法,出了问题他会自杀然后抛出错误类型,告诉你跑到什么地方了,然后给出调用堆栈,这方面 C/C++ 就不那么友好。经常是动不动就 Segment Fault,或者像前两天在 Windows 下调试程序,程序就在那儿挂着,很不方便,不过也可能是我具体的参数配置得不对,或者标准不太清楚的问题。

还有,我比较希望有足够的时间宽容度。不要总要求在什么时候把事情做完,这么个搞法不靠谱。一定的时间宽容度就意味着我能有机会真正地喜欢去做它,而不把它做成一个任务,后者我会特别抵触。

现在学校学习就上面几条条件一条都不占。

继续阅读“上限”


  1. 这一部分的分类方法,即 introduction – tutorial – reference 三步属于是我的理解,但后来想象,可能跟前两天在爆栈网站(Stack Overflow)上看到的一个 C++ 书籍终极推荐有关,感觉这种分类方法和我的想法非常统一的样子。