哈哈，起了个很有意境的标题，不过其实这事一点也不美，之所以雨中漫步，不是想要什么情调也不是想欣赏什么雨的旋律，实在是这雨来的突然并且我没带伞。

在外边看着园区。

电网电网

当初曾经一脚油门撞倒过灯杆😰

花呢

灰的天眼看着要下雨

大雨说来就来，找个地方避雨

雨小了，我可以继续得瑟漫步了。

到家的时候，雨就停了，看来这场及时雨，就是为我准备的😭

This page is synchronized from the post: 雨中漫步

十多天前，我用微信公众号发起了个小调查：搞了个投票，欢迎大家参与，或许是因为设置了时间限制的问题，调查最终参与人数并不多，只有42人参与了投票，样本有限，大家看个热闹就好。

(图源 ：pixabay)

你是否是STEEM/STEEMIT.COM用户？

(这是废话了，不过第一次搞调查，玩不明白，懒得修改)

你从何处知道STEEM/STEEMIT.COM?

你注册STEEM/STEEMIT.COM有多久了？

你是否曾经在STEEMIT.COM上发帖或点赞？

你是否使用过STEEM的差评功能？

你是否曾通过第三方APP/网站使用STEEM?

你是否投资过STEEM？

你是否使用过买赞功能？

你是否变现过STEEM/SBD?

你对STEEM前景如何看待？

总结如下：

• 大部分是朋友介绍的
• 一年以内用户还是比例较大的
• 大部分都发过帖子点过赞
• 差评还是很少被使用的
• 第三方网站/APP被接受的程度还是很高的
• 大部人曾参与过STEEM投资
• 买赞是很普遍的行为
• 变现的比例并不是很高(待涨？)
• 大部分人对STEEM前景看好

This page is synchronized from the post: 来看看之前搞的调查的投票结果

大约一个月以前，我曾经路遇宝马共享汽车，然而我按提示扫码下载软件后，弄了半天也没收到注册用户的短信验证码，也就没法把它打开开走。在那之后我就再也不曾遇到一辆共享宝马汽车了。

今天在路上突然发现了一组共享电动车，看来国人已经把共享经济玩出了花样。只是我有些好奇，这玩意真的能赚钱吗？

据我所知共享自行车很多都是赔钱的，当年满大街的绿色酷骑单车，现在踪迹皆无，据说押金什么的都无法退，想通过骑行消费掉，对不起现在一辆也找不到了。

所以这些企业看上的真的不是骑行消费给他们带来的利润，人家看重的可能是你的押金，或者是做出规模之后吸引投资以及上市等等。

百度百科中酷奇单车页面最底部有如下内容：

中消协调查，目前已经有34家共享单车企业倒闭，中消协收到众多消费者投诉押金无法退还。其中酷骑单车尤为严重，被消费者投诉21万次，涉及金额10亿多元。中消协申请执法部门立案，申请全国人大对网络平台押金收取监管尽快立法。

但愿这个共享电动车，别走这个老路吧，当然了，老路也难走了，毕竟吃一堑长一智，群众也变得精明了吧。

相关链接

• 路遇共享汽车

This page is synchronized from the post: 共享电动车来了？

今天刘美女发了个庆祝2周岁生日的帖子：My 2nd Steem Anniversary 兩週年之時光飛逝 。恭祝刘美女生日快乐，STEEMIT网站上线没几天刘美女就上来玩了，真是嗅觉敏锐啊。

(图源 ：pixabay)

你是不是也很好奇自己哪天过生日？可惜STEEMIT上，只能看到自己是哪年哪月注册的，也就是说生日是查不到了，只能查查生月了。然后比如我是2016年7月注册的，其实现在就可以发个帖子祝自己生月快乐了，但是总感觉怪怪的，哈哈。

JSON RPC API

好了，言归正传，那么如何查询生日呢？其实有好多方法啦，最原始的方法是调用STEEM JSON RPC API了

{"jsonrpc": "2.0", "method": "call", "params": ["database_api", "get_accounts", [["oflyhigh"]]], "id": 1}

然后我们从一大堆返回数据中找到以下内容即可：

'created': '2016-07-25T03:11:30',

原来我的生日是7月25日，这下我终于可以庆祝生日而不是庆祝生月喽。

不过这个方法太繁琐了，记住或者使用复杂的API都是让人头疼的事，比如我现在也搞不清到底是用上述API还是应该用：

{"jsonrpc": "2.0", "method": "call", "params": ["condenser_api", "get_accounts", [["oflyhigh"]]], "id": 1}

steemd.com

除了上述麻烦的API，其实我们可以用steemd.com 这个steem区块链浏览器来获取包括生日在内的账户信息啦。

https://steemd.com/@oflyhigh
以我账户为例，打开上述链接，在左侧可以轻易地找到我的注册日期（生日）

只需将链接后边的ID换成你自己的，就可以查询你的生日信息了，是不是很方便？

微信公众号

访问steemd.com还需要我们打开网页，并且steemd.com最近一段时间时不时地崩溃，如果你想查自己的生日，恰巧steemd.com又崩溃了，是不是会很抓狂？

别急，你还有个选择，就是使用我们的公众号来查询账户信息（包括注册时间）

(图源 ：pixabay)

只需发送@你的ID，比如@oflyhigh就会返回账户的基本信息，包括生日喽，是不是很方便？什么，你还没有关注微信号？直接扫描以下二维码添加即可：

其它方式

当然了，还有一些其它的方式，比如书使用数据库查询，或者使用一些其它的STEEM工具网站查询，这里就不一一介绍了。

快去查查自己哪天过生日吧，到时候别忘了发个庆祝贴，大家一起Happy!

This page is synchronized from the post: 如何查询哪天过生日？

外出办事，坐公交回家，因为是终点站上车，任我选择座位，于是我选择了公交车后半部分的第二排座椅，这个座位远离前边拥挤的人群，又远离后边嗷嗷喧嚣的空调，并且前边还有一排座椅靠背阻挡，很安全。

(图源 ：pixabay)

公交平稳地行驶，我在后边高高在上地坐着，看着乘客们上车下车，看着车窗外的风景，颇有些风景这边独好的意味，不禁地想，有时候坐公交来个环城一日游其实也不错的（当然了，要有座位）。

正美着呢，公交来了个急刹车，还好刚开出没几站，车上乘客不多，都有座位，所以没有发生乘客踩踏等事件，然而放在公交中间略靠前一点位置的拖布被晃倒了，横着公交车中间。

这可严重影响车内乘客的行走，如果有老人上来不小心就可以绊摔跤，应该马上扶起来才对。咦，怎么没有人扶？大家几乎都看到拖布倒在路中间，但是大家看了一眼后都事不关己高高挂起。

我想下去把拖布扶起来，然而我坐的是车后半边啊，离那个拖布有四五排座位的距离呢，如果我去扶，是不是有作秀的嫌疑呢？毕竟车里这么多人，拖布旁边也有人，大妈们在聊天，小姐姐们在低头玩手机，她们离倒地的拖布仅仅一步之遥啊！

我一边纠结自己要不要去扶，一边谴责这些大妈这些小姐姐，怎么这么懒惰，这么没有公德心，拖布就在她们脚下，她们竟然懒得弯一下腰，懒得伸一下手。不过是扶一个拖布而已，又不是扶摔倒的老大爷，况且我们这也不是南京啊？

等了老半天，拖布还在那静静地躺着，默默地嘲笑我，嘲笑全车人。算了，作秀就作秀吧，我准备起身把拖布扶起来，毕竟公交马上就到下一站了，如果上来上年纪的乘客就不安全了。

正当我活动手脚准备起身的时候，我后边座位的一个胖胖的大姐起身走到前边去，把拖布扶了起来。哎，终于有人挺身而出了，不用我去秀了，我如释重负，同时心想，这个大姐一定是要这站下车吧？

然而事实啪啪啪地打了我的脸，大姐扶完拖布以后径直地回到她原来的座位上，原来她就是看着拖布横在车厢路中间不安全，起身扶拖布而已。大姐坐在座位上，好似什么都没做，一脸坦然。

大妈们停止了嘁嘁喳喳地聊天，好像有些惭愧，低头看手机的小姐姐也抬起头来，略有些茫然，略有些羞愧。

(图源 ：pixabay)

至于前一秒还在纠结要不要起身扶起拖布的我，更是无地自容，不过是应该随手而为的小事，值得我纠结大半天吗？改怎么做就什么做，何必在意他人的目光呢？

This page is synchronized from the post: 公交车上一桩小事

写了一个简单的脚本，定时执行某些任务。好久没有用shell脚本了，有些生疏了，总算磕磕绊绊写完了这个脚本，然后手动执行也正常，然后开开心心地部署到机器上。

(图源 ：pixabay)

过了一天，脚本自动执行，我一看日志（我只在脚本中输出核心部分内容到日志），出错了，然而为什么出错呢？明明手动执行得很好呢。

因为这个任务时间敏感，提前一秒执行都不行，于是乎我在程序上将延时改成了加上了20秒，哼，这次一定不会出错吧。

然后又过了一天，脚本自动执行，果然——又出错了，于是我意识到可能是脚本的BUG。可是我反复执行很多次，看起来很正常啊。

哎，既然是在crontab中出错，还是放crontab中调试吧，于是把crontab时间定到下一分钟，开始执行时用ps观察进程执行的状况，咦，明明应该延时几分钟之巨的时间，为何显示延时20秒（我加上的时间）？之前的时间被你吃掉啦？

看来我对我的代码太过于自信了，还是让crontab的执行的所有内容都输出到log吧，然后重新定时，等着生成log，一下子发现了问题。我调用的一个命令行工具，竟然没有找到，然后之后当然一路错下去了😭

可是为啥我手动执行正常，而放crontab中却不正常呢？想来想去，只有一个可能，crontab没有正确地读取当前用户的环境变量。

既然这这个问题，那么解决起来也很简单了，一种方式是在脚本中加载一下环境变量。

source ~/.profile

另外一种方式就更直接粗暴了，脚本中命令行带上路径，比如: ~/bin/abc，这样就不错出错喽。

相对而言，我更喜欢第二种方式，你呢？

(图源 ：pixabay)

写完这篇文章我才回想起来，我十五六年前写shell脚本的时候就遇到过这样的问题，当时也是这样解决的(第二种方式)，哎，人生啊，就是在不断地做无用功。

这次我记下来，再忘记我就可以来steemit查找了，不过似乎放弃shell才是王道啊。

This page is synchronized from the post: crontab环境变量的问题