很多用户在发文时，喜欢给自己的文章加上尾巴，咳咳，我也是这样作者之一。但是呢，最近在浏览一些文章时发现，有些朋友给文章加了长长的尾巴，甚至比文章本身的长度还要长，这样做真的可取吗？

(图源 ：pixabay)

首先，我们来分析一下加尾巴的目的。加尾巴我分析无外乎以下几种目的：

• 附带一些与正文相关联的文章便于延伸阅读
• 增加自己一些文章的曝光度，或许能骗到更多的点赞
• 让文章看起来长一些

我们来分别探讨一下。

列出关联文章

关联文章包括但是不限于以下情况：

• 你的系列文章，前后有依赖
• 你创作时参考的文章，可以让读者更好的理解你的正文
• 有关术语，技术背景等资料，可以让读者进行深入的了解

这类文章加到尾巴里，无疑会让文章更加丰满，极大的方便了读者，所以适度添加有价值的关联文章是值得推荐的。

增加曝光度

很多作者倾向于把相关不相关的自己的文章通通堆上去。我私下里问过一两个作者，你放那么多链接到底是为了啥？他/她们回答，这样可以增加我其它文章的曝光度啊，万一哪个读者看我正文之后，再顺便点进我的其它链接，然后给我点个赞，岂不是赚了？

我好想和他/她们说，别做梦了！知道CN区每天多少文章吗？答案是每天近600篇文章，假设每看一篇文章耗时1分钟，那么需要10个小时来阅读完毕。谁有10个小时每天来看这么多文章？即便来看，每篇1分钟的时间还有精力注意你的尾巴？

真正看你文章的，都是真粉丝。你的文章他/她基本都看过或者赞过。所以没必要再加长长的尾巴给你粉丝制造负担了。也不用担心他/她漏了你的文章，如果他/她想看的话，会去你的主页中找的。况且不是有个东西，叫搜索引擎吗？

看起来长一些

好吧，你可能回答，我只是让文章看起来更长一些，毕竟文章长一些，会让别人觉得我付出了很多努力，然后点赞的时候也会给我多一些比重。

额，读者们并不傻，他们阅读和点赞肯定有自己的准则，或者文章长度是其中之一，但是这么无意义的长度肯定不是判断依据，相反，可能会降低读者对这个文章的评价。

毕竟在STEEM上，时间是很宝贵的，花费很大精力打开一篇正文没啥含量都是尾巴的文章，任谁都不会很爽吧？如果是走流量上网的，就更晕了。

长此以往，估计真爱粉都会流失光吧，毕竟STEEMIT上，取消关注不是啥复杂的操作。

总结

小尾巴到底多长比较好？

我个人觉得，不要为了加尾巴而加尾巴，只列出读者可能需要的关联的内容就好。

善待真爱粉，他们才不会弃你而去。

(图源 ：pixabay)

注：文章为个人观点，仅供参考

This page is synchronized from the post: 闲扯淡：小尾巴多长比较好？

之前我折腾了一通比特股的节点，终于咱也用上了自己的私有节点啦。用上私有节点之后，腰不酸了，背不疼了，腿也不抽筋啦，当然了，每月40刀的VPS费，还是很让人心疼不已的。

（图源：bing.com）

虽然用上了私有节点，但是我亲历了比特股爆仓事件之后，我觉得我真的不适合交易，无论做啥操作，我基本上都能准确的和市场趋势保持相反。但是弄个私有节点啥也不干有点浪费，那就折腾玩吧。

话说，之前我曾经写了个简单的脚本，查看指定市场当前订单情况，但是呢，但是这个脚本需要我每次手动运行一下，生成报表。我也有想过用循环随时刷新，但是因为当时用的第三方节点，延迟大概有3-5秒的样子，所以随时刷新是不现实的。

但是有了私有节点之后，我的这个想法又再次萌生，这次不存在延迟的问题了，是不是可以考虑做一个随时刷新的市场行情列表啦。而既然延迟不是问题，那么随时刷新就剩一个问题需要解决了，那就是在原地刷新，不然一屏屏的数据滚来滚去，我估计我是受不了的。

原地刷新的思路

那么如何解决原地刷新的问题呢？我首先想到的就是ASCII码表里的回车、换行、退格。

退格没啥说的啦，但是很多朋友搞不清楚回车、换行有什么区别，我这里简单说一下：

• 回车，即让光标回到行首
  比如：print("I am oflyhigh\r", end='')
  

  A carriage return, sometimes known as a cartridge return and often shortened to CR, <CR>or return, is a control character or mechanism used to reset a device’s position to the beginning of a line of text. It is closely associated with the line feed and newline concepts, although it can be considered separately in its own right.

• 换行，开启新的一行
  比如：print("I am oflyhigh\n", end='')
  

  Newline (frequently called line ending, end of line (EOL), line feed, or line break) is a control character in a character encoding specification, like e.g. ASCII. It is used to signify the end of a line of text and the start of a new one. Text editors set this special character when pressing the Enter key.

(引用部分为维基百科的解释)

有了上述了解后，我们就可以：把原地刷新问题处理成将光标移回到起始点问题

比如，这段代码：

1
2
3

print("I am oflyhigh\n", end='')
print("I am oflyhigh\n", end='')
print("\r\b\r\b\r", end='')

光标又回到原点啦

以下这组代码，可以实现程序原地刷新

1
2
3
4
5
6

import time
for i in range(1,100):
        print("I am oflyhigh\n", end='')
        print(f"Seconds: {i}\n", end='')
        print("\r\b\r\b\r", end='')
        time.sleep(1)

清理屏幕区域

到了这里，似乎我们可以实现实时刷新的市场行情信息了。但是，我在实际运行过程中却发现一个奇怪的问题。

本来报价列表应该是这样的：

但是跑着跑着却变成这样：

（后边多一列或者多列竖线）

我研究了半天，才研究明白，原来列表的宽度有有可能变化的，比如出现一两个大单，这样字符串就特别长，把列表撑宽了，然后大单被消灭掉，列表恢复原来的宽度，但是之前写在屏幕上的数据还在，就出现这样的情况喽。

于是乎我又想了个办法，就是先输出一排排的空格，将屏幕指定区域清空，然后再重新输出数据，一切OK。

总结

• Python 程序原地刷新问题可以换成光标控制问题。
• 新输出的内容比原位置内容短，就会在行尾出现无意义内容。
• 在屏幕上输出N个长度的空格，可以清空指定区域。
• 可以将光标复位、清空内容、光标复位封装为清屏回位函数
• 配合清屏回位函数与程序的输出，可以轻易实现程序原地刷新

相关链接

• 更新了一下bitshares节点以及轻钱包
• 每天进步一点点：bitshares中生成指定市场的订单列表
• https://en.wikipedia.org/wiki/ASCII
• https://en.wikipedia.org/wiki/Backspace
• https://en.wikipedia.org/wiki/Carriage_return
• https://en.wikipedia.org/wiki/Newline

This page is synchronized from the post: 每天进步一点点： Python 如何实现程序原地刷新

很多年以前，我所在的公司和日本公司合作一些项目，既然做项目难免和各种文档打交道，对方提供一些技术文档作为输入，而我们也时不时的弄些或者技术或者汇报类的文档作为输出。

日本公司在用户界面上要求尤为苛刻，无论是软件的界面，还是文档的格式。软件界面有一堆UI式样书来约定，无论是字体、字号、边距、行距什么的都约定得清清楚楚，让你没有一丁点的发挥余地。文档格式也同样如此，现在再把十几年前的文档拿出来，依然忍不住赞叹，简洁大方、清晰明了、看着舒服。

既然日方的东西这么先进，于是公司范围内掀起了向日方学习的高潮。于是不少人投身到文档模板的设计当中，针对字体、字号、页眉、页脚、什么情况用粗体、什么情况用斜体等等做很严格的约定。然后开各种会议要求大家遵循这个标准，所有输出文档必须符合要求。

这之后，开的一些评审会，原本焦点应该是一些技术问题，结果一大帮人讨论来讨论去最后变成文档格式的问题，一帮人针对某段话某个字符的格式争吵不休，乐此不疲。而技术问题，反而无人问津。

针对这个情况，我和当时的上司反应了一下这个问题。大意是我们的项目很多技术难关需要攻克，而始终进展缓慢，文档是项目的一部分，但是最终我们做项目依靠的还是技术，而不是文档。现在大家把都精力放到文档格式上，这样岂不是舍本逐末？

当时上司思索了片刻，然后这样回答我：“我们技术水平不行，很烂很烂，如果我们再不把文档做得漂漂亮亮的，如果彰显我们国际化大公司的风范？” 这回答让我无言以对。

说实话，这个上司一直是我最敬佩的人之一，哪怕已经过了十几年，他无论是学识还是技术或者的运营能力都让我佩服不已，从他身上，我学到了很多东西。但是事隔多年，我对他当年这个答复依旧是不以为然。

无论是文档还是文章，首要的目的是传达内容和思想，这好比是一栋大楼的基础和楼体，而格式之类的东西只不过是一些外在的装修。当然，我从不认为格式不重要，或者认为大楼的装修没有必要，我只是觉得，如果一栋大楼基础就不坚实，楼体是豆腐渣工程，那么装修得再漂亮也改变不了豆腐渣工程的事实，说不定哪天就轰然倒塌了。

如果是格式之类的是锦上添花，那么前提是，你的文章是丝绸是锦缎，如果是卫生纸，那么终究避免被用后冲走的命运。希望大家多创作出优秀的内容，再缀以完美的格式，不要向我一样，这不又生产出来一卷手纸😭。

查了一下锦上添花的翻译：Add a beautiful thing to a contrasting beautiful thing
有点意思。

This page is synchronized from the post: 回忆录之：文档格式的旧事

Steem和Bitshares都支持RPC，也就是远程过程调用(Remote Procedure Call)，这东西要我给出个正式的定义有点难，总之我理解就是通过RPC可以像调用本地函数一样使用远程服务的一些函数，来实现很多功能。

（图源：bing.com）

steem和bitshares都支持JSON PRC，在之前的文章中我没少和大家一起探讨，感兴趣的可以去翻翻。今天我来介绍一个Python自带的XML RPC库，来了解一下这东西咋玩。

Python 2.X

在Python 2.X里使用SimpleXMLRPCServer很简单，举一个简单的例子：

xmlrpc_server.py2

1
2
3
4
5
6
7
8

from SimpleXMLRPCServer import SimpleXMLRPCServer

def hello():
        return "Hello World!"

server = SimpleXMLRPCServer(("localhost", 8001))
server.register_function(hello)
server.serve_forever()

xmlrpc_client.py2

1
2
3

import xmlrpclib
client = xmlrpclib.ServerProxy("http://localhost:8001")
print client.hello()

运行 & 结果

首先启动server
python2 xmlrpc_server.py2

然后我们在另外的终端中运行client
python2 xmlrpc_client.py2

在server所在终端会显示类似如下信息：

127.0.0.1 - - [08/Feb/2018 20:45:54] "POST /RPC2 HTTP/1.1" 200 -

在client所在终端，我们会得出结果：

Hello World!

Python 3.X

在Python 3中，xmlrpclib被移到xmlrpc.client, SimpleXMLRPCServer被移到xmlrpc.server，所以上述代码要略作修改。

xmlrpc_server.py

1
2
3
4
5
6
7
8

from xmlrpc.server import SimpleXMLRPCServer

def hello():
        return "Hello World!"

server = SimpleXMLRPCServer(("localhost", 8001))
server.register_function(hello)
server.serve_forever()

xmlrpc_client.py

1
2
3

import xmlrpc.client
client = xmlrpc.client.ServerProxy("http://localhost:8001")
print(client.hello())

运行 & 结果

首先启动server
python3 xmlrpc_server.py

然后我们在另外的终端中运行client
python3 xmlrpc_client.py

在server所在终端会显示类似如下信息：

127.0.0.1 - - [08/Feb/2018 21:06:14] "POST /RPC2 HTTP/1.1" 200 -

在client所在终端，我们会得出结果：

Hello World!

结论

在Python中使用XML RPC还是很简单的，当然了，还有一些较高深的使用方式以及出错处理等，可以去参考手册了解更多，本文就不再赘述了。

另外尽管XML RPC很方便，我还是倾向于使用JSON RPC，回头在和大家分享一下Python里JSON RPC的库吧。

参考链接

• https://docs.python.org/2/library/xmlrpclib.html
• https://docs.python.org/3/library/xmlrpc.html

This page is synchronized from the post: 每天进步一点点：在Python 中使用 XML RPC

一个多月以前，为了实现赚一个亿的小目标，我在0.135的价位果断梭了一些狗币。做起了狗币涨到1W每枚，我赚它几个亿的美梦。然而，天有不测风云风云，随着比特币大哥跳水，狗币也不甘示弱，我要跳得更迅猛，于是一路跌倒1-2分，于是天亮了，梦醒了。

但是我可是立志要成为亿万富豪的人，怎么能被这点小小挫折所打击到呢？梦醒了，我们还可以继续睡啊。既然数字狗币不给力，我梭它点实物狗币会如何呢？恰逢实物狗币ICO，当然要毫不犹豫地参与了。

原本我告诉朋友，多多益善，不差钱，使劲梭。结果，最终他只帮我梭到了一盒。我拿到整整一盒狗币后我就震惊了，咋缩水这么多呢？仔细一看原本都是一盒200枚，这次变成100枚了。哭，这样涨到多少才能实现我赚一个亿的小目标呢？

不过ICO发行方越来越会搞了，狗币这盒做得这么精美，让我怎么忍心拆封啊。况且，据内部人士说，狗币从银行出库的时候，都要去掉外包装盒的，不允许整盒流入到市场。所以整盒的，尤具增值潜力。那就不拆了吧。随便拍拍盒子看看吧。

来看看狗年纪念币长啥样吧，网上找的图：

这小狗这么可爱，一定是在对我说旺旺旺，想必这次投资不会让我亏钱吧！也许年底就涨到1W一枚了呢，100枚说多不多，说少不少，也小100万呢。买不起豪宅，要求不太高的话，换个档次不高的小豪车还是有可能的。

嗯，就这么定了，我继续睡一会去，谁都不要吵醒我。

相关链接

• 娱乐贴：狗年买了点狗币 / Dogecoin

This page is synchronized from the post: ICO不停梭，明年能不能换豪车？/ 梭了点实物狗币

这两天有朋友问我，现在STEEM价格超过了SBD，那么发文是不是选择 Power UP 100% 更合算呢？你看CN区也有一些新老朋友选择 Power UP 100% ，是不是该向他们学习呢？

判断原则

关于这个问题，我记得我应该和大家探讨过很多次了，但是很多老鸟也时常搞不清楚到底是如何判断的，包括我自己在内也时常的迷糊。比如朋友问我的： “为什么明明STEEM的价格已经超过了SBD，还不选择 Power UP 100%呢？ Power UP 100% 发SP，很明显更合适啊？” 我一时半会也想不起来该如何反驳他。

为此我只好去找我之前的文章，比如说：

• STEEM圣诞发糖果，发文千万不要选择 “Power Up 100%”
• 老生常谈，是否100% Power UP？ 公众号新功能！

其中主要结论就是：

• 内部核算价格 > 市场价格时: 选择 Default(50%/50%)，这个肯定没错
• 内部核算价格 < 市场价格时: 比例悬殊时选择Power Up 100%，否则视情况操作。

微信公众号

尽管上述判断原则很简单啦，但是对于普通用户而言，去找内部核算价格（喂价）以及市场价格，再去做判断终归麻烦一些。

所以是时候关注微信公众号啦，它会建议你发文时该如何选择，只需输入pu

看吧，两种模式，收入相差一倍之多。

公众号发文建议功能之前有一个小BUG，市场价格我使用的是get_ticker返回的latest也就是说最新成交价。

但是在某些情况，订单撮合引擎会撮合买卖数量非常低的 订单，比如0.001个STEEM，这时候价格偏差就会比较大，比如明明市场价为1.2SBD/STEEM的时候，出现3SBD/STEEM的价格。而如果我们用这个最新价格去做判断，就可能得出偏差极大甚至错误的结论。

尽管出现上述情况概率很低，但是一旦给大家带来误导就不好了。所以今天我对公众号判断发文建议的部分做了一点小小调整，使用(highest_bid + lowest_ask)/2来作为市场价格，这样就不会出现上述极端情况了。

公众号添加方法

还没加公众号的，快点上车啊

• 方式一：
  进入微信通讯录->点击公众号->点右上角加号->搜索steemit，关注即可。

• 方式二：
  直接扫描以下二维码：
  

结论

• 当前还是选择 Default(50%/50%) 更加合算
• 使用公众号可以快速查询发文选择建议
• 公众号修复了一个小BUG，更加靠谱

This page is synchronized from the post: 发文选择建议，以及公众号的小小修改 / 100% Power UP? No!