分类目录归档：编程

最好的技术构架

最近看到一篇文章，里面谈通过Java替换之前的Python实现使服务的响应速度得到了很大的提升。同时又看到有公司通过Go替换Scala，取得了不错的效果。

似乎是Go>Java>Python？显然不是。

在项目启动的初期你很难预计到自己的项目最终将长成什么样子，最终能达到多大的规模。你能做的只是给出一个较清晰的中短期规划以及一个较模糊的长期规划。然后思考如何在满足要求的情况下尽快的把东西做出来。毕竟事情不会不完全按照你的预期发展，看上去在完美的构架也不可能一直完美下去。根据需求持续的演进才是正道。

关于性能：

由于需要服务海量用户，因此在提到互联网应用的时候很多人都对高性能有着异常的执着。经常听到有人说XX语言慢，XX框架慢。但实际上脱离了需求和构架单纯谈的语言/框架性能是没有意义的。就如Instagram至今依旧用着以慢著称的Django（注：其实我也挺好奇为啥没有将Django换掉。按照我的理解Django的有点是功能及资源丰富，性能方面确实没啥优势。按说Instagram对Web框架的功能需求应当非常少，换个更轻量高效的似乎会更好些？）。

另外优化的成本实际上也挺高，在早期用户不多的时候对性能的优化或许还不如直接加硬件来的实惠。

Django 2.0放弃Python 2的支持了

Django的master分支已经正式切换到Django 2.0了，其中的一个commit就是去掉Python 2支持的相关代码。这意味着从Django 2.0开始，Django将要放弃Python 2.x的支持。
对于这个消息，Reddit上一片喜大普奔。对我而言这绝对是一个好消息，毕竟我还是非常喜欢Python 3的type hints。如果放弃Python 2的支持，他们还是很有希望会加入type hints的支持。
从去年开始，不少最新的Python库只支持Python 3。另外type hints加入让甚至可以说让Python更像一个新的语言。或许Python 2终于要开始淘汰出局了。对我而言，除了老项目的维护外，新项目似乎没有什么理由再支持Python 2。

注：根据Reddit上的回复，由于model里用了太多的magic，model这部分要加入type hints还有很多问题要解决。不过可以肯定的是type hints绝对会是今后Python库的大方向，Django也是会支持的。

Python 3的type hints

近年来新出的语言Go、Rust、Swift都无疑例外的是静态类型。随着软件的越来越复杂，动态语言“太过随意”的缺点也越来越明显。此外随着IDE的发展，静态类型语言“繁琐”的缺点也得到了很好的规避。
在学习Swift的时候，Swift的类型推导给了留下了很深的印象。类型推导或许是现阶段兼顾类型检查以及动态语言简洁的最佳解决方案。
Python从3.5开始加入了type hints（类型注释）。

def greeting(name: str) -> str:
    return 'Hello ' + name

从名字“type hints”就可以看出，只是类型注释并不是强制要求。由于只是“注释”，“type hints”需要第三方工具的配合。你需要使用Mypy来对代码进行语法检查。另外PyCharm在新版本中也加入了对“type hints”的支持。

对我而言“type hints”无疑是一个非常棒的特性，让Python也具备了类似Swift的类型推导功能。希望日后的各类Python都能加入type hints的支持。另外就希望各类开发工具可以充分的利用type hints特性。

注：
Swift中使用“?”表示option，Python里则需要写成Optional[str]相比之下有些太过繁琐。

相关链接
- Mypy
- typing — Support for type hints

Docker

很早之前就听过Docker，当时感觉对个人使用而言Docker似乎派不是太大的用场。

Docker非常类似虚拟机。如果单纯出于统一开发环境的考虑，直接用虚拟机似乎还更直接一些。
虚拟机+ Vagrant也可以方便的对虚拟环境进行管理，Docker在这方面似乎也木太占优势。
Docker通过仓库分发Images，似乎同直接复制虚拟机的镜像效果也差不了太多。
由于并不需要管理大量的服务器，直接手动部署或用部署工具操作也不会太过复杂。用Docker还得学习Docker的使用，似乎也不太值得。

近期由于Discourse的缘故，实际用了一下Docker。感觉Docker确实是个不错的东西，不论是开发还是运维Docker都是值得使用的。

Docker有啥好处

Puppet, Chef等传统的运维工具可以实现应用的批量以及自动化的部署。但实际工作中，用户的系统千差万别，可能换个系统环境你的脚本就挂了。
对开发人员，可以使用统一的虚拟机作为开发环境。但虚拟机无法直接部署到生产环境。生产环境、测试环境、生产环境无法做到统一。很可能开发环境跑的好好的，一到生产环境就出各类莫名其妙的问题。
Docker 容器的启动可以在秒级实现，这相比传统的虚拟机方式要快得多。其次，Docker 对系统资源的利用率很高，一台主机上可以同时运行数千个 Docker 容器。
使用Docker可做到“各类环境”的完全统一。不论用户原始的环境是什么，真正跑应用的环境都是一样的。由于在开发阶段就已经把环境完全整好了，只需要简单的几个命令即可完成部署，Docker的部署异常简单。由于不用考虑系统的差异，Dockerfile写起来相对来是比较简单的。

OA平台技术分享

为公司其他部门做的技术分享，在一定程度上也算是在公司内部推广Python。不过很不幸的是由于某些原因，该分享不幸夭折。

PPT在这里：http://vik.haoluobo.com/static/slide/oa/

下面是更为详细的文案。

OA平台概况

Nginx
- 使用Nginx作为前端服务器，负责静态资源处理及HTTP请求分发
- 在需要扩展到多服务器时，Nginx可以用做负载均衡服务器
UCenter(统一认证中心)
- 统一的用户登陆管理
- 用户信息存储在公司的AD域中
OA
- 业务平台，公司的行政、人力等各项OA业务都在该平台搭建
- 同携程、inTrack平台对接实现相关业务
- 数据的汇总及分析

OA构架

基于Django搭建的可插拔APP平台
- 核心APP（基础APP）
  - 核心APP包括：UI框架、权限认证、流程引擎、用户、员工、部门管理等
  - 作为系统的核心模块，需要被其他各个业务模块所用到。
  - 为具体业务做支撑，大多不同具体业务相关
  - 核心模块在系统上线后将不太做改动，只需要少量的核心开发人员维护即可
  - 核心模块也是可复用的
    - UCenter同OA就是公用的相同的UI框架
- 可插拔APP（业务APP）
  - 可插拔APP包括：人力模，请假出差、财务模块，报销、预算、行政、固定资产管理…
  - 同具体业务相关，依赖核心模块。
  - 业务需求多，且易变，在平台建设初期难以做周全的计划。
  - 各个业务模块相对独立，各业务模块可独立开发。
  - 多个业务模块可由多人并行开发。

Django

The web framework for perfectionists with deadlines.
全功能的Web开发框架，依托Python提供快速开发的支持
– 提供模板、控制器、URL路由、表单、验证、ORM等各项Web开发需要的基础功能
– ORM及其强大，即使不懂SQL也可使用。
– 支持数据库的版本管理，并可自动更新线上数据库结构
– 模板支持继承清晰易用，对前后端分离提供很好的支持。
- 成熟的社区环境，大量现成的APP可用
- 被广泛应用，有成功易用范例：Instagram、OpenStack

流程引擎

采用Python自主开发
编码同配置结合在确保使用便携性的同时确保的功能的强大
- 表单、业务处理逻辑编码实现
  - 数据模型通常变动不大，采用配置方式实现不但实现复杂，也不会能为开发维护带来多少便利
  - 流程常用的，同意、驳回、打回、撤销等基础操作流程引擎已自动实现，不需要额外开发。
  - 如在流程流转需要进行特殊操作，需用代码给出对应的实现。
    - 比如新员工入职流程结束后需要自动在系统中创建员工账号等
  - 配合代码生成器的使用，对于标准流程编码工作流程只需要完成数据模型的设计即可。
- 流程流转用配置实现
  - 流程的审批节点，审批人变动概率较大，采用编码方式实现既不方便又不灵活
  - 流程流转的功能需要比较清晰，使用配置方式即可比较好的满足需求
    - 流转方式：抢先，会签
    - 流程节点的审批人、周知人、权限分享。
    - 流程分支支持
- OA上所有流程都基于流程引擎开发
提供代码生成工具生成流程框架
- 对于简单的流程，只需要实现数据模型即可生成完整的业务代码

Why

Why
- Python
  - Python is powerful… and fast;
    - 这里的快更多的是开发速度快。语法丰富，简洁
    - 开发效率高是我们选择Python的一个重要原因。
      - 信息部就2人，需要负责需求整理、设计、开发、测试所有工作，对开发效率要求非常高。
    - 不需要编译，启动时间快节约开发时间
      - 一个大Java项目编译要超过一分钟，Web服务器启动又会超过一分钟
      - OA对比原有的KM。KM启动时间超过1分钟，OA可在5秒内完成重启。
    - Python本身并不慢，
    - 真正影响性能的代码所占总代码的比重很少。
      - Python可方便的同C集成，用C扩展性能
      - 注：使用Cython可直接在Python里写C代码以提高性能
      - 目前不少性能敏感的库都采用C扩展的方式进行加速，方案成熟
  - plays well with others;
    - 对C友好，使用ctypes可直接使用C接口的动态库
    - 很多软件都有提供Python接口。如：OpenCV、MATLAB
  - runs everywhere;
    - 支持几乎所有的操作系统（包括各类嵌入式系统）
  - is friendly & easy to learn;
    - 非常容易入门。对有经验的开发者，花一天时间熟悉语法就可直接使用
  - is Open.
  - Python的第三方资源足够丰富，应用也足够广泛
    - 有很多采用Python的成功应用
      - OpenStack、Dropbox、Youtube、Mercurial
    - 虽然比不上Java，但Python的资源也非常丰富。
      - Django(Web)、Cython(在Python中直接写C)、NumPy(可选计算)、PyQT（UI）、QPython(Python on Android)
  - Python无所不能，但并不适合做所有事情。比如Android移动端的开发还是用Java更合适
  - 开发效率高
    - 信息部人少，需要快速实现需求
    - Java严谨、Java有接口等概念，在大项目协作时更容易。但由此带来的开销是在小团队情况下开发效率更低。
- Django
Why Not
- Java
  - Java严谨、Java有接口等概念，在大项目协作时更容易。但由此带来的开销是在小团队情况下开发效率更低。
  - 信息部是个小团，Java带来的好处不如优点大。
  - 即使是一个大团队，也可通过模块化的方式来减少规模化带来的沟通开销。除阿里这样的超大公司外，很多时候Java都不是一个很好的选择。
  - Java在Web开发方面一直是由多个开源项目所推动，本身就缺乏一个很好的体系。
    - Java的各个开源项目独立发展，在开发初期并未仔细考虑过如何同其他项目协作。
    - Java主流实现都是围绕如何实现一个超大规模项目来设计，对小项目来说负担太重。
    - 使用Java实现一个非常小的功能也需要写大量的代码及超多的XML配置。现阶段Java开发已经简化很多，但相比Python依旧太过繁琐。
- Node.js
  - 近年来前端技术发展非常迅速。
  - 前端开发只能用JS，因此会JS的群体非常广泛。
  - Chrome V8，Node.js将JS引入服务端，收到广大前端爱好者的支持，迅速发展。
  - Node.js天生异步，有着不错的性能。
  - 使用callback实现异步，大量的callback导致代码不容易理解。
- redis(Cache)
  - 开发应当优先考虑功能的稳定性，然后才是性能问题。
  - 性能问题更多的是构架问题，应当优先优化构架。
  - 以我们公司的规模还远没到需要增加缓存的情况。
  - 缓存会增加系统复杂度，也可能带来一定的潜在风险。

前端技术构架

UI
- AdminLTE(Bootstrap)
  - 信息部人少，缺少专业的UI及前端人员，尽可能的利用现有可用的资源。
  - AdminLTE是一套基础Bootstrap的界面框架，提供了大量基础的界面功能。
  - Bootstrap是当前非常流行的前端框架，有着丰富的资源。
JS
- 使用Bower管理静态资源。
  - 静态资源的包管理工具
  - 方便静态资源的升级管理
  - 避免将静态资源直接复制到代码库，为代码库增加存储以及响应压力
- JQuery
  - JS事实上的标准库，可极大的加速JS开发。
- formset.js、datepicker等
  - 实现formset，日期选择等节目效果。
- 使用Django-Compressor进行静态资源的压缩优化。
Why Not
- Webpack
  - 近几年前端发展速度非常快，前端开始变的复杂。JS不仅仅是为Web页面锦上添花。为配合使用JS进行大规模项目的开发，需要相关工具进行配合。
  - 前端打包工具，可对JS库进行依赖管理，控制JS包的按需加载。可对JS/CSS编译(ES6/TypeScript/SCSS/LESS)，压缩，图片优化等
  - OA前端应用相对比较简单，Django-Compressor可以满足要求现阶段需求。相比Webpack能带来的好处，没必要为项目增加不必要的复杂度。
- React
  - 用来构建用户界面的 JavaScript 库
  - 更适合单页面的应用，如为手机提供类似APP的体验。
  - 不采用原因同Webpack一样。

LBForum后续计划

开源应当是一件很认真的事。

保证持续的维护与更新，保证该项目的活力。
有完善的测试用例，方便在添加功能以及merge其他人的改动后进行功能测试。保证软件的质量。
完善的文档，让初次接触该项目的人可以快速的知道如何使用。

我写的一些东西基本上都是出于个人兴趣，因此有些随性，兴趣来了就写一写，兴趣过了这个项目就荒废了。
LBForum曾一度荒废，近期由于集成到公司系统，顺道做了一些更新。接下来可能还会陆陆续续做些更新。

增加Python3的支持
- 单纯的增加Python3的支持并不难。由于我的测试用例并不完善，增加Python3后测试的工作量会增加，因此一直没有做。
- 注：现在以及可以支持Python3了。比预计的要顺利不少，只做了很少的改动就完成了Python3的支持。
增加Rest接口
- 之前的Rest接口一直都是手动实现而且也还挺方便，想试试Django REST Framework看能减少多少工作量。
iOS的论坛APP
- 一直想做个移动APP，刚好用论坛来尝试一下。
- 第一个版本应当只有浏览功能，登陆、回帖、发帖等功能将在日后逐步添加。

React

之前简单的对比过React和Vue.js。React组件化程度很高，粒度很细，“模板”分散在整个JS文件中。Vue.js模板和JS文件分离，看上去要清晰不少。当时比较倾向于Vue.js。
近期又去了解了一下两个框架。Vue.js居然也计划要支持JSX了，模板和JS分离这本是我偏好Vue.js的一个重要原因。此外就网上的评价来看Vue.js的坑也并不比React少。考虑到React的背景，以及周边成熟的生态环境，决定再给React一个机会。
把React的《QUICK START》完整的看了一遍。React的入门并不难。如果不想将系统改造成“单页面应用”，只将页面上部分功能组件化也不存在困难。React的粒度很细，但拆分完后各部分会比较简单。
按照React的说法，React会颠覆大家对传统Web开发的认知，但一旦熟悉就会发现这很棒。
React是否真的很棒？因为没真正用过，还不敢断言。但React的组件化思想还是有些意思，本身的概念也比较清晰，加上并不复杂，或许值得一试。

目前项目用的一些东西

项目基于Django构建，如果你们也在用Django，可以参考下。

源代码管理 HG

之所以用HG完全是因为公司代码库用的是HG，如果让我选当然更愿意用Git。大多情况下HG也已经够用了。
项目中开发的Python公共模块使用submodule的方式引入。采用submodule的方式对子模块的更改和更新都会比较方便。

JS等静态资源管理 Bower

作为一个Web项目自然少不了用到jQuery等第三方JS库。将这些第三方库全部下回来丢到代码库里一是让代码库变的不必要的臃肿，另一方面库之间的依赖关系也不容易管理。引入Bower后代码库要干净很多。

Web前端框架 Bootstrap

现在用Bootstrap的网站有些太多了，以至于Bootstrap让人有些审美疲劳，不过对于缺少专业前端的团队来说Bootstrap绝对是个利器。

JS/CSS压缩 django-compressor

使用django-compressor可以对JS/CSS进行压缩，加快网站加载速度。

表单 crispy_forms

如果是做互联网应用crispy_forms的作用可能不大，但是对管理后台来说crispy_forms非常棒。

django-impersonate

让你可以方便的切换成其他用户。在系统维护的时候会方便很多。

异常日志 Sentry

Sentry 是一个实时的事件日志和聚合平台，基于 Django 构建。Sentry可以将程序的所有异常自动记录下来，然后在一个好用的 UI 上呈现和搜索。如果你还没用过Sentry，强烈推荐一定要试试。

为什么没有用

React/Angular
- 我们的应用场景还是传统的WEB应用，React/Angular可能更适合Web APP的场景，应用起来可能不能带来太多的便利性。
Webpack
- Webpack 是当下最热门的前端资源模块化管理和打包工具。也曾想试试，不过我们这里前端部分还不算太复杂，冒然引入Webpack似乎也不是太必要。目前Bower+django-compressor已可以较好的满足我们的需求了。

Swift

最近在看Swift。已经很久没有这么“悠闲”的看一本书了，从头开始认真的看一本书的感觉还不错。
Swift给我的感觉是一门挺“特别”的编程语言。Swift是一门动态语言却加入了很多静态语言的特性，从一定程度上说Swift比很多静态语言还更严谨。

在Swift里所有数据都是有类型。Swift有着强大的“类型推导”，因此很多地方是不需要指定数据类型的。也正是因为所有数据都有类型，相比大多脚本语言，编译器能检查出更多的问题，IDE的自动化程度也很高。
Swift和Objective-C采用ARC进行垃圾回收。以极低的性能损耗换取了接近全自动垃圾回收的便捷性。（注：官方宣称Swift比Objective-C要快很多）
Swift有这众多的动态特性以及语法糖，使用便捷且功能强大。

Swift中的?以及!

之前在其他语言中没有见过类似语法，初次接触时非常困惑。但一旦理解了之后就会发现这其实非常简单。
String?表示String或nil。首先要理解 String? 同 String 并不是同一个类型。 ?是一个封包的操作符号，将String封装成 ? 类型。（注：有点类似泛型，按照泛型的写法是 ?<String> ）
!则是解包操作，将String?转换为String。如果被解包的数据是nil，则会解包失败抛出异常。

var s = "abc"  // s被自动推导为String类型
s = nil  // nil本身也是一个类型，类型不相等，将抛出错误。
var ss: String? = "abc"
let x = ss!  // ss 有值，可正常解包不报错。
ss = nil  // String?允许值为nil，不报错
let y = ss!  // 报错，无法对nil进行解包

Swift中的Dictionary以及NSDictionary

Swift中的Dictionary同NSDictionary可以通用（NSArray类似），但实际上它们并不是同一个东西。它们在混用的时候，编译器是需要对数据进行转换的。如果你代码中涉及大量的Dictionary/NSDictionary转换，很可能导致你的代码出现性能问题。（注：据说Swift中JSON处理速度慢就是该问题引起的）

django-lbutils

在Github上公开了不少项目，不过其中大多都算不上“开源”。在我看来开源也应当是一件认真的事情，需要对项目持续的维护，同时也需要提供必要测试用例及文档以保证项目的质量。
最近打算将自用的Django工具组件做个简单的整理然后发布了。为了让项目不要太“随意”，开始补测试用例及文档。因为是自用，测试用例和文档几乎为零。最初只是想简单的修葺，不想真正做起来工作比预期的要高出很多。整了许久代码中的注释依旧很不全，测试的覆盖率都还未达到80%，文档更是没开始动。因为文档还没弄完，所以项目也不算正式发布，如果你感兴趣可以先去看看django-lbutils。
为了这个项目，尝试了一些之前经常看到却一直没怎么使用过的工具。

Tox

Tox是一个Python的自动打包测试用具，用来测试Python库在不同环境下的兼容性。因为是自用，本机环境跑起来是没啥问题。不过在兼容性测试时部分测试用例在Python3以及Django的某些版本下跑起来会有问题。为了搞定兼容性花费了不少时间。

Travis CI

Travis CI是一个在线的持续构建平台。Travis CI会检查你在Github上项目的变化，每当有新push的时候进行自动编译。我现在是每次改动后，直接在Travis CI看测试用例的执行情况。

Coveralls

Coveralls测试覆盖率查看工具。结合Travis CI，可在每次测试完成后将测试覆盖率信息推送到Coveralls。在Coveralls可方便查看当前的测试覆盖率。

Read the Docs

Read the Docs文档托管服务。可从Github抓取文档并自动编译好生成在线文档，目前几乎所有的Python库都将文档托管在上面。

天地一沙鸥

to be continue….