Denial of Service

题记:本文可不是关于DoS或DDoS的技术文章 :-D 前两个月受Pluskid之托,给浙大MSTC十周年的月刊(说是月刊,实际上按发刊速度已经是年刊了)写篇文章,于是便有了这篇。原文名为《拒绝》,为了放到Blog上而找题图时才突然想到DoS这个名字。

IT是个辛苦的行业。新人尤其辛苦,特别是刚刚毕业步入职场的应届毕业生。这种辛苦的直接体现就是加班:前一晚刚通宵上线完毕,今天还要赶调研报告?连续两个月的周末都没有出去玩,全窝在公司干活?白天开会、晚上干活,分身乏术?为什么总是这么忙、这么多工作呢?其中一个重要原因就是不懂得拒绝。

前几天面试时,有一个同学也提到自己当前的工作非常忙,手头很多个任务并行在做。从面试情况可以看出这个同学的个人能力很不错。当前手头上的任务既有短期的重要项目任务,又有中长期的技术储备任务。当时问他既然这么忙,为什么不推掉一些任务呢?他回答第一自己本来就是新人,应该多干;第二老大让干的怎么能不干?

于是我问:如果你带着一个队伍,老大让你干什么你也都接吗?干不完就逼着弟兄们加班吗?

Read More »

Posted in Work | Tagged | 8 Comments

分布式相关文献共享

去年从Google、Amazon分布式架构出发,针对分布式数据一致性和其他的一些分布式基本原理做了一些研究。期间搜集了一批文献,并用JabRef做了索引,现在共享出来供参考:

BibTeX索引文件可以直接用JabRef或者其他兼容BibTeX格式的文献管理工具进行编辑。共享出来的文献不仅仅包含分布式的内容,也有少量其他的东西,比如Erlang、LaTeX、魔方什么的,各取所需吧 :-P

Posted in Work | Tagged , | 7 Comments

个人数据安全 (2):保护即时通讯隐私

(本文部分链接可能需要翻墙访问)

一般来说,即时通讯(IM)软件都会对客户端到服务器的通讯进行加密,对用户隐私数据安全提供一定程度的保障。但也有例外,比如MSN就完全不加密。所以一些小公司将MSN作为主要IM工具是极为不明智的,借助Wireshark等简单工具对员工间甚至员工和客户间的对话内容进行监听易如反掌,极容易造成商业机密的泄漏。微软坚持使用明文MSN协议的目的让人难以捉摸,其中恐怕难免混有政治因素。使用MSN Shell插件的加密功能或者SSH隧道转发等手段,也可以不同程度地间接加密MSN通讯数据。

即使是那些号称使用加密协议的IM服务,也并不真的就百分之百地安全,在国内的网络环境下尤其如此。一直饱受质疑的QQ(12)自不必说,国内其他的IM运营商也多少存在类似的境况。这种行为固然可恶,但作为国内的运营商,若不如此便无法生存——饭否便是个极好的例子。即便是Google,也干出了中文版Gtalk不开启加密(12)这样的事情来。如果不采取一些特别的措施,无论你愿不愿意,正如题图一样:The big brother is watching you!

Read More »

Posted in Data security | Tagged , , , , | 8 Comments

个人数据安全 (1):用GnuPG保护个人隐私数据

之前在Twitter上说过,打算写一个个人数据安全解决方案的系列,内容包括:

  • 基于GnuPG的个人隐私数据保护
  • 自建XMPP服务器保障即时通讯安全
  • 使用Dropbox进行较低密级的文件共享和协作

后记:后来觉得Dropbox这个话题太简单了点,没啥好写的,且重点在共享和协作,而非安全,便取消了。

原本还打算写一写用SSH端口转发隧道建立SOCKS v5代理(俗称SSH翻墙术),鉴于网上已经有不少不错的介绍(12),就不再重复劳动了。这里所采用的技术全部基于开源软件、免费软件或免费服务商,同时也兼顾使用体验。除了自建XMPP服务器所需的域名费用外,其余部分的经济成本为零。

跟丫头暂时还维持着北京、杭州两地分居的状况,网络是平时联络和数据交换的最为重要的手段。上述的这些技术都是我们目前正在使用的数据安全保障手段。这几篇文章的前身其实就是我写给丫头的操作手册。内容并不艰深,丫头并非计算机专业也能轻松掌握就是最佳佐证 :-D

另外,由于我平时主要使用Ubuntu,所以这里的所有方案都同时适用于Ubuntu和Windows。对Ubuntu以外的其他Linux发行版,这里就不兼顾了,不过方法都大同小异。

第一篇挑个复杂点儿的,讲讲GnuPG 8-)

Read More »

Posted in Data security, Tools | Tagged , , | 26 Comments

尝试用urllib2和PyXMPP同步Twitter和校内状态

在翻墙技能还不熟练,同时Twitter上好友也还很稀少的那么一段日子里,一度拿校内状态当作Twitter使用。上周末,看到@Jun_Yu这么一推

发现一件有意思的事儿 好多有意思的推被转到校内 然后又被有的推友贴上”转自校内”的标签重新在这儿疯狂rt

于是想起之前发现校内桌面采用的是标准XMPP协议,且校内状态的更新是采用XMPP Presence实现的,便回了一句:

校内的IM是基于XMPP的,理论上只需要发一条<presence/>消息就可以修改校内状态,可以做一个校内和Twitter同步的工具 :)

然后@2325bt便推荐了这篇将Twitter自动同步到Facebook、饭否、校内、海内等网站的方法。不过这个办法严重依赖于嘀哒。然而,在墙内的网络环境下,任何和Twitter关系密切的Web服务只怕都难得长寿。而且,对于Twitter/校内状态同步这个简单需求而言,用于完成多方同步的嘀哒不免牛刀样十足。既然人家校内十分友好地采用了开放的XMPP,那么求人不如求己。 Read More »

Posted in For fun | Tagged , , , , | 15 Comments

Concurrent Programming in Erlang Part 1 中文译稿

链接:《Erlang并发编程》第一部分erlang-logo

从去年年中开始,利用闲暇时间零零散散地翻译Concurrent Programming in Erlang Part 1。完成了序言致谢简介第1章之后由于工作繁忙暂停了很久。今年年初,又重新捡起来,完成了第2章。同时也将原先的reStructuredText格式的译稿迁移到Sphinx上。借助Sphinx,将译稿切分、组织成了合理的工程目录。于是将译稿上传到了SVN,又在Erlang-China和TopLanguage发了帖子,正式发起CPiE-CN项目,召集了一批志愿译者,开始合作翻译剩余章节。

各位志愿者们动作都相当迅速,没多久便相继提交了各自负责章节的译稿。不过有些并非是Sphinx格式,需要再手工适配到Sphinx。有些即使是 Sphinx格式,一些排版和格式的细节处理也还不到位(有些译者还是Sphinx新手)。也有志愿者出于种种原因遗弃了认领的章节——不过没关系,考虑到本人本来就拖拉成性,所以特地在译者须知中注明本项目没有任何进度压力……

于是,适配非Sphinx格式译稿、整理其他译者的Sphinx译稿排版格式、校对所有译稿以及翻译惨遭遗弃的章节,就成了我剩下的工作。期间因为工作原因暂停过很长一段时间。不过说实话,由于暂停得实在太久,以至于后来工作不忙的时候也没能想起来……囧……咳,总之,断断续续一年,总算将全书主体 翻译完毕——“主体”的精确含义是:除附录B、E和参考文献列表以外的所有内容。

在此严重感谢无私贡献译稿的诸位志愿译者,他们是(按参与项目的时间次序排列):

  • 王飞(第4章、第8章)
  • Ken Zhao(第6章)
  • 张驰原(第5章)
  • 丁豪(第7章)
  • 赵卫国(附录C、附录D)
  • 吴峻(附录A)

最后……也感谢一下自己 :mrgreen:

  • 连城(序、致谢、简介、第1章、第2章、第3章、第9章、全文校对)

注1:CPiE-CN全部译稿使用BY-NC-ND的CC协议许可。曾经在erlang-questions邮件组中询问过Joe大叔的意见,大叔称没问题并将邮件转发给了Prentice Hall出版社的编辑,不过出版社并没有回音。

注2:曾经说要在DreamHost上折腾一个Trac用来做勘误,最终可耻地没有搞定。此事无限期顺延……没有寄宿到Google Code等站点的原因是这些站点不支持相应的CC许可协议。

注3:今年3月14号翻译完第2章的时候本写过一篇blog。第二天便正式发布了CPiE-CN项目。在那篇里对长篇技术文档的撰写工具进行了探讨,盛赞了Sphinx,并对Erlang社区表达了无限的憧憬。然而,该篇blog后来由于未知原因(估计是误操作或WordPress升级事故)被不幸截肢,全文只剩下大约30%。可怜我在事发之后不知道多久才发现,遍寻Google Reader、Google Cache和百度Cache也找不到原来的全文,只好忍痛将该篇匿了,秘谋让该篇在全书译稿完成时再次涅磐。然而,昨天重新编辑了这篇blog后,发现RSS却没有更新,可能是跟发布时间等因素有关,只好又新开一篇。这件事情教育我们:一定要定期备份WordPress数据库啊! 8-O

Posted in Translation | Tagged , , | 9 Comments

snipMate反引号转义补丁

vim-logo对于一套IDE来说,一个好的snippet管理工具可以大大提高程序员的工作效率。作为一个适应不了Emacs的Vim geek,Eclipse自带的代码补全、Visual Studio的Visual Assist插件、Emacs下由Pluskid荣誉出品的yasnippet,都让我十分垂涎。之前曾经用过很长一段时间的snippetEmu(这也是Debian/Ubuntu vim-scripts包中所带的snippet插件),虽然确实有助于提高效率,却有诸多不足:视觉效果很不清爽,时不时还出些问题,最难忍的便是其晦涩不堪的snippet定义方式。后来也尝试过同事推荐的另一个已经不记得名字的插件,仍旧不趁手,又换回snippetEmu。

前两天无意中发现snipMate,试用之后大呼惊艳!虽然和snippetEmu同是模仿TextMate,snipMate要精致得多。Snippet的定义方式也非常灵活和人性化。只有一处让人不待见的地方,就是snippet定义必须像Makefile一样以tab开头。通读文档之后依照自己的代码风格改写了默认的C/C++ snippet文件,又录入了Emacs erlang-mode所带的几个OTP behaviour的snippet。把玩一番,爱不释手 :-D Read More »

Posted in Tools | Tagged | 12 Comments

shared_ptr四宗罪

boost在基于C++的大型系统的设计实现中,由于缺乏语言级别的GC支持,资源生存周期往往是一个棘手的问题。系统地解决这个问题的方法无非两种:

  1. 使用GC库
  2. 使用引用计数

严格地说,引用计数其实也是一种最朴素的GC。相对于现代的GC技术,引用计数的实现简单,但相应地,它也存在着循环引用和线程同步开销等问题。关于这二者孰优孰劣,已经有过很多讨论,在此就不搅这股混水了。我一直也没有使用过C++的GC库,在实际项目中总是采用引用计数的方案。而作为Boost的拥趸,首选的自然是shared_ptr。一直以来我也对shared_ptr百般推崇,然而最近的一些项目开发经验却让我在shared_ptr上栽了坑,对C++引用计数也有了一些新的的认识,遂记录在此。

本文主要针对基于boost::shared_ptr的C++引用计数实现方案进行一些讨论。 C++引用计数方案往往伴随着用于自动管理引用计数的智能指针。按是否要求资源对象自己维护引用计数,C++引用计数方案可以分为两类:

侵入式

侵入式的引用计数管理要求资源对象本身维护引用计数,同时提供增减引用计数的管理接口。通常侵入式方案会提供配套的侵入式引用计数智能指针。该智能指针通过调用资源对象的引用计数管理接口来自动增减引用计数。COM对象与CComPtr便是侵入式引用计数的一个典型实例。

非侵入式

非侵入式的引用计数管理对资源对象本身没有任何要求,而是完全借助非侵入式引用计数智能指针在资源对象外部维护独立的引用计数。shared_ptr便是基于这个思路。

Read More »

Posted in Work | Tagged , , | 30 Comments

:wq 2008 (2)

mozilla-logo22009年也快过去两个月了,关于前一年的内容,写完这一篇也便就此打住。一来平日时间有限,写篇长长的博客实在是件奢侈的事情;二来这一年中所学甚多,但要总结起来不免会涉及到大量工作相关的内容,不方便详述。

自知之明

书接上回,从网易离职后,打算休整半个月,然后三月底到百度报到。而在这期间,我又干下了一件自不量力的事情。学校的一位老师找我合作一个项目,由于涉及保密条款,详细内容在此不表。题目很有挑战性,而且之前我对相关方向的经验完全是一片空白。这位老师曾经参加过我本科的毕业设计答辩,并且在网易时也曾经做了蛮长一段时间的同事。虽然项目本身也一定的经济回报,但当时完全是因为承蒙对方看得起,心存感激,才接了下来。当时预期半年内完成。

Read More »

Posted in Work | Tagged , | 5 Comments

:wq 2008 (1)

dreamhost-logo去年12月份,和Pluskid、Quark以及马铃鼠一起合租了DreamHost的虚拟主机。然而付款的过程却极其地蜿蜒曲折,在被我无能地拖沓了漫长的整整一个季度后,借助远在美国本土的Victor同学的帮助,终于以支票支付的方式艰难地画上了句点。于是也就有了liancheng.info这个域名以及这个blog。啊……在此向Kid和Quark谢罪 :-(

2008年是本命年。迷信说本命年会发生很多不顺的事情,是韬光养晦的年份。这一年确实碰到了很多非常有挑战的事件,在此一件件总结一下:

跳槽前的挣扎

这件事严格来说是从07年下半年开始,到08年初结束的。从网易杭研院跳槽到百度,其实07年10月就已经是板上钉钉的事情。但是却一直到08年2月才正式离职。之所以拖了这么久,原因是在于想尝试着推动几件事情,以尽力改变一些当时所面临的,同时也是促使我不得不选择跳槽的负面(技术)问题: Read More »

Posted in Work | Tagged , | 9 Comments