在之前的文章中，说到自己计划把萌蛋弄到 Telegram 上，做一个Telegram bot，准备一步一步似魔鬼的步伐 记录下来。

今天就先来大概了解一些Telegram bot 与微信公众号/微信机器人的异同。

(图源 ：bing.com)

微信机器人

微信公众号机器人

微信公众号收到信息后，微信会把信息发送到你指定的网址上，你的网站程序收到并处理信息后再返回给微信，微信再返回给用户。

所以要给微信公众号添加一些功能，你首先得有一个网站，否则是没法添加一些自定义的功能的。微信公众号无法应用在群聊中，只能坐等用户去访问，这是最大的弊端了。

微信机器人，基于Web版

除了微信公众号，我们还可以直接用一个微信号来跑微信机器人。

微信机器人的本质是利用微信Web版的API收发消息（相当于一个真人登陆微信Web版）。所以微信机器人可以实现很多微信公众号实现不了的功能，比如说在群内应答消息，添加好友，删除好友等功能。

但是由于微信Web版不支持抢红包，所以利用Web版API实现的机器人也无法抢红包哦。另外，对于微信而言，微信Web版修改API比较方便，所以一旦微信API变动，基于微信Web版的机器人将会无法使用。

微信机器人，基于破解版

Web版的机器人比较好实现，有好多前辈监听整理了微信Web版的API，但是每次微信修改API，就得随之变动。另外，也无法实现发红包抢红包等微信手机客户端才有的功能。

所以，更高端的做法是破解（反编译）微信，然后在其基础之上实现各种功能，比如说抢红包。

微信机器人的封号问题

相比于微信公众号，后两种微信机器人使用频度过高的话，非常容易被微信发觉并封号。这也是我后来停掉萌蛋并把其迁移到微信公众号的主要原因。

因为萌蛋那个微信号，我舍不得被封掉呢。

Telegram 机器人

(图源 ：bing.com)

Telegram 机器人最大的优点在于官方提供API。

这样你就无需去研究如何破解Telegram软件，或者如何监听整理API，也不用担心API频繁变动导致的机器人不工作。

Telegram机器人的工作方式类似于基于Web版微信机器人，也就是说无需像微信公众号那样提供一个网址来接收、处理以及反馈消息，我们只需在本地跑一个脚本即可，省却了购买网站空间的费用啊。

除了提供API以外，Telegram还提供了完善的教程以及Python库（别的库应该也有，我没去关注）。你想到的没想到的，Telegram 都帮你想了，帮你做了，所以，你还等什么呢？机器人玩起来吧。

参考资料

• https://github.com/python-telegram-bot/python-telegram-bot
• https://core.telegram.org/bots/api

This page is synchronized from the post: Telegram bot 与微信公众号/微信机器人

20多天以前，开始正式玩起了电报，还特意写了篇文章推销电报X。其实接触的时间可以再往前追溯几个月，但是都是科学上网登一下浅尝辄止，算不得数。

用上电报之后，就觉得这个东西是好玩，各种群组很是热闹，并且好多群里有好玩的机器人可以调戏，于是我就想，似乎我把萌蛋搞进电报里也不错啊。当然了，自己用，有公众号就行了，如果弄一个STEEM 电报群，带上萌蛋一起玩，应该很有趣。

所以，我首先想到建一个群。在我想来建群应该是非常非常容易的事情了。看我的其它朋友一言不合就建群，爽利的不要不要的。于是我就在电报X的界面上点New Group，终然我英语很渣，但是想必这么简单的意思还应该不会搞错。

然而我看到了什么，一个大大的空白屏幕给我了，除了回退，没有任何我可以点击的地方。提示信息应该是没有联系人，可是我明明和很多小伙伴聊得火热啊？他们不是我的联系人，又算是什么呢？

有问题问度娘嘛，我于是用百度Google了一下，结果竟然没有找到问电报建群问题的，感觉大家根本不存在类似问题。研究了好久也没弄出个子午卯酉，于是聪明如如我灵机一动，我找个小伙伴帮我建群，然后在把群主给我当，岂不是一样爽歪歪？

于是电报上联系一热心好友，她果断答应，然后经历了漫长的等待后，她无奈的告诉我，她也建不了群，应该是电报封了大陆的手机段，这样一听貌似也很合理，我的热情被当头浇了一盆冷水，既然如此，那就不研究了。

然而峰回路转，过一会我被一陌生人拖进了群里，介是谁呀，我也不认识啊，怎么就随随便便的拖我入群呢，我可不是随便的人。然后搞了半天才明白是那个热心好友的小马甲以前用过的国外手机号注册的账户。如此一来似乎真的验证了电报建群封了大陆手机的结论呢？

然后让她将群主转移给我，结果发现群主根本没法转移，也就是说我多说可以当个管理员，不甘心呀！我又想了个馊主意，让她主动退群，让位于我，这样我不就变成高大上的群主了吗？结果她退群以后，我依然是个管理员，更悲催的是我无法拉她回来，这个群的各种设置也无法修改，心痛！好在我这个热心好友，又用她小马甲新建了一个群，但是我已经被电报群折腾的心力交瘁。

今天看到 @xiaohui 创建了一个Steemit 中文社区 Telegram 群组，我突然意识到我是不是忽略了或者搞错了什么？小辉也是大陆的呀，没理由他能建群而我不能。在回头看提示信息，没有联系人，难道联系人不是我和聊天的小伙伴们吗？

再找电报X的菜单，发现有个添加联系人的选项，需要输入对方电话。我刚换过手机，通讯录还是空空如也，或者我禁用了电报X读取联系人的权限，总之，应该是此处的问题。

于是我喊 @midnightoil 大神，让他把他电话号码给我，我手动添加到电报X的联系人里，然后再点New Group，一下子就创建成功了，我终于变成了群主喽。

原本应该很简单的一件事，只因为我手机通讯录是空的(没有通讯录好友用电报)，并且我将每天和我聊天的小伙伴们理解成了联系人(话说他们不算联系人吗，应该算啥？)，所以绕了好大一个圈子，并麻烦了我的好几个小伙伴，真是惭愧。

我不由得想起以前帖子中提到的遇到灵异事件时先从自己这边找原因，然而事实上，我再一次盲目自信导致犯错😳。用telegram建群，也许每个小伙伴都会，然而我却用了整整好几天才学会这项操作，捂脸哭~~

This page is synchronized from the post: 人人都会的操作，不见得自己就会 (电报建群有感)

昨天一个朋友微信上问我，是什么契机接触的这个平台？我该如何回答她呢，莫不成告诉她我在别处看到人家说这个平台可以赚钱，然后就杀了过来？尽管可能略有偏差，但是事实大抵如此，但说出去终究有些惭愧，所以我用一句拒绝接受采访搪塞过去。

(图源 ：pixabay)

因何而来

2016年大概是比较清闲的一年，所以有时间爬爬几年没登陆的论坛了。然后看看别人挖坟帖，挖出一些很早以前大家讨论比特币的帖子，很是热闹。

当时比特币以及虚拟货币的人气越来越热，颇有一飞冲天的苗头，于是大家一起讨论要众筹矿场。于是又是讨论矿机又是讨论水电站，一派欣欣向荣的景象，不少论坛成员都表示愿意参与众筹，共同致富。然而万事俱备，就是没有执行人选，大家都愿意出钱，但是没人去执行，毕竟去四川大山里找电站，建矿场啥的，想想就是很辛苦的事情。

正在这时，STEEM横空出世，相比建矿场，STEEMIT上发发文就可以赚钱，看起来简直容易的不要不要的。当时论坛的大佬晒他文章几美元的收入，告诉大家真的可以赚到钱啊，于是没人再提矿场的事，都扑到STEEMIT上来了。

原本我对这东西并不是很感冒，但是天天逛论坛，看他们一个个晒赚了多少多少SBD，都玩得非常高兴，于是我也费了九牛二虎之力注册了个账户，就这么的，我来到了STEEMIT。其实与其说为了赚钱，不如说从众凑热闹更贴近。

神奇的网站

来STEEMIT之后，就完全被它的神奇(能赚钱)所吸引。当时有大佬照顾CN区，并且我提及的那个论坛，有好多朋友注册了STEEMIT投入大量真金白银购买STEEM POWER，所以尽管我第一个帖子只有三个点赞0收益，但是似乎第二个帖子之后，一般都能有接近10 SBD的显示收益。

当时SBD价格应该是1美元附近，10 SBD其实没多钱，但是写写文章就能赚钱，这还是很新奇很令人激动的事情。

记得当时 @laonie 写了两段自我介绍，一下子得了近3千 SBD，@somebody 找人翻译了STEEM的中文白皮书一下子得了近 4000 多SBD，@sweetsssj 介绍了一下女孩去酒吧的秘密，得了数千 SBD，这些激动人心的神话每日上演，让我不止一次的幻想，或许我也能一贴赚几千SBD呢？

辉煌的时刻

我期待一贴赚几千SBD等了好久也没到达，相反到后期越赚越少，在硬叉18初期，一个帖子赚1SBD以下，是司空见惯的事情。

整个中文区，每天就10多个帖子，其中包括@laodr 老道茶馆，我们几个人自娱自乐。有一阶段，我甚至觉得这样真的很好，STEEMIT上赚不到钱，我们发发帖子，娱乐娱乐，或者学习学习区块链知识，多惬意的事情。

当时还有个事情，就是 @abit 开设了#cn-programming 区，每天都在里边给大家讲课，那段时间是我对STEEM了解突飞猛进的日子，如果没有那段时间的授课，我估计我对STEEM的了解，还只是停留在发文赚钱上呢，至于什么区块链、什么节点、什么Transaction、什么数字签名，都是什么鬼，估计我现在也搞不懂。

HF19的到来，犹如平静的湖面投入了巨石，哦不，是炸弹，我在HF19前夜翻译的HF19介绍文章，一下子得了1600多SBD(最高时2000多，一度位于STEEMIT榜首)。曾几度幻想的情况成为了现实，激动的不能自已。

该往哪去

因何而来，已经成为了历史。

惨淡的日子也罢，辉煌的日子也罢，都已经成为了过去时。我时不时的思索，除了发帖赚钱，我们还应该干些什么，或者能干些什么？

但是自己能力有限，做不成英雄人物，也做不了什么改变历史，或者往小了说改变CN区的大事，所以我只能可能的介绍一些我对STEEM的理解，让新人少走一些弯路。分享一些自己心得或者遇到的坑，哪怕是有一个人阅读到了并因此受益，也算成就吧。

我和我的一些朋友聊天，大家似乎都在思索何去何从的问题，但是似乎都没有什么好的答案。既然没有答案，就且行且珍惜吧。哪怕有朝一日不写了，回头再看看自己的这个博客，至少这些内容自己看看还是觉得不厌恶，甚至心中欢喜，这样，就值得了。

(图源 ：pixabay)

相关链接

• Hello steemit! I am Laonie, a Super Superhero, a Hero of Heroes. 老聂的牛逼哄哄的自我介绍贴
• Steem White Paper Translated into Chinese
• The secrets of why girls go to the bar. 女孩去酒吧的秘密。
• 非正式翻译：硬叉19 “平等”即将到来，线性奖励 / Informal translation：HF19 “Equality” Coming Soon: Linear Rewards!

This page is synchronized from the post: 因何而来？

一般情况写一些技术相关的内容时，我都会做足够的测试，来支持我的每一点结论。所以涉及到技术问题时，我一般都附带代码以及执行结果，没有什么比执行结果更有说服力了。

比如今天的《Requests 与 HTTP Keep-Alive》，无论从代码的执行时间还是从调试信息上来看，都证明Requests的会话（Session）中可以自动实现持久链接（Keep-Alive）。

（图源：https://pixabay.com）

有时候明明看着很简单的东西，为了用代码去证明，然后耗费了很长时间，甚至会遇到一些坑，比如之前介绍Click中遇到的docstring 与help冲突的问题。尽管遇到一些坑，尽管去解决这个坑可能花费了好多时间，但是遇坑填坑的过程就是学习的过程，对此我挺欢喜的。

但是有时候也难免会因为太过于自信，不去测试，就下结论，而犯一些错误。今天要说的就是，我冤枉urllib3了。

SO_KEEPALIVE 不等于HTTP Keep-Alive

在之前介绍urllib3时，我已经介绍过了Requests，并且知道了Requests的会话（Session）中可以自动实现持久链接（Keep-Alive）等高级特性。然后我就想，既然Requests一直强调这是高级特性，而Request使用的是urllib3，那么这些高级功能在urllib3上实现起来，总应该略复杂才对。然后我在其它程序中看到如下代码：

1
2
3
4

from urllib3.connection import HTTPConnection
socket_options = HTTPConnection.default_socket_options + \
[(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1), ]
http = urllib3.poolmanager.PoolManager(socket_options=socket_options)

就想当然认为urllib3实现HTTP Keep-Alive要加入上述代码，于是直接在文章中加入了这个结论。

但是今天抽时间测试了一下这个功能，发现加不加上述代码，连接都是Keep-Alive的，那么就说明我之前得出的结论完全错误，另外又产生一个疑问加上述代码有什么意义呢？

通过一番调查，并祭出了我的宝典(200页)，又找了好多网页，大致明白了SO_KEEPALIVE相当于在TCP层实现了以个心跳机制，具体是啥我也没太看懂啦（没研究懂之前，我不敢妄下结论啦），总之，和我们要实现HTTP Keep-Alive是两码事，可以看作是HTTP Keep-Alive设置的特性之一。

urllib3 HTTP Keep-Alive的实现

那么urllib3的HTTP Keep-Alive又如何实现的呢？答案是自动实现的。（好像是废话？) 因为HTTP 1.1中默认启用Keep-Alive，所以无需指定诸如：headers={‘connection’: ‘Keep-Alive’}的HTTP头。

那么如何不让它 Keep-Alive呢？（咦，好变态的需求），答案有两个：

• 设置Header，比如headers={‘connection’: ‘close’}

• 每次清理PoolManager

对比一下，Keep-Alive的输出

结论

不要在没有做充分调研的时候就妄下结论，否则自己弄错了到无所谓，再误导了别人就不好啦。😳

把这个糗事记录下来，与诸君共勉吧。

This page is synchronized from the post: 冤枉urllib3了，望文生义不可取

在半个月以前，我介绍过一个强大并且易于使用的Python HTTP 库：Requests，并且在文章中提及了Requests的会话（Session）中可以自动实现持久链接（Keep-Alive）。

但是古人教导我们纸上得来终觉浅，绝知此事要躬行，不实际演练一下，我总觉得不放心，于是写个小程序测试一下。

思路

我们做一些小程序，遍历获得几个用户的用户ID以及用户名。通过对比程序执行时间，来看看Keep-Alive是否生效。

其实这个是可以通过一个API一下子返回的，那么就一次连接岂不是无法彰显Keep-Alive的作用了，所以就用笨方法喽。

代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

import requests
import json
import time

users = ['lemooljiang', 'ace108', 'oflyhigh', 'deanliu', 'rivalhw']
rpc = "https://api.steemit.com"

start = time.time()
for user in users:
        payload = {"jsonrpc": "2.0", "method": "call", "params": ["database_api", "get_accounts", [[user]]], "id": 1}
        r = requests.post(rpc, data=json.dumps(payload).encode('utf-8'))
        json_r = json.loads(r.text)
        print("id:", json_r['result'][0]['id'], "\tname:", json_r['result'][0]['name'])
end =  time.time()
print("Execution Time: ", end - start)

session = requests.session()
start = time.time()
for user in users:
        payload = {"jsonrpc": "2.0", "method": "call", "params": ["database_api", "get_accounts", [[user]]], "id": 1}
        r = session.post(rpc, data=json.dumps(payload).encode('utf-8'))
        json_r = json.loads(r.text)
        print("id:", json_r['result'][0]['id'], "\tname:", json_r['result'][0]['name'])
end =  time.time()
print("Execution Time: ", end - start)

执行结果

以下为上述程序执行结果：

对比可知，使用Session程序效率大幅提高，这就是Keep-Alive的神奇之处哦。

尽管效率提升很明显，约2-3倍，但是没到很夸张的地步，比如10倍8倍，这是因为我们get_accounts取回的数据量很大，如果数据量很小，网络操作频繁的话，就会更加明显啦。

验证

你可能说，尽管效率提升了，但是一定是Keep-Alive的功劳吗？也许就是Session干了啥不为人知的提升效率的勾当呢？

我们在代码中加入如下语句来打印DEBUG信息

1
2

import logging
logging.basicConfig(level=logging.DEBUG)

我们把程序结果分成两部分截屏，便于比较

通过对比，我们很容易就发现如下规律：

• 第一段程序每次都创建连接，再请求数据
• 第二段程序仅创建一次连接，然后每次请求数据即可

并且我们捎带发现一个秘密，Requests用的urllib3哦。

结论

Requests的会话（Session）中可以自动实现持久链接（Keep-Alive），可以极大程度提升程序的效率，尤其是网络操作频繁的程序。

相关链接

• 每天进步一点点：Python中使用Requests访问STEEM RPC
• Requests: HTTP for Humans
• Advanced Usage: Session Objects

This page is synchronized from the post: Requests 与 HTTP Keep-Alive

前些天看网易新闻的哪个频道说是苹果版本的微信软件支持切换账户了，这真是个好消息。

(图源 ：pixabay)

账户切换

我有好几个微信账户，分别用几台设备登陆。在家的时候还好，出去的时候带一个手机，如果想用其它账户，就得先退出原来的账户，再重新用新账户弄一遍登陆流程，偏偏是我的密码设置的极其复杂，一不小心就会出错，简直令人抓狂。

不过我外出带的是安卓手机，所以尽管看到新闻的时候很激动，但是暂时却享受不到这项福利，只能期待安卓版本微信尽快更新喽。

今天外出照例登陆一下其它账户，嗯，居然支持账户切换了，这以后就方便多了。多账户登陆或者账户切换功能，我可是企盼了几年啊，我都被逼得想去尝试那些微信分身软件了，但是出于安全考虑一直没敢用。看来微信终于肯放下姿态，倾听用户的呼声了。

修改头像

然后我就想顺便给第二个微信号换个头像吧，我觉得原来的头像不太好看。结果操作下来之后却提示我如下信息：

说点啥呢

本来微信增加个切换账户的功能，是很令人兴奋的，然而去用了一下修改头像，就被当头泼了一盆冷水。不过这事怪微信吗？怪微信的话，似乎微信也挺冤枉的，不过那又怪谁呢？

我不由得想起以前看过的一首小诗，或许放这很应景：

Fire and Ice

Some say the world will end in fire,
Some say in ice.
From what I’ve tasted of desire
I hold with those who favor fire.
But if it had to perish twice,
I think I know enough of hate
To say that for destruction ice
Is also great
And would suffice.

https://en.wikipedia.org/wiki/Fire_and_Ice_(poem)

This page is synchronized from the post: 微信切换账户与修改头像，冰火两重天