20天3D打印总结

mbot cube 3D打印机拿到手也有20多天了,有空就玩玩,还是做了一些好玩实用的东西出来,总结一些经验来分享。总体来讲3D打印技术还不是太难掌握,对于打印素材来源及模型选择有一些讲究,要特别注意一些模型打印起来非常困难,甚至无法打印。

2015.5 技术雷达 | 平台篇

Apache Spark(spark.apache.org)作为一种快速和通用的大规模数据处理引擎已取得稳步进展。该引擎基于Scala实现,非常适合于那些在多并行操作之间重用数据工作集的应用程序。它即可以作为一个独立集群,也可以作为Hadoop的YARN集群的一部分来工作。它可以从不同的源来访问数据,比如 HDFS,Cassandra,S3 等。不仅如此,Spark还提供了许多更高级的操作符,以便简化数据并行应用程序的开发。作为一种通用的数据处理平台,它使许多更高级别的工具的开发成为可能,如交互式SQL(Spark SQL),实时流媒体(Spark Streaming),机器学习库(MLib),R-on-Spark等。

2015.5 技术雷达 | 技术篇

当我们需要一张描述当前系统的基础设施或物理架构的图形时候,我们通常会选用自己最喜欢的工具来绘制。但是当你使用云或者其他虚拟化技术的时候,这种方式却不再适用。我们可以使用这些平台本身提供 API 去查询实际的基础架构环境,并使用一些简单的工具比如 GraphViz(graphviz.org),一些可以输出 SVG 格式的工具,生成实时的,自动化的基础架构图(automated infrastructure diagram)。

创业提案的逻辑

最近花了大量时间在自己新的内部创业项目,免不了给各种不同的人(内部或外部)进行商业提案(Business Proposal)的工作,同时也在帮助湾区一些社会企业包装面向投资人的Pitch,结合以往大量商业合作项目的经验,我重新思考了商业提案的逻辑,相信无论提案的规模、内部或者外部、创业或者商业项目,一个合理的逻辑都是必不可少,希望这个总结能给你帮助。

2015.5 技术雷达 | 工具篇

尽管依赖管理的概念并不新奇,在很多技术栈下它甚至已经被作为一种基础开发实践,但在 PHP 社区却并非如此。Composer(getcomposer.org)作为 PHP 技术栈下的依赖管理工具,深受其他技术栈下依赖管理工具的影响。例如, Node 的 npm 以及 Ruby 的 Bundler 等。现如今 Composer 已经被 PHP 项目广泛使用,并且其本身也日趋成熟。虽然在对内部库的管理上,Composor 还有待改进,但是对于大多数外部库的管理 Composor 已能够完全胜任。

2015.5 技术雷达 | 语言和框架篇

前端 Javascript 框架持续喷井所带来的一个好处是,时不时一个新的主意出现的时候,会引起我们的思考。React.js 是一个 UI/View 框架,在这个框架中,Javascript 函数在一个响应式的数据流中生成 HTML。我们已经见到几个小的项目成功的使用了 React.js,开发人员也被其干净的易组合的组件化方式所吸引。

为什么你的Scrum会失败?(一)

Scrum失败的原因有很多. 很普遍的一个原因是, 忽视其众多前提而仅仅是把现在的基层开发组织按照Scrum要求的那三种角色改一下, 就算是上马了, 很快Scrum也就像它的音译那样, 变成死马了, 仅留一身马皮. 我们来看一下为什么仅仅把基层开发组织改组为Scrum团队是不工作的.

浅薄的欢腾与自欺的流量

当我们在商业社会初学了讲故事的皮毛,却不知公益更需要引人入胜的故事时,鼓吹营销获得成功的本末倒置的思维又一次在“冰桶挑战赛”上演。公益不需要过度的娱乐、浅薄的关注和喧哗的吵闹,它需要朴素的内心和严肃的思考。

在约束与机会中权衡

做自己最适合的事,就有更好的生产力:在经济学教科书里,我们称之为比较优势。前段时间和几个创业的朋友聚会,发现创业起步者,尤其是靠项目盈利者,有一个最大的误区就在于复制客户或上游链条企业的模式,不少行业级的大企业也正在步入同样的误区:比如设备商做运营商的事,运营商做电商的事,电商做社交的事——这本质上都变成了服务商涉足自己客户的领域,同时又要求客户买单。

DevOps中文名: 开发自运维

在高度不确定性的产品创新中, 对市场的响应速度越来越快, 开发自运维是一个趋势, 可以缩短交付时间和对反馈的修复时间. 这种趋势的前一波浪潮, 则是”开发自测试”/“开发自设计“, 而下一波运动则极有可能是”设计自开发”.

敏捷咨询日记——沟通问题

强调沟通和杜绝浪费是敏捷最核心的东西,这两项基本是贯穿我这次咨询活动的主线-任何细微的活动都需要用心审视两个问题:我做这件事情的前提是传递价值给团队另一个人,那么价值的传递过程中有没有沟通的阻碍?价值的传递过程有没有什么东西导致了传递损耗既是浪费?从一对一沟通谈起,逻辑是你不可能消除所有的沟通壁垒,譬如你的口齿不够清楚,那么至少发现那些你可以消除的壁垒,消除它,并告知和提醒你的听众那些你不能消除的。往往人们犯的错误是:

建设全功能团队——实践篇

在咨询的过程中,我见过太多的团队把目标放在交付上,冀希望于工具,外部力量能够快速的解决问题,往往对小步前进不够耐心,不关心团队的成员。在我们这个 90%以上成员没有.Net经验,50%是毕业生的团队中,那些微不足道的改进,一点点的提升,最终造就了这个9个月中没有一天加班,几乎没有缺陷,提前交付的项目,客户甚至愿意为他们的满意额外支付3万美金作为奖励。我把全篇总结为一句话:把项目目标放在人员能力提升,让项目成功成为能力提升的副产物。