Loading [a11y]/accessibility-menu.js
access accident account accountrecovery address advertisement aes agricultural airdrop airplay alcohol alipay altcoin amazon android animal animals annual ansi anti-phishing anti-scam anti-spam anti-spamming ants apache apache2 api app appbase appdirs apple apr aptedit architecture arduino art ascii asksteem asset assets atom audio authentication autossl autumn aux avatar aws axel b1 backup balance bananapi bandwidth bank base58 base58check bat bbq bbs beauty beer beneficiaries bicycle bigdata binance bip birds birthday bitcny bitcoin bitshares bittrex blacklist blackmail ble block blockchain blocktrades blog bmi160 bom bomb bonus book boost bootstrap bot botany bp bsv bts buddha buddhism buetooth bug bugs build business busy buy byteorder bytes calculator calendar call car card carrier cartoon cat categories cd cdr certbot chair chance changes chat cheers child childhood children chinese christmas chrome cieme claim cleaning cleanplanet cleos click cn cn-chat cn-cleaners cn-diy cn-iot cn-news cn-programing cn-programming cn-prorgamming cn-stem cn-writing coca-cola code coffee coin cola cold collision color comment community community-governance computer condenser container content contest cooperation couplets cpanel cpanl cplusplus cpp cpu craigrant credit creditcard cron crontab crypto-news cryptocurrency css cterm culture curation curie curl custom-json cutehive cx cyberspace dapp data database ddns dead decathlon delegate delegation delete design device diary dictionary dig discord diseases disk diy dlive dns docker dog doge dogecoin dollar domain down downvote downvotes dpoll dream dreamland dreams drink drinks driver dtube dtube-test dyson ebs ec2 ecc ecdsa economic edison edit education egg eip email embed emoticon encode encoding encrypt environment eos eosdac eosio epicdice equality error esp8266 essay esteem etc eth ethtool evil excel exchange exchange-blast exchanges experience explode explorer eztk face fair faith fan favicon favorites fdisk feature fee feed festival filezilla fingerprint fire firefox fireworks firmware flag flower flowers follow followed follower followers followes following food footprint forecast forever format forum forward fossa fraud friend friends friendship fruit fruits fstab ftp funny future galaxy gamble gambling game gameboy gangster gateway gdex ghost gift github giveaway glyphicon gold google gpio gprs grape group gsm guide hack hacker happy harddisk hardfork hardware hash hdd hdparm headache header health hexdump hf20 hf21 hf22 hifi history hive hive-105017 hivedev hivemind hivesigner hivewatchers hmac home host hosting hosts hot hotpost house how-to howto htaccess html http https icbc ice icloud ico icon idea identicon idiom ikea image include index info insurance intel intelligence intercom interest introduceafriend introducemyself introduceyourself invest investigation investment io iot ip ipad ipfs iptables ipv6 it java jd jdenticon jp jquery js json jsonrpc jussi keep-alive keosd kernel key keyboard kfc ksitigarbha kungfu kyc lamp lan landscapes lantern laodr laodr-teahouse laptop law learning lesson libcurl library life lifestyle limit linksys linode linux liquor list literature live livelihood lm35 loan lock logic login lonely lotus love lvm lxc lxdcontainer mac macosx mail mainnet maintenance makefriends maker mana manabar map markdown market math matplotlib mausoleum md5sum meltdown memo memories memory message metro mfc microsoft mini mining minnowsupport mira mke2fs mkfs mobile modem momey money mongodb movie mpm-itk msp mssql multi-language multisig multisignature music mute mutex mysql mysqldump nat natue nature navigation net netplan network neusoft news newyear nginx night nightmare node nodejs nodeos nodes notebook notepad notification npm ns nuc ocd ocr odbc online opencv openledger openssh openssl opera opration option order otc outlet overload pal parameter paranormal parted partiko party passport password pay payout paypal peace pem pen permission pet phishing phone photo photofeed photograph photography photographynature photograpy php phptography pi piano pinyin pip piston plagiarism plan plant play plugin plus pm2 poem poetry points policies poloniex popular post posting power powershell powerup ppk ppoe pptp prayer prettytable price printer privacy probability program programing programming promo-steem promote promoted property proxy putty pwm pycurl pypi python python-bitshares python-ecdsa qq quantmod r radio rain rainbow ram random raspberrypi raspbian rc reading reblog recall reindexing replay reply report reputation requests research resteem review reward rewards rewrite rex richlist right rights risk rm robohash robot rocksdb root route router rpc rs232 rshares rubaiyat rules sailing sales sample samsung sbd sbds scam score screen script sct sct-cn se search secp256k1 secp256k1-py security sendgrid seo serialized server service setup sevendaybnwchallenge sftp sha256 shairport shared shell shopping show signal signature signup sing site skype sleep smartctl smartqq sms snow social socialmedia socks4 softfork softlayer software song sp spam spectre split sport sports spring sps spud sql ssd ssh sshd ssl stats stduy steem steem-help steem-python steem-stats steemalliance steemcommunity steemconnect steemd steemdata steemdev steemgg steemit steemit-dev steemitdev steemitphotochallenge steemitui steempowerupday steempy steemsql steemstem steemstemfeed steemthought steemtorch steemui steemvoter steenit stem stick stock stone stopthepowerdown stopthepowerdownm story string study stupas sudo suggestion supply surfer system systemd tags tags-cloud taobao tapos taxi tea tea-house team-cn teamwork technology telecom telegram telephone telgram temple testing testnet thanksgiving thinkpad thought thunderbird time timeago tips tool tools toys trade trafficking transaction transfer translation traval travel tree trending tron ttl tuling tulip tutorial ubuntu ufo ufw ui ultraedit unicode unix unor3 update upgrade uptick uptime upvote url urllib urllib3 usd user utc utf-8 utopian utopian-io uuid valuable varint vc vector vedio vegetables verification version vesting vi viewly vim virtualenv visa visualstudio vitamin vnc voice volume vote vpn vps vscode wakeonlan walk wallet wang war warning water wealth weather web webmaster website wechat welcome welfare wget whitelist whm whois wif wifi win10 windows wine wish witness witness-category witness-update witnesses wol wordpress work wps writing wrting www x x230 x61 xlm xml xxd xxx yoyow yy zb zip 中文标签 测试

如何计算内部市场当前参考价格

我们知道STEEM体系中,在处理STEEM和SBD之间转换时,使用的价格是median_history_price or feed price

比如说以下场景:

  • 在钱包中将SBD转化成STEEM
  • 系统发放文章奖励
  • 钱包中显示账户估值

使用这个价格的原因在于,这个价格相对而言比较稳定,不会大起大落,比较适合用于处理以上任务。

money-2724235_1280.jpg


(图源:pixabay)

但是,有时候,median_history_price内部市场的价格偏差比较大,比如我写作本文时

Feed price

Bid orders & Ask orders

不难看出,这两个价格偏差极大。
于是我们就有了, 发文时选择Power UP 100% 是否合算的问题?

为了方便自己和他人,我特意给微信公众号加了一个辅助大家判断的小功能。
老生常谈,是否100% Power UP? 公众号新功能!

以100SBD的作者奖励来比较,在当前价格下:

  • Power UP 100% 获得的奖励,市场价值约:113.036 SBD
  • 50%/50% 情况下获得的奖励, 市场价值约:106.518 SBD

我们据此给出判断:发文建议: Power Up 100%

问题所在

一切似乎都很正常,直到有一次我测试时发现,偶尔出现了 Market Price: 1.000 或者 Market Price: 2.000这样的数据。

在这两天市场价格一直在1.2 - 1.6之前徘徊的情况下,无论是1.000的极低价格还是2.000的极高价格都是不合理的。莫非是我抓的数据有错?看了一下内部市场的成交历史,竟然发现类似这样的数据:

我不清楚内部市场交易撮合的规则,但是既然这样的交易数据实实在在的存在,那么由此可见并非是我的错。

但是,无论是谁的错,这样毛刺数据,都是不可接受的,一旦出现这样的毛刺数据,我的辅助判断就可能出现极大的错误

如何解决

找出问题,不是我们的目的。找出并解决问题,才是我们要做的。

既然毛刺数据会影响我们的判断,那么我们就要想办法消除毛刺,用我做平衡车姿态分析啥的时候常用的术语叫做滤波

我们之前采取的方法是,get_ticker,从中我们可以获得:
最高买单价格,最低卖单价格,以及最后一笔成交价格等

我们之前辅助判断功能中采取的就是Last price,因为最后一笔交易可能是成交量极小的毛刺交易,所以偶尔会导致这个价格极度失真。

那么都有哪些方式可以解决这个问题呢? 我大致想到如下方法:

  • (Highest bid+Lowest ask)/2 的方式
  • 多获取一些Trade History,并用成交数据中的SBD/STEEM来判断价格
  • 获取N档order book,用其中的价格或数量来计算参考价格

对于第一种方式,由于steem内部市场不是很活跃,有时候还好,但有时候Highest bid以及Lowest ask差额巨大,单单取中间值,不是很合理。

对于第二种方式,同样steem内部市场不是很活跃,可能之前一笔成交订单已经过去了好长时间,这样取N比订单,计算参考价格,可能数据会比较陈旧。

第三种方式,相对比较合理,通过当前的买单和卖单来计算出参考价格,无疑是相对比较合理的。

以获取五档order book为例,我们会得到类似如下数据:

我们有几种选择

  • 将所有price数据平均
  • 对买单的’base’与’quote’求和并计算出买单价格,同理计算出卖单价格,取平均值
  • 对所有买单以及卖单的’base’与’quote’求和,直接计算出价格
  • 对所有卖单以及卖单的sbd以及 steem求和,计算出价格

通过测试,发现在不同场景下,以上几种方案计算出去的数据,差额极大。
以上述数据为例,后三种方案算出的价格分别为:

  • 1.4533425349381701
  • 1.4611225385999593
  • 1.4621550046265275

可见,计算出来的价格更倾向于反应买卖双方的期望价格。当市场价格趋于平稳时,这个三个计算出来的价格均在Highest bid与Lowest ask之间,差异不大。当市场暴涨或者暴跌时,这个三个计算出来的价格会有严重的倾向性,甚至会超出Highest bid与Lowest ask的范围。超出Highest bid与Lowest ask的范围是否代表不合理,也不尽然。但是上述计算出的数据显然不合理。或许我们根据卖单与买单的量,以及历史成交价格,据此判断出上涨或者下跌的趋势,进而对上述结果进行修正,才会得出趋于合理的数据吧。

再回头看,我们不过要一个市场价格的参考价格,用于判断是否适合Power UP 100%, 有必要搞这么复杂吗?心累!

那就随便用一种方式好了,毕竟都差不多嘛。以后请叫我差不多先生。😭


This page is synchronized from the post: 如何计算内部市场当前参考价格

Followers 突破3000大关,你想随时查看你的Followers数量吗?公众号增加新的小功能!

距离Follower突破1000大关已经过去了两个多月,之前庆祝的帖子仿佛就是昨天刚刚发的一样

前两天,偶尔看到Follower人数正好突破3000大关,遂截屏记录一下

这次不搞什么庆祝了,也没啥值得庆祝的。

只是想告诉大家,微信公众号增加了个新功能:显示Followers和Following 数量。


如何查询

想知道 自己或别人的FollowersFollowing 数量?
关注微信公众号: steemit

输入@steemid 即可查询
(将steemid替换成你自己的账户哦,比如oflyhigh

例如:
@oflyhigh

再来看看刘美女的
@deanliu

可恶😡,竟然又比我多!😡

再来看看甜心妹妹的
@sweetsssj

好有魅力 😍 ,好羡慕呀 😍

指令整合

大家或许注意到,我将Followers和Following 数量查询,放在最基本的用户查询里,这样大家就无需记忆以及多输入类似?follow这样的子命令了。

之后对指令进行规范和整合,是我的一个目标,让公众号更便于大家使用。

Follower数量排名

3045 个 Follower 大致能排到什么名次呢?
对此我感到很好奇,随手用 steemdata 查询了一下
print(db['Accounts'].find({'followers_count': {'$gt': 3045}}).count())

居然还没进入前200名,任重道远啊。

顺便说一下:
furion’s new toy: A full RPC steemd node for SteemData
@furion 为SteemData 专门买了个服务器做Full RPC steemd节点,以后 steemdata 将会更加稳定、快速和可靠。

将followers数量的排名集成到公众号,似乎是个不错的主意。不过有点困难😭


公众号添加方法

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

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

欢迎大家多提宝贵意见啊。


This page is synchronized from the post: Followers 突破3000大关,你想随时查看你的Followers数量吗?公众号增加新的小功能!

Python 随机选取元素的一些方法以及概率问题

之前有一个任务,其中一个步骤是从名单中随机选择部分用户去执行一些操作,而且要保证用户被选中的概率大致相等。

cube-442544_1280.jpg


(图源:pixabay)

random.randint()

我对Python不是很熟,所以我首先想到的是用random生成列表长度范围内的随机数,然后再用下标的方式去读取列表。

为了记录操作次数以比较列表元素被选中的概率,我将列表改成字典的形式,以便于记录操作次数。

代码如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import time
import random
from pprint import pprint

dict= {'a':0, 'b':0, 'c':0, 'd':0}
list = list(dict.keys())

pprint(dict)
pprint(list)

start = time.clock()
for i in range(0, 400000):
index = random.randint(0, 3)
dict[list[index]]+=1
pprint(dict)
print("CPU Time:", time.clock() - start)
执行结果如下:


可以看到元素被选中的概率基本相同,可以满足我们的需求。

random.choice()

上述代码虽然能实现功能,但是总感觉不是很优雅,经过查手册,发现了random.choice()这个函数,来试试这个吧。

代码如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import time
import random
from pprint import pprint

dict= {'a':0, 'b':0, 'c':0, 'd':0}
list = list(dict.keys())

pprint(dict)
pprint(list)

start = time.clock()
for i in range(0, 400000):
choice = random.choice(list)
dict[choice]+= 1
pprint(dict)
print("CPU Time:", time.clock() - start)
执行结果结果如下:


可以看出元素被选中的概率基本相同,但是就性能而言,比random.randint()方法要好很多.

random.sample()

有发现random模块居然还有个sample函数,看起来专门为取样设计的啊

代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import time
import random
from pprint import pprint

dict= {'a':0, 'b':0, 'c':0, 'd':0}
list = list(dict.keys())

pprint(dict)
pprint(list)

start = time.clock()
for i in range(0, 400000):
samples = random.sample(list, 1)
dict[samples[0]]+= 1
pprint(dict)
print("CPU Time:", time.clock() - start)

执行结果结果如下:

OMG, 尽管元素被选中的概率基本相同,但这性能哭了。(当然,可能耗费在列表元素读取上,具体是啥,懒得评估了),看来名字好看也不一定中用啦。

random.choices()

咦,又发现一个崭新的函数,之所以说它是崭新的,是因为这是在3.6版本中新增的函数 New in version 3.6

如果你还在运行3.6以下版本,对不起,这个你用不了。

代码如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import time
import random
from pprint import pprint

dict= {'a':0, 'b':0, 'c':0, 'd':0}
list = list(dict.keys())

pprint(dict)
pprint(list)

start = time.clock()
for i in range(0, 400000):
choices = random.choices(list, k=1)
dict[choices[0]]+= 1
pprint(dict)
print("CPU Time:", time.clock() - start)
执行结果结果如下:

哇,你看看人家,要结果有结果,要颜值有颜值,要性能有性能,简直完美的不要不要的。

更进一步

从上边的结果,不能看出,选取结果概率都是均匀分布的,符合我们的要求。

但是选择一个元素的时候, random.choice()函数性能最好

那么我们为何还要大力推崇random.choices()呢?答案有两点:

  • 支持选择多个元素
  • 支持设置不同元素权重
支持选择多个元素

代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import time
import random
from pprint import pprint

dict= {'a':0, 'b':0, 'c':0, 'd':0}
list = list(dict.keys())

pprint(dict)
pprint(list)

start = time.clock()
for i in range(0, 400000):
choices = random.choices(list, k=2)
dict[choices[0]]+= 1
dict[choices[1]]+= 1
pprint(dict)
print("CPU Time:", time.clock() - start)

结果:

看吧,选择了2倍量的元素,耗时只增加了一丁点。

支持设置不同元素权重

如果想让不同的元素,被选取的概率不同,我之前的做法是这样的
['a', 'b', 'c', 'd']改成['a', 'a', 'b', 'c', 'd'],是不是看起来傻,我觉得也是!

正确是姿势是用random.choices()并设置权重/weights 的方法

代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import time
import random
from pprint import pprint

dict= {'a':0, 'b':0, 'c':0, 'd':0}
list = list(dict.keys())

pprint(dict)
pprint(list)

start = time.clock()
for i in range(0, 400000):
choices = random.choices(list, [2, 2, 1, 3], k=2)
dict[choices[0]]+= 1
dict[choices[1]]+= 1
pprint(dict)
print("CPU Time:", time.clock() - start)

结果:

完美的不要不要的,有没有?

听说用cum_weights参数,效率会更高,比如改成这样:
choices = random.choices(list, cum_weights=[2, 4, 5, 8], k=2)
试了一下,果然性能提升了不少,不过我决定坚决弃用,为何? 不直观呗!

总结 / Summaries

通过学习,我们知道在Python 中,可以用下列函数随机选取元素

  • random.randint()
  • random.choice()
  • random.sample()
  • random.choices()

通过测试,我们发现最后一个函数可以用来选取多个元素,并且支持设置权重,性能也是极佳。以后就用它啦。


之所以做这个测试,是因为我的一段程序中原本用的random.sample(),但是选中的元素明显概率不一样,后来我改写了程序其它部分,并改用random.choices(),概率分布效果极佳。

但是我觉得random.sample()不应该存在概率问题啊,于是写了上述几段程序测试了一下,发现并不存在所谓概率的问题。看来我冤枉random.sample()了,是我其它代码导致的问题, 但是发现random.choices()果然是最佳选择


This page is synchronized from the post: Python 随机选取元素的一些方法以及概率问题

墙外的枣

我家所在单元楼一楼二号院子里有一颗大枣树,结的枣是又大又甜,现在正是收获的季节。

jujube-940598_1280.jpg

(图源:pixabay)

偶尔我从楼下经过时,总顺手拽一两颗大枣,边走边吃。先澄清一下,我这可不是偷鸡摸狗、顺手牵羊之类的行为,而是经过枣树主人允许的。枣树的主人,原本是我家楼上的阿姨,去年不小心崴了脚,虽然说休息一两个月以后已经没什么问题了,但是家里儿子孝顺,觉得老人住的楼层高,还是不太方便,恰巧一楼的住户房子亦欲出售,便买了下来。

从楼上邻居,变成楼上和一楼的双重邻居,我们不是一般的熟,那是熟透了。阿姨不止一次和我说,什么枣啊,院子里的水果和蔬菜想吃啥自己随便摘随便挖,千万不要客气。但是我还没无耻到自己带个小铲子去人家院子里挖菜的地步,但是摘几枚大枣,我认为不算啥大问题。

话说有天我从外边回来,有两个30左右的女子正在一楼花园的墙外扯着枣树摘枣吃,吃的好不欢乐。看到我回来,而且明显是这个单元的,她们有些窘迫。其中一个略微年轻的女子有些羞愧的对我说:“我们摘几个枣吃,这枣太甜了”。看到她们窘迫的样子,我觉得很有趣,便和他们开了个玩笑,我说:“摘吧,吃吧,反正枣树也不是我们家的”。两个女子闻言十分诧异,不知是因为她们觉得她们白惭愧了,还是因为对我面对她们摘枣行为无动于衷而感到愤怒,年轻女子沉默几秒后,大声对我喊,“你太过分了,怎么可以这样?!”原来面对摘枣者无动于衷,竟然会被指责,我感到很无语,我对她们说,“好吧,不要摘枣了”。两女子落荒而逃。

前几日从外边归来,恰逢阿姨在院子里忙碌,看到我之后,给我弄了一大堆蔬菜,并且给我找来一个凳子,让我自己多摘一些枣。我和阿姨聊起这个趣事。阿姨和我说,别人愿意摘枣就随便摘吧,她家儿子告诉她,如果自己吃枣就在院子里摘,不要去摘墙外边的。因为枣很多,吃都吃不了,伸到墙外的枝杈上的枣,就让来往的路人吃吧。因为路人们大多不会去院子里摘枣吃,而外边的枝杈上的,顺路拽几个还是很方便的。

keyboard-621830_1280.jpg


(图源:pixabay)

听了阿姨转述的她家儿子的话,我颇有些感慨。

小区里的一些邻居,将院子外物业栽植的观赏果树都视为己有,不许任何人采摘。尽管我不赞成采摘观赏果树上的果子,但是因为一两枚其实并不属于自己的家的果树上的果子而和别人吵架的事情,我也是相当看不惯的。而像阿姨儿子这样的,将本属于自己家的果子让路人随便采摘,又有几人能做到呢?

从其它邻居的口中,我曾得知,阿姨家的儿子是做珠宝生意的,做的规模很大很成功。以前,我总认为,成功有时候仅仅是运气,但从墙外的枣这个事上,我仿佛抓到一些什么,或许成功不仅仅都是运气和偶然吧。

——————

哦,对了,枣树是一楼二号的,不是一楼一号崔奶奶家的。


This page is synchronized from the post: 墙外的枣

老生常谈,是否100% Power UP? 公众号新功能!

之前我写过几篇文章,关于发文时,是否应该选择100% Power UP.

我看了一下日期,分别是4个月前,以及两个月前,现在距离上一篇文章又过了两个月,事情又有何新变化呢?

老实说,别说过两个月,就是过两周,哪怕是过两天,两天前我的想法为什么是这样?我都很难回想起。没办法,上年纪了,很难和年轻时一样记忆力极佳。


好在我在之前两篇文章的文末都有结论,比如这个:

一个简单的判断原则就是:
  • 内部核算价格 > 市场价格时: 选择 Default(50%/50%),这个肯定没错
  • 内部核算价格 < 市场价格时: 比例悬殊时选择Power Up 100%,否则视情况操作。

至于这个结论咋来的,我就不去回忆了。
但是这个结论对普通用户,甚至对我而言,都有些鸡肋

  • 我要牢记以上结论
  • 我要去steemd看内部核算价格(current_median_history_price)
  • 我还要去内部市场,看市场交易价格
  • 然后再对两者进行比较,再得出结论

很累,是不是?我也觉得是!

于是我就想,能不能在公众号中添加一项新功能,建议用户发文时选择Power Up 100%或者Default(50%/50%),所以公众号的新功能来了。

如何判断发帖时选择哪个选项?

关注微信公众号: steemit

输入: ?pu?powerup

例如:
?pu

以下是我测试时返回的结果

为了给小伙伴们一个直观的印象,我假设一篇文章 100SBD 作者收入,在当前行情下,不同选择的估算价格以及市场价格。

当市场价格以及中间价(内部核算价格)差额达到5%比重时,我会给出相应的建议。

当前差额实在太小(没有达到5%的阈值),考虑市场价格波动,其实选择啥差异不大啦。

模拟操作(非真实结果)


为了看起来更直观,我在程序中做了一下模拟,假设市场价格是1.5 SBD/STEEM, 公众号给出的结论还算靠谱😀

除了,给出发文选项建议以来,你还可以用来查看STEEM的市场价格以及中间价(内部核算价格)。

注意: 由于市场价格波动,公众号给出的操作建议仅供参考。


公众号添加方法

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

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

欢迎大家多提宝贵意见啊。


This page is synchronized from the post: 老生常谈,是否100% Power UP? 公众号新功能!

饮鸩止渴

potion-2217630_1280.jpg

(图源:pixabay)

从小到大,我都比较喜欢喝饮料。小时候喝的是2毛钱一瓶的老汽水,味道和雪碧类似,玻璃瓶子铁瓶盖。

那时候家附近有个汽水厂,我经常和父亲去汽水厂直接成箱买汽水。一箱24瓶,算批发价,我已然记不清楚是多少钱,但比从小卖铺一瓶一瓶买要便宜很多。我特别喜欢汽水厂车间内空气中香甜的味道,几十年过去,记忆尤深。

记不得什么时候开始,饮料市场渐渐被易拉罐装或者塑料瓶包装的各种饮料所充斥,汽水厂不知何时倒闭了。我时常喝的饮料也渐渐的变成了荔枝味的珍珍、康师傅的冰红茶、冰绿茶、王老吉、咖啡,以及雪碧及可乐。

以前工作的时候,公司有提供免费咖啡,我和几个好友,每到休息的间隙,就必喝一杯咖啡,顺便在从自动售货机中买一点小食品,边吃边聊,好不惬意。后来,大家普遍反应,喝了公司的咖啡之后,哪怕只有一杯,也整宿整宿的睡不着觉,第二天毫无精神,只好靠咖啡提神。这样下去,终不是办法,于是我们变集体戒了咖啡。

但是休息的间隙喝饮料吃零食的习惯却很难一下子戒掉,于是我们每到休息时间就集体光顾公司院内的小超市,基本人手一瓶可乐一根烤肠。虽然喝可乐多了,也会导致晚上失眠,但是不会很严重,所以大家都不以为意。我想或许是那个时候起,我便产生了对可乐的依赖吧。

有时候别人谈到毒瘾、烟瘾,我总是颇不以为然,一个人如果主观上想控制自己,那有什么控制不了的呢?如果控制不了,那一定是自制力不够。结果换到可乐这件事情上,我发现,有时候自己真的很难控制自己。这不,刚刚一瓶可乐灌下去,我才觉得我又有些活力了,否则已经昏昏欲睡了。

相信大家都知道碳酸饮料的危害,作为一个长期饮用可乐一类饮品的人,我更是被无数或专业或业余的人告诫,珍爱生命,远离碳酸饮料。对与碳酸饮料的危害,我更是深有体会,因为长期引用碳酸饮料,已经给身体上造成种种不适和伤害。可是我想说的是,我真的控制不住我自己呀。

每当我拿起可乐瓶,我脑海中总是情不自禁的冒出一个成语: 饮鸩止渴,或许这个成语用在此处,不是很恰当,但是无疑是非常形象的了。我总设想,如果有一天我非常非常渴,一瓶美味又解渴的毒酒放我面前,我是喝还是喝还是喝呢?我没有给出别的选项,我相信,我一定会毫不犹豫去喝的。

那么生活中又有多少这样的情况呢,当诱惑摆在你的面前,你是否会顾及有什么严重的后果呢?

饮鸩止渴、杀鸡取卵、涸泽而渔、急功近利大概是我们每天都在做的事情吧。


This page is synchronized from the post: 饮鸩止渴

Your browser is out-of-date!

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

×