忘记从哪次硬分叉开始，文章/点赞收益不直接发放了，而是进入到一个叫做reward_***_ balance的池子，然后需要用户自己申领(claim)一下，才会到达账户余额中。

(图源 ：pixabay)

以我的账户为例，当前这个池子的余额如下：

尽管你领或者不领，钱都在那里，不会少(随着文章/点赞收益等发放只会变多），但是感觉还是回到账户里更好一些，况且HIVE POWER越多，点赞收益越高，颇有些复利效应呢，所以收取收益还是很重要的。

收取收益使用的是claim_reward_balance，我定义个简单如下操作模板：

1
2
3
4
5
6

>op = ['claim_reward_balance',{
    'account': '',
    'reward_sbd': '',
    'reward_steem': '',
    'reward_vests': '',
  }]

程序中部分代码如下:

op[1]['account'] = "oflyhigh"
op[1]['reward_steem'] = "0.000 HIVE"
op[1]['reward_sbd'] = "0.000 HBD"
op[1]['reward_vests'] = "0.000001 VESTS"

然后追加操作并签名广播：

trx.append_op(op)
trx.sign_digest(wif)
ret = trx.broadcast()

成功广播的transaction大致长成这样：

1
2
3
4
5
6
7
8
9

{'expiration': '2020-04-26T02:43:43',
 'operations': [['claim_reward_balance',
                 {'account': 'oflyhigh',
                  'reward_sbd': '0.000 HBD',
                  'reward_steem': '0.000 HIVE',
                  'reward_vests': '0.000001 VESTS'}]],
 'ref_block_num': 5502,
 'ref_block_prefix': 4148586632,
 'signatures': ['20288535518661dd5ce376a812436a630d546d12b01333a64b0d9837155b4c102a0818f55cd99e72725889e1501d2251d24f55a11216eebadde9ffcee91943b537']}

https://hiveblocks.com/上可以查看成功的记录：

为什么是0 HP呢，因为我收取的太少，显示上被四舍五入了。

好了，这看起来并没有什么呀？为什么标题要叫：有趣的claim_reward_balance，标题党嘛？当然不是，你难道没有发现，其实收益是可以只收取部分的，是不是很好玩？

所有的都设置为零是否可以呢？我试了一下，出现如下提示：

(‘Assert Exception:reward_steem.amount > 0 || reward_sbd.amount > 0 || ‘
‘reward_vests.amount > 0: Must claim something.’)

就是可以少收，但是不难一点不收，那不是扯蛋呢嘛，哈哈。

那么收取全部收益是如何实现的呢？答案很简单，先读取账户信息，然后获取待收取的资产，然后一起收取就好了，思路就是这样了，实现也很简单，就不贴代码了。

怎么样，是不是很好玩？

This page is synchronized from the post: ‘每天进步一点点：有趣的claim_reward_balance’

前段时间发帖庆祝自己中签了两支新股，分别是锦和商业和沪硅产业，前者是上证，后者是科创版。

(图源 ：pixabay)

按着以往的经验，中签新股一般都至少赚一两万元（邮储银行除外），我的朋友还曾经一个签赚了十几万，那么我这两只股票保守估计也能赚两万吧，颇有些小期待。

沪硅产业上市当天表现的还不错，好像是涨了300%还是400%的，可惜一签只有500股，浮盈三四千，结果第二天就走了下坡路，我看形势不好，果断跑路。

尽管第三天又开始上涨，但是随后两天一直跌，算下来我也不算卖亏，到手赚了3500元左右，聊胜于无吧，还是继续期待1000股的锦和商业吧。

锦和商业上市第一天，不出意料的封板(40%好像），然后第二天又是涨停，我合计这要一连N个涨停赚10万不是梦嘛，结果第三天小涨一下就开始下行，吓得我果断清仓。

也还好我清仓了，之后这两天都再跌，周五甚至跌板，不过想想也是，虽然不知道这个锦和商业干些啥，但是疫情期间大凡商业都会受到影响吧，这个股又赚了3000多。

算下来，两只股票才赚了近7000，这还是我跑路较为及时的缘故，否则估计连5000也未必能赚上，距离我两万的目标有些远啊。

(图源 ：pixabay)

不过毕竟是赚钱了，看看我有可能退市跌掉几十万的航天通信已经其它赔了好多好多的中国核电等股票，发觉这俩新股还是很可爱的呢。

This page is synchronized from the post: ‘新股赚钱不再是一件容易的事’

想必用过API的都会有一点了解，那就是condenser_api，其实就是对其它各个API的封装，这样用户可以通过这个接口按一定的风格进行调用，可以忽略很多细节。

(图源 ：pixabay)

以我们最常用的API get_dynamic_global_properties为例，condenser_api其实是对其进行了如下封装：

看起来就是简单的映射，如果都是这样的，那么直接调用别的API也未尝不可。

但是等等，略复杂一点的情况来了，比如这个API：get_chain_properties，并没有同名的直接映射，而是其它API的部分返回结果：

这种情况，如果你的程序依赖于condenser_api，那么就要找出具体是哪个API的哪个返回部分，复杂度略增。

以上两种还算简单，请看官继续看，更加复杂的马上就来了，让我们来看看我们最熟悉的get_accounts，我们使用condenser_api调用get_accounts会返回很多信息，比如我的声望分啊，我的见证人投票啊，那么我们来看看代码如何实现的：

从上述代码中，我们不难看出condenser_api的get_accounts除了获取账户本身信息外，还追加了见证人票以及从其它插件获取了reputation信息，相当于多个API组合实现，这样我们如果用底层API直接实现，就复杂了好多。

尽管database_api中find_accounts提供了类似方法，但是并没有额外返回投的见证人票数据以及repution数据。

除此之外，在传递数据(输入)以及返回数据(输出)的格式方面，使用condenser_api以及直接使用其它APIdatabase_api等，也有很大的差异。

condenser_api参数一般是作为数组传入[]，而其它API的参数一般作为字典传入{}，还是就是涉及资产类型比较头大，我为了这事卡住了三两天，总算理清一点眉目了。

(图源 ：pixabay)

所以，真是试了其它API，才知道才知道condenser_api是多么便利啊。

This page is synchronized from the post: ‘每天进步一点点：condenser_api 与其它API(database_api)等的异同’

白居易有首诗中写过：人间四月芳菲尽，山寺桃花始盛开，要我说，诗人白居易所在的小区一定没找专门的园林/绿化设计人员规划过。你看这都四月下旬了，这些花还争芳斗艳呢。

有白色的梨花、粉红色的小桃红、淡紫色的诸葛菜、还有或是紫色或者白色的丁香花，还有封面图我叫不出名字的毛毛虫一样一串串小绿花。

走在小区里，闻着混杂在一起的淡淡花香，让人心旷神怡啊。

所以还是朱熹老先生的万紫千红总是春更适合一些呢：

胜日寻芳泗水滨，无边光景一时新。
等闲识得东风面，万紫千红总是春。

不过白居易要上山去看桃花，朱熹要去河边看美景，还是我最舒服，小区里转转就好，免去了跋涉之苦不说，还可以躲避新冠疫情。

This page is synchronized from the post: ‘万紫千红总是春’

昨天发帖讲了HIVE/STEEM的Batching Operations，测试用的是最简单的transfer操作，今天来弄一下claim_account，用于替换当前正在运行的beem脚本。

(图源 ：pixabay)

在HF20之前，创建账户是要花费一笔不菲的费用，这个费用参数由见证人们共同维持，好长一段时间这个费用都是3.000 HIVE/STEEM 。

这个费用看起来似乎并不多，但是要知道有段时间STEEM价格可是一度达到近50元一个，这对账户注册服务提供者来讲真是一笔不小的开支，当然了，这部分费用可以转嫁给用户，但是谁会舍得用150元注册个账户呢？

好在HF20的时候，随着RC(Resource Credits)系统的引入，这种情况得以改善。RC可以简单地理解成用户可用的资源，转账、发帖、点赞都耗费资源，并且资源按时间线性恢复，有效SP越多，可用资源越多。

HF20中还引进了用RC创建账户的概念，也就是说，不用耗费1分钱，只要RC足够，就可用创建账户，这样是不是很酷？

创建账户之前，我们要先领一张票，就好比我们想去看电影，要先买电影票一样，这个领票的过程就叫做：claim account，领完票之后我们可以先不创建账户等有需要的时候再创建(create_claimed_account)，这样可以充分利用RC资源。

claim_account 以及create_claimed_account分别对应下边两个操作，我们这篇文章先研究第一个：

根据上边的代码不难构造出claim_account对应的Operation

1
2
3
4
5

op = ['claim_account',{
    'fee': '',
    'creator': '',
    'extensions': []
  }]

然后，我们构造一个Transaction:

trx = Transaction(client)

然后，我们根据创建者信息来设置op:

op[1]['creator'] = "oflyhigh"
op[1]['fee'] = "0.000 HIVE"

因为是要批量操作，所以我将10个op循环加入到事务中：

for i in range(0,10): trx.append_op(op)

剩下的事情就简单了，签名并广播就可以了。

trx.derive_digest(chain_id)
trx.sign_digest(wif)
trx.broadcast()

广播出去的transaction大致长这样：

如果RC足够，就会申领成功：

一下子10个账户到手，是不是很过瘾？将其设置到定时任务(crontab)中，然后就不用管了。

有朋友可能会问，RC不够申领失败咋办？这个也不用担心，失败没啥影响的，当然也可以估算或者程序计算出个合理值，但是我觉得大可不必的，失败了就等攒够了再申领呗，当然前提是你申领的数值不能大于你RC全满时可申领的数值。

(说明：文内代码仅为逻辑表达，相关库正在完善中)

相关链接

• 每天进步一点点：再谈HIVE/STEEM的Batching Operations

This page is synchronized from the post: ‘每天进步一点点：批量claim_account (claim discounted account)’

18年7月份买NUC的时候，顺便配了一个罗技的G300s有线鼠标。我用过的罗技最舒服/最耐用的鼠标就是G1了，可惜G1已经停产，G300s带G，应该和G1一样禁用吧？

小鼠标外观我挺喜欢，又很贴合手型，操作非常灵敏，我还是非常满意的。想着之前用过罗技M705 无线激光鼠标，用过不久就坏掉了，这个有线的想必应该能坚持几年吧？

不过没想到的是，鼠标最近时不时地失灵，尤其是鼠标左键，按着左键拖拽或者截图的时候，左键经常突然无效，导致我拖拽文件拖错，或者截图截一半。

这段时间愈发严重，严重影响我使用电脑，就想着换个鼠标吧，反正没多少钱。去京东挑来挑去，觉得还是这个G300s最适合，想必我这个坏掉也是偶然事件吧。

正准备下单一个G300s，突然注意到商品服务中写着两年质保，然后进到订单里一看，我这个鼠标购买还不到两年，试着申请一下售后，发现有维修选项，就提交了一个售后申请。

其实我对维修没报多大期望，不过万一修好了，做个备用鼠标也好啊。结果申请提交没多久，京东那边就审核通过，但是不是我想象的维修，而是直接上门换新。

意不意外？惊不惊喜？

京东审核通过后，我订单里就出现了一条鼠标订单，不过价格是零元，快递小哥很快就把我的鼠标送上门并取走了旧鼠标。

秀个外包装：

连上测试了一下，非常灵敏非常好用：

京东上给售后一个好评：

小鼠标用着非常舒服，也非常顺手（毕竟用了一年半这个型号的），而且之前的故障一点都没有了。但愿这个能坚持久一些吧，争取用上两年以上。

有些好奇的是，如果这个再在两年内坏掉，我是不是可以继续换新啊？哈哈哈哈

This page is synchronized from the post: ‘鼠标零元购？免费换新！’