最近在 Qinling 项目中实现对 function 运行时做资源限制，主要是 cpu、内存和磁盘，后续还会考虑 package 大小、文件句柄、系统调用等资源限制。限制资源使用的原因很简单，因为底层是容器实现，function 都是跑在容器里，如果不做资源限制，任由用户自己在 function 里分配资源，那么不同用户的函数势必会相互影响，更严重的情况是恶意用户会利用一些手段突破容器的限制，威胁 hypervisor，进而威胁整个云环境。
继续阅读 »
从一个视频里接触到 JavaScript 的get和set
一般来说，我们是怎么给我们类的属性定义get和set方法的呢
```javascript
var Person = function (age) {
this.age = age;
};
Person.prototype = {
getAge: function () {
return this.age;
},
setAge: function (age) {
this.age = age;
}
};
var p1 = new Person(19);
var p2 = new Person(23);
```
继续阅读 »
事件处理
React中的事件处理方式与HTML方式类似，都是通过为标签添加属性来声明事件处理函数。如下所示：
```javascript
var LikeButton = React.createClass({
getInitialState: function(){
return {like: true};
},
handleClick: function(){
this.setState({like: !this.state.like});
},
render: function(){
return (
继续阅读 »
Nova在NFV场景下会提供NUMA相关高级特性，这里提供一个脚本查看计算节点的NUMA相关信息。
#!/bin/bash
function get_nr_processor()
{
grep '^processor' /proc/cpuinfo | wc -l
}
function get_nr_socket()
{
grep 'physical id' /proc/cpuinfo | awk -F: '{
print $2 | "sort -un"}' | wc -l
}
function get_nr_siblings()
{
grep 'siblings' /proc/
继续阅读 »
状态模式的关键是区分事物内部的状态，事物内部状态的改变往往会带来事物的行为改变。
电灯程序
首先给一个不用状态模式的电灯程序例子：
var Light = function() {
this.state = 'off'; //电灯初始状态off
this.button = null; //电灯开关按钮
};
Light.prototype.init = function() {
var button = document.createElement('button'),
self = this;
button.innerHTML = '开关';
this.button = document.
继续阅读 »
享元模式的核心是运用共享技术来有效支持大量细粒度的对象。如果系统中因为创建了大量类似的对象而导致内存占用过高，享元模式就非常有用了。在JavaScript中，浏览器特别是移动端的浏览器分配的内存不算多，如何节省内存就成了一件非常有意义的事。
初识
假设有个内衣工厂，要50个男模50个女模，你可能会这么写程序：
var Model = function(sex, underwear) {
this.sex = sex;
this.underwear = underwear;
}
Model.prototype.takePhoto = function() {
console.log('sex=' + th
继续阅读 »
一些重构的建议：
提炼函数
* 避免出现超大函数
* 独立出来的函数有助于代码复用
* 独立出来的函数更容易被覆写
* 独立出来的函数如果拥有一个良好的命名，
* 它本身就起到了注释的作用。
比如在一个负责取得用户信息的函数里面，我们还需要打印跟用户信息有关的log，那么打印log的语句就可以被封装在一个独立的函数里：
var getUserInfo = function() {
ajax('http://xxx.com/userInfo', function(data) {
console.log('userId: ' + data.userId);
console.log('u
继续阅读 »
本文翻译自老马(Martin Fowler)的博客文章，该译文现已被博客原文收录在其下方中文翻译处。
在我的职业生涯期间，我曾听过很多关于一个方法(或者说函数，本文针对两者将不做区分)应当有多长的争论。这其实引申到另一个更加重要的问题上：我们应该在什么时候把代码封装在它自己的方法内？有些准则会基于方法的长度，比如方法的长度不应该超出屏幕可以容纳的范围❶。有些会基于复用，即任何被使用超过两次的代码都应该抽出自己单独的方法，而只在一个地方使用过的代码就应当保留在行内。然而，于我而言，最合乎情理的还是这种论点：那就是意图和实现的分离。如果你不得不费点精力查看一段代码，才能弄清楚它具体做了什么，那你就需要把它抽出成一个方法，并且用“它
继续阅读 »
For the performance tuning, the simplest way is to record how many time is elapsed in a function. The only difficulty we’re facing is that: there maybe many exit for a function. Thanks to C++’s constructor/deconstructor feature, it’s easy for developer to record the elsaped time.
继续阅读 »
没什么好解释的，直接看代码吧。
js
(function (factory) {
if (typeof define === 'function' && define.amd) {
// AMD. Register as an anonymous module.
//define(['jquery', 'underscore'], factory);
} else if (typeof exports === 'object') {
// Node/CommonJS style for Browserify/Seajs
module.exports =
继续阅读 »