ps -ef | grep httpd | wc -l
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
/* =========================================================== | |
* bootstrap-tooltip.js v2.2.2 | |
* http://twitter.github.com/bootstrap/javascript.html#tooltips | |
* Inspired by the original jQuery.tipsy by Jason Frame | |
* =========================================================== | |
* Copyright 2012 Twitter, Inc. | |
* | |
* Licensed under the Apache License, Version 2.0 (the "License"); | |
* you may not use this file except in compliance with the License. | |
* You may obtain a copy of the License at |
/* =========================================================== | |
* bootstrap-popover.js v2.0.1 | |
* http://twitter.github.com/bootstrap/javascript.html#popovers | |
* =========================================================== | |
* Copyright 2012 Twitter, Inc. | |
* | |
* Licensed under the Apache License, Version 2.0 (the "License"); | |
* you may not use this file except in compliance with the License. | |
* You may obtain a copy of the License at | |
* |
在软件管理世界里存在着被称作“依赖地狱”的死亡之谷,系统规模越大,引入的程序包越多,你就越有可能在不久的将来发现自己深陷绝望之中。
在多依赖的系统中发布新版本程序包很快成为噩梦。如果依赖关系过紧密,可能面临版本控制被锁死的风险(必须对每一个依赖程序包改版才能完成某次升级)。而如果依赖关系过于松散,又无法避免版本混乱(\产生超过合理值的版本数/)。当你项目的进展由于版本控制被锁死和/或版本混乱变得不那么简便和可靠,也就意味着你正处于依赖地狱之中。
为了解决这个问题,我提议通过一些规则和约束来表述版本号如何命名及何时更新。要使此系统正常运作,你首先需要声明一个公共应用程序接口(以下简称API)。可以\以文档形式或代码形式实施/。需要注意的是,这个API必须是清晰和明确的。一旦公共API确定下来,你将通过版本号增量来描述版本修改。形如X.Y.Z(主版本号.副版本号.补丁号)这样的版本格式。通过增加补丁号来表示不影响API的错误修复,增加副版本号来表示兼容现有API的扩展/修改,而增加主版本号则表示不兼容现有API的修改。
(function() { | |
/** | |
* 记录方法使用情况的类 | |
* @param {Array.<boolean>} umMap 初始的使用情况 | |
*/ | |
var UsageManager = function(umMap) { | |
this.umMap = umMap || []; | |
}; | |
/** | |
* 记录新的使用情况 |