其实说白了就是低买高卖, bid-ask spread 也就是买一和卖一的价差, 价差越大价差越大 marker 潜在的收益就越高.

两天大 A 股行情不错

上世纪末 C10K 问题被提出来后, 各种程序设计模式被提出来解决这个问题. Reactor Pattern 是其中一个. Reactor Pattern 由 ... 在其论文 ... 中提出, 它以同步的方式侦听多个事件源已经处理这些事件源的方式. Reactor Pattern 包含如下几个组件: • Handles - 这是同步侦听器所侦听的事件源集合, 对应的可能是文件描述符, 定时器, 同步对象等

从来没有什么孙悟空，也没有什么西游记，师徒五人，其实只有唐僧，其他四个，都是唐僧的心魔。途中的磨难，都是唐僧内心的磨砺—— 定住心猿则悟空，拴住意马便化龙，戒贪戒色共八戒，戒杀戒嗔是悟净，身心纯净朝佛祖，心之所在即西天。 —戴荃《悟空》

Cookie 这里说的就是我们通常所熟知的 cookie，很多第三方公司就是借助这种 cookie 实现追踪的。比如网站 A，B 都使用了 DoubleClick 的 js 脚本，DoubleClick 的脚本在用户访问网站 A 时被加载并埋下 cookie，下次用户访问网站 B 时这个信息会上报回给 DoubleClick。这种方式实现起来简单，防范也简单，定期清理 cookie

K&R C, 是历史上第一个 C 语言标准, 是 C 语言的两位创始人亲手打造的, *C Programming Language, 2nd Edition* 这本书里记载了这一版标准 接下来, 1989 年, ANSI 作为美国国家标准局发布了 C89 标准, C89 也被称为 ANSI C. 1990 年, 国际标准组织 ISO 将 C89 收编, 发布了 C90 标准, 标准的内容和

(PS: steemit 啥时能发短推文就好了)

RESTful 在过去风靡了有一阵子，然而在实践中它并不是那么好用，在现今微服务横行的时期更是如此。 REST 由 HTTP 承载，REST 建议我们尽可能的使用 HTTP 的状态码表示业务返回码，这从一开始就是有问题的，HTTP 状态码屈指可数，根本无法囊括复杂的业务返回值。而且很多时候是有歧义的，比如 404 到底表示这个 url

不知是最早是哪个平台带起来的风气, 看文章先看评论. 大概是头条吧. 那时候我深受其影响, 加上现在信息这么多这么烦躁, 一篇文章又那么长, 看文章再也没有耐心认真看完, 而是走马观花式的快速划完文章, 然后划到最后看评论. 一是期望能够在评论中直接找到文章写了什么, 二是很多时候我自己不知道怎么理解文章内容, 想看看大众对此事的看法. 在评论中还能经常看能到很多诸如 "直接来看评论" "就喜欢看评论"

工厂模式 有些类对象的创建比较麻烦, 不仅构造参数多, 参数可能本身也是其它类对象,  也要事先构造. 比如 Java 里的 java.text.DateFormat 类, 自己用起来很麻烦.   工厂模式就是, 提供一个静态方法, 支持传入少量的基本类型的参数, 根据传入的参数创建不同的对象, 大大减小了使用者的使用成本.

URI 编码 URI 中的一些字符被保留来用作分隔符, 比如 `/`, `:` 用来指明协议, `?` 用来分割 path 和 querystring, `&` 用来分割 querystring 中的不同参数, `=` 用来分割每个参数的键和值. 其它还有很多. 那么问题来了, 如果我们想在 URI 中正常使用这些保留字符该怎么用呢? 比如说我们就是想在参数得值中包含 `&` 字符:

    我一直知道解释器与编译器的区别. 编译器是事先将代码编译成机器码, 然后直接送进内存让 cpu 执行; 解释器则是解释执行代码, 可能会将代码先转换成一种中间码.   以前一直有一个误区就是解释器在解释执行的时候会把源代码或者中间码转成机器码, 也直接交由 cpu 执行, 然而我错了. 解释器是不会把源代码或者中间码转换成机器码的,

今天又听到关于 TCP 是全双工通信的讨论, 勾起了一些思索. 全双工, 半双工这些术语在网络行业中比较严谨. 全双工指的是发送的同时也能接收, 这意味着通信的两端至少要有两条线, 一条线发送另一条线接收, 这样才能够达到 "发送的同时也能接收". 像传统以太网这种总线结构, 一台主机发送其它主机就只能等, 是不能称之为全双工的. 802.11 这种无线网络, 就要看有几根天线了, 如果有两根天线,

众做周知, PBFT 是目前能够有效对抗拜占庭问题的算法之一, 使用 PBFT 意味着就算我们的系统中有 2/3 的节点有问题, 只要有 1/3 是好的, 那这个系统就依旧能正常运作. 最近需要在 DPoS 的基础上实现 PBFT 算法, 断断续续看了很久 PBFT 的论文, 提炼出在 DPoS 中需要注意的如下一些概念, 并分析在 DPoS 中如何实现 PBFT 的一些行为. 视图 整个分布式系统随时间往前推进,

 单 io_service 多线程模式时 io_service 的典型用法，在这种模式下，多个线程会竞争 io_service，竞争到的线程会得到处理下一个 handler 的机会，通过这种用法，表现为 io_service 会自动的将 io 事件分配给各个线程去处理，并且我们自己的任务也可以通过 io_service.post() 丢给线程们去执行，这相当于我们拥有了一个线程池。 

为什么需要锁 当多个线程共享同一块内存区域时, 我们需要保证任何一个线程在访问这块内存时, 所看到的内容是稳定的. 如果所有的线程对这块内存的访问都只是读取, 那么我们就不需要采取额外措施. 但哪怕其中有一个线程会修改这块内存, 那我们就要对这些线程进行同步.之所以要这么做是因为修改内存的操作往往都不是原子操作, 而是分成多个时钟周期, 一个线程对内存的操作可能在任何一个周期被另一个线程打断,

  (首发 cifer.me : 对协程的一点认识) 协程的调度 我们知道线程是 CPU 的基本调度单元，线程调度靠的是时钟中断.   协程是执行于线程之内的更细粒度的执行单元，他的调度无法依赖时钟中断，而是要靠一个用户态的调度器，这个调度器可以是抢占式或非抢占式，抢占式调度器需要语言的运行时支持，据我所知只有 erlang

让这段经典台词上链： （李时珍）上奏疏如同开医方。上医医国，中医医人，下医医病。我大明朝已然病入膏肓，不知道你这道疏，是想医病，医人，还是想医国？  （海瑞）国因人病，医病便是医人，医人才能医国。  （李时珍）病根呢？  （海瑞）视国为家，一人独治，予取予夺，置百官如虚设，置天下苍生于不顾，这就是病根。

EOS “官方” 给出过两次测试结论，一次是 BM 在自己博客上宣布的，另一次是 @spoonincode 在 github 上公布的。  BM 是在自己的 macbook 上粗略的测的，没有给出太多细节。@spoonincode 后来给出的更详细的测试方案，这个方案也被一些 eos bp 的团队拿去重复试验过，可以算得上是官方证实的测试方案和测试结果了。   

最近一个项目里的 CMakeList.txt 是在网上找来的例子改的, 里面有这么一句: set(CMAKE_EXE_LINKER_FLAGS  "${CMAKE_EXE_LINKER_FLAGS} -L/usr/local/opt/boost/lib -lboost_system -lboost_program_options") 平时在 mac 上开发构建, 一直没什么问题, 今天拿到