可牺牲的架构

你坐在会议室里,凝视着你的团队在过去数年一直维护的代码。你已经做出了决定,你现在能够做的、最好的选择就是扔掉所有的代码,重建一个全新的架构。对于这些命中注定的代码、你投入其中的时间、此刻之前所做的那些决定,你该作何感想呢?

对于很多人而言,扔掉代码库是失败的象征,鉴于软件开发固有的探索性质而言是可理解的,但是,这仍然是失败。

不过,你现在能够编写的最好代码常常是你在数年之后要抛弃的代码。

架构是有寿命的

我们经常把伟大的代码视作永久的软件。作为一名编辑,我写这篇文章时的身份可追溯到1980年。对于软件架构是 如何减轻某种永久 做了很多思考。然而你的成功可以建立在代码之上,因为被送到了 /dev/null。

想一下网络上最成功的大型商务网站之一的、eBay的故事。它在1995年用了一周时间,从一堆perl脚本开始。在1997年,它推翻一切,在当时的windows工具之上,用C++编写的系统取而代之。然后到了2002年,应用程序用Java重写了。早期的版本因为它们被取代了就成为了错误吗?很难这样说。eBay目前仍然是web上最伟大的一个成功,但是成功的大部分因素是建立在90年代被抛弃的那些软件上。就像很多成功的网站一样,eBay已经看到了指数级的增长,指数级的增长对于架构不是友好的。支持1996年eBay的合适架构,对于2006年eBay来说,就不是合适的了。1996年的架构无法处理2006年的负载,但是2006年的版本太过复杂而难以建立、维护,它是根据1996年的需求演化而来的。

的确,这个原则可以引出工作的一种组织方式。在Google,大家熟知的要求就是设计一个满足当前10倍需求的系统,这暗示着如果需求超过了一个数量级,那么扔掉并从头做起是更好的。每隔几年就被重新设计与抛弃的子系统而言,这是非常普遍的。

的确,我们通常可以看到,刚接手一个成熟代码库的人们诟病架构的性能和可伸缩性。但是在软件系统的早期阶段,你不一定要确保它真正需要做什么,关注灵活性以应付功能改变是十分重要的,而不是性能或可获得性。随着你的用户越来越多,你需要切换优先级了,不过让太多用户处在一个低性能的代码库,通常是优先级较高的问题,而不是优先级低。Jeff Atwood发明了一句话“性能是功能”,一些人把它理解成性能总是第一优先级。但是任何功能只是你不得不从其它功能选出的。这不是说,你应该忽视性能之类的工作——软件可以变慢、不可靠到断送一个业务——但是团队不得不与其它需求做出痛苦的抉择。通常有更多的业务决定,而不是技术上的决定。

那么这意味着要故意选择一个可牺牲的架构吗?本质上它意味着接受,因为若干年后你将(如果顺利的话)扔掉当前创建的东东。这说明了要接受你堆放在一起的、跨功能需求的限制。这也说明了现在需要考虑,当这一刻到来的时候,如何能够让其变得容易——软件设计师很少考虑如何设计他们的创造,以支持将来的优雅替换。这也意味着在相对短的时间内被扔掉的软件,仍然带来了很大的价值。

明白了你的架构是可牺牲的,不代表要放弃软件的内部质量。通常,被牺牲掉的内部质量,将比替代时间更早地伤害到你,除非你已经工作在行将退役的代码库上。良好的模块化是健康代码库的关键部分,模块化通常在替换系统时起到巨大的帮助。对于系统的早期版本,要做的最好的一项工作就是搞清楚什么是最好的模块化结构,为将来的替换做准备。虽说在早期牺牲一整个系统是合理的,但是如果具备良好的边界,随着系统的增长,牺牲单个模块是更有效率的。

处理这个问题时,容易忽略的一个方面就是结算。是的,真的如此——我们已经陷入 人们不情愿替代一个明显的、不可行的系统 的状况,因为他们正在分期偿还代码库的方式。对于大企业,这更像是一个问题,但是不要忘了,只要你生活在这个世界上,就要去检查一下。

你还可以把这个原则应用到现有系统的功能上。如果你正在开发新功能,那么只让一部分用户可见是明智的,因为你能够得到 它是不是一个好想法 的反馈。为了达到这个目的,开始的时候,你可能在以一种可牺牲的方式在开发,你不必在一个功能上投入全力,因为你可能发现它不值得全面部署。

模块可替换性对于微服务是一个主要论据,但是我谨慎推荐可牺牲的架构。微服务暗示着分布和同步,它俩都是复杂的助推器。我已经碰到过一些项目,它们在走不是真正需要的微服务道路——结果严重减缓了它们的功能管道。因此,借助后来引入的微服务,逐渐将庞然大物分解,而庞然大物经常是好的可牺牲架构。

编写可牺牲架构的团队要决定牺牲它的时机。对于接手的新团队而言,他们讨厌现有代码、想重写,这是不同的情况。如果你没有理解已编写代码的上下文,你很容易就厌恶你没有编写的代码,明白你将要编写的代码属于可牺牲的代码,将是一个有用的变数。

致谢

与Randy Shoup的谈话启发了我,并帮助我构思了本文,尤其是eBay(和一些Google的类似故事)的历史描述。 Jonny Leroy指出了结算问题。Keif Morris, Jason Yip, Mahendra Kariya, Jessica Kerr, Rahul Jain, Andrew Kiellor, Fabio Pereira, Pramod Sadalage, Jen Smith, Charles Haynes, Scott Robinson and Paul Hammant 提供了有帮助的评论。

原文地址:http://martinfowler.com/bliki/SacrificialArchitecture.html

原创文章,转载请注明: 转载自腊八粥

本文链接地址: 可牺牲的架构

用JavaScript实现数据可视化

现在很难忽略我们生活中数据的重要性了。数据对于人类历史中的最大的社会组织是至关重要的,最不济它能影响到我们的日常决定。它的集合具有世界范围内的地缘政治影响。然而忽略数据本身貌似正变得更加容易了。我们的调查显示,我们系统收集的99.5%的数据被浪费了,从来没人有效地分析过它。

数据可视化是填补这一空白的工具。

有效的可视化澄清;它们把抽象的古董(熟知的数字)转换成浏览者快速领会和理解的形状和图表。事实上,最好的可视化,是在潜意识地传递这个理解。浏览者立即就领会了数据——不用思考。这种呈现把浏览者解放出来,让他们更加专注地考虑数据的意义:它讲述的事实,揭示的见解,甚至提供的警告。当然,它定义了最好的沟通类型。

如果今天你正在开发网站或web应用程序,就有一个表达数据的好机会,这些数据需要良好的可视化。但是,你怎么知道哪种可视化是合适的?甚至更重要的是,你该如何真正创建?这些问题的答案正是本书的核心。在下面的章节里,我们探索了很多可视化、可视化技术与工具集。每个例子讨论了可视化的适用范围(建议了可能的替代产品),并提供了把可视化包含在你自己网页里的、一步一步的操作。

为了让你快速了解这本书,我们对于 这本书是什么、以及不是什么 做了简介。

实现 VS 设计

本书没有教你如何设计数据可视化。老实讲,其他作者比我们更有资格做这项工作。(比如,你一定比Edward Tufte做得差多了)不过,我们关注实现可视化。适当的时候,我们从稍微宏观的视角讨论下具体的可视化策略的适用范围,不过我意识到,有时候老板绝对坚持饼图。

代码 VS 样式

正如你根据标题所猜测的,本书致力于创建可视化的JavaScript代码。我们不会花太多时间讨论这些可视化的样式。幸运的是,为可视化设置样式和为其他网页内容设置样式,是完全一样的。HTML和CSS的基础经验对你在网页中添加可视化是有极大帮助的。这些例子没有假定你是JavaScript专家,我们确信理解、并小心地解释比基本的jQuery复杂的任何代码。

简单 VS 复杂

书中大部分例子是简单的、直接的可视化。复杂的可视化是让人着迷、不可抗拒的,但是学习太多的高级代码通常不是学习这门手艺的最佳方法。在我们的例子里,我们尽可能保持简单,让你清晰地看到如何使用各种工具和技巧。简单并不意味着“令人厌烦”,因为,即使是最简单的可视化,也是有启迪性和趣味的。

现实 VS 理想世界

当你开始构建自己的可视化,你会发现现实世界很少与我们期望的一样和谐。开源类库有bug;第三方服务器有安全漏洞,不是每个用户都会更新到最新的、最伟大的web浏览器。在这些例子中,我们没有忽视这个现实。在实践中如何兼容低版本浏览器,如何遵循像CORS【注1】之类的安全限制,如何在其他人的代码里与bug共存。

示例的源代码

为了保证文字尽可能清晰和可读性,这些例子通常包含了JavaScript孤立片断,还有偶尔的HTML或CSS片断。所有例子完整的源代码在GitHub上可获得。

致谢

原创文章,转载请注明: 转载自腊八粥

本文链接地址: 用JavaScript实现数据可视化

用语音编程:不用伤害自己就可保持效率

我喜爱在ExtraHop工作的原因之一就是会议少、大块大块的连续开发时间。然而,我很快发现,我不习惯长时间敲代码了。我在ExtraHop工作数周后,我的手腕和胳膊不太舒服。这些地方在过去是断断续续的不舒服,但是放在以前,限制晚上在家使用电脑足以解决这个问题。不过,这一次不同了。

400x283xTony-ExtraHop
#Tony Grosinger是ExtraHop网络公司的框架工程师。

做为一个刚刚毕业的大学生,我担心每天的工作活动会引起永久性损伤。我开始研究人类工程学键盘和鼠标,期望找到万全的解决方式。正如你猜测的,我没有找到有魔力的方法,我的状态每况愈下。

这种不适让我沮丧,我更加担心,这种伤害将妨碍我在工作和生活上的快速、轻松创造和交流。

介绍一种方法

在尝试、摒弃了一些其它方法之后,ExtraHop的一个同事向我展示了Tavis Rudd的视频,Rudd用其声音编程。起初,我怀疑这种方法的可靠性和效率。不过,看了视频之后,我坚信声音输入对于程序员来说是一种并行的选择。Rudd患有类似的病症,他已经搜寻了我刚做的所有类似调查,最终认为,再好的键盘也不足以解决这种痛苦。

那天晚上,我在网上查找那些通过声音编程的人,想找到提示和教程。这些人少之又少,很多人断言这是不现实的。我没有那么容易放弃掉,开始鼓捣一个工具包,它支持在Linux机器上通过声音编程。

配置:最难的部分

很快就搞清楚了,Dragon NaturallySpeaking是听写软件中的唯一选择。他们的产品在语言识别上领先其他人很多,但是他只能运行在Windows或Mac上。不幸的是,我在Wine【注1】上从来没有成功运行过Dragon NaturallySpeaking,我不得不在Windows虚拟机上,设置代理到Linux主机的命令。

我在本文将略去一些配置步骤,你可以在我的Github repo找到如何搞定一切的详细指令。

如果你按照那些指令做了,你现在应该能够发送口授和示例命令到你的Linux主机了,不过离编程不远了。我在接下来的两周里编写语法,大部分过程是这样的:

  • 期望执行一个任务(编程、切换窗口等)。
  • 编写让我通过声音实现这个任务的命令。
  • 测试命令,增加相关的命令。
  • 重复。

这个过程进展缓慢,我希望,链接的仓库帮你避免从头开始。甚至在用了大概一个月以后,我每天仍然数次调整命令。Tavis Rudd宣称有2000多个自定义命令,这意味着我必须还有很多工作要做。

结果

如Rudd在讲话中解释的一样,麦克风是安装中的关键点。只能听到你的、好的麦克风将在识别的精度和速度上产生巨大的不同。我非常喜欢正在使用的Blue Yeti,但是我只有在办公室绝对安静的前提下才能使用它。

根据目前我建立的命令,我可以在窗口切换,导航web(借助Vimium【注2】),在工作区切换,还有最重要的,我可以用合理的速度进行Python和Go的编程。这没有使用键盘编程快,不过一旦你掌握了这些命令,它还是有着惊人的效率。

我在上面提到的Github仓库分享的语法是针对我所需的工作流。我推荐你把它们作为起点,但要注意计算机可能识别你的词语与我的不一样。这些语法也是我经常用到的、针对特定语言的。请不要犹豫写下你喜爱的语言。最后,在dotfiles仓库里的.vimrc文件,可以找到声音命令触发器的自定义快捷方式。

用声音编程还不完美,不过它已经达到了可作为实际选项的地步。不要继续忍受手腕和胳膊的不适了,因为现在有了替代方法。欢迎给我发送pull request,我们可以继续让声音编程变得更好。

原创文章,转载请注明: 转载自腊八粥

本文链接地址: 用语音编程:不用伤害自己就可保持效率

嘿,我正在写一本关于Uber的书

我有一些私人消息分享,我正在写一本书。是的,一本你可以拿在手里、或者下载到Kindle里的书。虽然认识我的很多人都是通过blog上的文章,但是我没有把自己看成是作家——因为,这仅仅是我与周围世界互动的方式,仅仅是我一直在做的工作的一个副产品,包括公司里、风投上,还有做为一个独立投资者的工作。然而,一个月前的周日早上,在我与一堆同事借道前往一个足球比赛之前,我们喝了一些啤酒,说到了这个话题,进而演变成了较长的谈话。

从那以后,我就赶不走这个想法了。我考虑得越多,我与朋友交流得就越多,他们也认为这是一个好想法,我的背景是广度大于深度,能够完成这本书,从广度上分享关联的想法,这将提供一个有趣的视角。我打算让这本书成为这个博客的外延扩展,通过精细的组织,以可信、文明的方式分享故事,并吸引合适的受众。

“好吧,”你说,“那么这本书是关于什么的!?”我答道:“Uber【注1】”。由于缺乏较好的标题,现在,我称之为:“Uber效应(The Uber Effect)”。

在去年,我注意到我写了越来越多关于Uber的博客,然后我在本站搜索了历史,我发现它比我想象得要多。最近,它更多地出现在对话里,当与我谈话的人们意识到这个公司很了不起、但是存在一个比较痛苦的时刻,那就是去想象这个公司能够达到多大规模、它能够聚集、发挥多大的影响,这些对话变成了讨论,涉及到我们今天如何组织社会的方方面面。我考虑这个公司及其增长潜力越多,我就越意识到它不仅仅是一个财务强大的公司,而且Uber将拥有涉及到数据、移动性、物流、商务、交通等其它所有种类的能力。就像之前的亚马逊、Google和Facebook,它是一家千载难逢的公司,它在未来的两年处于走向公众的边缘,随着鼓声越来越响,我做出了个人决定,用我的一些时间去组织和讲述这个故事。

“这本书包括什么?”你问。我仍然在整理,但是期望它能涉及到,移动设备是如何帮助建立了我们社会所目击到的最大的技术市场,人类是如何在世界范围内迁移到城市的,中央化系统(比如政府)是如何面临去中心化网络的挑战,人们更愿意按照里程数付费而不愿支付更多的税,关于公共交通设施随后的影响,在高技能和无人驾驶刚刚兴起不是一个时代之间的分化的劳动力,基于云的服务器和移动设备的知识上的分布,由移动设备驱动的、即时存货管理,无人驾驶汽车如何再次颠覆的前景。

真实情况是,我仍然在整理,在与代理商和发布商沟通,但是我想交付,因此我公开分享它,我需要真正细化这个范围和焦点。我猜,这就是假期到来的原因!

总之,下面列出的几点,都不会出现在本书里

一,这本书不是关于这家公司的诽谤,也不是成为这家公司的学术拉拉队长的借口。我看涨Uber,热爱自己的股票,但是我与这家公司没有财务关系,我深信Uber面对好未来的颠簸时光。Uber也是一家被很多人描述为“无底线”的公司,我将调查这些故事。我想写一本客观的书。

二,这本书不会有不合时宜的长篇大论——像一个智者深入研究数周,经过理解和消化,然后与其他人谈论,我想用这种风格。

三,这本书不会加入关于公司构成或创业竞争方面的漫谈细节——其他人从这个角度看是没有错的,我确信这是有受众的,但是它不会让我本人感兴趣。

四,它不会藉此炫耀数据图表(data porn)【注2】——我不想依赖于得到独家数据,也不想就展开打上了图表标签的辩论。不认同这本书的人会有的,这很好——那有什么呢,目前,很多聪明人认为这家公司被过高估值了。

五,我的目标不是让这本书成为经典的商业或战略方面的书——想想David Sedaris短小精悍的《Holidays On Ice》,每个假期可以读到,在这个博客上有许多这种类型的文章,不过这本书组织得更好了。

六,它不是Uber的“官方”账户或“官方”的书。我没有这种权限,也不会做这种声明。它只是我对这家公司的观点,超过了本博客所提供的细节程度,还有为那些对全球化、移动技术、新业务模型、劳动力市场和重塑城市问题感兴趣的、普通用户准备的内容。

就这样了。我会分享组织好的更多细节。很可能从一个内容目录开始。将有很多人阅读,在Twitter上有比我理解得更好的人——我写这本书,既是为了那些看到了Uber浪潮即将到来的早期技术从业者,也是为了还没有看到这些的普通大众。我希望我能够在这里定下期望,写一本满足这两种人群的书。感谢阅读,感谢一直收听我的想法,并提供反馈的朋友和观众。(还有,本文可能有一些打字稿,因此我安排了一个编辑和事实审查员来校正这本书。)

  • 原文地址:http://blog.semilshah.com/2014/10/19/hey-im-writing-a-book-about-uber/
  • 注1:优步(英语:Uber)是一间风险投资的创业公司和交通网络公司,总部位于美国加利佛尼亚州旧金山,以移动应用程序链接乘客和司机,提供租车及实时共乘的服务。优步已在全世界数十个城市提供服务。乘客可以通过发送短信或是使用移动应用程序来预约车辆,利用移动应用程序时还可以追踪车辆的位置。http://zh.wikipedia.org/wiki/優步
  • 注2:数据可视化本来就是描述性统计学的分支,除非你是那种明白「data porn」是什么意思的人,否则从来没有人能保证将一组数据做成饼图、柱状图或是其它什么图之后能让你获得视觉高潮。信息图的目的在于揭示数据背后的趋势和规律,而不是美化版面和页面。为原本枯燥的数据披上性感外衣,有时可以是一种不道德。http://qdaily.com/display/articles/1573

原创文章,转载请注明: 转载自腊八粥

本文链接地址: 嘿,我正在写一本关于Uber的书

少一些密码

在Mozilla,我帮助开发一个不依赖密码的登录系统。它也不使用诸如Facebook之类的社会化平台的登录。我认为我们已经创造了并行的替代方案——我乐于看到被使用,被其他设计师和开发者继续推动发展。当我们彼此身边的、需要密码的网站越少,被忘记的、被盗的、跨站点用一个密码的情况就会越少。

加入按钮

在本文,你可以了解到系统设计和用户体验。如果你对整个事情感兴趣,可以移步到Webmaker blog上的文章

加入——快速、简单

我们简化了加入Webmaker的流程。以前,在人们能够访问Webmaker之前,需要首先注册一个角色。这是莫名其妙的(因为名字和平台可能是新的、也不熟悉)。现在,新用户只需要输入他们的邮箱、选择一个用户名。他们马上就能访问Webmaker,不需要验证其账户。验证发生在用户首次登陆、或如果他们试着公布时去手动触发。(我们即将支持电话号码和短信,以作为邮箱的代替。)

join1

登录 ——不需要密码

登录就更有意思了。

网上已经有很多人讨论过这个话题了,我采用了通常的忘记密码的体验,并改造成主要的登录表单。

sign-in

一个人能够用他们的用户名和邮箱地址登录。Webmaker发送一封邮件,只有他们能够访问。这封邮件包含了一个登录按钮,和“记住我”的链接。这两种选择都会把他们带入网站、无需更多的点击。

登录表单

登录 ——跨设备

一些人是在学校或图书馆的公共电脑上使用Webmaker的。他们或许在手机上收到了登录邮件。对于这种情况,这封邮件将包含一个简短的key,他们可以看到并跨设备拷贝下来(上面邮件的黄色部分)。下面的图表描述了这个流程。

跨设备登录的流程图

这个key是临时的。一次使用或30分钟后,都会过期。如果被滥用,它也会在暴力破解时过期失效。

登录 ——可选的密码

对于在图书馆的公共电脑上工作的人们来说,密码可能是有用的。我们让密码变成可选择的,添加起来比较容易。事实上,人们在旅游的时候添加一个密码,当他们回到家里时就删除它,针对这两种情况的不同而顺畅地切换,以获取最佳体验。

sign-in-password

我想检验的一个理论是:如果我们在人们努力回忆自己密码的时刻,允许他们脱离密码,那么我们将增加这种替代登录方式的普及和理解。

password-opt-out

密码可以在个人首页上添加。上面展示的登录邮件上的链接,也可以做到。这个链接既做为登录链接,又把用户导向设置密码的地方。

服务器端的流程

人们将拥有根据他们的状况量身定制的体验,支持他们通过链接、key或者密码登录。服务器流畅地管理者这种体验,甚至对于那些忘记了以前建立过账户的人们,也是如此。

免密码的服务器端的流程图

反馈和讨论

我们欢迎你的反馈和疑问,在Webmaker上有更多关于这个项目的信息。你也可以在我们的开发人员Chris DeCairos写的文章里找到更多的技术讨论

致谢

原文地址:http://notebook.ideapublic.org/2014/one-less-password/

原创文章,转载请注明: 转载自腊八粥

本文链接地址: 少一些密码