罗泽轩

在[上一篇](http://segmentfault.com/a/1190000002968868)里我们定下了给`pandoc`写补全脚本的计划： 1. 支持主选项（General options） 2. 支持子选项（Reader options/General writer options） 3. 支持给选项提供参数值来源。比如在敲`pandoc -f`之后，能够补全`FORMAT`的内容。 ## 支持主选项 先列出实现了第一阶段目标的程序： ``` bash # 以pandoc的名字保存下面的程序 _pandoc() { local pre cur opts COMPREPLY=() #pre="$3" #cur="$2" pre=${COMP_WORDS[COMP_CWORD-1]} cur=${COMP_WORDS[COMP_CWORD]}...

最近在工作中写单元测试的时候，用到[jmockit](http://jmockit.org/)来mock无关对象。 在jmockit中，你可以使用`MockUp`来创建一个“fake”的实例，对某个方法指定自己的实现，而不是调用实际的方法。 对于接口类型，需要这样调用： ``` @Mocked private SomeInterface mockInstance; mockInstance = new MockUp() { ... }.getMockInstance(); ``` 这个倒没有什么古怪的。估计又是使用了[java.reflect.Proxy](http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Proxy.html)。这个技巧在很多Java框架中用到，比如Spring AOP对于接口类型的实现，就是通过Proxy来混入拦截器实现的。 但是，对于其他类型的调用，就比较奇怪了： ``` java @Mocked private SomeProxy mockInstance; new MockUp() { @Mock public...

三月底的时候，要去实习的公司就已经早早地确定下来了。这么一来，我有了一大段时间可以自由支配，可以学点有趣的东西，在毕业之前多多拓展自己的视野。 抱着这样的念头，外加一时心血来潮，我决定去跟一门MOOC课，看看传说中的MOOC课是什么样子。一阵东挑西选之后，我选中了这么课：Coursera上的《Principles of Reactive Programming》。当时之所以做出这样的选择，主要原因有三： 1. 当时正好对并发程序开发感兴趣 2. 这门课开课时间正好对得上 3. 计算机类的课程，大部分不是简单的算法入门或者编程语言介绍，就是机器学习或数据挖掘之类偏学术的课程。适合我口味的课并不多。 当然啦，这么课还有一点加分项：开课的三位讲师都是大牛，包括scala的作者、ReactiveX的开发者以及Akka的scala版本的开发者。总之，让他们三个讲Reactive编程简直再适合不过了。 既然讲师都是scala背景的，这门课自然是以scala讲述。于是乎，我还得去学scala才能跟上老师的授课。由于报名的时候，离开课只剩一个星期，想学会scala是不可能了，所以在上课的同时，也需要继续完善scala的学习。 这门课给我带来的第一份收获是对scala这门语言的认识。 虽然以后我恐怕不会用scala来开发自己的项目（主要是因为编译耗时太长，拖慢了开发效率），但是scala这门语言也是相当有趣的。它就像是c++一样，同时包含了多项编程范式。你可以把函数式风格和面向对象风格杂糅在一起。不过我最为看中的是，scala就像其他现代静态编程语言一样，把类型推导和匿名函数双剑合璧，大大拓展了语言的表达能力。除了之外，scala还有许多语法糖，比如mixin、操作符重载和时间字面量，具体可以看看 [Ruby VS Scala](https://ruby-china.org/topics/25439)。总之，scala是一门非常华丽的编程语言，具有许多让编程语言控兴奋不已的特性。当然，这么多特性的后果，是复杂到有时语法错误连IDE都发现不了，以及吊打c++的编译耗时。 Ok，该回到主题了，继续聊聊这门课。 课程一开始是介绍函数式编程的一些概念，比如map和flatmap等等。接着开始引入一些具有Reactive风格的概念，比如Signal。然后逐渐进入主题，开始出现两对基友： | | One | Many | | --- | ---...

诶，《只有神知道的世界》真得太好看了！我一连花了两周时间，实现了12×3集TV动画加3集OVA、两百多回漫画的补完，打破了之前的补番记录。很久没有见过这么对我口味的作品了。 《只有神知道的世界》是关于Galgame之神——桂木桂马在迫不得已的情况，活用二次元Galgame知识攻略三次元妹子的（后宫向）故事。听起来是不是很像YY小说的剧情……囧。但其实这部动漫三观到是很正（不，我不是说人渣主角最后被正义的柴刀制裁的结局）。没有攻略之神桂木桂马攻略不了的妹子——前提是该妹子是二次元妹子，对于三次元妹子，神大人可是不感兴趣。BTW，攻略这个词被用于三次元中的把妹，也是因为神大人而起的。然而桂木桂马不犯桃花，桃花也会来找他。有一天，桂马被连蒙带骗，成为了来自地狱的Bug魔艾露茜的协力者，不得不用恋爱的方式驱逐寄居在少女心中的驱魂，否则就会人头落地。当然啦，为了避免Nice Boat的Bad end，根据设定，只需要接下吻就能驱逐驱魂了。而且驱魂被驱逐之后，少女的记忆会被消除。（然而这个设定是有问题的……这导致了之后剧情的暴走，以及修罗场） 于是心中只有Galgame的神大人，走上了~~开后宫~~ ~~成为人渣~~ 拯救失足少女的不归路…… 已经踏上了不归路的神大人，不情不愿下被命运的洪流所推动，跟一位位少女上演恋爱的轻喜剧。于是乎，我们看到神大人将Galgame的知识活用到现实世界中，跟艾露茜一起攻略各路妹子，在经历千辛万苦后终于解开妹子的心结，吻得美人归。虽说是“经历千辛万苦”，但是期间不乏各种笑点，以及神大人的各种机智点子，令人不知不觉中喜欢上神大人这个心里只有Galgame，却不得不去~~攻略~~ 拯救失足少女的家伙。每当少女解开了心结，却忘却了跟神大人共同的记忆，只有神大人带着美好的回忆，继续他在Galgame的征途时，我总是替神大人感到可惜。 然而爱开玩笑的命运，并不允许神大人一幕幕地拍恋爱轻喜剧（哦不，我们不应该怪罪爱开玩笑的命运，应该怪罪脑洞大过天的画家）。神大人在完成一次次攻略后，逐渐接近10年前驱魂大逃脱的真相。于是为了呃，宇宙的爱和和平，不，为了三界的未来（确实如此），神大人开始走上一条成为人渣的不归路。为了集齐六位女神封印驱魂，神大人决定放下心爱的Galgame，心爱的二次元女神们，要从过去攻略过的妹子中寻找女神，而所拥有的线索是，心中栖息着女神的妹子，不会忘记跟神大人的共同回忆。也就是说，嗯，神大人要去问妹子们，你们记得“大明湖畔的桂木桂马吗？”，对了，这次是需要同时攻略七人哦！虽然神大人可以同时打六个Galgame。然而Galgame是Galgame，现实是现实，如果有谁敢现实里同时攻略两个妹子，未免会被打上“脚踏两条船”的印记，然后被众人所唾骂，而神大人的目标是，七个……这次就算五体投地也踏不上了。难怪神大人说，他决定变成攻略之鬼（攻略之人渣，即鬼也）。喔，我已经看到结局了，人渣诚在彼端向神大人你招手。 当然了，神大人这么做，也不是他一时心血来潮。毕竟，这一切都是命运的逼迫。如果没有被当作协力者，神大人乐得生活在Galgame的世界里。那里有他心爱的二次元，有他的四叶……“我确实对现实绝望了，但是我没有对自己绝望，决定现在平凡与否，开心与否，快乐与否的不是现实，而是我，我确实对现实绝望了，但是我没有对自己绝望”。神大人，其实是个生活在二次元里的现充。然而没办法了，面对如果不去做，就会有人牺牲的困境，神大人勇敢地面对命运的挑战，踏上了成为攻略之鬼的道路。其实，我觉得还有一个原因，神大人对现实世界还是不怎么习惯（没有那么多思想负担和道德约束），所以能够总是保持冷静，去找寻通往结局的最短路线。 然而这次，神也失手了。现实世界比Galgame复杂得多，神大人发现千寻是真心喜欢他，而不是因为受到有意为之的攻略的影响。不过，千寻心中没有女神，没有女神，也即不是攻略的目标。既然不是目标，就应该果断拔flag，然而，怎么能这样对待一个真心喜欢自己的人呢……最后的选择是无奈的，以至于接下来的剧情犹如暴走。然而局势已经不容婆婆妈妈了，神大人没有别的路线，只能一条路走到结局了。于是怀着对千寻的歉意，神大人终于集齐了六个女神，解除了正统恶魔社的威胁。 不过神大人的日常生活（天天无时无刻打Galgame）还没来得及恢复，新的挑战（命运的逼迫！）又过来了。为了保证打败正统恶魔社的事情确实能够发生，桂马被女神们传送回10年前。这次他需要修正世界线，让某一个特定的未来（成功的未来）能够发生。而他能够做到的，就是跟Bug魔艾露茜和新的助手一起，继续靠攻略妹子拯救世界。经历了重重困难，包括跟正统恶魔社的恶魔斗智斗勇，跟恶魔女王香织见招拆招，以及跟青梅竹马天理的羁绊，神大人终于修成正果，让过去的世界线接上自己熟悉的世界线，也拉开了《神知》故事的大幕。于是一切从10年前开始，攻略妹子也要从小计划啊。 就像所有别的故事一样，最后的结局里，正义都战胜了邪恶，神大人“胜算不是什么时候都有的，就算没有胜算我也要做给你看”，终于在“狗屎游戏般的现实中”，获得了“只有在游戏中追寻到的理想结局”。然而跟别的故事不同的是，勇士没有跟公主走在一起，“我们之间是不可能的”，虽然经过了10年的羁绊，桂马和天理还是没有走到一起。最后的结局，是属于千寻和桂马的。虽然无论天理还是千寻成为最后的女主角，我都没有所谓啦。但是看到这样的结局，还是感觉有点儿失落。毕竟，天理的戏份比千寻重多了，让天理成为最终的唯一更加众望所归是不是……不过神大人还是选择了千寻，毕竟千寻的反应总是能让他措手不及，让他体会到爱的感觉，也许，这就叫爱情吧。 在我的心目中，神大人是一个让我敬仰的存在。不是说攻略妹子的能力举世无双啦……神大人整天打Galgame，别人都嘲笑他是眼镜宅，然而神不在乎。他不是为了逃避现实而沉迷于Galgame，而是因为Galgame中有理想的结局，而现实只是一个狗屎游戏。虽然如此，当身陷狗屎游戏时，他总是全力以赴，极其冷静地去找寻通往结局的路径，就像每个孜孜以求的Galgame玩家一样。虽然本人对Galgame并不感冒（只对Galgame改编的动漫感兴趣哈），但是他的心态和行动，却也鼓舞着我这个字面意义宅，为了更加理想的结局而战斗，去找寻现实生活中的flag，去看到那个理想的结局。

不算完成scala作业和填find的terminal UI这个挖了一段时间的[坑](https://github.com/spacewander/find)，好像有一段时间没有写代码呢……最近真是提不起干劲啊，也许得等天晴一些之后才重新回到热情饱满的状态。 为了打发时间，上来闲聊下吧。既然最近没有写代码，那也聊不了多少编程相关的话题。嗯，就聊点闲散的东西，聊聊阅读吧。 我觉得，阅读可以分为三种方式，翻页式、流式和超文本式。 1. 翻页式：即阅读文本书时的方式，一页页翻下去，没翻到下一页之前就不知道后面发生的东西。 2. 流式：即阅读PDF文档时的方式，一页页滚下去，看着下一页一点点加载上来。 3. 超文本式：即阅读网页的方式，从一个地方跳转到另一个地方，然后又跳回来，也许就再也跳不回来了。 这三种方式带来的感觉真是不一样的。换句话说，各有特点吧。 翻页式是最自然的，尤其是当页脚卷起，触及肌肤之时，感觉整个人都很有状态呢:)。当然啦，毕竟这是在阅读实体书，而实体书带来的质感，是电子书所不能披及的。有些电子阅读应用试图复制这一体验，但在我看来，不过是东施效颦罢了。毕竟即使是“触碰”，发生在纸上和发生在触摸屏上，感觉是大相径庭的。这种拙劣的效仿，只会加深这种不真实感。 流式是阅读PDF的形式。虽然也可以把PDF浏览器做成翻页的样子，但是不比txt文件文件，PDF的大小不能轻松转换。如果硬要做成一页页的样子，假设用户需要放大缩小当页的内容，计算排版的任务可就有得忙啦，说不定就卡死了……流式阅读有个特点，其内容是逐渐拉上来的，而且页与页间的间隔不明显，没有翻页式那种内容被切割成一块块的感觉。不过，也因此迷失了进度，不容易知道自己到底阅读了多少。 超文本式是一种奇妙的阅读体验。你所面对的，不是一本有穷的书，而是无穷的知识网络。就像是跑到一个公园里，你追踪着各式各样的风景不断前行，突然又路过了之前的某个分叉路口。它跟之前的阅读方式都有很大的不同，以至于有人甚至不认为这算是一种阅读方式。不过事实上，恐怕跟前面两种方式相比，它跟现实生活中获取知识的方式是最为契合的。毕竟生活的知识，就是散落在世界这一广袤天地的各处。不过，要是想获得某种连续的，有趣的体验，比如去阅读一本小说，这种方式总会打断读者的遐想。所以，超文本式适合去求知，而想从想像的世界中获取乐趣，还是选择传统的阅读方式吧。 虽说，阅读这件事，主要还是看阅读的材料吧。但是，阅读的方式，还是大大影响了阅读的体验呀。

作为一个有志于开发服务端程序的人，如果没有尝试过Go，那实在是太可惜了。抱着这样的念头:)，最近尝试下了Go。敲了些能找到的例子，不过目前暂时既没有用Go开发过side project，也没有给Go写的开源项目贡献代码（等开始结课后，时间变得更加充裕才继续）。刚刚统计了下，大致累积了三千多四千行。我觉得应该可以给Go一个阶段性判断了。 Go作为一门专为服务器端并发编程而生的系统编程语言，果然不负众望。goroutine和channel珠联璧合，编译速度更是出乎意料地快，非侵入接口实现了静态语言版Duck type。但是，由于没有泛型，有些设计真让人啼笑皆非。另外，其错误处理的机制也让我有点不习惯。总的来说，要想实现Go原初的目标 - 替代C - 还有很长一段路要走。 ## 写啊写 Go作为Google的side project，也毫不意外地享受到GFW的“一视同仁”。golang主页如果不翻墙，是打不开的。关于golang的另一个资料来源，Google邮件组中的Go-nuts，也是得在墙外世界中。总之，如果你想学Go，那么翻墙吧。 现代编程语言往往提供all in one的工具链，方便用户进行编译/测试/打包/管理依赖等一系列工作。你可以尝试从Go China的国内镜像中获取，也可以使用包管理。包管理版本比较旧（我这里是Go 1.2，而最新是Go 1.4），但是安装方便，输完一行命令之后就会自动安装好了。鉴于本人比较懒，而且又不是狂热的Go fan，无需追求最新版，所以是使用包管理安装的。 开发工具直接使用vim + vim-go就好。Go开发非常轻便，无需一个沉重的IDE处理各种琐事。Keep it simple stupid! ## 困扰 Go的目标是Better C。所以它真的是挺simple的，而且跟C一样，也没有什么语法糖。嗯，这些也算是意料之中啦。只是Go的编译速度太快了，总是让人产生它是一门解释型语言的错觉。 跟其他的现代编程语言一样，Go也是把参数类型置于参数名字之后的。比如`i...

| | | | --- | --- | | Name | Zexuan Luo | | Github username | spacewander | | Email | [email protected] | | Timezone | Guangzhou, China,...

最近几个月的空闲时间里，我一直在做一件事，就是用各种编程语言实现同样的一套“算法”。 虽然名为“算法”，其实指的是C++标准头文件algorithms和numeric里面的一套辅助函数。因为这部分内容一般情况下都称之为STL算法，所以我也可以大胆地宣称自己实现的也叫做“算法”，哈哈。 目前，已经完成了C++/Python/Javascript/Coffeescript/Java这几个版本。由于新学期会有新的目标和计划，所以这个小实验就此打住，估计将来也就这几个版本。算法的时空效率方面，也许倒不是每一个都能遵守。代码实现方面，也更看重于代码是否清晰优雅，而不是效率（毕竟，如果要写出一个高效率的实现，恐怕得死更多的脑细胞）。 --- 聊聊下自己的感受： 第一个版本是C++实现的，用C++实现自带的辅助算法。由于要实现的本身就是为C++量身定做的内容，算法的参数和功能无须作出任何裁改。大部分函数都没有难度。 但是，诸如`stable_sort, rotate, prev_permutation, make_heap`之类的函数，还是花了一些功夫去思考。 第二个版本是Python实现的。这个版本的实现很快就遇到了一个问题，Python里面的`iterator`和C++的`iterator`不是同一个东西。 在Python里面，只有一种`iterator`；而C++中有各种`iterator`，输入的/双向的/随机的，等等。 可以这么说，在C++里面，所有可以访问容器中的数据的方式，都算作`iterator`。而在Python（和其它语言）里，`iterator`指的是一种在实现了`__iter__`（或者叫别的什么东西）的接口的容器中迭代访问的对象。 Python里面，只是单单实现了`__iter__`的对象是不能修改里面的值，即相当于C++的`input iterator`，你只能拿来input，其他的事情一概不能做。 然而相关的算法中，大部分需要使用`Forward iterator`。这种`iterator`允许你在迭代的时候修改当前迭代到的对象。 还好Python里面可以找到差不多的对象，只要该对象实现了`__setitem__`和`__getitem__`即可。严格来说，这算是`random iterator`的要求。 所以说，这个差不多真是差好多啊。 因此，许多算法在设计的时候，就只能应用在list上，尽管它们并不需要随机访问的要求。 有了C++和Python版本，其他语言的版本就方便很多了。因为可以直接借鉴C++和Python的实现…… 第三个版本是Javascript实现的。写了一会儿，发现Javascript跟Java还是很像的，都挺罗嗦。基本上，Python可以找到语法糖，三言两句就能解决的问题，要是使用了Javascript，你就不得不写`i < xxx.length; i++....blabla`，尽管它们都同为动态语言。写的时候我就猜了下，Javascript版本一定会比Python版本的要长得多，甚至说，比起静态类型的C++，Javascript版本也短不到哪里去。事后看来，确实如此。 而且让人讨厌的是，Javascript函数最后时不时要带上`});`这样的一串尾巴。处处带花括号就算了，你还要带上小括号，看来JS受C和LISP的影响真得挺深。 第四个版本是Coffeescript写的，Coffeescript不愧是Javascript的加糖版本，一下子就简单很多。写完这个版本，再一次坚定了从Javascript转到Coffeescript的决心。 当然，Coffeescript只是在JS上撒了薄薄一层糖霜。JS里没有的类库，在Coffee里面也没有……甚至说，JS的一些怪癖，Coffee也不能免除。你还是要小心翼翼，才能全身而退。 最后的一个版本是用Java写的。...

最近在朋友的推荐下看了《乐园追放》，号称是“老虚从良之作”，从头到尾没死过人…… 当然我不是来看没死人的。之所以朋友会推荐这个电影，是因为当时我们在讨论《文明：太空》中的三条线：至高、纯正和和谐，然后他提到“有部电影的主题也是讲这三条道路”。于是今天中午，趁着有空，我放弃午休看了下这部片子。感觉这部电影的确值得一荐。 > 以下内容具有剧透，请自行斟酌是否继续阅读！ ## 大致看法 设定一般，大概就是普通动画片和科幻片的套路。像是《群星的尽头》和《与拉玛相会》的混合。当然，编剧不太可能是因为受这两本小说影响，毕竟科幻的领域里，大部分的创意都被前人的作品挖掘光了，各种作品间难免能看到彼此的影响。 不过本片的优点在于细节和剧情、人设。人物的一言一语、一举一动，都能体现出动画制作者的精心设计。而剧情方面，安吉拉和野狗，还有安吉拉、野狗、拓荒者三位主人公之间的交互都令人记忆尤深。特别是主题曲EONIAN响起来的时候，顿时给人一种苍凉的沉重感。编剧在各种情节间的切换很在行，紧紧抓住了观众的心。 至于人设，三位主人公的形象已经深入我心。好强又果敢的安吉拉，机智而爱好自由的野狗，半个人半个机器、古怪又可爱的拓荒者…… 当然我才不会说，女主的身材也是个看点（pia飞） ## 乐园 天上有一个乐园，有人享受里面的生活，有人拒绝进入，有人想要追求新的乐园。 这就是《乐园追放》的三条道路。 当安吉拉奇怪野狗为什么一再拒绝前往乐园的邀请时，野狗认为，所谓的乐园，其实是骗人的。在乐园里的人，仍然免不了为有限的记忆体而争名逐利；如果有人为社会所不容，那么他就完蛋了，会被永远档案化。甚至还存在保安局这样的独裁机构。 当安吉拉和野狗惊讶于，拓荒者为了准备发射飞船到外星空间，已经花了上百年时间。拓荒者说，这是为了证明我自己的存在。 当安吉拉因为拓荒者求情而被保安局高层囚禁时，拓荒者出于仁义，前往解救安吉拉。两人从天上杀到地上。之后安吉拉也出于仁义，坚守发射基地，阻击迪瓦派来的来兵。 拓荒者问安吉拉是否愿意跟它同行。安吉拉当时正骑着她的机甲在空中激战。她俯瞰了下大地，回答说：“对于这个世界，我还有很多地方没有去探索，很多事情没有去了解”。最后决定留在地球。 最后，因为迪瓦中没有人回应共同踏上新的征途的邀请，拓荒者想要中断自己的计划。野狗和安吉拉告诉他，拓荒者虽然不是人，但也算是人类的一员。即使无人陪伴，也应该勇敢地走出去，向外星宣扬人类的功绩。拓荒者终于决定独自出发，驶往无尽的星海。 ## It is so far away 看完电影后，我找来主题曲听了一遍又一遍。只是没有了电影的氛围，主题曲的魅力折损不少。但是听到了`It is so far away`这一句时，心中难免感慨万千。...

这里的表格语法怎么调都调不对。直接放SegmentFault的链接： http://segmentfault.com/blog/spacewander/1190000002454946