Tag Archives: GeneDock

[得到大学课程作业] 利用“银行家思维模型”经营人力资源信用

  创业GeneDock时精心经营雇主信用,也因此获益:

一、 招聘阶段

  GeneDock技术团队始终坚持:

  1. 至少四轮技术面试,前两轮必须现场写代码。

  2. 最初阶段可以远程视频筛选,但不允许只通过远程面试就发offer。

  3. 一票否决,CEO和我(CTO)也不能推翻。

  严格遵守原则导致错过了不少人才。但产生了很好的口碑。业内的同行、客户、猎头都对GeneDock的严酷标准有清晰了解。有候选人面试时说:“两年前就一心想来GeneDock,但自己在XX和XX两方面达不到GDer标准,我努力做了这些事……”

  我们还通过细节取得信任。例如其他公司的招聘岗位描述(JD)都马马虎虎,只有我们认真“原创”(不止一家大公司曾为抄袭GeneDock招聘文案而道歉或辩解);再例如,有前端工程师投奔的原因是,上家公司要复制GeneDock的网站,结果他在HTML源码里发现一句话:“呆在只会抄袭的环境有意思吗?给我们投简历吧……”

二、离职阶段

  和大多数公司不同,GeneDock在离职阶段花了很多心血。离职一般分为两种:工作不合格被解职,或者能力出色被挖墙脚。

  对OKR不合格的员工,不允许直接“杀人”,必须做一次面谈,由组长、我(CTO)和员工本人参加。组长负责详细列出导致不满意的事项,并和员工一起制定改进绩效的Todo List和deadline,给最后一次机会。坦诚沟通往往带来情绪压力和管理成本,但这是对员工负责任的行为。曾有人面临痛苦的绩效约谈,经历激动人心的“触底反弹”,半年后被评为优秀员工。也有同事虽然遗憾离职,却在多年后表达感谢,因为“当时公司让我心服口服”。

  对于跳槽的员工,不想让人家走恰恰说明有贡献。优秀员工离开,都会收到一份认真准备的推荐信,向未来雇主列举优点和贡献。于是,很多人跳槽后很久还主动给我们推荐人才和客户。我们曾有一次询问前员工谁愿意回来,一个月后就有“新同事”在All hands上打招呼:“大家好,很激动,我又回来了!”

  当然,也遇到过突破底线的恶性事件,对峙公堂;也遇到过资金困难的至暗时刻,夜不能寐……回头看问心无愧,不必细说。

  总之,雇主信用不仅体现在招聘阶段,也应该体现在分手时刻。在人力资源市场建立强大的信用带来巨大优势。2018年B轮时,GeneDock创造了“融资额/团队人数”比值的领域历史记录。

BTW:这节课提到如果要对信用资产”加杠杆“,必须保持警惕,个人非常赞同。

GeneDock做什么?

1. 为什么选择基因数据作为创业的起点?

  2014年,厦戎和我创立GeneDock(聚道科技),希望用数据技术改变临床诊疗,这个使命始终没变。

  创立那年,中美两国允许基因测序技术进行临床试点,通俗点讲就是医生可以依据基因数据给人看病了(此前十几年,人类基因组计划等项目处于科研阶段,还没有成熟到可以应用于一线临床)。所以我们先从基因数据的处理下手。

2. 最初面临什么业务场景?开发了什么产品?

  GeneDock最早的客户是基因检测技术公司和科研机构,典型的业务场景是这样的:每天,不同城市的测序实验室产生上T的基因数据,先进行生物信息处理,再把数据和报告交付给下游客户,交付周期有商业承诺。领导数据生产部门的CIO往往面临很多复杂问题:

  • 首先,原始的测序下机数据无法直接应用,必须经复杂的拼接比对计算方能获得基因突变信息,而且还要对突变进行注释和解读。这就需要调度巨大的计算能力,管理庞杂的分析流程,维护复杂专业的参考数据库和样本信息。
  • 进一步,需要进行细粒度的业务划分和配置:实验团队、生物信息团队和遗传咨询团队处于上下游的不同环节,不同角色应该给予不同权限;而不同的检测种类,也会导致分析步骤的巨大差异,需要专门的分析流程、报告模版配置和数据隔离。
  • 同时,需要对各检测种类的不同处理步骤进行成本统计;对关键数据的使用和修改进行安全审计;对业务全局信息提供仪表板和显示大屏。
  • 更复杂的情况下,客户经常把一部分数据生产工作外包,例如基因测序外包给大的测序工厂,或者遗传解读外包给专门的医疗信息团队,这就必须对跨组织的数据交付、数据质量进行管理,对安全进行审计,对业务进行定期结算。

  针对以上场景,从2014年开始研发名为SeqFlow的基因数据生产线。这个产品首先是支撑海量计算存储的数据平台,对稳定性、算法优化、高吞吐和弹性拓展能力的要求都很高,以保证客户业务的质量、交付周期和成本控制。在此基础上,SeqFlow还增加了企业级的管理大屏、项目管理、权限隔离和数据审计功能,以便管理者对基因数据业务进行高效管理。

3. 研发SeqFlow的关键点是什么?

  SeqFlow的研发重点在于硬核技术,举个例子:分布式调度方面需要把计算任务表达为有向无环图(DAG),这个DAG是瘦长型的,步骤很多,最复杂的癌症肿瘤数据需要上百个步骤,很多步骤依赖成熟的算法包。这就导致常见Hadoop、Kubernetes等框架都无法满足需求(其实今天的Kubernetes是可以用的,但是4年前Kubernetes和其他几种类似框架都不完善,测试时发现了很多致命Bug)。所以我们就自己从头开发了一套分布式计算框架,刚好可以加上很多企业级服务的特性,例如冷数据压缩、项目隔离、Policy鉴权、管理大屏、数据审计机制等。

  刚进入这个领域的时候,市场上30X的人全基因组数据的常规处理价格是800元。2016年的时候,GeneDock发布了全球第一个价格低于100元的人全基因组数据处理服务,同时,这个服务承诺很高的并行处理通量,以及低于万分之一的失败率。我们为整个行业的发展构建了工业级的高性价比、高吞吐量、高稳定性基础数据生产平台。目前,SeqFlow上生产的客户包括泛生子、艾吉泰康、微基因和华大基因等行业领头羊。

4. GeneDock为何向医院客户拓展?

  基因测序技术刚开始临床试点时,大多数医院对它不熟悉,所以把业务外包给第三方检测公司。随着人才和数据的积累,顶级医院开始筹建自己的分子诊断中心:招聘团队,购买软硬件,建立实验室……要在院内完成整个基因检测的闭环。因此,他们也就逐步有了数据平台的需求。

  经过几年的探索,GeneDock从2016年开始全力开拓临床客户。和工业界的生物信息工程师不一样,医生不会写代码,这就要求我们从PaaS上到SaaS,把诊疗场景的产品做透。具体场景包括门诊电子病历收集、实验室管理、生物信息数据处理、位点和诊断报告系统,以及在此基础上构建的数据仓库和人工智能系统,最终实现临床辅助决策支持系统(CDSS)。

5. 基因数据与临床结合,面临哪些核心问题

  临床诊疗是非常专业的领域,场景更加复杂。所以研发难度不仅限于技术实现,而在于能否拥有清晰的业务洞察,设计出专业而易用的产品。得益于早期客户的信任和帮助,团队有机会一次次跟随专家出诊和试验,逐渐理解遗传诊疗过程。举几个例子:

  • GeneDock以前开发过科研病历,以为这套系统可以直接搬过来应用于一线门诊。后来才意识到不对。科研病历往往简化时间维度,把几百个字段平铺开,而门诊病历必须体现诊疗探索过程:根据症状,按指南检测,每一步检测带来更多信息,又决定了下一步的检测治疗方案。
  • 门诊节奏非常紧张,有时医生甚至几个小时没法喝口水,临床数据系统必须提供友好的半自动化录入和专业的检索统计。
  • 涉及基因数据的疾病,往往是遗传相关的。这就需要一套非常专业易用的家系图管理系统,通过家系信息把病历信息、实验样品信息、生物信息流程、检测报告、诊断信息都串联起来。
  • 在实验环节,样品无论外送或自做,都需要精密的实验步骤管理和质量控制,各个医院操作规格不同,又需要自主配置,具体实验室环境下,实验员一旦进入无菌操作环节就必须一气呵成完成操作,这时候突然要求他摘下塑胶手套到电脑键盘敲入信息是不现实。这就需要对场景和交互进行细致理解和思考。

  关于更具体的场景和技术方案,我在很多公开场合分享过。例如2018年初在顾大夫沙龙做的报告《面向临床的基因型和表型数据管理》。今天的公众号会转发那次活动的总结,其中包含了我的PPT。

6. GeneDock的系统已在哪些医院投入实用?

  随着对临床诊疗的理解逐步深入,面向遗传疾病诊疗的数据系统逐步打磨完善,完整覆盖了从门诊病历、实验流程、生物信息分析直到生成诊断报告的完整诊疗流程。GeneDock的数据平台已经陆续在陆军军医大学第一附属医院、四川大学华西医院、上海新华医院、厦门大学附属中山医院、中国医学科学院肿瘤医院、中信湘雅生殖与遗传专科医院、江苏省苏北人民医院、首都医科大学宣武医院等多家客户处投入实用,还有更多顶级医院正在落地。

7. 目前AI是热点,GeneDock有什么成果?

  在清洗好的海量基因数据和临床数据基础上,我们和临床科研专家一起合作,利用统计机器学习方法训练出了非常有效的人工智能算法模型,能够从成千上万遗传变异位点中,自动选取出最有可能导致疾病的遗传病因。

  在2018年的美国人类遗传学会(ASHG)年会上,陆军军医大学第一附属医院(重庆西南医院)医学遗传中心与GeneDock合作开发的遗传性耳聋基因变异功能预测模型DVPred刚刚发布。这个模型明显提高了预测准确度,ROC曲线的曲线下面积(AUC)达到0.998,在遗传性基因变异功能预测方面表现出更高的准确性,灵敏度高、特异性强。

  我们正在和客户继续研发,希望类似“大数据宝宝”的案例越来越多,让更多的患者真正受益于数据技术和人工智能技术。

8. 创业四年下来,你个人有什么总结?

  反思当然很多了,有一些是关于沟通、招聘和管理的,不多说。

  关于复杂系统的工程研发,这两天重新看了自己2015年梳理的博客《思考:如何开发应用平台》。感觉当时写得还不错,现在回头再看,很多观点都被验证了。当然,侃侃而谈是一回事,事到临头真处理好不掉进坑里,又是另外一回事了。有些东西必须躬身入局经历一番才算真懂。这一期公众号,这篇老文章也会发出来。

  总而言之,能构建起一支专业的软件工程团队,很有成就感。

9. 完成了B轮融资,接下来重点是什么?

  GeneDock会和越来越多的专家团队合作,对更多业务领域进行探索。不仅限于简单遗传模式的疾病,也开始涉及癌症、帕金森等复杂疾病,逐步覆盖生殖三级防控(婚前、孕前和产后)的各个阶段。

  具体到眼前这个阶段,随着标杆客户案例的建立,已经很多公司和医院的业务开始落地。项目交付能力至关重要,这取决于整个团队的软件工程水准:从需求分析、产品设计、研发迭代、测试发布、部署上线……要有一整套成熟高效的工程体系。这方面是GeneDock团队的强项。当然,团队还需要补充很多人才。

10. 对于想加入GeneDock的人有什么建议?

  随着B轮融资的到位,资金不再是问题,我们需要更多的程序员、基因数据工程师、人工智能专家和分子遗传学专家,对临床和基因数据进行充分的挖掘和建模。更详细的职位描述,欢迎访问 https://www.genedock.com/joinus/

  除了具体技能,个人想提醒的是,创业公司都会有一定的不确定因素。投简历之前一定要想清楚:心态上来说,创业变数多,需要有很强的抗压能力;能力上来说,需要你独当一面,有很强的落地执行力。GeneDock初步打开了局面,现在加入对个人而言有很广阔的成长空间。欢迎入伙!

GeneDock研发团队的一些方法论

  逼着自己上来写BLOG。最近工作强度非常大,回到家吃完饭洗完碗,真的手指尖都不想动一下。不过工作有进展,人有成长,心情还不错。今天冒着大雨回家,浑身湿透,但是心里一动:“两年前的今天我心情很糟,现在虽然累得像条狗,却很充实,看来这次创业是对了。”

  创业以来,感觉还算顺利。所谓好运气,部分源于GeneDock团队有一套自洽的逻辑。创业和投资说到底拼的是世界观,你对现实世界的某个局部有独特的洞见。这里面有些关于技术产品,有些关于团队管理,有些关于商务销售。

  这篇BLOG再总结一下GeneDock研发的方法论。算是呼应一年前的那篇《思考:如何开发应用平台》,对其做一些补充或再次强调。

一、彻底信仰API

  Alex Iskold说:“API代表公司的业务本质……思考API实际上就是思考公司的未来……”

  绝对赞同,一年多前我在社交网络发过一条对国内一些所谓基因云的吐槽:“不是做个Web页面就有资格叫云计算的。前端若不提供RESTful API、编程语言SDK以及UNIX风格的CLI工具包,后端若没有可拓展的分布式架构、防单点故障的failover机制……就别觍着脸自称云计算了,这只是一个网站而已”。这话似乎刺痛了某些人。

  GeneDock刚刚对外开放了第一批Workflow和Task有关的11个API。欢迎大家试用,这里是API-Reference文档。如果单从Web Service的设计这一点看,我们的产品领先于国内外友商。

二、To B 的产品逻辑:别抖机灵

  To B 产品和 To C 产品有很多业务差异。To B 是给专家甚至专家团队用的软件,本质上在卖你对行业的独特洞见,在卖你的工作哲学。例如,当年SAP的ERP软件最成功,因为他们最理解德国制造的业务逻辑;再如,Salesforce在卖的是销售团队的方法论;而GitHub实际在卖他们对软件工程的理解:Bug管理、版本管理、Code Review……

  另一方面,To B 和To C 其实都是给人用的软件。从设计和研发的方法论来看,并没什么本质区别。GeneDock产品经理何荣惠(在阿里云的时候程序员们昵称“神仙姐姐”)在知乎回答过“to B 的产品经理和 to C 的产品经理有什么差别?”,我觉得写得很好。

  总之。To B 产品,抖机灵没用,保持克制和敬畏。躬身入局,琢磨清楚基因数据传输、存储、分析、应用的所有业务场景。

  我们刚刚上线的企业账号功能,对很多团队都有用。GeneDock官方BLOG对此有描述,推荐大家看一下。

三、坚守软件工程底线

  GeneDock只雇用最好的程序员。好程序员必须能熟练应用软件工程的成功方法论。

  至于什么是好的软件工程,一年前都写过了:“好的软件工程实践,决定了技术团队的层次。Github用的怎么样、Bug管理怎么样、代码审核是否严格、发布升级是否自动化、有没有单元和集成测试……到一个技术团队里呆几个小时,鼻子闻一闻,就知道几斤几两。技术团队如果这些基本功不好,摩擦力会越来越大。”

  不只是提高自己内部生产率,GeneDock还想把数据生产的最佳实践推广到整个行业,成为生物信息行业的GitHub。我们正在优化配置和调试的体验,总结GeneDock生信团队的流程规范。后面会不断放出软件工程培训文档和配套工具,让生物信息程序员们效率更高,更专业,工作更有价值。

GeneDock招收生物信息实习生

  GeneDock每天帮助客户处理TB级别基因组数据。基因数据工程师支撑这个行业最活跃的创新企业设计业务架构方案,使用Docker容器等各种数据技术帮助客户把NGS分析流程迁移到云端。

  我们正在招收生物信息实习生,具体岗位要求请参考 https://www.genedock.com/joinus/ 这里的“生物信息算法工程师”和“基因数据工程师”两个JD。实习工资比照互联网行业平均标准按天计费。要求全职实习至少3个月以上。转正offer可以在面试时一起谈掉,也可以实习期间再谈。

  简历发送到 hr at genedock dot com 。也欢迎推荐人才。老规矩,实习生转正或候选人入职过了试用期,推荐人送iPhone或大疆DJI无人机。

2016新年快乐

  从2006年开始,每次1月份都会定两三个目标。之后一旦遇到纠结就力保重点,其他事一律让路。翻了翻过去10年元旦左右的BLOG:产品、论文、专利、买房、买车、求婚、生娃、跳槽、旅游、项目、商用、创业……单细胞动物,明取舍断妄念,受益匪浅。

  2015年只定了一个目标,是关于创业和成长的。一年下来,挺困难挺好玩的。感谢周围一圈恨铁不成钢、费心点拨我的朋友师长。忠告听进去了,善意记下来了,方法论还需要更多思考、学习和实践。今年最主要的目标一定还是与此有关,我需要好好琢磨一下。在GeneDock产品还不完美时,很多胆大的天使客户就毅然转向了基因云服务。2016年,要让他们获得与远见相称的收获。

  过去一年,只发了12篇BLOG,只买了34本书,都不到往年的一小半。所以2016年的目标之一是读50本书,并在BLOG和豆瓣上分享读书笔记,哪怕只是只言片语。

  RUDY哥酷爱马拉松一年参加四次正赛并获得奖牌,他总鼓励我尝试参加一次半程马拉松。我还在犹豫。其实想滑更多次雪,新买的单板装备却总没时间用,郁闷!倒是和RUDY哥打了一个赌:如果能B轮成功,我会把头发全部染白,RUDY全部染红(BTW,这个赌局,CEO怂了)。大家给我们作证!

思考:如何开发应用平台

一、开发难度

  和创造单个应用相比,创造应用平台的难度要高一个数量级:

  1. 架构难度:和特定应用不同,应用平台是开放性的,允许别人到系统肚子里自主编程,因此应用平台的用户边界本质上是API。设计一套干净强大、可拓展、安全、完整自洽的API,并在此基础上构建SDK、Console、GUI……是很难的。进一步,为了支撑第三方开发,需要有编程工具链。尽管程序员们都会用编程工具,但即使是计算机系科班出身的程序员,90%也不清楚DSL编译器和IDE的实现原理。

  2. 产品难度:应用平台的产品设计,需要抽象和分解能力。不仅仅满足某个具体用户场景,而是必须把握各种应用开发者在各阶段遇到的各种问题。这里面除了用户体验、E2E场景、还得注意统一的设计哲学和必要的分寸感。没经验的PD往往忽视谨慎思考和设计,强调快速迭代和重构。对应用平台而言,指望靠蛮力代替深思熟虑,行不通。

二、成长周期

  关于平台何时成熟,存在一些客观规律:

  1. 平台真正“立”起来至少需要4年时间。看那几本回忆Unix、Windows NT、NeXT、AWS初创的书,例如G.Pascal Zachary写的《观止:微软创建NT和未来的夺命狂奔》,这些系统前4年都跌跌撞撞甚至反复重构。

  2. 第2年最容易死。BAT三巨头几乎同时启动自主云平台:阿里的飞天系统、腾讯的台风系统、百度的C++重写Hadoop计划。但腾讯和百度的团队在第2年的时候都挂掉了。事实上,阿里云差不多也在那个阶段经历了惊涛骇浪,只不过运气好,马云这个老板异于常人。

  3. 关键是团队的成熟。阿里云最重要的行业贡献不在于其本身的IaaS业务,而在于那支从零开始把操作系统做出来的技术团队。现在飞天团队很多牛人跳出来创业,如果还是做平台的话,就会知道哪里有坑。

三、方法论

  1. 发布的节奏感非常重要。从阿里云辞职,老上级点拨我:如果只做一件事,就是保持发布节奏。一个里程碑一个里程碑下来,现在是Sprint 18。真是做对了。虽然前面说4年才能成熟,但是不可能有老板真能容忍你4年啥业务也不扛。这就意味着,得向客户和业务团队承诺产出,一旦承诺了就必须说到做到。这还意味着,必须现实主义,收敛战线,降低阶段性期望,为支持业务做些妥协。衡量一个技术团队的基本标准,就是持续交付能力。

(Intel曾经遇到过困境,CPU浮点运算部件有错误,不得不召回,AMD弯道超车抢先推出多核CPU。可惜AMD无法保证稳定交付,结果又坐失良机。再往前,摩尔定律其实不是客观存在的自然规律,而是Intel的明确战略,给客户承诺的交付节奏,给自己团队戴的紧箍咒。在撞到纳米墙之前几十年,Intel一直说到做到)

  2. 时刻关注平台架构。保持低耦合高内聚,保持模块之间的正交。否则越往后越痛苦。尤其是客户业务接进来之后,如果边界不清晰,到处插管子,就死定了。要理解著名的Conway’s Law: A design reflects the structure of the organization that produced it。这条定律的意思是:什么样的团队组织结构,最终就会开发出一模一样的软件架构。如果有四个小组合作开发编译器,系统最终一定会长成一个四阶段编译器。所以大型软件组织内,在重构系统之前往往先reorg团队。

  3. 好的软件工程实践,决定了技术团队的层次。Github用的怎么样、Bug管理怎么样、代码审核是否严格、发布升级是否自动化、有没有单元和集成测试……到一个技术团队里呆几个小时,鼻子闻一闻,就知道几斤几两。技术团队如果这些基本功不好,摩擦力会越来越大。

  4. 问题是什么,永远比解决方案更重要。最常见的错误就是:拿着个锤头,眼里看来满世界的问题都是钉子。必须花很多时间深入思考:客户有什么问题?我们能带来什么改变?逐渐建立对这个领域的独特洞见。

(仔细读了读巴菲特创业最初10年的信。他先建立了自己的独特benchmark,然后把投资对象分为4类,每类有不同的触发条件和行动。)

  5. 找到issue优先级明确roadmap才能减少焦虑。能砍事儿的才是合格的产品经理。做了太多客户不需要的事,团队总是加班,这是管理债,是耻辱,不是骄傲。

(讲到这里,顺便贴一篇两年前给pFind组的回信,最近Boss H又翻出来抄送给pFind团队)

  我已经离开pFind很长时间了,不了解细节。说错了大家拍砖。憋了好久,没憋住,因为pFind始终是我的产品。

  所谓战略,是明确不做那些“比较对的事”,只做一两件“非常对”的事情,壮士断腕才能做好产品,好产品才有资格进一步谈平台化和生态系统。

  客户需要精确的结果,客户需要飞快的速度,客户需要傻瓜式的安装和参数配置,客户需要全流程解决方案,客户需要在平台第三方开发的API和SDK,客户需要易用的界面、配图和表格……不从前面这些需求里砍掉90%,集中精力把剩下的一两项做到全世界第一,就没意义。

  不如每个人列两个单子:你认为pFind最该做的事,最该放弃的事。别写很多所有人都同意的真理,信息熵为0。如果为了防止互相影响,就单独发给BOSS H汇总。

  恕我直言,所有界面类的开发工作,pFind组都很不擅长,做得很苦、做得很烂。我们这些人离顶级UED差得太远,也未必有热情追求用户体验的卓越。也许更应该集中做算法、做流程框架、设计数据接口和API、向外界开发者提供API和SDK(这里的API也许是本地的,也许是Web Service)。至于界面也不是彻底不做,现有界面可以重构到前面说的API和SDK上去(以便吃自己的狗食,验证API、SDK的设计合理性)然后再开源出去。

四、BD和运营团队

  传统背景的业务人员面临挑战。因为他们要花一些时间才能意识到:推销的是通用平台,而不再是某种具体应用。

  1. toB销售,又面对专业技术话题,业务团队需要配备得力的业务架构师(BA)帮助技术交流,给解决方案。

  2. 找来了很多客户,仔细聊下来,有一半其实是需要Word(应用),而不是Windows和VC++(平台)。早期应该组建专门的技术小组,自己扑上去帮客户开发应用,也算吃自己的狗粮。后期再逐渐找外包商和集成商。CEO说,友盟的前70个客户,都是友盟自己的程序员扑上去帮他们写APP。

  3. 平台是前所未有的东西,是改变现状的创新。所以业务团队的目标不是销售数字,而是尽快立起标杆客户。

  4. 业务团队需要了解技术团队的发布节奏。知道有“水面以下”工作量存在,例如产品架构设计,例如重构偿还技术债。这些最终会影响到技术团队的持续交付能力。

  5. 业务团队有权要求更多后方的火力支援,理直气壮扯着产品经理的耳朵大喊客户需求,明确业务优先级,并监督技术团队的产出。

  6. 最终,其实和技术团队一样,业务团队最大的挑战还是学习能力,建立独特的思考模型。

GeneDock成立一周年了

  今天是GeneDock成立一周年。一大早,在外出差的厦戎就发了一封邮件出来。我很喜欢里面的一句话:“一起建设一家员工喜爱,客户信任,行业尊重的好公司。”

  后来RUDY哥又发了一篇博客《做一只努力的梯子》,感觉特别符合当下的心境。“做钉子的做一只坚韧的钉子,做踏板的做一只不打滑的踏板。”

  搜索了一下,找到去年刚开始时发的一篇微博

  回到家,女儿跑过来,给了一个认真的拥抱。

  跳出懒惰、恐惧、自负、自怨自艾……专注起来,做一个快乐、靠谱、勤勉的创业大叔。

GeneDock刘畅将在PyCon China 2015做报告

  人生苦短,我用python。但用python最人痛苦的事情有二件,一个是编码问题,另一个则是import不了包。9月19日,GeneDock团队的刘畅大神应邀在PyCon China 2015大会上做技术分享,题目是:python的module机制与最佳实践。

  畅爷这次报告将详细讨论python的包管理机制,python如何引用包,PYTHONPATH是怎么回事,sys.path与其有什么不同。为什么py3把py2的包引入机制彻底废弃。py3的absolute import又是怎么回事。还会给出关于python项目目录的最佳实践,避免各种引用的问题。

  刘畅,曾就职于微软与阿里云,现在是我们GeneDock创业团队的一员。他的博客地址是:http://lcblog.sinaapp.com/

GeneDock招聘前端工程师

  GeneDock.com是基因数据云计算领域的创业团队,帮助各领域用户处理海量的基因数据。随着业务增长和产品功能的增加,前端团队已经忙不过来了。所以我们需要你:一位有品味、有好奇心、热衷于前端技术的工程师。

  我们的系统是典型的云服务,实现了前后分离:后端复杂的分布式计算、上T数据的处理作业,都封装成了标准RESTful API;而所有的界面渲染和用户交互逻辑,则全都委托给前端AJAX实现,也就是常说的SPA(single page application )架构。在GeneDock团队,你有机会做出最酷的代表作,成为出色的全栈工程师。

  基因数据的业务交互非常复杂,前后端如何配合,提供多样流畅的用户体验是个关键问题。GeneDock团队正在实现:

  1.基因数据可视化。包括方便的基因浏览器,多样的交互统计图表功能,帮助用户高效对比多组DNA数据,查看和标注变异位点。
  2.生物算法开发IDE。包括App和workflow的图形化配置工具,帮助生物信息工程师通过更好的交互方式创建和调试基因数据的分析算法和流程。
  3.专业文档模板编辑器。包括交互式图表编辑和展示界面,让用户只需要编辑markdown模板,就可以通过报告引擎自动化生成分析报告。
  4. 多种资源控制面板。包括数据、计算任务、分析流程等的监控管理平台,帮助用户更简易的操作和分析大量的基因数据和计算作业。

  如果你对上面这些事有兴趣,请联系我们 hr@genedock.com 。GeneDock团队在云计算领域拥有丰富经验,会提供互联网行业有竞争力的薪酬、福利和员工期权计划。具体职位描述如下:

前端工程师
  我们希望您热衷于前端技术,对浏览器加载方式理解深刻,渴望实现多样流畅的用户体验。

工作职责:
  设计并开发web前端页面,完善报表展现、数据操作等功能,并能使用缓存和按需加载方式优化页面性能。

任职要求:
  1.熟悉W3C标准,熟悉MVC模式;
  2.熟练掌握HTML/JavaScripts/CSS等前端技术;
  3.熟悉jQuery/Bootstrap等常用库;
  4.对用户交互设计有自己的理解。

其他:
  1.熟悉主流Web框架优先;
  2.有数据可视化经验优先;
  3.熟悉Html5/AngularJS优先;
  4.有git使用经验优先。

更多细节,请参考: https://genedock.com/joinus/

4月11日的NGS创新开发者大会,GeneDock有个分享

  我们会参加明天(4月11日)的NGS创新开发者大会2015。GeneDock的CEO李厦戎博士会在大会上做一个报告。大会的具体日程点击这里。测序中国和基云惠康主办组织得非常成功,据说报名人数超出了预计的50%,会场已经彻底装不下了。很多圈子里的朋友都在,希望和大家多交流。以前没见过面的同学可以在会场上给我的微博账号 @还是地雷 发消息互相找。