过去一周，将自己最近一段时间做的两个小项目给开源了，都是基于Apache License 2。

其中一个是SiNALY， 用于SINA微博与Trunk.ly的同步程序。

项目地址:  https://github.com/roymax/py-sinaly

另一个是Xurrency ， iPhone实时汇率程序，用Titanium平台开发

项目地址: https://github.com/roymax/xurrency

有兴趣的话请移步到github浏览下载

之前用Play-framework写了一个新浪微博与Trunk.ly的连接器程序，并部署到GAE上，由于种种原因,其实是用不了的。我又用了大概一周晚上的时间，平均每天1个多小时左右用Python重新写了一个。我是从来没有用python写过web app，最多只是当胶水语言来实现一些偷懒的工作。

所以在框架上我选择了看起来最简单最容易入手的web.py作为开发框架。刚开始时是非常顺利的，甚至只用了一个小时就基本写好了代码结构，要知道我是不了解web.py的，但这也只证明web.py真提简单易用，但当要深一步去调整时就要不停的repeat再repeat地调试了，因为大部分的功能都需要依赖外部第三方实现，中途我甚至还有过一段时间在想是不是换成Django算了，我想我还是喜欢一栈式的解决方案。

最后，在CSS和排版上我也遇到一些问题，毕竟我不是设计师，但又超爱漂亮，所以就瞎鼓搞了一些时间。最终这个程序经过包装后重装放出来了

• 开发语言：python
• 微博 python SDK：sinat-python
• Trunk.ly python SDK:  trunkly-python
• web开发框架：web.py
• modules: lxml , jinja2 , sqlalchemy

因为一切都不熟悉，所以工作起来特别有趣。

现在SiNALY的只是定时获取微博内容分析并同步的Trunk.ly上去分享，我想现阶段在效率上一定会有问题，后面我将主要完成两个工作：

1. 改进同步的脚本，让它再有效率
2. 添加解除同步绑定功能

前段时间利用PlayFramewrok写了个sina微博与trunk.ly的连接器程序，已经发布到GAE。

这个程序的主要的功能就是将我新浪微博上发布及转发的包含链接的微博自动收集到trunk.ly上，以方便于回溯跟踪管理自己喜欢的链接。

工作原理：通过GAE的cron每隔五分钟读取最近发布的微博，分析原文或转发的微博内是否包含URL，如果有则用URL为trunk的url，并抓取URL页面的标题为title，微博的内容为note和text提交到trunk.ly保存。

但程序到少有以下缺陷：

1. 针对单用户设计的。
2. trunk.ly的API限制只能post链接到api key的提供者
3. 只保障能用，没有经过优化
4. 因为GAE的CPU和资源限制，部署到GAE上不工作
5. …….

依赖：

1. playframework 1.1
2. play module (siena-1.3 / gae-1.4 )
3. sina sdk for java （经过修改）
4. jsoup-1.4.1

代码暂时不打算再修改了，所有的代码都host到git，有兴趣的朋友拿去修改优化一下

https://github.com/roymax/sinaly

因为一些众所周知的原因，我认为每一个技术人员（甚至包含所有互联网从业者）都应该需要具备一个中国特色的技能－－通过技术手段来访问一些对于我们的事业发展起主导作用的网站，阅读、下载、分离资料。过去的一年我一直在用Astrill这个快速、安全的VPN服务，在全球多个国家有近30台的服务器接入点，最低100Mb的接入速度，非常快速，而且无限制的下载带宽，多浏览器（IE/Safari/Firefox/Chrome/Opera）和多平台支持（包含Mac OSX /Windonws/Linux/iPhone/iPad/Android)，无广告。而且安装非常便宜，只需要下载Astrill的客户端安装，登录选择接入点即可自由畅游互联网，从此不受束缚。

独有的Smart Mode（a.k.a GFW mode ……）可以有效地加速网站访问，并且通过打开Site Filter功能，指定必须通过VPN访问的白名单或反向指定，完全自己定义。在windows下还可以指定特定的应用程序才通过Astrill连接网络访问。通过Astrill下载软件，访问Twitter、facebook，看youtube、vimeo视频，技术博客畅通无阻，世界缺少了不必要的“和谐”而变得完美。

当然，Astrill的服务器是付费服务的，有四种营销包分为1/3/6/12月，费用各为美元10.95/19.95/34.95/62.95。包年折算人民币415元左右，价格是否合理睇个人吧，相对于我2010年2月22日订购的包年费用24.98美元已经贵了不少了。那时Astrill刚刚起步不久，服务器接入点也只有在美国境内3个、英国2个，现在已经升级到全球多个国家近30台。

嗯，如果你通过以下的推广地址订购Astrill的VPN服务，是可以获得一个7折 购买Astrill的服务，包年折算成人民币约300元，每天的成本一块钱不到的成本还是可以接受的。

https://www.astrill.com/a0f580808

http://twitter.com/#!/roy_wei/status/37935133290004480

http://xcarshop.com/astrill/

经过去一个月的开发，于上周末终于迎来了我们产品的第一个beta版本，该版本实现了产品最核心的功能，所有不是那么“不重要”的都被排除在外：它没有搜索功能，它没有站内消息功能，它也没有可嵌套的评论，甚至连找回密码都没有。因为以上的我们现在都不需要，我们只做了一个像样一点的帐号管理功能、登录、注册，你可以换一下头像，按我们的指引发布一个关于穿衣打扮的意见，关注其他用户关于穿衣打扮的见解，评论它。就是这么简单的一个“可用”版本，它也僅僅是“可用”，我们甚至打算为它准备好几天来Debug。但没有关系，我们都准备好了面对这一切，我们打算把它做得更好一些。

而在过去的一周，我一直在期待这一个beta版本的来临，为了给将来的产品模式部署做好准备，我谋划着如何为它准备测试机的测试环境。并尽量让测试环境接近于产品环境。

我们用到的技术：

• PlayFramework 1.1 ，刚刚升级到1.1.1
• MySQL 5.1.41 ， 打算在5.5测试通过后，升级到 5.5
• JDK 1.6.0_21
• memcached 1.4.2 ,    Cached部分
• GlassFish 3.0.1   ,        Application 服务器
• Mercurial Server (hg)     ,    代码仓库
• nginx 0.7.67  ,               Proxy ＋ 静态Host
• ubuntu-10.04.1-server-amd64  ,      服务器系统
• GraphicsMagick 1.3.12

1. 为什么选择PlayFramework ？一开始我们想用Rails，敏捷而且快速。但团队更熟悉Java，而本人认为SSH风格的开发模式过于繁锁，我们需要的是一个能够快速开发，快速迭代的框架，PlayFramework看起来不错，我们就尝试着用它。
2. 项目目录结构 为日后可能的多项目公共代码引用，我们将一些公共代码抽取放入到Play 的Modules 里，各项目以引用modules的方式共享公共代码。看起来像这样:

   sources
   |- apps
   | |- main
   | |- passport
   |- modules
   | |- models
   | |- commons
   | |- statics

3. 为CDN分发做准备 我们将所有apps的静态文件都放入了statics modules中分类存放，通过Play的routes配置，在开发者环境中各apps通过引入modules来做路径的相对引用，而产品模式可以配置成对应的host路由，像我们的配置文件一样：

   #{if play.mode.isDev()}
   GET /public/images/ staticDir:public/images
   GET /public/ staticDir:public/
   #{/}
   #{else}
   GET imgs.domain.com.cn/ staticDir:public/images
   GET jscss.domain.com.cn/javascripts/ staticDir:public/javascripts
   GET jscss.domain.com.cn/stylesheets/ staticDir:public/stylesheets
   #{/}

   以图片举例，在开发环境中，html片段为: /public/images/commons/foo.jpg
   而在产品模式下，html片段为： imgs.domain.com.cn/public/images/commons/foo.jpg
   要运用以上技巧，除了配置routes外，还需要修改HTML模板中的路由引用:
   将

<script src="@{'/public/javascripts/common/jquery-1.4.2-noConflict.min.js'}"></script>

修改为

<script src="@@{'/public/javascripts/common/jquery-1.4.2-noConflict.min.js'}"></script>

client_max_body_size 5m;

worker_rlimit_nofile 65535;

location ~ .* {
	    proxy_set_header        X-Real-IP       $remote_addr;
            proxy_set_header        X-Forwarded-For $remote_addr;
            proxy_pass   http://127.0.0.1:9000;
        }

[codesyntax lang=”text” title=”application.conf” container=”none” capitalize=”no” strict=”no”]

XForwardedSupport=127.0.0.1,10.0.0.25

天气寒冷最好的方法当然是躲在被窝里睡它一觉，要是有阳光背上手提出外走走被阳光沐浴一下，再找个店坐坐，上上网，喝点热腾腾的东西是多么写意的一件事情。

但当我来到这家星巴克接入CMCC-starbucks后，一切都恶心起来，中国移动拒绝我登录到WLAN，因为我的浏览器是safari/chrome/FF，而不是那个令我讨厌的IE

我意识到这是IE only后，无奈之下我打开了windows XP的虚拟器，打开IE进行登录然后就成功了，并且要保持这个虚拟机不被关闭，我才能正常的上网。

我不想谈什么多浏览器支持的必要性，我不必要听人说IE才是事实的标准，IE有多操蛋自己google去，我只知道对于我来说，IE就是垃圾！对于我来说，IE Only就是至用户利益之不顾！对于我来说，IE Only就是你没有技术能力做得更好！对于我来说，IE不是互联网的一切！你可以支持IE，但用户有权选择非IE浏览器！还请中国移动、各大银行等IE only系统高抬贵手吧。

Let’s kill IE!

macbook于2009年8月21日入手，至今16个多月，主要用于上网、编码，极少游戏。

入手前从来没有用过osx，当时想买的机器有IBM，SONY型号，主要原因是mac有点贵，还跟以往的操作习惯不同。后来在香港官网见到翻新机（其实大部分是14天退货，维修有说明的），价格便宜了不少，先是因为翻新的原因打了折，还因为以港币结算，折算RMB还可以当打个折。再者想用不习惯OSX就被人鄙视一下装Windows吧，没什么大不了的，于是就入手了一台ch467。朋友拆包后带过关，跟全新别无二样，操作系统是tiger，后来用88块港币升级到snow，到手后就开始学习windows到osx的切换。

通过这16个月的坚持，死活在mac中找win下软件的对应解决方案，习惯osx的系统理念后，现在可以说我离不开OSX ，而且极不愿意回windows体系下去，我觉得OSX很好用，以至于有人问我该买什么笔记本，我都会说：“你应该需要一台macbook，而且远离windows”，以到于目前M$最好的操作系统 win7都差点都不会用了。

没有病毒，没有弹窗，没有注册表，没有IE，不需要碎片整理，不需要防火墙，系统不会越用越慢，良好的用户体验……如果你拥有一台并且在运行着windows，应该试一试你的OSX系统，习惯一下就会被众多的细节所征服，浏览器配合触控板的多指手势的体验在windows下可是享受不到的。

对于开发人员拥有一台macbook绝对会为编程带来乐趣，原生就支持Java，Python，Perl，Ruby，PHP等，间接地令我对多用用python与ruby发生更多的兴趣。配合homebrew这个开源软件包管理工具，安装git,hg,svn,ssh……是多么的写意快捷。自从有了mac后，我仿佛又回到 DOS时代，通过Visor调出半屏透明的Shell窗口，喜欢敲打着命令行过着一半图形一半字符的生活，查找文件通过 ctrl＋ space调出spotlight基本可以搜索出来，运行程序也是用spotlight，我还是没有习惯用QuickSilver是因为觉得spotlight够用了。

现在唯一令我打开虚拟机运行windows的前提是：我需要使用网银系统！但好快我就可以不用了－－用手机银行解决一切问题。

今天整理文档时找到这份2009年底写就的优化思路，只是当笔记的整理编写。用来指引今年的工作方向，但最终没有深化落实执行下去就离开了旧东家，实在可惜。

1.   概述

同时，整理该份文档，有利于我们清晰现存的体系架构及面临的风险。

2.   优化的目的

• 节省资源，服务器、网络资源
• 消除或者减少系统瓶颈
• 提升用户体验

此外，或许也有炫技的因素在内，为了优化而优化，当然这是不可取的做法。

3.   一些数据

• * M注册用户，约*万个活跃用户(基于200912的唯一用户登录游戏数据推算)
• 1M综合浏览量/月
• MySQL数据库稳定运行了211天，共792M次数据库查询请求，43.292 qps/天
• 数据库读写比例是：r 74%/w 26%
• 数据库峰值416个连接
• 有9台PC服务器在运行
  • 其中6台提供线上服务，3台提供运维支撑
  • 2G memcached deamon

4.   平台架构

JAVA部分包含旧有的遗留产品和平台的核心服务接口，如：论坛、支付中心、游戏登录和支付接口、后台服务进程等等。JAVA应用分为WebApp和独立运行的应用程序。WebApp运行在Resin 3.1.6应用服务器上，JVM配置2GB的最大可分配内存。

RUBY部分包含一些前端服务页面，现在只要有三个应用使用RUBY实现：帐号中心，个人管理中心，所有产品运营活动。RUBY运行于Lighttpd+FastCGI基于TCP/IP监听模式，每个应用同时开启5个backends进程进行处理，每个进程各稳定占用45 - 60mb内存不等，共3个应用，约占总内存 50 * 3 * 5 = 750mb

数据库使用MySQL 5.0.51b-log版本，运行在一主两从的复制模式。其中一台从机未有效利用，只能当备份库使用，存在资源浪费；另一台从机用来进行OSS数据分析查询使用。主库配置使用mysql 4GB内存的例子配置文件修改配置。

其中三台IBM的机器因挂接的磁盘柜只支持Red Hat,所以操作系统使用Red Hat Enterprise AS 4，内核是Linux 2.6.9-67。其他机器统一安装CentOS 5.2，内核是Linux 2.6.18-92.e15。

5.   找寻瓶颈在哪

系统的瓶颈会在何方呢？如果系统有完善的监控分析系统的话，可以从统计数据和图形上看到大致的系统瓶颈所在。但是如果系统没有这些数据，按照一般的逻辑思路分析，将服务器细分为静态服务器，动态服务器，数据库服务器，业务逻辑服务器。分别针对这些服务器的带宽、内存使用、CPU使用率、磁盘IO进行基本分析。如对于动态服务器而言，其CPU的使用率一般情况下是其瓶颈；而对于静态文件服务器，由于其逻辑简单，但又需要传输大量文件，其出口的带宽、磁盘IO就很有可能是其瓶颈；数据库服务器则CPU和磁盘IO都可能瓶颈…我们需要根据这些数据结合经验来判断系统的负载是否达到瓶颈或接近瓶颈的预警判断。这些数据基于操作系统本身已经可以获取，而不需要我们去开发很复杂的应用监控。但系统本身产出的性能数据是不保存的，更理想的是，我们应该将利用一些开源软件组建一套更好的监控工具。

幸运的是，我们已经有一套现在看起来还非常不错的监控工具在运行着。而瓶颈通常还存在下面的问题：单点服务。

6.   寻找服务单点故障(Single Point of Failure)与高可用性（High availability）

单点故障从基础的硬件层，操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。以上各个环节任何有一处出了毛病就造成部分或整体网络、服务受到影响，最简单的解决方法就是做冗余设备和服务，其次再进一点，做层次化便于隔离问题。隔离问题有助于我们发现单点，解决单点。

而可用性并不是一个模糊概念，实际上它能用数学方法来精确地表示。简单地讲，一个高可用性系统就是一个用户能随时使用的系统，例如当用户需要在早上8点到下午5点启用该系统时，该系统就应该在这段时间内保证良好的可用状态，其余的时间可以用来进行定期维修保养。可用性常被定义为实际的服务时间和要求的服务时间的比值，常用百分比表示。许多现代化系统需要一天24小时、一年365天连续不间断运转(有时也称为7×24或365×24)。一个可用性为99.9%的365×24系统一年的平均故障时间为8.76小时(525分钟)，而要想让系统的中断时间在一年中只有3分钟的话，系统必须有99.999%的可用性。

7.   系统架构的发展方向

1. MySQL版本升级，打入性能优化补丁
2. 高可用性架构设计
3. 寻找并解决单点故障防患
4. RUBY优化，安装RUBY企业级补丁
5. 完善服务点监控，建立服务成功率KPI
6. 思考应用整合，接口整合，建立企业级系统架构服务
7. 服务器应用清理调整，运维服务器与生产服务器分开
8. 平台向分布式系统过渡

所以必须持之以恒的去探讨我们的架构，监控我们的系统，随时解决各种问题

8.   未来三个月目标

1. 优先MySQL
   • MySQL 5.1已经发布了多个稳定版本，可以考虑升级,以获取性能20%的提升。
   • Google为MySQL编写的开源性能优先补丁，经众多网站使用确实能为系统带来稳定性和高效率。
   • 参考MySQL 5.1手册，调整优先参数
2. 优先Ruby
3. 打入Ruby Enterprise Edition补丁。
4. 生产与运维环境分离
5. 开发评估设计系统应用架构，消除应用单点，高可用性设计方案
   • 登录接口(Socket/WebServices)
   • 网站平台前外服务(Web)
   • 内部应用系统总线架构(SOA)
   • 数据库读写分离架构
   • 运维评估网络设备单点及服务高可用性方案
6. 产品策划上从注重UI过渡到UE，应该给使用者一种「当然，应该这样」的感觉

9.   参考资料

病毒行销（英语：viral marketing）又称基因行销或核爆式行销，是一种讯息传递策略，通过公众将信息廉价复制，告诉给其它受众，从而迅速扩大自己的影响。和传统行销相比，受众自愿接受的特点使得成本更少，收益更多更加明显。

Hotmail是互联网初期最成功运用病毒行销的服务商之一，通过在每封免费发出邮件的底部附加”Get your private, free email at http://www.hotmail.com“使其在一年半的时间内吸引了1200万注册用户。

自从有了六度空间理论，病毒行销就真正的成为互联网生活的一部分。人们不停地被推介，人们主动地成为知名人仕、权威人仕、草根英雄的听众，接收他们的推荐。有些人甚至不做信息过滤就将信息二次传播，产品快速的形成影响力，占领市场。有些产品甚至不需要成千上万的广告投放而获取足够的人气，赚取丰厚的收入。

时到今日地球人都知道，新产品的推广方案里如果没有病毒行销是怎么也说不过去的。即使只是建立一个博客，也得想方设法的将它推销出去，于是人们不停的登录社区化网站，不停的Build an audience。

构建听众是一个漫长的过程，某些产品运营人员就是没有用心地去经营这个过程，而用了一些取巧的传播手段。如在微盘上下载文件页面的那个”转发此文件“的小勾勾，我专门发了一条微博痛骂运营人员的”不损手段“，而@咬人的小虾 同学就要求我明白什么是“迫不得已”与“快好省”，这非常扯淡。在互联网上，没有任何产品是不可替代的，产品认同度来自于人之间的口味相投，你的”迫不得已“已招至人们的排斥时你还无动于衷，那已经离消灭不远了。

好吧，微盘那个勾勾有什么问题？首先看看它跟其他分享转发有什么不同。在查看每一条微博是不会进行转发的，如果进行转发你必定认为它是有趣、有价值、有意义的，其实你是在做着信息过滤的工作，你是在对自己负责，这就是你。hotmail是通过熟人网络进行传播的，底部的广告多少有些强制性，但这个传播是单一的，它始终在推销着“hotmail”这个与众不同的电子邮件产品，而且它当时真的足够的好用，足够的酷，人家都愿意推销它（当然，现在不是了）。

微盘呢？传播者将自己认为好的东西上传到微盘，然后通过微博通知大家到达页面进行下载，这是一次传播，主动发生的。而微盘的运营人员为了使用户能够快速地形成二次、三次传播做了一个小小的诡计，设置了一个默认选中”转发此文件“的小勾勾（刚开始连这个button都没有），当用户确认下载文件时自动将用户下载行为通告于微博，使用户听众得到传播。微盘被我厌烦之处在于：

• 转发是基于内容，由微盘共享出来是基于文件的
• 该次转发的微博内容（微盘共享的文件）并未被我确认是有意义、有趣、可信的。
• 基于上一条，我没有义务去推广微盘和该次下载的文件
• 如果我推广出去了，是我的工作失误，我没有对我的听众尽责
• 下载文件是我的隐私，我的隐私不应该被默认公开
• 基于以上各条，为什么”转发此文件“是默认的？

如果不能改变，那么放弃它。我用Dropbox ~ 绝对的推荐