五一出门玩了吗？
cn
5 minutes read (About 763 words)

五一出门玩了吗？

以往每逢五一长假，都是出门游玩的日子，要么去别的城市远游，要么也要在所在城市的公园转上一圈。到也不是因为五一假日的特殊意义，而是五一草长莺飞、花红柳绿，气温又不冷不热，特别适合出门游玩。

image.png

而今年的五一则略有不同，因为疫情的缘故，远游肯定是不能远游了。孩子的学校也发了通知，禁止学生五一期间离开所在的城市。话说，即便学校不禁止，也不敢出远门啊。

原本打算家附近的公园转上一圈，看看风景、拍拍花花草草，现在正是郁金香盛开的时节，去看看郁金香貌似也不错。

可是想想估计会有很多人去公园，人一多，就会感觉不那么安全，所以赶上五一第一天去公园，貌似也不是什么好选择。

难道就这么宅在家里吗？思前想后，我断然决定开车去10公里以外的河边，那边地处荒郊了，想必去的人应该不多，去河边转转，顺便也让好久没动的汽车活动一下以免生锈，一举多得。

然后车一开出小区我就后悔了，一路上都是堵啊堵啊，车辆比平时多了好几倍。想着出了市区也许会好一些，就这样一路堵一路前行，总算开到河边景观路了。

到了景观路我才真正的体会到什么叫做堵车，或许因为疫情憋了几个月的人都选择在今天出来放风，河边景观路两边的车位上都停满了车不说，路上也堵满了车。

从车辆的间隙往外看去，不少人在河边支起了帐篷，而这个区域距离风景最美的区域还差好远呢，估计他们知道到了里边也未必有地方停车，也未必有地方支帐篷，所以随便选择个地方安营扎寨，还是明智的。

image.png

因为又是堵车又没有地方停车，最终经过一个岔道口的时候，我果断选择从景观路里开出来，打道回府了，还好回去的路上还是非常顺畅的。

虽然年年五一出行，年年堵车，但是今年在这么偏僻的地方也会堵成这样，还是出乎了我的意料，看来真的不能选择节假日出行啊。

This page is synchronized from the post: ‘五一出门玩了吗？’

每天进步一点点：Python 中int64_t的最大值？
cn
8 minutes read (About 1140 words)

每天进步一点点：Python 中int64_t的最大值？

在测试HIVE API的时候，发现要想使其中的一个API按着预想中的情况正确工作，需要传入int64_t类型的最大值，你要说什么8位、16位的最大值，我也许张口就来，可以64位我的大脑也处理不过来啊。


(图源 ：pixabay)

基本原理

HIVE代码中直接用的是std::numeric_limits< int64_t >::max()，我也没法直接引用呀。

那64位最大值是多少呢？我们知道，计算机中的数都是以二进制形式表示，所谓多少位就是多少个0和1，比如64位就是64个0、1组合。

而有符号数最高位用来表示符号位，符号位为0表示正数，符号位为1表示负数，其它数位用补码的形式表示：

正数的补码就是其二进制表示，与原码相同；负数的补码就是除符号位外的所有位取反后加1。

代码计算

知道了这些，那么求不同位数的数的最大正值就很容易了，比如我可以根据上述信息写出如下函数：

image.png

其实就是计算二进制函数的10进制值，因为正数补码和源码相同，那么int64_t最大值其实就是63个1组成的二进制数。

我们来测试并计算一下：

image.png

看来9223372036854775807就是我们想要的结果。

使用ctypes

为了计算一个数值，写了一堆垃圾代码，我觉得我有点傻，那是不是有更简便的方法呢？我找到一种也许不算是简便方法的方法，那就是使用ctypes

ctypes能做很多事情，不过我想让它做的就是在python中使用c语言的类型，比如int64，而我们根据上述分析不难得出，int64最大值就是uint64最大值减1再除以2。

所以我们可以利用如下代码计算int64的最大值：

image.png

对比不难发现，和我们之前计算的结果完全一致。

移位计算

其实还有一种更简单的方法就是移位计算法，int64的最大值是63个1组成的2进制数，那么怎么能得到这个二进制数呢？

我们知道1个1组成的2进制数，是可以通过二进制数10减去二进制数1来获取，那么63个1组成的二进制数，其实也可以用10000(63个零)组成的64位二进制数减1来获取，而1后边63个零，就是把1左移了63位。

代码也超级简单：

image.png

到底用啥？

尽管我制造出三种超级复杂的计算方法，但是我觉得很傻，不就是一个数嘛，直接引用9223372036854775807就好了呗？

可是在代码中引用这个数我又觉得很不优雅，哪怕我可以做类似如下定义：

MAX_INT64_VALUE = 9223372036854775807

我估计以后我会忍不住问自己，这个9223372036854775807哪里来的呢？

想了好久之后突然想起来，我是不是太傻了，十六进制数就是二进制数的便于阅读的表示嘛，那么INT64的最大值，那不就是0x7FFFFFFFFFFFFFFF嘛(最高位不等于1)，所以代码中直接用以下定义即可：

MAX_INT64_VALUE = 0x7FFFFFFFFFFFFFFF

既含义明确，又不会有疑问，看起来又很优雅。

补充

网上还有代码计算int类型最大值，使用sys.max_size，在64位主机上代码可以得出正确的值。

但是在32位系统上，算出的值就是int32_t的最大值了。

image.png

所以在我们的程序中使用这种对系统依赖程度高的代码，是行不通的。

相关链接

This page is synchronized from the post: ‘每天进步一点点：Python 中int64_t的最大值？’

乌龙单
cn
5 minutes read (About 685 words)

乌龙单

大概是前晚半夜12点左右，看到微信群里他们说HBD爆拉好多倍，我打开一直挂着的bittrex BTC-HBD的交易对页面，一看走势平平根本没动嘛。


(图源 ：pixabay)

结果看群里别人发来的截图，我才知道不是BTC-HBD的交易对的走势没动，而是因为网络链接的问题(墙)，我的页面数据没有刷新而言。

等我费了半天劲刷新之后，HBD的价格已经回复的正常，只能看高高耸立的绿线(暴涨)而徒呼奈何！不禁感慨，墙害死人啊。

既然HBD价格已经恢复了正常，那就不去想了，我还是看看HIVE吧，虽然HIVE比起高点也跌了下来，但是终究会有涨上去的时候，之前在山顶上买了一些，似乎可以挂在比山顶更高的位置等成交。

这两笔是在从山顶上跌下来之后买入的：

image.png

那我就挂0.0001上卖出吧，要是成交，也赚不少呢，这样一想美滋滋，结果因为网速以及自己不够清醒的缘故，把卖单挂成了买单，然后迅速地成交了，我哭：

image.png

这样就变成了我连续买入了三笔，心累，也不打算挂单去卖了，等涨到$1以后再说吧。

第二天的时候，朋友恭喜我，说HBD暴涨，我一定赚了不少，我都不知道咋回复才好。

然后突然想，HBD暴涨，是不是因为有人也挂了乌龙单呢？本来打算卖出，然后挂成了买入，和我操作手法相同，只不过人家资金量比较大，所以拉得比较高。

其实乌龙单的事情，以前也没少干过，买卖方向搞反是一种情况，还有一种情况是本来打算买A资产，结果不小心买了B资产。


(图源 ：pixabay)

不过虽然闹过不少乌龙，但是有时候反而因乌龙单获利过，要是按着自己正常的思路操作，反而会赔钱。

所以愈发地相信，赚钱全是凭运气，倒是有时候赔钱，是需要实力的。

This page is synchronized from the post: ‘乌龙单’

每天进步一点点：修改VIM中注释的颜色
cn
6 minutes read (About 924 words)

每天进步一点点：修改VIM中注释的颜色

最近一直用VIM编辑器写Python代码，发现注释的默认颜色，真的让人很是头疼，我要把脑袋贴近屏幕，瞪大双眼，仔细分辨，才能看清楚注释都写了些什么。


(图源 ：pixabay)

注释颜色

来，我贴一个截图，大家来感受一下：

image.png

就问你服不服？如果你说这很容易看清楚啊，那我就甘拜下风，只能承认自己眼神不好了。

无论是注释颜色设置问题，还是眼神本身问题，总之给我带来很多麻烦，以前用的频度不高，也就无所谓，但是天天对着这样的注释，或看或写，真的受不了。

修改配色

于是想着能不能改变一下注释的默认颜色呢？网上查了一下，VIM的配色都是可以修改的，而改动注释颜色用如下语句即可：

highlight Comment ctermbg=Blue ctermfg=White

其中Comment表示注释，cterm表示color term，bg以及fg分别代表前景色背景色。

我们在~./vimrc中加入上述语句试试看看：

image.png

吐血，有种玩Arduino时用1602液晶屏的感觉，感觉这颜色一点都不舒服。一般情况下，前景色和背景色分别可以设置为16种颜色，具体颜色设置表可以通过如下指令查询：

:help ctermbg

返回如下(默认情况下，是NR-8(8-color terminals)：

image.png

256色

既然默认是8色终端，那么有没有可能让终端颜色更加丰富多彩呢？比如这个列表列出的N多颜色：

image.png

或者一些基本颜色：

image.png

尽管看着挺花哨，其实就是RGB配色。

我研究了一下，要在VIM中用上256色也挺简单，在~./vimrc设置如下语句就可以了：

set t_Co=256

我们再来试一下配置注释颜色(hi等同于highlight)，随便选个艳丽的颜色：

hi comment ctermbg=165 ctermfg=0

噗，果然够艳丽：

image.png

方案一

选来选去，都太花哨了，还是选个普通的配色吧。

hi comment ctermbg=3 ctermfg=0

皇家才能用的尊贵的黄色，亮瞎我的眼睛吧！

image.png

其实我的目的就是看清楚注释，现在这样足够我看清楚了，如此足矣。

方案二

用方案一一段时间后，发现如下指令也能完美解决我的问题：

set background=dark

看起来有些刺眼，不过也还好啦：

image.png

到底选择方案一还是方案二呢？头疼。

相关链接

This page is synchronized from the post: ‘每天进步一点点：修改VIM中注释的颜色’

Amazon EC2动态扩展挂载磁盘(Volume)空间
cn
7 minutes read (About 1033 words)

Amazon EC2动态扩展挂载磁盘(Volume)空间

我有一个Amazon的EC2实例最近磁盘空间告急，眼看着就要满员了，这可让我急坏了。不过想着Amazon这么先进的云设施，一定会支持动态扩容吧，进面板看了一下，还真就支持，那就来实际操作一下喽。


(图源 ：pixabay)

准备工作

在这之前我们先在面板里看看我挂载的云盘(Volume)类型和大小：

image.png

除了在面板里查看外，在系统中我用sudo fdisk -l也看了一下

image.png

没啥其它额外的工作要做，不过我还是顺便升级了一下系统软件😀。

调整卷空间

接下来我们就可以在面板中直接调整卷大小了，其实很是简单粗暴。

直接选中卷，然后在菜单中选择Modify Volume

image.png

点进去后会出现类似如下界面：

image.png

直接指定新的空间大小(IOPS也会随之动态增加)

image.png

选择Modify按钮，会出现如下提示：

image.png

其中最主要的信息莫过于调整卷大小后，还要扩展操作系统的文件系统：

You may need to extend the OS file system on the volume to use any newly-allocated space.

按下Yes按钮确认，瞬间调整成功。

image.png

拓展分区大小

调整成功后，我们可以在面板中检查卷大小：

image.png

同样可以在操作系统中检查，不过你会发现虽然卷(磁盘)大小改变了，但是分区大小并没有改变

image.png

要让新增的空间可以被使用，我们首先需要扩展分区大小，确定分区后，执行如下命令即可：

sudo growpart /dev/nvme0n1 1

其中/dev/nvme0n1为设备(磁盘/卷)，1为分区编号(第一个分区)，执行命令后会出现如下提示：

CHANGED: partition=1 start=2048 old: size=2516580319 end=2516582367 new: size=3145725919,end=3145727967

现在再来检查分区空间，发现分区空间已经成功变大了：

image.png

调整文件系统

使用如下命令查看我们的文件系统：

df -lh

我们会发现尽管我们扩展的磁盘/卷空间，调整了分区大小，但是对应的文件系统显示的空间还是原来那么大。

为了让文件系统也跟上变化，我们需要执行如下命令：

sudo resize2fs /dev/nvme0n1p1

执行上述命令后会出现类似如下提示，代表我们调整成功：

image.png

再使用df -lh查看文件系统，就会发现对应的空间已经调整啦，至此扩容成功！

总结

尽管又是截图又是文字写了一大篇，不过其实概况起来就是如下几个步骤：

  • 面板中调整对应Volume的空间大小
  • 系统中拓展分区大小(growpart)
  • 系统中调整文件系统(resize2fs)

不过简单归简单，操作的时候一定要谨慎，尤其是重要数据的情况，一旦不小心搞崩溃，那就欲哭无泪了。

相关链接

This page is synchronized from the post: ‘Amazon EC2动态扩展挂载磁盘(Volume)空间’

每天进步一点点：发布喂价(feed_publish)
cn
5 minutes read (About 805 words)

每天进步一点点：发布喂价(feed_publish)

喂价(feed price)是保证HIVE系统正常运作的基础之一，喂价由见证人根据HIVE的市场价来获取并提交给系统，这个提交的过程就是发布喂价(feed_publish)。


(图源 ：pixabay)

系统会取3.5日内见证人喂价的中值作为系统喂价，注意是中值而不是平均值，更多细节我们就不在这篇文章中讲述了，这篇文章着重介绍发布喂价这个操作。

作为见证人，以往我都是使用 @furion的conductor应用来发布喂价的，这是一个基于steem-python的应用，读取很多交易所的价格，计算出实际价格并发布。但是HIVE系统上，conductor应该没法工作了，之前我都是使用命令行钱包发布喂价，很是不及时，所以使用程序发布很有必要。

发布喂价

发布喂价的Operation结构大致如下：

1
2
3
4
5
6
op = ['feed_publish',{
    'publisher': '',
    'exchange_rate': {
          'base': '',
          'quote': ''}
    }]

其中publisher是发布者，exchange_rate(兑换率)就是喂价了。关于quote和base我总是搞晕，以前总结过的结论再拿出来：

  • Base: 基础资产，用于计价的资产
  • Quote: 买卖资产，就是要买卖的资产

尽管quote和base可以传入任意数值的资产对，比如说1000个HIVE的价格为418HBD，但是为了便于系统处理，还是传入诸如1个HIVE价值0.480HBD的资产对比较好。

因为我使用的是network_broadcast_api来广播交易，所以需要将资产处理成network_broadcast_api识别的方式，所以对上述op结构赋值如下：

op[1]['publisher'] = publisher
op[1]['exchange_rate']['base'] = HIVE_ASSET(base)
op[1]['exchange_rate']['quote'] = HIVE_ASSET(quote)

其中quote为1.000 HIVE，base为当前市场行情，我撰写文章时为0.418 HBD。

将操作追加至事务(transaction)并用active私钥签名广播：

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

最终处理后并广播出去的事务类似如下：

image.png

在https://hiveblocks.com/ 上查看，可以看到我的喂价已经成功发布：

image.png

其它测试

如果使用Posting私钥来发布喂价会是怎样一种情况呢？我测试一下，返回结果如下:

‘missing required active authority:Missing Active Authority oflyhigh’

如果一个并不是见证人的用户，尝试发布喂价，会是什么情况呢？我尝试用@oflyhigh.test 这个用户的active key发布喂价，系统给了我如下提示：

‘unknown key:unknown key: ‘

补充

尽管已经可以使用程序发布喂价，但是实际上并不比命令行钱包方便多少。

需要更进一步完善，读取已上币交易所的行情，根据行情动态发布喂价，这样才算是完善的程序。

This page is synchronized from the post: ‘每天进步一点点：发布喂价(feed_publish)’

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×