吞吴

我个人非常喜欢iOS系统中的开关按钮效果。相比于普通的checkbox，这种带有滑动效果的开关按钮显得更加美观，体验也更好。刚好最近在开发围脖贴，于是想在一些要用到checkbox的页面中使用类似iPhone/iPod/iPad中的开关按钮效果。

当然首先是寻找现成的实现，可能是我太土鳖了，不知道这个东西叫做 toggle switch，结果一直搜 toggle button，得到的结果都不是我想要的。于是索性自己实现了一个。（效果，Github Repo）

下面简单记录一下实现的思路。

背景动画

实现的重点在状态的切换过程，需要产生一个平滑的滑动效果。于是我想，制作一个左侧是开启，右侧是关闭的图片，作为背景，然后在切换的时候给背景做一个动画。于是产生了下图。

为背景作动画用到了Backgroud-Position Animation Plugin。仅使用一个开启/关闭联合起来的图是不够的，因为按钮有一个圆角，如果始终使用联合图的话，在一个开启状态下，右上角和右下角会显示灰色，在关闭状态下，左上角和左下角会显示蓝色，很不自然。所以，需要在动画结束后，把背景切换到单独的开启/关闭按钮的位置。

状态保存

考虑到这个开关按钮基本是放在一个form里面用的，因此使用一个hidden的input元素来保存它的状态。每次开关被单击，就改变input的值。这样以来，就很容易把开关状态通过表单提交到后台。

自定义事件

很多时候需要根据开关按钮的状态进行编程，因此添加了两个自定义事件 on 和 off，分别表示按钮被开启和关闭。可以使用jQuery的bind方法来添加事件处理函数。

成果

感兴趣的童鞋，可以 点击这里查看效果，或者在这里下载。

不知道大家注意到没有，正心楼6楼的男厕所，靠门一边的两个小便池比其他的小便池的使用率要高很多。什么原因呢？据本人分析，原因是，靠窗一边的小便池让人有被窥视的感觉。请看下图：

图中蓝色的线条表示人的视线，半透明的黑色区域表示盲区，也是让如厕人感到安全的区域。可以看出，在厕所外面的人的视野理论上可以覆盖除靠门一侧的两个小便池外的其他所有小便池。毫无疑问的，小便是非常私人的事情，使用非盲区内的小便池就会有很强烈的不安全感，所以导致盲区内的小便池使用率远高于其他小便池。

过高的使用率将导致盲区内的小便池更容易损坏，而其他小便池的利用率过低造成资源浪费。同时，在如厕人数较多时，将有人不得不在非盲区内小便，造成如厕体验低，内心忐忑不安。

针对以上问题，本文作者本着科学的态度，设计了两种改进方案，如下：

最少用料方案

最少的建筑材料的方案。示意图如下：

该方案将外面的门和里面的门错开，减小可视角度，从而扩大盲区。

最少改动方案

对现有建筑格局改动最少的方案。

该方案在里面的门内增设障碍物，阻挡视线，从而扩大盲区。

您有什么更加高明的方案吗？欢迎分享。

小小终于恢复了。开始知道自己吃东西了。伤口也基本上长好了。悬了十几天的心终于可以放一下了。I’m gonna go back to work now.

两件事情要尽快做

1. HOJ在下周三之前上线(不含论坛功能)
2. 工大内部网站评估报告在下周日之前出个草稿

张志桐和李海，需要批评。备忘。

今天复习《把时间当作朋友》，看自己的上一篇流水帐时，发现已经是12天前的了。反省。

今天偷懒，在睡觉、上网冲浪、洗澡、吃零食中度过了。

反省。

今天搞定了Proposal Tool v2.0的PDF报表生成模块。简单总结一下我所使用的解决方案。

需求

需求是要根据用户选择的历史数据，动态的生成一系列的折线图、饼图、柱状图，然后将这些图表整合到一个PDF文件中。PDF中的文本也是动态的和可修改的。

工具

开发语言使用PHP；图表生成工具使用了强大的pChart库；生成PDF的库选择了dompdf。

pChart将直接生成图片文件，很方便的就可以作多种用途。(pChart和jqPlot的比较，可参考我之前的文章：《图表生成工具pChart和jqPlot》)

dompdf简单易用，可直接将HTML转换成PDF。API十分简洁。不过dompdf有一些限制，它不支持position:relative/absolute, 不支持嵌套表格，不支持float等等(其他限制参考dompdf官方网站)。所以布局比较复杂的页面用它来处理会比较吃力。

解决思路

分3步解决

1. 使用pChart将数据转换成图表，并存储为图片文件，保存在临时存储区中
2. 使用PHP的模板引擎定制HTML，并在其中引用上一步中生成的图片文件
3. 使用dompdf将上一步中的HTML转换为PDF文件，删除临时存储区中的图片文件

效果图

PDF Report Generated by pChart and dompdf

曰：贵有恒，何必三更眠五更起；最无益，莫过一日曝十日寒

要做的两件事情现在都开始做了。CMS决定放弃重新发明轮子的冲动，使用PMWiki作为解决方案。工大网站的评估今天正式开始了，由小雨、大龙、张雄、张志桐、陈云飞、李海六位同学来负责。希望他们能够完满的完成这个项目，给出一份牛逼的报告。

今天检查了一下功课，又是老毛病，没能持之以恒，中间时有间断。上一次的钢笔字还停留在5月10日。三天打鱼两天晒网，从小到大就是这个毛病。反省。

这两天方舟子在其微博上发布了关于哈工大机器人涉嫌造假的消息。这让很多哈工大的校友十分不满。我昨天刚刚看到这个消息的时候，也是满心的不高兴。我想有必要对这件事情做一个全面的反思。

今天在人人网上看到两篇文章：有关方舟子关注哈工大机器人事件的个人看法，关于工大机器人和方舟子我要说几句。让我对这个事情有了新的看法。

对于专业的计算机从业人员来说，机器人需要编程驱动是很浅显的道理，但是，对于普通人来说，机器人就是一个机器，至于它具体是如何工作的，大多数人恐怕并不清楚。因此，洪教授的那句话让大家以为“机器人是哈工大自己制造的”不仅是情有可原的，甚至几乎是必然的。方舟子尽管是一名科技工作者，但他是生物化学博士，不了解计算机科学也属正常。大家通过理性的讨论，把疑问和误会解开就可以了。

不过看起来有些哈工大的校友们有点不够淡定，从上面两篇文章及评论中能看得出来，显得有点着急和忙乱。实际上大可不必，方舟子尽管成功的打了不少假，可是那并不意味着他发布的所有消息就都是确凿的，都是定案。况且方舟子在这个问题上不是科普工作者，而是一个需要接受科普知识的受众，如果他果真搞错了，耐心的解释解释，误会是能够搞清楚的。如果把这种纯粹的学术上的争辩变成了对方舟子个人的攻击，那不仅无法有效的化解误会，更让我们哈工大人的斯文扫地。

况且，洪教授的话的确太过夸张，“我们自己研发的仿人型机器人，不输于任何世界各个国家”，即便考虑到上下文，也是言过其实的。这话不应出自一个严谨的科研工作者之口。

我想，在这个问题上，工大方面可以给出一个回应，澄清一下，达人秀那边也应该把洪炳镕教授说过的话的完整视频放出来。

造成这种误会，有多种原因，首先就是达人秀方面把节目进行了剪辑，使得洪教授的对话失去了上下文，让人造成误解；另外方舟子单凭几个机器人的图片就断定“没有做任何修改”，太过武断，这无疑是与科学精神相违背的；更重要的是，洪教授的话的确不够严谨，难免让人误解。

新浪的这篇报道很不错，综合了多方的看法，而且没有简单的给出结论。

Update

跟墨总吵吵了一阵子，我承认科学家的思路比较诡异，他认为在这件事情上，最应该反省的是那些搞机器人制造的。

Update

今天下午跟kinslover同学进行了一番争论，最后基本上达成了谅解。我的观点总结如下:

我认为，对于监督者，要求不应太高。因为监督者的作用是提醒性的。如果一定要每一个监督者都以“论述有力、证据确凿、毫不偏颇”为标准进行监督的话，那毫无疑问的，能够达到标准的凤毛麟角。我想，监督应该就是我觉得这事可疑，我就提出我的质疑，然后你来解释。可以类比近代民主制度中的一些基本原则，发对派的质疑可以尖刻或偏颇。因为只有降低监督的门槛，才能形成有效的监督。

因此，即便方舟子的质疑是尖刻和偏颇的，我认为这种质疑也是有价值的，因为它构成了对学术造假的有效监督。

kinslover同学的观点我不好总结，请参考他的原文。

Update

sunner依然是那么视角独到：《面子重要，还是真相重要？》。最后一段实在很“狡黠”。

曰：万事蹉跎因懒惰，穷困潦倒缘贪心

便捷灵巧的CMS

最近做好多事情都发现需要一个便捷灵巧的CMS，Wordpress现在也显得太过臃肿了。我又令人羞耻的想要重新发明轮子了。暂时的想法是使用Textile和Geshi库，在现在的Crude Framework上开发一个CMS。

在Textile的官方站上看到他们有一个CMS，不过下载试用之后发现太丑陋了，完全不是我喜欢的型。

一直很喜欢Textile风格的Markup，在考虑OJ的后台的内容编辑也基于它来做。

工大各院系处所网站评估

这是大烈交代的一件事情，要对工大各院系处所的网站做一个全面的评估，给出评估报告。原本我对这件事情兴趣不大，不过这几天仔细的思考了一下，发现这个事情还是很有意义也很有意思的。列一下思路，以防忘记。欢迎补充。

从以下几点进行评估

• 外观
  • 界面美观程度
  • 各浏览器下的兼容性
  • 图片、Flash等的使用情况
  • 特效使用情况
• 内容
  • 信息量
  • 主要内容分类
  • 时效性
  • 纯文本、多媒体内容的比例
• 功能
  • 展示功能模块
  • 交互功能模块
  • 其他功能
• 体验
  • 浏览体验
  • 信息获取的便捷程度
  • 交互功能体验
• 使用情况
  • 使用频率
  • 交互频率

针对以上各点给出评级，对于存在问题的，给出改进建议。针对每一点，评出一个最优一个最差。再对所有网站做一整体的评级。

尽管我不喜欢长篇大论的报告，但是这两天合计了一下，这个报告肯定短不了。

之前开发喜乐喜乐网的后台统计功能的时候，一直在用jqPlot，效果很不错，我挺喜欢的。最近手头的一个项目要求将生成的图表嵌入到PDF中，jqPlot就无能为力了。于是我不得不转而寻找其他的解决方案，这才发现了pChart。感觉只有一个，那就是相见恨晚啊。

下面简单对比一下这两个图表生成工具。

成像风格

先上两个图看看效果

pChart Showcase

jqPlot Showcase

在图像风格上，pChart更加倾向于秀气，线条比较纤细；而jqPlot则显得比较大气，线条结实稳重。pChart内置了边缘防锯齿的功能，阴影、透明等feature一应俱全，成像风格很漂亮，我个人比较偏爱之。

适用场景

当然，图像的风格只是外在的表象，这二者最重要的区别在于，一个是在服务器端渲染图像，另外一个则是在浏览器端。

因此，pChart要占用服务器的CPU资源，当然，也要占用硬盘空间，如果你要把图表通过web页面展示的话，还要占用带宽资源。因此，pChart并不适合于用在仅需通过web页面显示图表的情境下，在这方面，jqPlot要更有优势一些，因为它是完全通过Javascript在浏览器端作图像渲染，不需要占用服务器端的CPU和硬盘，带宽的消耗也偏小，因为仅需传输文本数据而不是图片。

反过来，当你的图片不仅仅是要在浏览器上显示，还要作其他用处，比如我现在面临的情境，需要把图表嵌入到PDF文件中，那么pChart就将是不二之选了。pChart还内置了缓存机制pCache，用以节约CPU资源。一定程度上减少了CPU的消耗。

API易用程度

由于图表中需要控制的元素特别的多，因此API不可避免的会比较复杂一点，总体上来看，由于jqPlot中可以使用json，API上相对会比较简洁一些。而pChart则略逊一筹。

pChart

jqPlot

总结

曰：路遥知马力

OJ要开始联合调试了，今天开始搭建一个测试环境，让OJ跑起来。折腾了一阵子，尚未搞定，判出来的题都是 -992, Server not ready。 估计要好好阅读一下Judge的代码才能找到问题的根源。

这两天在考虑开新项目，让小雨同学牵个头，充分利用一下学生们的空闲时间，力争不让他们空转。

现在参与项目的学生还是稍显少了点。不过兵在精不在多。还是克制住招更多人的欲望吧，把这些学生好好带出来。有了几个能独当一面的人，再招不迟。

OJ开发中遇到了不少问题，今天测Submit功能的时候，就发现张雄的代码有多处问题。为防止遗忘，记录之

• 测试用的echo语句没有删除干净
• 从老界面切换到新界面时，没有进行测试，直接提交了代码，导致原本应该post的表单变成了get，而且有一个输入框的name没有定义

OJ有很多页面都涉及到分页，原本打算写一个通用的分页功能，不过后来放弃了这个打算，改成让每个人都自己做一个分页。回头把它们各自的实现放在一起对比一下，然后再总结一下分页这个问题。恩，这需要组织一次分享会。

陈云飞的主题算是合格吧，不过评论的样式太过简陋，得安排他好好细化一下。