2013 PyCon总结

昨天参加一下2013
PyCon。原本以为是python的小规模交流聚会。结果是GDG赞助的布道会。感觉起来还是交流太少,结识的人也少,只是听取思路和知识点。一句话:太耗时间。
首先介绍了一个叫做Leo的项目。这个项目看起来使用的Python的自完备IDE。即是开发Python的,也是用Python开发的。所有的代码都可以集成到Le
o上面。听起来不错。只是不知道开发效率怎么样?

然后是豆瓣开发了一个和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. 下面是原文:

1
2
3
4
5
6
7
8
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. 我个人觉得手工上去敲代码,给听众演示。还不如做一个视频。做视频更为繁琐。而现场敲更容易出错。
  • 本文作者: 帐前卒
  • 本文链接: http://chillyc.info/2013/17332801/
  • 版权声明: 本博客所有文章除特别声明外,只能复制超链接地址,且必须注明出处!