Python老兵的新征程

用Python已经有近9年了, 大多数时候都是用它来做些内部使用的小工具,写的都比较随意(唯一的正式项目经历,就是写一个用户评论搜索引擎,那个网站已经关闭了,当年的页面可在archive.org看到)。 做这些开发时,开发的方法思路其实和十来年前没啥差别,当然有了些更好的辅助工具,例如Git,Pycharm等, 但主要方法没啥大变化。 这周用Python做另一个正式项目,尝试采用了和以前都不一样的方法,通过这一个星期学习到了不少新东西。

  1. pyenv来管理python的不同版本,
    因为项目用了Python 3.5, 而系统是Python 2.7
  2. 用了Python 3.5的Type Hints
  3. PyScaffold初始化了项目
    以前也用Django来生成过web项目,但非web项目还是第一次用生成器生成。
  4. commitizen来写git commit message, 这样能够用cz-conventional-changelog自动生成change log
  5. pylintflake8做代码检查
  6. tox做测试
  7. 在Git pre commit hook中加入pylint,flake8,tox检查
  8. SQLAlchemy来做ORM, 用Alembic做数据库的版本升级管理
    以前都是直接写SQL -_-;,当然是参数化的。 这次先用phpMyAdmin直接在mysql上设计数据表,然后用sqlacodegen生成model代码,再用Alembic做版本管理。
  9. Travis做系统集成
  10. pip做依赖管理
    1. 用pip freeze > requirements.txt 来记录依赖
    2. 再用pip install -r requirements.txt来重建依赖环境
    3. 正在研究virtualenv以实现依赖的隔离
    4. 另:以前研究过Docker,遇到些问题没能搞定,有经验的还请指点一二
  11. Slack集成
    现在已经能从Slack里看到Github的提交,Pull request提醒,并能看到Travis持续进程测试结果。上线时还要实现从聊天频道里直接下指令部署。

感觉现在开发的思想,哲学都比起20年前,甚至比起10年前都有了根本的改变,我们正迎来程序开发上的工业革命,生为这个时代的程序员是何其的幸福啊 :)。

Tags:

categories IT

高效会议的12个准则

工作中经常开会,开出了些心得,总结出开高效会议的12个准则,分成会前,会中,会后:

  1. 会前
    1. 明确会议目标
      要明确如下几个问题,并提前让所有参会者知道。 如果很多参会者都不清楚会议的目标是什么,那注定是个失败的会议。

      1. 会议要讨论什么问题
      2. 会议要有什么样的产出
        是要形成决议,还是要有行动计划,还是仅仅是为了互相沟通
    2. 只邀请必须的人参会
      什么是必须的人,就是需要做出关键决定,必须提供实时关键意见的人。
      下列的人则尽量不要邀请, 而只要把会议纪要抄送给他们参考即可

      1. 只需要知道会议结果的人
      2. 只是提供一些资料的人
        可提前和他们询问相关信息,资料,而不需要邀请参会
    3. 提前发出邀请,最好是提前一天以上
      很多人在会议上发表意见以前需要有个思考,准备的过程,才能给出深思熟虑的意见。 如果是会议开始前1分钟把他拽过来, 往往给不出太多有价值的想法,降低会议效率和价值
    4. 制定会议议程,明确会议时间,会议主持人(默认为会议邀请的发出者)
      制定出会议讨论的时间表, 将整个会议目标拆解成一个个小步骤,确定总的会议时间,并在邀请参会人员时就要发送给他。
    5. 一些关键问题可提前沟通
      有些关键问题是和某个参会人员相关,而和其他人无关, 这类问题最好在参会前和该人员提前私下沟通,节约大家时间。
    6. 参会人员需要提前准备
      上面的几个建议都是给会议组织者的,这一条是给参会者的。 参会人员需要根据会议组织者发送过来的会议邀请中说的会议目标及详细议程,提前准备资料和自己要发表的意见。 如果没有重要意见可发表,可考虑向会议组织者提出不参加。如果会议中发现会议和自己关系不大,或者自己意见已充分表达,自己也不是关键决定人,可提前退出会议。
  2. 会中
    1. 遵守会议议程
      按照议程一步步来,会议主持人要控制好以下三点

      1. 遇到跑题要及时拽回来,可反复强调会议目的
      2. 控制每个议程的时间,限制每个人的发言时间
      3. 让大家都有发表意见的机会
    2. 会议记录
      用电脑或笔记本都可以,把大家提出的重要意见,决议记录下来。
      做会议记录有两个问题要避免

      1. 一是记录太少,甚至没有
      2. 记录太细,每个发言都详细记录。 其实只要记录主要意见,决议即可,要注意提取每个人说的话背后的主题思想。
    3. 会议要明确产出
      1. 如果是为了沟通,要把大家达成的共识记录下来
      2. 如果是要达成行动计划,那要明确行动目标,责任人,完成时间点,完成标准,及中间的检查时间点和标准。
  3. 会后
    1. 及时发出会议纪要给大家
      除了每个参会人员要发送外,其他相关人员也要抄送。 达成的共识,计划等等,都要在纪要里明确,如果发出后大家没有意见提出,则大家就要按照这个纪要来执行。很重要的会议要先发给关键人员审核,没问题后再发给大家。
    2. 跟踪会议结果
      要在以后的工作中检查共识有否贯彻。会议达成的行动计划有否得到很好地执行,如果没有要督促相关责任人。
    3. 每次会议后都要总结
      每次会议后会议主持人要总结,以改进以后的会议,可围绕下面这些点来总结:

      1. 会议是否达到了目的
      2. 是否遵守了上面这些准则
      3. 是否有些人不必邀请或漏掉了一些该邀请的人
      4. 是否高效
      5. 怎么能开得更好一点
  4. 其他
    1. 会议中一些意外情况的处理
      1. 需要做关键决定的人员未能参会
        建议这种情况下取消会议,和该人员再约下次会议时间。 避免大家说半天,结果什么决定都做不了。
      2. 在会议中就一些问题的讨论形成僵持局面
        1. 如果问题不重要,就立刻做决定,不要浪费时间
        2. 如果问题很重要,形成僵持往往意味着缺少相关资料来充分的证明双方意见的优劣。如果资料能找到,就建议停止会议,明确找资料的责任人及时间,找到资料后约下次开会时间。 如果没有这种资料,在确保双方意见充分表达后,即终止无谓争论,迅速做决定。
    2. 工具
      可用工具来提高会议的效率

      1. 会议记录在网上有模板可循,大家可参照
      2. 可用Trello,Teambition 之类的工具来在会议后跟踪决议的执行情况

工作中看到的反面教材:

  1. 会议开始前几分钟通知人开会,人坐到会议室都不知道会议主题是什么,更不知道议程和要有什么产出。 甚至开会开到一半把人来进来参会,结果人家压根不知道之前的讨论,听得一头雾水。
  2. 邀请了一大堆不需要的人参会,但其实他们只是需要了解情况即可,结果大多数人在会场枯坐,玩手机
  3. 没有发出议程,大家都不清楚会议的目标,大家漫无目的讨论
  4. 会前没有找关键人员就一些关键问题提前沟通, 结果会议进行时发现重大分歧,大家看着两人争来争去。
  5. 会议后没有发出会议纪要,过几天这会议讨论了什么,做了什么决定早被人忘到九霄云外了
  6. 会议最后达成的决议没有明确责任人,完成时间点,完成标准,检查点等, 也缺乏追踪。 结果事情也就不了了之。
  7. 需要做决定时,没人敢拍板,结果开了很长时间会议什么决议都没达成

 

后注:

  1. 会议是成本很高的活动,无论是时间成本,还是耽误其他工作造成的机会成本。会议是必须的,但需要的是高效的会议,低效的会议宁可没有
  2. 这个准则是对面对面在一个会议室的会议,远程会议又不同,我还在摸索中。
  3. 抛砖引玉, 欢迎大家讨论

《世界秩序》

今天在地铁终于读完了基辛格的《世界秩序》。很久没有读这么大部头的实体书,每天在地铁端着这么一本大厚书,真的不轻松。 这两年书的读后感一般都是发到微信朋友圈,或者读书会的群,都是些只言片语。但读这个书有感想不少,还是感觉博客更合适些。

豆瓣里已经有了不少介绍和精彩的评价,这里就不重复了,下面谈谈自己的一些零碎感想:

  1. 每个国家或文明,他们的行事逻辑是由背后的价值观决定的,而这些价值观可能贯穿数百年,甚至上千年。 这些价值观,有的是摆在明面上的,而有的可能隐藏在深处,甚至身处其中的人都不自觉。
    从这又想到公司,推动一个公司前进的力量其实也和其背后的价值观密切相关。很多价值观与国家或公司反复在台面上宣传的没太大关系,而是通过众人实际的行为潜移默化的融进国家或公司的血液里。
  2. 很多事,很多圈子都是有其规则的,要想一起玩,要先熟悉规则,遵守规则。
  3. 看这本书时,还同时看一本心理学相关的书,其中提到人少年时受到的创伤,会影响到成年以后的思维逻辑方式。貌似一些国家的行为准则也能和这个国家的历史创伤拉上关系
  4. 感觉中国从人民到政府,乃至权贵,都缺乏安全感
  5. 以宗教,或某主义等崇高目标为宗旨的团体,往往为了他们的崇高目标,很多都可以牺牲,包括生命,诚信,规则等等,到最后连崇高目标的初心都忘记掉了。
  6. 在17世纪,一些智者就懂得了通过设计平衡,互相牵制的国际安全体系来保障和平,虽然失败多次,但总的来说还是在不断进步的。 而国内很多人对世界局势的想法还停留在三国演义的逻辑水平。
  7. 五月花号登上新大陆,萌芽了未来几百年后一个伟大的国家。 这是历史的必然呢,还是人类的运气呢?
  8. 当人类有机会去外星球殖民,有机会重新构建一个崭新的国家时,人类又会诞生什么样崭新的文明呢?

 

乱想 – 无线脑电波沟通

人类的沟通,通过语言,动作,眼神,书写。 这些过程都需要人类脑内思维翻译到这些外部的媒介,再被他人接收,再翻译成回脑部信号。 那么人脑之间能否越过这些中间的媒介而直接沟通呢?

这些年人类在脑电波控制上已经有了很多进展,可以用脑电波控制游戏,控制假肢。
12
那么人类有没有可能通过脑电波直接沟通呢? 如果可以,那一定会有很多有趣的事:

  1. 跳过了翻译过程,人脑之间直接用电波沟通,沟通效率会提高很多
  2. 因为跳过了翻译的中间环节,人与人间的误解会大大减少
  3. 人类之间可遇不可求的心有灵犀一点通的美妙感觉,用脑电波沟通可能会变得非常容易
  4. 到时,人们耳朵上带的就不再是蓝牙耳机,而是能帮助人与人间无线脑电波沟通的仪器
  5. 那时社交网络会有直接寻找脑电波匹配的人的交友服务,比通过分析什么各种兴趣爱好会准的多,保证两人一见能一拍即合
  6. 因为都是通过无线脑电波直接沟通,人们无论在哪里都可以高效的沟通,会有更多SOHO的工作者。
  7. 开会时可以一起组个脑波局域网
  8. 估计为了防止一些意外,脑波网络也需要有防火墙

为妹妹而骄傲2

十年前写过一个blog:为妹妹而骄傲。 老妹还是不停让我为她更加骄傲,昨天她又跑下了全程马拉松。还有:

慕尼黑马拉松做为国内最好的体育营销及赛事专家,她为国内体育界组织过多场培训,已经桃李满华夏。

这几年做为中国田协的咨询顾问,推动了中国马拉松赛事的规范,发展。

以她为骨干的北京龙舟人俱乐部,连着两年包揽北京金海湖龙舟赛的前三名。

如果当年我们的体育老师知道,这个从小就体育不及格的小姑娘在几十年后居然跑下了全程马拉松,还成为体育方面的专家,拿过龙舟赛冠军,估计惊的下巴都要掉了 :D.

为妹妹骄傲,从小。

 

后生优礼内测试吃报告

Max一个半月前告诉我,他辞职一个月了,回潮汕老家正做个自己家乡文化有关的小品牌。让我很是期盼。一个2013年广州创业周末大赛的冠军,一个为诸多大品牌做过品牌咨询工作的顾问,一个创意多多的90后,是不会让人失望的。

今天就收到了这个:

打开一看:

后生优礼  IMG_1734

这还只是试吃装,正品是下面这个:

后生优礼

打开的时候,发现貌似不经意绑上的绳子,其实是很妥帖的粘在纸袋上的:

IMG_1742

 

打开后看到小包装
IMG_1739 IMG_1738 IMG_1737

 

这是后面

IMG_1736

 

分三个味道:原味,梅子味,单丛茶味。
IMG_1748

 

每个小盒了里面是个小纸袋。小纸袋可不是一般的纸,而是三层,最里层一层薄膜,第二层是铝膜,第三层纸,里面的食品得到了最妥帖的保护。

IMG_1741 IMG_1747

这就是里面食物:花生。

晚上一个人坐着,一粒一粒慢慢品尝。 真没想到花生居然也可以做到有这么多层次的味道,梅子味的花生,入口一点酸,接着酸甜,接着甜,再接着花生的本味出来,花生的本味后又藏着说不出的味道,让人欲罢不能。 茶味味道层次更多,但我的语言表达力实在贫乏,很难用文字去描述那细微的味道变化。

本来不爱喝茶,但吃了这个花生后,忽然想起和朋友一起在古北口长城脚下喝茶的日子。喝着茶,再能吃上这么好吃的花生一定是极好的。 喝几道茶水,让味蕾充分舒张开来,再拿起一粒后生花生放进嘴里,让那味道慢慢在嘴里释放,体会味道层次的一点点变化,一定是非常惬意的。

强烈推荐梅味的,让人欲罢不能,茶味也是让人回味很久。原味对我来说有些太甜了,不过从小不喜甜食的我居然也吃了一整袋。

除了花生,Max还开发了芝麻糖和瓜子脆。芝麻糖没来得及拍照就被同事们分光了,下面是瓜子脆:

IMG_1750

 

这个也很好吃,但感觉味道不似梅味和茶味的花生那样层次那么多,回味那么悠长。

这些东西都没加防腐剂,都是潮汕传统工艺纯手工打造。

IMG_1745 IMG_1746

这是Max的个人微信号和公众号(公众号名: 换个姿势看潮汕)。 大家要购买可以直接和他联系。

另:在各地行走时,看到过很多古老传统的手工艺品,各种小地方的美食,躲在偏僻的小角落里,无缘被外界知道。当时就起过要把这些好东西带给世界的念头,不过自己是行动上的矮子,一直没有行动。Max从说起到做出产品,发布试吃套装,不到两个月的时间,执行能力之强让人侧目。而且更让人欣喜的事,他不只是把眼光放在小吃上,而是希望能把潮汕传统的文化借由后生优礼介绍给外面的世界。希望将来Max能做大做强,不只是潮汕,还能把各地的传统小众的美食及文化带给大家,还希望能出现更多的Max,成为急速前进的现代文明与传统文化之间的桥梁。

IE11在Windows 7中不能启动的问题

今天韩国阿姨的机器上突然IE11打不开了,点IE11的图标IE窗口死活不出现,而用Task Manager能看到IE的进程。 查看Windows update发现昨天刚安装了KB3058515, 一个关于IE11的安全补丁。在安全模式下,IE11启动没问题,看来是这个安全补丁和IE11的哪个插件冲突了。 于是把IE11的所有Addon disable掉,可依然不行。 还卸载了一堆可能和IE有关的软件,但毫无效果。 查杀了木马病毒,也毫无发现。

在网上也找到有人说是注册表权限问题,发现这台机器不是那个问题。

最后用Process Monitor查看系统中的进程,发现有个Baiduprotect.exe 进程很奇怪,明明这台机器没安装过任何百度的东西啊。 最后在C:\Program Files (x86)\Common Files\Baidu\BaiduProtect1.3\1.3.0.619 找到uninst.exe运行,卸载了Baiduprotect。 卸载后IE11终于恢复正常。

重写?重构?

今天看到Gu Lu的Blog《知乎回答:入职后发现项目组代码异常混乱,是去是留?》中谈重写还是重构的问题,说的很好, 读了很有些感触。重写与重构的抉择问题存在于很多公司,尤其是创业企业。下面说说自己的意见:

先说结论:如果是功能单一的某模块,重写问题不大,而复杂系统在绝大多数情况下,都不赞同推翻重写。

原因如下:

  1. 复杂系统的推翻重写需要投入的开发资源很大,周期很长才能见到效果。对企业来说这是一种孤注一掷的赌博,风险很高。
  2. 而且重写期间,旧有系统得不到根本改进,公司要冒着长时间内业务需要的技术支持无法得到改善的风险。
  3. 还有,看到过的推翻重写的复杂系统,很多没什么好结果。不少重写出来的东西同样百病缠身,甚至还不如原有系统。

做出重写或重构的决定很容易,但真正让一个系统能有提高,真正让一个团队能更进一步,需要的是一些更深层次的改变。

 

  1. 重构应该贯穿代码开发的始终
    好的代码是改出来的,代码需要不停的重构, 重构应该贯穿代码开发的整个阶段。很多人能在创业初期迅速开发出能工作的系统,但他们把这期间的遗留的问题称为技术债务,总希望能抽出专门的时间来解决它。这种事自己也做过,但现在不赞同专门抽时间重构,而是认为重构应该贯穿开发的始终。这之间的差别貌似很小,其实是开发方法上的本质差别。
  2. 自动测试
    当面对的是一个很庞大复杂的系统, 很难在短期内通过简单的阅读代码就彻底读懂它。这时你的一些改动如果没有测试去做检查,那弄不好就会造成系统的一些很严重的问题。 这个问题在代码缺乏良好的风格,缺乏良好的架构情况下会更突出。但如果手工测试的话,过程会很漫长,会造成整个系统迭代速度极其缓慢。而且手工测试本身也是有不低的错误率的。 复杂系统的重构必须要有自动化测试做保障。单元测试的技术已经很成熟,而seleniumappium等测试工具的出现则为为浏览器,app等终端产品UI的自动测试提供了很好的手段。robot framework等测试框架的出现,则为搭建自己的测试系统提供了很好的支持。而云技术发展,则为搭建可自动缩放的测试系统提供了很好的基础。 当几百个测试用例可以在半个小时就全部跑完的时候,重构的迭代速度会大大加快,而且会是有质量保障的速度。
  3. 可测试性
    代码的可测试性大家谈的不多,很多编程名著里见不到他的踪影。代码的可测性可能在开发简单系统,比如单机软件时还不那么重要。但在开发复杂的系统时,当你需要重构它的时候,可测试性的重要性怎么强调都不为过。 当你重构出现问题时,可测试性好的代码应该能让你迅速发现问题,定位问题。可测性不好的系统,自动测试的意义会大打折扣。至于什么是可测性,大家可参看同济大学的朱少民老师写的一个非常好的ppt:谈软件可测试性,这里就不重复了。可测试性不只是有利于在开发阶段调试代码,在生产环境中,可测试性好的系统也有助于迅速发现定位问题,减少问题造成的损失。
  4. 其他
    1. 持续集成
      有了持续集成,你就可以从打包,到测试,到生产环境部署都可以全自动化完成。 一旦发现问题可以立刻自动回滚。
    2. 在线生产环境监测
      应该建立一套生产环境监测系统,并不断完善,一旦发现问题立刻发出警报, 甚至能自动做一些自动应急修复错误。

 

做好上面几点,重构就可以放心大胆的进行。否则重构也是很冒风险的,这也是为什么很多公司都有些大家都不敢动的老代码的原因。

说到底让团队能做好重构工作,是要在团队里建立一种开发文化:

  1. 产品快速构建,小步快速迭代
  2. 重视测试,重视软件工程

===========================================

曾经做过很成功的一次重构,在半年后旧有代码已经很少,几乎90%以上都是新代码,系统性能和稳定性都大幅提高。有可能从半年后的视角,会觉得这是一次重写,但这其实都是每天一点点重构带来的。整个重构的过程系统不断稳步提升,整个改变平滑顺利。除了重构代码的工作,还做了不少别的:

  1. 当时重构工作开始的第一天,就安排专人开发自动测试系统
  2. 后来又开发了生产环境的监控系统
  3. 给系统增加了不少专用的监测接口
  4. 当时业务人员遇到问题常常直接捅到开发这边来,后来给系统增加了一个接口,能迅速帮助业务人员定位是使用错误还是系统错误,如果是使用错误是具体什么错误。增加这个接口后,从业务那边过来的技术支持压力一下少了很多。这也算是增加了整个系统的可测试性。
  5. Gulu文章中提到的幽灵替补,灰度发布的方法都用到了

也有些方面没做好:

  1. 当时的持续集成一直想做,但因为各种原因一直没做起来,真正持续集成是在现在的公司才做到
  2. 当时的自动测试系统只能做基于Web API的测试,UI自动测试做了尝试,一直没真正做起来。这也是到了现在公司才真正知道怎么做。
  3. 柔性服务的思想很好,当时没想到,希望以后能试试。

 

Page 1 of 5212345...102030...Last »