Charlie’s path to dEAth

在后台用工具将结构式信息都转换成图片格式（PNG, JPEG等），再将图片上传到网站服务器，用普通的图片显示方式显示出来。需要注意的就是一般的产品目录中，产品数量较大，是用数据库生成的列表，批量生成的图片，就需要用产品编号、CAS编号等相对固定的编码对应起来。

后台生成图片的工具很多，大部分化学信息学软件都可以做得到。但是为了方便批量操作，尽量选择有编程接口的软件，至少也要能够通过命令行调用的软件。

使用在线结构图生成服务

可以利用的服务，我在之前的这篇在线化学结构式图片生成服务中详细介绍过。前提基本都是要有化合物的SMILES编码信息。这样做的好处是，不用自己生成图片，不用占用自己网站的空间，甚至不用占用自己网站的带宽。同样潜在的问题是要依赖第三方服务的准确性、可靠性和稳定性。

使用浏览器插件

使用浏览器插件恐怕是最常见的解决方案。一般来说，这样的插件都需要用结构式的mol格式作为输入，mol格式可以从SDFile的连接表部分导出。关于mol 和SDFile格式请参考 Chemical table files。目前也只有使用插件，能够实现结构式的输入。

最常见的网页插件有

JME, http://www.molinspiration.com/jme/，java applet

我所见过的90%以上的在web中显示和输入结构式的浏览器插件，都是用JME来实现的。JME的作者没有声称过这个软件是免费的，非商业用户需要向他发一个邮件来索要。而实际上既然是java applet，直接下载下来用也很容易。而事实上大多数的人都是这么做的。

这个软件估计至少有10年历史了，作者是Peter Ertl。

Jmol, http://jmol.sourceforge.net/, java applet

没有用过。开源的项目，支持的格式非常多，不过还是不支持SMILES/InChI。

Chemdraw plugin, http://www.cambridgesoft.com/software/details/?ds=2&dsv=93, activex

不是免费的，在工作中用到过。功能非常强大，结构式编辑功能与Chemdraw软件基本相当，远远超出其他插件。

Chemwriter, http://metamolecular.com/chemwriter/, java applet

Chemwrite应用并不广泛，功能也不强大，只能说图片显示的质量要比JME好不少，进行了边缘平滑的处理。之所以要提到，是因为这个软件的作者是 Depth-first 这个化学信息学博客的作者Rich Apodaca，我在这里学到了很多有用的知识。

JChemPaint, http://apps.sourceforge.net/mediawiki/cdk/index.php?title=JChemPaint, java applet

基于CDK项目的一个衍生产品。

基于Javascript和AJAX的方案

不论java applet还是activex，都对客户端有所要求。java applet要求客户访问网站的时候，要安装java运行时环境；activex默认在浏览器中不能运行，要客户判断安装并执行，因为有臭名昭著的安全问题。而基于Javascript和AJAX的方案，能够解决这些问题，也符合Web2.0的趋势。

MX-GWT, http://chemhack.com/mx-gwt/, 纯javascript

这是国内的一位叫Duan Lian的同学的作品。是我知道的和见过的唯一的用纯粹的javascript实现的结构式显示和输入方案。这个软件实际上是把Rich Apodaca用java开发的一个轻量级的化学信息处理库，MX，通过Google的GWT编译成javascript，使之能在浏览器里运行。非常棒。

Molinspiration WebME, http://www.molinspiration.com/docu/webme/index.html, AJAX

是开发JME的公司Molinspiration最近开发的AJAX的方案，需要服务器的支持。如果愿意买这个软件的话，Molinspiration提供服务器端支持。对客户来说，仍然只要能支持js的浏览器就行了。

PubChem edit, http://pubchem.ncbi.nlm.nih.gov/edit/, AJAX

PubChem在线服务的结构式输入工具，可以拆出来用。而且PubChem也足够开放，提供了很详细的使用说明，包括如何把输入的结构传递到表单。在在线化学结构式图片生成服务提到过，这个编辑器背后隐藏着一个通过SMILES来显示结构式的接口。

Filed by charlie at 9:33 pm under Tools, chemoinformatics, webdev
No Comments

题目是唬人的，结论是从来就没有过武将单挑这种战斗方式。感谢水木社区历史版的朋友的指教。在我三十岁这年，冷兵器战争的臆想和个人英雄主义的YY可以结束了。

摘录各位朋友给的回复

Black8 (⑧)

武将单挑，然后双方部队群殴，这种战斗方式，在咱们国家历史上是啥时候开始和结束
的呢？

汉朝还没有吧？因为史记里面好像没有这种事情。
到了三国时期肯定有了，三国演义里说了。
到隋唐似乎也很盛行。
宋朝有没有不知道，射雕英雄传里写到郭靖和蒙古人的战斗没有武将单挑。
英烈传里单挑还挺多的。
到了清朝似乎就没有这么干的了。

反正我基本不懂历史，不知道哪位懂历史、有资料的，能指教个《中国武将单挑文化
考》？

i3721pp (pippen马拉投资.剩者为王)

小说里开始
评书里发扬
游戏里光大
怎么会结束

chinese (钟国仁)

还没开始，就已经结素

nkai (也许有太多的不应该)

本来就不存在过，还谈什么结束

olives (风~郁闷)

从来没出现过这种情况，除非在小说里面

lylxiao (大家都高兴才是真的高兴)

至少在西方是存在过的

武将单挑有现实意义，和利益基础
当有很多个群落的时候，弱肉强食的年代，哪个群落都避免鹬蚌相争，渔翁得利

所以当两个群落发生利益冲突，又不想发生大规模的损人害己的群斗
这时候采取的手段就是两个：1。谈判；2。单挑
谈判可能是包括交易，或者协定。
单挑有可能是点到为止，也可能生死决。

另外，西方国家里面的骑士精神中，也很重视单挑。往往用于决斗，解决宿仇，甚至情仇。

frankfurt (一次一篇)

这属于武侠版讨论范围啊

frankfurt (一次一篇)

在古希腊以雅典、斯巴达为代表的城邦之前，或许在公元前10世纪之前，由于战争一般都是由自己出钱武装的贵族之间进行，奴隶和平民都不参与，规模比较小，也许会出现单挑的情况吧。后来战争规模扩大，失败的下场更加悲惨，平民参与，步兵成为主力，傻子才单挑
就算是中世纪时期，以贵族骑士为主力的战争，由于防护好，死亡率相当低，有记载一次上千骑士的战斗才死了几个，但是失败的步兵都被处决了（应该是个例吧）。这种时候也很难想象上千骑士参与的战斗会弄什么单挑

Filed by charlie at 9:09 pm under Interests
No Comments

SQLMOL是我的第一个开源软件项目，发布在Google code上。是今年春节假期的空闲时间的成果。

作为一个基于关系数据库的化合物结构存储检索关系数据库平台，不同于之前介绍的各类方案，这个方案不需要Cartridge/CLR/UDF等数据库插件，只需要标准的关系数据库环境，用SQL程序即可实现功能。

目前的测试是在SQL Server 2008 express这个免费版本上进行的，以后的计划是在MySQL, PostgreSQL等主流数据库，尤其是免费的关系数据库平台上进行实现。

这个方案主要的原理是在“Chemical Substructure Search in SQL (Adel Golovin and Kim Henrick)”这篇paper中介绍的。将化合物分子中的原子、键的结构，以生成树(spanning tree)的形式存储在关系数据库中，用普通的SQL进行结构检索。为了实现这个方案，在SQLMOL中实现了以下的关键部件

• 用SQL实现的SMILES parser。
• 利用SMILES parser的结果，实现的Data builder和Query builder。

这样，用SMILES表达的化合物结构式信息，就可以用上面的方案导入到关系数据库中；用SMILES表达的结构检索条件，也可以以相同的规则生成，并执行检索。

到现在为止，这个项目的核心程序，SMILES解析器，还没有实现对SMILES协议100%的支持，对某些情况存在错误。

Filed by charlie at 9:13 am under DBA, SQLMOL, chemoinformatics
No Comments