2013 PyCon总结

         昨天参加一下2013 PyCon。原本以为是python的小规模交流聚会。结果是GDG赞助的布道会。感觉起来还是交流太少，结识的人也少，只是听取思路和知识点。一句话：太耗时间。

         首先介绍了一个叫做Leo的项目。这个项目看起来使用的Python的自完备IDE。即是开发Python的，也是用Python开发的。所有的代码都可以集成到Leo上面。听起来不错。只是不知道开发效率怎么样？
         然后是豆瓣开发了一个和Google App Engine很像的东西。叫做DAE。只能运行Python的APP。这样做的好处是方便部署，减少运维团队。豆瓣只有4个SA。这个东西想想贵司也是做过的。只是正规的项目都难以迁移到那个上面，所以现在沦为了静态页面和简单website的聚集地。看起来应该豆瓣强迫所有的项目都移植到那个上面吧。豆瓣的service会达到5K qps.这个service水平，听起来比词典要低好多好多呀...搜索了一下，豆瓣过去使用的是github的企业版，看起来这两年估计觉得缴费太多才使用了gitlab自己搞了一套？我觉得应该不是豆瓣自己用python写了一套同样的gitlab吧？DAE这个系统开发了两年，现在还是私有的。当然不知道他们用了多少个人做这个开发。这个DAE有一个不错的东西功能：灰度上线。不过对于基本上都是website的网站，可能这样做灰度上线切一下nginx就好了。想想如果有多个端，怎么做灰度上线呢？特别是发布各个端APP的平台都是第三方的。这个就更难做了。DAE这个还有几点是可以借鉴的。第一是内部的服务使用thrift,外部的服务使用HTTP。二是内部使用的UDP socket而不是TCP socket（这里...不知道对错）。
        然后是Uliweb 一款python的web框架，现在的版本是0.9+, 看来在作者心目中仍然没有到1.0...我觉得这样的产品还是作者自己先玩玩。等升到1.0，我等再拿来看看。其不错的特点就是可以将css和JS压缩打包。
        下面是Buildout，类似maven的一款依赖解决打包软件。为什么不用pip,作者说因为pip只能下载stable版本...自己查了一下pip的文档。自从1.4版本后，pip就支持pre-release version和devlopment version. 下面是原文：
Pre-release Versions

Starting with v1.4, pip will only install stable versions as specified by PEP426 by default. If a version cannot be parsed as a compliant PEP426 version then it is assumed to be a pre-release.

If a Requirement specifier includes a pre-release or development version (e.g. >=0.0.dev0) then pip will allow pre-release and development versions for that requirement. This does not include the != flag.

The pip install command also supports a –pre flag that will enable installing pre-releases and development releases.
所以尚不清楚Buildout的作者是否又在造轮子。

        然后演讲的是python的玄机，除了deep copy经常遇到。其他的好像都没有碰到过......要么是自己太遵循c/java的规范了，要么是用python的编程年头还太少。

       之后上午的演讲就全部结束了。结束后去自动化所吃了个非常难吃的饭。我头一次把各种肉剩下，而只吃了米饭。
       下午演讲继续。去哪儿运维人员用python+openstack + flask+postgreSQL+extJS+nginx做了一个后台的运维系统。主要是为了加入新的设备，程序的部署和发布。这个系统看起来相当不错。最主要的是这个系统把整个发布流程简化，只需要运维人员审批同意，就可以自动上线。管理机器也很方便。我觉得运维到那家公司应该很轻松。我想如果把整个文档需求设计=>开发=>代码评审=>测试环境部署=>测试=>线上部署/发布 流程整个都自动化的去做。这个公司的人都会很轻松。
       下面是python + Hadoop,对于Hadoop的优化，讲到主要看三个东西：tcp_mem, socket stat, tcp_max_orphans。另外他们把整个计算模式分为三个：pig, cascading, streaming.其中pig就是使用SQL-like的语言来执行Map-reducing操作的。cascading就是Map-Reduce操作JAVA库和API。这里应该是某些难于用SQL-like语句写的，就用编程的方式实现。而streaming是使用单独的脚步和命令作为Map-Reduce的输入的，所以这里应该是对于需要快速实现，而且又很少需要维护的应用建立起来的（例如运营人员的特殊要求）。
        另外也介绍一下Seafile这个开源项目。该项目是企业云存储云盘，为文档为中心的协作平台。可以聊天可以写wiki等。但是我唯一感觉到的不足之处在于文件存储于S3/swift/ceph之上。觉得如果存储在server搭建的本地磁盘或者SAN/NAS上更易于现在的企业使用。另外还有一个问题，seafile的所有数据都是加密的形式传入到server。我觉得至少分享给团队的文件不应该使用个人的密钥进行加密，或者在企业内部分享的文档不应该加密。一旦某人离职，他的文档就要被其他人员接手，否则那份文档就变得不可控了。这样做很安全，但是很不方便。另外Seafile将用户的密钥加密中间密钥，然后使用中间密钥对各个文档进行加密，用户自己的密钥是不传给服务器的，这样解决了改密码，所有文件需要重新加密的问题。这里仍然有些问题。一旦用户忘记密码，他的所有文件都拿不回来了。另外一个问题，如果用户删除了自己的本地数据包括中间密钥。他如何重新生成中间密钥。如果使用用户id+特殊字符做的可重复生成的中间密钥，那么一旦算法公布，这个很容易被破解。如果是随机密钥或者不可以重复生成的密钥，那就意味着数据一定会丢失，或者有运维人员介入。所以细细想想都不是可靠的协议/算法。

       在这个会里，除了有这些总结外。还有非技术的总结：
1.    ppt最好不要使用黑色背景。虽然这是脑残MAC粉的最爱。因为你们很喜爱，导致台下各位看不清，这样就不对了。
2.    如果脑残到一定要用黑色背景，请一定使用白色的文字（而不是其他颜色的文字）。
3.    演讲一定要兴趣点，如果开发出一款很像造轮子的应用/产品/框架，请简单的定义和比较你的应用/产品/框架（最好两三页PPT）。如果两三页PPT讲不完，这说明这个东西太复杂了。如果还凑不齐一页，那就忽略区别吧。用实际的例子说明更好。枯燥的文字，看得大家都很想睡觉。
4.    如果ppt中copy了命令行、或者把命令行截图了。那么背景也不要是黑色。如果是，请把字体都变成白色。
5.    演讲中尽量用图而不是用文字。
6.    演讲一定要对着台下的听众。如果你觉得背对着听众演讲更为出色的话，也请不要挡住ppt的大屏幕。

7.    我个人觉得手工上去敲代码，给听众演示。还不如做一个视频。做视频更为繁琐。而现场敲更容易出错。