abbshr.github.io
abbshr.github.io copied to clipboard
abbshr
人们往往接受流行，不是因为想要与众不同，而是因为害怕与众不同
_Note：第一篇bitcoin日志中介绍了JSON-RPC， 同时记录了启动bitcoind的基本方法。_ 使用bitcoin-explorer获取block chain中的数据，加以分析处理。这一过程的最开始就利用了JSON-RPC。拿insight为例，其后台insight-api中的核心bitcore就是用来和bitcoind进程通信的，而通信的方式就是JSON-RPC：insight进程向bitcoind进程发送RPC指令，并在回调中得到想要的数据，然后呈现给上层应用做数据可视化。 #### JSON-RPC JSON-RPC协议的本质仍是HTTP协议，也就是说JSON-RPC在HTTP基础上进行通信的。 在2013年更新了2.0版本，bitcoind使用的就是JSON-RPC 2.0 - 规定客户端发送JSON的格式： ``` jsonrpc: 用来指定JSON-RPC的版本，必须为2.0 method: 需要调用的方法名 params: 参数数组, id: 由客户端建立的rpc标识符 ``` - 服务器响应格式： ``` jsonrpc: 同上 result: 服务器返回的结果，如果出现错误，就没有这个字段 error: 一个JSON对象，如果调用成功则没有这个字段...
## Log 4：拆开Blocks看Transactions _Bitcoins 结构简图_ ``` Bitcoins：{ BlockChain ：{ Block0：{ Transaction0 ：{ …… } Transaction1 ：{ …… } Transaction2 ：{ …… } …… } Block1：{ Transaction0 ：{ …… } Transaction1...
## beta-v0.0.1 release log - version author: @abbshr - date: 2014-04-26 历经3个月yinle.me终于能以正常的姿态见人了。idea最初起源于一个已经不在Lab的学长，我对这个想法很感兴趣（已经被打印问题困扰很久了），想想今后要是能用上这样一个东西，打印岂不是美哉快哉？ 从寒假开始写前端的逻辑&UI，为了加快响应时间、提高脚本效率，同时保持松耦合以及模块化，我重头到尾写了yinle的前端逻辑框架、动态响应式布局外加一个独立的拖拽事件库。技术栈的这一层真没少下工夫。 后台业务处理部分我们最初选择了Ruby Sinatra框架，这一块是由另一位同学负责，后来因其为忙于其他多个项目，Lab里个忙各的，最后不得不交由我来搞。对Ruby代码，刚开始看着挺清晰，但是越看越迷茫…也不能现学现做吧。折腾了一两天，把代码写的乱七八糟，自己都不忍直视了。。于是我决定，干脆拿Node.js重写一遍算了，总比在这里纠结好。 我也是急急忙忙敲了一晚上，把原型做出来了。第二天陆陆续续修正bugs，增加安全机制，过滤检测模块。下午部署到了Lab服务器上，在内部测试了一下，绑定域名，然后就这样上线了。 说实话，当时心里还是有点没底，毕竟匆忙上线，还不知道有什么问题。昨晚模拟了一次次攻击，对一些模块进行了反复的测试，终于有点信心了，然后做了小范围的宣传。 ## 版本发布日志：（v0.0.1） 目前功能： - 上传文档，获取唯一的提取码 - 凭借提取码打印资料 细节更新： - 增加提取码cookies支持 - 允许在当前界面反复提交待打印文档 -...
## Log 3：拆Blocks之前 BitCoin Explorer环境配置就绪，下一步就可以利用Blocks做任何想做的了。 insight-api和bitcoinjs都使用Google出品的LevelDB作Transaction持久化。因此有必要了解一下LevelDB。 Key Words： - NoSQL - Key-Value - embed - one process - C++ - libleveldb - high performance - open source 关键词中描述了LevelDB的主要特性。很明了，这里不再赘述。 --- 作为一个嵌入式数据库，像SQLite和Node...
## Log1：玩BitCoins之前 ### 运行原理 ### 安全性保障 ### 如何使用 ### 优势分析与市场前景 key words： 去中心化，自由货币体制，无金融危机、通货膨胀风险 ### 带给我们什么？ 随着BitCoins越来越受人欢迎，其应用价值变得越来越大。对BitCoins的把玩之道更加值得探索也更能发掘有趣的东西。 比如说分析一个账户的消费情况、挖掘某些账户之间千丝万缕的关联、挖矿赚币、加密与解密的研究等等等等。 在对BitCoins的了解过程中，萌生了一个想法[incbrain](http://abbshr.github.io/incbrain)，这个构想也是借鉴了比特币的设计哲学。 ## Log2：BitCoins基本环境搭建 ### 配置客户端 无论是想写基于BitCoins的app还是做各种数据分析，首先应该将整个网络上的区块链（blockchain）获取下来并与网络保持同步。说的简单点，就是“成为BitCoins网络的一个节点”，没错，挖矿之前也要做这些。 第一步，到BitCoins的官网下载[BitCoins挖矿程序](https://bitcoin.org/en/download)——**bitcoind**。它运行在各个节点上，将会开启一个长期的后台服务进程，用来与全网络的BlockChain保持同步。 > Bitcoind is a program that...
ES5自从发布到现在已经有几年了，相比ES3确实增加了不少很赞的东西。可是大部分人还没接触到它非常棒的特性，下一代标准就要发布了。我想无论如何应该在ES6出台之前，回顾一下第五代提供的优秀特性。因为ES6的乱搞很有可能将JavaScript毁的面目全非。 ### Object ##### 属性的`getter`和`setter` 在ES5中属性值value可以用两个方法`getter`和`setter`替代。由这两个方法定义的属性称作**存取器属性**，而只有一个简单的值的属性被称为**数据属性**。当查询存取器属性时，自动调用getter方法，当为该属性设置值时，则调用setter方法。 如果存取器属性同时具有setter和getter方法，则该属性可读写;如果只有getter方法，赋值操作将会无效;如果只有setter方法，那么读取属性时返回undefined。 存取器属性也是可以被继承的。 ##### 定义存取器属性 _字面量格式_： ``` js var obj = { //普通的数据属性 data_prop: value, //存取器属性 get accessor_prop() { console.log("invoke 'getter' prop"); return ++this.data_prop; },...
## Chapter 1：事件如何被监听？ 看完libuv对watchers和事件循环的描述之后，突然发现我一直以来忽略了一个问题：事件是通过什么方式被监听的？ 无论是线程还是进程都和我们生物不同，他们不会自发感知外界环境的改变。所以对于这个问题，第一印象往往是：轮询。也就是用一个 while(true) 循环不断询问外部是否有什么新鲜事。 可问题是，我们从来没见过系统内核进程因为监听一個socket而导致CPU狂转、系统挂掉吧。还有，浏览器中监听JavaScript事件是常事，它也没让系统变卡顿啊。 单从这一点来看，轮询事件的产生并非上策！除了轮询，还有什么方法能做到事件的监听呢？或许我们可以从操作系统的底层——计算机硬件工作流程中找到答案。 操作系统在与外设进行交互是典型的事件监听：CPU与设备控制器之间有一条中断请求线，设备控制器会在外设I/O结束时通过电信号向CPU发送中断请求，CPU在原子指令过后检查中断线的状态位判断I/O是否结束，如果结束的话就跳转到内存特定进程位置（中断向量）调度中断处理程序。 我们先来简单分析一下底层的事件监听模型。所谓事件是由源发出，就是一个电信号（或脉冲信号）。进程虽然做不到监听，但硬件CPU却可以，它能接收到电信号的变化。最后CPU对事件做出反应，也就是调度处理进程。 没错，事件监听还可以靠中断来实现。 ## Chapter 2：基本I/O方式 阻塞I/O、非阻塞I/O、同步I/O、异步I/O是操作系统的几大I/O模式。 我们往往会认为阻塞I/O与同步I/O等同，非阻塞I/O与异步I/O等同。其实这种观点是不准确的，这里科普一下他们的细微区别。 阻塞I/O，即进程/线程在做I/O操作时，被CPU调度到阻塞队列，等待I/O操作的结束，然后进程再被调度回来，处理I/O结果。在等待期间，进程除了休眠无法做任何事情，不过他不占用CPU时间片，这时CPU可以先调度其他进程，当I/O完成时以事件形式通知CPU。 非阻塞I/O与上述相反。进程不会一直等待到I/O操作结束，当I/O请求发出时，进程会立马从系统调用返回，这时进程可以继续工作，也就是CPU不必将其调度到阻塞队列了。但此时进程很可能还没有得到I/O结果，所以要通过轮询来检验I/O是否操作结束。虽说进程没有被阻塞，不过CPU的时间片被白白占用。 同步I/O，就是进程先等待I/O结果，再继续处理其他任务。所以说，同步I/O由阻塞I/O实现。 而异步I/O与非阻塞I/O的差别就是：前者的I/O调用在不阻塞进程的前提下完整的执行，后者的I/O调用为了不阻塞进程会立刻返回，即便是没有得到I/O最终结果。 ## Chapter 3：Node中的事件循环机制 上面提到的**阻塞**和**非阻塞**是针对_进程_而言的，和_CPU_的阻塞正好相反，这点必须要认清。 libuv在Linux平台上使用了Linux的_epoll_机制。epoll是Linux平台的I/O事件通知工具，主要用来处理大量的文件句柄。 libuv的事件循环特性就是由epoll提供的，先介绍一下epoll。 epoll的函数在头文件sys/epoll.h中。用epoll编写程序会用到两个数据结构： ``` c...
近两年用Node写过几个web应用。过程远比预期的困难，涉及到了HTTP协议、TCP/IP协议、WebSocket协议等计算机网络知识，MongoDB、noSQL、schema设计等NoSQL数据库知识，进程、线程、同步、异步、并发、阻塞、文件系统、锁等操作系统知识，这些都是超出Node范畴的东西。然而Node中却处处提到他们，而Node的核心也构建在大多数这些基础知识之上，我觉得仅仅是“使用”并不能让你真正理解精髓。所以，要想理解&精通Node，需先广泛汲取必备知识，这也是我为毛要学习底层的原因。 这篇笔记记录了我学习libuv的过程，包括对一些模糊概念的解释，Node事件机制的实现。 没错，libuv就是Node两个核心架构（libuv + V8）之一！ /\* note: 操作系统默认为*nix */ 先获取libuv的源码。git clone下来github上的项目或通过HTTP访问dist页面下载，当时的版本是 libuv-v0.11.17 。 编译源码。过程很简单，我们可以参照README进行构建，这里提供了两种方式： 1.通过autotools： ``` sh $ sh autogen.sh $ ./configure $ make $ make check $ make install...