哈嘿！

Extempore 是一套实时编程语言和运行环境，它提供了一个机体编程 (Cyberphysical Programming)^[1] 环境，以支持对多媒体和实时系统的实时编程（Live Coding）。所谓机体编程，就是允许编程者可以在任意时刻自由地修改程序并即时影响系统的运作，达到“即写即执行”。官方的介绍如下：

Extempore is a programming language and runtime environment designed to support ‘cyberphysical programming’. Cyberphysical programming supports the notion of a human programmer operating as an active agent in a real-time distributed network of environmentally aware systems. The programmer interacts with the distributed real-time system procedurally by modifying code on-the-fly.

Extempore 的前身是 Impromptu ，由 MOSO 公司的创始人 Andrew Sorensen 所设计和开发，并托管在 Github 上。

缘起

工作大半年，开始感觉不如以前可以花很多时间在业余小项目上了。

读书的时候，虽然白天有很多课业上的压力，但到了晚上总有精力来做一些小东西。那个时候，熬夜的后果最多就是第二天到课室打下瞌睡。工作之后就完全不同了，白天的时候，需要一直聚精会神的工作，以保证每天的产出，到了晚上就感觉好累好累，不想再碰电脑。

这半年的时间，如果说我有进步的地方，就是学会了如何保养自己的身体。每天回家，我几乎都是先看半小时书，然后做一会儿简单的运动，再洗个澡，泡个脚，喝杯牛奶去睡觉。周末的时间，由于不放心外面的食物，我学会了下厨，于是周末两天我的大部分时间都是在一堆锅碗瓢盆中度过的。

前言

10个月前，我写了一篇解读欧拉影像放大技术的文章 Eulerian Video Magnification，这篇文章自发布以来，点击率超过了1300次，评论数达到了29篇。如果你在 baidu 上搜索“Eulerian Video Magnification”，我的文章排在第二名（第一名是原论文的链接）。而如果你在 google 或 baidu 上搜索 “欧拉影像放大” ，那么第一名的位置就是我的文章。

一个促使我写出这篇博文的原因是因为我的毕业课题就和 EVM 算法有关。当时想着既然一直在钻研这个算法，不如干脆写成博文，一来帮助自己思考，二来也能够通过与其他人交流，加深自己对这个算法的理解。我的论文的想法也很简单，EVM 对于存在大幅度移动物体的细微变化的放大效果并不理想，于是我想到通过与拉格朗日视角的框架相结合，先对感兴趣区域进行跟踪（拉格朗日视角），然后对跟踪结果进行局部的欧拉视角的动作放大，最后再进行多分辨率混合。整个算法框架我称之为“前景约束的欧拉影像放大算法”（Foreground-Constrained Eulerian Video Magnification, FCEVM）。

GodEyes-iOS 是一款针对 iOS App 的源码 crash 隐患扫描工具。特点包括：

1. 专注于 iOS APP 代码的 Crash 隐患静态扫描。
2. 扫描规则提取自 APP 的典型 crash 案例代码，并且在持续增加中。
3. 扫描规则可定制，提供多种格式的扫描报告。

一个典型的过程是每次完成你的 iOS 项目的迭代后，就使用 GodEyes 扫描一次你的工程的代码。然后打开扫描结果，定位到上面列举的存在隐患的代码，确认一下是否存在隐患，然后对问题代码进行修改。你也可以很轻松地将它作为持续集成的其中一步，通过解析生成的 json 结果文件，得到当前的代码隐患情况，并作为判断持续集成状态的其中一个项目。

GodEyes-iOS 还有一个兄弟 GodEyes-Android，顾名思义，GodEyes-Android 所针对的是 Android APP 源码的静态扫描。

下文将重点介绍 GodEyes-iOS。出于方便，下文一律将 GodEyes-iOS 简称为 GodEyes。

自从我将博客的主题 Freemind 开源了之后，我收到了很多朋友的来信，希望我也能把博客里的 Wiki 部分也开源。

当初没有将 Wiki 的部分放进博客，主要是考虑到主题的简单性。原来的主题包含了很多我个人的特殊定制，虽然自己用着方便，但对别人就不见得适用了。比如，由于我的博客有 post 和 wiki 两套主要的 layout，为了创建草稿的时候有所区分，原来的 hexo new 就不适用了，于是我都是用自己写的工具来创建草稿。再比如，由于是自己用的东西，也就无所谓代码的模块化，有些 hard-code 的地方要做到灵活可定制又得折腾一顿功夫，而且太多定制项又会增加用户的学习负担。考虑再三，我决定将 Wiki 部分去除，尽可能保证主题整体的简单和模块化。本来我开源了 Freemind 主题后也不打算再写其他主题了，但因为来信询问 Wiki 主题的朋友实在太多，于是也给了我动力编写第二个主题 Wixo 。