Beautiful World

长久以来都想搭建一个技术博客，当年疯狂研究NDS自制软件的时候，就想要有个写学习总结和整理文档的地方。尝试过很多公共博客，都不适合写技术类文章，因为我想要贴高亮代码。当时就很红的Wordpress可以安装代码高亮插件，但是搭建个人博客需要购买域名和php空间，我没有任何网上支付手段，于是只好用新浪博客凑合了一阵子。

某些得不到满足的需求会周期性的出现。后来用GitHub的时候发现居然可以在上面托管静态网站，也支持直接上传jekyll项目。折腾了一阵子，终于搞出了个还过得去的个人博客。在GitHub上写博客，最大的门槛是git。当时还没有GitHub for Windows，所有操作都要用命令行，并且由于某个广为人知的原因，GitHub也老是遭殃，推送一篇文章到GitHub也要半天，还不一定成功……于是这个博客根本就没有真正用起来。

搭建博客的想法再一次周期性出现的时候，我已经很习惯在Evernote中记录自己的想法了。但Evernot还是有让人不满意的地方，比如我不能用喜欢的Markdown来写，书写体验不佳，插入高亮代码也不方便，还有笔记主要还是给自己看的，人总有将思想传播出去的欲望。对于书写体验不佳的问题，我发现了Draft这么个应用，表面上功能很简单，致力于改善书写体验，并且支持Markdown语法。试用之后我很快喜欢上了这个简约而不简单的应用，然后在支持的发布列表中发现了Tumblr……

Tumblr是一个轻博客，风格清新，讨人喜欢。选一个漂亮的主题，用自定义css设置一下字体，修改几处不满意的地方，就打造出了一个个性十足的博客。虽然自带的编辑框很小，不适合写太多文字，但是好在有Draft这款神器。惊喜的是Tumblr居然支持Markdown，另外可以通过gist贴高亮代码，真是太完美了。虽然打心底里喜欢，但是不得不承认Tumblr也还是不符合我的要求。Tumblr是一个定位在社交领域的轻博客，不适合发布太长的文章是一方面，另外我几乎没发现有其他的中文用户啊亲！

好吧又扯远了，还是来说说用Jekyll搭建博客吧。Jekyll是用ruby写的静态网站生成系统，GitHub自家出品。Jekyll 官方网站上有详细的文档。最好在Linux上安装Jekyll，当时在windows上运行Jekyll真是各种坑啊。幸好现在我有Ubuntu Server虚拟机。Ubuntu发行版应该已经自带ruby1.8，直接$sudo gem install jekyll安装就可以。我就是开始没注意，误装ruby1.9.1，碰上很多麻烦。

Jekyll本身只是一个静态网站生成工具，相当于只有一个平台和一系列工具，靠这些来搭建一个高质量的博客系统难度较高。

那么下一个主角就是JekyllBootstrap了。这是一个接近成品的博客系统，把它克隆到本地，稍微修改一下就可以用了。另外它提供了7套主题，不算很丰富但也够用了。我比较喜欢的暗色主题所以选择了“Hooligan”。

首先有个问题，如果我在博客中引用了一段gist，它会自动引入一个用来支持代码高亮的css文件。亮色主题下看着还不错，但是在暗色主题下就悲剧了，不但和整体配色格格不入，并且和主题原本的代码高亮样式叠加后表现非常奇怪。gist本身无法自定义配色，那么只好改自己的css了。我写了一个gist-darkstrap.css，看上去完全模仿了自带的代码高亮样式。

还有一个问题，GitHub广泛支持它们改进过的Markdown方言，GitHub Flavored Markdown，简称GFMD，其中一项很实用的改进就是可以使用3个反引号作为代码的开始和结束标记，并且还可以指定语言。Jekyll也支持代码高亮，不过采用的是另一种用Liquid标签的方式，看上去很糟糕。实际上Jekyll默认使用maruku来转换Markdown文件，而改用redcarpet就可以使用GFMD的语法了。本地运行Jekyll的话可能需要安装redcarpet：$sudo gem install redcarpet。然后在_config.yml中添加一项配置:markdown: redcarpet就可以了。

以前在做项目的时候遇到过这个问题，在网页中实现套打。很奇怪的是居然没有很完美的解决方案。常用的是以ActiveX控件的方式实现套打，缺点很明显，你必须使用IE并且你需要下载安装一个个头似乎不怎么小的ActiveX控件，而且这东西技术控制在别人手里基本上你必须付费才能使用。

网上搜到的一篇分析目前可用套打方案的一篇文章明显是篇软文，无非是想推广他的”轻量级“ActiveX套打控件罢了。当时我发现一个比较可行的方法是用一个带media="print"属性的css来设置打印样式。鬼使神差的还找到一个叫”blueprint“的开源项目，因为有个print就天真地认为可以帮助我设置打印样式。后来发现这不过是个用来辅助网格布局的css框架罢了，但是无论如何，借助网格布局我硬是把一个单证套打的功能做出来了。反复调整行间距和单元格之间的距离，然后调整打印时上下左右各个页边距，然后就真的可以实现套打了，而且定位还蛮精准。

当然这种方式问题多多。首先它对打印条件要求很苛刻，页边距需要精确设置，可能还只对一个打印机型号甚至一台打印机有效。其次它不够灵活，网格布局受限水平方向上单元格的数量，很难精确对齐要打印的空白位置。最后是部署太繁琐，只能到现场安装调试。当时我疯狂迷恋的chrome浏览器甚至连打印参数设置都没有，无法设置页边距的话只能用IE。总之，这个解决方法太过儿戏。

这段时间试用了几个很赞的chrome应用，很多都提供打印功能，从打印预览来看排版上很接近印刷品，于是冒出个想法来，是不是可以在服务端生成一个pdf文件来打印。因为pdf本身就很适合用来打印，并且套打定位要比css容易控制。

java的pdf库比较流行的是iText。虽然免费版不能用于商业使用，但是这种许可方面的问题似乎没多大问题。简单使用了一下，很容易就生成了一个pdf文件，当然我们并不需要在服务器硬盘上保存这个文件，以字节流的形式发给浏览器就可以了。

下面的问题是如何在浏览器端将这个pdf打印出来。网上有解决方法说用object标签，设置一些参数，然后调用它的打印方法。但是我在chrome上试了不行，这个object根本没有所说的那个打印方法。开始以为是IE的专有方法，但是我在IE9上试验了一下也没有成功。另一个方法是使用iframe。在页面中加载一个看不见的iframe，对这个iframe中的window对象调用print方法。chrome下可以顺利弹出打印预览对话框，但IE会直接弹出Adobe Reader打开这个pdf文件，并且需要再点一下Adobe Reader的打印按钮。这不好，在IE下还要多一步操作。

后来发现pdf中可以嵌入javascript。在pdf中加入一句this.print()就可以在pdf加载完成之后自动提示打印了。IE下虽然仍是打开Adobe Reader，但是马上就会提示打印。this.print()有一个布尔类型的参数，true代表静默打印，也就是不弹打印预览对话框，false则会弹出打印预览对话框。chrome下参数无影响，IE下即使选择静默打印仍会弹出一个确认对话框问你是否允许自动打印……挺烦人的，还不如弹打印预览的好。

今天了解了一下RequireJS。之前很长一段时间都在纠结js的模块化问题，每个页面都写一大堆js代码，重复写着相似的逻辑。虽然对做的这些小应用来说算不上什么问题，但是人总得有点追求不是？而且随着使用了很多第三方组件，script标签长长的一列看着也非常的难受啊。

与js模块化加载这个话题相关的词汇有很多，在详细了解之前有所耳闻的有“AMD规范”、“CommonJS”、“SeaJS”。经过一番谷歌，大致了解了一下它们的意思：

AMD，全称“Asynchronous Module Definition”，就是所谓的异步模块定义，RequireJS就是遵守的就是AMD规范。

CommonJS，从介绍来看它是定义了一组普通应用程序常用的API，惊奇地发现NodJS居然就是CommonJS的一个实现。总之CommonJS貌似是一个很伟大的东西，并且看起来是致力于大致服务端js的生态环境。

SeaJS，淘宝前端团队搞出来的一个东西。尝试使用他们开发的KISSY之后便加了QQ群，但是后来群公告便成了“SeaJS是未来！KISSY是个过客”。了解之下发现SeaJS也是用来实现js模块化加载的一个东西，他们将SeaJS对比的论调像极了RequireJS与CommonJS的对比：太大太复杂，并且想要兼顾服务端和浏览器端。

抱着对“国产”二字天然的戒心，我还是先去了解一下他们用以对比的RequireJS好了。Require只有一个核心js文件，推荐的用法是在页面中只引入这一个js文件，然后另设一个主入口文件，在入口文件中进行参数配置，加载其他依赖模块和干些别的事情。

require函数用来加载模块，首先是一个数组参数，元素是作为模块名的字符串；第二个参数是一个回调函数，当要加载的模块全部加载完成后执行这个回调函数，并且加载完成的模块会以在数组中的顺序作为参数传给这个回调函数。

相对应的define函数用来定义模块。参数与request相似，也是数组和回调函数。数组用来设置依赖模块，如果没有就可以省略。回调函数可以简单的返回一个作为模块的js对象，还可以是一个函数。不过return后面接一个对象或函数字面量怎么看都不大对劲。

对于没有按照规范定义的代码，可以用配置参数shim来处理。这点非常有用，毕竟多数第三方库都不是作为RequireJS模块编写的。另外shim这个词意思是“垫片”，联想到它的用途还是蛮形象的。

考虑一下用在项目中的实际可能。对于基于jquery的项目来说，jquery从1.7开始支持作为RequireJS模块加载，并且它们的功能都定义在jquery这个命名空间下，用shim参数配置一下它们和jquery的依赖性就可以了。自己写的那部分代码则可以按照规范定义成一系列模块，不过如何将以前随手写就的那种散沙一样的代码组织成模块可能是个不小的挑战。

另一个大量引入文件的重灾区是css。并且css还有个特点就是经常作为某个ui组件的一部分，如果能在加载ui组件的js代码时能将css一起引入就完美了。不过目前看来RequireJS还不支持直接引入css，官方问题列表中倒有一个专门的话题，原因是firefox中引入其他域名的css文件时有问题，导致检查文件何时加载完毕是不可靠的，为了避免替浏览器背黑锅所以RequireJS就干脆不提供这个功能。SeaJS号称是支持加载css的，回头了解一下SeaJS，看看它是如何解决这个问题的。

总的来看RequireJS的基本理念还是蛮简洁的，当然要处理一些杂七杂八的细节问题会增加一些复杂度。不明白为啥有那么多别的规范并且争论不休。可能解决同样的问题不同人出于不同的考虑有会有不同的权衡，或者有时候干脆要解决的问题也是有差别的。

另外发现一个问题就是自己不知何时对“国产”二字产生的偏见。国外开源项目很多都是出于兴趣，为了证明自己可以做到某些事情；国内开源项目当然很多也是出于兴趣，但是老感觉动机不纯，虽然也是为了证明些什么，但很多是为了证明自己比别人强。国内不乏牛人，但开源社区相对不够活跃，很多项目都是一个人或少数几个人在做，一个人精力毕竟有限。

love2d bump.lua demo：

分页组件

设计原则

分页组件的设计相对来说是比较困难的，对于一个采用MVC模式的应用来说，分页逻辑需要纵贯视图、控制器和模型三层，牵连太大。 在我设计分页组件的时候也考虑了一些，基本上有以下原则：

1. 尽量降低依赖性

以前用的公司分页组件和servlet API是紧耦合的，而且封装太严密，很难再定制些其他操作。 而且当时也不是针对MVC进行设计，硬要用在MVC模式的应用中，会出现持久化层要依赖servlet API的情况。

本分页组件尽量降低依赖性，作为查询参数载体向下传递的QueryCondition和作为分页查询结果返回的Pagination都是简单的java类。 而QueryCondition中保存http请求参数的params是一个Map对象，在使用struts2的时候，可以直接从ActionContext中获取， 除此之外也可以依次将参数封装在Map对象中，虽有些麻烦但也可以写在一段共用逻辑中简化操作。

在实际进行分页查询的逻辑中，依赖Hibernate API。 因为在项目中，持久化层基本都是使用Hibernate，也没有在可扩展性上做过多设计，如有需要也可以很容易修改成依赖接口的方式。

2. 分页组件中各对象分工明确

目前分页组件有四个核心类，其中QueryCondition中还有一个ConditionItem内部类。

QueryCondition - 查询条件类。封装查询条件，保存请求参数。

Paination - 分页类。封装查询结果和与分页相关的信息。

PaginationQuery - 分页查询类。根据查询条件进行分页查询，并将查询结果和其他分页信息封装返回。

SimpleQuery - 简单查询类。不进行分页的查询，适用于不需分页的多条件查询。