uhealin / asskicker Goto Github PK

View Code? Open in Web Editor NEW

4.0 4.0 2.0 16.63 MB

上帝说：大部分人认为是对的，基本上都是错的

C++ 8.15% C 0.02% C# 53.21% CSS 4.94% JavaScript 0.14% MATLAB 33.32% Objective-C 0.04% M 0.17%

asskicker's People

Contributors

Stargazers

Watchers

Forkers

angel0836 lxy613

asskicker's Issues

html cheat sheet

空白模板

<!DOCTYPE html>
<html>
   <head>
       <meta charset="UTF-8" />
   </head>
   <body></body>
</html>

jquery

<!DOCTYPE html>
<html>
   <head>
       <meta charset="UTF-8" />
       <script type="text/javascript" src="http://code.jquery.com/jquery-1.11.0.min.js"></script>

       <script type="text/javascript">
              $(document).ready(function(){

               });   // $(document).ready
       </script>
   </head>
   <body></body>
</html>

jquery + knockout

<!DOCTYPE html>
<html>
   <head>
       <meta charset="UTF-8" />
       <script type="text/javascript" src="http://code.jquery.com/jquery-1.11.0.min.js"></script>
       <script type="text/javascript" src="http://smartken.github.io/cdn/knockout-3.1.0.js"></script>
       <script type="text/javascript">
              var ViewModel=function(){};
              var vm=new ViewModel();
              $(document).ready(function(){
                      ko.applyBindings(vm);
               });   // $(document).ready
       </script>
   </head>
   <body></body>
</html>

jquery + jeasyui

<!DOCTYPE html>
<html>
   <head>
       <meta charset="UTF-8" />
       <link rel="stylesheet" href="http://smartken.github.io/cdn/jquery-easyui-1.3.5/themes/default/jquery.easyui.min.css" />
       <link rel="stylesheet" href="http://smartken.github.io/cdn/jquery-easyui-1.3.5/themes/icon.css" />
       <script type="text/javascript" src="http://code.jquery.com/jquery-1.11.0.min.js"></script>
       <script type="text/javascript" src="http://smartken.github.io/cdn/jquery-easyui-1.3.5/jquery.easyui.min.js"></script>
       <script type="text/javascript">
              $(document).ready(function(){

               });   // $(document).ready
       </script>
   </head>
   <body class="easyui-layout"></body>
</html>

jquery + d3

<!DOCTYPE html>
<html>
   <head>
       <meta charset="UTF-8" />
       <script type="text/javascript" src="http://code.jquery.com/jquery-1.11.0.min.js"></script>
       <script type="text/javascript" src="http://smartken.github.io/cdn/d3.v3.js"></script>
       <script type="text/javascript">

              $(document).ready(function(){

               });   // $(document).ready
       </script>
   </head>
   <body></body>
</html>

jquery + three.js

<!DOCTYPE html>
<html>
   <head>
       <meta charset="UTF-8" />
       <script type="text/javascript" src="http://code.jquery.com/jquery-1.11.0.min.js"></script>
       <script type="text/javascript" src="http://smartken.github.io/cdn/three.min.js"></script>
       <script type="text/javascript">

             var renderer,scene,camera;

              $(document).ready(function(){
                      init();
               });   // $(document).ready

            function init() {
                var renderer = new THREE.WebGLRenderer({
                    canvas: document.getElementById('mainCanvas')
                });
                renderer.setClearColor(0x000000); // black

                scene = new THREE.Scene();

                camera = new THREE.PerspectiveCamera(45, 4 / 3, 1, 1000);
                camera.position.set(0, 0, 5);
                camera.lookAt(new THREE.Vector3(0, 0, 0));
                scene.add(camera);

                renderer.render(scene, camera);
            }
       </script>
   </head>
   <body>
      <canvas id="mainCanvas" width="400px" height="300px" ></canvas>
   </body>
</html>

jeasyui design online

jquery easyui design 简易在线代码生成器，适合新手使用, 最新支持1.3.5

for 1.3.5

设计之道 : sql to datagrid通用控制器模型

如何高效开发出datagrid数据源，实现输出分页的 json，excel和无分页的 remind

ccflow工作流引擎集成

奋战了一个礼拜，今天算是完成了ccflow在asp.mvc上面的封装整合，主要成果包括

通用sdk控制器,支持集成或直接调用
通用ext流程panel和toolbar
增加一种通用sdk表单模式：通用页面+注入式分部视图
由于还没搞懂ccflow怎样保存流程变量，直接先弄了个简单的序列化保存方式

后续工作还有：

继续搞懂ccflow的工作原理
完成各种流程列表的集成，如待办，挂起，抄送
继续增加流程处理页面的用户体验
尽量抽象化，最好要连白痴也会用的程度
写文档，开源。。。。。。

本周金句：
不是自己选的路，基本上都是错的

使用赵达大哥的spring博客可快速将任意一个repository变成一个博客，果然牛x。但如果需要在多个repository之间切换并实现各自的样式和行为，难道要为每个repository创建一个页面？ no，程序猿不干这傻事，小弟不才，想到一个不错方案，只需在repository的master根目录下放置spring.css和spring.js两个文件既可以实现自定义样式和行为，简单说说原理吧。

    var site_raw_root="http://rawgithub.com/"+owner+"/"+repo+"/master";
    var site_style_href=site_raw_root+"/spring.css";
    var site_script_src=site_raw_root+"/spring.js";
    document.write("<link rel='stylesheet'  href='"+site_style_href+"'  />");
    document.write("<script  type='text/javascript' src='"+site_script_src+"' ><"+"/script>");

一看就知道，其实就是根据owner和repo组装出repository的raw根路径site_raw_root，找到根路径后找资源就不难，为了尊重作者，所以两个文件分别以spring.js和spring.css命名，然后输出到页面就o了

smartken.github.io
blog repository

kicking ass 20140412

阿里云新增了一个php web shell接口
完成ccflow通用datatable控制器
使用全盲模式练习WRC04
webshell还没运行成功，老是报EOF，考虑用另一种方案替代
R和python又停滞了，发现很多资料都没时间看
韩语开始有点语感，后续要加强练习

脑图更新

当前脑图的规模，貌似已经超出地球人所能承受的程度。。。。

我的测试

我的测试，随便写啊

脑图更新--无法阻挡的步伐

本周金句

通往成功的路只有两条路，一是做别人做不到的事情，二是做别人不想做的事情

**城市选择控件

3年前做网站时用过的一个**城市选择控件，用户体验不错

纯js实现，无数据库依赖
支持中文和拼音的模糊搜索

html

<div id="inputCityPicker0" ></div>

    var cityPicker0;

    //必须在页面加载完后执行
     function onLoad(){

       cityPicker0=new CityPicker({
          inputName:"cp",
          layid: "inputCityPicker0"
       });
       cityPicker0.begin();

     }

example

消费者承担消费税真的吃亏了吗？

与众多其他市场一样，冰淇淋市场的需求曲线与供给曲线的走向是正好相反的。当冰淇淋的价格增加时，越来越多的消费者觉得吃冰淇淋的享受不值这么多钱，从而退出了消费市场，于是市场的总需求量越来越低。反之，冰淇淋的价格越低，能够提供冰淇淋的生产商也越少，因为越来越多的卖者认为他们没有赚头，从而退出市场竞争。两条曲线有一个交点，这个交点叫做市场均衡。对应的价格叫做市场均衡价格，对应的数量则叫做均衡数量（见图1）。在均衡价格下，买者的需求与卖者的供给数量正好相当，市场上的每个人都得到了满足。若市场价不等于均衡价格时，供给数量和需求数量将不再平衡；供不应求将导致价格上涨，供大于求则导致价格下跌，最终还是会自发地调整到均衡价格。

图　1

现在呢，有趣的事情发生了。假设有一个地方具有相当浓厚的冰淇淋文化，该地政府打算举办一个年度冰淇淋节。为了筹到这项活动的经费，政府决定：卖方每卖出一个冰淇淋，政府就向卖者征收0.5美元的税。于是，各大冰淇淋制造商上街游行，宣称这个税应该由买者支付。而消费者协会则声援政府，坚持认为这部分税应该由冰淇淋生产商支付。两大游说集团吵成一团。为此，我们不妨仔细研究一下，如果这部分税由消费者来承担的话，会发生什么奇特的事情。

假设政府向消费者征税。消费者自然会觉得自己亏大了：每买一个冰淇淋还要多付0.5美元。消费者并不关心市场价格，只关心自己的实际支出，因此，如果原本我能接受2美元的冰淇淋，现在我只愿意接受1.5美元的了，因为我还得额外支付0.5美元的税。换句话说，需求曲线向下移动了0.5个单位（见图2）。新的需求曲线与供给曲线产生了新的交点，市场的均衡数量变少了，市场均衡价格也降低了。假如说，没有征税时市场均衡价格为3.0美元，现在的市场均衡价格为2.8美元。但消费者要交0.5美元的税，因此消费者支付的实际价格是3.3美元。我们可以看到，政府若向消费者征税，则卖方损失了0.2美元的收益，买方则多付出了0.3美元。这0.5美元的税实际上是由双方共同承担的。究竟哪一边分担得多些是由两条线的斜率决定的。

图　2

20世纪美国曾经大规模地向消费者征收奢侈品消费税。因为政府觉得，买奢侈品的都是富人，因此对奢侈品征收消费税其实是非常巧妙地变相向富人多征一些税。殊不知，奢侈品不是生活必需品，只要价格抬高一点，便有大量的消费者退出市场，反正有的是地方花钱，买点房子啊，出去旅游啊，要实在得多。反过来，奢侈品的供给曲线则非常地陡，即使价格变化很大，产量变化仍然不大，毕竟生产制造奢侈品需要用很多时间、人力和设施，这些既定因素使得生产商无法快速应对市场需求变化。可见，需求曲线比供给曲线要“平”得多。结果呢，明明是向买方征税，税反而几乎都由生产者承担；而这些生产者并不是富人，奢侈品税的重担落在了中产阶级身上。政府的决策适得其反。

别着急，冰淇淋的故事还没讲完呢。我们再来看看，如果果真向生产商征税，结果又如何呢？显然，生产者必然会觉得自己亏了，原本可以卖2美元，现在卖了后只能得1.5美元了。因此，为了弥补这0.5美元的损失，卖方只接受比原来高0.5美元的市场价格。其结果是，供给曲线上升了0.5个单位（见图3），从而使得市场均衡价格从3.0美元增加到了3.3美元。但这3.3美元并不全部归卖方，卖方要交给政府0.5美元的税，因此事实上卖方只能得到2.8美元。结果呢，向生产者征税的效果与向消费者征税的效果完全一样。

图　3

搞了半天，最开始两边在那里拼了命地争论，结果却完全没有必要——不管向谁征税，结果都是一样的。

让你立刻爱上数学的8个算术游戏

数字黑洞

任意选一个四位数（数字不能全相同），把所有数字从大到小排列，再把所有数字从小到大排列，用前者减去后者得到一个新的数。重复对新得到的数进行上述操作，7步以内必然会得到6174。例如，选择四位数8080：
8800-0088=8712
8721-1278=7443
7443-3447=3996
9963-3699=6264
6642-2466=4176
7641-1467=6174
……

6174这个“黑洞”就叫做卡布列克（Kaprekar）常数。对于三位数，也有一个数字黑洞，即495。

特殊乘法的速算

如果两个两位数的十位数相同，个位数相加为10，那么你可以立即说出这两个数的乘积。如果把这两个数分别写作AB和AC，那么它们的乘积的前两位就是 A 和 A+1 的乘积，后两位就是B和C的乘积。

比如，47和43的十位数相同，个位数之和为10，因而它们乘积的前两位就是4_(4+1)=20，后两位就是7_3=21。也就是说，47*43=2021。

类似地，61_69=4209，86_84=7224，35*35=1225，等等。

这个速算方法背后的原因是，(10x+y)(10x+(10-y))=100x(x+1)+y(10-y) 对任意 x 和 y 都成立。

翻倍，再翻倍！

将123 456 789翻倍，你会发现结果仍然是这9个数字的一个排列：

123 456 789 * 2=246 913 578

我们再次将246913578翻倍，发现：

246 913 578 * 2 = 493 827 156

结果依旧使用了每个数字各一次。这仅仅是一个巧合吗？我们继续翻倍：

493 827 156 * 2 = 987 654 321

神奇啊，一个很有特点的数987 654 312，显然每个数字又只用了一次。

你或许会想，这下到头了吧，再翻倍就成10位数了。不过，请看：

987 654 321 * 2 =1 975 308 624

又使用了每个数字各一次，只不过这一次加上了数字0。再来？

1 975 308 624 * 2 = 3 950 617 248

恐怖了，又是每个数字各出现一次。

出现了这么多巧合之后我们开始怀疑，这并不是什么巧合，一定有什么简单的方法可以解释这种现象的。

但是，下面的事实让这个问题更加复杂了。到了第6次后，虽然仍然是10位数，但偏偏就在这时发生了意外：

3 950 617 248 * 2 = 7 901 234 496

看来，寻找一个合理的解释，并不是一件轻而易举的事情。

唯一的解

经典数字谜题：用1到9组成一个九位数，使得这个数的第一位能被1整除，前两位组成的两位数能被2整除，前三位组成的三位数能被3整除，以此类推，一直到整个九位数能被9整除。

没错，真的有这样猛的数：381 654 729。其中3能被1整除，38能被2整除，381能被3整除，一直到整个数能被9整除。这个数既可以用整除的性质一步步推出来，也可以利用计算机编程找到。

另一个有趣的事实是，在所有由1到9所组成的362 880个不同的九位数中， 381 654 729是唯一一个满足要求的数！

幻方之幻

一个“三阶幻方”是指把数字1到9填入的方格，使得每一行、每一列以及两条对角线的3个数之和正好都相同。图1就是一个三阶幻方，每条直线上的3个数之和都等于15。

图　1

大家或许都听说过幻方这东西，但是并不知道幻方中的一些美妙的性质。例如，任意一个三阶幻方都满足，各行所组成的三位数的平方和，等于各行逆序所组成的三位数的平方和。对于上图中的三阶幻方，就有

816^2 + 357^2 + 492^2 =618^2 + 753^2 + 294^2

利用线性代数，我们可以证明这个结论。

天然形成的幻方

从1/19到18/19这18个分数的小数循环节长度都是18。像图2那样把这18个循环节排成一个的数字阵，这将恰好构成一个幻方——每一行、每一列和两条对角线上的数字之和都是81。①

① 严格意义上说它不算幻方，因为方阵中有相同的数字。

图　2

一个小魔术

在一张纸上并排画11个小方格，叫你的好朋友背对着你（让你看不到他在纸上写什么），在前两个方格中随便填两个1到10之间的数。从第3个方格开始，在每个方格里填入前两个方格里的数之和。让你的朋友一直算出第10个方格里的数。假如你的朋友一开始填入方格的数是7和3，那么前10个方格里的数分别是：

7 3 10 13 23 36 59 95 154 249
现在，叫你的朋友报出第10个方格里的数，稍作计算你便能猜出第11个方格里的数应该是多少。你的朋友会非常惊奇地发现，把第11个方格里的数计算出来，所得的结果与你的预测一模一样！

其实，仅凭借第10个数来推测第11个数的方法非常简单，你需要做的仅仅是把第10个数乘以1.618，得到的乘积就是第11个数了。在上面的例子中，由于，因此你可以胸有成竹地断定，第11个数就是403。而事实上，154与249相加真的就等于403。

其实，不管最初两个数是什么，按照这种方式加下去，相邻两数之比总会越来越趋近于1.618——这个数正是传说中的“黄金分割”。

3个神奇的分数

1/49化成小数后等于0.0204081632…，把小数点后的数字两位两位断开，前五个数依次是2、4、8、16、32，每个数正好都是前一个数的两倍。

100/9899等于0.01010203050813213455…，两位两位断开后，得到的正好是著名的斐波那契（Fibonacci）数列1, 1, 2, 3, 5, 8, 13, 21, … ，数列中的每一个项都是它前面两个项之和。

而100/9801则等于0.0102030405060708091011121314151617181920212223…。

利用组合数学中的“生成函数”可以完美地解释这些现象产生的原因。

开源**maven库备忘

去年把kull开发手脚架放到了开源**maven库来管理，时间久了差点忘记了，在这里先做个备忘，访问http://maven.oschina.net,搜索kull即可，见图

 maven配置，如果你不知道maven是什么，请直接忽略本文

找东西背后的概率问题

各种违反常理的错觉图片和数学事实告诉我们，直觉并不可靠。其实这本身就是一种错觉，它让我们觉得直觉总是不可信的。而事实上，多数情况下直觉都是可信的，前一节的故事便是一例。我们来看另外一个有趣的例子。

我的书桌有8个抽屉，分别用数字1到8编号。每次拿到一份文件后，我都会把这份文件随机地放在某一个抽屉中。但我非常粗心，有 1/5的概率会忘了把文件放进抽屉里，最终把这个文件搞丢。

现在，我要找一份非常重要的文件。我将按顺序打开每一个抽屉，直到找到这份文件为止（或者很悲剧地发现，翻遍了所有抽屉都没能找到这份文件）。考虑下面三个问题。

假如我打开了第一个抽屉，发现里面没有我要的文件。这份文件在其余7个抽屉里的概率是多少？
假如我翻遍了前4个抽屉，里面都没有我要的文件。这份文件在剩下的4个抽屉里的概率是多少？
假如我翻遍了前7个抽屉，里面都没有我要的文件。这份文件在最后一个抽屉里的概率是多少？

继续往下看之前，大家不妨先猜一猜，这三个概率值是越来越大还是越来越小？

事实上，三个概率值分别是7/9、2/3 和3/1。可能这有点出人意料，这个概率在不断地减小。但设身处地地想一下，这也不是没有道理的。这正反映了我们实际生活中的心理状态，与我们的直觉完全相符：假如我肯定我的文件没搞丢，每次发现抽屉里没有我要的东西时，我都会更加坚信它在剩下的抽屉里；但如果我的文件有可能搞丢了，那每翻过一个抽屉但没找到文件时，我都会更加慌张。我会越来越担心，感到希望越来越渺茫，直到自己面对着第8个抽屉，忐忑地怀着最后一丝希望，同时心里想：完了，这下可能是真丢了。

有一个非常巧妙的方法可以算出上面三个概率值来。

注意到，平均每10份文件就有两份被搞丢，其余8份平均地分给了8个抽屉。假如我把所有搞丢了的文件都找了回来，那么它们应该还占2个抽屉。这让我们想到了这样一个有趣的思路：在这8个抽屉后加上2个虚拟抽屉──抽屉9和抽屉10，这两个抽屉专门用来装我丢掉的文件。我们甚至可以把题目等价地变为：随机把文件放在10个抽屉里，但找文件时不允许打开最后2个抽屉。当我已经找过个抽屉但仍没找到我想要的文件时，文件只能在剩下的个抽屉里，但我只能打开剩下的个抽屉

因此所求的概率是(8-n)/(10-n)。当分别等于1、4、7时，这个概率值分别是7/9、2/3和1/3。如果把(8-n)/(10-n)写成1-2/(10-n)，就很容易看出，当0<=n<=8时，它是一个递减函数。

趣味数学：丢蕃图的寿命

丢番图（Diophantus）是古希腊亚历山大学后期的重要学者和数学家，他的墓上有道经典数学题：

行人啊，请稍驻足，这里埋葬着丢番图。上帝赋予他一生的六分之一，享受童年的幸福；再过十二分之一，两颊长胡；又过了七分之一，燃起结婚的蜡烛。爱子的降生盼了五年之久，可怜那迟来的儿郞啊，只活到父亲岁数的一半，便进入冰冷的坟墓。悲伤只有通过数学来消除，四年后，他自己也走完了人生旅途。

问题：丢番图的寿命是多少？

正统代数方程解法，假设丢番图的寿命为x

(1÷6)x+(1÷12)x+(1÷7)x+5+(1÷2)x+4=x
计算过程省略......    
x=84

所以，丢番图的童年时光是14年，7年后他长大成人。又过了12年，在33岁的时候，他结了婚，5年后有了儿子。儿子死于42岁，丢番图当时80岁，4年后丢番图去世。

简易非主流推算法

思考一下题目的成立的最基本条件：就是丢番图的寿命至少能被12和7整除，简单求出12和7的最小公约数84，再按照人类正常寿命估算（古时代人有84岁已经很牛x了），所以照样可以推算出丢番图的寿命为84，是不是很简单呢？

本周金句

 想要成为伯乐，首先要让自己成为一匹千里马

mongo伪集群启动脚本

拓步架构： 2（主+备）+ 3（配置）+1（代理）=8
注意先配置好MONGO_HOME路径，所有脚本请放在同一个目录
servers-start.bat(启动所有服务器，人品没问题的话会很顺利的)

set cdir=%cd%

md data-0-master
md data-0-slave
md data-1-master
md data-1-slave
md config-0
md config-1
md config-2
md log

start %MONGO_HOME%/bin/mongod --dbpath "%cdir%\data-0-master" --port 20010 --logpath "%cdir%\log\data-0-master.log"  --master

start %MONGO_HOME%/bin/mongod --dbpath "%cdir%\data-0-slave" --port 20011 --logpath "%cdir%\log\data-0-slave.log"  --slave --source "localhost:20010"

start %MONGO_HOME%/bin/mongod --dbpath "%cdir%\data-1-master" --port 20020 --logpath "%cdir%\log\data-1-master.log"  --master

start %MONGO_HOME%/bin/mongod --dbpath "%cdir%\data-1-slave" --port 20021 --logpath "%cdir%\log\data-1-slave.log"  --slave --source "localhost:20020"



start %MONGO_HOME%/bin/mongod --dbpath "%cdir%\config-0" --port 20000 --logpath "%cdir%\log\config-0.log"

start %MONGO_HOME%/bin/mongod --dbpath "%cdir%\config-1" --port 20001 --logpath "%cdir%\log\config-1.log" 

start %MONGO_HOME%/bin/mongod --dbpath "%cdir%\config-2" --port 20002 --logpath "%cdir%\log\config-2.log" 

start %MONGO_HOME%/bin/mongos --configdb localhost:20000,localhost:20001,localhost:20002

servers-stop.bat（这么多服务器，总得有个批量关闭的脚本吧）

set cdir=%cd%
%MONGO_HOME%/bin/mongo  localhost:20010/admin  %cdir%/stop.js
 %MONGO_HOME%/bin/mongo localhost:20020/admin %cdir%/stop.js
 %MONGO_HOME%/bin/mongo localhost:20030/admin %cdir%/stop.js
 %MONGO_HOME%/bin/mongo localhost:20000/admin %cdir%/stop.js
 %MONGO_HOME%/bin/mongo localhost:20001/admin %cdir%/stop.js
 %MONGO_HOME%/bin/mongo localhost:20002/admin %cdir%/stop.js
 %MONGO_HOME%/bin/mongo localhost:20011/admin %cdir%/stop.js
 %MONGO_HOME%/bin/mongo localhost:20021/admin %cdir%/stop.js
 %MONGO_HOME%/bin/mongo localhost:20031/admin %cdir%/stop.js

stop.js

db.shutdownServer()

可能与不可能的边界：P/NP 问题

一个糖果厂老板决定推出一个活动，将五张金券藏到巧克力的包装里，而这种巧克力每年的产量数以千万计。找到金券的人将得到一次珍贵的参观工厂的机会。

如何找到这些金券？你可以买尽可能多的巧克力。你可能会试试用磁铁，可惜金没有磁性。或者你可以雇用数千人，让他们每人筛查一小堆巧克力。这听起来很傻，但是小姑娘维露卡·索尔特就要这么做，因为她特别想得到一张金券，去参观威利·旺卡的巧克力工厂。

维露卡的父亲索尔特先生是个富商，他决定买光他能找到的巧克力。这还不够，就算有堆积如山的巧克力，要从中找到小小的金券也很困难。索尔特先生也有一家工厂，他不惜动用工厂的工人，终于找到了一张金券。他对记者讲述了找到金券的过程：

我是做花生生意的，知道吧，我有大约100个女工为我剥花生，然后将它们做成烤花生米和腌花生米。她们整天就坐在那儿剥花生。所以我跟她们说：“好了姑娘们，不要剥花生了，大家开始给我剥这些破糖纸吧！”然后她们就剥。我让工厂的每一个工人都铆足了劲地撕掉巧克力的包装纸，从早干到晚。

但是三天过去了，我们还是没走运。哦，那可真够呛！我可怜的小维露卡越来越暴躁，每次我一回家她就朝我嚷嚷：“我的金券在哪儿？我要我的金券！”她撒泼又打滚儿，踢腿又叫喊，实在招人烦。我可不希望看到我的小宝贝这么不高兴，所以我决定一直找，不找到她要的东西誓不罢休。终于，在第四天的晚上，一个女工大叫：“我找到金券了！”然后我说：“把它给我，快！”她给了我，然后我跑着回家把它交给了亲爱的维露卡，她高兴得合不拢嘴。我们家又变得其乐融融了。

和索尔特先生一样，无论你打算怎么找那张金券，你都需要大量时间、金钱，或者运气。也许有一天，有人能发明出一个快速找到金券的便宜装置，也许这样的装置并不存在。

然而，1000万对于今天的计算机来说只是很小的数字。如果你把糖果数字化，录入一个数据库，现在的电脑只用不到一秒就能把它找一遍。虽然计算机比人快得多，但它面对的问题的规模也比在糖果里找金券大得多。

现在最大的电子数据集合规模有多大？比如，整个互联网，考虑到所有视频、音频、电子邮件及其他一切，总的信息量差不多有1 000 000 000 000 000 000字节，最多相差几个0。一个字节大致对应键盘上的一个字符。这个数很大，但记住，计算机也很快。一般的笔记本电脑每秒可以执行1万亿次操作，这样算来，理论上只需要不到4个月就能搜完整个互联网的内容，前提是你能把整个互联网装到你电脑的内存里。Google每时每刻都在搜索整个互联网，它使用了几十万台快速的计算机。

如果计算机可以很快地搜遍整个互联网，看起来好像我们就解决了这个找金券问题的电子版。但是，计算机不仅要帮人们搜索已有的数据，还要搜索问题的所有可能解。

认识一下可怜的旅行推销员Mary，她来自华盛顿特区，为美国木槌集团公司工作。她需要从家乡旅行到48个州的首府，向各州法院推销木槌。木槌公司为了削减成本，让Mary找到通过所有城市的最短路径。Mary画了一张图，写写画画了一会儿，制订了一个不错的路线。

图1-1　旅行推销员问题的地图

1 1英里约合1.609千米。——编者注

差旅部门的人想让Mary试试能否找到另一条路线，把路程缩短到11 000英里以下。Mary写了个计算机程序，试图穷举所有可能的路线，找出最短的一条，但是一周以后，程序还没跑完。Mary坐下来开始算数。作为第一站的城市有48种选择，然后从剩下的47个城市中选一个作为第二站，再从剩下的46个城市中选一个，以此类推。可能的路径共有48×47×46×…×2×1种，也就是下面这个62位数：

12 413 915 592 536 072 670 862 289 047 373 375 038 521 486 354 677 760 000 000 000

即使计算机计算一条路线的时间等于光通过最小的原子直径的时间（大约0.000 000 000 000 000 000 33秒），仍然需要十亿亿亿倍于宇宙年龄的时间才能算完。难怪Mary的电脑算了一周还没有完。Mary想知道有没有比穷举更好的方法找到最佳路线，就像在所有可能行程的“巧克力山”里面刨出那张小小的金券。

P/NP问题讨论的是以上所述的所有问题，以及许多与之类似的问题。它们归根到底都是在问：我们搜索大量可能性的速度能有多快？我们找到“金券”（即最佳答案）的过程能变得多容易？

P/NP问题是库尔特·哥德尔在1956年寄给约翰·冯·诺依曼的一封信中首次提出的，哥德尔和冯·诺依曼都是20世纪数学界的泰斗。这封信后来不幸遗失，20世纪80年代又被找到。P/NP问题在学术界的亮相是在20世纪70年代初，由斯蒂芬·库克和列昂尼德·莱文独立提出，当时两位所在的国家正在冷战。之后理查德·卡普列出了这个领域中的21个重要难题，包括前面提到的旅行推销员难题和划分难题。计算机科学家从卡普的工作开始认识到P/NP问题极为重要，由此计算机科学研究的方向发生了戏剧性的转变。如今，P/NP问题的关键性作用已经不仅限于计算机科学领域，还延伸到其他许多领域，如生物学、医学、经济学和物理学。

P/NP问题已成为所有数学领域最难的开放问题之一。1994年安德鲁·怀尔斯证明了费马大定理，受这一消息的鼓舞，克雷数学研究所决定举办竞赛，攻克他们认为最为重要而尚未解决的数学难题。2000年，他们列出了下面这7个千禧年难题，并为每道难题的攻破设立了100万美元的奖金。

贝赫和斯维讷通-戴尔猜想（Birch and Swinnerton-Dyer conjecture）
霍奇猜想（Hodge conjecture）
纳维-斯托克斯方程（Navier-Stokes equations）
P/NP问题（P versus NP）
庞加莱猜想（Poincaré conjecture）
黎曼猜想（Riemann hypothesis）
杨-米尔斯理论（Yang-Mills theory）
千禧年难题中的庞加莱猜想已于2003年被格里高利·佩雷尔曼解决，但他拒绝了100万美元的奖金。截至本书写作时其他6个难题都尚未解决。

解决P/NP问题就能拿到100万美元，这可是货真价实的金券啊！

更妙的是，如果你能证明P=NP，那么你也就掌握了找到金券的秘诀，解决其余的千禧年难题将是举手之劳。也就是说，证明了P=NP，你就能解决6道千禧年难题，并得到600万美元。然而证明P=NP或P≠NP可没那么容易。一心想得到600万美元的人最好去玩彩票，那样把握更大一些。

ccflow 二次开发札记 : 01 基本概念+开发思路

小弟入行5年，玩asp也玩了差不多3年，由web form玩到asp mvc,由ado到nhibernate再到linq，总体上也算进步不少，再玩下去就是要玩玩流程引擎了，c#开源的流程引擎不多了，nbpm貌似早以死了，目测只有ccflow这个选择了。目测ccflow属于一种高度抽象和现成的流程框架，非常适合天朝的国情，但是这玩意用起来省力不省心。。。。此话何解，请听小弟一一道说

js处理url工具脚本： js-url

原生js对url的处理能力不足，连获取参数值得方法都没提供，寻寻觅觅，总算找到这个简约优雅的工具脚本
example

url();            // http://rob:[email protected]/path/index.html?query1=test&silly=willy#test=hash&chucky=cheese
url('domain');    // example.com
url('hostname');  // www.example.com
url('sub');       // www
url('.0')         // (an empty string)
url('.1')         // www
url('.2')         // example
url('.-1')        // com
url('auth')       // rob:abcd1234
url('user')       // rob
url('pass')       // abcd1234
url('port');      // 80
url('protocol');  // http
url('path');      // /path/index.html
url('file');      // index.html
url('filename');  // index
url('fileext');   // html
url('1');         // path
url('2');         // index.html
url('3');         // (an empty string)
url('-1');        // index.html
url(1);           // path
url(2);           // index.html
url(-1);          // index.html
url('?');         // query1=test&silly=willy
url('?silly');    // willy
url('?poo');      // null
url('#');         // test=hash&chucky=cheese
url('#chucky');   // cheese
url('#poo');      // null

url('domain', 'test.www.example.com/path/here');            // example.com
url('hostname', 'test.www.example.com/path/here');          // test.www.example.com
url('sub', 'test.www.example.com/path/here');               // test.www
url('protocol', 'www.example.com/path/here');               // http
url('path', 'http://www.example.com:8080/some/path');       // /some/path
url('port', 'http://www.example.com:8080/some/path');       // 8080
url('protocol', 'https://www.example.com:8080/some/path');  // https

cdn:url.min.js
github:websanova/js-url

设计之道：一种介于第二和第三范式的数据表设计假想

首页回顾何为第二范式

ccflow 二次开发札记 : 02 设计dev2interface静态无参封装类

由于流程运行必须依赖统一的url参数，所以只要规定好流程页面url的参数名(必须严格规定大小写) ，就可以为dev2interface封装出静态无参调用方法是，主要是为了防止碎片化，简化实际开发中的流程相关操作。

ccflow集成总结

痛苦奋斗了两个月，总算把ccflow成功集成到项目中，顺便还开发出通用mvc控制器，通用toolbar，抄送，投票控件。。。。已下是在下对ccflow的总结

ccflow的代码写得很烂，基本上有价值就是流程设计器和权限管理，建议不要用它他的表单控制器，自己写 sdk表单更爽
不要完全相信官方文档，要通过实践去理解每个操作的概念，搞不清的就只有跟踪源码咯
流程执行过程中主要有三大基础元素：流程号，节点号，工作号，对于初学者理解起来有点难度，所以做抽象封装时要尽可能把这些元素透明化
ccflow的流程变量保存时是不靠谱的，逼着我要自己做序列化来保存
流程分支判断请尽量用开发者参数来配置，但原来的开发者参数太弱了，逼着在下改了一版，现在灵活多了
不知道到节点的自动执行有什么作用，暂时先用“按上一步执行人选择并自动跳转“来实现，效果还算不错
。。。。。

在这次集成过程中的，没有领导认可，没有经费补助，更没有第三方技术支持，而且花费了不少人力和时间，碰到莫名其妙问题时经常想过放弃，还好最后坚持了下来。一个一年赚几亿的企业，技术部水平低就算了，不招测试人员也可以忍，就连不写文档也就罢了，但连个连个像样的流程引擎都没有是无法接受的。一个程序员至少要掌握一套流程引擎，要不就只能一辈子当码农了

本周今句：

人的进步是必须的，但不是必然的，更不是自然的

sample

test

为什么人们往往不愿意承担风险？

假设现在有两份临时工作供你选择，它们的工作内容都完全相同，只是报酬方式不一样：工作一，有的概率获得500元，有的概率获得1500元；工作二，百分之百地稳拿1000元钱。虽然看上去两种选择的平均收入都一样，但是人们往往更愿意选择后一份工作，尽可能避免前一种工作的风险。为什么面对期望收入相同的事件，人们往往愿意选择风险更小的那一个呢？

关键的原因在于，收入本身并不重要，我们关心的是它能带给我们的好处，或者说它给我们带来的幸福感、满足感。在经济学中，我们用“效用”这个词来表示这种主观上对收益的评估结果。

这里，我们有一个重要的假设：收入的边际效用（收入每增加一个单位所带来的额外效用）是递减的。换句话说，增加同样多的收入，低收入者主观上会感觉自己收益了很多，本来就是高收入的人则觉得这点儿收入算不了什么。人们往往会觉得，收入从100元增加到200元所带来的效用，要远远大于收入从800元增加到900元所带来的效用。因此，如果把个人收入和它给人带来的效用画成一条曲线的话，大致就如图1中的那条曲线。

假如你获得了500元钱，你所得到的效用就用A点来表示；假如你获得了1500元，你所得到的效用就在B点。因此，工作一带给你的平均效用就用A和 B的中点C来表示。但是，如果直接就给你1000元，你将会得到一个大于C的效用D。这表明，直接选择工作二所带来的效用要高于工作一带给你的平均效用，自然人们都会选择工作二了。

因此，经济学中有这样一个定理：如果一个人认为自己收入的边际效用是递减的，那么这个人就是一个风险规避者。对于期望收入相同的两件事来说，他愿意去做风险更小的那一件。

事实上，风险规避者甚至有可能通过减少自己的收入来避免可能的风险。在图2中我们可以看到，如果工作二所提供的稳定收入值高于元，风险规避者就会毫不犹豫地选择工作二，即使它的收入低于工作一的平均收入。也就是说，一个风险规避者愿意花费元钱来避免他可能面对的风险。

本周金句：

人生中最大的风险是逃避风险，真正的失败是害怕失败

linux上R的痛苦升级经历

apt-get的最高R版本只能去到2.4，想要升级到3.03，必须先卸载旧版R

 apt-get remove r-base-core

到官网下载最新deb包，国内感觉是厦门大学的镜像最快，使用gdebi安装即可

gdebi r-base-core_3.0.3-1precise0_amd64.deb 
...

记得重启rstudio，用hist(c(3,232,232))试试，如果有图片输出则表示升级正常

linux 安装最新版R

不要用apt-get下载，那个是旧版的

wget  http://nbcgib.uesc.br/mirrors/cran/src/base/R-3/R-3.0.3.tar.gz

自定义安装必须的

./configure  --enable-R-shlib   --with-cairo --with-libpng --with-jpeglib --with-libtiff
make
make pdf
make info
make install
make install-info
make install-pdf

公用品的悲剧

一个经典的公用品悲剧实例就是过度放牧的问题。同样一块牧场，如果为私人所有，牧场主将会非常合理地规划牧场，让放牧数量达到一个理论上的最优值；但是，如果这是一块公共牧场，则所有人都会争抢放牧，从而导致放牧数量远远大于最优值，最终每个人都得不到什么好处。可能有人会觉得这个现象并不难理解——既然是一块无人管制任人使用的公共牧场，人人都能在这里放牧，过度放牧自然就会不可避免地出现了。但是，仔细一想你会发现这个解释是有问题的：每一个来牧场放牧的人，自己心里也都知道，过度放牧对整个大局是不利的，自己的收益也会随之降低。既然人人都知道过度放牧不好，为什么最后来放牧的人还是越来越多呢？私有牧场和公共牧场的区别到底在哪儿？我们可以借助数学工具来分析这个问题。

为了用数字来说明这一情况，我们首先做一些假设。我们假定牧场只放奶牛，收益也全部来自于牛奶供应。显然，牧场的总收益与放牧数量之间的关系是一个单峰函数——牧场上没有牛时总收益为0，牛的数量超过牧场的最大容量后总收益也为0，在这之间一定存在一个平衡点使得总收益达到最大。为此，我们无妨假设总收益y与放牛数量x满足 y=x(100-x) 的关系，即当牧场上的牛数为0或者为100时整个牧场都不会有任何收益，而x=50 时牧场的总收益将会达到最大。我们再假设，购买一头牛的成本为c，拥有奶牛之后放牧的成本则忽略不计。接下来，我们将求出该牧场在公有和私有两种情况下最终达到的放牧数量，大家将会看到开放牧场后确实将导致放牧数量远远超过最佳水平。

如果这是一块私有牧场，牧场主会选择放多少头牛呢？很多人可能会脱口而出，当然是50头牛，因为x=50 时收益达到最大值。但请注意，牧场主想要最大化的并不是他的收入，而是减去成本后所得的利润 x(100-x)-cx。对这个式子求导，就能得到利润最大化的条件：100-2x-c=0 。解出这个式子中的x，就得到牧场中的最佳牛数 x= (100-c)/2。

从另一个角度来看，上述结论也是很显然的：100-2x 恰好就是 x(100-x) 的导数，是增加第头牛给人带来的收入增加量。如果这个增加量比c大，那么买入一头新的牛显然划算；什么时候这个增加量比c小了，再买牛来放就要亏本了。因此，临界点100-2x=c正好就是牛的数量达到最优的时候。

但是，一旦整个牧场变为公有，上述推理就不对了，因为单个放牧人并不关心整个牧场的利润，只在乎自己的盈亏。为了简便起见，我们假设牧场上有 x 个放牧人，每个人都只放1头牛。那么，牧场的总收入将为x(100-x)，每个人得到的收入为x(100-x)/x=100-x。因此，当牧场上有 x-1 头牛时，对这块蛋糕垂涎已久的人会发现，他作为第 x 个放牧人进入牧场后，能够分得的收入为100-x，只要这个值比 c 大，这样做就是值得的。随着进入牧场的人数增多，新加入的放牧人会发现他所能赚到的越来越少。最终当100-x=c 时，便不会再有人想要进入该牧场了。此时的总体情况惨不忍睹——每个放牧人所得的收入都是 c，可以说是一分钱也赚不到。

为什么同样都是为了自己的利益最大化，公有牧场和私有牧场的差别那么大呢？根本原因就在于，在公有牧场中，每个人都能自由地进出该牧场，每个人都拥有在牧场放牧的权利。只要一个新来的放牧人发现自己有钱赚，他就会选择买牛放牧，而并不关心这样做其实会导致每个已经在牧场上的放牧人都要少赚一些。但是，选择在这里放牧是这个放牧人的权利，原来的放牧人没有理由驱逐他。随着新人不断加入，每个人都会赚得越来越少，最后大家的利润就将趋于0，悲剧也就产生了。

不仅仅是公共牧场，事实上“公用品悲剧”发生在几乎所有的公共资源上。例如，人人都知道污染环境损人损己，最后弄得每个人都活不下去，但为什么大家仍然亡了命似地破坏自然资源呢？原因就在于，对于某一个企业来说，直接排放污水废气给它带来了一个正的收益，但这却给其他的每个企业都造成了损失。每个决定要污染环境的企业都这么想，这样做的人便会越来越多，整个社会的损失也就越来越大。

公用品悲剧还会涉及很多非自然资源的公用品。例如，每个人都知道公交车挤着不舒服，但为什么最终车上还是这么挤呢？这就是因为，对于每个车下面的人来说，只要能上车，他就已经得到了好处，完全无视这一举措会使车上的每个人都受到一点损失。每个车下的人都这样想，悲剧也就发生了。

公用品悲剧的理论还有很多更奇怪的应用。很多时候，交通堵塞的原因是前方路段发生车祸，但事实上前方发生的仅仅是某辆车撞上了护栏，车祸根本没有挡住道路。为什么最终还是堵车了呢？原来，每辆开到车祸现场的车，都会减慢速度看看热闹，甚至停下来掏出手机照下这一“杰作”。这样做虽然满足了自己的好奇心，却让后面的每一辆车都多堵上好几秒。因此大家往往会发现这样一个有趣的现象：车祸越离奇，交通堵塞越厉害。另一个经典而有趣的应用是，为什么在餐桌上，实行AA制的总消费要比某一个人请客的总消费高出许多。原因就在于，在实行AA制后，每个点菜的人都会想，原来需要一百多块钱才能吃到的美味，这次只需要花二三十块钱便能享受到了。这样，虽然自己得到了满足，却让每个人都为你多付了一些钱。

uhealin / asskicker Goto Github PK

asskicker's People

Contributors

Stargazers

Watchers

Forkers

asskicker's Issues

最新觉悟

本周金句

搞了半天，最开始两边在那里拼了命地争论，结果却完全没有必要——不管向谁征税，结果都是一样的。

数字黑洞

特殊乘法的速算

翻倍，再翻倍！

唯一的解

幻方之幻

天然形成的幻方

一个小魔术

3个神奇的分数

因此所求的概率是(8-n)/(10-n)。当分别等于1、4、7时，这个概率值分别是7/9、2/3和1/3。如果把(8-n)/(10-n)写成1-2/(10-n)，就很容易看出，当0<=n<=8时，它是一个递减函数。

本周金句

人的进步是必须的，但不是必然的，更不是自然的

本周金句：

不要用apt-get下载，那个是旧版的

自定义安装必须的

Recommend Projects

Recommend Topics

Recommend Org