后端

npm国内镜像介绍

镜像使用方法(三种办法任意一种都能解决问题,建议使用第三种,将配置写死,下次用的时候配置还在):

淘宝镜像

1.通过config命令

1
npm config set registry https://registry.npm.taobao.org 
npm info underscore (如果上面配置正确这个命令会有字符串response)

2.命令行指定

1
npm --registry https://registry.npm.taobao.org info underscore

3.编辑 ~/.npmrc 加入下面内容

1
registry = https://registry.npm.taobao.org

GenScript 规则引擎项目

使用开源组件

Drools/Kie Workbench

使用Workbench中的规则文件类型

DRL

主要对运费、用户积分点数使用了该类型

Decision Table

主要对服务价格、周期计算使用了该类型

搭建文档

GenScript SAP项目

项目背景

GenScript是一家做生物的跨国公司,我有幸任职在IT部门担任Java开发工程师(在职),主要负责公司内部的SCM系统的开发及维护,虽然叫SCM,但是个人感觉这个系统就是一个ERP,里面包括了客户管理、物料管理、订单管理、生产管理、库存管理、发货管理、报表和财务等众多模块,由于功能太多,所以使得整个系统非常臃肿,而且由于是跨国公司,系统又没有做分布式部署,使用人群又是在全球各个地方,使得整个系统使用起来很慢,并因为各个站点不同的需求都集中到一个系统中,导致很多逻辑和程序上的Bug,或者因为一个Bug影响到所有站点的用户,非常影响公司内客户的使用体验,有些Bug可能会导致公司同事的日常工作会进行不下去,所以最终领导层决定,将这些模块拆分开,形成了3个订单系统(包括客户管理、订单管理),1个生产系统,2个发货系统,1个物料系统,将库存管理、发货管理以及报表、财务部分都整合进SAP,各个系统之间通过数据库层面同步、WebService传输、RFC/JCO传输等方式进行数据同步,通过这样的拆分达到各个系统因为地理位置进行分布式部署的目的,从而解决前面提到的问题。

JavaScript学习笔记之 斐波那契数列尾调用测试

为了验证JavaScript中尾调用的优点,所以做了计算斐波那契数列的尾调用写法和非尾调用写法的性能对比,结果是惊人的,真是不试不知道,一试吓一跳。

这里我都是循环计算斐波那契数列第1-40位的数值,下面是各个环境的验证结果:
Firefox: 普通写法:1000-1300 ms,尾调用写法:0-2 ms
Chrome: 普通写法:1550-1700 ms,尾调用写法:0-2 ms
IE9: 普通写法:46000+ ms,尾调用写法:0-2 ms

以上只是在我自己电脑上的3种浏览器测试的结果,但是可以看出其巨大的差异,所以多函数嵌套调用以及递归时,尽可能的使用尾调用。测试地址

JavaScript学习笔记之 强大的表达力

自定义方法

1
2
3
4
5
6
7
8
9
Number.prototype.add = function(x) {
return this + x;
};
console.log(8['add'](2));//10
console.log((8).add(2));//10
//第一个点解释为小数点,第二个点解释为点运算符。
console.log(8..add(2));//10
//报错,因为数值后面的点,会被解释为小数点,而不是点运算符。
console.log(8.add(2));//SyntaxError: Unexpected token ILLEGAL

ABAP基础之数据类型

变量定义

1
DATA <f> [<length>] <type> [<value>] [<decimals>]
<f>: 变量名称, 最长30个字符, 不可含有 + . , : ( ) 等字符
<length><type>: 数据型态及长度, 如 LINE(20) TYPE C. MYNAME LIKE SY-UNAME.
<value>: 初值
<decimals>: 小数位数