我有一个便携CD机，松下SL-510，超薄、银色金属外壳、40秒防震，20年前花费上千大洋购买，对它我爱不释手。但是我想说不是这个CD机，而是在梦里我时常梦见的一款CD机。

(图源 ：pixabay)

在梦里，我有一个超便携CD机，为何叫超便携呢？因为它只有普通CD机1/4的大小。浅绿色，金属外壳，带着梦幻般蓝色的液晶显示屏。

在以前的梦里，它时常伴随着我，在我学习时、在我工作时、在我外出游玩时，它唱着好听的歌曲给我。为何是唱着好听的歌曲，而不是播着好听的歌曲呢？因为它很懂我，我也很喜欢它，它更像是我的伙伴而不是我的工具。

可是在最近的梦里，我却遍寻不到我的小伙伴了。学校的书桌内，办公室的抽屉里，乃至家里的每一个角落，我都寻不到了。我的小伙伴哪里去了呢？是我不小心遗落在哪里？还是我把它借给了哪个朋友？又或者是不幸地遭遇了窃贼？

(图源 ：pixabay)

想必不小心遗落，这种事情不会发生，我视若珍宝的东西，每次使用时都小心翼翼，每次用完都呵护有加地收起来，怎么可能出现不小心遗落的情况？想必借给朋友这种情况也不会发生，梦里的朋友们都知道我对这个小CD机的珍爱有甚于我的性命，哪个朋友会忍心向我借命呢？即便他开口，想必我也会回绝的吧？

那么，我一定是遭遇了窃贼，可恨的该杀千刀的窃贼，哪怕窃走我的一切财富，都不会让我如此痛恨，但谁让他窃走了有甚于我的性命一般的小伙伴呢？但是遭遇了窃贼，也意味着我再也寻不回我的CD机了。我只希望这个窃贼会好好对它，像我一样爱它呵护它，但是一个窃贼又能对他抱有怎样不切实际的幻想呢？还是期望窃贼给它寻一个靠谱的新主人更靠谱吧？

(图源 ：pixabay)

我醒来，发现这不过是一个梦，不胜慨叹。我再也寻不回我的CD机了，哪怕是在我有着一定超能力的梦里。不知道为何，我经常梦到一些连续的情节，如若梦里有着一个截然不同的世界以及截然不同的人生。那么在那个世界，在那个人生中，我再也寻不回我的CD机了。

而现实中，当下的人生中，我却只有一个松下SL-510，已经被我束之高阁十数年了，我虽然曾一度当他是我的好伙伴，但是我想我没爱梦里的CD机那么爱它。

(图源 ：pixabay)

我梦里的CD机不复存在了，无论是在现实中，还是在梦里，都不在了。大凡过于美好的事物，总是不存在的罢，或者只能存在于过去的梦里。

This page is synchronized from the post: 梦中的CD机

十七年前的11月18日，朋友送我鲁迅的散文诗集《野草》。

你若问我为何记得如此清楚，其实不是我记忆力超人，而是扉页上题着如下赠语：

XXX
我的好朋友
送给你喜欢的书
希望将快乐
送到你心底
——诚挚的朋友 XX
2000、11、18

这真的是我喜欢的书，我翻看了十几年依旧爱不释手，以至于封面都有一些脏兮兮的。当年我能背诵这本诗集中几乎所有的诗篇，而如今却仅能记下零星的片段。

而这本诗集中，我最喜欢的无外乎《墓碣文》以及这边《野草》的题辞了。

今晚和另一友人聊天，却突然想起这篇《野草题辞》，想起我希望这野草的死亡与朽腐，火速到来的经典句子，想起很多被自己当作已然忘记却终会记起的往事。

但是正如野草题辞所言：当我沉默着的时候，我觉得充实；我将开口，同时感到空虚。但既然说无可说，那么就静等这野草的死亡和腐朽，火速到来吧。

野草题辞原文：

当我沉默着的时候，我觉得充实；我将开口，同时感到空虚。

过去的生命已经死亡。我对于这死亡有大欢喜，因为我借此知道它曾经存活。死亡的生命已经朽腐。我对于这朽腐有大欢喜，因为我借此知道它还非空虚。

生命的泥委弃在地面上，不生乔木，只生野草，这是我的罪过。

野草，根本不深，花叶不美，然而吸取露，吸取水，吸取陈死人的血和肉，各各夺取它的生存。当生存时，还是将遭践踏，将遭删刈，直至于死亡而朽腐。

但我坦然，欣然。我将大笑，我将歌唱。

我自爱我的野草，但我憎恶这以野草作装饰的地面。

地火在地下运行，奔突；熔岩一旦喷出，将烧尽一切野草，以及乔木，于是并且无可朽腐。

但我坦然，欣然。我将大笑，我将歌唱。

天地有如此静穆，我不能大笑而且歌唱。天地即不如此静穆，我或者也将不能。我以这一丛野草，在明与暗，生与死，过去与未来之际，献于友与仇，人与兽，爱者与不爱者之前作证。

为我自己，为友与仇，人与兽，爱者与不爱者，我希望这野草的死亡与朽腐，火速到来。要不然，我先就未曾生存，这实在比死亡与朽腐更其不幸。

去罢，野草，连着我的题辞！

一九二七年四月二十六日，鲁迅记于广州之白云楼上。

很抱歉，弄了好久，排版也没弄好，将就看吧。

This page is synchronized from the post: 我希望这野草的死亡和腐朽，火速到来

这两天总有朋友问我，为什么我的帖子奖金变少了？我一看额，大家的帖子收入都变少了，收入大约减少了三分之一或者更多。

(图源 ：pixabay)

其实一个更直观的就是，点赞增加的金额变少了，比如我这个ID，很多天以前点赞可以增加约27SBD，前几天可以增加约22SBD，而刚刚我测试了一下，只能增加17SBD了。这其中虽然有Voting Power变化导致的差异，但是我的VP一直以来变化其实是不大的。

帖子的(显示)收益

那么你可能会问，到底是什么导致帖子收益/点赞金额的减少呢？

为了搞清楚这个问题，我们首先需要知道帖子的收益以及点赞金额是如何计算的。在我之前的一系列帖子中，我曾经不止一次分析过这个问题，可惜我写的搜索工具因为steemdata的缘故已经无法正常工作了， 我自己又懒得去翻，那就大致说一下结论。

帖子的(显示)收益 = 帖子的收益(代币) x 代币中间价

在整个系统内部，帖子的收益是以代币进行核算的。也就是说，尽管我们看着每个帖子显示的预计收益为100SBD、1000SBD，但是实质上系统内记着的是 20 STEEM、1000 STEEM，这样说可能不太严谨，我们接下来继续详解。

帖子的(显示)收益 & 奖励池

那么这个代币又是如何计算的呢？这涉及到奖励池的概念：

比如上图就是奖励池的当前状态。

在本贴中我们需要关注奖励池两点，一是奖励池余额，一个是最近申领总份额(rshares计算)。

而我们帖子的代币收益：即为: `post_rshares / rf[‘recent_claims] rf[‘reward_balance’]`*
也就是说，按我们帖子被投票得到的总的 rshares占最近申领总份额的比例去分配奖励池的总奖金。

所以，对于我们的帖子而言，影响代币收益变化有以下因素：

• 帖子被投票获得的rshares
• 奖励池总金额
• 总的申领份额

其中第二、第三点，我们几乎控制不了(SP高的可以通过踩人略加影响)，那么对我们而言，只有帖子投票的增减或者被Downvote才会有所影响。

什么影响最大

那么你可能马上会有疑问，不对呀，我的帖子投票也没增加，也没人差评，为何显示的收益金额变化如此之大？当然了，如果收益增加了就无所谓了，但是减少了，终归不爽！

让我们回头再看最初的公式：帖子的(显示)收益 = 帖子的收益(代币) x 代币中间价

既然帖子的(代币) 收益变化不大，那么影响帖子的(显示)收益的主要因素当然就是代币中间价喽。

而前几天这个喂价为5.8，再早一些时候这个喂价高达7.x

那么想必你明白了，为何帖子价格变化如此之大了吧？

影响喂价的因素

这里的喂价其实是来自见证人喂价的3.5天均价，至于这个均价是咋均的，说实话我也不知道。但是见证人的喂价一般而言是来自交易所的STEEM价格。

所以STEEM涨，则喂价涨，反之亦然。不过因为是3.5天均价，比起STEEM价格变化略为滞后。

而前两天BTC的大瀑布导致各种币一起跳水，STEEM也未能幸免，所以加上滞后效应，这两天喂价几乎是这段时间的最低点，帖子价格当然变少喽。不过好在现在STEEM价格稳步回温中，想必过不了多久，喂价也会上来吧。

总结

• 帖子的(显示)收益 = 帖子的(代币)收益 x 代币中间价
• `帖子的(代币)收益 = post_rshares / rf[‘recent_claims] rf[‘reward_balance’]`*
• 代币中间价即为来自见证人喂价的3.5天均价，见证人喂价和交易所STEEM价格有关
• 帖子收益变少，主要是这几天STEEM价格下跌导致

This page is synchronized from the post: 为什么帖子的奖金变少了？

我是个对手机要求不高的人，当朋友们已经开始用各种智能机的时候，我虽艳羡不已，但是还是用着老旧的功能机，后来一个Iphone 4S 我更是使用了近4年，然后换了个华为的手机我用了快2年了。如果不是现在聊微信都有些卡，我是舍不得换手机的。

(图源 ：pixabay)

换什么手机好，我纠结了好久。苹果用着是很舒服，但是因为有两个常用手机号，无法双卡双待属实是个大问题，我总不能带两三个手机出去。我周围好几个朋友倒是总带几个手机出门，这让我想到双枪老太婆😳

华为的手机，如果不是那么卡，如果不是系统有点别扭，那么我还是很喜欢的。但是想到或许还要忍受一个相同的系统两三年，我就决定放弃了。

朋友有锤子的铁粉，一直鼓动我买锤子，想想还是不做吃螃蟹的人了。想想想去，选择了三星，当初S6出来我就觉得超级惊艳，可惜后来S7爆出了爆炸丑闻，现在出了S8总归不会再炸了吧？于是下单了个Samsung Galaxy S8 试试看。

不多说了，上开箱图：

简单地设置了一下，开机。话说现在的商家真烦，非得搞个什么插卡激活，我只用来连WIFI上微信就不行吗？当游戏机不行吗？哎。三星的卡槽只支持小卡，我的移动卡是中卡，放不进去，还好我手头的联通卡可以自行掰成小卡，否则买个手机用不了就笑话了。

用惯了四四方方平平整整的屏幕，这个曲面屏还真有点别扭，估计要适应一段时间吧。试着放了俩歌，家人一致评价这山寨机的感觉，和苹果的音质没法比。不过我估摸或许是音箱没煲好的缘故？也许用一段时间就圆润了呢？

三星还送了个无线充电器，不过还没试怎么样，不过说起来其实没啥神奇的，不过是两个线圈而已。玩IOT那阵没少玩过，到手机里就变成了高科技。

但愿这个手机也能坚持两三年吧，换来换去，太麻烦了。

网上找了个Samsung Galaxy S8 的图做首图，就是我买的雾屿蓝哦，可是为啥人家的这么漂亮呢，哎！

This page is synchronized from the post: 换了个新手机 / Samsung Galaxy S8 (雾屿蓝)

我们都知道，对于炒币而言，行情很重要，用在bitshares的内部市场，这个原则同样适用。我的微信公众号可以查询行情，但是由于微信公众号本身的限制，没法显示更多内容，比如买单和卖单的列表。

(图源 ：pixabay)

查看行情

网页钱包中我们可以查看指定市场的买单和卖单列表

但是我们需要滚动滑块来查看更多条目，并且序号，滚着滚着就懵了😵

鼓鼓钱包中同样可以查看指定市场的买单和卖单列表，但是需要单独查看买单和卖单。

于是我就想，能否自己做一个列表，将指定市场的买单和卖单信息按我想要的方式组织到一起呢？

获取订单列表API

说干就干，获取订单列表的API为get_order_book

先使用curl测试一下这个API：
curl -s --data '{"jsonrpc": "2.0", "method": "get_order_book", "params": ["CNY", "BTS", 5], "id": 1}' https://openledger.hk/ws

我们会得到如下信息：

可以返回内容包含： base、quote、asks、bids

顺便说一下我个人的理解：

• Base: 基础资产，用于计价的资产
• Quote: 买卖资产，就是要买卖的资产
• Ask: 要价，也就是卖单
• Bid: 出价，也就是买单

代码

尽管我上述CURL命令已经返回了订单列表，但是，这是给人看的吗？为了让显示对人类更友好，我写了如下代码：

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39

from bitshares import BitShares
from prettytable import PrettyTable

base = 'CNY'
quote = 'BTS'
limit = 20

bts = BitShares()
ob = bts.rpc.get_order_book(base, quote, limit)

ask = "Sell"
bid = "Buy"
t = PrettyTable(["No.", \
        f"Price({bid})", f"{quote}({bid})", f"{base}({bid})", f"{quote}({bid})Sum",\
        f"Price({ask})", f"{quote}({ask})", f"{base}({ask})", f"{quote}({ask}) Sum"])

t.padding_width = 1
t.align = "r"

bid_sum = 0.0
ask_sum = 0.0
i = 0
for ask, bid in zip(ob["asks"], ob["bids"]):
        i += 1
        bid_sum += float(bid["quote"])
        ask_sum += float(ask["quote"])
        t.add_row([
                i,
                "{:.5f}".format(float(bid["price"])),
                "{:.5f}".format(float(bid["quote"])),
                "{:.5f}".format(float(bid["base"])),
                "{:.5f}".format(bid_sum),
                "{:.5f}".format(float(ask["price"])),
                "{:.5f}".format(float(ask["quote"])),
                "{:.5f}".format(float(ask["base"])),
                "{:.5f}".format(ask_sum)
                ])

print(t)

测试

运行上述代码，可以生成如下报表：

左边为买单按价格从高到低排列，右边为卖单按价格从低到高排列，另外加上了序号和总量统计。

优化

代码很烂，将就看吧，显示精度啥的随便写的，感兴趣的可以自行优化一下。

另外，可以考虑加上指定节点提速，指定排序方式，指定总量统计的类型，甚至可以考虑将买单卖单分别显示等等，还可以考虑通过命令行参数指定其它市场等等。

对于我这种懒人，做到这样就可以啦。

相关链接

• Python PrettyTable 模块学习 (格式化打印内容)

文中代码仅为思路演示，不保证无误，仅供参考

This page is synchronized from the post: 每天进步一点点：bitshares中生成指定市场的订单列表

在之前的一篇文章中，我曾经设想过读取某个时间段内的区块，尽管最后没能成功，但却提供了一个思路。

(图源 ：pixabay)

20多天过去了，今天我决定抽出时间来实现一下当初的设想，首先我们简化一下问题，读取时间段内的区块，我们只需知道时间点1对应的区块编号以及时间点2对应的区块编号即可，那么这个这个文件可以简化为：如何获取指定时间点的区块编号？

原理

获取指定时间点的区块编号基于以下原理：

• 每个区块都有时间戳(timestamp)
• 两个相邻区块之间的时间间隔为3秒

那么我们拿任意块的时间戳与我们指定的时间点之间的差额，即可计算出中间间隔了多少块，进而计算出目标区块的编号。

换成简单代码逻辑就是：

1
2
3
4

db_base = Block(base_num).time()
seconds = dp - dp_base
blocks_diff = int(seconds / 3)
block_num = base_num + blocks_diff

问题

但是上述伪代码改成成实际代码并执行后，计算出来的区块编号(block_num)对应区块的时间和我们的目标时间点之间存在较大的差异，这是什么原因导致的呢？

比如上图，我们实现了一个粗糙版本的代码用于测试，但是我们期望读到2017-09-01T00:00:00的数据块，但是读出来的区块对应的时间为2017-09-07 02:06:51

经过分析，我得出结论，实际区块产生的时间间隔不是精准的3秒，而是可能会略大于此数值，所以会导致我们的计算有所偏差。

解决

知道了原理，以及存在的问题，以及导致问题的原因，我们就可以做出更加完善的代码，来获取指定时间点的区块编号了。

我们采取的办法是逐渐逼近法，以上边代码为例，我们通过指定时间点以及基准块获取到一个区块的时间点，我们如果这个时间点与目标时间点差异较大，我们则用这个时间点对应的区块作为基准块，重新去获取目标区块。知道我们找到符合条件的区块。

代码

为了更好完成上述任务，我实现了一个粗糙的函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

def find_block_by_time(data_point, base):

        print("\tBase:", base)

        dp = Block(base).time()
        delta = data_point - dp
        diff_seconds = delta.total_seconds()

        if abs(diff_seconds) > 3:
                diff_blocks =  int(diff_seconds / 3)
                base += diff_blocks
                block_num = find_block_by_time(data_point, base)
                return block_num
        else:
                return base

好吧，其实命名应该叫find_block_num_by_time，懒得改了，不然怎么对得起粗糙的称号呢？

测试

例子一：指定邻近区块为基准

1
2
3
4

dp = datetime.strptime('2017-12-01T00:08:00', '%Y-%m-%dT%H:%M:%S')
block_num = find_block_by_time(dp, base=22250000)
print(block_num)
print(Block(block_num).time())

例子二：指定创世块为基准

1
2
3
4

dp = datetime.strptime('2017-12-01T00:08:00', '%Y-%m-%dT%H:%M:%S')
block_num = find_block_by_time(dp, base=1)
print(block_num)
print(Block(block_num).time())

通过例子可见我们都完美地返回了正确的结果，但是例子一计算了2次，而例子二计算了四次，由此可见距离越近，计算得越快。

另外，我们程序只得到时间点临近的块，可能是正好的时间点，可能是之前或是之后，如果想得到不同的结果，需要将结果与时间点对比，判断出是之前还是之后，并根据需求+1或者-1即可。

用途

(图源 ：pixabay)

至于有啥用途，你自己想去吧，我倒是觉得挺好玩的，哈哈。

文中代码仅为思路演示，不保证无误，仅供参考

This page is synchronized from the post: 每天进步一点点：bitshares中如何获取指定时间点的区块编号？