怎么参与到百度的开源项目中来

写这篇主要想说明的一点,不一定非得贡献代码才算参与,有门槛更低的方式。
代码贡献特别是完成特定功能的代码,要考虑到设计、编码、自测和集成测试等一系列的工作,不应该作为新参与者的第一个目标。

以百度文件系统https://github.com/baidu/bfs为例,说下我建议的参与方式

1. 阅读项目首页的README.md,了解项目的情况概要,确定你是否对这个项目有兴趣。

2. 浏览下项目文档issue,说不定能解决你的很多困惑。

3. 当前各模块文档都不是很充分,所以你肯定还有疑问,提个新issue,描述下你的想法。这一步是重点,因为这是参与到一个项目中来最简单直接的方式:提出你的问题或建议。

4. 根据架构图和src下目录,尝试弄清楚源码结构。

5. 找一个你最感兴趣的部分去阅读,将重点放在理解和发现其中小的错误上,无论是拼写错误还是注释(或文档)与代码不一致的地方,都是一个很好的点。

6. 不要犹豫,fork下,更正上面你找的的小错误,然后提出一个pull request,这是第二个重点,这时,你的名字就已经可以进入contributors列表了。

7. 发掘下项目在跨语言支持、跨平台方面的一些问题,然后解决他们,你就为项目发展做出了非常突出的贡献了。比如bfs当前只有c++的sdk,其他语言访问只能mount成本地文件系统,如果你能包装个python、php或java的sdk出来,将会非常受欢迎。

8. 在这之后,你就有很多的选择了,这已不是本文的重点,比如你可以结合对系统的理解,通过issue和大家交流后面的开发方向,去尝试一些更有挑战的功能开发,成为主力贡献者。

发表在 bfs, 开源 | 标签为 | 留下评论

《毅力–如何培养自律的习惯》读书笔记

又一本来自吉姆 兰德尔的书。

1. 把一个人与其他人区别开来的品质之一(也即是一个人实现理想,而使另外一些人陷入平庸泥潭的关键),不是天赋,不是教育背景,也不是智商。它是一种自律能力,有了这种自律能力,就没有什么事情是不可能的。没有它,即使是最简单的目标,看上去也可能就像白日做梦。 — 第26届美国总统 泰迪罗斯福

2. 棉花糖试验,通过统计学说明:毅力、自律和延迟满足决定成败。

3. 设定具体目标,成功可能性会大大增加。瘦下来->减轻10公斤

4. 对自己做出承诺,和自己签订一份合同,我要达到XX目标。

5. 要实现人生目标,就必须培养积极的心态:

  •  把挑战分割成小的、易于管理的小块。
  •  教会自己把消极态度抛之脑后。
  •  找到自信。

6. 成功人士在自律问题上,坚持无一例外原则。

7. 你的毅力与你追求该目标的迫切程度成正比。你到底多想得到它?

8. 许多人有很好的想法,但不采取行动,问题出在惯性上。

9. 惯性的两面性:处于静止时,只有在外力的作用下才会运动;处于运动状态时,倾向于保持。

10. 把任务分解成易于操作的小目标,一方面不那么令人望而生畏,另一方面避免急于求成造成负面影响,比如锻炼过度。

11. 你计划的越多,你实现目标所需要投入的毅力越少。预先计划好当危机(考验毅力的点)出现时,该做怎样的具体反应。

12. 毅力的自我损耗,毅力就像肌肉一样,会产生疲劳。

13. 同样,毅力像肌肉一样,也可以通过锻炼加强。

14. 几种锻炼毅力的方法:不要挠痒;跟在慢车后面行驶;使用非惯用手。

15. 最后,是增强毅力和自律能力的15个要点

  • 下定决心,确定你将全身心的投入
  • 准备好为目标进行艰难的跋涉
  • 通过减少需要使用毅力的情景,为将来的挑战做好准备
  • 尽可能具体地确定你的目标和实现目标的过程
  • 把挑战分解成小而易于管理的小目标
  • 对你的思想保持警觉
  • 控制你的主导思想,全神贯注
  • 用一种愉快而不是痛苦的态度,勾画挑战
  • 辨别自己的薄弱时刻,有选择的使用自己的毅力
  • 强迫自己想象一连串非此即彼的选择的结果,毅力就是正确时间做出正确的选择
  • 你的毅力比你意识到的要强大,别说做不到
  • 你越是运用自己的毅力,你越有信心和实力去迎接新的挑战
  • 将积极行为转变为习惯
  • 自律不是自我剥夺,不是对满足感的否定,而是对于满足感的推迟
  • 强大的自律可以将你的生活推向新的高度
发表在 程序人生 | 标签为 , | 留下评论

分布式系统,终将回归C++

上个十年,分布式领域是由Java统治,无论是hadoop的HDFS、MapReduce还是HBase、Spark,都是Java系语言。从Google开放CloudBigtable,使用的竟然是HBase的java接口,也可见一斑。

但我觉得,分布式系统,终将回归C++。

首先在过去十年,分布式系统的主要瓶颈在IO,不是存储IO就是网络IO。存储系统HDFS、HBase的瓶颈在IO,计算系统Mapreduce、Spark的瓶颈也在IO。 而随着万兆网卡、SSD乃至NVMe的普及,系统的瓶颈重回CPU,这时C++优势明显。

其次从单机到分布式是一次大的飞跃,在新模型(gfs、mapreduce和bigtable等等)产生的时候,开发成本底的语言可以快速实现,迅速火起来,但随着行业的发展,模型的稳定,最终焦点又回到性能上,就像Cassandra面对ScyllaDB相形见绌一样,回归到C++也是一种无奈的选择。

最后,C++11及后续14,17的产生,将C++的开发效率也提升到了一个新的高度,Java等语言优势已经不再明显。

所以我也积极地去学习新语言,但还是会坚守C++。
我们的几个核心系统,也都是C++的:数据库 Tera  分布式文件系统BFS 集群管理系统Galaxy

发表在 C/C++, 分布式系统 | 标签为 , | 留下评论

百度文件系统,欢迎大家一起参与

最初的想法源于3年前刚开始做Tera的时候。Tera的设计从一开始就把所有数据持久化的工作全委托给了分布式文件系统,一方面,让Tera的设计简化了非常多,自己不需要考虑数据怎么存储,io怎么调度;另一方面,留下了稳定性隐患,一旦文件系统丢数据或者不可用,Tera就没法正常对外提供服务。所以当时就想做个可靠的分布式文件系统来支撑Tera。

真正开始动手实现,已经是2014年的事儿了,从春节期间开始构思设计,探讨各个方面的可行性,参考了hdfs、xfs、nfs、nearline等文件系统,断断续续的直到年底11月份才写下了bfs的第一行代码。到2015年初的时候,已经可以支撑Tera的正常运行,从那时起,我也将Tera的所有开发测试工作全部搬到了bfs上,也正是这个时候,重写了Tera的common库,将Tera正式对外开源。

2015的下半年,逐渐有其他同学参与进来,2016年初bfs正式更名为The Baidu File System(百度文件系统),作为Tera的核心文件系统立项研发。

今天,虽然bfs仍然是一个孵化阶段的项目,但是已经开始支撑实时日志处理和百度网页库这种重型项目,相信未来会发展成一个划时代意义的分布式文件系统。

bfs从创建起就是开源的,现在也是百度开源大家庭中的一个成员了,欢迎大家一起参与 https://github.com/baidu/bfs

发表在 分布式系统, 存储系统, 搜索引擎, 数据存储, 程序人生 | 标签为 , , , , , | 留下评论

搭建自己的hackernews

突发奇想,搭建个公司内部的hackernews,一方面公司技术人员基数很大,应该上万人,另一方面并没有类的内网站点。

1. 源码下载

git clone https://github.com/arclanguage/anarki

2. 安装racket

wget https://mirror.racket-lang.org/installers/6.6/racket-6.6-src-builtpkgs.tgz
tar zxvf  racket-6.6-src-builtpkgs.tgz
cd  racket-6.6
./configure –prefix=/home/work/racket
make -j18
make install
export  export PATH=/home/work/racket/bin:$PATH

4. 配置

lib/news.arc里,站点名、主题一类的东西,都可以改

3. 尝试启动

sh run_news

最后效果,还不错吧~

发表在 程序人生 | 标签为 | 留下评论

TeamGeek

TeamGeek – A Software Developer’s Guide to Programming Well with Others

Google的两位team leaders合著的一本书,关于怎么构建高效软件开发团队,非常适合团队leader,从中可以学到怎样培养团队文化,怎样更好的领导团队和怎么对付害群之马。

一、天才程序员的传说

软件开发是一个集体项目,单打独斗,闭门造车的时代过去了,团队才是王道。

想取得成功,就要打造一只精英团队。

团队协作的三原则:谦虚、尊重和信任(HRT)。

二、培养出色的团队文化

做出怎样的面包,取决于酵母的好坏,成就怎样的团队,取决于文化的优劣。

帮助新人融入,抵御良风气。

团队文化需要每个人去传递,不仅仅是负责人的事儿。

基于共识决策的团队,需要每个人都对产品的成功抱有强烈的主人翁精神和责任感。

在必须搁置争议先行动起来时,要能将决策托付给少数领导,这要设立个章程。

同事之间的相处方式很重要,要充分的尊重、信任和谦虚(还是heart)。

同步沟通的时候,人越少越好。(高效)

异步沟通的时候,涉及的听众越多越好。(开放、透明)

高层面上,目标要一致。

开会小贴士:

1. 只邀请一定要参加的人;
2. 开会前决定好议程,先通知所有人;
3. 达成目的后提早散会;
4. 别跑题;
5. 尽量把会议安排在休息时间前后(午饭时间,下班前)

三、大海航行靠船长

每个高效的团队都少不了一个强力的领袖。

仆人式领导,营造HRT氛围、消除障碍,宽松、减少微管理。

反模式:

1. 雇佣听话的人;
2. 无视表现不佳的人;
3. 无视人际关系
4. 和谁都是朋友
5. 降低招聘标准;
6. 把团队当小孩子

要给成员设定明确的目标。

坦诚,拒绝三明治赞美法,记录团队成员的快乐程度,关心职业发展。

内部激励:自主、精通和目标。

四、对付害群之马

用最佳实践和流程来提高团队抵抗力。

要勇于对抗有害行为,清除害群之马。

五、操纵组织的艺术

要学会向上管理,确保你的老板以及团队之外的人不但知道你在干嘛,还要知道你干得很棒。

请求谅解比请求许可要容易的多。不要让老板去承诺,去担责任。

处理好“进取性”和“防御性”工作的比例。

互惠。

晋升到一个安全的位置上。

和有能量的人交朋友。

学会向管理层求助,三个论点一个行动。三个点解释清楚问题,一个行动请求,说明你需要什么。

做正确的事儿,随时准备被炒。

六、用户也是人

管理大众印象,承诺时要谨言,做产品的时候要超出预期,尊重业界分析师。

关注用户,和用户交流。

营销、易用性、客服。

发表在 团队, 程序人生 | 标签为 , , , | 留下评论

内存屏障 memory barrier

内存屏障是用来解决CPU乱序执行的,而不是用来解决cache一致性的。

今天无意中看到一篇文章(http://blog.chinaunix.net/uid-24148050-id-270889.html),感觉和我的理解完全不一致,所以简单记下我的理解:

例如初始状态,x = 0,y = 0

a-CPU(或者a线程)上执行
x = 1;
y = 1;

在b-CPU(或者b线程)上可能会看到y=1,x=0的状态,如果b依赖这种状态不存在,那就会出问题。

这里的问题并不是a-CPU修改了x的值,没有同步到b-CPU的cache里(前面文章是这么解释的)

实际问题是CPU的乱序执行导致a-CPU可能先执行y=1;再执行x=1;b-CPU看到了一个中间状态。

这里存在一个争议就是Intel和AMD的ia32架构cpu,不会对写操作进行乱序,所以看起来不会出现上面提到的问题,而事实上他们的保序写只是先将x=1写到了一个叫storebuffer的地方,就继续执行y=1了,并没有真正的将x=1写入到cpu cache或者内存中,而只有数据进入cpu cache,那它的一致性才由MESI协议保证。所以还是乱序执行的问题。

 

参考:
编译器内存屏障:
__asm__ __volatile__(“” ::: “memory”)
CPU内存屏障
__asm__ __volatile__(“mfence” ::: “memory”)

CPU内存屏障一般隐含编译器内存屏障,

有兴趣可以研究:《Memory Barriers: a Hardware View for Software Hackers》

发表在 未分类 | 标签为 , | 留下评论

GFS Case Study

原文地址:http://queue.acm.org/detail.cfm?id=1594206

QUINLAN:http://research.google.com/pubs/author97.html

1. 允许多客户端append同一个文件给一致性带来了很大麻烦。
QUINLAN: I think it makes more sense to have a single writer per file.

2. 快照给实现带来了很多困扰,而且很少人用。
QUINLAN:I also think it’s interesting that the snapshot feature hasn’t been used more since it’s actually a very powerful feature. That is, from a file-system point of view, it really offers a pretty nice piece of functionality. But putting snapshots into file systems, as I’m sure you know, is a real pain.
应该提供一个足够用的快照,而不是一个完美的。
QUINLAN Exactly. This is a case where we didn’t cheat, but from an implementation perspective, it’s hard to create true snapshots. Still, it seems that in this case, going the full deal was the right decision. Just the same, it’s an interesting contrast to some of the other decisions that were made early on in terms of the semantics.

发表在 分布式系统, 存储系统 | 标签为 , | 留下评论

说服力

读吉姆兰德尔的书,是轻松愉快的,每页都是以ppt的形式呈现的,图替代了冗长的文字,生动故事替代了苍白的说教,说服力一书让人受益匪浅。
一个优秀的劝说者,牢记15个要点:
1. 你越有说服力,你就越有可能在你所选择的努力中取得成功。
2. 说服力是一种可以学会的技巧;
3. 你可以做到既有说服力有不必操纵别人;
4. 亲和力,人们都愿意被自己喜欢的人说服;
5. 劝说就是联系,试图找到你和对方的联系,让对方感觉舒适
6. 不打无准备之仗,做好准备是至关重要的;
7. 倾听,保持头脑冷静,察言观色;
8. 稀缺,人们纵向得到他们得不到的东西,稀缺,独享;
9. 劝说要恰到好处,不要让对方感到压力
10. 一致性法则,人们希望与先前所作的陈述或者承诺保持一致;
11. 互惠,人都不喜欢欠人情,都知恩图报;
12. 经验法则,人们往往不经过分析,而是通过反射和经验做决定,比如价格反映价值
13. 随大流、权威
14. 触动内心情感,90的决定都是基于感情作出的
15. 诚信,不能欺骗

发表在 程序人生 | 标签为 | 留下评论

linux下gbk转utf8

iconv -f gbk -t utf8 filename

发表在 GNU/Linux | 标签为 , | 留下评论