28

洪强宁及其技术团队在网站架构、性能、可伸缩性上有着深入研究。他们始终致力于用技术改善人们的文化和生活品质,用自己的技术口味去传播分享更好的技术。

加入豆瓣

2005年初,阿北在啄木鸟社区发出豆瓣网上线的通知,那时洪强宁加入啄木鸟社区,并学习使用Python已经有三年时间了。

洪强宁坦言,如何把以往的技术积累下来转变成产品, 是目前摆在自己面前最核心的问题
洪强宁坦言,如何把以往的技术积累下来转变成产品, 是目前摆在自己面前最核心的问题

与同龄人相比,因为受学计算机的哥哥的影响,洪强宁上小学时就开始接触计算机,并且很早就有写程序的爱好,并确定了做软件研发工作的方向。在清华的开放实验室里(全国最早允许学生访问互联网的地方),洪强宁接触到了大量国外的网站和技术。那是“我技术能力成长最快的时间”,洪强宁说。大四时候,洪强宁开始了解Linux,学习和使用了后来在豆瓣广泛使用的Gentoo,由此对开源软件产生了浓厚的兴趣,并参与到一些开源项目中去。

清华毕业后,洪强宁一直做嵌入式系统。出于对软件开发的喜爱,他在2002年开始接触Python语言,但只是业余时间才用Python做一些东西。进入第二家公司后,洪强宁在负责新的项目技术选型时,完全采用了Python语言,并应用在嵌入式XP系统上。就这样他逐步完成了硬件工程师到软件工程师的转变,也让洪强宁对一种语言在计算机底层如何工作有了深入的理解,从此无论是工作还是业余项目都使用Python。

2004年8月啄木鸟社区开始运营,这是由黄冬发起的Python语言社区,同在社区里活跃的洪强宁,最终被寻找技术伙伴的阿北发现,经过几次沟通,洪强宁成为豆瓣第一位全职员工。 阅读全文 »

标签:
阅读:20,082 次
22

——记 Trunk.ly 联合创始人董洵

记者 / 付江

编者按:本文的主人公董洵是微软2004年评出的全球56个架构师MVP中唯一的中国人,在知名外企工作多年,此后经历了多次的创业历程,有苦有乐。他兴趣广泛,除了历史和艺术,还喜欢品南方茶、看书、听各式音乐以及运动。他还在继续创业,最近的项目是一款新型的社会化书签服务Trunk.ly。关于创业,他给记者留下印象最深的一句话就是,创业可能会把一个人在十年里受到的苦和误解,以及对未来的恐惧压缩在两到三年里承受。当然,你的成长速率可能也是加倍的。

去蹭计算机系的课吧

董洵与计算机的渊源可从吉林工业大学(现在的吉林大学)时开始,他当时的专业是机械工程。在大学之前,董洵其实并没有真正接触过计算机,第一次正式与计算机的亲密接触是在大学二年级的时候:“当时就特别喜欢,可以说是一见钟情。”从那以后,他开始在大学里“跳课”,每天去蹭软件学院的课:“当时学校上机费用挺贵的,45分钟要8毛钱,而在学校食堂里吃一顿带荤菜的饭也才1块多钱。”

好在当时不少计算机系的同学并不是真正喜欢这个专业,也不喜欢做课程设计和实习实践,于是董洵就帮他们代劳了。这样不仅上机费有人买单,还能把计算机软硬件专业知识都跟着自学了。

不仅如此,他还帮计算机系的同学上机写作业,按照机时收费,比如当时机房收1块2每小时的上机费,董洵则每个小时多收计算机系的同学两毛钱,帮他把作业完成,存放到软盘上,然后他再用剩下的钱请人帮自己写机械系的作业。由于当时计算机系的作业收费贵,机械系的便宜,行情好的时候,董洵还能剩下钱买软盘用(当时安装中文版Windows3.11需要13张三寸盘)。董洵在大学里的很长一段时间内,都在乐此不疲着。

后话是,董洵在第一、第二学年的时候成绩还是机械系里前三名,到后两年基本上就是混及格的分数了。

董洵正式做软件,是从毕业前跟着学校博士生做项目开始的。离开学校来到北京后,董洵在上地的研华做Windows和Linux驱动程序开发。由于研华是一家硬件公司,而他更偏爱软件,所以在研华待了两年后又去了奥博杰天。 阅读全文 »

标签:
阅读:25,292 次
04

李伟

李伟

西门子中国中央研究院首席架构师、图书《架构之美——软件架构的艺术》作者李伟,从架构师的定义和内涵、能力和素质要求、成长途径等方面向您阐述成为一个真正的架构师需要经历的历程。


记者: 您认为具备哪些能力,才算是真正的架构师?

李伟:虽然业界有关什么是“软件架构”有着明确的定义及共识,但是确实没有软件架构师的定义。简单地讲,架构师是一个技术控制的角色。技术控制是从客户或市场开始,一直到交付或服务的整个链条。如果大家对一个应用研发机构或产品研制机构的主要活动熟悉的话,就知道该链条上存在很多需要架构师负责的控制点。以西门子为例,西门子的战略市场部门就会和业务部门的很多架构师进行协作。这主要是由于战略市场部门的职能之一就是对未来十到十五年的技术和创新进行预判。这样的技术预判,如果没有架构师作为技术控制,单凭MBA出身的市场人员,大家能相信这样的技术预判吗?所以架构师需要具备一定程度的技术及创新预判能力。 阅读全文 »

标签:
阅读:20,920 次
01

王速瑜2提问嘉宾:

王速瑜,腾讯R&D研发总监,从事产品研发和管理工作,对互联网产品发展趋势、管理理念、技术架构有浓厚的兴趣和深入研究实践。目前主要关注敏捷开发、大规模应用架构、企业SAAS、Web2.0产品的相关技术和趋势。

回答嘉宾:林昊

林昊,网名BlueDavy,China OSGi User Group Director,淘宝网平台架构部架构师,个人的研究方向主要为Java模块化、动态化系统的构建以及高性能的大型分布式Java系统的构建。曾编写《OSGi实战》和《OSGi进阶》两篇Opendoc,为OSGi在中国的推广起到了很大的作用。

王速瑜:数据集群问题:当数据增长到一定的数量级,必须要进行分布部署、备份、容灾、切割扩容等工作。请问什么程度的数量级需要分布部署,如何合理分布部署,需要考虑哪些情况?

林昊:一般来说,也没有固定的数量级,通常是根据硬件资源的状况以及所能接受的性能状况(例如一次查询必须在3ms内完成)来决定。当达到性能瓶颈时,通常需要进行数据的拆分或备份等策略,在这个过程中最需要考虑的,就是对应用的影响程度,因此通常会需要一个强大、透明的数据层,以屏蔽数据的拆分或备份、迁移操作给应用带来的影响,另外一方面就是应尽量能做到不停机完成。当然,这很难,因为需要面对多套数据结构并存、数据冗余和同步等问题。 阅读全文 »

标签:
阅读:12,566 次
27

by  图灵公司总编 刘江

关于论文的讨论,Feathers的文章显然成了网上的热门话题,我们另外一本已经获得版权的书《SOA Patterns》(Manning,2009)的作者Arnon Rotem-Gal-Oz受他启发,写了“所有架构师都应该至少读上两遍的十篇论文”:

  1.  The Byzantine Generals Problem (1982) by Leslie Lamport, Robert Shostak and Marshall Pease
  2. Go To statements considered harmfull (1968) – by Edsger W. Dijkstra 
  3. A Note on Distributed Computing (1994) – by Samuel C. Kendall, Jim Waldo, Ann Wollrath and Geoff Wyant 
  4. Big Ball of Mud (1999) – Brian Foote and Joseph Yoder 
  5. No Silver Bullet Essence and Accidents of Software Engineering (1987) – Frederick P. Brooks 
  6. The Open Closed Principle (1996) – Robert C. Martin (Uncle Bob) 
  7.  IEEE1471-2000 A recommended practice for architectural description of software intensive systems (2000) 
  8. Harvest, Yield, and Scalable Tolerant Systems (1999) Armando Fox, Eric A. Brewer 
  9. An Introduction to Software Architecture (1993) – David Garlan and Mary Shaw 
  10. Who Needs an Architect? (2003) Martin Fowler

注意到了吗,其中的第3篇是Feathers也推荐的。

(本文来源于CSDN博客 刘江@图灵,http://blog.csdn.net/turingbook/archive/2009/03/01/3946421.aspx

标签:
阅读:9,520 次
10
  • 数据分片(Sharding)设计问题

假设一家C2C 网站,DB中某表存储买卖双方交易的数据信息,对于一条交易来说,买卖双方数据具有一定程度的耦合性,比如卖家的状态更新对应买家的状态也会更新,对于一个中大规模的电子商务网站,架构师在设计中如何考虑数据分片的问题(假定该表随着数据的膨胀必须拆分)?

  • DDos 攻击问题

对于业界普遍比较头疼的 DDos 攻击问题,架构师需要对此进行预防性设计麽? 如何进行?

  • 钓鱼网站

网络钓鱼(Phishing)令你很头疼麽? 你认为最有效的解决办法是什么?

  • 分布式计算环境

介绍一点分布式事务处理的心得吧? 如何看待最终数据一致性这个问题。

  • 测试方面

技术团队在开发过程中是否进行集成测试? 进行与否的理由各是什么? 对于集成测试你是否有其他补充?

  • 时间管理

对于一个架构师来说,如何与冗杂的会议进行斗争? 你有哪些心得或者贵公司有哪些针对会议的策略呢?

  • 用户体验

架构师是否有必要关注用户体验? 如何从架构师的层面关注用户体验?

  • 时间一致性

对于分布式数据环境,如果数据处理严格依赖于时间,如何确保时间维度上无冲突? 有哪些可选的方法?

  • 阅读问题

最近在看什么书? 简单介绍一下。

标签:
阅读:6,304 次
06

不同类型的网站、公司,因为其各自业务与流程之不同,所赖以生存的系统架构乍看起来大不一样,然而有些基本的理念和元素却是类似的。就在这变与不变、同与不同之间,各家公司和网站的架构师们一方面固本守元,同时心系窗外,希望能借鉴其他架构师的经验,来增加自己对于架构和技术的理解。有鉴于此,《程序员》杂志特地推出“架构师接龙”栏目,以循环提问的方式,邀请业界知名架构师,请他们提出自己的问题,并可指明希望哪个公司或哪个领域的架构师做出回答。当期回答问题的架构师,接下来可以提出自己的问题,并指明下一个接龙的人或公司。如此循环往复,希望能为广大架构师和读者带来有益的观点和思考。

接龙的过程,我们将会直接放在《程序员》杂志官网上,同时择优在《程序员》杂志发表。当接龙数量积累到一定程度之后,我们还将择优整理作为图书出版,也欢迎广大读者和网友积极参与,同时提出自己的问题,有机会获得神秘礼物!

标签:
阅读:7,722 次
preload preload preload
京ICP备06065162