以太坊与随机数问题
值得注意的几篇文章： 这个 reddit 上的帖子里提到了 RANDAO 其实是不够安全的，但下面 RANDAO 的作者又出来说这个东西被它改进过了。 这个话题下面还有人引了 Vitalik 的一篇博客。 randao的实现。基本上就是用一个dao 的方式（Decentralized autonomous organization）来运行一个匿名先知组织。这个设计思路和 Vitalik 谈到的用先知而不是全上链的版本来运行智能合约的对比基本一致。 vdice 自己的博客里也提到了用未来的块hash来生成随机数是不安全的，他们直接使用了oraclize。改天要分析下它们所谓的“200行的安全的codebase”。
健康闲谈-健康管理和疾病预防
健康是一种身体上、精神上和社会上的完美状态。 — 世界卫生组织健康定义 养生三大原则： 和谐原则 辩证调摄 “度”和“量”的适当掌握-充分进行综合调养 和谐原则-“天人相应”理论和自然界相适应。情志养生。 辩证调摄-因人、因时、因地制宜每个人都不同。不要乱吃补品。疲劳的时候吃清淡的。运动可以发泄身体的郁闷。 “度”和“量”的适当掌握-充分进行综合调养碳水化合物是很重要的。吃蛋白质尿酸高。太操劳？知道寒暑冷热。不要运动过度。 四季养生 运动养生起居养生精神养生环境养生饮食养生睡眠养生 不要喝高汤里的嘌呤不要一哄而上吃流行的 合理的饮食适量运动戒烟戒酒心理平衡充足睡眠 未病先防欲病早治已病防变
学习区块链的基础资料
《猥琐发育成区块链开发者》普林斯顿的《Bitcoin and Cryptocurrency Technologies》课程《精通比特币（第二版）》
几种共识算法
达成共识的英文原文是 come to consensus。达成共识以后，也未必代表数据是完全一致的（Raft 算法中 leader 发出 append log 的 commit 命令即算达成共识？但如果中途数据丢失，则还是会有子节点数据不一致）。 在分布式环境下，多个系统协同工作的效率，受制于系统交叉点的性能。在需要达成分布式共识的场景下，分布式共识算法在保证系统安全性的同时，限制了全系统横向扩展的性能提升。 根据环境的不同，可以应用不同的共识算法。 在完全互信的环境下-私有链、私有的分布式数据库，节点之间可以使用 Paxos 或者 Raft 这种 leader 相对固定的算法。 在有限互信的环境下-联盟链，可以使用 PBFT。PBFT 算法是依据确定性的投票（可能是漫长的投票，也可能进入死循环）达到确定性一致的算法。 在没有互信的情况下-公有链，可以使用 POW/POS/DPOS/POA。这类算法是基于概率得到正确的最终一致性，性能比 PBFT 要稍微好点。 最好的共识算法应该模块化，例如 Corda 中的 notary，Hyperledger fabric 中的...
Vue 值得注意的小知识点
this.$el.querySelector(‘#map’) 只能查找第一个 dom 以内的 dom 节点，不包括当前的 dom。 在 webpack:// 这个域下可以看到可调式的 vue 文件。
Spark Standalone 模式启动的全过程
把这个事情做成一个小 routine，免得以后每次都要看英文文档来搭 dev 环境 准备工作下载安装包，解压并进入根目录。 ./sbin/start-master.sh。看 jps 果然已经有了一个 Master 进，文档里面说会打印出 spark 的 master url，但没打印出来。就去默认的http://localhost:8080上看即可： 12URL: spark://magicliang:7077REST URL: spark://magicliang:6066 (cluster mode) 这个6066在本地 telnet 不通，也是很神奇。 把这个 URL 拼接成 worker 的启动命令./start-slave.sh spark://magicliang:7077，然后可以看到以下这张图： 文档里的给出的定义 worker 节点的方法：在 Spark 根目录下定义一个 conf/slaves 的文件，每一行写一个主机名。如果这个文件不存在（就是我们现在这个状况），则 worker 就会全部启动在 localhost 上。而 master 是通过 ssh...
DAG 执行框架优于 MapReduce 的地方在哪里？
有个同学问我什么是 DAG 框架。我感觉隐隐约约听过，但又讲不清楚它的概念。 上网搜了一下，我们常见的新大数据执行框架如 Spark、Storm，还有一个我没听过的 Tez，都算 DAG 任务执行框架。他们的主要优点是，可以用 DAG 事先通晓整个任务的全部步骤，然后进行转换优化。如 Tez 就可以把多个任务转换为一个大任务，而 Spark 则可以把相关联的 Map 直接串联起来， 免得多次写回 hdfs（看来 hdfs 也很慢）。传统的 MapReduce 框架为什么不能理解这种优化空间的存在，在任务运行的时候好像一个盲人一样，是个很有意思的话题。 Quora 上的一个相关的问答。
风险问题
风险可能有收入也可能有损失。风控先是管理，然后是控制。 精细化管理，平衡点。 信用风险（Credit Risk）欺诈风险（Fraud Risk）操作风险（Operationl Risk）伦敦乌龙指？现金流风险（Liquidity Risk）市场风险（Market Risk）监管风险（Regulator Risk）声望风险（Reputational Risk） Exposion 担保套利 美国三大征信局 Experian、TransUnion、Equifax。美国百分之八十五的人的信息在民间征信局。 美国的征信分数 FICO 由五个部分组成。 中国人会抹掉五年期的征信历史。 Payday Loan 是没有年化上限的。
比特币小细节
收款地址是公钥的hash。 区块结构： 数据项 描述 长度 Magic No 魔数 总是 0xD9B4BEF9 4 字节（定长） BlockSize 区块大小 到区块结束的字节长度 4字节（定长） BlockHeader 区块头 包含六个数据项 80字节（定长） Transaction Counter 交易计数器 正整数 VI=VarInt 1-9字节（变长） BlockHeader 区块头 包含六个数据项 80字节（定长） Transactions 交易 交易列表（非空） 由Transaction Counter 描述的长度（变长） 由此表可见，只有交易计数器和交易明细列表是变长的。 比特币使用 SHA256 算法，它的结果哈希值大小为 256 位。也就是说，只要输入超过2的256次方个数，就一定会发生碰撞，即使只有2的255次方个数，也有百分之九十九的几率发生碰撞（为什么？）。 当前（这一百年内），每个区块都至少包含一个...
什么情况下 Scala 应该省略 Return 关键字
一个很有意思的回答。 总体而言，如果我们能够分得清什么 last expression，我们就能推导出和编译器一样的返回类型结果。否则，我们应该显式地加上 return，这样既指定了实际返回类型，也指定了控制流上的返回点。
