blog mail me! feed

悲剧啊!

第一个细菌基因预测程序写完了, 倒是有个巨大的bug,
内存回收那里总是会出错, 而且必然出错在第431个ORF序列, 为什么我就没有对这个数字敏感呢?
这个数字正好是霍乱弧菌小染色体上明确编码蛋白质的基因数…

为了支持多染色体文件的输入, 我改使用了顺序容器托管了染色体序列,
只有一个变量,  用于存储种子ORF数目的, 忘了使它自增, 于是就引起了后来的一系列内存操作越界,
以至于让我花了几个小时几乎崩溃去找到使得内存回收出错的地方…

seedOrfNumber = PickSeedOrfs(pttFile.c_str(), listSeedOrfs, listPutativeOrfs, instances);
改成
 seedOrfNumber += PickSeedOrfs(pttFile.c_str(), listSeedOrfs, listPutativeOrfs, instances);
后, 世界都清净了…

叫你丫的不注意… 悲剧啊! 教训啊! 惨痛的刻骨铭心的教训啊!!

Stage2 开发笔记

Sept 9
完成了基于栈的深度优先目录爬虫原型, 不过在实验爬的过程中, 各种古怪的Exception无数次打断爬虫工作,
这就是错误处理做得烂的恶果啊…

工作最后被打断在对含空格, 尤其是连续空格的文件名处理上, 苦想了半个小时, 也没想好怎么更快的通过split函数处理.

Sept 10
基于正则重写了字符串处理, 结果性能还比该死的split+filter高.
第一次看着爬虫模拟爬行, 处理完了清水河畔的202.115.22.16:21的FTP的所有目录, 接下来开始处理文件.

昨天大概想了下, 对于目录内只有文件而没有子目录的情况, 可以做一个FLAG, 这类的目录可以只判断最后修改时间即可, 没有发生修改则无需再进目录爬内容, 其他的情况都需要执行CWD再爬行.

太阳落山, 实验了下爬出的所有目录的写入数据库, 习惯了数据入库前的数据转义, 找了半天Python里转义与反转义的函数, 后来恍然大悟, 文件名是不可以有这些需要被转义的字符的. XD
想了很久的文件比对列表重建, 后来还是选择了相对容易实现, 和容易比对的平面dict重建.

将所有的目录都放在一个平面的dict中, key是文件夹的path(要不要用path的hash呢?), value是另一个dict, 定义了数据库中对应的唯一ID, 以及一个目录下文件的”files”的dict入口.

Sept 11
完成了对爬虫算法的所有优化, 即本地缓存的构造与文件/文件夹是否更新的检查.
在爬虫完成了首次对FTP仓库的探索后, 之后的每次爬行会进行可能的, 不含推测的最大优化,
这样, 每次的爬行可以避免重复的抓取长时间不会更新的文件.

对于如何在Python和PHP中构建相同的分词体系, 还在考虑中,
原来考虑过在Python里使用pymmseg-cpp, 但是后来担心词库和分词算法的不同, 使PHP和Python下的key不匹配, 结果就是, 搜索失败.

自己现在的想法是做一个scwsd, 即基于scws的守护程序, 监听某个端口完成分词API的执行,
即可做到分词的一致性.
*EDIT* 觉得似乎就在php里完成分词和Xapian Index最简单, 数据库里只需要做一个默认的字段, php每次检查尚未分词的条目进行分词即可 :)

当前还没有考虑好, 对于已删除的文件或文件夹的处理方法,
是建立一张回收表, 还是建立一个”已删除”的字段呢?

Sept 16
添加了对于部分无效目录的判断, 防止在爬行时出现的无效目录导致的无数bug的问题.
另外在些错误自陷时, 将当前的目录移除出缓存, 保证了最后处理”已删除目录和文件”时出现的冲突.

I’m crap.

过了这么久了, 对apply, call, prototype, 以及各种javascript的高级特性还是一团乱麻.
甚至有时连this的域都会考虑错…

我记得大一的时候借到过一本<javascript权威指南>, 当时看的如获至宝, 很受启发,
不过因为该死的不能带电脑的政策, 纸上谈兵很快就忘光了.

写了一年很烂的php, 还是没有用任何的框架,
又写了一年很烂的javascript, 从prototype库切换到了jQuery库, 却觉得对javascript还是陌生.
准备沉下来, 好好的看看javascript, 免得尽管我知道, 程序应该怎么写,
写出来还是一坨坨的crap.

I’m crap, anyway.