bigzhu's Blog

每次我写了新文章,提交以后,都会跳到其他人的blog地址上.

然后给我一个"文件不存在"的错误.

上次是跳到 http://sd44.is-programmer.com/posts/21690

不知道这次会跳到哪里?

咋个就这么难呢?
可以定义这样一个函数:

public function getUpperFun():String
        {
            var str:String=(new Error()).getStackTrace().split("at ")[2].split("[")[0].split("/")[1];
            str = str.replace("()", "");
            return str;
        }

非常bt的用法吧.
而且更bt的是,只能在 debug 的 flash 下用,正常的 flash下 (new Error()).getStackTrace()==null

谁知道有更好的办法不?

最近我们公司的一个"大型"系统上线。
为了图方便,为了与老系统的id区分,直接将这个id由原来的9位升到了12位.

估计经理忘了或者经验不足,通知了客户,并没有通知作下游系统主管的我这边.
自认为很通技术的客户一番测试,给了ok没问题的回复.

于是过了几天,客户发现,与我这边有接口的各种外围统系(主要是银行)无法成功调用了,而且只有这些新统进来的数据无法调,老的数据是ok的.

他们 tpcall 就挂住，而我这边可以看到报错：
 

WSH.708630.1.0: LIBTUX_CAT:6031: ERROR: Unable to pre-process buffer before tranmission.  Error code(12/4114)
WSH.708630.1.0: WSNAT_CAT:1148: ERROR: Processing of message to be sent to client failed
WSH.708630.1.0: WSNAT_CAT:1029: ERROR: Sending of reply message to client failed

奇怪的是，用我们自己的测试 client 来调是正常的。

只能认定是做为银行的调用端有问题，甚至还以为是 txuedo 的 bug 又出现了(确实有这个bug,报错也是一样的).
反复折腾.

最后一一比较新老数据,我终于发现,作为接口传输参数的这个id怎么新的变得这么长. 12 位!!!
蛋疼阿,因为我接手前,脑残的前辈和银行对接口的时候,定义 fml32 将这个 id 用了 long 型.

而同样不靠谱的银行端口,用的是32位的windows来开发的系统.
12位还想塞到 long 里面去? 银行的 tuxedo 那边连 buffer 都收不下来.
而我这边全部是64位的AIX,自然一点问题也没有.

而将接口改为 string 也是不现实的. 一但我这边一改,所有调用端都得动.
先不说一一通知10多家银行和各种接口是否现实, 就算接口改为 string 了,天知道银行自己内部的程序,是否有将这个id取下来,然后拿个 long 型变量的情况.  有些银行连开发人员和源代码都没了.

让他们升级为64位,更不可能了.
最悲剧的是,我们不占理阿,谁让一开始就用 long 来做接口,用 string 不就万事大吉了.你自己拿 long 又去存,存不存得下那是你的问题了.
以后切记凡涉及接口,一律用 string

各大领导开会,讨论,折腾.....
最后一检查9位段的资源,还有几辈子都用不完的资源没用.
解决方案就是改回9位.

数据库里那些已有的 id 也得 update , 系统复杂的模型阿,还有外键约束.....
于是我国庆也得悲剧的加班来写 update 的方案和脚本了

最近系统割接,实在太忙..瞎忙.

今早跟客户电话沟通了一个多小时.

因为老系统有一个很垃圾的特性. 新系统不准备将其兼容过来.

于是就悲剧了!

客户为了数据割接上省事,要求我们按那个特性,将数据弄过来.但是我们设计时候剔除了这种会引起混乱的东西.

系统比以前的要优秀.但是反而被客户责怪.

其实很事情清楚,客户也是为国企打工. 按照目前的数据倒换方式,他就有承担责任的风险. 与其这样,不如按部就班.

烂一些总比有风险来着好.

最好好说歹说,总算安抚下去了.但是割接后,我们得多做很多解释工作.可能到时还得背不少黑锅.

典型的干了吃力不讨好的事情.

看来,不论是在国企,还是我们这种给国企打工的公司. 混日子可能最好的生存方式.

系统勉强过得去就行,烂些都没关系.

所以阿,干啥都行,最好不要干IT,实在是在IT行当了,那也千万不要干工程,能去创业公司最好.

尊敬的客户：

您好！感谢您在卓越亚马逊购物！

非常抱歉，由于我们还没有收到您的订单款项（货到付款订单除外）或由于库存方面的原因，您的订单（订单号：C01-1087048-4796848）中的如下商品没能在预计发货日期内发货。为了让您得到更好的送货服务，我们对您订单商品的发货日期进行了修改，请注意“预计发货日期”栏目内的改动。如有疑问，请参考（帮助中心）。
 亨特, et al "程序员修炼之道:从小工到专家"
   预计发货日期 : 2010年10月14日
   预计到达日期: 2010年10月14日

其它商品将在原预计发货时间发出,有关订单更多详情,请您参考“我的帐户”-“查看最近的订单”。



这叫什么事!
发邮件说有货,可以购买了,也是它.
付款是订货当天(8月 31日)就付了
到现在9月13日..竟然说:由于我们还没有收到您的订单款项（货到付款订单除外）或由于库存方面的原因
那绝对是他库存原因了,但是没有任何一句道歉的话

页面还没初始化完成,就报错:
Error #2032

选择项目->属性->构建路径->框架链接

选择合并到代码中

重新编译,更新,好了

每次在 pl/sql developer 中编辑表,什么都不动,查看sql,就会看到有这一句:

-- Alter table
alter table BBS
  storage
  (
    next 8
  )
;

每次在 pl/sql developer 改了东西,直接应用,报错,也都是因为多了这一句,这是干啥?
难道有爱好要我强制把 storage 改成 8?8啥?单位呢?

看了下,发现问题了.
pl/sql developer 可以选择 storage 的单位,第一个是 Bytes ,然后是 KB,MB .

然后 Bytes 被这个山寨汉化版弄成'字节'了.
结果因为这个'字节'的存在,在 pl/sql developer 中选不到默认值MB,变成了空. 误认为发生了修改,于是生成了修改的sql.

还是用英文版好了.没有这种问题.

网上基本所有文章说到 python 的代码跳转,使用的都是 ctags.
实在是误人子弟.
不是说不可以,但是 ctags 没有区分 python 的 def xx, class xx,from xx import xx 的,人家毕竟是给 c/c++ 用的.
所以如果一个函数在很多地方都 import 了,那么在 vim 中 g 然后 ctrl+] 的时候,你就可以在10多,20多个选项中免费玩玩'大家来找茬'.
可能还得翻几次页,才能找到哪个才是 def.


其实 python 自己就带了生成 tags 的工具.
执行这个命令来生成 tags:

/home/bigzhu/.local/share/Trash/files/Python-2.5.2/Tools/scripts/ptags.py  *.py

同个文件再跳就是这样的:


不是一般的清爽.

刚接触树状查询的时候,总对树状查询中的 prior 很迷惑,其实 prior 用处很简单

决定树的遍历方向

树向父结节点方向生长：

select * from bss_org connect by  bss_org_id= prior bss_parent_org_id start with bss_org_id=876

树向子结点方向生长：

select * from bss_org connect by prior bss_org_id=  bss_parent_org_id start with bss_org_id=1

听一听心情会变好.

也许干程序员的是不是都应该去学学吉他.

弹吉他其实并不比敲键盘难多少,唯手熟尔.