abbshr.github.io
abbshr.github.io copied to clipboard
abbshr
人们往往接受流行，不是因为想要与众不同，而是因为害怕与众不同
## 讨论闭包（Closure） 闭包是JavaScript中的一个基本概念。咋一看感觉没什么了不起：不就是在函数中定义了一个嵌套函数，并且嵌套函数能够访问外部变量，然后这个嵌套函数就起个名叫Closure嘛~ 没错，在计算机科学文献中闭包的定义不过如此，但你不一定会用。举个例子： ``` var 一只变量 = 'global'; function 只是测试() { var 一只变量 = 'local'; function inside() { return 一只变量; } return inside; } 只是测试()(); ``` 在这个例子中外部函数返回了一个闭包inside，然后在全局作用域下调用了返回的这个函数，然后最终返回‘global’。 看上去很简单，不是么？ 如果要真是这样的话那就没意思了。。。真实的情况是调用闭包后返回“local”！...
## Idle进程和Init进程, 谁是老大? 感谢这学期开了一门**嵌入式操作系统**, 纠正了我一些认识上的误区. 当涂老师提到idle进程时, 我突然想起了init, > Init是所有进程的祖先, 它是内核创建的第一个进程... 记得我们学操作系统时水笔老范说了好几遍, 已经牢牢刻在脑海里了, 所以潜意识里仍是不假思索认为init是头子. 可是仔细看idle的作用以及地位, 貌似比init进程还有高, 这就让有点怀疑当初所学的东西是不是漏掉了什么... 确实当年学操作系统时漏掉了一些重要的东西, 今天和实验室的师兄们讨论了之后终于补回来了. ### 先从Linux启动流程说起... 当boot loader选定并加载一个内核后, 将计算机控制权交给加载的内核, 并创建一些系统函数. 当准备工作完成, 内核逻辑开始调用定义的`start_kernal()`函数. `start_kernal()`函数的任务就是建立中断处理机制, 初始化内存管理的剩余部分, 初始化调度器, 初始化设备以及驱动等等....
# Node.js启动流程探秘 _涉及源码_ > src/node_main.cc > src/node.h (src/node.cc) > src/node.js > src/env.h 这篇日志的诞生纯属偶然,我当初只是想寻找NPM上处理底层网络的模块用来处理ARP协议,搜索了半天并没有发现合适的,最贴近的也就是raw_socket模块,但它只能用来处理IP协议上层和ICMP数据报.然后我就开始各种Google各种Baidu,未果.于是想自己扩充一下这个底层功能,便查找C/C++ addon的文档,这就一不小心"误入歧途"了,从学习addon到研究模块加载最后成了源码阅读. 也好,在这个时候从设计和编码的角度重审Node也别有一番体会. 拿来Node的源代码,熟悉源码构建编译的童鞋一眼就会发现`src`,`lib`目录.这表示Node的源码结构很清晰,以下是源码目录的主要结构: - `deps/` Node核心功能的依赖,包括V8引擎源码,libuv源码,openssl,npm等等 - `lib/` JavaScript核心模块(*.js),如`http.js`,`net.js`等 - `src/` Node架构的核心源代码以及C++核心模块/内置模块(*.cc | *.h) - `tool/` 包含Node的项目构建工具gyp,js2c.py等,用来编译源码生成二进制文件,预处理工作等...
## Prototype JS除了有函数式编程、事件驱动编程、命令式编程的泛式之外，更支持面向对象编程这一泛式。 谈到OOP，当然少不了“继承”这一特性。 在JavaScript中**没有类**的概念，这句话也是各种教程中常说但常常自相矛盾的一句。 没有类该如何继承？ 这就是原型（prototype）出现的原因。JavaScript中继承的实现是通过设置原型完成的。原型是一个**对象** ，同时也是每个JS对象的一个**隐性的属性**，也就是说在遍历对象的全部属性时不会显示这个原型。对象会自动获取原型中的属性并允许直接使用。 其实继承可以选择**类式继承** 或 **原型继承**。 对于熟悉Java/C++的人选择类式继承会感觉更容易理解。不过原型继承更容易实现。 ``` var object = {}; //定义一个空对象 object._proto_ = { //直接为其设置原型 name: "Ran Aizen", age: 19 }; console.log(object.name); //...
### 编写Signaling服务 所谓signaling说白了就是外带的一个消息传递通道, 像polling, long-polling, long-connection, WebSocket等都可以做到. 至于signal服务具体要传递什么格式的消息, 下面有个signaling流程抽象, 来自HTML5ROCKs: ``` js // 用WebSocket构建signalingChannel最为直观 var signalingChannel = new SignalingChannel(); // call start() to initiate function start() { pc = new...
作为一个变革Web2.0的主力军, WebRTC赋予了浏览器之间实时通信(Real Time Communication)的能力, 提供了比WebSocket更加丰富的展现形式: 实时媒体流. 再去看看HTML5带来的Media API, 不难得出多媒体网络的特性正在逐渐与传统的Web融合的结论. 所以现在有必要研究一下多媒体Web的载体WebRTC了. 首先, 它是做什么的? 这里引用来自WebRTC官网的一段话: > WebRTC offers web application developers the ability to write rich, realtime multimedia applications (think video chat)...
椭圆曲线数字签名算法(ECDSA)为比特币系统运转的可靠基石. 私钥: 随机生成的32byte(256位)数字 公钥: 分为压缩公钥(33byte)和非压缩公钥(65byte) 签名: 对私钥进行HASH运算. 由签名和私钥可推出 地址: 为方便交易而使用的公钥替代物(25byte) 私钥→公钥→地址, 这一过程是不可逆推的. ``` tx hash id = SHA256(SHA256(tx data)) tx fee = sum(input) - sum(output) ``` ``` js /* 计算tx...
我以前常在windows环境下硬盘安装ubuntu, 过程挺痛快的, 没遇到什么大波折, 我想Linux下安装windows也会一样容易吧. 先列表统计一下安装方式: - U盘安装 - 光盘安装 - 本机硬盘安装 - 通过其他外置存储介质安装 光盘方式最傻瓜, 除此之外U盘安装最简单, 每款操作系统都有U盘刻录工具, 只要把镜像交给它基本上就ok了. ~~不过像我这样不喜欢用寻常方法的, 就要花点时间研究研究另外两种方法了.~~ 忽略上面那句话, 其实是被迫用其他方法的. 家里的ubuntu 13.10台式机要装windows 7, 现在手边没有光盘, 只有一个1GB的U盘, 但找到一个闲置的IDE接口老式硬盘. 难道没U盘就玩不转吗? 这怎么可能~ window装ubuntu不也是用硬盘安装的嘛~~~...
### Unix Stream 流(stream)是Unix中的一个古老概念. 它的出现解决了I/O上的许多问题. 流是数据源的抽象, 内部有一个缓冲区, 所有输入/输出的数据都要经过这个内部缓冲区. 最简单的讲, 他的作用就是**减少内存驻留数据**和**速率控制**. 要理解流的第一个作用, 需要清楚一点: 对于送来的数据, 我们有两种处理方式. 一种是直接送达目标(空目的地/socket/硬盘/显卡等外设), 另一种是经过某些处理(如解析器)之后再送达目标. 因此我们不会希望大量数据长久驻留在内存中. 回忆一下计算机网络里, 路由器的**存储转发**和**直通交换**概念. 所谓存储转发, 就是每经过一跳都需要等待所有分片的数据报全部接收到(也就是需要经过重组). 而无需等待其他分片的就是采用直通交换技术了. 我认为这是对stream的轮廓最形象的刻画. 流在这里就是路由器的直通交换功能. 拿Node.js中的文件读写举例. 读取文件最简单的API是`fs.readFile`, 他会一次性把整个文件读入内存中. 如果文件特别大, 那么内存的开销也相当可观. Node也提供了流式读取API`fs.createReadStream`....
高并发和大数据里面挑战无处不在, 花样层出不穷, 总能从中挖掘出新的知识,获得新的技能. 因此也成为架构师和追求程序性能的黑客津津乐道的话题. 再加上"实时"这一前卫特性, 整个程序就更加暗流涌动,险象迭生了. 所谓险象迭生包括**内存占用**,**核心架构**,**内存泄露**,**CPU占用**和**程序耗时**. 大数据算法就对内存占用和程序耗时要求特别严格, 而高并发一定会挑战资源占用的极限. ### 数据遍历问题 今年10月份有一段时间我集中精力处理Bitcoin Address的提取与更新问题. 提取到levledb中的数据集大概有2GB, 全都是BTC地址, 目的是方便后续基于账户地址的数据分析, 比如最简单的"统计Top 100 BTC Address", 我需要对数据集中的每条地址做更新, 这需要调用insight-api的计算函数填充空白地址的balance等等详细信息, 而这个函数内部又需要查询两个数据库, 在经过层层回调和数学计算才能得到一条地址的信息. 其实单看这个问题并不复杂. 有不错的解决方案,比如并行查询更新, 但对当前情况并不适用. Insight内部使用的是leveldb, 分别为区块和交易各建立一个数据库, key有不同的几种,...