装 2 个摄像头，挂载在无人机上做物体识别，执行实时测绘任务，4 的性能刚刚好

正好刚刚在学五笔，第 1 周极其痛苦，现在我已经第 2 周了，说说感受：

1. 五笔的规则还是好记忆的，基本 1 天就能学会规则，对着码表打几个字了
2. 但是，拆字的上手非常痛苦，总觉得特例特别多，有种小学生从头学写字的感觉
3. 以及，最难的是很多字完全忘了怎么写了，数位时代的提笔忘字
4. 五笔的直觉感不如双拼+形码，双拼是一想到字，先就把辅音打出去了，回头再来想是什么字，不会错，五笔就不行

总的来说，不如双拼+形码的方案，比如小鹤双拼，而且速度也是差不多的

多年 vim 党，去年在年青同事安利下，开始用 spacemacs，从此进了 emacs 的坑。然后有了如下心路历程历：

1. spacemacs 东西太多，慢，想用原生 emacs
2. emacs 的键位好怪，可能要改一下 keybinding
3. 看网上大神推荐用人体工学键盘，开始 taobao
4. 客制化键盘好酷，ergodox 好酷
5. 家里己经没地方放更多东西了，主要是租的房子太小了
6. 现在上海房价多少了?

@qazwsxkevin 就是循环生成规律变量名的变量并赋值是吗？就用反射好了

方法 1，对当前 module/class 使用 setattr
```
>>>import sys
>>>thismodule = sys.modules[__name__]
>>>setattr(thismodule, 'table1', 1)
>>> table1
1
```

方法 2，使用 vars()或者 2L 说的 globals() #前者是当前 module，后者是全局
```
>>> vars()['table2']=2
>>> table2
2
```

ACM 三个人，一个做题，一个翻译，一个送盒饭 🤣 不过讲真的，ACM 有时候的怪题蛮拼体力的

@linlance 大型项目还是要用 java 或 c#，python 的框架 django 是最强了，但是一庞大起来，或者业务复杂起来，每一次重构都是痛苦。

Django 我从 0.96 开始用，除了他的 mttv 范式现在有点不时髦，其他就没怎么烦恼过。flask 经常有这样那样的问题，主要是第三方的问题，但是也挺难受的。本来咱用 python 就是图方便，flask 适合将脚本输出服务，Django 适合快速搭建简单业务，但是项目一大型还是上工业级框架吧

@ironMan1995 路飞这账号一直都是讲假故事的，很多年了许多网友也都知道这个账号就是这个风格。但是那次运动影响面很大，而且确实“假的”故事对不知道上下文的网友来说很很多的误导性，所以我觉得删了这个号也实属应该。

然而这就是另一个话题了，就是知乎应不应该允许“虚拟的人设“存在。从种种迹象来看，在一定程度上他是允许的，张佳玮一定意义上就是这一样一个账号。

@keelii 我觉得知乎并没有把自己当作是“知识”平台，而是“故事”平台，让有趣的人分享有趣的故事，让有知识的人分享有知识的故事，从一开始找各种名人来答疑解惑，我觉得就是这种操作。而讲故事这件事，和个人的意识经验有很大关系，人和人的心智是有距离的，所以必须要包容，就像文章《“围剿”知乎第一大 V 》说的一样，张佳玮这样的才是知乎精神，而围剿他的网友们虽然也算是一种理性主义的知乎精神，但两者相冲突时，前者才是知乎的根本。

毕竟同时代的另一个知识社区 果壳网 现在又有多少知名度呢？

大众传媒和知识分子的讨论空间是有很大差异的，大众传媒有大众传媒的意义，只要核心内涵都是真善美，我觉得知乎优先追求流量这种事情也无可厚非，毕竟你不做也有别人来做，起码比微博和头条的格调还是高一点的，年轻人因为有趣被吸引过来，再在知乎上寻找有意义的知识，也算是一种教化了。

但是两种内容无差别的点赞让知识内容的输出者感到挫败，应该把有趣和有用两种点赞分开来，分别排名，分别索引，这样可能才是一个雅俗共赏的局面。

thinkpad x250，用了 4 年了，还能再战几年。读书的时候用的 mbp 15，用也用了 4 年，但第 4 年的时候已经各种问题了，软硬件的都有。

我是习惯遇到需求先写个 python 脚本，用简单的数据或者场景模拟一下，然后直接并入 django 写的系统提供对外服务。非常简单。

当然作为写了十年 python 的程序员，我也不得不说 python 在很多方面有他的缺点，别的不说，就说这个语法吧，代码一多就一坨一坨的，没啥优美性可言。

做每一件事情都有这个过程，抓耳挠腮百思不解，在多少个犹豫不决的苦恼和费力的通宵后，突然的就明白了。
我读书的时候搞编程是这样，创业以后学做项目管理是这样，后来学和客户打交道也是这样。

所以我现在和我的刚入行的同事说，学一个新技能不通几个宵（比喻）是不行的。

drf 需要显试配置的地方还是不少，CRUD 之外的操作，需要更多的带入到框架的逻辑内，业务复杂的时候反而显得麻烦。不过他帮我们把一些基础建设都做好了，在 Django 体系里暂时没有做的比他更好的。

不过主要 Django 本身的体系和结构也比较简单，而且是大包大揽的方式，所以 drf 的处理无可厚非。在一些更有分层和结构要求的框架和语言下，类似的框架会更有通用性，解决的问题更专一，当然使用起来也更复杂。

nodejs 里 nestjs 框架有一个 nestCRUD https://github.com/nestjsx/crud 我觉得是比较接近 drf 的，不过他是用了 nestjs 的分层架构，所以和 django 还是有很多不同。但是鉴于 django 和 drf 比他们成熟的多，而且他们俩本身是一揽子方案，没有外部依赖，所以一开始用 nestjs + nestCRUD 会不太适应。

@lihongjie0209 明白你的意思了。这个确实和 UoW 的概念没太大关系，UoW 主要作用就是事务。DDD 的设计战术之一就是一次操作只能修改一个 AR，所以需要 Domain Event 之类的东西来做关联，UoW 让各 AR 实现最终一致。

你这个例子中，确实没法在 Domain 或者 Application 层做相关的操作，因为对 Domain 他不关心持久化，对 Application 他只能看到 AR，不知道里面具体的实现。

这里你提问的半自动化 ORM，就是类似 Dapper 这样的吧？这些 micro-ORM 更多关注的是 M，而像 Hibernate 或者 EF 之类的更多的关注的是 O，也就是说前者还是一个面向数据库，效率高，透明轻快，而后者是面向对象，但是重量，不透明。在 DDD 中，领域对数据库无感知，甚至很多实践还强调聚合根里能用值对象就用值对象，所以无法在 Domain 中体现从对象关系变化映射到数据库变化的关联，这些都是由 Repository 完成的。

那么在如 EF 中，这种关联是自动实现的，因为他有 changetracker，另一方面，他还自己实现了 UoW。而 micro-ORM 没有这些，那就只能手动来做。具体的可以在 Repository 的实现中，对 AR 下的各 entity 的修改进行检查、保存。代价就是每一个特殊的检查都需要手动实现（或者如你的思路 2，自己实现一个 changetracker，如 Dapper.Contrib 就有类似的实现）。另外有些思路中，会拿 ORM 和 micro-ORM 混用，取两者的优点于一身 https://msdn.microsoft.com/zh-cn/magazine/mt703432.aspx

@lihongjie0209 这里篇文章讲了具体的实现 https://github.com/sheng-jie/UnitOfWork 。

因为 UoW 统一了持久化方法和事务，所以就可以用 AOP 的方式在框架层面对 UoW 进行隐式调用，如 ABP 的做法： http://www.cnblogs.com/1zhk/p/5309043.html

UoW 的作用是追踪 entity 在多个仓库间变化的依赖关系，自动帮你解决事务方法，让事务和持久化在多个聚合中保持统一，但是 IRepsoitory 的方法调用还是需要的。如果你的意思就 tracking changes 然后不调用 IRepository 更新的话，这个可能需要 orm 本身的支持。

@lihongjie0209 我指的是在 application 层对 repository 的显式调用，比如你说的 update。在实践中，repository 会用 IRepository 的形式作为基础设施服务，这样 application 就和具体的 orm 解除关联了。当然一般情况下，都会使用基础框架的 UoW 完成隐式更新。