• 顾仲贤
    2019-01-13
    哈哈,飞总总结得很好!我本人就是在Facebook工作,加入后,才体会到公司贯彻快糙猛很彻底。 其实本人也一直从事数据库方面的开发,原先是在Pivotal Greenplum里做Query Optimizer ORCA的。后来加入了Facebook, 虽然没有接着做这块(主要看了Presto, 感觉好像不是很看好),但还是对大数据这块非常关注。 读这个专栏,学到很多。不知道飞总现在还在西雅图吗?有机会来湾区很想当面认识您,再谢谢您的专栏。
    
     5
  • 幻想
    2018-07-21
    哈哈,好文章。
    
     3
  • bili
    2018-11-23
    A Philosophy of Software Design第三章也用Facebook为例讨论了类似的主题。文中定义并比较了两种编程模式:tactical战术编程着眼于尽快实现功能,而与之相反的strategic战略编程则着眼于好的设计,顺便实现功能。短期来看战术编程能更快出活,但长期来看由于技术债越积越多,开发效率将落后于战略编程。很多公司刚起步时会想着设计好不好以后再说,这里最危险的点在于,一旦有了拖延的想法,明日复明日,最后可能就积重难返了。作者提出的建议是,好的设计一开始就需要是目标之一,可以调节这方面投入的比例,但不能是零。Facebook作为反面教材在书中自然也是被大肆批判了一番。
    
     2
  • 顾仲贤
    2019-01-13
    再和飞总说个我自己参与的大数据相关的创业项目,离开Pivotal当时是因为在Pivotal的director做了这么多年数据库意识到一个问题就是,即使后面出来的数据库性能更高,还便宜,但想要从老牌数据库公司挖客户(比如Oracle, Teradata) 还是很难,痛点就是migration。即使application code用的是jdbc或者odbc, 正真migrate起来也不是换个driver就行,更别说很多老客户用bteq这种原生client. 这个director (Florian Waas)出来就创立了Datometry,我就当时也心一横也扎进去啦。Datometry version就想做vmware in terms of database,作为一个中间键,连接在客户的application和后端新数据库之间,而且保证底层协议端完全兼容(客户端相当于只要改个数据库ip地址就行),然后对所有请求,做runtime transfer和rewrite外加结果集的转换。我在那做了两年多,后来因为感觉发展有些缓慢,而且公司也经历了多次pivot, 外加也想尝试些新东西就离开了。那个时候我们已经有不错的POC版本,前段可以支持teradata, 后端支持psql兼容的,比如Grrenplun, redshift. 但感觉离production ready还是有距离,诚然,我觉得技术上难度挺大的。 已经离开两年了,感觉现在还是不瘟不火。很想听听飞总对这样一个公司和技术的理解。多谢。
    展开

    作者回复: 数据库这个东西真的是不好做,尤其这种做中间件想法的,我是不看好。IBM sybase都想过这样的做法都挂了。

    
     1
  • ByteFeng
    2018-07-21
    你的公众号的名字是什么,我去关注关注。还有你平常写不写技术博客,或者看不看技术博客,有没有,在大数据领域,技术博客写得不错的,推荐推荐。

    作者回复: 飞总聊IT

    
     1
  • 北冥Master
    2019-09-12
    谷歌刚开始创业的时候,代码质量也很差。jeff进来以后完全重构
    
    
  • Geek_aea02e
    2019-08-30
    当一个人一无所有的时候,唯一的办法就是拼力气。但是到了一定阶段,有了深度,就不需要拼力气了。实际很理解小扎的这种想法。小扎就是穷缀学生。拿他跟谷歌两个创始人比,实在是委屈呀。
    
    
  • epos
    2019-05-02
    Move Fast and Break Things 这句话在企业创业起始阶段 是最大的优势
    
    
  • Panda
    2019-02-26
    FB 虞兮虞兮奈若何
    
    
  • 逝水流年
    2018-12-14
    大开眼界啊 很有意思
    
    
我们在线,来聊聊吧