Intro:杂谈

Productivity

生产力是什么?

是应用吗?是也不是。那些经典的时间管理应用、笔记服务、写作编辑器一套下来,年订阅费上千,我也没有能力一一尝试。它们确实很强大,在 Omni Focus 上管理任务,在 Drafts 上书写文字或者在 MindNode 画思维导图的体验绝佳,但它们只是工具,使用的效果完全是由使用者决定的。

是理论吗?是也不是。我看过心理学方面的书与文章,它们也都并不是万能的。且不说很多内容都是在贩卖鸡汤与焦虑,很多东西,做起来比仅仅弄懂要难多了。

到了后面,这个话题似乎变得越来越沉重了。因为“生产力”这个概念涉及了太多。狭义上它是功利主义在一切领域的投射,广义上,它是所有方面的平衡指标。GPA 可以作为生产力衡量的一部分,工作质量也可以,爱情、友情和亲情一样可以——说白了,给生产力总结换个名字,“个人总结”就足够了,但我个人认为我对生产力的了解,还不足以吧“个人总结”应该写的内容全部搬上来,所以有机会,我还是另外写一篇所谓的“生产力总结“吧。

扯远了… 根据一个开发者的视角,还是先从技术说起吧。

Deep Learning

从这一部分开始,就是充满槽点的计算机领域了。而槽点最多的,当属 Deep Learning 这个分区。

我承认自己在这个领域是错漏百出。首先,学的东西(尤其是跨编程语言的时候)并没有成一个体系,而且绝大多数的用法只不过是一种记忆。再有,我现在也只不过是一个搬砖小工,并没有做出一些很前卫的实验——我能做的不过是不停的 Google 然后把这个项目一点一点的复制粘贴过来。到了 Deep Learning 的时候,我是完全能体会到这一点的——囫囵的把视频看过去,做笔记,然后跟每周的 quiz 和项目做斗争。到了最后,我最熟练的其实还是用 Keras 搭建一个模型,而搭建一个图片识别模型,只要上过几节 Python 课的人都能做。

Full Stack?

计算机领域的知识很庞杂,每一根枝条都可以耗费一个人的毕生去攀登。我只是想先爬上树,好好看一看再决定往哪边爬。

2018 年是深度学习被捧得最热的一年,然而我知道这意味着什么,每次看见那些“AI 科学家年薪百万”推文,我都会脑补几百年前,荷兰一株郁金香能换一座豪宅的“盛况”。深度学习被“炒冷饭”炒起来的这第二波潮流,已经走过了7 个年头,容易摘取的果实大抵已经穷竭了。

21世纪有过大量的引爆点。如果说 2010 年前桌面仍然存在红利的话,2017 年又已经给移动 APP 市场的大热敲响了警钟 —— 如果说在2010年以前,桌面端依然能从PC销量增长中获得红利; 15-17 年前,市场尚未饱和,移动端和 Web 依然可以相对轻松的抢占 Offline 市场,那么到了这个时候,它们昔日对抗 Offline 的战友已经变为了敌人,为了用户群体那有限而宝贵的时间与注意力而大开杀戒。时间和注意力像19世纪的美国西部金矿,刚来的那批牛仔转的盆满钵满,后面的那批和前面的那批大开杀戒,而当行政和法律终于到达这片领土的时候,再后来的人只能黯然离场。

下一个引爆点事什么?我们不知道。下一个被引爆的技术栈是什么?我不敢说。

但我可以多去接触每一种技术栈的可能,然后加深理解。

项目

这个寒假有三个项目:KLego 2.0,CalcTex 和 Hackintosh to Go。三个项目都由非常丰富的分任务组成,给我的感觉,能保持不太监的状态就已经不错了。

KLego 2.0:从新特性讲起

KLego 原本是一个面向新手的 LEGO NXT 编程框架。最初这只是一个 Wrapper 工程,把人家已经写的差不多的内容导入,包装的更简洁一些。但是到了 2.0,我希望实现的内容显然多了很多。

进度:编译器和通信协议正在重新设计。

编译器

KLego 2.0 最初将它视为一个不可能的特性,可是实际上,这是可行的,已经有人做了出来。如果看到了这个希望,我肯定也要把它做出来,因为 Demo Day 拖着长线的屈辱简直是……

pynxc 就是这样一个项目。我读了最初的那篇论文,作者承认他也找了很多 Python to C 的框架(比如 Shedskin 和 Cython),但是那些框架对 Python 环境依然有着严格的依赖,因此无法放到 NXT 上面去,于是他只好采用了看起来“最蠢”的方法——把 Python 代码转换成 NXC 代码,然后用编译执行体编译成可执行的二进制文件。这套工作流非常清晰易懂,唯一比较费解的部分是中间的”P to C“编译环节。

我曾经想,把代码替换掉不会是一件很难的事,可能一个主文件就可以搞定一切。但后来,在仔细分析了需求之后,我觉得我可能需要一个更复杂的结构来实现编译器。

with 引导的全局锁

在编写 KLego 1.0 的早期,我就碰到了并发的问题。但由于在此之前我甚至连线程池都没有用过,自然没有做预防措施,以至于看到 NXC 这么”简单”的语言都原生支持线程锁(称为 Mutex),真是想当场面壁。

在 NXC 中,可以使用 Acquire() 这个 API 函数来获取线程锁,并用 Release() 来释放,但是在 Python 中,为了充分利用语言的特性,我希望能够使用 with safelock: 这样的结构来实现这个功能。为了显得更友好,模块会提供一个全局的 safelock 对象供直接使用。

从 Python 运行环境的角度上来讲,with statement 设计出来就是这么用的,可是,从编辑器的角度来看,with 块并没有特殊的意义,只不过是一些替换性质的工作,编译工作就会变得不灵活——如果为了这个项目我要从 AST 树学起,参透整一本《编译原理》,那还不如直接去上大三。

修饰器

在做 2.0 草案的时候,为了让 Python 和 C 这两种类型机制迥然不同的语言能够和谐相处,又受到了 Flask 框架的启发,我决定加入装饰器。

实现的细节是在每一个本地(在 Brick 上)执行的函数前加上一个“声明“,然后编译器就可以获取这个函数的指针,进而通过 Inspect 模块获取源代码。这样管理起来会方便很多。这样一来,本地和远程的代码甚至可以写在同一个文件,运行一遍就可以部署本地程序并开始同步。

但是修饰器这个 idea 出来之后,算是标志着原先思路的破灭——原先的思路是将代码当作一个字符串来进行“静态编译”,但经手修饰器之后,代码就变成“动态编译”了,可以随时加入需要编译的函数和文件。同时,编译器也可以通过限制格式(比如,通过装饰器函数要求给出函数的类型)来摆脱C的一些限制。又或者,我们可以进行强制语言特性检查,禁用一些高级特性,来降低编译的复杂度。

通信协议

NXC提供了相关的 API 使得我们可以进行蓝牙通信,nxt-python也是如此,这使得异步协作成为可能。机器人在前方探索,然后计算机做计算支撑。终极目标是让深度学习这样的计算任务实现与本地的分离。

通过 with statement,语法上的使用难度会大大简化,但是这个特性也进一步提高了对”动态编译”的要求。

Hackintosh to Go:节外生枝

那天我和 Mason 逛旺角的电脑城,碰到一家硬盘专卖店,600多HKD可以换到一块500g的860 EVO 固态,于是就心动了。当然,除了用来装素材和数据,这块套盒的EVO还可以实现一个久久未能实现的心愿:给游戏本装上macOS。

macOS 可以满足我的很多需求:稳定的 iCloud, Continuity 和AirDrop 与 iPad 享受生态加成;类UNIX的开发环境;丰富的 Markdown 编辑器;Xcode 和 Final Cut Pro;漂亮的 UI;更顺手的快捷键和触控手势等等。

如果遇到 Mac,也可以直接使用自己的系统和数据,免掉一大堆登陆什么的。但在调研的过程中,学校的 iMac 是没法用了,因为固件密码杀死了从外部磁盘启动的可能。

进展:进行文字工作体验很好,但开发环境还没有搭建完。

APFS

APFS 文件系统是此项目最头疼的非致命问题。

该文件系统使得在 Darwin 内核的系统上操作磁盘分区的可能性为负。为什么是负呢?因为我 几次尝试修复错误,却把系统 corrupt 掉了,后来为了数据安全,被迫取消了允许 Windows与 macOS 文件相互修改的设定。安装的时候,也是采取了将空 HFS+ 分区转换为 APFS 的选项(而非常规做法,抹掉再重新分区)才幸免于难

内核扩展

好吧其实大部分人都把 kext 归类为驱动,直译成内核拓展实在是有点不接地气。不过 kext 能够管理 macOS 的文件系统,也确实够硬核的,因此在 Hackintosh 中它可是至关重要。

在已有的 Github 项目中,大多数的驱动已经加入,进入系统之后运行良好。但对于这个项目,我还是发现了一些情况:

  • USB注入补丁会造成 Kernel Panic,具体的调试信息显示另外的 USB kext 在加载时出现了无法解释的超时,阻滞了其它驱动的加载。
  • NoTouchID 驱动似乎解决了一些权限方面的问题。没有应用这个补丁的时候,除了终端 sudo 以外的授权都会卡顿。此外,在配置中曾经出现不明的突发重启,多次还原备份后无解,但不清楚这个权限是文件系统损坏造成的,还是因为授权故障。

工作生态

在不分盘政策的影响下,经过一个学期的折腾,我的游戏本收获了史上最大的 C 盘,接近300G。这包含了所有的程序 —— 从 Adobe 元素周期表到又丑又慢的 Matlab,也包含了配的近乎臃肿的环境 —— pip2,pip3 和 Anaconda 上塞满了一模一样的炼丹大礼包(没错就是 tensorflow 之流…)。每次开机的时候,iCloud 和 SSH 服务端和 Windows Defender 的例行扫描同时启动,风扇响的非常尴尬。

Windows 系统就像是一个没落的大城市,唯一能够挽留我的就是能够驱动显卡的能力。留着白天打开,做远程炼丹炉就好。如果要跑渲染,也无可厚非。只是有一件事情:Windows 桌面必须改造,快捷方式一个都不用留,反正都是用启动器启动的。

macOS 其实能够满足很多的任务了,比如轻度的 FCP 和修图,还有开发的各项任务。唯一不习惯的就是 macOS 的“慢一拍”,写起东西来好像连键盘的反应都慢半拍。这导致在 Win 下猛如虎的操作——动不动加一个桌面,新开二十多个标签页的 Chrome 窗口,在 macOS 下都收敛了许多。但不得不承认 macOS 更让人有工作的欲望,尤其是文字类的,因为这里的字体渲染更养眼,优质的编辑器十分丰富,文字输入的快捷键也更实用。

潜在问题

  • 无法解释的 Kernel Panic
  • 触控板的驱动有待提高,虽然手势的支持比较全,但和实际的差距还是有点的。

CalcTex:公式分步解答的微信小程序

在期末复习的时候,我几经磨难,配合 JSbox 做了一个捷径,可以把 LaTex 公式转换成 Wolfram 语言搜索答案。配合 MyScript Nebo 的识别率,效果奇佳。但这套解决方法对于一般用户有着很大的局限:首先,捷径只适用于 iOS ,并且门槛不够低;其次,Wolfram 在国内的使用体验是比较糟糕的。

我曾经尝试过 Windows 的墨迹公式,但很遗憾的是,尽管它有比较高的识别正确率,解微积分的步骤似乎给不出来。于是,CalcTex 这个想法就这样诞生了:初级需求是解决 LaTex 公式的计算问题,附带一个图片公式识别。

进度:公式识别模型的 bugfix 还没有结束,因此需求可能要搁置了。服务器后端基本已经完成,前端等待 UI 适配。

Why Mini Program?

微信小程序算是目前最轻量、入口成本最小的前端了。尽管我后来知道有像 Flutter 这样的“大一统”前端框架可以选择,我还是决定先从小程序做起。

Why Flask?

后端有过三个选项:PHP, node.js 和 Python 的 Flask 框架。

考虑语言风格和”新兴程度”的时候,我决定本次项目不采用 PHP。node.js 的技术面因为与小程序重合,再加上数据模型暂时是以 Python 搭建的,我也放弃了它。于是,Flask 框架就这样被选下来了。

更新(19-04)

目前这个产品已经改名为 Camculator,但是后端系统依然被命名为 CalcTex.

没有想到 Camculator 可以进入创业省赛……在这里感谢 Camculator Team 小伙伴们的付出 ^_^,大家都好棒

(to be continued…)

Leave a comment

Your email address will not be published. Required fields are marked *