Kyoto Cabinet支持多种数据存储方式，包括内存型与文件型。

内存型包括ProtoHashDB、ProtoTreeDB、StashDB、CacheDB、GrassDB，文件型包括HashDB、TreeDB、DirDB、ForestDB、TextDB。另外PolyDB可以动态绑定上述各种数据库形式。具体的规格参数以及性能可以参考官方文档http://fallabs.com/kyotocabinet/spex.html#features。

Kyoto Cabinet官方提供了makefile，可以直接在windows平台上编译。但由于使用了ISO C9x的标准，官方默认使用VS2010，如果使用vs2008编译，需要手动修改几个地方：

(1) 补充stdint.h头文件（http://msinttypes.googlecode.com/svn/trunk/stdint.h）

(2) std空间中的unordered_map,hash,regexsmatch等位于std::tr1空间

(3) 修改VCmakefile，

VCPATH = C:\Program Files\Microsoft Visual Studio 9.0\VC
SDKPATH = C:\Program Files\Microsoft SDKs\Windows\v6.0A

性能测试后续再补充。

这是历史上最最难熬的春节。

第一次发觉假期是如此的漫长和如此的难过。

希望一切都快点过去，一切都好起来。

2011年专业技术回顾-Q2

2011年专业技术回顾-Q3

10. 2011年10月

国庆节只休息了3天，4号上班。

10月6日，乔布斯走了，一个传奇。

在9月的时候，有很多的进展。经过了地毯式的测试，有限元这一部分功能基本上完善，也很稳定。后面基本上是专题性质的专项计算的深入调优，包括了施工模拟分析、随机活荷载不利布置分析、局部人防模型分析，整体上不错。

其他的内容大体上有这几个，都做得非常好。

一个是上部结构刚度传递到基础计算中，这一块涉及到上部结构和基础两个模型的计算，我们做得非常巧妙，很智能。上部刚度的凝聚支持动态的凝聚参数判断，对于超大底盘的结构，能动态减少出口数量，在牺牲较小精度的条件下大量减少计算量。 在基础模型计算，也用了了很妙的机制，进行上部刚度矩阵凝聚结果的自动拆分为合适的MATRIX单元。

第二个是有限元程序自动支持进程内计算与子进程计算，可以混用。这样可以隔离一些管理和内存上的问题。两种模式下的进度log，数据管理等都完全不需要变化，这里又再一次很骄傲地受益于精良的程序架构。子进程方式下采用异步的log控制器，而且支持很先进的中断计算。

还有一个，在ICF中增加了一种模式，称为Transaction。 和经典的数据库一致，在开启Transaction后，读写性能会大幅度提高，而且Transaction是自治的，只需要开启关闭，其他的不需要有任何变化。

然后开始进行大规模题目的测试，上限已经达到100w自由度，很领先。

———————————

10月也是一个很好的月份，都很开心。

11. 2011年11月

这个月还是测试，测试，不提。

这个月又被要求加一个新的功能，基础计算中后浇带的模拟计算，很罗嗦。但是我们有先进的储备，死活单元+自动单元分组，很简单的处理就好了，抽象了一个局部模型分析出来，取名PartialModelAnalysis，很稳定。

然后还是继续改进，改进无止境。重构了下命令行参数的解析，定义通用的规则，后面的增加参数也不用逐个解析。

ICF逐渐成为了后处理的瓶颈，查到原因是频繁的缓冲交换，于是增加了一个多并发的Turbo模式，根据系统内存智能适应，效果很好。

目标总是一步一步被提高，从最初的要求能计算30w自由度，逐渐被要求到50w、70w、100w。而且随着多塔的要求，还要适应越来越多的振型。原先的有些设计是针对50w的优化设计，100w再加100个振型是不能承受之重。好在，谁让咱们的设计牛呢。加入内存映射，ICF同步支持，只需要局部的小量代码就可以了。

11月就这么多啰嗦事情。相对前两个月来说，这个月有时候并不是非常开心，难免有些低谷起伏，但是我是小强，我喜欢向前，喜欢努力，加油。

12. 2011年12月

资源是一点一点省出来的，就像钱要开源，更要节流。

除去优化之外，本月逐渐增加竖向地震的计算，这一部分由于以前糟糕的代码，加一点东西都会引入错误和不兼容。找到一个肯动脑筋水平又好的人真的很难很难。

由于Midas building和etabs的特点，本月决定把原计划下一版本的功能提前，就是根据振型参与质量来自动决断振型个数，Midas building的这个功能很赞，于是我们也有了。 ETABS的RITZ向量法在很多情况下会是一个比较好的手段，于是我们有了。

—————-

2011年要结束了，12月开心。

感谢2011。

借用了一下云服务的概念，目前通过服务端的程序为用户提供对应的数据服务。而整个架构是在满足工程计算方面的实际需求，而不进行过度设计。

1. 整体特点

UcoCloud架构如下图所示，主要包括web前端、Master主控服务以及一系列的Worker工作机。

UcoCloud以Master服务为核心，负责任务队列、调度以及Worker的管理，不涉及具体业务。这里的Master服务不同与Gate服务，如果后来业务需要可以增加Gate服务，从而支持多个Master。

Worker承担具体业务，可以不同类型，可以随时增加更多worker来增强计算能力。

Web前端只是一个Master服务交互的界面，与用户进行交互。

必要时可以增加专门的File Server。

2. Master服务

Master服务主要功能有3个，维护Task队列和Worker在线列表，同时负责Task的调度。Master采用简单授权，以JSON格式数据交换；Master建议用Python开发，为有状态服务。

任务队列 /Task 包括以下接口服务：

•Add: 增加任务 (ROLE_USER)

•View: 查看任务 (ROLE_USER)

•Delete: 删除任务 (ROLE_USER)

•List: 任务列表(ROLE_USER)

•Result: 任务结果(ROLE_USER)

•Get: 获取任务(ROLE_WORKER)

•Update: 更新任务(ROLE_WORKER)

Worker列表 /Worker 包括以下接口服务：

•Register : 注册worker(ROLE_WORKER)

•Exit : 退出worker(ROLE_WORKER)

•Check : 心跳消息，获取任务列表

•调度器 /Scheduler

•Update : 调度器更新(如果是有状态服务，应该自起线程自动维护)

关于调度机制：

（主要涉及调度任务的分配、已分配任务的检测和重新分配等，待补充完善）

3. web前端

Web前端为Master服务的前端，Web前端不维护具体数据。Web前端从Master服务获取信息；Web与Master之间使用JSON数据交流。

建议用php开发，但不限制。

对于普通用户，提供以下交互界面：

对于管理员用户：

4. Worker工作机

worker工作机负责具体任务的执行。但是这里的worker只负责与Master的数据沟通和通讯，具体的业务处理由worker调用相关程序执行。

5. 关于Task任务

Task具有以下属性;

工作流程不画图了,简要如下:

6. 关于开发环境

7. 其他

关于授权/Email通知/Log及报表等略.

环境：VS2008 sp1

调试机(A)：win7 32bit         被调试机(B)： xp 32bit

即在B机上运行程序，A机上进行调试。

————————————

最简单的步骤如下：

B机上

(1) B机上的建立一个与A机当前账户相同的用户名，密码相同，管理员权限。

(2) 在B机安装rdbgsetup.exe，位于VS2008安装光盘上，选择对应的OS类型。

(3) 在B机上打开组策略(gpedit.msc)，修改“网络访问：本地账户的共享与安全模式”，选择“经典-本地账户以自己身份验证”

(4) B机上打开Remote Debuging Monitor

A机上

选择Debug-Attach to Process

Qualifier: 通过浏览找到对应B机。

注意

需要注意防火墙要对相关端口放行。 其他的就和本机调试一致。

2011年专业技术回顾-Q2

2011年专业技术回顾-Q3

7. 2011年7月

到了7月份，各种的外部环境开始微妙起来。有限元部分进展尚可，但是整体进度已经是严重地落后于估计。

在五一假期的时候，提到了几个问题。这些问题的恶劣后果还在继续，而且越来越严重。从产品来说，还完全看不到目标。不收敛的迭代，让人心里最最不安。

很多时候抱怨一些技术上的当断不断，但是工作毕竟都要人来做，水平有高有低。公司里缺少整体软件技术上的架构师。各自为政的条件下，还要求产品稳定可靠的话，只能要求大家都是天才。但是很不幸，没有天才。关键岗位的庸才用严重的影响战斗力。时间很值钱很值钱，对于创业型的公司来说，不能尽快拿出可用的产品就是死。以前的种种习惯虽然尽量避免，但是骨子里的东西哪有那么容易改变。

吊车分析还在缓慢缓慢地前进，其他一些也在推进。

既然脑袋是一团浆糊，既然必须有人去做，那就继续浆糊着做吧。

7月底，软件通过了住建部的鉴定。外部的不确定因素都已经扫清，成败与否已经完全取决于自己，取决于产品。但是目前的状况，我坚定地认为，10月1号不可能，2012年的元旦也不可能。

8. 2011年8月

预计8月8号的首场发布会因为各种原因取消。

各种工作还在继续，位移的管理增加了稀疏存储式的映射存储，效果很好。ICF的性能持续进化，很好。

stl中的map在大量应用时是内存的杀手之一。

9. 2011年9月

到了9月份，好像一切都更加忙碌起来了。但是有限元的部分很可控，至少功能和性能上都是稳定收敛逐步改进的，只会越来越好，而不是过山车。

9月份的事情很多，也是很开心的一个月。

9号，在北京进行了首场发布会，挺好的。讲的也很好。

11号，911事件10周年，很多事情值得反思。

12号，中秋节，这一年以来，第一次休了3天。

17号，参加了好友的精彩婚礼。总结了一些道理。凡事都有很多妥协，不管是员工还是老板。不管是工作还是其他。

18号，九一八事变80周年，很多谎言在今天还是继续。

——————-

这个月喝了几次粥，相当的开心。

这个月，开始用qq音乐在晚上加班的时候来听歌。很不错，整理list的过程就很不错。

这个月，加班已久，考虑过走路与健康和心情的问题，多走走路，无论对于身体还是心情都会很好。

这是今年以来最开心的一个月。

后续：

2011年专业技术回顾-Q4

(上接 2011年专业技术回顾-Q1）

4. 2011年4月

到了4月份，有很大一部分工作已经转向了测试和调试。框架的程序计算已经接近完善，剪力墙的工作还剩余几个单元需要处理。作为墙的超级单元凝聚和后续求解的框架已定。

从这一个月开始，犯了一个巨大的错误，确切地说是由于某些妥协带来严重的后果。

曾经不止一次的提起，相对于能力，态度更加重要。如果态度不端正不认真，即使能力再强，都不能做出成果，更何况没有能力。

这个月份，有限元求解核心开始向基础计算软件提供服务，效果不错。

5. 2011年5月

五一假期只休息了一天。

从这个月开始，公司统一的强制性加班。以前周三周五晚上休息，现在没有了。

平淡的工作，开始处理异形柱、地基梁等一些细节问题。

这一个月，终于决心在有限元内部对节点、单元的ID进行内部编码，外部输入的作为Tag存在。这是一个很大的改进，不再对外部编码进行连续性之类的依赖。而且能很好的兼容可以申请专利的节点、单元编码格式。

这个月，工作越来越忙，但是心情不错。

6. 2011年6月

有限元程序已经基本上稳定。这个月开始逐步的解决各种专项计算。最最坑爹的是所谓规定水平力。

其他的活荷载随机不利布置，施工模拟、人防计算等，在死活单元技术的支持下，都不是问题。

——————————-

工作辛苦，但是心情不错。

后续:

2011年专业技术回顾-Q3

2011年专业技术回顾-Q4

今年是历史最最忙碌的一年，接近于1年的6×12小时的工作。有开心也有不开心，但总归算是开心。

这一年的事情很多。

1. 2011年元旦

从这一天开始，从原公司交接完了工作，到了现在的单位，开始了一份充满了艰辛和挑战的工作。

与合得来的一些老朋友一起工作是很愉悦的，对进度也比较乐观。

人员合作上，4-2的的提议被否决。

这一年的事实证明，人员不再多而在精。不能做事情的人员还是需要尽早清理，否则有百害而无一利。

2011.1.8 搬家，结束了上下班1小时多的奔波，每天开始和10号线打交道。

————————-月份分割线—————————–

2. 2011年2月

简短的春节过后，继续紧张的工作。

这一个月的工作中，提出了有限元计算核心中的几个核心概念，很有价值，也很值得欣慰。

（1）单元分组与死活单元
在酝酿和研究Midas Gen后，坚定地提出单元分组的概念，并将死活单元技术作为核心底层支撑技术。阻力很大，被怀疑，所幸在和求解器部分充分沟通后得到共鸣和支持，后续的大量专项计算在这项技术支持下顺理成章的完成。

（2）影子模型的概念
由于10版新规范中要求同时计算折减与不折减，甚至要求计算强制刚性板假定（很坑爹）。于是讨论提出影子模型的概念（Shaddow Model）。影子模型是基本模型在不同场景下的投影，但是逻辑上的一个完整的模型。

——————-小段分割线—————————-

另外有几个程序开发上的基础设施也在这个时候成型，不断获益。

（1）ICF存储
数据存储采用专门设计带索引的二进制数据块文件，我称之为Indexed Chunk File，简称ICF。ICF作为数据存取的唯一管理者。在宣传材料，称为为异构模型数据库。ICF工作在后台，但是丰功伟绩。

（2）统一的log机制
这是每个软件都应该具备的基础设施，但是在这里没有。在有限元核心程序开发开始的第一天，就建立了单件式的log机制，采用观察者模式进行log分发。所以后续不管是控制台输出还是log到文件，还是再后来图形界面上的异步log输出，都只需要注册一个log handle。

（3）健全的资源监控机制

作为有限元分析核心，系统资源是最大的性能瓶颈。所以在一开始就建立了完善的资源监控，可以随时向log中输出当前资源状态和变化，后续调优中基本上完全依靠这一基础设施。

——————-小段分割线—————————-

还有一个被否决的提议，既然已经是被否决的提议，则可以多说几句。

对软件正确性的验证需要和其他几款软件结果进行对比，而对比的自动化程度则完全决定的对比的可行性。因此提出做一个小工具，与对比内容无关的对比程序，通过对比内容描述文件和内容数据进行第三方的对比。

做完了协议描述和实现规格，但是被否，很遗憾。

后来的后来，有了一个基于文本的对比程序，还好。有总比没有好，而且为什么没能更好呢。

还有几个被否决的提议，比较敏感，略过。

————————-月份分割线—————————–

3. 2011年3月

当年在第一份工作的时候，为陈旧的软件开发过程中引入了3个工具，分别是svn、bugfree和wiki。公司尝到甜头后成为了宝贝。

这个月份里面，首先建立了远程的svn代码库，后来为了方便和安全性，建立的svn的二级服务体系，包括局域网内的svn server和远程的svn server，rsync定期增量同步，很方便。

然后继续引入了bugfree，当然现在叫禅道了。

然后为禅道写了一个WorkDiary的模块，工作日志，现在或许是禅道里应用最多的一个功能。

——————————

在做墙柱墙梁内力合并的时候，提出了一个完善的方案，就是在世界坐标系进所谓的合并来解决各分肢的方向等问题，简单而且唯一。 但是遇到了相当相当大的阻力，相当的意外。 这个工作是纯数学的转换，不涉及任何的经验处理和调整。可能是不信任、不自信或者对某些软件的迷信，导致对一切新方案的抵制。 6个月以后，还是最终朝这个简单的天经地义的方案。

—————————–

在这个月，对MPC的应用也在艰难推进。

—————————-

不了解先进的技术并不可怕，可怕的是对先进技术的夜郎自大。

后续：

2011年专业技术回顾-Q2

2011年专业技术回顾-Q3

2011年专业技术回顾-Q4

——————无聊分割线————————-

一直对python很钟情，不过最近很少用，能记得比较完整的程序就是“用Python做了个Spider”，当时在一个Linode的VPS上跑了几个月。最近处理数据时候又重新用python来做，做完之后还是继续感慨它的便利性。

用python的一个最大的优点就是可以快速的迭代式开发，不断的重构，这一点在这次体会尤深。

其中有几次跳跃式的重构如下：

第一次的重构在书写了几个数据段的解析函数之后，决定定制一个规则，然后通过解析规则来处理各种字段。于是有了一个大约20条记录的标签库（后来再加一个文件解析的时候又增加了6行），然后就处理了近30种数据段，而且可以很方便的定制扩充。

第二次重构在输出报告的完成了一个数据段的汇总后，抽象出了一个Report类，完全控制报告的输出。也就有了后来用css+html的报告时候的顺理成章。

另外一次不大的重构，在于利用的简化的有限状态自动机的思想来处理各种特殊情况。当然只是思想而不是一个完整的自动机。 这一条在N年前给sudidi同学的abaqus数据文件提取工具中就大体考虑过，可以说轻车熟路。

后来用配置文件来设置参数，打包exe。从开始学习到成功，大约花了30分钟，代码10行，我爱python。

除去一些修饰性的代码和css样式表，核心代码不到500行。如果用c++的话，代码量至少要翻2倍，时间2倍不止。

Eclipse+PyDev是目前开发python程序的不二选择，除去log外，一个完善的Debug环境还是很赞的。

——————无聊分割线2——————–

有些东西记下来权当笔记，免得以后再找。

1.  文件路径的相关处理

用 os.path 就完全解决所有问题，包括路径拼接、路径拆分、相对路径提取、文件存在性判断、文件遍历、递归遍历等等。相关函数有：

os.path.join

os.path.basename

os.path.exists

os.makedirs

os.path.isdir

os.path.splitext

2. 文件的遍历

目录下的文件遍历有两种，一种是os.listdir，一种是用os.walk。如果需要递归，则后者更为方便。

   1: files = os.listdir(proj_dir)

   2: for f in files:

   3:     filepath = os.path.join(proj_dir,f)

   4:     if os.path.isdir(filepath): continue

   5:     if f.find('----')>-1:

   6:         shutil.copy(filepath, self.REPORT_DETAIL_DIR)

使用os.walk则很容易进行遍历：

   1: for root,dirs,files in os.walk(proj_list_dir, True):

   2:     for f in files:

   3:         pass

3. 文件的复制

对于文件、文件夹、目录树的拷贝删除可以使用shutil相关函数，注意有些条件，比如目标目录不能存在之类。

shutil.copytree

shutil.rmtree

shutil.copy

4. 乱码

如果能用utf-8统一处理是最好，但是如果在window下面，并且和平常文件打交道多的话，可能也需要其他编码。这时候需要注意系统的编码格式。下面这段代码有帮助。

   1: default_encoding = 'gbk'

   2: if sys.getdefaultencoding() != default_encoding:

   3:     reload(sys)

   4:     sys.setdefaultencoding(default_encoding)

5. 配置文件的读写

python内置了ConfigParser，一般的用途足够了。简洁好用。

6. 打包成exe

有时候为了部署方便，而且windows上默认也不会装python，所以打包成一个独立的exe还是相当有吸引力。以前的py2exe已经不维护了，不过现在有更简单的 pyinstaller (www.pyinstaller.org)，使用相当简单，支持各种python版本。

需要留意的是，vc9的crt和upx有冲突，可以取消upx选项。

—————-最后的分割线——————————-

写点喜欢的东西还是很高兴,能提高工作效率,从最枯燥无聊的数据工作中解脱出来更高兴.

人生苦短,有限的时间应该花在有意义的吃喝玩乐上,呵呵.

最近的情绪日渐低落，对于无休止的加班，忽然想到了一个词，叫“黔驴技穷”。

偶尔的加班或者一段时间的集中加班，可以认为是赶进度保时间节点。但是无休止的没有尽头的加班，只能说明其他方面存在严重问题。

——————

最近有很多牢骚和不满，具体也不方面写在这个公开的地方。但是，缺少管理经验，夜郎自大自以为是，以外行指导内行，必然导致工作量的无限放大。

还很清楚的记得，在五一的时候谈起。缺少整体规划、缺少架构设计、各自为政的原始开发模式会增加至少20%的开发成本（我承认在人面前的这个数字后面实际上还少说了一个0）。

但是有谁真正关心。心情好的时候解释一句现在结构都定下来了，以后版本再考虑改进，不好的时候就哼哼哈哈过去。

在按下葫芦浮起瓢的状态的时候，提出了个完整的解决方案。但是几乎所有人抵制，即便只是几十行代码的事情。这是一种在创业团队里非常腐臭的味道，不是真正的看方案的优劣，而是所谓的面子。

—————–

加班真的只是唯一的选择么？偏离了正确的路线，在努力也只会越走越远。

工作只有火热的心是不行的，已经有一些失望了。

—————-

但是不论如何，先不要让这些影响自己的心情吧。

以前，在黔中道这个地方没有驴，后来有个人用船运来了一头。可是因为没有什么用处，驴就被放养在山脚下。

一只老虎看到这个庞大的动物，很好奇。它慢慢地靠近驴，这时，驴长鸣了一声，老虎非常害怕，不敢再接近。但是在观察了一段时间以后，它发现驴没有什么特殊的本领，于是又开始在驴的周围走动。驴非常愤怒，用蹄子去踢老虎。老虎发现，原来驴的本领就只有这些了，于是就跳起来，咬断了驴的喉咙，把它吃掉了。