开始试用阿里云的 code 管理和 RDC

iOS 11, watchOS 4.0 各种升级,之后还有 macOS 的升级。

我一直很佩服 Apple 的项目管理,以前还略微空闲的时候,试图从外部来探究 Apple 是怎么进行这么复杂的项目管理的。当然后来也略明白,基本也是敏捷、多项目线、大量自动测试、功能尽可能的松耦合等。

之前几年公司一直用 jira 来管理项目,用的还不错,包括其中的敏捷项目管理。目前正在测试阿里云提供的 RDC 功能,比起 jira 来说,更加全面。并且 jira 有一个比较麻烦的就是,需要自己安装服务器,如果都是用 jira 云上的,速度性能有点不行。用阿里云 RDC 算是一个挑战吧,工具本身并不是最重要的,还是开发流程的再造重构本身压力很大。

最近先将两个大项目群中的几十个小项目从 svn 迁移到 git,算是 gitlab 的版本吧,然后在开发中继续使用 issue、milestone 来控制进度,wiki 来进行文档管理,项目本身还是要通过 unittest 以及 converage rate 来控制质量。不过还不是自动构建,每个 issue 的开发还是要人工来跑 unittest,并且 RDC 对于我直接带领的两个项目中使用的 Python 支持不是很好(对 Java 应该没问题)。还好,我们还不是迫切到需要每日构建和连续发布。

阿里云的 code 管理做的还算不错(应该就是 gitlab),git 我觉得建立本地分支和 pull request 流程都是非常不错的,养成习惯后,对于日常开发管理可以减少错误。习惯了 bitbucket 和 github 之类后,发现用 git 在国内的服务器速度要快了不少。

RDC 有专门的同事在做测试,两周后希望可以有一个实践心得,用在真实的开发项目中。

项目管理始终是一个大学问,是否做好,对于结果,天壤之辈。

因此多做一些记录,便于以后回顾和分享。

为了20年后的梦想

1995年-1996年,写了一本 Visual Basic 3-4的书,想必当时过于年轻,自以为是的文字很幼稚,文字不够代码来凑,其实也不是很负责。也缺乏持续更新的能力和勇气,当时我的编程经验全部来源于自学,做过的项目有几个,但不多,也不复杂。最关键是,对于 Visual Basic 本身的认识还是比较肤浅的。

想起来那时的确是充满了热情,白天也是完全没有办法写作,每天上班前,下班后,周末,几乎一年,花费在上。虽然作品不满意,还算是完成了。

20年后,又开始这样的梦想,前些年,比较空的时候到时也有想过,却不太了解行情,原来,现在出版行业也早就市场化运作了,只是要出书并不是那么难。

和同事们选择了自己相对还比较擅长和有独到体会的 Python 和其用在机器学习方面作为主题。因为外面 Python 的书其实也很多了,实在不想写一本简单的入门级,无疑,这个定位在中等水平的目标,让我们一方面提高很多,一方面也是绞尽脑汁,受累。

而今年工作的忙碌,到了这个岁数的种种事情,都耗用了很多时间和精力。不知道多少个晚上和周末,在看资料、写 demo 程序、组织文字、review 其他同事写的书稿,或许这就是梦想,这就是有梦想的力量吧!

记录一下,也有一些颓废的时候,作为鼓励。

python flask 写 api 如何返回自定义错误

在 python 开发中,利用 flask 写 restful api 函数的时候,除了标准的400、500等这些返回码通过 abort() 返回以外,怎么另外返回自定义的错误代码和信息呢?

我们碰到的业务场景是对于api 输入参数的各类校验以及在业务逻辑执行的时候,都会返回统一的400代码,同时也会返回我们约定的描述详细错误的代码以及描述字符串,提供给调用方来处理,这样可以让其用户体验做得更好,同时详细错误代码和描述字符串也会自动打印在 log 日志中。

flask 的官方文档中告诉我们:

默认情况下,错误代码会显示一个黑白的错误页面。如果你要定制错误页面, 可以使用 errorhandler() 装饰器

在写 restful api 的时候,并没有页面可以返回,我们可以在 flask 提供的代码基础上稍加改造如下。

在你的初始化 flask app 的相关代码中加入下面两个函数:

@app.errorhandler(CustomFlaskErr)
def handle_flask_error(error):

    # response 的 json 内容为自定义错误代码和错误信息
    response = jsonify(error.to_dict())

    # response 返回 error 发生时定义的标准错误代码
    response.status_code = error.status_code

    return response
class CustomFlaskErr(Exception):

    # 默认的返回码
    status_code = 400

    # 自己定义了一个 return_code,作为更细颗粒度的错误代码
    def __init__(self, return_code=None, status_code=None, payload=None):
        Exception.__init__(self)
        self.return_code = return_code
        if status_code is not None:
            self.status_code = status_code
        self.payload = payload

    # 构造要返回的错误代码和错误信息的 dict
    def to_dict(self):
        rv = dict(self.payload or ())

        # 增加 dict key: return code
        rv['return_code'] = self.return_code

        # 增加 dict key: message, 具体内容由常量定义文件中通过 return_code 转化而来
        rv['message'] = J_MSG[self.return_code]

        # 日志打印
        logger.warning(J_MSG[self.return_code])

        return rv

CustomFlaskErr 是我们自己写的处理错误的类,然后通过 @app.errorhandler(CustomFlaskErr) 这个装饰器在 flask 中注册。

具体功能在注释里基本都写了,我们看一下怎么使用这个自定义错误处理器。

# 用户名输入为空
if user_name is None:
    raise CustomFlaskErr(USER_NAME_ILLEGAL, status_code=400)

当需要处理某个错误的时候,rasie 刚才的 CustomFlaskErr,传递另外定义好的自己的错误代码,以及标准的返回代码;

上面说的常量定义文件可以参考如下:

USER_ALREADY_EXISTS = 20001  # 用户已经存在
J_MSG = {USER_ALREADY_EXISTS: 'user already exists'}

通过这样的机制,就做到了在具体 restful api 的业务逻辑代码中简单的进行各类自定义错误的处理,所有的错误处理是集中的,细颗粒度的错误代码和消息也是集中维护,便于扩展。

flask 官方文档和一些网上的资料都说比较简单,实践中摸索了这样的实现方式供参考。

python 中使用装饰器来统一检查 flask 用户权限

最近在一个项目中,需要判断 restful 接口函数传入的时候,是否之前已经登录状态是某个特定用户,以及该用户有没有指定的权限。检查下来如果没有的话,立刻返回错误,中断功能。

遮掩的场景虽然也可以通过标准的调用函数来操作,但都不如用装饰器来得简单。都知道装饰器好用不好写,废话不说,先来看看这个场景怎么实现,还是有一定的通用性的。

def validate_current_is_admin(f):
    @functools.wraps(f)
    def decorated_function(*args, **kws):
        # 需要在登录状态调用, 检查是否为有admin权限的用户登录,
        # 如果不是,返回错误码;
        if g.user.user_name != 'admin':
            raise CustomFlaskErr(USER_MUST_HAS_ADMIN_PRIVILEGE, status_code=401)

        # 验证权限是否为 admin, 不是的话,返回401错误
        if g.user.role_id != Permission.ADMIN:
            raise CustomFlaskErr(USER_MUST_HAS_ADMIN_PRIVILEGE, status_code=401)

        return f(*args, **kws)

    return decorated_function

这是一个标准的装饰器的写法,如果你要写一个简单的装饰器,整个框架可以参考。

装饰器调用举例:

@app.route('/api/create_user', methods=['POST'])
@auth.login_required
@validate_current_is_admin
def create_user():

    # 获得参数
    user_name = request.json.get('user_name')
    password = request.json.get('password')
......

 

核心代码的业务逻辑也不复杂,根据 flask 的 g 对象中预存的用户 user 进行检查处理,flask 的这些定义非常灵活,flask.g 怎么使用可以查看 flask 的文档。

这里的 user 以及相关的属性属于具体业务逻辑,就不展开解释了,可以望文生义。

因为不对 args 和 kws 这些参数进行解析和处理,所处理的是 flask 全局对象。最后将参数都原路打包返回即可,没有问题的话交给使用装饰器的代码继续处理。

这个例子比较简单,主要还是熟悉装饰器的基本用法。

python 之前因后果

如果你英语阅读还可以的话,推荐这个网站:The History of Python

2013年11月后就不再更新了,一共31篇 blog,讲的是 python 语言设计中的一些来龙去脉。我在搜索研究列表生成式的时候偶然看到了这个网站。

挺有趣的。

它更新的最后一篇文章是 The history of bool, True and False

或许你也像我一样被 python 的布尔值稍稍困惑过,我们可以看看当年这些天才的程序语言设计者到底是怎么想的。

python 单元测试中使用参数化测试技巧(parameterisation)

这篇文章介绍了在 python 的单元测试中如何使用参数化测试(parameterisation) 技巧来做到将测试数据和测试逻辑分离。Improve Python testing with parameterisation

的确,我们在应用程序中对于业务逻辑和数据的分离会做很好的考虑,但是在自动化测试,在单元测试中有时候会忽略这一点,我发现我也有这个问题,所以写出来的单元测试类似这样:

# test_prime.py
import unittest

from prime import is_prime


class TestIsPrime(unittest.TestCase):

    def test_x_negative(self):
        self.assertEqual(is_prime(-1), False)

    def test_x_zero(self):
        self.assertEqual(is_prime(0), False)

    def test_x_one(self):
        self.assertEqual(is_prime(1), False)

    def test_x_two(self):
        self.assertEqual(is_prime(2), True)

    def test_x_three(self):
        self.assertEqual(is_prime(3), True)

    def test_x_ten(self):
        self.assertEqual(is_prime(10), False)

    def test_x_fifty_three(self):
        self.assertEqual(is_prime(53), True)


if __name__ == "__main__":
    unittest.main()

而这篇文章中建议我们应该这样:

import unittest

from prime import is_prime


class TestIsPrime(unittest.TestCase):

    def test_is_prime(self):
        test_cases = [
            (-1, False),
            (0, False),
            (1, False),
            (2, True),
            (3, True),
            (10, True),
            (53, True),
        ]
        for x, output in test_cases:
            with self.subTest(name=str(x)):
                self.assertEqual(is_prime(x), output)


if __name__ == "__main__":
    unittest.main()

好处不言而喻。

python 3.x 的线程池模式实现多线程

之前发布在简书,我觉得简书还是一个做得非常好的写作平台,也有一定的互动,我现在比较纠结的就是在受众的广度、受众的亲疏、自己可以掌握的自由度、维护成本这些变量之间。

比如问题之一,简书虽然有很好的写作平台,但是我就是喜欢在 wordpress 里面自己折腾主题等等,怎么办。哎。

先从简书这里搬一些自己的文章过来。


看了不少书和资料,自认为对于 python 中的线程、进程、协程等略知一二了。

想实现一个多线程池的模型,但是也不想用 queue 甚至是 celery 这些,查了很多资料,国内的原创的不多,并且基本都是停留在 python 2.7 的时代,而且国内的文章即便用 google 搜索,大部分文章也是互相转载。国外的资料比较好的还是在 stackoverflow,国内的简书上好文章不少。

搜了半天,在 python 的官方文档上赫然有着一个例子:

The concurrent.futures module provides a high-level interface for asynchronously executing callables.
The asynchronous execution can be performed with threads, using ThreadPoolExecutor, or separate processes, using ProcessPoolExecutor. Both implement the same interface, which is defined by the abstract Executor class.

用 concurrent.futures 即可,然后

ThreadPoolExecutor is an Executor subclass that uses a pool of threads to execute calls asynchronously.

找了好久差点想自己实现(担心自己写的很烂)的线程池就在这里,例子如下:

import urllib.request

URLS = ['http://www.foxnews.com/',
        'http://www.cnn.com/',
        'http://europe.wsj.com/',
        'http://www.bbc.co.uk/',
        'http://some-made-up-domain.com/']

# Retrieve a single page and report the URL and contents
def load_url(url, timeout):
    with urllib.request.urlopen(url, timeout=timeout) as conn:
        return conn.read()

# We can use a with statement to ensure threads are cleaned up promptly
with concurrent.futures.ThreadPoolExecutor(max_workers=5) as executor:
    # Start the load operations and mark each future with its URL
    future_to_url = {executor.submit(load_url, url, 60): url for url in URLS}
    for future in concurrent.futures.as_completed(future_to_url):
        url = future_to_url[future]
        try:
            data = future.result()
        except Exception as exc:
            print('%r generated an exception: %s' % (url, exc))
        else:
            print('%r page is %d bytes' % (url, len(data)))

这个例子写得很清楚,可以直接运行,不过建议把那些网址换掉,因为 g*w 的关系。

没想到 python 的官方文档做的这么好,我准备从头到底先通读一遍。

从学习角度这个代码是够了,当然如果要用在真正的应用里面,还要考虑更多的事情哦!

学习 python 的可爱的孩子们

又是一个学期,时间真快,自己也不容易,这个学期14节课,风里来雨里去,来回就要1个多小时,坚持下来。今天终于是最后一节课,欢乐的考试时光。

还是希望现在这些条件越来越好的孩子们,可以好好学习电脑,学习编程,成为未来的栋梁之才!

小时候自己主要在中学和少科站,至今不能忘记当年格致中学的励幼娣、周柏生老师,少科站的曹文浩老师,谢谢他们的悉心指点,当年的我也有点像现在这些孩子,聪明、贪玩。很多道理都是后来才懂。

开源内部培训的 python 教程

这几年,作为布道者,始终在探索一些新的知识点,在 python 以及其应用的 restful api、数据统计、机器学习等领域算是略有斩获吧,也更加理解,作为初学者来说,如今的编程领域的确功能强大,但是门槛其实并不低。

在公司内部做了一段时间 python 培训,所以逐步将这些内部培训材料公开出来,目前是最基本的 python basic,也就是 python 的入门教材。

https://github.com/chinapnr/python_study

拙作,欢迎拍砖。希望之后有能力和时间继续各类 python 专题,特别是机器学习、NLP、flask、pandas 和 numpy 等,都非常有趣和功能强大,python 和 js、java 一样,几乎可以胜任任何领域的开发。

学习 python 这一年

大约2015年4月到5月开始,正式学习 python,发现之前大概在2009年左右也学过,可能当时没有坚持下去。

记得去年开始学 python 的时候,1个月左右,给同事写了一个基于 csv 处理的小程序,当时就被 python 的简洁优雅所倾倒。

然后边学边写东西,本来为公司 zion 框架写一个 dsl,当时水平还不行,所以写成了一个 sql 的包装工具 r2,用来在前端业务逻辑调用后台数据库的时候简化 sql 语句写法以及做到和数据库无关。

真正让我自己 python 水平感觉有点突破的是几个事情:

1 写真正生产上的应用。需要考虑的事情非常多,比如一个简单的 r2,就让我学到了 log、conf、import、class 等很多基本知识的应用,以及单元测试、性能测试。

2 教别人 python。这是让自己的基础知识巩固最好的办法之一。要把别人教会,且处理各类奇怪的运行错误,很有挑战。这样的结果,是对诸如列表、字符串、元组、字典、函数、循环等基本概念非常清楚。不管多复杂的程序,90%的代码其实还是基本的操作,在这90%的代码设计和编写的时候可以减少错误,节约时间,自然有用。

3 看资料。晚上有大量的英文和中文的 python 资料,绝大多数都写的很好,受益匪浅。

在我的推进下,公司也在个别项目上开始使用 python,通过 flask 来构建 restful 接口,机器学习也基于 keras 和 tensorflow 开始了实际的应用。

我相信,进步会是跳跃式的,而这还是仅仅发生在一年间,python 在胶水语言的应用,连接 js、php、java 和 moble 开发上面,以及 python 在人工智能、机器学习上这几年强劲的表现,都让人激动不已。