技术文章
各种编程技术，Perl, PHP, C, C++, C#, .Net, Java, J2EE, Ruby, Rails …
Pylons nightmare ends?
6月1日
Pylons 是 Python 的 MVC 框架之一，在 08 年写 SVN 管理后台 —— pySvnManager (sourceforge, ossxp trac) 的时候，选择了 pylons。当时有两个框架可以选择： Pylons 和 Django。
选择 Pylons 没有什么特别的原因，只是先看了 Pylons，觉得和 ROR 靠的很近，使用习惯和非常相近，再加上看了些老外写的 Pylons 和 Django 的对比文章。于是就从 pylons 入手了。“噩梦”从此开始。
单点登录和 OpenID
5月31日
上周在石家庄做报告，会后有一个同学对 Single Sign-on 技术非常感兴趣，就在会后进行了交流。
该同学说：
以前没有听说过 SSO, 但是一直有个疑问，为什么不能有一个网站将认证信息统一，其它网站都到那里去登录呢？
听到了 Single Sign-on，觉得这不就是解决方案么？如果谁在公网架设一个 SSO网站，不就实现全网的一次注册了么？
我当时回复他，OpenID是实现全网统一认证的解决方案，而不是单点登录，单点登录可以作为 OpenID 实现的基础。OpenID 推行由于公司政治被破坏。
阅读全部内容 »
Check — 强大的c语言单元测试框架
5月17日
C 语言的单元测试框架，上 WikiPedia 可以查到很多。经过一番比较之后，选定 check 作为 c 语言的单元测试框架。Check 最主要的优点是对于每一个测试用例的运行都 fork 一个子进程，这么做的原因是因为 C 语言的独特性：
- 其它语言如 Java，Python，Ruby等，单元测试出错最多不过是抛出异常
- C 语言如果指针操作错误，乱指一气，可是会 coredump的。测试框架因此直接退出，用户是看不到任何返回的，只有郁闷的 coredump
- Check 的单元测试运行在 fork 的子进程中，可以避免测试框架由于 coredump 而崩溃，优点显而易见
但是在 Debian 上安装 check，示例代码竟然没有办法编译通过，陷入忙等待，显然是陷入了一个死循环。
Debian 上安装 check，部署了下列文件（只列出主要文件）：
$ dpkg -L check /usr/include/check.h /usr/share/aclocal/check.m4 /usr/share/doc/check/examples/README /usr/share/doc/check/examples/Makefile.am /usr/share/doc/check/examples/configure.ac /usr/share/doc/check/examples/tests/check_money.c /usr/share/doc/check/examples/tests/Makefile.am /usr/share/doc/check/examples/src/money.c /usr/share/doc/check/examples/src/Makefile.am /usr/share/doc/check/examples/src/money.h /usr/share/doc/check/examples/src/main.c ...
将示例拷贝到工作目录，运行，陷入可怕的死循环！ CPU 占用 100%：
$ cp -a /usr/share/doc/check/examples examples $ cd examples $ autoreconf --install -v autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal
我们在运行 autoreconf 时间使用了 -v 参数，看到发生死循环是在运行 aclocal 命令时。怎么办呢？
阅读全部内容 »
国内难觅稳定的 Debian 源
5月11日
群英汇内部用 apt-cacher-ng 架设 APT 源代理，用公司内部使用的 Debian 和 Ubuntu 升级服务器。
本来想为国家节省国际出口的带宽，将 apt-cacher-ng 的上级服务器指向一些国内的源，今天再次失望了。
从 CoSign 看开源软件本地化（7）
5月9日
这应该是计划中 CoSign 本地化系列博文的最后一篇。之所以，要以 CoSign 为题，写一下开源软件本地化，是因为：其一、在我们经历的众多开源产品的定制中，CoSign 本地化最纠结，我们投入的精力最多。在之前的几篇博文中应该已经看出来了。其二、我们在 CoSign 本地化时采用了作为常见的 GetText 方式，非常典型。其三、使用模板以及模板本地化也是在 MVC 框架流行的今天最为重要的页面本地化方式之一，当然也要承认 CoSign 的模板实际上只是字符串替换，没有一些复杂模板中才有的编程能力。
作为这个系列博文的最后一篇，介绍一下 CoSign 的服务页面的本地化过程变迁历史，便于单点登录系统维护者理解群英汇单点登录平台和 CoSign 的异同。
从 CoSign 看开源软件本地化（6）
5月1日
在《从 CoSign 看开源软件本地化（3）》博文中，我们采用 Apache 内容协商，实现的静态页面本地化。这在当时是没有办法的办法。有点金玉其外，败絮其中的感觉：
- 冗余度增加了，本来保持静态页面和模板的一致性就够头痛的了（因为用户可能需要定制模板），这回又大大增加的静态页面的数量
- 采用 Apache 内容协商，需要更改 Apache 的配置，增加了软件配置的难度
在我们实现了 CoSign 核心本地化和模板功能的括中之后，很自然的就想到了将静态页面也纳入到模板的框架中来的想法。
最新评论