Skip to main content

2015.5 技术雷达 | 平台篇

   点击这里可以下载最新中文版本PDF

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

一段时间以来,Hadoop 社区一直在尝试把低延迟和交互式 SQL 查询能力带到Hadoop平台中(称为SQL-on-Hapdoop)。开源数据库引擎 Cloudera Impala,Apache Drill 和 Facebook的 Presto 都在2014年应运而生。我们认为,SQL-on-Hadoop 这一趋势标志着一个重要的转折,它将 Hadoop 的定位从与数据库互补的批处理,转变为某种可以与之竞争的技术。

Cloudera Impala(cloudera.com/content/cloudera/en/ products-and-services/cdh/impala.html)是早期的SQL-on-Hadoop 平台之一。它是一个基于C++的,支持大规模并行处理的分布式查询引擎。Impala 守护进程是这个平台的核心组件,其负责协调 Impala 集群中跨一个或多个节点间 SQL 查询的执行。 Impala 充分利用了 Hive 的元数据目录来共享两者的数据库和表。Impala 还提供了命令行工具以及 JDBC 和 ODBC 驱动程序供应用程序使用。

密码仍然是一种糟糕的用户认证机制。近来我们看到有公司(如Yahoo!)采用了“无密码”的解决方案——每当你需要从一个新的浏览器登录时,一个一次性验证码会被发送到你的手机来进行认证。如果你仍在使用密码认证,我们推荐您采用能够显著提高安全性的双阶段认证(two-factor authentication)机制。基于时间的一次性密码算法(TOTP)(en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm)是目前这个领域的标准,在 Google(play.google.com/store/apps/details?id=com.google.android.apps.authenticator2)和 Microsoft(windowsphone.com/en-us/store/app/authenticator/e7994dbc-2336- 4950-91ba-ca22d653759b)智能手机中都这样免费的认证应用。

Apache Kylin (kylin.io),是一个来自 eBay 公司的开源数据分析解决方案,它能够在超大数据集上进行基于 SQL 的多维度分析(OLAP)。Kylin 旨在构建一个基于 Hadoop 的混合 OLAP (HOLAP) 解决方案,最终将能够支持 MOLAP 和 ROLAP 风格的多维分析。你可以使用 Kylin 所提供的立方体设计器来定义立方体,并启动一个离线进程来构建它们。离线进程会进行一个预连接的步骤,将事实表和维度表连接到一个扁平化的结构中。下一个是预聚合阶段,各个单独的立方体被 Map Reduce 任务会构建出来。其结果被存储在 HDFS 序列文件中,之后被载入 HBase 。数据请求可以由基于 SQL 的工具提交 SQL 产生。查询引擎(基于 Apache Calcite)会决定目标数据集是否在 HBase 中存在。如果存在,该引擎会直接访问 HBase 中的目标数据,以次秒级延迟返回结果。如果目标数据集不存在,该引擎会将这些查询转向 Hive(或者是集群中任何其它可以用 SQL 查询 Hadoop 的方案)。

CoreCLR (github.com/dotnet/coreclr) 和 CoreFX (github.com/dotnet/corefx) 是 .NET 的核心平台和框架。虽然算不上是什么新闻,他们最近被微软开源了。一个主要的变化是这些依赖是基于二进制文件来部署的,不再需要事先安装在机器上。这使得并行部署变得容易,允许应用程序可以无冲突的使用不同版本的 .NET 框架。你可以安装 .NET 依赖到任何环境中,基于 .NET 编写代码成为了一个实现细节。从外部依赖的角度来看,一个用.NET实现的工具与用 C 语言编写的东西并没有什么不同,这就使它成为编写通用应用程序和工具的一个更有吸引力的选择。CoreFX 也已被分解为独立的 NuGet 依赖,从而使应用能够按需使用,这让 .NET 的应用和库占的空间的更小,并使得替换部分框架更加容易。

Heroku 用它的12要素应用模型改变了我们关于构建、部署、托管 Web 应用的方式。Deis (deis.io) 将 Heroku PaaS 模型封装到一个开源框架中,部署在可被托管在任何地方的 Docker 容器中。Deis 仍在进化当中,但对于那些符合12要素模型的应用来说,它具备大大简化部署,并在你自选的环境中进行托管的潜力。Deis 也已成为 Docker 周边丰富的平台和工具生态系统中的又一鲜活事例。

预测分析在越来越多的产品中被使用,而且通常出现在面向最终用户的功能上。H2O (docs.0xdata.com) 是一套非常有意思的新开源工具包(其背后是一家创业公司),因为其易用的用户界面设计,使得预测分析对项目组更可用。同时它还集成了数据科学家最喜欢的一些工具:R 和 Python 语言,以及 Hadoop 和 Spark。H2O提供了很高的性能,并且依我们的经验,非常易于在运行时集成,特别是在基于 Java 虚拟机的平台上。

当 Oracle 决定停止对 Sun 公司的 OpenSSO(一个开源的访问管理平台)进行开发时,ForgeRock 决定接管它并将它集成进他们的 Open Identity Suite 中。现在它被命名为 OpenAM (forgerock.com/ products/open-identity-stack/openam) ,成为了一个支撑 OpenID 连接和 SAML 2.0的可扩展的开放源码平台。不过,由于 OpenAM 历史悠久,导致它的代码库很庞大,并且文档也很难理解。希望在不久后,一个更轻量级的,对自动化部署和配置提供更好支持的替代方案将会出现。

Spark 是基于云的互联设备全栈解决方案,Spark Photon 是一个带 wifi 模块的微控制器,而 Spark electron 是连接到移动网络的变体。Spark 操作系统为这些设备添加了 REST API 服务。这套解决方案降低了进入物联网,并构建你自己的可连接设备的门槛。

时间序列数据库(TSDB)是一种针对时间序列数据的处理做了优化的系统。它允许用户对各种以时间序列组织起来的数据库对象进行 CRUD 操作。同时它还可以在整个序列上执行统计计算。虽然时间序列数据库不是一个新的技术,但是我们还是在这些数据库应用中看到了一些新的热点,尤其是在物联网应用领域。在许多开源和商业平台(比如OpenTSDB, InfluxDB, Druid, BlueFloodDB 等等)的促进下,时间序列数据库技术发展迅猛。另外还值得一提的是,其中一些数据库产品还使用了类似 Cassandra 和 HBase 的分布式数据库作为他们的底层存储引擎。

容器技术,PhoenixServer 以及持续交付的崛起已经开始让我们摆脱昔日部署 Web 应用的方式。传统方式是我们需要构建出应用工件,然后将工件安装到应用服务器中。这种方式会导致较长的反馈周期,构建时间的变长,以及在生产环境中管理这些应用服务器的开销变大。除此之外,这些应用服务器也很难做自动化。在与我们一同工作的很多团队中,开始倾向于将 HTTP 服务器嵌入到应用中。有很多可以选择的嵌入式服务器:Jetty, SimpleWeb, Webbit 和 Owin 等。更容易做自动化,更容易做部署,对基础设施的投入也会减少,因此我们推荐在未来的项目中使用嵌入式的应用服务器而不是传统的应用服务器。

Google 从2009年开发了一个实验性质的协议 SPDY (chromium.org/spdy/spdy-whitepaper),作为一个替代协议,它用于解决 HTTP/1.1中的一些性能短板。新的 HTTP/2 标准协议包含了很多 SPDY 中性能优化的关键特性,Google 已经宣布从2016年初就会停止在浏览器中支持 SPDY。因此,如果你的应用需要 SPDY 中的特性,我们推荐你去尝试 HTTP/2。

点击这里可以下载最新中文版本PDF

Share

敏捷咨询日记——消除浪费

waste

当我们追根溯源敏捷最先被发明的初期,可以发现,敏捷所消除的便是因为频繁业务需求改变带来的潜在浪费,而一切关于杜绝浪费话题到最后,都变成为对价值的纯粹追求。任何商业模式都基于创造新用户和挽留老用户,最终也被细化为为新用户提供不可替代的新价值和为老用户提供持续改进的旧价值(当然同样可为新价值)那么两件事情被认为是杜绝浪费最重要的两个方面:

  • 只给客户想要的;
  • 让客户简单地用到他们想要的;

简而言之,做了没用的和没用已经做了的是最普遍的两种浪费。二者间的关系是:做了没用的往往的结果是未使用,但未使用往往不止是因为没有用(也许你不够好)。

一个简单的对话可能会揭示这个道理。gigix在贴卡片的时候使用了没有ThoughtWorks logo那一面,我问:用反面的价值是什么?gigix说:我顺手写在了反面。我说:那你就把 logo marketing的价值浪费了。gigix便马上在正面重写。可以看出,在卡片的正面印上公司标志是一件具有市场推广和提高品牌认知价值的事情,我们也同意这种价值是实际需要,但是有50%的情况我们可能会忽略这个价值,于是,这个价值便被浪费了。

据说这个卡片的成本是两毛钱,而印刷logo的成本可能是1毛钱(印logo的唯一价值就是展示出来,于是不展示出来的浪费就是100%),每年全球范围内整个公司的卡片消耗量估计有51万张(一个人一年大概消耗300张,一年就是300X1700=510000张)于是理论上每年因为没有展示公司logo造成的浪费就是25500元。

解决这个办法有两个,长期的,如果每个TWer都有一种价值驱动的自然反应,把浪费扩展到日常生活中去,这个价值被浪费的几率可能减少;短期的,两面都印logo的成本理论上比一面印一面不印还要低,而当两面都有的时候,这种浪费便不可能发生,甚至成本更低。

这就是为什么用户体验被拔高到一个很高的地步,良好的用户体验可以更容易地把有用的价值传递到用户使用过程中,而很可能,往往被忽视,这是一个投入低于可能产生的价值浪费的过程。

敏捷当中关于杜绝浪费的阐述,绝对不应该只是个适用于软件开发(或精益制造)的概念,它应该贯彻到所有日常管理开发的过程中。有时候,我会刨根问底地询问某个内部管理表格上某行小字表述的意思,或者某个状态图中某个多余标签颜色的目的,甚至关于饮水机摆放位置的斟酌。

当各种询问进行之后,你会惊奇地发现,这样的价值最后一定被认为阻塞在一个更高级阶层人物的脑中,而所有人要做的只是忍受一次便接受这种浪费。而这样的现象成为一种奇特的人类自适应习性,特别是在一个具有组织结构的环境里,人们不加思索地游走忍受各种浪费,或者说有意识的拿出可能百分之一的生命作为浪费,而不去质问这个所谓深藏在高阶人士脑中的某个模式。而更神奇的是,这样的组织结构似乎就是为了种容忍浪费的习性提供养料,他们用权威语言(community language)描述这种可能产生浪费的活动,用意识形态的方式提高质问的门槛,他们用一种容忍浪费的高明手段来杜绝“浪费”,这种“浪费”被理解为更多的投入,或者改变,或者干脆就是自己权重更大的时间。

更深层次讨论这个问题这样的浪费被打造成一种十分有效的管理手段,因为我们的文化里,当你不懂我的时候,浅意识里我高过你,当你懂我的时候,你可能高过我,换言之,阻塞价值传递带来的心理慰籍多于价值广达于人。于是,如同状元可当驸马入赘皇族给天下清苦寒士打一针鸡血一样,这种“你不必懂,你只需做”的潜台词,成为底层工作者努力上进的“状元奖品”。同时,不可避免的是,各种浪费在这庞大的机器里不停被产生,讽刺地是,某种意义来说这样的浪费便成了机器运转的润滑剂,我们的发展不也是基于更庞大的物质浪费吗?

或许,我说到了最苦恼的地方,我努力尝试把敏捷方法跳出制造业(基于流程的软件业也是一种制造)而更多地作为一种现代企业管理方法论引入企业日常管理当中去,而似乎,敏捷原则的桎梏在于对人的依赖,以及是不是还有权威与非权威的概念,回到刚才的例子,如何保证所有质问的价值都是低于浪费本身的-万一大部分人的质问都是无理取闹?权威“不必问,只需做”的方式是不是本身也是一种杜绝浪费?

就此来看,敏捷方法还有很多值得思考的东西,但杜绝浪费初衷本身是值得肯定的。

本文转载自:

Share

2015.5 技术雷达 | 技术篇

点击这里可以下载最新中文版本PDF

2015-5 技术

当多个独立开发的服务通过 API 交互的时候,API 提供端的改动会让它所有的消费端调用失败。消费端服务通常也不会直接去连接处于开发中的提供端服务来进行测试,因为这样的测试是缓慢且脆弱的(martinfowler.com/articles/ nonDeterminism.html#RemoteServices),因此最好的方式是采用测试替身(martinfowler.com/bliki/TestDouble. html),但这又引出了测试替身和实际的 API 之间失去同步的风险。消费端的开发团队可以通过使用集成的合约测试(martinfowler.com/bliki/IntegrationContractTest.html)来保护自己——其比较真实服务的响应和测试替身之间的一致性。这样的合约测试是非常有价值的,而更有价值的方式是消费端把它们的测试提供给 API 提供端——采用消费端驱动的合约(martinfowler.com/articles/consumerDrivenContracts.html),提供端可以运行所有消费端所提供的测试来验证自己的修改是不是有可能引起问题。这种消费者驱动的合约测试(consumer-driven context test)是成熟的微服务测试策略(martinfowler.com/articles/microservice-testing/)中非常核心的组成部分。

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

离线优先 Web 应用程序(Offline first web applications)提供了基于缓存和更新机制来设计 Web 应用离线访问的能力。它的实现需要在 DOM 中设定一个标志来检查接入设备是否在线,离线则访问本地存储,在线则同步数据。现在所有的主流浏览器都支持离线模式,通过显示的指定 HTML 属性来使本地信息可访问,同时启动如 HTML, CSS,Javascript 或其他资源的下载和缓存。当前已经有一些工具使离线优先应用的实现变的简单,如 Hoodie(hood.ie),CouchDB(couchdb.apache.org),不仅如此它们还提供与本地部署的本地存储应用的集成能力。

大多数软件开发的心智模型都是做项目,在不同的档期内进行计划、执行和交付。敏捷开发极大的挑战了这种模型,通过与开发过程同时进行的持续需求发现,代替了预先的需求确定。精益创业的技术,如观察需求的 A/B 测试(martinfowler.com/bliki/ObservedRequirement.html),进一步削弱了这种心态。我们认为,大多数的软件开发工作应该遵循精益企业的引领(info.thoughtworks.com/lean-enterprise-book.html),将自己定义为构建支持业务流程的产品。这样的产品并没有所谓的最终交付,更多的是一个探索如何更好的支持和优化业务流程的过程,只要业务依然有价值就会不断持续下去。基于这些理由,我们提倡企业组织依照产品而不是项目(products rather than projects)的思路进行思考。

当前大多数开发团队都意识到编写安全软件并以负责任的方式处理用户数据的重要性。他们确实面临着陡峭的学习曲线和大量的潜在威胁,其范围从有组织的犯罪和政府的间谍活动到仅仅是为“玩笑或激怒什么人”而攻击系统的年轻人。威胁建模(Thread modeling)(owasp.org/index.php/ Category:Threat_Modeling)是一组技术,主要从防御的角度出发,帮助理解和识别潜在的威胁。当把用户故事变为“邪恶用户故事”时,这样的做法可给予团队一个可控且高效的方法使他们的系统更加安全。

Flux(facebook.github.io/flux)是 Facebook 为其互联网应用开发所采用的一种应用架构。它通常与 react.js 一同被提及,Flux 基于一个单向数据流,用户或外部事件对数据存储的修改会触发数据在渲染管道中向上流动。已经有好一阵子我们都没有看到任何古老的model-view-*架构的替代者了,Flux 拥抱这种 Javascript 前端应用与多个后端服务通信的现代互联网时代。

当前,大部分开发人员习惯使用 git 来管理源代码以及协作。但是,git 还可以为其他一些情况提供基础的实现机制,比如当人们需要使用基于文本化的文档进行协作的时候(这些文档可以被很容易的合并)。通过使用基于文本的可编辑格式,我们已经看到越来越多的项目把 git(git-scm.com)作为一个轻量化的 CMS 来使用。Git 有很多强大的功能,通过使用分布式的存储模型,Git 可以支持对变化的跟踪以及寻找替代品。然而,难于大范围采用 Git 的最大原因是 git 对于非编程开发人员来说并不容易学习,而我们期望看到更多的构建在 git 核心之上的工具的出现。这类工具可以为一些特殊听众简化他们的工作流程,如作为内容的作者。我们也欢迎更多的工具支持对比和合并非文本文档。

凤凰服务器(martinfowler.com/bliki/ PhoenixServer.html)的想法现在已经被很好的建立并且在被应用到一些正确的问题上时带来了很多好处。而我们要部署的服务器所依赖的环境,如在某些情况下需要等待网络配置、负载均衡、防火墙端口等等情况,却已逐渐成为修改配置时的主要瓶颈和限制。凤凰环境的概念可以帮助这种情况。它允许我们可以用自动化的方式创建整个环境并保证定期销毁和重建整个环境的流程正确,例如在AWS上使用CloudFormation。凤凰环境可以支持为测试,开发,UAT等等配置一个全新的环境。它也可以简化对灾难恢复环境的配置。由于凤凰服务器的模式并不总是可行的,我们需要小心地对待诸如状态和依赖,在蓝绿部署中用它对环境配置进行重置可以成为一种方式。

函数式反应型编程在过去的几年渐渐开始流行起来,同时这个概念越来越多被延伸到在分布式系统架构中。根据反应型编程宣言(reactivemanifesto.org),反应型架构(reactive architectures)主要基于通过一个网络下独立进程间的单向,异步的不可变事件流(可能具体实现为微服务)。在正确设置下,基于这种架构的系统容易扩展,具有弹性,也会减小了各个独立处理单元间的耦合。但是完全基于异步消息传递的架构同时会引入相应的复杂度,并且常常会依赖于一些专有的框架。所以我们推荐在选择这种架构风格前首先了解自己系统对于性能以及可扩展性的需求。

对于安全,传统的方式依赖于前期的需求规格以及最后阶段的验证。这种“安全三明治”的方式很难应用于敏捷团队,因为大部分设计都贯穿于整个过程,而且也没有持续交付所提供的自动化便利。公司或者组织应着眼于如何在整个敏捷开发周期中注入安全实践。这包括:正确评估当前威胁模型的级别以做前期设计;考虑何时将安全问题划分为独立的故事、验收标准、或全局的非功能性需求;在构建流水线中引入静态或动态的自动化安全测试;考虑如何将更深层次的测试,如渗透测试,引入到持续交付的发布过程中。正如 DevOps 的出现使得过去相互博弈的团队能够重新合作一样,同样的事情也正发生在安全人员和开发人员身上。(尽管我们并不喜欢安全三明治模型,但这也比根本不考虑安全要好得多,糟糕的是,这依然是一种非常普遍的状况。)

 

点击这里可以下载最新中文版本PDF

Share

创业提案的逻辑

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

不确定未来的要素

“投资人”(广义上的,可以是侠义上的投资者、也可以是你的客户和高层管理者)真正投资的是“不确定的未来”,在这份“不确定的未来”里实际上只有两个要素:

  1. 创始人:你和你的团队(即创始人)可能不能适应市场的要求快速和持续的成长;
  2. 市场:客户、客户需求、竞争、技术可能不按照当初设想的方式发展。

事实上,我并没有把产品放在其中,是因为,产品是内部团队对外部市场需求的答案,投资人在首次投资并不要求给出完整而详细的答案,在目前这个阶段它只是让投资人:

  1. 对“不确定未来的”创始人更加有信心:产品的方案部分(Solution)代表了创始人团队对市场需求的回应;
  2. 对“不确定未来的”市场更加有信心:产品的需求(Need)部分市场需求进行了具体化和细分。

对于投资人而言,Pitch结束后更好的结果应该是:

  1. 我对你们有信心;
  2. 我对你们所针对的市场有信心;
  3. 对于你们的产品形态,相信一个好的市场和优秀的你们会慢慢寻找到一个稳定成长的方向。

因此,过分强调现有产品可能喧宾夺主(创始人和市场)、完全忽视产品的描述也有可能减分。

完美逻辑

任何一次创业都是将市场、创始人、投资人三者之间关联,它体现着四种核心关系:

  1. 创始人用产品回应市场机会;
  2. 投资人要求创始人设计商业模式;
  3. 市场给予投资人回报;
  4. 为使得创始人能够运行产品、产生商业模式、最终从市场中获得回报,投资人需要投资。

因此对这四种关系的解答就是一个Pitch的精要,它分作以下7个步骤:

  1. 市场:你面对怎样一个市场?趋势、用户、习惯、需求、竞争、技术等;
  2. 产品:你的产品形态如何?目标用户、场景、功能、定位、竞品、模式、技术等;
  3. 创始人:为什么你和你的团队可以规划、创造、运营这个产品?经验、能力、资源、性格等;
  4. 商业模式:凭什么说这个产品可以带来商业价值?公司结构和治理、收入结构、支出结构、财务预测等;
  5. 投资人:为什么我要投你?投资组合、优势、战略、互补等;
  6. 投资:你需要投资多少?投资形式、合作方式、Burn Rate等;
  7. 回报:我可预期的回报是什么?回报形式、时间、风险等。

事实上,一个短时间的Pitch不可能完全完美回答以上所有这些内容,但是一个好的逻辑顺序引领投资人朝你所期待的方向前进,并帮助你或和你共同回答商业模式、投资、和回报三个问题。

一个好的逻辑顺序

一个好的Pitch永远是故事,你的听众是投资人,你的目标是将投资人拉入到你和市场的这个环中:

在这里,“商业模式”、“投资”、和“回报”不是你最擅长的,却是投资人最关系的三个问题:

  1. 怎么赚钱?
  2. 投多少?
  3. 挣多少?

一个好的逻辑顺序让你避开你最不擅长的领域,而把最吸引人的部分放在了前面所提到的“不确定未来的两个要素”:你(即创始人)和市场。这里我使用最多的逻辑是为以下:

  1. 趋势:市场发生了什么样的趋势?
  2. 人:趋势中人们发生了什么变化?产生了什么需求?
  3. 问题:需求和方案之间存在什么问题?
  4. 方案:我们如何解决这个问题?
  5. 独特处:我们方案的独特处是什么?
  6. 我们:我们是谁?
  7. 目标:我们要做什么?
  8. 状态:我们在做什么?
  9. 资源:我们需要什么资源?
  10. 计划:我们将如何使用资源?

通常一次Pitch的时间可能不超过30分钟,为了保证最后还有10分钟的交流时间,建议每点只用一张幻灯片讲2分钟,幻灯片尽可能视觉化和情景化,例如抽象层次的产品使用场景,而不用出现交互图。

再比如高度抽象化、结合图标设计的目标定义:

此外,根据使用场景的不同,例如投资人2分钟的快速沟通,我们还可以将其简略成五个逻辑,即:

  1. 解决什么问题?
  2. 怎么解决?
  3. 有何不同?
  4. 在做了什么?
  5. 还需要什么?

以一个社交性共享餐饮服务的模式做例子,一个两分钟的快速Pitch逻辑可以是:

用搭伙做饭的方式解决都市人中喜欢下厨的人的社交需求,它采用线上到线下的方式撮合和招揽食客,核心特点是基于一个200人的核心厨师群进行拓展,目前核心厨师群正在完成第50次主题家庭餐会,积累超过2000位食客群,需要场地和资金建设线下的旗舰厨房作为概念店。

如果我们只有30秒,我们该如何表达这个逻辑呢?

我们帮爱做饭的人寻找厨友和食客,有200个核心厨师加盟、2000食客、50次餐会,现在找地方找钱建线下概念店。

你看,越简单的逻辑越不出现解决方案,只告诉你我们在帮助谁?帮助什么?我们做了什么?我们要什么?这是不是比那种“我有一个想法”式的表述更加打动人?

最后,作为创始人,Pitch也许是每天在不同场合发生的事情,手上应该有适合2小时、30分钟、2分钟、30秒不同时长进行的口头表达,同时也有从30页PPT、5页PPT、移动端网站、名片等不同介质的平面表达。一个顺畅的逻辑表达(无论是口头还是平面)也让你更加清晰你和你的创始人团队、以及你所面对的市场,它也可以用来帮助招募早期和合伙人。

写在最后

打动投资人的是你展现的一个“有利可图”的不确定未来,里面是一个“有利可图”的团队,加一个“有利可图”的市场,同时在创业初期,我们不可能把市场、创始人团队、以及投资人所相互关联的逻辑关系彻底厘清,我们需要的是一个能够反复练习的逻辑,熟记在心,并在任何时候表达出来,随时接受挑战、并反复打磨。

我做业务分析师的时候,有这么一句话,“讲都讲不明白的需求十有八九是没必要做的”,那么讲都讲不通顺的创业逻辑,意味什么?最后的最后,一千次创业者热血沸腾的说道,也比不过一条从头到尾的逻辑。

Share

2015.5 技术雷达 | 工具篇

点击这里可以下载最新中文版本PDF

0

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

在企业级应用中,对组件进行良好的测试至关重要,尤其是对于服务的分离和自动化部署这两个关系到微服务架构是否成功的关键因素,我们更需要更合适的工具对其进行测试。“服务虚拟化”这一行业术语,意指能够在组件化服务的场景下模拟特定组件的工具。Mountebank 显然取得了不错的成绩。它是一个轻量的测试工具,可以被用于对 HTTP、HTTPS、SMTP 和 TCP 进行模拟(Mock)和打桩(Stub)。

 

Postman(getpostman.com/features)是一个在 Chrome 中使用的 REST 客户端插件,通过 Postman,你可以创建请求并且分析服务器端返回的信息。这个工具在开发新的 API 或者实现对于已有 API 的客户端访问代码时非常有用。Postman 支持 OAuth1 和 OAuth2,并且对于返回的 JSON 和 XML 数据都会进行排版。通过使用 Postman,你可以查看你通过 Postman 之前发起过的请求,并且可以非常友好的编辑测试数据去测试 API 在不同请求下的返回。同时,虽然我们不鼓励录屏式的测试方法,但是 Postman 提供了一系列的拓展允许我们将它作为跑测试的工具。

 

Brighter(iancooper.github.io/Paramore/Brighter.html)是一个基于.Net的开源工具库,主要实现了命令调用模式。我们从正在使用它的一些团队中收到了很好的反馈,尤其在与端口模式、适配器模式和命令查询职责分离模式(CQRS)一起使用的时候。特别值得一提的是,它还可以很好地与 Polly(github.com/michael-wolfenden/Polly)集成并提供熔断器模式的支持。

 

支持 DNS 和基于 HTTP 发现机制的服务发现工具 Consul(consul.io)持续让我们印象深刻。它提供了定制化的注册服务健康检查并标记不健康实例的功能远胜于其他类似的工具。更多时兴的工具与Consul的集成使其功能更加强大。Consul Template (github.com/hashicorp/consultemplate) 可以直接使用Consul的信息来填充配置文件,使得像用mod_proxy进行客户端负载均衡更加容易。在使用Docker的场景里,有了registrator (github.com/gliderlabs/registrator) 的帮助,只需要很小的工作量就可以自动化地向Consul注册Docker容器,使得管理基于容器技术的配置更加容易。

在我们软件开发领域,盲目地假设网络总是可靠,服务器总是能够快速并正确的响应导致了许多失败的案例。Hamms (github.com/kevinburke/hamms)是一个有趣的开源工具,它可以模拟一个行为损坏的HTTP服务器,触发一系列的失败,包括连接失败,或者响应缓慢,或者畸形的响应。它可以帮助我们更优雅的测试我们的软件在处理异常时的反应。

我们的多个使用.NET技术栈的项目已经在推广使用Polly(github.com/michael-wolfenden/ Polly)来帮助我们构建基于微服务的系统。它鼓励使用基于流畅表达式的透明错误处理机制,以及包含了多种断路模式(Circuit Breaker Pattern),如重试,不断重试,稍后重试。在其他语言中已经存在类似的程序库,如Java中的Hystrix,而Polly是.NET家族的一个很好补充。

REST-assured(code.google.com/p/rest-assured)是一个用于测试和验证RESTful服务的Java DSL。它使得为基于HTTP的RESTful服务编写测试变得更加简单。REST-assured支持不同类型的REST请求,并且可以验证请求从API返回的结果。它同时提供了JSON校验机制,用于验证返回的JSON数据是符合预期的。

 

ZED Attack Proxy(ZAP)(owasp.org/index.php/ OWASP_Zed_Attack_Proxy_Project)是一个OWASP的项目,允许你以自动化的方式探测已有站点的安全漏洞。可以用来做定期的安全测试,或者集成到CD的Pipleline中提供一个持续的常规安全漏洞检测。使用ZAP这样的工具并不能替换掉对安全的仔细思考或者其他的系统测试,但是作为一个保证我们的系统更安全的工具,还是很值得添加到你的工具集里。

 

相对于通过发送同步点对点请求的方式修改状态,最近许多企业级软件开发都在致力于基于异步不变事件序列的架构演进。Apache Kafka是一个开源消息框架,它支持基于有序的发布消息到许多独立的轻量级的消费方的架构风格。Kafka的独特设计使它能够在保持消息顺序强相关的前提下动态增加消费方的数量 。

 

Blackbox(github.com/StackExchange/blackbox)是一个用于加密源代码仓库中特定文件的简单工具。如果你需要存储密码或者私钥的时候,这个工具特别实用。Blackbox 可以和 Git,Merurial 和 Subversion 结合使用,并使用 GPG 加密。每个用户拥有自己的密钥,使得细粒度级别的权限撤销变得很容易。这个领域正在发生很多变化,一些其他的工具也可以考虑包含进来,如 git-crypt Trousseau

 

在数据科学和分析的世界里,大部分工作都是使用 Python 和 R 来完成,但是这两个语言只为 Web 可访问的可视化图形绘制提供了有限的几个支持。一种做法是将分析的结果转换成为能够在浏览器里很容易呈现和交互的格式。我们知道有两个工具来尝试这样做。Bokeh 是一个可以让你创建像 D3.js 一样风格的交互式可视化的 Python 和 JavaScript 库,但是在处理大数据集或者流式的数据集时,具有更高的性能。Vega 是一种针对 D3 的声明式可视化语法,它接收服务器端生成的 JSON 数据并将可视化描述转化为 D3.js 的代码。

 

Gor是一个开源工具, 可以实时捕获线上HTTP请求,并在测试环境中重放这些HTTP请求,以帮助我们使用到这些产品环境数据来持续测试我们的系统。使用它之后可以大大提高我们在产品部署,配置修改或者基础架构变化时的信心。

 

NaCl (nacl.cr.yp.to) 库(读作‘Salt’)提供了关于加密,解密和数字签名的一系列的功能,使得实现安全的网络传输,或者满足其他密码学方面的需求变得简单。尽管有一些其他的工具库也能提供这些功能,NaCl 承诺提供更快的速度和更简单易用的 API。当前支持 C 和 C++ 的库,关于 Python 的封装正在进行中。

Origami (facebook.github.io/origami) 是一款免费的用户原型设计工具,其对常用功能提供了大量的快捷键操作。它为将原型设计导出为代码片段提供了可能性,支持的语言有:iOS开发上的Objective-C,Android开发上的Java,以及Web开发上的Javascript。该工具可以被用来快速构建面向用户的交互式原型和测试用户使用流程。根据从一些团队收集的使用经验来看,我们建议您在需要时对该工具进行考察。

 

Pdfmake是一个可以在浏览器里直接生成和打印PDF文档的JavaScript库。使用pdfmake,你可以创建一个支持表、列和富样式等结构元素的文档,再通过辅助方法创建并打印或者下载为不包含客户端JavaScript的PDF文件。

在我们的经验中,相比其他办法而言,通过在一开始创建大量详尽的设计图表来开发软件系统,并不是什么好的选择。但用图表来表达系统中格外复杂和难懂的部分却往往是个好的想法,何况UML本身也已经提供了若干实用的、众所周知的图表。我们喜欢用 PlantUML(plantuml.sourceforge.net)来创建这些图表,因为它让我们以清晰的文字形式来表达图表背后的意图,而不用再去摆弄那些“过度”的图形化工具。同时,文字形式的表达方式还支持版本管理,并且可以和源代码存放在一起。

SoundCloud最近开源了一个Graphite的替代品:Prometheus (prometheus.io)。SoundCloud在解决生产环境中使用Graphite所遇到的困难的过程中,开发了Prometheus,它的工作方式和Graphite不同,主要体现在其对基于HTTP的拉模型的支持上(尽管它也支持和Graphite更类似的推模型)。不仅如此,它还因为支持根据获取到的度量指标进行告警的功能而比Graphite更胜一筹,所以,在你的运维工具套件中他会变得更加活跃。尽管在生产监控领域采用新技术需要谨慎行之,但早前的报告亦显示,SoundCloud对其在生产环境使用Prometheus表示满意,而且Docker也已参与到该工具后续的开发工作中。

Quick是一个针对Swift和Objective-C的测试框架,它和用来做测试验证的Nimble捆绑发布。Quick主要用于Swift和Objective-c程序行为的验证。它和rspec和jasmine具有相同的语法风格,基础环境很容易建立。Quick良好的结构和类型断言使得测试异步程序更加容易。

 

Security Monkey 是 Netflix Simian Army 工具系统中的一员,设计这套工具的初衷是为了确保系统是以有弹性的方式构建的。它不仅提供了针对AWS设置进行可配置的潜在安全漏洞评估功能,还对正在使用的 AWS 设置的变更进行监控并及时通知相应的负责团队。早于 AWS 的 Trusted Advisor Report 和 Cloudtrail 可用之前开发出来的Security Monkey虽然提供的功能在某种程度上与他们有些重叠,但Security Monkey还提供了更多的功能。如果这些 AWS 的服务不太能够满足你的需求,Security Monkey值得一试。

 

点击这里可以下载最新中文版本PDF

Share